GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Prototyping

9 min read

Summary

Prototyping is the process of building a simplified, testable version of a game (or a specific element of a game) to answer a design question as quickly and cheaply as possible. Schell’s core principle is risk-driven prototyping: identify the riskiest assumption in your design and prototype that first.

Bond (Ch. 7, 9) situates prototyping within a structured iterative design process and provides a detailed account of paper prototyping benefits, tools, and techniques — including interface prototyping with Lo-Fi wireframes.

(Schell, The Art of Game Design; Bond, Introduction to Game Design, Prototyping, and Development, see source-art-of-game-design, source-introduction-game-design-prototyping)

Iterative design process (Bond)

Bond (Ch. 7) structures the full design process as four phases looped repeatedly:

Analysis → Design → Implementation → Testing → (repeat)
  1. Analysis — Understand the problem space before designing. Research prior art (games in the same genre or with similar mechanics), study your target audience, identify constraints (platform, team size, scope). Analysis prevents designing solutions to the wrong problem.
  2. Design — Generate ideas and make decisions. Brainstorm broadly (diverge), then evaluate and select (converge). Document decisions so they survive the loop.
  3. Implementation — Build the prototype or feature. For paper prototypes, this is cutting cards and writing rules; for digital, it is coding and asset creation.
  4. Testing — Observe the prototype in use (playtesting). Gather data. Return to Analysis with new information.

“Game design is 1% inspiration and 99% iteration.” — Chris Swain (quoted by Bond, Ch. 7, source-introduction-game-design-prototyping)

The loop repeats from paper prototype through alpha, beta, and release. Each iteration should produce one clear question answered.

Innovation types (Bond, after Johansson, The Medici Effect):

  • Incremental innovation — systematic, predictable improvement within a known field; reliable but rarely transformative
  • Intersectional innovation — collision of disparate ideas, domains, or fields; high variance but potential for breakthroughs. Magic: The Gathering is cited as a classic intersectional innovation (collectible hobby + strategic card game)

The Analysis phase is where intersectional opportunities are found — by deliberately studying domains outside games.

Key ideas

Risk-driven prototyping

Not all design questions carry equal risk. A prototype should answer the question whose answer you are least confident about and whose wrongness would cause the most damage. If the core mechanic doesn’t work, the game doesn’t work — prototype it first, not the menus or the art.

Paper prototyping

Physical, non-digital prototypes using cards, dice, paper, and tokens. Bond (Ch. 9) systematises the benefits:

  1. Initial development speed — can be built in hours, not days; enables rapid idea exploration
  2. Iteration speed — redraw a card, cross out a number, add a token; changes take seconds
  3. Low technical barrier — no programming knowledge required; designers, artists, and writers can prototype independently
  4. Collaborative — tangible objects invite multiple people to contribute simultaneously; reduces the “programmer as gatekeeper” problem
  5. Focused and directed testing — only the mechanic being tested is present; there is no UI chrome, no sound, no visuals to distract or mask the core design problem

Even for digital games, a paper prototype of the core mechanic can reveal fundamental balance or fun problems before a line of code is written.

Tools for paper prototyping (Bond):

  • Index cards (for cards, tiles, counters)
  • Sticky notes (for movable elements)
  • Dice (for randomness and probability testing)
  • Poker chips / coins / tokens (for resources, health, currency)
  • Printed grids or map sketches (for spatial layouts)
  • Dry-erase markers or pencil (for in-session rule changes)

Interface prototyping

For digital games, Lo-Fi interface prototypes (paper wireframes of UI screens) test information architecture, navigation, and layout before any code is written.

A Lo-Fi wireframe is a rough sketch of:

  • Which screens exist and what they contain
  • What buttons/inputs are on each screen
  • How screens connect (navigation flow)

Testing a Lo-Fi wireframe with a playtester reveals whether the UI is intuitive, whether labels are clear, and whether the navigation makes sense — all before investing in digital implementation. Bond demonstrates this with a Legend of Zelda dungeon UI prototype (Ch. 9).

The “fail fast” principle

“Your first ten games will suck — so get them out of the way fast.” — Schell (source-art-of-game-design)

Prototyping embraces the expectation of failure. The goal of a prototype is not to produce a good game; it is to produce information — specifically, to answer the question “does this idea work?” quickly and cheaply. A prototype that conclusively shows an idea doesn’t work is a success.

Iteration

Prototyping is inherently iterative. A prototype informs changes; changes produce a new prototype; the new prototype is tested; repeat. Schell’s version of the design loop: imagine → try → observe → decide → repeat.

Kristjan: never stop prototyping

Schell and Bond both frame prototyping as primarily a pre-production activity. Kristjan (We Deserve Better Villains, Ch. 3) adds a practitioner counterpoint: prototyping should continue throughout the development cycle, not just at the start.

“I’m here to tell you that you should never stop prototyping if given the chance. Advocating for prototyping time while developing, I guarantee you, will help unlock areas you didn’t know possible as the development of the game goes on. I’ve seen this save entire titles as the changes found in a prototype quickly over a week helped the entire development team pivot to better gameplay with minimal changes to the project plan.” — Kristjan, Ch. 3

The common failure mode: teams prototype extensively in pre-production, then treat the prototype findings as settled and never prototype again. Mid-production prototyping of new features or difficult systems can prevent weeks of wasted implementation. The prototype in production serves the same function as before — answering a question cheaply before investing in full implementation — but the question being asked changes from “does the core mechanic work?” to “does this specific new feature work?”

Design implication: Schedule explicit prototyping time throughout the production calendar. If it turns out not to be needed, the time can be reallocated; if it prevents one costly design dead-end, it pays for itself many times over.

(Kristjan, We Deserve Better Villains, see source-we-deserve-better-villains)

Sellers: find the fun fast

Sellers (Advanced Game Design, Ch. 12) adds a practitioner principle that is more direct than Schell’s risk-driven framing: find the fun fast. Before any art, story, or UI is built, the designer must answer one question: is there a playable, enjoyable core interaction here?

The interactive loop test: the minimum viable prototype is one that closes the interactive loop — the player takes an action, the system responds, the player observes the result and decides on the next action. This loop must exist and must feel engaging before anything else is built. A prototype that cannot close this loop is not a prototype — it is a mockup.

Specific principles from Sellers (Ch. 12):

  • Prototypes must include interaction: a non-interactive proof-of-concept is useful for visual design but cannot answer the central question of game design — “is this fun to play?” Movement, choices, and feedback must all be present.
  • Keep prototypes separate from game code: prototype code should be throwaway. The most common costly mistake is treating a working prototype as the production codebase and building on top of it. Prototype code is written to answer a question; production code is written to ship. The priorities are different, and conflating them produces brittle architectures (see unity-gamemanager-pattern for the right production architecture).
  • Use both analogue and digital prototypes: analogue prototypes are faster to build and modify, and better for testing rule clarity and decision structure. Digital prototypes are required for anything involving game feel, timing, physics, or real-time interaction.
  • Each prototype should have a clear question: a prototype that is “just trying things out” produces ambiguous data. The question should be specific: “Is the ship-turning speed engaging at 90 degrees per second?” rather than “does the combat feel good?”

The Wizard of Oz technique

For systems that are expensive to implement (AI, procedural generation, complex UI), the Wizard of Oz technique allows early testing: a human operator manually performs the system’s role while a participant tests the interaction as if it were automated. The participant is not told the system is manual.

Used to test: conversation AI responses, procedural level layouts, matchmaking systems, narrative branching. The technique surfaces design problems in the interface and response structure before the underlying system is built.

Thinking aloud

During prototype sessions, asking participants to think aloud — verbalise their reasoning and reactions as they play — surfaces the cognitive model players are forming about the game’s rules. This is qualitative data that complements the observational data from silent testing (see playtesting).

Limitation: thinking aloud changes the experience — players become self-conscious, which can mask natural confusion or delight. Use it selectively, particularly for rule comprehension testing.

(Sellers, Advanced Game Design, Ch. 12, see source-advanced-game-design)

Open questions

  • At what fidelity should a prototype be playtested? Too low fidelity and testers can’t engage; too high and the prototype cost prevents iteration.
  • For student projects with limited time: when should prototyping end and production begin?
  • Paper prototyping is most useful for mechanic testing. What are the limits of paper prototypes — what must always be tested digitally?

Graph View

Backlinks