GHC17 / Teaching Literature with Interactivity

Any time I go to a conference and see the word 'learning' in a session title, I get excited. Even better when games are involved. So I was already positioned to enjoy Elizabeth Hunter's talk on teaching literature with interactivity. Bonus that she herself is getting a PhD in theatre and knows how to present!

Elizabeth told us about her interesting game project called Something Wicked. The project aims to answer the question of whether playing a true-to-the-text video game adaptation of a famous work of literature help people better understand the work.

In the demo version of the game, the player participates in a battle with the king of Norway. In the book, the battle is described for 70 lines by a bloody military man, but you don't get to see it; it's not engaging for modern students. But you need to understand the nuances in the monologue or else you don't really understand the play.

Elizabeth previously found in her research that taking Shakespeare into unusual settings, using the full environment, helped people enjoy it more. They felt inside the story, and they cared more, which allowed them to think more deeply about the text.

While live theatre does not scale, video games do. It's worth noting that video games are not a replacement of live theatre. However, we can use games to capture some of the benefits we get from live theatre, like boosting affinity, critical thinking, and comprehension. Unfortunately, a lot of literature video games are nothing more than a jazzed-up book, a little too true to text rather than just inspired by a work of literature.

Something Wicked was built according to the rules governed by the world in the book. The game mechanics reward making decisions that Macbeth would have made, rather than "playing well." If you don't play violently enough you have to start again. You have to behave with bloodlust and sneakiness.

So far the game seems to be succeeding in its goals. One cool thing, for example, is that older players end up being excited to analyze Shakespeare's text to figure out why the game was designed the way it was (and even to argue about those decisions).

Learn more about Something Wicked and sign up to playtest on the project's website.

GHC16 / Lyndsay Pearson on Valuing Inclusive Game Design

Invited technical speaker Lyndsay Pearson spoke at Grace Hopper this week about inclusive game design. Lyndsay has, as she puts it, grown up with The Sims, having working on the game in various capacities since nearly the beginning of the franchise. She shared some universally applicable advice on inclusive game design while sharing examples from The Sims.

By Dinosaur918 (Own work)

[CC BY-SA 4.0], via Wikimedia Commons

The first lesson, of course, is that the players are out there. Long gone are the days of believing all players are high-volume males in their late twenties whose central hobby is gaming. With such a huge diversity in players, there's an opportunity to develop games for even more inclusive audiences. To do that, we need to expand beyond the current factors most values in games: time, money, and number of games played.

So what can we do? Respect all players, invite different opinions, and intentionally build relatable experiences.

Respect All Players

Respecting players means truly recognizing them and their diversity. Coming to a game for a different reason that "most" gamers doesn't make you less valuable. Designers should ask themselves: how can I continue to connect with that player and relate to them? First impressions matter, which is why The Sims offered more options for body type and so on in their character creation.

Invite Different Opinions

The thing is that you have to do this even when it's uncomfortable. "We need to help bring people in and help them not bounce out," as Lyndsay puts it.

One example of this is ensuring you tune yourself to cultural sensitivity. For example, the Sims team learned that women were not allowed on game boxes in Saudi Arabia. Despite the fact they really didn't want to, they created a box with all men so that the game could be sold, and still be accessible in all the same ways to people in that country (especially women!).

Another example is religious sensitivity. They thought The Sims was good at avoiding overtly religious objects, but they later realized that the ghosts and voodoo dolls they included in the game also have religious origins. Thus, they realized were actually consistently inconsistent in this area. They had to own the fact they had no clean line and try to make decisions as consciously as possible.

The bottom line is that you need to get uncomfortable with these kinds of conversations. Do know that you get better at it the more you do it, though.

Build Relatable Experiences

Connect, relate, and interact with current world experiences. What's going on in the world that can be incorporated into the game? A nice example is finally incorporating women's team into the FIFA game. When they decided to do that, they became fully invested, considering all kinds of new possibilities, like a player leaving partway through a season to have a baby. The Sims also now has much more fluidity in its gender selection, helping break gender norms as we are trying to do in real life.

---

Lyndsay gave us a lot to think about when it comes to designing inclusive games, but as she pointed out, the lessons apply to all software design. Let's all make sure to keep these things in mind in our own endeavours.

Connections: Learning Science, Games, and Apprenticeships

I'm working on an education project that isn't ready to announce yet. In so doing, I've been taking another look at learning theory, game-like learning, and apprenticeships. Unsurprisingly, there are many connected ideas.

Close connection / Daniela Hartmann

There's a great book called How People Learn: Brain, Mind, Experience, and School that you can read for free online. The introductory chapter aims to separate speculation from science, summarizing some of the key concepts and practices covered in the rest of the book. Part of this is a research-based list of attributes that good learning environments ought to have:

1. "Schools and classrooms must be learner centered." Consider cultural differences between students, and foster a growth mindset over a fixed mindset.
     
2. "To provide a knowledge-centered classroom environment, attention must be given to what is taught (information, subject matter), why it is taught (understanding), and what competence or mastery looks like." Avoid presenting a large number of disconnected facts, and don't design tests that favour memorization instead of understanding. Doing with understanding is more important than just hands-on doing.
     
3. "Formative assessments—ongoing assessments designed to make students’ thinking visible to both teachers and students—are essential." Use formative assessments to allow students to experiment with and revise their understanding and track their progress.
     
