Hello!

During the quarantine, I joined a couple of game jams: the Quarantine Jam and the 46th edition of Ludum Dare. They were great experiences: I never participated in a game jam before. We shipped both of our games to a respectable level of polish and received encouraging evaluations.

I joined the jams to practice some game design, but, as I assembled the teams to be quite large, I felt I was supposed to lead the team that needed to ship as complete of a game as we could. Moreover, both the jams went fully remote because of the COVID-19 outbreak: a fluid communication flow was essential.

The first jam went quite well in terms of iteration and results. The game was not that complex, so we had time to refine its mechanics. The Quarantine Jam allowed me to groom the whole process and build a better “framework” for the Ludum Dare game jam we wanted to participate in.

My priority was to allow the team to sleep at night.

We knew game jams often are like marathons and time is never enough, but as part of my teammates had a full-time job, we couldn’t afford to destroy ourselves over the weekend. Furthermore, we wanted to ensure a sufficient level of polish: we agreed to favour a tiny enjoyable game over a bigger, buggy one. Secondly, we desired every team member to be part of the process, involved and, at least partially, satisfied with the project concept. Then, as I wanted to expose the team to some flavour of a real development cycle, we had a planning/pre-production moment, a production one, and a polishing one.

Let’s breakdown the process, assuming we joined a 72 hours jam. Let’s say we plan to sleep an average of 6 hours and that we need about 2 hours a day to eat and satisfy natural needs like, I dunno, going to WC, smoking, having snacks, breaks, phone calls etc..

Around 54 hours left. We are screwed, aren’t we?
Not at all.

The secret, like in professional game development is in minimizing the waste. How?

Let’s explore the tools and the process we followed during Ludum Dare #46.

48 hours before the game jam: from a group of people to a team
The team meets to introduce each other and talks about what everyone wants to achieve during the event. Then discusses tools and technologies to adopt, to fill any knowledge gap and get prepared the right way. It puts the agreements on a google document, then explores the production framework to apply. It may seem a little “over-structuring practice”, but humans work better when they can rely on a smart set of rules.

The pre-meeting ends with a set of – written – decisions:

It will be quite a long, comprehensive file. The team is not going to need nor use every entry of the list. It is also built to offer solutions to issues that didn’t arise yet.

The beginning: theme reveal
Almost every game jam starts with a theme reveal: a word or a sentence that your game must communicate. The team needs to build a project around it: brainstorming is the best method to explore ideas, to kickstart the creativity and set a direction for the team. No wrong opinions, no stupid ones: everything can become useful to refine or create an idea. We used Google Jamboard: a virtual whiteboard tool that provides everything you may need. It could take a day, but as we said earlier: timeboxing is essential. I suggest limiting it to one hour, then take another hour to groom the outcome and define a path for the team.

Every team member must understand the game and its features; it’s vital for the success of the project. It would be optimal to visually mockup the gameplay in one or more simple concept sketches. Those will define a baseline for confrontation and planning. Once the game concept is shaped, understandable, and the team feels it can be achieved, programmers and designers may want to explore the features and the mechanics they desire to implement and write them down. Concurrently, the art team might explore the visuals and build a references/sketches document to be used as an art bible.

Random brainstorming whiteboard

Prepare for success: the kick-off meeting
Like in professional game development, game jam teams require to establish a Minimum Viable Product for their game. The team must meet again and face all the decisions taken in terms of features and visuals, prioritize everything and take action. There’s a formal prioritization method called MoSCoW Analysis: a team distributes a list of features in four categories (Must, Should, Could, Won’t have). A one-hour timebox will make the team focus on what is important. In my experience, I found that the teams are more willing to accept a less tyrannical tone when choosing features they may love. I suggest a more comfortable “Iteration 1/2/3/+” scheme: it even raises determination with progressive, well-defined goals. This way the team will focus on what is really needed in the game by placing the features in Iteration 1, then plan the others in case there will be time to make them real. The features may come in a large shape, the team may want to break them down in smaller tasks to be handled more conveniently. This tastes agile, I love it: when you reach Iteration 1, build and release, then work on the next one. If the time falls short, polish the higher milestone and be proud of it.

The spreadsheet I use to apply the MoSCoW method.

Connecting the dots: execution
The team spent around three hours to prepare a game concept and a battle plan. At this point, we have a prioritized list of features, a game concept that is visually represented and a team aligned in terms of vision and work to do. According to the estimate we built earlier, there are circa 50 hours left to make the game: I bet that time will seem less insufficient once the team has defined “shippable project versions”. In the Scrum project management framework, part of the great Agile family, teams work by Sprints: time-boxes during which a potentially releasable increment is produced. While a game jam is not a great environment to set up fully implemented agile processes, sprints are a great tool to make people work autonomously. I’d suggest them to last four to six hours. At the start of each of them, the team has a brief planning meeting to last one hour max. That’s needed to pull features from the iteration board and put them on the preferred tracking tool (usually Trello or Excel) and if a sprint just ended, to review what rolled out. The team will develop new features and art, meet, inspect, confront, fix, re-plan and re-begin developing. Clarifications and task or feature-related conversations are meant to take place during the sprint: not during the review and planning meetings. The team will also have the chance to confront against time, to cut or re-treat features that are not crucial or possible to achieve by the end of the jam. Once the points in the first iteration of the plan are executed, the team will start attacking the second. On the other hand, if the jam is going to end in six or fewer hours, the team will stop executing and begin polishing the game. There will be final game balancing and tweaking to be tackled, art to be refined, tests to run, texts to be enhanced, and a myriad of tiny details to make the game look complete – including some promotional text, video and the game’s entry page on the official page of the event.

Time for your game to be played and evaluated! Don’t forget to play and judge the other entries: usually, your game gains visibility as the members of your team spend time on other ones!

The first prototype of SUPERHOT, realized for the 7 Day FPS Game Jam challenge

Summing up

What made this work for us?

I tried to assemble a framework that can be scaled in many ways: I wanted it to be a real development simulation and to provide a foundation for non-jam projects, at least in terms of events.

Such a structure may limit the fun and the spontaneity of the effort, but I can’t stop thinking that the project must be delivered in good shape; mostly because a large part of the usual attendees plays to build portfolio projects and enlarge their network.

I hope this will come handy for your next game jam and don’t hesitate in reaching out to me for feedback or further discussion!

Kudos to my friends Joel and Willy for their patient reviews.
Thanks all for your time,
G.