The Game Development Process Explained: From Concept and GDD to Launch

The game development process refers to the stages a team goes through from coming up with a game idea to releasing it. They include the concept, pre-production, production, testing, and launch and post-launch activities. Each stage has different deliverables, and each ends with a decision about the readiness to proceed.

A neat list does not show one thing, which is crucial in real projects. Feedback from playtests brings changes in design, QA sends build versions back for fixes, and an inadequate prototype may bring the entire idea back to the start. This guide takes you through the game development stages sequentially and then describes the gates, deliverables, and feedback loops that keep a project in check. If you are working out the steps to develop a video game, or planning a project with a studio, it gives you a map to follow.

The Game Development Process at a Glance 

Different studios use different names for the stages, but the core process remains similar across all of them. These stages are also an important part of professional game development services, which we will discuss in detail below.

Why the Game Development Process Is Not Linear

One game development school, CG Spectrum, puts it simply: the game keeps changing; an idea might sound great but prove unfeasible, so tasks keep coming back for review, feedback, and iterations. These changes can also affect the game development timeline, making flexibility an important part of the production process.

Two concepts help streamline the process.

• Gates. A gate is a quality control checkpoint at the end of a stage. The team reviews the product that was created and makes a decision: to move forward, fix certain issues before going on, or to stop altogether. A gate prevents an unfeasible idea from draining the entire budget allocated for production.
• Feedback loops. A feedback loop is a flow of information back to an earlier stage of the process. Testing results are fed to design, QA results are fed to engineering, and the results after the release are fed into the update cycle. The faster a loop runs, the less costly changes become.

Stage 1: Game Concept and Discovery 

Every game project begins with an idea, but an idea alone is not a plan. This phase sees the team asking simple questions about:

•        The core concept and gameplay of the title

•        The target audience and other titles in their library

•        The target platform

•        The business model – premium sale, free-to-play, or something different

•        Approximate size and cost of the project

The output is limited to a one-page idea document, information on the market and competition, estimated scope, and a first estimate of team size and budget. The team itself remains small during this phase: the producer, designer, and concept artist, perhaps just one or two people.

Gate: Does the concept have sufficient clarity and potential to warrant the effort of pre-production? Many concepts are cut short at this point, and this is a positive outcome if the rationale is valid.

Stage 2: Pre-Production, the GDD and the Prototype

It is in this stage that most of the risks are stripped away. According to CG Spectrum, it may take anywhere between one week and one year, taking up to 20% of the total production time.

The Game Design Document

The game design document, or GDD, contains the game design itself. The document will usually include information like the concept, genre, story and characters, gameplay mechanics, gameplay, levels and worlds, art style and monetisation. This is supposed to be a living document that changes as the game itself changes, rather than an inflexible agreement set in stone.

The GDD serves three important functions. It makes sure that everyone in the team is still aligned; it shows how big the project is from the start, allowing you to hire or outsource accordingly, and it gives something tangible to show to publishers or investors. Large companies tend to favour lots of documentation. Small teams prefer to keep it minimal and work through development, but a short GDD is better than no plan.

The Prototype

A prototype is a bare-bones playable version of the essential concept. It has placeholder graphics and simple mechanics, because the only issue is whether the core mechanic is fun and sound. Many concepts do not pass this hurdle, which is precisely the reason the phase exists. Initial paper testing and rapid digital prototypes are inexpensive relative to discovery after month twelve.

Prototypes should always be tested on outsiders to the development process. Designers know intuitively many things that a first-time player will find bewildering.

A good prototype test involves only one question, for example, is jumping fun with this control system, or will the card-based economy last ten games? Write out your question before you create the prototype, observe how players perform without leading them, and note areas of hesitation. You will have a hard time deciding whether the prototype passed if you cannot articulate the purpose of your prototype. Some projects require two prototypes: one for the game design, and another for the tricky technologies, such as online play or an innovative controller.

Other Pre-Production Deliverables 

•        Technical design plan for the engine, tools, platforms, and backend.

•        Budget and Milestones.

•        Art style guide and preliminary artwork.

•        List of risks and their respective response plans.

Gate: Has the core loop been validated, and are the plan, budget, and schedule realistic enough? A good gate at this stage will safeguard all the stages ahead.

Stage 3: Game Production 

This is the most time-consuming and costly step. Designers develop levels and systems, artists design characters and environments, programmers code the game and tools, and add audio. Depending on the scale of the project, CG Spectrum estimates the production period at one to four years. But a small mobile game can be made in several months.

Usually, milestones are used to monitor the progress of the team:

• First playable: The first version which demonstrates the final look and feel of the game and has assets instead of placeholders.
• Vertical slice: A small piece of the game, which usually lasts several minutes up to half an hour and which demonstrates the quality of the game for a publisher or investor and tests the production pipeline.
• Alpha: The game is feature complete and can be played from the beginning to the end but lacks polish and fine-tuning. Bugs start being reported by QA.
• Beta: Content and assets are done. No more features are added to the game. The team concentrates on fixing bugs, optimization, and balance.
• Gold master: The final version of the game that is released to the publishing platform.

