Balancing Creative Freedom with Constraints
You're under deadline pressure but haven't found what makes your game special. As a producer, what's the play?
Game Production Playbook is a series that aims to make you a more resourceful producer by teaching practical day-to-day techniques and the mindset that supports them.
Reading Time: 10m
Acknowledging Uncertainty
How do you balance creative freedom with hard constraints & deadlines? This is perhaps the “soul” of what distinguishes a good producer from a great one. My answer is to acknowledge the uncertainty that exists within your game and choose an effective process from there - more on that later.
First, we need to acknowledge a hard truth: many games fail (commercially and creatively). “Finding the fun” (or “finding what differentiates you in the market” if you’re more business-minded) is not a repeatable process. You might have a hunch, but you can’t know with certainty.
Creative freedom isn’t an indulgence executives “give” to teams to make them happy. Time and space to explore new ideas is the method by which we reduce uncertainty. The less uncertainty there is, the easier it is to estimate accurately and meet hard constraints.
In an ideal world, we’d keep our teams small at the beginning of development and give them ample time to explore. Then, when uncertainty is low, we’d scale the team. But you might find yourself in one of the following (very real) situations:
Your game idea was just greenlit and you have approval to hire the first few engineers and designers. Executives are asking you how long you need to prototype.
Your team just entered Pre-Production and is supposed to be building scalable pipelines, but you only really figured out the core moment-to-moment gameplay while prototyping. The entire week-to-week metagame and long term player motivation is unsolved.
You’re on a live game that’s declining. Maybe a competitor cloned you and added new innovations. Doing what worked up until this point isn’t going to cut it.
Story Time
A few years ago, I was working at a studio with a common problem: We’d spin up new game prototypes, work on them for a few months, do a little external playtesting, then cancel them because the metrics weren’t great. There was a strong desire for the next game we started up to “stick” and be taken through full development.
I volunteered to be the Game Lead for our most promising idea, hoping that my direct involvement would give us better odds.
Having mostly been a producer and not a creative in the past, the vision I set was pretty functional - “if we can take the core gameplay from Game A in our portfolio and add the metagame from Game B in our portfolio, we’ll have a hit!” That was enough for business-minded stakeholders - we passed through the Concept phase and into Prototype.
Around that time, another large project spun down, meaning 10+ artists were free. There was a question of whether they should join such a nascent team that was still figuring out the core gameplay loop, but I figured the more the merrier.
I diligently broke our prototype into a prioritized list of features that the dev team could understand and deliver. We ended up delivering a beautiful prototype due to all of the art support. Stakeholders looked past the fact that the game wasn’t that fun.
Suddenly, we were in Pre-Production. That’s when the train came off the rails. We were making content that wasn’t satisfying for our audience to play - why build robust pipelines to make more? Art and Engineering were blocked for months as Design tried to “find the fun” too late.
I’d missed something big. There was one massive uncertainty in my original vision: What made the core gameplay of Game A enjoyable in the first place? I was so focused on gate reviews and keeping the team busy that I inadvertently doomed the project. As a producer, how do you avoid the same fate?
Common Uncertainty Traps
Every production technique has a time and a place where it’s most effective. Here are two common traps where “the wrong tool is used at the wrong time.”
Uncertainty Trap #1: The “Factory” Model
This is the model I employed in my personal story - I was so worried about uncertainty at the feature level that I ignored it at the game level. I broke the prototype into a list of features, attempted to precisely estimate them and then showed stakeholders how quickly the team was moving down the backlog.
I asked the team to operate as if we were a factory that knew exactly what made the game fun on day one. It’s not a great use of time to build more of something that isn’t working.
How You Know You’re in a “Factory:”
Very precise estimates are called for, even if that level of granular estimation takes days or weeks to deliver
Every feature in the game needs to have a full spec with wireframes before development begins
You’re building robust and scalable code that’s difficult to change before playtesting a feature
Playtesting and keeping the development environment playable is viewed as low priority
This approach can be effective when making a derivative product that’s quite similar to something else on the market. Since you’re not worried about “finding the fun,” you can focus on executing as quickly as possible. If your “win condition” is more about marketing and distribution (which it often is in mobile games), this could be the right choice.
Uncertainty Trap #2: The “Jamming” Model
In this model, you look at uncertainty and falsely assume that any attempt to manage it through structure will destroy your chances of making a good game.
You’re operating like a band that only jams and never gets down to actually making music. Jam sessions are great - they promote freedom of expression, willingness to try new ideas and just a generally good vibe. But if you listen carefully to musicians describing their creative process, they often have a deliberate feeling they want to express. They’re quite focused about trying things they believe will evoke that feeling and evaluating whether they worked. They spot patterns that lead them to “find” the song.
How You Know You’re “Jamming:”
Unfocused brainstorming and ideation meetings with tons of attendees
Ten different developers going off to explore ten different directions, without a clear game vision
Little-to-nothing in terms of goal setting, tracking or planning
Fear that imposing any structure at all could snuff out that spark that will make the game special
This approach can have great benefits in small doses, usually at the beginning of development or after delivering a major milestone.
Managing Uncertainty
Earlier, I said the “soul” of a great producer is how they balance creative freedom & constraints. My method is to look at the uncertainty that exists in your game and choose an effective process from there:
Break the player experience into major areas
Determine how important innovating in that area is to what makes your game differentiated in the market
Determine how much uncertainty there is in that area
Determine an effective process to apply
Let’s take a hypothetical example of an RPG that’s in Prototype:
This team feels doing something different than other RPGs in terms of traversal (how you move around the game world) is absolutely essential. That’s their “secret sauce,” what they feel will make them stand out from the competition.
But they’re quite uncertain on what type of traversal system will feel fresh and prove to be a significant improvement on what’s already out there.
So my recommended process is “focused ideation” - allowing the team freedom to explore their hypotheses because there’s no obvious “right” set of features to build.
(Conversely, doing something different for the class system is not a big priority for this team. Finding something new in that space would also be highly uncertain. So I’d recommend this team “revert to genre standard” - basically, look at classes in other similar RPGs and do something similar to what they do.)
Practical Techniques for Focused Ideation
“Ideation” and “freedom to explore” often lead stakeholders to panic, especially if you’re operating within the false predictability of the factory model. Here are a few practical techniques you can use even within the context of ideation with no fixed deadline to ensure the team stays focused and results are measurable.
Alignment Techniques
Alignment techniques give a clear vision of the experience we’re trying to create for players and how our game is differentiated in the market.
Pillars. Sets of three descriptors that paint a vivid picture of a player experience. These can be set at any level of detail - you can have game pillars, feature pillars, narrative pillars, etc. Imagine the gameplay difference between these two sets of pillars for traversal:
Time pressure, puzzle solving, tight spaces
Relaxing, exploration, open spaces
Player Behavior & Motivations. Start with the intended behavior a part of the game is meant to drive (i.e. playing the game a lot, spending money, telling your friends about the game). Then explain what motivates players to behave that way (i.e. mastery, immersion, action). Example: If you have a precise and demanding set of traversal mechanics, you’re likely driving engagement through a desire for mastery. Understanding this makes it easier to know whether you’re getting closer to the intended experience.
Sliders. Credit to Guerrilla for this technique. You start with a divisive issue (could be related to the gameplay, monetization, narrative, etc.) and map it out on a spectrum. For example: “Traversal involves time pressure and precision timing” on one side and “traversal is relaxing and is focused on open exploration” on another. Then you ask all relevant stakeholders to indicate where they think the game should exist on that spectrum.
Genre Standard. Provide the team with detailed research on how other popular games in the genre handle a particular mechanic. For example, climbing in third-person open world games tends to rely on clearly marked yellow climbing holds and is mechanically simple (holding the stick upwards is enough). But there’s a new wave of “free climb” mechanics kicked off by Breath of the Wild. This helps understand current player expectations and also gives the team a safe place to “revert” if ideation isn’t turning up anything compelling.
Review the “Player Journey.” Teams often get stuck reviewing a single feature in isolation, but that’s not how players think. Sticking with the example of traversal - the way the character walks, runs, glides, grapples, climbs and swims are all going to be evaluated as part of “the player experience of movement” and should feel consistent.
Prioritization Techniques
Prioritization techniques let the team know which uncertainty is most important to reduce first.
Key Differentiators. Instead of prioritizing certain features (i.e. “Feature X is more important than Feature Y”) prioritize which areas of the game are most important to differentiate (i.e. “differentiated traversal mechanics are more important than a differentiated class system”). This will help leadership understand how much freedom and iteration time to give the team and whether it’s OK to revert to genre standard if they can’t find something better quickly.
Experiments. Create a list of experiments the team would like to run. Experiments can range from quite modest (i.e. changing the tuning values for run speed or jump height) to quite ambitious (i.e. a new teleportation mechanic). Each experiment is given a priority and a complexity rating. You start with high priority, low complexity.
Learning > Outputs. Create a list of questions the team would like to answer (or things they’d like to learn) instead of a list of features.
Timeboxing Techniques
Timeboxing techniques activate our tendency to come up with innovative solutions when facing constraints. They also help us avoid creative dead ends and diminishing returns.
Context & Consequences. Help your development team understand the constraints you’re working under (i.e. we have a high burn rate, the publisher demanded this milestone be delivered in three months, etc.). Explain the consequences of certain decisions (“if we spend X weeks on this feature, it means Y less weeks on this other feature”).
Problem Statements. First, you ask the team a question (i.e. “On a scale of 1-5, how satisfying is traversal through the environment?”). Then, you spend a set period of time (i.e. six weeks) to explore that question. If you ended up taking traversal from a 2 to a 3.5, maybe that’s good enough and you can move on. Or maybe it needs another iteration. Timeboxes build in a natural pause where the team can look back at the work they did and what they learned as a result.
Action Blocks. Credit to Respawn for this technique. Using this method, you prioritize skill-based experiences a single designer can create in a week. Those playtesting the experience should be able to get through it with no additional context. Once enough action blocks have been accumulated, patterns of what’s working (and what isn’t) tend to emerge.
Project Management Techniques
Project management techniques help use the team’s time as efficiently as possible, avoiding waste and rework.
Tie Questions to Milestones. Create milestones that specifically mention what questions will be answered (and what uncertainty will be removed) when they’re completed - not just what new features and content will be added to the game.
Separate Dependencies. If design is exploring a highly uncertain space, it’s better to avoid the situation where the rest of the team is waiting for them to “make a decision and stick with it.” The ideal case is that everyone is engaged in the process of exploration and comfortable with throwaway work. But the common solution here is to prepare lower priority, lower uncertainty work for art and engineering to work on in the meantime.
Next Steps
In my story, I talked about missing uncertainty so fundamental (i.e. what makes this type of game fun for players?) that it tanked my entire project. Hopefully you’re not in that particular situation - but what uncertainty exists on your project? How can you skillfully give the team the creative freedom it needs to explore it while still meeting the hard constraints you’re facing? I'd love to hear about your experiences and insights in the comments below!