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

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

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

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

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

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

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

前スレで判明したことだが>>1だけが異様に初心者でおまけに日本語が不自由で
一人だけ言っていることのレベルが低すぎて無駄な議論をすることになる。

ゲ板は>>1のための日本語教室ではない。
よって我々はこのスレは放棄する。

■■■■■■■■■■■■■　終　了　■■■■■■■■■■■■■■■■

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

ありゃりゃｗ
うわーん！もうこねぇよ！的書き込み？
前スレでとっちめ過ぎたか(笑)
強くｲｷﾛ

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

初心者でも日本語不自由でも構わないが、そのことを全く無自覚なのが致命的

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

>>3
俺も同感。こんな基地外の面倒見切れねぇ。

■■■■■■■■■■■■■　終　了　■■■■■■■■■■■■■■■■

**名前は開発中のものです。** · 2009/02/02(月) 18:56:46

埋めてみる

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

>>1
よかったね

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

>>1
おめでとうございます。

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

>>1
さすがです。

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

さすが>>1さん。
>タスクシステムはごった煮ソースになるので
>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
とか他の人と言うことが違う。
憧れるわ～。

**名前は開発中のものです。** · 2009/02/02(月) 19:36:10

俺のヒーローインタビューがまだ続いてるのか
まあ、数人のタスク信者を２人で撃退したからね当然といえば当然だな
忘れないように前スレの勇姿を貼っておこう

http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/824-974

824 名前：名前は開発中のものです。[sage] 投稿日：2009/01/31(土) 02:30:33 ID:2y83CUUn
デザインパターンで安全にタスクシステムを構築できるということについて
具体的に否定できるヤツは一人もいないなｗ

ファビョって否定してるやつが数人いるようにみえるがID変えてるだけのアホが一人なんだろうな。

826 名前：名前は開発中のものです。[sage] 投稿日：2009/01/31(土) 02:44:15 ID:rIovvj90
>>824
安全には無理でしょ
明示的な引数がない時点でプログラムの作法云々なんてもう
気にしない組み方だと思うけどね

update();

で動くのと

update(jiki,teki,tama,unko);

で動くのとじゃ
プログラムとしては絶対に下のがいい
上は結局、その関数で何が必要なのか要素がまったくわからない
アクセスしているものを知るには中身のプログラムを読むしかないし

**名前は開発中のものです。** · 2009/02/02(月) 19:40:57

>>12
終了ですよ

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

■■■■■■■■■■■■■　終　了　■■■■■■■■■■■■■■■■

**名前は開発中のものです。** · 2009/02/02(月) 19:43:21

このスレはすでに終了しています。

**名前は開発中のものです。** · 2009/02/02(月) 19:45:22

糸冬了

**名前は開発中のものです。** · 2009/02/02(月) 19:47:14

>>13-16
お前もしかして１人でやってんの？（笑）
でひゃひゃひゃひゃｗ

**名前は開発中のものです。** · 2009/02/02(月) 19:47:53

ひとりでやってるよ

**名前は開発中のものです。** · 2009/02/02(月) 19:51:25

>>18
書き込み制限つらそうだなｗ

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

このスレは俺が粘着してるから他のスレで楽しんでください。

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

>>12
> まあ、数人のタスク信者を２人で撃退したからね当然といえば当然だな

お前には、自分が撃退されることもわからないのか。こんな基地外珍しいな。

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

ID:cShVBku0がコテになるっていうなら俺は消える。
そしてコテになったら即あぼ～ん設定してあげるよ。

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

ＩＤあるんだからさっさとあぼーんしろよｗ
そしたら前スレの俺の武勇伝をあることないこと脚色して書き込むからさｗ

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

IDあぼ～んしちゃったら何がなんだかわからなくなるじゃん

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

まともに議論したいんだったら、mixiとか使って
基地外は排除しちゃえばいいんじゃない。

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

よーしじゃあmixiに移動だ
でどこ？

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

>>12
数人っていうか１人のように思う。

それと、疲れちゃったプログラマをからかい続けるのは感心しない。
そろそろやめとけば？
なんか効き目が強い。多分本当に病気だ。
それでもやっぱタスク使ってて何か引っかかるものがあるからこのスレに来てるんだろうし

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

■■■■■■■■■■■■■　スレ主が真性基地外であることが発覚したため終了　■■■■■■■■■■■■■■■■

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

>>27
いいんだよ
そいつの次の成長なんてタスクシステムを捨てた先にあるのは明らかなんだから
それに他の初心者がこんなもん妄信しはじめたらどうする

それに程度の低い書籍の悪影響もあるだろうな
ベタ書きを極度に馬鹿にするあまり
書かなければならない処理があるということの説明を怠った
独学ばっかりしてて会社でも誰ともやりとりがなければ誰にも指摘をうけないだろうな

前スレで引数の話を始めにしたが
引数が無い関数のがよく見える
とか言い出しやがった
明らかにレベルが低いというか危険レベルだろ
オブジェクト指向云々の前になぜプログラム言語が制限をつける形で成長してきたのか？
そこからすでにわかってねぇそんなレベルだった
型ってなんで必要なのか？引数ってなんであるのか？グローバル変数ってなんでダメなのか？
そういうところを一つ一つ考えなおさなきゃ次へいけないだろ

俺の周りにはたまたま教えてくれる人間がいたんだけどね

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

注意！！　>>29 = 真性基地外のため、初心者は騙されるな！！！

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

とりあえず
ttp://sdc.sun.co.jp/sunstudio/documentation/ss12/mr/man3cc4/task.3.html
昔のC++には含まれていたtask.h(task library)
今の標準にはない

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

近代的タスクシステムの構築
http://d.hatena.ne.jp/yaneurao/20090203#p1

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

>>32
いい記事だとおも

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

linus先生からのお言葉
http://tabesugi.net/memo/2009/1a.html#152154

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

>>32
どうせなら前スレでボコボコにされたタスク信者のために
明示的な引数の記述についてもコメントしてあげればよかったのにｗ
20090203とか今日だしよｗ
どうせみてんだろ＞やねうらお

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

>>32
>それではタスクシステムは現代においては不要なのかというとそうでもなく、
>成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
> 「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり(以下略)
現代的に仕立て直しても有用性がデバッガの存在という１点のみか。
まずは一番最初にデバッガ完成させないと有用じゃないんだな

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

や　ね　う　ら　お、はじまったな！

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

ここは空気読んでたすくしすてむはクソだ！って言っとけばいいのか？

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

>>31
コルーチンライブラリだね。コンテキストの保存と切り替えしてるね
　Win32APIのFiber
　protothreads
　Luaのコルーチン
　Squirrelのスレッド
　などなど
これらに相当するものでしょ

**名前は開発中のものです。** · 2009/02/04(水) 00:36:43

>>31
へー。C++標準にコルーチンを組み込む動きがあったとは知らんかった
コルーチン＝協調的マルチタスクだから task.h なんだろうね
でもリンク先に「タスクシステム」とか書いてあるし、嫌タスク派に名前が悪いと怒られないか心配だなｗ

検索したらC++トランスレータ時代(1985年頃)のマニュアルが参考文献として上がってたわ
"A set of C++ classes for co-routine style programming"
by Stroustrup, B. and Shopiro, J. E.
in Chapter 2 of the C++ Library Manual
ttp://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_e/doc/ClassesForCouroutines.pdf

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

>>40
＞名前が悪いと怒られないか心配だなｗ

