Horror Tip: All Alone

Going to start of a new, hopefully, weekly feature on the blog called "Horror Tip". This will be tips of lesser known games, books, movies, etc with some kind of relation to horror. Hopefully it will give you all some entertainment tips! First out will be a small game called "All Alone".

Name: All Alone
Type: Game (Interactive Fiction)
Link: Info and download
All Alone is a short work of Interactive Fiction taking place in an apartment a rainy night. It is very atmospheric and I think it gives a good hint on what is possible with pure text in a game. Make sure that you play this game in a dark room and perhaps with some spooky ambient track in the background.

If you are new to Interactive Fiction (IF) then a guide can be found here. Basically IF games are text adventures and you type the actions you want to do. This gives a very special feel for the game and gives lots of options for the player in what actions can be done. It can also lead to annoying "guess the word" type of puzzles, but good IF games keep this to a minimum.

To play IF games, one almost always need an interpreter, which is a program that runs the game file. All Alone requires TADS 2, which can be downloaded here.

Hopefully this will get some people interested in IF and if you found this a good tip, then I will continue to give tips of more good horror IF games. We are also interested in hearing what you think of this new feature!

Obstacles continued

In this post I would like to expand on some of the things that where brought up in the last post on obstacles. I am going to go through some of the steps involved in coming up with an obstacles and problems encountered.

Normally what we start with is having some kind of general journey for player. This could be something like this (a lit more detailed though):

The player starts at the pirate island and must then steal a ship to get the jungle and rescue his loved one.

This is then built upon step by step and ends up as detailed designs of each level. Now lets say that I now have to design the levels inside the skull castle on pirate island. Because of story reasons I now need to fit in the following levels:

• Treasure chamber
• Torture room
• Drinking hall
• Fencing hall

When trying to fit these levels together I can do it in various ways. It could be a linear progression like:
Treasure chamber -> Torture room -> etc...
Or I could use some kind of hub structure. A way to do this is by having a great hall (acting as a hub) that all of levels connect to.

Designing the basics for these levels are by far easiest in the linear progression. Here one can have an obstacle blocking the path between the current and next level or it could be as simple as just reaching the end of the level. Adding an obstacle is easy because there are no real constraints and just about any type of puzzle fits as solution.

In the hub structure things get more complicated. Here there must be some obstacle in the great hall that require the player to visit all of the levels it connects to. A way to solve this is by spreading the solution to all of the levels, like a door that needs four keys. Another solution would be to have the levels relying on each other, for example to enter the torture room the golden spear from the treasure room is required.

In terms of gameplay experience these two solutions varies a quite a bit. The linear progression gives a very, uhm, linear feel, but allows for a more fine-tuned and scripted experience. The hub structure gives more freedom for the player to explore and a less linear experience, it is also harder to script. In the Penumbra games we use a mix of these two types, to give the game some variation and try to use the strengths of both types.

Coming up with puzzles for overcoming the obstacles also vary from the different types. In the linear progression it is simple to add multiple solutions, and it can be possible to let the player complete the puzzle without exploring the entire level. For hub structures it is much harder to do some kinds puzzles, like those having multiple solutions. If the player can solve the puzzle in the great hall without visiting any of the levels, a lot of story and gameplay might be skipped. Coming up with one puzzle that requires the contents from all levels is hard enough, so you mostly have to live with having one unique solution to these puzzles. This also puts further constraints on the obstacle, as it is not very good if the player can come up with many alternate solutions that would overcome it. In that event the obstacle will seem too artificial and immersion is broken.

Note that there can of course be sub-obstacles blocking the path for the different parts of the great hall puzzle. For example the player might need get to a golden hook from a pirate frog in the treasure chamber and this puzzle have far less restrictions. That does not take away the problem with the puzzle in the hub though.

Hopefully this has given some insight into how we (or at least I) go about creating levels and the problems with obstacles encountered.

What are your thoughts on these problems? Know any more problems that might arise or perhaps any more solutions?

The problem with obstacles

Even though freedom is something of a buzz words these days in games, most games needs to restrict the player somehow. This is especially true for various types of adventure games where the player must be guided along a story path. In this blog post I will call these restrictions "obstacles" and will briefly discuss the various design problems connected with these.

First out I want to start out with an example of some obstacles from Penumbra. In Black Plague, after the player as managed to escape from his cell and get to the residential area, we wanted the player to search the area, find notes and solve puzzles. In order to do so we need to halt the player's progress and this was done by a door needing biometric input in order to open. To do this the player must collect some body parts and these are in turn blocked by other obstacles that need to be overcome (another locked door, corridor with gas, etc).

The big problem we have had when designing things like this is to make the obstacles seem well placed, fun and varied. Unfortunately it often boils to having some kind of locked door. And as we all know, while fitting, locked doors are not that exciting. If locked doors can not be used, what can? Below follows is a list of some different types of obstacles:

• Object. This is things like doors, bridges or other man made things that are blocking the players path.
• Environmental. There are obstacle that somehow limit the player movement and include holes, rivers, fires,etc.
• Character. This is normally seen in old point and click games. Some character is blocking the players path and requires something to let the player through.
• Enemy. A deadly creature of some sort that blocks the player path.
• Motivation. The player character does not want to continue because of some personal issue. Perhaps the road up ahead is too dark.
• Hidden. The path that the player needs to take is not yet visible. For example a portal that magically appears after the some condition has been satisfied.

I think these pretty much sums up all of the obstacles that are found in games. Also note that sum of these overlap, for example a robot guardian could be classified both as object or enemy.

For games like penumbra the game mechanic sets limit on what kind of obstacles that can be used. For example characters did not work because there where no real dialog system. Other games might have other kinds of limits. In some games it might not be a problem if the types of obstacles are not varied as it is part of the basic gameplay. In adventure games it is very important though, and only having one kind of obstacles (like always facing locked doors), makes the game feel repetitive and boring.

After releasing Penumbra Overture, we got some critique that the game contained too many open-locked-door obstacles and tried hard to fix this for Black Plague. The first thing we set out to do was to the skip simple locked door obstacles and if a door was needed we tried to make it interesting. In the example above we used a lock that required human parts to be opened and even though it was still a lock-and-key type of puzzles I think people considered it much more fun. The final game still contained obviously locked doors and we tried to limit this. However, we found it very hard and where not completely pleased at the end.

For Requiem we completely skipped trying to come up with interesting obstacles and instead focused on puzzles. In Requiem a portal always had to opened using some strange orbs in order to progress and this made the rest of the gameplay a lot simpler to design. At the same time it was apparent this was not good for an adventure game and player responses showed this. By using the same type of obstacle throughout the entire game a lot of the adventure feel was lost. This is especially true, like in Requiem, when obstacles are not part of the story either.

What are your thoughts on the obstacles in Penumbra? Know any game with really good or bad obstacles?

Maps with s-tile

The tool guy is back with some more dirty inside secrets on the development. This post was meant to talk a bit about the Level Editor, but first I need to tell you about something you might not know... and it's called tilemapping.

The term tilemapping refers to a technique born in the mid 80's or so, back when videogames were pretty much down to 2D. These games used 2D images to represent the game world and entities in it. A 2D image is, in a nutshell, a grid of color values or pixels, with the following parameters:

• Size in pixels (width x height): these values tell how big our image is - 64x64, 320x200, 1280x800...
• Color depth/bits per pixel(bpp): precision used to store an individual pixel in the image - 8 bpp, 16 bpp, 24 bpp, 32 bpp. This parameter pretty much depends on the format we are using to display our image.
  

To understand the need for such a technique, we have to think in terms of the hardware available back in the day. We are talking about machines with veeery limited resources, i.e. real slow CPU's and quite low on memory (far from a single megabyte), so one had to be really careful and always keep an eye on those limits when developing... and even more if developing a game.
Many older 2D games out there display a quite big and detailed world where the game action takes place, and with big here I mean many times the screen (Turrican's huge maps being a real good example of this). So, let's do a simple example:

1. Figure our system has a graphic mode with a screen size of 320x200 pixels and 8 bpp for color depth (and we are talking high tech here).
2. Now, we want our game to have maps with a moderate size of 960x200 (that's only three times the screen width). The first solution that comes to mind is making a 960x200 drawing that represents the map. Doing the math, that is 960*200*8 bits = 960x200 bytes = 187.5 KB in memory at runtime. Not that much, I agree, but back in the day we could have limits like 256 KB in our main memory, so in this case we would have little room left for the rest of the game data (not to mention the worst and most common case would actually be having even lower limits and much higher needs)

So here's where the tilemapping technique comes in. The technique itself is rather simple: we have an array of small (e.g. 16x16, 24x24,...) images called tiles, containing all the graphic details we need in our level, plus a 2D collection of integer values (almost like an image), which would act as the actual map, indicating which tile goes where. In our example, using a moderate set of 20 different 24x24 tiles and a 20x9 sized int array, we manage to build a big enough map to fit our needs, with a cost of 20*24*24 + 20*9*2 = 11880 bytes = 11.6 KB. Now that's saving memory, don't you think? ;).

Although nowadays we have tech advanced enough to kiss tilemapping goodbye, it's still used, specially in games for small and limited devices such as cellphones and hand-held consoles. Actually,Fiend and Energetic use tilemapping for levels :)

Little 2D horror gem

The Energetic map editor, in all its glory

After having bored you all with all this seemingly pointless babble, I'll tell you how most 3D games do for levels. There are many ways of having a 3D world. Most common is creating a huge 3D model in the modeling program of choice, that is all the geometry and texture mapping done there. While this is cool, any 3D artist out there would say it is a pretty time-consuming task, and doesn't allow much reuse of stuff.

I know it looks untextured and that... but does this ring a bell?

What we are doing in Unknown is to create several sets of 3D pieces and make maps using them as building blocks. One can have a production-quality map in less than four days with this method, and thanks to the excellent job from our artists, the results are really nice to the eye as well.

Quite impressive what you can do with such simple pieces I must say... kudos to Jens

As you might have noticed, there's quite a similarity in both cases. We can make a close analogy between the big 2D drawing and the huge 3D model map, and our current mapping method to the ancient tilemapping technique, although our point is not related to saving memory really, but to save time and sanity. Still, our technique allows for more flexibility, such as going back to the "huge 3D model" totally (by creating a piece containing the whole map geometry), or partially (just a room). Also, we have a grid, but only to ease the task of aligning pieces, so we are not constrained by it.

There's little left to add really. I hope this served at the very least to give you guys a little overview on one of the most famous game development techniques that has been around for quite a lot of time, and how its basic principle can still apply to today's methods.

Just couldn't help myself

Nothing will save you!

In this post the the no-save system hinted at in the previous post will be discussed by going over various systems and see how they apply to horror games. I also want to point out that as in the last post, saving means the type of save that determines where the player starts after failure (death) and not progress recording. Also note that I will, becuase of reasons found in the previous save post, consider that weak negative failure effects (like quick save) reduce the scare factor.

Death is final
This type of save can be found mostly in rogue games like Nethack and means that if you die, you will loose all progress and have to start over. Pretty much all games utilializing this system is based on random generation of levels, so when one starts over the game does not play out the same as last time. It also has a concept of levelling yourself instead of the game character meaning that by using knowledge obtained from the previous session one can make it longer in the next.

Would this kind of saving work for horror game? To my knowledge it has never been tried and I think the main reason for this is the random aspects. Horror require elaborate setups with environments, enemies and events something that is not (yet?) possible with randomly generated maps (at least one horror game use it though). The story also tends to be important in horror games and procedurally generating that at the start of each session would be quite some task.

The idea of only having one life has lots of appeal for the horror game designer, as actions made would really matter and the prospects for instilling fear are very tempting. However, the requirement of having to randomly generate content does not lend itself very well to horror games and this type of system might only be workable for some really short and experimental game.


Teleportation
In this system the player is teleported back to a certain spawn position upon death, often combined with some other punishment (lost of currency, experience points, etc). Some examples: In Bioshock the player is teleported without any sort of punishment and in Diablo 2 the player drops all inventory at the place of death. As seen in the two examples, the degree of punishment can differ quite a bit. The placement of spawn points also changes the amount punishment a lot.

The biggest problem with this kind of system is that unless the punishment is quite large, it is either a very accessible system (making death meaningless, like in Bioshock) or one that can lead to frustrating (like Diablo). Thus it seems like if one does not pose some large negative effect upon teleportation it is not ideal to retaining atmosphere and creating fear. However, if the punishment is too harsh it will be very hard to balance the game, for example if the ammunition is lowered too much it might be impossible for the player to progress.

Mini game
The idea of this kind of system is that the player is punished by some kind of minigame before being able to return to the normal game. Prey is one game that uses this system and forces the player to shoot a certain amount of spirits before returning to play. At first glance the basics of this system seem very solid - a player never has redo any gameplay section and is always in the game (meaning no immersion breaking).

After "dying" a few times the problems start though. Whatever mini game the player is forced to play it will always detract from the main game and will never be as fun as the "real thing". This will lead to frustration and immersion breaking. If on the other hand the mini game is very short and simple, death will (like the accessible teleportation) become too easy and scariness be lost.

Immortality
Would it be possible to make a horror game where the player never dies? As discussed in an earlier post on combat, it is very possible to do so and there exist many examples of such games. All of these games build the scariness from atmosphere and use no game mechanics to inforce it. Would such mechanics be possible in a game with an immortal character though? One way to do it might be in a Sim City kind of way where ones choices will have consequences later on. If bad decisions are made the player might be put in an unwinnable state (turning into a kind of "death is final" game) or simply be denied certain plot points or items. This is highly experimental though and I know of no games where it is implemented.

Rebirth
A variation on the "death is final" system is to add more playable characters to the mix. If one character dies the game continues with the remaining characters until all are dead. Although it might sound very similar to the "death is final" type, there is a large difference - a death of a character might be intentional and it might even be required for all characters to die in order to complete the game. In such a game "completing" takes on a new meaning as it would require the story to branch and have multiple endings (unless each death is scripted which defeats the purpose). This could in turn lead to all sorts of exciting new gameplay and it might be possible to induce emotions like sorrow to a degree impossible in other kind of games.

As with all approaches, is it not without problems. Rebirth requires the designer to manage several outcomes out of different situations and considering one story is often hard enough, this is not an easy task. If it should be possible to always complete game, then the situations where death can happen is also limited, especially if a death needs to branch the storyline. Given an appropriate story these problems are not impossible to overcome though and might work in some kind of Cube-like setup.

Heavy Rain is supposed to have this type of system and although I have my doubts of the game, this aspect will be extremely interesting to see how it turns out.

Physical punishment
Finally one could induce real physical pain to the player upon failure. Knowing that a couple of thousand volts might be put into ones body will definitely make one extra careful when exploring. There are already games where physical pain play a part of the game and it seems to me like it would fit perfectly for a horror game. Not sure if I would like to try it though (beta testers would be harder to find for sure!).

On a more serious note, this kind of system would not be impossible to implement without hooking the player up to a torture machine. Simply displaying disturbing visual and auditory effects might act as enough punishment, but just like with mini games it might end of frustrating instead of adding to the atmosphere. I know of no games that use this but games like The Path and Punishment might be considered close.



What are your thoughts on games without saving? Do you think any of these could be used to increase the scare factor or is saving the best way for horror games? I am also interesting in hearing if I forgot to mention any systems.

What will save you?

Having talked about combat for a few weeks I will now move onto something else: Save systems in horror games. I will briefly discuss the various save systems available and how they affect the scare factor. But before doing that I would like to give a quick overview of goals of a save system.

Save systems come in many varieties and basically fill two functions:

1. Record progress when the player chooses to turn off the game.
2. To give the player some a starting point after "dying" (or what ever constitutes failure).

Note that in almost all new games the two are connected. But in many older games, the "death save" happened at the start of the level, but the progress was never saved when the game was turned off. Instead, turning off the game meant restarting. The reason for having this system is to increase difficulty in games and the place of the "save" is as such a measure of the penalty for failure. It is this penalty save (type no 2) that I will focus on in this post, and not saving as a progress recorder (type no 1) .

Now for a quick overview on the different types:

Save Anywhere
This type of save is pretty much self-explanatory - players can save whenever they want. Ever since PC's had large enough hard drives (at least Wolfenstein 3D days), this have been the de facto save system for PC gamers, and games not using it have often gotten harsh reviews because of it. One of those games is Penumbra, but I think that we did right thing to not use this save system, on the grounds that saving anywhere severely lowers the fear factor.

Our reasons for not using the save anywhere system are several. The two top reasons are:

1. The saving becomes a part of the gameplay and breaks the mood. Unless you can work the save system seamlessly into the game world, then the immersion is broken every time the game has to be saved and less immersion will mean less fear.
2. The fear of death becomes virtually non-existing since it is so easy to undo mistakes. Instead we want players to think before acting and not be able to save right before entering a unexplored room.
   

One might argue that the save anywhere feature can be combined with some other system, but the problem here is that once one start using the simpler anywhere-system it is hard to go back. Perhaps players only have themselves to blame if they turn to the other system? The problem with that is when players get really afraid, they might feel urged to use the save anywhere feature, even though they know it will break the mood. We therefore felt that it would best to force the player into playing the game like we intended it to be.

Auto Saves
Games that save without the player having to do anything are all in this category. This means that the autosave system might only save after the completion of every level or every 5 minutes.

The best thing about an auto save system is that it is completely transparent and never interfere with gameplay (at least until the player dies). This means that it is very good at keeping up the immersion. Auto saves has problems though. One major is that unless you only save after very specific events (like completing a level) it is very hard to know when to save. For example, the game should not save when the player has 1 health point left and is about to get hit by an enemy. Also, if only one save slot is used, this can lead to the player getting stuck in an unwinnable state and needs to restart the game.

To compensate for its problems, auto save is usually combined with some other kind of save system.

Save spots
What began as a storage limit on consoles, has become one an important mechanic in many horror games. Some games, like Resident Evil, even put limits on saving and further make it a part of the atmosphere. Usually save spots are accomplished by some kind of object interaction. When using something fitting for the environment (like computer terminals, typewriters, etc) this can make save spots less intruding on the immersion, but unfortunately most games insist on using some cumbersome file systems, taking the player out of the game world.

Save spots overcomes the second save anywhere problem described above and lessens the first a bit (but does not remove it). Some other problems arise though, especially if limits are imposed or spots are badly placed. The main problem is that if one dies without saving for a while there might be several frustrating of minutes of gameplay that needs to be redone. This problem exists for autosaves too, but to a lesser degree since autsaves are easier to place (but comes with other problems, as explained above).

Another problem is that even though save spot are a part of the game world and hence should lessen the immersion breaking, it might encourage the player to run to a save spot whenever some goal is achieved. This not only breaks immersion but also add a unneeded backtracking to the game and makes it a more frustrating experience than it needs to be.



Now that I have gone over the three different "death penalty" save systems used in game I would like to reflect on these by briefly discussing the saving in Penumbra.

We decided early on that we wanted to have some kind of save spot system, because we believed it would maximize the scare factors. However, we felt that we did not want to break the immersion the way most (if not all) other horror games do by adding a file system whenever the game is saved. Instead we chose to just have some kind effect upon interaction and then use a certain amount of slots that where cycled whenever the player saved. This way there would still be older (than the most recent) saves to choose from and immersion would be kept. I think this worked great and am quite surprised that I have not seen a single other game use it.

Early on we also determined that save spots would not be enough, especially if we wanted to lower the frustration of redoing and backtracking that came with the save spot system. For this reason we added auto saves and tried to save whenever something dangerous was about to happen. At first we thought about not giving any hints when the game was saved, but later on added a bright flash so that players knew they could breath out at some moments. We are still not sure if this was a good decision though and by keeping it more transparent we might have made players feel more unsafe and scared in some situations. On the other hand, some players never understood what the bright flash was about, thus being scared when entering a new area even though the game just saved.



Finally, we have been internally discussing the possibilities of skipping a save system altogether and what this would mean for the horror and immersion. A discussion about that will be for a later blog post though.

Until next time: What is your favorite save system for horror games? How did you like the system in Penumbra?

A History of violence. Part 3

In this blog post I will focus an underused combat mechanic: Chase Sequences. This type of "combat" is very common in horror movies, but quite rare in horror games. I will briefly discuss how we used it in Penumbra, problems it causes and how some other games have implemented it.

In Penumbra we used chase sequences on three occasions in the entire series and and each time it was a highly scripted event. There was always little room for the player to move in and mostly a very clear path. The first two chase sequences were in Overture and both involved being chased by a giant worm. In both of these the player had to complete a specific obstacle along the way and failure resulted in death and a restart of the chase. While a lot of people said that they liked this, a large amount also disliked this portion of the game because of its trial and error nature.

In Black Plague the chase sequence was a bit different. Here the player had more space to move about in, the goal was not as clear and we also deliberately tried messing with the player's head. The Overture chase sequences focused more on creating fear, while this had a larger focus on confusing and disturbing the player. Like the worm chases, some players really liked the sequence while other did not liked it all. Here the problem was that some people did not found the right way quick enough and the terror experienced was transformed into frustration.

The reason for people not liking the chase sequence is pretty much the same in both of the above instances, and probably also the main reason why this type of combat is so underused: It requires a very scripted environment, has a very strong trial-and-error feel and loses much of its impact and fun-factor after the first try. In order for it to be entertaining, the player must not repeat the sequences too much.

Some example from other games with chase sequences includes Clock Tower and Beyond Good and Evil (which is not a horror game though).

In Clock Tower chase sequences replace normal combat to a certain degree. When an enemy appears, the player must either hide or escape by using scripted interactions with the environment (throwing plants, etc). This is probably the most fateful adaption horror-movie chases I have played in a game, but it comes with lots issues. First of all, the chases loose their appeal very quickly as there is no real reward for avoiding the enemies, so enemies become more of a chore as the game progresses. Also, to avoid players from repeating hiding/avoidance patterns hiding places and offensive environment pieces stop working after some uses, sometimes making it very hard to escape an enemy and leaving one running around in circles trying to avoid the threat. More problems exist, but to sum it up the main problem is that it is very hard to keep this kind of generic chasing interesting and it is therefore not a very good mechanic.

Beyond Good and Evil's chase sequences are very scripted and at times similar to quick-time events. The sequences are also very much based on trial and error, but have very frequent check points removing some of the frustration. The chases are quite rare too, so they never get too annoying and always seem fresh. They can still get very frustrating though, and like the chases in Penumbra, enjoyment depends on how many tries it takes to complete them.

Finally, a Silent Hill 1 remake is going to be based around some kind of scripted quick time chases instead of combat. It will be interesting to see how this turns out and how they will manage to keep the chases from becoming frustrating trial and error based Dragon's Lair like gameplay. Judging from previous chase sequences in games, it seems like a risky decision, but it is always fun that developers dare to try new things.

What is your take on chase gameplay? Did you find the penumbra chase sequences fun or just frustrating?