タスクシステム総合スレ part3

**名前は開発中のものです。** · 2008/11/09(日) 11:51:40

タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

**名前は開発中のものです。** · 2009/01/31(土) 15:49:35

>>846
そのContextとやらでポインタ使うことになるっしょ。
そこでスマートポインタ使うから安全って言うのかと思った。
そうでなければどういう意味で安全といったの？

std::list< Task<Enemyとか> *> m_bullets;

init(*jiki,*teki,*tama,*unko){ ←こことか、
　　m_bullets.push_back(new Task<Enemyとか>(jiki,teki,tama,unko)); ←ここで外部データへのポインタ使ってる。安全じゃない
}
enterFrame(){
　　foreach bullet (m_bullets) {
　　　　bullet.update();　←ここで渡すのを初期化時に移しただけ。状況はむしろ悪化してる
　　}
}

#template分かんねえｗｗｗ
#newまわり恐らく書き方違うだろうけど意図は大体通じるよね？

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

>>856
> そこでスマートポインタ使うから安全って言うのかと思った。
> そうでなければどういう意味で安全といったの？

すまんが、俺は「安全」という言葉は一言も言ってない。
「安全」と言ったのは俺じゃない。

俺は、オーバーヘッドがあるから、スマートポインタを使わなくて済むところでは
使わないし、この手のタスクをコントロールするのにスマートポインタは持ち出さない。
またオブジェクトが生きているかどうかの判定については >>855 で書いた。

ただ、
> Contextとやらでポインタ使うことになるっしょ。

については、このContextが保持しているstd::listなりstd::mapなりは、
Taskの解体の時に自動的にここから該当タスクのポインタをremoveするので
このstd::listなりstd::mapなりにあるオブジェクトが実在して、かつ生きている
ことだけは保証される。だから>>855 の方法で問題ない。

**名前は開発中のものです。** · 2009/01/31(土) 16:00:48

いま読み返してみたら、855の書き方が悪かったので以下補足＆修正とお詫び。

> Task chainに対して、
> tasks.isContain(jiki)
> のような判定が必要である。

だけど、tasksから一度removeされて、同じメモリがオブジェクトに割り当てられる
ことがあるので、このjikiというのは、オブジェクトのアドレスやポインタではなく
incremental ID(いわゆるhandle)だ。

誤解を生じさせる書き方をして済まない。

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

contextって俺は長命オブジェクトをイメージしてるんかと
思ったけど、違うの？
マネージャなりメディエータなり

よくある子に親への参照を持たせているようなケースは、
親が先に死なないデザインなら安全

オブジェクト間の相互参照グラフが無軌道に複雑化する場合は、
確かにGCなしでは酷いことになるだろうし
IDルックアップを毎回やるのは遅そうだな

**名前は開発中のものです。** · 2009/01/31(土) 16:21:35

>>852
その状態でなんで>>826,830-832の内容を否定するの？
俺が書いたのは>>831のみだけど
その状態をダメだって言ってるのが>>826,830-832の内容なわけ

ソースの記述で引数を明示的に表現しなければならないって話なのよ？
タスクシステム使うと完全に>>826,830-832の問題をどうにもできないでしょ？
ソースの記述で引数を明示的に表現できる？
（ま、別にする必要がないって主張をもってるからタスクシステム派なんだろうけどさｗ）

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

>>859
> contextって俺は長命オブジェクトをイメージしてるんかと
> 思ったけど、違うの？

もちろん、Contextオブジェクトの寿命はあらゆるTaskよりは
長いことは保証しなければならないし、保証されると仮定してプログラムする。

でもタスクフレームワークとして見たとき本質的なのはそこじゃなくて、
そのアプリ固有のcontextをTaskから切り離してTaskの呼び出しを抽象化するのに
ここをtemplate classにする必要があるということ。

> よくある子に親への参照を持たせているようなケースは、
> 親が先に死なないデザインなら安全

>>858 のようにhandleを持たせるのが嫌なら、boost::shared_ptrを用いて
　std::list<boost::shared_ptr> tasks;
としておくというのは一理あるんだな…でも、

> オブジェクト間の相互参照グラフが無軌道に複雑化する場合は、

循環参照するようなケースはshared_ptrではどうにもならないし
GCがある言語で書いたほうがスマートではあるな。

> IDルックアップを毎回やるのは遅そうだな

実際はオブジェクト数の上限は決まっていると仮定して良くて、
hash tableを使って実装するので、その部分は実はそんなに遅くはないよ。

たいていはhash値を計算してメモリを一度lookupするだけで済むので。
だから、ID lookupで実装するのがスマートだと思うな。

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

>>860
> ソースの記述で引数を明示的に表現しなければならないって話なのよ？

何故そんな必要があるのか、そのメリットがどこにあるのか俺には全く理解不能だ。

**名前は開発中のものです。** · 2009/01/31(土) 16:38:26

なんとなく論点のズレが分かった

ID:rIovvj90
は、タスクマネージャからのupdate()呼び出し
以外の関数呼び出しは一切存在しない（あらゆるオブジェクト間の相互作用を
それで解決する）プログラムを仮定しているように見える

他の人は（ID:9d5EHsE6）は、誰もそのようなものは仮定していない

普通に引数を使うところでは勿論使うわけで、
あくまでジェネリックなupdate()を書く時の作法として
どっちが適切かという話をしていただけでしょ

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

>>863
正解。

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

>>863
違うってなんで曲解するんだ？
update関数の中でアクセスするインスタンスがソースの記述から
わからないのがダメだって言ってるんだ（もちろんダメだと思わなければそれまでだがｗ）

>>826,830-832で言ってることがすべてだって
これがわからないって経験値が低いぜ
わかってやってるってのも俺的にはちょっと考えにくいんだけどね

**名前は開発中のものです。** · 2009/01/31(土) 16:46:49

>>865
> update関数の中でアクセスするインスタンスがソースの記述から
> わからない

？？？
C++だからthisポインタ越しに、オブジェクト参照をたどるだけでしょ
参照はメンバ変数に持っているのだし

何が「わからない」のかが分からない

**名前は開発中のものです。** · 2009/01/31(土) 16:49:34

>>865
> update関数の中でアクセスするインスタンスがソースの記述から
> わからないのがダメだって言ってるんだ

何度でも言うが、そんなものはわかる必要がないんだ。

Javaのupdate(Graphics g)メソッドひとつにしても
updateメソッドのなかでGraphics以外のオブジェクトにアクセス
することは当然あるし、それを禁じる方法はないし、
update(Graphics g)というシグネチャを見てGraphicsにしかアクセス
しないと判断することは出来ないし、
実際そんなコーディングスタイルで書く必要もないし、
そんなコーディングスタイルを強要されるとまともにプログラムを書けない。

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

すべてのタスクファイルのヘッダをincludeして
それが普通だと思っているID:rIovvj90みたいなド素人と
話していても時間の無駄なので俺は、ID:8CtHI7i5と勝手に話を続ける。

**名前は開発中のものです。** · 2009/01/31(土) 16:52:32

■　ID lookupの周辺。

typedef TaskHandle unsigned int;
struct HashEntry
{
TaskHandle handle;
Task* task_ptr;
};

typedef HashTable HashEntry[max_of_hash_entry];

Taskクラスのコンストラクタでは、TaskHandleとしてincremental IDを付与して
HashTableに登録するコードを書く。Taskクラスのデストラクタでは、HashTable
からremoveするコードを書く。

TaskHandleから具体的な型に変換するのは
template<class TaskClass>
TaskClass* TaskHandleToPtr(TaskHandle h)
{
Task* p = HashTableからhのTaskを取得();
if (typeid(p)!=typeid(TaskClassのインスタンス))
return null;
return (TaskClass*)p; // このcastは安全
}

こうなるな。

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

>>869 の続き。

TaskHandle enemy1;
TaskHandle enemy2;

に対して

EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
EnemyTask* enemyTask2 = TashHandleToPtr<EnemyTask>(enemy2);
if (enemyTask1!=null && enemyTask2!=null)
{
　// これらのタスクは生存している
　update_something(enemyTask1,enemyTask2);
}

という生存チェックが必要になるな。仕方ないと言えば仕方ないが、
使う前に必ず必要なのがちょっとうざい気はする。

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

>>869
まあ概ね想定どおりっすね
俺の考えを言うと、

・C/C++なら、そもそもオブジェクトの相互参照グラフを整理する
　のがベスト

・問題が不可避な場合にはGC, スマポ, ID管理などの解決方法があるが、
　スマポは良く知られているように巡回参照には無力（そもそもグラフが
　複雑化したから欲しくなったはずなのだから、それでは意味が無い）
　
　ID管理が一番シンプルでポータブル、仮に全てが利用できると
　仮定した場合、性能や特失に関しては研究の余地あり（ただ、ゲームでは
　いずれにせよGCは利用しにくいでしょうね）

ってとこかしら

**名前は開発中のものです。** · 2009/01/31(土) 17:00:55

>>871
>（ただ、ゲームではいずれにせよGCは利用しにくいでしょうね）

これは何故？俺は、C#で商用ゲームプログラムを書いたけど
別にGCがあるので困るということはなかったのだが。

どんなことが問題だと思ってるの？

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

>>872
優秀な世代別GCで、決してワールドがストップしないと
確信できるケースでは、問題ないかもしれません
その確信が持てないなら、ゲームでは難しいかもしれません

ということです

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

>>873
> 優秀な世代別GCで、決してワールドがストップしないと
> 確信できるケースでは、問題ないかもしれません

それが確信できないとそもそもXNAでプログラミングなんて出来ないわけで…。

あ、もちろん、大きなリソースを解放するときは要注意なのでそのタイミングは
なるべくコントロールしてやる必要があるけども。それはC++でも一緒なわけで…。

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

>>870 の続き。

結局、TaskHandleという汎用型があまりよくない気がするな。

TaskHandle<T>にして、operator T*() を用意して暗黙で変換できる
ようにしたほうがいいかもね。

これなら

TaskHandle<Enemy> enemy1;
TaskHandle<Enemy> enemy2;

に対して

try {
// これらのタスクが生存していなければ暗黙の変換のときに例外が飛ぶ
update_something(enemyTask1,enemyTask2);
// update_somethingのシグネチャは、update_something(Enemy*,Enemy*)
} catch {}

とか。こっちのほうが少しシンプルかも。これは、どう？ > ID:8CtHI7i5

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

>>874
いやその、「C#でゲームプログラミングは不可能である」という主張ではないので
誤解無きよう
そういう意味では、「GCはゲームではありえない」と読み取れるので、
強い主張すぎたかな、訂正します

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

>>876
いやまあ、C#で弾幕シューティング作ったら、やっぱり
GCが変なタイミングで動いてときどきカクカクなるから
object poolingするコードをtemplateで書きまくったとか
そういうことは日常茶飯事なので、GCに対して世間の目が
冷たいのはよくわかってるつもり。

このスレの趣旨に見合う形で話を戻すと、GCつきのほうが
タスクのinteractionは楽に書けることは書けるけども、
それでもC++でも >>875 のように書けるなら、さほど手間は
変わらないと思う。

**名前は開発中のものです。** · 2009/01/31(土) 17:16:15

>>866
それは別クラスのポインタの保持をするってこと？
まあ、ようは関数読んだときにアクセスしてるクラスがわからないようなのはダメってことよ
当然そういうメンバに別クラスのインスタンスのポインタを保持させるようなのも禁止だよ

>>867
それができるんだよ
グローバル変数・関数の使用禁止（当然スタティックとかも禁止）とか徹底して
メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
後、可能性があるのは引数とメンバ変数ぐらいだろ？
こうするとバグが比較にならないほど減るぞ

自分で一度この方式でプログラム組んでみてほしいね
決して面倒臭くない
むしろ開発が進むにつれこっちのが作りやすいとわかるはず

しかも読む人間もソースを追いやすいからバグの発見も早い

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

>>878
> メンバに別クラスのインスタンスの保持禁止にするのをちゃんと徹底すれば
> 後、可能性があるのは引数とメンバ変数ぐらいだろ？

別クラスのインスタンスの保持をすると何故いけないと思うんだ？

親オブジェクトが子オブジェクトのstd::listなんかを持っているのは普通であり、
当たり前だろ？これを禁止するなら、どのオブジェクトがある親オブジェクトに
対する子オブジェクトを持っていると言うんだ？具体的にソース書いて見せてくれ。

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

>>857
了解しました。スマートポインタは無かったことに。
あと「メモリ上のオブジェクト寿命の保証」が対策済みで問題ないのは了解しました。

それはそれとしてゲームオブジェクト間の「データ確定性の保証」
もしくはオブジェクト間関係の見える化の推進度合いの観点では
依然として「引数を明示的に表現する」ほうがupdate(void)よりも分かりやすい
と考えてるんですが、その点どうお考えですか？
update(void)メソッド呼び出しの中で他のupdateを呼び出す場合に
update(jiki,teki,tama,unko);と書くこと自体はその是非はともかく存在は想定されてますよね。

以下のように
Scene::update(void);
Player::update(void);
Enemy::update(void);
Bullet::update(void);
と全てをタスク化するのではなく、タスクの数はもっと減らして

Scene::update(void) { ←タスクはこいつだけ
　　player.update(jiki,teki,tama,unko);
　　enemy.update(jiki,teki,tama,unko);
　　bullet.update(jiki,teki,tama,unko);
}
としてやればだれがいつjiki, teki等を使っているのかが見やすくなる。
また、playerはTaskを継承しなくて良くなるのでPlayerクラスだけを抜き出して
test_player_class.cppとかいうコードを作ってPC上でクラスの単体テストすることもかなりやりやすくなる。
思うにTask導入しちゃうとタスクフレームワーク使わなければ単体テストすら満足にできなくなってるんじゃないかと。

update(void)を自動的に定期的に呼び出すのは要らないと言っているのではなく、
それを使った上でさらにそのメソッド内でupdate(jiki,teki,tama,unko)を導入することの利点について考えたこと有りますか？
きちんと比較したことありますか？という辺り

**名前は開発中のものです。** · 2009/01/31(土) 17:27:48

>>878
ひょっとして
> メンバに別クラスのインスタンスの保持禁止にする

の「インスタンス」には「std::list<EnemyTask*>」のようなものは
含まれないのか？これも立派な「インスタンス」だと思うんだが。

何かコンピュータ用語以前に、ID:rIovvj90は日本語が不自由で
何が言いたいのかよくわからない。

そもそも俺にしても >>875 のようなスタイルで書いているわけで
別のTaskのインスタンスなど(compositionでの)保持はしない。

しかしHandleは保持する。それは、参照するのに必要だからである。

**名前は開発中のものです。** · 2009/01/31(土) 17:39:37

>>880
あなたの想定しているように、ゲーム画面ではプレイヤと弾と敵が
存在するが、タイトル画面ではそんなものは存在しないという場合、
タイトル画面を構築に不要なものを排除して、タスク間のinteractionを
なるべく簡素で見える形にしたいという動機は当然ありえる。

それでも
> Scene::update(void) {
>　　player.update(jiki,teki,tama,unko);
>　　enemy.update(jiki,teki,tama,unko);
>　　bullet.update(jiki,teki,tama,unko);
>}
は良くない。この書き方はド素人くさい。

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

>>882
>は良くない。この書き方はド素人くさい。
良くない理由はなんで？

**名前は開発中のものです。** · 2009/01/31(土) 17:41:49

>>882
そう、結局そこに帰結する。
>この書き方はド素人くさい。

この１点の是非

**名前は開発中のものです。** · 2009/01/31(土) 17:43:39

メンバもグローバルも駄目なら、
update(jiki,teki,tama,unko)を呼ぶ側のクラスは
jiki,teki,tama,unkoをどこに持ってるんだ？
main関数のローカルに持って、延々と渡していくのか？

まあ、そんなことより、
ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。
新しいContextを追加すると、Taskのリストがひとつ増えるんだよね？
そのリストは誰がどういうふうに持つの？

**名前は開発中のものです。** · 2009/01/31(土) 17:48:59

>>882 そういう動機なら

class SceneXXXContext
{
GameGlobalContext* globalContext;
Jiki jiki;
Teki teki;
Tama tama;
Unko unko;
}
こう書いて、

public SceneXXX<GameGlobalContext> : public Task<GameGlobalContext>
{
virtual void update(const GameGlobalContext& globalContext)
{
this->grobalContext = globalContext;
my_task.update(this.context);
}
TaskList<SceneXXXContext> my_task;
SceneXXXContext context;
};
こう書くべきだろう。

**名前は開発中のものです。** · 2009/01/31(土) 17:49:22

>>886 の続き。さらに抽象化して、

template <class GlobalContext,class SceneContext>
public Scene : public Task<GameGlobalContext>
{
virtual void update(const GameGlobalContext& globalContext)
{
this->grobalContext = globalContext;
my_task.update(this.context);
}
TaskList<SceneContext> my_task;
SceneContext context;
}

こうとか。

ID:rIovvj90,ID:8N26Dxd2 の設計と上の設計との大きな違いは、このクラスが
使い回せるし、他の具体的などのTaskクラスにも依存していないということだ。

**名前は開発中のものです。** · 2009/01/31(土) 17:51:28

>>885
> ID:9d5EHsE6のタスク周りの実装をもう少し聞きたいな。
> 新しいContextを追加すると、Taskのリストがひとつ増えるんだよね？

増えない。Contextはタスク階層ごとに必要となるだけ。cf. >>886

**名前は開発中のものです。** · 2009/01/31(土) 17:56:00

>>880
> オブジェクト間関係の見える化の推進度合い

詳細を「隠したい」場合と「見たい」場合があるはずなので、
その場合はどっちですか、という話になるだけでは。
ネジ一本のツクリまで気にしなければ運転できないような車は設計の欠陥で、
「見える」ことが常に良いことである、という発想は誤りです。
OOPのカプセル化やポリモーフィズムの意味を理解してください。

>>885
直接のインスタンス参照ではなく、事実上参照代わりに使えるハンドル(ID)を
持っていると書いてあったと思うけど。
勿論それは寿命が微妙な短命オブジェクトの話で、
寿命管理が明確な長命オブジェクトは直接参照でしょう。

**名前は開発中のものです。** · 2009/01/31(土) 17:58:00

>>889
ネジ一本のツクリまで気にして設計してある車でなければ運転したくないです。
運転手の話したいの？
設計者の話でしょ？

**名前は開発中のものです。** · 2009/01/31(土) 18:00:52

>>890
クラスAを作るとき、クラスAを利用する人間は、クラスAのユーザになる。
どちらも同じ人間かもしれないが、クラスはユーザに対しては詳細を
隠蔽するように働き、汚い泥仕事はその中に閉じ込め、問題の局所性を
高める。
本当にネジを気にしなければならないコードを局所化するわけだ。

OOPどころか、構造化プログラミングの基本中の基本ですので、
一から勉強しなおして下さい。

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

>>891
> 問題の局所性を高める。

そのためには、あるオブジェクトが実装のために利用するオブジェクトの
種類について >>882 のように制約をかけたいという欲求はあるのでは。

だからこそ俺は、template <class Context>とContextを用いて、
こいつにしかupdateメソッドのなかではアクセスしないという制約
のかけ方を示し >>886 、さらにそれを抽象化して >>887 、
何故、update(jiki,teki,tama,unko);と書くのが良くないのかに答えた。

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

意味論的にupdate()をどう捉えるかでしょう

update()の抽象的意味が、「VSYNCを通知する」ということであれば
（というか多分そうだと思うのですが）
jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係な
代物、ということになります。

引数jiki, teki, tama, unkoを取るupdate()の「意味」は何でしょうか？

**名前は開発中のものです。** · 2009/01/31(土) 18:22:23

>>888
Task<GameGlobalContext> のリストは TaskList<GameGlobalContext> で、
Task<SceneXXXContext> のリストは TaskList<SceneXXXContext> なわけでしょ？
Contextが増えたらTaskListが増えてるじゃん。
Contextの種類数＝リストの種類数ってことなんじゃないの？

**名前は開発中のものです。** · 2009/01/31(土) 18:25:58

>>893
> update()の抽象的意味が、「VSYNCを通知する」ということであれば
> jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係

ああ、それは正しいね。通知するだけなら、引数は必要ないね。

ただ、世の中のイベントハンドラがすべてそうであるように、
そのハンドラのなかで使いたいであろうもの(マウスイベントならばマウスの状態、
キーボードイベントなら押されたキーの情報)を引数として渡すのは常識的なことなので
今回のケースも、updateなら何らかのContext(それは描画のためのものであったり、
そのSceneで使うものであったり)が付随していてもそれはおかしくはないと思うけど。

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

>>895
ええ、そうですね
Cならば、コールバックの第一引数として、いずれにせよthisポインタ代わりのもの
を使うのが普通ですし

ところで、違う目的のものに同じ"Context"という用語を用いているのは
混乱の元のように見えます

引数渡しをする場合には、テンポラリな情報のジェネリックラッパーを仮定していて
依存性をオブジェクト生成時に注入している場合には、長命オブジェクトへの
参照を仮定しているのではありませんか？

**名前は開発中のものです。** · 2009/01/31(土) 18:46:16

>>885
メンバはダメじゃないだろ
ただ、別クラスのインスタンスのポインタの保持が禁止なだけ
それとupdateの例ではなにやらゲームのオブジェクトのクラスに
同じゲームオブジェクトのjiki,teki,tama,unkoを突っ込んでるようなソースに
なってしまっているがこれも間違いでありえない
仮にシーンクラスなんてのがあったらそこのメンバとして
jiki,teki,tama,unkoをもつ

ちなみに俺が最初に書いたソースのupdateはゲームオブジェクトの更新処理のつもりの
updateだったが引数でゲームオブジェクトを入れてるのは間違い
必要な情報だけ入れる
まあ、この場で話す分にはあんまり気にしなくておｋ

**名前は開発中のものです。** · 2009/01/31(土) 18:46:59

>>894
俺は、>>888 では >>885 の
「新しいContextを追加すると、Taskのリストがひとつ増えるんだよね？」
の「リスト」を何故かstd::listのようなものではなく、表のようなものを
指しているのかと勘違いしてトンチンカンなことを書いてしまった。

これについては、謹んでお詫びしたい。
なるべくならこういうときは「std::listのようなもの」と書いてもらえるとありがたい。

ただ、

> Contextが増えたらTaskListが増えてるじゃん。

Contextに対応したTaskListが必要とは限らない。

class TitleSceneContext : GlobalContext {};
class GameSceneContext : GlobalContext {};
class PlayerSelectSceneContext : GlobalContext {};

このように(あとで拡張できるように各Sceneに対応するContextのclass
だけ生成しておいて)、実際は

TaskList<GlobalContext> taskList;

こう書くかも知れない。こう書くメリットは、TaskListの種類を減らして
生成されるコードを縮めることにある。

**名前は開発中のものです。** · 2009/01/31(土) 18:58:37

>>896
> ところで、違う目的のものに同じ"Context"という用語を用いているのは
> 混乱の元のように見えます

どれとどれが違う目的？
また、どう呼ぶべきだと思う？

ここで言うContextはtemplate class名なのでtemplate <class T>のTみたいなもので
それほど厳密な意味や名前は必要ないと思うのだけど。
(あったほうが理解したり、読みやすかったりするんだろうけど)

また、updateメソッドはContextとメンバ変数の状態のみによって、
次のContextの状態を作り出すことが出来るので、DFAと見なせる。

だもんで、CFTG(context-free tree grammar)とかの "context" という用語を
ここに持ってくるのはおかしくないと思ったんだけどな。

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

>>886
の
> >>882 そういう動機なら
って番号ずれてる？
>>884 以降流れについていけてない俺に愛の手を

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

>>900
番号はずれてない。
>>886 の「そういう動機」の「そう」が指すのは、 >>882 の　「あなた」から「したいという」まで。

わかりにくくてすまん。

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

>>898
その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。
呼ぶ側がどのContextを渡すかはどうやって判断するの？

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

俺、実は主婦なので、いまから買い物にいかなきゃならん。

そんなわけで、明日まで、返答できない。

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

半額セールがはじまる時間なんだ…。

>>902
> その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。

この場合は、しない。

place holder的に、Contextの派生型だけ宣言しておく( >>898 )という使い方がありうると言いたかっただけ。
902を混乱させたようで悪かった。些末な問題なので、忘れてもらって構わない。

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

>>899
> (あったほうが理解したり、読みやすかったりするんだろうけど)
無論、議論の参加者にとってはそのほうが良いわけですから、
その点の指摘に過ぎませんよ。

> また、updateメソッドはContextとメンバ変数の状態のみによって、
> 次のContextの状態を作り出すことが出来るので、DFAと見なせる。

updateメソッドの引数としてのcontextという名前が非常に典型的であるのは
その通り（特にその中身がopaqueで、その意味内容をその場で論じたくない場合）
ですが、一方クラスメンバの名前としては、「context」は適切で意味が
明快な名前であるとは言いがたいでしょう。

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

タスクシステム信者いたんだ？ｗ
なんかタスクシステムがヤバクなるとスレを流しにかかるよねｗ
>>826,>>830-832からの一連のレスは面白いから次のスレにも貼ろうｗ

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

>>901
Thanks!
なぜド素人くさいと言ったか分かった。あなたはSceneについてのみ話している。
私はゲームオブジェクトについてのみ話している。そこがまず違う。

まずupdate()という名前のメソッド群があったらそれらを抽象化してまとめて扱いたくなるのは当然。
でもupdate()に引数付けただけの段階ではまだ途中なんだよ。その次の段階に進むことでうまみが出る。
次の段階というのはupdate()を複数のメソッドに分割できるようになること。
つまり
　update(jiki, teki, tama, unko);
は下のように分割できる。
　Jiki::hit_check();
　Jiki::set_hp();
　Jiki::get_hp();
　Teki::get_hit_area();
　Teki::get_attack_point();
　Tama::get_hit_area();
　Tama::get_attack_point();
　...
それらをこうやって使う。
　foreach t (teki) {
　　　if (jiki.hit_check(t.get_hit_area())) {
　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　　}
　}
（続く）

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

（続き）
最後にSceneと統合すると
　SceneXXX::update(void) { ←タスクはシーンだけ
　　　foreach t (teki) {
　　　　　if (jiki.hit_check(t.get_hit_area())) {
　　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　　　　}
　　　}
　　　foreach t (teki_tama) {
　　　　　if (jiki.hit_check(t.get_hit_area())) {
　　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　　　　}
　　　}
　　　...
　}
こうなる。
Scene::update(void) は >>886 >>887 みたいなやり方で実装するのはアリ。
というかむしろそうしないと確かに「ド素人くさい」。ただそれはSceneにおいての話。

ゲームオブジェクトはSceneとは別枠で扱うべき。つまりゲームオブジェクトはタスクにすべきでない。
理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
タスクでは引数渡しができないのが嫌。

私がupdate()で引数扱えるようにした方がいいって思ってるのはゲームオブジェクトについての話。
ただ、update()という名前で引数を扱うのはタスクシステムを脱出する過程で現れる過渡的、一時的な姿。
複数のメソッドに分割された後はupdate()なんて名前は消えてなくなる（たまたま別の意味付けで残ることはありえるけど）。

Sceneはタスクで良いのでupdate(void)で構わないが、
ゲームオブジェクトはタスクにすべきではないので（過渡的な姿という意味で）update(jiki,teki,tama,unko); が良い。

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

買い物から戻ってきた。

>>905
> ですが、一方クラスメンバの名前としては、「context」は適切で意味が
> 明快な名前であるとは言いがたいでしょう。

俺の書いた、>>886では、そのメンバ変数の宣言は、
　SceneXXXContext context;
となっているけど、
A) SceneXXXContextのメンバ名がcontextとなっているのが適切ではない
と言いたいのか、
B) SceneXXXContextという名前が十分わかりやすいものではない
と言いたいのか、どちら？

俺としては、SceneXXXContextの変数名がcontextなのは、
大きなクラスでない限りはそれくらいの省略は許されるべきだと
思うんだが。また、SceneXXXContextは、SceneXXXを構築するのに必要な
文脈という意味で、意味明瞭だと思うのだが。

**名前は開発中のものです。** · 2009/01/31(土) 21:46:18

>>909
ああ、申し訳ないっす。後のほうの話を念頭に置いてなかった。
そっち見りゃ、少なくとも「なんのつもりか」は分かるでしょうね。

**名前は開発中のものです。** · 2009/01/31(土) 21:51:42

>>910
了解

**名前は開発中のものです。** · 2009/01/31(土) 21:54:52

>907-909
> 理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
> タスクでは引数渡しができないのが嫌。

タスクでは引数渡しがなんで出来ないの？

template <class Context>
void update(const Context& context);

このcontextって引数渡しでない？
それとも、これはいわゆるタスクではないの？

「オブジェクト間の通信」って何がしたいのかよくわかんないのだけど、
Handle経由で参照すれば(>>875)いいじゃん。

どうせ、ゲームオブジェクトにしてもそのオブジェクトの
生存の確認は必要なんだろうし、>>875 のコードと何ら変わらないんじゃ？

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

>>912
実質グローバル変数渡ししかできないから。

foreach t (teki) {
　　if (jiki.hit_check(t.get_hit_area())) {
　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　}
}
これならそもそも生存してるやつ同士しか参照が発生しないから生存確認必要ないかと

**名前は開発中のものです。** · 2009/01/31(土) 22:24:13

>>912
明示的なって意味じゃねぇの？
だいたいそんな十把一絡な引数あってもしょうがねぇし

引数はソースコードに明示的にわかるようなものでないと俺は意味がないと思ってる
グローバルにしてテキトーに渡したほうが速いじゃん

**名前は開発中のものです。** · 2009/01/31(土) 22:34:27

>>913
> 実質グローバル変数渡ししかできないから。

何故、そう思ったのかは知らないが、俺の書いたソース( >>869-870,875 )では
グローバル変数なんか経由していないし使ってもいないし、使うつもりもないのだが。

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

そもそも>>908の「ゲームオブジェクト」が何を指すのかがわからない。
「タスク」とどう違うのか。

そもそも、俺の「タスク」(>>846)とは「タスク」そのものが違うような気がする。

**名前は開発中のものです。** · 2009/01/31(土) 22:37:59

>>914
> 明示的なって意味じゃねぇの？
> だいたいそんな十把一絡な引数あってもしょうがねぇし

templateは実体化して使うだから
compile-timeには型が確定するし十分明示的じゃん。

templateが「十把一絡な引数」だと思うなら、お前はstd名前空間使用禁止な！

> グローバルにしてテキトーに渡したほうが速いじゃん

グローバル変数なんか使わないっちゅーの。
本当、ID:rIovvj90は、タスクシステム以前にプログラミング自体、ド素人なんだな。

**名前は開発中のものです。** · 2009/01/31(土) 22:41:36

そもそもまずいのはグローバル変数・関数じゃなくて
グローバル・スタティックの変数・関数、別クラスのインスタンスのポインタの保持、
シングルトン、アドレスジャンプ等を使用することによって
明示的な関連が全く見えなくなることだけどね

別にそこにこだわってないならいいんじゃないの？
どう組んでもｗ

**名前は開発中のものです。** · 2009/01/31(土) 22:44:58

>>915

> EnemyTask* enemyTask1 = TashHandleToPtr<EnemyTask>(enemy1);
これが実質グローバル変数。
これがダメ。
これをやめるべき。
これがグローバル変数とほぼ等価だと認識できないの？

俺の「ゲームオブジェクト」は
「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理において言えば
「自機」と「敵機」がそれぞれゲームオブジェクト。

俺の「タスク」は
class Task {
public:
　virtual void update(void)=0;
}
的なやつを実装したもの。update(Context？)=0;でもいいけど。

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

>>918
>> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
> これが実質グローバル変数。
> これがグローバル変数とほぼ等価だと認識できないの？

出来ないね。
それがグローバル変数に見えるならあんたの目が腐ってるとしか言いようがない。

ID:rIovvj90 と ID:8N26Dxd2 はいつも時間的に連続して出てきて、
二人とも極端にレベルの低いド素人プログラマなんだが、これは
同一人物なのか？

それとも、こんなド素人が二人も都合良くこのスレに出没してるのか？

**名前は開発中のものです。** · 2009/01/31(土) 23:37:25

>>918
>「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理に
> おいて言えば「自機」と「敵機」がそれぞれゲームオブジェクト。

タスクとの違いがわからない。

> 俺の「タスク」は
> class Task {
> public:
>　virtual void update(void)=0;
> }
> 的なやつを実装したもの。update(Context？)=0;でもいいけど。

「ゲームオブジェクト」とやらも、そのTask派生クラスでいいじゃん。
何がまずいの？

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

>>919
違うっつの
しかも、グローバル変数が問題じゃなくて
明示的な関連（アクセスかな？）が見えないのがまずいって言ってるだろ
関数の実行に必要なもんをソースみてわかるようにしろ
簡単だろ？
何もむずかしいこといってやしねぇだろ？

**名前は開発中のものです。** · 2009/01/31(土) 23:59:28

>>921の書き込みが　ID:rIovvj90　でされているんだが、ID:8N26Dxd2　のほうでログインしなくて
良かったのかい？

まあ、それはいいとして、ひょっとしたら、ID:8N26Dxd2 は、

static std::map<TaskHandle,Task*> taskHandleToPtr;
static Task* TaskHandleToPtr(TaskHandle h)
{
return taskHandleToPtr[h];
}

こういうソースを想定して、taskHandleToPtrがglobal変数で
この変数を経由してTaskHandleとTask*が結びついているから
enemy1がglobal変数だと主張しているのかも知れないが、
よほどのド素人でもない限り、上のような馬鹿なソースは書かない。

実際は、
> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
このように実装できるように書くなら、Task基底クラスに
TaskHandleToPtrメソッドを持たせてTask派生クラスの初期化のときに、
HashTable (>>869) のポインタを渡す。

だから「実質グローバル変数」ではない。

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

>>921
> 関数の実行に必要なもんをソースみてわかるようにしろ

についてだが、

> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);

の「関数の実行(コンパイル?)に必要なもん」は、EnemyTask*で、
これはEnemyTaskクラスの定義してあるheaderが必要だ。

これは「みてわかる」と思うんだが、何をそんなに問題にしているのか
それがわからない。

**名前は開発中のものです。** · 2009/02/01(日) 00:13:31

いま気になったので、ID:rIovvj90 と ID:8N26Dxd2 の書き込みを
全部読み返したのだが、この二人(一人？)は極端に日本語が不自由だな。

この二人は専門用語の使い方もかなり間違いだらけで、
何が言いたいのか理解に苦しむ。

本当にこれで社会人なのか…。

というのはさておき、わかってないのはこの二人(一人？)だけみたいなので
IDも変わったことだし、俺はもう寝る。

**名前は開発中のものです。** · 2009/02/01(日) 00:23:24

>>924
文体が全然違うのに病気だろそれはｗ
ちなみに俺はID:rIovvj90ね

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

君たち、タスクシステムの話をしなさい。
素人だとかプロだとか、技術と関係ない感想は取り除いて話しなさい。

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

ID:8N26Dxd2 です

>>919
グローバル変数の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ

「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の嫌なとこは
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できないことでしょ

俺には両者はほぼ等価でどちらも忌むべきものにしか思えないが
もし「グローバル変数」と呼称するのが受け付けられないだけなら呼び方はどうでもいいけど
技術者として設計に不吉なにおいを感じないか？

>同一人物なのか？
違うっつの

>>920
>タスクとの違いがわからない。
object: 物体, もの, 実物; 対象
task: コンピュータが処理する仕事の最小単位
*goo辞書より

>何がまずいの？
タスク間の通信は実質グローバル変数渡しでしかできないのにゲームオブジェクト間は通信たくさん必要でミスマッチなとこがまずい

#話全く関係ないけどgoogleびびったｗ

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

>>919
> 同一人物なのか？
人を陥れるために真似る奴もいるぜ
あまり単純に考えない方がいい

つか>826にあるコードの断片だけを見て
どっちがいいか判断できるなんてエスパーとしか思えん。

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

>>826
引数でどうしても縛りたいならupdate()のなかでupdate(jiki,teki,tama,unko)呼べば解決じゃねーのか。
何が問題になるんだ。

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

>>830
本題とは関係ないかもしれないが、
JavaのCanvas#paint(Graphics g)で、
g以外に何にもアクセスしないで何を描画するつもりなんだ?

Canvasインスタンスが持ってる他のオブジェクトへのリファレンスを経由して
他のオブジェクトにアクセスするからpaint(g)でうまくいくのであって、
決してgにしかアクセスしないわけじゃない。
826の下がいいと言うなら、
paint(Graphics g)だとCanvasが何をpaintするかわからないので、paintメソッドは
paint(Graphics g, jiki, teki, tama, unko)にしなければいけなくなる。

だからpaint(g)を例に出すのは間違ってる。

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

>>927
> 「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の
> 嫌なとこはプログラムのどこかで変数の内容が変更される可能性があるのに
> それが把握できないことでしょ

std::list<Task*> tasks;
に対してforeachでupdateを呼び出していくだけで、
この呼び出し側しかtasksにはさわれないのに、
何故「ポインタを全タスクにばらまいて」いることになって、
「どこからでも全データ参照できる」んだ？

各Taskは、このtasksはいじれないんだぜ？
根本的に何か勘違いしてないか？

> タスク間の通信は実質グローバル変数渡しでしかできないのに

何度でも言うが、俺のソース(>>875)はグローバル変数を経由している
わけでもなく、グローバル変数を使っているわけでもなく、大きなオーバーヘッドも
なく、他のタスクオブジェクトのメソッドを呼び出せているが？

>>875 の書き方が気にいらなければ、
　std::list<boost::shared_ptr<Task> > task;
というタスクリストに対して
boost::weak_ptr<Enemy> enemy;
こうなってると考えてもらっても良いが。

いずれにせよ、グローバル変数は使ってないし、
「どこからでも全データ参照できる機構」もないし、大きなオーバーヘッドもないが？

**929** · 2009/02/01(日) 02:06:31

省略しすぎた

> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
上のやつで引数はとってくるって意味ね４つだから

Jiki* jiki = TaskHandleToPtr<Jiki>(jiki1);
Teki* teki = TaskHandleToPtr<Teki>(teki1);
Tama* tama = TaskHandleToPtr<Tama>(tama1);
Unko* unko = TaskHandleToPtr<Unko>(unko1);

this->update(jiki,teki,tama,unko);

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

>>922
俺が実質グローバル変数と言う判断基準は

「グローバル変数そのものではなくとも、
　グローバル変数のように動き、グローバル変数のように扱えるのならそれはグローバル変数だ」

これ。
だから実装方法はとくに想定していないし、する必要も無い。

まぁグローバル変数という呼び方がだめならその呼び方はやめるよ。
問題点は
>初期化のときに、HashTable (>>869) のポインタを渡す。
こんな感じでポインタをプログラム中にばらまくと
プログラムのどこかで変数の内容が変更される可能性があるのにそれが把握できなくなること。
「メモリ上のオブジェクト寿命の保証」は対策できてるから問題ないとして、
「データ確定性の保証」の観点から見た場合はどうなの？ってこと。

もしかしたら
>>886
の
> Jiki jiki;
> Teki teki;
> Tama tama;
> Unko unko;
を扱う記述例はどんな感じになる？　と聞いた方が手っ取り早いのかもしれないが

>>924
>極端に日本語が不自由だな。
うん

ねもいにょ。俺ももう寝るにょ

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

>>932
俺、ID:9d5EHsE6で、その>>826 に反論してた側の立場なんだけど、
その>>932に対する返答らしきものが、>>907-908 にあるのだが、
これの意味が俺にはさっぱりわからない。

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

>>934
俺にもさっぱりです。

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

>>933
>> Jiki jiki;
>> Teki teki;
>> Tama tama;
>> Unko unko;
> を扱う記述例はどんな感じになる？　と聞いた方が手っ取り早いのかもしれないが

class SceneTask : protected Task
{
protected:
Jiki jiki;
　Teki teki;
　Tama tama;
　Unko unko;

public:
SceneTask();
virtual ~SceneTask();

　virtual void update();
};

何かこれで不満でも？

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

>>933
936の補足。

Jiki,Teki,Tama,UnkoがTask派生クラスとは限らないなら、そのへんはケースバイケース。

場合によっては>>886 のように書いたりもする。

Jiki,Teki,Tama,UnkoがTask派生クラスであるなら、
boost::weak_ptrを用いるか、TaskHandle(>>869) を用いるか、>>886 のようにContextに持たせるか。

方法はいろいろある。

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

>>929 >>932
それ良いと思う。

>>934
　>>908 の
>Sceneはタスクで良いのでupdate(void)で構わないが、
>ゲームオブジェクトはタスクにすべきではないので（過渡的な姿という意味で）update(jiki,teki,tama,unko); が良い。
は、つまり、
>>929 >>932
と同じようなこと言ってる。
急いで付け加えるとあくまで過渡的な姿に限定して言えばの話なので、その後

update(jiki,teki,tama,unko);

は

> 　　　foreach t (teki) {
> 　　　　　if (jiki.hit_check(t.get_hit_area())) {
> 　　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
> 　　　　　}
> 　　　}
> 　　　foreach t (teki_tama) {
> 　　　　　if (jiki.hit_check(t.get_hit_area())) {
> 　　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
> 　　　　　}
> 　　　}
> 　　　...

みたいに変化すべきと思うけども

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

意味というか、論点がわかんねぇ……

>>938
その引用部分は、何のつもりだかはある程度は想像はつくが、
update(jiki, teki, tama, unko)
はどこでも呼んでいない
「update(jiki, teki, tama, unko)が欲しい」という主張じゃなかったの？
その引用部分のコードを、（引数のない）「update()」の中に
記述できない理由は何？

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

>>938
> ゲームオブジェクトはタスクにすべきではない

俺には、この根拠がいまだにわからない。

V-SYNCに応じてupdateを呼び出されたり、描画のために呼び出されたりするのだから、
少なくともTask派生クラスであるべきだと思うのだが。

それとも、その自機、弾、敵は描画には関係ないのか？

それとも、描画に関係あって、Task派生クラスではあるが、foreachでぶん回したいから
std::list<敵*> のようなものがいると言っているのか？

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

>>936-937
ども。不満は着目点がずれたまま議論してることです。

Jiki,Teki,Tama,UnkoがTask派生クラスじゃないという前提で私しゃべってます。

まず
void SceneTaskSTG::update() {
　　update(jiki, teki, tama, unko);
}
こういう書き方が良い。急いで付け加えると、なぜなら

void SceneTaskSTG::update() {
　　foreach t (teki) {
　　　　if (jiki.hit_check(t.get_hit_area())) {
　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　　　}
　　}
　　foreach t (teki_tama) {
　　　　if (jiki.hit_check(t.get_hit_area())) {
　　　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　　　}
　　}
　　...
}
こう進化させていけるから。
ド素人くさいとか泥臭い書き方が嫌という場合は劣化と受け取るかもですが。

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

あーそうか

ゲームオブジェクトのステートは
相互に依存していることが往々にしてあって、独立しているとは限らないから
おのおのについて「自分のステートを更新しろ」という号令を発する
モデルが常に適切とはいえない、という主張か

もう少しランクが上のクラスで（相互に関連した）ゲームオブジェクトのの
ステート更新をまとめて行う設計であれば、その配下のオブジェクトが
号令（VSYNC通知）を受け取る必要は無いし、むしろそれは無駄だと

そういう意味だと俺は解釈した

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

>>941
Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。

それらは、いま議論しているタスクシステム(タスクフレームワーク？)とは何ら関係ないのだから、
タスクシステムの書き方に準拠する必要はないだろう。

しかし、どう見ても自機、敵、弾は描画の必要がありそうなのにTask派生クラスじゃないが
わけわかんないし、俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
持って否定されなきゃならんのか、まったくわけがわかんない。

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

>>940
>それとも、その自機、弾、敵は描画には関係ないのか？
関係ないっすね
Task派生クラスでも無いです
foreachでぶん回したいのはあります。
std::list<敵*> のようなものは要ります。

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

>>942
それは、俺も理解しているし、たぶんみんな理解している。

本人はそれをうまく説明する言葉を持ち合わせていなかったようではあるが…。

しかも、もしその理解が正しければ、ID:wxGi2uACの反論は誰に対する反論にもなっていない。

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

>>944
>> それとも、その自機、弾、敵は描画には関係ないのか？
> 関係ないっすね

なにー！それなら、いかにもシューティングみたいで、いかにも、描画します、みたいなものを例に
持ってくるのがわけわかんない。しかも接触判定とか、もろに描画考慮しているように見えるじゃん。

それなら最初から、
　「主人公の体力」「主人公の生命力」「主人公の知力」(それぞれ描画は不要)
とか、そのくらいの説明は欲しいよ。

長々とつきあって損した。

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

>>943
>Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。
Yes.　全くその通りです。

>それらは、いま議論しているタスクシステム(タスクフレームワーク？)とは何ら関係ないのだから、
>タスクシステムの書き方に準拠する必要はないだろう。
ここだったんですね、すれ違いの原因。
このスレではタスクシステムを使う＝自機、弾、敵はTask派生クラスに絶対すべき、それこそがタスクシステム
という人が多かったのであなたもそういう考えの人だと誤解してました。でもそうではなかった。
この勘違いは私の落ち度です。ごめんなさい。思えばそういうそぶりは節々に出ていた。

あと、描画は別途foreach作ります。
void SceneTaskSTG::update(context) {
　　...
　　context.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);　← 描画
　　foreach t (teki) {
　　　　context.dev3dg->draw_model(teki_gazou, t.x, t.y);　← 描画
　　}
　　...
}

> 俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
> 持って否定されなきゃならんのか、まったくわけがわかんない。
タスクの書き方というより自機、弾、敵をTask派生クラスにすることを否定したいと思ってました。
そのためにタスク使わなくても自機、弾、敵を扱えることを示していたつもり。
でもあなたはそもそもそこを重要視してなかったようです。ここにすれ違いの原因がありました。
SceneをTask派生クラスとするのは問題ないと思います。

夜遅くなっちゃいました。そろそろほんとに寝ます。

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

>>945
>たぶんみんな理解している。
それは・・・
そういうスレになったらうれしいですね

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

>>947
話はわかった…。お疲れさま＆おやすみ。

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

話がさっぱりわからないけど
ゲームオブジェクトまたはその他もろもろのごった煮リストとは
違うタスクの話を始めたの？

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

眠れねー。
どうでもいいけどforeachでヒットチェックしてるとこ、べた書きはないだろ。
判定対象は同士は同じメソッド持ってんだし。

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

×判定対象は同士
○判定対象同士

**名前は開発中のものです。** · 2009/02/01(日) 04:08:29

ちなみに俺 ID:rIovvj90ね
俺的には>>936もいいとは言えないね
jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
シーンをタスクにいれて何のごった煮になるのか知らないけど
仮にタイトルシーン、シューティングシーン、リザルトシーン、・・・という種類のあるものなら
当然それに必要なupdateの引数も異なる
だからダメだね
まったく汎用性のない糞クラスだ

**名前は開発中のものです。** · 2009/02/01(日) 04:20:37

ID:rIovvj90=ID:rVEgp4cMって本当にプログラム書いてんのか？
どう見ても役に立ちそうにないんだけど。

俺の現場にこんな奴来たら、即クビにしちゃうけどな。
いま本当に仕事やってんの？ニートとかじゃなく？

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

シーンなんて最も抽象化しやすいものの１つだと思うんだが……。