タスクシステム

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 01/20 07:30 / Filesize : 258 KB / Number-of Response : 798
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

タスクシステム

1 名前：名前は開発中のものです。 [2010/10/01(金) 19:54:53 ID:ZGMtyIlk]: タスクシステムで～す。
94 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 01:05:01.29 ID:4mf44gCT]: >>93
レベル（ステージ）毎に必要な型のforeachを実行する関数を用意するわけか。
レベルデザイン時の柔軟性が失われないか？
もしくは全ステージで同じ型出すと、ステージ色が失われないか？
95 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 06:56:47.84 ID:+MWn67Ig]: コールバックさせるupdate関数の引数が固定になる方が柔軟性が損なわれる。
96 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 09:34:01.98 ID:vhjBYDIv]: そうだよな
必要な情報ってオブジェクトごと違うのにそこをわざわざ統一しちゃうのは
逆に必要な情報が関数みてわからなくなっちゃう
ホーミングミサイルで更新にターゲットが必要ならそれが必要な情報とわかるように
むしろ引数で明示するべき
その情報がなければこの関数は実行できないよと

これがプログラムの基本なんだよ
97 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 19:39:44.89 ID:8sfW2Qro]: 書泉でゲームプログラムフェアってのやってたから「何とかでつくるシューティング」とか
何冊か立ち読みしたら6冊中4冊でタスクシステムの説明とそれ使ったゲームがのってた。
PHPのやつとAVGの二冊はタスクシステムじゃなかった。
>>92
の言うようにC++とかJavaとかObject-Cとかで実装は別々だったけど、作るゲームにあってるなら
タスクシステム使って。
ポインタや参照使えない言語使う、とかタスクシステムが合わないゲーム作るならほかの方法で実装すれば
いいんじゃないかな。
98 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 19:57:34.88 ID:4mf44gCT]: >>95
書籍で紹介されているタスクシステムでは、個体情報を含むメモリブロックへの参照をメンバに含む
構造体ポインタを引数経由で渡して、個体情報特有の構造体にキャストしている。
むしろ何でもありで、情報のやり取りの柔軟性が損なわれることはない。

>>96
呼ぶ側は呼ぶことしか行わない方が、分かりやすい。
また例で言うとターゲットが存在しない場合の条件分岐を、呼ぶ側にしわ寄せ実装する必要が出てくる。
生存および消滅の過程や、何をターゲットにするかは、対象リストへの広域なインターフェースを用意して、
個体タスク内で自律的に行わせる。
基本と言い切るのは勇み足じゃないか？
99 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 22:03:20.33 ID:vhjBYDIv]: >>98
バッカ
全然関係ない
ちゃんと引数で渡すようにすれば何が何をやるべきかちゃんと見えてくる
なんにも見えないのは年がら年中そうやってオブジェクト同士の関連を面倒だからって
端折ってるからなにも分析できないなにも進歩しない
100 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 22:58:45.25 ID:8sfW2Qro]: 書籍にソースコードを全て載せるぐらい小さいゲームや、iphoneとかandroidのミニゲームみたいに
ゲームの状態推移がほとんどなくてゲームオブジェも簡単に全て把握できる、みたいなシンプルなゲームなら
タスクシステムのような単純な仕組みで実装する、って判断も十分合理的かと。
どんなアルゴリズムにしろアーキテクチャにしろ、適した用途と適さない用途はあるわけで。
>>99 がどんなハードでどんな仕様のゲームを想定してるのかは本人しかわからないけど
想定しているゲームの仕様には適さないと思うならタスクシステムじゃなくもっとそのゲームに適した仕組みで
実装するのが現実的だと思うけど。
101 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:14:39.10 ID:+MWn67Ig]: 型ごとにリストを用意して、
必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？

引数も関数名も自由に決めれるし、
書いた順に実行されるから、
タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。

タスクシステムってタスクを順番に逐次実行するんでしょ？
でもプログラムって放っておいても逐次実行だよ？
void do_tasks(){ task1(); task2(); }
って書いとけば、それそのものがタスクのリストだよ？
わざわざ動的にタスクのリストを用意して逐次実行する意味ってあるの？
それじゃまるでインタプリタやVMだよ。それも碌な制御構造もない貧弱で直線番長な。
102 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:20:56.58 ID:+MWn67Ig]: 折角C言語やC++にはif文やらなんやらの立派な制御構造があるのに、
タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
言語の持つ折角のメリットを殺しちゃうことになるんだよ？

update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？

動的にタスクのリストを用意するから、
ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。

わざわざそんな茨の道を行く必要は無いんじゃないの？
103 名前：名前は開発中のものです。 mailto:sage [2011/09/06(火) 23:55:38.12 ID:8sfW2Qro]: ＞タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
上であげてるゲームでは実行順のソートとかワケワカラン処理は必要ないケースだし
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
単純なゲームだから引数にコンテキスト渡すだけで解決。

＞ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
ソース2～3個で完結してるようなゲームだし、普通のプログラマなら十分把握できるでしょ・・・

