Instuctional Game Design Documentation

The game design documentation for an educational game includes (1) an instructional design, (2) game design, (3) art, (4) programming, (5) data-analysis, (6) and logistics sections. This document emerges out of the work done by the subject matter expert, instructional designer, and the game designer for the team. The lead programmer and lead artists also contribute during the design phase by using their expertise to chart out how the team should tackle the technical portions of the game.

I) Instructional Design

• Audience Analysis: An analysis of the learner's current skills and how those skills map to the instructional content
• Entry Behaviors: Identification of the learning objectives the player must have mastered prior to playing the game in order to be successful. Any skills or knowledge identified as an entry behavior will not be covered in the game. It is a pre-requisite for the game.
• Instructional Goals: Broad educational goals for the game.
• Instructional Objectives: Performance objectives for the game. It is very critical that instructional objectives are granular enough to allow for the diagnosing of instructional problems. At a minimum objectives should address (1) behavior to be measured, (2) conditions under which the behavior will be measured, and (3) a minimum level of achievement needed to master the objectives.
• Assessment Items: Assessment items for each of the learning objectives should be created. It is important that each assessment item only tests a single instructional objectives. In the case of an educational game the assessment items are often constructed as in-game activities that map to specific learning objectives.
• Presentation Strategy: With the audience analysis, learning objectives, and in-game learning assessments prepared, we can then concentrate on how to present the necessary instructional materials to the learner in a manner that will prepare them to successfully complete the assessments. In the case of most educational games, the presentation strategy will drive many of the gameplay decisions about the game. The game-mechanics and game narrative will reflect the presentation strategy.

II) Game Design

• Game Concept:
  • Game Description: This is a very broad description of the game.
  • Genre: What kind of game is it?
  • Platform: Will this run on a PC, console, PDA, phone, etc.?
• Game Mechanics:
  • Core Gameplay: What actions will be available to the player consistently and how will those actions influence the world?
  • Mode of play: How many different modes of play will be available in the game?
  • Game Flow: How will the player progress through the game be organized. Is the game broken into levels? What triggers the end of a level? How will in-game assessments be integrated into the flow of the game?
  • Types of Characters: How many different types of characters are there? How do they behave differently in the game?
  • Gameplay Elements: What environmental elements exists in the game that add to the game play? Will there be items that act as a power-up? etc. Are there different types of weapons?
• User Interface Functionality: What are the user interface items and what functionality is needed for each of the items. This includes screens and menus.
• Narrative: The back-story for the game and characters

III) Art

• User Interface: What do the screen elements and menus actually look like? This should include the color scheme, resolution, fonts, etc.
• Gameplay Elements: What do the game elements look like? This includes sketches of the characters and the setting for the game.
• Sound and Music: Identifies any needed music and sound effects

IV) Programming

• Special Technical Requirements: Details any technical requirements that are beyond the norm for a game. If the game will rely heavily on networking or use a special type of rendering technique, it should be noted here.
• Game Engine: Will a particular game engine be used?
• Rendering: How will rendering and light be handled?
• Artificial Intelligence: How will AI be handled?
• Physics: How will physics be handled?
• Gameplay code: How will gameplay specific code be handled?
• Instructional data tracking and analysis: Are there any data tracking requirements for the instructional aspects of the game? How will that be done? Do we need to interface the game to a database? Do we need to send performance data via the network in real-time or can we batch it after the gameplay session?

V) Instructional Data Analysis

• Data analysis model: How will the data generated during the gameplay session be analyzed?

VI) Logistics

• Human Resources: How many people will contribute to the game and in what capacity?
• Schedule: How much time has been allotted to each task?

Sample documents are provided in our members area.