- Create a game that promotes cultural literacy
- Incorporate narrative as the driving factor in gameplay
- Include a technology component (digital or hybrid game design)
Articulating and building consensus around the goals went much easier than I expected. I asked them to reflect on the conversations of the first week and to write out all the various goals and constraints we could adopt, and to prioritize these. In a team meeting, I asked them to read out their highest-priority goals, and I put these on sticky notes and posted them to the board. Then, I left the room and asked them to sort the sticky notes. I came back after a few minutes, and they had actually completed the exercise quite well, identifying high, medium, and low priorities, and starring the three aforementioned goals as being the most important.
 |
| Result of the team's deliberations on design goals |
Our next step was to settle on fundamental game design ideas. I introduced the team to Tim Ryan's format for concept documents, which I like for several reasons. I invited the team to consider contributing in any one of the following ways before our next meeting:
- Identify game design elements that support our shared goals
- Write a game concept document
- Identify and justify a context for exploring cultural literacy, such that it could be taken as the theme of our game
- Create a poster that articulates clearly our three main goals for the project this semester
- Bring donuts
Sadly, no one brought donuts. I dug up two concept documents from my cybersecurity education game project (which, perhaps, I still have not blogged about) and posted those as examples. I then wrote up two concept documents to frame my own thoughts about the project. Only one other student created a concept document by the imposed deadline. A lot of the discussion centered on the ideas I had brought. I felt a little self-conscious about it, as I did not want to force my designs on them, but one student even said explicitly, "I think we should just go with Dr. G's design" (which, from the conversation, I inferred to mean "because he has already done the most thinking about this and has the most experience.")
We were then able to have a focused discussion about the game's theme. Several were proposed, but again the team quickly came to consensus: we will be using monsters from different cultures as a theme for the game. We had talked about how Tales of the Arabian Nights is successful in part because it is a big game about one culture, and that it may be too ambitious to expect similar results from a shorter game about world cultures. Theming around monsters allows to ask interesting questions, such as "How does culture inform what is considered monstrous?" Our background work and discussion leads us to believe that this theme will be attractive to our target audience, which is roughly 10-12 year-olds—a challenging group to engage with narrative-heavy games, and all the more reason to pick a theme that should excite them!
The team was once again challenged to approach the game design via concept documents, and I wrote up two myself—variations on the original two, based explicitly on monsters, and incorporating some further thoughts about the design space. This time, no one else brought any concept documents, but one student explained that one of my designs already captured his ideas. This is reasonable, since my own designs, and much of our discourse, has been inspired by Tales of the Arabian Nights.
I have been using Scrum for years now, but several forces have led me to seek out alternatives. After watching Allen Holub's DevWeek Keynote on #NoEstimates, I was inspired to try story mapping. Yesterday, with our concept laid out, we tried creating a story map, but it felt rather awkward. I think the main problem was that we still did not have the game design ideas well articulated: the concept document was necessarily brief on details. I told the students that I would start a game design log to help express the game design reflected in the selected concept document. As I re-read Daniel Cook's essay on game design logs, I was reminded that the game is the primary artifact, and that all design documentation is secondary—and so one should aim for building a minimal working prototype as quickly as possible. This inspired me to take on some creative and managerial challenges today: I spent about three hours this morning laying out the core game design in a design log, and later today, I am going to revise our draft story map into one that is aimed at an aggressive schedule of building a minimum viable product.
 |
| First attempt at a story map |
Incidentally, I didn't realize until after the meeting how very confusing this was to the non-CS people in the room. The CS majors and minors have all had CS222 with me, and so they are intimately familiar with the concept of "user stories," but I fear I did not frame this well enough for the others. One of them pointed out his confusion after the fact: how could one not be confused when we're making a story-based game and also talking about the stories of users?
This post started as a simple post to Facebook, something along the lines of "I am grateful for the creative freedom I have in my job, as I spent the last three hours working on a game design specification." I did not post that, however, because that's only part of the story. Sometimes I regret not blogging more of the mundane details about my teaching experiences, since the overall result is emergent from these moment-to-moment decisions. Hence, this post, which I hope you enjoyed reading, and maybe you have something to contribute in the comments, but if nothing else, it's something that Future Me can read to remember how we got to wherever we end up.
No comments:
Post a Comment