Lohnt es sich, Spielmechaniken / -regeln getrennt vom Hauptcode zu implementieren?

Ich bin mir nicht sicher, ob es in den Bereich dieser Community passt oder ob ich stattdessen Stackoverflow verwenden soll.

Nehmen wir an, ich möchte, dass mein Spiel in seinem Kern einfach erweiterbar ist, dh, dass viele Leute, auch ohne gute Programmierkenntnisse, nicht nur vorhandene Regeln ändern, sondern sogar eine völlig neue Spielmechanik hinzufügen können. Ich bin selbst kein guter Programmierer, aber ich bin bereit zu lernen, ich brauche nur ein paar Anweisungen und die Gewissheit, dass es getan werden kann.

Ich habe darüber nachgedacht, ob es möglich / machbar ist, Spielmechaniken getrennt vom Hauptdienstprogrammcode zu implementieren . Ich meine, für Tabletop-Spiele haben wir die Regelbücher, die nicht die tatsächlichen Algorithmen aller Aktionen enthalten, sondern einige Protokolle und Grenzen beschreiben, wobei der Kontext eines jeden solchen Gegenstands stark referenziert wird. Ist es möglich, etwas Ähnliches für PC-Spiele zu tun, wie alle Regeln in einem sehr hohen Level zu beschreiben, leicht lesbar (und änderbar) durch eine menschliche Programmiersprache, die dann vom Utility-Code in eine "konsumiert" und analysiert wird funktionierende Instanz der Spielmechanik?

Das scheint wirklich so, als müsste ich meine eigene Sprache und einen Compiler dafür schreiben.)) Das kann ich natürlich nicht. Aber gibt es vielleicht eine einfachere Herangehensweise an das Problem?

Zu Ihrer Information: Meine bevorzugte Sprache für den Utility-Code wird Python 3.x sein

Im Allgemeinen hängt die Einfachheit, mit der ein System erweitert werden kann, davon ab, inwieweit seine Subsysteme eng oder locker gekoppelt sind . Je lockerer die Subsysteme gekoppelt sind, desto einfacher ist es normalerweise, sie zu modifizieren, da sie isoliert sind und nicht unbedingt ein vollständiges Verständnis des gesamten Systems erfordern.

Nichts ist kostenlos - ein solches System erfordert in der Regel mehr Ressourcen (verschiedene Kombinationen aus Zeit, Geld und Fähigkeiten), um es zu erstellen. Der Grad der Erweiterbarkeit, den Sie beschrieben haben, steht in direktem Widerspruch zu der Fähigkeit, die Sie sich selbst zugeschrieben haben. Es könnte getan werden, aber das Entwickeln von Software, wie Sie es beschrieben haben, ist ein sehr herausforderndes Unterfangen.

Die nächsten Dinge, die mir bekannt sind, sind Vassal (das viel programmatischer ist, als Sie beschrieben haben) oder die Modifikation für Tabletop Simulator (die hauptsächlich von der menschlichen Interaktion abhängt, um Spielregeln zu interpretieren und durchzusetzen).

Ich habe darüber nachgedacht, ob es möglich / machbar ist, Spielmechaniken getrennt vom Hauptdienstprogrammcode zu implementieren.

Das ist absolut möglich. Eine Möglichkeit, die beim Spielen häufig verwendet wird, ist Lua-Scripting .

Aus dem verlinkten Artikel:

Lua wurde ursprünglich 1993 als Sprache für die Erweiterung von Softwareanwendungen entwickelt, um dem damals wachsenden Bedarf an Anpassungen gerecht zu werden.

Viele Spiele verwenden Lua. (Ich würde verlinken, aber der Ruf eines neuen Benutzers schränkt meine Linkanzahl ein.)

Lua-Skripte können zur Laufzeit kompiliert werden. Dies bedeutet, dass es sich beispielsweise um Textdateien handeln kann, die sich im "Skript" -Verzeichnis Ihres Spiels befinden und von einem Modder leicht bearbeitet werden können. Ihr Spiel lädt sie und führt sie aus.

Ich habe gesehen, wie Lua-Skripte die Eigenschaften von Einheiten im Spiel definieren. Hier ist ein zufälliges Beispiel von TA Spring.

Aber Sie möchten "alle Regeln beschreiben". Theoretisch ist dies möglich, da Lua eine vollständige Sprache ist. Das Problem ist jedoch, dass Sie vorausschauend genug sind, um den Kern des Spielcodes zu kennen und nach Skripten zu suchen, mit denen das Verhalten erweitert werden kann.

Zum Beispiel könnten Sie ein Kartenspiel entwickeln, das in einem "scripts / cards" -Verzeichnis nach Karten sucht. Dies ist ideal, um neue Karten hinzuzufügen oder vorhandene Karten zu bearbeiten. Aber wenn Sie Ihr Spiel später erweitern möchten, um Miniaturen in ein Raster aufzunehmen, müssen Sie den Kerncode bearbeiten - keine Menge Lua-Geigen bringt Sie von alleine dorthin.

Bitte beachten Sie: Ich rufe Lua auf, weil ich weiß, dass es sowohl für Spiele als auch für Software zur Anpassung verwendet wird. Ich schlage nicht vor, dass es die einzige oder die beste Lösung für die Bedürfnisse des Fragestellers ist.

Es gibt ein Kontinuum von Ansätzen, und ob sich einer von ihnen lohnt, hängt davon ab, was Sie genau versuchen. Wie viel Kontrolle möchten Sie dem Tweaker bieten?

Am äußersten Ende der Kontrolle können Sie den Tweaker einfach den Code des gesamten Spiels ändern lassen. Zu diesem Zeitpunkt würden Sie im Wesentlichen den Dienstprogrammcode und mindestens ein Beispiel für dessen Verwendung veröffentlichen. Ein Tweaker kann so viel oder so wenig Code verwenden, wie er möchte.

Ein Ansatz, der etwas weniger Kontrolle bietet, besteht darin, den Utility-Code einzufrieren (z. B. durch vorheriges Kompilieren) und Tweakers nur bestimmte Funktionen (Rückrufe) ausfüllen zu lassen, um die Möglichkeiten einzuschränken. Je nachdem, was Sie tun möchten, kann dieser Ansatz viele Formen annehmen. Eine gebräuchliche Methode wäre, den gesamten Anzeigeteil in den Dienstprogramm- / Hauptcode und die gesamte Mechanik in den optimierbaren Teil einzufügen. Oder Sie möchten vielleicht einige Mechaniken im "eingefrorenen" Teil belassen, weil es unwahrscheinlich ist, dass Spieler sie ändern möchten, oder weil es zu kompliziert ist, sie änderbar zu machen.

Am unteren Ende des Kontinuums können Tweakers nur Werte innerhalb eines festgelegten Bereichs ändern. Ein Beispiel wäre eine Datendatei, mit der Sie die Farben der Dinge im Spiel auswählen können. Sie können diesen Ansatz jedoch verwenden und dennoch viele Anpassungen vornehmen. Es wäre möglich, eine Auswahl von Funktionen zu definieren und Tweakers zu erlauben, diese zusammenzustellen, um die Rückrufe aus dem vorherigen Ansatz zu erstellen, aber ihnen nicht zu erlauben, neue Funktionen zu definieren. Oder überspringen Sie den Kompositionsteil und bieten nur eine begrenzte Auswahl an.

Die Details all dieser Ansätze und welche für Ihren Anwendungsfall geeignet sind, hängen davon ab, welche Art von Basisspiel Sie erstellen und wie viel Kontrolle Sie aufgeben möchten. Beachten Sie, dass kommerzielle Spiele im Allgemeinen nur die zweite und dritte Methode verwenden, da die Spieler bei der ersten Methode völlig getrennte Spiele erstellen können, was zu komplizierten Lizenzierungsproblemen führt. Da diese Ansätze ein Kontinuum bilden, kann der zweite Ansatz diese Probleme ebenfalls einführen.

Es ist absolut möglich, die Regeln des Systems von dem Code zu trennen, der diese Regeln anwendet. Ich bevorzuge es, meinen Code für komplexe Projekte so zu strukturieren, da es einfacher ist, neue Regeln hinzuzufügen oder die Regeln später zu ändern, ohne Fehler in das zugrunde liegende System einzufügen. Und Bugs in einer Rules-Engine werden schneller gefunden als Bugs in einem System, in dem die Rules und der andere Code higgledy-piggledy miteinander vermischt sind, da dieselbe Rules-Engine von jeder Regel immer wieder verwendet wird.

Ob es sich lohnt, hängt von der Komplexität des Systems ab. Als würde ich mich nicht um Pac-Man kümmern, aber ich könnte mir nicht vorstellen, Dwarf Fortress anders zu schreiben.

Es ist definitiv machbar. Ob es sich lohnt, hängt von Ihren Zielen ab.

Sie müssen keine eigene Sprache erfinden oder einen Compiler schreiben, damit dies funktioniert.

Wenn Sie möchten, dass Ihr Spiel leicht erweiterbar ist, ist es wahrscheinlich eine gute Idee, sich dafür zu entscheiden.

Es ist wahrscheinlich mehr Arbeit für Sie, zumindest kurzfristig, verständliche Systeme zu erstellen und Änderungen zu vereinfachen.

Ein Spiel, das dies tut, ist Rimworld (ich habe keine Zugehörigkeit), und Sie können möglicherweise sehen und daraus lernen, wie sie es gemacht haben, indem Sie eine Menge Spieldaten und -mechaniken in XML-Dateien ablegen , die sich in den Spielordnern befinden, damit jeder sie sehen und lesen kann ändern. Der Kern / die Engine des Spiels wurde mit Unity erstellt.

Es gibt auch die Möglichkeit, das Spiel durch eigentliche Codierung weiter zu erweitern, ich weiß weniger darüber, aber du kannst es im Mods-Forum lernen.

Die Möglichkeit, das Spiel zu modifizieren, macht es für viele interessanter und ich denke, es hat viel zu seinem Erfolg beigetragen. Außerdem können die Entwickler beliebige Mod-Inhalte in das Hauptspiel einbinden, wodurch die Entwicklung beschleunigt und das Spiel verbessert wird, da sie Unterstützung von vielen Leuten erhalten, und sie können sich entscheiden, Dinge basierend auf zu übernehmen was ist beliebt, was scheint zu funktionieren, etc.

Und natürlich haben sie, besonders für ein kleines unabhängiges Studio, Hunderte von Leuten, die sich Ideen einfallen lassen und diese für sie testen, was eine Menge Arbeit ist, die sie selbst nicht erledigen oder wahrscheinlich Leute einstellen könnten.

Vielleicht möchten Sie sich mit objektorientiertem Design befassen . Python hat dafür eine gute Unterstützung.

Darüber werden dicke Bücher geschrieben, die für Anfänger beängstigend sein können, aber die Hauptprinzipien sind ziemlich einfach.

Der Hauptpunkt ist nur, dass Sie identifizieren, mit welcher Art von Objekten Sie arbeiten. Sie sagen nicht, über welche Art von Spiel Sie nachdenken, aber Dinge wie Spieler, Monster, Gegenstand, Ausrüstung, Waffe, Rüstung usw. sind typische Objekte.

Wenn Sie verschiedene Spieltypen möchten, möchten Sie wahrscheinlich ein Spielobjekt, das sich um die Siegbedingung und dergleichen kümmert. Vielleicht auch ein Kartenobjekt?

Manchmal ist nicht klar, ob etwas ein Objekt verdient oder nicht, z. B. Schaden. Wenn Sie einem Objekt keinen Schaden zufügen, wird der Code einfacher, aber wenn Sie es zu einem Objekt machen, wird das Anpassen einfacher.

Unterklassen: Sowohl Waffen als auch Rüstungen sind Ausrüstung. Ausrüstungen sind Einzelteile. Es gibt wahrscheinlich andere Arten von Gegenständen. Sie werden es wahrscheinlich nützlich finden, einen Klassenkämpfer zu definieren, dessen Unterklassen sowohl Spieler als auch Monster sind.

Die Idee ist, dass zum Beispiel Waffen viele Dinge mit allen anderen Arten von Gegenständen gemeinsam haben, sie haben ein Gewicht, eine Größe und andere Eigenschaften wie diese.

Wenn Sie eine Unterklasse wählen, können Sie sagen: "Waffen sind wie andere Gegenstände, aber Sie können sie auch einsetzen, sie wirken sich auf den von Ihnen verursachten Schaden aus, usw. usw."

Durch Unterklassen können Ihre Mod-Builder auch sagen: "Mein neuer Waffentyp entspricht genau den Standardwaffen, nur dass ..."

Dann musst du entscheiden, welches Objekt für was verantwortlich ist. Dies ist nicht so einfach, wie es scheint, und Sie sollten darüber nachdenken. Wenn Sie die falschen Entscheidungen treffen, wirkt sich dies nicht wesentlich auf das Grundspiel aus, es wird jedoch schwieriger, die Einstellungen anzupassen.

Solange Sie nur selber basteln, können Sie Dinge ändern, aber sobald Sie etwas für die Öffentlichkeit freigeben, wird es viel schwieriger, Änderungen vorzunehmen! Die Leute werden Modifikationen machen, die davon abhängen, dass die Dinge so sind, wie sie jetzt sind. Sogar Bugs. Die Leute werden Mods schreiben, die von Fehlern abhängen, die im Code bleiben. Wenn du Dinge änderst, brechen diese Mods und Lynchmobs erscheinen in deinem Haus.

Beispielsweise:

Ein Spieler mit einer Waffe greift ein Monster mit mehreren Rüstungen an. Dies geschieht in einem bestimmten Spielmodus und auf einer bestimmten Karte.

Beide Combatant können Fähigkeiten wie Critical Hit und Dodge haben.

Welches Objekt ist für was verantwortlich?

Darauf gibt es keine richtige Antwort. Viel hängt davon ab, welche Art von Anpassung Sie zulassen möchten.

Wenn Sie niemals ein Objekt aufrufen (z. B. die Karte), kann dieses Objekt den Angriff in keiner Weise ändern.

Nachdem Sie alle diese Entscheidungen getroffen haben, dokumentieren Sie sie . Schreiben Sie ein "Modder-Handbuch", in dem genau aufgeführt ist, über welche modifizierbaren Methoden jedes Objekt verfügt, welche Parameter sie annehmen, was sie zurückgeben sollen usw. usw.

Viel Glück!

Eine einfache Möglichkeit, grundlegende Unterstützung dafür zu erhalten, besteht darin, die meisten numerischen Werte in eine oder mehrere separate Textdateien zu unterteilen, damit interessierte Personen sie in Vergessenheit geraten können.

Sie haben beispielsweise Tischspiele erwähnt. Wenn Sie ein Spiel hatten, das auf D & D basiert, könnten Sie eine weapon_damageDatei haben, die Linien wie enthält Battleaxe: 1d12. Ihr Dienstprogrammcode liest diese Datei und fügt sie hinzu, wenn BattleaxeIhr Code Schaden anrichtet generate a number from 1-12, 1 time(s). Wenn Sie die Zeile zum Lesen anpassen, werden Battleaxe: 4d6diese stattdessen generate a number from 1-6, 4 time(s)hinzugefügt. In ähnlicher Weise könnten Sie einen Ordner haben Creaturesund in Ihrem Inneren eine Datei für jede Kreatur, einschließlich Zeilen wie AC: 12; Wenn Sie diesem Ordner dann neue Dateien hinzufügen, werden neue Kreaturen erstellt. Es könnte sogar für Charakterklassen, Geländetypen und eine Menge Dinge gemacht werden.

Diese Art der nicht-Code-Anpassung kann immer noch sehr leistungsfähig sein und viele Teile Ihres Spiels abdecken. Auf diese Weise kann ein Benutzer jedoch keine Änderungen vornehmen, die Sie nicht explizit angegeben haben. Sie können beispielsweise aktivieren Sneak Attack: [damage], dass Sie einer beliebigen Kreatur oder Klasse zugewiesen werden [damage], um sie zu einem Angriff hinzuzufügen , der die Bedingungen für einen Sneak Attack erfüllt. Sie könnten sogar Möglichkeiten bereitstellen, um die Bedingungen zu ändern, z. B. "wann immer Sie aus dem Verborgenen angreifen" oder "wann immer Sie flankieren" oder "wann immer Sie einen Vorteil haben". Wenn ein Benutzer jedoch entscheidet, dass er Sneak Attacks ausführen möchte, können Sie beim Ausführen eines Angriffswurfs auch Stealth-Attacken gegen die Wahrnehmung des Ziels ausführen. Wenn beide Würfe erfolgreich sind, fügen Sie den Sneak Attack-Schaden hinzu.

Wenn Sie möchten, dass ein Benutzer dem Spiel ein völlig neues Verhalten hinzufügt, ohne dass er die gleichen Programmierkenntnisse wie der Entwickler benötigt, dann möchten Sie, wie bereits erwähnt, im Wesentlichen entweder eine Game Engine oder eine separate Programmiersprache erstellen. Für Änderungen, für die keine Codierungskenntnisse erforderlich sind, bieten textbasierte Datendateien und Ordnerstrukturen noch viele Optionen. Wenn Sie möchten, dass Benutzer mehr als das ändern, müssen Sie sie bitten, eine Programmiersprache zu lernen oder zu kennen.

[Ich bin ein jahrzehntelanger Softwareentwickler, habe aber keine Erfahrung in der Spieleentwicklung. Vielleicht geht die Spieleindustrie aus guten Gründen anders vor ...]

Ihr Ansatz ist absolut sinnvoll für mich. Der Kern enthält die grundlegenden Funktionen, auf denen Mechanik und Regeln aufbauen, sodass es sich um eine API handelt, die von den übergeordneten Komponenten verwendet werden soll.

Und beim Entwerfen einer API ist es meine Lieblingsrichtlinie, die Sprache zu erstellen, in der Sie Ihren Code auf höherer Ebene ausdrücken möchten (natürlich unter Berücksichtigung der Syntaxbeschränkungen Ihrer Programmiersprache).

Ein guter Ansatz wäre es, einige hypothetische Regeln und Mechanismen so zu schreiben, wie Sie es möchten (natürlich mit Pythons Syntax), um herauszufinden, was die Kern-API für die Regeln und Mechanismen bereitstellen soll Lagen.

Und natürlich würde ich empfehlen, sich die Skriptfunktionen bestehender Spiele anzuschauen, um eine Vorstellung davon zu bekommen, was sie tun.