それは大丈夫じゃないかな
複数のジョブを協調的に並行処理・逐次処理する仕掛けになってるから
ユーザーはプログラムの中にsleep()とかを挟みこむだけでおｋ

job()
{
　while(1)
　{
　　…
　　sleep();
　　foreach(…){
　　　…
　　　sleep();
　　}
　　…
　　sleep();
　}
}
sleep()とかを挟みこむだけでライブラリが半自動的にタスクに分割してくれる
コンテキストの保存と切り替えを全部面倒みてくれる。スケジューリング機構も
一応入ってる。>>2とは雲泥の差だよ

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

>>41
そこはただの軽口だから、そんな真面目に説明されてもね
つか君はコルーチンを説明するフリをして>>2をけなしたいだけだろｗｗ別にけなしていいけどさｗ
まあストラウストラップ先生の書いたクラス群はシステムの名に値するみたいだし
今度からコルーチンシステムと呼ぼうかなー

関係ないけどやねうらおは絶対ここチェックしてるよなｗ
やねうらお対ひらしょータスク戦争勃発ｗ

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

やねうらおはこんな場末のスレ、見てないだろ

>>32 は、前スレまでの議論よりずっとずっと先を行ってるから
彼にとってはこんなスレ、見る価値もないんでねーの？

さすがにこれは天晴れと言わざるを得ない

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

>>43
みてないとか嘘だろ
だって「ごった煮」とか前スレ特有の言葉だしてきてるし
わざわざ見てますよアピールしてんだからかまってやれよｗ

でも前スレで話題に上がった引数に関して触れてないのはいただけないな
無視なら「そんなもんは無視」って名言してくれるだけでもスタンスわかっていいんだけど
別にいい悪いも正解不正解もないわけだし

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

>39
protothreadはコンテキスト保存してないよ。

**名前は開発中のものです。** · 2009/02/04(水) 23:51:04

>>32
親切心から、敢えてコメントさせてもらうと・・・

アマチュアゲームプログラマ未満だな。
まともにゲーム製作を経験した人間が書いた記事とは、到底思えない。
これ誉めちぎっている奴の狙いって何なんだろ。
一部の明らかにテンションが違う応援団は、スルーするのが基本なのか？

**名前は開発中のものです。** · 2009/02/04(水) 23:58:11

ほめちぎってる応援団なんてどこにいるんだ

**名前は開発中のものです。** · 2009/02/05(木) 00:10:20

>>46
是非、どこかのブログで反論頼む！

**名前は開発中のものです。** · 2009/02/05(木) 00:31:46

やねう先生の近代的なタスクの話を読んでみたけど、
boost::shared_ptrとかunordered_mapとか実装が近代的というだけで、
やってることは古典的だよね（そういう趣旨だから当然だけど）。
ってことで、Mix-in好きのオレが近代的なタスクを考えてみた。

古典的タスクシステムをupdate巡回リストであると仮定すると、
タスクとはすなわちフレームをまたいだ継続的処理の抽象化だと考えることができる。
継続処理を今風に考えれば以下の３種類に分かれるはずで、
どれが良いかはケースバイケースで異なる。

//（１）毎フレーム呼ばれる古き良きタスク（負荷が小さい。排他処理不要）
class PeriodicalTask {
public:
　　virtual void update() = 0;
};

//（２）コルーチン動作するタスク（負荷は中程度。排他処理不要）
class CooperativeTask {
public:
　　CooperativeTask(size_t stackSize);
　　virtual int call() = 0;
};

//（３）ネイティブスレッド動作するタスク（負荷が大きい。排他処理必須）
class PreemptiveTask {
public:
　　PreemptiveTask(size_t stackSize);
　　virtual int start() = 0;
};

**名前は開発中のものです。** · 2009/02/05(木) 00:32:17

ここでは描画オブジェクトとタスクは無関係だと考えて、以下のクラスを用意する。
無関係とするのは、描画オブジェクトが必ず継続処理を必要とするわけではないからだ。

//描画オブジェクト
template <class DrawContext>
class DrawingObject {
public:
　　virtual void draw(const DrawContext& dc) = 0;
};

描画用リストは CompositeDrawingObject クラスが管理する。
インターフェイスは自明な気がするので省略。
さてゲームの主人公マリオをどう表現するかというと、

//マリオ
class Mario : public DrawingObject<DrawContext2D>, public PeriodicalTask {
public:
　　void draw(const DrawContext2D& dc);
　　void update();
};

このようにMix-inして作る。ここでは PeriodicalTask を Mix-in したが、
マリオの継続処理を CooperativeTask でコーディングしたければそれを選んでも構わない。
PreemptiveTask を選ぶのは明らかにオーバースペックで排他処理が面倒になるが、
やりたければそれもまあ可能だ。

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

タスクと描画オブジェクトが無関係な理由はもう一つある。
例えば以下のように、描画オブジェクトでなくても継続処理をしたい場合があるからだ。

//テクスチャ画像を波打たせるトランジション
class RippleTextureTransition : public TextureTransition, public CooperativeTask {
public:
　　int call();
};

とまあこんな感じはどうだろう。モダンっぽくね？

**名前は開発中のものです。** · 2009/02/05(木) 00:46:05

1,2,3を混ぜたい時はどうするんだ？
単一の巡回呼び出しでは呼べないぞ、それじゃ。

というか、3は明らかに不要だろ。
taskの更新処理は1と2以外にないだろ。

**名前は開発中のものです。** · 2009/02/05(木) 00:48:58

>>49
何か勘違いしているように思える。

(1)に限らず、(2)でも(3)でも毎フレーム呼び出されると思うのだが。

**名前は開発中のものです。** · 2009/02/05(木) 00:53:46

>53
3は論外だが、普通に実装すれば1と2はきちんと呼び出し元に帰るから問題ないんじゃね？

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

>>54
(2)は、1フレームごとに呼び出し元に戻らないのか？戻らないとしたらいつ戻るんだ？

そもそも1フレームごとに呼び出し元に戻すためにcoroutineにしているんだろ？

わけがわからん…。

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

>>52
単一の巡回呼び出しですべて巡回させる必要はないと思う。
もちろん共通のタスクプライオリティを実装して単一巡回にしてもいいのだけれど、
ここではタスクの呼び出し順序に依存しないコーディングを前提としてみた（３はそもそも処理順序を付けられないし）。
んで、今までの慣例的なゲーム開発手法で考えると確かに３は使わないように思えるが、
これから先の開発手法（ＭＴフレームワークとか）もにらんだ話であるし、
「タスク＝フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。
ただ、現状では貴重な資源であるネイティブスレッドを本当に他と同列に扱えるかというと難しいとは思う。

>>53
いや、３はただのスレッドだよ。２は、なんかごめん。確かに混乱するかもなこれ。
call() は毎フレーム（コンテキスト差し替えの上で）呼ばれる関数で、call() の中では yield し続けると思ってくれ。

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

>>56
毎フレームcallが呼び出されるなら、結局呼び出し側(タスクシステム)からしてみれば、
単なるメソッド呼び出しなわけで、その実装の詳細(coroutineで書かれているか/いないか)は
どうでもいいのでは？

だから、(1)と(2)でinterfaceを変更する意味がわからない。
どう見ても共通のinterfaceで良いように思える。

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

>>56
> 「タスク＝フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。

についてだけど、タスクはフレームをまたぐが、少なくとも1フレーム以内に制御はいったん呼び出し側に
戻ってこないと困ると思うのだが。

ID:9DTLfrVWは何かここを勘違いしているような気がする。

