A Serious Approach To Serious Game Development
•Als PPTX, PDF herunterladen•
1 gefällt mir•629 views
Presentation given at the Society for Interactive Learning Technology (SALT) Washington Interactive Technologies Conference 2010 by Ron Punako, Jr. and Joy Pachucki
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie A Serious Approach To Serious Game Development
Ähnlich wie A Serious Approach To Serious Game Development (20)
A Serious Approach To Serious Game Development
- 1. A Serious Approach to Serious Game Development Ron Punako, Sr. Software EngineerJoy Pachucki, Instructional Designer
- 2. Your organization decides to develop a serious game
- 3. You are tasked with planning and developing the game
- 4. You must quickly produce a product that will succeed in it’s learning mission
- 5. Put the proper processes into place
- 6. You will stand a greater chance of success
- 7. BackgroundGames for what purposes? (2008, Sawyer, B., Smith, P., “A Taxonomy of Serious Games”)
- 8. BackgroundIndividual first-person perspective role playing games
- 10. Sound Engineer
- 12. Video Engineer
- 13. Voice Actors
- 15. Systems Development Life Cycle
- 16. Systems Development Life CycleAnalysis Project Planning Initial Client Meetings Instructional Intent Assess Training Needs Determine Training Solution Client Requirements Technical Specifications Identified and Analyzed
- 17. EngineeringClient requirements ID: CLIENT1 The simulation shall enable the learner to progress by completing decision points within a scenario. Derived Requirement1 Derived Requirementn Use Case 1,2,n.. Trace to
- 18. EngineeringUse cases Scenario: 1. Learner: Observes the NPC in the first person. 2. NPC: Speaks to player to set up choices for current dialogue. 3. Learner: Observes the character dialogue choices. 4. Learner: Selects a dialogue choice. Exceptions: … ID: UC1 Name: Select Character Dialogue Choice Primary Actor: Learner Goal in Context: To select a character dialogue choice. Preconditions: 1. The Start System use case has been completed successfully. 2. The Start Simulation use case has been completed. 3. A decision point has been reached. Trigger: The learner decides to select a character dialogue choice while speaking with a non player character. Derived Requirement1 Derived Requirementn Derived Requirementn Trace to
- 19. EngineeringDerived requirements ID: FUN1 The simulation shall provide the capability for the learner to respond to character dialogue. Derived Requirement1 Derived Requirementn Design1,2,n.. Trace to Derived Requirement1 Derived Requirementn Trace to Test Case 1,2,n..
- 20. EngineeringRequirements traceability ??? FUN1 USE1 CLIENT1 ???
- 21. Systems Development Life CycleDesign Concept Paper Development Simulation Course Outline Screenplay Development Initial Product Asset Development Technical System Design
- 22. Systems Development Life CycleDesign Continued
- 25. EngineeringTechnical Solution Plan API Level 3 DFD Level 0 DFD … Class: Dialogue Description: A dialogue object. Methods: load, showResponses, getResponses, setStatement, get Statement, … Class: ResponseDescription: A dialogue response object. Methods: getResponse, setResponse, … Derived RequirementFUN1 Trace to
- 26. EngineeringInformation Architecture Plan Structure Content Model Visual Skeleton
- 27. Systems Development Life CycleDevelopment Text Simulation Development Asset Development Product Development
- 29. EngineeringGame engine development Event Sequencing Subsystem Sound Subsystem UI/Menu Subsystem Unity Character AI Subsystem Append Functionality Abstract Functionality Purchase Game Engine Notification Subsystem Animation Subsystem Virtools Lipsync Subsystem ScoringSubsystem
- 31. EngineeringIntegration Sequence of Events Sound Scoring Character AI Characters Scenario Authoring Tool Production Game Level Staging Video Decision Points Environments Animations UI/Menus
- 32. Systems Development Life CycleImplementation Verification for adherence to instructional specifications Final product installation Validation testing and discrepancies resolved Product training conducted Final review and acceptance
- 33. EngineeringVerification testing ID: TST1 Prerequisites: 1. The system must be started 2. The simulation subsystem must be started Actions: 1. NPC engages the learner’s character in dialogue 2. Learner attempts to select a dialogue response Outcome: 1. Pass: The learner is able to select a response to character dialogue 2. Fail: The learner is not able to select a response to character dialogue Derived RequirementFUN1 Trace to
- 35. Systems Development Life CycleEvaluation Evaluation tasks directly planned in support of individual efforts, if applicable, would apply to each part of the process
- 36. Questions?
- 37. Putting ideas into action.SM 1-800-CTC-4392www.ctc.com
Hinweis der Redaktion
- My name is Ron Punako and I am a Software Engineer. This is Joy Pachucki who is an Instructional Designer. We work for Concurrent Technologies Corporation (CTC). CTC is a non-profit, applied research and development corporation. Joy and I work on Serious Games at CTC under our Readiness capability. Today we are here to discuss some of our experiences with developing serious games throughout the Systems Development Life Cycle (SDLC).
- Your organization has decided to develop a serious game. Serious games are designed to educate, train and inform their learners. (Michael, D., & Chen, S., 2006) Some commercial game development companies are turning to serious games development to leverage their existing technology to fill funding gaps between major title releases. Some organizations are dedicated to serious game development.Gaming scenarios are intended to allow application of specific skills and concepts in a controlled environment. Learners become immersed in a scenario and are required to make decisions, apply complex procedures, and develop more extensive work products. Gaming scenarios may encompass extensive scenarios, complex decision points, detailed procedure application, work product development, remedial feedback, multiple levels of difficulty, multi-role play, and dynamic characters that change their responses and courses of action based on learner interaction.
- And now the responsibility has fallen to you to plan and develop a game. You need to determine what resources and processes should be in place to help ensure that your game will succeed in its instructional mission. No easy task, especially if you are starting from the beginning.
- A typical serious game requires that it be developed in a relatively short amount of time and on a relatively small budget. In a survey by (2006) Michael and Chen of developers, researchers and educators found that approximately a 25% majority of respondents placed their serious game development efforts between $100,000-$500,000 and 35% reported development times of 6 months to a year. This combination can make it difficult to take the time to plan and execute an effective approach to serious game development. It is important to resist the urge to just “Jump In” to development without a planned approach.
- With the exception of prototypes, organizations sometimes focus upon implementing core functionality instead of creating a complete, well-rounded product. In the case of serious game development, learning cannot be an afterthought or be “bolted-on”. Two examples of this come to mind including usability and security. Usability is the sum of a user’s experience with a system including its documentation. For example, What good is a car, for practical purposes, if it contains a good engine, but a poorly designed and unusable interface such as a steering wheel, pedals, gear shift, etc. This is what can happen when usability is not considered as an integrated part of design and development or as an afterthought. It is, in fact, a direct contributor to technophobia. Some organizations take a similar approach to the design and development of security within systems. A poor decision given that there are millions of would-be and professional black-hat hackers exploiting systems and only a few thousand good folks working to mitigate attacks. Often, these types of efforts create incomplete, poorly integrated products.When developing Serious Games, it is important to take an integrated approach to instructional and engineering design and development. It is critical not to depend solely on the multimedia provided by these games to ensure that the intended instructional experience is delivered. Although intended for learning, these kind of games tend to focus more oftenon entertainment, sometimes called Edutainment, instead of learning.
- Serious games are a software system and they typically require a formal approach to development to succeed.Today, I will talk to you a bit about the backgroundof the kinds of games that we develop to provide you some context into the kind of efforts that our presentation is based upon.Next, Joy and I will discuss examples of our processes and experiences in developing those games at each stage of the Systems Development Life Cycle.
- The development of games and simulations for education is not a new concept. In fact, it is a movement that has been well underway across the DoD since the mid-1990s. The management and technical players included on the CTC Team have been designing, developing, and implementing games since well before then and will blend their experiences.Here is a taxonomy of serious games which is quite large as you can see. I could not fit the entire taxonomy onto the slide and have it be viewable. The areas and clients that we work for are shown in yellow. We develop war game and disaster response group training games that train battle staffs at the strategic and operational levels and First-Person Role Playing games and simulations that train individuals at the tactical level. Our discussion today will be focused around examples of our experiences and processes uses in development of these types of games.
- We develop first-person perspective role playing games (RPG). These RPGs enable the learner to experience a number of linear and dynamic training scenarios as a character within a 3D virtual world. There are a number of inherent learning principles at work in well-designed RPGs that are independent of the content that is being taught. Some of these principles include identity and co-design.Identity is when the learner takes on the role of the person they are training to be or their own real-life role. Doing so provides the learner a environment in which they experience, first-hand, the values, attitudes and actions associated with a role that they may not receive otherwise through memorization of terms and definitions. (J, Gee., 2008)Co-design enables the learner to become active contributors to the training environment instead of passive observers. Unlike a movie in which an actor is observed performing his role throughout a finite scenario, the learner becomes an active agent within a scenario so that they may change the scenario. Being able to change the scenario enables the learner to experience training from different angles over time which is a key enabler to reflective learning and horizontal learning before they move to vertical learning. (J, Gee., 2008)
- Developing one of these types of games is similar to producing a small movie with an outcome that is determined by the learner.That being said, the development effort requires a range of talents from writing to animating to programming. The slide shows a typical list of staff required on these efforts. Being that serious game development efforts are typically smaller efforts in terms of time and budget, it is advantageous to find staff that are cross-trained in these disciplines for integration and backup purposes. For example, Artists may also serve as Modelers/Animators and Video Engineers may also serve as Sound Engineers. It is also advantageous to have Program and Project Managers that understand the unique needs and capabilities of this kind of team as there are many different kinds of perspectives to take into account.The development of games and simulations for education is not a new concept. In fact, it is a movement that has been well underway across the DoD since the mid-1990s. The management and technical personnel included on the CTC Team have been designing, developing, and implementing games since well before then and will blend their experiences.
- Everyone’s project needs are different based upon the type of game that is being developed and the amount of time and resources available to complete development. So, I will tell you a bit about the resources and technology we use to develop our games to provide you some context. We use the Virtools, and recently, Unity game engines which are both capable of producing immersive 3D games that will run in a Web browser. We develop both the development tools for our games and the game engine extensions to run them. A typical project that we undertake costs between $400,000 and $1,000,000 dollars, takes approximately a year to complete and is worked on by a team of between 6-10 people. All of these figures are typical of industry averages for serious game development (Michael, D., Chen, S., 2006). What these figures tell us about our efforts, and those of industry, is that there is not a great deal of time or money to get things done with a small team, especially when developing your own development tools to get started.
- The Systems Development Life Cycle adheres to instructional design and systems development processes and methodologies with constant consideration for Quality Assurance (QA). While key milestones are defined separately in specific project plans and schedules, they will reflect and step through these stages. It is important to note that this process is not linear and that many of the stages overlap. When developing any system, including games, it is advantageous to follow standards and processes. Every company’s approach to choosing and institutionalizing them is different. To give a bit of background on our own processes, we follow the ISO 9001 quality standard, Carnegie Mellon’s Capability Model Maturity Integration (CMMI) for Systems Development and proprietary Systems Development Process (SDP). We are accredited in both the ISO 9001 standard and at the CMMI Dev Level 3, which means that our processes and procedures are standardized throughout our organization. Each of these build upon the other in an increasing level of operational detail. The reason we go through the trouble of following these is to ensure quality of processes and products throughout our process, the lifecycle.
- Initial client meetings are critical. This is the time in which initial expectations about the game are set. Questions that need to be answered may include: What is the instructional intent? Leveraging instructional design expertise, advanced technologies, and past performance to develop performance-enhancing instruction. Whether that be a game, a simulation, or a combination of both (which is most common). It is good to be knowledgeable of the principles of learning in games and not rely solely upon well worn explanations (It’s engaging, it’s what young adults do) to answer this. During this phase, the instructional design team is working very closely with the client to assess training needs. This is often done through a variety of means – most commonly the organization’s training support plans, strategic plans, deficiency reports and meetings (workshops, summits) with key decision makers and subject matter experts (SMEs). Once the training needs are assessed and gathered, the instructional design team works with those key decision makers (and SMEs, if applicable) to prioritize training needs. Skill deficiencies, new skill development and return on investment are core topics of these discussions. Together a training solution is determined, an outline developed and resources identified and obtained. Note that for serious games this stage of the process is no different than it would be for facilitated instruction or web-based training. Just like all training solutions, analysis is a key process area in the systems development effort. What are the client requirements? Questions that need to be answered may include: What are the system specs in the classrooms where the system will be deployed and/or will the learners be distributed, and where? Does the system have to comply with the American’s with Disabilities Act Section 508 standards? These are just some of the questions that help determine the software and hardware required for integration, and for the engineers to begin preparing client requirementsfor the system. What are the technical specifications: Should the system provide the capability to author scenarios without technical knowledge? Has the software passed any certification and accreditation process, or will it need to? (Especially important if running on a government or military network.) If the system is a prototype on a short timeline this may be very difficult. This runs hand-and-hand with another important question, is there a requirement to teach classified subject matter in the system? (Classified systems have much different requirements, accreditations and processes overall than unclassified systems.)These questions are not what commercial game development houses typically have to worry about. These questions and their answers distinguish a serious game. At the end of this phase, the key decision makers work closely with the project managers, instructional design team and software engineers to come to a decision and determine the requirements.
- After elaborating client requirements during the initial client meeting and from project narratives and the client Statement of Work (SOW) they are formally written them into an Operational Requirements Description (ORD). The ORD is a short document that include requirements that are written in “Natural Language.” That is, these requirements are written as compound statements of functionality that the client clearly understands, and are sometimes co-designed statements. Before further planning may occur, the client must approve these requirements as they are the basis for more detailed planning and design required to create the game.A typical client requirement for a serious game may read “The simulation shall enable the learner to progress by completing decision points within a scenario.” For tracking purposes, we will give this requirement the ID CLIENT1. This requirement may involve many different sets of functionality. For example, it contains the nouns learner, decision points and scenario. Therefore, we may assume that these will become objects in the game. Similarly, it also contains the verbs progress and completing, which may become “actions” that may be taken within the game. To help sort these out, this requirement’s component parts will need to be broken down into one or more use cases in order to determine how this functionality might occur in the serious game.
- Use cases help Software Engineers elaborate how goals or tasks are achieved in the game. Several use cases may be created per client requirement or from multiple client requirements to help determine different scenarios in which goals and tasks could be achieved. In short, it helps Software Engineers think deeply about the problem that must be solved by using the system.In the example use case on this slide, we are continuing on with one possible scenario based upon the CLIENT1 requirement to provide the capability for the learner to complete decision points to progress through a scenario. One possibility is to have the learner’s character within the virtual world speak to a Non-Player Character (NPC)”. An NPC is a character that is controlled by the game itself and not the player.Note that the Use Case has been given an ID of UC1 for tracking purposes. It shows who the primary actor of the use case, the learner, and the goal which is for the learner to select a response to NPC dialogue. There are two other use cases that are required preconditions of this use case. Here we can see how multiple use cases and, thus, their client requirements are related to the current use case. The trigger for the use case requires that the learner attempt to respond to an NPC in conversation. Finally, there is a detailed breakdown of the scenario and its actors. There is more data that could be added to these use cases, if desired, such as exceptions, channels to actors and secondary actors.Once a use case is completed, it may be used to create one or more derived requirements to support it and, therefore, the CLIENT1 requirement.
- Derived requirements are created based upon functionality selected from the use cases. One or more requirements may be generated for a single use case. In contrast to client requirements, derived requirements are written in “Requirements Language”. That is that these requirements are atomic, unambiguous, complete and are testable. These are the requirements that Software Engineers will use to create the game. These requirements can cover a variety of requirement types such as functionality, design, documentation, interfaces, supportability and others.In order to partially satisfy the use case we created, USE1, we will create a new derived requirement, FUN1, standing for “functional requirement 1” that reads “The simulation shall provide the capability for the learnerto respond to character dialogue”. This is one of the possible requirements that could result from the use case. Notice that there is no “design” information in this statement about “how” to implement this requirement. This is to allow designers maximum design freedom.Once a derived requirement has been completed it may be traced to one or more design elements or test cases.
- In order to be able to track what has been requested by the client, what has been designed, developed and tested we use requirements traceability. Consider the back of your entertainment center. Do you have a rats nest of wires there between your various components or do you have your wires labeled? The rat’s nest represents poor traceability and the labeled wires represent good traceability. It is not difficult to plug the wires in any which way when you are hooking the components together initially. The problem is when you have to trace the wires back to their source to verify connections or disconnect things. This is the problem created during monitoring and control when we need to change to something in the game project, but don’t know where the authority or initiating requirement for the thing being changed came from.Its important to maintain traceability from the beginning of a project. Fortunately, we have been already have been going over an example of traceability from client requirement formation, CLIENT1 to use cases, USE1, to derived requirements, FUN1. If there is a change in any of these components we now know where they came from and what they are related to. We can trace further into the games components to design and test cases. We will discuss these two items in more detail later.
- As we noted in the previous slide, the instructional intent of the training solution has been determined. This allows for the Systems Development Life Cycle to really be spun into action. All team members are beginning to layout some initial ground work. The engineers are determining the design and build of the game, the artists are beginning initial product and asset design and development. And the instructional design team is working closely with the client to develop a concept paper and outline of the game. This concept paper, as we term it, details the terminal and enabling objectives of the game, along with a character list and descriptions, and a thorough scenario synopsis and outline of the games branching. The level (Beginner, Intermediate, Advanced, etc.) of the game is determined (again this stems back to the solution determination in Analysis) and from that the technical and instructional design expanded. Level of the game refers to the type of interactivity and amount of guidance provided through remedial feedback, resources, etc. Many organizations have their own definitions and requirements for these levels, such as the DoD Handbook for the Development of Interactive Multimedia Instruction (IMI).Once the concept paper is approved by the client, we move forward to expand the scenario, its branches, key decision points or knowledge reinforcement activities, and remedial feedback fully to support the client’s current curriculum and/or training needs.
- During this stage the instructional design team is working closely with the engineers to develop a rubric for the game, the example shown here shows a game where learners will be required to apply knowledge and skills within a simulated environment by making the correct choices at decision points. These decisions may (and/or could) require the learner to execute defined procedures, complete required tasks, or develop specific work products (such as briefings, reports, quad charts, etc.). Authentic and traditional assessment methods will be applied to determine gains in knowledge and skills. Methods such as self-assessments, objective tests, observations, and work products will assess knowledge and application of concepts, procedures, and principles. These assessments are then mapped back to the instructional objectives of the game, through a cognitive map. Bloom’s Taxonomy is most often used as the basis for categorizing behaviors and assessment methods through the cognitive map.
- Technical investigations are undertaken during requirements formation to help vet and validate anticipated design decisions. These “investigations” may involve their own mini plan, design, execution and testing cycles to help validate these anticipated design decisions. Notice that this is a form of design and, yes, it takes place prior to requirements being formalized and approved. Therefore, technical investigations force a game to take on some risk. Why do we do this? In the beginning of a project, Software Engineers often have to wait until instructional objective, the script and requirements are established to start designing and building the game. Once design starts, it is easier to fall back upon tried and true designs because it they are familiar and low risk. Technical investigation turns this kind of thought on its head by taking a calculated risk to help see what new designs are going to work and what is not before formal design and development begins. This approach allows Software Engineers to do some self-directed work (Pink, D., 2009). That is, that the Engineers are allowed to perform research in their area of interest and passion to be applied to the design and that makes work intrinsically motivating. This approach also helps to reinforce “Beginner’s Mind” (Duggan, B., 2007), which is the opposite of constantly relying on mastery of past designs. It requires that the Software Engineer take a open-minded view of the design challenge and put aside titles and mastery. This is important as in the serious games industry Software Engineers are required to stay on top of the latest in technology. In this way, we are able to make design innovation a priority on each project.On our current project we had completed a technical investigation that produced a prototype sequencing engine. The sequencing engine showed how the Unity software could be used to sequence event and character dialogue decisions in a game. The investigation enabled Software Engineers to design and build a production version of the engine quickly once formal design and development had started.
- The art plan is used to detail the vignettes, graphics, models and animations to be used in the game as specified in the game scripts. The art plan is critical to communicating the overall visual theme and style of the game and ensuring that the visual design “hangs together” well. The plan works in an increasing order of fidelity from initial concept art to the final art as created in our production graphic and modeling tools. The inputs for the plan come primarily from the scripts developed by the writer. Each character, animation and environment are given an matching ID within the Scripts and the Art Plan to establish traceability throughout design. Props and less significant details are not assigned IDs for practicality. Inputs to the plan may also come from design requirements specified by the customer. For example, the client may want to co-design a character’s physical appearance based upon specific demographics. However, in most cases we find that the client typically provides reference and instructional material from which our artists are able by be creative in design.The Art Plan is also the where all visual quality standards and character, environment and animation development processes are established for artistic components.
- The Technical Solution Plan is used to do several things such as create the system architecture, create the system data model and evaluate system design alternatives. In order to do so, derived requirements are allocated to design. For example, returning to our character dialogue requirement FUN1 to provide the capability for the user to respond to character dialogue,we may determine that we will require a character dialogue subsystem that is a part of a greater decision subsystem that controls the sequencing for events in the game. We could then develop a data model that details the classes and methods required to support the character dialogue subsystem. We may evaluate two or more alternative approaches to how the data model is organized based upon a set of selection criteria and log the results to substantiate the choice. Design requirements will also be allocated to specify system requirements. System requirements are critical to get right, especially with 3D RPG style games as they can be very resource demanding. If the system is being accredited to run on a government or military network then additional requirements may be needed to be allocated to system requirements. Interface requirements will be allocated to detail software and hardware interfaces needed to communicate with internal and external systems. These come into play when a system needs to authenticate to a single sign-on server or when a student must be authenticated to and LMS. Finally, supportability requirements are allocated to create maintenance and deployment instructions.
- The Information Architecture Plan is used to develop the information model for the serious game. There are several different ways to achieve an information architecture. We use a subset of the Information Architecture approach provided by Jesse James Garrett, the inventor of Asynchronous Javascript and XML (AJAX). The approach requires four different layers that when laid one on another like pieces of acetate, create a comprehensive information model including the structure, content model, skeleton and visual layers. The structure layer consists of the hierarchical structure of the game screens. Create a structure that is too deep and risk the learner not being able to find what is needed. Create one too broad and risk information overload. The second layer consists of a content model. The content model builds upon each screen by specifying an “inventory” of what goes on each screen such as text, images and controls. Note that this layer lists the inventory items by name and is not a visual inventory. The next layer, the skeleton layer, provides wire frame diagrams that visually build upon the content model inventory items. Now we essentially have blueprints detailing each screen and their contents. Finally, the visual layer is where graphics and prototype screen shots are developed to realize the wire frame blue prints.The Information Architecture provides several advantages that may not be immediately noticeable. First, the plan provides a single document that enables a decomposition of the system from conception to visual design. Therefore, the document is great to share with the client for understanding on how design decisions were made. Second, the plan provides a single document that Information Architects, Software Engineers, Graphic Designers and Managers can all contribute to and can use to coordinate situational awareness of the product being developed on many levels. Last, but not least, the Information Architecture helps us to think deeply in terms of game usability. We can apply usability heuristics to the wireframe designs and provide paper prototypes of the wireframes to test users before we have written a single line of code, thereby reducing rework due to usability issues later in the process.Like the associated Technical Solution Plan, requirements may be allocated to the Information Architecture Plan. The images above show how we might decide to implement the information design for the FUN1 requirement to provide the capability for the learner to respond to character dialogue.
- Now that the hard work of analysis and design have been completed, we are ready to develop and integrate the products. At this point the development team will execute the Technical Solution Plan, Information Architecture Plan and Art Plan to develop game authoring tools, the game engine and art assets. Each component of the game will be reviewed for adherence to the learning objectives and tested for functionality. Three points to cover for this slide:[Early Phase] The text simulation (full script) provides the team the ability to step through the flow and decision points in a simulation prior to an investment in multimedia elements.[Mid Phase] Product assets reinforce the elements of the learning scenario by incorporating realistic, engaging multimedia as well as incorporating guidance tools and supporting materials. Product assets may include characters, props, scenes, reference material, and remedial feedback.[Late Phase] The alpha product represents the opportunity to verify and validate that all components of the product are fully integrated, have been met; and the product contains all technical and functional requirements as designed. The alpha product is carefully reviewed prior to final product development.
- Authoring tools are critical to how project staff test visual assets, debug game code and author learning scenarios. Authoring tools are designed and developed so that they may be reused across future efforts. Game development companies depend upon this capability to reduce future development time and cost associated with building games from scratch with the out-of-the box functionality provided by game engines every time. Typical tools that are developed may include a virtual dressing room, game console, scenario authoring tool.The virtual dressing room tool enables Modelers and Animators to view how their models look and behave inside of the game engine before the actual game has been developed. The game console allows Software Engineers to load and debug configuration settings, event sequences, characters, animation, environments, sounds, video and other components in-game. It also provides access to the game’s application programming interface in order to issue programming commands to the game engine at runtime. Finally, the scenario authoring tool provides the capability for integrators to bring together all game assets and the game script into the production game quickly and easily as opposed to having to integrate them with programming code.
- Commercial game companies have the resources to build or license full-featured game engines that support their core entertainment products. These engines may then be reused for their own serious game projects. Due to the resource constraints of most serious game efforts and as a matter of practicality, serious game focused companies may license and modify these complex systems to support their own serious game development objectives instead of building their own engine from scratch. In this way the needed serious game functionality may be appended to and be abstracted out of the core game engine technology to make development easier. Our approach to game engine development is to buy a license to them so that we may append to them and abstract their functionality for our own purposes. For example, we have purchased an engine that provides, among other capabilities, the built-in capability to easily integrate 3D character movement and walk animations. On top of that capability we appended a waypoint artificial intelligence subsystem that enables the characters to walk from point A to point B while navigating around objects. Then, we may abstract, or hide, the complexity of the waypoint system by only requiring that points A and B be entered into the system for the characters to navigate. This approach helps provide the functionality that the game integrator will need to author the game using the scenario authoring tool.
- Asset development goes on in parallel with authoring tool and game engine development. Assets include the graphics, characters, models, animations, videos, sound and user interfaces required to develop the game. The assets are developed using the design specified in the Art Plan which is based upon the scripts. It is important that artists and modelers have access to game development authoring tools in order to see how their model assets look and behave within the game world. This is where the virtual dressing room tool comes into play. The dressing room provides just enough capability to view charactersand their animations from different angles as they would be viewed in the finished game before the game is finished.
- Integration is the culmination point in which the assets are brought together with the scenario authoring tool by the integrator to build the game as it will be experienced by the learner. It is also the point at which all of the scripts, design and development are put to the test. Often, as the assets are brought together in practice we are able to see for the first time how well things really work together. At this point we move out of formal design and development into bug discovery and fix mode using short tight discovery, design, build and test spirals. It is very helpful at this point to have documented how the scenario authoring tool works and the entire asset inventory so that integration can move forward smoothly. It is also imperative that an asset pipeline be planned and executed at this point. The asset pipeline is the process by which assets move from the artists’ and modelers’ hands into the integrators’ hands and into the game as efficiently as possible. Each pipeline is different based upon the roles, development tools and assets involved in the process. Some developers will develop their own automation tools to help drive the pipeline. In our current project we provide a staging or, sandboxed, version of the game where our modeler can import environment models and character models to build the game levels and verify that the models look and animate correctly. This step helps provide assurance to the integrator that the assets are ready for the next step in the pipeline which is to import the staging version models into the production version of the game using the scenario authoring tool. The Integrator then uses the functionality provided by the authoring tool give life to the models, sequence game events and score learner decisions.
- The most effective instructional tool is the instructor, whether that be in the classroom or through an online collaborative environment. It is imperative that faculty and others responsible for training and/or developing systems are equipped with the necessary skills and tools to enhance learning. Thus, the implementation phase is vital to a game’s success, not only for technical testing but also product training.During this phase we provide electronic copies of all training material and conduct a train-the-trainer session workshop. These workshopsallow for organizations to develop a plan for the integration of gaming and simulation technologies into classroom instruction. This plan will promote collaboration and knowledge development amongst instructors and support staff, as well as ensure additional expertise and support resources during solution implementation.
- Verification testing asks “Has the system been developed according to requirements?”. System verification testing allows Software Engineers to test the discrete functionality of the system using test cases. One or more test cases are developed to test each requirement. Each test case contains prerequisites, actions and outcomes necessary to verify its associated requirement. Requirements traceability is critical to verification testing as we need to be able to trace test cases back to requirements being tested. It is advantageous to stub-out, or create the test case shells during requirements formation as a reminder and as a way to get a jump start on traceability and testing.Let’s create an example test case labeled TST1 to test our example requirement FUN1. The FUN1 requirement stated “The simulation shall provide the capability for the user to respond to character dialogue.” In order to create the prerequisites for this requirement to be tested we know that the system must be started and that the simulation subsystem must be started and so these become prerequisites 1 and 2. In order to know what to do after the prerequisites of the test case have been completed we create actions. In this case the actions are for an NPC to engage the learner’s character in dialogue and for the learner to select a dialogue response. These will become actions 1 and 2. Finally, the expected outcomes of the actions are to have completed making a decision using character dialogue. Notice that much of what had been created in the use case USE1 could be re-leveraged to create this test case. They are similar in form. However, be careful. Use Cases are used to elaborate the game prior to requirements formation. Therefore, they may be out-of-date by the time test cases are written as requirements and design can change.Other forms of verification testing that are useful are code reviews, integration testing and usability testing. All verification activities are defined in a Verification and Validation Plan and in individual test plans that detail the testing environment, staff and processes needed to conduct tests.
- Validation testing asks “Does the game operate as intended in its deployment environment?”. This is an important question to be able to answer as the game is moved from development into the client's location. This is the time when system and interface requirements in particular are put to the test. It is important to mimic, to the extent possible, the client’s location requirements during validation testing to identify any incompatibilities prior to deployment. Depending upon the number and types of machines that the game may run on, this can be a difficult task. Having access to a lab or emulation software to emulate the client’s location is essential to perform the breadth of training that is required. Some games must be certified and accredited to be deployed to government or military networks. This creates a challenge as the secure networks that the game may run on may require security clearances be granted for testing. Furthermore, certification and accreditation standards may require that certain design considerations be made prior to deployment. During validation testing project managers and developers work with the client to test the game at the client’s location. After the test, the client may approve the game or request the changes be made prior to final deployment. All verification activities are defined in a Verification and Validation Plan and in individual test plans that detail the testing environment, staff and processes needed to conduct tests.
- Weunderstand the importance of evaluating the effectiveness and impact of the games we develop; therefore we work closely with our clients to conduct both formative and summative evaluation, as required. Formative evaluation, conducted during the development of the product, will aid in ensuring that the goals of the instruction are being achieved. Summative evaluation efforts are often supported per request and focus on evaluating the learning materials and learning process. After Action Reviews (AARs) that drill down and discuss core feedback, and surveys, on the usability and instructional integrity of the game, are vital to constant verification and validation, and success, of the games we develop.
- Questions from the audience.