Game Engine und datengetriebenes Design

Ich habe von datengetriebenem Design gehört und eine Weile darüber geforscht. Daher habe ich mehrere Artikel gelesen, um die Konzepte zu erhalten.

Einer der Artikel ist Data Driven Design von Kyle Wilson. Wie er beschrieben hat, scheint es mir, dass der Anwendungscode (dh der Code zum Steuern von Ressourcen wie Speicher, Netzwerk ...) und der Spiellogikcode getrennt und der Spiellogikcode von externen Datenquellen gesteuert werden sollten. An diesem Punkt kann ich mir vorstellen, dass der Entwickler eine Art Spieleditor schreibt, der externe Daten über Objekte im Spiel akzeptiert (wie z. B. Charakterinformationen, Waffeninformationen, Karteninformationen ...). Das Szenariodesign wird mit Hilfe einer benutzerdefinierten Sprache / eines benutzerdefinierten Tools erstellt, die / das vom Programmierer geschrieben wurde, damit der Spieleentwickler eine Interaktion zwischen Objekten im Spiel erstellen kann. Der Spieleentwickler verwendet entweder eine vorhandene / benutzerdefinierte Skriptsprache, um ein Skript für das Spiel zu schreiben, oder ein Drag & Drop-Tool, um eine Spielwelt zu erstellen. Ein Beispiel für einen Tool-Ansatz, den ich mir vorstellen kann, ist der World Editor, der normalerweise zusammen mit den Spielen von Bliizard geliefert wird.

Ein anderer Artikel ist jedoch gegen die Verwendung von datengesteuertem Design, The Case Against Data Driven Design . Der Autor schlägt vor, das Spieldesign nicht von Daten leiten zu lassen, da die Entwicklung eines Spiels mehr Zeit in Anspruch nehmen würde, da der Spieleentwickler die Programmierlast trägt. Stattdessen gibt es einen Spielprogrammierer, der das Spiel frei vom Skizzendesign programmiert und nach Abschluss der Spielprogrammierung vom Spieledesigner überprüft wird. Er nennt das programmierergesteuert. Was ich von dieser Methode halte, ähnelt meiner bisherigen Vorgehensweise: Die Spielelogik ist die Anwendung selbst, im Sinne der obigen Idee, die Anwendung ist der Spieleditor, und das eigentliche Spiel basiert auf dem Tool.

Die erste Methode erscheint mir sinnvoller, da Spielkomponenten für viele Projekte wiederverwendet werden können. Bei der zweiten Methode, die datengesteuertes Design ablehnt, gehört der Spielcode nur zu diesem Spiel. Aus diesem Grund denke ich, dass Warcraft so viele Spielgenres enthält, wie das ursprüngliche Warcraft und verschiedene benutzerdefinierte Karten, und eines der bekanntesten: DOTA, das tatsächlich ein neues Genre definiert. Aus diesem Grund habe ich gehört, die Leute nennen den World Editor die Spiele-Engine. Ist das wahr, wie eine Game Engine sein sollte?

Nach alledem möchte ich nur überprüfen, ob es einen Fehler in meinem Verständnis dieser Ideen gibt (datengesteuert, Programmiererlaufwerk, Skripterstellung usw.).

Es ist fast immer ein Vorteil, Ihr Spiel (oder ein beliebiges Softwareprodukt) datengetrieben zu machen. Der einzige wirkliche Nachteil ist, dass Sie möglicherweise etwas mehr Zeit für den Aufbau der entsprechenden Systeme im Vorfeld aufwenden. Es wird sich jedoch für den Rest Ihrer Karriere als Programmierer auszahlen (auch wenn Sie diese Systeme nicht die ganze Zeit über wiederverwenden, werden Sie die Techniken wiederverwenden, die Sie zum Erstellen dieser Systeme eingesetzt haben).

Die Herausforderung und wo die Trennung in diesen beiden von Ihnen verknüpften Artikeln zum Tragen kommt, ist, was Sie auswählen, um Daten einzugeben, und wen Sie auswählen, um Zugriff auf diese Daten zu gewähren. Grundsätzlich bedeutet datengetriebenes Design und Entwicklung nur, dass Sie Informationen in einen externen Speicher stellen, diese Informationen zur Laufzeit laden und darauf reagieren. Ihr Anwendungscode macht das, was die externen Daten ihm sagen, anstatt dass Sie Anwendungscode schreiben, der direkt das tut, was Sie für das Endergebnis halten. Es ist keine komplexe Idee.

Sie müssen keine komplexen "komponentengetriebenen Architekturen" erstellen (wie es heutzutage üblich ist). Das Einfügen von Konstanten zur Optimierung der Physik (Gravitationskraft, Restitutionskoeffizienten) in eine Textdatei erfolgt datengesteuert. Skripte (in Lua oder etwas anderem) sind datengetrieben. Beschreiben Ihrer Ebenendaten in XML. Sowas auch.

Sie können nahezu jede Softwarekomponente mit Daten betreiben und auswählen, mit welchen Sie dies tun möchten. Entwicklerzeit ist teuer; Programmiererzeit besonders so. Wenn Sie sich oder anderen Programmierern Zeit sparen können, indem Sie Verhalten und Daten in einem externen Speicher ablegen und das Spiel nicht für jede kleine Änderung neu kompilieren müssen, sollten Sie dies tun. Sie sparen Geld und erledigen Ihre Aufgaben schneller.

Außerdem laufen Sie ein großes Risiko, wenn Sie versuchen, "Designer-Design" zu machen, und lassen Programmierer "diese Designs Wirklichkeit werden lassen", was einen Programmierer dazu zwingt, in der Iterationsschleife für die Arbeit eines Designers zu existieren Er ist nur ein Code-Affe, der ständig kleine Änderungen am Design vornimmt. Dies kann für die große Mehrheit der Programmierer eine massive Demoralisierung darstellen, die an interessanten technischen Herausforderungen arbeiten möchten und nicht daran, ein Vertreter des Designers zu sein.

Für Ihre spezifischen Fragen:

Ist das wahr, wie eine Game Engine sein sollte?

Eine "Game Engine" hat eigentlich keine feste Definition. Im Allgemeinen ist es die vereinheitlichte Sammlung der zugrunde liegenden Technologie, die für die Erstellung eines Spiels verwendet wird und normalerweise von einer Reihe verwandter Tools unterstützt wird (und daher recht datengetrieben ist). Aber es variiert ziemlich stark von Kontext zu Kontext.

Nach alledem möchte ich nur überprüfen, ob es einen Fehler in meinem Verständnis dieser Ideen gibt (datengesteuert, Programmiererlaufwerk, Skripterstellung usw.).

Sie scheinen mehr oder weniger auf dem richtigen Weg zu sein, obwohl Sie die datengetriebene Konstruktion und Entwicklung möglicherweise übermäßig komplizieren, indem Sie sie mit komponentenbasierten Systemen kombinieren.

Als Autor des zweiten Beitrags möchte ich einige Punkte klarstellen.

1. Wie Josh Petrie vorgeschlagen hat, ist es immer ein Gewinn, Ihren Code so zu strukturieren, dass er Daten verwendet, anstatt nur hart zu codieren. Ich schlug nicht anders vor. Ich habe darauf hingewiesen, dass es keine gute Idee ist, alles auf den Designer zu schieben. Der Begriff "datengetriebenes Design" bedeutet für verschiedene Menschen verschiedene Dinge, daher hätte ich beim Verfassen des Originalartikels wahrscheinlich präziser sein sollen.
2. An jedem Ort, an dem ich gearbeitet habe, erstellen wir Datenstrukturen, die in der Engine optimiert werden können. Um eine Änderung vorzunehmen, müssen wir das Spiel nicht neu kompilieren. Wir können die Nummer zur Laufzeit dynamisch ändern. Die Datenstrukturen werden häufig in Code gespeichert, aber je nachdem, wer sie ändert, können sie leicht aus einer "Datendatei" geladen werden.
3. Die meisten Entwicklungsumgebungen unterstützen irgendeine Form des Bearbeitens und Fortsetzens oder des Modulneuladens für C / C ++.
4. Die meisten Spieleentwicklungsstudios haben Gameplay-Programmierer. Ihre Aufgabe ist es oft, mit dem Designer zusammen eine lustige Erfahrung zu schaffen. Ihr Hauptanliegen sind keine technischen Herausforderungen, sondern das Erstellen von Spaß aus Code. Ich habe viele Jahre als Gameplay-Programmierer gearbeitet und finde das interessanter, als nur technische Herausforderungen zu lösen. Meine Aufgaben waren unterschiedlich, aber ich fand meine Arbeit am erfüllendsten, wenn ich für die Implementierung verantwortlich bin und mit den Designern an der Gestaltung von etwas Coolem arbeite. Das Problem bei der Programmierung oder Skripterstellung von Designern besteht darin, dass Programmierer häufig die Fehler aussortieren müssen, was eine der am wenigsten unterhaltsamen Aufgaben ist, die Sie als Programmierer ausführen können.
5. Was für ein Studio am besten funktioniert, hängt vom Spiel ab. Wenn Sie viel Zeit haben, um ein Spiel zu erstellen, und Sie möchten der Mod-Community die Beine aus dem Leib geben und einen riesigen Spielraum schaffen, dann ist es sinnvoll, ein Spiel zu erstellen, das vollständig datengesteuert ist. Viele Spiele haben dieses Ziel nicht. Sie müssen in zwei Jahren ein neues Spiel herausbringen, und wenn sie kein Hit-Franchise haben, ist es wahrscheinlich eine andere Art von Spiel als ihre vorherige Arbeit
6. Was ein "Designer" macht, kann von Studio zu Studio unterschiedlich sein. Ich habe von einem Entwicklungsstudio gehört, in dem Gameplay-Programmierer von anderen Studios eingestellt werden, die sie als Designer bezeichnen und das Spielverhalten als Skript ausführen lassen. Dies umgeht das Problem, Menschen zu haben, die nicht in der Programmierung von Codierung / Skripten geschult sind.
7. Es sollte immer eine Abgrenzung zwischen Game Logic Code und Engine Code geben. Außerdem möchten Sie normalerweise einen visuellen Editor für die Objektplatzierung haben. Ich habe noch nie in einem Studio gearbeitet, in dem feindliche Standorte fest programmiert sind. Sie werden in einen Editor gestellt. Lassen Sie mich ein Beispiel dafür vorschlagen, wovon ich spreche. Nehmen wir an, der Designer denkt sich einen Feind aus. Zeichnet der Designer das Verhalten dieses neuen Feindtyps als Skript? Das ist, was ich als datengetriebenes Design betrachte (in Bezug auf das, was Tim Moss darüber geschrieben hat). Wie ich vorschlage, arbeitet der Programmierer mit dem Designer zusammen, er macht sich zusammen einen lustigen Feind, vielleicht mit einstellbaren Parametern, und dann werden sie in das Level platziert.
8. Nativer Code, der von einem Programmierer geschrieben wurde, wird zur Laufzeit schneller ausgeführt als ein Skript, das von einem Programmierer geschrieben wurde. Dieses Skript wird schneller ausgeführt als ein Skript, das von einem weniger technisch versierten Benutzer geschrieben wurde. Diese Leistung ist abhängig von der Art des Spiels und dem, was Sie machen, möglicherweise nicht wichtig, aber es ist etwas zu beachten.
9. Sie können den Spielcode zwischen den Spielen teilen, unabhängig von der gewählten Methode. Ich bin mir nicht sicher, was Sie mit diesem Punkt erreichen. Auch wenn Sie keine Skriptsprache oder kein visuelles Tool verwenden, um bestimmte Verhaltensweisen zu definieren, sollten Sie Ihren Gameplay-Code so weit wie möglich in wiederverwendbare Komponenten zerlegen. Es wird immer Dinge geben, die für Ihr nächstes Spiel nicht relevant sind, aber an jedem Ort, an dem ich jemals gearbeitet habe, beginnen wir mit der Codebasis des vorherigen Spiels, auch wenn es sich nicht um eine Fortsetzung handelt. Wir behalten dann das Zeug, das Sinn macht, und entfernen das spielspezifische Zeug.

Am Ende gibt es keine richtige oder falsche Antwort. Es ist eine Frage, wie Sie und Ihre Mitarbeiter sich wohlfühlen. Als ich vor einiger Zeit diesen Blog schrieb, wurde viel darüber gesprochen, wie die ganze Arbeit an die Designer weitergegeben werden sollte, und ich wollte darüber schreiben, wie viele erfolgreiche Spielefirmen, von denen ich wusste, dass sie eine andere Balance gefunden haben.

Außerdem ist mein Blogeintrag 5 Jahre alt. Es scheint, als würden sich viel mehr Studios in Richtung Skriptsprachen bewegen und so weiter, aber sie entwickeln ausgereifte Tools, um sie zu debuggen, was meine Hauptbeschwerde war. Als ich das geschrieben habe, glaube ich nicht, dass es Unreal Kismet gab, das ich nicht benutzt habe, aber es scheint, als würden sie versuchen, das Scripting zu vereinfachen, und es hat anscheinend einen Debugger. (Keine Ahnung, wie gut es funktioniert)

Ich glaube, dass Sie bei Spielen im kleineren Maßstab nicht versuchen möchten, eine Skriptsprache oder ähnliche Funktionen in Ihre Technologie einfließen zu lassen, aber wenn Sie ein riesiges Team haben und viel Zeit für Technologie haben, ist dies möglich Richtig und der Zeitaufwand kann sinnvoll sein, je nachdem, wie Ihr Entwicklungsteam gerne arbeitet. Persönlich werde ich wahrscheinlich so lange wie möglich an C ++ festhalten, da es für mich das einfachste und schnellste ist, da ich oft versuchen muss, "Features" wie die Garbage Collection zu umgehen.

Sie sollten sich die BitSquid Tech Engine ansehen . Es basiert auf DOD-Konzepten. Der Blog von Niklas Frykholm ist sehr interessant. Es gibt viele Artikel darüber, wie dieser Motor konstruiert ist.

Auf der GDC 2011 hat Niklas einen Vortrag über Data Driven Renderer gehalten .