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

**名前は開発中のものです。** · 2009/05/07(木) 13:33:06

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

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」と明示してください
　そうでない場合はカスタム版であることを明示してください

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

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

>>628
> 慣れてる人間にとっては使うほうが効率よく作れる。

もうこれしかないよな。これなら客観的な文書化ができないのも納得だよ。

このメリットは「慣れ」という個人に依存したものなので、元からタスクシステムに
慣れてない（むしろ嫌いとか）な人にとっては無いのと同じ。

繰り返し求められている「メリット」とは、何か客観的・普遍的なものだろう。
「メモリプールがあれば頻繁な確保・解放をしてもパフォーマンスにひびかない」だとか、
「仮想関数があればオブジェクトごとに異なる記述を書くのが楽」だとか、
「動的コンテナクラスがあれば煩雑なメモリ管理の手間が省ける」だとか。

**名前は開発中のものです。** · 2009/07/23(木) 04:09:12

俺は上司にそんなにコルーチンとやらがいいならメリットを説明してみろと言われたが、
説明している最中にいちいち反論されて結局ケンカになった

「メリットを言え」は「絶対にお前を言い負かすからかかってこい」と同義
別に教えを請うているわけではないのがポイント

**名前は開発中のものです。** · 2009/07/23(木) 06:41:26

>>636
そいつのレスに同意ってことでいいの？
だってそれお前のＩＤのレスじゃねーじゃん

**名前は開発中のものです。** · 2009/07/23(木) 07:40:09

>>638
一言で結論から言わないからじゃない？

**名前は開発中のものです。** · 2009/07/23(木) 09:48:56

メリットやデメリットは何かと比較したときに初めて出てくるもので
比較対象の無い文脈でメリットやデメリットを問うのは論理的におかしい。

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

>>640 一言で結論を言うなら「いいものです」で終わりだろ？

詳しく説明しろ、って言うから説明してやればいちいち文句言う。
ただいいがかりつけて優位に立ちたいだけの奴は見捨てるしかない。

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

言いがかりに反論するのもプレゼンのうち

**名前は開発中のものです。** · 2009/07/23(木) 15:51:59

コーディングスタイルに関する議論を見ているようだ

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

>>642
関係無いことしゃべり続けるからじゃない？
聞き手と話し手がいて会話って成立するじゃん

**名前は開発中のものです。** · 2009/07/24(金) 00:01:08

>>628
何と比較して便利な道具だと言っているのかが気になるな

・生成消滅が頻繁に発生する

つまり短命オブジェクトを扱うにはタスクシステム（>>2）は何かより優れていると
具体的に何と比較してどの点が優れているという話？
もしもそれがタスクコントロールやタスクマネージメントではなくメモリ割り当ての話なら
分離して考えたほうがいいと思うぞ。メモリアロケータはあくまでもメモリアロケータ

・オブジェクト毎に挙動が異なる

つまり複数のステートマシンを扱うにはタスクシステム（>>2）は何かより優れていると
具体的に何と比較してどの点が優れているという話？
もしも振る舞いを決定するステートが関数ポインタかそれ以外（インデックス番号や
オフセット値）かという話なら、それは実装対象や開発環境やタスク粒度に依存した話で
一概にどちらが優れているとは言えないと思うけどな。特筆するほどの特徴あるか？

・一定間隔で更新と描画を行う

つまり周期駆動で逐次処理するにはタスクシステム（>>2）は何かより優れていると
具体的に何と比較してどの点が優れているという話？
複数のステートマシンの振る舞いを定周期で更新する。大半のビデオゲームの
共通項だし、デジタルコンピュータの登場当初から科学技術計算や色んな産業で
当たり前のようにみんなやってたことだが、タスクシステム（>>2）に何か特筆する
ほどの特徴あるか？

**名前は開発中のものです。** · 2009/07/24(金) 13:29:33

>>638,642
言い負かされるのがわかってて、それが嫌だからタスクシステムの具体的なメリットに
ついては説明したくないってことですね、わかりますん。

> >>640 一言で結論を言うなら「いいものです」で終わりだろ？
説明能力なさすぎ。↓せめてコレぐらい示してやれよ。
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%AB%E3%83%BC%E3%83%81%E3%83%B3

**名前は開発中のものです。** · 2009/07/24(金) 21:20:19

自分で理解できないことを他人に頼ろうとかいう夏厨がいるのか。
ゆとりが馬鹿だというのはホントだな…。

**名前は開発中のものです。** · 2009/07/24(金) 21:31:30

ageてまで必死だなｗ
結局、メリットは説明できずか
バズワードにもほどがあるなｗ

**名前は開発中のものです。** · 2009/07/24(金) 22:58:44

>>646
慣れてる道具のほうが効率がいいっていってるだけで
優れてるから使ってるなんてどこに書いてあるんだ？

**名前は開発中のものです。** · 2009/07/24(金) 23:07:35

>>642
>>638だが、俺はアンチタスクだよ
単に、最初から話を聞く気がないんのにもっともらしい言い方してる奴が嫌いなだけ
同様にタスクのデメリットを説明してやる気もない。タスク好きは別に聞く気がないだろうし

**名前は開発中のものです。** · 2009/07/24(金) 23:08:21

あ、間違った >>647へのレスね

**名前は開発中のものです。** · 2009/07/24(金) 23:10:26

>>649
>>628 を必死でスルーするのは負けを認めたくないから？

**名前は開発中のものです。** · 2009/07/24(金) 23:47:24

「どの言語でも論文や詩を書くことは出来るけど、やっぱり母国語が一番効率よく書けます」
って言うマルチリンガルに向かって
「母国語つかうメリット教えろ。優れてるから使うんだろ？何が優れてるんだ？」
とか聞く馬鹿いないわな。

**名前は開発中のものです。** · 2009/07/24(金) 23:51:05

>>654
いや、普通聞くだろ

**名前は開発中のものです。** · 2009/07/24(金) 23:56:46

>>655
既に本人が理由言ってるじゃん。
「効率よく書けます」って。
よほど頭が悪くない限り理解できるでしょ。

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

>>656
なぜ効率よく書けるのか興味あるな。
日本人のマルチリンガルは「日本語って難しい」って思ってるっていうイメージがある。

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

>649
『ゲームを作るのに便利』というだけで理解できない人が、まだまだ居るんだなぁ…。

そういう人は、「タスクシステム」なんてただの言葉に、どんな壮大な夢をもってるんだろうか…？

**646** · 2009/07/25(土) 00:27:31

どっかの誰かは言い負かし合いが目的らしいが俺は違うな
そもそもゲームプログラマというのは99％以上は計算工学、計算機工学、etcの
専門家ではない。そういう者同士で喧嘩をする気は毛頭ない

>>650
慣れると効率よく作れるというのは優れているということなんだよ。
そして効率よく作れるというのは比較対象があるから言えることでもある。

比較対象はなく最初からの刷り込みでこれしか知らないから
これは便利である、ということはないと思うんだね

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

>>659
> 比較対象はなく最初からの刷り込みでこれしか知らないから
この前提はどこからわいて出たの？

**646** · 2009/07/25(土) 01:08:53

そこは無視していいよ

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

>>661
無視していいなら初めから書くなや。

**646** · 2009/07/25(土) 01:13:36

ところで ID:UHwH8QEw = ID:uHfnwL7s なのかな？
なんか随分と警戒されちゃってるなぁ。。。

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

ID:UHwH8QEw = ID:uHfnwL7s でOK。
IP変わった理由なんて知らんがな。プロバイダにでも聞いてくれ。

**646** · 2009/07/25(土) 01:16:12

それで、その一文が気に入らないからどうするんだい？

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

べつに。
やばくなると「そこは無視して」って人間に何か期待してるとでも？

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

>>660、>>662みたいな過敏な反応が面白すぎる
>>659は「、ということはないと思うんだね」て書いてんだから
>>659の予想が的中してるなら拘る必要何もないのにな

**646** · 2009/07/25(土) 01:28:07

俺が>>659で書いた

>慣れると効率よく作れるというのは優れているということなんだよ。
>そして効率よく作れるというのは比較対象があるから言えることでもある。

ここには異論はないということでいいのかな？

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

「質問に答えた人にとっては優れている」なら異論はないがね。
「質問した人」や世界中のゲームプログラマにとってってのなら条件が足りないから否だ。

**646** · 2009/07/25(土) 01:54:14

>>669
＞「質問に答えた人にとっては優れている」なら異論はないがね。

そう、それで構わない。それ以上は端から求めてない。
君にとって優れている。その訳を>>646で質問したんだ。

君は
・生成消滅が頻繁に発生する
・オブジェクト毎に挙動が異なる
・一定間隔で更新と描画を行う
の三点を簡単に実装できる道具とした。
簡単に実装できるというのもやはり優れてるということ。
君にとっては、何かと比較して優れた道具なんだ。
具体的に何と比較してどの点が優れているという話？

それが>>646の質問

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

プラットフォームやマシンスペック、ゲームジャンルや仕様、プログラマのスキルや人数、
チームが過去にどんな方法でどんなゲームを作ったか、
などの条件で「優れている」の最適解は異なるからそもそも無意味な質問だがな。

それらの条件が一切提示されていない状態では
「タスクに適したゲームなら」という暗黙の前提つきで素組みやActor、Stepと比較して慣れてるってだけの話。

**646** · 2009/07/25(土) 02:52:35

>>671
＞プラットフォームやマシンスペック、ゲームジャンルや仕様、プログラマのスキルや人数、
＞チームが過去にどんな方法でどんなゲームを作ったか、
＞などの条件で「優れている」の最適解は異なるからそもそも無意味な質問だがな。

うんにゃ。君にとっての「便利」「簡単」等の優れた面が成立する条件でいい。
それで構わない。それ以上は端から求めてない。
君にとって優れている。君の好みの条件付きで、その訳を>>646で質問したんだ。

でなければ>>628は

プラットフォームやマシンスペック、ゲームジャンルや仕様、プログラマのスキルや人数、
チームが過去にどんな方法でどんなゲームを作ったか、
などの条件で「簡単」「便利」「慣れている」の最適解は異なるからそもそも>>628は無意味な主張になる

俺はそういう否定のしかたはしない。だから誰かさんと違って言い負かす気は毛頭ないと言ってる

**646** · 2009/07/25(土) 03:16:49

だから
「タスクシステムに適したゲームなら」という条件下で何かと比較して「簡単」「便利」という話でいい
「タスクシステムに適したゲームなら」という条件下で何かと比較して「慣れてる」という話でいい

条件は暗黙にしなくていい。むしろ徹底的に君に都合の良い条件を添えてくれればいい
「タスクシステムに適したゲーム」は適当に有名どころの既製品を例にあげてくれて構わない。ラクだろう。
その上で「素組み」、「Actor」、「Step」と比較して「簡単」「便利」というのが、他の分からず屋にも理解されるだろう

①タスクシステム
②Step。これはLogicianLordが言うところのステップ処理だろう。
③素組みはまぁ素組みだろう。
④Actorはアクターモデルだろう。

スケジューリングにおいて④だけが異端。イベントトリガ型。
①②③はタイムトリガ型。ポーリング。cyclic executiveの仲間。

④のみで開発というのは聞かないな。①②③とのハイブリッドになるだろ

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

Actorはタスク以上に「何でもあり」なんだがなぁ・・・
メインループで「update」と「draw」のイベントシグナルを発行すればタスクと同じようなことできるし。

タスクに適したゲームっていえば少人数（プログラマ１～３人ぐらい）、低スペック（最高でも携帯機ぐらい）
で2D弾幕STGとか、ACTとかかね。
Actorやマルチコアでバリバリ動きます！って数億もするフレームワークは大げさすぎるし
Stepはアクション系とは相性悪い。素組みはめんどくさすぎでありえん。
となるとタスクじゃね？となる。

テトリスとか数当てゲームなみに単純なゲームならタスクでも大げさすぎるので素組み。

シュミレーションとかアドベンチャーとか、オブジェの生成消滅がフレーム単位ではなく、
状態推移とシーン管理がメインならStepとスクリプトを合わせて使う、とか。

PS3/360クラスのマシンで3～40人プログラマ使ってMMORPG作るよ！プログラマは派遣や新人もいるよ！
とかなら逆にタスクは絶対使わん。Actorか商用フレームワーク。

そんな感じでケースバイケースだ。

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

その商用フレームワークってどんなタスクシステムを使ってるの？

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

Actorという名前のタスクシステム

**名前は開発中のものです。** · 2009/07/26(日) 23:13:20

Actorの話はもう飽きたー

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

>>658
お前みたいなのが去年
「web2.0を理解できないなんて！」とほざいてたんだぜ

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

まだやってるんだな。
タスクシステムはファイルシステムのタスク版。
やってることもメリットもほぼ同じ。
これで理解できたかい？アンチ諸君

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

updateやらdrawやらはあってもなくてもどっちでもよい。
とにかくタスクを管理するものがタスクシステム。
でもそもそもタスクって何なんだといわれると、まぁこれは近代の言い方だとインスタンスだわな。
そんで、なんでインスタンスを管理する仕組みがわざわざ必要なのかって言われると、
それはCなどの一般的な言語にはインスタンスを管理する仕組みが用意されてないから。
ないから作る。それだけ。

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

変数システムはファイルシステムの変数版。
とにかく変数を管理するものが変数システム。
でもそもそも変数って何なんだといわれると、まぁこれは近代の言い方だとインスタンスだわな。
そんで、なんでインスタンスを管理する仕組みがわざわざ必要なのかって言われると、
それはCなどの一般的な言語にはインスタンスを管理する仕組みが用意されてないから。
ないから作る。それだけ。

なんかコピペになりそうな勢いを感じるなｗ

**名前は開発中のものです。** · 2009/07/27(月) 07:52:32

>>680
「～を管理する」で何かを説明した気になられても困る。
http://www.google.co.jp/search?q=SomethingManager

インスタンスを管理って、何のこと言ってんの？
コンテナへの登録・削除？
public/private とかのアクセス制御？
でもそれじゃぁ C++ では不要ってことになりそうなんだけど・・・

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

だからファイルシステムと同じだっていってるだろ。
ファイルシステムがやってることとそっくり同じことをメモリ上でタスクにたいして行う。

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

>682
それで理解できなきゃ、もっと知識つけてから来いよ。

それとも、2chでタダで得られる程度の情報に、何かとてつもないコトでも期待しているのか？

**名前は開発中のものです。** · 2009/07/27(月) 22:49:35

ファイルシステムがどうのとか、まーた相似性の希薄なもの
引っ張り出して偉っそうにふんぞり返ってる老害が湧いてるようだな
もう少しマシな例えが思い浮かばないのかね

>ギャラクシアン以外をタスクシステムと呼んでるのは某よっちゃんいかの人だけだよ
>固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある
>そもそも固定長レコードはフラグメント解消のものではなかった
>バナナでクギを打った所に新規性があるんだよ
>トンカチあるから必要ないよねっていうのは別の話

なんかこれ思い出した。この後に速やかに論破されてたけど

**名前は開発中のものです。** · 2009/07/27(月) 22:53:23

残念ながらもっともマシなたとえがファイルシステムなのだよ。
逆にほかに思いつくか？
というか、ファイルシステムの真似しておけば間違いないし、
それ以上のことをやろうとすると失敗する。
ファイルを制するものがコンピュータ界を制するのだよ。←これ俺の格言。

**名前は開発中のものです。** · 2009/07/27(月) 22:58:23

>>683
たとえばファイルシステムはファイル名とディスク上の記憶位置のマッピングを
提供するんだけど・・・ C/C++ にはこれを行うための変数というものがある。

たとえばファイルシステムはディスク上の使用領域と未使用領域を切り分けて
ファイルの作成・削除に備えたりするんだけど・・・ C/C++ にはこれを行うための
ヒープがある。

たとえばファイルシステムはディレクトリによってファイルの階層構造を実装したり
するんだけど・・・ C/C++ にはこれを行うための構造体やクラスや標準コンテナがある。

というわけで、「Cなどの一般的な言語には～用意されてない」と言われている「管理」で
何のことを言ってるのかはっきりわからない。

そこらへんもう少し明示してもらえると、もっといろいろ伝わるんじゃないかと思うんだけど。

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

>>686
だったら具体的に何のファイルシステムの中の何の要素が
タスクシステムの何に相似であるのか書いてみな

どうせ各処理単位の属性情報。処理単位の何らかの親子関係をあらわす階層構造。
その程度だろ

固定時間刻みで処理単位のコレクションを走査してぶん回してりゃタスクシステムなのに
どこかの何かのファイルシステムを真似てゴテゴテとアプリ依存の装飾加えてるだけだろ

**名前は開発中のものです。** · 2009/07/27(月) 23:04:53

MSもOracleもGoogleもファイルを制してきた者たちなんだよ。
一方、マックバイナリなんて分けのわからないもの付けたり、GUIにばかりこだわったAppleはあの様。
だから健全な一般市民たる我々は、余計なこと考えないで、常にファイルのことだけ考えとけばよい。
タスクシステムもファイルシステムの真似だけしとけば間違いない。歪ねぇということ。

>>687
ヒント：URI

**名前は開発中のものです。** · 2009/07/27(月) 23:06:40

>固定時間刻みで処理単位のコレクションを走査してぶん回してりゃタスクシステムなのに

そういうことをやりだすと失敗する。Appleのようにな。
さっきから言ってるだろ。ファイルシステムの真似しとけば問題ないって。
ファイルシステムにそんなのあるのかよ。

**名前は開発中のものです。** · 2009/07/27(月) 23:07:44

だいたいだな

>でもそもそもタスクって何なんだといわれると、まぁこれは近代の言い方だとインスタンスだわな。

システム内部の処理単位はメインフレームの時代においても現代においてもタスクだが
おめーのタスクってのはインスタンスで置換できるのか。そいつは面白いな詳しく話せよ
用語の使い方がそもそも狂ってることを自ら吐露しちまった感じだな。語るに落ちたか？
そういや「近代～」とかやねう先生も好きだよね

**名前は開発中のものです。** · 2009/07/27(月) 23:12:00

>>690
何がAppleだよ。言うに事欠いて知能障害起こしてんじゃねーの？
てめぇの村社会の中でタスクシステムがどんな独自の進化を遂げてるのか
知らないけどよ。その奇形が淘汰されずに生き残るウリがあるなら話してみ？

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

説明する気は無いみたいだし、発言内容からいってがんばって情報を引き出しても実りが
なさそうだし、もう数ある珍説のひとつってことでいいや。

**名前は開発中のものです。** · 2009/07/27(月) 23:15:40

処理の単位なんて発想が馬鹿げてるんだ。処理に単位も糞もあるかよ。
処理はCで言うところの関数なわけで、必要に応じて呼び出すまで。
古い価値観は脱ぎ捨てようぜ。

**名前は開発中のものです。** · 2009/07/27(月) 23:18:05

ところで、マックバイナリと仮想関数って似てるよね。
つまりはそういうことだ。

**名前は開発中のものです。** · 2009/07/27(月) 23:21:45

>>694
話を逸らして逃げてんじゃねーよ
ついでに本性を攪乱するためにアンチの振りしなくていいからな。
おまえは正真正銘のタスク親派の老害だよ。タスクシステム＝ファイルシステム
まぁ言いたいことは分からなくも無いが。様々な側面で粒度の異なるものを
引っ張り出して相似性を見出すというなら具体的にどこがどこにどのように
対応してるのか説明できなきゃな

**名前は開発中のものです。** · 2009/07/27(月) 23:45:08

だからタスクがファイルに対応してるってさっきから言ってるだろ。
タスクシステムっていう名前がいやなんだったら、もう、ファイルシステムに改名しちゃえ。

**名前は開発中のものです。** · 2009/07/27(月) 23:56:53

大体オブジェクト指向のアクセス制限って何であんなに融通利かないの？
公開すると全員から見られるし、非公開にすると、自分しか見られない。
アクセス制限に応じた分だけインターフェース作れってか？やってられるか。
friend指定とかもできるけど、何でクラスしか指定できないわけ？
俺は人を指定したいわけ。あの人なら信用できるから公開する、とかしたいわけ。
friend ひろゆき;　とかしたいわけ。クラスとクラスが友達になっても、それは現実に即してないだろうに。
ファイルシステムだと普通にできるのにな。なんだろな

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

それは型システムの話だろ

**名前は開発中のものです。** · 2009/07/28(火) 00:21:53

インスタンス単位でアトリビュートは異なるのは当たり前。
何故そこで型システムを批判するのかということだな

どうしても型システムが提供する仮想関数で
インスタンス単位のアトリビュート設定・変更がしたいなら
vptrを書き換えなさい。

**名前は開発中のものです。** · 2009/07/28(火) 00:29:08

何言ってんだこの人は。誤爆か？

**名前は開発中のものです。** · 2009/07/28(火) 00:32:46

もうなんちゅーか、汎用プログラミング言語に対する固執の仕方がちょっとおかしいな。
DSLで対応しときゃいいことまで無理やり汎用プログラミング言語でこなそうとする必要は
どこにもないわけだ

**名前は開発中のものです。** · 2009/07/28(火) 00:35:21

>>701
ゲーム専卒ってどんな気分なの？教えてくんない？

**名前は開発中のものです。** · 2009/07/28(火) 00:36:36

何を作るかが決まってないのに
どう作るかが決まるわけないだろうに。

タスクってのはゲームをどう作るか、の方法の一つにすぎない。
何を作るかが無くてどう作るかだけの話では永遠に結論は出んよ。

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

今湧いてるのは、タスクはファイルシステムと同じ君とDSL君？

DSL君は久々という感じがするね。

**名前は開発中のものです。** · 2009/07/28(火) 00:42:25

>>704
上のほうで誰かが問い詰めてタスクシステム使いが想定する好都合な条件を引っ張り出してたよ
>>674
＞タスクに適したゲームっていえば少人数（プログラマ１～３人ぐらい）、低スペック（最高でも携帯機ぐらい）
＞で2D弾幕STGとか、ACTとかかね。

**名前は開発中のものです。** · 2009/07/28(火) 00:44:25

>>705
悪いが俺にはあのウンコポエマーの真似はできねーな
まぁ率先してちょっかい出してた人間ではあるが

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

DSLとかマヤカシだろJK。
あれはプログラムの入出力を固定化することで、プログラムを簡素化するもの。
古くはCの標準入出力に始まりだな・・・

ゲームのマップデータやセーブデータ、さらにはBITMAPファイルですらDSLの一種なわけで。
普通にプログラム書いてりゃDSL使いまくりだわな。
ただ、マップデータはマップデータしか表現できないわけで、その辺がDSLのDSLたるところというか。
だからそれらのデータ群(DSL)を汎用言語で互いにコミュニケートさせなければならないわけだが、
そのための一つのアイデアがフレームワーク的な意味でのタスクシステムでもあるわけで。

そういう土台の上で話している俺からしてみれば、
DSLのような下等な一パーツ風情が何か解決してくれるの？って感じなんだが。

>>703
いや、普通にどのレスに対するレスなのか意味不明だろ。
唐突に何か語り始めて。

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

>>674
で結論が出てるみたいだな・・・

ファイルシステム云々ってのは追い詰められたアンチの自演か？

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

お、違う人なのか。
スマンカッタ。

**名前は開発中のものです。** · 2009/07/28(火) 00:59:22

フレームワーク的な意味でのタスクシステムとかほざく劣化やねうが出没してるようだが
これ、言うは簡単。具体的に何なのって聞くと黙るんだよなｗｗｗ
ま、説明を始めたら実は既存のゲームエンジンやフレームワークを真似て
>>2にグチャグチャと後付け増改築した雛形サンプルプログラムを
フレームワークっつってるだけなんだろうけどな

フレームワークっていえばなんとなくかっこいいから

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

ごちゃごちゃくっつけないんだって。
タスクシステムの場合、ファイルシステム以上の機能を付けるのはやりすぎ。
あえて、あえて。

**名前は開発中のものです。** · 2009/07/28(火) 01:06:14

>>711
お前の言うフレームワークの定義を具体的に説明してみな。

> フレームワークっていえばなんとなくかっこいいから
説明できなきゃ自己紹介だなｗｗｗ

**名前は開発中のものです。** · 2009/07/28(火) 01:10:21

これはアンチの自演だとかちょっと面白い発想だな
フルボッコにされた無能な味方は迅速に見切り付けて華麗に切り捨てる
なかなかうまい手だと思ったｗ

**名前は開発中のものです。** · 2009/07/28(火) 01:13:48

劣化Simulaみたいな言語をDSLと呼んだらマズイかな

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

単純に、劣化Simulaで出来ることは全てC++でも出来るだろうに、
なぜあえて、劣化Simulaを使う必要があるんだ、と思うね。
中途半端なDSLが一番の悪なんだ。BITMAPみたいな大人しいのは正義。

**名前は開発中のものです。** · 2009/07/28(火) 01:29:50

劣化Simulaってのは説明になってなかったな
coroutine
discrete event simulation
この2点をパクった

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

そっちメインで使うんなら、その劣化Simulaがむしろ汎用言語で、
C/C++がAPI叩いたり速度稼ぐという目的のDSLじゃね？

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

いや、汎用にはなってない
ゲームのシミュレーション部を記述することにのみ特化したスクリプト言語。
FSMの相互作用を記述する目的しかない

**名前は開発中のものです。** · 2009/07/28(火) 01:53:45

