Spielplanung und Software-Design? Ich finde, dass UML nicht bequem ist

An meiner Universität wird immer viel Wert auf UML-Design und solche Dinge gelegt, bei denen ich der Meinung bin, dass sie beim Design von Spielstrukturen nicht gut funktionieren. Jetzt möchte ich nur einen professionellen Rat, wie ich mit dem Entwerfen eines Spiels beginnen soll. Die Geschichte ist, dass ich einige Programmierkenntnisse habe und viele kleinere Spiele gemacht habe, wie zum Beispiel, dass 2D-Platformer in gewissem Umfang funktionieren. Die Probleme, die ich bei meinem Programm finde, sind das schlechte Design. Nach einer Weile des Codierens kommt es aufgrund einer schlechten Planung zu einem Zusammenbruch (Wenn ich eine neue Funktion hinzufüge, muss ich das gesamte Programm neu codieren). Es ist jedoch etwas zu ideal, alles ohne einen einzigen Konstruktionsfehler zu planen. Gibt es also einen Ratschlag, wie ich mein Spiel planen soll? Wie soll ich es sichtbar machen, damit ich und meine Freunde einen Überblick über die Entwürfe haben?

Ich hatte vor, mit meinem Freund ein Spiel zu programmieren. Dies wird meine erste Teamarbeit sein, daher wären professionelle Ratschläge ein Vergnügen. Gibt es andere Alternativen als UML?

Eine andere Frage ist, wie "Prototyping" normalerweise aussieht.

Ich möchte nur einen professionellen Rat, wie ich mit dem Entwerfen eines Spiels beginnen soll.

Das Game-Design ist die Spezifikation des Gameplays, der Assets, der Scoring-Systeme usw. - diese sind nicht softwarespezifisch. Daher ist UML das falsche Werkzeug für diese Aufgabe.

Wenn es darum geht, den Code für die Implementierung dieser Systeme zu entwerfen, ist UML ein gutes Werkzeug für diese Aufgabe, das Ihrem Team bekannt macht und sich an die gängigsten Diagrammtypen hält. Normalerweise wissen Sie beim Entwerfen eines Features, ob Sie eine Beschreibung oder ein Diagramm verwenden müssen. Wenn Sie ein Diagramm verwenden müssen, bietet Ihnen UML eine Standardmethode zum Zeichnen, was eine gute Sache ist.

Nach einer Weile des Codierens kommt es aufgrund einer schlechten Planung zu einem Zusammenbruch (Wenn ich eine neue Funktion hinzufüge, muss ich das gesamte Programm neu codieren).

Das ist im Allgemeinen ein Problem mit der Art und Weise, wie Sie programmieren, anstatt wie Sie planen. Gute Software lässt sich normalerweise leicht erweitern und wiederverwenden. Wenn Sie sich an gute Programmierpraktiken halten, verringert sich dieses Problem. Aber eine bessere Planung hilft auch, und Sie brauchen dafür keine komplexen Diagramme. Nur eine Liste von Features zu haben, bedeutet, dass Sie beim Codieren die anderen Features berücksichtigen und beim Codieren berücksichtigen können.

Gibt es also einen Ratschlag, wie ich mein Spiel planen soll? Wie soll ich es sichtbar machen, damit ich und meine Freunde einen Überblick über die Entwürfe haben?

Es hört sich so an, als würdest du hier zwei Probleme vermischen, das Spieldesign und das Code-Design.

Ich schlage vor, zuerst ein grundlegendes Spieldesign zu schreiben und die benötigten Funktionen, Grafiken und Sounds, den Gewinn und Verlust des Spiels usw. anzugeben. Wenn Sie dort Hilfe benötigen, schlagen Sie in den „Designdokumenten“ nach.

Von dort aus haben Sie eine Vorstellung von den Funktionen, die Sie zum Codieren benötigen. Sie können sich die einzelnen Funktionen nacheinander ansehen und überlegen, wie sie implementiert werden sollen. Diagramme können dabei helfen, die Beziehungen zwischen verschiedenen Klassen und Objekten in Ihrem Spiel darzustellen. Die Fähigkeit zu wissen, welche Objekte existieren müssen, müssen Sie jedoch durch Übung und / oder weiteres Lesen erlernen.

Versuchen Sie auch, an kleineren, weniger ehrgeizigen Projekten zu arbeiten. Das wird Sie daran gewöhnen, guten, funktionierenden Code zu schreiben, ohne dass umfangreiche Planungen oder Umschreibungen erforderlich sind.

Wenn man etwas nicht versteht, kann man es leicht abweisen. Die UML ist ein Engineering-Tool, mit dem Sie Ihre Ideen strukturiert kommunizieren können. Ein Spiel ist ein System, das wie jedes andere entwickelt werden kann. Wenn überhaupt, macht die Komplexität und Dynamik eines Spiels eine visuelle Darstellung seiner Teile und ihrer Interaktionen von unschätzbarem Wert.

Die UML-Diagramme sind verschiedene Ansichten eines Modells des diskutierten Systems. Ich beginne mit Anwendungsfällen für eine Person, die sich vor mein Programm setzt und es startet. Bei einem Spiel gibt es zwei Arten von Benutzern: Designer und Spieler. Ich schreibe einen Anwendungsfall für jedes der Dinge, die ich sehen kann. Dann fertige ich einige CRC-Karten an, um herauszufinden, welche Dienstleistungen ich erbringen muss. Dann erstelle ich ein Klassendiagramm für die Schnittstellen, die diese Dienste und ihre Beziehungen bereitstellen. Dies basiert auf den CRC-Karten. Als nächstes folgen dynamische Diagramme für Ereignisse wie die Initialisierung, für die Planung und Orchestrierung erforderlich sind. Dann detailliertere statische Diagramme, die die Klassen zeigen, die die Schnittstellen implementieren.

Währenddessen schreibe ich Code, erstelle Prototypen und entwickle ihn weiter, um die Dienste bereitzustellen, mit denen ich die Anforderungen meines Spiels erfüllen kann. Es wird nichts erstellt, das den Benutzer durch die Anwendungsfälle nicht unterstützt. Ich schreibe einige nutzlose Diagrammelemente, aber zwischen der Schnittstellencodierung und dem Diagramm schreibe ich sehr wenig nutzlosen Code. Diagramme geben mir die Gewissheit, dass ich verstehe, wie die Klasse, die ich schreibe, in das gesamte System passt.

Der Punkt, den ich anstrebe, ist, dass ein Trivialprogramm ohne Pläne geschrieben werden kann, aber ein Spiel alles andere als trivial ist. Vor einiger Zeit, als OOP neu war, gab es viele Experimente und einige Best Practices kamen zum Vorschein. Die Softwareentwickler waren sich einig, dass wir eine Sprache zum Schreiben und Analysieren von Softwaredesigns benötigen. Die UML ist die Sprache, die wir entwickelt haben. Wir alle kennen und verstehen das. Wenn Sie also die Lösungen anderer für Ihre Probleme (Bücher, Online-Diskussionen, Artikel, Musterkataloge usw.) verwenden und das Rad nicht neu erfinden möchten, müssen Sie lernen, die Standardnotation zu lesen. Als Bonus lernen Sie unerwartete Dinge, wenn Sie sich zwingen, über Ihr System in einer anderen Sprache nachzudenken.

Es gibt viele verschiedene Methoden, aber alle identifizieren das Problem und beschreiben systematisch eine Lösung. Das ist Engineering. Die UML ist riesig und komplex, aber kein Modell verwendet jedes Konstrukt. Es ist wie ein Schweizer Taschenmesser. Sie müssen es kennenlernen und herausfinden, wie Sie es verwenden können, um Ihren Engineering-Prozess zu unterstützen. Wichtig ist nicht, welcher Prozess oder welche Methodik Sie haben, sondern dass Sie eine haben. Andernfalls werden Sie in Komplexität ertrinken.

Ich arbeite auch an einigen unabhängigen Spielprojekten mit einem Freund (2-Personen-Team). Als jemand, der sich in einer ähnlichen Situation wie Sie befindet, kann ich ein paar Leckerbissen anbieten, die ich als hilfreich empfunden habe.

1. Wenn Ihre Ideen grob sind, versuchen Sie, sie einzeln in winzige Prototyping-Projekte umzusetzen. Zum Beispiel mache ich gerade ein 2D-Plattformspiel, und es ist mir extrem wichtig, den Sprung des Spielers richtig zu machen. Also habe ich ein neues Projekt erstellt, in dem nur zwei Dinge passieren: a) Den Spieler auf den Bildschirm zeichnen und b) Eingaben erkennen und den Sprung neu zeichnen. [Der Charakter kann sich nicht einmal nach links oder rechts bewegen.]
2. Einige Leute mögen diesen Rat missbilligen, aber denken Sie darüber nach, zuerst das Spielhandbuch zu schreiben (um die Konzepte, Kontrollen und Ziele zu erklären). Dies kann zwei Dinge für Sie tun - ein dringend benötigtes Dokument generieren, aber auch die Subsysteme Ihres Spiels und alle notwendigen Details für den Spieler skizzieren. Wenn Sie im Voraus wissen, was der Spieler wissen muss, wissen Sie im Voraus, was Sie tun müssen.
3. Schreiben Sie Code in so kleinen (auch als modular bezeichneten ) Blöcken, dass die faktorisierten Stücke entweder verschoben oder besser organisiert werden können, ohne das Gefühl zu haben, dass Sie versuchen, alle mittelgroßen Spaghettistücke von einem Pastateller zu entfernen.

Hoffentlich haben Sie dort mindestens eine nützliche Information gefunden und viel Glück!

Ich denke, es gibt einige wertvolle Erkenntnisse von UML, die Sie nicht leugnen können. Denken Sie andererseits daran, dass UML für Geschäftsprozesse entwickelt wurde, die Systeme mit vielen Mitarbeitern modellieren interagieren, und zwar mit unterschiedlichen Wünschen, Bedürfnissen und Wünschen. UML versucht sicherzustellen, dass Sie nichts auslassen oder von Details überwältigt werden.

UML ist "eine Standardmethode zur Visualisierung der Systemarchitektur"

UML beschreibt

• Aktivitäten
• Schauspieler
• Arbeitsprozesse
• Datenbankschemata
• (logische) Komponenten
• Programmiersprachenanweisungen
• wiederverwendbare Softwarekomponenten

Aber wenn Sie ein einfaches Spiel machen, müssen Sie all dies wirklich modellieren?

• Schauspieler: Der Spieler.

Wie viel hilft das?

Das Modellieren einiger anderer Dinge ist jedoch sehr hilfreich. Wenn Sie beispielsweise ein kleines MMO erstellen, möchten Sie auf jeden Fall gut gestaltete Datenbankschemata.

Die UML-Abläufe sind zwar hervorragend (wissen Sie, was Sie tun, schreiben Sie die Anforderungen auf und skizzieren Sie Diagramme von Flussdiagrammen, wo immer sie benötigt werden), und Elemente davon sind sehr nützlich. Ich bin jedoch der Meinung, dass der gesamte UML-Prozess darin besteht Ein bisschen wie ein quadratisches Loch für Spiele.

UML ist nicht eine Sache, es ist eine Sammlung von Dingen, von denen einige etwas wert sind, andere weniger. die älteren Use Cases (zumindest was wir Use Cases nennen) geben diesen Zustand an

• Name
• Anforderungen
• Voraussetzungen
• löst aus
• Aktionen
• alternative Aktionen
• Ausnahmen

kann sehr nützlich sein. Was Sie für "Use Cases" finden, wenn Sie eine Websuche durchführen (die Bilder), ist eher für allgemeine Software gedacht.

Ich würde auch das Klassendiagramm etwas würdigen. Dies zeigt, dass Sie die Beziehung zwischen all Ihren Objekten anzeigen können und das Layout Ihrer Architektur kennen.

Es kommt darauf an, dass Ihr Feature-Set vor der Modellierung vollständig geplant und gesperrt ist (sofern dies in einem Bedarfs- / Wunsch-Setup vorgesehen ist), und das Diagramm sogar gestartet wird. Diese sollten alle in Ihrem Brief / Treatment / Script enthalten sein (manchmal auch als Pitch, Feature-Dokument und Story bezeichnet). von dort aus würden Sie dann Ihre technischen Unterlagen mit Ihren Modellen und Diagrammen fertigstellen.

Es gibt Unternehmen, die UML verwenden, aber dies sind in der Regel Unternehmen, die separate Design- und Implementierungsteams haben. die Unternehmen, die ihre gesamte Dokumentation erstellen und sie dann einem Team von Code-Affen übergeben, um einen Prototyp / Alpha zu erstellen. Es heißt, wenn Sie Ihr Spiel genau modellieren können, sollten Sie es einem völlig anderen Team geben und programmieren können, obwohl dies eher ein Wunschtraum als eine Genauigkeit ist.

Sie werden Sie an Ihrer Universität über UML unterrichten, damit Sie dem Rest Ihres Teams Ihre Ideen mitteilen können, und Dozenten zeigen, dass Sie über gute Kenntnisse der grundlegenden Prinzipien des Software-Engineerings verfügen.

Wie bei jeder Diskussion über Sprache, Tools oder Design kommt es in der Regel darauf an, wie SIE es verwenden. Wählen Sie das beste Werkzeug / die beste Sprache / das beste Design für den Job und stützen Sie Ihre Wahl mit einer starken Begründung. Ich gebe zu, dass UML für die Spieleproduktion nicht so flexibel ist, obwohl ich sagen kann, dass wir es effektiv zur Modellierung von Engine-Funktionen wie Netzwerkkommunikation und -timing, parallele Aufgabenverwaltung und Anwendungsfälle eingesetzt haben. Es gibt nichts Schlimmeres, als 5 verschiedenen Teammitgliedern das Gleiche 10 Mal zu erklären, weil sie es nicht ganz verstehen. Hier ist die Dokumentation, lies sie.

Abhängig davon, wie solide Ihre Entwürfe sind und wie diszipliniert Ihr Team ist, kann es sehr produktiv sein, Ihre eigenen Konstruktionen anhand der Konstruktionen zu modellieren, mit denen Sie noch nicht begonnen haben, und dennoch genau zu wissen, wie sie aufgrund des Projekts funktionieren werden Dokumentation.

Trotzdem werden Sie wahrscheinlich hören (und feststellen, dass es sich um LEBENDE DOKUMENTE handelt), und wenn sie nicht regelmäßig überprüft und aktualisiert werden, sind sie schnell überholt und praktisch unbrauchbar.