🔒 Locked

16 direction character in a 2D isometric game?

Started by desdemian Feb 20, 2005 at 10:36 PM 18 replies 24.8k views

Original Post

Feb 20, 2005 at 10:36 PM

hi, i was wondering about games like diablo but controlled by keyboard instead of the mouse, and came up with the following problem... if im going to make a 2D isometric game i have to store every frame of every possible animation the character is able to perform? if the game is a 16 direction them im guessing that would just be too much memory to store a single chracter... i dont know if my math is correct but lets say my main character fits in a 70x50 sprite, if i save it in a .bmp format thats 10k per frame. lets say that an average animation has 10 frames, and that an average character has 10 animations thats 1 Mb... and if you multiply this by 16 directions... then my character is a bit larger than i spected... of course i can use anoter format and even zip it, but still i think it would compress to 1/3 which is still a lot if a want to have many different characters... so, what im asking, is there another way to have a 16 direction isometric character (not having every single frame in memory), maybe having each extremity and compose every frame...although im not quite sure how (and if) that would work? or should i just wait 300 hundred years when i finally learn 3D stuff and go that way? thanks, byeee

MikHaven

Feb 20, 2005 at 10:41 PM

Quote:
Original post by desdemian
i dont know if my math is correct but lets say my main character fits in a 70x50 sprite, if i save it in a .bmp format thats 10k per frame. lets say that an average animation has 10 frames, and that an average character has 10 animations thats 1 Mb... and if you multiply this by 16 directions... then my character is a bit larger than i spected...
thanks, byeee

Technically that comes to about what 16megs for the main sprite. I'd say go for it, you can always find ways to improve it laters.

Your video card has theoretically 16 meg to 256 to ++++ in the future.

Besides you really are just creating a few textures from the files and using those, and then the game could switch those out, because they don't all have to be in memory. MY philosophy is let the card and the api handle all the complicated stuff, build your game, and fix it later.

MikHaven

darookie

Feb 20, 2005 at 11:03 PM

I'd suggest using some compression (e.g. jpg) and store the sprites in system memory. Upload to texture as required (e.g. your texture will only change every few frames -> performance hit is not that big).

I implemented a similar system some time ago and it worked out very well - up to 32 directions, compressed frames and real-time decompression/uploading to video memory. On my development hardware (was a 400MHz Celeron w/ GeForce1) I could decompress and upload up to 10 characters simultaneously without significant loss of performance.

If you don't do 2D in 3D and use some 2D lib like SDL you don't have to worry about that, though plus as MikHaven already pointed out - finish the game first, optimise later (if required).

Best of luck!
Pat.

[Edited by - darookie on February 20, 2005 11:03:26 PM]

Evil Bachus

Feb 21, 2005 at 1:54 AM

Quote:
Original post by desdemian
if im going to make a 2D isometric game i have to store every frame of every possible animation the character is able to perform? if the game is a 16 direction them im guessing that would just be too much memory to store a single chracter...

i dont know if my math is correct but lets say my main character fits in a 70x50 sprite, if i save it in a .bmp format thats 10k per frame. lets say that an average animation has 10 frames, and that an average character has 10 animations thats 1 Mb... and if you multiply this by 16 directions... then my character is a bit larger than i spected...

of course i can use anoter format and even zip it, but still i think it would compress to 1/3 which is still a lot if a want to have many different characters...

Before taking a programmatic approach you see what other ways you can get the memory requirement down. First, 70x50 is enormous for an isometric sprite. I don't know the exact size of the Diablo II sprites, but I'd reckon that they were around 48x24, and you might even be able to go smaller. Second, you can duplicate direction frames by just flipping the sprite around, so your frames of the character looking left are the same as the ones looking right. That's dropping the number of frames nearly by half right there. Also, you may not need ten frames of animation for every action. You may be able to get by with less. And of course, you can always use 8-bit sprites instead of 16/24/32-bit. 256 colors doesn't seem like a lot, but it's usually plenty. The sprites in every 2D Street Fighter game only use 16 colors and they're gorgeous.

So, we'll say an 8-bit sprite with 9 views (7 duplicated plus up and down), 48x24, with 10 animations with an average of 8 frames an animation. That's 6635520 bits, or 810KB of data. See? Not so bad.

darookie

Feb 21, 2005 at 2:04 AM

