I haven’t played Stellaria in a while, but I don’t remember the performance being bad. If it is it’s not because of any graphical thing that can be improved, but for the same reason Dwarf Fortress runs like shit, i.e. there’s a limit to your CPU power when simulating hundreds of individuals.
The problem with Stellaris is that they simulate every individual even if nothing changed about them. If nothing changes on a planet or species then they shouldn’t recalculate employed pops.
Easy, event driven updates. Populations would all have a flag “should_update” which defaults to false.
When a population update event occurs, like constructing a building on a planet, you mark should_update for all the pops on that planet to be reevaluated.
Unemployed pops would have should_update until they are employed.
Changing a species would should_update for every pop that got gene modded.
Then every day you only run updates for pops with should_update set to true instead of every pop in the galaxy.
Late game performance would be on par with early game because a lot of planets have been forgotten about
In order to reshuffle pops to make sure they’re in the best jobs, there could be a timer per planet, based on things like the size of the planet, time since last migration, etc to trigger a should_update for the whole planet.
It’d be even better to just trigger the updates during the event and completely get rid of the polling loop, but that would require a lot more work in the paradox engine
That’s literally what the game already does. But it can’t have all the effects you believe it should have, because there are a lot of events that can change a modifier that would require a recalculation.
Also marking thing as “should_update” (like you called it here) the way you describe it would cause terrible performance issues. You can’t mark large amount of pops for an employment update, because employment calculations are some of the more expensive ones to do, and doing it for large amounts of individual pops at a time would cause severe lag spikes.
When the community researched the issue back in 21 it definitely seemed like there wasn’t any optimization because the monthly load was consistent and the major slowdowns appeared around pop job computing.
We may have been wrong because we were using profilers and decomps, which can lead to bad assumptions, but that’s what we saw.
I haven’t played Stellaria in a while, but I don’t remember the performance being bad. If it is it’s not because of any graphical thing that can be improved, but for the same reason Dwarf Fortress runs like shit, i.e. there’s a limit to your CPU power when simulating hundreds of individuals.
The problem with Stellaris is that they simulate every individual even if nothing changed about them. If nothing changes on a planet or species then they shouldn’t recalculate employed pops.
How would you know if nothing changed unless you’re simulating them?
Easy, event driven updates. Populations would all have a flag “should_update” which defaults to false.
When a population update event occurs, like constructing a building on a planet, you mark should_update for all the pops on that planet to be reevaluated.
Unemployed pops would have should_update until they are employed.
Changing a species would should_update for every pop that got gene modded.
Then every day you only run updates for pops with should_update set to true instead of every pop in the galaxy.
Late game performance would be on par with early game because a lot of planets have been forgotten about
In order to reshuffle pops to make sure they’re in the best jobs, there could be a timer per planet, based on things like the size of the planet, time since last migration, etc to trigger a should_update for the whole planet.
It’d be even better to just trigger the updates during the event and completely get rid of the polling loop, but that would require a lot more work in the paradox engine
That’s literally what the game already does. But it can’t have all the effects you believe it should have, because there are a lot of events that can change a modifier that would require a recalculation.
Also marking thing as “should_update” (like you called it here) the way you describe it would cause terrible performance issues. You can’t mark large amount of pops for an employment update, because employment calculations are some of the more expensive ones to do, and doing it for large amounts of individual pops at a time would cause severe lag spikes.
Oh they finally added that? Nice. The community has been asking for event driven since 2019 so it’s nice to know they added it. I’m gonna reinstall
That was always in there, but the degree of optimization varied of course.
When the community researched the issue back in 21 it definitely seemed like there wasn’t any optimization because the monthly load was consistent and the major slowdowns appeared around pop job computing.
We may have been wrong because we were using profilers and decomps, which can lead to bad assumptions, but that’s what we saw.