Monday, January 19, 2015

A Comic About Grace Hopper

Ramya from Udemy shared a neat little comic with me about Grace Hopper, and said I could share it here.  You can look at the comic on their website, too, where you can also order a Grace Hopper sticker if you live in the US.  Enjoy!





Tuesday, January 13, 2015

How Gameplay Affects Stories in Games

I am very interested in the role of storytelling in videogames.  Although I do like games without stories as well, the story is often the part of a game that engages me the most.  For my thesis proposal, I spent some time thinking about how stories integrate into games, and realized that some of the existing ways to analyze them didn't quite suit my needs.  Below is an excerpt from my proposal discussing a spectrum I came up with instead.

We are interested in the application of interactive storytelling in videogames. In particular, we want to create a more satisfying story experience in open-world adventure and role-playing games. A game that features an open world allows its players to move freely in a large space with few or no artificial barriers, choosing what to do and when. The flexibility of an open world and the fact that adventure and role-playing games tend to have strong story components [1] make these genres an interesting place to explore interactive storytelling techniques.

Combining IS and games introduces a new challenge: a balance must be achieved between creating a satisfying story and maintaining a reasonable level of player control in both the story and gameplay. This is no easy task, as Costikyan points out: “Divergence from a story's path is likely to make for a less satisfying story; restricting a player's freedom of action is likely to make for a less satisfying game” [2]. It also brings an important difference between interactive storytelling and storytelling in games to the forefront. In traditional interactive storytelling, the IS system is primarily responsible for arranging the story being told, making adjustments according to user interactions. When telling interactive stories with games, however, it is the gameplay that drives the story forward and determines how it should unfold. Gameplay is what we call the interaction between players and a game system's rules [3]. Gameplay includes physically moving through an open world's space, fighting enemies, conversing with non-player characters, and collecting items.


Figure 1: Our spectrum of how storytelling integrates with gameplay

Some gameplay actions might allow players to interact with the game's story elements, and others can indirectly affect the direction of the story. Viewed as a spectrum (Figure 1), the least interactive types of game stories come as a result of gameplay not having any effect on the story at all. The most interactive stories are directly affected by gameplay. In the middle, stories are affected by gameplay, but only indirectly. Many authors who wish to create compelling story experiences in games aim to create experiences as far right on the spectrum as possible, but several challenges make this more difficult than it may seem.

 Figure 2: Lebowitz and Klug's storytelling in games spectrum

Lebowitz and Klug [1] also proposed a spectrum to analyze videogame stories (Figure 2). As presented, non-interactive stories are at the far left. The level of control that players have over the story increases to the right of the spectrum. Implicitly, the spectrum also captures how much control an author has over a story, with the largest level of control to the far left. Furthest right, the author has no control at all; games that Lebowitz and Klug call fully player-driven are highly emergent with no set plot.

We are more interested in how directly gameplay affects a story rather than the magnitude of control the player has, partly because gameplay and story often feel like separate activities. Furthermore, most open-world games we are interested in fit into the open-ended story category of Lebowitz and Klug’s spectrum, which they characterize as games that allow players to progress how they wish and that often (but not always) feature open worlds. Some open-world games allow players to explore and complete various tasks without any relation to the story. Others have similar tasks to complete, but doing so will cause the story to change in some way. We want to be able to distinguish games within the open-ended category, and we are able to do so with our spectrum.

In the following, we discuss the types of strategies used to implement game stories across our spectrum and discuss problems that arise for each. We begin at the far left of our spectrum, where gameplay has no effect on story. This does not necessarily mean that the game is not an example of interactive storytelling, as the player may be able to interact with the story in ways that do not change it. The player might choose which parts of the story to consume and when, explore the world the story is set in, or interact with the characters within. Games in the Zelda series, such as The Legend of Zelda: Skyward Sword, feature fixed stories but allow the player to converse with non-player characters and take on missions that have no story consequences. Not allowing gameplay to affect a story results in stronger authorial control over how the story unfolds. However, it also introduces a risk of creating gameplay that does not align well with the narrative being told, especially in games that offer much freedom in terms of how to approach gameplay. A story told about a hero that in gameplay can rob innocent citizens at will leads to ludonarrative dissonance, a term originally coined by Clint Hocking. Red Dead Redemption openly tracks the player's heroism, but it does not matter how heroic the player is deemed to be: non-player characters treat the player character the same way, and the same tasks are required of him. The worst case of a story not affected by gameplay is a “constipated story,” where strictly alternating presentations of gameplay and story fail to interact with each other at all [4].

Stories that are indirectly affected by gameplay lie in the middle of our spectrum. With such games, players do not directly make choices that alter the course of a story. Instead, players interact with the game system, resulting in changes to the game state. How the story is presented or arranged depends on the current game state. For example, a portion of a story might only be available if the player character has enough experience points. Many areas of Fallout 3 were technically available all the time, but the player could only survive long enough to explore them after gaining enough experience points through gameplay elsewhere. Alternatively, the outcome of a plot point might depend on how evil the player acted in previous encounters. In Fable II, the player has opportunities to be good or evil through various tasks. Which approach is chosen unlocks some new tasks, and changes the player character's appearance on screen. Some games with branching stories, including those with multiple endings, are also found near the middle of the spectrum. In BioShock, for example, gameplay actions indirectly cause the story to change. The game ends differently depending on what the player decides to do with certain characters that can either be spared or harvested for player benefit.

The structuralist approach of defining an implicit graph at run-time could be applied here; gameplay statistics can be used in scene preconditions, for example. Although players can only affect the story indirectly, most players will be satisfied. In two surveys of game players, Mallon and Webb [5] discovered that players actually prefer episodic and directed story experiences over unrestricted freedom, and Lebowitz and Klug [1] found that while the majority of players place great importance on a game’s story, they do not require full control over it.

Games with quests commonly feature gameplay that indirectly affects story [1, 6]. A quest system in a game is used to organize what quests are available and when. It will also take care of offering quests to the player, possibly through conversations with non-player characters or markers in the world the player interacts with to trigger a quest. Many games with open-ended stories feature quest systems. Each quest contains a fragmentary story and provides short-term gameplay goals [7, 8]. Story consistency is enhanced by making the quests self-contained and largely independent [8]. As a result, completing a quest reveals a portion of the game's story that the player would not otherwise see, but rarely affects any other part of the story. The only indirect effect of choosing a quest through gameplay is the addition of the non-essential bit of story contained within. The stories revealed in quests would likely be more interesting if they connected better with what happens in the core plot; instead, they often feel like busy work, or little more than a way to improve your character's statistics.

If quests were less task-based and more goal-oriented, they might lie closer to the right of our spectrum where gameplay directly affects story. Quests in videogames tend to focus on tasks such as fetching items or engaging in combat instead of higher-level goals that can be achieved in various ways [7, 9, 10]. Instead of asking players to complete tasks, quests could be used to introduce meaningful conflict between characters that the player must resolve through gameplay, allowing for more direct interaction with the story. Games in the Mass Effect series use quests to introduce conflict between characters. Sullivan's GrailGM framework [10], designed to work with game mechanics based on social moves, also allows for conflict-oriented quests. GrailGM makes quests available based on the current social dynamics between player and non-player characters in the story. Players have the choice to complete the quest as put forth by the quest giver, or to create conflict by going against the quest giver's wishes. If more quests were explicitly connected to the game's main storyline, the gameplay act of choosing a quest could give a stronger sense of affecting the story.

There are games that more clearly lie to the right of our spectrum. Some games make their core mechanic a direct interaction with the story, as in Telltale Games’ The Walking Dead series. In The Walking Dead, players are primarily asked to decide how the main character should respond to various situations. Heavy Rain offers similar gameplay with one interesting difference. When players fail to complete an action move, the game does not ask them to try again. Instead, the following scene or scenes continue, but the exact content is affected by whether the player has failed or succeeded. Sometimes gameplay as simple as which quests the player chooses to embark on can directly impact the story. For example, Fallout: New Vegas tracks statistics about who the player is most loyal to. Which quests the player completes can affect loyalty and, by extension, how certain parts of the story will play out.

