MVC-Game-Engine-Architektur (Model-View-Controller) - Ja oder Nein? [geschlossen]

18

Ich lese ein großartiges Buch, Game Coding Complete , und in diesem Buch wird die Verwendung des MVC- Ansatzes (Model-View-Controller) mit drei Schlüsselebenen dringend empfohlen :

  1. Game Application Layer
  2. Spielelogik
  3. Spielansicht

Für mich sieht dieser Ansatz wie ein Overkill für ein mobiles Computerspiel aus.

Was ist Ihre Meinung, bitte? Lohnt es sich, diese Architektur zu implementieren, auch wenn zusätzliche Kommunikation zwischen den Modulen erforderlich ist? Kann dieses Design so viel CPU-Leistung verbrauchen, dass das Ergebnis am Ende deutlich langsamer ausfällt, als wenn es nicht implementiert wäre?

architecture Bunkai.Satori
quelle
5
-1 und stimmen zu schließen. Alles, was es wert ist, in Spielen über MVC zu sprechen , wurde unter gamedev.stackexchange.com/questions/3426/… gesagt , und bis jetzt haben wir hier nur Müll.
@ Joe Wreschnig, das ist ziemlich hart, aber ich denke, wahr ...
Spooks
@chaos: Eigentlich habe ich deine Antwort positiv bewertet, aber wir brauchten wirklich keine andere Antwort, in der stand: "Nutze Muster, wenn sie helfen, nicht, wenn sie nicht helfen." Oder vielleicht haben wir es getan, aber das ist immer noch sehr traurig. Ich weiß immer noch nicht, wie ich mich auf Ausdrücke wie "Laufzeitdesigns wie Vererbung" beziehen soll, außer auf Müll.
2
@ Joe: Oh, gut, danke. :) Das Argument, dass OOP kostenlos ist, verwirrt den Verstand ein wenig. Ich nehme an, wir sollten nach irgendeinem Standard keine Punkte wie meine wiederholen müssen, aber Noobs passieren und so zweifellos Fragen duplizieren. Es hat auch die Funktion, dass Spätankömmlinge wie ich trotz massiver Absterben der Aktivität ein winziges Stück Wiederholung zusammenkratzen können. :) Ich meine, verdammt, ich habe 40K Rep auf SO, aber hier kann ich nicht einmal ein Tag-Wiki bearbeiten.
Chaos

Antworten:

30

Ich unterstütze die Verwendung einer MVC-Struktur sogar für ein einfaches Handyspiel. Wenn nichts anderes hilft es bei einem Problem, das Entwickler plagt, die nicht oft genug davon gebissen wurden: Trennen des Anzeigecodes von der Spielelogik.

Ich möchte jedoch auch darauf hinweisen, dass MVC wie alle Designmuster vorhanden ist , um Ihnen das Leben zu erleichtern . Das bedeutet , dass , wenn zu einem bestimmten Zeitpunkt, innerhalb eines bestimmten Reihe von Regeln zu bleiben , was Sie sollen und nicht tun sollten bei der Verwendung von MVC Ihr Leben schwerer machen, ignoriert es . Eines von zwei Dingen wird passieren: 1) Sie werden später gebissen und werden dann verstehen, warum eine andere Vorgehensweise Ihr Leben auf lange Sicht einfacher gemacht hätte, oder 2) überhaupt keine Konsequenzen.

Computerprogrammierung bringt von Natur aus eine Menge von Regelanhängern hervor, die das Festhalten an eleganten Prinzipien über das tatsächliche Erreichen von irgendetwas schätzen, und sie lieben es, ihr Wertesystem vorzuschlagen. Lass dich nicht zu einem von ihnen machen. Das Wichtigste, was Ihrem Spiel passieren kann, ist, es zu versenden .

Chaos
quelle
Liebes Chaos, Ihre Antwort gefällt mir am besten, deshalb markiere ich sie als Antwort auf meine Frage. MVC-Ansatz fügt Abstraktion in Code-Design. Die Abstraktion fügt normalerweise zusätzliche Codeschritte hinzu, die mit einem geradlinigeren Design vermieden werden könnten. Wie ich richtig verstanden habe, muss ich mir keine Gedanken über die Kosten machen, die durch die Abstraktion entstehen, die durch das MVC-Design entsteht.
Bunkai.Satori
1
Gute Antwort, +1 dazu. Theorie ist in Ordnung und gut, aber es kann dazu führen, dass Spiele nicht ausgeliefert werden, wenn Sie es einfach nicht schaffen.
James
@ Bunkai.Satori: Es fügt Abstraktion hinzu, und IMO ist es nützliche Abstraktion, die sich auszahlt. Ich stimme mit Ihrer letzten Aussage, mit der Klarstellung , dass es ist eine kostengünstige, und dass ich glaube nicht , Sie brauchen , um Sorgen darüber.
Chaos
4

Entwürfe zur Kompilierungszeit verbrauchen keine CPU-Leistung, es sei denn, Sie haben einen unglaublich unheilvollen Compiler. Eine objektorientierte Sprache oder Vorgehensweise unterscheidet sich in ihren Leistungsmerkmalen nicht von einer prozeduralen. Sie werden keinen zusätzlichen Aufwand für die Verwendung von MVC verursachen. Die Modularität tritt zur Kompilierungszeit auf, nicht zur Laufzeit. Sobald der Code integriert und optimiert ist, macht dies keinen Unterschied mehr.

In vielen modernen Spielen werden die Modelle und die Ansichten auf separaten Threads ausgeführt, und auf den meisten Plattformen werden große Leistungsvorteile erzielt.

Letztendlich ist MVC ein gutes Design, mit dem Sie mehr Wartung und weniger Fehler usw. kostenlos erhalten . Es gibt keinen Grund, es nicht zu benutzen. Es ist wie zu fragen, warum Sie eine forSchleife anstelle von handgeschriebenen gotos verwenden sollten. Wenn Sie kein überlegenes Design im Sinn haben, ist es mit Sicherheit besser als nichts.

Bearbeiten: Entwürfe zur Kompilierungszeit verbrauchen keine CPU-Leistung. Laufzeitdesigns wie die Vererbung sind offensichtlich ausreichend.

DeadMG
quelle
-1. MVC ist eine Entwurfsentscheidung. Vererbung ist eine Entwurfszeitentscheidung. Beides tritt vor der Kompilierung und zur Laufzeit auf. Beide haben erhebliche Auswirkungen auf die Leistung. Durch Inlining wird Code nicht immer schneller. Ihr Threading-Vorschlag ist unglaublich naiv. Nichts ist umsonst.
Vielen Dank an DeadMG für Ihre Antwort. Grundsätzlich meine ich, dass mit jeder Abstraktionsebene der Code verschoben wird, da immer mehr Zwischenschritte hinzugefügt werden. MVC ist ein abstrakteres Design, das höchstwahrscheinlich mehr Schritte zur Erreichung derselben Aufgabe zur Folge hat. Dies hätte Einfluss auf die Geschwindigkeit, imo.
Bunkai.Satori
4

Es gibt fast immer einen Kompromiss zwischen der Klarheit des Codes und den technischen Anforderungen (Geschwindigkeit, Speicher usw.) des Programms. Objektorientierte Sprachen haben einen Overhead im Vergleich zu prozeduralen Sprachen, es hat sich jedoch gezeigt, dass sie viele Vorteile gegenüber prozeduralen Sprachen haben, insbesondere bei der langfristigen Pflege von Code (Bugs usw.) und häufig auch bei der Entwicklungsgeschwindigkeit.

Vor diesem Hintergrund schlage ich vor, dass es sich lohnt , MVC für Sie als Spielprogrammierer zu implementieren . Ihr Code wird besser objektorientierten Prinzipien folgen, insbesondere der Kapselung , und Sie werden es wahrscheinlich viel einfacher haben, ihn zu warten (Fehler zu beheben oder neue Funktionen hinzuzufügen).

Stellen Sie andererseits sicher, dass Sie ein Spiel tatsächlich beenden und nicht so viel Zeit damit verbringen, an der "Engine" zu arbeiten, dass sie niemals fertig wird.

Für weitere Informationen lesen Sie bitte die Frage "Warum werden MVC & TDD nicht mehr in der Spielearchitektur eingesetzt?" und meine wirklich lange Antwort.

Ricket
quelle
1
OO-Sprachen sind überhaupt nicht langsamer als prozedurale Sprachen. Wenn Sie Code in C ++ schreiben, der Bitverschiebungen ausführt, wird dieser nicht langsamer als in C. Eine Sprache oder ein Programm ist im Vergleich zu Prozeduren überhaupt nicht langsamer, nur weil es objektorientiert ist. Programme weisen nur Leistungseinbußen auf, weil sie schlecht geschrieben sind . Infolgedessen habe ich das Bedürfnis, Ihre Antwort abzulehnen.
DeadMG
Hallo Ricket, danke für deine Erklärung. Das klingt sehr logisch. DeadMG, na ja, auf der einen Seite haben Sie Recht. Auf der anderen Seite denke ich, dass der OO-Ansatz mehr Informationen in den kompilierten Code einfügt als die prozedurale Sprache. Diese zusätzlichen Bits des OO-bezogenen Codes verlangsamen den resultierenden Code. Sind Sie einverstanden?
Bunkai.Satori
3
Whoa now ... Sicher, eine einfache Zeile in C ++ wie a++wird genau das gleiche sein wie a++in C (wo aist ein primitiver Typ, etc. etc.). Stellen Sie sich eine einfache C ++ - Klasse mit einer virtuellen Funktion vor, die etwas bewirkt. Diese virtuelle Funktion verursacht einen erheblichen Overhead im Vergleich zu einer einfachen C-Funktion, selbst wenn der innere Code identisch ist. Objektorientierte Sprachen haben einen Overhead . Entschuldigen Sie, dass Sie ausdrücklich "Geschwindigkeit" sagen. Wenn zusätzliche Speicherzuweisungen und dergleichen nicht zu einem langsameren Programm führen, haben Sie absolut Recht.
Ricket
2
Wenn die Funktion virtuell ist, bedeutet dies, dass das Programm zur Laufzeit zwischen zwei verschiedenen Versionen derselben Funktion wählen muss. (Andernfalls würden Sie es nicht virtuell machen.) In diesem Fall haben Sie sowieso eine zusätzliche Bedingung oder Indirektionsebene, die Sie selbst in einer prozeduralen Sprache implementieren müssten (z. B. über einen Funktionszeiger oder eine switch-Anweisung). . Das ist kein Overhead - das ist das Problem.
Kylotan