ゲーム(RPG)のベースクラス設計を考える

キャラクター、フィールドなどのクラスの設計、データ構造、アルゴリズムなど。
もう少し踏み込んで、ストーリー内でのイベント、アイテム... と、やるべきことは
たくさんありますが、皆さんはどのように設計していらっしゃいますか？

みんなで一緒に雛型、あるいは枠組みを考えてみませんか。

あまりにも漠然としているので、まずはこんなテーマはどうでしょうか。
「フィールド上を歩く ＆ 敵と遭遇」
・フィールド、マップ
・フィールド上のキャラクター

マップというか「ゲーム世界」自体のクラス化は簡単だけど、
マップ表示は意外に難しいんですよね....。プラットフォームの
表示機能に依存するからクラスというより「コンポーネント」
を作る必要がある。

今、シューティングゲームをクラス化しているんですが、この
クラスも、「メインウインドウを作成しそのデバイスコンテキ
ストをゲームクラスに渡す」メインプログラムで駆動していま
す（プラットフォームはWin32で32ビットDIBのバックバッファ
を描画）。
ゲームの場合、「ゲームを駆動し画面を描画するメインゲーム
クラス」を作るよりクラス階層の「外」のメインプログラムで
駆動するようにした方が、結局楽なのかも。

構造としてはゲームの「状態」（＝モデル）をクラス化して、
そこで各種のデータやイベント処理機能を定義、そしてそれら
のクラスのインスタンスで表現される「世界」をメインプログ
ラムで駆動・描画、という形にすると比較的作りやすそう。

スクリプトの設計も話題に加えるべし。

スクリプトってあった方が便利なんだけど
いざ作ろうと思うと何を盛り込めばいいか分からなくて悩むね

最初から全部スクリプトで組めば問題ない？RubyとかPythonとか。
え？スクリプトの意味が違う？

　　ユーザー
　　│　↑
┌─↓─┴─┐
│入出力制御│
└↑──↑─┘
　Ａ　　Ａ
　│┌─┴───┐　┌─────┐
　││フロー制御←Ｄ→フロー制御│
　│└─┬─↑─┘　└─────┘
　│　　Ｂ　Ｃ
┌┴──↓─┴─────┐
│パラメータ・フラグ管理│
└───────────┘

Ａ）入力の監視・メッセージ・画像・音声の出力指示。
Ｂ）入力・判定結果に応じてパラメータの増減を指示。
Ｃ）キャラの死亡などをイベントで通知。
Ｄ）必要に応じて他のフロー制御サブシステムをコールor制御を移す。
　【例】フィールド画面→戦闘画面

■入出力制御サブシステム
各種入出デバイスの制御、ウィンドウ・グラフィック、メッセージの描画、
BGM・SEの演奏を制御する。

■パラメータ・フラグ管理
キャラクターのステータスやアイテム・フラグの管理。
ステータスウィンドウ・ステータス画面も管轄内。
セーブ・ロードの必要があるものは全てココにまとめる。

■フロー制御サブシステム
ゲームの流れを制御する。
全体の流れを制御する。
スクリプト及び、フィールド・戦闘・ミニゲーム等の各シーン毎のサブシステムを用意し、
相互にコールしたり制御を移行したりしながらゲームを進める。

【例】
ゲーム開始
　↓
Script：スタートアップスクリプト実行（オープニング）
　↓（制御移行）
Field：移動中
　↓（コール）
Battle：戦闘発生
　↓（リターン）
Field：再び移動中…
　：

>>7 のフロー制御サブシステムは State パターンみたいな感じで組むといい気がする…。ってそんな事はみんなわかってるか…。

本当に言いたかった(やりたかった)事は………良スレage.

UMLをテキストで出力するソフトとかってある？
（って、2chに書きこめる形じゃないと意味ないのか）

10!

イベントやアイテムなどの「コンテナ」としてのクラス設計は
できるんだけどねえ。RPGクラスを作ろうとしたら画像・GUI
で見事に挫折。

Java1.4だとグラフィック周りが強力だから、コンポーネント
を継承して作れるかな？

実際の表示モデルからは独立した、抽象的なRPGクラスが作れないだろうか？

>>9
ホレ。
　http://www.osk.3web.ne.jp/~shino/dev/DICON/DICON.html
　http://objectclub.esm.co.jp/Jude/jude.html
# もっとも2chじゃ>>7 みたく崩れるが…

>>12
コンピュータゲームを極限まで抽象化すると、
パラメータやフラグをいじる作業になる思われ。
単純作業とゲームの差は、フラグ等の変更に判定が要／不要な点とか。
でもってフラグ等を変更するプロセスの違い＝ジャンル（RPGやADV等）の違い
なんではなかろーか。

…ってことで>>7を提唱。

>>7

うーーーん、何か、圧倒的におかしかないですか？
何が目的で、どう実装していくのかがまるっきり見えてこない。


まず根本の、全てのゲームで通用する考え方としては。

「Scene」というベースクラスを用意します。それは スクリーン、サウンド、コントローラ、タイマー ... etc を自由に扱える（Java でいうところの Applet クラスみたいなもの）クラスです。互いにシーンを呼び出せるように作ります。

それを継承して、先頭シーンクラス、カジノシーンクラス、フィールドシーンクラス、ミニゲームクラスを作ります。

ＲＰＧツクールのソースみてえ

>>14 の言うSceneが >>7のフロー制御サブシステムに相当すると考えてオクレ。
いずれの Scene もユーザからの入力に応じてパラメータいぢって、
ユーザに出力返してるだけと考えられる。

# パラメータ管理と入出力管理だけ別格にしてあるとも言えるかも。

>>15

しかし「RPG のモデルを考える」ってのもちょっとな。

どんなゲームもプログラマの作りやすいように設計しているんだろうし、
RPG というジャンルでもゲームによって、やっぱり設計も変わるだろうし。

柔軟性を求めるならそう設計するし、全く凝り固まったゲームでいいっていうなら、そう設計する。


ケーススタディとして「ドラゴンクエスト」のクラス設計を考えるっていう
のは無意味じゃないと思うけど、作る段階になったなら、やっぱり今までに
無いものを作りたいし。（だから、多分、あまり有用な返事は期待しない
ほうがいいと思いますよ >>1 ）

>>13
＞コンピュータゲームを極限まで抽象化すると、
＞パラメータやフラグをいじる作業になる思われ。
それは具象化じゃ…？

>>7
ゲームシステムに関するモデルもほしいところ。
あと、>>7に出てくる各名詞の特定ゲームモデルに依存しない抽象オブジェクトモデルと
それらを管理するプラガブルなフレームワークが必要だな。

僕が思うに、ドラゴンクエストの設計で一番、やりがいがあるのは
戦闘シーンでしょう。

（柔軟性を求めるならば）例えば、アストロンは無条件でダメージ
を受けないけど、（ゲームデザイナーの気まぐれとかで）「アスト
ロン無効の剣」なんていうアイテムクラスを作って、それを戦闘シ
ーンクラスそのものの変更無しで、実際にアストロンかけてるキャ
ラクターにダメージを与えてしまえるようになるという。

こんなふうに、プラグインみたいな感じでどんどん追加していける
というのが理想だと思うんですけども。

OOP の練習をしたい方がいましたら、実装してみては。

>>19
アイテム1コ毎にクラス作ってたら死ぬよ…

>>19
多分、オブジェクトコンポジションしてるインスタンスを作る。って言いたかったんじゃないのかな？希望的観測だけど。

>>20

あれ、アイテム一つに毎にクラス作るのは、それは当たり前の話じゃ？

そりゃ、「ひのきのぼう」「こんぼう」は、全く同じ性質で装備すれば
攻撃力は上がる、という性質は変わらないので、これらは別にクラス作
る必要は無いけど、「ときのすな」なんかは、それ用のクラス作るしか
ないでしょ。

アイテムクラスに「効果」という属性をつけて、
「効果クラス」をいろいろ作って、アイテムクラスにコンポジションする、って方向のほうが有望そう。
効果クラスは、「体力を回復する」とか、「敵に投げると大ダメージ」とか定義したクラスね。
そうすれば、スクリプトのほうから、新しいアイテムを付け加えたりできる。
アイテムの種類＝クラスの数だったら、

アイテムにつける効果属性は、「発動条件」と「効果」のペアを集約したほうがいいのかな？

>>23

「効果クラス」と「アイテムクラス」分けるのは、いいと思います。

発動条件もシンプルでいいんじゃないですかね（ところで、あんまり OOP 用語は好きじゃないのですが）
プレイヤーキャラクターObserver みたいなもの作って、例えば、「しあわせのくつ」なら歩くたびにコー
ルバックして経験値１づつ増やしたり。「命の石」なら、ザラキかけられたら、それを取得して無効化して
しまうとか。

「効果」には、その「優先度」という値も持たせるといいかも。

ゲームデザイナーが
「魔法を 100% 成功させるアクセサリを追加したい。しかも、そのアクセサリは呪われていて、八割の確率でプレイヤーに直撃するんた。」

なんていうことを言い出したとき、命の石と100%成功する魔法をどっちを優先させるかっていうことになるから、そこで、優先度の値が高い方を適用するようにしたり。

良スレの予感。

>14
いいこと言った。14以上を良スレ認定。

