I'd like to work on a game, but for rapidly prototyping it, I'd like to keep it as simple as possible, so I'd do everything in top-down 2D in GDI+ and WinForms (hey, I like them!), so I can concentrate on the logic and architecture of the game itself.
I thinking about having the whole game logic (server) in one assembly, where the WinForms app would be a client to that game, and if/when the time is right, I'd write a 3D client.
I am tempted to use XNA, but I haven't really looked into it, so I don't know if it won't take too much time getting up to speed - I really don't want to spent much time doing other stuff than the game logic, at least while I have the inspiration. But I wouldn't have to abandon everything and transfer to new platform when transitioning from 2D to 3D.
Another idea is just to get over it and learn XNA/Unity/SDL/something at least to that level so I can make the same 2D version as I could in GDI+, and I won't have to worry about switching frameworks anymore.
Let's just say that the game is the kind where you watch a dude from behind, you run around the gameworld and interact with objects. So the bird's eye perspective could be doable for now.
Thanks.
You should really just bite the bullet and take a look at one of the frameworks you mentioned.
SDL is pretty good, but honestly, if you want to just get down to writing your game, XNA is incredible.
If you are already experienced in C#, you could follow the on-line tutorials, but picking up just a single book on XNA is enough to really get you going.
This too long for a comment but... Your game physics world should pretty much be independent of the type of view you're using to see it. As an example, it's not uncommon for RTS (like say Warcraft III) to offer both a 3D view and a "mini map". If you think about it, Warcraft 1 that was 2D isn't that different from Warcraft 3 (which is fake 3D, but represented using real 3D).
Another example, you're talking about watching some character walking: it's not unlike CounterStrike (well, in CS you are the dude but anyway), where you have both your 3D view and also a minimap. And gameplay aside, I sure can walk around "Dust" (one of the most famous CS map) using only my minimap: I don't need the 3D view to walk around (now of course to aim I can't use the minimap).
In a lot of game the "physics world" is not the same as the "3D world": otherwise people with different configs wouldn't be able to play in a network game.
Another CounterStrike example: I had a really old crappy celeron with a crappy graphic card that was barely enough to run the game, so I modded the game to use "low polygons" models for the characters (this greatly enhanced the rendering speed and hence made the game very playable on my crappy config). And I still could play networked. Why? Because changing the view world doesn't change the physics world.
So the "view" really shouldn't be influencing too much your model because the view is a detail. Now of course you have to somehow decide on what you want: but if the "dude" you mentioned could be followed using a 2D top-down view as well as an isometric view as well as an "FPS-like" 3D view, then by all mean model your "physics" in a way that is completely unrelated to the view. That way you'll be able to start with something simple: 2D view, using pixels (like a CounterStrike or a Warcraft 3 minimap). And later on you can start adding a 3D view.
Now the kind of world you need to use depends on what you want: heck, there are both "2D physics / 3D view games", "3D physics / 2D view games", "2D physics / 2.5D view games" (GIYF if you don't know about the '2.5D' term in videogame development), etc.
My point is: the view is unrelated to the model/physics (once again, otherwise people couldn't be playing networked game of CounterStrike or Warcraft).
I'm not a game programmer, but I know that the difference between modeling physics problems in 2D and 3D is huge.
I agree that it's a good idea to start with 2D, but don't expect to be able to reuse much of that code in the 3D version. 3D is a different animal.
Related
Pako Game
Hi there, I am just starting game development. Specifically with Unity, Android Studio, and C#. Me and my group planned to make a game for our thesis. The problem is that, our professors want us to make a 3D game if possible. Our proposed game is something like Dr.Driving a car simulation where it involves safety signs, road signs and their regulation. Wherein it should look like in the picture(the pako game)
And my question is that, is it easy to make a 3D game for someone newbie like me? Is there any way where I can just import package assets or API? so that I won't spend much more time in designing the environments and even the car?
Your reply will be appreciated. Thank you very much :)
credits to the picture: Pako Game
Spent some time learning the interface, Unity3D is a game engine and as any other game engine, is just a toolbox that let you do things in multiple ways: https://unity3d.com/fr/learn/tutorials/topics/interface-essentials/interface-overview
Forget about your project and spent some time discovering Unity SDK, make a simple pong or tetris or space invader just to get a habit of how Unity forces you to do things it's way (quite different than common OOP)
Discover the Asset Store to find packages that could help you, at least for the visual and the 3C of a game (Character, Camera, Control)
Then and until then, you can be able to sit down and implement your custom game logic. Good Luck.
is it easy to make a 3D game for someone newbie like me?
There are a lot of flavors of newbie. You will need to:
Have or gain some mastery over the Unity interface.
Have or gain some mastery over programming (I'd say in C#).
Have or gain some mastery over Blender* (or rely on 3rd party assets)
Have or gain some mastery over Audacity* (or rely on 3rd party assets)
Have or gain some mastery over story-telling, project management, etc...
So perhaps the easy answer is, "No."? Ultimately, what is easy for one is not easy for another. Easy or not, there will be a lot of work involved, if you plan to create anything worthwhile. That's how it "works".
Is there any way where I can just import package assets or API? so that I won't spend much more time in designing the environments and even the car?
As mentioned, the Asset Store can help you get quickly from A to B or even X, Y or Z. There are assets that are basically complete mini-games, ready to be branded and rolled-out, and there are assets that are just a model or pack of sound-effects. And of course, everything in-between.
In your case, it sounds like you might also need to have or gain some mastery with a modeling tool, such as Blender. It might be your easiest way to get the specific assets you need in terms of the safety signs, but then again, if you are using generic stop and yield type signs the chances are the assets can be found in either the Asset Store, or a 3rd party site like a Blender model site.
*Note: I mention Audacity and Blender because they are free to use, but of course you can use whatever software you like to create your audio and graphical assets.
For those who find the learning curve of Unity too steep for their time or their project, perhaps something like Game Builder would be a better starting-point.
Edit: As comments said, this question is way too complex so I only hope to get answers which focus on one certain part of this question. Welcome to any ideas in your mind.
I'm working on a project where I am supposed to analysis GIS (vector) data to extract road features like axis and border in a large scale city road network, then procedurally generate the 3D road model representation based on these features, and the objective is a 3d editable road network geometry in Unity which I can easily adjust the position/width/height... of each road in it(and of course get immediate proper feedback like what we can see in SimCity or City:Skyline, in other words, we can set procedural modeling parameters in Unity and directly see how it influence the result geometry).
Since I'm quite new to these things like GIS, Unity, and Maya, I'm wondering if you know what is the correct workflow? And do you have recommended tools for doing these? Especially, where and in which step should I write the algorithms for procedural modeling? Because it seems that Unity is just a rending/gaming tool and can't build a complex model itself so maybe I must build up the geometry before importing it to Unity3D, but can I adjust just the model and get immediate feedback inside unity if I do so?
In my assumption, I guess I need to:
use GIS tools like Qgis to export roadmap data in shapefile format--usually points and lines
then find somewhere to transform it into spatial coordinates and do the math things to extract road features
do the procedural modeling things to get a "dynamic" model
finally, render it in Unity
If so, which tool/platform is good for each step?
Thanks a lot!
There are Unity extensions available that can generate roads. A couple examples I've looked into:
Easy Roads 3d
can import from Open Street Maps (OSM)
Assuming you need to use a source other than OSM, you could translate from your GIS data to OSM format and import that
I don't have a lot of experience with this tool myself, but there are some threads on the Unity community forums and the author seems to be very responsive.
Mapbox Unity SDK.
if you are required to use your GIS data you won't be able to use this
open source, so you can always look at the source to see how the transforms are done.
There are many hooks available and several tutorials that demonstrate how to hook into the pipeline and extract features from the incoming data and perform procedural generation of scene geometry (see the tutorials). The team behind it has been very helpful in answering questions.
I've done a bit of work with this tool, and the biggest downside (for me) is that it can only generate a map at runtime, i.e. not in the editor. This is due to licensing restrictions on the data.
Both of the options I mentioned do the transform from GIS coordinates to Unity-space in Unity. Unity runs fully-featured C# code and is capable of building complex geometry. Obviously that takes computational time, so you need to trade off that against performance. You should only need to build the geometry once, however (or at least only once after each edit/modification), not per-frame. In my use I've modeled buildings in SketchUp and imported those into Unity, then used the Mapbox utilities to map their locations to the correct spot (elevation and lat/long coordinates). You could do a similar thing with Maya models.
Some of what you need to do depends on:
you need to dynamically generate the roads every time you launch the program
you are better off building the code into Unity to translate from GIS to Unity scene coordinates and dynamically generate road geometry
you are doing a one-time import of road networks and then modifying that static network.
build a tool to convert from your GIS and generate road geometry as a one-time task
you'll still probably want to use Unity since in includes many utilities to work with vectors and generate geometry
I would like an example on how to draw a sphere, with texture on it (e.g. checkered), in modern XNA (as per MonoGame). Everything should happen programmatically (model and texture are generated, not loaded from files). Brief and tractable is a plus.
The end result would look like
except for the shadow and the fact that I don't care how exactly texture deforms towards the edges.
Indicating prior research: I've tried SpherePrimitive but could never put texture on it. If you can, consider it is already present. I have also tried this example from the web, it didn't compile agains MonoGame, when it did the end result did not look like a sphere.
A bit of context: I'm using XNA because it looks like the only cross-platform way to do 3D in C#, but I'm doing a simple visualization so I only ever need spheres so far.
It turns out that XNA/MonoGame is a particularly poor fit for that task. Contrary to my expectations it is not a 3D game builder, but 3D game engine builder. APIs provided are too low-level to tackle the described task in one go.
I have tried Unity 3D but it makes development Unity-centric, which is a nuisance given that I already have code base and tooling selected.
I am currently settling for using OpenTK for the job. It is still fairly low-level, but:
It is a no-frills solution. Create window when needed, dispose when done. It doesn't force a certain mindset, tooling or entry point, being a library.
It is basically OpenGL, for which there's a huge amount of code already written and available for review.
It's one small and stable dependency. Smaller number of layers of indirection.
I have already found a working textured sphere-drawing example
I'm writing a monster AI that has some aspects of group mentality for my game. My first question is what would be the best way to make a heatmap in unity for migration patterns and such. I can figure out lots of things on my own, but I would like some steering in the right direction.
Basically, I need a perlin-noise-esque map with hot/cold based on location and season that has fluctuations between different hot and cold zones over time. I don't know if there's a way to do this with just prelin noise, since all I've seen it do is random 2D maps. Any help would be appreciated.
Oh, and I prefer any code in c#, but it's not a necessity.
I have around several hundreds of moving objects within screen at the given time, plus a thousand+ stationary objects. For simplicity, you can think of it as a billiard game with damn lots of balls :) Some of them are stayin still, some others are moving at all sorts of speeds to all sorts of different directions. I need coll detection each time each ball bumps into another ball. What is the best method, considering performance and, well, programming simplicity? I'm talking algorithm only, I guess I can implement it myself, tho suggestions on implementation are welcome as well ;)
Language is C#, XNA 3.1, 2D graphics, target platform is Windows only (if that matters). Thanks in advance for your help!
You might want to take a look at the answers to this question.