Milestones

In my consultancy I've received quite a few questions about how to set up your milestones for an optimal development cycle. Very frequently, these questions come from young producers, or producers moving into the games space from other industries - who are often taken aback by how different creative production is from other fields.

Milestones are invaluable (albeit not necessary) to a healthy development cycle, because they force clarity, definition, & recurring progress checks. Because of that, well-defined but appropriately paced milestones help guide a development process in a healthy and efficient matter. Conversely, poorly defined milestones and lack of understanding of time required can turn an otherwise pleasant development into a hellish experience, sometimes devolving in what is dramatically referred to as a Death March.

Because of that, even a basic understanding of Milestones can really help in the production of your game. The rest, sadly, is just pure experience: game development is an unpredictable business, and recognizing issues and potential future problems becomes easier with time and with familiarity with your team & resources. Very few production methodologies survive a collision with reality in most businesses, which means in games they're frequently borderline useless. Regardless, some knowledge of various methodologies will mostly help in recognizing which ones will help you put out the current fire most effectively.

That means that the following breakdown of Milestones is effectively an idealized reality: the reality will be messier, and more unpredictable. Attempting to fit reality to the production schedule will most often lead to worse results, but allowing the production schedule to become unmoored from reality entirely will result in anything from crunched or rushed titles to a complete failure to ship. The sweet spot is somewhere in the middle: where it is exactly will depend highly on your team, trust, resources, and problem-solving ability.

In general indie game development, I consider basic distribution of Milestones to be split into four major sections, each of the sections are then split further into smaller tasks. The first is Research: Ideation & Prototyping. After that comes Pre-Production: Vertical Slice & Production Start.  Next is Production, which contains Feature Complete and then Content Complete. Finally, the project is brought to release in the Wrap-up Phase, which includes the Release Candidate & Release Build.

In each phase (and in each subtask), the requirements & production issues of development shift significantly, and being prepared for those shifts is a large part of running a smooth production. I'll lay out each of the sections and tasks for an idealized development process for a mid-tier independent game process for some sort of six-to-ten person team.

Research

Research consists out of two phases: ideation (or, coming up with ideas) and prototyping (or, testing your ideas). This phase is one of the most unpredictable phases in development, and very few methodologies exist that can help give you a clear idea of how long this takes. In the research phase, you're mostly working on concepts and ideas, and the main production goal is to 'fail fast'.

In ideation, your team's primary focus will be on brainstorming, which means designers, concept artists, and prototype-focused engineers will be your key resources. Your production goal is to ensure the communication cycle between these teams is as short as possible - ensure direct communication, and tools to collaborate/draw/talk. Define a brainstorming methodology, preferably one that feels natural to your team - and ensure that the session is safe & allows for "bad ideas" to be explored a bit too. Coherence is less of a concern here, nor is the notion of a complete product: we're trying things out, and seeing if they'll stick. Quick & dirty prototypes, short text drafts, and fast mockups/silhouettes/sketches are the name of the game here. By the end of ideation, a clear intention should've formed.

Prototyping is when ideation has landed on an idea that seems viable. At this point, the team switches from divergent/lateral thinking to more convergent/focused thinking. That does not mean the 'fail fast' attitude should be abandoned here - try things fast, and test them rapidly. Try to keep your cycles short - keep what works, and abandon what doesn't. From a production point-of-view, your biggest challenge tends to be ensuring that there's enough time to follow interesting threads, without allowing the team to get stuck on a problem longer than necessary: prototyping isn't about problem-solving, it's about problem-finding.

Think of it as navigating a maze: you have to move forward to get somewhere, sometimes even backwards, but standing still never helps. Try to make prototypes, sketches, drafts, and move fast -again, we're not looking for perfect here- we're looking to see what works, and what doesn't. You want to rapidly go through various prototypes and iterations of those prototypes to get as much information on the table as possible. If there are question marks in your development process, this is where you want to surface most of them. If your prototypes have potential & proves the required versatility for the scope of your game, you can solve minor problems with it later.

If your production gets stuck at prototyping, now is a very good time to cut your losses. If your production process is laid out well, it means you've lost a month or two of work, gained new insights into what doesn't work, and can move on to new ideas. If your game exists in a niche & you need funding, now is a good time to do some early pitching to see if anyone is interested in your type of game at all.

Pre-Production

The Pre-Production phase continues on convergent thinking, but involves a lot more of the production team of the game. The core deliverable in this phase of development is the transition into production, and before that, validation that production is viable. In these phases, the development timeline is established and confirmed, and a clear picture emerges on the requirements the project will demand.

That also means that this is the 'make-or-break' phase for most projects: this is the phase where you'll have most of the information for a good pitch together. Often, funding has to be completed by the end of the Vertical Slice, or your team will likely run out of resources (or motivation) within several months.

Since I already discussed the Vertical Slice extensively in this earlier post, I won't spend too much time here. In the Vertical Slice the main goal is to test your production cycle. That means you're involving all parts of the production process and encouraging the completion of one full production cycle - what amount of content that represents depends on the game and the financial context: in general, you're looking at one full production quality sequence, segment, skirmish, scenario, or level. For this, it's critical that all parts of production are sincerely involved: it needs to become clear where pain-points exist in your process, where communication can be improved, and where a lack of clarity exists.

For production start, the lessons learned in Vertical Slice get put into motion. At this point, the production timeline is clear, necessary documentation exists for all disciplines, and everyone has clear and defined goals and timelines for their work. This frequently means a bit of a moving goal -in many games, parts of the game get defined as development continues- but it is important that every team has access to the information they need as they start on a task.

