View Issue Details

IDProjectCategoryLast Update
0021429AI War 2Gameplay IdeaAug 9, 2019 2:19 pm
ReporterChris_McElligottPark Assigned ToChris_McElligottPark  
Severityminor 
Status resolvedResolutionfixed 
Product Version0.877 The Strikecraft Goldilocks Zone 
Fixed in Version0.880 Belatedly Finding Friends... And Enemies 
Summary0021429: Performance Boost: Sim Step Bundling For Background Battles
DescriptionOkay, this is based on 0021288, but frankly was going to be needed no matter what. Here are the relevant changes.

1. On the performance tab in galaxy settings, under we'll have a new "Advanced: Background Sim Step Bundling" option, or something to that effect. It is an integer that is between... let's say 4 and 10, at least for now.

2. We'll now start calculating a sim-integrated "planet that each player is looking at," which will be remembered by the game. We may already have this, I can't recall, but we'll start using it and making it sim instead of nonsim, and make sure that it's network-synced. It will by nature often be 200-400ms behind the real, local, "planet THIS player is looking at," but that's absolutely fine. Even if you're looking at the galaxy map, it will count the planet you are "at" as being the planet you're looking at. It will be transmitted as-it-changes from clients and the host equally.

3. There will now be three tiers of planets:
1: Planet any player is looking at (continue working as now)
2: Planet with any player ships on it, but no player is looking at it (halfway measures)
3: Planet without any player ships on it, and also no player looking at it.

4. At the start of each sim step, the game will calculate what tier each planet is in, and it will also remember the current BackgroundPlanetCycle of the world, which will go from 0 to BackgroundSimStepBundling -1. That will increment by 1 each sim step, and loop around.

5. Each planet that is in tier 3 will ONLY do any of its ship processing (battles, long term planning, etc), on cycles that equal its PlanetIndex % BackgroundSimStepBundling. So essentially if the BackgroundSimStepBundling is 4, it will happen every 4 sim steps (every 400ms), and if it's 10 it would be every 1 second.

6. Each planet will have a new LocalDeltaTime associated with it, and I'll rename the global delta time in some fashion to make sure we stop directly using that for sim stuff, ever. Basically the planets in the background will be running only 1/4 or 1/10th as often, but will be doing 4x or 10x "as much" each sim step that they do something. This is kind of like our current method of fast-forwarding. "Doing more" is actually free on the CPU, since it's just a divisor or multiplier saying that the movements go further, etc. It's all based on that DeltaTime multiplier and will mostly "just happen."

The TLDR of this is that we'll cut our general background processing either into a quarter of what it is, or a tenth, depending on what people choose for their option. And all the processing that does happen will still be spread across all the frames. If one set of planets with giant battles are all on the same cycle bundle by unfortunate coincidence, then it will get slightly hitchy... MAYBE. Most likely since this is on the background threads it won't affect responsiveness, and all the lerping that is already done would make it so that the visual hitching of a slow sim step every 10th step or whatever won't be noticeable. If it becomes a problem then we can try doing intelligent load balancing, but that seems like it will be overkill.

7. On tier 2 or tier 3 planets, we will no longer spawn shot objects at all.... well, almost not at all. On tier 2 planets, if a player ship is shooting or being shot at, then those will still spawn shot objects like normal. But the other ships that might shoot at each other on those same planets will not spawn shot objects.

7.a. Rather than shots being something that spawn and have to move, and get taken into and out of pools and have a fair bit of data with them, we'll just make them impact instantly. This does change the balance some, but not enough to particularly worry me. If it would hit a forcefield it will still calculate that it should do so, etc. We aren't really using shots with long chase times anyway, so the effect on the results of the battle should be pretty marginal. And it won't affect player ships for good or ill.

8. On tier 3 planets only, we will switch to using a square radius for ranges -- aka, using VeryBasicWrongRange or similar. This is something that involves subtraction instead of multiplication followed by a square root. The amount this will cut down on the targeting costs is insanely huge, but of course it will "look wrong" to anyone who was watching. Which will be nobody, by definition. ;)

9. On tier 3 planets only, we can also consider switching to using a FastRandom instead of a QualityRandom for the battle-related calculations. For tier 2 planets, with non-player ships we might even want to use that there, too. It's a much more minor savings, but adds up over a lot of calculations.

So actually these latter things have nothing to do with the bundling, but are just related to the idea overall.
TagsNo tags attached.

Relationships

related to 0021288 resolvedChris_McElligottPark Serious Slowdown (Chris notes: proto-simulation needed for background third-party fights.) 

Activities

Chris_McElligottPark

Aug 9, 2019 2:19 pm

administrator   ~0052511

* Added a new setting to the Performance section of the galaxy map: "Advanced: Coarse-Process BG Planets"
** Unless you are having a problem with the simulation for some reason, this should be left on. This makes background planets take up far less processing than they otherwise would, particularly when a bunch of third party factions are battling and you can't even see.

* When the coarse-processing is on, then planets are divided into three tiers:
** Tier 1 planets have a player looking at them or at least at them, and they work like normal.
** Tier 2 planets have player ships at them but no player there.
** Tier 3 planets have no player or player ships there.
** Tier 2 and 3 planets both skip creating shots for any shots that are headed to any non-player ships, and just have them insta-hit. Same for AOE damage, etc. This is the number one performance-improver out of all this.
** Tier 3 planets use very cheap square ranges instead of the usual circular ranges for everything from ships to gravity effects to collisions, which saves some processing power during big battles between unseen background factions in particular.
** Tier 2 and 3 planets ony run updates every 10 sim steps, rather than every sim step, but act like they are on 10x speed for the sim steps they are on. All those planets are batched so that 1/10th of the planets get processed every sim step.
** The overall savings on one of our test case games was to improve performance from 31% to 68% or more.
*** It really seems like we ought to be able to get these numbers even higher, but we're not sure just at this moment exactly what is sucking up the performance. Anyone who wants to pick at this and use more of the planet.BattleStatus_ProcessThisSimStep logic on non-long-term-threads and non-per-second methods is definitely welcome to look at it.
*** We also wanted to go ahead and get this in place sooner than later not just so that people can see the performance benefits immediately, but also so that if there are bugs resulting from this we have time to fix those.

* A bunch of the shot-hitting logic, AOE logic, and related have been moved into the open-source parts of the game.

* The escape menu now shows the counts of tier 1, 2, and 3 planets, the number of shots that have hit (since game load), and the number of entities that have died (also since game load).
** This way you can get a sense for how things are progressing in the background if things are slow, for instance; and to be sure that shots are actually hitting and killing things.

Issue History

Date Modified Username Field Change
Jul 30, 2019 5:55 pm Chris_McElligottPark New Issue
Jul 30, 2019 5:55 pm Chris_McElligottPark Status new => assigned
Jul 30, 2019 5:55 pm Chris_McElligottPark Assigned To => Chris_McElligottPark
Jul 30, 2019 5:55 pm Chris_McElligottPark Relationship added related to 0021288
Aug 9, 2019 2:19 pm Chris_McElligottPark Status assigned => resolved
Aug 9, 2019 2:19 pm Chris_McElligottPark Resolution open => fixed
Aug 9, 2019 2:19 pm Chris_McElligottPark Fixed in Version => 0.880 Belatedly Finding Friends... And Enemies
Aug 9, 2019 2:19 pm Chris_McElligottPark Note Added: 0052511