Re: Main character animations.

[Steve Baker <sjbaker1@airmail.net>]

Katie Lauren Lucas wrote:
> 
> So I'm toying with this 2D spritey game idea. Has a main player character which
> has lots of pick-upable weapons (guns, bows, swords, spears). So I'm wondering
> how to handle this graphically. I can think of:
> 
>   1) Tons of sprites, going to need each weapon X each direction X each frame
> of animation.

Well, modern machines have an insane amount of RAM.  You should be able to
do a back-of-envelope calculation to know whether this is reasonable for
any given value of X and sprite size.
 
>   2) Layers of sprites, one to animate the main character, one to overlay a
> weapon on him/her. Issues of alignment, it might end up lacking graphical
> sophistication. I have a feeling this ends up needing (weapons X directions X
> frames + directions X frames) images in total.

I think this is the answer - although I'd probably write the code to rotate
the weapon sprite on-demand.  So you'd hand-paint a sword (say) laying horizontally
and then when the player picks it up, have the game code generate all the rotations
you need into a cache.  As each new weapon is picked up, you generate it's sprites - and
if your cache is full, you toss out the oldest weapon's sprites.

I doubt that the time to generate all those rotations would be too significant - but
if it is, generate each of the rotations on-demand, remembering which ones you've
done and which are missing.

I don't think the "Issues of alignment" should be too significant - although
you might have interesting problems when you'd like parts of the player's body
to block the view of the sword - whilst the sword simultaneously blocks the
view of other parts of the body.

>   3) Cheat. Have the player carrying an indistinct black blob.
> 
>   4) Sophisticated cheating. Player carries nothing, when he starts fighting he
> draws a weapon. Not sure this reduces images much.
> 
>   5) Not caring. Player carries a sword. All the time. If he's got a gun he,
> erm... appears to shoot with a sword. Heck, if RPG players can cope with an "@"
> being a person...

Na - those all suck.
 
> In a 3D game this would be easy (attach appropriate weapon mesh to the player
> character's "hand" matrix)... but how do people do this in 2D games?

Well, it depends on the resolution of the sprite.  If it's *very* high res then
it's going to be a problem.  If it's lower res then just rotating the sprite
whenever you draw it isn't impossible.

You are probably thinking of sprite rotation as involving lots of sin() and
cos() calls - but you can be smarter than that.

Suppose you built (slowly) a set of tables - one for each position a weapon
might need to be in. Each entry of each table would correspond to one pixel
in the rotated image and would contain a number indicating which pixel within
a UNROTATED sprite would end up at this position in a ROTATED sprite.

That table can then be used to render *any* weapon using a simple static image
of the weapon.  It could even be used to mask part of it out where the player's
body occludes it in that position.

Hence *one* (admittedly large) set of tables - one for each of your X positions -
will allow fast rotation of *ANY* object that the player might need to hold.
This would allow for interesting game play where the player can pick up monsters
or selected parts of the scenery and bash other hapless creatures with them!

Generally this kind of crude rotation aliases nastily because there is a
1:1 relation between the 'output' pixels and the ones in the unrotated
sprite.

You could get around that (for example) by storing FOUR pixel addresses at
each location in the table - along with a number to multiply each one by
before adding them together and writing them to the frame buffer.  This
would produce quite nice antialiased sprites.

Bear in mind that not many pixels of your output image have to go through
this complicated process - so it's not much of a stretch to presume that
you could rotate weapon sprites in realtime.

It's hard to give advice without knowing:

  * How big is 'X' (the number of sprite positions your player has) ?
  * What resolution will your sprites be?  (32 pixels? 100? 300?)
  * How many weapon types do you need for each 'level' of the game?
  * What CPU speeds do you want your game to accomodate?  (Does it
    have to run on 33MHz 486's?  Can we assume a 266MHz CPU?  Maybe
    it's going to take a year to write and only run on cutting edge
    processors at 4GHz?!)
  * How much RAM are you going to require the player to have? 16Mb?
    2Gb?

The nature of the answer depends critically on these questions.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net