Architettura framework di gioco: visualizza 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 inizio un gioco. Ho un'architettura basata sui componenti, ad es. Entità compone di un componente di posizione e una componente di salute e la componente Ai ecc

La mia domanda è se il mio modello compone vista componenti per consentire più di una vista del modello, o se utilizzare un MVC più vero in cui la il modello non conosce i suoi punti di vista e sono gestiti esternamente.

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

Answer 1

dipende dal pubblico, gli sviluppatori di giochi, me incluso non sono molto utilizzati per il modello MVC, anche se la maggior parte lo sanno, non è così facile mantenerlo pulito, a causa di perdite di sviluppo (non per motivi tecnici seri) . Quindi, per esperienza, ho visto decine di framework di giochi iniziare come MVC, ma solo una coppia è stata in grado di mantenerla fino alla fine. La mia teoria è che MVC aggiunge troppa complessità e pochi vantaggi per i piccoli giochi usa e getta (con in genere pochi sviluppatori), ed è difficile mantenere davvero separati gli oggetti di gioco in questi livelli per giochi di grandi e complessi. E poiché i giochi hanno una data di rilascio, molte volte sacrificano la chiarezza del codice e la riusabilità per le prestazioni e le soluzioni rapide ad hoc (che verranno riscritte se necessario nel sequel (se ce n'è una)).

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

Answer 2

Preferirei che la modella non sapesse nulla delle sue opinioni. L'accoppiamento lento è buono: codice del modello più semplice, test più semplice, più scelte.

Answer 3

So che questa domanda potrebbe essere superata, ma devo rispondere. In realtà, ho iniziato a programmare un gioco a Lua (con LÖVE) e ho iniziato a programmare un MVC - Framework per esso. In un primo momento, utilizzare MVC dipende molto da ciò che si desidera. Conosco i miei problemi con la programmazione di giochi, quando il programma diventa più grande, e soprattutto la struttura diventa troppo complessa da mantenere. La prossima cosa è, so che cambierò tutta la grafica quando trovo un artista che è disposto a lavorare per questo. Ma fino ad allora, userò la mia stessa grafica fittizia. Voglio che l'artista si senta libero di fare ciò che vuole, senza dipendere da alcuna risoluzione o restrizione di colore. Ciò significa che potrebbe essere necessario modificare l'intero (!) Codice di presentazione. Forse anche il modo in cui gli oggetti interagiscono (rilevamento collisione, f.e.). La logica del gioco viene catturata nei modelli, quindi posso concentrarmi su questo. E penso che la logica di gioco sia la parte più importante del fare un gioco. Non è vero? Spero che tu veda il mio punto.

Ma, se avete tutto insieme: tutta la grafica, i suoni, il tutto; quindi puoi codificare direttamente.

My MVC è un assetto di configurazione-convenzione, che rallenta un po 'la prototipazione. MA (!) Le iterazioni di sviluppo possono essere fatte molto più facilmente. I test, in particolare i test unitari, vengono eseguiti molto più velocemente. Direi che MVC trasforma la curva di velocità di sviluppo (che normalmente è una curva antiesponenziale) in una curva esponenziale. Lento all'inizio, ma sempre più veloce alla fine.

Answer 4

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