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

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

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

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

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

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

**名前は開発中のものです。** · 2009/01/29(木) 21:46:47

そうだけど、それとクラスの名前が～管理、～データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい

**名前は開発中のものです。** · 2009/01/30(金) 16:55:21

>>434は別に口答えしてるわけじゃない気がするｗ

**名前は開発中のものです。** · 2009/01/31(土) 08:12:45

アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな？
とたまに悩む

**名前は開発中のものです。** · 2009/01/31(土) 12:07:33

Ｇｅｍｓにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい

**名前は開発中のものです。** · 2009/01/31(土) 19:06:11

そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた

**名前は開発中のものです。** · 2009/01/31(土) 19:11:05

>>437
悩む悩むｗ

**名前は開発中のものです。** · 2009/02/01(日) 19:03:38

>>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。

int near = CEnemy::returnNearNum();
enemy[near].attack();

↑こんな感じで静的なメンバ変数を返して貰っていたけど

STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。

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

ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります

**名前は開発中のものです。** · 2009/02/03(火) 03:59:27

キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか

**名前は開発中のものです。** · 2009/02/06(金) 21:51:27

たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。

**名前は開発中のものです。** · 2009/02/06(金) 21:56:52

>>444
物の理を司る GOD class

**名前は開発中のものです。** · 2009/02/06(金) 21:57:18

分からないから指向をそのままレスとして出力。

・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。

ごめん、適当に書いただけ。

**名前は開発中のものです。** · 2009/02/06(金) 21:58:24

唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん

**名前は開発中のものです。** · 2009/02/07(土) 00:34:27

> ・石に重力を働かせる処理
石クラス

> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理

> ・石とマップの衝突処理
石クラス

**名前は開発中のものです。** · 2009/02/07(土) 01:46:53

> ・石に重力を働かせる処理
石クラス

> ・石と石の衝突処理
衝突判定クラス

> ・石とマップの衝突処理
衝突判定クラス

**名前は開発中のものです。** · 2009/02/07(土) 13:25:16

> ・石に重力を働かせる処理
ゲーム管理クラス

> ・石と石の衝突処理
ゲーム管理クラス

> ・石とマップの衝突処理
ゲーム管理クラス

**名前は開発中のものです。** · 2009/02/07(土) 14:22:20

> ・石に重力を働かせる処理
石に重力クラス

> ・石と石の衝突処理
石と石の衝突処理クラス

> ・石とマップの衝突処理
右とマップの衝突処理クラス

**名前は開発中のものです。** · 2009/02/07(土) 14:51:09

>>451
オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり？

**名前は開発中のものです。** · 2009/02/07(土) 16:19:23

>>450
CGameManagerですね、わかります

**447** · 2009/02/07(土) 16:35:33

みんな何のことだかわかっていて俺涙目

**名前は開発中のものです。** · 2009/02/13(金) 17:17:04

テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。

これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。

**名前は開発中のものです。** · 2009/02/13(金) 17:35:30

455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。

**名前は開発中のものです。** · 2009/02/14(土) 00:06:30

沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな

**名前は開発中のものです。** · 2009/02/14(土) 00:20:27

>>457
じゃあ新たなネタ出せよ

**名前は開発中のものです。** · 2009/02/14(土) 01:01:03

ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、１つだけ。

ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。

リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。

自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード＆短かい時間で)デバッグできるか教えてほしい。

そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。

**名前は開発中のものです。** · 2009/02/14(土) 03:08:07

人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はＯＦＦで。

コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利／敗北または成功／失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール（数十倍～数十分の一まで）。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。

スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。

**名前は開発中のものです。** · 2009/02/14(土) 10:08:02

リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。

**名前は開発中のものです。** · 2009/02/15(日) 16:27:42

速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。

**名前は開発中のものです。** · 2009/02/18(水) 14:05:52

>>460-462
いろいろありがとう。
あらかたデバッグ用に実装してみました。

**名前は開発中のものです。** · 2009/02/18(水) 14:39:48

行動力あるね
素晴らしい。見習いたい

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

いやいや。実装したのはこんだけです。
コリジョン可視化:テクスチャ読み込み後に四隅に沿って緑色で四角線を書くだけ
パラメータ操作:テンキーで実装
　4と6で対象パラメータを選択 (あらかじめ操作対象を手動でlistしておく)
　789でパラメータ上昇(7で+1,8で+10,9で+100)
　123でパラメータ下降(1で-1,2で-10,3で+100)
　0で強制0(bool値ならfalse)
便利ボタン:戦闘強制勝利機能とエンカウント無効をFXXキーに割り当て
速度コントロール:VSync非同期にして、FPSを上げることで対応
　2倍にすると早すぎたので、1.5倍(90fps)をボタンに割り当て
リプレイ機能:フレームごとの入力(キーボード/ジョイパッドを合わせた入力値)をファイルに出力
　(一見単純そうだけど、セーブ/ロードの関係でこれには実装に手間取った)

作っているのがRPGなので、便利ボタンとパラメータ操作がとても役に立っています。
ありがとうございました。

**名前は開発中のものです。** · 2009/02/21(土) 07:24:48

洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。

**名前は開発中のものです。** · 2009/02/21(土) 12:50:08

http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/

**名前は開発中のものです。** · 2009/02/24(火) 16:03:05

スマートポインタの使いどころ教えて

**名前は開発中のものです。** · 2009/02/25(水) 02:46:38

使いどころっつーわけじゃないけど
次のC++規格が決まれば、早ければ今年中にも
　std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど

**名前は開発中のものです。** · 2009/02/25(水) 05:08:14

>>468
まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。

**名前は開発中のものです。** · 2009/02/25(水) 11:43:26

要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか

**名前は開発中のものです。** · 2009/02/25(水) 18:18:12

Yes
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ

**名前は開発中のものです。** · 2009/02/25(水) 18:28:42

つまり、いらなくなったらすぐに消されるってことですね

私のように

**名前は開発中のものです。** · 2009/02/25(水) 18:31:43

不況だもんな・・・

**名前は開発中のものです。** · 2009/02/25(水) 18:55:09

いや、それは地球の資源不足で君の給料が確保できないだけだ
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・

**名前は開発中のものです。** · 2009/02/27(金) 15:15:39

例えばDirectxのDeviceインスタンスなど、あらゆる所で使われそうなインスタンスは、どう使ってますでしょうか？
Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは

1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他

現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?

**名前は開発中のものです。** · 2009/02/27(金) 15:58:46

デバイスホルダー的なシングルトン作るとか

**名前は開発中のものです。** · 2009/02/27(金) 17:33:53

俺もシングルトンかな。参照回数が0になったらreleaseで。

**名前は開発中のものです。** · 2009/02/28(土) 00:40:47

ハッシュテーブルのキーって文字列じゃなくてもいいのかな？
符号なし整数とか。
どっかにそういう例ないです？

**名前は開発中のものです。** · 2009/02/28(土) 08:42:03

ハッシュが計算できるなら、キーはなんでもいいよ

**名前は開発中のものです。** · 2009/03/04(水) 04:45:32

>>479
こんなんでいいか？
ttp://codezine.jp/article/detail/2171?p=2

**名前は開発中のものです。** · 2009/03/06(金) 11:34:39

C++でシングルトンするのってなんか滑稽じゃね？
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う

**名前は開発中のものです。** · 2009/03/06(金) 13:08:45

>>482
グローバル変数が欲しいんではなくて、システム全体で一つしかないということを
明示的にする為のパターンだから

**名前は開発中のものです。** · 2009/03/06(金) 14:26:30

グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう

**名前は開発中のものです。** · 2009/03/06(金) 14:28:31

あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。

**名前は開発中のものです。** · 2009/03/06(金) 15:48:06

>>484-485
エンドユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ

話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー

**名前は開発中のものです。** · 2009/03/06(金) 16:07:52

>>486
そのクラスのインスタンスが１つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ

C++でのシングルトンはマッチポンプなんだよ

**名前は開発中のものです。** · 2009/03/06(金) 16:18:21

http://www.geocities.jp/ky_webid/design_pattern/009.html

「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね？

// 生成やコピーを禁止する
↑アホじゃね？　最初からクラスにしなきゃいいじゃん

クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい

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

まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな

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

先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件

**名前は開発中のものです。** · 2009/03/06(金) 16:34:17

>>490
アンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか

**名前は開発中のものです。** · 2009/03/06(金) 16:39:54

クラスアンチだしｗ
http://www.google.co.jp/search?hl=ja&q=%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%A2%E3%83%B3%E3%83%81&lr=lang_ja
ググるとアンチクラスが出てくる上にプログラムカンケーねえしｗ

まあいいや
C++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい

**名前は開発中のものです。** · 2009/03/06(金) 16:57:37

労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん

>↑アホじゃね？　最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう

じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ

**名前は開発中のものです。** · 2009/03/06(金) 17:07:43

>クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
いくらでもあるのか

そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489

俺にはこの２つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね

>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484

**名前は開発中のものです。** · 2009/03/06(金) 17:20:31

>>484の方が楽だとは思えない
まあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな

**名前は開発中のものです。** · 2009/03/06(金) 18:55:30

namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。

ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。

それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。

**名前は開発中のものです。** · 2009/03/06(金) 20:00:35

まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね

**名前は開発中のものです。** · 2009/03/12(木) 10:42:00

Delphiでシングルトンする方法なんてこれだぞ(公式ライブラリVCLで使われている方法)

interface // 宣言部(C++のヘッダーにあたる)
type
　TPrinter = class　// クラスの宣言
　　：
　end;
function Printer(): TPrinter;

implementation // 実装部(ヘッダーじゃない方)

var FPrinter: TPrinter; // グローバルへんすうw

function Printer(): TPrinter;
begin
　if FPrinter = nil then FPrinter := TPrinter.Create; 　// TPrinter生成
　Result := FPrinter
end;

厳密にインスタンス化の制限とか、もはやどうでもいいクラスｗ

**名前は開発中のものです。** · 2009/03/12(木) 10:43:53

>>498
捕捉：

（わかると思うけど）使う時は、他のユニットから

　Printer.HogeMageSimasu;

見たいに使う

あと抜けてるけど、実際には、finalzation節？でアプリ終了時のFPrinterの開放処理がある。

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

また変なのが沸いてるのか

**名前は開発中のものです。** · 2009/03/18(水) 23:45:50

デバイスに直接アクセスする処理ってどこに書いてる？
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。

今：あちこちでデバイスにアクセス
void draw_landform(void) {
　　...
　　lpD3DDEV->draw(...);
}
void draw_menu(void) {
　　...
　　lpD3DDEV->draw(...);
}

案：デバイスアクセスは１箇所。デバイスに渡すデータをあちこちで作る。
const DrawData *draw_landform(void) {
　　...
　　return ...;
}
const DrawData *draw_menu(void) {
　　...
　　return ...;
}
void main_loop(void) {
　　draw_data.push(draw_landform(), ...);
　　draw_data.push(draw_menu(), ...);
　　lpD3DDEV->draw(draw_data, ...);
}

もし既に案の方法でやってる人いたら使い勝手教えて！

**名前は開発中のものです。** · 2009/03/19(木) 04:54:27

久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ！

**名前は開発中のものです。** · 2009/03/19(木) 05:21:17

描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。

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

俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…

**501** · 2009/03/20(金) 00:10:41

レスありがとう。

>>502
「案」の方に似たやり方だよね？ draw_dataがリスト相当で。
やっぱやってる人いたか。採用してるってことは使いやすいんだろうか

>>503
void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) {
　　...
　　lpD3DDEV->draw(...);
}
みたいな感じ？
デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？
この方が使いやすいってことかな？うーん。。。

>>504
Draw_data::draw(...) {
　　this->lpD3DDEV->draw(this->draw_data, ...);
}
こんな感じ？　ラッパー作れって話？
「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか

うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど
気になる人って少ないんだろうか。
0人では無かったけれど。

**名前は開発中のものです。** · 2009/03/20(金) 02:39:39

まずはMVCを試みてみるのはどうだろうか

**名前は開発中のものです。** · 2009/03/20(金) 04:52:36

struct Visitor;
struct Element { // 訪問される側の基底クラス
    virtual void accept(Visitor&) = 0;
};
class Landform : Element {
public:
    virtual void accept(Visitor& x) { x.visit(*this); }
    Data* getLandData();
private:
    ...
};
class Menu : Element {
public:
    virtual void accept(Visitor& x) { x.visit(*this); }
    Data* getMenuData();
private:
    ...
};

struct Visitor { // 訪問する側の基底クラス
    virtual void visit(Landform&) = 0;
    virtual void visit(Menu&) = 0;
};
class DrawingVisitor : Visitor { // 各要素を訪れて描画を行うクラス
public:
    DrawingVisitor(LPDIRECT3DDEVICE9 p) : pDevice(p) {}
    virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
    virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
private:
    LPDIRECT3DDEVICE9  pDevice;
};
続く…

**名前は開発中のものです。** · 2009/03/20(金) 04:53:53

…続き
elementList.push_back(landform);
elementList.push_back(menu);

void mainLoop() {
    DrawingVisitor visitor(lpD3DDEV);
    for(ElementList::iterator i = elementList.begin(); i != elementList.end(); ++i) {
        i->accept(visitor);
    }
}

うーむ…。

**501** · 2009/03/21(土) 12:54:05

>>506
今回の話ではModelとControllは関係なくて、Viewの枠内だけで完結する話だと思ってる

>>507
複雑すぎて俺の頭では完全には理解できないけど、
> virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
> virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
ここを見るとデバイスに直接アクセスする処理を１クラス内、複数関数にまとめたって感じかな

うーん…、複数の関数にデバイスアクセス処理が分散してるとこがあまりうれしくないかな。
（俺には複雑過ぎるのはさておき）

俺が扱いづらいと思ってるところは、
pDeviceさえあればdraw()以外にもbegin_render()とかset_camera()とかいろいろ
デバイスに対して変更加えることができちゃうわけで、
それをばら撒くってことはいつどこでデバイスに変更が加わるか、例えばいつどこで何回begin_render()されてるのか
とかが追跡しづらくなる。これは１週間後の自分に優しくない。

こんな感じでデバイスに直接アクセスする処理をどう管理したもんかと考えて
ひとつの対策案としてデバイスアクセス処理を１関数内に限定しちゃえってのが >>501 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。

**名前は開発中のものです。** · 2009/03/22(日) 03:32:29

描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。

**501** · 2009/03/23(月) 00:38:25

>>510
確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ2D的にしか使ってないし。
あとデバイスってサウンドとか入力装置とかもあるけど、それらもおんなじ感じで取り扱いたいし。

デバイスにアクセスする処理が関数１個の中に「ひとまとまりで」収まってればＯＫとするなら
下のように書いて済ませられるかな？
void dev_state1(void) {
　　lpD3DDEV->BeginScene();
　　lpD3DDEV->set_parameter(...);
　　lpD3DDEV->draw(draw_landform(), ...);
　　lpD3DDEV->set_parameter(...);
　　lpD3DDEV->draw(draw_menu(), ...);
　　lpD3DDEV->EndScene();
}

ひとまとまりってのは１フレーム分のデバイスアクセス処理全部。
描画内容を大きく変えたい時はdev_state2()とかをまた別に作っておいて、
ゲームのステートに応じてどれを実行するか切り替える。

なんか描画スクリプトの方が夢があるな。
外部GUIツールで描画内容を設計して
吐き出した描画スクリプトをゲームで解釈して表示とかおもしろそう。
でも描画システムの根幹過ぎて汎用的に作るのめんどくさそう。。。

うーん、とりあえず簡単に済ませたいからdev_state1()みたいにベタ書きで
どこまでいけるかやってみるかな。

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

hamigaki::coroutines使ってみた。

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

yhamigakiさんのexec.jamモジュールにはお世話になっております

**名前は開発中のものです。** · 2009/04/05(日) 14:24:00

スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド　仮想描画コマンドを解釈して実際のコマンドを発行

利点単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い

**名前は開発中のものです。** · 2009/04/06(月) 03:21:58

仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。

**名前は開発中のものです。** · 2009/07/15(水) 22:32:12

http://www6.atpages.jp/~autonomydoll/game/RPGClient.zip

クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。

今のクラス構成
ScreenManger-->ScreenGame-->Title
　　　　　｜　　　　　　　　　　　　　　　 |->Main-->Map -|
　　　　　｜　　　　　　　　　　　　　　　　　　　　　-->Unit--->sprite--|
　　　　　｜--------------------------------------------------------------->GraphicsWarpper

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

WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。

**名前は開発中のものです。** · 2009/07/15(水) 22:41:36

>>516
> ScreenManger

画面飼槽

> GraphicsWarpper

グラフィックスワープ装置

何が言いたいのかさっぱりわからないのだが。

**516** · 2009/07/15(水) 22:46:53

>>517
忘れてました。
net frameworkを使ってます。

>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます

GraphicsWarpperは単なるラッパーです。

**名前は開発中のものです。** · 2009/07/15(水) 22:57:45

こんな面白い難読化もなかなかないな

**名前は開発中のものです。** · 2009/07/15(水) 23:01:47

>>519
> net frameworkを使ってます。

.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・

> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます

それならMangerではなくManagerだろ。

> GraphicsWarpperは単なるラッパーです。

それなら、WarpperではなくWrapperだろ。

小学校は夏休みなのか・・
せめて中学生になってからにしてくれ

**名前は開発中のものです。** · 2009/07/15(水) 23:14:16

>>521
すまん。スペルミスった・・・。

**名前は開発中のものです。** · 2009/07/16(木) 01:35:23

まず日本語と英語を勉強するべきでは？
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね

ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う

**名前は開発中のものです。** · 2009/07/16(木) 02:06:03

>>523
ありがとう。
それをあたってみる。

**名前は開発中のものです。** · 2009/07/16(木) 02:29:30

質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ

**名前は開発中のものです。** · 2009/07/16(木) 05:49:13

2～3人で多いのか、寂しい生活してるんだな

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

言われて悔しいならもっと勉強しろよ

**名前は開発中のものです。** · 2009/08/14(金) 18:57:02

コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･

>>395
395以前のまとめ

>>404,406-407
シーン遷移考え方

>>408-413,416-425
シーン遷移実装サンプルと問題点。

>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。

>>437-443
オブジェクトと座標管理

>>444-456
オブジェクトと衝突判定と全体効果

>>459-465
デバッグ用処理を考える。(衝突判定表示とか)

>>501-511
DirectXのデバイスの管理とか使い方

>>523
ネットワーク機能参考図書紹介

**名前は開発中のものです。** · 2009/08/14(金) 19:24:51

STGのビジュアル関連向上に関するメモ。
･･･あんま設計と関係ないな･･･

それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。

ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。

弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。

**名前は開発中のものです。** · 2009/08/14(金) 22:21:56

>>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。

**名前は開発中のものです。** · 2009/10/05(月) 01:40:33

シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが，
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか？

データクラスを作ってアクセッサで操作を許す？
それとも，すべてグローバル変数で持たせる？

**名前は開発中のものです。** · 2009/10/05(月) 04:33:25

シングルトンクラスのオブジェクトをグローバルに定義する

**名前は開発中のものです。** · 2009/10/05(月) 07:34:29

SQLiteとか使って手抜くってのもあり

**名前は開発中のものです。** · 2009/10/14(水) 22:12:56

グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。