The Problem of Repetition

Introduction

After having played some adventure and RPG games lately something struck me: repetition in games have almost the same problems as trial-and-error do. This is not really a shocking conclusion, since repeating things in a game is basically what you do when stuck in a sequence of trial and error. But since the repetition is not a direct consequence of being unable to progress, and that not all repetition is bad per se, I figured it was worth looking into a bit.

The Problem

Most of the time the problem arise when doing an action several times causes the same response. Mostly, this does not apply when doing things to dead objects, like shooting a bullet on a wall. We expect that if we shoot the same bullet at the same place twice, the same response occurs both times. However this is not always true. For instance, many games use randomized particle effects for sparks from the hitting bullet. In more complex system, like water splashes, this is even more common, and while it might not be directly noticeable if they repeat, it can unconsciously lead to the virtual world being seen as less "real" (what I really mean is sense of verisimilitude, but more on that later) . So even though it does not constitute a large problem, we do run into trouble even when repeating consequences for very simple interactions.

The problem becomes more jarring when the object of interaction is a supposed to be an intelligent agent. This is very common in RPGs and adventure games during dialog, where the same question generates the same answer regardless of how many times you ask it. Adventure games are generally a little bit better than RPGs and often have NPCs giving a summary instead of the exact same response and more frequently terminate threads of conversation. Even so, a big part of dialog in both types of games have actions being met by the exact same response no matter how many times they are repeated.

There are of course a reason why it is like this. The player might have forgotten some information and need to hear it again, forcing dialog to be repeated. Or there might be some compulsory puzzle that requires the player to trick or persuade a character, which forces the player to redo the same conversation if unsuccessful at the first attempt. I think these reasons expose two problems that narrative focused video games have: reliance of "info dumps" and puzzles as core activities. Info dumping is a form of exposition that one tries hard to avoid in other media, yet is very common in video games (often forming the core storytelling device). It is something that I think needs to be considered more (and I am well aware we have been using it too much in our own games). Puzzles is something I have talked about having negative effects before and this is yet another argument to why we should try and cut down our reliance on them.

Another very common form of repetition is that of having the same kind of gameplay scenario repeated several times throughout the game. Sometimes this can be a core part of the experience, but most of the time it is just a form of padding and an attempt to prolong the time it takes to finish the game. There are tons of examples of this and two that spring to mind are the vent sections of Dead Space 2 and the spirit capturing in Sword and Sworcery. I felt that both of these activities would have been a lot more interesting if not repeating so much. You quickly become very familiar with them and they eventually loose much of their first

There is a deeper reason why repetition is so common in videogames. Many games base their interactions on traditional games and software systems where reproducibility is a corner stone. You do not want to use a paint-tool and not know what expect when pressing a button, and the only way for you to get this knowledge is to is for consequences to repeat themselves. In traditional games, you need to have systems that a human player can keep track of, and thus the consequences of actions must be easy to comprehend. Videogames carry baggage from both of these directions, and thus it is not strange that video games contain a large share of repetition.

As you might have guess I think this sort of repetition can be quite bad for videogames that focus on story and narrative.

The Causes
As I said earlier, the repetition has pretty much the same issues as trial-and-error. Since they are both about doing the same thing over and over, this can feel pretty much self-evident and not worthy of much discussion. However, while trial-and-error elements are more easily pointed out and can be directly addressed, repetition is more subtle and not always as obvious. Many of issues with repetition are also commonly seen as limits of the medium (or at least our current technology) and thus not really addressed. I do think these problems can be overcome though, and a first step is to figure out what give rise to them.

- Mechanics gets apparent

By having something repeated over and over to players, they will quickly start to notice patterns and short after figure out the system below. What this leads to is that the player will no longer focus on what the system is trying to represent (eg. dialog with a person) but will instead see the mechanics that it is built from (eg. the abstract dialog tree). Repetition does not force this onto the player as trial-and-error do (where the player often is required to learn the system in order to continue). But since many of the things that are repeated constitute a big part of the experience, the problem piles up. Like I mentioned above the repetition can include entire scenes and the player might go through a section in a go (ie no trial-and-error). But then when a very similar sections is repeated throughout the game, the underlying mechanics become more and more visible. As an example I think the enemies in our own game Amnesia have this very problem. This problem is very subtle though as it only applies on longer play sessions and can thus more easily slip by.

There is another aspect to this, that makes the problem even more severe. Once you figure out the mechanics of a system it can damage events that you experienced when you did not have this understanding. For instance, if you feel like a conversation is really meaningful, and then later on find this same character reduced to mechanics, it will change the way you view your prior experience. It will be very hard to still feel the same sense of meaningfulness when looking back at the conversation. Your mental construct of an aspect of the game's world has now been reduced to a mechanic and when you later summarize the experience you have had, this can severely reduce any emotional attachment you might have had to earlier happenings. As this piles up, it will slowly degrade the experience and makes you less emotionally connected to the game's world.

- Decrease in Verisimilitude

What verisimilitude means is basically how real and truthful the fictional world feels. This does not mean how well it replicates the real world we live in, but how much a it feels like it represents an actual place. In most narrative media, giving a strong sense of verisimilitude is really important. As I said, this does not mean that everything should be "just like in real life", but instead follow the fictional world's internal logic somehow. What this means in games is that when encountering a virtual element, such as a character, we do not need for it to behave exactly like in real life, but simply to behave in such a way that it evokes feelings of verisimilitude.

This means that we can tolerate dialog selection and similar, while other things are instant deal breakers. I think one of these deal breakers is the repetition of a responses. If a character repeats the same sentence over and over, it is very hard to see them as nothing but a simplistic automaton. We can quite easily disregard our knowledge that there is not a sentient mind

shaping the responses, just like know something is not really happening in a movie. But when the information that the experience is feeding us (in this case the repeated voice response), the very thing that is supposed to support the view of an intelligent being goes straight against its purpose.

Not only dialog is affected by this but plenty of other aspects. For example, whenever you have to go about clicking on the same hot-spots over and over in an adventure game, it also significantly reduce the feeling of verisimilitude.

- Decrease in effectiveness

This point is almost identical with what happens in trial-and-error. Certain scenes and events simply does not do well when repeated. For some events it is simply that they are very emotional, and it will be hard to feel the same way once again. You will grow desensitized and less prone to reacting to it. Just compare a movie filled with gory sequences to one with a single visceral scene. The latter will pack a much harder punch. Other times it might be that the event or scene is set up like a magic trick - it only works when you are not expecting what will happen. Finally, it might simply be that the passage is too boring, sensory intense or similar that you cannot bare to take further viewings. Other media rely on things like these hard-to-repeat moments a lot, but since games are so prone to repetition, they are much harder to put in and/or to have the same emotional value.

The Cure

So how do we overcome these issues? I think there are a few things to keep in mind when designing that makes them a lot simpler to avoid:

• Not a approach the experience as a competition. The less goals we set up for the player the less likely we are to need to repeat things for the player or to make them repeat their own actions.
• Make sure that the story is understandable without the need of info dumps. If the player is required to have story related information repeated to them, then I would consider that bad narrative design. The story should emerge simply out of playing.
• Skip the notion that players need to learn a system. I think this is mainly historical baggage from how software works for more practical application, where mastery of the system is essential. Creation of narrative art does not have this requirement though, and I think we should instead make the player focus on the representations (graphics, sounds, etc) that the system provide.
• We must demand more of the player and give them more responsible. We must teach them them live in our virtual worlds instead of trying to beat our game systems. As most games reward players for combing the virtual world for goodies this is not the easiest of tasks though. Our goal must thus be to undo this and reward roleplaying instead.

These small rules does of course not solve everything and there is a lot of hard problem connected with this. For instance, conversational responses is an incredibly tricky problem and the same is true for narrative devices in games.

Still, I think just a little change in our thinking can take us a long way and simply recognizing the problem is a big step forward.

Thoughts on Heavy Rain

Introduction

It is very easy to talk bad about Heavy Rain. One can say it is just an interactive movie where you press buttons at certain key moments, in rare cases changing the outcome of the story. One can talk about the hole and cliche filled story and the weakly developed characters*. One can talk about this and other negative aspects of the game and I would fully agree. But if one only focuses on these areas, there is plenty of really interesting aspects that are missed.

Despite all these flaws I really enjoyed playing Heavy Rain. Sure, the quick-time-events (QTE:s) really got me worked up on more than one occasion and a lot of other issues bugged me, but on the whole it was quite an engaging experience. There are some truly tense and disturbing moments in the game that work great. For example the scene at the mall, while lame in many ways, managed to capture the protagonists sense of panic and that in an environment and setup I have never seen in a game before. The game also features great graphics, nice music and not too shabby acting (for most of the time anyway, and once you get used to the uncanny valley feel). The game also lets you be in situations that I have never seen outside of Interactive Fiction.

What really made the game interesting though was not the things that I liked, but the things that are slightly broke. Because of the way that QTE:s work, being a quite fragile system in terms of immersion, it sort of exposes your own usually hidden thought processes as you play the game. Also, the game's filmic nature and focus on a branching narrative makes it a virtual smorgasbord of game design theory to try out. This is what truly makes Heavy Rain worth playing.

Immersion as an essence

By far, the most important realization I got when playing Heavy Rain is how interaction is not mainly about giving the player interesting choices. When playing the game I never felt the need to make choices on the basis of seeing what would happen, instead I simply wanted the characters to act in certain ways in order to confirm to my expectations of how I thought they would (and should) be acting. What I think happens is that as we interact in a videogame, there is feedback loop between us sending input to the game and us getting information back from the game (in the form of visuals, audio, etc), which builds the basis of us feeling present inside the game's virtual world. The better this loop works, the more we feel as a part of the experience.

Heavy Rain is an excellent example of this process at work. When there is flow in the controls (which is usually in the scenes giving you direct character control, such as the early mall sequence), there is a very satisfying feeling of being one with the character. Then suddenly some weird QTE pops up and you either fail at completing it, or it simply does not give the result you expected, and once again you are pulled out of your sense of presence. The game is littered with moments like this, pulling you in and the throwing you back out. When Heavy Rain manages to sustain the belief of you having agency over the character, that is when the game is at it best. These are the occasions when there is a very strong loop of interaction going on and you are the most present inside the game's world. When this loop is broken, it does not matter what kind of interesting choices you might have at your disposal. The game immediately becomes less engaging the moment the loop of interaction breaks down.

In this light of thinking, QTE events make perfect sense. It is simply a rudimentary system for trying and sustain a feedback loop during various types of scenes. It is not about setting up a competition for the player, it is just a very blunt and unreliable system to sustain a sense of presence. I really doubt that QTE:s is the way to do narrative art in videogames, but it does gives us invaluable information on how to proceed.

What all this seem to indicate is that a videogame that wants to tell a story, should not use interaction to deliver a multitude of choice, but instead to reinforce the feedback loop of immersion. This might entail having choice, but the choices in themselves are not what is of the most importance, giving a very sharp focus on how to design the mechanics. It may actually be that the very future of making artful games with focus on narrative is to focus on this interactive loop of immersion. There is a lot more to discuss on this subjects and there are other things that also points in this direction. I am hoping to devout an entire post on that subject soon, so consider this a taste of things to come.

A final note: This "interaction as a means to create immersion" does not imply that the future of videogames are incredibly linear interactive cinema -far from it. In many cases a non-linear and open game world is essential in order to support the feedback loop.

The importance of determinism

In most games you have a pretty strong sense of what the protagonist will do when a button is pressed. Not so in Heavy Rain. Apart from direct movement and a few repeatable actions (like be able to shout your son's name in the mall scene), most of the time icons just pop up with vague hints on what the input will achieve. Sometimes you will learn what action might happen (such as that an up-arrow at a railing will mean that you will lean against it), but this takes a bit time and requires that a similar action has already been carried out.

In many cases this has a drastic reduction on the sense of presence. For one, it makes you unable for you to form plans. Simply by surveying an environment you cannot determine a course of actions (even if you know all trigger spots), and during action sequences it gets even worse as QTE:s may up at any moment in pretty much unguessable form. Making up plans is one of the basic corner stones of human intelligence, and possible the reason we developed a conscioussness, so not having the option of doing this is a hard blow against the sense of agency. Another reason it reduces immersion is that your character might not act in the way you intended. Before picking an action you almost always makes some kind of assessment of what will happen, but it is quite likely that this will be dead wrong. Thus the character your are supposed to feel a connection to, ends up performing an action that you did not intend. Of course, it is very hard to feel as a part oft he game's world when this happen.

This system stands in stark contrast with how Limbo works, where you are pretty much always certain of exactly what will happen. I think this is very much connection in the level of immersion Limbo manages to have throughout (unless you get stuck in trial and error of course), and how Heavy Rain stumbles through the entire experience. One should not be too hard on Heavy Rain though as the space of interactions that are possible to perform throughout the game by far outnumber those in Limbo. The real challenge for the future is to coming closer to multitude of actions in Heavy Rain, but still having the determinism of Limbo.

The understanding between Player and Videogame

Another big problem in Heavy Rain, which is related to the point above, is that the game sometime seem to work against you. It might seem obvious that this is a dealbreaker in terms of immersion and I have already discussed the problem of camera control in Dead Space Extraction. The issue can be a bit more subtle though and Heavy Rain serves as great example of this. For instance, in one scene I had made a plan of actions: to first bandage an unconscious person and then to poke around in his stuff. There really was nothing hindering me from doing so but instead the game removed my ability to interact directly after caring for the person. The game interpreted me wanting to help the guy as I also did not want to poke around, thinking that they two were mutually exclusive actions. Of course I thought otherwise and considered it no problem at all to do some poking afterward.

There are plenty of situations like this and it makes it quite clear that you should never move ahead on a bigger outcome from a choice without being certain that this is also what the player expects. I also see this as a problem of having major choices the player in a game that lack a high level simulation (like Fallout for example). Just the simple action of walking out a door can have many different meanings to a player, and one needs to be careful and make sure that most players have same idea of what it means. Once you throw branching paths into the pot, it gets a lot more complicated and clashes between player and game is much more likely to happen.

Emotional Simulation

An interesting aspect of Heavy Rain that I have not seen (at least not this directly) in any other game using QTE:s (or normal mechanics for that matter) is to trick the player into feeling certain emotions. The way it works in the game is that the player is forced to hold down a lot of buttons at the same time, while often also moving the stick around. This creates an uncomfortable and demanding way to hold the controller in, which is meant to simulate the way the onscreen character feels. While it might sound a little dodgy, it works quite well in many cases, especially in a scene containing self-mutilation.

The research behind this kind of response is actually very well established and designer Chris Pruett has hypothesized that the effect is probably a reason why many unforgiving horror games turn out to be extra scary (a design decision that comes with other problems though). The way it works is that we humans often do not know why we are feeling a certain way and unconsciously project it onto something else. For instance one experiment had people thinking that arousal due to their fear of heights was due physical attraction instead.

All is not good with this design in Heavy Rain though. Because the inputs you perform are not fluent (as it is prompted on a situational basis) and non-deterministic (as explained above) you are mostly very conscious of what you are doing with the controller. If the controls where more transparent (like in Limbo) you would be less conscious of your input, and any uncomfortable placement of the hand is much more likely to be projected into whatever the protagonist is doing. I think this can be very potent stuff if handled properly and let the player get immersed in experiences that would be hard to simulate in any other way.

Trial and error

Heavy Rain boasts that it does not have any game over screen, but it still manages to have is massive amounts of trial-and-error. This time the forceful repetition of events does not only occur in death threatening situations though. In Heavy Rain it often happens during extremely mundane actions like brushing your teeth and taking a shower. It is an extremely good example why this sort of design is so immersion destroying. From believing that you are playing an actual living character, the sudden requirement to repeat an event pulls you out from the experience directly. It is so obvious that you go from trying to become present in a virtual world to just trying and overcome a very mechanical task.

I think the biggest problem is that Heavy Rain is very sensitive in how you complete the QTE sequences. Let go of a button for a micro seconds and it results in an instant failure. When the game gets rid of so many other stigmas of old game design, it is sad to see it stuck in this one. I think the way it should have done it is to become a little bit more relaxed and to allow some more failures. Instead being competitive-like and very strict in the actions, it should instead check if the player tried enough to do something. As long as the players are playing along, I see no reason for punishing them. The game should have tried to keep the illusion of an interactive-feedback loop alive for as long as possible, instead of simply breaking it at the slightest incorrect input.

Some misc points

Now for some shorter stuff that I found interesting:

• When done right, the direct and free control method is by far the more immersive. However it also puts a lot of pressure on the character reacting in a proper way. Quite often, the character I was controlling ended up acting like a moron, walking into walls and the like, even if I really tried hard to control him properly. The constrained events do not suffer this problem, and have the characters act much more lifelike, but at the same time they do not have the same level of interaction required for deep sense of presence.
• Heavy Rain is at its best when simulating tightly space and time-wise bounded scenes. At these points it was much easier to give me a sense of having agency and to let me become one with the moment. The scenes self-mutilation, pushing through a crowd, escape from bench in cellar, etc are all great examples of this. Judging from what seemed to have worked best in Amnesia, I think a lot can be gained by taking this design further.
• The game is a great test bed for a game that has decisions with big ramifications, such as the death of main characters. My own conclusion from Heavy Rain is that all of these choices are probably unneeded and did not gain me much except the sense of missing out on the story. Interestingly, Heavy Rain feels quite different in this regard from a game like Fallout (with the, as mentioned, more higher level narrative simulation).
• Achievements (trophies on the ps3) really suck in story-centric game. Having gone through a scene and then getting a sort of grade, really removes the ability to make up your own mind of what just took place. It is quite similar to the "understanding between player and game" problem, as achievements has a high risk of going against the player's intentions (and does not really help gain anything).

End notes

As I think this post shows there are many reasons why Heavy Rain is a really interesting game to play. It does a lot of things that other videogames do not even dare to consider, and while it kind of fails on a lot of it, just attempting it is an important step on the way. If only more mainstream games were like this.

Also, after playing through Heavy Rain I have come to wish that there were more games like it. By that I do not mean more games with QTE:s (which I really hated much of the time) but games that allows the player to always progress and focus on a rich narrative experience. In most other games I either have to endure annoying puzzles or have to become an accomplish in a genocide. Given the high scores the game has gotten (from press and the public) I do not think I am alone in this. Please do not see this as an urge for people to copy Heavy Rain though, but instead to use the game it as a step towards something that truly makes use of the medium.

*Emily short has a really good essay on the story of Heavy Rain. Check it here.

Thoughts on Limbo

A while ago I played through Limbo for the first time. I thought it was quite an interesting experience for many reasons and been thinking for it on and off. Now that I have collected most of my thoughts on the game I thought it was time to write a little post about it.

Starting off, I thought the game had really nice visuals that really added to the mood. Small things, like the change in light level and tilt of the camera heightened the mood substantially. Another thing I really liked was the variety of activities and lack of puzzle repetition. Too many games just try and extend play time as long as possible, and it is nice to see games going in the other direction. All this has been said before though and is not what this post will be about. Instead I want to discuss some other things I realized when playing the game.

Limited Interaction
I think the biggest take-away from Limbo is how you do not have to give the player lots of actions in order to make a fresh and interesting experience. The basic actions in Limbo are move, jump, climb and grab. These are then used in a mixture of ways, constantly keeping the experience fresh by putting the variety in the world instead of the controller. This can be seen in other games like Shadow of the Colossus (but then to a lesser degree), and I think it really helps to heighten the player's feel of presence in the game. It only takes the player the first few minutes of the game to familiarize with the controls and the rest of the game can be spent on building up immersion, instead of constantly learning and remembering controls.

It is so often that games become about the mastery of the controls and I think that makes it so much harder to become one with the game's world. The faster the flow of interaction from player to game can become intuitive, the better. We do not want players to think of what buttons to press and sticks to pull. Instead we want players to directly express their wishes from mind to game, unaware of any intermediate hardware.

Puzzles and Limits
As I played Limbo I realized that most (if not all) interactions were directly added to the puzzles you have to solve. I felt that there could have been tons of extra elements to interact with in order to make the player feel more connected to the world.

But then I realized that the design of the game went against this. The puzzles in Limbo depend a lot on experimentation and thinking "out of the box". You have to try out every object in order to find a way to progress. If the game had had superfluous elements, then this would have made the experience so much harder. Players probably would have spent much time interacting with objects that were completely unrelated to the puzzle they were trying to solve, increasing the overall frustration and damaging the flow of progress.

This means that puzzles can be quite a hindrance if you want to make a living world. If the player's goal is to solve puzzles, then that forces you into make sure the rest of the experience supports this. And because of this having puzzles excludes a lot of things that could increase the player presence, emotional connection or just about anything that might work against the puzzle solving.

This is one reason why we will try to completely remove puzzles for our upcoming game (more on that in another post).

Trial and Error
I just have to mention the trial-and-error nature of Limbo as it is something that I have talked a lot about before and it is quite a prominent feature in the game. First of all, the "repeat and try again" mechanic that is used in almost every puzzles is something that ties into the general design of the game. It is quite clear that it takes the basic design from Another World but I link Limbo is a lot less frustrating.

What I found interesting is that the most annoying parts were not the puzzles where you died and had to restart, but where you missed some part of a sequence and had go back and try again. This mainly because the latter meant you had to redo a lot more and the deaths often had a sort of fun, morbid "gotcha!" mentality to them. Also when the world is reset and the game place you at a certain point you get a greater sense of focus on and a hint that you are on the right track. Just failing to do something always give you that nagging feeling that you might not have set up everything in the proper way.

Still, dying or not, for every time I had to repeat a part of the game, it became less about being present in it's virtual world and and more about figuring out an algorithm. I felt a clear change in my state of mind after just one or two attempts at a section. I am probably a biased here, and thus not best of test subjects, so would be interesting to hear what others felt.

A final note on this: Some people have argued that the cruel death mechanic heightened the tension in the game. However, I think the most important part of creating tension in Limbo was that you never know what to expect next. I never felt any increased tension after having failed once or twice, but instead my greatest tension was from anticipation. Coming closer to some strange branches or a weird contraption, my mind conjured up all sort of imagery of what could happen next. I think this sort of build-up is a lot more powerful, than simply adding cheap engagement from the knowledge that you had to restart (which rarely worked on me anyways).


Cut scenes
The last part I want to discuss are the cut-scenes, or more precisely the lack there of. It is still so common in games that you remove control from the players and then pan/zoom/guide the camera to make sure that the player watches some event (e.g. a creature emerging).

Limbo does not do this, and it makes the events that you see so much more compelling. By using the game's space and character movement as a means of pacing, the events are very well directed, but without ever removing control from the player. I especially liked the villagers that you see running about and thought it was a shame that they were not utilized more. I would have really liked for a more coherent narrative to have come out of these encounters.

End Notes

Despite being mainly a game about solving puzzles, I think Limbo gives a lot of hints on atmosphere and narrative in games, both by things that it does good and things that it fails at. I also wish that we could see games with this kind of polish and interesting art direction, that had main focused on creating immersion, atmosphere and a compelling narrative. As seen when investigating games like Limbo, all the tools for creating truly expressive experiences already exists, it is just a matter of putting them to go use!

Amnesia - One year later

Introduction
A year has passed since we first released Amnesia and a lot has changed for us at Frictional Games since. We have gone from being pretty much out of money, to being financially stable in a way we never thought we would be. Everybody in the company has gotten raised salaries and we have more than enough money to complete our next game.

Our financial situation is far from the only change though. The success of Amnesia has led to us getting a lot more known among players and the press. Reactions to the game are still pouring in, and it feels extremely good and humbling to be able to have that kind of impact on people.

With that little summary, now let's get down and dirty with some more detailed information. (And oh, see end of post for a wee surprise.)


Sales
Let's start with what most people probably are the most interested in: how many units have we actually sold? During the GDC EU lecture I noted that we were now above 400k units total, but as we scrutinized all of the figures it turns out this was not quite correct. Jens did a recount of all income we have gotten so far and the figure ended on 391 102 units (which is of course not correct when you read this as the game sells at about 2 mHz).

This sounds like a huge amount for sure, but there is something to consider with this figure. About 75% of all the sold copies, that is 300k, were on discounted sale. This is quite substantial really, especially when you note that a good deal (almost half) of the remaining 100k were sold at launch. In the end this amounts to around 50% of all our earnings coming purely from discounted sales (most at a 66% or higher discount).

While discounted sales indeed dwarfs our normal sales, the day-to-day sales are quite expectational as well. Right now we are selling around 6000 units per month at full price. This is actually more than enough to cover all salaries and operational costs for each month, which is a situation we still have not really gotten used to. Another interesting fact is that monthly sales have actually increased, they are almost double now from what they were half a year ago. What all this means is that we can work with a healthy buffer that makes it possible to take more risks and down the road spend more money on outsourcing for sound, voices, art and more. Both of which should allows to make our next game as good as possible.

The distribution between platforms depends a bit on how you count it. In our own store it is as follows:
Windows: 70%
Linux: 15%
Mac: 15%
However, our store is the only one that sell a Linux version of the game, so in total sales the percentage of Linux is a lot less. When looking at other stores the distribution is around 11% Mac and 89% Windows. The Mac percentage goes down a bit during sales, where Windows sales increase 3 times or so more compared to the Mac ones. An interesting note here is that Mac sales in our own store did not go down as a other online outlets like Steam started to provide mac versions; meaning it did not steal our customers but opened up to a new market. We think it is a good incentive for other stores to support Linux as well!

The final data regarding sales is the difference between physical and digital sales. As of now, a total of 35, 000 boxed copies of the game has been sold, or around 9% of total sales. This is not too shabby considering we had no release in Europe and that the American box came out half a year after launch. The money earned from a physical unit is much less than from a digital one, but a physical release can still be helpful (however, other problem arise that might make it not worth it, something we will cover later on).


Impact on Penumbra
As Amnesia gained popularity, we already had our Penumbra games up for sale. We were quite curious in seeing how these sales would be affected by Amnesia's success. As Penumbra is quite similar to Amnesia i terms of gameplay and mood, and that both were made by the same company, we thought that we would see a boost in sales and attention for Penumbra. Turns out that Penumbra was almost not affected at all.

The number of monthly visitors for Penumbra are still the same as they were before Amnesia. Same with sales; the monthly total is still a little above 500, which it has been for over two years now. The only influence Amnesia could have had is to keep the average up.

So why did Amnesia have no (or very little impact) on the sales of Penumbra? We think one reason is that main bulk of Amnesia buyers simply does not connect the two. While they are similar, the first look is quite different. Penumbra takes place in present day and Amnesia in the 19th century. Another reason is that whenever there is some exposure for Amnesia, Penumbra is almost never mentioned, so most people that enjoyed Amnesia never learn there is a similar game available.


User response
I noted earlier that the daily sales have gone up over the last year, and large part of that has been due this - responses from the players. Still now, a year later, once a week or more some new post about Amnesia goes up on reddit, youtube or a similar user generated site. This kind of constant bombardment of Amnesia related material has continued to raise awareness of the game.

The major example of this would be the the Amnesia WTF video that reached 4 million views before YouTube, because of mysterious reasons, removed it (here is a copy). Others include this pug picture that managed to spread quite virally, images like this one, and much more.

Another pleasant surprise was the amount of custom stories that have been made. In Penumbra we only knew of a single attempt to make a user-created level and that one was never released in public. For Amnesia at least 300 custom story projects have been started, and 20 or so have actually become completed, high quality, experiences. There has even been a Tetris clone made with the tools!

This surge in interest has made our community a lot more active too. A year after we released Penumbra: Black Plague, our forum was quite dead, having a post every other day or so. Right now we average about 200 posts / day, and all of it is pretty much thanks to the custom story creation. This has also spread to other parts of the forum, and there is a lot more general chatter, technical help between users, etc . It really shows that supplying users with creation tools is well worth the time.


The making of Amnesia
As a year has gone by a few resources on how Amnesia was made has popped up, so it seems like a good time to sum them up now:

The Terrifying Tale of Amnesia
A post-mortem of Amnesia at the Escapist, that describes what we went through when creating the game. It mostly deals with the financial side, but also on how corporate decisions lead to changes in design, screwed everything up, and other juicy stuff like that.

Birth of a Monster
The design and production process of the grunt monster, written by several of the people involved. Do not forget that there is a second part.

Evoking Emotions and Achieving Success By Breaking all the Rules
A talk I gave at GDC Europe about a month ago. It goes over a lot of the design decisions that went into Amnesia.


Next for Frictional
So what is next for us at Frictional Games?

First of all, we want to get up to speed on our next game. Since we spent all resources we had on getting Amnesia done, we had to start the new project without any sort of momentum. Added to this was the potato thingie that also took a lot of time (but was really worthwhile). This has lead to a discrepancy between design, technology and art that we just about caught up to now. We have done a lot of work on the next game, but it is not until now we are close to having a nice work flow.

Because of this, a major issue for us to fix is to be able to manage multiple projects. We want to have a nice reallocation of resources at the end of each project and make sure to keep the flow going. However we do not want to grow the company too much, and thus we are looking into other avenues. If everything goes as it should we will announce our first stab at a solution to this quite soon!

Another big change for the future will be consoles. The main reason for choosing consoles is purely financial. Right now our main income comes from very few channels, and we need to spread out the risk somehow. The other reason is that we feel we are missing out on exposure by not being on a console and not reaching as many players as we should be able to. Unfortunately consoles are really old compared to the PC right now, so it will be far from straightforward to develop for two platforms. Our current thinking is to make the console get a lower end version and make sure console specs influence the PC version as little as possible.

Finally, in regards to what our next project is about, the basic idea is to use lessons learned from Amnesia and then take it to the next level. We have mentioned before that the next game will not be as horror focused as our past ones, but still have a scary atmosphere. Our intention this time is to dig into deeper and more intellectually demanding subjects. Another goal for us is to get past having classical puzzles that break the flow, but without making the game into a spoon-fed type of experience.

We are all really excited about the future, with tons of ideas we want to try out and now with the resources to do so properly. This is the first time for us developing a project that we know we can fund all the way and not worry about tight resources. It will be very interesting so see what will be possible to create this time!


More questions?
Anything else you want to know? Well, you are in luck because the entire team will be available for an Ask-Us-Anything at Reddit! Just go here:

http://www.reddit.com/r/IAmA/comments/k9vwj/we_are_frictional_games_creators_of_amnesia_the/

It is really simple to register at reddit, so just do so and fire away in case you are curious! And do make sure to up-vote it so it gets some exposure!

And finally, thanks to all who have supported us, pre-ordered our games, put up crazy stuff on the internet, provided help in the forums and in other ways helped to spread the word!

GDC Lecture now online!

The lecture I gave at GDC EU 2011 is now up here:
http://www.gdcvault.com/play/1014889/Evoking-Emotions-and-Achieving-Success

It is one of three lectures that were put up (so far) and it is 100% free for you to watch :)

GDC Europe Sum-up

Me, Marc and Jens got back from GDC Europe yesterday so thought I should write a small summary of the trip.

First of, some thoughts on the lecture:


My talk was scheduled the first day and was the first time I have ever had this type of lecture so I was quite nervous. This meant I had a bit of trouble relaxing and enjoying the other talks before mine. Also, the night before I had had the final practice round for the lecture, making my dreams that night filled with nothing but fragmented sentences from my script, which of course tainted the next day too. My head contained little but the lecture.
My first plan had been to learn the entire lecture and not use any notes, but during practice I always managed to miss something and felt having some kind of notes was more secure. As the lecture slides was pretty much void of text and the actual images often not very descriptive to what I said, I had to keep everything in my head. In the end, I am happy I made the decision of having notes as I did get lost a few times, but could quickly get back by a glance. Hopefully nobody noticed anything.
When it was finally time for the talk I was really worried if any of the videos would work, as there had been numerous problems when testing at home. Fortunately all videos showed perfectly!
Overall, I think it all went quite well and the audience seem to enjoy it too. There are summaries of the lecture at Gamasutra and Gamespot, and I will see if I can get the script up too later on.
I was also involved in a panel with some other people. My five minute presentation was pretty much an extended version of an old blogpost.

Once my lecture was done I could finally relax and enjoy the various lectures a bit more. As always there is a great mixture in quality and content. My favorites were probably a lecture about RPG mechanics, a talk on horror by the developer of the upcoming Silent Hill Downpour (even though I disagreed with plenty) and a talk about performance capture (by one of the founders of Ninja Theory).


Apart from the GDC stuff, we also attended something called the NotGames Fest. It was an exhibit that showcased a bunch of games that did not have a big focus on "fun game mechanics", and Amnesia was one of these. It was all much more nicely setup than I thought it would be. Visitors had to enter a atmospherically lit, cave-like room built up from cardboard. It was quite moody and fitted the exhibit perfectly. I really liked how it contrasted the normal, ear-deafening, sensory overloading exhibits videogames are normally shown in and had a very calm and serene feel to it instead. I hope that there will be more game exhibitions like this!
At the evening the exhibit also had a BBQ featuring hot-dogs in round buns, which was felt a strange (but still tasted good). Jens told me this some German tradition. Anybody know anything more about this strange way of hot-dog consumption?


Also like to note that two guys form the Italian company Santa Ragione gave us a free copy of their horror board game "Escape from the Aliens in outer space". We tried it while waiting for our plane to take off and even though we were probably a bit too few it was really nice. Will definitively play it again.

Horror Tip: Hide

I just saw this little horror game gem called "Hide". It is a very simple game with very simple graphics. Basically the game is all about finding five signs scattered across a map while avoiding being found. I think it is a great example in how not showing something properly makes the imagination go wild. The extremely sparse (yet workable) graphics and the atmospheric soundscape forces you to immerse your self and imagine your worse fear.

The game only takes a few minutes to play, so I suggest you all give it a go. And do not forget those headphones!

GDC Europe

Just wanted to inform everybody that I will be holding a lecture and be part of a
panel at GDC Europe next week.

The lecture is called "Evoking Emotions and Achieving Success by Breaking All the Rules" and will be about some of the design in Amnesia and also touch upon a lot of subjects discussed in this blog.

The panel has the name "Beyond Fun: Perspectives on Video Games as Expressive Experiences", which will include 4 other swell guys and gals. In it I will have a lil rant called "Games or Toys".

Both of these will take place on Monday and be one after another. Hopefully I can put something or link to video after the convention is over.

Will anybody here be attending?

Tech feature: Script Overview #2

Second part of the scripting overview.

Make sure to watch in HD: http://www.youtube.com/watch?v=UmQjO1C_Q90?hd=1

Amnesia Post-Mortem

A post-mortem for Amnesia is now up on The Escapist. You can read the whole thing here:

http://www.escapistmagazine.com/articles/view/features/9011-The-Terrifying-Tale-of-Amnesia

While not short, the article is a bit edited and does not go into details on all events. Still it should give a pretty good overview of how Amnesia came about.

Tech feature: Script Overview #1

I just recorded a little clip about how scripting works in HPL3. In this film I just talk about the very basic elements of scripting and will follow up with another movie were I talk about some more complex features:



Make sure to watch in in HD: http://youtu.be/5OKFik2IEZU?hd=1

Is the player an artist? - Redux

In case you did not follow the comments on the last blog post with my views on the player as an artist, you might have missed that James Portnow from Extra Credits responded and he and I had a brief exchange. This discussion is now up on the Escapist in case anyone is interested in checking it out:

http://www.escapistmagazine.com/articles/view/editorials/misc/8976-Extra-Credits-Addendum-Discussing-the-Role-of-the-Player

The articles has lot of interesting responses from the readers. I think I have already said what I have to say, so I will not discuss it further here. However, do feel free to continue the discussion in the comments!

The Player - the artist?

Introduction
In this week's Extra Credits it was argued that we should treat the player of a video game as an artist and co-author of the game. One major point was that other media can be said to be valid without an audience, but not so for videogames. In video games a player is needed for the work to fully come to life. The other point was that players have an artistic role in this co-operative creation and that understanding the feelings that drive an artist can be used to make better video games. You can watch the whole video here:
http://www.escapistmagazine.com/videos/view/extra-credits/3555-The-Role-of-the-Player

While I think that Extra Credits is an excellent show, I do not really agree with this. The hypothesis of player-is-artist sound quite plausible at first, but I think that if you take a closer look it does not really hold up. I also think that if we choose to design games with this mindset, we might be missing out on very important things that can be done in the medium.


Why an audience is crucial
Consider the information that a novel transfers to its audience. More than often a few words is all that is given as base for the reader to imagine a scene. It is assumed that the reader is able to fill out large informational gaps, make assumptions and to even retroactively dress earlier scenes as new information comes along. A novel also throws a lot non-trivial concepts at the audience. Just consider something simple as a person being labeled as "depressed". In order for the reader to understand the state of mind of this character, a personal knowledge in human behavior and psychology is necessary. The reader simply cannot understand literature without a certain amount of experience.

What I want to say with this is that books cannot be enjoyed in a void. They have to be processed by a human with a certain amount life experience in order to come alive. An alien would be completely unable to understand any literature even if it could decipher the language. There are just so many prerequisites needed that a deep study of humanity would necessary for full comprehension. And even then it might not be possible for the alien to understand; the very workings of our minds is probably crucial for a proper enjoyment of the work.

Further more, the mental image painted up in our mind is not merely an opinion-based interpretation of the written text. It is a full blown world, populated and maintained by ourselves. We are not just doing a trivial text to sensory input conversion when reading. We are doing an actual simulation, constantly adding and updating details based on the written words of the novel. The book helps us a long on the ride, but at the end the heavy work is done by the audience.

This mental construction work is not passive exercise either. We choose where to read, what to skim, where to put focus, if something should be skipped and so on. This is even more evident in other media. When watching a movie, interactions with other audience members can help shape the experience (a simple example would be laughing during funny moments). When listening to a piece of the music, the settings, our own movements, etc all change the way in which we experience the piece.

Enjoying a work of art is a very human experience and I argue that in this regard videogames are not different from other forms of media. What is so special about video games is that data flows in two directions and that the audience can help shape the output to an extent far beyond any other media. However, that does not mean that experiencing a videogame is totally different kind of activity.


Why players are not artists
Unless a game is incredibly linear (e.g. Dragon's Lair) everybody who play it will come away with their own personal experience. Because of this it is easy to imagine that videogames differ a lot from other media by essentially making the player a story-teller. And as being story-teller is essentially equal to being an artist, it leads to the conclusion that players are artists. I do not think this holds up though.

Consider doing a trek through the woods. Even if several people follow the same route in the same forest, each one will have with very different experiences. Some might take side-tracks, have some unique encounters, do the trekking at a different pace, etc. The possibilities are essentially endless. The person doing the journey shapes his/her experience in a unique way and has a big responsibility in how it all turns out. Still, this is not an artistic endeavor.

That is until the hiker decided to write, paint, talk, etc about the trek. Once a narrative, in whatever media, is created of the personal experience, an artistic process takes place. The art is not in living the journey, the art is in conveying it to other people; to create a work that expresses the very personal sensory input, actions and emotions evoked.

The same is true for videogames. Even though the player posses a great freedom in shaping their path through the virtual world, this does not equal the player to an artist. Likewise, even though readers of books create and simulate complex worlds, this does not make the reader into an artist. It is not until the personal experienced is expressed in some kind of medium, be that a written narrative of a game session or a painting from a scene in a novel, that art is made.

Sure there are videogames that give great opportunities for creating art, Minecraft being an good example. However, this artistic creation is a side thing and is not a requirement. The players can simply just let themselves be one with world, build a shelter, etc. It is not until the player simply sees the game as tool and foundation for their own work when the line between player and artist really blur.

With all this I am not saying that the activity of enjoying art is void of creativity. As explained when discussing how we read books, I made it quite clear that it takes a lot of effort to do it right. However, this does not mean that the act of reading a book is categorically equal to writing one. Instead it is more like the difference between solving a puzzle and creating the puzzle in the first place. Both activities are creative and challenging, yet quite different.


Why this matters
Why even have this discussion? Is it not just a silly debate over semantics? Well in part it is. But if we do not take care and use the words properly they will start to loose meaning. If we would say that the activity that players participate in during play is the same as artistic creation, then I think we simply stretch the concept of artistic endeavors too far, making far less usable.

A more important reason is that the way we see the relationship between players and videogames greatly shape the direction we choose we take the design of videogames. Even though video games have a very different voice from other media, we should not think of the activity of experiencing it as completely different. I fear that if we see players as storytellers and artists, we will miss out on a lot of opportunities at expanding the videogames medium. If the player is an artist, then our focus on game developers will be on creating brushes. This implies a bottom-up design, were short-term effects trump the bigger picture. If we want make games with a deeper meaning this is not the way to go. Instead we must focus on a higher level, something I think the player's role as outlined here greatly encourages.

Also, saying that the player is an artist and storyteller shift the burden in the wrong direction. If we grant the player a large artistic role, we make it easy to blame the player for any lack of meaning in a videogame and discourage the creators from trying to add it. A painting should not require a painter to enjoy it, a play should not require you to act for it to be engaging, and so forth. Like great works of art in other media a videogame can require a lot from the player. However, this does not mean it is up for the player to create meaning and depth, it should instead be there for the player to find and become immersed in.

Tech feature: Scripting upgrade

Introduction
For a couple of months now I have, on and off, worked on some basic tech aspects for the engine. Everytime I was done with one of these I thought it was among the hardest things I would do for the new engine, yet the next feature as always proved more challenging. Terrain geometry was harder to implement than sun shadows, terrain texturing harder than geometry, and so on.

Implementing the script system is no different. It is easily the hardest thing I have done so far for our new engine - HPL 3. It has had this "perfect"sort of challenge: Difficult problems to solve, much basic knowledge to wrap your head around and awfully boring and monotonous parts. I really hope this marks the end of this trend of increasing difficulty, as another proportionally large step might make my brain to melt and my fingers to crack. At least it can wait for a lil while...

Enough complaining. Now that the scripting is pretty much implemented (some engine stuff still needs to be added and some more problems remain to be solved, but it is really minor), I am extremely happy with it. I think it will help us build better games, and to finish them faster. Now let's move on to how a boring scripting system accomplishes this.


Background
Before moving on the the actual scripting I need to explain what brought on the creation of the current system. It all started with our first commercial games, The Penumbra series.

When creating the Penumbra games our tools were primitive to say the least. All maps were made in a 3D modeling program, Maya, and then exported to Collada. The game engine loaded the Collada file and built the map from it. As a 3D modeling program is meant to create 3D models, it is not really meant to make levels in. With no ways of placing entities we had to use special naming conventions to tell the game where any non-static objects in the game were located. To be able to do this properly we had to make special "instance" versions of each model meant for the game, since without this you would not be able to see how an object was placed before the game started.

Lighting was equally annoying since Maya has no support for radius on lights. This mean that you could not visually see how far a light reached, but simply entered a numerical value and hoped for the best. As this was not enough, you also needed to place portals and group meshes in order for the engine to provide occlusion culling. This could be quite tricky at times, and often you could sit a day or two simply tweaking portal setup. Added to this was also the problem that Maya often failed to show any textures, and most editing was done on grayish levels. For more info, you can just check the wiki.

The problems do not stop here though. Everytime you meant a change to the game, you had to do a complete reload. So setting up lighting in the game could be quite the effort: change light position for two seconds, load map for 2 minutes, notice it is not good, repeat. As you might figure, we got quite good at batches tasks and the phrase "it will have to do" was uttered more often than not.

For scripting it was just a grueling. Every change in the script required a full restart of the game, creating the same sort of frustration present when modeling maps. And to make scripting even more frustrating, there was no syntax checking until the entire map was loaded! This meant you could wait two minutes of loading only to find out you had forgotten a semicolon or something else trivial.

As I write this, I actually have a hard time understanding how we could have gotten anything done at all. And unsurprisingly, even though we released mod tools and documentation, not a single user map for Penumbra was ever released.

For Amnesia we knew we wanted to fix this somehow. The first step we took was to simply make our own editor where all the maps are built. Since it rendered with the same engine as the game, it made is much easier and faster to tweak entity and light placement. We instantly saw that productivity rise with this change. For scripting it was pretty much the same, but we added the extremely simple fix of compiling the script before loading the game. This removed some of the time previously spent on, in vain, looking at loading screen.

Although we had new tools all was not good. You still had to reload all level data every time you made a change to the map or script. We did not think much of this though as we were so used to doing it this way, and happy that we had all the other improvements. However, a year and a half into the development we discussed if we really needed to reload the level. I cannot recall what sparked this idea, but anyhow we figured that we did not and I added a menu with a Quick Reload button. This cached all textures, models, etc and reloaded map very quickly (usually taking but a few seconds). This increased productivity and creativity tremendously and was one of the better decisions we made during the development of Amnesia. Another sign of how much these changes improved work flow are the over a hundred of user maps created as of today.

What is so strange about the reload-feature is that is something that we could have added during the development of the first Penumbra, but for some reason we did not. It is quite frightening how often you convinces yourself that there is no better way of doing a task, and never try to improve it. We did not want to make this mistake again and started thinking of what more we could do.


Taking script to the next level
In Amnesia and Penumbra, scripting is only used to control logic flow in the levels. How enemies spawn, how puzzles work and so on. All other gameplay is hard-coded into the exe file and written in C++. Normally when I write this kind of code, rendering for instance, I can do large chunks at a time and then simply see if it works as intended. This often in small projects that are fast to reload. However, when writing gameplay and UI code this is almost never the case. Instead you constantly need to fine tune algorithms and variables until you get the expected behavior and work in large projects. Not only does this mean a level restart (with full resource reload), but the exe itself also needs to be built from code, a process that can easily take half a minute, even if the changes are minor. This means that coding gameplay can be quite a hassle at times, on par with how map building was in the Penumbra days. With the lessons learned from Amnesia fresh in mind, this felt like the obvious area of improvement.

In order to make this happen we had to move as much gameplay code as possible into the scripting. What this meant was that we needed to do some large upgrades to our current script implementations. For example, right now we only supported the most basic types (bool, int and float) together with strings in script. This already caused some issues when exposing game/engine functions and when writing scripts, for example instead having a single argument for color, you had to have four floats (one for each color and one of alpha), making code ugly and writing it more cumbersome. So just this upgrade was worth doing.

We also needed expose all engine classes, so that the script could be used pretty much as if it was normal C++ code, and achieve pretty much the same things. I was not sure exactly how much to expose but knew that the more the better.

Finally, the most important feature was to be able to reload script at any point, so it would be easy to just change a line, click a reload button and then a few seconds (or less) later see the change in-game. To get this working was the by far the most important goal with the entire upgrade. This would not be as easy as the level script was in Amnesia though, since the script system would not only take care of the code, but of part of the data as well. This meant I needed to save the state somehow, a feat I was not sure yet how to accomplish.


Implementing Classes
Before tackling the problem of script reload, I first had to make sure to add engine types to the engine. And even before doing that I needed to be sure our current scripting middleware was up to the task.

The scripting system that we were using, and have been for a long time, is a library called Angel Script. It is actually the middleware that we have used the longest, ever since end of 2004 and the Energetic project. Even though we have used it for such a long time we never really used to anywhere near its full extent and now was finally the time to make up for that. I took a day to look through the documentation and found that AngelScript could support everything that we needed, and what was even better was that it was not that difficult to add.

AngelScript is a bit different from other popular script languages (like Lua) in that it is strongly typed and very closely connected to the underlying C++ code. For one thing this makes the script quite fast (although not faster, see end of post for more info). It also meant that AngelScript could link to the classes almost directly and I only had to declare the class and link to its different parts (whatever member variables and methods that I wanted to be exposed). It also supports pointers quite easily, but makes them more secure with a script specific handle type. This requires you to keep track of some memory management for the data, but you do not need to do it, and I could very easily and quickly add support for a vast number of engine resources (textures, meshes, lights, etc).

The only thing that was a little bit trickier was supporting inheritance (when a class can build upon another class). Basically you have to redeclare methods every time you add new class that inherits from something. You also need to specify to what other classes this class can be cast to. This might sound a bit of a hassle, but the result is that you can control so the script always has a very close mapping to the code it exposes, something that I was extremely thankful for when implementing the state saving (more on that below). Also, through some use of macros, adding the implemented classes become quite easy.


Basic script layout
The next thing to figure out was the basic structure of the script code. In Penumbra and Amnesia we simply added the functions directly in a script file and then allowed that script file to represent an object. I first thought that this would be a valid design this time again, until I started thinking about how to store the data (meaning any data that should be kept between executions of the script).

In Amnesia and Penumbra the only data that is saved is simple variables like an integer for the number of times the player had stepped on button or similar. This is done through using special functions for all these variables, for example:

SetLocalVarInt("ButtonPushNum", 1);

This function saves the data to the game, and when the script is reloaded (meaning destroyed and recreated) the script can easily reference the data again by doing:

int lX = GetLocalVarInt("ButtonPushNum");

However, this time the game had to save a lot more complex data, like pointers to resources, matrices and whatnot. At first I actually considered using system with functions like this, but I figured that it would just mean a lot of extra work, and just make things more difficult. Again I thought about the lessons from Amnesia's reload feature, and thought it was worth trying to find a better solution. What I ended up doing was to force each object to be contained in class, and then let all data to be members of that class. This allowed AngelScript to make copies (needed for enemies and whatever there will be more than one instance of) and also made it was easy to keep track of the members (you simply create an object in the C++ code and can then iterate all its data).

A problem that I realized now was that I needed to have C++ functions that only worked in certain types of classes and only on data for a certain copy. For instance, an enemy class might want a function like IsInLineOfSight(...) to see if it has visual contact with something. However, there were not any functionality in AngelScript for doing this. I could give the script class a template class that forces it to implement certain functions, but I could not let the C++ code act as a base and expose specific functions from it. To solve this I had do some hacking. I ended up using global functions, and to keep track of the currently active object. (Again with macros to the rescue.) The resulting solution was not perfect though, as the global function can be used in any class and not just the one it was meant for. I am still looking into some fix for this.


Saving the state
It was now time to save the state of the script. To start this off I took the naive approach and simply saved the script data directly by copying it. This works very well for stuff like vectors, matrices, etc where it is just a matter to make a copy of the data. But it does not work that well with resources like meshes, texture or even objects like physics bodies, billboards and lights. There is way too much data in those to copy. And if I simply save the pointer I need to make sure that no data has changed when the state is loaded again, or else the saved state will not work.

At the time I was only building the system to work with a script reload only, so these issues did not pose a problem. But a major obstacle popped up when I wanted to save classes defined in scripts code. These where not possible to simply save by copying, because when you rewrite a script they can change entirely. For instance, if the class when saved consisted of two integers, and when reloaded has one string and a matrix instead the data you saved is invalid. It gets even worse if a script class has another script class as member and even more so if script classes are saved in arrays.

I figured I needed to do some kind of drastic change if this was to work. I was sketching on a few systems that could save variables in a separate structure, when it hit me. The system I was working on could not only be used to save the state, but if I implemented it correctly I could also use it for saving. For Amnesia and Penumbra I use a special serialize system that can save classes to file if initialized correctly. It is quite cumbersome, but way better than writing load / save for every single variable. However, as I was to do most gameplay code through script (the code that pretty much contain everything that needs saving), I could actually get rid of rewriting the save code for every single gameplay update. Another huge benefit of using scripting: automatic saving. This is bound to save tons of work. (It did mean a lot more work though...)

Up to that point I had looked at the scripting as separate part of in the engine. A module that all other modules could work without if removed, exactly like how most other modules work. Thinking like this had colored a lot of the design decisions I had made. Now, I instead decided that since scripting will be basically what controls the engine, I started of thinking as something that was part of all other modules. This led me to do a major rewrite of the state saving.

There is quite a lot to say about this system (and serializing in general), but I do not really have the space right now, so I will just do a quick overview. First of all, the system defines a few basic types that all other structures are built up from. These are bool, int, float, vector, matrix, color, etc and I implement very specific create/save/load methods for each of these. In AngelScript all of these are also implemented as primitives (built-in types) or data objects (which is a type where AngelScript handle all memory management). When saved the actual binary data is saved.

All other classes are implemented as references, meaning AngelScript only manages their pointers. When saving the state of these classes, each class must implement a a special method that adds all of the member variables (either basic types or other reference classes) to a list. (Basically the explicit method described here). This list is then used when transferring data to a special save buffer that contains the data of all the basic types and/or sub buffers containing data for other classes.

For certain classes, its pointer is backed up in the C++ code. So when the save data for it is loaded, the pointer to the class is first searched for and if found it is updated with the saved member data. This makes it possible to reload the script code without having to recreate all the data.

Of course, all sorts of complications arise during this, and again it would take too long to go through them all. But as I hinted before one thing that saved me is that script objects are so closely connected to the engine data. When writing code that deals with serialization one of the biggest annoyances is that that class pointers with multiple inheritance can change their address when cast. Because the script language only returns void pointers (memory address with no type specified), you must be sure of the type it returns, something AngelScript allowed me to be.

Another fun thing with serialization are all the strange macros that you have to make. For example, this one was pretty fun:

#define ClassMemberClassOffset(aClass,aMember)
( size_t(static_cast(&(( (aClass*)1)->aMember)) ) -1 )

This one is used to make sure that class member offset address points correctly. It is one of the many things that make sure multiple inheritance problems, as explained above, does not screw things up. I got an entire header file just filled with fun stuff like this!


Closing notes
Once I had the system working it was quite an effort to add all the classes. There are countless classes that all need to be set up in specific way and everything to be saved needs to be initialized. Sitting several days in a row just coding stuff like this can really tear on the psyche. Fortunately, almost everything is added now, so the worst part should be over.

Another nice addition to the new script system is that it can auto generate the API function file for NotePad++. This allows NP++ to autocomplete any text that you write and you no longer need to keep function names or arguments list in your head (and skip the manual look-ups). What is annoying though is that it only works with global functions and NP++ cannot recognice what class a certain variable is in and show all its members (like visual assist can for C++). Does anybody know an editor that can manage this?

One thing that I was really eager to get working was threading. In Amnesia we use tons of special timer callbacks to set up events, and it would have been so nice to do something like this instead:

...
PlaySound("x");
Sleep(10)
PlaySound("y");
WaitUntilTriggered("a")
...

AngelScript does support this sort of thing, but there is currently no way of saving the state. So if the player where to save during a sleep, the game would be different when loaded. This is unfortunate, but I am looking into some other solutions instead. If anyone has ideas on this please share!

Right now I have only tried this system in some tests, but it still feels really good and works exactly as I want. It is just so great to be able to reload any code changes in a fraction of second. It allows for rapid iteration, makes one more productive and generally just makes it so much more enjoyable to code. It is also so gratifying to have an idea and then successfully implement it to the sort of quality you hoped for.


Addendum:
I earlier wrote that AngelScript was faster than Lua, which is not the case when it comes to code solely executed in the script (see here). So obviously my initial statement was not correct. However, I still think AngelScript must be faster in calling implemented c++ functions/types as there is pretty much no overlay involved. I do not have any data to back this up though, so do not take my word for it :)


