Creative work tends towards an iterative process: Make the thing, then go back and redo bits until it starts to resemble your intentions.
However, across a larger project just saying that you will “iterate” leaves out context. It’s important to iterate towards goals. Each time you start an iteration and pick new goals you have an opportunity to seek out a new form of feedback. It is through both the effort and the feedback that development progresses: lots of effort with little feedback means you are flying blind. Likewise, feedback without effort is a consumptive experience and favors following trends and reproducing familiar experiences.
Having made many video games, I’ve noticed that there are specific forms of iteration that recur across game projects. Here’s my list:
This is the “I want to make it look finished” form of iteration. It has a title screen, and menus, and a logical flow to gameplay and a natural ending of some sort. You even have a trailer and promotional materials. It is ready to be published. Note that there is nothing here about making any of these things look spectacular: it is simply checklisting things you will need to have a product that can be demonstrated and potentially sold.
I credit David Crane for the canonical form of this, in discussing how he made the C64 Ghostbusters game in six weeks:
Complete a full game as quickly as possible, and then go back and enhance until they pry the code from your hands. After that, STOP adding features and only fix bugs, or you’ll simply fall victim to ‘creeping elegance’. Give your game a beginning, middle, and an end. If the code-release deadline comes and all you have is a fully playable and beautifully tweaked main game, all of your work is commercially worthless! That game can’t be released. Implement the complete game flow, from the time the player boots up until the final congratulations screen. Do this first, even if the fun part – the main gameplay sequence – is nothing but a placeholder.” 1
The beginning-middle-end pattern is a great way to expose feedback about the broad strokes and tell you how hard it is to complete each part of the game. It’s the iteration mechanism that drives game jams: you can go from zero to release in 48 hours if you set yourself to that goal only.
The vertical slice is subtly different from beginning-middle-end because the focus is on maximally fleshing out a short segment of gameplay - it is “screenshot finished” more so than it is “playable finished”, although playability often appears as a requirement. It isn’t necessarily looking at marketing considerations, but rather at the details of producing content: what techniques, processes and formulas will be used to make finished scenes at shipping quality?
A good vertical slice is not just a proof of concept, it’s a way to calibrate overall production effort, which makes it hugely important to big-budget projects that need to set themselves up for industrial consistency and a massive labor effort. It’s less relevant to solo developers who need to scope around maximizing their own leverage.
If you start on a game with a beginning-middle-end iteration, you end up with a lot of placeholder functionality - suggestions of features that have not really been fleshed out.
This makes it logical to take a pass to deepen those features to be more flexible, less buggy, use new assets, or revise the existing ones. Maybe you had really basic lighting design and you want to try again, for example.
Feature deepening is the place where specialists can really shine because it’s so geared to technical skills: you can add some really fancy simulation here or work on a really detailed character model there. The feedback loops are more straightforward to measure since they tend to be within a single knowledge domain. They let teams do things a little more independently, with fewer hard dependencies.
These things all make deepening appealing and satisfying in the moment, but surprisingly high risk. Any moment you spend gearing up an existing feature is one not spent on proving the rest of the game, and many an aspiring gamedev or ambitious team has fallen into an abyss of technique where they keep leaning on a “deep” approach and avoid getting broad feedback until it’s too late to go back.
If beginning-middle-end describes the external things necessary to ship, a throughline describes the process of adding a whole new game system, set of assets, or other broad, recurring elements. These are the kinds of things that don’t have an obvious start or end, so you have to weave them in gradually.
For example, if you decide that the player needs a “shoot fireballs” power, you have to implement this decision at multiple levels: You have to add new assets for fireballs and explosions, the player needs additional UI to see and understand that the power exists, the interaction between fireballs and the game world may create a lot of new requirements(set things on fire, AI reactions, dialogue lines etc.), and the design has to be rebalanced around the new power(difficulty tuning, changes to level layouts, changes to other powers, and so on). These things all have to go through a placeholder stage before the “whole feature” can really work: so don’t make the final asset, the final UI, or final code. Aim for the bare minimum.
Throughlines are hard to wrap your head around, but they are also the best way to approach expansion of scope, because they reveal the scope before you’ve fully committed resources: if you just go and make final fireball assets, and then it turns out that they don’t work very well, you wasted your time!
Coherency is extremely important to throughline development: if the game concept is incoherent it will surface during the creation of a throughline in the form of lots of edge case complexity, difficulty communicating the feature to players, etc. There are many examples of features that are easy to surface in a fragmented form, but quite hard to build a full throughline for.
If there is a “base unit of creativity”, the adaptation is it. In its simplest form this means copying existing work directly: sampling, photography, and other trivial copying mechanisms are a great starting point for building a “palette” for further exploration. More interesting adaptations use techniques to reshape and translate the meaning: same song, new arrangment. Same painting subject, different painting style. Same feature, different code.
This makes iterations where the only goal is “do something like that, using your favorite techniques” or “do a thing you did before, with a different technique” surprisingly powerful, since it only takes a little tweak here and there to communicate something very different.
In terms of a whole project, adaptation is also a way to calibrate iteration on things you’ve never done before: If it took team X 6 months to finish project Y, and your team is a similar size doing a similar thing, a strong first estimate is that it will also take about 6 months for your team to finish. Big budget projects “derisk” by adapting more and larger elements more directly, so that they have safe iterations in their schedule.
Which Iteration Should I Use?
Choose based on which questions are most pressing to answer. If you have a lot of unknowns, go broader with beginning-middle-end or a vertical slice. If you have a lot of details to clean up, go deep. If the goal is extension, look for a new design throughline or adaptation. Make sure it reads coherently. Each type of iteration has a different kind of pace and difficulty.