06/09/05 01:15:43 XCG3Ame9
画像だとめんどいけど多次元配列にすればいけるんじゃね？
120:名前は開発中のものです。
06/09/05 01:32:48 N2PWUf7J
>>119
普通はAABBのツリー構造にするけどな
121:名前は開発中のものです。
06/09/05 04:06:58 9I8P67h+
グリッドでやるのは現実的じゃないけど、オクツリーなら。
122:名前は開発中のものです。
06/09/05 05:52:03 b0Le55Md
こういう話題も一応『データ構造』の内に入るのかな？
レンジ広めな良スレだな。
123:名前は開発中のものです。
06/09/05 07:11:57 WVxlLvIu
まとめ
・形状衝突判定とゲームオブジェクト衝突判定の話が混在してて紛らわしいお
・VisitorパターンはAcceptor側の個数が暴発するときには使いづらいお
・挙動をStrategy化すればAcceptorが暴発しにくくなるお
・次元を問わずグリッドよりツリーのほうがお勧めだお
124:名前は開発中のものです。
06/09/08 23:55:09 NaDeRAxZ
群体を制御するプログラムのいい案ない？
複数の個体で整列したり陣形を作るっていうのが目標
どっちかというとＡＩの分野に入ると思うけど
そこまで複雑な物じゃなくてもいいかなと思ってる
125:名前は開発中のものです。
06/09/09 00:04:25 htHhZzlR
チーム全体の行動を担うダミーエージェントを用意して、
そいつが全エージェントの操作を行うというのが楽なんじゃね？
昔からある多間接キャラとかはこういうタイプなんだろか
個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
まさしくAIって感じだが果てしなく重くなりそう
126:名前は開発中のものです。
06/09/09 00:27:32 8XOJrFUy
>>125
> 個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
> まさしくAIって感じだが果てしなく重くなりそう
そうでもない。
今のクラウドシミュレーションの基礎になってるレイノルズの方法では
3つの単純な操作を各個体に適用するだけでリアルな挙動を作り出せる。
これに、基準になる目標点を個々に与えたり、パラメータを調節・追加することで整列や陣形も表現できる。
といっても完璧に意図した陣形にしたければ、予め動きを指定しておくしかないけど。
127:名前は開発中のものです。
06/09/09 03:06:35 KrPaatUc
boidっ言ってちょ。1行目だけ読んで「レイノルズって誰だ？」とか思っちゃった。
ツリー的な構造にしてセパレーション以外の適用範囲を限定したりすると、
複数の集団が扱えるし、（影響力の強くした）ツリーの親で操作できて手軽。
128:124
06/09/09 11:31:36 c7q33UAv
まとめると
チーム全体の指揮をするエージェントを作る
個々に単純な操作や状況判断する機能をつける
ツリー構造で処理する
思い出したんだがそういえば鳥の群れのシュミレーションとか参考になりそうだと思った
URLﾘﾝｸ(www.red3d.com)
>>125と>>126のやり方を組み合わせられれば理想的なプログラムになりそう
129:名前は開発中のものです。
06/09/09 13:29:03 QcPvLvjH
階層ステートマシーンってどんなものか知ってる人いる？
130:名前は開発中のものです。
06/09/10 00:43:16 20rok1qS
>>129
従来のステートマシン（全てのステートが完全に等価）に
クラスなりパッケージ化で階層を加えて
オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな？
131:名前は開発中のものです。
06/09/10 06:09:51 lBlbiG31
>>128
リンク先の動きが魚っぽい。
132:名前は開発中のものです。
06/09/13 09:43:56 NFAfFOse
魚に吹いたｗ
133:名前は開発中のものです。
06/09/17 13:13:30 w8QCz84O
2chからリンクされていたから何かと思ったら、こういう話かｗ 一安心。
>>129
ふつーのステートマシンだと全ての状態が対等なので、状態×入力に
比例して記述が増えていく。似た状態をまとめて、必要な記述量を減ら
そうってのが階層ステートマシン。
たとえば RPG の主人公キャラなら、まず「生きてる」「死んでる」で状態を
分けて、さらに「生きてる」の中に「通常」「混乱」「スリープ」とか入れ子に
して挙動が異なる部分だけ書く。
>>130
> オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな？
直接は関係ないです。OOPL を使ったほうが書きやすいかな、って程度。
むかし、ゲーム屋さんやってたときに作った代物があるので、どーぞ。
URLﾘﾝｸ(www.issei.org)
参考書
URLﾘﾝｸ(www.amazon.co.jp)
134:名前は開発中のものです。
06/09/17 13:24:01 yvndUkUn
strategyのstrategyみたいなもんか。
135:名前は開発中のものです。
06/09/22 22:18:45 u76SSGNK
質問です。
まず、動的にメモリ上に作成されたオブジェクト、ＡとBがあります。
ある時、オブジェクトBはオブジェクトAへの参照を保持したとします。
しかしその後、オブジェクトAは消失してしまいます。
こういった場合に、オブジェクトBの保持していたオブジェクトAへの参照が
無効になったことが分かる、良い参照構造がありましたら教えてください。
スマートポインタをちょっと調べてみましたが、あれってこういう場合に使うものではないですよね？（むしろ逆のような感じ）
言語はC++です。
136:名前は開発中のものです。
06/09/22 22:33:30 zpdtl+m6
>>135
boost 使うなら shared_ptr と weak_ptr 組み合わせて使う。
或いは、非参照オブジェクトに
bool isTerminated() const;
みたいなメンバ変数を持たせて、参照側はスマートポインタで保持。使う前に
if (p->isTerminated())
p = NULL;
みたいなチェックを入れる。私は intrusive_ptr 好き人間なので、後者で統一
してました。
137:名前は開発中のものです。
06/09/23 10:55:14 gkZ8TjvK
>>135
インスタンスのポインタのポインタ持たせておけばおｋ。
Aのインスタンス開放時は必ずぬるぽを指定する。
138:名前は開発中のものです。
06/09/23 14:31:03 HUIkr9ZU
>>136
weak_ptr使ってみました。これは良いですね。
セットされていたshared_ptrが消失すると以降のlock()が無効になる。
これで私の希望は叶ったように思います。
ただ・・これって内部ではどのような処理が行われているのでしょうか？
ソースを読んでみようかと思いましたが・・私にはちょっと難しかったです。
どなたか、簡単に解説していただけませんでしょうか？
intrusive_ptrについては、よく分かりませんでした。
>>137
Ｂがインスタンスのポインタのポインタを持つとして、
その「インスタンスのポインタ」にあたるデータは
Ａが持つのでしょうか？それとも違う者が持つ？または誰も所有しないのでしょうか？
ちょっと具体的なイメージが沸きませんでした。
宜しければサンプルコードみたいなものを書いて頂けるとありがたいです。
139:名前は開発中のものです。
06/09/23 15:44:06 LShRrPtb
>>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();
}
}
};
140:名前は開発中のものです。
06/09/23 20:21:11 gkZ8TjvK
>>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;}
}
};
141:138
06/09/23 20:22:09 gkZ8TjvK
改行が多いって怒られた。
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;
}
142:140=141
06/09/23 20:22:57 gkZ8TjvK
名前ミスった。気にせんでくれ。
143:名前は開発中のものです。
06/09/25 21:33:59 hvNCBo59
ここで挙げられたパターンや何やらを使っているような、
小規模でわかりやすいサンプルってありますかね？
シューティングを作ろうとしているのですが、設計で悩むことが多くて、
参考になるものが欲しくなってきたので、何かあればよろしくお願いします。
144:名前は開発中のものです。
06/10/10 21:23:54 yCqIkWyw
>>143
シューティング製作スレから．
ただし，漏れはまだ読んでないので内容については保証できんが．
URLﾘﾝｸ(ime.nu)
145:名前は開発中のものです。
06/10/31 10:38:39 xPxE7qYC
146:名前は開発中のものです。
06/11/04 23:26:00 fX21zZRx
タスクシステムって本当に有効なのか？
逆にプログラミングが煩雑になりそうな気がするんだが。
147:名前は開発中のものです。
06/11/04 23:30:01 gABtDaTi
>>146
何度か挙がってるネタだな。まず「タスクシステム」を定義しないと、
いつもどおりグダグダになるだろう。
148:名前は開発中のものです。
06/11/04 23:49:54 fX21zZRx
>>147
タスクシステムというのは、
処理関数とワークエリアがセットになったタスクがリスト構造になっていて、
順番にタスクの処理関数を実行していく仕組みだと思ってる。違うかもしれんが。
あるタスクが、ほかのタスクの保持するデータを参照するのが難しそうだ。
149:名前は開発中のものです。
06/11/05 01:52:09 SWu+bHZ4
>>148
関数とワークエリアがセットって言ったら仮想関数使えばいいだけの話。
あとは抽象クラスへのポインタをコンテナに保持すればできあがり。
システムって名付けるほどのもんでもないよな。
そこで済ませておけばいいものを、なんでもかんでもそのリストを
使ってやろうとすると、バグの温床となる「タスクシステム」ができあがるんじゃないか
と思っている。
150:名前は開発中のものです。
06/11/05 02:16:36 luPotGyi
実際C++だと必要ないよ。
151:名前は開発中のものです。
06/11/05 09:28:27 x/qHNT/o
>150
そうでもない。組み込み方面からもたらされたと思われる非プリエンプティブな
スレッドみたいなもうちょっと複雑なものとするなら、C++のみでは無理、
アセンブラが必要。WindowsならCreateFiberを使えるが、NT系で
しか使えない。
これからマルチコアが当たり前になると、スレッドをタスクと名づける人が増える
かもね、おおややっこしい。
152:名前は開発中のものです。
06/11/05 09:43:30 wi810l51
>>151
147の発言を地でいってるな。
153:名前は開発中のものです。
06/11/05 14:05:29 zA+hRC02
>>151
そういう意味のタスクじゃなくて
154:名前は開発中のものです。
06/11/07 04:30:19 grfbgSgu
初心者だがレスさせてくろ
タスクシステムはビデオ屋でいうポストレンタルシステムではないでしょうか
ゲームプログラムにおいてはリアルタイム戦略ゲームのＡＩに有効かと
例えば自立スレッド型のユニット(目的地を指定すれば、勝手に動いてくれる)をＡ地点に移動したのち、Ｂ地点に移動させるAIを組もうとしたときなど。
ユニットのスレッドが行動リストをもっていて、AIはぼんぼんリストに行動をaddしていけばいい
ユニットのスレッドはリストの下から行動を処理する。
このシステムがないとAIはユニットがＡ地点に到着した情報を取得し、
その後でＢ地点に池という命令を出さなければならないのでAIの手間が非常にかかる おやすみなさい
155:名前は開発中のものです。
06/11/07 10:26:39 vi/Nuttr
>>154
それは >>148 の言うようなタスクシステムとは全然違う。
コマンドのキューと言えば十分。システムなんて呼ぶほどのものでもない。
「タスクシステム」の共通な定義が無いのが
一番の問題なのかもしれないと思った。
俺様解釈が多すぎていまさら定義も難しい。
156:名前は開発中のものです。
06/11/07 10:45:17 FxrEUOug
少なくともこのスレでのタスクシステムの共通定義は
>>148でいいんじゃないの？
今までずっとそれ前提で話が進められていたし、
そうでないと思っているのは的外れな>>154だけだと思うんだが。
タスクに親子関係持たせるとか優先度がどうだとかいった細かい部分は
その都度最適なものを選べばよし。
157:名前は開発中のものです。
06/11/07 19:23:55 qUpAvALP
Cでリスト使ってて、
C++に移行したら「それタスクシステムだよ」って言われた。
どうすればいいでしょう？
158:名前は開発中のものです。
06/11/07 21:40:27 3jPQsnxn
もうすこしｋｗｓｋ
159:名前は開発中のものです。
06/11/08 10:10:54 U+HCvDbD
>>157
そうだよ。って答えれば解決。
160:名前は開発中のものです。
06/11/10 11:57:52 bWKjGfw+
ところで
URLﾘﾝｸ(d.hatena.ne.jp)
ここのブログのこの問題といてみない？
161:160
06/11/10 11:58:41 bWKjGfw+
すまね、上げちまった
162:名前は開発中のものです。
06/11/10 13:40:25 0fi4/IIn
この板にしては珍しく良スレだな
163:名前は開発中のものです。
06/11/10 21:25:10 ZkgdRmE9
>>160
>koei.co.jp scei.co.jp square-enix.co.jp みてるんだったら会社いれてよ！！！！！！
お題とは関係ないがこの辺にワロタｗ
proxyぐらい使いましょうね、大手の皆さんｗ
164:名前は開発中のものです。
06/11/10 22:26:18 HTGezavx
>>163
別に問題ないと思うけど。さすがに社内サーバのアドレスを referer で飛ばしてくるのは
どうかと思うが＞k社
165:名前は開発中のものです。
06/11/11 01:08:30 YsMNBgEw
自意識過剰
166:名前は開発中のものです。
06/11/12 00:41:12 uTWo+6kj
んで問題はとかねーの？
167:名前は開発中のものです。
06/11/12 01:35:58 R+1O/KH4
>>166
マジメに考えるほどのもんじゃない気がするが。
メモリの断片化や使用量見積もりを考えると、全オブジェクトを必要最小限の寿命で
確保・解放なんてせずに、シーン毎に必要なファイルぶち込んだアーカイブ作って
終わりだし。
168:名前は開発中のものです。
06/11/16 13:28:43 S/Ecbdk+
コーエーといえば寝るおもしろす事件だなｗ
169:名前は開発中のものです。
06/11/16 14:51:20 fgcxjfqh
>>167
いつ何時どういう顔でどういう武器を持ったアバターが登場するかわからない
MMOとかだとシーンとか生ぬるいこといってられないんじゃない？
170:名前は開発中のものです。
06/11/18 00:38:40 hjek6YSO
>>169
組み合わせが分からないなら、ワーストケースでも対応できるようにする必要があるから、
賢いメモリ管理はしない方が良いと思うが。
171:名前は開発中のものです。
06/11/18 00:45:51 Blaci8UD
１００００とか決めうちで適当にアバター（？）放り込む領域とっときゃい～じゃん。
クライアントで１００００人同時表示とかどうせ無理だからｗ
なんかが湧いたとしても、
射程外の見かけ小さく見えるアバターから削除しちまえばOK。
172:名前は開発中のものです。
06/11/18 18:42:03 uDXwDRk4
>> 171
その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
173:名前は開発中のものです。
06/11/18 19:28:39 GUEcKJwf
スケーラビリティはガン無視がゲームにおけるデータ構造・クラス設計の常識？
174:名前は開発中のものです。
06/11/19 04:21:52 qRasGZX0
コンシューマならそれでも良いと思うけど、
昨今のＰＣゲーム開発であればスケーラビリティは必須では？
なんせ環境が数倍以上違うことだってあるからね。
175:名前は開発中のものです。
06/11/19 06:35:18 2miANHZG
> その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
領域が決めうちでも決めうちでなくても発生する問題。
> スケーラビリティ
MMOなんだから、クライアントの更新でスケーラビリティを代替すればいい。
逆にPCの優劣で、プレイヤー間に格差が出るほうが問題と言えば問題。
176:名前は開発中のものです。
06/11/19 09:18:23 GnePFvEb
んで問題はとかねーの？
177:名前は開発中のものです。
06/11/19 10:07:08 P05vv5BZ
あれは、クラスデザインで対応すべき問題ではない、っつーのが答え
だろうな。
178:名前は開発中のものです。
06/11/19 15:53:33 3G1y/i2K
>> 175
だから、それを採用してもその問題が残るんだろ？
この問題の本質はそこだろ。どうやってデータへのアクセスを共有させんだ？
179:名前は開発中のものです。
06/11/19 16:36:03 2miANHZG
いや、エンジン書いてもそれはゲームじゃないからｗ
さっさとゲーム上の具体的なシーンについて見積もりを建てなさい。
領域なんて初期化時に必要な領域全部取ってしまえば問題無い。
180:名前は開発中のものです。
06/11/19 16:54:45 3G1y/i2K
>> 179
件のサイトってMMORPG作ってるわけで、
MMORPG開発を前提にした問題を出してるんだがなあ。
シーンなんて簡単なもんじゃ見積もれないって。
181:名前は開発中のものです。
06/11/19 17:17:03 2miANHZG
↓↓↓ここから見積もれる/見積もれないの一点だけで１００年戦争↓↓↓
182:名前は開発中のものです。
06/11/19 20:33:12 GnePFvEb
なんか虎をつかまえてほしいなら虎を屏風からだしてくれみたいな回答だな
あきれた
183:名前は開発中のものです。
06/11/20 01:22:30 SHLy4x4v
>>180
URL貼った上で「件のサイト」を持ち出すのは、
あまり良くないと思うのだが…
184:名前は開発中のものです。
07/01/14 05:03:57 gu/ia/06
良スレあげ
185:名前は開発中のものです。
07/01/19 02:34:32 RsBU2cJ/
シーン・・・
昔すべてのシーンはスタックのみで再現可能と思ってた時が俺にも有りました。
実際大半はＯＫだけど、相互に行き来できるような仕組みを作りたい場合
別の方法をとらないといけないし、平行して動かす場合や
一部をストップさせたいときはいっそシーンクラスじゃなく
スレッドで動くクラスの方が良いと思えてきました。
まだ研究中。
186:名前は開発中のものです。
07/01/19 13:33:30 GdZe8cga
俺はそれは兄弟関係をコンポジットにして解決しとるよ
187:名前は開発中のものです。
07/01/19 14:48:25 RsBU2cJ/
コンポジットパターンですか？
なるほど。
188:名前は開発中のものです。
07/01/27 00:03:58 Mwc3VMrB
良スレ発見。
皆様のお知恵をお借りしたい。
効果音、BGM、描画エンジンなどの管理オブジェクト（コンテキストっていうのか？）をどうやって、
キャラクターなどから参照させるかということについてです。
キャラのオブジェクト生成時に、必要なものだけ渡してやるのがベストなんでしょうか？
今は、全部持ったGameクラスっつーのを作って、そのインスタンスのローカル変数一個を
どこからでも参照できるようにして、
各キャラクターから参照できるようにしているんだが、
今の流行的に、ローカル変数がイヤンなので、
なんとかしてやりたいのです。
ABAさんのソースとか見ると、生成時に引数で渡しているんだけど、
うちのDelphiだと、各ユニット間の循環参照問題を回避できなくて真似できないんだよね・・・。
189:名前は開発中のものです。
07/01/27 00:27:08 GLW5syD3
ローカル変数？グローバル変数だよね。
その方法がまあ無理なくやれると思う。
グローバル変数がどうしても嫌なら
インターフェイス宣言を使えば、循環参照は回避できるよ。
190:名前は開発中のものです。
07/01/27 00:46:55 Mwc3VMrB
ごめん。グローバル変数です。
インターフェースか、Delphiのインターフェースって普通じゃないからなあ。
過去レスに出てた↓こちらのCtxってのが参考になるかもしれんけど。
或曰: お仕事
URLﾘﾝｸ(www.issei.org)
191:名前は開発中のものです。
07/01/27 01:29:23 lX9/hWgh
音はコンテクストとは違うのでは？リソース？
そのインスタンスの性質そのものなんだからバリバリ依存してていい
描画デバイスはそれ自体のステートがあるんで外からもらう必要があるだろうけど
別にグローバル変数で問題ないでしょう？
まあ描画するときにだけ引数でもらうように改変するのを無理して止める気はないけど
＞URLﾘﾝｸ(www.issei.org)
おもしろいなーfacade+visitorかぁ
192:名前は開発中のものです。
07/01/27 05:01:28 Cu/waNhi
サウンドみたいなものはモロにシングルトンにしてしまって
CSoundManager::GetInstance().Play( FX_HOGE );
こんなんでよいのでは
193:名前は開発中のものです。
07/01/27 14:40:32 lX9/hWgh
＞URLﾘﾝｸ(www.issei.org)
何か違和感があったので、寝ながら考えたんだけど
こいつの問題はゲームエンティティのクラスとctxのインターフェイスが１対１になってるとこかな。
まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
いちいち別の実装とインターフェイスを設けなくてはならなくなる。
意味のない制約を守るために重複コードができてしまう。
194:名前は開発中のものです。
07/01/27 15:41:16 lX9/hWgh
それにゲームエンティティクラスが増えて、継承の階層とかができても
ctxの実装は全部の名前に_ctxつけたインターフェイスを全部同時に多重継承するんだろか？
ctxにmixinするインタフェイスはゲームエンティティのクラス群の構造に依存しないで
区分けそのものに対する名前をつけてやる方がきれい、というか合理的に思う。
例えばとにかく弾をつくるインタフェイスを公開するctxインターフェイスならICtxShootとか。
195:issei
07/01/27 22:48:39 +PYaC1IQ
>>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; };
とかかなぁ。私は汎用インターフェースは結局作らずシングルトンで済ませちゃった
けど。
196:名前は開発中のものです。
07/01/27 22:53:18 FT2+QYPW
>188
個別にオブジェクトのアドレスを渡した場合、パラメータの個数が膨大になるのと、
きれいにまとめないとかなり手間がかかるね。
シングルトンで実装して、グローバルアクセスがよいのではとおもう。
197:名前は開発中のものです。
07/01/28 01:11:39 aVNVY6/P
>>issei（誰？ｗ）
＞// これで実装は両方に提供できる
確かにそうだね。書いてみてから気がついた。
具体的に書くコードの量とかの増減をあげつらう批判をしたいわけじゃないだホントは
また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
というエンティティクラスからの表明が主題で、managerが全部を継承して実装するというのは、
たまたま今回採用されたやりかたに過ぎない、別にどうでもいい部分なんだね。
エンティティクラスが継承ツリーをつくるようなときは最上位のクラスのctxに
下位層のクラスが使おうとする純粋仮想関数も書き加えてかなきゃいかんね。
つまり最上位のオブジェクトを以って、主要メソッドを実行しても、
その下位の継承したクラスの機能追加されたものが呼ばれる可能性があるわけなので。
なんで俺が日記の作者も言ってない手法の使い方をまとめてんだ…
ぜんぜん関係ないけどcontextってのはあんまり実態にそぐわない名前だと思うなぁ。分かるけど。
relianceとかdependencyとかのがいいような気がする。
198:issei
07/01/28 01:38:40 ViuHLna9
>>197
> >>issei（誰？ｗ）
日記の人です。
> また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
> このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
そうそう。
本当のマネージャとは別に、エンティティの単体テスト用とかデバッグ用に ICtx***
インターフェースを実装した別のマネージャーも作ってました。
確か別のプログラマがエフェクト用の対話型エディタを作ってたんだけど、そこで
デザイナからキャラクタにエフェクト乗せて見たいとリクエストがあって、エフェクト
エディタにキャラクタ用のコンテクスト実装してたんじゃなかったかな。もちろん、
大半の仮想関数はダミー(ヒット判定なんかの関数は、常にヒットしないと返す
だけ）だけど。
199:名前は開発中のものです。
07/01/28 19:27:03 aVNVY6/P
風呂はいりながら考えたんだけど
ようは移植用区画、エンティティクラス、実装を委譲したい関数群、
それぞれをシステム内で１対１対１。ひとまとめにしたいわけだ。それはわかる。
だが無駄に暗黙的な命名の制約を持ち込むvisitorインターフェイスには反対。
contextというが、それらが文脈として差異を持たされるのは結局はプロジェクト全体で複数作られる
実行単位ごとなわけだ。それに対してvisitor風に関数レベルで型への依存を表明するのは
適当だとは思えない。何がどのレベルで変わるのかがきちんと示せてるのがいいコードっすよね。
ついでに実装をまとめるだけが目的の節操のないmixinも反対だ。
俺はこうする。
class Player
{
public:
void exec() { CreateShoot(); }
void Method0();
private:
static void CreateShoot(); // どこか他のコンパイル単位で定義してやる
};
どこか他のシステムへもっていってもstatic関数を定義した.cppの方だけ取り替えれば移植が完了する。
200:名前は開発中のものです。
07/01/31 00:35:16 NKCnpIjT
クラス名・変数名に迷ったら書き込むスレ。Part9
ｽﾚﾘﾝｸ(tech板:113-132番)
から誘導されてきました。
・こんな構造の名前はなにがいいですか？
・タスクっぽいですねー
・擬似マルチタスクっぽいかも？
・スタック使え！
・え？スタック？
・segregated storage使え。
・boostのpool？
まあ、そんな感じで、ゲーム向けのデータ構造をどうするかって話になりました。
201:名前は開発中のものです。
07/01/31 00:44:13 YqKTmdjS
>>200
答えでてんじゃん。
ここで何が聞きたいの？
202:名前は開発中のものです。
07/01/31 00:49:48 jNUdiQRe
フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。
203:名前は開発中のものです。
07/01/31 01:00:05 8/b3tbHY
>>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの？
204:名前は開発中のものです。
07/01/31 01:08:05 kxHbC4YN
いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろｗｗ
205:名前は開発中のものです。
07/01/31 01:09:38 8/b3tbHY
今適当に書いたけどフラグなんか使うよりこっちのほうがいいんじゃないか
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);
}
};
206:名前は開発中のものです。
07/01/31 01:10:11 94hlWcQw
>>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 だけと。
207:名前は開発中のものです。
07/01/31 01:13:52 NKCnpIjT
boostみて、なんじゃこりゃーな感じだったので、
>>206とか、見るとわかりやすいですね。
配列でデータは持つんだけど、使用中ノードは、連結リスト風につないでおくっと。
未使用ノードも同じようにもつ。
これだけで、済む話かー。
208:名前は開発中のものです。
07/01/31 01:14:36 YqKTmdjS
>>205
それが segregated storage だろ。
209:名前は開発中のものです。
07/01/31 01:15:32 8/b3tbHY
>>208
そう言うのか
210:名前は開発中のものです。
07/01/31 01:17:52 kxHbC4YN
欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろｗ
だって、>>200より優れたクラスなんて存在しないんだからｗｗｗ
つ 【ステフ１８クラス】
つ 【次世代ｺﾐｭクラス】
つ 【ﾊﾞｷｭﾝﾊﾞｷｭﾝクラス】
この板ならではのクラス名を授けるから好きなの選べ
211:名前は開発中のものです。
07/01/31 01:18:10 8/b3tbHY
そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz
212:名前は開発中のものです。
07/01/31 01:22:57 94hlWcQw
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>
213:名前は開発中のものです。
07/01/31 01:24:55 NKCnpIjT
>>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。
>>210さんが、私のデータ構造を最高！マンセー！他はクズ！>>200様に一生従います！
と言ってくださるのは、うれしいのですが、
他に、どんな効率のよい、データ構造があるかというのを知りたいのです。
Delphiには、boostねーよー。うらやましい。
214:名前は開発中のものです。
07/01/31 01:26:10 NKCnpIjT
× >>200様に一生従います！
○ >>200様に一生を捧げます
間違えました。
215:名前は開発中のものです。
07/01/31 01:26:40 94hlWcQw
>>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの？
216:名前は開発中のものです。
07/01/31 01:46:00 94hlWcQw
もしかしたら、主要なデータ構造を一通り勉強したいってこと？ それなら、
まずは(データ構造を処理するアルゴリズムとセットで)
・Cプログラマのためのアルゴリズムとデータ構造
・珠玉のプログラミング
・プログラム設計の着想
・プログラミング作法
あたりの書籍を読むのがお薦めだが。
217:名前は開発中のものです。
07/01/31 02:00:35 kxHbC4YN
>>213
いや、普通に皮肉だから、無理にレスしなくていいよ。
218:名前は開発中のものです。
07/01/31 02:31:13 sTyDsN4F
この板で数少ない有用なスレッドだな
219:名前は開発中のものです。
07/01/31 15:38:04 CxDF9OMM
>>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。
>>216
勉強したいだけ、というわけではないのですが、
参考になります。
220:名前は開発中のものです。
07/01/31 19:22:58 WbpDldoh
弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは１つあれば十分だし。
221:名前は開発中のものです。
07/01/31 20:28:29 94hlWcQw
>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。
メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。
222:名前は開発中のものです。
07/01/31 22:47:38 YNrC6zK6
>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ
223:名前は開発中のものです。
07/01/31 23:00:17 94hlWcQw
>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。
一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。
224:219
07/01/31 23:25:03 NKCnpIjT
まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
（動作環境は、PCです）
新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。
225:名前は開発中のものです。
07/03/21 22:27:58 /cwA8n13
>>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね
226:名前は開発中のものです。
07/03/23 13:48:25 vxAgs8Dc
良スレage
227:名前は開発中のものです。
07/03/26 06:10:31 mFbF2Qb2
ところで、
キャラクターの構造体は何で取ってる？
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。
皆は何で取ってる？
228:名前は開発中のものです。
07/03/26 06:11:56 mFbF2Qb2
あ、ゲームは普通の２ｄのアクションゲームとかです。
229:名前は開発中のものです。
07/03/26 08:35:24 I1HKFzJn
doubleでおｋ
次の話題どうぞ
230:名前は開発中のものです。
07/03/26 12:51:40 74T0tUus
単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ
231:名前は開発中のものです。
07/03/26 18:43:03 /edWn9Q+
>>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし
232:名前は開発中のものです。
07/03/26 19:09:19 I1HKFzJn
桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。
そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。
233:名前は開発中のものです。
07/03/26 19:20:52 /edWn9Q+
>>232
そんなクラス作らなくてもいいんじゃね？
16ビットシフトするだけでゲームの精度的には十分かと。
234:名前は開発中のものです。
07/03/26 21:35:29 /T0E1d66
URLﾘﾝｸ(shinh.skr.jp)
235:名前は開発中のものです。
07/03/26 22:10:26 xV5pAsSl
>>232
なんか勘違いしてるけど、固定小数点数にするのに１０進は関係ないぞ。
236:名前は開発中のものです。
07/03/26 22:13:45 I1HKFzJn
>>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。
237:名前は開発中のものです。
07/03/27 01:42:55 0naF3MYn
10進でも2進でも丸め誤差は出るってば。
238:その1
07/03/27 06:12:21 6cy45QrY
「キャラの座標の型に関して」
・整数か小数か -> 断然小数
・小数の表現方法
-> 浮動小数点数 or 固定小数点数
-> 2進表現 or 10進表現
・浮動小数点数
○ 基本型であるので扱いが楽
× 演算速度が遅い
△ 非常に近い値同士を比較したときに桁落ちが発生する
(桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
○ 比較による桁落ちが発生しない
○ 実態は整数型なので演算速度が早い
-> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
× 固定小数点数オブジェクトの生成が頻繁であると遅くなる
(特にオペレータ・オーバーロードに注意)
△ 小数点以下の精度(桁数)が固定
(ただし、精度が足りなくて困ることはまず無いと思われる)
239:その2
07/03/27 06:13:22 6cy45QrY
・2進表現
○ 基本型は2進表現なので扱いが楽
× 10進表現で有限小数となるが2進表現で循環小数になるような値の場合、
表現できない桁が切り捨てられるなどして丸め誤差が発生する
・10進表現
○ 循環小数に対する丸め誤差が起きない
-> × 一般によく使われるであろう加算減算処理では問題ないが、
除算を行うなどすると何進数であろうが丸め誤差は発生する
XX 基本型とは程遠い別次元の演算手法が要求される
(2進表現で循環小数となるような値を基本型で記述した時点でアウト)
× 同じバイト数で表現できる値の範囲が2進表現より狭い
勝手にまとめっぽい形式で書いてみた。
固定小数点数に関してはクラスとして実装した場合を想定した。
個人的に、固定小数点数を素のintで表現して、その都度シフト変換を行うような手法は、
変換方法に依存した関数/クラスを大量発生させるので論外だと思う。
240:名前は開発中のものです。
07/03/27 06:39:01 AmaYqa2T
10進表現ってBCDのことだったの？
俺はてっきりintを10^nで割って使う話だと思ってた。
241:名前は開発中のものです。
07/03/27 06:42:53 6cy45QrY
色々書いたけど、結局俺は無難なdoubleを使っちまうかなあ。
試しに固定小数点数クラスを作ってみたけどあんまし早くならなかった。
っていうかコンパイラによって速度が大きく変わりそうな予感。
10進表現での計算は、誤差が出たら切腹必至の
銀行システムとかでのみ使うものだと思っている。
言語的にサポートされていれば話は別だけど。
以上長文&駄レスすまん。
242:名前は開発中のものです。
07/03/27 06:45:51 6cy45QrY
>>240
俺は流れ的にBCDのことだと思ったが…。違ってたらすまん。
243:名前は開発中のものです。
07/03/27 10:06:48 KORunXqt
昔は、固定小数点使ってたな
今は、さすがに、浮動小数だわ
問題は、環境によっては、リプレイでずれるとかその辺
（D3DXの最適化とか最適化とか最適化とか）
244:名前は開発中のものです。
07/03/27 12:34:52 WDGoOIYE
浮動小数点だと0.1ですらがあらわせないからな
表せないのに無理しているのが浮動小数点
あらわせないのなら扱わない、問題が出ないようにするのが固定小数点
0.1を10回たしたら１になるとか思ってるような人は固定小数点つかっとけと
245:名前は開発中のものです。
07/03/27 14:36:14 DOw2VNK3
アナログコントローラーとか3D処理やったこと無いのかな
246:名前は開発中のものです。
07/03/27 19:55:06 OAIOW3b5
Flashとかだと0.5ずつずらさないと隙間が空くとかあるんだよね
247:名前は開発中のものです。
07/03/27 20:06:13 6cy45QrY
微妙に関連する話題だと思うんだけど、
皆は(無限)多倍長精度整数を使ってたりする？
248:名前は開発中のものです。
07/03/28 00:55:28 3c8pkg+a
>>247
固定小数点数使ってたら、上の桁が足りなくて、
仕方なしに64ビット整数を使っちゃったことはある
249:名前は開発中のものです。
07/03/28 05:12:49 cMkZ8VMH
>>247
そういうのは学術用だと思うよ。
ゲームなら実際問題そんないらんっしょ。
250:名前は開発中のものです。
07/03/28 05:53:37 vQ7wya7A
得点計算で使われることもあると思う。
32bit符号なし整数では40億程度しか表せないし。
恐ろしい桁数の得点をガンガン加算させて、
かつ一の位までキッチリ使っちゃうような
血も涙もない鬼の方御用達です。
251:名前は開発中のものです。
07/03/28 07:59:56 cMkZ8VMH
無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか？
252:名前は開発中のものです。
07/03/28 11:11:39 xf4mLohJ
>>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。
253:名前は開発中のものです。
07/03/28 12:08:50 hyD2GS3G
ビルゲイツの資産とか32bitに収まりきらんもんな
254:名前は開発中のものです。
07/03/28 12:54:06 HnZM11tF
そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。
255:名前は開発中のものです。
07/03/28 15:10:12 +k+f3/yD
32bitどころじゃないだろ。
まあ、毎年訳分からん団体に１兆寄付してるおっさんだからな。
寄付してるのは妻の方だけ？
256:名前は開発中のものです。
07/03/28 16:57:57 erfbPR6U
自分の設立した財団じゃないのあれ？
257:名前は開発中のものです。
07/03/30 00:16:52 xOzIjQQy
Delphiの日付用構造体TDateTimeを馬鹿にするなよ？
日付なのに、不動小数
258:名前は開発中のものです。
07/03/30 01:10:16 /yTpVVer
不動ならいいや('ー`)
259:名前は開発中のものです。
07/03/30 03:52:48 HXn7HlKm
MSのAccessも日付はdoubleでもってたような・・・
260:名前は開発中のものです。
07/04/01 02:13:01 aK7v4JwN
いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。
261:名前は開発中のものです。
07/04/01 13:27:10 vpNPV10r
>>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。
262:名前は開発中のものです。
07/04/01 14:21:19 XdYqPGRk
なるほどそういうときにシリアライズを使うのか
263:名前は開発中のものです。
07/04/01 15:15:13 Sn7iJUNq
>>260
Gemsの５巻にスタックを使ったシーン管理が載っている。
試してみたら、なかなか使い易かったよ。
264:名前は開発中のものです。
07/04/01 15:35:35 gVILklLW
>>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ
265:名前は開発中のものです。
07/04/01 20:39:12 4uyw/V8k
>>260
作ってるゲームによるでしょ。
シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る（ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく）、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。
266:名前は開発中のものです。
07/04/05 20:02:57 53u6wZm0
>>263
Gemsうｐ！！
って、無理だｗ
ソースコードだけでも配ってないのか・・・
267:名前は開発中のものです。
07/04/06 02:24:49 jVhSsUiB
【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。
268:名前は開発中のものです。
07/04/06 16:07:18 +BNVME6N
スタックベースのシーン管理に参考になるページはないですか？
269:名前は開発中のものです。
07/04/07 09:34:17 ok5ggep+
どっかのやねうの昔のサイトに解説がなかったか。
270:名前は開発中のものです。
07/04/07 12:47:03 lstp6MTf
YaneSDK.Netのソース読め
271:名前は開発中のものです。
07/04/08 01:31:41 TWCxMGaJ
本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください＞＜
2ndからトランジエントビルトを移植しようとしたんですが正直無理です＞＜
272:名前は開発中のものです。
07/04/08 01:42:46 Svf9QlZ3
無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。
273:名前は開発中のものです。
07/04/08 02:50:06 l6t1YJuf
皮肉にマジレスしてどーする
274:名前は開発中のものです。
07/04/08 13:14:13 8g6onocj
そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。
275:名前は開発中のものです。
07/04/09 03:25:15 /ygJ9fwS
騙された馬鹿が、ギャーギャー文句言ってただけ
276:名前は開発中のものです。
07/04/09 03:38:12 TJO4g1v+
いい加減スレ違い。
277:名前は開発中のものです。
07/04/09 13:14:13 /ygJ9fwS
スタックベースのシーン管理について質問
つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・
278:名前は開発中のものです。
07/04/09 15:13:20 bk7kEELW
スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか
279:名前は開発中のものです。
07/04/09 16:14:10 3UDAKRrm
シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない？
280:名前は開発中のものです。
07/04/09 18:50:04 CrOX57BA
>>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。
281:名前は開発中のものです。
07/04/09 20:46:27 d0StE6D+
>>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。
282:277
07/04/09 20:49:46 d0StE6D+
とりあえず、googleして、定番とおもわれる
・呼び出し（Call)
・移動(GoTo)
・呼び出し側に戻る（Return)
をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、
これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし
クソー、Game Programing Gems 5がほしいZE
283:277
07/04/09 20:54:13 d0StE6D+
> 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな？と思うし
284:名前は開発中のものです。
07/04/09 23:33:21 HDs+xqt8
ところでシーン間の関係はだれが持つの？
シーンクラス？シーン管理クラスとか他のクラス？
分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・？
シーン遷移管理とシーン関係管理＋フラグ管理に分けるとか？
>シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。
こういうときにファイナライザ使うもんじゃないしね。
285:名前は開発中のものです。
07/04/10 00:13:19 NhbAQuFj
>>277
シーンは最初に全部確保して
最後に全部解放してるよ。
シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。
こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか
出来ますよ って趣旨だったと思う >Gems5
ただ、ウィンドウ関係以外には特に利点は無さそう。
286:名前は開発中のものです。
07/04/10 01:08:35 wXzQkwkx
マルチスレッドを実現する手段の一種ということ？
287:名前は開発中のものです。
07/04/10 01:12:58 vYIHoF6r
>>285
＞でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね？
LIFO≠スタック
288:名前は開発中のものです。
07/04/10 01:16:37 EIMh3HFt
なんだ、シーンの遷移がスタック的なのかと思ってた。
289:285
07/04/10 01:26:00 NhbAQuFj
>>287
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから 一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたｗ
スタック全体をなめるんだからスタックとは言わないと俺も思う。
290:277
07/04/10 01:59:26 9N2vtVIw
わかった。
かなり勘違いしていた・・・。
>>288
俺もそう思ってたｗｗ
291:名前は開発中のものです。
07/04/10 09:19:06 xnqcZNCE
これ読んで、久々にパックマン作りたくなったな～。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな？
292:名前は開発中のものです。
07/04/10 09:47:11 9N2vtVIw
Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.
293:名前は開発中のものです。
07/04/11 01:26:38 hEaakUMM
>>291
> デザインパターンって、しらない人多いのかな？
んなわきゃない
294:名前は開発中のものです。
07/04/11 05:40:08 6fD2+qm/
スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったｗ
これで、
タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面
とか、
タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
リプレイメニュー→(戻る)→タイトル画面
とかできるようになったｗ
スタックベースといったらやっぱりこっちだろｗ
295:名前は開発中のものです。
07/04/11 05:56:16 M15Cgj6f
スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。
296:名前は開発中のものです。
07/04/11 07:47:20 J6IpVt/X
スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る＝push操作
・1つ前のシーンに戻る＝pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279と>>281のようなやり取りが行われている現状では仕方がないか。
297:名前は開発中のものです。
07/04/12 03:38:40 AG1SAh/k
実質が状態遷移ならstateパターンでいいやんって事ですか？
298:名前は開発中のものです。
07/04/12 04:43:05 0Ip1HTkJ
>>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。
どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作＝次のシーンに移る
・pop操作＝1つ前のシーンに戻る
・top操作＝現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。
これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる？
299:名前は開発中のものです。
07/04/12 05:16:23 0Ip1HTkJ
(続き)
で、何故Stackベースのシーン管理に関して
>>295と>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。
例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。
"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。
"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。
ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。
300:名前は開発中のものです。
07/04/12 07:27:37 KA8mV/7R
Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。
301:名前は開発中のものです。
07/04/12 11:44:45 dOVFJA3U
>>185-
ちょっと参考になるよ
302:名前は開発中のものです。
07/04/12 18:19:58 sR+tFe8j
色々考えて、俺はスタック的な遷移も結構いいんじゃないかと思えてきた。
スタックだと、シーンの遷移の責任は全て親に任せることができる。
キャンペーンモードなのか、単独のマップを遊ぶだけのモードなのかは、自分は
知る必要もなく、遷移する理由（勝利、敗北、キャンセル…etc）だけを伝えれば
次にどのシーンになるかは親が決めてくれる。
各シーンが自分で次のシーンを選んでダイレクトに遷移していくよりは、
親に一任した方がすっきりするね。
スタックそのものでなくても、スタック的な遷移ができることは便利だと思う。
303:名前は開発中のものです。
07/04/12 20:03:01 +rjgMuLJ
うむ、完全にpush/popに収める必要はないよな。
304:名前は開発中のものです。
07/04/12 20:15:13 BUTEbHo0
素直に多方向リンクリストでやれよ。
305:名前は開発中のものです。
07/04/12 20:25:07 +rjgMuLJ
それは実装・データ構造の話じゃん。
306:名前は開発中のものです。
07/04/12 21:46:48 V5BuRGqQ
>>302
遷移する理由を伝えることによるシーン遷移ってのはいいね。
が、これは別にスタックに限った恩恵ではない
(っていうのは>>302もわかってると思うけど)。
>>304の言う多方向リストでも可能(っていうか本来はこっち)だし、
イテレータが指すシーンを現在のシーンとする双方向リストでも可能。
多方向リストで工夫して実装すれば、
リソースを食うシーンに移ったときに
前のシーンをいくつか解放するといった処理が行えるし、
シーンを激しく前後するような操作をしても
オーバーヘッドがかからないのでいいかも。
もっとも、ゲーム起動時にリソースを全部先読みしても
全く問題ないようなゲームだったら、
積みっぱなしのスタックで全く問題ないし、
これが一番簡単だと思うけど。
307:名前は開発中のものです。
07/04/12 22:34:50 Yo7l8Dzb
"多方向リンクリスト"に該当するページが見つかりませんでした。
308:名前は開発中のものです。
07/04/13 01:17:14 FDWvNnME
双方向リンクリストじゃない？
309:名前は開発中のものです。
07/04/13 01:37:40 maKmelpg
色んな方向につながってるってことは…
vectorじゃねぇの？
310:名前は開発中のものです。
07/04/13 02:13:59 ye+8qT/8
遷移元シーン番号と遷移事由コードで
テーブルから遷移先シーン番号（またはシーンオブジェクトの参照）を
引くだけというのはだめだろうか
311:名前は開発中のものです。
07/04/13 04:18:27 VGgK68eb
ヒント：C言語などの関数
312:名前は開発中のものです。
07/04/13 04:47:41 sVc4IdNT
>>311
エレガントじゃない気がする
313:名前は開発中のものです。
07/04/14 05:39:36 0P7qLuwH
状態の保存方法なんて画面にあわせて stack なり queue なり
vector なり list なり、適当に作ったツリー構造なりを使えばいいよ。
コンテナ実装するのも一苦労だったアセンブラやCで組む時代じゃないんだから、
全体でどれに統一するか悩む必要なんて無いでしょ。
314:名前は開発中のものです。
07/04/15 10:34:45 PbHNo8Qe
ログ
315:名前は開発中のものです。
07/04/15 14:31:59 GX7kX5Cm
参照カウント付きスマートベクトルポインタ使ってシーンの遅延生成や破壊を自動管理したり
夢が広がりまくりんぐ
316:名前は開発中のものです。
07/04/19 13:16:55 WPH1WRyj
シーン間の遷移（例えばクロスフェード）とかどうやってる？
317:名前は開発中のものです。
07/04/19 13:42:33 1tbYRD5H
俺はシーン別に切り分けてバッファを持っている。
318:名前は開発中のものです。
07/04/19 22:50:53 ofjIK8wt
自分は、Viewで処理してて、Modelでのシーン自体は完全に移行済みにしとく。
あくまで、表示（演出）は表示（演出）ときりわけやったほうがいいと思うし、
また、切り分けとくと変更も楽だし、テスト時とか演出要らん場合はさっさと飛ばせるし。
319:名前は開発中のものです。
07/04/20 18:21:55 NDgAfFd0
やべ。意味が分からん^^
ちょっと確認させて欲しい。
class IScene {
virtual void update(ISceneContext& ctx);
virtual void draw(ISceneContext& ctx);
};
class SceneStack {
void push(IScene *scene);
void pop();
void call(IScene *scene);
void update(ISceneContext& ctx) { /*登録されたシーンの更新*/ }
void draw(ISceneContext& ctx) { /*登録されたシーンの描画*/ }
};
自分の理解では、こんなのがシーン処理の実装なんだけど、
まずこの解釈はあってる？
当然、シーン変更時はscenestack.call(new_scene)とかやるわけね。
>>317
シーン別にバッファを持ってるってことは、
シーン遷移時の処理はSceneクラスで遷移を行うか、
他の遷移専用クラスがあるってことですか？
>>318
↑の例でいうと、ISceneまたはSceneStackのdraw内のみで
遷移処理を実行するということですか？
全然分かってないかもです。
理解が足りなくて申し訳ない。
320:316
07/04/20 18:22:39 NDgAfFd0
>>319も316です^^
321:名前は開発中のものです。
07/04/20 23:58:50 jHP7m8qh
やねうら臭がする
322:名前は開発中のものです。
07/04/21 04:53:19 upqCn/9t
>>319
俺もおおよそそんな感じ
323:名前は開発中のものです。
07/04/21 09:13:46 jPfR3hGz
沖縄県の方へ（命に関わる注意事項です）
沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度 沖縄 三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…
※一国二制度
簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。
今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
324:317
07/04/23 17:44:03 jyQ0IgwD
>>318とほぼ同じと思うけど
シーンに関してスタックは使ってないので、並列処理しているとき
それぞれのシーンが自分用の裏画面などを持ってないと都合が悪い
表示（演出）は別クラスにして任意シーンの裏画面を複数使って料理する
ぶっちゃけ、カメラを切り替えている感じ
325:名前は開発中のものです。
07/04/24 20:58:04 LmvfBEf6
>>324
なーる。表示用クラスが裏画面(テクスチャだよね？)
を複数使って演出してるわけね。
ありがとう^^
326:名前は開発中のものです。
07/04/30 13:33:52 rkXlhSNv
RPGでマップとかイベントはゲームスタート時に全部ファイルから読み込んでメモリに置いておくほうが普通でしょうか？
それともマップに入ったときにファイルからロードするほうがいいでしょうか？
327:名前は開発中のものです。
07/04/30 13:38:16 Omqviadr
普通なら、使いもしないデータを主記憶に展開しておくのは無駄としか思えないが・・・
328:名前は開発中のものです。
07/04/30 14:13:55 +32zYLn2
環境とか開発の容易性とかいろいろ考えた上で全部入れるのはべつにかまわん
重いのは画像や音声だったりするわけでそれがないので別に大丈夫かと
規模によっちゃそれすらもまるごといれてもかまわんけどな
1MBもあればFF4がまるごとはいるわけで
329:名前は開発中のものです。
07/04/30 14:36:40 rkXlhSNv
動的に読み込むってなかなか難しくて・・・
FF4で1MBなら自分の程度なら全部読み込んでも大丈夫かも。
330:名前は開発中のものです。
07/04/30 16:15:04 1Z2FVuUn
シームレスは少し難易度高いが、区画ごとに区切っていいなら難しくないんじゃ？
あっちこっちでグローバル変数使うような原人は知らん。
331:名前は開発中のものです。
07/04/30 17:45:14 QczQVIdr
最初は難しいことに手を出すよりも、楽なほうでやったほうがいいよ。
後からだんだん発展させていけばいいと思う。
ぐちゃぐちゃになったらリファクタリングで。
332:名前は開発中のものです。
07/05/01 07:32:01 n4UjW/KJ
クラスが多くなってぐちゃぐちゃになってきたorz
RPGって結構複雑ですぐ混乱してくる。
そろそろUMLとか勉強しないときついなと思ってきた。
333:名前は開発中のものです。
07/05/01 10:50:48 TWHDSCbL
UMLは構成を抽象化して理解するためのものであって
おぬしの想像しているものとは用途が違うぞ
334:名前は開発中のものです。
07/05/01 11:11:50 RvA2WJ3F
システムの規模が肥大して、クラスを整理するのが大変になってきたら
UMLなり何なり書いて一からやり直してもいいんじゃねぇの
335:名前は開発中のものです。
07/05/01 11:14:53 TWHDSCbL
リファクタリングとデザインパターンおぼえておけばおけ
アクセサとしてpublicなメソッド用意してるだけだとあとでみなおすとききついから
フレームワークつくればよろしい
336:名前は開発中のものです。
07/05/01 14:19:12 QizfdMH2
有名そうなライブラリをぱくるとかで
337:名前は開発中のものです。
07/05/02 23:12:09 n6prPmTN
UMLからソースのスケルトンを自動生成する奴とか使って手抜きしたい
一応ヘッダから関数の定義のスケルトンや、標準関数やライブラリの関数のusing宣言を
自動化する程度のツールは自作して使ってるけど
338:名前は開発中のものです。
07/05/02 23:15:54 waD0m0t1
今までいきなりコーディング始めてたんだけど大規模なゲーム作り始めて設計の重要性を痛感したorz
ただUML書いててもちっとも楽しくない。
339:名前は開発中のものです。
07/05/02 23:53:12 HOIFQT1u
>>338
おやこんな所に俺がいるじゃないか
早く新人研修のJava教本を読む作業に戻るんだ・・・
340:名前は開発中のものです。
07/05/03 03:33:21 aROKnpN+
俺はUML書いてるだけで楽しいけどなあ
341:名前は開発中のものです。
07/05/03 04:46:21 PxIyx3hy
同意
コードに落とす方がかったるい
342:名前は開発中のものです。
07/05/03 07:22:23 mjAAEilH
すげー、良く分かるｗ
コード打ってる時も、デバックしてる時はめんどい加減で止めたくなる。
343:名前は開発中のものです。
07/05/03 10:26:46 ykGFiN+W
俺は未だに、コーディングするときは脳内麻薬出まくり。
分かりきった定型的なコードを書いてるときは退屈で死にそうだけど。
344:名前は開発中のものです。
07/05/03 17:19:41 GHCrYaAw
人それぞれだなー
自分はキーボードかたかた叩いてちょっとずつ作っていく瞬間が楽しい
でも設計できないと先がなさそうorz
がんばってUML勉強しよう。
345:名前は開発中のものです。
07/05/03 17:36:22 mjAAEilH
>>344
UMLはそういうものじゃないぞ。基本的にあれは知らなくても十分だし。
（あくまでも、設計の書き方・設計のための言語みたいなもん。
個人か固定少人数でやるなら、適当でもなんとかなるし。）
設計を と思ってるなら、普通にオブジェクト指向系の本がいい。
自分が買って読んだ本で、お勧めは
憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門
まぁ、あと定番ながら
オブジェクト指向プログラミング入門
デザインパターンとともに学ぶオブジェクト指向のこころ
立ち読みで数ページしかみてないけど、入門の方はC++ 以外の言語（Object-C、Java、Delphi?）まで含めた本。
どれもこれも、値段も高いし・ページ数もやたらとあるしで
趣味でゲームを作るだけならちょっとオーバーワークっぽくも思えるけど、
Programmerとしての教養に読んでみては？
346:名前は開発中のものです。
07/05/03 18:20:36 q0fI33vb
憂鬱本は読んでみたけれど全くオススメできない。
ゲームプログラマなら、遅くともインベーダゲームを例とした説明のところで
頓珍漢なことを言っているのに気づくべき。
347:名前は開発中のものです。
07/05/03 18:36:59 l4cqkKLa
JAVAでもいいなら「オブジェクト脳のつくり方」がお勧めだぞ。
ＵＭＬの超簡単解説もあるし。
例題が業務システムなのがアレだが、
本質的な部分はC++も同じだから大丈夫かと。
348:名前は開発中のものです。
07/05/03 19:06:09 aROKnpN+
アレコレ言ってもしょうがないんでとりあえずUMLに触れてみて
どうやってコレを使ったら自分の助けになるのか
自分なりに理解するのが大切だと思いますよ
349:名前は開発中のものです。
07/05/03 21:21:39 ykGFiN+W
>>344
書籍で理論や共通知識を学ぶのも良いけど、ある程度コーディングできるように
なったら、「ホンモノ」のコードを読んでみるのも良い勉強になるよ。
個人的には UNIX V6 のソースコード読んで勉強したクチなんだが、いまどきの
人に薦められるかというと、ちょっと違う気がする。今だと Java, C++ あたりで
良い教材無いかねぇ…
350:名前は開発中のものです。
07/05/03 21:26:04 t/pC1jsI
UMLといってもクラス図くらいしか描かねぇ
351:名前は開発中のものです。
07/05/03 21:47:30 aROKnpN+
色んな図あるけど業務でやらない限りは
クラス図、アクティビティ図、シーケンス図あたりが限度かねぇ
352:名前は開発中のものです。
07/05/03 21:53:36 ifdqR3nP
業務でもそれプラスユースケースくらい
353:名前は開発中のものです。
07/05/03 22:57:52 ykGFiN+W
>>351
俺はアクティビティ図を抜いて、代わりにステートチャート図が追加って感じ。
354:名前は開発中のものです。
07/05/04 13:14:26 ljy2orUl
> 憂鬱なプログラマのためのオブジェクト指向開発講座
これ、全然おもしろくなかた。
わかりにくい。
オブジェクト指向分かってる後によんだのに、わかりにくかった。
「プログラマのための 憂鬱なオブジェクト指向開発講座」に直すべき。
355:名前は開発中のものです。
07/05/04 14:10:22 TiDrCtuu
そんな>>354のオススメ図書は？
いや、あおりでなしに、その本読んだけど分からなくて、今も分からないままなもんで。教えてくらさい orz
356:名前は開発中のものです。
07/05/04 21:08:31 +e+/DrXO
シームレスってどうやんの？
例えば2DのRPGマップをスクロールさせる様なばやいとか
357:名前は開発中のものです。
07/05/04 21:14:04 osoiCnRq
>>356
普通にやれば言いと思うが・・・
どんな状況を言ってるんだ？
358:名前は開発中のものです。
07/05/04 21:44:45 7VEgWe3m
>>356
マップをエリアに分割して、自分が今いるエリアの周囲をメモリに読み込んでおく。
移動して自分がいるエリアが変わったら、不要になったエリアの情報を破棄して
必要なエリアの情報を非同期読み込み。
これだけだが、何か疑問が？
359:356
07/05/04 23:07:32 +e+/DrXO
わかったありがとちん。
作ってみるよ。
360:名前は開発中のものです。
07/05/05 00:05:52 WcHz0Tx6
>>355
あー、俺は、Delphiを使っているうちに覚えてしまったたちでね・・・。
当時は、標準添付ライブラリのVCL使ったり、ソースとか読んだりして、オブジェクト指向を学んだな。
今なら、.NETのライブラリ使ったり、コンポーネント作って、覚えるようなもんだろうか。
習うより、慣れろって感じでスマソ。
あえて言うなら、実践的なオブジェクト指向ということで、
デザインパターンの言及しているwebページとか、本とかかな？
直接関係ないが、開発技法になっちゃうが、XP（エクストリームプログラミング）関連とかも、
OOP前提が多くて、実践的でためになる。
リファクタリング、ユニットテストなど。
あと、Javaでかかれた本とかページとかは、オブジェクト指向前提で参考になるよ。
361:名前は開発中のものです。
07/05/05 01:04:52 EPC7H7SP
なんとなくだが、>>360は見栄を張ってる気がする。
“ためになる” “参考になる”とか言いつつも具体的な書籍やHPも挙げないし、
言ってる事も理解へ向けてと言うよりも言葉で煙に巻く感じで（・Ａ・）ｲｸﾅｲ!!
自分なら>>355には、 オブジェクト指向プログラミング入門 を推す。
内容にがやや教科書的/板書的過ぎるから普通の読み方じゃなく
章単位の読み方とか多少英語論文的な読み方が求められるけどページ数に合った力がつくと思う。
あと、ここでなんか批判されまくってるが、「憂鬱な」はそんな悪い本じゃないと思うぞ。
まぁちらほら賛成できない部分や論理的におかしい部分は見受けるが、それでもなかなかの良書。
もう一度、読み直してみるのもいいと思うが。
362:名前は開発中のものです。
07/05/05 02:25:29 WcHz0Tx6
アホか。見栄はりに2chに来てねーよ。
煙に巻くつもりなら、レスしなけりゃいい。
具体的なページを上げられないのは、当時のをブックマークしてないから。
第一、コード書いて、読んで、実地で学んだと言っているのに・・・。
ただ、「デザインパターン」とか「エクストリームプログラミング」とかキーワード上げてるんだからさ・・・
まあ、ググレカスと言いたいところなのだが・・・
■デザインパターン
サルでもわかる 逆引きデザインパターン 第1章 はじめてのデザインパターン はじめに
URLﾘﾝｸ(www.nulab.co.jp)
Amazon.co.jp： オブジェクト指向における再利用のためのデザインパターン: 本: エリック ガンマ,ラルフ ジョンソン,リチャード ヘルム,ジョン ブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,本位田 真一,吉田 和樹
URLﾘﾝｸ(amazon.co.jp)
流行になった本だが、実例少なく今となっては読みにくい。CDの中身がまとまっていてよい。
Amazon.co.jp： デザインパターンとともに学ぶオブジェクト指向のこころ: 本: アラン・シャロウェイ,ジェームズ・R・トロット,村上 雅章
URLﾘﾝｸ(amazon.co.jp)
Amazon.co.jp： 増補改訂版Java言語で学ぶデザインパターン入門: 本: 結城 浩
URLﾘﾝｸ(amazon.co.jp)
363:名前は開発中のものです。
07/05/05 02:26:17 WcHz0Tx6
■リファクタリング
オブジェクト指向は直接関係ないけど、おすすめだから読んどけ。
Amazon.co.jp： リファクタリング―プログラムの体質改善テクニック: 本: マーチン ファウラー,Martin Fowler,児玉 公信,平澤 章,友野 晶夫,梅沢 真史
URLﾘﾝｸ(amazon.co.jp)
プロでこれ読んでない奴いたら、殴っていい
Amazon.co.jp： Java言語で学ぶリファクタリング入門: 本: 結城 浩
URLﾘﾝｸ(amazon.co.jp)
ちなみに、コメントないのは、俺が読んでないものなので注意（わかりやすそうなのを上げといた）
長いURL書き込めなくて苦労したぜ・・・
364:名前は開発中のものです。
07/05/05 02:33:04 WcHz0Tx6
あとは、OOPしてる読んでおきたいソース。
一応ゲーム制作技術板だから、ゲーム系のソースでも上げとこうか。
ABA Games
URLﾘﾝｸ(www.asahi-net.or.jp)
Titanion
URLﾘﾝｸ(www.asahi-net.or.jp)
とりあえず、ふつーに、OOPしとるんで読んで参考になること請け合い。
規模はでかくないが、ABA氏の一通り完成されたゲームばかりなので勧めやすい
あと、D言語やJavaばかりだから読みやすいよ。
365:名前は開発中のものです。
07/05/05 04:41:51 nOa25t75
初心者ならオブジェクト指向狂詩曲がいい。
内容はたいしたことは無いが、ＯＯＰの作法みたいなものがわかる。
軽く読めるのでおすすめ。
ところでダックタイピング系の書物でおすすめない？
366:名前は開発中のものです。
07/05/05 09:36:59 WcHz0Tx6
>>365
ダックタイピングって、Rubyとか、Pythonのアレですか？
C++とかで実装する方法とかってことですか？
そんな局所的な本なんてでてんのかなー。
367:名前は開発中のものです。
07/05/05 12:08:35 +5LnnL0c
ェネリックプログラミング系の書物がそれにあたるような気が
368:名前は開発中のものです。
07/05/23 19:36:40 yFXY+8Zs
たまにネタふり。
2Dゲームなどで使われる
オーダーリングテーブル（Ordering Table）は、すでに常識でしょうか。
たぶんローカル用語でしょうけど、大体用語がないので、これですませています。
おれは、弾幕ゲーム作ってるんだ！
いちいち、物体ごとに、Zソートしてたら遅くなる！そんな時に使用します。
z値ごとに、ArrayListをもって、バケットソート（バケツソート）するような感じです。
z値が広い場合は、z値を狭めるか（0～100くらいの定数にしてもいい）、
z値を割って使用します。
図では、こんな感じ。
z値
0 →□→□
1
2 →□
3 →□→□ →□→□
4 →□→□
□は物体。
369:名前は開発中のものです。
07/05/23 19:39:22 yFXY+8Zs
>大体用語
代替用語
370:名前は開発中のものです。
07/05/23 20:10:55 yFXY+8Zs
>>368
登録するのを物体ではなく、メソッドポインタなどにすれば、より汎用性が高まると思います。
371:名前は開発中のものです。
07/05/23 20:13:35 tJZKFF0H
久々に凄いネタ振りを見た
372:名前は開発中のものです。
07/05/23 20:46:34 sQffGK0m
人いたんだこのスレ
373:名前は開発中のものです。
07/05/23 21:17:01 h3A9cPXz
ぶっちゃけZソートで重いって8bitCPUかと
374:名前は開発中のものです。
07/05/23 21:37:02 5lNumVZr
最近知って、自慢したくて仕方なかったのでしょうw
使いどころ違うしw
375:名前は開発中のものです。
07/05/24 00:12:03 sQQ2EGyG
>>368
> 物体ごとに、Zソートしてたら遅くなる！
今ならZバッファ使えばいいじゃん。PlayStation じゃないんだし。
376:名前は開発中のものです。
07/05/24 00:19:50 4PByfCCv
>>375
画像処理のことなのか?
まぁ、半透明使うならZソートしといたほうがいいけど
>>368はハッシュとかツリーとか勉強するといいかも
377:名前は開発中のものです。
07/05/24 14:14:16 MN3OTeQA
>>375
3Dのシーンならそれでいいんですけど、
2D主体で、アルファ付きテクスチャ描画が標準、
アルファブレンドを使うのが当たり前、加算合成などが多めになると、
Zバッファが使えなくないですか？
俺、もしかしたら、基本的なところで、ミスってる？('A`)
>>373
毎フレーム、オブジェクトを数千個ソートするのもそんなには重くはないですけどね。
>>374
実は、昔から(DirectDrawの時代)から使ってるんですが、
使いどころ間違ってるのあｋ－－－－－マジ教えてくれ
>>376
そうです。半透明が多めなんです。
Hashとかﾂﾘｰは普通に使います。OTの実装もHashと同じですし
378:名前は開発中のものです。
07/05/24 15:21:37 4PByfCCv
hashとかわかってるならなんでそんなことをココに書き込むのだと小一時間問い詰めたい
379:名前は開発中のものです。
07/05/24 15:43:03 a3uG9+mx
・２D主体かつαブレンドを多用
・z値が整数で適当な範囲に収まる場合
ならその方法がいいのかもね
でもゲームによってやり方を変えるのが一番賢いだろうね
380:名前は開発中のものです。
07/05/24 16:17:32 aFaY4/D0
>378
最初にネタふりって書いてあるやん
381:名前は開発中のものです。
07/05/24 16:34:16 uojugi7P
っていうか、2Dのスプライトの場合はZオーダーなんてそう頻繁に
入れ替わるものではないから、前フレームのソート結果を上手く利用すれば、
もっと軽くできると思う。
382:名前は開発中のものです。
07/05/24 16:58:41 FtXKITOW
このスレの90％はネタを振る人間とそれにケチをつける人間でできています
383:名前は開発中のものです。
07/05/24 20:02:03 K0O2WDIn
>>382
残りの10%は？
384:名前は開発中のものです。
07/05/24 20:07:39 KUhBCX3E
ROM
385:名前は開発中のものです。
07/06/04 17:52:58 wXEt1jZx
ROMはいくらいても0%だろう
386:名前は開発中のものです。
07/06/12 16:35:34 KXWIMOSu
同人の俺は気にするほどのゲーム作らないからなー。
後から基数ソートやらに書き換えるつもりでSTLのsortでZソートしたけど
どこにも問題ないのでそのままリリースしたよ。めっちゃ富豪的
387:名前は開発中のものです。
07/06/12 20:19:56 mHZMnLTI
>>386
PS2 でも、そんなもんでした。STLport にお任せ。
388:名前は開発中のものです。
07/06/18 14:54:09 oOcxT9uX
コールバックってどういうときに使うんですか？
タスクシステム(というかハンドラオブジェクト)を使う時の場合において適当な例を教えてください
389:名前は開発中のものです。
07/06/18 15:00:56 2wNoPL2v
コールバックする時。
タスクシステムに限らず、メモリの解放を行ってもらうときとか、
進展情報を表示する時によく使うなあ。
とくに前者の場合は、他の開発環境で作ったDLL内でメモリを解放したいときとか。
390:名前は開発中のものです。
07/06/18 16:26:41 1gQkyo9F
>>388
オブザーバーパターンは便利だよ。
たとえば敵を倒したときにそいつのはいた弾をすべて消すとか、誘導弾のつけなおしとか
なれてくるとほとんどこれだけでイベントベースでコードが出来上がる。
391:名前は開発中のものです。
07/06/18 20:21:44 nIlBSYV8
タイミングが判明する場所と、そのとき行いたい処理との間の結合を
疎にしたいとき使います。
ほとんどこれだけでとか関係なし。必要なところへ必要なだけ使うべし。
392:名前は開発中のものです。
07/06/19 02:59:21 cFac+yZB
>>388
C時代のコードを利用するとき。
C++使えるんならほとんどのコールバックが仮想関数で見た目上は消せるだろう。
つまり仮想関数をCで使いたいときにコールバックが出てくる。
393:名前は開発中のものです。
07/06/19 05:07:59 AmvqVn7S
>>392
あとは、スクリプト言語との連携とか。
394:名前は開発中のものです。
07/06/22 08:30:52 njuyTnq1
Xboxのアレは禁断のボゴソートを使ったとしか思えない
395:名前は開発中のものです。
07/06/22 15:30:47 G4eFb+Vh
>>395
Xboxのアレって何ですか？
396:名前は開発中のものです。
07/06/22 17:18:36 vqNTOWGn
カルドセプトサーガの事じゃないの？
397:名前は開発中のものです。
07/06/22 20:36:17 OntiNUWq
そのタイトル名でググってみたが、これは酷いなw
サイコロが奇数と偶数が交互に出るとかw
398:名前は開発中のものです。
07/06/22 22:02:44 qN22ntrp
>>394
ボゴソートって知らなかった。
URLﾘﾝｸ(ja.wikipedia.org)
これはひどいあるごりずむ
399:名前は開発中のものです。
07/06/22 22:21:08 VTeo1nmT
>>398
これ逆にコーディングの手間がかかるだろｗ
400:名前は開発中のものです。
07/06/22 22:22:42 +XVLd04M
＞ボゴソートは、ソートのアルゴリズムの一つ。
＞平均的な計算時間はO(n×n!)で、非常に効率の悪いアルゴリズムとして知られている。
＞安定ソートではない。
最後の一行のオチで吹いたｗ
401:名前は開発中のものです。
07/06/22 22:28:33 0YS4QSdj
ここでボゴソートを使ったゲームを考えるのがゲームプログラマの努・・・ごめん無理
402:名前は開発中のものです。
07/06/23 00:06:58 WPiear32
ボゴソートﾜﾛﾀｗ
403:名前は開発中のものです。
07/06/24 05:25:19 zQnoyhbz
ﾜﾗﾀ
ソートつーか、バラバラに並び変えるアルゴリズムかとｗ
404:名前は開発中のものです。
07/06/24 11:16:29 1MtSzEPe
>>400
安定ソートの意味知ってるのかよ('ω`)
405:名前は開発中のものです。
07/06/24 11:33:03 NLW3QANP
>>404
安定ソートの意味知ってるのかよ('ω`)
406:名前は開発中のものです。
07/06/24 11:35:30 rfvCjIOU
>>404-405
知らないよ！（ﾟДﾟ）
407:名前は開発中のものです。
07/06/24 11:54:44 nOj+/xcZ
>>404-405
知らないよ！（ﾟДﾟ）
408:名前は開発中のものです。
07/06/25 03:07:29 qVqBESx6
えーっと、同じ順位のアイテム同士はソート前の順番を保つ、であってる？
409:名前は開発中のものです。
07/06/25 09:30:06 mc9m8oVn
あってる。
この記事のオチはInfinite monkey theoremだよ。ググレ、笑うから。
410:名前は開発中のものです。
07/06/25 10:06:14 U5o2CqSM
セットで RFC2795 もどーぞ。
URLﾘﾝｸ(www.ietf.org)
411:名前は開発中のものです。
07/06/25 20:59:14 NaYhg1aV
>>394-410
スレ違い
412:名前は開発中のものです。
07/06/25 21:35:29 933SMbqm
>>411
既存のゲームにおけるパターンの一端って事で
413:名前は開発中のものです。
07/07/17 22:54:23 Mh0Ht4Or
このスレ生きてますか？
基本的？なデータの扱いについて意見を聞きたいです
データに対応する操作クラス以外から値を書き換えることを禁止するためにこういうクラスを考えました
template <typename T> class IData {
public:
friend class Mutator<T>;
typedef T element_type;
typedef boost::shared_ptr< element_type > value_type;
protected:
value_type value;
};
template <typename T> class IMutator : public IData<T> {
typedef IData<T> data_type;
protected:
void assign(data_type& target) { value = target.value; }
void swap(data_type& target) { boost::swap(value, target.value); }
};
使う際はこいつを継承して
class CData : public IData<int> {};
class CMutator : public IMutator<int> {};
のようにすれば
CMutatorはIMutatorのassignやswapを使ってCDataのvalueの指すデータを生成から破壊まで自由に扱えるわけです
でもこのようにするとCDataの持つ情報が増えた時に
class CData : public IData<Param>, IData<Graphic>, IData<Sound>のように
継承しまくりになることとか、shared_ptrの機能によるコストが気になったりします
そこでもっと一般的なやり方を知りたいんですが何か良い方法ありませんかね？
414:名前は開発中のものです。
07/07/17 23:05:36 oI0Vf9iA
template <typename T> class IData {
public:
boost::shared_ptr<T> value; //!< 漏れ以外勝手に書き換えんなよ！
};
415:名前は開発中のものです。
07/07/17 23:19:26 Mh0Ht4Or
いくら防衛策を巡らせても書く人の意思でいくらでも変えられるから
そんな事考えるのは無駄だよってことですか
言われてみればそういう気もしますが…(´・ω・`)
416:名前は開発中のものです。
07/07/17 23:29:43 9lPCzUGd
多重継承にパフォーマンス(速度・容量の両面で)上の弊害は無いが
役割が酷似した基底(インターフェース)同士を多重継承って嫌過ぎだろ。常考。
衝突避けるためにインターフェース設計の段階でお互い調整しなくちゃいかんし
衝突上等ならキャストだらけの汚ねぇコードになる。俺ならコンポジットにする
417:名前は開発中のものです。
07/07/17 23:32:47 ecw8MgBR
いまいち要求が飲みこめんけど、委譲とかプロキシパターンとか
アダプタパターンとか、ありもののパターンで十分間に合いそうな希ガス。
経験上、複雑な仕組みはロクなことがない。
Keep it simple stupidですよ。
苦労して得られる利益が少なくて割が合わないパターンでは？
418:名前は開発中のものです。
07/07/18 00:07:21 xDBgIMCC
どうも
よく考えたらIDataはインターフェースじゃないっすね…
全く異なる型を同士でコンポジットにしてアクセスも上手く制限できる事って出来るんでしょうか
要求としては
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
です
操作されるデータの実体へのポインタを持つIDataと、それを扱うインターフェースIMutatorに分けたのは一番目のため
多重継承したCData経由でデータを扱うのは2番目を実現するため
データの実体へのポインタであるIDataのvalueメンバをprotectedにし
Mutatorをフレンドにしたのは三番目の為
以上によってゲーム内でのオブジェクトの振舞いは全てIMutator派生クラスのCDataに対しての操作として
書くことが出来て、リソースの確保等のシステム的な動作は外部に一任できる
という意図があったんですが、そんなに複雑ですかいね？
419:名前は開発中のものです。
07/07/18 00:28:49 JHo6PQLB
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
つまりテンプレートで実装する意味はないよね？
420:名前は開発中のものです。
07/07/18 00:37:53 9FpPIZ4u
>>419
ないね
421:名前は開発中のものです。
07/07/18 00:57:12 IHWjkDA2
> ・書き込み専用のクラス以外からのアクセスを制限する事
IMutatorを継承すればどんなクラス以外からでもアクセスできる以上、
制限できてるとは言いがたい。
「IMutatorの継承を無闇にするな」と、文書で説明する？
ならば、414でいいでしょ。
422:名前は開発中のものです。
07/07/18 02:48:50 vN51PGaN
>>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
「データ」と「ゲーム上のオブジェクト」の違いがよくわかりません。
「動作を～に対して書ける」ってのもよくわかりません。
「～を引数とする関数を書くことができる」ってことでしょうか？
423:名前は開発中のものです。
07/07/18 05:52:53 1k3Xg7ZP
なんか奇想天外なことになってるのは
＞・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ
424:名前は開発中のものです。
07/07/18 18:10:13 sTmzL7Mk
class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};
こうすると、CData::valueの型は何になるの？
425:413
07/07/18 19:28:34 xDBgIMCC
>>419,>>420
>つまりテンプレートで実装する意味は無いよね
恐らく既存の構造体を利用するためにこうした筈なんですが
普通にそれらをCDataにスマポで持たせた方がいいじゃんじゃんな気もしてきました
>>421
おっしゃるとおりです
細かいところにとらわれて本質を見失うという悪い例を晒してしまいました…
>>422
>「～を引数とする関数を書くことができる」ってことでしょうか？
そうです
キャラクタの移動や描画の際は、リソースのハンドラを移動クラスや描画クラスに渡すんでなく
CDataを渡すような形で書きたいわけです
>>423
なんかキャラクタのクラスに座標構造体と移動メソッドを定義してたソースを友人に見せると
値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
何か思い違いをしてますか…と問うまでもなく明らかにしてますね
>>424
晒したコードでは見事に多重定義のエラーになりました
実際はそれ避けたり多重定義されたIDataのvalueを内部で扱うためにboost::mplとか使って
さらに複雑な事やってるんですが>>417氏の言ってる事に繋がりますね
とりあえず苦労して作った車輪は最発明どころかガラクタですらないナニカだったというオチでした
もっかい一から作り直してみますm(＿ ＿)m
426:名前は開発中のものです。
07/07/18 20:55:21 ux1Fssbs
>>425
> 値を保持するクラスと操作するクラスは分けろこのスカポンタン
インターフェースと実装を分離するのは一般論としては間違いじゃないが、粒度が違う。
メンバ変数単位ではなく、意味のあるメンバ変数のセットをインターフェースにしろって
意味だと思うよ。
// 衝突判定後に、消灯判定マネージャから衝突回避のために位置をずらされる
struct IMovable {
// 現在位置
virtual void getPosCur(VECTOR3* p) const = 0;
// 移動したい位置
virtual void getPosNext(VECTOR3* p) const = 0;
// 衝突しないようにマネージャがずらした位置
virtual void setPos(VECTOR3 const& v) = 0;
};
class Player : public IMovable { ... };
class CollisionManager { /* こいつは IMovable だけ使用 */ };
こういう話かと。
427:名前は開発中のものです。
07/07/18 20:55:52 ux1Fssbs
>>426
s/メンバ変数のセット/メンバ関数のセット/g
428:名前は開発中のものです。
07/07/18 23:49:47 1k3Xg7ZP
>>425
＞値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの？
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ？
429:名前は開発中のものです。
07/07/19 00:19:41 RaZNmmmq
> 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
つかこれ自体間違いだろ。
430:名前は開発中のものです。
07/07/19 00:38:54 PDuVn1ka
>>429
だよな多分
431:名前は開発中のものです。
07/07/19 05:21:01 5YEt12VO
getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか（C++ならfriend？）
それ以上ってコストかかりすぎねえ？
432:名前は開発中のものです。
07/07/19 11:40:10 LxxDZCLh
少人数・小規模製作でアクセス制限も糞もないわな
433:名前は開発中のものです。
07/07/19 15:01:29 3ArgKadV
少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。
そういう場合は、アクセス権は考えといて損はねーですがよ。
434:名前は開発中のものです。
07/07/19 18:50:40 TacCeKvZ
アクセス権？になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない
435:名前は開発中のものです。
07/07/19 18:59:00 ajveBJeZ
とりあえず理由を
436:名前は開発中のものです。
07/07/19 19:27:00 3ArgKadV
なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ？
437:436
07/07/19 19:27:51 3ArgKadV
変な日本語になった
正しくは、
なんでファイルのパーミッションの話になってるんだ
>>433のアクセス権って、クラスのメンバーに対することで、
>>432のアクセス制限ってのもそのことだろ？
438:名前は開発中のものです。
07/07/19 19:39:53 /RFbeqQb
「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか＞ファイルシステムの例え話
個人管理のLinuxなんかだと、最初からrootでログインして使う人もいるくらいだから
それはそれで別に当人の自由だと思う。
要はアクセス権限を分ける方がトクか分けない方がトクかは
ケースバイケースで判断すればいいってことだけど
439:名前は開発中のものです。
07/07/19 20:12:33 TacCeKvZ
＞なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん
440:名前は開発中のものです。
07/07/20 12:39:13 vUDuhb3O
スレタイを百回声に出して読んでくれ
441:名前は開発中のものです。
07/07/20 12:40:51 vUDuhb3O
ついでに二人とも正座な
442:名前は開発中のものです。
07/07/20 21:52:02 +3gqdIHH
難しく考えすぎ。
他のオブジェクトにアクセスして欲しくないメンバは
クラスの中に隠蔽して、プライベートメンバにしておくのがセオリーでは。
アクセス権ってのは本来そうやってコントロールする。
外からオブジェクトにアクセスできるようにしておきながら
アクセスできないように制限する仕組みを作るってのがナンセンス。
443:名前は開発中のものです。
07/07/20 22:07:32 lyxTTGt6
「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難
444:名前は開発中のものです。
07/07/20 22:32:40 +3gqdIHH
動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。
445:名前は開発中のものです。
07/07/20 22:52:28 +3gqdIHH
本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。
例えばnoncopyableはオブジェクトのコピーを禁止するクラス。
こんなレベルのものでも有用さが認められればboostに仲間入りできる。
URLﾘﾝｸ(www.kmonos.net)
でも今現在boostにアクセス権制御のクラスがないってことは、
需要がないってことでは？
まずはプライベートメンバを使ったシンプルな隠蔽によるアクセス制御で
どこまでできるのか突き詰めてみた方がいいでしょ。
今のところ自分はそれで困ったことはないけどね…。
446:名前は開発中のものです。
07/07/21 00:49:20 DMrsrXyJ
ナンセンス。この一語に尽きる。
447:名前は開発中のものです。
07/07/21 01:16:04 oWQ5iQEX
progress_displayがあるのにそんなこと言われても説得力無いなぁ
動的にアクセス権決めるならgetter,setterを隠蔽してfunction使ってアクセス権を与えたいクラスに
そのgetter,setterを与えてやるって方法もあるけど
functionは1個で40bytes近く食う割と重たい(？)オブジェクトだから無茶かな、無茶だな
448:名前は開発中のものです。
07/07/21 03:00:31 DMrsrXyJ
動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ？RMIとかそーいった話の流れ方向での
静的だと外側の構造も知らん一クラスごときが誰に使われるのが良いだ悪いだ
決めるとか何いい気になってんだって話だ
>>443
＞静的に操作するのは困難
困難どうこうより、そのポリシーを決める根拠をどこにも求められないということだよ
適当に決めてしまえば後で直せなくなる
根拠がどこにもないから