Game Prototyping
A prototype answers one question: does the idea work? Not "is it pretty," not "is it ready for release" — does the core mechanic work so you want to play it. A week spent prototyping saves two months of production on a mechanic that turns out boring.
What a real prototype is
A prototype isn't a "quick version of the game." It's a tool to test a hypothesis. Each prototype must have a specific question: "Is managing a character with inertial movement interesting?", "Does tactical pause work in real-time?", "Does the combo system feel satisfying?"
Without a clear question, prototyping becomes early production — with "proper" architecture, beautiful assets, and lots of features, none of which are validated.
Speed matters more than clean code
In a prototype MonoBehaviour singletons — normal. Hardcoding numbers right in a method — acceptable. if/else instead of State Machine — OK. Goal — get a playable vertical slice in 2-5 days, not architect for years.
This doesn't mean "write garbage." This means making conscious tech debt decisions: this hack is acceptable now because we're throwing out this code after validation.
Tools for speed:
- Unity Prototype Kit (built-in primitives, ProBuilder for quick geometry)
- Kenney Assets and other placeholder libraries — free, neutral, don't distract from art
- DOTween — quick tweens without Animator setup
- Odin Inspector — custom inspectors in minutes, speeds up designer iteration
Prototype types and timelines
Paper prototype — zero cost, maximum speed. Cards, cubes, paper tokens. For mechanics with clear rules (turn-based, card game, puzzle) — mandatory first step before code. Validates logic in hours.
Gameplay prototype — only one mechanic in isolation. Empty scene, cubes instead of characters, debug text only. Tests feel — how management feels, how pleasant the physics, does the core loop work.
Vertical slice — developed fragment of the game: one full mechanic with final assets and UI. Used for attracting investment, pitching, or internal alignment.
| Prototype Type | Timeline | Goal |
|---|---|---|
| Paper prototype | 1-2 days | Validate logic and rules |
| Gameplay prototype | 3-7 days | Test game feel |
| Technical prototype | 3-10 days | Test feasibility |
| Vertical slice | 2-4 weeks | Presentation, investors |
What a prototype doesn't teach
A prototype doesn't show retention. "Fun to play 10 minutes" ≠ "want to return daily." Long-term engagement only validates through extended playtests with real users — different stage.
A prototype doesn't check scalability. Mechanics working with 10 objects may crash with 1000. Technical feasibility — separate question needing separate technical prototype.
Work process
Day 1: Hypothesis formulation. What exactly are we testing? What must be true for the mechanic to work? What are success criteria?
Day 2-4: Implement minimum. Only what's needed for the question. No "while we're at it, do it properly."
Day 5-7: Playtesting. 5-10 people from target audience. Watch what they do — not what they say. Record Gameplay Session via OBS or Loom.
Outcome: Decision. Continue → iterate → reject. The third option — also good result. Better to know an idea doesn't work in a week than three months.
Cost calculated after clarifying prototype type and specific mechanic to validate.