Collaborative Planning at Finji

A studio process for building better group confidence in outcomes.

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:

• Actually exist
• Actually make a thing worse
• Actually can be solved
• And are as accurately described as possible

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:

• a stronger pitch than we started with
• avoiding a mistake when a teammate catches a bad assumption
• an unchanged pitch, but a higher level of confidence from team vetting

So how exactly is this discussion different from the one that would happen as part of “argument culture”? What prevents participants from becoming overly emotional / combative / toxic? Maybe nothing. However, there are some factors that I think contribute to it generally producing much healthier discussions than argument culture does, while still maintaining some of the productivity of allowing critique to happen.

First, any discussion of any idea almost always entails restating and/or discussing exactly what it is we’re trying to solve. That might sound like a downside but it’s very much an upside in my experience. As long as this discussion is happening in good faith, then this provides a bigger base and better chance of shared understanding between participants, and helps avoid discussing solutions to problems that don’t even exist, which can be intensely stressful in and of itself. We believe that doing these steps in this order produces an environment in which all participants can be more confident that the thing they’re even bothering to talk about is useful or even necessary, which is great. Confidence in outcomes will always be higher when confidence in the discussion itself is higher.

Second, by pitching a big pink rectangle bridge, the conversation has a better chance of avoiding the swamp of architectural specifics when instead we are trying to focus on whether or not we want a bridge at all. That way when the discussion about bridge architecture does happen, there’s much higher confidence in that discussion, since we have good feels about the bridge itself. In other words, that bridge will have been crossed (sorry).

Third, once we establish the basic problem, the conversation tends to focus on addressing specific pros and cons tied to specific solutions. We’re not deciding whether or not the person pitching the bridge is smart. When we are talking about how we can optimize an idea together, we start to get a better understanding of how this idea relates to the rest of the game and the rest of the team. Maybe we also finally understand that greenlighting an idea is really always greenlighting several ideas. We start to understand that if we’re doing this right we’re all pitching the bridge together.

Fourth, I think it puts a lot of good, positive pressure on the person presenting the idea to value the solving of the root problem over any particular given solution. This is maybe the most important mindset you can have as an individual collaborator, and this process acknowledges this and even incentivizes this. It also requires it.

Steps 4 and 5: Test the Plan, Talk About the Test

The next step is to trust but verify. In this scenario, it might mean making a version of the pink-bridge that everyone else on the team can play too, that includes some of the revisions and feedback from the discussion, and listening to any new ideas or concerns that crop up after the collaborators have had a chance to experience this new idea in the concrete, as opposed to grappling with the pitch in the abstract. A million nebulous concerns that might exist when you’re talking about theories and doodles have a tendency to suddenly crystalize and/or evaporate as soon as the thing is put into practice.

Concrete tests can also be a way of vetting potential collaborators, especially early in a project. If team members are clinging to personal ideas despite their bad fit, well beyond the point of playtesting and seeing the objective pros and cons of the decision, it can be a warning sign that either they need more time to embrace this style of making things, or that they might not be able to work in that environment. Not everyone is … not everyone values project outcomes over personal contributions. Not everything or everyone needs or benefits from that mindset, but it is a practical (and in some sense tautological) reality of collaborative work specifically, and one that needs to be acknowledged.

Like the previous steps, we see huge benefits from focusing our post-test discussions on these four questions:

• what is the actual problem?
• what’s the actual solution?
• what are the actual upsides?
• what are the actual downsides?

If your collaborators are the wonderful, perceptive, intelligent folks that we all hope they are, it’s totally possible that new facets of the basic underlying problem will suddenly come to light during this test, so yes, you absolutely should reevaluate the solution if someone notices something new.

This whole process is all about building group confidence in this specific outcome, because in all likelihood, one team member’s plan to fix this nasty problem is going to require the cooperation of the rest of the team. This is the underlying philosophy / admission of this particular process, in a lot of ways. Lots of teams have team members wearing a lot of hats, with a lot of interdependency, and I think a lot of studio processes ignore this basic fact. Having a process that builds higher group confidence is something we’ve found invaluable for every facet of production.

Step 6: Finish the Plan

At some point, somebody has to actually build a dang bridge. As always, we keep an eye on our four basic questions. In the time that passed since identifying the need for a bridge and actually putting it in, has that need since been addressed by some other part of the design that we could use instead? Have the upsides changed dramatically? What about the downsides?

Just because a given proposal or idea or solution has passed muster once in the past doesn’t mean it’s the best possible design when it comes time to implement or put in the final artwork. If you’re unsure, pester a team-mate and see what they think; it could save you days of unnecessary stress, and help make the project as good as it can be.

So yea, that’s our pitch: a collaborative studio process for building better group confidence in outcomes. A way to make new things with people we never met before. A way to be more than the sum of our parts. The steps are so simple too:

• Make a plan
• Show the plan
• Talk about the plan
• Test the plan and talk about the test
• Finish the plan

The most surprising thing to fall out of this approach is the way that I think about individual contributions to a project. On our game Overland, for example, we have pretty well-defined roles: Heather is in charge of the visuals, I’m in charge of the maths and implementation, Jocelyn is in charge of the sounds, Rebekah’s in charge of the business, and so on. But on a day to day basis, I might figure out a nice little fix for an art problem. Jocelyn might fix a weird gameplay thing. Heather might have a cool marketing idea. Rebekah might identify a cool audio opportunity. This process allows us to capitalize on this, without unduly overburdening our teammates, and we get not just the satisfaction of excelling in our own disciplines but occasionally getting to fix something else.

And, in the spirit of this whole thing, I have to end by saying that I think this is the best way to solve this particular problem, but I’d love to hear your thoughts about the problem, our solution, and any other pros or cons we might have overlooked.