Isometric Design ala Diablo II

#1 I can't speak directly to doing an isometric game but I can say that the engine seems to setup to handle such a game just fine. You can build multilayer tile maps and set the collison convex poly on a tile by tile basis. You can even select the rendering order of a layer (ie if you want the tiles to render from top to bottom +Y or bottom to top -Y, etc).

I suggest looking at the 5 tutorials they just put out, those things really sold me on this engine and how easy to use the editor is.

Some arguements for 2D versus 3D that you may not have heard before:

- High Poly Model Export: Video cards are much faster at rendering these days but you still can't use 300K+ poly objects (characters, buildings, enimies, etc) viably in a game engine. Rasterzing them to sprite however allows you to use whatever you want as source art. So if you want to use that awesome 100K+ poly tank model you pull from turbo squid, you can.

- Art Licenseing: This is a huge issue especially for indie's. I will never understand why Poser and similar products (that use morphing to build variations to a character model) won't let you use the models that you produce in that software in your game but you can't. You can however use the images from said models, which means they can make great source art for 2D games. This opens up a far larger world to the art inhibited indie developer.

-Complexty: 3D is hard. Harder everywhere from a code perspective. It's sometimes difficult to move out of the rut of thinking that using a 3D model means I don't have to worry about 0,15,30,45, 60, 75 and 90 deg poses. Ask anyone who's used TGE or TGEA how easy it is to get a rigged, animated, character model into the engine for use as a player. To get 3D art into the engine you need a model, a texture or set of textures, bump maps possibly as well, possibly a shader for the model (if you want special rendering) and an animation file or set of files. Some of these can be reused from model to model but the reuse incurs a setup cost (you need to configure your game somewhere to use the files), and in all honesty you don't reuse nearly as much as you think you might. The ease of simply rendering to a sprite and just using that is often largely understated. And we aren't even touching on the enormous amount of visual issues that crop up in the 3d environment (zbuffer, culling, render order, differing shader versions, etc), the increased physics/collision complexity (its really no where near as simple as adding a dimension and therefore an extra Z variable to our equations) or the extra User Interface concerns that extra dimension adds. 3D is hard, not impossible, but harder than it might seem at first.

If you really haven't worked on a 3D title before then I would suggest the 2D path. You will lose some visual quality and some features. But you invariably will come to a point in your project that you have to trim scope anyway (this happens to even the big budget compainies). You will also lose the experience of learning the ins and outs of 3D (even if you have done 3D before there is always learning to be had). Which I would admit is the biggest disadvantage to going 2D. However with Torque X learning in 2D may actually be a viable path and make the Torque X 3D learning experience a lot easier. Since supposedly the framework will be similar.

Food for thought. You got a long reply because I have been thinking a lot lately about this very same subject. :)

Ves

#2 Great post Ves!

@David
There are currently no tutorials for isometric implementations with TorqueX. While I'm not sure, I believe you would have to create your own tiling system with XNA. While the engine supports multiple layers of tiled objects, the tiling is not setup specifically for isometric design. I am also not sure how much tinkering it would take to set it up for it. Did you have an iso implementation running with MDX?

#3 You should take a look at Dan Pascal's video tutorials. He steps through the process of creating an isometric game using Torque X Builder. He takes a very clever approach of using tiles, animated sprites, and sort points, then rotating the camera to get the isometric look. I think this would definitely be worth watching for you.

John K.

#4 That's great, John! I missed that along the line!

#5 @Ves
Thanks for the info! I read this on gamedev.net:

http://www.gamedev.net/community/forums/topic.asp?topic_id=47159

I have been learning Maya, so far its seems pretty decent, although ill admit when I first started, it was very daunting, but the tutorials have helped me a lot. I was originally leaning towards 2d, and after some research, it would seem that Diablo II used 3d models, converted to 2d (sounds like the rasterizing you mentioned above, not sure though, I am a graphics newbie :( ) The link above has me concluding that 3d is the way to go, and use a perspective camera, though as you point out, the complexity definitely rises versus a 2d approach.

Since I have been designing my game engine logic independent of the rendering mechanism, I will try your suggestion, and test some of my game engine logic in the torque 2d game engine, and see how it pans out. At the very least, I will understand the pipelines a little better, and see how it all works. The first goal will be to see if I can get some basic rendering of a small scene, with an avatar. I appreciate your input ves, it has given me some insight into which way I need to go.

@Blake
I only got so far as wrapping up the basic aspects such as input, sound, rendering, etc (like I have an Input class that wraps DirectInput). The goal was to isolate the actual mechanics for those peices into my own wrappers, so the game could make the calls to the wrappers and not worry about the underlying implementation. The benefit being if I were to switch to say dx10 and the implementations changed, the core engine itself would not need to change, just the implementations. In the Input example, my engine would talk to Input, not DirectInput. I am not sure if that is the best approach, but it makes sense to me (aka isolate what changes or may change)

I was able to get some tiles rendered, a basic FPS counter based on Queryperfcounter, and some basic text going. I was working on implementing and adjusting a camera, then XNA came out, and I began researching that. More recently, someone pointed me towards TorqueX recently, hence my post here :) MDX is a beast, but I can see it being able to easily handle a perspective based engine that gives the appearance of an isometric game. However, since it appears Torquex is using XNA, I am leaning towards it now, and with Ves's input, will try to implement my basic engine in that and hopefully torquex 3d when it comes out.

#6 Thanks John! Downloading now :)

#7 @David Everhart
Have you looked at the Adventure Kit for TGB? It sounds to me like exactly what you want, if you go the TGB route.

#8 @James
yah, I checked out the adventure kit, but it looks like it is for regular torque, and not torque x. As I am mainly a C# developer I am somewhat biased in that regard :P . Nonetheless, it does look impressive, and if torque x 3d doesnt come out soon, I may just go that route. It looks heavy on the sprites though. I am considering using 3d models, with mount points for weapons, armors, etc (as far as I understand it to work that way anyways) and 3d terrain for height . I am taking ves input about 3D into consideration, and may outsource the 3d modeling and concetrate more on the interaction. So much to research, so little time.

#9 Sounds like a good plan! Best of luck to you.