Friday, 30 May 2014

ParticleEditor updates

Hey! Today I'm sharing the results of the last two weeks of work on the ParticleEditor with you. I've had loads of time for additions and improvements -- I'm just gonna go over the most notable ones briefly:

  • Live update of particles: No more resetting the whole particle system to see the effect that little parameter you changed actually has!
  • Control of the update speed: Something looks weird but you can't spot what it is? Just slow the whole thing down. Works everytime.
  • Easing functions for fading values: We don't have tweakable curve controls just yet, but these work like a charm in the meantime. 
  • Helper graphs: A really nice addition so you can preview how fades are going to work. Together with easing functions, a slider and the live update, this is fun just to play around with.
Of course, a little video works way better than words for showing these off, so here it is:



Friday, 23 May 2014

People of Frictional: Aaron Clifford

Ninth post in the series. You can read the other posts here.

Who am I?

Hello! I’m Aaron Clifford, one of the artists here at Frictional Games. Right now there are four of us artists and I’m relatively new around here. I started collaborating with Frictional back in April 2012 as a contractor, making props and other smaller bits for SOMA. A few months later I was brought on to the team full-time and, as they say, the rest is history.

Since we all work remotely, I do my stuff from my home in a suburb of London, England. I was the only one representing the British in Frictional for a while, but now we have a few! You'll get to see their blog posts and learn about them soon, I’m sure.


Background

Hanging out at San Francisco pier.
Like any kid back in the 90s I had the pipe dream of one day growing up and making video games. I guess I just clung on to that dream a little longer than some of the others. Games in one form or another have always been with me; I think the first time I got my little hands on a video game must have been on the Amiga 500. I have very vivid memories of California Games, Prince of Persia and a pretty obscure game called It Came from the Desert. I was stuck with that machine and a Sega Master System (for which I only had a couple of games, including the built-in Alex the Kid) long after those became redundant until I was given £100 after my family sold our house. I blew it all on buying a Sega Megadrive/Genesis, only to have it stolen by the people working on our new house. They actually replaced the console inside the box with a couple of bricks!

Fast-forward past a few years of crying and I finally got my Megadrive (which I never let out of my sight), Playstation and eventually a PC which is when I started digging into the inner workings of games.

Inspired by old Sierra games I always wanted to make a point & click adventure. I remember scrawling countless pages of story and scribbling level plans for the game I wanted to make. I can’t really remember what it was, but it was something along the lines of a Broken Sword & Resident Evil amalgamation.

Then Half-Life and Counterstrike were released along with their mod tools and I started playing with the Hammer editor, making maps for CS which me and a few friends would play around in, stuff like “jump maps” (remember those?) and grenade dodgeball arenas. This was when I decided that, in my pipe dream of becoming a game developer, I'd take the path of a level artist. Having people run around inside my creations and enjoying themselves really gave me a lot of satisfaction.
Prometheus - A puzzle game I helped out with on level design.
So after high school I signed up for a college course that centered on computer games, digital art and media. Unfortunately it left a lot to be desired - I came away with just a few basic Photoshop and Flash skills. Undeterred and determined to make it into the industry I took it upon myself to learn the tools of the trade. I grabbed some free 3D programs like Milkshape and Blender and I started making guns, cars, space ships & crates (as is usual for a new 3D artist!) and eventually established myself in the modding community, helping out on various overly ambitious projects that eventually collapsed, but nonetheless making a lot of friends who would become professionals in the industry. A few are still good friends to this day. 
A little tower defense/RTS me and a couple friends made for iOS devices.

Like a few of us at this company I never landed a big job in a proper studio, instead I lent my skills to various projects as a freelancer, making enough money to get by. I did that for a couple of years but the unstable nature of freelancing didn’t really appeal to me. I applied to a few off-site fulltime jobs and some studios in London - due to family stuff I couldn’t really move out of London at the time - but finding a job in games around here is surprisingly tough. I struck it lucky when applying to a job posting at Frictional Games. I remember seeing the Penumbra tech demo and really digging it; Amnesia had just blown up and first-person horror was the order of the day. What Frictional was doing at the time was really quite unique and interesting to me so I was happy to see in the job description that people here work remotely which suited my situation perfectly.

I was always happiest working long-term with a team on a project we all care about. Frictional Games is really fulfilling for me in that respect, it’s like being back working on a project with friends only now I get paid and we actually release things.

What do I do?

An artist at Frictional has to wear many hats. This is something I’ve always been used to, and when friends tell me all they do is make textures all day or work on vehicles, I can never get my head around that. We generally work on whatever graphics that need creating for the project.

Every artist is usually responsible for a level each. We will pair up with a scripter and work on a level for 4-8 weeks bringing it from an empty space into a level in which the player can run around in, interact and advance the story. This doesn’t mean the work is done on the level at the end of our scheduled time on it, it just means by the time the weeks you have on it are up, there should be a decent amount of atmosphere to portray the mood of the level and you should be able to play through it from start to finish with all of the major events and activities in the design document present. At a later date I (or another artist) will come back to it to either change/rework it due to a design decision or if the design is solid, just work on the visuals more and bring it up to a better standard.

The number of tools I use has gone down a lot over the years and as software has improved. Day-to-day I use Modo for all my 3D polygon-pushing needs, Photoshop for my texture painting and HPL3’s toolset for everything game related.

Allow me to take you on a quick journey through the creation of a game asset from idea to game.

It usually starts with having a sketch kindly provided by Rasmus Gunnarsson or David Satzinger, two of our artists who are gifted in the traditional arts and visualisation. Not always, however, a lot of the time we just need to use our own imaginations and come up with designs for things on-the-fly.
Excerpt from concept art of the corpse on the table.
I usually start by making a high resolution mesh of the object. There are no limits on polygon counts here, this mesh is made up of millions and will be used to “bake” down detail to the lower-resolution in-game mesh.
Looking good there, Raznik.
Then I make the low polygon mesh. This will be the one that displays in game, so the polygon count is a factor here. The main objective is to have a silhouette that's as smooth as possible so curves don’t look choppy or faceted. Polygons have been saved by not modelling the torso or any face details, as they will be covered up by the sheet in game. Every little helps!
Poor Raznik doesn't even have a torso now.
Now I’ll “UV Map” the model, which is the process of basically unfolding the mesh into a 2D representation - like reverse-engineering a cardboard box and flattening it all out. That UV Map is then painted over in Photoshop to give it color, texture and make it look real.
In this case, as seen in our debut gameplay trailer, our Raznik is going to thrash around, so he'll need animation. He’s given a skeleton and handed over to one of our talented outsourcers for animating. Mikael Persson brought Raznik to life in the trailer.