A challenge of games whose gameplay directly affects the story is to find ways to allow players to make meaningful dramatic decisions. The Walking Dead is a game that almost entirely consists of what appears to be dramatically significant choices. However, most choices the player makes impact only the next line of dialog, nothing more. While perceived agency can be important [11], it is easy to have the effect wear off when few or none of your choices are dramatically relevant. 

---

[1] J. Lebowitz and C. Klug. Interactive Storytelling for Video Games. Focal Press (2011).

[2] G. Costikyan. Second Person: Role-Playing and Story in Games and Playable Media, chapter Games, Storytelling, and Breaking the String, pages 5 13. MIT Press (2007).

[3] K. Salen and E. Zimmerman. Rules of Play: Game Design Fundamentals. The MIT Press (2003).

[4] C. Crawford. Chris Crawford on Interactive Storytelling. New Riders, 2nd edition (2012).

[5] B. Mallon and B.Webb. Stand up and take your place: identifying narrative elements in narrative adventure and role-play games. Computers in Entertainment (CIE) 3, 1 20 (2005).

[6] J. Howard. Quests: Design, Theory, and History in Games and Narratives. A K Peters, Ltd. (2008).

[7] E. Aarseth. From hunt the wumpus to everquest: Introduction to quest theory. In F. Kishino, Y. Kitamura, H. Kato, and N. Nagata, editors, Entertainment Computing - ICEC 2005, volume 3711 of Lecture Notes in Computer Science, pages 496 -506. Springer Berlin Heidelberg (2005).

[8] M. Trenton, D. Szafron, J. Friesen, and C. Onuczko. Quest patterns for story-based computer games. In Proceedings of the Sixth Arti cial Intelligence and Interactive Digital Entertainment Conference (AIIDE) (2010).

[9] C. Lindley. Developing Interactive Narrative Content: sagas/sagasnet reader, chapter Story and Narrative Structures in Computer Games. High Text Verlag (2005).

[10] A. Sullivan. The Grail Framework: Making Stories Playable on Three Levels in CRPGs. Ph.D. thesis, University of California Santa Cruz (2012).

[11] M. W. Fendt, B. Harrison, S. G. Ware, R. E. Cardona-Rivera, and D. L. Roberts. Achieving the illusion of agency. In D. Oyarzun, F. Peinado, R. Young, A. Elizalde, and G. Méndez, editors, Interactive Storytelling, volume 7648 of Lecture Notes in Computer Science, pages 114 -125. Springer Berlin Heidelberg. (2012).

Friday, January 2, 2015

On Completing a PhD Proposal

In Mid-December, my PhD thesis proposal was accepted, leaving me ABD ("all but dissertation"). It was quite the journey to get there, and I have some hopefully useful insights to share from the experience.


if you've ever wondered... / toby


If you're curious, much of the information about the doctoral proposal for our School is likely widely applicable. We are supposed to finish the proposal within 6 terms of registration, but in reality that's not very common. Many students do their proposal much later in the process, after completing most of the work needed for the thesis. We tried to do my proposal a bit sooner so we could get some solid feedback earlier in the process. I'm really glad we did, but more on that later.

The Document

The first step of the proposal is to write the document. I started working on this during the summer while also developing a prototype game using my interactive storytelling framework, then part-time in the fall when I went back to teaching. However, several iterations were required, the first being on the general structure of the document. This is what we settled on in terms of chapter layout:
  • Introduction
  • Background
  • Project Goals and Design
  • Work Completed
  • Future Work Plan
  • Conclusion

I put most of my effort into the second and third chapters. The background is where you have to not only show that you have a good grasp on what's out there, but also clearly show the gaps you are trying to fill. I used the Project Goals chapter to really spell out what I was trying to accomplish, and describe the storytelling framework we had published at Foundations of Digital Games.

Both of these chapters needed multiple iterations even after I fixed the overall structure of the document. We tried to bring them as close to final thesis-level quality as we could in the time we had, hoping we could reuse a lot of it again later. This is what I spent most of the fall doing.

