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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 05/09 10:01 / Filesize : 187 KB / Number-of Response : 657
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：名前は開発中のものです。 [2006/08/10(木) 20:27:06 ID:BnvyxuCB]: 具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
2 名前：名前は開発中のものです。 [2006/08/10(木) 20:45:47 ID:X/dQa2Wp]: はっ、意味不明
3 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 20:46:24 ID:8+CwRGdy]: 設定提案とヲチと批判しかできないこの過疎板で
技術を語れるかが見物だ。
4 名前：名前は開発中のものです。 [2006/08/10(木) 22:23:22 ID:BnvyxuCB]: 抽象的過ぎたからひとまずお題を挙げておくか。
⊃「パックマン」

敵に関しては、敵の抽象クラスを継承したサブクラスで
移動アルゴリズムをオーバーライドするよりも、
アルゴリズムを別のクラスで用意して
それに対する参照を敵のクラスに持たせる方がいいのかな？
5 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 23:26:41 ID:BnvyxuCB]: +-----------------------+
| CEnemy |
+-----------------------+
| move() |
| (strategy->execute()) |
+-----------<>----------+
| strategy
|
|
+-----V-----+
| Strategy |
+-----------+
| execute() |
+-----A-----+
|
+------+---------+----------+
| |
+------+-------+ +------+------+
|AkabeeStrategy| |PinkyStrategy|
+--------------+ +-------------+
| execute() | | execute() |
+--------------+ +-------------+

クラス図で書くとこうなるのか？まあ絶対ズレているだろうがな…。
俺自身は超初心者だから間違いがあったら指摘お願い。
6 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 23:27:33 ID:BnvyxuCB]: ちょｗ
いくらなんでもズレすぎだ…。
7 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 23:29:52 ID:GhkTPLBd]: パックマンごときに大げさなパターンはいらねべ。
敵キャラの個別化をしたければテンプレートメソッドパターンぐらいで十分。
好きにすればよい。
8 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 23:38:42 ID:BnvyxuCB]: >>7
確かにその通りなんだが、
まあいきなり大規模なものを持ってきても
話しづらいかなと思って。
9 名前：名前は開発中のものです。 mailto:sage [2006/08/10(木) 23:39:13 ID:BnvyxuCB]: 一応>>5のズレ直しverを貼っておこう…。

　+-----------------------+
　|　　　　　　CEnemy　　　　　　|
　+-----------------------+
　|　　　　　　move()　　　　　　　|
　|　　(strategy->execute())　　|
　+-----------<>----------+
　　　　　　　　　　|　strategy
　　　　　　　　　　|
　　　　　　　　　　|
　　　　　+-----V-----+
　　　　　|　　Strategy　 |
　　　　　+-----------+
　　　　　|　　execute()　|
　　　　　+-----A-----+
　　　　　　　　　　|
　　　　　+------+------------+----------+
　　　　　|　　　　　　　　　　　　　　|
+------+-------+　　　+------+------+
| AkabeeStrategy |　　　|　PinkyStrategy |
+--------------+　　　+-------------+
|　　execute()　　　|　　　|　　execute()　　 |
+--------------+　　　+-------------+
10 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 00:00:57 ID:YoP5XUOs]: シューティングゲームの敵と敵から打たれるミサイルなんかは、
ファクトリメソッドパターンかな・・・
11 名前：名前は開発中のものです。 [2006/08/11(金) 00:24:48 ID:C/hX80Tz]: ｢こういうキャラに対しては何ちゃらパターンが使えるな｣
みたいなことは大体わかるのだが、
全体をまとめようとするとうまくいかないのはオレだけか？
12 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 00:39:49 ID:jjyZUyYu]: 同じ方向に話を進めるためには
タスクシステムの内容を統一した方がいいんじゃね??
13 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 01:37:19 ID:tpCf6gfL]: ttp://www.gamedesignpatterns.org/
14 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 05:13:38 ID:XHr3GWC7]: 名スレの予感
15 名前：名前は開発中のものです。 [2006/08/11(金) 07:46:49 ID:8h85L6qq]: >>9
CEnemyのCって何？
16 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 07:51:46 ID:sJYQdfLa]: ClassのCじゃねぇの。
17 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 08:14:44 ID:pd/2z5bI]: MFCを知らんのか？
18 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 08:22:18 ID:sJYQdfLa]: うん、普通に知らない。
19 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 10:46:52 ID:fe4sLs9R]: charだけあれば他は要らない
20 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 11:46:44 ID:YxjqBpJS]: Cつけるのはダサいからやめろ。
21 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 13:15:07 ID:NMgVyy7Y]: じゃあ、なにつければいいのさ？
22 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 13:16:16 ID:defJrMH6]: そのクラスを直感的に理解できるよう努力すれば他に何もいらない
23 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 13:32:51 ID:DmUndduC]: Cつけるの癖になってるなぁ。
24 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 14:04:44 ID:XHr3GWC7]: コードスタイルはクラス設計とは関係ないだろ
Ｃの１文字ぐらい脳内削除できんのかね
25 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 15:22:03 ID:AWZ202Sp]: 大文字で始まる名詞はクラス以外ありえないから、無意味に邪魔なゴミつけるんじゃないよ。
今出回ってる雑誌や書籍、それにオープンソースのコードに
Cつけてるものがどれほどあるか見てみろ。
MSなんか、C#では逆にCを「つけるな」と言ってるしな。

＞コードスタイルはクラス設計とは関係ないだろ

わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
普通にコードを書く気が最初からないんだから。
26 名前：名前は開発中のものです。 [2006/08/11(金) 15:37:25 ID:mPv7ZiBt]: >>25
コードスタイルについてはごもっともだけど、
＞わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
って誰が言ってたのさ。統計とったの？
そうですか、あなたの経験上ですか。では、変なクラス設計の基準はどこに？
27 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 15:56:24 ID:XHr3GWC7]: >>25
お前の言っていることは間違いではないが、焦点がズレているな
俺が言いたかったことは、>>9の敵クラス名がCEnemyだろうがEnemyだろうが
クラス図には何の影響もないということだ
変なスタイルを使う奴は云々という決め付けはいらない
設計がそこに転がっているんだからその優劣を語ればよい
28 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 16:01:15 ID:DmUndduC]: >>25
何でそんなに興奮してるんだ？
コードスタイルは分かりやすさ、第一。
別にコード公開する気もないし。
29 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 16:32:11 ID:C/hX80Tz]: >>7
Template Methodパターンだと、実行時に移動アルゴリズムを
変更したくなったときに面倒じゃないか?
パックマンがパワー餌を食べたことがMediatorを通して
通知されたとき、strategyを逃げるアルゴリズムに
変更すれば、同じ呼出しで適切な移動が可能。
まあ、オリジナルだと逃げるアルゴリズムは共通だから
それは組み込んでおいて通常移動はオーバーライドでも
問題ないけど、通常移動も動的に変更したいのならStrategyかな。

実際問題、パックマンを作るのにここまで慎重に設計する必要は
ないが、設計スレだし色々探ってみるのがよさそうだ。
30 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 18:51:41 ID:Vuvb9Lvy]: >>11
俺もその辺はよく悩むな。
最近はゲーム全体の構造について再度考え直そうと思って、
ttp://www.jeffplummer.com/Writings/Thesis/Thesis_with_Appendix.pdf
このあたりを読んで研究中。
GDC'06のTim Sweeneyの講演（Building a Flexible Game Engine）のスライド早く公開されないもんかな。
31 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 20:08:38 ID:Ip8C/yOX]: >>30
GDCのじゃないけどTim Sweeneyの別の場所での講演
スライド。参考までに。
ttp://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

時間表現からレンダリング、シミュレーションの並列実行化という
レベルの全体構造を考えるならGDC06のSim, Render, Repeat
? An Analysis of Game Loop Architecturesおすすめ。
32 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 21:10:41 ID:C/hX80Tz]: >>30-31
SUGEEEEEEE!!!
英語苦手だけど頑張って読んでみるか。
33 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 21:44:28 ID:Vuvb9Lvy]: >>31
おぉ、ﾄﾝｸｽ。参考になりまつ。
やっぱり並列化も次世代機を考慮すると重要なトピックになりつつあるんだなぁ…
34 名前：名前は開発中のものです。 mailto:sage [2006/08/11(金) 21:54:05 ID:Ip8C/yOX]: シングルコアを使い切る→マルチスレッド
マルチコアを使い切る→並列同時実行
35 名前：名前は開発中のものです。 mailto:sage [2006/08/12(土) 00:11:13 ID:Eayw3C5n]: お前ら！TCBを格納するのに何使ってる？
STLのlist使ってたんだけど、
動的メモリ確保で遅くなるから配列を使った方がいいと聞いて…。
それから単方向ではなく双方向リスト構造にする利点があれば教えてくれ。
36 名前：名前は開発中のものです。 mailto:sage [2006/08/12(土) 02:27:39 ID:pnW+o/wl]: やだ
37 名前：名前は開発中のものです。 mailto:sage [2006/08/12(土) 02:41:00 ID:Xdt1RmGF]: >>29
>Template Methodパターンだと、実行時に移動アルゴリズムを
>変更したくなったときに面倒じゃないか?
フラグのOF/OFFの分岐でいいべ。パックマン程度だったらその方がずっとコード
が分かりやすい。移動パターンが何種類もあると言うんだったら別だが。
38 名前：名前は開発中のものです。 mailto:sage [2006/08/13(日) 01:11:05 ID:o/UAG1nJ]: ゲームプログラムでMediator使うの微妙じゃね？
オブジェクト同士が相互作用しまくりで
処理内容が多岐にわたるゲームの場合、
updateしたよあとよろしくね♪じゃMadiatorの仕事が多すぎる。

結局俺の場合、例えばシューティングで当たり判定をとるんだったら
自機インスタンスへのポインタを敵のクラスのメンバに持たせたり
自機インスタンスをグローバルにしちゃったりする。
よくないことはわかりつつも。何か良い方法はないものかね。
39 名前：38 [2006/08/13(日) 02:36:16 ID:o/UAG1nJ]: ん？もしかしたら俺は物凄く馬鹿な勘違いをしていたのかもしれん。
今までは、Mediatorクラスが持つ関数は
呼び出し側の参照を引数として取るupdateただひとつだけで、
updateは引数から得られる情報を元に適切な処理を選択し、
適切なオブジェクトに通知するのだと思っていた。が、
Mediatorに複数の関数を持たせて
呼び出す側が選択するというのもありなんだな。
例えば当たり判定処理のためのhitCheckとか。

タスクリストを持つクラスにMediatorを兼任させるのもありか。
ごちゃごちゃするが。

>>35
listのままでおｋ
40 名前：名前は開発中のものです。 mailto:sage [2006/08/13(日) 08:56:01 ID:y5vatLvS]: この板ですごい久しぶりの良スレ候補だ。
41 名前：名前は開発中のものです。 mailto:sage [2006/08/13(日) 11:24:21 ID:vE5CRkDF]: >>38
まぁゲームシステムにもよるだろうなぁ。自機が一機しかなければ
自機クラスにMediatorの仕事やらせてもまず大差ないだろうし。
弾のような飛び道具出すにしても、
自機の敵キャラクタのインスタンス配列をそのまま渡せば
そこまで複雑になるとも思えない。むしろこっちの方が楽そう。
マリオみたいに敵同士の当たり判定がある場合は、
Mediatorみたいなものは必須だと思うけど。
42 名前：名前は開発中のものです。 [2006/08/15(火) 01:28:43 ID:mFMpUmTh]: デザパタ話か…
昔、GraphicsクラスやらInputクラスやらを
シングルトンにしようとしたが、初期化するための引数が多いせいで
Graphics.getInstance()なんて簡潔な呼び出しをすることが
不可能だと気づいて泣いたぜ
43 名前：名前は開発中のものです。 mailto:sage [2006/08/15(火) 01:53:25 ID:EK48DUhB]: >>42
initializeメンバ関数を別途用意して最初の方で呼び出せばいいだけの話じゃ？
44 名前：名前は開発中のものです。 mailto:sage [2006/08/15(火) 02:22:10 ID:mFMpUmTh]: >>43
それやるくらいなら俺はシングルトンパターンを適用せずに
フィールドを全部staticにする
初回のgetInstance()呼び出しでコッソリ初期化、
表面上は初期化いらずな点がシングルトンの利点だと勝手に思っているから
45 名前：名前は開発中のものです。 mailto:sage [2006/08/15(火) 03:30:20 ID:EPdRstT4]: Monostateパターンか
46 名前：名前は開発中のものです。 mailto:sage [2006/08/16(水) 12:54:24 ID:kC6PmX5a]: Mediator処理関数の呼び出すべき順番が決まっているのに
呼び出し側のタスクがその順番で並んでいないときは発狂する。
47 名前：名前は開発中のものです。 [2006/08/19(土) 01:00:05 ID:aLDfzS42]: Mediatorを適用しているサンプルを見たことがない。
プレイヤーへのポインタを保持する敵タスク(リスト)ばかりだ。
ttp://d.hatena.ne.jp/kenmo/20051215#p1にMediatorの解説があるが
接触判定のような単純な通信にしか使えんな。これは。
48 名前：名前は開発中のものです。 [2006/08/19(土) 10:25:32 ID:IzB67zRr]: このスレでよく出てくるタスクって何の事？
49 名前：名前は開発中のものです。 [2006/08/19(土) 10:59:20 ID:Br4d5o3I]: >>48
タスクシステムでググると出てくる。GameDevPukiWikiにも載っている。
gamdev.org/w/?%5B%5B%A5%BF%A5%B9%A5%AF%A5%B7%A5%B9%A5%C6%A5%E0%5D%5D
50 名前：名前は開発中のものです。 mailto:sage [2006/08/19(土) 12:03:47 ID:Ozyz6ud5]: タスクシステムの考え方は海外ではあまり見ない和製概念だね
向こうではDDAやらエンジン単位でのアーキテクチャが主流なのかな
51 名前：名前は開発中のものです。 [2006/08/19(土) 12:16:19 ID:IzB67zRr]: タスクシステムって要はリストの事なの？
52 名前：名前は開発中のものです。 mailto:sage [2006/08/19(土) 13:19:26 ID:Br4d5o3I]: タスクコントロールブロックがリスト構造を成しているとは限らない。
53 名前：名前は開発中のものです。 mailto:sage [2006/08/19(土) 14:40:17 ID:NMv1rX3b]: オレはCompositeパターンを使ってTCBをTreeにしている。
こうすると走査が面倒ななるから、必要なTCBだけMediatorに登録。
54 名前：名前は開発中のものです。 mailto:sage [2006/08/23(水) 17:59:02 ID:i8zrNBaj]: シューティングゲームなどで、C++タスクシステムにおいて、
敵管理タスクが当たり判定や弾の狙い撃ちをするために、
自機タスクから座標などの情報を取得するにはどうすればいい？
55 名前：名前は開発中のものです。 mailto:sage [2006/08/23(水) 20:30:16 ID:M0hCP3PA]: 今北お！

モデルの実装は普通にやればいいと思うんだけれども、
たとえば >>9 のパックマンでキャラ画像情報とかって
どこに持つ？

で、アルゴリズムとどうやって結びつける？

俺はなんかもう面倒くさくなって全部一緒になってんだよねー(最悪)
56 名前：名前は開発中のものです。 mailto:sage [2006/08/23(水) 20:32:29 ID:M0hCP3PA]: >>54
多分、自機情報がグローバルにあるんだと思うよ！
57 名前：名前は開発中のものです。 [2006/08/23(水) 20:55:16 ID:Y+7SXF19]: パックマンクラスかな
58 名前：名前は開発中のものです。 mailto:sage [2006/08/23(水) 21:23:13 ID:PRMjREAH]: つか、誰か>>50の解説を頼む。
59 名前：名前は開発中のものです。 mailto:sage [2006/08/23(水) 21:28:31 ID:3o00L+nM]: >>55
画像情報がビットマップなんかのことだったら殆ど別だな。
ゲーム総まとめクラスから
キャラの座標値、アニメーションインデックス値を吐かせて
それを画像クラスに投げてる。
60 名前：名前は開発中のものです。 mailto:sage [2006/08/24(木) 00:46:53 ID:YfRhQBsC]: 【敵機(Enemyクラス)が自機(Playerクラス)の座標の取得する場合】
(GetXY()となっているが、XとYを別々に取ってきても構わない)

・そもそもクラスにまとめていない or 自機も敵機もごちゃ混ぜクラス。
　自機の座標の取得には苦労しないよ派。
・Playerのインスタンスplayerがグローバル。
　player.GetXY()で座標を取ってくるよ派。
・PlayerがSingleton。
　Player::Instance().GetXY()で座標を取ってくるよ派。
・PlayerがMonoState。
　player.GetXY()もしくはPlayer::GetXY()で座標を取ってくるよ派。
・Enemyクラスがplayerへのポインタを保持。
　player->GetXY()で座標を取ってくるよ派。
・enemyがMadiatorに自機の座標の取得を要求。
　Madiatorがplayerの座標を調べて返してくれるよ派。
・playerやenemyが属する統括クラス(GameとかTaskListとか)に
　enemyがアクセス可能。
　Game.(->)GetPlayer()->GetXY()で座標を取ってくるよ派。
61 名前：名前は開発中のものです。 [2006/08/24(木) 20:19:35 ID:ioVHmuR2]: >>59
キャラの座標やアニメーションインデックス自体は、
やっぱり>>9でいうCEnemyにあるんだよねぇ？
それを総まとめクラスが集約してるみたいな構造かなぁ。

その設計だと、ダーティ領域を消すための前回のスプライト位置は
画像クラスに持ってるんだろうか？
62 名前：名前は開発中のものです。 [2006/08/25(金) 07:38:55 ID:hwdyVz4L]: アニメーションインデックスは
CEnemyのメンバとして直接持つのではなく、
委譲関係にあるインデックス管理クラスが持った方がいいかな。
インデックス管理クラスはmap<String, list<POINT> >みたいな構造にして、
動作の名前を与えるとPOINT構造体を返してくれるというような。
63 名前：名前は開発中のものです。 mailto:sage [2006/08/25(金) 11:50:36 ID:cXY4CALt]: >>61
総まとめクラスにインデックス値を吐かせてるのは
それがフレーム管理もやってるから。
インデックス値はCEnemyには持たしていない。
毎回背景から再描画してるんで、
前回スプライト位置は保持していない。メンドイし。
64 名前：名前は開発中のものです。 mailto:sage [2006/08/25(金) 14:31:51 ID:7Z0tsXKn]: >>63
>総まとめクラスにインデックス値を吐かせてるのは
>それがフレーム管理もやっているから
いやそれ全然理由になっていないと思うぞ…。
65 名前：63 mailto:sage [2006/08/25(金) 20:56:45 ID:cXY4CALt]: あれ？自分で書いておいて訳わかんねｗ
作ったまとめクラスよく見たらフレーム管理はしてなくて、
1フレーム進めるメソッドがあるだけだった。
んで、そのメソッドを実行するたびに
0～(アニメーション数-1)までくるくる回す
インデックス値のメンバがそこにあった。
数ヶ月前に書いたソースを思い浮かべながら書いたら
記憶があいまいで勘違いしてた。ｽﾏｿ
66 名前：名前は開発中のものです。 [2006/08/26(土) 02:58:51 ID:MLjkH/sO]: >>65
それをやると、敵を生成したタイミングにかかわらず
同じ敵が同じ状況で常に同じモーションをとることになるな(行進みたいに)。
俺はモーションをバラにさせたいときは>>62みたいなクラスを敵クラスに持たせ、
あえて統一したいときはそれを敵リストクラスに持たせている。
67 名前：名前は開発中のものです。 [2006/08/27(日) 01:28:02 ID:AkzK5166]: 簡単なことを難しくやる典型例みたいな…
やっぱしゲームには過度なオブジェクト指向は必要ないかなあ
68 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 01:36:32 ID:ksgBJOiI]: ３Dゲームはオブジェクト指向無しではやってられまへん。
69 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 01:58:03 ID:8IJYN4+M]: >>67
このスレに書かれているようなクラス設計を
どんな規模のゲームにでも毎回採用している奴はいないだろう。
採用した方がむしろ簡単になったり、差し替えが楽になったり
するようなところに適用すればいい。
パックマンとかシューティングとかは説明例に利用されているだけだし。
ゲームに過度なオブジェクト指向は必要ないというのはちと早計。
70 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 09:16:10 ID:6AN46lHX]
71 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 11:43:57 ID:1/1wdIdP]: こんなスレが出来てたのか。

いわゆるタスクシステム的な、個々のオブジェクト同士の依存関係の記述は、
ここの考え方と同じ方針でやってる。
ttp://www.issei.org/blog/archives/000225.html
72 名前：63 mailto:sage [2006/08/27(日) 12:10:26 ID:f+3tvpuV]: >>66
まぁ漏れの場合はそこまで凝ったシューティングじゃなかったし。
もっと拘ると最終的にそれに近くなってくるだろうなぁ。

