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

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

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

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

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

はっ、意味不明

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

設定提案とヲチと批判しかできないこの過疎板で
技術を語れるかが見物だ。

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

抽象的過ぎたからひとまずお題を挙げておくか。
⊃「パックマン」

敵に関しては、敵の抽象クラスを継承したサブクラスで
移動アルゴリズムをオーバーライドするよりも、
アルゴリズムを別のクラスで用意して
それに対する参照を敵のクラスに持たせる方がいいのかな？

**名前は開発中のものです。** · 2006/08/10(木) 23:26:41

+-----------------------+
| CEnemy |
+-----------------------+
| move() |
| (strategy->execute()) |
+-----------<>----------+
| strategy
|
|
+-----V-----+
| Strategy |
+-----------+
| execute() |
+-----A-----+
|
+------+---------+----------+
| |
+------+-------+ +------+------+
|AkabeeStrategy| |PinkyStrategy|
+--------------+ +-------------+
| execute() | | execute() |
+--------------+ +-------------+

クラス図で書くとこうなるのか？まあ絶対ズレているだろうがな…。
俺自身は超初心者だから間違いがあったら指摘お願い。

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

ちょｗ
いくらなんでもズレすぎだ…。

**名前は開発中のものです。** · 2006/08/10(木) 23:29:52

パックマンごときに大げさなパターンはいらねべ。
敵キャラの個別化をしたければテンプレートメソッドパターンぐらいで十分。
好きにすればよい。

**名前は開発中のものです。** · 2006/08/10(木) 23:38:42

>>7
確かにその通りなんだが、
まあいきなり大規模なものを持ってきても
話しづらいかなと思って。

**名前は開発中のものです。** · 2006/08/10(木) 23:39:13

一応>>5のズレ直しverを貼っておこう…。

　+-----------------------+
　|　　　　　　CEnemy　　　　　　|
　+-----------------------+
　|　　　　　　move()　　　　　　　|
　|　　(strategy->execute())　　|
　+-----------<>----------+
　　　　　　　　　　|　strategy
　　　　　　　　　　|
　　　　　　　　　　|
　　　　　+-----V-----+
　　　　　|　　Strategy　 |
　　　　　+-----------+
　　　　　|　　execute()　|
　　　　　+-----A-----+
　　　　　　　　　　|
　　　　　+------+------------+----------+
　　　　　|　　　　　　　　　　　　　　|
+------+-------+　　　+------+------+
| AkabeeStrategy |　　　|　PinkyStrategy |
+--------------+　　　+-------------+
|　　execute()　　　|　　　|　　execute()　　 |
+--------------+　　　+-------------+

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

シューティングゲームの敵と敵から打たれるミサイルなんかは、
ファクトリメソッドパターンかな・・・

**名前は開発中のものです。** · 2006/08/11(金) 00:24:48

｢こういうキャラに対しては何ちゃらパターンが使えるな｣
みたいなことは大体わかるのだが、
全体をまとめようとするとうまくいかないのはオレだけか？

**名前は開発中のものです。** · 2006/08/11(金) 00:39:49

同じ方向に話を進めるためには
タスクシステムの内容を統一した方がいいんじゃね??

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

ttp://www.gamedesignpatterns.org/

**名前は開発中のものです。** · 2006/08/11(金) 05:13:38

名スレの予感

**名前は開発中のものです。** · 2006/08/11(金) 07:46:49

>>9
CEnemyのCって何？

**名前は開発中のものです。** · 2006/08/11(金) 07:51:46

ClassのCじゃねぇの。

**名前は開発中のものです。** · 2006/08/11(金) 08:14:44

MFCを知らんのか？

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

うん、普通に知らない。

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

charだけあれば他は要らない

**名前は開発中のものです。** · 2006/08/11(金) 11:46:44

Cつけるのはダサいからやめろ。

**名前は開発中のものです。** · 2006/08/11(金) 13:15:07

じゃあ、なにつければいいのさ？

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

そのクラスを直感的に理解できるよう努力すれば他に何もいらない

**名前は開発中のものです。** · 2006/08/11(金) 13:32:51

Cつけるの癖になってるなぁ。

**名前は開発中のものです。** · 2006/08/11(金) 14:04:44

コードスタイルはクラス設計とは関係ないだろ
Ｃの１文字ぐらい脳内削除できんのかね

**名前は開発中のものです。** · 2006/08/11(金) 15:22:03

大文字で始まる名詞はクラス以外ありえないから、無意味に邪魔なゴミつけるんじゃないよ。
今出回ってる雑誌や書籍、それにオープンソースのコードに
Cつけてるものがどれほどあるか見てみろ。
MSなんか、C#では逆にCを「つけるな」と言ってるしな。

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

わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
普通にコードを書く気が最初からないんだから。

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

>>25
コードスタイルについてはごもっともだけど、
＞わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
って誰が言ってたのさ。統計とったの？
そうですか、あなたの経験上ですか。では、変なクラス設計の基準はどこに？

**名前は開発中のものです。** · 2006/08/11(金) 15:56:24

>>25
お前の言っていることは間違いではないが、焦点がズレているな
俺が言いたかったことは、>>9の敵クラス名がCEnemyだろうがEnemyだろうが
クラス図には何の影響もないということだ
変なスタイルを使う奴は云々という決め付けはいらない
設計がそこに転がっているんだからその優劣を語ればよい

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

>>25
何でそんなに興奮してるんだ？
コードスタイルは分かりやすさ、第一。
別にコード公開する気もないし。

**名前は開発中のものです。** · 2006/08/11(金) 16:32:11

>>7
Template Methodパターンだと、実行時に移動アルゴリズムを
変更したくなったときに面倒じゃないか?
パックマンがパワー餌を食べたことがMediatorを通して
通知されたとき、strategyを逃げるアルゴリズムに
変更すれば、同じ呼出しで適切な移動が可能。
まあ、オリジナルだと逃げるアルゴリズムは共通だから
それは組み込んでおいて通常移動はオーバーライドでも
問題ないけど、通常移動も動的に変更したいのならStrategyかな。

実際問題、パックマンを作るのにここまで慎重に設計する必要は
ないが、設計スレだし色々探ってみるのがよさそうだ。

**名前は開発中のものです。** · 2006/08/11(金) 18:51:41

>>11
俺もその辺はよく悩むな。
最近はゲーム全体の構造について再度考え直そうと思って、
ttp://www.jeffplummer.com/Writings/Thesis/Thesis_with_Appendix.pdf
このあたりを読んで研究中。
GDC'06のTim Sweeneyの講演（Building a Flexible Game Engine）のスライド早く公開されないもんかな。

**名前は開発中のものです。** · 2006/08/11(金) 20:08:38

>>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おすすめ。

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

>>30-31
SUGEEEEEEE!!!
英語苦手だけど頑張って読んでみるか。

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

>>31
おぉ、ﾄﾝｸｽ。参考になりまつ。
やっぱり並列化も次世代機を考慮すると重要なトピックになりつつあるんだなぁ…

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

シングルコアを使い切る→マルチスレッド
マルチコアを使い切る→並列同時実行

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

お前ら！TCBを格納するのに何使ってる？
STLのlist使ってたんだけど、
動的メモリ確保で遅くなるから配列を使った方がいいと聞いて…。
それから単方向ではなく双方向リスト構造にする利点があれば教えてくれ。

**名前は開発中のものです。** · 2006/08/12(土) 02:27:39

やだ

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

>>29
>Template Methodパターンだと、実行時に移動アルゴリズムを
>変更したくなったときに面倒じゃないか?
フラグのOF/OFFの分岐でいいべ。パックマン程度だったらその方がずっとコード
が分かりやすい。移動パターンが何種類もあると言うんだったら別だが。

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

ゲームプログラムでMediator使うの微妙じゃね？
オブジェクト同士が相互作用しまくりで
処理内容が多岐にわたるゲームの場合、
updateしたよあとよろしくね♪じゃMadiatorの仕事が多すぎる。

結局俺の場合、例えばシューティングで当たり判定をとるんだったら
自機インスタンスへのポインタを敵のクラスのメンバに持たせたり
自機インスタンスをグローバルにしちゃったりする。
よくないことはわかりつつも。何か良い方法はないものかね。

38 · 2006/08/13(日) 02:36:16

ん？もしかしたら俺は物凄く馬鹿な勘違いをしていたのかもしれん。
今までは、Mediatorクラスが持つ関数は
呼び出し側の参照を引数として取るupdateただひとつだけで、
updateは引数から得られる情報を元に適切な処理を選択し、
適切なオブジェクトに通知するのだと思っていた。が、
Mediatorに複数の関数を持たせて
呼び出す側が選択するというのもありなんだな。
例えば当たり判定処理のためのhitCheckとか。

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

>>35
listのままでおｋ

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

この板ですごい久しぶりの良スレ候補だ。

**名前は開発中のものです。** · 2006/08/13(日) 11:24:21

>>38
まぁゲームシステムにもよるだろうなぁ。自機が一機しかなければ
自機クラスにMediatorの仕事やらせてもまず大差ないだろうし。
弾のような飛び道具出すにしても、
自機の敵キャラクタのインスタンス配列をそのまま渡せば
そこまで複雑になるとも思えない。むしろこっちの方が楽そう。
マリオみたいに敵同士の当たり判定がある場合は、
Mediatorみたいなものは必須だと思うけど。

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

デザパタ話か…
昔、GraphicsクラスやらInputクラスやらを
シングルトンにしようとしたが、初期化するための引数が多いせいで
Graphics.getInstance()なんて簡潔な呼び出しをすることが
不可能だと気づいて泣いたぜ

**名前は開発中のものです。** · 2006/08/15(火) 01:53:25

>>42
initializeメンバ関数を別途用意して最初の方で呼び出せばいいだけの話じゃ？

**名前は開発中のものです。** · 2006/08/15(火) 02:22:10

>>43
それやるくらいなら俺はシングルトンパターンを適用せずに
フィールドを全部staticにする
初回のgetInstance()呼び出しでコッソリ初期化、
表面上は初期化いらずな点がシングルトンの利点だと勝手に思っているから

**名前は開発中のものです。** · 2006/08/15(火) 03:30:20

Monostateパターンか

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

Mediator処理関数の呼び出すべき順番が決まっているのに
呼び出し側のタスクがその順番で並んでいないときは発狂する。

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

Mediatorを適用しているサンプルを見たことがない。
プレイヤーへのポインタを保持する敵タスク(リスト)ばかりだ。
ttp://d.hatena.ne.jp/kenmo/20051215#p1にMediatorの解説があるが
接触判定のような単純な通信にしか使えんな。これは。

**名前は開発中のものです。** · 2006/08/19(土) 10:25:32

このスレでよく出てくるタスクって何の事？

**名前は開発中のものです。** · 2006/08/19(土) 10:59:20

>>48
タスクシステムでググると出てくる。GameDevPukiWikiにも載っている。
http://gamdev.org/w/?%5B%5B%A5%BF%A5%B9%A5%AF%A5%B7%A5%B9%A5%C6%A5%E0%5D%5D

**名前は開発中のものです。** · 2006/08/19(土) 12:03:47

タスクシステムの考え方は海外ではあまり見ない和製概念だね
向こうではDDAやらエンジン単位でのアーキテクチャが主流なのかな

**名前は開発中のものです。** · 2006/08/19(土) 12:16:19

タスクシステムって要はリストの事なの？

**名前は開発中のものです。** · 2006/08/19(土) 13:19:26

タスクコントロールブロックがリスト構造を成しているとは限らない。

**名前は開発中のものです。** · 2006/08/19(土) 14:40:17

オレはCompositeパターンを使ってTCBをTreeにしている。
こうすると走査が面倒ななるから、必要なTCBだけMediatorに登録。

**名前は開発中のものです。** · 2006/08/23(水) 17:59:02

シューティングゲームなどで、C++タスクシステムにおいて、
敵管理タスクが当たり判定や弾の狙い撃ちをするために、
自機タスクから座標などの情報を取得するにはどうすればいい？

**名前は開発中のものです。** · 2006/08/23(水) 20:30:16

今北お！

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

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

俺はなんかもう面倒くさくなって全部一緒になってんだよねー(最悪)

**名前は開発中のものです。** · 2006/08/23(水) 20:32:29

>>54
多分、自機情報がグローバルにあるんだと思うよ！

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

パックマンクラスかな

**名前は開発中のものです。** · 2006/08/23(水) 21:23:13

つか、誰か>>50の解説を頼む。

**名前は開発中のものです。** · 2006/08/23(水) 21:28:31

>>55
画像情報がビットマップなんかのことだったら殆ど別だな。
ゲーム総まとめクラスから
キャラの座標値、アニメーションインデックス値を吐かせて
それを画像クラスに投げてる。

**名前は開発中のものです。** · 2006/08/24(木) 00:46:53

【敵機(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()で座標を取ってくるよ派。

**名前は開発中のものです。** · 2006/08/24(木) 20:19:35

>>59
キャラの座標やアニメーションインデックス自体は、
やっぱり>>9でいうCEnemyにあるんだよねぇ？
それを総まとめクラスが集約してるみたいな構造かなぁ。

その設計だと、ダーティ領域を消すための前回のスプライト位置は
画像クラスに持ってるんだろうか？

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

アニメーションインデックスは
CEnemyのメンバとして直接持つのではなく、
委譲関係にあるインデックス管理クラスが持った方がいいかな。
インデックス管理クラスはmap<String, list<POINT> >みたいな構造にして、
動作の名前を与えるとPOINT構造体を返してくれるというような。

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

>>61
総まとめクラスにインデックス値を吐かせてるのは
それがフレーム管理もやってるから。
インデックス値はCEnemyには持たしていない。
毎回背景から再描画してるんで、
前回スプライト位置は保持していない。メンドイし。

**名前は開発中のものです。** · 2006/08/25(金) 14:31:51

>>63
>総まとめクラスにインデックス値を吐かせてるのは
>それがフレーム管理もやっているから
いやそれ全然理由になっていないと思うぞ…。

63 · 2006/08/25(金) 20:56:45

あれ？自分で書いておいて訳わかんねｗ
作ったまとめクラスよく見たらフレーム管理はしてなくて、
1フレーム進めるメソッドがあるだけだった。
んで、そのメソッドを実行するたびに
0～(アニメーション数-1)までくるくる回す
インデックス値のメンバがそこにあった。
数ヶ月前に書いたソースを思い浮かべながら書いたら
記憶があいまいで勘違いしてた。ｽﾏｿ

**名前は開発中のものです。** · 2006/08/26(土) 02:58:51

>>65
それをやると、敵を生成したタイミングにかかわらず
同じ敵が同じ状況で常に同じモーションをとることになるな(行進みたいに)。
俺はモーションをバラにさせたいときは>>62みたいなクラスを敵クラスに持たせ、
あえて統一したいときはそれを敵リストクラスに持たせている。

**名前は開発中のものです。** · 2006/08/27(日) 01:28:02

簡単なことを難しくやる典型例みたいな…
やっぱしゲームには過度なオブジェクト指向は必要ないかなあ

**名前は開発中のものです。** · 2006/08/27(日) 01:36:32

３Dゲームはオブジェクト指向無しではやってられまへん。

**名前は開発中のものです。** · 2006/08/27(日) 01:58:03

>>67
このスレに書かれているようなクラス設計を
どんな規模のゲームにでも毎回採用している奴はいないだろう。
採用した方がむしろ簡単になったり、差し替えが楽になったり
するようなところに適用すればいい。
パックマンとかシューティングとかは説明例に利用されているだけだし。
ゲームに過度なオブジェクト指向は必要ないというのはちと早計。

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

**名前は開発中のものです。** · 2006/08/27(日) 11:43:57

こんなスレが出来てたのか。

いわゆるタスクシステム的な、個々のオブジェクト同士の依存関係の記述は、
ここの考え方と同じ方針でやってる。
ttp://www.issei.org/blog/archives/000225.html

63 · 2006/08/27(日) 12:10:26

>>66
まぁ漏れの場合はそこまで凝ったシューティングじゃなかったし。
もっと拘ると最終的にそれに近くなってくるだろうなぁ。

>>67
難しいか？このくらいじゃ慣れの問題でしょ。
大規模なゲーム作るとなると設計をちゃんとしなければ
取り返しがつかなくなって訳若布になる。
それに、そこで作ったコードを再利用するなら
他のゲームも自動的にオブジェクト志向なコードになる。

**名前は開発中のものです。** · 2006/08/27(日) 13:24:46

そこに時間という足かせとのバランスを考慮するんだろ

**名前は開発中のものです。** · 2006/08/27(日) 14:46:15

過度のオブジェクト指向はゲームじゃなくても要らないっしょ。
過度なんだから。

まぁ、でもパックマンに >>9 ぐらいの設計は全然アリだよね。
CEnemyを直接継承しちゃうかな。俺は。

**名前は開発中のものです。** · 2006/08/27(日) 20:51:21

ゲーム固有のコード全てを持つクラスの名前ってどんな風に付けますか？

Game だと（他のタイトルのコードと）紛らわしいし、ゲームタイトルって選択もあるだろうけど
開発を始めたばかりの頃に気の訊いたタイトルを思いつけるとも限らないし・・・
参考までに聞かせてください

**名前は開発中のものです。** · 2006/08/27(日) 20:59:17

ゲームのすべてのコードが含まれてるなら後で変更しても問題ないんじゃないの

**名前は開発中のものです。** · 2006/08/28(月) 06:10:31

たとえばJavaならeclipse様の力で名前なんかどうにでもできるんだが、
そういうツールがない場合、開発コード名をつける。

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

>>75
namespaceで区切る。

**名前は開発中のものです。** · 2006/08/30(水) 08:47:32

良スレだと思うのだがなかなか伸びないな。
やはりこの板は設計論より実装論が先立ってしまう人が多いからだろうか…

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

単に内容について来られる奴が予想以上にいない説。
スクリプタやプログラム初心者が多いこの板では
このスレでメインに置かれているC++自体がまず敷居高し。
加えてタスクシステムやデザインパターン等の前提知識が必要だし、
ある程度作り慣れた人でないと語られている手法の有用性がわからない。
っていうか>>2が端的にこのスレの性格を表している気がしなくもない。

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

イベント駆動型で作れないかな

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

パズルゲームとかなら

**名前は開発中のものです。** · 2006/08/30(水) 19:00:19

むしろ糞スレ化せずに80以上のまともなレスがあるのが奇跡だよなぁ。

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

実装論先行型が多いと思う

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

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

とりあえずデザインパターンとあまり関係ないんだが
クラスの作り方どうやってるか聞きたい
複雑な行動パターンをお手軽に実装できる方法とかない？

**名前は開発中のものです。** · 2006/08/30(水) 23:37:00

C++で、クラス関連の機能から触り始め
テンプレートの書き方やSTLライブラリまで一通り勉強したけど
デザインパターンにはまだ触れたことがない
今のところ、機能ごとに切り分けたクラスを作りためながら
自前のゲーム用ライブラリを構築するだけで満足してしまってる

**名前は開発中のものです。** · 2006/08/30(水) 23:42:43

どうでもいいことを突っ込まずにはいられない
>85
>STLライブラリ
頭痛が痛いです

**名前は開発中のものです。** · 2006/08/31(木) 00:11:24

知ってるがな
どうでもいいことには突っ込まずにいてください

**名前は開発中のものです。** · 2006/08/31(木) 00:17:43

プログラムを勉強し始めて間もなく
多くの人が感動したアルゴリズムと同じく、
綺麗なクラス設計を示したのがデザパタだ
みたいなことを誰か言ってたな。

**名前は開発中のものです。** · 2006/08/31(木) 00:47:27

83が変なコトいうから微妙な空気が漂ってきた。

**名前は開発中のものです。** · 2006/08/31(木) 03:24:35

デザインパターンの意図については語る必要はない気がする。
こっちは利用する側なんだし。実際このスレではパターン名で疎通が取れているし
パターン自体も色々な使用例が挙げられていて役立っているからそれでいい。

>>84
＞複雑な行動パターンをお手軽に実装できる方法とかない？
なんとなく、このスレでは扱わない具体的な実装面に踏み込む内容な気がする。
どちらにしろ具体例を挙げてくれないと意見しにくい。
行動パターンがコロコロ変わるというのであれば>>9の方法でいいんじゃないか？

**名前は開発中のものです。** · 2006/08/31(木) 17:27:49

こういうスレは、この板では貴重だと思う。
当たり判定のアルゴリズムはわかっても、
それぞれの物体の座標をどうやって取得するか等を語れるスレは少ないし。

**名前は開発中のものです。** · 2006/08/31(木) 18:34:51

>>90
前にＳＴＧ作った時に敵の数を２０以上作れと言われた
一つ一つ行動パターンを作っていくのがえらいめんどくさかった
既出ですまそ、そしてありがとうございます

**名前は開発中のものです。** · 2006/08/31(木) 19:32:51

「複雑な行動パターン」ってどういうもん？
キャラの状態が色々あってステートの変化の組み合わせが多い(格ゲー系にありがち)とか、
行動の流れが複雑でプログラムがめんどくさい(シューティングにありがち)とか、
カテゴリはいくらでもありそうだからなぁ

でも大抵はスクリプトを使えば割と面倒なタスク処理が解決すると思うので紹介
タスクを実装するのに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みたいな感じのクラスを作るのがいい感じ。

**名前は開発中のものです。** · 2006/08/31(木) 19:34:21

それにしてもひどい文法エラーだと自分でつくづく思った。

**名前は開発中のものです。** · 2006/08/31(木) 21:15:01

>>93
ゲームプログラムとしては前者のコードの方が自然だから
わざわざ後者にしたいという理由がわからない。

**名前は開発中のものです。** · 2006/08/31(木) 21:43:04

IEnumerator<IAction> GetAction()
{
　for( float Angle = 0; Angle < 360; Angle += AngleVel; ) {
　　yield return new FireAction(m_Angle);
　}
}

C#でこういうのどうだろ

**名前は開発中のものです。** · 2006/08/31(木) 21:52:59

>>93の例は微妙に不適当な気がする。
”複雑な状態遷移をスクリプト（というよりこの場合fiber/coroutine）で処理した方が簡単”
というのは言えると思うが、
”毎フレームUpdateを呼ぶよりもHogeThreadを1回だけ起動する方法にしたい”
なんて思う人はごく稀だと思われる。

この場合、>>9のStrategyのサブクラスとしてScriptStrategyを定義して、
excuteが呼ばれるたびにコンテキストを復帰して起動する処理を作る方が自然。

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

>>95
そんなことは無いですよ。BulletMLはまさしく後者の方法の一種です。
わざわざこのためにpythonのマイクロスレッドを利用する人もいるくらい。

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

>>97
なんか表現を誤った気がします。
結局はおっしゃるとおりコルーチンってことです。

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

人それぞれといわれかねない質問だが・・・、
衝突判定は何処で行う？
キャラが他のキャラクタと当たるかどうかを各々チェックする？
衝突クラスなるものがキャラと他のキャラとをチェックする？

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

衝突判定の対象になるキャラを、障害物クラスに登録しておき、
キャラのメソッドで、判定用ベクトルを格納するクラスを生成し、
その判定ベクトルクラスを、障害物クラスに渡している。
障害物クラスで扱うデータは、
オリジナルだったり複数種のFVFだったりするので、
判定そのものはテンプレートにした。

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

5000個くらいのキャラの衝突を総当りでやってたらうざったいもんな。
キャラの最小サイズを１ピクセルになるようにマップを縮小したものを容易。
キャラを移動させたらその位置を塗り替えるが、その場所が既に塗り替えられてれば衝突、もしくは
詳細の衝突判定を行う。
クラスにするまでもないと思うが。