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:

• Revised game concept (preceding)
• Market analysis
• Technical analysis
• Legal analysis (if applicable)
• Cost and revenue projections
• Art

Market analysis:

• Target market: The target market is defined by the genre and the platform, issues that have been already addressed in the concept document. You can qualify this definition by mentioning specific titles that epitomize this market. The most successful of these titles will indicate the viability and size of the market. Also mention the typical age range, gender, and any other key characteristics. If this game involves a licensed property or is a sequel, describe the existing market.

• Top performers: List the top performers in the market. Express their sales numbers in terms of units and $. Detail who developed and published the game.

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.

• Experimental features: Identify the features in the design that seem experimental in nature, such as untried or unproven technologies, techniques, perspectives, or other unique ideas. Include an estimate of the time that it will take to bring the experimental feature to an evaluation state, as well as an overall time estimate for completing the feature. Experimental areas generally need more time in the schedule, so the more experimental features you list, the longer the schedule will be.

• Major development tasks: In a paragraph or a few bullet points, make clear the major development tasks. Use language that non-technical people can understand. Major means weeks/months of development. Give a time estimate that assumes that you have all of the resources that you'll need to accomplish the task. You could also give an estimate of the resources that you'll need.

• Risks: List any technical risks. Risks are any aspect of research and development that will cause a major set back (weeks or months) if they fail. List technologies that, though they've been proven to work by competitors, your company has never developed or with which your company has little experience. All untried off-the-shelf solutions (3D engines, editors, code libraries and APIs, drivers, and so on) should be listed as risks because they may end up not fulfilling your particular needs. Any development done by an outside contractor should also be listed, as that's always a big risk. When assessing risks, you should also indicate the likely impact that fixing or replacing the technology will have on the schedule. Indicate the time in weeks or months that the ship date will slip. List the time impact on specific resources. List any new resources (people, software, hardware, and so on) that would be required to fix it.

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.

• Alternatives (if any): Alternatives are suggestions for working around some of these experimental or risky features and major development tasks. By presenting alternatives, you give the reviewers options and let them make the choices. List anything that might cost more money or time than desired but might have better results, or vice versa (it may cost less money and time but it may have less desirable results). Whatever you do, be sure to spell out the pros and cons.

• Estimated resources: List the estimated resources: employees, contractors, software, hardware, and so on. Use generic, industry-standard titles for people outside of the company: for instance, the publisher or investor who might read your document. List their time estimates in work months or weeks. Ignore actual costs (dollars), as that comes later.

• Estimated Schedule: The schedule is an overall duration of the development cycle followed by milestone estimates, starting with the earliest possible start date, then alpha, beta, and gold master.

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.

• Resource cost: Resource cost is based on the estimated resources within the technical analysis. Employee costs should be based on salaries and overhead, which the finance or payroll department should provide. You can list these as average by title or level. Any hardware or software that you purchase should be listed as well, even if it will ultimately be shared by other projects or folded into the overhead budget. Use a spreadsheet template provided by the Business or Development Manager.

• Additional costs (if any): This section is an assessment of additional costs incurred from licensing, contracting, out-source testing, and so on.

• Suggested Retail/online Price: You should recommend a target retail price. The price should be based on the price of existing games and an assessment of the overall value being built into the product and the money being spent to develop and manufacture it.

• Revenue projection: The revenue projection should show pessimistic, expected, and optimistic sales figures using the costs that you've already outlined and the suggested retail price.

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:

• The analysis is based on magic numbers. Try to back up your numbers by listing your sources or explaining how you came up with them.

• The proposal fails to anticipate common-sense issues and concerns. You should find out what this proposal is up against -- other proposals, competitive products, financing concerns, cost and time expectations, game prejudices, and historical mishaps. Your proposal will stand a much better chance of being approved if it addresses these issues pre-emptively rather than getting besieged by them during the review process.

• The proposal writer is overly sensitive to criticism. Once your proposal is solid and well prepared, it will receive a fair hearing.

• The proposal writer is inflexible to changes to the game. Often during the process of gathering research or receiving criticism from other staff, some reasonable suggestions will arise for changing or scaling back the design. Game development is a collaborative process. Good feedback needs to be included in the game proposal.

• Ensure the proposal is exiting and realistic – even a small game is a new venture for the company.