Verwenden Sie Diagramme, um Spiele zu modellieren? [geschlossen]


17

Ich meine meistens UML, aber jede Methode, die funktioniert, ist machbar. Also - modellieren Sie Ihre Spiele tatsächlich mit UML / anderen Diagrammen oder anderen Methoden? Ich hatte an meiner Universität ein Fach zum Thema Modellieren mit UML und es schien mehr Aufwand als Nutzen zu sein, aber mir ist klar, dass dies möglicherweise nur darauf zurückzuführen ist, dass ich noch nie ein riesiges komplexes IT-System erstellt habe. Lohnt es sich also und welche Arten von Diagrammen / Methoden sind normalerweise * die besten?

* Natürlich müssen oft konkrete Werkzeuge ausgewählt werden, um konkrete Probleme zu lösen, aber vielleicht gibt es einige Muster.

Bearbeiten: Ich habe eine wichtige Sache vergessen - erstellen Sie Diagramme vor oder nach der Implementierung von Sachen? Was ich meine ist - wenn man etwas entwirft und implementiert, worüber man normalerweise nachdenkt oder etwas Unerwartetes aufkommt und man Änderungen vornehmen muss, manchmal größere - und diese in bereits komplexen Diagrammen durchzuführen, scheint ebenso aussichtslos wie im Code selbst.


5
Dies ist eher eine programmierbezogene Frage im Allgemeinen, schauen Sie sich also diese Frage an: programmers.stackexchange.com/questions/152997/…
congusbongus

3
Vielen Dank für den Link, aber ich habe diese Frage bewusst hier gestellt - ich wollte sehen, ob gamedev in diesem Aspekt mit anderen IT-Bereichen vergleichbar ist.
NPS

Antworten:


21

Ich denke gerne, dass alles um uns herum auf die eine oder andere Weise durch ein Diagramm dargestellt werden kann. Auch wenn es sich nur um ein lineares Diagramm handelt, das den Übergang zwischen den Zuständen eines bestimmten Objekts im Laufe der Zeit darstellt (wie ein Lebewesen, das eine Reihe von Zuständen von der Geburt bis zum Tod durchläuft). Ich benutze Diagramme, um meine Gedanken und Ideen für die tatsächliche Umsetzung niederzulegen. Ich improvisiere ziemlich viel.

Daher sind meine Diagramme die meiste Zeit auf einem sehr hohen Niveau und fühlen sich wie Mind Maps an .

Zum Beispiel ist dies eine Klassenvererbungskarte (eine, die geschnitten wurde) in meinem Spiel, bei der Interactive Object der Basistyp ist.

Interaktives Objekt ist der Basistyp

Dies ist ein FSM - Diagramm ( Finite-State-Machine ) für eine Spikes-Falle (diese fantastischen Fallen, auf die Sie treten und die Spikes aus dem Boden tauchen lassen ).

FSM-Diagramm für eine einfache Spike-Falle

Dies ist ein Handbuchdiagramm (so genannt, weil es ein häufig verwendetes Diagramm sein soll), das ich kürzlich gezeichnet habe. Es beschreibt die Komponenten eines Spiels und hilft auch beim Sammeln der erforderlichen Assets, da Sie sofort sehen können, was benötigt wird und was nicht. Ich empfehle diese bei kleinen Projekten, da sie bei großen ziemlich groß werden. Sie können jedoch weiter verbreitert werden, so dass möglicherweise Fehler behoben werden.

Spielübersicht

Wenn ich auf eine niedrigere Ebene gehe, muss ich in der Regel die komplexesten Aspekte meiner Architektur planen, und dort beschäftige ich mich in der Regel mit UML. Ich konzentriere mich jedoch nie darauf, absolut saubere und korrekte UML auszugeben. Ich habe das übernommen, was mir an der UML-Konvention am besten gefallen hat, und daraus eine nette Mindmap-artige UML gemacht. Es ist einfach und erledigt die Arbeit für mich, aber ich würde es aus offensichtlichen Gründen nicht in einer Umgebung tun, in der tatsächliche UML erwartet wird.

Eine andere Situation, wenn ich auf eine niedrigere Ebene gehen muss, ist, wenn ich tatsächliche Algorithmen beschreiben muss. Ich benutze sogenannte Flussdiagramme . Es ist ein Format, das sich an den beim White-Box-Test verwendeten Diagrammen orientiert .