>>67
難しいか？このくらいじゃ慣れの問題でしょ。
大規模なゲーム作るとなると設計をちゃんとしなければ
取り返しがつかなくなって訳若布になる。
それに、そこで作ったコードを再利用するなら
他のゲームも自動的にオブジェクト志向なコードになる。
73 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 13:24:46 ID:DcPmG1mi]: そこに時間という足かせとのバランスを考慮するんだろ
74 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 14:46:15 ID:Iv3Ktm5x]: 過度のオブジェクト指向はゲームじゃなくても要らないっしょ。
過度なんだから。

まぁ、でもパックマンに >>9 ぐらいの設計は全然アリだよね。
CEnemyを直接継承しちゃうかな。俺は。
75 名前：名前は開発中のものです。 [2006/08/27(日) 20:51:21 ID:e75LZdTl]: ゲーム固有のコード全てを持つクラスの名前ってどんな風に付けますか？

Game だと（他のタイトルのコードと）紛らわしいし、ゲームタイトルって選択もあるだろうけど
開発を始めたばかりの頃に気の訊いたタイトルを思いつけるとも限らないし・・・
参考までに聞かせてください
76 名前：名前は開発中のものです。 mailto:sage [2006/08/27(日) 20:59:17 ID:91MNPNDq]: ゲームのすべてのコードが含まれてるなら後で変更しても問題ないんじゃないの
77 名前：名前は開発中のものです。 mailto:sage [2006/08/28(月) 06:10:31 ID:ylt7gNTk]: たとえばJavaならeclipse様の力で名前なんかどうにでもできるんだが、
そういうツールがない場合、開発コード名をつける。
78 名前：名前は開発中のものです。 mailto:sage [2006/08/29(火) 08:01:09 ID:ewOrOlMJ]: >>75
namespaceで区切る。
79 名前：名前は開発中のものです。 [2006/08/30(水) 08:47:32 ID:nhdG+7sO]: 良スレだと思うのだがなかなか伸びないな。
やはりこの板は設計論より実装論が先立ってしまう人が多いからだろうか…
80 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 10:33:46 ID:/npQLrEC]: 単に内容について来られる奴が予想以上にいない説。
スクリプタやプログラム初心者が多いこの板では
このスレでメインに置かれているC++自体がまず敷居高し。
加えてタスクシステムやデザインパターン等の前提知識が必要だし、
ある程度作り慣れた人でないと語られている手法の有用性がわからない。
っていうか>>2が端的にこのスレの性格を表している気がしなくもない。
81 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 10:42:16 ID:ywEU+7yH]: イベント駆動型で作れないかな
82 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 11:31:13 ID:9Enygb8x]: パズルゲームとかなら
83 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 19:00:19 ID:/p+hSpd6]: むしろ糞スレ化せずに80以上のまともなレスがあるのが奇跡だよなぁ。
84 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 23:25:09 ID:YwiXGvRz]: 実装論先行型が多いと思う

デザインパターンって人に伝えるために作られたものだと思う
一人で作ってる分には必要ないんでない？

あとオブジェクト指向はホント必要、いやまじで、ないと軽く逝ける
どこまでやればオブジェクト指向ってのかは謎だけど

とりあえずデザインパターンとあまり関係ないんだが
クラスの作り方どうやってるか聞きたい
複雑な行動パターンをお手軽に実装できる方法とかない？
85 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 23:37:00 ID:zbf6UWXA]: C++で、クラス関連の機能から触り始め
テンプレートの書き方やSTLライブラリまで一通り勉強したけど
デザインパターンにはまだ触れたことがない
今のところ、機能ごとに切り分けたクラスを作りためながら
自前のゲーム用ライブラリを構築するだけで満足してしまってる
86 名前：名前は開発中のものです。 mailto:sage [2006/08/30(水) 23:42:43 ID:5F9omhv6]: どうでもいいことを突っ込まずにはいられない
>85
>STLライブラリ
頭痛が痛いです
87 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 00:11:24 ID:HS89R3Gm]: 知ってるがな
どうでもいいことには突っ込まずにいてください
88 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 00:17:43 ID:RTC9z+se]: プログラムを勉強し始めて間もなく
多くの人が感動したアルゴリズムと同じく、
綺麗なクラス設計を示したのがデザパタだ
みたいなことを誰か言ってたな。
89 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 00:47:27 ID:q0N5Gk6x]: 83が変なコトいうから微妙な空気が漂ってきた。
90 名前：名前は開発中のものです。 [2006/08/31(木) 03:24:35 ID:LuxRambo]: デザインパターンの意図については語る必要はない気がする。
こっちは利用する側なんだし。実際このスレではパターン名で疎通が取れているし
パターン自体も色々な使用例が挙げられていて役立っているからそれでいい。

>>84
＞複雑な行動パターンをお手軽に実装できる方法とかない？
なんとなく、このスレでは扱わない具体的な実装面に踏み込む内容な気がする。
どちらにしろ具体例を挙げてくれないと意見しにくい。
行動パターンがコロコロ変わるというのであれば>>9の方法でいいんじゃないか？
91 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 17:27:49 ID:AP7414ou]: こういうスレは、この板では貴重だと思う。
当たり判定のアルゴリズムはわかっても、
それぞれの物体の座標をどうやって取得するか等を語れるスレは少ないし。
92 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 18:34:51 ID:H1On9wAl]: >>90
前にＳＴＧ作った時に敵の数を２０以上作れと言われた
一つ一つ行動パターンを作っていくのがえらいめんどくさかった
既出ですまそ、そしてありがとうございます
93 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 19:32:51 ID:FYTUeEKw]: 「複雑な行動パターン」ってどういうもん？
キャラの状態が色々あってステートの変化の組み合わせが多い(格ゲー系にありがち)とか、
行動の流れが複雑でプログラムがめんどくさい(シューティングにありがち)とか、
カテゴリはいくらでもありそうだからなぁ

でも大抵はスクリプトを使えば割と面倒なタスク処理が解決すると思うので紹介
タスクを実装するのにvirtual Update() = 0;な関数を用意したクラスを使うのは皆よくやると思うのだが
キャラにとっては一連の流れ(＝関数)を一々タイムスライスしてやらなきゃならんのは面倒だ。
そこでスクリプトを使うと結構その辺が簡略化されるよ
例えばシューティングゲームで360度回転しながら弾を撃つ処理を書くときとかが良い例だと思うのだが

class Hoge
{
　float m_Angle = 0;
　Update() {
　　m_Angle += AngleVel;
　　Fire(m_Angle);
　　if( m_Angle >= 360.0f )
　　　Destroy( this );
　}
};
と書くよりは
HogeThread() {
　for( float Angle = 0; Angle < 360; Angle += AngleVel; ) {
　　Fire(m_Angle);
　　Wait(1);
　}
}
と書きたいわけだな。Wiat(1)みたいなのはスクリプトの得意技だ
>>9の例を使うと、class ScriptStrategyみたいな感じのクラスを作るのがいい感じ。
94 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 19:34:21 ID:FYTUeEKw]: それにしてもひどい文法エラーだと自分でつくづく思った。
95 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 21:15:01 ID:XOYGLdi+]: >>93
ゲームプログラムとしては前者のコードの方が自然だから
わざわざ後者にしたいという理由がわからない。
96 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 21:43:04 ID:WNbosGuA]: IEnumerator<IAction> GetAction()
{
　for( float Angle = 0; Angle < 360; Angle += AngleVel; ) {
　　yield return new FireAction(m_Angle);
　}
}

C#でこういうのどうだろ
97 名前：名前は開発中のものです。 mailto:sage [2006/08/31(木) 21:52:59 ID:q0N5Gk6x]: >>93の例は微妙に不適当な気がする。
”複雑な状態遷移をスクリプト（というよりこの場合fiber/coroutine）で処理した方が簡単”
というのは言えると思うが、
”毎フレームUpdateを呼ぶよりもHogeThreadを1回だけ起動する方法にしたい”
なんて思う人はごく稀だと思われる。

この場合、>>9のStrategyのサブクラスとしてScriptStrategyを定義して、
excuteが呼ばれるたびにコンテキストを復帰して起動する処理を作る方が自然。
98 名前：名前は開発中のものです。 mailto:sage [2006/09/01(金) 00:30:03 ID:r4ifVKGE]: >>95
そんなことは無いですよ。BulletMLはまさしく後者の方法の一種です。
わざわざこのためにpythonのマイクロスレッドを利用する人もいるくらい。

>>96
まさにその考え方です。
ただC#ではIteratorでしかyieldが使えないので…

>>97
なんか表現を誤った気がします。
結局はおっしゃるとおりコルーチンってことです。
99 名前：名前は開発中のものです。 [2006/09/01(金) 22:44:26 ID:gcVCkYdV]: 人それぞれといわれかねない質問だが・・・、
衝突判定は何処で行う？
キャラが他のキャラクタと当たるかどうかを各々チェックする？
衝突クラスなるものがキャラと他のキャラとをチェックする？
100 名前：名前は開発中のものです。 mailto:sage [2006/09/01(金) 23:18:48 ID:m70wFV1r]: 衝突判定の対象になるキャラを、障害物クラスに登録しておき、
キャラのメソッドで、判定用ベクトルを格納するクラスを生成し、
その判定ベクトルクラスを、障害物クラスに渡している。
障害物クラスで扱うデータは、
オリジナルだったり複数種のFVFだったりするので、
判定そのものはテンプレートにした。
101 名前：名前は開発中のものです。 mailto:sage [2006/09/01(金) 23:37:56 ID:PZ94qqHg]: 5000個くらいのキャラの衝突を総当りでやってたらうざったいもんな。
キャラの最小サイズを１ピクセルになるようにマップを縮小したものを容易。
キャラを移動させたらその位置を塗り替えるが、その場所が既に塗り替えられてれば衝突、もしくは
詳細の衝突判定を行う。
クラスにするまでもないと思うが。
102 名前：名前は開発中のものです。 mailto:sage [2006/09/01(金) 23:50:16 ID:KqJnfdNw]: 俺は衝突クラスを作るかな。
実装は>>101みたいな感じだけど4分木を使ってもっと大雑把にやる。
まあ実装に関してはこのスレの範囲外だけど。
103 名前：名前は開発中のものです。 mailto:sage [2006/09/02(土) 18:17:30 ID:NT+ChiaN]: 衝突判定でよく話題になるダブルディスパッチだけれども
boost::variant使うと継承無しで実現できちゃうよ。
中身はswitch caseのコンパイル時自動生成してるだけだけど。
継承関係なしで仮想関数の真似事もできるんで、
たまには役に立つかもしれない。
104 名前：名前は開発中のものです。 mailto:sage [2006/09/02(土) 18:26:27 ID:AcWLcw3K]: GameObjectは型クラスの概念に近いことが多いから、
ある程度規模が大きくなると、コンパイル時のダブルディスパッチの確定だけじゃ追いつかなくなるんだよね…
UnrealEngineではスクリプトに完全に委譲してしまってるみたいだけど。
105 名前：名前は開発中のものです。 mailto:sage [2006/09/02(土) 18:36:54 ID:NT+ChiaN]: variant型なんだからもちろん実行時型識別してくれるよ。
具体的には型にid振ってswitch caseしてるだけ。
メモリアロケーションも発生しないからなかなか優秀。
ただオブジェクトサイズが最大のものに揃っちゃうけど。
106 名前：名前は開発中のものです。 mailto:sage [2006/09/02(土) 18:40:42 ID:NT+ChiaN]: こんな感じね。↓

#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);
107 名前：名前は開発中のものです。 mailto:sage [2006/09/02(土) 21:49:46 ID:AcWLcw3K]: >>105
いや、突き詰めていくと、同じ型であってもゲーム上で異なる意味を持つ場合がよくあって、
そういう場合は（言語としての）型でのディスパッチだけでは不十分で、
結局、ゲームにあわせたIDなり名前なりで自前のルーチンを組むことになるって話。

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

