SOMA enters pre-beta

Another major milestone is reached: SOMA is now in pre-Beta!

So what exactly does that mean? First of, it isn't the same as Alpha. SOMA was in Alpha mid-March this year, and since then we've made loads of additions, changes and fixes based on feedback and our own evaluation of the game's state. The pre-pre-Beta that happened a few weeks back was our final big test of that work. The game's current state, pre-Beta, is a milestone in preparation for the proper Beta, basically the full game without the final polish, which will happen a few months into next year. The pre-Beta marks final our chance for us to evaluate a number of crucial elements in the game.

First, we need to check if any dialog is missing or needs to be tweaked. We'll be doing our final recording a few weeks into next year, so it's important that everything's ready by then. In SOMA the voice-overs are a lot more significant compared to our previous titles. In Amnesia most of the voice-overs were background stories that had little relevance to the gameplay. In SOMA most of the voice-overs are directly connected to what the player is currently doing. This means that any changes we make to gameplay might require changes to voice-over and vice-versa. There's also a much greater need to make sure the two match up. For instance, we need to make sure that when a character describes a piece of scenery, it's accurate to what is actually in the game. We're also making a lot of tweaks to ensure that tone stays consistent and that exposition never gets too overwhelming.

The amount of voice required for SOMA is staggering. The games use more voice-overs than all of our previous games put together. The combined recording sessions total up to almost a month. Most of this is active content spoken by characters you encounter on your journey through the game.

The other big task is to check the final implementations of changes made after the pre-pre-Beta. After we went into pre-pre-Beta a few weeks back, the team met up for a few days of in-depth discussions. During this gathering we played through the entire game and made sure that everybody was in synch with what kind of game we were making. Over the years there have been lots of changes, and we needed to make sure that everyone grasped the sort of atmosphere, narrative and gameplay each part of the final game was supposed to have. We also decided on any last major changes to make and nailed down the feel we should be striving for in each part of the game . For example, we had long discussions on how the ending should play out and what sort of emotional pay-off we were going for.

Now that we're in pre-Beta all of these changes are in and tested. This means the game's final form is basically set. From now on we are not allowed to do any major changes and if something turns out not to work, we need to use smaller tweaks to fix it or just skip it entirely. This is a scary phase to enter, but also crucial. There are so many disciplines that are interconnected when making a narrative-heavy game; the underlying systems, the writing, the sound, the art and the overall gameplay flow all have very strong ties. In order to allow us to focus on polish and making sure what we've got works properly, there needs to come a time when the game's structure get locked down.

It is important to compare this lock-down to our previous games. In Amnesia and Penumbra, a level was considered locked pretty much done straight after the first implementation. But in SOMA we have had entire levels torn them down and rebuilt several times over. Partly due to the higher standard of polish we are after, and partly due to the game just being harder to make. From the get-go SOMA has been about immersing the player in certain thematics that takes place inside an active narrative. Figuring out how to do this properly turned out to be a herculean task, far harder than we first thought.

Next week, most of the team will go on Christmas leave, and then get back at the start of the next year for the final push. We are now closing in on a development period of five years and everybody is excited that the end is finally in sight. It is easily the most complex and difficult project we have ever undertaken and being able to release it next year, at a level of quality we are proud of, feels extremely satisfying.

Before we leave for vacation here is a little treat for you all: a brand new screenshot!

(Click to enlarge!)

SOMA is now Pre-Pre Beta

Today is the day SOMA reached Pre-Pre Beta, which marked the first time the game could be played from start to finish.

Four of us have now played through 'til the end and it's really cool to be able to finally really feel what sort of game we're making, after almost 4.5 years in development.

While we've played the individual levels many times, you never really get the same sense as you do when you play the full thing. I personally think it's a significant experience as you now get a mental picture of the game as one complete thing, instead of a massive cluster of themes, systems and scenes. I finally know for sure what it is that we're working towards.

The testing took an average of 11 hours per person. This includes a lot of note-taking, quick discussions and bug-fixing. But, given prior experience, this should give a decent estimate of what it will take the average (and non stressing) player to complete SOMA.

While the game is still really rough in plenty of places, I think I dare to say that we've got something quite special brewing. There's still tons of work left to do, of course, but we're getting very anxious to show off our creation to the world.

Thoughts on Alien: Isolation and Horror Simulation

Alien: Isolation is an interesting game. It is the latest entry in a lineage of games that I refer to as horror simulators. It does an excellent job at creating tension and uses a lot of the knowledge built up over the years to great success. But, because it has such a laser focus on a certain type of play a bunch problems arise and other parts of the package suffer. It is a great game in many ways, truly excellent really, but there are some fundamental problems. These lead to, for me at least, a devastating flaw: At its core it fails to be a faithful emulation of the original Alien (1979) movie.

Before we can properly discuss the game, we need to talk some video game history and design theory. Over the past, there has been two different schools of horror games. One that has a horror wrapping on top of standardized gameplay (horror wrapping) and one that tries to recreate the happenings of a scary movie/novel (horror simulation). The former is quite well known and started with games like Lurking Horror (1987). Mechanically, the game played like other contemporary adventure games, but took place in a scary setting with events meant to frighten the player. The latter one is a bit harder to nail down precisely, but I would say it started out with a 3D Monster Maze (1982), a game that is neatly captured in its name: the player is trapped in maze and needs to escape a monster (in this case a heavily pixelated T-Rex).

While the horror wrapping design has thrived over the years, being a design corner stone for games like Phantasmagoria (1995, an adventure game), 7th Guest (1993, a puzzler) and Resident Evil (1996, an action shooter), the horror simulation is much rarer. After 3D Monster Maze, the next game to do it somewhat properly was Clock Tower (1995).

It is now time to dig into the distinction between these two types of design. What sets Clock Tower apart from Resident Evil is that its core mechanic is not there to entertain, it is there to put the player in the shoes of a protagonist in a horror story. Clock Tower does this by having a single monster (little guy with giant scissors) hunting the player in certain scenes. The player can choose to hide in closets, under beds and hope that the monster does not find and kill them. Compare this to the core mechanic of Resident Evil, where the player needs to scavenge for ammo, weapons and health potions and then combat the monsters encountered. Resident Evil's gameplay could really work with any sort of theme and setting, while the one in Clock Tower is much more focused on being a horror experience. It is important to mention that Resident Evil does tons of things to crank of the level of scariness; scarce ammunition, inventory management, limited saves, etc. But none of these give rise to any specific horror scenarios; the game is still all about shooting various enemies in order to progress. There are very few sections in Resident Evil would fit a horror movie or novel, but Clock Tower is filled with these moments.

The core difference can be summed up as Clock Tower being focused on having plenty of verbs that are related to a horror movie: hide under bed, looking into mirror, run away, push monster, etc. As the player plays the game, they reenact scenes of horror simply by following the rules set out by the gameplay. Resident Evil hardly does it all, the focus being much more on standard tactical combat with certain scariness attached to it.

As a horror simulator, and really horror game in general, Clock Tower is not very successful though. First, much of the gameplay is actually pretty standard adventure game affair. Second, the actual chase moments are quite clumsy and frustrating to play, rarely resulting in any proper feelings of dread and terror. Despite these, quite major shortcomings as a horror simulator, Clock Tower is well worth studying. If you look past its flaws, there exists a focus on making horror elements playable that just didn't exist in games at the time. In fact, it is really hard to find similar games until quite recently. Hell Night (aka Dark Messiah, 1998) has the player running from a single monster and features cool stuff like a look-behind-you-button and having to carefully choose a companion. But it also suffers from lots of problems and is often a very frustrating experience.

