From the soapbox #3

Believe it or not, we have some good news for you! At this point, we are searching for ways to upgrade the performance and the framerate. We want you to have the best experience possible while playing The Guild 3 and we are doing everything we can for that ;-).

So, while some of us are “playing” with motion captures, others are doing their best to improve the gaming experience. It’s been a long time since we started working on that because we can always improve it. Like we said not so long ago about the lack of gameplay videos, there are reasons for that. Essentially, while the game has been running for a while, there was multiple and significant performance issues due to all the data that we’re shoveling around. All of that was causing a not so optimal framerate. We needed to address that!

There’s been multiple tests along the line of development; we tried making the multithreading of the renderer better and now we’re at the stage where we are getting beautiful results. It’s exciting, because today we can truly talk with you about significant progress in that aspect!

Essentially, what we did was focus a lot of engineering effort on making the multithreading of the renderer better (like we said above). With everything we’ve done with The Guild 3, the engine is really being pushed to its limits. We have dozens of buildings on the screen at the same time, hundreds of characters, props, special effects, etc. on top of everything else that a normal game has to take care of: path finding, AI, sounds and music, inputs, etc.
All of that processing power wasn’t distributed correctly and it needed an overhaul. But anyone who has ever programmed at that level will tell you – multithreading a large project like that (coming close to the 1.5 million lines of code) is no small undertaking. It was (and still is) our mission! Because there was already some multithreading, but it wasn’t optimal. We really needed to isolate the rendering thread more, but that brings up loads of issues and modifications: destroying a model while it’s being accessed by the AI, or while there’s still a sound connected to it, all without falling to the temptation to use a BFM* to quickfix it all and kill the performance gains that we were going for.

Of course, with all these trials, many things changed and some others have “fallen” in the darkness of the abyss. Some assets needed modifications after all, like the buildings’ roofs (to give you one example). The level of detail (LOD) needed to be adjusted if we wanted to win a couple of frame seconds, so our wonderful team of artists worked a lot on that. And they still are!

In the same vein, other things that needed to change (or be adjusted) were the maps. Some of them had to be pruned a little. Paris, for example, is a massive urban agglomeration that just kills the CPU, because we tried to do it soooo realistically, with as many details as possible.

And we still need to optimize other parts of the code before launch to make it run smoother. No choice! But all in all, we’re a little relieved that we’re getting close to the targeted performance and we can resume our focus on the last gameplay tests and modifications!

And we prevailed! While not everything is back to smooth sailing and we’re still hunting some bugs and crashes left and right that need to be adjusted, the overall gains in performance was really worth it. It’s not perfect yet, but on fast machines, you can play with the settings cranked up to the maximum and get decent (30fps) performance!

So don’t worry and rest assured, you will have your favorite game soon, and it will be with the best performance we can offer you!

GolemLabs

 
* BFM – Big Fu**ing Mutex​