OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:19

>>191
では、そのIsKindOf(RUNTIME_CLASS())（のようなもの）であるとか、
Updateのメソッド自体に更新の判断をさせるほうが良い気がするのですが…。
それではデメリットがあるのですか？

**名無しさん＠お腹いっぱい。** · 01/11/11 23:23

>>195
IsKindOfを実装するには、これまたクラスごとに面倒なコーディングが増えるわけよ。
関数を作って、SetTask(Function)を呼び出すだけとい
お手軽さとは雲泥の差があるわけ。

Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ？
それまた面倒でパフォーマンスも悪いわけ。

**187** · 01/11/11 23:29

一応、現在の実装例を書いておこう
CTaskManager{
public:
TASK* SetTask(void* function_ptr);
void Update();
private:
TASK mTask[MAX_TASK];
};

CEnemy{
public:
static void Enemy1(TASK*);
static void Enemy2(TASK*);
static void Enemy3(TASK*);
};

＿ · 01/11/11 23:34

>>192
俺もC++の可読性については、ちょっと同意かなあ。
ちらっと読んでもわからないんだよね、他人のソースが。
継承ツリーの根元にあるメンバなんか、いきなり出されても
作った本人しかわからないよねえ。
グローバル変数使いまくりのCでも、そっちの方が読みやすいというのはあるよねえ。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:34

C++(OO)は圧倒的にデバッグが楽。って思うのは俺だけ？
特に多人数での開発になると顕著だと思うんだけど。
他のプログラマによる不正な操作を制限しやすいのはかなりメリットだと思う。

Cでもキチンと書けば問題無いんだけど、
なんか致命的かつ再現率の低いバグが出やすい気がする。
↑これは自分がへぼいのは自覚してます。

あとまともに動けば例外処理もかなり強力だと思うざんす。

**199** · 01/11/11 23:36

圧倒的ってほどでもないですね。誇大表現でした。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:36

>>196
>Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ？
こういう場合、むしろ管理する側がチェックするよりも自分自身が判断する方が
むしろ軽くできそうなすみそうな気がしますけど…（適当でスマソ）
＃もちろんこの程度ならC++使わなくても、Cだけでも出来ますけど。
class ab
{
virtual void update(const status& a)=0;
};
class con0 : public ab
{
virtual void update(const status& a){ do_update(); } // これはいつでも更新するクラス
}
class con1 : public ab
{
virtual void update(const status& a){ if(!a->pause){ do_update(); }} // pauseしてないときだけupdate
}

...
for(vector<ab*>::iterator i=obj.begin(); i!=obj.end(); i++){(*i)->update(current_status);}

**187** · 01/11/11 23:46

>>201
いや、
if (pause){
　for (;;){
　　if (task[i]->update == PauseTask){
　　　　(*task[i]->update)(&task[i]);
　　}
　}
}else{
　for (;;) (*task[i]->update)(&task[i]);
}

条件分岐をループの外に持っていけるし、妙な引数も必要ない分、
圧倒的に有利だよ。
まあPauseの用途に限定するならタスク構造体に属性を持たしておいた方が便利だけど。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:47

>>199
なんとなく同意です。
自分自身のヘボさを知るものとしてはCよりもデータへの不正な制限を掛けやすい
C++の方がいいかなぁ…と思ってます。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:50

>>199
俺も楽だと思うよ。
問題が局所化されるから見る範囲がかなり限定されてくる。
まー、何にせよ慣れでしょうね。
Cべったりな人たちには無理せず使い慣れたCがよござんしょ。

**192** · 01/11/12 00:00

>>194
ツールではバリバリ使うんで業界的に（というか、うちの会社的に）
「これから」っていうわけでもないんですけどね。なんでツールで
使うかといえば、クラスライブラリが用意されてたりして「圧倒的
に効率が上がる」から。

ツールとか実用ソフトの場合、インターフェイスの統一性
が重要ですが、ゲームの場合は寧ろゲーム毎の独自性や面白さ
の方が優先されるわけで、その辺も難しいですね。

あと、コンシューマーの場合リソースの管理をかなり見通しが
効くようにしておかないといけないのが、楽に組めない要因で
すね。快適にプレイさせる為には必要になった時にリソース
確保じゃ遅い（先読み対応）とか・・・
メモリも、「メモリ１２８ＭＢ以上推奨」で済まないし、
「最悪仮想記憶で・・・」というわけにもいかない。
Ｃ＋＋でやるにしても、メモリ管理は全部自前でしょうね。
まぁこれは、ＰＣでもそうなんでしょうけど。

なんか、愚痴っぽいな。

**名無しさん＠お腹いっぱい。** · 01/11/12 00:01

>>202
う～ん、このあたりは判断すべき条件の場合分けの数であるとか、どこの
オブジェクトがその判断に責任を持つかっていう所で実装を分けるかも
しれないっすね。（そういう意味ではpauseは不適当だったか？）

私が>>202のようなソースを見たときに一番危惧するのは、条件分けが
多岐にわたったときに（pauseだけではなく、アドバタイズであるとか、
デバッグ用のモード(?)であるとか）updateの呼び出しが多個所になって
しまい、たとえばupdateメソッドの呼び出し方が変わった場合、変更が多岐
にわたってしまうんでないかい？とか思ってしまうのです。

＃このあたりの考え方は好みに近いところだと思うので、なにが正解とも
＃思いませんけど…。

**名無しさん＠お腹いっぱい。** · 01/11/12 00:44

>>206
CTaskManager::Update()
{
　switch(mode){
　case UPDAETMODE_DEFAULT:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　case UPDATEMODE_PAUSE:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　case UPDATEMODE_DEBUG:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　}
}

多岐にわたる理由などありませんが。

**名無しさん＠お腹いっぱい。** · 01/11/12 00:45

>>207
ヲイヲイ・・・

**名無しさん＠お腹いっぱい。** · 01/11/12 00:46

>>208
何か問題でも？

**206** · 01/11/12 01:07

>>207
208の煽りは私ではないですよ～。誤解しないでね。（ﾆｺ

＃以下は好みの話し程度に読んでください。
いや、>>202のpauseの時にその呼び出し側に関係ない処理は（OOP抜きとは関係ないですけど）
呼び出し側で制御すべきでないと思うんですよ。（それは例え>>207のような形であっても、結局
caseの数だけupdateメソッドを呼び出す個所が出来るわけで。）
もし一つ一つのオブジェクトで処理を判断するのが重いぜ、やってられないぜというのであれば、

// >>201からのつづきと考えてくださいね
// 文法的に嘘があっても無視の方向で（自虐藁
class ab_collection
{
vector<ab*> abc;
void add_ab(ab* _o){ abc.push_back(_o); }
virtual void update(const status& _stat) = 0;
};
// 見たいな形でオブジェクトをまとめるクラスを一段「かませ」て、
class free_ab_collection : public ab_collection // 判断のひつようなしクラス
{
virtual void update(const status& _stat){
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
}

class test_ab_collection : public ab_collection // pauseフラグをチェック
{
virtual void update(const status _stat){
if(stat->pause){ return; } // ここでチェックすることで、以下のabの各クラスではチェックする必要が無くなる
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat);
}

みたいにしてやれば、見通しも良いまま、効率を保つことも可能ではないかと。
（親クラスはab_collectionの塊を持ってupdateを呼び出すだけ。）

実際にプログラムで重いところって大量のメモリのキャッシュミスと回数の非常に多い単純計算
だと思ってるんで、そこさえ気をつければ、見通しよくプログラムするためのコストって許されるんじゃ
ないかと思ってます。
＃もちろん、見易さは人によってそれぞれだとおもうんで、>>207さんの方法も尊重します。

**206** · 01/11/12 01:09

>>210間違い
それぞれのab_collectionから継承させたオブジェクトで
>for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
を呼ぶのは愚の骨頂ですね。ab_collectionに置くべき処理でした。
失礼…。

**名無しさん＠お腹いっぱい。** · 01/11/12 03:36

少なくともＰＣゲームのプログラムを組む場合、
Ｃ＋＋を利用したことによるオーバーヘッドはほとんど
気にしなくていいような気がします。

**名無しさん＠お腹いっぱい。** · 01/11/12 07:13

PC(Windows)のゲームでメモリの断片化気にして組まれてるのはどのくらいあるんだろ…。

**名無しさん＠お腹いっぱい。** · 01/11/12 07:56

というか断片化の話はoperator newのオーバーロードで対処。
CTaskの継承クラスのサイズに最大128バイトとか制限かけて、
メモリプールから確保するようにする。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:17

＞というか断片化の話はoperator newのオーバーロードで対処。
オーバーライドだと思うが…。
細かい突っ込みかな。

malloc自体が仮想メモリを利用することが前提の関数だし、おそらくnewもそうだろうと思います。
仮想メモリがある環境だと、あまりメモリの分断化は気にしないかも。
コンシューマだとガベージコレクトやメモリコンパクションやらを考えないと
いけないでしょうね。
メモリマップを始めにきっちりと作るというのも手だと思いますけど。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:24

>>215
オーバーロードでも対処できるよ。
newに特殊なパラメータ(フラグ)を取らせてそれによって、デフォルトのnewとは
動作を変える。
この場合、newの動作が暗黙のうちに最適化されるのではなく、プログラマが必要
に応じてメモリ割り当ての方法を選択できる。
うまくやれば、こっちの方が便利かもしれないよ。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:28

昔、擬似タスク処理をC++で実現しようとしたとき、処理とその処理で使う
メモリ領域をどうすり合わせるかで挫折した。

Cの場合は、構造体内部に関数へのポインタがあればそれを切りかえることで
簡単に実現できた。
C++の場合、上記メソッドのオーバーロードで簡単に実現できるのはひとつの
メソッドだけ。
無理やりやろうとすると、オーバーロードするメソッドの中で
処理するメソッドへのポインタを利用して処理を飛ばすという、
なんとも汚いものになった。
こんなことするくらいなら、構造体+関数へのポインタで処理させたほうがまし
だと思った。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:36

>>217
ごめん、ちょっとわかりにくい。
「オーバーロードで簡単に実現できるのは１つだけ」というのは
operator newのオーバーロードが１つだけってこと？

**名無しさん＠お腹いっぱい。** · 01/11/12 23:02

>処理するメソッドへのポインタを利用して処理を飛ばすという、
>なんとも汚いものになった。

あまり解釈に自信がないんだけど、例えばこういうの？汚いかなあ。

typedef void(Task::*TaskFunc)();

class Task {
public:
　　void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　　void Update() { (this->*m_updateFunc)(); }
private:
　　TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
　　HogeTask() {
　　　　SetFunc((TaskFunc) Func1);
　　}
　　void Func1() {
　　　　...
　　　　SetFunc((TaskFunc) Func2);
　　}
　　void Func2() { ... }
　　void Func3() { ... }
};

**219** · 01/11/12 23:06

こうやってTaskManagerから直接呼び出してもいいか。

class Task {
　　friend class TaskManager;
public:
　　void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
private:
　　TaskFunc m_updateFunc;
};

**219** · 01/11/12 23:07

ｷﾞｬｰｽ
s/Method/Func/g

**名無しさん＠お腹いっぱい。** · 01/11/13 00:29

C++のソースはなぜこうも美しく無いのだろうか？

**名無しさん＠お腹いっぱい。** · 01/11/13 00:30

>>222 Cで同じもん書いてみてみそ。

**名無しさん＠お腹いっぱい。** · 01/11/13 04:25

Cの人はなぜ、継承だけで解決しようとしたり、
C++で関数ポインタ使うのはイヤみたいに言うのかわからん。

**名無しさん＠お腹いっぱい。** · 01/11/13 10:18

とりあえず、タスクを１ステップ進行させるメソッドの名前は
みんなUpdateですか。

**名無しさん＠お腹いっぱい。** · 01/11/13 13:13

もうvirtual関数無しではプログラム組めないっす。

ゲーム系だと特に期限ギリギりでの仕様変更が多いので（仕様書な
んてものが存在しない場合も多いけど）、パッチ当てる感覚でその場
がしのげて良いです。

その後の事はしらん（藁。

**名無しさん＠お腹いっぱい。** · 01/11/13 14:05

>>219
Func1 は
typedef void (HogeTask::*FuncType)();
であって、
typedef void(Task::*TaskFunc)();
ではない。
メンバ関数へのポインタはクラスによってサイズが違うという話を聞いたんだが、
SetFunc((TaskFunc) Func1);
このキャストは安全なのか？
を

**名無しさん＠お腹いっぱい。** · 01/11/13 14:08

典型的なC++のタスクと、Game Programming Gemsの3.0みたいな
マクロ使った状態マシン組みあわせてみない？
オレは今から試すにょ。

**名無しさん＠お腹いっぱい。** · 01/11/13 14:17

>>227
安全じゃないからキャストしてると思われ（ｗ
仕様上は安全じゃない（プログラミング言語C++第３版15.5.1）が、
C++の実装上は上手くいくのではないか。
ちとキモチワルイ感はある。

**名無しさん＠お腹いっぱい。** · 01/11/13 14:36

ありゃ、キャストしたからってうまくいくのか?
エラーが出そうなものだが。

g++でコンパイルしてみたけど、駄目だった。
コンパイラの問題かな。

**名無しさん＠お腹いっぱい。** · 01/11/13 14:58

こんなのどう？

#define DECLARE_TASK(TypeName) \
void (TypeName::*m_updateFunc)();\
public:\
virtual void Update(){(this->*m_updateFunc)();}\
private:\

#define SET_TASK_FUNC(FuncName) {m_updateFunc = FuncName;}

class Task
{
public:
　　virtual void Update() = 0;
};

class HogeTask : public Task
{
　　DECLARE_TASK(HogeTask)
public:
　　HogeTask(){
　　　SET_TASK_FUNC(Func1);
　　}

　　void Func1(){
　　　…
　　　SET_TASK_FUNC(Func2);
　　}
　　void Func2(){};
};

**217** · 01/11/13 15:31

わたしが昔、書いたのは大体こんな感じでした。
219さんのソースを利用させてもらいます。

extern "C" {
#include <stdio.h>
}

//-----------------------------------------------------------
// 基本擬似タスク
//-----------------------------------------------------------
class Task {
public:
　Task() {};
　virtual ~Task() {};
　virtual void SetFunc(void) {}
　virtual void Update(void) {}
};

//-----------------------------------------------------------
// 擬似タスク定義部
//-----------------------------------------------------------
class HogeTask;

typedef void(HogeTask::*TaskFunc)(void);

class HogeTask : public Task {
public:
　HogeTask() { SetFunc(&HogeTask::Func1); }
　~HogeTask() {};

　void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　void Update() { (this->*m_updateFunc)(); };

　void Func1() { printf("Func 1\n"); SetFunc(&HogeTask::Func2); }
　void Func2() { printf("Func 2\n"); SetFunc(&HogeTask::Func3); }
　void Func3() { printf("Func 3\n"); SetFunc(&HogeTask::Func1); }
private:
　TaskFunc m_updateFunc;
};

**217** · 01/11/13 15:32

続き
//-----------------------------------------------------------
// 擬似タスク実行部
//-----------------------------------------------------------
class ExecuteTask {
　Task *taskArray[100];
　int iTaskPoint;
public:
　ExecuteTask() { iTaskPoint = 0; }
　void SetTask(Task* prtTask) { taskArray[iTaskPoint++] = prtTask; }
　void execute(void) {
　　{for(int i = 0; i < iTaskPoint; i++) {
　　　taskArray[i]->Update(); }
　　}
　}
};

**217** · 01/11/13 15:34

最後

//-----------------------------------------------------------
// メイン
//-----------------------------------------------------------
int main(int argc, char** argv) {
　HogeTask hogeTask;
　HogeTask hogeTask2;
　ExecuteTask executeTask;

　printf("<<1st>>\n");
　executeTask.SetTask(&hogeTask); // タスク1セット
　executeTask.execute(); // タスク実行

　printf("<<2nd>>\n");
　executeTask.execute(); // タスク実行

　printf("<<3rd>>\n");
　executeTask.SetTask(&hogeTask2); // タスク2セット
　executeTask.execute(); // タスク実行

　return 0;
}

**217** · 01/11/13 15:43

実際は、タスク実行終了時の資源の解放とか、タスク実行順序とか
いろいろ機能がありました。
ともあれ、結局構造体+関数へのポインタで実装したほうが
分かりやすい上に、パフォーマンスの上という理由で捨てました。

**名無しさん＠お腹いっぱい。** · 01/11/13 15:46

>>230
VC だとメンバ関数のアドレスはその名前だけでよいが、
C++ の仕様だと &クラス名::関数名でないとダメ
そこ以外でエラーはでないと思われ

**230** · 01/11/13 20:52

>236
うむ確かに、うまくいった。
つうか、なぜ気がつかない、俺。

こうなると、219のコードが一番スマートなのかな?
キャストが嫌ってことなら、231になるか。

**名無しさん＠お腹いっぱい。** · 01/11/13 21:09

試しにこんな感じにモデル化してみたんですが、どんなもんですかねえ。
これをいかに楽に記述する方法を考えるかみたいなー。
何かタスク記述言語でも作って、
C/C++ソースに変換するフィルタでも用意するのがええかのう。

タスク {
　　タスク変数
　　タスクの状態

　　タスク作成時の処理
　　タスク破棄時の処理
　　汎用イベント処理

　　状態１ {
　　　　状態の初期化
　　　　更新処理
　　　　状態の後始末
　　　　汎用イベント処理
　　}
　　状態２ {
　　　　状態の初期化
　　　　更新処理
　　　　状態の後始末
　　　　汎用イベント処理
　　}
　　...
}

**230** · 01/11/13 21:25

なんかここまで来ると、クラスの必要ないじゃないか
って感じもするな…。

#include <iostream>

class Task;
class TaskManager;

typedef void(Task::*TaskFunc)();

class Task {
　friend class TaskManager;
public:
　void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　//　void Update() { (this->*m_updateFunc)(); }
private:
　TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
　HogeTask() {
　　SetFunc(static_cast <TaskFunc> (&HogeTask::Func1));
　}
　void Func1() {
　　cout << "Func 1\n";
　　SetFunc(static_cast <TaskFunc> (&HogeTask::Func2));
　}
　void Func2() { cout << "Func 2\n"; }
　void Func3() { cout << "Func 3\n"; }
};

class TaskManager {
　Task *taskArray[100];
　int iPoint;
public:
　TaskManager() { iPoint = 0; }
　~TaskManager() {}
　void setTask(Task* task) { taskArray[iPoint++] = task; }
　void execute(void) {
　　{for(int i = 0; i < iPoint; i++) {
　　　(taskArray[i]->*(taskArray[i]->m_updateFunc))();
　　}}
　}
};

**名無しさん＠お腹いっぱい。** · 01/11/13 22:00

でも、Ｃで書いてUpdate関数にp->xとかp->vxとか並びまくったり、さらに
#define VX　(p->vx)
みたいな真似をしたりするのもどうも気が引けるとゆーか・・・。

**名無しさん＠お腹いっぱい。** · 01/11/14 12:35

オブジェクトの挙動のパフォーマンスなんて
多少高かろうが低かろうが屁みたいなもんじゃん。
描画エンジンの都合で……ならわかるけど。

**名無しさん＠お腹いっぱい。** · 01/11/14 12:52

>>241
文句言っている人は、たぶんコストが無視できないプラットフォームで作ってるんですよ・・・。

**名無しさん＠お腹いっぱい。** · 01/11/14 23:11

age

**名無しさん＠お腹いっぱい。** · 01/11/15 00:27

>>241
んなことはない。
オブジェクト指向ヲタはSetPixel,GetPixelとかまで仮想関数
にしたがるから。
それにパフォーマンスが問題にならないような上位層はスクリプトにするのが普通だし。

**名無しさん＠お腹いっぱい。** · 01/11/15 00:36

>>244
それ描画まわりじゃねえか

**名無しさん＠お腹いっぱい。** · 01/11/15 01:25

>>241
そういう簡単な挙動しか実装しない場合は
オブジェクト指向化の恩恵も少ないと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/15 02:14

>>239
たぶんサンプルコードだからだと思うけど、
Task *taskArray[100];　とかがいや。std::list使おうよぅ

**名無しさん＠お腹いっぱい。** · 01/11/15 11:09

>>247
禿同｡

**名無しさん＠お腹いっぱい。** · 01/11/15 12:18

皆さんどうしても関数ポインタ使わないと気が済まないの？
なんで？
パフォーマンスのため？
タスクシステムを忠実にC++で再現したいから？

CSomeTask::update ()
{
　switch(this->mode){
　case UPDAETMODE_DEFAULT:
　　this->do_default ();
　　break;
　case UPDATEMODE_PAUSE:
　　this->do_pause ();
　　break;
　case UPDATEMODE_DEBUG:
　　this->do_debug ();
　　break;
　}
}

実際これでほぼ十分でしょ。

**名無しさん＠お腹いっぱい。** · 01/11/15 12:36

まあ、実用上はそういうコードでほぼ大丈夫なんだけども。

＞タスクシステムを忠実にC++で再現したいから？
それに加えて、激しく状態遷移するタスクのデバッグは
もうこりごりってのもあるです。

**名無しさん＠お腹いっぱい。** · 01/11/15 13:55

>249
ゲーム全体で擬似的なスレッド処理を実現させたいからだと思われ。
背景をスクロールさせながら、ウィンドウをアニメショーンさせつつ移動させたり
するのをスレッドで実装すると分かりやすいからでしょう。
普通に、ループのなかでやるとifの連発になりそうだし。

＞std::list使おうよぅ
STLを使うとついてこれない人がいるから…。
という冗談はさておき、サンプルだからでしょう。

**名無しさん＠お腹いっぱい。** · 01/11/15 14:27

>>249はその「擬似的なスレッド処理」の中身だと思うですが。

**名無しさん＠お腹いっぱい。** · 01/11/15 15:05

>>249
汎用性の問題。
関数ポインタの場合はswitchと違って、
機能を増やしても書き直す必要がない。

**名無しさん＠お腹いっぱい。** · 01/11/15 17:07

ついでに
C++のメンバ関数へのポインタでやると
関数1つ追加ごとにヘッダーへの変更が発生するのも問題。
privateな関数をどうしてヘッダーに書かねばならん！

**名無しさん＠お腹いっぱい。** · 01/11/15 17:56

>>251
listは遅いのでvector使おう。

**名無しさん＠お腹いっぱい。** · 01/11/15 19:27

あんまり関数ポインタを多用するのは
オブジェクト志向っぽくない気がする。

**名無しさん＠お腹いっぱい。** · 01/11/16 00:18

>254
C++は、クラス定義を見ただけで、だいたい何をやってるか分かって
便利だと思っていた俺は厨なのかしらん。

っていうか、みんなVC++のClassViewを使いませんか？

**名無しさん＠お腹いっぱい。** · 01/11/16 00:30

>>241
何言ってるのよ
市販品かいとりますがな

**名無しさん＠お腹いっぱい。** · 01/11/16 00:31

>257
MFCに不満が山ほどあるから、使ってない。

**名無しさん＠お腹いっぱい。** · 01/11/16 00:42

>>255
あのコードだとタスクは死なないみたいだけど、
ふつー死ぬでしょ　順番かんけーなく
eraseのコスト考えたらlist

**名無しさん＠お腹いっぱい。** · 01/11/16 00:47

ClassViewマンセー

>>259
SDKベースでもClassViewは使えるよ。コード補完も。

**名無しさん＠お腹いっぱい。** · 01/11/16 00:59

>>261
あ、ClassViewか
スマソ、ClassWizardと勘違い

**名無しさん＠お腹いっぱい。** · 01/11/16 01:54

ちなみに、タスク間のデータの受け渡しって、みなさんどうやってます？

enum{
WORK1,
WORK2,

WORK_MAX,
};
DWORD Work[WORK_MAX];
をグローバルで宣言して共用してます。

もっとスマートで近代的なやり方を教えてプリーズ。

ＯＯと関係無い可能性があるので、sage

**名無しさん＠お腹いっぱい。** · 01/11/16 03:09

ソケット

**254** · 01/11/16 06:16

>>257
べつにヘッダーに書く手間が面倒なわけじゃない。
外部が使用するインターフェースに変更があるわけじゃないのに
内部に機能を追加するだけで、インターフェースを使用している
モジュールに再コンパイルがかかるのが嫌なだけ。

**254** · 01/11/16 06:21

しまった、俺もClassWizardと勘違い

**名無しさん＠お腹いっぱい。** · 01/11/16 15:25

>>265 Bridgeパターン

**254** · 01/11/16 15:58

結局、派生先を生成してるファイルは再コンパイルせないかん。
まぁそのくらいはどうでもいいが、いちいち基底クラス作って
どうたらこうたらなんてやってられんと思うのだが…

**名無しさん＠お腹いっぱい。** · 01/11/16 18:20

>>268
VC++使ってると全然気にならないんだけどな。

**名無しさん＠お腹いっぱい。** · 01/11/16 23:37

Delphi使ってると再コンパイルの手間すら気にならんけどな。

**名無しさん＠お腹いっぱい。** · 01/11/17 00:32

仕様がしっかりしている場合に限るけれど、
こーゆー書き方なら、たまぁにする。
class CMain;
class CSub
{
public:
CSub(){}
virtual ~CSub(){}
virtual void FunkA(CMain*pMain) = 0;
virtual void FunkB(CMain*pMain) = 0;
};
class CSubNull : public CSub
{
public:
void FunkA(CMain*){}
void FunkB(CMain*){}
};
class CMain
{
CSub*m_pSub;
static CSubNull m_SubNull;
public:
CMain(){ m_pSub = &m_SubNull; }
virtual ~CMain(){}
void FunkA(){ m_pSub -> FunkA(this); }
void FunkB(){ m_pSub -> FunkB(this); }
void SetSub(CSub*pSub)
{
if(pSub == NULL)pSub = &m_SubNull;
m_pSub = pSub;
}
CSub*GetSub(){ return m_pSub; }
};

**名無しさん＠お腹いっぱい。** · 01/11/17 00:51

それは立派なStateパターンでんな。

**名無しさん＠お腹いっぱい。** · 01/11/17 13:55

C使いでC++がダメ!って言う人は、実装継承とか深い継承とかを試してみてダメって言ってる気がする。
デザインパターン勉強すれば便利に使えるんだけど、使えるかどうか試してみるだけの人にデザパタ勉強しろとは言えないからなぁ。

**名無しさん＠お腹いっぱい。** · 01/11/17 18:20

OOの真髄はデザインパターンによるコーディングのパターン、及びテンプレート化だからなぁ･･･
ボトルネックとか、無駄な継承等を最適化していったら、どっかで既に使われていたパタｰンの
亜流だったなんての事は、実際かなりあったよ･･･

**名無しさん＠お腹いっぱい。** · 01/11/17 19:25

>>273
意味不明

**名無しさん＠お腹いっぱい。** · 01/11/18 02:39

>>275
デザパタの学習をやり出せば解る｡
デザパタはOOを十分理解してる事が前提で話を進めてるので｡

ラム · 01/11/18 09:59

ageるっちゃ。

**名無しさん＠お腹いっぱい。** · 01/11/18 10:48

>>276
違う、そういう意味じゃない。デザインパターンまで実務に使ってる。
キミの言ってることのつながりが全然わからないと言っている。

**名無しさん＠お腹いっぱい。** · 01/11/18 20:54

ゲ技版にもデザパタ馬鹿が出るのか・・・・。

**名無しさん＠お腹いっぱい。** · 01/11/18 21:18

別になあ、今更デザパタでもなかろうに。
つかっててあたりまえだといいたいんだろう？ >>279

**名無しさん＠お腹いっぱい。** · 01/11/18 22:29

Design Pattern for Computer Games
http://www.totempole.net/patterns/gamepatterns.html
こんな試みもあるがね。

**名無しさん＠お腹いっぱい。** · 01/11/19 22:42

とてもヨワヨワな質問でスマソ。
カードゲームを作ろうとしたときカード１枚１枚をクラスとして扱う？
カードの枚数だけクラスが出来るんかな…

**名無しさん＠お腹いっぱい。** · 01/11/19 23:38

>>282
MT:G 系のカードごとにルールがあるカードゲーム？
カードクラスとルールクラスで構成するか、それぞれをクラスにするかだね。
Prototype や Flyweight パターンを参照してみて。
↓だけじゃ分からないと思うけど、参考までに。
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/prototype.html
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/flyweight.html

**名無しさん＠お腹いっぱい。** · 01/11/20 00:08

さっそくのお答えありがとです。
Flyweight パターンが近そうなので
もうちょっと勉強してみます。

**名無しさん＠お腹いっぱい。** · 01/11/20 20:34

太閤立志伝Iは、オールアセンブラと思われる古いゲームだが
オブジェクト志向してたんじゃないだろうか。
基底クラス武将を継承するプレイヤー武将クラス、大名武将クラス、一般武将クラス。
それらのオブジェクトが家臣団ツリー構造で管理され、
マルチスレッド処理で並列で動いてる。
当時これをつくったひとは本当に天才だとおもう。
ずっと後に出た、これと似たシステムのガンパレードマーチはさんざん自慢しまくってたが。

**名無しさん＠お腹いっぱい。** · 01/11/20 21:25

大抵のゲームプログラマーはとっくの昔に自分でＯＯＰやデザパタ発見してるよ。
本に出てるのは他人に教えても良いゴミテクと知れや。

**名無しさん＠お腹いっぱい。** · 01/11/20 23:36

>>99

例えば、ゲームボーイとか、タイトなパフォーマンスが要求されるとことか、
まぁあったでしょうけど、やっぱ今後は開発効率の向上が必須項目。

例えば、全部組み込みJavaでゲームが書かれるようなことにも数年後にはなり
かねないしさ。

>101
モジュールやデータ構想の勉強っって何ですか？

**名無しさん＠お腹いっぱい。** · 01/11/20 23:43

タイトなパフォーマンスが要求されないゲームってＰＣぐらいしかないんじゃ？
アマですか＞287

**名無しさん＠お腹いっぱい。** · 01/11/21 07:35

>>286
こういうやつよくいるわ。

**名無しさん＠お腹いっぱい。** · 01/11/21 11:44

ま、とりあえず>>286がデザインパターンの存在意義を
理解してないのは分かるわねー。

**名無しさん＠お腹いっぱい。** · 01/11/21 12:33

個人的にはパフォーマンスよりも
開発効率のほうが今後のネックだと思うが。
納期に追われたこと無いの？>288

**名無しさん＠お腹いっぱい。** · 01/11/21 17:02

＋→描画デバイス
＋→シーン＋→キャラクタ→モーション
　　　　　＋→キャラクタ→モーション
なんて風にオブジェクトを階層構造にしてるとき
キャラクタの描画メッセージは、どいつがどのように送りますか？
それとも、こんな構造にはしませんか。

**名無しさん＠お腹いっぱい。** · 01/11/21 20:28

>>286
確かにデザパタ厨房は、
今は物理シミュレーションの時代だとか言ってるゲーハー厨並に痛いけど
（そんなのファミコン時代からやってるって…）

デザインパターン自体には、
昔からの手法に共通の名前を与えるという意義はあると思う。

**名無しさん＠お腹いっぱい。** · 01/11/21 20:52

>>271-272みたいな感じでんな。
プログラマ間の意思疎通がシャア並みに速くなる。