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

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

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

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

**名前は開発中のものです。** · 2008/03/24(月) 01:33:58

>>875
読み違えてはいないけど矛盾もしていない？
余計にわからなくなって混乱してきたので一晩寝て考えてみる。
色々有難う。

**名前は開発中のものです。** · 2008/03/24(月) 01:41:01

>876

>864氏の主張を僕なりに解釈

●前半
敵データを記述するにしても、
テキストファイル（CSV）の場合もあれば、バイナリデータの場合もある。
ゲームによっては、ネット越しにデータベースへアクセスするかもしれない。
そういう部分を汎用的に書くのに継承は有効。

●後半
スライムとスライムベスとホイミスライムとドラゴンとオオアリクイと彷徨う鎧とで
いちいちクラス作ってたら一生終わんなくね？

**名前は開発中のものです。** · 2008/03/24(月) 08:29:41

864だが、なんかいろいろと混乱を招いたようですまん。そしてさらに混乱させるのだが……

自分自身の意見としては>>877の通りなんだが、
種類ごとにクラスを作るような継承の使い方が全く見当がつかなかったので質問させてもらった。

本気で全種類分クラスを作るのか、
それともスライムとスライムベスはスライムクラスにまとめてしまうのか、
その場合出現テーブルなど外から参照するときはどうするんだ(クラス名？)とか、興味が尽きない。
実際どうやるんだ？

>>872のはどちらかというと戦闘時イベント(HP半減で台詞とか死亡エフェクトとか)など特殊処理を意識したものだと思うので
>>869の話を聞いてみたい。

**名前は開発中のものです。** · 2008/03/24(月) 12:03:07

集約とかせずに強引に継承で表そうとするとそうなるんじゃね。
と869ではないが予想

**名前は開発中のものです。** · 2008/03/24(月) 14:53:51

オナニーの話
クラス分けして幾つもの「科」を作り、何十もの「目」を作った
そして何百もの「種」を作ろうとしたとき、僕は秀丸のマクロで
大量のクラス(hpp、cpp)を作っていた

何かを間違えていることに気付き始めたのはその時だった
あれは14歳の夏休みでした

**名前は開発中のものです。** · 2008/03/24(月) 14:58:03

14歳か… その時、俺は何やってたかなー。6001とか叩いてた気がする。

**名前は開発中のものです。** · 2008/03/24(月) 15:00:11

＞本気で全種類分クラスを作るのか

本気で作ったよ。リビルドにかかる時間の長さに興奮した

**名前は開発中のものです。** · 2008/03/24(月) 15:00:26

C#でモンスターの基底クラス作って
IronPythonでスライムクラスとか全部継承で作ったら面白いかも

**名前は開発中のものです。** · 2008/03/24(月) 15:09:53

strategyパターンオヌヌメ

**名前は開発中のものです。** · 2008/03/24(月) 16:18:36

>struct IEnemy;
>class EnemyBase : public IEnemy {};

まだこんな命名規則使うやつ居たのか

**名前は開発中のものです。** · 2008/03/24(月) 16:25:13

>885
おまいは変数hoge や Func()関数にまで突っ込むのか

**名前は開発中のものです。** · 2008/03/24(月) 18:49:57

＞本気で作ったよ。リビルドにかかる時間の長さに興奮した
ひさしぶりに勇者を見た。

>>883
行動パターンとかをスクリプトにして外出しにするわけか。
でも動的に作成するのはなんだかコストが高そうな気がする。

**872** · 2008/03/24(月) 21:24:32

うん。一晩寝て考えが纏まった。

昨日のあらすじ
>>864継承使うよ（外部データ読み込むのにね）
>>870継承使わないよ（外部データで弄えばいいじゃん）
>>874（俺）矛盾しているやん！どっちやねん！？
>>875矛盾してるように思えないんだが
>>876（俺）え？！！

↑は置いといて取り敢えず1番の疑問の解消から…
>>864
>継承って、外部ファイル読み込みを外部データベース読み込みに変えるとき楽になるとか

ごめん。この継承の使い方、どんな使い方なのかまるで想像できない。
どんなの？

**名前は開発中のものです。** · 2008/03/24(月) 22:09:39

できれば、せっかく俺が書いた>877を読んでくれるとありがたいんだが。

**872** · 2008/03/24(月) 22:16:59

ああ、もちろんちゃんと読んでいるよ。

**名前は開発中のものです。** · 2008/03/24(月) 22:45:28

いや、読んでたら>888の発想は出てこないだろ？

**872** · 2008/03/24(月) 22:48:16

悪い。マジですまん。理解力なくて。
もうちょっと考えてみるわ。

**名前は開発中のものです。** · 2008/03/24(月) 22:56:35

まず

　>>864継承使うよ（外部データ読み込むのにね）
　>>870継承使わないよ（外部データで弄えばいいじゃん）

この時点で間違えてる。

**872** · 2008/03/24(月) 23:01:16

>>893
うん。たぶん自分が曲解しているんだろうと
そう思って>>874を書いたんだけど
>>875で矛盾していないっていわれたもんで
>>876 え、別に読み違えていないの？に到って
>>877読めば>>888にはならんだろと言われて余計に？？？？

**名前は開発中のものです。** · 2008/03/24(月) 23:23:01

お前はまず落ち着けｗ

>894の疑問に関してだけ言うとだ。
>874と>888とでは、お前さんの言ってる内容が異なる……と、自分は感じた。

>874の文章を読んだ限りでは、ちゃんと理解しているように見える。
>888は間違って理解しているように見える。

>864は
・データの読み込み方法（外部ファイルとかデータベースとか）については、派生クラスを作るべき
・データだけが違うオブジェクトについて、いちいちクラス分割するのはどうなんよ？正しいの？（疑問系）
の2点について述べている。
具体的には>877を参照してほしい。

>870は
データが違うだけのオブジェクトについて、クラスを分けるのは最適ではないのでは？と述べている。
データの読み込み方法については何も述べていない。

よって、両者は矛盾していない。

**872** · 2008/03/24(月) 23:54:26

>>895
おけ。落ち着いたｗ
やっと謎が解けた。
俺が単純に「継承使う」←→「継承使わない」で相反していることをいっているように
感じて何故かそこに噛み付いて「矛盾している！」叫んでいただけで

ずっと
「外部データの読み込みの為には派生クラスを作るけど、
　データの違いで吸収できるようなことにまで派生クラス作ってどうすんの？」
って主張してるだけで別に矛盾なんてしてねーじゃん
―と。

うん。それなら問題ない。確かに自分は読み違えてはいなかった。
変な方向にこだわって混乱させてスマン。
元々>>860でいうように継承使わない派だからクラスをうじゃうじゃ派生しない方が
良いのはわかるし。

残る疑問は「外部データを読み込みを楽にするために派生クラス」ってやつ。
これ、さっぱり実現方法がわからない。

**名前は開発中のものです。** · 2008/03/25(火) 00:54:06

えー？
インターフェースさえ揃えておけば
差し替えが楽になるってだけの話でしょ。

virtual void Img::Load(DestPtr* dst, FilePtr* src);
を継承したクラス郡
void Jpg::Load(DestPtr* dst, FilePtr* src);
void Png::Load(DestPtr* dst, FilePtr* src);
void Gif::Load(DestPtr* dst, FilePtr* src);
を作って差し替えるのが楽ってだけの。

**872** · 2008/03/25(火) 01:22:10

>>897
有難う。
説明するまでもないほど常識的なやり方なのね。
勉強不足ですまん。勉強になった。
ファイル形式が違うのを読み込むときに記述が楽出来るのね。

**名前は開発中のものです。** · 2008/03/25(火) 01:41:22

RPGなんてデータ駆動の典型だろ・・・

**名前は開発中のものです。** · 2008/03/25(火) 02:09:10

落ち着け。
お前は本当に872か？ｗ

**872** · 2008/03/25(火) 02:11:16

