A few weeks back, I asked my LinkedIn network what topic they’d like me to write about, and the majority voted for “The framing of game development phases may be preventing its evolution”. So here’s my thoughts on that…

To start off, let’s align on what I’m referring to by “game development phases”. Here’s a simplified visualization:

I’m going to go out on a limb here, and say what many people in game development think (and complain about indirectly, and often), but which rarely gets talked about, at least openly: these standardized phases are a source of frustration, and probably cause more harm than good. 

Per the headline, I’d also go one step further and say that simply invoking them by name in writing and conversations is probably holding back the evolution of how we approach making games in general – it anchors our mindset, closing off new possibilities and the inclination to start exploring them. 

I’ll loop back in a moment and break down that last line a bit further, but for now let’s look at some of the pros and cons of using “phases” that I’ve seen over and over across the dozens of games and contracts I’ve been involved with, years of “war stories” from peers, and piles of online post mortems. Just to be 100% clear, none of this list is meant to be criticism, and it’s not referring to any specific studio, publisher, or team – it’s broad themes from many sources. 

Here’s a few of the more prominent problems…

• Phase names are not useful in understanding the actual state of a game (what has been learned, what is left to learn, known challenges or risks, player feedback or outcomes, market fit, etc.), and often lead to gross over-generalizations by anyone not close to that state. When we ask peers about how their game is developing, they never stop at “Well, we entered production last week”; they typically qualify it with many buts, ands, and excepts, and contextualize it far beyond the phase name.
• The general concept of “phases” often causes development activities to be linked unnecessarily, pressuring them to start earlier/later than necessary, which then wastes time through staffing challenges, cascading pressure to continue working on something that may not be useful, re-prioritization and rework, etc. For example, developing content-creation tools or a visual benchmark during “pre-production” when neither one is actually a notable risk to the game’s opportunity or remaining development.
• The transition from “Pre-production” to “Production” often splits the perception of development in a very binary way – the learning is basically done, and it’s time to deliver; when learning happens during “production” (which is inevitable), a surprising number of people are… well, surprised.
  • For starters, Pre-Production and Production come from the movie industry, which are a different context – their overall creation is more complicated than complex (from a Cynefin/human observer standpoint), due to their 1-way format vs. the interactivity in games. This means they can do significantly more planning up-front, then move into production, because reconfiguring the product to meet a vision or audience sentiment/expectations (via test screenings) consists of editing and the occasional re-shoot. They also further offset this risk by creating more content than they need during principal photography (and now leveraging fully digital actors and sets), giving them incredible optionality during editing. J Allard touches on this as well in a Gamasutra article about industry burnout: “The writing, planning, budgeting and execution of three-act-narrative, whether TV show, movie, book, is far more predictable than modern games,” he says. “Video games have always been a more fluid medium with fewer rules and lower expectations on structure. Because of this, a pre-production phase for a game is far less predictable indicator of the schedule, budget and effort to build. A top-tier producer working on say, Project Gotham Racing that moves to Grand Theft Auto is going to need to push a very different pre-production phase, even though both games have similar elements.”
  • In games, I often see stakeholder expectations set too firmly because of this binary shift between learning vs. building – from budget, to dates, to “ensuring all major risks have been identified” in pre-production, which leads to various types of unhealthy friction when things need to change.
  • It’s also a large contributing factor to the oscillations in hiring and layoffs that have plagued the industry for years, and cause developers to burn out quickly (but that’s also another article for another time).
• Legacy definitions like “alpha” (ex: functionally-complete, content-incomplete) and “beta” (ex: content-complete, only bugs and/or polish remaining) are oriented around a narrow context: a game in which the known and major risks are horizontal (system-to-system and across the basic player journey) and need to be prioritized. It assumes little to no vertical risk (visual cohesion, visual quality w/expected performance levels, nuanced player journey, nuance in mood or tone) and totally ignores that most games need a mix of both vertical and horizontal development at different times for different reasons.
  • In the classic publisher / developer setup, this puts development teams on the hook for finishing up a huge breadth of scope during “beta”, with very little understanding of vertical effort (the classic “last 10% of the work is 50% of the total effort”); this often leads to significant overtime and frustration. This is also why “vertical slices” have become more prevalent over the years – they are essentially an exploration or “spike” into that axis of risk, to learn more about it. I’ve personally navigated this space several times on my own games, pushing for vertical direction in opposition to our contracts, and both the stakeholders and team came away quite happy with the outcomes, even when it meant less horizontal scope was released. 
  • By definition, it opens the doorway to deferring technical debt until “beta”.
  • It’s worth noting that these phases became even more solidified during an era where “total playtime” in retail games was an obsession, and stakeholders needed to build confidence through seeing the game “end to end”. This can be appropriate in games where there is a minimum expectation by players, but there are far easier and healthier ways to check this in advance, and in most F2P or service-based games, your immediate risks are in early retention, not being able to play through the entire experience.
• Phases lend themselves to “big-bang-governance” – making a few large budget and direction decisions, which can have significant opportunity costs if the game can be steered more responsively (i.e. if the learning and deployment cycles are smaller).

And here’s a few of the prominent benefits…

• Teams feel a sense of progress when they advance into a new phase (although I often see this as THE goal, which is another blog post altogether…)
• Individuals with some level of abstraction from a game’s development can apply their existing mental models to where they think a game or component should be, and frame feedback accordingly, i.e. “That should have been done waaaay back in pre-production”, or “That team is too big to be prototyping”. It provides a basic starting point for discussion and alignment, but again, it is very abstract, and it is inevitably followed by a deeper contextualization of their concerns or the state of the game.
• It enables reuse of contract definitions, saving some time and money. I’m not trying to be sarcastic here, I’ve had many conversations with parties writing and revising development contracts, and I’ve lost count of how many times they’ve explained that their lawyers and/or directors simply don’t have the time to revisit or even tweak their phase definitions. Teams that force their game to adhere to inappropriate horizontal or vertical constraints will waste exponentially more time and money than a few hours from those stakeholders.
• Phases lend themselves to “big-bang-governance” – making a few large budget and direction decisions, which can simplify being a stakeholder. 

So how is it “holding back the evolution of game development”? Sounds quite dramatic! 

Combining all of the above, it’s distracting us from the fact that game teams are constantly learning as they build a game, that learning is specific to a game, and that knowing those specifics is vital to understanding its state and options towards success. 

Let’s expand that phase diagram at the top of the post, and look at it through a lens containing hypotheses (our ideas for a game, or what we assume to be true), discovery (exploring and learning what to build) and delivery (“doubling down” on what was discovered).

As noted above regarding “pre-production” and “production”, and represented here, there is usually a misperception that learning generally stops once a team enters production, as if an invisible switch has been thrown.  (In much of mobile F2P, learning “restarts” when the game is launched in smaller regions that potentially represent larger regions (or a hybrid, such as a “closed beta”), and data is available.)

However the reality is that learning continues throughout development, whether we like it or not. Each new playtest, each new feature addition, each new complexity that emerges from systems interlinking or a player journey being tweaked can create unexpected results. Additionally, the team continues to learn how to build the game, how to best communicate and coordinate, how long it might take or how many people / capabilities they may need, what potential competitors are doing, etc. Conceptually, this looks more like the visualization below:

If we then contextualize it to a specific game, accounting for its opportunity space, riskiest assumptions, team and studio capabilities, and so on, we get a more useful view of when and why some aspect of the game might be an area of “discovery” or “delivery”, how some areas might oscillate between states, etc.

This, and not phases with names, is closer to the reality of a game’s state and evolution.

So what are the takeaways here? What could change? How could it evolve?

Names can carry a lot of mental models/baggage and power, and simply changing them can start to break those up and elicit new pathways of thinking and valuable conversation – it opens up new possibilities.

So as a starting point, consider getting rid of phase names in your team or studio, and simply replacing them with an existing framing that most people in games already know: “production-phase” milestones that are named or described in a way that is more specific to the game, usually oriented around proving a key aspect of the experience. I often see teams refer to them as milestone themes or intentions, spirit of a milestone, etc.

Here’s a basic example of what that might look like:

Taking a deeper step, try focusing on the reality of the development – how can you represent the state of the game and plans in a more robust and accurate, yet still digestible way? (This also means stakeholders will need a deeper understanding of why things are being developed in a certain order or way, but that’s probably a good thing.)

Borrowing a page from the above diagrams, try framing development through a learning lens first, and a delivery lens second. What questions are you trying to answer at any given time? What is the appropriate order of these questions or learning opportunities based on their risk to the overall vision and opportunity? What level of quality or coherence is needed to find the answer? 

This is essentially a “prototyping mindset”, which I would say is our domain’s “learning mindset”. 

Taking this view will naturally promote a game’s context compared to generic phases, since every game has its own set of questions and prioritization. Here’s one example of that approach (using a fictional game) which has helped some teams I’ve recently worked with think about learning vs. delivering, and which I usually refer to (very inelegantly) as a “lean game roadmap”. It’s similar to story mapping, but flipped on its axis (rows are now columns) and expanded to show teams or areas of the game, and other planning considerations.

(click to enlarge)

If you’re in a developer/publisher setup, take time at the start to collaborate and define milestones that fit the intended learning profile of the game (similar to the proposals above), not just deliverables. This will allow much better conversations about when and how the game can be steered, benefiting everyone involved.  Then look into modifying the structure of contract templates to support this co-steering based on learning, such as player/playtest outcomes being achieved, optionality to iterate or pivot when they are not, and a process for how that optionality will be handled. Speaking from my own experience, in the cases where I have managed to use this type of approach, it has generally resulted in more engaged and aligned steering from everyone involved, more satisfaction in the results, less rework, and less overall stress.

To support this, consider taking an approach that shares both risk and commitment in the contract terms – a rolling “window of milestone commitments”, splitting costs on unexpected or extended iteration, etc. It may sound a bit scary from a financial standpoint, until you consider how much money is lost when learning isn’t part of the contract conversation: games that release to lukewarm reception because the studio had to over-focus on deliverables to “keep the lights on”; teams that burn out and slow down in late milestones from horizontal commitment + vertical feedback; individuals that ultimately decide to quit under these pressures, disrupting the project at critical phases, especially post-launch; or the difficulty in being able to consistently find good talent and teams, and the associated costs (spoiler alert: it’s due to high churn in the industry). You don’t need to start this adventure alone or from a blank slate, there’s plenty of history and activity in this domain – starting by Googling “agile contracts”, and taking a look at the principles, approaches, and case studies.

Some closing thoughts

I don’t expect phase-based development to totally disappear anytime soon, but I do hope that this opens up some new lines of thought and consideration in a few readers. And there’s already significant change happening throughout the mobile/F2P space – stemming from the realization that a typical pre-production + production combination is too long to wait (when compared to the game’s opportunity window) to learn what real players (not playtesters) actually do in the game. 

I’d love to hear from those of you who have found new and useful frames for ongoing development outside of the traditional phases, or want to explore the opportunity space along with me – feel free to drop me a line at jeff.j.lindsey@gmail.com

Cheers!