Four months after Amnesia's release

Introduction
Frictional Games have now officially existed for almost exactly four years (4 years and 7 days to be exact), Amnesia: The Dark Descent is our fourth game and it is now four month since we released it. Because of this we thought it was time for another round-up of sales and other stuff that has happened.

Those who have read our two previous reports might have noticed a small trend of the later being a little bit more positive than the earlier. This post will not be an exception and we can happily announce that things are looking better than ever for us. Summarizing all sales since release actually puts us in a state that we never imagined being in.


Sales
Let's start with what I guess people are most interested in - sales. When counting all online sales as well a the Russian retail copies, we have now sold almost 200, 000 units! This is a tremendous amount and more than we ever thought we would. Our "dream estimates" before release was something around 100k, and to be able to double that feels insane.

Note that more than half of these units have been sold at a discounted price (with as much has 75% of the price off), so the total earnings are not as much as it first sounds. Still, we are in incredible good financial situation right now. Also, the daily sales are still quite high and the average has not dropped below 200 units yet. This means that we can still pay all daily costs from these sales alone, allowing us to invest the other earnings into the future (for outsourcing, PR, etc). It also gives us a healthy buffer and allow us to manage any unexpected happenings the future might hold.

With these figures at hand, we must confess that it gives us new confidence for the PC. The sales that we have had (and are having) are more than enough to motivate developing a game with the PC as the main (and even only) platform. Based on what we have seen, the online PC market is just getting bigger and bigger, and we are convinced we are far from the end of this growth. We think that other developers that consider making their game exclusive to a console might want to think again.

However, our sales have not been typical and it is safe to say that we have earned more than most other indie PC games. We have been extremely lucky with our media coverage and gotten tons of free PR (more on this later), something that has greatly influenced our sales compared to other titles. As proof of this, in the Steam sales charts we have been among the top three games for Adventure and Indie categories almost the entire time since release, often quickly above many of the games that were released after ours. With this we do not seek to discourage others from creating PC games, we are just saying that 200k units is not something that should be expected after 4 months of sales of an indie game. The market does continue to grow though, and it might not be long before these kinds of numbers are considered perfectly normal.

There is another really important thing that needs to be taken into account: If we have had a publisher and sold according to current figures, we would not be in the state that we are in now. More likely, we would now be something more like our first sales summary post. We would probably just have paid back our advance, and just recently been receiving royalties (at a much lower rate, like 25% of what we get now). This means that we would probably be looking for a new publishing deal at this point instead of having the freedom we now have. This does not mean that publishers are evil, just that one should think carefully before signing up for anything. Releasing a game without any financial backing or help with marketing is quite a struggle, but if you pull it off it is well worth the effort!


Media and PR
While we tried to make as much noise as possible at the release of the game, our marketing efforts have been far from big. Our main tactics have been to spread movie clips from the game, releasing a playable demo and to send out review copies. We think that most of this paid off as much as we could have hoped for, with great responses to trailers, players liking the demo and awesome reviews. However, plenty of PR came from a quite unexpected source, namely from user generated content.

An idea that we threw around before release was to have some kind of audience reaction footage, like Rec and Paranormal activity trailers have had. Having too much to do, we just left the idea lying and never did anything about it. However, shortly after the release of Amnesia players made their own videos with exactly this content! The extent that these have spread is quite amazing, one video having 775k views at the time for writing. That is almost a million views! And without any cats!

As we have now entered a new year, there have of course been a lot of awards. What is extra exciting about that is that we actually have been gotten a few! Just recently we got three nominations for Independent Games Festival, something that we are very thrilled about. Yahtzee of Zero Punctuation fame was kind enough to name Amnesia his forth best game of the year. Elder Geek awarded us PC Game of the year which was quite unexpected. IGN is currently nominating us for best horror game of the year and also awarded us best horror and coolest atmosphere for PC. Plenty of other awards have been given too and we are extremely happy about this kind of response!

How has these awards and nominations been us PR wise? Unfortunately it is a bit hard to say as all were announced during the Christmas sales, a time when sales where much higher than usual. Now when it is over, we do see around a 75% increase in daily sales compared to before the Christmas sale started. We think the awards and nominations are part of this increase, but the increase in new players during the holidays have probably also helped spreading the word and boost the sales.

What we can tell though, is that the awards and nominations gotten us more attention from the media. Especially after the IGF nomination we have gotten a lot of mails regarding interviews, review requests and similar. So even if these kind of things are not crucial for current sales, they can prove very important for the future of our company.


Current situation and future
So obviously Amnesia has been a huge success for us at Frictional Games, but what does it mean for us as a company? First of all, we are now completely financially stable and have enough money to complete our next game without any problems. It also means that for the first time in our lives we can actually get decent salaries, something that I personally would never thought would be possible. This means that Frictional Games is no longer a struggling endeavor that we will continue until our energy runs out. Instead Frictional Games has now become a proper career, income provider and something we hope to continue for a long time forward. Compared to how we felt just a few months ago, often considering getting "proper jobs", this is quite a wonderful change!

Our financial situation also means that we are able to take some amount of risk. While we of course do not aim to go crazy, it means that we can try out new things without risk of going bankrupt. It also means that we might have means to release a new game more frequently than every other or third year. We have some ideas on how to approach this, and are actually in the process of trying some things out.

As for our plans to focus on consoles, as hinted above, this is something we are reconsidering. If online sales figures continue like they have with Amnesia, there is actually not any reason for us to release to anything but PC. Still, it would be foolish not to try consoles out and our current idea is to work together with a third party to do a port. This would mean that we can still can keep a small staff and not risk growing beyond our capabilities.

We are also hard at work with our new game which we are extremely excited about. While we still do not want to disclose to much, our goal is to take "experience based gameplay" to another level. We aim to use the emotions that Amnesia was able to provoke and to focus them in a different direction, which will hopefully give delightfully disturbing results.



Finally, a big thanks to everybody who have supported us over the years, played our game, spread the word, made crazy videos, etc. We hope you all will continue to support is into the future!

Embracing Hardness

I am not very fond of new year's resolutions, but I will make one anyway: From here on, I promise myself to never take the simple way, but always take the hard one, when making game.

This might seem a bit weird, so let me explain myself.


When creating games in the past we have sometimes tried to take the easy way out, hoping to create a lot of "playtime" for little effort. This kind of thinking have always ended up being the worst parts of the game or the worst ideas. For example, in Penumbra Overture, I designed some of the maps to be maze-like and have roaming enemies, thinking it would be an easy way of adding engaging parts to the game. These levels turned out to be tedious and easily my least favorite parts of the game. Another example is from Amnesia: When coming up with the basic gameplay design we were set on creating some easy way of making levels. This ended up being a bad way to go about it and we pretty much discarded all of these features in the final game. Instead we went back to doing it the hard way - with much better results.

After releasing the Penumbra games, we actually felt a bit annoyed that it was so hard to make new maps for them. We saw that other games could put out a lot of map-packs and similar, but this was very hard for us, and would cost almost as much as making a new game. This feeling is not a new one, and I have personally felt like this many times. The ability games that could be completed quicker and that allowed for simple expansions.

This feeling has resided a bit after the release of Amnesia, but until very recently it was still there, nagging me. Then it suddenly occurred to me that I should not feel bad about having work that is hard to make. Instead I should feel proud and embrace it. I know this might sound a bit silly and self-evident, but it honestly came as a bit of a revelation to me. Not only should I feel good about any part of the game that was hard to make, I should actively strive for it and discard anything that is too easy. If a feature can easily create gameplay for a part of the game, it should be considered a bad idea and either scrapped it or a adjusted into a harder version. This not only because of personal motives, but because I am quite convinced that it will result in better games.

We should of course try and make the process of creating the game as simple and straightforward as possible. Just like we, to great success, improved and greatly simplified level and entity creation for Amnesia. Handling the tools of the trade is not what is meant to be hard, but the act of creation. I am also not implying that we should try and reinvent the wheel and try to come up with new solutions to already solved problems. What I am saying is that if any part of the game is too easy to design or implement, then we should be critically examine if it is really needed and if we really put enough thought into it. It should be considered if there are any ways to vary, expand or in any other way change it to make it harder.

What I am hoping will come out of this, are games that give a much richer experience. I think a good example of this at work is to compare a game like Braid to a "normal" puzzle game. The first few levels of Braid could easily have been expanded into a full game, but instead the hard route was taken. This resulted in a game where the gameplay is constantly fresh and provides a much deeper experience. You also see the same kind of forces at work when comparing the Super Mario games to contemporary platformer titles. There is a certain degree of quality to the Mario games, a large part of which I think comes from to doing things the hard way.

This will most probably result in more work for us, but as I now aim to embrace hard problems, that should only mean we are on the right track!

Player - Avatar Symbiosis

In a recently released paper, Jeroen D. Stout (creator of Dinner Date) proposes an interesting theory on the relashionship between player and avatar. It is related to the things that have been discussed previous post about immersion, so I felt it was relevant to bring it up. The full paper can be gotten from here. I will summarize the ideas a bit below, but I still suggest all to read the actual paper for more info!

Most modern theorists of the mind agree that it is not single thing, but a collection of processes working in unison. What this means is that there is no exact place where everything comes together, but instead the interaction between many sub-systems give rise to what we call consciousness. The most clear evidence of this is in split brain patients, where the two brain-halves pretty much form two different personalities when unable to communicate.

This image of a self is a not fixed thing though and it is possible to change. When using a tool for a while it often begins to feel like an extension of ourself, thus changing ones body image. We go from being "just me" to be being "me with hammer". When the hammer is put down, we return to the old previous body image of just being "me". I have described an even clearer example of this in a previous post, where a subject perceives a sense of touch as located at a rubber hand. Research have shown that this sort of connection can get quite strong. If one threatens to drop a heavy weight or similar on the artificial body part (eg the rubber hand), then the body reacts just like it would to any actual body part.

What this means for games is that it is theoretically possible for the player form a very strong bond with the avatar, and in a sense become the avatar. I discuss something similar in this blog post. What Jeroen now purposes is that one can go one step further and make the avatar autonomously behave in a way that the players will interpret has their own will. This is what he calls symbiosis. Instead of just extending the body-image, it is the extension of the mind. Quite literally, a high level of symbiosis means that part of your mind will reside in the avatar.

A simple example would be that if player pushes a button, making the avatar jump, players feel as if they did the jumping themselves. I believe that this sort of symbiosis already happens in some games, especially noticeable when the avatar does not directly jump but has some kind of animation first. When the player-avatar symbiosis is strong this sort of animation does not feel like some kind of cut scene, but as a willed action. Symbiosis does not have to be just about simple actions like jumping though, but can be more complex actions, eg. assembling something, and actions that are not even initiated by the player, eg. picking up an object as the player pass by it. If symbiosis is strong then the player should feel that "I did that" and not "the avatar did that" in the previous examples. The big question is now how far we can go with this, and Jeroen suggests some directions on how to research this further.

Having more knowledge on symbiosis would be very useful to make the player feel immersed in games. It can also help solving the problem of inaccurate input. Instead of doing it the Trespasser way and add fine-control for every needed body joint, focus can lie on increasing the symbiosis and thus allowing simply (or even no!) input be seen by players as their own actions. This would make players feel as part of a virtual world without resorting to full-body exo-skeletons or similar for input. Another interesting aspect of exploring this further is that it can perhaps tell us something about our own mind. Using games to dig deeper into subjects like free will and consciousness is something I feel is incredibly exciting.

Tech feature: Light Masking

So just wanted to give a quick info on a brand new feature: light box masks.

When placing lights in some rooms, it is common that light bleeds through walls, and show up in other rooms close by. The obvious way to fix this is to add shadows, but shadows can be pretty expensive (especially for point lights), so it is not often a viable solution. In Amnesia we solved this through careful placement, yet bleeding can be seen in some places.

To fix this I added a new feature that is able to limit the lights range with a box. This way the light can cast light as normal but is cut off before reaching an adjacent area. This pretty much does the job of shadows, but is much cheaper.

It turned out to be pretty simple to implement as well. In the renderer, different geometrical shapes are used to render lights (spheres for point lights and pyramids for spots) which make sure the light only affects needed pixels. To implement the masking, these shapes where simply exchanged for a box and then with some small shader changes it all worked.

Without masking:

With mask:

Bye, bye Pre-Pass lighting

I have an announcement to make.

I am dumping pre-pass lighting.

A couple of weeks ago I started to remaking the renderer from a deferred shader to a pre-pass lighting one. Directly after implementing it, I wrote this post. At first, pre-pass lighting sounded great: faster light rendering and more variation in materials. Having seen that companies such as Crytek and Insomniac Games used it, I thought it would be the next logical step to take.

However, even as implemented it, the problems began. The first one was that specular lighting has to be made through hacks or something that makes it closer to deferred lighting. The next was that implementation become more messy. I suddenly needed to redraw all objects in two separate passes and this made the material and shader code harder to maintain. Normal deferred shading has this nice design where all material info is rendered in one pass to one buffer. But in pre-pass lighting, this spread out and makes more annoying to add new stuff and to update existing.

Still, I stuck to it, because I was sure that the speed and material variety would make up for it. One of the features I was looking forward to was making more interesting decals, with normals and such. Since only the light data is written to an accumulation buffer I thought this would allow me to easily put more effects to the decals. However, I quickly realized that I had been quite foolish and not considered that pretty much every interesting part of a materials is added when lighting it. The surface normals, specular, etc are all baked into the light data. So I ended up doing tricks that I could actually work with normal deferred shading.

So what ended up with was lighting of worse quality, compared deferred shading, and with no more room for special effects. Still, this rendering is much faster right? Well, I did some checks which I collected in this post. It turns out that pre-pass is actually slower unless in very specific situations. None of the improvements I was hoping for turned out to be true.

Still, I stuck to it. I am not sure why, but I guess I did not want to face the truth after having put so much time and effort into it. Going back to the old renderer was something I did not want to consider.

Then last week, as I was starting making undergrowth for the terrain, it suddenly happened. I realized that I had to render the vegetation twice, creating more overdraw and making it a lot more cumbersome to implement. At this point I decided that I should seriously consider going back to the old deferred renderer. What I was most worried about about was that it would exclude us from consoles, but I found out that games like Burnout Paradise used a deferred shader too, and assuring me that consoles would still be possible to do.

This post by Adrian Stone, with an in-depth discussion on the subject, sealed the deal for me and I got to work with going back to deferred shading. I had actually come across Adrian's post before when implemented pre-pass lighting, but never read it carefully. I guess it would not had made me stop then since I wanted to check it out myself, but it is interesting to see how one can convince oneself that something is correct, to the point of avoid contradictory sources. This is a very important lesson to learn and one should always be prepared to reconsider and "kill your darlings".

Right now I have fully implemented the deferred shader again and even updated it a bit too. For one thing, I fixed so the decals support all the feature I had in the pre-pass lighting shader. Since we are aiming for a little higher specs (shader model 3 or 4) for our next game, I took that into account and was able to add some other fun stuff. Examples are colored specular and saving the emission in the g-buffer (allowing to cheaply to a variety of effects).

I am really happy to back to the old renderer and now that I am adding new features things are going a lot smoother. The pre-pass renderer was not all in vain though. I cleaned up the rendering code a lot and it also made me rethink how some features could be added. Last but not least, it also reminded me that I should never get too attached to an idea.

Tech Feature: Terrain textures

I have finally finished the part of the terrain rendering that I spent most time researching and thinking about: texturing. This is a quite big problem, with many methods available, each having its own pros and cons.

I was looking for something that gave a lot of freedom for the artists, that was fast and that allowed that the same algorithm could be used in both game and editor. The last point was especially important since we had much success with our WYSIWYG-editor for Amnesia, and we did not want terrain to break this by requiring some complicated creation process.

Even once I started working on the textures, I was unsure on the exact approach to take. I had at least decided to use some form of texture splatting as the base. However there is a lot of ways to go about this, the two major directions being to either do it all in real-time or to rendering to cache textures in some manner.

Before doing any proper work on the texturing algorithm I wanted to see how the texturing looked on some test terrain. In the image below I am simply project a tiling texture along the y-axis.


Although I had checked other games, I was not sure how good this the y-axis projection would look. What I was worried of was that there would be a lot of stretching at slopes. It turned out that it was not that bad though and the worst case looks something like this:

While visible it was not as bad as I first thought it would be. Seeing this made me more confident that I could project along the y-axis for all textures, something that allowed for the cached texture approach. If I did all blending in real-time I would have been able to have a special uv-mapping for slopes, but now that y-axis projection worked, this was no longer essential. However, before I could start on testing texture caching, I need to implement the blending.

The plain-vanilla way to do is, is to have an alpha texture for each texture layer and then draw one texture layer after another. Instead of having many render passes, I wanted to do as much blending in a single draw call. By using a an RGBA texture for the alpha I could do a maximum of 4 at the same time. I first considered this, but then I saw a paper by Martin Mittring from Crytek called "Advanced virtual texture topics" where an interesting approach was suggested. By using an RGB texture up to 8 textures could be blended, by letting each corner of an rbg-cube be a texture. A problem with this approach is that each texture can only be nicely blended with 3 other corners (textures), restricting artists a bit. See below how texture layers are connected (a quick sketch by me):