>>899ごめん
そもそも>>860でRPGを例に出したのが間違いだった。
敵の名前を皆が知ってるゲームでぱっと思いついたので安直に選んだ。
今思えばスーパーマリオの方が例としては良かった。

継承アレルギーの自分ならENEMYクラスひとつだけにして
全部データの違いで吸収するかなと。

ゲーム制作中にメットっていうファイヤーボールの効かない亀を思いついたとしても
ノコノコからの特化キャラとして派生させたりせずに
メンバ変数fireArmorを追加してメット以外のキャラを0に設定するかな。

**872** · 2008/03/25(火) 02:13:27

>>900
>>898の書き込みのこと？
俺また何か変なこと言ってる？

**名前は開発中のものです。** · 2008/03/25(火) 03:09:13

ゲームルールとか現実世界に複数の同種に思えるものが見出せるから
という理由で継承の木にあてはめてしまうのはダメだよ
ていうかそんなのならやらない方がいいswitch文でよろしい
インターフェイスやスーパークラスを使う側に何が必要かということ
隠蔽のニーズのほうを第一に考えるべき

**名前は開発中のものです。** · 2008/03/25(火) 06:25:37

君は872ではなくて862だと思うんだ。

**×872 ○862** · 2008/03/25(火) 10:48:21

>>904
ほんとだ。スマン

**名前は開発中のものです。** · 2008/03/25(火) 14:06:40

可愛いやつめｗ

**名前は開発中のものです。** · 2008/03/25(火) 21:21:33

お前ら、委譲を使えよ。

継承は多態が必要なときにしか使わないな。

**名前は開発中のものです。** · 2008/03/25(火) 22:47:32

継承より委譲を使えという文句が結構有名なためか、
委譲の形に書き直す際に、書き直す前の委譲元オブジェクトの継承関係を
委譲先オブジェクトがそのまま引き継いでしまうようなソースを書いても
何の疑問も持たない奴が意外と多いから注意な。
どの部分を委譲すればよいか、粒度は適切かどうかを見極めたうえで
コーディングすべき。

**名前は開発中のものです。** · 2008/03/25(火) 23:18:21

当たり前のことだと思うんだが

**名前は開発中のものです。** · 2008/03/26(水) 00:49:14

よくよく考えれば当り前なことを
当り前だと認識する(定石・パターンを共有する)のが
設計・パターンの学習の第一歩なわけだから、
>>909は最も必要な思考ではあるが
最もレスしてはいけない文章でもあるな。

**名前は開発中のものです。** · 2008/03/26(水) 05:21:20

ようは継承元の機能を手っ取り早く取り込む目的で継承をつかうな
ということだよ
そういうローカルな問題を解決するのに使ってしまうと
もっと大局的な構造を記述するために使われている継承との一貫性がなくなる

名前のつけ方からして一貫した目線であるべきなんだよ
ゲームを作ってる俺達はApplicationやSystemやEngineって呼べる一番高い位置から
見ているのだから敵キャラをEnemyと呼ぶのはおかしいよ
こんなのたまたまプレイヤーに敵対的なAIが乗ってるだけのゲームオブジェクト
に過ぎないんだから

データの入出力の種類どうこうはそんなの多分インスタンスが生成される必要も
ないんだろうからswitch文かなにかで書けば充分
「現実世界ではこれは～の一種類とされています」なんてのを継承で
示してみせたところで後で見たとき何の役にも立たないわけだよ

**名前は開発中のものです。** · 2008/03/26(水) 08:27:56

>>911
Enemyクラスを作ろうが、一ゲームオブジェクトの処理内容をベタ書きしようが、
どちらもApplicationが敵を直接意識して操作しているという悪例に他ならず
そういった意味で両者の違いなんてほとんどないに等しいから
「現実世界のものどおりに継承関係構築するのは無意味だ」という主張の
引き合いとして「名前の付け方からして～」以下の文章を出すのは
あまりにも不適当で意味不明。

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

ADVやRPGでシナリオの流れを状態で切り分けすることが多いと思います。
「1回目にここへ来たときはこっちのシナリオ、2回目以降はこっち」
「○○のアイテムを持ってるときに○○を調べるとこっちのシナリオ」
「○○への好感度が８０以上のときに話しかけるとこっちのシナリオ」
様々な切り分け方があると思うのですが、そういう条件式とルートを
統括的に扱えるような設計というかやり方ってあるのでしょうか。
今やってるのはもうごちゃごちゃで、テストが不安で仕方ありません…

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

ADVなら、シナリオがツリー構造になってたりグラフ構造になってたり
いろいろなタイプがあると思うけど、それぞれのシーン内の分岐は
基本的にはif分の羅列になると思うんだ

あとこういう枯れたジャンルなら既にある優秀なツール、例えば
RPGならRPGツクールを、ADVなら吉里吉里とかNスクを
それぞれ参考にするといいんでねの

サンプル見たりチュートリアルに沿って使ってみたりすれば
イベントの基本構造とかが何となく見えてくるぞ

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

>>913
基本的には if 文の羅列だけど、たとえば RPG なら

・基本となるスクリプト

を用意しておいて、その上で条件が成立したときだけ
オーバーライドする内容を列挙した

・派生スクリプト

を上にかぶせるような作りにしておくと、多少は管理が楽になる。

**名前は開発中のものです。** · 2008/04/12(土) 15:28:03

>>913
ちょっと考えたけど難しいわ。降参。
とりあえず綺麗にソースを書いといて。
シナリオそれぞれに分かりやすい名前付けといたがよさそうね。
300件以上とかあるだろうから、どうやって名前付けるんだろう・・・

**名前は開発中のものです。** · 2008/04/12(土) 21:03:35

913のような問題は、構造化プログラミング的なコードだけで実現しようとすると
if文の羅列で凄まじいネストになってしまったりして見難くなるんだろうなぁ。
まぁそういう制御の部分を、コードではなくスクリプトでなるべく見易くするってのはいいよね。
これらの方法は、全ての状態をグローバルなフラグなどで管理することになるのだろうから
セーブやロードとかの処理は、結構簡単で良さそうだね。

915のいうような感じで、条件や処理を一つのオブジェクトに見立てて
それらを動的に拡張していくような構造なら、いままでのフラグ的なものを
上手いこと隠蔽化してくれそうに思うので、一歩進んでいると感じるなぁ。
ただこれは、とあるポイントに複数の拡張が生じる場合を考えると、
優先順位が必要になると思うので、そこは考慮しないといけないね。
場合によっては一つの拡張の優先順位が複数存在することもありそうだし、
拡張の呼び出し元を拡張要求ってなものにして、それに優先順位と実拡張への参照を持たせるといいのかな。
あと現在の拡張状態をセーブするのがちょっと面倒なのかなって思う。

**名前は開発中のものです。** · 2008/04/12(土) 21:12:31

シナリオ構造をグラフにして、ステートマシンで管理すればOK

**名前は開発中のものです。** · 2008/04/12(土) 21:40:58

>>917
> 優先順位が必要になると思うので、そこは考慮しないといけないね。
実際には、ほとんど必要ない。そこまでやると、シナリオ担当がついてこられなく
なるから。

**名前は開発中のものです。** · 2008/04/12(土) 22:32:44

>>918
ステートマシンって一般的な単語なのかな
波動やってないとたぶん分からないきもするが

でもそんなににきがつくならこんなアホな質問はせんか
スクリプトだろうがコードだろうがっどっちも同じプログラムであって根本の話ではないし

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

>>920
> ステートマシンって一般的な単語なのかな
プログラマには常識だと思うな。

学生さんでも、大学で情報系専攻してれば必修だし。

**名前は開発中のものです。** · 2008/04/12(土) 23:11:40

考え始めたらこれ結構面白いなぁ。
さっき書いた動的拡張をスクリプトにするとして俺ならこんな感じ。

object 村人
　abstract action 会話

object 村人A extends 村人
　action 会話
　　message("おいらは村人A！")

action 魔王を倒した
　object 喜ぶ村人
　　action 会話
　　　message("あんたのお陰で村は平和だぜ！")
　dynamic extend 喜ぶ村人 on derived(村人)

action なんか知らんが魔王が復活した
　cancel dynamic extend 喜ぶ村人 on derived(村人)

>>920
ステートマシンて情報処理系の試験に出ないっけ？
波動(？)と何か関係あるの？

**名前は開発中のものです。** · 2008/04/12(土) 23:31:33

ものすごくスパゲッティになりそう

**名前は開発中のものです。** · 2008/04/12(土) 23:37:53

ここの住人はみんな情報系なのかな

**名前は開発中のものです。** · 2008/04/12(土) 23:45:24

波動ってハードのことね
ハードだと普通に使う、というかこの考え方がないと組み込みのコードもかけないだろ

**名前は開発中のものです。** · 2008/04/12(土) 23:48:56

>>922
誰でも一度は考えるなｗ
とはいえ、”いかに綺麗な構造を実現するか”より、
”いかに大量のフラグを管理するか”を中心に据えてツール類を整備した方が
スクリプターも楽だし、メンテもし易く、バグも出づらく、高速なコードができあがるという罠。

**名前は開発中のものです。** · 2008/04/13(日) 00:12:34

class Event
があって、List<Event> に全イベントをステージ最初にぶち込む。
で、各フェーズ毎に全イベントに、発動可能かを問い合わせる。
発動可能なら、キャラの位置を調べて、イベントの位置と合致する
なら実際にイベントを発動。

これ、chain of responsibility

**名前は開発中のものです。** · 2008/04/13(日) 00:29:46

DirectXと付き合うこと数年。
描画担当をエンティティから切り離すのはいいとして
その描画担当がシーンツリーの奥深くまでLPD3DDEVICEをもっていって
最底辺でd->SetRenderStateとかやってるのは
最近マルチパスレンダリングとか外部ファイルになったシェーダー等を考えるに
適当でないと感じるようになってきた
何かいいデザインがあるでしょうか

**名前は開発中のものです。** · 2008/04/13(日) 00:35:14

中間描画パケット使うてのはどうよ？
MTFrameworkやPSSG（はちょっと違うが）も似たような方式だし。

[シーンツリー] --(生成)--> [中間パケット配列] --(最適化)--> [最終中間パケット] --> [描画]

って流れで。
DirectX本体は、パケットの配列を読んで実行するのみで、シーンツリーには一切関与しない。

描画部を完全に切り離せる上、最適化部もシーンツリーのトラバースと分離できるメリットがある。
ただ、マテリアルやマルチレンダーターゲットの表現が難しい（的確なパケットを定義しないと冗長になってしまう）から、
パケットの設計が一番大変かと。

**名前は開発中のものです。** · 2008/04/13(日) 00:44:07

>>926
確かにその通りだよね。
今目に見えているものだけで動作を予測できるか、
ってとこがポイントなのかな。
自分でも、さっきのスクリプトみたいなのをスクリプターが頑張って書いても、
いざ実行してみて( ﾟдﾟ)ﾎﾟｶｰﾝってなってるのが目に浮かぶし。

でもそれは、専用のスクリプトエディタ的なアプリを作って
今見えているスクリプトに関連する情報を注釈としてオーバーレイ表示して
直ぐに関連を理解させることさえ出来れば結構改善できる気がするんだよね。
プログラムでクラス指向が普及しているのも、IDEによる直感的な補佐の
影響が効いているからだと個人的には思ってるし。

でもまぁ、一般的に想定出来る量の分岐のゲームで
ここまでやることはきっと割に合わないのだろうなぁと思う。
ただ、最近はオブリビオン(やったことないけど)とかいう、
莫大なスクリプトが存在するらしいゲームも出てるらしいじゃん。
そういったゲームリソースの肥大化から考えると、
こういうの考えておいて損はしないと思うんだよね。

**名前は開発中のものです。** · 2008/04/13(日) 00:57:00

>>927
こう書いたが良かった。List<Event*>
判定処理はConcreteEventクラス毎に違う

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

なんか勉強になる

**名前は開発中のものです。** · 2008/04/13(日) 04:39:58

>>929
MTFrameworkとかよくわからんけどデバイスコンテキストを持ちたくないとか、
ステートマシンにかかわりをもちたくないとか
単純なそういうものの隠蔽を望んでるわけじゃないのです

たとえば各個がDraw()を実装するような構造だと、シーンに一回デプスバッファだけ描かせるようにする
とかいう改変をしなくちゃならない場合に全部にDrawDepth()みたいな名前で同じようなことを
しなくちゃならん実装をしないといけないのはちょっと変だと思うわけです。

具体的な描画の手続きが末端におしつけられてる構造がなんとかならないかなと思ってるのかも。
わかりません。

**名前は開発中のものです。** · 2008/04/13(日) 05:37:30

>>933
自分でも分かってないのかよｗｗｗ
まぁ俺は末端の描画処理に上層から介入したいのだと見たよ。
その前提で答えてみる。

現状ツリー上に階層化された描画物は、上層から
IDirect3DDevice*を引数としてリレーしたものを使って描画してるわけだよね。
んでこれらの描画物の描画処理に変化を加えたいということであれば、
上層で、IDirect3DDeviceを拡張したインスタンスを作りそれを下層へ放流すれば良い。
分かるかも知れんが詳細にやり方を書くと、IDirect3DDeviceって確かクラスだったよね？
であれば単純に継承して各メソッドで本物のインスタンスへの委譲メソッドを書く。
そしたら自分が拡張したいメソッド、この場合SetRenderStateか？を好きなように変更する。
そんな感じでどうよ。
もちっと考えると、そもそもIDirect3DDeviceなんかを末端から直接触らせずに
自作クラスでラップしたものを使わせるようにすると見易いし色々と便利かと思うな。

こういう考え方、きっとよく知られてる知識なんだと思うけど、俺はJavaやって初めて知ったよ。

**名前は開発中のものです。** · 2008/04/13(日) 09:09:47

そういうことするなら直接継承はしないだろ

**名前は開発中のものです。** · 2008/04/13(日) 10:23:53

>>929
なるほど意味分かった。
形状描画とマテリアル（描画嗜好）分離されてるからそれでいいねえ

**名前は開発中のものです。** · 2008/04/13(日) 11:40:53

>>935
インタフェースなんだから直接継承しても問題ないんじゃないの？
あれ、ごめん、C++だとIDirect3DDeviceのメソッド郡はvirtualじゃないのか？
となると単純に継承しても元の型でアクセスされると拡張されたメソッドが呼ばれないのか。
じゃああれだ、自前クラスにするだな。

**名前は開発中のものです。** · 2008/04/13(日) 14:26:45

カプコンのなんとかフレームワークをパクればいいじゃない

**名前は開発中のものです。** · 2008/04/13(日) 14:39:55

言うは易し、行うは難し

**名前は開発中のものです。** · 2008/04/13(日) 18:58:15

中間なんたらを使うにしても結局ひとつのフレームを描画するための手続きが
シーングラフの各最小単位に分散してしまうのを僕は懸念してるのだと思うのです。
優先度みたいな古臭いタスクの仕組みが採用さられてるようだけれど結局
「あれ？この直前の優先度は何番だｔったっけ」とかいって探し回るマヌケな姿が目に浮かぶ
です。
MTFrameworkでぐぐってもimpressのアレしかでてこないのでこんな批判ですが
何か他に資料が公開されてるのでしょうか？

**名前は開発中のものです。** · 2008/04/13(日) 20:37:38

会社の機密情報をホイホイと公開すると思うの？
ｊｋ。

**名前は開発中のものです。** · 2008/04/13(日) 20:59:07

MTFrameworkについては公に出回ってる話しか知らんが

