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

**名前は開発中のものです。** · 2009/12/13(日) 18:11:06

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

part8 http://pc11.2ch.net/test/read.cgi/gamedev/1250678891/
part7 http://pc11.2ch.net/test/read.cgi/gamedev/1241670786/
part6 http://pc11.2ch.net/test/read.cgi/gamedev/1238725539/
part5 http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/
part4 http://pc11.2ch.net/test/read.cgi/gamedev/1233459490/
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/

・タスクと呼ばれる実装は、非常に多岐に渡ります
　古典タスクシステムについての話題は「>>2」と明示してください
　そうでない場合はカスタム版であることを明示してください

・人を憎んで言語を憎まず

**名前は開発中のものです。** · 2010/01/23(土) 17:54:27

>>237
じゃあなんなのよ。うそついてるって言うくらいだから教えてくださいよ。
こんなところで言っても意味はないけどコンシューマーでで３０万くらいは出てるタイトルやってきたよ。
シューティング、アドベンチャー、ＲＰＧ、シミュレーション。
PS1/PS2/GameCube/DS/PSP。プログラマーは５～１０人程度。

メモリ管理が便利になるとは思えないし(むしろ複雑になってデバッグが困難になることが多い)
フレーム処理用のインターフェイスの統一ならクラス継承そのもので
これをタスクシステムというならああそうなの？って感じだけど。
これなら確かに誰でも使ってるけど俺の回りではこれをタスクシステムとは呼ばないよ。

**名前は開発中のものです。** · 2010/01/23(土) 18:00:19

＞メモリ管理が便利になるとは思えないし
これはいわゆるTCBをいつでもどこでも自由につなぎかえるようなものをイメージしたときの話ね。

**名前は開発中のものです。** · 2010/01/23(土) 18:34:19

HtJlbitcのターン

**名前は開発中のものです。** · 2010/01/23(土) 19:53:05

>フレーム処理用のインターフェイスの統一ならクラス継承そのもので
フレーム処理用のインターフェイスの統一＝クラス継承
俺のまわりでは違うけど。君のまわりではそうなってるの？
説明どぞ

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

class IFrameInterface
{
virtual void execute() = 0;
virtual void draw() = 0;
}
これ以上に何が必要でしょうか。
できればそれによるメリットを教えてください。

**名前は開発中のものです。** · 2010/01/23(土) 19:57:32

さらにいうとこれもお題目なだけでわざわざ継承する必要すらないことも多い。

**名前は開発中のものです。** · 2010/01/23(土) 19:57:55

>これをタスクシステムというならああそうなの？って感じだけど。
>これなら確かに誰でも使ってるけど俺の回りではこれをタスクシステムとは呼ばないよ。
>>174
名前が違うだけで使ってるってオチですか？

>おれメインで５本ゲーム作ったことあるけど必要になったことないな。
あれ？前に言ってることと違うような。
周りはみんな使ってるけど俺一人使ってない、ということ？はて。

**名前は開発中のものです。** · 2010/01/23(土) 20:05:15

>>244
>>243がそうならそうだね。これをタスクシステムって呼んでるの？
でもタスクシステム云々言ってるときに
メリットとそのための実装が明確になっていることを見たことがないので。
タスクシステムと呼んでいた人たちのコードがバグを誘発してて
その複雑なコードはシンプルに書き換えられるという局面によく出会っていた。

＞あれ？前に言ってることと違うような。
これよくわかんないからもう少し説明して

**名前は開発中のものです。** · 2010/01/23(土) 20:12:46

>>245
>メリットとそのための実装が明確になっていることを見たことがないので。
メリットが明確になっていないものを
>これなら確かに誰でも使ってるけど俺の回りではこれをタスクシステムとは呼ばないよ。
君のまわりでは誰でも使ってる、と。
必要無いなら誰も使わないはずだけど？はてはて。

>これよくわかんないからもう少し説明して
"必要になったことない"のに"誰でも使ってる"？
はて、誰でもに君は含まれないのかい？

**名前は開発中のものです。** · 2010/01/23(土) 20:16:35

>>246
あのさぁ。こっちは少しでも例だして質問して答えてるんだから
少しは例だしてくれないかな。

＞>>244
＞>>243がそうならそうだね。これをタスクシステムって呼んでるの？

これはどうなの？これがそうなら「必要あります」
＞TCBをいつでもどこでも自由につなぎかえるようなもの
なら「必要になったことない」
という意味なんだけど。

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

>>243とは>>242のコードをさしてるのか？
ならちがうんじゃない？

こちらの感覚は >>174 とか >>178 に近い。
ゲームでは必ず必要になるゲームオブジェに処理を回す"何か"の
代名詞的な意味だ。

で、結局君は何を主張したいんだ？

こっちは >>137 みたいなタスクシステムもゲームエンジンもOOPも
ゲームオブジェに処理を回す必要も無い、って言ってるハード屋とやらの
矛盾をついてるだけなんだが。

まさか君も同じ考えなのかな？

**名前は開発中のものです。** · 2010/01/23(土) 20:42:00

まぁPS1時代みたいに片手で数えられるぐらいのプログラマ数なら
個々に必要になった箇所で作ってもいいんじゃない？とも思うが

今の外注やらライブラリやらサーバやら込みで３桁のプログラマが
コードをいじるプロジェクトで、タスクシステムなり何なり、処理を
回す基底処理を用意しないわけにはいかないし。

タスクシステムは非常にあいまいで名前が紛らわしいってのはあるけど
あんまりユニークな命名すると「これは何をするものですか？」って何回も
いろんな部署のプログラマに説明しなきゃいけなくなるし。（ドキュメント
用意しても百人超えるプログラマの中には読まないで聞きに来るのが絶対いる）
「タスクシステム」ってゲームプログラマならほぼ知ってる知名度の高い
名前つけてた方が面倒少ないから名前使う、ってレベルだけど。

**名前は開発中のものです。** · 2010/01/23(土) 20:44:38

>>248
>>174 >>178もそもそも具体的じゃないと思うけど
「定期的に処理を回す”何か”のこと」を>>242風に実現してるものはたくさんあると思うけど？
>>242からもシステムを構築する上でも無駄に複雑にする方法がいくらでもある。
(あまりにも汎用的な記述なんだから当たり前だよね。)
だからもっと具体的に、メリットがある「タスクシステム」はどんなものかを聞きたいのね。
「メリット」と、できれば実装を聞いているの。
少なくとも「メリット」が明確なら実装は聞かなくても推測可能だし。

＞で、結局君は何を主張したいんだ？

>>242 >>243以上の汎用システム化にメリットを感じたことがない。
>>242を毎フレーム呼び出すコードは普通に一般的だがそれ以上のメリットを備えた
汎用的なゲームシステムのことを「タスクシステム」と呼んでいるなら
そのメリットとはなんなのと質問しているんです。>>248でちがうんじゃない？といってるし。
きみも>>237で本質的なメリットじゃないっていってるじゃない？

わかりにくかったのかな。
本質のメリットというものを教えて欲しいんです。
別に誰かの意見の支持とかではなく>>236に対して>>237といったことの具体例を。

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

不必要に基底が肥大化したタスクシステムに弊害があるのは当然。
んでもゲームで必ず必要になる処理である以上、誰かが何処かで作るわけで。

２桁超えたプログラマが思い思いに勝手に作ってたら収集つかなくなるだろ・・・
で、作ったら命名する必要があって、命名するなら代名詞的なもの使ったほうが
理解しやすいね。ということ。こっちの言ってるメリットの一つはこれ。

PS1とか64とかCubeとか、あの頃はみんなプロジェクト毎に独自タスクシステムっぽいもの
毎回新しく作ってたんだけどねぇ・・・
今のPS3/360世代で同じことやってると会社つぶれるし間に合わん。

>本質のメリットというものを教えて欲しいんです。
どうも君はプログラム・ロジックレベルのメリットに限定してるみたいだけど。
そのレベルのメリットは「タスクシステムの実装による」としか答えられん。

うちで今使ってる「タスクシステム」と名がつくものはマルチ・非相対コアで並列動作して
リソース同期を極力抑えて・・・というようなもの。
これは古典的タスクシステムと似ても似つかないものだけど、使う側のプログラマにとっては
キャラ単位、フロントエンドUIのウェジット単位、とかに使えてよくあるタスクシステムと同じ
範囲をカバーするから「タスクシステム」と命名してある。

**名前は開発中のものです。** · 2010/01/23(土) 21:42:10

>>251
うーんそうすると>>242でもなにか便利な機能が追加されれば「タスクシステム」と呼ぶわけね。
(違うといってるのはおそらくこれに「独自の」メリットが追加されたものをそう呼んていると読み取った。)
で、そう呼ぶこと自体に意味があるということが>>237の真意ってことね？

それはあまりに技術的内容がないな。
たとえば並列化できるシステムは技術的コンセプトなしには作れないし
簡単じゃないことくらいはもちろんわかってるよね。メモリの安全な管理もそう。
UIの要素管理やAI管理もそうでしょう。

ここでの主張は「タスクシステム」と呼ぶこと自体が意味のあることという主張で
具体的な内容は>>242以上はないと。
そこまで言うならおれはやっぱり「タスクシステム」って呼ばないほうがいいと思うわ。
ネット見たってTCBがタスクシステムに必須であるような記述も多いし、
いろんな技術的要素をタスクシステムの例として説明しているものが多いし。
で、おれの経験でもタスクシステム云々言ってるコードは不要に複雑になったコードが多かった。
たしかに実装した「定期的に処理を回す”何か”」がシステムっぽいときに
「いわゆるタスクシステム的な」っていうのは通じやすいけど、
それじゃ「タスクシステムってなんですか」ときかれたら答えられないじゃん。

ゲームはいろいろな要素に>>242的な形が出現する、それを実装しているといったほうが優しくないか？
言い換えれば「定期的に処理を回す”何か”」ってことだから>>174そのものだね。
まあこれだけを意味する用語をおれも知らないけど。

というか>>137も>>174は否定してないように見えたけど？
(さかのぼるの面倒だったのでID:iYQ9vwhmしか見なかったけど)

**名前は開発中のものです。** · 2010/01/23(土) 21:51:35

>そこまで言うならおれはやっぱり「タスクシステム」って呼ばないほうがいいと思うわ。
それは会社や現場の文化なりルールなり開発者の嗜好なりの問題。
「タスクシステム」以外の名前で通ってる現場もいくつか見てきたし。
タスクシステムという名前を必ず使うべし、と言ってるわけじゃない。
ただうちの場合はロートルのプログラマとか、今は管理者になって現場に居ない上役とかにとって
「タスクシステム」ってのは通りがいいので使ってる。

>というか>>137も>>174は否定してないように見えたけど？
さかのぼれば色々面白いと思うぞ。
タスクシステムのメリットを否定したいがためにゲームエンジンも、クラスの継承も、OOPも抽象化も全て否定して・・・
「タスクシステムは全ての人にとってメリットが無い！」とまで断言しちゃ
色々からかいたくなるだろ？

「へー、どうやって証明するの？その悪魔の証明」って。ｗｗｗ

**名前は開発中のものです。** · 2010/01/23(土) 22:02:35

>>253
＞それは会社や現場の文化なりルールなり開発者の嗜好なりの問題。
これは否定できないけど
このスレは「タスクシステム」って何なのメリットあるのってスレだと思うけど。

「定期的に処理を回す”何か”」をタスクシステムって呼びます。
ならそれ自体はだれも議論しないと思うよ。

でも「タスクシステム」と称していろいろな実装についても語られる中
「タスクシステム」をそう理解しろってのも無理な話でしょ。
だって「定期的に処理を回す”何か”」って「ゲームループ」とすら言い換えられる。

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

