This document was created to accompany/expand upon the information contained in the feature Preparing a pitch which discusses the process of preparing a product submission (the pitch) for presentation to a publisher.
In February 2003 the IGDA (International Game Developers Association) survey of publishers revealed that the single most important aspect of a product submission (the pitch) is the game/code demo. The survey further found that a large proportion (77% of respondents) would be unlikely to sign up a game without a demo. Surprisingly many developers (especially new companies) fail to grasp the importance of the demo. Many consider that the work done to create a polished and well presented demo is time that could be better spent working on the game. Much of the code needed to create a good demo will never be used in the finished game. It is written simply to “paper over the cracks” – to cover those elements of the final game that have not been implemented yet and to prevent the demo from crashing. The IGDA’s survey shows how wrong this attitude is. For a commercial developer, seeking to secure publisher funding, creating a high quality demo is of vital importance.
What is a demo?
It is sample code/graphics/audio that demonstrates key elements of the proposed game. Depending on the genre of the game this could be an entire game level or part of one (FPS), a single race track with a couple of cars (racing) or a few locations/rooms with puzzles (point and click adventure game). Obviously the larger the demo (more features), the easier it is for a publisher to understand what you hope to achieve and the easier it is for them to make a decision. However the scope of your demo will mainly be governed by the time/resources you have available. The main difference between a good and a bad demo is quality of design and implementation.
What are the objectives of a good demo?
1. To demonstrate key game play and design elements of the game.
You can’t show the entire game (if you could you wouldn’t be pitching to a publisher for funding) so instead select a few key game play features. For example your platform game engine would be designed to have backgrounds, sprites, collision detection, scrolling, doors (links between levels), stairs, elevators, moving platforms, switches, keys, slippery floors, collapsing platforms etc. Depending on the resources you have available your demo would only be able to include a few examples of these game play features. The key is to pick the most impressive/vital ones such as scrolling, collisions, level links and a few of the actual platform features and then create a small environment that shows them off well. Bigger is not necessarily better exactly because you have a limited set of features. Taking a large level and filling it with only a small set of the proposed game features will make the demo seem empty and boring. By limiting the size of your environment and filling it with your few example you create a better feeling of playability.
2. To show the publisher that you are a creative, professional and competent developer.
The demo needs to start, run and exit gracefully and contain the minimum number of bugs. This is because the non-technical staff at a publisher (marketing, PR, sales, finance) are likely to view a demo that contains bugs and take it as an indication of the (poor) quality of the finished product. If a game feature is not finished/working properly then don’t include it in the demo. Filling a demo with a large number of malfunctioning features simply isn’t a good advert for your game or you teams abilities. Less but better is the key.
Include a nice title screen and, if the publisher needs to make any options selections to run the demo, ensure they are presented on a well designed and well implemented menu. Hide any programmer initialization information behind a simple and neat “loading please wait” screen. Programmers may find it useful to display frames per second or the current start up status of the game code but this doesn’t make for a well presented demo. Turn it off or hide it. End the demo with a nice “congratulations you won” screen or at the very least return to the title screen gracefully. Also remember to clearly display your teams name/logo and contact details on the demo in case the accompanying documentation gets lost.
3. To prove that you are capable of producing real code of an acceptable quality (or if you are using a licensed engine, that you can make use of its features).
Non-interactive video presentations are no longer acceptable as demos with which to secure a publishing deal. Too many publishers have signed up such projects only to find that the team was unable to do the necessary programming to realise the vision. Previously burned publishers now want to see interaction in action before they will sign a project. Unfortunately this means that the developer must shoulder the cost of developing demo technology (or license an existing engine) with which to produce a demo.
4. To demonstrate how much effort you have put into your demo.
Just presenting the demo in its complete form may seem like a good idea but it isn’t. To generate the best results you need to clearly show the amount of effort that went into creating the demo. Taking the platform game example again, start your demo with a blank screen then quickly turn on background display, then the player sprite, make him move (animation) and in so doing reveal new engine features (animating background or moving platforms). Use brief text pop-ups to point out these features as you introduce them. Then end by inviting the user to take control and experience the demo environment for themselves. In this way you ensure that all your efforts are clearly displayed to the publisher and in so doing you increase the perceived size of you demo.
Producing a high quality demo can be a lot of work but it is the single most important item when attempting to get a deal with a publisher. There will always be limits on the resources you can invest into a demo but the more effort you make the more likely you are to secure a deal. Rightly or wrongly publishers view a demo as an indication of your teams design and programming abilities and the likely quality of the finished game and any developer who ignores this does so at their own (financial) peril.