Side note: Yes, it would be possible to use an RGBA texture with this technique and let the corners of a hyper cube represent all of the textures. This would allow each texture type to have 4 textures it could blend with and a maximum of 16 texture layers. However, it would make life quite hard for artists when having to think in 4D...

When implemented it looks like this (note he rgb texture in the upper right corner):


However, I got into a few problems with this approach, that I first thought where graphics card problems, but later turned out to be my fault. During this I switch to using several layers of RGBA textures instead, blending 4 textures at each pass. When I discovered that is was my own error (doh!), I had already decided on using cache textures (more on that in a jiffy), which put less focus on render speed of the blending. Also this approach seemed nicer for artists. So I decided on a pretty much plain-vanilla approach, meaning some work in vain, but perhaps I can have use for it later on instead.

Now for texture caching. This method basically works as the mega texture method using in Quake Wars and others. But instead of loading pieces of a gigantic texture at run-time, pieces of the gigantic texture is generated at run-time. To do this I have a several render textures in memory that are updated with the content depending on what is in view. Also, depending on the geometry LOD I use, I vary the texture resolution rendered to and make it cover a larger area. So texture close to the view use large textures and far away have much lower.

I first thought had to do some special fading between the levels and was a bit concerned on how to do this. However, it turned out that this was taken care of the trilinear texture filtering quite nicely (especially when generating mipmaps for each rendered texture). When implemented the algorithm proved very fast as the texture does not have to be updated very often and I got very high levels of detail in the terrain.

Side note: The algorithm is actually used in Halo Wars and is mentioned in a nice lecture that you can see here. Seeing this also made me confident that it was a viable approach.

The algorithm was not without problems though, for example the filtering between patches (different texture caches) created seams, as can be seen below:

(click to enlarge, else it will not be seen)

The way I fixed this was simply to let each texture have a border that mimicked all of the surrounding textures. While the idea was simple, it was actually non-trivial to implement. For example, I started out with a 1 pixel border, but had to have a 8 pixel border for the highest 1024x1024 textures to be able to shrink it. Anyhow, I did get it working, making it look like this:

(Again, click image to see full size!)

Next up was improving the blending. The normal blending for texture splatting can be quite boring and instead of just using a linear blend I wanted to spice it up a bit. I found a very nice technique for this on Max McGuire's blog, which you can see here. Basically each material gets an alpha that determines how fast each part of it fades. The algorithm I ended up with was a bit different from the one outlined in Max's blog and looks like this:

final_alpha = clamp( (dissolve_alpha- (1.0 - blend_alpha ) / (dissolve_alpha * (1-fade_start), 0.0, 1.0);

Where final_alpha is used to blend the color for a texture and fade_start determines at which alpha value the fade starts (this allows the texture to disappear piece by piece). blend_alpha is gotten from the blend texture, and dissolve_alpha is in the texture, telling when parts of the texture fades out.

So instead of having to have blending like this:


It can look like this:


Now next step for me was to allow just not diffuse textures, but also normal mapping and specular. This was done by simply rendering to more render targets, so each type had a separate texture. This would not have been possible to do if I had blended in real-time as I would have reached the normal limit of 16 texture limits quite fast. But now I rendered them separately, and when rendering the final real-time texture I only need to use a texture for each type (taken from the cache textures). Here is how all this combined look:

You can see small version of each cache texture at the top.

Now for a final thing. Since the texture cached are not rendered very often I can do quite a lot of heavy stuff in them. And one thing I was sure we needed was decals. What I did was simply to render a lot of quads to the textures which are blended with the existing texture. This can be used to add all sorts of extra detail to map and almost require no extra power. Here is an example:


I am pretty happy with these features for now although there are some stuff to add. One thing I need to do is some kind of real-time conversion to DXT texture for the caches. This would save quite a lot of memory (4 - 8 times less would be used by terrain) and this would also speed up rendering. Another thing I want to investigate is to add shadows, SSAO and other effects when rendering each cache texture. Added to this are also some bad visual popping when levels are changed (this only happens when zooming out a steep angle though) that I probably need to fix later on.

Now my next task will be to add generated undergrowth! So expect to see some swaying grass in the next tech feature!