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

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

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

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

**名前は開発中のものです。** · 2008/04/15(火) 17:13:48

>>947
＞しかし一回のフレームを描画するのに全く異なる性質のものを複数回描画させられる
＞時代になった昨今

昨今？
見た目(形状、材質)が異なる複数種のインスタンスを効率よく描画するとか
そういう要請は10年以上前からほとんど変わってないよ

ところで俺の作文を見てくれ

　GPUのモンスターパワーに物を言わせ、パフォーマンスアナライザの類を一切用いずに
　呑気なコードを組んでもグリグリ動くちょい派手エフェクトの3Dアクションゲーがリリースできる
　時代になった昨今

どう思う？

**名前は開発中のものです。** · 2008/04/15(火) 17:29:08

すごく…いい時代です…

って俺なのか？ｗ

**名前は開発中のものです。** · 2008/04/15(火) 17:45:14

わりぃｗｗｗｗ>>948でレスアンカー間違えたｽﾏﾝｺ
×　>>947
○　>>945

＞ここでもしもシーンの各最小単位が各々判断してバッファへの描き出しをやっていると

あれ、中間描画ナンチャラの話はどこへ行ったんだ
「各最小単位」がシーングラフの階層構造内の各ノードのことで
そのノードのdrawメソッドが「バッファへの描き出し」をやるのか？
それ中間描画ナンチャラも何もなく、drawメソッド内で
直接DrawPrimitiveとか呼び出してね？

**名前は開発中のものです。** · 2008/04/16(水) 07:55:31

>>945
シーングラフを使ったことの無い俺が頓珍漢なことを言うけど、
一概にシーングラフって言っても、グラフ構造以外の
動作の実装って、各エンジンによってバラバラなんじゃないの？
その辺をどういう風に実装してるのかを>>944が情報開示しなきゃ、
具体的なアドバイスって出来ないんじゃないの？

ググってみたけどこれに近いの？各個が描画処理を持ってる。
http://www.quatouch.com/products/hisui/doc/scenegraph.html
こんな風に直に描画メソッドを呼び出しているから、
描画の主体がシーンの最小単位って言ってるの？
であれば「各ノードの描画要求」を仲介する管理者を立てればいいよね。
これは末端まで伝播されるコンテキストをその管理者とすると都合が良さそう。
管理者にエフェクト描画フラグとノード描画(node)メソッドを作って、その内部実装は、
if (
　(!nodeはエフェクト) ||
　(nodeはエフェクト && エフェクト描画フラグ)
){
　node.draw(this);
}
これで良いんじゃないのかな。

ただ、各ノードが描画メソッドを持ってしまっているとすると、
ゲームの実行状態と関係してくる複数の描画処理を、
一つのノードに内包させてしまっているのかなという気がするので、
その場合は、描画処理を一つずつノードへ分解しなければいけないと思うよ。

**名前は開発中のものです。** · 2008/04/16(水) 08:14:41

ごめん読み直したら解釈間違ってた。
「エフェクトをばっさり無効にしたい」ってとこだけ意識してしまって、
それが要求だと勘違いしてしまった。
半透明系のエフェクトの描画処理を無効化したいものだと思って
書いてしまったので、変なところは読み飛ばして欲しい。

ほんとの要求は、「描画先バッファを上層で制御したい」ってことだよね。
まあこれも多分、先に書いた管理者のノード描画部分で制御出来るんじゃないのかな。

**名前は開発中のものです。** · 2008/04/16(水) 21:55:02

>>951
＞ググってみたけどこれに近いの？各個が描画処理を持ってる。
そんなかんじです。drawをもってるcompositeパターン
>>952
＞ほんとの要求は、「描画先バッファを上層で制御したい」ってことだよね
制御できるかできないかという意味では
シーングラフがdrawを実装した今のままでも十分制御できます。
リファクタリングの動機は不可能を可能にとか、そういうところにはないと思います。

**名前は開発中のものです。** · 2008/04/16(水) 23:08:47

>>953
Visitor風の実装に変えてみたら？
シーングラフはモデルとマテリアル情報だけ持って、
Visitorがシーングラフをトラバースして必要があれば描画する
ポストエフェクトを切りたければ、ポストエフェクトのVisitorを無視すればいい、的な。

でも、どんなに描画とデータを分離したところで、実際にゲームを作ることになれば
ノード単位でのエフェクト制御（シャドウを落とすかどうか、とか）がどうしても必要になってきて、
末端に細かいフラグが蓄積してしまってあまり意味がないんだよね。

結局、描画エンジンに限っていえば、データと処理の分離は、
最大公約数的な情報を末端のノードに持たせることになって、逆に効率を落としちゃうし、
タイムクリティカルなゲームの最適化を阻害するのが実情。

先進的なエンジンほど、制約がきつい（拡張性が無い、固定機能ばかり）のが現実だから、
何かいい構造を思いついたら発表すれば、一儲けできるかもよ？

**名前は開発中のものです。** · 2008/04/16(水) 23:24:47

>>953
君のシーングラフというのは
ノード(特にdrawインタフェース付きのやつ)同士の接続は何を表しているの
まぁ典型的なものなら座標系(例えば姿勢行列)の親子関係になるわけなんだけど
この場合、巡回目的は行列スタックを積み上げてながら仮想空間上の各ノードの
ワールド座標を得ることだったりするわけだが、その処理の中でdrawを呼び出すの？

**名前は開発中のものです。** · 2008/04/17(木) 03:10:24

>>954
大枠のコンセプトとしてはVisitorということになるのかもしれません。
ただ、VisitorそのものはC++ではその真価を発揮できない、
Compositionツリーの方に新しい要素が頻繁に追加されることが予想される
等、その弱点がちょうど今回のケースにあてはまり、そのままでは適用しずらそうです。
さらに個人的な感想をかけば、型と場合に応じて関数がいくつもできあがるのは好みません。

それこそ中間描画パケットのようなローテクなアプローチが必要なのかもしれないです。

**名前は開発中のものです。** · 2008/04/17(木) 07:36:26

>>956
> ただ、VisitorそのものはC++ではその真価を発揮できない、
コードを書いてみてくれ。なんか勘違いしてるような気がするんで。

**名前は開発中のものです。** · 2008/04/17(木) 10:20:54

>>956
ゲームに使う分には、ノードに種類フラグを持たせて、適切にアップキャストするのが常套手段だね。
Visitorは対応している種類のノードだけ処理する。
Visitorの関数の数の爆発にも、ノードの種類の増加にも簡単に対応できる。
ダブルディスパッチが目的ではないから、Visitorとはコンセプトが少し違うな。
イテレータに近いかも。

**名前は開発中のものです。** · 2008/04/22(火) 22:42:37

>>956
つNVSG
Traverserあたりを調べればそういう基本的な悩みは解決すると思う。

**名前は開発中のものです。** · 2008/04/23(水) 18:23:23

>>959
とても参考になりました。
シーングラフはあくまでデータの一群であって
それぞれの目的をその名に冠したtraversalがそれを利用してそれぞれの目的を果たすと。
レンダリングもtraversalの一種に過ぎないと。そんな解釈みたいですね。

ただコレ、NodeHintsなるものとか、ShadowMappingがなぜか埋め込まれてるとか
ちょっと気味が悪い部分もありますね。

**名前は開発中のものです。** · 2008/04/23(水) 19:09:53

＞ちょっと気味が悪い部分もありますね。

具体的に言ってごらん

**名前は開発中のものです。** · 2008/04/23(水) 20:47:19

>>960

>>954　に
> ノード単位でのエフェクト制御（シャドウを落とすかどうか、とか）がどうしても必要になってきて、
> 末端に細かいフラグが蓄積してしまってあまり意味がないんだよね。

ってちゃんと書いてあるじゃねえか
NVSGはその典型例だよ

**名前は開発中のものです。** · 2008/04/25(金) 00:41:21

ノード毎の付加情報はあってもいいでしょ。各々のトラバーサーが自分に必要な
属性を処理すればいいだけ。C#のAttributeなんかが同じ要求から出てきたものじゃないかと思う。
プロパティグリッドの情報はオブジェクトにとって本質的じゃないけど、オブジェクト側に埋め込んでおきたい
みたいな。

**名前は開発中のものです。** · 2008/04/25(金) 00:47:43

C#のAttributeは型とメンバにメタデータを付ける機能だよ
オブジェクトには付けられない

**名前は開発中のものです。** · 2008/04/25(金) 01:13:35

インスタンスって意味でオブジェクトって使ったわけじゃないんだけど・・・。
じゃまぁ、s/オブジェクト/クラス・メンバ/ということで。

**名前は開発中のものです。** · 2008/05/05(月) 14:08:00

ほしゅ

**名前は開発中のものです。** · 2008/05/11(日) 16:38:51

プログラム板のデザインパターンスレから誘導されてきました。
ゲームを作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。

Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。

**名前は開発中のものです。** · 2008/05/11(日) 16:57:46

シングルトン滅びろ

**名前は開発中のものです。** · 2008/05/11(日) 17:02:04

バカほど背伸びしてアレコレ使いたがるよな。

**名前は開発中のものです。** · 2008/05/11(日) 17:24:11

やる気になってる馬鹿が一番伸びるだろ。
いい気になってる自称天才が一番伸びねえよ。

**名前は開発中のものです。** · 2008/05/11(日) 17:28:01

背伸びしてアレコレ使わないとバカとやらを脱出できないだろう。
少なくとも「糞だって他の人が言っていたから」
という理由だけで、一度も使ったことのないモノを非難する人よりはマシ。

**名前は開発中のものです。** · 2008/05/11(日) 17:42:18

デザパタの中でシングルトンが一番わかりやすいと思うんだけどなあ

**名前は開発中のものです。** · 2008/05/11(日) 17:52:03

>968-971を俺なりに要約すると、
・基本的な仕組みが判ってれば問題無い。
・ゲームを作っていけば、自ずと使う場面がわかるはず。
・判らないようじゃ、ゲーム制作に向いてない。
・むしろ技法を知らなくても何時の間にかそれっぽく書けるのが理想。
・使う言語が決まってるなら、そのスレを当たるのお勧め。

**名前は開発中のものです。** · 2008/05/11(日) 18:00:20

>>967
「クラスのインスタンスがひとつだけであることを保障する」というシングルトンの目的が
必要になる場面なんてほとんどないから、ピンとくるわけがない。

グローバル変数大好きなやつが免罪符みたいに使ってることのほうが多いから、
強いて言えば「グローバル変数が使いたいとき助かる」と言えるかもしれない。

**名前は開発中のものです。** · 2008/05/11(日) 18:16:18

>>974
画像を先読みしておいて使いまわしたい時には、
シングルトンで先読みして、
必要な時にクラス作って呼び出すってやってるんだけど、
これってもしかして、間違えてる？

**名前は開発中のものです。** · 2008/05/11(日) 18:30:24

>>975
それのどこでシングルトンが必要なのかわからない。

**名前は開発中のものです。** · 2008/05/11(日) 18:36:53

＞判らないようじゃ、ゲーム制作に向いてない。
はじめから知ってろってことか

**名前は開発中のものです。** · 2008/05/11(日) 18:40:49

（明示的な）グローバル変数が無い言語(java?)なら必要かもしれないけど、
ハナからある言語ならシングルトンなんてスパゲティ抑止策としか思えない。
そういう言語だとシングルトンは必要と言えば必要だし、いらなきゃいらない。

と言うわけでお前等落ち着け。

**名前は開発中のものです。** · 2008/05/11(日) 18:41:31

>>976
つーことは。間違えてるのか。
描画クラスをダレに持たせるかが分からなくて、
ダレにも持たせないのを選択したのが、悪いのかな？

**名前は開発中のものです。** · 2008/05/11(日) 18:42:43

書き忘れ。Ｃ＋＋でウインドウズ用のプログラムを作ってました。

**名前は開発中のものです。** · 2008/05/11(日) 18:53:03

コンストラクタやデストラクタが、近いように見受けられますが
それで済むなら、シングルトンは必要ないですよね。
一つしか存在しないのを分からせる為の目印と言うには分かりにくいですし…
となると、シングルトンが作られた目的というか、用途があるはずですが
例えば、データを受け取って、それをファイルへセーブするクラスはどうでしょうか。

キャラ毎に進行状況やフラグをセーブするような場合や
キャラリストファイルから特定のキャラを選び、探索チームを作成し
そのチームのキャラデータのみをキャラリストファイルへ反映させる場合です。
wile(チームの終わりまで) {
　Team[ chara_pos ].save()
}
（そんなごちゃごちゃしたセーブのやり方をするなと言うツッコミはなしで）

**名前は開発中のものです。** · 2008/05/11(日) 18:57:03

>>979
描画クラスは一つ一つのキャラクターが持つはず。
画像は同じでもアニメのパターンが違ってたりするので。

>>976
STGのザコ敵で、同じ画像を使っていて、何百匹も出る場合です。

**名前は開発中のものです。** · 2008/05/11(日) 19:03:55

ｇｄｇｄだなぁ…

クラスに画像が固定ならシングルトンでも良いけど、
可変なら微妙じゃね？
（シングルトンで可変な数の画像読むなら別だろうけど、
それはそれでアクセス方法がシングルトン的じゃなくなりそうｗ）

つか、必要か不要か二元論な奴は、
議論する暇あったらミニゲームでも作って、
いろいろ試したらどうよ…

**名前は開発中のものです。** · 2008/05/11(日) 19:38:15

質問する方も答える方もバカでﾜﾛﾀｗ
背伸びしすぎｗ

**名前は開発中のものです。** · 2008/05/11(日) 19:38:35

> 一つしか存在しないのを分からせる為の目印と言うには分かりにくいですし…
・シングルトンを知っていれば分かる
・知らずに2個インスタンスを作ろうとしても作れない
これ以上に分かりやすい目印はないと思うが。

**名前は開発中のものです。** · 2008/05/11(日) 20:27:08

今、自分は、地図を開いて「このマークはわかりにくい」と言ってるような
現状だというのは分かっています。
マーク単体の意味は分かっても、それを利用する為の判断基準のようなものが
自分の中にまだ備わっていないので、先達の方に例を示して貰えないかと来てみたわけです。

**名前は開発中のものです。** · 2008/05/11(日) 20:50:58

いい加減くどいな。ゲーム作り始めれば判るよ。お前だって
「自転車のハンドルを右にきる理由は理解してるのですが、タイミングは何時ですか？」
と聞かれたら「転んで憶えろ」と言うしかないだろ？

**名前は開発中のものです。** · 2008/05/11(日) 20:51:58

シングルトンて言葉にするの、何か恥ずかしくね？
「このクラスはシングルトンです。」
とか真顔で言える気がしない。
唯一のインスタンスを保障するだけの癖に
大層な名前がついてるなって思う。

**名前は開発中のものです。** · 2008/05/11(日) 20:52:35

とりあえず言わせてくれ。
みんな話題待ちすぎｗｗｗ突然レスがつきすぎだぜ

**名前は開発中のものです。** · 2008/05/11(日) 21:04:49

>>967
ハンドルとか設定とかを持たせるときとか

**名前は開発中のものです。** · 2008/05/11(日) 21:05:29

シングルトンは人に説明するのに便利すぎる
他のパターンと違って誤解される可能性が低いのと他よりは知名度高いからよく使ってる

でも、デザパタって意外と知ってる人少ないよね
普通に会話に使うもんだと思ってGoF勉強したけどほとんど通じない

**名前は開発中のものです。** · 2008/05/11(日) 21:07:20

ところで、シングルトンは
インスタンスがなければ生成してから返し、ある場合は既にあるインスタンスを返す関数が在るってことであってる？
個人製作なら自分ルールで最初にその手のインスタンスは初期化する、って決めておけばいらなそう。

複数人で開発する場合で、その手のインスタンスを前もって初期化したくない場合は効果がでるかもわからん

**名前は開発中のものです。** · 2008/05/11(日) 21:07:32

>>987
不幸なことに、シングルトンが必要と思われるケースのプログラムを
今までに組んだことがありません。
極端な言い方をすれば、この先シングルトンを使う場面に遭遇しなければ
シングルトンが何なのかさえ分かりません。
知っていて使わないのと、知らないで使えないのでは大きく意味が違うと思います。

**名前は開発中のものです。** · 2008/05/11(日) 21:29:15

ム板のデザインパターンスレに戻った方が良いと思うよ。
ここはGoFすらろくに知らないで設計語ってるスレだから

**名前は開発中のものです。** · 2008/05/11(日) 21:32:50

業務系とゲーム系だとまた求められてるものが違うから

スコープはコンテナが管理するというのが今の流れだよね
シングルトンであるとかプロトタイプであるとかで構成は変えないしね

ゲームなら面とかでスコープかえると初期化が楽になるかもしれないけど
メリットはあまりないかと

オンラインゲームなら必須の知識ではあるけど

**名前は開発中のものです。** · 2008/05/11(日) 21:45:37

>>993
だったら使うなよ。くだらん豆知識さっさと忘れてゲーム作れ。
気がつけば「あ、これシングルトンだったね」と気がつく日もあるだろう。

**名前は開発中のものです。** · 2008/05/11(日) 21:55:34

>>996
失礼ですが、他の人が言ったことを繰り返して言っているだけの言動からは
貴方がデザインパターンを理解しているとは到底思えません。

**名前は開発中のものです。** · 2008/05/11(日) 22:13:28

挙句の果てに、妄想で批判とか、折角ゲーム作るように促してやってるのに困った奴だな…

**名前は開発中のものです。** · 2008/05/11(日) 22:24:00

>>998
スレタイを確認した方が良いんじゃないですか？

**名前は開発中のものです。** · 2008/05/11(日) 22:24:58

他の方々のレスは大変参考になりました。
ありがとうございました。

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。