Hello everyone,
Every time we publish a devblog players reach out to us asking about the roadmap updates, while others criticize us for adding new features without care for optimization or existing content. So, this time we’ll try to explain the logic behind Hellion’s development process.
When we initially envisioned Hellion as a game, we had this grand idea of a game we always wanted to make. As we began putting ideas and concepts together it became obvious that an ambitious multiplayer open-world game like that might just be beyond what a small team like Zero Gravity could deliver. So we gradually began toning down the scope of Hellion. That’s when we decided to go with Early Access model after we thought of all the benefits it would include. First one was feedback directly from the player base, since we believe that players should be the ones to decide if something is suitable for the game or not since they are the ones who will be playing it for hours. This model also helped us iron out some of the major flaws in our development process, as some features did look great on paper and seemed to fit perfectly into the game world, when in actual gameplay they felt totally out of place.
So we’ve learned to adapt and listen to each other and most importantly to our players. We have also decided not to plan every single thing from start to finish and always leave room for changes based on feedback. After all we are not making a universe, but rather a game that is fun to play. So if there is a feature that we believe would be great for Hellion, we now first consider player submitted suggestions to try and see how well it would fit in with the current level of gameplay and existing mechanics. This often leads us to a conclusion that other features need changes or improvements before the new options can actually add to the player experience rather than take away from it.
Since our plans frequently change as the result of what is often called emergent development (concept borrowed from creators of ARK), we plan to start sharing mostly things that are planned for the next update. One of the things we most certainly do not want to do is over promise and then face backlash for not being able to deliver. This does not mean that we have given up on our “vision”. That vague but nevertheless grand outline is always with us and we believe that we are slowly moving towards it, one update at a time.
So, here’s the updated Roadmap containing mostly things that were already announced. For more, you’ll have to come back and check it regularly.
Optimization
Most optimization techniques that are frequently used in games like Occlusion Culling, Light Baking, Static Batching, etc. require that the scenes that make up the game world be static. Since in Hellion everything is in the state of constant motion and each module is a scene in the engine, most of those techniques were simply inapplicable. In order to optimize Hellion we had to write our own solutions from scratch.
Dynamic lights (along with dynamic shadows) had the most impact on the GPU and we always knew we would have to do something about that. Baking light onto the textures of the level is the most efficient way of making the scene look good while reducing the number of dynamic lights. Unfortunately for us, Unity only supports light baking for static scenes, so we had to modify our shaders as well as our pipeline (not an easy task by any account) to support pre-baked lightmap load in runtime. However, once we were done, it allowed us to drastically reduce the number of dynamic lights per module. And since lightmaps retain shadow information and apply it properly, they also remove the need for lights to cast realtime shadows.
Just for reference, a command module before the light bake had more than 20 dynamic lights with most of them casting shadows and after the light bake the same module has less than 10 lights with only 2 of them casting shadows. The final look is more or less the same. The only downside is that in some specific parts of the module you might notice that your character is not casting a shadow, if you look closely. On the upside, the light looks more realistic with calculated global illumination and even illumination from emissive surfaces. But the most important thing is the huge performance boost.
Another thing that we kept putting off and finally found time to mess with is the Texture Density. Texture density is the relation between the size of the pixels in the texture and the pixels on the screen. The object that most of the time occupies a very small portion of the screen needs to have its texture resolution reduced to correspond with the size on the screen. So we had to go through all the models that exist in Hellion and set the appropriate texture resolution for each of them, and there was no way in doing that automatically. In the end it also brought us an additional few frames per second, something that Hellion always needs.
The last thing that we have yet to do is the implementation of a custom Level of Detail and Occlusion Culling system. While we know that it can never be as efficient as it would be in a static environment we believe that it will also bring better performance especially for larger stations.
That’s all for today, folks. We’ll be at Gamescom next week, so if you want to meet us, be sure to ping us on Discord.
Fly safe,
Zero Gravity