2012-05-16 12 views
21

Sto scrivendo un semplice simulatore di sistema solare. Questo è il mio primo progetto libgdx. Sto usando uno stage e attori per il menu principale ed è piuttosto maneggevole soprattutto la gestione degli eventi touch. Ma ... guardando gli esempi vedo che nessuno usa gli attori nella logica di gioco reale. Vago se dovrei usare l'attore come genitore di un pianeta o semplicemente scrivere la mia classe per quello. I pianeti non saranno tangibili e saranno spostati solo tra i fotogrammi in modo che il terzo parametro di azione MoveBy dovrà essere il tempo tra i fotogrammi. Questi sono i contro. Quali sono i vantaggi nell'usare gli attori?Quando utilizzare gli attori in libgdx? Cosa sono i contro e i pro?

+5

Credo che molti degli esempi di libGDX precedenti il ​​supporto di Stage + Actor, in modo che possa spiegare perché non lo usano. –

risposta

36

I principali professionisti per gli attori sono azioni, test di hit e touch events e gruppi di attori.

Le azioni rendono l'interpolazione facile e veloce se la logica del gioco lo richiede.

È possibile chiamare stage.hit (x, y) in qualsiasi momento per restituire il primo attore che restituisce true a qualsiasi logica di hit scritta per esso (in genere controllando i limiti con x, y, width, height). restituire questo attore o null per continuare a scorrere tra i metodi di hit degli attori alla ricerca di un attore di successo. Null viene restituito se nessun attore viene colpito.

Il colpo viene utilizzato per gli eventi tattili dello stage. I metodi tattili dell'attore ricevono le coordinate locali e lo stage gestisce la sovrapposizione di oggetti, ad es. se un attore copre un altro attore in modo che l'altro attore non debba ricevere touchDown, restituisce true all'attore di copertura per interrompere la chiamata di touchDown sugli attori "sotto". Questo imposta anche "focus" sull'attore che restituisce true in modo che venga chiamato il touchUp dell'Actor.

È possibile raggruppare attori per eseguire azioni, toccare eventi, ecc. Sull'intero gruppo di attori come una singola unità.

Alcuni svantaggi: Gli attori richiedono uno stage che limita un po 'la funzionalità. Molti codificatori usano altre logiche per determinare lo stato dell'oggetto di gioco, piuttosto che le azioni scene2d (ad esempio box2d). Se usi gli attori per gli oggetti di gioco, probabilmente vorrai due fasi, una per gli ui e una per il mondo di gioco. Se non li usi, probabilmente utilizzerai comunque SpriteBatch e Camera. E ricorda che gli attori hanno solo un metodo di estrazione astratto, quindi dovrai comunque creare la logica di estrazione. Probabilmente manterrai TextureRegion o Sprite come campo privato per l'attore. Se si desidera utilizzare la propria logica di aggiornamento, è possibile sovrascrivere il metodo act (float delta) per ottenere il delta time (chiamare super.act (delta) se si utilizza Actions).

Quindi, se si dispone di una propria logica e non si utilizzerà molto di ciò che Stage ha da offrire, risparmiare alcune risorse e eseguire il rollover della propria soluzione specifica per l'applicazione. Se puoi usare alcuni dei pro senza limitare le funzionalità necessarie, allora vai per un secondo stadio per la logica di gioco.

+1

È possibile usare sia Scene2D che box2d, anche se è ovvio che alcune cose possono risultare scomode. In generale, però, è perfettamente possibile e lo sto effettivamente facendo. Per oggetti dinamici, devi semplicemente ricavare la posizione del tuo attore dal modello fisico. Ciò significa ovviamente che gli "Action" sono in qualche modo inutili, dal momento che il movimento va solo dalla fisica all'Actor, non viceversa. Tuttavia, si ottiene sempre la gestione degli input, un sistema di eventi, la gestione della telecamera e la mappatura delle coordinate gratuitamente. Le azioni possono ancora essere utilizzate per elementi visivi senza un corpo fisico (ad esempio oggetti equipaggiati, sprite degli effetti, ecc.) – Matthias

Problemi correlati