The model is then brought into the HPL Model Editor for setup. This includes adding collision so the player can’t walk through it, adding any animations for triggering in script, attaching lights, effects or sounds - whatever's needed for the type of asset you’re creating.
Bringing Raznik back to life.
The model is now placed into the game world by using the HPL Level Editor. This is pretty much the end of the line for the artist. It is now the scripter’s responsibility to make Raznik squirm and scream in pain when the player pokes around with him. Without the scripter’s input, he would just lie there motionless and that’s not very scary at all...
Ready for his 15 seconds of fame.
The finished product as seen in our debut gameplay trailer.

I hope this was an interesting insight into who I am and what an artist does at Frictional Games. If you have any more questions, drop me a line in the comments and I’ll be happy to answer them.

Thanks for reading!


Monday, 19 May 2014

People of Frictional: Luis Rodero

Eighth post in the series. You can read the other posts here.

Who am I?

Hi! I'm Luis Rodero, and I'm the target of all nagging and the shoulder to cry on when everything goes to hell. In other words I'm the tools programmer here at Frictional. I started back in 2006 (that's a while!) as a contributor; I made a few minor additions to the HPL Engine and then not-so-minor ones (like the OpenAL implementation that was added back in the day). I was hired for full-time work in 2008, when work on Amnesia had just started.

I live in Seville, southern Spain, home of the Feria de Abril, the Serranito and the Springmmer season from Hell, which starts in April-ish and spans until late October and can easily melt a human brain if no countermeasures are taken. Since we all work remotely, I've actually tried quite a range of places to do my stuff, like every room in my previous apartment, study rooms at my former school, trains, planes... but nothing beats having a dedicated office space at home.

This here looks nicer than it usually does.

Background

As a kid, I was really into finding out how stuff worked. Generally that involved ripping things open, much to my parents' disappointment of course. I also had an unhealthy attraction to videogames, which meant I vanished into thin air a lot only to be found at the nearest arcade in town. I got my first computer in the 80s and used to play games on it for countless hours; but it also came with these 'intro to BASIC programming' books that I thought were pretty cool, although I had no idea what I was doing when trying out the examples.

Beautiful and still working after more than 25 years (pic by Museo8Bits).

For a few years I moved my focus away from programming and just played stuff on my Master System and a few years later on my Mega Drive, as I was quite a Sega fanboy (you could have killed past Luis by telling him a Sonic game had been released on a Nintendo console, go figure). But as time went on it wasn't fulfilling enough. That's when I targeted my father's PC (sorry dad). I still played a lot of stuff, but I never lost that itch for knowing how stuff worked, so that meant the PC was sent for technical support a load of times (again, sorry dad), but it also meant I learned a lot from trial and error. It wasn't until I found Alone In The Dark that I became determined to learn how a game was made. Man, that game hit me hard.

Before jumping head-first into learning how to program, I tried pretty much everything: drawing pixel art, frame by frame animation, composing music in trackers, 3D modelling... I also created a mods for Doom and Duke Nukem 3D, and, while I learned a lot and had a lot of fun, I realised that if I had a forte, it was not on the artistic side of the craft. So I started to focus on the technical side. I used to open any kind of file in a game with a text editor (and also with a hexeditor, but I didn't know that's what it was until quite a long time later), just to see how it looked. Most of the time it was illegible nonsense, but sometimes I found stuff I could read, and that's how I learned to change strings in EXE files. But this was clearly not enough, so one day I got my hands on a C programming book.

Not my best look, but the tentacles make up for that (wait, that sounded weird).

I must say I never finished a single project I started back in the day, but I got to try out a lot of stuff in the process, and even more so when I found the Allegro libraries. I read lots of books and articles on the subject, and went through lots of source code for projects by others -- that was a great source of knowledge. I managed to do a broken shmup, a base system for a point&click adventure game, and my best work at the time, a Tetris clone that was so crappy I named it "tris-Te" (some basic understanding of Spanish will help you get this one). After that, I carried on with the learning and started checking out stuff like OpenGL, and that's when I came across a little game called Fiend on the Allegro depot, created by some guy called Thomas Grip.

Back in October 2004 (nearly ten years ago), I was still working on getting my degree in CS and looking for projects to work on for hobby, and then I checked this Thomas Grip guy out again, as after playing Fiend I knew he could pull off cool stuff. Turned out he was working on another game called Unbirth. That's when I approached him on the Unbirth forums. The rest is pretty easy to figure out. I had never seriously thought of doing this for a living, and now I feel I wouldn't be able to do anything other than this.

What do I do?

My main task here is to build and maintain the tools we use for creating content for our games. This means I'm in charge of the LevelEditor, ModelEditor, ParticleEditor and MaterialEditor programs. I made these pretty much from scratch, working on top of the HPL engine. This should make everything in the editors look just like it would do in a game powered by it. Occasionally I do bits of level scripting or other kinds of programming, but this is what I do most of the time.

The way the tools evolve is tightly coupled to how the engine changes. If, for instance, a new type of object is added to the map class in the engine, it would be weird if it didn't end up being added as a placeable object type in the LevelEditor. On top of that, we have changes to improve our workflows - for example, when an operation proves to be too time-consuming we look for ways to improve the editors to make that easier.

At the time of this writing, the tools are already huge, growing even bigger every day, but I can't just add features carelessly. One of the main goals of having custom tools is to make them suit our needs as much as possible, and that also implies paying a lot of attention to the user experience.

With this in mind, adding a new feature means that it should:
  • Work properly (would be weird to fail at this one)
  • Be straightforward
  • Be as quick to use as possible (the fewer clicks the better)
  • Have as much visual feedback as possible (where this applies)
