The question or thesis
The full game-development pipeline is the path from idea to post-launch support, but it is best understood as a sequence of different questions rather than one continuous build phase. First you prove the idea, then the prototype, then the vertical slice, then production reliability, then release readiness, then commercial launch, and finally post-launch support. This page is the shortest route through how those stages fit together for an indie PC/Steam-first project.
The central claim from the sources is that the pipeline is best understood as a sequence of different validation problems. Early on, you are testing whether the idea is interesting and feasible. Later, you are proving that the team can build it reliably. Closer to launch, you are proving that players can understand it, that stores can present it clearly, and that the release process itself will not fail under operational pressure (Bond, Introduction to Game Design, Prototyping, and Development, see source-introduction-game-design-prototyping; Keith, Agile Game Development, see source-agile-game-development).
What the evidence suggests
The pipeline in one view
| Stage | Core question | Main artefact | Typical exit signal |
|---|---|---|---|
| Idea and audience framing | What is the game, who is it for, and why would anyone care? | Pitch, hook, comparable-title list | The concept can be explained clearly |
| Preproduction and concept validation | Which assumptions are riskiest? | Risk list, lightweight prototypes, audience framing | The key risks are visible and testable |
| Prototype | Is the core interaction actually fun? | Playable experiment | The core loop works well enough to continue |
| Vertical slice | Can the team present a representative, polished sample? | Vertical slice build | Stakeholders can believe in the project |
| Production | Can the team build the shippable version reliably? | Backlog, sprint cadence, content pipeline | The minimum-viable-game is on track |
| QA and hardening | Is the game stable, understandable, and releasable? | Test plans, bug triage, release candidate | Release blockers are under control |
| Store and launch preparation | Can players discover and understand the game? | Store page, trailer, pricing, launch plan | The page, build, and launch timing are ready |
| Launch and sales | Can the product convert audience attention into purchases? | Release build, launch comms, visibility beats | The game launches with coherent messaging |
| Post-launch | What should be fixed, supported, or extended? | Patch plan, updates, analytics review | The team has a deliberate support strategy |
Stage 1: idea before scope
Early concept work is not yet production. It is the stage where the team decides what emotional promise, player fantasy, or strategic hook the project is actually built around. Kristjan’s “Blue Sky” phase treats the elevator pitch as the first usable artefact of development, while Hiwiller treats clear decision-making and player understanding as central design duties (Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains; Hiwiller, Players Making Decisions, see source-players-making-decisions).
This is why preproduction-and-concept-validation matters: if a team cannot explain the game cleanly, it usually cannot scope it cleanly either.
Stage 2: preproduction is risk reduction
Bond’s formulation of prototyping is risk-first: prototype the assumption most likely to invalidate the design. Keith’s Agile framing reaches the same conclusion from a production angle: the riskiest work should be surfaced early because uncertainty discovered late becomes schedule damage (Bond, Introduction to Game Design, Prototyping, and Development, see source-introduction-game-design-prototyping; Keith, Agile Game Development, see source-agile-game-development).
So preproduction is not merely “planning”. It is the period where the team discovers:
- whether the core loop is worth continuing
- whether the concept is small enough to ship
- whether the intended audience is legible
- whether the technical/art pipeline is realistic
Stage 3: prototype and vertical slice answer different questions
A vertical-slice is not a better prototype. It is a different artefact. The prototype proves fun and risk. The vertical slice proves representative quality and production viability for stakeholders, publishers, investors, or the team itself (CRE133 Lectures, see source-cre133-lectures; Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains).
Confusing these stages is costly:
- polishing too early can hide unresolved design risk
- staying in prototype mode too long can delay production discipline
- building slice-quality assets before the concept is stable creates waste
Stage 4: production is controlled scope, not endless addition
Once the core is proven, production shifts from “What could this be?” to “What will actually ship?” Keith’s answer is the minimum-viable-game, backlog ordering, sprint reviews, and continuous re-prioritisation. Production health depends on keeping the shippable version visible and protected from scope drift (Keith, Agile Game Development, see source-agile-game-development).
This is also the point where marketing stops being abstract. If the team cannot say what the game is by production, store and press materials will be weak later.
Stage 5: release is an operational discipline
Steam’s official documentation makes release look less like a dramatic final moment and more like a sequence of gates: page review, build review, pricing, release-date management, final release actions, and post-launch updates (Steamworks Documentation, see source-steamworks-store-and-release).
That means launch readiness includes:
- store-page clarity
- gameplay-first trailer and screenshots
- pricing and Early Access decisions
- submission buffers
- bug triage and release-candidate discipline
For console projects, certification adds another layer of requirements and scheduling risk beyond ordinary PC release work (Microsoft, Xbox Accessibility Guidelines and Xbox Requirements, see source-xbox-accessibility-and-certification).
Stage 6: launch is not the end of the pipeline
The later phases in Kristjan’s lifecycle explicitly include Post-release and Live, while Keith’s second edition also treats live games and post-ship iteration as part of modern game development rather than an optional extra (Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains; Keith, Agile Game Development, see source-agile-game-development).
For an indie PC team, post-launch usually means:
- fixing urgent bugs
- communicating updates clearly
- learning from analytics, reviews, and player behaviour
- deciding whether ongoing support is commercially and creatively justified
A practical default path for students and indie teams
For this wiki, the best default teaching path is:
- preproduction-and-concept-validation
- prototyping
- vertical-slice
- minimum-viable-game
- game-marketing-fundamentals
- build-and-release-management
- accessibility-and-localisation
- store-page-and-pricing-strategy
- publishing-and-funding
- post-launch-and-live-ops
For deeper follow-up, the path branches into qa-and-bug-triage for release-risk handling and legal-and-business-basics for ownership, credit, and obligation literacy.
This is intentionally indie PC / Steam first. Console and mobile variants matter, but the Steam path is the clearest general teaching model because the official documentation is comparatively open and specific.
Disagreements or tensions
Design truth vs. marketing truth. Marketing wants a clear promise early, but early design work is uncertain by definition. The productive tension is to communicate the current best promise honestly without pretending the design is already final.
Prototype freedom vs. production discipline. Creative exploration requires ambiguity; shipping requires constraint. Teams that stay in one mode too long either ship incoherent projects or never ship at all.
Launch ambition vs. support capacity. Not every game should become an endless live-ops product. The post-launch plan has to match the team’s money, time, and audience rather than imitating larger studios.
What to investigate next
- What current Steam festival, demo, and wishlist practices are most useful for student-scale projects?
- How should the pipeline be adapted for console-first teams where certification constraints appear much earlier?
- Which post-launch strategies actually make sense for small premium games rather than F2P or service games?
Related
preproduction-and-concept-validation | prototyping | vertical-slice | minimum-viable-game | game-marketing-fundamentals | build-and-release-management | store-page-and-pricing-strategy | publishing-and-funding | accessibility-and-localisation | post-launch-and-live-ops