タスクシステム総合スレ 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/15(日) 00:20:01

なんでタスクシステムのメリットデメリットを教えてくれないのさ
みんな俺だけ仲間はずれにして、泣くぞ

>>625
前に同じこと書いたけど>>2にはメリットデメリットが書いてないし
そのときも誰もメリットデメリットを教えてくれなかったし
推測しろという、不親切過ぎるだろ
補えって言うくらいだから、使ってる人は知ってるんでしょ?メリットデメリットを
まさか知らないで使っているわけないよね

誰でもいいからタスクシステムの
メリットとデメリットを教えてください
いじわるしないで教えてください、お願いします

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

ハハン、自分で考えろ
メリットデメリット→相対的な話

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

Q.タスクシステムのメリットとデメリットを教えてください
A.ハハン、自分で考えろ

……俺はどうすればいいんだろう

**名前は開発中のものです。** · 2009/02/15(日) 00:28:29

>>627
お前が一行もプログラムの書けないポエマーなのは十分わかったから、もう出てこなくていいよ

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

>>630
メリット、デメリットを出せって奴は俺もいるぜ

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

比較対象が出てこない限り、
アドバンテージ云々って話にはならんだろ

**名前は開発中のものです。** · 2009/02/15(日) 00:45:37

>>632
タスクシステムしか知らんの？

**名前は開発中のものです。** · 2009/02/15(日) 00:47:57

>比較対象が出てこない限り、
>アドバンテージ云々って話にはならんだろ
DSL

タスクシステムがフレームワークに類するのかどうかわからないけど
フレームワークはいくつかある

比較対照はたくさんあるけど
タスクシステムの基本的な事がわからないのでなんとも言えない
それに比較対照がなくても、大きいメリット一つぐらいはわかりそうなものだが

Q.タスクシステムのメリットとデメリットを教えてください
A.ハハン、自分で考えろ
なんだかこのやりとりが気に入ったw

**名前は開発中のものです。** · 2009/02/15(日) 00:53:32

DSLつっても色々あんぞ
boost::protoでevalできるものは全てDSL(*)って言えるし、さらに(*)すらDSLの一部だぞ

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

タスクシステム的発想を継承していないゲーム用並列動作処理を、
比較対象として出してみ。
そうすればメリット、デメリットの話もできるだろう。

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

>>635
DSLのメリットとデメリットはわかる
色々あるなら全部比較対照にすればいいから
比較してタスクシステムのメリットとデメリットを教えてもらいたい

>>636
タスクシステム的発想というものがさっぱりわからないけど
DSL

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

プログラム入門以前の人
・メリット：なんだこんな簡単な仕組みでゲーム作れるんじゃん。やっぱりな。これなら自分でも覚えられるぞ！　とか、
　　　　　おれのSTG（もどき）が動いた！　といったあたりまでゲーム製作が推進可能となる
・デメリット：わりと最悪の部類に入る設計思想でした。もう一歩も先に進めません。という時期が来る

ベテラン（？）
・メリット：デバッガとか周辺ツールが便利らしい
・デメリット：デバッガとか周辺ツールを自分で作るらしい。あと、抽象化を見極めるワザが必要らしい。

タスクシステムに設計パターンとしてのメリットは無いね。
Byアンチ

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

>>637
DSLとやらと比較したいんだったら、自分で比較作業やればいいじゃないか。
それを他人にさせようとするなよ。
ただしタスクシステム批判するなら、根拠となる比較作業結果を明示する。

**名前は開発中のものです。** · 2009/02/15(日) 02:50:31

>532
> 『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー』
> 脳みそに染み渡った？質問どうぞ

つまりアンチタスクシステム厨というのは、自分にとって理解できないものに対して『俺は何が理解できて
いないか理解できていないぞ』と公衆の場で叫ぶキチガイと言うことか？

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

頑張って非タスク作ってみたぞｗ
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8884.zip
どこか変わったか？ｗ

っていうか糞わかりにくいコードだったからバグってるかもしれない
まあ、雰囲気だけ受け取ってくれ

どうせやるなら
自機、敵、弾の３種類のクラスがあって
弾は追尾機能（関連を作るため）がついてるほうがいいな

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

>>641
mainにwhileがあって中で星の数だけ処理をforで回す…と。
初心者がC言語習って最初に作るミニゲームとかはこーなるだろうなーと。

これでブラックホールとか自機とかさらに複数の要素が加わったら全部の要素をこのwhile内にハードコードで追加して巨大化していくのかな？
タスクシステムなら新しい要素をタスクに登録するだけで、スクリプトとかから動的に要素を増減できるけど。

さらに、ゲームだとタイトルとかコンフィグとか、デモとか、ボーナスステージとかステージ毎に違う仕掛けがあるケースはどう書くのかな？
一個のメインループの中にswitchとかで切り分けて無理やり全部詰め込む？
それとも全ての要素の組み合わせごとにメインループを分ける？
…ってことは見苦しいからやりたくない、って思ったプログラマがタスクシステムを作ったんだけどね。

タスクならメインループは一個。タイトルやゲームも要素の増減もタスクで処理可能。

頑張って非タスク作るって、結局アンチはその程度のことも分かってないプログラマだった、という証明になってるんだが…
まぁ、たまたまこのアンチのレベルが低いだけで、まさか全部のアンチがこんなレベルのプログラマじゃないよな？

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

>>504
オレも最初そう思ったｗ
Squirrel可愛いよSquirrel
タスクからSquirrel呼んじゃうよ（まあ俺はタスク使わんけど）

んで、まじめにDSLという（Java/Ruby界隈中心に広まった？）言葉の定義を調べてみたが、
どうやら外部DSLはSquirrelやLua、XML、JRuby、Groobyのようないわゆる組み込み言語を指すらしい
で、内部DSLというのはyacc/bisonやboost::lambda、Lispのマクロ機能、
アスペクト指向トランスレータに見られるような言語自体のメタ的拡張手法を指すようだね

煽るつもりはないが、内部DSLがゲームのなにを解決するのか分からないなあ
しかもタスクの問題範囲と競合してるようにも見えない
どういう風にゲーム開発に活用しているんだろう？モナディウスとか？

>>642
売り言葉に買い言葉なのは分かるが、安全なところから他人のコードを叩くなよ

**名前は開発中のものです。** · 2009/02/15(日) 09:32:34

>>643
まあ、アンチの代表格が、510のプログラムさえ読めなかった低脳ポエマーだったことが発覚したので仕方ないんじゃね？

あと説明責任君とか。510のプログラム見てわからないなら、プログラマを語るなと言いたいんだが。

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

>>642
だから、こんなサンプルじゃそーゆーのを俺がどう書くのかわかんねーだろ？ｗ
だから、自機、敵、弾のサンプルのがいいって言ってるのに

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

>>645
ならこのサンプル出す意味無いんじゃね？
タスクシステムの比較対象にすらなってないし。

**名前は開発中のものです。** · 2009/02/15(日) 10:25:34

>>646
ホント、その通りなんだけど
それは>>510にしかわからないｗ

**名前は開発中のものです。** · 2009/02/15(日) 10:30:58

俺は>>641のほうが良いと思うぞ。
単純で読みやすい。
whieループの中の「～タスク」は別関数に切り出して欲しいが。

こんな簡単な問題をなんで変なマクロでくくって、ややこしくするのかが理解できん。
>>510タスクシステムが理解できないのではなく、
簡単な問題をわざわざ複雑に解く理由が分からんと言っている。

事実、>>641のコード量は>>510の半分程度になってるだろ。

**名前は開発中のものです。** · 2009/02/15(日) 10:32:18

抽象化コストがまるでペイしてないという実例として有意義だと思うが、どうかな。

**名前は開発中のものです。** · 2009/02/15(日) 10:39:55

>>504
DSL具体例出してくれてありがとう。よく分かったよ。
Squirrelな俺にとってはいつのまにか外部DSL派だったわけね。
スクリプトにタスク概念入れると処理の一貫性や可読性やらの諸問題で、
タスク使わない派に戻りました。今のところコルーチンでFAな感じ。すげえし読みやすい/書きやすいよ。
もしコルーチンで記述できない/処理が重い問題にぶち当たればタスクに戻るよ。その辺は柔軟に考えている。

ゲームっつっても、小規模STGなのか大規模RPGなのか、2D/3Dなのかネットワーク対応/非対応なのかにもよって変わってくるだろうし
理論と実践は異なるってことだよだな。銀の弾丸は無いよ。
各自好きなの使えばいいじゃん。

**名前は開発中のものです。** · 2009/02/15(日) 10:44:27

>>649
こんなんじゃ納得できないと思うな奴等ｗ
結局オブジェクトも１種類しかないし
種類が増えたときにごった煮が役に立つを思ってる奴等でしょ？ｗ
なんで>>510なんかに飛びついてたのかわからないけどｗ

**名前は開発中のものです。** · 2009/02/15(日) 10:45:34

>>648
それは庭いじりしか知らない人がハサミで十分だから
ノコギリの必要性が理解できないと言ってるのと同じ。

サンプル規模のプログラムでタスクシステム使うのは庭いじりにノコギリ使うようなものだが
>>642 のような実際のゲーム規模では必ず遭遇する問題にはタスクシステムかそれに変わる何らかのシステムが無いと
こんなベタ組みじゃやってられんよね、ということだ。

**名前は開発中のものです。** · 2009/02/15(日) 10:52:37

>>652
絶対、かわんねぇよ
だって書かなきゃいけない処理って決まってるじゃん
書かなきゃいけない処理の一覧書き出して
タスクシステムで書かなくてよくなる処理を○でもつけてみろｗ

自機、敵、弾ってあってそれぞれが関係するなら
自機ｘ敵、自機ｘ弾、敵ｘ弾の関連の処理は絶対に省略できないってｗ
アフォでもわかるべ～ｗ
冷静になって考えてみろよｗ

**名前は開発中のものです。** · 2009/02/15(日) 10:58:26

>>653
>タスクシステムで書かなくてよくなる処理を○でもつけてみろｗ
タスクシステムは書かなきゃいけない処理を書かなくてもよくするためのものじゃないぞ。
そもそもそんなシステムは無いだろ。

関係するオブジェクトの増減やゲームの状態推移を統一した扱いにできて便利、ぐらいのもの。

自機、敵、弾だけで完結できるほどシンプルなサンプルレベルのなら使わなくてもいいんでない？

**名前は開発中のものです。** · 2009/02/15(日) 10:59:18

>>649
抽象化するコストって、TaskSystem自体は再利用できるんだから、たくさんゲームを作るなら
ゼロに近づいていくんだが。

まさかあんたは一本だけゲームを作って一生を終えるつもりか？

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

>>654
>タスクシステムは書かなきゃいけない処理を書かなくてもよくするためのものじゃないぞ。
>関係するオブジェクトの増減やゲームの状態推移を統一した扱いにできて便利、ぐらいのもの。
はぁ？じゃ、何がメリットなんだよｗ
さっさと言えよ
とりあえず>>510のサンプルなんてなんの役にも立たないってわかった？
目的もなく動いたって無駄なんだよ
ホント馬鹿だな
無駄、呼吸してること自体が無駄
>>510のサンプルに飛びついてたゴミはすべて無能

>自機、敵、弾だけで完結できるほどシンプルなサンプルレベルのなら使わなくてもいいんでない？
だから、そういうだろｗお前等ｗ
>>510のサンプルはなんの意味もねーって言ってるのに
わかんねぇかなぁｗ

**名前は開発中のものです。** · 2009/02/15(日) 11:14:35

>自機、敵、弾ってあってそれぞれが関係するなら
>自機ｘ敵、自機ｘ弾、敵ｘ弾の関連の処理は絶対に省略できないってｗ
処理が似たり寄ったりなら、そこはクラスの「抽象化」の一言で済むんじゃない？
タスクの範疇じゃないでしょ。タスクについて勘違いしてるよ～

**名前は開発中のものです。** · 2009/02/15(日) 11:14:44

>>656
>はぁ？じゃ、何がメリットなんだよｗ
>>642 でタスク使えばこーかける、ってのが出てるけど。
これじゃ理解できないかな？

まぁ、メリットデメリットが理解できないなら使わなければいいだけなんだが。
誰か君にタスク使うよう強要してるの？

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

>>657-658
うーん？
何？言ってることさっぱりわからない
苦し紛れに意味わかんないこと言わないでよｗ

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

何を言っているのか分からないのなら、デザインパターン/クラス設計についてもうちょっと勉強してくれ。
GoFのデザインパターンとか、その辺から見てみるといいよ。
あくまでタスクは状態遷移のためのもので、データの抽象化等とか根本的に違うっしょ。

**名前は開発中のものです。** · 2009/02/15(日) 11:20:48

>>660
えーだって結局>>510のサンプルはなんの意味もなしてないわけでしょ？
あのソースにあれこれ言ってた人はどこ行ったの？

**名前は開発中のものです。** · 2009/02/15(日) 11:22:49

>>661
タスクシステムの実装の一例として
>>641のサンプルよりは意味があるんでない？

**名前は開発中のものです。** · 2009/02/15(日) 11:24:37

>>662
おいおい>>641は>>510がなんの意味もなくね？っていうのを表現するために作ったんだぜ
んでそれは納得できた？ＹＥＳ？orＮＯ？

**名前は開発中のものです。** · 2009/02/15(日) 11:29:11

俺はまだ510のサンプルはぱらっとしてしか読んでないが、
従来のタスクよりは、可読性について大幅に改善していると思うよ。
今までのタスクは処理が飛びまくるから目で追うのが大変だったからね。

**名前は開発中のものです。** · 2009/02/15(日) 11:33:51

>>663
>>510 タスクシステムを使ったサンプル（実装例として意味ある）
>>641 何も使ってないサンプル（実装例として意味無い）

だけの話でしょ…