This takes time to figure out, and will most probably require a couple of iterations and some feedback from users to become a good enough addition.

And where do these new features come from? Most of the time they are user requests, since when one is working with the tools, it might become obvious that some processes feel cumbersome and could be made simpler. Other requests come up from comparisons to other editors - 'hey, UDK has that feature, can we have it?' Also, if something reasonably simple can be done to save a user from having to alt-tab out of the editor to carry out an external task, that sounds like a good feature to me.

It begins with the description of the feature: what it should do and maybe a little overview on how. Then it's time for a preliminary design, which shouldn't be excessively detailed, since chances are we are gonna run into something at the time of integrating the feature into the system that we never took into account.

Once the first design is done, a first implementation is carried out. This should be done and put out to test as quickly as possible, to find flaws or possible improvements in the first stages.

After the first approach is tested, then any issues or requests in the feedback should be fixed. It's very unlikely that a feature turns out to be perfect or even acceptable before any checking (unless we are talking about really small ones), so here's where the feature is really shaped up.

Once the issues are fixed, it should be tested again. If no bugs or weird stuff pops up after that, then the feature makes it to the toolset. And that's how we make it!

Looking fishy if you ask me.

Of course, the job doesn't come without problems. The main issue I face everyday is the fact that most of the stuff I have is based on code that's been there since we started work on Amnesia, when I had little to no idea on how things should be done. Since then, I've been working hard to migrate to a design that automates as much as possible and makes it easy to add or improve features. I'm kind of happy with what we have currently, but I know I can do way better than this.

Another issue is that we're dealing with software here. If something can break, it will break. And that will mean someone (most probably Marc) will come at me complaining about something broken. And then I'll have to stop what I'm doing at the time and move on to fixing stuff until that someone goes back to their normal happy state again.

So summing up, my workday revolves around keeping people happy (a noble cause, actually), and otherwise adding new stuff or improving the existing stuff. Hope you liked finding out more about what I do here, and see you in the next post on new tool features!


Thursday, 8 May 2014

People of Frictional: Patrik Dekhla

Seventh post in the series. You can read the other posts here.

Who am I?
I'm Patrik Dekhla, scripter and gameplay programmer. I joined Frictional back in 2012 and since then I've worked full-time on SOMA, making the gameplay feel awesome and terrifying.

Like the rest of the team, I work from the comfort of my home, which is in the south of Sweden. This is how my workspace looks (only it's generally a lot messier):


Background
Growing up, I always had games around me thanks to my gamer dad, which sparked my gaming interest at a very early age. This developed into a bit of an obsession over time, and for a large part of my childhood almost all my thoughts circled around games. If I wasn't playing games, I pretended real-life was a game or drew game levels on pieces of paper and "played" them in my head. I'm not sure how healthy all of that was.

I always loved it when games came with editors, as I usually found playing around with those even more fun than the games themselves. I tried learning QBasic (an old programming language) when I was 9 or 10 years old and managed to make some terribly written text adventures in it. That was about as close I got to making games for a very long time. Even though it seemed like a cool thing to do, I just didn't know where to start.

As I grew up, I stayed interested in games but outgrew the obsession a bit. I studied acting for a good while and thought for sure that was what I would be doing professionally in the future. Then, as I was looking to take the next step in my education, I got a postcard dropped on me from The Game Assembly, a game development school, and something convinced that I had to give this a shot. I sent them an application and got accepted.

The education was brutal. Some weeks we would only leave school to eat or sleep. Some nights I slept in a couch at school to save time. We had tests that almost everyone failed at. We had to come in on weekends to fix old projects. We got conflicting, vague or just plain weird guidance from our teachers. The entire experience bounced back and forth between amazing and horrifying. But in the end it was worth it for all the things I had learned. Game development was no longer a mystery.

RTS/Stealth game made at school

After my 6 month internship at a studio in Denmark, I saw a blog post about Frictional hiring a scripter and decided to apply. After an interview, a work tests and some nervous waiting, I got a nice mail from Jens letting me know I was welcome aboard.

What do I do?
Though I get to do work in a lot of different programming, scripting and design areas, most of the time I work in AngelScript, scripting events and interactions specific to a certain level.

My work on a level starts after Thomas has written the design and an artist has had the chance to build the most essential parts of the level. I have a long meeting with Thomas about the design, divide the different scenes and events into tasks and get started.

The first thing I do is to script a rough version of the most important events to get a sense of how things will play out. As I do this, some design issues usually make themselves apparent and I have to deviate a bit from Thomas' instructions. This is natural as it's not possible to write a flawless design document without trying things out in the game.

Once I'm done with this rough outline, I get some feedback on the progress so far and start to flesh things out further. This means among other things that the events get a dose of nice looking screen effects and sounds, some of the timing is reworked and fail-safes are added in case the player behaves in unexpected ways. Some puzzles and events need multiple iterations before they feel quite right, and some times they simply never do and they get removed and replaced by something completely different.

Eventually the entire team gets to play through the level and give their feedback. Based on the feedback I spend about a week more tweaking and fixing until the level is all nice and shiny. Then I move on to a new level.

Of course, the level is still not done. There are still proper sounds that need to be added, art that has to be polished and voiceovers that have to be implemented; not to mention all the redesign that happens as we refine the game as a whole. So eventually I'll have to return to the level once more to tweak and fix.

That should at least give you an idea of what it is that I do. It's a very fun process really. With SOMA we're trying to do a lot of interesting stuff around how the player interacts with the story, which means that with each level I work on I'm faced with some totally new and cool design challenges to overcome. I'm looking forward to seeing your reactions to some of my stuff when the game is released!


Monday, 5 May 2014

Alien: Isolation and The Two Hardest Problems in Horror

Introduction
So I recently saw this reaction video to Alien Isolation and I thought it showcased a few interesting problems with horror games. These are not issues that are specific to this game, but that plague horror games in general. We've had these problems in all of our games and are currently trying avoid them as much as possible in our upcoming game, SOMA. So I'm not trying to take a shot at Alien Isolation here (I'm looking forward to playing it!) but the video demonstrated these issues so clearly that it's worth focusing on it for this article. That said, let's move on to the two hardest problems in horror.


1) Death Means Relief and Repetition
If you watch the video you can see that the players aren't being freaked out of their minds when they die. They're laughing, and feeling relief. And the death sequence is non-interactive, which further enhances this sense of sitting back and becoming a spectator. You can clearly see the effect here, where there's a stark difference in emotion compared to the fear that was expressed earlier.  So when a death occurs, the situation has lost its sense of fear and the unknown. The player now knows what they're up against. It's gone from tense terror to "I need to beat this gameplay section".

We saw this in Penumbra Overture, where the player's experience of a chase sequence depended on the number of attempts. And what's important to note is that even if the first one or two attempts are exciting, the frustration that ensues from repeated attempts will spoil those initial memories and the sequence as a whole. Of course, there are only a certain percentage of players that will have this bad experience, and if that number's low enough it might not be such a big issue. But if your game is based around this kind of experience, like Alien Isolation and many other horror games are, then it becomes a much bigger problem. The game is under constant danger of losing its basic tension, the most fundamental ingredient of engagement that a lot of the game depends on.

What's the solution for this, then? The only proper solution is to make sure that death is postponed. Outlast has a monster that throws you to one side, giving you a chance to run off, a mechanic that works well in its story. Daylight has damage build up on the screen, which gives you time to escape. Both of these are great ways of extending the terror. Some kind of death must happen sooner or later, though, or the player will quickly realize that the monster is harmless - and that's no good at all. When death occurs I think it's important to remove this sense of repetition. For instance, in Amnesia we changed the map a bit after each death (which in some cases led to additional scares).

It might also be interesting to look into 'a fate worse than death', a subject that's perhaps too big to cover here (check here for some examples in various media). This is something we're trying out for SOMA right now. The basic idea is that "death" is not final but takes the player closer and closer to a very disturbing state of being.

I think the crucial point here though is to think outside the mechanics and to trust the player to be immersed in the fiction. From an abstract point of view of the game, there are only three options really: repeating, branching or skipping a section. Whichever is chosen the important thing is to keep the player in the right mindset and let their immersion do the bulk of the work.

2) Monster Exposure Makes The Horror Familiar
If you don't have weapons in your horror game - which, for many reasons, should be the case (for those needing arguments see this talk) - then you need to have some form of avoidance. This in turn leads to longer periods where the player's forced to pay attention to the danger, i.e. looking straight at it. This means that the player gets used to the monster,  figuring out details and their mental picture of the beast breaks down into the prosaic reality of the implementation. In the worst case, the player will start noticing AI glitches and animation issues. The possibility space for the danger is reduced and it becomes obvious to the player that the monster is just a puppet.

This is a serious problem. It's well known that the most effective horrors are the unseen ones. This is obvious in the most successful horror books and films. If games want to achieve good horror, they need to keep this in mind and be careful when and how the monster is seen. Having said that, I think that games have a bit more leeway, because players are not just passive observers but are also engaged in an activity and responsible for the outcome, and therefore prone to take the monster more seriously.

Which brings us to the first problem: showing the monster in a cutscene (as Alien: Isolation can be seen doing here). I can understand the reason for doing this, to be certain that the players "get it". But this is a major dent in the creature's effective level of horror. You leave the player passive, and free to notice tons of detail about the monster in a much more relaxed way than if they were the ones in control. It also means that you're missing out on making one of the most potent horror moments interactive. The reveal of the monster is almost always a high point in a horror story; it's such a waste to let it be a non-interactive part of the game. Actually, they've already had a good reveal moment here, which I feel could have been used better. This one also perfectly nails the proper alien look: a swirling mass of Giger-esque limbs and claws.

The problems deepens as the game progress. Here is a good example of this. Just imagine what sort of AI quirks and animation issues might pop up when you are under a desk and the alien is a few meters away in a tight space. On top of that, the player is getting a really good look at the creature, just throwing away any chance of the player having their own subjective mental image of the beast.

This is really hard to solve. Outlast has a good solution where they use the night vision mode on the camera to blur out the monster features and add creepy glowing  eyes. It doesn't work for the entire game, of course, but it makes it possible to have more glimpses of the monster without lessening the scare factor. In Amnesia we had the player's vision blur when a monster was in sight, something that worked pretty well. Or an even more successful monster was the water lurker, that just gave away its position with splashes in the water.

The best solution is really simple, though; keep monster encounters down to a minimum. I think the first basic problem is to rely on "monster hunts player" as a core gameplay foundation in the first place. This also exposes another big problem in horror games. If the monster hunting you is not what makes up the majority of the playing time then what does? This is an even harder nut to crack than the problems presented in this article.

In SOMA we try and solve this with a couple of tricks. First, all of the monsters are connected to the narrative; the more you figure out about them, the more you understand of the story. Therefore simply just looking for signs of monsters becomes a more interesting activity (compared to a game where the monster itself is not that interesting story-wise), and we can make do with fewer encounters. The inspiration from this comes from the SCP Foundation wiki, a collaborative database for weird artifacts, where many of the really spooky entries are just a collection of vague clues about a creature. Second, we keep the types of monsters fresh and varied throughout the game (which should fix one of the bigger issues in Amnesia: TDD). Finally, all of the monsters are connected to a sort of "worse than death" mechanic, to give the feeling that the encounters are more disturbing than simply "I will get a death screen if it catches me".

Endnotes
Again, I want to make it really clear that these problems are not specific to Alien: Isolation. These are things that just about every horror game struggle with, including our previous efforts and our upcoming Soma. Alien: Isolation is looking good and I'm excited to play it once it comes out. But that doesn't mean that it's not worthwhile looking closely at it and discussing any problems that might arise. Also, I felt the reaction video was great a springboard for the topics covered in this post. For me as a developer these sort of discussions are crucial, and whenever I see footage of a new horror game, I try to analyze what things might and might not work in it.

Finally, it's really fun to see this kind of game being made by a large studio. I wouldn't have imagined that happening a couple of years ago. No weapons, few monsters etc. are features not very common in a high budget game. Hopefully Alien Isolation will do well enough for us to see more of this!


Tuesday, 29 April 2014

4-Layers, A Narrative Design Approach


Introduction
This blog post will be about a new way to approach narrative design in games - the 4 Layers Approach. It is based on a GDC talk I gave in March this year. The approach is primarily meant to suggest a workflow that focuses on the story and makes sure the narrative and gameplay are connected. The end goal is to create games that provide a better interactive narrative.


Narrative Basics
First off, "narrative" will need to be defined. At its most fundamental level, the narrative is what happens as you play the game over a longer period. It is basically the totality of the experience; something that happens when all elements are taken together: gameplay, dialog, notes, setting, graphics etc.; the player's subjective journey through the game. I know this clashes with other definitions that refer to narrative as a separate aspect of the game, but I think this is the one that's most helpful when discussing game design. It also fits with job titles such as "narrative designer", who is a person that doesn't just deal with writing or cut-scenes, but who works at a much higher level.

Quick note: A deep dive into various story-related terminology can be found here.

Let's compare this to the other basic elements of a game. Looking at a game second-by-second, you see the core mechanics. Moving up to look at it using a time-frame of minutes, you see tactics and problem-solving (which also includes things like puzzles). Higher still, often on the scale of hours, you see the narrative. Almost all game design is focused on the two lower levels, mechanics and tactics, and narrative mostly comes out as a sort of byproduct. Designing the narrative becomes a sort of patchwork process, where you try and create a coherent sense of storytelling from the small gaps left behind by the layers below. For instance, in games based on combat mechanics the narrative usually just acts as a form of set-up for encounters and is heavily constrained by how the fights work and so forth.

So a crucial step towards better storytelling in games is to give at least as much focus to the narrative layer as to the other two layers, mechanics and tactics. It is important to not devote all the focus to the story though; having a symbiosis between all of layers is a core element of what makes video games special. If we want proper interactive story, we need to preserve this.

Simply saying that we want to put more focus on the narrative level is still pretty vague; it doesn't tell us anything useful. So I'll make it a bit more concrete by listing five required cornerstones of an interactive story. This is where we get into highly subjective territory, but that can't be helped - there's a wide span of opinions on how narrative and gameplay should work together (some would even object to having focus on the narrative layer at all!). But in order to move on we need to have something concrete; if we just continue to talk in vague terms of "improving storytelling", any suggestion can be shot down on the basis of some personal preference. Doing it like that will just get us stuck in boring discussions and it becomes much harder to set a proper goal.


Core Elements of Storytelling
The following elements shouldn't prove too controversial and I think most people will agree with them. But it still feels important to acknowledge that this is an opinion and not something I regard as an eternal truth. That said, here are my core requirements for a game with focus on narrative.

1) The focus is on storytelling.
This is a trivial requirement, but still way too uncommon.  Basically, the main goal of the game should be for the player to experience a specific story.

2) The bulk of the gameplay time is spent playing.
We want interactive storytelling, so players should play, not read notes, watch cutscenes, etc. These things are by no means forbidden, but they should not make up the bulk of the experience.

3) The interactions make narrative sense.
This means actions that:
  • Move the story forward.
  • Help the player understand their role.
  • Are coherent with the narrative.
  • Are not just there as padding.
4) There's no repetition.
Repetition leads to us noticing patterns, and noticing patterns in a game system is not far away from wanting to optimize them. And once you start thinking of the game in terms of "choices that give me the best systemic outcome", it takes a lot of focus away from the game's narrative aspects.

5) There are no major progression blocks.
There is no inherent problem with challenge, but if the goal here is to tell a story, then the player should not spend days pondering a puzzle or trying to overcome a skill-based challenge. Just as with repetition this takes the focus away from the narrative.

There is a lot more that can be said about these requirements, all of which you can find here.


Good Examples To Strive For
Now for the crucial follow up question: what games satisfy these requirements?

Does Heavy Rain manage this? Nope, there's too little gameplay (requirement #2).

Bioshock, with all the environmental storytelling? Nope, too much shooting (requirement #4).

These two games symbolize the basic issues almost all video game storytelling have: either you do not play enough, or most of what the gameplay does is not related to the narrative.

There are a few good examples, though. Thirty Flights of Loving is a game that I think lives up to the requirements. But the problem here is that the storyline is extremely fuzzy and disjointed. The game is a series of vaguely connected scenes, and is lacking a certain pure storytelling quality.



We come much closer to finding something that lives up to the requirements by looking at specific sections in games. Two good ones are the giraffe scene in The Last of Us and the end sequence in Brothers: A Tale of Two Sons. Both of these sections have this strong sense of being inside a narrative and fulfill my requirements. You are definitely playing a story here. But these are just small scenes in a much larger game, and that larger game breaks most of the core elements that I have gone over.  So what we really want is to have a full game filled with these sorts of sections. That would be perfect!

However, that isn't possible. These scenes depend on tons of previous game content and are extremely hard to set up. You cannot just simply strive to fill the game with stuff like this, it's just not doable. In order to get a game that consistently evokes this feeling, we have to approach it from a different direction.

This leads us to the main bulk of this post, where I'll talk about a way to achieve this. This is an approach named “4 Layers” and the basic idea is to not attack the problem directly, but reduce it into steps and thereby be able to get proper interactive storytelling into just about any section of  the game.


The 4 Layers Approach
 The framework is something that's been developed between myself and Adrian Chmielarz, the man responsible for Painkiller, Bulletstorm, etc. At Frictional Games we are using this a cornerstone for our new game SOMA, and Adrian's new company, The Astronauts, is using it for their upcoming The Vanishing of Ethan Carter.


They way this approach works is that you divide the design process into four big steps. You start with the gameplay and then work your way through adding more and more layers of storytelling. The additional layers are Narrative Goal, Narrative Background and finally Mental Modeling.

Before I get more in-depth it is important to note that in order to use this approach correctly, the game must be broken down  into scenes. Each scene could be a puzzle, an enemy encounter, and so on. Normally, gameplay refers to how the game plays out as a whole, but for this framework, we must split it up into sections. This is connected with the above requirement of not having repetition, and usually means that there needs to be a lot of logic and gameplay coded into the world. I think that this is presents a crucial piece of the puzzle for having better storytelling: to drop the need for an overarching play loop and instead make the gameplay fit each specific scene of the game.

So instead of having the gameplay describe the player's overall experience of the game, the narrative will provide this structure. Exactly how this is done will become more apparent as we go through the different layers.


Layer 1: Gameplay
First we need to start with the basic gameplay and it's crucial that the narrative aspects are kept in mind from the get-go. If the gameplay doesn't fit with the story, then problems will start to accrue and it'll make the later layers much harder to achieve and reduce the final quality. As a first step for ensuring this, there are four basic rules that must be followed:

1) Coherency
The gameplay must fit with the game's world, mood and characters. There should be no need for double-thinking when performing an action; it should fit with what has been laid out by the narrative. The player should be able to think about the actions made to get a deeper understanding of the game's story. What the player does must also make some sort of sense and not just be a sequence of random or nonsensical interactions. The infamous "mustache and cat"-puzzle from Gabriel Knight 3 is a shining example of what not to do.

2) Streamlining
It is important that the gameplay is not too convoluted and doesn't have too many steps. This is partly to minimize the chance of the player getting stuck. When the player is stuck for longer periods they focus on the mechanics or tactics for gameplay. Also, we want to have situations where the player can plan ahead and feel like they understand the world. If the steps required for any moment are too complicated, it's very easy to lose immersion and to lose track of the goal. This happens very often in classic adventure games, where the solution to something straightforward requires a massive number of steps to accomplish.

3) A Sense of Accomplishment
This sort of thing is normally built into the core gameplay, but might not be as straightforward in a narrative-focused game. It is really easy to fall in the trap of doing “press button to progress” type of gameplay when the main goal is to tell a story. But in order to make the player feel agency, there must be some sense of achievement. The challenge needed to evoke this sense of accomplishment does not have to be skill or puzzle-based, though. Here are a few other things that could be used instead: memory tasks, out-of-the-box thinking,  grind,  endurance tests, difficult story choices, sequence breaks,  understanding of the plot, exploration,  navigation, maze escape,  overcoming fear and probably tons more.

4) Action Confirmation
When the player does something in the game, they must understand what it is that they are doing and why they are doing it. For basic mechanics this comes naturally, "I jumped over the hole to avoid falling down", "I shot the guy so he would not shoot me back" and so forth. But when taken to the level of a scene it is not always as straightforward. For instance, the player might accidentally activate some machinery without being aware that this was going to happen beforehand and afterwards not knowing what it accomplished. If this occurs too frequently, the player starts optimizing their thinking and stops reasoning about their actions. This then leads to an experience where the player feels as if they are just pulled along.

Getting all of these four rules into a gameplay scene and also making sure it is engaging is no small feat. Most games that want to focus on storytelling stop here. But in the 4-Layer approach this is just the first step.


Before moving on to the next layer of the framework, I will give a simple gameplay example. Say the player encounters a locked door blocking their path. Some earlier information has hinted that there a key is hidden nearby, and now they need to search the room to find it. Once they find the key they can unlock the door and progress. Very simple, and not very exciting, but it fulfills rules set up above.

1) A locked door and hidden key should not conflict with the story.
2) Given that the search space for the key is rather small, it is not likely the player will get stuck.
3) It requires enough from the player to give a sense of accomplishment.
4) Set up correctly, it should be very obvious to the player that the door needs to be opened and the key is the item used to accomplish this.

I will come back later and expand upon this with the other layers to give you a better feel for how the approach works.


Layer 2: Narrative Goal
So, next step: the narrative goal. Normally the reason for the player to get through some gameplay segment is just pure progress. There is often some overarching story goal like “kill the evil wizard”, but that is quite far into the future, so when the player encounters an obstacle they try to overcome it because that is what the game demands of them. It is often very clear that they are in “gamer mode” at this point and until the obstacle is cleared. This is useful in order for the player to know what to do, but it is very problematic for the narrative - it removes the experience of being inside a story. The player stops seeing their actions as part of a story and instead sees them as steps towards an abstract gameplay goal. What can often happen is that the player starts thinking stuff like "Now I just need to get this section out of the way so I can get on with the story", a forced mental division between narrative and gameplay, which is diametrically opposed to the fusion we're striving for.


The way to fix this is to give the player some sort of short-term narrative goal, one that is directly connected to the current gameplay. The aim is to keep the player in narrative mode so they do not brush the story aside for some puzzling or shooting action. When the player is engaged in the gameplay at hand we want them  focused on and motivated by this narrative goal. This makes it harder for the player to separate the two, as the narrative goal is always in sight. It is no longer about "doing stuff to get the story going", instead it is about "doing stuff because of the story". The distinction might not seem that big, but it makes all the difference. Keep in mind this is at a local level, for a scene that might just last a few minutes or less; the narrative goal is constantly visible to the player and a steady reminder of why they are going through with the actions.

A nice side-effect of this is that since the goal is narrative in nature, it becomes a reward for completing the gameplay section. The player is motivated to go through actions because of story and is then promptly rewarded with a fresh piece of the story. In all, this binds the gameplay much more tightly to the storytelling. An additional side-effect is that it can keep the player on the right track. The player might not be sure what to do next, but if the narrative goal is connected with the solution to the obstacle, then the player will progress simply by being interested in the story.

Here are three different types of narrative goals that could be used:

Mystery
The most obvious and simple is mystery; that there is something unknown you want find out about. It's pretty easy to have environmental assets that constantly reminds the player of this - this sort of goal is also pretty easy to fit into a gameplay scene.

Uncomfortable Environment
Another way is to give the scene a narrative reason for the player not wanting to stick around. The most trivial example of this would be a dark and scary environment; the player is scared and wants to leave. It could also be that the situation is awkward or emotional in a way that the player can't cope with and wants to escape. For example, it could be a depressing scene, like a funeral reception, that makes the player sad. It's important, though, not to get caught up in game mechanics; it must be a story reason that makes the player uncomfortable, not some mechanic (spikes popping up here and there, etc.). We want the focus to be on the narrative, not the underlying systems.

