GMTK Game Jam 2020 Retrospective: But First, Coffee
Two weeks ago my wife and I participated in the GMTK Game Jam 2020, a 48-hour online game jam where the goal was to develop a game that fit a particular theme announced at the start of the jam. Over 18,000 people signed up for the jam and in the end over 5,400 games were submitted, making it the largest online game jam ever.
A game jam is a great time to learn, gain experience building and releasing games, and just generally have some fun. I’ve personally only ever participated in one game jam before, the month long GitHub Game Off back in 2016 and I’ve learned so much about game development since then. Recently over the last couple of months I’ve been working on a game called Siren Song every day outside of work hours, so this was a great chance to switch it up and take a short break from that project, and at the same time potentially get some new ideas and a fresh perspective.
I expected it would also be a blast working on a game with my wife, as she’s not a developer or artist so it’s not something we typically do together (although she does a ton of playtesting for me and provides great feedback). In fact the Sunday of the jam was our 6-year wedding anniversary, so it was extra special to work on this project together!
Now that the jam has concluded and the results are available, it’s important to me to reflect on the project and see can be learned. This post will be an overview of the process we took to build the game, an evaluation of the results, and an evaluation of some key learnings we can take from the jam.
But first, here’s a look at what we actually built.
But First, Coffee
The game we made and submitted is called But First, Coffee, a silly and chaotic game where you play as an intern tasked with fetching coffee and baguettes for your coworkers.
The game starts simple where you just go out and fetch a single coffee, but quickly ramps in difficulty as you have to deal with larger orders. The key mechanic of the game is that you have to keep your tray balanced by individually controlling the character’s left and right arms to raise the tray, which gradually lowers over time as the intern gets tired. Add to that some distractions, such as a pager that startles the intern, some environmental silliness and a high stress level, and the fact that the controls for each arm periodically shuffle on you, and it makes for a ridiculous and challenging little game.
If you’re interested, you can play the game in your browser at teambanks.itch.io/but-first-coffee.
Timeline
Friday
- 8:00 PM - The theme is announced to be Out of Control with a short YouTube video on the GMTK channel.
- 8:05 PM - We have a very general idea of what the game is going to be.
- 8:15 PM - We’ve sketched out some rough designs for the look and feel of the game, and put together a long list of mechanics, hazards, themes, etc.
- 8:20 PM - Out of all the ideas we’ve sketched, we trim it down to a handful of core features and locked in the base scope of the game.
- 10:30 PM - A rough prototype of the game is playable to validate our ideas.
Saturday
- 1:00 PM - The core game implementation is complete, allowing us to move on to some of the other ideas we originally brainstormed as well as a few new ideas that came up during development.
- 9:00 PM - Essentially code complete on the gameplay and functionality.
Sunday
- 8:00 AM - Tutorial, instructions, dialog added.
- 12:00 PM - Added final sound effects, animations, and general polish.
- 1:00 PM - First build of the game is submitted, itch page written and screenshots/gifs added.
- 2:00 PM - Released a couple of bug fixes and called it complete a few hours early.
Putting together all the assets for our @itchio page for our #gmtkjam submission is as much work as the actual dev portion of the game jam. Here's the cover photo and some screenshots.
— Kyle Banks (@kylewbanks) July 12, 2020
41hrs down, 7 to go! https://t.co/Ib5C8R11xA#gamedev #madewithunity @chloe_ontheroad https://t.co/e97Q4SRH7a pic.twitter.com/tn5C3H0KHq
Results
Before getting into what we learned it’s perhaps important to take a look at how we did. Certainly everyone participates in a game jam for their own reasons, so it doesn’t always make sense to pay too much attention to the rankings. However for me personally I am at a place in my career as a software developer and as an amateur game developer where I do strive to be competitive, so the rankings are important to me personally.
The final results were announced this week and while we didn’t break the top 20, which are showcased in a special “Best Of” YouTube video on the GMTK channel, we are still quite pleased with our results:
I can’t say I’ve ever been happy with coming in 500th or 600th place at something, but given that there were over 5,400 games submitted this puts us in the 88th - 90th percentile in the Original, Overall and Fun categories, while we’re a little lower on the Presentation category. I’m personally pleased with that outcome, though it’s something I’ll certainly be looking to improve on in the future.
More important perhaps than the rankings were the written reviews we received, which were overall quite positive and we really loved reading them. Here are a few of our favorites:
In addition to the kind words, plenty of reviews also contained helpful and critical feedback that would be invaluable for us if we were to consider releasing this as a real game, so I suppose that can be chalked up as the first learning of the jam. And with that said, let’s take a look at what we learned.
Learnings - What Went Well
First I’d like to reflect on what went well with our game, at least in my opinion.
Moving Quick
As you can see from the timeline above, we moved quite quick once the jam started. I mentioned that my wife and I haven’t worked on a game together before, but we make a strong team together in general. We decided before the jam started that we weren’t going to get bogged down on the idea and instead wanted to have the concept decided on in the first hour. In fact, we pretty much immediately settled on an idea of playing as someone frantically trying to get to work within the first couple of minutes, and about 20 minutes later that had evolved into the final idea of doing a coffee run.
By being decisive on the idea we didn’t allow ourselves to doubt it or overthink things, and as we saw on some Twitter threads going on at the time a lot of people really seemed to spend too much time (in our opinion) on this step of the project. The way we looked at it was, it’s a 48 hour jam so not only is each hour important, but in the grand scheme of things if you don’t end up liking the final project it’s not really that big of a deal, so what’s the point in trying to come up with the perfect idea?
This also meant we were able to get a rough playable prototype on the first night, meaning we could sleep on it and scrap the idea Saturday if we woke up and really hated it, and otherwise all of Saturday could be spent fleshing out the mechanics and gameplay.
Brainstorming and Scoping
My day job involves leading a software team, and one of the things I stress to my team is the importance of delivering the smallest possible pieces of value. This takes the form of MVPs or Minimum Viable Products, where the idea is to trim down a feature to it’s absolute barest form, delivering that (usually to a alpha or beta group), and then rapidly iterating on it by incorporating your original vision with the feedback received from the users.
By developing software this way you don’t wind up waiting until you have everything fully developed to find out that your ideas aren’t resonating with your users, or that critical assumptions you made were actually incorrect. A six month project turns into a dozen two week projects, where you’re constantly iterating and receiving feedback on your product as you go.
So what does this have to do with our silly coffee game? Well, we took this idea and incorporated it into the way we scoped the game. In the timeline above I mentioned that we sketched out some ideas and then trimmed that down to a few core mechanics. We actually wrote and drew about 15-20 different ideas that we liked - hazards, gameplay, inputs, concepts, etc. - and then decided on the best and most central 3-5 of those that would make the basis of the game, the minimum viable product. We knew that if we could prototype these handful of mechanics that we’d have a playable game and we’d be able to tell if it was fun without having spent too much time on it. From there we could incorporate some of the remaining ideas or, more likely, bring in fresh new ideas that came out of that simple prototype.
This process worked really well, and plenty of those 15-20 ideas did end up in the final game as we had the time to add them in, but we also had time to introduce new ideas that came out naturally as part of the prototyping process. Additionally, had the game wound up being more complex or time consuming to develop than originally imagined, we at least had a minimal game that could be submitted from those 3-5 ideas we originally developed.
Simple Models
This one’s a little weird as we scored lowest in the Presentation category, but I still think it holds true. I’m not an artist and have a much stronger technical background, so the artwork for games is always the most challenging part for me. By keeping the models very simple (the characters are just three out-of-the-box capsule meshes) it actually made it much easier for me to make them more expressive than I would have been able to do with more complex models, especially in a 48-hour jam.
Each character has a set of animations, whether it’s the main character with the level complete and level failed animations, the band members each playing their own instruments, the volleyball players throwing around a ball, or the baristas running around their coffee carts. There’s no way I could have made even a quarter of those animation sets in the alloted time had I needed to rig more complex models.
By keeping the characters simple I was able to use the basic shape and animation tools available in any game engine (Unity in this case) but still make them quite expressive.
Leaning into the Silliness
Quirky and rather ridiculous animations, silly dialog, fun and upbeat music all came together really well on this game. One of the things we learned is that the rather punishing gameplay and the simplistic graphics were really overcome by making the game silly and fun.
One of my favorite parts of the game is the animation when you complete a level. Your character is so overjoyed having completed the order that they throw their arms up in the air and let the tray and all it’s contents go flying.
It completely destroys the order you worked so hard to bring back to the office, but it’s just so fun when coupled with the music and sound effects, and people noticed!
It’s such a small thing, but when combined with all the others like the band playing the background music, the crying animation when you lose, the silly dialog… it all combines to make a pretty fun package. Of the ten written reviews we received for the game, six of them made mention to the game being funny, silly, or humorous, so I think it was well worth adding those touches.
Learnings - Where to Improve
Feedback
As I mentioned in the results section, we received really valuable feedback throughout the review period. I think what made this feedback even more interesting is that it primarily came from other developers in the game jam, with varied game development experience. That’s a pretty unique demographic reviewing your game, so I definitely think that’s somewhat of a benefit to participating in game jams that I hadn’t quite realized before.
This process also opened my eyes to a more transparent game development process which would help get early feedback from potential players, tying into my comments on MVP-style development in the Brainstorming and Scoping section above. Rather than worrying about having a really polished game before getting it into the hands of folks outside my small circle of friends and family, I’m definitely seeing the value of just getting your game out there for (more critical) strangers to give you feedback.
“Marketing”
It’s perhaps a little silly to talk about marketing for a game made in 48-hours, or for a game jam game in general, but I do think this is an area where I need to take a serious look if I ever plan to release a commercially viable game. Our “marketing” plan was little more than to build the game, tweet about it a couple times to our combined barely 400 Twitter followers, and just hope for the best.
If you build it, they will come, right?
Looking at the #gmtkjam hashtag over the course of the jam weekend and the week long voting period afterwards, it was clear that some people have a much better grasp of this than we do. There were tweets with several hundred likes, and these very clearly translated into ratings during the voting period. We did receive slightly more than the average and median numbers of votes, but I don’t think that can be attributed to more than just luck of the “random game” button on itch.io.
It’s tremendously difficult to stand out in a crowd of 5400 games, but that’s the reality of the marketplace for games launching on Steam, Nintendo’s eShop, the mobile app stores and the like. This is something I’m definitely going to need to improve on, so it’s going to be an area of focus going forward.
Wrapping Up
Overall we had an absolute blast participating in the jam, and we’ll be on the lookout for more jams to participate in in the future. It’s great to take a break from your core project and it really opened my eyes to some key areas of improvement, and was just generally a lot of fun to build a game with such constraints, and play and analyze the games made by so many creative developers.