そもそもスレッドを割り当てるのは、呼び出し側で制御すべき問題であって、
スレッド一つ割り当てて実行させたいからと言って呼び出される側のタスクが勝手に
スレッドを作っていいわけではない。

ここまではわかってる？

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

>>58
んー、古典タスクの定義にこだわりすぎだと思うんですが
あくまで近代的タスクという思考実験なので・・・
暇な時に簡単な参考実装でも作ってみようかな

>タスクは(略)1フレーム以内に制御はいったん呼び出し側に戻ってこないと困ると思うのだが。
１と２は戻ります
３は戻りませんが、ユーザプログラムはそれを分かって３を使うわけなので困らないと思いますよ

>そもそもスレッドを割り当てるのは、呼び出し側(タスクシステム)で制御すべき問題であって、
スレッドの割り当てはユーザプログラムが制御すべき問題であって、
呼び出し側(システムプログラム側)ではない、という考えでこうなっています。
ＭＴフレームワークではシステム側で各スレッドにタスクを振り分けて負荷の分散を
行っているらしいのでそういう場合は仰るとおりですが、
それを前提にすると１と２も排他処理必須になるのでちょっと複雑になりすぎるかなと。

**名前は開発中のものです。** · 2009/02/05(木) 02:11:55

>>59
> ３は戻りませんが、ユーザプログラムはそれを分かって３を使うわけなので困らないと思いますよ

戻らないということは、そのスレッドは呼び出し側で生成したスレッド
そのまま使い切ることになるのだから、「呼び出し側(システムプログラム側)では
ない、という考えでこうなっています」と明らかに矛盾してるんだが。

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

CreateThread()というAPIがあるとして、誰がCreateThread()を呼ぶかと言う話なら
それはシステム側になると思いますけど、
作成タイミングもスタック容量もユーザプログラムが制御するのだから別に矛盾してないと思いますよう

それより、なんか疑問点を出されているというより粗探しをされている気がする
どうして突っかかられてるのかが分からないなあ

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

>>61
粗探しをしているつもりはないので、疑似コードなり何なりを出してもらえれば
協力はさせてもらうが。

threadというのは生成に時間がかかるものであって事前に作ってpoolingして
おくのが普通であって、stack sizeなんか都度指定されたらpoolingしている
threadが使い回せない。

つまり、(3)でスレッドを割り当てて欲しいときにstack sizeの指定はいらない。
タスクシステムからのupdate呼び出しのなかでスレッドを割り当てて欲しいときに

threadPooler.Run(boost::function(&MyClass::Worker));

とするだけのことではないか？

だから、(3)を、普通のタスク(1),(2)と区別する意味が俺にはよくわからないのだが…。

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

とりあえずどんな問題を解決したいのか明らかにしてからコード書いてください。おねがいします。

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

>>62
なる、プールされたスレッドってのは考えてなかったです

例に挙げられたコードも分かりやすいと思いますが、
とりあえず>>49の方向でそうした実装を取り入れるなら、
PreemptiveTask のコンストラクタがスタックサイズを引数に取らないようにして、
内部的にプールされたスレッドを使い回すようにすると良さげかもですね
それか、必ずプールされているのも都合が悪いことがありそうだから
PooledPreemptiveTask のような新しいクラスにそうした実装を組み込むか
とりあえず、その辺はより実装に近い部分なので、ゆっくり煮詰めていくたぐいの話ではないですかね

１、２、３をそれぞれ区別するのは、使い手側から見た時に混同せず
明確に区別すべきものだからです（コーディング方法もそれぞれ異なるし）
>>62はシステム側の都合から見てるから区別不要に思えるんじゃないかな

>>63
え、おれ？ごめん

ということですいませんが、そろそろ寝ます
敗北宣言

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

近代的タスクシステムの構築(2)
http://d.hatena.ne.jp/yaneurao/20090204

**名前は開発中のものです。** · 2009/02/05(木) 04:12:57

やねうらおの方からきますたｗ

まあ、ゲームオブジェクト管理周りをどうするかは作るもん次第、銀の弾丸なしってことで、
それはプログラマの仕事がなくならないってことで、いい話なんじゃね。

**名前は開発中のものです。** · 2009/02/05(木) 07:42:18

やねも昔ほど強く言わなくなってるな
実は必要無いってもう気付いてるな
そもそもタスクシステム、コーティングの手間しか削らない割に記述の複雑さは一級品だからな
ベタガキで誰でも読めるソースになるならそのほうがいいだろ
長い期間強く組む為には構造は単純でないと駄目なんだよね

**名前は開発中のものです。** · 2009/02/05(木) 07:42:24

>64
1,2,3を混ぜて巡回呼び出ししたい場合というのが存在するから、同一I/Fから呼び出せないと困るぞ。

例えば、全てのtaskにコンテキスト保存が必要では無い場合に一部taskは1で作成するとかな。

**名前は開発中のものです。** · 2009/02/05(木) 17:15:53

>>32
現代じゃなくて近代なのか。ずいぶん遠慮がちに書くのだなぁ。最初から後退戦か
敗北主義を匂わせれば、相手は正面から斬り付けるのを躊躇うはず、という計算が
見え隠れすんなぁ

＞いまの視点(2009年)で見たときに拙著(ASIN:4798006033)にて不足している部分を補足するため

今までは利得がどこにあるのかを決定的に見誤っていた、と白状したほうが高感度アップな

＞成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
＞「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり

それにしてもタスクフレームワークとか鼻クソみたいな造語を作るの好きな人が多いな
ビデオゲーム開発のためのフレームワークなんだろ？
ビデオゲームというのは何かしらの時間ステップで何かしらの逐次処理（数値積分など）を
繰り返すもの。そしてその処理は複数。だから並行処理ないし並列処理することになる
どんなものであれ、その内部でジョブステップ（タスク）が駆動するなんて当たり前のこと
ありふれたこと。むしろないほうがおかしい

なのにビデオゲーム開発のためのフレームワークの看板にタスクを掲げる
つまり【タスク】が他のフレームワークには存在しない特徴でありウリだと思い込んでる

タスクというキーワードに何か特殊な意味・特定の実装（>>2とか）を連想し、それ以外は
タスクではない、という視野狭窄・自己中・ド田舎ルール・カルト信仰が見え隠れするね
つまりタスク厨

タスクというキーワードに対する思い入れの強さ。これは>>2、松浦本ベースの劣化
トンデモ情報による刷り込みがやねうらおにも及んでいた可能性を示唆する

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

何と戦っているんだ？

**名前は開発中のものです。** · 2009/02/05(木) 20:05:59

>>32
＞現代において、タスクシステムを実装するなら、もう少しタスク間通信を抽象化してタスク側から
＞タスクシステムが保持しているlistには直接触れないようにするべきだが

今度は近代じゃなくて現代なのか
はっきり言っちゃうよ。それは時代ではないんだよ。それは開発規模に応じた普遍的な要求なんだよ
例えば大所帯でRPG作るとき、みんながジョブエントリ・タスクエントリのコンテナに直接触れたらどうなる
わかるよな？
15年以上前にはビデオゲームの世界にさえジョブモニタやタスクモニタといったものが存在した
これは汎用機や組み込みシステムのモニタやOS（RTOS）が大昔に進んだ道を踏襲しているに過ぎない

32bit機が登場した頃には中堅どころでさえブクブクと膨れ上がるゲームのボリュームに汲々としており
ジョブを記述するユーザー（スクリプタ含む）にジョブエントリやタスクエントリのコンテナへの自由な
アクセスを許可するなんて蛮勇以外のなにものでもないケースは珍しくなくなっていた
一定以上の規模になればユーザーを中枢から隔離するなんて時代を問わず当たり前のこと
CだのC++だのアセンブリ言語だの関係ない