あと、タスクだと敵出現のシーケンスは、データ読んでその種類のタスク生成してくっつけるタスクの原理を
うまく使ったシンプル実装。
これを逐次駆動でタスクよりシンプルに実装できるのかな？
タスクの方法より短くシンプルなコードでSTGの弾、エフェクト、敵AI切り替え、ボス、敵のシーケンス化、等々を
実装できるのならその方法でもいいかもしれないけど・・・
書籍のサンプルでは上記全てタスク実装で1個のソースにして綺麗にまとまってたから、逐次ベタ書きで
これよりシンプルに短くこの仕様全て実装するのは難しいと思うけど。

STGのサンプルの大多数タスクシステムを採用してるのはそれなりに合理的な理由があると思うよ。
104 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:11:57.19 ID:2Lv+in6p]: 実行順のソートが必要ないなら、なおさら動的にタスクリストを持つ必要ないじゃん。
ソースコードにベタでtask1(); task2(); task3()って書いてけよ。
なんども言うけど、ベタで書いたほうが、タスクシステムよりよっぽどシンプルなんだ。
型ごとにリスト用意して、必要に応じてupdateってのは、
名前すら付いていないほど、普通に考えりゃそうなるだろうってやり方。
だから、単純さを武器にタスクシステムを薦めるのは可笑しい。
タスクシステムは、最終ビルド後、製品出荷後で、
後からプログラムを拡張したいときなんかに使われるような、それなりに高度なやり方。
プラグインやMODやドライバなんかで使われる手法。
その必要も無いのに使うものではないんよ。乱用なんよ。コールバックの乱用。
105 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:20:37.44 ID:2Lv+in6p]: list<弾*>弾リスト; list<エフェクト*>エフェクトリスト; list<敵*>敵リスト、list<ボス*>ボスリスト;

foreach( 弾リスト ) { update( 弾 ); }
foreach( エフェクトリスト ) { update( エフェクト ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( ボスリスト ) { ボス->シーケンス(); }

な？簡単だろ？
型情報も殺さないし、引数も自由だ。
106 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:27:04.18 ID:2Lv+in6p]: 複数処理を型に跨って順不同に呼ぶことだって出来るぜ？

foreach( 敵リスト ) { 前処理( 敵 ); }
foreach( 弾リスト ) { 前処理( 弾 ); }

foreach( 敵リスト ) { 敵->AI(); }
foreach( 弾リスト ) { update( 弾 ); }

foreach( 敵リスト ) { 後処理( 敵 ); }

タスクシステムだと言語本来が持つ制御構造を殺しちゃってるから、
こう言うことが難しい。
107 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:31:43.66 ID:2Lv+in6p]: 敵->AI();とか書いちゃったけど、実際には
敵->AI( 敵 );　だな。ごめんごめん。

ついでに。
foreachを多重ループにすれば、相互作用の記述も簡単。
タスクシステムですると破綻しかねん処理だ。

foreach( 敵リスト ) //二重ループ
foreach( 弾リスト )
{
　　当たり判定とか相互作用的なもの( 弾, 敵 )
}
108 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 00:59:04.96 ID:2Oz0OCTe]: 逐次実行の書き方って...本気でこのコードでゲームを最後まで書くっていってるの...？
まぁこー書かないとコード追えないって言ってるから、しょうがないのかもしれないけど...
タスクシステムで実装されたSTGゲームは書籍なりネットなりでいろいろコードみれるけど
この方式で最後まで完成したちゃんとしたSTGのコードって今まで一つも見たことないな。
論より証拠で、どんなものになるかぜひ完成したものを見せてほしいな。
109 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:02:00.30 ID:2Lv+in6p]: 一応書いておくと、話題に挙がった、タスク = ゲームオブジェクトなタスクシステムのほかに、
タスク = 純粋な処理なタスクシステムもある。
一見良さそうだけど、種類の違うタスクを同じコンテナに混ぜ込んじゃうから本質的には何も変わらない。

コンテキストが必要なタスクの場合、
タスクのコンテキスト構造体を作って型ごとにリストで管理。

foreach( タスク1のリスト ){ タスク1の処理( タスク1 ); }
foreach( タスク2のリスト ){ タスク2の処理( タスク2 ); }

コンテキスト不要なタスクの場合、タスク=関数。

foreach( 敵リスト ){ タスク1( 敵 ); }
foreach( 敵リスト ){ タスク2( 敵 ); }

こうした方が良い。
110 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:06:48.32 ID:njRzaK7Q]: >>108
なんでゲームやSTGに限ろうとするの？
ほとんどのアプリが、型ごとにリスト持ってて、必要に応じて更新ってスタイルだよ？
111 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:14:01.19 ID:8h9D8UMl]: >>109
前スレより随分と解りやすくなった
112 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:17:49.74 ID:AZsoDlPL]: 4mf44gCTだけど、みんなのエネルギーもらってるみたいで楽しいよ。

>>99
　繊細なんだな。俺は煽るつもりはなかったんだ。

>>101
＞必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
　いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。

　解決策としては、むしろ以下の方針で、ソースの透明性確保の努力をするべきじゃないか？
１）呼ぶ側の構造をできるだけシンプルにする。
２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
３）個体同士の相互作用のメカニズムを統一して単純化する。
　上の方針を守っている限り、柔軟性のあるいわゆる「タスクシステム」の方が有利だと思うんだが。
113 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:18:43.81 ID:AZsoDlPL]: >>106
＞タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
＞言語の持つ折角のメリットを殺しちゃうことになるんだよ？
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？

　言語の「メリット」「機能」というのが曖昧だな。
　本質ではないかもしれんが、>>106をみると敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
　このように分ける必然性がわからない。
　むしろハードコーディングにより、このように分けてしまうと柔軟なレベルデザインの妨げになるような予感がする。

　あと誤解しているが、書籍などで紹介されている「タスクシステム」は、タスク登録時に優先順位（Priority）により各個体の実行順序を制御できる。
　だから実質的に、同種の個体で実行順序をグループ化することも可能だ。つまりこれまでID:+MWn67Ig / 2Lv+in6pが提起している「制御構造」の問題は解決されている。
114 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:31:29.34 ID:2Oz0OCTe]: >>110
なぜタスクシステムを使うべきでないケースでタスクを使うことを考えるんだろう...
>>100 の前提のとおり、タスクシステムにしろどんな仕組みにしろそれを使うケースは
それが合理的なケースだけ、というのは当然でしょう。

なにか否定している理由は合理的な考えから出たものとは違うみたいなので
これ以上続けても意味のある結論は出なさそうですね...
115 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:35:34.18 ID:njRzaK7Q]: これはもう石頭でどうしようもない。物事を勘違いしたまま突き進んじゃってる。

>いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
ワケワカにならないように、違った型のオブジェクトを同じリストに突っ込まないようにするわけで。
ワケワカでOKってことはないでしょ？

>敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
>このように分ける必然性がわからない。
敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
一回ずつオブジェクトをupdateでなめなめして、それで全ての処理が終わるとは限らないだろ？

>タスク登録時に優先順位（Priority）
それは、違った型のオブジェクトを同一のリストに入れるから必要になる仕組みであって、
苦肉の策であることを分かって言ってるのか？
そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
116 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:46:07.51 ID:njRzaK7Q]: >１）呼ぶ側の構造をできるだけシンプルにする。
物事は上流で解決した方が良い。

>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
言ってる意味が良く分からんが、あえてエスパーすると、メモリアロケートの話ならアロケーターの仕事。

>３）個体同士の相互作用のメカニズムを統一して単純化する。
上流(メインループ部)を直接改造できる状況下においては、
相互作用は上流でするべき。

>>114
逆にタスクシステムを使うべきケースって何？
ああいったコールバックシステムは、
上流部が固定されている場合だけだと思うんだけど。
ゲームはメインループ部を自由に触れるよね？
リリース前なんだから。
117 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 01:46:51.37 ID:AZsoDlPL]: >>115
おい、煽るなよｗ

＞ワケワカ
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
俺はそうなる事態を予見して、解決策を提案したんだが。

＞敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
率直に言うと、複雑な相互作用メカニズムになっているという気がするな。

＞そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
もっと「言語本来の制御構造」のメリットが出ている例を挙げてもらいたいな。

所詮は場末の小競り合いだ。
落ち着いて逝こうぜ。
118 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:02:46.60 ID:njRzaK7Q]: >>117
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
そこにズラーーーと書いてあることが、格ゲームオブジェクトのupdate関数に移るだけだから同じこと。
むしろ、分散されて余計わけが分からなくなる。

>率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
あえて例で上げたまでだからね。
だけど、一回のupdateで全ての更新が終了するとは限らないだろ？

>例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
二回のupdateが必要な場合はどうするの？
a->update1(); →　何かの処理　→　a->update2();
C言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
119 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:10:21.64 ID:AZsoDlPL]: >>116
＞物事は上流で解決した方が良い。
上流のフローは、単純でなければいけない。
その解決策は、先に書いた通り。

＞>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
＞言ってる意味が良く分からん
　生存＝個体がタスクリストに登録されている状態
　消滅＝個体がタスクリストに登録されていない状態

＞相互作用は上流でするべき。
　詳しく。
　レベルデザインの足かせとならないか？

＞逆にタスクシステムを使うべきケースって何？
　確実に言えるのは、メモリリソースが希少な場合だろう。

＞ゲームはメインループ部を自由に触れるよね？
　そんなに簡単にいじれるかな？
　どんな触り方を言ってるのん？
120 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 02:21:42.40 ID:AZsoDlPL]: >>118
＞一回のupdateで全ての更新が終了するとは限らないだろ？
これ具体例教えてもらえないか？

ところで（書籍ででている）タスクシステムでも、（この議論の流れでは反則になるかも知れんが）
ちょっといじれば各個体にupdateを2つ持たせることは可能だぜ。
優先順位を2つ持たせることも可能だ。
メインループで登録リストを2回なめることになるが。
121 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 05:53:24.18 ID:P+KLPKHG]: ひさしぶりにタスクシステムな人が来たみたいだな。
まずは >>2-4 あたりを読んで、それでもまだ何か言いたいんなら、まぁがんばって。
122 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 08:11:32.13 ID:BWfYxSne]: >>105
俺はお前を支持する
こっちのほうが１０００倍楽
タスクシステムの起こすバグはハンパじゃない
123 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 08:21:53.19 ID:BWfYxSne]: >>105に書いてある内容は本来書き並べないといけない処理なんだよ
必要に応じてわかりやすい単位で関数に分けることは必須だけど
これをタスクシステムにしたら実行しないとこの順番がわからないとか
開発がホント酷いことになる

