ゲームにおけるデータ構造・クラス設計・パターン

**名前は開発中のものです。** · 2006/08/10(木) 20:27:06

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

**名前は開発中のものです。** · 2007/09/27(木) 13:19:16

荒れていても技術的な話題が堪えることのない名スレ
でも最近少々荒れ気味だから皆落ち着け

**名前は開発中のものです。** · 2007/09/27(木) 14:40:58

落ち着いてないのは>>620くらいじゃ？
元々隔離板の過疎スレだから少数が騒ぐと目立つだけ。
またーりログ読んでるか、生温かい目で見守ってるのが大半じゃない？

**名前は開発中のものです。** · 2007/09/27(木) 23:24:46

言うに事欠いて「必死だな」で切り抜けようと試みる
古典的バカが未だに生き残ってるとは驚きだな

**名前は開発中のものです。** · 2007/09/27(木) 23:31:57

煽っても必死さが正当化されるわけじゃないよ

**名前は開発中のものです。** · 2007/09/27(木) 23:38:28

BohemGCｻｲｺｰ

**名前は開発中のものです。** · 2007/09/27(木) 23:47:44

「必死さが正当化される」ってのはよく分からないけど・・・
とりあえず、「必死だな」とか言う前に>>620を論破してみれば？
例えば、
１，BohemGCだけにある、もしくはJavaやC#のGCでは解決された重要な問題を列挙する
　　（数値とアドレス値が識別できないという問題はあるけど、確率的にそれが不都合になることはほとんどない）
２，吉里吉里にはBohemGCが向いていないことを示す他のソースを提示する
とかね。

個人的に１はとても興味があるので、問題があるなら教えて欲しかったりする。

**名前は開発中のものです。** · 2007/09/27(木) 23:48:30

>>620
本題からそれるけど、
> スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
> var a = [0];
> a[0] = a;
> これだけでメモリリーク起きるなんて、危なくて使えん。
スクリプト言語におけるインスタンスの寿命管理と、C++ インスタンスの寿命管理は
別の話だよね。

俺は VM のスタックは C++ のスタックを使わず、C++ で std::vector<> 使って確保した
記憶域を使ってる。でないとスクリプト一時中断する (co-routine 実装) のが難しい
からさ。

当然スタック上にあるスクリプト言語のインスタンスは全部 VM でトラッキングできる
ので、ガベコレできる。C++ 側のメモリ管理が GC 使ってるかどうかとは無関係に。

**名前は開発中のものです。** · 2007/09/28(金) 00:02:16

>>634
ようするに実装がスタックレスってことだな。
つかスタックレスでないVMにコルーチンを実装するのは不可能じゃないか？

**名前は開発中のものです。** · 2007/09/28(金) 00:23:32

>>635
多少制約がつくけど、Cスタックを保存・切り替えできればスタックフル VM でも
コルーチンは実装できます。

ただ、どうやってもポータブルなコードにはならないし、C++ 例外の実装方法に
よっては問題出るから、お勧めしないけど。

**名前は開発中のものです。** · 2007/09/28(金) 01:10:11

>>636
スタック切り替えてまでやるかｗ
猛烈に処理系依存なコードになりそうだな

**名前は開発中のものです。** · 2007/11/17(土) 17:10:37

戦闘シーンの進行管理をするクラスって、どういう名前にしたらいいんだろう？
BattleManagerかな…でもManagerは使うなって話もあるし。

**名前は開発中のものです。** · 2007/11/17(土) 17:27:39

>>638
Manager 使うなって話は、つまり「管理」というあいまいな言葉を使うなって話。
「戦闘シーンの進行管理をするクラス」の役割を見直さずに名前付けだけ考えてても
無意味。

**名前は開発中のものです。** · 2007/11/17(土) 17:45:31

>>639
レスありがとう

そう、今プログラム素人の子と話してたんだけど、
漠然と「場」みたいなもので考えるから名づけに迷うんであって、
相撲の行司みたいなのがいると仮定して、
そいつに戦闘の進行管理をさせればいいんじゃない？
という意見をもらった。

そこでまた、「戦闘の進行」っていう、時間を伴ったものを、
その「行司」の中に持たせちゃっていいのかなと迷うんだけど、
その辺りは割り切っちゃったほうがいいの？

OOPド素人丸出しでごめん

**名前は開発中のものです。** · 2007/11/17(土) 17:53:06

戦闘シーン関連の処理に関して、俺が抱いてるイメージとしての「管理」から考えると
そのManagerが関連する他のクラスに処理を分配して、それを仲介するようなクラスだとMediatorあたりになるんじゃなかろうか
俺が作ってた「Manager」は上記のものがさらにFacadeの役割も果たすってのが多かった
デザパタから借りてるだけで正解とはとても言えんけど、「Manager」よりはマシかな…と

**名前は開発中のものです。** · 2007/11/17(土) 18:09:05

>>640
> そいつに戦闘の進行管理をさせればいいんじゃない？

それじゃ何も解決しないでしょ。「管理」という役割が同じなままなんだから。

「管理って、実際のところ何するの？」と問い、「あれして、これする」っていう
もっと具体的な単位に分解できれば、「あれするクラス」「これするクラス」に分割する
ことが考えられる。それらを組み合わせたものを「戦闘シーン」というクラスにすることも
考えられる。

どうしても「管理」としか呼べないんなら、それを Manager と名付けること自体には
何の問題も無い。

「戦闘の進行」と「行司」という切り分けができるなら、前者を Advance() なんていう
関数、後者を Rule とかいうクラスにすることが考えられる。 Advance() は Rule に
従って処理をする、って感じね。具体的な状況がわからないんで、全然ダメかも
しれないけど。

**名前は開発中のものです。** · 2007/11/17(土) 18:34:11

SceneManagerとか定番だな

**名前は開発中のものです。** · 2007/11/17(土) 18:35:34

javaの立場が・・・

**名前は開発中のものです。** · 2007/11/17(土) 20:30:54

class Referee
{
public:
　　Referee(const class Rule& current_rule);

　　const bool judge(const class Battle& current_battle);
　　void bribe(const int price);

　　inline void win(void) { http://youtube.com/watch?v=ubhW9R-F7cM }
};

**名前は開発中のものです。** · 2007/11/17(土) 21:45:56

>>644
？

**名前は開発中のものです。** · 2007/11/18(日) 06:00:26

使うなとは誰もいってないよ

**名前は開発中のものです。** · 2007/11/18(日) 07:27:13

>>642
俺の場合、Manager って名前は使っちゃうな。ただし Manager クラスで
何でもかんでも処理せずに、分割できるところは別のクラスに切り出して
Manager クラスに集約する。

Facade やね。

**名前は開発中のものです。** · 2007/11/20(火) 01:41:42

さっきからしょぼいＢＧＭのループがひどいな
２ループもすりゃ十分だろ

**名前は開発中のものです。** · 2007/11/20(火) 02:00:34

>>649
何に対して言ってるのか

**名前は開発中のものです。** · 2007/11/20(火) 06:51:02

B・・・・・GM・・？

**名前は開発中のものです。** · 2007/11/24(土) 17:27:35

シューティング作ってて、敵のクラスと自機のクラスを分けちゃったけど、わけない方がスマートだったかなあ

**名前は開発中のものです。** · 2007/11/24(土) 17:36:40

>>652
一部同じインターフェースを持つことはあるだろうけど、普通に考えてまったく同じクラスに
なるとは思えない。

**名前は開発中のものです。** · 2007/11/24(土) 19:10:43

自分は敵１と敵２とかでもわけてる

**名前は開発中のものです。** · 2007/11/24(土) 21:09:45

>>654
そりゃ、作るゲームにもよるな。キャラクター数少なくて差異が大きい場合には
クラス分けるが、RPG のように数が多いと基本1クラスでデータ駆動にする。

**名前は開発中のものです。** · 2007/11/24(土) 22:25:37

>>652
何シューティングか知らないが、
よくある２Dのシューティングなら自機と敵機で違う処理したほうが、
当たり判定の最適化しやすそうだな。
（同じ基底クラスから派生させるとかいう話はおいといて、

**名前は開発中のものです。** · 2007/12/23(日) 16:09:31

シューティングでも、データ駆動（簡易スクリプトもしくは、相当するもの）
がお勧め。

俺は、クラス志向でやってたら、敵、弾のクラスが200超えたあたりで、死んだ

**名前は開発中のものです。** · 2007/12/23(日) 17:43:24

もっと詳しく。
数の多さからの管理の複雑化という問題だとしたら、
データでもクラスでも一緒だと思うんだが。

**名前は開発中のものです。** · 2007/12/23(日) 17:48:27

、>>657は敵の動きや弾の速度やダメージなんかを全部
コード中に書いてたんじゃね

**名前は開発中のものです。** · 2007/12/23(日) 18:00:13

DIO「所詮OOPはゲームプログラミングの亜流！データドリブンに敗北する定めよおおおぉっ！！」

**名前は開発中のものです。** · 2007/12/23(日) 18:27:09

実際に完成したゲームのデータj構造・クラス設計が王道。

**名前は開発中のものです。** · 2007/12/23(日) 20:45:04

ＲＰＧゲームのクラスを作ろうとしているのですが・・・
http://www.kent-web.com/pubc/book/test/uploader/uploader.cgi?mode=downld&no=530
キャラクタークラスや技エフェクトクラスにも画像データを持たせたいのですが、描画処理クラスの下に
キャラクタークラスを置くべきでしょうか？それとも多重継承で描画処理クラスのデータを継承させたほうが良いでしょうか？
描画処理クラスでは画像のデータや実際に描画する関数など描画データを統合して持っています。

他にもこうした方がいいというところがあればお教え下さい。
よろしくお願いしますm(_ _)m

**名前は開発中のものです。** · 2007/12/23(日) 21:13:08

２Ｄゲームだと仮定すると
キャラクタークラスがコピーする画像の種類、座標と大きさをパラメで持ってればいい
変数５個ぐらいだからあとはそれを描画クラスに渡して描画されるしくみがあればおｋ

エフェクト関係の位置が微妙に変だと思う
あれは継承？それとも集約（コンポジション）？

あと図の矢印が継承と集約混ざっててわかりにくす
あれが全部継承なら最初から作り直し

**名前は開発中のものです。** · 2007/12/23(日) 21:20:38

>>659
そのとおり
で、途中からやばいことに気づいて（そら100もクラス作ってたら、気づくわｗ）
スクリプトで外に出したりしてたら、
かなーりカオスに・・・

**名前は開発中のものです。** · 2007/12/23(日) 21:22:59

>>662
矢印の関係、向きがグチャグチャだなおいｗ
UML関連の入門記事をさらっと読んだ方が、いいよ

本まで買って厳密にやることはないが

**名前は開発中のものです。** · 2007/12/23(日) 21:35:43

>>659
それのどこがやばいのかよく分からないなぁ。

>>664
本当に必要なものならクラス数は増えても良い気がするけど。

**名前は開発中のものです。** · 2007/12/23(日) 21:38:17

.NETだったらコンパイルも早いし、dllに分けてスクリプト言語で書いたりもできるから
派生クラスで全部書いちゃってもいけそうだな

**名前は開発中のものです。** · 2007/12/23(日) 21:39:00

>>664
ふつーは、プレイヤー弾クラス、敵弾クラスとか作って、そいつがパラメタを
ファイルから読み込む or スクリプト駆動にするわな。パラメタ変更では手に
負えないような差異がある場合（バラバラの弾とレーザーとか）は、そこを
クラスに切り出す。

どこまでプログラムで書いて、どこからスクリプト or データ駆動にするかは
センスの問題。何でもかんでもスクリプトで書くと、結局 C++ で書くより手間
かかるだけだしなｗ

**名前は開発中のものです。** · 2007/12/23(日) 21:41:05

>>663
描画処理にキャラクターのデータを渡すだけでいいのですね。
図は全て継承の意で矢印を書いてしまいました。
継承と集約の相違点と関係を見直してもう一度はじめから考え直してみます。
>>665
確かに書き方が全く成っていませんね・・
ネットでＵＭＬを説明してる所へ行ってみます！

ご指摘ありがとうございました。
大変ためになりました＞＜

**名前は開発中のものです。** · 2007/12/23(日) 21:42:05

このキーワードを出すと荒れそうだけど、やっぱりデザインパターンは
一通りかじった方が良いと思うよ。そうしたら、何が悪いか見えてくる。

あと、基本的に継承しまくるのは良くない。継承よりも委譲で処理した方が
スッキリする場面が多い。

**名前は開発中のものです。** · 2007/12/23(日) 21:44:24

>>662
まずゲーム上の意味を持たず、単純に描画関連の処理だけ行うクラスを作る。
3Dモデル、2Dスプライトとかな。

その上で、次に、3Dならモデルのモーション制御用のクラスと、2Dスプライトなら
テクスチャアニメーションや拡大縮小アニメーションなどを行うクラスを用意する。

最後に、ゲーム的に意味があるクラス（技エフェクトクラスとか）は、上記クラスの
インスタンスをメンバ変数に持たせて使う。間違っても継承するなよ。

**名前は開発中のものです。** · 2007/12/23(日) 23:44:07

>>670
>>671
なんでもかんでも継承すればいいというわけではないのですね・・・
is-a関係とhas-a関係をよく確かめます。
ありがとうございました。

**名前は開発中のものです。** · 2007/12/24(月) 01:50:39

>>672
慣れてくると悟れるようになるけど、
HogeHogeUtil
っていう名前にできるものはオブジェクトにしちゃいかんよ。

StringUtil、DBUtil、CSVUtil、DrawUtil、SpriteUtil、etcetc...

こういう「いつでもどこでも使う」ものは、本質的に
状態を持たない（＝オブジェクトにはならない）もの。
これらはスタティックに関数を定義しておけばそれでOK。
初心者はここを勘違いして地獄を見ることになる。

ま、慣れてくれば分かるさ。

**名前は開発中のものです。** · 2007/12/24(月) 03:14:08

そういう機能メソッドのstatic化って今までとても気持ち悪く感じていた。
C#の拡張メソッドみたいなものはもっと以前からあって然るべきだった。

**名前は開発中のものです。** · 2007/12/24(月) 08:33:00

どうしてもクラスにしたいならシングルトンパターンだな

**名前は開発中のものです。** · 2007/12/24(月) 13:19:10

>>657
スクリプトでも下クラスでも同じだろ?

どっちに記述するかの問題だが
IDEサポートある環境ならクラスのほうが見通しやバグがへる

**名前は開発中のものです。** · 2007/12/24(月) 13:28:54

>>676
> スクリプトでも下クラスでも同じだろ?
スクリプトとかデータファイルだと、

1) 必要最小限のことしかできないように制限かけておく
2) 少ない記述量で済むようにする

から、量産するときに手間が減る。あとプログラマが一人で全部作る場合は
良いんだが、企画やスクリプタに調整してもらう場合は、開発環境そのまま
渡すのはいろいろコストが高くつく。

**名前は開発中のものです。** · 2007/12/24(月) 13:38:18

あとしょぼいとはいえ技術情報だだもれのうえソース持ち逃げ逃亡の可能性もでる（同人の場合）

**名前は開発中のものです。** · 2007/12/24(月) 14:26:45

>>677
いや、データの一元管理をしたいならクラスにまとめてかいとけばいい
だからどこに書くかどうかという程度の問題だからかわらん
外部ファイルだと整合性が取れない場合とかそういうことも考慮しないと

**名前は開発中のものです。** · 2007/12/24(月) 14:59:36

>>678
むしろ同人以上に仕事でやってるときのほうがソースの中とか見せたら危険すぎだね…

>>657
ま、そのくらいの規模になったらデータ化したほうがいいっすな。

**名前は開発中のものです。** · 2007/12/24(月) 15:11:02

>>679
> 外部ファイルだと整合性が取れない場合とかそういうことも考慮しないと
外部ファイルも事前にコンバートするから、そこで整合性担保するでしょ。

テキストで書いておいて、ツール使って実行時環境の構造体に直接マッピング
できる形に変換。実行時にテキストパーするなんて、エラーチェックの意味でも
実行効率の点でもありえんので。

開発効率に関してはたとえば、

　ATK=100,THROUGH=1

とか書くのと、

struct Shot1 : IShot {
　　virtual int getAttackPoint() const { return 100; }
　　virtual bool canThrough() const { return true; }
};

とするのと、どっちが楽かって話だよな。プログラマならともかく、それ以外の人間に
後者はありえんと思う。

**名前は開発中のものです。** · 2007/12/25(火) 00:11:32

技術者以外でコードさわらせることってある？
その程度がかけない人を使う場合はツールつかうでしょ

**名前は開発中のものです。** · 2007/12/25(火) 07:00:22

>>682
> 技術者以外でコードさわらせることってある？
ない。

人数増えると、開発環境をセットアップ・メンテナンスしたり、ソフトウェアの
ライセンス費用だけでも馬鹿にならんし。

**名前は開発中のものです。** · 2007/12/27(木) 14:55:37

アクションゲームのプレイヤーキャラクター、エネミーの状態遷移はどう管理するべき？
タスクシステムとか使うんでしょうか？

**名前は開発中のものです。** · 2007/12/27(木) 18:41:38

Cならタスクシステムで良いと思うけどOOPでタスクシステムは勝手が悪いだけだぞ。

というかタスクシステムの話は荒れるからやめれ。

**名前は開発中のものです。** · 2007/12/27(木) 18:43:32

>>684
単純に書くなら、プレイヤーとかエネミークラスのメンバ変数として状態変数を持たせる。

class Enemy
{
　　enum STATE { STATE_INIT, STATE_LOAD, STATE_ATTACK, STATE_DOWN } m_state;
public:
　　void exec() {
　　　　switch (m_state) {
　　　　case STATE_INIT:
　　　　　　　// 必要な処理。状態遷移は m_state の値を上書きすることで行う。
　　　　　　　break;
　　　　case STATE_LOAD:
　　　　　　　break;
　　　　}
　　}
};

入退場動作を記述したいとか、状態遷移が複雑で手に負えなくなったら、
XML なり CSV なりで書いた状態遷移表から C++ のコードを自動生成する
トランスレータ書くとか、階層化状態をサポートするライブラリ (有名どころ
だと Boost Statechart とか) を入手して使う。

**名前は開発中のものです。** · 2007/12/27(木) 18:51:03

関連でboost FSMって言うのがあるんだけど
ゲームならこちらの方がいいかも
(state_chartと違ってコストがポインタ経由の関数呼び出しと同等程度)

**名前は開発中のものです。** · 2007/12/29(土) 19:02:05

>>684
こちらへどうぞ

タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/

**名前は開発中のものです。** · 2007/12/29(土) 19:05:56

>>686
前に作ってたプロジェクトで、
30個くらい状態ができて、exec相当の関数が長くなりすぎ、
関数内関数にしたものの、死にそうに。

こういうときは、やっぱり、データ駆動にすべきなんかね

**名前は開発中のものです。** · 2007/12/29(土) 20:33:51

俺だったらまず階層化を考えるかな。
>>686の状態列挙子を

　　enum STATE { STATE_INIT, STATE_LOAD, STATE_ALIVE, STATE_DEAD, } m_state;

と変更して、STATE_ALIVEのとき

　　enum ACT_STATE { STATE_MOVE, STATE_ATTACK, STATE_DOWN, } m_act_state;

を参照するとかね。

**名前は開発中のものです。** · 2007/12/31(月) 13:37:37

>>689
関数の作成単位を処理毎 (exec(), draw()) から状態毎 (_stateAlive(),
_stateDead()) にして、各関数の中に exec, draw なんかの処理を
書くよう逆転させるとメンテナンスが楽になるよ。

実装はこんな感じ。
ttp://gameobj.issei.org/trac/wiki/HSM

それでも複雑になってきたら、更に状態ごとにスクリプトを貼り付ける。
状態遷移の入場動作でスクリプトを読み込み VM を設定、exec 相当の
処理ではスクリプトの VM を実行するように書く。

どこまで C++ で書いて、どこからスクリプトにするかは、一律の答えが
ないので難しい。作業を一人でやるか分担するかにもよるし、仕様変更を
どこにどれだけ見込むかにもよる。ただリソース（メモリとかテクスチャとか）の
確保・解放が絡んだら、経験上、そこは C++ で処理した方がトラブル少ない。

**名前は開発中のものです。** · 2008/01/02(水) 03:34:31

実は、>>689の後のプロジェクトでは、苦肉の策で、
簡単な非階層型の状態遷移クラスを作って対処してた。

状態ごとに派生クラス作ると、しんどかったので（これもかなりやってた）
結局、できるだけ、簡易的にするために、
draw、exec はメソッドポインタにして、状態遷移クラスに持たせ、
状態遷移クラスのdraw、execでそれらを呼び出すことに。
これなら、派生クラスを大量に作る必要がなく、気が楽（笑）

呼びたい entity に、1状態につき、initialize_hoge、draw_hoge、exec_hoge メソッドを作り、
状態遷移時に（initialize_hoge内で）、状態遷移クラスにメソッドポインタを割り当て、遷移させてた。

まあ、結局、entityのメソッドが増えるのと、階層化ができないのがキズ。
階層化は、状態遷移クラスをさらに持たせて、実現してたけど

**名前は開発中のものです。** · 2008/01/02(水) 06:36:13

>>691
ありがとう。

あー、逆の発想か・・・
ナルホ・・・

HSMは、（・∀・）ｲｲ！って聞いてたけど、実際の実装を見たことがなかったので、
参考になります。
じっくり見てみる。

しかし、勉強セナあかんな・・・

**名前は開発中のものです。** · 2008/01/02(水) 20:15:35

>>692
> これなら、派生クラスを大量に作る必要がなく、気が楽（笑）
GoF のステートパターンよろしく、状態ごとにクラスを作るか
それともクラス一つで済ませるかも場合によるよね。

AIとかシーンのように、各状態がそれなりに複雑で個別のメンバ
変数を大量に持つような場合は、状態ごとにクラス分けた方がいい。
アクションゲームのキャラクタ程度だと、クラス分けるとクラス間の
データ受け渡しの手間がかかりすぎ。

**名前は開発中のものです。** · 2008/01/05(土) 01:21:42

(ﾟДﾟ)

**名前は開発中のものです。** · 2008/01/05(土) 01:23:01

(･∀･)

**名前は開発中のものです。** · 2008/01/11(金) 13:18:44

age

**名前は開発中のものです。** · 2008/01/25(金) 11:38:57

保守

**名前は開発中のものです。** · 2008/01/25(金) 20:32:41

＾＾

**名前は開発中のものです。** · 2008/01/25(金) 20:33:24

随分漏れのIDにCが多いな。

**名前は開発中のものです。** · 2008/01/25(金) 20:37:13

VIAのCPUがいる

**名前は開発中のものです。** · 2008/02/02(土) 14:42:47

ム板のクラス名・変数名に迷ったら書き込むスレ。Part11でメソッド名を質問している内に
設計を見直したくなったので誘導に従い引越して来ました。

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

class PlayChara{
int hp;
int mp;
…
public:
void receiveAttack(ATTACK_TYPE atk_type, ATTACK_POINT atk_point);
}

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

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

**名前は開発中のものです。** · 2008/02/02(土) 14:49:42

戦闘管理クラスみたいなので上からまとめてやっちゃう

**名前は開発中のものです。** · 2008/02/02(土) 14:53:31

なんでそんな小難しく考えるのかわからん。

**名前は開発中のものです。** · 2008/02/02(土) 15:03:58

hp/mpをprivateにしてメソッドで操作するメリットは、
それらを操作するコードを制限できる点で、メンテナンス性向上を期待できる。

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

**名前は開発中のものです。** · 2008/02/02(土) 16:16:27

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

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

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

void sendMessage(Msg const* pMsg);

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

**名前は開発中のものです。** · 2008/02/02(土) 17:20:36

receiveAttack(ATTACK_TYPE atk_type, ATTACK_POINT atk_point)
を
damage(DAMAGE_TYPE dmg_type, DAMAGE_POINT dmg_point)
に改名すれば謎は全て解ける

**名前は開発中のものです。** · 2008/02/02(土) 19:05:26

俺なら戦闘進行クラスに行動のプライオリティキュー持たせてコマンドパターン突っ込んでキャラクラスにキュー見せるかな。
でキャラクラスはストラテジーパターンで行動処理を分けると・・・。
キャラクラスはキャラごとにインスタンス化して行動処理はストラテジーに分離。

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

**名前は開発中のものです。** · 2008/02/02(土) 19:08:36

忘れてた。
↑のコードをスクリプト言語内蔵してハードコーディングしないようにする。

**名前は開発中のものです。** · 2008/02/02(土) 19:11:17

>>709
ドラクエだと、コアロジックのスクリプト化は要らん気がするなぁ。

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

**名前は開発中のものです。** · 2008/02/02(土) 19:48:03

スクリプト化するかどうかとかは開発において本質的な部分じゃないし
今回の実装方法の話は好きにしろとしかいえんね

**702** · 2008/02/02(土) 21:06:24

>>706
有難うございます。

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

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

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

**名前は開発中のものです。** · 2008/02/02(土) 21:25:25

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

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

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

**名前は開発中のものです。** · 2008/02/02(土) 22:11:59

俺今Java MEのMIDP上に汎用のゲームミドルウェアとほかのライブラリに組み込んで使う
AVGエンジン作ってるが設計は使ってる言語とプラットフォームによると思う。

たとえばCだとOOPが言語仕様にあるわけじゃないから再利用性のあるライブラリは作りにくいと思うし、
MIDPみたいなリソースが限られてる環境上だと制限多いし。

**名前は開発中のものです。** · 2008/02/02(土) 23:15:59

>>713
> プレイヤーに関しても、戦闘で利用するプレイヤークラスとフィールドで利用
> するプレイヤークラスは別にしとく。

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

**名前は開発中のものです。** · 2008/02/02(土) 23:17:36

>>714
> たとえばCだとOOPが言語仕様にあるわけじゃないから再利用性のあるライブラリは作りにくいと思うし、
それはない。ただ設計が OOA/OOD じゃなくなるだけ。

むしろソース非公開でライブラリ配る場合は C++ より C の方がバイナリ
互換性を維持するの楽だし。C++ だとメンバ変数ひとつ加えただけで
バイナリ互換性崩れるから COM のようにインターフェースと実装を厳密に
分離するような細工が必要になってくる。

社内ライブラリとかでも公開 API は extern "C" してあって、中が C++
なんてのは未だに良くある。

**名前は開発中のものです。** · 2008/02/02(土) 23:22:17

中身も全部 C っつーのも、もちろん良くある。

**名前は開発中のものです。** · 2008/02/03(日) 02:15:42

見てる人自体は結構いるんだなとしみじみ感じた。

**名前は開発中のものです。** · 2008/02/03(日) 15:45:30

全部ベターCってのもまだいるな

**名前は開発中のものです。** · 2008/02/05(火) 01:04:17

さすがにそれは設計だのライブラリ配布だの以前の

**名前は開発中のものです。** · 2008/02/05(火) 15:29:46

C++でオブジェクト指向を生かすにはゲームはちょっときつい
フラグメントの問題が面倒だしな

PCのようにリソースが多い場合はJava等でOpenGLベースで作ったほうが楽かも

**名前は開発中のものです。** · 2008/02/05(火) 17:47:40

VGAドライバーのバグがどうしても回避できないからイマイチ安定しないよ、JOGL。
fpsはかなり出るんだが。

**名前は開発中のものです。** · 2008/02/05(火) 20:50:19

>>722
具体的に

JOGL単体だと不具合はまずでない

**名前は開発中のものです。** · 2008/02/05(火) 21:18:49

>>721
> C++でオブジェクト指向を生かすにはゲームはちょっときつい
PS2 の頃から、ゲーム部分はほとんど C++ だよ。

**名前は開発中のものです。** · 2008/02/06(水) 01:01:34

C++ に GC 付きの軽量スクリプト載せるのが主流じゃね？
フラグメントがどうとか言ってメモリのやりくり縛ってるような人は、
GC 付き言語は絶対導入しないってことなんだろうか？

**名前は開発中のものです。** · 2008/02/06(水) 01:37:49

>>273
GF7600GTと特定のドライバで出る。ドライバのバグだといっただろJOGLの問題じゃない。
後はググレ

**名前は開発中のものです。** · 2008/02/06(水) 02:46:02

>>725
コンシューマとかサーバーとかは普通に気にするだろ
だから、素の状態だと使えん
GCつきなら問題はないが、フットプリント大きくなるからコンシューマでは採用しにくい

>>726
そんな特定のドライバで動かないといったらそんなのは大量にあるわけだが

**名前は開発中のものです。** · 2008/02/06(水) 06:22:47

>>727
> コンシューマとかサーバーとかは普通に気にするだろ
メモリに関しては断片化と使用量の問題がある。

断片化はモデル・テクスチャ・モーションといった数百KB単位の
リソースデータと C++ インスタンスのようなせいぜい数KB程度の
データを混在させると問題になる。最初からヒープ領域を分けて、
リソースに関しては
・事前に複数ファイルをアーカイブして1つにまとめておく
・ファイル読み込み領域を階層化して管理
・用途によっては固定長で
とすることで解決できる。

使用量は頑張れとしか…

>>725
GCつきの言語は使ってないなぁ。lua とか悪くないとは思うんだが。

メモリ使用量やCPU消費が読めないのと、そもそもスクリプタに
高度なロジック書かせない方針なので、そこまで高機能な言語は
要らなかった。

ストラテジー系のゲームで AI とかスクリプト化するとなると、Lisp
系言語を使うかもしれん。実装簡単だし。