Evil Bachus: The only problem with your approach is that it's very restrictive, e.g. imagine you have a half-transparent shadow attached to your sprites -> flipping won't work. And 70 x 50 isn't huge at all, Diabolo II had what resolution? 640x480? 800x600[wink]? I want sprites that look good at 1024x768 and above, so 70x50 is actually quite reasonable[smile]. I totally agree on the bit-depth issue! That is a very good advise indeed, thumbs up for that.

Best regards,
Pat

Evil Bachus

Feb 21, 2005 at 3:30 AM

Quote:
Original post by darookie
Evil Bachus: The only problem with your approach is that it's very restrictive, e.g. imagine you have a half-transparent shadow attached to your sprites -> flipping won't work. And 70 x 50 isn't huge at all, Diabolo II had what resolution? 640x480? 800x600[wink]? I want sprites that look good at 1024x768 and above, so 70x50 is actually quite reasonable[smile]. I totally agree on the bit-depth issue! That is a very good advise indeed, thumbs up for that.

Best regards,
Pat

Aye, it is pretty restrictive. It's mostly just something to think about. It's always good to sit down before the project gets too far underway and do some art mockups and some calculations on paper to discover what your art requirements are. What you need, what you can get away with, etc. If I had a dollar for every time I had to rewrite graphics drawing routines because the art requirements changed I'd be a rich man. :-)

Luckless

Feb 21, 2005 at 9:08 AM

another big thing about flipping sprites is your guy holds his weapon in his right hand, and sheild in left,... and looks rather foolish when it switches hands when he faces the other way.

nife

Feb 21, 2005 at 9:27 AM

You could always use DDS files without mipmapping if your game doesn't allow you to zoom in and out.
It would require the user to have a GeForce 256 or Radeon 7000 card, as far as I recall, but it would be well worth it.

evelyn

Feb 23, 2005 at 5:13 AM

AP - why would only 8 directions be ok?..excuse my ignorance (I'm not being funny here as I'm trying to understand isometric viewpoints) but I thought the more directions you use, the less 'clunky' the movement would look..am I wrong?

EDI

Feb 23, 2005 at 7:54 AM

8 directions is ususaly considred to be the 'minimum' for isometric games, however 4 directions is also okay if your game only allows orthagonal movement.

8 directions is ususaly fine, unless you are trying to create somthing that looks 'really' smooth, and ususaly unless you are planning to have lots of similar animation in the game (that would benefit from a more gradiant rotation), using 16 directions is probably pointless.

Luckless

Feb 23, 2005 at 10:50 AM

16 does look better, but at a cost of coruse. You could 'cheat' and still use the 8 visual dircetions, and give it 16 movements, but that might look bad.

Meagermanx

Feb 23, 2005 at 10:58 AM

How is this game going to be released? Download or CD-ROM? 'Cause if you are going to be distributing it in CD-ROM format, you are going to be able to get away with much larger files than if you are offering it as a download. Just a thought.

Kramy

Feb 23, 2005 at 12:35 PM

Here's a thought - design for the future and the past. Have your sprites get scaled in memory when loaded, at the start of the game, depending on the screen depth and resolution. That way you can save 120x80 sprites on your CD or w/e, for 1600x1200, but at 640x480 the sprites are only 48x32. Less pixels requires less detail, and if the monitor's depth is only 16 bit, then why use up all that extra memory? [grin]

16(Dirs)*10(Animations)*10(Frames per Anim) = 1600

120*80 = 9600px (1600x1200)
96*64 = 6144px (1280x960)
76.8(80)*51.2(56) = 4480px (1024x768)
60*40 = 2400px (800x600)
48*32 = 1536px (640x480)

32bit = Bytes(4*Pixels)
16bit = Bytes(2*Pixels)
8bit = Bytes(1*Pixels) + Pallette?

Result:
32bit, 1600x1200 = 61440000 (60000kb) (58.59375mb) (ouch :P )

16bit 1280x960 = 19660800 (19200kb) (18.75mb) (reasonable)
16Bit, 640x480 = 4915200 (4800kb) (4.6875mb) (low end fine [smile] )

8Bit, 1280x960 = 9830400+163840 (9600kb, 9760kb) (9.375mb, 9.53125mb) (low end fine [smile])
8Bit, 640x480 = 2457600+163840 (2400kb, 2560kb) (2.34375mb, 2.5mb) (low end fine [smile])

*Note - I assumed the 8bit sprite had a 1024b overhead for the pallette per animation, giving a (163840b, 160kb overhead per sprite)

Roots

Feb 25, 2005 at 7:21 AM

Quote:
Original post by Talroth
16 does look better, but at a cost of coruse. You could 'cheat' and still use the 8 visual dircetions, and give it 16 movements, but that might look bad.

Anyone remember Final Fantasy VI? Sometimes sprites would move "diagonally" but would only be facing one direction. I don't think it looked bad at all, and in fact I've implemented the same thing in my game and I think it looks pretty good. It gives the player more degrees of freedom, yet doesn't tax the sprite artist anymore. Of course that's 4->8, I don't know what 8->16 would look like. But once you are planning on going up to 16 directions, you might as well just make the game 3D in that case.

Luckless

Feb 25, 2005 at 4:28 PM

Quote:
Original post by Roots
Quote:
Original post by Talroth
16 does look better, but at a cost of coruse. You could 'cheat' and still use the 8 visual dircetions, and give it 16 movements, but that might look bad.

Anyone remember Final Fantasy VI? Sometimes sprites would move "diagonally" but would only be facing one direction. I don't think it looked bad at all, and in fact I've implemented the same thing in my game and I think it looks pretty good. It gives the player more degrees of freedom, yet doesn't tax the sprite artist anymore. Of course that's 4->8, I don't know what 8->16 would look like. But once you are planning on going up to 16 directions, you might as well just make the game 3D in that case.

Well, sprites LOOK better, but are harder to do the so called 'cool' effects at times. So, doing a free movement envorment, *meaning you can mose any x:y relation you want, not restircted to 4,8, or 16 directions* is still a good idea if you don't actually need the 3d features. As, 3d models don't look as good as well made sprites.

desdemian

Feb 28, 2005 at 6:20 PM

hey there, some replies...

Evil Bachus:
I was planning a 800x600 resolution, and having a character who's height is 1/10 of the screen seems ok to me, i've considered making it smaller but i think it might hide a lot of details in the characters.
Also, flipping sprites (like Talroth said) would make my character change if its not simetric, althoug for simetric characters this is a very good approach, thanks.

Meagermanx:
Since this is a hobbie project i was thinking about distributing it on the web, and thus my concerning about having a 16 mb main character.

To everyone who was talking about the number of directions:
I want this to be a keyboard controlled game, and the player will 'aim' by holding one key, using the left and right arrows, and releasing the key. As you can see if i use 4 or 8 directions it will make it very rigid when it comes to fireing (using the 'Final Fantasy VI mode', posted by Roots, wouldn't help either). Actually first i wanted to make it a 32 direction game... but then i came across the problem i posted here.

Thanks everyone for the replies!!

markr

Mar 4, 2005 at 3:41 AM

Yes, you're going to need to use a lot of sprites for a character which can be facing even in 8 directions.

Some actions can share animation frames with other actions however. Also some actions may only require 1-2 unique frame, this will reduce it a lot.

I created a game for a compo last weekend. This used isometric graphics with the character facing 8 directions. I had four walking frames plus one attacking frame, however that is already 40 frames of animation just for one character.

You can't generally get away with flipping the left-facing sprites for the right-facing ones unless they are really low quality, or the object happens to be perfectly symmetrical.

DOOM did this (Yes, I know Doom used perspective) - they had 8 directions for their characters, but only 5 directions of animation - they would just flip 2,3,4 to get 6,7,8.

But it looks really bad, because as your character turns around, they instantly switch from being left-handed to right-handed (and then back again). Also the lighting won't be right.

Also for death animations you can cheat and have the character instantly turn to face the camera before they die. That's what DOOM and many other games did.

Mark

Trond A

Mar 4, 2005 at 9:42 AM

As someone above posted, you could/should make parts of the game 3D. IMHO making the characters 3D looks cool, as long as the environment is 2D. Remember the game Little Big Adventure? Probably one of the best games ever, and they did this. And the memory problem vanishes along with the choppy character turning as well :)

-Trond

kburkhart84

Mar 4, 2005 at 10:07 AM

My opinion is that you should do eight frames of direction that are animated, but the actual firing direction can be almost any angle like the final fantasy VI idea. If is shooting you are concerned about, then make it where your aiming rotates freely, eeven if the sprite itself does not. The shooting can be like asteroids, but the sprite can only be eight directions.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.