Even such horror classics such as Silent Hill (1999) have little focus on trying to do proper horror simulation. Most of the game is based around solving puzzles and fighting enemies (while running is sometimes advisable, most encounters are best handled through combat). Instead a lot of your typical horror moments are not simulated, but put outside of the player's control. For instance, in Silent Hill 2 (2001), when the protagonist hides in a closet it happens in a cutscene. Remember, this is a scene that played out through gameplay in Clock Tower. If you look at the large body of the gameplay the player does in a Silent Hill game, little of it resembles what you would see in a novel or film. In fact, it resembles little of how a rational person would behave in similar scenarios. This does not make the games bad by any means, but it is a crucial concept to keep in mind. The games heavily rely on standard, often narrative-wise nonsensical gameplay in order to create the foundational engagement for the player.

The next game, after Clock Tower, to really give horror simulation another proper go was Siren (2003). Here the player's actions are a lot more aligned with how it makes sense for them to act. For instance, it features a map without any indicator of the player position, and also allows you to see the world through the monsters' eyes. In all, it creates a much stronger sense of being inside a horror story. The problem with Siren, like Clock Tower, is that this focus amounted to a very frustrating experience, which in turn easily diminishes the overall immersion and scariness. Once again, this type of design didn't gain any traction.

I now need to briefly discuss a design concept called "mental modeling". A concept that is closely related to the difference between horror wrapping and horror simulation. When you play a game like Resident Evil, every encounter is a very tactical and precise decision. You look at what kind of opponent you are facing, what weapons you have, the current ammo supply, health levels, etc. The model in your head is much less about the appearance of the creatures, and much more about pure numbers. This can be very stressful, and combined with a horror thematic the total experience can feel quite scary. But on the whole very little is left to the imagination and narrative-related intuition. In a game like Siren however, you are much more worried about what you cannot see, and your mind is racing with trying to predict future happenings. Combine this with a map that forces you to think yourself as part of the environment, and monsters that you mostly keep track of by inferring their position, and you get a mental model that is far more horror-like and vivid. The problem is that since you lack the sense of numerical certainty that Resident Evil supplies, it becomes much harder to formulate correct tactical decisions. This is a fact that I think has a part in making these kind of games so frustrating. It is clear that the mental modeling that Siren has is better suited for a horror game, but it was not yet working properly gameplay-wise.

Now back to game history again. The release of Siren marks the beginning of the end for what I would like to call the golden age of survival horror. It had brought us gems like Resident Evil, Silent Hill, Fatal Frame (2001), all of which brought a very fresh take on the horror experience. But after that, the well seemed to dry up and horror games got increasingly action oriented. Resident Evil 4 (2005) really got this trend going. One reason for this change in focus is partly diminishing sales and increasing production costs. Another major – and connected – reason was almost certainly the lack of evolution in the genre. All of the big games had been based on horror wrapping, with most of the gameplay being quite standard. The wrapping did not allow for much change, and when the focus was put on the underlying mechanics, the horror rapidly faded.

It took a while before anything new came along, and this is where we enter the picture. When we released Penumbra: Black Plague (2008), we made our attempt at doing a game without having any weapons. It had a bunch of issues, but showed promise in how it changed the player's perception of the game's world. The decision was based on lessons learned for Penumbra: Overture (2007) and from the linage of games discussed above. The following year sees the release of another combat-free horror, Silent Hill: Shattered Memories (2009) which also puts emphasis on crafting more of a horror simulation, but also manages to get a bit too frustrating. Upon releasing Amnesia: The Dark Descent (2010), there is one thing I am especially proud being part of creating. Simply by using the game's basic system, we can get the player to hide in a closet and fearfully watch as a monster pass them by. It felt like we basically managed to recreate, through gameplay, the closet cutscene from Silent Hill 2, and properly simulate one of the main mechanics from Clock Tower. I feel way too biased to say how much effect – if any – this had on horror games in general though, but for me personally I feel it is one of our biggest contributions to the genre.

Two years later, the short and free game Slender (2012) is released and this what I think really kickstarted the horror simulation. Slender is a simplistic game with not much in terms of standard gameplay. The player is simply tasked to collect a few notes in an open, but still slightly maze-like environment. Where the game gets all of its engagement from is how it manages to simulate its horror. You cannot look at slender man, you have to move carefully, you cannot use your flashlight too much, you need to stay away from spooky sounds, etc. All of these gameplay elements are quite vague and together they give rise to a rich mental model. The end product is that you got a very engaging horror experience from almost nothing. Remember that Slender has very little story and interesting goals. It is all about existing inside a certain virtual space. It is all about raw horror simulation and little else. While other indie games like Hide (2011) have done similar things in the past, Slender proved it was really a viable method of making a game. If you just make things vague enough, and allow the player to play based on that vagueness, you can make engaging games of pure horror simulation. In some ways, Slender is sort of like the Super Mario Bros or Wolfenstein 3D of horror games, a distillation of what makes the genre work into its purest form.

Since then a bunch of similar a games have followed, one of the most successful being Outlast (2013). The story in Outlast is paperthin: A journalist enters an old asylum where experiments are rumoured to have taken place, is met with the place being overrun and now has to escape. There are no puzzles, no standard gameplay, it is all a bunch of levels where you run or hide from insane inmates. Also included are a few breather levels where you simply walk to (or try to find) the next destination by going through some spooky environments. Scattered around are also documents detailing background lore, but you gain very little from reading them. You can pretty much go through the whole game ignoring them and still get a coherent narrative. What makes the game engaging is the situations that it puts you in. Hide from monsters in lockers, sneak past them as they talk gibberish, walk past weird looking denizens not knowing if they will jump you or not, try to make out dangers using grainy night vision camera, and so on and so forth. Almost any gameplay scene that plays out could be directly baked into a horror movie or novel. Outlast is a pure horror simulator, and a narrative naturally arises from the situations the game throws you in.

And now, finally, we get to Alien Isolation. This is the latest breed of horror simulations, and a very successful one at that. The big feature in this game is that there is only one monster that can appear at any time. In many ways, it is really the 2014 version of 3D Monster Maze, in which the whole game was built around trying to figure out where the monster was located and how to avoid it. Alien: Isolation obviously has complexity far beyond that, but it is striking how similar the basics are.

There are bunch of elements that all work together to craft a mental model that perfectly fits the game and make Alien: Isolation really scary. First off, like in any other horror game, the sound is vital and you need to constantly listen for clues. This can be cues from other survivors (who are hostile towards you), malfunctioning androids, or the alien monster itself. Not only do these paint a terrific ambient soundscape, but they are also very important for you in order to progress. You also need to be conscious about how much sound your own actions are causing. The game warns you to not use the notorious bleeping motion scanner too near people as they might hear you, and after that you get really paranoid about any sounds you might be making.

On top of that, the save stations, which are crucial to locate, give off a faint and distinct beeping noise. As the environments are dark, and the stations can sometimes be found in a hard to spot location, you have another reason to listen carefully. The difficulty level in the game is quite harsh, and the tiniest mistake can lead to sudden death, so you are always eager to save the game. This leads you to listen extra carefully when you have gone a long way from a save, making you vulnerable to any other sudden noises. Remember those jump scare videos that told you to watch or listen extra carefully only to throw a spook at you when you least expected? It is sort of like that that, but without you feeling annoyed afterwards. Add to the fact that the Alien can really appear anywhere in the game, and you get a mind model that is primed for picking up and seriously considering even the slightest sound.

