     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Game Proposal
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. 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:
|
|||||||||||||||||||||||||||||
Features
2. The Game Overview|
|
|