Tuesday, January 26, 2016

Spring 2016 Studio: Goals and Early Design

This semester's Spring Game Studio is off to a good start. We are exploring narrative-rich games in collaboration with Connection Corner in Muncie. The first week was primarily an orientation, during which we played Buffalo, Tales of the Arabian Nights, and Two Rooms and a Boom, and I introduced the team to fundamentals of serious game design, including MDA analysis. The team also met Rebecca Parker, our contact at Connection Corner. From these discussions, the team was able to agree on the following primary goals for our work this semester:

  • 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.

Monday, January 18, 2016

Design questions inspired by playing Witcher 3

Last night, I finished playing Witcher 3. I enjoyed it, and I think it offers quite a bit to think about. This morning, I want to share some of the design questions that it made me consider. Many of the formal elements of Witcher 3 are staples for its genre, but as my previous post intimates, I've been thinking more about the concept of genre lately and how it's not well applied in games. My wife described Witcher 3 as "my kind of game," which is traditionally true: I love a good CRPG fantasy simulator. However, I am also approaching this as a father, playing a game whose story is fundamentally about fatherhood—aware that the game that takes an enormous amount of time and attention that could otherwise be spent on actual fatherhood.

Without further ado, then, here are some design questions that came to mind while playing Witcher 3.

What if time-sensitive tasks were actually time-sensitive? It's conventional design in CRPGs to tell the player about some important and imminent event, but then give them a functionally infinite amount of time to proceed with it. There's a monster killing everything in the swamp, your daughter is being chased by the Wild Hunt, there's a guy waiting for you at dusk by the docks... but you can faff about for days and there's no in-game impact. The reason for this is really that the rest of the systems are not tuned to time being an important part of the system.

What if crafting took time? As long as I have a diagram, any talented smith can do any number of complex operations instantaneously. That is convenient because the game preferences incremental numeric increases over story. What if that was inverted?

What if gear were not limited by level? Geralt is a mutated fighting machine, a master of swords and violence, yet more than once, I found a club that he couldn't figure out how to swing at enemies until he gained levels.

What if herb-collecting were not a drudgery? For example, what if you could mark patches of different herbs and then, like fast-travel, do a fast-collect operation? Or what if you could hire a local kid to go do it for you for a gold coin or two? Making it a manual process is like eliminating fast-travel: it just fritters away player time without contributing to other goals.

What if you felt heroic from the start? Geralt was a veteran witcher before the series even started, yet common wolves posed a serious threat at the start of the game. The idea that players and monsters have levels, and player levels escalate, is a trope of CRPG design: what if we got rid of it?

What if you had a reasonably limited inventory? I was carrying a veritable armory for most of the game. Lax realism of inventory is a prerequisite to avoid frustration when the game privileges stats and stuff-collection over story. What if that wasn't the case?

For a game with such an impressive and thoughtful story, the design actually privileges loot-hunting stat-boosting over story every time. I suspect that if you start breaking these constraints, you would very quickly fall out of the conventional Fantasy CRPG space—but really, I am tired of that game. Couldn't we have an even better Witcher experience if they allowed the story to define the gameplay experience, rather than inhibit the story by tropes of Fantasy CRPG design?

I heard a designer from Bethesda talk about the Elder Scrolls series at a conference a few years ago, and the question came up about how little design or story innovation there was across the series: each one is fundamentally the same, a child-of-prophecy story. The answer was economic: these games have enormous budgets, and there's always a new generation of 14-year-olds for whom [Daggerfall/Morrowind/Oblivion/Skyrim] is their first Fantasy CRPG epic, and so they keep the formula the same. (It helps that nostalgic older gamers will pay for the new installment and memories of that first time as well.) Witcher probably falls into this morass as well: to craft such a beautiful and engaging world takes millions of dollars, and they don't want to risk alienating an audience.

I believe that there is plenty of room for innovation in game design, but after playing Witcher 3 and Dragon Age: Inquisition in the last nine months—and never having finished Skyrim out of boredom a few years ago—I am tired of the tropes. Although I enjoyed playing Witcher 3, I feel like its story was made the worse for the conflict between the narrative and the formal systems.

Sunday, January 3, 2016

Characterizing a genre

The Spring semester starts in about a week, and with it, my most recent immersive learning project. Ball State's immersive learning program has allowed me to offer several Spring Game Development Studio experiences, but this Spring the project is a little different. The following video describes my motivation for the project:

