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:

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!

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!

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!

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!