4. "Learning is influenced in fundamental ways by the context in which it takes place." Make the norm of your learning environment one that encourages risk-taking, mistakes, feedback, and revision.

Meanwhile, one of my favourite examples of game-like learning (that is, applying what we know about learning in good games to more traditional forms of education) is NYC public school (grades 6-12) Quest to Learn. Seven principles of learning are outlined in the Q School Design Pack, directly quoted below:

1. It kind of feels like play: Learning experiences are engaging, learner-centered, and organized to support inquiry and creativity.
     
2. Everyone is a participant: A shared culture and practice exists where everyone contributes, which may mean that different students contribute different types of expertise.
     
3. Failure is reframed as iteration: Opportunities exist for students and teachers to learn through failure. All learning experiences should embrace a process of testing and iteration.
     
4. Everything is interconnected: Students can share their work, skill, and knowledge with others across networks, groups, and communities.
     
5. Feedback is immediate and ongoing: Students receive ongoing feedback on their progress against learning and assessment goals.
     
6. Challenge is constant: A “need to know” challenges students to solve a problem whose resources have been placed just out of reach.
     
7. Learning happens by doing: Learning is active and experiential. Students learn by proposing, testing, playing with, and validating theories about the world.

I'm sure you are already seeing the connections. For example, the learner-centred theme appears in both lists, formative assessments to revise thinking is similar to failure reframed as iteration, and context and practical experience are important throughout. Of course, this is no accident: The Institute of Play, the organization behind Quest to Learn and similar schools, have done a lot of careful research into both learning and games. Even without the more obvious game-based approach of Quest to Learn, game-like learning principles are useful to apply to any educational initiative.

Finally, I have also been learning more about apprenticeships, particularly for software developers.  In the introduction of another freely available book, Apprenticeship Patterns, software craftsmanship is defined as a community of practice with a common set of underlying values. Many of the values listed tie again to the ideas described above. For example:

• “An attachment to Carol Dweck’s research, which calls for a ‘growth mindset.’” How People Learn calls for a community in which the growth mindset is the norm.  Failure as iteration shows students that they don't need to 'get it' the first time, but instead work toward mastery.
    
• "A need to always be adapting and changing based on the feedback you get from the world around you." Formative assessment provides opportunity to react to feedback, and in game-like settings feedback is always coming your way.
      
• "A belief that it is better to share what we know than to create scarcity by hoarding it." Game-like learning encourages sharing knowledge broadly.
    
• "A willingness to experiment and be proven wrong." Again related to failure as iteration.
    
• "A strong preference for what Etienne Wenger calls ‘situated learning.’" Communities of practice are one part of Wenger's situated learning theory, which relates to the idea of learning in context and learning by doing.

I'll be delving deeper into a lot of these ideas and seeing how they will apply to the project I'm working on. Perhaps the perspective from the three different angles presented above will help you in your own projects, as well.

Creating a Sense of Coherence in Open-World Adventure and Role-Playing Game Stories

The following is my most recent explanation of my thesis project.

We are interested in the application of interactive storytelling to videogames.  We want to improve story experiences 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 make these genres an interesting place to explore interactive storytelling techniques.

Our central goal is to support the creation of open-world videogame stories that give players a sense of coherence.  To achieve this, we take a structuralist approach and partition stories into two types of scenes inspired by the concept of kernels and satellites.  First, a minimal set of fixed scenes form a core story with strong authorial control.  A game’s most central plot points become fixed scenes, thus acting like kernels.  The rest of the story emerges from a much larger collection of flexible scenes that can appear just about anywhere in story save a small set of preconditions.  Most flexible scenes act like satellites: minor plot points, or opportunities to develop story elements like theme.

We want to give players the freedom to explore flexible scenes however they wish as they move through the fixed scenes as designed.  A certain level of coherence is guaranteed when the content of the fixed scenes is itself coherent, but a story with few satellite scenes will have minimal aesthetic appeal.  The challenge, then, is to maintain coherence no matter how a very large set of flexible scenes is experienced.

Instead of arranging flexible scenes according to a strict definition of causal coherence, we want to create a “sense of” coherence.  By this we mean that not all events have to be causally related in explicitly obvious ways, but that players should have the sense that they could figure out the meaning of and relationships between events if they thought hard enough about it.

One of the major ways we achieve a sense of coherence is by managing the story’s progression.  We keep track of when certain story elements, such as theme and character, are reflected.  We then prioritize which scenes should be made available to players next according to a desired distribution of the story elements.  For example, if a particular theme was developed very recently, we want to prioritize scenes that reflect some of the other themes.  On the other hand, if it has been a long time since a theme was developed, scenes that reflect that theme strongly should have high priority.  A good distribution of elements ensures that story elements don’t feel out of place when developed, and that reminders of previous scenes are made throughout the story.

Another facet of creating a sense of coherence is the emergence of structure at run-time through the use of conditions.  Instead of defining causal relationships in a scene graph a priori, we allow authors to define prerequisites for their scenes.  Using prerequisites is a common technique, but in our design we push for prerequisites based on story state values in addition to game state.  For example, scenes might have prerequisites that only allow them to be seen once a particular theme has been developed sufficiently.  Alternatively, a scene might be best suited for the early development of the theme, and should not appear later on.  We want authors to think about flexible scenes in terms of how they function in a story’s development without having to worry about how they will fit within a series of causally related events.

In addition to controlling the path players take through a set of fixed and flexible scenes, we can improve the sense of coherence by adjusting the content of scenes.  In so doing, we want to give players interpretative agency: they should feel like there are deeper layers in the story not being explicitly told, and they should feel like they can interpret those layers in a reasonable way.

We are exploring three ways of dynamically affecting the content of scenes.  In the first, run-time criteria is used to choose a set of scenes that a recurring motif (say, an apple) can be featured in.  Observant players will begin to notice the motif over time and assign meaning to why it appears in certain scenes.  Eventually, they will expect something in particular to happen when a new scene with the motif begins.

Second, mix-ins give us pre-scripted opportunities to make connections to scenes the player happens to have already seen.  As Keith Johnstone points out in the context of improvisation, “feeding something back in from earlier in the story adds ‘point’ and creates structure.”  Characters, story elements, and dialog are all examples of source material that could be referred to in future mix-ins.

Finally, we can adjust the presentation of a scene to alter the player’s interpretation of otherwise unchanging events.  Choice of lighting, background music, camera angles, and even the weather can all depend on the story’s state at the time a particular scene is reached.  Perhaps the heroine of the story returns to the castle with the head of a dragon.  The mood evoked during the scene might be bright and cheerful if the player saw the dragon as an evil menace.  However, the mood might be more sombre if the player found out that the dragon was simply a loving mother trying to protect her hatchlings.  The final event stays the same, but the interpretation of it changes.

In summary, our goal is to give players a sense of coherence when exploring stories in open-world adventure and role-playing games.  We structure our stories as a set of fixed and flexible scenes.  Players can traverse the set of flexible scenes freely, barring any prerequisites that deem certain scenes inaccessible.  Flexible scenes are prioritized so that story elements are well distributed throughout the story.  We encourage interpretative agency by dynamically introducing recurring motifs, using mix-ins to make connections to earlier points in the story, and modifying the presentation of a scene to affect interpretation.  Through all of this, higher quality open-world stories will emerge while still maintaining a satisfactory level of interactivity.

Keynotes and Inspirations at Foundations of Digital Games 2015

I had a great time at this year's Foundations of Digital Games, but it was the talks and the hallway track with narrative folks that really left me inspired.  In this post I'll summarize the first three keynotes and some inspiration I got from one of them; you can check out my raw talk notes and the proceedings for more details.  The sketch notes I'm including are all by Chris Martens, a fellow narrative PhD candidate (though she'll be done soon!).

Tom Forsyth's Keynote

The first keynote of the conference was given by Tom Forsyth, who worked at Valve and then Oculus VR.  Tom highlighted some of the challenges we face when designing all-new experiences for virtual reality.  For example, motion sickness comes from there being an imbalance between what your eyes see and what your ears feel, so having players move up stairs causes issues (elevators are apparently much better).  It's also important to avoid most cinematography techniques, and to use an eye blink transition whenever possible.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

Robin Hunicke's Keynote

The next day we heard from Robin Hunicke, who produced Journey and is seriously inspirational.  She began by talking about Wattam and its designer Keita's inspiration for the game.  The zaniness levels of that game are right up my alley, making me want to get a PS4 even more...

Most of Robin's talk was about her inspiration for Luna, which as she puts it, was kind of a beast.  She talked in depth about the inspiration noted on the game's website: "origami, shadow boxes, abstract sculpture and minimalist illustration."  Near the beginning of the design process, she apparently spent six months alone in her apartment, folding paper.  It turned out that folding paper digitally wasn't very fun, but that didn't mean some of the lessons learned from origami couldn't apply to a game's design.  Luna looks wonderfully whimsical, and I am hoping I was mistaken about it being a VR game (or at least, not VR-exclusive) because I would really like to try it.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

R. Michael Young's Keynote

The first academic keynote of the conference, R. Michael Young is in charge of the Liquid Narrative Group at NCSU.  He described some of the main areas his group looks at in the world of narrative after reminding us that "narrative is big. Really big."

The systems his group builds are evaluated based on whether they produce narratives that can be understood by humans in particular ways.  They break narrative down into story (everything that happens inside the story world), discourse (the choices the author makes in how to tell the stories; what goes into the telling), and interactivity (what happens when a player goes into the role of a character? How do we design the story and discourse?).

The group's most used tool seems to be artificial-intelligence-based planners.  Planning looks at how to automatically sequence actions in the face of a novel set of environmental goals.  In narrative, this might mean anything from having characters scheme to achieve their own goals, to authors planning to mislead then reveal.  Stories are broken down into the smallest possible units (such as individual actions), then built back up.  Many problems arise from the use of standard planners, which often tell uninteresting stories.  One of the ways to improve the outcomes is the group's current work in progress that attempts to express character traits through the action sequences created.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

Inspiration

Michael's distinction between story and discourse got me thinking about my own thesis project (read a somewhat out-of-date description here).  I realized that a large part of what I'm doing feels more like discourse than story.

It felt even more clear to me when I thought about Mieke Bal's definitions of story and fabula from Narratology: Introduction to the Theory of Narrative.  A fabula is "a series of logically and chronologically related events that are caused or experienced by actors" while a story is "a fabula that is presented in a certain manner."  Most of the techniques I am working on actually don't affect the fabula so much as the way the fabula is experienced.

One of the areas I struggled with in my thesis proposal was justifying why I didn't want to use planners.  There are some definite reasons that were easy to articulate, such as difficult authoring.  However, I also had this unarticulated understanding that planners weren't quite right for the design approach I took, but wasn't sure exactly why.