For producers, this is where the juggling often gets a little more complicated: as certain tasks are missed, or resources are unavailable, cascading errors might occur. Adequate buffering, triaging, and clever scoping may be relevant here - the main goal of the first part of development is to get all functional parts of the game in: the 'verbs', so to speak. The reason we focus on 'verbs' is because their modification, addition, or removal frequently affects other 'verbs', and commonly a lot of 'nouns' - assets, content, and interfaces. The sooner we can lock in the core 'verbs', the more predictable everything else gets.

Production

Production is a continuation of the Pre-Production, and is usually quietly transitioned into as development approaching the 'Feature Complete' stage. As the production process becomes more of a cycle, the team iterates on issues for future cycles.

Feature Complete is the first major milestone out of three production milestones - it is also generally referred to as alpha. It's when all core features of the game are implemented and functioning - just not necessarily with all content. To illustrate, you might be creating an inventory system: for feature complete, you'd want the inventory screen, the ability to select an item, the ability to 'use' it, the ability to 'discard' it. For that, you'd need at least two implemented items: so you can toggle between the two items.

Note that I emphasized core features - I often get asked whether level- or unit-specific mechanics count here - while opinions differ, I tend to feel those fall under 'content' rather than features. If they are removed, they often affect relatively small amounts of content and code, and as such are far less risky to development.

In most cases, there'll be plenty of content development parallel to this, but the target of Feature Complete is the core features & the framework for the 'golden path' of the title if such a thing is relevant to the specific game in development.

The sooner these get locked down, the sooner the full requirements on the Content Team & potential external porting vendors become clear. For most genres of games, you'd hope for Feature Complete to happen somewhere just past the halfway-point of development, but it frequently will be closer to two-thirds of the development cycle. On a relatively common two-and-a-half year timeline (which includes six months of preproduction), and for most common genres, you might want to hope to reach this between a year & a year-and-a-half in, leaving you with about one to one-and-a-half years of pure content development.

For your marketing team or person, this is generally the point where things properly start moving: the clarity of what the game is & is not helps create messaging that sets appropriate expectations.

Content Complete, then, is the next obvious goal. With all main features implemented, the team now has a clear context for content & asset development. In the long walk to Content Complete, all question marks have been answered - although some variability might remain for the amount of content: the creative team might see potential space to create additional blocks of content. It is a producers' job to allow as much space as possible while ensuring that nothing goes in that would jeopardize the process or game through complexity, dependency, or otherwise.

At this point, the biggest challenge for a production that isn't running on time & schedule is decisive scope management: either accepting that there's a need for additional resources (both people and/or time), or triaging aggressively. The goal becomes to create space for the Wrap-Up Phase to begin as close to the original plan as possible.

For a production that is running on time and schedule is to maintain course, scope, and to continuously re-evaluate resources as the team starts building down near the end of the Production Phase.

Wrap-Up

The Wrap-Up phase is one of the toughest ones for most developers, as it's the one you get to practice least often. Lots of developers have boundless experience in starting and producing games, but many have remarkably little experience in wrapping up things. Your main goal as producer will be to coordinate external services to come in at the right time with the right things - which means clarity is a must.

For Release Candidate, the main focus will be to ensure Localisation, Quality Assurance, and Release Management are initiated -in the optimal case, continued-and finalized. This will include ensuring the final files are sent off as Content Complete wraps up. Depending on your resources, most of your team will move on to a future project or post-launch content, but a core group remains to deal with certification & QA issues (and/or potential post-launch content). Metadata and marketing assets are finalized and uploaded for each launch platform, and localisation is implemented and tested (I'm going to say it anyway: make sure your German localisation didn't break your text-boxes, and for the love of anything, check your Arabic).

As soon as you have a stable and completed build, submit it for certification if required. This build shall be referred to as Release Candidate 1 - and it shall remain the primary Release Candidate for launch until it is rejected, or a newer, stable, and completed build passes certification.

Many developers really push to the line here, and there's simply no good reason to be uploading unstable builds here. Only submit what you're comfortable shipping, but make sure that on launch date, something is there: even if it's not perfect. Have clear sprints, ensure builds are good for upload, and systematically upload new stable builds whenever you're happy with them. While "perfect, now we sit back" would be ideal - in general you'll be dealing with a few rounds of "better than before", and that is good enough, here.

And then your game releases. Give your team some time to celebrate and/or recover, but try to post-mortem relatively soon after launch. What production expectations were met, and what empowered those teams to achieve that goal? Which production expectations were met, but under unpleasant or less-than-healthy conditions? Which production expectations were not met, and why not? Specifically review the process at-large, and review the lines of communication, responsibility, and accountability.

And please take some time to celebrate. It's a miracle any game ships at all, and if you've made it this far, you've been part of making that miracle happen.

Actionables

• Create or review your milestone schedule, and try to break it down similarly to my examples above. Define the goal, strategy, resources, and timeline. Try to be complete without necessarily trying to be exhaustive: you simply cannot prepare for everything, it is way more important to create clear goals and deadlines for your project.
• Every project has its own needs, and mapping out your milestones should come from the highest priority needs. If your project is time-bound (ie. you have a set date), establish Milestones in collaboration with your team after deducting buffer time. If your project is not time-bound (for example, when you're pre-pitch), establish Milestones in collaboration with your team and add buffer time. But needs are also project-based: for example, you might want to discuss what you think the ratio between Feature- and Content will be or is for your game & genre.
• If you're not doing progress-tracking, I very strongly suggest you do so. There's no way to see how you're doing if you're not keeping track of it - so do evaluate your options for it. Indies -depending on size- use anything from general-purpose tools like Notion, Kanban boards like Trello or Codecks, or more integrated AAA-scale trackers like Jira or Asana. The tools all do the same thing in different ways: focus on finding a tool that would help your team report their progress to you.