Tabletop Game Design: Theory, Management and Process


The purpose of this document is to provide structure to the organization and management of the tabletop game design process. It defines terminology that can be used in accurately discussing game design. Additionally it defines a structured method for how a concept turns into a prototype, and how a prototype turns into a publishable game. The goal is to be technical and accurate and yet unopinionated about how a designer moves incrementally to a final product.

Game Design Theory


Game: A game is a list of versions. Very often the word “game” can refer to a specific version. This is the case in the normative usage of the word and also in this document.
Version: A version is defined by the “Rulebook” and the “Definition”.
Rulebook: Conveys the theme of the game and is the source of truth for the mechanics of the game.
Components: The individual units that can be manipulated in the game. This usually means physical pieces, but could include less substantive things such as a timer, phone app, etc…
Mechanics: The rules that limit and govern when and how the components of the game can be manipulated.
End of Game Conditions: The state of the components that ends the game with 0, 1, multiple or all the players being declared the winner.
Victory Conditions: A subset of the End of Game conditions where at least 1 player is declared the winner.
Theme: The theme is the real world nouns and verbs that are represented by the mechanics. Some games may not have a theme.
Craft: Anything the players see that is a result of the game. This includes the components, the shape of the components, the pictures on the components, the box, the rulebook etc…
Design: The design is a subset of craft. Design conveys the relation between the mechanics and the theme.
Experience: The emotional response that the players have to the craft, design and mechanics.
Component Item: An individual component or piece in the game. For example a single “gold coin” piece is a component item.
Component Type: A collection of component items that are all identical to one another. For example the collection of all of the gold pieces is a component type.
Component Category: A group of component types that all are printed in the same way (card, token, dice, etc…). For example the group of gold, silver and bronze coins is a component category.
Game Design Management: The practical methods and tools used to iteratively create versions of a game. The organization of a game and it’s versions. The way in which a game and it’s versions are expressed.
Game Design Process: The set of phases that take a game from being a concept to a publishable game.

Game Design Management


Placeholder Components: Any component that is only text, but otherwise does not have any design. Note that design can conveys theme, and theme can be conveyed through text, but placeholder components do not usually go beyond text. The line between placeholder components and designed components is not precise, as placeholder components could have images. The goal for the placeholder components is that they all can be expressed in a single file (often a spreadsheet) and can be quickly changed.
Designed Components: Any component that attempts to near-fully convey the theme via design. These components usually come from a print on demand source.
Placeholder Prototype: The collection of component categories that define your game, such that the components are placeholder components.
Designed Prototype: The collection of component categories that define your game, such that the components are design components.
Placeholder Definition Document: The electronic file that completely expresses the placeholder prototype.
Design File: Any electronic expression of a component category such that the components expressed by the file have design, and therefore convey theme. This is often a photoshop file or something similar.
Design Layer: Each design file should have multiple layers that can either be shown or hidden. This directly corresponds to the photoshop “layer”. Other designing applications should have similar concepts.
Design Definition: The group of design files that completely expresses the designed prototype.
Folder: Some grouping of files and folders that additionally has a name.

Getting Started

  • Create a folder for the game. The name of the folder should match the alias title for the game, with the understanding that the actual title may change from version to version.
  • Create a “Version 0.1” folder underneath the game folder.
  • Create a “Rulebook” document.
  • Create a “Definition” document.
  • When you are ready to create a designed prototype, create a “Design” folder underneath the version folder.

Game Folder

  • Images and assets should reside in this top level folder so that subversions can all reference and use them.

Version Folder

  • These generally only contain the definition document and the rulebook document.
  • Any images or other assets should not be put into the version folders in case future versions also need the image or asset.
  • When you are about to make significant changes, or you want to try changes but also want to maintain the old version, copy the latest version folder with it’s contents and start a new version.

Rulebook Document

  • Includes the title and version number of the game
  • Partially convey the theme of the game
  • Describes and lists the components
  • Unambiguously conveys the game mechanics and end of game conditions

Definition Document

  • Create a data sheet for each category that lists the data for each individual component item in this category.
  • Create print sheet for each category that uses this data sheets to create printouts referencing the data. In the data sheet either each row represents one individual component item or represents one component type.
  • Create calculation sheets which does any game balancing calculations that can help understand the game as a whole.

Design Folder

  • Contains the design files for the actual designed prototype.
  • Each design file contains one category of component.
  • Each design file contains multiple layers:
    • Helpers: Anything that helps with creating the design file but will not ultimately be printed out.
    • Shared: Anything that is shared by all of the items within this component category.
    • Types: Layers that represent one type of component from this component category. In the end only one type layer should be seen at a time. Sometimes every component type only has one component item (such as when you have a deck of 20 cards that are each unique). Other times some component types may have multiple component items (such as if you have 30 gold and 20 silver). If their is more than one item per type, the count should be listed in the layer title.
  • The collection of design files should totally define your game, and when moving to the designed prototype stage of the game these files become your game definition (replacing the placeholder definition document).
    • It may be helpful to continue to maintain the placeholder definition document because this is usually expressed as a spreadsheet and allows for easier change, balancing and referencing.

Game Design Process

Phases of Game Development

  • Concept Phase
  • Placeholder Prototype Phase
  • Designed Prototype Phase
  • (Optional) Pitch Phase
  • (Optional) Publisher Changes Phase
  • Publish Phase

Concept Phase

  • This is when the game does not have a version.
  • The moment the game has both a rulebook and a definition, the first version of the game is created and the prototype phase has begun.

Placeholder Prototype Phase

  • This is all of the versions of your game that have a rulebook and a definition, but the definition is expressed with placeholder components and not designed components.
  • The goal in this phase is to focus on mechanics.
  • Large changes between game versions is likely to occur in this phase.
  • Categories, types and amounts of game components could swing wildly between versions in this phase.

Designed Prototype Phase

  • The designed prototype phase begins when the definition of the game is expressed with designed components and not simply with placeholder components.
  • The goal in this phase is to focus on experience, while fine tuning mechanics.
  • Only small changes and adjustments between game versions should occur in this phase.
  • The categories, types and amounts of game components should stay fairly steady in this phase.

(Optional) Pitch Phase

  • The first version of a game to be pitched to a publisher moves the game into the Pitch phase. In the case of self publishing or internal publishing, this phase is not relevant.
  • Experience, mechanics, and components should not be undergoing any major changes at this point because these three things will affect  what publishers will accept the game.

(Optional) Publisher Changes Phase

  • If the game was pitched, the experience and mechanics could undergo another round of significant changes depending on the contract between the designer and publisher and depending on the needs and desires of the publisher.

Publish Phase

  • Either a designer publisher contract is agreed upon, or a self publisher has arrived at a version that they desire to publish.
  • The publisher (or self-publisher) is making plans on production, advertising and selling the game.


This document is meant to define at a theoretical level what game design is as well as what a game itself is. Additionally it is meant to provide a practical method of structuring and defining a game as well as the process of game design and the different phases that it goes through. This document purposely does not discuss how one version of a game moves into the next version of the game. This is intentionally left to the individual game designer to fill by his game design expertise. In this way many game designers could ascribe to the game design theory and practice articulated in this document, while at the same time expressing their own creative talents and expertise.


I want you help and contribute! With your help we can arrive at a thorough theory and practice of game design that can be clearly articulated and understood. The goal is for this document to be ambiguous as to the specific tools used, as well as to the specific methods of incrementally, version by version, improving upon a game. In this way the theory, management, and process of tabletop game design can be understood without at the same time limiting the methodology of game designers.

If you have any contributions, suggestions, questions, qualms or disagreements, email me at with the subject “Tabletop Game Design Theory”.

Popular Posts