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 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.
Forming a clear intention for the game, with some ideas about the style, gameplay, and purpose.
Designers, Concept Artist, Prototype-focused Engineers
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.
Testing the idea, and ensuring the idea is viable, versatile, and possible.
Rapid iteration, convergent thinking.
Designers, Concept Artist, Prototype-focused Engineers
For a smaller production, up to several weeks. For more complex games, up to two months.
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.
Establishing, testing, and improving the production pipeline, ensuring you can hit envisioned goals, establishing timelines.
Encourage a full production cycle on a significant segment representing the game experience.
Experienced members of all major disciplines.
Depending on the amount of scaling the studio needs to do for the full production, this could take up to a quarter of the total development time.
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.
Creation of features and content, focusing on features (or 'verbs'). Iterate on the production process.
Ensure all teams have access to relevant resources and information, keep track of potential delays & blockers and adjust down the line accordingly.
Full production team.
This segment of development (up to 'feature complete') is generally between a quarter and a third of the game's development.
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.
Completion of core features and 'verbs', allowing a focus on content and asset creation for the rest of the development process. Evaluate common reasons for delay and smoothen them out as possible. Additionally, to create the 'golden path' if possible.
Focus on supporting core feature development, striving for a process where core features are never or rarely blocked by other development processes.
Full production team.
"Feature Complete" is highly variable, and depends on the genre and complexity of the features, and the ratio between features and content in the game. For most titles, this will heavily weigh towards 'content', and as such, you'd want to leave 30-50% of your development timeline focused purely on content.
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.
Completion of content, placing the game in a fully playable state from start to finish. Tutorialisation is fully implemented, and the project & vendors are ready for localisation & final QA efforts.
This is mostly a book-keeping exercise - keep track of expected output versus actual output, and continuously triage remaining content with relevant leads.
Full Production Team, start of team size reductions as team members required for ideation start moving to a future project.
"Content Complete", or 'Beta', indicates the end of the Production cycle, and moves the game into wrap-up. For a $300K-range indie game, you probably want to arrive here 8 to 12 weeks before launch, and I've found best results when you arrive here no later than 4 weeks prior - while it can be done with less - plenty of work remains, and a lot of it is outside of your control.
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.
A release-appropriate build is uploaded & configured for launch to all relevant delivery methods.
Ensure that you take full inventory of needs & requirements of external vendors & platforms, and ensure you don't become the blocking part of the machine.
External Vendors, Marketing, Key Art, Core Team
Anywhere between twelve to four weeks.
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.
- 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.
Levelling The Playing Field Newsletter
Join the newsletter to receive the latest updates in your inbox.