Making a game with a lot of real time rendering effects is very hard and requires a lot of resources. This is why we had to put a lot of work into optimizing the game.
Optimization is about making the best and most effective use of a resource. In video games it means saving as much resources as you can without the player noticing it. The best way to achieve this is to put as much resources as you can on what the player can see and removing everything that's outside of the field of view.
This article covers how we managed to save as much performances as possible to save power on the rendering without affecting the game-play and the frame-rate. If you are not a very technical person don't go away! There is a lot of illustration and the approach is high level.
Smart script execution
Doing well written scripts is very important, but it is not enough to make an optimized game. It's important to execute the script at the right time and disabling it when it's useless. It's not a problem when you run a game with small scenes. It could be a real issue if the game needs to run bigger maps.
In Shadows of Time maps can contain more than 1000 dynamic objects... A normal PC could not run at more than 15fps if all of them were processed at the same time. To solve this issue only the necessary behaviors are executed. For example, if a soldier is too far away to see the player there is no need to run the "eyes" script.
This allows to make bigger maps without affecting to much resources. Unfortunately it's not sufficient when you have a lot of models to render.
Disabling noise (Green) and visual sight (Yellow) detection when the player is to far away
Even static objects consume resources. Physics processing for collisions, 3D rendering... don't need to be processed if the player is not around.
The best solution for this was to make chunks, and enabling only those around the player. Every static object like walls, floor, decoration... are disabled if they are too far away. Only the tiles that are visible by the camera are active. This includes their models and the scripts attached to them.
This allowed to have a lot more 3D models without affecting performances. It cleared enough resources for the post processing and the lighting.
Showing how the chunk algorithm hiding tiles outside of the player line of sight
Video game developers tend to avoid dynamic lighting, because it's a lot more consuming than baking (the Pre is calculating lighting and shadows). Why using dynamic lighting them? The main issue with baking is it's not possible to have dynamic shadows and it does not work with dynamic 3D objects. All the optimization above allowed to save a lot of resources to be able to have dynamic lights. But having too many lights can be very resource consuming.
At the beginning of the development the lights were disabled and enabled by the chunk system. But it didn't take into account the player line of sight. As a result, it could enable a light hidden behind a wall. Given the cost of each one of them it was necessary to make a special optimization for them.
Light being disabled when outside of the player line of sight
All those optimizations are not necessary at all to make a cool game, but they definitely helped clearing some space for performances. If you are a gamer, I hope you enjoyed reading this behind the scene article. If you are a developer, I hope it can give you some ideas. Don't forget to take a look at our steam page and to follow us on IndieDB.