>「タスクシステム」をそう理解しろってのも無理な話でしょ。
今のゲーム業界でそー使われてるのが事実だからしょうがないんじゃない？
他にもっと適当な用語があればそれ使いたいんだけど、誰も代案なんて出せないだろうし。

「ファミコンショップ」に行って「何でPS3とか最近のゲームが置いてあるんだ！
ファミコンショップだろ！ファミコンのソフト売れよ！紛らわしいだろ！」とか怒られても
「今時ファミコンなんて売れないし・・・そーいうものです」としか答えられん。

技術的な話題をしたいなら、自分で明確なコードなり設計なりを出してから
「ここの問題どうしましょう？」とか聞くのがいいんじゃないの？
それかもっと適切なスレに行くか。
>たとえば並列化できるシステムは技術的コンセプトなしには作れないし
とかはタスクシステムじゃなくてゲームエンジンなりフレームワークなりの持分かと。

今まで「タスクシステム」と名がつくシステムを数十個見てきたけど、見事にゲーム毎に別々。
2Dアクション系でrect情報持ってるのとか、3D系でシーングラフとくっついてるのとか、
Win32APIのエミュみたいにHWNDとか持ってるわけわからんタスクシステムとか・・・
まぁ基底がごちゃごちゃしたタスクシステムと言われるものはだいたい糞だけど。
そうでない理にかなった自称タスクシステムも沢山見てきたわけで。

で、「全てのタスクシステムはデメリットしかない」と言われると「うーん・・・視野が狭いなぁ」となる。

**名前は開発中のものです。** · 2010/01/23(土) 22:32:30

>>255
いやいやだからきみは「２ちゃんで煽りたい」ってスタンスが透けて見えるんだって。
>>237では「お前が無知なだけでメリットがあるよ」って雰囲気だしてるし
＞技術的な話題をしたいなら、自分で明確なコードなり設計なりを出してから
これを出したら「タスクシステム」の話ではなく「俺システム」の話でしょ。
で共有できる「タスクシステム」の概念は何と質問すると>>174
こちらが出した擬似コードが>>242

＞今のゲーム業界でそー使われてるのが事実だからしょうがないんじゃない？
＞とかはタスクシステムじゃなくてゲームエンジンなりフレームワークなりの持分かと。
＞今まで「タスクシステム」と名がつくシステムを数十個見てきたけど、見事にゲーム毎に別々。
結局こう言ってるのにすごい含みを持たせているようにしか見えない。
そんな議論だとだれも食いついてくれないから何かあるように見せる。
それが>>3だったり「タスクシステム」にまつわる大きな問題じゃないの？

**名前は開発中のものです。** · 2010/01/23(土) 22:48:10

>いやいやだからきみは「２ちゃんで煽りたい」ってスタンスが透けて見えるんだって。
初めからいってるじゃん。ｗｗ
隙だらけの説を吹いてる奴の矛盾をついて楽しむのが目的だって。
たまたま覗いたこのスレに、理論的に隙だらけの奴がいたから遊んでるだけ。
理屈のおかしい主張は突っ込みたくなるだろ？ｗｗ

今さらタスクシステムなんてあいまいで初歩的な話、たいして興味ない。

んでもこっちがからむのは話の矛盾している箇所にであって、純粋な技術の話には
からまんけどな。相手がからんでこない限り。

で、あんたは「タスクシステムは全ての人にとってメリットの無い」って主張しているのを肯定するのかい？
それとも技術的な話の邪魔と思うの？

俺は無料逆転裁判を楽しんでるだけだ。ここは2chだしｗｗ

**名前は開発中のものです。** · 2010/01/23(土) 22:51:57

ちょっと考えれば IFrameInterface とでも役割を反映した名前にできるところを
「タスクシステム」なんて内容のわからない名前付けにして済ませてしまう。
そんな名前になってるからメモリ管理やら処理優先度やら妙なものがいっしょくたに
なっても、おかしいことに気づかない。あるいは気づきにくい。
そういう悪習を広めるという意味で「タスクシステム」は害悪であって、それを上回る
ようなメリットは持っていない。

**名前は開発中のものです。** · 2010/01/23(土) 22:55:43

IFrameInterfaceも何するものなのかいまいちわからないけどな

**名前は開発中のものです。** · 2010/01/23(土) 22:58:59

>>257
論理の飛躍が見えてちょっと恥ずかしいなといってるだけ。
技術的な話を一切シャットアウトしてるのは突込みではなく煽りでしかない。

いっていることは結局>>174
そうだとしたらこのスレのだれも反論しないよ。

＞で、あんたは「タスクシステムは全ての人にとってメリットの無い」って主張しているのを肯定するのかい？
ここ数レスだけを見れば君の主張を否定する点はない。ただそれはこのスレ的には誰も興味ないんだよ。
「俺の環境で概念の共有手段として使っている」といっているだけで
このスレで出てきている技術的な話についてもなにも理解が進むわけがないし
>>3のようなデメリットに対する反論になるわけでもない。

＞それとも技術的な話の邪魔と思うの？

君がかき回しているだけだと思うよ。

**名前は開発中のものです。** · 2010/01/23(土) 23:04:43

>君がかき回しているだけだと思うよ。
そうかい？
まぁこっちの楽しみのために技術的な話題をしたいという
真面目な人の邪魔するつもりは無いから退散するよ。

このスレで技術的に意味のある話ができるといいね。

**名前は開発中のものです。** · 2010/01/23(土) 23:05:39

二人が話してる「タスクシステム」は、相互にズレがあるようだな

**名前は開発中のものです。** · 2010/01/23(土) 23:10:30

そもそも論点が違うっていう

**名前は開発中のものです。** · 2010/01/23(土) 23:10:38

そんなものを用語として使うことがｗ

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

for(;;)を永久ループって言ってるようなものだよね。

**名前は開発中のものです。** · 2010/01/24(日) 02:10:17

IFrameInterfaceってtaskSystemよりセンスが悪いと思う…

**名前は開発中のものです。** · 2010/01/24(日) 09:40:18

ネットでダウンロードできる実践的なタスクシステムのソースってある？
オープンソース化してる市販ゲームって海外が多いから
タスクシステムのお手本みたいなのが見つからなくて・・・・

**ハード屋** · 2010/01/24(日) 11:49:57

なんか荒れてるね。皆色々背負ってるみたいだから大変なんだろうね。
「技術」ねぇ。ノウハウの間違いなんじゃないかって。まあいいや。

俺なんかだとあれだけどね。
動的に実行順を制御したい部分が出てきたときは、
個々にモジュール化しちゃうけどね。
たとえば、Zソートだと、描画エンジンに任せたり。
局所性が高い方がカスタマイズしやすいでしょ、
そのスケジューラは描画エンジン専用にしていいわけだから。

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

経験によって意見がだいぶ違うな
小規模開発の実装プログラマ視点からはタスクシステムは諸悪の根源
大規模開発のアーキテクチャやプログラムディレクター視点からは
タスクシステムのような統一処理は必須

**名前は開発中のものです。** · 2010/01/24(日) 12:34:09

全部アセンブラで書くのならタスクシステムは有効かもね
このスレではあまり重要視されないけど、複数人で開発しやすい構造だしね

**名前は開発中のものです。** · 2010/01/24(日) 12:49:13

便利なシステムはあったほうがいいけど具体的にどんなものなの？ってことでしょ。
それを具体的にしないと。

**名前は開発中のものです。** · 2010/01/24(日) 12:57:31

ゲームでは必須になる処理だけどジャンルとかプラットフォーム世代とかで
最適解が異なるから、具体的な一つに集約はしないだろう。

最大公約数的に全てのタスクシステム共通の処理だけ抜き出してきても
それは実際に使われてるタスクシステムとは似ても似つかないものだから
そんなの調べても実際のゲーム開発には役に立たないし。

**名前は開発中のものです。** · 2010/01/24(日) 13:19:25

実際に役に立たない概念・定義できない概念をタスクシステムと呼んでいるなら
それは意味がないでしょう。通常はメリットとその実装方法に意味があるんだから。
(「ゲームシステム」ってあると便利だよね。つくったほうがいいよっていってるのと変わらない。)

例えば、動的な処理順番変更がメリットでその実装方法としてTCBがあり
それがタスクシステムならそれは必要ないことが多い。
必要な場面で使えばいい手法ということになる。

上で「定期的に処理を回す”何か”」っていってるけど
それだけを「タスクシステム」と呼んでいるのならデザインパターンのひとつくらいの意味だね。
デザインパターンでも普通はサンプルコードくらい書けるけど。
>>2あたりはそういう主張じゃないよね。

**名前は開発中のものです。** · 2010/01/24(日) 13:26:35

タスクシステムはデザインパターンではなくアーキテクチャパターンだろうね。
PACアーキテクチャなんてタスクシステムの親類みたいな感じだし。

アーキテクチャパターンレベルの話にデザインパターンレベルの具体的な実装を
求めても、いろんな実装が出てきてまとまらないのは当然だな。

**名前は開発中のものです。** · 2010/01/24(日) 13:26:49

ここまでタスクシステムへの明白なメリット明言なし。

適切な特性に適切な命名がなされることは、
皆さんご存知の通り、設計としての良い指針。

**名前は開発中のものです。** · 2010/01/24(日) 13:51:16

>>274
アーキテクチャパターンでもいいがサンプルは書けるでしょ。
メリットとそのメリットの明確化のためのサンプルがない用語に意味はあるの？
最悪メリット・目的だけでもあればまだ話はできるが。
それすらもないならアーキテクチャパターンですらないのではないのか？

PACアーキテクチャのどの部分がタスクシステムとの類似点なの？
「定期的に処理を回す”何か”」より具体性が後退してると思うんだけど。
MVCといわないのならこの差に特徴があるの？そんな議論もあまり見たことないが。

**名前は開発中のものです。** · 2010/01/24(日) 13:56:40

今までいろいろ明言されてるタスクシステムのメリットとデメリットって
PACアーキテクチャのそれとみごとにかぶるな。
タスクシステム≒PACアーキテクチャのゲーム業界方言
と言っても説明が通じそう。

で、実装レベルの理解が限界の一兵卒には設計レベルのメリットは目に入らない、
という感じか…

このスレの現状が見えてきた気がする。

**名前は開発中のものです。** · 2010/01/24(日) 13:57:59

>>277
なぜ具体的に語れないの？

**名前は開発中のものです。** · 2010/01/24(日) 14:09:25

具体的にってのは一兵卒からみた戦術的な話だろう。
銃の上手なうち方みたいな。

アーキテクチャは戦術じゃなく戦略の話だから
そのレベルの具体的な一例を戦略の話に求めるのがそもそも変なんじゃないのかな？

ちなみにアーキテクチャパターンなら、それを実装するデザインパターン例
の組み合わせが載ってたりするから、そこまで噛み砕いて具体例を要求すれば
デザインパターンレベルでの実装例は出せるかもね。

**名前は開発中のものです。** · 2010/01/24(日) 14:11:15

>>279
うん君のレスは中身がないよね
＞MVCといわないのならこの差に特徴があるの？
まずこれに答えてみてよ。

＞アーキテクチャは戦術じゃなく戦略の話だから
じゃあきみは一平卒にどうやってそれを伝えるの？

**名前は開発中のものです。** · 2010/01/24(日) 14:14:20

>>279
一平卒に分からなくてもかまわないから、
タスクシステムがどういう「戦略」なのか書けよ。

あれか？無能下請けを閉じ込める檻ってやつか？

**名前は開発中のものです。** · 2010/01/24(日) 14:26:18

>>279
具体的な戦略を語ってほしい。
それこそが求められている。

タスクシステムの具体的な何かを知っている人は、
このスレで問い詰められると、いつも最後には逃げる。

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

