A Guide to Animating Sprites

Step One: The Sprite Sheet

Step Two: Setting up your sprite block.

I've read around the poor, neglected Zot forum on ZodiacGamer and I've noticed most problems with Zot are here, with animating your characters.  Fear not, for I shall dispel the daemons which infest your script and cause your sprites to spasm inhumanly!

Obviously, you can't have a sprite, none the less an animated one, without a sprite sheet, the image containing each frame of your animation.  If you already have something in mind, it's easy enough to slice, dice and mince your artwork into a solid and usable sprite sheet.

If you're like me, and aren't the best with digital imagery, you could call upon the almighty Public Domain sprites, or rip them from your favorite ROM file, as long as you aren't planning on profitting from it!  Unless you're a jack of all trades, I suggest that or finding a team of artists and level designers to help you, even what seems like "a simple Zot game" can require a small team to accomplish mind you.

As I mentioned in the Basics section, the easiest way to throw together a sprite sheet is to make a standard measurement of the largest sprite you plan to use, then use a grid on your image program to fit each sprite image into the sheet evenly, leaving room for the largest and usually not leaving too much excess around it.  But what if there IS alot of excess you ask?  Just use the lines "height" and "width" in the sprite block to set how large the collision detection area is!

Depending on what you're making, you may need anywhere from only three frames (for say a space fighter game where you only move left and right and a still state), all the way up to dozens for the maximum ten animation states.  Remember to space accordingly!  (What I did was use my standard measurement and multiplied it by the highest number of frames or my longest animation, so my, say ten frame running animation has room now, and the extra space is just empty!)

Oh yeah, and I recommend using TGA, since it doesn't involve indexing or filling the background with (123,123,123) RGB solid grey.  TGA also holds more colors :)

A sprite block is where you store all of the information that defines a sprite.  Information that goes here could range from just the name, size, an option or two, and a still state artwork, all the way to everything listed plus nine more animation states and more options.  Of course, defining eight directions isn't necessary if you're only planning on moving four ways, so deciding what you want is key.

There are two types of sprite blocks for animations, one with angles and one without.  A sprite block that includes angles does not have anim_statedefs of up, down, left, right and diagonals, but it instead has just the angle, still, inactive and dead statedefs.  The "still" state is required for all sprites, as any missing states will revert to this (so if you left out, say, "down", your sprite will use the "still" animation state instead!).

I've broken the block up into seperate tables for you.

Typical, directional sprite setup:

sprite	player
name	player
ai	player
speed	1

option	impassable
option	velocity
#option	nostill
#option	angles

order	1
leaving	60
inactive	100

width	50
height	90
offset_y	0

image_width	50
image_height	90

anim_statedef	still
anim_steps	1
anim_shift_x	0
anim_shift_y	0
offset_x	0
offset_y	0
anim_image	your_spritesheet

You'd just take the same layout as the still state and adjust the shift and offset lines to each animation.  I like to order mine like this, top to bottom: up, down, right, left, still, inactive, dead.  Remember that standard measure thing?  It comes in handy here, as you can easily do some quick math to find your shift and offset lines!

Quick note, OFFSET is the amount of pixels the engine moves right or down (x or y) to find the next frame, and SHIFT is how many pixels it moves to find the FIRST frame!  Don't mix these up or you'll go nuts trying to figure it out!