というか、コルーチンと聞くだけで虫唾が走るのは俺だけか？
たとえば、ジャンプしながらパンチも出来るキャラの制御を考えたとき、
ジャンプの処理とパンチの処理は別々のコルーチンで処理しないとコルーチンの意味がないけど、
それぞれのコルーチン間での連携はどうするんだって思うね。
フラグでやるの？どっちみち汚くならね？いやこれは純粋に質問なんだが。煽りとかでなく。

**名前は開発中のものです。** · 2009/07/28(火) 01:54:48

>FSMの相互作用を記述する目的しかない
その程度の大人しいDSLだったらいいんじゃね。

**名前は開発中のものです。** · 2009/07/28(火) 01:55:11

>>720
そんなもんにコルーチン使うなボケ

**名前は開発中のものです。** · 2009/07/28(火) 01:55:40

でも俺はコルーチンとか嫌いだからね。

**名前は開発中のものです。** · 2009/07/28(火) 01:55:54

ボケはいい過ぎた。寝たいのだ。寝る

**ID:KvaJ18tR** · 2009/07/28(火) 01:56:51

>>722
だったらコルーチンなんて使い道なくね？

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

>>725
このクルクルパーの登場のタイミング、なかなか空気読めてるよね

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

誰でもいいからコルーチンの有効な使い方教えてよ。
タスクシステム以上に謎なんだが。

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

アスペクト指向？

**名前は開発中のものです。** · 2009/07/28(火) 03:42:48

コードがあっちこっちに散らばらなくて汚くならない

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

>727
スレッド使ったこと無いのかな？

**名前は開発中のものです。** · 2009/07/28(火) 21:17:54

そこなんだよ。
コルーチンって要はお手軽スレッドだろ。
スレッドって必要に迫られて使うことはあるけど、積極的に使うようなものか？
お手軽スレッドってことは沢山作ることを前提にしているわけだが、
そんなほいほいスレッド100本とか作りたいと思うか？
なんかそのへんずれてるんじゃないかと。

>>729
むしろ最終的には当初の予定に反して散らばりそうな予感。

**名前は開発中のものです。** · 2009/07/28(火) 21:24:30

たとえばアクションゲーム作るとして、
ジャンプはジャンプ用のスレッドで処理、歩くのは歩く用のスレッドで処理、攻撃は攻撃用のスレッドで処理するとして、
互いの処理に依存があった場合、どうやってコミュニケートさせるんだってなる。
各々にフラグかなんか用意しておいて、
互いの処理が互いにそれらしく振舞うように互いのフラグを監視しながらも個々の処理は独立して動かすとか、
意味不明だろ。

**名前は開発中のものです。** · 2009/07/28(火) 21:48:51

>>732
依存がないようにする
簡単に言えばそれぞれの状態が直交するようにすれば
コンポジットして並列に動かしてもいいんじゃないか？

**名前は開発中のものです。** · 2009/07/28(火) 21:58:26

>>732
その問題ってなんでも起こるよね
それが解決できるなにかを主張してるわけじゃなくて
それ自体を主張されてもなんか困るよねｗ
お手軽スレッドを「ね？お手軽でしょ？」っていわれても
それらを纏め上げるのは正直地獄をみる
カプセル化して個々のスレッドからは影響するほかのスレッドの処理を除くとしたら
当然スレッド同士を繋げるスレッドが必要になる
２つのスレッドが関連するなら１つのスレッドがさらに必要になる
関連処理＝スレッドの勢いで増えていく
誰も説明がないからとりあえず他のスレッドと並列に扱うと酷いことになる
しかし、スレッドの扱いについてはなにも触れられない
きっとツリー構造になるだろうが、これはなにかに似てないだろか？
普通に組んだときとなにか違うだろか？この仕組みのアドバンテージってなんなんだろか？
と疑問になる

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

そんなことしたらゲームデザインに制約が出来るぞ。
コルーチンの仕様にゲームデザインを合わせるなんて本末転倒もいいところだ。
それにゲームの面白さってのは色々な処理に依存性があるから生まれてくるってのもあるだろ。

**名前は開発中のものです。** · 2009/07/28(火) 22:05:10

>>735
何をいってるのかさっぱり理解できない
俺はなんでもできる
面倒であんまり意味ないけど
俺は上記構造でもなんでも作ってみせる
意味のない発言をするな