>>280
MVCとPACパターンの違いをきいてるのかな？
>PACにおけるCは、GUIに限らずMとVを協調させるという責務を持っている。またPACは明示的に階層構造を定義しているという点でMVCと異なる。
だって。
タスクシステムと違ってアーキテクチャパターンは明確な定義があるからやりやすいな。

あとネットで具体例を出してって本職には難しいんじゃないかな。
仕事のコード出したら大問題だし、説明のためだけにサンプルゲームつくるような親切な例は >>2 ぐらいじゃないかな。
それで飯食ってる人間に、説明のためだけに無給でコード書くこと要求してそれが通らないと逃げるなって言われるのは…
さすがに甘えすぎじゃない？と思う。

ほんとにやる気があるならGemsのactor周りとかアーキテクチャパターンとかある程度の基礎を自分で勉強して、
それでもわからない箇所があれば自分から具体的な質問を出す方が現実的かと。
質問が具体的なら返答も具体的になるだろ。

って何か「教えて君」に話しているような内容だな、これ。

**名前は開発中のものです。** · 2010/01/24(日) 15:11:39

>>283
＞だって。
ようはMVCとPACの違いを意識したことはなかったわけね。
で
＞タスクシステム≒PACアーキテクチャのゲーム業界方言
＞と言っても説明が通じそう。
それはないだろう。

君が
＞タスクシステムのような統一処理は必須
っていってるけどじゃあタスクシステムは何なのってきくと
＞タスクシステムと違ってアーキテクチャパターンは明確な定義があるからやりやすいな。
じゃあ「タスクシステム」というものはなんなの？
これも答えず
＞仕事のコード出したら
なんて誰も言ってないことを言い訳するし>>2の内容にすら触れない
＞さすがに甘えすぎじゃない？
何もいえない奴にどう甘えろって言うんだ？

＞って何か「教えて君」に話しているような内容だな、これ。
君ののレスから君が何か有意義な考えを持ってるようには読み取れないよ

**名前は開発中のものです。** · 2010/01/24(日) 15:24:05

タスクシステムについて、明確な説明をすることは、
とてもとても大変で、とてもとても難しいことのようだ。

MVCのメリットなら一言で言うと、
俺はモジュール性が高まることにあると思う。

MがVもCも知らなくていいように作れるし、
ユーザからのinputはCが、ユーザへのoutputはVが担う、
という、名前と一致した明確な役割分担が美しいと思う。
交換可能なままで、各役割のクラス階層が育っていくので好ましい。
また、GUIでよくあるインタラクションへ、
ひとつの解をしめしてみせたという、
設計例の共有という意味でも有意義だったと思う。

**名前は開発中のものです。** · 2010/01/24(日) 15:25:54

>>284
ずいぶんつっかかるな。

>それはないだろう。
そう言い切れる根拠を出してくれないかな。
明確に言い切れるということはタスクシステムに関して明確な定義があるということだろうし。

それが皆の納得できるものならこのスレも有意義になるんじゃないのかな？

**名前は開発中のものです。** · 2010/01/24(日) 15:44:52

>>286
結局きみは自分にカードがあるように見せかけるけど一枚も場に出さず人にカードを切れというだけなんだよな。

PACアーキテクチャはMVCとの差を意識することで意味のある概念だろ。
だから後発にもかかわらず存在している。
つまりPACアーキテクチャはMVCとの差を意識することによって意味のある用語となっている。
PACパーキテクチャの方言という説明が有意義だと思うのなら一般にどう使われてるか配慮すべき。

MVCの議論はこのスレにもあった。
それも意識せずにPACアーキテクチャと比較するのであれば
そもそもその概念を有意義に考察しているかどうか疑問に思わざるを得ない。

そもそも
＞明確に言い切れるということはタスクシステムに関して明確な定義があるということだろうし。
これは君が答えるべきことだから。
君は何を意味しているの？
おれは
・「定期的に処理を回す”何か”」
・それ以外の何か(例えばTCBを使って実装されている。動的な処理順番変更機能を持つ。など)
のどれのことか具体的にときいてるんだけど。
で「PACパーキテクチャの方言」っていうからどこがそうなのって聞いてるの。

カードがないならないって言えばいい話。

**名前は開発中のものです。** · 2010/01/24(日) 15:57:16

>>287
>PACアーキテクチャはMVCとの差を意識することで意味のある概念だろ。
ちがうと思うぞ。PACはMVCとは別概念。
PとAが直接参照しない点とCが階層を持てる点でMVCより一般的なタスクシステムに近いんじゃない？

>これは君が答えるべきことだから。
教えて君に答えなきゃいけない義務なんていつの間に出来たんだろう？
妄想の中？おしえて。

ちなみにタスクシステムに関する個人的な見解は >>272 だ。

ところでカードって何？

**名前は開発中のものです。** · 2010/01/24(日) 16:15:46

>>288
お前のレスが>>272で尽きてるならもう>>274以降このスレ的に意味のあることは何もないってことだね。

これすら意味ない。
＞PとAが直接参照しない点とCが階層を持てる点でMVCより一般的なタスクシステムに近いんじゃない？

まあもういいけど、これを解釈すれば、
・階層構造が持てること
・描画がデータを直接参照しない
がタスクシステムの特徴ってこととなるけど階層構造はともかく
描画がデータを直接参照しないってすでに「一般的なタスクシステム」をなんら表してないだろ。
でもせめてうえの２つを直接指摘すれば議論にはなったね。
一兵卒に理解できない内容とはとても思えないけど。

**名前は開発中のものです。** · 2010/01/24(日) 16:27:30

ID:KTZGeiZiが断片的に示してくれたタスクシステム像。

>>269 タスクシステムのような統一処理
>>272 ゲームでは必須になる処理
>>274 PACアーキテクチャなんてタスクシステムの親類みたいな感じ
>>277 タスクシステム≒PACアーキテクチャのゲーム業界方言
>>288 PとAが直接参照しない点とCが階層を持てる点でMVCより一般的なタスクシステムに近い

**名前は開発中のものです。** · 2010/01/24(日) 16:37:03

今のタスクシステムって用語はいろんな実装から帰納的に求められた
広い意味を持つ用語だから、具体的な実装の話をしたければ質問側が
具体的な条件を出さないと無意味だね、と。

で実装レベルではないアーキテクチャレベルの話ならPACアーキテクチャ
とかが近そうだね、と。

用語のあいまいさの問題と実装と設計と、別々の問題なんだから質問を分別する必要があるんだけどね。
そこが分けられるかどうかが一兵卒とそうでないかの試金石？

まぁ何か「意味のあることは何もない」って完結したみたいだからいいか…

**名前は開発中のものです。** · 2010/01/24(日) 16:40:01

煽ってるつもりが煽られて捨て台詞ｗ
カッコイイ

**名前は開発中のものです。** · 2010/01/24(日) 17:45:29

タスクシステムとPACなんとかって別に近くないだろ
もちろん数あるタスクシステムの中にはPACなんとかっぽい構造または機能を持ってるものがあるかもしれないけど

**名前は開発中のものです。** · 2010/01/24(日) 17:47:59

>>268
やぁ。元気取り戻したようだね。じゃあこれよろしく。>>209

**名前は開発中のものです。** · 2010/01/24(日) 17:50:52

>>293
煙にまこうとしただけなんだから触れてやるなよ。

**名前は開発中のものです。** · 2010/01/24(日) 17:52:41

>>290-291
自分の考えてる「タスクシステム」とは何かを説明してよ。
たとえを一切使わないで。

**名前は開発中のものです。** · 2010/01/24(日) 18:06:18

ID:KTZGeiZiは間違ったことは言ってないんだけど
相手のレベルに合わせた話ができないのは痛いな。
この人部下の人望無さそう。

**名前は開発中のものです。** · 2010/01/24(日) 18:11:49

タスクシステムについては結局なにも言ってないからな。
応対はかなりひどいけど。

**名前は開発中のものです。** · 2010/01/24(日) 21:42:39

裸の王様インターフェースの実装がまたひとつ。

**名前は開発中のものです。** · 2010/01/24(日) 22:16:42

なんか香ばしいねここ。

>>2の「古典タスクシステム」って、CodeZineのリンクにあるような
メモリアロケータまで詰め込んだ「固まり」、でいいの？C++なのにいろいろ
意味のない車輪の再発明しちゃってるような。
それなら、Cライブラリ的な何かが提供するメモリマネージャが貧弱で、
コルーチンすらないような組み込み系で「だけ」なら使えるかもね。
というか、そういう組み込み環境で使われる設計的な何かが「タスクシステム」の正体ってことでいいのかね？
（「組み込み環境」は、DS的なもの以下の環境を想定してます。）

とすると、そういうもの（「固まり」）は、あくまで組み込みとか貧弱な環境で必要があるもので、
Windows環境で動くゲーム（アーケード含む）とか、ハイエンド家庭用ゲーム機とか、
リッチな環境だといらないよね？
いやもちろん、「タスクシステム」にも含まれている処理、たとえば個々のオブジェクトに
処理を回したりすることを提供する「何か」は、環境が変わろうと必要で、そういうのは
各ゲーム会社にあるんだろうけど、
>>2の「古典タスクシステム」を「タスクシステム」である、として説明しているようなページが多い現状で
その「何か」を「タスクシステム」と呼ぶのはどうなのよ、と。
もっと言うと、「何か」を「タスクシステム」って呼んじゃっているようなところって、
「何か」に、「古典的タスクシステム」の要素のうち、もう自前で書かなくても済むようなものまで
組み込んじゃってません？

いやもちろん、業界内で「タスクシステム」といえば「何か」を指すのが当然だ、というのなら別に
構わないんですが、それにしては「古典タスクシステム」の紹介や実装がWebに溢れているなー、と。

**名前は開発中のものです。** · 2010/01/24(日) 22:45:34

結局タスクシステムという名前が好きか嫌いかだけの問題なんだな。

**名前は開発中のものです。** · 2010/01/24(日) 22:49:21

名前の意味すら不明瞭なのが問題

**名前は開発中のものです。** · 2010/01/24(日) 23:07:56

ここはニートに労働のメリット教えるスレと同じだな。
どんなに説明されようと初めから労働のメリットを認めるつもりは毛頭ないニートと
ニートを見下したいだけのリア充の終わり無き戦い。

ID:bsBl9MV5は持論と違うことをいくら説明されても馬の耳に念仏で「何もないってない。意味が無い」と繰り返すだけ。
ID:KTZGeiZiは自分の周りだけの業界常識を持ち出して相手を見下したいだけ。

どっちもどっちだ。

おまえらいいからゲーム作れ。

**名前は開発中のものです。** · 2010/01/24(日) 23:17:16

>>303
>>272でなにかあるってならそうだけど。
きみは>>272からなにを読み取るの？

**名前は開発中のものです。** · 2010/01/24(日) 23:28:03

>>304
>>303のまんま過ぎてﾜﾛﾀ

**名前は開発中のものです。** · 2010/01/24(日) 23:33:43

>>305
>>304
煽りたいだけなの？

**名前は開発中のものです。** · 2010/01/24(日) 23:42:51

>>306
自分の想定しているタスクシステムってどんなの？
状況に応じて違う、とかいうなら、その状況を自分で前提してでもいいから
たとえとか無しで自分の言葉で説明してみてよ

**名前は開発中のものです。** · 2010/01/24(日) 23:48:11

>>307
レスをたどってはくれないのか・・・
おれは
＞・「定期的に処理を回す”何か”」
＞・それ以外の何か(例えばTCBを使って実装されている。動的な処理順番変更機能を持つ。など)
＞のどれのことか具体的にときいてるんだけど。
＞で「PACパーキテクチャの方言」っていうからどこがそうなのって聞いてるの。

一つ目なら必要な機能だけどこれが「タスクシステム」でいいの？
TCBを使って動的な処理順番変更機能を持つものが「タスクシステム」なら
その方法にこだわる必要はないと思う。

なので「タスクシステム」を各々どう想定しているか聞いている。
おれは２番目も含めた説を見ることが多いのでそれは必須じゃないと言うのが持論。

**名前は開発中のものです。** · 2010/01/24(日) 23:56:22

>>304
事実を言ってるだけじゃね？
あんたの持論とは違うから何も読み取れないみたいだけど
そもそもあんた初めから議論するつもりなんて無いだろ
自分の聞きたい答えが聞けるまで人に質問繰り返すだけなんだから

>>272こそ>>308の答えそのものなんだが、これ以上何を期待してるのやら

こんなところで意地張ってないでゲーム製作にでも打ち込んだほうが
あんたにとっても有意義じゃね？

**名前は開発中のものです。** · 2010/01/24(日) 23:59:28

>>309
うん「タスクシステム」が技術的な実体を持たないというならそれでいいよ。
でも含みを持たせてみたりしてるしそもそも「実装はそれぞれ」だけじゃなんの話にもならないでしょ。
そういっているだけ。

＞こんなところで意地張ってないでゲーム製作にでも打ち込んだほうが
＞あんたにとっても有意義じゃね？

これはそうだけどね。これを突っ込む意図は何？

**名前は開発中のものです。** · 2010/01/25(月) 00:21:13

>>310
>うん「タスクシステム」が技術的な実体を持たないというならそれでいいよ。
あんたのいう技術的な実態って何のこと？
タスクシステム並みにあいまいなんだけど

>これはそうだけどね。これを突っ込む意図は何？
そうだけどね、と納得したならいいんじゃね？あんまり意地はるな

**名前は開発中のものです。** · 2010/01/25(月) 00:28:55

>>311
うーん読み取れないものなのかな
＞・それ以外の何か(例えばTCBを使って実装されている。動的な処理順番変更機能を持つ。など)
これは違うの？
＞その方法にこだわる必要はないと思う。
ともいっている。これはあいまいなの？

＞そうだけどね、と納得したならいいんじゃね？あんまり意地はるな
この板一応技術板だよ。実体のないものと結論付けるのはそれなりに意味があるでしょう。
それすら否定するならこのスレにレスする君の意図は何と聞きたかったの。

**名前は開発中のものです。** · 2010/01/25(月) 00:35:39

あんた笑っちゃうほど>>309のまんまだな
人の質問には答えずに質問返し。そしてものすごい意地っ張り…

**名前は開発中のものです。** · 2010/01/25(月) 00:39:40

>>313
＞＞・それ以外の何か(例えばTCBを使って実装されている。動的な処理順番変更機能を持つ。など)
＞これは違うの？
＞＞その方法にこだわる必要はないと思う。
＞ともいっている。これはあいまいなの？

これは返答じゃないの？
むしろこの返答に答えて欲しいんですが。
質問の意図を確認しながら返答することすら許さないの？

＞人の質問には答えずに質問返し。
それ俺がそう思っちゃうんだが。

**名前は開発中のものです。** · 2010/01/25(月) 00:40:30

>>309
実例を挙げて、具体的に言ってあげたらいいと思うよ。
自分の関わってるプロジェクトを例に挙げて、
こういう要求の時にはこういう処理をタスクシステムと呼んでる
っていうのをボカさずに説明してあげるべきだと思う。

**名前は開発中のものです。** · 2010/01/25(月) 01:04:58

>>314
>これは返答じゃないの？
返答じゃないでしょ。質問でしょ
>質問の意図を確認しながら返答することすら許さないの？
こっちの質問の答えになってないからね

まぁいいや
これじゃID:KTZGeiZiと同じ結論のわかってる終わり無き戦いに巻き込まれるだけ
なので撤退しますわ

時間は大切にね！

**名前は開発中のものです。** · 2010/01/25(月) 01:08:22

この機能なんの意味もないってそろそろ認めてもいいと思うｗ

**名前は開発中のものです。** · 2010/01/25(月) 01:15:12

煽りたいときに意味があるでしょ
>>3は秀逸

**名前は開発中のものです。** · 2010/01/25(月) 09:06:17

> これじゃID:KTZGeiZiと同じ結論のわかってる終わり無き戦いに巻き込まれるだけ

説明出来ないことを誤魔化すには、その対応は手垢がつき過ぎてる。

**ハード屋** · 2010/01/27(水) 21:45:20

あーやっぱこういう流れになったか。

なんていうかさ、たとえ、タスクシステムのメリットが出てきたとしても、
「そのメリットに焦点を当てた専用のモジュールを作れば？」
か
「そのメリットが生きる機能に専属でくっつければ？」
で終わっちゃうんだよな。

メモリ管理やオブジェクトの管理をするモジュールがあってもいいとは思うけど、
タスクシステムにくくりつける必要はないし、その方が可搬性が高まる。

Zソートやあたり判定で動的な実行順制御が必要な場合も、
それぞれのモジュールなりエンジンなりにそういう機能を持たせた方が、
これもやっぱり可搬性が高まる。

**名前は開発中のものです。** · 2010/01/27(水) 21:57:51

最小構成のタスクシステムって、動的に実行順序を制御できるだけの代物だと思うけど、
でも、動的なスケジューリングをするからには、その目的が絶対あるはずだろ。
だったら、その目的の機能内で動的なスケジューリングを勝手にやればいい話じゃん。
たとえば、Zソートだったら描画エンジン内で勝手にやりゃすむはなしだし。
動的スケジューリングってことは、それだけ　ややこしい　わけで、
汎用性を持たせようとして表に出してくる必要はないよな。

**名前は開発中のものです。** · 2010/01/27(水) 22:12:29

あと、開発手法としてタスクシステムはどうのこうのってのも出てたけど、
そういう動的呼び出しに頼ったやりかたは、そりゃプラグインなんかで使う増設の手法だ。
ゲームで言えば、ModだよMod。あとから拡張するやつ。
まだリリース前で最終ビルド前なのにModはねぇだろ。
だって、まだ、メインループ部は触れるわけだろ？
拡張拡張の延長でゲーム作るわけ？めんどくせ。

**名前は開発中のものです。** · 2010/01/27(水) 22:18:54

プロジェクト管理の面でも、
メインループから明示的に関数なりメソッドなりを呼び出す静的なやり方の方が、
トップダウンで管理しやすいと思うんだがなぁ。

**名前は開発中のものです。** · 2010/01/27(水) 23:06:33

静的のメリットをわかってない奴は多い。違いすらわかってない奴も。
抽象化はメリットがあって初めて必要なもので
メリットが小さければ可読性保守性が落ちるだけのことがほとんどということもわかってない奴多い。

**名前は開発中のものです。** · 2010/01/28(木) 01:48:59

>>320
自称ハード屋くんの文章は相変わらず中身がない。批評の対象をきちんと明示していないから。
君が考察し批評している対象物が何なのかきちんと明示してねー、と何度も何度も指摘してるよねぇ。
それはいつ、誰が、誰と、どういう状況で、何を作るために使ったものなんだい？実在するのかい？
ハード屋ともあろう者がこの期に及んで「あーあー聞こえない聞こえない」で押し通すはずないよねぇ
まさか脳内で生成した何かについてあーだこーだ自問自答してるわけもんねぇ

さぁ、さっさと>>107の質問に返答してくれ。な。待ってるんだよ

君は、使ったこともない見たこともない対象物についてあーだこーだ薀蓄垂れる知ったかゲハ厨
ではないと俺は信じてる

**名前は開発中のものです。** · 2010/01/28(木) 02:01:55

どっちが中身がないのだか。

**名前は開発中のものです。** · 2010/01/28(木) 02:26:16

前スレで彼の妄想の産物かと疑いたくなる曖昧な批判対象に付き合い
ESPを駆使して可能な限り具体的に書くよう努めてきたので勘弁してね

彼の批判する謎のタスクシステム。それが一体何でどういう状況でどう使われ
何が糞だったのかを彼が書かない限りもう駄目だと思うんだ

**名前は開発中のものです。** · 2010/01/28(木) 02:39:33

もー書かなくていいよｗ
だってこのシステム存在価値ないじゃん
そろそろ気がつかねーと駄目だろ
やっぱ>>3は優秀だな

**名前は開発中のものです。** · 2010/01/28(木) 02:41:16

例えば5万円未満で買い揃えられるローエンドのPC、例えば
最底辺のAtomネットブック、で60[fps]でヌルヌル動く程度の
こういう同人STGをVS2008EE(のC/C++)+DX9で作ったけれど
Codezineみたいな組み方って何でここをこういうふうにするかな
なんでこうしないのだろうか、とか。これくらい書けるでしょ。普通。
なぜ彼は書けない？おかしいだろ。前スレからの疑問

彼の批判には、具体的なゲームの仕組みの切れ端すら出てこない。
不自然なくらい綺麗さっぱり無い。不思議だよねぇ

おやすみ

**名前は開発中のものです。** · 2010/01/28(木) 02:48:34

>何が糞だったのかを彼が書かない限りもう駄目だと思うんだ

必死さが伝わってきて満足です。

**名前は開発中のものです。** · 2010/01/28(木) 03:07:35

自称ハード屋は自分が作り出した敵のイメージと戦ってんだよ。
みんなの前でシュッシュッてやってみせてるシャドウボクサーが呟きました
「こいつ使えねー（笑）存在価値なくね？（笑）」

ギャラリーには何が何やら分かりません

**名前は開発中のものです。** · 2010/01/28(木) 06:23:04

>>331
ごめん
さっぱり意味わからない

**名前は開発中のものです。** · 2010/01/28(木) 09:10:52

>>326
俺もおもったｗ

**名前は開発中のものです。** · 2010/01/28(木) 11:06:32

手の届かない葡萄は酸っぱいと言い張るしかないアンチの皆さんでした

**名前は開発中のものです。** · 2010/01/28(木) 12:30:42

C++でタスクシステム作ってて
・特定の種類（型）のタスクに定数時間でアクセスしたい
・実行順位を定めたい
・タスクの数を制限したい
これらの条件を満たすものをファンクタと型消去とリンクリストで実装したら
boost::mpl::listにある型リストにタスクに値するファンクタの型を入れて
各々の要素のメモリ領域を再帰継承のtemplateクラス内部で実体化及びリンクリスト生成、
そのクラスが持っているリンクリストを基底型から順に実行する、
という形になったんだけどこれだとファンクタの種類が多くなった場合に
空リンクリストを見て実行せずに制御だけ返すっていう処理も多くなってしまう。
どうすればもっと軽くできるんだろうか。
それとも、この条件を維持しつつだともうこれ以上最適化できない感じ？

**名前は開発中のものです。** · 2010/01/28(木) 23:53:28

>>320
> なんていうかさ、たとえ、タスクシステムのメリットが出てきたとしても、
> 「そのメリットに焦点を当てた専用のモジュールを作れば？」
> か
> 「そのメリットが生きる機能に専属でくっつければ？」
> で終わっちゃうんだよな。

ところで「タスクシステム」はバズワードなので結局この文章全体が
ほとんど意味を成してない。それではあんまりなのでこのバズワードを
より適切な言葉で置換して、この文章の価値をよりわかりやすくしよう

　　僕が考えたエターナルフォースブリザードシステムのメリットが出てきたとしても
　　「そのメリットに焦点を当てた専用のモジュールを作れば？」
　　か
　　「そのメリットが生きる機能に専属でくっつければ？」
　　で終わっちゃうんだよな。

はは、知るかバーカ、って感じだよね

**名前は開発中のものです。** · 2010/01/29(金) 00:18:06

がんばるねぇ