Architettura del motore di gioco MVC (Model-View-Controller) - Sì o No? [chiuso]

Sto leggendo un grande libro, Game Coding Complete , e quel libro raccomanda vivamente di utilizzare l' approccio MVC (Model-View-Controller) , con tre livelli chiave:

1. Livello di applicazione del gioco
2. Logica di gioco
3. Vista di gioco

Per me, questo approccio sembra eccessivo per un gioco per computer portatile.

Qual è la tua opinione, per favore? Vale la pena implementare questa architettura, anche se aggiunge ulteriore comunicazione necessaria tra i moduli? Questo design può consumare così tanta potenza della CPU, che alla fine il risultato sarebbe significativamente più lento, se non fosse implementato?

Sostengo in qualche modo l'utilizzo di una struttura MVC anche per un semplice gioco mobile. Se non altro, aiuta con un problema che affligge gli sviluppatori che non sono stati morsi abbastanza da esso: separare il codice di visualizzazione dalla logica di gioco.

Dirò anche, tuttavia, di tenere presente che MVC, come tutti i modelli di progettazione, esiste per semplificarti la vita . Ciò significa che se, in un dato momento, rispettare alcune regole su ciò che si dovrebbe e non si dovrebbe fare quando si utilizza MVC rende la vita più difficile, ignorarlo . Accadrà una di queste due cose: 1) verrai morso più tardi, e poi capirai perché farlo in modo diverso in primo luogo avrebbe effettivamente reso la tua vita più facile a lungo termine, o 2) nessuna conseguenza di sorta.

La programmazione informatica, per sua natura, ha molti seguaci della regola che apprezzano l'aderenza al principio elegante rispetto al realizzare effettivamente qualsiasi cosa, e adorano proporre il loro sistema di valori; non lasciare che ti rendano uno di loro. La cosa più importante che può accadere al tuo gioco è spedirlo .

I progetti in fase di compilazione non consumano potenza della CPU, a meno che non si disponga di un compilatore incredibilmente abissale. Un linguaggio o un approccio orientati agli oggetti non differiscono in termini di prestazioni rispetto a quelli procedurali. Non invocherai alcun sovraccarico aggiuntivo per l'utilizzo di MVC. La modularità esiste in fase di compilazione, non in fase di esecuzione, una volta che il codice è integrato e ottimizzato, non farà alcuna differenza.

Molti giochi moderni eseguono effettivamente i modelli e le visualizzazioni su thread separati e ottengono grandi vantaggi in termini di prestazioni sulla maggior parte delle piattaforme.

In definitiva, MVC è un buon design che ti offre una maggiore manutenzione e meno bug ecc . Gratuitamente . Non c'è motivo di non usarlo. È come chiedere perché dovresti usare un forciclo invece di gotos scritti a mano . A meno che tu non abbia in mente un design superiore, è sicuramente meglio di niente.

Modifica: i progetti in fase di compilazione non consumano la CPU. Ovviamente i progetti run-time come l'ereditarietà lo fanno.

C'è quasi sempre un compromesso tra la chiarezza del codice e i requisiti tecnici (velocità, memoria, ecc.) Del programma. I linguaggi orientati agli oggetti hanno un sovraccarico rispetto ai linguaggi procedurali, ma hanno dimostrato di avere molti vantaggi rispetto ai linguaggi procedurali, specialmente nella manutenzione a lungo termine del codice (bug, ecc.) E spesso anche nella velocità di sviluppo.

Quindi, con questo in mente, propongo che MVC meriti di essere implementato per il tuo bene come programmatore di giochi . Il tuo codice seguirà meglio i principi orientati agli oggetti, in particolare l' incapsulamento , e probabilmente avrai un tempo molto più facile per mantenerlo (correggere i bug o aggiungere nuove funzionalità).

D'altra parte, assicurati di finire effettivamente una partita e di non passare così tanto tempo a lavorare sul "motore" che non viene mai eseguito.

Per maggiori informazioni, leggi la domanda "Perché MVC e TDD non sono più impiegati nell'architettura di gioco?" e la mia risposta davvero lunga.