I’m the director and co-founder of a mom-and-pop indie game studio called Finji (Overland, Night in the Woods), and today I am attempting to record the process we use for collaborative decision-making and planning. That is, how do we decide what we will do next on any given project? How do we get a bunch of different opinionated and intelligent people to cooperate and produce something greater than the sum of its parts? How do you retain individual creative satisfaction but also benefit from the input of your brilliant collaborators? How do you take abstract principles like “putting the project first” and turn that into something concrete you can apply?

Disclaimer Time

First, the process we’re about to outline is one that we’ve been using, formally and informally, with our internal and external game development teams, for maybe two years now. So, what follows is not just theory, at least for us — this is practice, and we’ve been happy with the results so far. Thus, what follows.

Second, I’m not talking about basic production and scheduling practice, which I’ve written a little bit about elsewhere. Instead, please treat this article as a kind of a pitch for an alternative to toxic argument culture but also an alternative to things like “only say yes” “brainstorming” “sessions” that are often proposed as the obvious “good” alternative to argument culture. The idea that intelligent critique doesn’t have a place in a design discussion is as absurd as the idea that survival of the fittest is a good way of running (more like ruining lol) (sorry) (sorry) your team.

Third, this process is unequivocally not something that I invented. Just like our games it was the result of a kind of informal collaborative process with a lot of input from a lot of lovely brilliant folks — my Finji partner Rebekah, our art director Heather Penn, NITW team, and more. This was an exploratory process that grew over time, and is mostly practiced informally by all of us, we don’t have like a rigid checklist sitting around for this or whatever. Rebekah outlined a lot of this in her GDC talk this year too. A lot of this article is just revisiting and expanding on those ideas, with the added benefit of not having shipped NITW last week. This process sort of grew out of this process, if that’s even possible. Or maybe that’s the only way it can happen.

Fourth, probably someone else smarter and more qualified than us has already outlined a better approach that we just haven’t found yet. YMMV etc. And finally, in the spirit of every design text that actually has any value, I’m going to do my level best to adhere to the design rules we’re pitching here. This way the article itself can be an example of whether or not this process has any value.

Ok, let’s do this.

Step 1: Make a Plan

Usually a good plan starts with a good problem. I know, I’m probably blowing your mind right now but bear with me. On your project it might be that players aren’t having enough fun on level 7, or that your QA department are grumpy all the time, or that your logo still sucks, etc. Gasp!

But ok so, for the purposes of things, I’m going to define Good Problems as problems that:

These sound over-obvious but they’re also very easy to overlook, especially in the middle of a long and difficult project. That last one is a real kicker, because it requires a level of understanding that most teams making most things just won’t have until quite late in the project. Until then, just do your best.

Anyways, so let’s say that we think we’ve identified a good problem, and we’re working on a plan to fix it. It’s important to understand that at this stage, the plan can be absolutely terrible, completely ludicrous, and otherwise impossible, as long as it addresses the needs of the problem we’re trying to solve. The clunky-but-accurate term intermediate impossible is the best I’ve found to describe the inherent nature of these plans.

Of course, it’s fine if the plan is totally amazing in every regard too. I mean that is always convenient. Impossible, but convenient. This step of the process is primarily about having any plan at all, not magically having a perfect plan immediately. For example, let’s say that you know you want adventurers to be able to travel over this scenic canyon in your game. You don’t know yet if that will be achieved by running across a bridge, or riding a griffon, or using a teleport spell, etc. But you know they need to be able to cross.

The initial plan might be to simply link the two areas using a long hot-pink rectangular box. This is not an acceptable solution in the long-term, obviously, but it provides a starting point for talking about how to address the problem of linking these two game areas. This is a perfect intermediate impossible, and a great place to start this discussion, and the rest of this article is about how and why that’s true.

Note: sometimes the problem appears after the plan, which is fine, as long as you’re honest about the problem being a good one. For example, Overland’s audio director Jocelyn Reyes recently proposed that we include a new type of environmental hazard in an upcoming area of the game. This plan started because it just seemed like a cool idea, but we were able to also identify that it would address a major problem we had, which is that we didn’t have any unique environmental features in that area yet. So our hypothetical bridge plan here could easily start from “gosh we don’t have any bridges, a bridge would be neat” only to realize “oh, that would fix our crappy canyon problem. Hmm”

Step 2: Show the Plan

Ok, so let’s say you’ve been thinking about this “link two game areas” problem for a while, and you’re still not sure what the best thing to do is, above and beyond a pretty convincing argument that players need to be able to cross this canyon in some way. Maybe you’ve even ruled out a couple of options, or think that a bridge might be the best option. Either way it’s time to show your plan to your collaborators.

