Last month, I decided to enter my first ever GameJam — the Gamemaker’s Toolkit Game Jam 2020 hosted by itch.io. If you aren’t familiar with GMTK, it’s a Youtube channel, created by (mostly) one bloke who has some interesting insights into how games are made. You can find his youtube channel here. It turns out he has quite the following; the GMTK game jam is the biggest that itch.io has ever hosted and it continues to grow, year-on-year.
When I was about 18 or so, I really saw myself in game development. It’s never actually happened! I’ve written a couple of smaller games, but always my interests and commitments led me elsewhere. Like most other folks I know, I’ve been locked down due to the 2020 global pandemic and so I had to find some indoor projects to fill my time. I figured if not now, then when. So just like with my first demoscene entry, I committed myself to entering and completing a game within 48 hours!
Rules of the game
Most game jams have a time limit. This jam started on the Friday at 8pm and finished on the Sunday at 8pm. You are expected to write the majority of your code during the jam, though this is somewhat hard to enforce. A number of tools are recommended, such as Unity(of course!), Gamemaker Studio and Stencyl, among others. WebGL and HTML based games are also accepted. So long as the game runs on Windows it counts — so no mobile, VR or Linux games (‘boo!’ to that last one!).
It’s fine to work on your own, or in a team. I had some help from my partner in the early stages (see next section) but I was on my own for coding and any assets I would need.
There is also a theme, which is announced right at the start of the jam. Typically, GMTK comes up with interesting themes that are simple, but make you think about design. Usually, it’s just a few words. This year, it was ‘Out of Control’. Quite appropriate don’t you think?
Each game is voted for by the public. The host of GMTK plays the top 100 of these games, selecting 20 for individual praise. The games are judged on presentation, fun and how well they fit the theme.
I decided I’d work with pygame for my entry. I was pretty sure I could develop on my Linux laptop, creating a Windows build on a virtual machine, possibly testing on an actual Windows box if I had the time. I felt that although a pygame entry would be 2D and not as flash as some of the Unity entries, I’d still be able to engage in the design of a game; coming up with ideas and quickly testing them out. I wasn’t aiming for something polished, but something realised.
This would be my first tip to anyone entering a game-jam: have some realistic expectations. If you’ve never developed a game or are an ace with Unity or similar, it’s unlikely you’ll end up with something like Pink River in 48 hours. But so long as you are ok with that, you can still have a lot of fun, and learn a fair bit.
I’d watched the game-jam hints video posted on the GMTK channel; some of the developer tips were quite good. My main take-away was how to divide up your time. It was suggested that the first evening should be brainstorming away from a computer. Get your ideas down and some sketches drawn up. Don’t code everything but have a plan. The first day should end with the basic core of your idea and a working build. The last day should be all about refinements and extras that make the game really shine. I felt this was good advice, so I went with that.
My partner has some experience in coming up with plans and working one’s creativity. She suggested I go broad to begin with, not sink into details about the first idea that comes into my head. Indeed, we started not thinking about games at all, but what the phrase ‘out-of-control’ meant. Thinking widely, I took a pad and a pen and began to scribble ideas. I talked them over with my partner who came up with more questions for me to consider. This helped drive the imagination forward. It’s great if you have someone to bounce ideas off.
There was a discord channel setup especially for the jam so folks could talk through ideas, share progress images and ask for help. I nipped in now and then but found it quite noisy and hard to navigate due to there being so many people. I was pretty fortunate I had someone around in meat-space I could bounce ideas off.
After an hour or so of deliberately not focusing on any idea, I’d come up with four distinct ideas around what ‘out-of-control’ meant. At this point I’d not thought about games much at all. The next step was to remove the least compelling idea and move into the other three. A bit more time spent on these ideas and a second one was removed. Around this time I started to think about games. How would I bring this idea to fruition and how would it be fun?
With a couple of ideas that seemed like strong contenders I decided to settle on one and move forward with it, finally putting a rough plan together. How would the game be coded up in the broad-strokes. With all that in mind, I went to bed at a sensible time! One developer tip I heard was to look after yourself. I decided I’d take that to heart and not pull any silly all-nighters (I’m too old for that anyway!)
Coding it all up
I’d decided to try and make a game inspired by Conway’s Game of Life. My thinking was that simple systems can get out of hand, just as you are trying to bend them to your will. Can you achieve a stable or steady state? I thought about a setting and went with lights, or fires. The goal of the game is to keep the light burning for as long you can. Fires near each other will spread faster, and if you set fire to a special square, things will explode. Some areas have more fuel than others. You can only place fires where you can see, and you only have so many fire-starters. How long can you last?
This seemed to fit the theme I thought. It’s also relatively easy to program in a short time. I set to with Pygame, putting in the normal event loop structure, a class to hold the world state and some animation classes for the fire. The first build used boxes that changed their colour depending on whether or not they were on fire, burned out or untouched. The visibility of each tile is determined by it’s Manhatten distance from the nearest fire.
After the first day, I got the basics in place. The game seemed to fall between one of two states: either the fire would not spread at all and you’d run out of fire-starters, or it would all explode far too quickly. I decided I’d spend the following day tweaking the system, adding some simple animations, some status indicators and some game start and end states.
By the middle of the last day, these things were in place. I now needed to get a build together for windows. Using pyinstaller seemed like a good shout. I had a virtual Windows 7 machine available through Virtualbox so I copied the game over and built an exe there. However, my first attempt didn’t work. One of the python libraries I’d used needed to be built from source. I was attempting to use a library to generate Perlin noise for the terrain, however there was no time to get visual studio installed just for this, so off I went to hunt for an alternative.
With a working build, I decided the last thing I needed to do was a test on Windows 10, with no python installed of any kind, just to make sure. Thankfully, I had access to such a machine. The program worked just fine. Now that I had a working build, I could add some refinements. I played around with the game mechanics a little more, added some basic graphics, game-states and once that was done, I decided to call it a day. I had about 6 hours left on the clock but it felt right to submit a build and see what would happen.
You can download my game, Slow Burn, on my itch.io webpage. It’s not great but then it doesn’t need to be for a jam. It’ll provide you with a few minutes of fun at the very least.
What did I learn?
Overall, I came in at 4271 out of 5411. Not too bad for my first ever GameJam I suppose. I was mostly pleased with the ‘originality’ score of 3083. I think I managed to capture the concept of ‘out-of-control’ even though the game doesn’t look particularly good. A few folks saw it as a ‘reverse mine-sweeper’ which I can sort of see. I’ll take that as compliment as folks love minesweeper! :)
So what did I learn then? Well firstly, I think the advice I was given was spot on! Dividing up your time in the way I did seemed to really work. Taking a whole evening just to brainstorm, doodle, discuss and play around away from the keyboard was a great idea!
Secondly, I think I was both right and wrong to choose PyGame. Wrong, because it’s not as powerful as something like Unity; you can do a lot more in less time in Unity. However, I was right to pick PyGame because it’s what I know. The last thing you want to do in a GameJam is learn another set of libraries, tools or programming languages. I did think about using something like godot which I probably could have learned but I decided against. Had I spent less time on coding though, I’d have needed to get into the art and sound which is much more tricky for me.
Related to that, I think a lot of jammers used asset packs and royalty-free music. This is something I’ve never done, and I think if I did another jam, I’d definitely get some assets collected. I think the idea of a jam is to play around with putting existing pieces together, whether they be code snippets, sprites or music.
Fourthly, being in a team might be an advantage. I suspect many of the better entries were made by teams. I found the discord channel to be a little too noisy and I don’t think I’d enjoy teaming up with someone random I’ve never met. Nevertheless, it’s nice to know the option was there.
Related to the above, I do wonder what the demographics of this GameJam were. Taking two whole days off to develop a game is quite an ask for someone with responsibilities. I certainly didn’t pull any all-nighters or use up all the time I had in a fury of typing. I bet there were a few teams who really burnt the midnight oil. I also suspect a few teams were using the jam to promote their studios or games, though I have no hard evidence for that.
Fifthly, I found the time-frame really useful. At one point on the Saturday night, I almost stopped because I felt the game wasn’t that great but then I realised it was more important to complete something and submit, even if I felt it was a bit rubbish, rather than just stop. I’m really glad I carried on and did that. I think many nerds can relate to this — we all have so many unfinished projects. After a time, they begin to weigh a little heavy. Having a clear-cut deadline really helps to focus the mind. Once it’s finished you have that lovely feeling of having completed something, with the refreshing feeling of being able to move on.
Finally, I think the way we approached the creative first part of the jam really worked! Going broad with many ideas, refining, rejecting and not tying into game tropes too early worked quite well. I suspect there are many books and articles on the subject of creativity — I might have a read in the future.
I’d recommend a gamejam to anyone who has ever wanted to make a game. I’m really glad I took part and I look forward to the next one.