Sign in to follow this  
unreason

2D versus 3D

Recommended Posts

I'd like to make an isometric game, and I'd like the levels to be reasonably detailed, in a way that pretty much mandates at least some 2D background stuff. Basically, I have a few ideas on how to balance 2D versus 3D. 1. All 2D. This allows a lot of nice 2D pictures, but makes lighting, and character animation a bit more difficult. 2. 2D, with some 3D for characters. This would let me use 3D models for the players, allowing easy rotation, interchangable parts, etc., while having a nice looking 2D background. 3. All 3D, with really nice textures. This allows easy 3D lighting, and because I'm planning on using a fixed isometric viewpoint, I can make my objects knowing what viewpoint they'll be seen from. Does anyone have any advice on this? Which of these methods should I use? Are there options and issues I'm missing? Thanks!

Share this post


Link to post
Share on other sites
Pure 3D is going to lose all the mystique, beauty and niche of pure 2D.

3D models on 2D might not look so good, I'm not sure. I can't think of any examples that use it.

Pure 2D is a little bit of work (more so on the artists than the programmers, I can only imagine) but ends up with the most "classic" look in my opinion.

Share this post


Link to post
Share on other sites
I would design my engine so that I could try all three and decide what I liked best. Try as much as possible to use either RAD disposable code or something that is quick but redeemable if you decide to implement further in that technique. After prototyping you may find other nuances and ideas that you not first considered.

Since you are locking your isometric view you may be able to cut some corners and get a 2d/3d architecture to work. If I was going to blend the two together, I would handle the terrain (just the land) in 3d - this allows you to build vistas and edit height pretty easily and would also allow some data points later on for path finding (ie - if slope > a certain amount then it cannot be crossed..). Terrain features such as trees and plants could be 3d and then billboarded in the distance/background. Meaning, the first few visible layers of your tree line could be a procedural tree and everything behind it billboards. Structures, troops, and all the other implements of war would be 2d with a fixed view angle for structures. Then you could look at having a number of "shadow" maps that could be blended on the sprite depending on where your light source was coming from - sort of a crude sprite lighting technique.


Again, however, I would try to design an engine that allows you to prototype these ideas very quickly and decide what YOU like. I can understand the nostalgia for a pure 2d game - but on the other hand Dungeon Siege looks completely stunning - and has no load times.


Hope that helps -

#dth-0

Share this post


Link to post
Share on other sites
Quote:
Does anyone have any advice on this? Which of these methods should I use? Are there options and issues I'm missing?


Just do whatever's easiest and will have the game done sooner.

Share this post


Link to post
Share on other sites
Quote:
Original post by unreason
2. 2D, with some 3D for characters. This would let me use 3D models for the players, allowing easy rotation, interchangable parts, etc., while having a nice looking 2D background.
Total Annihilation does this.

Share this post


Link to post
Share on other sites
I've been pondering an experimental fork of Golem to explore the 3D characters on 2D backgrounds idea. The possibilities for smoother animation, no limitations on the direction a character can face, combined with enormous memory savings are appealing to me. I would not want to trade in the 2D backgrounds for 3D (that is reserved for my side project, Golem3D), since 2D backgrounds currently offer far greater potential for richness and detail. Fully 3D models, even on newer hardware, still suffer from limitations. (Though, the pace of hardware development is rapidly changing that).

Each of the alternatives you suggest have their upsides and their downsides, and your choice will drastically affect not only the basic design of your game, but the overall "look-and-feel" as well.

Typically, a sprite-based character system will implement animations for 8, 16 or even 32 possible directions the sprite can face. In the old days, it was possible to mirror certain of the animations, to reduce memory consumption. However, with non-symmetric characters (barbarian with sword in one hand, shield in the other, or a guy with one robotic leg) the mirroring becomes obvious, as shields and swords suddenly "switch hands", and all of a sudden the robot-guy's right leg is robotic, when earlier it was his left leg.

