There are three primary deliverables that are due before the end of the semester. They are defined in their respective sections below.
The concept document describes the overall project. It establishes a vision such that production plans can flow from it.
There is not one way to write a concept document, and there are many recommendations. The structure presented here can be used as a template or as a guideline. For the purposes of our course experience, it presents the criteria by which your work will be evaluated, but it is not meant to be dogmatic in structure.
One of the goals of writing a concept document is to make sure that all the various pieces of your design hold together. There are a lot of different skills that go into game production, and newcomers will often gravitate toward focusing only on those ones they find intrinsically rewarding. Programmers will want to program, and artists will want to art. Writing the concept document forces you to think about all the various aspects that will come up in production before you have to face them.
The concept document, like all good technical writing, begins broadly and narrows into details as it goes. This way, the reader can understand the big idea before they are presented with the wheels and cogs.
The document is a multimedia composition. At the very least, it should contain text and images. The images and the text should reinforce each other, of course: they are both chosen toward your rhetorical ends. Audio can also be included, usually in the form of hyperlinks. Do not be afraid to reference other games when appropriate. For example, if you want to say that your art style is inspired by Undertale, include a screenshot to make your point clear and hyperlink the game’s name to where an unfamiliar reader can best find more information.
This is the title of the project at the time of the pitch. It should be descriptive and evocative. Note that it will not necessarily be the final name, which will be determined later in production.
Describe the premise of the game in no more than two sentences.
Describe your goals for the player’s experience. That is, identify what you want the player to think, feel, or do in the game.
A reasonable and satisfactory approach is to follow Joe Baxter-Webb’s approach. That is, you can choose a few of the Garneau’s Fourteen Forms of Fun and, for each, write a sentence describing how your game uses that kind of fun to create a good player experience.
Lemarchand’s Playful Production Process uses a more narrative approach, for which he cites Fullerton as a source. He recommends articulating experience goals as short statements that capture how players experience the game. Students have successfully used this approach in the past. For example, the team that made [Mission Rovee] regularly referenced their experience goals, which included items such as “Rovee is adorable”—a goal that impacted many disparate parts of the design.
Sylvester describes emotional triggers as an essential aspect of game design. He explains how we use flow states to get players’ minds into the game, then trigger emotional responses through threats and challenges in the game mechanics, and then we guide the player to label those emotional reactions using the layer of fiction. I recommend this approach for those who want to dive deeply into design theory.
Describe in bullet points what makes your game unique. This tells the reader what sets your game apart; no one wants to play a game that is just a worse version of another game. It is almost certainly out of our scope to have more than three of these.
Describe the kind of player for whom this game is being made.
Quantic Foundry provides an empirical, research-based framework for describing player motivations. It is the gold standard, and as such, it is an appropriate framework for you to use in describing your audience. Another option is to use the framework described by International Hobo Ltd.
This is an appropriate section to cite other successful games that serve your audience. For example, you might point out that people who liked X would also like your game.
Describe the core gameplay—the main activities of the player. Be sure to use strong and appropriate game verbs that capture the main actions.
Identify the core loops of your game. Andrew Chambers describes how you can articulate these in text by answering three questions:
Describe what the player sees and what they do to actuate the game verbs. Explain the game feel.
Explain how the game should look and sound. This can use a combination of inspirational pieces, concept art, and finalized key art from your vertical slice.
Describe the game world in enough detail that the reader can imagine how it impacts the gameplay and fiction. Different kinds of games will have different needs here: some games have very little fiction, and some are steeped in lore. The purpose of this section is to provide just enough details that the reader can share in your vision for the game.
Describe where you plan to release your game and what kind of monetization strategy you intend.
Describe the game engines, programming languages, asset production tools, and distribution platforms you intend for your game.
Contrast the resources you have available against the resources required to produce the game you just described. Describe any work that will need to be licensed or contracted out, and remember to keep in mind the needs of your distribution platforms. For example, releasing on Steam requires creating marketing assets that are not used in the game software but are still part of production.
Try to articulate the assumptions you have made and what can be done to mitigate them. You can also address the major risks that your prototyping and vertical slice already addressed.
The vertical slice is a small, representative piece of what you imagine your final game will be. If you think of the whole game as a cake composed of many layers—art, code, music, design—then the vertical slice is a piece of cake that cuts through all the layers.
The vertical slice must demonstrate core gameplay. Anyone in the target audience should be able to play it, but it would be inappropriate at this stage to incorporate tutorialization: focus on demonstrating the core loops with which a player will engage.
Your vertical slice must contain a representative sample of all the types of assets appropriate for your game. For example, you should have at least one sprite or 3D model that is fully produced, that is not a placeholder, that demonstrates how you want the final game to look and feel. It is expected that other parts of your vertical slice will be placeholders since your focus in preproduction is on finding the fun, and you’re better off using low-fidelity approximations of assets until you have evidence that the core gameplay is right.
The vertical slice is a rigorous prototype, but it is still a prototype. The value in it is in what we learn from it. A vertical slice whose code is a mess may still pass muster. Preproduction is about finding the fun while moving fast and breaking things: next year’s production class will be more concerned with software engineering. (Of course you will use version control during preproduction. You should always use version control. If you are not doing so, then you have not learned what version control is all about.)
The pitch is a slide-supported oral presentation that will be given to our Games Advisory Board. Like so many things in game production, there is not one right way to create a pitch. It is a good idea to study the genre using public examples such as those provided by Video Game Founder’s Kit and GameDiscoverCo’s Pitch Deck Collection. Brian Upton’s 2017 GDC talk describes many of the pitfalls that await the unwary.
The general rules of public speaking apply: know your audience, know your goal, and know your material.
For the purposes of our course experience, your pitch is expected to contain the following:
In total, you should have no more than ten slides, and they should have scant text.
©2025 Paul Gestwicki. This work is licensed via CC BY-SA 4.0.