web-dev-qa-db-ja.com

RPG(ロールプレイングゲーム)のクラス図の例

RPゲーム開発用のクラス図の例がどこにあるか知っている人はいますか? here のようなものは非常に役に立ちます。私は私が自分のクラスを書き下ろしてみているときに発見している問題のさまざまな解決策を図解するさまざまな例のためだけに、私が怠惰にコピーできるものを探していません。

27
Steerpike

GameDev.netのEmmanuel Delogetは知っていますが、彼が持っている階層を使用するかどうかはわかりません。継承が多すぎ、柔軟性が不十分です。

テキストベースのRPGを作成していた場合(これまでに行ったように)、次のようになります(残念ながら、そのための図を作成する時間はありません)。

  • WorldEntityから派生した生き物、部屋、およびアイテム。WorldEntityオブジェクトは複合構造に配置されているため、アイテムは部屋内に存在する生き物によって運ばれる他のアイテム内に存在できます。 WorldEntitiesにビジターパターンを実装するとうまくいく場合があります。
  • 個々のCreatureおよびItemインスタンスの「クラス」データを含むCreatureTypeおよびItemTypeクラス。対応する「type」オブジェクトを参照します。 (例えば、前者の基本ヒットポイントと統計、後者の現在のヒットポイントと一時的な影響)。これらは、作成時にCreatureまたはItemインスタンスにコピーされるプロパティのプロトタイプリストとして実装する場合があります。特定のゴブリンCreatureインスタンスが「ジェネリックゴブリン」CreatureTypeへの親参照を含む「戦士ゴブリン」CreatureTypeに関連付けられるように、「親」プロパティを介してプロパティ継承を実装できます。等々。
  • 部屋が所有している一方向の出口であり、移動方向や通過のさまざまな条件などを詳しく示します。
  • いくつかの論理的な組織によって接続された部屋のグループを含むエリア。
  • CreatureとItemインスタンスが作成される場所(たとえば、どの部屋、どの座標にあるか)、いつ、どの頻度で、どのCreatureTypesとItemTypesから作成されるかを指示するSpawnクラス。ここに少しランダム化するロジックがあるかもしれません。
  • 呪文、スキル、能力などはすべて、前提条件(現在の位置、マナポイント、スキルのある程度の習得など)を指定する基本アクションクラスまたはインターフェイスから派生します。通常のコマンドとアクションは、ある種の要件もあることが多いため、ここでも使用できます(たとえば、「sleep」コマンドでは、まだスリープしていない必要があります)
  • 基本的に、将来実行するために優先キューにプッシュするコールバックであるFutureEventクラス。これらを使用して、戦闘ラウンドのスケジュール、クールダウン時間のスペル、夜/日サイクルなど、好きなようにスケジュールできます。
  • プレーヤーとアイテムの統計情報の名前と値のペアのハッシュ/マップ/辞書。タイプセーフではありませんが、柔軟性は後で高く評価されます。私の経験では、統計のメンバー変数を作成することは実行可能ですが柔軟性がなく、特殊化された「属性」クラスを持つことはデバッグ時に複雑な悪夢になります。
  • 統計名と修飾子の値を含む修飾子タイプ(例:+ 10、+ 15%)。これらは、使用されると(たとえば、呪文効果によって、またはエンチャントされた武器を振るうことによって)クリーチャーに追加され、時間指定されたFutureEventまたは実行中のコマンドなどの他のイベントによって後で取り除かれます。
  • PlayerClassやPlayerRaceなどのゲーム固有のクラス。各クラスは、プレーヤーのクラス(たとえば、戦士、ウィザード、泥棒)または人種(人間、エルフ、ドワーフ)を記述し、開始統計値と制限、スキルの可用性リスト、特別な能力、等.
  • 実際のゲームタイプによって異なる基本的なプレーヤーインターフェイスクラス。グラフィカルゲームのレンダリングクラスがある場合や、MUDに、プレーヤーのクライアントへのTCP接続を反映するConnectionクラスがある場合があります。すべてのゲームロジックをこれらのクラスに含めないようにしてください。
  • スクリプトインターフェイス。ほとんどのコマンド、スペル、およびクリーチャーAIは、適切なスクリプトインターフェイスを使用してより迅速に実現でき、コンパイル時間も短縮されます。また、ゲーム内の優れたデバッグ機能と診断機能も利用できます。

それが私が使用する基本的な高レベルの構造になります。

49
Kylotan

従来の継承階層ではなく、コンポーネントエンティティシステムを検討することをお勧めします。特定の種類の変更に対してより柔軟になり、ツール(ワールドエディターなど)の開発がはるかに容易になり、他の方法では明白でも簡単でもない並列化の機会を提供します。

最新のゲームエンジンの多くは、「モノリシッククラスオブジェクト」(またはクラスエンティティなど)から離れ、「コンポーネントのバッグ」アプローチに移行しています。

周りにはたくさんの本や記事があります。一般的に:

具体的には(注目に値するもの、Googleの「コンポーネント」と「エンティティ」のさまざまな組み合わせでの詳細):

これらの各記事は、さらにいくつかの記事にリンクしています。

クールエイドを試してみてください。 =)

11
leander
<tongue_in_cheek_mode_because_it_is_friday>

はじめに:

          ----------------                    --------------
          |   Creature   |                    |  Item      |
          |--------------|                    |------------|
          | Name         |                    | Name       |
          | Hp           |                    | Value      |
          | Abilities    |--------------------| Weight     |
          |--------------|                    --------------
          | Attack       |
          ----------------
                 ^
                 |
        ----------------------
        |                    |
----------------    ----------------
|  Hero        |    |  Monster     |
|--------------|    |--------------|
| Level        |    |              |
|--------------|    |--------------|
| KillMonster  |    | AttackAndDie |
| GrabTreasure |    | DropTreasure |
----------------    ----------------

</tongue_in_cheek_mode_because_it_is_friday>
5
Toon Krijthe

A 非常に異なるアプローチ Steve Yeggeによる。

4
h0b0
4
Andreas Grech

複雑なゲームの概要については、 JADEのJavadoc をご覧ください。

3
changelog

大胆に、あなたのゲームはハックのクローンやナンセンスなスラッシュであってはなりません。あなたの俳優は側を切り替えたり、彼ら自身のイニシアチブをとったり、他の俳優を募集したりすることができるはずです。それ以外の場合、ポイントは何ですか?

   +-----------------------------+
   V                             |
[Actor] ------- [Allegiance] ----+
 - risk comfort    - weight
 - temerity        
1
Justin