こーいうのはどう？

・データ
【アイテムの属性】（*1）
　ID、アイコン、名前、説明
　種別ID、品質、基本価格、etc...
【コマンド】(*1)
　ID、名前
　種別ID配列、効果用スクリプト

・選択したアイテムは一旦スタック（*2）に積む。
・選択後、積んであるアイテムの種別IDを「コマンドテーブル」と照合し、
　一致するコマンドがあれば一致するアイテムを全て取り出し、
　「効果」が発動。（効果の内容はスクリプトで記述）
・魔法・技もアイテムの一種として扱う。（*3）

*1:個々にクラス化するのではなく、管理用のクラスが1コ有れば良い。
*2:実際には双方向キューにして、一定数以上溜まったら
　古いものから順に破棄。
*3:単にメニューが別なだけで処理内容は一緒なので。

コレなら「調合」も実現できるかと。

>>28 の追加案。
アイテムによっては、スタックに保留中特別な効果有り。
<例>「炎の紋章」
　保留中：炎に対する耐性UP
　保留中杖使用：「ファイア」（MPのみ消費）
　保留中剣使用：「魔法剣ファイア」（紋章消費）

>>28
＞*1:個々にクラス化するのではなく、管理用のクラスが1コ有れば良い。
アイテムもコマンドも、管理用クラスで片付けた瞬間に OO のダイナミズムが
全て消え去ると思う。
無茶苦茶な仕様変更の多いゲーム製作において、この方式は手戻りが多くなり不毛だと思う。
(ま、ドラクエを作りますっていうのならば、仕様変更は絶対無いわけだからこれでもいいのかも知れないけど、何も新しい物を生み出さないね。ところで>>17の想定するドラクエは1〜7のどれ？)

まずどういう目的で設計するのかを表明していただきたい。>>7

７ってVB厨くさい

>>30
例えば特殊アイテムを１個追加したい場合、
・専用のクラスを新たに書くのと、
・スクリプトエンジンに（必要であれば）クラス追加して
　アイテム用にスクリプトを書くのと、
どっちが不毛か考えてみ。
後者はプログラムの再ビルドが必須だが、
後者は運がよければスクリプトの追加だけで済む。

>>28の方が不利な点があったら教えて。

>前者はプログラムの再ビルドが必須だが、
>後者は運がよければスクリプトの追加だけで済む。
ね。

>>34
全部スクリプトで作ったら？
再コンパイルはいらないよ。

あと、>>28の欠点は、大部分をスクリプトに頼っているため、スクリプトをかなり大規模に作りこまないといけないところかな。
思いつかない問題点を「スクリプトにやらせる」と先延ばししてるだけ。

>>33
なんとなくこのスレの掟のようなのでドラクエを例にして答えるよ。

「時の砂」を想定していないで製作していた場合。
このアイテムを追加するのに、スクリプトの適応範囲を超えている。
(できる/できない じゃなくて、スクリプトで時の砂の機能をつけるのはやめたほうがいい)

再ビルドはあんまり気にしない方がいいと思う。一ヶ月かかるなら話は別だけど、
CPUは年々早くなるが人間に出来る仕事量はそんなにかわらない。

書き終わった頃にはみんなが説明してくれてたね。

いわゆる、フラグの役割しか果たさないアイテム作りたいなら、
FlagItem というクラスを作ればいいです。

（フラグのためとか画像などリソースとの連携させるために
「ID」を返すメソッドを持ったオブジェクトにするのは、い
い方法です。データベースは作る必要はありません。）

本当に良スレな気がしてきた。

時の砂は例外中の例外じゃないかなぁ？
ゲームシステムにまで影響を与えるアイテムをあとから追加するなんて、至難のわざなような気がする。
でもそれを許容するようなフレームワークを作ら無ければならないってことか。

>>41

そうでもないと思う。考え方としては、戦闘が始まるイベントをキャッチ
して、戦闘シーンに入った直後のアイテムとステータスを全て保存して、
時の砂を使ったら全部元にもどして音楽を出現メッセージを流すクラスを
書けばいいのでは。

音楽やスクリーンやウィンドウを自由に扱えるオブジェクトをアイテムク
ラスに渡す機構さえ作ってしまえば、何でもないでしょう。

>>41
そう、柔軟性が必要なんだよ。OO は RPG (言語じゃない)の為にあるようなパラダイムだね。

>>42
アイテムクラスが戦闘システムの流れを全部制御しちゃうの？
オブジェクト間の関係が複雑化しすぎて収集がつかなくなると思うんだけど？

アイテムの機能毎にクラス化する場合、
"時の砂機能"は、巻き戻す状態を保持して、使用された時に戦闘システムに
その状態を渡す。

アイテム管理クラス方式の場合、
アイテム管理クラスが巻き戻す状態を保持して、時の砂が使用された時に
戦闘システムにその状態を渡す。

どちらにしても、アイテム関連のクラスが戦闘システムそのものの一部になるようなのは辛いよ。

>>37
だからさー、「時の砂」を想定してなかった場合、コードいぢるのはどっちも一緒。
しかしその後、時の砂に全体攻撃の効果も付けよう、ってなった時どっちが楽？
スクリプトなら元々有るであろう、全体攻撃の処理をスクリプトに足すだけ。
クラスで作ってたら、また新たにクラス作らんとダメ。

オブジェクト・ファクトリー

>>45
スクリプトの機能を作りこんでいる場合と、クラスフレームワークを作りこんでいる場合を比較すると、
結論は「両方楽」。
イザというとき小回りの効く設計が常に出来たらいいね！

>>45
なんで"時の砂効果クラス"があるのに"時の砂と全体攻撃効果クラス"を
0 から作らなきゃいけないのさ。
アイテムクラスのインスタンスが"時の砂効果クラス"と"全体攻撃効果クラス"を持つんだよ。
多分、あなたの考えてる柔軟性と俺の考えてる柔軟性はほぼ同じ物。
同じだけの柔軟さを持てるなら、それはスクリプトではなくてコードで表現した方がいい。
なぜなら、その方がスクリプトが単純になるから。

ちょっと書き間違えた。
＞ アイテムクラスのインスタンスが"時の砂効果クラス"と"全体攻撃効果クラス"を持つんだよ。

＞ アイテムクラスのインスタンスが"時の砂効果クラス"のインスタンスと"全体攻撃効果クラス"のインスタンスを持つんだよ。

誤解を与えかねない表現でした。スマソ。

＞49
クラスの属性なんかを区別しなきゃ。ごっちゃにすると不味いよ。

>>50
理解できなかった。
"時の砂効果クラス"と"全体攻撃効果クラス"を同じインターフェイスを実装するクラスにすべきではないという意味？
だとしたら、そこまでは考えて発言してなかったけど。

>>51
「アイテム」が「効果クラスへのポインタ」と
「効果反映ターゲット情報クラスへのポインタ」を一つづつ持つ、ということ。
「効果クラスへのポインタ」に"時の砂効果：クラス"のポインタを代入。
「効果反映ターゲット情報クラスへのポインタ」に"全体をターゲット：クラス"
のポインタを代入。
そして「アイテム」は自分の「効果クラス」に対する一定の関数を実行。
「効果反映ターゲット情報クラス」に対しても同様に。
つまり全て同じ型にしてはいけないってこと（>>51の通りかな？）

手抜き。エディタに貼り付けるか2ch-mode等で見れ。
　　　　　　　　　　　　　┌──────────────────┐
　┏━━━━━━━━━┓　│　　　　　　┏━━┓　　パラメータ　│
　┃スクリプトエンジン┠─┼─────→┨効果┃　　管理システム│
　┗━┯━━━━━┯━┛　│　　　　　　┗━┯┛　　　　　　　　│
　　　│　　　　　↑　　　│　　　　　　　　△　　　　　　　　　│
┌──┼─────┼──┐│　　　　┌───┴───┐　　　　　│
│┏━┷━┓┏━━┷━┓││　┏━━┷━━━┓┏━━┷━━━━┓│
│┃効果　┃┃コマンド┠┼┼→┨アイテム消費┃┃パラメータ変化┃│
│┗━┯━┛┃メニュー┃││　┗━━┯━━━┛┗━━┯━━━━┛│
│　　△　　┗━━━━┛││　　　　↓　　　　　　　↓　　　　　│
│┏━┷━━┓　　　　　││┏━━━┷━━━┓┏━━┷━━━┓　│
│┃時間停止┃　　戦闘　││┃アイテムリスト┃┃キャラリスト┃　│
│┗━━━━┛　システム││┗━━━━━━━┛┗━━━━━━┛　│
└───────────┘└──────────────────┘

>>52
そういう意味か、それならそういう方式もあると思う(効果クラスに対象まで含めるかどうか、によるけど)
前提になってた話がDQの時の砂だった(全体も一体もなく、戦闘シーンまるごとが対象)ので、>>45 の発言に対して、
時の砂の効果の直後にイオナズン！みたいな物を想像していた。

>>45 =7
＞48については理解してもらえた？

>>54
あ、DQか。スマソ知らなかった（有名所に弱い）。
「効果クラス」に関数へのポインタが必要かもね。

>>53
独自形式の図表だけじゃ、何がいいたいのか他人にはまったくわからん(取りたいようにとれる)。
説明の文章をつけてくれ。

>>53
クラス図だろうけど、矢印の意味がわからん。
ロール名くらいほしいね。

もう何を言いたいのかさっぱりわかりません。

>>59
ついていけないならC++系の入門ページを探すといいよ。

>>59
オブジェクト指向はわかりますか？
スクリプトを使用する事と対立する概念ではありません。
(むしろスクリプトをどの範囲で使用するのかをはっきりさせてくれるでしょう。)

なぜC++・・・

>>60
JavaやC#の方が概念の勉強には向いていると思うけど。
(C++は難しい＆既成の方法という逃げ道があるからね)

ドラクエ７の時の砂は、使い勝手が
悪かったな〜。命令や、あるとくぎ（まほう）に
自動的にカーソルが合うようになる機能まで
リセットされるから、いちいち選びなおすのが大変だった。
メタル系の敵と戦う時は特に。

例えば、このような部分を修正する可能性が
あるとした場合、どのような設計がいいのでしょうか？

>>64
保存する状態(時の砂の使用で戻る状態)にカーソル位置についての情報を含めないようにする。
具体的な実装としては、
状態の保存という意味では、そのまんま Memento パターンだが、Memento オブジェクトにはカーソル位置に関する情報を持たないようにする。

>>44
> オブジェクト間の関係が複雑化しすぎて収集がつかなくなると思うんだけど？

全くそうは思いません。



盛んにスクリプト処理を語ってますけども、
それが話を分かりづらくさせてます。

見たところ、>>35、>>36 さんと全く同じ意見で、スクリプト処理を
要らないところで持ち込もうとして、逆に複雑化しています。

ドラクエにおいてスクリプトが用いられるシーンは、せいぜい、ちょっと
したイベントシーン定義くらいしか思いつかないのですけども。

>>64
戦闘の中で発生する情報を毎ターン蓄積していく（取った行動、ダメージ等）
時の砂よく知らないんだけど、戦闘開始ターンに戻るなら初期状態
を保持するだけでいい。（そのアイテムを持っているor敵が使える時だけ）
戻る前に、現在のカーソル位置なんかの操作情報だけを保持したまま戻れば
戻ってからもその状態で戦闘を始められる。

>>66
武器データ、アイテムデータ、魔法・必殺技データ、
敵データ、エフェクトアニメデータ、・・・・・
これらはあとかどんどん追加変更されるものだからコードに
混ぜるわけにはいかないんだよ。
スクリプトはゲーム製作（特にRPG）に欠かせないもの。
だから無理にでもスクリプトの要素を食い込ませなきゃいけない。
一度自分で作ってごらん。重要性が分かるから。

>>68
プログラマの仕事が発生しなくなるくらいまでスクリプトを作りこむのは大変そうだなぁ。
あぁ、なつかしきEnd User Computing。

>>66
俺は盛んにスクリプト処理なんて語ってないんですけど^^;
むしろ「スクリプトにでしゃばらせ過ぎるな」と言ってる。
(プログラマの仕事じゃない部分に使う≒イベントシーンとか、なので、あなたと同意見です)

＞＞ オブジェクト間の関係が複雑化しすぎて収集がつかなくなると思うんだけど？
＞全くそうは思いません。
どの部分を否定されてるのかわからないんだけど、
「その程度は複雑化したうちに入らない」という意味か、
「オブジェクト間の関係は複雑化しても問題無い」という意味か、
後者だったら……私にはちょっとお相手できません。
前者だとしたら、俺が勘違いしてるのか、あなたが相当辛抱強いタイプなのか、

＞そうでもないと思う。考え方としては、戦闘が始まるイベントをキャッチ
して、
＞戦闘シーンに入った直後のアイテムとステータスを全て保存して、
＞時の砂を使ったら全部元にもどして音楽を出現メッセージを流すクラスを書けばいいのでは。

ここまではすごく同意。

＞音楽やスクリーンやウィンドウを自由に扱えるオブジェクトをアイテムク
＞ラスに渡す機構さえ作ってしまえば、何でもないでしょう。

これは、アイテムクラスが戦闘システムに深くかかわりすぎだと思いませんか？
例えば戦闘システム自体に変更が起こったとき、アイテムに関しても修正部分が多くなりますよね？
ご意見をききたいです。

>>68

再三言われてますけど、何のための OO か分かりまりません。

少なくとも、君の設計じゃ僕はプログラムは書きません。

>>70
＞＞音楽やスクリーンやウィンドウを自由に扱えるオブジェクトをアイテムク
＞＞ラスに渡す機構さえ作ってしまえば、何でもないでしょう。
＞
＞これは、アイテムクラスが戦闘システムに深くかかわりすぎだと思いませんか？
＞例えば戦闘システム自体に変更が起こったとき、アイテムに関しても修正部分が多くなりますよね？
＞ご意見をききたいです。

例外フラグ変数を一つ付けるだけでOK。何もしない奴ぁ0でもほうりこんどく、と。

なんか、みんな誰が何言ってるかわからなくなってきてるっぽいので別の板で使ってたコテハンつけます。

>>72
そういう事ではなくて、そもそもアイテム系のクラスに戦闘システムに関する動作をさせないようにする。という事です。

>>71
スクリプトから読み込んだデータでオブジェクトを作る。
あらかじめオブジェクトの仕様変更をスクリプトに反映させる
ためのツールを用意すればいい。（型は最初にきっちり決めとくもんだが）
何のためのOOかというと、OOPが好きな人のためのOOなわけです。
OOPは慣れれば巨大なシステムも容易に構築・保守できるから優先
されます。イヤならOOPできない人たちで作るとか。
僕は設計なんかするつもりはないし、やるとしてもあなたのために
設計することはないでしょうね。安心して下さい。

>>73
じゃ時の砂を再現する方法は皆無になるね。

で、ですね。話が食い違ってる要因として何を前提としてるのかが違ってるというのがあると思うんですけど。

ドラクエを作る/ドラクエ系の物を作る/ドラクエは関係ない
C を使う/ C++ を better C として使う/ C++ を OOPL として使う/ C++ をマルチパラダイム言語として使う
全てスクリプトにやらせるべき/スクリプトは適材適所で/スクリプトなんて知らない

等々、各人ごちゃまぜでは意思疎通できないと思うんですけど

せっかくいいスレだと思ったのに、あげあし取りと罵倒が始まりそうです。
残念ですね。

>>75
誤解されたのだと思いますけど、戦闘システムのやるべきことと、
アイテム系のクラスがやるべき事を区別するべきだと言ってるんですよ。
解りますか？

>>77
まあまあ。マターリしましょうや。

>>73
だから、アイテムクラスのメンバに例外フラグを加えると。
その例外フラグ＝SCREEN_SCROLLならシステムに関して画面をスクロール
しろって意味になると。
そのフラグに対応したシステム関数をつくると。
仕様変更でスクロール方法に変更があればこの関数をイジルだけと。
この関数を使わなくなったなら、そのアイテムの例外フラグ＝OFFにすると。
で関数を除去すりゃいいんでは。

関係ない攻撃の対象にもされそうなので、このスレで発言した番号をまとめました。（あんまりリンクが増えると良くなさそうなので番号だけです。）
21 30 37 38 40も一応 43 44 48 49 51 54 55 61 63 65 70 73 76 77
コテハンになってから口調が変わった事は突っ込まないでね。
学生時代演劇部だったので、役名を貰った瞬間にキャラが変わるのさ^^;

>>78
そうですね、マターリと実りのあるやり取りができると素晴らしいです。
でもマターリしていらっしゃらない方が出てきてるようなので。

>>77
あ、あのね、戦闘システムに対してアイテム系クラスがメッセージを
送るだけであって、２つを同列に扱うわけではないよ。

確かに、柔軟性を求めすぎたら複雑になります。
プログラマは、凝り固まったシステムでかまわければ、その範囲
でできるだけシンプルに設計します。

「時の砂」をプラグイン的に実装できなくてもよいというのに、
わざわざそうするのは、愚かです。（そのかわり、後で設計の
変更やアイテムの追加には応じられませんが・・・）


ただ、複雑といいますけども、この件はそうでもないと思います。
必要なときに、戦闘シーンオブジェクトにアクセスし、必要なければ
アクセスしなくていいのです。

（Java風で行きます）

アイテムが戦闘開始時に何かしら実行しなければならないときだけに、
BattlerObserver インターフェースを（戦闘に参加するキャラクター
を定義するインターフェース）組み込めばいいのです。

アイテムを取得した時点で、

　void setOwner( Battler owner){
　　this.owner = owner
　}

というメソッドを用意しているでしょうから、
これをオーバライドして

class SandOfTime extends Item implements BattlerObserver{

　public void setOwner( Battler owner){
　　 super.setOwner( owner);
　　 owner.addBatlerObserver( this);
　}

　/**
　 * 戦闘開始時に発動。
　 */
　public void battleStart(){
　　BattlerGroup[] group = getOwner().getBattleScene().getEnemyGroup();
　　.
　　（延々と戦闘状態を保存するコードを書く・・・）
　　.
　}

複雑とは思いません。

いやぁ・・・怒ってるような書き方だったのかな・・？
話もそれほど難しいことじゃないんだけど・・・

>>79
その関数がアイテム側にあるのはちょっと…。
アイテムと画面効果にはコード上で直接的な関係を持たせないほうがいいと思うのですが。
(アイテムオブジェクトが画面効果オブジェクトを持つ、とかの方がよい)

>>82
それだと”時の砂バトル”になるね。

>>82
やっぱり「何が複雑なのか」の話がかみ合ってないですね。
コードが表面上複雑かどうかじゃなくて、オブジェクト間の関係が複雑だ、と言いたいのです。
だいたい、>>70 で、Observer 関係については「同意です」とお伝えしてありますよね^^;

>>81
だとしたら、アイテム系のクラスに対してUI関係のオブジェクトを渡す必要はないのでは？

>>86
知識が薄くてごめんよ・・。UIってのは何？
GUIではなくて？

>>87
UI は UserInterface です。
Graphical を付けなくても通じると思いました^^;

>>86

それだけ分かってて、それでも複雑だと思います？？？

>>82
＞（延々と戦闘状態を保存するコードを書く・・・）
延々とというか、戦闘状態も抽象化するのがいいね。

class SandOfTime extends Item implements BattlerObserver{
　　private BattleState saved_state;
　　// 戦闘開始時に発動するBattlerObserverのメソッド？
　　public void battleStart() {
　　　　BattleScene battle = getOwner().getBattleScene();
　　　　saved_state = battle.getSceneState().clone();
　　}
　　// アイテム使った
　　public void apply() {
　　　　BattleScene battle = getOwner().getBattleScene();
　　　　battle.setSceneState(saved_state);
　　｝

まぁ、「時の砂が使われたら先頭シーンを巻き戻す」という機能をどのオブジェクトに持たせるかというのは、難しい選択だね。
戦闘シーンに持たせるか、アイテムに持たせるか、プレイヤーオブジェクトに持たせるか、グローバルなルールとして持つか。
どのオブジェクト（システム）が一番使用的に固まってるかとかで判断するのかな？
というか、C++やJava系のOOPLの弱点？

>>88
知らなかったよ・・。GUIと似たようなもんだーね。
んで、
＞アイテム系のクラスに対してUI関係のオブジェクトを渡す必要はないのでは？

えと、渡さないよ。「アイテム系クラスがメッセージを 送るだけ」なんだけど・・。
まさか丸裸のオブジェクトをやり取りするわけでなし。メッセージを処理する関数
をちゃんと付けなきゃだめだよ。

>>89
え、はい^^;
もともと頭が良くないので、単純にできる物はできるだけ単純にするクセがついてるからですかね^^;

例えば、戦闘画面の敵の位置が変わったとします。
修正するべきは戦闘システムのUI関連クラス(これは当然)、
それにそれ以外のUI関連クラスですよね。
この中にアイテム関係クラスが含まれるのは私的には「いやだなぁ…」です。
「画面効果クラス」があって(これは当然上記のUI関連クラスに含まれますよね)
そこをクッションとして、UI関係の修正をアイテムクラスまで持ち込まない。
この方がずっといいと思うのですが。

>>90

そうそう。そういう感じです！

>>91
それは OOPL の弱点ではないと思いますけど(設計の問題では？)
OOPLを使っても、個々のモジュールに明確な役割が振られていないコードはかけますし、Cでも構造化BASICでも、適切な役割分担をしたモジュール設計はできます。

>>92
「戦闘システム」という言葉にUIが含まれるか含まれないかを取り違えてただけですかね^^;

なんでJavaで作るんだ？アプレットでも携帯でもないのに？
Java信者のネタスレか。

>>95
う〜ん、、ゲームにもよるだろうけど基本的にGUI周りはラップして
独立させるべきだね。
ゲームシステムに絡むと製作初期段階ではやりやすい（？）だろうけど
あとあとややこしいことになったりするし。
ゲームシステムとGUIの間でメッセージのやり取りをした方が無難だよ。

>>92
> アイテム系のクラスに対してUI関係のオブジェクトを渡す必要はないのでは？

柔軟性を求めるなら当然、渡すしか無いです。
攻撃する際にすら、アニメーションエフェクトは違いますよね。こういう時こそ、オブジェクト指向の肝であるポリモーフィズムを活用すべきです。

ジャ川必死だな（藁

>>98
それだとスクリプト書けなくなるよ。
アイテム3つ4つのアクションじゃないんだから。

ジャ川必死だな（藁

参考までに、「時の砂」の撒き戻し機能は、どのオブジェクトにつけるべきだと思います？>>95

プププ、哀れジャ川
javaで本格的なRPGを作ることなんか永久に無いのに。
1円にもならない妄想はやめとけ（藁

>>100

ここでスクリプトを用いる意味ありますか？

>>104
既に大議論されたことなので過去レス参照。俺はスクリプトは必要
という結論済み。一度その考え方でRPG組んでみなよ。そしたら
意味があるかどうか分かる。

>>105

結局理由言わないで「作ってみろよ」の一点張り。

残念ながら、それでは結局は複雑さをスクリプトに持ち込むだけで、破綻します。

>>97
まったく同意見です。(ちがうと思ってました？)

>>98
方向が逆です。UI関係のオブジェクトに、アイテム系オブジェクトの方(もしくはアイテム系クラスが保持する画面効果オブジェクト)を渡すべきです。

>>102
私なら、以下のような感じを想定します。
戦闘システム部分が「こういう状態の戦闘をはじめるよー」というデータをうけとって戦闘が開始され、この時に戦闘開始イベントにフックしていた「時の砂機能」の「状態を記録する操作」が呼び出されます(つまり復元すべき状態は「時の砂機能」のインスタンスが保持します)

で、「時の砂機能」をもつアイテムが使われた場合、復元するべき状態を先頭システム側に渡します。
戦闘システム側は、そのデータを元に、以前の状態から再開します。

これならば例えば、「戦闘開始直後じゃなくて３ターン前に戻る事にして、時の砂機能をもったアイテムは複数登場させたいんだ」と言われても対処できますよね(ターン通知イベントとかは追加しなきゃいけませんけど)

>>106
まぁ作らずに”こうした方がいいんダッ！！”って妄想し
続けるのもいいかもね。
＞残念ながら、それでは結局は複雑さをスクリプトに持ち込むだけで、破綻します。
何もせず突如破綻してるところが、スゴイね。
スクリプトの扱い方知らないのかな？

>>107
残念ながら全く別物としかよめませんでしたよ。

＞私なら、以下のような感じを想定します。
＞戦闘システム部分が「こういう状態の戦闘をはじめるよー」というデータをうけとって戦闘が開始され、この時に戦闘開始イベントにフックしていた「時の砂機能」の「状態を記録する操作」が呼び出されます(つまり復元すべき状態は「時の砂機能」のインスタンスが保持します)
＞
＞で、「時の砂機能」をもつアイテムが使われた場合、復元するべき状態を先頭システム側に渡します。
＞戦闘システム側は、そのデータを元に、以前の状態から再開します。
＞
＞これならば例えば、「戦闘開始直後じゃなくて３ターン前に戻る事にして、時の砂機能をもったアイテムは複数登場させたいんだ」と言われても対処できますよね(ターン通知イベントとかは追加しなきゃいけませんけど)

それって>>67辺りで既にでていますよね。もっと簡単なものが。

109＝72です

>>107
なるほど。>>23あたりといっしょの考えって事かな。

＞時の砂機能をもったアイテムは複数登場

アイテムに時の砂機能をハードコーディングする場合でも、
そのクラスを継承したアイテムを作れば（もしくは、時の砂機能をもつ抽象クラスをはさめば）、
複数登場させられるけど、継承パスを深くしすぎると分かりにくくなるからきついかなぁ？
（げんだいのgoto問題か。

>>108

だから、スクリプトにこだわる理由を説明してよ。

>>109
＞残念ながら全く別物としかよめませんでしたよ。
今までの私の発言が、ですか？だとしたらやっぱり誤解を招きやすい表現をしやすい性質なんですね、私。
現実世界でも、そりゃもう山ほど…。

＞それって>>67辺りで既にでていますよね。もっと簡単なものが。
>>67 は私じゃないですけど、その近辺から、ずっとそう主張している(つもり)ですから、>>65 とかでも。

>>111
＞なるほど。>>23あたりといっしょの考えって事かな。
っすね。ちなみに >>21 で私が先に言ったんです(自己主張)。

継承よりは、コンポジションによって解決する方が大抵の場合スマート＆ダイナミックですので^^;

本格的なゲームなんか作ったことの無いJava房がほざいてるよ（藁

ただの擬似コードとして書かれただけなのに、Javaで作ってると勘違いしてスレまで立てた悲惨な>>1のいるスレからの出張ご苦労様。

>>116
多分、読んでないんでしょう、文盲なのかも知れません。
正直ウザいですが、慈悲をかけて相手をしてあげてはいけません。

さっさとおまえが「Java」で作った大作RPGをウプしろや>ニュートラル
できなければ、ただのハッタリJavaネタ師。

>>53以来久々に見たら、レス倍増でﾋﾞｸｰﾘ。
ついでに荒らし(>>99,101,103,115,118)登場でｹﾞﾝﾅﾘ。
塩まいとこ。｀д´）ノ.:∴

ところでアイテムクラスマンセーの皆さん、
個々のインスタンス生成の方法とかもきちんと考えてる？

>>119
それはスクリプトで。

人に「相手にするな」と言っておきながらですけど、ちゃんと意思表示してからじゃないと気がすまないので今回だけ。
これを読んでも荒らしつづける方は無視します。

>>118
誰にでも馬鹿みたいに喧嘩を吹っかけるのはおよしなさい。
私がいつJavaで大作RPGを作る/作ったと言いました？
ソースがあるなら出してくださいね。
強調の「」までわざわざ人の真似して、そんな事して楽しいですか？
あなたは人生を楽しんでいますか？
悲しくないですか？人の邪魔をして、自分の品格も落として、
そんな事にしか楽しみを見出せない人生なんて。

もっと前向きに生きましょう。人生の中に辛い事、自分の思い通りにならない事があるのはあなただけじゃないです。
全ての人が、悩み、憤り、悲しみを感じながら生きています。
でも、多くの人が助け合い、向上しあい、そして笑いながら生きているのです。
あなたもその仲間に入りましょう。
悲しいこと、苦しい事が世の中から消える事はないでしょう。
でも、嬉しい事をどれだけ受け取れるかは、あなた自身が決められるのです。
どうか、強く生きる事を恐れないで下さい。

トリップ付けんの忘れてた。>>121は私です。

>>119
それはアイテムクラスの作り方次第で変わってくると思うんですよね。
複雑なインスタンス生成関係は、いろいろ難しいですよね^^;って
単に私が勉強不足なだけなんですけど。

アイテムIDをキーにしたコレクションにアイテムの原型を作っておいて(どうやって作るかは省略…というか、まだイメージできない)
そこから clone してくる。というのはどうでしょう？
(はっきり言って突っ込み所満載ですね^^;)

まずファクトリーオブジェクトを全アイテムクラス分作っておいて
セーブデータからアイテムID呼んで、対応するファクトリーを使う、あたりでいいんじゃない？

>>68

ゲームデザイナーのためにスクリプト処理が要るのは分かるけど、
スクリプトにどの程度の柔軟性を求めるかってことだよね。

それは、C++ とかで一旦、ゲームをしっかりデザインし終わってから、
スクリプトとして扱える機能を一つづつ（キャラクターを動かす。
ドラクエIIIのオルテガの戦闘シーンみたいなのをスクリプトで
作りたい）という要望が出たときに、その都度、スクリプトの機能を
増やして増やしていく、くらいでいいと思う。

（スクリプトでゲーム作りたいなら Ruby を使うのがベストだけど、
それは、問題解決になってないでしょ？　結局スクリプト上でどう
設計するかというところに戻っちゃう）

>>121
相手にしなさんな。アラー氏は無視orアボーンしてるのに

止まったね。
じゃ、激論を目指して話題振りしまぁす!!

OO 的 RPG 設計におけるスクリプトの役割および実装。

何をスクリプトにさせるべきなんだろう？
どこまでがスクリプトの仕事なんだろう？

熱い意見のバトルをキボンヌ!!

正直スクリプトに拘るのはやめた。
本当に言いたい事を忘れていた。
前フリとして質問その2。つぎの仕様の実装方法を考えるべし。

・「調合」等、複数のアイテムを組合わせるコマンド
・使用するキャラや、装備個所によって効果の変化するアイテム（メモリ効率も考えて）
・どんな戦闘システムでも対処できるクラス。（再利用できなきゃ意味が無い）
　例：DQ（基本）、ロマサガ（あのコマンドをどうするか）、テイルズ（アクション） 全てに対応。

（プログラムが分からないのにイベントの実装をしたいという人がいた場合を除いて）

スクリプトは要らない。

ちょっとだけスクリプトに対する未練を書いてみる。

>>128
シナリオもハードコーディングですか。（・∀・）

恐らくシナリオ自体はスクリプト等にすると思うけど、
当然ダメージ処理とか、画面エフェクトの機能も付けますよね。
そうするとアイテムクラス、スクリプトエンジン双方に対する
インターフェースを用意するのは面倒ですよね。
だからここは、Chain of Responsibility パターンを適用して、
効果の管理はスクリプトに全任してはどうかと思ったんですよ。

>そうするとアイテムクラス、スクリプトエンジン双方に対する
>インターフェースを用意するのは面倒ですよね。

意味不明。
効果クラスに双方に対するインターフェースを用意する、です。

なんだかなぁ…
＞「調合」等、複数のアイテムを組合わせるコマンド
そんなもの、具体的な仕様がなければ決められないでしょ。

＞使用するキャラや、装備個所によって効果の変化するアイテム（メモリ効率も考えて）
getter をダブルディスパッチ

＞どんな戦闘システムでも対処できるクラス。（再利用できなきゃ意味が無い）
無理。しいて言えば入力デバイスとか

>「調合」等、複数のアイテムを組合わせるコマンド

調合クラスを作ります。

> 使用するキャラや、装備個所によって効果の変化するアイテム（メモリ効率も考えて）

組み合わせ一つ一つをクラス化する、相性クラス、みたいなものを導入します。

> どんな戦闘システムでも対処できるクラス

モデルと表示部を分離するように設計していけばできるでしょう。

>>129
> シナリオもハードコーディングですか。

結局はそうするのが一番いいです。

マップとか、定型的なイベント、例えば「階段」「村人」「旅の扉」「出入り口」
くらいは、それ専用のエディタを作ってデータ化するべきでしょうが、それ以外は
プログラミングが必要なんだから、プログラムを書けばいいと思います。

職人ですな

>>132
＞＞どんな戦闘システムでも対処できるクラス
＞モデルと表示部を分離するように設計していけばできるでしょう。
そんなの当然として、だからってどんな戦闘システムでも対処できるクラスって？
たとえ話だが、Sword World のキャラクターを GURPS 上に再現する方法を教えてくれ。
わかりづらいなら、ドラクエのキャラをゼルダの伝説のルールで再現する方法でもいいや。

どう考えてもこの部分はゲーム毎に異なる部分だと思うんですが。

>>135

確かに、ゲーム毎に最終的にはやはり、共有できない部分はあると思い
ます。

ゼルダの伝説とドラクエというと、それはゲーム性に大きな違いがある
ので何ともいえないんですけども。

ドラゴンクエストとファイナルファンタジーくらいの違い（見た目以外は
ほとんど変わらない！！）のゲームで、戦闘システムの中で共有できるモ
デルで重要なポイントとしては「ダメージ決定プロセスのフレームワーク」
ではないでしょうかね。

マジック・ザ・ギャザリングのルールを実装すれば、それはいろんなゲーム
で再利用可能ではないでしょうか。

（実際にゲーム作る際は「再利用」にこだわる必要も無いと思いますが・・・。
開発者は、デザイナーが望むものだけを実装するのが鉄則ですから。）

まともなゲーム作ったことの無いJA川、また妄想電波まいてるよ（ｗ

とりあえず言いたかった事を先に述べておく。
アイテムと効果をコンポジションで結びつけるのは
間違いだと思われ。（多分↓図になると思う）

　コマンド −(1)→ アイテム −(2)− 効果

　　(1)コマンドからアイテムに「使う」というシグナルを送る
　　(2)アイテムは効果を持っている

理由は↑の関係はコマンド「使う」に特化されすぎている為。
自分はコマンド「使う」以外のコマンドも考慮して、
↓のような関係を提唱する。（つーかしていた）

　アイテム ←(1)− コマンド −(2)→ 効果

　　(1)コマンドは（必要に応じて）アイテムを参照。
　　(2)コマンドはアイテムに応じて効果へシグナルを送る。

　例：コマンド「使う」
　　(1)「使う」コマンドは（アイテム管理クラス=袋から）アイテムを取り出す。
　　(2)「使う」コマンドはアイテムを効果に変換。
　　　（※コマンドクラスはアイテムと効果の対応表を持つ）

これなら「調合」コマンドや、使用者に応じて効果の変化するクラス等も
簡単に実現可能。
また戦闘システムの変更も、コマンドクラスで全て吸収できる。

解答は大方>>28でガイシュツだったんだけどね…
（多少変形してる上、記述がわかりづらいけど）

>>138
解らない…。ちょっと煽り風の言い方になるけど
「あんたの脳内設計を、そのままの言葉で書き出されても他人には理解不能」
って感じです。
前提になっている物が何なのか、暗黙の部分がさっぱり見えていないので
何にも解らないです。

＞アイテムと効果をコンポジションで結びつけるのは(中略)
＞コマンド「使う」に特化されすぎている

これは… void 氏ネタになってしまいますけど
「そう思いたいのですね ; ) 」
としか言えません。

あなたの提唱する方法をみると、要するに「テーブルにまとめてデータ持っておきましょう」という事だと思うんですけど、
これって OO がなかった時代の方式をそのまま使いましょう、という以上の
意味を持ってないと思うんですよ。
せっかく話し合うのなら、新しい可能性について話し合う方が有意義だと
思うのですが、どうでしょうか？

あと、あなたのいう「調合」の仕様を明確に示してもらえませんか？
「調合」にもいろいろありますので。

おいお前ら！2ch 発、ソース公開の RPG ツクール開発スレってのはどうですか？

RPG用のクラスライブラリの開発・・・とかね。

> RPG用のクラスライブラリの開発・・・とかね。

僕の考えでは、そんなものを作る価値は無いと思っているのですが、
（デザイナーが要求しているものだけを作るのが一番シンプル）

もし、作るとしたら、.NEt プラットフォームで作りたいですね。
一応、DirectX を叩くことができるし、C#、C++、VB、（あるいは
Java や Ruby や Delphi でも）クラスを直接使えるようになる、
とのことですから。

（多分、現実的には C++ で作ることになるんでしょうけど・・・）

>>142
一応、何かしら完成させてから次の段階へ進むべきだと思うよ。
毎回途中で投げたり、頭の中だけで終わらせてちゃ駄目駄目。

> 「テーブルにまとめてデータ持っておきましょう」

ただ、これも 100% 悪い方法というわけじゃなくて、用いる場によっては
正しい場合がありますよね。例えば、Java でいうところの ResourceBundler
なんてのは、ID と 文字列リソース を分離しています。

これは、英語なら「slime」日本語なら「スライム」中国語なら「粘物」なんて
というデータベースを作って、それに対応する ID を、例えばモンスターオブジ
ェクトなら返すと思うんですけど、それを一つ一つ

getJapaneseName()
getEnglishName()
getChineseName()

なんてのを作ってたらちがあかない。
こういうところでは、ID と データベースを持つというのもいいと思います。



ただ、アイテムの振る舞いに関する部分に関しては、やはり
クラス単位で分離して機能を実装すべきだと思います。

あぼーん

あぼーん

あぼーん

あぼーん

あぼーん

あぼーん

あぼーん

本当に必死だねぇ…。
というか、暇だねぇ……。

あ！o(≧o≦)o オレモカー!!

↑新キャラのモカーです。よろしく！

いきなり荒れてるな

チンカスはこれ以降無視ね。
================================================================================

>>138
うー、アレでも分からないか。
まぁ確かに下手な説明ではあるけど、ちょっとはピンと来て欲しいなぁ…
やはりまぢめにUML描かなきゃいかん？

あと「調合」と言うたら、FF5の薬師のアレ。
他にもあると思うが「選んだアイテムの組み合わせによって効果が変化」という
基本スタイルは変わらんと思うんだけど？

>>155
コマンドクラスをクソ沢山つくらにゃいけないような気がするが

しかし各人それぞれのRPGのイメージがあるから平行線もいいところだな。
ユースケース図でも書くといいかもしれん。
もちろん DQ1 タイプ、トルネコタイプと特定のモデルがないと
いくらでもアイデアが詰め込めるから話が発散するが。

>>156
数個（作り方によっては1コで）十分。
インスタンス初期化時に渡すテーブルを変えりゃ、
幾らでもバリエーションを増やせる。

例えばインスタンス初期化時に、
「アイテム使用時の効果一覧」を渡せばコマンド「アイテム」に、
「アイテムを投げた時の効果一覧」を渡せばコマンド「アイテム」になる。

んで各コマンド実行時の処理の流れは以下の通り。
(1)コマンドクラスのインスタンスは、
　アイテム管理クラスのインスタンスを取得。
(2)(1)で取得したインスタンスに、
　「これらのアイテムの中から選ぶよ」というシグナルを送る。
(3)アイテム管理クラスのインスタンスは
　プレイヤーにアイテムを選択させる処理を実行。
(4)選択されたアイテムのIDをコマンドクラスの
　インスタンスに返す。
(5)返されたアイテムのIDとテーブルを照合して、
　対応する効果クラスへシグナルを送る。

以下デザインメモ。
・アイテムを使わないクラスには(1)〜(4)の処理は無く、
　常時固定（とは限らんが）の効果クラスへシグナル送信。
・(1)の処理は、DQ風のキャラ単位でアイテムを管理している
　システムを想定して付け加えた。
　FF風のパーティ全体で共有するシステムの場合、
　コマンドクラスのインスタンス生成時に与えればOK。
　DQ風の場合は、インスタンスを取得するための関数等を渡しておく。
・コマンドクラスの生成時に渡すテーブルを「魔法効果一覧」、
　(1)で捕まえる管理クラスのインスタンスを「魔法管理クラス」に
　すれば「魔法」コマンドの出来上がり。

> 数個（作り方によっては1コで）十分。
何を作るの？

> インスタンス初期化時に渡すテーブルを変えりゃ、
何のインスタンスの初期化するの？
テーブルって何？

> 幾らでもバリエーションを増やせる。
何のバリエーション増やすの？

> 例えばインスタンス初期化時に、
何のインスタンスの初期化するの？

> 「アイテム使用時の効果一覧」を渡せばコマンド「アイテム」に、
何に何を渡すの？

> 「アイテムを投げた時の効果一覧」を渡せばコマンド「アイテム」になる。
何に何を渡すの？

> んで各コマンド実行時の処理の流れは以下の通り。

> (1)コマンドクラスのインスタンスは、
コマンドクラスの仕様を定義せよ

>　アイテム管理クラスのインスタンスを取得。
アイテム管理クラスの仕様を定義せよ

> (2)(1)で取得したインスタンスに、
何を取得するの？

>　「これらのアイテムの中から選ぶよ」というシグナルを送る。
どこにシグナルを送るの？

> (3)アイテム管理クラスのインスタンスは
>　プレイヤーにアイテムを選択させる処理を実行。
> (4)選択されたアイテムのIDをコマンドクラスの
> 　インスタンスに返す。

どこに返すの？

> (5)返されたアイテムのIDとテーブルを照合して、
>　対応する効果クラスへシグナルを送る。

どこに送るの？

>>7 君。こういうのもなんだけど、君の説明能力の無さは本当に呆れるほど。
また、OOP 設計の常識からもかけ離れすぎてる。

もう書き込まないでほしい。

ご飯を食べて生きていくクラスを書いてくれ。早くな。

誰かアイテム管理クラス、効果クラスとコマンドクラス、それらを保持するクラスのUMLを
書いてどこかにアプしてもらえないでしょうか...

>>155
＞ちょっとはピンと来て欲しいなぁ
もしかしたらUMLは私とあなたの間を結ぶために存在するのかもしれません^^;
FF5 の調合ですか…。FF5 は友達に借りて、格ゲー風のコマンド入力ができなくて
そのままつき返したから知らないんだよな^^;
ちょっと勉強しときます。

ところで、GoF のパターンズはご存知ですか？
一通り覚えると OO の世界が変わります。こういう場合にもパターン名で
意思疎通できたりします。

>>163
＞FF5 の調合ですか…。FF5 は友達に借りて、格ゲー風のコマンド入力ができなくて
本当にFF5やったんかといいたい、とことん問い詰めたい。

うそつきがおおいですねぇ

>>164-165
え？FF5って女の子が主人公で、マクロスの敵のロボットの上に乗っかるみたいな奴がでてくるやつでしょ？ちがったっけ？

だとしたら、嘘はついてないぞ。
変な格闘家みたいのが助けに来る戦闘で、そいつのコマンド技入力しないと
勝てないみたいなのさ、20回くらいやったけど、全然発動せず。
怒り心頭で *友達に借りたカセット* を ×自主規制中× たシーンまで思い出すよ。

ごめんなさい、勘違いしてました。それ６じゃん。
俺、やった事ないのは抜かしてカウントしてるのかも…。
というわけでFF5やった事なかったです。スマソ。

>>166
今頃になっていうのはアレだが、
あのコマンド入力は、非常にゆっくり(噛み締めるように)
入力してもオッケーなのだよ。

そんなことはどうでも良いので
議論を続けよう。

ワラタ。マッシュの「ばくれつけん」ね…。
漏れもあそこでキレかけたことあるよ。

あのへんから□はおかしくなっていった気がするよ。
ウケ狙いというかなんというか・・・。

>怒り心頭で *友達に借りたカセット* を ×自主規制中× たシーンまで思い出すよ。

これに、ちょっと笑ったある寒空の夜。

あのコマンドは、ストIIのコマンド入力できない俺でもできたけどな。
10秒くらいかけてゆっくりやってもでるんだもの・・・

斜めを入れなくてもいいしな。

あぼーん

>>ALL
2chに詳細設計書くほど私は酔狂な人間じゃありませーん。

>>157でGoFパターン使うなら、
・コマンドクラスのインスタンス生成時に、
　アイテムID→効果変換テーブル等を付加するために
　AbstractFactory。

・コマンドクラスとアイテム管理クラスの関係にBridge。
　Abstraction=コマンドクラス
　Implementor=アイテム管理クラス。
　GUI等の「機能」はコマンドクラスに、
　アイテムの個数判定などの「実装」はアイテム管理クラスに任せる。

・「コマンドの実行」はFacadeで定型化。
　Facadeも別インスタンス化しておき、コマンドクラスのインスタンス
　生成時に付加するようにしておけばコマンドクラスは1個で済む。

・コマンド管理クラスと効果クラスの関係にCommand。
　Client=コマンドクラス
　Invoker=実行待ちキュー管理クラス（実行順序を制御）
　Command=効果クラス

とか。何故↑なのかは各自考えれ。
2ch上で一方的に詳しい説明を期待するのが、そもそもの間違い。

>>7

じゃあ書くな。

あぼーん

あぼーん

つーか>>127の冒頭に書いた「アイテムと効果のコンポジションは間違ってる」に
反論するモンはおらんのか。
どっちかっつーとそっちを期待してたんだが。
わざわざ比較対象まで用意したのに。

ついつい熱くなって>>127の設計について語ってしまったが、
「それ以外の設計」について、熱く語ってくれる方の登場をキボン。

>>179

> 2chに詳細設計書くほど私は酔狂な人間じゃありませーん。

なんて自分で言っといて、それは何ですか？

もうつきあってられません。

あぼーん

>>180
だから私は自分の設計を「見せたい」んじゃなくて、
アンタらの設計を「見たい」わけ。

とか言うとかえって設計見せずに「逃げる」んでしょうな。（ﾌﾟ

>>7が
> 2chに詳細設計書くほど私は酔狂な人間じゃありませーん。
って書いたから、
「それなら、俺もここで設計書くほど酔狂でないぞ。」って言いたのでは？
>>7は詳細に書けとは言ってないんだよな？
どっちにしても、また五月蝿い厨房が出てくるから
マターリ行こうよ。

人の設計だけ見て自分の設計を見せないって
逃げてる奴が何言ってるんだか。

あぼーん

まあ>>7はアレだけど、「アイテム管理クラス」はあった方がいいんじゃないの？
こんな感じでどうよ。

・構造
Flyweightパターン使用。

・構成要素
Flyweight = アイテムクラス
UnsharedConcreteFlyweight = 「薬草クラス」「武器クラス」等。
FlyweightFactory = アイテム管理クラス （= 袋クラス）

・協調関係
袋クラスは、アイテムの個数とIDを内部プールに保持する。
Clientはアイテムのインスタンス、又はIDと個数を渡すことで、
「袋にアイテムを入れる」ことができる。
（インスタンス以外に「IDと個数」という手段があるのがミソ）
また、ClientはID（と個数）を指定して「袋からアイテムを取り出す」ことができる。
この際袋クラスは、指定されたアイテムをインスタンス化する役割を持つ。

・補足
袋クラスにIDと個数指定でアイテムを追加するメソッドを与えておくことで、
アイテムの生成を袋クラスで担当できるようになる。（>>119はコレで解決）

ところで袋クラスがアイテムクラスのインスタンス生成する部分は、
どのパターンを使ったら良いと思う？>>1-185

# AbstractFactory、Bridge、TemplateMethod あたりが候補かな。

Abstructである必要は無いように思うが　>> AbstructFactory
でも一番無難そうなのはAbstructFactoryだな。
Unsharedか否かを管理出来ればよい訳だけど

ただ個人的にはFlyweightは最適化の範疇だな。
クラスレベルの情報とインスタンスレベルの情報を慎重に切り分ければ
Flyweightでなくともさほど問題にはならんと思うよ。
（せいぜいアイテムインスタンスごとにポインタ一個分ぐらい増える程度）

上で「アイテムと効果のコンポジションは間違ってる」って意見があるが
では効果のインスタンスレベルの情報はいかにしてスマートに実装するか？
という疑問がまず浮かぶ。

アイテムが効果を持つ。これは不自然なことじゃないと思う。
ただ、アイテムが効果を実行する。これは日本語として不完全だと思う。
このイメージがそもそもの間違いじゃないだろうか。
実際には
誰かさんがアイテムを（どのように）使って効果が発動した。
コレが自然じゃなかろうか。
よってアイテム実行コマンドは少なくとも
誰が、どのアイテムを（複数可）、どのように、使ったのかという引数が必要。
これを実装するとなると恐らく「誰」がに相当するクラスすべてに
アイテム実行機能を持たせることになると思う。
Javaライクに言えばItemuserInterfaceが必要。
・・これでどう？

上の書いてて思ったが「効果」って厳密に定義するなら
インスタンスレベルの情報は無いように思えるな。
でも実際にはアイテムの固体によって変化のある効果だなんて
ありがちな話なので効果じゃなくて特性と言葉を変えて
上の話を読んでくれ！

>>189
そうですね。
自分もアイテムの効果は「使われる」時点で決定された方が良いと思います。

あと、アイテム実行コマンドに渡す引数の「どのアイテム」は必要ないのでは。
「どのアイテム」かは、「誰」が持っているアイテムの中から、
「どのように」の方法で使えるアイテムをピックアップし、
ピックアップした中からプレイヤーに選択させる処理を
アイテム実行コマンド内で行えば良いと思います。

あぼーん

あぼーん

＞１６６
ＦＦ６のコマンド入力は２Ｐコントローラ側にターボファイルが
ささってると絶対成功しないなり。
（ターボファイルだけじゃないかもしれないけど）
もちろん、ゆっくりやっても、斜め入力なしの方法でも無理だった。
この原因はあまり知られてないみたい。

>>194
原因は何？

と言いつつ。
>>194
単に2P側コントローラー挿して、何かボタン押してるだけでも出なくなる。
恐らく2人プレイ用のロジックのマズさが原因かと思われ。

#そういや7以降は消えたなぁ…

野球ヲタﾜﾗﾀ

http://ime.nu/www.baseball-lover.com

156 ：参加するカモさん ：02/01/08 14:08
>>115
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死

157 ：参加するカモさん ：02/01/08 14:11
>>115
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪

>195
あ、原因ってのは「２Ｐコントローラに余計なものがささっているとダメ」
ってことを指したつもりです。それの技術的な原因って意味ではありませんデス。
・・・ってか、完璧こっちのミスでしたね。誤解を招く文章ですみませんでした。

194 名前：名前は開発中のものです。 ：02/02/24 00:55 ID:SXLvaQtu
＞１６６
ＦＦ６のコマンド入力は２Ｐコントローラ側にターボファイルが
ささってると絶対成功しないなり。
（ターボファイルだけじゃないかもしれないけど）
もちろん、ゆっくりやっても、斜め入力なしの方法でも無理だった。
この原因はあまり知られてないみたい。


195 名前：名前は開発中のものです。 ：02/02/24 00:57 ID:???
>>194
原因は何？


196 名前：ゲーム板へ逝け ：02/02/24 02:04 ID:???
と言いつつ。
>>194
単に2P側コントローラー挿して、何かボタン押してるだけでも出なくなる。
恐らく2人プレイ用のロジックのマズさが原因かと思われ。

#そういや7以降は消えたなぁ…


197 名前：名前は開発中のものです。 ：02/02/24 02:06 ID:1yncznHk
野球ヲタﾜﾗﾀ

http://ime.nu/www.baseball-lover.com


198 名前：名前は開発中のものです。 ：02/02/24 10:16 ID:???
156 ：参加するカモさん ：02/01/08 14:08
>>115
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死

157 ：参加するカモさん ：02/01/08 14:11
>>115
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪

アンチJa川必死だな(ﾌﾟ

ﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉ
（≧□≦）ｂ　＜　ビーグルちゃん、ほんっとかわいいでちゅーーーーー！！！ （＾＾） （＾＾）
　　　　　　▼・ェ・▼＜ぼくちん、ほんとかわいちゅぎだワン！＞▼≧□≦▼　
　　　　　　ヾcUUっ　　　　　　　　　　　　　　　　　　　　　　 　　 　 　 ヾcUUっ　　
ヽ（≧□≦）人（≧∇≦）人（≧▽≦）人（≧ω≦）人（≧□≦）人（≧◇≦）ﾉ
　かわいいー！！かわいいー！！かわいいー！！かわいいー！！かわいいー！！（＾＾）
ヽ（≧□≦）人（≧∇≦）人（≧▽≦）人（≧ω≦）人（≧□≦）人（≧◇≦）ﾉ
　かわいいー！！かわいいー！！かわいいー！！かわいいー！！かわいいー！！（＾＾）
ヽ（≧□≦）人（≧∇≦）人（≧▽≦）人（≧ω≦）人（≧□≦）人（≧◇≦）ﾉ
　かわいいー！！かわいいー！！かわいいー！！かわいいー！！かわいいー！！（＾＾）
ヽ（≧□≦）人（≧∇≦）人（≧▽≦）人（≧ω≦）人（≧□≦）人（≧◇≦）ﾉ
　かわいいー！！かわいいー！！かわいいー！！かわいいー！！かわいいー！！（＾＾）
ヽ（≧□≦）人（≧∇≦）人（≧▽≦）人（≧ω≦）人（≧□≦）人（≧◇≦）ﾉ
　かわいいー！！かわいいー！！かわいいー！！かわいいー！！かわいいー！！（＾＾）
ﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉﾍ（＾＾ﾍ）（ﾉ＾＾）ﾉ

魔法の使用効果とアイテムの効果をまとめられるといいかも！

2ch-mode 推奨。あるいはエディタへコピペ。

■クラス図モドキ
┌────────┐登録　┌───────┐
│キャラクター　　├──＞│実行待ちキュー├…
├────────┤　　　└───────┘
│コマンド一覧　　│
│袋　　　　　　　│　1..*┌──────────┐ ┌────────
├────────┤◇──┤袋（アイテム管理）　│─┤各キャラ毎に用意│＼
│コマンド実行()　│　　　├──────────┤　│or パーティ共有 └─
└───┬────┘　　　│所持品のリスト　　　│　└──────────┘
　　　　│　　　　　　　　├──────────┤
　　　　Ｖ「動作」取得　　│アイテムを取出す(ID)│
┌───┴────┐　　　│アイテムを入れる(ID)│
│コマンド　　　　│　　　│アイテムを選ぶ(種類)│
├────────┤　　　└──┬───────┘
│所有キャラクター│　　　　　　│
├────────┤　　　　　　Ｖ
│コマンドの実行()│　　　┌────────┐
└───┬────┘　　　│静的データ管理DB│
　　　　△　　　　　　　　└────────┘
　　　　├─…　　　　　　　　　Λ
┌───┴──────┐　　　　│
│「アイテム」コマンド├────┘
└──────────┘


■コラボレーション図モドキ
（「アイテム」コマンドの流れ）
┌──────┐ 　┌───────┐
│キャラクター│──┤実行待ちキュー├─…
└──┬───┘5:→└───────┘6:→
　1:↓│↑4:
┌──┴─┐　　┌─┐
│コマンド├──┤袋│
└──┬─┘2:→└─┘
　3:↓│
┌──┴─────┐
│静的データ管理DB│
└────────┘
1:「キャラクター」は所有している「コマンド」の中から１つを選んで実行。
2:「コマンド」は初期化時に与えられた「キャラクター」へのポインタを介して、
　「袋」からアイテム（のID）を取り出す。
3:アイテムのIDをキーに、データベースを参照して「動作」を生成する。
4:「コマンド」は生成した「動作」を「キャラクター」に返す。
5:「キャラクター」は「動作」を実行待ちキューに登録。
6:順番が回ってきたら、「動作」を実行。

※「動作」が何であるのかは未定。
　スクリプトやクラス等、動作の内容を定義するモノへのポインタ
　＋実行するキャラ、ターゲット等の付加情報が適当かと。

図とか書くのに適しているAAエディタなどご存知ありませんか？

一旦画像で書いてAscii Art Editor でトレースするとか・・・

ギャハハハ、ざまあみろジャ川
ジャ川スキルが低いな、デザインパターンのセンスなさそうだ（嘲笑

じゃあ書いてみれ。煽るだけなら誰にでもできる。>>207

つーか「デザパタつかっとらん」位しか言う事ないの？
他に色々突っ込み所あるだろうに…（叩き台と称する位だ）

>>205
UML のクラス図なら Jude で出力できる。
やや大きくなるけど。
http://objectclub.esm.co.jp/Jude/jude.html

>>208
ローカルアボーンしなさい。それかフィルタをかけるか。

このスレが正常に機能するためには
何を作るか、何で作るかをはっきり定義しないと駄目だってば。

あと、ソースとUML図をウプできる所が欲しいな。

とりあえず
・ドラクエ式 RPG を C++ でオブジェクティブに作る
っていうのはどうでしょう？

実装は置いといて、まず設計。

sage進行ならﾀﾞｲｼﾞｮﾌﾞかな

このスレでやってみない？
　http://game.2ch.net/test/read.cgi/gamedev/1014979288/31?&nofirst=true

やだ

RPG に重要なものといえばやっぱり愛と友情だよね
というわけで

class AI : public virtual Degawa{
　　...
};

class Yuujou : public virtual WannaBe{
　　....
};

でどうだろう？

class Degawa : public virtual Tyubo {
};

class WannaBe : public virtual Tyubo {
};

class Tyubo {
protected:
　　Thread m_thread;
public:
　　Tyubo() {
　　　　m_thread.assign(_2ch.game.ghard);
　　}
};

class 成田逝き快速特急 : public virtual WannaBe {
}

class あの世逝き新幹線 : public virtual WannaBe {
}

age

難しい話になると荒らすのかよ。
やれやれだな。

まず
アニメーションクラスを作れば

難しいことしすぎ。まずドラクエ２から作りたい人は
どうすればいいの？

つーかネタだろ。

>>222

とりあえず.NET Frameworkでも落としてきて「マップをスクロール
表示するコンポーネント」でも書いてみる。それができたら、次は
キャラクタ、そして世界を駆動するスクリプトエンジンオブジェク
トかな。

マップの出入り口っていうか、マップ間を瞬間移動するしくみ
はどうやって作ります？

だいたい、RPGみたいにタイトルごとにシステムが極端に違うものをたとえ基本であっても、ひとくくりにしようというのが厨房的発想。

>>225
大規模なマップをシームレスに繋ぐより遙かに簡単だけど

>>226
とっくに >>2 で指摘されてる内容を今更偉そうに書くあなたも立派な厨房です。

しかしまあ、上のほうで語られているのはほとんどカスっちいのばっかだな。
どれも実用的じゃない。糞スレとはまさにこのこと。

つーか、ゲームと言わずすべてのアプリケーションに適応できる優れたクラスがあるやん

うむ。やねSDKだな。

JavaやC#のO|objectクラスだよ

>>232
○(O|o). ｼｭﾜｯﾁ!!

やねさんてそんなに優秀なの？
汎用性は？
gccでコンパイルできます？（リナックスで動く？）

>>234
キチキチのDIrectXチューンのライブラリなんで無理です。
BCCでも動かないんじゃないか？

○(％). ｼｭﾜｯﾁ!!

（・∀・）ﾄﾞﾝｸﾞﾘ!!

mage

ui

Ｃ＋＋がわかりません。Ｃレベルでお願いします

･･･

>>240
@protocol GameObject : Object
-die;
@end

ObjectiveCできたか・・・

去年の今ごろ
http://www5.justnet.ne.jp/~uuuu/battle/
にＦＦ風の戦闘をDHTML&JScriptで作ってる
すごいプログラムがあったが
あれはどうなったのか・・・・

nage

みんなJavaと聞いたとたん、投げやりになってますね（藁

内部パラメータって何種類くらい作ってます？
　つよさ
　かしこさ
　すばやさ
　愛

>>247
それこそゲーム依存になってしまうから汎用的な設計というのは無理じゃないかい？

保守下げ　

漏れら極楽人道のageブラザーズ！
良スレっぽいものは強制的にageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧ 　 ∧＿∧ 　　　age
　（・∀・∩）（∩・∀・）　　　　age
　（つ　　丿 （ 　　⊂）　age
　 （　ヽノ　　 ヽ/　　）　　　age
　 し（＿）　　 （＿）Ｊ

あぼーん

終了？

age

どの処理系で作る？ウインドウズかJAVAか、、、
言語はＣ言語でないと私は会話に加われません。

あぼーん

やっと、荒しのローカルあぼ〜ん完了。良スレ発見sage。

議論が止まってるようなのでネタフリ。
それぞれのイメージはあると思うが、必要だと思うクラスを片っ端から
挙げてみるってのはどうかな？

あぼーん

class man{
int x;
int y;
int palet_no;
int pattern_no;
struct pow_stat;
};

class anim{
int flg; //use/not disp/hide
int stat; //etc
short direction;
short animation_no;
void disp_pattern();　//表示
void clr__pattern(); //消去
int touch_bg(); //背景との当たり判定
void move_charactor(); //移動？
};

int pokotin; //ポコチンフラグ

int型じゃないとダメなのか？

char型ｷﾎﾞﾝﾇ

　　　　　　　　　　　　　　　　ｏ.
　　　　　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　　　　　/　　　このｽﾚは無事に .　　/
　　　　　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　　　　　/　　　ﾍﾟｲﾋﾟｯﾆﾀﾞより　　　　 /
　　　　　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　/
　　　　　　　　　　.　/
　　　＿＿<｀∀´>./
　　／＿＿　＼　/
　　|　|　　 |　　|
　 （＿）　（＿＿）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

テスト

俺のHP。絶対来い


http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e
http://ip.tosp.co.jp/i.asp?i=1396e

ショートカットの幼い娘！といった感じのいずみちゃんです。
部屋の中のベンチでローターをクリにあてしきりにオナニーに励み、
男性二人に責められて喘ぎまくる姿が妙に色っぽいです。
感じやすそうなピンクの乳首もいいですよ。
セーラー服いっぱいで無修正！
無料ムービーいい感じだよ。
http://www.pinkschool.com/

>>267
業者のくせに、６行も使いやがって。

http://elife.fam.cx/a011/

てすと

保守

class Character {
long x,y,z;
long palet_id;
long pattern_id;
int lev;
int exp;
int hp;
int mp;
int str;
int def;
};

>>272
せめてメソッドくらい書こうよ

汎用フィールドクラス
ttp://d.hatena.ne.jp/kenmo/20050627#p1

struct power_stat {
　int lev;
　int exp;
　int hp;
　int mp;
　int str;
　int def;
};

class Chara {
　long px,py,pz;
　long palet_id;
　long pattern_id;
　struct power_stat;
};

struct power_stat
{
　　int lev;
　　int exp;
　　int hp;
　　int mp;
　　int str;
　　int int;
　　int def;
　　int mr;
　　int dex;
　　int agi;
};

struct visual_info
{
　　long px,py,pz;
　　long palet_id;
　　long pattern_id;
};

class Chara
{
　　power_stat power;
　　visual_info visual;
};

a

>>269から>>277までの９件の書き込みに２年半もかかってる件について

ベースクラスなんて人それぞれってことでしょか ^^