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

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

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

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

**名前は開発中のものです。** · 2006/09/23(土) 15:44:06

>>138
# boostは使ってないけど、weak_ptrの実装に興味あったのでソース見てみた。
# 間違ってたらごめんね。

intrusive_ptrは参照されるオブジェクトに参照カウンタの仕組みが備わっている場合に
使えるスマートポインタ。shared_ptrは参照カウンタをヒープに確保してて何にでも使える
汎用性がある代わりにオーバーヘッドがありゲーム用ならintrusive_ptrが好まれるという
ことだと思われる。

weak_ptrはそのヒープに確保される参照カウンタ(オブジェト)自身の参照カウンタを
上げ下げするもので、weak_ptrが全部消えるとその参照カウンタオブジェクトが
消えるという仕組みのようだね。

# detail/sp_counted_base_w32.hpp
class sp_counted_base
{
long use_count_; // #shared
long weak_count_; // #weak + (#shared != 0)

virtual void destroy() // nothrow
{
delete this;
}
void weak_release() // nothrow
{
if( BOOST_INTERLOCKED_DECREMENT( &weak_count_ ) == 0 )
{
destroy();
}
}
};

**名前は開発中のものです。** · 2006/09/23(土) 20:21:11

>>138
こんな感じだな。インスタンスのポインタは別に誰が持ってても良い。
っつかポインタのポインタ持ってる時点でそれと同義だし。

class clsA;
class clsB;

class clsB
{
int val;
public:
clsB(int v){val=v;}
int getVal(){return val;}
};

class clsA
{
clsB **pb;
public:
clsA(clsB **b)
{pb=b;}

int getVal()
{
if((*pb))
{return (*pb)->getVal();}
else
{return -1;}
}
};

**138** · 2006/09/23(土) 20:22:09

改行が多いって怒られた。

int _tmain(int argc, _TCHAR* argv[])
{
clsA *a;
clsB *b;
int ret;

b=new clsB(256);
a=new clsA(&b);
delete b;
b=NULL;

ret=a->getVal(); //ret==-1
return 0;
}

**140=141** · 2006/09/23(土) 20:22:57

名前ミスった。気にせんでくれ。

**名前は開発中のものです。** · 2006/09/25(月) 21:33:59

ここで挙げられたパターンや何やらを使っているような、
小規模でわかりやすいサンプルってありますかね？
シューティングを作ろうとしているのですが、設計で悩むことが多くて、
参考になるものが欲しくなってきたので、何かあればよろしくお願いします。

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

>>143
シューティング製作スレから．
ただし，漏れはまだ読んでないので内容については保証できんが．
ttp://ime.nu/www.amazon.co.jp/exec/obidos/ASIN/4797337214/

**名前は開発中のものです。** · 2006/10/31(火) 10:38:39

**名前は開発中のものです。** · 2006/11/04(土) 23:26:00

タスクシステムって本当に有効なのか？
逆にプログラミングが煩雑になりそうな気がするんだが。

**名前は開発中のものです。** · 2006/11/04(土) 23:30:01

>>146
何度か挙がってるネタだな。まず「タスクシステム」を定義しないと、
いつもどおりグダグダになるだろう。

**名前は開発中のものです。** · 2006/11/04(土) 23:49:54

>>147
タスクシステムというのは、
処理関数とワークエリアがセットになったタスクがリスト構造になっていて、
順番にタスクの処理関数を実行していく仕組みだと思ってる。違うかもしれんが。
あるタスクが、ほかのタスクの保持するデータを参照するのが難しそうだ。

**名前は開発中のものです。** · 2006/11/05(日) 01:52:09

>>148
関数とワークエリアがセットって言ったら仮想関数使えばいいだけの話。
あとは抽象クラスへのポインタをコンテナに保持すればできあがり。
システムって名付けるほどのもんでもないよな。

そこで済ませておけばいいものを、なんでもかんでもそのリストを
使ってやろうとすると、バグの温床となる「タスクシステム」ができあがるんじゃないか
と思っている。

**名前は開発中のものです。** · 2006/11/05(日) 02:16:36

実際C++だと必要ないよ。

**名前は開発中のものです。** · 2006/11/05(日) 09:28:27

>150
そうでもない。組み込み方面からもたらされたと思われる非プリエンプティブな
スレッドみたいなもうちょっと複雑なものとするなら、C++のみでは無理、
アセンブラが必要。WindowsならCreateFiberを使えるが、NT系で
しか使えない。

これからマルチコアが当たり前になると、スレッドをタスクと名づける人が増える
かもね、おおややっこしい。

**名前は開発中のものです。** · 2006/11/05(日) 09:43:30

>>151
147の発言を地でいってるな。

**名前は開発中のものです。** · 2006/11/05(日) 14:05:29

>>151
そういう意味のタスクじゃなくて

**名前は開発中のものです。** · 2006/11/07(火) 04:30:19

初心者だがレスさせてくろ
タスクシステムはビデオ屋でいうポストレンタルシステムではないでしょうか
ゲームプログラムにおいてはリアルタイム戦略ゲームのＡＩに有効かと
例えば自立スレッド型のユニット(目的地を指定すれば、勝手に動いてくれる)をＡ地点に移動したのち、Ｂ地点に移動させるAIを組もうとしたときなど。
ユニットのスレッドが行動リストをもっていて、AIはぼんぼんリストに行動をaddしていけばいい
ユニットのスレッドはリストの下から行動を処理する。

このシステムがないとAIはユニットがＡ地点に到着した情報を取得し、
その後でＢ地点に池という命令を出さなければならないのでAIの手間が非常にかかる　　おやすみなさい
　　

**名前は開発中のものです。** · 2006/11/07(火) 10:26:39

>>154
それは >>148 の言うようなタスクシステムとは全然違う。
コマンドのキューと言えば十分。システムなんて呼ぶほどのものでもない。

「タスクシステム」の共通な定義が無いのが
一番の問題なのかもしれないと思った。
俺様解釈が多すぎていまさら定義も難しい。

**名前は開発中のものです。** · 2006/11/07(火) 10:45:17

少なくともこのスレでのタスクシステムの共通定義は
>>148でいいんじゃないの？
今までずっとそれ前提で話が進められていたし、
そうでないと思っているのは的外れな>>154だけだと思うんだが。
タスクに親子関係持たせるとか優先度がどうだとかいった細かい部分は
その都度最適なものを選べばよし。

**名前は開発中のものです。** · 2006/11/07(火) 19:23:55

Cでリスト使ってて、
C++に移行したら「それタスクシステムだよ」って言われた。
どうすればいいでしょう？

**名前は開発中のものです。** · 2006/11/07(火) 21:40:27

もうすこしｋｗｓｋ

**名前は開発中のものです。** · 2006/11/08(水) 10:10:54

>>157
そうだよ。って答えれば解決。

**名前は開発中のものです。** · 2006/11/10(金) 11:57:52

ところで
http://d.hatena.ne.jp/kataho/20061013
ここのブログのこの問題といてみない？

**160** · 2006/11/10(金) 11:58:41

すまね、上げちまった

**名前は開発中のものです。** · 2006/11/10(金) 13:40:25

この板にしては珍しく良スレだな

**名前は開発中のものです。** · 2006/11/10(金) 21:25:10

>>160
>koei.co.jp scei.co.jp square-enix.co.jp みてるんだったら会社いれてよ！！！！！！

お題とは関係ないがこの辺にワロタｗ
proxyぐらい使いましょうね、大手の皆さんｗ

**名前は開発中のものです。** · 2006/11/10(金) 22:26:18

>>163
別に問題ないと思うけど。さすがに社内サーバのアドレスを referer で飛ばしてくるのは
どうかと思うが＞k社

**名前は開発中のものです。** · 2006/11/11(土) 01:08:30

自意識過剰

**名前は開発中のものです。** · 2006/11/12(日) 00:41:12

んで問題はとかねーの？

**名前は開発中のものです。** · 2006/11/12(日) 01:35:58

>>166
マジメに考えるほどのもんじゃない気がするが。

メモリの断片化や使用量見積もりを考えると、全オブジェクトを必要最小限の寿命で
確保・解放なんてせずに、シーン毎に必要なファイルぶち込んだアーカイブ作って
終わりだし。

**名前は開発中のものです。** · 2006/11/16(木) 13:28:43

コーエーといえば寝るおもしろす事件だなｗ

**名前は開発中のものです。** · 2006/11/16(木) 14:51:20

>>167
いつ何時どういう顔でどういう武器を持ったアバターが登場するかわからない
MMOとかだとシーンとか生ぬるいこといってられないんじゃない？

**名前は開発中のものです。** · 2006/11/18(土) 00:38:40

>>169
組み合わせが分からないなら、ワーストケースでも対応できるようにする必要があるから、
賢いメモリ管理はしない方が良いと思うが。

**名前は開発中のものです。** · 2006/11/18(土) 00:45:51

１００００とか決めうちで適当にアバター（？）放り込む領域とっときゃい～じゃん。
クライアントで１００００人同時表示とかどうせ無理だからｗ
なんかが湧いたとしても、
射程外の見かけ小さく見えるアバターから削除しちまえばOK。

**名前は開発中のものです。** · 2006/11/18(土) 18:42:03

>> 171
その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。

**名前は開発中のものです。** · 2006/11/18(土) 19:28:39

スケーラビリティはガン無視がゲームにおけるデータ構造・クラス設計の常識？

**名前は開発中のものです。** · 2006/11/19(日) 04:21:52

コンシューマならそれでも良いと思うけど、
昨今のＰＣゲーム開発であればスケーラビリティは必須では？
なんせ環境が数倍以上違うことだってあるからね。

**名前は開発中のものです。** · 2006/11/19(日) 06:35:18

> その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
領域が決めうちでも決めうちでなくても発生する問題。

> スケーラビリティ
MMOなんだから、クライアントの更新でスケーラビリティを代替すればいい。
逆にPCの優劣で、プレイヤー間に格差が出るほうが問題と言えば問題。

**名前は開発中のものです。** · 2006/11/19(日) 09:18:23

んで問題はとかねーの？

**名前は開発中のものです。** · 2006/11/19(日) 10:07:08

あれは、クラスデザインで対応すべき問題ではない、っつーのが答え
だろうな。

**名前は開発中のものです。** · 2006/11/19(日) 15:53:33

>> 175
だから、それを採用してもその問題が残るんだろ？
この問題の本質はそこだろ。どうやってデータへのアクセスを共有させんだ？

**名前は開発中のものです。** · 2006/11/19(日) 16:36:03

いや、エンジン書いてもそれはゲームじゃないからｗ
さっさとゲーム上の具体的なシーンについて見積もりを建てなさい。
領域なんて初期化時に必要な領域全部取ってしまえば問題無い。

**名前は開発中のものです。** · 2006/11/19(日) 16:54:45

>> 179
件のサイトってMMORPG作ってるわけで、
MMORPG開発を前提にした問題を出してるんだがなあ。
シーンなんて簡単なもんじゃ見積もれないって。

**名前は開発中のものです。** · 2006/11/19(日) 17:17:03

↓↓↓ここから見積もれる/見積もれないの一点だけで１００年戦争↓↓↓

**名前は開発中のものです。** · 2006/11/19(日) 20:33:12

なんか虎をつかまえてほしいなら虎を屏風からだしてくれみたいな回答だな
あきれた

**名前は開発中のものです。** · 2006/11/20(月) 01:22:30

>>180
URL貼った上で「件のサイト」を持ち出すのは、
あまり良くないと思うのだが…

**名前は開発中のものです。** · 2007/01/14(日) 05:03:57

良スレあげ

**名前は開発中のものです。** · 2007/01/19(金) 02:34:32

シーン・・・
昔すべてのシーンはスタックのみで再現可能と思ってた時が俺にも有りました。

実際大半はＯＫだけど、相互に行き来できるような仕組みを作りたい場合
別の方法をとらないといけないし、平行して動かす場合や
一部をストップさせたいときはいっそシーンクラスじゃなく
スレッドで動くクラスの方が良いと思えてきました。

まだ研究中。

**名前は開発中のものです。** · 2007/01/19(金) 13:33:30

俺はそれは兄弟関係をコンポジットにして解決しとるよ

**名前は開発中のものです。** · 2007/01/19(金) 14:48:25

コンポジットパターンですか？
なるほど。

**名前は開発中のものです。** · 2007/01/27(土) 00:03:58

良スレ発見。

皆様のお知恵をお借りしたい。

効果音、BGM、描画エンジンなどの管理オブジェクト（コンテキストっていうのか？）をどうやって、
キャラクターなどから参照させるかということについてです。

キャラのオブジェクト生成時に、必要なものだけ渡してやるのがベストなんでしょうか？

今は、全部持ったGameクラスっつーのを作って、そのインスタンスのローカル変数一個を
どこからでも参照できるようにして、
各キャラクターから参照できるようにしているんだが、
今の流行的に、ローカル変数がイヤンなので、
なんとかしてやりたいのです。

ABAさんのソースとか見ると、生成時に引数で渡しているんだけど、
うちのDelphiだと、各ユニット間の循環参照問題を回避できなくて真似できないんだよね・・・。

**名前は開発中のものです。** · 2007/01/27(土) 00:27:08

ローカル変数？グローバル変数だよね。
その方法がまあ無理なくやれると思う。

グローバル変数がどうしても嫌なら
インターフェイス宣言を使えば、循環参照は回避できるよ。

**名前は開発中のものです。** · 2007/01/27(土) 00:46:55

ごめん。グローバル変数です。
インターフェースか、Delphiのインターフェースって普通じゃないからなあ。

過去レスに出てた↓こちらのCtxってのが参考になるかもしれんけど。

或曰: お仕事
http://www.issei.org/blog/archives/000225.html

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

音はコンテクストとは違うのでは？リソース？
そのインスタンスの性質そのものなんだからバリバリ依存してていい
描画デバイスはそれ自体のステートがあるんで外からもらう必要があるだろうけど
別にグローバル変数で問題ないでしょう？
まあ描画するときにだけ引数でもらうように改変するのを無理して止める気はないけど

＞http://www.issei.org/blog/archives/000225.html
おもしろいなーfacade+visitorかぁ

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

サウンドみたいなものはモロにシングルトンにしてしまって
CSoundManager::GetInstance().Play( FX_HOGE );
こんなんでよいのでは

**名前は開発中のものです。** · 2007/01/27(土) 14:40:32

＞http://www.issei.org/blog/archives/000225.html
何か違和感があったので、寝ながら考えたんだけど
こいつの問題はゲームエンティティのクラスとctxのインターフェイスが１対１になってるとこかな。
まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
いちいち別の実装とインターフェイスを設けなくてはならなくなる。
意味のない制約を守るために重複コードができてしまう。

**名前は開発中のものです。** · 2007/01/27(土) 15:41:16

それにゲームエンティティクラスが増えて、継承の階層とかができても
ctxの実装は全部の名前に_ctxつけたインターフェイスを全部同時に多重継承するんだろか？

ctxにmixinするインタフェイスはゲームエンティティのクラス群の構造に依存しないで
区分けそのものに対する名前をつけてやる方がきれい、というか合理的に思う。
例えばとにかく弾をつくるインタフェイスを公開するctxインターフェイスならICtxShootとか。

**issei** · 2007/01/27(土) 22:48:39

>>193
> まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
> いちいち別の実装とインターフェイスを設けなくてはならなくなる。
そうですね。

ただ、純粋仮想関数のプロトタイプが同じなら実装は一つで済むから、ヘッダ
ファイルをメンテするのが多少面倒って程度です。

struct ICtxEnemy { virtual void createShot() = 0; };
struct ICtxField { virtual void createShot() = 0; };
class Manager : public ICtxEnemy, public ICtxField { virtual void createShot(); };
// これで実装は両方に提供できる

このスキーム使って仕事で RPG のリアルタイム戦闘を作ってたんだけど、面倒で
手に負えないって状況には至らなかった。むしろインターフェースごとに公開する
関数が限定されていたから、仕様変更時にチェックが短期間で済んだ感じ。細かい
数字を残してないから、具体的に何パーセント改善とは言えないけどさ。

汎用的なインターフェースをどうするかってのは悩みどころだけど、やりたければ
sturct ICtxEnemy { virtual ICtxCommon& getCommonCtx() = 0; };
とかかなぁ。私は汎用インターフェースは結局作らずシングルトンで済ませちゃった
けど。

**名前は開発中のものです。** · 2007/01/27(土) 22:53:18

>188
個別にオブジェクトのアドレスを渡した場合、パラメータの個数が膨大になるのと、
きれいにまとめないとかなり手間がかかるね。

シングルトンで実装して、グローバルアクセスがよいのではとおもう。

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

>>issei（誰？ｗ）
＞// これで実装は両方に提供できる
確かにそうだね。書いてみてから気がついた。
具体的に書くコードの量とかの増減をあげつらう批判をしたいわけじゃないだホントは

また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
というエンティティクラスからの表明が主題で、managerが全部を継承して実装するというのは、
たまたま今回採用されたやりかたに過ぎない、別にどうでもいい部分なんだね。

エンティティクラスが継承ツリーをつくるようなときは最上位のクラスのctxに
下位層のクラスが使おうとする純粋仮想関数も書き加えてかなきゃいかんね。
つまり最上位のオブジェクトを以って、主要メソッドを実行しても、
その下位の継承したクラスの機能追加されたものが呼ばれる可能性があるわけなので。

なんで俺が日記の作者も言ってない手法の使い方をまとめてんだ…

ぜんぜん関係ないけどcontextってのはあんまり実態にそぐわない名前だと思うなぁ。分かるけど。
relianceとかdependencyとかのがいいような気がする。

**issei** · 2007/01/28(日) 01:38:40

>>197
> >>issei（誰？ｗ）
日記の人です。

> また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
> このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
そうそう。

本当のマネージャとは別に、エンティティの単体テスト用とかデバッグ用に ICtx***
インターフェースを実装した別のマネージャーも作ってました。

確か別のプログラマがエフェクト用の対話型エディタを作ってたんだけど、そこで
デザイナからキャラクタにエフェクト乗せて見たいとリクエストがあって、エフェクト
エディタにキャラクタ用のコンテクスト実装してたんじゃなかったかな。もちろん、
大半の仮想関数はダミー(ヒット判定なんかの関数は、常にヒットしないと返す
だけ）だけど。

**名前は開発中のものです。** · 2007/01/28(日) 19:27:03

風呂はいりながら考えたんだけど
ようは移植用区画、エンティティクラス、実装を委譲したい関数群、
それぞれをシステム内で１対１対１。ひとまとめにしたいわけだ。それはわかる。
だが無駄に暗黙的な命名の制約を持ち込むvisitorインターフェイスには反対。
contextというが、それらが文脈として差異を持たされるのは結局はプロジェクト全体で複数作られる
実行単位ごとなわけだ。それに対してvisitor風に関数レベルで型への依存を表明するのは
適当だとは思えない。何がどのレベルで変わるのかがきちんと示せてるのがいいコードっすよね。
ついでに実装をまとめるだけが目的の節操のないmixinも反対だ。

俺はこうする。

class Player
{
public:
void exec() { CreateShoot(); }
void Method0();
private:
static void CreateShoot(); // どこか他のコンパイル単位で定義してやる
};

どこか他のシステムへもっていってもstatic関数を定義した.cppの方だけ取り替えれば移植が完了する。

**名前は開発中のものです。** · 2007/01/31(水) 00:35:16

クラス名・変数名に迷ったら書き込むスレ。Part9
http://pc10.2ch.net/test/read.cgi/tech/1168356029/113-132
から誘導されてきました。

・こんな構造の名前はなにがいいですか？
・タスクっぽいですねー
・擬似マルチタスクっぽいかも？
・スタック使え！
・え？スタック？
・segregated storage使え。
・boostのpool？

まあ、そんな感じで、ゲーム向けのデータ構造をどうするかって話になりました。

**名前は開発中のものです。** · 2007/01/31(水) 00:44:13

>>200
答えでてんじゃん。
ここで何が聞きたいの？

**名前は開発中のものです。** · 2007/01/31(水) 00:49:48

フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。

**名前は開発中のものです。** · 2007/01/31(水) 01:00:05

>>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの？

**名前は開発中のものです。** · 2007/01/31(水) 01:08:05

いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろｗｗ

**名前は開発中のものです。** · 2007/01/31(水) 01:09:38

今適当に書いたけどフラグなんか使うよりこっちのほうがいいんじゃないか

template<typename T,int N>
class FixedAllocator
{
　union Block
　{
　　T Data;
　　Block* pNext;
　};
　Block*　m_pGarbage;
　Block　m_Pool[N];
public:
　FixedAllocator()
　{
　　m_pGarbage = &m_Pool[0];
　　for( int i = 0; i < N-1; i++ )
　　　m_Pool[i]->pNext = &m_Pool[i+1];
　　m_Pool[N-1]->pNext = NULL;
　}
　T* Alloc()
　{
　　Block* pRet = m_pGarbage;
　　m_pGarbage = m_pGarbage->pNext;
　　return &m_pGarbage->Data;
　}
　void Free( void* p )
　{
　　static_cast<Block*>(p)->pNext = m_pGarbage;
　　m_pGarbage = static_cast<Block*>(p);
　}
};

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

>>202
フラグ管理より双方向リストでつないどくのが良いと思うけどな。

struct PoolNode
{
　struct PoolNode* pn_next;
struct PoolNode* pn_prev;
　char pn_padding[8]; //必要なら
　char pn_buf[PN_BUFSIZE];
};

static PoolNode nodes[NODENUM];

// 未使用ノードは、こっちにつなぐ
static PoolNode* free_first = &nodes[0];
// 使用中ノードは、こっちにつなぐ
static PoolNode* inuse_first = 0;

現実には、俺なら自前で書かずに STLport の node allocator にお任せして、
STLコンテナ使っちゃうか、boost::pool だけと。

**名前は開発中のものです。** · 2007/01/31(水) 01:13:52

boostみて、なんじゃこりゃーな感じだったので、

>>206とか、見るとわかりやすいですね。

配列でデータは持つんだけど、使用中ノードは、連結リスト風につないでおくっと。
未使用ノードも同じようにもつ。

これだけで、済む話かー。

**名前は開発中のものです。** · 2007/01/31(水) 01:14:36

>>205
それが segregated storage だろ。

**名前は開発中のものです。** · 2007/01/31(水) 01:15:32

>>208
そう言うのか

**名前は開発中のものです。** · 2007/01/31(水) 01:17:52

欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろｗ
だって、>>200より優れたクラスなんて存在しないんだからｗｗｗ

つ　【ステフ１８クラス】
つ　【次世代ｺﾐｭクラス】
つ　【ﾊﾞｷｭﾝﾊﾞｷｭﾝクラス】

この板ならではのクラス名を授けるから好きなの選べ

**名前は開発中のものです。** · 2007/01/31(水) 01:18:10

そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz

**名前は開発中のものです。** · 2007/01/31(水) 01:22:57

boostは、知ってても使いこなせてないクラスも多いなぁ。fusionとかmplとか。

普段お世話になってるのは、stdafx.h 見るとこんな感じ。

#include <boost/array.hpp>
#include <boost/bind.hpp>
#include <boost/call_traits.hpp>
#include <boost/crc.hpp>
#include <boost/cstdint.hpp>
#include <boost/function.hpp>
#include <boost/format.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/noncopyable.hpp>
#include <boost/ref.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/scoped_array.hpp>
#include <boost/static_assert.hpp>

**名前は開発中のものです。** · 2007/01/31(水) 01:24:55

>>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。

>>210さんが、私のデータ構造を最高！マンセー！他はクズ！>>200様に一生従います！
と言ってくださるのは、うれしいのですが、

他に、どんな効率のよい、データ構造があるかというのを知りたいのです。

Delphiには、boostねーよー。うらやましい。

**名前は開発中のものです。** · 2007/01/31(水) 01:26:10

× >>200様に一生従います！
○ >>200様に一生を捧げます

間違えました。

**名前は開発中のものです。** · 2007/01/31(水) 01:26:40

>>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの？

**名前は開発中のものです。** · 2007/01/31(水) 01:46:00

もしかしたら、主要なデータ構造を一通り勉強したいってこと？　それなら、
まずは(データ構造を処理するアルゴリズムとセットで)

・Cプログラマのためのアルゴリズムとデータ構造
・珠玉のプログラミング
・プログラム設計の着想
・プログラミング作法

あたりの書籍を読むのがお薦めだが。

**名前は開発中のものです。** · 2007/01/31(水) 02:00:35

>>213
いや、普通に皮肉だから、無理にレスしなくていいよ。

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

この板で数少ない有用なスレッドだな

**名前は開発中のものです。** · 2007/01/31(水) 15:38:04

>>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。

>>216
勉強したいだけ、というわけではないのですが、
参考になります。

**名前は開発中のものです。** · 2007/01/31(水) 19:22:58

弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは１つあれば十分だし。

**名前は開発中のものです。** · 2007/01/31(水) 20:28:29

>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。

**名前は開発中のものです。** · 2007/01/31(水) 22:47:38

>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ

**名前は開発中のものです。** · 2007/01/31(水) 23:00:17

>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。

**219** · 2007/01/31(水) 23:25:03

まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
（動作環境は、PCです）

新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。

**名前は開発中のものです。** · 2007/03/21(水) 22:27:58

>>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね

**名前は開発中のものです。** · 2007/03/23(金) 13:48:25

良スレage

**名前は開発中のものです。** · 2007/03/26(月) 06:10:31

ところで、
キャラクターの構造体は何で取ってる？
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。

皆は何で取ってる？

**名前は開発中のものです。** · 2007/03/26(月) 06:11:56

あ、ゲームは普通の２ｄのアクションゲームとかです。

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

doubleでおｋ

次の話題どうぞ

**名前は開発中のものです。** · 2007/03/26(月) 12:51:40

単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ

**名前は開発中のものです。** · 2007/03/26(月) 18:43:03

>>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし

**名前は開発中のものです。** · 2007/03/26(月) 19:09:19

桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
　敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。

そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。

**名前は開発中のものです。** · 2007/03/26(月) 19:20:52

>>232
そんなクラス作らなくてもいいんじゃね？
16ビットシフトするだけでゲームの精度的には十分かと。

**名前は開発中のものです。** · 2007/03/26(月) 21:35:29

ttp://shinh.skr.jp/template/gamenum.html

**名前は開発中のものです。** · 2007/03/26(月) 22:10:26

>>232
なんか勘違いしてるけど、固定小数点数にするのに１０進は関係ないぞ。

**名前は開発中のものです。** · 2007/03/26(月) 22:13:45

>>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。

**名前は開発中のものです。** · 2007/03/27(火) 01:42:55

10進でも2進でも丸め誤差は出るってば。

**その1** · 2007/03/27(火) 06:12:21

「キャラの座標の型に関して」

・整数か小数か -> 断然小数

・小数の表現方法
　-> 浮動小数点数 or 固定小数点数
　-> 2進表現 or 10進表現

・浮動小数点数
　○ 基本型であるので扱いが楽
　× 演算速度が遅い
　△ 非常に近い値同士を比較したときに桁落ちが発生する
　　 (桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
　○ 比較による桁落ちが発生しない
　○ 実態は整数型なので演算速度が早い
　　-> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
　　　　　可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
　× 固定小数点数オブジェクトの生成が頻繁であると遅くなる
　　 (特にオペレータ・オーバーロードに注意)
　△ 小数点以下の精度(桁数)が固定
　　 (ただし、精度が足りなくて困ることはまず無いと思われる)