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!

Reading GM suggestions...

So, would you believe it... I found some free time. Probably because everyone at home is ill, or sleeping but time none the less. So I decided to read through the current GM suggestions listand there's some interesting stuff on there. I suspect much of it wil have to wait for the rewrite, but we can still do a fair bit during the many updates to 8.x we hope to do in the future.

Types... Not for 8.x (or not fully that's for sure)

Values
we'd like to get ints/bools etc. in there, but not sure when. Enums are also a must at some point - I hate having to define constants in the menu system. Unicode is a long term goal for Game Maker, but I think it may well be too painful for 8.x.

Collections.
Actually, I don't really like any of the collections. I think it's one of the few areas where you really NEED "class" based operations. So instead of giving you a handle to something, you actually get the object back. This will be a hotly debated topic at YoYo, that's for sure. We don't want to break everyone's source, but at some point, you have to make a change. This may mean keeping the old ones and giving some new ones, then removing the older stuff in a later version. But at some point, I think the old "handle" system should go. Again.... will be a huge debate internally on this, and we'll then need to open that debate up to external devs as well.

Scope.
Yes. Need Scope. I'm not a huge fan of C++ style namespaces, but they work well on C#. That said... they aren't vital. So not sure, another one to discuss. Multiple inheritance...Mmmm...prob not, but who knows. def not for 8.x. As to uninitialised variables not being 0, well.... that's needed for beginners, there's no doubt. We are coming to the conclusion that there may be a new level though - Pro (or something), where things get really interesting! Time will tell on that one.


Scripts.
Default args would be better. I suspect we may well start allowing proper script definitions, then all this would be possible. But it would also allow us to keep the current method for beginners. But I prefer proper definitions as it means you get proper error checking when calling functions as it knows the number of args it needs. We can work it out I guess simply by checking how many args it uses IN the script, but it's cleaner and less error prone to define it. I don't think you need pass multiples args back. Again, if you had proper defined functions you could specify "outs", but other than that, you can currently just use globals and set them. It does the same thing.

Flow control - not for 8.x
Multi level break? Don't be silly.

Editor.
non-modal editors. Sooooooooooooooooooooo YES! I hate the horrible modal dialogs! Hate them!! Hate them!! Hate them!! Hate them!! Depending on time, This might get in to 8.1, however we need to discuss with the community to see if there's any valid reasons to keep them. Mark thinks there is... but couldn't remember, so we'll open it up for discussion soon.
Better window management. Yes. def. Tabs would be nice.
Multiple selection/editing of tree resources. Yes.
Dragging resources between projects. This would be nice... but no idea when.
Group duplication. Another nice but "when we have time..." one.
Portable Installation.. We'd have to look into that due to piracy issues.
Escape closes... yeah.

Debugging
Whole debugger needs redoing, but that'll probably be 9.x or so. You need the new scripting engine for this. Once thats in, then pretty much all this is possible, and will be done. Not sure about dynamic recompiling though. It's nice, but might be tricky... Probably between game "ticks" is the simplest way.

Code
I've said before. The code editor is reasonably good, but just needs a little update to make it very good. Most of these should be done at some point, with luck during 8.x life cycle. I'd remove the external editor, but more on this later....

Objects
Bypassing D&D - yes.
Inheritance graph. I guess. I never use them, but on others games it might have been handy to see, and I know others use them.
Show GML equivalent of D&D. We hope to go one better than that...
undo.. yeah... need a better undo system over all. But that's probably a 9.x thing.


Rooms
Instance stuff. Yes. The idea at some point in 8.x is to move to a more select and change system, rather than the current kinda mushed one. We will start making everything brushes, and that will let us do all manner of things. Group selection/editing, grabbing chunks from the map, painting with them and all the rest. You should also be able to set some instance data directly from the editor. rotation, scale, colour etc...
Zooming. Oh HELL yes. Will be there in 8.1, in fact... it's almost complete. We might post a video soon to show it working. It's a massive MASSIVE improvement.
Layers/tiles. Yes. In fact, I want to completely change the tiling/instance system to be more "playfield" based. I find this is much less error prone, and will let the graphics engine draw everything much, MUCH faster. Currently tiles are really just very cheap instances, and everything is drawn pretty slowly. But if you do a proper tile/layer system, then you can blast whole layers very quicly indeed. Rendering would speed up massively. Not sure if this will make it into 8.x as again, we will need to take care not to break everything.
Grid offset/colour - sure.

Sprite.
onion skinning. Yes. Might be 9.x
Selection/manipulation... not sure.
Curves. Probably.
default precise checking. If this is the pixel checking for game collision, then no. This is really REALLY slow... so you should be forced to think about it. If its something to do with the editor, then not sure. Preload. I think all preload stuff is going.

Triggers.
Not used them yet, so won't comment.

Files.
split gmks... More on this later....
Remove redundant compression. The file format will be changing. More on this later.
conditional compilation. Yes. Would be nice. Not sure when.

Editors
Sound editor. Perhaps...
Particle/effect. Yes, at some point. Preferably right inside the room editor. Prob a 9.x thing, but you never know...

Extensions
DLL access to in game resources. Yes, would be nice. But tricky. At the very least getting texture handles and a pointer to variable "values" would be good, but I don't know how possible this is yet.
IDE mods. Not for 8.x
extensions in general will be changed in 9.x I think. We want to do a lot more with them. 8.x ones are pretty limited.

Drawing.
Animated tiles - yes.
isometric tilesets. Not high on the list. (I presume you all mean free assets here)
alpha in colour - oh hell yes! Full 32bit colour values rather than alpha, and colour would save LOADS of effort in the engine.
draw_*_tiled_region... not sure what this means. Draw a sprite./background tiled? yes, sure.
More vector support. more prims. bigger better drawing in general... yep
Layers - I'm a BIG fan of layers...
Correct normals for 3D solids??? They aren't correct? (spheres, cubes etc?)
More 3D formats - 9.x (at some point)


bloody hell this list goes on some!


Collision
Not used the more complex collision very much.. so won't comment. It's pretty slow though, so needs an overhaul.

Instances - sure. Though don't hold your breath for Lambda stuff.

Sound
Sound instance. Yes
formats - yes.
seek - probably
length - probably.
modification - probably
mute - yes. Master volume should mute media player music too really.

Rooms - yes and yes.
I'd also like to add scissor regions. So you can hardware clip to a rectangle.

Networking.
Total rewrite required.

Reflection.
Yes. But not sure when.... 9.x prob

Maths.
Well, better maths in general.


Files
ini files. INI files aren't too bad. But need some kind of instance or handle so you can have multiples open at once. You also need to be able to flush an ini file, to get rid of old stuff. Basically, a refresh would be nice. xml etc would also be good.
read whole file - yes. soon I hope.
game save/load. This whole thing needs redone. But it could throw an event.

Input
yes. Allow multiple mouse clicks at once as well (allows for multi-touch devices)
Joystick - sure.


Timing.
Mmm...
Naming alarms would be nice. I don't like just having alarm[3] either.
Hires timer would be great. It's available, so we should provide it.

Interface.
Message boxes. This is an on going debate. I think we should make all message boxes the OS native ones. This allows for Macs to look like Macs, and windows to look like Windows. But there is a backward comparability issue, in that the code allows your to change the look/feel. I think if you want to do that... do your own dialogues. SO not sure if it'll be in 8.x.
Not sure about the rest.....

Runner.
We will be changing the runner format, and making it harder to decompile. Will be done in 8.x time-frame.
Bytecode generation at build time. Yes. Not sure when. Might need the c++ runner for that.
remove debugging in release builds - would also be nice.
Unused resources. Yes, however... since you can refer to resources as strings, and then later make them into actual object references, then it becomes hard to actually know if someone has used an object. However, we hope to make this an option so if you don't do this, then we can strip out all the crap. We've seen sketches and photos in a games .exe as the developer as used it as a project workspace, but the final program has gotten it all as well. This should be cut in some way.



Wow. Okay, that was much longer than I though it was going to be..... Now just because I've said yes doesn't mean it'll happen tomorrow. And just because I've said no, doesn't mean it'll never happen. ALL these things are still up in the air, and under discussion. We're very aware that anything we change will have a massive impact on the community and developers work flow, so we want to be very careful as to how we proceed. I think I'll probably start some GMC topics to open discussion with the community about some of the changes, and we will speak directly to the devs we've been working with before anything major is affected. In general, additions will probably go right in, while changes may take some time to validate the need, and the effect on the community.

I've mentioned before just how excited I am to start working on Game Maker itself. It's a fabulous product, with a great community, and huge scope for change and improvement. I think we can drive Game Maker to be the tool to use for indi devs, but it'll take time. The real improvements will only come with the rewrite, but we should be able to start the process in this iteration.

In the next few weeks, you'll hear whats going to be in our first update, although you all know about the room editor zoom. We hope to do small iterations, more often. So with luck, for 8.x there won't be any more massive waits, you'll get updates much more often, and new features will slowly start to appear.

EDIT: Oh yeah... The documentation needs an overhaul as well. It should be more like DirectX with actual examples of function use, not just listing them - that's no use to anyone! However, this is a massive task. But one day, we will.

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...

A new direction in gaming...

I've been clearing out some of my folders and I discovered this, it's an article I wrote, way back in mid-2004 for MCV and it talks about appealing to the mass market, not hard core gamers. Re-reading it, I feel that very little has changed really. Realtime Worlds and APB epitomised this problem - to their cost, and while individual developers have taken some of this to heart via the new mobile market, consoles and PC games are still very much stuck in the old way of thinking. Sure, EA and other companies have just started to do the same in the mobile space, but it wasn't through choice, it was forced on them. Anyway, here it is. Perhaps I should do another, and try to predict what will happen in another 5-10 years! :)


A New Direction In Gaming

In today’s mass market climate, the idea behind making games is simple, spend as little as possible to make as much as possible. To do this, you need to get the highest percentage of players to development pound as is possible. For example, if you can get 100 mass market players for 1% spent on a project compared to 5-10 hardcore gamers for the same 1%, then you do what you need to get as many mass market punters as you can.

This makes sense, a lot of sense; so you have to wonder why so very few developers/publishers do it. Sure more and more players are being welcomed into gaming culture, but where’s the development cost going?

First, you have to decided how long an average project is, and for this discussion we’ll say two years. For many Large AAA games, this is conservative, since they can span 3 or more years (Half life 2 and Doom3 being 4 to 5!).

If we also assume that the cost is spread evenly (which isn’t usually what happens – costs usually go up towards the end), what portion of your development do gamers play? Well the mass market gamer will buy a game, and play only a small section of it before either becoming bored with it, or simply not possessing the skills needed to reach higher levels. Problem is, with games being so expensive, they won’t then rush out and buy another one, they’ll simply play this on off and on, and not getting much further, and getting more and more frustrated.
The Hardcore gamer will play the game from start to finish, and take however long is required to do so. This means he won’t buy a new game until he’s finished the current one. The developer’s problem is that they make content for the hardcore gamer, making games bigger and bigger to satisfy these people (and I include magazine reviewers in this as well since they play games for a living).

This pushes up team sizes, costs and risk. The problem is, around ⅔ of this is wasted effort. The casual gamer just doesn’t get that far, so the return on your development pound drops after the first few levels. Ironically, the first few levels are easiest to make, the most polished and usually finished inside a year to 18 months, and would probably reduce the development cost by at least half. So, what if games were ⅓ the size? What if they were ⅓ the price? This would place games squarely in the impulse buy bracket (around the £15-£20 mark), and as a result, people would probably buy more games. And even if they did finish the game, a new one isn’t 4 years off. Updates could extend the game easily with more levels; in fact the exact same levels that were going to be in the game in the first place, only now, the casual gamer will now want to buy and play them, pushing up the return on the development pound.

Teams should not only find that the dreaded overtime is now reduced giving them a social life, but that the next set of games are much easier to do. With a firm codebase to work from, extra features and content can be added along with new levels in around 6 to 8 months making new releases quicker to come out, again increasing the value of the development buck.

So what’s the downside? Reviewers will no doubt complain that games are smaller, and hardcore gamers moan that they finished it already and will then promptly rush out and buy more. However since the price is now at least half what it was, they can afford to.

They may have to wait 6 months for the next set of levels and added features and so on. But what percentage of your paying public is this? No clear study has been done, but several reports suggest that only around 10-15% of the market can be attributed to the hardcore.

Given a choice of paying ⅓ to a ½, most of your paying public would opt for the smaller game, given that they’ll never finish it anyway. Putting it another way, if GTA was ⅓ the price and ⅓ the size (say only 1-2 stages), would you care? Especially if you knew another was only 5-6 months away?

There’s also a sound psychological reason as well. When a player finishes a game, he gets a thrill from seeing it through to the end, and this encourages him to do it again. Being beaten over and over isn’t very satisfying, and will eventually drive them off. Valve’s “Blue Shift” was a case in point. Small, beautifully done, and possible to finish for the masses; not to mention only costing around £15. Reviewers weren’t happy at the size of it, because they were used to these games and finished them easily, but most people who played it, loved it.

Anyone who’s played Farcry will know that it just doesn’t stop! It goes on and on. By the end of it (and I cheated to see the end, only to discover around 15 huge levels!), you’ve had your fill. And if another one came out, I doubt I’d buy it, as nice as it was.

Certain games will always take time (Doom, Unreal and HalfLife etc.) since they also make engines to sell, and others will appeal to everyone no matter what the size (Sony’s Eyetoy being one). But for the most part, there is simply too much content in games. Anyone that’s played Halflife 2 will notice fantastic levels that you fly past and only see once; pointless.

The point is, that even though there is a small market for very large games, all gamers expect games to be large because the magazines, online reviewers and even publishers assume that every game has to be, when its simply not the case. Games are one of the cheapest forms of entertainment around; DVD’s and Cinema give you only a few hours fun at most for a lot more cost. However reviews and the hardcore seem to expect games to last for months, but without the price tag. This needs to change.

While games will always represent value for money, the size and scale of them needs reducing. Around the days of Shenmue on the Dreamcast, there was talk of episodic game creation. While not quite the same thing, the concept is sound. Smaller games, more often.

The Sims have proven the bolt on market very successfully, and while the game is larger than normal, it keeps extending itself with each “small” release. This in turn keeps the interest up, and sales going. The last problem here, is convincing publishers that they need to sell these games cheaper. After all, the public's used to paying £30-£40 for a game, so why stop? We can make even more money? Publishers must also be made to realise that its in their who best interests to reduce the price, and get into that critical impulse buy bracket. Once there, sales should go through the
roof.

Not only would this aid in getting a better return on development costs, but it helps the development team do less overtime per game, reduces the risk to the publisher, and thereby allowing more variety in gaming. It also helps the public by reducing gaming costs and by allowing them to complete games, which in turn encourages them to play more, and hence buy more.

Its time to stop coding for the hardcore gamer, and go where the money is.

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!