Our Broken Maps
Game development is hard. I think it’s quite understandable that someone who spent two, four, maybe six years of exhausting work on a title and finally sees some success would think that they now understand how to make games. This is wrong, of course. They understand how to make a game.
Most of us in the industry know examples of brilliant developers leaving their genre (or platform, or business model), applying their hard-won lessons in the next project — and hitting a wall. This can lead to a kind of anxious arrogance; a declaration that those other things you don’t quite understand aren’t “real games”. Over the years, I’ve seen this charge levelled against anything from mobile games to strategy titles, to story-focused experiences, to games with crafting, to — well, anything. It’s all a bit silly.
Games are complex and varied. Whether you decide to double down on a specific niche or to move around the industry, having a decent mental map can make life a lot easier. I’m not sure I do, but there are a few concepts that have helped me over the years. Today, I’d like to talk about the idea of system- and content-focused games.
What are we talking about?
You may already be thinking of some of your favourite games (a Telltale title, for example) that invested a bigger portion of their budget on the one side, while others (let’s take a Firaxis game) may have put the emphasis on the other. Of course, this’ll lead to different team make-ups, to the experts inside the teams pushing for different definitions of excellence, and so to different grown competences in each studio. That doesn’t make “system vs. content” any more useful than say “2D vs. 3D” as a category to think in, though.
What I’m really asking after is how early in the project the first representative version of your game loop becomes playable.
Content-Focused Projects
I’m going to have to beg your patience and start with the textbook project lifecycle. We could certainly quibble about the details and nomenclature of each stage, but I suspect that most of us who work in the industry have some version of the pictured process in our heads as the default, ‘correct’ way to build a game. And I agree that for a huge variety of titles from AAA action-adventures to indie puzzle games, it is.
In a project following this model, the first playable game loop will arrive sometime around the end of Pre-Production, maybe a third of the way into the project. If your game idea is particularly elegant, it may even be a good bit earlier.
A friend of mine (guess which company we met at) discusses dev culture under such conditions as a move from war- to peacetime: A volatile, creative early phase that ideally ends in decisive results, followed by a structured, predictable period of growth.
When I say that this model fits a content-focused game, that’s not to imply that there’s no challenging systems work here. Arguably, the locomotion system of a well-realized third-person action game has as much or more depth as the construction loop of a high-end strategy game. The point is rather that content production depends on a settled core loop.
Once you’ve got that loop in place and proven, each thing you build risks at most the work you put into it: It hurts to cut act 2’s biggest set-piece battle after it just didn’t come together, but you can still release a good (if thinner) game. Before you prove out your core loop, you risk everything that comes after: If you find out that you need to double your combat arenas’ size to accommodate that crucial new dodge move, all set-pieces you built so far might need to get torn up.
So you don’t do that. You keep your team small and design- and tech-heavy up to the end of pre-production, and bring in the bulk of your content authors once that risk has been managed. It’s textbook, after all.
Now here’s my point: I believe this isn’t a universal model for how to make games; it’s an instruction for how to safely run projects that rely on content to generate playtime. In terms of risk management, such a game will benefit from a loop that’s relatively quick to put together, leading to that “short war — long peace” structure.
I suspect that shooters and action-adventures have become such mainstays of blockbuster gaming exactly because combat loops fit that bill so perfectly. It’s possible to lay out the basics of a 3C (character, controls, camera) system and its AI counterparts via fast-ish prototyping, to derive your relevant metrics and boundaries from there, and then, while content production ramps up, to refactor and deepen that loop (via new weapons; via more nuanced controls; via that late-stage enemy that can break some rules of movement…).
System-Focused Projects
Now let’s compare all this to a game that relies on its systems to generate playtime. Think of a long-session strategy game, or a city builder:
Gameplay is based on a wider loop that encompasses more individual systems (e.g., research, construction & production, movement, positioning & combat, etc.). Most of these will be comparably shallow, generating complexity out of their interplay. Obviously, the game still relies on content (units, buildings, resources), but a much higher portion of that is itself systemic: It directly represents specific features and mechanics. Environments, narrative and set-piece assets are either left out, auto-generated, or much more heavily reused.
It’s obvious that you’ll need to author more systems to reach a playable loop. At the same time, prototyping becomes less efficient: If you have to set up ten shallow systems that you can maybe sketch up in a quarter or half the time it’d take you to write them cleanly, that may still be the way to go — but it’ll be less efficient than a game with three deeper systems that you can each prototype in fractions of the time it’ll take to get them stood up properly.
When in your project’s lifespan does the loop become playable under such conditions? In my experience, somewhere between the halfway- and two-thirds points. So, relatively close to Alpha.
If you’re thinking in risk management terms, this picture may have spiked your blood pressure: Until the core loop is proven out, you don’t actually know whether the game will work, after all. Running this long — potentially years — without that moment of truth flies in the face of best practice, from the concept of the Minimum Viable Product to the designer’s adage of “Fail Fast”. Even if you keep your “Pre-Production” team as small as possible, you’ll still gamble with a huge portion of the project’s budget and your team’s time.
In terms of development culture? In the grim darkness of systems game projects, there is very little peace indeed: The creative chaos of design revision and feature adaptation lasts well into the time of mid-development exhaustion. A proven concept only emerges so late that content production ramps up under very tight deadlines (if you weren’t forced to ramp into insecurity due to launch window constraints or similar), only exacerbating the fatigue of a team that has seen a lot of its work burned, repeatedly. Predictability and stability are incredibly hard to maintain.
How we deal with it
There are some ways to improve the situation. You may have spotted my rhetorical dance between “first representative game loop” and “deepened systems”, for example. To a point, it is up to debate what task belongs in which bucket: Do you need the trade system in place to be able to judge your 4X game’s core loop, or can you just stub that in for now?
These kinds of conversations will happen in all of game development. With systems games, I’d expect them to occur, lead to a hopeful consensus that then eventually fails during playtest; re-occur and lead to a new, expanded consensus — and repeat like that several times.
This kind of “development by accretion” can feel slapdash and confused to people thinking in terms of the textbook lifecycle: Can’t the designers just settle on what their game is about? Are the producers incapable of handling the feature creep? In fact, since most of us have been trained in one way or another on the model of the fast(-ish) pre-production, those designers and producers will very often carry that same doubt around with themselves.
If we accept that there are cases where it’s normal to have a long road to a proven loop, things suddenly look healthier. Project management methodologies that are specialized on live service- or other conditions with limited visibility have always put a premium on prioritization over prediction, after all; take Scrum’s stack-ranked backlog or Spiral’s iterative increment for example. Framed like this, we can take the process of setting up and then expanding the loop towards viability as the next best thing we’re likely to achieve to iterative incrementalism: We can’t say with certainty when our product will begin to ‘work’, but we can make sure we’re building its most important parts first and ensure regular validation.
(There’s a nifty 2010 book by Christopher Schmitz and Holger Nathrath, elaborating a methodology on such a Spiral-inspired approach. I don’t think it ever got translated into English, unfortunately.)
Another mitigation is to switch business models to one with a less demanding MVP. Early Access (and before it pre-Alpha sales, or shareware) has arguably become standard in systems-heavy genres like survival- and colony sims for this reason: It allows you to run a first release with less content and a barer core loop, reducing the need for premature ramp-ups and keeping the overall investment somewhat more manageable.
The likely most widespread way of dealing with the challenge is the most straightforward, of course: You ignore it. In more than one studio, I have met director- and C-level people — brilliant folks, with more success and experience than I may ever find — who were insistent that the kinds of games they worked on could be made in less than half the time it took their teams to actually build one.
I don’t think this phenomenon is unique to systems games. You work on a game, it’s a success; you rise out of hands-on development as your studio and the audience’s expectations grow; you stick to certain ideas well past their sell-by date. It’s a very human mistake to make. But I think it’s easier for it to go unchallenged in systems games development, with its unpredictable phase of feature accretion.
A lot of the places I refer to actually use some version of the ‘pre-production/production/finaling’ stage gate model. Everybody just kind of remembers how the last game’s proof of concept also felt pretty rough, and that things only really came together around Alpha. The model doesn’t truly fit, the safeguards built into the stage gates are lost, but institutional knowledge keeps things moving along. Until people from more content-focused places enter the picture.
I don’t think it’s a surprise that so many systems game successes come from small, self-publishing developers. It may be easier to stick it out on such a project if you have no pre-conceptions of when things should normally come together — or if you’re so personally invested that you’re in it for the long haul, anyway.
Hybrid Projects
There’s a kind of unwritten rule in game development: Once somebody has managed to do something really difficult, three others will try to pull off the same thing, only with higher production values, more expansive scope, or mashed together with another incredibly difficult thing. There’ve always been games that try to go deep on both systems and content.
Now, I have to cop to some bias here: Warren sent me. Like oh so many people who joined the industry some fifteen-twenty years ago, I did so because of immersive sims like System Shock, Thief and Deus Ex; arguably some of the most systems-heavy titles ever to send you through a narrative campaign. Of course I’d think that going heavy on both was a worthy cause, and damn the torpedoes. But I also don’t seem to be alone with the idea.
As long-term player engagement becomes more important across the industry, systems-heavy approaches become more attractive: Content production may be risk-manageable, but it is expensive and it takes time. Giving people incentives to re-play becomes more valuable; systemic gameplay is often the answer. Of course, these games still try to appeal to audiences that are used to blockbuster productions a far cry from the pared back, often top-down presentations you’d associate with so many Early Access hits.
As time goes on, more and more of us will be faced with this challenge. So how do we deal with it? How can we maintain a healthy development culture and a viable path to success when uncertainty and financial risk pile onto each other?
As always, I can only offer ideas.
Compartmentalize
Given that I speak about a huge span of game concepts and development scales here, I hope I can be forgiven for so far talking about the game loop in a rather undifferentiated way. It’s of course often possible to divide a game into separate smaller experiences that communicate with each other via defined inputs and outputs. You may be thinking of casual mobile- or hardcore multiplayer titles right now; both frequently distinguish between the match’s (or level’s) gameplay, and the meta-game’s progression loop that frames it.
In extreme cases, you can subdivide your production to the same degree: If your systems-heavy- and your content-heavy gameplay can be proven out separately, it’s possible to run a textbook project lifecycle on what will likely be the bigger, financially riskier part.
Even if it’s not quite as clear-cut, it’s still worth to ask which parts of the game impact which types of content. For example, character- and vehicle-based gameplay have often been separated in open world games. If your expanded systems loop mainly lives on one side of this divide, it’ll be possible to de-risk development of the other, down to the always-vulnerable level design, comparably easily.
The more connected and systemically complex the game becomes, the fewer such chances you’ll find, of course. That doesn’t make your project untenable, but it’ll increase the period of uncertainty and the likelihood of cost- and schedule overruns. The less compartmentalization is possible, the more will an honest risk conversation become crucial.
Show the exits
People start behaving badly when they feel trapped. You can’t really blame a sponsor for becoming more heavy-handed when they feel their backs against the financial wall, nor a team member for losing faith when there’s no clear perspective. Knowing that there are ways out, that there is a plan B in case you don’t sit on the next game of the year after all, can be very helpful. And though it’s counter-intuitive for project leadership to open the door to such conversations, I think it’s a healthy thing to do well before the moment of crisis has arrived. After all, if you work on a hybrid project, that crisis can hit hard:
Every organization will have a threshold beyond which outright cancellation becomes so financially painful that it threatens to drag executives and business units down with it. Maybe you’re OK with burning fifty thousand dollars, maybe fifteen million; at some point, the write-off will always be too big for your overall balance sheet to handle.
If we’re honest, even ‘deserving’ content-focused games often don’t get cancelled before this point has been crossed. The industry’s widespread unreadiness to take its pre-production gates seriously might be a good topic for an article of its own. What we’ve established here though, is that the threshold may lay significantly below the investment needed to prove out a systems-heavy loop. The vertical slice “kill-gate” stops being a useful decision point.
It’ll still be good to identify early cancellation points if you can — say, a market viability check towards the end of conception. It allows you and your sponsors to refresh the project commitment, and that’s rarely a bad thing. But you’ll also need ways of handling bad news in the time beyond viable cancellation.
Most publishers know how to deal with a disappointing launch. In the premium PC market for example, that usually comes down to an early discount and a push towards break-even via bundles and season sales. If your systems-heavy game refuses to come together but is too big to just kill, this may be the next best exit: Accept what’s there, generate what content you minimally need, maybe apply a lower sticker price, and take your learnings into the next project. It’s not what anybody really wants, but hey — closing strategies rarely are.
During project set-up, such a ‘lesser launch scenario’ can be the way for you and your sponsors to consciously discuss how much time to give the loop to come together. A good product manager should be able to forecast how much revenue the lesser version of the game could generate. That number can lead to an acceptable timebox for your extended “pre-production”, setting a horizon to steer by and reducing pressure ahead of the moment of truth.
Monitor your re-use
If you have systems you can carry over from previous projects, it’s worth it to try and do so. In some ways, every point I’ve raised so far shows that really complex productions are best conceived of as not one project, but instead a series of releases.
Say your new action game is set to include a bunch of fancy progression systems and you have a nice and punchy shooter loop laying around from your last game. Everybody’s life will be so much easier if you can build the new systems around it.
Often, this will face pushback from inside your team. First, because we in the games industry tend to be novelty-hungry; second, because the old and new systems may just not be compatible.
If what you’re trying to build is a looter shooter and your last game’s combat was so satisfying because enemies dropped in three bullets tops, that whole loop will need to be rebuilt for your new world of rapidly deprecating weapon stats.
If we want to talk about “Fail Fast” opportunities, these are the kinds of contradictions to recognize and surface during Concept or early in Pre-Production. It’s easy for a project brief to be founded on optimistic assumptions of re-use. An honest conversation about threats to that, even if they won’t actualize until much later, is likely the best opportunity you’ll get to course-correct.
Never underestimate the power of (simple) content
Many a hardcore strategy- or simulation game comes with a bunch of event cards tucked in between its economics loops and battle resolution systems. You’ve seen them: RNG-triggered text passages that narrate a situation, maybe a button or two to make a decision, and some currency or modifiers to give the whole thing relevance in the wider game. One of my previous employers has turned this into an art form, with full-on narrative arcs and the promise that with luck, determination and foresight, you too may put a horse on the Byzantine throne.
On their own, such event chains would create an interactive novel beloved by a dedicated but limited audience. Inside these complex systems games, they’re a welcome source of variety to a much larger group of players. Development-wise, they offer a chance to introduce factors it’d be unfeasible to create separate simulations for into the game loop.
To me, they are a reminder that there are no awards for dogmatic purity in game development. If you can shortcut a lengthy iteration phase with an affordable amount of content, that might be the way to go.
Conclusion
So where does all this leave us?
My main argument is that we don’t have a unified theory of how to make games. Even widely accepted models like the conventional stage process are much more suited to some productions than others.
I take this as an encouragement to tailor your project approach to brief and vision. One of the most useful lenses I have found for this is to ask when you can expect to prove out your main game loop, and which parts of your content investment are particularly at risk before that point.
Navigating this process will require a reflected approach to the length of your incremental-iterative design phase and the financial red lines of your sponsor. You may be able to mitigate to some degree via feature compartmentalization and re-use, and fallback business planning. Only very rarely will these be easy conversations. If they seem to be, somebody may not be paying attention and you might be heading towards a rude awakening come mid-project.
I end again by wishing you good luck — and if you have found useful patterns for how to structure high-system, high-content productions, please share your notes!
