The 2018 Game Maker’s Toolkit Jam starts tomorrow. So I thought I’d wind back the clock to July of 2017 when I took part in the first GMTK jam. I’d been anticipating the jam for some time. I’m a huge fan of Mark Brown’s YouTube series, so the chance to apply some of the theories outlined in his videos was an appealing prospect.
Game Maker's Toolkit Jam - 2017
The theme of the jam was “Dual Purpose Design“. I struggled a bit with this one because I was limited to my own art and coding abilities. I’m a designer by trade, but in my free time I like to try and improve my art and presentation skills, so that’s usually where I tend to focus my efforts. It’s also what I find most fun; something that is likely down to a lack of confidence in my own programming skills.
The problem however, was that the theme didn’t lend itself well to an aesthetic-first approach. So, I ditched my initial plans to create a detailed, pixel art project in favour of something I felt was mechanically “interesting”. The challenge was coming up with an interesting mechanic that I was able to develop in the time available within the scope of my own abilities.
From the moment the theme was announced, I knew I was going to make an action game. I felt like I was getting pretty good at making action prototypes, I just hadn’t had the chance to develop one to completion. I wanted to push myself to see if I could deliver a polished and complete, fast-paced action experience, regardless of theme. It just so happened that the theme played into that.
I knew that I wanted to tackle multiple AI types. AI has been a sticking point for me in past prototypes; hell, my first indie game doesn’t even have AI! Creating an enemy is easy, but multiple archetypes is a hurdle I often fall at. It just balloons the project size and increases the amount of testing time required.
I built grunt enemies as well as a boss character. This provided an escalation in difficulty and varied gameplay. This AI push genuinely increased my capacity to handle such things for future projects. I’ll take that as a win.
I also wanted to create multiple weapon types. And while an automatic pistol and shotgun were ready to go, there simply wasn’t enough time to include them (or rather, fix any bugs related to them). Shame. But at least the pistol was super satisfying to shoot! I’ve since added these debug weapons to the starting area in the version uploaded to itch.io. Neither the weapons nor AI played directly into the theme; that’s where the player came in.
My first feature was to have shooting slow the player’s movement speed. This would have players gain a slight speed increase when the fire button wasn’t held. The natural progression to this was to tie it into a reload system. Releasing the fire button would not only reload the player’s weapon, but also allow players to better evade enemies. This was a very basic form of dual purpose design, but it was a start, and an anchor point for my primary mechanic, “Juju”.
Juju was simply my name for “slow motion juice”. Once a player killed an enemy, the fallen foe would drop behind Juju gems. Should the player stop firing, the Juju gems would move towards the player’s location. This played well with the player’s speed increase; a valid (and perhaps accidental) use of dual purpose design. Players could then use Juju to activate slow motion.
I’ve gotten into a bad habit recently, where I find myself writing postmortems long after a game has been released. However, during and after game jams, I tend to take a lot of notes documenting my process and experiences. I mostly use these notes to keep track of what’s been completed, but they also come in handy at a later date to form the basis of a postmortem. So without further ado, here’s a breakdown of what I feel were my successes and failures…
What went wrong?
I originally had grand plans of meeting up with others to jam in meat space (and potentially meet some new people in the process). Unfortunately, I had a lot on my plate, given that I had just started a new job and had recently moved into a new apartment. I was living and working in a different end of the country than when the jam was originally announced, so I hadn’t allowed for time to settle in.
Aside from the various life complications, my productivity took a dive when I decided to upgrade from Construct 2 to Construct 3. I’d been putting off the upgrade since it was first announced. Construct 2 has always been my engine of choice, since discovering it in early 2013. But I was hesitant to move to the monthly payment model with the engine’s jump to the web platform. With Adobe Creative Cloud, Netflix, Amazon Prime, etc. I feel I’ve got enough “fun” subscriptions. However, the promise of new and shiny was too much; I caved, and subscribed to Construct 3 for the jam.
Don’t get me wrong, Construct 3 is great, but with it being web based, you’re at risk of a crash from both the editor and your web browser. And as it turns out, I lost a lot of work during the jam. So much so, that I had to reduce the scope of the game. I’d like to think that I’ve got my CTRL+S game down, but I couldn’t keep up with the crashes in the engine. They were relentless. And as many will point out, it’s a terrible idea to try a new engine in a game jam situation anyway – even if it was simply a new version. There are too many unknowns to handle in the time frame. If you’re going to do this, proceed with caution.
I applied the theme where I could, but my use of dual purpose design certainly wasn’t innovative. I feel that my fixation on wanting to make an action game and tackle AI was dictating my interpretation of “dual purpose design” rather than allowing me to experiment.
What went right?
I previously mentioned that one of my self imposed goals was to create multiple AI archetypes, but it wasn’t my only goal. I also wanted to create a game with multiple rooms or levels. Previously my game jams have mostly been single screen or infinitely scrolling. This time I wanted to make something that felt bigger, but stay within the scope of a 3 day jam.
This may not be “the point” of game jams, but one of my primary goals has always been to make something that looks visually appealing. And again, I really feel that I managed to craft a unique and cohesive aesthetic this time. The sprites were simple, but featured tight, responsive animations. And perhaps most importantly for me, I came up with a striking colour scheme that was not only quick to work with, but provided a lot of readability.
Despite the life and technical problems, I still managed to deliver a “complete” game. And a rather polished one at that. Mostly thanks to my familiarity with Construct’s tools, I was able to package the game with a custom loading screen, a basic front-end and a full game loop. This is something I have struggled with in the past, so I’m glad to have delivered this time.
I also spent a lot of time making what few mechanics I had feel good. I neatly married the sound effects to the screenshake and threw a lot of particles around the screen in reaction to player input. As a result I received a lot of positive feedback for the “game feel” or “juice” in the game.
Some choice quotes:
“this feels great” – Mark Brown, Game Maker’s Toolkit
“this is sweet” – Danny O’Dwyer, Noclip
It’s always nice to receive praise from those you look up to.
While I didn’t “win”, I was featured as an honourable mention in the jam’s wrap-up video. Which was nice, and to be honest, rather unexpected.
I knew I was never going to win per se, because I don’t feel that I stuck very closely to the theme. However, it’s humbling to be recognised against 770 other games. That’s crazy.
Bad Juju is at around 3:41. Enjoy the video!
If you’d like to play the latest version of Bad Juju, then check the banner below. You’ll notice that I’ve added some additional weapons at the start of the game. These aren’t particularly balanced, as I used them for testing, but I thought players might enjoy them. So please enjoy!
Best of luck to those of you participating in the 2018 Game Maker’s Toolkit Jam!