Play it now
Built in 6 hours
The digital agency I [used to] work at has one day a month they call ‘Supercharged’. These are sort-of hack days where all of the agency team gets to work on something new.
The Christmas edition of Supercharged had the theme of ‘make a game’. While we could have made any type of game, I was paired with Shaun and we’d previously been talking about collaborating on a computer-based game, so I jumped at the chance to try and make that a reality.
Our team ended up consisting of myself, Shaun (who is a developer in his day job) and Kate, the office manager. After some initial discussions at lunch about the possibilities, Shaun was keen to underline the fact that making a game in six hours was quite “optimistic”. Aside from time, work distribution would be a challenge, Kate had no programming experience and both Shaun and I would need to work on the code simultaneously.
We quite hastily put together a game design document in the week before the Supercharged day from a template that Shaun found. This gave us at least a basic idea of what objects we would need to use in the game as well as the asset requirement from an art and sound point of view. While I’m guilty on personal projects just ploughing ahead without a design document, I can’t stress enough how important they are when working with a team. Sometimes, even the core idea may differ from person to person unless you take the time to document it and discuss the detail. By getting everybody to contribute to this template, I think Shaun pre-empted several issues we would have had.
Shaun and I had already had experience using Gamemaker: Studio which is excellent for fast prototyping. Another advantage with Gamemaker is that you can develop once and easily export to Windows, Mac, Linux, HTML5, Android and iOS. For ease, we originally aimed just to get the project working for Windows and if we had time, tweak it to work well in-browser. For simultaneous development we used a repo in Bitbucket using the SourceTree client. This actually turned out to be something of a nightmare as Gamemaker: Studio didn’t play that nicely. After having several frustrating file overwrites during the day, we found that after pulling the latest repo you had to reload the project within Gamemaker: Studio so that it was using the latest files. We probably lost around an hour of development time between us rewriting code and resolving various merge problems.
Prior to the day, I tried to write a few pieces of code that solved some of the challenges I could see us facing, such as a good method of infinitely and randomly generating the play area. Going into the day with the confidence that we wouldn’t run into any major problems coding the core mechanics of the game really helped.
We went into the day with the idea of making:
A fast-paced multiplayer party game where each player is a rival present delivery corporation. Players must attempt to drop as many gifts as they can into different size chimneys that whizz past the bottom of the screen. The game lasts 60 seconds and random powerups and mutators will spawn to help or hinder the player.
We got off to a quick start thanks to the design document and Kate had a baptism of fire in pixel art using Piksel to start producing the art assets we needed.
While Kate was working on the “proper” art, I just made some beautiful MS Paint placeholder art that was the correct dimensions and allowed us to start building the layout of the play screen.
Within an hour we had something very basic, two player controlled blocks to move around and the illusion of movement by having a slow scrolling, repeatable background and chimneys that spawned off-screen and moved slightly faster from the right to left.
All of this was pretty straight forward and we got the basic mechanics working of confining the players to the screen, adding the countdown timer and increasing the speed of the moving chimneys every 10 seconds to make the game harder.
Shaun was very keen to add controller support, which was incredibly quick and easy to do with Gamemaker. As I worked on the timings for chimney generation he very quickly got controllers working alongside the originally planned keyboard controls.
Neither Shaun nor I were particularly keen to tackle the collision detection, as it’s usually the hardest (and normally least fun) to debug. After some discussion, we settled that I should do it for reasons I have still yet to understand (:
We considered using a score that was adjusted for how accurately the player dropped the present into the chimney, similar to the accuracy code I have written for the Jungle Joey project. However, with only two hours left to go, I made the unilateral decision to have the collision detection would simply work on a “hit or miss” basis, with more points awarded for dropping presents into smaller chimneys.
To ensure this play mechanic worked, we added a “fire delay” mechanism to each player, meaning they could only drop 1 present per second. This meant that you couldn’t just hold down, or hammer the “drop present” button and effectively forced the player to choose a target. Would they use their drop to get guaranteed points on a big target or risk missing in pursuit of having to make a more accurate shot for a small chimney?
The powerup challenge
We originally planned four powerups to be present in the game:
- Christmas Pudding: Halves the movement speed of opposing player for 5 seconds
- Selesti Logo: Doubles the rate at which you can drop presents for 5 seconds
- Carrot: Doubles your movement speed for 5 seconds
- Beer: Reverses your movement controls for 5 seconds
It turns out that powerups were slightly more difficult to implement that we first thought.
Some things that were not initially considered
- As powerups sometimes need to affect the player that collects them and other times the opposing player, we need to take this into account when applying the effects.
- As each powerup is time limited, we need way to track which powerups a player currently had affecting them and how long for.
While these are pretty garden variety problems, the new snags were taking their toll after five hours of coding. I passed the problem to Shaun who eventually passed it back to me. In the end, we simply made a separate object that handled all the status effects by triggering a specific timer depending on which effect and which player. It was a dirty solution, but it worked – which was good enough for now!
How it all came together
Dirty fixes aside, things were coming together very nicely and it was very satisfying seeing Kate’s art overlaid onto the code we had produced.
The original idea was to have “60 second santa”, a red and blue santa competing to drop presents. This transformed into “Gift Delivery Corporation”, two rival companies delivering presents to try and win the yearly delivery contract. Somehow, this game ended up being Santa versus… Donald Trump. I’m pretty sure it was because Kate wanted to draw his “hair” flapping in the wind. Anyway, it was deemed that Donald Trump wouldn’t drop presents, so Kate had to finally hammer out some pixel grinches for him to drop.
All three of us worked together to source some sound effects from freesfx.co.uk and I contacted a guitar instructor on YouTube if he wouldn’t mind me using his metal version of a Christmas theme for the game music.