Character Conflict
Character-based conflict can also be used as a narrative goal. Walking Dead is full of this; what are really just fairly simplistic activities become engaging because of story reasons. A great example is the food distribution "puzzle" where the player is instructed to determine how the remaining stash of food is divided. What makes it interesting is that the player cannot come up with a division that doesn't upset at least one of the characters. Any gameplay that results in the player changing the social dynamics can act as powerful narrative goal.

These are just three examples of what could be done and there are bound to be a ton more. I think you could use basic writing techniques to come up with more.

Now let's update the example from before and add a narrative goal. To keep it simple let's go with some mystery. Say there's a man on the other side of the door trying to get in. He wants to retrieve something that's in the room that the player is currently in, and is asking them to open the door. Now all of a sudden there's a short-term goal for wanting the door open, and it's no longer just due to wanting to progress. “Who is this man?”, “What object is it that he's after?” You want to get these questions answered and that adds narrative motivation.

Important note: The 4-Layers framework is not a linear method, you'll have to constantly skip back and forth between the layers. In this case, you need to check the first layer, gameplay, and see if there's anything that could be updated in order to improve the narrative goal. You might need to change where the key is hidden, or even exchange the key for something else.


Layer 3: Narrative Background
With the addition of a narrative goal, the scene is now framed in a much more story-like manner. But there is still an issue: the actions the player does are quite gameplay-focused. In the above example, the player searches the environment simply in order to find a certain item; there is no proper sense of story-telling going on as the player goes through these actions. That is what this layer is all about fixing.


The basic idea is that the actions the player is supposed to be doing are immersed in story substance. So when the player is interacting, it is not just pure gameplay, they are constantly being fed story at the same time. When the narrative goal was added, the player's thinking was changed from "doing stuff to get the story going" to "doing stuff because of the story". With narrative background in place we change it to "doing stuff in order to make the story appear". Narrative-wise, the player's actions are no longer just a means to an end, they are what causes the story to emerge as you play. Or at least that's how we want it to appear to the player. By having the gameplay actions and the narrative beats coincide, we make it hard for the player to distinguish between the two. The goal is for this to lead to a sense of always being inside a story.

Here are a few examples of the kind of background that can be used:

Story Fragments
This means having narrative clues scattered through the environment which are stumbled upon while playing. An important note is that shouldn't just be the standard audio logs and diary entries. While it can consist of those sort of elements, it's important that they never mean a large interruption in the gameplay, and that they're found as the player goes through with the actions needed to overcome the obstacle. The act of collecting clues should not feel like a separate activity, but come as a part of the scene's main gameplay.

Complementary Dialog
There can also be dialog going on at the same time, giving context to the player's actions. Bastion uses this to great effect. All of the standard gameplay elements like enemies, power-ups and breakable crates are given a place in the world and a sense of importance. It also gives a great sense of variation to similar activities, as their narrative significance can be quite diverse. Dear Esther is another good example of this at work. Here the simple act of walking is given the sense of being vital to the story.

Emotionally Significant Assets
If the the items involved in the gameplay have some sort of emotional value or a strong connection to the story, the player is much less likely to see them as abstract tools. Inside of picking up "item needed to progress", the player finds something that can be a story revelation in itself. There is a huge difference in finding "standard knife A" and "the murder weapon from a hideous crime".

These three are of course not the only methods at your disposal to create narrative background. Just like with the previous layer, there are bound to be tons of other things too.

To make things a bit more concrete, let's go back to the example scene and add some narrative background. First off, let's add story fragments in the form of clues. These can give hints to the player about who the man behind the door is. Pictures, painting, documents and so on. So while the player is searching for the key they'll also be fed hints about the story. Secondly, let's have the man comment on the player's actions and give hints, making him reveal his character a bit. Third, we could say that it was the man who hid the key and that he did so for some very important reason. That way the key has some narrative significance and is not just an abstract tool. Getting all of these things in might require us to change the puzzle a bit, but as said before, this not a linear design approach. What you learn from the later layers must be fed back into the previous ones.


Layer 4: Mental Modeling
Now comes the 4th, and final, layer - Mental Modeling. The goal with this layer is to change the way the player perceives and thinks about the game. We want to tap into how the player evaluates their experience.

The first and crucial fact you must be aware of is that what is actually on the screen when the player is playing is not what ends up in their head. Nor does the player rely directly on any abstract system to make choices. The player's brain build up a mental model of the game, a sort of virtual representation based upon what they see, hear and do. It's this model that's used when you choose what to do next.

This might seem a bit bizarre and counter intuitive but it really isn't. Just consider how a player doesn't rely on direct feedback from the underlying systems in order to traverse a space. They don't bump into every wall in order to check where they can go. Instead they use their knowledge of the real world, intuition of the systems, and visual and auditory clues to plan a path. And once that plan is finished (which for simple tasks like walking takes a fraction of a second), the plan is executed. Stated like this it sounds really trivial, but if you think about it a bit more, it's actually quite profound.

The underlying gameplay systems only really become evident for the player if they do something wrong or when they directly contradict their mental model. Otherwise they play and plan largely part based on an imaginary game. Obviously the underlying system is what keeps it all working, and the feedback between the systems and the player's input is crucial for anything to happen. But the systems are never directly queried to lay out the boundaries and options available to the player. In fact, keeping the player's sense of immersion is often directly related to keeping the systems hidden. The player is not a computer and doesn't make decisions based on tables of abstract data. Built-in brain functions handle all that, and the smoothest sense of play comes about when the player is relying on gut feeling and intuition. Constantly having to probe a system to figure out its exact make-up is almost never a pleasing experience. (Unless that is what the game is all about, as is the case with some puzzle games).

Side note: I need to note that the player's intuition is updated the more that a system is revealed to them. If the player first assumes some enemies can jump but later finds out that they can't, their mental model is updated accordingly. This can have devastating effect on a narrative-focused game, making life-like characters turn into dumb automatons and so on. For more information on how all that works, check this out.

