Kann ich Feature Creep zu meinem Vorteil nutzen? [geschlossen]

Kann ich Feature Creep zu meinem Vorteil nutzen?

Jedes Mal, wenn ich ein Spiel als Prototyp entwerfe, werden versehentlich Features hinzugefügt. Dies geschieht entweder durch Zufall, oder es ist einfach, es basierend auf vorhandenen Inhalten hinzuzufügen.

Wenn ich das Genre des Spiels kenne, kann ich dann einfach damit beginnen, die grundlegenden Mechanismen zu erstellen und Features hinzuzufügen, sobald sie offensichtlich werden?

Wenn ich zum Beispiel über einen Zeitraum von 6 Monaten einen 2D-Plattformer herstellen möchte, kann ich dann einfach mit dem Laufen, Springen, Schießen usw. beginnen und die Kernmechanik hinzufügen, wenn ich sie versehentlich finde? Oder ist dies zu riskant für eine Zeitinvestition ohne vorher festgelegten Plan?

Meine Logik dahinter ist, dass das Design mehr für das Geld sein wird. Die Entwurfsentscheidungen lassen sich einfacher auf das aufbauen, was (zeitlich) einfach zu treffen ist.

Fazit: Stimmt etwas nicht mit dem Erstellen eines Spiels, bevor ich es gestalte?

Das ist eine interessante Frage. Hauptsächlich, weil die Beantwortung das Dilemma zwischen Grautönen und Schwarz und Weiß erhöht.

Ist etwas falsch daran, ein Spiel zu erstellen, bevor ich es entwerfe?

Wenn Sie diese Frage als Ja- oder Nein-Typ betrachten, kann die Antwort nur lauten: Ja, das gibt es. Wenn die Antwort nuancierter sein kann, ändert sich dies. Grund: Sie sollten nie ein Spiel vor dem Bau einiger Gestaltung. Sie können jedoch Teile des Designs für später speichern .

Das heißt, ich denke nicht, dass Sie das vorliegende Problem als eine Aufgabe sehen sollten oder nicht. Vielmehr ist es etwas, woran Sie in Grad denken sollten. Feature Creeping ist vielleicht die zweitwichtigste Wurzel allen Übels in Bezug auf die Spieleentwicklung (die erste, wie Donald Knuth meinte, ist, dass "vorzeitige Optimierung die Wurzel allen Übels ist" ). Nach meiner Erfahrung ist es jedoch auch keine gute Idee, an eine der Hauptfunktionen zu denken, dh nicht mindestens die Grundkonstruktion zu haben, in die Sie Ihre Grundmechanik integrieren möchten.

Der erste Hauptgrund ist, dass es in Bezug auf Ressourcen (einschließlich Zeit als Ressource) hilfreich ist, eine gewisse Planung zu haben, um Sie durch die Sackgassen zu führen Ressourcen müssen unvorhergesehene Funktionen enthalten.

Der zweite Hauptgrund, was das Spieldesign betrifft, ist die Kohärenz. Gutes Game-Design hat konzeptionelle Kohärenz oder Konsistenz, wenn Sie wollen. Es bedeutet, dass das gesamte Gameplay, die Geschichte, die Implementierung und sogar die Grafiken so reibungslos wie möglich zueinander passen sollten. Es ist sehr unwahrscheinlich, dass ein Game-Design so etwas erreicht, wenn die wichtigsten Funktionen nur unterwegs herausgefunden werden. Wenn nicht für irgendetwas anderes, weil unterwegs eine Menge Zufälligkeit dahinter steckt: Die Dinge, auf die Sie treten, können sehr unterschiedliche Auswirkungen haben, je nachdem, wann Sie sie im Entwicklungsprozess gefunden haben .

Ich meine nicht, dass du nicht tun sollst, was du gesagt hast. Ich behaupte nur, dass Sie ein Gleichgewicht finden müssen.

Wenn ich zum Beispiel über einen Zeitraum von 6 Monaten einen 2D-Plattformer herstellen möchte, kann ich dann einfach mit dem Laufen, Springen, Schießen usw. beginnen und die Kernmechanik hinzufügen, wenn ich sie versehentlich finde? Oder ist dies zu riskant für eine Zeitinvestition ohne vorher festgelegten Plan?

Ich würde mit einer geringfügigen Änderung Ihres Satzes beginnen. Durch das Laufen, Springen, Schießen und so weiter implementieren Sie bereits die Kernmechanik. Was Sie in Ihrem Beispiel für unterwegs hinzufügen würden, sind die spezifischen Spielfunktionen.

Es ist nicht so, dass Sie wissen, dass das Spiel eine 2D-Plattform sein wird, das Laufen, Springen oder Schießen kann je nach Spieldesign nicht variieren. Kann dein Spieler an den Wänden rennen? Kann Ihr Spieler beim Springen in der Luft schweben? Kann Ihr Spieler sogar beim Laufen schießen? Schießt Ihr Spieler nur in einer linearen Richtung oder über eine Parabel? Diese Entscheidungen können sehr stark von den jeweiligen Spielfunktionen abhängen.

Aber ich verstehe Ihren Standpunkt: Diese Mechanik hat oft Teile, die sich nur sehr wenig unterscheiden. Wenn Sie also ein wenig Spieldesign machen und sich für grundlegende Funktionen entscheiden, um sicher zu sein, wie Laufen, Springen, Schießen usw. funktionieren, ist das ein Anfang. Dann können Sie sich für diese Mechaniker entscheiden und weiter darauf aufbauen.

Natürlich können Sie später noch eine neue Funktion finden, bei der Sie diese Mechanik ändern müssen - egal wie grundlegend sie war. Aber der Schlüssel ist hier die Wahrscheinlichkeit. Die Wahrscheinlichkeit, dass dies zu oft passiert, ist geringer, wenn Sie zumindest über die Konsequenzen des Laufens, Schießens, Springens usw. für die Grundideen nachdenken, die Sie für das Spiel hatten.

Zum Schluss, wenn Sie diesen Weg gehen möchten, würde ich Folgendes vorschlagen. Betrachten Sie es als einen iterativen Prozess. Sie üben ein anfängliches, allgemeines Design-Denken aus. Sie implementieren das, was grundlegender und "universeller" erscheint, in Ihr Spiel, damit es erfolgreich ist. Dann überlegen Sie sich etwas mehr, überdenken, überdenken, was Sie implementiert haben, und entscheiden sich für eine weitere Implementierung.

Wenn Sie komplexe Projekte wie Spiele ausführen, können Sie oft nicht alle gewünschten Funktionen erstellen, weil Ihnen die Zeit / das Geld ausgeht oder weil sich herausstellt, dass sie nicht so gut sind, wie Sie es erwartet haben. Dies wird als Merkmalskriechen bezeichnet. Aber das hat eine Kehrseite. Sie werden auch Funktionen finden, von denen Sie nicht dachten, dass sie benötigt werden, aber wenn das Projekt Gestalt annimmt, wird deren Bedarf offensichtlich.

Aus diesem Grund bauen die Leute Prototypen - damit sie lernen, was funktioniert und was nicht, damit sie Funktionen schneiden können , die nicht funktionieren , aber auch, um neue Funktionen zu finden, die großartig wären . Wenn Sie keines dieser Dinge tun, die Sie nicht lernen , machen Sie es falsch.

Dies ist im Grunde das Gefühl, das in einem Vortrag namens Advanced Prototyping von Chris Hecker und Chaim Gingold zum Ausdruck kommt , der viele Beispiele aus ihrer Arbeit an Spore enthält, in denen sie oft überrascht waren, was funktionierte und was nicht, bis hin zur Neugestaltung des Ganzen Systeme basierend auf Prototyp-Feedback.

Ein weiteres Beispiel ist der Entwurfsprozess für Left 4 Dead . Anfangs hatte das Spiel nur einfache Zombies, aber die Entwickler stellten beim Testen mit erfahrenen Spielern fest, dass die Spieler effektiv zusammen hielten und das Spiel zu einfach war. Deshalb fügten sie spezielle Zombies hinzu, um das Team auseinanderzubrechen und das Spiel aufregend zu halten.

Das bedeutet natürlich nicht, dass Sie Ihr Spiel ohne vorheriges Design erstellen sollten . Sie sollten sicherstellen, dass der Kern Ihres Spiels Spaß macht, bevor Sie fortfahren, da dies häufig der schwierigste Teil bei der Erstellung eines Spiels ist.

Ich würde ja sagen, mach mit. Planen Sie jedoch einige gemeinsame Features / Klassen im Voraus, um eine gewisse Kohäsion zwischen den einzelnen neuen Komponenten zu erzielen.

Unity ist für seinen komponentenorientierten Ansatz bei der Spieleentwicklung bekannt und würde diese Form der Entwicklung leicht ermöglichen. Wenn Sie Unity nicht verwenden, können Sie einen Semikomponentenansatz replizieren. Ich bin mit anderen Spiele-Engines nicht vertraut.

Einheitsspielobjekte haben alle eine Transformationskomponente. Hier werden Position, Drehung und Maßstab des Objekts angegeben. Erstellen Sie also eine generische "Transformation" -Klasse, die diese Werte enthält, sowie möglicherweise einen Verweis auf das eigentliche Spielobjekt.

Nehmen Sie zum Beispiel eine Sprungkomponente. Lassen Sie die gesamte Logik mit der Transformationsklasse eines Spielobjekts arbeiten, um die Position zu manipulieren. (Oder Ihre Engine verfügt bereits über eine ähnliche eingebaute Klasse.) Sie können diese 'Jump'-Klasse an jedes Objekt anhängen, und die Klasse animiert die Transformationsposition, wenn eine Aktion ausgelöst wird (Jump.PerformJump () oder was auch immer). Die Jump-Klasse muss nichts über ihren Besitzer wissen (oder zumindest minimale Informationen).

Jetzt können Sie Spaß daran haben, eine Tonne von Komponenten zu erstellen, sie dann an Spielobjekte anzuhängen, sie auf einem Objekt zu kombinieren usw. Zum Beispiel: Run, Jump, Crouch, MovingTile, FireWeapon eine generische Komponente) usw.

Stellen Sie jede Komponente so allgemein wie möglich ein, um mehrere Verwendungen / Variationen zu ermöglichen. Für FireWeapon können Sie das Aufzählungszeichen, die Geschwindigkeit, den Schaden usw. angeben. Sie können versuchen, diese Attribute zu normalisieren, sodass Geschwindigkeit und Schaden zwischen 0 und 1 angegeben werden. Skalieren Sie diese dann auf die Maximalwerte des Spiels. Auf diese Weise sorgen Sie sich nur um relative Unterschiede zwischen den Waffen. Dies passt sich außerdem globalen Einstellungen an, wie z. B. Schwierigkeitsgrad, bei dem ein höherer Schwierigkeitsgrad einen höheren maximalen Schaden verursacht.

Bevor Sie es wissen, müssen Sie ein Arsenal an Komponenten einstecken, und Sie können sich jetzt schnell für jeden Spieltyp entwickeln.

Kurz: Meistens können Sie nicht einen einzelnen Entwurfsschritt gefolgt von einem einzelnen Codierungsschritt haben. Sie müssen sie abwechseln. Versuchen Sie generell, das zu respektieren, was bereits entworfen wurde (nicht das, was bereits codiert wurde).

Über das Fehlen eines ursprünglichen Entwurfs (nur einer Skizze oder eines mentalen Bildes): Wenn Sie keinen Entwurf haben, haben Sie keinen Entwurf. Sie müssen etwas tun, um mit einem zu kommen. Aber solange Sie anfangen, eine zu bauen, versuchen Sie, diese zu respektieren, und kommen Sie nicht jedes Mal mit einer neuen.

Experimentieren Sie und erhalten Sie zufällige Funktionen, die möglicherweise nicht schädlich sind. Es kann sogar nützlich oder unvermeidlich sein. Zum Beispiel: Sie wissen, dass Sie das Springen unterstützen möchten (viele 3D / 2D-Rollenspiele erlauben das Springen nicht). Woher weißt du das? Weil Sie sich eine Game Map vorgestellt haben, bei der Sie springen müssen, um ein Hindernis zu überwinden? Die Sprungimplementierung ist also gut genug, solange der Spieler das Hindernis sortieren kann oder bestimmte Eigenschaften wie die maximal erreichbare Höhe erfüllen muss. Kann sie durch Gegenstände oder Spielobjekte in der Karte verstärkt werden, muss die Physik eine Beschleunigung oder einen Sprung beinhalten ( Wenn Mario in einen Feind springt, bekommt er den Impuls, sich wieder zu erheben, und das ist sehr wichtig für das Spiel.

Wenn Sie diese Fragen bereits beantworten können, sind Ihre Entwurfsunterlagen (imaginär oder real) sehr vollständig. Wenn Sie diese nicht beantworten können, ist Ihr Entwurf unvollständig. In diesem Fall müssen Sie erneut an der Konstruktion arbeiten oder experimentieren, um die Lücken zu schließen. Die Möglichkeiten können sehr offen oder sehr restriktiv sein. Wenn einige deiner Spiellevels Hindernisse haben und du nur das Springen für sie brauchst, dann gibt es eine Menge Freiheit, die maximal erreichbare Höhe oder die Geschwindigkeit zu bestimmen. Vielleicht entscheidest du dich dafür, vorzutäuschen, dass es eine Physik-Engine gibt, mit der alles nur zu beginnen ist Verbessere die Grafik der Sprunganimation, aber du brauchst sie für nichts anderes. (In vielen 2D-RPG-Spielen können Sie nicht springen, wenn Sie möchten, aber solange es ein einzelnes Kachelloch in einer Karte gibt, wird beim Versuch, es zu betreten, automatisch ein Sprung auf das Bodenplättchen neben dem Lochplättchen ausgelöst.)

Ich verstehe, dass es in Ordnung ist, ohne ein vollständiges Design zum Code zu gehen, solange Sie das respektieren, was bereits entschieden wurde. Es kann auch in manchen Situationen unvermeidbar sein, da Spieluniversen aus einer Vielzahl unterschiedlicher Denkprozesse aufgebaut sein können. Zum Beispiel ein Kartenspiel: Ich weiß, dass die Karten Angriff und Verteidigung haben sollen, eine bestimmte Anzahl von Karten zu einem bestimmten Zeitpunkt im Tisch und dass der Spieler während seines Zuges auswählen kann, mit welcher Karte welche andere Karte angreift. Es mag für manche als ein bereits vollständiges Design erscheinen, aber dann kommt es zum Ausgleich des Spiels, was nur durch viele Simulationen möglich ist. Nach vielen Simulationen entscheide ich, dass eine Karte mit Attack 10 überfordert ist. Ich kann sie einfach aus dem Spiel löschen, aber es gefällt mir zu gut, so dass ich etwas anderes machen werde. Ich werde eine neue Regel erstellen, die besagt, dass ein Spieler, der mit einer solchen Karte angreift, in diesem Zug nicht mit einer anderen Karte angreifen kann. Jetzt habe ich eine neue Regel, die die Spielmechanik bereichert, aber wende sie auf eine einzelne Karte an, die seltsam aussieht (wie ein schmutziger Hack). Mir ist klar, dass sie seltsam aussieht, und dann entscheide ich mich, einen neuen Kartensatz zu erstellen, der aber hohe Zahlen hat für sie gilt eine neue einschränkungsregel. Jetzt habe ich eine komplexere Spielmechanik, die über der einfacheren aufgebaut ist. Meiner Meinung nach habe ich es zu meinem Vorteil gemacht, ein besseres Spiel zu machen.

Nun, eine Sache zu diesem letzten Beispiel, in dem vorgeschlagenen Beispiel des Kartenspiels, können neue Karten zu neuen Vermögenswerten führen (Kostenerhöhung, Zeiterhöhung). Aber ich denke, dies ist ein gutes Beispiel dafür, wie die Möglichkeiten, die Sie nur beim Codieren sehen, Ihre Entwurfsentscheidungen auf gute Weise beeinflussen.

Ich glaube nicht, dass die meisten Spiele, die wir spielen, vor dem Codieren vollständig entwickelt wurden. Ich bin sicher, dass sie schwierige Entscheidungen treffen mussten, um die Zeitpläne einzuhalten und so weiter.

Wenn jemand anderes für alles zahlt: Erklären, verhandeln.