Production

Video Game Pre-Production Deliverables: Prototypes & Design

Share:

“First, have a definite, clear practical ideal – a goal, an objective. Second, have the necessary means to achieve your ends – wisdom, money, ­materials, and methods. Third, adjust all your means to that end.” (Aristotle)

You can find the introductory article “The Importance of Pre-Production” here!

In the following section, I will try to give an overview of all the essential ­materials that are usually created in the pre-­production phase in coordination between the development studio and the publisher. Depending on the genre, ­platform and business model, some may be of lesser importance, others of greater importance – but you can use this checklist as a general guide to the most commonly expected deliverables.

Prototypes/Core Playable (Proof of Fun)

At the end of the pre-production phase ­there must be at least one early version of the game that demonstrates the “fun”. The core game mechanics and game loops should be presented in a way that clearly shows how the final game will excite and entertain players.

The creation of this build, often referred to as “Core Playable” or “First Playable”, should be tackled in the first half of Pre-­Production, before any major design work and documentation has started. The following essential areas related to “proof of fun” need to be covered:

1. Core Game Loop

The Core Playable (as the end result of all prototypes created) demonstrates the ­essential key mechanics of your gameplay. It must become crystal clear what the player will spend most of their time doing in the finished game and why they will find it entertaining and enjoyable.

2. Camera, Character and Controls (CCC)

The commonly used acronym CCC describes the relationship between the player’s input and the reactions of their “virtual
representation” (such as character, ­vehicle, troops etc.) on the screen, including the ­visual staging by the game camera. In ­virtually every game, this interdependence has a major impact on the overall experience (and thus on the “fun”). Therefore, it should be prototyped and thoroughly ­tested at an early stage of pre-production.

3. User Interface and Experience (UI/UX)

Part of the CCC proof above also depends on how the player interacts with interfaces and menus and what feedback they receive. This could be demonstrated e.g. by click dummies, using Balsamiq, MS-Power Point or other tools – or ideally already in a rough version within the Core Playable itself.

4. Definition of Production Value

Another pre-production objective is to ­demonstrate the desired quality of the final game in terms of graphics and audio. This can be achieved separately outside of running prototypes with the help of reference materials from other titles (video footage, benchmark graphics etc.).

Game Design Documentation

At the end of the pre-production phase, the development documentation – in particular the game design document – is completed to the extent that all key features and gameplay loops are defined and described.

Everyone involved is aware that a game design document is subject to constant changes and additions, and accordingly a GDD cannot have the status “final” at the end of a pre-production phase in the sense that the definitions of all values, formulas, texts and the like are completely finished.However, the GDD must at least capture and describe the game features in such a way that all project participants can identify and evaluate the complexity of the respective work. The project plan (or prioritized backlog), which is also part of the end-of-pre-production requirements, will be based on these assumptions. The documentation should include the following deliverable items:

1. Game Vision

A description of the main goals of the game in the form of a vision statement, usually no longer than two pages. The game vision usually already exists as part of the pitching materials. However, by the end of pre-production it has been validated and finalized. At this stage, ­adjustments may have been made based on findings about core game mechanics and decisions about specific features. Once in production, the game vision does not change anymore. Otherwise, it automatically means that you have to start from scratch again and enter another pre-production phase to ­re-evaluate everything based on the changed vision.

2. Game Design Document (GDD)

A description of all relevant game features and core gameplay loops in a comprehensive form. The GDD should provide all project participants with a clear and as accurate as possible vision of the game and its content, enabling team members to estimate and prioritize their workload and implementation efforts (=tasks).

3. Definition of Game Scope & Quality

A definition of how big the game will be (game length, size of the world etc.). In addition, publisher and developer have agreed on the means to measure the quality of the core features, e.g. by comparing them with competing products or using a quality matrix.

4. Feature and Asset List (including Classification)

An overview of all the features and assets of the game. Each of the individual features has been classified as: ‘Must-have’, ‘Should-have’, or Nice-to-have’. An excellent format for such a deliverable is a product breakdown structure, also known as PBS.

5. Art/Style Guide

Definition of the visual style of the game, using supplied examples as a benchmark for all graphics to be created. Both from both a technical point of view (engine, ­shaders, poly-count etc.) and from an artistic perspective (graphical style, concept artwork, mood boards etc.).

6. Level-/World- & Story Guide

A detailed description of the game world and backstory (if any), including any scenarios, levels or settings that occur in the game. Overall scope, such as number of worlds, levels, settings (dungeon, forest etc.) and all variants.

7. Name of the Game

Ideally, the final name of the game has already been determined during pre-production, legally checked, A/B tested via marketing and trademarked (including URL etc.). This is not a prerequisite, but a strong recommendation and less trivial than it may sound.

8. Monetization Strategy (F2P)

If you are working on a Free2Play game, the monetization strategy is also a key ­deliverable as part of the overall game design documentation. This strategy must explain the game’s monetization mechanics and hooks, including concepts such as:

  • Description of the core game loops, economy, progression and player gating mechanics
  • Currencies: hard currency, soft currency, major sinks (and: are these sinks valid in all phases of the game or e.g. only in early or in endgame etc.)
  • Expected lifetime value (LTV) by item category, high conversion items, whale items etc.

9. Definition of balancing format (F2P)

For Free2Play games, a definition of all relevant balancing parameters is often also required by the publisher at the end of pre-production. Such a document should define how the balancing variables are implemented in terms of format and how they can be updated once the game is live (Database, Balancing Sheet/Google Doc etc.).

Share: