Verwendung standardisierter Syntaxen beim Spielen: ja oder nein?

TL; DR: Verwenden von CSS als Element bei der Definition von Regelsätzen in rundenbasierten Strategiespielen im Civ-Stil: Wahnsinn oder einfach nur alter Wahnsinn?

Echte Frage:

Das Entwerfen von Regeln zum Analysieren von Regelsätzen ist ein Problem. Jedes einzelne Spiel scheint einen eigenen Regelsatz zu definieren, wie Regelsätze analysiert werden sollen (sofern das Spiel natürlich anpassbare Regelsätze enthält).

Ist es Zeit für den Spielentwickler? Community standardisierte Synatxe für Regelsätze zu akzeptieren?

Ist CSS eine praktikable Option für anpassbare Spiele?

Beispiel: Betrachten Sie eine Civ-ähnliche mit anpassbaren Regelsätzen. Wie schön wäre es nicht, Regelsätze wie folgt entwerfen zu können:

artillery:era(modern) {
  range: 2;
  sprite: url(/isophex/artillery.png);
}

artillery:era(classical) {
  range: 1;
  sprite: url(/isophex/cannon.png);
}

Ich stimme dem Vorschlag von Michael Stum zu, XML beizubehalten , um das Schreiben eines eigenen CSS-ähnlichen Parsers zu vermeiden. Wenn Sie eine vorhandene CSS-Parsing-Bibliothek finden, die cool ist, aber ansonsten KISS .

So könnte Ihr Beispiel in XML aussehen:

<artillery era="modern">
    <range>2</range>
    <sprite>/isophex/artillery.png</sprite>
</artillery>

<artillery era="classical">
    <range>1</range>
    <sprite>/isophex/cannon.png</sprite>
</artillery>

Nicht zu unterschiedlich, oder? Und mit einer der vielen XML-Parsing-Bibliotheken da draußen ist es garantiert ein Kinderspiel, eine solche Datei zu laden.

Persönlich würde ich auch XML für Regelsätze oder andere Konfigurationsdateien verwenden.

Es gibt jedoch auch andere Alternativen wie YAML oder JSON . Diese sind normalerweise kleiner als XML-Dateien (wenn dies ein Problem darstellt), und es gibt robuste Parser zum Lesen dieser Dateien. Ihre Syntax ist auch näher an CSS, wenn Ihnen das wichtig ist :-)

Ihre Sprache sieht aus wie CSS, ist es aber nicht. Es ist Ihre eigene domänenspezifische Sprache.

Fragen Sie sich Folgendes: Möchten Sie wirklich ein eigenes Dateiformat erstellen, für das Sie einen Parser schreiben müssen? Dieser Parser muss schnell und robust sein. Sie müssen auch Ihr Dateiformat dokumentieren und den Leuten beibringen, wie es funktioniert - schließlich handelt es sich um eine angepasste Sprache. Sie müssen sich dann darüber im Klaren sein, dass Sie möglicherweise auf Probleme stoßen, an die Sie nie gedacht haben. Vielleicht hat jemand gedacht, dass es eine gute Idee ist, eine 50-MB-Datei zu erstellen, und Ihr Parser stürzt ab und beschädigt ein Spiel oder so. Oder Sie müssen eine Funktion hinzufügen, die nur mit einer Änderung der Syntax implementiert werden kann, wodurch alle vorhandenen Dateien beschädigt werden.

Der Grund, warum Formate wie XML so beliebt sind, liegt darin, dass XML diese Probleme gelöst hat. Sie finden viele großartige XML-Parser, die sich als robust, schnell und leckagefrei erwiesen haben. Außerdem kennen viele Leute XML-Dateien und wissen, wie man sie bearbeitet. Da es sich um eine so allgemeine, aber gut definierte Syntax handelt, können Sie sicher sein, dass Sie sie später erweitern können.

Ihre Motivation scheint die einfache Bearbeitung von Hand zu sein, was in Community-SDKs üblich ist. Der Grund, warum Benutzer diese Dateien von Hand bearbeiten, ist, dass sie nicht über die Tools verfügen, die die Game Devs verwenden. Sie können davon ausgehen, dass ein Unternehmen, das seit mehreren Jahren ein Spiel entwickelt, über einige grafische Tools zum Bearbeiten solcher Dateien verfügt. Diese sind möglicherweise nicht besonders gut und fehlerfrei, aber sie bearbeiten die Dateien für Sie, und Entwickler bearbeiten sie nur selten von Hand, um etwas zu optimieren. Diese Tools werden selten in 'Modding SDKs' veröffentlicht, daher bearbeiten die meisten Modder diese manuell.

Meine erste Reaktion wäre also: Anstatt Zeit damit zu verbringen, ein neues, unbewiesenes Format zu entwickeln, das einfach von Hand zu bearbeiten ist, würde ich lieber ein kampferprobtes Format verwenden und die Zeit damit verbringen, Werkzeuge zu schreiben, die das Bearbeiten vereinfachen.

Aber pauschale Aussagen funktionieren so nicht. Es kommt immer darauf an. Wenn Sie 3 oder mehr Jahre damit verbringen, ein großes Spiel mit einem großen Entwicklerteam zu schreiben, können Sie viel Zeit damit verbringen, Ihr System zu entwickeln, zu testen und zu optimieren. Wenn Sie 15000 Dateien analysieren müssen, ist es wichtig, Möglichkeiten zur Reduzierung der Speichernutzung zu finden.

Aber für kleine / mittlere / Indie-Spiele würde ich ein bekanntes und gut unterstütztes Format wie XML und ein nettes Tool zum Bearbeiten verwenden.

Was Sie vorschlagen, ist keine Standardsyntax. Es sieht aus wie eine Standardsyntax, ist aber nicht wirklich CSS, und das CSS-Modell passt nicht zu dem, was Sie versuchen. Die Syntax ist gut darin, Strukturen auszuwählen, aber nicht zu beschreiben.

Schraube XML. Es ist wortreich, laut, nervig zu analysieren, viele knifflige Randfälle, und trotz all seiner Validierungsansprüche tut das niemand wirklich. Ich schlage YAML vor . Es ist ein Standard-Datenbeschreibungsformat mit Parsing-Bibliotheken, die für jede praktische Programmiersprache verfügbar sind.

So würde Ihr Code in YAML aussehen - zuerst als nackte, nicht typisierte Variante, dann mit optionalen Typ-Tags für Personen, die zu pedantisch sind, um ihre Arbeit tatsächlich zu erledigen.

artillery:
    modern:
        range: 2
        sprite: /isophex/artillery.png
    classical:
        range: 1
        sprite: /isophex/cannon.png

--
artillery:
    !Era modern: !Artillery
        range: 2
        sprite: !URI /isophex/artillery.png
    !Era classical: !Artillery
        range: 1
        sprite: !URI /isophex/cannon.png

Das zweite Format ist scheiße. In der Praxis ist es Ihnen egal, ob jemand eine! Ära oder eine! Periode oder nur ein einfaches, nicht typisiertes Wörterbuch dort ablegt, solange es die gewünschten Schlüssel enthält - Reichweite und Sprite. Es ist analog zum Entenschreiben in Programmiersprachen und macht die Dinge viel lesbarer. Wenn die gewünschten Schlüssel nicht vorhanden sind, können Sie diese beim Laden auch ohne Schema leicht erkennen. Was großartig ist, weil Sie den Code sowieso brauchen. Warum sollten Sie sich also wiederholen? (Solange die Anwendung weiß, wie URIs aufgelöst werden, besteht nicht das Risiko, dass jemand versehentlich URLs aufruft und aus dummen Gründen nicht validiert, wie Sie es bereits getan haben.)

Wenn Sie wirklich eine analysierbare Beschreibung der Datendateien benötigen - beispielsweise möchten Sie automatisch Eigenschaftenblätter für Editoren generieren und dies aus irgendeinem Grund in derselben Codebasis tun, in der Ihre Engine nicht akzeptabel ist -, können Sie so etwas wie Kwalify- Schemas verwenden.

Soweit ich Ihren Vorschlag verstehe, sprechen Sie über die Erstellung einer externen domänenspezifischen Sprache (DSL) für Ihre Spielregeln, die einer präzisen und standardmäßigen Syntax entspricht.

Aufgrund meiner Erfahrung beim Erstellen von DSLs für Spielregeln und meiner Lektüre von Martin Fowlers jüngstem Buch über DSLs habe ich festgestellt , dass zwei Hauptteile erforderlich sind, um so etwas wie Ihre Idee zu erstellen:

• Ein semantisches Modell (oder Geschäftsmodell) für das, was Ihr DSL darstellt. Wenn Sie OOP machen, wäre dies eine Klasse, um die Einheiten mit Attributen wie Ära, Reichweite, Stärke usw. zu halten. (OOP ist jedoch nicht obligatorisch.)
• Ein Parser zum Auffüllen dieses Modells aus Textdateien, die die von Ihnen gewählte Syntax verwenden.

Ich denke, dass der größere Aufwand tatsächlich darin besteht, das Modell und nicht den Parser zu erstellen, aber die Auswahl einer Standardsyntax macht den Parser viel schneller und einfacher zu erstellen. Wenn die Syntax einfach ist und / oder den Leuten, die die Regeln schreiben, bekannt ist, ist es für sie außerdem viel einfacher, dies zu tun.

Erstellen Sie also auf jeden Fall ein umfassendes Geschäftsmodell für Ihre Regelsätze und schreiben Sie diese dann mit einer Standardsyntax. XML wird in der Tat sehr oft in dieser Funktion in Spielen und anderswo verwendet, aber es wird allgemein als zu ausführlich angesehen und zunehmend durch schlankere Formate wie Json oder Yaml (und warum nicht CSS) ersetzt.

Ich hoffe, das hilft, Ihre Idee in ein anderes Licht zu rücken.

Ich bin mir nicht sicher, ob das wirklich CSS-Syntax ist, daher ist dies eher das Format "$ selector {$ rules;}" als CSS selbst. Meine Bauchreaktion ist, dass der "kaskadierende" Teil von CSS zu kompliziert wird und zu diesem Zeitpunkt zu sehr nach Code aussieht.