Architettura del framework di gioco - visualizzare i componenti o MVC?

Question

Sto cercando di creare un framework riutilizzabile molto leggero per i miei giochi, piuttosto che ricominciare da capo ogni volta che avvio un gioco. Ho un'architettura basata sui componenti, ad es. Entity compone un componente Position, un componente Health, un componente Ai ecc.

La mia grande domanda è se il mio modello compone i componenti della vista per consentire più di una vista del modello o se utilizzare un MVC più vero in cui il modello non è a conoscenza delle sue viste e loro sono gestiti esternamente.

Ho provato entrambi i metodi, ma se qualcuno conosce i pro ei contro di ogni approccio e qual è lo standard del settore, sarebbe bello saperlo.

Answer 1

dipende dal tuo pubblico, dagli sviluppatori di giochi, incluso me stesso non sono molto abituati al modello MVC, anche se la maggior parte lo sa, non è così facile mantenerlo pulito, a causa delle perdite di sviluppo (non di gravi ragioni tecniche). Quindi, per esperienza, ho visto decine di framework di gioco iniziare come MVC, ma solo una coppia è stata in grado di mantenerlo fino alla fine. La mia teoria è che MVC aggiunge troppa complessità e piccoli benefici per i piccoli giochi usa e getta (con normalmente pochi sviluppatori), ed è difficile mantenere la maggior parte degli oggetti di gioco in questi livelli per giochi grandi / complessi. E poiché i giochi hanno una data di rilascio, molte volte sacrificano la chiarezza del codice e la riusabilità per prestazioni e soluzioni rapide ad hoc (che verranno riscritte se necessario nel sequel (se ce n'è uno)).

Tuttavia, con l'avvertenza sopra, è meglio puntare in alto, perché se ci riesci è meglio :) e se fallisci, anche male. Quindi dovresti probabilmente provare l'MVC, ma non preoccuparti se fallisce, gli sviluppatori di giochi professionali hanno fallito molte volte nell'attività :)

Answer 2

Io certamente voterei per il modello di non sapere nulla delle sue opinioni. L'accoppiamento lento è buono: codice modello più semplice, test più facili, più scelte.

Answer 3

So che questa domanda potrebbe essere obsoleta, ma devo rispondervi. In realtà, ho iniziato a programmare un gioco a Lua (con L & # 214; VE) e ho iniziato a programmare un MVC - Framework per esso. Inizialmente, usare MVC dipende davvero da cosa vuoi. Conosco i miei problemi con la programmazione del gioco, quando il programma diventa più grande, e soprattutto la struttura diventa troppo complessa da mantenere. La prossima cosa è che so che cambierò tutta la grafica quando trovo un artista che è disposto a lavorarci. Ma fino ad allora, userò la mia grafica fittizia. Voglio che l'artista si senta libero di fare tutto ciò che vuole, senza dipendere da alcuna risoluzione o restrizione di colore. Ciò significa che potrei dover cambiare l'intero codice di presentazione (!). Forse anche il modo in cui gli oggetti interagiscono (rilevamento delle collisioni, ad es.). La logica di gioco è catturata nei modelli, quindi posso concentrarmi su quello. E penso che la logica di gioco sia la parte più importante della creazione di un gioco. No? Spero che tu veda il mio punto.

Ma se hai tutto insieme: tutta la grafica, i suoni, il tutto; allora puoi programmare direttamente.

Il mio MVC è una configurazione-over-convention-ass, che rallenta un po 'la prototipazione. MA (!) Le iterazioni di sviluppo possono essere rese molto più facilmente. I test, in particolare i test unitari, vengono eseguiti molto più rapidamente. Direi che MVC trasforma la tua curva di velocità di sviluppo (che normalmente è una curva anti-esponenziale) in una curva esponenziale. Lento all'inizio, ma sempre più veloce alla fine.

Answer 4

MVC funziona davvero bene per i giochi, almeno per i miei giochi progettati per multipiattaforma. Dipende davvero da come lo si implementa per ottenere il vantaggio.