Tuesday, 23 May 2017

The SSM Framework of Game Design

This article goes over a framework for understanding how videogames work. It divides games into systems, story, and a mental model, and then shows how these interact. Using this system makes it easier to make design decisions and enables one to have insights into the workings of a game.

I've previously talked about story and mental models, and now it's time to wrap it all up into one neat framework. By looking at how these aspects influence one another it's much easier to talk about a game, and it also allows us to draw some fresh conclusions. In this post I'll go over the basic framework and then discuss how it can be applied to gameplay.

It's worth noting that this is by no means the only way of looking at games, nor does it take into account every single aspect of what games are. I think it's broad enough and covers enough ground to be really useful, though. In fact, it'll be used as a foundation for many of my upcoming articles on design. With that said, let's start.

The first thing you need to realize is that all games work in three different spaces: System, Story and Mental Model. These are the building blocks of the entire framework and I'll henceforth refer to this as the SSM-framework. This theory derives a few of its basics from the MDA framework, so it feels right to briefly go over that. In the MDA framework, games are divided into Mechanics, Dynamics and Aesthetics. The mechanics are the basic building blocks of a game, the dynamics are how they work together, and the aesthetics describe the user experience[1]. All of these different components are layered and dependent, so mechanics give rise to dynamics and dynamics give rise to aesthetics.

While I think the MDA approach to looking at games can be really helpful, it doesn't properly separate the player's understanding of the game from the actual behaviour of the game. That's the main thing that the SSM Framework tries to fix. The way it does this is by viewing a game as something that takes place in the three spaces I mentioned earlier: Story, System and Mental Model. Now let's go through each of these.


The System space is where all of the code exists and where all of the game simulations happen. It's here that things get done. We can divide this space into two layers: Mechanics and Dynamics. This is incredibly close to the MDA framework, with the exception of the Aesthetics layer. It's also important that the mechanics and dynamics here are abstract; we don't take any account of how they are presented to and understood by the player. System space only concerns itself with functionality.

Story, as explained in this previous post, is what gives context to the things that happen in System space. In Super Mario's system space, a fireball is just an abstract object with bounds that trigger a particular event on collision. It's in Story space that it looks like a fireball, which helps the player intuitively understand what sort of threat they are dealing with. Sometimes the Story space is very thin. For instance, in Tetris the visuals are basically just a direct visualization of the system space. In other cases, the Story space can be very thick. A good example of that is The Walking Dead where the systems are supported by hours of non-interactable Story-space cutscenes.

Just like the System space can be divided into two layers, so can Story space. At the bottom layer we find the Mis-en-scéne, which is basically everything that the player can see, hear, and in other ways reach their sensory organs. This is a term borrowed from film and I think it best encapsulates this component of the story layer. In the layer above that we find Drama. Just like the Dynamics of System space, this is something that is generated by the layer below, in this case the Mis-en-scéne. Here's a quick example of this: In Super Mario, the character of Bowser is part of the Mis-en-scéne and the fact that he does not like Mario is Drama. Just like with Mechanics and Dynamics, there is some overlap between the two, but they are still separated enough for it to be a useful distinction.

Mental Model
Finally we arrive at the Mental Model space. It's hard to quickly summarize exactly what a Mental Model is, and the best thing really is to read the previous blog that discusses the subject. In very simplistic terms the Mental Model is the player's personal experience of the game, making it similar to the Aesthetics of the MDA framework. The big difference is that while it does derive from what happens in a game's Mechanics and Dynamics, it is thought of as its own separate space. When you join together the three different spaces, it looks like this:

It is when the Story and System space are experienced together that a Mental model is formed. I think it's incredibly important to think of this as a separate space, because just like System and Story have their components, so does the Mental Model. At the basic level you find Affordances. This is basically the functionality that the player attributes to a perceived object, e.g. that a door is something that can be opened. Then at a layer above that you find Schemas, which is how the player thinks they should behave in various situations and how these situations ought to play out.

This is a quite rough division of layers and as before there is overlap. There are also further details to take into account, such as the player's emotional responses and so on. Normally, you wouldn't think of these as part of, say, Affordances, and if you wanted to you could make the components of the Mental Model space quite complex. I feel that for a framework to be useful it needs to simplify things and as a start Affordances and Schemas work quite nicely. It's not at all that different from Mechanics and Dynamics; these are widely used concepts in game design despite not being exact expressions.

A final important note about the Mental Model space is that it doesn't necessarily need to contain things from either System or Story space, it can be things that the player makes up from their own imagination. For instance, certain items might disappear when they are out of view for a long time. The player might form the Mental Model that that this is due to some gnomes, despite neither System nor Story space contains any such information. This is very common, and a large part of the Mental Model space is usually taken up by these kind of imaginary entities, actions, etc. Sometimes a game is designed for this, other times it is purely accidental.


With the basics laid down let us discuss how the SSM Framework describes a game loop. Here is a an overview for how it all works:

Click to enlarge.

The steps are as follows:
  1. The users triggers an input on the controller and this data is sent to System space.
    Example: The fire button is pushed.
  2. System space handles the data, does all the required simulations and then generates a bunch of abstract data.
    Example: The trajectory of the bullet is calculated, a collision is found, the hit points are lowered for the object and this causes the object to transition into the "exploded" state.
  3. This abstract data is sent to the Story space, where it is given context.
    Example: The game changes various numbers which are used by various graphics components to produce output. The "exploded" event triggers a particular sound file to be played.
  4. A collection of sounds, animations, graphics and so forth is produced.
    Example: The bullet is animated as a flying projectile. It is seen hitting a barrel which then explodes to the sound of a loud "Boom!".
  5. This Story generated content gets sent to the various sensory organs of the player. The most common are the eyes and ears.
    Example: The player hears and sees the explosion.
  6. The player's sensory organs sends the data to the brain where it is processed in various ways. We are now entering the Mental Model space of the game loop.
    Example: The player recognizes the bullet and barrels as those objects. It's also clear that the bullet hitting the barrel caused an explosion event. This, together with the boom sound, gives the player a feeling of satisfaction.
  7. The player's impressions are fed into the current mental model.
    Example: This is the first time the player witnesses a bullet making a barrel explode.
  8. Using the new data, the mental model is updated.
    Example: The player is now aware that shooting barrels will make them explode and cause satisfying effects.
  9. The player uses the most recent model to figure out what to do next and simulates what effects various scenarios would have.
    Example: The player is surrounded by barrels and knows that their goal is to destroy as many objects as possible. They consider what would happen if they were to shoot at more barrels. A mental simulation is made where the result of shooting the other barrels would make them explode as well, causing a lot of carnage, which brings the player closer to their goal. This feels like a good plan.
  10. With a plan for what to do next, commands are sent for the player to trigger the game's input device.
    Example: The player's brain sends signals telling their hands to move the stick and hit the fire-button in such a way that it should hit the nearby barrels.
And then then it all loops back to step 1 again and begins all over. Hopefully this gives an idea of how useful the SSM Framework is in describing the game loop. Once you have this sense of how data is formed and transported around as a game is played, it's much simpler to see where something goes wrong. 


Now for a simple example of how this framework can be helpful when analyzing input. Hopefully this will also show how SSM can help us discuss certain game design problems in a much simpler way. 

Let's start by imagining a System space that has the following: 

  • A character where the bounds are defined as an abstract cylinder.
  • An abstract device that will play sound files when certain events are triggered.
  • A couple of rules that will make the cylinder character stay at a certain distance from the player.
Now say that the Story space looks like this:

  • The cylinder takes the form of a cute rabbit.
  • The sound files played are cute quips that the player is meant to find endearing.
The designer's goal is that the rabbit should be something that the player cares about. If the Mental Model gets constructed properly the player will think of the rabbit as a living creature and base their imagination mainly on the story aspects of the character. This makes the player protect the rabbit and makes sure that it never falls too far behind. This is a case of the Mental Model working as desired.

However, it might be that the player realizes that the rabbit is a great shield against incoming enemy attacks. The game becomes much easier to play if the player manages to position the rabbit in between them and any hostiles when it's time to loot treasure chests. 

This radically changes the player's mental model. Instead of being a living creature, a fantasy mostly derived from Story space, the player now sees the character mostly as an element of System space. The rabbit is now simply a handy game object that has various tactical benefits.

This sort of thing is quite common in games. Entities usually start out in story space and then as you play the game and discover how they actually work, your mental model becomes more influenced by System space. And since the story content can usually deliver a lot more emotional depth, the experience comes off as very "gamey". In some cases this can be perfectly fine, but when you want to deliver a narrative experience it can be devastating. In this case it's really important to keep our Mental model close to what we had in Story space.


These sort of story vs gameplay issues are really easy to discuss in the SSM Framework, and it also provides us with several avenues of attack for how to solve them. You need to make sure that System space doesn't generate Mentally Modeled behaviors that directly contradict what is in Story space. By thinking about the flow of data in the game loop you can pinpoint where it all went wrong and then change things accordingly. While this doesn't spell out every single step needed to fix the problem, it gives us a way to formulate it and a foundation on which we can lay a more detailed plan.

Next week I will go over how the gameplay is defined in the SSM Framework and how it shows us a way to give narrative games a great sense of play.

[1] The MDA framework also brings up various ways in which games engage players, but that I felt no need to go over that in this article. Do note that there is more to the framework than simply 3 layers of components.

Monday, 15 May 2017

Thoughts on Five Nights at Freddy's

I have seen many people saying Five Nights at Freddy's is simply a jump-scare fest. While the game does rely a lot on jump scares, I think it's wrong to dismiss it just because of that. There are a number of aspects of Five Nights at Freddy's that I find really interesting and I think it's worth exploring them.

Here are my top take-aways from the game:


No traversal

Just about all horror game games revolve around the protagonist moving around. It's a core part of the game. Not so in Five Nights at Freddy's. Here the player is unable to move around at all. Instead, the game is all about observation and seeing how other creatures move about.

As I've said in a previous article, traversal can be problematic. So it's very interesting to have a game that solves those issues simply by ditching the entire concept. The lack of traversal also helps the game to have a more nightmarish feel and further simplifies the gameplay (more on that later).

Great use of sensory deprivation

In my previous post I talked about how it's really helpful to put the player in the right mood by not overwhelming their focus. Five Night at Freddy's is excellent at this. The game is so simple and there really isn't much for the player to do apart from observing. This means that you have plenty of mental capacity left over, and all of that is put into simply being worried. This fuels all sorts of paranoia.

Tight connection between story and mechanics

While the setup is quite silly, one has to applaud just how connected the systems and narrative are. As the background story of the game is told you also learn how to play the game. They are really one and the same. There are very few narrative games where this is true and it means your mental model of the game is almost entirely built in narrative terms.

Obscure mechanics done right

At first it's almost impossible to figure out how the animatronics behave and you simply have to rely on intuition. The thing is that your intuition is pretty good at letting you survive, but not so good that you start understanding any underlying systems. When you hear particular sounds, you'll want to close the door or turn on a light, and in many cases you are doing just the right thing. But as these intuitions are not based on simplistic systems, you are driven to mentally model the various creatures as living things. Just like the previous point, this makes your mental model much more story-like.

Death and jump-scares combined

In Five Nights at Freddy's there is always a jump-scare right before the game ends. This weaves a very tight connection between "failure" and "being spooked" allowing these things to reinforce one another. This really helps to increase the tension as it provides feedback both in terms of mechanics and by giving you a painful experience. This makes you not want to fail at the game, which ramps up paranoia and other things described earlier.

Focus on anticipation

Five Nights at Freddy's is also unique in that it puts all of its focus on the things that happen before an encounter. This is quite rare in videogames where much of the gameplay happens once a monster starts coming after you. But in most horror movies and books, much of the narrative revolves around what happens beforehand. This makes sense, as a lot of fear comes from anticipation. Just take a look at movies like Ringu, where the entire story is build-up for a proper encounter in the end.

This game works pretty much like that. When the game goes your way, you never encounter the monsters. In fact, the moment there is a monster encounter the game is over. I don't think any other game has done a better job at emulating this way of building up a horror story.

Dynamic horror situations

Finally, the game is also great at causing moments of horror to emerge from its systems. Five Night At Freddy's doesn't script specific situations, but it sets up systems which will allow them to occur naturally. To me this is one of the foundational aspects of really good interactive storytelling. My own favorite moment:

It was just a few hours before the night was about to end, and I was getting really anxious. I heard a footsteps but couldn't really figure out where they were coming from. I scanned the camera feeds and couldn't see anything. The sounds died out and an eerie silence replaced it. The night was almost over and I saw that my power was nearly exhausted. I decided to a small amount of it just to make sure that nothing was outside the window. The moment I turned on the light I saw this rat creature, just staring at me. My entire body froze.

In that moment it really felt like I was taking part in a horror movie. I built up most of the tension myself and then it was a dynamic system that made the crescendo happen. It felt amazing.


Five Nights at Freddy's is far from a perfect game, of course. My biggest problem is that it gets boring fairly fast. The scares stop being scary after a while, and once you understand how the systems work your mental models becomes a lot less interesting. For me it took a less than an hour before I felt I'd had enough of the game. Much of that hour was really, really good though.

It's also worth noting that I've written this about the first game. I've played two of the sequels, but didn't think they were as good as the first.

In any case, if you haven't played the game yet, I highly recommend doing so. It's great while it lasts and there's a lot of great to design to inspire you.

Tuesday, 9 May 2017

6 Reasons For Having a Defenseless Protagonist

Not having any combat can be really helpful to horror games and crucial in delivering the desired experience. This article presents the top 6 reasons for this and also explains how it ties into narrative games in general.

Outlast 2 has recently been released and has spurred a lot of discussions around not giving the protagonist any means to fight back. I haven't played enough of the game to be able to give an overall impression of it (I'm just 30 minutes or so in), but I think I've seen enough to weigh in on the discussion. We at Frictional have been knee deep in this problem since 2006, and I've been up against the problem myself ever since I made my first hobby horror game in early 2000. This is something I've been thinking about for almost 20 years, and hence something I have a strong opinion about.

The discussions around weaponless protagonists is often focused on horror games. It's really a question that concerns narrative games in general, though, and isn't just about what sort of horror you want. It's really about what sort of approach you want to take to storytelling. It also has a lot to do with my recent post on mental models, which makes this a good time to go into it.


Let's start with the main reasons why you would want a game with a defenseless protagonist. This is by no means an exhaustive list, but it brings up the most important reasons.

1. It makes the player assume the appropriate story role
To someone with only a hammer, every problem will look like a nail. The same is true for the tools that we give to a player. The actions that we let the player use informs them about the role they are supposed to play within the game. It's really hard to make the player feel like a detective if they never get to do any actual detecting.

Why is this the case? Because the way we interact with the world around us is via a mental model. This mental model is built from a network of connected attributes, all having do with the various aspects of our world. When taken together this gives us a sense of how the world behaves and what we are dealing with. So when we see a character looking for clues in a crime scene, interviewing witnesses and trying to piece together evidence, it'll point towards the idea that this person is trying to solve a crime. This creates a strong belief that the character is indeed a detective. If we are simply told a character is a detective but only see him chopping wood it is really hard to take the first statement seriously. You will never model this character as a detective. No matter how many times you tell me that a pile of sharp glass is a chair, I will not perceive it as one. It simply lacks any of the attributes that I associate with things that are chairs.

In the same way, in order for the player to feel like they are inside a horror story they need to have access to the actions of the protagonist of a horror story. In horror the protagonist is supposed to be vulnerable, uncertain, and out of their depth, and to get this across to the player you need to restrict their available actions to support this. A really simple way to do this is to simply skip any means of fighting back. Sure, you can always make weapons less effective in the game, but the moment you give them any sort of weapon it's likely to awaken deeply rooted mental models in the player. We humans are really good at generalizing and unconsciously judge many situations on the first pieces of evidence we can get our hands on. So when you introduce a weapon in a horror game, the player will view the game as one where the primary action is combat and then by assumption add a variety of other attributes to the experience. This is something we experienced firsthand when making Penumbra: Overture where player would even treat an old broom as a potential weapon.

2. It make monsters feel like threats

Just as the actions at your disposal informs your role, so do your interactions inform what sort of world you are in. If the player's main action is to shoot down monsters, the monsters become target practice. Again this is mental modeling. Just like we determine something to be a chair by determining its shape, how well it can be used for sitting, and so forth, we also evaluate any dangers by what attributes we can assign to them. When "thing that I shoot to generate fun gameplay" becomes a strong attribute for a monster, a lot of the horror is lost.

If, instead, monsters are things that the player interacts with only by running away and hiding from them, the mental model becomes quite different. You start to draw connections to other things that you would run away from, and this jacks much better into your primal fear response. The monster is no longer a game object connected to a core combat loop. Instead it becomes an unknown entity that you have no means to fight. This makes a huge difference to how the player perceives the threat.

3. It leaves more to the imagination
Another problem with being able to fight any creature is that this requires many close up encounters. You need to aim at the creatures, see feedback of them being hit and so forth. Most importantly, in order for this gameplay to work you need to have lots of actual confrontations. This goes against one of the most important rules in horror: leave the monsters as vague as possible.

When your gameplay doesn't rely on combat, it's much easier to keep the monster out of sight. When you are running and hiding, the monster doesn't really need to be visible at all. You can just rely on the player seeing quick glimpses, hearing sounds, watching a motion tracker and so on in order to sustain the gameplay. This gives a lot more room for the player's imagination, and allows them to conjure up far scarier monsters than what could be rendered using polygons.

4. It makes the player paranoid
Checking how much ammo you have left, thinking about what gun to have available, planning for ammo usage, looking for items and so on - all of these are activities that the player constantly has on their mind when playing a shooter. And all of these take up mental resources that could have been used for other things instead. It's very important to know that the player has a limited amount of focus and whenever you tell the player to give something their attention, something else will have less attention. Remember this as a designer: whenever you say yes to something, you say no to something else.

What this means is that when you remove any form of combat, the player has a lot of mental focus to spare. In fact, many players will have too much. This almost leaves the player is a state of sensory deprivation. The outcome of that is that they start to pay a lot of attention to small details. It makes players more paranoid, more prone to invent reasons for small sounds and so on. This is an extremely good state in which to play horror. It's also something you lose if you give the player too much else to think about. We noticed this ourselves in Amnesia: The Dark Descent, where many levels where made better by giving the player less to do. This encouraged them to fantasize more and gave the unintuitive result of increasing their engagement,

5. It makes it harder to optimize away emotions
A combat system is something that the player often has played hundreds of hours of before. Sometimes much, much more. There are lots of well-known tactics for dealing with encounters, and players often come with a huge instinctual toolset on how to bypass various dangers. What this means is that there is ample opportunity for the player to figure out ways to beat the monsters. In turn, this means that the monsters lose their core attribute, to be horrible threats, and instead just become standard gameplay objects.

It's much harder to do this in a game without combat. When you don't have a set loop that the player uses to interact with the game's world, it becomes much harder to figure out underlying systems and to optimize. This means that the player has to rely more on their imagination to make a mental model of the world and its inhabitants. If the systems that drive the monsters are obscure, you have to think of them as living, breathing creatures and this greatly heightens any emotions that you associate with them.

Of course, if you use non-combat oriented gameplay in the wrong way, you will fall into the same trap. This is something I'll go over in a bit.

6. It is a great design constraint
As I noted before, games are often too much fun for their own good. This is most certainly true for combat. In fact, combat is probably the most common core mechanic in games. It's really easy to come up with engaging ways for you to do it. So the moment that you decide that you will have combat, it makes it so much simpler to come up with engaging scenarios for a game. This means that you are very likely to overuse combat and to drop focus on the narrative you are trying to convey.

When plot dictates that the player has to go through a sewer, how should we make this section engaging? With combat this answer is easy: just add some monsters and have the player fight them. Problem solved! You see this over and over in games that use combat, especially horror games. Even though it is clear that the focus ought to be on delivering a certain end experience, there are tons of areas that, by being satisfied with just having simple combat, counteract this goal.

If you don't have combat, you don't have this option. If your basic gameplay is just running and hiding, it's actually quite the opposite: your core mechanics are not much fun. This means that you need to think of ways to vary them, you need to be careful when to use them and there need to be other activities involved. This forces you to avoid any easy solutions. Simply relying on "add some monsters for the player to encounter" will not work in the long run. It will soon become very tiresome to play the game, because you are relying gameplay that is, at its core, not engaging enough to be the driving force of the experience.


That concludes the list of the most important reasons why a defenseless protagonist is really good to have in a horror game. Now I will go over a few common counter-arguments, and respond to them.

Claim 1: "Without combat, the game becomes boring"
I think this is both true and untrue. 

It's true in the sense that in order to get the player to experience certain things, such as the paranoia that comes with sensory deprivation, your game simply cannot be too much fun. This is how narrative works in other media as well. Certain experiences cannot simply be made into a super-engaging package. There needs to be a certain level of "boredom" for it all to work. The experience as a whole must of course be engaging, but not every game can have the moment-to-moment excitement like something like Doom. 

It is untrue in the sense that we haven't yet seen what can be done without having combat. Many people simply compare the current state of games with defenseless protagonists to the current state of games with combat, and then take this as how it will always be. I think there's a lot that can be done in order to make interesting defenseless horror, or other narrative experiences for that matter, and still have a level of "gaminess" on par with that of a shooter. The problem is that combat gameplay comes naturally and has had 40 years to evolve; gameplay without combat is much harder and has had much less time to evolve.

I have to admit that I am growing quite bored with the standard "run and hide"-gameplay. I think it can work when used in short bursts, but it's far from an ideal solution. We need to think harder and dig deeper in order to improve gameplay for horror and other narrative games. That is basically what this whole blog is about and something Frictional Games is investing heavily in. This is uncharted territory and there is huge room for improvement.

Claim 2: "No combat leads to lots of trial and error"
If you look like a game like Outlast 2, this is certainly true. There are a bunch of sections where you have to replay over and over in order to continue. This all boils down to Outlast 2 using the "run and hide"-gameplay as a foundational element of the game, and it's interesting to discuss why this must give rise to so much trial and error.

The first reason is that it is very hard to have a good analog feedback system. In a game with combat it's much easier to have stats for things like health and ammo which you can vary during an encounter and use as feedback. But in a game where you are trying to not get caught, the situation is much more binary. You either get caught or you don't. So the moment you need to give the player the feedback that they are "not playing correctly" that usually means killing them off, and forcing them to start over again.

The second reason is the fact that player failure means death and restart. This doesn't have to be the case. Few things break our immersion as much as having to replay the same section over and over. In fact, in order keep a level of presence you are almost obliged to make sure this never happens. Every time you pull the player out of the experience, you break the illusion and force them to build up the fantasy from (almost) scratch again. Player death is a huge problem in narrative games, and despite this, very few games try to deal with it.

Again this is something I think that has lots of room for improvement. It is also something that we at Frictional Games are trying to solve in both of our upcoming games. The goal is to have an experience where you never see a "Game Over" scene, yet feel a strong sense of being able to fail and is very anxious about not letting that occur. This is not an easy challenge, but it is also one with huge potential. Staying immersed and feeling your actions have consequences are big reasons why interactive storytelling is so interesting, and even small improvements can come have great impact.

Claim 3: "Not having combat is unrealistic"
This claim is highly dependant on what sort of experience you are trying to create. Sure, if you are doing a videogame version of Aliens or Deep Rising, it's a great fit. But as I have outlined in this ancient blog post, there are many different ways in which combat is featured in horror movies. If you want to do a videogame version of The Exorcist then combat will play a much smaller role - probably none. Most of the time, weapons are there as a last line of defense for the protagonist(s). From that angle it makes sense that you should have at least have some form of defense. But you also have to consider all of the negative aspects, many of which I listed earlier, that come along with having combat. If a horror story should "realistically" let the protagonist use a weapons in two or three places, then it might make more sense to try and make these places go away somehow.

Another way to approach this is to have combat in ways that doesn't imply your standard combat mechanics. Weapons could be puzzle items that the player have to be careful about when they use them. It's also possible to use the environment as a means of defense. The point I'm trying to make here is that it's possible to retain a sense of realism without reverting to full-blown combat mechanics.

Either way, I think the most important question to ask is: "What is the best way to achieve the intended experience?". If combat is the best way, even if you take all of the downsides into account, then by all means go in guns blazing!


Most of these discussions have centered around horror games, but really most of these things apply to any narrative game. It's not just horror games that strive to keep the player's imagination going or want to avoid players that optimize away emotions. These are foundational issues for any game that wants to try and tell a story. The problem of not being able to rely on an engaging set of core mechanics is also something that goes beyond horror games.

Thinking about why we want a defenseless protagonist in the first place and then figuring out means to make it better feels like a really important question to me. It connects to many of the core issues that face a game that wants to focus on narrative, and any improvements are bound to be helpful to interactive storytelling in general.

Next week I will present a system that will allow us to more easily think about these issues, and will hopefully also make it easier to find solutions.

Thursday, 4 May 2017

Story - What is it good for?

Do videogames really have to try to tell stories? Are they not just better off focusing on interactive systems and gameplay? In this post I argue that stories are fundamental to the play experience by supplying context. This story context is crucial in order for videogames to engage and make the gameplay easy to grasp.

For ages there's been an argument going on about what part stories should play in videogames. Over time stories in games have gained more acceptance, but the discussion still continues. For instance, Ian Bogost recently wrote this article where he asked why you should make a game out of a story when you might as well make a movie or write a book.

This "go write a book instead" attitude isn't new. One of my favorite articles on the subject is Jesper Juul's "Games Telling Stories?". Interestingly, I pretty much agree with all of the points that Juul raises, but reject most of his conclusions. I think that video games are very well suited for telling stories and that there is no inherent conflict. Where I fully agree with Juul is on the argument that if you just take stories as we normally see them on film or in books and apply them to games, there will be a lot of friction. In order to make stories work in games you need to consider them in a different way.

The "go write a book instead" response is usually provoked by the fact that a game's attempt at storytelling disrupts the flow of the game. The most common example of this is when you need to watch some lengthy cutscene before you can continue playing. Problems also arise when juxtaposing gameplay and story gives rise to ridiculous inconsistencies, such as characters that can take hundreds of hits in-game being easily hurt in a cutscene. But this isn't evidence of stories being inherently unsuitable for games, these are just examples of sloppy implementation.

Stories are, in fact, crucial for videogames, and this has been the case almost since the earliest days of gaming history. They provide something vital to the experience: context. You can clearly see this in cabinets of early arcade machines, for instance this one for Asteroids:

The images are there to tell the player: "Those badly drawn circles coming at you are asteroids! Deal with them or perish!" This may be a really simplistic story, but it certainly is one. It gives the player a mental model of what is taking place on the screen, which allows them to intuit the workings of the world and to build a personal narrative. "I barely escaped getting crushed by an incoming asteroid!" is a much more interesting fantasy than simply thinking about the game in abstract. "I made the arrow-shape move out of the way for the incoming polygon thereby avoiding the game's fail state" doesn't come as naturally to us. In fact, it's quite hard to think of events in that manner. Take a look at this video:

You instantly think of the shapes as having intentions and personalities. Our brains are wired to do so, and the cabinet art of Asteroids taps into that. It also raises an interesting question: if humans are so prone to see stories in abstract shapes, do we really need any actual story content at all? This might seem a tempting conclusion, but there are a number of reasons it's misguided. For example:
  • It provides the player with an idea of what the game is about before they even start playing. Explaining Asteroids using abstract systems is non-trivial. Saying "you control a spaceship that has to avoid or blow up incoming asteroids" makes immediate sense.
  • It puts the player in the proper mindset from the get-go. This way we don't have to wait for a bunch of gameplay to unfold in order for the player to shape a suitable fantasy for it.
  • The fantasy is more likely to be coherent with the actual gameplay. If you just leave everything to the player's imagination, there may be later aspects of the game that contradict this, causing big problems as the player's mental model would contradict the concrete implementation of the game's systems.
  • While people are good at constructing fantasies it doesn't mean they don't need any help. Story-based context acts as a very potent catalyst for the player's inherent capabilities. If delivered properly, the result is a much deeper fantasy than the player could have made up on their own.
However this doesn't mean that you need to fill in all the blanks with story context. In fact, by leaving certain bits to the player's imagination the result can be even better. The trick is to know which parts to leave blank and which ones to fill in.[1]

It isn't just shooters with basic polygonal graphics that benefit from story context. Even adventure games, known for their strong story focus from the get-go, have similar roots to that of Asteroids. The first adventure game, Colossal Cave Adventure, started out as a simulation of a cave. In order to make the experience more interesting, Dungeons-and-Dragons-inspired events and puzzles were added to the mix. Again, the story was there to provide context to the basic experience - in this case exploring a cave system. Instead of just randomly wandering through a cave the player was now on a mission to search for a treasure and to avoid dangers that lurked in the darkness. This not only makes the experience more engaging, it also makes it easier to understand.

The case I want to make is that stories are incredibly potent for setting up play. Story is not just optional window dressing. By telling the player a story it makes it much easier for the player to engage. We as humans also grasp problems a lot more easily when they are presented as a narrative [2]. It enables us to use various built-in mental faculties to approach the problems and to figure out solutions. Understanding the dynamics of two factions that are at war comes naturally to us. When you pose the same problem in the form of mathematical equations it might require years of study to grasp the basic concepts involved. Human relationships come naturally, maths doesn't. This makes story context an indispensable part of game design.

Asteroids can get away with a really simple story because it is such a simple game. But games haven't stayed that simple, and as they grew more complicated, the story context needed to become more complicated as well. If you want the player to play as a spy infiltrating an evil organisation, simple polygons and cabinet art will not be enough. You need to add more details to your story context in order for the game's actions to make sense, be engaging, and easy to grasp.

Story isn't just something that has been slapped onto games because videogame designers have hidden desires to be film directors or novel authors instead. They are there there because they are crucial to the end experience. Sure, there are games that have pretty much zero story content - Tetris is a prime example. But these games are also very straightforward and possible to grasp based on very little play time.  The moment you want anything more complicated, story context comes naturally and becomes an ubiquitous part of conveying the game's intentions and forming a coherent experience.

It's similar to how kids play. Give them some sticks and stones and they will instantly use them in some sort of story context. Sure, they could just build stone and stick structures for the inherent enjoyment of it, but it's much more fun to think of them as castles, soldiers and a grand battle taking place. This is inherently human and permeates many more areas than just videogames and child's play. For instance, it's common to show backstories of the athletes before a sporting event in order to make the actual competition more exciting. News reporting also follow a similar pattern. Whatever the area is, the reason for having stories is the same: it provides context that makes the actual activity or content more exciting and relatable.

The idea of stories as context for play is even true for a game like The Walking Dead. In this game the player has little actual gameplay, and most of the time you just sit and watch. However, the hours of cutscenes are really just there to give context to the choices that the player eventually has to make. This might sound a bit weird, but if you think about it from a gameplay perspective it makes a lot of sense. The abstract systems that power the dialog selection wouldn't have much meaning if it weren't for the cutscenes preceding them.

You can even say that The Walking Dead requires the cutscenes for its gameplay to work. The gameplay in this case is simply making selections from a set of options that pop up on the screen. It's quite clear that abstract shapes and some cabinet art will not do the trick here. Your story context must be quite elaborate for the player to intuitively grasp and feel engaged by a simple "select the right option" process.

The same thing is true for games like the recently released What Remains of Edith Finch (which Bogost bases much of his argument around in his article). Much of the content in this game can be seen as the context for the character vignettes that you play from time to time. Without all of the intricate setup that the game has, these playable sections would have been a lot less engaging and harder to understand. In fact, it's actually quite likely that making these vignettes of gameplay was one of the major cornerstones in the game's development process. A similar process was at least true for SOMA. We started the development of it with the intention of making a few distinct scenarios playable. Much of the game was then built around that goal.

So when I say that the cutscenes in The Walking Dead are just context for the choice scenes, I am not just making a silly argument. In many cases, this is really how it works. Obviously, development is by no means this rigid, nor do I think many developers think consciously about it. Reality is always way more messy than theory. But that doesn't mean that this division is untrue. I think it's a really valuable way of looking at gameplay versus story.

It's also really important to note that this doesn't mean that context is just a superfluous aspect of the game experience. The story context can be engaging in its own right, and it is almost always beneficial if it is. But that doesn't take away the fact that the story content is there to provide context for the play. In fact I think it is crucial that we realize this as it clears up a lot of confusion around video game storytelling.
  • Story is not just plot, a sequence of events; it is whatever story content that provide context to the play experience. The setting, characters, themes and so forth all have part in this. In order to create a proper context there may be a need to tell a certain sequence of events, but it is by no means a requirement. This is where storytelling in video games and film/novels/etc. diverge and it is crucial to keep this in mind.
  • When it feels like a game has poor storytelling, it's not the same as it being unnecessary. The question to ask is: "Could there have been a better way to provide story context?". The problem is not that the game tries to focus on its characters, the problem is that the game is bad at providing the necessary context in an efficient and engaging manner.
  • Games are not trying to "tell deeper stories" compared to film or novels. They are trying to provide deeper thematic play. A core part in achieving this is by putting more focus on the story context. This is a very different goal from that of other media and to say "you might as well write a book" is to gravely misunderstand the challenge at hand.
Obviously context and play aren't simply two separate things. Context very often has a big part in influencing what sort of gameplay is best suited to it, and there may even be gameplay created with the sole purpose of influencing a certain bit of context. 

For me the most interesting question at this moment is: when it comes to evolving storytelling in videogames, what is the relationship between context and play? How can we set up context in such a way that it's the play that does the bulk of the actual storytelling?

I think this is a problem in many story-heavy games. There may be a lot of well-told story in them, but it's delivered in the form of cut-scenes, dialog, written notes, and so forth. I don't get to actually play it. This is also where I think seeing story as context comes as handy. It makes it evident that "classical story" in games is not an end goal in itself, but a framework, there in order to enhance the experience of play. To be better at understanding how this works and how to build experiences around it is where I see the future of interactive storytelling.

[1] I will go deeper into this in a future blog post.
[2] Here is a really good example of this.

Friday, 28 April 2017

Mental Models

The reality that we sense in front of us is a fiction created by our brains. A host of modules process information in various ways and the end result is a mental model of the outside world. Knowing how this works is crucial to game development as the shape of these mental simulations has a huge effect on how a game feels and plays.

Look around the room or the place you are currently in. It certainly feels like what you are seeing is really there, right? However, that's not really the case. Reality is in fact made up by subatomic particles that constantly exchange various force particles amongst each other [1]. What you think of as a chair is really just a collection of particles that happen to form a temporarily semi-stable configuration. The reason why you see it as a chair only has to do with how your brain chooses to process the various data that it collects through its senses.

In the previous post on presence I mentioned how the brain is made up of modules, each of them having their own specific purpose. The results from these various modules are then used to form a collective image of your surroundings. For instance, there is a particular module that recognizes faces and, if damaged, it can no longer recognize people - the person affected will only see an object made up of some hair, a nose, two eyes and so forth. Recognizing individual people will only be possible if they have a particularly stand-out feature, like a large beard. Apart from that, all faces will look alike to this person. The normal flow of information is broken and something that most of us take for granted, an intrinsic part of our reality, is no longer present.

This is an extremely important point and it's essential to fully grasp it. It's not as if people who lose the ability to see faces still really see faces but don't "recognize" them. This is the good old "homunculus in the head" fallacy. When you look at the world around you, you are not really seeing details. You are being fed a stream of information and that stream contains things like "that is a chair", "the chair is made of wood", "that is the face of your mother", and so on. If the brain module that does the processing needed for a particular piece of information is damaged, it's not like your "mental view" remains the same - information is what your mental view is made up from. To get a better idea of this, look at this image:

When first looking at it, most people see this image as simply a collection of dots. But if you look carefully for a bit you will see the form of a dog appearing. Once you have managed to spot this dog, it becomes impossible to unsee. Your brain has gone from interpreting the image as a collection of dots to seeing it as a dog. If you were to lose a brain module this process would be reversed. What was once an image of a dog would turn into a collection of dots. The dog would not still "be there" - it would be erased from your perception of reality.

Your view of reality is not what reality is like, it is a mental simulation based on interpretations of data collected by your senses. You are really living your life in a sort of virtual world that the brain constructs for you [2].

This doesn't mean that your view of reality is a complete lie, though. It is still based on things that do exist and is a crucial tool for getting around and being able to make decisions. Even though a chair is a made up concept with no basis in reality, it still is very useful. It tells you something about what to expect and what your options are. For instance, if you are presented with either sitting down on a chair or on a pile of broken glass, your mental simulations are invaluable and can quickly give you pretty accurate estimates of what sitting down on each of the alternatives would mean. Note that these mental simulations are not confined to a single aspect of an object. There are things like shape, materials, current light conditions, the physical dimensions, emotional attachment, ownership and many other things that are all connected to an object. When you focus your gaze on an object, that is what you "see" - not some crystal clear pixel-by-pixel representation.

This array of properties is not always correct, though. For instance, if you try and pick up a carton of milk that your brain has modeled as filled (=heavy) and it turns out to be empty (=light), you will lift it with way too much force. But most of the time, because of the practice you've had at experiencing reality, your brain is pretty good at providing a good simulation.

Contra (1987)

Let's move on to games. When you are playing a game, you are not playing the game that is presented on the screen. You are playing the game that you are currently modelling in your mind. The brain turns clusters of pixels into abstract icons (eg "a power-up") and then attaches all sort of concepts to them. Just in the same way as it does when you encounter a chair in real-life. The modules in your brain use pre-existing knowledge and experience from interacting with the game and build up a mental model of how it is all connected.

The best example I know of this is from Brian Upton's book "The Aesthetics of Play". In the book he presents the example of navigating an environment in a game. What doesn't happen is that the player bumps into every wall and object, trying to figure out the bounds of the simulation. Instead the player analyses the scene in front of them and then mentally figures out a path to follow. This means that there is a lot of gameplay that takes place inside the player's head. In fact, unless the player is actively trying to test the systemic bounds of the game, almost all gameplay happens within the player's mental simulation of the game.

What all of this means is that is that we should be less concerned about the data (images, sounds, etc) that we send to our players and focus more on the sorts of mental simulations it gives rise to. This is an extremely important aspect of game making, and it has far-reaching consequences. No matter how much more realistically you render an object, it doesn't matter if the player's mental model chooses to represent it as something else.

The mental model is closely linked to our ability to anticipate. This is something that happens in all kinds of media [3]. For instance when watching a film and a character steps on a banana peel, we predict that they will slip and fall. As we see the foot approaching the banana our brain is already simulating possible outcomes and various filmic tricks, such as editing, are based around this happening in our minds. All mediums rely on this, but creating anticipation in games is extra tricky because of interaction.

In order for us to work with this we need to learn how these mental models are formed. There are three basic ways in which this happens: by using built-in knowledge, extrapolating from past experiences or learning through experimentation. These three modes complement one another, but it is useful to start by looking at them one at a time.

Built-in Knowledge
This is what our brains come equipped to deal with when we are born. They're essential to a human and you can pretty much assume that anyone playing the game will have them. Basic things like shape, lighting, perspective and so forth are all part of this category. It also includes behaviors like how pouring the content of a large glass into a smaller one will cause it to overflow, rotation of 3D shapes and how objects ought to act if you drop them. Social things like facial expressions are also part of this sort of knowledge. The facial expression connected to disgust is universal, hardwired, and does not depend on mimicking.

The one thing you need to realize about any built-in knowledge is that it's extremely hard to break. It takes a lot of effort to convince a person that dropping a ball will make it fall upwards. It is basically impossible to make a person intuitively see a mad face as a positive response. This is all hardwired knowledge that comes with equally interesting pros and cons.

If you can tie some basic functionality of your game directly to some built-in knowledge then it will instantly come off as intuitive to any player. For instance, if you want the player to feel disgusted by an enemy it's good to know that disgust is a disease-avoiding behavior. This knowledge allows you to trigger built in responses and also suggest what sort of events and interactions will strengthen a mental model that gives rise to feelings of disgust.

On the contrary, if your gameplay relies on something that goes against built-in knowledge, you either need to be prepared to spend a lot of time building the proper mental model or to ditch the concept altogether. Sometimes it is of course OK to break the rules, but remember that conforming to built-in knowledge is what makes a world seem believable. And if you want to focus on evoking basic human emotions, this basic believability is crucial. Without that you also lose a bunch of connections which are foundational to our emotional world.

Past Experiences
This is a huge area and it includes everything the player has learned throughout life. It is also something that can vary culturally. What I will focus on right now are two parts of this: past experiences with games versus past experiences with real life.

When you are first presented with a scene in the game there is a ton of stuff for you to process. If you see a red barrel and you have played games in the past, there is a big chance that you will think the barrel will explode when being shot upon. This interpretation relies on more than simply having encountered this specific object before. It relies heavily on what sort of game you are playing (point and click behaves differently from a quake-like shooter), what actions you think are possible (can you shoot it?), and so forth. So players come in with a lot of expectations and preconceptions on how things ought to behave. All of these will not just change how the player feel about the game, they will directly affect how the player think the game actually is like.

A monster can either be a horrible threat that you wanna keep away from, or it can be the source of what makes the game fun in the first place. The view the player takes directly affects how they behave and also has a long reaching effect on the experience of playing the game. For instance, in our game Penumbra the player has the ability to use weapons but they are very weak and inefficient. For players that interpreted the game as one where you'd best avoid any monsters, this worked great and they used the weapons as a last desperate effort to escape - as we had intended. Their mental model was one where the weapons and monsters were just like in real life. For other players the game was interpreted as a one where you could fight back. For these players it didn't work at all. The weapons felt frustrating to use and the monster was an annoyance. Their mental model was based on how videogames usually work. Despite interacting with the same system, seeing the same visuals and hearing the same sound, these two types of players experienced radically different games.[4]

To combat this in Amnesia: The Dark Descent we started the game with a quick notice on how the game was supposed to be played. This, together with other design changes of course, made a huge difference in how players approach the game. Unlike built-in knowledge, things learned from past events are quite malleable and it is possible to adapt them according to new situations. Which leads us to the final foundational way in which mental models are formed.

From the moment we are born (and possibly even earlier) our brains are hardwired to analyze, generalize and make assumptions. Whenever we encounter a new object we try it out in a variety of ways (squeezing, chewing, throwing, etc) in order to figure out what it is like. We then store that information and pull it out whenever we encounter a similar object. Everyone who has been near a small child knows about this process, and so does everyone who has played an unfamiliar game.

As noted before, the moment we see a scene from a new game, we make a whole load of assumptions of what everything is like and how it functions. But it is not until we get to interact with the scene that our assumptions get confirmation and are cemented. Unless the game is similar to another game we've already played, we know that we have new lessons to learn. These first impressions are crucial to how the rest of our experience is shaped [5]. This is why the opening of a game is so important. If a player gets the wrong idea about something it can be really hard to get rid of that faulty mental model.

Once the player interacts with something it will tell them about some aspect of the object. For instance, if they can pick it up or not. The player will then try to generalize this knowledge, often by using pre-existing information. So if a glass bottle can be picked up, they will assume that it's possible to pick up plastic bottles as well. Furthermore, if you throw a glass bottle and it breaks, it means the player will assume that everything made of glass is breakable. And so the experimentation continues as the game is played. Every new aspect is connected to other things the player already knows and an increasingly detailed mental simulation is built. The next time the player finds a bottle lying around,  a lot of attributes will be assumed the moment it comes into view.


The basic gist of the above shouldn't be too surprising, as it's pretty basic stuff. But the key thing to remember here is that these are not just things that form opinions. They form actual reality for the player.

To be able to look at an object and assume a bunch of attributes is what makes the world feel alive. It allows the player to use their hardwired brain faculties to explore, interact and make plans. The world might be rendered using toon shaders and feature talking rabbits, but if it allows for a rich mental model it will feel "real". Remember, it isn't about the objective facts of what you see (eg a teapot using highly realistic PBR-based shading), but what processing it gives rise to.

In order to make this happen, you can't just put objects and interactions into a world at random. The player must be able to explore the elements of the world, and in doing so they must be met by a consistent set of rules. The brain doesn't have an infinite amount of resources, and will therefore optimize when possible.

So if an object looks like something found in the real world, but you are unable to interact with it, it will not be given any further attributes. As it isn't of any importance, it will simply become part of the background. In a similar vein, the simplest explanation will also be used when possible. If there are ten keys lying on a table, but only the one that unlocks the door can be picked up, then players will stop modeling these objects as any sort of real keys. They will instead be seen as quest items, possible to pick up when it is convenient for the designer. When there's no consistency of any sort, the player's brain will just skip trying to do any modeling and rely on direct experimentation when needed (trial and error, basically). In these cases, players will have a very fuzzy mental model of an object and the object won't feel very "real".

An important aspect of this is that it's not always a bad thing that the brain optimizes away things. For instance, if you are making a simple shooter you don't really need to take any wall ornaments into account. You should just focus on the overall layout and the positions of the monsters. Everything else is a distraction.

It is, however, crucial to keep all of this in mind. There may be many cases where you don't want the player to optimize away certain objects. If you want the player to feel like the environment is a real place, you really need to make sure that as many details as possible can have intricate attributes in the player's mental simulation. It becomes even more important for characters where you want the player to model internal emotions, needs and goals. If your goal is to make the player feel like they are encountering real people, you want those people to be part of their mental model. This is what it means to make something feel real and alive.

All of this doesn't mean that one's goal should be to model everything in as detailed a way as possible. In fact, in many cases this may be counterproductive. Details could mean the player makes more assumptions, leading to the structure being more fragile and more likely to crumble. Keep in mind that all we want to worry about is the end result - how the player perceives the experience. The actual content - images, sounds and so on - that we send to the player is just a means to an end.

It's at this point where narrative-focused games become very different from classical ones. In a classical videogame, it's almost always a good thing for the player to learn the systems exactly as they are. The better the player understands how all the underlying mechanics work together, the more competently they can play the game and the more fun they will have. Narrative-focused games are different. Here we often want to suggest a lot more than what is in the systems that we have at our direct disposal. Pulling this off requires a collection of tricks where the common thread is to try and make the player do the hard work. I will go over these tricks in future blog posts.

Next week there will be a discussion on how systems and story come together to form a mental model and more discussions on the most common pitfalls and opportunities when designing for mental simulations that feel alive.

Foot notes:
[1] It is actually much more complicated than this as your current reality is a sort of vertical slice of a much later Hilbert space where everything is modeled as waveforms.

[2] And even the idea of a "you" is a mental construct. Check the previous blog on presence for some discussion on this.

[3] Brian Upton goes very in-depth into this area in his book.

[4] The game was not this evenly divided into groups, but the general gist was this kind of behavior.

[5] There are a lot of psychological reasons for this such as the ultimate attribution error and anchoring.

Friday, 21 April 2017

Creations inspired by Frictional Games

Last week we announced a competition on Facebook and Twitter, asking our community to share their creations inspired by our games. We knew that there was a whole load of art, mods and just plain crazy stuff out there, and we're really happy to have seen many of them which we might otherwise have missed.

Today we're announcing the four winners, who will each receive a Tobii Eye Tracker 4C, courtesy of Tobii Gaming. They've helped us make SOMA even more immersive on PC by enabling eye tracking - see how it works here. Each winner will also get a copy of SOMA on Steam. We wish you the best of luck as you experience your descent into the depths in a completely new way!

So, drum roll time... here are the four lucky winners!

Best Music
SOMAGE - a 10-track album by exandroid, inspired by SOMA! Just wow. This blows us away, and will be used as a soundtrack when working on our new projects!

Listen and be amazed.

Best Fan Art

hoshiSAM posted this piece on Twitter, showing how much baggage Simon needs to carry...

Best Mod
Mods make us extra happy! But they're really hard to choose between. Two mods ended up with the same number of votes from our staff, but luckily they were both sent in by Draugemalf

Best Random Thing
The final winner is someone who did something both irresponsible and amazing - and shed some blood for us! Jonathan showed off this incredible tattoo, which makes him worthy of the final prize.

Congratulations to all winners, and thanks so much to everyone who took part! We'd love to see more of what you're doing!

Thursday, 20 April 2017

Evoking Presence

Playing a videogame can put you in a state where the borders between your self and the character gets blurry. This is one of the major differences that sets games apart from other mediums such as films and literature. When creating games, evoking this feeling of presence is worth trying to achieve. 

Before starting on the concept of presence, I need to discuss why it's so important to dig deeper into these aspects of games. This is not really needed in order to explain presence, but I think it is vital to know why it is so crucial to gain this deeper understanding.

I have talked about the concept of an "idea space" and how developing a game is basically about navigating this space. The most important concept that I want to get across is that developing a game is like going on a journey. You have a starting point and an idea of where you want to end up. When making a narrative game, having a clear focus on the goal is extremely important as there'll be many occasions when you need to go against what has the greatest gameplay benefit in the short term in order to reach a better end result. But given that you can't choose your next step based on what gives the largest boost to "fun", what do you base your decision on? How can you achieve a high degree of certainty that you've made the right choice?

You do this by having rules and principles that you follow. A simple example of such a principle is to ensure that gameplay makes sense within the story. It might be more "fun" from a short-term perspective to give the player a flying unicorn, but if that seems silly within the story then this is a bad decision. However, it's not always that clear-cut, and since you can't simply "follow the fun" you need other things to guide you.

Evoking the feeling of presence is such a principle.

So what exactly is presence? Well, it isn't the most well-defined term, but for our needs we can define it as something like "How much the player feels like they are present inside the game's virtual world". One way to measure this is to test the player's unconscious reflexes and see if these react to events in the game. For instance, does the player flinch if an object comes flying towards the screen? It's simple, but not the only way to measure presence. A more important aspect, in my opinion, is to evaluate to what degree the player feels they are their on-screen character. If the player views an in-game threat as something that is bad for them personally, then it means the sense of presence is high.

Silent Hill 2 (2001)

I remember playing Silent Hill 2 with my wife 6 years or so ago. As the intro sequence was over and she headed into the woods, she started to feel quite shaken. She went on for a minute or so and then eventually exclaimed that she couldn't play it any longer. The game was just too scary. So I took over the controller and suddenly she didn't feel as scared any more. I now decided to conduct an experiment and handed her back the controller. The moment she started controlling the main character she got scared, and again refused to play for more than a minute or so. This is quite interesting. Her feelings towards the game were quite different depending on whether or not she was holding the controller.

This is a great example of presence. When my wife held the controller she was no longer just a spectator of a scary narrative, she was the protagonist in a horror world. This sense of presence changed her view of the game drastically, and I believe this is what makes it a core component of creating good interactive storytelling [1]. So, understanding this phenomena is paramount in becoming better at making this sort of games.

To understand what it is that happens here, let us take a look at an experiment.

In order to conduct this experiment you will need a screen, a rubber hand and a hammer. You let your subject place their hand on a table and then place the rubber hand next to it. The screen is placed between the two so that the subject can only see the rubber hand.

You now start to stroke the rubber hand and the subject's real hand in the same place at the same time. Once you have done this for a while the subject will start to feel as if the rubber hand is their own. You can now test this sensation by quickly grabbing the hammer and slamming it on the rubber hand. The subject will now, as an unconscious reflex, pull their real hand out of the way. You can see a video of it all in action here:

This is quite astounding. By just using some very simple manipulation you are able to change a person's mind in such a way that they think of a rubber hand as their own. You don't even have to use a hammer to test it. You can even threaten the rubber hand with a knife and see that the galvanic skin response (palm sweat basically) is the same as if it was the real hand that was threatened. There has really been a change in how a person perceives their body.

A bunch of similar experiments have been made by Henrik Ehrsson, above, who has managed to get people to have out of body experiences, by putting them in the bodies of mannequins and using very similar techniques to the ones explained earlier.

So why does this happen? In order to understand this you first have to understand a bit of how the brain works.

It is common to intuitively think that inside our heads sits a little man, a homunculus, who receives all of the input picked up by our eyes, ears and other sensory organs. When you start pondering this idea, it's obvious it's not the case - it just begs the question of how the little man is able to see, and you end up in an infinite regression. What actually happens is that there are a bunch of different modules in your brain that collect and process various data. This data is then sent onward for more processing or used as a means for decision making. There is no one thing that controls the brain. It's all controlled by a bunch of different computational systems, each receiving different input and being able to give certain output. Marvin Minsky's "society of mind" is a very good description of how it all works.

So what happens in the rubber hand illusion is that the input you get from your eyes overrides the kinesthetic sense. There is a sort of feedback loop going on between the constant sensation of being stroked, combined with the visual confirmation of seeing it being stroked. This provides a slight conflict with the kinesthetic sense, but the brain has to make a decision and decides to treat the hand as actually being the rubber hand.

Your sense of self is not set in stone. It's something that is highly malleable and is under constant evaluation. At any moment, the brain relies on the information that it has available in order to form the concept of your self. The entity that you refer to as "yourself" is really just a mental construct that's useful in making sense of the world, navigating it, and taking decisions. Most of the time it's fairly accurate and gives the right picture, but as we've seen, it's not always the case. It can be hacked.

This is where games enter the stage - because this sort of self-hacking is exactly what games do. When your current mental model of your self incorporates your in-game character, an approaching monster will make you feel afraid. This is extremely powerful and something that makes games very special. When you press down the button or stick that makes the player move forward, you instantly get confirmation that you are making a character move. Volition turned into action becomes a feedback loop and this causes your brain to change its view of your self.

In books and movies there is no such feedback loop. Information is only presented to you. In these media you are a spectator that watches as events unfold. But in a game you are an active participant who causes events and where things happen to you personally.

This is what presence is all about! And for me this is the core reason why interactive storytelling is so exciting. You are no longer just a passive audience but an active and present participant in the narrative. Being able to achieve a strong presence is a fundamental building block in an interactive narrative.

So does this mean that Virtual Reality is the ultimate device for doing interactive storytelling? Well, it is true that VR has a lot of potential to create presence. For one, it adds two senses, balance and peripheral vision, to the mix, It also allows a natural feedback loop to occur by looking and seeing the view move about. There is no denying that VR does things that games on your standard TV or monitor cannot. However, what is crucial with presence in games is what sort of activities it allows you to be present in. VR can increase the sense of presence when it comes to just standing and looking around. But I am not as convinced that VR will be as suitable for more complex narrative actions. For instance, a drawback of VR is that the game can't really seize control of the camera - something that allows many games to provide contextual animations. This and other tricks are things that are effective in making the player feel present in story events. We used this a lot in SOMA in order to give philosophically complex events, such as the body swap, a more visceral feel.

Obviously if you use the VR medium to its advantage you can elicit responses that wouldn't be possible otherwise. But what it all comes down to is that different mediums can do different things well, and that it's not a case for VR always being better at conveying presence.

I am not bringing this up to be dismissive of Virtual Reality - I think it's a very exciting field. I go over this in order to make it clear that a sense of presence is not just about recreating our normal way of being as accurately as possible. Ways to convey presence can take many forms, but what they all have in common is that they hack our brain into believing it's partaking in something it's not.

This also answers the common question whether or not a first person mode is better at generating presence: sometimes it is, and sometimes it isn't. Sure, we normally see our lives from where our eyes are situated. But this is really just a helpful mental model. Remember, there is no small man in your head that is witnessing everything. It is all just modules that process information in various ways. If it wanted to, your brain could construct your sense of reality from a third person perspective. This is in fact what happens during out of body experiences. The reason we don't use this version during everyday life is because it is not the most optimal one. We cannot see everything that happens around us, and therefore it makes more sense to just let vision be modelled as if seen through the front of our face.

So really, the output from a game is just a stream of data that gets injected into our brains. The brain will then process the data and model the world accordingly. A third person viewpoint is just another way to be presented with that data. Sometimes it can be advantageous compared to a first person one - for instance when showing damage to the protagonist. This is something we normally get as a signal of pain, but as that is not possible [2] in a game, you can trick the brain by having the onscreen character limp and show big disgusting wounds on their legs. So again, it all comes down to different approaches being suited for different things.

So the sense of presence is a brain hack, and it can be done in different ways. Then what exactly are these different ways?

I will now go over a few basic principles that will help you maximize your sense of presence. There is a lot more to be said about these, but right now I'll just summarize the most important aspects. I'll go over each of these in more detail in another blog post later on.

Intuitive controls
The most important principle is to make sure that the controls can't be overly complicated. What we want to achieve is a feedback loop where the player thinks of something and then sees it happening. We want to make a connection between the onscreen character and the player by connecting volition with action. This won't happen if the player is too focused on pressing specific buttons.

In order to achieve a strong sense of presence, the controls need to be established as early as possible and be used for all future actions. Every time the player has to learn new ways to control their character, or has to look down on the controller to make sure they are doing an input correctly, the feedback loop is broken and presence is weakened.

A good example of a game doing this correctly is Limbo (and the more recent Inside). The player is taught the controls during the very first minutes of gameplay, and from then no new controls are needed. Instead the existing control scheme is used in intuitive ways to provide many different sorts of actions. This makes the player-protagonist connection very strong and I think it is one of the game's big success factors.

Constant Feedback
Once you have the player-protagonist feedback loop up and running it is important to keep it up. If the player just sits with the controller in their lap watching as things happen, the feedback loop will be broken and their self will no longer be extended. So it is important to keep the player busy. It is especially good if you also make sure the input has a good correlation with the movements that you are doing. For instance, moving the mouse to look around creates a nice feedback loop, but if you just press a button in order to accomplish a complex manoeuvre you will not feel as present.

Experiments show this clearly. As soon as you stop stroking that rubber hand the illusion start fading away.

This is one of the reasons why we have the physical interaction in Amnesia. Not only does it allow for some interesting analog actions (such as peeking out from a closet), it also makes sure that the players are feeling a sense of presence as they open the door, pulling a lever and so forth.

In order to hack our brains there needs to be a good pattern to follow. The key feedback loop has to do with desiring something and then seeing it happen. But in order for this to actually work, the thing that you want to happen must actually happen. If you press the jump button and the character doesn't jump then there is not a connection any more. In fact, this becomes a negative stream of data to the brain which brings about the conviction that you are in fact not controlling the on screen character. The same rule also applies to interactions. The player will base their actions upon what they are currently seeing and what they know about the world. And if that set of beliefs is not accurate, then the player's volition will fail.

This doesn't just apply to actions that you input, but also to those where you don't. It is really annoying if the character does some movement without you having provided any input for it. A game that does this the right way is Assasin's Creed. Here the player's character jumps without the player providing input, but it feels good because you press down on a button as it happens (hence willing the action) and jumping is sensible and handled in a consistent manner. Presence is maintained. However, the game also fails miserably at times and the characters can start jumping when you really just wanna walk close to a wall. In these cases the sense of presence is severely weakened.

Finally, it also very important that things feel real. By this I don't mean that things should be photorealistic. But it is good if things happen according to how they are anticipated to happen, and that forms take a shape that make sense to us. In that way, the brain can more easily process the data using existing methods. For instance, presence works better when your character is walking like a normal human and not running around like some freak (as is the case in games like good ol' Doom). In the same way it's positive if as many of the actions as possible feel close to the ones we experience in everyday life.

Experiments can clearly express this by showing that it is much harder to make the subject feel as if the table belongs to them, than it is with the rubber hand. However, a super detailed hand doesn't matter as much. The most important aspect is that it looks pretty close to a real hand.

Exactly what sort of level of realism required is hard to say. A good thumb of rule is that you should try and have enough room for the brain to fill out the details. If you go with overly photorealistic there will be too much focus on that, and you'll end up with a problem similar to the uncanny valley [3].


Back to where I started. Now we have four new principles that we can follow in order to navigate the space of ideas. So instead of just trying to go with ideas that give us the most fun gameplay, we can instead try and get as much presence as possible. What is good about having principles like these is that we don't have to be able to directly playtest the amount of presence added, we can instead just rely on making sure the game fulfils the requirements for creating lots of presence.

Obviously you'll need to test at some point. A principle is not an absolute truth. But it allows you to plan further ahead and gives you more confidence to tread into uncharted territory. If you can see that a certain path through idea space means that the underlying goals of evoking presence is met, then that's a good indicator you're moving in the right direction. Of course, presence is not the only thing you need to work on, but it's a fundamental part of creating an engaging narrative experience. If your game is going in a direction where the principles are not met, then you might be undermining any other features intended to accomplish interactive storytelling

That's it for now on presence. There are more details to be explored, but those will be brought up in later blog posts. Next week, I will be going over something called the Mental Model. This will go deeper into how we as humans create a virtual representation of both our selves and the world, and how this can be exploited for making better narrative games.

[1] This is how I see it and where I personally want to take games. There are other ways to approach digital storytelling. For instance, you can see the player's role as someone who controls how the plot and pacing flows, and so forth. There is really no best way of doing it. But in order to get somewhere I need to take a stance, and games that puts the player in the shoes of another character are the ones that I find most interesting. Therefore, this is the direction that I want to explore. People who feel otherwise are welcome and encouraged to follow other paths.

[2] At least not without special equipment and not being afraid of a painful gaming experience.

[3] This is a huge subject and very interesting, but will have to cover it in a future blog post.