MMOクエストの仕組みを実装するためのヒントは？

以下にリストされている要件を満たしたクエストの仕組みを実装するには、どのツール、パターン、またはベストプラクティスをお勧めしますか

ソフトウェアアーキテクチャ（一般的な方法）とオブジェクトワイヤリング、イベントサブスクリプション、および条件の表現の選択肢について説明しています。使用に成功したツール/ライブラリについて言及してください。 編集：スクリプトを使用している場合、どのような設定をお勧めしますか？

要件：

シンプルな2D mmo（rpg）
クエストを含むすべてのゲームデータは、リレーショナルデータベースに保存されます
ゲーム内のイベントは、プレイヤーの新しいクエストまたは既存のクエストの前進を引き起こす可能性があります
クエストは、プレイヤーがクエストを利用できるようになる前に満たさなければならない任意の数の条件を持つことができます
クエストは、任意の条件を持つ任意の数のサブクエスト/ステップで構成できます
クエストはシンプルから

Aと話す-5人を殺すB-Aと話す-永久に健康を増進する
非常に関与する：

エリアXのアイテムを使用-エリアYに移動-ボットが出現します-10％以上のダメージを与えることなくボットを殺します-ボットがアイテムをドロップします-アイテムを受け取ります-ポータルのロックを解除します-ポータルの背後のJにアイテムを配信します-ゴールドと経験を受け取ります-もう一度ポータルを渡すことができます-このプレイヤーのポータルをロックします
レベルインスタンスは可能性があります（プレーヤーはチームまたは特定のクエストを完了することができ、それらの参加者だけにレベルの場所をスポーンします）
クエストは、できればスクリプトやプログラミングの知識がなくてもワールドエディターを使用して管理できる必要があります（編集：一般的にはスクリプトに反対しません）
実装言語としてC ++を想定しています

イベントと条件のチェーンを組み合わせることができれば、より複雑な、したがってより魅力的なクエストをモデル化できると考えていました。独自のECA（イベント-条件-アクション）エンジンをローリングして実験しましたが、それはやり過ぎかもしれません。スクリプトを使用せずに一般的な条件をモデル化することは特に困難でした。

— jmp97
ソース

スクリプトをスキップすることにした具体的な理由はありますか？（lua / gamemonkeyなど）。

— サイモン

これは主に、経験不足と、これがパフォーマンスに悪影響を与える可能性があるという仮定（おそらく不適切）によるものです。また、世界の編集をできるだけシンプルにしたかったのです。ただし、スクリプトを使用することはできます。

— jmp97

私は同意しますが、スクリプトのサポートがなければ、エンジンプログラマを関与させずにクエストに多様性を加えることは難しいでしょう。

— drxzcl

スクリプト言語は、問題がないほど高速である傾向があります。それらを使用することを強くお勧めします。とはいえ、WoWのスクリプトの多くは、呪文やイベントのトリガーに基づいています。「Talk to A」は、舞台裏でAがプレイヤーに「呪文を唱える」原因となり、クエストは実際に「これはプレイヤーに呪文＃55728がキャストされたときに成功します」とコーディングされます。その後、プレイヤーにクリーチャーが呪文を唱えるためのちょっとしたAIコーディングが必要なだけで、設定は完了です。

— -ZorbaTHut

最近のスクリプト言語（Lua Vmなど）はおそらく十分に高速です。それらは使いやすく、実装が簡単で、実行時にスクリプトをリロードでき、実行時にスクリプトをデバッグおよびステップ実行でき、コンテンツを作成する際により速く反復できます。クエストをスクリプト化するために、スクリプトエンジン（例：luaおよびgamemonkey）を調べることを強くお勧めします。

— サイモン

回答:

最初に警告、次にいくつかのアドバイス。

前回このようなシステムを実装する必要があったときは、元々MMOのようなアプリケーション向けのエンジンを使用していませんでした。付属のクエストシステムは、シングルプレーヤーの努力を対象としており、使用できませんでした。

次のように、クエストに関係するすべてのオブジェクトのスクリプトを多少手作業で詰めることになりました（疑似コード）：

Lever004_on_activate() {
    if isOnQuest(player, QUEST_0012) do_something();
    if isOnQuest(player, QUEST_0015) do_something_else();
}

これは完全な悪夢です。ゲーム全体を清掃せずにクエストがどのように機能するかを把握する方法はありません。こんなことしないで。

クエスト（ライン）全体が有限状態マシンとして表され、遷移をチェックするイベントと、その遷移に反応するスクリプトを備えたシステムを作成することをお勧めします。これにより、特定のクエスト（ライン）のどこにいるかを簡単に追跡でき、すべてのクエストの状態をきちんとカプセル化できます。

必要に応じて、ワールドエディターで一般的な出来事（プレイヤーがNPCと話す、プレイヤーが暴徒を殺すなど）のためのスクリプト/スクリプトテンプレートのライブラリを作成できます。

イベントスクリプトを頻繁に起動しない限り、スクリプトのパフォーマンスについてあまり心配しません。経験則として、スクリプトは、少なくとも「コア」ゲームロジック（アニメーション、物理学など）よりも1桁少ない数で起動する必要があります。定期的に起動して条件が満たされているかどうかを確認するのではなく、イベントに反応する必要があります。

— drxzcl
ソース

ただし、クエストパスが外部要因の影響を受けたい場合、またはクエストが比較的複雑な場合、ステートマシンは非常に複雑になりがちです。また、複数のクエストステートマシン（複数のクエストをアクティブにできる場合）は悪夢のようです。ただし、本質的にすべてのプログラムはステートマシンであるため、実行できます。しかし、複雑な問題は、どのようにカプセル化しても複雑なままです。良い例（imo）は、いくつかのmodが他のmodの動作を停止するOblivionです。状態の事前条件と事後条件は、かなり堅実であるか、非常に寛容/エラートレラントでなければなりません。

— カイ

うん、カイは正しい。今すぐWoWフォーラムにアクセスして、完了できないクエストについて苦情を言っている人々について読んでください。メジャーリーグでも、それは常に起こります。すべてを正しくするのは本当に難しいです。

— drxzcl

私たちのシステムは、基本的に、各ミッションステップの各サーバーフレームで式を実行します（カスタムミニスクリプト言語ですが、tcl / lua / pythonも同様に機能するか、自分で何かを作成します）。これは、特定のプレイヤーに結び付けられた「パーソナルミッション」用です。各サブステップは、ミッション自体のFSM（有限状態マシン）の一部になります（別のミッションのサブステップにすぎない場合があります）。また、単一のFSMを持ち、プレイヤーではなくマップに結び付けられた「マップミッション」もあります（WARのパブリッククエストを考えてください）が、サブステップは基本的に同じように機能します。

これらの式が実際に見ているのは、「NPCが死んだ」や「インタラクションが完了した」など、システムによってブロードキャストされるイベントです。つまり、さまざまな部分をある程度切り離すことができ、ゲームプレイシステムは必要に応じてイベントを送信するだけで、ミッションスクリプトはイベントをリッスンするだけで、どこから来たのか心配する必要はありません。それを重ねると、ミッションFSMがワールドステートと対話できるようになります（ミッションステートXの場合のみこの連絡先を表示します）。システムから多くのパワーを得ることができます。

— コーダーレンジャー
ソース