ゲームエンジン：スクリプティングサポートを実装するための適切なアーキテクチャ上の方法？

単純なゲームエンジン（C＃で、重要な場合）を開発していますが、アーキテクチャの観点からスクリプトを実装するのに十分な方法は考えられません。

これは、戦闘用のロジックに依存しないカスタムアニメーションを使用したシンプルなターンベースの戦略です。これには、システム/低レベルのもの用のグローバルアーキテクチャレイヤーがあり、最も重要なのは、イベントマネージャーを使用して通信する2つの主要なモジュール（ロジックとゲームビューのもの）です。

そして事は、スクリプトがゲームロジックに関連するもの（ユニットパラメーターの変更など）とゲームビューに関連するものの両方に影響を与えたいと思うことです。特定のスクリプトトリガー。

（正直なところ、理想的には、スクリプトでゲームフローを制御し、コアメカニックス/グラフィックスのみをロジック/ビューに任せたいのですが、私はこれが初めてなので、今すぐにできるかどうかわかりません）

私は3つのオプションを考えてきました：

• スクリプトをロジックで実行するだけで、ゲームのグラフィカルな側面を知らせます。しかし、これによりロジック/ビューの区分が非常に曖昧になりますよね...

• スクリプトを、同じイベントマネージャーを使用して他のユーザーとイベントを交換する別のモジュールにします。しかし、これにはイベントの同期に非常に注意する必要があると思います...そして、マネージャーに膨大な種類のイベントを追加します。（それでも個人的なお気に入り）

• 何よりもスクリプトをモジュールにして、ロジック/ビューの機能に直接影響を与える/呼び出すことができるようにします。これにより、イベント交換スキーム全体を台無しにして、スクリプトが実際にそうすべきではない場合でも物事を壊すことを恐れて、本質的に幅広い機能が可能になります。

したがって、これらのいずれかを決定することも、スクリプトモジュールを挿入するためのより良い方法を考えることもできません...提案や有用なリンクはありますか？

ありがとうございました！

質問を移行してくれてありがとう、gamedevに特化したセクションがあることを知りませんでした

3番目のオプションが必要だと思いますが、論理的なイベントが2つの場所で発生する可能性があることは悪いことだと考えていることに気付くでしょう。エンジンのロジックモジュールを、「今何をすればいいですか？」という2つの質問をする更新ティックにしたいことがわかります。そして「どうすればいいの？」これらの質問への回答を処理するためにスクリプトをバインドできます。

これと、必要なロジックコンポーネントにアクセスするためのデータとAPIを含むオブジェクトの公開とを組み合わせます（つまり、AIパスの検出をスクリプト化できますが、それは使用および再利用される可能性が高い一般的なコードなので、それをモジュールに埋め込み、スクリプト言語に公開されているAPIに追加しますか？）。これにより、アクセシビリティと、物事が発生している場所を明確に定義することができます。

繰り返しますが、私はこれを私がいつもしているのと同じ声明で警告します。完成した製品は、プログラミングの優れた理論よりも常に価値があります:)

お役に立てれば！

多くの人は、このような柔軟性には速度が犠牲になると考える動的言語の強力さを過小評価する傾向があります。これは事実ですが、多くの場合、コストはごくわずかです。

個人的には、表現力を活用した動的言語を使用して可能な限り開発する傾向があり、最適化が必要な場合と必要な場合を理解するためにプロトタイプをプロファイリングします。

あなたの場合、これは、スクリプト言語としても使用できる適切な動的言語を使用して「より高い」部分を開発する、3番目のオプションに向かって移動することを試みることを意味します。

ダイナミズムを適切な深さに配置した後、多くのパターンを使用できます。カスタムスクリプトは、コールバックシステムとしてイベントベースのシステムに統合できます。コアがコールバックすると、適切な環境が提供され、スクリプトがグローバルステータスまたはシステム全体のサブセットの状態のみを変更できます。

Façadeパターンを使用して、スクリプトが対話できるインターフェースをカプセル化できます。ファサードの方法では、ロジックを置くことができることを定義する方法、とき、場合、スクリプトは機能を使用し、コア実装からスクリプトの相互作用を抽象化することができます。

スクリプトは、関連するファクトリメソッドを提供して、スクリプトが要素を直接インスタンス化せずに生成できるようにする必要があります。これらのインスタンスは実際のオブジェクトのラッパーになるため、アクセス制御ロジックをさらに実装できます。

スクリプトオブジェクトは、データを提供する他のオブジェクトにアクセスする必要があります。これらの他のオブジェクトをスクリプトオブジェクトに直接渡さないように注意してください。そうすると、脆弱なインターフェースが作成されます。これらのオブジェクト参照を管理し、スクリプトオブジェクトへのデータアクセスを提供するメディエータークラスのようなものが必要になる場合があります。

Luaは、汎用スクリプト言語の一般的な選択肢です。LexとYaccを使用して独自のスクリプト言語を作成できます（Game Programming Gems 3の記事を参照）が、大小に関係なくLuaで大部分のニーズに対応できると思います。