People of Frictional: Marc Nicander

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

Who am I:
I'm Marc Nicander, I started working for Frictional Games as a freelance artist back in 2006 and got hired full-time when development on Amnesia started in 2008. When I was freelancing I was still a student so I did my work in my 13 square meter student apartment but I have since managed to get a larger space. This is what my current workplace looks like.

Background:
My first real contact with games was back in 1989 when my parents gave me a NES for Christmas. It was the most amazing thing and I spent countless hours in front of the TV playing games like Super Mario Bros, Zelda and Megaman. It also made an impact on my other hobby, drawing. My drawings changed from being things inspired by comics to mostly being Nintendo characters and home-made Megaman bosses.

When I was in 9th grade I got hold of 3D Studio Max and started playing around with 3D for the first time. I remember it being quite confusing - it wasn't easy to figure out how everything worked on my own. I got together with a friend who knew C++ and we managed to make 2 games. The first was an adventure game with pre-rendered 3D backgrounds, the second a shoot'em up that we entered in a PC Gamer competition. We didn't win anything for it, and working as a game developer in the future felt like a far-off dream.

So, instead, I went on a Media Technology course at Karlsham to study 3D, where I learned Maya, film-making and video editing. While on the course, I discovered a different programme that hadn't been listed when I first applied, a 2-year course called School of Future Entertainment (SOFE) that focused on games programming and 3D for film and games. After my 3 year of Media Technology I applied to SOFE, and it's there that I first found out about Frictional Games.

One night when I was working late on a school project a friend, Emil, called me over to his desk. He had been working late nights on a secret project. We were the only ones left there that night, and he wanted to show it off to someone even though he wasn't supposed to. He was doing models for an extension to the Penumbra tech demo, and to say I was amazed is probably an understatement. The way the game used physics for all the interactions was beyond anything I had experienced in any other game at that point, and it got harder to play other games afterwards when I knew what was possible.

When Frictional started building Penumbra they needed freelance artists to create in-game models for props, and this is where I started my Frictional career. I created 3 objects for Penumbra:Overture: a flare, a lock and an engine. I continued freelancing during the development of Penumbra:Black Plague and worked mostly with props but also built some of the levels. After Black Plague was released work started on the HPL2 engine and I was tasked with building levels for the expansion Requiem. We had feedback complaining about Black Plague's levels mostly being a series of boxes on a single plane and my main goal in Requiem was to fix that. It's one of the reasons why the third level in Requiem is all about climbing.

When development on Amnesia started in 2008 I was hired full time and I was happy to finally have a secure income. Little did I know what was waiting around the corner...

What do I do?
I'm one of the four 3D artists working at Frictional Games. My work is to create the world described in the design documents. This means creating a lot of props, making textures and creating levels. I still do most of my 3D work in Maya but thankfully I no longer have to build full levels in it like I did when I was working on Penumbra:Black Plague.

To further illustrate what I do for those of you who aren't in game development, I'll show you an example of how I make a simple prop. I start out with a basic object, in this case a cube. As you can see in picture A, the cube is built with planes between vertex-points. By adding vertices and moving them around as seen in picture B I can shape the cube into anything I like. If I add more basic objects and modify them I can end up with the result in picture C.

When I'm done with the basic object I save it as a low poly (low detail) object and start adding more details to it. This new model will become the high poly (high detail) object you can see in picture D. We'll use this highly detailed model to trick the viewer into believing that the low poly object in the game is more detailed than it really is. We'll show examples of this in our upcoming artist blog posts along with level building and concept artwork.

(Note: Model is not from SOMA...)

The Five Foundational Design Pillars Of SOMA

First, here is a new video from SOMA showing off an environment captured directly from within the game:



Now moving on to the main topic of this post: The foundational design pillars of SOMA. When creating a game I think it is crucial to have a few basic rules that underlie all other decisions. That way it is much easier to keep everything on track and get the final game to play out as intended. For SOMA our intention is to craft an experience where players become deeply connected and affected by the game's world and themes.

Here are the five cornerstones that we hope will let us achieve this:


1) Everything is story
First up, we want the player to constantly feel as if they are inside a flowing narrative. It is so common that a game is distinctly split into story and puzzle/action moments. We want to blur the boundaries here and make it impossible to distinguish between the two. Whatever the player does it should feel as if it is part of the story. We do not want to have sections that simply feel like blockers to the next narrative moment. From start to finish the player should be drenched in a living, breathing world of storytelling.

A good example is how we design puzzles. Instead of having the puzzle by itself, as a separate activity, it always springs from and is connected to some aspect of the story. For instance, if the player encounters a locked door, there are more reasons for getting it open than simply to progress. There are always short term narrative reasons and rewards for getting it unlocked. On top of this, the very act of solving it results in the player taking part of a narrative scene.

Encounters with hostile beings are handled in the same way. A creature will never attack you without good reason; they never do it out of pure gameplay necessity. We want every encounter to feel like a bit of storytelling is happening. To get this working properly, almost every single creature has unique AI.


2) Take the world seriously
This leads us to the next point: that every detail in an environment is connected to the story somehow. Nothing should be written off as simply a requirement for gameplay or exposition. For instance, if you find an audio log you will be able to learn more about the story by pondering its placement alone. There should be no need to "double-think"; the game's world should be possible to evaluate on its own terms.

We constantly think about what each character would have done in a situation, and shape the environment accordingly. For instance, in one level, we started out with scratches on the walls but later realized the character had access to a whiteboard pen and changed the graphics accordingly.

It's so easy to justify design "because the game needs it" even if it doesn't make sense to the story. But for each such thing you do, the less seriously the player will approach the environment. In SOMA a big part of the game is to ponder the situation you are in.Therefore it's crucial that players consider the world from a story view, and in order for that to happen we must provide them the opportunity to do so.


3) The player is in charge
When you invest this much in a setting, it's important to make sure that players feel connected to it. In order to this we need to put a bigger responsibility on the player. An environment quickly loses its sense of realism if it is extremely streamlined and does not allow you to make choices. The player must be the one that drives the narrative forward.

The game never tells the player exactly how to progress. There may be hints and other implicit guidance, but in the end it must be the player that figures out what to do next. If a game is constantly flashing up cues with objectives or showing arrows pointing where to go, the player will never take on the world at a deeper level. If it takes some effort to progress, players are forced to understand and mentally map the surroundings in a way they would not do otherwise.


4) Trust the player
This brings us to the next point: that we trust players to act according to the story. We do not force players to notice events by use of cutscenes and similar, but assume they will properly explore the environment and act in a rational fashion. We simply set up situations and then let the player have full control over their actions.

This means that we will let players do stupid things even if they might break the experience a bit. For instance, if they skip talking to a character with important information then they are on their own after that. And if they get hints that a dangerous creature is approaching, they need to figure out that hiding is the best course of action by themselves.

While we do our utmost to make the narrative unfold in a fluent and intuitive way, we will not cater to players that make irrational decisions. The environment is set up to be taken seriously and we expect the players to do so too.

5) Thematics emerge through play
Now for our last foundational design rule: that the game's thematics will emerge through play. SOMA is meant to explore deep subjects such as consciousness and the nature of existence. We could have done this with cutscenes and long conversations, but we chose not to. We want players to become immersed in these thematics, and the discussions to emerge from within themselves.

It feels wrong to just shove information down the player's throat. What I find so exciting about having these thematics in a game is that the player is an active participant. There are plenty of books and movies that cover these sort of subjects, but videogames provide a personal involvement that other mediums lack. We want to explore this to the fullest degree

Just like all of the other design goals, there is a bit of risk in this. It requires the player to approach the game in a certain way and it will be impossible to make it work for everyone. But for those people where it succeeds, it will be a much more profound experience. I also find that it is when you are dealing with uncertainties that you are doing the most with the medium, and am extremely excited to see how far it will take us.

Editor feature: New color picker

Hey there! So I finally dropped by to write a quick post on our stuff after quite a long hiatus (exactly 3 years, 3 months and 8 days long according to my last post) and Thomas pretty much took over the blog. Right now most of you might be wondering who's typing even . The name is Luis and I mainly code the tools we use here at Frictional (also the ones you might have been using for making your own Amnesia custom stories) After the quick introduction, here comes a little editor feature showoff.

If you ever used the Amnesia tools yourself, it's more than probable that you already know about this little buddy here:

One could say it is functional. I mean, you actually can pick a color by using it. But it had a little problem. It sucked, and real bad I must add.

When you are editing a level and need to pick a color for anything, be it the diffuse color for a light or the color multiplier for some illumination texture, you are probably going to need a nice system that allows for quick tweaking with not much sweat. This is definitely not the case of our old color picker, mainly because of two reasons: the RGB color space and lack of immediate preview of changes.

Selecting a color in the RGB color space is pretty straightforward you might think. And it is indeed, you only need to set the values for the Red, Green and Blue components and you are all set. That's it. Okay, but what if you need to choose from a range for a particular color tonality? How are you supposed to know which RGB values you need to set for that? Summing up, RGB is a pretty uninintuitive system when it comes to edition, so we pretty much had to update the color picker to use the HSB color model as well.
This model describes colors as follows:

• the H value, ranging from 0 to 360, controls the hue for the resulting color; 
• S, which stands for saturation and ranges from 0 to 100, indicates, in layman terms, how washed the color will look, with 0 being white and 100 equalling the original hue color (for a B value of 100); 
• and finally B, standing for brightness and ranging from 0 to 100 as well, is quite self explanatory and sets how bright the final color will be, with 0 meaning black and 100 meaning the color that is set by the other 2 parameters.

As for the immediate preview, anyone who used the old picker knows that you had to exit the picker in order to apply and see the changes. When you need to tweak things, which involves constantly changing values and checking out how it looks, this setup is bound to get old and annoying way quicker than you would want it to. To fix this, the new picker can change the target color on the fly, letting the user see the end result in the scene while modifying the values.

Another upgrade that speeds things up a lot is going as visual as possible. No matter which parameter you are editing, being able to change it via a slider or some other graphical tool that you can click on will always help tons. The drawback of these, though, is that it's very likely that you spend more time on them than needed just because they are so fun to use.

After all this long-ish introduction, just say hi to our new color picker:

And see it in action in this short demo video:

People of Frictional: Jens Nilsson

Second post in the series. Thomas Grip posted the first, which you can read here.

Who am I
I'm Jens Nilsson, one of the people that started the company in 2006. Back then my work space was dubbed the "Pink Room" and in it all the Penumbra and Amnesia magic happened. The previous occupant of the apartment had a young girl and that room was the girl's room. We did not get around to give it some new paint until the year before we moved out. I dug and dug but could unfortunately not find a picture of it. Anyway, I've always had the luxury of having a dedicated room to work in and currently I am located in a cozy attic space.

Background
I got an urge to make my own games when I was seven years old and the family got a C64. Spent a great deal of time copying the code from the Basic manual and got stuff printing, balloons flying and even the C64 making sounds. Did I understand anything of it beyond the end command "run"? Nope.

My first actual working modification of a game was around 1990 when we had a game called "Italien 90" which was a game written in Basic for the C64. The game was a simple text based football manager for the world cup in Italy 1990. As it was a Basic program you could pause the game, scroll through the code and make changes. I'm sorry Thomas Ravelli, but you got replaced by Jens Nilsson and my stats were all top 9 values. While at it, the rest of the Swedish team got top 9 values as well but they got to keep their names. Sweden won the world cup, over and over, which was quite similar to how they performed in the real competition (group c).

The following years I did not spend much time trying to create anything, kept it to gaming only. Instead I spent a great deal of time playing instruments, at first the piano and later the guitar. I eventually started playing in bands and music was the main occupation during the years 1988 to 2002. In 1995 the family acquired the first computer since the C64, which was an Apple Macintosh 5200. With it some craving for trying to create something with games came back. As in my younger days, actually programing something was not on the table, rather modifying games was what I did the most. Mainly Bungie's game series Marathon, it had third party tools available so you could create and edit content for the game. For anyone interested the Marathon games are available for free through the Aleph One project.

Not very pretty deathmatch level for Marathon.

In 1996/1997 the family computer got bumped to an Apple Macintosh 6400. With this my two interests started to merge and I began using the computer to record and make music.

One day in 1997 I was reading the latest news on insidemacgames.com and there was a post about the next game from Brian Greenstone. He had announced that his next game was going to be freeware and because of it he asked if there were anyone interested in helping out making graphics, music and such. I had no clue at all about how/what to do in terms of music for a game, but I figured I should at least mail and offer to help out. I got a positive response and for the next couple of months we sent emails back and forth. Brian sending new builds and I sent my attempts at making music for it. As this was in 1997 it took time to send or receive an email with a large attachment, as much as 30 minutes. Always with the risk of the dialup connection breaking. Tough times. In the end I only did one track, the one used for the menu. Regardless, I had gotten my first taste of working with some actual game development.

  

 Video of the game Nanosaur (only a few seconds of my music at the start…). 

I finished high school in 1998 and in 1999 I turned my "music for games"-hobby into a self-employment business. The following years I did a lot of small projects, some that never got released, but quite a few that did. Lot's of the work I did was for free, or for little pay, what I earned I mostly spent on getting new gear and software. The main "pay" was gaining experience and contacts. I increasingly did less and less music and more and more sound design. These projects gave opportunities to do tasks other than audio. Scripting, design and such all got some leveling up. Running a small business also required me to get up to speed in all sort of departments. I needed to make websites, understand how to invoice, bookkeep, market, customer relations, international work/pay and all the taxation rules that goes with it, and so forth. Experience that turned out to be quite handy as we started Frictional Games.

Thanks to the wonderful Wayback machine I can show a saved version of my old site. Listed are all the game projects that got released up to 2006.

Captain Bumper, cool and forgotten Mac game.

From 2002 to 2006 I attended a game development program at the Gotland University College. We did some fun projects as part of the education. My favorite is probably the large, foot controlled, floor projected Pong game that we created at the end of the first year. Overall the education was quite chaotic, lots of changes as to what the purpose of it should be. Because of that the quality of the education was lacking. It did allow for a lot of free time, I spent that time doing other projects through my self-employment business. A friend in class one day told me about a guy that he met online. It was some strange dude that was making a horror game and my friend was helping him out making graphics for it. A couple of months later I got in contact with that guy as well, it turned out to be Thomas and his Unbirth project. I did a bit of sound design for it and well, yeah, I think Thomas pretty much covered the rest of how we went from there to Energetic, to the Penumbra Tech Demo and ending up starting Frictional Games.

Four player Pong clone.

What do I do?
I have headed up the audio department, where I have done most of the sound work and design of the sound while working with Mikko Tarmina as our composer. For Amnesia, Kaamos Sound helped out making sounds. For Soma, Kaamos and Samuel Justice are doing all the sound work with Mikko doing his magic with the music. Other game work has been level scripting, level editing, level optimization and design.

I take care of our servers, both for development and for the public sites. This involves setting up and making everything running properly, it could be something as simple as registering a domain, researching and installing a bug tracker, it could be writing the code and server scripts for websites or making sure everything is backed up on a running schedule. I do, or did, lots of our customer support, these days we have a very nice forum community that does way too much of it (in particular one guy…). Like Thomas I also have a slew of small stuff that is done from time to time.

Two rows of not games.

In addition to the server management, what I pretty much only do at the moment is managing the company side of things. This is all sort of stuff not related to game development: Partners, agreements, salaries, taxes, bookkeeping, sales reports, buying equipment, paying invoices, sending invoices, reading and writing a never ending stream of emails and so on and on. At the moment I am not doing any game development due to two reasons. First, we have grown to 12 people and have numerous contractors, partners and service providers. It all requires a bit more time to manage these days. Second, currently only working three days a week, so I have less time than what I used to have (hmm, I can think of quite a few years when we worked seven days…). Next year I'm going back to full time again and with it I should be back to a bit of the game development work.

Four reasons to work three days a week.

If you are thinking, "Oh, the poor sod. From game development to office rat". No, not really! I've always been the most interested in the whole of it, to run a company as well as to do creative work. The main perk with Frictional Games has always been the wide variety of things to do.

I did not go much into details about how I actually do the various things that I do. If you are interested and have any questions about it, just post a comment and I'll do my best to give you a prompt answer.

Tech Feature: Linear-space lighting

Linear-space lighting is the second big change that has been made to the rendering pipeline for HPL3. Working in a linear lighting space is the most important thing to do if you want correct results.

It is an easy and inexpensive technique for improving the image quality. Working in linear space is not something the makes the lighting look better, it just makes it look correct.

(a)  Left image shows the scene rendered without gamma correction 

(b) Right image is rendered with gamma correction

Notice how the cloth in the image to the right looks more realistic and how much less plastic the specular reflections are.

Doing math in linear space works just as you are used to. Adding two values returns the sum of those values and multiplying a value with a constant returns the value multiplied by the constant. 

This seems like how you would think it would work, so why isn’t it?

Monitors

Monitors do not behave linearly when converting voltage to light. A monitor follows closer to an exponential curve when converting the pixel value. How this curve looks is determined by the monitor’s gamma exponent. The standard gamma for a monitor is 2.2, this means that a pixel with 100 percent intensity emit 100 percent light but a pixel with 50 percent intensity only outputs 21 percent light. To get the pixel to emit 50 percent light the intensity has to be 73 percent.

The goal is to get the monitor to output linearly so that 50 percent intensity equals 50 percent light emitted.

 Gamma correction

Gamma correction is the process of converting one intensity to another intensity which generates the correct amount of light.

The relationship between intensity and light for a monitor can be simplified as an exponential function called gamma decoding.

To cancel out the effect of gamma decoding the value has to be converted using the inverse of this function.

Inversing an exponential function is the inverse of the exponent. The inverse function is called gamma encoding.

Applying the gamma encoding to the intensity makes the pixel emit the correct amount of light.

Lighting

Here are two images that use simple Lambertian lighting (N * L) .

(a) Lighting performed in gamma space

(b) Lighting performed in linear space

The left image has a really soft falloff which doesn’t look realistic. When the angle between the normal and light source is 60 degrees the brightness should be 50 percent.  The image on the left is far too dim to match that. Applying a constant brightness to the image would make the highlight too bright and not fix the really dark parts. The correct way to make the monitor display the image correctly is by applying gamma encoding it. 

 (a) Lighting and texturing in gamma space

(b) Lighting done in linear space with standard texturing

(c) The source texture

Using textures introduces the next big problem with gamma correction. In the left image the color of the texture looks correct but the lighting is too dim. The right image is corrected and the lighting looks correct but the texture, and the whole image, is washed out and desaturated. The goal is to keep the colors from the texture and combining it with the correct looking lighting.

Pre-encoded images

Pictures taken with a camera or paintings made in Photoshop are all stored in a gamma encoded format. Since the image is stored as encoded the monitor can display it directly. The gamma decoding of the monitor cancels out the encoding of the image and linear brightness gets displayed. This saves the step of having to encode the image in real time before displaying it. 
The second reason for encoding images is based on how humans perceive light. Human vision is more sensitive to differences in shaded areas than in bright areas. Applying gamma encoding expands the dark areas and compresses the highlights which results in more bits being used for darkness than brightness. A normal photo would require 12 bits to be saved in linear space compared to the 8 bits used when stored in gamma space. Images are encoded with the sRGB format which uses a gamma of 2.2.

Images are stored in gamma space but lighting works in linear space, so the image needs to be converted to linear space when they are loaded into the shader. If they are not converted correctly there will be artifacts from mixing the two different lighting spaces. The converstion to linear space is done by applying the gamma decoding function to the texture.

      (a) All calculations have been made in gamma space 

        (b) Correct texture and lighting, texture decoded to linear space and then all calculations are done before encoding to gamma space again

Mixing light spaces

Gamma correction a term is used to describe two different operations, gamma encoding and decoding. When learning about gamma correction it can be confusing because word is used to describe both operations.
Correct results are only achieved if both the texture input is decoded and then the final color is encoded. If only one of the operations is used the displayed image will look worse than if none of them are.

     (a) No gamma correction, the lighting looks incorrect but the texture looks correct. 

(b) Gamma encoding of the output only, the lighting looks correct but the textures becomes washed out
(c)  Gamma decoding only, the texture is much darker and the lighting is incorrect. 

(d) Gamma decoding of texture and gamma encoding of the output, the lighting and the texture looks correct.

Implementation

Implementing gamma correction is easy. Converting an image to linear space is done by appling the gamma decoding function. The alpha channel should not be decoded, as it is already stored in linear space.

// Correct but expensive way

vec3 linear_color = pow(texture(encoded_diffuse,  uv).rgb, 2.2);

// Cheap way by using power of 2 instead

vec3 encoded_color = texture(encoded_diffuse,  uv).rgb;

vec3 linear_color = encoded_color * encoded_color;

Any hardware with DirectX 10 or OpenGL 3.0 support can use the sRGB texture format. This format allows the hardware to perform the decoding automatically and return the data as linear. The automatic sRGB correction is free and give the benefit of doing the conversion before texture filtering.

To use the sRGB format in OpenGL just pass GL_SRGB_EXT instead of GL_RGB to glTexImage2D as the format.

After doing all calculations and post-processing the final color should then to be correct by applying gamma encoding with a gamma that matches the gamma of the monitor.

vec3 encoded_output = pow(final_linear_color, 1.0 / monitor_gamma);

For most monitors a gamma of 2.2 would work fine. To get the best result the game should let the player select gamma from a calibration chart.

This value is not the same gamma value that is used to decode the textures. All textures are be stored at a gamma of 2.2 but that is not true for monitors, they usually have a gamma ranging from 2.0 to 2.5.

When not to use gamma decoding

Not every type of texture is stored as gamma encoded. Only the texture types that are encoded should get decoded. A rule of thumb is that if the texture represents some kind of color it is encoded and if the texture represents something mathematical it is not encoded. 

• Diffuse, specular and ambient occlusion textures all represent color modulation and need to be decoded on load 
• Normal, displacement and alpha maps aren’t storing a color so the data they store is already linear

Summary

Working in linear space and making sure the monitor outputs light linearly is needed to get properly rendered images. It can be complicated to understand why this is needed but the fix is very simple.

• When loading a gamma encoded image apply gamma decoding by raising the color to the power of 2.2, this converts the image to linear space 
• After all calculations and post processing is done (the very last step) apply gamma encoding to the color by raising it to the inverse of the gamma of the monitor

If both of these steps are followed the result will look correct.

References

·         https://en.wikipedia.org/wiki/Gamma_correction

·         http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

·         http://filmicgames.com/archives/category/gamma

People of Frictional: Thomas Grip

Introduction
This will be the first part in a series where we introduce all the members of Frictional Games. Apart from the obvious "getting to know the team", it will also be an insight into the daily workings of the company. What makes Frictional Games different from many other developers is that everybody works from home, rarely meet in person and very few have had any professional game making experience before joining the team. All communication is done over Skype (plus the rare phone call), and for the last few years the whole team only meets up once a year. When we tell this to people we usually get surprised reactions, and they have trouble understanding how it all can work. Hopefully this series can help answer that.

With that said, let's get this series started! First up, I will get myself out of the way.

Who am I?
Hi all! My name is Thomas Grip and I am one of the two founding members of Frictional Games. For the first few years at Frictional Games I used to work from my living room, on a desk placed next to the TV.(This made me an expert in shows like Top Model, Bold and Beautiful and whatever my fiancee watched while I worked during the evenings.) Eventually we moved to a bigger apartment and I got my own office. This how my work space looks right now:

Background
I started out making games in 1997 (when I was 16) and my first game, called "Köttar Monstret" (yeah, I know...), was made on a TI-83 and became kinda popular in my class. At the time I did not have a computer, and had never really used one. I did not feel I was a very technical person and even though I had chosen to study the natural sciences, my main interest was with art and I drew and painted a lot. But when I started to program on that TI-83, which was quite clunky with only 8 or so short lines visible at once, it was like a revelation to me. I had never understood that you could do this sort of thing with a computer. I was hooked, and needed to learn more. First up, I got hold of an actual PC, this wonderful machine, and started to learn QBasic on it. With no access to the internet, my only source of information was old and worn programming books that I found at the library. I remembered that I searched hard for some book that explained how to display graphics. When QBasic did not tell me, I learned Pascal, but no graphics in there, so I went on to C, but I did not find anything there either. The best I could do was to get colored symbols from the extended ASCII character set, but that was no fun, I wanted proper pictures!

