エンティティ構成をスクリプトの外に配置するのはなぜですか？

スクリプトファイルでエンティティコンポーネントを定義する多くのゲームを見てきましたが、各エンティティを構成し、そのエンティティが持つコンポーネントを指定するとき、他のファイル形式（XMLなど）を使用します。なぜ彼らはそれをするのですか？

私は主に他の人の根拠がこれについて何であったかを確認するように求めています。私はまた、（私はXML JSONを選択しなかったが）外のスクリプトの私のエンティティを設定します。これを行う理由は、セーブゲームを簡単に実装できるようにするためです。また、この種の構成はXMLやJSONのようなものに整理するほうがよいと思うからです。

@ クリストファーラーセンの答え： コメントとして投稿するには長すぎる

質問の主題から少し逸脱しているのではないかと思います。あなたが説明している問題は、階層ベースのエンティティにより関連しています。私の質問では、コンポーネントベースのエンティティについて話していることを述べました。

これが私が聞きたかった例です。以下は、エンティティを構成する2つの代替方法です。スクリプトを使用する方法と外部JSONファイルを使用する方法です。私の質問は、なぜ多くの人がスクリプトの外でエンティティを構成することを好むのかということでした。

基本エンティティクラス：

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

スクリプトのアプローチ：

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

JSONアプローチ：

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

このアプローチを使用する理由は既に述べましたが、これは技術的で組織的なものです。なぜこれほど多くの他の人（私が見たものから）がこれを使用するのか知りたいと思いました。

私の頭に浮かぶ主な利点は、プログラマー以外の人がゲームスクリプトに触れなくても構成を編集/管理できることです。

通常、スクリプトではなく構成ファイルを使用する理由の1つは次のとおりです。

すべての値を指定するなど、スクリプトが正しいかどうかを確認する唯一の方法は、スクリプトを実行することです。

スクリプトで値を構成できるようにコードを作成するということは、スクリプトが値を入力するためのスケルトンオブジェクトを作成するコードを作成し、スクリプトがそうしたことなどを検証することを意味します。多くの場合、ある種の検証メカニズムをサポートするライブラリを使用して、フラットな構成ファイルからロードするよりもコードとバグの多いコードです。

エンティティ構成は、特定のエンティティの単純なシリアライゼーションにすることができます。これにより、ゲームの編集および改造ツールの出力を、セーブゲームとほぼ同じように処理できます。特に、ゲームの保存中に特定のエンティティがどの状態になるかを予測できないゲームの場合-たとえば、AIや最初から部分的に手続き的に生成されているため-全体をダンプできると便利です保存するバイトストリームとして、エンティティが「何をするか」ではなく「何をするか」を定義するデータ。

説明するパターンは、データ駆動型システムの実装です。

データ駆動型システムは、コンテンツの定義をソースの外部でカプセル化できるため、ゲーム開発で一般的に使用されます。次に、この外部表現を簡単に変更して（さらに、変更を監視するアプリケーションによってリアルタイムで更新して）、エンティティの動作方法を変更できます。

データが外部で定義されると、テキストファイルを直接編集する（ハァッ！）から、デザイナーの選択を論理的で一貫性があり正確性を検証する（さらにゲームバランスの観点）マナー。

データがコードに直接埋め込まれている場合、変更を行うとアプリケーションの再構築が必要になります。これは、大規模プロジェクトの場合、適度に時間がかかり、バイナリの展開に必要な時間もかかります（たとえば、新しいバイナリをに展開してインストールする必要があります）サーバ）。

典型的な実体「オーク」の例を見てみましょう...

オークの実装方法の1つは、オークのすべての特性とロジックのコードで完全な説明を記述することです。

• maxhealth = 10
• ダメージ=毎秒3ダメージ
• runaway = true
• runawaywhen = health <10
• aggressive = true

オークをインスタンス化するとき、それらの値はすべてまったく同じように初期化されます（またはおそらく静的です）。発生する問題は、一部のデザイナーがやって来て、「初心者エリアには別のタイプのオークが必要であり、健康が低く、暴走せず、攻撃的ではないということです。これにより、新しいプレーヤーは、戦闘システムを学びながら、難易度と混乱を増加させました。」

これで、別のクラスが必要になるか、（たぶん前向きでした）「初心者」領域にオークを作成するときにオークを作成する「ファクトリ」にフィードする値を調整します。そこで、変更を加え、新しいバイナリをデプロイします。プレイテスターが戻ってきて、1回のヒットでオークを殺すため、新しいヘルス値が低すぎると言ってもらうだけです。

システムがデータ駆動型であった場合（および変更が行われたときに再読み込みをサポートするアプリケーションのボーナスポイント）、デザイナーとプレイテスターを満足させるために必要な変更は単純なデータ変更であり、再コンパイルや展開は必要ありません。これにより、コードの変更を待たずに済むためデザイナーは満足し、値を微調整するためにソースコードを常に変更しているため、プログラマーも満足します。

データ駆動型システムを極端にすることで、ゲームレベル、呪文、クエストなどすべてを、コードの変更をまったく必要としないデータの簡単な変更で実装できます。結局のところ、それはゲームコンテンツの作成、調整、反復を簡単にすることです。

あなたの例では、実際にはすでに2つのスクリプト言語を使用しています。これは、長い目で見ればうまくいく方法ですが、使用しているスクリプト言語を統一することをお勧めします。あなたが与えたスクリプトの例がJsonではなくLuaで行われた場合、私はLuaのテーブルを使用してオブジェクトを構築します。構文は実際には似ており、コンポーネントを公開するための1つのインターフェースをサポートできます。

なぜ人々が通常XMLでそれを行い、それからロジックでスクリプトを書くのを選ぶのかという理由に触れると、これはあなたがそれを言うときに意味をなすということです。これがデータ内のオブジェクトの私の定義です。適切なデータストレージ形式は何ですか。ほとんどの場合XMLです（ただし、JSONも使用します;）。そして、ロジックを追加したい場合は、それをコード化するか、スクリプトファイルに入れます。

それは間違った考えではありませんが、私の目には人々は次のステップに進んでいません。完全な言語であるc / c ++ / c＃を見てください。オブジェクトとそのロジックをすべて1つの言語で定義できます。スクリプトインターフェースでも同じようにしてください。XMLでクラスを定義し、メソッドをc＃で定義する必要があると考えるのとほとんど同じです。たぶん、古いゲームスクリプト言語は十分に強力ではなかったし、それはまだそれが行われた方法を保持しているだけです。