animation system

I don't feel like making a new screenshot so here are some tulips instead.

This is a general overview of the way my character editor works.

To recap from my last post about aiming, all of the objects in the editor are nodes in a hierarchy. They are derived from a base class that I call TransformNode. The specialized nodes that I have so far are the Joint, IKHandle, and Quad. Joints are nodes that form a skeleton and can be affected by IK, IKHandles are nodes that control an IK chain (of joints), and Quads are the textured quads that make up the visible part of an entity.

All nodes contain a collection of attributes that are used in animation. The base node has translation and rotation attributes, and specialized nodes can add other attributes to the collection. The Quad, for example, has additional attributes for width, height, and texture coordinates. (This means that texture/sprite animation can be used in combination with skeletal animation.) New attributes are animateable as soon as they are added to the node and exposed to the interface (via a public property with get/set accessors so that they show up in the property grid).

Attributes are animated by setting keyframes in the animation curve that is associated with that attribute. A curve contains a set of keyframes and a reference to the node it affects, along with the attribute index. Keyframes contain data for control points on the animation curve and their tangents. The positions of the points on the curve are the frame of the animation (x) and the value of the attribute at that frame (y). Bezier interpolation is used to interpolate the values between keyframes. An animation is simply a set of curves.

Aim animations have an additional bit of data called an AimVector. It has minimum and maximum rotation values and is attached to a node in the hierarchy. Aim animations are like regular animations except that there are only two keyframes. When aiming, the angle of the vector between the aim vector node position and the target position is compared to the minimum and maximum angles to get an interpolation value. This value is used to do a linear interpolation between the two frames of the aim animation.

When exporting animations, the curve data is interpolated and values are saved for every frame in the animation (so that interpolation does not need to be performed in game).

This editor has evolved a lot over the time I've been working on it. I'm finally satisfied with this particular implementation, although a lot of the functionality was copied from Maya.

animated gif creation

In my previous post, I included an animated gif showing my editor in action. I thought a gif was appropriate in this situation because it was a short animation, uploading it to YouTube caused serious distortions, Photobucket doesn't allow me to host swf files, and because the limited colours make it suitable for gif compression. I used several free tools to make this gif, and thought I'd describe the process in case others find it useful.

First I used CamStudio to record the demonstration. It's a really simple app that outputs avi files and has the option of converting them to swf files.

After that I used RAD Video Tools to convert the avi file into a series of gif files. I set "Adjust (adds/removes frames) to" to 15, so the output would be 15 frames per second of video.

Then I used GIMP to turn the gif files into a single gif animation using the instructions I found here. Like the post says, I opened the first file and imported the rest as layers using File -> Open As Layers. I saved the file as an animation that loops forever with a 60 ms delay between frames. I also set "frame disposal where unspecified" to one frame per layer, and checked "use delay entered above for all frames" and "use disposal entered above for all frames".

The result was a 523 KB file with 266 frames at 272x248 pixels, 17 seconds at about 15 fps.

more aiming

I came up with a better way to do weapon aiming. In order to implement it I had to rewrite some parts of the editor to make it work more like Maya. All of the objects in the editor (Joints, IKHandles, and Quads) are now derived from the same base class, called a TransformNode, which has translation and rotation values. They are all contained in the same hierarchy, with a single root node. Here is an example of how this system can be used for aiming:



In this example, the aim animation rotates the node that the IK handles are grouped to. The shooting/recoil animation moves the IK handles.

It seems so obvious now that this is the correct way to do it; I'm not sure why I didn't think to do it this way earlier. This system uses the IK handles directly, so the hands are always placed correctly. It's also more flexible and consistent than what I had in my previous post.

game project

I figured I should start documenting the development of my game more thoroughly. I've avoided posting my plans because I don't feel certain about them, but there are some things that are not likely to change so I can at least talk about that.

As you can probably tell from previous posts about this project, it's a side-scrolling game inspired by Soldat. I was motivated to start it by the demand from the Soldat community for more modding possibilities in Soldat. I'm borrowing heavily from Soldat in several aspects (2D skeletal animation, terrain made of textured polygons, combat with projectile weapons, mouse aiming) but the similarities mostly end there.

My game is going to be a single-player Metroidvania-style platformer with a focus on exploration and the use of a variety of weapons and items to defeat monsters and progress through the world. I plan to incorporate elements inspired by the Zelda series, especially Wind Waker, into the gameplay and visual style. Like Zelda, it will have a fantasy theme, with possibly some steampunk thrown in (see Chrono Trigger). Features include vehicles, water, and dynamic lighting.

One of my main goals with this project is to make content creation relatively easy and fast. To that end, I'm developing powerful tools for use with the engine (the character editor and the map/general editor that I will start re-writing soon). I'm aiming to have the tools and engine ready to use by September 2009, with a demo ready by May 2010 for use in my portfolio. At that point, assuming I get there, I will decide if it is worth turning into a full game (possibly with online play). However this schedule is not fixed.

I'm using C# with MDX, and I intend to port it to XNA 3.0 eventually.

In upcoming posts I will go into more detail on the internal workings of the game and character editor and on my plans for the game itself.