派遣で色々と会社まわったけど
タスクシステムを使わないところはバグの数が１０分の１ぐらいだかんね
タスクシステム使ってるようなところはバグ数がプロジェクトで３万（万？はぁ？）とか
明らかに数字がおかしい
124 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 12:09:48.38 ID:Cw/CE0Hp]: もともとはアセンブラ時代のテクニックだろうよ
CPUやメモリ資源もない時代。
１．ゲームオブジェクトを統一的に扱う。
２．アラインメントを考慮したメモリにやさしい固定長のオブジェクト
３．固定長のオブジェクトを柔軟に扱うためのプロセスアドレスの保持

今の時代は
１は継承で可能。２は資源的にちっとやそっとの無駄は気にしない。
３は今で言うところのメンバ関数とか関数ポインタ。
125 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 12:39:30.24 ID:njRzaK7Q]: 今の時代なら、
>１．ゲームオブジェクトを統一的に扱う。
はテンプレートでしょ。
126 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 17:13:02.56 ID:V+dkRM26]: ジョブコンの説明を確認すればわかるが、非常に単純化されたコルーチンのようなものの
メカニズム、というのが元の姿。
127 名前：名前は開発中のものです。 mailto:sage [2011/09/07(水) 20:57:18.96 ID:njRzaK7Q]: 違った種類のジョブを単一リストで管理する理由はないね。
上流の呼び出し部分が出来合いのもので、
改変が許されないのなら別だが。
128 名前：名前は開発中のものです。 mailto:sage [2011/09/08(木) 01:34:35.91 ID:lvpyEMH1]: タスクシステム大佐：
「私のフレームワークはデリケートにチューニングされている」
129 名前：名前は開発中のものです。 mailto:sage [2011/09/08(木) 01:44:22.92 ID:IMtv8g35]: 違った種類のモンを一端混ぜておいて、
場合によっちゃあ後から分別するんだから間違ってる。
別に扱いたいのなら、別に持っておけば十分だし簡潔。
130 名前：名前は開発中のものです。 mailto:sage [2011/09/10(土) 09:54:25.43 ID:10z5xUck]: >>92 で言ってることが全てなんだろうな
メンバーのスキルが「型固定で全てのフローをコードに直書きしないとソースが読めない」
みたいなレベルの場合はタスクシステムとか関数ポインタ使うとバグだらけで完成しないだろうし。
その場合はタスクシステムは使わないのが正解だろう。

Unreal Engine等の近頃のメジャーなゲームフレームワークの場合はタスクやアクターを使っていて
「敵やアイテムを型固定にしてコードに直書き」なんて作りはありえないけど
プロじゃなくて同人とかなら無理してスキルに合わない方法を背伸びして使わずに
自分のスキルで使える範囲の言語のフロー構造だけで作る、という結論は間違っていない。
131 名前：名前は開発中のものです。 mailto:sage [2011/09/10(土) 23:52:59.57 ID:h48cNNb3]: タスクシステム = 上級者用　？？？
これはこれは。
132 名前：名前は開発中のものです。 [2011/09/11(日) 00:03:27.99 ID:Y7Irx4Sl]: タスクシステムが上級者用なんて、まさかwww
タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ただそんな単純な仕組みでも、つかうと手に負えなくなってバグが直せない、
みたいな超初心者なら、もっと単純な方法で作るのが正解だ。
hello worldの次のステップのプログラマならifとswitchだけ、ぐらいで
つくるのが適切。
133 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:07:30.68 ID:AdyJz/xc]: 俺はタスクシステムに逃げちゃう設計者は根性がないと思うけどね
この構造がダメなのはみんなうすうすわかってんだよ
134 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:41:24.97 ID:P9u9NThf]: >>132
> タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ということにしたいのですね。 >>3
135 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:47:43.20 ID:Y7Irx4Sl]: >>97 のようにタスクシステムを使って最後まで完成されたゲームは
沢山あるから書籍にしろネットにしろタスクシステムのサンプルには困らん。

完成してゲームという最終成果が出ている以上、そのゲームで必要な機能は
満たしているわけだし。

根拠が「根性」で出せるサンプルが foreach～だけ、みたいなのよりかは
採用するにしろしないにしろ、タスクシステムの例の方が参考価値がある。
ゲームを完成させたこともない人の言う「みんながうすうす」って言葉には
正直言ってこれを覆すだけの説得力が無い
136 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:53:21.53 ID:P9u9NThf]: >>135
「タスクシステム」と言って具体的に何のことを指してるのかよくわからないから、
ネットのほうの「タスクシステムのサンプル」をいくつか URL で示してもらえませんか？
137 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 00:57:39.18 ID:Y7Irx4Sl]: >>136
>>92 を見ればその答えがわかると思うね。
その上で疑問に思うことがまだあるなら個別にコンテキストを明示
して聞かないと無意味。
138 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:03:39.39 ID:P9u9NThf]: >>137
つまり「タスクシステム」と言って指しているものは具体的にはわからんし状況によって変わりうる、
ということでしょうか。そんなもの役に立ちませんし「基礎中の基礎」だなんて具体的な技術である
かのように言えるわけないですね。なんかおかしいですね。
139 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:14:44.40 ID:Y7Irx4Sl]: 現実的に多くのゲームで「タスクシステム」と命名されてる構造が使われてるわけだ。
それを「共通じゃないから無意味」と結論するのは勝手だけどその行為もまったく無意味。

