Guidelines for the Game Feasibility Study


Created by: Game Producer/Business Manager

Target audience: Game Approval Committee/Investors

Approval: MD & Development Manager

A game feasibility study is a formal project proposal used to secure internal or external funding and resources for a game development project. It is designed to assess the business and technical potential/problems of the proposed project i.e. can we make it, if so can we make at a profitable level. After the study, the game project is either further developed or cancelled. As a game feasibility study takes time (and therefore, money) to do correctly, it should only be developed for promising game concepts.

The study is an expansion upon the game concept. Writing and researching a study may involve gathering feedback and information from other Eirplay senior staff, especially marketing input and the Development Manager. You may need to perform some market research and analysis on the concept. If the game requires licensing, you may need to investigate the availability and costs involved in securing the license.

The programming staff, typically a senior programmer, should perform an initial technical evaluation of the concept. They should comment on the technical feasibility of the concept and the programming areas that may require research. They should assess the risks and major tasks in the project and suggest solutions and alternatives. They should give a rough estimate as to the required research and development time and resources.

The game feasibility study should include a revised version of the game concept. Technical, marketing, and finance feedback to the concept document might force you to scale back the concept. It might also suggest modifying or adding features. These changes should not take anyone by surprise, as this is the first time that the concept has been subjected to major criticism and the collaborative process.

The game feasibility study includes the following features:

Market analysis:

Feature comparison: Break down the selling features of these top performers. Compare and contrast them to the key features described in the concept document.

Technical analysis: The technical analysis should be written by a programmer, preferably a senior one, then edited and compiled into the study. Reviewers of this proposal will use this technical analysis to help them make their decisions.




This section may seem pessimistic, but it creates a comfort level for your document's reviewers - they will come away with the impression that the game implementation is under control, especially if they can perceive these risks themselves.




Legal analysis (if applicable): If this game involves copyrights, trademarks, licensing agreements, or other contracts that could incur some fees, litigation costs, acknowledgments, or restrictions, then list them here.

Cost and revenue projections: This data should give the reader a rough estimate of resource costs based on the technical analysis's estimated resources.



Art: If your game concept did not include any art, then the game proposal certainly should. The art will set the tone for the game. Assume that the readers may only look at the art to evaluate the proposal, so be sure that it expresses the feel and purpose of the game. Include a number of character, unit, building, and weapon sketches, in both colour and black and white. Action shots are great. Include a GUI mock-up if your game is a cockpit simulation

Presentation: The whole proposal, including the revised concept document, should be printed and bound. In addition, a brief slide show program should be prepared in MS PowerPoint.












Common Mistakes
Some common mistakes in preparing a game proposal include: