FC2ブログ
2010.02.21 攻撃する人
702 :名前は開発中のものです。:2008/02/02(土) 14:42:47 ID:mI6LOL9z
ム板のクラス名・変数名に迷ったら書き込むスレ。Part11でメソッド名を質問している内に
設計を見直したくなったので誘導に従い引越して来ました。

C++で練習用にドラクエモドキ作っているんですが

class PlayChara{
int hp;
int mp;

public:
void receiveAttack(ATTACK_TYPE atk_type, ATTACK_POINT atk_point);
}


プレイキャラクラス自身に敵からのダメージを与える為のメソッドで
(攻撃のタイプと攻撃力の引数を受け取る)receiveAttackってのを検討したんですけど
設計そのものを見直したほうがいいでしょうか?


・攻撃者が.attackメソッドを持って引数に被攻撃者のパラメータを渡す
・攻撃用のクラスそのものを作る


703 :名前は開発中のものです。:2008/02/02(土) 14:49:42 ID:nEhdyqU2
戦闘管理クラスみたいなので上からまとめてやっちゃう


704 :名前は開発中のものです。:2008/02/02(土) 14:53:31 ID:72phXJxx
なんでそんな小難しく考えるのかわからん。


705 :名前は開発中のものです。:2008/02/02(土) 15:03:58 ID:eaarCO+A
hp/mpをprivateにしてメソッドで操作するメリットは、
それらを操作するコードを制限できる点で、メンテナンス性向上を期待できる。

でも、ちゃんと管理できればpublicでも全く問題ないので、
このやり方で良いとも言えるし、このやり方でなくても良いと言えるけどねw


706 :名前は開発中のものです。:2008/02/02(土) 16:16:27 ID:sj8x5kQa
>>702
ドラクエならダメージの計算はキャラによらず一律だし、ダメージが
発生するタイミングや順序も明確だから、他の人が言ってる様に
計算式を実装するのはプレイヤークラスではなく、戦闘の進行
管理やってるクラス。

キャラクターごとに持っているパラメタが全然違って計算式が
異なるとか、キャラクタの内部状態によってダメージあり/なしが
変わる、またリアルタム進行でダメージ判定などタイミングが
シビアな場合には、プレイヤークラス内部で計算した方が
やりやすい。対戦格闘とか一部のアクション RPG とか。

ただ、その場合は receiveAttack() というように攻撃専用の
メッセージにせず、回復やらダメージやら全部含めた汎用の
メッセージクラスを一つ用意して、

void sendMessage(Msg const* pMsg);

で送りつけてやったほうが良い。あと、メッセージは即処理せず
キューにためておいて、あとでプレイヤークラスのほうで都合が
良いようにソートしたりしてから処理するとか、インスタンスの
ポインタ直接使わずにハンドル管理にするとかした方が良い。


707 :名前は開発中のものです。:2008/02/02(土) 17:20:36 ID:09h7GmI7
receiveAttack(ATTACK_TYPE atk_type, ATTACK_POINT atk_point)

damage(DAMAGE_TYPE dmg_type, DAMAGE_POINT dmg_point)
に改名すれば謎は全て解ける


708 :名前は開発中のものです。:2008/02/02(土) 19:05:26 ID:NHG8vmrt
俺なら戦闘進行クラスに行動のプライオリティキュー持たせてコマンドパターン突っ込んでキャラクラスにキュー見せるかな。
でキャラクラスはストラテジーパターンで行動処理を分けると・・・。
キャラクラスはキャラごとにインスタンス化して行動処理はストラテジーに分離。

ぱっと思いついたがこんなもんか。


709 :名前は開発中のものです。:2008/02/02(土) 19:08:36 ID:NHG8vmrt
忘れてた。
↑のコードをスクリプト言語内蔵してハードコーディングしないようにする。


710 :名前は開発中のものです。:2008/02/02(土) 19:11:17 ID:sj8x5kQa
>>709
ドラクエだと、コアロジックのスクリプト化は要らん気がするなぁ。

俺ならスクリプト指定にするのは、エフェクトとか SE 再生とかの種類・
タイミング制御と、あとはパラメタの定数設定ぐらいか。


711 :名前は開発中のものです。:2008/02/02(土) 19:48:03 ID:KbmRx+Ru
スクリプト化するかどうかとかは開発において本質的な部分じゃないし
今回の実装方法の話は好きにしろとしかいえんね


712 :702[sage]:2008/02/02(土) 21:06:24 ID:mI6LOL9z
>>706
有難うございます。

なるべく他のアクションゲームとかにも流用できる汎用性の高い作りにしようと
思っていたのでリアルタイムに仕様変更があっても対応できるように後者のような感じ
でやってみようと思います。

取り合えずクラス候補としてこんな感じでいこうかと。

・プレイキャラ(敵キャラ含む)
・成長管理
・戦闘管理
・シナリオ進行管理
・コマンドメニュー
・アイテム(装備品含む)
・ステージ(街、ダンジョン、フィールド含む)
・ショップ
・酒場(キャラ登録、出し入れ管理)


713 :名前は開発中のものです。:2008/02/02(土) 21:25:25 ID:sj8x5kQa
>>712
ふつーのRPGにするなら、まずシステム全体を
・戦闘
・フィールド
・デモ(イベント)
に分割して、それぞれの間のツナギを緩やかにしておく(直接インスタンス
参照せずに、パラメタ渡して立ち上げるようにする)、さらにサブシステムを
切り替えるときには画面ブラックアウトさせるようにしておくのが敷居低いよ。

装備品や戦闘中に利用できるアイテムに関しては戦闘システムに密に
絡むので、装備品のパラメタとして何をどう持たせるかなどは戦闘システム
中心で考える。

プレイヤーに関しても、戦闘で利用するプレイヤークラスとフィールドで利用
するプレイヤークラスは別にしとく。戦闘側プレイヤークラスではアイテムの
戦闘中効果や使用可/不可の管理なども要るけど、フィールドだと個数や
値段だけ管理しとけば良いから、必要な情報が全然違う。


715 :名前は開発中のものです。:2008/02/02(土) 23:15:59 ID:ld1ta0/w
>>713
> プレイヤーに関しても、戦闘で利用するプレイヤークラスとフィールドで利用
> するプレイヤークラスは別にしとく。


あ、それでいいんだ。
現にそうやってRPGのクラス設計してたけど、もしかしたらマズイやり方なんだろうかと
不安になってたとこ。これで前進できるよ~。

-----
ゲームにおけるデータ構造・クラス設計・パターン @ゲーム製作技術板 より
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226
Secret

TrackBackURL
→http://nullptr.blog70.fc2.com/tb.php/12-0a28f6e1