トップページ⇒gamedev
1001コメント599KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001名前は開発中のものです。2008/11/09(日) 11:51:40ID:+pjnJyQQ
タスクシステムについての議論、相談、質問、雑談などのスレです

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/
0890名前は開発中のものです。2009/01/31(土) 17:58:00ID:8N26Dxd2
>>889
ネジ一本のツクリまで気にして設計してある車でなければ運転したくないです。
運転手の話したいの？
設計者の話でしょ？
0891名前は開発中のものです。2009/01/31(土) 18:00:52ID:8CtHI7i5
>>890
クラスAを作るとき、クラスAを利用する人間は、クラスAのユーザになる。
どちらも同じ人間かもしれないが、クラスはユーザに対しては詳細を
隠蔽するように働き、汚い泥仕事はその中に閉じ込め、問題の局所性を
高める。
本当にネジを気にしなければならないコードを局所化するわけだ。

OOPどころか、構造化プログラミングの基本中の基本ですので、
一から勉強しなおして下さい。
0892名前は開発中のものです。2009/01/31(土) 18:05:52ID:9d5EHsE6
>>891
> 問題の局所性を高める。

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

だからこそ俺は、template <class Context>とContextを用いて、
こいつにしかupdateメソッドのなかではアクセスしないという制約
のかけ方を示し >>886 、さらにそれを抽象化して >>887 、
何故、update(jiki,teki,tama,unko);と書くのが良くないのかに答えた。
0893名前は開発中のものです。2009/01/31(土) 18:19:35ID:8CtHI7i5
意味論的にupdate()をどう捉えるかでしょう

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

引数jiki, teki, tama, unkoを取るupdate()の「意味」は何でしょうか？
0894名前は開発中のものです。2009/01/31(土) 18:22:23ID:j5ds1u2H
>>888
Task<GameGlobalContext> のリストは TaskList<GameGlobalContext> で、
Task<SceneXXXContext> のリストは TaskList<SceneXXXContext> なわけでしょ？
Contextが増えたらTaskListが増えてるじゃん。
Contextの種類数＝リストの種類数ってことなんじゃないの？
0895名前は開発中のものです。2009/01/31(土) 18:25:58ID:9d5EHsE6
>>893
> update()の抽象的意味が、「VSYNCを通知する」ということであれば
> jikiだのtekiだのtamaだのunkoだのといった情報は抽象的意味とは無関係

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

ただ、世の中のイベントハンドラがすべてそうであるように、
そのハンドラのなかで使いたいであろうもの(マウスイベントならばマウスの状態、
キーボードイベントなら押されたキーの情報)を引数として渡すのは常識的なことなので
今回のケースも、updateなら何らかのContext(それは描画のためのものであったり、
そのSceneで使うものであったり)が付随していてもそれはおかしくはないと思うけど。
0896名前は開発中のものです。2009/01/31(土) 18:35:35ID:8CtHI7i5
>>895
ええ、そうですね
Cならば、コールバックの第一引数として、いずれにせよthisポインタ代わりのもの
を使うのが普通ですし

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

引数渡しをする場合には、テンポラリな情報のジェネリックラッパーを仮定していて
依存性をオブジェクト生成時に注入している場合には、長命オブジェクトへの
参照を仮定しているのではありませんか？
0897名前は開発中のものです。2009/01/31(土) 18:46:16ID:rIovvj90
>>885
メンバはダメじゃないだろ
ただ、別クラスのインスタンスのポインタの保持が禁止なだけ
それとupdateの例ではなにやらゲームのオブジェクトのクラスに
同じゲームオブジェクトのjiki,teki,tama,unkoを突っ込んでるようなソースに
なってしまっているがこれも間違いでありえない
仮にシーンクラスなんてのがあったらそこのメンバとして
jiki,teki,tama,unkoをもつ

ちなみに俺が最初に書いたソースのupdateはゲームオブジェクトの更新処理のつもりの
updateだったが引数でゲームオブジェクトを入れてるのは間違い
必要な情報だけ入れる
まあ、この場で話す分にはあんまり気にしなくておｋ
0898名前は開発中のものです。2009/01/31(土) 18:46:59ID:9d5EHsE6
>>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の種類を減らして
生成されるコードを縮めることにある。
0899名前は開発中のものです。2009/01/31(土) 18:58:37ID:9d5EHsE6
>>896
> ところで、違う目的のものに同じ"Context"という用語を用いているのは
> 混乱の元のように見えます

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

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

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

だもんで、CFTG(context-free tree grammar)とかの "context" という用語を
ここに持ってくるのはおかしくないと思ったんだけどな。
0900名前は開発中のものです。2009/01/31(土) 19:14:54ID:8N26Dxd2
>>886
の
> >>882 そういう動機なら
って番号ずれてる？
>>884 以降流れについていけてない俺に愛の手を
0901名前は開発中のものです。2009/01/31(土) 19:21:22ID:9d5EHsE6
>>900
番号はずれてない。
>>886 の「そういう動機」の「そう」が指すのは、 >>882 の　「あなた」から「したいという」まで。

わかりにくくてすまん。
0902名前は開発中のものです。2009/01/31(土) 19:31:42ID:j5ds1u2H
>>898
その場合、呼ばれる側はdynamic_castか何かで必要なContextの型に変換するんだよね。
呼ぶ側がどのContextを渡すかはどうやって判断するの？
0903名前は開発中のものです。2009/01/31(土) 19:31:50ID:9d5EHsE6
俺、実は主婦なので、いまから買い物にいかなきゃならん。

そんなわけで、明日まで、返答できない。
0904名前は開発中のものです。2009/01/31(土) 19:35:06ID:9d5EHsE6
半額セールがはじまる時間なんだ…。

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

この場合は、しない。

place holder的に、Contextの派生型だけ宣言しておく( >>898 )という使い方がありうると言いたかっただけ。
902を混乱させたようで悪かった。些末な問題なので、忘れてもらって構わない。
0905名前は開発中のものです。2009/01/31(土) 19:57:21ID:8CtHI7i5
>>899
> (あったほうが理解したり、読みやすかったりするんだろうけど)
無論、議論の参加者にとってはそのほうが良いわけですから、
その点の指摘に過ぎませんよ。

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

updateメソッドの引数としてのcontextという名前が非常に典型的であるのは
その通り（特にその中身がopaqueで、その意味内容をその場で論じたくない場合）
ですが、一方クラスメンバの名前としては、「context」は適切で意味が
明快な名前であるとは言いがたいでしょう。
0906名前は開発中のものです。2009/01/31(土) 21:06:47ID:rIovvj90
タスクシステム信者いたんだ？ｗ
なんかタスクシステムがヤバクなるとスレを流しにかかるよねｗ
>>826,>>830-832からの一連のレスは面白いから次のスレにも貼ろうｗ
0907名前は開発中のものです。2009/01/31(土) 21:14:54ID:8N26Dxd2
>>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());
　　　}
　}
（続く）
0908名前は開発中のものです。2009/01/31(土) 21:21:41ID:8N26Dxd2
（続き）
最後に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); が良い。
0909名前は開発中のものです。2009/01/31(土) 21:42:33ID:9d5EHsE6
買い物から戻ってきた。

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

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

俺としては、SceneXXXContextの変数名がcontextなのは、
大きなクラスでない限りはそれくらいの省略は許されるべきだと
思うんだが。また、SceneXXXContextは、SceneXXXを構築するのに必要な
文脈という意味で、意味明瞭だと思うのだが。
0910名前は開発中のものです。2009/01/31(土) 21:46:18ID:8CtHI7i5
>>909
ああ、申し訳ないっす。後のほうの話を念頭に置いてなかった。
そっち見りゃ、少なくとも「なんのつもりか」は分かるでしょうね。
0911名前は開発中のものです。2009/01/31(土) 21:51:42ID:9d5EHsE6
>>910
了解
0912名前は開発中のものです。2009/01/31(土) 21:54:52ID:9d5EHsE6
>907-909
> 理由はゲームオブジェクト間は通信が多いので引数渡しを使用可能としたいため。
> タスクでは引数渡しができないのが嫌。

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

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

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

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

どうせ、ゲームオブジェクトにしてもそのオブジェクトの
生存の確認は必要なんだろうし、>>875 のコードと何ら変わらないんじゃ？
0913名前は開発中のものです。2009/01/31(土) 22:22:05ID:8N26Dxd2
>>912
実質グローバル変数渡ししかできないから。

foreach t (teki) {
　　if (jiki.hit_check(t.get_hit_area())) {
　　　　jiki.set_hp(jiki.get_hp() - t.get_attack_point());
　　}
}
これならそもそも生存してるやつ同士しか参照が発生しないから生存確認必要ないかと
0914名前は開発中のものです。2009/01/31(土) 22:24:13ID:rIovvj90
>>912
明示的なって意味じゃねぇの？
だいたいそんな十把一絡な引数あってもしょうがねぇし

引数はソースコードに明示的にわかるようなものでないと俺は意味がないと思ってる
グローバルにしてテキトーに渡したほうが速いじゃん
0915名前は開発中のものです。2009/01/31(土) 22:34:27ID:9d5EHsE6
>>913
> 実質グローバル変数渡ししかできないから。

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

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

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

そもそも、俺の「タスク」(>>846)とは「タスク」そのものが違うような気がする。
0916名前は開発中のものです。2009/01/31(土) 22:37:59ID:9d5EHsE6
>>914
> 明示的なって意味じゃねぇの？
> だいたいそんな十把一絡な引数あってもしょうがねぇし

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

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

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

グローバル変数なんか使わないっちゅーの。
本当、ID:rIovvj90は、タスクシステム以前にプログラミング自体、ド素人なんだな。
0917名前は開発中のものです。2009/01/31(土) 22:41:36ID:rIovvj90
そもそもまずいのはグローバル変数・関数じゃなくて
グローバル・スタティックの変数・関数、別クラスのインスタンスのポインタの保持、
シングルトン、アドレスジャンプ等を使用することによって
明示的な関連が全く見えなくなることだけどね

別にそこにこだわってないならいいんじゃないの？
どう組んでもｗ
0918名前は開発中のものです。2009/01/31(土) 22:44:58ID:8N26Dxd2
>>915

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

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

俺の「タスク」は
class Task {
public:
　virtual void update(void)=0;
}
的なやつを実装したもの。update(Context？)=0;でもいいけど。
0919名前は開発中のものです。2009/01/31(土) 23:31:26ID:9d5EHsE6
>>918
>> EnemyTask* enemyTask1 = TaskHandleToPtr<EnemyTask>(enemy1);
> これが実質グローバル変数。
> これがグローバル変数とほぼ等価だと認識できないの？

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

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

それとも、こんなド素人が二人も都合良くこのスレに出没してるのか？
0920名前は開発中のものです。2009/01/31(土) 23:37:25ID:9d5EHsE6
>>918
>「自機と敵機の座標が重なっていたら自機にダメージ与える」という処理に
> おいて言えば「自機」と「敵機」がそれぞれゲームオブジェクト。

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

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

「ゲームオブジェクト」とやらも、そのTask派生クラスでいいじゃん。
何がまずいの？
0921名前は開発中のものです。2009/01/31(土) 23:55:45ID:rIovvj90
>>919
違うっつの
しかも、グローバル変数が問題じゃなくて
明示的な関連（アクセスかな？）が見えないのがまずいって言ってるだろ
関数の実行に必要なもんをソースみてわかるようにしろ
簡単だろ？
何もむずかしいこといってやしねぇだろ？
0922名前は開発中のものです。2009/01/31(土) 23:59:28ID:9d5EHsE6
>>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) のポインタを渡す。

だから「実質グローバル変数」ではない。
0923名前は開発中のものです。2009/02/01(日) 00:02:59ID:YQa72ap1
>>921
> 関数の実行に必要なもんをソースみてわかるようにしろ

についてだが、

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

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

これは「みてわかる」と思うんだが、何をそんなに問題にしているのか
それがわからない。
0924名前は開発中のものです。2009/02/01(日) 00:13:31ID:YQa72ap1
いま気になったので、ID:rIovvj90 と ID:8N26Dxd2 の書き込みを
全部読み返したのだが、この二人(一人？)は極端に日本語が不自由だな。

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

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

というのはさておき、わかってないのはこの二人(一人？)だけみたいなので
IDも変わったことだし、俺はもう寝る。
0925名前は開発中のものです。2009/02/01(日) 00:23:24ID:rVEgp4cM
>>924
文体が全然違うのに病気だろそれはｗ
ちなみに俺はID:rIovvj90ね
0926名前は開発中のものです。2009/02/01(日) 01:03:01ID:DFOa0Cn0
君たち、タスクシステムの話をしなさい。
素人だとかプロだとか、技術と関係ない感想は取り除いて話しなさい。
0927名前は開発中のものです。2009/02/01(日) 01:07:33ID:wxGi2uAC
ID:8N26Dxd2 です

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

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

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

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

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

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

#話全く関係ないけどgoogleびびったｗ
0928名前は開発中のものです。2009/02/01(日) 01:42:31ID:ZI4Z1t2K
>>919
> 同一人物なのか？
人を陥れるために真似る奴もいるぜ
あまり単純に考えない方がいい

つか>826にあるコードの断片だけを見て
どっちがいいか判断できるなんてエスパーとしか思えん。
0929名前は開発中のものです。2009/02/01(日) 01:52:34ID:7YDjPQ+X
>>826
引数でどうしても縛りたいならupdate()のなかでupdate(jiki,teki,tama,unko)呼べば解決じゃねーのか。
何が問題になるんだ。
0930名前は開発中のものです。2009/02/01(日) 01:59:33ID:v/nkqtd/
>>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)を例に出すのは間違ってる。
0931名前は開発中のものです。2009/02/01(日) 02:01:26ID:YQa72ap1
>>927
> 「ポインタを全タスクにばらまいてどこからでも全データ参照できる機構」の
> 嫌なとこはプログラムのどこかで変数の内容が変更される可能性があるのに
> それが把握できないことでしょ

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

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

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

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

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

いずれにせよ、グローバル変数は使ってないし、
「どこからでも全データ参照できる機構」もないし、大きなオーバーヘッドもないが？
09329292009/02/01(日) 02:06:31ID:7YDjPQ+X
省略しすぎた

> 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);
0933名前は開発中のものです。2009/02/01(日) 02:09:16ID:wxGi2uAC
>>922
俺が実質グローバル変数と言う判断基準は

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

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

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

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


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

ねもいにょ。俺ももう寝るにょ
0934名前は開発中のものです。2009/02/01(日) 02:13:36ID:YQa72ap1
>>932
俺、ID:9d5EHsE6で、その>>826 に反論してた側の立場なんだけど、
その>>932に対する返答らしきものが、>>907-908 にあるのだが、
これの意味が俺にはさっぱりわからない。
0935名前は開発中のものです。2009/02/01(日) 02:20:15ID:7YDjPQ+X
>>934
俺にもさっぱりです。
0936名前は開発中のものです。2009/02/01(日) 02:21:59ID:YQa72ap1
>>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();
};

何かこれで不満でも？
0937名前は開発中のものです。2009/02/01(日) 02:28:22ID:YQa72ap1
>>933
936の補足。

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

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

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

方法はいろいろある。
0938名前は開発中のものです。2009/02/01(日) 02:36:57ID:wxGi2uAC
>>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());
> 　　　　　}
> 　　　}
> 　　　...

みたいに変化すべきと思うけども
0939名前は開発中のものです。2009/02/01(日) 02:42:44ID:U7FhX9ul
意味というか、論点がわかんねぇ……

>>938
その引用部分は、何のつもりだかはある程度は想像はつくが、
update(jiki, teki, tama, unko)
はどこでも呼んでいない
「update(jiki, teki, tama, unko)が欲しい」という主張じゃなかったの？
その引用部分のコードを、（引数のない）「update()」の中に
記述できない理由は何？
0940名前は開発中のものです。2009/02/01(日) 02:44:19ID:YQa72ap1
>>938
> ゲームオブジェクトはタスクにすべきではない

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

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

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

それとも、描画に関係あって、Task派生クラスではあるが、foreachでぶん回したいから
std::list<敵*> のようなものがいると言っているのか？
0941名前は開発中のものです。2009/02/01(日) 02:50:32ID:wxGi2uAC
>>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());
　　　　}
　　}
　　...
}
こう進化させていけるから。
ド素人くさいとか泥臭い書き方が嫌という場合は劣化と受け取るかもですが。
0942名前は開発中のものです。2009/02/01(日) 02:51:44ID:U7FhX9ul
あーそうか

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

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

そういう意味だと俺は解釈した
0943名前は開発中のものです。2009/02/01(日) 02:55:14ID:YQa72ap1
>>941
Task派生クラスではないならタスクではないのだから、好きなように書けばいいじゃないか。

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

しかし、どう見ても自機、敵、弾は描画の必要がありそうなのにTask派生クラスじゃないが
わけわかんないし、俺のタスクの書き方をどうして、タスクと関係のないプログラムの書き方を
持って否定されなきゃならんのか、まったくわけがわかんない。
0944名前は開発中のものです。2009/02/01(日) 02:58:30ID:wxGi2uAC
>>940
>それとも、その自機、弾、敵は描画には関係ないのか？
関係ないっすね
Task派生クラスでも無いです
foreachでぶん回したいのはあります。
std::list<敵*> のようなものは要ります。
0945名前は開発中のものです。2009/02/01(日) 02:59:14ID:YQa72ap1
>>942
それは、俺も理解しているし、たぶんみんな理解している。

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

しかも、もしその理解が正しければ、ID:wxGi2uACの反論は誰に対する反論にもなっていない。
0946名前は開発中のものです。2009/02/01(日) 03:02:00ID:YQa72ap1
>>944
>> それとも、その自機、弾、敵は描画には関係ないのか？
> 関係ないっすね

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

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

長々とつきあって損した。
0947名前は開発中のものです。2009/02/01(日) 03:16:59ID:wxGi2uAC
>>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派生クラスとするのは問題ないと思います。

夜遅くなっちゃいました。そろそろほんとに寝ます。
0948名前は開発中のものです。2009/02/01(日) 03:22:54ID:wxGi2uAC
>>945
>たぶんみんな理解している。
それは・・・
そういうスレになったらうれしいですね
0949名前は開発中のものです。2009/02/01(日) 03:24:59ID:YQa72ap1
>>947
話はわかった…。お疲れさま＆おやすみ。
0950名前は開発中のものです。2009/02/01(日) 04:01:32ID:rVEgp4cM
話がさっぱりわからないけど
ゲームオブジェクトまたはその他もろもろのごった煮リストとは
違うタスクの話を始めたの？
0951名前は開発中のものです。2009/02/01(日) 04:03:36ID:7YDjPQ+X
眠れねー。
どうでもいいけどforeachでヒットチェックしてるとこ、べた書きはないだろ。
判定対象は同士は同じメソッド持ってんだし。
0952名前は開発中のものです。2009/02/01(日) 04:04:49ID:7YDjPQ+X
×判定対象は同士
○判定対象同士
0953名前は開発中のものです。2009/02/01(日) 04:08:29ID:rVEgp4cM
ちなみに俺 ID:rIovvj90ね
俺的には>>936もいいとは言えないね
jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
シーンをタスクにいれて何のごった煮になるのか知らないけど
仮にタイトルシーン、シューティングシーン、リザルトシーン、・・・という種類のあるものなら
当然それに必要なupdateの引数も異なる
だからダメだね
まったく汎用性のない糞クラスだ
0954名前は開発中のものです。2009/02/01(日) 04:20:37ID:3I9VPm/8
ID:rIovvj90=ID:rVEgp4cMって本当にプログラム書いてんのか？
どう見ても役に立ちそうにないんだけど。

俺の現場にこんな奴来たら、即クビにしちゃうけどな。
いま本当に仕事やってんの？ニートとかじゃなく？
0955名前は開発中のものです。2009/02/01(日) 05:38:23ID:1JPWlzeO
シーンなんて最も抽象化しやすいものの１つだと思うんだが……。
0956名前は開発中のものです。2009/02/01(日) 11:56:06ID:wxGi2uAC
>>951
自機も敵も弾も全て同じ当たり判定してるなら同じメソッドでしょうから
1つのforeachにまとめてもいいかもしれませんね。
ただ、自機、敵、弾のリストを当たり判定リストとして統合した１フレーム限りの寿命のリストを作るのが良いかどうかという問題が発生しますが。
オブジェクト毎に異なる当たり判定処理を導入しやすいという利点を得た代わりにどんくさい見た目になってると考えればまぁ許容範囲かと。

あと、この手法が真価を発揮するのはひとくくりに抽象化できないもの同士の情報やり取りが楽になることです。
つまり当たり判定という「処理」部分の中に閉じた話ではなく、
「入力」、「処理」、「描画」を簡単に接続できるとこに真価を発揮します。

例１：自機を動かす
　・InputDevice（イベントハンドラとかで１フレーム分キー入力とかをバッファリングするオブジェクト）
　・jiki
　・OutputDevice
というオブジェクトがあった場合に
　・InputDevice・jiki間はswitch (InputDevice->popKey()) ～
　・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
と書ける。

例２：メニュー画面を操作する
　・InputDevice
　・menu（キー情報を入力として保持カーソル位置情報を変更）
　・menu_draw_model（menuを入力として１フレーム分の描画内容を決定）
　・OutputDevice
この場合もオブジェクト間で発生するデータのやりとり処理が素直に思いつきますよね。

オブジェクト間にまたがるデータ通信は無理やりどこかのオブジェクトに押し込めるのではなく、
Sceneクラスが受け持つ。そしてC入門書よろしく関数呼び出しを延々と書いていく。構造化プログラミングに逆戻りです。
利点はオブジェクト間の通信処理がC初心者でも書ける位に簡単化されることです。
（私はゲームオブジェクトにタスク導入反対派なので、こう記述すればタスク使うより楽にプログラミングできますよねという意図で書いてます）
0957名前は開発中のものです。2009/02/01(日) 12:07:10ID:wxGi2uAC
そういえば
>　・InputDevice・jiki間はswitch (InputDevice->popKey()) ～
>　・jiki・OutputDevice間はcontext.dev3dg->draw_model(jiki_gazou, jiki.x, jiki.y);
これらをそれぞれタスク化するのはありかも。
処理だし
0958名前は開発中のものです。2009/02/01(日) 12:39:31ID:rVEgp4cM
タスクシステム総合スレ part4
http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
0959名前は開発中のものです。2009/02/01(日) 13:07:49ID:1YAKubd4
なんだこの損した感は
0960名前は開発中のものです。2009/02/01(日) 20:36:02ID:3I9VPm/8
ID:rVEgp4cMには>>954の返答がもらえないみたいなんだが
無視して>>958みたいに次スレ立ててるところを見ると本当にニートなのか

それは悪いことを聞いたな・・

前スレ、前前スレから、ひとりだけ異様にレベルの低いことを言う、
プログラムが少しも出来そうにもない、日本語の読み書きが不自由そうな
タスクシステム否定派が混じってると思っていたんだが、
それがID:rVEgp4cMだったのか・・・
0961名前は開発中のものです。2009/02/01(日) 21:15:33ID:rVEgp4cM
>>960
一応、本職のＰＧですわ
ってなんでお前にそんなこと言わなきゃいけないのか？
内容でレス返せなくなったから人格攻撃に移ろうと思ったの？
育ちが悪いなぁ
0962名前は開発中のものです。2009/02/01(日) 21:29:27ID:3I9VPm/8
>>961
あんたの書いた>>831とか

>タスクシステムはごった煮ソースになるので
>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞

この一文を見ただけであんたがとんでもない大馬鹿野郎で相手するだけ無駄な
三下プログラマだと誰が見てもわかるんだが。

なんでそこまで自覚無いのか知らないが、このスレであんた一人だけレベルが
異様に低いんだよ。

こんな場末のスレだってまともな人がたまに遊びに来て、
有意義なことを言ってくれるのに、あんたみたいな
クズが居たら議論の妨げにしかならない。ほんと、いい迷惑。
0963名前は開発中のものです。2009/02/01(日) 21:36:14ID:DFOa0Cn0
自分が三下ではないと思うのならぜひ >>497 の問いかけに答えてみて欲しい。

いつのまにかタスクシステムありきで話が始まるんだから恐ろしい。
0964名前は開発中のものです。2009/02/01(日) 21:46:58ID:rVEgp4cM
>>962
全然主旨と違うところに噛み付いてるけど
ソースに明示的に引数を書いて関数に必要なインスタンスをわかるようにしろ
ってのがメインなんだけどね
ここをあんまりずらしてほしくないな

あと、インクルードだってできるできないは別にしてもインクルードしてるんでしょ？
だって折角引数なくしてごった煮にしたのにそんなところに制限あっても
邪魔なだけもんねぇｗ
それとタスクシステムで組むなら俺はインクルードしちゃうべきだと思うよ
制限があることにもはやなんの意味もないわけだし
あえて言えばタスクシステムにしたのが運の尽きでしょｗ
プログラムの組み方（主に引数）によるクラスや関数の関連・アクセスの限定が
できないわけだしもうなんでもやっちゃったらいいよｗ
0965名前は開発中のものです。2009/02/01(日) 22:02:08ID:wxGi2uAC
>>953
> jiki,teki,tama,unkoと同じ問題が今度はシーンにうつるだけだ
まあね。

> まったく汎用性のない糞クラスだ
ほどほどに汎用性のないちょっとだけダーティクラスだ
程度の言い方の方が良いのでは？

いつまでも通用する完全に汎用的なライブラリとして整備するかどうかは別として
似たようなゲーム量産する時にこういうクラスを作っとくのは実用上アリと考えても良いかと。

シーン間にまたがった画面遷移させたいというような要求が出て「やっぱシーン間も引数渡ししたいね」
となってから使うのやめたとしても、ゲームオブジェクトを脱タスク化する仕事量と比べたら傷は無いに等しい。
だから導入する人の直近の実用上に問題無いなら問題無いか、という姿勢で自分はＯＫと思った。
0966名前は開発中のものです。2009/02/01(日) 23:42:46ID:YQa72ap1
>>953
> 俺的には>>936もいいとは言えないね
(snip)
> まったく汎用性のない糞クラスだ

あんた、本当に頭がおかしいんじゃないの？

936は、具体的なシーンを構築するためのクラスであって再利用するわけでもなく、
汎用性なんか必要ないんだが。
0967名前は開発中のものです。2009/02/01(日) 23:52:08ID:rVEgp4cM
>>966
だったらなぜにTask？ｗ
0968名前は開発中のものです。2009/02/02(月) 00:23:38ID:+kwO8CZh
何故理解していないものを批判できると思うのか。
Taskはより抽象的なクラス。こちらは汎用的である必要がある。
SceneTaskはより具象的なクラス。こちらは汎用的である必要はない。
0969名前は開発中のものです。2009/02/02(月) 00:25:53ID:cShVBku0
>>968
したらどうして継承して～Taskクラスである必要があるのん？ｗ（俺はないと思うんだけどｗ）
ばっかじゃねぇんｗ
0970名前は開発中のものです。2009/02/02(月) 00:30:10ID:SpnGISw5
まさかの第２ラウンドｗｗｗ
遅刻の予感ｗｗｗ
0971名前は開発中のものです。2009/02/02(月) 00:31:50ID:+kwO8CZh
名前の話か？　それは単にサンプルだからだろ。
実際にはSceneTaskなんて何も表してない名前は使わないだろう。
Scene全体のスーパークラスとしてはあり得るかもしれんが。
0972名前は開発中のものです。2009/02/02(月) 01:19:55ID:ZmvZOOAJ
俺はID:rVEgp4cM(スレ主)と議論するのは時間の無駄だと思うので
よそのスレでやりたいわ。

あるいは、ID:rVEgp4cMを無視して話を続けてもいいだろうが。
0973名前は開発中のものです。2009/02/02(月) 01:38:35ID:lhNqT94l
いいスレなのに、スレ主がいるだけ邪魔というのが惜しいな
0974名前は開発中のものです。2009/02/02(月) 06:25:56ID:cShVBku0
>>972
アレアレ？
敗北宣言？ｗ

まあ、いいけどダメな組み方なのわかってて
それを人に押し付けるのやめてね
その先に進歩ないからｗ
0975名前は開発中のものです。2009/02/02(月) 06:49:09ID:lhNqT94l
>>974
お前が一人でスレのレベルを下げてるのな
せっかく、いいスレなのにな・・
0976名前は開発中のものです。2009/02/02(月) 07:40:15ID:P5kryGXr
タスク信者、反論できなくなっちゃったかｗ
ていうか、タスク信者っていたんだ？
0977名前は開発中のものです。2009/02/02(月) 10:33:29ID:+kwO8CZh
俺はこのスレでは「タスクシステムの是非」あるいは
「安全性の高いタスクシステムの設計」について論じたいのだが、
前者については「理解できないから全否定」というスタンスの
奴がいる限り、まともな議論は望めそうにないな。
後者に関して、もう少しID:9d5EHsE6の話を聞きたかったが、
こうもノイズが多すぎては……。
0978名前は開発中のものです。2009/02/02(月) 11:18:38ID:LfmM5Xp6
タスクシステムではタスクがどうのこうのという割に、
実際にはタスク＝オブジェクト みたいな図式ができあがってて、
それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

ゲームを設計する上でゲームオブジェクトみたいな概念を持ち出すようでは、
タスクシステムを設計するのに向いてない。

BASIC時代のように、自機は自機関連サブルーチンが処理して、敵Aは敵A関連サブルーチンが処理をする。
これらのサブルーチン群をうまくスケジューリングするために、タスクシステムを設計するのが本道である。

データ中心指向と機能中心指向の対決がこのスレにつまっているのだよ。
えっへん。

とか言ってみるテスト。
0979名前は開発中のものです。2009/02/02(月) 12:05:21ID:ZmvZOOAJ
こんな基地外(>>976)、死ねばいいのに…
0980名前は開発中のものです。2009/02/02(月) 21:18:42ID:SpnGISw5
>>978
なるほどなー
なんか自分がすごいことを考えてるような気がしてきた

BASIC時代ってあんま知らないけど、
BASICの「サブルーチン」ってCでいう引数がvoidの関数だよね？
0981名前は開発中のものです。2009/02/02(月) 21:36:01ID:SpnGISw5
タスクだけで組もうとしてタスクシステムに行き着き、
結果、タスク間にまたがるデータのやりとりがおろそかになった。

一方データだけで組もうとして最初期のオブジェクト指向、つまり
オブジェクトとメッセージングのみが存在するシステムに行き着き、
結果、データ間にまたがる処理の記述がおろそかになった。

こんな感じかな？

そこでさらに、タスクのつもりで実はオブジェクト作ってたとか、
オブジェクトのつもりで実はタスク作ってたとかいうことが発生して
それはもう大混乱←今ここ
って感じ？
（はてなばっかりだ俺）
0982名前は開発中のものです。2009/02/03(火) 03:34:35ID:dxGO6tf5
初心者向けを適当にピックアップ。
というよりぱっと見て自分が理解できる情報。用語力のなさと前提条件がわからないのが致命的。

>>114,115
>>331,334,337,339,340
>>427,429,431
>>459
>>492-498,>>503,508,509,>>522,>>528
>>498,500,516,523
>>529,534,553,571,573,588

とりあえず休憩。

>>460,>>544
そういや松浦さんってシューティングゲームプログラミング書いてた人なのね。
あれは結構初心者の自分としては色々参考にはなったんだけどなぁ。まさに>>544の初心者ですわ。
(当時タスクシステムが何いいたいかよく分からんかった。ので、自機、敵機のリストで多態性して組んだ。
ってかこの本のやつは別にごった煮リストじゃナカタヨ。普通に自機系、敵機系と分けてるよ。)

0983名前は開発中のものです。2009/02/03(火) 04:10:21ID:dxGO6tf5
>>684-686,>>762,803,762,>>805,807-811
>>816-819,>>823

>>826
上、開発中とか思案中に良くある。下、クラスライブラリとして整理して切り出した後。
うん、クラスライブラリ化できると下っぽくはなる気がする。

>>876,>>877
C#のGC自体はどんな間隔でやってるか知らないけど、実行中にタスクマネージャのメモリを見ると結構こまめにやってそうな気がする。

ここら辺から先、斜め読みできなくて困る。

0984名前は開発中のものです。2009/02/03(火) 04:53:00ID:dxGO6tf5
>>932,938
俺、個人的には配列とかリストみたいなコレクションの変数名は、sをつける派です。jikisとかenemysとかunkosとか。
文法的に間違ってそうだけどたまに配列の配列とか、jikisesとかやりだします。こりゃ流石に自分しか分からんが。
これ、jikiとかtekiとかunkoとかが同じ汎化クラス持てると、super　superses[][]とかできまっせー。
こんな洗練されてなかったけど、>>982の本読んでたころの最終系は確かそんな感じにSTGSceneを構築してた。
(もちろんシーンはタスクじゃなかった。線形リストでもない、ただのスイッチで分岐したやつだった)
シーン管理については↓に解説があったよ。
ゲームにおけるデータ構造・クラス設計・パターン2
http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/l50

とりあえず追いついたー。




0985名前は開発中のものです。2009/02/03(火) 05:01:55ID:dxGO6tf5
>>983になぜか>>762が2つあるね。明らかなミスです。
0986名前は開発中のものです。2009/02/03(火) 05:38:27ID:SI2YL2Kh
>>978
＞タスクシステムではタスクがどうのこうのという割に、
＞実際にはタスク＝オブジェクト みたいな図式ができあがってて、
＞それ、劣化オブジェクト指向だよねって突っ込まれる事例が増えていると。

このスレには色んな村の人々が入り乱れていてそれぞれの村独特の言葉を駆使するから
議論が途中でヘロヘロになるんだろう

例えばタスクという言葉、ようなハードウェアにかなり近い位置で動く、つまりOSやモニタといった
プログラムにおいては古くから使われてる、わりと由緒正しい、計算機用語だ
50～60年代のメインフレーム用マルチタスクOSの誕生時よりタスクとはジョブステップであり
ユーザー定義のジョブを逐次処理・並行処理するために（システムが内部で）それを分割し
CPUに割り当てる（ディスパッチする）ときの単位だ。タスクは基本的に

　　①計算機の内部状態（コンテキスト。これはレジスタセット等）の全て、ないし必要な部分
　　②ジョブ（プログラムとデータの参照）

で構成される。①は例えばマルチタスクOSのプロセスのようにレジスタセットの大半を保存し
アドレス空間まで切り替えてしまう大掛かりなものから、超簡素な組み込みシステムの軽量な
スレッドのようにPCとSP（と一部の汎用レジスタ）のみを保存して切り替えるものまで多様
0987名前は開発中のものです。2009/02/03(火) 05:39:06ID:SI2YL2Kh
だが>>2のタスクの説明では揃いもそろって可視で移動するキャラクタ（OBJ）でしか解説しないし
コンテキストの切り替えというのは一切してくれない。ユーザープログラム側で解決すべきこととしている
この辺がOS用語のタスクと明らかに異なるところでありひとつめの誤解を作り出し、「なんぞこれ
逐次処理してくれるんじゃなくてジョブを周期的にバッチ処理してるだけじゃねーか」という突っ込みが来る。
また小規模な組み込みシステムみたいにハードとユーザーが接近してる環境を除けば
タスクというのはユーザープログラムの知る由もない内部の処理単位のはずなのだが
>>2ではユーザー自身がジョブを分割し周期タスク用のユーザープログラムを書かせる
普通のWindowsやLinuxのようなOSのタスクを念頭に考える人にとってこれも混乱のひとつに
なるだろう。あとTCBという言葉の意味もかなり変わってる

こうした特殊な意味づけは個々の商品・製品・システムの中のローカル用語なのだから
こういう場でポーンと無造作に使えば混乱するのは仕方ない
0988名前は開発中のものです。2009/02/03(火) 05:51:19ID:SI2YL2Kh
このスレには様々なセカイの人々が入り乱れてる

　①-a　厨房タスクシステムのセカイ
　　ネットで発生。主成分は純真無垢な中二。一部2Dオヤジ、レトロ765信者。>>2とか松浦本がバイブルだ
　　知的水準としては松浦先生のタスク解説に感銘を受けCodeZineの記事は参考になるという程度
　　彼らがタスクというとき、それは画面に表示されるキャラの構造体やクラスのインスタンスのことらしい
　　それは自称TCBなる管理領域の変数を侵入・癒着させており、連結リストに繋がれてるようだ
　　彼らはOS用語を変質させ特殊な意味を与えてしゃべる。予め>>2や松浦本を読んどかないと理解不能だ
　　若年層は純真無垢な中二なのでタスクシステム＝負け組のかっこ悪いコードという印象操作に弱い
　　最近はひらしょー本でアンチタスクに鞍替えし②-aになった者が多いように見受けられる
　　
　①-b　幻想タスクシステムのセカイ
　　ネットで発生。①-aの末期症状。主成分はファンタジー、若気の至り。原理主義。教条主義。OOで再解釈
　　彼らは全ての処理を唯一のリストに放り込み1/60[s]周期で逐次処理することこそ美しいと確信する
　　あらゆる粒度の処理を唯一のリスト巡回＆関数アドレス経由で実行することこそ真のタスクシステムと信じる
　　シーンも敵も味方も通常弾も誘導弾もアイテムもパーティクルも何もかも皆同じリストに入れなきゃ異端
　　可視属性も不可視属性も関係なく全ては1/60[s]固定時間刻みで周期的に実行されるものであるとする
　　OOで再解釈するとこれはGoFのobserver patternだったのだ（←な、なんだってー！？）strategy pattern
　　だったのだ（←な、なんだってー！？）といったかなり無理矢理な話をはじめたりする。狂気に見えるが
　　どうも本気らしい
0989名前は開発中のものです。2009/02/03(火) 06:29:34ID:SI2YL2Kh
　①-c　中小零細タスクシステム使いのセカイ
　　亜種多数。逆引き本もその内のひとつ。現在でも中小零細ソフトハウスのモバゲ・DSの現場でたまに見られる
　　あと7号の現場にも見られる。プロっつってもピンキリ。キリはモバゲに多く、ピンは7号に多い傾向にある
　　①-a ①-bとは異なり現場で使い込んできた人間であるため無茶苦茶なことはいわない。欠点も承知している
　　タスクシステムというのが身内でしか通じないイナカッペの方言・ローカル用語であることも承知しており
　　お天道様の下でタスクシステム万歳と声高に叫ぶ者は稀
　
　①-d　昔はタスクシステム使いだった人のセカイ
　　自称タスクシステムといっても千差万別であり、①-a,b,cとは似ても似つかないようなお化けが存在した
　　SSのAに近い統合開発環境だったりしたけど、こういうものは現在ではミドルウェアだのゲームエンジンだの
　　フレームワークだのと呼んでいるよ
レス数が950を超えています。1000を超えると書き込みができなくなります。