Because the alien feels so random in when and how it appears, it is hard to get a grip on what sort of signs to watch out for. The mind model becomes vague, and more prone to paranoid imagination, which is obviously great for a horror game. This is combined with the fact that unless you have one of the beefier weapons, if the alien spots you, you are dead. With no possibility to run away, the player gets very conscious about their movements, the alien's possible location, and – yet again – the sounds that they hear and might be causing.

Combined with all this is an assortment of items (noise makers, flares, a revolver, etc) that all have pros and cons (eg flares light the dark, but also attracts attention) along with a certain interplay between the different types of hostiles. For instance, if there is a room with human adversaries you could throw a noise maker in among them, attract the alien and then have that kill them off. But that also means you now have an alien in your vicinity, which might prove more dangerous than the humans. And since the systems are vague, it is hard to predict outcomes and you live in this constant uncertainty.

Another aspect I love is how the alien monster forces you to sneak. It is quite common in stealth games that you can simply lie in wait and club down patrolling hostiles, and that that tactic is far better than the (narrative-wise, better fitting) approach of sneaking past them. But in Alien: Isolation, you do not want to risk any sort of alarm, and staying hidden almost always feels like the better option. In turn this makes most humans that you encounter seem more alive. You mostly only see their vague outlines and hear their conversations from afar. In your head you a build much more vivid picture, since you are never pushing the game into displaying their often immersion breaking behaviors that occur when they are up-close.

All these actions available coupled with the resulting mind model lead to gameplay spaces that properly simulates horror. Sometimes even unscripted horror shows play out in front of you eyes. For example, a band of survivors can be caught off guard by the alien as you hide in a locker and you end up staring at the onslaught terrified that the monster will come for you next. And like with Outlast, just about any scene that plays out would be fitting in a book or movie. A horror story unfolds as you play and is affected by your actions. And unlike similar games based on horror wrapping, eg Dead Space (2008), the actions that you do feel sensible and realistic. Apart from some more gamey mechanics like the save station and scrap collection, you behave just like a character would do in a movie or book version of the same story. This is horror simulation at its best.

But this super focus on being a horror simulation, also starts showing cracks in the game as a whole. For instance, just like in older games of the same genre, Alien: Isolation can be very frustrating. The tension built up from being 20 minutes from your last save, quickly turns to anger and frustration when you are killed seemingly out of nowhere. While still vague (which is essential for giving rise to the right mind model), it is predictable enough for you to be able to get past any threats if you are just careful and cunning enough. Still, this part is divisive, as can be seen by the review scores and I have myself felt extremely frustrated with the game from time to time. There is a certain sweet spot in how to approach situations properly. Too aggressive, and you will die a lot. Too passive and the game's pacing gets messed up. The trick is to be able to move forward at a steady pace and still be cautious enough to avoid death. A way to fix this would have been to make the alien AI better adapt to the player's style, so if they hide a lot in lockers, it backs off quicker and keep things interesting and the pace at the right level. The developers should have probably focused a bit less on challenge alone to provoke a certain mindset and also have had some elements to dampen the difficulty for players that were behaving properly, but are being a bit too passive to get a good experience.

While the frustration and bad pacing are clearly issues, I do not think they are that bad and, as noted above, it should be relatively easy to fix. What is a much bigger problem is how these system gives rise to a very simplistic narrative. The first part of the problem are the save stations. Having these are a crucial part of making it all work, partly based on the simple reason that after a little while you get too comfortable around the alien for it to be intrinsically scary. There needs to be some gameplay aspect that keeps the tension up, and keeps you in the right mindset. The save stations does just this. But the side-effect is that the save stations become the biggest objective for you as a player. Finding the power station that you need to activated is not at all as important as finding the next place to save. This means that your personal narrative becomes dumbed down, and ends up being a simple hunt for loot and save locations, without any thought on what the higher level fiction behind your actions really is.

The problems with objectives does not stop there though. Another issue is that they are all extremely simplistic and without any interesting narrative significance. They are all about powering up things or finding keycards. It is old school mission design with a thin layer of narrative coating. While these sort of boring objectives are pretty common in games, I think Alien: Isolation has an especially hard time getting away from it. Because the game is constantly so dense with information that you need to keep track of (save stations, motion tracker, alien signs, loot, resources, etc) you really cannot manage to keep any complex objectives in mind. It is also crucial that the player has a good idea of where they should be headed, because too much disorientation and the mind model starts breaking down. This leads to basically decent objectives (eg find a keycard on a dead doctor by figuring out what rooms he has visited) becoming very handheld experiences, as the game constantly marks your next destination. The simple reason for this is that less hand holding would have made it too frustrating. You can see similar mission design in Outlast, and while I think there was more room for improvement there, it is a design decision that probably stems from the same issues.

Another connected issue is that the notes and audio logs you find in the game never really feel that relevant. It is another issue similar to Outlast, although I find that the content was way more interesting in Alien: Isolation. But the real issue is that you cannot really have too much important information in these, because accessing terminals means a danger to the player. It is really hard to explore and think about the environments and backstory when you are constantly worried about the threats the game might throw at you.

As you look closer at these flaws in Alien: Isolation, it becomes more clear that it really is just a pure horror simulator, like Slender or 3D Monster Maze, just with more sections to play through. The aim of this game is not to tell a longer horror story. The aim is to put the player in different scenarios involving hostile human survivors, creepy androids and/or an alien. Any interesting narrative then arises from how these scenarios play out. It has no real story at a higher level apart from the basic "get the hell out of there". There is nothing wrong with this of course, and the basics of the game works fine as is. But Alien: Isolation's issue is that it just goes on for too long. If you (like me) want to get some sort of deeper narrative experience from your game to keep going, the game wears thin after just a few hours. This is a bad thing for a game that last for at least 15 hours. Outlast takes about 5 hours to complete, and that feels like a better fitting length for this sort of gameplay.

Alien: Isolation has another big problem. If you went in hoping this would be an interactive take on the first movie, you will be disappointed. Rather than being some sort of video game adaption of the original film, it is more like a version of Alien 3 or 4. The first movie is the birth of a monster, it is a long build-up of a creature followed by a final confrontation. It is much more about discovering some hidden lovecraftian horror, than about people fleeing for their lives from a well-established creature. So what the game ends up being about; sneaking from place to place, just constitutes a minor part of the movie, and is a far cry from replicating the experience.

It is hard to blame the developers though. In order to deliver a similar narrative they would have had to rethink the alien quite a bit, and most likely diverge from the source material. Something that I wouldn't think Sega or 20th Century Fox would not be too happy about, as the creature is the game's foremost selling point. But even if we disregard that, it would be very hard to use the game's given form to emulate the make-up of the movie. If we trace the game's gameplay lineage way back to Monster Maze, we see very little about the other things that make the movie so great. All of these games are about putting the player in a predefined situation and to let that play out. The great strength of the genre is to provide the thrills of being the hunted, and to have a super focus on this.

Alien: Isolation does do some attempts to better replicate the source material. For instance we are taken on an expedition to the iconic derelict spaceship, but for me all of this falls flat. The eggs, facehuggers, and all that are already so well established that you never get a sense of mystery from it all. Worse still, this section differs so much from the movie – which comprises of sneaking about – that there is no tension. The game has trained you to look for save stations, be aware of your resources, listen for certain sounds, etc in such a specific way that when you are taken out of this space, the game loses a lot of its impact.

I think that horror simulation is the sort of design we want to strive for when making horror games. I love how it is possible to set up scenarios where the player gets to experience terrifying scenes, fitting for a horror movie or novel, simply by playing. This is the sort of storytelling that we want from games, and I do not think going back to merely using horror as a wrapping is a good idea. However, it is pretty clear that there is a big problem here. Horror simulation as it is currently done, is very limited in what it can let the player do, and what higher level narratives it can tell.

We had similar issues in Amnesia: The Dark Descent. When playing the game, all you do is go from room to room, solving puzzles and avoiding monsters. But as you read about the backstory you hear about opening tombs in the desert, the first visit to the Brennenburg castle and much more. All of these are moments that an ideal horror game should have let the player play, not just read about in some diary entries.

The issue is not just to recreate these sort of scenes, but to make sure the experience is fitting. As can be seen in Alien: Isolation, the trip to the planet lacks the immersion that the sneaking around has. When you try and hide from the alien, your mind model is aligned with was happening and you act like a protagonist would do. But when visiting the derelict spaceship, you could have just as well been watching a cut scene. There needs to be something more in order to properly bring this sort of scenes into the standard that proper horror simulation has set.

First of all I think there needs to be more restraint on how much of the basic gameplay is used. Even though Outlast takes about 5 hours to get through, it has a hard time keeping the gameplay fresh and the tension up throughout. For me, the game started to feel slightly drawn out the last third or so. Amnesia also suffered from this. Enemy encounters got pretty predictable and less scary after you had gotten through half the game. While the exact time at which this sort of gameplay stops feelign engaging is highly subjective, I think most can at least agree that the less practice you get with the encounters, the more intense they feel. Therefore lies in the best interest of a horror game to use its monsters sparingly.

Second, there needs to be much less reliance on difficulty in order to build the proper mind model. The way that games like Alien: Isolation and Siren are set up really increase the tension, but it does so at the cost of making the game's scope very narrow. As explained above, it is hard to have much else going on in order for the player to enjoy the experience. Also, as soon as you remove any of these elements that rack up challenge (like save stations) a lot of the tension goes away. What games like these are after is to couple the sensation of stress of losing progress together with a firm horror setting. The psychological effect is that the player takes the tension they are feeling and projects it on the frightening visuals and sounds. But building purely on this is a fragile structure as it means you always need to present a mechanical device of stress to the player, and this leaves out a lot of horror scenarios.

I think that the answer lies in having some sort of uncertain outcome as an ingrained gameplay device. Instead of having the player fear "what if I lose my progress?" they should be thinking "what if I affect the world in a negative way?". This is a kind of thinking that can be applied to a much wider range of things. Probably the best example of this in action is the Walking Dead (2012) series. Here one can clearly see the range of scenes that can have tension, purely based on an uncertain outcome. And what I especially like is how personal the choices can be, eg deciding between which person gets your trust. The most apparent problem with this sort of gameplay though is that it requires branching, but this is not as big of an issue as it seems. Walking Dead has in fact very little branching, but even if you know this, you still feel tension by the choices. There is still enough uncertainty for you to feel immersed and care about the decisions.

However, Walking Dead is quite different from how a horror simulator works- In a horror simulator the player needs to be in control most of the time, and cutscenes should be minimal. So it is not possible to just rip out the mechanics and apply them as is. What we need to do is rethink how choices can be set up and what the effects can be.

We did some very early testing of this in Amnesia: Dark Descent and its free extra story Amnesia: Justine (2011). In The Dark Descent we have no proper choice, but there are some slight consequences to failure. If the player is killed by a monster, the world is slightly changed. This was not enough to be on the level of the tension gained from fear of losing progress, but it gained a certain level of uncertainty that helped to keep some of the fear. In Justine we also tried having optional puzzles, that resulted in a person getting killed if you failed. This also worked pretty well, and it meant that puzzles – a previously pretty separate element of gameplay – got more of a horror simulator feel (somewhat recreating scenes from movies such as Saw).

These are just small things though, and the big problem is to have it work on a larger scale in a smooth, coherent manner. I think the first step is to see if you could remove the penalty of death from standard sneaking gameplay, but still retain the same sense of tension. There are three big things to gain if this can be achieved. First, to remove a lot of the inherent frustration connected to the "fear of progress loss"-design, and have less risk of breaking immersion. Second, it will allow for more integration of exploration and more complicated objectives, as you remove the forced repetition coming a design based on difficulty. Third, it will give us a glimpse of how we expand the horror simulator and have it cover things beyond sneaking by and hiding from monsters. My hope is that we then could take a stab at making a proper horror simulation, a recreation of experiences like in the original Alien movie.

This is what we are currently experimenting with in our upcoming game SOMA. Since I do not want to spoil the system I cannot go too in-depth on our approach, but I can give a basic outline. The idea is that by having choices inserted directly into the game world and have the way you chose to handle these change how the narrative unravels. These choices can simply be whether you interact with a certain object or not, or it can be more vague things, like how you behave around a certain creature. The narrative effects will not be any sort of heavy branching, but smaller things things like making upcoming sections scarier (eg by removing lights), killing people you encounter, changing the way you perceive a character or even how you feel about yourself. Our hope is that by having these sort of decisions as an integral part of the game world, that the player internalizes them and makes it part of their mind model. Then, just like the tension you feel by wondering where the next save station is in Alien: Isolation, you will feel tension by pondering what ramifications a certain set of actions might have.

This is just a little step forward, and until we release the game, we will not know how well it works. I do think it is crucial that we start to think about these things though. Just as the horror genre stagnated in the mid 2000s, because horror was merely a wrapping, the same might happen if we fail to move beyond "chased by monster" scenarios. While there is nothing wrong with these sort of games, I think it would be foolish to be satisfied with just that. There is so much more to explore in horror, and the success of recent horror simulators gives me hope that video games can handle it.

More to read:

• My article about the 4-layers approach towards narrative design, has more on mind model stuff.
• Before playing Alien: Isolation I wrote an article and the problems it might have, that should be interesting to read too. I think some of my predictions, but I really underestimated how scary the alien could feel despite being a well-known creature.
• Chris Pruett's 2-factor theory on horror, ties into some of this stuff. Check out the basic background here and how it applies to games here.

People of Frictional: Samuel Justice

Who Am I?

My name is Samuel Justice. I became audio lead here at Frictional Games in February of this year. However, I’ve been directly and indirectly involved with the studio for 3 years. I work from home in a place called Worthing in England - a small seaside town that’s fairly sleepy.

Background

When I was about 10 or 11 I started to get almost unhealthily obsessed with videogames; this carried on throughout my teens. My mother played piano and my father the bass guitar and both enjoyed listening to a lot of music, so I was always surrounded by that as well. 

During high school the obsession with games shifted from playing them to developing them. I would sit and help make Half Life 2 mods and levels whilst watching whatever documentaries I could find about game makers. This became my own little escape. When I left school I went to college to do standard A-levels. College in the UK is unlike the USA - in the UK you can finish high school at 16 and study for 2 years at college, then move on to university. I hated what I was doing and after 5 weeks dropped out and joined a music production course, as I had no idea what I wanted to do longer term. It was during that course that I developed a passion for audio production and sound. And then it clicked! The obsession I had with making games and sound finally could cross paths, and I began to venture into sound design for games.

So during the nights and evenings I experimented, plugging sounds into these mods and seeing what my experiments produced. I joined a few modding teams during this time (Off-Limits, Nuclear Dawn and Iron Grip The Oppression being just a few that I helped sound design). I got really lucky and landed a small contract out of college through my mod links which sustained me for a year. After which I had no money left and saw vacancies in the police - the pay was okay and I saw it as a way to continue doing what I loved on the side and it was great because I was able to afford audio equipment with the pay as well! Not much, mind you.

I continued working in the police for a few years but never fully embraced it - it had never been an ambition of mine. About two years in I started to enjoy it more, and began to think that maybe the police was my calling after all. But I was wrong.

A source modder got in touch and asked if I'd do audio for a title of his. I worked on that, and then the next title, and suddenly I was springboarding from one title to another. 3 months later I made the choice to leave the police: as this was what I was so desperate to do that I wanted to grasp the opportunity!

This led me to finding myself being audio lead on Amnesia: A Machine for Pigs and working with Frictional for the first time. I then joined the fantastic audio team at DICE in Sweden and worked on Battlefield 4 and a number of its expansions. After 18 months at DICE I was feeling quite homesick so I decided to return to the UK. Jens had taken the reigns of maintaining Frictional Games as a company, and there was a gap that needed to be filled. I jumped on board knowing that SOMA was an extremely unique title and something that’s going to be quite special. I’d been working on SOMA in the background during my work on A Machine for Pigs. So even though I have only joined the studio full time recently, I have been involved in the title from the early stages.

And that brings me to today... here...  typing this post to you guys.

Life at Frictional

What does an audio lead do on a daily basis at Frictional Games, I hear you ask? No? Well, tough, I’ll tell you anyway.

The bulk of my time is working directly on SOMA and making sure we can deliver the best-sounding game available within the timeframe. But I also manage the small band of Frictional Audio compadres. We have one sound designer (the great and mysterious Tapio Liukkonen), an intern/junior sound designer who goes by the name of Mike Benzie and composer Mikko Tarmia who are all working extremely hard to make sure SOMA sounds great. 

So my time is also split managing their workloads, giving feedback, listening to their feedback and ideas and keeping the lines of communication wide open which is vital when working for a virtual studio.

Once those duties are taken care of I love to get my hands dirty and dive right in and create and implement sound for the game. To a lot of people sound design is a dark art - they understand the process of pointing a microphone at something. But how does it go from that raw recording to a big sound effect... and then how does that get in to the game?

The best analogy for creating a sound is to compare it to cooking - in-game sounds aren’t made from single source sounds, but instead mixed from multiple sources. We’ve created the SOMA sound library at Frictional which contains a large number of custom recordings for us to use as our ingredients.

So, when you have a library of ingredients, the second phase is to think and to ask questions. You need to gather an understanding of the sound you want to make. What kind of environment is it in? What kind of story do I want to tell with this sound? What other sounds does it effect?

Once this is done, the next stage is one of the most important - just listening to the source material. We use a program here called Basehead that is our SFX database and auditioner, for this we can type in (like Google) the kind of sound we want, and it’ll search the SOMA sound library and give us results (we also have to name the files, which makes it vitally important that they are named correctly and comprehensively). This is the “picking ingredients” stage. Once I’ve selected a few sounds that I think are interesting and which could convey the story I want to tell, I’ll drop them into my DAW (Digital Audio Workstation). I use a program called Nuendo - there are a lot out there (ProTools, Cubase, Logic, Fruity Loops etc. etc.)  and they all do the same basic thing. Using Nuendo I then manipulate each ingredient until I have something that resembles the sound in my head.

A typical SFX session, each coloured block is a different recording!

Now how do we get this in game? I’m sure many of you reading this are aware that Frictional has a proprietary engine and toolset called HPL (version 3 is being used for SOMA). However the audio side is handled by third-party software called FMOD. HPL and FMOD talk to each other and FMOD provides the toolset to import the sound and attach parameters to it (such as volume, how far away the player should hear it, should it have in game echo etc.). Once this is done, FMOD encodes and generates a file that HPL is then able to read - and we trigger the sound from that file using the scripting system in HPL. Thanks to the fact that HPL updates script on the fly, it makes it very easy to tweak a sound in Nuendo, drop it into FMOD and test it in the game without having to restart anything. Workflow chain is absolutely the most important part when it comes to implementation - otherwise it can take hours just to test a single sound.

This image shows the logic within FMOD for underwater movement sound - this is just one type of movement on one surface!

So there we have it! Now leave me alone: I need to go away and make sounds that will contribute towards a national diaper shortage.

People of Frictional: Peter Wester

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

Who Am I?

I'm Peter Wester and I have been an Engine Programmer here at Frictional Games since late 2011.
I work from my apartment in Stockholm, Sweden. I used to have a nice big desk, but after getting a PS4 Devkit it has become cramped.

Background

My gaming interest started as a kid when my parents bought a Sega Megadrive and I became obsessed with Sonic the Hedgehog.

On my 12th birthday I got a program called Multimedia Fusion. It was a 2D game maker that didn't need any coding knowledge. Instead you placed objects on a canvas and gave them existing behaviors to get them to move or collide. I used this to try and recreate my favorite 2D games. The most memorable one was a GTA clone with the goal of killing as many civilians as possible before the timer was up.

This got me interested in how games were made and I started to look for tools to modify other games. Me and my friend would replace all the voice acting in Worms with our own recordings or make custom maps for Counter-Strike.

It wasn't until high school that I got into programming. After taking a programming course and learning basic C++ I downloaded the Doom 3 SDK and tried to understand the code; eventually I started helping out on a few overly ambitious mods that never got close to being released.

After high school I applied to a game development education at Stockholm's University. It didn't turn out to be the best education, but I met a lot of people and started making games from scratch. Three years later me and three of my friends dropped out and started a game company.

Phoenix Spirit - Our second game

We made games for Android and iOS and I was in charge of game design and programming. After releasing two games we got the chance to go to China and meet up with a contact and start a subsidiary there. We made some money and got a few awards but after two years we decided to shut down the company to focus on other things.

Mana Chronicles - Made by our Chinese subsidiary

I started looking for a job and saw a blog post about Frictional hiring an engine programmer. Knowing that Frictional had their own engine and that I wanted to focus on programming I decided to apply.

What do I do?

As an Engine Programmer I take care of the code that makes up the foundation of the game. The game is built on top of this. We've separated the engine and game code; this means that the engine can be used for multiple different games. In fact, most of the engine code used for Amnesia: The Dark Descent is still in HPL3 (our latest engine version) and could run the game with a few tweaks.

What an engine needs to provide is different for each title. For instance, SOMA requires a way to simulate physics, to render a believable 3D world, to play sound effects and to support fast iteration of level creation. My job is to make sure all those exist and work as they should.

An Engine Programmer's job can be broken down to two basic parts: adding features, and supporting existing features. Adding a new feature takes about 1-2 months and goes something like this:

When I added Depth of Field to the engine I started out by researching the subject. I read up on tech blogs and research papers to find the best implementations of Depth of Field. I decided to try out two versions, an expensive bokeh version and a more standard blur based one. After implementing both and getting feedback I decided to go with the blur based version since it was cheaper and fit with our underwater aesthetic. Once completed I added script functions and made a helper class so that the gameplay programmers could add it where it was needed.

Depth of Field - blur visible in the background

Some tech features also need to work in the editor. When I'm done with such a feature I hand it over to Luis who later adds it to the editor in a user-friendly way.

The closer a project gets to the end, more of my time gets spent on supporting and improving the code. This could mean fixing bugs that have been reported or optimizing code to make the game run faster.

I'll test the game on different hardware and make sure it runs as fast as it should. If it doesn't I'll try and figure out what's causing the game to be slow and then find a solution to that problem.

Editor Fly Mode

Hey there! Vacation time is really close now and there's so much to do before it arrives, but I still wanted to drop by and keep you posted on new editor stuff, so I'm gonna keep it short this time.

We have a fly mode for the perspective camera now! Yes, and it works nicely enough. No video today, but enjoy this animated GIF instead:

People of Frictional: Steven Redmond

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

Who Am I?

I'm Steve, another newcomer to the ranks of Frictional Games from the foggy British Isles. I joined around the same time as Ian give or take a few weeks and, like both Ian and Patrik, am responsible for level and gameplay scripting. 

I'm originally from London, having moved out five years ago and settled in a small village in the Midlands. I'm married and have two daughters who I have to keep out of my room for at least 8 hours a day. So essentially, as an adult about to hit 30, my days involve sitting in a corner of my bedroom on the PC playing with editors and programming languages while trying to keep the family out. Life has a funny habit of coming full circle sometimes!

But before we get on to that, here's the photo of my workspace:

Until recently I had a tiny desk!

Background

Most of my career up until the past few years has been spent as a Linux systems administrator both as a contractor and full time with ISPs. I started out using computers as a child when my dad gave me a hand-me-down VIC20. All my friends had games consoles, but I was never allowed one. Instead my dad would set me code tasks to complete which would earn me my next upgrade. I went through a C64, Amiga and then on to various low-end Intel-based PCs until I was old enough to get a job and buy my own.

My dad's friends were completely eccentric hacker-types and he'd take me to visit when I was young. I grew up around people who had hacked valve amplifiers with the cases off and custom-built motion sensors on the doors to their bedsits wired up to a very loud car alarm sitting on top of a bookshelf. There was a semi-constructed motorbike indoors on the first floor of a residential building in Willesden, with lots of computers humming away running Linux all to the sound of Pink Floyd. Hearing my dad and his friends talk about computers and electronics was like listening to some sort of alien language. I didn't understand a word of it, but I wanted to.

At secondary school I met one guy in particular who I'm still good friends with to this day – Robert. We'd copy our QBASIC games on to floppies to swap at school, learning from each other. During this time we also discovered the editors that came with Duke3D and would share levels we had made. Because of Robert, I got heavily in to adventure games and survival horror. Since I didn't have a games console, I had no access to all the games played by cool kids. I was able to run an emulator though. Robert let me borrow his Resident Evil 2 Claire disc and I got hooked. It had all the stuff that we liked in adventure games, obscure puzzles, and it also had this really interesting mix of action and survival. Robert didn't have a memory card, so he would always play these games through on one run without saving. This got us speculating about horror games where you weren't armed and had to survive using just your wits. Of course since we were young, this was just a dream. We'd have to wait for some smarter people to make that game for us.

After school I ended up going straight into work. I started out in PC repair and went through various support roles before spending about 7 years or so as a Linux Systems Administrator. However, that all came to an end when jobs ended up being cut. The timing was pretty bad: we were expecting a baby, and my fiancée and I were some distance apart - she was finishing up her work contract. I did the sensible thing, moved closer to her, and decided to start down a new path.

I started out writing a shmup using XNA, teaching myself C#. Then I got a job as a game tester at Codemasters. There I met a 3D Artist called Ben, who sold me his PC so I could play more up-to-date games. He wouldn't shut up about one game in particular - Amnesia.

I downloaded the demo and that was pretty much it. This was the game I wanted when I was back in school. It was moody and grim like other first person games I'd grown up with and it made me use my brain. I bought it and after gritting my teeth and getting through it, then went back and took a trip through the halls of Penumbra. I realised that I cared more about story in games than I'd believed. I wasn't averse to a good story in games, it's just that it really mattered how well it was presented and whether there was synergy between plot and gameplay. It was a bit of an eye-opener.

After leaving Codemasters, Ben and I decided to have a go at writing games like this. We survived for a while on contract work while trying our own thing, but none of our bigger projects came to fruition. I could handle the mechanics, but it all felt very shallow without solid design. I kept restarting projects trying to get the formula right; but eventually Ben had to move away, and I had to find full time work. So although it never went anywhere, I've still got bits and pieces of prototypes  lying around spanning Japanese folk horror, Asimov sci-fi and dark cyberpunk.

Some remnants that I found kicking around..

Then I stumbled across a job post for Frictional Games; the ideal job, but it took me a while to summon up enough courage to apply. I got stressed out a lot during the long application process and on multiple occasions as the process went on I gave up and told myself I hadn't got the job, retiring to the bathtub for a sulk. But each time I'd get out of the bath to an email telling me I'd gotten further in the application process. I guess that was to be expected when applying to an indie studio renowned for crafting suspense?

  

As I got through to the last part of the application process, things took a turn for the worse. My grandmother who I was very close to passed away. I also had a wedding very soon, so things were all over the place. I had to ask to push the interview back which was yet another worry on top as it's rather unusual to request such a thing during an application process. However as you may guess, the story has a happy ending. I woke up on August 9^th ready to get married, and checked my email – I had a job offer. So that turned out to be a pretty good day.

What do I do?

 

Most of my work is at an extremely high level using the in-house editors created by Luis and AngelScript, the scripting language we've embedded. Just like Ian and Patrik, I'm responsible for setting up the events that you're going to encounter in the game and ensuring that everything in the environment is hooked up correctly. At the moment I don't do any C++ stuff, but since I'm surrounded by a lot of smart and experienced programmers, there's a lot of opportunity to learn.

Since other bloggers have already talked about the process of creating the levels and the events that make up our levels, I thought it would be fun to go a little deeper in to what it's like to actually work on an event and some of the cool features in HPL3 that facilitate this high level approach to creating the game. I sometimes play with the older Amnesia toolset in my spare time, so it's quite easy to spot where things have improved.

So let's jump right in to some of the really big differences. One of the most used tools in the scripter's arsenal is the Area. In Amnesia, you needed to place down an area with the type set to “Script” and then in order to hook up a simple player/area collision you'd end up with a section of your script file that looked a lot like this:

void OnStart()
{
     AddEntityCollideCallback("Player", "AreaOne", "CollideAreaOne", true, 1);
     AddEntityCollideCallback("Player", "AreaTwo", "CollideAreaTwo", true, 1);
}

Now with HPL3 while you can still add and remove collision callbacks and connections at runtime the process is certainly a lot tidier and easier to maintain with regards to setting these things up at the start.

 

Your old callbacks such as PlayerLookAtCallback and PlayerInteractCallback can still be found under the Basic Callbacks tab but, as you can see, a lot more has been added in HPL3. To set up a basic collision trigger to use in script, we simply have to specify the entities that we want to take into account for the collision and the function name that we want to have called in script. Keep in mind if you have a number of entities that you want to collide with this area, we support wildcards. So if you have a bunch of red cubes you want the player to throw in to a basket, the entities field would have cube_red* and then this works for all matching entities. Lastly, thanks to the handy “Copy” button, we can automatically copy and paste a skeleton method into our script:

bool CollideAreaOne(const tString &in asParent, const tString &in asChild, int alState)
{
     return true;
}

The boolean return type lets us control whether or not the callback will be removed once it has executed, just like the old callback system. The alState parameter tells us whether the player has entered or left the area - there's no need for multiple functions. Say we want all the lights to turn off when the player enters a bathroom and for the player to remark on just how creepy it was when they exit the area and then disable the callback – we can now do all this inside a single function using a combination of the return value and the state parameter.

bool CollideAreaOne(const tString &in asParent, const tString &in asChild, int alState)
{
     /////////////////////////////
     // Player enters the bathroom 
     // (When alState==1, we've entered the trigger area.)
     if (alState == 1)
     {
          Lamp_SetLit(“Bathroom_Lamps*”,false,true);
          return true; // Allow the callback to run again
     }

     /////////////////////////////
     // Player exits the bathroom and remove callback
     // (When alState==-1, we've left the trigger area.)
     else // alState will be -1
     {
          Voice_Play(“CreepyBathroom”);
          return false; // Remove the callback
     }
}

Obviously while this is one of the most basic events you can script it should hopefully demonstrate that with this new approach it's a lot easier to be able to write your scripts in the order you mostly expect events to happen without having to move around in the file too much. This, along with many other improvements that follow the KISS principle, makes HPL3 a lot easier to work with than its predecessors.

  

Another thing that's particularly useful and considerably easier to implement compared to HPL2 is the timed sequence. Perhaps you remember trying to write an intro sequence and ending up with something that looked like this? Certainly if you've ever looked at some of the existing maps you'll recognise this approach and have probably based some of your own scripts around it:

void TimerIntro(string &in asTimer)
{
     string sEvent = asTimer;
     AddLocalVarInt(sEvent, 1);
     bool bPauseAtStep = false;

     float fEventSpeed = 1.0f;
     switch(GetLocalVarInt(sEvent))
     {
          case 0:
             PlayGuiSound("scare_baby_cry.snt", 0.3f);
             fEventSpeed = 4.0f;
          break;

          case 1:
             FadeIn(5.0f)
             FadeImageTrailTo(1.25f,0.1f);
          break;

          // And many more steps to follow!
  
          default:
               bPauseAtStep = true;
          break;
     }

     if(!bPauseAtStep)
          AddTimer(sEvent, fEventSpeed, sEvent);
}

Although this worked, this was a slightly cumbersome way to work with these timed sequences at the higher level. Now, we have helpers specifically for doing this. How they actually work is a little different. We have a separate helper class which holds the current step as an int and then checks to see if the current step should be run or not. The great thing is that all the inner workings of the sequence helpers are exposed through script so it is always possible to add more functionality and reuse this across all maps.

Here's how a sequence now looks:

cSequenceStatesData mSequenceBabyCry;
void SequenceBabyCry(const tString &in asTimer)
{
     Sequence_Begin(“SequenceBabyCry”, mSequenceBabyCry);

     if (Sequence_DoStepAndWait(4.0f))
     {
          Sound_PlayGui(“scares/scare_baby_cry”, 0.3f);
     }
     else if (Sequence_DoStepAndWait(3.0f))
     {
          Effect_Fade_In(5.0f);
          Effect_ImageTrail_Start(1.25f,0.1f,10,10);
     }

     // More steps!

     Sequence_End();
}

This is much easier to work with and lets you move things around with ease without having to change as many things if you want to add something later.

Another feature which I'll praise at least once a month is definitely worth mentioning here. This is where HPL3 really shines for me compared to some other toolsets.

Often it's been the case where I'd have to stop a game in order to make a change, recompile and then get back to the point that I was at in order to test. This could get old pretty fast, especially when you were after a very specific feel that required some fine tuning.

Almost everything you will ever need is exposed through scripts with HPL3 and if it isn't, you can easily write it in script. Most of these with a few exceptions can be reloaded at runtime by simply pressing F5 to reload the level. However, HPL3 will also reload your level script on task switch if you want it to. So you can alt tab over to your scripting file to make a few changes, save the file and when you alt tab back to the game you can just test your event again. Add a debug key that resets all the conditions and you'll find yourself able to tweak values to your hearts content with minimal downtime. However if that still isn't fast enough for you, the game can be left running and can automatically reload changes in your script file - which is particularly efficient if you're running a dual monitor setup.

There's such an extensive list of new features that HPL3 has it would be impossible to list them all here, but in time I suspect all will be revealed.. In the meantime however, if this has gotten you interested in some of the scripting possibilities - you can check out a little more on HPL3 scripting here where Thomas Grip explains some of the other things you can do:

HPL3 Scripting Part 1

HPL3 Scripting Part 2

I think I've rambled long enough, so hopefully now you know a little more about me and what I do with the rest of the team. Cheers!

People of Frictional: Ian Thomas

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

Who am I?

I’m Ian, one of the handful of Brits on the Frictional team. Like Patrik, I’m a level scripter and gameplay programmer. I’m a recent recruit - I only joined Frictional in October 2013, and have been on SOMA since then.

Like everyone else, I work from home. I live in Cardiff in South Wales in a house that was once a butcher’s shop. Kind of appropriate for Frictional, somehow. When we excavated the cavernous and partially-flooded basement, we found a door that led to nowhere. It’s that sort of house.

So here’s the obligatory workspace photo:

Yeah, I know, cluttered! Note how I’ve carefully selected the angle of my screen so that daylight glares right off it. Nice for working on dark, spooky environments, huh?

Background

I’m the old man of the company, and got into the industry by a weird set of diversions. I won’t bore you with the whole thing, but here’s a small selection of the official jobs I’ve had:

• Run a mask and puppet-making company.
• Worked in a cartoon studio (the one who made Superted, for the Brits!) in the days when animations were still drawn by hand on paper.
• Worked in a nut-making factory. You know, like nuts-and-bolts. I’ve still no idea who made the bolts.
• Headed up the team making the official Fireman Sam CD-ROM in the days when CD-ROMs were a new and exciting thing.
• Worked in a department licensing people to dig holes in roads, and also licensing people to supervise other people digging holes in roads. Oddly enough, the number of supervisor licenses vastly outstripped the number of people actually licensed to dig, which explains the UK road system.
• Been chief technical architect for an interactive TV company, designing and building the systems behind a series of interactive TV channels on the Sky platform, when the ‘red button’ was a new and exciting thing.
• Been co-director of a company making educational games for young kids. We released about 40 interactive titles, a bunch of books and a board game.
• Worked on a bunch of LEGO console and PC games as a game mechanics coder, where I got to write code for Obi-Wan and Jack Sparrow and Harry Potter and the like.
• Worked on the port of LittleBigPlanet to the Vita, mostly doing the code behind the touch interface.
• Worked as narrative designer and gameplay/UI coder on the port of Frozen Synapse to the Vita (which, at the time of writing, still isn’t out).

I grew up in Scotland and started out with computers pretty early on: ZX81, Sinclair QL (I was the customer!), then Amiga 500. I coded from the very first because my ZX81 wouldn’t save or load - which meant I’d type in a program, run it a few times, then turn off the computer and would never see that program again. The QL was pretty much a dead-end, but with no real games for it I had to write my own. The Amiga was an astounding machine. I still miss writing for it, and there were so many superb and iconic games on it. For reasons of Windows-hatred I stayed with that Amiga through University (Computer Science in Glasgow), desperately hoping it’d survive - and then moved on to Sun workstations in the computer labs, where I spent too much time creating and running multi-user text games.

After Uni I moved to the middle of nowhere in Wales, which kind of put paid to any aims I might have had to get into the games industry, and that’s why I made a start on that weird list above.

As you can see from those jobs it took a while to get back on track. But games were what I always wanted to do, and when I’d been running the kids’ games company for a bunch of years I finally went ‘you know what? if I don’t get in now, I’ll regret it’ and made the jump to a triple-A studio.

It wasn’t easy. First I had to convince someone in the games industry to take me on. I had years of coding in a bunch of different languages (including C++, very much still the core requirement in a AAA game coder), so I could show off the tech skills; but I also had to convince them that I knew about games and games code. Traveller’s Tales liked my work test; happily I could talk about Monkey Island and Baldur’s Gate for hours. I think they eventually gave in to shut me up.

LEGO Harry Potter. I forget which title.

LEGO Star Wars III. Anakin's acting was so much better than in the movies.

Once I’d had enough of LEGO (I know that sounds unlikely), I moved to Double Eleven in Middlesbrough and worked on the Vita when the Vita was still called some Sony codename or other; oddly enough, collaborating with a Swedish company (Tarsier). After LittleBigPlanet I did a fairly hefty narrative rewrite on Frozen Synapse for the Vita; it’ll be interesting to see what it finally turns into when it comes out.

Converting a gamepad-powered editor to a touch editor can't be hard, right? Right!?

Converting a mouse-and-menu-driven game to sticks-and-touchpad can't be hard either...

Then comes the bit I’m ashamed about. A friend saw a job at Frictional and asked me if I’d be a reference for him if he applied. Of course I said yes; and then I saw the job description. I asked him if he’d mind terribly much if I applied for it too as it looked ideal for me. He said yes, we both applied, and I got the job. I’m not sure if he’s forgiven me yet. (I don't recommend having to do a work test in the spare moments of a project crunch, by the way!)

Ah, I’ve missed something, haven’t I? Why would Double Eleven let me do a narrative rewrite on a title?

Shameless plug!

It’s pretty straightforward. The list of jobs up at the top of the page have been my day jobs. By night *puts on hat and cape* I’ve been doing things with story for about twenty years. All sorts of things. I’ve written feature film scripts - one got made into a full-length film last year, and another shoots this summer. I’ve written books, including kids' books about Cthulhu. I’ve written and designed narrative for games, and have spent many years writing and running live-action events and interactives of all sorts. So it’s nice to be able to bring some of that into the games I’m working on.

I should set the record straight, though, as some games journalists have got that wrong - I don’t do any of the writing or narrative design for SOMA (other than the usual brainstorms the whole company gets into). Mike is our writer, and Mike and Thomas deal with the overall story. I just occasionally edit people’s blogs for typos. :-) I still do narrative design & writing - just not for Frictional.

What do Iwe do?

This section could be a bit bare, because Patrik’s already given you folks a rough idea of the level scripting process for SOMA. And that’s pretty much what I do. So instead, the guys suggested I write a little bit about how we deal with working remotely.

For those who haven’t realised it, Frictional doesn’t have an office. Everyone in the company is remote. While most people are in Sweden, we now have four guys in the UK and one in Spain, and everyone works from home. Everyone also speaks English, which is really useful for me but also brings on the old colonial guilt.

We have textual Skype running constantly, split into a few chat rooms. The main one is normally full of weird links and discussions about which is the best game to be playing on Steam at the moment. I guess it takes the place of people arguing around the coffee machine in an office. Then there’s a chat room for level scripting and design; one for programming; one for art, and we set up whatever other rooms we need for whatever else is going on.

So despite us all being in different places, there’s a constant sense of presence - people are always commenting and chatting via text on Skype, asking each other questions about the game, complaining about bugs, or posting Luis’s Grunt-pinup pictures. 

Then every Friday morning we have a group audio call, where Thomas goes through any general company news and then everyone chats through what they’ve been up to that week. Luis will say he’s been fixing editor bugs in an Eeyore-kind-of-voice, because that’s what he says every week. Someone will be asked to talk, we’ll hear nothing for a while, and then that person will realise they’re on mute. Someone else’s Skype connection will drop constantly. Thomas’s young son will join the conversation with loud squealing, or end it prematurely. Jens, for reasons no-one quite understands, will be mysteriously busy during the meeting. I think he has an allergy. But it all kind of works - it gives you a good overview of what’s going on and it’s good to hear people’s voices. Although it was a weird experience meeting everyone physically for the first time at GDC this year - everyone was about ten years younger than I expected.

Outside of the regular meetings we often have brainstorming audio sessions with Thomas when about to start on new levels or when trying to work through some particularly tricky gameplay problem. (“But look, if Simon could ride a unicycle then this puzzle would be a lot easier - can’t we get Mike to write an underwater circus background into the story?”)

Moving away from Skype, we have a shared wiki where we keep the engine documentation, workflow & pipeline information, and design documentation. We use Google Docs a lot, but generally for more temporary stuff such as the feedback notes everyone in the company gives after trying out a level. All our code and assets are stored in Subversion, along with things like Mike’s scripts. We make use of Dropbox for sharing assets with contractors and freelancers.

For general project and task management we’ve recently moved to Trello, which is a very simple task-management system where you lay out things on virtual index cards - essentially a well-organised Todo list. Before that we were relying on a much more complex task tracker and a series of Google Docs; Trello has simplified that dramatically. Also it has a Pirate mode. Every productivity tool should have a Pirate mode.

We also have something called S&T - Show and Tell. Every so often we have a milestone for a level, after it's been worked on for a few weeks. At that point it should be playable, and everyone in the company spends a couple of hours together playing through it and writing their impressions into a feedback document. So everyone gets a say about whether they think the level is working on all counts - art, gameplay, sound, story, general atmosphere. We'll often have Skype discussion based on that feedback doc and throw ideas around. Then Thomas will do a pass through the comments and mark which things he considers important and which are nice-to-haves. They'll turn into Trello cards for the different people working on the level. (S&T also applies to engine and editor code - it's just that levels are easier to explain!)

This means that unlike some bigger companies, everyone here gets to comment on the direction the game is taking. It's fantastic - you're not just a cog in the machine, faithfully doing what gets handed down to you by the design department. ;-) You also get to see the whole game as it develops instead of working on isolated levels or features.

So, how is it compared to working in an office? It’s really not that different. It’s easier to tune out noise when you’re trying to concentrate on getting something done - you just ignore the ten posts about E3 reveals that have just gone past. It’s very easy to talk to someone else - easier than it was being in an office of three hundred people, really, because by the time you’d trekked down three floors to talk to the rendering team they’d all gone out to lunch. You can play your own music. You can eat garlic-flavoured snacks.

Other companies shy away from remote working, partly because they worry about people being out of the loop. I’ve been in situations in the past where I was the only remote worker and everyone else was in an office. That really sucks. But because there is no central office and none of us really have anyone else to be talking to during the working day, it feels like a nice tight-knit group here.

And that’s the other argument I hear - mostly from bosses - about remote working. “How could we trust that people were getting on with their work?” It’s pretty simple, really - it is about trust. If you don't trust your staff (whether they're in an office or not) then why did you hire them? If you know everyone is into the project, engaged in it, and wants to make a great game, then you don’t have to stand over them checking up on them all the time. 

I’ve waffled on long enough. I hope that gives you a little insight into how we keep it together. Cheers!