Ist Domain Driven Design gut für Spiele?

10

Ich habe gerade über Domain-Modelle gelesen und es hat mich aufgeklärt, seit ich ein Spiel entwickelt habe, das eine Klasse hat, die nur Daten enthält (wenige Verhaltensweisen / Methoden). Ich habe den Managern die Aufgabe übertragen, diese Klassen zu verwalten ... und jetzt scheint mein Manager wie ein Gottobjekt auszusehen. Mein Spielobjekt, das die Logik handhaben soll, ist nur ein anämisches Domänenmodell.

Mein aktuelles Entwurfsmuster ist in Singleton und ich möchte einige Neukodierungen vornehmen, um dieses Zeug herauszubekommen. Ich habe noch nie eine DDD für Spiele gesehen (bis jetzt), aber ist das ein guter Ansatz? Ich bin nur ein Anfänger im Programmieren (geneigt zu Spielentwicklern), daher möchte ich mehr über gute Architektur erfahren, bevor das Spiel für eine Neugestaltung zu aufgebläht wird.

Sylpheed
quelle
2
Ich kann sagen, dass ein beliebtes Design für Spiele eine Komponentenarchitektur ist. Ein neues Design, das auf dem neuesten Stand der Spiele-Engines ist, ist das datenorientierte Design (bedeutet nur, dass die Art und Weise, wie die Daten im Speicher abgelegt werden, das höchste Designproblem darstellt). Aber ich kann nicht mit Domain Driven Design in Videospielen sprechen. Daher nur ein Kommentar.
James
Spiele sind keine Geschäftsanwendungen. Soundarchitektur in einer Geschäftsanwendung (DDD / CQRS) ist definitiv kein Sound in einem Spiel und umgekehrt. Warum nicht das Dekorationsmodell oder das Komponentenmodell untersuchen? Diese sind "gut" für Spiele und würden Ihr Singleton-Problem lindern - selbst wenn Sie sagen, dass Singletons in Spielen normalerweise in Ordnung sind; vor allem, wenn Sie Indie-Entwicklung machen. Konzentriere dich darauf, etwas zu beenden, sonst landest du wie ich mit einer großartigen Architektur, aber ohne Spiel.
Jonathan Dickinson
Danke für den Vorschlag. Ich werde über Komponentendesign lesen. Ich werde das Spiel beenden, an dem ich arbeite, obwohl das Design nicht so gut ist. Ich habe diesen November eine Frist lol. Ich habe das Konzept von Singleton entfernt und füge Module in Objekte ein, die es benötigen. Ich denke, das wird vorerst ausreichen, aber ich muss mehr lernen.
Sylpheed

Antworten:

12

Ich hatte vor Ihrem Beitrag noch nie von domänengesteuertem Design gehört. Ein kurzer Blick auf einige Referenzen - hier und hier - scheint darauf hinzudeuten, dass es nur ein ausgefallener Name für die traditionelle Methode der objektorientierten Programmierung der 90er Jahre ist, die mir an der Universität beigebracht wurde, wo Sie versuchen, Klassen für jedes erscheinende Substantiv zu schreiben In der Situation, in der Sie versuchen, mit Software zu modellieren, scheint die Struktur der Software der Struktur des realen Konzepts zu folgen.

Daher ist meine Antwort darauf, dass es nicht "gut" ist. Dies ist normalerweise ein vernünftiger Ausgangspunkt, erweist sich jedoch im Laufe der Zeit als unzureichend. Sie haben selten eine einzelne Domain, aber mehrere verschiedene Domains innerhalb einer Software - zum Beispiel haben Sie möglicherweise die Domain des Spiels (die Welt, die Charaktere, die Gegenstände), die Domain des Renderers (die Shader, die Meshes, die Materialien), die Eingabedomäne (das Dateisystem, das Netzwerk, die Tastatur und die Maus) und die Probleme treten dort auf, wo sich die Domänen überlappen und gegenseitig beeinflussen. Oft stellen Sie beim Zusammenfügen von zwei Domänen fest, dass dort tatsächlich eine Abhängigkeit besteht, die eine Änderung erfordert, was bedeutet, dass eine Ihrer Darstellungen eher eine Belastung als eine Hilfe darstellt.

Ein vages Beispiel könnte eine Mathematikbibliothek auf einer Konsole und Ihre Charaktere im Spiel sein. Ihre Mathematikbibliothek möchte eine große Liste von Daten und dann 1 Anweisung haben, um diese Liste auszuführen und effizient auszuführen. Ihre Charaktere im Spiel haben jeweils einen eigenen Satz von Scheitelpunktdaten zum Rendern und Animieren usw. Wie erhalten Sie nun eine lange Liste aller Scheitelpunktdaten von jedem Ihrer Charaktere, um sie auf einmal verarbeiten zu können? Sie können einen langsamen Kopiervorgang ausführen oder stattdessen Ihre Zeichen so umgestalten, dass ihre Daten besser von der Mathematikbibliothek verarbeitet werden können. Dann bricht jedoch eine Ihrer Domänen zusammen, um eine andere zu bevorzugen.

Persönlich bin ich sehr vorsichtig mit jedem Label, das "Whatever-Driven-Design" ähnelt. Software ist sowohl zu weitreichend als auch zu komplex, als dass es einen einheitlichen Ansatz für ihre Erstellung geben könnte. Wenn ich versuche, die bestmögliche Software zu schreiben, greife ich stattdessen auf die SOLID- Prinzipien zurück. Diese geben Ihnen eine gute Vorstellung davon, wie gut Ihr Code ist, ohne ein Allheilmittel für eine Methode zu versprechen, der Sie folgen und auf magische Weise zu gutem Code gelangen können. Leider erfordert es ohne eine solche angehängte Methodik viel Erfahrung, bis Sie lernen, wie man diese Richtlinien einhält, weshalb wahrscheinlich so viele Menschen die Methoden mögen.

In Bezug auf Ihr Problem mit anämischen Klassen und Managerobjekten wird dies normalerweise in einführenden Lektionen zur Objektorientierung behandelt, und Sie müssen sich nicht unbedingt an eine spezielle Methode halten, um das Problem zu beheben. (Wenn Sie gerade erst anfangen, möchten Sie vielleicht ein Buch über objektorientierte Programmierung lesen.) Eine Klasse ist eine Kopplung von Status und Verhalten, bei der das Verhalten diesen Status ändert. Dies wird als Kapselung bezeichnet. Im Allgemeinen versuchen Sie, so viel wie möglich zu kapseln, was bedeutet, dass der Status vom Objekt selbst (und nur von diesem Objekt) manipuliert werden sollte. Nur für Verhalten, das nicht innerhalb der Klasse modelliert werden kann, würden Sie es an eine externe Klasse delegieren, z. B. an einen Manager. Daher wird das Vorhandensein von Managerklassen häufig als Zeichen für schlecht geschriebenen objektorientierten Code angesehen.

Mein aktuelles Entwurfsmuster ist in Singleton und ich möchte einige Neukodierungen vornehmen, um dieses Zeug herauszubekommen.

Ich weiß nicht, was du mit dieser Zeile meinst. Ein Entwurfsmuster ist eine bekannte Methode, um einen kleinen Teil Ihres Programms zu schreiben. Sie hätten weder ein "aktuelles" Entwurfsmuster, noch würde es den Rest Ihres Programms prägen. Für Anfänger sind diese Muster nützlich, um Sie auf den richtigen Weg zu bringen, während sie für Experten eher eine Möglichkeit sind, über gängige Codesituationen zu kommunizieren. Eines ist jedoch wichtig: Singletons sind fast immer eine schlechte Idee, und Sie sollten sie nach Möglichkeit vermeiden. Sie können viele Meinungen zu Singletons auf dieser Site und darüber auf Stack Overflow finden, aber hier ist eine praktische Frage mit Antworten, die Ihnen helfen, diese nicht zu benötigen.

Kylotan
quelle
Okay, lassen Sie mich die Frage ein wenig ändern. Gibt es einen Unterschied zwischen Domänenmodellen und domänengesteuertem Design? Meine Idee zu Domänenmodellen ist, dass eine Klasse in der Lage sein sollte, sich selbst zu handhaben, ohne sich so weit wie möglich auf einen Controller / Manager zu verlassen. Mein aktuelles Design macht diesen Zweck zunichte. Ich kann etwas falsch verstehen. In einem RPG-Spiel hat meine Spielerklasse eine eigene Domain und besteht aus verschiedenen Domains wie Fertigkeiten, Gegenständen usw.
Sylpheed
Ja, eine Klasse sollte in der Lage sein, sich selbst zu handhaben, ohne sich so weit wie möglich auf einen Controller / Manager zu verlassen, aber das hat nichts mit Domänenmodellen zu tun und ist nur ein Standardansatz der objektorientierten Programmierung. Es ist nicht klar, was Sie möglicherweise missverstehen, da ich nicht weiß, warum Sie diese Managerklassen haben.
Kylotan
Ich sehe nicht, wie ich mein Modul ohne einen Manager oder eine Klasse zum Laufen bringen kann, die mein Objekt abfragt. Zum Beispiel habe ich ein Modul für Quests. Damit ich auf die richtige Quest zugreifen kann, muss ich mich beim Manager erkundigen. Wie gehe ich das ohne Manager durch?
Sylpheed
Was ist die "richtige" Suche? Woher weiß der Manager, was richtig ist? Ich vermute, dass die Logik, die solche Entscheidungen trifft, sich auf andere Objekte stützt, um sie zu treffen, und diese anderen Objekte sind bessere Kandidaten für diese Funktionalität.
Kylotan
Nun, im Moment verhält sich mein Manager nach einigen Aufräumarbeiten wie ein Repository. Zum Beispiel habe ich 10 Live-Quests. Ich greife über die ID auf diese Quests zu, um sie leichter abrufen zu können. Mein Spieler hat also eine Komponente für Quests (der Manager) und ich werde von dort aus auf die Quest zugreifen. Es ist immer noch der Spieler, der kontrolliert, welche Quest er haben kann. Ist das eine schlechte Idee?
Sylpheed
6

Paradigma

Zum Zeitpunkt der Erstellung dieser Antwort sind die anderen hier veröffentlichten Antworten alle falsch.

Anstatt zu fragen, ob Domain-Driven Design für Spiele gut ist oder nicht. Sie sollten sich fragen, ob "Domain Modeling" für Spiele geeignet ist.

Ist Domain-Modellierung gut für Spiele?

Die Antwort lautet: Manchmal ist es absolut fabelhaft. Wenn Sie jedoch ein Echtzeitspiel wie einen Plattformer oder FPS oder was auch immer erstellen (VIELE VIELE Arten von Spielen), dann nein. Es ist nicht unbedingt gut für diese Systeme geeignet. Es kann jedoch Systeme innerhalb dieser Spiele geben, in denen die Implementierung des Domänenmodellmusters effektiv ist.

Wie andere hier erwähnt haben, sind Komponenten-Entity-Frameworks aus gutem Grund sehr beliebt. In der Spielentwicklungskultur scheint es jedoch einen deutlichen Mangel an geschichteten Architekturen zu geben. Auch dies ist aus gutem Grund so, da die meisten Spiele, die Menschen entwickeln werden, nur einen mutierten Zustand auf Entitäten entwickeln und die aufkommenden Konsequenzen das Spiel sein lassen.

ALLE SOFTWARE IST NICHT DIE SOFTWARE, DIE SIE SCHREIBEN. Einige sind ganz anders als andere.

Einige Beispiele für Domänen, in denen die Domänenmodellierung gut funktioniert, sind Kartenspiele, Brettspiele und andere Arten von Systemen, die ereignisgesteuert sind.

Spiele, die mit einer X-Bildrate mit Bewegung usw. ausgeführt werden, die durch Zeitdeltas als Kerndomänenkonzepte bestimmt werden, passen wahrscheinlich nicht gut zusammen. In diesem Fall ist unsere "Domain" oft so einfach, dass keine Domain-Modellierung erforderlich ist. Kollisionserkennung, Laichen neuer Entitäten, Einfluss von Kräften auf vorhandene Entitäten usw. decken in der Regel das meiste Gameplay ab.

Wenn die Dinge jedoch komplexer werden, sehen Sie Entwickler, die Domänenmodelle in ihren Entitäten implementieren, um bestimmte Arten von Verhalten und Berechnungen zu handhaben.

Domänenmodellmuster in Spielarchitekturen

Ihre Spiel-Engine (z. B. Unity3D) ist häufig komponentenentitätsorientiert. In einem Plattformer haben Sie möglicherweise eine Entität für Ihren Charakter und sein Status wird ständig geändert, um die Position usw. zu aktualisieren.

In einem ereignisgesteuerten Spiel ist es jedoch wahrscheinlicher, dass die Rolle des Komponenten-Entitäts-Frameworks eher als Benutzeroberfläche existiert. Sie erhalten eine mehrschichtige Architektur.

Die Benutzeroberfläche gibt dem Benutzer den Spielstatus. Der Benutzer interagiert mit der Benutzeroberfläche und löst Befehle in der Serviceschicht aus. Die Serviceschicht interagiert mit Domänenobjekten. Domänenobjekte haben Domänenereignisse ausgelöst. Ereignis-Listener hören die Ereignisse und lösen Änderungen in der Benutzeroberfläche aus.

Benutzeroberfläche> Serviceschicht> Domänenmodell

Kurz gesagt, Sie erhalten einen Model-View-Controller mit einer Service-Layer-Implementierung.

Mit dieser Architektur verfügen Sie über einen vollständig auf Einheiten testbaren Spielkern (eine Seltenheit in der Spielentwicklungskultur, wie es zeigt) mit einer ereignisgesteuerten Oberfläche.

Ok, was ist DDD?

Domain-Driven Design ist speziell eine Kultur / Bewegung mit Schwerpunkt auf analytischen Mustern, die verwendet werden, um etwas über die Domain zu lernen, damit Sie tatsächlich das Richtige erstellen, und dann Implementierungsmuster, mit denen Sie eine Modellebene implementieren können, die das darstellt Konzepte im Domänenmodell unter Verwendung der Sprache Ihrer Sprache. DDD stammt aus einer Community, die mit komplizierten Domänen arbeitet und immer nach Möglichkeiten sucht, die hohe Komplexität ihrer Anwendungen zu verwalten, indem sie sich auf die Domänenmodellierung konzentriert.

DDD funktioniert nicht so gut, wenn Sie nur mit dem Codieren beginnen, mit dem System herumspielen und dann herausfinden möchten, was Sie später erstellen möchten usw. Es wird davon ausgegangen, dass mehr oder weniger eine Domäne vorhanden ist. Wenn Sie also keine Ahnung haben, wie Ihr Spiel aussehen wird, funktioniert es nicht.

Shawn McCool
quelle
1
Danke für den Einblick. Ich hatte das vielleicht vor 3 oder 4 Jahren herausgefunden. Ich war damals (vor 5 Jahren) naiv, da ich immer versuche, das "Designmuster" an alle meine Probleme anzupassen. Das Erlernen dieser "Muster" und der Architektur hat geholfen, da ich mehr Möglichkeiten hatte. Ich halte mich immer daran, Teile meines Codes "gerade genug" zu abstrahieren, damit es für Designer (sehr wichtig), Komponententests und zukünftige Mechaniker einfach wird. Das Übertreiben der Architektur machte es schwierig, damit zu arbeiten, und das habe ich auf die harte Tour gelernt. Im Moment habe ich bereits eine komponentenbasierte Architektur genutzt, um sie meinem Codierungsstil anzupassen. FESTE ftw.
Sylpheed
3

Nein, ich denke nicht, dass DDD oder eine andere "Schlagwort" -Architektur wirklich gut für Spiele ist. Mit der möglichen Ausnahme des "Komponentensystems", das hier sehr beliebt zu sein scheint.

Wenn ich solche Fragen und Diskussionen höre, werde ich an diese Seite erinnert. Das Nachdenken über verschiedene Architektur-Schlagworte bringt Ihnen normalerweise weniger, als das eigentliche Entwerfen und Codieren Ihrer eigenen Anwendung.

Keine Ursache
quelle
1
+1 für "Entwerfen und Codieren Ihrer eigenen Anwendung". Diese Muster sind für mich Richtlinien und Denkanstöße - nichts weiter. Es ist falsch, ein Problem so zu ändern, dass es in eine Lösung passt.
Jonathan Dickinson
-1

Ja, aber du solltest dich anpassen.

Bei Verwendung von DDD erhalten Sie Modularität und Einzelverantwortung für jede Domäne. Aber alles andere macht die Dinge nur komplex.

Siehe meine Antwort hier

b.ben.
quelle
Möglicherweise möchten Sie Ihre Antwort etwas erweitern (den Hauptteil der Antwort abdecken), da es sich derzeit nur um eine Link-Antwort handelt (auch wenn sie auf eine andere Stapelaustausch-Site verweist).
Vaillancourt