This step can be scary, especially at first. What if your team doesn’t like your plan? What if your cool idea gets shot down? And this is a chicken-and-egg problem in a lot of ways. The point of this process is actually to completely avoid these fears, but until you’ve been doing the process for a while, these worries will still be hanging around. Until then, just do your best.

So ok, you’re about to explain to your team that you need to add a big garish pink box over this scenic canyon that your collaborator worked on for two weeks. What does that look like in practice?

Step 2a: Show the Good Problem

Hey team, so I’ve been playing our alpha a bunch, and the pacing gets really weird around the canyon. To get from Area A to Area B, you have to run all the way back around this region here, and it feels like busywork. But the canyon itself is awesome, obviously. And Area A and Area B are also great. I just want to fix this weird pacing thing. Here, watch how flat it is if I try to run around it right now. (Bonus points here for showing a concrete example, and not an abstract, unsubstantiated theory)

Step 2b: Show Your Plan

Ok so keep in mind that I’m not actually proposing that we put a giant magenta box into this excellent canyon. However, a giant magenta bridge would allow players to go directly to Area B without the pacing problem I just illustrated. Watch this (runs directly across bridge in hacky prototype mode). Not bad right??

Step 2c: Explain the Upsides

So obviously the main upside is you can avoid that whole area with the bad pacing if we do this. It’s also the simplest plan I could think of. The other ideas I had for addressing the pacing are a lot more complicated: it involves adding a whole new Area C in between A and B to provide some activities on the journey, or else adding a new ability set which is going to change navigation for the rest of the game and put too much burden on the UI. But we can talk about those if one of those stands out for some reason. A bridge is also a chance to show more of the architecture from Area A, and we could also reintroduce that intro character here also. Plus landmarks are almost always valuable, and this doesn’t seem to be an exception yet.

Step 2d: Explain the Downsides

The main downside is that we don’t have a bridge yet. We’ll need to design that whole thing. Which won’t be free. Also it’s going to mess up the line of sight for this key navigation point down in the canyon, which is used in like four other quests. Also there’s at least two tech issues that I’m not sure how to do here.

…and, scene!

So while we might not always pitch things quite this formally, even small informal pitches benefit a lot from hitting each of these general concerns. Constantly restating a problem might seem annoying after a while, but in my experience understanding a problem too well is sufficiently rare that I’m willing to take that risk. On everything. All the time. Plus, as Christopher Alexander says, a perfectly-defined problem is also by definition it’s own solution, so maybe the right thing to do will just pop up on its own here, especially later in the project.

So not to get too meta hopefully, but the upside to this entire step of the process is increasing the odds of having everyone be on the same page, not just in what you want to do but why you want to do it. This drastically increases the chances of these next crucial steps working out. If you don’t spend the time here, then the odds that your team will be talking past each other about completely different problems is too high, in our experience. The downside is that this does require some extra effort and due diligence before presenting, although that burden is localized to the team member most likely to be able to explain it well, which actually is an upside.

Step 3: Talk About the Plan

This step tends to work best if you wait until after your collaborator has finished their full pitch. There are some exceptions but generally we’ve found the best discussions happen once the pitch is done. So try not to interrupt unless maybe it’s going to save a ton of time, or there’s something you’re extremely confused about. This isn’t so much about avoiding critique or avoiding interruptions in and of themselves, but about making sure everyone understands the whole pitch before they start analyzing it. So I mean pitch how you want, but the problem we’re trying to solve here is getting everyone to understand the problem and the solution as fast as possible, which usually means trusting your team and letting them say their piece.

This step also tends to work best if you can focus on the same breakout the person presenting the idea used. Is the problem that we’re trying to fix actually framed correctly? In the case of the pink bridge, is it actually a pacing problem, or is there some other underlying issue that needs to be addressed (or both)? If there’s a problem with the problem, then we probably have to rethink our plan.

If we mostly agree that the problem description is accurate, is a bridge actually the optimal solution here? Maybe these other areas also have pacing problems that can’t be solved with the addition of a bridge, and a more general purpose plan is what is needed at this time. Maybe there’s plans for a flying ability that hasn’t been implemented yet and this needs to be sidelined for a bit.

If we mostly agree that some sort of bridge is the best option, did we miss any upsides? For example maybe the bridge could include this puzzle that had to be cut earlier, that would work much better here, and most of the work on it is done already. Also there is already some concept art for a bridge from pre-production that never got used.

Did we miss any obvious downsides? Maybe the canyon dividing the two areas is currently of great importance for the story, and bridging it undermines a big chunk of the narrative. Maybe the environment artist won’t be available again until it’s too late.

So, after this step, what we hopefully have is either: