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.
Like I said I haven’t played Stellaris in a while and never got into modding it so I’m not sure how the engine works, so correct me if I’m wrong. It’s my understanding that pops have a “life”, i.e. they get educated, they develop traits, they join factions, etc. those are not things that can be simulated only when something changes on a planet, otherwise crime/unrest would never change on a planet, traits wouldn’t be added/removed and factions wouldn’t grow/shrink or have demands unless you do something on that planet. Also there’s the migration from one planet to another, and the growth of pops and several other things that have to be simulated all the time and can’t be triggered by an event since they’re slow growing (and the slow growth is the simulation that happens every frame). Also, even on late game there should be probably a few thousand pops in the entire galaxy, right? If most of the time nothing was happening that would be a very fast loop, the fact that it’s not should be evidence that there is some calculation happening for every pop at every frame, because while you’re correct that an event system is much better for large amounts of data points, a few thousand is not that big, which is to say that a loop that checks all of these conditions and only does something heavy when one of them is true should not be as slow as you’re describing, sure it’s not optimal, but should only become a problem when you get to several million 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.
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.
Like I said I haven’t played Stellaris in a while and never got into modding it so I’m not sure how the engine works, so correct me if I’m wrong. It’s my understanding that pops have a “life”, i.e. they get educated, they develop traits, they join factions, etc. those are not things that can be simulated only when something changes on a planet, otherwise crime/unrest would never change on a planet, traits wouldn’t be added/removed and factions wouldn’t grow/shrink or have demands unless you do something on that planet. Also there’s the migration from one planet to another, and the growth of pops and several other things that have to be simulated all the time and can’t be triggered by an event since they’re slow growing (and the slow growth is the simulation that happens every frame). Also, even on late game there should be probably a few thousand pops in the entire galaxy, right? If most of the time nothing was happening that would be a very fast loop, the fact that it’s not should be evidence that there is some calculation happening for every pop at every frame, because while you’re correct that an event system is much better for large amounts of data points, a few thousand is not that big, which is to say that a loop that checks all of these conditions and only does something heavy when one of them is true should not be as slow as you’re describing, sure it’s not optimal, but should only become a problem when you get to several million pops.