Come migliorare le prestazioni per funzioni costose in 2d city builder

Ho già cercato risposte ma non sono riuscito a capire l'approccio migliore per gestire costose funzioni / calcoli.

Nel mio gioco attuale (un edificio di città basato su piastrelle 2d) l'utente è in grado di posizionare edifici, costruire strade, ecc. Tutti gli edifici hanno bisogno di una connessione a un incrocio che l'utente deve posizionare al bordo della mappa. Se un edificio non è collegato a questo incrocio, verrà visualizzato un cartello "Non collegato alla strada" sopra l'edificio interessato (altrimenti deve essere rimosso). La maggior parte degli edifici ha un raggio e potrebbe essere correlata anche tra loro (ad esempio un corpo dei vigili del fuoco può aiutare tutte le case entro un raggio di 30 tessere). Questo è ciò di cui ho bisogno anche per aggiornare / verificare quando cambia la connessione stradale.

Ieri ho riscontrato un grosso problema di prestazioni. Diamo un'occhiata al seguente scenario: Un utente può ovviamente cancellare anche edifici e strade. Quindi, se un utente ora interrompe la connessione subito dopo l'incrocio, devo aggiornare molti edifici contemporaneamente . Penso che uno dei primi consigli sarebbe quello di evitare i cicli nidificati (che sicuramente è una grande ragione in questo scenario) ma devo controllare ...

1. se un edificio è ancora collegato all'incrocio nel caso in cui una piastrella stradale sia stata rimossa (lo faccio solo per gli edifici interessati da quella strada). (Potrebbe essere un problema minore in questo scenario)

2. l'elenco delle tessere raggio e ottieni gli edifici nel raggio (anelli annidati - grosso problema!) .

   // Go through all buildings affected by erasing this road tile.
   foreach(var affectedBuilding in affectedBuildings) {
       // Get buildings within radius.
       foreach(var radiusTile in affectedBuilding.RadiusTiles) {
           // Get all buildings on Map within this radius (which is technially another foreach).
           var buildingsInRadius = TileMap.Buildings.Where(b => b.TileIndex == radiusTile.TileIndex);  
   
           // Do stuff.
       }
   }

Tutto ciò scompone il mio FPS da 60 a quasi 10 per un secondo.

Quindi potrei fare. Le mie idee sarebbero:

• Non utilizzare il thread principale (funzione di aggiornamento) per questo, ma per un altro thread. Potrei incorrere in problemi di blocco quando inizio a utilizzare il multithreading.
• Usare una coda per gestire molti calcoli (quale sarebbe l'approccio migliore in questo caso?)
• Conservare ulteriori informazioni nei miei oggetti (edifici) per evitare ulteriori calcoli (ad es. Edifici nel raggio).

Usando l'ultimo approccio ho potuto invece rimuovere un annidamento in questo foreach invece:

// Go through all buildings affected by erasing this road tile.
foreach(var affectedBuilding in affectedBuildings) {
    // Go through buildings within radius.
    foreach(var buildingInRadius in affectedBuilding.BuildingsInRadius) {
        // Do stuff.
    }
}

Ma non so se sia abbastanza. Giochi come Cities Skylines devono gestire molti più edifici se il giocatore ha una grande mappa. Come gestiscono queste cose ?! Potrebbe esserci una coda di aggiornamento poiché non tutti gli edifici si aggiornano contemporaneamente.

Non vedo l'ora di ricevere idee e commenti!

Molte grazie!

Copertura dell'edificio nella cache

L'idea di memorizzare nella cache le informazioni su quali edifici si trovano nel raggio di un edificio effettore (che è possibile memorizzare nella cache dall'effettore o nell'effetto interessato) è sicuramente una buona idea. Gli edifici (di solito) non si muovono, quindi ci sono poche ragioni per ripetere questi costosi calcoli. "Cosa influenza questo edificio" e "Cosa influenza questo edificio" è qualcosa che devi controllare solo quando un edificio viene creato o rimosso.

Questo è un classico scambio di cicli della CPU per la memoria.

Gestione delle informazioni sulla copertura per regione

Se si scopre che si sta utilizzando troppa memoria per tenere traccia di queste informazioni, vedere se è possibile gestire tali informazioni dalle aree della mappa. Dividi la tua mappa in regioni quadrate di n*npiastrelle. Se una regione è interamente coperta dai vigili del fuoco, anche tutti gli edifici di quella regione sono coperti. Quindi devi solo memorizzare le informazioni sulla copertura per regione, non per singolo edificio. Se una regione è coperta solo parzialmente, è necessario ricorrere alla gestione delle connessioni di costruzione in quella regione. Quindi la funzione di aggiornamento per i tuoi edifici dovrebbe prima controllare "La regione in cui questo edificio è coperto dai vigili del fuoco?" e se no "Questo edificio è coperto individualmente dai vigili del fuoco?". Questo accelera anche gli aggiornamenti, perché quando un vigili del fuoco viene rimosso, non è più necessario aggiornare gli stati di copertura di 2000 edifici, è necessario aggiornare solo 100 edifici e 25 regioni.

Aggiornamento ritardato

Un'altra ottimizzazione che puoi fare è non aggiornare tutto immediatamente e non aggiornare tutto allo stesso tempo.

Se un edificio è ancora collegato alla rete stradale non è qualcosa che devi controllare ogni singolo frame (A proposito, potresti anche trovare alcuni modi per ottimizzarlo in modo specifico esaminando un po 'la teoria dei grafi). Sarebbe del tutto sufficiente se gli edifici lo controllano periodicamente ogni pochi secondi dopo la costruzione dell'edificio (E se ci fosse una modifica alla rete stradale). Lo stesso vale per la costruzione di effetti di portata. È perfettamente accettabile se un edificio controlla solo ogni poche centinaia di fotogrammi "È ancora attivo almeno uno dei vigili del fuoco che mi riguardano?"

Quindi puoi fare in modo che il tuo ciclo di aggiornamento esegua questi costosi calcoli per poche centinaia di edifici alla volta per ogni aggiornamento. Potresti voler dare le preferenze agli edifici che sono attualmente sullo schermo, in modo che i giocatori ricevano un feedback immediato per le loro azioni.

Per quanto riguarda il multithreading

I costruttori di città tendono ad essere sul lato più costoso dal punto di vista computazionale, soprattutto se si desidera consentire ai giocatori di costruire molto grandi e se si desidera avere un'elevata complessità di simulazione. Quindi a lungo termine potrebbe non essere sbagliato pensare a quali calcoli nel tuo gioco possono essere gestiti in modo asincrono.

1. Lavoro duplicato .

Il tuo affectedBuildingssono presumibilmente vicini l'uno all'altro, in modo che il raggio diverso si sovrappongono. Contrassegna gli edifici che devono essere aggiornati, quindi aggiornali.

var toBeUpdated = new HashSet<Tiles>();
foreach(var affectedBuilding in affectedBuildings) {
    foreach(var radiusTile in affectedBuilding.RadiusTiles) {
         toBeUpdated.Add(radiusTile);

}
foreach (var tile in toBeUpdated)
{
    var buildingsInTile = TileMap.Buildings.Where(b => b.TileIndex == radiusTile.TileIndex);
    // Do stuff.
}

2. Datastructures non idonee.

var buildingsInTile = TileMap.Buildings.Where(b => b.TileIndex == radiusTile.TileIndex);

dovrebbe essere chiaramente

var buildingsInRadius = tile.Buildings;

dove Edifici è un IEnumerabletempo di iterazione costante (ad es. a List<Building>)