このテキストゲームをどうやってコントロールすればいいのですか？

Question

私はitemとenemiesのオブジェクトを持つroom型のオブジェクトを持つworldオブジェクトを持っているtextgameを持っていて、次に実際のプレイヤーのためのユーザーオブジェクトを持つgamehelperオブジェクトを持っています。 （このゲームには私の質問が私のために大いに複雑になるので、徘徊している敵はいません:-)）

敵を殺すか、 私のクラスを完全に構造化するときに、他の方法で考えるべきですか？私は世界を支配し、ユーザーとオブジェクトの間の仲介を必要とするマネージャーが必要だという提案を得ましたが、がどのように見えるかはわかりません。

私はまた、関連性のあるものなら、必要に応じてオブジェクトをそれぞれのオブジェクトから分離するためのインターフェイスを実装します...そして、Javaを学ぶので、理解するのに役立つ可能性のあるサンプルコードはその中に書かれています。

すなわち：

 World 
     | 
    ____Rooms____ (could be like a 4x4 array or something with X and Y cords) 
    |   | 
    Objects  Enemies (Either killable/pickupable) 

     Game 
     | 
     User (can walk around in rooms, kill monsters and take treasure) 

Answer 1

あなたの図がそれを示した図でない限り、私はあなたのクラス構造と明らかに間違っ何も表示されません。 :)部屋、オブジェクトと敵は確かにを継承しないでください世界。あなたが閉じ込めを図っているようですが、これはうまくいきます。

どのように敵を殺したり、オブジェクトを拾いに行くのですか？それはあなたのゲームでそのアクションが意味するものに依存しませんか？それは、オブジェクトをピックアップするために、ObjectはRoomまたはUserのいずれかの環境を持つように思えます。その環境がユーザであるオブジェクトは、そのユーザのインベントリに含まれています。オブジェクトをピックアップすると、環境が部屋からユーザーに変わります。

可能性のあるオブジェクトには敵もその環境として持つことができるため、敵を殺すと敵を破壊し、敵の目録のオブジェクトを敵が占有していた部屋に移動させます。あるいは、あなたは "死んだ敵"タイプのオブジェクトを望んでいますか？本当に、それはあなたのゲームモデルによって異なります。おそらく攻撃可能とpickupable項目について

Answer 2

インターフェース、：

interface IAttackable { 
    void Attack(); 
    event Killed; 
} 
interface ILiftable { 
    void Get(Container putHere); 
} 

は、その後、あなたが攻撃したり、物事を拾うことができるかどうかを確認するために、単純な型チェックを行うことができます。

はい、メディエータオブジェクトはいいアイデアのように聞こえます。たとえば、IAttackable.Killedイベントをすべて購読して、何かが同じ部屋で死んだときにUserクラスに信号を送ることができます。また、どれくらいのダメージを受けるかを組織するのにも間に合います。

個人的には、私はCreatureクラスを持っていて、少しずつ単純化するために、敵とユーザーの両方をサブクラス化しています（必要性が生じた場合に敵と戦う可能性があります）。

Answer 3

コントローラやメディエータクラスは、アプリケーションでよく使用されますが、これは私には「匂い」があります。そのようなクラスは、他のすべてのクラスが単なるデータコンテナであるときに、すべてを知る、いわゆる「神クラス」になることがあります。

この種のデザインは警告されています。この警告と他の本当に良い原則が含まれていますOO - デザインについて良いbookがあります。

私はOO-Designのために、一般的に「おじさんのおじさん」Robert C. Martinの記事をお勧めします。あなたは「デザイン原則」と特に最初の記事を見てください。

これらは、クラスをどのように設計するべきかを理解する上で貴重な資料です。イベントやその他のものによるデカップリングもそこで処理されると思います。

この武器では、デザインの準備がはるかによくなります。

デザインは、どのオブジェクトがどのような作業を行うべきなのかを考えて開始することもできます。すべての活動を集めるテントのオブジェクトは、神のクラスのように臭いがあります。すべてのアクティビティを持たないテントのオブジェクトは、まったく必要ないものとして臭いがあります。他のオブジェクトが持ち運びできない機能を実際に持たない限り、「World」と「Game」のボックスはこの方向でやや臭いです。

世界がどのように機能しているかを考えてみると、デザインが非常に簡単になることがあります。このような「環境」のような思考は、協会としてここで行うことができます。しかし、異なるモデリングも可能です。このことについて（ちょうど推測！）：あなたの部屋はなぜオブジェクトでなければならないのですか？部屋に含まれるオブジェクト用のスロットを持つ2D配列（ユーザーオブジェクトを含みますか？）だけを含むワールドオブジェクトを持つこともできます。これは、あなたが大きな「世界」を持っているときに、物事を楽にすることができます。もちろん、オブジェクトとしての部屋には、無制限のオブジェクト（敵、ユーザー、アイテム）が簡単に含まれるという利点があります。

まず、あなたはItemクラスまたはTakeableクラスを持っていればそれについて考え始めるかもしれません。

ほんの少し役に立ちます。躊躇しないでください。

Answer 4

コメントに記載されているように、ゲームがシングルプレイヤーかマルチプレイヤーか、ターンベースかリアルタイムかを知ることは重要です。シングルプレーヤーターンベースのゲームのためのシンプルなソリューションは、マルチプレイヤーのリアルタイムゲームでは変更されていないため動作しません。シングルプレイヤーターンベースのゲームのために

、以下の基本的なアウトラインは、あなたに1つのアプローチ（Pythonのような擬似コード）を与える必要があります。

def main_loop(): 
    while not finished: 
     command_text = ask_user_for_input() 
     execute_player_command(command_text) 
     update_world() 
     send_output_to_player() 

def execute_player_command(command_text): 
    # look up the command object and work out what parameters to pass it 
    command, parameters = parse(command_text) 
    # ask the command to do its stuff 
    command.execute(player, parameters) 

def update_world(): 
    # obviously you can munge these together with an Updateable interface 
    # or something similar 
    for each creature in all_creatures: 
     creature.update() 
    for each object in all_objects: 
     object.update() 

あなたはリアルタイムだというよりもターンベースの場合は、お使いのメインループはおそらく入力のためにポーリングするように変更されるでしょう。おそらく、繰り返しごとに1回ではなく、何らかのタイマーでupdate_worldを実行したいと思うでしょう。ラウンド・バイ・ラウンドによる戦闘などの定期的な作業については、そのようなタイマーでも実行できます。将来のイベントを時間順に並べ替えることができれば、各イベントの待ち行列の先頭を確認して保留イベントを確認すると便利です。

コマンドオブジェクトは、必要に応じてすべての関連パーティーをルックアップして操作を実行することができます。必要に応じてPCやNPCによって使用され、将来動作させたい場合は、将来のイベントキューにプッシュされます。明らかにコマンドオブジェクトが有用であるためには、それらは世界で物事を見ることができる必要があります。部屋内のすべてのオブジェクト、部屋内のすべてのオブジェクトなどを探し出すことができます。狡猾な人は、薄型ラッパーを使用して、ほぼすべてを1つの包含インターフェイスで実装できます。