My process for the background section is interesting to look back on: although I knew from the beginning what the text in that chapter had to accomplish, it still took me three to four iterations to get there. I fixed one problem each iteration. First, I improved the organization of the chapter so each major section had a clear organizing principle. Then I analyzed the literature more critically, then more effectively highlighted the gaps. I reorganized the sections again, and finally added better conclusions to tie up each section. The final product actually ended up being decent!

In some ways I would have liked to spend more time on the document. I noticed a few too many problems when re-reading it a few weeks after giving it to the proposal committee. For example, I cut back my introduction just before submitting, and later I realized just how... bad it was. But, to be honest, the end result — passing the proposal — would not have changed. Sometimes you have to know when to stop, even if that reason is that you simply can't spend any more time on it.

The Oral Examination

Three weeks after submitting the document to the committee, we had our proposal examination. It started with me giving a 15-20 minute talk, followed by two rounds of questions from the committee.

When preparing for the talk, I re-used a technique that helped me with a past conference presentation: I wrote a script to figure out what I wanted to say. After some feedback from my supervisor on that, , I ended up iterating on that, too.  I ended up finishing my slides a little too close to the actual presentation time. I had originally hoped to run through the talk at home at least a few times (once with my husband), as well as take notes about my background section and key project information so I would be really well prepared for questions. I did none of that. Although I still passed, I think those with some more time might really benefit from trying these ideas.

These are the slides from my talk, which give a decent enough idea of how I structured it in the end. As you can see, I centred the organization around the proposed contributions of the thesis.



Because of my lack of planned practice, I ended up being pretty nervous for the talk, and it showed.  Which is a shame, because I'm generally pretty good at presentations and keeping nerves in check.  But I guess it turned out well anyway, since some of the committee understood what I was trying to do better after the presentation.

The question portion of the exam was... interesting.  I feel like I was barely asked any questions at all.  I mostly got feedback about the proposal document (lots of constructive criticism!) and suggestions for where to go from here.  The committee suggested some ways to narrow the scope of our work and suggested ways to avoid having to make an entire game to test our designs.  This was incredibly relieving! Nothing I've done so far has been wasted effort, and future plans now look more achievable somehow.  The plan is to meet back up with the committee in six months to go over an updated plan since things are likely to change enough that we don't yet know what the final thesis will look like.

Based on this outcome, I am very glad we did an "early" proposal.  I highly recommend biting the bullet and proposing your thesis as early as you can.  Your supervisor should know if you've got enough to pass.  Get valuable feedback early and perhaps even save yourself some work, as happened in my case.

Tuesday, December 9, 2014

An Update on Our CS2 Experiment with C++ and Java

Back in September, I reported on an experimental course design I was trying out for our CS2 class.  The main idea was to start with C++ and slowly transition to Java so that we could use the explicit nature of C++ to better understand what Java is doing behind the scenes.  I wondered, will it work? Or will it be a disaster?


Danger, unexploded bomb