So, you have, say, 8 facing directions. Now, you want to implement a full set of animation sequences for a detailed, complex character. You've got standing-idle, walking, running, attacking, casting a spell, dying, reacting to a hit, jumping, maybe even flying. You provide a small selection of alternates for selected animation sequences (options for different attack methods, for instance, to avoid obvious repetition when attacking an enemy repeatedly). All of a sudden, you realize that the animations for one character done in traditional 2D amount to >100 frames (a typical Golem combatant usually sits in the ball-park of <60 frames, but I'm a memory mizer sometimes). Now, multiply that by 8 (for 8 facing directions, remember? multiply by 16 or 32 if you decide to use more facing directions) and that amounts to >800 frames of animation for a single character. Now, how many different types of monsters did you want to include? At 128x64 (the most common dimensions for a single Golem character sprite) that amounts to 6553600 pixels of image data, uncompressed. Now, what format are your sprites stored? Even in a palettized 256 color encoded format, that is 6.25 MB of image data. Now, try that with 24-bit sprites (and maybe even an alpha channel, for transparency or translucency) and all of a sudden you've maxed out on-card memory and bled over into system memory.

Now that is a little exaggerated. You can always trim a frame here, snip a few frames there, and reduce the total frame count. But however you look at it, a fully-animated isometric character done in 2D is a significant investment in video memory.

Now, contrast that with the 3D version. You have a model stored as a single texture (if your 3D artist is skillful enough at texturing models) or a small handful of textures at worst. You have animation frames stored as 3D vertex data. Even looking at, say, 2000 vertices (a rather extreme example, since most isometric-game-style characters won't be viewed closely enough to warrant such geometric detail), where each vertex is represented by (x,y,z) (u,v) (normalx, normaly, normalz) (32 bytes per vertex, if all are floats) you are looking at perhaps 64,000 bytes per animation frame. Since rotations of the model are performed real-time, rather than pre-rendered, the concept of pre-set facing directions is a non-issue; just rotate the model. So instead of 800 frames, we only need 100. That means about 6MB of animation data in system memory, plus one or two textures in video memory. Weed out a few frames, and you can reduce even that much, and still maintain far smoother animation (using interpolation between frames) than you can for an equivalent number of frames done in traditional 2D pre-rendered style.

Go with a skeletally animated approach, and you can limit the memory usage even further, by maintaining only one copy of the character model, and storing frames for just the bones of the skeleton. At 100 frames, and say 15 bones per skeleton (a rather high estimation), where each bone is represented by a quaternion (4 floats) and a relative translation (3 floats) (28 bytes per bone), you end up with about 41k in animation data, 64k in vertex data, and a handful of textures tossed in on top. Not to mention the huge simplification in designing a component-based system to easily allow the player to customize his/her character--a task that is fairly complex, messy and difficult to accomplish in a standard 2D isometric.

There are downsides to using 3D of course, including possible limitations to character detail and a significantly greater amount of time required to draw the view, possibly affecting the time that can be spared for other tasks, and even increasing the minimum requirements of the player's machine.

Now, I apologize for getting so darned long-winded about this. My point is just to get you thinking in-depth about the various alternatives you have brought up. Each has their advantages and their drawbacks, and each will drastically affect the game you make. Thus, you need to think deeply on exactly what you want to accomplish with your game.

Best of luck.

(Note: All of the above numbers are approximations pulled off the top of my head, so please excuse any mathematical errors. ;) )

Share this post


Link to post
Share on other sites
The best approach is to have your game and/or engine support both. The terrain should be in 3D as flat terrain just doesn't cut it in the market these days. Then, the objects can be either billboard sprites or 3d models depending on the complexity of the animation as Golem wisely points out above.

I am currently working on a 3d isometric engine + game that does just that. It uses, believe it or not, managed DirectX in C# and yes it's plenty fast! :)

You might argue that using 3d makes it no-longer isometric. However, to me it's really the view-point that defines the engine as isometric since it changes the dynamics of the game and how the engine is architected.

-Mike

Share this post


Link to post
Share on other sites
Quote:
Original post by unreason
VertexNormal, how do games like Diablo manage the massive number of character sprites? They appear, at least, to have full rotation for the characters.


I believe that, for one thing, Diablo 2 uses palettized 256 color graphics. They change palettes for the different acts, and maintain certain ranges of colors for character graphics, IIRC... but they avoid the bloat of using full-color 24 or even 16 bit color images.

Also, there are apparent design limits on the size and number of assets needing to be loaded. Each level typically only makes use of a relatively small number of monster varieties (one or two, usually). Monster graphics are apparently reused with coloration effects applied to implement other monster varieties and boss/unique monsters.

