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!

Horror Tip: Beacon

Name: Beacon
Type: Game (Windows exe)
Link: Download and short info
The core of the game is simple: You are trapped in a cave and need to escape. To do so one must go through gloomy caves avoiding darkness at all cost. Helping the player accomplish this are crystals that spread light and a mysterious beacon that moves around, illuminating the surroundings where it goes. The game starts out slow and then progressively get more challenging.

This is not really a horror game, but the way darkness is handled makes it quite interesting. First of all since darkness is deadly it serves as a sort of unseen foe and it is up to the player's imagination to decide what hides in the shadows. The brief and sometimes obscure text messages at death also add to this and leaves what happens to the player open for interpretation.

Even though the game is really simple in its graphics, the darkness makes one feel like there are more details than what there really is. Many times one gets a quick look at some creature passing by, hinting that there is a vast world hidden in the darkness. These brief creature appearances also makes one wonder what might be lurking up ahead ready to attack. Finally, the minimalistic ambient track adds greatly to the atmosphere and although very simple the game becomes quite immersive.

Closer to the end, the game gets quite unforgiving in the platform jumping, taking away some of the atmosphere. This is only true for the last few maps though and works nicely as finale. Added to this is a nice little twist ending. The games should take less than 30 minutes to complete, so make sure to play until the end!

Also worth noting is that the game was made in 48 hours, which is quite a feat!

As always, we are interested in hearing your comments!

Video Editing Hell - Linux to the Rescue!

I'm the proud owner of the oldest and crappiest computers here at Frictional Games. This is very unfortunate, to say the least, considering I'm the one usually recording videos of our work, editing and then publishing it. For the Penumbra games it worked pretty OK, for Amnesia it works surprisingly well to record videos, probably thanks to a much more polished and optimized game engine. But as online videos increase in quality it puts more strain on my poor computers and I bet that "Security Update" is a synonym for "Force User To Upgrade Computer", which really does not help at all.

I record videos on my PC using Fraps and CamStudio, the former for doing full screen capture of in-game scenes and the latter for partial screen recordings of the editors. These programs save in specific formats that I have to convert into other formats in order to import the videos into the editing software. I have not been really happy with the software that I have used for these conversions, VirtualDub, while it works it has problems using many of the codecs that I have installed, often resulting in error screens. My first step on this "Improve The Video Editing Workflow With Out Spending Any Cash On Software Or Hardware"-journey ("It vew wosaco soh"-reescha as the Swedish Chef would say) was therefore to find a new converting tool, should be the easiest thing to find in the world I thought. Hell no!

Video converters seems to be a typical piece of software that encourages it creators to add a lot of advertisements in them or to limit them a lot for the "free" part. Those that are truly free tend to be a bit too basic, while I'm happy to not have to tweak a lot of settings there is some essentials configurations you want to be able to control. It think I tried 4-5 different "free" converters until I finally found MediaCoder. MediaCoder is quite nice once you get past two obstacles. The first is that the homepage and download site is filled with advertisements, placed so that it is difficult to know if you are clicking on an advertisement or the actual link. This continues on with a lot of advertisement in the software itself, it gives a bit of a bad impression because you get worried that the software might be filled with spyware and the alike! But as far as I know it is not :) The other obstacle is that it is very detailed with settings and configurations for all the codecs. However, it has a nice setup wizard which smooths it all out a bit and once you have configured a codec the way you want you do not have to do it again.

I continued my "It vew wosaco soh"-reescha by looking into video editor options.

For editing I have been using good old iMove running on my super fast 1.4 Ghz PowerPC Mac. iMovie is simple and quite enough for doing our type of demonstration videos (infact all trailers for the Penumbra games made by us were created using iMovie). But as YouTube allows for larger and larger resolutions these days, the videos have been more and more time consuming to make, not to mention painfully slow on the interface when everything lags around, the computer struggling to render the previews in real time. The export of the final videos also take quite some time on that old Mac, when it was created there were no such fancy things has h.264 codecs.

This really led me to start looking into some options for video editing on my PC, a real monster machine powered by an AMD Athlon 2.2 Ghz (*sniff* Yes, I know, it's not really a monster at all). I searched long and hard to find some suitable free software, something that was not very complicated, yet feature rich enough to do the type of editing we have in our videos. I finally found VideoSpin by Pinnacle, which at first seemed to be pretty nice, but while trying to use it to edit our next video, it was clear it was way to simplistic. Of course there is Movie Maker, but that really didn't cut it either, so I searched long and hard but could not really find anything usable for Windows. But, for Linux there were 5 options that seemed very promising. I figured why not try some Linux editing, I do have Ubuntu installed too, so it would be easy to test some software.

I downloaded Kino, PiTiVi, kdenlive, Open Movie Editor and Cinelerra-cv (maybe LiVES too). Kino and PiTiVi was very rudimentary, Kino the better. Open Movie Editor was almost right but, I'm almost ashamed for it, it wasn't a very visually appealing interface. Cinelerra was promising, but the interface a tad to cluttered, not very pretty and for our editing needs too complicated. I was starting to get a bit worried, kdenlive was low on my list because it looked to be as simple as Kino and PiTiVi, but kdenlive really shined! It's about the same level as iMovie, a bit more functions and a killer with the amount of supported codecs (not a unique feature, but well implemented). I'm not sure if it was due to running kdenlive on the latest Ubuntu release or if it is a common problem, but it took a bit of tinkering to get all the codecs to work properly. I'm guessing the latest Ubuntu release as it has caused quite a bit of problems for our own Penumbra games.

I've been working with the software (converter & editor) during the day and after a lot of baby steps of testing I'm starting to get quite comfortable with them both. To summarise, the "It vew wosaco soh"-reescha was quite successful, it takes a while to get used to a new program but this setup is definitely an improvement over the old. At least it buys this dying computer of mine a bit more time until the day of doom. Our next YouTube video will also be in HD, making it our first contribution to the bandwidth monster.

What are your suggestions for good video editing tools for Linux / Windows?

Why Horror Games Suck!

Inspired by Ron Gilbert's article "Why adventure games suck" I decided to do my own list. To be fair I do not think that all horror games suck (in fact some are really good!), but there are some common problems that pretty much all the games have. These issues hold horror games back from using the medium's full potential and I am convinced that games can be a lot more scary and engaging than what we have seen so far.

I also want to point out that the Penumbra games all have their share of flaws from the stuff below and are by no means exceptions from the rule. However, it is always a start to notice what kind of flaws that exist, so that one can work upon fixing them. It is our goal that our upcoming game Amnesia will minimize on these sucky aspects! Now that I have lined up the mistakes, it would be quite stupid to step into them.


Control is taken away when things get scary
"The protagonist enters a seemingly empty room, starts looking around when suddenly a strange sound is heard from outside. Something is about to enter and it's time to hide. At this point the game removes the player's control and a cut-scene is started showing how the protagonist hides and just barely manages to remain unseen by the approaching monster."

This is a very common situation and I have seen it in just about every horror game that I have played. Just about when things are about to get really scary, the player's control is taken away. Why does this keep happening in games? It's been over 10 years since Half-Life skipped having cut-scenes and it seem rational that all horror games should be using this approach by now.
I think the major reason for still using cut-scenes like this is because a certain scenes requires "special moves" (like hiding) from the protagonist and/or will lead to a strange situation if the player does play along (tries to kill the approaching monster or similar). This does not mean that the cut-scenes are needed though and scenes can be rewritten or game mechanics can be changed to make it work. It is also possible to allow players to do really stupid decisions as long as they has been given a fairly good hint on what a good action would be. If some of the players insist on walking up to the man seen butchering his victims then just put them up against him in an unwinnable fight. Next time they should be a lot more careful...
Another reason for designers to add cut-scenes is because they do not want the player to miss something. In horror games this could mean a shadow briefly seen in the distance or similar. Often this is very sloppy design and some simple changes can make the shadow almost impossible to miss. Let's not forget that it is an interactive medium either and it is often trivial to add some line-of sight check and activate the shadow when the player is actually looking in that direction. Sure, a small percentage of the players might miss it, but that is something one has to live with when working in an interactive medium.
If one needs to have a cut-scenes in a horror game, then make sure not to have it during the actual horror segments. Doing that is like having Mario enter a cut scene when he is about to jump from one platform to another.


Combat is designed to be fun
Many horror games are fairly combat oriented and because of this a great deal of design time is spent making sure that combat is fun. If players will spend a lot of time killing stuff, is it not reasonable to make the combat fun? Unless the goal is not to make a really scary horror game then the answer to this is "NO".
If fighting the monster is the best part of the game, then this what players will want to do. In horror games, where enemies almost always are the main mechanics for making the player scared, this approach is counterproductive. Players are supposed to fear the monsters, but if killing them is what makes the game worth playing then enemies are bound to be a lot less scary. If one gains positive feedback whenever an enemy is encountered then approaching sounds might give a reactions like: "Oh, that might be an enemy! Goodie!". This is of course the completely opposite of what a horror games strives for.
But if combat is not "fun", then will it not be boring, meaning that the game will be boring too? I would like to answer this with a loud "NO" this time too. First of all, combat can be "unfun" for many different reasons and some reasons are better than others. For example, the combat still needs to be pretty fair, responsive and not feel too frustrating. A good way to make the combat feel unfun is by resources, an example being System Shock 2 where ammo is very sparse and weapons will degrade (and eventually break) whenever used. In Silent Hill (the older titles anyways) combat use responsive controls but aiming can be imprecise and a bit clumsy, making it feel more like a last resort than the basis of fun in the game.
These examples have their own flaws, but point at least in the right direction. Also, with all the problems that combat give rise to, one might consider skipping it altogether. Even though it might be hard to believe, violence is not the only way to drive gameplay...


Overusing the same enemy
Usually a monster in a horror game has some kind of spooky encounter at which they are quite frightening, but then an hour into gameplay, they have become cannon fodder. For some reason, designers seem to think that all hope is lost after this encounter and that they might as well scatter thousands of copies into the rest of the game. Or perhaps they think that if it was scary once it will be scary every other time too (embarrassingly, I am guilty of this myself in the past). Horror is tightly connected to the unknown and if something becomes too familiar then the impact that it first had will be lost. This means that for an enemy to remain scary, the way it is presented needs to vary and the player can not be exposed to it too much. Players will eventually learn patterns, what to expect and the moment this happen, pretty much all scariness connected to the enemy is lost.
I think the main reason that this flaw is present in just about every horror game is because content is so expensive and time consuming to make. Players need to have something to do when playing and the easiest way to do this is to scatter enemies around the levels. This is far from good horror design though and just leads to repetitive and predictable gameplay instead a truly frightening and engaging experience.


The monster is always shown
A well known fact in horror is that the audience's own imagination is the greatest asset. It allows the horror to be more vague and people to project their own fears into the experience. Because of this, many books and movies keep the monster hidden in darkness, not revealing its true form until the very end or not at all.
In games it is quite different. Sure, before a monster is shown there can be shadows and strange sounds, but as soon as it comes into play it's there in full high-poly detail (preferably with lots of slime and/or gore). It seems like horror games are way too anxious to show of the monsters and there are extremely few games that uses an unseen enemy as a gameplay device (and not just some foreboding ambient piece). I suggest that games should add proper gameplay mechanics to an unseen monster and if possible even refrain from showing it at all!
Some might wonder how an enemy that is not seen can affect gameplay, if it can hurt the player, surely it must be visible? I do not think this is needed and in Penumbra: Black Plague we had an enemy that was entirely sound based and never shown in the game. It was far from perfect and had a plenty of flaws but it is at least a step in the right direction. If horror is to reach new levels in games, the fear of the unknown must be used to the fullest!


The horror is slapped on as a side thing
The final reason why horror games suck sort of tie in to all of the above. For some reason it almost always seems like the horror is an afterthought in games. First the game main gameplay design is made (third person shooting, Myst-like puzzle adventure, etc) and then some kind of horror theme is slapped on top. Surely this is not the way horror games are designed, but to design the gameplay mechanics without considering the horror aspect seem fairly common. FEAR is the dictionary example of this where the horror elements are clearly separated from the main gameplay in a very obvious way. The player goes through a section of John-Woo-like shootouts and then after that is a horror section where a scary girl shows up or similar. It soon obvious that these scary sections never pose any threat to the player and the horror factor is greatly decreased. The combat also does nothing to increase the horror, instead it just lessen it by making the player feel everything but vulnerable as wave after wave of enemies are mowed down.
This divide in design is present in pretty much all games though and a lot of the gameplay is designed in isolation from the horror elements (as mentioned above, the most common thing is the entire combat system). I think this problem is fairly common in other games genres too. Instead of trying to combine the gameplay with the story told and feeling that are to be evoked, they are designed separately and then forced together. If games are to reach new heights in terms of telling stories and being emotional than this needs to be improved upon. One can not see the game as a story part and a gameplay part, but have to realize that they both need to support each other.

Until this happens in horror games (and other genres too) they will continue to suck*.

*or at least not be as good as they could :)

Horror Tip: Korsakovia

Name: Korsakovia
Type: Game (Half Life 2 Mod)
Link: Mod DB page (info + download)
Masterminded by the same guy that made Dear Esther is a highly experimental horror game about a man with Korsakov's syndrome. Its tag line goes:

"The paramedics report that they were unable to find his eyes. We think he may have eaten them."

If you like me find that awfully intriguing then go on and play the game now and read the rest of the post later!

I have put up posting a horror tip for Korsakovia for quite a while because of the simple reason that I have not been able to complete it! I have still not managed to do so, but thought it was time to make a post about it anyway. My inability to complete it highlights the strength and weakness of the game quite well: First, the game is quite demanding on your eyes and ears with a dark environments and extremely unnverving sounds at times. Secondly, the game is frustrating as hell as it is hard to orient oneself in the similarly looking environments and some gameplay parts are very unforgiving.

As said above, and different compared to Dear Esthter, Korsakovia has actual gameplay elements consisting on bashing (or avoiding) monster and some annoying first person platforming. Especially the platforming feels quite unfair and is awefully frustrating to the point where the otherwise excellently built-up atomsphere goes away. I feel that the game would have been a lot better without any of this gameplay and experiencing this makes the game extra interesting to play. It clearly shows how the player's attention diverts from being immersed to focusing on the game's mechanics when gameplay gets too frustrating.

What really shines in Korsakovia (and made me play it as long as I did!) is the haunting atomosphere and the script consisting of the protagonist talking to his doctor who may or may not be real. The game is quite abstract and there are no clear goals or motivations, yet it managed to captivate me and want me to play more. This also makes the game an excellent experiement in player motivation, as it differs quite a bit from other games. Finally, as noted above, the game is quite hard on the senses and is far from a fun experience, proving the point that games do not have to be "fun" to be engaging. Note that these "brain-fuck"parts of the game where not what eventually made me stop playing; it was the combination of that and the bad gameplay. Had the gameplay been more streamlined and solid, I am sure I would have played to the end.

In conclusion, Korsakovia is very interesting game from a design perspective and I urge you all to play it as long as you can stand it. However, from a gameplay experience stand-point I think it fails, mainly becuause of some unfair and extremly frustrating sections.

To play it Half Life 2 - Ep 2 is needed (I do not think the normal hl2 works). Download the zip and extract to "steamapps\SourceMods". Then start the game through steam.

Mandelbulb comes to Mac!

Finally, to end our fractal-odyssey, the MathFuncRenderer has come to Mac!

Get it here:
http://frictionalgames.blogspot.com/2009/11/fractional-fun.html

As with the Linux version, Edward Rudd is that man behind the port.

If you like it, please spread the word!

Important note:
Because of some strangeness with Nvidia osx drivers, the program is unusable on some Nvidia cards. 7300 GT under Leopard under leopard is know to have this problem, and there might be more.

Mandelbulb explorable in Linux

A Linux version of the MathFuncRenderer has now been built and uploaded!
All this has been possible because of our Edward Rudd who makes all porting for Frictional Games.

Download link and stuff in this post (scroll to end):
http://frictionalgames.blogspot.com/2009/11/fractional-fun.html

If you like it, please spread the word :)

Mac version is also in the works and will come very soon!

For those wondering where all development and horror related post are, then I promise there will be some of that very soon! Got plenty of horror tips to share and more :)

Fractional Fun

(Programs and Mandelbulb screensshots available at the end of the post!)

This blog post will not be totally game related, but more about the engine and a recent obsession of mine. Do not fear though! It should hopefully still be interested and I will also provide some nice images! Hopefully it will also be able to evoke a sense of wonder too. Read on to find out!

Ten years or so ago I wrote a paper for school about Fractals. These constitute a large variety of objects but what they all have in common is that they have several levels of self similarity. Nature consists of tons of fractals, for example trees and mountains. In games the term fractal landscape was quite common at time and was a way of generating terrain. Although not heard of as much today it is still a part of game making. Below are some examples of fractals, note how the same type of shape appears over and over again:
Now, while doing the paper for school I came across a weird thing called the Mandelbrot Set. This is a certain function that when iterated and mapped (drawn to screen) creates a fractal. The function for the set is very simple and is based around this formula:

N(0) = c N(n+1) = N(n)^2 + c

What this means is that one starts of with a number c, then multiply by itself and finally add c to get the next number in the sequence. If done with normal numbers, one gets something like this:

1 + 2 + 5 + 26 + ... and so on towards infinity

However, there is a twist to this formula when creating the Mandelbrot set, instead of using a normal number for c, a complex number is used. A complex number has a real and imaginary part and is written like this: c = 3 + 2i (the imaginary parts gets i behind it). When using the above formula on a complex number, it gets slightly more complicated and is (kinda) analogous to a 2d vector being rotated by itself.
Now, to get the Mandelbrot set, one "simply" checks if a certain c makes N go toward infinity or not. If it it does not, then it is part of the set. In practice one just iterates (does the same thing over and over) the formula a fixed number of times and see if it has reached a certain limit value. If it has it is said to be not part of the set.

Hopefully the math part made sense and was not too boring, but I felt it was needed for full understanding of what makes the Mandelbrot set so amazing. And to see why it is amazing one has to visualize it. This is done by letting c be a point on the screen where the x coordinate is the real part of the y coordinate the imaginary. Then one colors the pixel black if it is part of the set, and if not color it depending on how many iterations it took to reach the limit value. Doing so will generate this picture:

Click here for large version.

I gotta say that that is a pretty damn detailed picture one gets from just iterating some boring function! If someone had just shown me the formula I would never have guess it could produce such a wonderful result!
It gets even better still! If one zooms in on this image, the details just keep coming and they never repeat! As with the other fractals same kind of shapes return again and again, but never in the exact form. The beauty of it is breathtaking! Here are some examples of zoomed in parts:

Large versions: here, here and here.

When I made my own Mandelbrot program I could not stop searching the set. It felt like I was exploring some kind of alien world and it feels so weird that such a simple formula can create a cosmos of infinite detail. If you want to explore it yourself, here is a pretty nice web application for just that.

Fast forward to present day. Last Friday Luis sent me a link to this page of someone who managed to create a 3d version of the Mandelbrot set. Naturally this was irresistible for me and inspired by the works of Iñigo Quilez (I had his presentation "Rendering World with Two Triangles" as a reference throughout this project) I set out to create a real time application that could explore this world .

My idea was to use some kind of ray tracer to render out depth, then use that depth to generate normals and just plug that into the deferred shader and let it add ssao, nice light and fog. I thought about this for a while and came up with the idea to use the same method as when rendering high quality parallax. This technique is called relief mapping and works by first making a rough linear search for an intersection and then a binary search to pin the exact location down. Hopefully this would prove fast enough to do a nice 3D Mandelbrot in real time! What I ended up with was an algorithm that could render arbitrary mathematical functions, so I tested this on some functions and got pretty nice results:

Some metaballs rendered and animated. This is not the fastest way to do this, but proved that stuff worked!

Here is an animated "Sine Landscape" that is just a bunch of sine curves added together.

What was left now was to attack the Mandelbrot set! The formula for getting hold of the 3D version is a little bit different from the 2D one and is not really THE 3D Mandelbrot either, but it surely the closest I have seen! It was discovered by Daniel White and works by using spherical coordinates. Remember how I said that the 2D Mandelbrot formula was kind of like rotating a vector by itself. Well, in the 3D version one rotates a 3D vector around itself by using spherical coordinates instead of polar (skipping formula, but if anyone is interested I can give more details!). Also, to make it look good in 3D, one has to have a power of 8 in the formula, meaning that one spins the coordinate around by itself 8 times!

It took quite some time get this working as the 3D-card did not do what I want to and so on. But finally I got it all working and boy was it worth it!!! Here are some screens:

At the edge of a hole. Perhaps some strange creatures live in those burrows?

This is a 3D version of a Julia set! Looks like some alien space ship flying through the vacuum.

Once I got this far I could not stop using it! It was so much fun exploring the weird world of the 8th degree Mandelbrot fractal! Because of some limitations in the ray tracing method I added a new version of the renderer that builds up the image in slices and can use a lot more iterations when checking if it is in the set or not (more iterations = more details). It is slower, but creates more details in the images and it is fun to use it when one discovers some extra interesting shape and want it enhanced. Here is a video of me exploring the set:

Now the best of all this is that YOU can explore this strange world yourself! To do so, just download the MathFuncRenderer and get going! (ShaderModel 3 capable card required) Windows, Mac and Linux version below.
Note that you need OpenAL installed for it to run. Get that here:
http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx

Winodws:
http://unbirthgame.com/MathFuncRenderer.zip
(Link might change so please do not hotlink)

Linux:
http://unbirthgame.com/MathFuncRenderer-Linux.zip
(Link might change so please do not hotlink)

Mac:
http://unbirthgame.com/MathFuncRenderer-Mac.zip
(Link might change so please do not hotlink)

(Also note that because of some nvidia driver issues in OSX, some nvidia card will not work properly, 7300 GT on leopard is known and there might be more.)

I am very anxious to see what kinda of strange pictures you all can take so have opened up a post for this in the forum. I have already posted more of my own images there.

http://www.frictionalgames.com/forum/thread-3044.html

The struggle between Light and Dark

When making a horror game an important ingredient is the darkness. When in a dark place people tend to be more easily spooked and have a more vivid imagination, a genetic heritage passed on from our ancestors who were hunted by predators at night. Taking advantage of this is important and just changing the light level of an environment can make a huge difference in the scare factor.

Of course one cannot just turn off the lights and hope to make a scary game. The player still need to be able to see something, as watching a pitch black image is not all that exciting. The appropriate amount of light also depends on the type of environment and the type of events that will take place. If the environment is very large, then it might need to be brighter, whereas smaller rooms, where it is easier to navigate, can be darker.

Added to this the player is usually equipped with some kind of lantern or flashlight to help illuminate. In Amnesia (and the penumbra tech demo) the player has a vague light around her to help make the closest surroundings more easy to see. Penumbra Overture and Black Plague had a large blue help light when sneaking in darkness, although this had the problem of illuminating too much. Finally another trick is to add "fog" that gets blacker the longer the distance and this gives a the darkness a more thick and oppressive feel. This was used to great effect in the first Silent Hill game and gave the added visual effect of enemies emerging from the darkness a head of you.

Once starting to implement this, a huge problem appear: Darkness is Subjective! This means that a certain area willseem to have a different light level depending on who plays it and how it is played.

The first problem comes from the monitor itself and depend on:

• Light level of the room.
• Settings on the monitor.

This means that depending on the current setup at a player, a scene can look vastly different. The only way to get around this is by some sort of setup screen. Ever since I made Fiend I have been obsessed by this and always make sure to do preparations when playing a horror game. The problem is that most games do not provide with any such screen and when they do the setting is often far from optimum and makes game way too bright. I cannot understand how game developers can miss something as important as this and wonder if they ever did any tests in a dark room when creating the adjustment screen (or even played the game using the purposed settings). It is even worse with movies and although I can not think of anyone who has raised this problem before, it can make a huge difference when watching a horror flick.

As implied above, I think it is essential to have a good light level setup screen for a game (and would like it for movies). For Penumbra we had an in-game gamma value that could be tweaked and also a test image to calibrate against. There were however two large flaws here. First of all the judgment required ("Make this screen barely visible") is a highly subjective! Instead we should have had some simpler and more accurate test and in Amnesia we will have two squares of different light levels, where one should be visible and the other not. This is far from perfect, but avoids some of the extra subjectivity. Secondly, gamma is not all there is to it: changing the contrast makes a large difference and can make the calibration image fail. There is also the actual brightness to be change which of course also make a large difference. To make matters worse these three values (gamma, contrast and brightness) affect each other too.

The problems does not stop there though! It also turns out that the apparent light level changes depending on the light environment it is in. This illusion clearly illustrates the point:

Although it is hard to believe, the squares A and B are of exactly the same light level! A game example of this is in Silent Hill were the background light level looks much darker when the flashlight is off than when it is on. This means that when you setup your monitor to look good when flashlight is on, it looks too bright when it is turned off. The game developers should actually have decreased the ambient light when the flashlight was off in order to give the best effect. Another example is how a game can look much darker when running in windowed mode because of a brightly colored desktop image (note: windowed mode usually do make a game objectivly darker, but this problem can add to the effect).

So how to solve this struggle between light and dark? For developers it is important to always check a settings screen and adjust gamma before testing the lighting in a level. And to do this properly there must off course be good tools for doing just that. Another important thing is to always try the light level of a map in different ways. How does it look when the flashlight is on, when it's off, what happens when the fog comes rolling in, etc. Changes in the environment and gameplay can greatly affect the perceived darkness which in turn can have great effect on the game's ambiance.

It is also upon the players to make sure that they set up properly before playing. I have read several reviews where the reviewer claimed that the game was too dark and one can wonder if they really had set up properly. One can also wonder if the makers of the game gave proper direction on how a good set up would be like! There needs to measures taken on both sides to assure that a game can reach its potential to frighten.

How do you go about with setting up monitor gamma and so on? How much thought have you given this in the past?

The dull side of it - Part 1.

"Jens, I really need to read an email, but the email queue is taking forever to download! It's some guy named Brian that has sent a huge file as an attachment, probably 1MB. If not more!"

The other day I came to think of the above situation, when my dear father was in the need to read some email on the family computer back in 1997/1998. A few days earlier I had come in contact with a fellow named Brian Greenstone who was working on a freeware game and had asked on a game news site if anyone was interested in helping him. I volunteered to try and make some music. I was 18 and studying music during my final year of high school, with a life-long interest in games I thought this was a good opportunity to combine the two interest of mine. We discussed over email and he sent me the test builds of the game as simple attachments and I in turn sent my attempts at writing music back. My family had a 14.4 Kbps or maybe a 28.8 Kbps modem and sending and downloading those attachments took a little while... But that was how Brian worked with his game (and the following games too!), all content, as far as I know, was passed back and forth between the people working on the game using nothing but email.

As I thought about it I figured that maybe some interesting blog material could be found here. So, a couple of blog posts will take a look at how we have organized it here at Frictional and hopefully give a tip or two to those in a similar situation. To kick it all off I'm going to quickly go through how the company deals with daily communication among its members.

Frictional consist of five people, four live in Sweden, one in Spain and we do not have an office or place where we regular meet. We do all the work on our games from our homes and by using typical programs and technologies, all which are free. Much like other companies our work hours are from 8 in the morning to 5 in the evening and it is required that you are online on MSN during that period so that it is easy to get in touch with each other. While we also talk over the phone and through email, MSN is our main tool for daily communication. The exception is on Fridays when we meet up over Skype for our weekly meetings. The general idea is that news regarding the company (perhaps we have had a successful weekend sale) is shared to all the members and that all members do a quick "This I have done lately" presentation.

We split up our work in three week periods, where two weeks are the main period to work on a certain task and the third week is an extra week. The extra week is used to make sure there is time to compensate, should a task have had some problem or taken longer than two weeks. If anyone managed to finish within two weeks, the third week is used to work on some special assignment, usually something that is a bit more interesting and fun than the normal tasks. Should it be me, perhaps I spent two weeks making footstep sounds for 5 types of surfaces and on the third week I can instead work on making the sounds for a monster (which should be more interesting than walking on surfaces). On the Monday and the end of every three week period we have a "Show and tell" meeting on Skype where everyone has documented what they have done during the week and everyone can test it out (some gameplay, a new editor feature, new level etc). We spend 1-2 hours testing each others work, write down feedback and pass it to the creator, followed by the voice meeting where we give the most important feedback and discuss it.

That's pretty much it, only put on repeat! There is more work with the actual organisation and project planning, all the work that relates to who does what when and so on, but that would make this darn long. For next post I'll talk about the system we use for file sharing, we have used the same system since 2006 and have had some different solutions on where it has been hosted.

The Haunter Of The IGF

After lots of work and little sleep Frictional Games have entered into the IGF, an international competition for indie games, with our upcoming horror! The game is still a while from being completed, but the build we sent in to the competition is a very important milestone and the first version that gives of a taste of what the full game will be like. When creating a horror game gameplay needs to be tested over longer periods of time (because atomsphere, etc requires long build up) and testing the IGF version of the game tells us that we are on the right track!

At the start of the next year we will see if we managed to get nominated! In case you are wondering, Penumbra Overture entered the 2008 competetion (no nomination) and Black Plague did not enter in 2009 because we had financial backup from a publisher (i.e. not indie). Now that we are back as full indie we can enter again!

Now its back to work again!

Brain slugs sure are great motivators!
*Must... serve... hive*

Puzzles in horror games. Part 7.

Now it is time for the final part in these series on puzzles in horror games! This post will be about some puzzles in Penumbra that I personally find especially interesting. Because of this, the post will be filled with puzzle spoilers so if you are planning on playing any Penumbra game and have not yet done so, do so before reading!
First I am going to go through some basic guidelines we had when designing the puzzles though.

General puzzle design
Our main rule when implementing puzzles was something we called the "Island approach". What this means is that all things needed to solve a puzzle are located in the same area, the "island", and connections between islands should be very few and quite obvious. An example of this kind of connection was the hand and head needed to open the door the in residential area in Black Plague. The puzzles to get hold of the head and hand where both confined to their respective islands and where then linked together, hopefully obviously, at the biometric panel.

I think we managed to stick by this rule pretty well and it was just some instances, like at the end of Overture, when the connections became a bit too obscure. Considering the feedback we have gotten, the appraoch worked quite well and the island approach is something we will use for our upcoming game too.

Having gotten some critique after Overture that there where too many locked door puzzles, we set out to minimize the number of locked doors in Black Plague. Our main goal was to not have a single key-and-door puzzle and while we did not fully succeed, it did force us to come up with more interesting obstacle than we probably would have otherwise. Also, when having a locked door we tried to mask it as much possible or at least make it a bit more interesting by using other means of opening it. It was also interesting to see how many obstacles that boiled down to locked doors when one thought about and how hard it was to not include them.

Now for the puzzle examples:

Invisible Ink (Overture)
This started out as a puzzle where the player had to read a note written in invisible ink by using a uv-lamp and then our writer, Tom, suggested that the uv-lamp should also show text all over the walls. I really like how this combined the puzzle element with a strong horror event and from feedback we got it, people seemed to consider it one of the most frightening moments in Overture.

Exploding Potion (Overture)
At the end of of the game, the player needs to clear a cave-in by using homemade explosives. This is done by first mixing something called Armstrong's Mixture, a highly sensitive explosive, carry it through an "obstacle course" and place it at the cave-in. A fun fact is that we had to censor the real receipt for the mixture as we had to get a 16+ Pegi rating and our publisher where worried that learning kids how to make bombs would give it a higher rating. This is also the cause why dextrin was renamed to the nonexisting substance "baxtrin".

The puzzle was supposed to be solved by looking up the mixture in a book found earlier. However, it was made harder by not properly labling the chemical and a kind of cypher had to be solved. Because of some bad design in this, many people did not make the right connections and got stuck at it. Luckily, there where only 6 different chemicals and it was easy enough to solve it by brute force, something many seemed to do.

Trying to get the chemical past the obstacle course is a favorite of mine. I think many did not like it as it could be quite frustrating, but I think it did what it was intended to. It was quite tense and worked as a sort of physical endurance test as it could be quite exhausing to keep the mouse pressed down, knowing that releasing it for only a fraction of a second could make the solution explode.


The Blood Lock (Black Plague)
When designing Black Plauge another goal we had was to give the puzzles themselves a horror feeling. This puzzle does exactly that and connects quite nicely to the story giving the player some forshadwing of things to come. It is also an example of a locked-door obstacle that we tried to make more interesting and less generic. The desing of the device, where the player needs to inject blood in order to unlock a door, is not very realistic though and a silly way to lock a door in a facility overrun by alien creatures. Player's did not seem too bothered by this though and I think that as long something fits the game world and is fun enough, one can take a bit of implausibility.

The Cryogenics Chamber (Black Plague)
This is another puzzle where the element of horror was used as a base for design. To complete the puzzle the player had to nearly kill himself (making Clarence very disappointed) and then grab a severed head from a thawd cryogenics container. Hopefully this helped sending some chills down the player and still worked as a puzzle.

The Tuurngait Trials (Black Plague)
What made this series of puzzles different from any other puzzle in the Penumbra series was that it tried to convey an idea. The main goal of these puzzles was not to challange the player mentally but rather to have her think as a hivemind organsim and learn to see things their way. This was quite experimental and many people either did not get the theme (and just saw it as some puzzles) or thought that the whole section was out of place. A few people seemed to get the message though and this was very fun for us as we where worried nobody would like it. The segment was far from a success, but was at least a fun experiment and given that some people got the point it might be worthwhile to try the approach some other time (if we do, it will be in a totally different way though...).

Camera Puzzle (Requiem)
This puzzle starts the second leve andl is worth mentioning as it is probably the puzzle with the most possible solutions. The player can choose to take a different path at the beginning and if she decides to tackle the camera head on there are at plenty of ways to do so. Jens spent a lot of time with the puzzle and I was not aware of some of the solutions until after Requiem was released. This puzzle also shows that physics does not mean that puzzles have mulitple solutions "built in", instead it requires time and hard work to implement them. We put more and more time into this for each release and Requiem contains more multiple solution puzzles than the other two games combined.

That marks the end of this post and the horror puzzles series. Hope you all enjoyed it and at least gotten something out of it! As always please tells us what you thought about it and what you would like to see in the future.

For those of you who have not checked all parts. Here is a quick round up:
Part 1: Why are puzzles so suited for horror games?
Part 2: Common problems with adventure game puzzles.
Part 3: Why physics puzzles is not the "promised land" of adventure games.
Part 4: Backtracking and why it is essential.
Part 5: Things to consider when desinging puzzles.
Part6: On "brain boosters" and hint systems.