In the video, I describe Tales of the Arabian Nights and Agents of SMERSH as "narrative-rich games," but the term is not rigorously defined—and I'm not sure it's the best choice of terms either. It was what I came up with last summer, when I originally gave that presentation at THATCamp Indiana 2015. As I began working on a formal course plan for the Spring, I realized I needed to more rigirously define this genre. This will help us to focus our efforts as well as communicate our findings.

I have identified the following necessary characteristics:
  1. Take place in a believable fictional setting. The world of Tales of the Arabian Nights may be unfamiliar to the player, but everything in it is representative of the source material, even if there are contradictions. Agents of SMERSH is similar with its cold war secret agent theme.
  2. Use narrative as the primary feedback mechanism. Raph Koster wrote about how narrative is a feedback mechanism in game design. In Tales of the Arabian Nights, player's reaction choice has two forms of feedback: first, the narrative that describes the outcome, and then any changes to the player's game state (story or destiny points, location, status, wealth level, and treasures). Tales gives the narrative first, and the state change is secondary to it.
  3. Have measurable goals. That is, there is a winning condition: this is a game after all and not just cooperative storytelling. 
  4. Incorporate endogenously meaningful ambiguous decision-making. Along with the previous point, I am borrowing from Keith Burgun's philosophy of games, and his taxonomy of interactive forms in particular. The player in these games must make decisions that are important but without total knowledge, and these decisions have an effect on the game world. To me, one of the most bizarre properties of Tales is how little agency a player really has: decisions are made on very little information, but these decisions are critical to the player's success. This leads to the next characteristic:
  5. Reward players for decision-making that reflects cultural understanding. The knowledge that a player brings to bear on decisions is not just knowledge of in-game systems. If you are playing Tales and you face an Angry Ifrit, and you don't have the Combat skill, and you choose to Fight, it is probably not going to end well. This prediction is not based on my having memorized the Book of Tales, nor knowing how many hit dice an Ifrit has. Rather, I am drawing upon my understanding of Anger, Spirits, Fighting, and probably more. I would like to add that I don't mean the game should set up "right" and "wrong" answers to problems, and there should be unexpected twists, but by and large, the story remains logically consistent—or as logically consistent as you can be when you are allowed to respond to a sudden squall with the "Drink" or "Enter" option. 
There are some characteristics which I have not yet determined to be necessary, beneficial, or merely accidental. Principle among these is whether the game needs to involve multiple players. My inspiration for this project comes from multiplayer games, but perhaps the goals of the project could also be met in a single-player experience. This is an important consideration since building digital prototypes of single-player experiences is generally much easier than supporting multiple players. A few potentially important characteristics follow from the adoption of a multiplayer requirement:
  1. Take place in an explicit, represented virtual space. In both Tales and SMERSH, the fact that the game takes place in space is critical to the gameplay. Originally, I thought this was a necessary characteristic, but consider the Choose Your Own Adventure style of single-player experience. These take place in an implicit viritual space, expressed only in text, yet a player may feel immersed in the environment without maps or tokens. If there are multiple players, an explicit virtual space makes it easier to see (and believe?) that each character is on their own journey, in a way that is unnecessary for single-player experiences. Note that text adventure games have an explicit virtual space, although it may be obfuscated through the user-interface, and we see in classical MUDs that this space was critical for maintaining a sense of space to players.
  2. Players orate narration to each other. Having players read narrative to each other is, in part, a game design trick to keep players involved while it is not their turn, but I think it has a deeper significance here. Oral storytelling is an ancient tradition, and my understanding of the literature (although it's outside my area) is that hearing stories leads to different comprehension than reading stories. Having players read the tales to each other feels practomimetic, subtly turning the players into bards and elders, changing the social and power dynamics. However, I also know of games of Tales of the Arabian Nights being ruined by having low-literacy players—players with poor vocabulary skills who read the narrative poorly or incorrectly, impeding the listeners' understanding of the story.
Taken together, I think we can agree that "narrative-rich game" is not a very expressive moniker for this genre. I am open to suggestions for a new name, and perhaps I will give this as a challenge to the team in the Spring. In any case, these are the characteristics I have identified so far, to set some boundaries around the kind of games we will be investigating in the Spring. I am looking forward to this project, although I admit I am not entirely sure how this will all play out. There are a lot of unknowns, but that's always the case with a research project. Regardless of what we find and how it turns out, I am sure the team and I will have a great learning experience, if nothing else.