Game Survival Test

This test was developed by Erik Bethke, and appears in his book Game Development and Production, and is meant to be taken at intervals before, during, and after the project to evaluate the state of the game and its chance of success. It's a little skewed/biased when dealing with small teams, assuming that a small enough team can coordinate well enough to overcome most issued, but is an interesting exercise.

Have each member of the team complete this survey individually, then go through your results as a group, and for each question take the lowest score chosen by any of the team members.


For the project, answer each of the following questions with a value 1-3
- 1 means No
- 2 means Partially/maybe/sometimes
- 3 means Yes

    Game requirements

  1. Is there a clear, unambiguous vision statement for the game?
  2. Do all team members believe that this vision is realistic?
  3. Does the project have a reasonable expectiation of being profitable for both the publisher and the developer?
  4. Has the core gameplay and user interface of the game been fleshed out so that everyone clearly understands what the game is and why it is fun?
  5. Do the team members think the game will be fun?

    Planning

  6. Does the game have a detailed, written game design document?
  7. Does the game have a detailed, written technical design document?
  8. Does the game have a detailed, written art production plan?
  9. Do you have a detailed, integrated project schedule that lists all of the tasks that need to be performed, and have the dependencies between the various team members been indicated?
  10. Does your project schedule include tasks like
  11. Were the schedule and the budget for the game officially updated and discusssed between the publisher and the developer at the end of the latest milestone, even if to say "Yes, everything is on track"?
  12. Are the features of the game tagged with core, secondary, and tertiary levels of priority to facilitate feature trimming if necessary to maintain the schedule?
  13. Does the game have a written quality assurance plan that includes beta-testers, in-house testing, and automated test suites?
  14. Does the game have a detailed milestone plan that clearly describes what will be delivered and reviewed at each milestone?
  15. Does the schedule allow enough time for balance, tuning, and tweaking of features to ensure that it is fun?
  16. Does the schedule account for sick days, holidays, vacation time, and ensure that developers are tasked at less than 100% and that leads are tasked at less than 75%?
  17. Have all team members signed off on the the game design, technical design, art production plan, and QA plan?

    Project control

  18. Does the game have a single executive who has full authority, responsibility, and accountability for the success of this game and who fully and enthusiastically embraces those attributes?
  19. Does the project leader's workload give them adequate time to perform at the highest level of project management?
  20. Have the milestones been laid out with clear, measurable deliverables that can easily be quantified as done or not done?
  21. Are the milestones being delivered to the publisher in such a manner as to make it easy for them to review the milestones and measure the progress of the project for themselves?
  22. Do the developers have access to an anonymous communication channel where they can report problems without fear?
  23. Does the game project plan have a written plan for controlling feature creep in the game?
  24. Does the game project have a clearly defined method that team leads, such as art and technical directors, will use to review changes?
  25. Are all of the game design, technical design, schedule, art production, QA, and all other planning materials easily accessible to all development team members, and are the team members encouraged to read them?
  26. Is all source code under version control software?
  27. Are all of the binary assets, such as textures, models, music files, and sound effects also stored under version control software?
  28. Do all of the team members have the tools to do the job, such as workstations, development kits, bug tracking software, scheduling software, etc?

    Risk management

  29. Does the game project have a written risks document with possible solutions?
  30. Is this risks document updated at the completion of every milestone?
  31. Does the game project have a risks officer who is encouraged to scout ahead for risks on the project?
  32. If the project is using subcontractors, is there a written plan for how to manage them, including ensuring that each subcontractor is the responsibility of a designated development team member?

    Personnel

  33. Does the game development team have all of the expertise needed to complete the game?
  34. Does the development team have a management team that is experienced with managing game development, freeing the developers to concentrate on developing rather than worrying about the state of the project?
  35. Does the game have a lead programmer who is capable of leading the team to the creation of an excellent game?
  36. Are there enough developers to do all the work?
  37. Do all of the development team members get along with each other?
  38. Is each team member committed to staying with the game until it successfully ships?
Total up your answers, and if your team has 1-8 members mulitply the total by 1.5, if your team has 9-18 members multiply by 1.2.