＞優先度みたいな古臭いタスクの仕組み

意味わからん
ハードウェアに渡す描画コマンドに優先順位があるのは今も昔も同じだし
よって投げるパケットに優先順位があるのも別に古臭くもなんとも無い
つか必須

「タスクの仕組み」がナニを指すのか知らんが、タスクシステムスレで言うところの
タスクシステム（＝ギャラクシアンの実装）の話をしてるのなら、あれは
エンティティ処理も描画処理も何もかも内包してる概念だから、ここでその話題を
持ってくるのは何か違う気がする

エンティティを線形リストに入れるだけなんて古臭い、シーングラフを使うのが現代的
などという話をしたいなら、それはここでは無関係の話題と思われ

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

＞描画するための手続きがシーングラフの各最小単位に分散してしまう

ないない。MTFrameworkだろうがその他のミドルウェアだろうがそれはない
各エンティティがグラフに入ってようが何であろうが自由だし
そのグラフ走査の順序でエンティティ更新処理が決定していようが

GPUに投げる情報の順序とは独立した、全く別の話

**名前は開発中のものです。** · 2008/04/13(日) 21:47:18

＞れはここでは無関係の話題と思われ
＞GPUに投げる情報の順序とは独立した、全く別の話
はい。MTFrameworkがいい、だめ、といったことを話したいんじゃなくて
MTFrameworkみたいなのの上の層の、中間描画パケットや描画の手続きを投げつける
構造のほう
のアイデアを伺いたいんです。

でもシーングラフ的構造を改めて設計でやりくりしようとせず
そこはそのままの形を留めたまま横断的事象を管理するために
一旦描画手続きをバッファにまとめる、というのもひとつの現実解なのかもしれないですね。

**944** · 2008/04/15(火) 05:27:06

>>943
＞ないない。MTFrameworkだろうがその他のミドルウェアだろうがそれはない

「手続き」というのは適当ではない表現だったとおもいます。
中間描画パケットはシーングラフの構成とは無関係に共通するシェーダをまとめあげる
役には立つと思うんだけど（そのためにつくられた仕組みなんでしょうし）
描画の主体は依然としてシーンのノードにあるのが普通だと思います。
全体としてみればシーングラフのツリーが描画をしていると言うことができるはず。
具体的にはシーンの最小単位がdrawとかいう名前のインターフェイスを持っていて
ここがパケットを発行するようになっているはず。

しかし一回のフレームを描画するのに全く異なる性質のものを複数回描画させられる
時代になった昨今、drawがここにあるのに違和感を感じる場面に遭遇することが多くなりました。

たとえばあるポストエフェクトのためにバックバッファとは別のバッファへデプスを描きだしていたとします
ユーザーの設定や場面によってそのエフェクトをばっさり無効にしたい場合
このバッファを描画する必要もなくなるわけです。ここでもしもシーンの各最小単位が
各々判断してバッファへの描き出しをやっていると大変なことに。シーンの最小単位が
描画の主体であるがゆえにこういった非効率が生じるわけです。

シーングラフとは別に描画の主体が存在するべきなのかもしれません。わかりませんが。

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

ガンダムに例えるとどういうこと？

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

>>945
>描画の主体は依然としてシーンのノードにあるのが普通だと思います。
>全体としてみればシーングラフのツリーが描画をしていると言うことができるはず。
>具体的にはシーンの最小単位がdrawとかいう名前のインターフェイスを持っていて
>ここがパケットを発行するようになっているはず。

シーングラフのノードにdraw()があるのが「普通」だと言いたいのか？
普通というからには有名どころの3Dゲームエンジンの少なくとも過半が
そういう設計になってることを実際に確認したんだろうな？

脳内妄想で普通とか言ってるとか言うなよ？

**名前は開発中のものです。** · 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
画像を先読みしておいて使いまわしたい時には、
シングルトンで先読みして、
必要な時にクラス作って呼び出すってやってるんだけど、
これってもしかして、間違えてる？