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

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

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

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

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

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

**名前は開発中のものです。** · 2009/10/15(木) 07:50:05

アクセッサ書くのめんどいだろ

**名前は開発中のものです。** · 2009/10/15(木) 08:41:22

なんでそんな両極端なの？

**名前は開発中のものです。** · 2009/10/15(木) 15:54:18

0と1しか無いからな
オタクの頭ん中は

**名前は開発中のものです。** · 2009/10/15(木) 20:13:55

別に両極端で構いません．
意見を頂けるだけで嬉しいです．

むしろ噛み付くほうが迷惑です．

**名前は開発中のものです。** · 2009/10/15(木) 22:16:10

使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。

**名前は開発中のものです。** · 2009/10/15(木) 22:18:05

>>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。

**名前は開発中のものです。** · 2009/10/15(木) 23:29:40

俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。

**536** · 2009/10/16(金) 00:35:50

>>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…

**名前は開発中のものです。** · 2009/10/16(金) 01:18:33

２ｃｈで素直に謝られると逆に困ります．
参考になりました，ありがとうございます．

**名前は開発中のものです。** · 2009/10/16(金) 01:38:32

グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。

// gamedata.h
void update();
int get_parameter1();

// gamedata.cpp
static int s_paramter1 = 0;
static int s_paramter2 = 0;
....
void update() { /* 更新 */ }
int get_parameter1() { return s_paramter1; }

唯一しか存在しないゲーム中のデータをどう実装・管理するか、って視点だけで考えれば
スタティックグローバルであろうと、クラスであろうと大差ないと思うけど、
ある時点でのスナップショットを扱う必要がある、みたいな場合、

// gamedata.h
void update(Data* gamedata);
int get_parameter(Data* gamedata);

て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。

**名前は開発中のものです。** · 2009/10/16(金) 06:29:56

代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。

**名前は開発中のものです。** · 2009/10/16(金) 11:40:43

入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。

**名前は開発中のものです。** · 2009/10/16(金) 20:07:25

アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。

**名前は開発中のものです。** · 2009/10/18(日) 12:51:59

>546
確かに使い方を間違えるってのはよく起こる

**名前は開発中のものです。** · 2009/10/25(日) 23:29:18

Compositeをゲームのシーン管理に使うのってどうやるんですか？
次に来るシーンを各クラスに設定しておいたりとか・・？

**名前は開発中のものです。** · 2009/10/25(日) 23:57:46

何を聞いてるかがちょいと分からないけど
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。

**名前は開発中のものです。** · 2009/10/26(月) 00:08:52

というか前スレの260あたりか。Compositeかどうかも微妙だな。ｽﾏｿ

**名前は開発中のものです。** · 2009/11/16(月) 14:29:49

>>501
その後どうなった？
俺も今描画周りを考えてる

**名前は開発中のものです。** · 2009/12/13(日) 15:40:07

よく読んでないけどEmptyProject風に

void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}

void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}

って風にやったら問題あるの？

**名前は開発中のものです。** · 2009/12/14(月) 01:36:46

deviceの作成は一箇所のクラスでシングルトン
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ

無知なんだけど、デバイスて何個も必要になることあんの？

**名前は開発中のものです。** · 2009/12/14(月) 01:57:52

デバイスが複数あったら複数必要なんじゃね。

**名前は開発中のものです。** · 2009/12/14(月) 03:13:37

その複数てのがさ、動的に管理しないといけないものなら複数個保持するクラスにすればいいし
そうでないなら同じようなクラスを用意するかな

便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる

まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな

**名前は開発中のものです。** · 2009/12/14(月) 11:05:57

ボンバーマンを拡張して繋がれてるコントローラの数だけ
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。

**名前は開発中のものです。** · 2009/12/14(月) 14:08:44

プレイヤが一人でも全てのコントローラで操作できるようにしているが
（左右同時に押された場合は後からの入力を優先）
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな

**名前は開発中のものです。** · 2009/12/14(月) 15:35:13

壊れたコントローラーはサポートしなくてもいいと思うよｗ

**名前は開発中のものです。** · 2009/12/21(月) 22:25:25

sharedptrみたいなの実装したいのですが、
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか？

boostソース読めってのは無しでお願いします。

**名前は開発中のものです。** · 2009/12/21(月) 23:10:45

>>560
「スマートポインタ」でググれば解説もサンプルも見つかるよ。

**名前は開発中のものです。** · 2009/12/22(火) 01:26:27

>>560
なんで boost::shared_ptr 使わないの？

**501** · 2009/12/30(水) 05:37:23

>>552
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。

簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。

コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列（描画スクリプトみたいの）を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。

デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。

**501** · 2009/12/30(水) 22:40:42

>>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。

つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。

たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。

**名前は開発中のものです。** · 2009/12/31(木) 08:32:52

sqliteを組み込んで、画像やモデルを相互変換可能な名前/IDで管理するとか夢が広がるわな
内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし

**名前は開発中のものです。** · 2009/12/31(木) 15:10:35

>>565
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。

**名前は開発中のものです。** · 2010/01/04(月) 06:09:33

おおー、ゲームのバックエンドサーバーにもGAE使う時代かｗ

たしか、mixiアプリのモバイルゲームでGAE使った事例があったな。
3000万PV/月をかなり安価で乗りきれるとか

Togetter(トゥギャッター) - まとめ「100万PV／日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー」
http://togetter.com/li/494

すれ違いの話題になるが、昨今のネットが絡むゲームの場合バックエンドの技術も必要だけど、
そういう話題を扱ったスレってないものかな
この板にネットゲームの開発時代が少ないみたいだから、需要はないのかもだけど

まーGAEならWebProg板のAppengineスレ行けばいいしな

**名前は開発中のものです。** · 2010/01/04(月) 06:10:39

x 開発時代
o 開発自体

**名前は開発中のものです。** · 2010/04/20(火) 00:42:02

前スレの最後のほうに出てた描画の話題って結局どうなりました？（928ぐらい）

**名前は開発中のものです。** · 2010/05/11(火) 16:43:34

http://blog-imgs-27.fc2.com/c/h/u/chudoku200/1239712143736s.jpg

**名前は開発中のものです。** · 2010/09/20(月) 21:23:17

アクションゲーム作ってるんですが
どういう風にクラス分けすればいいか悩んでます

MAPクラス
Playerクラス
GameFrameクラスの3つがあって
mainループで

switch(MODE)
{
case TITLE:~~~~;break;
case MENU:~~~~;break;
case STAGE01:~~~~;break;
case STAGE02:~~~~;break;
.
.
.
}

みたいなことをしています。
各Stageに行くたびに、ステージ前処理と、ステージ後処理をしたいです
というとコンストラクタとデストラクタ……つまりはクラスを使えばいいんじゃないか？
という感じなのですが

Playerクラスの持っている情報と、操作関連を上手く融合させたり
Mapクラスの持っている情報と、Playerクラスを上手く組み合わせたりが出来ません……

こういう部分はどういう風にデザインするのがいいのでしょうか

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

STAGE01とSTAGE02を分ける必要は無いだろ。
ファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。

**名前は開発中のものです。** · 2010/09/23(木) 17:38:03

まずそのswitch文をなんとかしよう。
TitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ？

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

>>571
貴方は俺か
クラス名と悩みが殆ど同じとかｗ

**名前は開発中のものです。** · 2010/12/04(土) 14:39:29

>>571
ちょっと難しいかもしれないが
ttp://marupeke296.com/GDEV_main.html
ここはかなり参考になる気がするよ。サンプルもあるし。
その6とその7ね。

**名前は開発中のものです。** · 2011/02/02(水) 03:54:28

保守

**名前は開発中のものです。** · 2011/05/20(金) 08:10:28.28

良スレ保守

**名前は開発中のものです。** · 2011/08/02(火) 05:21:50.11

Android開発でのパフォーマンスTips
http://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293

オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける

携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな

**名前は開発中のものです。** · 2011/08/02(火) 12:43:43.47

iアプリを思い出すなーｗ

**名前は開発中のものです。** · 2011/08/04(木) 13:31:14.84

PS時代のゲーム開発みたいだなｗ
あの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてｗ

**名前は開発中のものです。** · 2011/08/09(火) 01:57:38.36

処理能力を操作に割かせるためにメモリに読めるだけ読むのかな

**名前は開発中のものです。** · 2011/08/09(火) 20:19:58.06

それやりすぎるとアプリの切り替えをすることが多いスマフォじゃ
面倒が起きやすいんじゃないか

**名前は開発中のものです。** · 2011/08/15(月) 07:32:13.82

>>19
消えてるみたい
どこか掲載されるサイトしらない？

**名前は開発中のものです。** · 2011/08/21(日) 15:33:02.73

こないだ色々探したんだけど、糞アフィブログのリンク記事しか見つからなかった
キャッシュとかも見たんだけどさ

**名前は開発中のものです。** · 2011/09/04(日) 02:30:22.85

>>580
そうかもしれない。
その世代が今のゲーム現場で老害化してるんでむしろ行って欲しい。