Physics and Heightmaps

When I thought that all problems with heightmaps was over, I stumbled upon something sort of tricky recently. The only thing I had left for heightmaps was to add physics to them. This seemed easy to do as it was basically just a matter of sending the raw heightmap data to the physics engine (newton game dynamics) However just as I had done this I realized that this was not enough: the terrain could have many different physical properties at different places (a spot with dirt, one with rock, etc).

The thing is that in physics simulations you give a material per shape, each material having certain properties (friction, etc) and special effects (sounds, etc). The heightmap is counted as a single shape, and thus it only has a single physics material. This was something I had totally forgotten. Luckily, the physics engine supports the assigning of special properties to each point in the heightmap. Once I found the proper info, it was pretty simple to add this (see here).

Now it was just a matter of adding extra material values to the heightmap (basically just an array of single integers, the id of the physics material at each point). My initial idea was that this could be "painted" on as an extra step, and to be sure I asked Jens what he thought about it. His reaction was that this would be way too much work and wondered if it could not be auto-generated instead. We already had a physics material assigned to each render material, so the basic info was easily accessible.

However, when I started to thinking about this, I found the actual auto-generation increasingly tricky. How should we determine which of the many blended materials to set the physics properties (blending was not possible)? Also, how do I get this information, considering that the blend textures can saved as compressed textures, into a CPU buffer?

The way we chose to solve the material picking was that the top visible (meaning over a certain limit opacity) blend material always sets the physics material. This allows map creators to set priority on materials in terms of physics, by simply placing them at different places among all blend materials. For example, if a material like gravel should also have its effects shown no matter what it is blended with, then it should be placed high up in the list. While currently untested this seem pretty nice and can also be tweaked a bit (like having something else determining priority).

The generation of this data was made by rendering the blend textures to an off-screen target and then grabbing the data into normal memory. What this meant is that the GPU would decompress any packed textures for us. This also solved some other problems, like the need to resize the texture according to heightmap resolution. Once the data is grabbed from the GPU it is just a matter to loop through it, check values and write to the final buffer.

Problem was finally solved and physics properties auto-generated!


With this little post I hope to show that there often is more to a problem than what is visible at first. Also, this shows another advantage of using normal texture splatting (more info here), instead of megatextures or similar. With the auto-generation of physics, it is much easier to create and update the terrain, something extremely important when you are a small team like us.

Would be very interesting what other techniques people use (or known of) for setting up physics properties on terrain!

Tech Feature: Undergrowth

Introduction
After a little break with updates on the rendering system, holidays and super secret stuff, I could finally get back to terrain rendering this week. This meant work on the final big part of the terrain system: Undergrowth. This is basically grass and any kind of small vegetation close to the ground.

As always, I started out doing a ton of research on the subject to at least have a chance of making proper decisions at the start. The problem with undergrowth/grass is that while I could find a lot of resources, most were quite specific, describing techniques that only worked in special cases. This is quite common when doing technical stuff for games; while there are a lot of nice information, only a very small part is usable in an actual game. This is especially true when dealing with any larger system (like terrain) and not just some localized special effect. In these cases reports from other developers are by far best, and writing these blog posts is partly a way to pay back what I have learned from other people's work.

Now on with the tech stuff!


Plant Placement Data
The first problem I was faced with was how to define where the undergrowth should be. In all of the resources I found, there was some kind of density texture used (meaning a 2D image where each pixel defines the amount of plants at that point). I did not like this idea very much though, mainly because I would be forced to have lots of textures, one for each undergrowth type, or to not allow overlapping plants (meaning the same area on the map would not be able to contain two different types of undergrowth). There are ways past this (e.g. the FrostBite engine uses sort of texture atlases), but then making it work inside the editor would be a pain, most likely demanding pre-processing and a special editor renderer. I had to do something else.

What I settled on was to use area primitives, simple geometrical shapes that defined where the undergrowth would be. The way this works is that each primitive define a 2D area were plants should be placed. It then also contains variables such as density, allowing one to place thick grass at one place, and a sparser area elsewhere.

I ended up implemented circle and convex polygons primitives for this, which during tests seem to work just fine.


Generating the Plants
The next problem was how generate the actual geometry. My first idea was to simply draw the grass for each area, but there were some problems with this. One major was that it would not look good with overlapping areas. If areas of the same density overlapped, the cross section would have twice the density of the combined area. This did not seem right to me. Also, it was problematic to get a nice distribution only using areas and I was unsure how to save the data.

Once again, the report on the FrostBite engine gave me an idea on how to approach this. They way they did this was to fill a grid a with probability values. For each grid point a random number between 0 and 1 is generated and then compared to to the one saved in the grid. If the generated number is lower than the saved, a plant is generated at that point, else not. Each plant is then offset by random amount, creating a nice uniform but random distribution of the plants!

This system fit perfect with the undergrowth areas and simplified it too. Using this approach, an undergrowth area does not need to worry about generating the actual plants, but only to generate numbers on the grid.

The final version works like this:

There is an undergrowth material for each type of plant that is used on a level. This material specifies the max density of each plant and thus determines how the grid should look. A material with a high density will have a grid with many points and one with a low density will have few grid points. Each point (not all of course, some culling is used) on the grid is checked against a area primitive and a value is calculated. This is then repeated for each area, adding contributions from all areas that cover the same grid point.

This solves the problem of overlapping areas, as the density can never become larger than max defined by the grid. It allows makes it possible to have negative areas, that reduce the amount of undergrowth in a certain place. This way, the two simple area primitives I have implemented can be used for just about any kind of undergrowth layout.


Cache system
Now it is time to discuss how to generate the actual plants. A way to do this is to just generate the geometry for the entire map, but that would take up way too much memory and be quite slow. Instead, I use a cache system that only generate grass close to the camera (this is also how FrostBite does it).

The engine divides the entire terrain into a grid of quads, and then generates cache data for each quad that is close enough to the camera. For each quad, it is checked what areas intersect with it, and layers are made for each undergrowth material that it contain. Then for each layer, plants are generated based on the method described above. The undergrowth material also contains texture and model data as well as a bunch of other properties. For example, the size can be randomized and different parts of the texture used, all to add some variety to the patch of undergrowth. Finally plant is also offset in height according to the heightmap.

This cache generation took quite some work to get good enough. I had problems with the game stuttering as you traveled through a level, and had to do various tricks to make it faster. I also made sure that no more than one patch is generated at each frame (unless the camera is teleported or similar).


Rendering
Once the cache system was in place, rendering the plants were not that much of a problem. Each generated patch comes with the grass in world coordinates, so it is as simple as it can get. The only fancy stuff happening is that grass in the distance is dissolved. This means that the grass does not end with a sharp border, but smoothly fades out.


In the above image you can see how the grass dissolves at distance. Here it looks pretty crappy, but with proper art, it is meant that grass and ground texture should match, thus making the transition pretty much unnoticeable.

Another thing worth mentioning, is that the normal for each grass model is the same as the ground. This gives a nice look to many plants, but an individual plant gets quite crappy shading. Undergrowth is meant to be small and not seen close-up though, so I think this should work out fine. Also, when making grass earlier (during development Amnesia), normal normals (ha...) were used and the result was quite bad (sharp shading, etc).


Animation
Static grass is boring, so of course some kind of animation is needed. What I wanted was two different kinds of animation: A global wind animation (unique for each material) and also local animation due to events in a limited area (someone walking through grass, wind from a helicopter, etc).

My first idea was to do all of these on the cpu, meaning that I would need to resend all the geometry to the graphics card each frame. This would allow me to use all kinds of fanciness for animation (like my dear noise and fractals) and would easily allow for lots of local disturbances.

However, I did some thinking and decided that this would be a bad idea. Not only does the sending of data to the graphics card take up time, but there might be some pretty heavy calculations needed (like rotating normals) for a lot plants, so the cpu burden would be very heavy. Instead I chose to do everything on the GPU.

Implementing the global wind animation was quite simple; i was just a matter of sending a few new variables to the grass shader. But it was a bit harder to come up with the actual algorithm. Perhaps I did not look hard enough, but I could find very little help on this area, so I had to do a lot of experimenting instead. The idea was to get something that was fast (i.e. no stuff like Perlin noise allowed) and yet have a natural random feel to it. What I ended up with was this:

add_x = vec3(7.0, 3.0, 1.0) * VertexPos.z * wind_freq + vec3(13.0, 17.0, 103.0);
offset.x = dot( vec3(sin(fT*1.13 + add_x.x), sin(fT*1.17 + add_x.y), sin(fT + add_x.y)), vec3(0.125, 0.25, 1.0) );

add_y = vec3(7.0, 3.0, 1.0) * (VertexPos..x + vOffset.x) * wind_freq + vec3(103.0, 13.0, 113.0);;
offset.y = dot( vec3(sin(fT*1.13 + add_y.x), sin(fT*1.17 + add_y.y), sin(fT + add_y.z)), vec3(0.125, 0.25, 1.0) );

This is basically a couple of fractually nested sin curves (fbm basically) that take the current vertex position as input. The important thing to note is the prime numbers such as vec3(7.0, 3.0, 1.0) without these the cycles of the sin curves overlap and the end result is a very cyclic, boring and unnatural look.

The offset generated is then applied differently depending on the height of the plant. There will be a lot of swaying at the top and none at the bottom. To do this the base y-coordinate of the plant is saved in a secondary texture coordinate and then looked up in the shader.

Now finally, the local animation. To do this entities called ForceFields are used. (Thanks Luis for the name suggestion! It made doing the boring parts so much more fun to make.) These are entities that come with a radius and a force value, and is meant to create effects on the graphics that they touch. Right now only grass is affected, but later on effects on ropes, cloth, larger plants , etc are meant to be added.

These effect of these are applied in the shader and currently I support a maximum of four ForceFields per cache patch. In the shader I either do none, a single entity or four at once. This means that if three entities affect a patch, I still render the outcome of four, but fill the last one's data with dummy (null) values. Using four is actually almost as fast as using a single. Because of how GPUs work, I can do a lot of work for all four entities in the same amount of instructions as for a single. This greatly cut down the amount of work that is needed.

Again, just like with the global wind, it was hard work to come up with a good algorithm for this. My first idea was to simply push each plant away from the center of the force field, but this looked really crappy. I then tried to add some randomness and animation to this in order to make it nicer. As inspiration, I looked at Titan Quest, which has a very nice effect when you walk through grass. After almost a days work the final algorithm look something like this:

fForce = 1 - distance(vtx_pos, force_field_pos)/force_field_radius

fAngle = T + rand_seed*6.28;
fForce *= sin(force_field_t + fAngle);

vDir = vec2(sin(fAngle), cos(fAngle));
vOffset.xz += vDir * fForce;

Rand seed is variable that is saved in the secondary texture coordinate and is generated for each plant. This helps gives more random and natural feel to it.

Here is how it all looks in action:

Note: Make sure to check in HD!

And in case you are wonder all of this is ugly, made in 10 seconds, graphics.


End notes
Now that undergrowth is finally done, it means that all basic terrain features are implemented! In case you have missed out on earlier post here is a summary:

Terrain Geometry
Fractals and Noise
Terrain Texturing

I hope this has been of use and/or interest to somebody! :)

Next up for me is some final terrain stuff (basically just some clean-up) and then I will move on to more gameplay related stuff. More on that later though...

Why not release a game on Steam that has been ported to Mac?

As we have released all of our games for Windows, Mac and Linux and because we also release our games on Steam, this will be a quick reflection over the lack of games available for Mac that are not on Steam.

Looking at the Steam forums you can find a thread or two every now and then that brings up the topic "why are there many well known games, that are ported to Mac, but are not on Steam??".

The reason for this can be many: Perhaps there is a contractual limit or perhaps the company that did the Mac port have their own online store and only wants to sell the game in that store.

There has also been a mention here and there about SteamPlay, the feature on Steam that gives you a game for all platforms, even if you only bought it for Windows to begin with. This means that if you have a Mac as well, you get the game for Mac for free on Steam. Or the other way around of course. This might be viewed as a negative thing, because as the company porting the game, you have a lot of potential customers that will simply get your game for free. This makes SteamPlay also a possible cause not to release the game on Steam.

Bringing me to the point of this short blog post: As a long time Mac user, gamer and as someone that worked on quite a few Mac games over the years, I feel the urge to post a little "Steam is good, SteamPlay is good and if nothing stops you from releasing the game, do it."-suggestion.

Looking at our own sales, we have about 7-8% coming from Mac users. Last I heard, the Mac portion of the PC market was less than 7-8%! We have had this sale share since the very first month our games were released on Steam for Mac, so despite all the potential "lost sales" due to SteamPlay, we have sold as many copies as the Mac market should be able to support.

Let's take Penumbra Collection as an example; when it was released on Steam for Mac, the Mac sales accounted for 20% of the total sales of Penumbra Collection that month. This for a game that is to be considered old and have been available for the Mac elsewhere for as long (almost) as the PC version has been out.

If you are a Mac porting company, take a moment to think about it and if nothing stops you from releasing it on Steam, why not maximize the potential customer base?



Psst. Of course there are other originally Windows oriented stores that have support for the Mac, such as Gamer's Gate and Direct2Drive. Not to forget the newly released (long overdue) App Store by Apple themselves.

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!