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

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

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

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

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

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

**名前は開発中のものです。** · 2008/05/23(金) 22:15:47

■デザインパターン
必須ではないが用語として便利なのでしばしば話題に上がる

[参考サイト]
Gameつくろー！　デザインパターン習得編
http://marupeke296.com/DP_main.html

サルでもわかる逆引きデザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html

[参考書籍(Amazonリンク)]
オブジェクト指向における再利用のためのデザインパターン
http://amazon.co.jp/o/ASIN/4797311126/

デザインパターンとともに学ぶオブジェクト指向のこころ
http://amazon.co.jp/o/ASIN/4894716844/

>>1乙
一応デザパタ軽く。

**名前は開発中のものです。** · 2008/05/24(土) 01:01:32

3ゲトー1乙。ずっと待ってたぜ。

**名前は開発中のものです。** · 2008/05/24(土) 01:10:28

・オブジェクト指向といったら特に指定しない限りクラスベース（所謂最も一般的なオブジェクト指向）
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。

とかスレの前提としてどうだろう。

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

インスタンスってつまりは実体のこと？
Foo foo = new Foo() とすると foo がインスタンス？

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

デザインパターンとOpen-Closed Principle
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html

これも

**名前は開発中のものです。** · 2008/05/24(土) 02:07:45

>>5
揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね？
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。

**名前は開発中のものです。** · 2008/05/24(土) 02:41:35

「ゲームとはPrettyなインターフェースを備えたデータベースである」
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな

**名前は開発中のものです。** · 2008/05/24(土) 16:24:52

スクリプト指向の意味がさっぱりわからない

**名前は開発中のものです。** · 2008/05/24(土) 17:17:01

今最高峰のプログラマって、全員ＷＥＢ系じゃん？
ＷＥＢ系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな？

**名前は開発中のものです。** · 2008/05/24(土) 17:53:41

>>8
ゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。

**名前は開発中のものです。** · 2008/05/24(土) 21:56:16

メリットやデメリットを言えないくせに
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな

それで、教祖様は誰がなる予定なの?

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

>>12
今出てるのってそんな話か？
俺には世間話に>>10が適当な横槍入れただけに見えるが

**名前は開発中のものです。** · 2008/05/24(土) 23:16:51

プ板から厨房誘致すればこのｽﾚは盛り上がる。間違い無いｗ

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

たてなきゃいいのに布教スレなんかたてるからこうなる

**名前は開発中のものです。** · 2008/05/25(日) 00:49:54

もう厨房が数匹住み着いたのか

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

プ板？
ム板のことか？

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

マ板じゃね？

**名前は開発中のものです。** · 2008/05/27(火) 12:06:43

これも貼っておこう

やる夫で学ぶデザインパターン
ttp://mojalog.com/cgi/mt/mt-search.cgi?tag=%E3%82%84%E3%82%8B%E5%A4%AB%E3%81%A7%E5%AD%A6%E3%81%B6%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3&blog_id=1

**名前は開発中のものです。** · 2008/05/28(水) 00:17:53

途中からゲーム関係なくね？

**名前は開発中のものです。** · 2008/05/28(水) 09:16:17

俺には全部ゲームに関係した話に見えるけど？
サンプルコードもゲームだしわかりやすくていいと思うが

**名前は開発中のものです。** · 2008/05/28(水) 10:19:46

なんか、無理矢理ゲームに例えてる感がひしひしと。

**名前は開発中のものです。** · 2008/05/28(水) 12:07:15

日本語も満足に読めないのか

**名前は開発中のものです。** · 2008/05/28(水) 12:58:54

お、2スレ目立ってたのね。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。

**名前は開発中のものです。** · 2008/05/28(水) 19:17:39

>>22
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ！」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い

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

俺のレベルではよくわからんが
ゲーム屋からみれば変な設計なん？

**名前は開発中のものです。** · 2008/06/01(日) 20:35:37

デザインパターンを丸々入れ込むとゲームだと描画とかで
速度でないゴミになりそうな悪寒

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

関数呼び出しとか仮想関数分のオーバーヘッドってそんなに響くか？
まぁ使い過ぎが良くないってのには同意だけど

**名前は開発中のものです。** · 2008/06/02(月) 00:45:33

クラスというか、同じ関数名が増えまくるオブジェクト思考言語は、GTAGS使えないので嫌いです。継承構造とかも嫌い。
こんなんじゃ、ゲーム屋って無理？

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

>>29
マならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…

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

>>29
利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど

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

cscopeならglobalと同じような事をC++やjavaのコードに対してもできるぜ

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

CodeWarriorとか、OOPでもばんばんタグジャンプできるから問題ないのでは？
どうしてもGTAGSがいいの？GTAGSってGNU Tags？Google Tags？

**名前は開発中のものです。** · 2008/06/04(水) 03:53:09

>>33
>GTAGSってGNU Tags？Google Tags？
ｶｴﾚw

**名前は開発中のものです。** · 2008/06/07(土) 05:38:48

>>27
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。

デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。

皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。

**名前は開発中のものです。** · 2008/06/08(日) 20:08:17

シューティング作っているんだけど
参考になるサイトでもある？

**名前は開発中のものです。** · 2008/06/08(日) 20:17:15

積み木ファイターのひととか

**名前は開発中のものです。** · 2008/06/10(火) 10:07:55

ゲーム作るときってどうやってプログラム組んでいく？

全体構造を決めてから、トップダウンアプローチで作る
その場その場で決めていき作っていくスパイラルモデル

**名前は開発中のものです。** · 2008/06/10(火) 10:18:30

>>38
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。

これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ？

**名前は開発中のものです。** · 2008/06/10(火) 11:31:11

>>38
まず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。

**名前は開発中のものです。** · 2008/06/10(火) 12:26:21

趣味で1人で作るのか、同人誌即売会狙いで数人で作るのか、会社の業務として作るのかで変わるとは思うけどな。
まあ、最後はありえねーとしてもｗ

**名前は開発中のものです。** · 2008/06/10(火) 19:02:52

>>38
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視

エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz

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

>>42
でも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。

**名前は開発中のものです。** · 2008/06/14(土) 10:10:24

まずはトップダウンでモデル作って、作りながら問題があれば
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。

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

それができないから、他に方法が無いかと模索してるんでしょうね。お察しください。

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

あのgoogleですらボトムアップだという

**名前は開発中のものです。** · 2008/06/14(土) 21:53:33

それはプロジェクト的な意味でだろ。

**名前は開発中のものです。** · 2008/06/23(月) 00:38:10

デバイスへのポインタってグローバルにしたほうが明らかに管理しやすいよな

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

>>48 は？なんで？

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

俺はどっかにまとめるなあ
グローバルとか、デバイス差の吸収とか必要になったとき困らね

**名前は開発中のものです。** · 2008/06/23(月) 02:05:44

Direct3Dのデバイスの話とまず仮定。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との２択から、管理しやすさについて語っているのだと推測。

で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。

引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。

**名前は開発中のものです。** · 2008/06/23(月) 02:31:28

ヘッダーが重たくなるから一部のソースでデバイス関連のインクルードして、
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。

**名前は開発中のものです。** · 2008/06/23(月) 08:22:39

オレはシングルトンクラスに持たせてそこからgetter呼ぶかなあ

**名前は開発中のものです。** · 2008/06/23(月) 14:04:29

レイヤスーパータイプじゃないの
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど

**名前は開発中のものです。** · 2008/06/23(月) 22:16:08

デバイスを使うような処理は関数で囲っちゃって、
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな？

**名前は開発中のものです。** · 2008/06/23(月) 22:34:15

>>55
俺もー

56 · 2008/06/23(月) 22:37:13

↑でも、ビューアとかデバッグ系のプログラムは別だけどね。

**名前は開発中のものです。** · 2008/07/02(水) 02:46:33

お前らシーンの遷移ってどういう風に管理してる？
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。

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

シーンクラスじゃなくて管理クラスの方を積むの？
俺の鳥頭じゃちょっとイメージしにくい・・・

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

シーンなぞ市販のゲームだって両手の指で足りるくらいしかないのに
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの？

**名前は開発中のものです。** · 2008/07/02(水) 10:15:59

シーンねぇ
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。

**名前は開発中のものです。** · 2008/07/02(水) 19:16:17

それで問題感じなきゃ無問題
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね

**名前は開発中のものです。** · 2008/07/02(水) 22:59:17

シーンの切替で驚いた事といえば、
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。