Sprite Animation
Sprite Animation
Once we are able to load and "blit" our sprites around the place, we can look into
having them animate too.
The simplest form of animation is simply to have the sprite cycle through a number
of "poses", possibly while translating around the screen at some suitable
corresponding rate.
BTW: These "poses" are sometimes called "frames"
(of animation), but I try to avoid overloading the word
frames in that confusing way.
(of animation), but I try to avoid overloading the word
frames in that confusing way.
Super Mario
I suppose the early Mario games are the classic
illustration of this kind of sprite-animation:
illustration of this kind of sprite-animation:
Manic Miner
However, as a child of the 8-bit home micro era,
I have a sentimental fondness for this earlier one:
I have a sentimental fondness for this earlier one:
(1:47 for the bit I want)
Sprite Sheets
The poses for a particular character are usually stored
together in a larger image called a "sprite sheet"
together in a larger image called a "sprite sheet"
Individual poses can be extracted from a single
sprite-sheet by using the generalised drawImage method.
sprite-sheet by using the generalised drawImage method.
The Running Man
Another Sprite-Sheet
Here's another one that I found lying around somewhere:
Using a Sprite-Sheet
If a sprite-sheet is designed on a regular grid,
it's easy to extract each pose...
it's easy to extract each pose...
By cycling through the poses, as part of our "update" logic,
we can then playback the intended animation.
we can then playback the intended animation.
Here is a (very crude) code example:
Animation Driven Motion
The previously described method is the simplest way of creating "multi-pose" sprites, but it can be rather limited.
In particular, the actual motion is still dictated purely by the code, via explicit co-ordinate updating code (i.e. "maths").
This is actually quite good in some situations, because it's
very regular and predictable, but it doesn't necessarily produce the best quality of animation.
This is actually quite good in some situations, because it's
very regular and predictable, but it doesn't necessarily produce the best quality of animation.
Animators often like to control the motion aspects too,
so they can provide hand-made & artistic non-linearities.
so they can provide hand-made & artistic non-linearities.
Prince Of Persia
The original classic, from 1989/1990.
(Gameplay begins at 01:45)
(Gameplay begins at 01:45)
How?
In an animation-driven system, the positional offsets are encoded alongside the animation "poses" (aka "frames"),
and are created by the animator... possibly via a special tool.
and are created by the animator... possibly via a special tool.
Although, "back in the day" when I did such things, our "tool" was a text editor into which the offsets were typed by hand!
These offsets then govern the runtime motion, instead of the
"x += speed * du" code that would otherwise be there.
"x += speed * du" code that would otherwise be there.
But, really, How?
In this particular case, it was done by filming live motion,
and then "tracing over" the result on graph-paper.
and then "tracing over" the result on graph-paper.
Modern Remake
I found this rather nice-looking effort to
recreate the original Price of Persia as a web-game.
recreate the original Price of Persia as a web-game.
Downsides?
Animation-driven systems can produce better results in terms of pure animation-fidelity, but they can be trickier to work with, and challenging to integrate with other systems
(e.g. physics, networking, potentially even AI).
(e.g. physics, networking, potentially even AI).
In 3D games, they can also be expensive to compute on the server-side, especially on MMOs (which is why MMOs like "APB" generally avoid this approach and stick to old-style "physics-driven motion").
Having your "bugs" being hidden inside a bunch of "magic numbers" maintained by the animators can be... non-fun.