I’m Max, and I do gameplay programming and design. I joined Frictional about a year and a half ago, and I’ve been working on one of our super secret projects since.
Yours truly.
For the first nine months or so I, like everyone else, worked from home. Last summer we got an office set up in the heart of Malmö. Since then the amount of days I spend working from home has reduced greatly, though I still do it from time to time.
Setup at home and at work.
These are my two workspaces, the first one in the office and the other one at home (which is rather bare bones right now, moved in just a couple of days ago!). They’re quite similar; both the computers and the chairs are the same kind. I wanted to be even more consistent and get the same type of desk as the office one at home, a decision that was ultimately overruled by my better half (apparently it doesn’t go with the rest of the decor).
Background
Games have always been a big part of my life. Most of my time growing up was spent either playing games or talking about games. But, for quite a while, my family didn’t have a PC. Which meant I was stuck playing all sorts of old, weird games on rapidly aging Apple computers. One of my earliest gaming memories consist of repeatedly failing at air-hockey, losing to a hideous pig-man in Shufflepuck Cafe on my dad’s old Macintosh.
Eventually I scraped together enough money to put together my first PC, in front of which I would stay rooted for the following years. In addition to playing, I spent a lot of time creating custom content for games with my friends. It was always quite basic though, as I hadn’t learned any programming yet.
For a year or so I studied film and media studies at the university, with a diffuse goal of wanting to work in games down the line. One night my girlfriend gave me a push, and I applied for a three-year game development program at Blekinge Institute of Technology (BTH).
My years at BTH were a mixed bag. On one hand, we had a lot of freedom and got to work on tons of small projects, which was very fun and super rewarding. On the other hand, some courses felt like they were only marginally related to game development. Working on side-projects during your spare time was crucial. I got through it all by finding a good group of like-minded students that I stuck to for the entirety of the education. Our final project was a side-scrolling adventure game called Far Away – you can watch the trailer for it on Youtube.
Perfectly in sync with graduating, I stumbled across a job opening at Frictional and sent in an application. Over the following weeks I answered some additional questions, did a work test and finally had an interview. A couple of days before I would hear from Frictional, I got a job offer from another company in software development. I clumsily explained to them I was waiting on another offer and asked for a few more days. Finally, I got an email from Fredrik and Thomas offering me the job. It was a no-brainer, and I happily accepted.
What I do
My first few weeks at the company consisted of completing a list of introductory tasks, to learn more about the tools and the engine. This was a lot of fun, and culminated in the creation of a silly mini-game where I got to put everything I had learned to the test.
After I had completed the introductory tasks I got to work on Safe Mode for SOMA, which was something I was really excited about — contributing to a game I truly thought was great. From the get-go, we felt it was important to maintain the monsters’ threatening presence in order for their new behaviours to gel with the overall tone of the game. We couldn’t just disable their ability to harm you; doing this would end up breaking immersion (imagine repeatedly throwing a toolbox in Akers’ face and him just standing there, taking it). Instead, we tried to focus on how to best tweak each monster’s behaviour in a manner that suited that particular encounter. For instance, some might eerily walk up to you and size you up, and can even bluff charge you if you’ve strayed too close. To further enforce the behaviours fitting with the world, we decided that if you were to actively mess with monsters (like invading their personal space for too long, hurling trash at them and so on), they should still be able to hurt you, just not kill you. Overall it was a very worthwhile experience, and I’m quite happy with how it all turned out.
Now I’m working on one of our secret projects. As the gameplay programmer/designer workflow has already been described in previous posts I won’t go into detail, but my days in general are spent designing and scripting events and scenes, as well as programming gameplay systems.
The office
Additionally, I thought I’d talk a bit about the differences in working from home compared to working in the office. We’re also gonna do a proper office tour later on, so stay tuned!
This is where the magic happens.
This is our office! Currently, we’re around seven people occupying this space, probably with more to come. It’s quite seldom all of us are here at once though, but there are usually a few people around. And on the off chance that you’re here by yourself one day, fear not; there’s always the noisy, seemingly stiletto heel-wearing, tap-dancing travel agency crew upstairs to keep you company (seriously).
So, it really isn’t all that crowded here. But, seeing as most of us don’t work from the office, we often have meetings over Slack. It can easily get annoying for your desk-mates if you keep babbling on and on in various meetings throughout the day, which is why we’ve set up a separate meeting room. It also moonlights as a test room, complete with a TV, some dev kits and a monster webcam.
The fact that the company is split into people working from home and people working in the office could potentially lead to complications, such as communication issues. In order to prevent this we’ve made sure that all important decisions and discussions still happen over Slack, to keep everyone in the loop. So far this policy has worked well, and the transition has been quite smooth.
In the end, a typical day of work in the office is very similar to one at home. There is of course the added social aspect of working in the same physical space as you colleagues, which is great, but if you one morning feel like you’d rather stay at home and work, you can. Having this option every day really is quite luxurious.
Other than this, and the requirement to wear pants, the routines of working in the office and and working from home differ very little.
Some links in this article have expired and have been removed.
On the last day of the cold January Will from Extra Credits sat down to stream SOMA, and for the first few hours of the game he was joined by his friend and Frictional employee Ian Thomas. Ian worked on scripting, coding, and level design for SOMA, and is now the Story Lead on one of Frictional’s two upcoming projects. During the stream he answered some questions from the viewers, ranging from what type of pizza he thinks Simon had in his fridge, to ways of minimising dissonance between the player and the character in a narrative game.
In this blog we’ve compiled the best questions and answers into an easily readable form. So go get a beverage of your choice and dive into the everyday life at Frictional, narrative game design and tips on networking in the industry! Or, if you’re not the reading type, you can also watch the whole video on Twitch.
Have some other questions? Hit us up on Twitter and we will try to answer the best we can!
(Picture commentary from your favourite community manager/editor of this blog, Kira.)
Q: Does the Frictional team scare each other at the office?
We didn’t have an office until recently, and even now most people are still remote, so not really!
The thing about being behind the scenes in horror is that it’s very difficult to scare yourself, and each other, because you know what’s going on. We do play each others’ levels every other week, and it’s always brilliant to get a decent scare out of a coworker.
Otherwise we don’t hide in the office cupboards or anything like that… regularly.
Q: Is it true that developers don’t actually play their games?
No – we play our games thousands of times, and most developers do!
It does depend on where you sit in the development chain. If you work for a very big company and only do something like facial models, you might rarely play the game until it’s close to completion. But in a team the size of Frictional everyone plays the game all the time. That’s how we get our primary feedback and develop our levels before the game goes anywhere near alpha testers.
Q: How about after they’re released?
Probably not that often. For me personally there are two reasons, which both have to do with time. Firstly, I’m probably already working on a new thing. Secondly, during the short downtime after a release I’m trying to catch up on games I had to put aside during development. But it depends: for example, when I worked on LEGO games I would later play them with friends, because they’re so much fun to sit down and co-op play.
For a couple of years after the release you might be fed up with your game and not want to see it, but then you might come back to it fresh. With SOMA I sometimes tune into livestreams, especially if I’m feeling down. That’s one of the kicks you get out of this stuff – knowing which parts of the game people are going to react to, and getting to watch those reactions! That’s the best payoff.
Q: Did the existential dread of SOMA ever get to the team?
It’s a little different for the dev team, as the horror is a slow burn of months and months, whereas for the players it comes in a short burst. The philosophical questions affected people in different ways, but I don’t think we broke anyone. As far as I know we’re all fine, but given that a lot of us work remotely, it could well be that one of us is deep in Northern Sweden inscribing magical circles in his front room and we just don’t know…
Q: Why did SOMA get a Safe Mode?
SOMA was originally released with monsters that could kill you, and that put off some people that were attracted to the themes, the sci-fi and the philosophy, because they saw the game as too scary or too difficult. Thomas and Jens had discussed a possible safe mode early on, but weren’t sure it would work. However, after the game came out, someone in the community released the Wuss Mod that removed the monsters, and that and the general interest in the themes of the game made us rethink. So now we’ve released the official Safe Mode, where the monsters still attack you, but only if you provoke them – and even then they won’t kill you.
You can now avoid one of these three death screens!
The concept of death in games is a strange one. All it really means is that you go back to a checkpoint, or reload, and all the tension that’s built up goes away. The fact is that game death is pretty dull. It becomes much more interesting when it’s a part of a mechanic or of the story. We at Frictional have talked about it internally for a while, but it’s something we’ve never really gotten a satisfactory answer to.
So, all in all, even if you turn on Safe Mode, it’s not that much different from playing the game normally.
Q: What type of pizza does Simon have in his fridge?
Meat lovers’, definitely.
Schrödinger’s pizza! And a Mexicana. Unless they mixed it up at the factory. In which case it’s also a Schrödinger’s pizza.
Q: What was the funniest or hardest bug to fix in SOMA?
There were so many! You can find some of the stuff in the supersecret.rar file that comes with the installation.
I spent a lot of time fixing David Munshi. His animation really didn’t behave and he kept leaping around the place. He was so problematic, especially in this sequence where he was supposed to sit down in a chair and type away at the keyboard. We had so much trouble with that – what if the player had moved the chair? We couldn’t lock it in place, because we want the player to be able to mess with these things. We went around trying to come up with an answer for ages.
And then someone on the team went: “Standing desk!”. Problem solved! It’s silly little things like this which tie up your time.
For all you thirsty Munshi lovers out there. You know who you are.
Another similar element was the Omnitool. It was a fairly major design thing that we came up with to connect the game characters, and to gate scenarios. We were struggling trying to tie these things together, and then it was just one of those days when someone came up with one single idea that solved so many problems. It was a massive design triumph – even if we realised later that the name was a bit Mass Effect!
Q: Why does using items and elements in Frictional’s games mimic real movements?
This is one of Thomas’s core design principles: making actions like opening doors and turning cranks feel like physical actions. It binds you more closely into the game and the character, on an unconscious level. We’ve spent an awful lot of time thinking about ways to collapse the player and the character into one and make the player feel like a part of the world. It’s a subtle way of feedback that you don’t really think about, but it makes you feel like you’re “there”.
There’s an interesting difference between horror games and horror films in this sense. You would think that horror movies are scarier because you’re dragged into the action that moves on rails and there’s nothing you can do about it. But for me that kind of horror is actually less scary than the kind in games, where you have to be the person to push the stick forward.
We try to implement this feedback loop in other elements of the game too, like the sound design. When a character is scared it makes their heartbeat go up, which makes the player scared, which makes their heartbeat go up in turn, and so on.
Q: Why didn’t SOMA reuse enemies?
It obviously would have been much cheaper to reuse the monsters. But in SOMA it was a clear design point, since each of the enemies in SOMA was trying to advance the plot, get across a particular point in the story, or raise a philosophical question. Thus, the enemies were appropriate to a particular space or a piece of plot and it didn’t make sense to reuse them.
Q: Did SOMA start with a finished story, or did it change during development?
The story changed massively over the years. I came on to the game a couple of years into development, and at that time there were lots of fixed points and a general path, but still a lot changed around that. As the game developed, things got cut, they got reorganized, locations changed purpose, and some things just didn’t work out.
Building a narrative game is an ever-changing process. With something like a platformer you can build one level, test the mechanics, then build a hundred more similar levels iterating on and expanding those core mechanics. Whereas in a game like this you might build one level in isolation, but that means you don’t know what the character is feeling based on what they’ve previously experienced.
You don’t really know if the story is going to work until you put several chapters together. That’s why it’s also very difficult to test until most of it is in place. Then it might suddenly not work, so you have to change, drop and add things. There’s quite a lot of reworking in narrative games, just to make sure you get the feel right and that the story makes sense. You’ve probably heard the term “kill your darlings” – and that’s exactly what we had to do.
A lot of the things were taken out before they were anywhere near complete – they were works in progress that were never polished. Thus these elements are not really “cut content”, just rough concepts.
Q: The term “cut content” comes from film, and building a game is closer to architecture or sculpting. Would there be a better name for it?
A pile of leftover bricks in the corner!
Q: How do you construct narrative horror?
Thomas is constantly writing about how the player isn’t playing the actual game, but a mental model they have constructed in their head. A lot of our work goes into trying to create that model in their head and not to break it.
A central idea in our storytelling is that there’s more going on than the player is seeing. As a writer you need to leave gaps and leave out pieces, and let the player make their own mind up about what connects it all together.
You’ll meet a tall, dark stranger…
From a horror point of view there’s danger in over-specifying. Firstly having too many details makes the story too difficult to maintain. And secondly it makes the game lose a lot of its mystery. The more you show things like your monsters, the less scary they become. A classic example of this is the difference between Alien and Aliens. In Alien you just see flashes of the creatures and it freaks you out. In Aliens you see more of them, and it becomes less about fear and more about shooting.
It’s best to sketch things out and leave it up to the player’s imagination to fill in the blanks – because the player’s imagination is the best graphics card we have!
There are a lot of references that the superfans have been able to put together. But there are one or two questions that even we as a team don’t necessarily know the answers to.
Q: How do you keep track of all the story elements?
During the production of SOMA there was an awful lot of timeline stuff going on. Here we have to thank our Mikael Hedberg, Mike, who was the main writer. He was the one to make sure that all of the pieces of content were held together and consistent across the game. A lot of the things got rewritten because major historical timelines changed too, but Mike kept it together.
During the development we had this weird narrative element we call the double apocalypse. At one point in writing most of the Earth was dead already because of a nuclear war, and then an asteroid hit and destroyed what was left. We went back and forth on that and it became clear that a double apocalypse would be way over the top and coincidental. So we edited the script to what it is now, but this has resulted in the internal term ‘that sounds like a double apocalypse’, which is when our scripts have become just a bit too unbelievable or coincidental.
Q: How do you convey backstories, lore, and world-building?
Obviously there are clichés like audio logs and walls of text, but there is a trend to do something different with them, or explaining the universe in a different way. But the fundamental problem is relaying a bunch of information to the player, and the further the world is from your everyday 21st century setting, the more you have to explain and the harder it is. So it’s understandable that a lot of games do it in the obvious way. The best way I’ve seen exposition done is by working it into the environment and art, making it part of the world so that the player can discover it rather than shoving it into the player’s face.
Q: How do you hook someone who disagrees with the character?
It’s hard to get the character to say and feel the same things as what the player is feeling. If you do it wrong it breaks the connection between the player and the character, and makes it far less intense. Ideally, if the player is thinking something, you want the character to be able to echo it. We spend a lot of time taking lines out so the character doesn’t say something out of place or contrary to what the player feels.
With philosophical questions there are fixed messages you can make and things you can say about the world, but that will put off a part of the audience. The big thing when setting moral questions or decisions is that you should ask the question instead of giving the answer. If you offer the players a grey area to explore, they might even change their minds about the issue at hand.
To murder or not to murder, that is the question.
Q: How do you write for people who are not scared of a particular monster or setting?
In my experience the trick is to pack as many different types of fear in the game as you can, and picking the phobias that will affect the most people. If there’s only one type of horror, it’s not going to catch a wide enough audience. Also, if you only put in, say, snakes, anyone who isn’t afraid of snakes is going to find it dull.
We probably peaked in our first game. What’s worse than spiders? (Not representative of the company’s opinion.)
Q: What’s the main thing you want to get across in games?
The key thing is that the players have something they will remember when they walk away from the game, or when they talk about it with other people. It’s different for different games, and as a developer you decide on the effect and how you want to deliver it. In games like Left 4 Dead delivery might be more about the mechanical design. In other games it’s a particular story moment or question.
In SOMA the goal was not to just scare the players as they’re looking at the screen, it was about the horror that they would think about after they put the mouse or controller down and were laid in bed thinking about what they’d seen. It was about hitting deeper themes. Sure, we wrapped it in horror, but the real horror was, in a way, outside the game.
Q: What does SOMA stand for?
It has many interpretations, but I think the one Thomas and Mike were going for was the Greek word for body. The game is all about the physicality of the body and its interaction with what could be called the spirit, mind, or soul – the embodiment of you.
The funniest coincidence was when we went to GDC to show the game off to journalists before the official announcement. We hadn’t realised there is a district in San Francisco called Soma, so we were sitting in a bar called Soma, in the Soma district, about to announce Soma!
As to why it’s spelled in all caps – it happened to look better when David designed the logo!
Q: Does this broken glass look like a monster face on purpose?
I’m pretty sure it’s not on purpose – it’s just because humans are programmed to see faces all over the place, like socket plugs. It’s called pareidolia. But it’s something you can exploit – you can trick people into thinking they’ve seen a monster!
This window is out to get you! `__´
Q: What is the best way to network with the industry people?
Go to industry events, and the bar hangouts afterwards!
It’s critical, though, not to treat it as “networking”. Let’s just call it talking to people, in a room full of people who like the same stuff as you. It’s not about throwing your business cards at each other, it’s about talking to them and finding common interests. Then maybe a year or two down the line, if you got on, they might remember you and your special skills or interests and contact you. Me being on Will’s stream started with us just chatting. And conversations I had in bars five years ago have turned into projects this year.
You have to be good at what you do, but like in most industries, it’s really about the people you know. I’m a bit of an introvert myself, so I know it’s scary. But once you realise that everybody in the room is probably as scared as you, and that you’re all geeks who like the same stuff, it gets easier.
Another good way to make connections is attending game jams. If you haven’t taken part in one, go find the nearest one! Go out, help your team, and if you’re any good at what you do, people will be working with you soon.
Q: Can you give us some fun facts?
Sure!
– You can blame the “Massive Recoil” DVD in Simon’s room on our artist, David. A lot of the things in Simon’s apartment are actually real things David has.
– We try to be authentic with our games, but out Finnish sound guy Tapio Liukkonen takes it really far. We have sequences of him diving into a frozen lake with a computer keyboard to get authentic underwater keyboard noises. It’s ridiculous.
– Explaining SOMA to the voice actors was challenging – especially to this 65-year-old British thespian, clearly a theatre guy. Watching Mike explain the story to him made me think that the whole situation was silly and the guy wasn’t getting the story at all. And then he went into the studio and completely nailed the role.
– There’s a lot of game development in Scandinavia, particularly in Sweden and Norway, because it’s dark and cold all the time so people just stay indoors and make games. Just kidding… or am I?
It’s over two years since we released SOMA, so it’s time for another update on how things have been going.
First of all, let’s talk about sales. As I’ve said many times before, sales are not straightforward to count, and the number you come up with is reliant on many different factors. For instance, SOMA was part of the Humble Monthly Bundle, which meant that everybody subscribing to that service was able to download a copy of SOMA. These are not really “sales”, so should we count them? It’s also worth noting that pricing differs a lot between different sales. A single unit sold at full price means more than one sold when the game is 75% off. I think it’s important to think about these things, and remember you can’t directly compare the sales of two games.
With all that said, what I’m going to do here is to basically take every single download of the game as a sale. Doing so gives us a total of 650 000 units, a 200 000 units increase since the the same time last year. This is a very good result.
It’s interesting to compare how sales have changed across the two years for SOMA. The normal day-to-day income, when there are no discounts or anything, is 33% of what it was the same time last year. However, when the game is at a discount (such as a Steam summer sale), the generated income is about 75% of what similar events generated last year. This means that discount events are extra important this year.
Taken as a whole, the sales that we make from all our games will cover all our expenses every month, and even make us a profit. This is quite amazing. Given that we currently have about 16 people working with us full time, we have a pretty high burn rate, and to still be able to support all that on your ongoing sales is great.
This means that we still have a good buffer from our launch sales. While it will by no means last forever, it gives us peace of mind and lets us take the time we need. While we’ll continue to generate income next year too, I’m not so sure it’ll be enough to cover all our costs. This is when that initial buffer comes in handy, and will let us continue working on our projects without any monetary worries. To put things in perspective, it is worth noting that most companies start using up their buffer just a few months after release, so we are in no ways in a dire situation right now – quite the opposite!
However, this also makes it very clear that we need to be able to release games at a more regular rate. We were lucky that SOMA was a hit, and that the money is easily able to sustain us for the time we need to complete our next project. Had SOMA been a flop, the situation would have been a lot worse now. That’s why we are focusing on becoming a two project studio, and the goal is to be able to release a game every two years. Had we managed to set that up prior to SOMA, we would be in the process of releasing a game right now. Needless to say, it would makes us a lot more financially stable, and able to handle a less successful release. In turn this should allow us to take greater risks, which I think is a key element in being able to create great games.
This leads me to another thing that’s been on my mind. A few months back someone asked me: “How do you get people to buy your game?”. This is a fairly basic question, but it really made me think. When it comes to sales made during launch, the answer feels quite self-evident. We generate a lot of buzz, there are reviews, let’s plays and so on. There are a number of fairly obvious ways that people learn about our game.
But what about the customers that buy our game two years after release – why do they do it? That’s a much harder question. I think most of this is via word-of-mouth recommendation. When the right circumstances arise (e.g.: “I feel like playing a game tonight”) and when external influence (e.g.: “your friends said they liked our game”) is strong enough, that’s when a sale happens. I know that Steam and other stores have some forms of discovery tools, but I don’t think they play a major factor. What really matters is not a single source, but the slow build-up of good will around a game – eventually this will make a player consider buying it. Discovery tools, such as “you might also like”-adverts, surely help, but they are just part of a much larger process [1].
Because of this, and considering the sheer number of games that are currently being released, I think the best strategy is to focus on unique experiences. You want to create the type of experience that is not only hard to get elsewhere, but also leaves a mark on those who play it. This is now a core philosophy here at Frictional. I guess we sort of always had it unconsciously, but we have now made it official. Our goal is to create games that are more than forgettable escapism. We want people to come out of their experiences feeling changed. A lofty goal? You bet. While it’ll be impossible to make sure every single player has this type of experience, it feels like the perfect thing to strive for.
Now I will round of this post with a brief discussion on the status of our current projects.
The first project is in full production, and about 80% of the team is currently working on it. The focus for most of this year has been on creating the first few maps of the game to create a solid vertical slice based on our experiments last year. However, we recently came up with some new avenues that we wanted to explore. The stuff that has come out of this recent detour is feeling really great and I am certain it’ll make the game feel very special. All of this came out of what I just discussed: our focus on making games that leaves a mark on the player. I’m not sure we would have gone down this route if we hadn’t explicitly stated that goal, which makes me confident it’s a really good way of thinking. I’m afraid I can’t go into any details on this, other than to say that the project will be horrific in nature. There will be no release this year, but we hope to announce something during the first six months of next year.
As for the other project, that’s also going well. We’ve been a bit delayed due to new tech taking longer than anticipated to develop [2]. The upside of that has been that the game has had more time in pre-production than any of our previous games. This has been incredibly valuable, as the things we aim to tackle in this game are quite difficult, and allowing it all to brew for a bit has meant many of the basic aspects are clearer for us. This game will be less about direct, visceral horror, and more about the player gaining an understanding of different concepts. This can, as we know from working on SOMA, be quite tricky to get right and requires a slightly different approach than when working on a more direct horror game. Release for this game is quite far off though, so don’t expect to hear any concrete details in the near future.
That’s it for this update. I’m incredibly excited about the things that we have planned, and I’m very eager to give you all more updates. I also want to thank everybody for the support over the years, and rest assured that while we might not reply to every single mail, tweet, etc. that you send us, we make sure to read every single one!
Notes:
1) For games that are heavily based around online communities, such as a Rocket League, I think things work slightly differently. There is still a word-of-mouth zeitgeist going on, but a lot of it comes from your game become a habit for your players, something that they participate in on a daily basis. This forms a feedback loop that helps drives new buyers, which I think is quite different from how our games work.
2) We are currently working on the fourth iteration of our HPL engine for this game, and due to some of the things we need to be able to do for the game, we’ve been required to make some major adjustments. These things take time, but luckily we have most of it done now.
There is something about unclear options which make choices a lot more interesting. This post goes into the reasons behind this, and various ways of achieving it in games.
Warning: this post will include some spoilers for Spec Ops: The Line.
The typical example for a choice in a game is something like this:
The situation is clearly set up and you are explicitly told what your options are. While they are most common in interactive movies, these sort of choices existing in just about every genre. They are easy to setup and can easily give a sense of moral drama. However, they miss out on a really important aspect of making real-life choices: that you are almost never aware what your options are or what they lead to.
Here is another example of a choice:
The player could avoid the incoming bullet by going down, or they could do it by going up. This is a choice very much in the same vein as the one from above. However there is no explicit prompt that asks the player what direction they want to go in. Instead the choice is implicitly stated through the use of the game’s mechanics. And in contrast to the explicit choice, it is unclear just what the options are. The choice might lack the ethical implications from the previous one, but the choice itself is way more interesting. It also feels like an ingrained part of the play experience instead of something that is an obviously designed situation.
Super Mario derives this choice purely from the functioning of its basic mechanics. Simulation is another game genre that does this, but manages to add a bit more philosophical depth to the choices. For instance, in a simulation game focused on survival you might not have enough food for all your party members and have to make a decision on who lives and dies. When these things work well it can have a tremendous impact – but more often that’s not the case. Letting your simulated party members starve to death very rarely give rise to the same strong feelings as a scene in a game like The Walking Dead. Let’s unpack why this is so.
—
In order for a choice to be made, the player need to understand that they are making one. The cornerstone of this is the player’s access to affordances. The player must have a robust mental model where they understand how the various aspects of the world work, and what abilities they can use to affect it. A choice then arises when it becomes clear to the player that there are two or more separate ways in which they can progress. Basically, the player understands that are at least two distinct plans for them to make, and they need to chose one of them. When this is crystal clear, the player has a choice on their hands.
Most games feature these sort of choices all the time. “What ammo should I use?”, “What path should I take?”, “Should I sneak or just attack?”. As I explained in an earlier post, the selection of plans is a fundamental part of gameplay. What makes a choice carry depth is that there’s something major at stake. So not only does the player need to understand that a choice is happening, but also that a major decision is happening. And in order to elicit the correct emotional response there needs to be a particular setup and framing.
A game like The Walking Dead has an easy time of it setting up all of these requirements. First of all, the game is explicitly stating that a choice is happening. It is impossible to miss. Secondly, since there is so much focus on the choice, it is quite clear that it is of major importance. Finally, The Walking Dead is heavily plotted and the designers have a great deal of control over what happens before the choice. It is relatively easy for that game to make sure the player is in the right frame of mind.
Things are much harder for a simulation game. Here the player takes part in choices all of the time and it’s harder to work out which ones are crucial and which ones are minor. The player might miss entirely what their choice is about. For instance, take the choice where the player needs to choose whom from their group to let die. It might be that the player doesn’t understand that they are running out of food, or thinks that they have some ways to survive. So at the crucial moment when the player decides who lives and who dies, they might be thinking about other things entirely. On top of that, even if the player grasps what the choice is about, it might be lacking proper build-up. The player might not be in the right mood, or have a suitable level of affection for the characters and so on.
It may of course be possible to improve the simulation to take things like this into account. However, this is very likely to run up against the complexity fallacy which I wrote about last week. Chances are that these additions to complexity will not be noticeable and instead just make the game harder to design and code.
—
Instead, there’s a middle ground here. Instead of explicitly stating the choices, it is possible to set up a situation that is driven by established gameplay mechanics. Since the setup is not something that happens dynamically, it’s possible to properly signpost the scenario. That way you can make sure that the player is in the right mood. But when the actual situation arrives there is no menu popping up that flags a choice moment. Instead the instruction to choose can come from the story mechanics (e.g. a character can speak), or, better, arise from how the situation is designed. The actual options are then chosen, not through an abstract menu, but through interacting using standard gameplay mechanics.
The best example of this sort of design is a scene from Spec Ops: The Line. Late in the game the player finds themselves surrounded by civilians. These people are not too happy that you are here and start throwing rocks at you. It is a very dangerous situation and it is clear that you need to get out of there. At this point, the player basically only has a single verb at their disposal: “shoot”. So what can you do? You really don’t want to shoot civilians, but you also don’t want to die. The player really has two options here. One is to shoot at the civilians, killing a few of them and making the others run away. The other option is to simply shoot in the air and scare them off, killing nobody.
The thing is that, since the game doesn’t tell you what your options are, shooting in the air is not obvious to a player. And that is what makes this choice so interesting and makes it feel like a real choice. Had a prompt popped asking you to choose between “fire at civilians” and “fire in the air”, the situation would have been radically different and would have lost a lot of its impact. But since you select the option with a gameplay mechanic, it not only feels like a proper part of the playable narrative, it also means that you are uncertain of what your options are.
Having choices like this makes the game feel analog. Under the hood the choice is just as discrete as the ones you would make in The Walking Dead, but it doesn’t feel like it. It feels like there are a spectrum of choices to be made, a continuous space of options, and not simply “this way or the other”. This concept of choices feeling analog is really important and I’ll talk about it more later on.
Spec Ops: The Line features half a dozen or choices of this kind. For instance, there is one where you are to chose which of two prisoners lives or dies by shooting one of them. But what the game doesn’t tell you is that there is a third options, which is to target the men that are holding the prisoners captive. Another scenario has you deciding whether or not to kill a war criminal. And again, it’s unclear just what your options are. The game simply puts you in a situation where it is possible to kill him. That there is a choice to be made is something you have to make up your own mind about.
Another interesting aspect of Spec Ops: The Line is how it handles the consequences of its choices. The solution is that it simply doesn’t. It just sets up the situations in such a way that either choice makes sense for what happens later in the story. While I don’t think it is possible to always shy away from showing consequences, it can be very helpful in maintaining the analog feeling. Because the moment you show a consequence, it makes it clearer that there is a discrete aspect to your choice. But if you keep consequences hidden, the possibility space is larger and the player is free to fantasize more just about what took place.
—
It’s worthwhile digging a bit deeper into this. What is it that makes the choices in Spec Ops: The Line different from a game where the options are explicitly stated? The key difference is that in the former, the player is in a position of uncertainty. There’s no clear-cut information to go by and the player is forced to fill out informational gaps using their imagination. When the options are explicit there is no need for this. The brain always wants to optimize, so any concrete piece of information will remove any mental guesstimation. This leads to Spec Ops: The Line having a much more vivid mental model of the scene. Remember, we play the game based on what is in our heads – not what is in the actual systems – so that means the game itself becomes a more interesting experience.
This is what the “feeling of analog” is all about. By having situations where not everything is clearly cut and where the player is free to imagine a wide range of freedoms. The goal is for it to seem like there are a continuous space of possibilities. This makes the situation feel real and organic. It lessens the feeling of there being a designer guiding your every step, despite the experience being just as guided as in the more explicit case.
It’s worth noting that there can be drawbacks to this approach. Just like in the pure simulation case, the player might misunderstand what the choice and its implications are all about. An explicit approach with a prompt laying out all the options will always be better at this. But it will also never feel analog. So there may very well be situations where an explicit choice is the right way to go. As always in design, one shouldn’t get hung up on the manner of implementation, but to focus on what the end results are.
In SOMA we tried to make all of the choices feel analog, and used a similar approach the one in Spec Ops: The Line. We presented a situation and then used common game verbs to let the player make their choice. The idea was to make the choices feel embedded in the game experience, and judging from feedback we have gotten, it feels like it worked out very well.
The only choice in SOMA that didn’t work properly was when you decided the fate of Wau. Here we failed create a proper emotional setup, and didn’t spend enough time on implementing consequences. A lot of this was due to this choice coming quite late in design, and it feels like it shows. It is a good reminder that you can’t just casually throw in these sort of choice-moments. One needs to make sure that the player is in the right mental state when they occur, and that you follow up on them in an appropriate matter. Just because something is supposed to feel analog doesn’t mean it doesn’t require a strict, and guided, implementation for it all to work out.
—
It is not only moral choices that can take advantage of becoming more analog. There are a wide range of other types of gameplay where it is worth considering if it can be made more analog. A good example of this is in interactive fiction (ie, good old text adventures). Normally these are controlled by simply typing commands into a parser. The type of commands are things like “pick up lamp”, “look under the carpet”, “remove dust from the table”, and so forth.
So, normally, there is no explicit prompt saying what sort of commands are possible. You have to infer the space of possibilities by reading the descriptions you get as you explore the current environment you are in. You are building up a mental model of the place at hand, and the character you are playing as, and using that to build a sense of what is possible to you. When this all works out, it feels great. It really feels like there is a living, breathing world for you to interact with. It feels analog.
This system comes with issues though and the most common one is the “guess the verb” problem. The player might know exactly what to do, but can’t figure out the right commands that allow them to do it. This is really frustrating and it breaks down the sense of immersion. A way to fix this is to make it clear exactly what the various verbs at your disposal are. This solves the problem, but it adds a new one: the game loses its sense of being analog.
I think it’s worthwhile to give this a test yourself. First try a normal interactive fiction game. I would recommend something like Lost Pig as it allows a lot of commands and, especially in the beginning, shows just how engaging it is to play something that lets you type whatever you want at a blank prompt. After you have done so, try out Walker and Silhouette and only use the highlighted words to play. The two experiences are very different. Sure, the latter makes it a lot easier to progress and removes some frustration. But on the other hand, it removes a lot of what makes the medium interesting in the first place.
I think this is a really good example of just how important the feeling of analog is. Implementation-wise, these two interactive fiction games are really similar, to the point of basically being the same. But the way that they chose to do their user interface radically changes the experience. By forcing the player to build an internal mental model of the game’s world, the experience becomes so much richer.
—
There are lots of other instances where the feeling of analog can be useful. Another good example are puzzles. I recently played through 999 which has “escape the room”-like puzzles. While these can be quite fun to play, the way they are set up it is incredibly obvious that the game wants you to reproduce a specific number of steps. You are basically trying to read the designer’s mind to find a very specific chain of actions that lead to a success state. This doesn’t feel very analog.
A big reason this is so is because the game will only respond to very specific commands. Most of these commands are not part of a generic verb-set either. For instance, you only ever use a screwdriver in a specific place and so forth. So you never really build a mental model of how the world functions, because such a model would basically be worthless. It is much better to think of each object as a specific case of “what does the designer want me to do with this?”. As such the world becomes stale and never gets a rich mental model. This is a very common problem with puzzles.
However, there are puzzle games that manages to work around this. One of the best examples is Portal. In this game is rarely feels like you are following a set path. Instead it feels like you are discovering a solution. It feels analog. And this is despite the solution being no less designer-directed than your average escape-the-room game. A core reason why Portal is different is that it always uses a foundational set of mechanics for solving the puzzles. You have your portal gun, the ability to pick up certain objects and to move around. That is it. Nothing else is used in order to progress. On top of that, there is a coherent design to all of this encouraging you to build a mental model around it.
There might only be one specific sequence of events to solve a puzzle. But when playing Portal you are not as aware of this. Much of the time it’s not even clear after you have completed a section. Because the puzzles are based on foundational verbs, it is much less clear whether there were other possible solutions available. There is often the sense that you could have completed it in another way.
This consistency in actions also means that you can mentally simulate a number of possibilities. You know up front the type of interactions that are possible and can use that to work out the sort of things that you can do in order to progress. And that without needing to interact with the world at all. What this means is that you are able to make plans. You can think about what steps to take in advance and be fairly confident all of these are possible to execute. As discussed earlier, making plans is a core part of what makes gameplay engaging. This is another reason why making choices feel analog is good – it also makes it feel more like proper gameplay.
The consistency in actions is not the only thing that makes Portal feel analog. The level design itself also plays a big role. By just giving the right number of hints, the player never feels pushed along a certain path, nor are they completely bewildered about what they are supposed to be doing. By not pushing the player too much, the game makes sure that the player comes up with ideas on their own. This gives a much greater sense of picking one solution out of many, instead of going along an intended route. And by making sure the solutions never feel too obscure, players refrain from trying to brute force a puzzle. Brute forcing can be quite damaging to the feeling of an analog world as this forces the player breaks down the world to its basic components, revealing the non-analog nature of it all.
Getting the level of handholding right is not an easy task and how to achieve it varies a lot from game to game. The basic idea is the same, though: you want to make the player understand what to do without revealing what your preferred route is. There needs to be enough uncertainty for the player to start building a vivid mental world around a situation. But there can’t be too much uncertainty as that means there is nothing to build a world on.
—
Another example of crafting analog worlds is the closet-hiding in Amnesia. We chose to simulate this using a physics-based interaction system. We also tried to make the behavior an implicit part of the gameplay, and never directly state how it is supposed to work. Despite this, a great number of players still entered closets to hide and opened the door slightly to see if the coast was clear. We could have just had an explicit prompt and some specific controls when you are hiding behind doors, but it doesn’t feel like that would have been the same kind of experience. This way, the world has a much great sense of being an analog one.
There are bound to be tons of game mechanics that could make good use of becoming a bit more analog. One obvious example is dialog response, where I think there would have been a lot more to gain if the options could be chosen by using core mechanics instead from an explicit menu.
How could you go about making a scene more analog? I think there are two main aspects that you need to implement:
The choice selection must be made by using a set of core mechanics. The number of ways in which these mechanics can be used must also be so large that the player can’t easily grasp the options available. For instance, if the player can only punch red objects, and you enter a room with a single red object, the situation doesn’t feel very analog.
The hints on how to complete the scene can’t be too direct. There needs to be a certain level of vagueness so the player feels that they have come up with the solution themselves. It’s also important to teach the player (through play if possible) how the core mechanics functions. The idea is that when they encounter a choice moment (be that a puzzle, moral choice, etc.) they have an intuitive understanding of they ways they can approach it.
It’s also important to not just focus on the interactions at hand, but to think of it as a multi-scene setup. In order for the player to be in the right state, and to have the right mental model, there’s a lot of setup required. It is really important to think holistically about these things.
—
I think there’s a lot to be gained by thinking in terms of making a world more analog. I also think that it’s something that hasn’t really been explored enough. It is quite common to just take something that works through explicit means and stick with it. Crafting scenes in an analog way is a lot more work, but I also think it can be really rewarding. It’s also a very good concept to have in mind when trying to merge more standard narrative approach with proper gameplay. Analog worlds are a core part of evolving Interactive Storytelling.
It is easy to think that the player sees all of the complexity you put into a game, but nothing could be further from the truth. A game’s complexity is basically meaningless when it comes to the end experience. All that matters is what the player actually perceives.
Brian Upton once told me the following anecdote about a game that he got pitched to him.
The game presented to him was a space sim where the player took on the role of a space pirate. A big part of the pitch was the virtual economy that the game had. It determined what sort of goods that planets needed, what the prices of various things would be and so forth. In turn this then determined the trading routes that ships would take and what sort of cargo you were most likely to find on them. This was a really complicated system and I guess they planned on devoting quite a bit of development time for it.
Sounds cool, right?
Problem was that none of this complexity was really apparent to the player. The only feedback that the player got from the whole system just boiled down to what sort of ships and cargo they would be encountering. From this meager data it was impossible for the player to get any sort of insight into underlying systems. If all of that system was replaced with a random number generator, the player wouldn’t notice. So in essence, all of this complexity was a waste.
The reason something like this happens is quite easy to see when viewed through the lense of the SSM Framework. In this framework we divide the game into three separate spaces: system, story and a mental model. Something like the virtual economy would go into to the system space. But the problem is that these systems would never end up in the player’s mental model. Understanding how this works is a fundamental, perhaps the single most important, part of the game design. The player doesn’t play a game based on what happens in the computer, they play it based on what happens in their head. Any feature that doesn’t have a mental representation might as well not exist.
In play, the Game Model is irrelevant. Players can’t perceive it directly. They can only perceive the Player Model in their minds. That’s where the stories are told. That’s where dilemmas are resolved. So the Game Model we create is just a pathway through which we create the Player Model in the player’s mind.
The Player Model Principle indicates a source of risk. Namely, anything in the Game Model that doesn’t copy into the Player Model is worthless. That’s what happened with the ecologies in Ultima Online and BioShock. They didn’t enter the Player Model and so degraded into noise. This is a fairly obvious risk and is common in game design – all designers have seen players not understand a piece of their game. […]
What we want to do is create systems that are smaller and simpler than these giant hairballs, yet have more interesting, comprehensible interactions than simple systems like orbiting planets. What we really want is not a system that is complex, but a system that is story-rich.
This is coming from a developer that is developing a hardcore simulation game. If it this sort of thinking applies to that genre then you can be sure that it applies to the entirety of game development.
Adding a feature is not about adding art and systems. It about is adding content that when played with will create a certain mental model in the player’s head. In this sense, it’s quite a bit like being a stage magician. Just like in games, the important thing in magic is not performing a hard trick, it is making the audience believe that you did one. In fact, many spectacular-seeming magic tricks have really boring explanations. But since the audience is never directly exposed to the method of implementation, it doesn’t really matter. The only thing that matters is that the magician has a high chance of succeeding and what sort of reaction it gives the audience. Games works exactly like this too.
Most of the time, an increase in complexity is a bad thing. There is a higher chance of bugs, and it is less likely that you can maintain control of the system. This is why things like artificial neural networks doesn’t have much use in games except for in very specific areas. While a neural net could accomplish a lot of cool things, robustness is more important. As a game developer you want to be able to intuit how a system works in order to properly use it in design. Go past a certain point of complexity and the output might as well be random. The KISS-approach is almost always the right one to take.
The simplest way of designing a system is, of course, not designing a system at all. It cannot get more simpler than zero. While this might sound a bit silly at first, it’s a crucial part of game design. Last week I wrote about utilizing gaps of the imagination, which is really all about replacing something with nothing. The best way of understanding how to do this is to not see your features as concrete content, as complex machinery, but as experiences you want to evoke in the player. This is not just limited to fuzzy things like NPC emotions, but every single aspect of the game.
As I explained in the previous post, gaps have a lot of advantages over an explicit systemic implementation. Not only are they cheaper, but they are also more malleable and easier for the player to fit into their idiosyncratic view of the game and its virtual world. It is not always the solution, and sometimes the goal cannot be reached without having an actual system managing everything. The only way to make this decision is to look at games in the right way and understand that what matters is not the underlying machinery, but the mental states it gives rise to.
In games, if a tree falls and nobody hears it, it is a feature you should cut.
We don’t perceive every single piece of information around us. Instead we must constantly fill in blanks in our knowledge to properly create a mental image of the world. This processes of filling in gaps is really important to understand and to exploit when crafting games.
At the very core, games are driven by systems. We have extremely powerful machines that can quite accurately simulate various forms of physics, economics, group dynamics, intelligence and so on. This means that at our fingertips are the tools to create entire worlds. It is therefore very tempting to use these in order to solve every single problem. But this is not always the best approach. Sometimes it’s best to just leave gaps, and let the player’s imagination handle the rest.
There are five core reasons why this is so:
We are all unique individuals with different needs and likes. By leaving things unsaid, players can personalize their experience without any asset requirements from the creator. A typical example is that players can envision the sort of monster they personally are the most afraid of.
It is impossible to simulate things on an atomic level; there always needs to be a cut-off at some level. Since highly complicated things tend be unstable and encourage scrutiny, it is often better to make the cut off at a higher level.
There are certain things which are, for various reason, not possible to implement properly. In this case a lot can be gained by simply leaving it to the imagination. This includes everything from creating immense battle scenes to conveying a particular emotional state.
For the sake of pacing; sometimes it’s simply not possible to give the player all of the required information and it’s better for them to just work it out for themselves. This could be things such as background story, details on a map, or the areas that it’s possible to visit in a location.
There is an inherent enjoyment in filling out blanks in various forms of art. The reasons are a bit fuzzy, but you can clearly see it in all art. It’s fun to wonder what a character is really feeling, what events lead to a scene, and to mentally picture what a shadow is hinting at.
All of this works because of how our brains is constructed. We are all equipped with highly capable pattern-matching machines. Our brains, and therefore we ourselves, want the world to make sense and will always try and fit things into a coherent and convincing narrative. The simplest example of this at work is motion. Just consider this animation:
This is really just a series of circles that we see in rapid succession. Despite the fact that it’s quite easy to notice the individual frames, we still see it as a ball jumping up and down. We fill in the gaps between the frames and see it all as an animation. Notice that this doesn’t really take any conscious effort – it comes naturally. In fact, it is quite hard (possibly impossible) to not see this motion. When done right, gaps of the imagination never really feel like such – they simply get incorporated into the overall experience.
There is no white triangle pointing downwards, but the other shapes suggest that there should be, and hence we see one. Again, this is something that we carry out automatically and while we can rationally understand that there really is no triangle, we cannot mentally unsee it.
Closing gaps like this is not just a fun side effect. It is a crucial way in which our brains function. Taking decisions on incomplete information is an essential skill in the function of our day to day lives. In fact, most of the information we receive is incomplete – it’s quite rare that we are directly exposed to situations where we have all possible information to hand. So it’s not so strange that closing gaps should come so naturally to us, we literally wouldn’t be able to survive otherwise.
As I have said before, any decisions we make are based around a mental model. In our heads is a mental simulation of how we think the world works, and before we do anything we first run through the action in our model to see if it would have the effect we intend. However, it is not possible to get complete information about our surroundings. So in order to get a working map of the terrain we need to fill some of the information. That is what the gaps in imagination are all about – our process of crafting a working mental model.
Given that this is a foundational part of how people work, it is essential that we always have it in mind when designing games. After all, the end result of a game is really to create a specific mental model in the player. This can be done through direct system access, sensory input or, what this post is all about, through suggestions of something unseen. I will now go over the most common, and most important, ways in which gaps can be used.
—
Sensory Gap
This is the most common one and also easiest to understand. When we are presented with sensory information that is somehow incomplete, we try and fit it into a working context. There are many different ways in which to do this. It can be quick, disjointed shots of something, events seen through the eyes of a monster, a character reacting to a smell. or a sound that is so loud it shatters glass. Normally you build this sort of gap up by presenting a negative space where one or more object/events/reactions/etc. all related to something unseen.
We tend to use this sort of gap more than we realise, simply because it is such an ingrained way of working with various artforms. But that just means you have to be extra aware of how it works. For instance, it’s good to know that we are extremely prone to seeing familiar shapes, such as faces, in just about anything.
It’s actually quite hard to not see anything in an image. We have evolved in an environment where there was nothing like pure noise, everything we saw was part of the environment somehow. Therefore, when we see random patterns the brain goes into overdrive to find a connection. Of course, it is not just the direct information received that we use to do this, but anything related is accessed as well. Because of this, you can often get away with very little if the scene is just set up in the right manner. Learning to do this is incredibly important.
Informational Gap
This is very similar to the sensory gap, but instead of sensory data it deals with information in the abstract. Jeff Vogel recently wrote a blog post on how games often have too many words [1], and properly using gaps is the best remedy for that. It is often easy to underestimate just how much information a player is prepared to fill out for themselves. You might think that a player really needs to know details of everyday routines in order to fully understand how a certain society functions. But often it is just as good to simply have some brief glimpses (visually or through text) of what they are doing along with something that sets the tone (music, animation, etc).
This sort of advice might seem a bit obvious, but it is worth keeping in mind how good we humans are at filling out these sort of gaps in information, especially if it comes in form of gossip. Gossip is something that has probably been part of our lives since before we evolved into modern humans. We are social animals and gossip serves as a tool to keep track of the group we are living in. This means our brains are extra-sensitive to this sort of information, similar to seeing shapes and motion, and can easily assess even the smallest hints.
Spatial Gap
Games are often very spatial and requires the player to navigate various places. Because of this it is often very tempting to accurately represent every single area to give a proper sense of place. However, for various reasons this might not be feasible or required. It is then important to note that spaces can also be created from gaps, just as much as sensory information and lore. Spatial gaps are a bit trickier though as we are now messing with the actual play area which means you you have to be extra careful.
The sloppy way to implement is to simply have a lot of locked doors that the player cannot access. But this can be bad for pacing and, worse, it can lead to a weak mental model. The brain is usually quite lazy and will try to optimize. If the pattern becomes ‘locked door equals the room is irrelevant’, it will be noticed and incorporated into the model. After all, dismissing these spaces is much easier than assuming they are there.
Instead it is better to vary the ways in which the rooms are blocked off, and to build up a negative space hinting that it is there, such as glimpses into it from a small window. It is especially effective to make the player believe that room might contain something of value. That way it is much more likely it will be part of the mental model. Remember, what matters is not what is actually there, but what the player perceives to be there.
Causal Gap
This next time is very similar to the animation example from above, but happens over longer time scales. As I said before, closing gaps is all about creating a working mental model. Where the previous gaps where are all about what we see, causal gaps is more about why we see it. Just like we humans are quick to see familiar objects in random patterns, so are we quick to correlate two events with one another. A black cat runs over the street and then you get a headache. We humans often correlate the most strange occurrences and it is quite hard not to. Many of our psychological fallacies are really based around this fact, and it takes effort to learn not to do this. Why is this so? Because for our ancestors it was okay to have a few weird beliefs if it meant we could pick up on dangerous situations and survive better. If you are a skeptic about the cat causing the headache, you might also be skeptical towards the signals of an impending avalanche.
This is obviously the sort of brain glitch that we can make use of in art. Film is a medium that uses it all the time, in editing. See a gun fire, and then a person being hit, and it is obvious what has happened. Correlating these two events into a single event comes naturally to us. But because games are so driven by the player understanding the flow of input and output, or how the player’s actions correlate to events in the game world, it gets a bit harder to deal with gaps.
The simplest way to do it is with events taking place. For instance, say the player suddenly notices that a door is blocked, and hears the sound of feet running away. They will now assume that whoever is running away is also the one who blocked the door.
A little harder is for us to provoke imagined causal connections from actual interaction. What I mean by this is that you actually leave out certain information when actions take place, and ask the player to fill in the middle. For instance, if I click on an object in a game and it simply pops into my inventory we would like the player to mentally simulate this as “I picked up the item” and not “the item got magically teleported into my inventory”. The three key elements for achieving this are consistency, negative space and optimization-avoidance.
Consistency means that we need it to happen in a way that makes it possible to distil it into a couple of universal rules. For instance, is the distance you can pick up items at consistent with the player using their hands? Negative space means that we use other events to reinforce the fantasy. These can be sounds effects when you pick up, feedback messages when you are too far away, and cutscenes where we see this happening for real. Finally, optimization-avoidance means that our intended mental model, that of the player actually picking these objects up, must be the “simplest” [2] available explanation. If there are too many edge cases, weird behaviors or simply not enough supportive negative space the “magical teleportation”-theory will win.
Anticipatory Gap
This one is quite similar to causal, but worth having in its own category. These are basically events that might happen to the player in the future and that they will take into account when planning. As explained in an earlier blog, planning is a core reason why gameplay is engaging, and thus it is important to shape what sort of consequences the player can conceive of taking place. When the player plays a game, they will generate their mental models not just based on what they are playing, but also what they know from before. This is gives us an opportunity to make the player think certain things are possible, without them never having witnessed them.
Suppose that the player hears footsteps from afar. These might just be coming from a couple of scripted sound effects, but the player doesn’t know that. Given the right context the player will conjure up a monster that is making these sounds and assume that it might attack them. Now the player will start making plans based on a few sound effects and project a lot more onto the game than what is actually there. This is something that we saw a lot in Amnesia. The player could create long, and engaging, gameplay situations for themselves only because of a few sound effects.
Of course, this sort of trick can’t last forever. As I have mentioned several times, the brain likes to optimize and once the pattern gets to clear the illusion will go away. So it is important to constantly update the negative space, to not make the events so predictable and to setup situations in ways that feel exciting to partake in. Even more important is to make sure that this trickery is not the only gameplay there is. If the player has a baseline of actual planning and execution going on, this sort of illusory anticipation can be sustained for quite a long time and add a lot to the experience.
Agency Gap
If you are in the jungle and the high grass suddenly moves. Do you:
Assume it is a tiger with the intention of eating you?
Be skeptical and consider that it might just be the wind playing tricks?
In our ancient past, the people who thought like number 2 were much less likely to survive. Sure, they escaped the embarrassment of being afraid of grass from time to time. But they also got eaten a lot more by tigers. Thinking of events as being caused by something with agency (e.g. an animal) is powerful concept for survival. It is also something that leads to all sort of weird beliefs like tree spirits and demonic possession. For many events it comes naturally to think of them as caused by intentional beings. And once again, this is great stuff to use in games.
This video that is a great example of the whole thing in action. Just note how you directly project agency on the shapes.
The most common use of this is in enemy AI. Most of the time, AI that feels smart is because the player thinks it is so, not because the underlying systems are complex [3]. F.E.A.R. is a great example of this. While the AI does have some clever systems at play, it derives most of its impressiveness from being good at giving the player feedback. For instance, by saying “cover me” while a grenade is thrown, it gives the impression that much more is happening than what actually occurs. The player projects a set of thoughts running through the soldier’s mind and incorporates that into their mental model. But in reality it is just very simple code that is executed.
This is an area where the brain works a lot to our advantage. We are ill-equipped to mentally simulate things like state machines, but it comes naturally to think in terms of people. This means that we can get a lot of content to the player only through suggestion. The player’s brain is really apt at simulating people and can do so much better than any existing computer system. So the more of that power we can use, the better.
All of this get harder when we get away from combat though. While players want to think of other characters in games as entities with rich mental lives, there is a limit to how far they are willing to go. If animations start to look weird, if responses come out as canned or if interaction possibilities are too limited the brain gets lazy and optimization kicks in. Characters go from intentional beings to simply being objects.
A big problem of interactive storytelling is how to keep this from happening. Just as I discussed with causal gaps, the key elements in achieving this are consistency, negative space and optimization-avoidance. How exactly to achieve this with characters is still too unclear and complex to cover this time around – I will go over some possible directions in a future blog post.
Volition gaps
Finally we have arrived at the last gap type, which is similar to causal gaps. Previously we have mostly talked about things happening when the the player is the one causing it, but volition gaps contradict that. These are events that the player thinks they cause when in fact they don’t.
This is something that I think currently is quite unexplored and has a lot of potential. It is quite hard to construct control interfaces that allows the player to take all the possible actions. Therefore it would be nice if we could have actions that the game does automatically but that the player believes they used their volition to cause. This is what this gap is all about.
Just like we construct a mental model of what is happening on the outside world we are also constructing a narrative of what we are doing ourselves. While we are not conscious about it in everyday life, a lot of the time we have reasons and beliefs because we do certain things, instead of the other way around.
For instance, take choice blindness. In an experiment the subject had to pick which face they thought were the most beautiful, and then when handed back a different picture, most subjects continued to explain why they had chosen it. So a lot of the time, we make up reasons based on the actions we find ourselves doing. And as always, whenever there is a brain deficiency, we should try and exploit it for art.
The best example of this effect in use is in Assassin’s Creed. When you run across the roofs in a city, the game will automatically make the character jump. Despite that, it always feels like you are the one who is willing those jumps to happen. This works as a great way of streamlining the controls and making the experience more fluent without taking away a sense of agency in the player. Another example of is in games like Uncharted where the character will interact with the world in ways that make sense and enhance the feeling of being there.
I believe that these sort of gaps can be taken further, though. An interesting example of this is The Path, where the protagonist will carry out actions of their own choice when you leave them alone. It is by no means perfect, and doesn’t really provide an illusion of volition. But I think it shows the potential of this and I think causes the player to feel intimately involved with various events if used correctly. Currently, though, it is too unexplored to say for sure what the possibilities really are. I will explore some more thoughts on this in a later blog post.
—
That should summarize the basics for the various gap types. I am sure there are even more than these, but this selection is what I found most useful for games. In upcoming blogs I will dig deeper into some aspects of this and give more examples on how it affects gameplay.
Until then I recommend reading Ian Thomas’s excellent article on the subject where he discusses gaps for LARPs, SOMA, and much more.
Footnotes:
1) The follow-up post that looks at the game Pillars of Eternity specifically is also well worth reading:
2) This is simplest in terms of effort used by the brain, not in a strict theoretical sense. For instance “a witch did it” is a simple explanation for a human brain, but in reality is quite complex because it assumes a lot of attributes for the witch. But we as humans are great at just ignoring this, making the silly explanation seem simple.
This article goes over why it is so important for choices to matter in a game and how it all has to do with planning. If a user perceives that their actions have no consequences, you remove a core component of engagement – the ability to plan.
Say you are playing a game like The Walking Dead, or any other interactive movie, and you are faced with the choice whether or not to help someone who is hurt. You decide that you want to help the person, after which you never see them again for the rest of the game. Reloading a save and playing through the scenario you find out that if you chose not to help, the same thing plays out. Simply put: in this case, your choice really has no consequences.
While the scenario is made up, it presents a very typical situation that opinions are heavily divided on. Some people are totally okay with it for various reasons. But others will argue that this lack of consequences ruins the entire experience, as your choices doesn’t really matter. It’s really easy to say that people who feel this way are simply playing the game the wrong way or are not properly immersed. However, I think it’s really important to investigate this reaction further as it gets us closer to some fundamental problems of narrative games.
The argument from people who get annoyed by these non-choices goes something like this: if every branch leads back to the same path, then you really don’t have any say in how the game plays out. You are not playing a game, you are only pretending that you are. It’s like when you are playing a split-screen game and notice you’ve been watching the wrong side. The feeling of play is just an illusion. Nobody would tolerate a Super Mario where a pre-written script – not the player’s skill – determines whether or not they survive a jump, so why tolerate games where all choices lead to the same conclusion?
One could counter that by saying the intention is to put you into a hard position and the game is about your varied emotional reactions as you ponder the different choices. It isn’t about affecting how the game plays out – it is about making an emotional journey. If you require the game to show you the consequences of your actions, you are not immersed in the game’s story – you are simply trying to optimize a system. This might sometimes be the case, but I also think this line of thinking is missing what the actual problem is: the failure of the player’s mental model.
—
Let’s start by breaking down the problem. A mental model, as explained in this previous post, is how the player perceives the game’s world and their role in it. As you are playing a game, you slowly build a mental model of the various objects and systems that make up the game and attach various attributes to them. At first a box might just be a piece of the background, but as you learn you can destroy it in order to gain items, attributes are added. The object gains complexity. The reverse can also happen. For instance, when you first see a character you might think that you are able to speak to it and therefore label it with various attributes you know that humans usually have. But when you find out that the character is really just a piece of the background without any sort of agency, most of those attributes are lost.
Your mental model of a game is something that is continually revised as you are playing, and it is something that always happens, no matter what the game is. In fact, this is a process that is a core part of any medium, including books and films. So, obviously, when you are playing an interactive movie game, you are not simply reacting to a direct stream of information. You are answering questions based on your mental model.
Take my “will you help your hurt companion?” scenario from above. The knowledge you take into account about that choice is not just what is currently projected at you from the TV screen. It is a combination of everything you have gone through up to this point, along with a bunch of personal knowledge and biases. Even basic concepts like “hurt” and “companion” aren’t just created in this moment. They are ideas that the game has spent a lot of time building up, be that for good or bad, from the very moment you started playing.
When you are faced with the hypothetical scene of a hurt companion, you are not just dealing with an animated image on a screen. You are dealing with a whole world constructed in your mind. This is what your choice will be based around. While it might objectively seem that everyone is reacting to the same scenario, they may in fact be dealing with quite different setups.
So when someone gets annoyed by the lack of consequences, it is not necessarily the direct consequences that are missing. The issue is that they have constructed a mental around a real person in need, along with that person’s future actions. So when it becomes apparent that the game doesn’t simulate that as part of its own model, the player’s mental model is broken and it feels like a big let down. Remember that we don’t play the game that is on the screen, we the play game as we perceive it in our heads. So when it turns out that your imagined world is fake, it has a huge impact.
It gets even worse once we take into the fact that planning is fundamental to a sense of gameplay. As explained in a previous post, engaging gameplay is largely fueled by the ability to make plans. The way this works is that the player first simulates a course of action using their mental model, and then tries to execute that in the game. This is a continuous process and “planning and executing the plan” is basically the same as playing. Interactive movies normally don’t have a lot of gameplay and it is really only in the choice moments that the player gets to take part in any actual play. Hence, when the choices turn out to have no consequences, it becomes clear that planning is impossible. In turn, this means that any meaningful play is impossible and the experience feels fundamentally broken.
[…] one scene I had made a plan of actions: to first bandage an unconscious person and then to poke around in his stuff. There really was nothing hindering me from doing so but instead the game removed my ability to interact directly after caring for the person. The game interpreted me wanting to help the guy as I also did not want to poke around, thinking that they two were mutually exclusive actions. Of course I thought otherwise and considered it no problem at all to do some poking afterward.
I think that people to complain the loudest about the lack of consequences are extra sensitive to situations like this. But, as I said, this is not due to lack of consequences per se, but due to the impact it has on the consistency of their mental model and sense of play. It is really important to note that this is not due to some sort of lack in immersion or ability to roleplay. On the contrary, as I have described above, many of the issues arise because they mentally simulate the game’s world and characters very vividly.
—
So the problem that we are faced with is really not a lack of consequences. It is because the underlying systems of the game are not able to simulate the mental model for a subset of players. One way of mending this is of course to add more consequences, but that is not a sustainable solution. Additional branches increase exponentially, and it quickly becomes impossible to cover every single possible outcome. Instead it is much better to focus on crafting more robust mental models. Sure, this might entail adding consequences to choices, but that is just a possible solution – it is not the end goal.
As I outlined in the previous blog on the SSM framework it is incredibly important to keep track of how systems and story help form a mental model in the player’s mind. For instance, if you start your game saying “your actions will have consequences”, that will immediately start filling up your player’s imagination with all sort of ideas and concepts. Even how pre-release PR is presented can affect this. All of these then become things that lay groundwork for how the game is modeled in the player’s head and it is vitally important to make sure this mental model remains stable over the course of the game.
One of the main things to have in mind is consistency. Remember that as someone is playing a game, they are building up a mental simulation for how things are supposed to work. If you provide information that certain events are possible when they are in fact not, you are running the risk of breaking the player’s mental model. You either need to remove this sort of information or to make sure that they never take part in situations where these sort of events feel like a valid option.
However, the most important thing to keep in mind is the ability to plan. A major reason why the lack of consequences can feel so bad is because these consequences were part of the player’s gameplay plans. So when it becomes apparent that they don’t exist, the whole concept of play breaks down. In all fairness, this might be OK for certain genres. If the goal is to simply to make an interactive movie, then losing a subset of player might be fair. But if the goal is to make proper interactive storytelling, then this is of paramount importance – planning must be part of the core experience.
That doesn’t mean that every choice is something the player needs to base their plans on. But in that case then there need to be other things that lie on a similar time scale and which are possible to predict and incorporate into plans. I think that one way around this problem is to have a more system-focused feature that runs alongside the more fuzzy narrative choices. When the players make choices, their mental model will have the best predictive skills around this more abstract system, and play revolves mostly around this. Then when more narrative choices are presented they will feel more game-like and part of the a solid simulation, despite not really having any consequences.
A simple and good example is the choices you have to make in Papers, Please. This game is driven by a type of survival simulation where you need to gain credits (though doing proper passport check) in order to keep your family live. Entwined into this are choices about who you will allow into the country. Many of these don’t have any far reaching consequences, but that that doesn’t really matter because your ability to plan is still satisfied. But despite that, these choices still feel interesting and can have an emotional effect.
This sort of approach relies on combining several elements in order to produce the feeling of something that might not actually be there. This is something that is used in a wide range of applications, from how we view images on a TV, to how films can create drama through cuts. We don’t always have to have solve problems straight on, but often the best way is to split the problem into many and to solve each problem on its own. The combined effect will then seem like a solution to the original problem. This is a technique that is super important for not just this, but many other narrative problems. I will write a blog post later on that goes into more details.
Once you have a game that is consistent and that has some sort of planning apart from the more narrative choices, the probability of satisfying the people will be greatly improved. And not only that, your narrative experience will improve over all, for all players, not just a subset. In this case I think it is fair to view these extra sensitive people as canaries in a cave, something that is first to react on a much bigger issue.
—
This blog post by no means presents the solution to end all problems with choices and consequences. But hopefully it will give a new way of thinking about the problem and some basic directions for finding a solution. I don’t think we will ever find a perfect way of dealing with choices, but the better informed we are at underlying causes, the better experiences we can provide.
In this post I dig into planning, and how it is a fundamental part of what makes a game engaging. Planning affects many aspects of what is so special about games and why we enjoy playing them. This post will go over the reasons behind this, and explains why planning is so important for narrative games.
I think we can all agree that there is a difference in how certain games feel to play. There are just certain games that feel “gamier” than others. Just compare playing Super Mario to something like Dear Esther, and I think it’s clear that the former feels like it has more gameplay than the latter. What is it that causes this? My hypothesis: the ability to plan.
The more a player can plan ahead in a game, the more engaging that game will feel to play.
Before I cover some evidence of why this is most likely true, I will need to get into some background information. In order to understand why planning has such a prominent role in games, we need to look into the evolution of our species and answer this question: why are fish so stupid?
This is how the world looks to the average fish:
They can really only see 1-2 meters in front of them and often it’s even worse than that. This means that a fish can’t do much planning. It just reacts to whatever pops up in front of its face; that’s really what their lives are all about. If a fish’s life was a game, it would be a limited version of Guitar Hero played to random noise. This is why fishing works. Fish don’t think like us, they’re mainly just driven by hardwired responses.
For a large part of earth’s history this was what life was like for organisms. But then 400 million or so years ago something happened. Fish started to move on to land. Suddenly, the view looked more like this:
This changed their world. Suddenly it was possible to plan ahead and to properly think about your environment. Previously, smart brains had been a waste of energy, but now it was a great asset. In fact, so important was this shift that it is probably a big factor in how consciousness evolved. Malcolm MacIver, who as far as I can tell originated this theory, writes about it like this:
“But then, about 350 million years ago in the Devonian Period, animals like Tiktaalik started making their first tentative forays onto land. From a perceptual point of view, it was a whole new world. You can see things, roughly speaking, 10,000 times better. So, just by the simple act of poking their eyes out of the water, our ancestors went from the mala vista of a fog to a buena vista of a clear day, where they could survey things out for quite a considerable distance.
This puts the first such members of the “buena vista sensing club” into a very interesting position, from an evolutionary perspective. Think of the first animal that gains whatever mutation it might take to disconnect sensory input from motor output (before this point, their rapid linkage was necessary because of the need for reactivity to avoid becoming lunch). At this point, they can potentially survey multiple possible futures and pick the one most likely to lead to success. For example, rather than go straight for the gazelle and risk disclosing your position too soon, you may choose to stalk slowly along a line of bushes (wary that your future dinner is also seeing 10,000 times better than its watery ancestors) until you are much closer.”
To showcase the above, he has the following image:
This images nicely shows the conceptual difference in the processes involved. In one you basically just use a linear process and “react as you go”. In the other one you scout the terrain ahead, consider various approaches and then pick one that seems, given the available data, to be the best one.
It is not exactly the same, but there is a striking likeness to the following image comparing old school and more modern FPS design:
I know that this is not a completely fair comparison, but the important point here is that when we look at these two images, it feels pretty clear which of these two designs ought to have the best gameplay. The image on the left represents a more complex and interesting landscape, while the one on the right represent a linear sequence of events. And just like the worlds of a fish compared to that of the world of land animals, this means a huge difference in our ability to plan.
There are other interesting connections with the ability to see far and to plan. Malcolm MacIver replies to a question regarding the intelligence of octopi:
“It’s incredible what being an unprotected blob of delicious protein will get you after eons of severe predation stress. They, by the way, have the largest eyes known (basketball size in the biggest deep sea species). Apparently, they use these to detect the very distant silhouettes of whales, their biggest threats, against the light of the surface.
The theory is committed to the idea that the advantage of planning will be proportional to the margin of where you sense relative to where you move in your reaction time. It then identifies one period in our evolutionary past when there was a massive change in this relationship, and suggests this might have been key to the development of this capacity. It’s interesting that octopuses and archerfish tend to be still before executing their actions. This maximally leverages their relatively small sensoria. There may be other ways, in other words, for animals trapped in the fog of water to get a big enough sensorium relative to where they are moving to help with planning.”
Sight is of course not the only reason for us humans to have evolved our current level of intelligence and consciousness. Other important factors are our upright pose and our versatile hands. Standing up meant that we could see further and allowed us to use our hands more easily. Our hands are the main means with which we shape the world around us. They allowed us to craft tools, and in various ways to change parts of the environment to optimize our survival. All of these things are deeply connected to the ability to plan. Once we learned how to reshape the world around us, our options opened up and the complexity of our plans increased immensely.
It doesn’t stop there. Planning is also a crucial part of our social life. Theory of mind, our ability to simulate other people, is both a reason for and a product of our planning abilities. Navigating our social groups has always been a careful activity of thinking about various paths of action and their consequences.
Planning also underlies two other phenomena that have been discussed recently on this blog: Mental Models and Presence. The reason why we have mental models is so that we can evaluate actions before we make them, which obviously is crucial to planning. Presence is a phenomenon that comes from us incorporating ourselves into our plans. We don’t just want to model what happens to the world, but also to ourselves.
So, to sum things up: there are lots of evolutionary reasons why planning would be a fundamental part of what makes us human. It’s a big part of who we are, and when we are able to make use of these abilities we are bound to find that engaging.
So this background is all very well, but is there really any good evidence that this is actually a thing in games? Yes – in fact, quite a bit of it! Let’s review the ones that I find the most important.
There is a model of player engagement called PENS (Player Experience of Need Satisfaction) which is quite rigorously researched. It uses the following criteria to evaluate what a player thinks about a game.
Competence. This is how well a game satisfies our need to feel competent – the sense of having mastered the game.
Autonomy. How much freedom does the player have and what options do they have to express it?
Relatedness. How well is the player’s desire to connect with other people satisfied?
Measuring how well a game performs on the above metrics has been shown to be a much better indicator of various types of success (sales, how likely people are to recommend the game, and so forth) than simply asking if the game is “fun”.
And, more importantly, two of the above factors are directly related to planning. Both Competence and Autonomy heavily rely on the player’s ability to plan. Let’s go over why this is so.
In order for a player to feel competent at a game they need to have a deep understanding of how the game works. Sure, there are games where mere reflexes are enough, but these are always very simplistic. Even in most rhythm games there are certain rules that the player needs to learn and understand in order to play well. A big part is also learning the melodies that make up each level. Why? In order to optimally place your inputs (be that fingers or feet) to hit as many beats as possible. All of these aspects boil down to one thing: being able to predict the future.
You see the same thing in most games. You get better at Darks Souls when you understand how monsters attack, how levels are laid out and how your own attacks work. Learning how a world operates and gaining the ability to predict is a cornerstone of competence. Sure, you also need to develop the motor skills to carry out the required actions, but this is almost always less important than understanding the whys and whens of the actions. Simply being able to predict is not enough, you also need to have a sense of what goal you are trying to achieve and then, using your predictive abilities, to carry out the steps required to reach it. Or in other words: you need to be able to plan.
Autonomy is also highly dependent on the ability to plan. Imagine a game where you have plenty of freedom, but have no idea how the game works. Everybody who has booted up a complex strategy game without understanding the basics knows that this is not very engaging. In order for the freedom to mean something, you need to have an idea what to do with it. You need to understand how the game’s mechanics behave, what tools are at your disposal, and what goals you want to achieve. Without this, freedom is confusing and pointless.
So in order to provide a sense of autonomy a game needs to not only provide a large possibility space, but also teach the player how the world works and what the player’s role in it is. The player needs to be able to mentally simulate various actions that can take place, and then come up with sequences that can be used to attain a specific goal. When you have this, you have freedom that is worth having. It should be pretty obvious that I am again describing the ability to plan. A world in which the player is not able to plan is also one with little autonomy.
Similarly, if the game only features a linear sequence of events, there’s not much planning to be done. In order for the player to be able to craft plans there need to be options. This is not the case if only a certain chain of actions is possible. This scenario is a typical example of having no freedom, and unsatisfactory in terms of autonomy. Again, planning and autonomy are intricately linked.
One could make the case that Relatedness also has a connection with planning. As explained earlier, any social interactions heavily rely on our ability to plan. However, I don’t think this is strong enough and the other two aspects are more than enough. Instead let’s look at evidence from a different angle.
One trend that has been going on for a long time in games is the addition of extra “meta” features. A very common one right now is crafting, and almost all big games have it in some way or another. It’s also common to have RPG-like levelling elements, not just for characters, but for assets and guns as well. Collecting a currency that can then be used to buy a variety of items also turns up a lot. Take a look at just about any recent release and you are bound to find at least one of these.
So why do games have them? The answer to that is quite easy: it makes the game more engaging. The harder question is why that should be the case. It can’t solely be because it gives the player more to do. If that was the case you would see games adding a random variety of mini games to spice things up. But instead we are seeing certain very specific types of features being used over and over again.
My theory for this is that it’s all to do with planning. The main reason that these features are there is because it gives the player a larger possibility space of plans, and more tools to incorporate into their planning. For instance, the act of collecting currency combined with a shop means that the player will have the goal of buying a particular item. Collecting a certain amount of currency with a view to exchange it for goods is a plan. If the desired item and the method in which the coins are collected are both connected to the core gameplay loop, then this meta feature will make the core loop feel like it has more planning that it actually has.
These extra features can also spice up the normal gameplay. Just consider how you need to think about what weapons to use in combat during The Last of Us. You have some scrap you can craft items from, and all of those items will allow you to use different tactics during combat. And because you cannot make all of them, you have to make a choice. Making this choice is making a plan, and the game’s sense of engagement is increased.
Whatever your views on this sort of meta-feature are, one thing is certain: they work. Because if they weren’t we wouldn’t be seeing this rise in them persist over such a long time. Sure, it’s possible to make a game with a ton of planning without any of these features. But that’s the hard way. Having these features is a well-tested way to increasing engagement, and thus something that is very tempting to add, especially when you lose a competitive advantage by not doing so.
Finally, I need to discuss what brought me into thinking about planning at all. It was when I started to compare SOMA to Amnesia: The Dark Descent. When designing SOMA it was really important for us to have as many interesting features as possible, and we wanted the player to have a lot of different things to do. I think it is safe to say that SOMA has a wider range of interactions and more variety than what Amnesia: The Dark Descent had. But despite this, a lot of people complained that SOMA was too much of a walking simulator. I can’t recall a single similar comment about Amnesia. Why was this so?
At first I couldn’t really understand it, but then I started to outline the major differences between the games:
Amnesia’s sanity system
The light/health resource management.
Puzzles spread across hubs.
All of these things are directly connected with the player’s ability to plan. The sanity system means the player needs to think about what paths they take, whether they should look at monsters, and so forth. These are things the player needs to account for when they move through a level, and provide a constant need to plan ahead.
The resource management system works in a similar fashion, as players need to think about when and how they use the resources they have available. It also adds another layer as it makes it more clear to the player what sort of items they will find around a map. When the player walks into a room and pulls out drawers this is not just an idle activity. The player knows that some of these drawers will contain useful items and looting a room becomes part of a larger plan.
In Amnesia a lot of the level design worked by having a large puzzle (e.g. starting an elevator) that was solved by completing a set of spread out and often interconnected puzzles. By spreading the puzzles across the rooms, the player needs to always consider where to go next. It’s not possible to just go with a simple “make sure I visit all locations” algorithm to progress through the game. Instead you need to think about what parts of the hub-structure you need to go back to, and what puzzles there are left to solve. This wasn’t very complicated, but it was enough to provide a sense of planning.
SOMA has none of these features, and none of its additional features make up for the loss of planning. This meant that the game overall has this sense of having less gameplay, and for some players this meant the game slipped into walking simulator territory. Had we known about the importance of the ability to plan, we could have done something to fix this.
—
A “normal” game that relies on a standard core gameplay loop doesn’t have this sort of problem. The ability to plan is built into the way that classical gameplay works. Sure, this knowledge can be used to make such games better, but it’s by no means imperative. I think this is a reason why planning as a foundational aspects of games is so undervalued. The only concrete example that I have found[1] is this article by Doug Church where he explains it like this:
“These simple, consistent controls, coupled with the very predictable physics (accurate for a Mario world), allow players to make good guesses about what will happen should they try something. Monsters and environments increase in complexity, but new and special elements are introduced slowly and usually build on an existing interaction principle. This makes game situations very discernable — it’s easy for the players to plan for action. If players see a high ledge, a monster across the way, or a chest under water, they can start thinking about how they want to approach it.
This allows players to engage in a pretty sophisticated planning process. They have been presented (usually implicitly) with knowledge of how the world works, how they can move and interact with it, and what obstacle they must overcome. Then, often subconsciously, they evolve a plan for getting to where they want to go. While playing, players make thousands of these little plans, some of which work and some of which don’t. The key is that when the plan doesn’t succeed, players understand why. The world is so consistent that it’s immediately obvious why a plan didn’t work. “
This is really spot on, an excellent description of what I am talking about. This is an article from 1999 and have had trouble finding any other source that discuss it, let alone expands upon the concept since then. Sure, you could say that planning is summed up in Sid Meier’s “A series of interesting choices”, but that seems to me too fuzzy to me. It is not really about the aspect of predicting how a world operates and then making plans based on that.
The only time when it does sort of come up is when discussing the Immersive Sim genre. This is perhaps not a big surprise given that Doug Church had a huge part in establishing the genre. For instance, emergent gameplay, which immersive sims are especially famous for, relies heavily on being able to understand the world and then making plans based on that. This sort of design ethos can be clearly seen in recent games such as Dishonored 2, for instance [2]. So it’s pretty clear that game designers think in these terms. But it’s a lot less clear to me that it is viewed as a fundamental part of what makes games engaging and it feels like it is more treated like a subset of design.
As I mentioned above this is probably because when you take part in “normal” gameplay, a lot of planning comes automatically. However, this isn’t the case with narrative games. In fact, narrative games are often considered “lesser games” in the regard that they don’t feature as much normal gameplay as something like Super Mario. Because of this, it’s very common to discuss games in terms of whether you like them to be story-heavy or gameplay-heavy, as if either has to necessarily exclude the other. However, I think a reason there is still such a big discrepancy is because we haven’t properly figured out how gameplay in narrative games work. As I talked about in an earlier blog post, design-wise, we are stuck at a local maxima.
The idea that planning is fundamental to games presents a solution to this problem. Instead of saying “narrative games need better gameplay”, we can say that “narrative games need more planning”.
—
In order to properly understand what we need to do with planning, we need to have some sort of supportive theory to makes sense of it all. The SSM Framework that I presented last week fits nicely into that role.
It is really best to read up on last week’s blog post to get the full details, but for the sake of completeness I shall summarise the framework here.
We can divide a game into three different spaces. First of all we have System space. This where all the code is and where all the simulations happen. The System space deals with everything as abstract symbols and algorithms. Secondly we have the Story space which provides context for the the things that happen in the System space. In System space Mario is just a set of collision boundaries, but then when that abstract information is run through the Story space that turns into an Italian plumber. Lastly, we have the Mental Model space. This is how the player thinks about the game and is a sort of mental replica of all that exists in the game world. However, since the player mostly never understands exactly what goes on System space (nor how to properly interpret the story context), this is just an educated guess. In the end though, the Mental Model is what the player uses in order to play the game and what they base their decisions on.
Given this we can now start to define what gameplay is. First of all we need to talk about the concept of an action. An action is basically whatever the player performs when they are playing the game and it has the following steps:
Evaluate the information received from the System and Story space.
Form a Mental Model based on the information at hand.
Simulate the consequences of performing a particular action.
If the consequences seem okay, send the appropriate input (e.g. pushing a button) to the game.
A lot of this happens unconsciously. From the player’s point of view they will mostly view this sequence as “doing something” and are unaware of the actual thought process that takes place. But really, this always happens when the player does something in a game, be that jumping over a chasm in Super Mario or placing a house in Sim City.
Now that we understand what an action is, we can move on to gameplay. This is all about stringing several actions together, but with one caveat: you don’t actually send the input to the game, you just imagine doing so. So this string of actions are built together in mental model space, evaluating them and then if the results feel satisfactory, only then do we start to send the required input.
Put in other words: gameplay is all about planning and then executing that plan. And based upon all of the evidence that I showed above, my hypothesis is: the more actions you can string together, the better the gameplay feels.
It isn’t enough to simply string together any actions and call that a plan. First of all, the player needs to have an idea of some sort of goal they are trying to achieve. The actions also need be non-trivial. Simply having a bunch of walking actions strung together will not be very engaging to the player. It’s also worth pointing out that planning is by no means the only thing that makes a game engaging. All other design thinking doesn’t suddenly go out the window just because you focus on planning.
However, there are a bunch of design principles that go hand in hand with planning. For instance, to have a consistent world is crucial, because otherwise it isn’t possible for the player to form a plan. This is why invisible walls are so annoying; they seriously impede our ability to create and execute plans. It also explains why it’s so annoying when failure seems random. For gameplay to feel good, we need to be able to mentally simulate exactly what went wrong. Like Doug Church expressed in a quote above: when a player fails they always need to know why.
Another example is the adventure game advice that you should always have several puzzles going at once. In planning terms this is because we always want to make sure the player has ample room to plan, “I will first solve this and then that”. There are lots of other similar principles that have to do with planning. So while planning is not the only thing that makes a game engaging, a great number of things that do can be derived from it.
Let’s quickly look at some examples from actual games.
Say that the player wants to assassinate the guy in red in this situation. What the player does not do is simply jump down and hope for the best. They need to have some sort of plan before going on. They might first wait for the guard to leave, teleport behind the victim, and then sneak up and stab them. When that’s done they leave the same way they came. This is something the player works out in their head before doing anything. It isn’t until they have some sort of plan that they start acting.
This plan might not work, the player might fail to sneak up on the guy and then he sound an alarm. In this case the plan breaks, however that doesn’t mean that the player’s plan was totally untrue. It just meant they didn’t manage to pull off one of the actions of. If presented properly, players are okay with this. In the same way, the player might have misinterpreted their mental model or missed something. This is also okay as long as the player can update their mental model in a coherent fashion. And next time the player tries to execute a similar plan they will get better at it.
Often this ability to carry out your plans is what makes the game the most engaging. Usually a game starts out a bit dull, as your mental models are a bit broken and the ability to plan not very good. But then, as you play, this gets better and you start stringing together longer sets of actions and therefore having more fun. This is why tutorials can be so important. They are a great place to get away from that initial dullness by making the experience a bit simpler and guiding the player to think in the correct manner about how the game works.
It’s also worth noting that plans should never be too simple to carry out. Then the actions become trivial. There needs to be a certain degree of non-triviality for engagement to remain.
Planning doesn’t always need to happen in the long term, it can also be very short term. Take this scene from Super Mario, for instance:
Here the player needs to make a plan in a split second. The important thing to notice here is that the player doesn’t simply react blindly. Even in a stressful situation, if the game works as it should, the player quickly formulates a plan and then tries to carry out that plan.
Now compare these two examples to a game like Dear Esther:
There are a lot of things one can like about this game, but I think everybody agrees that the gameplay is lacking. What’s harder to agree on, though, is what’s missing. I’ve heard a lot about the lack of fail states and competitive mechanics, but I don’t find these convincing. As you might guess, I think the missing ingredient is planning.
The main reason that people find Dear Esther unengaging is not because they cannot fail, or because there is nothing to compete against. It’s because the game doesn’t allow them to form and execute plans. We need to figure out ways of fixing this.
By thinking about the planning in terms of the SSM-framework we get a hint at what sort of gameplay that can constitute “narrative play”: When you form a plan in Mental Model space it is important that the actions are mostly grounded in the data received from Story space. Compare the the following two plans:
1) “First I pick up 10 items to increase the character X’s trust meter, this will allow me to reach the ‘friendship’-threshold and X will now be part of my crew. This awards me 10 points in range combat bonus.”
2) “If I help out X with cleaning her room, I might be able to be friends with her. This would be great as I could then ask her to join us on our journey. She seems like a great sharpshooter and I would feel much safer with her onboard.”
This is a fairly simplistic example, but I hope I get the point across. Both of these describe the same plan, but they have vastly different in how the data is interpreted. Number 1 is just all abstract system-space, and the number 2 has a more narrative feel, and is grounded in the story space. When the gameplay is about making plans like the second example, that is when we start to get something that feels like proper narrative play. This is a crucial step in evolving the art of interactive storytelling.
—
I believe thinking about planning is a crucial step in order to get better narrative games. For too long, game design has relied on the planning component arising naturally out of ‘standard’ gameplay, but when we no longer have that we need to take extra care. It’s imperative to understand that it drives gameplay, and therefore that we need to make sure our narrative experiences include this. Planning is by no means a silver bullet, but it’s a really important ingredient. It’s certainly something that we’re putting a lot of thought into when making our future titles here at Frictional Games.
Footnotes:
1) If anyone has other concrete resources describing planning as a fundamental part of games I’d love to hear about them. Please post about them in the comments if you know any.
2) Steve Lee had an excellent lecture called “An Approach to Holistic Level Design” at this year’s GDC where he talked a lot about player intentionality. This is another concept closely related to planning.
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.
System
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
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:
The steps are as follows:
The users triggers an input on the controller and this data is sent to System space. Example: The fire button is pushed.
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.
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.
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!”.
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.
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.
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.
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.
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.
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.
Footnotes:
[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.
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.
