Laskuvarjotaisto

2018-07-28

Once again, the Finnish Blender IRC channel had a gamejam around midsummer. An established tradition, I wrote my game hungover.

This time I had some time to plan my game in advance. The theme was simple: Creating a clone of an older Amiga game known as Parachute Joust. In this game, two guys fall out of an airplane and fight it out for a single parachute. The guy who ends up with the parachute when the time runs out, wins. The mechanics were laughably simple and easy to implement with a strict time constraint of three days.

For the basic engine I copied an old template of mine I had lying around from several abandoned projects. This template included basic rendering, configuration options, controller support and data storage. After spending a couple of hours cleaning this code I had the basic structure in place. I moved on to implementing controls using the gamepads. I didn’t have the time to write a proper controller configuration utility allowing custom deadzones or customizable keybindings, but these both could be done via a config file. Writing this code I couldn’t help but to wonder how some games (I’m looking at you, Guilty Gear Xrd) manage to mess up their gamepad support so badly: With SFML all I had to do was write a generic gamepad button mapping matching certain input events in the game. How complicated can it be to properly support multiple controllers of different types? At the end of the project I ran a test game with two other guys, all of us having controllers of different types, and after some calibration the game ran fine. As an added bonus what was originally a bug turned into a feature: I never limited the number of controllers, having assumed the game was played by two players. However, since there was no limit, I gave the game a try with up to four controllers and nothing broke - technically there’s no limit on how many players can join the fun!

The enjoyable part of a project well planned and limited in scope is how easily everything falls into place. With the basic controls down, all I had to do was get implementing the features I wanted: Punchable guys, a timer that runs out and stealable parachutes. All of these were fast to conjure up. I moved on to adding some audio, lavishly stealing open licensed sounds and music. I even had the time to spare to add some variety in the played sound effects to make them more interesting.

For animations I implemented a basic file format, the .chute, which contained only two bits of data: Animation playback speed and images to play in the animation. Some refactoring later I had a basic sprite class written supporting animations and looping them. Next would be the hardest part so far: replacing temporary programmer art with actual graphics, a task I had dreaded for and tried to avoid until the very end.

I first dared to try drawing the art myself. This quickly proved to take much longer than I had time for, and I instead jumped to take a shortcut. Soon I had MakeHuman running and a dashing protagonist “modelled”. I sent this file to Blender and animated the character. Luckily there only were four different actions to do in the game, including movement in all directions in different states, which was doable even by an incompetentjumped to take a shortcutWell before the deadline the basic game was done. I only have a Windows build available, but I’m pretty sure the game compiles on Linux too.

Credits for external resources: