Timers are fun!

Just doing some work on our new timer and interpolator system, and in the process of doing so I was able to figure out an interesting twist.

You see, timers are used all over – from driving a time value that sparks an interpolator to produce a “value” to driving an animation to produce “frames”, timers are useful. Even more useful than just being able to go forward and backward in time (because that’s just too easy) is when one partitions up time segments into “actions”. This gives rise to the actioned timer.

Actioned timers are even more interesting in that they allow a general interpolator, which knows only a curvature of some kind (using both interpolation between defined key frames and extrapolation beyond those frames), to exist itself as a generator for actioned values. What this means is that parts of a curvature can then be segmented and ran across in an interesting way.

Quake was the first of the major series to introduce VKFs (vertex key framed) animations. The later .md2 file format was very common and used in a lot of different places, but the sad part was that it was split into two unique sections (torso and legs) and then also the key frames were statically partitioned into actions. Well, overall, the key frames that defined the entire model were just one long stream.

I’ve read a number of books that show how people have taken .md2, paired it with an extra “script” that defines actions and their time frame start and end points, and then loaded that (e.g. Eberly). I think that is such a horrible way to do things, because even though you’ve managed to make what was once static into dynamic, it still has a lot of further problems. I am really glad we’re using our own file format for this now (the game asset manifest, or GAM (GAMX for the XML version)).

Animation becomes a really much more difficult task to attack because the mechanism that drives the conceptual details can be built up in so many different ways. Either way you look at it, though, the timer object, the way it’s built, etc., has a direct relationship to how animations “happen”. It isn’t just that an animation is occurring, or that a model is being displayed on screen, there has to be some layer of “control” that manages the process.

Of course, there are other forms of animation that should be taken into account also, such as streamed video. That requires an entirely different mechanism than a timer all together (more of a streamer object). When you start dealing with video content streamed over the web, that becomes even a more simple, yet complicated, problem to solve.

So, really, by abstracting the timer control out, we’re left with a very simple infrastructure to work on. For sprites, all we need to do is produce an image based on a particular frame number. For interpolators, all we need to do is produce an interpolated/extrapolated value based on a frame number. For VKFs and SBAs, all we need to do is produce a new vertex list based on a frame number. The concept otherwise, swishing around from key frame to key frame, is all handled in the timer control.

The abstraction here is all key. The way that the animations “happen”, under the hood, shouldn’t have any bearing on how time segments are ran across. However, we do wind up seeing some interesting problems arise. Back in the days of N64, we saw many games that used basic action controllers. The most consumer visible aspect was that animations would “jump” from one to another. If you were in the middle of running, and jumped, the animation was not streamlined. Of course, now-a-days this is fixed by doing a double interpolate, which is a weird architectural change that works.

What will become more interesting to see in the future is when animations are driven purely by the physics involved. We’ve already started seeing this behavior in many games, but it still has a long way to go. Before too long, it may start looking possible to model animations not as strict key frames, but instead model it as motions of power applied to a physics based system. This will be the ultimate animation, when you can actually trip characters walking along, or actually bust holes through a pirate ship. That’s a whole lot more fun, and tricky, to see happen.

Of course, for now, just to get to the point were we can have fully animated sprites, 3D models, and other “things”, will be a great base to continue building onwards. RPNi will definitely be able to take things to the next level.

I can’t wait to see how these interfaces work out during production.

Best of luck. -JvL

Advertisement