The Game Proposal Part Two: The Contents

Introduction

[The following following article is the long overdue conclusion to 2002's 'The Game Proposal, Part One: The Basics']

Publishers are inundated with game submissions. As a game developer trying to get the attention of a publisher, that's a concept you probably already understand. Your submission, like all of them, will be filtered as it moves up the chain from receptionist to key decision maker.

To better the odds that your game proposal will advance up the decision chain, it must contain the data that the publisher is looking for. Moreover, this information should be easily found within the document structure and formatting. In this article I explain what a game proposal for a publisher should contain, under the assumption that you are already familiar with the game industry but new to the process of pitching a publisher as a third party developer.

I'm assuming that you've recently broken off from a larger company, or you have the wherewithal to develop a running demo, and you're forming your own team with the intention to create a game for a publisher. In this scenario, your first step in the proposal process should be to contact the publishers you're likely going to pitch and try and get your hands on any standardized submission forms that these publishers use. It's true that most game proposals are created from the ground up by the developer, but many publishers (particularly the largest ones) also require you to fill out a form to help them get to the meat of your game proposal.

Get these forms as early as possible in the process. Often, seeing what the publisher asks in these forms can help you determine if that company will even want your game, and there's no sense in wasting time in crafting a proposal for a publisher that's not a good fit for your game. (Note that game agents have submission forms as well, and they are very similar to the ones publishers use.

Contents of the Game Proposal

Game proposals generally contain the following elements:

The Cover Letter

Probably the most important thing you will write will be the cover letter. This document will most likely be the first and possibly the only one read before the demo is played. It has to tell the publisher everything about you and your proposed game. A cover letter is typically a one page document with an introduction, a body and a conclusion, usually about four solid paragraphs that sum up the entire game proposal.

The main points you want to get across in the cover letter are that you have a great game idea (marketable) and that you are able to make that idea a reality. The letter sums up all that is contained in the proposal briefly and only mentions specifics if you have a hot selling point such as a cutting edge technology, license, or top name talent on board. And this is not just a document that sells the game, but you as well. The reader of this letter will notice bad formatting, spelling errors, and how well your thoughts are organized, among other details that will speak of the letters’ author.

When writing the cover letter remember to consider your audience and state why you would want to be published by this particular publisher. If possible include a reason you are a fit for this publisher. If, for instance, you have read an article where the publisher has been quoted as saying that they are looking your type of game, mention it here. And remember to conclude your letter with a request for action. Don’t just say thanks and goodbye, ask the reader to follow up or better yet, tell them you will be following up. Part one of this article focuses more on aspects that will help you write an effective cover letter.

2. The Game Overview

The game overview should contain the basic data about your game. This generally includes the following:

Game Title. Be sure to indicate that your game's name is a "working title", as this means that you are aware that the title may change. Clinging to the name you gave your game is a sign of inexperience, and publishers have may have legitimate reasons for changing the name such as copyright issues, marketing reasons, and (believe it or not) the possibility that the title you came up with is simply not the best. This doesn’t mean you shouldn't give any thought to the title, though. You should have a title that speaks to the publishers and connotes the essence of your game.

Category or Genre. Usually publishers want innovation, not invention. That means that the preference is for an improved version of the latest hit, not a new, untried idea that nobody can define in traditional market terms. Games based on proven genres (action games or RPG games, for example) are easier to market and easier for retailers and gamers to understand.

In the book Game Architecture and Design by Andrew Rollings and Dave Morris, genres are defined in their truest sense and can be broken down into about seven types:

- Action: Lots of frantic button pushing.
- Adventure: The story matters.
- Strategy: Nontrivial choices.
- Simulation: Optimization exercises.
- Puzzle: Hard analytical thinking.
- Toys: Software you just have fun with.
- Educational: Learning by doing.

Of course genres can be defined, like Action/Adventure titles and Action/Strategy and so on. On top of these classifications you pile on the details about your technology, marketing and other factors, and soon these traditional genre labels become less effective. Conveying details about your game's technology, game play, and other critical information in just a few sentences can be extremely challenging.

For example, much confusion surrounds the simple term "3D". If a game describes itself as “3D Action” on its box, what does that tell you? Will it be first- or third-person perspective? Will there be multiplayer support? Obviously the term “3D Action” doesn’t answer all the questions someone could have about a game. So you're back to using a list of genres, around which you'll need to provide some context. In other words, don’t just put “3D Shooter.” If the publisher’s has a particular negative bias towards that term, chances are your game won't get the second look it may deserve.

When discussing your game, keep the genre in mind, as it is a foundation for communicating your vision to others. Once you have a clear idea of your game, “It is a first person shooter with shades of military simulation and strategy in the multiplayer mode,” you can proceed to describe it in visual terms on paper, eventually breaking it down into the elements that will comprise the design document.

Technical Specifications. The technical specification explains the how and what of the technologies and tools your team will use to develop the game. This section forces you to consider all of the tasks that are needed to complete the game development process. The technical specification is extremely important for the proposal as well as the development schedule, but it's beyond the scope of this article to go into depth about it. For more information see The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications by Tim Ryan (www.gamasutra.com/features/19991217/ryan_01.htm).

Minimum System Requirements. List the platform, hardware, software, special peripherals, RAM, and so on that will be needed to run the game. You may want to demonstrate your understanding of the gaming market in this section by citing the current installed base of this certain PC configuration.

Media. If you need four CDs or a DVD, then discuss it in this section - and justify the added expense the publisher will see in terms of replication, packaging, and even design fees. Explain why that media is justified and why it will make the publisher money. Keep in mind that the publisher generally wants a game that will be economical to make, easy to market, and fits current standards of shelf space and box design.

Internet/Multiplayer Capabilities. Clearly define your game's single and multiplayer modes. If you are lacking one of these modes, you must present a solid argument why the market will support a one-mode-only game.

Development Stage. Each publisher has its own definition of the development stages, and you should understand these stages when you work a company. You need to indicate to the publisher what stage your game is at. You may want to stay away from labels and simply describe how far along your game is and how much farther it needs to go. If you indicate that you are at beta stage out of ignorance or misunderstanding when the publisher judges the demo to be at alpha, you could inadvertently give the publisher the impression that you have a half-functioning game when you consider it almost finished.

Here are the generally accepted definitions of game development stages:

3. The Game Treatment

“I didn’t have time to write a short letter, so I wrote a long one instead.”
— Mark Twain (1835-1910)

This quote sums up a very important aspect of the game treatment: it is often easier to write a 10-page document describing your game than to write one page that says everything concisely and effectively.

The game treatment is your primary selling tool which quickly orients the publisher to your game (genre, platform, story and other elements should be mentioned). The treatment is your opportunity to convince the publisher that your idea is as complete and crystal clear as you believe it to be. If you can’t briefly explain your game idea, then the following might be true of your game:

One approach to writing the game treatment is to cite your game's "unique selling points" (USPs). USPs are the aspects that differentiate your game from the competition, offer gameplay value, and ultimately make consumers want to buy the product. You should be able to determine the USPs of your game after writing the "competitive analysis" section of your proposal. If yours is truly a good idea, the publisher may even read your design document all the way through.

The game treatment should also grab the publisher’s attention by focusing on the bottom line. You can do this by citing sales projections based on solid market and sales information relevant to your game.

When you have distilled your game into a single game treatment page, have others proofread it for you to see if they understand what you are trying to say and find the game idea compelling. Have it edited and reviewed by as many qualified people as possible.

Note: Many people erroneously believe the treatment is the first thing written, since it is usually the first thing read. But this document should be written last, right before you approach the publisher. The reason for this is that at this point you know as much as possible about your game. The treatment is a distillation of all the work that you have done designing, researching, and otherwise developing the game on paper.

Proposals and forms are often used by publishers and agents to weed out developers and game ideas. Not just bad developers and game ideas are weeded out however; publishers are just as likely to weed out inappropriate or unwanted ideas and developers.

4. Competitive Analysis

The competitive analysis illustrates to the publisher how you stack up against your competition. It must explain why your title will outsell the competition, yet how it will be similar enough to be sold right next to the competition on store shelves. A simple way to graphically illustrate how your game stacks up against the competition is a table that lists functions and features down the X axis, with your game and its competitors across the Y axis, checking off the features that each game has. You can also list other competitive differentiators here too, such as licenses, technology, development costs -- anything that will make your title perform better in the retail channel.

Be prepared to discuss each point of your analysis that relate to the competition. For example, if you list a great technology developed in-house as a selling point, you need to be prepared to discuss why it will give you an edge over the competition. Will it save development time or money? Will it make the game noticeably better? Or is it just a source of personal pride that doesn’t translate into publisher benefit?

The competitive analysis should contain at least five products (in today’s marketplace you shouldn’t have a problem listing ten or more) and at least five features of those products with a few paragraphs discussing the competitive analysis in terms of how you drew your conclusions. The most important determinant of what your competitive analysis contains is your game idea. You need to include your real competition and not leave out a top selling game hoping the publisher won’t notice your omission. The same goes for features, you can’t leave a feature out of your analysis because your competition has it and you don’t. Most importantly make sure the features you include have a selling point to them. And be honest too – there will be games that simply have features going for it that yours won’t.

The competitive analysis requires you to market your game -- and yourself. You are being given the chance to tell the business guys that your game will perform in the marketplace better than titles X, Y, and Z for reasons that you state as persuasively as possible in their language.

Done correctly, the competitive analysis can help you jump ahead of other developers by demonstrating to the publisher that you understand its goals. And once you've written it, you'll be able to rattle it off in conversations – and that helps convince others that your title stands a strong chance of performing well in the marketplace.

5. The Design Document

The design document is a long, in-depth document that shows the publisher your game in detail. The contents of the design document are substantial, and beyond the scope of this article. See The Anatomy of a Design Document by Tim Ryan for more information about what the design document should contain.

6. The Team Introduction

Convincing the publisher that you are a good risk is critical, so it's imperative that you build your credibility as a developer. Your "team introduction" (or "team bios") section lets you convey your experience via resumes, portfolios, and press clippings.

Most developers who submit games to publishers have little or no real industry experience or published games under their belt. This is why a substantial demo is required for publishers – it's the only way to prove to a publisher that you have the team skills, technical skills and personal ability to produce the title you propose. Even if the proposed title is a good idea, you still have to prove you can produce that good idea.

But make no mistake, just because you haven’t had any game industry experience and you have a great proposal doesn’t mean the team won’t be discussed at length by the publisher. They will want to know if you have any serious work experience (this will be looked upon favorably) or if you are just another gamer wanting to make a game. If you can demonstrate real world experience that relates to your job description in the proposal and you have a solid employment history, you will have achieved some level of credibility. Proving you can hold a job, deal with people and deadlines, and can communicate is a huge plus in the eyes of the publisher.

7. The Budget and Schedule

The budget and schedule are the amount of time and money it will take to make the game. I discuss Budgets and Schedules in the article Budgeting and Scheduling your game on Gamasutra.

8. The Game Demo

I mention the game demo last because it is most likely the most important part of your submission, especially if you are a not a top hit producer, and also most likely the part most of you are already familiar with -– actually creating the game.

This article is meant to give you a detailed overview of the business end of the proposal package and a detailed discussion of the technical aspects of the game demo are out of the scope of this article. A few words though. A game demo must obviously run well, not have any viruses on it, and be easy to use. A good menu is worth the trouble for a demo that is unable to be played is useless.

Putting It All Together

Working through all the aspects of your game proposal takes time, and it may feel like a real chore to a developer who would rather code or create art. But a well-formed proposal is the best tool to convince a publisher you can make the game you propose and that the game will sell.

Remember that although publishers are inundated with game submissions you can make yours really stand out by putting your best foot forward and you do that by giving the publishers what they want – a game that will sell and a development team that can make that game.

[Luke Ahearn has over fourteen years of professional game development experience and has served in lead positions such as designer, producer, and art director on seven published game titles including Dead Reckoning and Americas' Army and worked as a background artist at EA. He has authored six books on game development and ran his own computer game company for ten years. Currently, he is the Art Director and partner of ICPU.]