The terms 2D and 3D (as you probably already know) refer to the number of spatial dimensions in a Euclidean world-space. This dimensionality must be an ordinal number; there is no such thing as a half dimension, so the term 2.5D is really a nonsense term, and has no intrinsic meaning. That said, 2.5 is "somewhere between" 2 and 3, so 2.5D generally means ...
I'm actually one of the Don't Starve devs (Kevin on our forums). I don't usually handle the rendering stuff, but I can tell you that the game is in 3D. The ground is just a regular 2D tile map with special transition pieces to make corners look better. There's no special Deathspank-style rounding going on, although we have talked about doing that in the past....
The first game I'm aware of that had the term "2.5D" applied to it was Doom (although Wolfenstein 3D qualifies in some sense too).
Wolfenstein 3D was a basically 2D game with a 3D presentation. You navigated a 2D maze, all the floors were flat, all the ceilings were at the same height, there were no windows, doors were floor-to-ceiling and opened sideways, ...
Assets like these can be created in any 3D package.
They are imported into a game by pre-rendering the models at specified angles, using orthographic projection in the viewport. The pixel effect probably is a side-effect of rendering at a low resolution with little or no anti-aliasing. The spritesheets generated by these will be ordered in such a way that ...
You will have to separate your code into separate projects (in the same solution). Usually you would have the following setup:
-Engine Core (DLL)
-Game + Game Logic (EXE)
-Content Pipeline (DLL)
For even larger projects you might want to separate the Engine Core over multiple projects like Core, Physics, Graphics, Audio, ...
Going to try and doodle up what I mean here as soon as I finish typing this, but:
What about merging the two?
Use the second (occlude by base) for everything that isn't a wall and the first (occlude by tops) for lighting the walls?
You actually did this by accident in your second example, with the wall that goes off the bottom of the image. Extending ...
2.5D ("two-and-a-half-dimensional"), ¾ perspective, and pseudo-3D ar terms, mainly in the video game industry, used to describe either 2D graphical projections and similar techniques used to cause a series of images (or scenes) to simulate the appearance of being three-dimensional (3D) when in fact they are not, or gameplay in an otherwise three-...
A platformer like this is still, in its essence a 2D platformer. The 2.5D effect, even the curling around the mountain, is merely a visualisation of a world constrained in 2D. Your physics engine will probably only operate on this world and not on the visualisation of it, so a 2D physics engine will be sufficient.
That said, you might be interested in some ...
2D isometric is just a 3D orthographic projection, with a little camera work you could use almost any 3D engine really. The screenshots that I find of Bastion look like they are 3D rendered, but built simply and angular like it was built on a 2D grid.
Note that similar games like Diablo3 or Wakfu that look like they are 2D are really built and rendered in ...
Well, start programming!
You can google for some basic tutorials to get you started, but if you don't know with what game to start, this answer is a great starting point: What are good games to "earn your wings" with?
As for books, I would suggest you start from something like XNA 4.0 Game Development by Example: Beginner's Guide and then move to Building ...
2.5D is just a convienient way of saying 2D that looks 3D.
I supose you could really blur the lines of the definition if, for example, you use a 3D engine but restrict gameplay to a 2D plane only, but personally I'd consider something 2.5D is it looks 3D but acts 2D.
Swapping textures will kill your performance. Modern hardware has only gotten more susceptible to this problem, not less, as the speed and power of the shader units and video RAM are growing much faster than the speed increases of the bus between system RAM and the GPU.
The only sane approach is to cut down your texture sizes, or generate procedural ...
This is a long answer, but actually the basic premise of divide-by-camera-z is very simple: The further something is away from you, the smaller it appears. Also, the smaller distances between two things appear.
Positions (Not required reading if you're using Unity!)
Firstly, you need to render positions / points that using correct perspective.
You need to use the range instead of the distance when you cast the ray. The range is the length of the projection of the ray onto the camera plane.
See this source.
Though IMHO some amount of fisheye distortion is kind of cool to keep around.
Separate out rendering logic as best as you could from actual game logic when designing your game engine. One way of doing this is to use Component pattern when building your game engine. For example, XNA uses this pattern at the framework level for flexibility. Use the same code-base for rendering with your level editor; write wrappers if you have to.
It could be any 2D engine, but you need to design your tiles somewhat diferent.
Also remember that you need to draw your tilemap from top-left to bottom-right to paint the nearest tiles in the last time, so nearest tiles are always painted over the other tiles.
You can refine your algorithm by making semitransparent or not drawing tiles when these tiles ...
A Wolfenstein-style raycaster is really simple. You basically shoot beams horizontally in an arc from one side of the player view to the other edge. When a beam encounters a wall, you get the wall slices height on screen from the distance (e.g. scale_factor / distance). E.g. for this height calculation you don't need to understand anything about matrices etc,...
Best tutorial on raycasting i could find when i was researching the topic a couple years back. It's pure theory, no programming. Other than that i suggest you read about the Doom engine and the Build engine. Reading the source code is IMHO far too time consuming (it's pure C and ASM, plus plenty of ...
Here's a very detailed tutorial: Creating pseudo 3D games with HTML 5 canvas and raycasting. The key search term is "pseudo 3d game."
Also I posted the text of the tutorials scgrn mentioned. (I think I read these a long time ago. I remember the ASCII diagrams!)
This is actually a quite simple thing to do.
Use your "heightmap" as a texture input to the shader of your sprite.
Then simply add the heightmap height to the fragment depth inside the shader.
Here's a little example fragment shader:
uniform sampler2D heightmap;
gl_FragDepth = gl_FragCoord.z + texture2D(heightmap, ...
I can't say for sure how that one game did it, but from the video it looks like it's just a regular 3D game world that uses billboarded sprites for game objects. Similar games include some of the Paper Mario games and the Death Spank series.
Render your terrain as 3D with a perspective camera. Maybe apply some simple vertex shader to get a little extra "...
Keep list of compatible components in each system. This way you don't have to iterate over every entity. Your entity manager can take each new entity, and dispatch its components to the correct systems.
IMO tiles shouldn't be entities. It's just too memory expensive. Also, as you noticed, tilemap needs special treatment in rendering (also physics), where you ...
You can still make the skeletons 3D, in game. Animate them once in 3D or generate their animations procedurally. Now, when you're rendering in game, use that 3D skeletal information to apply z levels to the 2D sprites that make up the body parts of your characters.
Now, when the 3D bone moves, use the 2D screen translation (of the current ...
In order for the correct parts of the sprite to be obscured by walls and other sprites, you need to create a plane in the rendering space upon which you can blit the sprite.
The plane itself should be the size of the interactable you want to draw, and its normal should be facing the camera, essentially a moving wall perpendicular to the view angle.
There are a couple of (very) old tutorials on Wolfenstein-style raycasting written by Peroxide. Search for "pxdtut7.zip" and "pxdtut8.zip". The code is written in Pascal but the concepts are explained very well.
I would firmly vote for Unity3D. The environment is great, it is fast, it can deploy to all of those platforms (plus iOS I believe).
In terms of 2.5D, you'll just want to fix the camera along an axis.
No. You can choose whichever coordinate system you want. The only thing to maybe consider is what coordinate systems your tools and models are in; converting is no biggie but there's only headaches to be found in being too different.
There's a lot of opinion about coordinate. I've been witness to some rather heated debates about whether it makes "more ...
Isometric games are indead games viewed from above, in such a way that the x, y and z axis are exactly 120 degrees from eachother. So an isometric game is a game viewed in an isometric projection: http://en.wikipedia.org/wiki/Isometric_projection (this source is very reliable :P).
So as you have already guessed, it is about the way the game is drawn.
The game screen shot you posted is a 3D game.
In a 3D game, the objects are drawn using vertices to draw actual 3D objects, which are then colored, textured, so forth.
In a 2D game, the objects are taken from sprites / sprite sheets, etc.
The difference between the two is how you can view them. A sprite is like a flat piece of paper. You can not view it ...