Surviving a Game Hackathon Like the 48-Hour Global Game Jam
If we haven’t met yet, hello. Let me introduce myself. I’m Curtis Cummings, and I have been a video game developer and software engineer for a handful of years now. Once upon a time, I set upon a quest to be the best game developer like no one ever was.
That’s when I learned about game jams. A game jam is a hackathon of varying length in which participants must conceive of and create a game based on a theme, before the time runs out.
My first experience in game jams was at the 2014 Global Game Jam with some of my friends. Now, I’ve been making games with that group of friends for almost 5 years at Parallax Visions. That year, we created Last Man Alive, a game where you’re the last living person aboard the second International Space Station when you witness the Earth’s destruction due to thermonuclear war.
I’m very proud of this game, despite how shoddily it was made. This shabby MVP captured the theme of that year’s jam well, and it demonstrates the smart design that allowed us to make a game experience in such a short time frame.
I’ve participated every year since, and I’m proud to be able to host a jam site this year at Revelry HQ in New Orleans. Here, I’ll share the wisdom and insights that I’ve gleaned over these years to help you survive a 48 hour game hackathon like the Global Game Jam.
It’s a 48 Hour Hackathon. SLEEP and DRINK WATER.
Yeah, we have 48 hours to work on this. But I can’t stress enough that you do not have to, and for that matter probably shouldn’t, use all 48 hours working on the game.
As a human being, you will need rest and food to make sure your body is capable of working on something as complex as a game. Please, please, please, please, if you take nothing else from my advice here, remember to take care of the meat sack in your skull. Don’t push yourself to exhaustion and dehydration.
A game jam is an event where people come together for the joy of making games, not the horrible stress that comes along with it.
Don’t overthink the theme.
I would qualify a good jam game as one that “oozes” theme, but I do think that advice can lead you to overthink things.
Our theme prompt for Last Man Alive was “What do we do now?” We had a quick brainstorm, and the first idea we had was to have a selection of actions for the player to take. OK, that satisfies “What do we do” but what about the “now?” piece of it?
To address the prompt completely, we decided that our need to choose an action should be based off some kind of external event. Eventually, we came up with this backstory:
Aboard the 2nd International Space station, you witness the Earth’s destruction due to nuclear war. The resulting shockwave knocks off the oxygen purification system aboard the station and you, the player, have 15 minutes to explore the station and reminisce about the people you once shared the station with.
Basically, we used the exact words in the prompt and we made a game out of it. That’s it! And that’s exactly right. We followed our gut. Pick something, and go with it. It’s not going to go out to market in 2 days, and you’re not trying to sell it or anything (unless you really like it and you want to sell it, but that can all come later).
Interpret the theme in a way that speaks to you and try and make that, no matter how silly of an idea it may be. Have fun with it.
Limit yourself. It helps boost creativity.
Making something around a core theme in a game jam forces you into a very helpful place. Limitations foster creativity.
If you had the freedom to come up with anything, you’d get stuck deciding on specific features to add (and keep adding). In order to be effective creating your jam game, you need to specify why you want to add something to the game.
A story I like to tell to illustrate this point comes from Japan. When game designer Hideo Kojima and his team were working on the original Metal Gear for the MSX2 back in the 80s, they encountered some technical limitations.
They had originally planned a military action game where the player shoots at enemies on screen with an equipped weapon. However, since the MSX2 could only draw 32 sprites on screen at once. This was a problem, because you wouldn’t be able to draw a lot of bullets if you wanted many characters on the screen. (That’s the condensed version. For the full story, see Kojima’s GDC 2009 keynote.)
Because of this limitation, Kojima pivoted from an active shooter game to more of a game of stealth. In 1987 Konami released Metal Gear, the world’s first stealth game which became an international sensation in the years to follow. (And it’s my favorite game franchise).
Grammar for Game Design
A trick I picked up from some book I read is to think of things in your game as parts of grammar.
In English, a complete thought or sentence has two main parts: a subject and a predicate. The subject is the actor and the predicate is some sort of action. For instance, the sentence “Mike ran.” Here, we can easily identify the subject, Mike; and the predicate, or the action, ran. You can use this framework to describe mechanics in a game.
In a game, we can have things that are nouns and things that are verbs. Nouns describe individual units in the game. In Super Mario Brothers, some nouns would be: Mario, Goombas, blocks, coins, mushrooms. There are some verbs which describe actions performed by those nouns. Our subjects jump, run, and collide.
If you put these two together, you can form sentences that describe the game’s mechanics. So, we have Mario runs or Mario jumps. And just as we can make phrases and clauses in English, so too can we in this system of describing game mechanics.
Mario jumps on a goomba.
Abstracting your mechanics like this not only makes it clear what each piece in the game is capable of, but it also establishes a vocabulary that you can share with your team. Something that we at Revelry have found invaluable.
Break things down to the core
Something that will bring every jam game down is letting scope get out of hand. It’s easy to have an idea and think about how great it would be to have that in the game, however, these things take time to implement.
Since our time is limited during this hackathon, it’s helpful to keep the core of the game at the forefront of your mind. Using Super Mario Brothers as an example again, let’s try and think about which mechanics would describe the core of the gameplay. Super Mario Bros is a platforming game, which means that the levels are obstacle courses of platforms. The player has to navigate each platform to get to the end. And the core of that experience, as I’d describe it, includes player movement, the ability to jump, and obstacles or enemies to avoid.
Notice that I didn’t mention coins, score, the timer, defeating enemies, power ups, warp zones, secret areas, destructible blocks, water levels, or bosses. Although those are all features that enhance the core experience of the game, they are not the bones of the experience.
I can’t stress enough the importance of maintaining small scope. It’s going to be easy, and exciting, to think of more things that you can add to the game. But it will take some hard work to get that extra functionality into the game, and that’s not always apparent when you set about thinking up these great ideas.
Don’t let cool mechanics distract you from working on what needsto be there for your game to work.
Plan your MVP
Everything I’ve just described – nouns and verbs, core mechanics of the game, don’t get too deep into features: This is how you create what’s called an MVP, or a Minimum Viable Product.
Since you know how to describe parts of your game in a way that makes sense, and you know the core of what you’re trying to make, the next step is to plan the most bare bones version of the game. Ideally, you will get the game to this MVP state before the jam ends.
“What’s the minimum number of nouns and verbs in your gameplay to make the story viable?” Once you get this done, you can spend the rest of your time testing and polishing your product.
Do this before going the extra mile to add more features. This is crucial, because getting somewhere is much more difficult when you don’t know where that somewhere actually is. When you and your team know what “done” looks like, it becomes much easier to find the path there.
When developing game mechanics, chances are you aren’t going to have things tuned perfectly the first go around. When you are able to playtest the game, think about how the tuning of the mechanics feels and how it would feel if it were different.
After realizing an idea, you want to try a few variations on it to make sure that you’re satisfied before moving on and forgetting about it. Iteration is the core of most commercial game development, because design philosophies and priorities will change throughout a project. Even on a much smaller scale, this is a useful paradigm.
Pretty self-explanatory really. OR SO YOU WOULD THINK.
When you’re working hard on a project, it’s easy to get caught up in the moment and get flustered about progress or about some small semantic. Working on a team brings about some creative differences. Don’t let it lead to the Thirty Years’ War. In the immortal words of Douglas Adams, “DON’T PANIC.” Everyone at the jam wants to have fun and celebrate how great games can be.
Would you like to join us? You can come to the game jam with ideas, skills, enthusiasm, or only one of the above. You can build any type of game during the game jam, not only video games.
Select “Join This Jam Site” and we’ll see you January 25-27 2019!
At Revelry, we guide Design Thinking for Product Development.
We also provide platform technology to help your business scale quickly.
Find out more: