Promote Desired Learning Opportunities Through Introduction of Key Obstacles, Problems, and Plot Elements within the Game and the Implementation

What Happened?

Apart from the game‟s primary structure and rule-base, concepts were introduced through available game actions, obstacles and challenges within the game, and random impacts built into the game. After deciding on the goal of the game and what variables would determine how well players were able to reach that goal, the researcher designed what actions would be available to the players, again based on his own knowledge of the

OOSAD process which composed the topic of the game. These actions were largely taken directly from the UML OOSAD methodology taught in the class. For example, player actions included the building and revising of the exact design models taught in class. Other actions also arose from the researcher‟s knowledge of what a systems analyst‟s responsibilities are on a real SAD project. These included such actions as talking to stakeholders, testing the system, and communicating with other members of the development team. Again, as recommended by the GATE method, these actions were uncovered by looking at what actions an analyst takes in a real SAD project.

The researcher also wanted to identify additional challenges to the players and again looked to real-world SAD processes to identify these. Design and development is a dynamic process and therefore, no matter how much care is taken, unpredictable things occur which can sabotage a project. Looking at these ideas as well as the learning goals of the game, the researcher was able to identify random impacts that could further embed important concepts in the game, and related actions the players could take to address these occurrences.

A goal of this game was to help students to understand what an analyst does as well as what skills are important to pursue a career as an analyst. These include strong communication, technical, and teamwork skills. These concepts are reflected by negative random impacts that can occur if the player does not have the foresight to strengthen each of these areas by using the appropriate action. This can be further described by looking at the random impacts in the game (see Appendix C).

Random impacts are used in the game to both add variability and increase the value of replaying the game, as well as to reinforce additional concepts, such as the importance of various skills to a systems analyst, as well as the unpredictable nature of real world development (see Appendix C). These impacts are meant to add to the game‟s fun and unpredictable nature and make each replay different than the previous while also reinforcing additional concepts covered in class.

What Did and Did Not Go Well?

Again, by following the GATE theory‟s recommendations to base this sub- method‟s process on capturing realism and embedding the desired learning goals, the process of designing player actions, random impacts and obstacles in the game went smoothly.

The previous section noted the largely positive student perspective on the game‟s realism. There were some issues with the random events that occurred in the game and made some students question how realistic the random events were. One student noted his frustration with having repeated team members get sick during one of the times he played the game: “If people were getting sick that much in a company I was working for I would leave them” (Student 5, reflection assignment).

While experiences like this were frustrating, other students highlighted the random events as reflecting the unpredictable nature of real world development: “[In the real world] you have to plan ahead to deal with unexpected things like [a] sick team member or waiting [for] confirmation from the boss” (Student 1, reflection assignment). Tentative Recommendations

Student comments about receiving an inordinate number of the same random event even after taking actions to lower the chance of that chance are corroborated not only by video of student gameplay but also by the researcher‟s own experience playing the game. For example, one student had two team arguments occur after having two team meetings which have the impact of reducing the chance of arguments occuring (Student 14, game play chart).

This issue was brought up with the developer multiple times, and the researcher was repeatedly assured that the function was operating correctly, and it was just by chance that the random events would occur again. However, this highlights the problem that the researcher had to rely on the developer as he could not decode the game‟s code by himself. A similar issue was solved by the researcher having the developer create an output screen that showed the current value of the game‟s primary scoring variable. By examining this, the researcher was able to identify where calculations were going wrong within the game‟s scoring structure and have those corrected.

It is recommended that a game‟s structure be made as transparent as possible during development so that the designed rule structures can be verified and accurately tested. Furthermore, the frustration of some students with the random occurrences highlights the importance of ensuring that the obstacles and problems introduced in the game fit naturally within the context and are tied to promoting learning opportunities through the game. For example, in this case, most of the random events were tied to specific game concepts; however, team members getting sick, while trying to accurately reflect life, created frustration for at least one student as the event is not tied to any action or SAD related concept.

1.6 Design Specific Implementation Guidelines and Artifacts, including External