タスクシステム総合スレ 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/14(金) 02:05:40

>>42
必要ないものは取り入れる必要はない。コンプレックスは持つ必要ない。
俺も同人ゲーを作ったことあるが規模相応の簡素なコーディングで済ませてた。
いわゆるタスクシステムとか紹介されてるあのヘンテコな仕掛けも不要だった。プライオリティ？ハァ？って感じだ。
敵の配列が弾の配列があって。そんな感じだ。
タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる
配列厨のコードそのものだ。

同人ゲームを悪く言うつもりで書いたわけではないのだが、もし>>40-41の「同人ゲーム～」の部分が気に障るなら
そこは撤回する。すまなかった

**名前は開発中のものです。** · 2008/11/14(金) 02:05:58

>>49
luaはver4のころちょっとかじっただけなんだけど、スクリプト処理のために
組み込んでみようとは思ってたんで、考えてみるよ。ありがと。

**名前は開発中のものです。** · 2008/11/14(金) 02:22:54

>>44
多種多様な人間が多種多様なジョブ（ユーザープログラム）を記述することになると
「FSMモデルのみ」という拘束条件は必ず無理が生じる。これはやれば分かるという他ない
RAM数KBの組み込み用モジュールのモニタプログラムでもコンテキストスイッチをサポートしたがる。
FSMモデルでジョブを記述させると色々面倒くせーことになるから。説明するよりも組んでみたほうが
分かるという他ない

＞別スレッドで～

よく分からんがコンテキストスイッチをサポートしたくないがためだけに
何やら複雑怪奇な仕組みを導入する話のような気がしてならない
素直にLuaとか使ったほうがいいよ。というか眠いばいばい

**名前は開発中のものです。** · 2008/11/14(金) 02:29:54

>>50
＞規模相応の簡素なコーディングで済ませてた
そこんとこがよくわからんのだよなあ。
単純な配列とループで組めて問題ないならぜんぜんOKでしょ。俺もそうする。

ただ、サンプルでも使ってる GLLib の人のサンプルソースは単純ループ
だけど、けっこうきつい印象を受けた。

俺も「タスクシステム」を採用するだけでバラ色の未来が開けるとは思わん
(まだかじっただけなんで実はすごい泥沼が待っているのかもしれない)けど、
そこそこ使いまわしが効いて、それなりに見通しがいいように思う。

要は適材適所じゃないかと思うんだが、用語を使うことすら非難するほどの
問題があるの？

**名前は開発中のものです。** · 2008/11/14(金) 02:37:14

＞何やら複雑怪奇な仕組みを導入する話のような気がしてならない

こういうのは、同意できるんだよね。
そこそこ便利そうだけど決してわかり易い仕組みとはいいにくいから、
なんか泥沼にはまりそうな気がする。

まあ、小学生の感想文ですまん。

**名前は開発中のものです。** · 2008/11/14(金) 02:38:50

タスクシステムが有効なのは小規模システムだな
メモリの単位がkまでの環境
Mになると不要

**名前は開発中のものです。** · 2008/11/14(金) 02:46:45

>>55
キャッシュじゃねーかw<k
あー、PICのプログラムとかそれっぽい。

**名前は開発中のものです。** · 2008/11/14(金) 02:49:24

AVRは俺の嫁

**名前は開発中のものです。** · 2008/11/14(金) 07:52:52

i君はルサンチマンに満ち溢れてるなｗ

**名前は開発中のものです。** · 2008/11/14(金) 16:00:01

>>48
Luaの文法が嫌いならSquirrelもいいよ。
ム板でスレタイ検索してみてくださいな。

>>53
自分の書いた文章で古い設計方法に名前がついたことにより
予期せぬ形でもてはやされるようになってしまった。
そのことに対する責任感から現代的な知識を伝えると共に
言葉狩りを行っている。

彼の行動はこのように解釈することもできる。あくまで妄想だが。

**名前は開発中のものです。** · 2008/11/14(金) 19:49:55

タスクシステムを使ってるプログラムの
メモリ・ポインタまわりのバグり具合はハンパじゃないな
フツーに書けとあれほど言ってるのにやって
ゲームと違うところでいっつも四苦八苦してるとなりのプロジェクト

あんまりポインタ周りのバグが酷いからプロジェクトをまたいだ会議で
原因を指摘してやったのにまだごにょごにょ言ってる
もう、お前（となりのプロジェクトのウンコリーダー）に逃げ場はねぇよ

グローバル変数とタスクシステムとポインタの悪用は絶対に全部セットなんだよな
タスクシステム使わないプロジェクトはグローバル変数も使わないしポインタの悪用もしない
だからプログラムがメインから必ず終えるし
組み込むべき箇所もすぐにわかる
第三者がきてもすぐに全体が把握できるってのはでかいね

もういい加減に信者も目を覚ますべき

**名前は開発中のものです。** · 2008/11/14(金) 20:17:38

メモリ、ポインタを怖がるってプロとしてどうなのｗ

**名前は開発中のものです。** · 2008/11/14(金) 21:58:54

馬鹿が触ったポインタほど怖いもんはねえぞ

**名前は開発中のものです。** · 2008/11/14(金) 22:21:45

確かにコンテキストスイッチがないとグローバル変数に頼らざるをえない。

コンテキストスイッチがあったところでスパゲティにする奴はするけどなw

**名前は開発中のものです。** · 2008/11/14(金) 22:34:07

nullポはいねぇがあ～？

**名前は開発中のものです。** · 2008/11/15(土) 00:05:57

>>48
昔Delphi使ってたから、馴染みはあるんだけど、C/C++と併用すると間違うんだよね。
演算子とか。

>>60
あー、それは俺も気になった。
親クラスのメソッド呼んだら、内部で自分自身を削除してて戻ってきたところで落ちるとかw
俺がタコなだけなんだけど、基本的にポインタを多用するスタイルみたいだしな。
几帳面なやつ向きかも。実はちょっとびびってるw

**名前は開発中のものです。** · 2008/11/15(土) 00:27:43

それタスクシステムとかいうナニに限った話ではないと思うんだけどな
相互参照オブジェクト（インスタンス）の取り扱いについてのごく初歩的な
あらゆるプログラムに通じる基本的なお作法の話だと思うんだ

**名前は開発中のものです。** · 2008/11/15(土) 00:34:05

ポインタなくてもタスクシステム組めるけど？

**名前は開発中のものです。** · 2008/11/15(土) 00:46:53

>>66
んー、いいわけがましくなるけど、俺の場合、インスタンスの廃棄は生成した側
が責任をもつというスタイルだったんで、インスタンス自身が自分を廃棄する
という形式に慣れてないんだと思ったけど。

**名前は開発中のものです。** · 2008/11/15(土) 00:55:46

>>67
でも悪用するだろ？
しかもグローバル変数は使わないと恩恵（笑）は受けられないだろ？

所詮、アフォが飛びつく糞なアイテムよ

**名前は開発中のものです。** · 2008/11/15(土) 01:00:16

＞インスタンス自身が自分を廃棄

その廃棄っていうのは、自殺を決断したらメモリ開放まで一気に行ってるわけだよね？
タスクシステムとかいうナニにおけるインスタンス（というかエンティティなんだろうね）の
自殺のプロセスというのは、常にそういうもの（自殺を決意したらメモリ開放まで一気に決行）
と決まっているの？それとも君が読んだ何かしらの自称タスクシステムのサンプルコードの
実装がたまたまそうなっていたというだけなの？

**名前は開発中のものです。** · 2008/11/15(土) 01:06:54

>>70補足
＞（自殺を決意したらメモリ開放まで一気に決行）

なおかつ生みの親や己を参照するインスタンスに何ら通知する手段を提供しない。ね

>>68
＞俺の場合、インスタンスの廃棄は生成した側
＞が責任をもつというスタイルだったんで

これも同じく。自殺を決意したら生みの親に自分を殺してくれと依頼するような手続きは
タスクシステムと呼ばれるナニにおいては「存在しない」ということになってるのか、それとも
君が読んだ何かしらの自称タスクシステムのサンプルコードの実装がたまたまそういう
手続きを用意していなかっただけなのか

自称タスクシステムってどれもこれも俺俺システムで内容がバラッバラだよね

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

>>70
イテレータに矛盾が生じないような工夫はされてたけど、delete はdelete だったな。
まあ、それでも、たまたま、じゃないかと思うけど。入門用サンプルだし。

**名前は開発中のものです。** · 2008/11/15(土) 01:34:51

>>72
そうかー。もし良かったらそれのURLとか書籍名教えてくれないかな
いや、別に悪戯とかしないからさ

**名前は開発中のものです。** · 2008/11/15(土) 01:53:28

>いや、別に悪戯とかしないからさ
却ってこえーよw
こっちは勉強させてもらってる立場だからあんまりなー。
このスレを調べりゃわかるよ。

**名前は開発中のものです。** · 2008/11/15(土) 02:00:05

あー、ここに載ってるならいいや

＞却ってこえーよw

何にもしねーよ。入門用を謳う自称タスクシステムがいっぱいあるから
そのカオスを更に加速させて「タスクシステム」がどんどん
「口に出すだけで何とも居た堪れなくなるムードを醸し出すキーワード」
になっていく様はある意味で痛快だしな。

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

いっぱいあるから →　増殖するのは結構なことだ

**名前は開発中のものです。** · 2008/11/15(土) 02:45:06

ちょっと大げさかもしれないけど
コンテンツ産業に理解ある総理の下で
国策としてコンテンツ産業に力を入れようとしているのに
裾野を支える初心者が混乱に陥ることを喜ぶのは
日本人として恥ずかしくない?

**名前は開発中のものです。** · 2008/11/15(土) 08:16:42

タスクシステムすごくね？
いつも途中で破綻する俺でもゲーム作れた

**名前は開発中のものです。** · 2008/11/15(土) 13:25:03

>>77
そういう、いかれた自称上級者はいつの時代にもいた。

**名前は開発中のものです。** · 2008/11/15(土) 14:12:48

タスクシステムを使うようになってからというもの、周囲がボクを見る目が変わったね。

なんかこう一目置かれてるって感じ？

隠し切れない風格を醸してるせいかコミュニケーションにも微妙な距離が生まれるみたい。
こういう孤独も上級者ならではの悩みだよね

**名前は開発中のものです。** · 2008/11/15(土) 14:30:50

自由度が高い分だけめちゃめちゃ遅い点はあまりつっこまれない、なんで？

**名前は開発中のものです。** · 2008/11/15(土) 16:47:53

遅いって何が？

**名前は開発中のものです。** · 2008/11/15(土) 18:45:10

たぶんこの辺の話
http://pc11.2ch.net/test/read.cgi/tech/1217813098/985

**名前は開発中のものです。** · 2008/11/15(土) 19:01:12

仮想関数まで否定することになるな

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

なぜタスクシステムを嫌うのですか？（上位５回答）

１．名前が気に入らない
２．名前を付けた人物が気に入らない
３．名前の「システム」の部分が気に入らない
４．自由度が高いのが気に入らない
５．隣のプロジェクトが気に入らない

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

「気に入らないから叩かれてるに過ぎない」として批判を過小評価したがってる様子が
ひしひしと伝わってくるけど、そういうワンパターンなかわし方を続けるのってのもどうなんだろうね

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

カプの開発で大規模に作っちゃったもんが
タスクシステム使いまくりでバグりまくりなので
そもそもの構造からいってすでにまずいってことがわかると困る人がいるのです

**名前は開発中のものです。** · 2008/11/16(日) 07:03:30

>>86
いやいや、俺はタスク使わんし・・・
批判の仕方が感情的だっつってんの

タスク派も嫌タスク派も、なんで自分のやり方が一番いいと思えるんだ？

**名前は開発中のものです。** · 2008/11/16(日) 07:44:51

>>88
二つの方法ですでに開発したことがあって比較した上での結論

**名前は開発中のものです。** · 2008/11/16(日) 08:44:31

早いレスども

タスクシステムという名称は新しいものらしいけれど、
それ自体はかなり古い手法だろ？
当時対比されるべき「もう一つのやり方」は
アセンブリで非構造化の逐次プログラミングだったはず
当時のタスクの本質がコンポーネント指向にあったんだろうと考えれば
取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね

なんつーか、フラッシュ使いがハイパーカードを非難してるようなモヤモヤを感じる

**名前は開発中のものです。** · 2008/11/16(日) 08:50:18

ギャラクシアン - Wikipedia
http://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%B7%E3%82%A2%E3%83%B3

タスクシステムの初出は１９７０年代

**名前は開発中のものです。** · 2008/11/16(日) 08:56:45

ちなみに旧ナ○コ系の一部では
ジョブコン（ジョブコントローラー）と呼ばれていたらしい
他にも派閥によって呼び名が・・・おっとだれか来たようだ

**名前は開発中のものです。** · 2008/11/16(日) 14:53:09

>>87
以前このスレでも話が出たMTなんとかのことですか？

**名前は開発中のものです。** · 2008/11/16(日) 22:47:39

>>90
> 取り込む要素があると思いこそすれ、非難する気には全然ならないんだよね
C++ で仮想関数として取り込み済み。

**名前は開発中のものです。** · 2008/11/16(日) 23:43:18

70年代の技術でオブジェクト指向を表現したのがタスクシステム

**名前は開発中のものです。** · 2008/11/17(月) 00:52:54

別にゲームに限らず、関数ポインタ＋データブロックという構造はよく使われてたけどな。
UNIX のデバイスドライバとか UNIX V6 の頃から、こんな作りだ。

**名前は開発中のものです。** · 2008/11/18(火) 00:07:12

>>92
だっせー

**名前は開発中のものです。** · 2008/11/18(火) 01:47:54

当時としてはすごい技術だったという話は

・いまタスク使ってるやつは擁護になってないからスルー
・アンチはそんなの知ったことじゃないから叩く

技術史が好きなヤツにしか意味のない話です

**名前は開発中のものです。** · 2008/11/18(火) 02:15:13

だからタスクシステムの要点は
　　・メモリ管理
　　・タスク管理
だって言ったじゃん

メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績
そして扱うべきデータがどんなデータであれ管理レベルでは等価である事がタスクシステムか否かの分岐点だと思うね

ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
プログラムも複雑化してタスクシステムより尚悪い

あと余計な事かもしれないけど、このスレが迷走しやすいのは「何を解決するのか」を定義しないで話を進めるからだよ
例えば「ジャンルにとらわれない万能オブジェクト管理システム」なんていう途方もない事であっても目的があるとないのでは
議論の濃さが全然違う

最後に何度も言ってるけど、・・・タスクシステムを使うには現在のPCはオーバースペックすぎると思うよ
HSPでよくみかける固定長配列での管理よりわかりやすく速度的にも有利なタスクシステムなんて見たことないし
有意な差が出るとも思えない

**名前は開発中のものです。** · 2008/11/18(火) 07:37:14

わけのわからんこと言い出すからレスが止まっちゃっただろ

**名前は開発中のものです。** · 2008/11/18(火) 08:29:07

>ちなみに継承＋多態はメモリ管理、タスク管理のどちらから見ても最悪なばかりか速度まで低下して何のメリットもない
>プログラムも複雑化してタスクシステムより尚悪い
お前は継承も使わずにプログラムしてんのか？

**名前は開発中のものです。** · 2008/11/18(火) 09:07:44

Cには継承ないよ
haskellには継承なんてないけどそれでも綺麗なコードの実用プログラムが沢山書かれてるよ

**名前は開発中のものです。** · 2008/11/18(火) 12:59:38

なんで唐突に Haskell が出てくるのかわからんが
deriving とか知らないのか？

で、必死になってメモリ管理とか叫んでるひととか、バカにしようと必死な人とかは
スルーしたほうがいい気がする。

**名前は開発中のものです。** · 2008/11/18(火) 16:11:47

>>99
＞タスクシステムっていうのは
＞　　・メモリ管理
＞　　・タスク管理
＞の2種類から構成されている

前スレログ読みましたが、クラスを使うとフラグメントが発生どうのとかよく分からない話をして
数人から突っ込まれてたID:IuSgJyHuさんですか？たぶんそうだろうかと私は思うのですが。
ところであなたの言う「タスクシステム」とやらは具体的に何なのでしょう。これと思う実装例が
あるならそれを示してくれませんか。人によって定義が千差万別の俺俺システム「タスクシステム」
ですから、その言葉を発する人間が登場する度にこうやって確認せざるをえないわけで。
このように、確固たる出典がない、言い方を変えれば権威が不在というのは不便なものです。
技術用語としての存在価値が疑問視され、所詮はローカル用語といわれるのも頷けます

＞メモリフラグメントに対して固定長データという回答を出したのがタスクシステムの功績

ん？70年代中期・末期において主記憶をページング方式で管理することに新規性があったと。
簡単のために操作対象を固定長に分割・管理する、つまり固定長レコード方式というものに
新規性があったと。そういうお考えで？
当時のソフトウェアエンジニアの通念というものが集計できるならば、あなたの考えは当時としても
非常に珍しい類のものだろうと思います。かなりエキセントリックだろうと思います

まぁ確かに、計算機についての基礎教養が欠乏、というかむしろ知的水準が絶望的に低い人間
にとっては世の中のあらゆる仕組みはあらゆる時代を通じて常に新規性に満ちた凄いテクノロジー
なのでしょうけど…
そういう知的弱者・情報弱者・底辺階級をターゲットにした功績話を絶叫するのはあなたの趣意ですか？

**名前は開発中のものです。** · 2008/11/18(火) 16:24:48

i君乙
あいかわらず厭味だねぇ

**名前は開発中のものです。** · 2008/11/18(火) 22:15:12

変わらぬ芸風も、また一興

**名前は開発中のものです。** · 2008/11/19(水) 02:14:42

>>101
今は継承を使わないのが流行り
おまえだってhasAにしてるんだろ？
特に深い継承はアンチパターンになりつつある
継承＋多態の効率の悪さはいわずもがな
ゲームで使っちゃいけません

>>102
継承は基本的に汚いコードになると思うよ
設計書は綺麗になるけど

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

**名前は開発中のものです。** · 2008/11/19(水) 03:31:19

>>107
"is a" 関係でも継承使わないってこと？それだと無理なコードにならない？

効率が悪いというけど、そもそもゲームで CPU 処理時間がボトルネックになること
すら稀なのに、さらにそのうち継承＋多態によるものは数％以下でしょ？
ヘビーなループ内では問題になることもあるだろうけど、はじめから使わない前提に
する必要は無いと思うよ。

**名前は開発中のものです。** · 2008/11/19(水) 08:36:26

>>107
> 今は継承を使わないのが流行り
実装継承とインターフェース継承を混同しとるな。

**名前は開発中のものです。** · 2008/11/19(水) 19:07:46

>>107
> 固定長レコードというCOBOL的なものをゲームに持ち込んだのは新規性がある

固定長レコードはそれよりずっと以前のパンチカード由来。例えば19世紀末のタビュレーティングマシン
そこから進化したユニットレコード装置とかPCS（パンチカードシステム）とか。（※）
この時点でパンチカードのレコード長は大抵【80カラム】。これが処理単位だった
それがそのままコンピュータの記憶装置に使われ、その後の記憶装置の仕様にも反映された
アセンブリ言語のプログラムは一行80カラム。データも同じく。メインフレームのRecord Oriented Filesystem
初期のFORTRAN、OSのジョブ制御言語、COBOLなどなど、あらゆる処理の単位としてこの【80カラム（バイト）】が
当然のごとく登場した

FORTRANが登場したのは1950年代の半ば
COBOLが登場したのは1950年代の末

（※）更に遡れば19世初頭のジャカール織機だとか18世紀末のオルゴールだとか色々あるかもだが

**名前は開発中のものです。** · 2008/11/19(水) 19:37:40

（訂正）
> アセンブリ言語のプログラムは一行80カラム。
　↓
アセンブリ言語のプログラムは80カラム単位でロードされた。
----------------------------------------------------------

>>170
> そもそも固定長レコードはフラグメント解消のものではなかった

固定長レコードとか固定長データとかいう構造（要するに配列）が大昔から現在まで色んなところで
便利に使われてるのはその取り扱いが、実装が、極めて単純だから。
例えば
・データの所在（番地）が容易に算出できる
　　先頭番地+オフセット。このオフセットがレコード長*レコード番号で済む。
　　処理が単純化できるし回路も単純化できる。つまり真空管数（トランジスタ数）を抑えられる
　　占有面積も重量も放熱設備も電気料金も抑えられる。
・外部フラグメンテーションの制御が簡単
　　記憶領域を【容易に】再利用できる
　　最大長を決めてるからデータ書き換え時には旧データに新データを直接上書きできる
などなど。頻繁に書き換えるデータにはどれも重要な特性。

固定長なデータ構造はそのメリットの大きさゆえに、デメリット（レコード内の無駄。内部フラグメンテーション）
が許容されるケースは多い。COBOLも、COBOLが登場する以前の事務処理プログラムも可変長データの大半は
最大サイズを決めたうえで固定長レコード、それを収束した固定長ブロックで格納した。
今のRDBや簡素なDBMも基本的には同じ

**名前は開発中のものです。** · 2008/11/19(水) 20:12:26

>>170
> バナナでクギを打った所に新規性があるんだよ
> トンカチあるから必要ないよねっていうのは別の話

その例え何かおかしくないか。常温バナナで釘を打つのは確かに斬新な愚行だが

規模がまるで違うものを指してトンカチと冷凍バナナという話をしているのかなと前向きに解釈してみるか

大昔には科学者もエンジニアもシステム屋もみんな今とは比べ物にならないくらい貧弱なハードでやり繰りしてた。
FORTRANやCOBOLが登場する以前の計算機を駆使する人間は多かれ少なかれ今で言うところのハッカーじみた
技能やバッドノウハウを身に付けて自前のサブプログラム群をシコシコ作って自前ライブラリ用意したりした。
FORTRAN登場後も初期のFORTRANコンパイラの最適化は不十分で最内周ループ処理など頻繁に呼び出す処理の
アセンブリコードを自分で書く利得は大きかった。（※）

これらは日本のビデオゲーム業界が隆盛を誇るずっと以前の話

つまり、ド貧弱な装備でシコシコ戦うことを強いられ、セコくて貧乏くさい高速化テクやリソース節約テクを駆使してたのは
何もゲーム業界固有の境遇・逆境だったわけじゃない。もしゲーム業界固有だなどと思い込んでる人間がいるなら
そいつはルサンチマン君だ

（※）その後BLAS、LAPACK、MPIなどなど先人の開発した優れたライブラリが沢山登場し
　　　FORTRANコンパイラの最適化機能もとても優秀なので自前でシコシコする必要なくなった

**名前は開発中のものです。** · 2008/11/19(水) 20:14:33

（訂正）
>>170
↓
>>107

＞規模がまるで違うものを指してトンカチと冷凍バナナ
↓
本来の用途がまるで違うものを指してトンカチと冷凍バナナ

**名前は開発中のものです。** · 2008/11/19(水) 22:25:30

>>108
俺も継承は使わないほうがいい派
実装とかインターフェイスとか関係無い
そのメソッドやメンバがどのクラスのものであるのかわからなくなるのが最大の害だと思う
しかもオーバーライト（？名前忘れた）されると今度は同じ名前のメソッドがあって
どれを呼んでるのか本格的にわからなくなる

どうしても使わなきゃならんのがMFCみたいな変態実装になってる場合
自分に内包してるモンを継承使って書き換えさせるウンコソース
これは仕方がない

でも、できるだけhas aの関係でまとめたほうがいいと思う

**名前は開発中のものです。** · 2008/11/19(水) 23:52:57

>114
ttp://www.bizlogic.co.jp/techinfo/reconsider/inherit.htm

>新人プログラマほど継承を乱用します．特に新人が好むのは、
>コードの再利用のための継承です．（中略）
>新しいサブクラスが必要になって定義しようとしたら、親ク
>ラスに不整合があることを発見して修正．すでに定義済のサ
>ブクラス群に影響が出るためそれらを修正．その影響がクラ
>スのクライアントに出ることに気づかず、バグが連発．修正
>を繰り返すうちに設計し本人しか理解できないような継承階層が完成･･･

ｲｲﾊﾅｼﾀﾞﾅｰ

耳の痛いことだが、とりあえずタスクシステムのせいじゃないと思うんだw

**名前は開発中のものです。** · 2008/11/19(水) 23:59:13

ギャラクシアン以外をタスクシステムとして認めない原理主義者が現れてスレ的には
おめでいたいことだが、狭量すぎやしないか？
とりあえずメモリ管理については
・当時はそもそも自前のメモリ管理以外存在しない。
・メモリに制約のあるシステムならタスクシステムでなくても必要
だから、タスクシステムの絶対条件じゃないと思うんだが。

**名前は開発中のものです。** · 2008/11/20(木) 00:34:43

そもそも当時と今とでは
「メモリ管理」って言葉が指すものがだいぶ違うからな。

今のゲーム開発だと
メモリ管理モジュールの綿密なアーキテクチャの設計と実装を主に指すけど、
当時のは「管理モジュール」なんて呼べないような極々シンプルなものだからな。

**名前は開発中のものです。** · 2008/11/20(木) 00:39:08

連投ｽﾏﾇ　ちと古いが、>>44
ttp://www.t-pot.com/program/140_GameAISeminar4/index.html
Haro2のAIは階層型FSMとやらで実現されているそうだ。

>>41によれば「タスクシステム=FSM」だそうだから、タスクシステムでできそうな
気がするというのもあながち的外れではないかもよ。

もっとも、50がいう配列厨もFSMの一実装じゃねーのと思うので
タスクシステム=FSM=配列厨となって自己矛盾じゃないのかとか思ったり。
なんかFSMの解釈間違ってる？

**名前は開発中のものです。** · 2008/11/20(木) 00:52:20

>>117
CUDAを調べてて思ったんだが、メモリ・ワークをどこにとるかでパフォーマンスが
大幅に違ったりするみたいだし、いまどきのゲームのメモリ管理ってそうなんだろうな

**名前は開発中のものです。** · 2008/11/20(木) 01:35:27

３スレ目になったが、今だに喧嘩腰じゃないと議論もできないのか・・・

**名前は開発中のものです。** · 2008/11/20(木) 01:41:10

>>120
喧嘩腰に見える？そりゃすまん。

**名前は開発中のものです。** · 2008/11/20(木) 03:32:51

ああいや、個人を指してるわけじゃなくて、
スレ全体の雰囲気のことを言ってる。

**名前は開発中のものです。** · 2008/11/20(木) 23:36:18

>>118
> >>41によれば「タスクシステム=FSM」だそうだから

>>41では「タスクシステム＝FSM」というような趣旨のコメントはしてない
>>41までは「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」という立ち位置でコメントしてる。ただ
そのままの状態でポエムを書き続けるのは難しいんで>>43以降はみんなのテンプレ（？）と思われる>>2を引っ張り出し
「タスクシステムとは>>2」という前提（or仮定）のもとでコメントした

そして>>43以降(ID:mdtDWXyh、ID:U55fYg17)でも「タスクシステム＝FSM」という趣旨のコメントはしてない
【非常に簡素でオーソドックスなFSMモデルの】ジョブ制御、【小規模で簡素なFSMモデルの】ジョブ制御
というような書き方はしてたが。これ通じ難かったんかな。一応意味を補足するためにダラダラ書いたんだが。
与えられたCPU時間でジョブを細切れにして処理の継続(continuation)に必要な手続きをユーザーに丸投げする
原始的なジョブ制御な

「70年代のハードに依拠する簡素なゲームにとっては無難なジョブ制御プログラムとかモニタプログラムの【断片】だね」
とも書いてるが、「70年代のハード」をちょっと修正すると「70年代～80年代初頭にかけて登場した典型的な実装対象（※1）と開発環境（※2）」

（※1）基本的には○MHzの8bitCPUに○KBのRAMに○KBのROMのマイコンボード
　　　　これにOBJ（とかBGとか★とか）の表示や（固定）サウンドの出力やコイン制御のための回路や各種スイッチ（のインターフェース）
　　　　あと必要なら大容量ROMのバンク切り替え回路、などなどを付加したカスタムボード。
（※2）ここでは、8or16bitPC（或はマイコンボードをカスタムしまくってデスクトップPC化したTK-80BS　みたいなやつ）と
　　　　簡素なリモートデバッガ、エディタ、クロスアセンブラ（別にハンドアセンブルでもいいけど）で構成されるもの

**名前は開発中のものです。** · 2008/11/20(木) 23:39:52

（訂正）
○MHzの8bitCPU
↓
○MHzの8or16bitCPU

**名前は開発中のものです。** · 2008/11/21(金) 01:39:25

>>123
そういう立ち位置なんだとすると余計にわからなくなるのよ。

>「ここでタスクシステムと呼ばれてるものが何なのか知らんけど」

という立ち位置の人間が、ゲーム開発者ローカルな用語である「タスクシステム」
という用語とそのスレッドで、

>タスクシステムすげぇすげぇ言ってる超小規模開発・個人開発なら

てな形で批判的な言説を繰り返す理由が。てっきり

>タスクシステムを心の底から崇拝する人間が心の底から子バカにしている様子がたまに見受けられる配列厨のコードそのものだ。

という形で小ばかにされたことをこのスレにぶつけてるんだと思ったよw 俺の立場としては

>ゲームプログラムでは、複数の構造体変数を管理することにより、複数のキャラクタを
>管理できます。複数の構造体変数を管理するための方法は、構造体をリスト構造で管理
>する方法と構造体を配列で管理する方法の 2 種類あります。
ttp://msdn.microsoft.com/ja-jp/academic/cc998623.aspx
の実装方式の一つだろうという前提で、そのメリットデメリットに興味があってここに参加しているのだけども。
ちなみに上記の例でいえば、マイクロソフトは配列厨だなw

**名前は開発中のものです。** · 2008/11/21(金) 01:41:47

>>120,122
タスクの話題に限ったことじゃないけど
賛成か反対かの単純な対立に流れることは多いね。
わかりやすいから盛り上がるけど白熱しすぎて喧嘩になったりする。
でもその対立構造が正しいとは限らなくて
良い意見が喧嘩に埋もれてしまったり。

ゲーム製作技術板なのに技術の話じゃなくてすまん。

**名前は開発中のものです。** · 2008/11/21(金) 02:31:22

>>126
確かにそうだ。俺も何が対立軸なのかよくわからなくなってるよw
俺は情報系の人間じゃないんで、ゲームのオブジェクトの相互の振る舞いは
FSMの一形態と見なせるみたいな発言を単純に面白いなと感心するんだけど。

**名前は開発中のものです。** · 2008/11/21(金) 02:35:33

配列で線形リストも組めない雑魚が配列をバカにしてるのを見ると悲しくなるし、
そもそもタスクシステム（特にこのスレで主流の複雑な実装）は速度的に不利なんだから
素直に配列さんごめんなさいって言えばいいと思う

**名前は開発中のものです。** · 2008/11/21(金) 21:53:14

この3連休でタスクシステムの仕様についてまとめるように、以上。

**名前は開発中のものです。** · 2008/11/21(金) 23:55:06

>>128 が、>>123だとして、わからん、お前のいうことはわからん！（大滝秀ry

>配列で線形リストも組めない
どこかで queue を配列で組む入門例があったけど、そんなものじゃないだろうし、
だとしてもその線形リストで、まさかタスクシステムをつくるわけじゃなかろうし、わからん。

>雑魚が配列をバカにしてるのを見ると悲しくなるし
どのレスを指しているのか、わからん！

>このスレで主流の複雑な実装
どれだよ！>>43なんか、
>誰が書いても同じようなものになるってくらい凡庸な、道端の雑草並みのありふれた仕掛け
とかいってるぞ。凡庸でありふれて複雑て、どっちなんだよ。

>速度的に不利
いや、ロジックの部分は大して食いませんてば。最近のゲームはそうでもないのか？

>素直に配列さんごめんなさい
君が配列ラブなのだけはなんとなくわかったよ。ごめんな。

**名前は開発中のものです。** · 2008/11/22(土) 06:09:06

>>128は書いてる内容から明らかに雑魚だなｗ

**名前は開発中のものです。** · 2008/11/24(月) 11:26:55

>>129
いまどきのタスクシステムの仕様
１．クラス名、構造体名に「Task」を含む
２．描画物とそれ以外の処理を同列に扱える（ことがある）

これくらいじゃね

**名前は開発中のものです。** · 2008/11/24(月) 23:39:25

「ゲームプログラマになる前に覚えておきたい技術」
を読んだけどタスクシステムなんて使ってなかった
普通に配列使ってて、配列の上手な使い方がのってた

やっぱプロは配列を使うんだね

**名前は開発中のものです。** · 2008/11/24(月) 23:42:11

>>133
２ｃｈでしかでかい声は聞かない（マジで）

**名前は開発中のものです。** · 2008/11/24(月) 23:58:55

>>133
はいはい、配列さんごめんなさい。

>>133は、配列の利便性と構造体を使ったリストの有用性の違いがわかっていないようだ。
もう一度、データ構造を見直すことをお薦めする。

**名前は開発中のものです。** · 2008/11/25(火) 00:45:31

>>133
おま・・・リスト使うか配列使うかの話かよｗ
セガがリスト使わないなんてありえないから、安心して両方の使い方を覚えような
ついでに二分木やハッシュも覚えておくこと

**名前は開発中のものです。** · 2008/11/25(火) 00:58:47

配列　：　削除、追加時のコストが高い。検索が速い
リスト　：　削除、追加時のコストが安い。検索が遅い

リストは単純に舐めるだけでも遅い
ここで比べるべきなのはデータの検索（巡回）・追加・削除がゲーム中にどれだけ発生して
それを処理するにはどんなアルゴリズムとデータ構造がベターであるかだ

データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
だからリストより配列のほうがゲームに適している

リストの有意点とはデータサイズの見積りをサボれるという一点に尽きる
たしかに配列のリサイズはゲーム中にはとても不可能だからこれは魅力だ
しかし、ゲームを製作する上で場面ごとに必要なメモリの見積もりなんてやって当たり前の話で
その程度の理由でリストを使うなんておかしい

以上の理由からゲームでリストを使う事はない

弾幕STG等ひたすら衝突判定を繰り返す場合なら
検索アルゴリズムの都合で配列よりツリーがベターな場合もある
（STG製作技術スレで話題になってたエリア別ツリー構造等。FPSでよく使われるが）
だから配列がベストとは言わないが少なくともリストに劣ることは無い

**名前は開発中のものです。** · 2008/11/25(火) 02:46:59

いつからリスト対配列になったんだ?
タスクシステムは固定長データが重要とか言い出した>99あたり?

つか>126じゃないけどその対決って
どうしても勝ち負けを決めないといけないようなことなの?

**名前は開発中のものです。** · 2008/11/25(火) 13:07:00

>>137
もっともらしくウソついてんじゃねーよ
わざと言ってんだろ。明らかに初学者に対して悪意のあるウソだな

>リストは単純に舐めるだけでも遅い
誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。
配列が有利なのはランダムアクセスの場合。

>データの検索（巡回）よりも追加と削除のほうが多いゲームなどない
比較方法の誤り。巡回回数と挿入回数を単純に比較しても意味はない。
コストの違いは以下のようにO記法で考えると分かりやすい。

・シーケンシャルアクセス（巡回）のコスト
　配列はO(n)：要素数が増えると処理時間が増える
　リストもO(n)：要素数が増えると処理時間が増える
・ランダムアクセス（インデクス値でアクセス）のコスト
　配列はO(1)：要素数が増えても処理時間は変わらない
　リストはO(n)：要素数が増えると処理時間が増える
・挿入、削除のコスト
　配列はO(n)：要素数が増えると処理時間が増える
　リストはO(1)：要素数が増えても処理時間は変わらない

O(1)はO(n)に対して非常に有利なので、
ランダムアクセスがありそうなら配列を、挿入がありそうならリストを選ぶのが一般的。
どちらもありそうなら実際に処理時間を計測してみるのが良い。
処理時間とは別に、メモリのフラグメントを嫌ってリストを避けたい場合は、
データ本体は配列構造に置き、管理はＺソートされたリスト構造に、
というように両方を組み合わせる手法もある（C++オブジェクトをメモリプールするのと同じことだけどね）。

とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

**名前は開発中のものです。** · 2008/11/26(水) 00:21:42

ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ　だが…。どうしたもんかね。とりあえず俺にレスした人から順番にレスするか…

> ID:K7xBu4Cw、ID:gOWsGtVr

>>123の時点では↑この人の諸元と過去発言を把握できなかったがサンプル数が増えたおかげで大凡のところ見当が付いたわ。
まず俺の一連の書き込み（ ID:mdtDWXyh、ID:U55fYg17、Xvygn8lQ ）から「タスクシステム＝FSM」という解釈に至るのは難しい（※）
①FSMの意味をよく理解していない②人の話をよく聞いてないか③意図的に歪曲して解釈しようと努めている、のどれかだろう。
①ならFSMや有限状態機械でググレとしか言えんし②ならちゃんと読んでくださいとしか言えんし③なら正直相手にしたくない

奇遇にも過去にこの人物と同じ解釈「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
ID:K7xBu4Cw 、ID:gOWsGtVrがこれと同一人物なのか知る由も無いが、かなり似通った特徴的な思考・読解の持ち主だなとは思う。

さて、この人は更に>>130で「>>128 が、>>123だとして」という謎めいた仮定を持ち出してるのだが、なんでこうなるんだろうね…
俺の過去発言と照らし合わせれば無理があると容易に分かるはずだよな
この人は>>130で自らそれを説明してみせているにも関わらず、その仮定が真であるという前提のコメントを書くだけで
その仮定が偽であるという（当然あってしかるべき、より可能性の高い）前提のコメントは結局書くことはなかった。妙だね

　・ただ単にコミュニケーション能力の不足、悪意のない、無知、短気、舌足らずゆえにこういう尻切れトンボで終わった
　・「>>128 ＝>>123であってほしい。いやむしろそうあってくれ。頼む。これで終いにしよう」という願望の現われ

まぁ後者ならそのご期待には添えないとしか言えない
俺は配列に「さん」付けしてもらうことも、ましてや便所のラクガキにおいて初心者（？）に謝ってもらうことにも興味がない

**名前は開発中のものです。** · 2008/11/26(水) 00:23:32

（※）素直な思考の持ち主ならば、ゲームプログラムの中で【状態を保持し遷移する】ような要素、つまりFSMモデルを適用しやすいもの
としてまず初めに思い浮かぶものといえばシーン（オブジェクト）やエンティティだろう。そういったもの⊂FSMと解釈するならわかる

＃>>2そのものをFSMとして説明することはできるが、これを言い出したらプログラムも電子計算機も社会基盤も自然環境も惑星も
＃銀河も宇宙もFSMモデルで説明できるという話になる。ぬるま湯に溶かしたハナクソを構成する分子の振る舞いも、乾いて風化した
＃ハナクソ粉体の振る舞いもFSMモデルで滔々と説明できるという話になる。こういう話は埒外であり、するつもりはない

**名前は開発中のものです。** · 2008/11/26(水) 01:14:00

話が難しすぎてついていけません＞＜

**名前は開発中のものです。** · 2008/11/26(水) 02:19:03

>>140が誰と何の話をしてるのか全然わからんけど
>>2＝「ジョブコン」＝ＦＳＭという話は直感的で分かりやすいと思うぞ

てか名称「タスクシステム」は人によって定義が違うから使うな。議論が混乱する

**名前は開発中のものです。** · 2008/11/26(水) 02:34:19

ああ、>>140をフォローしたつもりが逆だったらしい
>>140はＦＳＭって言い方が抽象的すぎるっつってんのね？
了解。もう言わん

**名前は開発中のものです。** · 2008/11/26(水) 08:30:23

>>137
冗談だろって思って配列にしたら速くなった
たぶんキャッシュ周りも関係してる気もする

**130** · 2008/11/26(水) 23:22:37

>>140
>①FSMの意味をよく理解していない②人の話をよく聞いてないか③意図的に歪曲して解釈しようと努めている、
どれもそれなりにあてはまるとは思うが、あえていうなら②かなw

とりあえず③についてはそういう意図も一部あったんでそれは謝っとくよ。
ただ、前提として >>40,>>41で繰り返された

>ここでタスクシステムすげぇすげぇ言ってる

というような傾向は無いとはいわんけど（タスクシステムスレだし）、実装で苦労してるみたいな話が中心で、
mdtDWXyhが挑発的な言辞を繰り返さなきゃいかんほどかね？と思うけどな。

**130** · 2008/11/26(水) 23:23:39

>「タスクシステム＝FSM」を披露したのはルサンチマン君のID:SCRh4oL7ただ一人だ。
これは順番が違う。同じレスを指してると思うんだけど、

(1)「タスクシステム＝FSMだ」という発言があった。
(2) そのあとに >>41で「原始的なFSMモデルのジョブ制御」という発言があった

ので、同一人物か同じ立場の人間が批判的な意味で FSMという単語を使ってるのかな？と思ったんだよ。意味合いは違うようだけどFSMという用語を使うレス自体が少なかったからそこは勘弁。

その上で、ゲーム上のオブジェクトの振る舞いをFSMモデルで捉えることはできるだろうけど、それは配列で構成されたゲームについても言えることで、タスクシステム（実装）批判につなげるのはおかしいんじゃないの？と皮肉ったつもりだったのよ。

**130** · 2008/11/26(水) 23:28:25

ただまあ、タスクシステム（ジョブコンでもいいや）の適用範囲とか実装上の問題点と
か、そういう流れになってくれると嬉しいんで、「これで終わりにしてほしい」という
のも正直なところ。だからピンダッシュに反応しすぎた俺も悪い。もうだまっとく。

**名前は開発中のものです。** · 2008/11/26(水) 23:53:44

>>139と>>137のお話について横から首突っ込んで初学者向けにポエムを書いてみるか

実際の処理速度を語るとき、ランダムアクセスといったら、メモリアドレスを基準にしたランダムアクセスという話も当然絡んでくる
データ構造上の順番（連結リストなら繋がれた順番）を基準にしたらリニアアクセスだよ、といってもメモリアドレスを基準にしたら
ばっちりランダムアクセスになっていました、という状況も当然あり、この場合は処理する要素数と要素サイズと実装対象によっては
べらぼうなペナルティを受けたりする。ので

>>リストは単純に舐めるだけでも遅い
>誤り。「単純に舐める」＝シーケンシャルアクセスに有意差はない。

これは状況ごとにプロファイラなりアナライザにかけて検証してみないと分からないというツマラナイ結論に帰結する
ので

>とにかく、初学者は「どっちが勝ち」みたいな議論に振り回されないこと。
>ぶっちゃけ実際に動かしてみて問題がないなら、なんであれそのやり方は正しい。

だよな

（続く）