LittleBear
says: It's six-dozen of one, half the other.
05.02.07
Riders on the Storm Postmortem
This is the first postmortem I’ve written on a game, but I feel it’s already been helpful just thinking about what to write. Riders on the Storm is a game I created for the AutoFire 2007 Shooter Competition. It was sort of inspired by a combination of hearing the famous song by The Doors one day, and thinking about Plasma Pong and the fluid effects used there.
So, we have a game that essentially started as a song title, with some nifty physics added, and then I started to think about gameplay. This is generally not the recommended way to go about developing a game. But it’s not that bad, either. By placing a set of artificial restrictions around yourself you at least limit the scope of what you are tring to do, helping to focus on fewer things. Kind of like writing a Haiku.
What went right? (Or: The Fairly Obvious Stuff)
Sound. The contest deadline was extended a month, which gave me time to finally learn the OpenAL sound API in LWJGL. It’s really hard to state just how much this added to the overall feeling of the game. I was reading about Druid Soccer and noticed that the music used there fell under a Creative Commons License. This was perfect for me, as this site and my games fall under the same type of license. I was then very luck to find Slipstream, the background music, by Darren Nelsen. I think the mood it creates while playing the game is near perfect for what I wanted.
Technology. Given that I have been programming Java for almost 10 years now, it’s pretty obvious that it would be a comfortable language to write a game in. If you combine that with OpenGL and the excellent LWJGL library to bind it, you’ve got a combination that’s pretty hard to beat for shoot ‘em ups. You’ve got low level access to everything, all the power of a mature programming language, and the productivity that brings with it.
The Team. This is just a little bit painful to even write, but the fact is that doing it all yourself makes decisions easier. They’re not always right, but there are no arguments over aesthetics, and no fights over deliverables with depedencies not done. Do I wish I could create pixel art like in Force Majeure? You bet. But I’m also a fan of abstract styles, and that I can carry off.
Eye Candy. Early work was spent figuring out the math in Real-Time Fluid Dynamics for Games. The success of the effect in real-time was such that I kept it in as an intereactive part of the title screen. A lot of people have probably spent more time playing around with the effects there than playing the actual game. Is that a good thing? Well, if one purpose to this is to entertain, then yes, it need not be just the game that achieves that.
Innovation. The game has some nice features, such as using a wind-charge to blow bullets back at the enemies. Another interesting mechanic added is the affect of the fire on your own ship, it can overheat if you’re not careful. These two elements allowed me to add multiplier bonuses to scores that nicely traded off the score with the danger in getting it.
What went wrong? (Or: The Interesting Stuff)
Real-Time Fluid Dynamics. The game turned out to be a showcase for the fluid engine. I’m ok with this, except that I happened to choose some physics that are pretty taxing on my CPU. Running the initial demonstrations unthrottled left me at only 10 or so FPS above my final goal of 60. Yet I still had a game to implement, with its inherent logic and all that. This didn’t give a lot of room for the game on the CPU, and the game sufferes on my machine at times with a noticeable slowdown.
Lack of Gameplay Focus. The game itself is comprised of only 3 different enemies, with bullets and mines. There’s no theme to them, other than they fly. It would have been nice to have a little more background or story to what was going on.
OpenAL. It seems that support for OpenAL is very inconsistent at best. Being pretty new to the API left me unsure of how to properly use it and how to properly cushion myself from the potentional errors. Some late bugs caused me to err on the side of caution and turn sound off at the slightest hint of the player’s computer not behaving properly. The general consensus seems to be “next time I’m using FMOD“. I’ll likely be making that switch myself.
Missing Features. While I’m generally pleased at how the game is “packaged”, there are some features missing that would have nicely finished it off. There’s only support for keyboard control, and even that is not customizable. Hiscores were also never implemented. These things, at least, should be expected in any game, even if it’s free. Some easily reusable code can be built around these for Riders and other games in the future.
Lack of Planning. The scope of the game is small enough that it seems easy to fall into the trap of not planning things out. However, I then tended to find myself with time to program and no idea what I should do. Plans can and will change, but going forward I’ll be doing a lot more work away from the computer on what the game will look and play like.
Conclusion
In general, I’m pretty happy with how this game turned out. With the exception of adding a few of the mentioned features, though, it’s unlikely that I’ll revisit it to add new gameplay. There are other games to be made, and other ideas to be explored.
