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

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

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

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

**名前は開発中のものです。** · 2006/09/01(金) 23:50:16

俺は衝突クラスを作るかな。
実装は>>101みたいな感じだけど4分木を使ってもっと大雑把にやる。
まあ実装に関してはこのスレの範囲外だけど。

**名前は開発中のものです。** · 2006/09/02(土) 18:17:30

衝突判定でよく話題になるダブルディスパッチだけれども
boost::variant使うと継承無しで実現できちゃうよ。
中身はswitch caseのコンパイル時自動生成してるだけだけど。
継承関係なしで仮想関数の真似事もできるんで、
たまには役に立つかもしれない。

**名前は開発中のものです。** · 2006/09/02(土) 18:26:27

GameObjectは型クラスの概念に近いことが多いから、
ある程度規模が大きくなると、コンパイル時のダブルディスパッチの確定だけじゃ追いつかなくなるんだよね…
UnrealEngineではスクリプトに完全に委譲してしまってるみたいだけど。

**名前は開発中のものです。** · 2006/09/02(土) 18:36:54

variant型なんだからもちろん実行時型識別してくれるよ。
具体的には型にid振ってswitch caseしてるだけ。
メモリアロケーションも発生しないからなかなか優秀。
ただオブジェクトサイズが最大のものに揃っちゃうけど。

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

こんな感じね。↓

#include <boost/variant.hpp>

using namespace boost;

class visitor : public static_visitor<> {
public:
void operator () (int n, int m) const {}
void operator () (char n, char m) const {}
void operator () (char n, int m) const {}
void operator () (int n, char m) const {}
};

・・・・
variant<int, char> v0, v1;
v0 = int(2);
v1 = char(3);
apply_visitor(visitor(), v0, v1);
v0 = char(2);
v1 = char(3);
apply_visitor(visitor(), v0, v1);

**名前は開発中のものです。** · 2006/09/02(土) 21:49:46

>>105
いや、突き詰めていくと、同じ型であってもゲーム上で異なる意味を持つ場合がよくあって、
そういう場合は（言語としての）型でのディスパッチだけでは不十分で、
結局、ゲームにあわせたIDなり名前なりで自前のルーチンを組むことになるって話。

特にRTSやFPSみたく、プログラマは基本的な構造とツールを提供するだけで
後はデザイナーの仕事、のように分業されてるゲームではそうなりやすいでしょ。

