Decouple rendering and mechanics engine threads and introduce time diletation

3 votes

Somewhere in between 3-400 beavers the game starts to lag on normal(>>>) speed and has to be slowed down. While pausing the game or using a reduced speed, the graphic lag stops. Seems like the rendering and the mechanics engine are sharing the same thread. Decoupling these into separate threads (think of as a server-client approach, but both are in the same process space, and instead of IP they are using some in-process communication for state synchronization).

And after the decoupling the mechanics engine is still hitting the CPUs limit, start dilating time. Display an indicator to the user that its potato is at its limit, and physics is being calculated slower.

The physics engine hitting the CPU's limit shouldn't affect the rendering.

Under consideration Performance Suggested by: gczuczy (10 Jan, '22) • Upvoted: 21 Jan, '23 • Comments: 7

Comments: 7

11 Jan, '22
Gin Fuyou Admin
Please state your expertise with Unity development, as community moderator and a web developer myself I think it's not appropriate to give technical advises to developers, unless you at least understand the framework.
11 Jan, '22
gczuczy
I don't think this particular issue is specific to any given framework. I've met similar issues with all kind of codebases - which all either I've solved or working with its devs got the issues resolved.. It's not an interview, I don't think I have to explain myself, so please disregard the technical details.

After a bit of poking around with process explorer, it shows that the game has a fair amount of threads, one utilizing tops 24.8% CPU, a handful around max 3-8%, and the rest are idle. At the first glance seems like some code is blocking on something, which prevents it from utilizing the available CPU power to provide a smooth gameplay.

The point is, after a given infrastructure size the game lags, and reducing the speed as the given game grows - which after a while gets to the point where the game is unplayable.. The issue is known, that's all.
11 Jan, '22
Gin Fuyou Admin
gczuczy, please, don't take me wrong, but I've encountered a number of times when people gave technical advice obviously not understanding the topic, let alone it's already questionable to give talks about code base you don't see and project which concerns you can't know. Even generally a good idea not always a good suggestion because of implementation details. I find it disrespectful when someone meddles into professional work like that.

I take it that you have an idea about what are you talking about and take it as proper feedback, but generally I'm inclined to close topics like that immediately
unless I see a good reason not to.

Yes, problem with game losing performance with larger colonies is known, and devs said they have optimizations planed, but I don't have any details.
12 Jan, '22
gczuczy
Gin, No worries. I'm an software engineer, and regardless of the type of code, poking my nose into such things is part of my job IRL.

Anyway, these things can be really hard, and making blackboxish assumptions can indeed go wild. There are two definite signs that can be seen, and that's sure:
- Slowing time down "smoothes" back the visuals, meaning it's not the visuals that have gone too large for the computer to render, but something is preventing the rendering codepath to get its require running time to provide a smooth framerate. As this happens when the game instance is getting bigger, an obvious suspect is the background mechanics calculations.
- The (suspected) main thread not utilizing more than 25%-ish of the cpu. This means that time is spent on something else. Given there's no any noticable disk activity (and it's an SSD), and probably there's no other IO it should be dealing with, most probably it's some other kind of blocking.
12 Jan, '22
gczuczy
So, anything beyond that guessed from the outside (without knowing the code) is like playing darts in pitch-black. There are common suspects of course, like many games/engines prefer to start off with a single thread for various reasons, and in that case two different codepaths preventing each other from getting their time once one of their runtime increases is obvious. If a scripting language is involved, it's usually a good idea to check its multithreaded capabilities - like python blocks on GIL.

Anyway, i'm glad that the guys are aware of the issue, and I hope that they will solve it. Currently my gameplay pattern is like starting a new one, and once the game lags, just abandon it, while there are still lots of stuff to build and mechanics to try. And I don't think that's the intended usage experience here.
12 Jan, '22
Gin Fuyou Admin
Ok, thanks for feedback, devs eventually will see it, I know they check open topics.
07 Mar, '22
Jacob Havinga
I saw a topic that was closed ... Above 400 beavers and performance drops like a stone ... Somewhere at the end of last year ...
But it's still not solved ...