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


21

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.


26
UML ist Schwachsinn. Es ist ein schlecht entworfenes Paradigma, um Geschäftsleuten das Gefühl zu geben, etwas zu produzieren und zu verstehen, während sie tatsächlich nur nutzlose Einschränkungen schaffen.
o0 '.

Obwohl ich definitiv der Meinung bin, dass UML einen Platz in der Unternehmenssoftware hat, ist es nicht dazu gedacht, etwas zu Interaktives zu entwerfen. Versuchen Sie , einige Game Design Documents für bestehende Spiele zu finden , um zu sehen , wie sie die formalen Dinge handhaben , so etwas wie diese: delta3d.org/filemgmt_data/files/... auch versuchen , im Auge zu behalten vielen Prototypen zu tun und keine Angst Sachen wegwerfen (hier Wegwerfen bedeutet Regal in Ihrem Quellcodeverwaltungssystem und nicht aktiv verwenden).
Roy T.

4
Ich benutze xmind , um so ziemlich alles zu planen. Ich würde kein technisches Ding wie UML verwenden, wenn ich nicht dazu gezwungen wäre. Es ist wichtig, Dinge zu visualisieren, bevor man technisch wird. Mind Mapping ist dein Freund. Damit können Sie auch technische Dinge planen.
Er Shiming

Imho, das große Problem bei UML ist das Fehlen von Werkzeugen, um Diagramme zB in Klassen- und Funktionsdeklarationen umzuwandeln und umgekehrt. UML ist ein großartiges Werkzeug, um Ideen zwischen Teammitgliedern zu visualisieren und zu kommunizieren, aber die Art und Weise, in der die meisten UML-Workflows ohne Tools bestimmte Dinge zweimal ausführen, macht UML für kleine Projekte und / oder Hobbyprojekte überflüssig. Persönlich benutze ich Stift und Papier, um Beziehungen zwischen Klassen und Entitäten in einer Art Pseudo-UML zu visualisieren. Es ist schön, sich einen Überblick über Klasseninteraktionen und -hierarchien zu verschaffen.
Exilyth

Antworten:


18

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.


Ich denke, ich habe es gemischt. Ich denke, ich könnte sagen, dass ich wirklich einige grobe Spielsystemideen habe. Ich möchte jedoch wissen, wie ich mein "Code" -Designproblem effektiv angehen kann. Oder mit anderen Worten, meine Spielstruktur effektiv in Code umwandeln? Normalerweise muss ich wählen, ob ich längere Zeit zum Verallgemeinern des Codes oder zum schnellen spezifischen Codieren brauche. Normalerweise hat mir der erste die Hölle genommen, also bin ich auf den zweiten gegangen und bin später gegen eine Wand
gestoßen

2
Es sieht so aus, als wären Sie mit Softwaremodellierung noch unerfahren (Modellierung ist der Prozess der Übersetzung von abstraktem Design in konkrete Implementierung). Ich fürchte, das wird nur mit der Erfahrung wirklich besser. Eine gute Möglichkeit, um zu überprüfen, ob Sie Fortschritte erzielen, besteht darin, sich von Zeit zu Zeit Ihren über 6 Monate alten Code anzusehen. Wenn Sie nichts finden, was Sie anders schreiben würden (oder einfach besser), wenn Sie das Ding umschreiben, haben Sie sich in dieser Zeitspanne wahrscheinlich nicht verbessert.
TravisG

Einverstanden mit heishe - experience ist hier die einzig wahre Lösung, kombiniert mit dem Lernen, dass die Erfahrung zählt. Versuchen Sie, grundlegende Konzepte wie Verkapselung und Abstraktion, komplexere Konzepte wie das Demeter-Gesetz und das Prinzip der Einzelverantwortung, zu lesen und zu verstehen. Dieses Wissen, kombiniert mit der Praxis, gibt Ihnen die Werkzeuge, um Ideen in Arbeitscode zu übersetzen.
Kylotan

2

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.


2

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!


1

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.


1
Schauspieler: Designer, Künstler, Netzwerkspieler, (wenn Sie Glück haben) Geldgeber, qa Leute. Die Kommunikation zwischen Designern, Entwicklern, Kunden, Endbenutzern und Programmierern ist in allen Branchen der Softwareindustrie, die ich gesehen habe, bestenfalls miserabel. UML ist ein Tool, mit dem der Stakeholder eine gemeinsame Sprache für die Diskussion eines Projekts erhält. In der Entwicklungswelt herrscht ein gewisses Maß an Feindseligkeit gegenüber Dingen wie Dokumentation (Programmierer) und Quellcodeverwaltung / Zusammenarbeit (Designer), die die Qualität des endgültigen Projekts wirklich beeinträchtigen. Die meisten dieser Dinge werden von Teams gebaut, also müssen wir sie teilen.
Sinthia V

@SinthiaV Schauspieler sind nicht als das gemeint Entwicklerteam . Schauspieler sind die Personen, die mit dem Endprodukt interagieren .
Bobobobo

Was ist mit Level- / Ressourcen-Editoren und Engines? Das war der Anwendungsfall, auf den ich mich bezog.
Sinthia V

0

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.


0

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.

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.