Thread: What type of graphics is this ?

I'm not at all sure that a full OpenGL tutorial is necessary, but that's not to say it would hurt.

3D modellers are just as hard to find as 2D spriters, to be honest, (I've hired games artists in the past) but yet loading and handling 3D objects created in random formats is more difficult than someone sending you an RGBA PNG and editing as required to make it fit. I've made sprites for my game in Blender, for instance, by importing 3D models onto an isometric perspective and exporting them as PNG. It's not at all difficult compared to loading and rendering massive amounts of OpenGL TRIANGLE_STRIPS, taking account of CCW-windings, backfaces, loading from a 3D file format (*is* there a standardised one for 3D models?), applying texturing, modifying camera positions and lighting etc. and in fact some of those stages have exactly the same problems as you'd face in trying to create 2D isometric tiles but much more so. Hell, getting a model and texture from an artist and getting it to the point you can slap it into the game at the right scale is a heck of a lot of work compared to giving them an RGBA PNG template and then loading the result when you get it back (one call to a "load_png" routine and one call to draw it at the right point which is a two-line formula).

The difference is, I can knock up an RGBA PNG on a template background and stick it in the program. I can get iso graphics from the Internet and just throw them in with a simple resize or crop. It won't look great but it will work and I can literally sit in MSPaint or equivalent and touch them up to make them perfect. But knocking up "any old 3D model" for that kind of use is something I consider beyond my skill (I can JUST about knock up an isometric 2D PNG from a 3D model in Blender format if I follow a tutorial I found online and don't touch any option in that program except the ones I need).

There's also the performance issues to consider - do you want to be optimising your 3D model loading routines, camera rotations, etc. when you're new to programming in OpenGL and just want to see something on the screen? And, using OpenGL, rendering 2D is easier than rendering a 3D model using the same commands (hell, the windings, triangle strips, vertex arrays etc. necessary to render one 3D model can get horrendous, combined with external file formats). "True" 3D has a lot of advantages but most of them are quite minor and most people are willing to sacrifice them - e.g. you can view from ANY angle including 0.1 degrees off center so you can rotate "smoothly". But most games of that genre don't let you rotate because they've assumed it will be from a fixed angle. Once you have that kind of 3D "anything, any angle, any where" setup, the isometric viewpoint loses its appeals because of things going behind other objects (e.g. in Bastion, it's 3D accelerated but it's basically 2D projection and they have to "fade" the graphics that you have walked behind - but there are reasons the programmers took that trade-off instead of having a full-3D environment). Literally, by that point, turning your game into an FPS or a side-scroller or an iso or anything else is just tweaking the camera in 3D. That might sounds good but it also shows the complexity of what you're doing programmatically and just how much data you have to create just to throw it away because it's on a creatures backside and will never be visible.

If you do go OpenGL, I can thoroughly recommend the OpenGL Superbible, but the 5th edition focuses only on shader-style drawing which I find obtuse and unnecessary for a simple game. If you can get a copy of the 4th edition, that's almost the perfect introduction to "direct rendering", "vertex arrays" and the newer "shader model" styles of drawing in OpenGL. But, personally, I'd experiment with a 2D game first, get up to speed and if you find it's too tricky the move to 3D is required anyway. And if the game hits performance problems, you can shift to 3D acceleration and ease yourself in. My philosophy is: the game is not the graphics, it's still a learning experience, and I can knock up the graphics in MSPaint if necessary but I can't do 3D modelling myself and wouldn't like to try.

Originally Posted by manasij7479

As it is a hobby project almost solely for getting my feet wet, "requirements, timeline" are almost non existent.
And the goals are yet ot be defined, other than some vague ideas jotted down.

But I have the overhead of learning and experimenting with the API (s) I'm going to use and all the theory and algorithms.
(I understand coordinate systems and projections a bit but have absolutely no idea yet about lighting, texturing, and other nice stuff)
Also, whether it is OpenGL and everything else handcrafted or using complicated behemoths like Ogre3D and Bullet, I still have to learn much.

Have you done a complete game yet? Like a Pong or Snake clone or something like that?
There's many aspects to game programming that doesn't involve how many dimensions you're using: How are you gonna manage your resources? How are you gonna separate rendering and physics/updates? How are you gonna store/load settings for your game? Are you gonna use a deep inheritance hierarchy or object aggregation to define entity behaviour, or something else? Do you want to hardcode the behaviour of each kind of enemy or object, or do you plan to utilize a scripting language for this?

What i did, and am still doing, is to build a completely over-engineered 2D game to familiarize myself with these problems. To me, this project looks to be _huge_ for a first project, and that's usually a recipe for not completing it.

Originally Posted by Neo1

Have you done a complete game yet? Like a Pong or Snake clone or something like that?

I made a command line snake like that in the *ancient* nokia phones an year ago.. but that doesn't really count.

There's many aspects to game programming that doesn't involve how many dimensions you're using: How are you gonna manage your resources? How are you gonna separate rendering and physics/updates? How are you gonna store/load settings for your game? Are you gonna use a deep inheritance hierarchy or object aggregation to define entity behaviour, or something else? Do you want to hardcode the behaviour of each kind of enemy or object, or do you plan to utilize a scripting language for this?

1. I'll write a resource manager myself. (Which'll keep track of 3D models (perhaps loaded with assimp), shaders, unicode strings, textures, scripts(later), ..and any arbitrary kind of stuff). I can write this separately from the game and test it, so it won't be much of a headache.
2.What do you mean? Can't I just make the changes to the world with the physics library or my code, set collission flags and other things if needed, and then render the updated world ?
3. No idea yet, but I think I shoud be able to figure out something, depending on the other components of the game.
4. Not sure.
5. Hardcode for now, (and perhaps control some aspects with a config file), scripts later, when everything else is done.

What i did, and am still doing, is to build a completely over-engineered 2D game to familiarize myself with these problems. To me, this project looks to be _huge_ for a first project, and that's usually a recipe for not completing it.

That was my original plan for this project (which was sort of debunked here )... but if 3D isn't going to an order of magnitude more difficult, I'll rather learn by making a small 3D game.

Originally Posted by manasij7479

That was my original plan for this project (which was sort of debunked here )... but if 3D isn't going to an order of magnitude more difficult, I'll rather learn by making a small 3D game.

Well, my non-expert opinion is that usually the graphics are a trivial matter compared to:
1. Figuring out a good and elegant design.
2. Actually finishing.

With your particular project, the above 2 tasks seems like a tall order for a first project, 3D or not.

Now that I take a closer look at the screen I can start to see that it looks somewhat like a cheesy Flash game that borrowed assets. The trees look plopped in there and their palettes don't exactly match the rest of the scene. The characters can be forgiven b/c maybe they were going for that cartoony look..although they do look like they are out of plane with the rest of the scene. It is possible this is a massive bitmap that was pieced together and the data beneath it simply defines the walkable areas.

There's also the performance issues to consider - do you want to be optimising your 3D model loading routines, camera rotations, etc. when you're new to programming in OpenGL and just want to see something on the screen? And, using OpenGL, rendering 2D is easier than rendering a 3D model

With modern cards you can pretty much brute force a large world of 3D objects without optimizing anything and the card will take it and ask for more. 2D rendering on the other hand generally requires more vertex buffer fiddling due to the nature of the beast and if done incorrectly this can and will bring even the best cards to their knees. Pipeline stalls are much easier to come by in 2D than 3D where you are literally just throwing meshes with textures at the card. Besides look at the scene. This isn't Crysis 2 we are talking about here. I do not see anything all that complicated from a 3D standpoint. And besides 3D is not much harder than 2D. As has been said in the end it comes down to the projection matrix. If it's orthogonal it's 2D and no Z, if it's persepective it's 3D. The rest of the math is the same. 2D is a bit harder b/c usually you ditch the z-buffer and must resort to layered rendering which isn't all that hard but it is an extra step. Animations are a moot point since both Soma and I have recommended using 2D sprites for that which means an animation system must be designed and developed either way. I do not understand the problem with winding order since you usually set this one or two times per scene and you are done. Pick a winding, set your API to the winding and draw. Not hard at all. You should not be creating triangles for meshes anywhere in your code if you are using a pre-built mesh approach so you would not have to concern yourself with the winding order. For particles set the order and draw.

As to the comments about the camera for an iso game your camera should only move on x and z if +y is up or down. X in an iso game does not follow the right vector and Z does not follow the look vector. You must keep the camera vectors as they are but use another set of vectors to move the camera. Normally you can move the camera along its vectors but in this case that will not produce the correct movement. You need a set of vectors that are rotated about 45 degrees around the Y axis. Since this never changes and the camera doesn't rotate in traditional iso games you can copy the world up, right, and look vectors into camera move vectors, rotate them and use them for the duration of the game. I have iso camera code that I can give you. It uses the D3DX math library but the same mathematical concepts apply in OpenGL. For OpenGL you transpose the matrices since it uses a right handed coordinate system.