というか、タスクシステムごとき単純な考え方を煽りじゃなく本当に理解できないとしたら
プログラマとしてどーかと思うぞ。

**名前は開発中のものです。** · 2009/02/15(日) 11:34:44

まあ、抽象化された部分がコストに見合った働きをするならOK。
扱う問題が巨大になったとき、>>510版と>>641版でどれほどの差が出るかなんだが。
なんかあるの？

単にタスクシステムの分だけオーバーヘッドになってるように見えるんだけど。
>>510を使えば使うほど何らかのコストが浮くのかな？

一体何がラクになるのだ。
どんな問題を解決しているのだ。

もともと制御部っていうのは本質的に複雑だから再利用は難しい。
汎用的にすればするほど中身がなくなっていく部分。
「ドラクエ風ゲームエンジン」「横シューエンジン」「スト２風格ゲーエンジン」「アンリアル風エンジン」
ここまで的を絞って３～４本量産してようやくペイするってところじゃないか。
マルチスレッドに注目したMTフレームワークなんかは、デバッグのしやすさや移植しやすさも売りにして抽象コストをキッチリ回収している。
実行環境／開発環境として、実行／開発において誰もがぶち当たるありふれた問題を一手に引き受けて解決している。
単にforループで済む部分を別のやり方でやって偉ぶっているわけではないので混同しないようにな。

>>510
これはＨＯＷ。結局タスクシステムはどの問題を解決しているのか。
ただのforループ以上の何があるんだ。ただのforループに勝ってるのか。
そうでないならforループを使うほうが遥かに良い。単純明快説明不要でコスト０だ。

>>620
「ここに処理を書けば自動で並列化できますよ」

まず、何がどう自動なんだか分からない。
実のところ、何も自動化されていない。

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

>>661
お取り込み中のところ横からで済まないが
>>641 のソースだが、明らかに元のソースより読みにくい。

forがロジック部に出てきてるのだとか、null判定してcontinueしているのとか
Starの空きを探す部分だとか。

結局、
・もし事前に510のタスクシステムが存在していてこの開発コストが0だと見なせるなら、
641のコードのほうが工数が多いのは明らか。

・もし事前に510のタスクシステムが存在していてこの開発コストが0だと見なせるなら、
が成り立たないなら641の書き方でいいんじゃね？とは思うけどな。

**名前は開発中のものです。** · 2009/02/15(日) 11:36:30

>>665
で？>>510と>>641は大して変わらないソースになったけど
これがオブジェクトの種類が増えていくとどう変わる？って展望があるのかな？
そーゆーことが言いたいなら少なくともそういう色の出てるソースじゃないと意味ないよね？
つまり、この時点では>>510はなんの意味もない、そういうことだよね？

**名前は開発中のものです。** · 2009/02/15(日) 11:37:31

>>667
>>>641 のソースだが、明らかに元のソースより読みにくい。
なんか言い出しちゃったよｗ

**名前は開発中のものです。** · 2009/02/15(日) 11:39:29

結局、アンチって

明確なデメリットがあるからアンチとか
他にもっといい方法があるからアンチ

ってわけじゃなく
そもそも経験不足でメリット・デメリットや使いどころが想像つかないけど
他の人は理解してて悔しいからアンチ
って感じにしか見えん。

自分の好みに合わないなら使わなきゃいいだけなのにねぇ…

**名前は開発中のものです。** · 2009/02/15(日) 11:40:50

>>666
> 「ドラクエ風ゲームエンジン」「横シューエンジン」「スト２風格ゲーエンジン」「アンリアル風エンジン」
> ここまで的を絞って３～４本量産してようやくペイするってところじゃないか。

そう簡単な話じゃないんだ。

これは現場の俺から言わせてもらえれば、
エンジンを作ったり設計したりしてるのは賢い連中なのよ。

それぞれのゲームを作ってるのはもっと質の悪い、単価の安い、なんと言うか・・まあ、皆まで言わすな。

だから、プログラムのうち、難しい部分と簡単な部分とを切り分けて、難しい部分を賢い連中に
担当させるのは、理にかなってるんだよ。

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

>>650
組み込みスクリプトには２種類のメリットがあると思う

１．フレームをまたいだ継続処理の記述が平易にできる
　　コルーチンがもてはやされるけど、実はコルーチンでなくても
　　コンテキストを保ったままフレームをまたげる実装であれば良い
　　そういう意味では目新しいものではなく、今までも各社独自でこのようなスクリプト実装は行っていた

２．データをソースコードの外部に出すことができる
　　Game Programing Gems１巻で最初に触れられるのがこれ（データ主導設計）
　　今風に言うとXMLよりJSONだよね的な話だが、もちろんコレも新しいものではない

こうして見ると、結局コルーチンもデータ主導設計もDSLと同じで、
それと意識されることなく昔から使われていた手法だよね
考え方に名前を付けるのは必要なことだけど、普及しはじめるとHYPE化するのはどうしてなんだろう

みんな銀の弾丸が欲しくてHYPEに踊らされすぎなんじゃないか？
＃もちろん"タスクシステム"もHYPEであり、タスク厨はそれに踊らされ、アンチはそれを嫌うクセに別のHYPEに群がるんだ

**名前は開発中のものです。** · 2009/02/15(日) 11:42:11

非タスク版は車輪の再開発すぎるっしょ。
わざわざ>>510から戻した理由がわからん……。

**名前は開発中のものです。** · 2009/02/15(日) 11:43:39

>>673
いや、比較のためだろう。
俺は、>>641 はそういう意味ではいい仕事したと思うよ。

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

>>672
なかなか深い観点だ。恐れ入った。
業界人じゃないから昔の話とか全然わからんけど、色々と工夫していたみたいね。
いまからゲームを作るのであれば、コルーチンで書く書かないはスクリプターのセンスに任せるとして、
データの外部化については正直必須だと思うんだ。
その辺をしっかり作っておけば、準汎用で使いまわしが便利な資産になる感じだと思ってる。(完全に汎用ではないけど)

HYPE化はしかないんじゃない？
タスクに代わる実装には選択肢が多々あるから、
1択に絞れる(1択に絞れる方法が存在する)のならそれに依存したいとおもうのは仕方ない。信仰宗教と代わらんね。

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

結局、実際にいろいろ使ってみて自分でレビューするしかないな。
作るゲームの規模や種類によっても違ってくるだろうし、
万事での最善も最悪も無さそうだ。

実際にある程度の規模のゲーム作って
議論してるやつがどれだけいるか知らんがなあ。

**名前は開発中のものです。** · 2009/02/15(日) 12:32:22

1000行以下なら構造無しで気合でどうにかなる
1000行程度から5000行程度ならタスクシステム導入でもなんとかやりすごせる
30000行程度ならタスクシステムは糞。完全に開発ストップ。 >>641 的に書くとこから再出発。
100000行程度、、、組んだこと無い

>>641 よりタスクシステム導入した方が良いとかいうやつ、30000行以上のもの書いたことあるのか？
また話変わるぞ？
そんな小手先の技術じゃどうにもならなくなる時が来るはずなんだが
なぜそこまでたどり着かないのか不思議

**名前は開発中のものです。** · 2009/02/15(日) 12:44:56

行数で手法を変えなくてはならないのは
タスクシステム以前に設計が糞なだけだろ

**名前は開発中のものです。** · 2009/02/15(日) 12:45:47

>>673
>>620

**名前は開発中のものです。** · 2009/02/15(日) 12:47:31

>>678
タスクシステムは設計の範疇にいれないんだｗｗｗ
設計じゃないならなんなんだよｗｗｗ

**名前は開発中のものです。** · 2009/02/15(日) 12:47:49

昨日　>>510 面白い面白いって言ってた奴だけど、
自分も同人で50Kオーバーの作品を作ったことあるけど、
総ステップと、タスクが使えるかどうかは、>>670と全く同じ考え。
タスクシステムは歪みがこの程度のサイズで出てくる。
行数で、手法を変えるというよりも、タスクでやるのが、無理になってくる。

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

>>670　でなくて >> 677　か

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

>>677
3万行って、ソースで言えばたったの1MBぐらいだろ？
10万行規模のソースのあるプロジェクトに関わったことがないって、どこの弱小ゲームメーカーだよ。

ちょっとした規模の商用ゲームなら、ライブラリの一部だけでも3万行ぐらいあるだろうに。

タスクシステムに限らんが、使うに値するところには使えばいいんだ。

まあ、たいていのゲームは大規模になってくると、そのゲームに特化したエンジンにせざるを得ないので
汎用的で使い回しの利く部分は減っていくのは仕方ないが。

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

規模が大きくなるとタスクで使えなくなるのは同意。
タスクシステムは規模が大きくなるにつれ処理を追うことが困難になりやすい。
(そのためにタスク管理やタスク監視のデバッグメニューを実装する必要も出てくる)
そんな中>>641に戻すのも手だが、それなら初めから組み込みスクリプト使うかな。自分なら。

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

複雑な組み込みスクリプトってさ、
CGエフェクトのハードコーディングを避ける目的に使うくらいじゃねえの？

ある程度、個々のタスクの動作の選択肢が限られているからこそ、
>>2をより一層抽象化できるというか。

タスクシステムの動作原理を継承しているよな。

**名前は開発中のものです。** · 2009/02/15(日) 13:48:09

50万行規模の某シュミレーションで全てタスクで実装してるのを見たことあるが。
決して見やすいソースでは無かったけど、不可能では無いわな。

ゲームのモード用メインループタスク階層。敵や味方のオブジェクト用タスク階層。
メニューシステムタスク階層とか、分割統治方式で使ってたが。

他にはswitch/caseの状態を階層化して管理してる某ステップ方式とかも見たことあるが
どれも規模が大きくなると悲惨なことには変わりなかったなぁ

ただ >>641 は何のシステムも無しに力技でベタに作ってく方法だから、そもそもタスクが使えんほど
大きなコードではまったく話にならんよ…

**名前は開発中のものです。** · 2009/02/15(日) 13:59:12

組み込みスクリプトは洋3Dメジャータイトルで積極的に採用されている。
例えばLuaの適用ゲームはこんな感じ。
http://en.wikipedia.org/wiki/Lua_(programming_language)#Applications

どの程度使ってるのかは、ゲーム内によって異なるので定かではないが、
CEDECでスクエニの中の人が発表していた内容では、
WiiのFFCCというゲームの開発ではSquirrelを使っていて、
コード比はプログラム3割スクリプト7割だってさ。

**名前は開発中のものです。** · 2009/02/15(日) 14:10:51

>>687
参考になりました

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

>>684
それは意図が全然違うじゃん
スクリプトは処理を企画に渡せるってだけでしょ？
書かなきゃいけない処理はまったく変わらない
スクリプトを話題に出してる時点で意味不明

**名前は開発中のものです。** · 2009/02/15(日) 14:20:50

>>687
スクリプトだと中間言語経由になるから、高速な相互影響処理には向いてないよね。

＞WiiのFFCC
FC世代RPGの厚化粧版か。

＞コード比はプログラム3割スクリプト7割
プリミティブな次元では従来のゲームからの変革はなし。
VFXだけ肥大といったところか。
タイトルの詳細をチェックしていないので、テキトーなこと言ってるけど

結局、タスクシステムは必要ってことだ。

**名前は開発中のものです。** · 2009/02/15(日) 14:26:13

もちろん書かなくちゃいけないコードは変わらないよ。
減ったりも増えたりもしない。
まずは、フレームワークとスクリプトを完全に分けます。
で、スクリプト言語の持っているコルーチンに頼って、
スクリプト実装者がゴリゴリ書く。
仕事も責任も分担できる。オススメです。

**名前は開発中のものです。** · 2009/02/15(日) 14:26:58

その『○万行を超えたらタスクで管理するのがムリになってくる』っていうのは、結局FSMにするのが
ムリになってくるってことだろ？

**名前は開発中のものです。** · 2009/02/15(日) 14:27:13

>>691
じゃあ、この場所で出す話題として適切なの？どうなの？
それともその話題はタスクシステムのメリットデメリットに直結するものなの？

ちゃんと考えて発言してよ

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

>>690
JITがあるよ。x86なら公開されてる。必要なら個人で実装すればいいけど、敷居は高いかな。
速度を稼ぐ必要があるのならCに戻すことも考慮されている。
Luaならここかな。http://luajit.org/

**名前は開発中のものです。** · 2009/02/15(日) 14:34:20

>>693
俺の考えは、アンチタスク派で、
タスク派がコード量でプログラムが肥大化して可視性が悪いよというのであれば、スクリプト使え
ってこと。
ちゃんと考えて発言してないように見えるかい？

**名前は開発中のものです。** · 2009/02/15(日) 14:43:31

アンチタスク派に一つ聞きたいんだが、例えば自機選択式のSTGがあったとして、機体それぞれの
jikiについての関数は当然別々に書くんだよな？　違うの？

**名前は開発中のものです。** · 2009/02/15(日) 14:55:33

>>695
今後ゲーム開発はスクリプト使う方向に行くだろうし、
それ自体は賛成だけど

タスクシステムの上にスクリプトが乗っかるのか、スクリプトの上にタスクシステムを構築するのか、って感じで
スクリプト自体はタスクシステムの有無とはまた違う話だよね。

間接的にデータ駆動でコード中の複雑性が減ってタスクシステムでもコード見通しがよくなるね、という程度の話なのかな？

まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…

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

>>696
処理よっては別になるかもわからんねぇ
敵のパーツを奪って武器・装甲を強化するタイプの自機と
経験値蓄積型のパワーアップをするタイプの自機ぐらいの違いがあると
もうプログラム自体共通部分を探すほうが難しいぐらいになるかもしれんし
まあ、仕様によるかな？
何が来てもいいように別にしておくのがいいな
もし、共通部分があったとしてもたかが数箇所（自機分）でしょ？

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

>>697
スクリプトだけでタスクは乗らないです。
どっちも載せたりすると直感的に分かりづらくなる。
フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。

>まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
>ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…
これは同意です。1人で実装するとなると2倍手間になりそうですが、そこは明確な作業分担でできるってことで。
スクリプトのメンテはスクリプトの動的ロードを実装すれば、プログラム実行中でも即座に反映されるようになるから便利ですぜ

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

アンチです。

>>696
ごめん。よくわからない多分自分の理解力不足だけれど
タスクでもそうでなくても、jikiを別々には書かないかと。
タスクにした場合と壮でない場合で、その点に違いが出るの？

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

>>699
>フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
オブジェクトの粒度をどの単位にするかにもよるけど
例えば敵の弾一個一個につき協調スレッド、ファイバー、マイクロスレッド、のどれかの生成、破壊を繰り返すの？
そりゃパフォーマンス的に厳しいんでないかなぁ…
協調スレッド、ファイバー、マイクロスレッドのどれも普通のスレッドに比べればかなり軽いけど
タスクシステムの関数コール同等の負荷とは比べ物にならないぐらい重いし。

まぁ、十年後のPC環境なら全然問題ないレベルの負荷かもしれんが。

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

>698
じゃ、自機が変更されると言う仕様を実装すると、それぞれの機体別jikiをswitch～caseで
分岐して呼び分けるわけ？

>700
じゃ、jikiの内部で、機体によって処理をswitch～caseで分岐するわけ？

**名前は開発中のものです。** · 2009/02/15(日) 15:22:52

>>701
コルーチンはスクリプト言語が実装してくれてるから、スクリプト内で使うんです。
(LuaやSquirrelがスクリプトの実行順に関して、協調型のスレッドをスタック型で内部実装してくれている)
コルーチンの生成にはちょっとコストが掛かるので、一度作ったら再利用して呼び出すことで無駄をなくしますね。
パフォーマンス的に厳しいデメリットに関しては、ネイティブ側で対応します。
(例えばSquirrelはC++のクラスをオブジェクトとして持つことも出来ます)

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

>703
スクリプト上のコルーチンの中から呼んでるC/C++関数の中でyieldしたい場合は？

**名前は開発中のものです。** · 2009/02/15(日) 15:26:41

話はすれ違ってるが設計は多分同じだ。

　擁護派　：本来スクリプト言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている
　アンチ派：本来ネイティブ言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている

どちらもスクリプト言語を適用すべき箇所まで >>641 で組むとは考えてないだろうし、
どちらもネイティブ言語を適用すべき箇所までスクリプト化すべきとは考えてないだろう。

多分論点はここかな
論点１：「ゲームエンジン部分＝ネイティブ言語の相互作用記述＋スクリプト言語解釈部」は意見一致してるよね？
論点２：「個々のスクリプト→個々のタスク」というのも性能UPが必要ならありでは？

アンチはネイティブ言語を全廃してスクリプト言語に置き換えるべきとは言ってないと思うし、
擁護派はネイティブ言語の相互作用記述を分解してタスクに置き換えるべきとは言ってないと思う。

**名前は開発中のものです。** · 2009/02/15(日) 15:26:41

>>702
まだ理解し切れていないのだけれど、
普通に継承使っては駄目ですか？

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

>>702
どう変更されるかによるなぁ・・・
例えば、自機Ａが後方に下がるシーンと自機Ｂが変わりに前方に出てくるシーンなんか入る日には
もうインスタンス２ついるわけだし操作がユーザにあるって点以外はすべてが別処理じゃね？

ペカっと光ってチェーンジ！でよくてもやっぱり変更が怖いから完全に別にオブジェクトだな・・・俺なら

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

>>703
スクリプト内で対応しているコルーチンならコンテキストスイッチとか無いからパフォーマンスは大丈夫かもね。
でもそうなるとスクリプト管理オブジェ同士の依存関係が有る場合、状態取得とかで同期処理が必要になるが…

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

>706
いや、別にそれでいいけど、このスレに約一名C++ワカランチンが常駐してるから、最底辺にあわせて
判りやすいレベルで話した方がいいかと思って。

じゃ、共通部分をtemplateにしてvariantsをfactoryから作るようにして対応するんだ。
常道だよね、やっぱり。

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

C++わからんとか、510のプログラム読めんとかは、ゲームなんか悠長に作ってる場合じゃねぇだろ。

はじめてのCでも猫でもわかるでも読んで出直してくるべきじゃね？

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

>>704
こうやって実装できなくないけど、実装しない方が良いと思う
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
速度が必要でC++で実装しつつ、関数を途中で止めて戻す場面ってのがあまり思いつかないし、
スクリプト側でcoroできれば十分かと。
なので、スクリプトからC/C++関数へはサブルーチンのみと縛るべきかな。
もし必要になればそのときに考えます。

