The perception of $100 000

I read the other day that the US budget deficit is expected to be $1 300 billion for 2010. Which led me to say to Thomas that we should ask the US government (Yes, I know we are Swedes. Yes, I know it is wrong to expect Swedish game development support from the US government.) for $100 000... Who would notice?

Which led me to think about the perception of numbers, in particular when talking about money. Usually people (such as myself!) perceive money from an individual perspective, making sums like $100 000 appear very large. But, if one puts the same sum into the perspective of a group, the same amount of money is all of a sudden much less (really?!). For instance, 1 300 billion shared by a 300 million population adds up to $4 333.33 per individual. That's not so bad is it?

I'm not going to continue on the topic of the US budget, it only reminded me of a situation about a year ago which in turn will lead to the actual subject of this post.

I met a fellow that does not play games, know anything about the game industry or how you go about creating games. He curiously asked me a bunch of questions regarding these matters and I explained that in general it takes at least one year to create a game, more like two years. I talked a bit about how we worked (from home, with limited resources, etc) and what differs us from a "normal game company". He also asked how it generally works with the development process and how you fund it. I explained, in a simplified form, that you have two options: Either you have the money and you fund the whole development process yourself or, you lack the money and you make a deal with a publisher to fund the development. At the time we were quite close to settling a deal with a publisher, so I got the question: How much are they paying you to create Amnesia?

I hesitated a bit, it is not something that I normally tell people, so he started guessing some figures -What? $25 000? -Well, no. it is more than that... (I replied, thinking about what a good answer would be without giving any numbers) -OK, so it's like $100 000 then? -Uhm... (I didn't get a chance to reply) -Well, that's not so bad! He said cheerfully, reflecting over my previously mentioned "limited resources". To cut things short, we didn't talk much more about it after that as other topics were brought up, but this is basically what this post will be about - How much money is $100 000 when you run a company, in particular an independent game company? I would really like to go over it, because I am not sure how in general people reflect over these types of sums when talking about "Indie games". I have the impression that $100 000 is considered to be a lot of money, but I could be wrong. Is it?

As a starting point, I will summarize a couple of things:

-We are funding the development of Amnesia on our own. When the game is released we have been working on the game for about three (3!) years.

-Initially we had a publisher involved, but we had to terminate that contract and re-think how to create the project on our own.

-We are five full-time workers here at Frictional Games and we also have contractors that do varying amounts of work during periods of the development.

-Last year we had a very successful Steam weekend, followed by a successful Linux weekend and a period after that with better sales than normal due to the extra attention we got from those weekends. It gave us a total of about $80 000 in revenue for that month, 20 times as much as we have on average during a month.

-To keep it simple, let us assume the $80 000 actually were $100 000.

So how long can Frictional Games go on using these $100 000?
Well, lets take a look at how much it costs to pay ourselves a monthly salary of $1 500 each. Our salaries are less than that, they vary a bit too, but as with most things in this post I try to leave the details out of it. We also have to take into account all of the taxes and fees involved. In Sweden we have 30% income tax, but for small amounts such as $1500 it is more around 20%. We also have employer fees that are 32%, 16% if the employee is under the age of 26, these fees are added to the original amount. We also have 12% added for vacation salary, and another 32%/16% of fee added for that sum. That means:

$1 500 paid, gives the receiver $1200 to put in the pocket.
$480 in employer fees.
$180 for the vacation salary.
$58 for the employer fees on the vacation salary.
$2 218 total cost for the company to pay an employee $1500.

Let us round it down to $2 200, that means that for all five members of Frictional Games you get a monthly expense of $11 000. Making $100 000 a sum that would last for almost exactly 9 months. Which sounds really great! But... of course this did not include contractors or any other expenses (server, insurrance, legal advice etc). We could remove all of the contractors and do everything ourselves, but that would only extend the development time and increase the amount of money needed. We really must, and want to, work with the contractors that we do as they are great at their specialities - saving time and producing great content. As an estimate I would remove about 3 months of pay to cover the rest, which leaves us at a best case scenario of 6 months of living time. This too sounds pretty good, but then again a salary of $1 500 is at least $1 000 below an entry salary at a Swedish game company. It is not exactly a salary following the industry norm!

While 6 months is a good time to last, it is only 1/6 of the time needed for the whole Amnesia project. It was 6 months that were given to us from all those that made the two sale weekends so great, but it is not possible to have that type of success all of the time. In particular when the games you have to sell gets older and older, even if you can always reach new customers it is very rare to have those high spikes of revenue.

I hope that this post can give a bit of insight into the needs you have when running an indie game company and trying to make it your full-time job. To show that a sum of $100 000, that I think can be looked upon as a large sum, might not be so large after all when you are a group of people that are sharing it and all the taxes and fees are applied. I would never complain about our situation (it's definitely a good time), but I would not consider it to be a "successful living" just yet, we have a bit to go before we can make a proper living and not constantly having worry about "what happens next month?".

How Gameplay and Narrative kill Meaning in "Games"

Introduction
In many of the posts here I have been discussing how having "unfun" gameplay can greatly enhance the experience. I have also ranted about how too much "fun" can completely destroy the intended experience. What I want to discuss now is how a game's most common ingredients might be detracting from certain kinds of experiences and are in some cases best gotten rid of. These ingredients are Gameplay and Narrative. It is my view that these two features can seriously get in the way when trying to take the interactive medium in new directions.

I also believe that using the word "Game" is holding back progress in certain areas. The reason for not using the word "Game" is that it comes with certain expectations, which I will go through below, and these can work against both user and creator.

This post will also explain a bit about the design and goals for our upcoming game Amnesia. Hopefully it will provide a bit insight into the game and explain some of the concepts and ideas that we are trying to accomplish. In Penumbra we put a lot of focus on the actual emotional experience and in Amnesia, we aim to take that thinking a step further.

To get things started I will first dive into something that lies at the heart of all artistic creations.

Meaning
In many people's minds, the word "meaning" probably provoke images of some hard-to-grasp piece of art with deeply hidden messages. That is not the sort of meaning I will discuss here though. Instead I am going to define it as the essence of all creations. When one make some sort of creative work there is always something that the creator wants to express with it. This can be to create a certain emotion, explore an idea, describe some events and countless of other things. It is this that I call "meaning". It can be shallow or very deep. It can be very obvious or extremely obscure. No matter its form, it is always there at the core of the work.

Different kinds of medium have different tools for expressing this meaning. When writing a book there are plenty of ways to do so (e.g. style and format) and the same is true for any other medium. When working in a medium a certain type of implementation is most often used because it will best express the intended meaning. This means that two works of fiction, using different implementations, can express the same meaning. For example, take the book Atlas Shrugged by Ayn Rand. This books tells a lengthy story, but its meaning is not the narrative but an explanation and exploration of Objectivism. The important thing here is that the story could be changed but the meaning, the essence of the work, would still be left the same. Further more, compare this with other non-fiction books written about Objectivism where the meaning can be very similar, but the implementation quite different.

Narrative
Basically, a narrative is a sequence of events and is (mostly) the building block for a story. I am aware that narrative, just like "meaning", does not have an exact definition and will therefore make it more precise in order to avoid confusion. When I say narrative, I mean a sequence of preplanned and connected events that have been laid out by a designer. The sequence can be branching and be told out of order, but it remains a narrative as long as the events have been purposely placed and in some way connect to one another. For many media, narrative plays a very large role. Pretty much all fiction books and movies use a narrative in order to express meaning and the craft of creating a narrative has been analyzed and evolved for a very long time.

Early games used the narrative structure to add more meaning, but mostly it was not connected to the interactive experience. Often the narrative was just inserted in between levels and had little to do with what the game played like. One of the first games that really connected narrative and interaction was Another World, where changes from cut scenes and gameplay where seamless. Also, most action that took place had relevance to the actual story. Since then the biggest step forward came with Half-life where the line between narrative and gameplay blurred to the point where the word "cut-scene" was not really applicable. Now the narrative was expressed without ever taking away the player's control and a great example of this was the opening sequence that told of events normally shown through non-interactive cut-scenes.

Half-life was released over ten years ago and there has not been many improvements since. In fact many games have actually not even started using the type of storytelling found in Another World and are still stuck at the level-to-cut scene-to-level-etc formula (While of course fine for some games, many could use the improvement).

Gameplay
Now yet another word needs to be defined in order to progress. When I say the word "gameplay" I will refer mechanics that have a goal. This means that mechanics on its own is not gameplay, but will become so when a goal is added to the mix. For instance, Mathematics is not a form of gameplay, but when a goal is added, such as solving a magic square, gameplay is created! Since a game can be defined as something that contains gameplay, this is the reason why I said that calling some interactive works "games" can be misleading and counter productive. More on this soon.

While gameplay are at the core of game making, it comes with a lot of baggage and makes certain meanings harder to realize in the medium. The most striking issue is the entire failure mechanism that is used in just about every game. You try a certain task, you fail and then have to repeat it. As described in other posts, this can be especially damaging in horror games, where repeating scenes seriously lessens the experience. This mechanism also impose limits on the player's rate of progress and effectively tells the player: "Either you complete this or you will not proceed!". Other baggage include the notion that gameplay must be fun and the need to constantly pose challenges. What I mean with the last point is that players assume that a game will always keep them occupied with some kind of obstacle to overcome. This leads to very little interactive content that is added for its intrinsic sake alone. Instead a game's interactive content almost always have some connection to the goals of the gameplay.

If gameplay has all this baggage, why is it used? The answer is simply that gameplay provides the same function an exciting story does in a narrative. It is an efficient way of keeping the player/reader hooked and engaged for the duration of the work. Also worth noting is that when a game does not have gameplay that is engaging enough, it almost always falls back on the narrative to keep the player hooked (as is the case in many adventure games).

To make myself clear here: I am not saying that gameplay is a bad thing. I am just saying that gameplay comes with certain issues and when applied to some meanings it leads to problems (such as the meaning to scare, which has been discussed extensively in this blog).

The Problem
Now to the heart of this matter and a discussion on what is wrong with all this. As said above, my main stand point is that having focus on narrative and gameplay is holding back interactive media's potential. It is now time to explain why I think this is so.

The main problem with a narrative is that it forces a linear experience and lessens the user interaction. It pressures that events should unfold, imposes a certain order on things and wants to keep a strict flow (e.g "prologue-middle-ending" and "character arcs") . These things work against the interactivity and freedom of the player. For instance, I have previously discussed how physics is very hard to add since players might mess things up and break the intended order of things set by the narrative.

Despite of this, there is currently a focus in games industry to combine gameplay and narrative. Perfecting this art seems to be some kind of holy grail. However, gameplay will never smoothly be part of a narrative and as noted by Jonathan Blow there is an inherent conflict between the two. Gameplay wants to give the player a challenge and sets up goals that needs to be overcome. A narrative wants to move things forward and is often highly dependent upon time and space. Simplified one can say that gameplay tells players to stay where they are and experiment, narrative presses the player onwards and wants them to obey commands.

This sort of conflict is highly obvious in games. Some examples are: making use of quick time events to fit certain events of the narrative (that does not work with gameplay), providing very linear paths and simplifying the mechanics. The end product is that either you focus on the narrative or you focus on the gameplay, making it impossible to be strong in both. This effectively weakens the amount of meaning that can be put into this combination and is why the market is filled with so many shooters and hack-and-slash games. Other types of meanings are simply not possible to pull off in this system.

Increasing focus on the narrative eventually creates a non-interactive medium. There are some very nice examples of narrative heavy games in Interactive Fiction (such as Photopia), but they all heavily cut down on the ability to control and interact (because of the problems listed above).

Gameplay by itself can also be used to created meaning and has been done so in games such as Gravitation. Again Jonathan Blow describes the problem in the lecture linked to above: when the mechanics are fitted for a certain meaning they might not work as a game and the slightest change will change the meaning. Obviously this approach works for some types of meaning (as in Gravitation), but it is very limited, especially if the game is supposed to engaging as well.

Interactive Experience
I am quite convinced (for reasons stated above) that there is a vast new world to explore if the interaction is in focus, instead of gameplay and narrative. Doing this is probably the only way to get away from having a majority of games that are just based on killing stuff. I am not against games with violence, but I think it is quite sad how overrepresented they are. Just check check the Game of the Year 2009 nominees from Gamespot - only two out of ten nominees did not have violence as the core experience. The two remaining on that list does not evoke much hope though, one of them is a car game and the other Sims 3 (although it was quite original 10 years ago). There really needs to be some change to this!

The first step is to get rid of the idea that a challenge is needed, at least in the way it works in today's games. This is why I said at the start that "game" is a bad word. Not only does it imply gameplay, but it also gives the idea that playing should be about winning. Because of this both user and creator have preconceptions of what a game experience is like. A user picking up a game will assume that there will be obstacles awaiting and the goal will be to overcome them. The creator will also assume that this is what the user wants and we got ourselves an "evil spiral".

Instead of having every challenge as a performance test, one can let the user just experience it. For example, navigating through dark tunnels can be creepy even if failure is not possible. All other media works this way and I do not see how the addition of interaction changes it. Just think about all of the horror games that does not have any player death in them and still manage to be scary (as discussed here). Just like when reading a book or watching a movie, there is a form of role playing going on and interactive works can use this as well.

Another way of overcoming the need of challenges is to have learning as a goal (discussed in a recent Gamastura article). An extreme example of this would be a "game" where players could skip a level at any time but was required to reach a certain degree of understanding in order to grasp later levels. Note that this would be far from what is expected of a game and I think many users would be very confused by the approach. This is another example why I think the word "game" simple does not fit (and is even greatly misleading!) for some interactive works.

As for skipping narrative, this does not mean that games cannot have stories. Instead it means that we need to rethink how stories are told. Many (sometimes most!) events in a narrative are there in order to express some kind of meaning. For instance, in a story about polar explorers some events might be needed in order to show how hostile and unforgiving the land at the poles are. In an interactive work, this can be accomplished through interaction with the environment, thus making these parts of the narrative unnecessary. What I am trying to get at here is that instead of replicating what is described in written form or shown on film, the focus should be on the meaning and how it is best expressed in an interactive format. I am convinced that goals like "creating a cinematic experience" are dead ends in terms of evolving the interactive medium.

Of course there is a still room for a narrative, but trying to copy the way it works in non-interactive media is wrong. The experience should be adjusted according to how the user interacts, instead of trying to control the user's interaction in accordance to the narrative.

I am not saying that gameplay and narrative should be skipped altogether. In some types of interactive works it might even be best to focus on them! But in order to be able to explore other kinds of meanings in the interactive medium, they cannot always be in focus. It is also important that we let go of some of the preconceptions that exist, both when "playing" and creating an interactive work. If not, we will miss out on a lot of rich and valuable experiences!

Some "games" like Everyday the same dream, Fatale and Dear Esther have begun experimenting with this sort of thinking, but I believe they are just barely scratching the surface of what is possible. This is especially true when it comes to using the power of interactivity, which the work listed are quite sparse with. Also, most works of this type have a certain avant-garde feel to them and I think it possible, and quite necessary, to use this way of thinking to create more mainstream works as well.

Our efforts
The above not only outlines a direction in which I think that "games" should evolve. It also describes a lot of the thinking we have had when designing Amnesia. As our project have progressed, we have moved more and more away from gameplay and narrative, instead focusing on the meaning we want to express. This does not mean that Amnesia will be absent of both gameplay and narrative though. It just means that they have been far from the focus during development. The goal (and meaning) with Amnesia is to create a disturbing atmosphere and expose players to concepts about the nature of human evil. All of the game's design has been built around enhancing these things.

Gameplay wise, we have never really thought about how we want to challenge the player, instead it has been all about creating a certain atmosphere and evoking emotions. No puzzle have been thrown in just to drag out on the playtime or just to pose an extra challenge. We have been very careful to make sure that puzzles have relevance to the story and the feelings we want to convey. The is also true for other gameplay elements, for instance how enemy encounters are handled.

There is a narrative in Amnesia (two separate actually), but instead of making an effort to have certain events at certain times, we have left it up to the player to explore and experience the story. In Penumbra we tried to make sure that the player could not miss certain plot elements, but we are taking a more "relaxed" attitude with this in Amnesia. The game is meant to be explored at a gentle pace and for the clues found to be carefully considered. We think this approach is more interesting instead of just spoon feeding all important information to the player. A vital aspect of the game is for the player to take a stance against things that are revealed and this is deeply connected with the way the game is played.

We are not suggesting that Amnesia is going to be a giant leap in the evolution of the interactive media, but believe that this way of thinking is a step the right direction. It remains to be seen if the finished game will benefit from it, but at least we are giving it a try!

When focusing on fun fails

Because of a past as sort-of-toys (explained nicely here and here) important features of games are: How "fun" they are, replay value and how long they last. Reviews often take this into account and in turn this makes developers focus a lot on making a game "fun", "replayable" and "long lasting". I think this kind of thinking (which I am at times guilty of myself...) can seriously hurt a game. I think designers shall focus entirely on what kind of experience they want to deliver and make that come across as effectively as possible!

I have mentioned in a previous article how making combat fun can hurt the experience in a horror game, especially if scaring the player is the main goal. Instead of trying to make the combat as frightening as possible, combat is often added with little thought on how it affects the experience and much more focus on how "fun" it is. So instead of making a scary horror game a fun shooter is created (which is not always what is intended).

I recently finished playing the second Professor Layton game and while I enjoyed it quite a lot, it also had the same kind of problem. It is quite obvious that Professor Layton has been designed to last long and that a great deal of effort has been spent on this. The game has several side quests (collecting pieces for a camera, making a hamster loose weight, etc) and none of these are really connected to the game's story. There is also many puzzles in the game (150 of them) and because of this a lot of them are just different versions of the same type or just really boring and unimaginative. I think that the game could have been a better experience without these extra bits. For instance, with fewer puzzles more focus could have been put on making the puzzles that the player do encounter more varied and exciting. Instead, many of the better puzzles are put in as extras or part of side quests and a play through focusing on the story will miss out on them. If the goal with Layton has been to give the player an experience of being a puzzle solving detective, focusing on making the game last longer has definitely made it worse.

The last example I want to give is from the horror genre and concerns Dead Space: Extraction (which Jens have been playing lately), an on-rails-shooter for the Wii. The game tries hard to immerse the player and create a frightening experience, but makes a serious error. To give the game more replay value and "fun", the player has to hunt for bonus boxes, some appearing for a very short period. This happens all of the time and has several negative effects. Cut-scenes becomes treasure hunting sections and instead fearing what might lurk behind the next corner the player focuses on catching goodies. Collecting these bonuses is of course optional, but having extra ammo has a great impact on the gameplay and bonuses also include interesting story material (in the form of audio logs). Worst of all, it makes the on-rails aspect a lot more noticeable. If the player just barely misses a bonus because of a change in view, the player will want the character to look back at the previous area. This creates a sort of struggle between player and protagonist, seriously reducing immersion! I think this a very clear example of how focusing on the wrong features creates a less compelling experience.

Of course games should not take too little time to complete or be absent of fitting replaybility. However, I think that it is very wrong when it detracts from the wanted experience. Making sure the game is fun, replayable and long lasting should not be a design goal in itself, but something that is added if possible.

Future of Adventure Game Interaction

Introduction
Interactions in adventure games has gone from written input (aka "text adventures") to todays mouse controlled (and often single-button-driven) games. There still exist text adventures though, although now called "Interactive Fiction", and here the complexity of interaction has increased instead of becoming simpler. It seems like the way of interacting has on one end gotten more and more complex over the years, while on the other end it has gotten more and more simplified. What I want to explore in this post is if this great polarization has made us miss out on other ways to interact in adventure games and in what other ways interaction might be possible.


History
Before moving on to the core of this post I need to very briefly discuss the history of interaction. It is always important to know the past in order to figure a way to progress in the future.

The first adventure game created was Colossal Cave Adventure, aka "Adventure", which was built on top of a cave simulator and featured interaction through text commands. After Adventure more text adventures followed and as time went on the parser became more and more advanced. The parser is what handles the text input and translates it into game commands and the better the parser the more synonyms and complex grammar is supported. A few years after the release of Adventure, text adventures started to get a graphics, but still had a the text input (like Mystery House).

The first evolution in terms of interaction was to add third person character and allow movement using the arrow keys. Text was still needed to do actions, but the player could explore the environments more freely (moving around in text adventures can easily become quite confusing). Examples of this type are the original King's Quest and Leisure Suit Larry.

It is important to note that the divide between text and graphical adventures started here. Texture adventures continued to evolve along their own path, getting more complex interactions, while graphic adventures instead started to become more and more simplified. Both types co-existed commercially until the early 90s when commerical text adventure games where pretty much extinct. Text adventures still continued to be developed by hobbyist though and has continued to evolved the entire time (now days called Interactive Fiction).

The next evolution was made in Maniac Mansion by skipping the text input and instead exclusively using the mouse (except for some shortcut keys) and a predefined verb list with words such as "Push", "Open", "Walk to", etc (all in all there where 15 verbs) . To simplify things further objects that could be interacted with had their name displayed when the mouse was over and right clicking carried out a default command (such as "walk to" an empty spot or "look at" a sign). This trend of interaction continued and was further evolved by cutting down on the number of verbs.

The next and most recent big step has been to take away the verb list altogether and restrict the possible actions in such a way that all the user has to do is to click on things that requires interaction. An early example of this is Myst and now days pretty much every adventure game use this system.

An important thing to note is that as adventure games have evolved with the interaction, the unforgivingness (mostly meaning how easy it is to die and get stuck in an unwinnable state) have decreased as well. This is of course due to improved design, but I also believe it has to do with the interaction systems. With more actions, there are also more ways to mess up. Text adventures actually tend to be more unforgiving than adventure games released in the same time period. Although it is certainly possible to make text adventures free of cheap deaths and places where player can get stuck (there are many modern examples of this), but the large space of possible actions makes it more easy to do so. More on this later.


Why simplicity?
The main (and probably obvious) reason for making the interactions simpler, is to make the game easier to play. For example, games like Samorost are extremely simple to get hang of. In text based interaction (especially with older parsers) one quite often ended up in a guess-the-verb- situation and having to pick from a list of verbs can easily become a boring activity. Also, text input requires a bit of knowledge of what kind of actions usually works and which doesn't. This makes text based games harder to get into for beginners.

When using verb lists much of the freedom from text input was lost and interaction could become the boring task of testing every word in the list against every object in a scene. This is similar to the situation of branching dialogs but mostly without without a fun response for a specific combination ("cannot push door", "cannot pick up lawn", etc are quite common). Because of this, just using a single command context-sensitive interaction for each object can even increase the immersion.

Another major reason for simplifying is that it makes the games more laid back to play. Modern graphical adventure games are often quite relaxing and one can easily lie down (or some other comfy position) while playing. Actually, requiring the player to use the keyboard seems to be a hideous crime in some gamer circles. We have even gotten quite a few angry emails regarding the "dated input method" in Penumbra.


Why complexity?
So if having simplified interactions makes adventure games easier to play and more relaxing, why add more complexity? Does the years of evolution from complex to simple not show the right way to go? I confess that this might be the truth, perhaps the current system is the best way to go and further enhancement should be concentrated around making things simpler still (like the evolution has been so far). However, I suspect that there is bias towards simplicity lurking and that the success of some titles have set the path for other designers as well. Before moving on to the reason for me suspicions, I would like to quickly discuss why I think increased complexity is a good thing.

My main motivation for increasing complexity comes from playing Interactive Fiction (ie "text adventures"). As stated before, this genre diverged from graphical adventures almost 30 years ago and has, contrary to graphical adventures, increased in complexity since. By using the rich space of actions provided by words, there is a lot of actions possible that are not possible in graphical adventures. A major feature is ability to use all senses: the player character (abbreviated PC) can "touch" an object hidden from view in order to get more information, smell the air for tell-tale signs of some gas, listen next to a door to overhear a conversation and more. It also allows for more intricate interaction, for example when holding a piece of paper it can be crumbled to a ball, folded to become a container or rolled up to act as a funnel. To include these actions in a modern graphical adventure game they would either have to be special cases (like a folding-paper mini game) or implemented as a default action in some situation (using the door when in cell makes the PC listen next to it). Both of these solutions are forced though and do not give the sense freedom that a text parser would.

Am I suggesting that we should go back to some older type of interaction? No, I am not. What I am suggesting is that instead of improving the interaction by simplification, some other route should be taken. Making a user interface better does not always mean making it simpler. Consider first person movements as an example. The first FPS games like Wolfenstein 3D had really simple controls, with arrows for moving and strafe modifier key for sidestepping. Later on games like System Shock made the controls more complex, adding the ability to look up and down and more. These where then made easier to use in Quake by using mouse control for head movements. Since then controls have become even more complex with leaning, crouching, etc. The controls for first person games have over time become more simple to use, yet more advanced and allowing greater interaction in environment. I think that the same could be true for the future adventure game interaction.


The problem with freedom
So, what should be the goal with interaction in adventure games? The first reaction might be to use some kind of virtual reality suite (or matrix-like brain connection) that can entirely immerse the player in the game, allowing any kind of interaction. I do not think this would be wanted though as a big part of designing a game is actually to restrict the player from doing certain actions. If the player picks up a very important key and then throws it into a bottomless pit, it will probably be very hard for the player to continue. Although a designer can add alternative solutions for situations like this, due to time and resources it will not be possible to add for every possible bad choice the player makes. It is also impossible to find all of these situations during testing, given the huge amount of choice a realistically simulated world would give. Some actions might seem so stupid that player deserves ending up in an unwinnable state, but this can be a really fine line at times (especially for a designer that knows how the game is "supposed to be played").

The problem with freedom is actually a lot easier to control in a modern point-and-click system. When the designer can exactly determine all possible actions, it is a lot easier to make sure that the player does not end up in an unwinnable state or manages to skip large sections of the story. This is a really important bit to have in mind when designing a new system and simply going for whatever gives the most freedom will simply not be enough.

Because of the problems with too much freedom, it might actually be harder to design puzzles for adventure games with high interaction complexity. When designing a puzzle in Amnesia the idea was that the player should open a door connected to rope throwing the rope through a pulley, tie the rope around a rock and then push the rock into a hole, pulling the door up. When doing this with physics as implemented in penumbra it simply was not possible without adding lots of restrictions. The stone should not be possible to push down the hole before rope was in the pulley and tied around it. Also, the rope should not be possible to tie around rock until it was pulled through the pulley. Restrictions could be added to make it work, but would make the game too inconsistent (it would the depend on the situation if a rock could be pushed or not, etc). Making alternative solutions is possibility, but cannot be done indefinitely (especially if the difficultly level of the solutions should be similar).


Future
The problem here is that more complexity is wanted, but at the same time the player must be restricted. How can these ideas be united? I do not have an answer to this, but have at least some ideas in what directions to start looking.

First of all I do not think it would be worth thinking about things that might be possible in the future. This would include things hooking up some device to the players brain or to have some kind of AI in the parser that could understand a wide variety of phrases and respond accordingly. I think it is more interesting to discuss what can be done now or even that which could have been in the past. When it comes to the evolution of first person control, much of it does not depend on technology and could have been implemented much earlier than it did.

A path that might lead fruitful results is the use of predefined verbs. The major problem with this was that they where always visible to the player and easily became an exercise in trying combinations. Text adventures are not far from this kind of interaction, since they too have a set list of verbs, but these are never visible to the player and because of this, they feel more free. So, the idea is simply to add some kind of way to use a certain amount of actions without listing them in view for the player. This can be done using mouse gestures which, if similar to the action performed (for instance: move mouse in a circle to spin something), could be quite intuitive. Even if intuitive, it would take some time to get into and would be far from as easy to pick up as the modern point and click mechanic. A sort of remedy could be to allow combinations of gestures to make more actions, requiring only a few base movement to be learned. An example would be that there was a gesture for each body part and then some other gesture for the type of movement performed. Of course this does not require mouse movements and key combinations is another alternative. Games that kind of use a similar approach are Loom and The Void.

Farenheit (and the upcoming Heavy Rain) has another way to tackle this problem: By having context-sensitive inputs depending on where the PC is. This system works pretty well to add a great deal of possible actions and the additions of "gestures" (this might stretch the definition, as I do not think calling button mashing a "gesture" is entirely correct) can add some simply gameplay and challenge to this. These gestures are quite nice at the start of the game, and gives the feeling of actually performing the action, but later on they get quite arbitrary and feel more like a chore. This system would work without gesture though and could just be a single button push or icon click (if using a mouse-only system). The main problem with the system is that it just like visible verb list boils down to a try-all-combinations-exercise (even more so than the verb list!). I think that for a system like this to work, the actions available need to be meaningful choices and not just different ways of interacting (which is also the direction Heavy Rain seem to be going).

Finally, I do not want to rule out physics even though we have had some problems with it. Physics work extremely well for objects that are in limited in their movements, like doors and drawers. It is much more complicated when it comes to stones and furniture that can be moved in any which way. I think that using some kind of hybrid system would be investigating more, but the focus must be on providing consistency. What works so good with physics is that it uses the simple and intuitive point and click input, but allow for a lot more possibilities. And that is something must be retained as much as possible.


Conclusions
Getting interaction in adventure game has taken quite a bit to come where it is today, both for text-based and graphical adventures. This means that finding another way of doing it will not happen over night, but will take a lot of time, testing and iteration. I do however think that it is something well worth exploring and although we will not have anything revolutionary for Amnesia we plan to give this some more thought and research for what ever game comes after.

If you know any adventure game that have an interesting way of doing interactions, please let us know! We are also very interesting in seeing what other people have written and of course hearing your thoughts about this!

On Versioning (or how the simplest thing can save you from the hardest pain)

Been there, know the feeling...

Long titles aside, this is no flashy post. Some will even find it a bit boring, but if at least one can learn anything from it, I will be happy. The motivation for it comes from an often overlooked issue. I now must tell how a work day can eventually turn out:

A freelance artist we are working with found this really strange and annoying crash bug in the LevelEditor. One point listed in the Luis's standard procedure manual when working with bugs says "first, check the logs, see if anything looks strange there", next one states: "try to reproduce, and work your way on from there". Happened that the logs looked alright, and no one in the team could reproduce the bug in their machines, me included. So neither of these points threw any light into the issue.

It started to look like I was staring at one of those errors that no one wants to deal with, caused by hardware incompatibilities or similar übernice stuff (oh boy).

A new log seemed to make Luis happy, showing some strange error when loading a temporary file. It warned that the file the editor tried to read hadn't been even created. This might sound like hint... but the way the editor works (it checks if the file exists before trying to read) certainly told me that it could not be possible. Frustration++ now (or for the non C speakers there, Luis starts to lose his temper a bit).

After a while of step-by-step execution debugging, unsuccessful thinking about the cause and some other shooting in the dark, a new log came in to my hands and, while it looked alright, it stank of "I fixed this warning thing like three months ago". Turns out that the freelancer was using a dusty old version. He updated and bug gone. Gñe... now I want my sanity back.

This longish story confirms a couple things:
- You must never assume your users have the latest version when they complain about some bug.
- You definitely need a way to identify what version they are running without needing to ask them.

One might think I'm playing Captain Obvious here, but the same kind of situation described above happens a lot of times. It is actually strange to see no new messages for a while in our tech support forum. And even stranger if they are about stuff we have never seen before. Most of the time they are already solved issues, and the solution for them is as easy as updating to the latest patch.

So, after learning this nice lesson, I made a little program that is called by the IDE on the pre build event, and updates a build-ID string (in the form of yyyymmddhhmmss, with y - year, first m's - month, d - day and so on... basically a timestamp of the moment the thing was built) that will then be hardcoded in the engine and apps, and appear at the first line in logs. I am pretty sure there already are better solutions out there for this kind of stuff, but I felt like doing it before any googling, and it didn't take long, so no big deal. At least it might save me from having to buy a little suit:

Our Random Crash Simulator 1.0, feels just like crashing for real!

That's enough for today. Remember to take care, and always version your stuff!
Also, merry Christmas and happy holidays everyone!

Level Editor Video - The Inside Scoop

Continuing the topic of my last post, here comes a post about the creation of our latest video...

What we wanted to do in this video was to show how quickly you can create something playable using our Level Editor. So we decided to take 30 minutes to build something, use another 10 minutes at most to do some gameplay scripting and then finally show it all in game.

To make it all viewable without spending more than 40 minutes watching a video we time lapsed it all down to about 8 minutes. While working on the video we also wanted to add a voice, describing what was going on, but it did not work very well. To make this properly, you should write down what you want to say first, then record and edit the material after the spoken text. So it got difficult to make a voice that would have enough time to properly say what was going on during the very fast level editing (due to the time lapse). As I was battling with this problem I had a chat with Thomas, who joked that I could "write it all in verse", which I thought was actually a pretty good idea. Then I could have some voice talking, making the video more interesting but not need to be overly specific in what is said, so it could be more freely added to the visual editing going on in the video.

It took me about 4-6 hours to write the whole thing for the full video and then another 2 hours to record and edit the voice. Then I showed Thomas the video...

He got a bit worried, with good cause, that the video could give the wrong impression about the game. Is the game a parody on the horror genre? Or what is really going on? So after some discussion we decided that we should probably skip the voice altogether and only add some nice music or else the video would go on consuming time we need to spend on the game!

To cut things short, here you have the final demonstration of our Level Editor! We have shortened it a bit, then removed the actual scripting part as we felt it looked more difficult than it actually is. But to give you all the goodies, at the bottom of the post you can find the script with comments, to give you a view of the amount of script needed (and to show that a lot of gameplay is done automatically by the objects in the game). I have also, for everybody's pleasures, added the original verse. It's not structured correctly but hey let us call it free-form verse.

Have you got any questions about the editing or scripting of levels for Amnesia? Shout them out in the comments!

The Video (our first HD release!):


Gameplay Script:
As you can see, if we remove the comments (in green) it is a total of 19 lines of script code!

// This is the initial setup that is done when starting the level
void OnStart()
{
// Check if Player enters the area called AreaExit, if so then do the CollideExit function
AddEntityCollideCallback("Player", "AreaExit", "CollideExit", true, 1);


// Check if Player uses any of the two keys on the desk or door if so do the UseKey function
AddUseItemCallback("usedesk", "key_desk", "desk", "UseKey", true);
AddUseItemCallback("useexit", "key_exit", "mansion_1", "UseKey",true);


// A timer that will activate a function after 120 seconds
AddTimer("enemy", 120, "TimerActivateEnemy");


// This says to play the music file 04_amb.ogg, that it should loop, play at volume 1, start with a 3 second fade, have a priority of 0 and that it will resume where it ended if the music is stopped and played again.
PlayMusic("04_amb.ogg", true, 1, 3, 0, true);


// Adds a quest for the player, escape is the name to use in scripts and XXVideo is an entry in the file that contains all the text for Amnesia.
AddQuest("escape", "XXVideo");


// As this level is for testing, we give the player a lantern at the start of the level
GiveItemFromFile("lantern", "lantern.ent");
}


// The timer function that is called after 120 seconds from start of level
void TimerActivateEnemy(string &in asTimer)
{
// Slide the door open leading to the room with the enemy
SetMoveObjectState("door_1", 1);

// Activate the enemy
SetEntityActive("grunt_normal_1", true);

// Play an extra sound to warn the player
PlaySoundAtEntity("enemyBoo", "notice", "door_1", 0);

// Give the enemy a patrol node so that he will start to move into the large room
AddEnemyPatrolNode("grunt_normal_1", "PathNodeArea_5", 0, "");
}


// Function for when using keys on the desk and door
void UseKey(string &in asItem, string &in asEntity)
{
// Set the entity(desk or door) to unlocked
SetSwingDoorLocked(asEntity, false, true);

// Remove the item used from the inventory
RemoveItem(asItem);
}


// Function triggered as player enters the exit area
void CollideExit(string &in asParent, string &in asChild, int alState)
{
// Show quest complete message, using XXVideo entry in the text file.
CompleteQuest("escape", "XXVideo");

// Change the map to 02_entrance_hall, player start in area PlayerStartArea_1
ChangeMap("02_entrance_hall", "PlayerStartArea_1", "", "");
}


Without further ado, a Christmas carol just for you:

Jens I am, Frictional Games I curse you damn -
"Bastard from hell, don't force me to tell!"

"You better sing it like a snake or else you won't get that cake!"

"OK, OK I'll spill it all!"

You see, I got a call during the fall... a dude handed it to me "Man, what can you do in 30 minutes short, using that editor of yours, I've heard its like snort?"

Lo and behold, I told. See you do it like this. Half an hour building the base, 666 seconds to script, not even taking a piss. To not bore you stiff, check my time-lapse I'm fast as a mastiff, pay attention or get lost in another HPL dimension.

With sets of 3D tiles, even kids will get smiles. Easy as copy that floppy a room is crafted, damn it might even get you drafted. Walls, windows, ceiling and floor comes in different flavours we all can adore, combine as it unfold, see how I build a top so gold. Press B to compound create, it will save you from being late.

Feisty as they are, Entities of many kind makes the world go round, what ever you can find, make sure to use them sound. At times like these, a light or two will surely brighten the mood, where art thou tease of a candle? Shine upon my wood so I can tweak it further, it can't look as if created by a vandal.

A bed or cradle to take a nap, drawers and a table, you know, we even have a horse stable. Crap! Thomas - damn you and your ideas, "write it in verse" your words gave me this curse! I hope the christmas sock has nothing but peas (this should rime with ideas).

It is all pre-configured, place it and you won't have to go figure. What the player can do, we have already turned to our attention, it works as I mention: Doors swing, drawers pull, boxes carry, if a berry found it can be eaten, it will even crunch as you munch.

Entities of light is best placed in the dark, it will show their proper mark. Some gameplay they have, with the player around it can astound - as the Tinderbox comes to use, sort of like a fuse. Paintings, paper and books you could have them all on hooks, but let's put them all at their proper places: Walls so fine with a painting of mine, a desk is best if placed below papers and pen, the book from the den fits perfect by the pillow, perhaps something about Willow? Where did I put my glasses? Argh, it did not rhyme with places, it must be time for tea, why those long faces?

Adding a chest for treasures to keep, it is as safe as it is true that a mouse says "meep". A key for a puzzle and tinderboxes, just for the dazzle, put them all in. Remember though, it will cost you a dime if you want to get them back, not gooey in slime.

In a closet so small, Santa will fall. We poked him with a stick, to really make him tick. Locked behind a door he can't get out, but as I'll later shout - we can script some dangerous code, letting him get out finding a node. Like bread crumbs Santa can follow, the player better hide in hollow or better yet! Escape the room avoiding Santa's evil bloom.

Speaking of which, let's brighten it all up in a hitch. Spotlights in windows, shadows will cast, a gobo can be added just as fast. Size and colour adjusted with ease, we promise you do not need to lease a professional. This has all been very visional, just one more thing. We need glory fitting for a king, rays from the windows to shine upon the gory inner part of our highly technical art. Tweak it back and forth, you can really make it worth by adding particles as pretty in the light as pickles are delight.

Let's continue on and write that script or else Frictional will throw me down the crypt!

Music, oh music, my kingdom for some music. With one line of code, some music will load.

Add a timer that when 60 seconds pass, a Santa will get on your ass. Add a noise, to make sure the player has a choice. I forgot it at this point, but later I will make the door open as though pushed by a spring joint.

With a few lines of code two keys of use will be. On a desk and a door both will see, that there is no stopping me. Writing code should be made with care, not like here - I wrote a lot but "SetSwingDoorLocked" would have made a perfect knot. Erase it all and do it proper while standing tall.

An area we placed, to check if the player is correctly paced. If they collide, we should take it with pride, load a new level and end the player's ride. Took it for a test. But quickly noticed what a mess! Some last minute fixes, should make it all work without any trixes. A patrol route here, a remove item there, it starts to feel polished, if only the player knows it all clear. As a cooking show on TV, I prepared some text in a file that will make it all worthwhile, with a big bong a quest is heard making the player follow the herd. One minute the timer was short, Santa came out furious and picky, I had to increase the timer in a quickie.

And so the carol reaches the final destination, the player's faith I won't even mention. Take a look, hope we got you on the hook!