MVC-artige Unterteilung in Spiele? [geschlossen]

Ich habe über das Design eines Spiels nachgedacht (das Übersetzen eines Brettspiels auf den Computer, was in diesem Fall meiner Meinung nach relevant ist), und mir ist der Gedanke gekommen, dass es möglicherweise Sinn macht, das Spiel getrennt von der Anzeige zu erstellen.

Es würde mir erlauben, etwas schnell mit einer einfachen Textschnittstelle zu prototypisieren und es dann später hübsch zu machen. Dadurch könnte ich das Spiel auch einfacher auf andere Medien übertragen.

Ist diese Art der Unterteilung in Spiele üblich? Sollte ich versuchen, die Dinge weiter aufzuschlüsseln? Gibt es Komplikationen, die mir fehlen könnten?

Ein Brettspiel ist ein gutes Beispiel für ein Spiel, das mit MVC erstellt werden könnte, da die Spiellogik (Modell) unabhängig von der Grafik (Ansicht) existiert. Wenn Sie jedoch ein Actionspiel wie "Gears of War" in Betracht ziehen, ist die Geometrie der 3D-Modelle für die Spiellogik von wesentlicher Bedeutung, sodass es sinnlos wird, die Ansicht so zu trennen, als ob sie austauschbar wäre. Unity3D ist ein großartiges Beispiel für eine spielspezifischere Art, Code zu organisieren. Sie haben eine Basisentitätsklasse, der Sie Funktionen mit Komponenten hinzufügen, wobei eine Komponente das Zeichnen der Entität, eine Spielelogik usw. handhaben kann. Sehen Sie sich diese berühmten Blog-Beiträge zum Thema an:

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

http://gameprogrammingpatterns.com/component.html

Meine Einstellung dazu:

• Im Modell liegen die meisten Daten und die gesamte Logik findet statt.
  Es liest eine Warteschlange von Eingabeereignissen und ändert den Spielstatus entsprechend.
  Es verarbeitet dann Dinge wie Physik und andere Kernkomponenten, die auch den Spielstatus aktualisieren.
  Schleife. Das ist alles.
  Das Ziel ist es, das Modell unabhängig zu machen: Es ist nicht abhängig von der Ansicht oder dem Controller-Material. Sie sollten in der Lage sein, ein Programm zu erstellen, das nur ein Modell ausführt.
• Die Ansicht liest einfach den Spielstatus des Modells, aktualisiert seine eigenen Komponenten für die Darstellung der Daten und zeigt Dinge auf dem Bildschirm an.
  Es wird nie etwas in das Modell geschrieben, es ist ein schreibgeschützter Prozess, außer vielleicht die Registrierung eines Event-Handlers (wie "Hey Mister Model, wenn Sie eine Kollision zwischen diesen beiden Objekten feststellen, rufen Sie bitte meinen Event-Handler an, der einen Sound abspielt! ").
• Der Controller erfasst Eingabeereignisse und leitet sie an die Eingabewarteschlange des Modells weiter. Es liest die Ansicht (ist dieser Knopfklick auf einem UI-Knopf vorgekommen?).

Auf diese Weise können Sie einen gefälschten Controller anschließen, der eine Datei liest, die zuvor aufgezeichnete Eingabeereignisse enthält.
Erstellen Sie auch eine einfache Ansicht, in der nur Dinge in einer Datei protokolliert werden.
Sehr nützlich zum Testen und Debuggen.

Denken Sie daran, die Modellaktualisierung mit einer konstanten Rate (fester Zeitschritt) und die Anzeige und Steuerung so schnell wie möglich durchzuführen (jedoch nicht zu stark variabel).

Diese Art der Unterteilung ist die Trennung zwischen einer Engine und einem Gamecode und ist weit verbreitet. Auf dem Weg dorthin ist viel Raum für Abstraktion.

Ihre Engine und Ihre spielespezifischen Grafikdaten können beispielsweise die Ansicht, Ihr Gamecode das Modell und der Controller sein. Dies ist der Klebstoff, mit dem Sie Ihrer Engine mitteilen, welche Textur auf welche Entität in Ihrem Gamecode angewendet werden soll.