**名前は開発中のものです。** · 2009/02/15(日) 15:34:28

>>709
そんなことして共通部分が共通でなくなっちゃったら大変だぜ

俺は継承はやらないほうがいい派
メンバで持つ派

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

>712
そんなのは結局、どこまでをまとめて一つのクラスにするかの問題だから、瑣末なことだよ。
作ったものを修正せずに済むとか思ってるほうが間違いだ。たとえメンバにしたとしても、
それを分離修正する必要があれば同じこと。

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

>>709
あ、すまん継承って軽く書いてしまったけれど、
自分も>>712と同じく、コンポジションとかいうの派

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

>>708
そこが一番のネックですね。
スレッドは協調型のみですので普通のスレッドのような並列処理に関しては、
同期処理が保障されていないです。
(基本はシングルスレッドのみで実装しているので試してみたことがない)
並列可能なスクリプト言語は今後の課題ですね

**名前は開発中のものです。** · 2009/02/15(日) 15:39:54

>>713
上の修正が末代まで来るのがやだから、集約使うのではないの？

**名前は開発中のものです。** · 2009/02/15(日) 15:42:33

集約のメリットは、その部分を丸ごと交換できること。
修正の手間はさほど変わらないよ。とくに機能を分離する場合はね。

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

>>715
あれ？
>フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
ってことはフレームをまたぐオブジェクトが複数ある場合は必然的に
並列処理が必要になるんだよね？

>並列可能なスクリプト言語は今後の課題ですね
となってしまうとその方法（コルーチン）では使い物にならないんじゃない？

結局、スクリプト使ったゲームで一部データ駆動されてるものも
オブジェクト単位ではタスクシステムなりに乗っかってスクリプトのupdate部分がオブジェクト数分定期的に呼ばれる
という実装なんじゃないかな。

でないとマルチスレッドの複雑性の問題をスクリプトが抱え込むことになるような…

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

実際の話、C/C++のcoroutine使うにしてもスクリプトのcoroutine使うにしても、それが中断してる最中に
内部の状態変更要求を外から通知された場合、どう処理するかが問題。

実行途中のcoroutineを強制的に終了したとしても大丈夫かどうか。

**名前は開発中のものです。** · 2009/02/15(日) 15:55:33

>>715は現状ではシングルスレッド＆コルーチンを使っているんじゃないの
マルチプロセッサでのネイティブスレッドとは違って並列処理にはならないので
同期制御の類は要らないはず
時分割された処理の継続をあからさまにFSMのような形で実装するのと
違って、自然に書けるのがコルーチンの利点で、プログラムカウンタや
スタックのリストアを処理系がやってくれる

>>715が「課題」と言っているのは、マルチコアでのパフォーマンスが求められる
ようになった場合にどうするか、という類の話では

**名前は開発中のものです。** · 2009/02/15(日) 16:00:34

遅レスだが、

>>699
＞コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)
ってのは結局・・・

//万里ゆうじ氏が著書で紹介していたタスクシステムを参考
struct Task
{
//(1) データ更新・描画処理用関数ポインタ
void (*Update_n_Draw)(Task*);

//(2) データ記録用バッファ。場合によってはメンバ変数に分解して固定。
char WorkBuf[WOKK_BUF_SZ];

//以下省略
：　　　　 //タスク・チェーン結合用ポインタ
};

上のタスクシステムで言うところの、
１．Task構造体の生成・破棄
２．（１）の関数の切り替え
３．（２）のメンバ変数への分解
の処理パターンを、ある程度、限定・抽象化して、スクリプト駆動でルーチン化してるだけなんじゃね、実質？
コルーチンの生成・フレーム間維持・破棄のために、結局バックグラウンドで、タスクシステムが必要でしょ。
データのまとまりって言うのは、結局構造体だ。

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

全然違うよw

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

>>718
>>720で合ってます。
現在の組み込みスクリプト言語はシングルスレッド仕様で、
マルチスレッド化やマルチコアの恩恵は受諾できないと思います。

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

>>723
そーなると結局
コルーチン同士のリソース同期処理はどうなったの？

これはスクリプトの仮想マシンがシングルスレッドかマルチスレッドか、というのとは
別の話なのだが。

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

>>722
詳しく

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

コルーチン同士のリソース同期処理？？
同期処理はLuaやSquirrelの仕事ですね。こちらが意識する必要はないです。
そもそも走っているスクリプト解釈スレッドは1つだけです。

複数のコルーチンをつくり、中断／再開を行うことで擬似マルチスレッドっぽいことはできますが、あくまで擬似です……。

あくまでコルーチンはコードの見晴らしの為だけに使います。(使うのも使わないのもスクリプト実装者の裁量による)