What type of graphics is this ?

This is a discussion on What type of graphics is this ? within the Game Programming forums, part of the General Programming Boards category; I'm thinking of investing some time into making a 2D game.
(I'll use sfml and standard C++...and create the sprites ...

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

It's an isometric, more correctly an axonometric, projection. It's not exactly the same as a classic engineering/CAD isometric because of the way the pixels line up, but as close as damn it. It looks like a classic 2-across, 1-up isometry that almost every "isometric" game uses - for every pixel you go "up", you go two to the side so in order to draw a "straight" line that follows the grid of sprites.

To make it, you blit 2D sprites that have been drawn that way (i.e. lay down two lines that cross using the "2-across, 1-up" rule, those are your "axes" and then you have to make the sprites face the right way, look parallel to them, etcc.) onto a 2D background in the right order. No 3D involved but you may have to manually handle some depth (e.g. the top of the screen is drawn first so the bottom of the screen draws over it, etc.). You'll probably find that if you're doing a lot of drawing, you can accelerate the graphics with something like OpenGL but you still tend to keep it 2D and just use OpenGL as an accelerator, not a 3D-space creator. I'm in the middle of writing a game like that (very similar to Theme Hospital style, though that example is particularly pretty) and I just rewrote my SDL 2D blitter routines to use OpenGL to make it faster (about a 5-10x speed improvement I think, but not quite finished that yet).

The hardest part is probably obtaining the sprites (and especially animated sprites) in the correct projection. Not many spriters can do iso and make it look good. You basically have square images with a "diamond" shaped sprite / tile inside them. By using colour key transparency / alpha tricks you get those sprites and tiles to overlap and come out like your image. Inside the game, it's just a grid and a simple conversion formula or two to go back and forth between grid and screen coordinates and the drawing routines are pretty simple. Not much code, lot of work for the artist, though. It's also a bit of a faff when it comes to rotating the screen so you can see things from "the other side" (e.g. behind a house) - you can only really rotate between the four views and only then if you bothered to make the sprites all properly (i.e. facing each way) and you have to code it yourself.

If you're interested in actual code and the way sprites are used in a real game, go have a look at the Theme Hospital remake, corsix-th, based on an old DOS isometric game (so, no, you definitely don't need 3D!).

- Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
- A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
- The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

Can you post a link or explain what the 2.0 RC is, im kinda interesting.

As Phantomotap said, it's just the newest version of SFML, it's still in beta, but i would bet it has less bugs than SFML 1.6 does anyways, and it is much better to work with. You'll have to compile it yourself though, there is a thorough tutorial (as always) on their site, here: SFML - Simple and Fast Multimedia Library

There aren't any tutorials for actually using it yet, but you really don't need them, since the documentation is rather fantastic.
The only downside is that they moved to lower camelcase

In today's world it would be much simple to render in 3D and position the camera so that it appears isometric. Almost every tool out there is built for 3D not to mention every framework and API that wraps OpenGL or Direct3D. If you do this in 2D it will be extremely painful. It is no small task to build iso graphics that look good, fit together seamlessly, and hide the underlying 2D grid.

In today's world it would be much simple to render in 3D and position the camera so that it appears isometric. Almost every tool out there is built for 3D not to mention every framework and API that wraps OpenGL or Direct3D. If you do this in 2D it will be extremely painful. It is no small task to build iso graphics that look good, fit together seamlessly, and hide the underlying 2D grid.

Won't it be too daunting to try making my first game in 3D, without having a good idea about Computer Graphics theory ?
And things like animation, collision detection, etc will be very difficult to handle, especially if I'm to do everything from scratch.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !