ゲームでの標準化された構文の使用法：はいまたはいいえ

TL; DR： Civスタイルのターンベースの戦略ゲームでルールセットを定義する際の要素としてCSSを使用する：狂気か、それとも単なる狂気か？

本当の質問：

ルールセット解析ルールの設計は面倒です。そこにあるすべてのゲームは、ルールセットの解析方法について独自のルールセットを定義しているようです（もちろん、ゲームにはカスタマイズ可能なルールセットが備わっているため）。

ゲーム開発者の時間です。ルールセットの標準化されたsynatxを採用するコミュニティ？

CSSはカスタマイズ可能なゲームの実行可能なオプションですか？

例：カスタマイズ可能なルールセットを持つCivのようなものを考えます。次のようにルールセットを設計できないとしたらどんなにいいでしょう。

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

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

マイケル・スタムがXMLを維持し、独自のCSSのようなパーサーを作成しないようにするという提案に同意します。かっこいい既存のCSS解析ライブラリを見つけることができれば、それ以外の場合はKISS。

次に、XMLでの例を示します。

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

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

違いすぎないでしょ？そして、多数のXML解析ライブラリの1つがあるので、そのようなファイルをロードするのは簡単なことです。

個人的には、ルールセットやその他の設定ファイルにもXMLを使用します。

YAMLやJSONのような他のいくつかの選択肢があります。これらは通常、XMLファイルよりもファイルサイズが小さく（問題がある場合）、これらのファイルを読み取るための堅牢なパーサーがそこにあります。それがあなたにとって重要であるなら、それらの構文はCSSに近いです:-)

あなたの言語はCSSのように見えますが、そうではありません。それはあなた自身のドメイン固有言語です。

自問してみてください：パーサーを作成する必要がある独自のファイル形式を本当に作成しますか？このパーサーは、高速で堅牢である必要があります。また、ファイル形式を文書化し、それがどのように機能するかを人々に教える必要があります-結局のところ、それはカスタマイズされた言語です。次に、思いもよらなかった問題が発生する可能性があることに注意する必要があります-おそらく誰かが50 MBのファイルを作成するとパーサーがクラッシュし、savegameが破損するなど、素晴らしいアイデアだと思ったかもしれません。または、破壊的な構文変更でのみ実装できる機能を追加する必要があると判断し、既存のすべてのファイルを破壊します。

XMLのようなフォーマットが非常に人気があるのは、XMLがこれらの問題を解決したためです。堅牢で高速でリークのないことが証明されている多くの優れたXMLパーサーを見つけることができます。また、多くの人々はXMLファイルとその編集方法を知っています。これは非常に一般的ですが明確に定義された構文であるため、後で拡張できることを確信できます。

あなたの動機は、手作業で簡単に編集できるようで、これはコミュニティSDKで一般的です。今、人々がそれらのファイルを手で編集する理由は、彼らがゲーム開発者が使用するツールを持っていないからです。数年間ゲームを開発している会社には、そのようなファイルを編集するためのグラフィカルツールがいくつかあると想定できます。これらは優れたバグのないものかもしれませんが、あなたや開発者がファイルを手動で編集することはめったにありません。これらのツールが「Modding SDK」でリリースされることはほとんどないため、ほとんどのモダーは手動で編集します。

したがって、私の最初の反応は次のとおりです。手作業で簡単に編集できる、証明されていない新しいフォーマットの開発に時間を費やす代わりに、戦いで実績のあるフォーマットを使用して、編集を容易にするツールを作成することに時間を費やしたいと思います。

しかし、包括的ステートメントはそのようには機能しません。それは常に依存します。かなりの開発チームで大きなゲームを3年以上書いている場合、システムの開発、テスト、微調整に多くの時間を費やすことができます。解析するファイルが15000ある場合、メモリ使用量を削減する方法を見つけることが重要になります。

しかし、中小規模のゲームでは、XMLのようなよくサポートされている既知のフォーマットと、それを編集するための素晴らしいツールを使用します。

あなたが提案しているのは標準的な構文ではありません。これは標準的な構文のように見えますが、実際にはCSSではなく、CSSモデルは、実行しようとしているものに適合しません。構文は構造を選択するのに適していますが、それらを記述することはできません。

XMLをねじ込みます。これは冗長で、騒がしく、解析が面倒で、多くのトリッキーなエッジケースがあり、検証の主張については、誰も実際にはそうしません。YAMLをお勧めします。これは標準のデータ記述形式であり、実用的なプログラミング言語で利用できる解析ライブラリを備えています。

YAMLでのコードは次のようになります-最初は型なしのバリアントとして、次に、知識が豊富で実際に作業を行うことができない人のためにオプションの型タグを付けます。

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

2番目の形式は最低です。実際には、範囲とスプライトなど、必要なキーがある限り、誰かが！Eraや！Period、または単純な型なし辞書をそこに置いても、実際には気にしません。これはプログラミング言語でのダックタイピングに似ており、物事をより読みやすくします。必要なキーがない場合は、スキーマがなくてもロード時に簡単に検出できます。とにかくコードが必要なので、どれが素晴らしいのでしょうか。（また、アプリケーションがURIを解決する方法を知っている限り、すでに行ったように、誰かが誤ってURLを呼び出して、愚かな理由で検証に失敗するリスクを負うことはありません。）

データファイルの解析可能な説明が本当に必要な場合（たとえば、エディターのプロパティシートを自動的に生成し、エンジンが受け入れられないのと同じコードベースでそれを行う必要がある場合）、Kwalifyスキーマなどを使用できます。

私はあなたの提案を理解していますが、正確で標準的な構文に準拠した、ゲームルール用の外部ドメイン固有言語（DSL）の作成について話しています。

ゲームルールセット用のDSLを構築した私の経験と、DSLに関するMartin Fowlerの最近の本を読んだことから、あなたのアイデアのようなものを構築するには2つの主要な部分が必要であることがわかります。

• DSLが表すもののセマンティックモデル（またはビジネスモデル）。OOPを行う場合、それは、時代、範囲、強度などの属性を持つ単位を保持するクラスになります（まだOOPは必須ではありません）。
• 選択した構文を使用するテキストファイルからそのモデルを生成するパーサー。

より大きな労力は実際にはパーサーではなくモデルの構築にあると思いますが、標準の構文を選択すると、パーサーの構築がはるかに速く簡単になります。さらに、構文が単純で、ルールを作成する人に知られている場合は、その方がはるかに簡単です。

したがって、はい、必ず、ルールセットのリッチビジネスモデルを構築し、標準の構文を使用してそれらを記述します。実際、XMLはゲームや他の場所で非常に頻繁に使用されていますが、一般的に冗長すぎると考えられており、JsonやYamlなどのよりスリムな形式（そしてなぜCSSではない）に置き換えられることが増えています。

それがあなたのアイデアを別の光に変えるのに役立つことを願っています。

それが本当にCSS構文であるかどうかはわかりません。したがって、これはCSS自体よりも「$ selector {$ rules;}」形式に近いものです。私の直感的な反応は、CSSの「カスケード」部分は、操作が非常に複雑になり、その時点ではコードのように見えすぎるということです。