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

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

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

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

**名前は開発中のものです。** · 2008/03/17(月) 21:06:48

あんまりデザインパターンでゲーム設計しちゃうとデザインパターンにはめようとするからゲームではあまり使わないな。

ストラテジー・コマンド・ステートパターンはよく使うが。

デザインパターンって言ってもgofやgof以外やマルチスレッドなやつとかwebアプリケーション用とかいろいろあるよ。

**名前は開発中のものです。** · 2008/03/17(月) 21:46:13

>>838
あと、これも多少使うかなぁ。

・シングルトン　ファイル I/O を一括管理するときとか
・オブザーバー　関連するゲームオブジェクト同士の管理（プレイヤーと、それに張り付くエフェクトとか）

実際のコードは、GoF のサンプルとはだいぶ違う形になってるけど、
まぁデザパタは設計のカタログなんで、実装の見た目が乖離する
ことはよくある。

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

オブザーバーっていうよりフックパターンがオブザーバーになってる事ない？

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

>>838-839
勉強になるよｔｈｘ
まだGOF読んでないから今の段階ではさっぱりわからんけど
読むときに思い出すようにするよ

**名前は開発中のものです。** · 2008/03/22(土) 13:55:51

GOF本高けぇえええ！！

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

GoFを中心に解説してる本ならいくつかある。javaが多いけど。

**名前は開発中のものです。** · 2008/03/22(土) 21:20:08

Grove On Fight？

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

glove on fight

でしょ

**名前は開発中のものです。** · 2008/03/22(土) 22:34:31

>>844
o がいっこ足らんぞ
Groove on Fightは名作

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

しかしPS版豪血寺は戦闘中に長いロードが入るという糞仕様

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

Gang of Fourも知らんのかここの連中は

**名前は開発中のものです。** · 2008/03/23(日) 12:20:13

ググって出てきたものを、知ったかぶりで書いたんだろうなぁ…

**名前は開発中のものです。** · 2008/03/23(日) 12:56:06

>848も言ってることは大して変わらんだろｗ

**名前は開発中のものです。** · 2008/03/23(日) 18:28:12

Glove on Fight・・・同人ゲー
Groove on Fight･･･豪血寺3のサブタイトル
Grove On Fight･･･俺のミスタイプ

**名前は開発中のものです。** · 2008/03/23(日) 20:57:34

デザインパターンも知らんで設計語ってんのか

**名前は開発中のものです。** · 2008/03/23(日) 21:19:48

めったに使えないGoFのやつか

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

継承イラネ
と思う俺はたぶんまだまだ

**名前は開発中のものです。** · 2008/03/23(日) 22:08:36

そりゃあゲームでGoFなんて使わんだろ。上に出た通りだ。

**名前は開発中のものです。** · 2008/03/23(日) 22:14:12

>>854
基本クラス変数に派生クラス実体が入ってる時に関数を呼ぶと、
もし派生クラスがその関数をoverrideしてたら派生クラスの関数が呼ばれるんだぜ。
便利だと思わん?

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

仮想関数ならな。

**名前は開発中のものです。** · 2008/03/23(日) 22:28:35

>>855
上に出たとおりだと、

いくつかのパターンは使ってる
ただし実装は書籍と違うけど

だと思うんだが。読み間違い？

**名前は開発中のものです。** · 2008/03/23(日) 22:51:49

>>857
自分の中で、仮想でないメンバの上書きはシャドウで、オーバーライド＝仮想メンバの上書きだと思ってた

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

>>856
そういうことができるのは知識としては持っているんだけど

例えば
モンスタークラスの派生でスライムクラス、ドラゴンクラスがあって…
とやらないで

モンスタークラスだけがあって
モンスタータイプっていうenumメンバ変数があってそれによって処理が変わる…
みたいに書いちゃうのね

まだまだスクリプト言語のときの癖が抜け切らないというか
たぶん継承をうまいこと使った方が生産性上がるんだろうけど

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

例えに突っ込むのは無粋だとは思うが、
外部ファイル読み込み（ハードコーティングでもいいけどさ）を考えると面倒じゃない？

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

>>861
ごめん。今の自分のレベルでは
継承だと外部ファイル読み込みが楽になる理由がよくわからない。

**名前は開発中のものです。** · 2008/03/23(日) 23:42:50

スクリプト言語を使ってたときの癖とか
ノウハウとか捨てずに大事にするよろし

C++だのJavaだのC#だの使っても
最終的にはスクリプトなりテーブルなりで
キャラデータを管理することになるから
そんときに経験は生きるぜ

継承大好きっ子にありがちなハマリ道は
何でもかんでもソースに（ハードコーディングで）
記述してみたりクラス分けしてみたりして
結果として異様に複雑で深い継承木を
こさえて、仕様変更時の手間の多さに
戦慄して初心に返ること

**名前は開発中のものです。** · 2008/03/23(日) 23:58:07

継承って、外部ファイル読み込みを外部データベース読み込みに変えるとき楽になるとか
そういう使い方をするものだと思っていた。
今は>>860のスライムクラスみたいな継承の使い方をするの？
データに当たるような部分をコードに絡ませるのはなんか抵抗があるんだが。

**861** · 2008/03/24(月) 00:07:17

>863
言語仕様には開発者の哲学が詰まってるからなあ。

>864
俺の分かりづらい文章（>861）の翻訳㌧クス

**862** · 2008/03/24(月) 00:11:51

>>864
なる。
ちょっとわかったような気がする。

**862** · 2008/03/24(月) 00:21:04

いや、ごめん。
やっぱわかんね。

>>856風の継承が>>860みたいな感じかと思っていたんだけど（違ってたらスマン）
そういう継承の仕方は主流じゃなくて
>>864風の継承（どういうクラス構成なのかはイメージがわかないけど）のが主流なのかな？

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

>>863
実装継承を適当に使うと、そうなりがち。

インターフェース継承は、設計しっかりしてれば問題ないでしょ。

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

>>864
いや、リア厨のときに俺はそれ（>>863）やって
ゲロ吐いたの

でも継承木ビューワの眺めは壮観だったよ
オナニープログラミング

**861** · 2008/03/24(月) 00:35:53

>867
あくまで、RPGっぽい敵のデータを例として挙げたから、それに対してのツッコミってことね。
他のところで使う分には知らん。

で、だ。
RPGを作ったことがないアマチュアの意見なんで、聞き流すだけでいいんだが。

敵データを外部ファイル読み込みで作るとする。
敵の動きを変更したり、敵の種類を増やしたいと思った時は、当然そのデータを弄ることで対応するわけだ。

敵のデータを変えるたびに、ソースコードの中のクラスを書き換えるのか？
敵の種類を増やしたら、派生クラスを動的に生成するのか？
そういうこと。

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

>>869の継承図が見てみたい。自分も最初のころやって破綻したｗ
まあ多くても3回以上は継承したくはないよな

キャラ＞モンスター＞種族特性＞個々のモンスター　は既になんとやら

>>870
外部ファイルを作らず未だにステータスの固有値を派生クラスに直接書き込んでる俺はどうすｒｂ・・・

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

>>870
RPGだと、

struct IEnemy;
class EnemyBase : public IEnemy {};
class EnemyBase : public EnemyBase {}; // 敵ザコクラス
class EnemyBoss1 : public EnemyBase {}; // 敵ボス1
class EnemyBoss2 : public EnemyBase {}; // 敵ボス2

って感じにするな。

ザコは全部一つのクラスで、データファイルとスクリプトで駆動。ボスは
プログラムでの特殊処理が必要なら、個別で作る。

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

>872
その辺は柔軟に、ってことね

**862** · 2008/03/24(月) 01:09:59

>>870
えーと…
ごめん。なんか混乱してきた。
自分が何か読み違えているのかもしれないけど

>>864が>>861の翻訳であるとあったので
>>864に書いてあることを
「モンスターの派生でスライムみたいな（哺乳類の派生で犬みたいな）
　クラスの構成は間違っている。
　外部データを読み込む際に便利なるような継承の仕方が実はあるよん。」
―と解釈したんだけど誤解している？

で、>>870を読むと「継承なんて使わずにデータを弄ることで挙動を変えるんだ」
と解釈したんだけど、それだと>>864の主張と矛盾するのでアレ？？と思った。

どっちを勘違いしているんだろう俺は。

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

矛盾してるように思えないんだが

**名前は開発中のものです。** · 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じゃないのか？
となると単純に継承しても元の型でアクセスされると拡張されたメソッドが呼ばれないのか。
じゃああれだ、自前クラスにするだな。