Monday, October 5, 2009

Puzzles in horror games. Part 6.

Yeah, late again... development is becoming more intense, but I will try and keep the blog entries coming in some kind of regular fashion!

A major feature of many games is to let the player become a another person, to play around as some fantasy alter ego. In God of War you take the role as a powerful spartan, Tony Hawk lets you become a professional skater and so on. All of these games lets you have skills and attributes that you normally do not. In God of War it is super human strength and combat abilities. In Tony Hawk it is abilities that normally takes lots of talent and years of talent to acquire. In most adventure games, the player takes the form of some type of Sherlock Holmes character and here one runs in to a problem: How does the player become Mr Holmes? How can she be given Sherlock's wit and problem solving abilities, just like she is given Kratos' strength? That's what the rest of this blog entry will be about.

Physical attributes, like dexterity and strength, are simple to put into the actual gameplay and is nothing that feels intrusive. These physical attributes can be pretty much everything that exists outside of the brain and problem only starts when the thing to boost exist wholly or partly inside of the gray lump. An example of this is aiming, which requires some physical dexterity but is also about reflexes, something that resides, to a degree, in a person's brain. This is a pretty easy thing to solve and have been done so in the form of auto aiming and slow motion systems (ala Max Payne). It would be possible to do something similar with problem solving and add help systems that guide the player. This could come in the form of A Beautiful Mind-like "number visions", where the protagonist ability to find patterns is visualized as certain numbers becoming illuminated and floating out in the air. An example of this in use, are pool simulators where player can see where a strike will go. Another example of the same type is simply to add some kind of calculator, to help offload the player's brain from some heavy cognitive challenge.

The biggest problem with having these kinds of helper systems is that they will only work on very specific tasks (like playing pool) and are not something that helps in the wide varieties of puzzles encountered in an adventure game. Another problem is that it might actually weaken the experience of solving puzzles. Giving the player extra strength to take on hordes of enemies does not feel like cheat, but being given visual tools to solve to problem feels like hand holding. It is almost the equivalent of the game taking over the controls in an action game. These two issues are probably the cause why I have never seen such a system in an adventure game (but would very much like to know if one exists!).

Another way of letting the player become Sherlock Holmes, is by putting all of the problem solving in "game space". This means that all actual thinking is implemented as game mechanisms and is determined by dice rolls or something else. In the Call of Cthulhu RPG the player has to make dice rolls against certain skills to do things like decipher runes, read books and understand the meaning events. This is a quite good way of doing more complex tasks that would require years of education (like understanding ancient languages), but is not as a fun with simpler "connect the clues" kind of challenges (where it turns into hand-holding). However, when implemented in games, where generating important outcome from random generator is not as accepted, it is quite hard to get right. What happens if the player fails the "dice roll"? Should she be able to try again? If so, how many times should it be possible to retry? Instead of using the random generator, there could be some mini-games involved, which is the way it is implemented in Farenheit (indigo prophecy) at certain places. Mini games is not much better than a random generator though, and no solution feels really good.

A hybrid solution to putting everything in "game space" is to limit the player's options according to the protagonist's skills and letting the game provide parts of the solution. The most common usage of this is in dialogs where the player is given a certain number choices of what questions to ask or what to answer. This kind of system lets the game do half the work and lets the player finish it, giving a lot more satisfaction than simply rolling die or completing an unrelated mini game. Problems can still arise though, for example in a dialog the player can come up with something more clever than the options given or perhaps the protagonist have not yet figured something out that the player has, leaving an option unavailable. This leads to "guess the action" and "missing item" problems (see this post) respectively and is something that one wants to avoid. While working pretty good in a dialog, this system can become quite annoying when applied to other areas, as it is very much like the game taking control from the player.

A game can also implement some kind of hint system which gives the player help when in needed or just continually feed the player advice. Hint systems not only let the player gain some brain power but is also a way of lessen the chance of getting stuck. However, like with the other systems described, hints can easily turn into hand holding and make the experience worse. Hint systems can either be implemented as an ingame thing or a completely separate system.

When in game, hints are dropped through character comments, notes, etc and is the main way in which we implemented hints in Penumbra. The problem with this is that it is hard for the player to ignore the hints, and while their help might be appreciated by some, others might find that they make game too easy. As they are part of the in game resources, they are very hard to remove and must thus be carefully tuned. They can also never spell out the solution to a puzzle and might not be of much help for a player that has become stuck.

By using a special hint system, the player can chose for herself how much to use it. This sort of freedom is not always good though and players might unwillingly abuse the hint system. For example, I know many cases where I pretty much stopped solving puzzles after checking a walkthrough and when playing the remake of Monkey Island, I used hints much more than what I really wanted to. A way to solve this is to use some kind of limt for hints, as in Professor Layton where hint coins are used. However, the problem then becomes that some players might have tons of hints left to use and others few. This makes it very hard to tweak correctly and those in most use of hints might end up not being able to use them.

Finally, is some kind of brain booster really needed for the player? In terms of hint systems, it is pretty obvious that they are good at making sure the player does not get stuck. But perhaps the player should just settle with who they are, use the brains given and not try and be someone who they are not? But does this not defeat the purpose of games? If we can have games that improve every other attribute in a player character, why not intelligence? I also think many would agree that being really smart would be preferable from being really strong, and providing people with such an experience would be very worthwhile! As discussed in this entry though, boosting brainpower in a game is highly problematic and has even proved to be so in real life. However, by using some of the systems above at least the problem of puzzle difficulty is partly solved and more people can enjoy playing the game.

What do you all think of this and how would you like to see a "brainbooster" implemented? If you know any game with an especially good or bad hint system, then we are very interested in hearing about it!

Sunday, October 4, 2009

Designing a good API

So I've been doing some work porting some code to another platform (which I'll speak about later), and it's showing a severe lack of API design. Now I design APIs for a living I thought I'd quickly go over what I think makes a good API, not just from a users point ov view, but internally as well.

Simple and Fast. And we're done. Thanks for reading.

Okay... I'll go into a litte more detail. Now, API's are usually there to give a coder simple access to a more complex system. Take DirectX. The underlying hardware and systems are pretty complex these days, what with interrups, DMA chains dynamic memory management and all the rest of it, yet the API is (reasonably) simple. So... here goes.

Simple. An API must be simple, in fact as simple as you can get away with. This isn't to say you should make it basic, no. You should make it do everything a coder will normally have to do, but don't over complicate it by using 1,000,000 calls for each function. Take DirectX texture creation... Now, whenever I do a graphics engine I have a single CreateTexture() function where as DirectX has several. Textures, Surfaces, DepthBuffers and Cube Maps, the list goes on. Now why? Theres really no reason for that kind of split. You could just as easily use flags and paramaters to allow the various types of selection. This means the coder only has a single function to learn, and if you follow this kind of rule for the whole API, then the entire system becomes much smaller. After all, would you rather a 1,000 call API where you have to set the width and height of a texture indavidually, or 10 functions that can do everything! The smaller the API, the more control you can keep over it. If you give access to every single function and variable, then it becomes a nightmare to change or upgrade.

So, keep an API simple. It's less to maintain, and the programmers that use it will thank you for it.

Speed. This is obvious. It has to be fast. If your management code gets in the way, then the API will become too expensive for coders to use properly, and they'll end up writing support functions themselves. This is really bad. You want the programer to have confidence in the API, not only that it'll do what you say it'll do, but that it won't slow him down. Streamline as much as possible, remove as many if's and but's as you can inside performance critical areas.

Now, a quick word about abstraction. It's important to abstract certain types of API so that it's clean and portable. Now theres a few of reasons for that. First you expect the API to change under you. If your using some open source interface, you never know when the latest buzz word is gonna take hold and your whole API is gonna change, so a simple layer of abstraction will protect you. Next, it will allow you to add value to an underlying API. Take DirectX texture management, if you add a simple layer to your API, you could then now keep track of all your textures, and it'll allow your to manage things like device resets (when you resize the window etc.) as since you own all the texture pointers you can free/reallocate things like render targets automatically. Lastly... Portability. Now most hobby projects don't care about this, but you never know when your project might take off and someone else might want to port it for you to a Mac, or a ZX81...or something.

The program I'm currently working on was hard coded for windows, using not only MFC, but DirectX calls and enums directly. So, being someone that designs APIs, I know all about abstraction. Being someone who's worked on lots of multi-platform games, I know all about how to make an API platform independent. So, thats what I'm doing. All calls to DirectX and being put through a layer of abstraction, each ENUM is being changed to be platform agnostic. This means the API can translate (very quickly) to whatever rendering API I want, without the main application knowing, or caring. The classic case is DirectX and OpenGL. Doing this would allow this program to run on the Mac, without the main program changing. I'd only have to port the (now pretty small) API, and not the whole program.

If you've done your job correctly, you'll have to port a handful of API's. Sound, Graphics, Networking and simples file systems and memory management. All games can be based on these simple API's, and then be made to run on other platforms (reasonably) easily.

Theres obviously lots of ideas for each API. Designing graphics APIs is an art in itself. I've used the same API for the last 10 years. The underlying graphics systems have been PS2, XBox 1, DirectX 8&9 and I know it would work just as well on a PS1, XBox360 (never seen a Ps3 SDK), and DX10/11. A well designed API will work on any platform and be a pleasure to use.

So there you go... Keep an API simple - don't get sucked into the latest fad. Keep if as fast as you possibly can. And abstract to reasonably protect yourself from underlying systems and to allow simple porting.

Thursday, October 1, 2009

Horror Tip: [REC]


Name: [REC]
Type: Movie
Link(Movie details): http://www.imdb.com/title/tt1038988/
This is a spanish little gem in the "first person documentary horror" genre, same as the first Blair Witch movie (which I have not seen by the way). While pretty famous in Spain, I'm not sure how known it is worldwide, I think you will at least know the american remake "Quarantine". I like the original better, just my opinion.

The movie is shot from the point of view of a cameraman in a fictional TV show called "Mientras usted duerme" (While you sleep), as he films reporter Ángela Vidal during a usual Barcelona Fire Dept. work night, until there's a seemingly rutinary emergency call from an old apartment block. I don't want to give away anything further than this, so if you want to know more on the plot, you are adviced to watch the movie instead of checking the internet for details :).

The actors do a nice job, the set is claustrophobic enough, it actually gets to build up quite an atmosphere, and apart from some a bit lamish moments, the movie delivers in my opinion. Directors Jaume Balagueró and Paco Plaza also have some more interesting work, which I might advice sometime in the future.

Now that the sequel is about to hit the spanish streets (well, like in some hours actually :P), I recommend you watch this one, and if you already did, just feel free to discuss, but be careful with spoiling stuff.

Wednesday, September 23, 2009

Parallax trix

Since many seemed to enjoy the parallax mapping showed off in the material editor, I just wanted to show off the more advanced way of doing it and also giving some explanations.

No Parallax
This is when no parallax effect is added, just boring and flat. What happens is that the engine simple interpolates the uv-coordinate (the position on the texture map) according to the vertices (the points) of the model.

Offset Parallax

This technique is really just a cheap trick and as seen in the picture it fails at steep angles. Despite this, as the material editor video showed, it still gives a good effect in most cases! The way it works is by adding an offset to the uv coordinate depending on the height of the height map and of the angle of the eye (compared to position of the pixel). The biggest problem with this is that a pixel can never occlude (be in front of) another.

Relief mapping
This algorithm is a lot more accurate than offset mapping, but also a lot more expensive. This is no longer a cheap trick and works by casting a ray from the position of the eye and into the height map. It is then computed where the ray first hit something and the uv coordinate of that point is used. This sort of ray casting is used in all advanced parallax techniques, but is implemented differently. In relief mapping, one first steps along the ray at certain intervals and looks for an intersection. When one is found a binary search is used between the intersection and the eye position to pin point the exact intersection point. The binary search means that the distance between eye and the first found position is halved over and over, locking in on the intersection.

Other techniques such a cone step mapping give even better results but require the height map to be set up with certain extra data that is calculated before the rendering starts. There are also techniques for letting the height map not only occlude itself but also the other objects in the scene. It can even carve the actual model to better fit the height map, see "Relief Maps with Silhouttes" here for an example. This really takes the technique to new heights (ha..ha...) and it is really cool how much can be done with what starts out as a flat surface!

Monday, September 21, 2009

I'm a Material Boy

Sorry for the long period with no tool show off. Blogging sure takes time :P

Here's the HPL Material Editor, our latest addition to the tool suite. This is what we use to create, edit and preview materials with. In a nutshell, a material is what's gonna determine how an object is going to look like in the engine. As of now, we have three basic types of materials:
- SolidDiffuse, which we use to model solid surfaces. Take a bit of a bump map, and another bit of a heightmap and you will have a more than convincing rock like material for example :)
- Translucent, to create a "glass like" look - Windows, ice... transparent stuff falls in this material type.
- Water, the most bleeding edge feature in the engine right now, used to simulate "liquid objects". Just like water in Penumbra, but now with more Reflection(tm).

Of course, it wouldn't be a HPL2 tool if it hadn't a realtime preview window, which is what really makes the tool worth it. In the good old Penumbra days, one would have to edit the material using the HPLHelper app, but then testing how the material looked meant having to start an independent viewer program, a bit of a pain if you ask me. The preview window features cubemapped and flat colored background, different preview models (ie cube, cylinder, sphere and plane), and lighting with customizable colors.

And last, but not least, here's a little video showing the Material Editor in action, in standalone mode (yeah it is also integrated in the other editors)