参考になるかどうか、現状のコンテキストから判断して適切に参考にして
作るゲームに役立てることの方がはるかに有意義。
140 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:40:32.06 ID:+CByEq1T]: >>138
書籍などで紹介されているもは、タスクシステムの一般化された形態であり、
あとはアーキテクトが、場合に応じて、一般化形態から出発して特殊化するんじゃないかな。

一つのキャラを完成させるために上流も下流もいじる必要があるとなったら、
それこそ到達点が低くなる。
力を注ぐ必要のある要素は、キャラの基本的な出現消失の管理以外に一杯ある。
出来るだけ、いじらなきゃいかんソースの場所減らそうって目的で、
メインループ内を抽象化したのがタスクシステムじゃないか。

一方、上流のタスクシステムのアーキテクチャを改修すれば、当然、下流側への影響は絶大なわけで、
>>133は、ヘッポコアーキテクトが、途中で無責任改修やっちゃった事例なんじゃないか？
そんな奴はフレームワークに何使っても、むしろ何をやってもｗ上手くいかないんじゃないかと想像が膨らむ。
141 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:42:27.37 ID:P9u9NThf]: >>139
そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
後を絶たなくて困るんですが、あなたのいう「タスクシステム」がそういうクソの山とは違うと
いうのなら >>136
142 名前：141 mailto:sage [2011/09/11(日) 01:44:12.94 ID:P9u9NThf]: 「後を絶たなくて」は言いすぎですね。今ではだいぶ稀になってますね。
143 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:48:03.10 ID:Y7Irx4Sl]: >>141
＞そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
書籍や何かでいくらでも簡単に手に入るサンプルをみても全てクソだと思うなら
君がゲームの仕様に適したもっと適切な構造で実装すればいいだけだ。
「僕にはアーキテクトを決める権限は無いけどタスクシステムと命名されたクソしすてむ
で作らされたおかげでバグだらけ（涙）」って愚痴ならご愁傷様としか言えんが。
144 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 01:53:19.19 ID:b4z41GvT]: タスクシステムを一般的に語るなら、要はCなどの構造化言語がgotoを封じたもんだから、それに代わる状態遷移方法が必要なわけ。
そこでメインループというものを一般化し、キー入力イベント、敵の動き、当たり判定などの処理のセットを入れ替えることで状態遷移を可能とした。
でもgotoと同じく各状態への遷移が自由なためにスパゲッティになりやすい。
145 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 04:26:51.67 ID:ZZ/mHUa2]: タスクシステマーのレベルが下がってきてるな。

そもそも、
update(){ task1(); task2(); }と処理を静的に書き並べていくことと、
実行時にタスクのリストを動的に生成して、逐次実行することに、
構造的な差はあまり無い。
ただ、後者は言語の持ってる型や制御構造といった機能を殺す。
アセンブラ時代に考えられたものだから、高級言語との相性は考えられてない。
146 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 13:02:01.02 ID:YqmjwGNN]: >>144 ご大層なもん作らんでも、ごく普通のステートマシンの実装法でいいだろ
147 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 13:28:29.62 ID:b4z41GvT]: >>146
ごく普通のステートマシンってなんだよ。
ifやswitchをメインに構成された状態遷移ならともかく、
関数やクラスのポインタを扱うstateパターンとか、ごく普通のステートマシンのことを
タスクシステムと呼んでタスカーたちは崇め、奉ってるんだと思ったんだけど違うの？
148 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 13:32:34.15 ID:ZZ/mHUa2]: 全然違うね。
ステートマシンであることと、ごった煮リストであることは、なんら関係が無い。
149 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 15:36:06.08 ID:Y7Irx4Sl]: >>144-148
つ >>135
タスクシステムでそのゲームに必要な仕様を全て満たして完成されたゲームが
現実に多数存在する以上、せめてタスクシステムで作られたのと同じゲームを
別の実装で全て移植してみてそのコードの優劣を比較、ぐらいやらないと
根拠がお花畑すぎてちょっとなぁ・・・

童貞がリア充に女の口説き方を説教してるみたいで見ていて痛々しすぎる。
童貞のリアリティの無い妄想レベルのupdate()～みたいな程度の低いサンプル出されても
経験のある人間からしたら「ああ、この人一度もゲーム最後まで完成させた経験が無いんだなぁ」
ってバレちゃうだけ。
150 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 16:27:01.31 ID:YqmjwGNN]: PHP信者が必死で主張する「PHPをdisるべきではない理由」にそっくりだなw
151 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 20:10:56.36 ID:b4z41GvT]: ごった煮システムを別の視点から見ればそれはステートマシンそのものであり、
一つのシーンを形作るタスクのセットを入れ替えることで状態を表現する。
152 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 20:21:21.31 ID:ZZ/mHUa2]: 副作用を許すような、普通のプログラム、普通のプロセス、普通のゲーム、は、
それ自体がステートマシンそのものだろ。ごった煮リストであるかどうかは関係ない。
ごった煮リストってのは、型関係なく、単一リストに何でもかんでも入れてる状態。
たとえ型や種類ごとに綺麗に整理整頓して分けてリストに入れていたとしても、
ステートマシンはステートマシンだわな。
153 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 20:33:46.30 ID:ZZ/mHUa2]: >>149
タスクシステムは全てのタスクを単一リストで管理するけど、
それを複数リストに分けろと言っているだけなんだから、
これが可能であることは、プログラマなら誰でも分かるわな。

タスクシステムで書かれてないゲームも多いぞ。
とくに海外製のゲームなんかはベタで書かれていることが多い。
気になるんだったら、探してみたら？

というか、何かリストで管理しようとしたとき、
型ごとにコレクトしていくのって、割と普通じゃないか？
型によっては木構造とかで管理したいかもしれないし。
画一的に全てを同じタスクリストで管理ってのはどうかと。
154 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 20:57:08.72 ID:b4z41GvT]: タスクシステムはゲームに特化した状態管理の枠組みや方針、レイヤー、仮想環境ともいえるものを提供する。
155 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 21:35:33.06 ID:Y7Irx4Sl]: >>153
＞タスクシステムで書かれてないゲームも多いぞ。
わざわざ海外のゲームなんて探さなくても大昔のベーマガ時代から
ベタで書きなんて珍しくもないよ・・・
数当てゲームとかね。
しかし、>>92 >>97 あたりに書いてあることをほんとに何一つ理解できてないんだねぇ
コンテキスト依存で実装考えるって当然のことを理解できる知能があればそんな
見当違いなこと言い出さないはずだけど。
まぁ、それをその当然のことを前提にしちゃうとどう見ても勝ち目が無いから
馬鹿のふりして話題そらして逃げてるんだろうけど。

ちなみ海外と言えばUnreal EngineやCryEngineのactorはタスクのごった煮とやらと
本質的に同じ。型固定でifとswitchだけ、なんて牧歌的な作りは影も形も無いけど、
それについてはどんな逃げ方をするのかな？また話題そらし？
156 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 21:40:28.61 ID:YqmjwGNN]: 偉そうなタームを並べちゃってw

現代言われている「ゲームエンジン」が、もはやタスクシステムとはぜんぜん違う
ものであることには目をつぶって「あれもこれもシステムだもん」とかw
157 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 22:13:11.16 ID:Y7Irx4Sl]: 結局その逃げ方しかできんのか。つまらんな。
taskもactorも逐次実行じゃないよ？ほら？どうした？ｗｗｗ

タスクシステムとはぜんぜん違う？どのタスクシステムとは違うのかな？
AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の
ゲームエンジンに本質的な違いがあるならその違いを言ってごらんよ。
158 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 22:54:47.89 ID:Ynk6BT3o]: その前にタスクシステムは普通の書き方のなんの問題を解決してるのか聞いてみたい
単に面倒なだけだと思うんだけどｗ
159 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:14:25.45 ID:Y7Irx4Sl]: 形勢不利だから話題そらしで逃げるつもりみたいだけど残念。
>>157
の答えを早くくれないかな。
actorが逐次実行なのはいいのかな？ゲームフレームワークも全否定？
タスクとゲームエンジンの本質的な違い、「ぜんぜん違う」と断言できるなら当然答えられるよね？
160 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:15:43.66 ID:QoX0R0+Y]: 皆が話してる「タスクシステム」って何なの？
161 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:17:28.01 ID:YqmjwGNN]: それは本質ではない、という逃げは万能だもんな。
はいはい、あんたの勝ちですよw
162 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:21:28.73 ID:Y7Irx4Sl]: ＞あんたの勝ちですよw
典型的だなｗｗｗ
「もう来ねえよ!ウワァァン」が足りないぞ？
163 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:47:35.30 ID:Ynk6BT3o]: >>160
ごった煮リストにインスタンスをすべてぶち込むシステム
なんだけど
明らかに取り出すときにそのぶち込んだものがなんであるか判定する必要があってやたらと面倒なんだ
しかもバグる
実行順序も制御きかねぇし
164 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:50:22.61 ID:ZZ/mHUa2]: 俺に言わせりゃ、actorなんか使うのはアホだけど、
それでも、フレームワークが社外製で、
メインループを触ることが出来ないっつーんなら、仕方ない。

ちょうどOSのウィンドウやドライバがそうなっているようにな。
新しいアプリやドライバ書く度にカーネル触って再コンパイルってわけにはいかないからな。
どうしてもコールバック前提の非同期処理になる。

だから、メインループ部に改変不可なフレームワークを導入するのはお勧めできないな。
メインループはゲームに合わせて自分で書いたほうがよい。

描画エンジンやサウンドエンジンや物理エンジンは外部ライブラリに任せてしまえば良いけどね。
165 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:50:44.67 ID:YqmjwGNN]: 典型的な勝利宣言バカだろ、おまえが
166 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:55:56.92 ID:Ynk6BT3o]: >>164
え？お前んとこって全部追加部分はdllかなにかで書いてるわけ？ゲームなのに？
そうでないならタスクシステムはいらないっていってる？
なんか特殊じゃね？
167 名前：名前は開発中のものです。 mailto:sage [2011/09/11(日) 23:57:25.94 ID:Y7Irx4Sl]: >>165
＞はいはい、あんたの勝ちですよw
なんてみっともない白旗自分から上げといて
もう一度参上できるとはすごい勇気だね。
普通ならとても恥ずかしくて出てこれないよｗｗｗ

で？答えは出た？ｗｗｗ
168 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:04:11.07 ID:1pUHEh9P]: >>163
実行順の制御は出来る場合が多い。
ただ、普通にtask1();task2();って並べて書いてくのと何も変わらないし、
ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
if文やfor文といった高度な制御構造を持てない直線番長だし、
高級言語では当たり前の機能の型も死ぬし、
実行効率もベタで書いたコードより速い訳ではないし。

>>158も言っている様に、ここまでの話の流れで、
だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
まったく使う理由が無い。
169 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:06:20.63 ID:k+/jcxg5]: > だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
> そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
> まったく使う理由が無い。

それなのに >>167 のように完全に勝ったつもりでいるんだぜ？
キチガイここに極まれりだな。
170 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:10:36.54 ID:0e8x3TnW]: >>135-161
で見事なまでに完全論破してるね・・・

型云々とか逐次実行とか言ってるのは >>157 に答えられない以上
惨敗確定だｗｗｗ
171 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:17:43.46 ID:k+/jcxg5]: どこが？
172 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:53:29.75 ID:C74P2jTs]: >>155,157
Unreal Engine の Actor ってのはこれでいいんかな？
udn.epicgames.com/Three/ActorTicking.html
udn.epicgames.com/Three/ActorComponents.html

クラスの必要性がちゃんとドキュメント化されてていいね。いつ使うべきか、使わないで
いいのはどんな場合か、ちゃんとわかるだろう。

少なくとも、必要性やメリットを問いただすだけで荒れるような「タスクシステム」とは
まったく格の違うものに見える。
173 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 00:56:51.96 ID:C74P2jTs]: >>157
> AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の

さらっと流しかけたけど、これマジか？どの本にそんなの載ってるの？
174 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 01:26:30.29 ID:1pUHEh9P]: >>172
俺的にはタスクシステムと同じかなー。
個人的にはこう言う仕組みってあまりメリット感じなんだよね。
それでも規格とドキュメントがしっかりしている分、ずいぶんマシだけど。
175 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 08:40:01.46 ID:k+/jcxg5]: ttp://tatsu-zine.com/books/squirrel/pages/interview2
なんか、どんなもんでもタスクシステムだと言っちゃえばタスクシステムだ、
みたいなこと言ってるなw
176 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 08:40:33.34 ID:c30nkSHj]: 意味不明なんだよ
だってごった煮にしたから各update側には余計なもんが流れてくるから仕分けしないといけないし
一旦まとめる意味がまったくない
論破とか言われてもこの事実が覆る情報なんて一つも出てないじゃん
だからオナニーなんだろ？(笑)
正直に僕のオナニーを見てって言えよ
177 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 09:40:05.43 ID:r2WqQWWe]: アセンブラ時代にフレームワークとして、
自前でちょっとこーいう枠組みを用意しちゃうよ、ってんなら理解できる。
だってそこには、型も、クラスも、リストも無いんだから。
178 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 17:07:09.89 ID:Q2UPSfzC]: ポインタ覚えたてのころにやると、何か得体のしれない黒魔術みたいでカッコいいじゃん
よく分からん…けど動いたスゲーって感じで
>>2のTCBは子供騙しでありロマンだよ
179 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 21:27:03.15 ID:0e8x3TnW]: タスクシステムとUnreal Engine の actorの違いはドキュメントの有無。
ドキュメントがあるぶんactorの方がはるかにマシだが両方ごった煮には変わりないのでどちらもメリットは理解できない、と。
で、taskにしろactorにしろメリットがわからない、といってる人の目から見るとそれが何で動いてるのかわからない
何か得体のしれない黒魔術のように見えている、と。
で、ifとswitchだけ使って全て逐次実行でベタ書きしないとバグだらけになって作れないと主張している、と。
まとめるとこんな感じになるな。
180 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 21:43:17.91 ID:JVPxlqK+]: Unreal Engineはレンダリング、コリジョン探索の両方を扱う枠組みを与えてくれるんだろ？
しかも、それぞれにしっかりした実装があるってんならメリットはまさにそれのことだろう？

自力でレンダリングや衝突を頑張っても、わりと汚くなって性能なんてお粗慢なんだから。
181 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 22:19:19.23 ID:0e8x3TnW]: レンダリングやコリジョン探索を扱う枠組はUnreal Engineの一部ではあるが
アーキテクト上actorとは別階層の話だ。
レンダリングやコリジョン探索の実装があるならメリットは理解できる、というなら
同じようにタスクシステム上にレンダリングとコリジョン検索を扱うフレームワーク実装があれば
そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？
182 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 22:33:43.32 ID:JVPxlqK+]: ん？

> そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？

いいのかね？　と言われても…。タスクシステムだろうと、Unreal Engineだろうと、
それ以外のなんかであろうと、一定の評価を得たライブラリの実装があれば、
それは評価できるし、使えるんならメリットだろう？　それだけのことを言ったつもりだが。

ちなみにこのスレで発言したのは>>180が初めてだよ。
183 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 22:40:22.91 ID:0e8x3TnW]: ほう、これが初めての書き込みね。そーいうことなら大変失礼。
ま、普通の人間はメリットについて当然そう考えるわな。
＞普通にtask1();task2();って並べて書いてくのと何も変わらないし、
＞ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
とかでtaskもactorも全てメリットが無い、みたいな考えをするアレと一緒にされたら
誰でも不快だよな。大変失礼、謝るよ。
184 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 23:02:21.91 ID:1pUHEh9P]: といいつつ、メリットは書き込まれない。一度も。
185 名前：名前は開発中のものです。 mailto:sage [2011/09/12(月) 23:10:27.89 ID:1pUHEh9P]: 例えば、レンダリングエンジンやコリジョンエンジンが搭載されているタスクシステムがあったとして
とても便利だったとする。
でも、それらからタスクシステムを無くすともっと便利、
もしくは、有っても、あえてタスクシステム部は使わない方がもっと便利、
なわけだから、やっぱりタスクシステムは要らないって話になる。

そもそも、タスクシステムに描画エンジンやコリジョンエンジンをくっ付ける必要はないしな。
タスクシステム、描画エンジン、コリジョンエンジン、サウンドエンジンが
それぞれ選択的に利用できるようになってた方が、必要に応じて選べて便利だ。
そんで、タスクシステムだけ使わないのなw。

アンリアルエンジンのActorも使わなければ良いだけの話。
186 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 00:00:04.61 ID:7WlpQLAU]: 真性のアレのお出ましか。
＞メリットは書き込まれない。一度も。
今までのログや >>2 のリンク先からいくらでも長所、メリットが
明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような
特殊学校級の真性君に根気よく説明するサリバン先生みたいな
聖人じゃないんだ、ゴメンネ。

＞アンリアルエンジンのActorも使わなければ良いだけの話。
世界でミリオンタイトルをいくつも出してるゲームエンジンを
使ってる優秀な人たちは君とは何故か違う考えみたいだけど、
君にとっては自分の頭で理解できないものを使わない、ってのは
正解だとは思うよ。
187 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 00:04:51.24 ID:pCx3Pnsp]: ソースロンダリングはいいって。
さっさとメリット挙げたら？
188 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 01:08:57.32 ID:D6ApEC6F]: >>186
> 今までのログや >>2 のリンク先からいくらでも長所、メリットが
> 明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような

それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
より汎用的で粒度の高い現代的な手法の選択的な組み合わせで置き換えられるから、
今さらタスクシステムなんて作る必要はないよね。

ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
タスクシステム独特の長所だろう。

すでに出てるんなら URL 貼るだけでもいいんだから、出してもらえないだろうか？
189 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 08:59:03.57 ID:aC0nIGEU]: タスクシステムのメリットはあがらない絶対だ
190 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 13:11:55.54 ID:3fH2rWBj]: 真性のアレ、はどう見てもおまえなんだが。

現代的なゲームエンジンのことなら「ゲームエンジン」と呼べばいい。
過去いくつも、全くそれに及びもつかない実例がある「タスクシステム」なんて呼称で、
現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
どう見ても真性のアレ。基地外タスクシステム信者。
191 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 20:43:23.42 ID:7WlpQLAU]: >>188
＞それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
へぇ、「それらの長所・メリット」ってことは君は少なくともメリットがあがってるのを知覚できるぐらいの知能はあるんだね。
＞ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
でも「他の手段がある＝メリットが無い」の論理的な間違いを認知できるだけの知能は無いみたいだね。

>>190
＞現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
ほぅ、つまり
＞アンリアルエンジンのActorも使わなければ良いだけの話。
みたいな真性ちゃんと一緒にするな、と言ってる訳ね。www
192 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 22:55:00.28 ID:pCx3Pnsp]: そしてやっぱりタスクシステムのメリットは挙がらない。
193 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 23:09:28.54 ID:CoLgixDm]: ＞タスクシステムのメリット
一言でいえば抽象化。
まあ実際に抽象化によだれ垂らして魅力を感じる人種なんてごくわずかだよな。
194 名前：名前は開発中のものです。 mailto:sage [2011/09/13(火) 23:48:36.64 ID:pCx3Pnsp]: タスク=処理なんか抽象化して、一体何をしようって言うの？
何か目的があるなら、その目的のエンジンでも作って外部に追いやったら良いだけでは？
例えば描画エンジンやサウンドエンジンや物理エンジンみたいに。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef