While the initial creation of these games was difficult, we were lucky to forgo significant revisions in our second round of prototyping. During our recovery from the initial struggles of conceptual development, I learned a valuable lesson about teamwork. But first, let me describe what went wrong.
Face Finder had a complicated design that was difficult for the student designer to keep track of. Consequently, errors were made during data collection. According to our original design, players were supposed to use clue cards, face cards, and character cards to guess the identity of five characters in a murder mystery. Guessing was supposed to take place during each round of play, and players could update their current guess using cards that already lay on the table. However, the student experimenter only allowed students to guess the identity of one of the five characters at a time. Subsequently, players received very specific feedback that enabled them to correctly guess the hidden characters after only a few rounds of play. The specificity of the feedback did not leave much room for an ethnic bias to emerge. Fortunately, we found a solution to this problem, which I will describe in the final post about this game.
For Teen Angst, the initial delays associated with finding a topic and designing the game left very little time to actually make the game. The student created content that was appropriate, but it took her a long time to format her questions and put them into PowerPoint slides. She pulled at least one all-nighter to my knowledge. Game design always takes twice as long as you think even if you take this rule into account. Students will always fail to appreciate this statement, even if it’s scrawled on the chalkboard in blood. Because the student was rushing to finish her game, critical errors were made during data collection. We had no time for playtesting, and data collection was conducted using the first playable version of the game. There were serious omissions on the data sheet used to collect player responses. These omissions made it difficult to determine how player responses corresponded to the questions in the game. Again, we got lucky and found a solution to this problem that allowed us to analyze the data. You might think all these problems could have been avoided if the student was working harder or if I pushed her more. However, she was working to the best of her ability, and I was constantly urging her forward. So, what went wrong?
In this case, it was a mistake to resist the natural flow of energy in the room. These two students were friends, and they were constantly interacting with each other during the development process. Rather than separating them in an authoritarian attempt to control the situation, it would have been a better to let the students to work together on one project. I predict that they would have had more fun, the project wouldn’t have been delayed, and fewer errors would have been made.
In the past, I’ve had success when everyone in the lab works on the same project. The quality of the final product was better, but some of the students didn’t participate as much as they could have. Furthermore, there are always students who are happy to reside in the background and let others take the lead. This time, I assigned students to individual projects to help them reach their maximum potential. I hoped that each student would contribute to every project in the lab during the group brainstorming sessions, and I hoped each student would learn independence by managing their own project. Unfortunately, the students ended up focusing too much on their own projects and collaboration was limited. As a result, errors were made because there was no quality control built into the design process. In a typical lab, there is a chain of command that insures quality control. Principal Investigators manage postdoctoral fellows, postdoctoral fellows manage graduate students, and graduate students manage undergrads. However, when a PI is managing a group of undergrads, gaps in the normal chain of command result in too many details for the PI to keep track of. I now believe that pairing students up on a project is a good idea to minimize errors, build camaraderie, and help students achieve milestones during development.
