Wednesday 23 September 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!

Tuesday 22 September 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 17 September 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:

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.

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 3 September 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!