Developer Diary - Penumbra: Black Plague
Posted: Wed Jan 23, 2008 5:36 pm
Developer Diary 1
Penumbra: Black Plague by Frictional Games
Introduction
Welcome to the first Penumbra: Black Plague developer diary! In this part we will focus on some of the improvements we have made to this stand-alone game since Penumbra Overture and elaborate on some of the game features.
Overture vs Black Plague
Black Plague is a sequel, however we did not just want to settle with what we had and only make minor improvements. Instead we aimed to really evolve as game creators and that has meant identifying imperfections in our previous game and remove them completely.
One of the challenges we've faced when creating a game, is that we become very attached to our creation and that makes it more difficult to objectively identify these imperfections. We also get used to the elements that make up a game and have a hard time imagining how first time player perceive specific features.
Examples of such imperfections are technical features, where improvements are easy to evaluate because we can use simple metrics (frames per seconds, visual quality etc) to determine if they are better then last time. At the same time there are other imperfections related to gameplay and the quality of a gaming experience where it is a lot harder to determine if and when these have been fixed.
Thankfully we have a great bunch of people trying out new ideas and we use their feedback to see if our improvements have been successful. We have also gained a lot of knowledge through the feedback from our first game, all of which has made us better at judging what works and what doesn't.
Dev Diary Part 2
Voice overs
The voiceovers are an area that has received more attention in Black Plague than it did in our previous Overture game. In Overture we had one character speaking to the player through a radio, in Black Plague this has been extended to around five characters speaking to him through various media. As we are working with a small budget we have not done any animated and synced characters. This is also a design choice as we believe horror is created by being lonely and isolated in an unknown territory, so don't expect any friendly chats over a cup of tea!
As Internet savvy as we are when it comes to how we develop games, we set about arranging for the voice creation in the same way. We found some interesting sites that enable voice seekers to come in contact with voice creators (actors).
This turned out to be an incredible smooth process where you create a project for each voice you need, give as much detail as you want and add some lines for actors to make auditions to. After posting the projects live it took less than an hour before the first audition files dropped in and a couple of days later we had a nice selection of voices to go through and select actors from. For any fellow developer we can certainly recommend this approach, its also affordable as they post projects using sub-standard rates and leave it up to the actors to decide if they want to addition regardless.
As it would be, we are not the only ones Internet savvy, voice actors are too! Tom (the writer of Black Plague) supplied the voice actors with the scripts and had a chat with each one going over the script before recording. For some of the key characters it was also possible for him to attend the recording over Skype and give live directions, which has resulted in some very tailored performances for Black Plague.
All in all it can safely be said, voice actors work in a manner that fits our production methods lovely.
Technical issues
One of the more important things you need to do in a game is to make sure that everything is as optimized as much as possible. However, since optimization often happens as one of the last things in development there is not always time for it and the game does not perform as good as it should at release. When it comes to Penumbra: Black Plague, the entire backbone for the game was already made which meant we did not have to spend a great deal of time to get things to work, instead we could focus on making things work fast at an early point in development. For the gamer, this means that Black Plague will run smoother than Overture and we have also been able to add more eye candy and can make the game look prettier without making it run slower.
Next up we also found a large slowdown in the animation code and as we examined it more closely we found several bugs and slow pieces of code. The skeleton that is used as a base of all animations is a hierarchy of bones that usually starts with the pelvis and then spread out to the other bones of the body (spine to shoulders, shoulders to upper arm and so on). This means that to when you update a bone, the positions and rotations of the bones below it in the hierarchy, called children, need to be updated as well and normally this is not a problem. However in an animation all bones get updated at the same time and because the children always got updated as well for each bone, there was a lot of redundant updating. The fix was very simple and just a matter of not updating any children until all bones had had their animations applied. And as if this code was not bad enough there was also a bug that attached all the children twice to each bone making the redundant updating twice as costly. This was also easy to fix and once it was done, things ran a lot smoother.
The above was just a little taste of the code optimizations done. We have tried hard to reduce processing time on all calculations made by the engine and we are not done yet.
Dev Diary Part 3
Introduction
One of the main features in Penumbra: Black Plague is the physics. This is a feature that adds a lot of immersion and gives new opportunities for gameplay. However, it has not been without problems to implement it and that is what we will focus on in this diary entry. We will go through some of the different problems we encountered and explain how we solved them.
Implementing physics
At the core of the physics in Penumbra: Black Plague there is an engine called Newton Game Dynamics. This engine makes sure objects collide and react realistically in the game world. But having the physics running is far from enough if you want to have an interactive game, there's a lot of work left to be done.
Our first challenge was to get the physics engine working with the game and the main thing in Penumbra is to be able to interact with objects. We wanted the interaction to be natural, simple and allow the player to intuitively understand the controls. However to get it all working we could not just slap on a generic system, instead we had to specialize every object in the world so that it reacts as you expect it to. First of all we have three different types of interaction that we use for each object: grab, push and move. Grabbing is used for objects that you simply pick up, push is used on larger objects that cannot be lifted and move is used on things like drawers, doors and levers. Once the type of object has been determined several properties needed to be tweaked. How much should the object weigh, is it slippery, should it be rotated along with the player and so on. All of these things needed to be tweaked carefully and the wanted behavior often changed depending on the situation.
Another challenge was getting the actual interaction algorithms to work well. Once you had a finely tuned an object, you need to have some controls in the game that uses the tuned properties and makes sure that the object behaves as planned. For example, one issue that arose was that the forces used to correct the orientation of an object were way too large at times. Meaning that when you picked up a small box it got so much energy that it was able to “punch“ large metal crates, making them fly several meters. The first fix was to set a max limit, however the object was not corrected quickly enough when doing so. This lead us instead to lowering the mass of the object, but in turn this lead to objects not being able to be lifted because of other items inside them (for example a trashcan with trash). The final solution was to have all of these controls set on an object basis, letting some object get their weight lowered, some got a max force limit, etc.
As if things where not complicated enough, once we started to add AI to the world, it got even more problematic. The problem with normal AI routines is that they assume the world is static, which is certainly not the case in Penumbra: Black Plague where almost every object can be moved. This meant that a route the AI had picked out could be blocked at any time and become invalid. To solve this we made the AI constantly check if the path was clear and if it was not, have them update their paths to go around the obstacle. Also, the AI needed to have routines to see if a blocked path could perhaps be cleared (by pushing or kicking and breaking) instead of going around, which took a lot of tweaking to get right. In the end we had to tweak all world objects (again) and make sure that the AI would handle them correctly. Countless of hours have been put into checking so that the enemies behave intelligently in the many situations that can arise.
Using the physics to design puzzles
As mentioned above, a lot of work went into to setting the correct properties to various objects so that they reacted correctly in the world. This was especially true when designing and creating the puzzles in the game levels. We wanted to have as few inventory based puzzles as possible and instead have the player physically interacting as much as possible. Having this goal proved to require a lot of work to make sure that the puzzles where fun and worked as planned.
The best and worse thing with physics puzzles is that you can never plan for every event. There are endless of ways in which the physics can be used and this means that you can never be sure that you have tested every single way in which the player can approach a puzzle. The good thing with this is that the player can solve puzzles in ways, we as designers, never planned. The bad thing is that the puzzle might be broken in unexpected ways too. For example if you need to cross a rift using boards, it is hard to prevent the player from simply throwing down all the boards into the rift, making the puzzle unsolvable. During the development of the game we tried hard to minimize these sorts of things, however we also didn't want to be overprotective either. Because of this we made the decision to leave a way to destroy the puzzle, if it made the way to solve it the more open. As long as it was very obvious when the player destroyed a puzzle we figured this approach would be a lot better than holding a player’s hand every step of the way, making the game much more linear.
Another grim feature of a physics system is its chaotic nature. By chaotic we mean that the slightest change in starting conditions might lead to vast changes in the result. For example, at one point in the game we wanted a corpse to fall down, but the physics would never behave the way we wanted it to. Every time we thought we had it in the right starting pose, it would still fall completely wrong on a later occasion. This forced us to add several correctional forces to make sure the corpses landed where it should and a task we at first thought would be simple, turned out to consume over a day’s worth of job.
Conclusion
What we have just described is just a little part of all the obstacles we had with the physics, but hopefully it will give you a glimpse of the work we have put into getting them really good. Although the physics have been hard work, we believe that it has added a lot to the game and given it a unique feel and atmosphere. Hopefully all of you who play the game will think likewise!
Penumbra: Black Plague by Frictional Games
Introduction
Welcome to the first Penumbra: Black Plague developer diary! In this part we will focus on some of the improvements we have made to this stand-alone game since Penumbra Overture and elaborate on some of the game features.
Overture vs Black Plague
Black Plague is a sequel, however we did not just want to settle with what we had and only make minor improvements. Instead we aimed to really evolve as game creators and that has meant identifying imperfections in our previous game and remove them completely.
One of the challenges we've faced when creating a game, is that we become very attached to our creation and that makes it more difficult to objectively identify these imperfections. We also get used to the elements that make up a game and have a hard time imagining how first time player perceive specific features.
Examples of such imperfections are technical features, where improvements are easy to evaluate because we can use simple metrics (frames per seconds, visual quality etc) to determine if they are better then last time. At the same time there are other imperfections related to gameplay and the quality of a gaming experience where it is a lot harder to determine if and when these have been fixed.
Thankfully we have a great bunch of people trying out new ideas and we use their feedback to see if our improvements have been successful. We have also gained a lot of knowledge through the feedback from our first game, all of which has made us better at judging what works and what doesn't.
Dev Diary Part 2
Voice overs
The voiceovers are an area that has received more attention in Black Plague than it did in our previous Overture game. In Overture we had one character speaking to the player through a radio, in Black Plague this has been extended to around five characters speaking to him through various media. As we are working with a small budget we have not done any animated and synced characters. This is also a design choice as we believe horror is created by being lonely and isolated in an unknown territory, so don't expect any friendly chats over a cup of tea!
As Internet savvy as we are when it comes to how we develop games, we set about arranging for the voice creation in the same way. We found some interesting sites that enable voice seekers to come in contact with voice creators (actors).
This turned out to be an incredible smooth process where you create a project for each voice you need, give as much detail as you want and add some lines for actors to make auditions to. After posting the projects live it took less than an hour before the first audition files dropped in and a couple of days later we had a nice selection of voices to go through and select actors from. For any fellow developer we can certainly recommend this approach, its also affordable as they post projects using sub-standard rates and leave it up to the actors to decide if they want to addition regardless.
As it would be, we are not the only ones Internet savvy, voice actors are too! Tom (the writer of Black Plague) supplied the voice actors with the scripts and had a chat with each one going over the script before recording. For some of the key characters it was also possible for him to attend the recording over Skype and give live directions, which has resulted in some very tailored performances for Black Plague.
All in all it can safely be said, voice actors work in a manner that fits our production methods lovely.
Technical issues
One of the more important things you need to do in a game is to make sure that everything is as optimized as much as possible. However, since optimization often happens as one of the last things in development there is not always time for it and the game does not perform as good as it should at release. When it comes to Penumbra: Black Plague, the entire backbone for the game was already made which meant we did not have to spend a great deal of time to get things to work, instead we could focus on making things work fast at an early point in development. For the gamer, this means that Black Plague will run smoother than Overture and we have also been able to add more eye candy and can make the game look prettier without making it run slower.
Next up we also found a large slowdown in the animation code and as we examined it more closely we found several bugs and slow pieces of code. The skeleton that is used as a base of all animations is a hierarchy of bones that usually starts with the pelvis and then spread out to the other bones of the body (spine to shoulders, shoulders to upper arm and so on). This means that to when you update a bone, the positions and rotations of the bones below it in the hierarchy, called children, need to be updated as well and normally this is not a problem. However in an animation all bones get updated at the same time and because the children always got updated as well for each bone, there was a lot of redundant updating. The fix was very simple and just a matter of not updating any children until all bones had had their animations applied. And as if this code was not bad enough there was also a bug that attached all the children twice to each bone making the redundant updating twice as costly. This was also easy to fix and once it was done, things ran a lot smoother.
The above was just a little taste of the code optimizations done. We have tried hard to reduce processing time on all calculations made by the engine and we are not done yet.
Dev Diary Part 3
Introduction
One of the main features in Penumbra: Black Plague is the physics. This is a feature that adds a lot of immersion and gives new opportunities for gameplay. However, it has not been without problems to implement it and that is what we will focus on in this diary entry. We will go through some of the different problems we encountered and explain how we solved them.
Implementing physics
At the core of the physics in Penumbra: Black Plague there is an engine called Newton Game Dynamics. This engine makes sure objects collide and react realistically in the game world. But having the physics running is far from enough if you want to have an interactive game, there's a lot of work left to be done.
Our first challenge was to get the physics engine working with the game and the main thing in Penumbra is to be able to interact with objects. We wanted the interaction to be natural, simple and allow the player to intuitively understand the controls. However to get it all working we could not just slap on a generic system, instead we had to specialize every object in the world so that it reacts as you expect it to. First of all we have three different types of interaction that we use for each object: grab, push and move. Grabbing is used for objects that you simply pick up, push is used on larger objects that cannot be lifted and move is used on things like drawers, doors and levers. Once the type of object has been determined several properties needed to be tweaked. How much should the object weigh, is it slippery, should it be rotated along with the player and so on. All of these things needed to be tweaked carefully and the wanted behavior often changed depending on the situation.
Another challenge was getting the actual interaction algorithms to work well. Once you had a finely tuned an object, you need to have some controls in the game that uses the tuned properties and makes sure that the object behaves as planned. For example, one issue that arose was that the forces used to correct the orientation of an object were way too large at times. Meaning that when you picked up a small box it got so much energy that it was able to “punch“ large metal crates, making them fly several meters. The first fix was to set a max limit, however the object was not corrected quickly enough when doing so. This lead us instead to lowering the mass of the object, but in turn this lead to objects not being able to be lifted because of other items inside them (for example a trashcan with trash). The final solution was to have all of these controls set on an object basis, letting some object get their weight lowered, some got a max force limit, etc.
As if things where not complicated enough, once we started to add AI to the world, it got even more problematic. The problem with normal AI routines is that they assume the world is static, which is certainly not the case in Penumbra: Black Plague where almost every object can be moved. This meant that a route the AI had picked out could be blocked at any time and become invalid. To solve this we made the AI constantly check if the path was clear and if it was not, have them update their paths to go around the obstacle. Also, the AI needed to have routines to see if a blocked path could perhaps be cleared (by pushing or kicking and breaking) instead of going around, which took a lot of tweaking to get right. In the end we had to tweak all world objects (again) and make sure that the AI would handle them correctly. Countless of hours have been put into checking so that the enemies behave intelligently in the many situations that can arise.
Using the physics to design puzzles
As mentioned above, a lot of work went into to setting the correct properties to various objects so that they reacted correctly in the world. This was especially true when designing and creating the puzzles in the game levels. We wanted to have as few inventory based puzzles as possible and instead have the player physically interacting as much as possible. Having this goal proved to require a lot of work to make sure that the puzzles where fun and worked as planned.
The best and worse thing with physics puzzles is that you can never plan for every event. There are endless of ways in which the physics can be used and this means that you can never be sure that you have tested every single way in which the player can approach a puzzle. The good thing with this is that the player can solve puzzles in ways, we as designers, never planned. The bad thing is that the puzzle might be broken in unexpected ways too. For example if you need to cross a rift using boards, it is hard to prevent the player from simply throwing down all the boards into the rift, making the puzzle unsolvable. During the development of the game we tried hard to minimize these sorts of things, however we also didn't want to be overprotective either. Because of this we made the decision to leave a way to destroy the puzzle, if it made the way to solve it the more open. As long as it was very obvious when the player destroyed a puzzle we figured this approach would be a lot better than holding a player’s hand every step of the way, making the game much more linear.
Another grim feature of a physics system is its chaotic nature. By chaotic we mean that the slightest change in starting conditions might lead to vast changes in the result. For example, at one point in the game we wanted a corpse to fall down, but the physics would never behave the way we wanted it to. Every time we thought we had it in the right starting pose, it would still fall completely wrong on a later occasion. This forced us to add several correctional forces to make sure the corpses landed where it should and a task we at first thought would be simple, turned out to consume over a day’s worth of job.
Conclusion
What we have just described is just a little part of all the obstacles we had with the physics, but hopefully it will give you a glimpse of the work we have put into getting them really good. Although the physics have been hard work, we believe that it has added a lot to the game and given it a unique feel and atmosphere. Hopefully all of you who play the game will think likewise!