Ich versuche, ein sehr leichtes wiederverwendbares Framework für meine Spiele zu erstellen, anstatt jedes Mal von vorne anzufangen, wenn ich ein Spiel starte. Ich habe eine komponentengesteuerte Architektur - z.B. Entity setzt eine Positions- und eine Health-Komponente sowie eine Ai-Komponente usw. zusammen.
Meine große Frage ist, ob mein Modell View-Komponenten zusammensetzt, um mehr als eine Ansicht des Modells zu ermöglichen, oder ob ein wahrer MVC verwendet werden soll, bei dem das Modell seine Ansichten nicht kennt werden extern verwaltet.
Ich habe beide Methoden ausprobiert, aber wenn jemand die Vor- und Nachteile jedes Ansatzes kennt und der Industriestandard ist, wäre es großartig zu wissen.
hängt von Ihrer Zielgruppe ab, Spielentwickler, ich selbst bin nicht sehr an das MVC-Modell gewöhnt, obwohl die meisten es wissen, es ist nicht so einfach, es sauber zu halten, aufgrund von Entwicklungsverlusten (keine ernsthaften technischen Gründe). Aus Erfahrung habe ich Dutzende von Spiel-Frameworks als MVC gestartet, aber nur ein Paar konnte es bis zum Ende beibehalten. Meine Theorie ist, dass MVC zu viel Komplexität und kleinen Vorteilen für kleine Wegwerf-Spiele hinzufügt (mit normalerweise ein paar Entwicklern), und es ist schwierig, die meisten Spielobjekte für große / komplexe Spiele wirklich sauber in diesen Ebenen zu halten. Und da Spiele ein Veröffentlichungsdatum haben, opfern sie oft Code-Klarheit und Wiederverwendbarkeit für Performance- und schnelle Ad-hoc-Lösungen (die, wenn nötig, in der Folge neu geschrieben werden (falls es eine gibt)).
Allerdings ist es besser, mit dem obigen Vorbehalt hoch zu zielen, denn wenn es dir gelingt, ist es besser :) und wenn du versagst, gut bis schlecht. Also solltest du wahrscheinlich den MVC ausprobieren, aber mach dir keine Sorgen, wenn es schief geht, professionelle Entwickler haben bei der Aufgabe viele Male versagt :)
Ich weiß, dass diese Frage vielleicht veraltet ist, aber ich muss darauf antworten. Eigentlich habe ich angefangen, ein Spiel in Lua (mit LÖVE) zu programmieren und habe dafür ein MVC - Framework programmiert. Am Anfang hängt die Verwendung von MVC wirklich davon ab, was Sie wollen. Ich kenne meine Probleme mit der Spielprogrammierung, wenn das Programm größer wird und die Struktur zu komplex wird, um sie zu verwalten. Als nächstes weiß ich, dass ich alle Grafiken ändern werde, wenn ich einen Künstler finde, der bereit ist, dafür zu arbeiten. Aber bis dahin werde ich meine eigenen Dummy-Grafiken verwenden. Ich möchte, dass der Künstler sich frei fühlt, zu tun, was immer er möchte, ohne abhängig zu sein von irgendeiner Auflösung oder Farbbeschränkung. Das bedeutet, dass ich den gesamten (!) Präsentationscode ändern muss. Vielleicht sogar die Art wie Objekte interagieren (Kollisionserkennung, zB). Die Spiellogik wird in den Modellen festgehalten, damit ich mich darauf konzentrieren kann. Und ich denke, Spiellogik ist der wichtigste Teil beim Erstellen eines Spiels. Ist es nicht? Hoffe, du siehst meinen Punkt.
Aber, wenn Sie alles zusammen haben: alle Grafiken, Töne, die ganze Sache; dann können Sie direkt codieren.
Mein MVC ist ein Konfiguration-über-Konvention-Ass, der das Prototyping ein wenig verlangsamt. ABER (!) Iterationen der Entwicklung können viel einfacher gemacht werden. Tests, insbesondere Unit-Tests, werden wesentlich schneller durchgeführt. Ich würde sagen, dass MVC Ihre Entwicklungsgeschwindigkeitskurve (die normalerweise eine Antiexponentialkurve ist) in eine Exponentialkurve umwandelt. Langsam am Anfang, aber immer schneller am Ende.
MVC funktioniert wirklich gut für Spiele, zumindest für meine Spiele, die plattformübergreifend entwickelt wurden. Es hängt wirklich davon ab, wie Sie es implementieren, um den Vorteil zu erhalten.
Tags und Links model-view-controller frameworks components