Before reading on, you may want to go read about the course design.  In particular, have a look at the progression of topics at the end (my lecture slides are attached as well, if you're interested).

After introducing problem solving strategies that I wanted students to use throughout the course, I started with C++ basics.  I began talking about how simple data appeared in memory.  The next topic, solving problems with arrays, allowed me to build on both the problem solving strategies and the memory model.  Once we introduced classes, I brought Java into the mix.  Then we covered dynamic memory in C++ and compared that with Java's memory model.  We talked about linked lists and a branching story app in Java to get used to programs with more complex reference structures.  At this point, we were able to leave C++ behind and move on to more advanced OOP with Java.  Later I showed them how to use the Processing library in Java to make a program where you could "see" polymorphism at play with various related objects on the screen.  I also showed how to set up a simple model-view-controller design with Processing.  Finally, we covered recursion with a focus on recursive data structures.

In the middle of the term, I conducted an informal, anonymous survey to find out how well the new design was working (or, more accurately, whether doing C++ and Java together was a bad idea).  Although the reviews were mixed, there were definitely more positive responses than I would have guessed.  It was also very interesting to learn that more students found Java more difficult than C++.

When I met with two fellow instructors and one of my TAs to decide whether we would continue this course design next term, we discussed one very promising phenomenon: students were finally asking conceptual questions instead of just syntax.  My TA had worked with this course three times in a row with three different instructors, each with a different approach.  He noted that this was the first time he had heard so many interesting, in-depth questions.  Students were talking about things like the stack and the heap for the first time, for example, even though these topics were technically covered in previous offerings.  Getting students to go beyond syntax has been one of the faculty's major goals for a while now, and it seems that we may have finally figured out how to make that happen.

Ever since the midterm survey, students have been telling me in person and over email how much they appreciate this course design.  Some tell me that they understand Java so much better than they had previously (either from taking this class before, or learning Java elsewhere).  Others tell me they have found the class interesting and useful.  One or two complained about the difficulty, but they seemed to appreciate what we were going for when we discussed it.

Of course, there are a number of students who are struggling.  But it seems these are the students who would be struggling regardless of whether we included C++.  We know this because many of these students are the ones who miss all or most lectures, who don't go to (or work during) tutorials, who don't complete assignments, and who don't come to ask for help.  These students are the ones who would be unlikely to pass even if the course was all Java.

Indeed, ensuring that only those who truly understand the material move on is another goal of the redesign.  We don't want students who have no hope of passing our systems programming class to be able to move on from this course.  An added bonus of including Java has been better assessment tools.  I've been able to ask much more pointed questions about how Java works thanks to the ability to compare to C++.  So those who pass should truly understand what we want them to.

Regardless of those who are struggling, the verdict has been clear: C++ and Java together are definitely not a disaster.  Now we shall see how the next iteration of the design fares next semester when we have quadruple the students taking the course, and even more importantly, when these students move on to second year.

Friday, October 10, 2014

Technology and How It Is Evolving Storytelling in Our Entertainment Experiences / GHC14

What luck! An invited technical speaker at GHC wants to talk about storytelling and games! As Bonnie Ross' abstract states, "stories spill into every aspect and facet of our lives; narrative leaps between nations, and stories span devices, media and demographics. The entertainment industry stands at the crossroads of where those stories intersect, how those stories are told and who tells them."  Here is my summary of Bonnie's talk.


Recent stats: 48% of gamers are women.  But where are we on the creation side? Software is omnipresent, and it's harder to see what you can do when you finish a degree in technology.  Bonnie originally came to gaming because of technology, and wasn't planning on staying more than a year.  But she found a passion.  She hopes some of us will too.

Bonnie showed us a video prologue of the Halo story.  She asks, what tools and technology have enabled us to tell more immersive stories? Games have different genres, and different styles requiring different graphics.  Similarly, games have different needs in terms of storytelling.  Audiences are asked to have some kind of suspension of disbelief when consuming entertainment.

Technology had advanced to support this suspension disbelief in many areas, but one that has helped immensely with Halo is facial motion capture.  Golum was one of the first characters to use this, but now it's in many movies and games.  The technique leads to more believable performances, helps bridge the uncanny valley, and leads to more efficient development.  We get a stronger emotional attachment to the higher fidelity characters.

One funny thing about casting interviews for character actors: they don't tell the interviewees what they are doing, and just ask them to move their faces around in a wide range of emotions.  What they are really looking for is botox, because they need every wrinkle to move for facial motion capture to work.

Bonnie showed us several examples of various stages of animations, and I must say I am flabbergasted.

Fans are also now becoming part of the Halo story.  They've always wanted to be, but it used to be a more physical form (cosplay, for example).  Lost engaged fans through things like ARGs and really invited them into their story.  Is this a good thing? Bonnie says yes.  The more the users feel ownership in your story, the more they will stick with you.  Is there a way to bring the Halo story and the fans' story together into something bigger? Perhaps through ARGs, transmedia initiatives and the like...

Bonnie hopes we all walk away thinking about what new things we can do with technology.  That we see the balance of art and science in games.  That everyone coming out of university realized we all need some kind of technical background.  Now that's a story I can buy into!