Blog Schedule

Today I want to provide some insight about my plans with this dev-blog. My intent is to write blog posts on a regular basis to maintain a constant flow of information from our side to our community. The current plan is to release a blog post every Sunday. Depending on the timezone and my habit of working at night for some of you the blog posts will appear on Monday. At this point I am not 100% sure if there is enough information after 7 days, maybe I have to re-evaluate the interval, however I definitely want you to know when the next post will appear and therefore keep a fixed interval.

‍Weekly Updates

Since the last post we've been mostly working on the balancing and game-testing. I can happily announce that the balancing and game-testing for the first alpha release are done and that the improvements on performance are promising. This is the main focus for now, and depending on how much we change by improving the performance we might need to do additional game-testing afterwards. So again I cannot narrow down the release day, but I can assure that we're making good progress. "This Summer" still seems reasonable.

‍Performance [Technical]

Our current goal is to get steady 60 FPS on the recommended hardware requirements and I hope to achieve this by the time I write the next blog post. In the following lines I will explain the basic architecture and the technical fundamentals of the game in a very short way. Longer in-depth technical posts might follow.

FOUNDRY is a simulation-heavy game and therefore mostly CPU-dependent. Currently 90% of frame-time of an endgame factory is CPU-time as it's really costly to update thousands of different entities many times per second. Currently the biggest time-consumer is the belt system and the items it carries + the machines interacting with the belts. The game is made with Unity and therefore uses C# scripting compiled to C++ binaries via IL2CPP. C# in general is pretty slow for what we're trying to accomplish, so the IL2CPP compiler is nice as C++ is a lot faster. But that alone still wouldn't get us anywhere with that kind of game: A lot of the internal mechanics are within an external C++ library as we need to have exact control to really fine-tune all the performance-heavy tasks. There is plenty of ways to increase performance but most of it is pretty time-consuming to implement, for example parallelization: Some entities' actions can be calculated simultaneously as they don't depend on each other. We could always move more stuff to the C++ part, but at a certain point the P/Invoke overhead and it's limitations (only static C# methods can be called from the C++ part) would outweigh the benefit. At the moment we're pretty close to our goal for the first release, so we don't need to do anything crazy for now. But it will be a ever-lasting struggle when we add more content and factories grow bigger and bigger.

mrmcd