Found this irresistibly interesting? We are hiring!

The Gathering

On the morning of May 10, we all gathered for the very first time. Unlike what many had prophesied, this did not bring about the end of the world. No, this Tuesday morning turned out to be quite benevolent. The six of us met at Malmö train station right next to the statue of the knotted gun, which incidentally did no longer exist.

“Good,” said Thomas, “would have been too easy to find if we were able to follow our directions.”

Thomas and Jens are the founders of Frictional Games. They make an interesting and effective pair. Thomas is a force of nature hauling us off to adventure, while Jens is the more reserved type who dryly states that we’re going the wrong way. Together they manage to keep us moving on the right track.

I had already met them both before and along with Marcus and Luis, who I had met on the trip to Seattle, there was only one man left.

Marc turned out to be a cheerful man with subtle gestures. His eyebrows bounced as a silent hello.

“I guess we are all here.”

The Gang

That innocuous Tuesday might seem arbitrary, but there was a reason for us to meet in Malmö that day. The city hosted the Nordic Game Conference and we were to attend and hopefully receive some love from the press and our fellow game developers.

“This is going to be fun. And the award ceremony is going to be exiting!”

“Right, about that. We were not nominated for anything,” informed Jens.

“Nothing?”

“Nope.”

“Not a single nomination? From the very people who even helped to fund Amnesia.”

“We got a free booth to display our game.”

“Better than nothing?”

“Not really, now we have booth to attend to.”

We were there to attend the conference, to hang out, and get to know each other. We really didn’t have anything new to show, which kind of explains why our booth was grossly understaffed and consisted of one computer running Amnesia with a t-shirt strung up above it.

The conference took a slow and smooth start as we really didn’t have anything to attend except a minor exposé of games including some casual drinking. That is why we first headed off in a completely different direction and ended up visiting the “House of Science and Maritime History”, a museum filled with old machines and oddities. Having filled our heads with interesting factoids, it was about time we burned a few braincells with a bit of reckless driving at the go-cart circuit. Marcus stumped us all with his motor skills, leaving us convinced he must have had a lot of practice. Being from the northern wastes, it only seems reasonable he would have to drive fast to get away from polar bears and Santa.

Road Rage!

Wednesday was the day that the conference really got going. Ed Fries, a game making legend from Microsoft, launched the day with a great keynote speech about creativity and constraints. Afterwards we all split up and to attend the lectures we found most interesting, only to meet up by the Street Fighter arcade machine during the breaks, to kick ass, chew pastries, and drink coffee.

Hadooooouken!

During the evening the main gala was held to announce the winners of all the awards. Knowing well we hadn’t been nominated, we chowed down on the delicious food we were served. That’s when we suddenly noticed that they were playing a Amnesia-trailer on the big screen.

“We won... something!”

“Wait, what? Did we?

No, we didn’t, at least I don’t think we did, but we were called on stage to take a bow in a nice lifetime-achievement sort of way.

The next day when all the hoopla had settled, we were greeted, by strangers and friends.

“Congratulations on the award!”

“Thanks, we didn’t get one.”

“Sure you did, you were on the stage and everything. Must have been some kind of award.”

To this day we don’t really know what that was, but it was interesting mixed with a hint of awkward.

Thursday passed with even more lectures and Street Fighting. As a final farewell, all the participants gathered in the large hall to play a game. Not the digital kind, well almost, indirectly if you will. The moderator pulled up two game titles and a statement. Then two people from the audience got to argue which game fitted the statement. The first bout? Amnesia v.s. Bioshock – Which one is more disturbing.

The first thing that ran through my head was; what if I was picked to defend Amnesia, that would be embarrassing. Then it struck me. What if I decided to defend Bioshock! It was not like anyone really recognized me as the writer. That would be hilarious, to talk smack about our own game, what if I won that argument? I was laughing inside already.

Even though I now and then get some clever ideas, I tend to be slow. When I went to raise my hand, it was already too late. Two contestants had begun to argue what was more disturbing already. Pride and shame mixed as they argued their sides, but it turned to a heartwarming experience as the crowd favored Amnesia. Hell yeah, we made a disturbing game.

If you want to slow down, just crash into something.

On Friday there was no conference, it had ended on Thursday. However, there was more to be done. Luis and Marcus, the two people who actually had to fly in to be able to attend, had one more day to spend. Jens and Thomas invited us to come to Helsingborg, where they and Frictional Games officially reside.

Since there was no office to visit, we headed out into the city. To do so in style, we jumped on Segways and rode around. It was tremendous fun and we got to see the surrounding nature in a pleasant way. Some even got to see the dirt road, up close, as they came crashing down. That’s right, no less than Jens, Marcus, and Luis managed to crash their Segways. In increasingly dramatic ways too.

After the death defying speed racing with Segways, we slowed down with some care free sightseeing in the city and a visit to the local tropical zoo.

The evening and the week ended with some fine dining and then some beer at the pub. It is difficult to sum up the experience and let you in on all the details. Let’s just say, a bunch of anonymous internet people came together in real life... and the world didn’t end this weekend, that’s strange, isn’t it?

You’re welcome.

Marcus in his natural habitat.

Feel like joining the insanity? We are hiring!