As well, (and I am not 100% certain on this, not being a Blizzard programmer) they are probably using some sort of run-length encoding scheme to reduce the in-memory size of each animation frame. Sprites can be stored in memory as run-length encoded data, which eliminates the unneeded whitespace around a sprite, and which can be drawn using special routines that decompress the image on the fly and render it to the frame buffer. It is an approach that has been common in 2D games in the past, and can grant significant memory savings. Such an approach is simple to implement using straight 2D methods, but becomes just a little more complicated when you try to use 3D hardware to accelerate the rendering and/or provide lighting effects and such, since 3D likes to have image data either uncompressed into a texture, or at best compressed using texture compression extensions. Though it's not impossible, of course, to build a hybrid system to take advantage of the best of both worlds.

It is these limitations, I believe, that led Blizzard to state that they would probably never do another fully 2D game again (I believe it was in Diablo 2's post-mortem at gamasutra.com that they said it, though I could be wrong.) Sorta a shame, really, although their 3D offerings certainly do not disappoint.

strahan: You're pretty much right about the viewpoint defining an isometric. 2D or 3D has little to do with it. An isometric projection (as has been previously discussed at length in this forum ;) is simply a sub-class of orthogonal projection (ie, projection without the scaling due to perspective/distance) in which the main world coordinate axes when viewed appear to bisect a circle into 3 equal parts. Kind of a clunky way of putting it, but basically if you view a cube from an isometric perspective, looking at the nearest top corner, the visible edges of the cube will form lines that are exactly 120 degrees apart from each other. In real world terms, an isometric perspective is one in which the camera is located at 45 degrees around the vertical axis, and ~35 degrees (can't remember the exact degree value) above the horizon. So it is most certainly possible to make an isometric using 3D; in fact, one could argue that it is more plausible to do so in full 3D than it is in straight 2D, since 2D typically benefits from tile sizes and wall graphics that don't hold strictly to an isometric perspective. For example, Golem uses tile sizes with a 2:1 ratio, which isn't strictly speaking an isometric perspective. Merely a close-enough approximation thereof.

End nitpicking. :D

Share this post


Link to post
Share on other sites
128x64 is pretty big for a character sprite, if you're making a RTS at least. Sounds like an RPG type game, where the focus is more on the individual character(s).

For my RTS design I think 32 wide by 64 high would be fine. That comes out to what, 2 Kb x 24 bits = 6 Kb per frame. Assuming an arbitrary 128 frames of animation (like VertexNormal said, over 100) and a more detailed 16 facing possibilities, that comes out to 6 x 128 x 16 = 12 Mb per character.

I plan on using compositing to generate the final equipped unit, so adding weapons and armor is as simple as overlaying the appropriate set of sprites. The 12 Mb would be "per race type" basically, where there would be one base/stock unit that you would equip with different combo's.

Still, that's a ton, and makes me question my use of 24 bit color. Old systems would choke.

If you use a palletized system things look a little better. 2 Kb per frame. 2 x 128 x 16 = 4 Mb per character.

Pardon me for thinking as I write. Heh. That's still a lot, if you have 4 races. Not to mention ambient life (deer, rabbits, etc.) and/or monsters. I can't see how the big games do it anymore without storing all of that video info in system memory. Especially if you play the game on an old video card with say 8 Mb of memory.

But that's the cool thing, right? How hard is it to render 1 textured quad for the base sprite and a handful of overlayed quads for the equipment? We're talking maybe 10 triangles per character. Modern cards could render thousands of such units no problem. And even older cards could no doubt handle a lot.

My goal is to have 3D terrain with 2D units. But the 2D units are displayed, as mentioned above, using textured quads (2 triangles). The camera angle is fixed, but you can zoom in/out. This way I can have nice looking terrain with thousands of on-screen units, theoretically with no problem. Cossacks does it. I just wish Blizzard had made a version of War 2 that did it. Could you imagine War 2 with a unit limit of 1000 per team? That would have been awesome.

Anyway, I think I'm going to go the brute force approach for starters. 24 bit color. It'll be easier to get everything working that way, like the equipment overlays, etc. Then I'll try and optimize it later into a palletized system.

Just some thoughts. I think 3D terrain is the way to go, but I definitely prefer 2D sprite units over 3D modelled ones. It allows you to create games that will work acceptably well on older systems, and to have more than 100 units on a team.

:)

Take care.

Share this post


Link to post
Share on other sites
Thanks everyone for the advice! All 3 ways have their strong points, but I think I will definitely use 2D backgrounds, and I'll probably use 3D characters in the foreground. Thanks for all the advice!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this