Ein Beispiel für die Spike-Falle, die ich gerade gezeichnet habe, würde folgendermaßen aussehen: Detaillierteres Flussdiagramm für Spike-Fallen

Dies ist normalerweise die letzte Ebene zwischen Diagrammen und tatsächlichen Algorithmusimplementierungen. Bei Bedarf führe ich die Flussdiagramme weiter aus (mit zusätzlich ausgeführten Anweisungen), leite die Komplexität ab oder schätze sie ab und erstelle genaue Testfälle. Ich bevorzuge auch Diagramme gegenüber Pseudocode.

Ich habe auch ein nettes Format, um die Bildschirme in einer Multiscreen-App zu beschreiben, die Funktionen, die der Benutzer auf jedem Bildschirm auslösen kann, und die Beziehung zwischen den Bildschirmen. Normalerweise erstelle ich diese, bevor ich mit der eigentlichen Entwicklung beginne, und sie verhalten sich während des gesamten Entwicklungsprozesses wie eine Landkarte. Wenn es für einen Kunden ist, ist das Bildschirmdiagramm noch nützlicher! Es hilft mir, das gesamte Projekt von Anfang an durchzugehen und alle Funktionen zu berücksichtigen, die es benötigen wird. Daher ist es von unschätzbarem Wert, eine genaue Kosten- und Zeitschätzung bereitzustellen.

Also ja, ich zeichne definitiv alles und jeden. Wenn ich eine Idee habe, kann und werde ich auf jeden Fall ein Diagramm dafür zeichnen. Wenn ich irgendwie ein Projekt ohne ein sehr breites Diagramm beginne, um mich zu unterstützen, fühle ich mich verkrüppelt.


4
Haben Sie nebenbei yEd für die Diagramme verwendet? Ich finde es sehr praktisch.
Kromster sagt Unterstützung Monica

4
Genau! Freut mich, einen anderen yEd Benutzer zu sehen. Ich habe es in den letzten Jahren viel benutzt, es ist mein aktueller Favorit.

2
+1 für yed. Der einzige Nachteil ist, dass die UML überhaupt nicht intuitiv ist. Aber für jedes andere Diagramm ist es erstaunlich, für eine kostenlose App.
Sidar

2
Ich habe yEd benutzt, um meine Verhaltensbäume für den AI-Wettbewerb von AiGameDev zu entwerfen.
Nick Caplinger

15

Ich mache - sowohl strukturelle als auch verhaltensbezogene - meine Faustregel ist, dass ich Diagramme erst dann erstelle, wenn die Kosten für die Erstellung des Diagramms geringer sind als der Versuch, mich zu erinnern, was zum Teufel ich einen Monat später gedacht habe - oder wenn ich mich klar erklären muss ein anderer Entwickler

Klassendiagramme, wenn die Vererbungshierarchie ausreichend komplex wird

Objektdiagramme, in denen Dinge wie das Instanziieren von Objekten aus unterschiedlichen Teilen an die Entstehung eines Frankenstein-Monsters angrenzen - besonders nützlich für Benutzer von Kitchen Sink Vertex und Pixel Shader, um sicherzustellen, dass alle erforderlichen Bits durch die Röhre geschoben werden

Sequenzdiagramme, wenn die detaillierten Interaktionen zwischen einer Reihe von Objekten komplex werden - dies ist äußerst nützlich bei der Modellierung komplexer Renderflüsse, bei denen zuvor berechnete Informationen an kaum zusammenhängenden nachgeordneten Stellen benötigt werden


Ich habe eine wichtige Sache vergessen: Erstellen Sie Diagramme vor oder nach der Implementierung? Was ich meine ist - wenn man etwas entwirft und implementiert, worüber man normalerweise nachdenkt oder etwas Unerwartetes aufkommt und man Änderungen vornehmen muss, manchmal größere - und diese in bereits komplexen Diagrammen durchzuführen, scheint ebenso aussichtslos wie im Code selbst.
NPS

6
ah ha - hängt davon ab, auf welche Weise das jeweilige Problem gelöst werden kann - manchmal ist es einfacher, den Code zu fummeln und dann zu zeichnen, manchmal ist es einfacher, ihn zu zeichnen und dann zu erstellen - ich habe keine feste Regel dafür one
Mark Mullin

@Mark: dieses Bit sollte ein Teil der Antwort sein;)
Kromster sagt Unterstützung Monica

8

Diagramme sind eine großartige Möglichkeit, Ihr Design zu kommunizieren, zu dokumentieren und zu unterstützen , und Design ist der wichtigste Teil der Softwareentwicklung. UML hat viele Funktionen, aber Sie sollten nicht alle Funktionen gleichzeitig verwenden, sondern nur die, die nützlich sind.

Halten Sie beim Navigieren in einer neuen Stadt tatsächlich an und sehen Sie sich eine Karte an, anstatt einfach fortzufahren und den Schildern zu folgen? Darum geht es bei Design vs. Codierung. Wenn Dinge ungewohnt sind, wenn das Problem komplex ist, wenn Sie sich verloren fühlen, dann ist es am hilfreichsten, über Design nachzudenken, und es ist besser, dies früher als später zu tun. Es ist viel einfacher, Ihr Design zu ändern, bevor Sie etwas implementiert haben .

Diagramme sind eine großartige Möglichkeit, das Problem zu visualisieren und Ihrem Design zu helfen, insbesondere für visuelle Denker (was die meisten von uns auf gamedev, wie ich es mir vorstellen würde, sind). Viele Probleme werden trivial, Mängel werden offensichtlich, wenn sie eindeutig auf ein Diagramm abgebildet werden. Einige Probleme, die Sie möglicherweise in einem Diagramm finden:

  • Zu viele Verbindungen zu einer einzelnen Komponente? Sie können einen haben Gott Objekt , das schwer zu halten
  • Zu viele Verbindungen? Möglicherweise kann die Modularität verbessert werden, um die Architektur weniger anfällig zu machen
  • Zu viele Wege zwischen zwei Komponenten? Vielleicht hast du eine enge Kopplung
  • Befinden sich für Hochleistungsanwendungen wie Spiele zu viele Komponenten im Hot Path oder in der inneren Schleife? Dies kann sich auf Ihre Leistung auswirken
  • In den meisten Fällen zeigt das Diagramm jedoch Inkonsistenzen zwischen dem geplanten Entwurf und der tatsächlichen Implementierung

Darüber hinaus eignen sich Diagramme hervorragend, um Ihr Design zu kommunizieren und zu dokumentieren, entweder für nicht-technische Personen oder für Personen, die neu in Ihrem Projekt sind - und denken Sie daran, dass Sie in 6 Monaten praktisch auch neu im Projekt sind!

Die Verwendung von UML sollte anhand dieser Überlegungen erfolgen. Diagramme für dich selbst? Verwenden Sie die Notation, mit der Sie sich am besten auskennen. Mit anderen Entwicklern zusammenarbeiten? Versuchen Sie, die Details von API-Aufrufen, Nachrichtentypen und Richtungen von Abhängigkeiten einzuschließen. Architektur diskutieren? Black Boxes und einfache Anschlüsse reichen aus. Niemand nutzt ohnehin alle UML-Funktionen , und es ist sehr nützlich, wenn es sich um eine standardisierte Notation handelt, die viele Leute verstehen.

Ich selbst verwende ständig Diagramme - einfache Notepad-Zeichnungen für persönliche Projekte, einfache UML-Diagramme bei der Arbeit. Dieses UML-Diagramm ist meiner Meinung nach zu komplex und würde ich niemals erstellen, da die Kosten für die Herstellung und Wartung des Diagramms den Nutzen überwiegen, aber natürlich YMMV.


Eine große Frage für Sie - IIUC, Sie versuchen (immer), sich an einfache Diagramme zu halten. Diagramme werden jedoch normalerweise benötigt, wenn die Anwendung kompliziert wird. Wie halten Sie Diagramme klein und einfach, wenn Sie große und komplexe Systeme modellieren?
NPS

@NPS Es kommt auf den Zweck / die Zielgruppe an, und meiner Erfahrung nach können Sie weiterhin einfache Diagramme verwenden, um komplexe Systeme zu modellieren. Normalerweise haben Sie viele verschiedene einfache Diagramme für verschiedene Personen oder zeigen verschiedene Aspekte des Systems - deshalb gibt es in UML auch verschiedene Arten von Diagrammen. Komplexe Systeme sind in der Regel in dem Sinne komplex, dass sie viele Aspekte oder Schichten aufweisen, die alle für sich genommen einfach sind. Wirklich komplexe Systeme sind sehr selten, da sie für die besten Experten in der Regel sehr schwer zu verstehen sind.
Congusbongus

8

Ich würde sagen, es gibt zwei Arten von Diagrammen. Formale Diagramme und Skizzen.

In Bezug auf formale Diagramme mache ich sie, wenn ich mit anderen Programmierern zusammenarbeite, aber ich mache das selten, wenn ich alleine programmiere.

Das heißt jedoch nicht, dass ich mich hinsetze und programmiere, was mir gerade einfällt. Meiner Meinung nach ist das Wichtigste beim Programmieren (oder eigentlich allem im Leben) , zuerst zu denken und später zu tun .

Das Codieren ist eine sehr mechanische Aufgabe. Sie tippen und Wörter erscheinen auf dem Bildschirm. Die Idee ist, dass Sie das Problem bereits gelöst haben sollten, wenn Sie mit dem Codieren beginnen. Kritzeleien zu machen ist eine großartige Möglichkeit, Ihre Gedanken zu sortieren und sich sogar dazu zu zwingen, das zu tun, was Sie brauchen, um den Codierungsteil korrekt auszuführen. Skizzen sollten nicht zur späteren Verwendung gespeichert werden, damit Sie Ihre Gedankenprozesse leicht verstehen können.

Mach dir keine Sorgen, wenn Sie zu viel Zeit zum Nachdenken nehmen. Ich denke, dass eine gute Balance entsteht, wenn Sie 90% Ihrer Zeit für das Denken und 10% für das Codieren aufwenden. Ich habe mehrere "Senior" -Programmierer getroffen, die davon leben, "wir haben keine Zeit zum Nachdenken, nur zum Tun". Aber selbst wenn sie ihren Code früher als "erledigt" bezeichnen, als diejenigen, die sich die Zeit nehmen, über das nachzudenken, was sie tun, verbringen sie (oder die unglücklichen Seelen, die danach übrig sind) unzählige Stunden damit, etwas zu reparieren und zu reparieren, das korrekt hätte erstellt werden müssen von Anfang an.

Das Beste ist, dass das Denken kostenlos ist! Sie müssen nicht auf Ihrem Computer sitzen, um nachzudenken. Sie können über den Code nachdenken, während Sie essen, pendeln, trainieren ... Tatsächlich kommen die besten Ideen, wenn Sie sie am wenigsten erwarten. Denken Sie also immer offen darüber nach und beginnen Sie erst mit dem Codieren, wenn Sie wirklich wissen, was Sie tun werde codieren.

Hier ist ein verwandter Artikel , dem ich zustimme.

Bearbeiten : In Bezug auf das tatsächliche Format und den Typ der Diagramme würde ich empfehlen, Freestyle zu verwenden und statt vorgefertigter Tools tatsächlich handschriftlich zu verfassen. Denken Sie daran, dass es darum geht, Sie in Ihrem Denkprozess zu unterstützen. Zeichnen Sie also nach Belieben. Die Semantik ist das, was Sie möchten, und sie kann zwischen Diagrammen und sogar zwischen verschiedenen Teilen des Diagramms unterschiedlich sein.

Freestyle / handschriftliche Diagramme bieten drei Hauptvorteile gegenüber vorgefertigten Tools:

  1. Sie müssen sich nicht an den Diagrammtyp halten, der von dem von Ihnen ausgewählten Tool unterstützt wird. Manchmal funktionieren Mapminds, manchmal ist etwas wie UML in Ordnung, und manchmal kann ein Logikdiagramm verwendet werden. In anderen Fällen funktioniert ein vollständig benutzerdefiniertes Diagramm, und kein Tool bietet Ihnen die Flexibilität von Freestyle-Diagrammen (stanzen Sie ein Loch in das Papier und fahren Sie auf der Rückseite des Papiers in Ihrem bevorzugten Paket fort, um zu sehen, was passiert).

  2. Sie werden mehr Zeit damit verbringen, Diagramme zu erstellen, anstatt das Tool zu verwenden. Unabhängig vom Werkzeug lassen sich mit Stift und Papier immer schneller Diagramme erstellen als mit Tastatur und Maus durch Menüs, um die gewünschten Elemente zu finden.

  3. Zum Schreiben benötigen Sie keinen Computer. Meistens mache ich komplexe Entwürfe in einer Bibliothek, einem Café oder sogar in einem Flugzeug. Außerdem tauchen gute Ideen immer im ungeeignetsten Moment auf. Nehmen Sie also immer etwas mit, mit dem Sie schreiben können, und etwas, auf das Sie schreiben können.


3
und diese "Kritzeleien" existieren möglicherweise nur in Ihrem Kopf oder folgen keiner formalen Diagrammkonvention. Und haben Sie keine Angst, das Design anzupassen, während Sie neue Erkenntnisse gewinnen. Natürlich können Sie dies nicht tun, wenn Sie für andere arbeiten und sie allein für das Design verantwortlich sind (obwohl Sie möglicherweise Vorschläge und Anfragen machen können), aber wenn Sie alleine sind, probieren Sie es einfach aus. Ich setze mich oft hin und fange einfach an, Dinge zu tun, und finde heraus, dass sich ein Design von dem entwickelt, was ich tue, bis ich genug Ideen habe, um es in einem Diagramm oder Dokument zu formalisieren.
14.

0

Es kann sich lohnen, auf einige Design-Diagramm-Vorträge der Game Developers Conference 2013 hinzuweisen. Dies sind einige sehr praktische und auf der Straße getestete Beispiele - und es scheint, dass sie im Laufe der Jahre auf vielen Konferenzen vorgestellt wurden.

(Die anderen Antworten haben bewundernswert demonstriert, warum und wie designorientierte Diagramme bei der Planung, Erstellung, Erweiterung und Pflege einer Codebasis enorm hilfreich sein können. Ich werde diesen Aspekt also in Ruhe lassen und darauf vertrauen, dass diese Ressourcen nützlich sein könnten an alle, die die Frage besuchen.)

Joris Dormans und Ernest Adams diskutierten das Machinations -Spieldesign / Balance-Diagrammsystem. (Hier ist ein kostenpflichtiges GDC Vault-Video von GDC EU 2012; Beispiele von GDC 2013 in Dormans Wiki.) Anstatt zu versuchen, das System zu paraphrasieren, beschreibt das Wiki Folgendes :

Machinations ist ein theoretischer Rahmen und eine interaktive, dynamische, grafische Darstellung, die Spiele als dynamische Systeme beschreibt und sich auf geschlossene Rückkopplungsschleifen in ihnen konzentriert. Es soll ein Weg gefunden werden, (wiederkehrende) Spielstrukturen methodisch auszudrücken und zu untersuchen. Machinations bietet ein neues Objektiv für die intuitive und delikate Praxis des Spieldesigns und Balancierens.

Noah Falstein hielt einen Vortrag mit dem Titel "The Arcane Art of Puzzle Dependency Diagrams" (kostenpflichtiges GDC Vault-Video ). Ich kann hier keinen nicht bezahlten Link finden, aber verschiedene Leute haben ihre Notizen online besprochen oder gepostet.

In beiden Gesprächen wurde erörtert, wann sie erstellt wurden und wie sie diese Diagramme in dem einen oder anderen Umfang aufrechterhalten.


0

In diesem Artikel sollten Sie sich wahrscheinlich über die Verwendung einer einfachen abstrakten Grammatik informieren, um Ihre Gameplay-Schleife zu beschreiben, wie Sie damit Entwurfsprobleme identifizieren und wie einfach es ist, auf dieser Ebene zu iterieren.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Ich kann Sie auch auf meine eigene Arbeit zu diesem Thema hinweisen, die mehr auf der Ökonomie der Gameplay-Schleife basiert und abstrakte Ressourcen verwendet, um Dinge wie Chancen, Glück oder Vorbereitung zu verfolgen:

http://www.stephanebura.com/diagrams/

Wenn Sie diesen Ansatz nützlich finden, sollten Sie einen Blick auf Joris Dormans 'Machinations werfen, ein Werkzeug zum Erstellen solcher Diagramme und Ausführen ihrer Simulationen:

http://www.jorisdormans.nl/machinations/

Sein gesamter Prozess wird in seinem Buch erklärt:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.