Throughout development, there are periodic build reviews and playtests. Teams remove or modify features based on time and budgetary constraints. This is where scope management comes into play. Each uncontrolled feature requires additional design, art, engineering, and testing effort.

Gate: With every milestone, ask yourself if the game matches the agreed-upon definition. For instance, alpha does not mean near-complete; it must be feature-complete.

Stage 4: Testing and Quality Assurance

Testing is not a single step at the end. Good teams are continuously testing from the first playable, with the fervor arriving between alpha and release.

QA has a few types of testing:

• Functional testing: Are all functions working correctly?
•  Performance testing: Does it sustain its frame rate and load times on target devices? 
• Compatibility testing: Does it function on different devices, OSs, and screens? 
• Balance and usability testing: Is it really fair, intuitive, and enjoyable for the players?
• Platform support: Is it compatible with the technical requirements of each store and console?

Testers report issues in a bug tracker, known as a bug sheet, so the team can decide what to fix first. A release candidate is a build that the team thinks they can release once final verifications have been made.

Gate: Is the build stable and free of the most critical bugs? Define the criteria for a blocker before testing begins. Don't make those decisions on a tight schedule. 

Stage 5: Game Launch 

Launch has its own stages. Submit the build to the store, make a page for the store, trailers and screenshots, and do any press or community stuff. Review requirements and response times change from platform to platform. First submissions often require multiple rounds of fixes, so add that time to your schedule.

Some mobile teams will soft launch, releasing in one or two markets for a period to gauge retention, crash rates, and early monetisation. PC and console teams will sometimes have a demo or small early-access period.

Gate: Is the game running smoothly, are the fundamental features healthy, and do we have support?

Stage 6: Post-Launch Support

Then the game development process continues at launch. Once the game is launched, some members of the team are resolving bugs, publishing patches, and updating the game for new devices and different operating systems. Other team members are creating DLC, seasonal events, or new features, while others are on to the next game.

A postmortem is a great final step. The team discusses what worked well, what didn't, and what they want to do differently next time. Design documents, assets, and code are saved so they can be repurposed later.

Game Development Gates and Deliverables: What to Approve Before Moving Forward 

Gates only work if the criteria have been established in advance. This is a sample that you can use for your own project.

Name one person who is responsible for each decision. When ownership is shared, decisions tend to be very slow.

Feedback Loops That Keep a Project on Track

Gates tell you when to stop and test. Feedback loops tell you what to change. The most valuable feedback loops are: 

• Play test to design: Observe actual players playing the prototype, or build, and redesign based on what they have trouble with, not just what they tell you.
• QA to engineering: Incremental bug fix cycles that last a day or a week and which continuously incorporate builds of the product ensure that issues stay small. 
• Build review to production: Regular build review that assures art, design, and code work towards the same thing. 
• Stakeholder review to scope: Share early and often with decision-makers, so large decisions come early rather than late. 
• Post Launch Updates: Post-launch, retention, crash, and spending data determine the next patch or feature. 

The shorter the loop, the cheaper the correction. By the time you find a problem in a prototype, you can fix it in a day. The same problem after you ship costs you time and damages your reputation.

Agile vs. Traditional Game Development Approaches 

The steps to develop a video game handled by those studios vary. Big publishers tend to employ stage-gated, heavy-document, approval-driven processes. Small and mid-size teams tend to employ more agile, low-document, iterative approaches where small teams work in sprints with frequent builds.

A great majority of real projects use a blend. Pre-production and gates are sequential; production is iterative, in sprints. Whatever you do, hold onto the gates and the feedback loops, because they matter more than the name.

Example: A Small Game Moving Through the Development Stages 

Here's an example of how gates work on a small mobile puzzle game.

They pitch the idea and then get through the concept gate when two people outside the team repeat it correctly. During pre-production, the team creates a two-week prototype. Testers find the main move entertaining but the scoring complicated, so the team simplifies the scoring and re-tests before moving to the pre-production gate.

For the most part, production works in sprints; the first playable is delivered at 6 weeks, with an alpha once all levels are complete. At alpha, QA discovers a crash on older phones which blocks it, so the build has to go back to engineering, and the alpha gate remains closed until it is fixed. Once the game hits beta, we submit to the stores, conduct a soft launch in 2 countries, and fix a tutorial drop-off before going wide.

Common Mistakes in the Game Production Process

• Avoiding the prototype: Going directly into production can uncover fundamental issues at the most costly stage.  
• The GDD will be done: It will need to be modified as the game progresses. 
• Unclear gate acceptance criteria: If no one can agree on what "done" means, the gate is nothing but a meeting. 
• Additional features late: Late additions impact design, art, code, and testing.
• Testing too late: Beta issues are much more difficult to address than first playable issues. 
• Overlooking launch Preparation: Planning needs to include time for submission to the store, soft launch, and marketing.

Choosing a Game Development Partner 

A defined process helps working with a third party easier, as both parties know what each phase should provide and when the decision points are. If you are a turnkey supporter in the pipeline, the partner providing game development services will include the prototype, build, test, and post-release updates. Request from each partner to provide you with the stage gates, deliverables, and review timetable before closing a deal.