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

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

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

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

**名前は開発中のものです。** · 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
系言語を使うかもしれん。実装簡単だし。

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

>>728
だから、素の状態では使えないと書いた
固定長とかしばってるとC++らしいオブジェクト指向のコードが書けなくなる

結局クラスが名前空間程度のベターCでおわってしまう

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

D言語で良いんじゃね？
バグだらけだが

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

>>729
> 固定長とかしばってるとC++らしいオブジェクト指向のコードが書けなくなる
断片化が問題になるのはリソースデータだから、そっちだけ固定長とか
縛り入れる。

他は気にせず new しても、ヒープ多めにとっておけば大丈夫だよ。

**名前は開発中のものです。** · 2008/02/07(木) 02:50:44

>>731
newとdelete繰り返しているとフラグメントがぐちゃぐちゃに

**名前は開発中のものです。** · 2008/02/07(木) 04:12:05

つプールかスラブ

**名前は開発中のものです。** · 2008/02/07(木) 08:58:00

>>732
ゲームの場合はたいていインスタンスの寿命が入れ子状になってて、
寿命がやたらに長いインスタンスが不定期のタイミングで作成される
ことは少ない。

delete されたときに、積極的に前後のアドレスの空きスペースと融合
するたいぷのメモリアロケータ使ってれば、そんなに酷いことには
ならんよ。

これがサーバ系だと、また話が変わって来るんだが。

**名前は開発中のものです。** · 2008/02/07(木) 09:25:32

>>706
702じゃないけど、なんか目からうろこだわ。Thanks!!

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

new を使わなければすべて解決

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

まぁゲームで new とか使わんな。ポインタも殆ど使わん。

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

そんなプログラムはゴミ箱へ

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

プログラマもゴミ箱へ。

**名前は開発中のものです。** · 2008/02/09(土) 18:50:29

ゴミ箱はリサクル。

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

なるべく一般性の高いゲームの骨作りをしたいんだけど
みんなどうしているんだろう…
CGやBGMのロード、キーチェックをどこで実施すべきか悩んでしまう
↓だいたいこんな感じで組んでいるけど変？
//----main.cpp----
int WINAPI WinMain( ... ){
GameFrame *game = new GameFrame();
game->doMainLoop();
delete game;
}
//---gameframe.cpp---
void GameFrame::doMainLoop();{
loadCG();//ここ？
loadBGM();//ここ？
while(ProcessMessage()==0 && ...){
switch(gameState){
case GAME_DEMO : drawGameDemo ();break;
case GAME_TITLE : drawGameTitle();break;
case GAME_MAIN : drawGameMain ();break;
...
}
...
}

void GameFrame::drawGameMain(){
checKey();//どこに入れよう？
drawBG();
drawEnemy();
drawPlayChara();
drawHoge();
}

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

class Task { public: virutal ~Task() {} virtual void exec() = 0; virtual void draw() const = 0; virutal bool needGC() const = 0; };

void GameFrame::doMainLoop() {
　// シングルトン系の処理実行
　g_pad.exec(); // パッド入力処理
　g_file_loader.exec(); // ファイル非同期読み込み処理
　// その他の処理実行
　std::for_each(m_task_list.begin(), m_task_list.end(), boost::bind(&Task::exec, ::_1));
　std::for_each(m_task_list.begin(), m_task_list.end(), boost::bind(&Task::draw, ::_1));
　m_task_list.remove_if(boost::bind(&Task::needGC, ::_1));
}

こんな感じだと思うが。ファイルの読み込みは Task 派生クラスの exec の中で

TestTask1::exec() {
　　switch (m_state) {
　　case INIT:
　　　　g_loader.load("file1.arc");
　　　　++m_state;
　　　　break;
　　case LOADING:
　　　　if (g_loader.isLoaded("file1.arc"))
　　　　　　++m_state;
　　　　break;
　　case MAIN:
　　　　...
}

って感じで。マジメに作るとファイルは事前にアーカイブ＆圧縮しておいて、ロード時に
展開するとか、そもそも名前ではなく #define シンボルで扱えるようにして下らないバグを
出さないようにするとか、断片化防ぐためにメモリのセグメント分割するとか、いろいろ
あるけど。

**名前は開発中のものです。** · 2008/02/19(火) 23:21:10

>>742
過疎っている思ったのに光速レス有難う。
なんかタスク管理とか高度でかっこいいですね。
デザパタとboostをもうちょい勉強してみます。
自分のはなんかCでやってたことをクラスに詰め込んだだけっぽい。

**名前は開発中のものです。** · 2008/02/19(火) 23:24:49

タスクというと、タスク原理主義者の襲撃受けるのでアレだがｗ

直接 m_task_list に突っ込むのは、いわゆるシーンオブジェクトぐらいに
しておいたほうが良い。個々のキャラクターとかエフェクトの類は、派生
クラス (TastTask1 とか) のメンバ変数で持たせる。

m_task_list は見て分かるように exec, draw 両方とも引数ないので、
これだと相互作用するようなインスタンスをうまく扱えないので。

**名前は開発中のものです。** · 2008/02/20(水) 00:09:11

>>706とかでもありましたけど
タスクにキューをためるような処理の仕方が一般的なんですね。
自分はそういうスタイルで組もうとしたことがないので色々と勉強しないと…

**名前は開発中のものです。** · 2008/02/20(水) 00:09:55

に×
を○

**名前は開発中のものです。** · 2008/02/21(木) 01:33:19

>>741-742
いきなり、スレタイ否定だが、
本気で一般性の高いのを目指すなら、
ここで聞くより、ソースが見られるゲームエンジン見た方が100倍いい。
力がつくよ。
俺もいろんなソースみて力つけてきた

**名前は開発中のものです。** · 2008/02/21(木) 08:24:03

>>747
どのエンジンが勉強に良かったか教えてくれ。

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

言語の講座は大量にあるけど
設計の講座はさっぱり見当たらないな。
実装部分の詳細はよくみつかるけど

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

>>747
俺も聞きたい。どんなエンジンを見てきたの？

**名前は開発中のものです。** · 2008/02/21(木) 16:09:59

>>747
>>741のようなCの延長的な書き方でクラスで関数を纏めただけじゃん
みたいにしか組めない俺もききたい。

**名前は開発中のものです。** · 2008/02/21(木) 20:26:16

yaneSDKとかｗ

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

　　　　　　　　　　 . ｨ
.._ .......､._　　　 _　／:/l!
　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　_
ﾞ､'､::::::ﾉ:::::::_,.-=.　 _～:、　　　　／_.}'':,
　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._　／_ﾞ''iﾞﾉ､ﾉ
　,.--l‐''"~..-_'.x-='"ﾞｰ､`'-､　,:'　　ﾉﾞﾉﾌﾞ
"　　 .!-'",／　 `'-‐'') /＼　`/　てﾞノ-〈
　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.,'　　 ~　／
　　／/:::::　　　　　 ',　　 /　　　 ,:'ﾞ

**名前は開発中のものです。** · 2008/02/25(月) 00:12:54

マジレスすると「ゲームデザイン」の中の人最強だろ

**名前は開発中のものです。** · 2008/02/25(月) 03:05:17

ゲームデザインでググって一番上に来る人のことですよね？
そうじゃなければ自演乙

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

間違えた。
ゲームデザインの方じゃなくてABA Games最強だろ。

なんか俺の脳内で一緒になっていた

**名前は開発中のものです。** · 2008/02/26(火) 15:08:24

>>753がマスターシャーフーに見えたｗ

**名前は開発中のものです。** · 2008/02/26(火) 15:52:10

ご冗談をｗ

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

首があるから「ネコ～」じゃないよ。

**名前は開発中のものです。** · 2008/02/26(火) 20:11:44

カリンさまだろ？

**名前は開発中のものです。** · 2008/02/26(火) 23:56:46

ゲームのHPとかMPみたいにMAX値を超えたり0を下回ると困る数字の処理って
一般的にはどうしているんでしょう？
↓みたいな感じでやっているんですけど

class MyFunc{
public:
　　　　　　　//上限を超える、0を下回るときの処理
　　　　　　　static float trimZeroMax( float val, float val_max ){
　　　　　　　　　　　　　　if ( val > val_max ) { val = val_max; }
　　　　　　　　　　　　　　if ( val < 0 ) { val = 0; }

　　　　　　　　　　　　　　return val;
　　　　　　　}
};

//使うとき（ダメージ処理、回復処理の後）
hp = MyFunc::trimZeroMax( hp, hp_max );

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

プロパティが使えない言語なのか

**名前は開発中のものです。** · 2008/02/27(水) 00:07:04

>>761
それで数値がMAXまで行ってクリッピングされた時に
音を鳴らしたい場合どうする？
ポインタ渡しの引数増やすのも気持ち悪いし
GetLastError() みたいな別関数で状態を取得するのも気持ち悪い

**名前は開発中のものです。** · 2008/02/27(水) 00:07:18

見るからにC++だからなぁ。

俺なら数字っぽく扱えるクラスを書いて、
operator+()の中で範囲チェックするかなー。

**764** · 2008/02/27(水) 00:09:34

追記
>>763みたいな要求にこたえるときは、
作ったクラスにコールバックの仕組みを追加する、とかの方法で実現できる。
クラスのクライアントに対しては修正いらないはずだし。

**名前は開発中のものです。** · 2008/02/27(水) 00:30:52

プロパティが何だか分からなくて心が折れた。

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

要はgetHPとsetHPのこと

**名前は開発中のものです。** · 2008/02/27(水) 00:35:39

…VBとかの機能か。

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

>>761
言語がHSPなので参考になるかわからんが、

isover(val, min, max) //溢れ判定
irange(val, min, max) //上限下限
itorus(val, min, max) //ループ
ibound(val, min, max) //跳ね返り

の４つでだいたい足りている。

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

>>761にプロパティを使うのは不適切だね
プロパティは外から見てフィールドのように振舞うべき
101をセットして1が返ってくるのは直感的じゃない

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

java使いの俺も泣けてきた。プロパティの仕様でカオスってる。
アクセッサメソッドでいいじゃん。getter/setter。

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

プロパティを使うときの一番ありふれた事例が
上限下限のコントロールかと思ってた……

まあ1人で開発するから問題にはなんないけど

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

max(0, min(val_max, val));

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

その程度の計算にしては高価じゃない

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

デバッグで失われる時間のほうが高価なので
どんどん怠けましょう。

**761** · 2008/02/27(水) 02:08:49

getter/setterとかのメソッド≒プロパティというんでしょうか？

プレイキャラクターのクラスにダメージやら回復やらを処理させるメソッド内で
件の自作関数を呼び出しています。同じような処理ばかりあちこちにガリガリ書いていたもんで…

↓みたいにクラス化してしまう方が一般的ですかね
class LimitFloat{
//.なんか勝手に良い感じにしてくれる処理
…
};

class PlayChara{
LimitFloat hp;
LimitFloat mp;
…
};

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

>>776
直接的なプロパティへのアクセスを許可すると
情報隠匿の観点からマズイので、getter/setterを噛ませるってだけ。
プロパティ自体は
http://e-words.jp/w/E38397E383ADE38391E38386E382A3.html
こんな感じ。
文字列なら、文字列長や、文字エンコーディング。
mp3ならアーティスト名とか曲名。

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

いやプロパティはアクセス時にgetter/setterが呼ばれる変数みたいなもんだろ。
プロパティが言語仕様にある言語て何があったっけ？

esのプロパティはスロットだし

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

触ったことある言語の中だとC#にはあったな。

**名前は開発中のものです。** · 2008/02/27(水) 07:04:41

>>761
bool add_ubound(float& x, float xmax, float add)
{
　　assert(x > 0);
　　assert(add > 0);
　　asert(xmax > 0);
　　assert(x <= xmax);

　　x += add;
　　if (x > xmax) {
　　　　x = xmax;
　　　　return true;
　　}
　　return false;
}

>>763
if (add_ubound(hp, MAX_HP, 10)) {
　　playSound();
}

ベタだけど、こんな感じで処理してる。あと >>769 みたく上限加減とか
ループとか扱う関数をいくつか用意。

**名前は開発中のものです。** · 2008/02/27(水) 12:56:18

C#には、getter/setter関数を、通常とは異なる文法の関数１つにまとめて記述できる文法があってそれがプロパティ。
代入演算の左に来ればsetterが、それ以外ならgetterが呼ばれるから結果的にグローバル変数のように使用できる。

個人的にはプロパティの用途は以下のようだと思ってるのでプロパティで処理するのはありだとおも。
>>772、インターフェイスのメンバにして多態性、getterのみ。

それにしてもRPGっぽいステータス管理って結構複雑だな。
今ぱっと考えただけじゃクラスが作れん。

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

値を上限・下限内に丸めるのとアサートによる契約プログラミングは別問題じゃないか？
単にセッタ内で丸めるという処理が目的だろこの場合。
アサートは条件に違反があった場合に吠えることが目的だろ？
違反があるかないか以外に影響しちゃだめだろアサートは。

**761** · 2008/02/27(水) 19:30:12

>>780有難うございます。参考にして改造しました。
static U_BOUND_RESULT add_ubound ( float& val, float val_max, float add ) {
　　　　if ( val < val_max ) {
　　　　　　val += add;
　　　　　　if ( val >= val_max ) { val = val_max; return MOMENT_FULL; }
　　　　　　val -= add;
　　　　}
　　　　if ( val >= val_max ) {
　　　　　　val += add;
　　　　　　if( val >= val_max ) { val = val_max; return ALREADY_FULL; }
　　　　　　val -= add;
　　　　}
　　　　if ( val <= 0 ){
　　　　　　val += add;
　　　　　　if( val <= 0 ) { val = 0; return ALREADY_DEAD; }
　　　　　　val -= add;
　　　　}
　　　　if ( val > 0 ){
　　　　　　val += add;
　　　　　　if(val <= 0) { val = 0; return MOMENT_DEAD; }
　　　　　　val -= add;
　　　　}
　　　　val += add ;
　　　　return NORMAL ;
　　}
} ;
>>763
if ( MOMENT_FULL == MyFunc::add_ubound (hp, MAX_HP, 10) ) {
　　playSound ( ) ;
}
満タンになった瞬間だけ音が鳴るようにしてみたんですがえらく冗長に…

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

>>783
C++ なら、せっかくだから関数テンプレートにしとこうか。

**761** · 2008/02/28(木) 00:50:13

関数テンプレート化頑張ってみます。
CからC++に移行したばかりで手間取りそうですが…

>>783の条件分岐の記述はもうちょっとスマートに処理できそうな気がするんですが
良い方法が思いつかず…

**名前は開発中のものです。** · 2008/02/28(木) 00:53:56

アサートが何なのかわからなくて検索してしまったぜ。
要するに本来はデバッグ検出用の関数なのね

**名前は開発中のものです。** · 2008/02/28(木) 00:56:28

まあHPならfloatで決め打ちでもそんなに困らない気がしないでもない
将来のための勉強にはなるかな

**名前は開発中のものです。** · 2008/02/28(木) 02:04:32

HPとかステータス値は普通整数じゃね？

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

表示するときは整数でも実数で保持しておいたほうが便利なことがあるかもしれない
MOTHER2みたいにダメージ受けても減少するまで時間がかかるとか……

**名前は開発中のものです。** · 2008/02/28(木) 02:44:14

時間とともにちょっとずつ回復みたいなことをやるなら実数の方がいいかなと。
ドラクエとかって最初から整数なのかな…
1ポイント前後のダメージって強制的に1ポイントダメージに補正されている感じだし
内部的に実数で0.1fずつ喰らったダメージが蓄積して1ポイントダメージになったりはしてなさそう

**名前は開発中のものです。** · 2008/02/28(木) 07:23:54

>>786
俺は assert() が入っていおらず、かつ UnitTest も書かれていない関数は
信用しない。

**名前は開発中のものです。** · 2008/02/28(木) 07:41:00

どうせリリース時には消えるしな

**名前は開発中のものです。** · 2008/02/28(木) 08:43:52

>>789
固定小数でググれ

**名前は開発中のものです。** · 2008/02/28(木) 09:17:18

アサートっていうかイベントだな

**名前は開発中のものです。** · 2008/02/28(木) 14:13:32

floatと書いておけば何も考えなくてもいいのに比べて
今どき固定少数で処理するのってメリット少なくない？

処理速度の面でも遜色ないし使用するメモリも
そこまでケチる時代じゃないしコードも固定少数の
ほうがいくらか読みづらくなるでしょ

**名前は開発中のものです。** · 2008/02/28(木) 16:35:34

固定小数点数のメリットは論じても仕方ないので置いておくとして、
floatなら何も考えなくていいってのは違うので気をつけよう
値の比較や、演算誤差・丸め込みに注意を払う必要がある

int main() {
　float a = 0.0f;
　for (int i = 0; i < 100; ++i) {
　　a += 0.01f;
　}
　std::cout << a << std::endl;
　return 0;
}

手元の環境だと結果は0.999999になる
あとゲームではよく使う % での剰余も出来ないので、代わりにfmod()を使う必要がある

例がFAQすぎてすまん

**名前は開発中のものです。** · 2008/02/28(木) 18:26:26

言ってることは別に間違ってないけど、float値の比較に「==」とか使うような奴は
ゲーム以前に計算機リテラシー欠乏者なのでこのスレでは無視していい存在では？

**名前は開発中のものです。** · 2008/02/28(木) 18:46:41

このスレではThe art of computer programmingは既読が前提ということか
質問しようと思ったけど出直すわ

**名前は開発中のものです。** · 2008/02/28(木) 19:23:14

ヘソ曲げ乙
別にそんな鈍器を買わんでも、その辺の理工学書コーナーに売ってる
薄っぺらい数値計算法の初歩本(教科書)を一冊借りて読んどけばいいよ
情報工学系大学1年次の基礎教養レベルの話なんだからさ

**名前は開発中のものです。** · 2008/02/28(木) 21:18:29

まあHPとかのステータス値を%で剰余出す計算することは少ないだろうし
>>796の問題でバグ出すケースも少ないだろうな……

ステータスアップや次のレベルに必要な経験値テーブルなんかに
アクセスすることが多いLVは整数型にするだろうけど、
その場合は値を丸める処理がHPと同じじゃまずいし

**名前は開発中のものです。** · 2008/02/28(木) 21:56:42

リテラシー(笑)

**名前は開発中のものです。** · 2008/02/29(金) 00:50:23

>>795
すまん
単にMOTHER2だとかドラクエだとか
DC/PS2以前のゲーム機で浮動小数なんて使わないよということが
言いたかっただけなんだｗ

何でもかんでもfloatにしたら配列の添え字にも使えないわ、単純な比較は出来ないわ
論理演算は出来ないわ
余計に面倒な気がするけど。