これを【現代】の流れというなら、それはやねうらおの内なる世界における歴史的系譜を辿る際に
現代の1ページに登場するとある事変に過ぎず。やねうらおの個人的出来事に過ぎない
『やねうらおの歴史　～やねうらおの近代そして現代～』というタイトルで出版したほうがいい
みんな買うよ

**名前は開発中のものです。** · 2009/02/05(木) 21:33:53

ID:tABpRsfLはなんでそんなに日本語が不自由なの？

**名前は開発中のものです。** · 2009/02/05(木) 21:44:34

タスクというキーワードに対する思い入れｗｗｗ

**名前は開発中のものです。** · 2009/02/05(木) 21:48:23

やねが今回タスクシステム（なにそれ？）を語りだしたときに
それがどういう規模のゲーム開発のお話なのか、という部分には
一切言及しなかったよな
この手のお話には必須の大前提なんだけどバサーリ省いた
あらゆる規模にタスクシステムとやらいうものが適用するメリットがあると
考えてるんだろうかね
もうこの時点で彼のタスクシステム（はぁ？）論は敗北確率急上昇だろ

とても残念だ

少人数・ないし一人のプログラマによる小規模開発ではベタ書きのがいい
彼の言うタスクフレームワーク（あ？）とかいうもの。こいつを構築するために
支払うイニシャルコストがペイできる分岐点ってもんがあるわけ

やねはここを見積もってないんだろうね

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

誰と作るのか。何人で？そいつらの戦闘力はいくつ？期間は？実装対象は？
開発機材は？既存のライブラリとかのリソースは？買っていいの？

こういうファクターを丸無視してコーディングスタイルとか設計の是非を語ろうったって
解なんて出やしない。だからやねがエロゲ作ってるならエロゲ話のことだと言えばいいんだよ

PC用3Dエロゲにおけるタスクシステムの有効性について

とかな。あ、3Dは駄目なんだっけこのオッサン

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

やねうや夫は2Dオヤジだから一般化して語れないぞ

あとゲーム専用ハードのゲーム開発経験もないんじゃないかな

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

やねうらおさんってコンシューマ畑とも縁遠いのか。それは失礼した
DSで死にそうになってるフェードアウトハゲが10年単位の周回遅れで
発明した独自理論を得意げに語ってるのかと思ってた

エロゲの人ならこういう発見もアリなんじゃないかな。煉獄へようこそ

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

>>36
前々スレから散々におわせていたことをようやく認識した
ということだろうね

IDだのハンドル云々の話は10年近く前にファミベのよっしんが記事を書いてる
http://www2.tky.3web.ne.jp/~yosshin/memo/000213.html
アーケードやコンシューマと無縁なやねなら確実に読んでると思うんだけどね
参考リンクとして貼りゃいいのに

よっしん氏が呼んでるタスクシステムという代物と>>2は同一ではないよな
>>2はタスクリストとかいうものを周期的にナメまわしてバッチ処理するだけ
「はいこれでオシマーイ。あとはお前らにお任せだっよーん」みたいなゴミカス
最近じゃこれだけでタスクシステムってことで通用するんだから
タスクシステムはタスクの相互作用なんて気にする必要まったくないわけ
変な通信機能盛り込むなよ

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

>>74
http://d.hatena.ne.jp/yaneurao/20090204
に
> すべてのゲームにタスクシステムが必要なのではない。

はっきりと書いてあるのに

> あらゆる規模にタスクシステムとやらいうものが適用するメリットがあると
> 考えてるんだろうかね

とは、とても残念な理解力ですね。

**名前は開発中のものです。** · 2009/02/05(木) 23:15:47

>74
> 彼の言うタスクフレームワーク（あ？）とかいうもの。こいつを構築するために
> 支払うイニシャルコストがペイできる分岐点ってもんがあるわけ
> やねはここを見積もってないんだろうね

逆に、一人で開発してるなら何やってもイイと思うけどね。

**名前は開発中のものです。** · 2009/02/05(木) 23:45:46

>12
> update();
> で動くのと
> update(jiki,teki,tama,unko);
> で動くのとじゃ
> プログラムとしては絶対に下のがいい

普通に考えると、visitorに共通コンテキストを持たせてコンテナ内のタスクを巡回処理させる。
引数で渡すなんて愚の骨頂。

**名前は開発中のものです。** · 2009/02/06(金) 00:09:26

>>81
>>12＝スレ主＝基地外が前スレで判明している。触るな危険。

**名前は開発中のものです。** · 2009/02/06(金) 00:12:08

>>81
引数のない関数ってどうよ？
お前、自分が使ってみろって言われたときのこと考えろよ

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

>83
おまえvisitorの意味判ってないだろ。

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

>>84
関係ないね
大事なのは引数で渡すことによって関数無いで変更される恐れのある
インスタンスを明確にすること
お前のような素人はデザパタの前にＣ言語でも勉強しろ
なにせ引数もよくわからずグローバル変数で渡してるぐらいの低知能なんだからなｗ

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

>85
やっぱり判ってないのかw

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

釣りにしか見えない

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

>>86
引数の有効性はわかったかね？

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

>>86
前スレよろしく
今回も俺が特別に教えてあげよう

上のupdate()は関数内で何にアクセスしてるのかまったくわからないが
下のupdate(jiki・・・）はアクセスしてるインスタンスを引数に絞ることができる
（グローバル変数を使わないという規約を守れば）
これによってデータの安全性が保障されるというわけだよ
君のようにコーディングの効率ばっかりとって
引数もわからんような低知能は俺と話すようなレベルにないということがわかったかね？

**名前は開発中のものです。** · 2009/02/06(金) 00:26:08

>88
ここまでムキになるということは、>12=スレ主ってヤツかwww
修正コストとか考えたこと無いんだろうなぁ。幸せなヤツw

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

ID:H1z7Q+5uが噂のスレ主だな
一人だけ極端にレベルが低いのにその自覚なし

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

こらこら、触るな危険といってるだろうに。

**名前は開発中のものです。** · 2009/02/06(金) 00:31:12

>89
> 下のupdate(jiki・・・）はアクセスしてるインスタンスを引数に絞ることができる

笑っちゃうなwww
ということは、ID:H1z7Q+5uはtaskの種類によって引数が変わることが前提か。
もしかしてtask保持コンテナも別に持つ派なのか？

例えば敵タスクがあったとして、雑魚敵Aと雑魚敵Bが異なるコンテキストを必要とする場合とか
考えたこと無いのか？　雑魚敵Ａと雑魚敵Ｂで最小公倍数的な引数を取るupdate関数をつくったら、
それはID:H1z7Q+5uが>89で言っていることと矛盾するって気づかないのか？

**名前は開発中のものです。** · 2009/02/06(金) 00:34:26

残念なスレ主と遊ぼうのスレはここですか？

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

押すなよ！　絶対押すなよ！

**名前は開発中のものです。** · 2009/02/06(金) 00:53:38

>>80
その一人開発ってことは趣味の世界の話でいいよな？
プロの一人開発ったってフリーランスという名のプーでもなければ
自分一人の問題じゃねーし、他と折り合い付けないと会社つぶれるしな
>>2ベースのゲロゲロフレームワークなんて誰も使いたがらないから作らないよ

で、趣味野郎でオナニーフレームワーク？これもあんま意味ないよ女子高生
大多数のパンピースペックの趣味プログラマは無難にサクっとゲーム一本
作りあげる方法を模索する
パンピースペックの趣味野郎がオナニーフレームワークとかいうハマリ道に
進んだら大半は生きて還ってこれん。終わり無きライフワークになるだろ
まぁそれはそれで楽しい人生なのかもね。否定はしない

ゲームではなく部品を作ることに情熱燃やして技巧に走って茨の道へ突進して
何年もの歳月をかけて山篭りして誰にも使われないフレームワークを構築する人生
悪くない。でもその結果が>>2ベースのゲロゲロシステムじゃな。成仏できんの？ｗ

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

96もスレ主じゃね？こいつ本当に頭おかしいんだな。

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

引数君と一緒にすんなハゲ

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

>>98
じゃあ、この残念な引数君にも何か言ってやってくれ

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

引数君がアンチタスクだということは知っているが、前スレ終わりごろの
議論の内容がよくわからん
俺は>>2＝チンカスゴミカス　だと思ってるが引数君とは批判のベクトルが違うようだ
彼は数種類のクラスに共通のインターフェースを与え、共通のコードから呼び出す
というメカニズムを全否定してるのだろうか？だとしたらそれは仮想関数の全否定であり
わけわからん

引数君の主張内容がよく分かってない

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

>>100
>>12

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

あぁ？

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

引数君の主張なら>>12のリンク先を見れば十分わかると思うんだが、わからないのか？

それとも、あんたも日本語の残念な人か？

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

俺は前スレの>>823だ。何なら他の発言も発掘してこようか？

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

引数君の方がまだ技術に近い話をしてる分マシだな。
もしかして彼はひらしょー氏の言うデータと処理の分離を
超まわりくどく主張しているのかな。

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

>>104
前スレ823か。

引数君よりは能力的にマシだということはわかるが、説明がくどく、わかりにくい。

俺はこんな内容の薄い、回りくどい説明を読むのはまっぴらごめんなので、さいなら。

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

ESP能力に問題があるID:1vrKKSIM は
すべてのアンチタスクがスレ主に見える病気を克服するべき

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

超能力能力か

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

くっ…。どうして「お前はバカを克服するべき」って言ってくれないの？
内容の薄い、回りくどい指摘を読むのはまっぴらごめんなので、さようなら

**名前は開発中のものです。** · 2009/02/06(金) 07:38:45

お前等馬鹿は、プログラミングで一番時間がかかるのはどこですか？
と聞かれてコーディングとは絶対に答えないくせに
コーディングの手間ばかり減らすことに執着している
なかなか読めないプログラムってなんだ？
構造が複雑なプログラムじゃないの？
お前等馬鹿は全く逆のことを自己満足のためにやっているオナニストだ
プログラマならせめて理詰めで動けよ
お前等凡人から理性まで抜いたら猿と変わらないだろ

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

>>32
えーと、この人ってイイ歳した何者なの？プロ？パソゲー専門なんじゃない？

＞ビデオゲーム黎明期においては、オールアセンブラで書くことが普通だったので、
＞std::listのような便利なコンテナがあるわけでもなく、技巧的な方法でstd::list
＞みたいなことを実現していただけ

えっえー？この人のいうビデオゲーム黎明期っていつごろのお話なのかな？
70年代？だったらまずZ80アセンブリで>>2を書いてみればいいのに。おかしな人だよ
16bit機時代？intrusiveなコンテナを使った理由がオールアセンブラだから？本当に？

最近は想像だけで昔話を書いても教科書になるのかしら？
どこのゲー専の子が犠牲になるのかしら。ちょっと可哀相ね
知らないことは知らないって言えばいいし、足を使って取材しに行けばいいと思う
んで、頭下げて監修してもらえばいいと思う。このままじゃあんまりだよ

＞古典的なタスクシステムにおいてはタスクに番号(プライオリティ)が振られており
＞番号を指定して特定のタスクのポインタを得ることが出来た

えっえー？つーか古典的タスクシステムってなんじゃい？ファンタジーゾーンなの？

**名前は開発中のものです。** · 2009/02/06(金) 10:34:43

>>111
あんた、何かがしゃべり方がキモイんだけど。

それはそうと、相手は年収何千万もある凄腕のプログラマらしいので、
技術的な反論は是非どこかのブログでやっちゃってください。

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

タスクシステムでグローバル変数使うから駄目だって意見が多いけど、
でも見渡してみると、ウィンドウズのウィンドウだってそういうしくみだしなぁ。

**名前は開発中のものです。** · 2009/02/06(金) 22:07:10

エロゲー製作は大変ナリよ
http://d.hatena.ne.jp/yaneurao/searchdiary?word=%a5%a8%a5%ed%a5%b2%a1%bc%c0%bd%ba%ee

**名前は開発中のものです。** · 2009/02/06(金) 22:31:40

>>113
ウィンドウ同士であまりやりとりしなくてもあの複雑さだぞ
リストコントロール２つを連動させるだけでもやばいくらいの手間
基本的にウィンドウズの作り自体関連がたくさん生まれる処理に向いてない
あくまでも独立した動作が前提

**名前は開発中のものです。** · 2009/02/06(金) 22:36:12

>>113
そう思ったのなら両方とも自分で実装してみて比較検討だ！

でも数千行レベルでは使いやすかったやり方が数万行レベルでも同じように使いやすいままかどうかはまた別問題だ！
そこは注意な！　王道はグローバル変数使わないことだぞ！

**名前は開発中のものです。** · 2009/02/06(金) 23:12:31

また引数クンの登場か。

>93について、具体例を挙げて答えてよ。

**名前は開発中のものです。** · 2009/02/06(金) 23:44:30

>>117
はぁ？何言ってるのかわからない
俺が言いたいのは関数に引数つけろってそんだけだけど？
コンテキスト？は？
そんなもん使った時点で負けだ馬鹿
設計死んでるんだよ
俺の価値観ではそんなもん使った時点で負け
void*となにも変わらない

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

まあ、用は固定でない引数に意味がないんだよね
俺の価値観からすると

**名前は開発中のものです。** · 2009/02/06(金) 23:53:12

>118
> はぁ？何言ってるのかわからない

じゃ、具体的に質問するけど、雑魚敵Aと雑魚敵Bに関係性が出てきたらどうするの？
例えば雑魚敵Aは雑魚敵Bを殺すことがある、となった場合に、雑魚敵Aのupdate関数の引数に
雑魚敵Bのリストを渡すの？

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

>>120
>雑魚敵Aのupdate関数の引数に雑魚敵Bのリストを渡すの？
それをやってはダメ
哲学的になるけど
基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
つまり雑魚敵ＡＢに書くべき処理ではない

このアクションはあくまでも雑魚敵Ａと雑魚敵Ｂが存在する空間で起こったことであって
それをシーンクラスとしたらそこに書くべき処理じゃねぇかな？
オブジェクト指向的にはよ

俺はオブジェクト指向原理主義者（テロリストではないｗ）だけど
基本的にオブジェクト指向を変な解釈をしないとしたら
種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ

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

>121
> 種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
> それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
> そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
> 昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ

今はっきりわかった。キサマはクズだ。

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

>>122
なんでだよ
いいこと教えてやったのに
何がどうダメなのか言ってみろ
勉強になるぞ
なにせ俺は１０年以上もやってんだからな

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

10年以上ワナビー君ですかwww
ヒッキーニートで親のスネカジリ。楽しそうですねwww

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

>>124
不毛な会話したくないんだ
どこがどうダメなのか思ったこと言ってみろ
なんとなく漠然とある自分にとっての常識なんて大抵間違ってる場合が多いぞ

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

>125
雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
20種類くらいなら、RTSとかだと当たり前にいるぞ。

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

というか、どういえばいいんだろう。
あっちのスレでも書いたんだけど、どの処理を誰が担当するかが難しいわけであって、
タスクシステム云々、グローバル変数云々はあんま関係ないと思うんだが。
たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。

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

ヒッキーだが有能なゲームプログラマの発言＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞（越えられない壁）＞＞＞無能な社会人もどきヘタレグラマの妄言

それがここのルールだ。覚えておきな。

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

>>126
そりゃ当然それだけの処理が必要になるだろうね
仮にプログラムの組み方が変わったところで
その数が少なくなることは絶対にないからね

それを踏まえて何が問題？

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

>雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
>20種類くらいなら、RTSとかだと当たり前にいるぞ。
ダブルディスパッチ

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

>>126
その莫大な組み合わせを纏めるかどうかは書く人の力量次第だが、
書く場所としてはシーンクラスが良いのでは？ってはなしだろ。
お前が読解力ないだけ。

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

>>127
全部シーンだろうな

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

>128
ヒッキーで無能はどこにいるんだ？

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

>>132
となると、シーンクラスが肥え太って困る。
モジュール化する何かいい方法は無いですか？

オブジェクト指向ってのは、オブジェクト(リソース)の管理は上手いんだが、
オブジェクトとオブジェクトの関連の記述には向いていないんだよなぁ。

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

>>133
居たら教えてくれ。

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

>>79
どうでもいいけど、やねうらおの文章の引用部分さ

> すべてのゲームにタスクシステムが必要なのではない。

これ文脈読めばわかると思うけど、規模じゃなくて種類の話だよね
あと、残念な○○っていう表現が大好きなブログがあるよね

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

>>134
ないね
オブジェクト指向ではそこが限界
原理主義者の俺が言うんだから間違いない
後はＣ言語風味にうまく分離して書くしかない

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

>137
> ないね

単にモノを知らないだけだな。

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

>>127
衝突したかの判定はシーンクラスで、衝突に伴う処理は
オブジェクト同士のメッセージ交換ってのが俺のやり方だな。

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

>127
物理エンジンで本物っぽく動かすつもり？
それとも2Dのマリオやソニックみたいに、それっぽく動けばいいの？

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

>>138
関連をオブジェクトに見立てて・・・とか馬鹿なこと始める気？
俺、そういうの読み手にわかりにくくなるだけであんまり意味ないと思うぜ
折角オブジェクトが誰にでもわかる表現にするためにオブジェクト指向を使ったのに
変にトリッキーな解釈（関連＝オブジェクトだ！）してわかりにくくしたら
本末転倒じゃね？

って勝手に関連＝オブジェクトの話するだけこいつ馬鹿だなー的
先読みをしてみたけど言いたいことあってる？

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

でもちょっとまって。
この流れでいくと、タスクシステムで行うべきことは、
・描画順序の管理
のみ、ということになるな。
その他の処理はすべてシーンクラスで行うと。
晴れて、タスクシステム＝グラフィックエンジン
ということになり、みんな幸せになると。

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

>>127
俺なら重力は重力クラスが担当、衝突は衝突クラスが担当するようにする。

重力に引かれたい奴は重力クラスに登録するように！

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

オブジェクト指向的には、当たり判定は関連をクラス化すればおｋ

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

>>127
石に重力が働くというのなら地面みたいなものがあるはずだから、
石ー重力ー地面としてこの重力をクラスにすれば使いまわしも出来ていい

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

>143
つ【オールドタイプの魂】

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

>>121
＞基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
＞雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
＞つまり雑魚敵ＡＢに書くべき処理ではない

YES

＞それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？

シーンでも神でも何でもいいけど、ゲーム世界の物理現象の調停者ｗが
介在し、結果を双方（作用する２体）に通知するというのは全くもって普通
珍しくない

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

ていうか目をさませ
もしオブジェクトが２０種類いてそれぞれが関連をもつとしたら
少なくとも
a=オブジェクトの状態の数の総和
aC2（aの中から２つ選んだときの重複のない組み合わせだっけ？）
の数だけ処理を書かなきゃいけないことには
どう組んであろうが変わりはないんだぞ

>>147
なんのメリットがあってそんなわかりにくい書き方をするんだ
無駄だろ

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

あ、aC2じゃ同じオブジェクト同士が抜けてるなｗ

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

>>145
重力をクラス化するのは個人の趣味だろうが、
使いまわせるかどうかは怪しいな。

細切れの小さなクラスが1000個ぐらいあって、
それぞれにそれぞれが関係しあって一つの生態系をなし、
結果としてゲームになっている・・・とか。
そういうのって想定外の仕様変更には弱いからなぁ。
まぁゲームの方向性にも寄るのだろうが。

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

>>148
ゲームワールドをゲームエンジン内部で時間発展させてるからさ
衝突イベントでユーザー定義のコールバック関数が呼ばれるやつだ

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

>147
普通に考えてそれか。

じゃ俺も普通に考えてみるかな。

雑魚敵Aが雑魚敵Bを攻撃して殺す場合、Aは攻撃判定用不可視オブジェクトXを作成する。
BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。

攻撃判定用不可視オブジェクトを必要に応じて複数作り、それぞれ攻撃する側はそれを作成し、
攻撃を受ける側はそれに対する応答処理を書く。

シーンクラスには、雑魚敵コンテナと同じレベルで攻撃判定用オブジェクトのコンテナを追加して、
そこで相互の判定をする。

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

>>151-152
いや、だから全然わかってねぇな
なんかお前等変な組み方してるけど
関連の処理を仕様である分、全部書かなきゃいけないことは変わらないんだろ

なんでわざわざ間になんか挟むの？
なんか得になんの？金もらえんの？
素直にシーンオブジェクトに必要な数だけ処理かけよｗ
何をどうしたくてそんな複雑な仕組みにするんだｗ

オブジェクトＸなんていきなり見てお前のそれ誰が理解してくれるんだよ>152
どうせドキュメントもかかねぇしよまねぇだろ
っていうか手間増やしてるしｗ

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

>>152
不可視オブジェクトXの受け渡しは誰が行うんだ？

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

ちなみに俺はオブジェクト指向原理主義者であると同時に
Ｃ＋＋をはじめとするオブジェクト指向言語が大嫌いなんだ
だってなんのメリットもねぇよこの言語ども・・・ｗ
だってよ・・・処理が集中・複雑化するのってシーンクラスみたいなところであって
別に個々にオブジェクト単位にできる部分は誰も苦労してねぇよマジで

ってみんなにはないしょだよｗ

ってところで>>147につけたレスは内容まちがってたな俺
すまんこ

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

>153
> なんでわざわざ間になんか挟むの？

雑魚敵が増えた時の修正が少なくてすむ。
攻撃判定オブジェクトを間に挟むことで、複数種の雑魚敵が同属性の攻撃だしても、一つの攻撃判定オブジェクトとの
関連処理に還元できる。

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

>>150
使いまわすってのはコード的にって事ね

数が多い場合は面倒くさいけど一個一個やっていくしかないなぁ
上位概念のオブジェクトを作れるんであればいいけど
STGでいうなら弾 - 衝突 - 敵では無くて自機 - 弾判定 - 敵みたいに

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

>>152
＞Aは攻撃判定用不可視オブジェクトXを作成する。

そう。AABBとか、高速飛翔するならカプセル、線分を空間上に射出するわけだ
Xがそのうちどっかのバカに命中（得点ゲット）したときの通知が欲しけりゃ
おまえらの大好きなオブジャーバーパティャーンでXにAを登録するやつだ
subjectはX。observerはA

＞BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。

まぁ、何かが自分に衝突したら呼ばれるコールバック関数（オブジェクト）を
登録してるわけだから、その中でユーザー独自の死ぬ処理を入れるわけだ

炎を吹いて墜落するなり、爆発四散するなり好きに振舞え

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

>>156-157
>雑魚敵が増えた時の修正が少なくてすむ。
だからならないって
必ず仕様の分だけ処理かかなきゃならないんだよ
（それが汎用デフォルト処理に挿げ替えられるかどうかは別として）

>使いまわすってのはコード的にって事ね
コード的なんて気にすんなマジで
関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
３０回コピペして終わる程度の使いまわしなら３０回コピペする気でいろ
そのぐらいでちょうどいい

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

>>155
いや確かにそのとおりだと思う。
ただ、シーンクラスみたいなところに処理が集中するのは、
ゲームにオブジェクトとオブジェクトの関係が多いからだと思う。
一般アプリやツールは、リソースの管理がメインなので、
オブジェクト指向も役に立つのだろう。

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

ID:lLkuERdrはド素人だろ。こんなクルクルパーは相手にするだけ無駄。

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

>159
> >雑魚敵が増えた時の修正が少なくてすむ。
> だからならないって
> 必ず仕様の分だけ処理かかなきゃならないんだよ

新規雑魚敵が今までの他の雑魚敵と同じ攻撃を出すのなら、それと同種の攻撃判定オブジェクトを
作成するだけで終了。

オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。

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

>>160
一般のアプリだって同じだよ～ｗ
絶対にボタンとかツールバーの処理なんてウンコぐれーだろ
メイン画面の処理の強烈さといったらない
メインに集中してなくても絶対にどっかに偏るｗ（ツールウィンドウとか・・・）
部品は平均２００行程度しかないのにメインで１０万越えで放置されてるソースとか多いぞｗ

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

>>146
もれなくリストに登録しておいた。

>>121
もしBがAに殺された時、「うわああああ！」って悲鳴を上げるなら、
その悲鳴を上げる動作はBでやるべきだと思う。
AがBを殺した時、「やっほお！！」って喚声を上げるとしたら、それはAが行うべき内容だろう。

シーン（あるいは調停者）がやるべきことと言ったら、Bに対して「お前はAに殺された」ってメッセージを送ることと
Aに対して「お前はBを殺した」ってメッセージを送ること。

なんかややこしくなってきた。
皆えらいわ。

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

>>158
今、攻撃判定用「不可視」オブジェクトXって言ってるのだから、
弾をXにしてしまうと、弾が不可視になって困る。
弾が飛ぶってのなら、弾は普通のクラスにすべきだろう。
で、弾と雑魚敵Bの間で攻撃判定用不可視オブジェクトXをやり取りする・・・と。

なぜインターフェイスでやらないのか。攻撃判定用オブジェクトとか馬鹿げてるよ。

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

>>162
>オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
基本的にはそうだと思ってるし、そうでなければおかしいと思ってる
第一、お前が書かない処理はどうなるんだ？
プログラマならこれが答えられなければダメだろ？

それとお前がしてるのはあくまで仕様の話であって設計の話ではない
決まっていない仕様をむりやりプログラムの仕組みで解決しようとしている
必ずすべての組み合わせ分の関連を把握するべき
その上で共通な処理を共通であるように書いたらいい
（デフォルトを「何もおきない」としたら何も書かなければいい）

ちなみに俺はオブジェクトごと必ず関連をすべて書き出している
雑魚敵Ａｘ雑魚敵ＢがいたとしてＡのステータスが３種類、Ｂのステータスが２種類だとしたら

　　　Ｂ１　Ｂ２
Ａ１　Ｓ１　Ｓ２
Ａ２　Ｘ　　Ｘ
Ａ３　Ｘ　　Ｘ

Ｘ　はなにもおきない
Ｓ１は爆発
Ｓ２は押される

とかねｗ地道にｗ実際はもっとでかくて多いぞｗゾッとするぐらいな
例えばステータス１から２にうつるときのステータス１－２が問題になったりねｗ
書き出してるっていってもそこまで明確でもないんだよね、それでも見える分ぐらいはやるべきだと思ってる

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

>165
不可視ってつけたのはちょっと余分だったかもな。別に可視でもいいんだ。STGの場合は、
弾という可視の攻撃判定オブジェクトを介して敵と自機が攻撃しあってるわけだ。

例えば格闘ゲームでパンチなりキックなりするばあい、攻撃判定の瞬間だけ拳や足先に
不可視の攻撃判定オブジェクトを作るというのはよくやること。この場合は、その攻撃判定
オブジェクトに『威力』なり『方向』なりの属性を与える。攻撃を受ける側は、その『威力』なり
『方向』なりを攻撃判定オブジェクトが当たった位置と一緒に見て、それぞれのダメージモーションを
再生したりダメージ処理に移行する。

波動拳（のような何か飛び道具）なら、可視の攻撃判定オブジェクトになるだけ。

スクリューパイルドライバー（のような何か近接巻き込み方攻撃）なら、巻き込み範囲を持つ不可視の
攻撃判定オブジェを作って、それにそれぞれへのコールバックを持たせる。当たったらコールバックを
よんで攻撃側・被攻撃側それぞれに対してモーション発動なりなんなりをする。

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

>>165
＞不可視

あ、この部分は見落としていた

>>152は「一瞬で目標に到達するレーザーみたいな攻撃（視覚効果なし）」
を想定してたのかな

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

>166
ガンバレw
努力の人はさすがにすごいと思うよw

学習できない無能はもっとすごいと思うけどねw

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

>>162
だから処理纏めたいときは普通はインターフェイスとか使うの。
オブジェクトのやり取りなんかしない。

class X{ public: virtual void hoge()=0; };
class A : public X{ public: void hoge(){} };
class B : public X{ public: void hoge(){} };

for(int i=0; i<tasks.size(); ++i){
X *x = dynamic_cast<X *>(tasks[i]);
if(!x){ continue; }
x->hoge();
}

とかすれば処理は纏められるだろ。
で、どう纏めるかは問題ではなく、これをどこに書くかが問題なんだ。

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

>>167
格ゲのAABB当たり判定か。把握

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

>170
で、どこに書くの？

間にオブジェクトを介在させる場合は、書くべき場所はひとつしかないけどね。

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

>>166
＞　　　Ｂ１　Ｂ２
＞Ａ１　Ｓ１　Ｓ２
＞Ａ２　Ｘ　　Ｘ
＞Ａ３　Ｘ　　Ｘ
＞
＞Ｘ　はなにもおきない
＞Ｓ１は爆発
＞Ｓ２は押される

あれ。当たり判定表はアリだと思うが…

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

>>172
シーンクラスが良いのではないかということになってる。

>>167
オブジェクトを作るのは、インスタンスを複数にするためであって、
処理を纏めるためではないと思うぞ。

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

>>174
シーンが肥え太る？ゲームエンジン（神）が肥え太ってんだよ

肥え太ったゲームエンジン（神）が作りしシーン
その中での現象に関して肥えた神にお願い・お祈り・お伺いするためのインターフェース
これをシーンが提供してる。それだけのことだ

神と交信するためのインターフェース（シャーマン、イタコ）は色々ある
物理エンジンにしかアクセスできないインターフェースとか
どのインターフェースを使えるかはゲームオブジェクト（アクター）によりけり

あとおまえやねうらおじゃない？睡魔に耐えてたらESPが冴えてきたぞ
外れてたらごめんね。もし当たってたら一言言わせろ
あんたさー知りもしない昔の話を捏造してペラペラしゃべってる暇あんなら
一次情報にアクセスしてきっちり裏取れよな
あれじゃネット発のタスクシステム都市伝説の怪文書がまたひとつ増えただけじゃん
松○とドングリだろ。悔しくないのか？足使えよ足
ネットとか２ちゃんで怪情報かき集めて本書くな

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

アンカーミスだ。>>134な
ばいばい

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

>>175
横レスですまんが、やねうらおに関しては、
遠藤さんとも面識があるみたいだし、
http://d.hatena.ne.jp/yaneurao/20090108
吉村さんとも知り合いみたいだし、
http://d.hatena.ne.jp/yaneurao/20081004
岩谷さんが取り上げるぐらいだし、
http://d.hatena.ne.jp/yaneurao/20060212
彼は2chなんか端っから相手にもしてないだろう。

自分の説が正しいと思うなら是非どこかのブログで
今回の記事に反論してみてくれ。俺はそれを楽しみにしている。

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

今回の記事は魅力ないでしょうよｗ
前スレでタスク信者が詰まってたところ全部無視だものｗ

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

俺はweak_ptr使って実装するっての一つにしても為になったがな
まあ、あの記事から何も学べない奴は学習能力がアレなんだろうな

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

ID:lLkuERdrは10年以上プログラムやってて( >>123 )、
C++が使えない( >>125 )ってぐらいだから、まあ、本当にアレなんだろうけどな・・

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

>>179-180
あんたが複数ＩＤを使えるのはもうわかってるよ
このスレのはじめのほうでもやってただろ？
でもいいの？
あんた自分より賢い人には絶対にたてつかないクズじゃん
俺なんかに噛み付くと反撃が痛いんじゃない？ｗ

**名前は開発中のものです。** · 2009/02/07(土) 04:26:54

weak_ptr とかはもうすでにみんなやってるでしょ。
そこはそんなに。本質とは違うというか。
別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。
全般にわたって高速化のことしか書かれていないが、そんなの正直どうでも良い。
ってのが感想。

**名前は開発中のものです。** · 2009/02/07(土) 04:52:05

>>182
> 別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。

それは、何かweak_ptrを勘違いしてそうだな・・。

OnDeleteTaskのときに、被参照ポインタをどうやって無効にするんだ？

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

>>181
> あんた自分より賢い人には絶対にたてつかないクズじゃん

それは、俺を他の誰かと勘違いしてねーか

俺はC++わからないとか、デザパタわからないとか、
そんなド素人と話しても得ることがないから、そういう奴とは話さないだけだよ

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

>>183

class my_task : public task
{

task *m_ptask1;

public:

virtual void OnDeleteTask(task *ptask)
{
if(m_ptask1==ptask){ m_ptask1=NULL; }
}

};

**名前は開発中のものです。** · 2009/02/07(土) 05:15:04

>>185
ああ、言わんとしていることはわかったし、あんたはまともなプログラマに属すると言えるとは思うが、
そのコードだとオブジェクトの削除はO(N^2)になるよな。

俺の現場ではそんなコードは全然現実的じゃないんだが。
あんたは本当に数万オブジェクトの出てくる規模のゲーム書いたことあるの？

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

ただ、これらの話題で絶対出てくるのが、
オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。

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

もちろん185の実装は別に間違っちゃいないので、俺の183は発言を撤回する。
185があまり良くない実装だと理解した上で確信犯的にやっているんだろうから。

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

>>187
> オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。

(そういう議論が発生するのはわかるが)それは、変じゃないだろう。
被参照ポインタの無効化というのは、そもそもそういうものだから。

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

>>186
まぁ10000も出すとなぁ・・・
ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
つーか、10000もオブジェクト出すって、何のゲームよ。

**名前は開発中のものです。** · 2009/02/07(土) 05:54:06

>>190
> ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。

weak_ptrと同性能のものを自前で書くだけでも結構大変だと思うがな。
少なくとも現場のプログラマがやるのは時間の無駄で車輪の再発明以外の何物でもないと思うのだが。

> つーか、10000もオブジェクト出すって、何のゲームよ。

いまどきの3Dのゲームでは、足や手のパーツごとに接触判定を持っていて、それぞれのパーツが
独立していて、それぞれがC++のオブジェクトになってたりするのだが。

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

いや、ま、どういうか。
再発明だろうがなんだろうが、あまりどうでもよくて、
要するに、そういうところで困ってる人はいないだろうと。

余談だが、
そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。
昔weak_ptrのようなものを使ったコードも書いたことがあるが、釈然としなかった。
だって、lock出来るときと出来ないときでコードが分岐するなんて、変だ。
そういう仕組みに頼ってると、オブジェクトの所有権がどこにあるのかわからないコードになりがち。
オブジェクトは作ったやつが削除すべきという結論に達したが。。

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

>>192
> そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。

そんなことはない。

シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
子分は親分のポインタを保持していてはいけないのか？違うだろ？

そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。

**名前は開発中のものです。** · 2009/02/07(土) 06:49:26

>>192
> オブジェクトは作ったやつが削除すべきという結論に達したが。。

これも全くのでたらめ。

シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
ボスはザコより先に逝っちまうことがあるだろ。

ザコから参照されているからボスはいつまでもオブジェクトを解放しないのか？違うだろ。

オブジェクトの所有者は、そのオブジェクトを生成した奴(ボス)にあってはいけないんだ。
もしそう設計しているならそれは設計上の誤り。

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

>>193
>シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
>子分は親分のポインタを保持していてはいけないのか？違うだろ？

>そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。

親分も子分も、シーンクラスが管理すればよい。

>シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
>ボスはザコより先に逝っちまうことがあるだろ。

なぜボスがザコを生成する必要がある？
シーンクラスがザコを生成、削除すればよい。

Cのmallocにはweak_ptrのような仕組みは用意されていないが、世のプログラムはちゃんと動いている。
windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
なのにゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
だけど止めはしない。weak_ptrをつかってゲームを書いてみるといい。きっと後悔するから。

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

>>195
> 親分も子分も、シーンクラスが管理すればよい。

うわ。それはひどい。なんか、またド素人と話している予感。

子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
どんな依頼コードを書くの？それ書いて見せてくれないか。

> windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。

何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。

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

シューティングでボスとザコが居て、ボスとザコが何故か紐で繋がってたとする。
紐の管理はボスとザコのどちらですべきか？

答えはどちらでもなく、
ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。

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

>>195
> ゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。

「ゲームではweak_ptrに頼らざる得ない」なんて俺は言ってないからな。

weak_ptrを使えば簡単に書けるものを、馬鹿が車輪の再発明したり、weak_ptrを知らないがために
複雑な設計になっていたりすると言ってるだけなんだが。

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

>>197
> ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。

まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は？

**ID:XPRCk6pD** · 2009/02/07(土) 07:40:43

ID変わってしまったけど、俺がID:XPRCk6pDな。

>>子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
>>あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
>>どんな依頼コードを書くの？それ書いて見せてくれないか。

依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大親分クラスを作って
そっちで管理する。

>>何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。
ハンドルは同じ値が再利用される可能性もあるわけで。