って書いてて気づいたけど型クラスじゃなくて型オブジェクトだったよ(´･ω･`)ｽﾏｿ。

**名前は開発中のものです。** · 2006/09/03(日) 02:35:53

それは単に振る舞いを型まで落としきれてないだけでは。
仮に振る舞いが外部設定可能だったとしても
型をパラメータ化したファクトリ作れば良いし。

**名前は開発中のものです。** · 2006/09/03(日) 02:45:46

ああ、”ゲームオブジェクト”のディスパッチでは
足りない、ということであれば同意。
上のは当たり判定オブジェクトを別に作ってそっちで
ディスパッチする前提で話してた。

**名前は開発中のものです。** · 2006/09/03(日) 20:53:10

てかここまでくるとスレ違いじゃね？

**名前は開発中のものです。** · 2006/09/03(日) 21:18:48

>>110
何故？

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

>>109
そう、そういう意味ですた。
パックマンやテトリスみたく、型とオブジェクトの振る舞いが１：１で対応するようなゲームであれば
boost::variantやLokiのStaticDispatcherで事足りるし、その方が高速なんだけど
ツールでカスタマイズ可能なオブジェクトを導入したとたんに破綻しちゃうんだよね…
普通はどうするもんなんでしょうか。

**名前は開発中のものです。** · 2006/09/04(月) 00:35:37

>>110
話題が無いよりマシ

>>112
>>108、>>109にも書いてあるけどStrategyパターン使ったら？

**名前は開発中のものです。** · 2006/09/04(月) 22:45:10

衝突は悩みますよねー。
まぁ、衝突判定のためのクラスを作って、そこに対象をごっそり
addしていくような感じですかね。わたしは。

**名前は開発中のものです。** · 2006/09/04(月) 23:02:41

2Dの衝突判定の話と３Dの衝突判定の話が混在しているから困るｗ

**名前は開発中のものです。** · 2006/09/04(月) 23:16:45

次元１つ違うだけジャン

**名前は開発中のものです。** · 2006/09/04(月) 23:41:18

判定アルゴリズムを語っているわけではあるまいし、問題ないだろう。

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

さすがに>>101のやり方は３Dじゃやらんだろｗｗ

**名前は開発中のものです。** · 2006/09/05(火) 01:15:43

画像だとめんどいけど多次元配列にすればいけるんじゃね？

**名前は開発中のものです。** · 2006/09/05(火) 01:32:48

>>119
普通はAABBのツリー構造にするけどな

**名前は開発中のものです。** · 2006/09/05(火) 04:06:58

グリッドでやるのは現実的じゃないけど、オクツリーなら。

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

こういう話題も一応『データ構造』の内に入るのかな？
レンジ広めな良スレだな。

**名前は開発中のものです。** · 2006/09/05(火) 07:11:57

まとめ
・形状衝突判定とゲームオブジェクト衝突判定の話が混在してて紛らわしいお
・VisitorパターンはAcceptor側の個数が暴発するときには使いづらいお
・挙動をStrategy化すればAcceptorが暴発しにくくなるお
・次元を問わずグリッドよりツリーのほうがお勧めだお

**名前は開発中のものです。** · 2006/09/08(金) 23:55:09

群体を制御するプログラムのいい案ない？
複数の個体で整列したり陣形を作るっていうのが目標

どっちかというとＡＩの分野に入ると思うけど
そこまで複雑な物じゃなくてもいいかなと思ってる

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

チーム全体の行動を担うダミーエージェントを用意して、
そいつが全エージェントの操作を行うというのが楽なんじゃね？
昔からある多間接キャラとかはこういうタイプなんだろか

個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
まさしくAIって感じだが果てしなく重くなりそう

**名前は開発中のものです。** · 2006/09/09(土) 00:27:32

>>125
> 個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
> まさしくAIって感じだが果てしなく重くなりそう
そうでもない。
今のクラウドシミュレーションの基礎になってるレイノルズの方法では
3つの単純な操作を各個体に適用するだけでリアルな挙動を作り出せる。

これに、基準になる目標点を個々に与えたり、パラメータを調節・追加することで整列や陣形も表現できる。
といっても完璧に意図した陣形にしたければ、予め動きを指定しておくしかないけど。

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

boidっ言ってちょ。1行目だけ読んで「レイノルズって誰だ？」とか思っちゃった。
ツリー的な構造にしてセパレーション以外の適用範囲を限定したりすると、
複数の集団が扱えるし、（影響力の強くした）ツリーの親で操作できて手軽。

**124** · 2006/09/09(土) 11:31:36

まとめると
チーム全体の指揮をするエージェントを作る
個々に単純な操作や状況判断する機能をつける
ツリー構造で処理する

思い出したんだがそういえば鳥の群れのシュミレーションとか参考になりそうだと思った
ttp://www.red3d.com/cwr/boids/

>>125と>>126のやり方を組み合わせられれば理想的なプログラムになりそう

**名前は開発中のものです。** · 2006/09/09(土) 13:29:03

階層ステートマシーンってどんなものか知ってる人いる？

**名前は開発中のものです。** · 2006/09/10(日) 00:43:16

>>129
従来のステートマシン（全てのステートが完全に等価）に
クラスなりパッケージ化で階層を加えて
オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな？

**名前は開発中のものです。** · 2006/09/10(日) 06:09:51

>>128
リンク先の動きが魚っぽい。

**名前は開発中のものです。** · 2006/09/13(水) 09:43:56

魚に吹いたｗ

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

2chからリンクされていたから何かと思ったら、こういう話かｗ　一安心。

>>129
ふつーのステートマシンだと全ての状態が対等なので、状態×入力に
比例して記述が増えていく。似た状態をまとめて、必要な記述量を減ら
そうってのが階層ステートマシン。

たとえば RPG の主人公キャラなら、まず「生きてる」「死んでる」で状態を
分けて、さらに「生きてる」の中に「通常」「混乱」「スリープ」とか入れ子に
して挙動が異なる部分だけ書く。

>>130
> オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな？
直接は関係ないです。OOPL を使ったほうが書きやすいかな、って程度。

むかし、ゲーム屋さんやってたときに作った代物があるので、どーぞ。
ttp://www.issei.org/diary/?20040208#08

参考書
ttp://www.amazon.co.jp/exec/obidos/ASIN/1578201101

**名前は開発中のものです。** · 2006/09/17(日) 13:24:01

strategyのstrategyみたいなもんか。

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

質問です。

まず、動的にメモリ上に作成されたオブジェクト、ＡとBがあります。
ある時、オブジェクトBはオブジェクトAへの参照を保持したとします。
しかしその後、オブジェクトAは消失してしまいます。

こういった場合に、オブジェクトBの保持していたオブジェクトAへの参照が
無効になったことが分かる、良い参照構造がありましたら教えてください。
スマートポインタをちょっと調べてみましたが、あれってこういう場合に使うものではないですよね？（むしろ逆のような感じ）

言語はC++です。

**名前は開発中のものです。** · 2006/09/22(金) 22:33:30

>>135
boost 使うなら shared_ptr と weak_ptr 組み合わせて使う。

或いは、非参照オブジェクトに

bool isTerminated() const;

みたいなメンバ変数を持たせて、参照側はスマートポインタで保持。使う前に

if (p->isTerminated())
　p = NULL;

みたいなチェックを入れる。私は intrusive_ptr 好き人間なので、後者で統一
してました。

**名前は開発中のものです。** · 2006/09/23(土) 10:55:14

>>135
インスタンスのポインタのポインタ持たせておけばおｋ。
Aのインスタンス開放時は必ずぬるぽを指定する。

**名前は開発中のものです。** · 2006/09/23(土) 14:31:03

>>136
weak_ptr使ってみました。これは良いですね。
セットされていたshared_ptrが消失すると以降のlock()が無効になる。
これで私の希望は叶ったように思います。
ただ・・これって内部ではどのような処理が行われているのでしょうか？
ソースを読んでみようかと思いましたが・・私にはちょっと難しかったです。
どなたか、簡単に解説していただけませんでしょうか？

intrusive_ptrについては、よく分かりませんでした。

>>137
Ｂがインスタンスのポインタのポインタを持つとして、
その「インスタンスのポインタ」にあたるデータは
Ａが持つのでしょうか？それとも違う者が持つ？または誰も所有しないのでしょうか？
ちょっと具体的なイメージが沸きませんでした。
宜しければサンプルコードみたいなものを書いて頂けるとありがたいです。

**名前は開発中のものです。** · 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
答えでてんじゃん。
ここで何が聞きたいの？