ゲームの仕組み/ルールをメインコードとは別に実装する価値はありますか？

このコミュニティの範囲に適合するかどうか、またはStackoverflowに代わりに行くべきかどうかはわかりません。

ゲームをそのコアで簡単に拡張できるようにしたいとします。つまり、多くの人々が、ある程度のプログラミング知識がなくても、既存のルールを微調整できるだけでなく、まったく新しいゲームメカニクスを追加できるようにしたいとします。私はプログラマーとしては上手ではありませんが、学ぶ準備はできています。いくつかの指示とそれができることを保証する必要があります。

私が考えたのは、メインのユーティリティコードとは別にゲームメカニクスを何らかの方法で実装することが可能かどうかです。つまり、卓上ゲームには、すべてのアクションの実際のアルゴリズムが含まれていないルールブックがありますが、いくつかのプロトコルと制限を記述し、各アイテムのコンテキストを大きく参照しています。PCゲームでも同様のことを行うことができます。たとえば、すべてのルールを人間のプログラミング言語で非常に高レベルで読みやすい（および変更可能な）で記述します。ゲームの仕組みの実例？

それは本当に自分の言語とそのためのコンパイラを書く必要があるように思えます））もちろんこれはできません。しかし、問題へのより簡単なアプローチがあるかもしれませんか？

参考までに、ユーティリティコードの選択言語はPython 3.xになります

一般的に、システムを拡張できる容易さは、そのサブシステムが密結合または疎結合の程度に依存します。通常、サブシステムは疎結合であるほど、分離されているため、システム全体を完全に理解する必要がないため、サブシステムを簡単に変更できます。

しかし、何も無料ではありません-そのようなシステムは通常、構築するためにより多くのリソース（時間、お金、スキルのさまざまな組み合わせ）を必要とします。あなたが説明した拡張性の程度は、私があなたに帰したスキルのレベルと直接対立しているように思います。それはできますが、あなたが説明したようにソフトウェアを作成することは非常に難しい仕事です。

私が知っている最も近い既存のものはVassal（あなたが説明したよりもはるかにプログラム的です）、またはTabletop Simulatorのmodを作成します（これは主にゲームルールを解釈および実施するために人間の相互作用に依存します）。

私が考えたのは、メインのユーティリティコードとは別にゲームメカニクスを何らかの方法で実装することが可能かどうかです。

絶対に可能です。ゲームでよく使用される1つの方法は、Luaスクリプトです。

リンクされた記事から：

Luaは当初、1993年にソフトウェアアプリケーションを拡張するための言語として設計され、当時のカスタマイズに対する需要の高まりに対応していました。

多くのゲームでLuaが使用されています。（リンクしますが、新規ユーザーの評判によりリンク数が制限されます。）

Luaスクリプトは実行時にコンパイルできます。これは、たとえば、ゲームの「scripts」ディレクトリにあるテキストファイルであり、modderで簡単に編集できることを意味します。ゲームはそれらをロードして実行します。

Luaスクリプトがゲーム内ユニットのプロパティを定義するのを見てきました。ここで TA春からランダムに一例です。

しかし、「すべてのルールを説明する」必要があります。Luaは完全な言語であるため、理論的には可能ですが、問題は、コアゲームコードがその動作を拡張するスクリプトを探すように十分に予知しなければならないことです。

例えば、「scripts / cards」ディレクトリでカードを探すことを知っているカードゲームを開発するかもしれません。新しいカードの追加や既存のカードの編集に最適です。ただし、後でゲームを拡張してグリッド上のミニチュアを含める場合は、コアコードを編集する必要があります。

注：ゲームとカスタマイズ用ソフトウェアの両方で一般的に使用されていることを知っているため、Luaを表示します。私はそれが唯一の解決策であることも、質問者のニーズに最適であることも示唆していません。

一連のアプローチがあり、そのうちの特定の1つが価値があるかどうかは、あなたが何をしようとしているかによって異なります。具体的には、微調整をどの程度制御したいですか？

制御の極限では、ゲーム全体のコードを微調整者に変更させることができます。その時点で、基本的にユーティリティコードとその使用方法の少なくとも1つの例を公開します。調整者は、必要なだけコードを使用できます。

少し制御が少ないアプローチは、何らかの方法でユーティリティコードを「フリーズ」し（事前にコンパイルするなど）、微調整者に特定の機能（コールバック）のみを入力させ、実行できることを制限します。目的に応じて、このアプローチは多くの形式をとることができます。一般的な方法は、すべての表示部分をユーティリティ/メインコードに配置し、すべてのメカニズムを調整可能な部分に配置することです。または、プレイヤーがそれらを変更したくない、またはそれらを変更可能にするのが複雑すぎるため、「凍結」部分にいくつかのメカニズムを保持したい場合があります。

連続体の低制御側では、調整器に固定範囲内の値を変更させるだけです。ゲーム内の物の色を選択できるデータファイルは一例です。ただし、このアプローチを使用しても、多くのカスタマイズを提供できます。選択した関数を定義し、調整者がそれらを構成して以前のアプローチからのコールバックを作成できるようにすることはできますが、新しい関数を定義することはできません。または、構成部分をスキップして、有限の選択を提供するだけかもしれません。

これらすべてのアプローチの詳細とユースケースに適合するアプローチは、どの種類のベースゲームを作りたいか、どの程度のコントロールをあきらめたいかによって異なります。市販のゲームでは一般的に2番目と3番目の方法しか使用されないことに注意してください。これらのアプローチは連続体を形成するため、2番目のアプローチでもこれらの問題が発生する可能性があることに注意してください。

システムのルールを、それらのルールを適用するコードから分離することは絶対に可能です。基礎となるシステムにバグを導入することなく、新しいルールを追加したり、後でルールを変更したりするのが容易になるため、複雑なプロジェクトではコードをそのように構成することを好みます。また、ルールエンジンのバグは、同じルールエンジンがすべてのルールで何度も使用されるため、ルールと他のコードが混じり合っているシステムのバグよりも早く発見されます。

価値があるかどうかは、システムの複雑さに依存します。パックマンに迷惑をかけないように、ドワーフ要塞を他の方法で書くことは想像できませんでした。

それは間違いなく実行可能です。それが価値がある場合、それはあなたの目標に依存します。

この作業を行うために、独自の言語を発明したり、コンパイラを作成する必要はありません。

ゲームを簡単に拡張できるようにしたい場合は、おそらくそれをお勧めします。

少なくとも短期的には、理解可能なシステムを作成し、物事を簡単に変更できるようにすることは、おそらくあなたにとってより多くの作業です。

これを行うゲームの1つはRimworld（私は所属していません）であり、基本的にはゲームフォルダーにあるXMLファイルに多くのゲームデータとメカニズムを入れて、誰でも見ることができ、変更します。ゲームのコア/エンジンはUnityを使用して作成されました。

実際のコーディングによってゲームをさらに/より深く拡張する可能性もありますが、それについてはあまり知りませんが、modsフォーラムを見て学ぶことができます。

改造の可能性は、多くの人々にとってゲームをより面白くし、成功に大きく貢献したと思います。また、開発者は、必要なMODコンテンツをコアゲームに取り込むことができ、多くの人々から支援を受けて開発をスピードアップし、ゲームを改善し、それに基づいて物事を取り入れることができます人気のあるもの、機能していると思われるものなど

そしてもちろん、特に小規模な独立系スタジオでは、何百人もの人々がアイデアを考え出し、それらのためにテストしています。

オブジェクト指向設計を検討することをお勧めします。Pythonはそれをうまくサポートしています。

厚い本は、これについて書かれており、あなたが新しいときに怖いかもしれませんが、主な原則はかなり簡単です。

主なポイントは、作業しているオブジェクトの種類を特定することです。どのようなゲームを考えているのかはわかりませんが、プレーヤー、モンスター、アイテム、装備、武器、鎧などは典型的なオブジェクトです。

さまざまな種類のゲームが必要な場合、おそらく勝利条件などを処理するGameオブジェクトが必要になります。おそらくMapオブジェクトもですか？

何かがオブジェクトに値するかどうか、例えば損傷などが明確でない場合があります。オブジェクトに損傷を与えない場合、コードは単純になりますが、オブジェクトにすると、カスタマイズが容易になります。

サブクラス化：武器と装甲はどちらも装備です。機器はアイテムです。おそらく他の種類のアイテムがあります。おそらく、プレイヤーとモンスターの両方がサブクラスである戦闘員を定義することは有用でしょう。

たとえば、武器には、他のすべての種類のアイテムと多くの共通点があり、重量、サイズ、その他のプロパティがあります。

したがって、サブクラス化は、「武器は他のアイテムと似ていますが、さらに武器を使用したり、ダメージに影響を与えたりするなど」という方法を提供します。

また、サブクラス化により、MODビルダーは「私の新しいタイプの武器は、それ以外は標準の武器とまったく同じです」と言うことができます。

次に、どのオブジェクトが何を担当するかを決定する必要があります。これは見かけほど簡単ではないので、考えてみてください。間違った選択をしても、基本的なゲームにはあまり影響しませんが、カスタマイズが難しくなります。

あなたが自分でいじくり回している限り、あなたは周りのものを変えることができますが、あなたが何かを一般に公開する瞬間、変更を加えることはずっと難しくなります！人々は、今のように物事に依存するMODを作成します。バグも。人々は、コードに残っているバグに依存するmodを作成します。物事を変更すると、これらのMODが破損し、リンチモブが家に現れます。

例えば：

武器を振るうプレイヤーが複数の鎧を着たモンスターを攻撃します。これは、特定のゲームモードおよび特定のマップで行われます。

どちらの戦闘員も、クリティカルヒットやダッジなどのスキルを持っている場合があります。

さて、どのオブジェクトが何を担当していますか？

これに対する正しい答えはありません。許可するカスタマイズの種類に大きく依存します。

オブジェクト（Mapなど）を呼び出さない場合、そのオブジェクトは攻撃を変更できません。

これらすべての決定を行った後、それらを文書化します。各オブジェクトに含まれるmoddableメソッド、それらが取るパラメーター、返すべきものなどを正確にリストした「Moddersマニュアル」を作成します。

がんばろう！

これに対するいくつかの基本的なサポートを取得する簡単な方法は、ほとんどの数値を1つまたは複数の個別のテキストファイルに分割して、関心のある個人がそれらを忘却に調整できるようにすることです。

たとえば、あなたは卓上ゲームに言及しました。D＆Dに基づいたゲームがある場合、次のweapon_damageような行を含むファイルがあるかもしれませんBattleaxe: 1d12。ユーティリティコードはそのファイルを読み取りBattleaxe、コードによって損害が与えられるたびgenerate a number from 1-12, 1 time(s)にそれらを追加します。Battleaxe: 4d6代わりに、行を調整して読み取りgenerate a number from 1-6, 4 time(s)、追加します。同様に、フォルダーを作成しCreatures、内部に各クリーチャーのファイルを作成できますAC: 12。そのフォルダに新しいファイルを追加すると、新しいクリーチャーが作成されます。キャラクタークラス、地形タイプ、たくさんの物に対しても可能です。

このスタイルの非コードカスタマイズは、非常に強力であり、ゲームの多くの部分をカバーできます。ただし、明示的に指定しなかった変更をユーザーが実際に行うことはできません。たとえば、Sneak Attack: [damage]クリーチャーまたはクラスに付与し[damage]て、スニーク攻撃の条件を満たす攻撃に追加できるようにすることができます。「ステルスから攻撃するとき」、「側面攻撃をするとき」、「有利になるとき」など、条件が何であるかを変更する方法を提供することもできます。ただし、ユーザーがスニーク攻撃を行うことを決定した場合、「攻撃ロールを行うとき、ターゲットの知覚に対してステルスをロールすることもできます。両方のロールが成功した場合、スニーク攻撃ダメージを追加します」

ユーザーが開発者と同じレベルのコーディングスキルを必要とせずにゲームにまったく新しい動作を追加できるようにしたい場合、人々が言っ​​たように、本質的にゲームエンジンまたは別のプログラミング言語のいずれかを作成することを検討しています。コーディングの知識を必要としない変更の場合、テキストベースのデータファイルとフォルダー構造には、まだ多くのオプションがあります。ユーザーがそれ以上の変更を行うようにしたい場合は、プログラミング言語を学ぶか知るように依頼する必要があります。

[私は数十年のソフトウェア開発者ですが、ゲーム開発の経験がないため、ゲーム業界はさまざまなアプローチを取っているかもしれません。

あなたのアプローチは私にとって絶対に理にかなっています。コアは、メカニズムとルールが構築する基本的な機能を提供するため、上位レベルのコンポーネントで使用されるAPIです。

そして、APIを設計するとき、私のお気に入りのガイドラインは、より高いレベルのコードを表現したい言語を作成することです（もちろん、プログラミング言語の構文上の制限はありません）。

したがって、良いアプローチは、いくつかの仮説的なルールとメカニックを表現したい方法で（もちろんPythonの構文を使用して）書き、コアAPIがルールとメカニックに提供するものを見つけることです層。

そしてもちろん、既存のゲームのスクリプト機能を見て、それらが何をするのかを理解することをお勧めします。