By thinking about story and fabula, I was able to realize that I'm not trying to arrange actions into a story so much as allow navigation through a set of coarser story pieces featuring fixed actions.  I want players to be able to explore a mostly fixed fabula in different ways, leading to different interpretations of it.  In the process, the resulting story should still have a sense of (but not necessarily actual) coherence.

As a result of this insight and another cool idea that came up during the conference, my thesis project's focus is tightening up very nicely.  I'll share more about that sometime in the future.

My Experience at Foundations of Digital Games 2015

During the last full week of June, I took a wonderful trip to Pacific Grove, California for Foundations of Digital Games 2015.  (You might recall that last year's conference was on a cruise ship.)  I didn't end up presenting anything this year, and I'm so glad I went despite this.  I found the whole experience rather invigorating.

Before continuing, be sure to note that I've posted publicly accessible notes for most keynotes and a selection of paper sessions.  The proceedings are also available.  I'll talk more about the academic content of the conference in another post.

This year's conference was held at Asilomar Conference Grounds, which began life as a YWCA summer camp for girls about 100 years ago.  It is part of Asilomar State Beach, which is, unsurprisingly, gorgeous.

Our keynotes and some of the parallel track sessions were held in the site's chapel.  Not the greatest for lighting (and, to an extent, sound), but a really neat building in terms of its architecture.

All meals were held in the dining hall at a set time signalled by the dinner bell.  In addition to giving meals a fun summer camp feel, it ensured that everyone in the conference ate together.  I loved this setup for its ability to build community and encourage networking.  I had many excellent conversations over food, and even some pivotal moments in terms of my thesis (more on that in a future post).  A downside was that the food was usually just ok at best, and there was always too much of it .

Although most attendees stayed on site, we were spread around many different buildings on site.  I was really surprised to see our lodging when I first walked up to it.  I remember describing it as a "70's nature lodge" and wondering how something so dated, and without any in-room phones or TVs, could cost so much.  I suppose, though, that a lot of the money goes towards the maintenance of the beach, which softens the blow.  It really did grow on me over time; the slight ocean view from the balcony likely didn't hurt.

One of the things I really enjoyed was walking along the boardwalks that wound through the protected sand dunes.  They were often higher than the beach, thus affording some lovely views.  Occasionally, you even met some wildlife along the way.

After the conference was over, I headed to Monterey and spent an afternoon at Monterey Bay Aquarium with a fellow conference attendee.  The aquarium is inside old cannery buildings, so from the outside doesn't look like much.  It was absolutely spectacular inside, though.  I loved every minute there and could have stared at some of the exhibits forever, constantly discovering new details.

After a long walk along the coast to my last hotel room and an early morning flight the next day, my trip was over.  I can't say I've ever had a bad experience travelling to California, and I'm really grateful that I was able to use my professional development money at Carleton to make this trip.  Stay tuned for a future post about the academic side of FDG.

A Classroom Game to Teach Data Representation With Images

Our Gram's House team has been working on three classroom games designed to teach middle school girls about computer science principles.  One game intends to teach data representation by showing how images can be represented on computers with numbers.  Here are the current rules of the game.  These are not final—there are open questions about some individual rules, and we need to do more play testing with the target audience.  Feedback is most definitely welcome!

Materials

Each player will receive two pieces of paper.  The first will be hidden from the other player and contain an encoded image and the total number of black cells contained in the image.  The image will be different for both players.

The second page is a blank grid where the encoded image will be revealed over time.  This page will be placed on the table where everyone can see it.  Each player must copy the total number of blacks in her image onto this page.

Each player also needs a pen.

Rules

Players alternate turns, with the youngest going first.

On her turn, Player A calls out a row number and column number.  Player B then takes one of the following actions:

• If the cell on Player B's publicly revealed image is blank, the colour of the cell will be revealed.
• If the corresponding cell on Player B's hidden image is a 0, Player B places a dot inside the cell on the revealed image to indicate that the cell is white.
• If the corresponding cell on Player B's hidden image is a 1, Player B colours the entire cell with her pen to indicate that the cell is black.
• When the revealed cell is black, Player A gets to call a second row and column, which can be for the same cell or a new one.  This happens only once, and only when revealing a black cell for the first time.
• If the cell on Player B's publicly revealed image is already revealed as a certain colour, a run of cells directly to its right is also revealed until the colour changes, or the row ends.
• If the very next cell is a different colour, nothing new is revealed.

Winning the Game

A player wins the game if the public image of their opponent has all of its black pixels revealed first.

Example

Here is an example turn.  Player A is trying to reveal Player B's image.  Player B's publicly revealed and hidden encoded images currently look like this:

Player A calls "4, 2" which means she wants to reveal the cell at row 4, column 2.  Player B looks at her hidden encoded image and sees that the cell at "4, 2" contains a 1, so the cell needs to be coloured black:

Because a black cell was revealed, Player A gets to call an extra row and column.  Though not required, she decides to call "4, 2" again to see if she can reveal a run of blacks following the first one.  Player B sees that there are three more cells that contain 1 before the colour changes, so Player B colours in all three cells:

Player A's turn is now finished.

Early Designs for Classroom Games Teaching Computer Science Principles

We have been working on designs for three classroom games as part of our Gram's House story project.  Each game teaches a different computer science principle, and has three different forms: an abstract game, a game with a fictional context, and a game with a complete story.  We will eventually be comparing engagement and learning outcomes between the different versions, but for now we are focused on getting the game mechanics right.  What follows is a summary of the three games so far and some of the design issues we have been running into.

Algorithms

The first game is about writing and performing algorithms. Our learning objective is that players should be able to both create and understand an algorithm of clear and concise directions to solve a simple problem.

First Iteration: Before the game begins, clue bags and decoys are hidden in the space the game will take place in (around a classroom, in a hallway, and so on). The bags will be placed inside of and underneath existing objects to require more complex instructions to find them. Two teams compete in a relay race. One player writes precise, step-by-step instructions to lay out three objects in a clue bag in precise positions on the floor. The next player follows the instructions. Another player writes instructions to find a location on a map inside the clue bag. A fourth player follows the instructions. A fifth player writes instructions to assemble individual parts in a clue bag into a completed object. A final players follows these instructions. Finally, players race to the finish line with their completed objects.

Design Issues: Because the teams are working on the same problems, they must be separated into two different locations. A proctor is required to determine whether algorithm performers have followed the steps correctly and whether the steps have lead to the correct outcome. Because teams are not in the same room, the facilitating instructor cannot proctor effectively, resulting in a player having to do it. Players are only active when they are reading or writing algorithms in their leg of the race, resulting in excess downtime.

Second Iteration: We are working on a cooperative version of the relay race that will reduce player downtime significantly. The race will be done with two teams in two rounds. For each team, two players will work together to write instructions, one player will be the algorithm reader, and the last player will be the algorithm performer. At the beginning of a round, writers will work together to plan their algorithms within a time limit. The non-writers on the first team will begin reading and performing their algorithm. After watching the first team for a short period of time, players on the second team will begin reading and performing their instructions. Writers will continue to refine their instructions after they are fully performed until the performers successfully complete the task.

Data Organization

The second game is centred on the principle of data organization. Our learning objective is that players should be able to recognize different ways to organize data, and see how the organization will affect data retrieval. For example, finding information in data that is unorganized requires a linear search, while a binary search can be used when the data is sorted.

First Iteration: Players are required to search a set of cards to find a specific data point. A deck of cards is arranged face down using a different organization each round. Each team draws a target card, and tries to find a card that matches the data on the target. Players can turn over one card at a time, check it, and turn it back down if it is not correct. There is a score penalty for each card checked. In the first round, cards are arranged randomly in a row, forcing players to search linearly or randomly. In the second round, cards are sorted according to the type of data being searched, allowing players to discover binary searching techniques. In the third and final round, cards are grouped into categories based on the data being searched (for example, the groups might be A-D, E-H, and so on).

Design Issues: Although there are points involved, the game feels more like an activity. Students have to observe the sorting order and determine how to make use of it, but there aren't any interesting choices to be made. The first round with randomly ordered cards makes it clear that unorganized data is difficult to search, but is unfair in a game setting; there is a risk of disengaging players.

Second Iteration: Our most recent idea for this game is unrefined, but holds some promise.  The game involves dividing a communal set of objects with varying properties across multiple dimensions (something like cards, or buttons) into individual piles.  Each player would get a target card that indicates the exact item in the pile she needs to find.  Using one of a hand of action cards, players would modify the piles on the table.  Her goal is to isolate the item she is looking for in a pile with only that item.  This will hopefully lead into a discussion about how to arrange data once so that it is easy to find any data.

Data Representation

Our final game shows players how images can be represented by computers. Our learning objective is that players should understand how images can be represented as numbers using different protocols. We also want players to understand the idea of compression using run-length encoding.

First iteration: Players will work on teams to transmit an image by encoding and decoding it in a relay. Before the game starts, players are asked to decide on a protocol they want to use during the game. In the first round, one team member takes a pixelated image and encodes it row by row by writing numbers according to the chosen protocol. The encoded version is taken to the next team member, who decodes the numbers back into an image within a time limit. The image is checked for accuracy. Players have an opportunity to discuss their protocols before repeating a second round using new images.

Design Issues: Players spend most of their time doing the rote activity of filling in their images or writing out the numbers. The only interesting choice is in making the protocol to encode images with, but the choice of protocol is constrained by the information already given. While some time is given to improve protocols between rounds, but there is little to no in-game motivation to try something new.

Second iteration: We wanted to maintain a clear connection between numbers and an image, but centre the gameplay on interacting with individual pixels. Our second iteration is for two players and is inspired by Battleship. Each player has an encoded black and white image that she keeps hidden from her opponent, and a publicly displayed grid of unknown pixels where the encoded image will be revealed as a regular image. How many pixels are black in each image is also public. Each player's goal is to reveal the image of the other player. On her turn, a player announces a pixel coordinate. Referring to their hidden encoded images, the other player either reveals the colour of the pixel at that coordinate, or reveal a run of all the pixels of the same colour starting at the coordinate.

---

We are play testing all of our games right now, though some are further along than others.  In a future blog post, I'll share more details about the image representation game, since that is a design I have been working more closely with.

Spring Research Update

It's been a while since I last did a research update. With spring (sort of) arriving, there's no better time to reflect on a winter's worth of hard work.

First / Dean Gugler 

Coherent Emergent Stories

Most of my effort in the last 8 months has been dedicated to teaching, but despite this, I managed to make progress on my PhD and thesis project.  In the fall, I spent time putting together my thesis proposal, trying to make the content as close to final-thesis quality as I could.  Then I proposed in December.

Since then, I have been dabbling with a next-iteration prototype to test my story ideas.  Instead of trying to craft an entire game, I am focusing on what I call a "story explorer."  I am designing the prototype to be as data-driven as possible so I can quickly and easily test many different stories and approaches to arranging those stories with my story engine.

Gram's House

The Gram's House project is a labour of love, and I am so excited to see how far it has come since I came up with the idea years ago.

Lately we've been hard at work on the NSF AISL Pathways grant we were awarded to study the effect of story on teaching computer science concepts with games to middle school girls.  We have been working on prototypes for three analog games to be used in informal settings.  The game cover the concepts of data representation (specifically images), data organization (searching and sorting), and algorithms (writing and reading precise instructions).

It has been a lot of fun coming up with the game designs, but also very challenging.  I really want to make sure we have something more than a lightly gamified activity.  I want the games to have inherently interesting and motivating goals that happen to require understanding of our CS concepts to achieve.  I want the games to present interesting and meaningful choices to players, and have at least some degree of replayability.  I'm not sure that our current games have all these features, and I am convinced that we can come up with even better designs.  Hopefully our resident story and game design expert Lorraine Hopping will stay patient with my constant pushing, because she has been an amazing asset to this project and has a lot more experience than I do!

Something else exciting is that two of my first year students may be joining the procedural content generation grant team at Northeastern University in Boston this summer.  I am beyond thrilled to be able to enable this kind of opportunity, and I can't wait to see what they are able to accomplish.

In addition to the summary of Gram's House on my own webpage, we have started an official project site hosted by Northeastern.  We are still working on adding content, but that should be a good place to find information about the project in the future.

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

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.

Image from GHC speaker profile

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!

Games to Get Girls Interested in Programming, and Animation for Music and Dance Games / GHC14

I started my last morning of GHC with two presentations in the GFX track, which covers games and graphics.  I enjoyed both talks, though the first is particularly relevant to our Gram's House project.

Image from the virtual world Shahnaz Kamberi worked on in her research.

Gamher: Creating a Game to Increase Girls' Interest in Programming
Shahnaz Kamberi

Shahnaz targeted girls aged 13-17 with a game to increase their interest in programming at a time when many lose that interest.  It's nothing new that we want girls to study STEM, but despite all the time, money and effort, we have not succeeded.  But maybe game-based learning, which has been proven effective in the past, can work here.

There are two deliverables with Shahnaz's research, which is part of her doctoral thesis project: game design elements list (aesthetics, mechanics, story, and technology) and an educational game that teaches Java programming.

The framework Shahnaz followed is known as the ADDIE model: analyze, develop, design, develop, implement, evaluate.

During analysis, she realized that she did not want to take a constructivist approach, which covers programs like Scratch and Alice.  Rather, she wanted to make an instructivist game, an area that is more lacking.  She then decided that she preferred a gender-specific game rather than a gender-neutral game, but wanted to break the stereotype of what gender-specific games look like.

To help with development, Shahnaz prototyped a 2D game in GameMaker and an exploratory 3D world using OpenSim.

To evaluate, Shahnaz compared performance between a group that used the game vs. a group that had traditional lectures with added interactivity. It turned out that the lecture group did a little better than the game group on the post-quiz.  This may have been because the facilitator was able to control the classroom's progress, whereas students playing the games may not have finished all the material. The game group has a higher positive response to computer science in the post-surveys, but there was not a significant difference.  Interestingly, story appeared in the participants' lists of worst and best things about the game.  There was a lot of positive response in terms of whether the girls would play the game again and whether it positively influenced their views of computer science.

My take: it was really nice to see how Shahnaz set up her experiment, and how she dealt with the fact that the game group did not perform better than the lecture group.  She realized that she works as a professor, and therefore is paid to teach programming.  So if girls were able to learn as much while playing a game, then indeed the game has succeeded! It did as good a job as a professional!

You can learn more about this project on Shahnaz's blog and website.

Animation Programming Techniques for Music and Dance Video Games
Jessica S. Scott

Jessica is the lead engineer at Harmonix, and has a mixed background in CS and art.  She opened with the question of why we even need character animations.  Among the usual answers was the notion of using animation as a user interface.  In games like Dance Central, animations tell the user what to do.  Then, why do you need programmers for animation? You need to get animations from a 3D program into a game, usually with requirements in terms of memory usage, performance, and response to user input.

Jessica started with some of the basics of computer representation of animation on a computer.  For skinning, they use bones that meshes can follow.  Animators can pose a skeleton of a character.  Keyframes are a way of storing animation poses at points at specific points in time, and movement in between can be interpolated.

Memory and performance issues: Animation often takes up a large percentage of a game's memory and CPU budget.  When storing animations, store rotation, position and scale for each keypoint, and use compression and blending techniques.

Game animation special needs: it's more complicated than movie animation! Players get control of characters, and real-time playback is important.  Game worlds have dynamic elements that help determine what animations to play.

More about blending: needed for the dynamic choice of animations.  Two kinds: combine multiple animations at one point in time, or over a period of time.  Blending allows for natural-looking but automatic transitions between different animations.  Blending involves a lot of interpolating, for example between rotation values between bones.

Storing animations: quaternions instead of rotation matrices since you only need 4 floats instead of 9, and blending is easier due to easier interpolation.

Inverse kinematics: modifying a character's joint positions and rotations based on physics constraints.  Mathematical calculations are applied after regular skeleton posing.  Important not to apply to only one set of bones!

Dance Central example: foot slide during blending.  Suppose you want to blend two dance moves and the foot is on the ground with weight on it.  Takes a lot of effort to get the foot to do something interesting in between.  (Showed a funny example with a really long, stretched leg.)

Beatles: Rock Band example: wanted the Beatles to lean in toward the mic during harmonies.  Seems like a good idea to just stretch the neck toward the mic, but turns out not such a good idea when the character is too far away from the mic! (Showed another funny example with one Beatle standing too far away, with a super long neck stretched to the mic.)

My take: how cool to learn a bit more about what's behind animations in my favourite games! (Dance Central and Beatles Rockband happen to both be games I've played a lot.)  The talk also makes me wish I could spend more time on computer graphics, which I have learned but never get to practice.