By the way, that "blackness" artifact at the edges of the water plane are caused by the current preview window setup. Looks like I'm gonna need to fix that... :P

Thursday, September 17, 2009

Puzzles in horror games. Part 5.

Due to illness and an unhealthy obsession in making rendered water look nice this post is a little late. Hopefully no harm has been caused :)

Figuring out a good puzzle is often a hard and tricky process. Sometimes a puzzles presents itself from story and environment naturally, but more often it is put in just to add some gameplay and/or slow the player down. This means first coming up with some kind of obstacle and then designing some sort of solution for overcoming it. During this process, and especially when "forcing" a puzzles into the game, one has to consider a couple of things. The most important of these are:

Enjoyment
How fun a puzzle is to solve and how unique is it both determine the level of enjoyment a player gets from trying to figure and actually solving a puzzle. Solving the same kind of puzzles over and over is never fun and any appearance of a sliding puzzle is bound to bring forward feelings of unhappiness.

Cleverness
While a bit related to Enjoyment, a clever puzzles does not really need to be fun, it just needs to have a solution that makes the player think out of the box. A clever puzzles often includes using something in a non-obvious way and/or piecing together several fragments of information. If a game mainly relies on solving puzzles (such as Professor Layton), having clever solutions becomes extra important.

World Coherence
This means how well the puzzle fits with the story/world and is often the hardest part to accomplish. A puzzle with good world coherence adds realism and immersion to the game, while a bad one pulls the player out of the experience. In order to obtain high coherence a puzzle must fit with the story and also suite the world and not feel out-of-place.

When designing puzzles for Penumbra and our upcoming game, it is always a balance between these. Sometimes a puzzle might fit perfectly with the story but just be really dull and sometimes a fun puzzle does not fit at all with the game world. It is almost impossible to come up with a puzzle that "score" high in all the above criteria, so one has to concentrate on something.

In horror games, where immersion is key, it is probably best to always make sure that no puzzle feels out of place. For some reason many action based horror games seem to forget this and are filled with mood breaking puzzles. In Penumbra we did our best to have as high world-coherence and often had to sacrifice other criteria in order to do so. This is one of the reasons why Requiem contains so little story, we wanted for once to concentrate on the making fun and clever puzzles.

Most (at least we hope so!) puzzles in Penumbra where not dull and stupid, but often we concentrated on either making it clever or fun. In the cryo-chamber, getting the head out of the jar was not a very rewarding puzzles to solve, but the main idea there was to let the player do something fun (who does not like playing around with severed head?), instead of teasing the player's brain. Figuring out how to enter the cryo-chamber was instead an attempt at making a clever puzzles and required several pieces of information to be linked.

By trying to vary puzzles like this we hope to have made the experience more interesting. As discussed earlier, games does not need focus on creating joyful feelings all the time. By letting the player sweat over a more complicated task, more emotions can be added to the game and end up being a more rewarding experience. Adding instances of more fun and simple puzzle in between breaks things up and make the brain-teasing parts stand out more.

This brings me to the final issues one has to consider. Difficulty. I did not include it in the list above because, while an important thing to ponder, it is quite a different beast. The main problem lies in that when a solution is known it is no longer hard to solve, and thus it can be hard for designer to now the difficulty of a problem. Even so, it is a very important part of the gameplay and the time spent pondering a puzzle plays a large role in the gameplay flow. At times it might be fitting to throw a harder challenge at the player and other times the player should be able to solve it quickly. Especially when a situation is meant to be frightening, having the player scribbling on a note in the "real world" is not good for the mood.

Pretty much the only thing that can be used to test difficulty is extensive play testing, but this being time consuming and expensive (especially since the same person can not reliably test something twice) other methods are needed. I usually try to "wipe" my mind, think myself in the situation of the first time player and imagine the moves she would make. This is actually not far from the tactic used when designing scary situations, something that also greatly relies on an unknowing player. Designing puzzles is actually kind of related to creating a horror atmosphere in that one has to try mess with another person's mind and supply hints, confuse, etc in order to create a satisfying experience. This is yet another reasons why horror games and puzzles are such a good fit.

What do you think is most important criteria for a good puzzles? As always we are also eager to hear feedback on puzzles present in Penumbra with the above in mind!

Thursday, September 3, 2009

Puzzles in horror games. Part 4.

Quick note: Due to me being caught up in a lot of technical work this blog entry is a lil bit late and I also missed a horror tip last week. Gonna try and be better in the future! :)

The fourth part in the puzzle series will be about a specific "feature" that I am sure you are all aware of. Backtracking. This is often to considered to be a big problem in adventure games and seem to especially plague survival horror like Resident Evil. It is often blamed for being a product of bad design, and it can often be very annoying. Backtracking does not always need to be bad though and might actually be a part in increasing the immersion.

To start up, I would like to define the different kinds of backtracking:

Compulsory backtracking
In some games, the design forces the player to do backtracking and games like Resident Evil and the newer Castlevania are full of this. After collecting a certain item, the player needs to backtrack to a location far back where the item is to be used. Sometimes the location is known (for example highlighted on a map) and other times it is up to player to figure out where to use the item. To make the journey back more fun, some games add new enemies, obstacles and/or change the environment. Other times the player simple needs to grind their way back. Especially when the target location is unknown it can be a very frustrating experience and I know of times in Castlevania where I pretty much searched through the entire game before finding out where the newly found item was to be used.

Forgotten item backtracking
Adventure games are often based around the player exploring environments and when much searching is needed, chances are something will be missed. This can lead to the player not having picked up an important item, done a certain task, etc and when arriving at an obstacle one needs to backtrack to find out what was missed. This type is different from the compulsory backtracking in that it is not explicitly designed, but stems from the fact a player has not been successful when searching. This situation can be very annoying to end up in as it might not be obvious where to look for the missing item/event. In many adventure games the player is some kind of scrap-collector and the usability of an item is not obvious until collected (if even then...). Thus it is hard to get any hints from the examining obstacle one is stuck at.

In my opinion the forgotten item type of backtracking is the most annoying and not always predictable from a design standpoint. Because of that I am going to discuss how to go around solving this first, and will be using Braid as an example. In Braid it is always possible to solve a puzzle when encountered as no items or upgrades are needed in order to find the correct solution. Instead the player needs to come up ingenious ways of using the game mechanics and sometimes simpler puzzles need to be solved in order figure a harder one out. When encountering a puzzle the player is always certain that a puzzle can be solved and can never be missing any special item or triggered event. This approach is a an "extreme" way of solving the missing item problem in that it never relies on previous areas (note: Braid does rely on it in on a single occasion).

But what if one wants to pick up items and such as part of the gameplay? A way to solving this is either to let force-feed the player with items, placing them in such obvious location that they are impossible to use and/or have sub obstacles that require the a certain event to be triggered for the player to continue. Many action adventure games uses this approach. Another way to deal with it is to always place the items close to the obstacle and removing the need to do any backtracking. This approach is what we used a lot in the Penumbra games and it requires that the player knows that items are always close (something we did not totally succeed with) . If the player still thinks that the needed item might be anywhere, then it does not matter that it in reality is very close. Also, this approach requires 100% consistency and if some puzzle suddenly requires an item way back, the player will still assume it is nearby and never go searching far enough. Finally making the puzzle solutions more "realistic" and intuitive will also improve the situation as the player can then easier figure out what might be needed for overcoming the obstacle.

Although there exist solutions for the forgotten item backtracking problem, they are not without flaws. On the other hand, with the compulsory backtracking it is easy to fix. Just remove the need of backtracking, right? On closer inspection, it turns out that it is not that easy. First of all, in open ended games there is a need to spread out puzzles and will therefore always be some kind of backtracking. The problem of not knowing where to go can still be addressed though and many open ended games has a map with blinking hot spots, arrows, etc indicating where the player should go. However, sometimes this is not wanted either and the enjoyment of the game might come from exploring the game without being spoon-fed the next action all the time.

Going back to Braid, which even though it does not have the forgotten item problem, still has some compulsory backtracking. Unless the player solves all of the puzzles in linear fashion, there is a need to go back through levels and find the last puzzle pieces needed. Now Braid could have let the player instantly teleport through some menu to each location, but in my opinion that would ruin the game. By being forced to traverse the world one is more immersed in the game world and even though the activity is not fun in itself, it still enhances the experience. To be fair, Braid has very minor backtracking compared to other games, but I still think it is an important observation.

Back to the forgotten item backtracking. Is this really always a bad thing? As mentioned in the solutions for overcoming it, a remedy mostly means limiting the player somehow and forcing one through the game. Limits can be a good thing, but if a game should give the player a feeling of exploration then it is almost impossible to remove it. Having some type of frustration is most likely essential in order to provide the right experience. The problem does not lie in removing the frustration, but rather limiting and managing it.

To sum things up: the problem of backtracking that at first glance just seems like an annoyance, might actually be a very important part of making a game. A designer should not try and remove the frustration caused by backtracking, but instead limit it and use it to improve the player experience. Frustration is a large part of life and just trying to remove it from a game will only result a brainless and less satisfying experience.

As always we are very curious to know what you think about all this!