A Successful Scoping Down: Controlling Expectations in a Game Jam

One of the most common hurdles faced by game jams teams is the challenge of “scoping down” their expectations in the face of real-world limitations. Recently I was part of a game jam which successfully scoped down a project. This is a break-down of what happened, and what lessons I’ll be taking with me going forward.

The Scenario

I joined the Adventure Jam 2023 with no small amount of trepidation. I’d done solo game jams in the past but this was the first time I’d be teaming up with a group of strangers, and I didn’t know what to expect. What I found was a group of smart, accomplished game dev enthusiasts with big aspirations.

Before long, I was part of a team and we began to make plans for a fun, reasonably scoped point-and-click adventure. Then everything went sideways.

In the end, our team shrank from six to two people (myself and the artist ilikethepixies). This could easily have ended the whole thing, but we re-evaluated the situation, re-scoped, and delivered a fun, fully-playable game within the jam parameters.

If you’d like to see the finished product, please go give it a play: https://vampire-banana.itch.io/sprouts-in-the-dark I’m quite proud of both the work we put into it and the final result.

NOTE: While the team size dwindled, this is in no way a criticism of those who had to step aside. Game jams are by nature volunteer efforts, and real-life developments often interfere with the best laid plans. The other team members simply faced circumstances that didn’t allow them to set aside a chunk of their life in this particular two-week stretch of time.

The Initial Scope (aka: The Before Times)

Adventure Jam has no theme beyond making an adventure game. So we were free to design whatever we liked.

As a group we brainstormed the kind of games we enjoy, and the features we’d most like to see included. The result was a list of abstract concepts and specific details. (It included: cats, dinosaurs, space, spooky-cute design, and so on.) This list spanned genres and styles, but each item on it inspired us as designers.

Using those initial features, I came up with two concepts. From there, ilikethepixies provided thumbnail sketches, and the team as a whole chimed in on which concept would be easier to implement and the best mechanics to focus on.

This was immediately enlightening. Each team member effectively served as a creative department (albeit departments of one or two people) all of us getting a say in what would be doable and fun. This led to early buy-in, and also established the scope and skill levels of narrative and art departments.

At this early stage, one of the first members to join officially stepped aside due to life complications, and that left us with a team of five, still plenty to tackle the initial scope.

LESSON: It can be tempting to tamp down concepts out of scope concerns at the brainstorming stage, but that can backfire. Find the things that motivate the team, and then scale down from there, bringing in feedback and concerns from each department.

Putting Flesh on the Skeleton (aka: Design like Doctor Frankenstein)

With a scenario selected, I built a Miro flowchart to test the overall narrative and puzzle logic, then turned it over to the rest of the team. Based on their feedback I iterated the design to expand in some areas and pull back in others.

Calling these changes “iterations” may make them seem overly formal. It was more like: “People told me what they’d like to see; those suggestions were awesome; I changed the flowchart to make it better.” But ‘iterations’ is a lot easier to type out, so I’ll stick with that for the rest of this article.

At this point, it was all about refining the scope, and finding a balance of features and achievability that we could live with. This would prove critical later on. Because our initial aspirations were rooted in reality, when we needed to scope down, we never had to fight through excess details.

LESSON: Invest time in clearly defining the scope and goals of the project. This provides the groundwork for any pivots in scope later on.

Reality Sets In (aka: Houston, We Have a Problem)

Up to this point, all work was done pre-jam. (Unlike many game jams, the Adventure Jam allows for concepting and dialogue creation ahead of the actual jam period.) Once the actual jam started, it was time to kick production into high gear.

ilikethepixies’s artwork began to flow in, and the main character and settings moved from rough concept sketches toward adorably-polished final versions.

In addition, the composer began creating ambient noise and a list of sound effects to produce, while I built a Twine walk-through, allowing us to check narrative flow and puzzle logic.

Unfortunately, this is when the two-person programming department wasn’t able to continue with the project. And the clock was ticking.

LESSON: The sooner you identify a scope issue, the sooner you can remedy it.

Re-Evaluate and Re-Scope (aka: Panic and Lamentations)

The Adventure Jam allows for a two-week build time. At one week in we had terrific art, but our git repository held a ReadMe file and tumble weeds.

I checked in with the team on Discord, laying out where we were and re-examining our goals. With half of our work time gone, it was clear we couldn’t hit our anticipated scope. So the options were to quit or to scope down.

The two most complete elements at that time were the artwork (which was looking better every day) and the Twine walk-through. Seizing on those elements, we opted to switch our end state from a point-and-click adventure in Godot to a graphical text adventure in Twine.

I believe this achieved a few things:

First, it took all pressure off individual team members; if they had the spoons to contribute they still could, but no one was *depending* on them to do so. It meant that they could continue with the team, or stop work without feeling uncomfortable.

Secondly, by scoping down to only incorporate work that was already close to done, we took away pressure to go into new areas while also allowing us to put a few “dream features” in the pipeline. If there was time, we could implement them. If not, it wouldn’t break the final product.

Lastly, it allowed for easy backstops. While some sound design had been started, for example, we also built a list of CC0 sounds to use in case that aspect of the development fell off as well.

LESSON: Clear communication helped lay out the situation clearly, while the steps we’d taken earlier provided a stable base to pivot from.

Implementation (aka “Make it so.”)

With a new plan in hand, we could dive back into the work. ilikethepixies and I began producing as fast as we could. Unfortunately, the last of the other members had to step away from the jam for personal reasons. It was now officially just the two of us.

For many teams, this final hurdle would have proven disastrous. But because of the steps we’d taken to scope down and set up backstops, this didn’t cause a hitch in production.

LESSON: Thanks to the work we’d put in at the initial stages, the remaining team had a shared vision and an achievable roadmap to success. It may not have been the game we’d initially dreamed of, but it was a game, and it hit the criteria of the jam.

The Final Product

The final game ranked in the top third of the jam. I’m proud of the work we did on it, I’m proud of the way we were able to scope down the project without losing sight of the elements that inspired us, and I’m very happy my words get to hang out with ilikethepixies’s incredible artwork.

As mentioned, the final game can be played in-browser over at itch.io: https://vampire-banana.itch.io/sprouts-in-the-dark

Summary

Find elements that excite the team. This helps fight the urge to layer on more details, since what you love is already represented.

Keep initial scope under control. Once out of the brainstorming stage, we stayed in regular communication, checking our assumptions and making sure that one department wasn’t writing checks another department would have to cash.

Develop robust prototyping tools. This not only kept us in touch with the actual scope as the project fleshed out, it also ended up serving as unintended backup plan when we had to rescope.

Communication. Throughout the whole process, the more we talked the better things went. We each checked in with other departments regularly, and act quickly when issues were identified.

Find the Fun. Game jams are volunteer efforts where we can meet other awesome people and make cool things. Roll with the punches, adjust as needed, and view others with empathy.