Something went wrong. Try again later

PeezMachine

This user has not updated recently.

702 42 20 25
Forum Posts Wiki Points Following Followers

SummerJammers Update #7: A Matter of Time

In case you missed it, I'm working on a Giant Bomb game inspired by that old chestnut, Windjammers. And it needs your help!

Yeah yeah yeah this update is a few days late. But oh man, is it worth it.

Interestingly enough, this is the first time that I've ever written a program with time dependency. My other work has mainly been logical and computational stuff or tools for working with turn-based board games, but nothing that actually has to keep an eye on the clock. So the past week and a half gave me my first ever real-time challenge: animations. This was something I wanted to come at blind, so I didn't look up how to code animations or anything like that. I just read up on XNA's clock features (which are simple yet robust) and got to work. The result is an Animation class that holds a list of AnimationFrame objects that hold references to an image and a TimeSpan object indicating how long the frame lasts. The original implementation had each Animation keeping track of when it was being started in absolute time (for example, 3 minutes and 14 seconds after the program launched) and then attach that information to its frames (so frame 3 knows that it should start at 3 minutes and 14.2 seconds). This worked, but came with a number of problems, the biggest of which was the need to be continually creating and destroying new Animation objects (since they referred to an absolute start time). The system also didn't present a neat solution for mid-animation speed changes, so getting it to behave properly when, say, a player's run speed drops mid-stride, was cumbersome.

But praise the sun for showers, because it was in the shower that I got the idea to do the obvious smart thing and instead use XNA's built-in ability to see how long it's been since the game last updated itself. Accordingly, I changed each animation to simply keep track of how far along in its progression it is (.7 seconds since it started, for example). This immediately solved the issue of speed changes; if it's been .02 seconds since the last update (which was .7 seconds into the animation) and the animation needs to run at half speed because the player became dazed on that very frame, then it simply cuts the time jump down by a factor of two and sees which frame it needs for .71 seconds instead of .72. This system also eliminates the need to be constantly building new animations, since you can just reset an animation's progression when you need to start it (instead of building a new one with a new absolute start time). I've also built in support for one-off and looped animations.

The player on the left has thrown the (fully collision-enabled) disc to the player on the right. The
The player on the left has thrown the (fully collision-enabled) disc to the player on the right. The "2" indicates that the players are on the second frame of their standing animation.

Working with animations has given me a good sense of how most time-based issues will be handled in the game. Essentially, it's one big application of Euler's Method, a system for approximating a curve by using the instantaneous rate of change from a large number of discrete points. That's exactly what we're doing here - we're asking 30 to 60 times a second, "how fast should this be happening" and then moving things along at that speed for a fraction of a second before getting a new reading. However, while the animations work beautifully, implementing them has exposed a poor design choice in separating my Character and Avatar objects, but that fix is underway and pretty straightforward, so it's all good.

And now seems like as good a time as any to start recruiting folks to contribute!Right now I'm interested in getting the art and sound departments staffed up. I'm looking for two (2) people to act as heads in each department. Ideally, these folks have some experience in their field, because they'll be in charge of setting the tone and ensuring the consistence of both the quality and style of assets. The overall audiovisual design (retro, gloomy, futuristic, etc.) is more or less in the hands of the department heads (though we will definitely need to agree on it!). The graphics engine is exclusively based on 2D sprites.

So if you have some experience and want to be a department head, shoot me a private message by Friday, Jan 31 at 5 PM PST telling me which department you're interested in (obviously) and what experience you have in that field. If you want to contribute but don't want to be a department head, just hold on and we'll get to that in about two weeks once we've named some heads, who will be free to field as large a team as they desire. As for additional code contributors, we'll need people to work on networking and AI, but that probably won't be until the game is otherwise feature- and asset-complete.

There probably won't be an update this Monday, what with it already being Thursday and all, so good luck and #BeatRemo.

1 Comments