オブジェクト指向でドラクエ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG「オブジェクト指向の視点から、ドラゴンクエストを考えてみよう」という趣旨のスレです。
子供の頃やったドラクエを、オブジェクト指向で捉えた場合どんな設計で作るのかに興味を持ちました。
ＲＰＧだって「現実世界をゲーム上でシミュレート」なんだから、相性はいいはずです。
オブジェクト指向で分析すればどんなカタチになるか、面白そうじゃないですか？
「勇者はどんなクラス」とか、「マップはどう表現しよう」とか、
はたまた「このイベントはユースケースではどんなものになるんだろう」
みたいな討議をしていきましょう。
もちろん”車輪の再開発”で”妄想”なスレです。成果などは期待しません。
「言いだしっぺの法則で成果物出せやｺﾞﾗｧ」系のあおりは無しの方向で。
基本的には、ＤＱⅠをターゲットにします（昨今のは煩雑になりがちなので）
が、それ以外のＤＱシリーズや、転じて２ＤＲＰＧ全体に対しても、扱っていっても良いかと思います。
実装例などを出す場合には、言語は問いませんが、基本はJavaでおながいします。
(わかる人が多いと思うので。)
じゃぁ、みんなお願いね。
System.out.println("へんじがない。ただのしかばねのようだ。");
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNGハイドライド、ザナドゥ、ブラックオニキス、ファイアーストーンなどです
ドラクエなんてありませんでした
0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG板違いです。
ゲーム製作技術板
http://pc5.2ch.net/gamedev/
0006デフォルトの名無しさん
NGNGアーストレック、表参道アドベンチャー、南青山アドベンチャーでした。
ドラクエなんてありませんでした。
0007デフォルトの名無しさん
NGNGpublic class Braver extends Actor {
public String speak() {
if ( Math.random() > 0.5 ) {
return "はい";
} else {
return "いいえ";
}
}
}
(-Ａ-)あ～もう、これでいいすか？
0008デフォルトの名無しさん
NGNGスカッシュ、ブロックくずし、インベーダーでした。
ドラクエなんてありませんでした。
0009デフォルトの名無しさん
NGNG北朝鮮では大人がやらされるそうです。
0010デフォルトの名無しさん
NGNG（この板の人はﾋﾏじゃないのか…）
0011デフォルトの名無しさん
NGNG"当店は最高のサービスをお客様に提供することをモットーとしております。",
"はぁ? 金持ってねえならさっさと野垂れ死ねや!"
);
0012デフォルトの名無しさん
NGNG0013デフォルトの名無しさん
NGNGUINT Hp;
void HpDec(Damage);
boolean TellDie();
};
0014デフォルトの名無しさん
NGNG0015デフォルトの名無しさん
NGNGpublic void fight(){};
public void magic(){};
public void escape(){};
}
0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNG0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNGFightAbleインターフェイスを作るってことを。
勇者は当然、２以降からのパーティバトルでのプレイヤーキャラとか。
モンスターもこのインターフェイスを実装する。
メソッドは…どうしようかな。
0021デフォルトの名無しさん
NGNGリファクタリングしたコードをうｐしてください。
0023デフォルトの名無しさん
NGNG0024デフォルトの名無しさん
NGNGバトル可能なキャラオブジェクトのメソッド・パラメタは定型なもので、
バトルマスターっていうかジャッジメンターみたいなオブジェクトがいて、
そいつが実際の「たたかい」のコントロール(闘う順番、ダメージ通知とか)
をするんかな。
経験者様もいらっしゃるみたいですが。
おしえて、エロい人！
0025デフォルトの名無しさん
NGNG00261
NGNG>>5 , >>2
ゲーム作るっていうのじゃなく、分析したらどうなるの？的なスレにしたかったのですが。
例えば、職業SEの方々は「業務」の部分をモデル化して、クラス抽出で、実装じゃないですか。
その分析対象である「業務」部分が、誰でも知ってるもの（でドラクエ）なら、
今から設計の世界に入る技術者さんにも、良いリファレンスモデルになるのではないかと。
OOの入門書に「車を例に…」なんて多く出てくるところから、それよりも解りやすかろうと。
ゲ板で「クラス抽出を…」とかの話って出てくるんですかね？
はたまた「JAVAでシューティング作る～」スレもム板にあることですし、
って言うのは都合の良い考え方ですかそうですか。
0027デフォルトの名無しさん
NGNGhttp://pc5.2ch.net/test/read.cgi/gamedev/1075636615/
0028デフォルトの名無しさん
NGNGあくまでもゲームを作ることが目的なんじゃなくて、
データ構造などを、オブジェクト指向的に表現したらどうなるかって話でしょ。
とりあえず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("それを すてるなんて とんでもない！");
}
}
}
0029デフォルトの名無しさん
NGNGpublic 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;
}
}
0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNGスライムベスを継承したメタルスライム。
スライムを継承したバブルスライム。
スライムを継承したホイミスライム。
キングスライム、メタルキング、スライムベホマズン・・・以下略
課題。
スライム属の全ての継承関係を作れ。
0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG↓
HSP＝糞
↓
onionsoftのTOPの物体＝スライムのパクリ
↓
両方とも糞
↓
HSP＝ドラクエ
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNGclass Yuusya {
List itemList;
void getItem(Item item) {
}
void dropItem(Item item) {
}
}
とかじゃあ、うまくいかんなあ。
あと、Itemを店で金払って買うっていう行動。
どう設計すんだろ？
0036デフォルトの名無しさん
NGNG0037デフォルトの名無しさん
NGNGList 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("おや、お金が足りないようですね");
}
}
}
0038デフォルトの名無しさん
NGNGオブジェクト指向がアダになるっつーか、
アイテムは単なる数値配列で持ったほうがラクじゃね？
0039デフォルトの名無しさん
NGNGせめて、キャラクタ共通の行動と道具の効果とシナリオ中のイベントの効果を
明確にしなければ、プロトコルを決めようがないじゃん。
0040デフォルトの名無しさん
NGNGオーサリングされたシナリオと、それを読み込んで動くプレイヤー
という構造にしかならない。
0041デフォルトの名無しさん
NGNGそれぞれシナリオからパラメータを読み込んでインスタンスとして生成する
ということになる。
野外マップ・ダンジョンマップ・街マップという
大体三つくらいのデータオブジェクトの固まりがあって、
エンカウントするモンスターの種類や数は野外マップオブジェクトの
各スクェアに書き込まれる属性。
モンスターは全部Monsterというひとつのクラスで表現され、
それぞれが名前、HP、MPや呪文／特殊能力の種類、強度、発動率などの
データを属性として持つインスタンスとして戦闘発生時に生成される。
0042デフォルトの名無しさん
NGNGそれじゃ、Cで敵キャラ用の関数をmonster.cに書くのと何の変わりもないね。
全然OOにする意味無し。
0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNGルーチンワークなシナリオゲームにしかならないと。
0045デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0046デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0047デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0048デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0049デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0050デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0051デフォルトの名無しさん
NGNGシナリオ性が無くなるけど。
0052デフォルトの名無しさん
NGNGclass 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();
}
}
0053デフォルトの名無しさん
NGNG0054デフォルトの名無しさん
NGNG0055デフォルトの名無しさん
NGNG例外でオチたりしない。まぁ最近はCD-ROMとかメモカとかあるけど。
デバグ用にエラー検出コードは入れるけど。
0056デフォルトの名無しさん
NGNG0057デフォルトの名無しさん
NGNGclass Shop {
List itemList;
List showItemList() {
return itemList;
}
//売る。
Item sell(Item item) {
return item;
}
//買い取る
void buy(Item item) {
}
}
これをどうやってPlayerクラスと使うかだな。
Itemを店に下取りに出したとき、確実にPlayerからそのアイテムが
無くなってなきゃいけない。
あと金の受け渡しはどうやる？
0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNG0060デフォルトの名無しさん
NGNG違いってなにか、教えてください
0061デフォルトの名無しさん
NGNG0062デフォルトの名無しさん
NGNG馬鹿。エラー⊂例外だろ
0063デフォルトの名無しさん
NGNGとりあえず、interface Shoppingable でも規定した方がいいんでないか？
0064デフォルトの名無しさん
NGNGtradableにでもしとけ。buyableとsellableに分離してもいいな。
あと武器用にもoffensiveとdefensiveも定義しる。
0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNGintarface IDroppable {
boolean isDropped();
int getMoney();
IEnumerable getItems();
}
キャラクターと PlayerControllable は分離した方が良くないか？
class PlayerChara extends Character implements IPlayerControllable
つー感じで
0067デフォルトの名無しさん
NGNGうらやましいと感じてる、ゲームプログラマのオレ。
0068デフォルトの名無しさん
NGNG0069はぐれメタﾉﾚ
NGNG0070デフォルトの名無しさん
NGNG>>キャラクターと PlayerControllable は分離した方が良くないか？
なぜ？
007166じゃないが
NGNGプレーヤーのキャラ選択でキャラにプレーヤーがつくのとつかないのとあるじゃん。
同じオブジェクトで表現したければ、クラスとしてはキャラで、プレーヤからの操作は
インターフェースで宣言するのがいいと思うが。
0072デフォルトの名無しさん
NGNG0073デフォルトの名無しさん
NGNG0074デフォルトの名無しさん
NGNGモンスターやNPCもキャラクターClassの派生だと考えれば、プレーヤーのキャラ自体は
ユーザーが制御可能であるという点で特徴づけられるから
0075デフォルトの名無しさん
NGNGドラクエ１形式を考えると、共通のキャラクタークラスを用意するより１つのインターフェイスを定義した方がいいんじゃないのかな。
モンスターはマップに出てこないからまた別だと思う。
0076デフォルトの名無しさん
NGNGDQ2 を作るときに資源を活用できるようにだろ。次スレがDQ2か？
0077デフォルトの名無しさん
NGNG> 次スレがDQ2か？
だいぶ先は長いがな。あと925レスか。
0078デフォルトの名無しさん
NGNGそれは View レベルの問題だと思われ
OOとしての設計ではないと思うんだが、モンスターもPCもHPやらアビリティを持っている
訳で、そこらへんは統一した実装クラスにまとめておいた方が管理上、楽でしょ
マップとして必要なエリアにきたら、データからアクティベートしてエンカウント計算して
遭遇時にマップ上に表示すりゃいいわけで
って、何まじになってんだろ、漏れorz
0079デフォルトの名無しさん
NGNGみたいに
>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{
};
みたいに行動ごとにクラス用意したほうが敵の攻撃方法をランダムに選ぶ時によくない？
0080デフォルトの名無しさん
NGNG戦闘用のインターフェースを定義して、キャラクターやモンスターのクラス
で実装する時に、各攻撃手段や呪文などをCommandパターンで実装する
のが定石だろうな。
008179
NGNG>戦闘用のインターフェースを定義して、キャラクターやモンスターのクラス
>で実装する時に、各攻撃手段や呪文などをCommandパターンで実装する
>のが定石だろうな。
ってのは、
interface Fighter{
void onAttacked(Action action);
};
Action someAction = 勇者.getSelectedAction();
スライム.onAttacked(someAction);
って感じ？
0082デフォルトの名無しさん
NGNG薬草を使いたいときはどうすんだ？
0083デフォルトの名無しさん
NGNGいってしもたらつらいけど。
008479
NGNGYakusou implements Item, Action{
};
Action someAction = getSelectedAction();//薬草インスタンスを返す
Character someTarget = getSelectedTarget();//ターゲット(自分)を返す
someTarget.onAttacked(someAction);
ってな感じか？onAttackedは別の名前にすべきだと思うけど。
0085デフォルトの名無しさん
NGNG「薬草」というアイテム自体と「薬草を使う」という行為は
別オブジェクトにしたほうがいいな。
薬草の効果や商品価値などはそれぞれの薬草固有だし、
「薬草を使う」という行為と直接関係ないから。
それとは独立して「薬草を使う」「薬草を買う」等の行為を
それぞれオブジェクトにまとめるのがいい。
その上で、「使う」「買う」などを抽象クラスにすればいいのでは？
0086デフォルトの名無しさん
NGNG薬草を「買う」のと武器を「買う」のは同じinterfaceだよね。
008779
NGNG>「薬草」というアイテム自体と「薬草を使う」という行為は
>別オブジェクトにしたほうがいいな。
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);
}
};
という感じか？薬草オブジェクトから「使う」オブジェクトがもらえるのは違和感ないけど、
「買う」オブジェクトがあるのは違和感あるな。
0088デフォルトの名無しさん
NGNGvoid use(Unit target){
のところは
void use(ＨＰ回復可能なインターフェイス target)
ってところか。
008979
NGNG自分でコード書いておいてなんだが、対象がないアイテムもあるだろうから、
interface UseProcedure{
void use();
};
class YakusouUseProcedure implements UseProcedure{
YakusouUseProcedure(Healable target);
void use();
};
のほうがいいかな、と思った。
それとも「使う」のインターフェースを対象別に分けるべきかね？
0090デフォルトの名無しさん
NGNGとかしたいよね。
void use(Healable item)
void use(あと何使うんだable item)
0091デフォルトの名無しさん
NGNGvoid affair(Chara chara);
void affiar(Enemy enemy);
...
}
とかにした方がいいんでないか？
0092デフォルトの名無しさん
NGNGinterface Healable じゃなくってってこと？
0093デフォルトの名無しさん
NGNGなんか勇者.use(...)は関係が密すぎる感じがする。
アイテムを使うのも、攻撃するのも、魔法を使うのも
メソッドじゃなくて、同じインターフェースを持ったオブジェクトにまとめたほうがよくね？
>>91
対象のオブジェクトによって動作を変えるためにメソッド二つ用意するくらいなら、
CharaとEnemyに同一スーパークラスを持たせて、
affairメソッド内でinstanceofで動作を変えるべきじゃない？
0094デフォルトの名無しさん
NGNG明示的に処理を行いたいときがあるかな、と思ってね
しかし、こういうときほど多重継承のありがたみがわかるなぁ（ｗ
0095デフォルトの名無しさん
NGNG> しかし、こういうときほど多重継承のありがたみがわかるなぁ（ｗ
それはちょっと間違って(ry
0096デフォルトの名無しさん
NGNGそういうところでinstanceofは使うべきじゃないと思うな。if else if else if else if ......
0097デフォルトの名無しさん
NGNGいや、実際、これまでの話の中で何度か「それは多重継承すればいいんじゃないか」と
思ってね
0098デフォルトの名無しさん
NGNG> affairメソッド内でinstanceofで動作を変えるべきじゃない？
せめてダブルディスパッチしてくれい…
00991
NGNGいやー、地下でスレ伸びててびっくりしました。集ってる方感謝っす。
途中、ケンモホロロに追い返されたので、素直にゲ板いってそれ系のスレ見てました。
さて、勢い出たんで、このスレ立てた時に考えたクラス体系を、
皆さんのやりかたを加味して書きたいと思います。
(一笑に伏された後、だれかがもっと良いのを出してくるのを期待してます)
01001
NGNGObject
├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 - 逃げる。(隊列先頭の奴に強制的に付加されるって、なぁ)
└[その他] - 昨今のドラクエの"とくぎ"など。
01011
NGNGBattleable - 戦闘ができる。Hp,Mp,つよさ全般のパラメータはここに含まれる。
Controlable - 戦闘時自分で操れる。
BattleUse - Item、Magicに任意で実装。戦闘中に使える。
FieldUse - Item、Magicに任意で実装。フィールドで使える。
EventUse - Itemに任意で実装。捨てられない。使うと無くなるなど。
Tradable - Peopleに実装。Shopから買うのではなくて売買資格のある人から買う、という概念で。
01021
NGNGMainActor,Enemyごとにメソッドとして実装したほうがいいのかな。
コントローラ的なものが居るって、なんか正しくないんでしたっけ？
あと職業の概念をどこにも入ってないっすね。
ああ･･･叩きどころは満載ですのでたたき台ということでどうか一つ…
MainActorは、みんなが"Player"クラスとして話されて居た箇所で、あえて名前を変えました。
うる覚えですが、なんかの本で
「Playerはゲームしている人自身で、応答が必要な時(DQのはい・いいえ等)にはＰｌａｙｅｒにメッセージを送る」
な設計を正としていたのを見た気がしたので･･･
0103デフォルトの名無しさん
NGNGjavadoc にしてどっかにupしる。
0104デフォルトの名無しさん
NGNGおかえり。
俺も昔ＲＰＧを作ろうと思ってどういうクラスわけすればいいか悩んだから、
ここの話を参考にゲーム作ってみたい。
で、なんか>>100の内容はちょっと範囲が広すぎるから
範囲をせばめて話を進めたほうがいいんじゃね？
とりあえず今まで戦闘の話が多かったから戦闘の話とか。
漏れはjavadocよりクラス図とシーケンス図がみたい。
0105デフォルトの名無しさん
NGNG次の話題にいこうよ。
0106デフォルトの名無しさん
NGNG01071
NGNGPG人足とはいえ、一応普通に働いてる人なので…
自分的には、「ゲームになってなくてもオブジェクト志向にこだわりたい」と想ってます。
上記をちゃんとクラス図に起こしたい気もしますが、その前に異論等、他の意見をききたかったです。
夢見がちな願望では、「オブジェクトの動きをウォッチするとゲーム画面ができる」っていう挙動が理想なのですが…
まとまってなくてすいません。
0108デフォルトの名無しさん
NGNG0109デフォルトの名無しさん
NGNG「オブジェクトの動きをウォッチするとゲーム画面ができる」っていうのは違う気がする。
物事にはいろいろな側面があって、見る方向によって見え方が変わって当然。
こういうＲＰＧ（今回で言えばドラクエ１）をつくるっていう前提があるからというか、
その前提に立ってオブジェクトというか、クラス設計していくんじゃないのかな。
同じものでも視点が違えば（例えば武器屋のおっちゃんの視点から考えると）ぜんぜん違うものにならない？
01101
NGNGセオリーというモノを余り知らないヒヨッ子なもので、定番の視点がわかんないっす。
ただ、「見る方向によって…」という観点なら、>>107 は「>>100 はこういう視点でクラス抽出してます」という表明でしょうか。
「設計の『正しい』は人それぞれ」、「視点によって変わる」を前提に、他の考えも期待してます。＞皆様
0111デフォルトの名無しさん
NGNG他の人がモデリングしたら違うはありだとおもうけど、他の登場人物から見た
ら違うってのは、客観的にうまいモデリングができてないってことじゃない？
システムとしての視点がずれてると、わかりにくく(他人が理解しにくく)なり
そう。
0112デフォルトの名無しさん
NGNGちなみに、絵を書くなら
http://objectclub.esm.co.jp/Jude/jude.html
0113デフォルトの名無しさん
NGNG武器屋のおっちゃんが主人公なゲームを作るとなると、経営シミュレーションゲームになるよね。
勇者も魔法使いもいらない。Customerだけ。モンスターに鉄斧売ってもいい。
いくらで仕入れていくらで売るか。在庫はいくらか。
製造もするなら原材料を仕入れて工場おさえて仕掛品の在庫管理も品質管理もせないかんね。
よーし。おっちゃん、隣の町にも出店しちゃうぞぉ。
0114デフォルトの名無しさん
NGNG用語してるのか、ヒニクってるのかわからん。
ここが、ﾂｰﾁｬｿﾈﾛというところか…
0116デフォルトの名無しさん
NGNG大まかに同意。
そうなんだよ。>>109 は いいたいことはあるんだろうが、例がおかしい。
0117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
NGNG0119デフォルトの名無しさん
NGNG・オブジェクト間の通信。
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
0120119
NGNG0121デフォルトの名無しさん
NGNG0122デフォルトの名無しさん
NGNG0123デフォルトの名無しさん
NGNG{
____void Pufpuf(Target t);
}
Console.WriteLine("昨晩はお楽しみでしたね。");
0124デフォルトの名無しさん
05/01/18 21:32:20あの程度のインターフェイスならWEBアプリで作れるな
BCEで分けて今から作り始めるとするよ
0125デフォルトの名無しさん
05/01/20 00:59:290126124
05/01/20 19:41:560127デフォルトの名無しさん
05/01/21 05:11:050128デフォルトの名無しさん
05/01/22 02:09:40うpきぼんぬ。
0129デフォルトの名無しさん
05/02/04 08:37:27Javaでドラクエを再現する
ttp://f57.aaa.livedoor.jp/~javagame/rpg/dq.html
0130デフォルトの名無しさん
2005/05/01(日) 18:15:44勇者クラスに攻撃メソッドを
魔王に攻撃を受けるメソッドを作るのがいいのか
第三の全く別の戦闘クラスを作って値を仲介させたほうがいいのか 難しいところですね。
c初心者で意味不明だったらごめんなさい。
0131デフォルトの名無しさん
2005/05/01(日) 18:18:250132デフォルトの名無しさん
2005/05/01(日) 23:51:54俺は「第三の全く別の戦闘クラスを作って値を仲介させ」るやり方でやってる。
戦闘クラスに、主人公と敵のパラメータと、
プレイヤーが選択した行動（攻撃／呪文／道具／防御など）を渡して、
ダメージ計算やダメージを与えた結果などを、すべて戦闘クラスで処理してる。
>>131
宝箱を落とす確率と同じように、仲間になる確率というパラメータを、
モンスタークラスのメンバに持たせればよいのでは。
戦闘終了後に、その確率で仲間が増えるイベントを発生させる。
仲間を増やすのは、戦ってではなく、
普通に話しかけて仲間が増えるイベントと同じように作ればいい。
0133デフォルトの名無しさん
2005/05/02(月) 00:04:24AとBの当たりを調べるのに
当たり判定クラスを作成してそこからAとBの公開メソッドを呼ぶな
0134デフォルトの名無しさん
2005/05/02(月) 00:28:36当たりデータはオブジェクトに付属させたいな
当たり判定ルーチンがキャラクターオブジェクトの公開メソッドになるのは嫌だな
0135デフォルトの名無しさん
2005/05/02(月) 06:56:57実際にどうコーディングするかというよりも、オブジェクト指向でガチガチにRPGを
モデリングしたらどうなるか、というのがスレの趣旨だと思う。
そういう視点で見ると、勇者に攻撃、魔王に防御判定とダメージ処理メソッドを置く方がいいと俺は思う。
0136デフォルトの名無しさん
2005/05/02(月) 07:00:490137デフォルトの名無しさん
2005/05/02(月) 08:44:31承させるととんでもない数のサブクラスが出来てえらいことになり
そう。ItemやMonsterだけがクラスで、挙動は継承に依らずに実装
するほうがいいのかな。
0138デフォルトの名無しさん
2005/05/02(月) 19:48:22離れているとは誰も言っていない。
趣旨に沿うのであれば、135の方が俺は相応しいと思ったというだけ。
0139デフォルトの名無しさん
2005/05/02(月) 22:02:21敵としてのスライムと、仲間になるスライムが、同じ１つのクラスである必要性はないと思うが。
別にしろってんじゃなくて、そういう選択肢もありかなと。
0140デフォルトの名無しさん
2005/05/03(火) 16:30:50具体的にどんな感じ？
たとえばこう？
class 勇者{
int 攻撃力;
void 攻撃(魔王){
魔王.防御判定(攻撃力);
}
}
class 魔王{
int HP;
int 守備力;
void 防御判定(攻撃力){
HP -= 攻撃力 - 守備力;
}
}
0141デフォルトの名無しさん
2005/05/03(火) 16:38:03デスマが待ってるのは、このスレですか？
0142デフォルトの名無しさん
2005/05/03(火) 17:52:240143デフォルトの名無しさん
2005/05/03(火) 18:12:04なんで知力が攻撃力なんだ? と素で15秒思考が止まった。
0144デフォルトの名無しさん
2005/05/03(火) 19:04:410145デフォルトの名無しさん
2005/05/03(火) 20:40:290146デフォルトの名無しさん
2005/05/03(火) 21:02:210147デフォルトの名無しさん
2005/05/03(火) 21:13:560148デフォルトの名無しさん
2005/05/03(火) 21:51:28*アセンブラかぁ。
*何人月くらいかかるんだろー。
*/
0149デフォルトの名無しさん
2005/05/03(火) 22:44:51クラス設計を勉強していく、
ゲームで学ぶOOP
売れるかな
0150デフォルトの名無しさん
2005/05/03(火) 23:24:44「勇者クラス」とかはたまにOOPの教材にも出てくるしな。
0151デフォルトの名無しさん
2005/05/04(水) 00:15:16ただ本一冊で済みそうもないな
0152デフォルトの名無しさん
2005/05/04(水) 00:18:28詳細な説明はいらんからとにかくいろんなパターンを紹介してくれるような本欲しいな。
0153デフォルトの名無しさん
2005/05/04(水) 00:46:29結構いい題材だと思うけど。
アイテム、マップ、戦闘、ユーザーとのインターフェースなど題材は尽きない。
真面目に設計したらかなり実力がつくと思うぞ。
0154デフォルトの名無しさん
2005/05/04(水) 02:20:30「勇者クラス」を作って「モンスタークラス」を作ってとか、そういう分かりやすい話にはならないと思うが。
もっとシンプルなゲーム、例えばインベーダー辺りのモデリング手法を書いた方が面白い本になると思う。
0155デフォルトの名無しさん
2005/05/04(水) 02:28:44どういうこと？
0156デフォルトの名無しさん
2005/05/04(水) 02:37:48チラシの裏
{
いわゆる開発支援ツールを通じて開発するということでしょ
「ぽりごなみえ」みたいな
}
0157デフォルトの名無しさん
2005/05/04(水) 02:39:53そそ、そゆこと。
0158155
2005/05/04(水) 02:45:42漏れは設計することのみの本を考えてた。
実装までしようとしたらそりゃ大変だわな。
0159デフォルトの名無しさん
2005/05/04(水) 02:48:24プレイヤ視点でエンジン部分だけを設計でRPG作ろうとしても、多分途中でコケると思うぞ。
むしろRPGツクールをどうやって作ればいいかという設計を考えた方が、
実際のRPG制作の上では近道だと俺は思う。まぁ、俺は途中で頓挫したんだがorz
0160デフォルトの名無しさん
2005/05/04(水) 06:09:15俺も挫折したタイプｗ
とりあえず、汎用的なエンジン／システムを作ってみよう、っていうスタンスだと恐らく完成しない。
明確な目的・需要があって作るのが良い。
その上でどこまで汎用的に設計するか決めるのが一番良いと経験的に思う。
0161デフォルトの名無しさん
2005/05/04(水) 08:16:05なるほど。今までのこのスレの流れは間違ってたんだな。
面白そうだな。ここでそういう話をできないかな。
0162デフォルトの名無しさん
2005/05/04(水) 09:06:36ドラクエといってもたくさんあるけどな。
1を継承して2を、2を継承して3を…と出来たらおもろいけどな。
0163デフォルトの名無しさん
2005/05/04(水) 11:45:55ゲーム本体とマップエディタとかを平行して作ってるけど、
汎用性なんて全く考えてない。というか余分な機能作る余裕ない。
最低限ＤＱとして必要な機能を実装するだけでも量が多くてアップアップですよ。
0164デフォルトの名無しさん
2005/05/04(水) 12:29:09{
BattleCommand DecideCommand(BattleStrategy strategy);
…
}
class クリフト implements AI
{
public BattleCommang DecideCommand(BattleStrategy strategy)
{
return ザラキ;
}
}
0165デフォルトの名無しさん
2005/05/04(水) 13:14:06学習してザラキ唱えなくなるらしいよ。
0166デフォルトの名無しさん
2005/05/04(水) 15:17:09ＷＡＲＡＴＡ
0167デフォルトの名無しさん
2005/05/04(水) 15:30:29class ItemBox{//シングルトン
・・・
----------------
List items;//アイテム袋の持ってる物と個数を管理
BOOL Use(Actor&,ItemType);//アイテムの使用効果などを記述
ItemBox GetInstance();//唯一のインスタンスを吐き出す。
---------------
・・・
}
class Hero :Actor{
・・・
-----------
BOOL UseItem(ItemBox IB){
return IB.Use(this,yakusou);
}
-----------
・・・
}
あ、仲間増えるとこれ使えないや。
0168デフォルトの名無しさん
2005/05/04(水) 15:45:320169デフォルトの名無しさん
2005/05/04(水) 15:45:40クラスはなるべく一個ずつで完結して痛いわけなんだけど、
それじゃ、他のオブジェクトと通信が難しい。
うまい設計って無いかな？
0170デフォルトの名無しさん
2005/05/04(水) 15:47:14クラスはなるべく一個ずつで完結していたいわけなんだけど、
誤字すいません。
0171デフォルトの名無しさん
2005/05/04(水) 15:56:390172デフォルトの名無しさん
2005/05/04(水) 15:58:120173デフォルトの名無しさん
2005/05/04(水) 16:17:35172のいうとおりで、なるべく再利用できる形で作っていきたいんです。（するかどうかはわからないけど、
今考えたのは、カプセル化して基礎を作って継承して２レイヤ目で通信機能を実装する方法。
バッシングされそうな設計なので、なんかいい方法ないかな？？
と、思ったのです。
0174デフォルトの名無しさん
2005/05/04(水) 16:21:53集約だったらその方法は使えないし。
パッケージ単位で完結するようにすればいいでは。
0175デフォルトの名無しさん
2005/05/04(水) 16:30:49DQ1は一人旅。
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番目。
}
ほかに何かあったっけ？
0176デフォルトの名無しさん
2005/05/04(水) 16:56:44パッケージ単位にしても、うまい切り分けができないと難しいなぁ。
パッケージっていうと、ほとんど完成したアプリケーションしか思い浮かばない。OTL
うーん。
うまい切り分けを考えて、インターフェース指向を考えたんだけど、
これがなかなか、うまくマッチしないんだよなぁ。（勉強不足も否めないが。
ex.コンソールとGDIとDirectXにマッチするようなインターフェースを基本機能に絞って記述。
コンソールで開発して、Dxでリリースとかしたかった。
って、与太話になってるな。
ま、切り分けはセンスってことで、センスを磨くようにするなり。
サンキュー
0177デフォルトの名無しさん
2005/05/04(水) 17:32:57Observerパターンとかどうだろう？
0178デフォルトの名無しさん
2005/05/04(水) 18:30:59提案ありがとう。
検討してみる。
0179デフォルトの名無しさん
2005/05/06(金) 22:14:260180デフォルトの名無しさん
2005/05/06(金) 22:16:36うぇｗｗｗうぇｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ
うぇｗｗｗ
っうぇｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗおｋｗｗｗ
0181デフォルトの名無しさん
2005/05/07(土) 21:44:060182デフォルトの名無しさん
2005/05/07(土) 21:57:45ｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗｗｗうはっｗｗｗうはっｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗっ
おｋｗｗｗ
っうはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗ
0183デフォルトの名無しさん
2005/05/10(火) 03:50:140184デフォルトの名無しさん
2005/05/10(火) 22:58:460185デフォルトの名無しさん
2005/05/11(水) 04:30:03> ドラクエ自体アセンブラなのに
ドラクエってアセンブラだったのか。。。
アセンブリ言語で開発されてんじゃなくて、ドラク自体がアセンブラなんだよな？
0186デフォルトの名無しさん
2005/05/15(日) 19:56:160187デフォルトの名無しさん
2005/06/06(月) 22:56:180188デフォルトの名無しさん
2005/08/12(金) 23:22:410189デフォルトの名無しさん
2005/08/13(土) 03:20:15■ このスレッドは過去ログ倉庫に格納されています