タスクシステム総合スレ 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/

**名前は開発中のものです。** · 2008/11/13(木) 22:53:24

飯くってた
>>36
node allocatorは良いものらしいね

>>38-39
把握した

WindowsだのVisual Studioなど言ったって、なんだよ結局はユーザープログラム固有の
モニタプログラム（システムモニタ（リソースモニタ）やジョブモニタ）を用意しなくちゃ
いけなくなるのかよバーローつー話だよな

通常、ゲーム開発用のフレームワークはデバッグ支援用のツール群とセットになってるけど
それに相当するサービスをVS標準機能に期待するのは難しいね

ま、同人ゲームとか、ここでタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら
無用の機能だが

**名前は開発中のものです。** · 2008/11/13(木) 23:55:15

前>>969
（前略）だからコンテキストスイッチは不要では。

＞コンテキストスイッチは要らなくネ？

ゲームに要求される表現は多様化・高度化し続け、それに伴いゲーム内で処理されるジョブの粒度も多様化し
１イント内に処理すべきジョブ数も増大の一途をたどった。ジョブ（ゲームコード。例えばAI）を記述するスタッフも
増大し多様化した。時間ステップ毎に単純に数値積分していくだけのジョブばかりではなくなり、継続（continuation）
が必要なジョブが増えた。にも関わらずゲームの特性上個々のジョブはμsecオーダーで終了ないし中断することを
要求される。継続に必要な手続きをユーザープログラム側に丸投げする（ユーザープログラム側にリエントラントな
仕掛けを用意させる）原始的なFSMモデルのジョブ制御だけではお話にならなくなり、ファイバーやコルーチンのような
仕掛けも必要になった。これらのジョブの粒度はスレッドを使うには小さすぎ、また数も多すぎる

まぁ、同人ゲーやタスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら無用の機能ではあるが