Logica del gioco Libgdx in Render?

Question

Sto imparando Libgdx e ho alcune domande sull'aggiornamento della logica di gioco durante il metodo di rendering.

Preferirei mantenere la logica di gioco e il rendering separati. Il motivo è che se avessi un FPS alto su un sistema il mio ciclo di gioco sarebbe "accelerato" più veloce.

quello che sto cercando è quello di mantenere l'experance costante e possibilmente limitare il mio updates..if qualcuno mi può puntare verso un tutorial su come a) limitare il mio rendere gli aggiornamenti via tempo delta b) limitare la mia logica di gioco aggiornamenti via Deltatime.

voi :) Grazie

Answer 1

La risposta finora non sta utilizzando thread paralleli - ho avuto questa domanda io stesso in passato e sono stato consigliato contro di essa - link. Una buona idea sarebbe quella di eseguire prima l'aggiornamento mondiale, e quindi saltare il rendering se non c'è abbastanza tempo per il frame. Tuttavia, i tempi Delta dovrebbero essere utilizzati per mantenere tutto liscio e prevenire il ritardo.

Se si utilizza questo approccio, sarebbe opportuno evitare più di X salti di frame consecutivi, poiché nel (improbabile, ma possibile, a seconda di quanto logica di aggiornamento è rispetto al rendering) caso che la logica di aggiornamento dura più del tempo totale assegnato per un frame, questo potrebbe significare che il tuo rendering non avviene mai - e questo non è qualcosa che vorresti. Limitando il numero di frame che salti, ti assicuri che gli aggiornamenti possano essere eseguiti senza problemi, ma garantisci anche che il gioco non si blocchi quando c'è troppa logica da gestire.

Answer 2

Dopo aver riletto la tua domanda, penso che il trucco che ti manca (basato sul tuo commento che l'esecuzione su un sistema di aggiornamento più alto comporterebbe il rallentamento della tua logica di gioco), è che ridimensionhi effettivamente gli aggiornamenti basati sul tempo "delta" passato al rendering. Andrei Bârsan lo menziona sopra, ma ho pensato di elaborare un po 'su come viene usato il delta.

Ad esempio, all'interno del mio rendering del gioco(), prima chiamo il mio entityUpdate (delta), che aggiorna e sposta tutti gli oggetti nel mio gioco ridimensionati dalla distanza percorsa nel tempo "delta" (non rende loro, sposta semplicemente le loro variabili di posizione). Poi chiamo entityManageCollisions (delta), che risolve tutte le collisioni causate dall'aggiornamento, quindi definisco infine entityDraw (batch, delta), che usa delta per ottenere i fotogrammi giusti per le animazioni sprite e in realtà disegna tutto sullo schermo.

Uso una variante di un modello Entity/Componet/System in modo da gestire tutte le mie entità genericamente e quelle chiamate di metodo che ho menzionato sopra sono essenzialmente "Sistemi" che agiscono su Entità con determinate combinazioni di componenti su di esse.

Quindi, tutto questo per dire, passa delta (il parametro passato a render()) in tutta la tua logica, così puoi ridimensionare le cose (spostare le entità della distanza appropriata) in base alla quantità di tempo trascorso da l'ultima chiamata. Ciò richiede che tu imposti le tue velocità in base a unità/secondo per le tue entità, dal momento che stai passando un valore per ridimensionarle di una frazione di secondo. Una volta che lo fai qualche volta, e sperimenta i risultati, sarai in buona forma.

Si noti inoltre: Questo ti farà impazzire nelle sessioni di debug interattive, dal momento che il timer delta continua ad accumulare tempo dopo l'ultima chiamata di rendering, causando i soggetti di sorvolare l'intero schermo (e non solo - verificare quei confini per voi!dato che generalmente ottengono aggiornamenti sub-second, ma possono finire per essere passati 30 secondi (o per quanto tempo hai passato a guardare cose che passano attraverso il debugger), quindi in cima al mio render(), ho una riga che dice delta = 0.016036086f; (quel numero era un esempio di detla dalla mia workstation di sviluppo e sembra dare risultati decenti: è possibile catturare il delta tipico del proprio sistema video scrivendolo alla console durante un'esecuzione di test e utilizzare invece quel valore, se si mi piace) che commento per le build da distribuire, ma lasciano i commenti non commentati durante il debug, quindi ogni frame sposta il gioco in avanti di un importo consistente, indipendentemente da quanto tempo trascorro guardando le cose nel debugger.

Buona fortuna!