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

**名前は開発中のものです。** · 2008/05/23(金) 21:10:59

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

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

前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

テンプレ追加事項あったらよろすく

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

FFとかのムービーシーンの管理はどうやればよかですたい？

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

プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。

いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と

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

あれ？　ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス？

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

>>308
ムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。

**名前は開発中のものです。** · 2008/08/04(月) 17:38:42

うさんくさか博多弁多かたいね。なんかぐらぐらこく

馬鹿にしないでください＞＜

**名前は開発中のものです。** · 2008/08/04(月) 23:28:56

>>312
こらあげにまっことすまんかったぜよ。

**302** · 2008/08/04(月) 23:40:39

>>306
そうそうそんな感じ。

1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。

**名前は開発中のものです。** · 2008/08/07(木) 02:18:10

　　しーん…

**名前は開発中のものです。** · 2008/08/07(木) 15:44:15

【審議中】
　　∴∵

**名前は開発中のものです。** · 2008/08/24(日) 00:35:34

（審議が長引いています。今しばらくお待ちください）

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

キャラクターの状態って、どうやって実装してますか？
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか？
stateパターンでは無理？？？

**名前は開発中のものです。** · 2008/08/27(水) 21:31:52

それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う

ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。

マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。

**318** · 2008/08/28(木) 00:48:01

>>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。

**名前は開発中のものです。** · 2008/08/28(木) 01:16:45

>コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな！」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。

ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねｗ

**名前は開発中のものです。** · 2008/08/28(木) 01:34:35

最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな

**名前は開発中のものです。** · 2008/08/28(木) 03:20:26

関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。

**名前は開発中のものです。** · 2008/08/28(木) 09:12:41

そこで goto ですよ

**名前は開発中のものです。** · 2008/08/28(木) 10:11:26

某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。

**名前は開発中のものです。** · 2008/08/28(木) 11:46:09

javaは関数ポインタ使えないんだ・・・・

**名前は開発中のものです。** · 2008/08/28(木) 11:57:21

>>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。

**318** · 2008/08/28(木) 17:59:10

>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな～と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。
完成させることが第一と思っていてもついつい・・。

>>323,327
stateパターンですよね？

>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。

**名前は開発中のものです。** · 2008/08/28(木) 18:35:54

自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。

つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる？

**名前は開発中のものです。** · 2008/08/28(木) 19:03:37

むしろ可能な全ての表記法を試す勢いで！
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。

**名前は開発中のものです。** · 2008/08/28(木) 19:43:21

人が書いたソースを読むのって勉強になるけど、読む気が出ない……

>>328
>stateパターンですよね？
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。

**名前は開発中のものです。** · 2008/08/28(木) 20:37:26

＞状態という概念が無い

敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。

**名前は開発中のものです。** · 2008/08/28(木) 21:28:28

>>332
他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。

**318** · 2008/08/28(木) 21:30:31

>>329
コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。
今問題にしてるのは、主にこのうち後者２つです。
ただ、読みやすさは人それぞれなのかもしれません。

>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。

**名前は開発中のものです。** · 2008/08/28(木) 21:59:24

保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの？

**名前は開発中のものです。** · 2008/08/28(木) 22:18:17

ダライアス継承ってどんな継承？

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

>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる？

**318** · 2008/08/28(木) 23:04:17

>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。

>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。

**名前は開発中のものです。** · 2008/08/29(金) 00:44:03

ダライアス継承なんて初めて聞いたなあ

英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス（Darius？）はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな

**名前は開発中のものです。** · 2008/08/29(金) 00:50:36

ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える

**名前は開発中のものです。** · 2008/08/29(金) 02:39:33

Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん

**名前は開発中のものです。** · 2008/08/29(金) 06:43:42

http://ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50

**名前は開発中のものです。** · 2008/08/29(金) 10:26:08

>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)

**名前は開発中のものです。** · 2008/08/29(金) 14:31:33

>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw

**名前は開発中のものです。** · 2008/08/29(金) 14:34:13

>だったりしてw
いやだったりしてっつーかそれしかなくね

**名前は開発中のものです。** · 2008/08/30(土) 13:56:18

ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。

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

ドラえもん「ことわざゲーム」
これはいいアニメ。 ... ドラえもん藤子Ｆ不二雄アニメ
ドラえもん後期ドラえもん本編教育アニメコメント非
表示推奨緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar

**名前は開発中のものです。** · 2008/08/30(土) 14:23:18

なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク

**名前は開発中のものです。** · 2008/08/30(土) 14:32:04

夏休みも終わりって事さｗ

**名前は開発中のものです。** · 2008/08/30(土) 14:40:33

Bot使った宣伝書き込みかなぁ

**名前は開発中のものです。** · 2008/08/30(土) 15:36:27

なんかのマルウェアって聞いたが

**名前は開発中のものです。** · 2008/08/31(日) 15:40:22

A has B B has C C has Dのようなクラス構成で
Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に
Ｅを渡していくのはいいのかな？

**名前は開発中のものです。** · 2008/08/31(日) 15:45:26

いいんじゃね。

**名前は開発中のものです。** · 2008/08/31(日) 15:47:56

別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない

**名前は開発中のものです。** · 2008/08/31(日) 15:54:48

>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな～と
思ったんだよね

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

このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠

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

>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。　っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと）
本当はいいとも悪いとも言えないが。

**名前は開発中のものです。** · 2008/09/02(火) 17:16:20

CarクラスはTireクラスを４つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？

**名前は開発中のものです。** · 2008/09/02(火) 17:22:14

コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外

**名前は開発中のものです。** · 2008/09/02(火) 17:30:36

TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか？

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

>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。

**名前は開発中のものです。** · 2008/09/02(火) 17:40:44

タイヤが車に関心があるってどういう状況？

**名前は開発中のものです。** · 2008/09/02(火) 17:42:28

「パンクしたよ」って知らせてくれるんじゃね？

**名前は開発中のものです。** · 2008/09/02(火) 17:44:29

なるほど

**名前は開発中のものです。** · 2008/09/02(火) 19:17:31

それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？

**名前は開発中のものです。** · 2008/09/02(火) 19:20:27

車が、常に「パンクしたか？」ってタイヤに聞くの？

**名前は開発中のものです。** · 2008/09/02(火) 19:24:40

うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど

**名前は開発中のものです。** · 2008/09/02(火) 19:38:46

メディエーターみたいなの？

**名前は開発中のものです。** · 2008/09/02(火) 20:44:39

>>366
実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。

float _pressure = m_wheel[n]->GetPressureState();

**名前は開発中のものです。** · 2008/09/19(金) 19:13:57

ほしゅ

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

このスレはJavaでも大丈夫なの？

**名前は開発中のものです。** · 2008/10/05(日) 14:52:40

>>371
質問内容の分野がよくわからないなら、以下へどうぞ。

【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288

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

>372がエスパーすぎる

**名前は開発中のものです。** · 2008/11/01(土) 11:27:07

データ(アイテムとかマップとか)ってどうやって作ってます？
エクセルで打ち込んでcsvで保存？

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

別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし

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

>>375
マップに関しては、フリーのエディタがあるんですね。

規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。

**名前は開発中のものです。** · 2008/11/01(土) 16:47:28

既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。

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

海岸線自動生成とかやってくれるエディタあるっけ？

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

>378
エディタでやるの？

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

機能としてはエディタ側じゃね？

**名前は開発中のものです。** · 2008/11/06(木) 00:16:08

ツクールで海岸線をシフト＋右クリックすると分かる

**名前は開発中のものです。** · 2008/11/11(火) 20:24:09

最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。

1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。）

2、再利用を考えたフレームワークは（初心者は）作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。

他に鉄則があったらだれか教えてください　orz

**名前は開発中のものです。** · 2008/11/12(水) 01:30:10

相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ！」
ピー…

**名前は開発中のものです。** · 2008/11/12(水) 09:02:45

> Gofのデザインパターン
GOF本でわかったならよいけど、退屈でわからない人は
First Headの本オススメ

Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリックフリーマン, キャシーシエラ, エリザベスフリーマン, バートベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤直生, 木下哲也, 福龍興業: Amazon.co.jp: 本
http://www.amazon.co.jp/dp/4873112494
http://images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

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

ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。

たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite）
2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent）
3、そもそもが間違い。同一名前空間に配置する。

どれが適切でしょうか？

**名前は開発中のものです。** · 2008/11/13(木) 21:08:31

>>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。

ってそういう話じゃない？

**名前は開発中のものです。** · 2008/11/14(金) 01:18:47

>>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。

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

ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。

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

>>382-384
まだ読んでいない俺には勉強になったthx

**名前は開発中のものです。** · 2008/11/20(木) 09:17:22

>>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ

ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
（まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ）

**名前は開発中のものです。** · 2008/11/30(日) 20:02:56

すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)

1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling()　…主目的が『必要ならば読み取る』なので何かしっくりしない。

2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。

どなたか導きをお願いします

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

なんかいっぱい改行が入ってるorz

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

>>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。

ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。

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

>>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。

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

ついでにスレを読み返してメモメモ、と思った情報をまとめてみた。

コルーチン、マイクロスレッド、ファイバ
>>145,>>146,>>162,>>164

楽だが応用性のないありがちな実装
>>159,>>160

分業とデバッグ
>>194-213

ADVの画面クリックとか
>>270,>>271

メニュー画面の管理とかシーン管理とか
>>59-71,>>207,>>273-276 >>302,>>305-314・・・VMCはたぶんMCVのことだよね？

状態管理とか
>>318-325

priateとgetter、setter
>>277-301

設計Tips
>>352-357,>>358-367,>>382-384

**名前は開発中のものです。** · 2008/12/13(土) 14:29:53

ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか？

↓ゲーム開発論スレ要望の経緯
http://pc11.2ch.net/test/read.cgi/gamedev/1206381315/

ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える～ゲーム会社技術開発の現場から2～」
http://game.watch.impress.co.jp/docs/20080916/cedec_dev.htm

「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス
http://www.4gamer.net/news/history/2007.03/20070309215934detail.html

Agile型開発でのゲームデザイン
http://www.4gamer.net/news/history/2007.03/20070311002313detail.html

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

>>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ！！

**名前は開発中のものです。** · 2008/12/14(日) 06:47:43

想定通りでワロタ

**名前は開発中のものです。** · 2008/12/15(月) 01:28:13

>>395
ありがとう助かるよ

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

キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。

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

俺はそうしてる。

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

つまりスクリプトですね。

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

知ってるよDIって言うんだよね

**名前は開発中のものです。** · 2008/12/26(金) 01:45:37

最近でたセガのあれな本を読んで、自分がずっと詰まってたしょーもないことを勝手にメモ。
結論としては基本中の基本で、データと処理は独立させましょ、ってことなんだけど。

ゲーム中ができたけど、ポーズ機能を追加、ポーズメニュー表示関連をクラスで作って実装するには、という感じの想定。
こんな感じに管理してるとして(具体的にはもっと複雑だけど。)

class StgScene　{
　Mover movers[];

　void Update() {
　　//A
　　for(・・・) {
　　　movers[i].Move();
　　}
　　//他判定処理等
　　//B
　　for(・・・) {
　　　movers[i].Draw();
　　}
　　//C
　}
}

・A～Bまでの処理はポーズ時すっ飛ばす、となる。ので、関数化するなりクラス化したい。
・対象性を考え、Menuクラスに対してA～Cの処理をPlayingクラスにする。(つまりSTGSceneはデータのみ。)
・MenuクラスにもB～Cの処理を書き、追加してMenu関連の処理も記述する。

こうすると、結果的にSTGシーンはデータしか持たなくなって、処理はPlayingクラスやMenuクラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。

**名前は開発中のものです。** · 2008/12/26(金) 08:47:36

「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい

**名前は開発中のものです。** · 2008/12/28(日) 17:34:36

MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか？
Stateパターンという風にも捉えられる？

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

Stateパターンだとこんなかんじかね？

struct StgScene {
　void A();
　void B();
　void C();
};

class State {
　virtual void Update(StgScene&) = 0;
};

class Playing : public State {
　virtual void Update(StgScene& scene){
　　scene.A();
　　scene.B();
　　scene.C();
　}
};

class Menu : public State {
　virtual void Update(StgScene& scene){
　　scene.C();
　}
};