Gram's House Project Team Receives Two NSF Pathways Grants!

Gram's House is a research project I started several years ago with a prototype originally designed for Microsoft's Imagine Cup competition.  Since then, a core research team has formed around the project: me (Carleton University), Elisabeth Gee (Arizona State University), Carolee Stewart-Gardiner (Kean University), Gillian Smith (Northeastern University) and Casper Harteveld (Northeastern University).

We just got awarded two NSF Pathways grants for the Advancing Informal STEM Learning program!

The Role of Story in Games to Teach Computer Science Concepts to Middle School Girls

This project is being co-lead by Elisabeth Gee and Carolee Stewart-Gardiner.  Since I'm not a research faculty member, I am participating as a contractor.  We are going to dive deeper into determining the effect of story in educational games that teach computer science to middle school girls.  This will extend previous work I did with a study during my mini-course a couple of years back.

As part of its overall strategy to enhance learning in informal environments, the Advancing Informal STEM Learning (AISL) program funds innovative resources for use in a variety of settings. Nationally, the US has a shortage of computer scientists; a big part of this problem is that girls are discouraged from learning computer science at a very young age. This project tries to address this problem by creating a videogame specifically oriented towards getting middle school girls interested in learning computer science concepts outside traditional programming classes. Based on evidence that stories provide a compelling way to present complicated technical subjects and that girls in particular respond to technology careers as a way to help others, the project is building a videogame called "Gram's House" in which social workers intend to move a fictional grandmother to a retirement home unless the player can outfit her home with sufficient technology for her to remain independent. Solving puzzles in the game requires learning core computer science concepts. Research studies will be conducted to determine whether the videogame is effective at getting girls interested in computer science, at teaching computer science concepts, and whether using stories makes videogames more effective for learning.

This project based on an earlier successful prototype uses an iterative research-based design process including paper prototyping, playtesting, and focus groups (N=20) to create age appropriate activities, based on the CS Unplugged series, that support learning concepts from the Data, Internet, Algorithms, and Abstraction sections of the high-school level CS Principles curriculum. A quantitative, quasi-experimental design will be used to determine the overall effectiveness of teaching CS concepts under three types of game conditions: (a) games alone, (b) games with fictional settings, and (c) games with stories. A novel assessment instrument will be developed to assess content learning and qualitative observation using a standard observation protocol will be used to gauge interest and engagement. 70-80 middle school girls will be recruited for afterschool participation in the study in two states. As part of the dissemination efforts, a facilitator's guide, rule book, and materials such as maps and storyboards will be created and shared with the game. In addition, a workshop for computer science and other teachers who are interested in using games to teach CS concepts will be conducted.

(Project link on NSF website.)

GrACE: A Procedurally Generated Puzzle Game to Stimulate Mindful and Collaborative Informal Learning to Transform Computer Science Education

The PCG project, as I like to call it (where PCG stands for procedurally generated content), is being lead by Gillian Smith and Casper Harteveld.  They want to learn more about how best to generate puzzles that teach high level computer science concepts, and whether players will learn more about the concepts when discussing how puzzles are generated in an attempt to help one another solve them.

Northeastern University will design, test, and study GrACE, a procedurally generated puzzle game for teaching computer science to middle school students, in partnership with the Northeastern Center for STEM Education and the South End Technology Center. The Principal Investigators will study the effect of computer generated games on students' development of algorithmic and computational thinking skills and their change of perception about computer science through the game's gender-inclusive, minds-on, and collaborative learning environment. The teaching method has potential to significantly advance the state of the art in both game-based learning design and yield insights for gender-inclusive teaching and learning that could have broad impact on advancing the field of computer science education.

Development and evaluation of GrACE will consist of two, year-long research phases, each with its own research question. The first, design and development, phase will focus on how to design a gender-inclusive, educational puzzle game that fosters algorithmic thinking and positive attitude change towards computer science. The content generator will be created using Answer Set Programming, a powerful approach that involves the declarative specification of the design space of the puzzles. The second phase will be an evaluation that studies, by means of a mixed-methods experimental design, the effectiveness of incorporating procedural content generation into an educational game, and specifically whether such a game strategy stimulates and improves minds-on, collaborative learning. Additionally, the project will explore two core issues in developing multiplayer, collaborative educational games targeted at middle school students: what typical face-to-face interactions foster collaborative learning, and what gender differences exist in how students play and learn from the game. The project will reach approximately 100 students in the Boston area, with long-term goals of reaching students worldwide, once the game has been tested with a local audience. Results of the project will yield a new educational puzzle game that can teach algorithmic thinking and effect attitude change regarding computer science. Through the process of creating a gender-inclusive game to teach computer science, it will provide guidelines for future educational game projects. Beyond these individual project deliverables, it will improve our understanding of the potential for procedural content generation to transform education, through its development of a new technique for generating game content based on supplying educational objectives.

(Project link on NSF website.)

How Small Changes in a Game's Story Can Make a Huge Difference

I recently wrote to the author of a book I love, Think Like a Programmer.  I had wanted to ask some questions related to using the book for one of our first year classes. But it turned out that V. Anton Spraul also happens to be interested in stories in games, the topic of my thesis.

Leave me alone, I'm reading. / Hey Christine 

We had some interesting discussion on the topic after he read our Foundations of Digital Games paper on coherent emergent stories. I thought that some of his suggestions of how this sort of system could work were so spot on, I wanted to share them here.  So, with Anton's permission, here is what he said:

So I'm intrigued by your idea, especially by how it could be employed without the player knowing -- using a "tension" value to control the type or volume of music in a scene, for example. What if a game gradually lowered tension over time outside of character interaction or combat, so that a scene would actually play differently just because the player took a long walk before a key confrontation? Cool stuff. Or a game with Bioware-style dialogue interaction where certain choices were not always present, and not because certain information had previously been discovered or not, but because of the emotional state of the player avatar at that moment, as influenced by prior events? Perhaps ultimately, a game could be made which always arrives at the same scene, but the outcome of the scene is largely controlled by prior actions in a way the player wouldn't predict--so maybe the player can only shoot the final boss if he or she is angry enough to do it. (I was let down by the endings of the otherwise brilliant Deus Ex and Deus Ex: Human Revolution because they didn't depend on anything that happened five minutes before the end of the game.)

I like the tension example especially.  We had pictured using different lighting, or camera angles, depending on the path the player took previously.  For example, maybe the ending of the game is the same either way, such as the princess returning to the kingdom after "taking care of" the threat of the nearby dragon.  Simply knowing that the player befriended the dragon and learned its behaviour was a result of it protecting its child would already cause a different interpretation of the culminating scene than if the player had slayed the dragon.  But adjustments in lighting, for example, might emphasize this.  The idea that additional small changes based on tension could reflect the urgency with which the player acted seems all the more interesting!

This kind of approach is meant to allow players to have an effect on a story's outcome without the need to create much (or anything) in the way of additional assets.  I think the potential is enormous.

GLS10 / Let’s Prototype: Women at the Intersection of Learning, Games, & Design

The tenth annual Games, Learning and Society Conference, held this past June in Madison, WI, featured a panel on women in gaming.  Moderated by games-journalist-turned-grad-student Amanda Ochsner, the panel featured some heavy hitters: Elisabeth Gee, Deborah Fields, Yasmin Kafai, Colleen Macklin, and Mary-Margaret Walker.

The discussion was mainly focused on how to get girls interested in both game design and computer science (but not necessarily both).  Following is a summary of some of my notes from the panel.

Image modified from original via Wikimedia 

How can educators create better mentoring opportunities for young women?

The first answer was a great one: be visible, and be outspoken.  Show why this is such an exciting time to be in games.

The experience of some panellists is that no matter how they set up workshops featuring game programming, it's always the boys who sign up.  We need to talk to teachers and actively talk to girls, personally inviting them to come.  Perhaps girls-only groups are needed (that's what I've been doing in my own outreach!).

One panellist pointed out that she was able to attract girls by featuring stories, music, and animations rather than games and programming directly.  The students don't even realize they are programming at first.  In another panellist's workshop, attendees would work on e-textiles; in this case, marketing must be done very carefully as both boys and girls hold onto stereotypes they aren't even aware of ("no sewing, circuitry or programming required").

Another challenge is that many still hold onto stereotypes about what it means to be a gamer; supposedly, only uncool gamers take game design classes.  At ASU, they are trying to infuse game design into journalism.  Foregrounding the subject matter that games are about seems to be a successful way to attract more women.

How can we approach teaching game design in ways that support a diversity of ideas and process?

In a sense, the discussion surrounding this question presented a solution to the previous one.

One of the most interesting ideas was that all art is technical - there are always technologies to learn that you use to be creative.  Hence, making games, and all the technology behind that (including programming) could be considered an arts subject.  The technical element is simply something you need to learn in order to effectively express yourself.

How might we engage young girls in game design, programming, and technology at earlier ages?

Something to remember: "We can't do it all, and we can't do it all in programs." Nonetheless, it is not difficult to find really good tools to help design programs to engage girls.  We can engage kids in actively designing and making things, and in making connections to things they care about.

One greater issue is the poor quality of many games designed for girls.  According to panellists, there is nothing in these games to get girls interested in computing and other technical pursuits.  The games have a low level of complexity.

We are often trying to get girls interested in game design and computing at the same time.  Perhaps, panellists pointed out, we should sometimes keep these types of outreach separate.  Learning about technology, for example, doesn't always have to be done through game design.  There are many other great opportunities like e-textiles.  At the same time, we don't always have to be trying to get girls interested in programming and computer science when we teach them game design.

Remember that each kid is already designer ("I designed my first games during recess").  That's a start.  Now let's talk about how games are actually made.  In the 1980's, you typed game code from a magazine to be able to play.  Everyone understood how programming worked because we had to.  Can we make programming not such a special thing?

---

For more, see my conference notes on this session.