Separazione logica di gioco e rendering

Question

Qual è il modo migliore per separare il codice di rendering dal motore di gioco/codice logico effettivamente? Ed è anche una buona idea separarli?

Supponiamo di avere un oggetto di gioco chiamato Cavaliere. Il cavaliere deve essere reso sullo schermo affinché l'utente possa vederlo. Ora siamo rimasti con due scelte. O diamo al Cavaliere un metodo Render/Draw che possiamo chiamare, oppure creiamo una classe di rendering che si occupa di rendere tutti i cavalieri.

Nello scenario in cui i due sono separati, il Cavaliere dovrebbe ancora contenere tutte le informazioni necessarie per renderlo, o anche questo dovrebbe essere separato?

Nell'ultimo progetto che abbiamo creato abbiamo deciso di lasciare tutte le informazioni necessarie per il rendering di un oggetto da memorizzare all'interno dell'oggetto stesso, ma avevamo un componente separato per leggere effettivamente tali informazioni e renderizzare gli oggetti. L'oggetto conterrebbe informazioni come dimensione, rotazione, scala e quale animazione era attualmente in riproduzione e in base a ciò l'oggetto di rendering avrebbe composto lo schermo.

I framework come XNA sembrano pensare di unirsi all'oggetto e il rendering è una buona idea, ma abbiamo paura di rimanere legati a uno specifico framework di rendering, mentre la creazione di un componente di rendering separato ci dà più libertà di cambiare framework a in qualsiasi momento.

Answer 1

Farei il possibile per rendere i vostri oggetti generici quanto fattibili e per evitare di codificare i fatti del gameplay nel vostro codice il più possibile.

E.g. hai una classe Entity o Object o Actor, e quella classe ha un puntatore al suo processo decisionale (la sua IA) e un puntatore alla sua rappresentazione grafica.

Il suo processo decisionale è necessariamente associato ai fatti del gameplay; infatti lo è una parte dei fatti del gameplay. Quindi questo è un posto dove potresti nominare il tuo decisore "KnightAi" o qualcosa del genere.

D'altra parte, la rappresentazione grafica è solo un po 'di grafica. Sarà disegnato come ogni altra entità. Hai un modello o alcuni bitmap e alcune animazioni o no ... Questo sarebbe/potrebbe essere chiamato qualcosa come "Modello" e caricherà le informazioni che viene detto di caricare definisce l'aspetto dell'entità al giocatore. Quando si tratta di rendere il tuo cavallo contro il tuo cavallo contro un castello, probabilmente scoprirai che tutti fanno la stessa cosa solo con dati diversi. Il tipo di dati che hanno è anche lo stesso, sono solo i contenuti che sono diversi.

Supponi che le tue entità siano tutte rappresentate come cerchi. Avresti semplicemente fatto in modo che puntassero su un CircleRenderer che prendesse le dimensioni che dovrebbero essere disegnate. Non crei una classe di rendering diversa per ogni dimensione (o colore, o qualsiasi altra cosa) diversa di cerchio che volevi!

Answer 2

Vorrei creare una classe separata KnightRenderer. Vantaggi:

• Separazione pulita tra la logica di gioco e il rendering. Lo stesso potrebbe persino funzionare su un server di gioco e non sapere nulla sul rendering.
• Classi più piccole e semplici, che riguardano una sola funzionalità.

Tutto le KnightRenderer ha bisogno di conoscere la Knight (posizione, stato) deve essere pubblicamente leggibile in Knight.

Le proprietà specifiche del rendering vanno nella classe KnightRenderer. Ad esempio, potresti voler far lampeggiare il cavaliere quando viene colpito, quindi dovrai memorizzare un contatore o un valore temporale.

Answer 3

So che arriverò in ritardo, ma per i futuri lettori, potresti essere interessato a un tutorial che ho scritto.

Non sono un vero e proprio esperto, ma questo è come vedere una corretta separazione degli interessi:
http://aurelienribon.wordpress.com/2011/04/26/logic-vs-render-separation-of-concerns/