Rolling Average Smoothing

At the IGDA Twin Cities meeting in March, the lead developer for Just Jam, Matt Heinzen, mentioned using rolling averages to do animation. This caught my attention, since it was a perfect phrase for a trick I have used a number of times in my programming. I thought I'd take a shot at explaining it here since I did a horrible job on the IGDATC Podcast.

A rolling average is also known as a moving average along with a few other cute names. Wikipedia does a good job explaining it in that Wikipedia way. You know, the equation way with complicated, but accurate, descriptions. I say a rolling average is just a way to take the average of a select part of data set. For example, in the last 7 days, I've averaged 0.6 cans of Mt. Dew a day. If, tomorrow, I don't consume any Mt. Dew, my 7 day average will go down.

So how does this help in programming? For me, its usually a matter of convenience. You may have binary data and you want to smooth it out some for instance. To really smooth it out you may want to be aware of your time step, acceleration/deceleration, velocity, motion time, time into motion. Maybe even more. With a rolling average all you need is a target value.

Lets say you've got an arrow and you want to have it point somewhere. You don't want to have super control over the animation of the arrow like I mention above, you simply want to tell it to point up or point down. However, it would be nice if the arrow rotation had some motion.

Let's set up this example. There is an arrow pointing up, lets call that 0 degrees. Now at some moment you want to say point down, rotating 180 degrees. If all you do is say at one moment your 0 degrees, and the next moment your 180, there is no animation. Let's use rolling average to smooth it out. All we need to know is the target rotation angle, which in this example is either 0 or 180, and the current angle. We need to pick a period, which in the Mt. Dew example was 7 days. In a typical game, and in most cases I've designed, they end up depending on the frame rate, lets not concern ourselves with that at the moment and pick a period of 10.

rolling average rotation = ((current angle) * 9 + (target angle) * 1) / 10

With that example, the first frame after the target angle is changed from 0 to 180, the rolling average will calculate it to be as follows.

rolling average rotation = ((0 degrees) * 9 + (180 degrees) * 1) / 10

rolling average rotation = 18 degrees

That is to say instead of it immediately snapping to 180 degrees, the first frame after its told to go to 180 degrees it rotates to 18 degrees. The next frame would look like this:

rolling average rotation = ((18 degrees) * 9 + (180 degrees) * 1) / 10

rolling average rotation = 34.2

And continuing on.

To help illustrate this I've made a little XNA program.  You can either download it and give it a try (no guarantees), or watch this video.

Zombie Game Prototype

I'm working with Robert Green at Battery Powered Games on another game, this time its a action game. About 4 months ago, Rob and I got together for a meeting to discuss our next efforts and discussed ways to learn from our mistakes on Deadly Chambers. We each came with five game ideas and pitched them to each other, back and forth. At the end we picked one idea and went with it. The idea we picked was mine and goes something like this:

Combine Flight Control with Tower Defense, best described with with humans and zombies. You control the humans and try to get them to a safe house, they may or may not have weapons. The zombies try to eat your humans. I'm not going to go into the details beyond that because, along with a designer we've hired, we working on many of the details to make sure the game is fun, engaging and rewarding.

Since the pitch, I've been thinking about the game play and I've come to many conclusions. This is a problem, since we have yet to see the game in prototype form. Rob (and me to some extent) has been busy on some other projects, one of which is Battery Tech, and another is an android game that will be hitting the market within the month (fingers crossed). (My friend Bill and I did the art for this soon to be released game FYI so look for future blog posts about it). Rob hasn't had the time to make a prototype as he's also executing some other business ventures and contracts.

As I said we hired a designer but he has become confused about the game which is primarily my fault. With so much time thinking about the game play its hard to keep an open mind, to be flexible. It's hard to explain things well and succinctly, at the same time to not seem contradictory to previous statements. We've gotten buried in communication issues and semantics. It has been interesting to see the designer's interpretations and opinions, and his designs given our flawed descriptions and requirements. Its also been problematic because we each have our ideas we're pretty adamant about, but no way to see them in action, get a feel for what works and further the discussion. I was contemplating making some level drawings and animating them to show how I expect game play to work, but then I decided I should just program a prototype.

This is what I love about programming. I started at about 9pm and fired up some XNA sample and just had at it. 6 hours later the clock reads 3am and I reluctantly call it quits. But at the end is a partial prototype allowing for human path drawing, basic zombie AI seeking/attack, a safe house, turning (human becomes zombie), weapon pickup, and human AI targeting.

 

 Ryan's Zombie Prototype Version 1

In the above picture, the grey blue lines are paths for the humans. The purple diamonds are zombies. You can also see some of the humans are armed with little guns. The lines from humans to zombies show that the humans are targeting and within range of a zombie. I'll be adding some code to do shooting next as well as see what Rob and the designer say.

Needless to say, I'm excited to program again and wonder why I never really get into it when its so much fun. I'm excited to build up some momentum on this project as well. I'm art lead with two artists on my team, so I'm anxious to get them working.

Deadly Chambers Controls

Making a game can be fun and profitable (so I've heard), but its also a learning experience.  One of the main criticisms of Deadly Chambers is the controls.  It's a mobile phone game granted, and a shooter at that, but we fell we did a pretty good job dealing with some of the limitations and oddities of Android and the numerous devices to make a control system for the game.  Yes, it has its issues, it isn't perfect granted, but it's pretty ok.  In some ways I think it works really well, innovative even.

Regardless of how much I pat myself on the back, or how close to the design and biased I am as co-inventor, it still comes down to the user experience.  That made me think not only about how people play, but what they may be trying to do.  If they are anything like me, they skip the tutorial, skip the control scheme image description, etc. and just jump into the game to figure it out.  This isn't a big deal I think, unless you make some misinterpretations about how it works, maybe even blame it for doing what you are telling it to do but not realizing it.  Then I found a video on YouTube of someone else playing and it made sense.  Of course people don't play it the same as I do, but why don't I show them.

IGDA Twin Cities Podcast #2, Velcro

The second episode of the IGDATC poscast is published.  We talked about video games, mobile gaming devices, IGDA’s impact on the Twin Cities, last month’s meeting recap (Dead Space 2, Technical Artist Sandra Voelker) and upcoming events.

Check IGDATC.ORG to listen to the podcast, or check it out the on iTunes.