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

**名前は開発中のものです。** · 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 のパックマンでキャラ画像情報とかって
どこに持つ？

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

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