When at school I mostly spent lectures drawing stuff like this.

Eventually, I stumbled upon a book, called Game Programming Explorer or something, in the back of a strange bookstore at the outskirts of my home town. It explained to me that I had to program these routines myself! So I learned all about the wonderful world of Mode 13h. Soon after I bought a proper PC (120Mhz if I recall correctly) that some shady guy had advertised in the newspaper. As we got better access to internet at school I found a site called ProgrammersHeaven.com (it looked different back in 98) and I downloaded tons of stuff on floppy disks. My most important discoveries were Denthor's Asphyxia Tutorials and a small game called "Boboli" that came along with source code (made by this guy). These were my main inspirations for a while - until I stumbled upon Allegro. This was (and still is) a game development library with tons of useful functionality. No longer did I need to code all those low-level graphics, keyboard and sound routines myself! It was like magic to me. And what was more, around this library was a whole community of people making games.There were annual competitions, reviews and an online database with all games using the library. As far as I know, this was the first gathering similar to today's indie movement.

Exploring a dark basement in my first proper horror game, Fiend.

Using Allegro I created Project 2 and continued making another similar top-down game using rendered Half-Life models. Eventually I made Fiend, the game that set me on the course as a horror game developer. In this game I made pretty much everything myself, code, art and music. As a sidenote, it is interesting to note that I had zero expectations to make any money from this. I simply made these games, because I loved making them. Even getting player feedback was a rare thing. The very idea of selling my games was preposterous. I think this was a pretty common mindset at the time, and quite different from how it is nowadays with outlets like Steam. Making your own games feels much more like a viable career option today. Back in 2000 this was not the case at all.

In 2002 I started studying at the university (bachelor of science in software engineering) and I had also started my next project: Unbirth. This time I wanted to make it in 3D and started the to learn some basic modelling and texturing. However, there was a big problem with finding a 3D engine. All the good ones were commercial and expensive, and the free alternatives did not feel like viable options. I think the best one was Ogre3D, but it was lacking a lot of features back then. Luckily, I got in contact with a guy that was developing his own commercial 3D engine and I got to use it for free. I worked on the game for 2 years, but it never got completed, mainly due to various engine problems along the way. After this I swore to never use unfinished third-party software again, and try to make as much as possible by myself. All this time was not wasted though as I had learned tons about the structure and design of a game engine. Had I not used this engine for Unbirth, I doubt I could have created my own later on.

Jumping and shooting, while conserving energy, were the core aspects of Energetic.

During the development of Unbirth I got to know Jens, whom I would later found Frictional Games with, and as our university educations would end at the same time, we decided to make a thesis project together.This resulted in Energetic, which can be seen as a the first step towards the formation of Frictional Games. It was the first project that we made from the ground up together and some of the game's engine code is still in use (the engine was actually named HPL at this point).

When university was over I did not know what to do next. I knew I wanted to make games, but I do not think I ever saw it as a proper career path and instead just thought I should do something non-game programming related. At  this point Jens asked me if I wanted to do a Master's course at Gotland. The course was all done from a distance and was mainly about making a big game project. That sounded really interesting to me, so before the course even started, I began working (using Energetic's code as a base) on my own 3D engine. The idea was to make a game that continued along the same lines of Unbirth. And one thing was sure: I did not want to use a third party engine again.  When the course was over, the Penumbra Tech Demo was the result. The game did not do very well at a competition we submitted it to (SGA), but I hoped it might be a way to get a foot inside some actual game company. However, a month or so after putting it up online, it exploded and got downloaded more than a million times over the course of the summer. Remember that all start-up game devs: bad results in a competition is not the end of the world!

Before starting Penumbra: Overture, we had some plans to do a sci-fi brawler/shooter. Here is an enemy sketch I made for that game.

With this success behind us, we decided to try and start a company, and I scrapped my thoughts on joining a "proper" game developer. The technology used in the tech demo was the foundation for our first game "Penumbra Overture", with the team consisting of myself, Jens and another guy from the master's course, Anton.  Having worked on the game for more than half a year,  Frictional Games was officially formed January the 1st, 2007.

Working from home means you sometimes need to do multiple tasks at once...

What do I do?
When Frictional Games first started I did all the C++ programming, level design, planning, about half of the map scripting (using Angel Script), most concept art and even some level modelling. As we hired more people the amount of stuff I have to do has (thank god!) gone down a bit, and currently I mostly do design, part of the programming and most of the planning. I also act as a sort of lead artist and decide in broad terms what direction the art should take.

The thing that I spend most of my time doing these days is design work. This includes a large variety of tasks, and the most obvious is simply writing a design document for each level. When making the type of games that we do, a proper design for each level is crucial. We do not have any basic gameplay mechanics that you can simply add in a variety permutations. Every activity must be designed, programmed and often have specific art assets created for it. On top of that, every single part of the game is deeply connected with the story. Actually, when we create our games we do not really separate the gameplay and story, as both stem from the same kind of interactions. The only thing that we take care of separately is the plot, which is something that is written at a fairly early stage and describes the main happenings that the player will take part in.

So when you have a game like this, you cannot just start with a basic ideas and then flesh things out as you go along (as you might do in a shooter). Normally, we have our writer, an artist, a programmer and sometimes even our sound and music people doing assets for a level at the same time. All of these parts are crucial for the final experience and had we not had a written plan that everybody could use as a base, then nothing would work. However, the design document is not something set in stone. It just represent the first draft. As the map is being implemented things evolve and might change quite drastically. This means that the people who are working on the map, writer, programmer and artist, are all part-designers as well. Sometimes it is just not possible to implement something like the design document says, sometimes details are missing and sometimes new ideas that takes things in a entirely new direction pop up.

Example of the amazing ms-paint art I sometimes send as feedback to artists.

This leads to my biggest design related task: feedback. As all of the assets and implementations are constantly in flux it is my job that make sure that they are still coherent with the overall vision of the game. This might sometimes lead to long discussions on what the intentions are, nagging on specific details or just explanations of the bigger picture. While crucial, this sort of things is often annoying to me because it never feels like you are never accomplishing anything. You basically just pester people about changing things. But it is also a great feeling, as you got more of an outside view and can see the entire project coming together, step by step.

The programming tasks I do mostly have to do with subsystems, map scripting and AI. At the start of SOMA (our current project), I did a lot of tech related programming, for instance terrain, undergrowth and scripting. But ever since we hired a dedicated tech programer I hardly do any of that. I still try and get my hands dirty in tech when I have time for it though, and I implemented an immediate GUI system quite recently. But mainly I just plan out what tech related things to focus on, and help out with some of the high-level design. Since I do most of the gamedesign work, I try and program the more design-sensitive or unpredictable parts when I am able to. I think that if you as a designer only ever supervise the construction of a game, there is a certain magic that gets lost. For certain parts of the gameplay, you cannot say how you want it to work until you see it in action. Therefore I feel it is very important that I build some of that stuff, like AI and certain visual effects, myself.

All planning is done in Google Docs. Here is how end of last year looked like. (Spoilerish stuff cencored!)

Finally, I also do a lot of the planning for the project. Our approach is not to micro manage or waste time on any sort of strict development method. What we do is that every week people get something they should work on and then we have special "Show And Tell"-days when the task should be done and shown to the rest of the team. How to utilize the time during the week is totally up to each and everyone. Despite having this loose attitude towards planning, there is still quite a lot of work to it. Whenever some assignment slips, it often affects the schedule of several other team members and you need to move stuff around.. It is also important to constantly plan far ahead, and make sure that project is on track. It is easy to just get focused on the "here and now" and forget about the overall progress. As early as possible we make a rough plan on when the game is to be completed, and then update that with more detailed information as we go along. This can be really depressing work, as looking a year or two into the future makes it feel like the time ahead is so short, which leads you to thinking life is too short, etc, yada, yada.

There is a bunch of other small stuff that I do, like pr, interviews and booking travel. But all that is not very interesting and I think you should have heard enough now to have a fairly good idea of what it is that I do all day!


Stay tuned for more! In two weeks it will be time for Jens, the other founder of Frictional, to talk about his past and what his job is all about.