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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体的に言ってごらん

>>960

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

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

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

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

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

ほしゅ

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

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

シングルトン滅びろ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ｇｄｇｄだなぁ…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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