The question or thesis
A final-year game project should produce two things: a playable artefact and a clear body of evidence about the decisions that shaped it. The finished game matters, but the process also has to show concept validation, technical risk management, production discipline, player feedback, ethical judgement and reflective learning.
The route below assumes a student or small team building a Unity-first project, but the structure also works for Unreal, Godot or custom-tool projects. The engine can change. The evidence questions stay similar.
Route
Stage 1: Define the project claim
Start by writing a claim that can be tested:
- “This game teaches spatial reasoning through navigation puzzles.”
- “This game explores grief through resource loss and environmental storytelling.”
- “This game tests whether a short stealth loop remains readable with minimal UI.”
- “This game is a portfolio piece for 3D environment art and technical lighting.”
Use:
- preproduction-and-concept-validation
- game-design-documentation
- business-model-canvas-for-games
- overview-game-design-theory
Output:
- one-page concept
- one-sentence hook
- audience and comparable-title list
- risk list
- project evidence question
Exit signal:
- the project can be judged against a stated purpose, not only against taste
Stage 2: Build risk prototypes
Prototype the assumptions most likely to damage the project if they are false. For a combat game this might be control feel. For a narrative game it might be interaction pacing. For a 3D project it might be asset import, scale or camera readability.
Use:
- prototyping
- playtesting
- unity-object-communication
- overview-unity-csharp-cpp-programming
- overview-beginner-3d-game-development-route
Output:
- one prototype per major risk
- short test notes
- decision log: keep, change or cut
Exit signal:
- the team has stopped arguing from opinion where it can test in play
(Bond, Introduction to Game Design, Prototyping, and Development, see source-introduction-game-design-prototyping)
Stage 3: Make an honest vertical slice
The vertical slice should demonstrate the intended quality, tone and core loop without pretending the whole game already exists. It is a proof object for the project, the team and possible external audiences.
Use:
Output:
- playable slice
- short video or trailer draft
- first-minute test
- known limits list
Exit signal:
- a new player can understand the core loop, and the team can explain what the slice proves and what it does not prove
(CRE133 Lectures, see source-cre133-lectures. Brush, 25 Game Dev Tips for Beginners, see source-thomas-brush-indie-game-dev-tips)
Stage 4: Plan the shippable version
Move from “what could this become?” to “what will be finished?” The project needs a minimum viable game, a backlog, milestones and a cutting strategy.
Use:
Output:
- MoSCoW or must/should/could scope table
- sprint plan or milestone map
- burn-down or progress log
- cut list
Exit signal:
- the project has a visible smallest complete version
(Keith, Agile Game Development, see source-agile-game-development)
Stage 5: Gather player evidence
Final-year work should show how feedback changed the project. The evidence does not need to be statistically large. It needs to be honest, relevant and connected to design decisions.
Use:
Output:
- playtest plan
- observation notes
- issue list
- before and after changes
- accessibility check
Exit signal:
- at least three design changes can be traced to evidence
Stage 6: Prepare the public-facing argument
Even if the project is not intended for commercial release, students should be able to explain it as a product, portfolio piece or research-informed artefact.
Use:
- game-marketing-fundamentals
- store-page-and-pricing-strategy
- investment-pitches-for-games
- publishing-and-funding
- game-design-documentation
Output:
- short description
- screenshot set
- pitch deck or project poster
- audience explanation
- next-step plan
Exit signal:
- the project can be understood by someone who has not followed the development process
(Steamworks Documentation, see source-steamworks-store-and-release. Della Rocca and McAloon, Four Tips for Pitching Your Game, see source-game-pitching-to-publishers)
Stage 7: Finish, test and reflect
The final stretch is not only polish. It is evidence consolidation.
Use:
- build-and-release-management
- qa-and-bug-triage
- post-launch-and-live-ops
- legal-and-business-basics
- evidence-based-learning
Output:
- release candidate
- final bug triage
- project archive
- reflective report
- portfolio page or public video
Exit signal:
- the student can explain what was built, why it changed, what evidence mattered and what would happen next
Assessment-ready evidence pack
| Evidence | Purpose |
|---|---|
| Concept and hook | Shows project intent and audience framing |
| Risk prototypes | Shows early uncertainty was tested |
| Vertical slice | Shows representative quality and production ability |
| Production log | Shows planning, cuts, decisions and iteration |
| Playtest evidence | Shows player-centred change |
| Technical or art breakdown | Shows discipline-specific learning |
| Pitch or store-page draft | Shows public communication |
| Reflective report | Shows judgement, limits and future work |
Self-test
- What is the difference between a prototype and a vertical slice in a final-year project?
- Why should a capstone project have a minimum viable game?
- What kind of evidence makes a playtest useful for assessment?
- Why might a pitch deck be useful even for a non-commercial student project?
- What should a reflection explain beyond “what went well”?
Answers
- A prototype tests a risk or mechanic. A vertical slice demonstrates representative quality, tone and production viability.
- A minimum viable game protects the project from endless scope growth and gives the student a visible complete target.
- Useful playtest evidence links observations to decisions. It should show what players did, what changed and why.
- A pitch deck forces the student to explain audience, hook, evidence, scope and next steps clearly.
- A reflection should explain decisions, trade-offs, evidence, limits, mistakes and what the student would do next.
What the evidence suggests
Bond’s prototyping model supports risk-first development: test the assumption that could invalidate the project before polishing lower-risk work (Bond, Introduction to Game Design, Prototyping, and Development, see source-introduction-game-design-prototyping).
Keith’s Agile model supports iterative planning, visible increments, backlog ordering and scope control. These are especially important in final-year projects where time is fixed and ambition can expand quickly (Keith, Agile Game Development, see source-agile-game-development).
Hiwiller’s business material reminds students that commercial claims need cost, revenue and market assumptions rather than enthusiasm alone. Even non-commercial capstones benefit from this realism when explaining feasibility (Hiwiller, Players Making Decisions, see source-players-making-decisions).
Steamworks and pitching sources support the route’s final communication stage: a project needs clear screenshots, description, audience framing, playable evidence and next-step logic if it is to be understood outside the development team (Steamworks Documentation, see source-steamworks-store-and-release. Della Rocca and McAloon, Four Tips for Pitching Your Game, see source-game-pitching-to-publishers).
What to investigate next
- Add discipline-specific capstone variants for programming, game art, technical art, design research and production.
- Decide whether assessment rubrics should stay in private teaching docs or become public wiki guidance.
- Add a downloadable capstone evidence checklist if the public wiki later supports attachments.
Related
overview-gdnd-practice-route | overview-full-game-development-pipeline | preproduction-and-concept-validation | prototyping | vertical-slice | minimum-viable-game | playtesting | game-marketing-fundamentals | publishing-and-funding | build-and-release-management