[Ohrrpgce] Sprites, animation food for thought

[Mike]

Shoot, if this email went out multiple times, I apologise.

If not, please disregard this.
--
Mike Caron

-----Original Message-----
From: Mike Caron <caron.mike at gmail.com>
Date: Sun, 10 Oct 2010 13:37:53 
To: <ohrrpgce at lists.motherhamster.org>
Subject: Sprites, animation food for thought

First off, a disclaimer: This is not an actual proposal for a data 
format for the OHR. This is something I've cooked up for another project 
which may or may not ever see the light of day (hopefully, it will, but 
it's immaterial to this discussion).

This is how I've implemented sprites and animations in this other project:

First, all pixel data is stored in sprite sheets. These are PNGs that 
contain all the sprites for a given on-screen entity. Technically, as I 
am writing it in .NET, nothing is stopping them from being BMP or JPG or 
something, but I prefer PNG for its true-colour and transparency support.

Then, with each sprite sheet, there is an XML document that describes it:

<spriteset xmlns="http://mike-caron.com/za" name="link1" file="link.png">
     <frame x="33" y="1" width="16" height="22" ox="8" oy="19"
name="stand-down" />

     <frame x="3" y="31" width="16" height="22" ox="8" oy="19" 
name="walk1-down" />
     <frame x="33" y="31" width="16" height="22" ox="8" oy="19" 
name="walk2-down" />

     <!-- etc. -->

Each frame has a name, a position and size on the sheet, and an origin. 
The origin is aligned up with the actual entity's origin (which, ATM is 
always their (x,y) position, but that may be customizable later on)

Then, after the frame definitions, we have the animation definitions:

     <animation name="stand" deftime="1" loop="no">
         <dir dir="down">
             <frame>stand-down</frame>
         </dir>
         <dir dir="up">
             <frame>stand-up</frame>
         </dir>
         <dir dir="right">
             <frame>stand-right</frame>
         </dir>
         <dir dir="left">
             <frame>stand-left</frame>
         </dir>
     </animation>

This is mostly self explanitory. Every frame has either one or four 
directions defined, depending on if the sprite has meaningful directions 
(an item on the ground, for example, probably only has one direction. An 
NPC, on the other hand, will have all four).

Each frame in a direction can have a time parameter, which describes how 
many ticks the frame is displayed for. deftime is just the default such 
value. Obviously, as well, if loop is yes, the animation will start from 
the beginning. If no, it will just stop on the last frame forever.

Finally, every entity in the game references both a sprite sheet and an 
animation. The idea is that you could change one or the other. For 
example, if you get a better shield, the sprite sheet changes from 
"link1" to "link2". And, obviously, the animation changes based on what 
is happening in the game.

A few notes on this structure:

  - There is no accounting for palettes. If you wanted to use a paletted 
sprite, then by all means you are able, but don't expect to be able to 
change that palette in game. The canonical way to add palette swaps is 
to have a different sprite sheet with the same animations (and, I may 
add some way to automate this. Eg, "this sprite sheet is exactly the 
same as this other sprite sheet, so use those definitions")

  - There is also no way to get any fancier animations. I.e, there's no 
way to automatically oscillate or go backwards or whatever. The way to 
achieve these effects would be to duplicate the frames in the animation.
    - I may or may not add sprite flipping.

  - The way the images are laid out on the sheet has absolutely nothing 
to do with how they are animated or displayed. If you wanted the same 
frame, but offset by 5 pixels or whatever, you just modify the origin. 
No muss, no fuss.

  - Also, there are no inherent limitations on how large or small the 
sprite is. If you want to make a 2d version of Shadow of the Colossus, 
then be my guest! (just, don't expect the video card to necessarily play 
along ;)

So... yeah. Make of that what you will, I'm just adding ideas to the 
pot. I am aware that this format, as is, is unsuitable for the OHR. It's 
just my two cents.