Compartimentazione simile a MVC nei giochi? [chiuso]

Stavo contemplando la progettazione di un gioco (tradurre un gioco da tavolo sul computer, in particolare, che suppongo sia rilevante in questo caso) e mi è venuto in mente che avrebbe avuto senso costruire il "gioco" separato dal "display".

Mi permetterebbe di prototipare qualcosa rapidamente con una semplice interfaccia di testo, e poi di andare avanti in un secondo momento. Mi permetterebbe anche di trasferire il gioco su altri media più facilmente.

Questo tipo di compartimentazione è comune nei giochi? Dovrei provare a scomporre ulteriormente le cose? Ci sono complicazioni che potrei perdere?

Un gioco da tavolo è un buon esempio di gioco che potrebbe essere realizzato usando MVC, poiché la logica di gioco (modello) esiste in modo abbastanza indipendente dagli elementi visivi (vista). Tuttavia, se si considera un gioco d'azione come Gears of War, la geometria dei modelli 3D è intrinseca alla logica del gioco, quindi separare la vista come se fosse intercambiabile diventa inutile. Unity3D è un ottimo esempio di un modo più specifico per il gioco di organizzare il codice. Hai una classe di entità di base a cui aggiungi funzionalità con i componenti, in cui un componente potrebbe gestire il disegno dell'entità, uno gestire la logica di gioco ecc. Dai un'occhiata a questi famosi post sul blog sull'argomento:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

La mia opinione su di esso:

• Il modello è dove si trovano la maggior parte dei dati e avviene tutta la logica.
  Legge una coda di eventi di input e modifica di conseguenza lo stato del gioco.
  Quindi elabora elementi come la fisica e altri componenti principali che aggiornano anche lo stato del gioco.
  Ciclo continuo. È tutto.
  L'obiettivo è rendere il modello indipendente: non ha alcuna dipendenza dalla vista o dal controller: dovresti essere in grado di creare un programma che esegue solo un modello.
• La vista legge semplicemente lo stato di gioco del modello, aggiorna i propri componenti dedicati alla rappresentazione dei dati e visualizza le cose sullo schermo.
  Non scrive mai nulla sul modello, è un processo di sola lettura, tranne forse la registrazione di alcuni gestori di eventi (come "Hey Mister Model, quando rilevi una collisione tra questi due oggetti, chiama il mio gestore di eventi che riproduce un suono! ").
• Il controller rileva gli eventi di input e li passa alla coda di input del modello. Legge la vista (questo clic sul pulsante è avvenuto su un pulsante UI?).

In questo modo è possibile collegare un controller falso che legge un file che contiene eventi di input preregistrati.
Crea anche una vista semplice che registra le cose su un file.
Molto utile per i test e il debug.

Ricorda di effettuare l'aggiornamento del modello a una velocità costante (intervallo di tempo fisso) e la vista e il controller il più velocemente possibile (ma non troppo variabili).

Questo tipo di compartimentazione è la divisione tra un motore e un codice di gioco ed è abbastanza comune. Lungo la strada c'è molto spazio per l'astrazione.

I dati grafici specifici del tuo motore e dei tuoi giochi potrebbero essere considerati come la vista, il tuo codice di gioco, il modello e il controller sarebbe qualunque colla tu usi per dire al tuo motore quale trama applicare a quale entità nel tuo codice di gioco.