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

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

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

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

**名前は開発中のものです。** · 2008/03/07(金) 18:25:22

俺だったら、自機の基底クラスである（例えば）機体クラスで管理する。

理由は、機体クラスの派生クラスで敵機クラスを作れば、
敵機の溜めショットの実装が楽になる。

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

おおむね>821に同意しつつ、自分なら、キーの押しっぱなし時間も同時に保持しておくかな。
溜めショット以外にも使うこと多そうだし。

カーソルとか、ポンと押した場合は１つ進むだけだけど、押しっぱなしにすると自動的にカーソルが動くとか、
そんな類の処理に流用できそう。

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

>>820
void 機体クラス::update()
{
　if (joypad1.getOnf() & BTN2) // getOnf() はボタン押し下げてれば真
　　m_shot2.Charge();
}

俺なら、こうするかなぁ。機体クラスのメンバ変数に溜めショット用の
メンバ変数を持たせる。

キー管理クラスというのが何を意図してるのかわからんけど、汎用の
パッド入力処理関数として

enum { BTN1 = 0x1, BTN2 = 0x2, BTN3 = 0x4, BTN4 = 0x8, ... };

getOnf(); // 押し下げボタンの論理和が返る
getTrg(); // 直前まで放されてて、このフレームに初めて押し下げられたボタンの論理和
getRep(); // 一定時間以上押しっぱなしのボタンの論理和

ぐらいは用意しておいた方が便利だよ。

**820** · 2008/03/07(金) 23:07:06

>>821-822
有難うございます。その方向でちょっと作ってみます。

**820** · 2008/03/07(金) 23:26:54

>>823実は自作で汎用のパッド入力処理関数のようなものを作ってあったんですが
ちょっと出来に難があります。
1回のメインループで2回使用、例えばKEY_DOWNとKEY_UPの2種類を検出しようと
したりすると1種類目の呼び出ししか有効でなかったり。
enum BTN_STATE{ NO_PUSH, KEY_DOWN, KEY_PUSH, KEY_UP };
//「押されていない」「押下げた瞬間」「押されている状態」「押上げた瞬間」
class JoyPad{
　int isPushDown[2][8];//[パッド1P、2P][ボタン数] （各ボタン押されているか否か）
public:
　BTN_STATE getBtnState(int pad_num, int btn_num );
}

BTN_STATE JoyPad::getBtnState (int pad_num, int btn_num ){
　　int btn = ボタンが押されているか？関数( pad_num, btn_num ）;
　　if ( btn == 1 ) {//ボタンが押されていたら
　　　　if ( isPushDown[pad_num][btn_num] == 0){
　　　　isPushDown[pad_num][btn_num] = 1;
　　　　return KEY_DOWN;//「押下げた瞬間」
　　　　}else{
　　　　return KEY_PUSH;//「押されている状態」
　　　　}
　　}
　　if ( btn == 0 ) {//ボタンが押されてなければ
　　　　if(isPushDown[pad_num][btn_num] != 0){
　　　　isPushDown[pad_num][btn_num] = 0;
　　　　return KEY_UP;//「押上げた瞬間」
　　　　}
　　}
return NO_PUSH; //「押されていない
}

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

状態を管理する部分と、管理されてる情報を参照する部分を分ければいいんじゃね？

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

Win系ならWindowメッセージかDirectX使え。

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

>>825
>>826も言ってるが
それぞれの状態について保存しておいて、それを参照すればいいじゃん

現在の状態をcurrentに0,1で保存するとして
押下した瞬間 on_trigger = (on_trigger ^ current) & ~current
離した瞬間 off_trigger = off_trigger ^ (^current & last)
過去の状態 last = current

**820** · 2008/03/07(金) 23:56:56

>>826
ちょっと考えて見ます
>>827
使っているのが「DXライブラリ」というDirectX用ライブラリなんですが押している状態しか
チェックできなくて難儀しています。
直接DirectXガリガリした経験がないのでわかりませんがWindowメッセージの
WM_KEYDOWN, WM_KEYUPに相当するものがあればその方が楽できそうですね…

**名前は開発中のものです。** · 2008/03/08(土) 00:15:59

DXライブラリってのは名前くらいしか知らんが、
１フレーム内にon/offがあった場合検知できないのかねぇ？
（FPSを上げれば解決できそうな問題だと思うけど）

DirectXは（デバッガで止めるなどして）１フレーム内に複数の入力あっても、
全部取得できると思った。でもDirectXはその性質上最低レベルAPIだから、
DXで済ませるならDXでやったほうがいいんじゃないかな…

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

stateパターンか

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

DXライブラリの中の人もチラと言ってたけど、そのまま使わずに、自分でラップして使った方がいいんじゃないかな？
低レベルな部分を隠すだけ、って割り切っちゃう。

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

>>828
横レスすまん。
たぶん俺が根本的に何かを勘違いしているんだろうけど、
どう考えても意図がわからない。

押下した瞬間 on_trigger = current & ~last
離した瞬間 off_trigger = ~current & last
ほんとはこう？

「C,C++じゃねーよ」ってのならごめん。他の言語はわからない。

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

素直にifを使うっていうのはどうだろうか。

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

そういうことだな

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

最近デザインパターンを覚え始めたんだが、
oopのコンポジション集約と、デザインパターンのコンポジットは全然別なことと、
デザインパターンのファザードがコンポジション集約と似た効果/構造してて戸惑った。

この違和感は普通にそのうち無くなるもの?

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

デザインパターンか…
そろそろ俺も覚えないと不味いな

**名前は開発中のものです。** · 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
ステートマシンって一般的な単語なのかな
波動やってないとたぶん分からないきもするが

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