Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
This article exposes the way I use to manage game jams development cycles. The method takes from the most used project management frameworks.
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?
Adopting an iterative approach.
Timeboxing every meeting (define a maximum duration and respect it).
Building a transparent passive communication flow (aka write excellent documentation and make good use of tools).
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:
Game Engine (i.e. GameMaker, Godot, Construct, LOVE2D, Pico-8, Unity 3D, Unreal Engine 4, etc.)
Communication Tools (i.e. Google Docs, Trello, Discord etc.)
Development Tools (Wwise, FMOD, Houdini, Spine, etc.)
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
Meet with the whole team to introduce each other, define the boundaries and the technologies, agree on a development strategy.
Brainstorm your project according to the given theme.
Breakdown the project into a features list.
Prioritize the features of the project collaboratively.
Iterate on the game with 4 hours sprint, divided by one-hour max meetings to review and re-plan.
When the time remaining is below 6 to 8 hours – depending on the complexity of the project – stop executing and polish your last complete iteration to make your game shine.
Ship it!
What made this work for us?
Everybody in the team agreed on the framework.
The team lacked no roles, we ensured to be complete in every discipline.
Everyone accepted the responsibilities of their roles, i.e. programmers and artists submitted their ideas, but the designers took any final decision on the project.
We had a great, trusty atmosphere where difficulties and obstacles were brought up as they emerged.
No one in the team fell in love with his ideas over an acceptable level; the team was focused on the shared goal. Everyone was open to confrontation and discussion.
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.
Read more about:
Featured BlogsYou May Also Like