Brian Upton has a great example of mental modelling in action based on his work with the original 1998 Rainbow Six. In Rainbow Six the player dies from a single shot and has to be very careful how they progress. Since they are constantly on the look out for hostiles, even a very simplistic world can have a lot of gameplay, and that's without the player doing much. For instance, if they are about to enter a new room they stop and try to figure out the best approach. They need to consider if someone might be hiding out of sight and so forth. Based on their mental model of the game they will simulate many different approaches in their mind, trying to figure out which will work best. Even an empty hallway can conjure up these sorts of thought processes. The game is filled with possibilities that the player needs to be aware of, and the only way to do this is to use their intuition on how the game's virtual world and its inhabitants work. These constant mental gymnastics are a crucial piece of the experience.

The important point here is that most of what exists in the player's mind has no systemic counterpart. The player might imagine a guard hiding behind a corner, thinking of how he might be looking around. But in reality there is no guard behind the corner. Thus, a great deal of the playing time is spent just imagining stuff. This might seem like a cop-out, and not like proper gameplay, but that's not the case at all. It's sort of like chess, where most of the gameplay comes from you thinking about a situation, and the actual interaction only makes up minor portion of the playing time. Making mental models is very much a valid form of play.

The takeaway here is that there is a lot of gameplay which doesn't translate into an input-output loop within the game's systems. And more importantly, this sort of mental model-based gameplay comes from the player's high level interpretation of the game's systems, graphics, sound and so forth. This means that it basically ties directly into narrative. The mental model and the narrative lie on the same level, they are the accumulation of all the lower level stuff. And if we can get them to work together, then what we have is the purest form of playable story where all your gameplay choices are made inside the narrative space. This is clearly something worth striving for.

What's also interesting is that these sort of thought processes share the imaginary nature of books and film. The player doesn't have to be 100% correct with all assumptions, just like you don't have to have a perfect mental recreation of the locale a novel takes place in. If the player imagines a non-existent guard being around the corner then that is OK. He might approach slowly trying to get signs of the guard's whereabouts and not finding a guard behind the corner doesn't need to mean the fantasy is broken. The player can now imagine that the guard soundlessly snuck away, or something similar. When interacting directly with systems, like shooting bullets at a clearly visible enemy, the player's assumptions can't stray very far from reality. If the player imagines the bullets hitting when they in fact don't, that fantasy will quickly be broken.

Quick note: In case you haven't already noticed, this layer isn't just confined to a single scene. It's something that overlaps a lot of of the game. While you could potentially have mental models that only last for a short durations, it is more effective when it spans a greater part of the game.

Many narrative games already have some degree of mental modeling, but in the worst way possible: collectables. Say you have this story about a creepy forest and a protagonist trying to figure out what is real. And then picture the mental model constantly saying: “find all the thermoses, you know there are some around”. This will obviously make the game lose a lot of its potential. Be wary of this kind of issue.

Instead you want to have a mental model that fits with the rest of the narrative. What follows are a few suggestions:

Danger
There is something lurking about that constitutes a threat for the player. It's important that this threat is not some common occurrence that relies on twitch reflexes or similar, as it's just a normal gameplay element then. Instead it must be something hiding, only making brief appearances. The idea is for the player to constantly scan the environment for clues that the danger is near and present.

Goal-focused Mystery
This can mean that the player has the objective of solving a crime or similar. What we are after is that the player should see the game world as a place where important clues are to be discovered. So whenever the player finds a new location they should instantly start thinking about what new things it can teach them about the mystery.

Social Pressures
The player is amongst other people that they have to try and figure out. Now whenever the player finds something new or watches NPCs interact it updates their mental model of what makes the characters tick and what their motivations are.

The above should give an idea of what is possible, but as before, there are probably tons more to explore.

Now it's time to go back to the example scene and update it with the 4th and final layer. Let's add some sort of danger. Say the player is hunted by shape-shifting demons throughout the game and that these are also a big part of the story. This means the player won't be sure if the man behind the door is a friend or foe. We can tie this into the layer 3 stuff as well; as the player uncovers the narrative background they receive hints about the true nature of the man behind the door as well.

We've now gone from just having a really simplistic puzzle about opening a door to an entire story experience. The player is now under threat that there might be some kind of demon on the other side and is desperately trying to find clues on what the secret man's true identity is. At the same time, the man is also the key to a mystery, a mystery the player is very curious to figure out. The player is scavenging for the key, digging up more information as he goes along and when he finally finds it he needs to decide whether to use it or not. The basic gameplay hasn't changed much, but we've changed the wrapping and it totally transforms the experience.


Endnotes
What I think is extremely interesting about this approach is that it always forces you to think about story. Normally it's so easy to just be satisfied with a well-thought-out gameplay segment and to leave it at that. But when you follow 4-Layers you need to make sure that there's some story significance to the activity the player is currently doing. Story becomes an essential part of the game design.

It can also act as a filter. You can evaluate every gameplay scene and make sure it fulfills the criteria in each of the layers. This way you can easily tell if a some segment is just filler, or lacks in some other way. This is a great way to keep the design on track and make sure there is a strong narrative focus.

The method is not without its problems though.

First is that it requires a lot of planning. You need to design a lot of this up front and it's not very practical to build a scene from experimentation and iteration alone. Design documents are crucial, as there are just too many aspects to keep track of.

Second is that its core strength is also the biggest weakness. The gameplay and narrative are intertwined and if you change one the other needs to be updated too. This mean that you need to throw out and remake a lot more than usual during development.  But I don't see this as a failure, I see this as evidence that the approach really is bringing gameplay and narrative close together.

In a way this approach doesn't really change the core ingredients of a game. It just adds a bit of trickery on top. This is exactly what I like about it though. It doesn't rely on anything that we don't have at our disposal. And, as with all good storytelling, it relies on the audience's imagination doing the bulk of the work. I am really excited to see how this approach will turn out in the finished games. So far it's been of great use to us, and hopefully someone else will be inspired to give it a go.

Acknowledgments:
Adrian Chmielarz, for all the great e-mail discussions that led to all this and feedback on the talk.
Brian Upton, for letting me read an early copy of his book and providing the basis for the Mental Model section.
Matthew Weise, for providing valuable feedback to the lecture.
Ian Thomas, for copy-editing this whole thing.