- 1 名前：名前は開発中のものです。 [2008/05/23(金) 21:10:59 ID:8M1gqhPX]
- 具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく
- 484 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 14:26:30 ID:7UNSgj8M]
- グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう
- 485 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 14:28:31 ID:7UNSgj8M]
- あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。
- 486 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 15:48:06 ID:A313Daxt]
- >>484-485
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー
- 487 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:07:52 ID:7UNSgj8M]
- >>486
そのクラスのインスタンスが１つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ
- 488 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:18:21 ID:7UNSgj8M]
- www.geocities.jp/ky_webid/design_pattern/009.html
「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね？
// 生成やコピーを禁止する
↑アホじゃね？ 最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい
- 489 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:29:34 ID:7UNSgj8M]
- まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな
- 490 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:29:53 ID:oPKUKLY9]
- 先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件
- 491 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:34:17 ID:7UNSgj8M]
- >>490
アンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか
- 492 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:39:54 ID:7UNSgj8M]
- クラスアンチだしｗ
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++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい
- 493 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:57:37 ID:12yJl3As]
- 労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね？ 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
- 494 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 17:07:43 ID:7UNSgj8M]
- >クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
いくらでもあるのか
そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489
俺にはこの２つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね
>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484
- 495 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 17:20:31 ID:12yJl3As]
- >>484の方が楽だとは思えない
まあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな
- 496 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 18:55:30 ID:Erqh3NJs]
- namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。
- 497 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 20:00:35 ID:z7QigqBL]
- まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね
- 498 名前：名前は開発中のものです。 mailto:sage [2009/03/12(木) 10:42:00 ID:X7nBBwQA]
- 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;
厳密にインスタンス化の制限とか、もはやどうでもいいクラスｗ
- 499 名前：名前は開発中のものです。 mailto:sage [2009/03/12(木) 10:43:53 ID:X7nBBwQA]
- >>498
捕捉：
（わかると思うけど）使う時は、他のユニットから
Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節？でアプリ終了時のFPrinterの開放処理がある。
- 500 名前：名前は開発中のものです。 mailto:sage [2009/03/16(月) 15:21:22 ID:FTtiBwy2]
- また変なのが沸いてるのか
- 501 名前：名前は開発中のものです。 mailto:sage [2009/03/18(水) 23:45:50 ID:1sOkzJT6]
- デバイスに直接アクセスする処理ってどこに書いてる？
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。
今：あちこちでデバイスにアクセス
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, ...);
}
もし既に案の方法でやってる人いたら使い勝手教えて！
- 502 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 04:54:27 ID:KYbRBn+z]
- 久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ！
- 503 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 05:21:17 ID:XLj1eEa+]
- 描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。
- 504 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 19:28:19 ID:ALN5WhPj]
- 俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…
- 505 名前：501 mailto:sage [2009/03/20(金) 00:10:41 ID:/TREybMM]
- レスありがとう。
>>502
「案」の方に似たやり方だよね？ draw_dataがリスト相当で。
やっぱやってる人いたか。採用してるってことは使いやすいんだろうか
>>503
void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) {
...
lpD3DDEV->draw(...);
}
みたいな感じ？
デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？
この方が使いやすいってことかな？ うーん。。。
>>504
Draw_data::draw(...) {
this->lpD3DDEV->draw(this->draw_data, ...);
}
こんな感じ？ ラッパー作れって話？
「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか
うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど
気になる人って少ないんだろうか。
0人では無かったけれど。
- 506 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 02:39:39 ID:D2lp0Ec4]
- まずはMVCを試みてみるのはどうだろうか
- 507 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 04:52:36 ID:09EDEaYz]
- 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;
};
続く…
- 508 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 04:53:53 ID:09EDEaYz]
- …続き
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);
}
}
うーむ…。
- 509 名前：501 mailto:sage [2009/03/21(土) 12:54:05 ID:Y4F/PoMw]
- >>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 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。
- 510 名前：名前は開発中のものです。 mailto:sage [2009/03/22(日) 03:32:29 ID:O7e3N6nq]
- 描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。
- 511 名前：501 mailto:sage [2009/03/23(月) 00:38:25 ID:/nVLLFvd]
- >>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()みたいにベタ書きで
どこまでいけるかやってみるかな。
- 512 名前：名前は開発中のものです。 mailto:sage [2009/03/25(水) 00:59:33 ID:koP5FPqt]
- hamigaki::coroutines使ってみた。
- 513 名前：名前は開発中のものです。 mailto:sage [2009/03/25(水) 12:39:16 ID:C50L0uFm]
- yhamigakiさんのexec.jamモジュールにはお世話になっております
- 514 名前：名前は開発中のものです。 [2009/04/05(日) 14:24:00 ID:a5PaoF6B]
- スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い
- 515 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:21:58 ID:NgKFyYts]
- 仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。
- 516 名前：名前は開発中のものです。 [2009/07/15(水) 22:32:12 ID:1c2msACv]
- www6.atpages.jp/~autonomydoll/game/RPGClient.zip
クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
｜ |->Main-->Map -|
｜ -->Unit--->sprite--|
｜--------------------------------------------------------------->GraphicsWarpper
- 517 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:40:07 ID:h6KyoexM]
- WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。
- 518 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:41:36 ID:3ppQI3l+]
- >>516
> ScreenManger
画面飼槽
> GraphicsWarpper
グラフィックスワープ装置
何が言いたいのかさっぱりわからないのだが。
- 519 名前：516 [2009/07/15(水) 22:46:53 ID:1c2msACv]
- >>517
忘れてました。
net frameworkを使ってます。
>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
GraphicsWarpperは単なるラッパーです。
- 520 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:57:45 ID:cL81hhcG]
- こんな面白い難読化もなかなかないな
- 521 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 23:01:47 ID:3ppQI3l+]
- >>519
> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。
小学校は夏休みなのか・・
せめて中学生になってからにしてくれ
- 522 名前：名前は開発中のものです。 [2009/07/15(水) 23:14:16 ID:1c2msACv]
- >>521
すまん。スペルミスった・・・。
- 523 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 01:35:23 ID:Ac1CnfQd]
- まず日本語と英語を勉強するべきでは？
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う
- 524 名前：名前は開発中のものです。 [2009/07/16(木) 02:06:03 ID:Dq9kBSTx]
- >>523
ありがとう。
それをあたってみる。
- 525 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 02:29:30 ID:lK28N0n1]
- 質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ
- 526 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 05:49:13 ID:0eDNLm6a]
- 2〜3人で多いのか、寂しい生活してるんだな
- 527 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 10:25:09 ID:irpkCXOF]
- 言われて悔しいならもっと勉強しろよ
- 528 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 18:57:02 ID:qfXJNhjS]
- コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･
>>395
395以前のまとめ
>>404,406-407
シーン遷移考え方
>>408-413,416-425
シーン遷移実装サンプルと問題点。
>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。
>>437-443
オブジェクトと座標管理
>>444-456
オブジェクトと衝突判定と全体効果
>>459-465
デバッグ用処理を考える。(衝突判定表示とか)
>>501-511
DirectXのデバイスの管理とか使い方
>>523
ネットワーク機能参考図書紹介
- 529 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 19:24:51 ID:qfXJNhjS]
- STGのビジュアル関連向上に関するメモ。
･･･あんま設計と関係ないな･･･
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。
- 530 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 22:21:56 ID:FZUQWr9u]
- >>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。
- 531 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 01:40:33 ID:mQYy5BRf]
- シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが，
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか？
データクラスを作ってアクセッサで操作を許す？
それとも，すべてグローバル変数で持たせる？
- 532 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 04:33:25 ID:/TvwIsfE]
- シングルトンクラスのオブジェクトをグローバルに定義する
- 533 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 07:34:29 ID:Rel4l/Gg]
- SQLiteとか使って手抜くってのもあり
- 534 名前：名前は開発中のものです。 mailto:sage [2009/10/14(水) 22:12:56 ID:TwzkU58s]
- グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。
- 535 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 07:50:05 ID:P3b4xThD]
- アクセッサ書くのめんどいだろ
- 536 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 08:41:22 ID:OtHf9VTl]
- なんでそんな両極端なの？
- 537 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 15:54:18 ID:byjv3si3]
- 0と1しか無いからな
オタクの頭ん中は
- 538 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 20:13:55 ID:P3b4xThD]
- 別に両極端で構いません．
意見を頂けるだけで嬉しいです．
むしろ噛み付くほうが迷惑です．
- 539 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 22:16:10 ID:r8d5RKMA]
- 使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。
- 540 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 22:18:05 ID:2byzEsEE]
- >>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。
- 541 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 23:29:40 ID:r8d5RKMA]
- 俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。
- 542 名前：536 mailto:sage [2009/10/16(金) 00:35:50 ID:L+kS7tAJ]
- >>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…
- 543 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 01:18:33 ID:MsmDVyev]
- ２ｃｈで素直に謝られると逆に困ります．
参考になりました，ありがとうございます．
- 544 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 01:38:32 ID:tEeFyBBH]
- グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。
// 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);
て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。
- 545 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 06:29:56 ID:UJ9WR3Zt]
- 代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。
- 546 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 11:40:43 ID:/PDPq+0/]
- 入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。
- 547 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 20:07:25 ID:eJ9LLkd5]
- アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。
- 548 名前：名前は開発中のものです。 mailto:sage [2009/10/18(日) 12:51:59 ID:Yr/zm5ey]
- >546
確かに使い方を間違えるってのはよく起こる
|
 |