って書いてて気づいたけど型クラスじゃなくて型オブジェクトだったよ(´･ω･`)ｽﾏｿ。
108 名前：名前は開発中のものです。 mailto:sage [2006/09/03(日) 02:35:53 ID:zkit7pB+]: それは単に振る舞いを型まで落としきれてないだけでは。
仮に振る舞いが外部設定可能だったとしても
型をパラメータ化したファクトリ作れば良いし。
109 名前：名前は開発中のものです。 mailto:sage [2006/09/03(日) 02:45:46 ID:zkit7pB+]: ああ、”ゲームオブジェクト”のディスパッチでは
足りない、ということであれば同意。
上のは当たり判定オブジェクトを別に作ってそっちで
ディスパッチする前提で話してた。
110 名前：名前は開発中のものです。 mailto:sage [2006/09/03(日) 20:53:10 ID:IzfZGbvV]: てかここまでくるとスレ違いじゃね？
111 名前：名前は開発中のものです。 mailto:sage [2006/09/03(日) 21:18:48 ID:2Y2SZ/cc]: >>110
何故？
112 名前：名前は開発中のものです。 mailto:sage [2006/09/03(日) 23:09:12 ID:H5xQl2Ix]: >>109
そう、そういう意味ですた。
パックマンやテトリスみたく、型とオブジェクトの振る舞いが１：１で対応するようなゲームであれば
boost::variantやLokiのStaticDispatcherで事足りるし、その方が高速なんだけど
ツールでカスタマイズ可能なオブジェクトを導入したとたんに破綻しちゃうんだよね…
普通はどうするもんなんでしょうか。
113 名前：名前は開発中のものです。 mailto:sage [2006/09/04(月) 00:35:37 ID:Q7Y7fGRp]: >>110
話題が無いよりマシ

>>112
>>108、>>109にも書いてあるけどStrategyパターン使ったら？
114 名前：名前は開発中のものです。 mailto:sage [2006/09/04(月) 22:45:10 ID:rb/d93oY]: 衝突は悩みますよねー。
まぁ、衝突判定のためのクラスを作って、そこに対象をごっそり
addしていくような感じですかね。わたしは。
115 名前：名前は開発中のものです。 mailto:sage [2006/09/04(月) 23:02:41 ID:IU7YOKU2]: 2Dの衝突判定の話と３Dの衝突判定の話が混在しているから困るｗ
116 名前：名前は開発中のものです。 mailto:sage [2006/09/04(月) 23:16:45 ID:FM5ShwwG]: 次元１つ違うだけジャン
117 名前：名前は開発中のものです。 mailto:sage [2006/09/04(月) 23:41:18 ID:sQ13V/oj]: 判定アルゴリズムを語っているわけではあるまいし、問題ないだろう。
118 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 00:52:09 ID:ZZN1keOu]: さすがに>>101のやり方は３Dじゃやらんだろｗｗ
119 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 01:15:43 ID:XCG3Ame9]: 画像だとめんどいけど多次元配列にすればいけるんじゃね？
120 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 01:32:48 ID:N2PWUf7J]: >>119
普通はAABBのツリー構造にするけどな
121 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 04:06:58 ID:9I8P67h+]: グリッドでやるのは現実的じゃないけど、オクツリーなら。
122 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 05:52:03 ID:b0Le55Md]: こういう話題も一応『データ構造』の内に入るのかな？
レンジ広めな良スレだな。
123 名前：名前は開発中のものです。 mailto:sage [2006/09/05(火) 07:11:57 ID:WVxlLvIu]: まとめ
・形状衝突判定とゲームオブジェクト衝突判定の話が混在してて紛らわしいお
・VisitorパターンはAcceptor側の個数が暴発するときには使いづらいお
・挙動をStrategy化すればAcceptorが暴発しにくくなるお
・次元を問わずグリッドよりツリーのほうがお勧めだお
124 名前：名前は開発中のものです。 mailto:sage [2006/09/08(金) 23:55:09 ID:NaDeRAxZ]: 群体を制御するプログラムのいい案ない？
複数の個体で整列したり陣形を作るっていうのが目標

どっちかというとＡＩの分野に入ると思うけど
そこまで複雑な物じゃなくてもいいかなと思ってる
125 名前：名前は開発中のものです。 mailto:sage [2006/09/09(土) 00:04:25 ID:htHhZzlR]: チーム全体の行動を担うダミーエージェントを用意して、
そいつが全エージェントの操作を行うというのが楽なんじゃね？
昔からある多間接キャラとかはこういうタイプなんだろか

個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
まさしくAIって感じだが果てしなく重くなりそう
126 名前：名前は開発中のものです。 mailto:sage [2006/09/09(土) 00:27:32 ID:8XOJrFUy]: >>125
> 個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
> まさしくAIって感じだが果てしなく重くなりそう
そうでもない。
今のクラウドシミュレーションの基礎になってるレイノルズの方法では
3つの単純な操作を各個体に適用するだけでリアルな挙動を作り出せる。

これに、基準になる目標点を個々に与えたり、パラメータを調節・追加することで整列や陣形も表現できる。
といっても完璧に意図した陣形にしたければ、予め動きを指定しておくしかないけど。
127 名前：名前は開発中のものです。 mailto:sage [2006/09/09(土) 03:06:35 ID:KrPaatUc]: boidっ言ってちょ。1行目だけ読んで「レイノルズって誰だ？」とか思っちゃった。
ツリー的な構造にしてセパレーション以外の適用範囲を限定したりすると、
複数の集団が扱えるし、（影響力の強くした）ツリーの親で操作できて手軽。
128 名前：124 mailto:sage [2006/09/09(土) 11:31:36 ID:c7q33UAv]: まとめると
チーム全体の指揮をするエージェントを作る
個々に単純な操作や状況判断する機能をつける
ツリー構造で処理する

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

>>125と>>126のやり方を組み合わせられれば理想的なプログラムになりそう
129 名前：名前は開発中のものです。 [2006/09/09(土) 13:29:03 ID:QcPvLvjH]: 階層ステートマシーンってどんなものか知ってる人いる？
130 名前：名前は開発中のものです。 mailto:sage [2006/09/10(日) 00:43:16 ID:20rok1qS]: >>129
従来のステートマシン（全てのステートが完全に等価）に
クラスなりパッケージ化で階層を加えて
オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな？
131 名前：名前は開発中のものです。 mailto:sage [2006/09/10(日) 06:09:51 ID:lBlbiG31]: >>128
リンク先の動きが魚っぽい。
132 名前：名前は開発中のものです。 mailto:sage [2006/09/13(水) 09:43:56 ID:NFAfFOse]: 魚に吹いたｗ
133 名前：名前は開発中のものです。 mailto:sage [2006/09/17(日) 13:13:30 ID:w8QCz84O]: 2chからリンクされていたから何かと思ったら、こういう話かｗ　一安心。

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

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

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

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

参考書
ttp://www.amazon.co.jp/exec/obidos/ASIN/1578201101
134 名前：名前は開発中のものです。 mailto:sage [2006/09/17(日) 13:24:01 ID:yvndUkUn]: strategyのstrategyみたいなもんか。
135 名前：名前は開発中のものです。 mailto:sage [2006/09/22(金) 22:18:45 ID:u76SSGNK]: 質問です。

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

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

言語はC++です。
136 名前：名前は開発中のものです。 mailto:sage [2006/09/22(金) 22:33:30 ID:zpdtl+m6]: >>135
boost 使うなら shared_ptr と weak_ptr 組み合わせて使う。

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

bool isTerminated() const;

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

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

みたいなチェックを入れる。私は intrusive_ptr 好き人間なので、後者で統一
してました。
137 名前：名前は開発中のものです。 mailto:sage [2006/09/23(土) 10:55:14 ID:gkZ8TjvK]: >>135
インスタンスのポインタのポインタ持たせておけばおｋ。
Aのインスタンス開放時は必ずぬるぽを指定する。
138 名前：名前は開発中のものです。 mailto:sage [2006/09/23(土) 14:31:03 ID:HUIkr9ZU]: >>136
weak_ptr使ってみました。これは良いですね。
セットされていたshared_ptrが消失すると以降のlock()が無効になる。
これで私の希望は叶ったように思います。
ただ・・これって内部ではどのような処理が行われているのでしょうか？
ソースを読んでみようかと思いましたが・・私にはちょっと難しかったです。
どなたか、簡単に解説していただけませんでしょうか？

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

>>137
Ｂがインスタンスのポインタのポインタを持つとして、
その「インスタンスのポインタ」にあたるデータは
Ａが持つのでしょうか？それとも違う者が持つ？または誰も所有しないのでしょうか？
ちょっと具体的なイメージが沸きませんでした。
宜しければサンプルコードみたいなものを書いて頂けるとありがたいです。
139 名前：名前は開発中のものです。 mailto:sage [2006/09/23(土) 15:44:06 ID: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 名前：名前は開発中のものです。 mailto:sage [2006/09/23(土) 20:21:11 ID: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 mailto:sage [2006/09/23(土) 20:22:09 ID: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 mailto:sage [2006/09/23(土) 20:22:57 ID:gkZ8TjvK]: 名前ミスった。気にせんでくれ。
143 名前：名前は開発中のものです。 mailto:sage [2006/09/25(月) 21:33:59 ID:hvNCBo59]: ここで挙げられたパターンや何やらを使っているような、
小規模でわかりやすいサンプルってありますかね？
シューティングを作ろうとしているのですが、設計で悩むことが多くて、
参考になるものが欲しくなってきたので、何かあればよろしくお願いします。
144 名前：名前は開発中のものです。 mailto:sage [2006/10/10(火) 21:23:54 ID:yCqIkWyw]: >>143
シューティング製作スレから．
ただし，漏れはまだ読んでないので内容については保証できんが．
ttp://ime.nu/www.amazon.co.jp/exec/obidos/ASIN/4797337214/
145 名前：名前は開発中のものです。 [2006/10/31(火) 10:38:39 ID:xPxE7qYC]
146 名前：名前は開発中のものです。 mailto:sage [2006/11/04(土) 23:26:00 ID:fX21zZRx]: タスクシステムって本当に有効なのか？
逆にプログラミングが煩雑になりそうな気がするんだが。
147 名前：名前は開発中のものです。 mailto:sage [2006/11/04(土) 23:30:01 ID:gABtDaTi]: >>146
何度か挙がってるネタだな。まず「タスクシステム」を定義しないと、
いつもどおりグダグダになるだろう。
148 名前：名前は開発中のものです。 mailto:sage [2006/11/04(土) 23:49:54 ID:fX21zZRx]: >>147
タスクシステムというのは、
処理関数とワークエリアがセットになったタスクがリスト構造になっていて、
順番にタスクの処理関数を実行していく仕組みだと思ってる。違うかもしれんが。
あるタスクが、ほかのタスクの保持するデータを参照するのが難しそうだ。
149 名前：名前は開発中のものです。 mailto:sage [2006/11/05(日) 01:52:09 ID:SWu+bHZ4]: >>148
関数とワークエリアがセットって言ったら仮想関数使えばいいだけの話。
あとは抽象クラスへのポインタをコンテナに保持すればできあがり。
システムって名付けるほどのもんでもないよな。

そこで済ませておけばいいものを、なんでもかんでもそのリストを
使ってやろうとすると、バグの温床となる「タスクシステム」ができあがるんじゃないか
と思っている。
150 名前：名前は開発中のものです。 mailto:sage [2006/11/05(日) 02:16:36 ID:luPotGyi]: 実際C++だと必要ないよ。
151 名前：名前は開発中のものです。 mailto:sage [2006/11/05(日) 09:28:27 ID:x/qHNT/o]: >150
そうでもない。組み込み方面からもたらされたと思われる非プリエンプティブな
スレッドみたいなもうちょっと複雑なものとするなら、C++のみでは無理、
アセンブラが必要。WindowsならCreateFiberを使えるが、NT系で
しか使えない。

これからマルチコアが当たり前になると、スレッドをタスクと名づける人が増える
かもね、おおややっこしい。
152 名前：名前は開発中のものです。 mailto:sage [2006/11/05(日) 09:43:30 ID:wi810l51]: >>151
147の発言を地でいってるな。
153 名前：名前は開発中のものです。 mailto:sage [2006/11/05(日) 14:05:29 ID:zA+hRC02]: >>151
そういう意味のタスクじゃなくて
154 名前：名前は開発中のものです。 mailto:sage [2006/11/07(火) 04:30:19 ID:grfbgSgu]: 初心者だがレスさせてくろ
タスクシステムはビデオ屋でいうポストレンタルシステムではないでしょうか
ゲームプログラムにおいてはリアルタイム戦略ゲームのＡＩに有効かと
例えば自立スレッド型のユニット(目的地を指定すれば、勝手に動いてくれる)をＡ地点に移動したのち、Ｂ地点に移動させるAIを組もうとしたときなど。
ユニットのスレッドが行動リストをもっていて、AIはぼんぼんリストに行動をaddしていけばいい
ユニットのスレッドはリストの下から行動を処理する。

このシステムがないとAIはユニットがＡ地点に到着した情報を取得し、
その後でＢ地点に池という命令を出さなければならないのでAIの手間が非常にかかる　　おやすみなさい
　　
155 名前：名前は開発中のものです。 mailto:sage [2006/11/07(火) 10:26:39 ID:vi/Nuttr]: >>154
それは >>148 の言うようなタスクシステムとは全然違う。
コマンドのキューと言えば十分。システムなんて呼ぶほどのものでもない。

「タスクシステム」の共通な定義が無いのが
一番の問題なのかもしれないと思った。
俺様解釈が多すぎていまさら定義も難しい。
156 名前：名前は開発中のものです。 [2006/11/07(火) 10:45:17 ID:FxrEUOug]: 少なくともこのスレでのタスクシステムの共通定義は
>>148でいいんじゃないの？
今までずっとそれ前提で話が進められていたし、
そうでないと思っているのは的外れな>>154だけだと思うんだが。
タスクに親子関係持たせるとか優先度がどうだとかいった細かい部分は
その都度最適なものを選べばよし。
157 名前：名前は開発中のものです。 mailto:sage [2006/11/07(火) 19:23:55 ID:qUpAvALP]: Cでリスト使ってて、
C++に移行したら「それタスクシステムだよ」って言われた。
どうすればいいでしょう？
158 名前：名前は開発中のものです。 mailto:sage [2006/11/07(火) 21:40:27 ID:3jPQsnxn]: もうすこしｋｗｓｋ
159 名前：名前は開発中のものです。 mailto:sage [2006/11/08(水) 10:10:54 ID:U+HCvDbD]: >>157
そうだよ。って答えれば解決。
160 名前：名前は開発中のものです。 [2006/11/10(金) 11:57:52 ID:bWKjGfw+]: ところで
d.hatena.ne.jp/kataho/20061013
ここのブログのこの問題といてみない？
161 名前：160 mailto:sage [2006/11/10(金) 11:58:41 ID:bWKjGfw+]: すまね、上げちまった
162 名前：名前は開発中のものです。 mailto:sage [2006/11/10(金) 13:40:25 ID:0fi4/IIn]: この板にしては珍しく良スレだな
163 名前：名前は開発中のものです。 mailto:sage [2006/11/10(金) 21:25:10 ID:ZkgdRmE9]: >>160
>koei.co.jp scei.co.jp square-enix.co.jp みてるんだったら会社いれてよ！！！！！！

お題とは関係ないがこの辺にワロタｗ
proxyぐらい使いましょうね、大手の皆さんｗ
164 名前：名前は開発中のものです。 mailto:sage [2006/11/10(金) 22:26:18 ID:HTGezavx]: >>163
別に問題ないと思うけど。さすがに社内サーバのアドレスを referer で飛ばしてくるのは
どうかと思うが＞k社
165 名前：名前は開発中のものです。 mailto:sage [2006/11/11(土) 01:08:30 ID:YsMNBgEw]: 自意識過剰
166 名前：名前は開発中のものです。 mailto:sage [2006/11/12(日) 00:41:12 ID:uTWo+6kj]: んで問題はとかねーの？
167 名前：名前は開発中のものです。 mailto:sage [2006/11/12(日) 01:35:58 ID:R+1O/KH4]: >>166
マジメに考えるほどのもんじゃない気がするが。

メモリの断片化や使用量見積もりを考えると、全オブジェクトを必要最小限の寿命で
確保・解放なんてせずに、シーン毎に必要なファイルぶち込んだアーカイブ作って
終わりだし。
168 名前：名前は開発中のものです。 mailto:sage [2006/11/16(木) 13:28:43 ID:S/Ecbdk+]: コーエーといえば寝るおもしろす事件だなｗ
169 名前：名前は開発中のものです。 mailto:sage [2006/11/16(木) 14:51:20 ID:fgcxjfqh]: >>167
いつ何時どういう顔でどういう武器を持ったアバターが登場するかわからない
MMOとかだとシーンとか生ぬるいこといってられないんじゃない？
170 名前：名前は開発中のものです。 mailto:sage [2006/11/18(土) 00:38:40 ID:hjek6YSO]: >>169
組み合わせが分からないなら、ワーストケースでも対応できるようにする必要があるから、
賢いメモリ管理はしない方が良いと思うが。
171 名前：名前は開発中のものです。 mailto:sage [2006/11/18(土) 00:45:51 ID:Blaci8UD]: １００００とか決めうちで適当にアバター（？）放り込む領域とっときゃい～じゃん。
クライアントで１００００人同時表示とかどうせ無理だからｗ
なんかが湧いたとしても、
射程外の見かけ小さく見えるアバターから削除しちまえばOK。
172 名前：名前は開発中のものです。 mailto:sage [2006/11/18(土) 18:42:03 ID:uDXwDRk4]: >> 171
その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
173 名前：名前は開発中のものです。 mailto:sage [2006/11/18(土) 19:28:39 ID:GUEcKJwf]: スケーラビリティはガン無視がゲームにおけるデータ構造・クラス設計の常識？
174 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 04:21:52 ID:qRasGZX0]: コンシューマならそれでも良いと思うけど、
昨今のＰＣゲーム開発であればスケーラビリティは必須では？
なんせ環境が数倍以上違うことだってあるからね。
175 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 06:35:18 ID:2miANHZG]: > その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
領域が決めうちでも決めうちでなくても発生する問題。

> スケーラビリティ
MMOなんだから、クライアントの更新でスケーラビリティを代替すればいい。
逆にPCの優劣で、プレイヤー間に格差が出るほうが問題と言えば問題。
176 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 09:18:23 ID:GnePFvEb]: んで問題はとかねーの？
177 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 10:07:08 ID:P05vv5BZ]: あれは、クラスデザインで対応すべき問題ではない、っつーのが答え
だろうな。
178 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 15:53:33 ID:3G1y/i2K]: >> 175
だから、それを採用してもその問題が残るんだろ？
この問題の本質はそこだろ。どうやってデータへのアクセスを共有させんだ？
179 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 16:36:03 ID:2miANHZG]: いや、エンジン書いてもそれはゲームじゃないからｗ
さっさとゲーム上の具体的なシーンについて見積もりを建てなさい。
領域なんて初期化時に必要な領域全部取ってしまえば問題無い。
180 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 16:54:45 ID:3G1y/i2K]: >> 179
件のサイトってMMORPG作ってるわけで、
MMORPG開発を前提にした問題を出してるんだがなあ。
シーンなんて簡単なもんじゃ見積もれないって。
181 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 17:17:03 ID:2miANHZG]: ↓↓↓ここから見積もれる/見積もれないの一点だけで１００年戦争↓↓↓
182 名前：名前は開発中のものです。 mailto:sage [2006/11/19(日) 20:33:12 ID:GnePFvEb]: なんか虎をつかまえてほしいなら虎を屏風からだしてくれみたいな回答だな
あきれた
183 名前：名前は開発中のものです。 mailto:sage [2006/11/20(月) 01:22:30 ID:SHLy4x4v]: >>180
URL貼った上で「件のサイト」を持ち出すのは、
あまり良くないと思うのだが…
184 名前：名前は開発中のものです。 [2007/01/14(日) 05:03:57 ID:gu/ia/06]: 良スレあげ
185 名前：名前は開発中のものです。 mailto:sage [2007/01/19(金) 02:34:32 ID:RsBU2cJ/]: シーン・・・
昔すべてのシーンはスタックのみで再現可能と思ってた時が俺にも有りました。

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

まだ研究中。
186 名前：名前は開発中のものです。 mailto:sage [2007/01/19(金) 13:33:30 ID:GdZe8cga]: 俺はそれは兄弟関係をコンポジットにして解決しとるよ
187 名前：名前は開発中のものです。 mailto:sage [2007/01/19(金) 14:48:25 ID:RsBU2cJ/]: コンポジットパターンですか？
なるほど。
188 名前：名前は開発中のものです。 [2007/01/27(土) 00:03:58 ID:Mwc3VMrB]: 良スレ発見。

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

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

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

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

ABAさんのソースとか見ると、生成時に引数で渡しているんだけど、
うちのDelphiだと、各ユニット間の循環参照問題を回避できなくて真似できないんだよね・・・。
189 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 00:27:08 ID:GLW5syD3]: ローカル変数？グローバル変数だよね。
その方法がまあ無理なくやれると思う。

グローバル変数がどうしても嫌なら
インターフェイス宣言を使えば、循環参照は回避できるよ。
190 名前：名前は開発中のものです。 [2007/01/27(土) 00:46:55 ID:Mwc3VMrB]: ごめん。グローバル変数です。
インターフェースか、Delphiのインターフェースって普通じゃないからなあ。

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

或曰: お仕事
www.issei.org/blog/archives/000225.html
191 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 01:29:23 ID:lX9/hWgh]: 音はコンテクストとは違うのでは？リソース？
そのインスタンスの性質そのものなんだからバリバリ依存してていい
描画デバイスはそれ自体のステートがあるんで外からもらう必要があるだろうけど
別にグローバル変数で問題ないでしょう？
まあ描画するときにだけ引数でもらうように改変するのを無理して止める気はないけど

＞www.issei.org/blog/archives/000225.html
おもしろいなーfacade+visitorかぁ
192 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 05:01:28 ID:Cu/waNhi]: サウンドみたいなものはモロにシングルトンにしてしまって
CSoundManager::GetInstance().Play( FX_HOGE );
こんなんでよいのでは
193 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 14:40:32 ID:lX9/hWgh]: ＞www.issei.org/blog/archives/000225.html
何か違和感があったので、寝ながら考えたんだけど
こいつの問題はゲームエンティティのクラスとctxのインターフェイスが１対１になってるとこかな。
まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
いちいち別の実装とインターフェイスを設けなくてはならなくなる。
意味のない制約を守るために重複コードができてしまう。
194 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 15:41:16 ID:lX9/hWgh]: それにゲームエンティティクラスが増えて、継承の階層とかができても
ctxの実装は全部の名前に_ctxつけたインターフェイスを全部同時に多重継承するんだろか？

ctxにmixinするインタフェイスはゲームエンティティのクラス群の構造に依存しないで
区分けそのものに対する名前をつけてやる方がきれい、というか合理的に思う。
例えばとにかく弾をつくるインタフェイスを公開するctxインターフェイスならICtxShootとか。
195 名前：issei mailto:sage [2007/01/27(土) 22:48:39 ID:+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 名前：名前は開発中のものです。 mailto:sage [2007/01/27(土) 22:53:18 ID:FT2+QYPW]: >188
個別にオブジェクトのアドレスを渡した場合、パラメータの個数が膨大になるのと、
きれいにまとめないとかなり手間がかかるね。

シングルトンで実装して、グローバルアクセスがよいのではとおもう。
197 名前：名前は開発中のものです。 mailto:sage [2007/01/28(日) 01:11:39 ID:aVNVY6/P]: >>issei（誰？ｗ）
＞// これで実装は両方に提供できる
確かにそうだね。書いてみてから気がついた。
具体的に書くコードの量とかの増減をあげつらう批判をしたいわけじゃないだホントは

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

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

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

ぜんぜん関係ないけどcontextってのはあんまり実態にそぐわない名前だと思うなぁ。分かるけど。
relianceとかdependencyとかのがいいような気がする。
198 名前：issei mailto:sage [2007/01/28(日) 01:38:40 ID:ViuHLna9]: >>197
> >>issei（誰？ｗ）
日記の人です。

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

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

確か別のプログラマがエフェクト用の対話型エディタを作ってたんだけど、そこで
デザイナからキャラクタにエフェクト乗せて見たいとリクエストがあって、エフェクト
エディタにキャラクタ用のコンテクスト実装してたんじゃなかったかな。もちろん、
大半の仮想関数はダミー(ヒット判定なんかの関数は、常にヒットしないと返す
だけ）だけど。
199 名前：名前は開発中のものです。 mailto:sage [2007/01/28(日) 19:27:03 ID:aVNVY6/P]: 風呂はいりながら考えたんだけど
ようは移植用区画、エンティティクラス、実装を委譲したい関数群、
それぞれをシステム内で１対１対１。ひとまとめにしたいわけだ。それはわかる。
だが無駄に暗黙的な命名の制約を持ち込むvisitorインターフェイスには反対。
contextというが、それらが文脈として差異を持たされるのは結局はプロジェクト全体で複数作られる
実行単位ごとなわけだ。それに対してvisitor風に関数レベルで型への依存を表明するのは
適当だとは思えない。何がどのレベルで変わるのかがきちんと示せてるのがいいコードっすよね。
ついでに実装をまとめるだけが目的の節操のないmixinも反対だ。

俺はこうする。

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

どこか他のシステムへもっていってもstatic関数を定義した.cppの方だけ取り替えれば移植が完了する。
200 名前：名前は開発中のものです。 [2007/01/31(水) 00:35:16 ID:NKCnpIjT]: クラス名・変数名に迷ったら書き込むスレ。Part9
pc10.2ch.net/test/read.cgi/tech/1168356029/113-132
から誘導されてきました。

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

まあ、そんな感じで、ゲーム向けのデータ構造をどうするかって話になりました。
201 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 00:44:13 ID:YqKTmdjS]: >>200
答えでてんじゃん。
ここで何が聞きたいの？
202 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 00:49:48 ID:jNUdiQRe]: フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。
203 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:00:05 ID:8/b3tbHY]: >>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの？
204 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:08:05 ID:kxHbC4YN]: いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろｗｗ
205 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:09:38 ID: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 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:10:11 ID: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 名前：名前は開発中のものです。 [2007/01/31(水) 01:13:52 ID:NKCnpIjT]: boostみて、なんじゃこりゃーな感じだったので、

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

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

これだけで、済む話かー。
208 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:14:36 ID:YqKTmdjS]: >>205
それが segregated storage だろ。
209 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:15:32 ID:8/b3tbHY]: >>208
そう言うのか
210 名前：名前は開発中のものです。 [2007/01/31(水) 01:17:52 ID:kxHbC4YN]: 欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろｗ
だって、>>200より優れたクラスなんて存在しないんだからｗｗｗ

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

この板ならではのクラス名を授けるから好きなの選べ
211 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:18:10 ID:8/b3tbHY]: そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz
212 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:22:57 ID: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 名前：名前は開発中のものです。 [2007/01/31(水) 01:24:55 ID:NKCnpIjT]: >>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。

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

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

Delphiには、boostねーよー。うらやましい。
214 名前：名前は開発中のものです。 [2007/01/31(水) 01:26:10 ID:NKCnpIjT]: × >>200様に一生従います！
○ >>200様に一生を捧げます

間違えました。
215 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:26:40 ID:94hlWcQw]: >>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの？
216 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 01:46:00 ID:94hlWcQw]: もしかしたら、主要なデータ構造を一通り勉強したいってこと？　それなら、
まずは(データ構造を処理するアルゴリズムとセットで)

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

あたりの書籍を読むのがお薦めだが。
217 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 02:00:35 ID:kxHbC4YN]: >>213
いや、普通に皮肉だから、無理にレスしなくていいよ。
218 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 02:31:13 ID:sTyDsN4F]: この板で数少ない有用なスレッドだな
219 名前：名前は開発中のものです。 [2007/01/31(水) 15:38:04 ID:CxDF9OMM]: >>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。

>>216
勉強したいだけ、というわけではないのですが、
参考になります。
220 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 19:22:58 ID:WbpDldoh]: 弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは１つあれば十分だし。
221 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 20:28:29 ID:94hlWcQw]: >>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。
222 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 22:47:38 ID:YNrC6zK6]: >>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ
223 名前：名前は開発中のものです。 mailto:sage [2007/01/31(水) 23:00:17 ID:94hlWcQw]: >>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。
224 名前：219 [2007/01/31(水) 23:25:03 ID:NKCnpIjT]: まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
（動作環境は、PCです）

新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。
225 名前：名前は開発中のものです。 mailto:sage [2007/03/21(水) 22:27:58 ID:/cwA8n13]: >>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね
226 名前：名前は開発中のものです。 mailto:age [2007/03/23(金) 13:48:25 ID:vxAgs8Dc]: 良スレage
227 名前：名前は開発中のものです。 [2007/03/26(月) 06:10:31 ID:mFbF2Qb2]: ところで、
キャラクターの構造体は何で取ってる？
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。

皆は何で取ってる？
228 名前：名前は開発中のものです。 [2007/03/26(月) 06:11:56 ID:mFbF2Qb2]: あ、ゲームは普通の２ｄのアクションゲームとかです。
229 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 08:35:24 ID:I1HKFzJn]: doubleでおｋ

次の話題どうぞ
230 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 12:51:40 ID:74T0tUus]: 単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ
231 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 18:43:03 ID:/edWn9Q+]: >>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし
232 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 19:09:19 ID:I1HKFzJn]: 桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
　敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。

そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。
233 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 19:20:52 ID:/edWn9Q+]: >>232
そんなクラス作らなくてもいいんじゃね？
16ビットシフトするだけでゲームの精度的には十分かと。
234 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 21:35:29 ID:/T0E1d66]: ttp://shinh.skr.jp/template/gamenum.html
235 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 22:10:26 ID:xV5pAsSl]: >>232
なんか勘違いしてるけど、固定小数点数にするのに１０進は関係ないぞ。
236 名前：名前は開発中のものです。 mailto:sage [2007/03/26(月) 22:13:45 ID:I1HKFzJn]: >>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。
237 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 01:42:55 ID:0naF3MYn]: 10進でも2進でも丸め誤差は出るってば。
238 名前：その1 mailto:sage [2007/03/27(火) 06:12:21 ID:6cy45QrY]: 「キャラの座標の型に関して」

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

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

・浮動小数点数
　○ 基本型であるので扱いが楽
　× 演算速度が遅い
　△ 非常に近い値同士を比較したときに桁落ちが発生する
　　 (桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
　○ 比較による桁落ちが発生しない
　○ 実態は整数型なので演算速度が早い
　　-> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
　　　　　可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
　× 固定小数点数オブジェクトの生成が頻繁であると遅くなる
　　 (特にオペレータ・オーバーロードに注意)
　△ 小数点以下の精度(桁数)が固定
　　 (ただし、精度が足りなくて困ることはまず無いと思われる)
239 名前：その2 mailto:sage [2007/03/27(火) 06:13:22 ID:6cy45QrY]: ・2進表現
　○ 基本型は2進表現なので扱いが楽
　× 10進表現で有限小数となるが2進表現で循環小数になるような値の場合、
　　表現できない桁が切り捨てられるなどして丸め誤差が発生する

・10進表現
　○ 循環小数に対する丸め誤差が起きない
　　-> × 一般によく使われるであろう加算減算処理では問題ないが、
　　　　　除算を行うなどすると何進数であろうが丸め誤差は発生する
　XX 基本型とは程遠い別次元の演算手法が要求される
　　 (2進表現で循環小数となるような値を基本型で記述した時点でアウト)
　× 同じバイト数で表現できる値の範囲が2進表現より狭い

勝手にまとめっぽい形式で書いてみた。
固定小数点数に関してはクラスとして実装した場合を想定した。
個人的に、固定小数点数を素のintで表現して、その都度シフト変換を行うような手法は、
変換方法に依存した関数/クラスを大量発生させるので論外だと思う。
240 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 06:39:01 ID:AmaYqa2T]: 10進表現ってBCDのことだったの？
俺はてっきりintを10^nで割って使う話だと思ってた。
241 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 06:42:53 ID:6cy45QrY]: 色々書いたけど、結局俺は無難なdoubleを使っちまうかなあ。
試しに固定小数点数クラスを作ってみたけどあんまし早くならなかった。
っていうかコンパイラによって速度が大きく変わりそうな予感。

10進表現での計算は、誤差が出たら切腹必至の
銀行システムとかでのみ使うものだと思っている。
言語的にサポートされていれば話は別だけど。

以上長文&駄レスすまん。
242 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 06:45:51 ID:6cy45QrY]: >>240
俺は流れ的にBCDのことだと思ったが…。違ってたらすまん。
243 名前：名前は開発中のものです。 [2007/03/27(火) 10:06:48 ID:KORunXqt]: 昔は、固定小数点使ってたな
今は、さすがに、浮動小数だわ

問題は、環境によっては、リプレイでずれるとかその辺
（D3DXの最適化とか最適化とか最適化とか）
244 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 12:34:52 ID:WDGoOIYE]: 浮動小数点だと0.1ですらがあらわせないからな
表せないのに無理しているのが浮動小数点
あらわせないのなら扱わない、問題が出ないようにするのが固定小数点

0.1を10回たしたら１になるとか思ってるような人は固定小数点つかっとけと
245 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 14:36:14 ID:DOw2VNK3]: アナログコントローラーとか3D処理やったこと無いのかな
246 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 19:55:06 ID:OAIOW3b5]: Flashとかだと0.5ずつずらさないと隙間が空くとかあるんだよね
247 名前：名前は開発中のものです。 mailto:sage [2007/03/27(火) 20:06:13 ID:6cy45QrY]: 微妙に関連する話題だと思うんだけど、
皆は(無限)多倍長精度整数を使ってたりする？
248 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 00:55:28 ID:3c8pkg+a]: >>247
固定小数点数使ってたら、上の桁が足りなくて、
仕方なしに64ビット整数を使っちゃったことはある
249 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 05:12:49 ID:cMkZ8VMH]: >>247
そういうのは学術用だと思うよ。
ゲームなら実際問題そんないらんっしょ。
250 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 05:53:37 ID:vQ7wya7A]: 得点計算で使われることもあると思う。
32bit符号なし整数では40億程度しか表せないし。

恐ろしい桁数の得点をガンガン加算させて、
かつ一の位までキッチリ使っちゃうような
血も涙もない鬼の方御用達です。
251 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 07:59:56 ID:cMkZ8VMH]: 無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか？
252 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 11:11:39 ID:xf4mLohJ]: >>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。
253 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 12:08:50 ID:hyD2GS3G]: ビルゲイツの資産とか32bitに収まりきらんもんな
254 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 12:54:06 ID:HnZM11tF]: そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。
255 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 15:10:12 ID:+k+f3/yD]: 32bitどころじゃないだろ。

まあ、毎年訳分からん団体に１兆寄付してるおっさんだからな。

寄付してるのは妻の方だけ？
256 名前：名前は開発中のものです。 mailto:sage [2007/03/28(水) 16:57:57 ID:erfbPR6U]: 自分の設立した財団じゃないのあれ？
257 名前：名前は開発中のものです。 [2007/03/30(金) 00:16:52 ID:xOzIjQQy]: Delphiの日付用構造体TDateTimeを馬鹿にするなよ？
日付なのに、不動小数
258 名前：名前は開発中のものです。 mailto:sage [2007/03/30(金) 01:10:16 ID:/yTpVVer]: 不動ならいいや('ー`)
259 名前：名前は開発中のものです。 mailto:sage [2007/03/30(金) 03:52:48 ID:HXn7HlKm]: MSのAccessも日付はdoubleでもってたような・・・
260 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 02:13:01 ID:aK7v4JwN]: いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。
261 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 13:27:10 ID:vpNPV10r]: >>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。
262 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 14:21:19 ID:XdYqPGRk]: なるほどそういうときにシリアライズを使うのか
263 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 15:15:13 ID:Sn7iJUNq]: >>260
Gemsの５巻にスタックを使ったシーン管理が載っている。

試してみたら、なかなか使い易かったよ。
264 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 15:35:35 ID:gVILklLW]: >>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ
265 名前：名前は開発中のものです。 mailto:sage [2007/04/01(日) 20:39:12 ID:4uyw/V8k]: >>260
作ってるゲームによるでしょ。

シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る（ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく）、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。
266 名前：名前は開発中のものです。 [2007/04/05(木) 20:02:57 ID:53u6wZm0]: >>263
Gemsうｐ！！
って、無理だｗ

ソースコードだけでも配ってないのか・・・
267 名前：名前は開発中のものです。 mailto:sage [2007/04/06(金) 02:24:49 ID:jVhSsUiB]: 【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。
268 名前：名前は開発中のものです。 [2007/04/06(金) 16:07:18 ID:+BNVME6N]: スタックベースのシーン管理に参考になるページはないですか？
269 名前：名前は開発中のものです。 mailto:sage [2007/04/07(土) 09:34:17 ID:ok5ggep+]: どっかのやねうの昔のサイトに解説がなかったか。
270 名前：名前は開発中のものです。 mailto:sage [2007/04/07(土) 12:47:03 ID:lstp6MTf]: YaneSDK.Netのソース読め
271 名前：名前は開発中のものです。 mailto:sage [2007/04/08(日) 01:31:41 ID:TWCxMGaJ]: 本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください＞＜
2ndからトランジエントビルトを移植しようとしたんですが正直無理です＞＜
272 名前：名前は開発中のものです。 mailto:sage [2007/04/08(日) 01:42:46 ID:Svf9QlZ3]: 無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。
273 名前：名前は開発中のものです。 mailto:sage [2007/04/08(日) 02:50:06 ID:l6t1YJuf]: 皮肉にマジレスしてどーする
274 名前：名前は開発中のものです。 mailto:sage [2007/04/08(日) 13:14:13 ID:8g6onocj]: そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。
275 名前：名前は開発中のものです。 [2007/04/09(月) 03:25:15 ID:/ygJ9fwS]: 騙された馬鹿が、ギャーギャー文句言ってただけ
276 名前：名前は開発中のものです。 mailto:sage [2007/04/09(月) 03:38:12 ID:TJO4g1v+]: いい加減スレ違い。
277 名前：名前は開発中のものです。 [2007/04/09(月) 13:14:13 ID:/ygJ9fwS]: スタックベースのシーン管理について質問

つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・
278 名前：名前は開発中のものです。 mailto:sage [2007/04/09(月) 15:13:20 ID:bk7kEELW]: スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか
279 名前：名前は開発中のものです。 mailto:sage [2007/04/09(月) 16:14:10 ID:3UDAKRrm]: シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない？
280 名前：名前は開発中のものです。 mailto:sage [2007/04/09(月) 18:50:04 ID:CrOX57BA]: >>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。
281 名前：名前は開発中のものです。 [2007/04/09(月) 20:46:27 ID:d0StE6D+]: >>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。
282 名前：277 [2007/04/09(月) 20:49:46 ID:d0StE6D+]: とりあえず、googleして、定番とおもわれる

・呼び出し（Call)
・移動(GoTo)
・呼び出し側に戻る（Return)

をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、

これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし

クソー、Game Programing Gems 5がほしいZE
283 名前：277 [2007/04/09(月) 20:54:13 ID:d0StE6D+]: > 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな？と思うし
284 名前：名前は開発中のものです。 mailto:sage [2007/04/09(月) 23:33:21 ID:HDs+xqt8]: ところでシーン間の関係はだれが持つの？

シーンクラス？シーン管理クラスとか他のクラス？

分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・？

シーン遷移管理とシーン関係管理＋フラグ管理に分けるとか？

>シーンを遷移するときって、前のシーンは開放しちゃっていいのか？

javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。

こういうときにファイナライザ使うもんじゃないしね。
285 名前：名前は開発中のものです。 mailto:sage [2007/04/10(火) 00:13:19 ID:NhbAQuFj]: >>277
シーンは最初に全部確保して
最後に全部解放してるよ。

シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか
出来ますよ　って趣旨だったと思う >Gems5

ただ、ウィンドウ関係以外には特に利点は無さそう。
286 名前：名前は開発中のものです。 mailto:sage [2007/04/10(火) 01:08:35 ID:wXzQkwkx]: マルチスレッドを実現する手段の一種ということ？
287 名前：名前は開発中のものです。 mailto:sage [2007/04/10(火) 01:12:58 ID:vYIHoF6r]: >>285
＞でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね？
LIFO≠スタック
288 名前：名前は開発中のものです。 mailto:sage [2007/04/10(火) 01:16:37 ID:EIMh3HFt]: なんだ、シーンの遷移がスタック的なのかと思ってた。
289 名前：285 mailto:sage [2007/04/10(火) 01:26:00 ID:NhbAQuFj]: >>287
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから　一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたｗ

スタック全体をなめるんだからスタックとは言わないと俺も思う。
290 名前：277 [2007/04/10(火) 01:59:26 ID:9N2vtVIw]: わかった。
かなり勘違いしていた・・・。

>>288
俺もそう思ってたｗｗ
291 名前：名前は開発中のものです。 [2007/04/10(火) 09:19:06 ID:xnqcZNCE]: これ読んで、久々にパックマン作りたくなったな～。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな？
292 名前：名前は開発中のものです。 [2007/04/10(火) 09:47:11 ID:9N2vtVIw]: Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.
293 名前：名前は開発中のものです。 mailto:sage [2007/04/11(水) 01:26:38 ID:hEaakUMM]: >>291
> デザインパターンって、しらない人多いのかな？
んなわきゃない
294 名前：名前は開発中のものです。 [2007/04/11(水) 05:40:08 ID:6fD2+qm/]: スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったｗ

これで、

　タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面

とか、
　タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
　リプレイメニュー→(戻る)→タイトル画面
とかできるようになったｗ

スタックベースといったらやっぱりこっちだろｗ
295 名前：名前は開発中のものです。 mailto:sage [2007/04/11(水) 05:56:16 ID:M15Cgj6f]: スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。
296 名前：名前は開発中のものです。 mailto:sage [2007/04/11(水) 07:47:20 ID:J6IpVt/X]: スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る＝push操作
・1つ前のシーンに戻る＝pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279と>>281のようなやり取りが行われている現状では仕方がないか。
297 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 03:38:40 ID:AG1SAh/k]: 実質が状態遷移ならstateパターンでいいやんって事ですか？
298 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 04:43:05 ID:0Ip1HTkJ]: >>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。

どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作＝次のシーンに移る
・pop操作＝1つ前のシーンに戻る
・top操作＝現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。

これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる？
299 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 05:16:23 ID:0Ip1HTkJ]: (続き)
で、何故Stackベースのシーン管理に関して
>>295と>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。

例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。

"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。

"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。

ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。
300 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 07:27:37 ID:KA8mV/7R]: Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。
301 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 11:44:45 ID:dOVFJA3U]: >>185-
ちょっと参考になるよ
302 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 18:19:58 ID:sR+tFe8j]: 色々考えて、俺はスタック的な遷移も結構いいんじゃないかと思えてきた。

スタックだと、シーンの遷移の責任は全て親に任せることができる。
キャンペーンモードなのか、単独のマップを遊ぶだけのモードなのかは、自分は
知る必要もなく、遷移する理由（勝利、敗北、キャンセル…etc）だけを伝えれば
次にどのシーンになるかは親が決めてくれる。

各シーンが自分で次のシーンを選んでダイレクトに遷移していくよりは、
親に一任した方がすっきりするね。

スタックそのものでなくても、スタック的な遷移ができることは便利だと思う。
303 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 20:03:01 ID:+rjgMuLJ]: うむ、完全にpush/popに収める必要はないよな。
304 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 20:15:13 ID:BUTEbHo0]: 素直に多方向リンクリストでやれよ。
305 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 20:25:07 ID:+rjgMuLJ]: それは実装・データ構造の話じゃん。
306 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 21:46:48 ID:V5BuRGqQ]: >>302
遷移する理由を伝えることによるシーン遷移ってのはいいね。
が、これは別にスタックに限った恩恵ではない
(っていうのは>>302もわかってると思うけど)。
>>304の言う多方向リストでも可能(っていうか本来はこっち)だし、
イテレータが指すシーンを現在のシーンとする双方向リストでも可能。

多方向リストで工夫して実装すれば、
リソースを食うシーンに移ったときに
前のシーンをいくつか解放するといった処理が行えるし、
シーンを激しく前後するような操作をしても
オーバーヘッドがかからないのでいいかも。
もっとも、ゲーム起動時にリソースを全部先読みしても
全く問題ないようなゲームだったら、
積みっぱなしのスタックで全く問題ないし、
これが一番簡単だと思うけど。
307 名前：名前は開発中のものです。 mailto:sage [2007/04/12(木) 22:34:50 ID:Yo7l8Dzb]: "多方向リンクリスト"に該当するページが見つかりませんでした。
308 名前：名前は開発中のものです。 [2007/04/13(金) 01:17:14 ID:FDWvNnME]: 双方向リンクリストじゃない？
309 名前：名前は開発中のものです。 mailto:sage [2007/04/13(金) 01:37:40 ID:maKmelpg]: 色んな方向につながってるってことは…
vectorじゃねぇの？
310 名前：名前は開発中のものです。 [2007/04/13(金) 02:13:59 ID:ye+8qT/8]: 遷移元シーン番号と遷移事由コードで
テーブルから遷移先シーン番号（またはシーンオブジェクトの参照）を
引くだけというのはだめだろうか
311 名前：名前は開発中のものです。 mailto:sage [2007/04/13(金) 04:18:27 ID:VGgK68eb]: ヒント：C言語などの関数
312 名前：名前は開発中のものです。 mailto:sage [2007/04/13(金) 04:47:41 ID:sVc4IdNT]: >>311
エレガントじゃない気がする
313 名前：名前は開発中のものです。 mailto:sage [2007/04/14(土) 05:39:36 ID:0P7qLuwH]: 状態の保存方法なんて画面にあわせて stack なり queue なり
vector なり list なり、適当に作ったツリー構造なりを使えばいいよ。

コンテナ実装するのも一苦労だったアセンブラやCで組む時代じゃないんだから、
全体でどれに統一するか悩む必要なんて無いでしょ。
314 名前：名前は開発中のものです。 mailto:sage [2007/04/15(日) 10:34:45 ID:PbHNo8Qe]: ログ
315 名前：名前は開発中のものです。 mailto:sage [2007/04/15(日) 14:31:59 ID:GX7kX5Cm]: 参照カウント付きスマートベクトルポインタ使ってシーンの遅延生成や破壊を自動管理したり
夢が広がりまくりんぐ
316 名前：名前は開発中のものです。 mailto:sage [2007/04/19(木) 13:16:55 ID:WPH1WRyj]: シーン間の遷移（例えばクロスフェード）とかどうやってる？
317 名前：名前は開発中のものです。 mailto:sage [2007/04/19(木) 13:42:33 ID:1tbYRD5H]: 俺はシーン別に切り分けてバッファを持っている。
318 名前：名前は開発中のものです。 mailto:sage [2007/04/19(木) 22:50:53 ID:ofjIK8wt]: 自分は、Viewで処理してて、Modelでのシーン自体は完全に移行済みにしとく。

あくまで、表示（演出）は表示（演出）ときりわけやったほうがいいと思うし、
また、切り分けとくと変更も楽だし、テスト時とか演出要らん場合はさっさと飛ばせるし。
319 名前：名前は開発中のものです。 mailto:sage [2007/04/20(金) 18:21:55 ID: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 mailto:sage [2007/04/20(金) 18:22:39 ID:NDgAfFd0]: >>319も316です^^
321 名前：名前は開発中のものです。 mailto:sage [2007/04/20(金) 23:58:50 ID:jHP7m8qh]: やねうら臭がする
322 名前：名前は開発中のものです。 [2007/04/21(土) 04:53:19 ID:upqCn/9t]: >>319
俺もおおよそそんな感じ
323 名前：名前は開発中のものです。 [2007/04/21(土) 09:13:46 ID:jPfR3hGz]: 沖縄県の方へ（命に関わる注意事項です）

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度　沖縄　三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
　簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
　（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
　さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
　3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
　そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
324 名前：317 mailto:sage [2007/04/23(月) 17:44:03 ID:jyQ0IgwD]: >>318とほぼ同じと思うけど
シーンに関してスタックは使ってないので、並列処理しているとき
それぞれのシーンが自分用の裏画面などを持ってないと都合が悪い

表示（演出）は別クラスにして任意シーンの裏画面を複数使って料理する
ぶっちゃけ、カメラを切り替えている感じ
325 名前：名前は開発中のものです。 mailto:sage [2007/04/24(火) 20:58:04 ID:LmvfBEf6]: >>324
なーる。表示用クラスが裏画面(テクスチャだよね？)
を複数使って演出してるわけね。
ありがとう^^
326 名前：名前は開発中のものです。 mailto:sage [2007/04/30(月) 13:33:52 ID:rkXlhSNv]: RPGでマップとかイベントはゲームスタート時に全部ファイルから読み込んでメモリに置いておくほうが普通でしょうか？
それともマップに入ったときにファイルからロードするほうがいいでしょうか？
327 名前：名前は開発中のものです。 mailto:sage [2007/04/30(月) 13:38:16 ID:Omqviadr]: 普通なら、使いもしないデータを主記憶に展開しておくのは無駄としか思えないが・・・
328 名前：名前は開発中のものです。 mailto:sage [2007/04/30(月) 14:13:55 ID:+32zYLn2]: 環境とか開発の容易性とかいろいろ考えた上で全部入れるのはべつにかまわん
重いのは画像や音声だったりするわけでそれがないので別に大丈夫かと

規模によっちゃそれすらもまるごといれてもかまわんけどな
1MBもあればFF4がまるごとはいるわけで
329 名前：名前は開発中のものです。 [2007/04/30(月) 14:36:40 ID:rkXlhSNv]: 動的に読み込むってなかなか難しくて・・・
FF4で1MBなら自分の程度なら全部読み込んでも大丈夫かも。
330 名前：名前は開発中のものです。 mailto:sage [2007/04/30(月) 16:15:04 ID:1Z2FVuUn]: シームレスは少し難易度高いが、区画ごとに区切っていいなら難しくないんじゃ？
あっちこっちでグローバル変数使うような原人は知らん。
331 名前：名前は開発中のものです。 mailto:sage [2007/04/30(月) 17:45:14 ID:QczQVIdr]: 最初は難しいことに手を出すよりも、楽なほうでやったほうがいいよ。
後からだんだん発展させていけばいいと思う。
ぐちゃぐちゃになったらリファクタリングで。
332 名前：名前は開発中のものです。 mailto:sage [2007/05/01(火) 07:32:01 ID:n4UjW/KJ]: クラスが多くなってぐちゃぐちゃになってきたorz
RPGって結構複雑ですぐ混乱してくる。
そろそろUMLとか勉強しないときついなと思ってきた。
333 名前：名前は開発中のものです。 mailto:sage [2007/05/01(火) 10:50:48 ID:TWHDSCbL]: UMLは構成を抽象化して理解するためのものであって
おぬしの想像しているものとは用途が違うぞ
334 名前：名前は開発中のものです。 mailto:sage [2007/05/01(火) 11:11:50 ID:RvA2WJ3F]: システムの規模が肥大して、クラスを整理するのが大変になってきたら
UMLなり何なり書いて一からやり直してもいいんじゃねぇの
335 名前：名前は開発中のものです。 mailto:sage [2007/05/01(火) 11:14:53 ID:TWHDSCbL]: リファクタリングとデザインパターンおぼえておけばおけ
アクセサとしてpublicなメソッド用意してるだけだとあとでみなおすとききついから
フレームワークつくればよろしい
336 名前：名前は開発中のものです。 mailto:sage [2007/05/01(火) 14:19:12 ID:QizfdMH2]: 有名そうなライブラリをぱくるとかで
337 名前：名前は開発中のものです。 mailto:sage [2007/05/02(水) 23:12:09 ID:n6prPmTN]: UMLからソースのスケルトンを自動生成する奴とか使って手抜きしたい
一応ヘッダから関数の定義のスケルトンや、標準関数やライブラリの関数のusing宣言を
自動化する程度のツールは自作して使ってるけど
338 名前：名前は開発中のものです。 [2007/05/02(水) 23:15:54 ID:waD0m0t1]: 今までいきなりコーディング始めてたんだけど大規模なゲーム作り始めて設計の重要性を痛感したorz
ただUML書いててもちっとも楽しくない。
339 名前：名前は開発中のものです。 mailto:sage C++が書きたい [2007/05/02(水) 23:53:12 ID:HOIFQT1u]: >>338
おやこんな所に俺がいるじゃないか

早く新人研修のJava教本を読む作業に戻るんだ・・・
340 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 03:33:21 ID:aROKnpN+]: 俺はUML書いてるだけで楽しいけどなあ
341 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 04:46:21 ID:PxIyx3hy]: 同意
コードに落とす方がかったるい
342 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 07:22:23 ID:mjAAEilH]: すげー、良く分かるｗ
コード打ってる時も、デバックしてる時はめんどい加減で止めたくなる。
343 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 10:26:46 ID:ykGFiN+W]: 俺は未だに、コーディングするときは脳内麻薬出まくり。

分かりきった定型的なコードを書いてるときは退屈で死にそうだけど。
344 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 17:19:41 ID:GHCrYaAw]: 人それぞれだなー
自分はキーボードかたかた叩いてちょっとずつ作っていく瞬間が楽しい

でも設計できないと先がなさそうorz
がんばってUML勉強しよう。
345 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 17:36:22 ID:mjAAEilH]: >>344
UMLはそういうものじゃないぞ。基本的にあれは知らなくても十分だし。
（あくまでも、設計の書き方・設計のための言語みたいなもん。
　個人か固定少人数でやるなら、適当でもなんとかなるし。）

設計を　と思ってるなら、普通にオブジェクト指向系の本がいい。
自分が買って読んだ本で、お勧めは
　憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門
まぁ、あと定番ながら
　オブジェクト指向プログラミング入門
　デザインパターンとともに学ぶオブジェクト指向のこころ
立ち読みで数ページしかみてないけど、入門の方はC++ 以外の言語（Object-C、Java、Delphi?）まで含めた本。

どれもこれも、値段も高いし・ページ数もやたらとあるしで
趣味でゲームを作るだけならちょっとオーバーワークっぽくも思えるけど、
Programmerとしての教養に読んでみては？
346 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 18:20:36 ID:q0fI33vb]: 憂鬱本は読んでみたけれど全くオススメできない。
ゲームプログラマなら、遅くともインベーダゲームを例とした説明のところで
頓珍漢なことを言っているのに気づくべき。
347 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 18:36:59 ID:l4cqkKLa]: JAVAでもいいなら「オブジェクト脳のつくり方」がお勧めだぞ。
ＵＭＬの超簡単解説もあるし。
例題が業務システムなのがアレだが、
本質的な部分はC++も同じだから大丈夫かと。
348 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 19:06:09 ID:aROKnpN+]: アレコレ言ってもしょうがないんでとりあえずUMLに触れてみて
どうやってコレを使ったら自分の助けになるのか
自分なりに理解するのが大切だと思いますよ
349 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 21:21:39 ID:ykGFiN+W]: >>344
書籍で理論や共通知識を学ぶのも良いけど、ある程度コーディングできるように
なったら、「ホンモノ」のコードを読んでみるのも良い勉強になるよ。

個人的には UNIX V6 のソースコード読んで勉強したクチなんだが、いまどきの
人に薦められるかというと、ちょっと違う気がする。今だと Java, C++ あたりで
良い教材無いかねぇ…
350 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 21:26:04 ID:t/pC1jsI]: UMLといってもクラス図くらいしか描かねぇ
351 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 21:47:30 ID:aROKnpN+]: 色んな図あるけど業務でやらない限りは
クラス図、アクティビティ図、シーケンス図あたりが限度かねぇ
352 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 21:53:36 ID:ifdqR3nP]: 業務でもそれプラスユースケースくらい
353 名前：名前は開発中のものです。 mailto:sage [2007/05/03(木) 22:57:52 ID:ykGFiN+W]: >>351
俺はアクティビティ図を抜いて、代わりにステートチャート図が追加って感じ。
354 名前：名前は開発中のものです。 [2007/05/04(金) 13:14:26 ID:ljy2orUl]: > 憂鬱なプログラマのためのオブジェクト指向開発講座

これ、全然おもしろくなかた。
わかりにくい。
オブジェクト指向分かってる後によんだのに、わかりにくかった。

「プログラマのための憂鬱なオブジェクト指向開発講座」に直すべき。
355 名前：名前は開発中のものです。 mailto:sage [2007/05/04(金) 14:10:22 ID:TiDrCtuu]: そんな>>354のオススメ図書は？

いや、あおりでなしに、その本読んだけど分からなくて、今も分からないままなもんで。教えてくらさい　orz
356 名前：名前は開発中のものです。 mailto:sage [2007/05/04(金) 21:08:31 ID:+e+/DrXO]: シームレスってどうやんの？
例えば2DのRPGマップをスクロールさせる様なばやいとか
357 名前：名前は開発中のものです。 mailto:sage [2007/05/04(金) 21:14:04 ID:osoiCnRq]: >>356
普通にやれば言いと思うが・・・
どんな状況を言ってるんだ？
358 名前：名前は開発中のものです。 mailto:sage [2007/05/04(金) 21:44:45 ID:7VEgWe3m]: >>356
マップをエリアに分割して、自分が今いるエリアの周囲をメモリに読み込んでおく。
移動して自分がいるエリアが変わったら、不要になったエリアの情報を破棄して
必要なエリアの情報を非同期読み込み。

これだけだが、何か疑問が？
359 名前：356 mailto:sage [2007/05/04(金) 23:07:32 ID:+e+/DrXO]: わかったありがとちん。
作ってみるよ。
360 名前：名前は開発中のものです。 [2007/05/05(土) 00:05:52 ID:WcHz0Tx6]: >>355
あー、俺は、Delphiを使っているうちに覚えてしまったたちでね・・・。
当時は、標準添付ライブラリのVCL使ったり、ソースとか読んだりして、オブジェクト指向を学んだな。

今なら、.NETのライブラリ使ったり、コンポーネント作って、覚えるようなもんだろうか。

習うより、慣れろって感じでスマソ。

あえて言うなら、実践的なオブジェクト指向ということで、
デザインパターンの言及しているwebページとか、本とかかな？
直接関係ないが、開発技法になっちゃうが、XP（エクストリームプログラミング）関連とかも、
OOP前提が多くて、実践的でためになる。
リファクタリング、ユニットテストなど。

あと、Javaでかかれた本とかページとかは、オブジェクト指向前提で参考になるよ。
361 名前：名前は開発中のものです。 mailto:sage [2007/05/05(土) 01:04:52 ID:EPC7H7SP]: なんとなくだが、>>360は見栄を張ってる気がする。
“ためになる”　“参考になる”とか言いつつも具体的な書籍やHPも挙げないし、
言ってる事も理解へ向けてと言うよりも言葉で煙に巻く感じで（・Ａ・）ｲｸﾅｲ!!

自分なら>>355には、　オブジェクト指向プログラミング入門を推す。
内容にがやや教科書的/板書的過ぎるから普通の読み方じゃなく
章単位の読み方とか多少英語論文的な読み方が求められるけどページ数に合った力がつくと思う。

あと、ここでなんか批判されまくってるが、「憂鬱な」はそんな悪い本じゃないと思うぞ。
まぁちらほら賛成できない部分や論理的におかしい部分は見受けるが、それでもなかなかの良書。
もう一度、読み直してみるのもいいと思うが。
362 名前：名前は開発中のものです。 [2007/05/05(土) 02:25:29 ID:WcHz0Tx6]: アホか。見栄はりに2chに来てねーよ。
煙に巻くつもりなら、レスしなけりゃいい。

具体的なページを上げられないのは、当時のをブックマークしてないから。
第一、コード書いて、読んで、実地で学んだと言っているのに・・・。

ただ、「デザインパターン」とか「エクストリームプログラミング」とかキーワード上げてるんだからさ・・・
まあ、ググレカスと言いたいところなのだが・・・

■デザインパターン
サルでもわかる逆引きデザインパターン　第1章はじめてのデザインパターン　はじめに
www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html

Amazon.co.jp：オブジェクト指向における再利用のためのデザインパターン: 本: エリックガンマ,ラルフジョンソン,リチャードヘルム,ジョンブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,本位田真一,吉田和樹
amazon.co.jp/o/ASIN/4797311126/
流行になった本だが、実例少なく今となっては読みにくい。CDの中身がまとまっていてよい。

Amazon.co.jp：デザインパターンとともに学ぶオブジェクト指向のこころ: 本: アラン・シャロウェイ,ジェームズ・R・トロット,村上雅章
amazon.co.jp/o/ASIN/4894716844/

Amazon.co.jp：増補改訂版Java言語で学ぶデザインパターン入門: 本: 結城浩
amazon.co.jp/o/ASIN/4797327030/
363 名前：名前は開発中のものです。 [2007/05/05(土) 02:26:17 ID:WcHz0Tx6]: ■リファクタリング
オブジェクト指向は直接関係ないけど、おすすめだから読んどけ。

Amazon.co.jp：リファクタリング―プログラムの体質改善テクニック: 本: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
amazon.co.jp/o/ASIN/4894712288/
プロでこれ読んでない奴いたら、殴っていい

Amazon.co.jp： Java言語で学ぶリファクタリング入門: 本: 結城浩
amazon.co.jp/o/ASIN/4797337990/

ちなみに、コメントないのは、俺が読んでないものなので注意（わかりやすそうなのを上げといた）

長いURL書き込めなくて苦労したぜ・・・
364 名前：名前は開発中のものです。 [2007/05/05(土) 02:33:04 ID:WcHz0Tx6]: あとは、OOPしてる読んでおきたいソース。

一応ゲーム制作技術板だから、ゲーム系のソースでも上げとこうか。

ABA Games
www.asahi-net.or.jp/~cs8k-cyu/

Titanion
www.asahi-net.or.jp/~cs8k-cyu/windows/ttn.html

とりあえず、ふつーに、OOPしとるんで読んで参考になること請け合い。
規模はでかくないが、ABA氏の一通り完成されたゲームばかりなので勧めやすい
あと、D言語やJavaばかりだから読みやすいよ。
365 名前：名前は開発中のものです。 mailto:sage [2007/05/05(土) 04:41:51 ID:nOa25t75]: 初心者ならオブジェクト指向狂詩曲がいい。
内容はたいしたことは無いが、ＯＯＰの作法みたいなものがわかる。
軽く読めるのでおすすめ。

ところでダックタイピング系の書物でおすすめない？
366 名前：名前は開発中のものです。 [2007/05/05(土) 09:36:59 ID:WcHz0Tx6]: >>365
ダックタイピングって、Rubyとか、Pythonのアレですか？
C++とかで実装する方法とかってことですか？

そんな局所的な本なんてでてんのかなー。
367 名前：名前は開発中のものです。 mailto:sage [2007/05/05(土) 12:08:35 ID:+5LnnL0c]: ェネリックプログラミング系の書物がそれにあたるような気が
368 名前：名前は開発中のものです。 [2007/05/23(水) 19:36:40 ID:yFXY+8Zs]: たまにネタふり。

2Dゲームなどで使われる
オーダーリングテーブル（Ordering Table）は、すでに常識でしょうか。
たぶんローカル用語でしょうけど、大体用語がないので、これですませています。

おれは、弾幕ゲーム作ってるんだ！
いちいち、物体ごとに、Zソートしてたら遅くなる！そんな時に使用します。

z値ごとに、ArrayListをもって、バケットソート（バケツソート）するような感じです。
z値が広い場合は、z値を狭めるか（0～100くらいの定数にしてもいい）、
z値を割って使用します。

図では、こんな感じ。

z値
0　→□→□
1
2　→□
3　→□→□ →□→□
4　→□→□

□は物体。
369 名前：名前は開発中のものです。 [2007/05/23(水) 19:39:22 ID:yFXY+8Zs]: >大体用語
代替用語
370 名前：名前は開発中のものです。 [2007/05/23(水) 20:10:55 ID:yFXY+8Zs]: >>368
登録するのを物体ではなく、メソッドポインタなどにすれば、より汎用性が高まると思います。
371 名前：名前は開発中のものです。 mailto:sage [2007/05/23(水) 20:13:35 ID:tJZKFF0H]: 久々に凄いネタ振りを見た
372 名前：名前は開発中のものです。 mailto:sage [2007/05/23(水) 20:46:34 ID:sQffGK0m]: 人いたんだこのスレ
373 名前：名前は開発中のものです。 mailto:sage [2007/05/23(水) 21:17:01 ID:h3A9cPXz]: ぶっちゃけZソートで重いって8bitCPUかと
374 名前：名前は開発中のものです。 mailto:sage [2007/05/23(水) 21:37:02 ID:5lNumVZr]: 最近知って、自慢したくて仕方なかったのでしょうw

使いどころ違うしw
375 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 00:12:03 ID:sQQ2EGyG]: >>368
> 物体ごとに、Zソートしてたら遅くなる！
今ならZバッファ使えばいいじゃん。PlayStation じゃないんだし。
376 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 00:19:50 ID:4PByfCCv]: >>375
画像処理のことなのか?
まぁ、半透明使うならZソートしといたほうがいいけど

>>368はハッシュとかツリーとか勉強するといいかも
377 名前：名前は開発中のものです。 [2007/05/24(木) 14:14:16 ID:MN3OTeQA]: >>375
3Dのシーンならそれでいいんですけど、
2D主体で、アルファ付きテクスチャ描画が標準、
アルファブレンドを使うのが当たり前、加算合成などが多めになると、
Zバッファが使えなくないですか？

俺、もしかしたら、基本的なところで、ミスってる？('A`)

>>373
毎フレーム、オブジェクトを数千個ソートするのもそんなには重くはないですけどね。

>>374
実は、昔から(DirectDrawの時代)から使ってるんですが、
使いどころ間違ってるのあｋ－－－－－マジ教えてくれ

>>376
そうです。半透明が多めなんです。

Hashとかﾂﾘｰは普通に使います。OTの実装もHashと同じですし
378 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 15:21:37 ID:4PByfCCv]: hashとかわかってるならなんでそんなことをココに書き込むのだと小一時間問い詰めたい
379 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 15:43:03 ID:a3uG9+mx]: ・２D主体かつαブレンドを多用
・z値が整数で適当な範囲に収まる場合
ならその方法がいいのかもね
でもゲームによってやり方を変えるのが一番賢いだろうね
380 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 16:17:32 ID:aFaY4/D0]: >378
最初にネタふりって書いてあるやん
381 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 16:34:16 ID:uojugi7P]: っていうか、2Dのスプライトの場合はZオーダーなんてそう頻繁に
入れ替わるものではないから、前フレームのソート結果を上手く利用すれば、
もっと軽くできると思う。
382 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 16:58:41 ID:FtXKITOW]: このスレの90％はネタを振る人間とそれにケチをつける人間でできています
383 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 20:02:03 ID:K0O2WDIn]: >>382
残りの10%は？
384 名前：名前は開発中のものです。 mailto:sage [2007/05/24(木) 20:07:39 ID:KUhBCX3E]: ROM
385 名前：名前は開発中のものです。 mailto:sage [2007/06/04(月) 17:52:58 ID:wXEt1jZx]: ROMはいくらいても0%だろう
386 名前：名前は開発中のものです。 [2007/06/12(火) 16:35:34 ID:KXWIMOSu]: 同人の俺は気にするほどのゲーム作らないからなー。
後から基数ソートやらに書き換えるつもりでSTLのsortでZソートしたけど
どこにも問題ないのでそのままリリースしたよ。めっちゃ富豪的
387 名前：名前は開発中のものです。 mailto:sage [2007/06/12(火) 20:19:56 ID:mHZMnLTI]: >>386
PS2 でも、そんなもんでした。STLport にお任せ。
388 名前：名前は開発中のものです。 mailto:sage [2007/06/18(月) 14:54:09 ID:oOcxT9uX]: コールバックってどういうときに使うんですか？
タスクシステム(というかハンドラオブジェクト)を使う時の場合において適当な例を教えてください
389 名前：名前は開発中のものです。 mailto:sage [2007/06/18(月) 15:00:56 ID:2wNoPL2v]: コールバックする時。

タスクシステムに限らず、メモリの解放を行ってもらうときとか、
進展情報を表示する時によく使うなあ。

とくに前者の場合は、他の開発環境で作ったDLL内でメモリを解放したいときとか。
390 名前：名前は開発中のものです。 mailto:sage [2007/06/18(月) 16:26:41 ID:1gQkyo9F]: >>388
オブザーバーパターンは便利だよ。
たとえば敵を倒したときにそいつのはいた弾をすべて消すとか、誘導弾のつけなおしとか
なれてくるとほとんどこれだけでイベントベースでコードが出来上がる。
391 名前：名前は開発中のものです。 mailto:sage [2007/06/18(月) 20:21:44 ID:nIlBSYV8]: タイミングが判明する場所と、そのとき行いたい処理との間の結合を
疎にしたいとき使います。
ほとんどこれだけでとか関係なし。必要なところへ必要なだけ使うべし。
392 名前：名前は開発中のものです。 mailto:sage [2007/06/19(火) 02:59:21 ID:cFac+yZB]: >>388
C時代のコードを利用するとき。
C++使えるんならほとんどのコールバックが仮想関数で見た目上は消せるだろう。

つまり仮想関数をCで使いたいときにコールバックが出てくる。
393 名前：名前は開発中のものです。 mailto:sage [2007/06/19(火) 05:07:59 ID:AmvqVn7S]: >>392
あとは、スクリプト言語との連携とか。
394 名前：名前は開発中のものです。 [2007/06/22(金) 08:30:52 ID:njuyTnq1]: Xboxのアレは禁断のボゴソートを使ったとしか思えない
395 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 15:30:47 ID:G4eFb+Vh]: >>395
Xboxのアレって何ですか？
396 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 17:18:36 ID:vqNTOWGn]: カルドセプトサーガの事じゃないの？
397 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 20:36:17 ID:OntiNUWq]: そのタイトル名でググってみたが、これは酷いなw
サイコロが奇数と偶数が交互に出るとかw
398 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 22:02:44 ID:qN22ntrp]: >>394
ボゴソートって知らなかった。
ttp://ja.wikipedia.org/wiki/%E3%83%9C%E3%82%B4%E3%82%BD%E3%83%BC%E3%83%88

これはひどいあるごりずむ
399 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 22:21:08 ID:VTeo1nmT]: >>398
これ逆にコーディングの手間がかかるだろｗ
400 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 22:22:42 ID:+XVLd04M]: ＞ボゴソートは、ソートのアルゴリズムの一つ。
＞平均的な計算時間はO(n×n!)で、非常に効率の悪いアルゴリズムとして知られている。
＞安定ソートではない。

最後の一行のオチで吹いたｗ
401 名前：名前は開発中のものです。 mailto:sage [2007/06/22(金) 22:28:33 ID:0YS4QSdj]: ここでボゴソートを使ったゲームを考えるのがゲームプログラマの努・・・ごめん無理
402 名前：名前は開発中のものです。 mailto:sage [2007/06/23(土) 00:06:58 ID:WPiear32]: ボゴソートﾜﾛﾀｗ
403 名前：名前は開発中のものです。 [2007/06/24(日) 05:25:19 ID:zQnoyhbz]: ﾜﾗﾀ
ソートつーか、バラバラに並び変えるアルゴリズムかとｗ
404 名前：名前は開発中のものです。 mailto:sage [2007/06/24(日) 11:16:29 ID:1MtSzEPe]: >>400
安定ソートの意味知ってるのかよ('ω`)
405 名前：名前は開発中のものです。 mailto:sage [2007/06/24(日) 11:33:03 ID:NLW3QANP]: >>404
安定ソートの意味知ってるのかよ('ω`)
406 名前：名前は開発中のものです。 mailto:sage [2007/06/24(日) 11:35:30 ID:rfvCjIOU]: >>404-405
知らないよ！（ﾟДﾟ）
407 名前：名前は開発中のものです。 mailto:sage [2007/06/24(日) 11:54:44 ID:nOj+/xcZ]: >>404-405
知らないよ！（ﾟДﾟ）
408 名前：名前は開発中のものです。 mailto:sage [2007/06/25(月) 03:07:29 ID:qVqBESx6]: えーっと、同じ順位のアイテム同士はソート前の順番を保つ、であってる？
409 名前：名前は開発中のものです。 mailto:sage [2007/06/25(月) 09:30:06 ID:mc9m8oVn]: あってる。
この記事のオチはInfinite monkey theoremだよ。ググレ、笑うから。
410 名前：名前は開発中のものです。 mailto:sage [2007/06/25(月) 10:06:14 ID:U5o2CqSM]: セットで RFC2795 もどーぞ。
www.ietf.org/rfc/rfc2795.txt
411 名前：名前は開発中のものです。 [2007/06/25(月) 20:59:14 ID:NaYhg1aV]: >>394-410
スレ違い
412 名前：名前は開発中のものです。 mailto:sage [2007/06/25(月) 21:35:29 ID:933SMbqm]: >>411
既存のゲームにおけるパターンの一端って事で
413 名前：名前は開発中のものです。 [2007/07/17(火) 22:54:23 ID: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 名前：名前は開発中のものです。 mailto:sage [2007/07/17(火) 23:05:36 ID:oI0Vf9iA]: template <typename T> class IData {
public:
　boost::shared_ptr<T> value;　　//!< 漏れ以外勝手に書き換えんなよ！
};
415 名前：名前は開発中のものです。 mailto:sage [2007/07/17(火) 23:19:26 ID:Mh0Ht4Or]: いくら防衛策を巡らせても書く人の意思でいくらでも変えられるから
そんな事考えるのは無駄だよってことですか
言われてみればそういう気もしますが…(´・ω・`)
416 名前：名前は開発中のものです。 mailto:sage [2007/07/17(火) 23:29:43 ID:9lPCzUGd]: 多重継承にパフォーマンス(速度・容量の両面で)上の弊害は無いが
役割が酷似した基底(インターフェース)同士を多重継承って嫌過ぎだろ。常考。
衝突避けるためにインターフェース設計の段階でお互い調整しなくちゃいかんし
衝突上等ならキャストだらけの汚ねぇコードになる。俺ならコンポジットにする
417 名前：名前は開発中のものです。 mailto:sage [2007/07/17(火) 23:32:47 ID:ecw8MgBR]: いまいち要求が飲みこめんけど、委譲とかプロキシパターンとか
アダプタパターンとか、ありもののパターンで十分間に合いそうな希ガス。

経験上、複雑な仕組みはロクなことがない。
Keep it simple stupidですよ。

苦労して得られる利益が少なくて割が合わないパターンでは？
418 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 00:07:21 ID:xDBgIMCC]: どうも
よく考えたらIDataはインターフェースじゃないっすね…
全く異なる型を同士でコンポジットにしてアクセスも上手く制限できる事って出来るんでしょうか

要求としては
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
です

操作されるデータの実体へのポインタを持つIDataと、それを扱うインターフェースIMutatorに分けたのは一番目のため
多重継承したCData経由でデータを扱うのは2番目を実現するため
データの実体へのポインタであるIDataのvalueメンバをprotectedにし
Mutatorをフレンドにしたのは三番目の為

以上によってゲーム内でのオブジェクトの振舞いは全てIMutator派生クラスのCDataに対しての操作として
書くことが出来て、リソースの確保等のシステム的な動作は外部に一任できる

という意図があったんですが、そんなに複雑ですかいね？
419 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 00:28:49 ID:JHo6PQLB]: ・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事

つまりテンプレートで実装する意味はないよね？
420 名前：名前は開発中のものです。 [2007/07/18(水) 00:37:53 ID:9FpPIZ4u]: >>419
ないね
421 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 00:57:12 ID:IHWjkDA2]: > ・書き込み専用のクラス以外からのアクセスを制限する事

IMutatorを継承すればどんなクラス以外からでもアクセスできる以上、
制限できてるとは言いがたい。

「IMutatorの継承を無闇にするな」と、文書で説明する？
ならば、414でいいでしょ。
422 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 02:48:50 ID:vN51PGaN]: >>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること

「データ」と「ゲーム上のオブジェクト」の違いがよくわかりません。
「動作を～に対して書ける」ってのもよくわかりません。
「～を引数とする関数を書くことができる」ってことでしょうか？
423 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 05:52:53 ID:1k3Xg7ZP]: なんか奇想天外なことになってるのは
＞・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ
424 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 18:10:13 ID:sTmzL7Mk]: class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};

こうすると、CData::valueの型は何になるの？
425 名前：413 mailto:sage [2007/07/18(水) 19:28:34 ID:xDBgIMCC]: >>419,>>420
>つまりテンプレートで実装する意味は無いよね
恐らく既存の構造体を利用するためにこうした筈なんですが
普通にそれらをCDataにスマポで持たせた方がいいじゃんじゃんな気もしてきました

>>421
おっしゃるとおりです
細かいところにとらわれて本質を見失うという悪い例を晒してしまいました…

>>422
>「～を引数とする関数を書くことができる」ってことでしょうか？
そうです
キャラクタの移動や描画の際は、リソースのハンドラを移動クラスや描画クラスに渡すんでなく
CDataを渡すような形で書きたいわけです

>>423
なんかキャラクタのクラスに座標構造体と移動メソッドを定義してたソースを友人に見せると
値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
何か思い違いをしてますか…と問うまでもなく明らかにしてますね

>>424
晒したコードでは見事に多重定義のエラーになりました
実際はそれ避けたり多重定義されたIDataのvalueを内部で扱うためにboost::mplとか使って
さらに複雑な事やってるんですが>>417氏の言ってる事に繋がりますね

とりあえず苦労して作った車輪は最発明どころかガラクタですらないナニカだったというオチでした
もっかい一から作り直してみますm(＿＿)m
426 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 20:55:21 ID: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 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 20:55:52 ID:ux1Fssbs]: >>426
s/メンバ変数のセット/メンバ関数のセット/g
428 名前：名前は開発中のものです。 mailto:sage [2007/07/18(水) 23:49:47 ID:1k3Xg7ZP]: >>425
＞値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの？
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ？
429 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 00:19:41 ID:RaZNmmmq]: > 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが

つかこれ自体間違いだろ。
430 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 00:38:54 ID:PDuVn1ka]: >>429
だよな多分
431 名前：名前は開発中のものです。 [2007/07/19(木) 05:21:01 ID:5YEt12VO]: getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか（C++ならfriend？）

それ以上ってコストかかりすぎねえ？
432 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 11:40:10 ID:LxxDZCLh]: 少人数・小規模製作でアクセス制限も糞もないわな
433 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 15:01:29 ID:3ArgKadV]: 少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。

そういう場合は、アクセス権は考えといて損はねーですがよ。
434 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 18:50:40 ID:TacCeKvZ]: アクセス権？になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない
435 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 18:59:00 ID:ajveBJeZ]: とりあえず理由を
436 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 19:27:00 ID:3ArgKadV]: なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ？
437 名前：436 mailto:sage [2007/07/19(木) 19:27:51 ID:3ArgKadV]: 変な日本語になった

正しくは、
なんでファイルのパーミッションの話になってるんだ
>>433のアクセス権って、クラスのメンバーに対することで、
>>432のアクセス制限ってのもそのことだろ？
438 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 19:39:53 ID:/RFbeqQb]: 「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか＞ファイルシステムの例え話

個人管理のLinuxなんかだと、最初からrootでログインして使う人もいるくらいだから
それはそれで別に当人の自由だと思う。

要はアクセス権限を分ける方がトクか分けない方がトクかは
ケースバイケースで判断すればいいってことだけど
439 名前：名前は開発中のものです。 mailto:sage [2007/07/19(木) 20:12:33 ID:TacCeKvZ]: ＞なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん
440 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 12:39:13 ID:vUDuhb3O]: スレタイを百回声に出して読んでくれ
441 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 12:40:51 ID:vUDuhb3O]: ついでに二人とも正座な
442 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 21:52:02 ID:+3gqdIHH]: 難しく考えすぎ。

他のオブジェクトにアクセスして欲しくないメンバは
クラスの中に隠蔽して、プライベートメンバにしておくのがセオリーでは。
アクセス権ってのは本来そうやってコントロールする。

外からオブジェクトにアクセスできるようにしておきながら
アクセスできないように制限する仕組みを作るってのがナンセンス。
443 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 22:07:32 ID:lyxTTGt6]: 「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難
444 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 22:32:40 ID:+3gqdIHH]: 動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。
445 名前：名前は開発中のものです。 mailto:sage [2007/07/20(金) 22:52:28 ID:+3gqdIHH]: 本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。

例えばnoncopyableはオブジェクトのコピーを禁止するクラス。
こんなレベルのものでも有用さが認められればboostに仲間入りできる。
www.kmonos.net/alang/boost/classes/noncopyable.html

でも今現在boostにアクセス権制御のクラスがないってことは、
需要がないってことでは？

まずはプライベートメンバを使ったシンプルな隠蔽によるアクセス制御で
どこまでできるのか突き詰めてみた方がいいでしょ。
今のところ自分はそれで困ったことはないけどね…。
446 名前：名前は開発中のものです。 mailto:sage [2007/07/21(土) 00:49:20 ID:DMrsrXyJ]: ナンセンス。この一語に尽きる。
447 名前：名前は開発中のものです。 mailto:sage [2007/07/21(土) 01:16:04 ID:oWQ5iQEX]: progress_displayがあるのにそんなこと言われても説得力無いなぁ

動的にアクセス権決めるならgetter,setterを隠蔽してfunction使ってアクセス権を与えたいクラスに
そのgetter,setterを与えてやるって方法もあるけど
functionは1個で40bytes近く食う割と重たい(？)オブジェクトだから無茶かな、無茶だな
448 名前：名前は開発中のものです。 [2007/07/21(土) 03:00:31 ID:DMrsrXyJ]: 動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ？RMIとかそーいった話の流れ方向での

静的だと外側の構造も知らん一クラスごときが誰に使われるのが良いだ悪いだ
決めるとか何いい気になってんだって話だ

>>443
＞静的に操作するのは困難
困難どうこうより、そのポリシーを決める根拠をどこにも求められないということだよ
適当に決めてしまえば後で直せなくなる
根拠がどこにもないから
449 名前：名前は開発中のものです。 mailto:sage [2007/07/22(日) 02:55:07 ID:/VC165Eo]: >>443
インターフェースを多重継承して、必要な時・相手にアップキャストしたものを渡せば。
450 名前：名前は開発中のものです。 mailto:sage [2007/07/22(日) 03:36:44 ID:jrExVTdK]: 簡単な具体例も挙げてくださいお願いします
451 名前：名前は開発中のものです。 mailto:sage [2007/07/22(日) 13:24:51 ID:/VC165Eo]: >>450
struct IFoo { virtual Vec3 getPos(); const = 0; };
struct IBar { virtual setPos(Vec3 const& pos) = 0; };
class CPlayer : IFoo, IBar { ... };

f1(IFoo&);
f2(IBar&);

CPlayer player;
f1(player); // f1には getPos() しかさせない
f2(player); // f2には setPos() でメンバ変数書き換えを許可
452 名前：名前は開発中のものです。 mailto:sage [2007/07/22(日) 15:08:54 ID:PSHVXCKb]: >>447
functionって40byteも食うの？
その半分くらいですみそうなんだけどな。
453 名前：名前は開発中のものです。 mailto:sage [2007/07/22(日) 18:59:44 ID:jrExVTdK]: なるほど、呼び出す側にインターフェースを渡すんですね
参考になりましたありがとうございます。
454 名前：名前は開発中のものです。 mailto:sage [2007/08/05(日) 01:30:04 ID:CiKwXSKt]: boost::functionって便利だけどむちゃくちゃヒープが汚くなりそう
455 名前：名前は開発中のものです。 mailto:sage [2007/08/05(日) 07:10:10 ID:4IAfjfpf]: >>454
小さなオブジェクトが多数 new されそうって意味？　気にしなさんな。
456 名前：名前は開発中のものです。 mailto:sage [2007/08/05(日) 07:37:18 ID:CiKwXSKt]: まあ、それが気になって使ってない、という訳じゃないけどねえ。
アロケータ作れば何とかなるだろうし。
457 名前：名前は開発中のものです。 [2007/08/05(日) 20:35:16 ID:ki20ixME]: javaでTCBを使いたいんだけど、どうしてる？
458 名前：名前は開発中のものです。 mailto:sage [2007/08/05(日) 20:46:45 ID:4IAfjfpf]: >>457
ふつーにメンバ変数使えばいいだけでは？　Task Control Block なんてのは、アセンブリ時代の名残だから、
C++, Java あたりでは使わんでしょ。
459 名前：名前は開発中のものです。 [2007/08/06(月) 00:04:42 ID:Mz0XA0lP]: ゲームのデータを独自のフォーマットとかにする場合にヘッダを用意する？
460 名前：457 [2007/08/06(月) 00:40:04 ID:wjb80OI1]: ueno.cool.ne.jp/dinna/topic/task.htm
こんな感じに組みたいんだけど、javaには関数ポインタがないので、引っかかり中。
461 名前：名前は開発中のものです。 mailto:sage [2007/08/06(月) 00:44:36 ID:N/EWx1nS]: >>460
まじめに勉強したら？
462 名前：名前は開発中のものです。 mailto:sage [2007/08/06(月) 00:45:37 ID:N/EWx1nS]: というかあからさますぎて夜釣りに思えてきた
463 名前：名前は開発中のものです。 mailto:sage [2007/08/06(月) 02:03:36 ID:dDj8AjaH]: TCBと言えばRTOSなので
ここはeCosに実装されたwabaを紹介してやるのが筋だろうか
464 名前：名前は開発中のものです。 mailto:sage [2007/08/06(月) 03:43:57 ID:r8MqGT/t]: ppc arm super wabaなら・・・
465 名前：名前は開発中のものです。 mailto:sage [2007/08/06(月) 07:16:51 ID:R+5scQVe]: >>460
Java だとインターフェースもしくは抽象基底クラス使う。
466 名前：457,460 [2007/08/06(月) 22:38:48 ID:dCjdYchV]: aを規定クラスにしたb1タスク
aを規定クラスにしたb2タスク
b1、b2タスクが混在したリストを作成したい。
C/C++なんかだと、関数ポインタnextなどにタスクをつなげてゆけるところだが・・・
javaだと関数ポインタがないので、配列にしてインデックス参照にするしかないのだろうか？
インデックス参照だと、個々のタスクごとに属性を割り振って、別々に読み出すか32bit以内に押し込むかなどして値を管理し、switchで分岐
して実行する記述が必要・・・。
C++なら多重継承があるので、b1からb2にたどることもも可能だが、javaには多重継承はないし・・・。
インターフェースは同じインプリメントを保障してくれるだけど、結局タスク切り替えのロジックが必要になるし・・・。
関数ポインタに比べて、これだと積極的に使うにはオーバーヘッドが気になるのと、記述が煩雑でプログラム的にCより退化しているように感じてしまう。
（今はリスト構造にせず、配列でタスクリストを持つ方向性で考慮中・・）
467 名前：457,460 [2007/08/06(月) 22:41:30 ID:dCjdYchV]: だれか経験豊かなjavaプログラマた通りかかったりしないかなぁ。
468 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 00:03:46 ID:ziyaQFb3]: Vectorじゃだめなのか
469 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 00:17:53 ID:2nrPyfF8]: やはり釣りだったか
470 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 00:42:53 ID:lyE3j1c/]: HSPでOOPをやろうとするのと同じくらい馬鹿げてるな
471 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 01:25:29 ID:/sDbVbxZ]: >>466
ぐちゃぐちゃ言ってないで書いてみろ。あんまりにも考察がめちゃくちゃで
どこから突っ込んでいいのかわからん。ソース晒してみれば突っ込みも入れやすい。
472 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 01:55:24 ID:sukzLC0P]: >>466
日本語でおｋ
473 名前：名前は開発中のものです。 [2007/08/07(火) 03:33:11 ID:jZSDWWPE]: >>466
参照使え馬鹿
474 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 03:37:03 ID:Qoe4Y4zA]: なんでみんな冷たいんだｗｗｗ
475 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 06:44:09 ID:vUw1LN3Q]: >>468
LinkedList の方が。
476 名前：457,460,468 [2007/08/07(火) 07:55:20 ID:8/4fXdca]: void (*func) ();
これのjavaでの代用法が知りたい。
477 名前：457,460,468 [2007/08/07(火) 08:07:53 ID:8/4fXdca]: LinkedList ....
Thanks! >> 475
478 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 08:09:00 ID:/sDbVbxZ]: >>476
java.lang.Runnable func;
479 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 08:24:51 ID:88OVU+XC]: >>466
aを要素にとるコンテナを宣言して
それにb1インスタンスだのb2インスタンスだのを加え、
コンテナを走査して処理メソッドを順に呼び出せばいいだけの話。

データ構造だとかクラス設計だとかいうレベルじゃない。
単にプログラミング言語の勉強が足りていないだけ。
それにお前は多重継承を激しく誤解している。出直して来い。
480 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 10:39:17 ID:98Sz9x7X]: なんかタスクってGoToやってるような雰囲気があるな
481 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 10:48:42 ID:TDGAxW6A]: >>476
>>460では関数ポインタ使ってなくね？
482 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 14:27:28 ID:lyE3j1c/]: まぁvtableは関数ポインタみたいなもんだけどな。
483 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 14:28:52 ID:gmxLaOKz]: >>478
Swingでやってハマるとかｗ
関数ポインタに直感的に一番近いのはjdk7までお預けだな。

javascriptならそのまま
(function(num){ print(num);})(100); //-> 100
だが。
484 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 15:06:05 ID:2nrPyfF8]: >>483
日本語でおけ
485 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 19:51:36 ID:LOGzBd/R]: 自分が話理解出来てないだけなのに日本語でｒｙとか言ってる奴増えたよね。
486 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 20:52:36 ID:2nrPyfF8]: >>485
>Swingでやってハマるとか

理解できないのはこの部分だ
487 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 23:28:41 ID:rZkCIKw7]: Swingがスレッドセーフではないって話かな。

もしそうなら >478 が言いたいのはRunnableのインターフェースだけを
借りることだろうから話が飛躍してるな。
488 名前：名前は開発中のものです。 mailto:sage [2007/08/07(火) 23:51:16 ID:vUw1LN3Q]: >>476
だから抽象基底クラスかインターフェース使えと。下のサンプルコードは C++ だが、Java でも
ほとんど変わらん。

#include <boost/foreach.hpp>
#include <boost/ptr_container/ptr_list.hpp>

struct ITask {
　　virtual ~ITask() {}
　　virtual void exec() = 0;
　　virtual void draw() const = 0;
};

class TaskManager {
public:
　　void exec() { BOOST_FOREACH(ITask& task, m_tasks) task.exec(); }
　　void draw() const { BOOST_FOREACH(ITask const& task, m_tasks) task.draw(); }
private:
　　boost::ptr_list<ITask> m_tasks;
};
489 名前：名前は開発中のものです。 mailto:sage [2007/08/08(水) 00:01:44 ID:2nrPyfF8]: >>488
優しいな
490 名前：名前は開発中のものです。 mailto:sage [2007/08/08(水) 07:33:12 ID:71C/M+UG]: たったこれだけのことなのに
さも凄まじいシステムであるかのように
タスクシステムと言う人の気がしれない
491 名前：名前は開発中のものです。 mailto:sage [2007/08/08(水) 07:48:40 ID:4PM0J5aw]: >>490
歴史を勉強しましょう
492 名前：488 mailto:sage [2007/08/08(水) 07:51:26 ID:obrNCieZ]: >>490
同意。

アセンブリ言語でハードコーディングしていた時代に初めて見たら「やるな」と思うが、
今時だとふつー過ぎて何も言うことがないよね。UNIX V6 のころのデバドラも、既に
こんな作りだし。

自分でコード書くのもいいけど、もっとコード読もうよ、と思う。
493 名前：名前は開発中のものです。 mailto:sage [2007/08/08(水) 07:53:43 ID:HMa+110c]: 今とは比較にならない制限の厳しさの中で
TCBを弄り回してた時代のことを知らないんだろね
494 名前：名前は開発中のものです。 mailto:sage [2007/08/08(水) 08:21:56 ID:XmcrCIW0]: そういう話題は以下のスレでやってくれ

タスクシステム総合スレ
pc11.2ch.net/test/read.cgi/gamedev/1173708588/
495 名前：457,460,466,476 [2007/08/09(木) 01:21:26 ID:WI6u6LTt]: できた。
抽象基底クラスは知っていたが、
仕様上、基底クラスから上位のクラスをたどる必要があったので、
関数ポインタ云々といっていたのだが・・
キャストすればよいだけだった。
javaにはポインタの概念がないから、
javaのクラスは当然キャストできない、というような誤解があったので。
496 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 01:24:51 ID:Tm6LW0Jp]: >>495
それなんか設計がおかしくないか？
みんなの意見無視ってところか
497 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 02:27:45 ID:RcnrWFRi]: ＞仕様上、基底クラスから上位のクラスをたどる必要があったので、
そんな仕様にするのが悪い。
第一、抽象基底クラスを知っているのならば
そんなところで困ったりしない。
498 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 02:50:07 ID:yVPi3RJq]: 初心者には冷たいもんだな
499 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 03:14:21 ID:v8CPCZuZ]: というか言語仕様勉強しろ
500 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 04:12:56 ID:k08h5JG9]: キャストってw
ポリモフィズムをカケラも理解しとらんじゃないか
501 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 04:46:19 ID:BskRNsfr]: 自分から質問してきたくせに
まともな意見すら無視するような勉強不足君は
鮮やかに放置して、次の話題ドゾー
502 名前：名前は開発中のものです。 mailto:sage [2007/08/09(木) 05:27:24 ID:nQyaGvDb]: まともな意見を無視するのと勉強不足なのは関係ないと思うぞｗ
質問者はどちらの属性も持ってるけど
503 名前：457,460,466,476,495 [2007/08/10(金) 20:04:16 ID:aK9bbQO3]: 失礼。

>>488
解決のヒントになりました。
ただboostライブラリはjavaにはないような気がします。

>>468
Vectorの案内が最初の解決のヒントになりました。
504 名前：名前は開発中のものです。 mailto:sage [2007/08/11(土) 20:49:07 ID:AcYB8hIq]: >>503
さんざん情報貰ったんだから、せめてソース晒して恩返ししてみないか？
505 名前：名前は開発中のものです。 mailto:sage [2007/08/17(金) 01:53:51 ID:7sSY46ad]: JavaSEでVectorつかってそーだな・・・
506 名前：名前は開発中のものです。 mailto:sage [2007/08/21(火) 16:35:31 ID:/oULNmRu]: 質問すまそん。DXライブラリ＆VC++でゲーム製作してます。

例えばRPGで、キャラデータ・アイテムデータ・フラグおよび
ゲーム内システムデータ（ゲーム世界での日付とか）は、
それぞれグローバルなデータクラスにしてるんですが、
もうちっとスマートな設計の仕方はないでしょうか？

ほぼ全てのインスタンスから参照するデータ（例えばフラグとか）って、
いちいち参照やポインターで格納させるよりか、データクラスとしてグローバルに
展開してメソッド経由でアクセスさせたほうがいいような気がするど素人なんですが、
こんな俺はオブジェクト指向として根本的に間違ってますね？
507 名前：名前は開発中のものです。 mailto:sage [2007/08/21(火) 18:54:06 ID:/OCncB5N]: ちゃんと管理できるなら問題ない
508 名前：名前は開発中のものです。 mailto:sage [2007/08/21(火) 19:55:25 ID:LQCVNOKZ]: >>506
>>507に同意
オブジェクト指向をしたいのか、ゲームを作りたいのか。
書き方に明確な規則やルールがあれば、それだけでいいと思うけどね。

でも自分が「オブジェクト指向的」に組むなら、その辺の情報はグローバルにはしないと思う。
必ずシステム内で生成する。何故なら、ゲームシステム≠ゲームの世界と考えてるから。

１．ゲームシステム＝ゲームの中の宇宙を作る（ゲームシステム＝プログラム本体）
２．宇宙の中に惑星を一個作る。（ゲーム世界（日付等含む））
３．ゲームの世界の中に、登場人物やアイテムを作る。（キャラクターデータ、アイテムデータ）
４、登場人物とアイテムは、状態を所有している。（フラグ）

単純に現実に沿って状態を作る（これがRPG向きか？と言われると、そうではないけど）
データは必ず1→2→3→4の順にアクセスする。面倒くさいけど、一応これにも利点がある。
・ゲーム内での登場人物の役割を切り替えやすい。
・同時に複数キャラが操られても破綻しにくい。（マルチプレイさせやすい）
・同様に、ゲーム世界以下の要素は増やすのが比較的容易。

まとめて言えば、人や物、物事の取り扱いを現実と同じようにできるってことね。
最初に戻ると、規則があるなら君の好きで良いんじゃないってことで。
509 名前：名前は開発中のものです。 mailto:sage [2007/08/22(水) 02:49:01 ID:xHfctKqh]: >>505
標準ライブラリが互換性のために未だに使いまくってるんだが・・・。
んで使い勝手悪いからいい加減JCFに移行しろと叩かれてるじゃないか。
510 名前：名前は開発中のものです。 mailto:sage [2007/08/22(水) 10:20:41 ID:lSyOGrel]: Universe.MilkyWay.SolarSystem.Planets.Earth.Enabled = false;
511 名前：名前は開発中のものです。 mailto:sage [2007/08/22(水) 21:45:27 ID:HTZJHbeS]: >>508
> 単純に現実に沿って状態を作る（これがRPG向きか？と言われると、そうではないけど）
単一システムで作るのは、結構つらいなぁ。

俺だと RPG はフィールド＆シナリオ、戦闘、デモシーンでシステム完全に切り離して
作っちゃうけど。どーしてもフィールドからシームレスに戦闘に入りたいと言われたら
考えるが、工数は開発もデバッグも倍かさむよって感じ。
512 名前：名前は開発中のものです。 mailto:sage [2007/08/22(水) 21:58:56 ID:9DW3Phyd]: >>506が心配してるようなのって構造化手法の方の話で
オブジェクト指向とはあんまり関係ない気がする
オブジェクト指向言語は結局構造化手法の流れを汲んでるから関係あるっちゃあるんだけど
「オブジェクト指向的」に批判されることはないと思うんよ
513 名前：名前は開発中のものです。 mailto:sage [2007/08/22(水) 22:26:25 ID:9DW3Phyd]: >>508はこの方針でゲーム作ってなんかあったらここへ相談しにきてね
514 名前：名前は開発中のものです。 mailto:sage [2007/08/23(木) 00:15:28 ID:mSgl7P3T]: >>60が参考になるんじゃね
515 名前：名前は開発中のものです。 mailto:sage [2007/08/24(金) 15:43:24 ID:C1/M3//R]: >>513
>>510みたいなことは流石にやってないけど、マップが複数面あって
自由にキャラクターを選べるのを作ってるから、今のやり方で全く問題なかったりするぜ！
516 名前：名前は開発中のものです。 [2007/09/01(土) 13:35:04 ID:+CS1vDDV]: >>510おれもそんな感じだww
517 名前：名前は開発中のものです。 mailto:sage [2007/09/01(土) 15:26:53 ID:AAlSvZp8]: >>516
お前って奴は…
518 名前：名前は開発中のものです。 mailto:sage [2007/09/01(土) 18:53:13 ID:pEzsrlB5]: チラウラだが .NETの自動生成コードとか見ると
クラス名がネームスペース入りのフルネームで書かれてて
>>510と比べてもあまり遜色ないくらい長ったらしい記述になってる
519 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 18:50:24 ID:pkJ0HJ1y]: >>510はどこまでが名前空間でどこからがコレクションなんだろ
520 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 18:56:19 ID:l4kjvmoQ]: Universe.、までが宇宙空間
521 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 20:58:24 ID:nm3JiNC1]: Planetsまでじゃないのか
522 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 21:43:06 ID:l4kjvmoQ]: C#とかだと区切り記号が全部ピリオドだから分かりにくいよなあ
523 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 22:51:36 ID:4m5q0iOi]: 俺ならPlanetsは入らないな。
Universe.MilkyWay.SolarSystem.Earth

しかし、こんな話題しかないものか。
524 名前：名前は開発中のものです。 mailto:sage [2007/09/03(月) 23:01:33 ID:nm3JiNC1]: いいんじゃない、超光速星間航行を多用するスペースオペラ的ゲームのデータ構造。
525 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 00:01:23 ID:aU+sltFh]: >>522
そんなこと言いだしたらjavaのエンクロージング型の完全修飾名は恐ろしいことになる。
526 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 00:51:30 ID:SZHcTWC/]: 外から内部クラスをアクセスすることはほとんどないんじゃね?
527 名前：名前は開発中のものです。 [2007/09/04(火) 01:36:58 ID:aBG3sZkW]: >>522
Delphiはわかりにくいと申すか
528 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 01:47:09 ID:h5r4WGWI]: まあDelphiもC#も、同じヘルスバーグ氏設計の言語だからな
俺は氏の思想は好きだが
529 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 09:17:06 ID:/fq60VcD]: どっちもIDEで使うための言語だからそんなに問題にならないでしょ
530 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 14:17:11 ID:A5VD8Kop]: C#はCLRで使うための言語だろ。
VSがIDEなだけで。
531 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 17:20:53 ID:/fq60VcD]: 独立して使えるように体裁は整えてあるし確かにそうなんだけど
#regionとかpartialとかIDE向けの機能があるのは確か

www.atmarkit.co.jp/fdotnet/insiderseye/20060215cscommunity/cscommunity_03.html
>Q.C# 3.0では、型推論によって読むのが難しいコードになってしまうのではないか？
>A.Visual StudioのIDEを強化すればおｋ

さすがにスレ違いだなすまん
532 名前：名前は開発中のものです。 mailto:sage [2007/09/04(火) 18:32:28 ID:1MQtcsKR]: まあ、確かに動的な型変換と型推論は型の決め方が違うから読み辛い。
というかC#は既存言語の枯れたパラダイム
てんこもりにしただけのくせに信者が騒ぎだすんだろうなぁw
533 名前：名前は開発中のものです。 mailto:sage [2007/09/05(水) 22:29:15 ID:wushZy2l]: アンチうぜぇ
534 名前：名前は開発中のものです。 mailto:sage [2007/09/06(木) 00:13:48 ID:XDEo8NLL]: 信者うぜー
535 名前：名前は開発中のものです。 mailto:sage [2007/09/06(木) 01:04:58 ID:ojjbKURb]: 突然何の脈絡もなく言語叩きをしだす馬鹿は放置して次の話題ﾄﾞｿﾞｰ
536 名前：名前は開発中のものです。 [2007/09/07(金) 00:33:06 ID:B51b23c5]: JAVAとかC#とかってキャストないよね

タスクシステムのワーク領域のキャストってどうやるのかな
537 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 00:44:42 ID:GaWvLQQX]: >536
今どきそんなC時代の古典的「タスクシステム」に無理矢理合わせようとしないのが正解。
538 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 00:54:28 ID:qKvVhzB0]: >>536
だからインターフェース継承しろと。どうせメモリ管理は GC 入ってるんだし。
539 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 09:56:16 ID:+KS6LJ+F]: キャスト自体はあるだろと

まぁC++でもそんなコードかいてたら殴り倒すけど
540 名前：名前は開発中のものです。 [2007/09/07(金) 10:04:18 ID:puv664XK]: >>539

シューティングゲームプログラミング
松浦健一郎 (著)

この本ではC++でワーク領域のキャストしてたけど、殴るの？
541 名前：名前は開発中のものです。 [2007/09/07(金) 10:07:03 ID:ODKwq4Ib]: ワーク領域のキャスト（笑）
542 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 11:36:49 ID:+KS6LJ+F]: それ悪い見本だろ
543 名前：名前は開発中のものです。 [2007/09/07(金) 12:02:42 ID:xHXwrHzM]: >>542
普通に使ってたよ
本を書いてる人を殴れる程、出来るプログラマーなの？あなたは
544 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 12:51:19 ID:6U+LdAPY]: 松浦健一郎 (著)、じゃなくて
松浦健一郎 (笑)の間違いだろ。
545 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 13:28:52 ID:43uHszUC]: MAKKENは殴ってよい
546 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 13:54:05 ID:NUmtK/nu]: >>540の本って継承知らない程度の初心者向けの本ってところか？
継承使わずにやるやり方にページ割くくらいならさわり程度でも継承教えたほうがためになりそうだが・・・
547 名前：名前は開発中のものです。 [2007/09/07(金) 16:11:07 ID:g09BD/TG]: >>543
>>542が出来るプログラマーかどうかはわからんが、
基本的に日本だと本を出す奴ってのは3流だから
とりあえず本出してる人すごいって認識は改めたほうがいい。
548 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 16:48:36 ID:HXEpQNDZ]: ３流は本すら出せんだろ
549 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 16:51:44 ID:wO5yXJcP]: >>547
三行目に同意
俺も高校まではそういうステレオタイプを持ってた
550 名前：名前は開発中のものです。 mailto:sage [2007/09/07(金) 17:54:50 ID:VwzOSVjv]: じゃあ「俺よりは凄い」で。
551 名前：名前は開発中のものです。 [2007/09/07(金) 20:37:04 ID:B51b23c5]: ここは自称凄い人がたくさんいるスレですね
552 名前：名前は開発中のものです。 mailto:sage [2007/09/08(土) 00:42:34 ID:hAtUkBFn]: >>546
一応継承は使ってるみたいだよ
new deleteのオーバロードも使ってるし

だから単に継承を使ったやり方をしらないだけじゃね
553 名前：名前は開発中のものです。 mailto:sage [2007/09/08(土) 02:39:33 ID:RITYgY6W]: 最近のライターがコード書けんのは確かだな。
554 名前：名前は開発中のものです。 mailto:sage [2007/09/08(土) 07:47:53 ID:bNPXbGtI]: はいはいスレ違い
555 名前：名前は開発中のものです。 mailto:sage [2007/09/13(木) 22:14:56 ID:1Bt3Jrj9]: "Those Who Can't Do, Teach"という言葉があってだな。

シューティングの本？
同人シュー作者の俺がそのうち書いてボコボコにしてやんよ

　　　　　　　　　　　∧＿∧
　　　　　　　つ≡つ);:)ω・）.,，';
　　＿|￣￣||≡つ＝つ　 )
　／旦|――||/／／|　　　＼
　|￣￣￣￣￣|￣| . |∪￣＼_)
　|＿＿＿＿＿|三|／
556 名前：名前は開発中のものです。 mailto:sage [2007/09/13(木) 22:42:21 ID:sAjH+7xy]: >>553
正直、本を書いてもあまり儲からないんだよな……。前に技術書書いたことがあるんだが
印税8%で初版3000部とかだったから、時間単価考えたらコード書いてた方が遥かにマシ
だった。

もう少し幅広く売れる本とか、時間かけずに書けるとか、その後の仕事受注につながる類の
ヤツなら良いんだが。
557 名前：名前は開発中のものです。 mailto:sage [2007/09/13(木) 22:44:13 ID:p9GEmztQ]: 何系の本なの？ゲーム系？ハード系？
それとも普通の言語系？
558 名前：名前は開発中のものです。 mailto:sage [2007/09/13(木) 23:27:43 ID:sAjH+7xy]: >>557
ネットワーク系。だいぶ前だけど、当時は翻訳やら執筆やらイロイロやってた。
今じゃすっかりコンサル稼業で、趣味でしかコードかけない人生だけどな……。
559 名前：名前は開発中のものです。 mailto:sage [2007/09/14(金) 00:00:01 ID:qAC7e6UH]: 技術書って印税8%も来るのか。
560 名前：名前は開発中のものです。 mailto:sage [2007/09/14(金) 01:56:40 ID:kBeEhHlB]: >>559
でも 1 冊 2,000 円 x 8% x 3000 冊だと 48 万だぜ。駆け出しのプログラマだった頃は
実質 1.5 ヶ月かけても割に合ったけど、もうダメだ。金以外に何か目的がないと
やってられんよ。
561 名前：名前は開発中のものです。 mailto:sage [2007/09/14(金) 04:58:49 ID:CTgFkt8N]: やねうらおさんですか？
562 名前：名前は開発中のものです。 [2007/09/15(土) 18:37:54 ID:odGWNMQb]: けっこう、計算するとシビアな値段だな・・・
人生掛けてまでやることじゃない
クソ本あろうとしったことか！

あ、俺？俺は、情報商材にして、単価上げて(ﾟДﾟ)ｳﾏー
563 名前：名前は開発中のものです。 mailto:sage [2007/09/15(土) 20:05:14 ID:5hbSwr+P]: 自分の備蓄禄だと思えば良いじゃない。

何ページで執筆に何カ月かけたか知らんが、
コード書けない人間なら数こなせば良い金になるな。
eclipse本なんてコード書かなくても良いしソフトの新版出る度に改定するから副業にはちょうど良いじゃないか。
デザインパターン本なんて同じ内容なのに言語ごとにあるぞ。

コード書いて食ってる人間に本なんて書いてる暇があるかは知らんが・・・。
564 名前：名前は開発中のものです。 mailto:sage [2007/09/15(土) 20:15:34 ID:zE0h51TJ]: 日本の場合、コード書いても食えない人間ばかりだろ。
だから低レベルな本しか出てない。
そんな本ばかりだから若い人が育たない。
で、その若い人がコードで食えないから、さらに劣化した本を書くというスパイラル。
565 名前：名前は開発中のものです。 mailto:sage [2007/09/15(土) 20:27:26 ID:lBqIBG3l]: と、コードを書けもしない人間が申しております
566 名前：名前は開発中のものです。 mailto:sage [2007/09/15(土) 21:30:05 ID:kmdFdmdy]: >>564
> 日本の場合、コード書いても食えない人間ばかりだろ。
というか、単価の高いプログラミング仕事がほとんどない。

大手ゲームメーカーでリードプログラマやるより、中小の基幹システム改修
案件の SE やってた方が全然収入がいいという。技術的にもプロジェクト運営の
面でも、ゲーム屋の方が大変なんだが。
567 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 03:07:48 ID:YcEkQAYx]: しょせん日本のマは末端の土方
568 名前：名前は開発中のものです。 [2007/09/16(日) 07:52:57 ID:hBA8iHMq]: プログラマなんて、IT土方だからな
569 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 09:22:16 ID:bdw4UY6n]: >>568
GoogleとかMSだと給料高いけどな。現地ではなく日本採用でも。
570 名前：名前は開発中のものです。 [2007/09/16(日) 09:44:24 ID:hBA8iHMq]: >>569
プログラムだけできるだけじゃ、入れないところじゃねーか
571 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 11:01:46 ID:5DEnzRu4]: >>569
M$はともかくgoogleは給料安いんでないの？福利厚生はともかく給料は。
572 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 12:12:44 ID:bdw4UY6n]: >>571
Google は給与水準公開してないから情報限られるけど、俺が中の人から
聞いた話だと十分高いと思った。

それより株式公開前にストックオプション貰ってた連中は、上場と同時に
億万長者の仲間入りしちゃってるから、それと比べると給与はどうでも
良いっつー話らしいが。
573 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 19:28:45 ID:OIlosS2z]: 絶望した。上場したてのGoogle株を買って、任天堂に乗り換えれば
たった3年で20倍になってる事実に絶望した。
絶対うまいこと乗れたギーク系投機家がどこかにいるはず。
574 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 20:24:04 ID:JalQ3AgQ]: お前ら良いなgoogleが上場とか、俺の頃はまだyahooすらなかった。
CEREN vs NCSAのhttpd戦争終結後くらいか・・・。
575 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 20:58:05 ID:uZJ+v8CM]: みんな、UMLとかdoxygenとか使ってる？
576 名前：名前は開発中のものです。 mailto:sage [2007/09/16(日) 23:32:07 ID:cz5uVFrl]: どっちもつかってます
577 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 01:15:23 ID:YnotUqm6]: javaだからdoc toolはデフォだな。
578 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 01:50:53 ID:VnVYOx3U]: 色気出してプリプロセッサ・テンプレートメタプログラミングしてると
doxygenが酔ってくれるから困る
579 名前：名前は開発中のものです。 [2007/09/17(月) 10:46:54 ID:4TcSZ3vD]: doxygenはマニュアル作ってくれる事もいいんだけど、コメントの規格を統一できるのもいいよな

でも、心がけてくれないチーム員もいるんだよなあ
580 名前：名前は開発中のものです。 [2007/09/17(月) 11:33:01 ID:wCNRu3Bd]: ■□■□■□■□■□■□■□■□■□■□■□■□■□■ □■□■
　　　　　　　　――――Click Click Click――――
それは、一番クリックした国が優勝するバカバカしくも熱いゲーム！
2ch全板から力を結集して日本を１位にしよう！日本は過去に8勝（世界最多）しています。
めざすは、台湾の6連勝記録を打ち破ること！
現在日本は３連勝中だけど、猛加速のハンガリーに昨夜逆転されてしまいました。
日本のツールはとても優秀ですが、参加人数が足りません！！
逆転するには、最低でもあと100台のPCが必要です。
専用ツールを落として、ブラウザを起動しておいてくれるだけでOKです！
放置できるので、寝ながら日本の戦力になることができます！
どうか力を貸してください！

【日本２位】一番クリックした国が優勝【版画ｋｓk】
wwwww.2ch.net/test/read.cgi/news4vip/1189932725/l50

※オリジナルのゲーム制作チームがあります。ぜひ力を貸してください。
581 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 11:46:33 ID:gzVOF+3o]: doxygen で生成したドキュメントは使ってないが、doxygen 用にコメントは
書いてる。(javadoc 形式というべきか)

> コメントの規格を統一できるのもいいよな
目的はこっち。
582 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 12:30:12 ID:GfvjK68d]: 実際のチーム開発の現場って、
コメントだけでなく、ファイル名とかクラス名とか変数名とかのコンベンションも
やっぱ決められてるもんなの？
583 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 12:33:20 ID:gzVOF+3o]: >>582
当然。

ただ汎用ライブラリを持ってくることもあるから、そっちとこっちで
規約が違って一部混在することはある。たとえば STL と DirectX
だと名づけ方大分違うしな。
584 名前：名前は開発中のものです。 [2007/09/17(月) 15:33:27 ID:GfeYD8ac]: >>575
Delphi使いなんで、Togetherで UMLはコードから自動生成だぜ～（嘘、使いません

ドキュメント生成ツールは、日本語対応したものがなくて、使ってない orz
585 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 19:51:10 ID:W3g8XPDv]: doxgenは日本語出せたよ、Delphiに対応してない気が下が
586 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 23:45:15 ID:/t9Slj66]: >UMLはコードから自動生成だぜ
普通設計してからコード書かないか？
UMLの仕様上は確かにcode2UMLもUML2codeも相互運用可能だけど・・・。
587 名前：名前は開発中のものです。 mailto:sage [2007/09/17(月) 23:57:57 ID:zeWn8DxN]: >>586
ネタにマジ(ry

> UMLの仕様上は確かにcode2UMLもUML2codeも相互運用可能だけど・・・。
C++ は code generation に向かない言語だなぁとおもうよ。

集約・コンポジション・関連の区別とかつけにくいし、boost::scoped_ptr で pimpl イディオム
使ってる場合とか、マジメに piml クラスもクラス図に入れると煩雑になりすぎ。

私は設計段階で主要クラスだけ図に書き出して、あとはコードでって感じ。
クラス図は必要があれば更新するけど、あくまでコードが第一の文書に
しちゃってる。
588 名前：名前は開発中のものです。 mailto:sage [2007/09/18(火) 00:16:16 ID:0DwxQSyZ]: UMLはドキュメントとしてはいいが、コードにそのまま適用されるものではない
というのは比較的お堅い業務アプリでの常識なんだが
柔軟性が求められるゲーム開発ならなおのことじゃね？

組込み系が今突撃中
589 名前：名前は開発中のものです。 mailto:sage [2007/09/18(火) 00:22:12 ID:3aYPJasO]: そこでinterface definition languageですよ
590 名前：名前は開発中のものです。 mailto:sage [2007/09/18(火) 01:16:19 ID:5yeO/Swt]: IDLでも結局は各言語に落とさなきゃ使えないからやる事はUMLとかわらなくない？
591 名前：名前は開発中のものです。 mailto:sage [2007/09/18(火) 08:32:52 ID:FiLXhuol]: UMLってやっぱEAでやってるの？
eclipseでNECのプラグインのを最近使ったんだが
592 名前：名前は開発中のものです。 mailto:sage [2007/09/18(火) 19:37:18 ID:QkVIQXVh]: 個人的には MagicDraw とホワイトボード。
593 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 06:01:52 ID:8Q9ZtqfD]: まず、マインドマップで手書きして頭の中整理してからUML使うな。
594 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 07:15:57 ID:kYNbLBEe]: 紙と鉛筆最強
595 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 08:22:34 ID:+HDOOkBH]: 同意。小型ホワイトボードもいい。
596 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 21:49:02 ID:umm3ZbPO]: Eclipseのプラグインなんて使うのは、UMLドキュメントも成果物として要求されるような
ソフトウェア製作現場くらいじゃないか
597 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 22:07:56 ID:sx0yn1sA]: そうなんだ・・・eclipseのプラグインでしか良いのないなーって思ってた
598 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 22:43:10 ID:amMsIx49]: それよりeclipseのプラグイン=UMLツールって図なのはどうなのよ？

スタンドアローンなUMLツールもちゃんとあるんだからね！？
599 名前：名前は開発中のものです。 mailto:sage [2007/09/19(水) 22:49:24 ID:jK01tyWi]: >>598
> スタンドアローンなUMLツールもちゃんとあるんだからね！？
俺が使ったことあるのは、こんな感じ。結局 MagicDraw の Standard Edition 買って
使ってる。

Visio
・汎用お絵かきツールなので UML 専用ツールとしてみると、かなりイマイチ…

Together 試用版
・ソースコードに特定の形式でコメント埋め込む必要あり。ソースコードと UML の
　同期は完璧だが、C++ だとマクロやらテンプレートやらあって逆に足枷に。

Enterprise Architect
・細かいことは忘れたが、値段の割りによくできてた気がする。

Jude竹
・使いづらかった記憶が。Java 前提で C++ だとイマイチ。

MagicDraw
・それなりに自由に図がかけつつ、UML 固有のサポートも十分している（基底クラスの
　メソッドをコピーしてくるとか）。サポートしている図の種類も豊富で、開発も順調に
　継続中。Pure Java アプリなのでメモリは多めに。

　ただ C++ だとソースコードと同期する reverse engeneering, forward engeneering は
　制約ありすぎで使い物にならない。
600 名前：名前は開発中のものです。 mailto:sage [2007/09/21(金) 00:31:32 ID:KPDpA4Lk]: C++ …
601 名前：名前は開発中のものです。 mailto:sage [2007/09/21(金) 16:35:38 ID:GgMzSNNV]: なんかC++のマクロが元凶なだけじゃ・・・。
javaにマクロないし。
602 名前：名前は開発中のものです。 mailto:sage [2007/09/21(金) 22:17:12 ID:RhYk6YdF]: >>601
スマートポインタ・pimplイディオムあたりも、そのまま図にすると冗長で
ワケわかめ。
603 名前：名前は開発中のものです。 mailto:sage [2007/09/23(日) 23:05:37 ID:7hC9eV3o]: javaにスマートポインタなんてないし世代別GCという逸材が組み込まれてる。
とか言ってみて良い？

実際javaでGCが必要になるケースって言語実装する場合だけど、javaのGCに投げれば良いだけだし。
604 名前：名前は開発中のものです。 mailto:sage [2007/09/23(日) 23:32:34 ID:/EvVKbRp]: え、いや、だから何？としか･･･
605 名前：名前は開発中のものです。 mailto:sage [2007/09/24(月) 00:13:37 ID:5E4o0Iyz]: >>603
文面見るだけだと、集約とコンポジションの区別がつかんけどな。関連との区別も
つかないし。
606 名前：名前は開発中のものです。 mailto:sage [2007/09/24(月) 00:36:17 ID:N33NsFp0]: >>603
CでもC++でもライブラリでGC使えるようになるよ
とか言ってみて良い？

デストラクタのタイミングがJavaだと曖昧だから、
確実に呼ぶためには明示的に呼び出す必要あるよね
とか言ってみて良い？
607 名前：名前は開発中のものです。 mailto:sage [2007/09/24(月) 00:38:43 ID:wP3VhiV8]: Dispose論争がやりたいなら他でやってくれ
608 名前：名前は開発中のものです。 [2007/09/25(火) 01:43:17 ID:cUqDGz0b]: 共同開発で、Bohemなんか使ったら（ｒｙ
609 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 01:59:20 ID:Ubo+pWpI]: >>608
アーーーー！！
610 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 02:50:51 ID:j6V698Ny]: Bohemと言えば、吉里吉里３の開発で使っていたような。
と思って調べてみたら、やはりけっこう面倒になことなっているようですね。
ttp://kikyou.info/diary/?200603

C++でGCをするのは、やはりリスクは大きいんでしょうかね。
挙動をきちんと把握していないと、余計なバグを出しまくると。
611 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 07:15:30 ID:p/ZTpO6S]: まさにそれで右往左往してるじゃん。吉里吉里３は。
というか誰のコードが入るか分からんOSSにはBohemGCは向いてないと思う。
612 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 14:42:50 ID:IK+Mi4/+]: > とくにファイナライザ(デストラクタ)が呼ばれるタイミングや、
> そもそも呼ばれるか呼ばれないかすら信用できなくなるというのは痛いです。

これってBohemGCというか、
JavaでもC#でも似たような問題抱えてるような気が。
C#はusingでだいぶ良くなる（というか必須）けどね。
613 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 15:49:03 ID:j6V698Ny]: C#でusingを使えるような状況なら、C++でも
std::auto_ptrやboost::scoped_ptrが使えるのでは。
まあこの当たりのスコープによる廃棄を使えるのは、データ構造でなくその
呼び出し側のほうになるとは思いますが。

データ構造の内側たるメンバ変数では、結局いポインタwをを使おうとすると、
やはりGCかスマートポインタが(r
614 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 19:45:25 ID:w6OvpTgu]: ヒープの解放と後片付けは違うぞ
615 名前：名前は開発中のものです。 mailto:sage [2007/09/25(火) 23:37:49 ID:k19pdkx7]: >>611
全然右往左往はしてないので、BohemGCは向いていると思うよ
616 名前：名前は開発中のものです。 mailto:sage [2007/09/26(水) 02:49:14 ID:9IVyIRI7]: >>614
java6からはそこらへんもVMの仕事だな。

>>615
一時期、他のコードとの相性で苦戦してただろ。
というか吉里吉里は実質一人開発なのでバザールモデル開発時の問題は無縁かも知れん、
がソースを公開してるので誰がどう使うか分からないのでBohemGCは向いてないだろ。
617 名前：名前は開発中のものです。 mailto:sage [2007/09/26(水) 04:16:25 ID:PN2WWo+U]: >java6からはそこらへんもVMの仕事だな。
？
618 名前：名前は開発中のものです。 mailto:sage [2007/09/26(水) 07:07:41 ID:i8F3qiyk]: >>616
よく知らないんだけど、BohemGC特有の問題ってなんなの？
>>812はBohemGCだけの問題では無いよ。
619 名前：名前は開発中のものです。 mailto:sage [2007/09/26(水) 08:13:44 ID:3isC6Gy4]: >>616
w3m も BohemGC 使ってなかったっけ？

俺は C++ だとスマートポインタで十分なケースが多いので、BohemGC は
まず使わないけど。
620 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 02:23:21 ID:+pE/2Wnl]: >>616
ほら、言い直した。
「一時期問題があった」だろ？
それなのに>>610-611で2006年から今もずっと右往左往してるかのような印象操作をして、
BohemGCがOSSに向いてないとか、そんな詭弁はやめろ。
お前が古い人間で、よく理解出来ていないガベージコレクションが嫌いなだけなんだろ？

>ソースを公開してるので誰がどう使うか分からないのでBohemGCは向いてない
これとかまったく意味不明。
boostのshared_ptrでも、まったく理解しないで使うと罠がある。
そういう仕組みをまったく使わないで、手作業で開放しても罠がある。
お前の論では、ナニをやろうが向いていないんだよ。

>>619
スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
var a = [0];
a[0] = a;
これだけでメモリリーク起きるなんて、危なくて使えん。
621 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 02:44:05 ID:VvpaMtLQ]: ＧＣは魅力的だと思うが、まだ”枯れてないから”じぶんは好きくない
技術は何かを実現する手段であって目的ではない
622 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 07:51:02 ID:N1wjX3wO]: 枯れぬなら　枯らしてしまえ　ほととぎす
623 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 08:18:58 ID:w2Fnc2yT]: >>620
> スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
スクリプト言語の仕様にもよるな。

PCのギャルゲーだとスクリプト言語自体をリッチな仕様にして、動的な
メモリ確保なども可能にする（文字列連結とか）場合もあるみたいだけど、
俺はスクリプトでは完全にコンパイル時にメモリ割り当てが確定しちゃう
ようにして、メモリやリソース管理は C/C++ 側のコードでプログラマが
責任を持って行うようにしてる。

スクリプタとプログラマの役割分担どうするかだが、スクリプタ大量投入
するタイプのプロジェクトだと、スクリプトの自由度を下げた方がバグの
発生頻度が小さくなって、結果的にｳﾏｰなことが多いと思う。
624 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 10:54:43 ID:5M+6zylX]: なんで>>620はエスパーレッテル張りまでして必死なの？
吉里吉里信者？
625 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 11:00:37 ID:qVZI5NrD]: 確かに必死さが伝わってくるな
626 名前：名前は開発中のものです。 [2007/09/27(木) 11:33:55 ID:ET62U43b]: nanndeこんんあに必至なの？
627 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 12:37:22 ID:vs9qugjh]: 池沼だから
628 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 13:19:16 ID:HGokK3wm]: 荒れていても技術的な話題が堪えることのない名スレ
でも最近少々荒れ気味だから皆落ち着け
629 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 14:40:58 ID:1l0/TfAT]: 落ち着いてないのは>>620くらいじゃ？
元々隔離板の過疎スレだから少数が騒ぐと目立つだけ。
またーりログ読んでるか、生温かい目で見守ってるのが大半じゃない？
630 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 23:24:46 ID:foTLrBw8]: 言うに事欠いて「必死だな」で切り抜けようと試みる
古典的バカが未だに生き残ってるとは驚きだな
631 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 23:31:57 ID:n9Qt+CRZ]: 煽っても必死さが正当化されるわけじゃないよ
632 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 23:38:28 ID:Kt0ma0Lg]: BohemGCｻｲｺｰ
633 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 23:47:44 ID:CbY2cE68]: 「必死さが正当化される」ってのはよく分からないけど・・・
とりあえず、「必死だな」とか言う前に>>620を論破してみれば？
例えば、
１，BohemGCだけにある、もしくはJavaやC#のGCでは解決された重要な問題を列挙する
　　（数値とアドレス値が識別できないという問題はあるけど、確率的にそれが不都合になることはほとんどない）
２，吉里吉里にはBohemGCが向いていないことを示す他のソースを提示する
とかね。

個人的に１はとても興味があるので、問題があるなら教えて欲しかったりする。
634 名前：名前は開発中のものです。 mailto:sage [2007/09/27(木) 23:48:30 ID:w2Fnc2yT]: >>620
本題からそれるけど、
> スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
> var a = [0];
> a[0] = a;
> これだけでメモリリーク起きるなんて、危なくて使えん。
スクリプト言語におけるインスタンスの寿命管理と、C++ インスタンスの寿命管理は
別の話だよね。

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

当然スタック上にあるスクリプト言語のインスタンスは全部 VM でトラッキングできる
ので、ガベコレできる。C++ 側のメモリ管理が GC 使ってるかどうかとは無関係に。
635 名前：名前は開発中のものです。 mailto:sage [2007/09/28(金) 00:02:16 ID:qVZI5NrD]: >>634
ようするに実装がスタックレスってことだな。
つかスタックレスでないVMにコルーチンを実装するのは不可能じゃないか？
636 名前：名前は開発中のものです。 mailto:sage [2007/09/28(金) 00:23:32 ID:l1EYGW9S]: >>635
多少制約がつくけど、Cスタックを保存・切り替えできればスタックフル VM でも
コルーチンは実装できます。

ただ、どうやってもポータブルなコードにはならないし、C++ 例外の実装方法に
よっては問題出るから、お勧めしないけど。
637 名前：名前は開発中のものです。 mailto:sage [2007/09/28(金) 01:10:11 ID:iJmhMBkl]: >>636
スタック切り替えてまでやるかｗ
猛烈に処理系依存なコードになりそうだな
638 名前：名前は開発中のものです。 [2007/11/17(土) 17:10:37 ID:iMK/PWng]: 戦闘シーンの進行管理をするクラスって、どういう名前にしたらいいんだろう？
BattleManagerかな…でもManagerは使うなって話もあるし。
639 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 17:27:39 ID:tjJHhoDY]: >>638
Manager 使うなって話は、つまり「管理」というあいまいな言葉を使うなって話。
「戦闘シーンの進行管理をするクラス」の役割を見直さずに名前付けだけ考えてても
無意味。
640 名前：名前は開発中のものです。 [2007/11/17(土) 17:45:31 ID:iMK/PWng]: >>639
レスありがとう

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

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

OOPド素人丸出しでごめん
641 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 17:53:06 ID:3LkIon8X]: 戦闘シーン関連の処理に関して、俺が抱いてるイメージとしての「管理」から考えると
そのManagerが関連する他のクラスに処理を分配して、それを仲介するようなクラスだとMediatorあたりになるんじゃなかろうか
俺が作ってた「Manager」は上記のものがさらにFacadeの役割も果たすってのが多かった
デザパタから借りてるだけで正解とはとても言えんけど、「Manager」よりはマシかな…と
642 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 18:09:05 ID:tjJHhoDY]: >>640
> そいつに戦闘の進行管理をさせればいいんじゃない？

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

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

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

「戦闘の進行」と「行司」という切り分けができるなら、前者を Advance() なんていう
関数、後者を Rule とかいうクラスにすることが考えられる。 Advance() は Rule に
従って処理をする、って感じね。具体的な状況がわからないんで、全然ダメかも
しれないけど。
643 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 18:34:11 ID:2u92yTvZ]: SceneManagerとか定番だな
644 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 18:35:34 ID:JxWacONa]: javaの立場が・・・
645 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 20:30:54 ID:/rbqSJ11]: class Referee
{
public:
　　Referee(const class Rule& current_rule);

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

　　inline void win(void) { youtube.com/watch?v=ubhW9R-F7cM }
};
646 名前：名前は開発中のものです。 mailto:sage [2007/11/17(土) 21:45:56 ID:K5pYaEDh]: >>644
？
647 名前：名前は開発中のものです。 mailto:sage [2007/11/18(日) 06:00:26 ID:D4743XwF]: 使うなとは誰もいってないよ
648 名前：名前は開発中のものです。 mailto:sage [2007/11/18(日) 07:27:13 ID:mDvA2is2]: >>642
俺の場合、Manager って名前は使っちゃうな。ただし Manager クラスで
何でもかんでも処理せずに、分割できるところは別のクラスに切り出して
Manager クラスに集約する。

Facade やね。
649 名前：名前は開発中のものです。 mailto:sage [2007/11/20(火) 01:41:42 ID:Xv2CgjLa]: さっきからしょぼいＢＧＭのループがひどいな
２ループもすりゃ十分だろ
650 名前：名前は開発中のものです。 mailto:sage [2007/11/20(火) 02:00:34 ID:B+/JlwAo]: >>649
何に対して言ってるのか
651 名前：名前は開発中のものです。 mailto:sage [2007/11/20(火) 06:51:02 ID:x6OdnLNb]: B・・・・・GM・・？
652 名前：名前は開発中のものです。 [2007/11/24(土) 17:27:35 ID:5kPj3Eca]: シューティング作ってて、敵のクラスと自機のクラスを分けちゃったけど、わけない方がスマートだったかなあ
653 名前：名前は開発中のものです。 mailto:sage [2007/11/24(土) 17:36:40 ID:BsLqDTe0]: >>652
一部同じインターフェースを持つことはあるだろうけど、普通に考えてまったく同じクラスに
なるとは思えない。
654 名前：名前は開発中のものです。 mailto:sage [2007/11/24(土) 19:10:43 ID:XdMXhxj/]: 自分は敵１と敵２とかでもわけてる
655 名前：名前は開発中のものです。 mailto:sage [2007/11/24(土) 21:09:45 ID:vFIasKer]: >>654
そりゃ、作るゲームにもよるな。キャラクター数少なくて差異が大きい場合には
クラス分けるが、RPG のように数が多いと基本1クラスでデータ駆動にする。
656 名前：名前は開発中のものです。 mailto:sage [2007/11/24(土) 22:25:37 ID:Y480fdwm]: >>652
何シューティングか知らないが、
よくある２Dのシューティングなら自機と敵機で違う処理したほうが、
当たり判定の最適化しやすそうだな。
（同じ基底クラスから派生させるとかいう話はおいといて、

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef