Monday, January 31, 2011

SEGA TOYLET




the Sega Toylet! A new game system attached to urinals in Japan that you play by literally peeing into it and having the game measure your stream!It basically consists of a screen on a wall and a pressure sensor positioned inside a public urinal below it. If you haven’t guessed how it goes yet, the games are based on the strength of your stream.


The games are currently being tested in four locations in Tokyo, with each Toylet offering four games to choose from:


There’s the “Graffiti Eraser”: The stronger the stream, the more cyberwalls you can clean up.


Or try “Milk From Nose.” This is a multiplayer game. Your stream is measured against those of previous users and translated into milk blown from a character’s nose. The strongest nose-blowers pushes the opponent out of a ring, and we have a winner. Your opponent need not be present to play.


Another game equates stream strength with a gust of wind blowing the dress off a girl.


The concept might sound silly (not to mention sexist, since it’s obviously designed to go into a men’s room), but it sure beats staring at a blank wall at your local watering hole. The screens can also be used to display digital ads when no one’s, uh, playing. The platform is still in development, so there’s no word when we’ll start to see local pee tournaments in Japan yet. 


Once again, the Japanese have beat us in the war of toilet evolution. 

Thoughts on: Red Dead Redemption



Unlike the rest of the world, I hated red dead redemption; the game is basically GTA on a horse, only driving a horse is much more difficult than a car. 

Perhaps, i'm being a bit biased here, RDR no doubt is a polished work of a veteran team. The obvious repetitive use of their previous successes and trying to mask it in an unappealing - in my opinion - wild west theme is kind of insulting. They could've easily called this game GTA:Wild West and no one would've though twice about the name. 

I don't know if it's just me, but I think the wild west theme belongs to the 40's; we've grown tired of it, it's not cool to be a cowboy, it's not cool to roam between cacti and the accent is definitely not attractive. 


The game starts out by giving you no ties with the character whatsoever, they throw you off in the middle of no where and then start giving you pitty tasks to teach you the controls of the game. Some would argue that the reason the character doesn't have a back story at the beginning of the game is to give the player the impression that they control the outcome of the character, which is somewhat true, how the player rarely have control over scenarios that might get you shot like the first bit of the game. 


The game could've been much more enjoyable on a PC, this is clearly not a console game from the control scheme, moving the two analogue sticks while you're riding is pain as it is, then you have to aim with a trigger button, shoot with another and adjust aim with the right analogue stick. I believe these mechanics would've worked a lot better with a keyboard and a mouse. 


Not to mention the painful horse back riding experience; carefully tapping the x button on a high speed chase while desperately trying to control the crazed camera is one thing, but shooting while doing that is something else. 
 
The game would definitely have it's fans; Rockstar games fans probably get their socks off playing this; but this isn't my cup of tea ... definitely hoping that they would try a much more original effort with LA Noir; looking forward for that one. 

Tuesday, January 25, 2011

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!

Monday, January 24, 2011

Christmas Holidays & New Year


Well another Christmas has come and gone, coupled with the start to another new
year.

Christmas

Christmas generally starts to feel less and less special as you grow older, but this year's Christmas and the surrounding days still felt very special to me.

This was mainly due to two main reasons:

The first reason was that I spent the majority of the time with my family. To me the Christmas holiday doesn't really begin until the tree is put up as a family, with classic Christmas music playing in the background. (The Best Christmas Album In the World Ever! Which contains classic songs like 'Happy Xmas', 'I wish it could be Christmas Everyday', 'I believe in father Christmas', A Spaceman Came Travelling', and so on). Unfortunately since we've had the tree many years, some of the lights have begun to stop working. The overall effect of the tree, however, is still very impressive.


Christmas itself was a very festive occasion, all of the relatives came round, to eat and drink and be merry. We also played some new board games, beginning with Who Wants to be a Millionaire, and Harry Potter Scene It.

Friends

The second reason was that I met up with two of my good friends Mike and Ste, after not seeing them for months due to each of us going to different universities in different parts of England.

The three of us went to Cineworld to see the new Tron film, Tron: Legacy. I found the film to be enjoyable, although in hindsight I wish I'd have watched the original Tron film before seeing the new sequel. That would have given me a different perspective on the movie. I still knew of Tron, mainly from the popular Lightcycle game, which has been re-made in many forms.
After the movie we returned to my house to relax and play some video games. We played our traditional matches of Super Smash Bros Brawl, with me reprising my usual role as Kirby, Mike as Ganondorf, and Ste as Marth or Pit.

After a dozen or more matches we switched to playing Halo Reach, the newest game in the Halo series. Reach is a prequel to the rest of the series, and adds many new multiplayer features.

To begin with Me, Mike and Ste played some online games of Rumble Pit (a selection of free for all gamemodes). Mike had the advantage since he'd played Reach at University with his flatmates. It was the first time me or Ste had played Reach, and we did quite badly until we got used to the differences in Reach compared to the other Halo games. The most obvious difference is the addition of classes called, 'loadouts' in most game modes. Each 'loadout' comes with pre-defined weapons and a single special ability.

These abilities range from; sprinting, active camouflage, jetpacks, a radar jammer and temporary invincibility. Me and Ste really enjoyed trying out the jetpack. Flying around the map was an excellent way to traverse the map, and get the jump literally, on ground dwelling enemies. Unfortunately the jetpack is relatively slow, so the player flying around in the sky is a massive target, and is often picked off from afar for an easy kill.

After a few matches we switched to the new and improved Forge map creation tool, now named Forgeworld.

Forgeworld

Forgeworld allows the player to create custom multiplayer maps by selecting and placing developer created objects onto the game map.

The variety of the objects is truly staggering, the player has near limitless possibilities with the wide range of pieces Forgeworld provides.

To begin with me, Mike and Ste began by exploring the default blank map itself. We were all very surprised by the absolutely massive size of the map itself. Next we spawned in some weapons and vehicles and had a deathmatch of sorts, with Ste taking on the role of making a small base area for us to fight in. Soon the base began to take a different shape, a giant ramp leading to the heavens, an excellent sniping position, to prey on those players, far, far below.

Without me or Mike really realising it, Ste continued developing what soon turned into a racetrack, although not exactly the typical image of a racetrack. Suspended way, way up in the air, with no sides or barriers, it was a very perilous racecourse. Falling off meant restarting the entire course, which became an issue as the course continued to grow.

I hope to record a video of the finished racetrack using Reach's video editing features to be posted in a future blog post. (After the new year we made a second and probably better designed racetrack, so I'll try and post a video of that also).

New Year

I rang in the new year in a quiet way, with my family. We watched Toy Story 3, which I found to be a very entertaining, yet emotional movie, which definitely tugged on my heartstrings.

I don't want to spoil the plot of the movie, so I'll just heartily recommend that you buy the DVD and watch it if you haven't already.

Thanks for reading. :)

P.S. After writing this, I realise how far behind I've managed to fall with my blog posting. I also remembered how much I love the Christmas holiday, and how it's probably my favourite time of year, hence why I got so incredibly sidetracked. Well I plan to update my blog regularly again from now on.

Sunday, January 23, 2011

Video Game Museum




A new video game museum opening in Berlin today claims over 300 exhibits and an archive of over 14,000 games tracing the history of the nascent medium.


The Computerspielemuseum is the latest public effort from Andreas Lange, a former German game rater who quickly outgrew the space that housed his first public game collection, opened in 1997, according to a Spiegel report.


Lange's collection reopens today in its new East Berlin location thanks in part to the patronage of German-American Ralph Baer, creator of the Magnavox Odyssey and widely acknowledged as one of the fathers of the game industry.


Other funders for the museum include the Germany Lottery Foundation and the European Regional Development Fund, according to the museum's web site.


Exhibits at the new museum include a Wall of Game Milestones, displaying dozens of titles that moved the industry forward in some way, and others that examine connections between gaming and real world artists, thinkers and technology trends.




Rochester, New York's Strong Museum of Play opened the National Center for the History of Electronic Play in early 2009, housing a collection of over 15,000 games.


And in 2008, the UK launched its first national video game archive as part of Bradford's National Media Museum.

Thursday, January 20, 2011

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

Wednesday, January 12, 2011

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.

Friday, January 7, 2011

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!

Tuesday, January 4, 2011

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!