オブジェクト指向でドラクエ

ＯＯな皆さま、出番です。

「オブジェクト指向の視点から、ドラゴンクエストを考えてみよう」という趣旨のスレです。

子供の頃やったドラクエを、オブジェクト指向で捉えた場合どんな設計で作るのかに興味を持ちました。
ＲＰＧだって「現実世界をゲーム上でシミュレート」なんだから、相性はいいはずです。
オブジェクト指向で分析すればどんなカタチになるか、面白そうじゃないですか？
「勇者はどんなクラス」とか、「マップはどう表現しよう」とか、
はたまた「このイベントはユースケースではどんなものになるんだろう」
みたいな討議をしていきましょう。

もちろん”車輪の再開発”で”妄想”なスレです。成果などは期待しません。
「言いだしっぺの法則で成果物出せやｺﾞﾗｧ」系のあおりは無しの方向で。

基本的には、ＤＱ�Tをターゲットにします（昨今のは煩雑になりがちなので）
が、それ以外のＤＱシリーズや、転じて２ＤＲＰＧ全体に対しても、扱っていっても良いかと思います。

実装例などを出す場合には、言語は問いませんが、基本はJavaでおながいします。
(わかる人が多いと思うので。)

じゃぁ、みんなお願いね。

System.out.println("へんじがない。ただのしかばねのようだ。");

ｸｿｽﾚ

子供の頃やったのは
ハイドライド、ザナドゥ、ブラックオニキス、ファイアーストーンなどです
ドラクエなんてありませんでした

そんなもんマ板でやれ。

>>1
板違いです。
ゲーム製作技術板
http://pc5.2ch.net/gamedev/

子供のころやったのは
アーストレック、表参道アドベンチャー、南青山アドベンチャーでした。
ドラクエなんてありませんでした。

勇者クラスつくりました！

public class Braver extends Actor {
　public String speak() {
　　if ( Math.random() > 0.5 ) {
　　　return "はい";
　　} else {
　　　return "いいえ";
　　}
　}
}

(-Ａ-)あ〜もう、これでいいすか？

子供のころやったのは
スカッシュ、ブロックくずし、インベーダーでした。
ドラクエなんてありませんでした。

子供の頃やったのは、わけのわからない小躍りをさせられるマスゲームでした。
北朝鮮では大人がやらされるそうです。

微妙に面白そうにおもうけど、レス伸びてないなぁ…
（この板の人はﾋﾏじゃないのか…）

new Actor(
"当店は最高のサービスをお客様に提供することをモットーとしております。",
"はぁ? 金持ってねえならさっさと野垂れ死ねや!"
);

(´-`).。ｏＯ(どんなコンストラクタが書かれているのだろう？)

class yusha {
UINT Hp;
void HpDec(Damage);
boolean TellDie();
};

（ローマ痔のクラス名がなんとも…）

public interface fight {
public void fight(){};
public void magic(){};
public void escape(){};
}

>>15 頭悪杉。ネーミングセンス無さ杉。

でも自分も書けないとｗ

>>17
つーか、俺、市販RPG開発したことあるんだけど(藁

じゃあ俺、市販ゲーム機開発したことあるんだけど（裏

>>15 は、ネーミングセンスはおいといて、俺も同じ事考えてた。
FightAbleインターフェイスを作るってことを。

勇者は当然、２以降からのパーティバトルでのプレイヤーキャラとか。
モンスターもこのインターフェイスを実装する。

メソッドは…どうしようかな。

>>16
リファクタリングしたコードをうｐしてください。

>>21
悪いが、それはできない。著作権売っちまったから。

開発って言ってもピンキリだからな。

疑問に想うんだけど、オブジェクトでDQの「たたかい」の概念を作るってどうするのかな。

バトル可能なキャラオブジェクトのメソッド・パラメタは定型なもので、
バトルマスターっていうかジャッジメンターみたいなオブジェクトがいて、
そいつが実際の「たたかい」のコントロール(闘う順番、ダメージ通知とか)
をするんかな。

経験者様もいらっしゃるみたいですが。
おしえて、エロい人！

ローカルルール嫁

あのう、1ですが…

>>5 , >>2

ゲーム作るっていうのじゃなく、分析したらどうなるの？的なスレにしたかったのですが。
例えば、職業SEの方々は「業務」の部分をモデル化して、クラス抽出で、実装じゃないですか。
その分析対象である「業務」部分が、誰でも知ってるもの（でドラクエ）なら、
今から設計の世界に入る技術者さんにも、良いリファレンスモデルになるのではないかと。
OOの入門書に「車を例に…」なんて多く出てくるところから、それよりも解りやすかろうと。

ゲ板で「クラス抽出を…」とかの話って出てくるんですかね？
はたまた「JAVAでシューティング作る〜」スレもム板にあることですし、
って言うのは都合の良い考え方ですかそうですか。

○○とゲームプログラミング Rev 3.0.0
http://pc5.2ch.net/test/read.cgi/gamedev/1075636615/

あれれ。良スレだと思ったんだけどな。
あくまでもゲームを作ることが目的なんじゃなくて、
データ構造などを、オブジェクト指向的に表現したらどうなるかって話でしょ。
とりあえず1の言いたいことは分かる。

じゃあ、アイテムあたりを行ってみようか。基本的なゲッター・セッターのメソッドは
めんどいので省略。
public abstract class Item{
　　private int price;
　　// プレイヤーが「つかう」コマンドを実行したときに呼び出される
　　public abstract void used();
　　// 「すてる」ことが出来るかどうか
　　public abstract boolean canThrowOut();
}
public class Player{
　　private static Player player; // ドラクエ1は一人旅なので、シングルトンパターンで。
　　public static Player thePlayer(){
　　　　return player;
　　}
　　private Player(){
　　}
　　public void use(Item item){
　　　　item.used();
　　}
　　public void throwOut(Item item){
　　　　if(item.canThrowOut()){
　　　　　　System.out.println(this.name+"　は　"+item.getName()+"　を　なげすてた");
　　　　}else{
　　　　　　System.out.println("それを　すてるなんて　とんでもない！");
　　　　}
　　}
}

public class やくそう extends Item{
　　public void used(){
　　　　Player p = Player.thePlayer();
　　　　System.out.println(p.getName()+"は　やくそう　をつかった！　"+p.getName()+"のHPが　かいふくした！");
　　　　p.recover(30);
　　}
　　public boolean canThrowOut(){
　　　　return true;
　　}　　
}
public class おうじょのあい extends Item{
　　public void used(){
　　　　Player p = Player.thePlayer();
　　　　Position pos = p.getPosition();
　　　　int x = pos.getX();
　　　　int y = pos.getY();
　　　　// あーめんどくさくなってきた。あとは省略
　　}
　　public boolean canThrowOut(){
　　　　return false;
　　}
}

もつ鍋

スライムを継承したスライムベス。
スライムベスを継承したメタルスライム。
スライムを継承したバブルスライム。
スライムを継承したホイミスライム。
キングスライム、メタルキング、スライムベホマズン・・・以下略

課題。
スライム属の全ての継承関係を作れ。

ひくいどりとホークブリザードの多重継承でにじくじゃくになるわけだが。

ドラクエ＝糞
↓
HSP＝糞
↓
onionsoftのTOPの物体＝スライムのパクリ
↓
両方とも糞
↓
HSP＝ドラクエ

どう考えてもマ板向けのネタだろ。

プレイヤーはどうやってItemを持つんだ？
class Yuusya {
List itemList;

void getItem(Item item) {
}

void dropItem(Item item) {
}
}
とかじゃあ、うまくいかんなあ。

あと、Itemを店で金払って買うっていう行動。
どう設計すんだろ？

実際に作ってみればいいんじゃないの？

class WeaponShop{
  List listItems;

  getItemList();

  buy( Item* item ){
    Player p = Player.thePlayer();
    int balance = p.getMoney();
    if( balance >= item->getPrice() ){
      System.out.println("おお！お目が高い");
      p.setMoney( balance - item->getPrice() );
      p.addItem( item );
    }
    else{
      System.out.println("おや、お金が足りないようですね");
    }
  }
}

>>35
オブジェクト指向がアダになるっつーか、
アイテムは単なる数値配列で持ったほうがラクじゃね？

そんなやり方してても手続き的なプログラムをクラスにまとめただけになるだろ。

せめて、キャラクタ共通の行動と道具の効果とシナリオ中のイベントの効果を
明確にしなければ、プロトコルを決めようがないじゃん。

正直、まともに作ろうと思ったら、
オーサリングされたシナリオと、それを読み込んで動くプレイヤー
という構造にしかならない。

そうすると、個々のモンスターやアイテムごとにクラスを定義することはなくなり、
それぞれシナリオからパラメータを読み込んでインスタンスとして生成する
ということになる。

野外マップ・ダンジョンマップ・街マップという
大体三つくらいのデータオブジェクトの固まりがあって、
エンカウントするモンスターの種類や数は野外マップオブジェクトの
各スクェアに書き込まれる属性。

モンスターは全部Monsterというひとつのクラスで表現され、
それぞれが名前、HP、MPや呪文／特殊能力の種類、強度、発動率などの
データを属性として持つインスタンスとして戦闘発生時に生成される。

>>41
それじゃ、Cで敵キャラ用の関数をmonster.cに書くのと何の変わりもないね。
全然OOにする意味無し。

Quake あたりのエンジン持ってきて、リアルタイムなDQになっちゃいそうだ

つまり、定型的なことしか起き得ない、
ルーチンワークなシナリオゲームにしかならないと。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

じゃあ、人工知能を作るか。
シナリオ性が無くなるけど。

物を買うメソッドを追加してみた。

class Player{
　　public static final int ITEM_MAX_SIZE = 10;
　　private ArrayList items;
　　private int money; // 所持金
　　public void buy(Item i){
　　　　if(this.money < i.getPrice()){
　　　　　　throw new MoneyShortageException();
　　　　}
　　　　if(this.items.size() == ITEM_MAX_SIZE){
　　　　　　throw new CannotAddItemException();
　　　　}
　　　　this.items.add(i);
　　　　this.money -= i.getPrice();
　　}
}

そこでthrowなのか・・・

buyの宣言でthrowsを入れとけ

テレビゲームじゃエラーは発生しないし、
例外でオチたりしない。まぁ最近はCD-ROMとかメモカとかあるけど。

デバグ用にエラー検出コードは入れるけど。

>>55はExceptionとErrorの違いを(ry

例えば武器屋だとか、薬屋だとかがあるとする。
class Shop {
List itemList;

List showItemList() {
return itemList;
}

//売る。
Item sell(Item item) {
return item;
}

//買い取る
void buy(Item item) {
}
}
これをどうやってPlayerクラスと使うかだな。
Itemを店に下取りに出したとき、確実にPlayerからそのアイテムが
無くなってなきゃいけない。
あと金の受け渡しはどうやる？

だからclassより先にinterface決めろやって。

キャラクタを表わすクラスがPlayerってのはどうなんだろう。

>>56
違いってなにか、教えてください

エラー∈例外

>>61
馬鹿。エラー⊂例外だろ

>57
とりあえず、interface Shoppingable でも規定した方がいいんでないか？

>>63
tradableにでもしとけ。buyableとsellableに分離してもいいな。
あと武器用にもoffensiveとdefensiveも定義しる。

魔法使いには Castable もいるねぇ

モンスターによって、アイテムやお金を落とすかどうかを定義かな

intarface IDroppable {
　　boolean isDropped();
　　int getMoney();
　　IEnumerable getItems();
}

キャラクターと PlayerControllable は分離した方が良くないか？

class PlayerChara extends Character implements IPlayerControllable

つー感じで

メモリを潤沢に使える環境で開発している人たちが
うらやましいと感じてる、ゲームプログラマのオレ。

まぁスレタイ的に、メモリ潤沢は当然

OOとOOPLは別物と言い残して逃げよう

>>66
>>キャラクターと PlayerControllable は分離した方が良くないか？

なぜ？

>>70
プレーヤーのキャラ選択でキャラにプレーヤーがつくのとつかないのとあるじゃん。
同じオブジェクトで表現したければ、クラスとしてはキャラで、プレーヤからの操作は
インターフェースで宣言するのがいいと思うが。

何でもable付ければ良いってもんじゃねえんだよ

対象は DQI じゃなかったのか

>70
モンスターやNPCもキャラクターClassの派生だと考えれば、プレーヤーのキャラ自体は
ユーザーが制御可能であるという点で特徴づけられるから

NPCとプレーヤーの共通点は、マップ上にグラフィックがあって２コマで動きますってぐらいか。
ドラクエ１形式を考えると、共通のキャラクタークラスを用意するより１つのインターフェイスを定義した方がいいんじゃないのかな。
モンスターはマップに出てこないからまた別だと思う。

>73
DQ2 を作るときに資源を活用できるようにだろ。次スレがDQ2か？

>>76
> 次スレがDQ2か？

だいぶ先は長いがな。あと925レスか。

>75
それは View レベルの問題だと思われ
OOとしての設計ではないと思うんだが、モンスターもPCもHPやらアビリティを持っている
訳で、そこらへんは統一した実装クラスにまとめておいた方が管理上、楽でしょ
マップとして必要なエリアにきたら、データからアクティベートしてエンカウント計算して
遭遇時にマップ上に表示すりゃいいわけで

って、何まじになってんだろ、漏れorz

>>15
みたいに

>public interface fight {
>public void fight(){};
>public void magic(){};
>public void escape(){};
>}

ってやるより、

interface Action{
　doAction(...);
};

class Fight implements Action{
};

class Magic implements Action{
};

class Escape implements Action{
};

みたいに行動ごとにクラス用意したほうが敵の攻撃方法をランダムに選ぶ時によくない？

>>79
戦闘用のインターフェースを定義して、キャラクターやモンスターのクラス
で実装する時に、各攻撃手段や呪文などをCommandパターンで実装する
のが定石だろうな。

>>80
>戦闘用のインターフェースを定義して、キャラクターやモンスターのクラス
>で実装する時に、各攻撃手段や呪文などをCommandパターンで実装する
>のが定石だろうな。

ってのは、

interface Fighter{
　void onAttacked(Action action);
};

Action someAction = 勇者.getSelectedAction();
スライム.onAttacked(someAction);

って感じ？

それなら見方に呪文だのラリって見方に攻撃だのってのが、って見方がいないんだっけな。
薬草を使いたいときはどうすんだ？

この調子でsourcefogeまでいったらおもろいな。
いってしもたらつらいけど。

薬草をクラスにすべきかは置いといて、

Yakusou implements Item, Action{
　
};

Action someAction = getSelectedAction();//薬草インスタンスを返す
Character someTarget = getSelectedTarget();//ターゲット(自分)を返す
someTarget.onAttacked(someAction);

ってな感じか？onAttackedは別の名前にすべきだと思うけど。

>>84
「薬草」というアイテム自体と「薬草を使う」という行為は
別オブジェクトにしたほうがいいな。

薬草の効果や商品価値などはそれぞれの薬草固有だし、
「薬草を使う」という行為と直接関係ないから。
それとは独立して「薬草を使う」「薬草を買う」等の行為を
それぞれオブジェクトにまとめるのがいい。
その上で、「使う」「買う」などを抽象クラスにすればいいのでは？

どうもイメージがわかないけど、
薬草を「買う」のと武器を「買う」のは同じinterfaceだよね。

>>85
>「薬草」というアイテム自体と「薬草を使う」という行為は
>別オブジェクトにしたほうがいいな。

interface Item{
　UseProcedure getUseProcedure();
};

interface UseProcedure{
　void use(Unit target);
};

class Yakusou implements Item{
　UseProcedure getUseProcedure(){
　　return new YakusouUseProcedure(this);
　}
};

class YakusouUseProcedure implements UseProcedure{
　void use(Unit target){
　　target.heal(30);
　}
};

という感じか？薬草オブジェクトから「使う」オブジェクトがもらえるのは違和感ないけど、
「買う」オブジェクトがあるのは違和感あるな。

実際にはＨＰ無い物体には使えないから、

　void use(Unit target){

のところは

void use(ＨＰ回復可能なインターフェイス target)

ってところか。

>>88
自分でコード書いておいてなんだが、対象がないアイテムもあるだろうから、

interface UseProcedure{
　void use();
};

class YakusouUseProcedure implements UseProcedure{
　YakusouUseProcedure(Healable target);
　void use();
};

のほうがいいかな、と思った。
それとも「使う」のインターフェースを対象別に分けるべきかね？

勇者.ｕｓｅ（薬草）

とかしたいよね。

void use(Healable item)
void use(あと何使うんだable item)

interface Effect {
　void affair(Chara chara);
　void affiar(Enemy enemy);
　...
}

とかにした方がいいんでないか？

>>91
interface Healable　じゃなくってってこと？

>>90
なんか勇者.use(...)は関係が密すぎる感じがする。
アイテムを使うのも、攻撃するのも、魔法を使うのも
メソッドじゃなくて、同じインターフェースを持ったオブジェクトにまとめたほうがよくね？

>>91
対象のオブジェクトによって動作を変えるためにメソッド二つ用意するくらいなら、
CharaとEnemyに同一スーパークラスを持たせて、
affairメソッド内でinstanceofで動作を変えるべきじゃない？

>93
明示的に処理を行いたいときがあるかな、と思ってね
しかし、こういうときほど多重継承のありがたみがわかるなぁ（ｗ

>>94
> しかし、こういうときほど多重継承のありがたみがわかるなぁ（ｗ

それはちょっと間違って(ry

>>93
そういうところでinstanceofは使うべきじゃないと思うな。if else if else if else if ......

>95
いや、実際、これまでの話の中で何度か「それは多重継承すればいいんじゃないか」と
思ってね

>>93
> affairメソッド内でinstanceofで動作を変えるべきじゃない？

せめてダブルディスパッチしてくれい…

あのぅ、1ですが…

いやー、地下でスレ伸びててびっくりしました。集ってる方感謝っす。
途中、ケンモホロロに追い返されたので、素直にゲ板いってそれ系のスレ見てました。

さて、勢い出たんで、このスレ立てた時に考えたクラス体系を、
皆さんのやりかたを加味して書きたいと思います。
(一笑に伏された後、だれかがもっと良いのを出してくるのを期待してます)

・クラス
Object
├Controler - 一階層かます(なくても良いかも)
｜├GameControler - ゲームの進行を管理
｜├GraphicControler - 表示を管理
｜├SoundControler - 音の管理をする。
｜├ButtleControler - 戦いを管理。
｜｜　　　　　　　　　行動の順や、「この人が"戦う"選んでるからこの人にダメージ」なジャッジをする
｜└MapControler - マップを管理(町、ダンジョンの切り替えなどをつかさどる)
｜
└GameObject - 一階層かます(ゲーム内登場物という共通特性がある場合に。Nameとか)
　├Actor - 演者。主に有生物。
　｜├People - 町の人とか、戦わないマップキャラで終わる人々。
　｜├Enemy(Monster?) - 敵。Battleable実装
　｜｜└[性格を持った敵] - 振る舞いが特化されていて、個々に実装必要な奴。ボスなど。Battleable実装
　｜└MainActor(Player?) - 主人公とその仲間。Battleable実装。
　｜　└[性格を持った仲間] - それぞれ実装を必要とする場合のキャラ。
　｜　　　　　　　　　　　　　NPCを含むためControlable実装は任意。
　├Map - マップの名前とマップチップのデータを持つ。
　├MapChip - マップの特性を持った構造体(構造定義せずに配列とかでも良い？)
　├Item - アイテム共通の性格。
　｜└[個々のアイテム] - 性格を持ったアイテム。振る舞いは個々に違うため別個に記述。
　├Magic
　｜└[個々の魔法] - 性格を持った魔法。振る舞いは個々に違うため別個に記述。
　└Skill(Action?) - スキル。プレイヤーごとにインスタンスを4つまで保持し、戦闘時コマンドとして表示。
　　├Spel - 呪文をとなえる。(PlayerのMagicリストを参照したい)。
　　├Fight - たたかう。
　　├UseItem - アイテムを使う。(Playerのアイテムリストを参照したい)
　　├Defence - 防御
　　├Escape - 逃げる。(隊列先頭の奴に強制的に付加されるって、なぁ)
　　└[その他] - 昨今のドラクエの"とくぎ"など。

・インターフェイス

Battleable - 戦闘ができる。Hp,Mp,つよさ全般のパラメータはここに含まれる。
Controlable - 戦闘時自分で操れる。
BattleUse - Item、Magicに任意で実装。戦闘中に使える。
FieldUse - Item、Magicに任意で実装。フィールドで使える。
EventUse - Itemに任意で実装。捨てられない。使うと無くなるなど。
Tradable - Peopleに実装。Shopから買うのではなくて売買資格のある人から買う、という概念で。

Skillのところは適当すぎるかも。FF5のアビリティか…
MainActor,Enemyごとにメソッドとして実装したほうがいいのかな。
コントローラ的なものが居るって、なんか正しくないんでしたっけ？
あと職業の概念をどこにも入ってないっすね。
ああ･･･叩きどころは満載ですのでたたき台ということでどうか一つ…

MainActorは、みんなが"Player"クラスとして話されて居た箇所で、あえて名前を変えました。
うる覚えですが、なんかの本で
「Playerはゲームしている人自身で、応答が必要な時(DQのはい・いいえ等)にはＰｌａｙｅｒにメッセージを送る」
な設計を正としていたのを見た気がしたので･･･

1

javadoc にしてどっかにupしる。

>>1
おかえり。
俺も昔ＲＰＧを作ろうと思ってどういうクラスわけすればいいか悩んだから、
ここの話を参考にゲーム作ってみたい。

で、なんか>>100の内容はちょっと範囲が広すぎるから
範囲をせばめて話を進めたほうがいいんじゃね？
とりあえず今まで戦闘の話が多かったから戦闘の話とか。

漏れはjavadocよりクラス図とシーケンス図がみたい。

>とりあえず今まで戦闘の話が多かったから戦闘の話とか。

次の話題にいこうよ。

で、>>1はどこいったんだ？

すいませんすいません。
PG人足とはいえ、一応普通に働いてる人なので…

自分的には、「ゲームになってなくてもオブジェクト志向にこだわりたい」と想ってます。
上記をちゃんとクラス図に起こしたい気もしますが、その前に異論等、他の意見をききたかったです。

夢見がちな願望では、「オブジェクトの動きをウォッチするとゲーム画面ができる」っていう挙動が理想なのですが…

まとまってなくてすいません。

ウィンドウや、カーソルといったものも必要になるんじゃない？

>>107
「オブジェクトの動きをウォッチするとゲーム画面ができる」っていうのは違う気がする。
物事にはいろいろな側面があって、見る方向によって見え方が変わって当然。
こういうＲＰＧ（今回で言えばドラクエ１）をつくるっていう前提があるからというか、
その前提に立ってオブジェクトというか、クラス設計していくんじゃないのかな。
同じものでも視点が違えば（例えば武器屋のおっちゃんの視点から考えると）ぜんぜん違うものにならない？

そうですね、そうだと想います。

セオリーというモノを余り知らないヒヨッ子なもので、定番の視点がわかんないっす。

ただ、「見る方向によって…」という観点なら、>>107 は「>>100 はこういう視点でクラス抽出してます」という表明でしょうか。

「設計の『正しい』は人それぞれ」、「視点によって変わる」を前提に、他の考えも期待してます。＞皆様

> 同じものでも視点が違えば（例えば武器屋のおっちゃんの視点から考えると）ぜんぜん違うものにならない？
他の人がモデリングしたら違うはありだとおもうけど、他の登場人物から見た
ら違うってのは、客観的にうまいモデリングができてないってことじゃない？
システムとしての視点がずれてると、わかりにくく(他人が理解しにくく)なり
そう。

>1
ちなみに、絵を書くなら
http://objectclub.esm.co.jp/Jude/jude.html

>>111
武器屋のおっちゃんが主人公なゲームを作るとなると、経営シミュレーションゲームになるよね。
勇者も魔法使いもいらない。Customerだけ。モンスターに鉄斧売ってもいい。
いくらで仕入れていくらで売るか。在庫はいくらか。
製造もするなら原材料を仕入れて工場おさえて仕掛品の在庫管理も品質管理もせないかんね。
よーし。おっちゃん、隣の町にも出店しちゃうぞぉ。

>>113
用語してるのか、ヒニクってるのかわからん。
ここが、ﾂｰﾁｬｿﾈﾛというところか…

>>114
「他の登場人物から見たら違うってのは、客観的にうまいモデリングができてないってことじゃない？」では無いんじゃないの？
って意味です。

>>115
大まかに同意。
そうなんだよ。>>109 は いいたいことはあるんだろうが、例がおかしい。

静かになった。

で、どうなったの？

あがってきたので、記念かキコ
・オブジェクト間の通信。
abstract class  CommandBase {
  CommandOwner owner;
  public abstract void send();
}
// ターゲットが、１つ
abstract class SimpleCommand extends CommandBase {
  CommandObserver commandObserver;
  public void send(){
    commandObserver.doCommand( this );
  }
}
// ターゲットが、複数
abstract class MultiCastCommand extends CommandBase {
  ArrayList commandObservers;
  public void send(){
    Iterator it = commandObservers.iterator();
    while( it.hasNext() ){
      CommandObserver target = ( CommandObserver )it.next();
      target.doCommand( this );    
    }
  }
}
ゲーム内オブジェクト間で影響を及ぼしあう
MagicCommand, ItemCommand, SpeakCommand, MenuCommand
プレイヤーからのイベント
AButtonCommand, BButtonCommand, StartButtonCommand
周期的に変化をさせる
TimeCycleCommand

Command の実行は、間にDispather　をかまして、非同期にしたほうがいいかもしれない。

良スレだと思っていたのだが、止まっとるね。

あげ。

interface Pufpufable
{
____void Pufpuf(Target t);
}

Console.WriteLine("昨晩はお楽しみでしたね。");

ドラクエと言ったら３しか知らないけど
あの程度のインターフェイスならWEBアプリで作れるな
BCEで分けて今から作り始めるとするよ

>>124さんに期待

できたおー

(eval(read))

>>124さん
うpきぼんぬ。

Javaみたいだけどこれはどうだい

Javaでドラクエを再現する
ttp://f57.aaa.livedoor.jp/~javagame/rpg/dq.html

例えば勇者が魔王と戦う戦闘をプログラミングした場合、

勇者クラスに攻撃メソッドを
魔王に攻撃を受けるメソッドを作るのがいいのか

第三の全く別の戦闘クラスを作って値を仲介させたほうがいいのか　難しいところですね。

c初心者で意味不明だったらごめんなさい。

仲間になるモンスターをどうクラス化するのだろう、

>>130
俺は「第三の全く別の戦闘クラスを作って値を仲介させ」るやり方でやってる。
戦闘クラスに、主人公と敵のパラメータと、
プレイヤーが選択した行動（攻撃／呪文／道具／防御など）を渡して、
ダメージ計算やダメージを与えた結果などを、すべて戦闘クラスで処理してる。

>>131
宝箱を落とす確率と同じように、仲間になる確率というパラメータを、
モンスタークラスのメンバに持たせればよいのでは。
戦闘終了後に、その確率で仲間が増えるイベントを発生させる。
仲間を増やすのは、戦ってではなく、
普通に話しかけて仲間が増えるイベントと同じように作ればいい。

シューティングなんかもそうだけど
AとBの当たりを調べるのに
当たり判定クラスを作成してそこからAとBの公開メソッドを呼ぶな

当たり判定ルーチンはコンテナの外側に置きたいな
当たりデータはオブジェクトに付属させたいな
当たり判定ルーチンがキャラクターオブジェクトの公開メソッドになるのは嫌だな

>>132
実際にどうコーディングするかというよりも、オブジェクト指向でガチガチにRPGを
モデリングしたらどうなるか、というのがスレの趣旨だと思う。

そういう視点で見ると、勇者に攻撃、魔王に防御判定とダメージ処理メソッドを置く方がいいと俺は思う。

戦闘クラス（戦場クラス？）があってもスレの趣旨からは微塵も離れていないと思うんだが。

あらゆるアイテムやらモンスターやらをそれらの基本クラスから継
承させるととんでもない数のサブクラスが出来てえらいことになり
そう。ItemやMonsterだけがクラスで、挙動は継承に依らずに実装
するほうがいいのかな。

>>136
離れているとは誰も言っていない。
趣旨に沿うのであれば、135の方が俺は相応しいと思ったというだけ。

>>131
敵としてのスライムと、仲間になるスライムが、同じ１つのクラスである必要性はないと思うが。
別にしろってんじゃなくて、そういう選択肢もありかなと。

>勇者に攻撃、魔王に防御判定とダメージ処理メソッド
具体的にどんな感じ？
たとえばこう？

class 勇者{
　int 攻撃力;
　void 攻撃(魔王){
　　魔王.防御判定(攻撃力);
　}
}

class 魔王{
　int HP;
　int 守備力;
　void 防御判定(攻撃力){
　　HP -= 攻撃力 - 守備力;
　}
}

仕様も決めずに、プログラム書いて
デスマが待ってるのは、このスレですか？

ただの実装例だし、別にいいでしょ。

> int 攻撃力;

なんで知力が攻撃力なんだ? と素で15秒思考が止まった。

typedef int intellect;

//ところで、ドラクエは何の言語で書かれてるの？

//あの時代ならアセンブラとかじゃないの？

//律儀にコメントタグ、ﾜﾛｽ

/*
*アセンブラかぁ。
*何人月くらいかかるんだろー。
*/

このスレみたいにRPGを題材にして
クラス設計を勉強していく、

ゲームで学ぶOOP

売れるかな

RPGは選択ミスだと思われ。戦闘だけ作るならいいのかもしれんが。
「勇者クラス」とかはたまにOOPの教材にも出てくるしな。

ゲーム製作の基本の基本から解説していくなら教材になるかも
ただ本一冊で済みそうもないな

いろんな種類のゲームのクラス設計をＵＭＬで。
詳細な説明はいらんからとにかくいろんなパターンを紹介してくれるような本欲しいな。

>>150
結構いい題材だと思うけど。
アイテム、マップ、戦闘、ユーザーとのインターフェースなど題材は尽きない。
真面目に設計したらかなり実力がつくと思うぞ。

実際にRPGを作ろうとすると、RPGツクールをデザインせにゃならんからなー。
「勇者クラス」を作って「モンスタークラス」を作ってとか、そういう分かりやすい話にはならないと思うが。
もっとシンプルなゲーム、例えばインベーダー辺りのモデリング手法を書いた方が面白い本になると思う。

> 実際にRPGを作ろうとすると、RPGツクールをデザインせにゃならんからなー。
どういうこと？

>>155
チラシの裏
{

いわゆる開発支援ツールを通じて開発するということでしょ
「ぽりごなみえ」みたいな
}

>>156
そそ、そゆこと。

あーそういうことか。
漏れは設計することのみの本を考えてた。
実装までしようとしたらそりゃ大変だわな。

いや、開発環境も設計の段階で必要だと思うけど・・・。
プレイヤ視点でエンジン部分だけを設計でRPG作ろうとしても、多分途中でコケると思うぞ。

むしろRPGツクールをどうやって作ればいいかという設計を考えた方が、
実際のRPG制作の上では近道だと俺は思う。まぁ、俺は途中で頓挫したんだがorz

>>159
俺も挫折したタイプｗ

とりあえず、汎用的なエンジン／システムを作ってみよう、っていうスタンスだと恐らく完成しない。
明確な目的・需要があって作るのが良い。
その上でどこまで汎用的に設計するか決めるのが一番良いと経験的に思う。

>>159
なるほど。今までのこのスレの流れは間違ってたんだな。

面白そうだな。ここでそういう話をできないかな。

ここでの目的はドラクエか。
ドラクエといってもたくさんあるけどな。
1を継承して2を、2を継承して3を…と出来たらおもろいけどな。

現在進行形でＤＱクローンを作ってる俺が来ましたよ。
ゲーム本体とマップエディタとかを平行して作ってるけど、
汎用性なんて全く考えてない。というか余分な機能作る余裕ない。
最低限ＤＱとして必要な機能を実装するだけでも量が多くてアップアップですよ。

interface AI
{
BattleCommand DecideCommand(BattleStrategy strategy);
…
}

class クリフト implements AI
{
public BattleCommang DecideCommand(BattleStrategy strategy)
{
return ザラキ;
}
}

デスピサロ戦で1000回位全滅するとクリフトAIが
学習してザラキ唱えなくなるらしいよ。

>>164
ＷＡＲＡＴＡ

アイテムboxは一個しか持たなくていいから、クラス指向だと、シングルトン使ってもいいかもなー。

class ItemBox{//シングルトン
・・・
----------------
   List items;//アイテム袋の持ってる物と個数を管理
   BOOL Use(Actor&,ItemType);//アイテムの使用効果などを記述
   ItemBox GetInstance();//唯一のインスタンスを吐き出す。
---------------
・・・
}

class Hero :Actor{
・・・
-----------
 BOOL UseItem(ItemBox　IB){
              return IB.Use(this,yakusou);
 }
-----------
・・・
}


あ、仲間増えるとこれ使えないや。

パーティーを管理するクラスが必要じゃね？

オブジェクト間通信のいい見本って無いかな？？
クラスはなるべく一個ずつで完結して痛いわけなんだけど、
それじゃ、他のオブジェクトと通信が難しい。
うまい設計って無いかな？

>>クラスはなるべく一個ずつで完結して痛いわけなんだけど、 
クラスはなるべく一個ずつで完結していたいわけなんだけど、 

誤字すいません。

何が言いたいかよくわからん。一個ずつで完結って何だ？

他クラスへの依存性をなるべく減らしたいって話かなぁ

>>171
172のいうとおりで、なるべく再利用できる形で作っていきたいんです。（するかどうかはわからないけど、
今考えたのは、カプセル化して基礎を作って継承して２レイヤ目で通信機能を実装する方法。
バッシングされそうな設計なので、なんかいい方法ないかな？？
と、思ったのです。

クラス間通信っても、いろいろあるべや。
集約だったらその方法は使えないし。

パッケージ単位で完結するようにすればいいでは。

>>168
DQ1は一人旅。
DQ2は3人で、DQ3は4人。

class party{
 List Members;//重複禁止だからMapの方がいいかもしれない。
 BOOL Uniqe();
 Actor& Search(string);//名前で検索。
 Actor& Search(int); //x番目で検索。
 BOOL Join(Actor&);//追加。
 BOOL Leave(string);//削除by名前
 BOOL Leave(int);//削除by　X番目。
}

ほかに何かあったっけ？

 
 

>>174
パッケージ単位にしても、うまい切り分けができないと難しいなぁ。
パッケージっていうと、ほとんど完成したアプリケーションしか思い浮かばない。OTL
うーん。
うまい切り分けを考えて、インターフェース指向を考えたんだけど、
これがなかなか、うまくマッチしないんだよなぁ。（勉強不足も否めないが。
ex.コンソールとGDIとDirectXにマッチするようなインターフェースを基本機能に絞って記述。
コンソールで開発して、Dxでリリースとかしたかった。
って、与太話になってるな。
ま、切り分けはセンスってことで、センスを磨くようにするなり。
サンキュー

>>176
Observerパターンとかどうだろう？

>>177
提案ありがとう。
検討してみる。

うおぉーーーーーーりゃぁーーーーーーーーーーー

http://p5057-ipad03aobadori.miyagi.ocn.ne.jp/
うぇｗｗｗうぇｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ
うぇｗｗｗ
っうぇｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗおｋｗｗｗ

もうだめだーｗ

http://YahooBB218124060027.bbtec.net/
ｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗｗｗうはっｗｗｗうはっｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗっ

おｋｗｗｗ

っうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗ

ドラクエ自体アセンブラなのにオブジェクト指向で作られてるって聞いたけどな

まぁどの言語だってオブジェクト指向はできるわな

>>183
> ドラクエ自体アセンブラなのに

ドラクエってアセンブラだったのか。。。
アセンブリ言語で開発されてんじゃなくて、ドラク自体がアセンブラなんだよな？

むしろアセンブラがドラクエ

age

ロトってroot?

たしか、Roto という綴をサントラCDで見た希ガス。