Bridging delle pratiche di sviluppo delle applicazioni e delle pratiche di sviluppo del gioco

In precedenza mi sono imbattuto in una pratica interessante chiamata occultamento nello sviluppo del gioco. Sto ancora facendo ricerche per comprendere meglio come funziona, dal momento che questo è per lo più discusso in programmazione / strumenti / IDE di giochi come Unity, quindi sto applicando la pratica alla gestione dei dati nello sviluppo di applicazioni.

Altri nomi per la pratica come definiti nella wiki qui : Determinazione della superficie (nota anche come rimozione della superficie nascosta (HSR) ), occlusione culling (OC) o determinazione della superficie visibile (VSD))

La mia comprensione della pratica è che quando si esegue il rendering della grafica 3D, viene utilizzato un algoritmo per determinare quali oggetti devono essere renderizzati e in memoria, in base ad una prospettiva vista / telecamera. Questo è principalmente usato per usare la memoria grafica in modo più efficiente, ma non rende necessariamente più efficiente l'utilizzo della memoria non grafica, dato che i dati dietro gli oggetti non renderizzati sono ancora manipolati.

Per quanto riguarda l'applicazione pratica, sto tentando di utilizzare l'aspetto della gestione dei dati caricati durante l'esecuzione di un'applicazione, in cui i dati potrebbero essere righe, valori specifici o alcuni oggetti.

Dal punto di vista di un'applicazione, questo sembra essere simile a una qualche forma di caricamento lazy o chiamate / eventi senza stato.

private Lazy<Foo> DataItem;
public void GoToNextView()
{
    DataItem = new Lazy<Foo>();
    //return data to some display
}

Per l'esempio precedente, i dati precedenti verrebbero cancellati / impostati per la garbage collection tramite il nuovo costruttore, quindi ci sarebbero nuovi potenziali dati da caricare.

Ecco un esempio specifico:

Per alcune tabelle paginate, ci sono solo dati specifici per la pagina caricata, quindi su "Avanti" la pagina precedente viene scaricata e viene caricata la nuova pagina. questa pratica si presta a essere più basata sugli eventi nella mia mente, e ciò è dovuto principalmente al pensiero in termini di interfaccia utente / aspetto front-end di un'applicazione. A meno che non si stia manipolando i dati dal codebehind di alcune UI, non riesco a vedere un buon esempio dell'utilizzo del pigro come aiuto nella gestione dei dati, dal momento che l'interfaccia utente caricherà i dati più immediatamente anziché attendere un passaggio specifico. (si prega di correggere se la mia comprensione non è corretta tra il caricamento lazy e stateless)

Dal punto di vista di una libreria / libreria personalizzata, credo che potrebbero esserci più differenze tra le due pratiche, dal momento che esiste il potenziale per più istanze di manipolazione dei dati e passaggi incrementali che possono precedere determinati carichi di dati.

private Bar DataItem;
public Bar Process()
{
   DataItem = new Bar();
   //return some processed/manipulated Bar value
}

private Lazy<Bar> OtherDataItem;
public Bar OtherProcess()
{
    OtherDataItem = new Lazy<Bar>();
    //process other items
    //at some step, get the value associated to the variable via OtherDataItem.Value
    //return some processed/manipulated Bar value in respect to the other processed items
}

In questo caso, c'è una differenza nella gestione dei dati, in cui il primo manterrà i dati completi associati al tipo dall'inizio alla fine (la fine è una delle estremità del metodo o la raccolta / eliminazione dei dati inutili). Dalla mia comprensione del pigro, i dati non verranno effettivamente recuperati fino a quando non viene chiamato il valore, quindi i dati non verranno mantenuti dall'inizio alla fine (credo che ci sia anche un controllo in background per lo smaltimento dei dati inutilizzati per i tipi pigri, e non so se è vero o si occupa di qualche altra cosa specifica.

Sto cercando pratiche nello sviluppo di applicazioni che raggiungano lo stesso obiettivo di gestione dei dati basato sull'essere a fuoco come la pratica osservata nello sviluppo del gioco. Non so se c'è una possibilità che questo sia effettivamente uno strumento piuttosto che una pratica, dal momento che la ricerca tende a condurmi verso l'utilizzo in Unity.

Per le mie domande, quali pratiche di sviluppo delle applicazioni rientrano effettivamente nella pratica di gestione dei dati mostrata nell'eliminazione dell'occlusione dalle pratiche di sviluppo del gioco? Se le precedenti due pratiche di sviluppo dell'applicazione sono equivalenti a quella pratica di sviluppo del gioco, allora la comprensione che sto cercando di trasmettere sembra accurata?

Ancora una volta, sto ancora ricercando e immergendomi in tutte le informazioni che riesco a trovare, e le mie conoscenze potrebbero non essere corrette su entrambi i lati (sviluppo di applicazioni o giochi). Sento che sono ad un punto, dove ho bisogno di avere un controllo sulla mia comprensione prima di impegnarmi in questa idea e avanzare. Accolgo con favore eventuali correzioni o domande a mio avviso.