Making games is hard work. Having been part of the development process of several games, I can say that when you’re in the middle of it, it can seem like messy, magical chaos.
Even in the best circumstances, where everyone is great at their job, and the design discoveries come easily—creative work doesn’t usually follow a logical path!
Without some sense of organization, it’s highly likely that your team will never launch their game. In order to get to the finish line, you’ll need to provide some structure by breaking down the work to be done into specific stages.
So, How are Games Made?
Every project is different, but the games I’ve worked on (primarily in the mobile and AAA space) have all gone through the same four general steps before they are ready for launch.
- Ideation
- Pre-Production
- Production
- Soft Launch
Dividing the work into these stages can help your team understand what type of work you should be doing as your game comes together.
I’ve written this based on my own personal experience as a Quest Designer for World of Warcraft and Senior Game Designer for The Sims. I’ve also led multiple game teams of varying sizes as Design Director, Creative Director, and Game Director at studios like EA’s Playfish, Scopely, Media Molecule, and PlayStation’s London Studio.
My current role is Director of Live Operations at Sumo Digital.
I’ve tried to stay high-level, so these ideas are applicable to almost any team or game. However, there are going to be things that don’t apply to the game you’re making. Take what is useful and leave the rest.
For more specific context on the process of how other specific types of games are made, you can check out these other guides:
I could probably write an entire book on the topic of game dev stages because there is so much to cover.
Keep in mind that there are definitely things missing from this overview. In the interest of being digestible within a single sitting, some things ended up on the cutting room floor!
Note: All views expressed are my own, and aren’t representative of Sumo Digital (or any previous employer).
Stage 1: Ideation and Concept
This stage has one main goal: Prove the concept and make your game playable as soon as possible.
Here are the four primary steps of the ideation and concept stage:
As you can see, there are many nuances to making this happen.
1. Create Concept Brief
First, you’ll need a basic Concept Brief—a summary of your game idea. Your brief must cover genre, target platforms, audience, critical features at a high level, a summary of the narrative, gameplay or design pillars, and the overall gameplay experience.
A standout concept will also showcase a great USP—a unique selling point that sets your game apart from the competition.
Your brief should answer the following 3 questions:
- What excites you about this concept?
- What type of player will enjoy this experience?
- Why will they leave the game they already love to play this one?
Many concept briefs come as a presentation deck (Google Slides, Microsoft PowerPoint). Alternatively, you can create a document that goes further into the concept, giving more details than you typically see on a slide.
It’s important to understand what you want to build, but don’t spend too much time working things out on paper—the true lessons will be learned once you start actually testing your idea through prototyping.
Just get enough written down so that your team can all align around what you’re making together.
2. Engage in Discovery
Once you have a good idea of what you’d like to build, you and your team should engage in discovery to determine whether your concept will work.
Discovery might involve brainstorming with your team to generate ideas, building paper prototypes to refine those ideas, or enlisting the help of playtesters to help you iterate on those prototypes.
There are no set rules for this type of work—if it helps you arrive at an answer, it’s worth spending time on.
3. Build Playable Prototype
Once you land on a core concept that you feel works, your team will likely want to move into a quick prototyping environment such as Unity or Unreal to build something playable.
Overall, the goal of playable prototyping is to prove the idea as fast as possible with the least amount of resources needed—so be clear about what you want to learn and what kind of criteria you will use to evaluate your progress.
Here’s an example of a stripped-down playable prototype from Moon Studio’s Ori and the Blind Forest:
Ideally, you want to build a small experience showcasing your game experience. Initially, that can be as little as 30 seconds of gameplay. Prototypes like this typically don’t contain any assets or artwork representative of your ideal experience.
At this stage, things are quick and dirty—focused on helping you arrive at answers. Once your team is confident about progress, you might want to build a longer experience, 3-5 minutes, for example.
Here’s an example of an early prototype build of the now-popular battle royale Fall Guys:
As you discover and learn, consider also exploring your game from a visual perspective, showing off the art style or a tech prototype that demonstrates the gameplay working within your target engine/environment.
Note: You can complete ideation without this step. However, these types of prototypes are essential if you intend to pursue external investment. Investors often need to see it to believe it, so tech prototypes are worth spending time on in ideation if that’s your goal.
Often, your art team will need to build what’s called a beautiful corner—a small area of the game that hits the visual target. Eventually, you’ll want to grow this playable experience so that it lasts 5 to 10 minutes (or even longer) and really delivers on the promise of your concept.
This concept image formed part of the beautiful corner for God of War 2018 and was used to establish the tone and look of the game:
In my experience, it’s usually a good idea to focus the team around a playable experience that feels like a cohesive session or “chapter” of the game so the demo can stand on its own.
If your game has concepts like levels, quests, or missions, you can often use one of these to demonstrate what your game will offer players.
When to Move On From Ideation to Concept Pitch Deck?
I’ve seen teams struggle to understand when to move out of a prototyping environment (ideation) and begin working on the game within the target engine (typically pre-production). There aren’t any hard rules around when this is right—each game and team is different.
However, I tend to stick to the following steps:
1. Identify clear goals: Prototypes need to be light and lean. They should have clear goals, and the team should be able to build them quickly, prove their hypotheses, and then move on.
There are great examples of lean prototypes with a specific purpose in this GDC talk about Horizon Zero Dawn:
2. Use time wisely: Anything you build within a prototype that passes the test will eventually need to be rebuilt in the target engine, so consider the time, energy, and financial cost of creating elaborate prototypes.
Sometimes, building it twice is the right call, but other times, it wastes time and resources.
3. Focus on learning: Prototypes are best when focused on areas of risk where your team has the least understanding or certainty. Prototyping is a great solution if you’re trying something new and unsure if it will work.
Building it quickly can help you make decisions fast. Contrast this with the alternative: Building it “the right way” in your target engine, where it might take much more time, and you’re not sure it will be a fit.
4. Use comps: Don’t prototype things that can easily be proven by playing them in another game.
Is there a feature you really like from a game you play already?
Get your team into a play session to experience it in that game, and then plan a session to talk about what the team likes and doesn’t like about that particular implementation.
Using other games is far faster and cheaper than recreating that feature in a prototype, and it can be just as effective.
5. Progression can’t be prototyped: Prototypes can be used to prove almost anything. However, they shouldn’t be used for anything involving long-term player progression, metagame, or compulsion loop (long-term engagement).
To prototype game progression in a playable experience, you’d need to build so much of the game and its different systems that it isn’t worth the time investment.
You’d essentially be building the game once in a prototype and then still have all that work to build it in-engine all over again.
The best prototypes are simple, have clear hypotheses, and are gameplay-focused!
6. Beware chasing “fun”: Fun is often very subjective, and chasing it can be elusive.
Suppose fun is the goal of a prototype. In that case, it becomes difficult to measure its success because fun is often a combination of gameplay, visuals, supporting systems, audio, player feedback, and so on.
Typically, “fun” requires a layer of polish that many prototypes lack. Instead, build prototypes that address a clear question that your team has about your game.
Questions like:
- Will this targeting system work for hordes of enemies?
- Will this AoE ability work in a multiplayer setting?
- Is this the right location for the contextual menu?
The above are great questions for small, focused prototypes and don’t involve the word “fun.”
4. Create Concept Pitch Deck
Once you have completed your short, playable demo, if you’re seeking investor funding, you’ll need a concept pitch deck. This document is your concept brief with lots more sparkles.
The pitch deck needs to cover the same information as listed above and should focus on selling the core idea in a way that gets your audience excited. It should also include things like the expected timeline and budget. Amazing concept art can also go a long way in selling your idea.
Here’s an excerpt from the pitch deck with concept art for an unreleased game called Operation Outsmart:
A great way to end a presentation like this is to directly transition into showing off the playable demo at the end.
Word of caution: Do not show unfinished or rough prototypes to investors—many of them are unfamiliar with the process of building games, and they don’t have the experience to look at an early prototype through the lens of what it might become.
If you’re going to show off your game to investors (and you likely will, as this has become a requirement to secure investor funds), you’ll need to make sure it looks great. Fake it if you must: Sometimes, the path to success involves smoke and mirrors at the beginning.
Your pitch needs to sell not only your game but also your team.
Most investors are looking to understand why your team is a smart investment. They typically look for prior experience in other games: A proven team is a much safer investment than a newbie team that has never built a game.
Potential investors will want to know who is on your leadership team (Creative Director, Art Director, Tech Director, Production Director, etc.) and how you plan to staff the team to build the game.
Here’s an example of the team intro section of an unreleased game (pitched to A16z) from Atomech:
You should also have a clear plan for the game’s business model:
- Is your game free to play with in-app purchases?
- Is your game a premium purchase with 6-month DLC packs?
- Is it a lower-cost initial purchase with planned seasons and a monthly game pass?
Note that if your game is planned as a premium purchase with no further updates planned, it will likely be difficult to impossible to find investor funding. An investor will want to understand how the return on investment will continue past the initial couple of weeks past the game launch date.
Here’s an example of the financial projection from an unreleased game’s pitch deck:
It may seem early to decide, but the business model is tied to core design in such a way that you need to make decisions about this early on in development.
In his book Press Reset, journalist Jason Schreier discusses the player revolt that resulted from developer Mythic Games’ release of Dungeon Keeper Mobile with an aggressive free-to-play model.
Publisher EA suggested that the backlash was due to players’ nostalgia for the older games in the series, but Dungeon Keeper Mobile never fully recovered. Its business model simply didn’t work with its core design.
Make a decision about what type of product you’re making and how that product will be financially successful. If you’re seeking external funding, this is critical to mention in your concept—most investors want to understand the return they will see on their investment!
When to Move On From Ideation and Conception to Pre-Production?
At some point, your team will be ready to move into the next stage, which is pre-production.
Here are five questions you can use to determine if you’re ready to do that:
- Core experience: Can you easily explain the core experience of your game to someone outside your team in one or two sentences?
- Unique proposition: Can you speak confidently about what sets your game apart from others and why players will be drawn to it?
- Prototype: Have you created prototypes to reduce uncertainty and prove hypotheses about your gameplay?
- Playable demo: Are you able to show off your core gameplay through a playable demo?
- Pitch deck (optional): Have you created a compelling pitch deck to present to investors?
As you move to pre-production, you should ensure the team has spent time creating a plan covering people, products, and processes for the next stage. For example, you should know what roles you need to hire for before starting any work.
Think about how you’d like to utilize outsourcing, create a production plan that prioritizes how you want to build your game systems and content and put an initial estimate of how much time you think it will take to build the game.
This pitch deck image from an unreleased Atomtech project gives an estimated production timeline:
It’s especially important that your team understands the design and technical challenges that will be addressed in pre-production. These will be your areas of greatest risk and uncertainty.
Stage 2: Pre-Production
In this stage, your team will take what they’ve learned in the ideation stage and prove that the game concept they’ve come up with works as a full experience. They achieve this by building a part of it in the target engine.
In addition, pre-production is where the team will engage in the groundwork of planning, preparation, and targeted innovation to make the upcoming production stage as predictable as possible.
Here is an overview of the general steps involved in pre-production:
Pre-production is a fun and eventful stage where your team will really see the game come to life!
It’s also a time when you simultaneously know very little about some aspects of the game but quite a bit about others—a potentially anxiety-inducing time for some team members.
There might be many great, innovative ideas, but it might still be unclear how all the pieces fit together to create a cohesive experience.
1. Fill Leadership Roles
One of the first things that needs to happen in pre-production is to ensure you have a solid leadership team. Ideally, you’ll have experienced craft leads in all areas who are committed to the project and will guide it through to completion.
The roles that you settle on might shift from project to project, but generally, you’ll want the following:
- Project Lead (sometimes called General Manager, Executive Producer, or Game Director),
- Creative Director or Design Director
- Technical Director
- Art Director
- Director of Production
- Audio Director (possibly)
If you’re leading a small team, these may be called Leads rather than Directors, as titles can shift based on team size.
If it’s a very small team, it’s possible that one person might take on more than one of these roles! Regardless of their specific title, their responsibilities on the project are the same.
Extreme examples include games like Stardew Valley and Undertale, where a single developer took on the entire project.
Craft leads will be responsible for key decisions, making the call on priorities, features, and content for the game, and ensuring progress in their area(s) of ownership.
Forming this team early ensures that each area of the game has the attention it needs and that there is a clear game vision, which is absolutely essential for your team to be successful in pre-production.
Because these roles are so critically important to the project, bringing someone into a role like this later on can disrupt project momentum and cause restarts / extra work.
When making changes, the intention may be to correct a mistake or to realign with the product vision. However, sometimes it happens because someone joins and wants to put their mark on the game.
Either of these situations can cause disruption. Ensuring that lead roles are filled very early minimizes this possibility and creates an environment of consistency for the team.
2. Establish Game Vision
In the ideation stage, the team did early work to define the core concept—what’s often called the Game Vision. In pre-production, you’ll need to evaluate how clear the game vision is for the team.
If there are areas that raise questions, ensure that the team engages with these questions and finds concrete answers.
Questions can be any number of things—some examples:
- What genre is the game?
- Is it single-player or multiplayer?
- Is there PvP?
- What role does narrative play in the game?
- Who is the target audience to be served by the game?
- What are the target platforms for launch?
- What are the closest comps? (What games are similar to your game?)
- What are the core features of the game?
- What are the pillars of the design that guide decision-making?And so on…
Ask the team what they feel is unclear, then work towards clarity in those areas. Sometimes, answers will come from leadership making decisions; other times, they will come from prototyping or discovery work.
Either way, it’s essential that the team works together and gets to a clear, shared understanding of the high-level direction of the game as early as possible. The more clarity the team has, the better they can focus and the more progress they’ll make!
Word of caution: Don’t underestimate the importance of a clearly defined game vision.
When a game is loosely defined, each team member might have a slightly different idea about what they’re building. It’s easy for a team to get lost in its ideas, drift, and lose focus, especially as new hires and ideas are added to the mix.
A strong game vision is the best way to keep the team all moving in the same direction together!
3. Build Vertical slice
During pre-production, the team is often focused on building a smaller version of the eventual experience, showing many different aspects of the game. This version is different from the prototyped experience built-in ideation in several ways.
This experience will be built in the target engine, which is typically more detailed and contains more gameplay. The pre-production build will form the core around which you’ll build the rest of the game in production.
This experience is sometimes called a vertical slice because, in some cases, it contains a small version or slice of each game feature or system in the final game.
In this GDC presentation, Volition’s Greg Donovan discusses the studio’s process for making vertical slices and what elements they find essential to include:
In my experience, based on the complexity or scale of your game, creating a small version of each system or feature may not be feasible, and that’s ok. The team can decide on a reasonable scope for the Vertical Slice based on what makes sense for your project.
If your game is centered around matches, levels, or missions, then build a match, level, or mission.
Sometimes, creating a full zone, a set of levels, or a collection of missions might make sense.
You’re looking to build a version of the game that can stand alone and demonstrate at least 30 minutes of gameplay.
Whether it contains every system you’ll eventually build isn’t a requirement—but it should feel like a cohesive experience from start to finish, containing gameplay, narrative, systems, UI, and any supporting features required to ensure the experience feels like you expect the final game to feel.
If it’s core to the game experience, it needs to be in the vertical slice in some form.
From a design perspective, the most important thing during this stage is to prove out the core gameplay loop, focusing on the gameplay feel and player journey. Having a cohesive start-to-finish experience that represents the game—even if it’s short—is crucial.
Don’t underestimate the impact of small details—such as a fully realized character with an animation set, a title screen, music and other audio cues, end-of-match celebration feedback, or icons rendered in the final art style.
4. Set Priorities
During pre-production, the design team should be as confident as they can about a feature roadmap. This document lists all of the features the team will need to build in the order of priority that they should be taken on.
Prioritization is more of an art than a science. Consider the level of risk and unknowns, dependencies within the design, and dependencies across different areas of the team.
For example, even if a feature is straightforward in terms of design, it may be bumped up in the list if it is expensive from an art perspective or complex from a technical perspective.
From a visual perspective, a goal for pre-production is to define the art style by exploring all aspects of the game’s visual appearance while the design team works out the gameplay.
The visual aspects of the game should be collected in a detailed art style guide, which the team (and any outsource/co-dev partners) will utilize during production and beyond to ensure visual consistency across all parts of the game.
Here’s an example from Riot Games’ style guide detailing how artists should approach and implement visual effects in League of Legends:
Every part of the visual approach should be part of your style guide—characters, environments, surfaces, VFX, menus, icons, lighting, animations, cinematics, and so on.
Optionally, the same exploration can happen for audio as well if your team has the ability to do so in pre-production. Audio is typically not a focus early on for many teams, but it can make a huge difference in the feel of a game.
If your team has the ability to bring in audio early as part of the game vision, do it!
5. Set Up Workflow, Pipelines, and Tools
On the technical side, it’s essential to develop the workflows, pipelines, and tools the team will need to produce the game efficiently and predictably during pre-production.
Asking the following questions can help nail down:
- Steps: What steps will the team use to create a level? What about a character? Props? Cinematics? What are the steps for checking in code?
- Team cooperation: How does the design team work with the art and coding teams?
- Features: How are features developed and approved?
- New build frequency: How often will a new build be produced?
- Building and testing: How will designers and artists build and test their work in-engine?
If it’s something that your team will need to do reliably over and over, it needs to be standardized. Establish these ways of working during pre-production and make sure your entire team utilizes these workflows.
Once the team transitions to production, it must be able to create game assets and other content predictably. Without established working methods, the team will struggle to make progress.
Usually, if the team has grown in size, it will also end up in a situation where the lack of consistency makes the game difficult to build predictably and more prone to bugs.
In addition, established workflows help your production team understand how to plan for the upcoming production stage.
Here is a great example of an visual overview of how a dev team workflow and pipeline:
Teams that know how long it takes to build the assets and game content can more predictably estimate their timeline, and therefore, they are more able to scope their final experience effectively.
For example, if it takes two months to build, rig, animate, and fully implement a single character into the game, it becomes easier to estimate how long it will take to complete the 12 characters planned for launch.
Your team will immediately know how to prioritize this work against other work, if more hires are necessary to speed up the work, or whether they need to cut a character or two to hit the desired deadline, for example.
6. Outsource Asset Creation
Pre-production is also great for establishing relationships with possible co-dev or art outsourcing teams. If the intention is to use external teams to complete some percentage of the work in production, it needs to be planned for in pre-production and agreed upon with each external team.
In the case of both design and art, outsourcing guides should be created to help an external team understand the work and how it should be completed, aligning with any processes that the dev team uses internally.
For example, companies like RetroStyle Game Studios specialize in creating full-cycle 2D and 3D art assets for larger studios:
Production will need to account for the lead time required to send out for these assets, time for feedback, and work out what the approval process looks like.
Most teams require a dedicated outsourcing manager who can liaise with external teams and ensure that they get what they need throughout the process. The manager also needs to receive clear instructions from the team on what needs to be built.
7. Test with External Users
Testing with external users should be a part of pre-production. This testing can take several forms:
Concept testing: Get responses from the expected target audience on the game concept, vision, or narrative. This type of testing can be used to identify if the audience you’re after will be interested in what you’re offering.
It’s more effective when delivered as a story/experience of the game through the player’s eyes versus a list of features (which the average player may not know what to do with).
With this type of testing, ensure that these concepts are written and polished by a writer rather than a game designer. They need more of a marketing twist than just a straightforward description of gameplay or features.
Aim for a “back of the box” style description that gets people excited like this one from the original release of WoW:
Art style testing: Get responses from the expected target audience to the art style overall or a specific part of the game (like characters). This type of testing is useful for gauging player reactions to your game’s visual style.
Artists will often go through many iterations of characters, props, buildings, and weapons before landing on the final version.
The art style in the Zelda series has kept some key elements while varying widely across its many iterations.
These images detail the evolution in both graphical fidelity and stylistic choice:
Use results sensibly. Players sometimes have stronger reactions to art style without gameplay than if paired with a playable experience. This effect can be positive or negative.
Usually, what I look for with this kind of testing is to ensure there isn’t a strong negative reaction. If you’re in neutral to great territory, you’re fine. Keep in mind that audience reaction should never be the key metric used to validate or choose between art styles.
If you want opinions on the quality of the art or the style itself, ask experts, not random players.
Playtesting: Get responses from the expected target audience to a real, playable version of the game. In pre-production, it is incredibly important to test the experience often with testers who have never seen the game before and know nothing about it.
It’s common for a team to get tunnel vision, where they no longer see the flaws or problems with their game. Bringing in playtesters who haven’t seen your game before can be an essential and eye-opening experience.
In this GDC talk, BioWare’s Barbara Klimek explains the importance of testing at every level of the studio’s process:
Playtesters can help you understand what is confusing or unclear, often doing things you don’t expect. Then, you’ll need to decide if you want to fix those things or lean into them.
While I have utilized all three types of testing in the past, I would say the first two are optional, especially if funds are tight.
The last one is never optional: Your team MUST engage with external testing to validate the gameplay.
This may be challenging on a minimal budget, but there is no better way to get feedback than to have people play the game.
Finally, if you’re creating a live service game or any game that intends to have a live-operated component, you should start exploratory work in pre-production.
For example, consider spending time ensuring your product’s business model is viable through economy modeling and a base monetization pass. You could also create a live service roadmap that shows you have a good understanding of how you’ll support your game when it goes live.
When to Move On From Pre-Production to Production?
Here are some questions you can use to determine if you’re ready to move into production:
- Is the team feeling confident about moving forward with the playable experience/vertical slice? Do ALL parts of the team feel ready?
- Has the team arrived at answers to the design and technical challenges identified in Ideation?
- Has the team created a prioritized Design / Feature Roadmap?
- Has the team established the art style and created an Art Style Guide?
- Have you proven the value and appeal of your playable experience by testing with external playtesters?
- Have workflows, pipelines, and tools been created and tested so that the entire team can use them?
- Has the team used estimates gained in Pre-Production to create a Production stage timeline, hiring plan, and outsourcing plan?
- (Optional) Has the team engaged in concept testing to gain insights into the art style, narrative, or game concept?
Stage 3: Production
Production is where development kicks into high gear, and your team will scale up to develop and implement content and systems along a predictable schedule as they prepare for launch.
Even the best planning can’t remove all of the risk and unpredictability of game development. Still, if your team has utilized the pre-production stage well to establish what needs to be built, production can run as smoothly and efficiently as possible.
The production stage typically adheres to the following steps:
Prior to this point, your producers may be in more of a facilitation mode—helping the team with some basic structure as they define the game experience, allowing for a lot of flexibility and freedom during early discovery work.
In the production stage, producers will step up and collaborate with all parts of the team to determine a realistic timeline for the game.
1. Evaluate the Project’s Scope and Create Milestones
Producers must now engage in a scoping pass of features and content, ensuring a clear and consistent process for the team to follow—one with deadlines, approvals, and, at times, difficult choices to make about what’s in and what’s not.
Getting the team comfortable working quickly and adhering to production deadlines is especially important in creating a live service game. In such cases, launch is just the beginning, and the production of features and content will continue into live operations.
Predictability becomes a key goal, and everyone on the team needs to hold themselves accountable for delivering each milestone on time.
More attention should be paid to quality assurance as well—it’s not enough to finish the work. It needs to be tested and as bug-free as possible by the agreed-upon deadline!
2. Build Content and Features
The team should continue following the roadmap laid out in pre-production, building features and content, iterating where necessary, and revisiting the roadmap priorities with their producers at a regular cadence.
There will still be discoveries and big design decisions to make in production, but overall, the team should understand what they are building, and as they progress, the game will really start to come together.
Forming milestones based on playable experience goals is an easy way to make the work tangible and easy to understand for every discipline on the team.
First, engage everyone around a single concept. Examples could include:
- A feature: The weapon crafting system will be fully functional and integrated into the game.
-or- - A chunk of content: The entire second zone will be fully playable and polished.
Taking these (or any other ideas you come up with) as a milestone goal—and then allowing the team to figure out what needs to be built to reach that goal often works best.
3. Scale Team
Production is when the team will scale up to its largest size. Much of this expansion comes from bringing on designers and artists entirely focused on creating the content for the game.
Quests, game objects, character barks, level layouts, boss encounters, spell effects, and loot are just some of the many examples—chances are you will need to bring on additional staff to create the content the game will require.
If the systems for each of these have been well-defined, and clear examples are already in the game (at the quality bar the team would like to hit), you can bring on less-experienced staff to create this content.
Some of us got our first chance at being game designers in a role creating content for well-established systems. I started my design journey as a quest designer on the original World of Warcraft.
I was lucky to join when all of the game systems were largely figured out (only Talents and Reputation went through big changes during my time). It was an environment where there weren’t big questions about what quests were or how they might function.
We had a clear vision of what makes a quest and an amazing editor with which to implement them. Quest design felt like playing in a big toy box all day: If I had an idea, I could usually figure out how to build it.
It was a wonderful way to learn how to be a game designer. If that’s your goal too, I hope you find a role like I had, where you can learn how to build content first before taking on more complicated aspects of design.
The guard rails created by WoW’s years of quest design and excellent editor allow Blizzard to churn out memorable quests like this one from the Dragonflight expansion nearly 20 years later:
With a larger team, you’ll find that it may make sense to have different parts of the team working on different goals. This sometimes happens when an entire system needs to be built, but it doesn’t necessarily represent playable content.
For example, your engineering team may be focused on building backend support for eventual live services during production—something that needs to be done, but may not align with the playable content that the rest of the team is building.
Multiple goals can complicate planning and make it harder to keep everyone moving in the same direction.
Wherever possible, try to align the team against the same overall milestones. Otherwise, things will get out of sync, making communication more challenging across the team.
If you start to hear the word “siloing” or if people start to complain that they don’t understand what a different part of the team is doing—that’s a warning sign that you need to pull everyone together and realign everyone against the vision and create milestones that represent work that everyone can engage with.
4. Playtest Internally and Externally
Playtesting should continue into the production stage, and the cadence of tests should become more frequent. The entire team should play the game weekly (if not more often) and set aside time to talk openly and honestly about what is working and what isn’t.
Of course, external testing with a larger group of players is a must. That feedback is invaluable in production, helping to find elusive bugs, exploits, and unexpected complexities. Feedback should be analyzed organized and discussed; the highest-priority fixes and changes should become tasks in the next sprint.
Here is an example playtest report analysis:
When playtest feedback internally begins to trend positively, this is a great time to consider exposing the game to a much larger audience. You can look for cues like positive internal survey data or listen for comments on the team like “The playtest today was awesome,”
I’ve found the best way to gauge if you’ve got a great game is when the team starts playing it on their own, unprompted and outside of any mandatory team playtests.
Conversely, if you have a game that no one on the team plays unless they are forced to, that can be a warning sign that something is not quite right.
Once the team feels confident about the core gameplay and that the game has enough playable content, they should prepare for an early launch stage. This can be called by different names:
- Mobile development: In mobile development, the early launch stage is often called soft launch. This can mean testing the game by releasing it live for an entire territory (mobile companies in the US often release soft launch builds in Australia, for example) and then using the data from that test to make tweaks to the design or economy:
- PC/Console development: A PC or console game dev team might call the same stage Alpha, Beta, or Early Access.
No matter what you call it, this is a build of the game that is intended for a wider audience.
Or, early launch might mean starting small with a Friends and Family Alpha release, which eventually flows into an External Beta with a public, much larger player base.
For soft launch, your team should determine the features and the amount of content that will be part of the release. In some cases, you will be aiming to maintain an audience, so a good rule is to have 30 days of content in the game, with more in the pipe ready to release within that initial 30 days.
For example, Call of Duty: Mobile soft-launched in Australia, Canada, and Peru:
Player retention is a key factor in designing online games with regular updates and events. Having sufficient content in the pipeline gives your game the best chance at holding onto some of those initial installs.
The typical player retention curve for new mobile games looks something like this:
The better the game’s design, the longer its tail of retention will be.
In other cases, such as a single-player, narrative-based PC, or console game, the build should contain some percentage of the final levels, missions, or areas at a high level of polish.
There is no standard requirement for this type of soft launch, but the release should contain enough content and core features so that your team can gauge the audience’s reaction. Ideally, your early release gives players a taste of your full experience and entices them to stick around for more!
Finally, suppose the game is intended for live operation. In that case, the production stage is where the team needs to take measures to ensure they are ready for the relentless nature of running a game live by polishing the team tools, automation, and pipelines.
Allocate time to implement telemetry hooks (trackers that let the team understand what players are doing) into the game. There are off-the-shelf solutions that you can integrate or you can roll your own, but this is a requirement.
In this video, Sanju Sriram from 2K Games discusses architectures and best practices for real-time game telemetry:
If you don’t know what players are doing in your game, it’s impossible to balance it well or make strategic changes to better serve your audience when the game is live.
Another requirement for moving to Soft Launch is to ensure that monetization is fully functional and working from a backend perspective.
The design doesn’t have to be final (you can make changes during Soft Launch), but if you are going to take real money from people, it needs to work flawlessly prior to the Soft Launch date.
Toward the end of production, the team should prepare to manage the needs of the player base by developing a plan for several aspects of running a game.
The following is a checklist of questions to help your team prepare for an active player base:
- Growth: How will you grow your audience?
- NDA: Will they need to sign an NDA? (Is this a private or public release?)
- Deployment: How will you deploy builds to players?
- Uptime: What uptime will the game have? (Are there specific testing times, or can players play whenever they like?)
- Communication: What mode of communication will you use to communicate with players?
- Feedback: How will you gather player feedback?
- Contact: How can a user contact the team, report a bug, or discuss the experience with other players?
- Community management: Who will take on the role of community manager?
Consider how you will market the game at launch and acquire users. This might mean making a plan for your internal team or reaching out to an external marketing team that will handle this as a partner to your team.
In either case, it’s key to develop a plan for how you will reach your audience once the game is live. This doesn’t have to be overly detailed, but it’s critical to make some basic calls about how you want to present your game to the world through visual marketing, endorsements from Twitch streamers or other influencers, etc.
Video game marketing has changed dramatically since the medium’s inception, becoming ever more sophisticated.
This trailer for 2006’s Gears of War was one of the first to opt for an overtly emotional tone—something new for video game advertising at the time:
When to Move On From Production to Soft Launch?
Some questions that can help your team determine if they are ready for Soft Launch:
- Does the game include enough content, features, and polish necessary to release to a large audience? (What this looks like varies depending on what type of game you’re making.)
- Are the content-building tools, team workflows, and production pipelines well-defined and prepared for live operations? (Note: Even if you aren’t creating a live service game, these things might be used for DLC or further updates, or even sequels, so they are worth spending time on.)
- Has the team created their live operations roadmap for content and features, and are they prepared to deliver against it?
- Does the game contain telemetry hooks allowing the development team to track what players do over time?
- Is your team prepared to manage an active community of players who formally share builds, communicate regularly, and respond to player issues and concerns?
- Is monetization (in-game purchases, real money transactions) complete and working flawlessly?
Stage 4: Soft Launch
Soft Launch is the stage where the team adds and adjusts the final features, content, and game balance and proves that the game is ready to be supported in live operations.
This is achieved in several steps. Here is a brief overview:
Let’s break down each step.
1. Finalize Workflow and Pipelines
Up until this point, developing the game usually feels like building the ship when you’re already sailing in the ocean.
The team will be doing their best to put the game together, but there will be situations where features, assets, tools, systems, or workflows haven’t been created or implemented yet, making progress sometimes feel slower than desired.
Gaps in content and functionality will make it difficult for the team to say that the playable experience is “done.” In soft launch, the team should ensure they address these gaps, finalize workflow or pipeline needs for live operations, and tie all the game features together.
2. Refine Playable Experience
From a design perspective, the team should be focused on refining the playable experience so that it is as good as it possibly can be. This generally isn’t the time for sweeping changes, although they will likely be adjusting game balance up until the game goes live.
Sometimes, cutting or scoping back features and content is the right call when something just isn’t coming together. It’s always better to release a smaller game that has a higher level of polish rather than a larger game that is uneven in terms of how finished it feels.
An important part of refining the playable experience in later stages of development is polishing the First Time User Experience (often referred to as FTUE or “Tutorial”).
The first few moments of your game are incredibly important—players will decide in only a handful of minutes whether or not they will continue playing.
How will you:
- Explain how to play the game?
- Engage them with fun moment-to-moment gameplay?
- Show off all of your engaging features?
- Hook them with a great narrative and progression path?
Your FTUE will be a part of the game that you iterate on, over and over, tweaking it to get it just right—which is why you want to wait until late in development to implement it.
I’ve seen teams waste time on this in the beginning stages of development and then have the burden of changing it with each design iteration. While you may want to implement light tutorials for any public playtests, it’s best to wait until the game comes together to implement the FTUE that most players will experience upon launch.
In mobile gaming, first recharge rewards are another way of getting players invested early on. Here’s an example from the game Mobile Legends:
There are no strict rules about what you include as part of your FTUE, but here are four suggestions:
1.Teach players the basics: What are the core moves or actions that players need to know how to do in your game?
The FTUE should show them. Introducing new mechanics later is fine—so cut this down to the core. What’s the minimum they would need to know to be successful?
2. Ordering and pacing matter: It’s important that elements are introduced in a way that is manageable. Players can’t take in too much information at once, and any information they are presented with should build on what they already know.
Remember, everything the player is seeing in your game is new to them, so the potential for cognitive overload is high. Figure out how to simplify, draw focus to what’s important, and then slowly show more over time.
Many games reduce the elements of the UI that show at first, and then reveal them as new mechanics are introduced.
3. Integrate it into the story/gameplay: The best tutorials are those that are cleverly integrated into the path that players will be following as part of their intro experience.
There’s nothing worse than the game saying to a player: “Before you can actually play this game, we want to teach you how to move and jump…” It breaks people out of the experience they are there to have.
Figure out how to teach a player your controls and systems within the construct of your story or premise, without calling attention to it as a separate experience.
Zelda: Breath of the Wild is an excellent example of an effective tutorial and starting area that are as fun as they are instructional:
4. Players don’t like reading: If your tutorial involves a bunch of pop-up tutorial windows that require players to read to understand what to do, be prepared for them to skip over them and then not understand what to do.
Find another way to show them because most players don’t want to read your carefully written instructions. Many mobile games do this skillfully by highlighting parts of the screen, animated buttons, and pointing emojis. The more visual, the better.
3. Share with Players
Outside of any beta or alpha builds, soft launch is the first major opportunity to show players what you’re offering—and this first release can often be the moment that makes or breaks a game.
If you show players a build that lacks the polish or depth of experience they expect or doesn’t introduce the game in an accessible way (such as with a great FTUE) they may lose interest, stop playing, and then tell their friends about their experience.
Once you’ve lost a player this way, it’s tough to get them back—even if you make the necessary changes later.
Many years ago, I worked on a game called Auto Assault. It was a unique offering for an MMO: think Mad Max, post-apocalyptic setting, customizable cars with big guns.
Here are some gameplay stills and concept art:
Unfortunately, the game didn’t survive even two years after its launch.
The main failing of Auto Assault was the lack of end-game content for players to engage with once they hit max level, followed closely by the quick pacing/leveling speed—a deadly combo for any MMO.
Players loved how fast they could reach the max level, but once they got there, there wasn’t much to do. Customizing your car is only fun for so long.
After launch, as the game floundered, we knew that it needed a re-balancing pass as well as a strong strategy for long-term progression—things that you typically should figure out well before launch, not afterward.
We did implement some changes including a complete refresh of the crafting system, but it was too little, too late. Auto Assault never recovered, and the publisher eventually shut the game down.
First impressions tend to stick.
Because of this, it cannot be overemphasized that it’s best not to move into a soft launch stage until the team feels like the game is truly ready for a wider audience.
While mobile game developers tend to release features well before they feel finished, this approach isn’t right for every audience or platform. Console and PC players tend to have higher expectations and will react much more negatively to anything they perceive as unfinished.
No matter the platform, releasing a feature or chunk of content too early can yield results and data that aren’t useful to the team or cause them to conclude that a feature isn’t working at all. If they had taken the time to polish the experience a bit more, it might have resulted in a different outcome.
Take the time to understand player expectations and ensure that the team feels confident before sharing anything with a wider audience.
Generally, the bar for soft launch is to ensure that the game is feature complete (in terms of core gameplay) and that there are no critical bugs that impede gameplay—issues like crashes, problems with memory, saving player state, or anything related to monetization are must-fix!
In this GDC talk, Epic Games’ Ed Zobrist describes the challenges of launching Fortnite (and how much that game changed during development):
Once the game is live, it is the point of no return for community engagement. Make sure you’re prepared to invest time and energy in the direction of maintaining the community of players who are engaged with your game from this point forward.
Releasing updates inconsistently or going dark can be incredibly damaging to this relationship. Players may also have issues installing or running the game and will look to you to help them, so be prepared for the level of technical support required.
Parse Feedback and Measure KPIs
Soft launch can be a complex balance. Many new responsibilities must be taken on, including managing players’ needs while continuing to develop features and content.
One of the biggest changes in this stage will be that feedback will now come from the players in addition to the team. Understanding the vision—what that game is and what it isn’t—will be more important than ever at this point.
Because the volume of feedback will likely be considerable, it’s impossible to please every player. Learning how to parse all of the feedback and understanding which parts to listen to and which parts to ignore will be critical skills for everyone on the team.
In addition to the feedback, you’ll also have a lot of player data to parse. This data usually provides information that aids the team in balancing changes, ensuring that players are experiencing the game in the way that the team has intended.
For example:
- Leveling speed & progression: If players are leveling much faster than expected, you can adjust the leveling curve so that it takes longer to level up, or you might reduce experience rewards for quests or for killing enemies in order to slow the pacing of progression.
- Overpowered abilities: In a multiplayer setting, if players are using one particular weapon or skill more than others, you can rebalance it against the others so that it’s no longer overpowered.
- Overall balance: If players die disproportionately in one particular encounter, you can review it to see why. Fixing the issue could mean changes to level design, enemy design, or player abilities. Sometimes, issues like this are very difficult to figure out and can be caused by something unexpected!
- Disengagement: If players quit the game at a very specific point, you can evaluate the user journey to determine why they might be leaving. Is something broken? Are they losing interest?
The list of things you might evaluate can be endless and consume a lot of time to review— focus on the instances that you feel are the most important.
Finally, during soft launch, the team should discuss the global launch and develop a plan that covers the target release date and where the game will be released—perhaps there is a staged launch for different territories or platforms, along with estimations for the first few post-launch releases (if applicable).
The process of launching a game can be quite different depending on the release platform, but all of them have some form of approval process. Whether you’re releasing on mobile (Apple / Android), console (Switch / PlayStation / Xbox), or PC (Steam), the build you submit will need to go through a formal review.
Australia has a notoriously strict approvals board. So much so that games like Disco Elysium remained banned there for several years, despite its relatively low levels of violence and the game’s clear artistic merit:
This review should be factored into the release timeline, as your game may require multiple changes and resubmissions before it is finally approved for release.
Plan backward from the launch date you’re targeting to understand when you should lock down that final build for submission. Depending on the release platform, it can take 5-30 days.
If you’re launching a live service game, the date the game goes live is such an exciting moment because it is just the beginning of the game’s lifespan. However, it is not always a smooth process, and your team should understand the possible scenarios and what needs to be done if they occur.
Soft Launch is Too Successful?
A problem many of us have all seen or experienced in the past for some games is that they are too successful at launch! When players face login queues, can’t log in at all, or experience lag or other load issues.
It can spell disaster for early reviews and can negatively impact early trajectory when players experience
- Login queues
- Can’t log in at all
- Lag (or other load issues)
This happens when the team underestimates the potential popularity of the game and is unable to support all the players who want to play it. This is usually about hardware (servers) and the right type of backend architecture to support a user base that may increase in size, rapidly.
I’ve personally experienced two game launches like this: World of Warcraft’s initial launch in 2004 was bumpy because the team completely misjudged the number of people who would want to play. This resulted in hours-long queues for players and a shortage of physical copies in stores.
In 2011, the launch of The Sims Social on Facebook was initially disastrous. Millions of people tried to access the game when it was released. (Peak players for the title were around 65 million.)
We had to turn off access for entire countries because the server load was more than the team had ever experienced for other Facebook games they had launched:
Both of these examples are from years ago, but launches like this are still occurring now—the launches of Helldivers 2 and Wayfinder in 2023 are both examples of audiences responding much more enthusiastically than the team expected—as this image from the Helldivers 2 Steam Chart can attest:
As problems go, it’s a wonderful one to have, but not being able to play when they want to can impact players’ first impressions of the game, and your team should come up with a plan for how they will handle it if it occurs.
There are optimal ways to prepare for moments like this that involve scalable server architecture and spending time on scenario planning. It’s something that needs to be planned for from the beginning of development.
Live service architecture is a big topic that we can’t cover in depth here, but if live service is a goal, discuss solutions early and often.
Too many teams leave this topic for “later,” which presents nearly unsolvable problems for the team after the game launches because the game does not scale for live service in the way it needs to.
And, of course, the opposite issue exists as well. For indie teams, often the challenge is that they cannot get enough eyes on their game at launch. Maybe the marketing budget didn’t allow for wide reach or other, higher-profile games released that same weekend.
Either of these situations can mean that your game is effectively invisible. This can even happen when your game is super fun, polished, and amazing. It’s not enough to just create a great game anymore.
Titanfall 2 was an example of a fun, highly-polished experience that never reached the level of popularity it (arguably) deserved due to a combination of marketing errors and launching several days before Battlefield 1:
We now exist in a time when there is a proliferation of games out there, meaning lots of competition for players’ attention.
User acquisition is a challenge right now for everyone, no matter the size of your marketing budget.
Your team needs to discuss how they plan to acquire users through as many channels as they can manage, creating a plan that begins several months before global launch and continues several months after launch.
It might involve influencers, Twitch streams, early reviewers, and strategic partnerships or other promotions. The community managers are going to be working almost nonstop to engage with and grow the game’s audience.
Positive early reviews from sites like IGN can make a massive difference to the discussion around a game’s launch:
During this stage, the team should be measuring chosen KPIs (Key Performance Indicators). Soft Launch gives your team time to see what players are doing in your game—which elements they are engaging with, how they are spending their time, and which features are popular. This is less about game balance and more about game performance.
There are KPIs that are most commonly tracked and measured, and your team will need to decide which of these are meaningful for your product. KPIs are a topic of depth, and we can’t go into all of that here, but here is a quick list of eight KPIs that might be useful when evaluating your game’s performance:
- Daily Active Users (DAU): The number of unique players that engage with your game on a daily basis.
- Retention: The ability of a game to retain users over time. Day 1, 7 and 30 are the ones most popular to measure.
- Engagement: The level of interaction a player has with a game. Measured in metrics such as session duration, frequency of use (such as number of sessions daily) or churn rate.
- Acquisition: The process of obtaining new users for the game. Measured in the number of new users.If your product has microtransactions, these will be useful:
- Growth: The increase in specific metrics such as users, revenue or market share over time
- Revenue: The total amount of income earned. Usually tracked daily / monthly.
- Average Revenue per Daily Active User (ARPDAU): The average amount of revenue that is generated per player, per day. This is calculated by dividing total daily revenue by the number of daily active users.
- Conversions: The process of turning non-paying players into paying players. Tracking Conversions usually means tracking daily paying users.
- Lifetime Value (LTV): The total revenue that a player is expected to generate over the entire period of time that they are engaging with the game
Soft Launch can be as short as a month, but it is typically longer, depending on the changes and refinement needed.
When to Move On From Soft Launch?
The following questions can be used to assess if your team is ready for a global launch:
- Are all of the core features implemented, balanced and working as intended?
- Has the soft launch proven that the game is capable of hitting KPI targets?
- Have all critical bugs been addressed?
- Has the game been localized for players in the release territories?
- Have you planned for the risks associated with a global launch? Is the team prepared for various possible scenarios?
- Is the team prepared to support a global audience of players?
- Is the team prepared to continue development of the game through live operations, maintaining and growing the audience over time? (Seasons, Battlepass, patches, etc
Wrap Up
Creating interactive art is never a simple process—there will always be some element of laying the tracks as the train approaches. However, quality leadership, clearly defined roles and workflows, and effective communication between teams go a long way.
Ultimately, the creative process involves whittling down infinite options into a singular vision.
That said, too much uncertainty can eat into productivity, causing your team to waste time, energy, and resources on the wrong ideas. The clearer your game vision is from the outset, the easier it is for your team to execute the milestones assigned to them on time.
Chaos and the spark of spontaneity will always be part of the creative process, but a clear vision, well-defined stages, and straightforward milestones act as important guardrails.
Deviation from the steps and processes I’ve listed may be inevitable, depending on the scope and scale of the project. Still, generally speaking, the roadmap for game dev stages is designed to create workflows, pipelines, and contingencies that have proven their value over decades.
2 Responses
This information is really great. Thanks for this.
Great for someone like myself who wants to get into the field to understand how the process works from ideation to completion in easily digestible broadstrokes.
This article has given me excellent insight on what to do for a game and when. It is explained simply while still remaining very effective.