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

1 ：名前は開発中のものです。：2007/12/04(火) 04:51:53 ID:bGSXJYb0

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

前スレ　http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

2 ：名前は開発中のものです。：2007/12/04(火) 04:54:13 ID:bGSXJYb0

White Paper - Programming
http://homepage3.nifty.com/moha/programming.html

タスクシステム
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

CodeZine：本格的なシューティングゲームを実現するタスクシステム（タスクシステム，シューティング，ゲーム）
http://codezine.jp/a/article.aspx?aid=297

いまどきのタスクシステムの実装
http://omoikane.my-sv.net/gcss/tasksystem/index.php

ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
今は無き C MAGAZINE 2006年1月号
http://www.cmagazine.jp/contents/200601.html

3 ：名前は開発中のものです。：2007/12/04(火) 17:53:51 ID:3YteMgDl

Logician Lord　…　【コンピュータゲームのからくり】
※ウェブアーカイブのキャッシュ
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

ウェブでタスクとかタスクシステムについてまとまった情報を提供したのは
このページが初めてだったのだが、残念なことに既に消滅してしまっている。
このページが登場する以前はgoogleで「タスク|タスクシステム」等で検索しても
ゲームプログラミング関連のページはひとつもひっかからなかった

当然ながら、Cマガにおいてド素人さんのタスクシステム紹介記事が載る前の話な

4 ：名前は開発中のものです。：2007/12/04(火) 18:00:24 ID:3YteMgDl

4 ：名前は開発中のものです。：2007/03/13(火) 01:05:48 ID:lSPAnQVN
暇だったんで書いてみた。添削できる人がいたらよろしく。

タスク

プロセス・スレッド・ファイバなど実行パスの総称。
この用語はシステムによって異なるものを指すため、動作システムを明らかに
するか、「実行する何か」といった抽象的な意味でのみ使うことが推奨される。

古典タスク (別名: ファイバ/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

→ファイバの項を参照

ただし、ゲームのプロセス管理システムとして実装されたものは、コンテキストスイッチの他に
優先順位や実行順序のソートなど各種管理機能を備えたものが通常である。

擬似タスク (別名: 関数ポインタリスト)

関数ポインタ・クラス・(関数ポインタを持った)構造体などをリストで繋いだもの。
古典タスクの機能のうち個々のタスクをリストで繋ぐ部分のみを継承したものと思われる。
データ構造にツリーや配列などの変種がある。一部のゲームプログラマのローカル用語。

注: Winedows3.1等の擬似マルチタスクとは関数のリターンが必要なところは同じであるが、
コンテキストスイッチが伴わないところが異なるため、同じものとは言い難い。

5 ：名前は開発中のものです。：2007/12/04(火) 18:01:49 ID:3YteMgDl

5 ：名前は開発中のものです。：2007/03/13(火) 01:06:36 ID:lSPAnQVN
プロセス[Process]

→http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9

注: 組み込み業界ではプロセスをタスクと呼ぶ慣習がある。
ゲーム業界は組み込みに近いシステムから同時代のPC並のものまで主流なシステムが
増えたため、異なる方面のエンジニアが交じり合い用語の混乱を招いていると思われる。

スレッド[Thread] (別名: ライトウェイトプロセス/プリエンプティブスレッド)

→http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_%28%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

ファイバ[Fiber] (別名: 古典タスク/軽量スレッド/マイクロスレッド/ノンプリエンプティブスレッド)

軽量スレッドとも呼ばれる。並列的な記述が可能だが、スレッドで必要な
ロックが必要ない点がメリットである。コンテキストスイッチをOSではなく
アプリケーションが明示的に行うスレッド。WindowsではCreateFiber()で作成できる。

6 ：名前は開発中のものです。：2007/12/04(火) 22:58:33 ID:IISCFTco

普通のゲームプログラムとアルゴリズムは変わらない。
ただASM臭い実装を好むという嗜好に過ぎない。

7 ：名前は開発中のものです。：2007/12/05(水) 01:23:10 ID:KjVlOJvV

【タスクシステム狂信者のバイブル】
■松浦本
シューティングゲームアルゴリズムマニアックス
http://www.sbcr.jp/books/products/detail.asp?sku=4797327316

アクションゲームアルゴリズムマニアックス
http://www.sbcr.jp/books/products/detail.asp?sku=4797338954
シューティングゲームプログラミング
http://www.sbcr.jp/books/products/detail.asp?sku=4797337214

　タスクシステム厨が信奉する松浦教祖の本

■やね本
Windowsプロフェッショナルゲームプログラミング１、２
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0314-X
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-0603-3

　BM98の中の人の本。残念なことに絶版

■逆引き本
逆引きタスクシステム
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1169-X

　タスクシステム厨の書いた本

8 ：名前は開発中のものです。：2007/12/05(水) 01:29:22 ID:KjVlOJvV

【タスクシステム厨が読むべき不朽の名著】
■shi3z本
Direct3D プログラミングガイドブック
http://www.seshop.com/detail.asp?pid=159

　3Dエヴァンジェリストの本。嬉しいことに在庫あり

■山崎本
ゲームプログラマになる本
http://www.cqpub.co.jp/hanbai/books/35/35751.htm
めざせゲームプログラマ
http://www.cqpub.co.jp/hanbai/books/35/35641.htm
　
　日本におけるメガデモ第一人者の本。残念なことに絶版

9 ：名前は開発中のものです。：2007/12/05(水) 08:00:47 ID:Lh4sjdD/

↑に古臭い本が紹介されてるけど、これ使えるの？

10 ：名前は開発中のものです。：2007/12/05(水) 11:36:59 ID:Jvl1n8OM

>>9
わからん。が、期待は禁物。正直、目次からはそんな感じはしないなぁ。
大学とかで見たら、立ち読みして見れ。

11 ：名前は開発中のものです。：2007/12/05(水) 12:10:18 ID:Isze4xKb

>>8
最後の二つはURLが逆？
めざせゲームプログラマは持ってます

12 ：名前は開発中のものです。：2007/12/05(水) 12:54:53 ID:+KnvWAen

絶版なっているやつ
誰かスキャンしてpdfで公開してくれ

13 ：名前は開発中のものです。：2007/12/05(水) 22:59:09 ID:Ng0dTUw2

>>8
＞ゲームプログラマになる本
＞http://www.cqpub.co.jp/hanbai/books/35/35751.htm

昔かって殆ど読んでないが持ってた、表紙見て思い出した
早速読んでみよう

14 ：名前は開発中のものです。：2007/12/05(水) 23:25:55 ID:A6jH8VGj

タスクシステムが理解できなければ、職業ゲームプログラマになれないんでしょうか？

15 ：名前は開発中のものです。：2007/12/05(水) 23:28:17 ID:VOAxOcjQ

YES.
使う使わないは別にして、この程度も理解できないような頭では、
プログラミングを職業にすることはあきらめた方がいい。

が、プログラマというのは所詮未来無きＩＴ土方であって、
理解できずにあきらめた方が出世できる、とも言える。

16 ：名前は開発中のものです。：2007/12/05(水) 23:50:00 ID:Jvl1n8OM

>>15
それは・・・微妙に問題を摩り替えてる気もする。
プログラマでも、コーディング猿ならともかく
色々とやる人間はどこでも働き口見つけられるし、
そういういみで、より出世しやすいだろ。

問題は、プログラ"ム"しかできないプログラマがダメなだけ。
会話や交渉、人の扱い・金の計算などなど、ちょっとした事でも
それらができれば、単純なプログラマよりも幅広い選択と未来がある。
Sヨが精々な人も同様に、それほど未来がないしねｗ

17 ：名前は開発中のものです。：2007/12/05(水) 23:52:53 ID:rqZWEfda

そんな御託は会社説明会で偉そうにぶっとけ。

18 ：名前は開発中のものです。：2007/12/06(木) 00:35:26 ID:5WVY/F2x

ゲームにハマっている間に1000いってたので、500レス一気読み

441からのネタに対するひとつのソースがあったけど、今更だな。

>　【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
>　　　　　　　　　　　ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
>　　　　　　　　　　　その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
>　　　　　　　　　　　
>　【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
>　　　　　　　　　　　ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
>　　　　　　　　　　　俺がタスクシステムって呼べばタスクシステムなんだいバーロー

最後のこれいいな。俺はまさに２だ。
ゲームでオブジェクトの動作に使われている巡回UPDATE＝タスクシステム

19 ：名前は開発中のものです。：2007/12/06(木) 00:41:53 ID:2ewBanaL

>>16
そんなこといったってプログラム組めると知られたら
一生プログラム組まされるにきまってるだろ？
実はどこの現場でもプログラマいねーんだ
でもだからっつってプログラマの給料が高いわけじゃない

そんなたけーなら開発やめるor別のプログラマ探す。以上

ってだけ
最近、ゲーム以外の現場でもこんな感じ
めっちゃやる気ない。後継者不足で中小企業がつぶれたりしてるしね
っていうのは世界の労働力が大暴落してんだよね
中国とかインドとか発展してきてるしね（つまり○投げ）
んなもんで今後さらに苦しくなることが予想されるし
そんなの実力云々でどうのこうのできるはずもないのであきらめが肝心

まあ、日本の人件費で物作るのがそもそも割りにあってないっていうかそんなん
いまからプログラマになんてなろうと考えちゃ駄目だよ。これはマジで

20 ：名前は開発中のものです。：2007/12/06(木) 00:48:20 ID:5WVY/F2x

あと>2の
>いまどきのタスクシステムの実装
>http://omoikane.my-sv.net/gcss/tasksystem/index.php
>ゲーム・ノ・シクミ第11回 C++によるタスクシステムの実現
>今は無き C MAGAZINE 2006年1月号
>http://www.cmagazine.jp/contents/200601.html
この２つはもう要らなかったんじゃね？

追加で

関連スレ
ゲームにおけるデータ構造・クラス設計・パターン
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

C++ と今時のハードウェアでやる古典タスクシステムに替わるもの
ttp://www.issei.org/blog/archives/000225.html

21 ：名前は開発中のものです。：2007/12/06(木) 00:50:33 ID:AhaNCitW

↑派遣って自分の身の回りしか見えてないのか。
そうなるとインドや中国云々も世間で言ってることの受け売りだろう。

アウトソーシングで倹約できる分野の仕事に付いたら終わりかもしれないが
できない分野のプログラマもいるんだよ。

22 ：名前は開発中のものです。：2007/12/06(木) 03:19:35 ID:HdWZc6ta

ていうか解釈広くとっておかないとこのスレの意味がなくなるような
まあデータ構造スレへいけばいいだけのはなしなんだけどね

23 ：名前は開発中のものです。：2007/12/06(木) 06:11:52 ID:UqqGAKZG

自分のこだわり

１、ゲームループはシーンごとに別にする
例えばRPGで移動シーンと戦闘シーンがある場合、
移動時は移動ループに入り、戦闘時は戦闘ループに入る。
お互いにまったく別の処理をするので、
お互いが見えない方がソースを簡潔に書ける。
データの受け渡しは、2つの元の関数(mainなど)から引数で渡す。

２、ゲームループにはウィンドウメッセージループ(GetMessage)を使う
タイトル画面など自動的な処理する必要がない時は
ループを回さないでCPU率を軽くする。
再描画やキー入力などに備えておくだけ。
アクションなどの場合はTimeBegin系を使う。

24 ：名前は開発中のものです。：2007/12/06(木) 08:20:05 ID:AhaNCitW

俺から見たら嫌な作りだね。
ゲームのメイン部分では、メッセージループでどんなAPIを使うかなど思考の埒外にしたいね。
Direct3Dのデバイスのリセットやメッセージループがあちこちに散らばるなんて
デバッグで面倒が増えるだけだ。

25 ：名前は開発中のものです。：2007/12/06(木) 08:22:16 ID:2ewBanaL

>>21
その場合、開発をやめてしまったり潰れてしまう会社が多い
人材倒産っていうんだとさ

26 ：名前は開発中のものです。：2007/12/06(木) 09:05:59 ID:aorsrR2s

>>23
ないわ

27 ：名前は開発中のものです。：2007/12/08(土) 01:44:04 ID:CYfUYGS1

>>24
始めはシーンごとにコールバック関数を作っていたが、
グローバル変数やstatic変数を使いたくないので、
メッセージループ(の中にコードを書く)を複数作るようになった。

DirectXは使っていないのでよく分からないが、
デバッグは現在のシーンのコールバックかメッセージループ
を調べるだけなので分かりやすい気もする。

28 ：名前は開発中のものです。：2007/12/08(土) 05:37:29 ID:l8AiqE/q

これが同人ソフトだとしたら
タイトル画面が魅力的になるようにキャラを動かしたりアニメさせましょうと提案されても
「CPU使用率が上がるから駄目」「そういう構造になってないから駄目」と拒否するのか
だっさｗｗｗｗ

29 ：名前は開発中のものです。：2007/12/08(土) 05:40:49 ID:cj/l/sA4

>>23
まぁ、mine sweeper 作るならアリかなぁ。

30 ：名前は開発中のものです。：2007/12/08(土) 07:28:22 ID:CYfUYGS1

>>28
一般的に派手な動きは少ないシーンという意味で使った。
だからコンフィグシーンなどでもいい。

それとキャラをアニメさせたとしても、
OSに処理を返すとかをしっかりやれば重くならないと思う。
自分のレベルは昔の横シューティングぐらいで、
ホームページのフラッシュアニメレベルだとそうなりそう。

>>29
逆にロープレとか
シーンの種類の多いゲームの方が向いている気がする。

31 ：名前は開発中のものです。：2007/12/08(土) 13:14:00 ID:/PKo7xok

// たすくしすてむ

foreach(ball b in balls)
{
　　b.update();
　　b.paint();
}

32 ：名前は開発中のものです。：2007/12/08(土) 15:37:53 ID:dpKOt0nT

>>30
シーンの切り替えでクロスフェード等を使う場合はどうするの？
かならずフェードアウト／イン(もしくは一瞬)？

ドラクエみたいに、フィールドの上で戦闘やショップの処理、
ステータス表示なんかを行いたい場合とかもどうするのか気になる。

33 ：名前は開発中のものです。：2007/12/09(日) 05:57:18 ID:fYOmZnNF

>>32
クロスフェードというのは音楽のなんかみたいだがよくわからない。

ドラクエはショップを例にすると、
店の処理をポップアップ子ウィンドウを出して行う。
ドラクエの黒塗りのウィンドウがホントのウィンドウになる感じ。

店に入る時に、所持金、商品、所持アイテムなどのデータは受け取るが、
店には関係ない、主人公がどこにいるか、NPCがどこにいるかなどは、
まったく関係ない(コードに触れない)状態になっている。
もちろんデータは取って置いてあって、
店ループを抜けフィールドループに戻ると触れるようになる。

親ウィンドウメッセージが来たなら、店シーンに入る時に
保存しておいたメモリビットマップを使っての再描画、
閉じる(プログラム終了)、デフォ処理のみ行う。

子ウィンドウメッセージが来たなら、
キー、マウスによるカーソルの移動、決定、キャンセル、
WM_TIMERによるカーソルの点滅、
再描画、閉じる(店シーンの終了)、デフォ処理などを行う。

シーン切替えの説明にはなっていない気がするが、大本の違いは
if(g_scene == SceneField) **
else if(g_scene == SceneShop) **
のチェックを、よくあるやり方の場合、1ループ毎に行っていると思うが、
シーンを切り替える場合は、一度チェックしたら
**の所で別のゲームループまたはコールバックに入ってしまうので、
そのシーンから抜けるまでシーンのチェックは行わない。

34 ：名前は開発中のものです。：2007/12/09(日) 06:57:29 ID:fYOmZnNF

お店のシーン(ゲームループ、コールバック)にも複数あって、
買う売る出るの選択、買う物の選択、売る物の選択、
誰が買うかの選択、「○○を買った」と表示し、
キー入力があるまで待つシーンなどがある。

お店だけでもシーンがたくさんあり、
シーンごとに分けるとコードが膨大になり、たしかにめんどくさい。

ただ、買う売る出るの選択、買う物の選択、誰が買うかの選択などは
文字列を選択するという共通の処理なので、個別にシーンを作るのでなく、
ひとつの文字列選択シーンを作り、使いまわしている。
そのシーンでは、どの位置の文字列を選択したかのみをチェックし、
そのシーンを抜けた後で、お金が足りているかなどのチェックをする。

「○○を買った」と待つのも、「扉を開けた」、「○○を手に入れた」
などと同じキー入力があるまで待つという共通の処理なので、
ひとつの待つシーンを作り、使いまわしている。

35 ：名前は開発中のものです。：2007/12/09(日) 07:20:28 ID:nQCm/lvH

誰もが普通に使うような技法や、誰もわざわざやろうとしない技法に特別な名前を付けて、
俺様天才！俺様スゲーーーー！！！

というのがタスクシステムの本質だとすれば、きっとスレ違いではないのだろうな。

36 ：名前は開発中のものです。：2007/12/09(日) 09:00:37 ID:fYOmZnNF

>>35
確かに自分のやり方以外のやり方はあまり知らないので、
他のやり方と比べた客観的な説明にはなっていないのかも。
出直してきます。

37 ：名前は開発中のものです。：2007/12/09(日) 19:28:44 ID:Lzb0B9+Z

>>33
クロスフェードってのは、元の場面をフェードアウトしつつ、新しい場面をフェードインすること。
ゲームの場合だと、元のシーンを後ろで動かしつつ、新しいシーンの描画のアルファ値を
上げていって切り替える感じかな。
計算や描画の重さもあるから、「前のシーンを動かしつつ」ってのは難しいかもしれんが。

シーン管理の方法は大体理解した。
ゲームのロジックの中にWindows独自のルールが平然と出てくるのは気になるが、
その辺割り切って作るならいいんじゃないかな。

38 ：名前は開発中のものです。：2007/12/09(日) 20:16:34 ID:QBlb02fM

いまのマシンってワンシーンで限界まで性能ださないからロードさえ気をつければ
クロスフェード（２シーン分）ぐらいなら普通にいけると思うよ
PS２とかじゃ苦しいけど

39 ：名前は開発中のものです。：2007/12/09(日) 20:24:41 ID:RxPCFRcK

>>38
> PS２とかじゃ苦しいけど
あれは性能より VRAM が…

40 ：名前は開発中のものです。：2007/12/09(日) 20:25:58 ID:RxPCFRcK

>>34
アニメーションはどうするの？　ドラクエだと敵が動いたり、攻撃時にエフェクトが
出るような場合。

41 ：名前は開発中のものです。：2007/12/09(日) 20:38:58 ID:QBlb02fM

複数のシーンを絡ませて管理する機能が必要なんだから
シーン同士を管理するシーンマネージャーを作ればいいだけの話じゃねぇの？
シーン間を飛び越えてマップやキャラのデータが存在し続けるんなら
キャラやマップはシーンに属さないっていうかシーンが抱えるべき情報ではない
つまりシーンの前処理後処理でロードアンロードされないわけだな
じゃ、誰がするのかというとさっき用意したシーンマネージャーが管理するわけだ
シーン間を接続する役目もシーン間が絡む以上シーンマネージャの仕事だろう
シーンクラスの役目は今の情報・状態から自分の表示・実行に必要なデータをシーンマネージャに
返す機能だけになるんじゃね？
それをうけてシーンマネージャは複数のシーンを総合的にみて現在必要なデータを搾り出すと
シーンマネージャに当たるもんは結構でかくなるぜ
これをシーンごとに頑張って管理しようとするとデスマーチ確定

42 ：名前は開発中のものです。：2007/12/09(日) 23:12:03 ID:rwPHbHKr

>>23
> １、ゲームループはシーンごとに別にする
つまりタスクシステムだね
タスクを入れ替えることで違うシーンに対して別のループを提供できる
もしタスクシステムを使わなければシーンの数だけほぼ同じソースを別個に書かなければならない
1箇所ソースを変更するだけでそれらのシーンすべてのループを書き換えることになりメンテナンス性が著しく落ちる

> 例えばRPGで移動シーンと戦闘シーンがある場合、
> 移動時は移動ループに入り、戦闘時は戦闘ループに入る。
戦闘タスクと移動タスクを入れ替えるってことだね

> お互いにまったく別の処理をするので、
> お互いが見えない方がソースを簡潔に書ける。
そう、タスクシステムではタスク単位で完結するから独立性が高い記述が可能になる

> ２、ゲームループにはウィンドウメッセージループ(GetMessage)を使う
CPU使用率を稼げるし、仮に必要になっても多少のループならタイマーで十分だよね

> タイトル画面など自動的な処理する必要がない時は
> ループを回さないでCPU率を軽くする。
タスクシステムを使えばシーンごとにまったく違う処理が書けるから
シーンごとに違うメインループを書くことも可能なんだよね
仮にオープニングでアニメーションやデモを追加したい場合
タスクを入れ替えることで対応可能

43 ：名前は開発中のものです。：2007/12/09(日) 23:19:22 ID:rwPHbHKr

>>24
タスクシステムを使えばそれらは一箇所に記述するだけでいい
重複した記述を最小限にできるタスクシステムはデバッグにも役立つ

>>27
限りなく正解に近い
タスクシステムとはコールバック進化系の一種だ
コールバックされる関数を制御する仕組みが追加されたものがタスクシステムなのだ

44 ：名前は開発中のものです。：2007/12/10(月) 00:12:04 ID:kVa9UCh4

何が「限りなく正解に近い」だ、このおっぱい占い野郎
「コールバック進化系」とか無駄にESP値を要求する造語を散りばめんな

コールバック＝何かをきっかけに呼び出される
それだけだ。これの進化系ってどういうことだ。具体的に何に対して何が進化したんだ

45 ：名前は開発中のものです。：2007/12/10(月) 00:17:12 ID:FgTvF4nS

また面白い燃料が投下されたようですね

46 ：名前は開発中のものです。：2007/12/10(月) 01:07:39 ID:AFViqWGu

> > １、ゲームループはシーンごとに別にする
> つまりタスクシステムだね

この時点で釣りとしか思えない。

47 ：名前は開発中のものです。：2007/12/10(月) 08:12:39 ID:oZKWD7tz

店なんか床に商品並べて店番一人置いておけばループ分けなど不要

48 ：名前は開発中のものです。：2007/12/10(月) 11:26:27 ID:4KeM6Lnp

シーンって何よ？
言葉の定義なくして話進められても？？だぜ

49 ：名前は開発中のものです。：2007/12/10(月) 13:37:22 ID:NNHyQgcJ

また定義厨か
さすがにそれはないな

50 ：名前は開発中のものです。：2007/12/10(月) 16:08:36 ID:FhEMVCWa

>>48
さてはDirect3D使ったこと無いな？

51 ：名前は開発中のものです。：2007/12/10(月) 17:15:59 ID:TRJA29h8

>>48
見た感じ
・タイトル画面
・戦闘画面
・マップ移動画面
みたいなのをシーンと書いてあるだけ。

>>50
なぜ突然Direct3D・・・
(IDirect3DDeviceN::BeginScene？)

52 ：名前は開発中のものです。：2007/12/10(月) 18:15:58 ID:kVa9UCh4

定義厨の俺でも
さすがに>>48はないな

53 ：名前は開発中のものです。：2007/12/10(月) 19:32:53 ID:ynLW352R

ゲームをまともに作れないことが明らかな>>48の発言に、一同、シーンとなった。

54 ：名前は開発中のものです。：2007/12/10(月) 19:44:32 ID:sWUDY/qD

プログラム開発現場の駄洒落は99%、発言者が死ねばいいのにという感想になる。
しかもバグの取れない苛立ちまでも一手に引き受けてな。

55 ：名前は開発中のものです。：2007/12/11(火) 00:04:17 ID:T0+r8UQD

>>53
誰がシーンとなることを言えと

56 ：名前は開発中のものです。：2007/12/11(火) 00:53:40 ID:ECQVp0Tr

さっきからチーンチーンチーンチーンってお前等は変態か？

57 ：名前は開発中のものです。：2007/12/11(火) 08:56:37 ID:xDs0NYc0

ユビキタスとかWeb2.0とかあんな感じの電波を感じるな

58 ：名前は開発中のものです。：2007/12/15(土) 22:33:07 ID:dW/LIK6y

>>44
説明しよう！

＞コールバック＝何かをきっかけに呼び出される
まさにその通りだ！！
コールバック関数とは関数ポインタを呼び出し側に登録しておき
適宜呼び出される方式だ
この方式はタスクシステムにも採用されている

タスクヘッダには初期値としてタスクエンド（Cでは大抵NULLだろう）を示すポインタが入っている
図1.タスクヘッダ → タスクエンド

ここにタスクを登録していくことで呼び出される関数が増えていく

図2.タスクヘッド → タスク1 → タスク2 → タスクエンド

こうして生成されたタスクリストのタスクはタスクループで順番に呼び出されていく

図3.タスクループ
　　　　　↓
　　　タスクヘッド → タスク1 → タスク2 → タスクエンド

以上のような構造からタスクシステムはコールバック関数であるといえる

コールバック関数に比べてタスクシステムを特徴づけているのは次の3点だ

　　1.呼び出し側と呼び出され側が1対多である
　　2.呼び出し側は機能を持たない
　　3.呼び出され側がさらに呼び出され側を登録することができる

以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである

59 ：名前は開発中のものです。：2007/12/16(日) 00:14:11 ID:tU3FXTu1

>>58
> 以上の特徴により、動的に機能を拡張し、相互に連携することが可能になったのである
単にインスタンスの数が可変なだけで、連携については何も触れてないじゃん。

60 ：名前は開発中のものです。：2007/12/16(日) 01:22:25 ID:Uds4tbII

先頭をheadにするなら末尾はtailにしてくれ
末尾をendにするなら先頭はbeginかstartにしてくれ
俺が言いたいのはそれだけ

61 ：名前は開発中のものです。：2007/12/16(日) 01:27:07 ID:tU3FXTu1

>>58
どうでも良いけど
> タスクヘッダには初期値としてタスクエンド（Cでは大抵NULLだろう）を示すポインタが入っている
番兵1つ置いた方が、余計な場合分けが減って嬉しくない？　
BSDで使われてる TAILQ でも、ヘッドは

#define TAILQ_HEAD(name, type) \
struct name { \
struct type *tqh_first; /* first element */ \
struct type **tqh_last; /* addr of last next element */ \
}

っつー定義だよな。

あと C++ だと昔は std::list<> 好きだったが、最近は std::vector で、フレームの最後に
まとめて std::remove_if と std::vector<>::erase 組み合わせて済ませる方向に。

62 ：名前は開発中のものです。：2007/12/16(日) 01:50:58 ID:eEobSst5

>>58
タスクシステムが誕生する70年代末期よりも遥か前の
古典的なコンピュータのプログラムで既に同じようなことをやってるだろ。
例えば、割り込み信号にフックするとき、つまり割り込み処理ルーチン
（常駐プログラム・サービス）を割り込みベクタテーブルに追加するとき
既存のルーチンがあればそれと数珠繋ぎにするだろ

63 ：名前は開発中のものです。：2007/12/16(日) 02:16:17 ID:eEobSst5

単純で乱暴なやり方をするなら、割り込みベクタテーブルに
既存ルーチンの代わりに自分のアドレスを上書きして
先に自分の処理を呼び出させ、自分の処理が終わったら
既存ルーチンへジャンプさせる。つまり割り込み処理に割り込む。

もう少し紳士的なやり方なら（同じ割り込み信号にフックする）
割り込み処理ルーチン同士で協定を作り
割り込み処理ルーチンのリストを管理するルーチンを用意する。

こうした仕組みは>>58の言う

　　1.呼び出し側と呼び出され側が1対多である
　　2.呼び出し側は機能を持たない
　　3.呼び出され側がさらに呼び出され側を登録することができる

を全て満たしている。

　呼び出し側＝ハードウェア
　呼び出され側＝割り込み処理ルーチン

ハードウェアは割り込み信号に応じて割り込みベクタテーブルの
当該アドレスに登録されてる割り込み処理ルーチンを呼び出す。
そしてリストに登録された順に次々呼び出される。
割り込み処理ルーチンは処理完了時のリターン命令を
他のルーチンへのジャンプ命令に書き換えることで
子ルーチンの追加が可能

64 ：名前は開発中のものです。：2007/12/16(日) 02:18:07 ID:eEobSst5

紳士的なやり方なら
呼び出し側＝割り込み処理ルーチンのリスト管理プログラム、か

65 ：名前は開発中のものです。：2007/12/17(月) 15:54:34 ID:d05xYvvB

意見は出したくないが文句はつけたい
そんな嫌タスク厨の巣窟だというのがわかる流れでしたね
文句つけてる暇があったら、58がかすむくらいの有益情報でも書き込めっての

66 ：名前は開発中のものです。：2007/12/17(月) 16:25:30 ID:fh4AIKkl

またブーメラン芸か

67 ：名前は開発中のものです。：2007/12/17(月) 16:43:25 ID:fh4AIKkl

=210.130.51.98 ヘ(　`Д)ﾉ

68 ：名前は開発中のものです。：2007/12/17(月) 21:14:21 ID:PVpDrrvq

コールバック進化系（笑）スィーツ（笑）

69 ：名前は開発中のものです。：2007/12/17(月) 21:26:04 ID:FK63IV8y

確かにプログラム用語の大半はスイーツ（笑）テイストを感じさせる回りくどい言い回しだな

70 ：名前は開発中のものです。：2007/12/17(月) 23:00:26 ID:ZuWNJ+Fe

つまりタスクシステムは何なわけ？
わたしわかりまぁせん

71 ：名前は開発中のものです。：2007/12/17(月) 23:12:00 ID:DxnpSp/c

foreach

72 ：名前は開発中のものです。：2007/12/17(月) 23:52:08 ID:lVhxy2mV

ここはwhile(1);つかfor(;;);かな。最適化されてればどっちも同じだろうが。

73 ：名前は開発中のものです。：2007/12/18(火) 20:23:42 ID:RgUcH/0L

1フレーム毎に（大抵）全てのオブジェクトのupdateメソッドがコールバックされるシステム

と考えていいんじゃね？

74 ：名前は開発中のものです。：2007/12/18(火) 23:42:42 ID:LovnfmvP

-----------------------------------------------------------
987 ：名前は開発中のものです。：2007/12/03(月) 23:02:28 ID:hqsjjSWF
　スレのログ見ると、定期的に「タスクシステム＝デザインパターン」とか絶叫してる人がいるみたいだが
　この人たちの言うタスクシステムってどのタスクシステムの話なんだろうね？

　【１．タスクシステム＝Logician Lordで紹介されているもののことだよ】
　　　ギャラクシアンとその直系に見られる特徴的な実装こそタスクシステムであり
　　　その要件を満たさない異形のコードは全て紛い物だ。タスクシステムとか名乗るな
　　　　　　　　　　　
　【２．タスクシステム＝リスト巡回UPDATE。ていうかforeachだよ。】
　　　ギャラクシアンのそれとは全く別物の、異形のコードであろうとも
　　　俺がタスクシステムって呼べばタスクシステムなんだいバーロー
-----------------------------------------------------------

観察してると、どうもタスク厨って呼ばれてる子は後者が多いような気がしてきた。
何も知らない頭白紙の状態で松浦教祖に洗礼を受けたこの恐るべき子供たちは
タスクシステムというフレーズにとても執着してるようだが、厨房神経を刺激する
何かがあるのか？

とにかく何が何でもこのタスクシステムという古のローカル用語を俺様理論で
再定義・再構築してやろう、という無駄な努力がヒシヒシと伝わってくるんだが
ある意味で（マムコ信者に言わせれば）由緒正しいｗローカル用語をわざわざ
掘り起こしてきて流用するのは止めてくれって思う

「朕思うに」「新概念」「新解釈」「オナニー」「再構築」は好きなだけやっていいから
なんか別の名前にしろよ。「リスト巡回UPDATE」でも「僕のforeach」でも
「エターナルフォースブリザードシステム」でも何でもいいからさ

75 ：名前は開発中のものです。：2007/12/18(火) 23:44:17 ID:m+PO2WK4

私はもうタスクという言葉自体を使ってない

76 ：名前は開発中のものです。：2007/12/19(水) 08:00:04 ID:hUc1dbeP

ゲイは身をタスク。

77 ：名前は開発中のものです。：2007/12/19(水) 15:24:26 ID:Ir64JLrB

○○システムって言い方自体、かなり厨2魂を揺さぶるフレーズだよ

78 ：名前は開発中のものです。：2007/12/19(水) 15:25:28 ID:F/n53iWq

じゃあタスクパターンで

79 ：名前は開発中のものです。：2007/12/19(水) 20:46:55 ID:UEhDeB5F

＞タスクパターン

「ストラテジーパターン？あー、AoEとか大戦略ってパターンだよね」
とか真顔で言ってのけるウィザード級ハッカーの心の琴線に触れる

80 ：名前は開発中のものです。：2007/12/19(水) 20:47:44 ID:hUc1dbeP

じゃあ、「タスクモンスターとのアルティメットコラボレーション」で。

81 ：名前は開発中のものです。：2007/12/20(木) 07:20:27 ID:c5xOqVc7

>>74
タスクシスステム改め
ギャラクシアンロジックかLogician Load Systemでおｋ

82 ：名前は開発中のものです。：2007/12/20(木) 20:44:20 ID:tLt8cR7R

エロスロジック

83 ：名前は開発中のものです。：2007/12/21(金) 00:29:57 ID:rVMYRhvV

オナニーシステムで通じると思うんだ
リスト巡回オナニーも分かりやすい
オナニーforeachは微妙
オナニーパターンはオナテク板で使用済み

84 ：名前は開発中のものです。：2007/12/21(金) 00:38:40 ID:Jo2a6K/I

じゃ、タスクシステム関連は、PinkBBSに移動しようか。

85 ：名前は開発中のものです。：2007/12/21(金) 01:45:05 ID:sZQMdwXf

僕の肛門もリスト巡回されそうです

86 ：名前は開発中のものです。：2007/12/31(月) 11:54:08 ID:K8WL7pln

どうすればギャラクシアンのソースを見られますか？

87 ：名前は開発中のものです。：2007/12/31(月) 15:03:05 ID:73X1rpDN

逆アセンブルすればそれがほぼソース

88 ：名前は開発中のものです。：2007/12/31(月) 18:29:38 ID:K8WL7pln

>>87
ファミコン版でいいですか？

89 ：名前は開発中のものです。：2008/01/07(月) 06:40:49 ID:5ateSYSb

タスクシステムこそ
ゲーム業界にのみ伝わる現代の魔術
連綿と口伝によってのみ受け継がれ
変化し、進化と退化を繰り返す
その亜流は数知れず、もはやその全てを語れるものはいない

90 ：名前は開発中のものです。：2008/01/07(月) 14:38:53 ID:GyFmGIbt

都市伝説テンプレート

91 ：名前は開発中のものです。：2008/01/14(月) 14:54:45 ID:qTpR8IwF

つまりはスケジューリングでおk？

92 ：名前は開発中のものです。：2008/01/14(月) 15:24:10 ID:qReoD61a

少なくともスケジューリングは含まれるだろうな

93 ：名前は開発中のものです。：2008/03/13(木) 22:58:00 ID:Bu/r75Um

保守

94 ：名前は開発中のものです。：2008/04/03(木) 17:01:08 ID:0WE0DNgq

ゲームプログラミングで分厚い目の本選んだら
著者流タスクシステムの解説が大半で(´･ω･`) ｼｮﾎﾞｰﾝ。

95 ：名前は開発中のものです。：2008/04/03(木) 18:08:34 ID:HifUC8Yv

>>94
>>7

96 ：名前は開発中のものです。：2008/04/03(木) 18:34:18 ID:0WE0DNgq

逆引きタスクシステム
これだorz

97 ：名前は開発中のものです。：2008/04/03(木) 18:37:31 ID:0WE0DNgq

ちょっと違ったな。
買ったのは「逆引きゲームプログラミング」って書いてあるから姉妹本かな。
表紙に堂々とタスクシステムなんて書いてあったらさすがにスルーするしねw

98 ：名前は開発中のものです。：2008/04/06(日) 18:50:02 ID:cIcTAloV

Javaはポインタが使えないからイテレータ使うしかないのかな？

99 ：名前は開発中のものです。：2008/04/06(日) 21:07:19 ID:RBp65Y5g

>>98
Java がポインタを使えないのは確かだが、たぶん >>98 はそれ以前の
勘違いをしている。

100 ：名前は開発中のものです。：2008/04/06(日) 21:09:30 ID:ptmozDNb

ねぇぼく、すれたいよめゆ？

101 ：名前は開発中のものです。：2008/04/06(日) 21:24:10 ID:hAyEqcH5

>>98にタスク厨の素質を感じた
お前たち、大事に育てなさい

102 ：名前は開発中のものです。：2008/04/07(月) 04:08:41 ID:qDynBUHm

■星屑きらら杯
ttp://kirara111.sakura.ne.jp/
主催：１１１
超絶神星屑きららを迎えての史上最強コンテスト。
優勝賞金はwebマネー３万円ぶん。
今までの常識は通用しない、コードネームは・・・アンタッチャブル。

103 ：名前は開発中のものです。：2008/04/07(月) 16:38:25 ID:V2Suu5FZ

ほえ

104 ：名前は開発中のものです。：2008/04/20(日) 10:58:52 ID:tFc51Cra

boost::circular_bufferってタスクシステム向きだと思う

105 ：名前は開発中のものです。：2008/04/21(月) 20:44:13 ID:RVUuTgSY

どこらへんが向いてると思うの？
バッファからあふれた分は上書きされるわけだが・・・

106 ：名前は開発中のものです。：2008/05/05(月) 11:03:20 ID:RRXW9Hmv

結局タスクシステムって良いプログラム？？それとも悪いプログラム？？

107 ：名前は開発中のものです。：2008/05/05(月) 16:01:08 ID:h5LjEvcu

普通のプログラム

このボケを期待してたんだろうけど若い人はこのネタ知らないよ。
欽どんと欽どこのどっちだったかな。

108 ：名前は開発中のものです。：2008/05/05(月) 16:01:33 ID:/b4BEf3P

適材適所
なんでもタスクシステムで済まそうとすると苦労する

109 ：名前は開発中のものです。：2008/05/05(月) 18:20:31 ID:mspxDfm7

この絵は良い絵ですか？悪い絵ですか？

110 ：名前は開発中のものです。：2008/05/23(金) 05:11:37 ID:urjZe250

もーやだ
普通に逐次処理で書いて並列的な仕事はスレッドっぽい何かでやりたい
ゴリゴリとタスクとやらで状態マシン書いていけるお前らはすげーよ
俺は頭悪いから無理。forループ相当のことやるだけでも混乱する

111 ：名前は開発中のものです。：2008/05/24(土) 21:14:24 ID:MJp3dmaD

>>110
普通に考えてスレッド同士の関連の処理考えるだけで頭痛いじゃん
分けたからどうだってのよ？
結局

主人公：スレッドNo１
敵A：スレッドNo2
障害物A：スレッドNo３

ってなったら、例えスレッドに分けたとしても
関連時にスレッドNo１ｘスレッドNo２ｘスレッドNo3のステータス分の
対応表ができることはかわらんがな
言ってることわかる？

つまり、スレッドごとにステータスが３つ（仮に状態○、△、□とする）あったら

　　　　　　　敵A○　敵A△　敵A□
主人公○　　STA 　　STB　　　STC
主人公△ 　STC　　　STC　　　STA
主人公□　　X　　　　　X　　　　　X

　　　　　　　敵A○　敵A△　敵A□
障害物○　　STA 　　STB　　　STC
障害物△ 　STC　　　STC　　　STA
障害物□　　X　　　　　X　　　　　X

主人公ｘ障害物省略

STA　　ステータスA
STB　　ステータスB
X　　　　なにもおきない
とか必要になるってわかるだろ？

112 ：名前は開発中のものです。：2008/05/25(日) 00:58:28 ID:6V9YbMCv

>>111
タスクシステムとやらを使っても
全部処理しなければならないというのは一緒なんだろ
ならどっちでもいいじゃないか、状態遷移の話をしているのか?

113 ：名前は開発中のものです。：2008/05/25(日) 01:06:31 ID:6V9YbMCv

スレッド使えばこんな感じに書けるはずだが

主人公() {
while (true) {
if (A) ... ;
else if (B) ... ;
else if (C) ... ;
}
yield();
}

タスクシステムとやらを使ったときのありえない複雑さは凡人の俺には理解できない
簡単にできるものをわざわざ複雑に書く、天才だけの思考は全く理解できんな

114 ：名前は開発中のものです。：2008/05/25(日) 05:25:51 ID:dDrBARgy

>>111が何を言いたいのかはよくわからんが、
タスクシステムも>>113も、複雑さは特に変わらないように思えるけど。

class 主人公 : public Task {
　void 実行() {
　　if (A) ... ;
　　else if (B) ... ;
　　else if (C) ... ;
　}
};

どの辺が、>>113に比べて「ありえない複雑さ」なんだ？

115 ：名前は開発中のものです。：2008/05/25(日) 05:35:43 ID:5unbeWfm

サブクラスにいちいちIF仕込んでんのかよｗ

116 ：名前は開発中のものです。：2008/05/25(日) 08:15:02 ID:vQVRM4Hf

>>110ですが、俺は>>112-113とは別人です一応
まあ使ってんだけどねタスク。仕事だし

>>111の言うような連携処理は、処理自体の複雑さの問題だと思うんだわ
俺が言ってんのはもっと低レベルな話でー

//10フレームかけて10ドット右へ
for (int i=0; i<10; ++i) {
move_right(1);
}

とやればいいとこが、

//10フレームかけて10ドット右へ
void task_handler() {
static int i = 0;
if (i >= 10) {
go_next_mode(); // 処理が終わったよ！
return;
}
move_right(1);
}

みたいになるのが長いと言うか分かりづらいと言うか、処理がこみいってくると混乱するなあと。
俺、なんか勘違いしてますかねー？

117 ：名前は開発中のものです。：2008/05/25(日) 08:40:06 ID:vQVRM4Hf

ごめん、ちょっと直した。あとインデント入れた

//10フレームかけて10ドット右へ
for (int i=0; i<10; ++i) {
　　yield();
　　move_right(1);
}

//10フレームかけて10ドット右へ
void task_handler() {
　　static int i = 0;
　　if (i++ >= 10) {
　　　　go_next_mode(); // 処理が終わったよ！
　　　　return;
　　}
　　move_right(1);
}

118 ：名前は開発中のものです。：2008/05/25(日) 09:38:01 ID:xbxgumKd

>>117
前者の方が不自然に感じる俺はどうすれば・・・

119 ：名前は開発中のものです。：2008/05/25(日) 10:39:48 ID:qUO2NAd9

>>113
スレッドの生成/破棄がどれだけ高コストか分かっているのかね？

>>117
途中のフレームでやっぱり左に切り返す処理等を入れたら後者の方が
遥かにシンプルになる。

120 ：名前は開発中のものです。：2008/05/25(日) 10:52:41 ID:7UG2hamH

>>112
いや、だから変わらんでしょ？って言いたかったわけよ

121 ：名前は開発中のものです。：2008/05/25(日) 10:57:13 ID:7UG2hamH

あーだから、スレッドなんて作っても
根本の複雑さが問題なんであってタスクシステムなんて
してもここは変わらんよと

122 ：名前は開発中のものです。：2008/05/25(日) 11:08:35 ID:K3dp7DqQ

時間かけて行う処理、広くいうと、ある条件を満たすまで待って次に進むような逐次処理
を書こうとすると>>117の言うようなストレートに記述をしたくなるのは分かる

こういうのをコルーチン(co-routine)っていうんだっけ。

ただ>>119の後半にあるように条件判断をイテレーションごとに行う必要があるなら、
コルーチンであってもコルーチンっぽくは見えなくなってしまうかもしれない

（スレタイにあわせていうなら）
たとえば制御系タスクとワーカ系タスクっていうのがあって、
それぞれ記述しやすい方法が違ったりする？

制御系タスク　　　イテレーション（表示フレーム？）ごとに細かい条件判定を行い、大きな分岐がある
ワーカ系タスク　　↑に比べて単純なループ、条件判定は脱出するかどうか、程度

おれなら、
前者はメッセージディスパッチャっぽく書きたい。
後者はコルーチンっぽく書きたい。
なあ。

123 ：名前は開発中のものです。：2008/05/25(日) 11:56:53 ID:MyJQpRZH

結局何やっても複雑になるんだからどんな実装してもおｋ
Flashなんかも標準でタスクシステム（笑）のような仕組み持ってるんだけど、
やっぱ処理順序とかインタラクトとかみんな悩んでるお

124 ：名前は開発中のものです。：2008/05/25(日) 14:13:14 ID:7UG2hamH

作るもん間違ってんじゃねぇの？
>>117みたいな処理ってスクリプトやプログラムで解決しないで
フラッシュみたいなタイムライン（？）があるビジュアル的なもんがあったほうがいいんじゃねぇの？

んでキャラの状態遷移みたいなもんは遷移図と各ステータスの遷移条件表がないとどうしたってダメだろ？
こんな属性の違うもんをいっぺんに解決しようとする手段を探してること自体
問題の切り分けができていないんと違うか？

タスクシステムはあくまで全然別な独立処理をわかりやすく書くためだけのもんだろ
こいつは上記の２つの問題にはなんの解決策にもなっていねぇ
ゲームプログラムが複雑なのはオブジェクト同士の絡みだろ？

125 ：名前は開発中のものです。：2008/05/25(日) 14:17:00 ID:vQVRM4Hf

>>119
あ、そうなのか？　あー、そうかも。

>>122
なる。制御系とワーク系って分けると、なんか分かりやすい。
多分俺がストレスを感じるのは、ちょっとした演出、タイトル画面のデモ、プレイ前の説明画面、
そういう目立たないけど手早くたくさん作らないとならない動きをつけるために、
ゲーム時のキャラクター制御と同じくらいがっちり組まされることなんだな。
実際、ゲーム中の制御は最初からがっちり組みにいくんでストレス感じないし、
俺の場合はイベントドリブンで考えた方が組みやすいから確かに>>119の言う通りかも知れない。

しかし・・・だまされないぞ！
イベントドリブンがしたければ別にスレッドでもできるわけで（Windowsで言うPeekMessageね）、
スレッドのコストの問題は（色々と解決方法が考えられるはずなので）ここでは無視して考えてほしいんだけど、
処理によってはタスクと同じ機構をスレッド上に構築することがあったとしても、
それが可能なことは悪いことじゃないと思わない？
それはＣ＋＋がベターＣとして使えるように、スレッドがベタータスクとして使えることだとは思わない？

126 ：名前は開発中のものです。：2008/05/25(日) 15:41:32 ID:0NNJH3W1

>>122
コルーチンとかファイバーとか言うね。
少し違うけど継続(continuation)の方が知られてるかな。
スレッドは同時に走ることを期待するからこの点は違う。

そういやゲーム方面でLuaが人気あるらしいけど
コルーチンも使ってるのかな。

127 ：名前は開発中のものです。：2008/05/25(日) 15:43:46 ID:dDrBARgy

我々に必要なスレッドは２つ。
メインスレッド、データ読み込みスレッド、BGM再生スレッド、この３つだ。
スクリプトでタイトル画面実装してコルーチン使う、とかならともかく、
キャラの制御なんかと同じレベルにスレッドぽこぽこ作るのは嫌だなぁ。

つか、どう実装するにしても、
ボタンによる演出スキップとか、時間経過によるデモへの移行とか、
タイトル画面程度のものでも状態遷移は考えなきゃならないと思うけど。
まあ、キャラなんかとは、複雑さは全然違うけどさ。

128 ：名前は開発中のものです。：2008/05/25(日) 15:55:46 ID:7UG2hamH

何度も言うけどスレッドは状態遷移の複雑さの問題を解決しないよ

129 ：名前は開発中のものです。：2008/05/25(日) 16:03:27 ID:zNY0acjC

マトリクスでも書いて整理しろよ

130 ：名前は開発中のものです。：2008/05/25(日) 16:43:17 ID:vQVRM4Hf

全レスしたいけどウザがられるしとりあえず

>>128
んとですね、夢を語ってるように見えたかも知れないけどもｗ
スレッドがゲームの状態遷移の複雑さを解決すると考えているのではなく、
タイマードリブンないわゆるタスク処理というものは、
本来ローカル変数やプログラムカウンタという言語上の機能を
プログラマが自分で状態として（ワーク変数などで）管理しなくてはならないのが
負担だと思いませんかと言いたいのです

131 ：名前は開発中のものです。：2008/05/25(日) 17:01:19 ID:vQVRM4Hf

あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
ＯＳが用意するプロセス／タスク／スレッドは想定してないです

132 ：名前は開発中のものです。：2008/05/25(日) 17:02:07 ID:7UG2hamH

>>130
もとのレスと比べて全然いってることが違うような希ガス

133 ：名前は開発中のものです。：2008/05/25(日) 17:02:23 ID:6V9YbMCv

おれも>>130と同じ事が聞きたい
話を広げて逃げないでください>天才タスカーの皆さん

134 ：名前は開発中のものです。：2008/05/25(日) 17:15:50 ID:7UG2hamH

>>133
んあ？
考えてることがさっぱりわからん
ゲームプログラムで複雑なのは各オブジェクトの状態遷移であって
タスクシステム云々は問題じゃねぇから気に入った方法で好きにしろってのが
みんなの総意だろ（おそらく）

ここまででなんか違うこと言ってるならなんか言ってみ？

135 ：名前は開発中のものです。：2008/05/25(日) 17:22:31 ID:6V9YbMCv

>>134
130に対する答えにはなってないな
質問の意味が理解できないのならできるだけわかりやすく解説するが、必要か?

136 ：名前は開発中のものです。：2008/05/25(日) 17:23:16 ID:A+/TQh+q

>あ、俺が想定してるスレッドは擬似スレッドです。コルーチン等
最初から「マイクロスレッド」と言えば無用な混乱を避けられるぞ

137 ：名前は開発中のものです。：2008/05/25(日) 17:23:43 ID:vQVRM4Hf

>>134
ですよねー

すんません、でかけてきます

138 ：名前は開発中のものです。：2008/05/25(日) 18:00:32 ID:xbxgumKd

ゲームプログラムからそれを取ったら後は何が残るんだ？

139 ：名前は開発中のものです。：2008/05/25(日) 18:10:01 ID:dDrBARgy

>>113 の if の羅列は状態ごとの処理の振り分けじゃなかったのか。

140 ：名前は開発中のものです。：2008/05/25(日) 18:24:49 ID:6V9YbMCv

>>139
状態ごとの処理の振り分けが何を指すのかわからないけど
マイクロスレッドと状態遷移のトレードオフとして

例えば信号の状態が「赤、青、黄」の三つだとして

普通に状態遷移を書く場合(Stateパターンではなく)
state; // をメンバ変数か、グローバルで
if (state == 赤) ... ;
else if (state == 青) ... ;
else if (state == 黄) ... ;

それよりも、スレッドを用いて
while (true)
{
赤(); sleep(?);
黄(); sleep(?);
青(); sleep(?);
}
の方が直感的で読みやすいでしょという意味で書いたつもり。

141 ：名前は開発中のものです。：2008/05/25(日) 18:38:09 ID:A+/TQh+q

青→黄→赤と遷移するんだろう？
さっそくバグを仕込んでいるじゃないか

142 ：名前は開発中のものです。：2008/05/25(日) 18:52:00 ID:6V9YbMCv

GOFパターンで言うと
タスクシステムとやらがStateのCommandをListに突っ込んだものなら
Stateのメリットは拡張性にあって可読性にはないから
可読性を優先するならマイクロスレッドの形を取るべきだ
と言いたいわけだ。

ところが天才タスカーはタスクシステムを使えば簡単になるよとしか言わない
可読性が低下するというデメリットにも触れない、又は理解していない
そう見える

143 ：名前は開発中のものです。：2008/05/25(日) 19:34:28 ID:dDrBARgy

>>140
？　ごめん。>>113 をどう読んでも、そうは解釈できんわ。
……まあ、>>140として、
それだと、他から状態を変えたりしにくいし、
仕様変更への対応も大変じゃないか？
仕様が確定していて絶対変わらないというのならいいけど。

>>142
「簡単になる」とは誰も言ってないよ。
そもそも「すべての場合でタスクシステムを使え」とも言ってない。
（実装方法そのものが本質ではないから）状態遷移の複雑さに応じて、
自分のやりやすい方法でやれと、みんな言ってると思うんだが。
何か変な思い込みが議論を阻害してる気がするな。

144 ：名前は開発中のものです。：2008/05/25(日) 19:57:43 ID:7UG2hamH

>>140
上はstateによって処理を決定するけど下はなんだ？
stateを途中で変えられないような気がすんだけど
なんか比べるもん間違ってね？

145 ：名前は開発中のものです。：2008/05/25(日) 22:16:46 ID:6V9YbMCv

142に書いてる
>Stateのメリットは拡張性にあって可読性にはないから
>可読性を優先するならマイクロスレッドの形を取るべきだ
マイクロスレッドの方が可読性が高いかどうかは主観によるものだが
これを否定するのなら、そっちに話を持っていく

可変性や拡張性が低いってのも142に書いてるけど
そもそもスレッドを与えるクラスが小さいものであるなら、変更は脅威ではない
逆に、タスクシステムとやらが変更に強いとも断定はできない
あれは新しいクラスを作る拡張に強いのであって、置き換える形の変更には強いが
修正する変更はスレッドを用いたものと同じようなものだ

146 ：名前は開発中のものです。：2008/05/25(日) 22:45:40 ID:dDrBARgy

たとえば、>>140 の信号に「夜間は点滅する」「殴られたら停止する」という仕様が追加された場合、

前者の、普通に状態遷移を書く場合だと、
void 夜になる() { if (state != 停止) state = 点滅; }
void 朝になる() { if (state == 点滅) state = 赤; }
void 殴る() { state = 停止; }
みたいなメソッドを追加して、
if (state == 赤) ... ;
else if (state == 青) ... ;
else if (state == 黄) ... ;
else if (state == 点滅) ... ;
else if (state == 停止) ... ;
と分岐を追加していけばいいよね。

後者のスレッドを用いる場合だとどう修正するの？
結局、似たような感じになっていく気がするんだけど。

147 ：名前は開発中のものです。：2008/05/25(日) 23:08:03 ID:jMUik1Ya

>>125
>イベントドリブンがしたければ別にスレッドでもできるわけで

スレッドとタスクシステム（笑）では想定されている粒度が違う
極端な話、相互作用ありのパーティクルにスレッドなんて使わない
たとえばコンテキストスイッチなんて御大層なサービス要らないでしょ

148 ：名前は開発中のものです。：2008/05/25(日) 23:16:28 ID:jMUik1Ya

>>131
えー。それは疑似タスク（笑）同様に疑似スレッド（笑）でしょ
単語の使い方が変杉。最初からスレッドでなく俺定義の
スレッド（笑）の話ってことを断ってその定義も説明しといてよ

149 ：名前は開発中のものです。：2008/05/25(日) 23:21:39 ID:7UG2hamH

>>148
まあ、それはわかってるからいちいちこだわんなよ
わかってないのお前ぐらいだってｗ

150 ：名前は開発中のものです。：2008/05/25(日) 23:25:47 ID:jMUik1Ya

携帯端末でテケトーに流し読みレスしてっから
会話の全体像は見えてないよ！俺は！

151 ：名前は開発中のものです。：2008/05/25(日) 23:27:07 ID:6V9YbMCv

>>146
がんがん追加してください
追加するほどスレッドを使った方がいいじゃないかと思えてきます
Stateを用いると文の上下の意味的なつながりがなくなるため
規模が大きくなるほどコードが分散して理解するのが困難になります

while (true)
{
if (通常)
{
赤(); sleep(?);
青(); sleep(?);
黄(); sleep(?);
}
else // 真夜中
{
点滅(); sleep(?);
}
}

void 緊急停止()
{
スレッドに対して停止命令();
}

152 ：名前は開発中のものです。：2008/05/25(日) 23:27:28 ID:4NW3nz0D

てかくだんね

153 ：名前は開発中のものです。：2008/05/25(日) 23:29:42 ID:jMUik1Ya

そもそもタスク（笑）とマイクロスレッドの明白な相違点て何よ
例えばコンテキストスイッチ付いてるとタスク（笑）じゃないっていうなら
おまいらのいうタスク（笑）ってどういうタスク（笑）なの
Logician Lordのタスクか？

154 ：名前は開発中のものです。：2008/05/25(日) 23:59:22 ID:vQVRM4Hf

俺の考えなしな書き込みのせいで、
タスクとコルーチンが対立項として扱われてる感じで、なんかゴメン
今までの流れから自分がどっちに行きたいのか整理してみると、こんな感じ

・タスク（あるいはオブジェクト指向による代替タスク）は有用だ。それはもちろん
・ただし、イベントドリブン主体であることには欠点もある。>>130のような負担ね
・コルーチンを併用すればそれを補えるかも知れない

例えばもし次のような実装が手元にあって、簡単にイベントドリブンとコルーチンを
使い分けられるなら、早く仕事がこなせる方をケースバイケースで選びたいよね

class Task {
public:
　　//サブクラスでonFrameTimer()をインプリメントすると毎フレームコールバック処理が行えます
　　virtual void onFrameTimer() {}

　　//サブクラスでcoroMain()をインプリメントすると関数がコルーチンとして起動されます
　　//yield()でメインルーチンへ処理が戻り、次フレームで再開（resume）、を繰り返します
　　virtual void coroMain() {}
}

実際にこんなC++実装が手元にあれば、みんな使う？

>>151氏あたりは既に使ってそうだけど、俺は使わない、もしくは迷うと思う。
実行コンテキスト切り替えコードは大抵アセンブリで速いけど移植性がないし、
他人に引き継ぎしずらいし（普及してないから）、ノウハウが無ければケアレスミスで簡単にスタックあふれるし。
だけどオールドスタイルのタスクもとてもストレスがたまるんだ

じゃあどうしたい、どうしたらいい、って話を、俺と同じように
現状のタスクに（意識的、または無意識的に）ストレス感じてる人に聞いてみたかったんだ

155 ：名前は開発中のものです。：2008/05/26(月) 00:21:41 ID:UvsW7CAY

タスク（笑）といえばイベントドリブンなのか？
一定のタイムスライスでコンテキストスイッチするものはもはやタスク（笑）ではないのか？

156 ：名前は開発中のものです。：2008/05/26(月) 00:39:42 ID:J4tqU4Kx

>>151
＞がんがん追加してください
じゃあ、もう少し追加してみる。
「殴られたら停止する」を、「殴られたら青→黄→赤の遷移を強制的にひとつ進める」に修正。
「点滅状態からの復帰時、点滅状態に遷移する直前の状態に戻す」を追加。
class 信号 {
　enum State { 赤, 青, 黄, 点滅 };
　State state, oldState;
　void 実行() {
　　switch (state) {
　　　case 赤: 赤処理(); break;
　　　case 青: 青処理(); break;
　　　case 黄: 黄処理(); break;
　　　case 点滅: 点滅処理(); break;
　　}
　}
　void 殴る() {
　　if (state == 赤) state = 青;
　　else if (state == 青) state = 黄;
　　else if (state == 黄) state = 赤;
　}
　void 夜になる() { oldState = state; state = 点滅; }
　void 朝になる() { state = oldState; }
};
＞Stateを用いると文の上下の意味的なつながりがなくなるため
＞規模が大きくなるほどコードが分散して理解するのが困難になります
ところで、この部分が何を言ってるのか良く分からないんだけど、もう少し説明してくれない？
関数が長くなるから読みにくくなるってことじゃないよね？

>>154
前にも書いたけど、そういうのは同じレベルで実装しないで、
コルーチンを使いたい部分をスクリプトで実装するのが良いと思う。

157 ：名前は開発中のものです。：2008/05/26(月) 00:56:08 ID:FFo0It8G

あんたらいちいち相手を挑発しなきゃ議論できねーのかｗ

158 ：名前は開発中のものです。：2008/05/26(月) 01:19:18 ID:lNPZHMUK

>>156
ひどいやつだなw
Pythonのジェネレータ関数風味で

色 foo() {
　while (true) {
　　yield 赤;
　　if (夜) {
　　　yield 点滅;
　　　yield 赤;
　　}
　　yield 青;
　　if (夜) {
　　　yield 点滅;
　　　yield 青;
　　}
　　yield 黄;
　　if (夜) {
　　　yield 点滅;
　　　yield 黄;
　　}
}
}
void 殴る() { foo(); }

処理の前後に何が処理されているのかというのは
スレッドなら前後の文を見ればすむ。
stateで管理するとstateの変化を追って確認しなければならないから
前後の流れを読むのが難しい。
gotoのスパゲッティコードのデメリットと同じようなもの。
分けてすぎたせいで、逆に可読性が失われている。

159 ：名前は開発中のものです。：2008/05/26(月) 01:25:20 ID:onffbclF

coroutine的なことやってるのはスクリプト上だから移植うんぬんの悩みはないな
かといってオールマイティなのかといえばそーでもなく
時間経過に連続的に対応するような流れのもんは、要するにsleepをする必要のないものは
逆にcoroutineしないほうがきれい

>>156のように二通り選べるようにするのは理想的なのかもしれないが
大体ある特定の現象群を表現する分にはどっちか片方で十分だったりする

160 ：名前は開発中のものです。：2008/05/26(月) 01:37:09 ID:lNPZHMUK

>>159
>時間経過に連続的に対応するような流れのもんは、要するにsleepをする必要のないものは
>逆にcoroutineしないほうがきれい
無理やりタスクシステムとやらのメリットを作ろうとしても無駄
タスクシステムとやら、つまりStateのメリットは拡張性にある
そのため可読性をかなり犠牲にしている
普通に書けばcoroutineの方が可読性が高い場合が多い、俺の主観では

161 ：名前は開発中のものです。：2008/05/26(月) 02:05:33 ID:02TzkeDh

>>154
少し前の俺を見ているようだ。

>>116,130はコルーチンを使えば時系列に沿った行動の記述が簡単になる、という主張でいいんだよな？
それを踏まえるが、時系列に沿った記述をするコルーチン内では
外的要因による状態遷移を行おうとすると複雑になる、というのは気づいているかな。

yield() する前に毎回状態をチェックしてもいいんだが、チェックする内容によっては
スタックが溢れかねないし。

タスクで状態を監視＆管理しながら、コルーチンなりスクリプトなりで記述された行動を呼び出して、
両方の良いとこ取りをするのがいいと思うな。外的要因による行動の差し替えはタスクから行う、と。
俺はそうしてるよ。

162 ：名前は開発中のものです。：2008/05/26(月) 02:29:45 ID:J4tqU4Kx

>>158
夜間に殴りつづけたときの動作がおかしくない？

＞stateで管理するとstateの変化を追って確認しなければならないから
＞前後の流れを読むのが難しい。
そういう面は確かにある。けど、通常の流れはstateを順番に
見ていけばいいので、それほど複雑にはならないと思うし、
特殊な処理を通常の流れとは分けて書けるメリットがある。
>>158みたいなやり方だと、一部分を見たときに前後の流れは直線的に理解できるけど、
通常の流れ(この場合だと夜=falseの場合)が読みにくくならないか？

163 ：名前は開発中のものです。：2008/05/26(月) 02:33:43 ID:lNPZHMUK

タスクシステムとやらを使うメリットを誰も言えない
でも、タスクシステム信者としては黙ってられない

目を覚ませ
高いレベルでCommand利用を前提としたロジックを実装すると
他の有益なパターンが使いづらくなる
わざわざ、自分で制限をかけてプログラムを書いて
なんの修行をしているんだってのw

164 ：名前は開発中のものです。：2008/05/26(月) 02:51:26 ID:lNPZHMUK

>>162
君こそ通常時の遷移が抜けてるぜw

状態遷移図書いたらわかるけど、このケースだと状態が
赤、黄、青、赤点滅、黄点滅、青点滅の六つ必要になってる
俺は状態遷移そのものが複雑なだけと見てるから
その割には単純になったと思ってる

どっちを選択しても複雑なんだから
StateをCommandとしてListに突っ込んでさらに複雑にするのは
バカげていると思わないかい?

165 ：名前は開発中のものです。：2008/05/26(月) 03:18:22 ID:j2qTftQO

どーでもいいじゃん

166 ：名前は開発中のものです。：2008/05/26(月) 03:53:53 ID:J4tqU4Kx

あー、ごめん。「点滅」は色とは関係ないつもりだった。実際は黄色か赤だろうけど。
つまり、State は４つで、夜間は殴ってもなにも起きなくていい。
つか、自分で仕様変更して自分でソース書いてるんだから、
「状態の数が違う」みたいな豪快なバグは入れないよ。
でも、状態が６つだとしても、>>158 はおかしいだろ。
夜間に殴りつづけると、点滅→赤→青→点滅……と変わっていくんじゃないの？

通常時の遷移はわざわざ書く必要もないだろうし、改行が多すぎて拒否されたんで省いたけど、
その部分だけ書くと、こんな感じかな。
class 信号 {
　static const int 赤時間;
　static const int 黄時間;
　static const int 青時間;
　int timer;
　void SetState(State state) { this->state = state; timer = 0; }
　void 赤処理() { if (++timer >= 赤時間) SetState(青); }
　void 黄処理() { if (++timer >= 黄時間) SetState(赤); }
　void 青処理() { if (++timer >= 青時間) SetState(黄); }
};

＞StateをCommandとしてListに突っ込んで
というのが分からんのだが、List に突っ込むのは
タスク (この場合は信号オブジェクト) であって、State じゃないだろ。
状態ごとの処理は各タスク内で完結してるんだから、さらに複雑にはならんよ。

167 ：名前は開発中のものです。：2008/05/26(月) 05:18:08 ID:lNPZHMUK

>>166
俺の書き方が悪かった、二択だ
ひとつめ
赤、青、黄、赤の裏の点滅、青の裏の点滅、黄の裏の点滅
ふたつめ
赤、青、黄、点滅
このどちらかが状態のリストになる
コードは前者であると仮定してシンプルに書いた、点滅は書き損じ
それとも、状態遷移の状態も作るというのなら、俺はパス

168 ：名前は開発中のものです。：2008/05/26(月) 05:33:57 ID:lNPZHMUK

赤、青、黄、赤の裏の点滅、青の裏の点滅、黄の裏の点滅
ならば
遷移が発生するイベントは時間経過(通常)と殴ると時間経過(例外)

赤、青、黄、点滅
ならば
遷移が発生するイベントは時間経過(通常)と殴ると時間経過(例外)
さらに、時間経過(例外)から入力された三つの値、赤から、青から、黄からのイベント
時間経過(例外時)に入力が発生する

169 ：名前は開発中のものです。：2008/05/26(月) 12:34:03 ID:J4tqU4Kx

よくわからん。「状態遷移の状態」を作るってどういう意味？
あと、普通に色が変わる場合の「時間」は誰がどこで設定するの？
他のオブジェクトから信号の色を知りたい場合にどうするのかも気になる。
結局、>>158 のスクリプトとは別のところで信号の状態を管理することになるんじゃないの？

170 ：名前は開発中のものです。：2008/05/26(月) 15:51:02 ID:lNPZHMUK

状態のネストというらしい、俺はその辺は詳しくない
最初に適当に書いた俺が悪かった

enum { RED, BLUE, YELLOW } color;
void timeout()
{
　if (color == RED) color = BLUE;
　else if (color == BLUE) color = YELLOW;
　else if (color == YELLOW) color = RED;
}

enum { RED, BLUE, YELLOW } color;
void coroutine()
{
　while (true)
　{
　　color = RED;
　　yield;
　　color = BLUE;
　　yield;
　　color = YELLOW;
　　yield;
　}
}
void timeout() { yield; }

171 ：名前は開発中のものです。：2008/05/26(月) 16:04:14 ID:lNPZHMUK

INIT状態で点滅、resetでINITに遷移
殴るはtimeoutと同じ意味だから必要ないよな

enum { RED, BLUE, YELLOW, INIT } color;
void timeout()
{
　if (color == INIT) color = RED;
　else if (color == RED) color = BLUE;
　else if (color == BLUE) color = YELLOW;
　else if (color == YELLOW) color = RED;
}
void reset() { color = INIT; }

enum { RED, BLUE, YELLOW, INIT } color;
void coroutine()
{
　color = INIT;
　yield;
　while (true)
　{
　　color = RED;
　　yield;
　　color = BLUE;
　　yield;
　　color = YELLOW;
　　yield;
　}
}
void timeout() { yield; }
void reset() { コルーチンリスタート(); }

172 ：名前は開発中のものです。：2008/05/26(月) 20:50:15 ID:pgU86LI0

あれ、こんなスレあったんだ。

何年かゲームプログラム(非プロ)やってるけど、
この周りはどうしても複雑になるよね。以下この辺の処理の個人的感想。
・(いわゆる)タスクシステム
　関数ポインタでジャンプやらStateパターン、Strategyパターンなど。
はまってた頃は多用したのだが、今ではシーンの遷移にしか使わない・・・
敵やら弾とかの状態遷移はif文分岐で困らん。
いわゆるUpdateやRenderの中でif文分岐の方が読みやすいよ。。。

・コルーチン、ファイバ、マイクロスレッド
エフェクトやら敵の動きのような処理を外だししたときに
スクリプト内で使うのみ。
組み込まれていない言語(C++とか)では使わない。

・スレッド
メイン、BGM再生、データ読み込み以外は不要。
デバッグ用のログ出力ウィンドウとか作成したときは別スレッドにする。
1キャラクタ1スレッドとかやった人いるのだろうか？
スレッドでつくると、スレッド生成時にそのスレッドのための
スタック領域(デフォルトだと1スレッドにつき、512kBだか1MBだっけ？)が必要ですよね。
もちろんサイズ変更はできるけど、少なくしてスタックオーバーフローで落ちる
限界を見極めるとか面倒すぎる気がする。

173 ：名前は開発中のものです。：2008/05/26(月) 21:45:04 ID:QJtuJBIN

>・コルーチン、ファイバ、マイクロスレッド
>エフェクトやら敵の動きのような処理を外だししたときに
>スクリプト内で使うのみ。

なるほど、そういう使い分けなのね

>組み込まれていない言語(C++とか)では使わない。

継続やコルーチン的なことがやりにくいから？
可能ならやる？

174 ：名前は開発中のものです。：2008/05/27(火) 00:01:22 ID:cvXssXEI

>継続やコルーチン的なことがやりにくいから？
>可能ならやる？
可能ならやるというか
その言語の通常の仕組みで記述できる範囲なら使います。
ただC++で書く場合なら、このスレでいうタスク(敵とか弾とか)のようなのは
外部ファイルに出します。

あと組み込みでない言語を細工してコルーチンを実装するのと
元々実装してある言語では、できることの範囲に差があるように思えます。
例えばコルーチンはコルーチン自体を入れ子にできると
便利ですよね。説明しづらいですが
エフェクト作成関数
{
　coroutine エフェクトメイン
　{
　　coroutine エフェクト座標操作{...}
　　coroutine エフェクト描画元画像位置操作{...}

　　エフェクト座標操作コルーチン起動
　　エフェクト描画元画像位置操作コルーチン起動
　}
　エフェクトメインコルーチン起動
}
のような感じで、関数やコルーチンの内側に次々と子の関数やコルーチンを生成できるようなの。
C++には内部関数すらないのでこういったのは難しいです。
(関数内に構造体を宣言して内部関数みたいなのはつくれますが
外部のローカル変数にはアクセスできない)

175 ：名前は開発中のものです。：2008/05/27(火) 00:38:38 ID:5lsjU+J+

コルーチン的なことはスクリプトでやると言う人がちらほらいるね。
何を使ってるんだろう。
Lua？　Squirrel？　それとも独自実装スクリプトなのかな

>>173
>継続やコルーチン的なことがやりにくいから？
>可能ならやる？

C言語上のコルーチンは環境に左右されやすすぎない？

たとえば、ゲームプログラマが多分いま一番関わることが多いだろうDSで
C言語上のコルーチンを実装したとしても、
DSでは通常スタック領域をDTCMという高速メモリに割り当てているにも関わらず、
コルーチン呼び出し中はスタック領域をメインメモリ上に持っていくことになってしまい、
ローカル変数アクセスや関数呼び出しはガクンと遅くなると考えられる。

※以上のDSの話は以下の記載を根拠にした
ttp://meraman.dip.jp/index.php?NDS_Chap11

176 ：名前は開発中のものです。：2008/05/27(火) 08:13:36 ID:tDqFmLHm

>>175
俺は独自実装スクリプト。lua だと、ちょっとスクリプタが辛そうだったんで。

177 ：名前は開発中のものです。：2008/05/28(水) 20:41:16 ID:2pIaJOU5

>>172
ちょっとまって
横文字書いて満足しちゃってそうだから突っ込むけど
そのどれも>>111にあるみたいな
オブジェクト同士が絡むときの処理の何かを解決するの？

意味ねぇっていってんじゃん
わざわざそんな複雑にしていったい何がやりたいのか意味不明

ちょっとオナニー入ってない？

っていうのはね
なんか聞きなれない言葉多いじゃない？
そういうの複数人で開発するときやこういう掲示板で情報を共有しようってときに
すごく邪魔なのよホント

178 ：名前は開発中のものです。：2008/05/28(水) 20:47:29 ID:DREncIEi

>>177
turemasuka

179 ：名前は開発中のものです。：2008/05/28(水) 20:50:08 ID:2pIaJOU5

>>178
アフォ？
そんな部分どう組んだって完成すんだよ
問題はオブジェクト同士がかかわったときの管理をいかにうまく管理するかだ
そこに技術使わないで一体どこに技術を使うというのか？
逆にそれ以外好きにしろよｗ

180 ：名前は開発中のものです。：2008/05/28(水) 20:54:51 ID:DREncIEi

タスクシステムのスレでそんなこといわれてもな。

181 ：名前は開発中のものです。：2008/05/28(水) 21:18:38 ID:DREncIEi

>問題はオブジェクト同士がかかわったときの管理をいかにうまく管理するかだ
>そこに技術使わないで一体どこに技術を使うというのか？
ここについて話したい素直にそう書けばいいことでは。

182 ：名前は開発中のものです。：2008/05/28(水) 22:37:27 ID:UT4Zgemv

これがいわゆるツンデレってやつかい？

183 ：名前は開発中のものです。：2008/05/28(水) 23:55:23 ID:shc+nb/z

>>177
いったいどれが聞きなれない言葉？
ゲームプログラム特有の言葉は
＞タスクシステム、いわゆるUpdateやRender、エフェクト、1キャラクタ、シーンの遷移、敵やら弾
くらいで、他はプログラムかじってたら知っていそうな用語ばかりだと思う。
と思ったが、かじってる言語によるわな。
スレッドのスタック領域ってなんですか？　ってなってもおかしくないし、問題があるわけでもない。

>問題はオブジェクト同士がかかわったときの管理をいかにうまく管理
ここは同意。整然とかけない。

184 ：名前は開発中のものです。：2008/05/28(水) 23:57:06 ID:Uls7k781

>>177が言ってる横文字って、デザインパターンのことじゃね？

デザインパターンは、プログラマ同士の簡潔な意思疎通に
役立つというのが利点のひとつだと思うけど、
デザインパターン自体が分かってもらえない場合は逆に混乱をまねく。
ゲーム業界にはデザパタは明らかに普及してないから、
>>117のような多分古株のプログラマから反発があるのは仕方ないかと・・・。

まあ、俺は>>172の味方だけどなｗ

185 ：名前は開発中のものです。：2008/05/29(木) 00:35:39 ID:b9433K2i

タスクの勉強するにあたってのお薦めの書籍はありませんか？

186 ：名前は開発中のものです。：2008/05/29(木) 00:53:27 ID:XHqPrNQg

「勉強」するほどのものなのだろうかといつも思うんですが……。
普通に思ったままC++で組んでみれば？

187 ：名前は開発中のものです。：2008/05/29(木) 00:59:34 ID:syTZfubz

>>185
古典的なタスクを勉強したいのですか？
なんのために？？？

C++が使えない場合や、メモリ管理がシビアな場合、
技術レベルが一定しない複数人数でコーディングする場合などは、
管理構造体のリストor配列で手軽に管理できる（つまり、作りが単純な）タスクは
確かに役に立つけれど・・・。
Windowsでプログラムするならもっと色んな良いやり方があると思う。

タスクを解説した本って見たことないんだよなー。
ネットの情報の方がまとまってるんじゃないかな。
仕事で必要ってのなら、現場でソースを見て覚えるのが一番かと（そもそも、会社によって作りが全然違うし）。

188 ：名前は開発中のものです。：2008/05/29(木) 01:49:18 ID:DnMQ76l7

ゲームのためのタスクシステム：C MAGAZINE 2004年12月号特別記事
ttp://cgi32.plala.or.jp/higpen/sIssue/tasksystem.shtml

書籍というとこれぐらいか。
今でもCマガのバックナンバー買えるのかどうか知らんが
わざわざ買うようなもんでもないと思う。

189 ：名前は開発中のものです。：2008/05/29(木) 01:52:42 ID:cLzPDmvQ

つ>>7-8

190 ：名前は開発中のものです。：2008/05/31(土) 21:32:30 ID:O6vPsevd

流れで記述するための擬似コルーチン（？）マクロ
ちゃんと時間があるならスクリプトを組み込むなりすべきと思うが
そういうことができない場合もある

#define BEGIN　　　　　int pg_cnt__ = 0
#define END　　　　　　 ++work->pg_cnt
#define DO　　　　　　　if (pg_cnt__++ == work->pg_cnt)
#define LABEL(x)　　　pg_cnt = x
#define GOTO(x)　　　 do { work->pg_cnt = x-1; return; } while (0)

void task_handler(TASK_WORK* work)
{
　　BEGIN;
　　DO printf("１フレーム目\n");
　　DO {
　　　　printf("２フレーム目");
　　　　GOTO( 100 );
　　}
LABEL( 100 );
　　DO printf("３，５，７，９…フレーム目\n");
　　DO {
　　　　printf("４、６，８，１０…フレーム目\n");
　　　　GOTO( 100 );
　　}
　　END;
}

他にこういうのもある>http://www.sics.se/~adam/pt/index.html
なんにしろコルーチン不要論は理解できないです

191 ：名前は開発中のものです。：2008/05/31(土) 21:57:25 ID:+aan3boX

>>190
何がいいたいのかわからない
オブジェクトとオブジェクトが関わるところ以外は好きに組めばいいじゃん

俺等が知りたいのはオブジェクトAがステータス１の状態で
オブジェクトBがステータス２の状態のときに
この２つの物体が接触したときのそれぞれのステータスの変化
やそのときに生じるイベントの管理の方法なわけよ

ここさえ綺麗に管理できるってんなら他は何しててもいいよ

以上

何書いてあるか正直読んでないけど
これを解決できるものなの？>>190の内容は・・・

だいたいね、君が管理していい気になってるところなんて
管理できなかったゲームはないのよ
既存部分をちょっと自分流に書き換えていい気になってんでしょ？邪魔邪魔（笑）

192 ：名前は開発中のものです。：2008/05/31(土) 22:06:22 ID:O6vPsevd

うーん、気を悪くしてほしくないんだけど
>>191のテーマだって管理できなかったゲームはないと思うんだが・・・

つかね、>>191のテーマは別の議題として議論する価値はあると思うし
ちゃんと議題としてまとめてもらえれば、俺も参加させてもらうよ

俺は最近のゲーム業界ではむしろ演出面での要求の負担が大きくなってるから
演出をいかに効率的に実装するかを（特にタスクとの併用において）考えたいって言ってるんだ

193 ：名前は開発中のものです。：2008/05/31(土) 22:32:22 ID:4GhMIZDi

190=110だとするなら最初の話から外れてきているように見える。

191の話題はタスクシステムの範疇を超えて設計全般に及びそうだから
↓のスレの方がふさわしいと思う。

ゲームにおけるデータ構造・クラス設計・パターン2
http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/

194 ：名前は開発中のものです。：2008/05/31(土) 22:44:52 ID:+aan3boX

タスクってなんのためにタスクにするのか最早意味不明なんだよな
なんでもタスクにすると今度は当たり判定の優先順序の管理のが面倒になって意味がねぇ
ここはプライオリティなんて変数作って番号で管理なんかするより
ソースに直接記述したほうがわかりやすくていい
そもそも状況によって処理順序が変わることがあるんだろうか？

って考えるとタスクも意味がねぇよな

195 ：名前は開発中のものです。：2008/05/31(土) 22:52:05 ID:twk4PUSn

外れるように話を広げたのはタスクシステム信者だろ
タスクシステムのメリットを言える奴は誰もいない
拡張性がいいとほざく奴がいるけど、代わりに複雑性を内包する必要が出る
さらに、影響が広範囲に及ぶため、他の様々な有益なパターン適用の枷となる
しかも、これを使えば万能みたいな説が流れているせいで初心者が勘違いして使って
無駄に複雑なコードを書いて自滅する
使う理由は「あんなすごいひとが使っているから」というカルト的理由によるもの
完全に時代遅れのアンチパターンだ
こんなクソパターンは今世紀に入る前に消滅させるべきだった

196 ：名前は開発中のものです。：2008/05/31(土) 23:23:00 ID:D6/N/mJk

おまえ今世紀に入る前に消滅させるべきだったって言ってみたかっただけやろ

197 ：名前は開発中のものです。：2008/05/31(土) 23:34:14 ID:O6vPsevd

>>193
外れてきてますね・・・。最初はただの愚痴だったｗ
まあでもせっかく人が集まってるみたいだし、なんかタスク絡みのいろいろを情報交換したいな

>>194-195
アンチパターンかー。過激だが、そうかもなあ

俺は、タスクは（名前の通り）継続的な処理を示すんだと解釈してるんだが
それを、それ以外の状態を持った何かに拡張させようとするから混乱するんじゃまいか
たとえばタスクとスプライトは、俺は別の扱いにすべきだと思う

198 ：名前は開発中のものです。：2008/05/31(土) 23:43:37 ID:O6vPsevd

MVC設計でいうと、スプライトが車だとすれば
タスク=Contoroller
スプライト=View
車の車種やスピード管理クラス=Model
かな

199 ：名前は開発中のものです。：2008/05/31(土) 23:51:05 ID:rHVvUvBq

>>195
タスクシステムって、制御構造を動的かつ柔軟に変更出来るところがメリットでしょ。
コード片を一つのオブジェクトとして使えるというのはアンチパターンなんかじゃなく、
柔軟なプログラミングを行ううえでの重要なパターンに違いないと思うけどな。

>>194
表示順位なんかはころころ変わるでしょ。斜め上方からの視点な2Dゲームとか。
また例えば、BがAというオブジェクトの相対位置に固定されるように
動的に処理の切り替えを行いたいとして、Aが毎フレーム自由に移動している場合、
Bは必ずAの移動処理の後に位置を決定しなければならない。
でないと1フレーム分位置がずれてしまうから。(そういうゲームあるよね・・)
これは１タスクを表すオブジェクトに、事前に完了しているべきタスクへの参照情報を保持させれば
スマートに実装出来ると思う。(デッドロック的な状況に陥る可能性がふと頭を過ったのは内緒･･)
もしこれがハードコーディングでB->Aという処理順序で固定されてしまっていたら
フラグなどを使った面倒くさい制御なんかが増えて可読性が良くないと思うんだよね。

200 ：名前は開発中のものです。：2008/06/01(日) 00:09:34 ID:26Sl1TFL

要するに汎用性を追及したい病、ハードコーディング気持ち悪い病でしょ。プログラマのかかる罠。
ゲームのオブジェクト管理の場合、中途半端に成功しそうに見えるのがまた手に負えないところだ。

201 ：名前は開発中のものです。：2008/06/01(日) 00:53:17 ID:DrvtIKA9

そうそう、どの方向に拡張したいかを考えずに
どの方向にも拡張したいと考えるからおかしくなる

それと、ノベルゲーみたいなものでは割とうまくいきそうな
PAC(プチPAC)を、他のゲームでもうまくいくだろうと考えるのはおかしい
PACはエージェント同士の関係が複雑にならないものや
単純なルールのゲームでしか使い物にならない

202 ：名前は開発中のものです。：2008/06/01(日) 01:02:29 ID:DrvtIKA9

>>199
おまえが何もわかっていないということはよくわかった
変更と追加はまったく違う
CommandやStateのメリットですらない

有益なんだったら、外国に布教してきなよ
鼻水流して感謝されるぜw

203 ：名前は開発中のものです。：2008/06/01(日) 01:44:46 ID://w8HXJr

一応補足しとく
>>201の言うPACとは（Presentation, Abstract, Controller）の略で、MVCに近い手法らしい

んで、PACは俺は知らないんだけど、大体MVCのようなものとして聞くけど、
PACが単純なルールにしか適用できないと考えるのはなぜ？

俺はむしろ、単純なルールならMVCやらPACみたく、わざわざ構造を分離させない
>>199の言うような、複雑で動的なルールに対応するために
そういう設計手法があるんじゃないのか？

204 ：名前は開発中のものです。：2008/06/01(日) 01:46:29 ID:37mn39Y5

厨房だらけの掲示板でさえ
Singletonとか言い出す奴にはグローバル変数で十分じゃいと返され
MVCとか言い出す奴にはおまえV複数つくる気あるんかいと返される
そんな海外
合理的だ

205 ：名前は開発中のものです。：2008/06/01(日) 01:55:03 ID://w8HXJr

>>201
あ、ごめん。PACはツリー構造なんだな。MVCとはだいぶ違うっぽい
PACの何を批判してるのか俺は理解してないようなので>>203はスルーしてくれ

206 ：名前は開発中のものです。：2008/06/01(日) 08:00:05 ID:A9oINGs6

>>195
＞拡張性がいいとほざく奴がいるけど、代わりに複雑性を内包する必要が出る
＞さらに、影響が広範囲に及ぶため、他の様々な有益なパターン適用の枷となる
「複雑性を内包」とはどういうことか？
なぜ「影響が広範囲に及ぶ」のか？
どのようなパターン適用の枷となるのか？

この辺をちゃんと説明してよ。
それこそ「初心者が勘違いして使って無駄に複雑なコードを書い」た結果なんじゃないの？

207 ：名前は開発中のものです。：2008/06/01(日) 09:03:00 ID:rH1ss0D0

>>206
そんなのわかんないのお前だけだよ
もうね、そういう議論に勝つための質問はもうおなかいっぱいなんだ

208 ：名前は開発中のものです。：2008/06/01(日) 16:10:22 ID:A9oINGs6

いや、勝ち負けじゃなくてさ。
純粋に、「タスクシステムだと適用できない、有益なパターン」てのを知りたいんだけど。
その「有益なパターン」が本当に「タスクシステムのせい」で使えないのだとすれば、
曖昧にしておく意味はないと思うんだけど。それこそ、君の「勝利」のためにも。

つか、「自分に質問／反論する奴はすべてタスクシステム信者」と思ってるみたいだけど、
俺はタスクシステム、非タスクシステムどちらも経験していて、
複雑さに関しては「どっちでも特に変わらない」と思ってるんだよね。
とすると、「タスクシステムだと適用できない、有益なパターン」が鍵を握ってそうじゃん。

209 ：名前は開発中のものです。：2008/06/01(日) 16:25:17 ID:uh0F8OUP

>>199
＞表示順位なんかはころころ変わるでしょ。斜め上方からの視点な2Dゲームとか。

それ要するに深度値（Z）ソートだよね。で、半透明なしは深度バッファ任せとか。そういう話でしょ。
たすくしすてむ？プライオリティ？なになにー？みたいな。そんな単語が出る幕あるか？

＞また例えば、BがAというオブジェクトの相対位置に固定されるように
＞動的に処理の切り替えを行いたいとして、Aが毎フレーム自由に移動している場合、
＞Bは必ずAの移動処理の後に位置を決定しなければならない。
＞でないと1フレーム分位置がずれてしまうから。(そういうゲームあるよね・・)

それ要するに親子関係でしょ。ペアレントするとか骨を入れるとか。そういう話でしょ。
モノ同士の依存関係を表すために、なんで線形リスト（？）の要素内にプライオリティ
という変数があってー、みたいな話になるのかわかんね

210 ：名前は開発中のものです。：2008/06/01(日) 16:29:37 ID:uh0F8OUP

あとこれ偏見かもしらんけど、端から2D前提で話をする人には2通りいる気がする

①2D3Dを一般化して同じ土俵で語れる。話の便宜上（簡易化のため）2Dで語ってるだけの人間。
②3Dが苦手。2D全盛時代の貧弱ハード＆開発環境下に苦し紛れに生み出された貧乏テクを
　その生まれた背景や導出過程を理解することなく天下り的に教わり、盲信し、呪縛されてる。

で、タスクシステム狂信者って圧倒的に後者が多いでしょ。老いも若きも。
この手合いは、表示上の縛り（2D、クォータービュー疑似3D）が発想の縛りにすら
なってしまっていて、とにかく何でもかんでも一個の線形リストにぶち込んで
とにかく巡回巡回巡回、僕のforeach！リスト巡回UPDATE最高！以外に脳がない

211 ：名前は開発中のものです。：2008/06/01(日) 17:29:17 ID:uh0F8OUP

松浦尊師のナンチャッテタスクシステム教団に入信し洗礼を施され
タスクシステムこそ絶対にして至高、時空を超越した普遍の真理と
信じて疑わないこの恐るべき子供達は、経典に記述された線形リストと
その要素内にあるプライオリティという変数に固執し、それをもって
深度による前後関係や物体同士の親子関係を表現させようと試みる。
その様はもはやカルト。不合理の極みだが、彼らは経典に従わねば
仏罰が下ると盲信しているので家族による奪還は難しい。

彼らは粗末なバラック小屋に無理やり機能拡張を試み増改築魔改造
を繰り返しついには九龍城みたいなよくわからないものを築き上げ
その偉容にホルホルするのだが、いざ使ってみればただのグロテスクな
汚物だと気付き、世を穿かなんで配列厨になることだろう

212 ：名前は開発中のものです。：2008/06/01(日) 17:40:18 ID:PJD7oyGT

君のおかげでタスク教から目が覚めたよ
だから単純明快で使いやすい代替システムをまとめた講座サイトを作ってくれないかな

213 ：名前は開発中のものです。：2008/06/01(日) 17:44:22 ID:zLG7F7W1

毎度必ず、連続投稿の最後にポエムつけてくるよなｗ

214 ：名前は開発中のものです。：2008/06/01(日) 17:47:28 ID:uh0F8OUP

最終解脱者の私はHSPこそ絶対にして至高だと確信する
タマネギ狂信者だが、それでも構わないかね？

215 ：名前は開発中のものです。：2008/06/01(日) 17:49:26 ID:Vobw4BHh

好きにしろ
日本国憲法で宗教の自由は認められている

216 ：名前は開発中のものです。：2008/06/01(日) 17:59:55 ID:K8JTnWL1

>>214
HSPとタスクシステムは直接関係ないからＯＫ

217 ：名前は開発中のものです。：2008/06/01(日) 19:12:10 ID://w8HXJr

なにこの流れｗ
「タスクシステム信者」なんて都市伝説ですよ

>>212
>単純明快で使いやすい代替システムをまとめた講座サイトを作ってくれないかな
他人任せなのはどうかと思うが、「単純明快で使いやすい代替システム」については同意です
ここがその提案の場で良いのでは？

218 ：名前は開発中のものです。：2008/06/01(日) 19:14:10 ID:rH1ss0D0

>>208
だからさー
擬似タスク使う意味がないっての
なんのために擬似タスク使うの？

何が楽になる？
具体的に書いてよ

ぶっちゃけ、なんにも役に立ってないでしょ？

219 ：名前は開発中のものです。：2008/06/01(日) 19:27:29 ID://w8HXJr

>>218はＣ＋＋禁止プロジェクトでゲーム作る時もタスク使わないの？

俺はＣ縛りの場合はタスクは便利だと思うし、
それはつまり、実装（関数ポインタを使うか仮想関数を使うか、構造体を使うかクラスを使うか）は
どうあれ、設計的には一理あるものだと思うんだけども

220 ：名前は開発中のものです。：2008/06/01(日) 19:47:12 ID:nqxXsx94

>>213
私が以前ここでカキコんだのは昨年クリスマス前あたりだから
たぶん人違いだ
「恐るべき子供たち」で検索してヒットすればきっとそれ

221 ：名前は開発中のものです。：2008/06/01(日) 19:51:40 ID:nqxXsx94

あとSTGスレで富豪理論を展開してつまみ出されてるくらいだな
ID違うのは今帰宅中の電車の中だからだ。すまんの。じゃあの

222 ：名前は開発中のものです。：2008/06/01(日) 19:58:03 ID:A9oINGs6

>>218
何度も書いてるだろ。「特に変わらない」って。所詮ただの手段なんだし。
少なくとも、他の手段に比べて特に複雑になったり、「影響が広範囲に及」んだりって
ことはないよ。「タスクごとに記述を分ける」のがタスクシステムなんだから。
あと、俺が使ったのは、「会社で使ってたから」だよ。
言語がC++だから、いわゆる「古典的タスクシステム」とは違うかもしれんが。

いい加減、話を逸らすのはやめて、
タスクシステムだと使えない「有益なパターン」ってのを教えてよ。
なぜ、わざわざ議論を長引かせようとするんだ？

223 ：名前は開発中のものです。：2008/06/01(日) 20:11:10 ID://w8HXJr

>>222
なんか>>218には「タスクを使う人間」に対する強い憎しみを感じるよね・・・
まー会社かなんかで色々あったんだろうけど

「影響が広範囲」ってのは十分にカプセル化されてなかったりが原因だと思うけど、本質的な問題とは思えないなあ
結局運用の問題であって、同じナイフでも使う人間によって役にも立てば凶器にもなる、みたいな

224 ：名前は開発中のものです。：2008/06/01(日) 20:17:47 ID://w8HXJr

あ、もちろん安全鋏でまかなえることは安全鋏を使う方がいいと思う
なんでもできるナイフを全員が持つ時代でないのは確か

225 ：199：2008/06/01(日) 20:59:26 ID:I+z4oIpe

>>202
>変更と追加はまったく違う
>CommandやStateのメリットですらない
ごめん主語つけてくれんと意味分かんない。

>>207
俺も分からんから教えてほしいんだけど。
具体例を示してもらわんと議論し難いしね。
あと218で聞き返す前に自分への問いに答えるべきじゃないの？

>>209-211
Zソートと近いね。リンクリスト構造になっているタスクを使うのは適切でしょ？
また、深度バッファとか210の文を見ると、3D表示での話をしたいのかなと思ったんだけど、
Zバッファ可能な3D描画デバイスではZ値そのものを表示順位として使えるから、
この表示部にわざわざタスクシステムを使う必要は無いけどね。
ただ半透明だとか、内部処理の実行順の制御にはタスクシステムは使えると思う。
3Dだとシーングラフ的な構造に近くなるのかも知れんけど。

あとさ、「要素内のプライオリティ変数」とかいうのを勝手に幻想して毛嫌いしてるのそっちじゃない？

226 ：名前は開発中のものです。：2008/06/01(日) 21:17:24 ID:uTWu7ixX

別に自分の作りたいように作ればいいじゃない

227 ：名前は開発中のものです。：2008/06/01(日) 21:30:53 ID:rH1ss0D0

>>222
なんだよ
じゃ、バグ増やして遊んでるだけかよ
仕事しろよｗ

>>225
あんまり、突っ込みたくないけど
お前のは他の誰とも違うと思うよｗ
なんかズレてる

228 ：名前は開発中のものです。：2008/06/01(日) 21:46:12 ID:DrvtIKA9

議論するのも無駄に思えてきた

ゲーム脳と同じで
論文もなしに根拠のない本を書いて金稼いで
公演開いて金稼いで
信じている連中は考えることを放棄している

それでいいかもな
結晶に話しかけるときれいになるよ
宇宙人と会ったことあるよ
マイナスイオンはすごいよ
ゲルマニウムパワーだよ

229 ：名前は開発中のものです。：2008/06/01(日) 21:52:09 ID:DrvtIKA9

>>225
おまえが3Dを全く理解していなくて
知ってる言葉を並べているだけということはわかった

230 ：名前は開発中のものです。：2008/06/01(日) 21:55:10 ID:rH1ss0D0

>>228
でも、世の中の９３％ぐらいはそんなもんだぞ

論文なんて正しい間違ってるのジャッジなんて
まったく同じ研究をもう一度誰かがやってジャッジするか
頭でシミュでもして擬似的に想像するぐれーしかないんだから

まあ、言ったもん勝ちって面はあるだろうな

231 ：名前は開発中のものです。：2008/06/01(日) 21:59:45 ID:DrvtIKA9

>>230
有害だとわかっているのにうまく説明できない
批判しようとしても悪魔の証明を求められる
しかもシステムの知識が浅い人ばかりなので、まわりくどく説明しなければならない
このもどかしさ、この理不尽さ
でも死滅させないと、信者が増殖してますますおかしなことになる
俺にはもうどうすることもできない
……
……
……

たまにはタスクシステムもいいよね

232 ：名前は開発中のものです。：2008/06/01(日) 22:03:01 ID:rH1ss0D0

>>231
無理でしょ？
どっちが正しいかなんて判断できんの？

233 ：名前は開発中のものです。：2008/06/01(日) 22:24:32 ID:DrvtIKA9

>>232
無理
宇宙人がいるかどうか問われても
いるともいないとも言えない、調べる術がないから
それに宇宙人がいないことを証明しろと言われても無理
だからといって宇宙人は存在するんだといわれても
それは肯定するわけにはいかない
宇宙人の存在を肯定している人が宇宙人を連れてくるべきだと思う

タスクシステムについても同じ
タスクシステムを使うメリットがなんであるのかはっきり言うべきだろう
それがないのに、タスクシステムのメリットがないことの証明を
俺に求めてくるのはフェアじゃない

タスクシステム信者は卑怯者だ

234 ：名前は開発中のものです。：2008/06/01(日) 22:30:29 ID:2ljWYPOW

スレが進んでいるから何かと思ったら…
何ヶ月か毎に似たようなこと繰り返すよね、このスレ。
それにしてもID紅い奴多すぎだろう。

235 ：名前は開発中のものです。：2008/06/01(日) 22:32:09 ID://w8HXJr

rH1ss0D0とDrvtIKA9は同一人物かと思ってたわ
二人ともなんか言ってることが子供っぽいよ

タスクが有害な理由はいくらでも思いつくし、有益な理由もいくつか思いつく
多分、あと１０年もすると中心的な世代が入れ替わり、
欧米的な設計手法ばかりになってタスクは嫌でも消えていくと思う
だから、そんな風に汚い言葉で煽ったり非難する必要なんかない

あなた方が理想論者で世の中を自分の思っている方に変えたいと考えてるのは分かったけど
俺にとっては目の前にタスクを使う先輩方がいるっていう現実が問題であるわけで、
彼らが引退するまで増大し続ける要求に対して古き良きタスクで頑張り続けることは到底不可能だから、
前に進むためには、そうやってただ気持ちよく批判して否定してても仕方ないんよ
どうやって彼らを懐柔して、いかにも「タスクいいっすよねー、使ってますよー」という顔をしながら
実際には本来のタスクとは根本を異にする欧米流の設計手法にすりかえていき、
安全で品質の良いコーディングをしていくかってことが大事なんよ

236 ：名前は開発中のものです。：2008/06/01(日) 22:45:00 ID:sbTmSAWc

>>235
C++禁止とか、先輩には技術的批判ができない空気とか、かわいそうな環境に居るんだね。
そういう環境を変えようとは思わないの？

237 ：名前は開発中のものです。：2008/06/01(日) 22:57:04 ID:DrvtIKA9

タスクという言葉には意味があるのに
タスクシステムという偉そうな名前にして
略してタスクって言ってる、これ自体がおかしい

意味を勝手に再定義して、人を混乱させて何か楽しいのか
消防署の方から来ましたって言って人を騙しているのと同じだろ

そんな奴に子供っぽいとは言われたくないな
カルトを批判することが子供っぽいのなら、いくらでも子供っぽくなってやる

238 ：名前は開発中のものです。：2008/06/01(日) 23:15:28 ID:A9oINGs6

ただ「ダメだ」と言い続けるだけでは「批判」にならんよ。

>>227
で？　「有益なパターン」とやらは、まだ挙げられないの？
もう調べなおす時間は十分あったと思うけど？

>>233
「メリットのないことの証明」なんてする必要ないでしょ。
代替手段のメリットか、タスクシステムのデメリットを説明すればいいだけ。
その「デメリット」をはっきりさせるために質問してるんだけどなぁ。
君でもいいので>>206に答えてよ。

239 ：名前は開発中のものです。：2008/06/01(日) 23:26:32 ID:DrvtIKA9

>>238
もうどうでもいい
散々書いてるのに無視されまくって同じことを何度も書くのもバカらしい
知識を持たない奴と議論しても何も生まれない
タスクの正しい意味もわかってないような奴と対話する必要もない

240 ：名前は開発中のものです。：2008/06/01(日) 23:37:44 ID:DrvtIKA9

半端に容認してやがるカスのせいで
信者が新しく増え続ける弊害
延命する手助けをして自分の首絞めてろ

241 ：名前は開発中のものです。：2008/06/01(日) 23:39:12 ID:6rc2ui2D

捨て台詞入りました

242 ：名前は開発中のものです。：2008/06/01(日) 23:43:59 ID://w8HXJr

>>236
正論ですねｗ
そういう環境を変えるのが一番だと思うし、そういう風にも動いています

ただ、単に今までのやり方をやめさせて新しいものを受け入れさせるっていうのは
傲慢だとも思うんですよねー
のちのち、自分の後輩が、例えば「boost使いたいんですけど」って言ってきた時に
多分自分も「んー、boostは、コンパイル環境に依存するからなあ・・・」とか
「shared_ptrとかbind程度ならいいけど、あまり複雑すぎるのは使わないで」とか
もっともらしい言い訳しながら抵抗すると思うんですよね
それは慣れたやり方を捨てるのが嫌で、知らないものを受け入れるのが怖いから
誰だってそうだと思う。そんな簡単に既存のやり方を否定なんかできないと思う

>>239
タスクの正しい意味がわかってなくてすいませんでしたー

243 ：名前は開発中のものです。：2008/06/01(日) 23:50:57 ID:rH1ss0D0

>>238
お前の議論の仕組みがわからない
俺等にデメリットを出させてそれでどうしようっていうの？
まず、これを答えてくれ
質問内容は「デメリットを出してそれでどうしたいのか？」

なにやらどうしてもあげてほしいみたいだから書いておくけど
こんな感じ↓
・仕組み自体が意味ないし、
・グローバル変数必須になるし
・デバッグのしにくさ、
・インスタンスの把握のしにくさ、
・各オブジェクトの管理のし難さ、
・無駄なプライオリティの管理の必要

追記しておくと、はっきりいってこんなみんなわかってるようなことを
あえて聞くあたりもう議論に勝つためにわざと知らないふりをして
知っていることを相手にいちいち答えさせることでうんざりさせる効果を狙ってるとしか思えないけどね

244 ：名前は開発中のものです。：2008/06/01(日) 23:52:10 ID:Q8YpYrfT

よくわからないのでソースで示してください

245 ：名前は開発中のものです。：2008/06/01(日) 23:52:38 ID:rH1ss0D0

>>244
邪魔　消えろ

246 ：名前は開発中のものです。：2008/06/01(日) 23:59:28 ID:zLG7F7W1

243を見てさっきからニヤニヤしてる

247 ：名前は開発中のものです。：2008/06/02(月) 00:04:43 ID:TfZZ1SZH

俺もニヤニヤしてる。

248 ：名前は開発中のものです。：2008/06/02(月) 00:33:36 ID:cwut3Cbv

タスクシステムを理解できなかったからって醜態をさらすなよ、見苦しい。

249 ：名前は開発中のものです。：2008/06/02(月) 00:43:16 ID:CLd7aMjs

>>238はデメリットをあげてもらってどうしたいのか答えられるのかね？

250 ：名前は開発中のものです。：2008/06/02(月) 00:43:51 ID:Y5ac98mm

>>248
おいおい、本物のタスクシステム信者？

251 ：名前は開発中のものです。：2008/06/02(月) 00:52:30 ID:cwut3Cbv

いんや rH1ss0D0 みててタスクシステム大好きなんだなって思って書いてみただけ。

252 ：名前は開発中のものです。：2008/06/02(月) 00:57:40 ID:tWKX9lA+

>>225
本当に往生際の悪い人だなぁ

＞Zソートと近いね。

「近い」ではなく「そのもの」だろう

＞3Dだとシーングラフ的な構造に近くなるのかも知れんけど

「的」ではなく「そのもの」だろう
タスクシステムの原義(※)に照らせばシーングラフ的思想などない。
強引に解釈して「シーングラフの片鱗が見出せます！」とか
歴史修正主義者みたいな苦しい抵抗は試みるなよ。
シーングラフ的ならそれはもはやタスクシステムと呼べない。
そう認めたほうがきっと気持ちいい

＞「要素内のプライオリティ変数」とかいうのを勝手に幻想して

タスクシステムの原義(※)に照らせばそのような実装になっている。

（※）現在、公の議論の場で出典として使えるまともな一次情報がない。
ギャラクシアンのプログラマがダンマリを決め込んでいるから当然だ。
ギャラクシアンのバイナリイメージをリバースエンジニアリングした
結果は胸のうちに仕舞い込むしかない。公にした違法なのだから
出典として使えない。よって合法的に入手可能な限りなく一次情報に
近い情報を持ち出して、これを原義とするしかなく、俺の知る限りじゃ
Logician Lordのウェブアーカイブがかなりまともだった

253 ：名前は開発中のものです。：2008/06/02(月) 01:02:35 ID:tWKX9lA+

タスクシステムという単語はローカル用語に過ぎない。密教みたいなものだ。
経典が公に明かされてないのを良いことに、玉入れ民族根性丸出しで勝手に捏造修正
拡大解釈再定義増改築魔改造して原型留めない異形のコードを尻からひり出して
それを現代的タスクシステムなどと称し社内で発表会やって悦に浸るのはまぁいい。
それをこのような場に乗り込んで臆面も無くやるからカオスになるのだ。具体的定義や
実装もロクに語らず、オラが村の娘っこが一番めんこい正統派だぁ、いんやオメんとこのは
淫売ドブスだぁオラんとこのがめんこいしウンコもしない清純派だぁ、みたいなアカデミックで
高属性な水掛け論になる。

さゆりすとに言わせればみんな出来悪い紛い物だ

254 ：名前は開発中のものです。：2008/06/02(月) 01:19:16 ID:ZvhvBDDi

>>243
デメリットがはっきり示されていれば、
君らの言う「タスクシステム信者」も減るかもしれないだろ？
使うにしても、デメリットを理解して使うほうがいい。
つか、君は議論とは「相手を言い負かす」ものと思ってるようだけど、
俺は別にどっち派でもないから、勝ち負けはどうでもいいんだよね。

で、挙げてもらったデメリットだけど、巷のタスクシステムの説明を何も考えずに
鵜呑みにして、なんでもかんでもタスクにしようとすれば、確かにそうなり得ると思う。
ただ、グローバル変数は必須にはならないし、
「オブジェクトの管理のし難さ」は元々ゲームプログラミングが内包する問題で、
タスクシステムによって増すものではないと思うけど。
それがタスクシステムそのもののデメリットだと言うなら、
タスクシステム自体が「どのように」影響してそうなるのか説明してくれないと。

んで、タスクシステムだと使えない「有益なパターン」は？
君が言い出したことなんだから、最低限これだけは答えてほしいなぁ。
これだけちゃんと答えてくれれば、議論は君の勝ちでいいよ。

……つか、ここまで書いて思ったが、君に「デメリットを出せ」とは言ってなくないか？
俺は>>233(231)が言うような「悪魔の証明」は必要ない（メリットが「ない」ことの
証明は必要なく、デメリットが「ある」ことを示せば良い）と言ってるだけで、
君にはずっと「有益なパターン」とやらについてしか聞いてない。
それが使えないこと＝タスクシステムのデメリットなんだろ？

255 ：名前は開発中のものです。：2008/06/02(月) 01:35:21 ID:CLd7aMjs

>>254
>デメリットがはっきり示されていれば、
>君らの言う「タスクシステム信者」も減るかもしれないだろ？
ならまずはじめにそれを説明するべきじゃない？
明らかに順序が違うと思わない？
それとまだメリットを説明できてないわけだけど
メリットがないのにデメリットの検証をするの？おかしくない？

>んで、タスクシステムだと使えない「有益なパターン」は？
は？しゃべってる日本語がまったく意味不明なんですけど？
現状、デメリットがでてしまっている部分を解消できたら有益なパターンといえないですかね？
まあ、しっかり例としてあげなきゃ気がすまないっていうならあげちゃいますけど

プライオリティなんて定義しないで直接ソースにならべりゃいいんですよ
現状、数字打って管理するしかないっすよね？
if(){
　if(){
の形で実行の条件が書けないからタスクシステムで正しく動作させようとすると
動的にプライオリティを振りなおす必要がでてくることも多いでしょうよ
当たり判定の実行順序なんかでかなり複雑になるはずです

これをやらないことが有益なパターンですよ

256 ：名前は開発中のものです。：2008/06/02(月) 01:37:15 ID:CLd7aMjs

>>254
>これだけちゃんと答えてくれれば、議論は君の勝ちでいいよ。
じゃ、答えたよ
俺の勝ちだね
敗北宣言だけはしていってほしいなぁ
「私はタスクシステムのメリットを説明できませんでした」
ってちゃんと言ってってよ

257 ：名前は開発中のものです。：2008/06/02(月) 01:45:21 ID:VZyqS9Dw

なんと醜い争いだろうか

258 ：名前は開発中のものです。：2008/06/02(月) 01:50:28 ID:2Kuej5cO

＞んで、タスクシステムだと使えない「有益なパターン」は？
そういう攻め方はもうやめなよ
見苦しい

259 ：名前は開発中のものです。：2008/06/02(月) 01:56:22 ID:Y5ac98mm

こんな言い争い、誰の得にもならねえｗ

タスクシステムに「有益なパターン」を追加することは可能だし、実際に各自やっていることだが
そうやってデメリットを減らしていくと最終的には今風のモダン設計になる
「原義のタスクシステム」などというものは、すでにどこの現場にも存在しない
「タスクシステム」という名前だけが残って内実は形骸化しているから、いいとか悪いとか言うことが無意味
二人ともこれで満足か

260 ：名前は開発中のものです。：2008/06/02(月) 02:02:05 ID:MtYGqYka

曖昧なスタンスの奴が議論に混ざると話がおかしくなるんだな。
中立だと言うくせにアンチだけにやけに食いついてる。
見ていて気持ち悪いから、黙るかタスクシステム肯定しているのかはっきりしないだろうか。
タスクシステムってのは前から疑問に思ってたけど、
こんな流れじゃタスクシステムについての理解は深まらないんだが。

261 ：名前は開発中のものです。：2008/06/02(月) 02:04:38 ID:CLd7aMjs

いいんだよ
タスクシステム（擬似タスク）はもう滅んだ

262 ：名前は開発中のものです。：2008/06/02(月) 02:50:03 ID:ZvhvBDDi

>>255
たぶん別人だろうけど、一応説明しとく。>>195 >>206 を読んでくれ。
タスクシステムの影響が広範囲に及ぶために、他の様々な有益なパターン適用の枷になる
というのなら、
タスクシステムを使わないことによって使える、様々な有益なパターンがある
ってことだろ？　それはどんなパターンなのかってのを、俺はずっと聞いてるんだけど。
>>195 と >>207 が別人というならスマンが、
少なくとも >>207 はその「有益なパターン」とやらを知ってるわけだろ？

>>259
その言い分はまったくもって正論だと思うが、向こうは
「タスクシステムに「有益なパターン」を追加することは可能」というのを否定してるんだよ。

>>260
スマンね。別に中立と言うわけじゃない。前から言ってる通り、俺の立場は「どっちでもいい」
なので、「タスクシステム」VS「非タスクシステム」であれば、中立の立場を取るが、
「タスクシステム肯定」VS「タスクシステム否定」なら、アンチの言い分をはっきりさせたい。
IDで調べてもらえば分かると思うけど、俺は「タスクシステムだと使えない、有益なパターン」
が知りたいだけなんだよ。それさえ教えてもらえば黙るよ。

263 ：名前は開発中のものです。：2008/06/02(月) 04:20:41 ID:2Kuej5cO

>>262
相手には答えない自由があることを認めよう
＞それさえ教えてもらえば黙るよ。
ならもう「使えない有益なパターンは無い」でいいじゃん終了
言質とってからなんか議論を展開するのかと思ったら黙っちゃうのかよ
がっかりだよ

264 ：名前は開発中のものです。：2008/06/02(月) 05:11:15 ID:NbU9ArOr

だからソースコードをだせと

265 ：名前は開発中のものです。：2008/06/02(月) 07:06:29 ID:CLd7aMjs

>>262
>タスクシステムを使わないことによって使える、様々な有益なパターンがある
現状タスクシステムのデメリットが払拭できるんだからタスクシステムを使わないことが
有益なパターンででいいんじゃねぇの？
ダメな理由を言ってよ

っていうかこれが正しい正しくないはおいておいて
有益なパターンとしてあげたんだからさっさと敗北宣言しろよ

なにもあげたパターンがお前の意にそうものかどうかのジャッジまで
お前は求めてなかったぞ
あげた時点でお前の負けだ

266 ：名前は開発中のものです。：2008/06/02(月) 11:18:09 ID:FVmHkf2I

>>252
スレ違いだけど重要な事だと思うので指摘。

リバースエンジニアリングは違法ではない。
否定も肯定もされていないグレーゾーンにある。
ダンプしたコードをコピーすれば著作権侵害になるが
参考にすることは明確に権利の侵害とはいえない。

それではみなさん愚論の続きをどうぞ↓

267 ：名前は開発中のものです。：2008/06/02(月) 13:17:51 ID:ZvhvBDDi

>>263
本当に、タスクシステムだと使えない有益なパターンがあるのであれば、
「タスクシステムを使うべきではない」あるいは
「使えるパターンに制限があることを考慮して使うべき」で終了。
そうでなければ、そもそも議論の前提が成り立たないのでやっぱり終了。
他のことならともかく、この点についてはこれ以上展開する必要はないよね。

>>265
あれ？　同一人物だったのか。

＞なにもあげたパターンがお前の意にそうものかどうかのジャッジまで
パターンが意に添う必要はないけど、「タスクシステムを使わない」じゃ
そもそも「パターン」になってないじゃん。
パターンというからには一定の「型」が必要だろ。
タスクシステム以外の方法はすべて同じパターンなのか？

まあ、それがパターンであると言い張るのならしょうがない。
確かに、「タスクシステム」を使えば、
「タスクシステムを使わないパターン」は使えないよなぁ。
俺の負けだよ。おめでとう！

268 ：名前は開発中のものです。：2008/06/02(月) 18:05:37 ID:nsmxUAKf

おめでとう

269 ：名前は開発中のものです。：2008/06/02(月) 18:31:33 ID:tWKX9lA+

>>266
＞リバースエンジニアリングは違法ではない。
＞否定も肯定もされていないグレーゾーンにある。

よく嫁。リバースエンジニアリングが違法だとは言っていない。
リバースエンジニアリングした結果取得された技術情報を
公に発表することは権利侵害であり、これはグレーではなく
完全に黒、違法だと言っている

だから、
ギャラクシアンのバイナリイメージをリバースエンジニアリングした
【結果】は胸のうちに仕舞い込むしかない。【公にしたら違法】なのだから
出典として使えない。と言っている

270 ：名前は開発中のものです。：2008/06/02(月) 19:20:27 ID:RkeN99NI

>>269
何権が侵害されるの？
アイディアやアルゴリズムを含む「仕様」に発生する
権利は現在の法体系には存在しないぞ。

それが特許になってるとまた別だけどね。

271 ：名前は開発中のものです。：2008/06/02(月) 19:50:17 ID:CLd7aMjs

>>267
じゃあ、タスクシステムがまったく使えないって完全に認めたってことだよねｗ
そもそもね

俺はデメリットをたくさんあげたけど
君は１つもメリットをあげられなかったんだ

勝負とかそういうんじゃなくてね
君の言うことにはまったく説得力がないのさ（笑）

272 ：名前は開発中のものです。：2008/06/02(月) 20:18:50 ID:rQLP4r4x

要所で使い分けろよ
喧嘩すんなよ

273 ：名前は開発中のものです。：2008/06/02(月) 20:31:21 ID:r55Dmo9D

いや、ここ隔離スレだしｗ
知ったかと学生が喧嘩するのを
時折いじりつつ基本的には高みから見物する場所だ
>>243には笑わせてもらったよ

274 ：名前は開発中のものです。：2008/06/02(月) 20:37:46 ID:nsmxUAKf

275 ：名前は開発中のものです。：2008/06/02(月) 20:40:28 ID:tWKX9lA+

>>270
そのとおり。アルゴリズムやアイディアに著作権はない

リバースエンジニアリングした結果取得された技術情報を公に発表する
と書いたのは、具体的には当該箇所のZ80マシン語コードの断片を例示しての解説。
自分でディスアセンブルしたコードなら独自の著作物と主張できるんじゃないの、とか
断片を例示しての解説は引用に過ぎないから問題ないんじゃないの、とか
そこまでは詳しく知らないので黒じゃないかもだが

276 ：名前は開発中のものです。：2008/06/02(月) 22:32:05 ID:78e1tECU

>>269
それは大変失礼した。ひとつ言い訳をさせてもらうと>252は
「公にした違法」だからリバースエンジニアリングした事実を
公表することが本人にとってまずいと解釈した。
タスクもそうだが、人によって想定しているものが往々にして
異なるから、話をする時は見解の違いがどこに由来するものか
慎重に見極める必要があるな。全くの誤解であることも少なくない。

>>275
> 自分でディスアセンブルしたコードなら独自の著作物と主張できるんじゃないの、とか
> 断片を例示しての解説は引用に過ぎないから問題ないんじゃないの、とか

前者はありえないな。後者も解説にオリジナルのコード断片が
どうしても必要とは考えにくいから怪しいな。擬似コードでもいいだろ。

277 ：名前は開発中のものです。：2008/06/02(月) 22:36:24 ID:tWKX9lA+

>>276
＞公にした違法

悪かった。それ素でtypoってた

278 ：名前は開発中のものです。：2008/06/03(火) 00:35:43 ID:9OwbDmWK

これは古のオーパーツ、密教、タスクシステムを己の意のままに再定義・再構築・
拡大解釈しようと試みる修正主義者共の不毛で果てしない内ゲバ、宗教戦争だ。
我こそ現代的タスクシステム（御神体）を手にする神の代弁者。おまいら皆異端！
といった具合に定期的に出没しては四散してゆく田舎侍たちには2通りいる

①カルト教団ナンチャッテタスクシステム学会学会員
松浦先生（師匠）の書物を経典とし、それに記述された言葉を神の恵みと有難がる。
彼らは若く純粋で無知ゆえに洗脳されやすい。低学歴ゆえにアカデミックな権威を
忌避するので、そこに漬け込まれて得体の知れないカルトにハマる。
ゆえに密教総本山と縁もゆかりも無いレトロ趣味者の先生（師匠）が語る出典不明の
現代的タスクシステム論を妄信することができる

②自称プロ
出自を明かせないチキンにも関わらず誰一人として出典を挙げられない。
手持ちのエモノといえば、村のジジ・ババ世代が街道の旅人から伝え聞いた
神器タスクシステムに関する風の噂をもとに復元し村独自のハイセンスで
新解釈・再定義・再構築・アレンジ・増改築・魔改造して出来上がった何だか
よくわからない塊だ。

教条主義や権威主義やアカデミズムは時と場合によっては害悪となるものだが
ことこれこの「タスクシステム」なる経典不在の胡散臭いローカル用語に関しては
「教条や権威の不在」を理由に小突き回して迫害してイジメてシメたほうが良い。
ローカル用語であることを忘れ、何食わぬ顔で公の場にひょうひょうと出没
することがないよう、タスクシステムには自己批判と総括が必要だ

279 ：名前は開発中のものです。：2008/06/03(火) 00:55:20 ID:VvhS3kOQ

これ才能の無駄遣いってやつじゃね。

280 ：名前は開発中のものです。：2008/06/03(火) 01:11:43 ID:5RWrmeor

タスクシステム（笑）を銀の弾丸か何かみたいに思ってる人多いよね。
たぶんそれなりの規模のまともなゲーム１本仕上げたことないんだろうけど。

281 ：名前は開発中のものです。：2008/06/03(火) 03:15:13 ID:MeXq4ZrZ

お前らいちいち相手を煽らねーと議論ができねーのかｗ

282 ：名前は開発中のものです。：2008/06/03(火) 03:30:49 ID:vDXWXCn8

同一抽象度のリスト内での位置取りを決める必要があるなら
必ず優先度みたいな値が必要になるだろう
でも、そういう場面では同一の抽象度で扱うのがそもそも適当じゃない
そういったリストの構成はリストの要素が各々決めるべきものではない
継承を使える言語なんかでアイデアを真似てしまったタスクシステムの
根本的な問題はここだと思う

283 ：名前は開発中のものです。：2008/06/03(火) 13:18:46 ID:SxIgnH8O

>>275
著作権はないけど特許はあるよ

284 ：名前は開発中のものです。：2008/06/03(火) 16:41:39 ID:Uafcojed

タスクシステムに特許はないよ

285 ：名前は開発中のものです。：2008/06/03(火) 23:34:19 ID:knR5aZLW

おそらく特許って言ってみたかっただけなんだな

286 ：名前は開発中のものです。：2008/06/04(水) 00:00:16 ID:i3SoJRXc

じゃあパテント

287 ：名前は開発中のものです。：2008/06/04(水) 00:54:44 ID:bwfPDWKd

タスクを使うと多人数で開発する場合に
コントローラー（各オブジェクト処理を呼び出す）部分を
新たなタイプのオブジェクトが増えるたびに書き換えなくていいという
メリットがあるけど

タスクを使わずに素直に書く場合どうなるのだろう？
FactoryMethod? 使うのかな？

288 ：名前は開発中のものです。：2008/06/04(水) 05:38:36 ID:efviw52E

>>287
タスクとかコントローラー部分の具体的な内容がわからないけど、
具体的なオブジェクトが増えても呼び出し元を書き換えたくないってことなら
普通に仮想関数と、必要ならコンテナを使えば済むんじゃない？

289 ：名前は開発中のものです。：2008/06/04(水) 06:57:08 ID:qWTsFTty

この流れなら言ってもいいよな？

タスク
ダメ
ゼッタイ！

タスク依存症から抜け出す方法について議論しようぜ

290 ：名前は開発中のものです。：2008/06/04(水) 08:25:19 ID:7qi7u0vz

その様子だとカルト教団ナンチャッテタスクシステム学会から足を洗うのは
なかなかに多難のようだな

余りの風当たりの強さと叩かれっぷりに熱狂的信徒がパニクってるようだが
叩かれてるのはあくまでもその呼称であって、その動作原理ではない。
熱烈な信徒らがカルト教団にお布施して入手した池ｄ、じゃなくて松○先生の
著書（聖書）に記述された教義の内容自体は至って平凡で凡庸で有り触れた
もので、別にあれこれ叩かれるようなものではない

それをタスクシステム（笑）などと呼ぶから小突かれたりイジメられるんだよ

291 ：名前は開発中のものです。：2008/06/04(水) 08:40:59 ID:qWTsFTty

？？？　>>290の言ってることはよくわからん
松○先生とやらは知らんし呼称はどうでもいいのだが・・・
みんな動作原理っつーか設計の古さを問題にしてるんだと思うぞ

292 ：名前は開発中のものです。：2008/06/04(水) 08:50:34 ID:7qi7u0vz

みんなとは誰のことだ？設計が古いとはどれのことだ？
ギャラクシアンのZ80コードの古さを問題視するのか？

293 ：名前は開発中のものです。：2008/06/04(水) 09:15:13 ID:UiW3eWaI

タスクを使おうと主張する奴らって低学歴低賃金ワープア臭がするよな

294 ：名前は開発中のものです。：2008/06/04(水) 11:36:50 ID:3Jrj0qeW

別にそんなことないけど？

295 ：名前は開発中のものです。：2008/06/04(水) 16:18:00 ID:MMARvLzl

こんな過疎技術スレで不似合いな精神論とか人格批判をやりたいと申したか
ニュージェネレーションの到来を予感させるのう

296 ：名前は開発中のものです。：2008/06/04(水) 16:37:21 ID:JPzcOSZw

糞スレだけど、過疎ってないと思う。

297 ：名前は開発中のものです。：2008/06/04(水) 19:08:43 ID:dA0XQ2Ce

ケンカ始めるとあっというまに流れるな

298 ：名前は開発中のものです。：2008/06/05(木) 00:19:17 ID:BfpoJj45

いつもはGoFだの蟹飯本だのストールマンのソースだのGDC論文だのの権威を傘に
用語の正しさを巡ってあーだこーだ言ってる偏屈野郎が、タスクシステムの話になった途端に
それまでの頑なな教条主義や権威主義をかなぐり捨てて、まともな出典もない一介の
ローカル用語を必死になって擁護するのだから面白くてしょうがない

299 ：名前は開発中のものです。：2008/06/05(木) 03:16:13 ID:jWfxbouu

ところで・・・

>GoFだの蟹飯本だのストールマンのソースだのGDC論文だのの権威を傘に
これ↑ってプログラムを組む上でほとんど役に立たないよな（笑）

知識として知ってるのはいいけど
今、目の前にある問題を解決してくれる類のものではないことは確かだよな

色んな奴がいていいと思うけど
所詮、作ったのは人間って部分を忘れて
「ちょっと知られた論文＝絶対に正しい＝出典を示せば説明不要」って
前提で話を始めるのはよろしくない
正直、分野が分野だけに未熟だと思うぜ
論文って反論するのにものすごい時間を使うから誰も相手にしてないだけで
出版社なんかが盛り上げたらそれでOkみたいなもんあるし

正直、便利以外に「効果、可読性、品質、実用性」あたりの面から検証すれば
ボッコボコに叩かれるもんってたくさんあると思うけど現場で働いてるプログラマーにそんなことする暇ないわけで
こんな本や論文書いてる奴がどんな奴かっていうというまでもなく
本職のプログラマじゃないわけでダメなもんもそのまま広がってしまっているって面あるぜ

300 ：名前は開発中のものです。：2008/06/05(木) 08:50:34 ID:OUccFB/T

もっと人格批判やろうぜ

301 ：名前は開発中のものです。：2008/06/05(木) 15:48:09 ID:z9orY+fP

GOFの1/4ぐらいは、知っててほしい

302 ：名前は開発中のものです。：2008/06/05(木) 15:49:05 ID:z9orY+fP

>現場で働いてるプログラマーにそんなことする暇ないわけで
そういう人が３５歳定年説

303 ：名前は開発中のものです。：2008/06/05(木) 16:43:00 ID:fUsn6oNK

ごｆは古いから読む気しない
OO関係は計算機科学と違ってナマモノだし
改訂版というかyetanother的なものがあればいいんだけど

304 ：名前は開発中のものです。：2008/06/06(金) 13:09:49 ID:L0mhQQ6Z

singletonぐらいはわかってやれ

305 ：名前は開発中のものです。：2008/06/07(土) 00:04:29 ID:Oo0P7gwB

singleton をグローバル変数の隠れ蓑みたいに使ってる人と
「タスクシステム」を使ってる人に、何とはうまく言えないけども
共通点を感じる。なんだろう？

306 ：名前は開発中のものです。：2008/06/07(土) 15:10:10 ID:pJb1OYfH

データベースに格納してもグローバル変数ですよ

307 ：名前は開発中のものです。：2008/06/07(土) 16:36:21 ID:k73DxxZ1

>>305
型や引数を捨てちまうから結果的にそんな感じで組むしかないだろう
別に使わなくても強引にキャストしてタイプみてクラスの型判別して
switch caseで処理分けてなんてやってる手間みると
遊んでないで真面目に仕事しろよってマジで思う

308 ：名前は開発中のものです。：2008/06/08(日) 00:00:30 ID:HvoeC0NO

GOFパターンの利点と欠点を理解して考えて使ってる奴と
利点と欠点を理解せず考えなしに、使い方だけは知っているGOFを使ってる奴の違い

タスクシステム信者は後者
他人の権威や威光を振りかざして他人に自分をよく見せかけたい奴や
理解してないけど使ったら自分の理解を超えた何かが得られるに違いないと
考えることを放棄している奴

理解できてないからメリットを説明できないので、揚げ足取りだけ
中立だと宣言して安全な場所から攻撃する
部分的にタスクシステムも使うべきだと譲歩して話をそらす

309 ：名前は開発中のものです。：2008/06/08(日) 00:57:24 ID:reXzLmVa

パターンてのは「誰かが考案した画期的な設計」じゃなくて
「普通に作ってたら誰でもこうなる」の最大公約にすぎない。
最大公約にすぎないので、各々のシステムに合致するとは限らないし
不満点も出るだろう。パターンは改造する事が前提になってるんだから当然だ。

とGOF本に書いてあった。

タスクシステムもある種のゲームプログラムのパターン

310 ：名前は開発中のものです。：2008/06/08(日) 03:50:08 ID:C6EIFH9z

タスクシステム厨は後退戦を始めると必ず「タスクシステムはパターン！」とか絶叫する。
リスト巡回UPDATE、僕のforeach、オナニーパターン等の強烈な説得力と妥当性の前では
全くの無駄な抵抗と言える

311 ：名前は開発中のものです。：2008/06/08(日) 03:57:53 ID:gLC0FzQF

なんでタスクシステムスレで吠えるんだろう
アンチってやつか
ベクトルが違うだけで、信者と変わんねえな

312 ：名前は開発中のものです。：2008/06/08(日) 05:42:55 ID:19xi0Pci

ここのトピックはタスクシステムじゃなくて
タスクシステム厨がいかなるものかポエムを投稿する場所
らしいよ最近は

たしかに「ここは○○パターンを使いました。エッヘン」ってやつとか
どうタスクシステムを導入するかみたいな議論があったりとかするけど
まぁ初心者なんだし生暖かく見守るしかないだろ
少なくともこき下ろして楽しいほどの権威も威光もないぞ

もしかして自戒をこめて過去の自分を攻撃してるのかな？

313 ：名前は開発中のものです。：2008/06/08(日) 06:07:00 ID:7MPd/8c6

>>309
が後者な
本に書いてあったからって言って、考えようとしない
メリットもデメリットも理解できてない
マイナスイオンも科学だと言ってる連中と同じレベル
本当のことの中に嘘を混ぜて正当化しようとしている

314 ：名前は開発中のものです。：2008/06/08(日) 06:39:27 ID:7MPd/8c6

議論にすらならない、不毛だ
タスクシステムという言葉を肯定的に使う奴は、例外なく設計のセンスがない
これだけが唯一の事実だ

315 ：名前は開発中のものです。：2008/06/08(日) 06:41:40 ID:C4yVvUkh

>>190 で紹介されている Protothreads、マクロ展開された後のコード見て気絶...
ついでに、ウェブページ右の news のリンク先がまた面白かったり。

316 ：名前は開発中のものです。：2008/06/08(日) 08:55:38 ID:uXx0W8YJ

>>314
おお、久々にわかる奴みた

>タスクシステムという言葉を肯定的に使う奴は、例外なく設計のセンスがない
これ同意
まず、その辺にあるタスクシステムのサンプルみて
拒絶反応がないところがプログラマとしてのスキルが低いよな

強引で意味不明な型キャスト、引数消滅、グローバル変数使いまくり、
誰かに説明してもらわなわからん基本構造、一覧でも作成しないとわからない処理順序と
ちょっと見ただけで俺は吐気がするんだが・・・

317 ：名前は開発中のものです。：2008/06/08(日) 16:05:28 ID:03Qtljvd

j自演乙ｗ

318 ：名前は開発中のものです。：2008/06/08(日) 22:25:17 ID:SDe8+kDd

>>315
PT_BEGIN が switch(xxx) { とかに展開されるよな。

アイデアは面白いけど、ローカル変数は保持されないわけだし、制御の流れが変わるし、
まったく別の言語として扱うしかなさそうだ。

319 ：名前は開発中のものです。：2008/06/10(火) 15:11:17 ID:uFRpudfY

http://frgm.jp/ （フリーソフトで面白いゲームまとめサイト）（新）
やっと復活しました。好きなゲームに投票できます。

海外フリゲ（？）特集
http://frgrgnd.blog99.fc2.com/　自由遊戯黙示録フリーゲーム
http://www.gametunnel.com/ 　game tunnel
http://www.tigsource.com/ 　TIGSource

320 ：名前は開発中のものです。：2008/06/13(金) 10:11:18 ID:FGpNXRkP

どういう判定基準で自動投稿してんだ
この糞スクリプトはｗ

321 ：名前は開発中のものです。：2008/06/14(土) 19:26:44 ID:2gbKTgUB

タスクの使いどころについて考えてみたら70行近くになったｗｗｗ
分割します。長文スマソ
結論はタスク使えねぇなって感じね

class Task {
public:
　　virtual void update(void)=0;
};
std::list<Task *> tasks;

私は上のコードを軸に趣味ゲーム作ってたんですけども、
Task１つとゲームオブジェクト1つを当てはめようとすると無理がでる。
主にゲームオブジェクト間のデータの受け渡しで。こんな感じ。
class Task {
public:
　　virtual void update(void)=0;
};
class GameObject : public Task{
public:
　　uint32_t get_type(void);
　　uint32_t get_hp(void);
　　...
　　bool init(...) {
　　　　... //tasksにthisを追加
　　}
　　void update(void) {
　　　　... //charasにアクセスする。
　　}
};
std::list<Task *> tasks; //実行タイミング規定用グローバル変数
std::list<GameObject *> objs; //データ参照用グローバル変数
（続く）

322 ：名前は開発中のものです。：2008/06/14(土) 19:27:33 ID:qfLbT2tM

がんばれ

323 ：321：2008/06/14(土) 19:28:55 ID:2gbKTgUB

（続き）
メインループでtasksの全インスタンスのupdate()を呼びます。
ゲームオブジェクト間のデータ受け渡しのためにGameObjectはobjsにアクセス。
しかしGameObjectなんていう一つのクラスで全てのゲームオブジェクトを
表現できるはずもなく行き詰る。objsを複数に分割（Chara, Field等）してもいずれ管理不能に。

最初はTaskというきれいな切り口だけでことが済むと思っていたのに
なぜこんなぐちゃぐちゃなことが起きるのか。
それはGameObjectはデータ構造を中心とするオブジェクト指向の思想であり、
一方Taskは振る舞い（実行順番、タイミングなど）を規定するものである
という違いがあるため。データ中心か処理中心かという思想の相違。

本来はまずTaskを採用したという時点で処理単位でゲームシステムを構成すべきだったのに
（例えば２つの四角の衝突判定といった区切りなど。キャラクターやゲームオブジェクトなんていう言葉は出てこない。
　もしくは具象クラス１つで済む程度に種類が少ない）
何も考えずゲームオブジェクトなんていうデータ単位を組み合わせようとしたことが問題。
人間としてはデータ中心で考えるのがやりやすいだろうから、Taskは捨ててデータ構造中心で考えるのが良い。
処理中心でゲームシステムを組み立てるとか無理。Prolog？アセンブラ？少なくとも私には無理。

しかし処理中心で考えることが全く必要ないかというとそうでもない。
CPU2個あったら2個使いたい。でもゲーム部分のデータ構造を考えているときにCPU2個とかいう考えは出てこない。
そもそもCPUなんて単語が出てこない。
処理の効率化。それはボトムアップ的に、ゲーム部分のデータ構造とは全く異なる観点から浮かび上がってくる思想。
必要ないかといわれれば必要。
（続く）

324 ：321：2008/06/14(土) 19:30:30 ID:2gbKTgUB

（続き）

結論として、ゲーム部分はデータ中心に例えばゲームオブジェクトとかから考えるのか吉。Taskは忘れましょう。
データ構造が決まった後、さてどうやって駆動するかという話になった時には実現手法の一つとしてTaskを検討項目に入れるのも良いかも。
ただしTask=ゲームオブジェクトにはならないので注意。恐らくゲームオブジェクト一つにつき1個以上のTaskとかになる。

ゲーム部分のコードをCPU上で走らせる場合、CPUが一つであれば適当に書けばよい。
しかし複数CPUの場合はTaskという思想が有効となる可能性がある。ゲーム部分の処理を小分けにして適当に空いてるCPUに
渡すといった考えがそれに近い。関数ポインタでもいいが、引数渡しではきれいに表現できない、
状態保持をカプセル化したいといった場合には有効かもしれない。

#ありきたりなゲームじゃないのなら部分的に何かに使えるかもね＞処理中心指向
（終わり）

325 ：321：2008/06/14(土) 19:37:06 ID:2gbKTgUB

>>322 thanks!

趣味でだけど数年上記のTaskクラス使ってきて(ほんとはdisplay()=0もあるけど）
なんか使い勝手悪いなぁと思ってたんですけど、
最近ようやく腑に落ちるような観点が見つかったのでおすそ分けです。

326 ：321：2008/06/14(土) 19:39:44 ID:2gbKTgUB

ごめんなさい。なんか一人であげまくってた？
2chあまり書きこまなくて気づきませんでした。
ゆるしてちょ

327 ：名前は開発中のものです。：2008/06/14(土) 20:16:05 ID:Ay3rPjdR

タスクシステムの代わりとしてはどういうの使えばいいの？

328 ：名前は開発中のものです。：2008/06/14(土) 21:02:55 ID:ykCKUlgy

>>327
１フレ処理で

自機.move();
敵.move();
弾.move();

自機ｘ敵hit();
自機ｘ弾hit();
敵ｘ弾hit();

自機.draw();
敵.draw();
弾.draw();

ってちゃんと書く
マジでバグ減りまくる

329 ：名前は開発中のものです。：2008/06/14(土) 21:23:38 ID:7nDfwchY

>>321
個々の悩んでる様はそれなりにわかるんだけど、
結局何を言いたいのかうまく読み取れなかった。

このスレでいうタスクというのは、処理するデータの単位
(>>321のゲームオブジェクト?)のことを指しているのだと私は思ってたけど、
>>321はそれちがうってことを言いたいのかなあ。
書いてたら余計混乱してきた。

330 ：名前は開発中のものです。：2008/06/14(土) 23:46:40 ID:1uskoNxo

>しかしGameObjectなんていう一つのクラスで全てのゲームオブジェクトを
>表現できるはずもなく行き詰る。objsを複数に分割（Chara, Field等）してもいずれ管理不能に。
管理不能になるまでの具体的な経緯を書いてくれよ。

331 ：名前は開発中のものです。：2008/06/14(土) 23:46:49 ID:ykCKUlgy

>>329
だから、それを表現したいなら
「タスク」じゃダメなんじゃない？
ってのが>>321の言いたいことだろ

332 ：名前は開発中のものです。：2008/06/14(土) 23:47:19 ID:ykCKUlgy

>>330
逆に管理できる方法を書いてみたら？

333 ：321：2008/06/15(日) 00:20:13 ID:RDtyKsgS

今度は100行超えたｗｗｗｗ
もう夜遅いので中途半端だけどカキコ

>>327
実はその代わりを探すために今日2chを見てたのです。。。

まぁでも、タスクシステム使っててもゲームを作ることはできるので必要なデータはそろっているはずで、
あとはvoid Task::update(void)という過度な抽象化を取り払ってしまうだけで結構おさまりよくなるかなとは思ってます。
グローバル変数使う時点で既にカプセル化も絶縁もできてないし消しても特に悪影響無いかと。

例としてSTGの場合のコードを即興で書いてみます。自分の中でもまだ不明確なので書きながら具体化ｗ

１、まずは処理抜きで、データ構造だけでのゲーム構成要素を洗い出す。
struct {
　　uint32_t time_count;
　　std::list<Player_t *> players;
　　std::list<Enemy_t *> enemys;
　　std::list<PlayerBullet_t *> player_bullets;
　　std::list<EnemyBullet_t *> enemy_bullets;
} GameObjects;

struct {
　　InputDevice input_device;
　　std::vector<TextureResource *> textures; //本当はResourceManagerクラスとか作る
　　DXGraphicsDevice graphics_device;
} Devices;
（続く）

334 ：321：2008/06/15(日) 00:23:24 ID:RDtyKsgS

（続き）
２、データ構造間の関係性を洗い出す。
・Player_tはenemysと座標が重なったら爆発
・Player_tはenemy_bulletsと座標が重なったら爆発
・Player_tはplayer_bulletsを生成する（少なくとも生成タイミングを生成する）
・Enemy_tはenemy_bulletsを生成する
・Player_tはinput_deviceの入力に従って動く。
・enemysはtime_countが規定値になったら画面に出現する（enemysにnew Enemy_t追加でも可）
・...

３、１と２の実装方法を考える。
　　カプセル化を念頭にグローバル変数的なアクセスは避ける。
　　オブジェクト内で完結する処理はなるべくオブジェクト内で済ませる。
　　オブジェクト間の調停が必要なあらオブジェクトの外側、例えばメインループで書く。
　　無理に対象オブジェクト内のどれかでやろうとしない。
class Game {
private:
　struct _GameData {
　　　uint32_t time_count;
　　　std::list<Player_t *> players;
　　　std::list<Enemy_t *> enemys;
　　　std::list<PlayerBullet_t *> player_bullets;
　　　std::list<EnemyBullet_t *> enemy_bullets;
　} _GameData;
　struct Devices {
　　　InputDevice input_device;
　　　std::vector<TextureResource *> textures; //本当はResourceManagerクラスとか作る
　　　RenderManager render_manager;
　　　DXGraphicsDevice graphics_device;
　} Devices;
（続く）

335 ：321：2008/06/15(日) 00:26:29 ID:RDtyKsgS

（続き）
public:
　void update()
　{
　　　foreach player (players) {
　　　　foreach enemy (enemys) {
　　　　　if (player.hit_test(enemy)) { // void Task::update(void)以外のメソッド使える！
　　　　　　　player.damage_increment(); // void Task::update(void)以外のメソッド使える！
　　　　　}
　　　　}
　　　}
　　　...
　　　foreach player (players) {
　　　　player.update(); // damage_increment()反映、前フレームの入力に従って移動等
　　　}
　　　foreach enemy (enemys) {
　　　　enemy.update();
　　　}
　　　...
　　　foreach player (players) {
　　　　for (int i = 0; i < player.num_of_generate_bullet(); i++) { // void Task::update(void)以外のメソッド使える！
　　　　　player_bullets.push_back(new PlayerBullet_t(座標と方向とかショット種別とか), 優先度?); //システム化したい。Iterator? 構造体のリスト渡し？
　　　　}
　　　}
　　　foreach enemy (enemys) {
　　　　enemy.update();
　　　}
　　　...
（続く）

336 ：名前は開発中のものです。：2008/06/15(日) 00:26:33 ID:fgJN+8Ya

>>330
update() で別インスタンスを参照したいクラスの増加に応じて
対応するグローバル変数と登録削除処理が増えるなんて、
もうやってられないでしょ。

337 ：321：2008/06/15(日) 00:30:52 ID:RDtyKsgS

（続き）
　　　foreach player (players) {
　　　　player.draw(&render_manager);
　　　}
　　　foreach enemy (enemys) {
　　　　enemy.draw(&render_manager);
　　　}
　　　...
　　　foreach enemy (enemys) {
　　　　render_manager.render(&graphics_device);
　　　}
　　　...
　　　foreach player (players) {
　　　　player.input(input_device); // void Task::update(void)以外のメソッド使える！
　　　}
　　　...
　}
};

こんな感じでいけたらいいなあと。・・・あれ？　update()必要ですね。。。
まぁでもvirtual void Task::update(void)=0の実装じゃなくて具象クラスのvoid Player::update(void)なので勘弁して。

おっきな変化点はゲームオブジェクトの外側から「void Task::update(void)以外のメソッド使える！」ってとこです。
うれしいところもそこに尽きます。それだけです。
でもそれだけのことなのに「void Task::update(void)」にしばられてるとグローバル変数使うとか動的キャストでもしないと実現できなかったので
自分的には大発見なのです。なんかGame::update()を見てると関係無いと思ってたデザインパターンとか適用できそうな気がしてきたしいいことずくめ。
（続く）

338 ：321：2008/06/15(日) 00:37:24 ID:RDtyKsgS

（続き）
これは蛇足っぽいですが、タスク関係で思いついたので。
・Game::update()にずらずらオブジェクト間にまたがった処理書くの嫌ならforeach1個を1つのTaskとして実装するのもよいかも。
　２の「データ構造間の関係性」の項目１つ１つに相当。
　Taskとして切り出す単位がデータオブジェクトの区切りを全くシカトして処理単位で切り出してるとこがミソ。
　入出力、アルゴリズムが決まりきってればvoid update(void)でも事足りる。
　データ構造はオブジェクト指向で管理、振る舞いはそれ以外の思想で管理と分けるなら我慢できる気がする。UMLも複数の図使うし。
・Game::update()の開始からplayer.update()を呼ぶループより直前までの処理は
　ループ毎に並列に実行可能かも、ループ毎にTask化できるかも、とか考えてくと面白そう。
　ttp://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm とか参考に。

#あと >>321 のcharasはobjsの間違いです

339 ：321：2008/06/15(日) 01:50:12 ID:RDtyKsgS

>>329
> >>321はそれちがうってことを言いたいのかなあ。
そうです。

タスクって実は処理するデータの単位じゃなくて処理の単位で区切らないといけないんじゃね？とか
ゲームオブジェクトというデータの区切り方とタスクという処理の区切り方って全く関係ないんじゃね？というのが言いたいことです。

ゲームオブジェクトは構造を、タスクは構造間の振る舞いを規定するということにすると素直に感じられる気がするとか、
ゲームオブジェクトというデータ中心の観点、それからタスクという処理中心の観点というのは
クラス図と状態遷移図みたいに異なる観点であって、クラス図のゲームオブジェクト内に状態遷移図の情報を
きれいに突っ込むの無理じゃねみたいな感じ。
1000行以下のちっちゃい例題プログラム程度なら1状態遷移を1メソッドで表現とか可能かもしれませんが。

タスクは処理区切りという観点で考えると、設計はデータ構造区切りでの分析を先行してやりたいかなぁ、慣れてるし、とか
処理区切り先行でプログラム組み立てるとかって何それできるの？　数学とかLISP方面？　俺無理。
という思考の流れでタスクをゲームプログラムの主軸に据えるのってどうなのよと思い至りました。

>>330
１、グローバル変数が増える
２、グローバル変数を参照する箇所もたくさん増える
３、脳みそパーン
・・・すみません。もう寝ます。

340 ：名前は開発中のものです。：2008/06/15(日) 02:01:57 ID:zJaLEBLM

それってタスク限らないんじゃないか。

341 ：名前は開発中のものです。：2008/06/15(日) 02:15:26 ID:4um+jjiN

複数パスの処理を明示的に組み立てられるタスクシステム(ライクなもの)を作ればいいんじゃね？
と言い捨て

342 ：名前は開発中のものです。：2008/06/15(日) 03:16:28 ID:kCeJLpX+

ここまで読んでも結局よく分かりませんでしたが(頭固くてごめん)、
>>331を元に推察すると
「これまでこのスレでタスクと呼んでたものをオブジェクトと呼びましょう、
それによって実装もこんなに変わりました！」
ってことでしょうか?

343 ：名前は開発中のものです。：2008/06/15(日) 03:46:46 ID:fgJN+8Ya

抽象化して具体的な型を失うと、具体的な型に応じた処理が書きにくくなるという
あたりまえのことに気づいた。

本人がそう捉えているかどうかは別にして、そういうことに見える。
データの区切りと処理の区切りの話は、たぶん問題の本質じゃない。

344 ：名前は開発中のものです。：2008/06/15(日) 04:22:06 ID:3r3JLp6V

設計についての文句は別にないが、Gameクラスにリストをすべて突っ込んで
「グローバル変数がなくなった！」というのは詭弁ではないか？
タスクシステムでも、リストをひとつのクラスにまとめておけば、
オブジェクトが何種類増えようがグローバル変数増えないじゃん。

つか、全てのゲームオブジェクトをタスクとして作るのなら、
>>321 で言うGameObjectは、種類が増えるたびにリストを増やすんじゃなくて
タスクリストからそのオブジェクトのリストを取得する関数を作るべきじゃないかと思った。
例えばこんな風に。（先にリスト化するにしても、ラッピングはすべきかと）
class Bullet : public Task {
public:
　　static const int TARGET_PLAYER = 0x01;
　　static const int TARGET_ENEMY = 0x02;
　　bool check_target(int target) const {
　　　　return (this->target & target) != 0;
　　}
};
void search_bullets(std::list<Bullet *> &list, int target) {
　　for (std::list<Task *>::iterator i = tasks.begin(); i != tasks.end(); ++i) {
　　　　Bullet *bullet = dynamic_cast<Bullet *>(*i);
　　　　if (bullet != 0 && bullet->check_target(target)) {
　　　　　　list.push_back(bullet);
　　　　}
　　}
}

std::list<Bullet *> list;
search_bullets(list, Bullet::TARGET_PLAYER); // 自機に当たる弾を取得

345 ：名前は開発中のものです。：2008/06/15(日) 13:45:30 ID:rp8a8YLA

>>343
>抽象化して具体的な型を失うと、具体的な型に応じた処理が書きにくくなるという
>あたりまえのことに気づいた。
あるな
こっちの処理のが複雑なのに擬似タスクなんてやってる場合じゃねぇと思う

346 ：名前は開発中のものです。：2008/06/15(日) 14:11:00 ID:KmbefDXz

class Bullet : public Task {

347 ：名前は開発中のものです。：2008/06/15(日) 14:15:57 ID:KmbefDXz

ミスった

class Bullet : public Task {
}
;
じゃなく
class Bullet : public Sprite, Task
{
}
;
みたいに必要な場合だけMix-inしてみるとか。
たくさんの弾幕が協調して動くみたい処理なら
class CompositeBullet : public Task
{
　　list<Bullet*> bullete_list;
}
;
ダメかね？わかりづらい？

348 ：名前は開発中のものです。：2008/06/15(日) 16:37:11 ID:9+3p1uWs

原子による世界構造を体言してるだけで
システムとしてはTaskなり大きすぎる抽象性は機能を為さない
不釣合いに広範囲からアクセスされることが大域変数の邪悪性だとしたら
不釣合いに広くをカバーしてしまう抽象性というのも同様に邪悪なんじゃないかね

349 ：321：2008/06/15(日) 16:50:12 ID:RDtyKsgS

>>340,343
はい、そうです。今まで気づきませんでした。なんでだろ。

>>341
データ構造が既に別途確立した上での話ならありかと。

>>342
大体そんな感じです。
タスク（Commandパターン？）はデータ構造を記述できない。だからプログラムの大黒柱になりえない。
もっと抽象度下げたデータ構造を記述可能なものを用意してそれを大黒柱にしよう。
そうしたらタスク使わなくてもなんか記述できちゃうからタスクいらないよね、って感じです。

でもデータ構造と処理フローの２柱がプログラムには必要と考えると処理フローの部分に
タスク（というかCommandパターン）を適用可能かもしれません。

350 ：名前は開発中のものです。：2008/06/15(日) 18:45:50 ID:n3ZqdSRd

タスクシステムこそがデータ構造であり、リスト構造。

351 ：321：2008/06/15(日) 18:47:15 ID:RDtyKsgS

>>344
> 設計についての文句は別にないが、Gameクラスにリストをすべて突っ込んで
> 「グローバル変数がなくなった！」というのは詭弁ではないか？
データは全部引数経由で必要な時に必要なだけ渡すように構成可能だと思います。
具体的には >>335 のplayer.hit_test(enemy)の部分。衝突判定のつもりですが、
敵1体のデータだけが渡されています。その他の必要の無いリスト、Devicesの情報は
渡っていません。常に全情報が公開されてるわけではないので無くなってる（無くせる）と言っていいと思います。

> タスクシステムでも、リストをひとつのクラスにまとめておけば、
> オブジェクトが何種類増えようがグローバル変数増えないじゃん。
タスクシステムでは0にできないと思います。
できたとしても必要最小限の引数渡しができないと思います。
Task::update(Game *)みたいなグローバル変数的なデータの受け渡しが必要かと。
タスクから能動的に情報取りに行くんじゃなくて外部から受動的に情報渡されるのを待つ感じです。
カプセル化できるので結構使い勝手良くなるんじゃないかと思ってます。
まだ思ってるだけで実装確認してませんが。

> つか、全てのゲームオブジェクトをタスクとして作るのなら、
> >>321 で言うGameObjectは、種類が増えるたびにリストを増やすんじゃなくて
> タスクリストからそのオブジェクトのリストを取得する関数を作るべきじゃないかと思った。
確かにその方がリストが１つになってきれいな感じですね。
でも私dynamic_castとか例外とか好きじゃないんです（未サポートコンパイラ的な意味で）。
たとえイベント通知とかで見かけるunionとenumのtypeの組み合わせ的な実装だったとしても、
言語が用意してくれてる静的な型システムという利点を自ら捨てるようなのはあまり好きじゃないです。
よく知らないんですが、もし静的な型システムに替わる保証方法が存在していて、リスト走査の無駄を
許容可能なCPU速度もしくは上司wなら後は好みの問題かも知れません。

352 ：名前は開発中のものです。：2008/06/15(日) 20:20:52 ID:fFyG+ObX

もし自機追尾弾とかが必要になったら、追尾弾だけbullet.update(player)とかやるの？
オブジェクトの種類を増やしたらメインループが一気に肥大化しそう。

できれば、新しい種類の敵を作ってもenemy.update(), enemy.hittest(), enemy.draw()
の3つは統一させて、メインループの変更は不要にしておきたいな。
そっちのほうが敵を作るときも処理内容だけに専念できるし、無理してグローバル変数を
削る必要はないと思う。
（グローバル変数にするべきかどうかはよく考える必要はあるけど）

353 ：名前は開発中のものです。：2008/06/15(日) 20:24:58 ID:3r3JLp6V

なんでhit_testの引数とupdateの引数を比較してるの？
タスクリストを使ってても、衝突判定関数に渡すのは判定対象のオブジェクトだけだろうし、
>>335のやり方でも、update内で必要な情報は、呼ぶ側からは確定できないんじゃない？
updateのときか、ゲームオブジェクトを作るときかは知らんけど、
struct _GameData への参照、もしくはそこから情報を得るためのインターフェイスが
必要になると思うんだけど。

後半については、「全てのゲームオブジェクトをタスクとして作るのなら」という前提の話だから。
タスクとして作る（極端な抽象化を施す）のであれば動的キャストは避けられないと思うし、
動的キャストを無理矢理避けて、すべてのオブジェクトを別々のリストに入れておくなら、
そもそもタスクとして作る意味がない。
というか、型を静的に判断したいのに、なぜTaskを継承する道を選んだのか……？

354 ：321：2008/06/15(日) 21:29:52 ID:RDtyKsgS

ども321です。そろそろななしに戻ります。
最後に、私は「タスクに飛びついて無駄に複雑なコード書いた初心者」で
「なんかおかしくね？まだまだゲーム内容シンプルでつまんない段階なのにプログラム複雑すぎね？」
と悩んで、ごく最近原因はタスクであろうと思い至りました。思い至っただけで何も実装確認してません。
即興でコード片でっちあげましたけど、あれ本当に動くかわかんないです。

ただ、タスクはデータ構造が規定できないというのが弱点なのはいえると思います。
タスクはCommandパターンだとして考えると、Wikipediaの「デザインパターン (ソフトウェア)」に
　　1 GoFによる23のパターン
　　　　1.1 生成に関するパターン
　　　　1.2 構造に関するパターン
　　　　1.3 振る舞いに関するパターン
って書いてあってCommandパターンは振る舞いに関するパターンだったので、
生成と構造に関することがらは不得意なんじゃないかと。

「Commandパターンだけじゃねえ、タスク「システム」だぞ！　構造規定も入ってる！」という話でも無い限り、
タスクシステムの他にゲーム用のデータ構造を独自に定義する必要があって、
それらデータ構造間のデータやり取りとタスクというもののすり合わせについても考える必要があるので
無駄に複雑になっているのかと。特にすり合わせの部分の増加分。

つなぎ、振る舞いの部分はマルチCPU対応とかの（俺的）未開拓領域があるのでタスクシステムの生きる道が見つかりそうな気もします。
まぁ、ハードウェアに合わせないといけない低レベル層だとか、独自スクリプト処理系とか独自通信プロトコル処理系みたいな
処理毎の内容は変化しないけど実行順番は変化するという環境では普通に生き残ると思いますが
（タスクシステムがというよりCommandパターンがですが）。

355 ：名前は開発中のものです。：2008/06/15(日) 21:32:34 ID:RDtyKsgS

>>347
それで目的の処理が苦もなく実装可能ならありかも。
でもBullet１つで複数のSprite使いたくなった時どうしようとか、
CompositeBulletを複数階層に渡って構築してったらタスクリストの存在意義が薄れてくとか
なんで俺がタスクリストとCompositeBulletの住み分けで悩まないといけないんだとかになりそう。
もしタスクリストに統一するとグローバル変数地獄、
CompositeBulletにPlayerとかEnemy入れてったらタスクシステム廃止と変わらない気がとか。

356 ：名前は開発中のものです。：2008/06/15(日) 22:00:54 ID:RDtyKsgS

>>350
こんな感じ？
enum TaskType {
　PLAYER,
　ENEMY,
　BULLET,
　BINARYDATALOADER,
　RES_PIC,
　RES_ANIM,
　RES_SOUND,
　RES_BGMPLAYER,
　...
};

class Task {
public:
　enum TaskType get_type()=0;
　void update(void)=0;
};

std::list<Task *> tasks;

これは予想外・・・。なんだこれ。
LISPをほんの少し参考にした独自中間コードのインタプリタ＋リソースマネジャー？

なぜか異次元という言葉が頭に浮かんだ。。。
これが本当のタスクシステムだというなら
最初にタスクに飛びついたのはまずった気がする。自分の趣味じゃない。

357 ：名前は開発中のものです。：2008/06/15(日) 22:25:39 ID:rp8a8YLA

>>352
それって結局メインループで解決すべき複雑性を
個々のオブジェクトに移して余計問題を複雑にしてるだけのような希ガス
各オブジェクトなんかに問題をばら撒いたら転移した癌細胞のごとくどうしようもない
状況になるって直感でわからんか？センス悪いな

メインループを意固地に固定することにこだわる方向は間違っている
そうじゃなくて複雑になるメインループをうまく管理する方向にいくべきだったと俺は思うぞ

>>354
>「なんかおかしくね？まだまだゲーム内容シンプルでつまんない段階なのにプログラム複雑すぎね？」
感がいいな
そのセンスを大事にしたらいいと思う

358 ：名前は開発中のものです。：2008/06/15(日) 22:42:25 ID:RDtyKsgS

>>352
> もし自機追尾弾とかが必要になったら、追尾弾だけbullet.update(player)とかやるの？
私なら敵弾全部でbullet.update(player)とやりそう。私もある程度は抽象化したいです。楽だし。
まぁでも、chase_bullet.target_point(player.get_position_center())とかはそれはそれでありかも。
面倒だけどエンバグ少なそう。

> オブジェクトの種類を増やしたらメインループが一気に肥大化しそう。
増えますね。ここがタスクシステム（というかCommandパターン）の出番なのかもしれません。
例えばループごとにタスク１個ずつ作るとか。まだ具体的な対策考えてません。

> できれば、新しい種類の敵を作ってもenemy.update(), enemy.hittest(), enemy.draw()
> の3つは統一させて、メインループの変更は不要にしておきたいな。
virtual void Enemy::update(Player *)=0;　みたいな感じですよね？
ありだと思います。

359 ：名前は開発中のものです。：2008/06/15(日) 22:56:28 ID:G2pedMq+

>>356
インタプリタはいい線。
TCBなんて用語からするとOSから借りてきた技術だろう。
>4-5

360 ：名前は開発中のものです。：2008/06/15(日) 22:57:19 ID:3r3JLp6V

敵はEnemy、弾はBulletからの継承でいいだろ。それは自然な抽象化だと思うが。

>>354
「タスクシステム＝Commandパターン」についてちょっと説明してほしい。
GoFでいうなら、Adapterパターンあたりじゃない？

361 ：名前は開発中のものです。：2008/06/15(日) 23:00:18 ID:RDtyKsgS

>>353
私は動的キャストと例外は使いません。使い方知らな（ry
静的な型システムの保証範囲広げたいので。
> というか、型を静的に判断したいのに、なぜTaskを継承する道を選んだのか……？
それしかやり方知らなかったからです。
修破離の修の段階でした。今は破の段階？だといいんですが、ほんとかなー

>>357
あざーーっす

#...5年前にゲーム開発を始めて今週ようやくTaskの弊害に気づいたという事実は胸の内にしまっておこう

362 ：名前は開発中のものです。：2008/06/15(日) 23:08:49 ID:rp8a8YLA

>>358
メインループを整理する方向でプログラム組んだほうがいいだろ？

ゴジラとメカゴジラがいたとして
それらがぶつかり合ったときの処理は
ゴジラにもメカゴジラにも書いてはダメだろ
ぶつかった後のリアクションは当然それぞれに書くけど

ゴジラとメカゴジラの戦うフィールドなりなんなりでするべき処理であって
ゴジラの処理でもメカゴジラの処理でもない

オブジェクト指向的に考えても戦うフィールド（仮）のサブルーチンにしかならない出来事だと思うぜ

自機、敵、弾、オブジェクト指向ではこんな単位で分けることまでしかやってないっしょ？
戦うフィールドのサブルーチンは
昔のC言語よろしくコツコツ関数化して書かなきゃいけねぇんじゃねぇかなーと思うよ俺は

363 ：名前は開発中のものです。：2008/06/15(日) 23:24:10 ID:RDtyKsgS

>>360
Wikipediaを見ながら何となくCommandかなーって思ったからです。
今見るとIteratorもそれっぽい気がしなくもないです。
要はフィーリングです。

#私は上司から「お前は詰めが甘い。突き詰められてない」とよく言われますが
#趣味ならそれでも怒られない。趣味サイコー!

Adapterは戻り値の存在が重要な意味を持つんじゃないでしょうか。Wikipediaぱっと見た感じ。
Commandは戻り値はどうでも良くて、実行したということが重要な感じ。ぱっと見。

364 ：名前は開発中のものです。：2008/06/15(日) 23:40:01 ID:azsLMlHb

デザインパターンなんてそのまま当てはまることのほうが稀じゃない？

365 ：名前は開発中のものです。：2008/06/15(日) 23:54:37 ID:3r3JLp6V

根拠がないんだったら、それを前提として論を展開するのは止めたほうが良いかと。

366 ：名前は開発中のものです。：2008/06/15(日) 23:58:51 ID:rp8a8YLA

>>365
どうせだったら

「デザパタの～とそこがちがう、だからあの説明の～はこの部分でおかしい」

って話をしてほしい

367 ：名前は開発中のものです。：2008/06/16(月) 01:07:19 ID:HtcJzfTs

>>359
TCBってTask Control 「Block」なんですね。
RAM領域をBlockに小分けして管理しやすくしてると。
異次元からカッコイイ！に印象が変化しました。バイナリアンカッコヨス
C++じゃなくてC言語で書きたい気分。拡張子は*.cで。

こんな感じですよね
・RAM領域は0x00000000～0x0010000（64KByte）で、
そのうち0x00008000～0x00100000（32KByte）までをTCB1個あたり1Kbyteを32個で管理したいって時に
下記TCB_Infoを0x00008000に割り当てる。

typedef byte[1024] TCB_t; /* typeとかもっと詳細に定義しとくのかも */

struct {
　　TCB_t[32] tcb_vector;
　　std::list<TCB *> no_used_blocks;
　　std::list<TCB *> used_blocks;
}TCB_Info;

プールするあたり、Flyweightパターンかな。
でもアプリケーション層であるゲームの根幹には置きたくないですね。OSがやればいいのにみたいな。
プロセス管理とメモリの動的確保を１つのシステムでお手軽に実装可能なのはいい感じ。
でもメモリ使用効率は悪いし型システム使えないしで、最初の一歩って感じかな。
私組み込み系なので黎明期の開拓のロマンを感じるし自分でOSの下の層を実装することになったら
最初は使わせてもらうこともあるかもしれないけど、改善の余地は十分あるって感じ。

>>365
デザインパターンの本立ち読みしてがんばれ。フィーリングでなんとかなるはずだ。
俺は寝る。既に明日遅刻の予感がしている。やばい。上司怖い。超やばい。

368 ：名前は開発中のものです。：2008/06/16(月) 01:20:06 ID:HtcJzfTs

>>367
リストがRAMはみ出てたｗｗｗｗ
詰めあめぇｗｗｗ

369 ：名前は開発中のものです。：2008/06/16(月) 01:22:53 ID:PSleqKIe

年寄りのスレ流し読みESPレス
>>356
＞LISPをほんの少し参考にした独自中間コードのインタプリタ＋リソースマネジャー？

違和感の正体が何となく見えてるようね。開発規模に適したコーディングスタイルというものがあり
タスクシステムとか呼んでるそれをまともに運用するには高いイニシャルコストを支払う必要があるのね。
今みたいに出来合いの優秀な統合開発環境も、というかまともなコンパイラもデバッガも機材も無かった
貧弱開発環境時代、そしてマシン語を直接読んでデバッグするような人間が珍しくも何ともなかった時代
↓のようなスタイルは低コストで受け入れられたけどね、今は違うのね
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

15年近く前、マシン語読めて当たり前とかいう時代では既になくなってて、上のようなレガシーな
コードを効率的に運用するためには様々な周辺グッズとかや支援ツールが必要になってた。
ゲームコードコンパイラ、テキスト画面ベースのグラフィカル（笑）なデバッガ、テストツール、
メモリ可視化ツール、非プログラマ向けの様々なエディタ、などなど。そういったものを設計・開発・
テスト・実戦投入・運用した。当時はお金払っても手に入らないものばかりだったので作った。
君らが道端で拾ったタスクシステムとか呼んでるコード断片ね、それ単体だと何の価値もないのよ。
それを生かすのに必須となる支援ツールのセット、統合開発環境、分業のためのワークフロー
そうしたノウハウと組み合わさって初めて意味を成すの

個人製作の趣味者向けに分かりやすく一言で言えば
VisualStudioを素のままで使うつもりなら>>328でやるほうが遥かに小回りが効いて良い。
それを理解したうえでタスクシステムじゃなきゃ嫌だい！ってんならもはやカルトってことで

がんばれ

370 ：名前は開発中のものです。：2008/06/16(月) 02:11:14 ID:rSqKWN6I

なんか定義があいまいなまま議論してる気がする

「タスクシステムライクなもの」という言葉を以下のように定義する
・「複数の状態を持ち、状態ごとに別の処理を行える」という特性のあるタスククラスを持つ
・タスククラスから派生した形でゲーム内のほとんどのオブジェクトを実装する
・毎フレーム、存在するタスクを何らかの順序に基づいて逐次実行する
・実行順序や回数に関しては内容に応じて適当に工夫する。
・タスクは親子関係を持ち、親タスクをOFFにすると子タスクも自動的にOFFになる、親子ツリーごと削除のようなことが可能。

371 ：名前は開発中のものです。：2008/06/16(月) 02:11:38 ID:rSqKWN6I

を、書きたいこと書く前に投稿しちゃったorz

372 ：名前は開発中のものです。：2008/06/16(月) 02:27:29 ID:rSqKWN6I

で、今までどっちかというと>>328風味なプログラム作ってたんだけど、
だんだんクラス作成のオーバーヘッドが重くなってくるから、
ちょっとしたエフェクトのためのクラスとかを作りづらくなってくるのね。

そういう意味では「タスクシステムライクな」構造(>>370)にしておくことで、
規模が大きくなってきたときとか、GUIとスプライトが入り乱れたりとか、
細かい変なエフェクトクラスをいろいろ作る場合には便利なのかなと思ってきた。

（ただし、今のところ処理の実装をスクリプトでやる方向だけど・・・。）

373 ：名前は開発中のものです。：2008/06/16(月) 02:30:41 ID:rSqKWN6I

ちなみに、 >>370 の定義の内容だと、
WindowsのHWNDまわりとか、3Dのシーングラフなんかも微妙に似た構造かもしれない。
どっちかというとそっちを参考にしてる度合いが強いので。

374 ：名前は開発中のものです。：2008/06/16(月) 02:31:43 ID:I3VGe9XK

>>372
エフェクトクラスのインスタンス生成が重いのなら、そこだけ高速化するべき。
メインループとか外部の構造を変える必要はない。

375 ：名前は開発中のものです。：2008/06/16(月) 02:36:11 ID:rSqKWN6I

>>374
すまん誤解させた。
速度じゃなくて、クラス作成の工数のオーバーヘッドね。
ソースツリーのいろんなところをいじくらないとちゃんと動かないという。

376 ：352：2008/06/16(月) 03:01:56 ID:hw017bwB

タスクシステム関係ないけど

>>358
そんな風にやってたら、途中で追尾弾追加するためだけに他の敵弾bullet1, bullet2, ...にも
update(player)を追加しないといけなくなるから面倒じゃないかな。
最初から完全に仕様が決まっていればいいけど、俺みたいに気まぐれに作ってるとなぁ。

自機と敵弾とか影響しあうオブジェクトは一部しかなくても、どのオブジェクトも同じ空間に
あってそれぞれが影響しあう可能性はいくらでもあるし…
（ゴジラの処理内容に戦車が関係なかったとしてもゴジラから戦車を見えなくする必要はないし
　ゴジラが気まぐれで戦車を壊し始めたりするかもしれない）
と開き直ってお互いが参照しあえるようにしてます。
ちょうどfield.player, field.enemyListみたいに

>>357
俺はメインループからの関数呼び出しをできるだけ統一させたいって言ってるだけで、
メインループでのupdate(), hittest(), draw()以外の処理を禁止してるわけではないですよ。

377 ：名前は開発中のものです。：2008/06/16(月) 03:48:31 ID:PSleqKIe

>>375
エフェクトとは
　エフェクトデータ
　　・必要なメディア（音声、アニメーション、etc）名の一覧（トラック）
　　・再生手続きを記述したタイムテーブル（タイムライン）
　エフェクト再生クラス
　　必要なときにリストに再生リストにインスタンス生成＆再生リストに登録
　　指定されたデータセットを指定された場所で指定された時間に再生
　　再生終了したら再生リストから削除してインスタンス破棄

細かい変なエフェクトクラスって具体的になんだ？
ソースツリーのいろんなところをいじくらないと、って具体的にどこだ？

>>328方式で「ソースツリーのいろんなところをいじくらないとちゃんと動かない」
たって、増える余地があるのはせいぜい専用リストの作成と削除の2箇所くらいだ

378 ：名前は開発中のものです。：2008/06/16(月) 03:50:31 ID:PSleqKIe

眠くて日本語ぬっこわれてるな

×必要なときにリストに再生リストにインスタンス生成＆再生リストに登録
○必要なときにインスタンス生成＆再生リストに登録

何はともあれ、いろんなところをいじくる必要がある例としてあげるには
向いてない気がするよ

379 ：名前は開発中のものです。：2008/06/16(月) 04:31:23 ID:rSqKWN6I

自分で言い出しといて用語が誤解を与えるのはすまんね・・・

>>372 でエフェクトといってるのは、いわゆる簡単にデータ化できるものじゃなくて、
それぞれクラス化するしかないようなものをまとめてエフェクトと呼んだ感じ。

具体的に挙げろというと案外思い出すの難しいんだけど・・・
たとえばマウスで行動を指示するときのマップ上のインジケータみたいなものとか、
キャラの残像みたいなものとか・・・　まあ、そういった、単純にデータ化できなくて、プログラムの処理が噛んで、
しかも他のものと一緒くたにするにはおさまりが悪いような、そんなもの。

> >>328方式で「ソースツリーのいろんなところをいじくらないとちゃんと動かない」
> たって、増える余地があるのはせいぜい専用リストの作成と削除の2箇所くらいだ

そもそもそれらを「タスク」的なものともとらえていなかったから、
専用の関数を直接呼び出したり、
キャラ用クラスの内部メンバとかにおさまったりもしたわけですよ。

380 ：名前は開発中のものです。：2008/06/16(月) 07:41:06 ID:JnidzRuD

>>376
それが意味無いと思う
なんで記述を統一しようとするの？
メインでやるべきことを強引にほかに移してまで
やるいみ無いでしょ

381 ：名前は開発中のものです。：2008/06/16(月) 11:48:50 ID:F6aM01P1

>>328
オブジェクト同士の判定はベタで書く必要があるだろうけど、
move() と draw() の呼び出しはそれぞれ一本ずつにまとめられそうな気がする。

全オブジェクト.move();

自機ｘ敵hit();
自機ｘ弾hit();
敵ｘ弾hit();

全オブジェクト.draw();

382 ：名前は開発中のものです。：2008/06/16(月) 13:00:35 ID:m0I6lFOP

>>381
まとめようとするのが害なんだって
という話をしてるんだろ

383 ：名前は開発中のものです。：2008/06/16(月) 17:32:04 ID:OzKcYXUg

まとめない場合描画順は深度指定で描画ライブラリに任すのだろうか

384 ：名前は開発中のものです。：2008/06/16(月) 19:24:10 ID:JnidzRuD

は？
描画順なんてこんな処理に依存してちゃ駄目だろ
drawは登録だけしてソートは後でじっくりやれ

385 ：名前は開発中のものです。：2008/06/16(月) 20:39:24 ID:PSleqKIe

>>370
＞タスクシステムライクなもの
それはタスクシステムライクではなく、もっと別の、より適切な呼び方があると思うのね。

＞・「複数の状態を持ち、状態ごとに別の処理を行える」という特性のあるタスククラスを持つ
FSMの一言で済む

ライクとか擬似とか現代風とかのバリエーションを唱える人間は過去に何人も見たが
どれも新たな俺解釈俺定義俺拡張でしかなく、10レス先にはそんなもの誰も覚えてないのね

386 ：名前は開発中のものです。：2008/06/16(月) 21:15:29 ID:HtcJzfTs

>>369
カッコヨス。テラカッコヨス。

387 ：名前は開発中のものです。：2008/06/16(月) 22:20:00 ID:HtcJzfTs

>>370
多分こんな感じ？
・バージョン１：動的キャスト使用バージョン
std::list<Task *> tasks;
class Task {
public:
　　virtual void get_type(void)=0;

　　virtual void update(void)=0;
　　virtual void hit_test(Hit_st *);
　　virtual void draw(void) {}
　　//その他メソッドを具象クラスで定義
};
task_add(Task *);
task_del(Task *);
task_update_all_task();

388 ：名前は開発中のものです。：2008/06/16(月) 22:20:55 ID:HtcJzfTs

（387続き）
私はこんな感じのをタスクシステムと思ってた。
・バージョン２：動的キャスト非使用バージョン
struct CommonData {
　　InputManager inputmgr;
　　GraphicsManager gramgr;
　　HitManager hitmgr;
　　SoundManager sndmgr;
　　SceneManager scenemgr;
　　...
} common_data;
class Task {
public:
　　virtual void update(void)=0; //ここでcommon_dataにアクセス
　　virtual void draw(void) {}
};
class TaskManager {
private:
　　std::list<Task *> tasks;
public:
　　add(Task *);
　　del(Task *);
　　update_all_task();
};

多分バージョン１は言語処理系を参考に、バージョン２はOSを参考にしてるんだね。
おもしろす。
でもバージョン１は既にCが、バージョン2はWindowsなりフレームワークなりが既にあるんだから
わざわざ自分で独自スクリプトもしくはPCエミュレータを作る必要無いよね。
周辺知識は付くけどゲームの完成には寄与しないよ。
..と今、5年間の暗黒時代の経験からくるフィーリングを受けた

389 ：名前は開発中のものです。：2008/06/16(月) 22:27:30 ID:PSleqKIe

>>379
＞マウスで行動を指示するときのマップ上のインジケータみたいなものとか

いわゆるHMD、視界内に記号をオーバーレイする仕組みと思うけど
記号はゲーム内仮想空間上に存在しない＝物体（エンティティ）との「相互」作用ない。
スクリーン上の映像から何らかの作用を受ける

だから仮想空間上のエンティティと同じリストには入れる必要がない
どんな組み方だろうと「他の物と一緒くたにするにはおさまりが悪い」と言える。
マウスカーソルが絡む記号はTerrain::GetFromScreen(スクリーン座標)のように
取得される地形情報を元に表示されるというだけで、他の記号と大差ない

＞残像

当該ボーン（ペアレントしたオブジェクト。剣とか）の姿勢情報を数フレーム分保持し
フレーム間の姿勢情報を補間して残像モデル（トライアングルストリップ）の頂点情報を
更新して加算合成表示する何らかの機構のことだとすると
IK同様に割りと頻繁に使うものだからデータ側で指定できるように、例えばボーンや
オブジェクトのアトビュートに残像についての項目を加えたりして、実際の再生処理は
アニメーション再生クラス内に隠蔽されるだろう。
残像はエンティティではないから、仮想空間上のエンティティと同じリストに入れる必要がない
どんな組み方だろうと「他の物と一緒くたにするにはおさまりが悪い」と言え

390 ：名前は開発中のものです。：2008/06/16(月) 22:30:11 ID:PSleqKIe

る。

391 ：名前は開発中のものです。：2008/06/16(月) 22:34:10 ID:HtcJzfTs

>>372
その道はいつか来た道（5年位かけて）
そしてそろそろ去りたい道・・・

自分がプログラマでコード読み書きが可能なのにスクリプト作りたくなるってのはどこかおかしい。
既存のスクリプトシステム使って、本当にやりたかったことか考え直すのがお勧め。もしくはRubyとか。
それで満足したらラッキー！

でももし「もっときびきび動いてアクション系にも使えるスクリプトシステム作るんだ！」って思ったならば
「もっといろいろ機能削って手抜きして融通利かない特化・劣化バージョンを部分再発明して速度だけは上げるんだ！」っていうのと同じかと。
しかも既存のスクリプトシステムって描画にアセンブラとか駆使してたりするみたいだから追い越すの結構しんどそう。
そもそも追い越すんじゃなくてゲーム作りたいんだし、全然楽になってないと思う。

やっぱ真正面からコード上での対策をどうにか考えた方が良いかと。
そして私にも教えてください！私も知りたいですその対策！！マジで！！！

#「スクリプト作って！」って誰かに頼まれたのならやってもいいかも。
#でも、「お前プログラム作るの遅いし出来もつまんねえから俺が制御書くわ、どいてろ！」って言われたのと同義じゃね？
#「なんでもいってみろ！俺がすぐ実装してやる！」くらい言いたくね？　なんかくやしくね？

>>373
「ハード」ウェアに適した構造を参考にすると「ソフト」に動けなくなると思う。
ハード側に合わせたデザインパターン（Commandパターン）って決まりきった処理しかできないと思うよ。

392 ：名前は開発中のものです。：2008/06/16(月) 22:43:37 ID:HtcJzfTs

書き込む文章間違えた

>>372
タスクシステムは最初の1, 2ヶ月は結構すいすい設計進むけど、
その後は体調が絶好調の時に少しだけ機能追加ができる程度にまで
作業効率が落ち込む。
お勧めしない。

でも自分はバージョン２でやったんだけどバージョン１はもうちょっとやりやすいのかもね。
3,4ヶ月位はなんとか持つのかも。グローバル変数の弊害の壁まで。
どっちも人海戦術じゃなきゃ小規模なゲームしか作れなさそうだけど。
（作業効率の低さから来る気力の減衰度合い的な意味で）

393 ：名前は開発中のものです。：2008/06/16(月) 22:46:17 ID:PSleqKIe

>>373
過去にタスクシステムライクと称する何かをシーングラフ的だと表現した人間がいたが
あれも結局はシーングラフ的ではなくシーングラフそのものだった。
タスクシステムというカビの生えた古のローカル用語を無理やり持ち出す必要性が
微塵もなかったのね

394 ：名前は開発中のものです。：2008/06/16(月) 22:54:33 ID:Vsm26JrC

シーングラフとかFSMとか
タスクシステムのパクリ元となる技術もどんどん紹介して欲しい

395 ：名前は開発中のものです。：2008/06/16(月) 23:01:28 ID:PSleqKIe

>>387
>>388
それが何でタスクシステムと呼ぶのか分からないんだが。
↓の要件を満たしているのか
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

>>387、>>388はエンティティのリスト巡回UPDATEとか僕のforeachをする機構だと思うが
それが何でわざわざタスクシステムなどというカビの生えた古のローカル用語を発掘して
再利用する行為と絡められるのかが分からないんだ

396 ：名前は開発中のものです。：2008/06/16(月) 23:18:51 ID:HtcJzfTs

>>376
自分もきまぐれに作ってるのですが、タスクシステム単体じゃきつかった。
今はこんな感じでどうにかうまくまとまらないものかなぁと考えてます。
class Game {
private:
　Player player;
　std::list<EnemyBullet> enemy_bullets;
　std::list<Gozzila> gozillas;
　std::list<MechGozzila> mech_gozillas;
　...
public:
　onFrame()
　{
　　　foreach behavior (tasks) {
　　　　　behavior.execute(game_objects);
　　　}
　}
（続く）
#コード書くと改行制限がががが

397 ：名前は開発中のものです。：2008/06/16(月) 23:20:13 ID:PSleqKIe

>>394
パクリ、パクられという話をしてるのではないのねー
GoFの権威や教条を素直に受け入れるだけの度量があるなら、他の権威や教条の産物
計算機科学の分野で公知の技術用語も公平に幅広く受け入れてもいいと思うのね

タスクシステムなんていうカビの生えきったローカル用語にいまさら無理やり存在価値を
見出そうとするのは、何らかのカルトか、単に頭の引き出しが小さいかのどちらかだと思うのね。
総本山ですら既に使ってない廃れた言葉だなんて知ったら信者はきっと発狂すると思うけど
勉学に励む若い子は我に返ってもっと見識を広めていったほうがいいと思うのね

398 ：名前は開発中のものです。：2008/06/16(月) 23:20:20 ID:HtcJzfTs

（続き）
　onInit()
　{
　　　tasks.push_back(new Player_EnemyBullet_Hit(&player, &enemy_bullets));
　　　tasks.push_back(new Player_Gozzila_Hit(&player, &gozzilas));
　　　tasks.push_back(new Gozzila_MechGozzila_Hit(&gozzilas, &mech_gozzilas));
　　　tasks.push_back(new InputPad_Player_FPSBattleScene(&inputmgr->get_pad(), &player));
//　　　tasks.push_back(new InputPad_Player_Field(&inputmgr->get_pad(), &player)); //切り替えはこんな感じでできたらいいなぁ
　　　...
　　　tasks.push_back(new Player_Render_Draw(&player, &render));
　　　tasks.push_back(new EnemyBullets_Render_Draw(&enemy_bullets, &render));
　　　...
　　　tasks.push_back(new Render_D3DDevice_Sort(&render));
　　　tasks.push_back(new Render_D3DDevice_Render(&render, &d3ddev));
//　　　tasks.push_back(new WaitNextFrame()); //onFrameもいらなくできる！？
　}
}

タスク（というかCommandパターン？Iterator？）が生き残ってるとこがこのスレ的に
おいしい落としどころ

399 ：名前は開発中のものです。：2008/06/16(月) 23:23:17 ID:HtcJzfTs

>>395
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html
はなんかIEで見れないので今Firefoxインストール中です。
まだ見てないのです。

400 ：名前は開発中のものです。：2008/06/16(月) 23:26:55 ID:HtcJzfTs

明日はさすがにもう遅刻できないので
もう落ちます。明日見ます。

401 ：名前は開発中のものです。：2008/06/16(月) 23:29:52 ID:HtcJzfTs

>>397
やっぱりカッコヨス

402 ：名前は開発中のものです。：2008/06/16(月) 23:31:05 ID:PSleqKIe

>>399
文字エンコードがshift-jisなのねー
表示→エンコード→日本語（Shift-JIS）で見れるのね

403 ：370-373：2008/06/16(月) 23:46:38 ID:rSqKWN6I

>>385
>それはタスクシステムライクではなく、もっと別の、より適切な呼び方があると思うのね。

じゃあどう呼ぶべきかな。Gems漁れば何かあるかな？

>ライクとか擬似とか現代風とかのバリエーションを唱える人間は過去に何人も見たが
>どれも新たな俺解釈俺定義俺拡張でしかなく、10レス先にはそんなもの誰も覚えてないのね

バリエーションというよりは、例のURLの「タスクシステム」でできること、やりやすいことを
少なくとも犠牲にせず、タイプセーフなモダンな環境で実装する、というのが
方向性かなと思う。
ただし、環境全体の高速化があるので、速度面・メモリ面でいくらか妥協するのは問題ないと思う。

そういうものが既に存在するなら是非紹介してほしい。
おそらくちゃんとゲーム作ってるメーカー内ではそれらしきものがあるはずだけど。

404 ：名前は開発中のものです。：2008/06/16(月) 23:48:35 ID:7mOquyOO

このスレの空気は、庭先で日曜大工なお父さんが
近所のガチムチ現役大工に相談に行ったら本気で説教されてる感じだな

日曜デザインパターン教室を誰か開講汁

405 ：370-373：2008/06/16(月) 23:57:04 ID:rSqKWN6I

>>389
>「他の物と一緒くたにするにはおさまりが悪い」と言える。
当時のシステムでは、「キャラ」「地形」「エフェクト」みたいに、それぞれクラスがあって、
>>379 で書いたようなものはうまくその中に入らなかったんで、
他のクラスのメンバに入ったりとか、独立した関数コールとかになっちゃってたわけだ。

でも、「画面表示を持っていて、処理を持っていて、親子関係がある」
という物体のリストには、案外うまくおさまるのではないか、と。

406 ：370-373：2008/06/17(火) 00:11:38 ID:4bQeTGvs

>>391
えっと、スクリプトの話はあまり深くいきたくなかったので括弧で囲ったのね。
まず、スクリプトのVM自体を自作はしないっす。
上のほうで少し出てるけど、タスクの処理をマイクロスレッドで書いたら楽だよねっていうあたりを
追求してみているところです。

ただし、スクリプト・マイクロスレッド特有の書きやすさの点を除けばC++で実現可能なものなので、
ここではそっちの話をしたいなと。

> >>373
> 「ハード」ウェアに適した構造を参考にすると「ソフト」に動けなくなると思う。
> ハード側に合わせたデザインパターン（Commandパターン）って決まりきった処理しかできないと思うよ。

Windowsの上でHWND使って実にさまざまなことが実現されていると思うんですよ。
あと概念として参考にしているだけで、パクっているというわけではないです。
ゲームの実装がもっと簡単になるようにっていうのが方向性です。

どの部分を「ソフト」にするかというのがC++での抽象化の腕の見せ所じゃないですかね。

407 ：名前は開発中のものです。：2008/06/17(火) 00:50:27 ID:GN/jFPWe

>>395
ゲームオブジェクトをタスクと捕らえてそれを管理する機構を総称してタスクシステムって呼んでるんでしょ。
そんな風にLogicianLordのタスクシステムにばかり固執してるのはおじさんだけだと思うよ。
皆、ゲームオブジェクトの効率的な若しくは面白い管理方法を探るためにこのスレを見ているのだと思うし、
ただ「タスクシステム」という言葉をさげしむ文章なんか見てもノイズと一緒だし意味ないから辞めてね。

408 ：370-373：2008/06/17(火) 00:53:04 ID:4bQeTGvs

>>393
自分もこれまで、「タスクシステム」とか、うぜえ！C++のほうがいいやん！って思ってたほうなんで、
気持ちはわかるんだけど、そこそこ経験積んでからよく見直してみると、
なかなかゲーム特化で工夫されてるなと思うもので。
（ただし、メモリ節約、CPU節約については現代ではそこまでやらんでもと）

なので、「タスクシステム」が結局どういう要素によって構成されていたか、
という考察もなしに捨て去るには惜しい概念だと思うのですよ。
とっくにそれは終わっているというのであれば、どっかまとまった資料が必要かと。

その上で、完全に旧タスクシステムを上回る能力を持つライブラリ・フレームワーク、
もしくはそれを構築するためのノウハウが存在しなければと。

で、まずは >>370 あたりが叩き台にならないかなと。

409 ：名前は開発中のものです。：2008/06/17(火) 00:58:39 ID:Y/642oqK

>>408
ならんでしょ。

> ・タスククラスから派生した形でゲーム内のほとんどのオブジェクトを実装する
これやると、基底クラスが超リッチになるのがオチ。一般的には、実装継承せずに
インターフェースを多重継承しといた方が変更しやすい。

410 ：名前は開発中のものです。：2008/06/17(火) 01:19:58 ID:GN/jFPWe

前にGems5を立ち読みしてて「コンポーネントベースのオブジェクト管理」ってのがちょっと気になったんだよな。
参考になるかは分からんけど気になる人は読んでみてくれ。
日本だと殆どヒットしないから海外の関連リンクでも張っとくわ。
http://www.google.co.jp/search?hl=ja&lr=&q=%22component+based+object+management%22&start=0&sa=N

411 ：名前は開発中のものです。：2008/06/17(火) 01:38:18 ID:MdkHWajA

明日も遅刻しそうなのに頭がかっかして寝られない。

>>406
ほんとごめんなさい。
391は無かったことに、もしくは392の後に括弧つきの蛇足として書いたものとして
受け取っていただけるとありがたいです。

>>403
会社のコードを2chにさらすとか普通道義的にできない。
コードじゃなくて言葉でさわりのヒント出すとか、
批判して初心者遠ざけるよう仕向けるとかしかできないと思う。

412 ：名前は開発中のものです。：2008/06/17(火) 01:44:23 ID:MdkHWajA

>>395 （ども、見れました）
オリジナルの存在を知った後ならば１つの歴史を上書きして消すのは忍びないとか、
別の言葉にしようかなと感じるところはある。

でも「タスクシステム」は既に定義された言葉なんてことを知らなければならないなんてことはない。
仕事をする単位の名称としてTask, Process, Job, ...いろいろあるなかでたまたまTaskを選んで、
どこかでみたタスクシステムという名前が「かっこいいから」という理由だけで
俺プロジェクトに採用されても不思議ではない。下のようにスコープが異なる。

ギャラクシアン() {
　　タスクシステムは TCBリスト;
　　...
}
俺様ゲームシステムその1() {
　　タスクシステムはエンティティのリスト巡回UPDATE;
　　...
}
俺様ゲームシステムその2() {
　　タスクシステムは僕のforeachをする機構;
　　...
}
タスクは仕事Windowsでも「タスク」マネジャーという名前で一般的に聞きなれている。
その聞きなれたことばを使った「タスクシステム」という響きはネーミングとして魅力的。
中身とか別にどうでもいい。あとそもそもギャラクシアンって何？（的な世代）
私がはまったのもリスト巡回UPDATEであって、TCBリストではない。
カルトな人でもいまさら新規でTCBリストにはまりこむ人いない。もう問題ない。

413 ：370-373：2008/06/17(火) 02:12:32 ID:4bQeTGvs

>>412
まあ、なんとなくあなたが「タスクシステム」という名前でforeach{ update() } に
妙にこだわっている点が見えたので >>370 を書いてみたわけだけど。

TCBリストが古い手法だというのは認識した上で、
それを現代C++の上で実現する手法の一部として、リスト巡回updateが存在して、
それを含むオブジェクト指向風味の方法を駆使して
旧タスクシステムを含むいにしえの技の持っていたメリットを享受する、そしてデメリットは排除する。

そういう流れの中で話をしたいかな。僕は。

414 ：名前は開発中のものです。：2008/06/17(火) 04:01:27 ID:JZDPJ/Qk

>>403
え、ただのゲームループでしょ

>>412
＞タスクは仕事Windowsでも「タスク」マネジャーという名前で一般的に聞きなれている。
＞その聞きなれたことばを使った「タスクシステム」という響きはネーミングとして魅力的。
＞中身とか別にどうでもいい。

うむ。これがタスクシステム厨の実態、本音だろうな。正直なのは評価できる。
タスクシステムというネーミングへのこだわりは中二魂を心地よく刺激するから。
ただそれだけなのだ。お子様の言葉遊びだということが鮮明になるのは良い

415 ：名前は開発中のものです。：2008/06/17(火) 04:16:34 ID:fUrGiP0Z

「タスクシステム」という呼び方が気に入らないだけなのか？

416 ：名前は開発中のものです。：2008/06/17(火) 04:25:44 ID:JZDPJ/Qk

>>411
会社のコードを2chにさらすのは同義的な問題ではなく
一般的に労働契約の中で秘密保持義務を課しているから。
公知の技術情報をダラダラ書く分には何の拘束も受けない

417 ：名前は開発中のものです。：2008/06/17(火) 04:36:03 ID:JZDPJ/Qk

>>415
タスクシステムは、とあるゲーム会社の特定のスタッフ同士だけの固有名詞だった。
具体的な「実装」にわざわざ「名前を付ける」この行為は、例えば自作のコンバータやエキスポータに
「減色くん」とか「モーション平滑くん」とか「圧縮番長」とか「ニ○マ○イザー」とか
「エターナルフォースブリザードシステム」とか命名する程度の遊び心。洒落なんだ。

身内でどう呼ぼうが自由であるし好きにすればよいんだが
何の事前説明もなく公衆の場で「これはエターナルフォースブリザードシステムですね」
とか語り出す人間がいたら頭がおかしい人だと思うのは当然の話だろう

418 ：名前は開発中のものです。：2008/06/17(火) 04:37:22 ID:JZDPJ/Qk

×スタッフ同士だけの固有名詞だった
○スタッフ同士だけで使っていた何かの固有名詞だった

419 ：370-373：2008/06/17(火) 04:51:23 ID:4bQeTGvs

>>414
>え、ただのゲームループでしょ

リンク辿ってみた？
>>412 の人の呼ぶ「タスクシステム」の話じゃないのでよろ。
それともあなたの言う「ただのゲームループ」は実は相当に洗練されたシステムのことなのか？
だったら詳しく教えてくれ。

420 ：名前は開発中のものです。：2008/06/17(火) 04:53:47 ID:ZH96Nhjs

>>417
実装に名前を付けるのが「デザインパターン」なんだぜ。
タスクシステムではなく、○○パターンと名付けてあげれば
みんな納得するかもしれない。

というわけで、俺が名前を考えてあげた。
タスクシステムパターン(笑)

421 ：名前は開発中のものです。：2008/06/17(火) 04:56:55 ID:JZDPJ/Qk

ゲームの基本的な仕掛けはFSMの相互作用をシミュレートすることなんだ
仮想空間内に配置されたエンティティ(FSM、自己駆動粒子)同士の相互作用を
固定時間刻刻みの数値積分している

ところで科学技術計算の分野、特に分子動力学の分野では70年代よりずっと前から
近傍分子同士の相互作用を、運動方程式や支配方程式を離散化して適当な
差分スキーム（ゲームならオイラー法とかベルレ法ね）を選択して数値積分することで
分子の振る舞いをシミュレートしたりしていた
その基本的な実装はリスト内の要素を巡回しながら数値積分していくもので
近傍探索コストの削減と並列計算のための階層型領域分割なども昔から行われていた。
ゲームにおける要素は自分の意思で自在に動くという特殊なものだが、巡回しながら
UPDATEしていくという点で分子シミュレータのそれと基本的な構造は同じだ

422 ：名前は開発中のものです。：2008/06/17(火) 05:09:18 ID:JZDPJ/Qk

現在ではFSMアプローチの数値解析手法は様々な分野に応用されている
ライフゲームしか思いつかない人もいるかもしれないが、流体、粉体
車の渋滞、大規模災害時の火災、などなど、例をあげればきりが無いが
それらはどれも時間ステップ毎に要素巡回UPDATEしてループする
プログラムでありゲームのそれと基本的に同じだ。FSMの基底に
記述されたインターフェースの仕様も、誰が書いても大差ないものだ

423 ：名前は開発中のものです。：2008/06/17(火) 06:01:08 ID:fuXKuiFY

連投規制にかかった

ゲームのそれと酷似した基本構造のソースコードがあらゆるジャンルで日々作られてる。
そうした事実は井の中の蛙にしてみれば無視しても済ませられるどこか遠い世界の話
なのかもしれない。だが、君らのような懸命なるゲーム開発者にとってはどうなのか。
別に他所の分野の流儀に何が何でも批准しろと言ってるのではない。GoFのそれを
知識として受け入れる脳容量があるなら、もう少し他の分野ものぞいてみてはどうかと

>>420
そうだ。そしてGoFのデザインパターンがなぜ通用するかというとそこに権威があるから。
タスクシステムパターンを普及させるにも権威が必要だな。権威による布教がなければ
エターナルフォースブリザードシステムと同じカーストから抜け出すことは決してない。
名無しのタスクシステム厨は権威なんて要らんと強がるだろうが、まぁ強烈なカルト教団なので
信者同士で「普及してる！普及してるよー！」と幸せ回路発動してホルホルするくらいはできるが
その先はない

424 ：名前は開発中のものです。：2008/06/17(火) 06:02:06 ID:fuXKuiFY

話はそれるが、技術情報を発信し布教する権威としての日本人ゲーム開発者は少ない。
布教といえばカーマックたんだが、彼率いるID Softwareが公開してるMOD開発用ソースや
フルソース内のコメントに散見される彼ら流の造語の数々は海外MODコミュニティに限らず
広く普及し認知されてる。エンティティ周りのソースを眺めながら参考にしてみてはどうだろうか？

そんなわけでゲームプログラム関連の公知の技術用語の大半は海外発だ。（別にどうとも思わないが）
CEDECで日本人も沢山情報発信してるけど主催してるCESAは各セッションで使われたスライドの
PDFを参加者以外には配布しないし講演者の多くも自らのサイトで再配布することに積極的でない。
彼らは「布教」とか「提唱」することにあまり興味がないのかもしれない。（別にどうとも思わないが）

425 ：370-373：2008/06/17(火) 10:32:05 ID:4bQeTGvs

>>421
その例では均質な粒度の物体を扱うことに特化しているように思うので、
ちょっと問題領域が単純化しすぎるのではないか。

>>422
離散シミュレーションとかいう領域のものかな・・・
あれは見た感じ非常にゲームライクな見た目のものだよね。シムシティとかそんな感じで。
そういう意味では、ゲームと同様のシステムが有効に使えるのもありうる。
ただソースコードレベルの実装手法がそこらに落ちてるかどうか？

ゲームでは、「シーン」のような大きな粒度まで扱えるシステムであるべきと思う。
それとシミュレータではGUI的なものは扱うデータの範囲の外かもしれないが、
ゲームではそれらもやはり同じ枠の中で扱えるとベター。

>>424
今ちらっとquakeまわりのソース見てみたんだけど、
ネットゲーだとエンジン側はGUIとかエフェクトとかを無視して実装できるから、
上記シミュレーションと似たような状況ではあるね。
quake2 engine: edict_t（？）　　quake3 engine: gentity_t（ゲームエンティティ）
どちらにしてもモンスターとプレイヤーを扱うもの。あとソースはC(not C++)。

今後のゲーム用フレームワークは、ネットワーク化を常に念頭においた構成になっている
必要があるのかもしれないが・・・。

欧米製のゲームで、ボタン・ウィンドウとかインタフェースまわりにファンシーな効果がついてることが少ないのは、
「タスクシステムライクなもの」の不在のせいもあるんじゃないか、と思ったりするわけよ。
まあ、ゲームの本質じゃあないにせよ、日本人は手触りを重視するし。

426 ：名前は開発中のものです。：2008/06/17(火) 14:20:10 ID:uHMmvplh

ここはタスクシステムのスレだし、タスクシステムでいいじゃねーか。
外でタスクシステムについて知らんやつに使ったら、スルーされるだけだ。
俺はデザインパターン知らないからスルーしてるがな。

…デザパタ本買ってこよう。

427 ：名前は開発中のものです。：2008/06/17(火) 16:13:08 ID:OzqeTbhG

>>426
古いし情報も少ないけど話をあわせるには十分かも。
ttp://www.objectclub.jp/technicaldoc/object-orientation/handbook
1～3だけあればいいんじゃね。実装例はぐぐるとたくさん出てくる。

428 ：名前は開発中のものです。：2008/06/17(火) 22:41:30 ID:MdkHWajA

>>410
ttp://www.radiumsoftware.com/0307.html#030702
ここにそれっぽい記事が

429 ：名前は開発中のものです。：2008/06/18(水) 00:40:55 ID:tfU1zVm/

>>414
たしかにゲームプログラムって描画まわり以外は
あんまりきっかりとした名前の付いた技術ってないからね
タイトルがあって公式があって・・・って参考書にでもできそうな
もんにすがりたいのはわかるな

実際はなにもねぇけどなｗ
ファイルが読み込める、文字列が処理できる、計算式をプログラムで表現できる
とか地味ーで言葉にするのも難しいぐらい小さく当たり前なことが積み重なって技術を構成してるからな
だから、毎日勉強してる奴としてないやつとで差がついたときにその差が表現できない

長年PGやってるやつでもこれがわからない奴をよく見る
だから、よく春になると
「ゲー専卒PGなんか無意味、PCなんか使ったことなくても大卒なら１年で・・・」
とかいう言葉が掲示板で飛び交うけどこれもそんな気がするだけで
いかにゲー専PGであっても積み上げたもんがたしかなら１年そこらで追いつかれることはほとんどない
名称のある技術を一通り教えてすべてを教えた気になってもやはり戦力にはまだならない

つまり、何が言いたいかというと

「あんまり、見えるもんにばっかりすがってても良い事無いぜ」

ってことよ

430 ：名前は開発中のものです。：2008/06/18(水) 00:44:09 ID:o+kcLTJo

>>3 のページを見て自分的に見習いたい点、考えるべきと思う点
・小さくて単純な関数をたくさん作ろう
・グローバル変数は使わずにワーク領域を使う（自前メモリ管理のnew, deleteを使うと同義？）
・他タスクへの読み書きの方向性は制限をつけること
・シーン管理、当たり判定、入力管理、得点管理、プレイヤーの死亡判定などもワーク単位を使用する。
　また、同一の実行優先度決定機構の仕組み上でその実行順序を規定。
・タスクリストは抽象クラスのリストでもあるし具象クラスの複数のリストでもある点。
　タイプセーフにどう実現したら良いのか。リスト複数本持つ？
　そうするとリスト巡回アップデートや複数リストにまたがるインタフェースの一括実行はどうする？
・他タスクに影響を与えるタイミングはフラグセットしてタスク巡回完了後に一括反映などする、削除も同様。

改善すればどうにかな点
・ワーク単位によるキャラクタ表示手法の標準化（アニメーション含む描画の簡単化、代償としてワーク領域１つにつきキャラクタ表示１個の強制）

どうだろか

431 ：名前は開発中のものです。：2008/06/18(水) 03:56:14 ID:+evL1k5Y

まずタスクという言葉を使うのを止めることから始めようか

432 ：名前は開発中のものです。：2008/06/18(水) 07:33:30 ID:AwUC+HJR

>>425
＞その例では均質な粒度の物体を扱うことに特化しているように思うので、
＞ちょっと問題領域が単純化しすぎるのではないか。

それはちょっと見当違いだな
微視的な現象から巨視的な現象までを関連付け統合するマルチスケール・
マルチフィジックスのシミュレーション技法は、局所集中豪雨予測から核爆発
シミュレーションに至るまで、様々な分野で必要とされ研究・開発・運用されてる

433 ：名前は開発中のものです。：2008/06/18(水) 07:39:16 ID:AwUC+HJR

>>429
＞（前略）
＞とか地味ーで言葉にするのも難しいぐらい小さく当たり前なことが積み重なって技術を構成してるからな

まで読んだ。同意だな

434 ：370-373：2008/06/18(水) 07:41:01 ID:rJprML7o

>>428
そこから辿った
http://www.gamearchitect.net/Articles/GameObjectRoundtable.html
がおもろいなー。

ゲームオブジェクトリストがシーングラフをポイントしているようなハイブリッドシステム
＋実装派生をできるだけせずに、コンポーネントもしくはプロパティシステムを使う
というのがわりと中庸なところなんだろうか。

これは2003だから、それから変化しているだろうか・・・

435 ：名前は開発中のものです。：2008/06/18(水) 07:51:23 ID:AwUC+HJR

>>430
＞どうだろか

カルト教団にとっては理想的カモネギ

436 ：名前は開発中のものです。：2008/06/18(水) 19:41:01 ID:o+kcLTJo

>>435
タスクシステムを使いたい理由を挙げたとかじゃなくて
どうにかタイプセーフに実現すれば使いものになりそうな点を
挙げてみたつもり。

次の２点をどうにかタイプセーフに実現すれば連鎖的に他のもものになりそうな雰囲気を感じる
・小さくて単純な関数をたくさん作ろう
・オブジェクトからオブジェクトへのデータの伝播の指定方法

なんとなく、オブジェクトという表現がダメな気がする。タスクでも違う。
「データ＋処理」の出力を他の「データ＋処理」に伝播させる手法という表現の方が
なんかしっくりくる。古くさくて汎用的な匂いを感じる。
STLだったかのデータ構造とアルゴリズムの分離、直交性とかにも同じものを感じる。

あとオブジェクト間の通信で各オブジェクトがシングルトンに依存するのも
なんとなくダメな気がする。トンが豚を連想させて嫌。かっこ悪い。
リスト巡回アップデート的なやり方の方が名前がなくてかっこいい。
空気のように当たり前な技術って感じ。

437 ：名前は開発中のものです。：2008/06/18(水) 20:43:44 ID:AwUC+HJR

＞かっこ悪い

あー、把握した

＞オブジェクトからオブジェクトへのデータの伝播

それはそんなに難しく考える必要のあることなのか？

話の簡単のためオブジェクト＝エンティティという前提で話をする
（オブジェクト＝インスタンスでは一般化に過ぎるので話しづらい）
ゲームで個々のエンティティのUPDATE処理といったら、その内容は基本的に
「外部からの作用（衝突等）」と「内部からの作用（車輪や手足の駆動等）」の
合成結果を算出して自身のパラメータ（位置・姿勢・速度）をUPDATEするだけだ。（基本的にはね

　外部との情報のやり取りは原則的に入力（読み込み）のみ
　＝外部への出力（書き込み・更新）は原則的には行なわない

この基本方針の上で、外部に直接作用を及ぼす（メッセージパッシング）する
何らかの仕組みを用意するけど、それは付随的なものでUPDATE処理の本質
ではない

438 ：名前は開発中のものです。：2008/06/18(水) 21:09:45 ID:AwUC+HJR

エンティティが外部に情報を晒す手段は、基本的にはアクセサ用意して終わり。
リードオンリーだから複雑な物にはならない。極端な話パラメータ直接参照でも良い。

で、各UPDATE処理では、自身に作用を及ぼすエンティティを探索するなんらの機構から
対象エンティティの参照（ハンドルでもアドレスでも良い）をゲットして、そいつから直接
位置・姿勢・速度などをゲット。自身の差分計算に反映。自身のパラメータをUPDATE。

439 ：名前は開発中のものです。：2008/06/18(水) 21:44:59 ID:AwUC+HJR

STGやアクションゲーみたいなインスタンスがバンバン飛び交うゲームの
中枢部分は基本的にこんなもんだ。2DでもSTGでもほとんど変わらん

さて、こんな初心者向けの戯言をダラダラ書いてんじゃねーよ老害消えろ
と怒りの「本物の猛者」とか「爪先立ち知ったかクン」も一部にいるかもしれないが
俺の直感だが、このスレでタスクシステムとかという怪しげな誘蛾灯に吸い寄せれてる
人間の大半はビギナークラスの趣味プログラマだろう
俺が会話の対象としているのはそういう基本がズタボロ暗中模索の迷える子羊。
何だかよく分からないけどタスクシステムすげーよ銀の弾丸だよオーパーツだよ
ありがたやーありがたやー、というかっこ悪いカルトの道にハマル前にもっと色々見てまわろう

カーマックたんのソースはでかすぎて食えないということなら
例えばABAゲーのソースとか参考にしてみてはどうだろうか
紅茶を片手にマッタリ読むにはよい教材だと思うよ

440 ：名前は開発中のものです。：2008/06/18(水) 21:52:47 ID:AwUC+HJR

×インスタンスがバンバン飛び交う
○エンティティがバンバン飛び交う

×2DでもSTGでもほとんど変わらん
○2Dでも3Dでもほとんど変わらん

441 ：370-373：2008/06/18(水) 23:47:03 ID:rJprML7o

>>439
しょうがないからABAゲームズ見に行ってみたよ。
Dは何だからC言語のソースみたら全部力技じゃねーか！古いせいだけど。

てんで、しょうがないからDのソースみてみたよ。
基本的に描画対象のものはActorの殻かぶせて、クラスごとにActorプールを作ってある。
moveとdrawメソッドがある。drawでは直接OpenGL描画関数を呼んだりする。
プールの中の要素は一括でdrawとかmoveを呼んだりできる。

親子関係とかはフレームワークレベルでは特になし。

XNAのやつもDのシステムをほとんど書き直した感じだけど、
ただShape（描画要素）がActorから分離しているのが見受けられる。
このあたりは「シーングラフとゲームエンティティは別物として扱うべき」という議論とやや符号している。

結局、ミニゲーム職人のソースとしては「らしい」けど、１つのミニゲーム以上のものを
柔軟に記述できるシステムには昇華していない。

で、カーマックたんのソースでQuake3より後の奴ってどっかにある？

442 ：名前は開発中のものです。：2008/06/18(水) 23:52:44 ID:AwUC+HJR

Doom3のMOD開発用SDKでおおよそのところは察することはできる

443 ：名前は開発中のものです。：2008/06/19(木) 00:11:37 ID:kYScmWrH

>>441
＞全部力技じゃねーか
＞（中略）
＞結局、ミニゲーム職人のソースとしては「らしい」けど

そゆことなのねー。開発規模に応じたコーディングスタイルがあるということなのねー

＞１つのミニゲーム以上のものを
＞柔軟に記述できるシステムには昇華していない。

それを本当に必要とする人間がここに果たしてどれだけいるのかってことなのね
万能の矛を切望し、柔軟性の名のもとにコード上での様々な概念の一般化
ロジックの外部化を進めていく果てには、それを効率的に運用するためのリソース
様々な支援ツール、極端な話ツクールに近いオーサリングツールの存在が
不可欠になるのね

さて、その環境を構築するための膨大なイニシャルコスト、これをきちんと見積もり
それを許容できるものと判断する個人開発者、趣味プログラマがここにどれだけ
いるのか、俺は常々疑問に思ってるんだよ

444 ：名前は開発中のものです。：2008/06/19(木) 00:28:44 ID:kYScmWrH

手段が目的になってるだと？ざけんなそれもまた趣味だ文句あんのかこの野郎お！
と心の中で叫んで10年計画でひとつのゲームをシコシコ作ってるマッチョ趣味プログラマも
もしかしたらいるのかもしれない

そういう変わり者にとっては大規模開発を前提とした仕組みを猿真似してホルホルするのは
とても楽しいことのかもしれない。厨と呼ばれようと変態趣味と蔑まれようが火病ることなく
ひたすらわが道をZUNZUN逝く個人開発者や趣味プログラマには心から敬意を表する

ただし、右も左も分からない健全なビギナーを、まるで王道楽土へ手招きするがごとく
茨の道に誘い込むのはちょっと趣味が悪いと思うのねー

445 ：370-373：2008/06/19(木) 00:32:01 ID:PvMuTsdq

>>442
さんきゅう。後でみてみるよ

>>443
イニシャルコストはあるかもしんないけど、それはそれ。

どういうシステムを作るとどういうイニシャルコストがあるかってことを考察すること
が無駄というわけじゃない。

イニシャルコストがあまり上がらないぎりぎりのソリューションもあっていいわけだし、
共通の土台があれば、イニシャルコストの部分を外部のライブラリ・ツールで担うって
可能性もありうる。

446 ：370-373：2008/06/19(木) 00:43:17 ID:PvMuTsdq

>>444
2chの読者層をあんま規定しないほうがいい。

ま、初心者が甘い汁だと思ったならそれはそれでいいんじゃ？
世の中にはそういうの他にゴマンとあるし。

ちゃんと何かまとまった知識になったなら、メリットもデメリットも紹介する場所はあるでしょ。

自分なんか、問題ある点ばっか先に書いて、なんだこれ使えねえって思わせるのが得意なほうだよ。
悪かったな！

447 ：名前は開発中のものです。：2008/06/19(木) 00:50:24 ID:kYScmWrH

>>445
＞どういうシステムを作るとどういうイニシャルコストがあるかってことを考察すること

そうなのね。
ところが、このスレと過去スレを適当に流し読みした中で、そうした極めて重大な話題
趣味プログラマにとっては最強のデメリットと言える部分に言及している信者は
全くと言っていいほどいないのね。無知というかカルトだからご神体に欠陥はないという
ことなのだろう

＞イニシャルコストがあまり上がらないぎりぎりのソリューションもあっていいわけだし

そうなのね。何事にも落としどころってもんがあるのね

448 ：名前は開発中のものです。：2008/06/19(木) 01:01:31 ID:twNSgHMm

>>438
あるエンティティが外部の情報を参照する際に
エンティティという枠より一段だけ汎用的な型で参照できたらいいなと思う。
EnemyとかPlayerみたいな型じゃなくて座標とか衝突範囲みたいな型。

全部のエンティティにget_position()とかget_hit_area()みたいなインタフェースを
実装するの面倒でいやん。特に全エンティティに共通のインタフェースのはずの
座標取得get_position()ができないクラスを後から作っちゃったとか、
参照してた先のエンティティが消えた（STGでプレイヤーキャラが死んだとか）というときに
(x=INVALID_POSITION, y=INVALID_POSITION)みたいな特別な座標データを用意するの汚いとか
そもそも座標を参照する前にエンティティの生存確認をやらないといけないとかが嫌。
外部エンティティの生存確認はそのエンティティの仕事じゃない気がする。

対策としてエンティティが別エンティティの情報を参照しにいくんじゃなくて、
エンティティが別エンティティに情報を流す（メソッド呼ぶ？）ようにしておいて
さらにエンティティ間に１段何かはさむ、
例えば情報元のエンティティから情報を取り出して
情報伝達先エンティティに与えるべき必要最小限度の情報（恐らく適度に汎用的な型で済む）
を抽出して情報を受け渡す（メソッド呼ぶ）とかしたらいいかなとか考えてる。
これなら参照先の外部エンティティの生存確認をエンティティでしなくてすむ。
間にはさんだやつが代わりに生存確認してset_target_position(x=?, y=?)
とかnot_found_target_position()みたいにメソッドの呼び分けしてくれたら楽そう。

特別な座標データ用意するとかしなくても済むし、エンティティ間の依存関係が
きれいに切れそうでより一層タイプセーフな感じにならないかなぁと。
でも >> 437 のやり方とは共存できなさそうだね。どうしたもんか。

449 ：名前は開発中のものです。：2008/06/19(木) 01:04:58 ID:kYScmWrH

>>446
＞2chの読者層をあんま規定しないほうがいい。

いやまぁここ２ちゃんだから、釣りぐらいさせてよ
君が信者でないというのは理解している。
岸で小アジ用の仕掛けを垂らしてるのに何故かマグロ（君）に釣り針ごと
もぎ取られてる状態だ

希望の獲物（ちゃんと痛い本物の信者）が正面から食いついてくれないので
がっかりしているんだ

450 ：370-373：2008/06/19(木) 01:17:36 ID:PvMuTsdq

>>449
笑っちゃったじゃないかｗ

つ [ ツンデレ乙 ]

451 ：名前は開発中のものです。：2008/06/19(木) 01:45:17 ID:kYScmWrH

>>448
＞外部エンティティの生存確認はそのエンティティの仕事じゃない気がする

そうね
エンティティ自身は自分自身や周囲のエンティティがどんなコンテナにぶち込まれてるか
なんて興味の対象外だから、例えば近傍探索とかは空間（ゲームワールド）に問い合わせる
形にしてもいい。ほしいのは自分に作用を及ぼす相手達だ

もっと単純化すればその相手達が自分に及ぼす作用さえ得られればそれで良いと言える。
力学的な作用が欲しいなら、必要な自身のパラメータ（位置・姿勢（形状）・速度など）を
世界に投げて、世界が作用の合成（外乱）を返す形でもいい

コンポジションで力学的特性をパックしているなら、その参照を渡す感じになるかもだ
World::GetPhysicalDisturbance( &_disturbance[OUT] , &m_PhysicalInformation[IN] );

自身が特殊な物理特性を持ってるならコールバック関数も与えてカスタム衝突処理を
与えてもいい。商用の物理エンジンとかを使ってるならもっと別の形になるかもだが

452 ：名前は開発中のものです。：2008/06/19(木) 23:53:49 ID:twNSgHMm

自分が今改善したいと思ってることってどうやら単純なことみたいです。
・キャストを使わない
・グローバルな変数、関数を使わない（自分的にはシングルトンも含む）
こういった入門書レベルのことを守ってプログラミングしたい。

恐らく「リスト内の個々のエンティティの巡回アップデート処理」と
それに伴うエンティティの過度な抽象化（自分的にはタスクシステムと言いたいけど我慢）
を廃止できさえすれば
「エンティティ間の情報伝達」も含みで万事解決できそうな雰囲気を感じてます。

いたずらにどこまでもきれいに属性分けをしたいわけではなくて
入門書レベルのことが守れてない状況に何か不自然さを感じて
そこをどうにかしたいのかなと自己分析。

>>451
> 世界に投げて、世界が作用の合成（外乱）を返す形でもいい
それだとシングルトン的なものにアクセスすることになりそうなので
逆に世界がエンティティにデータを与えるというのはどうでしょうか。
コードで書くと >>396 >>398 的な仕組みで、世界はエンティティの情報を
吸い上げて何かしら変換をかけた後にエンティティに情報をばらまくという
「エンティティ間の情報伝達」ルールのリストみたいな存在。

明らかな欠点とかが既に分かってるとかでも無ければ実際にコード書いて検討してみようかと。

453 ：名前は開発中のものです。：2008/06/20(金) 01:39:22 ID:4KlRF5cY

＞・キャストを使わない
＞・グローバルな変数、関数を使わない（自分的にはシングルトンも含む）

「“できるだけ”使わない」「使いどころを理解する」ということなら分かるが
もし全否定ということならばそれもまたある種の原理主義やカルトだべ

＞世界がエンティティにデータを与えるというのはどうでしょうか

ある種のゲームエンジンではそういう形になっている。各エンティティの
ユーザーUPDATE関数（コールバック関数）がエンジンから呼び出される際
ユーザーUPDATE処理（状況把握、意思決定、実行）に「使ってよい」情報
（の参照なりハンドルの）パックが渡される

454 ：名前は開発中のものです。：2008/06/20(金) 03:46:24 ID:Kj6Z9sWt

>>453
>「“できるだけ”使わない」「使いどころを理解する」ということなら分かるが
>もし全否定ということならばそれもまたある種の原理主義やカルトだべ
横から突っ込むけど
正直、面倒だからって理由以外でこれを破らないとどうしようもない
って状況がない

455 ：名前は開発中のものです。：2008/06/20(金) 07:33:11 ID:bUsBl1xz

これでもし>>454がタスクシステム使いだったりしたら分裂症確定だなｗ

456 ：名前は開発中のものです。：2008/06/20(金) 11:46:38 ID:JuaZocDQ

せっかく良い流れなんだからいちいち毒を吐くのをやめないか。
タスク厨が邪魔してるようにしかみえん。

これだけじゃなんなのでOSにおけるプロセス管理の例
ttp://www.linux.or.jp/JF/JFdocs/Linux-Kernel-Internals-2.html
ttp://www.linux.or.jp/JF/JFdocs/The-Linux-Kernel-5.html
ここの話とはかけ離れててわろた。

457 ：名前は開発中のものです。：2008/06/20(金) 13:08:39 ID:F9xtG57Z

>>456
OSを真似すると汎用的ではあるがそれ単体では何もできない
という特性も真似することになるわけで、
その上で動作するアプリケーションも作る必要が出てくる。
つまり >>443 のように膨大なイニシャルコストうんぬんという話につながる。

「OS->擬似OS->擬似OSその2->擬似OSその3->・・・」
丸投げ・先送りイクナイ！　美しくない！
*OS→C言語、擬似OS→独自スクリプトに置き換えても同じ

458 ：名前は開発中のものです。：2008/06/20(金) 13:48:47 ID:y1iWT4sI

そのコストに見合うような開発規模（市販ゲーム？）なら有用ってこと？

459 ：名前は開発中のものです。：2008/06/20(金) 14:21:33 ID:F9xtG57Z

>>458
そうなるんすかねぇ。自分は趣味だから知らない。
でも有用というよりそもそもOS無くて自分で作らないといけないとか
マルチプラットフォーム化のために素のOSをラッピングといった別の理由で
必要そうではある。
スクリプトも単純なものならプログラマじゃない人との分業に有効そう。

460 ：名前は開発中のものです。：2008/06/20(金) 21:58:27 ID:WIOtJeKV

>>456
毒吐くなと言いながら毒を吐くギャグですね
わかります

461 ：名前は開発中のものです。：2008/06/21(土) 01:31:56 ID:p4z3vLca

>>454
＞キャスト
具体的にはstatic_castやreinterpret_castで明示しないとコンパイラが激怒する型再解釈キャスト。
この手のキャストはコンパイラの型チェックを無効化し型付言語の利点の一つを台無しにするのだから
「危険」「悪手」「お下品」「低学歴」「野蛮」「極悪」「型レイプ」「アウトロー」「ハカー気取り（ﾌﾟｯ」と貶しても良い。
でもソースコードをいじるのが自分ひとりのような場合は、この手のキャストのはらむ危険性を管理するのは
容易い話なのね。メリットが上回れば使えばいいのね

＞グローバル変数、関数（シングルトン）
シングルトンが必要な時点で設計がおかしい（横着してる）という側面は当然あるのね
でもその場の思いつきやひらめきでゲームをサクッと一人で作っちゃうタイプのプログラマなら
身もふたもない言い方だが、設計で多少横着しても、それが手軽に簡素に作れる手段になるなら
使えばいいのね

462 ：名前は開発中のものです。：2008/06/21(土) 01:33:42 ID:p4z3vLca

ところで「タスクシステム」とか呼ばれていたものの実態って（Z80アセンブリ言語だから当然なんだけど）
型付き言語にとってはまさにカオス、フリーダム、小汚いハックのオンパレードなのね。

にも関わらず、このスレでは型付言語のルールや掟に緊縛されることに至福をおぼえる真性のマゾ
学級委員や風紀委員校則の守護者のごとき優等生発言を連発する融通利かない生真面目な
頭コチコチくんが「なぜかタスクシステム信者」だったりするから、頭がクラクラすることがある

463 ：名前は開発中のものです。：2008/06/21(土) 01:47:47 ID:p4z3vLca

「タスクシステム」とか呼ばれていたものの実態は型付言語にとっては悪夢そのものだ
凶悪なのは汎用ワーク。状態遷移でvptrを書き換えてメンバ変数の様相を一変させるようなものだ。
型付言語のポリシーを重んじる潔癖主義者や理想主義者や原理主義者は蕁麻疹が起きるだろ？

464 ：名前は開発中のものです。：2008/06/21(土) 03:04:07 ID:HRymmcX7

ActionScript の MovieClip クラスがこのスレで言われてる
タスクシステムそのものだよね。描画順やら親子関係なんか特に。

465 ：名前は開発中のものです。：2008/06/21(土) 05:24:18 ID:oOAxrRaT

>>462
・型付言語のルールや掟に緊縛されることに至福をおぼえる真性のマゾ
・学級委員や風紀委員校則の守護者のごとき優等生発言を連発する融通利かない生真面目な頭コチコチくん
これら一体誰を指して言ってんの？
>>461を見て思ったけど、君って、汚い言葉が好きで使いたいだけなんじゃないの？
ノイズと分かって言ってるんなら、いい歳こいた意地の悪い男にしか見えないのね。
釣りの為の餌と言い張るなら、君の場合はシャコがエビで釣りをしてるようなもんだと言っておきたいのね。

466 ：名前は開発中のものです。：2008/06/21(土) 06:30:24 ID:7UsNOBf3

風紀委員ｗ

467 ：名前は開発中のものです。：2008/06/21(土) 07:10:07 ID:3d8FYq+7

>>461
プログラムを組むことに限ってその２つを無視したら
他に何が残るのか聞きたい
つまるところなんにも制御できてないと思うのだが・・・？

468 ：名前は開発中のものです。：2008/06/21(土) 15:19:38 ID:NgLsg0my

釣りと称して現実の鬱憤晴らしてるだけにしか見えないな
開き直れば許されると思うな

469 ：名前は開発中のものです。：2008/06/21(土) 17:16:25 ID:v+oawE3O

まーた自治厨気取りがわいてきたのか

470 ：名前は開発中のものです。：2008/06/21(土) 17:58:33 ID:ZFImiquI

独自の文学的表現のつもりなんじゃね？
文字通り水増しするだけのこういう修辞は俺大嫌い

471 ：名前は開発中のものです。：2008/06/21(土) 18:25:54 ID:05YWsV/n

理詰めで論破できないとなると
もはや態度に文句付けるぐらいしか
やれること残されてないという典型

472 ：名前は開発中のものです。：2008/06/21(土) 19:16:28 ID:NgLsg0my

議論する気があるならいちいち相手を挑発したり議論対象を侮蔑してんじゃねーよ
論破以前の問題だ
下らない口喧嘩に付き合う価値があるか

473 ：名前は開発中のものです。：2008/06/21(土) 20:08:44 ID:5D4mni2Y

クリティカルヒットしたからノイズが気に触るんだろｗ
タスク厨煽り耐性なさ杉

474 ：名前は開発中のものです。：2008/06/21(土) 21:42:24 ID:NgLsg0my

いや、タスク厨もクソも俺ゲーム作れないし
議論するときはいつも相手を煽ってばっかな
ガキ臭い連中がいい加減見苦しいから口出しただけだ
やっぱこの板ダメだな

475 ：名前は開発中のものです。：2008/06/21(土) 22:25:29 ID:ENX9pxx5

釣りだと明言してるのに釣られてやる必要もないんじゃね。
逆に釣っているようでもあるが。

>>425
遅レスだけど初代シムシティならMicropolisの名前で公開された。

476 ：名前は開発中のものです。：2008/06/22(日) 03:37:50 ID:g/+3l4Gu

>>474
ついに乞食までタスク厨の加勢に入るほどの窮状ｗｗｗｗ

477 ：名前は開発中のものです。：2008/06/22(日) 08:15:51 ID:pEWm2Nvm

>>474
>俺ゲーム作れないし
>俺ゲーム作れないし
>俺ゲーム作れないし

こんなフナ虫まで誘引するパワーがあるのか。。。
やはりスレタイのタスクシステムというフレーズは捲き餌としては優秀すぎるな
構造スレと分離、隔離する理由が分かるよ

478 ：名前は開発中のものです。：2008/06/22(日) 08:35:48 ID:08uuS13S

そのフナ虫にたかってる連中が一番面白いｗｗｗｗｗｗｗｗｗ

479 ：名前は開発中のものです。：2008/06/22(日) 11:32:06 ID:EI+nCyeb

草は怒りゲージじゃないんだから
顔真っ赤にしながら何本も生やさなくていいと思うよ

480 ：名前は開発中のものです。：2008/06/22(日) 12:18:41 ID:jdJeFwFV

>452さんが考えているのはMVCに行きつくのかな。
ゲームの中に登場するものは受動的なMになって抽象的なCが主に処理する。
当たり判定はMediator、親子関係はDecorator、
ループ本体はInterpreterみたいな。

481 ：名前は開発中のものです。：2008/06/22(日) 12:28:29 ID:LfyAvz/j

>>474
＞俺ゲーム作れないし

もうこのフレーズだけで今日はおなかいっぱいです。
ごちそうさまでした。

482 ：名前は開発中のものです。：2008/06/22(日) 12:52:53 ID:rl6WJKHf

今からでも遅くないから
「多少プログラムをかじってるけど、ゲームは完成させたことは無い」
と言い訳すべき展開ｗ

483 ：名前は開発中のものです。：2008/06/22(日) 21:02:39 ID:PdqU/TQ3

確信犯チックな酔いしれぶりに突っかかりたくなるのは分かるがなｗ
そもそもこの板ってリア厨に毛が生えたような層が中心なのに、ここは専門用語地獄よのう

484 ：名前は開発中のものです。：2008/06/22(日) 21:08:17 ID:+Ow9MecJ

リア厨に毛が生えた程度の奴が専門用語だけ覚えて得意気に使うからこんな有様なんだろうな
社会に出てから「なにそれ？」って普通に言われたときに
また、専門用語使って説明しようとするくせがついてると一生誰からも相手にされないんだぜ（かなりマジで）

485 ：名前は開発中のものです。：2008/06/22(日) 21:09:53 ID:+Ow9MecJ

実は実際の開発云々よりもこういう
他人との擦り合せでどうしても譲歩できなくて辞める事態にまで
追い込まれて辞めてしまう奴が多い

486 ：名前は開発中のものです。：2008/06/22(日) 21:13:30 ID:PdqU/TQ3

>>484
専門用語が多いのはアンチタスクの方ね
俺含めタスク厨止まりは用語一つ二つ三つは出せてもあんなにペラペラにはなれんて

487 ：名前は開発中のものです。：2008/06/22(日) 23:28:02 ID:iMzzAhqf

>>486
道端に捨てられてたかリサイクルセンターで埃かぶってた粗末な壺を持ってきて
おぼえたてのオサレ（？）用語（GoFのデザパタ用語とか）でうわっ面をお色直しして
これぞ名器・現代的タスクシステム！とか称して初心者に薦めてる
マルチ商法まがいのペテン師みたいなタスクシステム伝道師もけっこういるけどね

488 ：名前は開発中のものです。：2008/06/23(月) 01:34:16 ID:1AZuU4qd

>>486
彼はアンチなのか？やたら事情に詳しくないか？

489 ：名前は開発中のものです。：2008/06/23(月) 11:08:36 ID:eH23AaRd

シューティングスレにタスク厨予備軍が沸いてるがあれでいいのかと・・・

490 ：名前は開発中のものです。：2008/06/23(月) 17:42:17 ID:xReDDG2i

彼は明らかにプログラム初心者だから最初は好きなようにやらせりゃいいだろ
そのうち利点と欠点に気づくだろう

491 ：名前は開発中のものです。：2008/06/23(月) 20:33:01 ID:FfEyNKqI

>>489
湧いてないよ。俺以外はみんな優しいオジサンばかりだから
あえて突っ込まずにヌルーしてるだけだ

>>490
全くだな。ったく誰だよあんな無粋な長文を書いてるヘタレ老害は

492 ：名前は開発中のものです。：2008/06/23(月) 21:14:33 ID:xReDDG2i

お前じゃねーかよｗ

493 ：名前は開発中のものです。：2008/06/25(水) 00:11:08 ID:+bhYeJa7

いつもケンカばっかりやってるけど、
500ぐらい消費してなんか結論でた？
タスクシステムよりマシな実装とか

494 ：名前は開発中のものです。：2008/06/25(水) 14:35:32 ID:1/WhRn+X

あらゆる問題を解決してくれる神なる万能の設計タスクシステムは永遠に不滅なり
という結論が出た

普通の人は目的のシステムに適した設計を行うということで

495 ：名前は開発中のものです。：2008/06/25(水) 18:19:57 ID:6DMytFeS

一億と二千年前から分かりきってる結論だな。

496 ：名前は開発中のものです。：2008/06/25(水) 20:50:45 ID:7UZCA8Xd

どうあれゲームをつくるはずが
なぜかライブラリや基幹の実装だけに固執して
そこから抜け出せなくなってるのは
求められるゲームが高度化しすぎたからしょうがないことなのかもしれないが
傍目になんとも痛々しいしなんとかしてやれないかと思うのであった

497 ：名前は開発中のものです。：2008/06/25(水) 21:27:54 ID:4PLXCLdL

一番元になっているタスクシステムの実装ってどうなってんの？
少なくとも当時のゲーム機レベルでベターな解にはなってるんだろうけど

>>496
ライブラリを否定して一から作り始める人ばかりだからこそ、皆がライブラリから作らねばならなくなるという矛盾
ここに日本人プログラマの均一化のカラクリがあると思うね
ライブラリ（ゲームエンジンやMODを含む）をバンバン利用して、あらゆる分野のプロフェッショナルが育つべき
そうでなければ、日本人は”タスクシステム”ばかり上手に作って、肝心のゲームが作れなくなってしまう

>>494
さぁ、ジャンル別のタスクシステムでも語ろうか

>>493
適材適所が結論になってそれ以上深化できないのがこのスレの弱点だな

498 ：名前は開発中のものです。：2008/06/26(木) 01:00:36 ID:+1tijvkd

積極的な意味での適材適所でしょ
タスクという個々のシステム内では意味をなさない
最上位の抽象性を現出させるために無理をするのはやめて
もっと特殊化しろと
特殊化したままにしておけと

499 ：名前は開発中のものです。：2008/06/26(木) 01:29:55 ID:8YxPUGQm

>>497
ジャンル別のタスクシステム（笑）

500 ：名前は開発中のものです。：2008/06/26(木) 09:03:56 ID:cU5ZU0T1

「神なる万能の設計」が皮肉であると
解釈できない人もいるということさ

501 ：名前は開発中のものです。：2008/06/26(木) 16:38:35 ID:7UeStfxm

Flashやらデジタルロケやらみたいな器を作るなら汎用性確保のためにいろいろ考えるが、
（ただしタスクシステム（笑）などとは絶対に名づけないぞ。シーングラフで考えたほうが適切だろ、常識的に考えて）
単発のゲームならどう考えてもベタにハードコーディングしたほうが速いし、目的に適うし、メンテナンス性も高い。

だいたい元のギャラクシアンのタスクシステム（笑）だって汎用性など確保できてないだろうに。
単に、アセンブリコードいろいろ最適化してたらいわゆるタスクのようなものになっただけだろ。
俺も16bit時代に弾幕シュー作ってて経験あるけどさ。

で、そんなのは今ならタスク（笑）なんてメタファーを使わなくても
普通にC++でオブジェクトをリストにすれば済む程度のことでしかなくて。
（タスクシステム（笑）オタに言いたいけど、C++の吐くコード見たことある？）
ギャラクシアンがやってたのだってその程度のことでしかなくてさ、
タスクシステム（笑）とかかっこつけてみても何か変わるわけじゃなくてさ。
根底には、目の前の複雑な題材に対して、何かエレガントな解決策があるという妄想があんのよね。

ねーから。あきらめろ。

根本的にさ、この21世紀にさ、8bit時代のゲームの実装を神格化するなよ。いくら名作だっつーても。
始まる前からフェードアウトしてるようなものだ。非科学的でいかにも日本人らしい。

502 ：名前は開発中のものです。：2008/06/26(木) 17:58:02 ID:gUTnFl6Q

長文書く能力があるんだから、
誰でも付けられる(笑)なんて付けずに、文章で論理的にバカにしろよ。

503 ：名前は開発中のものです。：2008/06/26(木) 18:34:49 ID:FnDc9wiB

>>501
> ねーから。あきらめろ。
科学なら存在しないことを証明する必要がある。
証明抜きにそう言い切ってしまうのは科学の発展を否定することで
ひいては科学自体を否定することになる。
どうせ証明できないだろうからここは「てめーに解決できるわけねーだろ」
程度に非科学的に煽っておくのが吉。

504 ：名前は開発中のものです。：2008/06/26(木) 20:19:07 ID:ymGJ8OUV

>>503
>証明抜きにそう言い切ってしまうのは科学の発展を否定することで
いつから数理論理学の話になってたんだ（ｗ

まぁ、正しくても証明不可能な命題も存在するから、「証明しろ」は強すぎ。

505 ：名前は開発中のものです。：2008/06/26(木) 20:25:54 ID:N5id5iTP

で、結局何を使えばいい？

506 ：名前は開発中のものです。：2008/06/26(木) 20:56:50 ID:Y4ULcr4V

507 ：名前は開発中のものです。：2008/06/26(木) 20:59:47 ID:GHU31vDd

>>505
Quake2のエンジンでも使えば

508 ：名前は開発中のものです。：2008/06/26(木) 21:00:41 ID:Y4ULcr4V

>>505
DarkBasic

509 ：名前は開発中のものです。：2008/06/26(木) 21:04:42 ID:Y4ULcr4V

>>497
＞一番元になっているタスクシステムの実装ってどうなってんの？

ギャラクシアン基板はROMデータにスクランブルかかってないから
基板買ってきてそいつのドータボード上のROM全部引っこ抜いてROMライタで読み出してみ。
面倒くさいなら嫌ならそこらへんのエミュ（ｒｙ。拡張子がuのやつから順に開始アドレスから
コード入ってっからディスアセンブラの出力結果を片手にMAMEデバッガでステップ実行
して観察すてみろ
ワーク用のメインRAMは4000H～47FFHの2KB。
OBJテーブル用のRAMは5800h～5FFFHの256バイト

OBJテーブルに書き込んでる周辺のコードがエンティティUPDATE処理をしてる
ここまで書いたら答えを書いたも同然だな

510 ：名前は開発中のものです。：2008/06/26(木) 21:24:11 ID:M7qb4NIE

要は超簡易LISPだろ

511 ：名前は開発中のものです。：2008/06/26(木) 21:28:12 ID:Y4ULcr4V

ところで、タスクシステムとか呼ばれていたナニを崇拝する若い子はZ80でもH8でもPICでも
何でもいいから組み込み用途のマイコンボードキットとか学習キットでも買って勉強してみそ。
あんなチマチマしたプログラミングテクに興味があるならゲーム制作趣味よりもそっち方面の
ほうが趣味の適正あると思うよ。そして行く行くはFPGAにチャレンジだ

512 ：名前は開発中のものです。：2008/06/26(木) 22:05:09 ID:Y4ULcr4V

>>509訂正
×5800h～5FFFH
○5800H～58FFH

513 ：名前は開発中のものです。：2008/06/26(木) 22:20:54 ID:gUTnFl6Q

それ、現在やろうと思う人がいると思って言ってる？

514 ：名前は開発中のものです。：2008/06/26(木) 22:29:38 ID:ymGJ8OUV

FPGAは大学の実習でやったな。そのあと、Verilog 使って論理回路設計。

今でもやってるんじゃないかなぁ。

515 ：名前は開発中のものです。：2008/06/26(木) 22:36:06 ID:ifi2KKCv

>>497
＞適材適所が結論になってそれ以上深化できないのがこのスレの弱点だな

適材適所は至極当然の帰結で
柔軟性と汎用性を兼ね備えた万能の槍、タスクシステムｗ
を夢見るタスク派が次々に勝手にホイホイ寄って来るんだから
話がそれ以上深化しないの当たり前

スレの弱点というよりタスク派の弱み、急所

516 ：名前は開発中のものです。：2008/06/26(木) 22:59:43 ID:gzo15sHF

プログラミングを始めた頃にやねうらおの本を読んだせいで
２Dゲームも３Dゲームもタスクシステムでやる、
タスクシステム病にかかってしまったのですが
何か解決策はないでしょうか

517 ：名前は開発中のものです。：2008/06/26(木) 23:11:23 ID:Im8BFapF

その病に実害が発生してないなら別にそれでいいじゃない。

518 ：名前は開発中のものです。：2008/06/26(木) 23:14:07 ID:FnDc9wiB

>>514
東大ですか？

519 ：名前は開発中のものです。：2008/06/26(木) 23:18:51 ID:ymGJ8OUV

>>518
本郷じゃなくて大岡山の方

520 ：名前は開発中のものです。：2008/06/26(木) 23:45:35 ID:ICzeg2Oh

タスクシステムの代案でC++とクラスによる多態の実装が提示されることがあるけど、あれはダメだ
関数ポインタに比べて自由度が低すぎる

521 ：名前は開発中のものです。：2008/06/26(木) 23:52:01 ID:ifi2KKCv

>>513
夏コミで糞ゲー出すのがせいいっぱいの高専生だけど
暇を見つけてはUSB-IF付PICで俺専用デバイス作って遊んだりしてるよ
ゲーム改造とか好きだからいろいろ自作しないとダメなんだな
アマゾンで検索すれば初心者向けの本がごろごろあるし
この程度の工作ごっこなら理系じゃ珍しくもなんともない
ロボコン参戦してる友人はもっと妙なことやってるが
そいつはツクラーでRubyヲタ
研究室にAlteraのFPGA評価ボードもあるけど
ちょっと高価なので指導教官（映像ヲタ）のオモチャとなっている

ど田舎暮らしの俺でもネット使えば世の中の趣味は更に多種多様
と気付かされるんだから、君もこういう電子工作の話を見たら
『現在やろうと思う人がいると思って』くれてもいいんじゃない？

あんま視野狭いこと言ってるとタスク派認定しちゃうよ

522 ：名前は開発中のものです。：2008/06/26(木) 23:55:00 ID:FnDc9wiB

>>519
どうも。公開してあった実習の資料を少し見たことがあったのでそれかと。
こちらは専門卒のしかも文系です。プログラムは実習で少し。

523 ：名前は開発中のものです。：2008/06/27(金) 00:00:16 ID:FqfIVInp

そういや高専卒の同僚もいろいろ濃いな

524 ：名前は開発中のものです。：2008/06/27(金) 01:10:21 ID:FqfIVInp

>>516
あの人は2Dの人なので3Dとか期待するのは酷だな
教科書としてではなく読み物として楽しんだほうがええ
shi3乙本と同じなの

525 ：名前は開発中のものです。：2008/06/27(金) 01:22:22 ID:iY75Ipwt

>>511
そんなの中学くらいでやってるだろ

自分も高専の土木工学科行ってたぜ
仕事は組み込みとかコンシューマー機(一作だけ)とかアーケード機とか普通の開発とかだけど

526 ：名前は開発中のものです。：2008/06/27(金) 05:25:31 ID:c7s41g/J

＞そんなの中学くらいでやってるだろ

そう？>>511の言う
「タスクシステムとか呼ばれていたナニを崇拝する若い子」って
まだそういうの見たことも触ったこともないタイプが多いと感じるけど

リア厨とかリア工の頃って無知でバカだから何かに神秘性とか魔術性を
感じて信じ込んでカルト的な盲目（俺tuee）状態に陥ることあるでしょ

中二病ってやつ？知らんけど

527 ：名前は開発中のものです。：2008/06/27(金) 05:33:30 ID:5eAHUy9m

>>520
C++だと、自由度というよりは、クラス１つ作るときの記述負荷が重いって感じはあるよね。

528 ：名前は開発中のものです。：2008/06/27(金) 09:11:03 ID:VKUOhqyG

>>520
メンバ関数ポインタも使えばいいじゃん。

外からオブジェクトを実行する
→抽象基底クラスの仮想関数を経由して呼び出し

オブジェクト内部での状態遷移
→メンバ変数にメンバ関数ポインタを持たせておいて、必要に応じて関数呼び出し
　（ふつー HSM にしておく）

両方ひとつにまとめるから、ややこしくなる。

529 ：名前は開発中のものです。：2008/06/28(土) 01:00:19 ID:UNOxry2I

>>528
HSMって何？

530 ：名前は開発中のものです。：2008/06/28(土) 12:31:24 ID:ts5IwU99

>>515
夢見るタスク派というより夢破れた元タスク派じゃね？寄ってきてんの。
話が深化しないのが弱点って暗に「適材適所って具体的にどう書けばいいんだYO!
もっと分かりやすく詳細Plz!!!」っていってんじゃね？俺も知りたい（ボソッ

531 ：名前は開発中のものです。：2008/06/28(土) 13:48:51 ID:GEGPJOTr

Finite State Machine(FSM)かね

532 ：名前は開発中のものです。：2008/06/28(土) 14:33:30 ID:vkQAURq2

「タスク」じゃなく「ゲームシステム総合スレ」ってないの？

俺はそっちが話したいし聞きたい
このスレけっこう有用な話もあるのに、結局「タスク」の名前がどうとか定義がどうとか
言い出す人が多くてぐだぐだになりすぎじゃね

533 ：名前は開発中のものです。：2008/06/28(土) 15:34:13 ID:kMfb3SsT

スレタイ読めないの？

534 ：名前は開発中のものです。：2008/06/28(土) 17:36:45 ID:BZan8oG/

>>531
Hierarchical (Finite) State Machine

535 ：名前は開発中のものです。：2008/06/28(土) 17:38:17 ID:oojg4rxt

http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/
ここじゃだめ？

＞ぐだぐだになりすぎじゃね
実はそういうことをやる隔離スレなんだよ

536 ：名前は開発中のものです。：2008/06/28(土) 23:36:49 ID:ypt1dnc7

>>530
＞適材適所って具体的にどう書けばいいんだYO! もっと分かりやすく詳細Plz!!!」

そういうのは初心者相談スレでどうぞ
タスクシステムという単語さえ出さなければ真面目に答えるよ

あとこれは技術系スレ全般に言える事だけど、何か質問するときは
タスクシステムって言葉は使わないほうが幸せになれるからな。
使えば「タスクスレでやれよ」で一蹴されるか、タスク厨（回答者）を
釣り上げる餌として流用されて質問者そっちのけでタスク厨狩りの
宴が始まる。俺は楽しいが

>>532
それはスレタイを恨みな

そういやゲームプログラミング相談室ってのがずーっと続いてたと思うんだが
いつの間にか消えてるな。まぁ相談スレは初心者スレ一個で済むからかな

537 ：名前は開発中のものです。：2008/06/28(土) 23:37:48 ID:ypt1dnc7

>>535
秀逸なレス

538 ：名前は開発中のものです。：2008/06/28(土) 23:49:11 ID:ArHCtpWP

つーか名前が嫌われてる理由かね
「タスク」は最早OS用語だし、「システム」なんて大きなプロジェクトぐらいにしか使われない。
実装当時はOSがないFC上だったから、名前に特に問題はなかったんだけど、
今のセンスで見たらちょっと大げさすぎるわなあ。

というわけで新しい名前でも考えようぜ！
リニアスレッドとかリニアルーチンとかどうよ。

539 ：名前は開発中のものです。：2008/06/29(日) 00:17:18 ID:PTdPx+yc

この際、スーパーミラクルシステム feat. タスクズ　(SMST)　とかで。

「でさー、ＳＭＳＴがさー」とか話をすれば、
大したことを言っていなくても
一見さんが付いてこられなくなって、笑えること請け合い。

540 ：名前は開発中のものです。：2008/06/29(日) 00:19:10 ID:4EzdzTPb

ここは「タスクシステム」という名称を憎むひとたちが集まるスレです
技術的な議論はスレ違い

って>>1に書いとけよｗ

541 ：名前は開発中のものです。：2008/06/29(日) 00:28:31 ID:Rdj68xcQ

>>540
そう書くと、こんどはホイホイに集めておきたい人間が来ないという罠。

542 ：名前は開発中のものです。：2008/06/30(月) 12:53:23 ID:HQPfJ2jg

ttp://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm
「タスク」で検索だ！

543 ：名前は開発中のものです。：2008/06/30(月) 22:35:46 ID:xObvUcvs

>>542
それ、社内での呼称は違うって事前に説明してたけどね
タスクシステムとは一言も言ってなかったから

544 ：名前は開発中のものです。：2008/07/01(火) 01:53:53 ID:Cy0nR/q6

ttp://www.typex.taito.jp/feature2.html
ミドルウェアとしてタスクシステムがついてくるらしいぞ
どんなもんだか興味はあるなｗ

545 ：名前は開発中のものです。：2008/07/01(火) 10:11:10 ID:7BxVFs3X

ActionScript 3.0の疑似マルチスレッドライブラリ「ActionScript Thread Library 1.0 (そうめん)」
ttp://www.be-interactive.org/index.php?itemid=385
ActionScript Thread Library 1.0 (そうめん) ドキュメント
ttp://www.libspark.org/htdocs/as3/thread-files/document/

546 ：名前は開発中のものです。：2008/07/02(水) 00:02:39 ID:1JjhbBAN

fladdict.netのamaznodeの出来損ないみたいなサンプルはまぁいいとして
擬似スレッドとかタスクシステムとか造語をボコボコいたずらに使ってるだけで
やってることは要するにユーザーレベルのスレッド。アプリ側で要素巡回（ポーリング）。
コルーチンとかマイクロスレッドとかファイバーとか言ってしまえばそれでお仕舞いだ

この手の単語を一度も使わずに解説してる辺りから察するに、1988年生まれの
フラッシャーがタスク厨だったというだけの話だろう

547 ：名前は開発中のものです。：2008/07/02(水) 12:44:16 ID:NhTLwzj4

>>546
スタック切り替えも行わないのに、スレッドとかコルーチンと呼ぶのは
違和感あるなぁ。

548 ：名前は開発中のものです。：2008/07/02(水) 13:41:58 ID:1JjhbBAN

あー、やってないの？
スレッドだって言ってるから当然やってるもんだと思ってたよ
つまり擬似スレッドですらないってことだな

549 ：名前は開発中のものです。：2008/07/02(水) 14:18:21 ID:NhTLwzj4

>>548
http://www.libspark.org/htdocs/as3/thread-files/document/

俺もソース読んだワケじゃないけど、サンプル見ると、どうみてもローカル
変数ではなくメンバ変数だよね。スタック切り替えてないっしょ。

public class CountThread extends Thread
{
public funciton CountThread(n:uint)
{
_n = n;
_c = 0;
}

private var _n:uint;
private var _c:uint;

override protected function run():void
{
trace(_c);
if (++_c <= _n) {
next(run);
}
}
}

550 ：名前は開発中のものです。：2008/07/06(日) 05:18:35 ID:wwvr6Qee

ちょっとデータ構造スレ覗いてみたら
なんかタスクとか日本がどうとか言って暴れてる人たちがいて
いたたまれなくなった
>>541 の言うことは本当だった・・・！

551 ：名前は開発中のものです。：2008/07/06(日) 05:44:51 ID:3zGp5pSD

見てきたけどデータ構造でもなんでもない話してるなw

このスレみたいに、不毛でもいいから技術について論争してるなら、
何か思いついたときに話題を振ってみるんだが。

552 ：名前は開発中のものです。：2008/07/06(日) 06:34:49 ID:XCulGsMF

すみません
実はアメリカ最高とか言ってた中の人は俺です。分類ではタスク厨なんです。。。
タスクシステム最高と思ってたらこのスレで視野狭いと言われてくやしくて。。。
俺をだましてた日本人の閉鎖性が憎い、おまえらが悪いって叫んだら
今度は自分の英語力の無さを日本人のせいだとか話すりかえてると言われて。。。
くやしいです。

553 ：名前は開発中のものです。：2008/07/06(日) 11:44:42 ID:cfpKXYBe

>>551
人を叩きやすいネタに人を叩くことで自尊心を満たそうとする連中が
群がってる感じだな。マスコミや国会でさえそんなもんだから
2chならしかたないさ。あの論争には俺も参加してるしｗ

554 ：名前は開発中のものです。：2008/07/06(日) 12:01:30 ID:i1S1gouX

おまいら･･･過疎化するよりましだがほどほどに。と、話についていけない人の意見。

555 ：名前は開発中のものです。：2008/07/06(日) 12:02:14 ID:HG7Vxq5Q

タスクシステムは最高です。
なぜなら、

　・　コンパクトである
　・　高速である。
　・　シンプルである。
　・　フラグメンテーションが発生しない。
　・　プロはみんな使っている。

以上の事から自明なのです。

556 ：名前は開発中のものです。：2008/07/06(日) 16:43:12 ID:NyEm8bIu

ちょっと質問。
このスレ見てる人でグローバル変数使わないで済む設計してる人ってどれ位いますか？
聞いた理由はタスクってMediator（当たり判定managerとか）必須な気がするので
Mediator実装のためにグローバル変数使わざるを得ないって状態の人多いのかなと思いまして。

557 ：名前は開発中のものです。：2008/07/06(日) 16:48:55 ID:hSUFfzp7

ゲーム管理クラスにMediatorを持たせて
下位のプレイヤークラスにはゲーム管理クラスへの参照を作ってる

558 ：名前は開発中のものです。：2008/07/06(日) 16:54:21 ID:i1S1gouX

究極的な話をすれば、グローバル変数って可読性の向上やバグを未然に防ぐ為に使わないわけで、
自分しか見ないコードなら、グローバル変数を使う自分ルールがしっかりできてるならかまわないんじゃないか？
グローバル変数を使わないために膨大かつ複雑なものを管理して、可読性低下やバグの可能性が向上したら本末転倒でしょ。

559 ：名前は開発中のものです。：2008/07/06(日) 16:57:28 ID:PYEaz6Ug

自分しかみないんだったら何やろうが俺最強だろ

560 ：名前は開発中のものです。：2008/07/06(日) 17:05:40 ID:HG7Vxq5Q

タスクシステムに変数などという概念はない
あるのはワークエリアだけだ

561 ：名前は開発中のものです。：2008/07/06(日) 17:16:20 ID:NyEm8bIu

さっそくのレスありがとー

・・・みんな、、使ってるんだ。。。

562 ：名前は開発中のものです。：2008/07/06(日) 17:55:32 ID:cXpJQpiz

なんなんだその
みんなもチンコの皮かぶってるんだ
よかった
みたいなの

563 ：名前は開発中のものです。：2008/07/06(日) 18:03:44 ID:HG7Vxq5Q

それはかぶってない
断じて違う！！一緒にすんなっ！ちょっとだけだ！！！！

564 ：名前は開発中のものです。：2008/07/06(日) 18:35:16 ID:NyEm8bIu

>>562
タスクシステムから一皮むけた立派な方法持ってる人が
いたら見せてもらえるかなと期待してた。残念。。。

565 ：名前は開発中のものです。：2008/07/06(日) 18:49:09 ID:jVOdbK3J

LISP組み込め

566 ：名前は開発中のものです。：2008/07/06(日) 19:40:22 ID:i1S1gouX

>>559
2週間ぐらい全く触ってなかった辺りを触らなければならなくなったときの事を考えると、さ。
適当に作ると後悔するぜ。自分ルールは意外と重要。

567 ：名前は開発中のものです。：2008/07/06(日) 19:50:36 ID:NyEm8bIu

>>557
やっぱりそうなりますよねー

自分もそんな感じなんですが、下位クラスがゲーム管理クラスという
一番大きいクラスを知らないといけないっていう依存関係がしっくりこなくて。
対策考えてるんですがまだまとまってない

>>558
ここ数日グローバル変数というよりMediatorが規模増大の原因じゃないかとか疑ってるんで
それが当たってればグローバル変数は複雑性増大に関係ないかもしれな…自分で言ってて、ねーな

568 ：名前は開発中のものです。：2008/07/06(日) 20:20:58 ID:bOQhFRQW

>>567
引数で渡せばいいじゃん。

struct ICtxPlayer
{
　　// ショットマネージャーにインスタンス追加
　　virtual void addShot(IShot& shot) = 0;
};

class Player
{
　　// プレイヤーの実行
　　virtual void exec(ICtxPlayer& ctx) = 0;
};

class Manager : public ICtxPlayer
{
　　Player* player_;
　　std::list<Shot*> shots_;
public:
　　void exec() {
　　　player_->exec(*this);
　　　std::for_each(shots_.begin(), shots_.end(), boost::bind(&ICtxShot::exec, ::_1, boost::ref(*this)));
　　}
};

569 ：名前は開発中のものです。：2008/07/06(日) 21:20:03 ID:NyEm8bIu

>>568
なるほど、プレイヤークラス側で組のインタフェース用意してそれをManager側に実装させると。
自分が想像してたのとは違う方針だけどそれも有りかもしれない。
依存性切れてるし、いまいますぐ悪い面が思いつかない。
他オブジェクトとの当たり判定情報の受け渡しもインタフェース経由だよね？

自分もコード固まったら投稿するのでその時比較してみます。
それが１週間後か数ヵ月後になるか分からないけど。

570 ：名前は開発中のものです。：2008/07/06(日) 23:16:50 ID:bOQhFRQW

>>569
面倒といえば、インターフェースがやたら増えるのと、Manager クラスが肥大化したときに
委譲するための単純なコードが増えることかな。

ま、それでも見通し良くなるメリットと比べると、個人的にはおすすめの設計だが。

571 ：名前は開発中のものです。：2008/07/07(月) 00:08:11 ID:6OC3YW/e

前スレ>>60

60 名前：名前は開発中のものです。[sage] 投稿日：2006/08/24(木) 00:46:53 ID:YfRhQBsC
【敵機(Enemyクラス)が自機(Playerクラス)の座標の取得する場合】
(GetXY()となっているが、XとYを別々に取ってきても構わない)
・そもそもクラスにまとめていない or 自機も敵機もごちゃ混ぜクラス。
　自機の座標の取得には苦労しないよ派。
・Playerのインスタンスplayerがグローバル。
　player.GetXY()で座標を取ってくるよ派。
・PlayerがSingleton。
　Player::Instance().GetXY()で座標を取ってくるよ派。
・PlayerがMonoState。
　player.GetXY()もしくはPlayer::GetXY()で座標を取ってくるよ派。
・Enemyクラスがplayerへのポインタを保持。
　player->GetXY()で座標を取ってくるよ派。
・enemyがMadiatorに自機の座標の取得を要求。
　Madiatorがplayerの座標を調べて返してくれるよ派。
・playerやenemyが属する統括クラス(GameとかTaskListとか)に
　enemyがアクセス可能。
　Game.(->)GetPlayer()->GetXY()で座標を取ってくるよ派。

572 ：名前は開発中のものです。：2008/07/07(月) 03:23:12 ID:ohkg3t4w

グローバル変数を避ける理由って隠蔽化のためでしょ？
K&Rの単純なスタックのコードみたいに、static変数で管理して
インターフェイス（ってかグローバル関数）だけ外部に公開すればいんでないの

時間があって設計が楽しいって時もあるから別にいいけど、
グローバル変数を避けるためだけにクラス設計に凝るのは結構危ないと思ったり

573 ：名前は開発中のものです。：2008/07/07(月) 07:42:34 ID:oOt9p1/p

>>572は名前空間も知らない低学歴。

574 ：名前は開発中のものです。：2008/07/07(月) 07:59:40 ID:1RaeXbIY

>>547-549
内部実装の話とごっちゃにすんな

575 ：名前は開発中のものです。：2008/07/07(月) 13:09:23 ID:W17i5akd

グローバル変数使うなら、コメントで参照するオブジェクトを示しておくと分かりやすいかも？

class Player {
　　// グローバル変数参照 Player g_player *;
　　// グローバル変数参照 EnemyList g_enemyList *;
}

頭悩ましながらコード増やすよりもこっちのが好きだ。

576 ：名前は開発中のものです。：2008/07/08(火) 04:16:06 ID:NMTyfxS6

>>573
ええと、つっかかるわけじゃないが一応・・・
名前空間を使ってもグローバル変数は外部から書き換えられるから、
名前空間は隠蔽化とはまったく関係ないと思うなー

577 ：名前は開発中のものです。：2008/07/08(火) 05:47:08 ID:ENNwk1+H

>>573は普通に馬鹿

578 ：名前は開発中のものです。：2008/07/10(木) 01:58:37 ID:2LBnz8y4

嫌タスク厨はこのスレでやる分にはいいが
他のスレにまで迷惑かけんな

579 ：名前は開発中のものです。：2008/07/12(土) 03:16:55 ID:XJB6co32

むしろタスク厨をなんとかしろといいたい

580 ：名前は開発中のものです。：2008/07/12(土) 11:43:00 ID:KYyTN9Xu

タスクシステム普及委員（タ普委）　：　このスレの中でタスクシステムと呼びます。ローカルですよ。ローカル
　↓
（とりあえず皆が使う）
　↓
タ普委　　：　ほら！普及していますね！
　↓
一見さん　：　「タスクシステムってナニ？」
　↓
タ普委　　：　「知らないんですか？常識ですよﾌﾟｯ」

（タ普委、他スレに凱旋）
　↓
タ普委　　：　「タスクシステムこそ奇跡の技！失われたアーク！伝説の神器！万能の槍！マンセー！」
　↓
一見さん　：　「タスクシステムってナニ？」
　↓
タ普委　　：　「知らないんですか？常識ですよﾌﾟｯ」
　↓
野次馬　　：　「バーカｗ」
　↓
タ普委　　：　「他のスレにまで迷惑かけないでください！」　　　　←今ここ！

581 ：名前は開発中のものです。：2008/07/12(土) 23:55:17 ID:Qetm04PA

うむ。このスレだけで暴れているな

582 ：名前は開発中のものです。：2008/07/12(土) 23:56:48 ID:UIcT0kpG

世の中には2つのシステムがある
タスクシステムと非タスクシステムだ

583 ：名前は開発中のものです。：2008/07/13(日) 01:55:35 ID:UM30DsAY

タスク信者が面白いのは事実
嫌タスク厨にキチガイが混じってるのも事実

584 ：名前は開発中のものです。：2008/07/13(日) 01:57:00 ID:LG58SZaR

タスクシステム分が足りない

585 ：名前は開発中のものです。：2008/07/13(日) 02:01:26 ID:o8pv9PR4

タスクシステムの定義が未だによく分からん・・・
なんか人によって言ってること微妙に違うような気がするし

586 ：名前は開発中のものです。：2008/07/13(日) 02:20:07 ID:ZwxlhR79

知恵が遅れる、タスクシステム。

587 ：名前は開発中のものです。：2008/07/13(日) 04:35:10 ID:/hlYrGpq

>>585
俺もそう思う
両厨が思ってる定義に食い違いがあるような

588 ：名前は開発中のものです。：2008/07/13(日) 04:58:37 ID:uaqPI4FP

このスレでタスクシステムってのを初めて知りました。
Stateパターンのオブジェクトがリンクリストで繋がってる。
という理解であってます？

589 ：名前は開発中のものです。：2008/07/13(日) 07:04:16 ID:8j+NPxbX

>>588
そんな感じ。

ただ、ゲームでは細かい状態遷移が多いので、状態ごとにクラスを
作るようなことをするととんでもないことになる。

590 ：名前は開発中のものです。：2008/07/13(日) 08:14:53 ID:FP4ZrPCd

リスト巡回UPDATE＝タスクシステム（笑）

591 ：名前は開発中のものです。：2008/07/13(日) 14:22:38 ID:6SG0y8ml

ゲームのタスクシステムは、
任意のタイミングでタスク追加／削除できる上、
フロー制御ステップ（例：各ルーチンの実行orスキップのif判定）を、最小限に抑えることができる。
だから、リスト巡回UPDATEだけとっても相当な恩恵がある。

タスクシステムを使わないとすると、どんなやり方があるんだ？
タスクシステム理解は、外向的ゲーム開発者の義務教育じゃないのか。

初めてゲームのタスクシステムを知った時は、「あぁ、こうやればいいのか！」
と感動したが、これほど単純で高速な上、メモリ管理とも直結した解決法が、
他に普及しているか？

嫌タスク厨って、具体性のない煽り文句ばかり連発しているようにしか見えん。
「タスクシステム」という言葉に神経質になるほどのことではないと思うが。

592 ：名前は開発中のものです。：2008/07/13(日) 14:50:45 ID:L3kGAfa0

>>591
> 任意のタイミングでタスク追加／削除できる上、
バグの元

593 ：名前は開発中のものです。：2008/07/13(日) 15:05:16 ID:6SG0y8ml

>>592
一般的に言って、大規模なプログラム制作過程は、完全にバグから解放されることはない。
そんな浅い議論は、建設的ではない。

594 ：名前は開発中のものです。：2008/07/13(日) 15:08:14 ID:uaqPI4FP

>>591
タスクシステムの肝ってようはタスクごとに持ってる関数ポインタですよね？
オブジェクト指向が当たり前の昨今、その程度の技術は既に空気では？

3Dゲームでは大抵キャラごとにUpdate()とかRender()などの抽象メソッドを
インプリメントする手法がメジャーです。
タスクシステムなんて言葉は使いませんが本質的に同等だと思います。

余談ですが、しかし最近のマルチコア・マルチスレッド環境で
ハイパフォーマンスを出すにはオブジェクト指向のデータの持ち方は
並列化が難しく不利だと思われているようです。

並列可能なジョブ単位で処理しやすいようにインタリーブされたデータ構造が最適です。
ソフトウェア屋さんにとってはなかなか辛い道です。

595 ：名前は開発中のものです。：2008/07/13(日) 16:06:28 ID:6SG0y8ml

>>594
必ずしも生起と消滅のタイミングが一致しない並列タスクを、リストで管理して、
フレーム毎に、最小限のリスト巡回を行い、各タスクを更新する。
同時にメモリ管理の最適化も行える。

この発想を、明快なモデルで実現した一形態が「タスクシステム」である。
他に、Web検索で引っかかる呼び名まで付けられた、明快なモデルを知らない。

＞3Dゲームでは大抵キャラごとにUpdate()とかRender()などの抽象メソッドを
＞インプリメントする手法

上記の手法も、タスクシステムを、文字通り継承している。

596 ：名前は開発中のものです。：2008/07/13(日) 16:45:53 ID:6SG0y8ml

>>594
＞余談ですが、しかし最近のマルチコア・マルチスレッド環境で
＞ハイパフォーマンスを出すにはオブジェクト指向のデータの持ち方は
＞並列化が難しく不利だと思われているようです。

この辺の話はよくわかりません。すまん。

597 ：名前は開発中のものです。：2008/07/13(日) 17:01:04 ID:L3kGAfa0

>>596
画像のバックバッファと同じように、各オブジェクトのメンバ変数を
二重化しろって話でしょ。そうすれば、複数オブジェクトの Update() を
同時に呼び出しても競合が発生しない。

結構面倒くさいし、それだけじゃ片付かない問題もいろいろあるけどな。
ヤダヤダ。

598 ：名前は開発中のものです。：2008/07/13(日) 17:24:04 ID:kk0986WJ

>>591
おまえには設計のセンスが全くないな

>任意のタイミングでタスク追加／削除できる上、
>フロー制御ステップ（例：各ルーチンの実行orスキップのif判定）を、最小限に抑えることができる。
代わりに複雑になったり、他の部分のコードが肥大化する
メリットだけを強調して、それ以上に厄介なデメリットには目をつぶるんですか、そうですかw

>タスクシステムを使わないとすると、どんなやり方があるんだ？
つまり、MVCもDocumentViewも知らないという初心者さんですねw

>初めてゲームのタスクシステムを知った時は、「あぁ、こうやればいいのか！」
>と感動したが、これほど単純で高速な上、メモリ管理とも直結した解決法が、
>他に普及しているか？
そういうのをバカの一つ覚えって言うんですよw
一つのプログラムで速度に対するボトルネックになる部分なんてごく一部に過ぎない
全体を高速にする対価が、全体を複雑にすることなら、そんな高速化なんて必要ない

>嫌タスク厨って、具体性のない煽り文句ばかり連発しているようにしか見えん。
>「タスクシステム」という言葉に神経質になるほどのことではないと思うが。
何度も書かれているが、メリットとデメリットを出さずに
「これはいい」を連発するだけの、何がなんだかわからないものを崇拝している
システム設計の知識がない人間に対して、どういう言葉で接したらいいのか
それが最大の悩みだw
お前がバカなのはいいけど、拡散するな

599 ：名前は開発中のものです。：2008/07/13(日) 17:32:58 ID:kk0986WJ

笑いが止まらないwwwwwwwwwwwwww、お前らバカ過ぎ
冗談で言ってないなら、お前らが設計について語るのはやめろよwwwwwww
MVCで言うMとVの分離は基本だろ、一つのクラスで同時に実装してる奴は
よっぽど深く考えている奴か、真性のバカだ

>>594
お前の言ってることは全体的に間違ってる
周りの空気を読んだらそういう結論が出ましたみたいな感じだw
それでいいって言うのならそれでいいけどなww
おまえの人生に考えることは必要ないからなwwwwwwww

600 ：名前は開発中のものです。：2008/07/13(日) 17:51:31 ID:kk0986WJ

礼儀正しく上品に振舞って
知識や思考力がないことをごまかして生きていくって楽しいですか

タスクシステムを捨てて調べて考えるだけで
代わりの選択肢をいくらでも手にすることができるのに
意固地になってタスクシステムを崇拝する君たちが好きですwwwwwwwwwwwwwwww

効率の悪い設計で死ぬまで苦しんでいってねwwwwwwwwwwwww

601 ：名前は開発中のものです。：2008/07/13(日) 18:00:18 ID:6SG0y8ml

>>598
お前、落ち着けや。
別にお前が知恵おくれでも、いじめたりしないから。

＞つまり、MVCもDocumentViewも知らないという初心者さんですねw
「MVCやDocumentView」と「ゲーム開発のタスクシステム」は相互補完的であり、排他的なものではない。
見栄えのいい物作ろうとしたら「ゲーム開発のタスクシステム」の発想を知らないと、話にならんだろ。

煽りウザえ。
ポイントだけほざけや。

602 ：名前は開発中のものです。：2008/07/13(日) 18:02:07 ID:wN9PL2AC

まあタスクシステムについて語るスレだからねぇ…。
それ以外のテーマについてだとちょっとスレの趣旨と違う。

機能Aを設計してくれ、と客に依頼されたのに、
それは効率悪いし一般的には使われないから、
かわりに機能Bを設計します。
なんて返事はしないだろう…。

603 ：名前は開発中のものです。：2008/07/13(日) 18:07:31 ID:wN9PL2AC

ということで>>kk0986WJの語りも終わったみたいなので、話を戻しましょうか。

604 ：名前は開発中のものです。：2008/07/13(日) 18:08:35 ID:UM30DsAY

>>591
さ、さすがに釣りでしょ・・・？
下２行以外まったく同意できないｗ
もっと色々な（ゲーム以外の）コードも読んだ方がいいですよ

>>595
>上記の手法も、タスクシステムを、文字通り継承している。
Update()やRender()メソッドとタスクは、動作の上では似ている点が多いので最初はその理解でよいですが、
元々の考え方や進化の系統が違うのでタスクの延長と考えるのは深い理解の妨げになります

C++の仮想関数が内部的にＶテーブルで実装されているからと言って、
「仮想関数は関数ポインタテーブルが進化したものです」と言う人はいませんよね？
※Smalltalkなどの原型を触ってみると分かりますが、関数ポインタと仮想関数は
「実装上は同じ」ですが「考え方はまったく異なる」ものです

>>599
きちがい乙ｗｗｗ

605 ：名前は開発中のものです。：2008/07/13(日) 18:34:26 ID:UM30DsAY

あとメモリ管理に関して
>>591は new 演算子が非効率だと思ってます？

デフォルトの new 演算子は毎回 malloc() するのと同じですが、
それだと組み込みなどで困りますから、C++の場合当然その辺は考えられています
「アロケータ」でググれば後付けで効率化する手法が色々出てきますよ

まあ、こういう個々の具体的な話は知ってるのかも知れないけども、
つまり言いたいのは、ゲーム進行管理とメモリ管理が分離されていない、
というのはデメリットであってメリットではないということです

606 ：名前は開発中のものです。：2008/07/13(日) 19:02:36 ID:kk0986WJ

>>601
じゃあ、MVCやDocumentViewとタスクシステムのどちらが上位に来るのか
ほざいてみろよ、お前程度では答えられないだろうがなw

Update()やRender()を混在させるということは
タスクシステムをMVCやDocumentViewと同じレベルのものにしたという事だ
当然排他的になる、お前の意見を正確に書け

>>604
きちがい乙ｗｗｗって書けば勝ちだと思っているバカ乙www

607 ：名前は開発中のものです。：2008/07/13(日) 19:13:40 ID:6SG0y8ml

>>604、>>605
釣りはお前だろ（笑）って突っ込みを入れたくなる。
「深い理解」とか、具体性を欠く。
抽象的な表現が多く、総じて何が言いたいのかよくわからん。
すまん。

608 ：名前は開発中のものです。：2008/07/13(日) 19:17:45 ID:uaqPI4FP

>>606
MVCでゲーム作ってんですか？
それまともに動いてます？
ゲームならUpdate()とRender()が分かれているだけで十分と思います。
過度な抽象化は失敗のもと。
現実的にならないといい作品は作れないよ。

609 ：名前は開発中のものです。：2008/07/13(日) 19:37:54 ID:6SG0y8ml

>>606
＞煽りウザえ。
＞ポイントだけほざけや。
＞きちがい乙

610 ：名前は開発中のものです。：2008/07/13(日) 20:10:42 ID:UM30DsAY

両方から叩かれて俺涙目ｗ

>>607
具体的な例は世の中にいっぱいあるじゃないですか・・・。
俺は単に、
>タスクシステムを使わないとすると、どんなやり方があるんだ？
>タスクシステム理解は、外向的ゲーム開発者の義務教育じゃないのか。
これにＮＯと答えてるだけです

タスクは否定しませんが、押し付けｲｸﾅｲ!
若いのはGame Programming Gemsとか読んで勉強してるわけですよ。
タスク理解が義務と言うなら、あなたが他のやり方を理解するのも義務だと思う。

>>606
ＭＶＣ厨乙ｗｗｗｗ

611 ：名前は開発中のものです。：2008/07/13(日) 20:55:06 ID:kk0986WJ

6SG0y8ml
本性表したなw
おまえはこの単純な質問に答えられない
なぜならば、この質問に答えるとおまえ自身の矛盾を認めることになるか
自分の味方を否定することになるからだwwwwwwwwwwwww

もう一度、問う
MVC, DocumentViewはタスクシステムの上位なのか下位なのか?
それとも、この質問の意味がわからないかい?wwwwwwwwwwwwwwwwwwwwwwwww

612 ：名前は開発中のものです。：2008/07/13(日) 21:07:26 ID:6SG0y8ml

>>611
＞MVC, DocumentViewはタスクシステムの上位なのか下位なのか?
「上位、下位」ってどういう意味なんよ？
抽象的な言葉多し　＋　煽り全開。
だからキチガイって言われるんだよ。

613 ：名前は開発中のものです。：2008/07/13(日) 21:08:34 ID:kk0986WJ

>>608
自分の愚かさを知らずに、それを正当化するための理由を書いて満足かよwwwww

タスクシステムのようなまがいものを使うと
オブジェクト指向言語の利点を引き出すことができない
そういうものだと思い込んでいるからだ
そしてオブジェクト指向言語の利点を引き出す設計であるMVCが
なんなのか理解していないから平気でそういう事が言える
そんな浅い知識と経験と思考力しか持ってないあんたに
上から目線で言われる覚えはない、自分を知れ、お前は下っ端なんだよwwwwwwwwwwww

614 ：名前は開発中のものです。：2008/07/13(日) 21:09:58 ID:ZwxlhR79

熱くなって参りました！

615 ：名前は開発中のものです。：2008/07/13(日) 21:10:57 ID:o8pv9PR4

本気で言ってるとしたら精神科にかかる必要がありそうなのが二人ほど居るな

616 ：名前は開発中のものです。：2008/07/13(日) 21:11:08 ID:kk0986WJ

>>612
MVC, DocumentViewはタスクシステムに含まれているのか?
それともタスクシステムはMVC, DocumentViewに含まれているのか?
それともどちらもどちらかに含むことができないのか?
これなら理解できるだろ、それとも俺の質問の仕方が悪いのかよwwwwwww

617 ：名前は開発中のものです。：2008/07/13(日) 21:14:45 ID:kk0986WJ

別の言い方をした方がいいのかもな
MVC, DocumentViewが同じ偉さの人間だとして
タスクシステムはこいつらよりも偉いのか、偉くないのか、それとも同じ偉さなのか?

618 ：名前は開発中のものです。：2008/07/13(日) 21:16:16 ID:luJBP/jy

草の量に焦った

619 ：名前は開発中のものです。：2008/07/13(日) 21:18:01 ID:kk0986WJ

　　　 _, ._
　　（・ω・）
　　○=｛=｝〇,
　　|:::::::::＼, ', ´
.ｗｗしｗ`（.＠）ｗｗｗｗ

620 ：名前は開発中のものです。：2008/07/13(日) 21:21:15 ID:6SG0y8ml

>>616
お前みたいなやつに返答するのは、不愉快なんだが。

＞MVC, DocumentViewはタスクシステムに含まれているのか?
＞それともタスクシステムはMVC, DocumentViewに含まれているのか?
＞それともどちらもどちらかに含むことができないのか?

「含む」ってどういう意味よ。
強いて言うなら、一つのシステムに両者が含まれうる。

621 ：名前は開発中のものです。：2008/07/13(日) 21:24:47 ID:kk0986WJ

質問に答えやすいように、もっと別の言い方をしよう
MVC, DocumentViewを構成するModel View Controller Document等の中で
タスクシステムが使われるのか?
それともタスクシステムの中でMVC, DocumentViewが使われるのか?
それともタスクシステムはModel View Controller Documentに似たような要素を含むものなのか?
おまえはこの質問に答えられないから、そのうち逃げると思ってるw

622 ：名前は開発中のものです。：2008/07/13(日) 21:24:48 ID:uaqPI4FP

いやさ
そもそもMVCをゲーム開発で使わないから。
MVCってぶっちゃけ非リアルタイムのオフィスアプリのためのフレームワークでしょ？
ゲームのオブジェのモデルとビュー分けことに意味があるとは思えないな。

623 ：名前は開発中のものです。：2008/07/13(日) 21:31:13 ID:ni6QBog5

いや、普通に分けると思うけど…?

624 ：名前は開発中のものです。：2008/07/13(日) 21:35:55 ID:ZwxlhR79

つか、真剣に議論したい奴は捨てハンでもいいから名乗った方が良くね？
武将リストとか人物相関図とか作って当分楽しめそうだ。

625 ：名前は開発中のものです。：2008/07/13(日) 21:41:28 ID:IEzc7ZIH

MVCってのが、Smalltalk発祥のプラガブルMVCのことを指すんだったら
ゲームじゃ使わないし、フレーム単位で呼ばれるオブジェクトとエンティティ
オブジェクトを分離する程度の意味合いで言ってるんだったら普通に使うなあ。

626 ：名前は開発中のものです。：2008/07/13(日) 21:42:02 ID:uaqPI4FP

>>623
おれが言ってるのはMVCのモデルとビューだよ。
じゃあお前さんの作ってるゲームではビューが全面的に切りかえ可能なわけだ。
すごいね。
何のためにそんなことやってるの？

627 ：名前は開発中のものです。：2008/07/13(日) 21:53:12 ID:ni6QBog5

モデル - オブジェクトの変形、座標変換、アニメーション、その他パラメータなど
ビュー - 出力ウィンドウ、レンダーターゲット、出力デバイスと解像度切り替え
コントローラ - ゲーム全体の進行管理、状態管理

という意味でなら使ってる。

「オフィスアプリケーション以外では使うな」なんて限定してたら
せっかく応用性の高いフレームワークがもったいない。
人それぞれ解釈があるとは思うけど。

628 ：名前は開発中のものです。：2008/07/13(日) 21:55:56 ID:kk0986WJ

さてと、質問の説明をするのも難しいもんだな
都市と家と部屋
都市には複数の家が存在する
家には複数の部屋が存在する
MVCが家の設計なら、タスクシステムは都市の設計なのか、部屋の設計なのか?

629 ：名前は開発中のものです。：2008/07/13(日) 22:00:29 ID:uaqPI4FP

>>627
それはMVCじゃないね。
モデルとビューが対応していない。

そもそもは ID:kk0986WJ はおれが書いた >>594 のゲームオブジェクトが
Update()とRender()を持つというところに対してツッコミを入れたのだから、
そのゲームオブジェクトの粒度でMVCになっているべき、という主張なんだろう。

パターンというのは、万能じゃなくある特定の問題を解決するものだという基本を
理解しておくべきだよ。
普通パターンの本を読むと、はじめにこのパターンはこれこれの問題を解決する
ためのものであるか書いてあるでしょ？

630 ：名前は開発中のものです。：2008/07/13(日) 22:05:41 ID:6SG0y8ml

>>616
＞MVC, DocumentViewが同じ偉さの人間だとして
＞タスクシステムはこいつらよりも偉いのか、偉くないのか、それとも同じ偉さなのか?

「偉い」とかガキな表現だな。
おまえの「タスクシステム」コンプレックスの闇の深さには、辟易する。
強いて言うならゲーム開発では、「MVC, DocumentView」を使える人間よりも、「タスクシステム」を使える人間の方を、圧倒的に重宝する。

>>621
＞MVC, DocumentViewを構成するModel View Controller Document等の中で
＞タスクシステムが使われるのか?
いいえ。

＞それともタスクシステムの中でMVC, DocumentViewが使われるのか?
いいえ。

＞それともタスクシステムはModel View Controller Documentに似たような要素を含むものなのか?
いいえ。

「一般的なMVC, DocumentView」、「ゲーム開発のタスクシステム」は、一つのシステムの中で、混在しうる。
両者は、得意な処理系が違う。補完的な関係にある。

つうか、お前、質問する立場に居座って、必死で無能さを隠そうとしているように見えるぞ。
ところで、お前はどんなゲームジャンルを問題にしているんだ？

631 ：名前は開発中のものです。：2008/07/13(日) 22:13:09 ID:ni6QBog5

>>629
んー、ということは、Update()がオブジェクトの変形や移動(>>627のモデルで書いた部分)で、
Render()が描画(>>627のビュー)ってことか。
たしかにオブジェクト単位のRender()で直接描画はしないなぁ…。

632 ：名前は開発中のものです。：2008/07/13(日) 22:18:31 ID:kk0986WJ

>>630
やっぱり逃げるのか、そして明確に答えたくないから濁すのか、ふーん

>「一般的なMVC, DocumentView」、「ゲーム開発のタスクシステム」は、一つのシステムの中で、混在しうる。
>両者は、得意な処理系が違う。補完的な関係にある。
いやいや、お前らの話からするとタスクシステムというものは
MVCなんかと同列のアーキテクチャパターンで
MVCで言うModel, View, Controllerの全ての要素について語ってるから
それで混ぜて使えるぜというのなら
MVCのいずれかの要素に内包されていなければならないはずなのだが
矛盾してるねw
どうも、互いに考えていることが食い違っているみたいだ
もっと詳しく話してくれないとわからないよwwwwww

>ところで、お前はどんなゲームジャンルを問題にしているんだ？
タスクシステムというものがアンチパターンで何の役にも立たないし
どんなジャンルでもMVCの方がまともに書けるから、ジャンルなんて関係ないなw
全てのジャンルでもいいぜw、タスクシステムにだけ有利なジャンルというものもないだろう

633 ：名前は開発中のものです。：2008/07/13(日) 22:25:03 ID:UM30DsAY

>>625
青軍：タスクシステムは義務教育
赤軍：青軍ﾜﾛｽwwwMVC万能wwww

どっちも釣りくせえｗｗｗ

634 ：名前は開発中のものです。：2008/07/13(日) 22:26:33 ID:r2yfCmtz

なんでお前らはタスクシステムを知らない人間と議論しようとしてるの？

635 ：名前は開発中のものです。：2008/07/13(日) 22:26:48 ID:tw1/nxGs

>>632
MVCって凄いんだな。でも俺にはどうしてもイメージが湧かないんだ・・。
頼む、君の今までに経験した中で一番、MVCだとこんなにイイ感じに書けるんだぜっていう
具体的な実装例、MVCの分け方、または体験談でいいから教えてくれ！

636 ：名前は開発中のものです。：2008/07/13(日) 22:30:17 ID:kk0986WJ

MVC万能とは言ってないけどな
タスクシステムと比較するならMVCの方が圧倒的に強い
MVCがクリリンならタスクシステムはヤムチャだ

637 ：名前は開発中のものです。：2008/07/13(日) 22:36:32 ID:tw1/nxGs

何でも万能なものなんて無いのは分かってる、とにかく実装例を教えて欲しい。
ググッても数当てゲームとか微妙なのしかないし、ほんと分かんないんだ、頼むよ。

638 ：名前は開発中のものです。：2008/07/13(日) 22:39:48 ID:UM30DsAY

どの範囲でMVCを適用してるのか分からんのだよね
スーパーマリオをMVCで設計するとどういう感じなんよ？

639 ：名前は開発中のものです。：2008/07/13(日) 22:40:19 ID:uaqPI4FP

ID:kk0986WJ が逃げずに答えられたら本物だよね。
おれの中のパラダイムをひっくり返してくれることを期待してる。

640 ：名前は開発中のものです。：2008/07/13(日) 22:51:10 ID:6SG0y8ml

>>632
病院に行ってこい。

>>633
釣りじゃないってば（笑）。
問題解決の導入としては、よいモデルだと思うが。

641 ：名前は開発中のものです。：2008/07/13(日) 23:10:51 ID:kk0986WJ

>>640
>病院に行ってこい。
おまえがな

MVCと、タスクシステムに詳しく、これらの相互補完の方法を知っている
>>640様が、すばらしいタスクシステムの使い方を
みなに広めてくれることを願っております

俺の負けって事でいいよ、君のプライドを壊したくはないんだ

642 ：名前は開発中のものです。：2008/07/13(日) 23:19:57 ID:ni6QBog5

やっぱり逃げたw

643 ：名前は開発中のものです。：2008/07/13(日) 23:21:38 ID:6SG0y8ml

>>641
とりあえず、お前は>>637-639の期待に答えろ。
病院に行くのはその後でいいから。

644 ：名前は開発中のものです。：2008/07/13(日) 23:27:03 ID:kk0986WJ

>>643
いやいやMVCしか知らない俺よりも
MVCとタスクシステムの両方を理解し使いこなすおまえの方が適任だよ
お前の好きなように布教してくれ、俺は逃げるぜw
ここはタスクシステムについて語る場だからな
「ゲームにおける(以下略)」スレになら書いてもよかったけど
タスクシステム信者が邪魔しやがったもんだから
書く気もしなくなったぜwwwwwwwwwwwwwwwwwwwwwwww

645 ：名前は開発中のものです。：2008/07/13(日) 23:32:44 ID:UM30DsAY

>>644
おま・・・ｗ　ほんとに書かないの？ｗｗ
コードくれとか言ってないぞ
ちょっと簡単なクラス図でも見せてよって言ってるだけだぞ？

646 ：名前は開発中のものです。：2008/07/13(日) 23:38:03 ID:o8pv9PR4

まだやってんのかｗ
どう見ても釣りだろう・・・常識的に考えて・・・

647 ：名前は開発中のものです。：2008/07/13(日) 23:44:51 ID:T0lQAxXZ

>>622
> そもそもMVCをゲーム開発で使わないから。
> MVCってぶっちゃけ非リアルタイムのオフィスアプリのためのフレームワークでしょ？
俺もまったく同意。MVCは主にウェブ系アプリのフレームワークで頻繁に利用されるもの。
これをどうゲームに活用してるのか非常にきになる。
>>644よ逃げずにぜひ教えてくれ。

648 ：名前は開発中のものです。：2008/07/13(日) 23:49:49 ID:QxRyBdDg

ぶっちゃけ某大手の糞ライブラリにイライラしてる下請けが多いんだな
（覚えてるか？あの発表した奴ですよ、論文で糞だよなーだれも欠点指摘して批判しないもんなー）
タスクシステムは欠陥品だ

メリットより明らかにデメリットのほうがでかい
そのメリットだって、言語の型誤魔化して無理やりキャストして
明示的に書かなきゃいけない処理を面倒臭いから端折ったとか酷いものだし

ふつーに組めばふつーに完成するのに
これ使うとバグが何十倍にも膨れ上がる

649 ：名前は開発中のものです。：2008/07/13(日) 23:54:06 ID:kk0986WJ

>>647
いやいや、使わなくていいんじゃないの?
タスクシステムというMVCと組み合わせて使えるすごい何かがあるんだったら
それ使っておけば間違いないよ、うん
貧弱で負け犬の俺は逃げる
俺の言ったことは全部釣りでしたー、てへwwwwwwwwwwwwww

650 ：名前は開発中のものです。：2008/07/13(日) 23:55:05 ID:r2yfCmtz

>>649
>本性表したなw
>おまえはこの単純な質問に答えられない

>知識や思考力がないことをごまかして生きていくって楽しいですか

そっくりそのまま返ってきちゃったね。

651 ：名前は開発中のものです。：2008/07/13(日) 23:58:32 ID:kk0986WJ

日付が変わる、IDも変わる
これからが本当の地獄だ……

652 ：名前は開発中のものです。：2008/07/14(月) 00:01:31 ID:tw1/nxGs

>>648
ｋｗｓｋ

653 ：名前は開発中のものです。：2008/07/14(月) 01:59:27 ID:ZLSPS2ff

でも実際の所、ゲームオブジェクトが描画要請までするのってどうなのよ？

654 ：名前は開発中のものです。：2008/07/14(月) 02:45:49 ID:oV5fvSE8

このスレ見てると訳が分からなくなってくる。
ゲームオブジェクトってどいつのこと？ある特定のタスクそのものまたは一部の事？それともタスクを管理している何かの事？
タスクとは関係ない話でリスト巡回の個々の要素の事?それともプログラムと直接関係の無い概念的な何か?

描画要請って、あるクラスの描画メンバを誰かが呼ぶこと?それとも例えばDirectxなどの描画するための関数を呼ぶこと?

655 ：名前は開発中のものです。：2008/07/14(月) 02:57:19 ID:SM8gZCjO

2DRPG作ってるけどMVC普通に使ってる
エフェクトを除けばビジネスアプリと作り方もそう変わらない
ツール作るのも楽だし
これがSTGとかになると設計は単純だし
複雑化しようがないからMVCの利点は見えてこない

あとタスクシステムの話はまったくわからん

656 ：名前は開発中のものです。：2008/07/14(月) 04:10:54 ID:3KLD41lJ

>>654
ごめん。
ゲームオブジェクトはゲームの自機とか敵機とかを想定して書いてた。
タスクそのものという意味になるのかな？
描画要請は、直接間接関係なく、そのオブジェクト内に
draw()とかrender()とかあるのはどうなんだろうと。

でも正直、個人でやる分にはモダンなやり方で全然構わないと思うんだけどね。

657 ：名前は開発中のものです。：2008/07/14(月) 08:12:29 ID:2wpDRLgy

MVCは元々Smalltalk-80でのUI実装例に頭文字で名前をつけたものに過ぎない
「UI実装」の名前だお？

MFC（Document-View構造）は、MVCをオマージュして別の問題に適用したものだが、
ドキュメント＝ファイルとビュー＝アプリケーションウインドウという対比で分かるように
「ファイル志向」のアプリ構築のために限定されたアーキテクチャに過ぎない。

WEB系におけるMVCは、モデル＝データベースバックエンドとビュー＝HTML/XMLという
限られた適用分野の問題解決のための枠組みであって、これもまた上のどちらとも違う。

ゲームに適用してるって言っている人に言いたいのだけど、
具体的にどう適用してるかがとても重要だから、そこをみんな聞きたがってるんですお
やや疑ってはいるが、実際にみんな興味があるのだ

658 ：名前は開発中のものです。：2008/07/14(月) 11:01:40 ID:wZepfXXK

>>656
> >>654
> ごめん。
> ゲームオブジェクトはゲームの自機とか敵機とかを想定して書いてた。
> タスクそのものという意味になるのかな？
> 描画要請は、直接間接関係なく、そのオブジェクト内に
> draw()とかrender()とかあるのはどうなんだろうと。

3Dかどうかで違うのかもね。
2Dの人は昔からあるアドホックで効率的な方法でやる人がおおいかもしれない。
3Dだとオブジェクトとはシーングラフ中のノードだね。
3Dは表示のためのアセットやパラメータが多いからそれぞれがRender()を持ってないと管理できない。
Render()って中身はDirectXやOpenGLの関数、つまりGPUに対するコマンド生成だね。

ゲームでMVCと言ってる人は、おれの予想では
M ゲーム全体のロジック
V イメージプレーンへゲーム画面全体を描画する
C 入力
という大枠の部分がMVCになっていると言ってるだけではないかな？
最終的にはWindowsとかのフレームワークで動かすのだから、
そうなるのだろうけど、ここでMVCに興味持ってる人は、
もっと細かい単位でMVCを適用してるの？と聞いている。

UIのコンポーネントがMVCって作られているというのは
テキストボックスやボタンやメニューのそれぞれがMVCの構造を持っている。
ではゲームでは上であげられた例で言うとスーパーマリオのマリオやキノコが
のぞれぞれがMVCで作るのか？という疑問。
>>655 答え頼む

659 ：名前は開発中のものです。：2008/07/14(月) 11:08:56 ID:hiwKNv2R

メッシュを当たり判定に使ったり
ビットマップをそのままデータ処理に使ったりするから
線引きができない
たとえばキャラクタの背の高さは描画のためのリソースを読んでみないことには
分からないがこれはモデルに属するべきデータだ

描画とデータを分けるようなデザインにしてたけど今では失敗だったと思うね
Bot的なものをつくるために描画をしないゲームもビルドできるようにしたけど
#ifdefがぐちゃぐちゃに散らばった上にゲーム内では盲目みたいにふるまうしかない
出来損ないができただけでクラス設計は何の役にもたたなかった

660 ：655：2008/07/14(月) 14:05:54 ID:SM8gZCjO

マリオやキノコは M。(性的な意味でなく)
ただし画面上にある幾つかのオブジェクトのうちの一つをクリックした時に反応を返す場合、
例えばキノコと毒キノコをユーザに選択させたい場合はM/Vに分け、Cで操作する。

MVC が威力を発揮するのは複雑なユーザ入力、
端的に言えばマウス入力がある場合。

MVC のキモはプラガブルなイベント処理にあるんだから
マウスオーバーやクリックで何の反応も返さないオブジェクトが
MだろうがM/Vだろうが大差ないと思うのは当然。

あと M/V を綺麗に分離するとメインループが
model.update();
view.draw();
のようになるはずと思うかもしれないけど
そんなのはMVCの副産物程度で重要な問題でないし
またそうである必要もない

まあ要するに MVC はスレ違いって事だ

661 ：名前は開発中のものです。：2008/07/15(火) 01:38:48 ID:gtIAMyAK

>>660
言ってることが全般的におかしい。
MVC理解してないでしょ。

お前さんのマリオの例は例えばWindowsのコントロールとして
マリオやキノコを実装すると言っている？
もしそうならそれはプログラミングの遊びにはなるだろうけど
まともなゲームにはなると思えないな。

> あと M/V を綺麗に分離するとメインループが
> model.update();
> view.draw();
> のようになるはずと思うかもしれないけど

特にここがおかしい。
model.update()すると、modelを参照しているオブジェクトに変更されたことが通知される。
そこにはviewも含まれる。
でviewはその通知を受けて描画する、となる。
view.draw()なんて直接呼ばない。

いずれにせよゲームでこんなアーキテクチャを使う必要はない。

662 ：名前は開発中のものです。：2008/07/15(火) 07:22:56 ID:jUUalvKq

え？

663 ：名前は開発中のものです。：2008/07/15(火) 11:13:01 ID:rZk1oc86

概念としてはゲームにもMVCを使う利点はあると思うんだけど。
何か実装レベルの話でビジネスアプリの設計を持ち出して、
これは使えない。ゲームにおいてMVCは悪。なんて流れは納得できないな。
もちろん、ゲームの仕様によっては意味が無い場合もあるのは分かるけどね。

664 ：名前は開発中のものです。：2008/07/15(火) 16:56:48 ID:u82e8pDr

設計は戦略レベルなのに戦術レベルでしか語れないから
それで目標が見えずに完璧な戦術にこだわるから
戦略的に特に重要でない話ばかりをやりたがり、こだわる
戦略的に重要な箇所は理解できないか関心がないから避ける
避けるから設計能力が向上しない
設計能力がないから設計で悩む
検索してみる
タスクシステムすげー
という結論になる

665 ：名前は開発中のものです。：2008/07/15(火) 19:41:23 ID:F8XElOWm

頂点シェーダー使うとViewとModelの関係が固くて切れない。
MVCはバラバラになった。

666 ：名前は開発中のものです。：2008/07/16(水) 02:22:21 ID:qC1mHsjs

>>663
> 概念としてはゲームにもMVCを使う利点はあると思うんだけど。
> 何か実装レベルの話でビジネスアプリの設計を持ち出して、
> これは使えない。ゲームにおいてMVCは悪。なんて流れは納得できないな。

すまんが、どこがそういう流れなんだ？
何人かがMVCをゲームに使う例を知りたがっていて
>>660がゲームでの一例を書いた
それが>>661でツッコまれた
という流れに思えるが。
お前がMVCをゲームで使う利点を知っているなら具体的に説明してみなよ。

667 ：名前は開発中のものです。：2008/07/16(水) 03:09:44 ID:GHeUJ08F

661の突っ込みはバカらしくて無視してたが
Windowsのコントロールにロジック書く設計だとMVCではなくPACになる
MVCでObserverを使う義務はない
ということでMVCの表面だけをなぞっただけの人だから無視してよい

そもそもMVCの話はスレ違い
PACなら近いからいいけどな、実はタスクシステムはPACではないかと思っているw

668 ：名前は開発中のものです。：2008/07/16(水) 03:32:16 ID:qC1mHsjs

>>667
マリオのクラス図プリーズ
それでお前が正しいかどうか判断できるから

669 ：名前は開発中のものです。：2008/07/16(水) 03:39:51 ID:j8s7PlLo

そこはマリオじゃなくて、パックマンだろ

670 ：655：2008/07/16(水) 05:11:06 ID:xMH3TnoB

アク禁で放置してた

>>661
ゲームなんだから再描画イベントの通知なんてあるわけがない
fps 通りに毎フレーム描画するだけ
ゲーム内の GUI をビットマップにキャッシュするなら別だけど
それは個々の V が勝手にやる事な

フィールド V とマリオ V の関係をGUI風に言えばリスト V と子のラベル V だな
実際のマウスイベントの処理はフィールド V が行う。
マリオの位置がクリックされたらフィールド V がマリオ選択イベントを C に送出。
C はマリオの V とマリオ M を受け取り状況に応じて処理する。
だからマリオ V の実装は描画とマウスの領域判定くらいでスプライトとほぼ一緒。

というかそもそもマリオは例として最悪。パックマンも。
スーパーマリオを MVC で作っても利点なんてほとんどない
マップエディタをパッと作れる程度だ

RTS とかの方が適切だな
兵士ユニット M はフィールド V 上のスプライトとして表現されたり
編成リスト V のラベルやボタンとして表現されたりする
つまり一つの M に対して複数の V があるケースだ
でもこの辺は普通のアプリと大差なくなるので書いてもツマランと思う

671 ：名前は開発中のものです。：2008/07/16(水) 06:01:32 ID:O5I9kqZp

○　一般的なMVCとかDocumentView：
　分布パターンに価値のある少量のデータ（銀行口座情報、個人情報など）を処理するのに向いている。
　データ更新の頻度は、比較的少ない。
　データ更新過程に段階の区切りがあり、各段階をたどる流れ（＝更新手続き、画面遷移）が、ユーザにより柔軟に変化されうる。

　M：ミクロなデータ更新方法を詳細かつ厳密に規定する。なぜ「モデル」というのかはよく分らん。

　V：データ更新手続きが行われる際に、ユーザ向けインターフェースとなる。

　C：ぶっちゃけ、銀行ATM機の画面遷移を制御する機能。
　　　M－V間連携の制御をするという意味でも使われる。
　　　「Controller」というのは、データ更新の手続きにおいて、クライアント側（＝ユーザ側）とサーバ側の手続き進行を制御する（＝Control）から来ていると思われる。

○　ゲーム開発のタスクシステム：
　分布パターンの価値が薄い大量のデータ（多数のキャラの位置、火花の分散状態など）を処理するのに向いている。
　データ更新の頻度は、相当多い。
　データ更新過程に明確な段階の区切りがない。

ゲーム中で、銀行ATM機のような遷移形式ウィンドウを一時的に使う場合などは、その部分についてだけ、MVCの発想で設計してもいいんじゃないか。
タスクシステムの代用として、MVCを使うというのは「Crazy Timeにようこそ救世主伝説」だ。

一般的なMVCの意味合いが、タスクシステムで処理する問題に当てはまらない。
ゲーム本体部分についてMVC適用とか言うのは、ゲームジャンルによっては明らかにミスリードだろ。

672 ：名前は開発中のものです。：2008/07/16(水) 06:24:51 ID:GHeUJ08F

なんだかよくわからないけど、
タスクシステムはアーキテクチャルパターンでいいのかね?
前に共存できるというアホがいたからそうではないと思ったのだが違ったようだな。

http://en.wikipedia.org/wiki/Presentation-abstraction-control
タスクシステムはPACの劣化コピーwwwwwwwwwwwwwwwwwwwwwwwww
知ってた?wwwwwwwwwwwwwwwwww
MVCと肩を並べるなんてずいぶんと偉くなったなwwwwwwwwwwwwwwwwwwwwwwww

673 ：名前は開発中のものです。：2008/07/16(水) 06:26:41 ID:Dm0i59R6

>>669
無理やり話題に入ろうとしててワロタ。

674 ：名前は開発中のものです。：2008/07/16(水) 06:35:18 ID:O5I9kqZp

オンドレ。キチガイはダマットレや。

　　　 ∧＿＿＿∧　　　　　
　　/　＿＿［Ｄ）＿_i　　　　
／∩ 「￣(_・`"・_)￣;ト、
　 |／＞'"‘・ｰ・’`＜;|　＼　
　{ ／　, イ二ｴ二!ヽ　!　　＼
　（　　(＿＿＿＿＿) ﾉ　　　＼　

（出所：アニメAA辞典、一部抜粋）

675 ：名前は開発中のものです。：2008/07/16(水) 13:23:33 ID:qVDcOX49

単にデータと描画処理を分離することをみんなMVCと呼んでるのか？
まあそれならそれでいーけど

個人的にはWEB系プログラマがMVC語ってるの見ると、Squeakくらい触ってから言えよと思ったり

676 ：名前は開発中のものです。：2008/07/16(水) 15:57:34 ID:VDH9y+dj

単に？

677 ：655：2008/07/16(水) 20:15:24 ID:xMH3TnoB

>>675
> 単にデータと描画処理を分離すること

どの書き込みに対して言ってるの？

678 ：名前は開発中のものです。：2008/07/16(水) 21:03:14 ID:Ou+YKOXb

MVCってさ、１つのデータを２つ以上の別の方法でユーザーに提示して、異なった方法で
元のデータをいじくったりすることができるってのが勘所だと思うから、
基本的に１つの画面でしか操作しないようなアクションゲームなんかではあまり意味ないだろうね。

PC用に複雑なGUIを使ったゲームとかなら使えるかもしんないけど、
それはもうビジネスアプリとあんま変わらない気がする。

679 ：名前は開発中のものです。：2008/07/16(水) 22:02:43 ID:0ZuSnVv6

>>670
MFCのコンポーネントを使ってゲームのキャラを作ってるの？
具体的にどういうGUIフレームワークを使ってるか知りたいです。

680 ：名前は開発中のものです。：2008/07/16(水) 22:46:10 ID:GHeUJ08F

君らのMVCに対する熱い情熱はわかった
あんまり有益な情報は提供しないようにしてたけど一つだけ書いておく

MVCの利点のひとつはModelのテストを簡単にすることにある
Viewと切り離されているため、ModelのUnitTestを実装することができる
テスト用のViewを作ってModelをテストすることもできる
おなじみのprintfテストもできるw

ViewとModelが混在している場合だと、ModelのテストをするためにViewを起動しなくてはならない
メソッド単位でUnitTestを適用することも可能だが
オブジェクト同士が依存関係を持った状態でそれをやるのは難しい

さらに開発時間の短縮にも影響が出る
プログラムのテストを1000回行って1000回ウィンドウが開くとしたら
Modelのテストだけでもウィンドウを開く必要がなければ
どのくらい速く開発ができると思うかい?

681 ：名前は開発中のものです。：2008/07/17(木) 00:22:11 ID:TWLB0nfA

500秒くらいかな。

682 ：名前は開発中のものです。：2008/07/17(木) 01:20:27 ID:0LoYOqms

塵も積もれば山となるというが、この手の時間短縮は全然積もらない気がする。

683 ：名前は開発中のものです。：2008/07/17(木) 01:38:29 ID:QTsQdZDe

つーかMVCにそのものの興味じゃなくて(そんなのいまさらの技術だし)
ゲームでMVCが使えるのか？という議論だろ
>>680さん乙、でも話が的外れ

684 ：名前は開発中のものです。：2008/07/17(木) 02:05:13 ID:0LoYOqms

>>683
対戦とかだと C はプレイヤー, リプレイ, AIの切り替えの都合で、切り出して
おいたほうが無難だな。ジャンルによってはどうでもいいけど。

685 ：名前は開発中のものです。：2008/07/17(木) 05:15:11 ID:xMMME6s2

>>683
へー、ゲーム開発にテストは必要ないのか
それは知らなかったなw

686 ：名前は開発中のものです。：2008/07/17(木) 23:45:14 ID:wIIwBA38

MVCを当てはめてどうかじゃなく
ゲームに適したレイヤー分けみたいなものが新たに提案できるんじゃないかな
一般的なGUIと違って第一の目的はデータを変更することじゃなくかっこいい描画をすることだし
それゆえに見た目を司る部分とは根深い１対１の相互依存がある一方で
入力はさまざまなものをサポートする必要がでてくることが多いね

687 ：名前は開発中のものです。：2008/07/18(金) 00:06:45 ID:6yruIhmm

MVCとは
　Model
　View
　Controller
に分割して設計・実装する手法

ゲームで考えるとMVCそれぞれは
　Model
　　　キャラクタの移動やパラメータの増減

　View
　　　ジョイパッドやキーボードからの入力（※）、画面描画

　Controller
　　　いわゆるメインルーチン、ゲームループ、タスクシステムなどと呼ばれる部分

※　　入力のみ。入力への反応はModelで行う。
　　　たとえばキー入力で「右」が押されたという情報を変数に格納するまでがView
　　　キャラクタのX座標に＋１をするのがModel

688 ：名前は開発中のものです。：2008/07/18(金) 01:26:23 ID:KJRMV7kA

>>687
それだとタスクシステムはアーキテクチュアじゃねーじゃねーか
なんで俺が質問したときに出てこなかったクソ野郎
タスクシステムを肯定する奴がひとりひとり言ってることが違うじゃねーか
それで、お前らはタスクシステムという言葉を使うもの同士で
その矛盾を突っ込みあわなくて、タスクシステムそのものを批判する奴に対しては協力して攻撃する
やっぱり宗教じゃないかクソ

689 ：名前は開発中のものです。：2008/07/18(金) 01:34:16 ID:r0vZ2gPp

どうでも良いけどタスクシステムの定義ってジョブリストでいいの？
関数ポインタでも何でも良いけど、ジョブを自由に追加削除入れ替え出来る仕組みって認識で
未だにタスクシステムってものがどういうものかつかみきれてないから教えてほしい

690 ：名前は開発中のものです。：2008/07/18(金) 01:54:19 ID:c+FL9TYJ

>>687
パターンってのは頻繁する共通のデザインに名前をつけることに意義があるわけ
まぁMVCは亜流が多いから意味がぶれがちだけど
お前のは簡略化しすぎ

691 ：名前は開発中のものです。：2008/07/18(金) 02:09:10 ID:YaAkQubs

>>3

692 ：名前は開発中のものです。：2008/07/18(金) 17:47:07 ID:MAojNpIh

>>591
> 任意のタイミングでタスク追加／削除できる上、
大仰
> フロー制御ステップ（例：各ルーチンの実行orスキップのif判定）を、最小限に抑えることができる。
大仰
> だから、リスト巡回UPDATEだけとっても相当な恩恵がある。
大仰
> 初めてゲームのタスクシステムを知った時は、「あぁ、こうやればいいのか！」
大仰
> と感動したが、これほど単純で高速な上、メモリ管理とも直結した解決法が、
大仰

てかさー、キャラクターを生成したり消したりするなら
オブジェクトをなんぞコンテナ（リストとは限らない）に入れて管理する以外ありえないし、
毎フレーム更新するなら当然update関数を作るし、描画するなら当然render関数を作るし
いったいこれのどこに工夫らしい工夫があるワケ？　そのまんまやないかい。

もっとインタラクションとか実際的なことに立ち入って検討するなり、
組み込み方面から面白いノウハウでも引っ張ってくるなりするならともかく、
何もやってないじゃん。本当にただのオブジェクトのリストじゃん。「オブジェクトのリスト」でいいじゃん。

たぶん、プログラミング初心者がろくに自分で解法を考えもしないうちにタスクシステムとか耳にして
すばらしいものだと刷り込まれてしまってるんだろうけど、
そんなね、並のプログラマなら何も言われなくてもするようなことに
大仰な名前をつけてありがたがってるやつがいると、
ゲームプログラマ全体がレベル低いように見られて迷惑なんですよ。実際レベル低いけど。

「タスクシステム」なんて言葉は、手を頬にそえて顔を赤く染めながら言うくらいでちょうどいいよ。

あと、なんすか、今度はドキュメント-ビューですか。あれもどれほど実際的なものかね。
ビューをすげ替えたらローグになったりトルネコになったりするんですか。
そんなもん見せられたら俺はビビッて白旗揚げて土下座して謝る。

693 ：名前は開発中のものです。：2008/07/18(金) 19:07:02 ID:cU2jYr/L

>>692
> あと、なんすか、今度はドキュメント-ビューですか。あれもどれほど実際的なものかね。
MFC 使うと知らねばならんのだ。もう忘れて良いけど。

694 ：名前は開発中のものです。：2008/07/18(金) 22:39:31 ID:6mKQHPS9

嘲笑として言ったんだろうけど、ローグ系なら使えるなと思ってしまった。
tty表示とかタイル表示とか切り替えたりするし、
有志がより良いUIを付属したりするローグ系には最適だね。

まあ、１フレームごとに更新するゲームを対象としてるスレだろうから無意味な意見だけど。

695 ：名前は開発中のものです。：2008/07/18(金) 23:18:09 ID:c+FL9TYJ

>>694
完全にMVCの目的を勘違いしてる
一度じっくりパターン本読んでみな

696 ：名前は開発中のものです。：2008/07/18(金) 23:37:04 ID:SOEKH9dh

お勧めの本プリーズ

697 ：名前は開発中のものです。：2008/07/18(金) 23:57:49 ID:cU2jYr/L

>>695
MVCはデザパタというより、ソフトウェアアーキテクチャーじゃない？

たとえば Controller を実装するために Command パターンを使うとか、
より上位の概念っつー気がする。

698 ：名前は開発中のものです。：2008/07/19(土) 08:53:52 ID:fHjcMlA8

>>692
基本を馬鹿にしたらあかんぞ。
大層なことを言っているが、その方法論を使いこなせているのか？
タスクシステムには全く依存せずに仕事をしているのか？
タスクシステム無しで、自己満足にとどまらない話題を巻き起こした仕事をしてきたと言えるのか？

地道な基礎の習熟無くして、革新無し。
素直な心無くして、精進無し。

699 ：名前は開発中のものです。：2008/07/19(土) 08:56:38 ID:E75dPbBr

>>698
> 基本を馬鹿にしたらあかんぞ。
タネンバウムとかヘネシー＆パターソンですね
分かります

700 ：名前は開発中のものです。：2008/07/19(土) 11:57:03 ID:vD184tg1

これが真のタスクシステムだ

class TaskAgent
{
Abstraction a;
Control c;
Presentation p;
}

AbstractionがModel、ControlがController、PresentationがViewだと考えるとわかりやすい
そしてタスクシステムはより柔軟なComposite構造になる
Listに入れてる奴はこれの簡易バージョンなのでお勧めしない

701 ：名前は開発中のものです。：2008/07/19(土) 12:22:03 ID:lczMI6ps

この人はどんなこと言ってるの？

702 ：名前は開発中のものです。：2008/07/19(土) 12:32:18 ID:r2AvBQOl

いまどきめずらしいPACマンセーな人です
でちょっと機転をきかせてタスクシステムと合わせてみて
おれすげーって思ってる人です。

703 ：名前は開発中のものです。：2008/07/19(土) 12:56:07 ID:MKSfmuIO

>>695
そうなん？
複数目的があるものなんじゃないの？

ちなみにローグのView切り替えはビルド時じゃなくて実行時だし、
UIも切り替えられたら便利なんだが。
少なくとも、>>692はそういう意味で言ってないかな。

それでも何か勘違いしてたらすまん。

704 ：名前は開発中のものです。：2008/07/19(土) 15:32:41 ID:Tk0uZ3zU

まあ、なんにも名称がない技術が多いから
こういう名前がついてる技術にあこがれるのはわかるけど
こういう無駄なキーワードついてる設計技術ってのは怪しいｗ

聞きなれないキーワードを連発しだす奴がスレに出始めたら
大抵嘘吐きな法則発動中ｗ

705 ：名前は開発中のものです。：2008/07/19(土) 15:39:07 ID:Tk0uZ3zU

そもそも、そーんな名称知らないと構造がわからんような
プログラムってどんだけ価値があるのか考えたことあるのか？って話ですよ

名前をつけるってややこしいことだぜ
「何？それ？・・・」って言われた時点で説明責任が発生しちまうしよ
キーワードと仕組みが相手の中で一致してもらわにゃほとんど意味ねぇしよ

長くやってるほどこの説明の面倒臭さってのは
どうしようもねぇぐらい開発の負荷になることがわかる

俺みたいにできるプログラマってのは誰にでもわかる言葉で話をするんだぜ

706 ：名前は開発中のものです。：2008/07/19(土) 15:41:15 ID:QEQKqCSO

>>3の説明を見た限りでは、現代では特に使い道のない仕組みのような・・・
これってコンピュータが貧弱だった時代にリソースを有効活用するために生まれたものでしょ
いまいち現状に即してない気がしてならないんだけど・・・

707 ：名前は開発中のものです。：2008/07/19(土) 15:43:52 ID:Tk0uZ3zU

>>706
相手にも自分にもわからんようなキーワードを自分に都合のいい解釈で使用することで
相手を煙に撒く技ってわかっているなら相手にしないほうがいいよ
このスレこういう中身がない奴多いんだ

708 ：名前は開発中のものです。：2008/07/19(土) 15:43:56 ID:xzYy5tYF

>>706
そうそう。
総当たりのループの非効率性が許容できなかった時代の話。

このあたりのノウハウができてないと、
「星を見るひと」とか「スーパーモンキー大冒険」とかそういうレベルの速度になる。

現在では、使ってもデメリットは少ないが、
「使わなければならない状況」自体が少ない。

709 ：名前は開発中のものです。：2008/07/19(土) 15:55:04 ID:r2AvBQOl

今だって総当りのループは避けるってw
ハードの性能向上にしたがってオブジェクトが増えているんだから。
おれはタスクシステムの意義は認めるよ。
歴史的な価値としてね。
C++あれば同等の性能でより型安全な記述が可能だし。
(1段vtableが入るから非効率とか言われるかな？)

いずれにせよタスクシステムは至極ナイーブな仕組みなので
使い物になるのはせいぜい2Dのシンプルゲーム程度でしょ。
いまどきの3Dゲームを作ろうとすると、ベースのフレームワークもそれなりに
高機能なものでないと複雑さに対応できないよ。

710 ：名前は開発中のものです。：2008/07/19(土) 15:56:28 ID:r2AvBQOl

>>705
じゃあVisitorパターンを誰にでもわかる言葉で説明して

711 ：名前は開発中のものです。：2008/07/19(土) 16:54:02 ID:f8lDD3Nc

仕事で会うデザパタ厨もこういうの多いな

712 ：名前は開発中のものです。：2008/07/19(土) 17:02:49 ID:Tk0uZ3zU

>>710
http://www.aerith.net/design/Visitor-j.html
はい
掲示板に長々と書く気はないし知らなくていいよこんなの
だいたい俺は名称があると面倒だっていったのにそれを説明しろっておかしくない？
俺が面倒だと主張することをわざわざ俺にやらせて俺になにを表現させたいの？

あと
俺はこんな仕組みのプログラムが必要になっちゃうこと事態ダメだと思うけどね
俺の仕事の進め方だと話題でデザパタの内容を説明することはあっても
デザパタを仕事で使うことは完全に無いといっていいよ
まず、こんなの仕組みありきでソースを書く状況ってありえることか？

713 ：名前は開発中のものです。：2008/07/19(土) 18:16:05 ID:E75dPbBr

>>712
デザパタは単なる定石だからなぁ。良くある問題に対する良くある設計を
まとめて、得失考察して名前付けただけ。

ただ、名前がついてると同僚と話はしやすいやね。いちいち順を追って
解説しなくても、「今回、AI とのやりとりはコマンドパターンっぽい感じに
なってるよ」でとりあえず済む。

714 ：名前は開発中のものです。：2008/07/19(土) 18:27:49 ID:Tk0uZ3zU

>>713
いらないいらない
だってさ

まず、対象をソースに実装するに当たって
まず、対象の構造を分析するじゃん？
そんで分析したもんどおりにクラス作って実装すればいいわけであって
それがデザパタの何に当たるか？なんてやる工程ないっしょ？

いらないじゃん
いつデザパタって必要になるの？

だから、デザパタが必要になるようなクラス設計してる時点で手順がおかしい
対象物の分析して分析した結果を強引にデザパタに当てはめるようなことをするのは
もはや直感的に設計をしてないよね？
折角、分析モデルをそのままクラスに落とせるのにそれを潰してデザパタ適用するなんて
無駄にもほどがある

715 ：名前は開発中のものです。：2008/07/19(土) 18:42:25 ID:kwFO5l8i

無理にあてはめる事に反感持つのはわかるけどさ
だからと言って Iterator としか言いようのないクラスに
Iterator 以外の名前付けられてもウザいでしょ

716 ：名前は開発中のものです。：2008/07/19(土) 18:47:31 ID:Tk0uZ3zU

>>715
誰もそんな話してないけど
どうしてそんな発言したの？

717 ：名前は開発中のものです。：2008/07/19(土) 19:46:25 ID:grjjkTbc

デザインパターンは分析手法の一つですよん。
IT屋がやる分析ってのはコンピュータで実装できる要素の組み合わせに持っていくことでしょ。
それがUMLだったりDFDだったりERDだったり、デザパタ、アーキテクチャ、何かのプログラミング言語だったりするわけ。

そもそもデザパタを使わない分析をしてるならデザパタなんか使わなくていいよ。あれはOOPに特化してるし。
>>716は何でもかんでもデザパタをねじこもうとしてくる人が多くて辟易してるんだろうと予想してみる。

718 ：名前は開発中のものです。：2008/07/19(土) 20:01:58 ID:Tk0uZ3zU

>>717
>デザインパターンは分析手法の一つですよん
は？
じゃ対象物があったとしてどうやって使うの？
（俺は違うと思って聞いてるぜ、お前が返答できると思ってないからわざと聞いてる）

719 ：名前は開発中のものです。：2008/07/19(土) 20:05:01 ID:eXsdvwwV

＞IT屋がやる分析ってのはコンピュータで実装できる要素の組み合わせに持っていくことでしょ。
これ設計じゃん。分析ってその一歩手前の作業でしょ。
デザパタが分析手法とか何言ってんのかと思った。

720 ：名前は開発中のものです。：2008/07/19(土) 20:31:43 ID:grjjkTbc

分析手法と設計手法は同じものだよ。
建物の設計図は設計図であると同時に、その建物を分析した図であると言える。
目の前にあるものに対して「分析」、これから作るものに対して「設計」という言葉を使ってるだけ。

例えば、社長が書類にハンコを押す作業を分析したとき、規定の場所にハンコを押すだけなら
その様子をIteratorパターンであると分析できる。
書類は一定の用式さえ保っていれば、常にハンコが押されるというわけだ。

721 ：名前は開発中のものです。：2008/07/19(土) 20:36:02 ID:Pb4UPnyH

巨大な構造物をつくるのに共通言語が必要って
バベルの塔みたいだね

722 ：名前は開発中のものです。：2008/07/19(土) 21:04:00 ID:E75dPbBr

>>721
専門家がいる業界は、どこもそうなるわな。

723 ：名前は開発中のものです。：2008/07/19(土) 21:13:42 ID:E75dPbBr

>>714
世の中細かいところは違うが、よくある問題ってのはある。で、その手の
問題にはみんな取り組んでるので、だいたいこれが定石だろうという
設計も決まってきてる。

だからカタログ化しました、っつーだけの話だろ。

> いつデザパタって必要になるの？
設計するときに、自分の経験だけでなく人の経験も活かしてみるかと
思ったときじゃね？

まぁ、プログラマ長くやってると、たいていのデザインパターンは「そうそう、
前のプロジェクトでこんな設計にしたことあったよなぁ」って感じだけど。

俺が駆け出しの頃はデザパタ本なんてなかったから、自分で考えたり
人のコード読んだりで定石身につけたけど、あれば学習効率上がった
かなぁとは思う。

724 ：名前は開発中のものです。：2008/07/19(土) 21:38:05 ID:Tk0uZ3zU

>>723
お前は対象物を見ないで勘で設計してるの？

725 ：名前は開発中のものです。：2008/07/19(土) 22:13:40 ID:E75dPbBr

いいえ

726 ：名前は開発中のものです。：2008/07/19(土) 22:16:59 ID:r2AvBQOl

>>724
デザパタをテクニック集と思ってないか？
あれ別にテクニックとして驚くようなものはないよ。

そうじゃなくて意思疎通しやすいように語彙を決めてくれることに意味があるわけ。
お前さんがVisitorの説明を逃げたように一から説明するの面倒でしょ？
そういうときにVisitorと一言言えば通じるって便利じゃん。
配列とかリンクリストとかそういう名称の延長。

だからここでオレMVCで語るやつも話が混乱するだけだから基本
を勉強してからMVCという言葉を使うべき

727 ：名前は開発中のものです。：2008/07/19(土) 22:57:32 ID:vbSKYQbR

タスクシステムと一言言えば通じるって便利じゃん。
配列とかリンクリストとかそういう名称の延長。

728 ：名前は開発中のものです。：2008/07/19(土) 23:12:23 ID:lczMI6ps

しかしこのスレでこれだけ議論になるということは、
タスクシステムというのは一言で表せる代物ではないってこった。

729 ：名前は開発中のものです。：2008/07/19(土) 23:30:19 ID:E75dPbBr

むしろ、タスクシステムなんて実体は存在しないんじゃないか疑惑

730 ：名前は開発中のものです。：2008/07/19(土) 23:46:25 ID:Tk0uZ3zU

>>726
なんでそうやって人の発言を曲解して返すの？
じゃあ、聞き返すけどVisitorって何？
説明責任が発生すること事態が面倒臭くないか？

ここでVisitorを知らない人ってリンクたどっていちいち学んでから
お前と会話しなきゃいけないのか？

あと、お前ずるいよね
説明責任が発生するのが面倒でしょ？って言ってる俺にそうやって
説明させて「ほらできないじゃん」って馬鹿ですか？
根本から脳みそおかしいでしょ？

それとMVCって何？
説明が足りないっていうなら補って完璧に答えてみてよ

731 ：名前は開発中のものです。：2008/07/19(土) 23:50:03 ID:Tk0uZ3zU

さらに発生する負荷をいうけど

Visitorを知らない人が調べてきたとして
そのVisitorとみんなのVisitorが一致するかどうかってまた確認しなきゃならなくない？

現にデザパタってなんのこと？って言っててさっき全然頓珍漢なこと言った人いたじゃん
あんなもんでしょ

お前のやり方じゃ、全然、仕事がすすまねぇよ
これが結果だし、お前の実力なんじゃねぇの？

732 ：名前は開発中のものです。：2008/07/19(土) 23:55:35 ID:Tk0uZ3zU

しかも、デザパタってどう考えてもオブジェクト指向のどの工程で使うのか俺にはわからないんだよね
折角対象物の構造どおり分析した結果をクラスにできるのに
わざわざデザパタアレンジ加えるその無意味さをだれも説明できたことがねぇよ

まあ、もうわかると思うけど典型的な論文ビジネスだろ
書いてあるパターンも稚拙なもんが多いし、
そもそもパターンなんて少ないほうがよかっただろ
人間の脳みそじゃせいぜい覚えてて８つぐらい？ｗ
それをあんな大量に増やしてパターンとしてカウントするものに
シングルトンなんて普通に考えて入れますか？
こんなグローバル使う時点で設計死んでんだよ

馬鹿でしょ？なんでシングルトン？なんのために設計してるのよ

733 ：名前は開発中のものです。：2008/07/20(日) 00:17:42 ID:tmHWlv8v

>>730
お前はなぜそんなに怒りまくってるんだw
最初のコメントにもどってレスしてみよう。

>名前をつけるってややこしいことだぜ
>「何？それ？・・・」って言われた時点で説明責任が発生しちまうしよ
>キーワードと仕組みが相手の中で一致してもらわにゃほとんど意味ねぇしよ

GoFのなんちゃらパターンと言えばいいだけ。
ある程度の複雑な仕事を複数人でやるなら知識のボトムラインは強制していい。

> 長くやってるほどこの説明の面倒臭さってのは
> どうしようもねぇぐらい開発の負荷になることがわかる

おれはこれに同意してる。
だからデザパタ便利でしょと言っている。

> 俺みたいにできるプログラマってのは誰にでもわかる言葉で話をするんだぜ

誰にでもわかる言葉で話さないといけないから面倒なんだろ？

734 ：名前は開発中のものです。：2008/07/20(日) 00:26:49 ID:itzBDsJr

>>733
>GoFのなんちゃらパターンと言えばいいだけ
だからそれがすでに一致してねぇって
少なくとも俺が考えるデザパタと、さっきいた頓珍漢なこと言ってた奴のデザパタと、お前のデザパタは
明らかに違うだろ

ここですでにおかしいから以降のレスは意味ねぇじゃん

厳密なのはいらないけど
どうやってみんなのデザパタを一致させる気なの？

俺の考えるデザパタは>>730-732で説明した通り
お前のデザパタはテクニック集（何の？設計？実装？いつ使うの？）、
頓珍漢な奴のデザパタは分析らしいぜ

なんでこんなに違うの？誰が正しいの？
俺のが正しいってことでいい？
ダメなら喧嘩して俺の主張をお前が受け入れるまで頑張るけど

735 ：名前は開発中のものです。：2008/07/20(日) 00:27:30 ID:tmHWlv8v

>>732

あとここも

> しかも、デザパタってどう考えてもオブジェクト指向のどの工程で使うのか俺にはわからないんだよね
> 折角対象物の構造どおり分析した結果をクラスにできるのに
> わざわざデザパタアレンジ加えるその無意味さをだれも説明できたことがねぇよ

デザパタ工程なんてあるわけないだろw
やっぱり根本的に意義を履き違えている。
使わないで済むんのなら使わなければいい。
使う場合も自分なりにアレンジしたって全然構わない。

でもGoFのパターンは基本的な構造だから、いたるところに出現すると思う。
単にデザパタを暗記できていないから、自分が考えた設計が既にパターン化
されていることに気づいていないだけでは？

シングルトンを否定してるが、シングルトンって言葉便利だろ？
シングルトンと書くだけでお前が何を否定したいか一発でわかる。
そういうことだ。

736 ：名前は開発中のものです。：2008/07/20(日) 00:32:51 ID:itzBDsJr

>>735
は？
無駄なこと覚えてどうするの？

だってシングルトンなんて普通に設計してりゃまずありえねーじゃん

それと工程ってのはデザパタの工程じゃねぇだろ？
ここは俺の文章よく読んでよ
開発の工程のことでしょ？

737 ：名前は開発中のものです。：2008/07/20(日) 00:35:15 ID:tmHWlv8v

>>734

じゃあとことんやるか？

> >>733
> >GoFのなんちゃらパターンと言えばいいだけ
> だからそれがすでに一致してねぇって
> 少なくとも俺が考えるデザパタと、さっきいた頓珍漢なこと言ってた奴のデザパタと、お前のデザパタは
> 明らかに違うだろ
なんだ？
デザパタという概念の理解が異なるというとと、パターンの意味の理解が異なることを混同している。
落ち着け。

> 厳密なのはいらないけど
> どうやってみんなのデザパタを一致させる気なの？
GoFの本ぐらい、仕事場に一冊ぐらいあるだろ。
その本読んでもらうといい。

> 俺の考えるデザパタは>>730-732で説明した通り
> お前のデザパタはテクニック集（何の？設計？実装？いつ使うの？）、
> 頓珍漢な奴のデザパタは分析らしいぜ
おれはテクニック集とは言ってない、その反対だ。
落ち着け。

> なんでこんなに違うの？誰が正しいの？
> 俺のが正しいってことでいい？
> ダメなら喧嘩して俺の主張をお前が受け入れるまで頑張るけど
ここは2chで知識のレベルがバラバラだから意見も理解も異なるだろう。
みんなで共通の理解を持ちたいなんて思わない。
おれはお前に言っている。

738 ：名前は開発中のものです。：2008/07/20(日) 00:40:07 ID:itzBDsJr

>>737
まあ、こういう会話がはじまっちゃうのもなんでなのか聞きたいね
まずさぁ、こんな会話続けても無駄だからデザパタを実際の開発のどこにどうやって使うのか
ちょっと言ってみてよ

そもそも俺の理解がここで止まってる状態なのに
これ以上なんも知らない俺がデザパタを批判するのもなんだと思うわけだよ

739 ：名前は開発中のものです。：2008/07/20(日) 00:45:29 ID:tmHWlv8v

>>736
> >>735
> は？
> 無駄なこと覚えてどうするの？
>
> だってシングルトンなんて普通に設計してりゃまずありえねーじゃん

それはお前の経験不足。
システムで有限個しか存在してはいけないものってはありえるよね。
物理的なデバイスに対応してたらそうなること多い。
そんなときにシングルトンでグローバルにアクセスできるように設計しても
何の問題もない。
いちいちご丁寧にローカルな参照チェーンを作る設計の方がどうよ？と思わないか？

> それと工程ってのはデザパタの工程じゃねぇだろ？
> ここは俺の文章よく読んでよ
> 開発の工程のことでしょ？

デザパタ工程ってのは皮肉だw
デザパタをどこで使うかなんて悩む必要はないってこと。
設計して結果としてパターンになっているだけ。
そして人に伝えるときにここはなんちゃらパターンといえばいい。
まぁRADツールではパターンからテンプレート作るものもあるけど。

740 ：名前は開発中のものです。：2008/07/20(日) 00:50:48 ID:itzBDsJr

>>739
>システムで有限個しか存在してはいけないものってはありえるよね
は？なんでそんなものを実行時にチェックしようとしてるのか本気で意味不明
設計が死んでるじゃん
なんか設定によってはうっかりインスタンスが２つできちゃうみたいじゃねーかｗ

だからそういう会話繰り替えしても無駄だってｗ

デザパタのパターンはどこでどう持ち出してどう使えば満足なんですか？
お前、もしかしてデザパタ使ったことないのにデザパタ人に勧めてるの？

741 ：名前は開発中のものです。：2008/07/20(日) 00:55:56 ID:tmHWlv8v

>>738

とことんやるから粘着でいくよ

> >>737
> まあ、こういう会話がはじまっちゃうのもなんでなのか聞きたいね
> まずさぁ、こんな会話続けても無駄だからデザパタを実際の開発のどこにどうやって使うのか
> ちょっと言ってみてよ

使うんじゃない、適切な設計をした結果としてパターンが現れる。

> そもそも俺の理解がここで止まってる状態なのに
> これ以上なんも知らない俺がデザパタを批判するのもなんだと思うわけだよ

確認だがGoF読んでいるんだよな？
クラス図だけでなくそのパターンのmotivationとかforceなどの前書き部分をよく読むといい。

世の中のデザパタ解説はクラス図だけを見せていかにもテクニック集に見せているものが多い。
初心者にはそういう理解でもとりあえずはいいかもしれないが、
ある程度経験を積めばGoFのほとんどは自分で見つけ出せるものだ。
だからテクニック集としてのデザパタという理解に関してはお前と同じ拒否反応がおれにもある。

742 ：名前は開発中のものです。：2008/07/20(日) 00:58:19 ID:itzBDsJr

>>741
>使うんじゃない、適切な設計をした結果としてパターンが現れる。
笑わせんなよ
それじゃいつ使うんだよ

>確認だがGoF読んでいるんだよな？
読んだ読んだ
読んだけど使えない
くだらない話をするな
お前はどうやってデザパタを使ってるんだ

743 ：名前は開発中のものです。：2008/07/20(日) 01:05:44 ID:Tcsf7iZJ

オブジェクトの構造がぐちゃぐちゃになったとき → あ、○○パターンを使うとうまく整理できるぞ！
ってくらいの感覚で使えばいいよ。

744 ：名前は開発中のものです。：2008/07/20(日) 01:07:49 ID:L2XNyVag

>>736
> だってシングルトンなんて普通に設計してりゃまずありえねーじゃん
ゲームだとファイル非同期読み込みの実装は必須だが、その管理クラスとか
シングルトンにしないか？

745 ：名前は開発中のものです。：2008/07/20(日) 01:11:17 ID:tmHWlv8v

>>740
> >>739
> >システムで有限個しか存在してはいけないものってはありえるよね
> は？なんでそんなものを実行時にチェックしようとしてるのか本気で意味不明
> 設計が死んでるじゃん

実行時にチェック？意味不明だが。
じゃあOSがオブジェクト化されているとしよう。
いちいちオブジェクトをnewするたびに引数でそのOSオブジェクトへの参照を渡すか？

> なんか設定によってはうっかりインスタンスが２つできちゃうみたいじゃねーかｗ

そうだ、場合によってそういう変更に対応できるように、
シングルトンはあくまでインスタンスベースで行うわけだ。
これをクラスベースにすると、あるとき1でなく2つまでOKと変更になった場合に
変更量が多くなる。
しかしうっかり2つって言う状況はシングルトンのインタフェース的に考えられない。

> だからそういう会話繰り替えしても無駄だってｗ
>
> デザパタのパターンはどこでどう持ち出してどう使えば満足なんですか？
> お前、もしかしてデザパタ使ったことないのにデザパタ人に勧めてるの？

お前がOO言語使っているなら100%、GoFのパターンを踏んでいると思うよ。
おれは自分言語作ったときに評価関数内にきちんとVisitor使った。
再帰的なツリー構造を持つデータ構造に対してはVisitorはおもしろいパターンだ。
あのときはまだ経験が浅かったから、結果として使われていたでなく、
使おうと思って使った。

経験談を知りたかったらGoFのデザパタ読め。

746 ：名前は開発中のものです。：2008/07/20(日) 01:11:42 ID:itzBDsJr

>>743-744
ええー
お前等ちゃんと対象物にあった設計しろよー

747 ：名前は開発中のものです。：2008/07/20(日) 01:16:07 ID:L2XNyVag

>>742
いつ使うかっつったら、設計フェーズ。

どういう設計でいくか考えるときに、材料の一つとして使う。

プログラマとして経験を積むと「こういう場合には、この方法」ってのが
身体に蓄積されていくけど、デザパタは、それを体系化して名前付けた
だけだって。普段からやってる作業だろ？

たぶん ID:itzBDsJr は、今更デザパタ本を読んでも「知ってることばかり」
だと思うけど、引き出しの数が少ない初心者には良い材料なんだよ。

748 ：名前は開発中のものです。：2008/07/20(日) 01:17:05 ID:itzBDsJr

>>745
>そうだ、場合によってそういう変更に対応できるように、
は？実行時に？

後のレスは全部無駄話で結局デザパタをどうやって使うかって説明できてないじゃん
お前も対象物の構造を素直にクラスに落とさないでデザパタアレンジかけて遊んでる奴の仲間か？

749 ：名前は開発中のものです。：2008/07/20(日) 01:17:32 ID:L2XNyVag

>>746
ファイル読み込み管理クラスをシングルトンにすると、具体的にどこがどう
対象物にあった設計にならないんだ？

750 ：名前は開発中のものです。：2008/07/20(日) 01:18:02 ID:Tcsf7iZJ

>>746
すまんね。対象物にあった設計というのは俺の辞書には無いわ。
トライ＆エラー繰り返して、物を作り上げていくスタイルだから。

ちなみに俺の場合、設計＝オブジェクトの構造決定＝デザパタの適用したりしなかったり
だから、設計という行為にデザパタの適用も含まれてる。

751 ：名前は開発中のものです。：2008/07/20(日) 01:22:20 ID:itzBDsJr

>>747
>どういう設計でいくか考えるときに
なんで考えるの？（クリエイトな意味で）
考えるもさ、対象物の分析に力を注ぐならわかるけど
いかにも自分設計を作ってやろうってのが下手糞なんじゃねぇの？って思うんだけど
そこんとこどうよ

いままでデザパタを使おう使おうって方に頭がまわっちまって本来どうあるべきか？
って部分がテキトーになってんじゃねぇの？

やっぱりねぇ、おかしい部分がデザパタのパターンにまでいかないんだよ
ここですでにおかしい、対象物を分析して構造を理解してクラスに落とす工程がないのがわからん
そもそも対象物の分析すらしてないように見える

752 ：名前は開発中のものです。：2008/07/20(日) 01:26:24 ID:itzBDsJr

>>750
>すまんね。対象物にあった設計というのは俺の辞書には無いわ。
>トライ＆エラー繰り返して、物を作り上げていくスタイルだから。
ええー
それじゃ折角オブジェクト指向で組んでもみんなと対象物についての認識が一致しないじゃないかー
自分設計がダメだから対象物をそのままクラスにすることで大きくはずれた設計にならないようにする
つまり、わかりやすい直感的なものになるんじゃないんかー？

ちがうぜーなんかやっぱデザパタやってる奴は俺と根本的に組み方がちがうぜー

ちょっと聞くけどほかのデザパタ利用者もこんな感じかマジで？

753 ：名前は開発中のものです。：2008/07/20(日) 01:28:02 ID:Tcsf7iZJ

>>751
そりゃ、対象物が定まらないからだよ。
度重なる仕様変更のたびに固い設計を繰り返してたんじゃ、納期に間に合わない。
だから出来るだけプログラム部品を独立、カプセル化の限りを尽くして、設計の変更に耐えるようにしてる。

って言う風に俺は理解してるんだけど。
最初から細部まで仕様の確定してるプロジェクトなんてあるの？

754 ：名前は開発中のものです。：2008/07/20(日) 01:28:56 ID:yelSdOCQ

共通言語としてのパターンに気がついてくれたかとおもったのに
なんで実際に使うだの使わないだのに話もっていくかな

755 ：名前は開発中のものです。：2008/07/20(日) 01:29:11 ID:tmHWlv8v

>>748
> >>745
> >そうだ、場合によってそういう変更に対応できるように、
> は？実行時に？

どうでもいいけど実行時ではない設計を変える場合だ。
GoF読め。

> 後のレスは全部無駄話で結局デザパタをどうやって使うかって説明できてないじゃん
> お前も対象物の構造を素直にクラスに落とさないでデザパタアレンジかけて遊んでる奴の仲間か？

お前が経験を積んだエンジニアなら、「パターンを使う」という発想はいらないと言っている。
最初の方に書いたが、配列とかリンクリストを使わずにプログラム書けるか？
それと同じ。
そういうデータ構造のレベルから、クラス構造のレベルにあがっただけの話だ。

お前の「対象物の構造を素直にクラスに落とす」のはよいことだ。
しかしそれはパターンを否定することにはならない。
それはわかってくれ。
そろそろ眠い。

756 ：名前は開発中のものです。：2008/07/20(日) 01:31:41 ID:Tcsf7iZJ

>>752
オブジェクトの指向の場合、ブラックボックスをつなぎ合わせて全体を作りましょうっていうのが流行りだから、
細部の仕組みについて各々に周知徹底させる手間を減らす効用を期待してるんだ。

757 ：名前は開発中のものです。：2008/07/20(日) 01:32:17 ID:L2XNyVag

>>751
> なんで考えるの？（クリエイトな意味で）
そりゃ、仕様が変わるからだよ。

設計で重要なのは、もちろん現状の分析結果を反映して実装に落とすための
枠組みを決めることだが、現実のプログラミングだと常に仕様変更がつきまとう。
そのときに、どこにどの程度の柔軟性を持たせるかによって、適切な設計が
違ってくる。

既存オブジェクトに対して新たな操作を頻繁に追加することが想定されるか、
あるいは操作はほぼ固まってるがクラス自体がガンガン追加される可能性が
高いか･･････対象物によらず、こういう視点での考察は必要だし、それに
応じた定石ってのもあるでしょ。

758 ：名前は開発中のものです。：2008/07/20(日) 01:34:55 ID:L2XNyVag

そもそも、分析から設計が一意に決まるようなら、分析結果を入力すると
設計結果が出てくるプログラム作成するよなｗ　プログラマ要らん。

759 ：名前は開発中のものです。：2008/07/20(日) 01:36:01 ID:itzBDsJr

>>753
そーんな話してないぞ
時間がなけりゃ対象物だって頭の中にあるのでもいいぞ
で、まあ、対象物はあるわけだ
当然だよな？どんなに急いでたってどういう仕様にするかは頭の中に組み立ててから組むよな？

次にそれがどういう構造をしてるのか考えるわけよ
ここで気をつけなきゃいけないのには自分でどういう構造をしてるのか作っちゃダメ
あくまで【対象物】を考えた仕様のまま構造を考える
ここで対象物が定まってないなら前の工程に戻れ仕様ができて無い

んで分析できたらそのまんまクラスに落としてこい
別に何がオブジェクトにならねーとおかしいとかそんなんいいからそのままクラスにしろ
まちがってても対象物を見てそうならそうしたほうがいい
ただし、自分アレンジを加える癖があったら気をつけろ

あとはうんにゃらかんにゃら詳細入れて終了
こんな感じだろ？

760 ：名前は開発中のものです。：2008/07/20(日) 01:40:46 ID:dhJxTFKo

あれだ
戦略家、孔明
戦術家、張飛
で議論してもまとまらないってことだw

761 ：名前は開発中のものです。：2008/07/20(日) 01:41:18 ID:itzBDsJr

>>755
>お前の「対象物の構造を素直にクラスに落とす」のはよいことだ。
>しかしそれはパターンを否定することにはならない。
嘘だよｗ
絶対共存できないｗ
おかしいってｗおいｗてめぇｗおかしいぞｗ

だいたいどこで使うんだよｗ
それを言ってけこらぁｗ

762 ：名前は開発中のものです。：2008/07/20(日) 01:48:13 ID:L2XNyVag

>>745
> おれは自分言語作ったときに評価関数内にきちんとVisitor使った。
マトモに作ると、構文解析終わったところで DAG かツリーで解析結果を
保持することになるけど、ここで再帰的に
・最適化
・デバッグ用に標準出力にダンプ
・実行コードの出力
・シンボルテーブルの出力
とかやりたくなるから、Visitor になってると、後々やりやすいやね。

俺は 1pass もしくは、1pass でないにしても全部解析する前に適当な
ところで最適化とて実行コードを書き出しちゃうようなテキトーな言語
処理系しか作ってないので、Visitor になってない。

ただ、これだと後から「分割コンパイルできるようにするため、シンボル
テーブル書き出そう」とか言った瞬間に、変更箇所が分散して後悔する
ことになる。

こういうトレードオフを想定した上での設計をする一つの指針が、
デザパタだと思うんだけどなぁ。あと同僚と議論するときに「Visitor に
しとけば」と一言で伝わるってのも、もちろんある。

763 ：名前は開発中のものです。：2008/07/20(日) 01:48:43 ID:Tcsf7iZJ

>>759
至極真っ当なプログラマ像だなー

俺はそこまで明確な対象物は持ってないし、仕様は後から決めるよ。
なんとなく使えそうな部品から作っていくタイプなんで。
ファイル読み込みとか、タスクシステムとかw

764 ：名前は開発中のものです。：2008/07/20(日) 01:53:37 ID:Tcsf7iZJ

>>763
そうやって、ボキャブラリ(関数、クラス、アーキテクチャ)を増やしてから、
何ができるか、何をすればいい感じになるのかを探ってる。

765 ：名前は開発中のものです。：2008/07/20(日) 01:54:13 ID:tmHWlv8v

>>761

お前さんが苦しくなってきたようだから潮時だな。

> >お前の「対象物の構造を素直にクラスに落とす」のはよいことだ。
> >しかしそれはパターンを否定することにはならない。
> 嘘だよｗ
> 絶対共存できないｗ
> おかしいってｗおいｗてめぇｗおかしいぞｗ

仮に共存できないとしよう。
お前さんの設計を人に説明するときに、GoFのパターンは一切使ってません、
とか言えるじゃないか。
このセリフは自由に使ってくれ。
じゃあな。

766 ：名前は開発中のものです。：2008/07/20(日) 01:56:29 ID:L2XNyVag

>>759
> あくまで【対象物】を考えた仕様のまま構造を考える
設計は、そんなに機械的にできる工程じゃないと思うんだけどなぁ。

じゃあさ、ゲームに組み込むためのスクリプト言語を作るとしよう。
用途はパラメタの設定や時間軸に沿ったイベント発生の制御など、
スクリプタは新人プログラマが担当することになったので、
ちょっとしたプログラミングできるぐらいの制御構造はあっても
使いこなせそう。

で、動的メモリ管理なしで Pascal ライクな文法にしようと決めた。

この先、スクリプトコンパイラの設計をどう進める？

767 ：名前は開発中のものです。：2008/07/20(日) 01:58:08 ID:itzBDsJr

>>765
結局、デザパタのなにも説明できてねぇじゃん

768 ：名前は開発中のものです。：2008/07/20(日) 01:58:44 ID:itzBDsJr

>>766
それって仕様を決める話じゃねぇの？

769 ：名前は開発中のものです。：2008/07/20(日) 02:01:03 ID:L2XNyVag

>>768
外に出す言語処理系ならともかく、プロジェクト内部で使うインハウスの
スクリプトなら、このへんで設計してさっさと動くもの作っちゃうでしょ。

770 ：名前は開発中のものです。：2008/07/20(日) 02:03:11 ID:itzBDsJr

>>769
でしょ？とかいってもその仕事が仕様決めである事実が覆るわけでもねぇぞ

771 ：名前は開発中のものです。：2008/07/20(日) 02:06:02 ID:L2XNyVag

>>770
言語仕様は Pascal ライクで良いと決めてあって、あとはゲームに
組み込むんだからスクリプトコンパイラはネイティブコードではなく
中間コードを出力して、ゲーム本体に中間コードのインタプリタ
組み込めば良いや、ぐらいまで決めとこうか。

で、具体的にコードに落とすためにクラス階層どうするよ？

772 ：名前は開発中のものです。：2008/07/20(日) 02:10:33 ID:itzBDsJr

>>771
そのままクラスにしたらいいんじゃない？
スクリプト（文字列？中間コード？フラッシュのオブジェクトに書くスクリプトみたいな？）を
誰にもたせてどう使うか？の仕様は決まってるんだよな？

だったら後は閉じた仕様だから外のオブジェクトに影響を与えることはないはずだよね
そのままクラスにしたらいいよ

773 ：名前は開発中のものです。：2008/07/20(日) 02:20:28 ID:L2XNyVag

>>772
そのままクラスって、具体的には？

たぶんスクリプトコンパイラのメイン関数はこんな感じだ。

int main(int argc, char** argv)
{
　　Compiler comp;
　　try {
　　　　comp.parse(*++argv); // スクリプトのソースが入ったファイル名を渡す
　　　　comp.outputBinary(*++argv); // コンパイル済みの中間コードを、引数のファイルに書き出す
　　} catch (std::exception& e) {
　　　　std::cerr << comp.getErrorMessage() << std::endl;
　　　　exit(1);
　　}
}

ただ、この Compiler クラスを機能させるためには、それなりに中身を
書く必要があるし、ボリュームも大きくなることが想定されるから全部を
1クラスにまとめず複数クラスに分割したほうが良いだろう。

そこを具体化していくのが設計だが、さっきから言ってる「そのまま
クラスにする」と、具体的にどうなるんだ？

774 ：名前は開発中のものです。：2008/07/20(日) 02:23:22 ID:itzBDsJr

>>773
そーんなところまでいきませんよー
だってスクリプトってぐらいだし文字列の塊を誰かがもってりゃいいんでしょ？
何が書いてあるかなんてぜーんぜん関係ないもん

実行して実際に指示出すのはインタプリタに接続する部分なんだからスクリプトなんて閉じた世界じゃない？
なんでそんなもののクラスの関連なんて気にしてるの？

やっぱ、設計下手っぴなんじゃない？

って同業者にドカンといわれると辛くて死にたくなるでしょｗ

775 ：名前は開発中のものです。：2008/07/20(日) 02:24:04 ID:L2XNyVag

設計は、上流工程の結果から簡単に導かれるものじゃないし、そこには
常にトレードオフがある。

設計の代表事例集であるデザパタを参考にすることで、設計を行う
指針となるし、また他人と議論するときにもイチイチ説明しなくても
話が通じやすくなる。

そういうものだと思うんだがなぁ＞デザパタ

776 ：名前は開発中のものです。：2008/07/20(日) 02:25:02 ID:GSRbJe3L

OOスレ12 プログラマならおじゃば好きだよな？
http://pc11.2ch.net/test/read.cgi/prog/1215645206/

おじゃば、こっちからでてくんなよ

777 ：名前は開発中のものです。：2008/07/20(日) 02:31:51 ID:wZdAPvcd

いまきた俺に
なにを議論をしてるのか３行でお願い

778 ：名前は開発中のものです。：2008/07/20(日) 02:32:01 ID:L2XNyVag

>>774
> だってスクリプトってぐらいだし文字列の塊を誰かがもってりゃいいんでしょ？
最終的には、その文字列の塊を解析して、実際にゲームで再生するところまで
持って行く必要がある。

スクリプトを「使う」側からすればブラックボックスでいいけど、スクリプト言語
処理系を「設計・実装する」側は、誰かが持ってれば良い、じゃなくてコードに
落とさなければ動かんでしょ。

で、ID:itzBDsJr は、どうやってコードに落とすまでのギャップを埋める（設計する）？

俺なら、スクリプトのソースコードのファイルを開いて読み込みトークンごとに
切り出して返すクラスとか、変数名や関数名を管理するシンボルテーブル管理
クラスとかリストアップして、シンボルテーブル管理クラスはいろんなところから
アクセスされそうだからシングルトンにしとくかなーとか考え出すところだが。

何度も「そのままクラスにしたらいい」と言ってるんだから、是非してみてくれ。
その過程で、デザパタの有効活用ってこういうことだよと実例挙げて突っ込める
場面があると思うから。

779 ：名前は開発中のものです。：2008/07/20(日) 02:45:47 ID:itzBDsJr

>>778
なんかごちゃごちゃいいわけ多いなぁ
僕のやってることはすごいんだぞぉって言いたいんですかぁ？

あの仕様ならスクリプトなんて所詮中間コードを出す役目しかないじゃない？
だったら他の何とも関わらないよね？思う存分スクリプト組めばいいじゃない
もう閉じてるんだから好きにしろよｗ
クラス：スクリプト、やること：文字列読んで中間コードを吐く、関連：おそらく中間コードを吐く機構があればそう

中間コードを受け取ってそれぞれ命令を出すのはインタプリタの仕事でしょ？
これも閉じてるよね？思う存分中間コードを命令に直したらいいんですよ
もう閉じてるんだから好きにしろよｗ
クラス：インタプリタ、やること：中間コードを読み取ってなにやら、
関連：中間コードを読み取る何か、中間コードを実行することで命令を出すものたち

これ以上複雑にならないのは確定してるよね？
いくらオブジェクト増やしてもどんなに複雑にしてもいいですよｗ
どうせたかが知れてますしｗ

これだけ決まってれば後は重要じゃないでしょ？
それともまだ何か必要？
多分ね、お前スキル不足で何が必要で何がプログラムを複雑にするのか見えてねぇんだよ

780 ：名前は開発中のものです。：2008/07/20(日) 02:47:36 ID:L2XNyVag

>>777
タスクシステムはアーキテクチャーパターンｗｗｗ
タスクシステムは PAC　PACマンセーｗｗｗ
PACとかMVCとか名前がついてる技術は怪しいぜｗｗｗ
んなこたねー。Visitor パターンとか一言で説明できて便利じゃん
デザパタ厨（・∀・）ｶｴﾚ!　デザパタなんて使わないぜ
設計どうしてんだ？
設計は対象物の構造を素直にクラスに落とせば良いんだよ。
((( ；ﾟДﾟ)))ｴ・・・ｴｴｰ!!　仕様変更とか想定しないのか
ここで対象物が定まってないなら前の工程に戻れ仕様ができて無い
じゃ、具体的にスクリプトコンパイラ作る手順について語ってみようぜ　←今ここ

781 ：名前は開発中のものです。：2008/07/20(日) 02:51:50 ID:L2XNyVag

>>779
> あの仕様ならスクリプトなんて所詮中間コードを出す役目しかないじゃない？
そうだよ。

> クラス：スクリプト、やること：文字列読んで中間コードを吐く、関連：おそらく中間コードを吐く機構があればそう
で、具体的にどうするの？　これだけじゃ、まだヘッダファイルも書けんよな。
まさか1クラス1関数で作るつもりじゃなかろうし、もう少し細かくしないと
コードに落とせないっしょ。

782 ：名前は開発中のものです。：2008/07/20(日) 02:55:41 ID:itzBDsJr

>>781
は？スクリプトの詳細まで決めるの？
勝手にやればぁ？
もう完全に閉じてるから設計としては十分でしょう
何がしたいの？
後はコツコツ、昇給のしない仕事しなさいなｗ
１人でこもってやる仕事ばかりつかまされる奴は給料上がらないんだぜｗ

783 ：名前は開発中のものです。：2008/07/20(日) 02:59:55 ID:itzBDsJr

>>781
いっとくけどそれって全部閉じた仕事だからね
もうここまできたら設計なんてどうやってもいいぜ
後はスクリプトが組める組めないの話でしょ？
わからないっぽい人だから細かくいってあげるけど
字句解析、構文解析を理解してるか？の話になるんであって
設計はさほど重要ではない
おもっくそC言語風味で組んでもぜーんぜんもんだいなーい

この話をできるできないで何かを主張しようとするのは無理だと俺は考えるがどうだ？

784 ：名前は開発中のものです。：2008/07/20(日) 03:01:40 ID:ZbM+kRVz

>>782
> もう完全に閉じてるから設計としては十分でしょう
齟齬がないように確認しておくけど「設計が終わった」というのは「実装が
開始できる」って意味だよね。

さすがに
>>779
> クラス：スクリプト、やること：文字列読んで中間コードを吐く、関連：おそらく中間コードを吐く機構があればそう
これじゃまだコード書けないから、設計終わってないでしょう。

これで OK というなら、ドラクエの設計も
int man(int argc, char** argv)
{
　　while (waitForVSync()) {
　　　　exec();
　　　　render();
　　}
　　/* NOTREACHED */
}
これで終わったことになっちゃうよ。
　　

785 ：名前は開発中のものです。：2008/07/20(日) 03:07:15 ID:ZbM+kRVz

>>783
> おもっくそC言語風味で組んでもぜーんぜんもんだいなーい
C言語でも設計するでしょ。C だと C++ と違ってクラス使わないだけで。

どう設計してもいいといってるけど、ともかく実装するには設計を終わらせないと
ダメだろ。「どうでもいい」じゃコンピュータは動いてくれん。

> この話をできるできないで何かを主張しようとするのは無理だと俺は考えるがどうだ？
デザパタを設計フェーズでかつようするという話がピンときてないみたいだから、
事例あげて現実に即した形で話そうかと思ってるだけだ。

786 ：名前は開発中のものです。：2008/07/20(日) 03:07:52 ID:itzBDsJr

>>784
じゃあ、クラス１つでいいよ
確実に問題が起きない部分に嫌にこだわるね
俺がどっかのスクリプト製作サイトからその通りに話するだけで満足なのか？

だいたい設計じゃなくて仕様が決まってねぇじゃん
複雑なのは仕様決めだけですでに設計じゃねぇし

何がやりたいのかはっきりしてくれ

787 ：名前は開発中のものです。：2008/07/20(日) 03:08:24 ID:itzBDsJr

>>785
じゃ、仕様を決めて

788 ：名前は開発中のものです。：2008/07/20(日) 03:18:00 ID:ZbM+kRVz

>>787
言語仕様は Pascal がベースだが、ゲーム組み込み用の小規模スクリプト言語として
仕様することを想定するので

1) 動的メモリ管理 (new, dispose) は不要
2) 入出力関数 (write, writeln, read, readln) は不要
3) C++ で記述してあるゲーム本体側のフリー関数を呼び出すための仕組みを用意する
　この関数は、開発中にどんどん増えていく
4) 分割コンパイル不要
5) 単純なスタックマシンあるいはレジスタマシンで実行できる中間コードに変換すること
　（ゲームプログラムでの実行速度向上のため）
6) リバースエンジニアリング対策として、ソースコード中のシンボルは極力残さない
7) (どっちかというとコンパイラより実行時の問題だが）マルチスレッド対応

っつー感じで。

789 ：名前は開発中のものです。：2008/07/20(日) 03:20:06 ID:ZbM+kRVz

>>786
> じゃあ、クラス１つでいいよ
せめてシンボル情報ぐらいはクラス（構造体でもいいけど）にしといたほうが…

790 ：名前は開発中のものです。：2008/07/20(日) 03:24:21 ID:itzBDsJr

>>788
は？ふざけてるの？
ドラクエ３作って、ただし、職業に戦士はいらないや
と同じレベルの仕様出して馬鹿じゃねぇの
もうちょっと掲示板で話が進む程度の規模にしてくんねー？
しかもパスカルしらないし、俺の知ってる言語は仕様がでかすぎて機能を制限するのも精一杯だぜ

あと、一ついっておくとこんな限定的な場面を想定して話進めても説得力薄いぜ
まず、どうやって話を進めて俺に説明するつもりなのか手順を教えてくれ

ついてってなんかなんにも的を射ませんでしたとか洒落にならない

791 ：名前は開発中のものです。：2008/07/20(日) 03:31:25 ID:itzBDsJr

>>789
中間コードにしちまうからぶっちゃけ
入力に文字列（スクリプト）、出力に中間コードがあれば中身はなんでもいい
設計なんてしなくても作ればなるようになっちまうレベルだと思うがね

難しいのはスクリプトが機能どおりに実装できるかどうかの話で
分析がどれほどできるかって話になる

792 ：名前は開発中のものです。：2008/07/20(日) 03:35:50 ID:itzBDsJr

あ、もしクラスで作るならね

ちなみに中間コードの仕様がどんなだか知らないけど
字句解析してそれぞれコードに直すだけになるんかね？
インタプリタのほうかな？こみいった実装になるのは
変数がどうたら、配列がどうたらってのは・・・

793 ：名前は開発中のものです。：2008/07/20(日) 03:42:55 ID:FRdAeOX9

なんでタスクシステムのスレでデザインパターンの論争してんだよw
GoFのパターン＝デザインパターンじゃなくて、デザインパターンってのは
「2回以上同じ実装」をしたら、それがパターンなんだよ。
それに名前付けたら便利だよねって話。

GoFのパターンを使うことがデザインパターンだと思っている奴が多くて困る。

794 ：名前は開発中のものです。：2008/07/20(日) 04:01:23 ID:yelSdOCQ

>>793
＞使うことがデザインパターンだと思っている
とにかくこの間違った思い込みがあって
そのうえで実装した経験がないことにコンプレックスがあるのかなんなのか
「○○パターンを使ってみました」とかいう物言いとかブログエントリもあったりで

795 ：名前は開発中のものです。：2008/07/20(日) 04:44:02 ID:wZdAPvcd

おはよー
つまりデザパタ本のパターン言語を使う派、使わない派って話だな

パターン言語を好もうが好むまいが、良い設計ができればそれでいいだろ
なんでどっちも喧嘩腰なんかね
「使わべき！」「使わないべき！」とか、すぐ「べき論」になるのはデザパタ・コンプレックスだろ

796 ：名前は開発中のものです。：2008/07/20(日) 08:33:18 ID:ZbM+kRVz

>>790
Pascal コンパイラのサブセットなんて書籍の1章で書ける程度だから、
ボリューム的にはちょうど良いと思うんだけどなぁ。これより小さいと
toy program で、それこそ「設計なんてしなくてもかけるよ」ってレベル
だろ。

別に Pascal じゃなくて C の freestanding 版から構造体・共用体と
ポインタ抜きでも良いよ。こっちの方が構文解析が面倒だけど。

> まず、どうやって話を進めて俺に説明するつもりなのか手順を教えてくれ
設計を進めてクラスとその関係を考察するときに、デザパタを
設計のベストプラクティスとして、どう活用できるかを具体的に
示せると思うけどな。

意外といろんなところからアクセスされる可能性があるシンボル
テーブルをどう持つか、とかさ。（シングルトン vs ファサードとか、
たぶん言葉は違えど同じ検討してるはず）

797 ：名前は開発中のものです。：2008/07/20(日) 08:52:18 ID:zgBZw03q

■デザパタを使うべき・使わないべき（過去プロジェクトを参照するか？的な意味で）
　新人「せんぱ～い、ここどうしてもわからないんですけどぉ～」
　PG　「どれどれ・・・・、ああこれは山田さんパターンだよ。別チームが作っている部分と橋渡しする都合でこうなってるんだ。」
　新人「ふーん、（・・・無駄が多いけど仕様変更多すぎて設計できてないんだろうな）」
　PG　「そうだ、次の案件では君にまかせるよ。わからない所は山田さんに聞いてね」
　新人「いえ、別チームの電話番号教えてください」
　山田「ﾌﾞﾋｰ」

■デザパタを使うべき・使わないべき（GoF大先生の書籍はどの職場でも本棚に飾ってありますよ的な意味で
　SE「デザパタの○○パターンでつくっておいてー」
　PG「へーい」

　PG「できやしたぜ」
　SE「え、なぜこの成果物は要求満たしてないんだぜ？」
　PG「だって、○○パターンで作るならこうなるのが当然じゃん」
　SE「そんなこと知らねぇし、打ち合わせで内容説明したよね」
　PG「だから○○パターンって言ったら普通そうなるでしょ」

798 ：名前は開発中のものです。：2008/07/20(日) 11:59:38 ID:itzBDsJr

>>796
だからパスカル自体しらねぇって

>別に Pascal じゃなくて C の freestanding 版から構造体・共用体と
>ポインタ抜きでも良いよ。こっちの方が構文解析が面倒だけど。
そんなもんわざわざクラス作んないよ俺
例が悪いんちゃう？

そもそもキーワード抽出して中間コードを出力するだけっしょ？
VBのStrSplitみたいなのがあったら１関数で終わる内容ちゃうん？

インタプリタの部分なら中間コードをどんな仕様にするかでちがってくると思うけど

799 ：名前は開発中のものです。：2008/07/20(日) 12:04:34 ID:itzBDsJr

あー、だからスクリプトクラス１つで終わりってことね
設計ないだろここ

800 ：名前は開発中のものです。：2008/07/20(日) 12:28:04 ID:+VLobiMW

>>796の最後で言ってる「意外といろんなところからアクセスされる可能性がある」云々を
仕様として定義しないとitzBDsJrはそれらを一切考えないというスタンスで居るんじゃないの？
それで、コードの保守性・再利用性を高める目的でパターンを推奨していくんだと思うんだけど、
だとすればその目的を念頭におくことを両者で一致させておかなきゃならないと思うけど、それは出来てるのかな？

801 ：名前は開発中のものです。：2008/07/20(日) 17:47:55 ID:RiFYBbX1

話は脱線するが、
ゲーム制作で、高級スクリプト言語仕様と、それを入力するインタプリタを確保してるの？
データ構造周知と、スクリプト・エディタと、中間コードだけでよくね。

802 ：名前は開発中のものです。：2008/07/20(日) 18:40:35 ID:itzBDsJr

>>801
意味わかんね
何が言いたいの？

803 ：名前は開発中のものです。：2008/07/20(日) 19:23:34 ID:3f1biKfa

ほんとにここは罵り合いしかしないスレだなぁ
でも、学歴板とかに比べたらまだましか

804 ：名前は開発中のものです。：2008/07/20(日) 19:35:16 ID:Tcsf7iZJ

スクリプトエディタまで作るのが夢ではあるけれど、
エターなりそうで、なかなか手を出せないなー。

805 ：名前は開発中のものです。：2008/07/20(日) 20:45:57 ID:itzBDsJr

>>804
志が低いな
スクリプトエディタって本当に必要か？って疑問はもったほうがいいぞ
Flashみたいなツールを一度触ってみるといいと思う

俺もスクリプトで色々入力するように作ってるけどそのほとんどが
画面くりっくして入力できねぇのかよこの値ってもんが多いから

806 ：名前は開発中のものです。：2008/07/20(日) 22:57:22 ID:Tcsf7iZJ

>>805
スクリプトエディタと言っても、その場で部分的な実行結果を試せたりするのがいいな。
画面上のオブジェクトがてくてく歩いたりするのをその場で確認できるみたいに。

このスレの主旨的に行けば、
空のタスクシステムが常に動いていて、
スクリプトエディタはタスクシステムに接続して
今書いてる途中のオブジェクトとかをさらっとタスクに変換してタスクシステムに登録、
オブジェクト単位で実際の動きを確認できる

んー、完璧だ。

807 ：名前は開発中のものです。：2008/07/21(月) 01:17:33 ID:Nr/a5JLC

class TaskObject : TaskState
{
Model a;
View v;
Control c;
static void exe(TaskObjects*);
}

これが、MVCタスクシステムだが
知らない奴多すぎだろ
もっと勉強しろ

808 ：名前は開発中のものです。：2008/07/21(月) 01:39:15 ID:RX6W/zkZ

デザインパターンの件はID:itzBDsJrが構文解析も知らないレベルとわかってどっちらけかww

> そもそもキーワード抽出して中間コードを出力するだけっしょ？
> VBのStrSplitみたいなのがあったら１関数で終わる内容ちゃうん？

低能っぷりがよく表現されてるよw

809 ：名前は開発中のものです。：2008/07/21(月) 02:10:42 ID:vlXSR/s8

ID:kk0986WJと同一人物かな。
なんで自分の得意じゃない分野で戦おうとするんだろ。
だから他人には質問するけど、質問されると答えられないんだよね。

810 ：名前は開発中のものです。：2008/07/21(月) 04:10:15 ID:teRzTwRr

>>808
大してズレがないのにそこで微妙な差分に拘っちゃってもいいことないぜ
C言語風味だったとして関数の流れを表現できる程度のキーワードを出てきた順番に
中間コードに入れてそこの処理はどう考えても終わりだ
他にすることはない

811 ：名前は開発中のものです。：2008/07/21(月) 04:46:39 ID:RX6W/zkZ

>>810
お前ID:itzBDsJrだろw
こんなバカな事を言うやつが2人もいるわけない
キーワードを置き換えただけってそれなんてBASIC？
置き換えるだけだと結局evalに複雑さを移しただけってことがわからない？
わからないよなー。

812 ：名前は開発中のものです。：2008/07/21(月) 08:34:20 ID:kxus2EQp

> VBのStrSplitみたいなのがあったら１関数で終わる内容ちゃうん？
俺もこの一言でだめだこりゃと思ったw

813 ：スーマリ in MVC：2008/07/21(月) 09:33:46 ID:oQB4h/tJ

MVCなんてネタだろって煽ってた>>645だが、本当は俺MVC派なんだよね
遅くなったが、代わりにスーパーマリオをMVCで書いてみましたよ
※入りきらないので３レスに分けてます

・マップ関係は省略してある
・通信対戦／協力プレイやペーパーマリオ（画面が2D/3Dで切り替わるマリオ）を考慮した
・プレイヤーがクッパや雑魚キャラを操作してみたい可能性も考慮した

個人的にはMVCは、Modelが十分複雑でViewも複数使い分けるシミュレーションゲーム向きだと思うが、
このくらい詰め込んだ仕様ならアクションでもMVCの出番だと思うんだ
どう？

814 ：名前は開発中のものです。：2008/07/21(月) 09:34:14 ID:oQB4h/tJ

ここでいうDomain（勢力）の定義：
　操作者単位での固まり。マリオ軍、ルイージ軍、クッパ軍のように分かりやすくまとめるためにある。
　通常プレイヤーが操作するマリオ軍ならマリオの他にファイアーボール類も含む。
　通常ＣＰＵが操作するクッパ軍ならクッパの他に雑魚キャラや敵弾も含む。

≪継承関係≫
Model
　←　GameModel　　　　　　　　　　 ※ゲーム全体の管理
　←　DomainModel　　　　　　　　　 ※各勢力の管理
　←　CharactorModel　　　　　　　　※キャラクターの座標、状態、ピクセルイメージなどを管理
　　　　←　MarioModel
　　　　←　NokoNokoModel
　　　　←　ItemModel

Controller
　←　DomainController　　　　　　※各勢力の操作
　　　　←　HostUserController　　※ホストユーザー操作用（1人プレイまたは通信時ホスト）
　　　　←　ClientUserController　※クライアントユーザー操作用（通信時クライアント）
　　　　←　AIController　　　　　　※CPU操作用
　←　CharactorController 　　　　　　　※キャラ操作用
　　　　←　PlayerCharaController 　　　※プレイヤーのキャラ操作用
　　　　←　AICharaController 　　　　　　※CPUのキャラ操作用
　　　　　　　←　AINokoNokoController ※敵キャラごとに作っていく
　　　　　　　←　AIItemController　　　　 ※アイテムも動きます
　　　　　　　←　AIFIreBallController　　※マリオが撃ったファイアーボールの操作
　　　　　　　←　AIMarioController　　　※CPU対戦プレイならCPUがマリオを操作することも
　　　　　　　←　ReplayCharaController ※リプレイ（プレイデータを元に操作する。タイトルデモなどに）

View
　←　GameView
　←　Charactor2DView　　　　　　 ※2D描画時のキャラクタ描画方法を管理する汎用View
　←　Charactor3DView　　　　　　 ※3Dに切り替わった時はこの View を使用する

815 ：スーマリ in MVC：2008/07/21(月) 09:35:09 ID:oQB4h/tJ

≪集約関係≫
GameModel
　◇-　DomainModel
　　　　　◇-　CharactorModel
GameController
　◇-　DomainController
　　　　　◇-　CharactorController
GameView
　　　　　◇-　Charactor2DView
　　　　　◇-　Charactor3DView

816 ：名前は開発中のものです。：2008/07/21(月) 10:28:58 ID:Nr/a5JLC

思考ルーチンはModelに
Modelはホストに置く、ホスト-クライアント間にRemoteFacadeを置く
どのユニットを動かすかはCで決定する
黒幕はピーチ

817 ：名前は開発中のものです。：2008/07/21(月) 10:32:56 ID:Nr/a5JLC

そんなことよりも、これがスーパータスクシステムだ
class SuperTaskSystem
{
TaskState* p;
MVC mvc;
}
class MVC
{
Model a;
View v;
Control c;
}
class SuperTaskExecutive
{
static void exe(TaskObjects*);
}
class SuperSingleton
{
static SuperTaskSystem getInstance();
}
class TaskObjects
{
void* objects;
}

818 ：名前は開発中のものです。：2008/07/21(月) 10:45:47 ID:teRzTwRr

>>812
はぁ？機能わかってる？
中間コードに落とすだけだよ

819 ：名前は開発中のものです。：2008/07/21(月) 10:48:35 ID:HHCwPw2H

じゃあ、俺はハイパータスクシステムね。
#include <list>
class Task
{
public:
    bool doTask();
};

class HyperTaskSystem
{
private:
    std::list<Task*> tasks;

public:
    void doTasks()
    {
        while ( !tasks.empty() ) {
            std::list<Task*>::iterator i = tasks.begin();
            while ( i != tasks.end() ) {
                 if ( (*i)->doTask() == true ) { i = tasks.erase(i); }
                 else { i++; }
            }
        }
    }
};

820 ：名前は開発中のものです。：2008/07/21(月) 11:04:38 ID:teRzTwRr

対象物の分析もしないでそんな仕組みから入ろうとした時点で
すでにオブジェクト指向的には死んでるよなｗ

なんで目的に即して無いコードを崇拝して強引に適用しようとするのか

821 ：名前は開発中のものです。：2008/07/21(月) 11:11:25 ID:RX6W/zkZ

>>818
> >>812
> はぁ？機能わかってる？
> 中間コードに落とすだけだよ

あのさコンパイラ/インタプリタの基礎なんて情報工学の初歩なわけ。
情報工学部ででりゃみな知ってる内容。
Pascalはp-codeという仮想スタックマシン用の中間コードに直される。
いまどき中間コードって言ったらそういうものを指す。
そういう常識的な知識を前提でみんなお前にデザインパターンの使いどころを
教えてやろうとしてたのに、そんなレベルでない全くの無知野郎ということがわかって全員脱力。
お前はそういう空気が読めずいまだ一人強がって知ったかを繰り返している。
という状況な。
まぁがんばってStrSplit駆使して志の高いスクリプトエディタ作っててよ。

822 ：名前は開発中のものです。：2008/07/21(月) 11:22:31 ID:Nr/a5JLC

バーチャルコードスピリットスクリプティングエディタアーキテクチャルパターニングタスクシステム
と名づけようではないか

823 ：名前は開発中のものです。：2008/07/21(月) 11:32:07 ID:oQB4h/tJ

>>816
>Modelはホストに置く、ホスト-クライアント間にRemoteFacadeを置く
あー、そうすね。その辺考えてなかった。地味にまともな意見だなあ

>思考ルーチンはModelに
そういう考えも分かるんだが、
Mと思考ルーチンは必ずしも同一のものとは限らなくね？
思考ルーチンからもプレイヤーからと同じく入力が発生すると考えれば
MではなくCになるのが自然と思わん？

824 ：名前は開発中のものです。：2008/07/21(月) 11:40:28 ID:oQB4h/tJ

あ、やっぱ撤回
Modelと思考ルーチンを分離する必然性がなんか薄いから、
実装の面倒くささを考えてまとめる方を選ぶ

825 ：名前は開発中のものです。：2008/07/21(月) 12:03:50 ID:oQB4h/tJ

連投スマソ
少し詰めて考えてみたが、全部>>816の言う通りだった
なんなんだ>>816は。的確すぎる。プロの設計屋か。ピーチ軍に変更しないと

826 ：名前は開発中のものです。：2008/07/21(月) 12:07:55 ID:OPrv4+8Z

Model = モニタの電源を落して放置してあるSimCity

827 ：名前は開発中のものです。：2008/07/21(月) 12:24:23 ID:teRzTwRr

>>821
え？その本にのってるC言語のサンプルだって
字句解析でそんなクラスをボコボコ作るような仕組みにはなってないよ
お前こそ何いってんの？

828 ：名前は開発中のものです。：2008/07/21(月) 12:27:05 ID:teRzTwRr

しかも、

>別に Pascal じゃなくて C の freestanding 版から構造体・共用体と
>ポインタ抜きでも良いよ。こっちの方が構文解析が面倒だけど。

この仕様で
結局、全体が把握できてないから作るもんが見えてこないんだろ？

自分がこれから手をつけるものを理解しようとしないから
いつまでもクラスに無駄な汎用性を入れ続ける

で、実際に要望があると自分が想定した拡張とは違うってことを毎回やってんだろ

829 ：名前は開発中のものです。：2008/07/21(月) 12:28:28 ID:teRzTwRr

だから対象物の分析もしないでいきなり仕組みありきでその適用方法を考える

かなづちをもつとなんでも叩いて解決しようとする馬鹿と同じだな

830 ：名前は開発中のものです。：2008/07/21(月) 23:43:37 ID:Nr/a5JLC

今までのまとめ

before
ピーチ「デザインパターン? し、知ってるわよそのくらい。
当たり前でしょ、バカにしないでよ。シングルトンのことでしょ」

after
ピーチ「新しいご主人様ですか？
出来るのは料理の下拵えと掃除、水汲みと牛と羊の世話、
裁縫、文字は少しなら読めます。
数は20まで…あ、死体の片付けもやっていましたから… 」

831 ：名前は開発中のものです。：2008/07/21(月) 23:58:06 ID:NSazL6fG

>>827
スクリプト言語の前に "1 + 2 * 3" みたいなテキストを受け取って 7 と
出力するプログラムを書けるか？

単純に文字列置換しただけじゃ、演算子の優先順位などを反映できない
から計算できない。

一般的には、スクリプトコンパイラで構文解析まで済ませて、あとは
現実の CPU が持ってる程度の極めて低レベルな命令セットだけで
記述できる中間コードにする。たとえば "1 + 2 * 3" を最適化なしで
中間コード化したら、こんな感じ。

push 1 ; スタックに1をつむ
push 2 ; スタックに2を積む
push 3 ; スタックに3を積む
multiply ; スタックトップから2つ値を取り除き、その積をスタックに積む
add ; スタックトップから2つ値を取り除き、その和をスタックに積む

演算子の順番と multiply, add 命令の順番が違うことに注意。

スクリプトコンパイラはこの発展系で、変数や制御構造を使えるように
したもの。変数スコープを持つ言語だとシンボルテーブルの管理が
必要になるけど、その辺で設計上の悩ましい問題がいくつか出てきて、
話のネタになる。

832 ：名前は開発中のものです。：2008/07/22(火) 00:15:19 ID:FTzfQVG0

戦略と戦術の区別がつかないらしいな
だから目的を見失う

完璧なものを作るのに必要なコストを10としよう
とりあえず動くものを作るのに必要なコストが1で
スクリプト実装はシステム全体の一部である
トータルで使えるコストが12だった場合
完璧なスクリプトを実装すると、他の部分に2のコストしか使えなくなる

マラソンの最初で全力疾走して体力を使い果たし
ビリになる人生もいいだろう
だが、そういう奴は戦略家になるべきではない
設計が戦略で、実装が戦術であるならば
それらをごっちゃに語るのは不毛というものだ

勝利への選択肢はただ二つだ
戦略を覆せるだけの戦術を身に付けるか
戦略を練るか

833 ：名前は開発中のものです。：2008/07/22(火) 00:41:02 ID:k2uoxLls

>>831
は？中間コードの仕様も決めないままそんなこと言われてもね
俺なら構文解析はしないでそのままキーワードを送る

なんたって仕様は

>別に Pascal じゃなくて C の freestanding 版から構造体・共用体と
>ポインタ抜きでも良いよ。こっちの方が構文解析が面倒だけど。

だ
演算子の順番なんてそんなにこらなきゃ解決しないほど困難な問題か？

とこれはすべて仕様の問題
設計以前に仕様がまとまっていませんでしたっていう話

834 ：名前は開発中のものです。：2008/07/22(火) 00:48:48 ID:SL2/omP2

とりあえずラーメン食べたい。

835 ：名前は開発中のものです。：2008/07/22(火) 06:59:06 ID:Gn4aw1TU

>>833
>は？中間コードの仕様も決めないままそんなこと言われてもね
>>788
> 5) 単純なスタックマシンあるいはレジスタマシンで実行できる中間コードに変換すること
>　（ゲームプログラムでの実行速度向上のため）

> 俺なら構文解析はしないでそのままキーワードを送る
構文解析は CPU パワーもメモリも食うし、未宣言変数の使用といった簡単なエラー
さえ実行時まで検出不可能になるから、ゲーム組み込み用の言語を作る際に、
構文解析を実機側で処理することの利点が見いだせないなぁ。

とはいえ、それでやるのなら、ゲーム本体側で動く仮想マシンのプログラム設計を
議論すれば良いね。

どうやって、構文解析されてないキーワードの羅列から、実行結果を得ます？
こっちはさすがに文字列置換関数呼び出して終わりとはいかないから、それなりの
設計が必要になると思うけど。

836 ：名前は開発中のものです。：2008/07/22(火) 07:08:40 ID:k2uoxLls

>>835
じゃあ、その仕様でいいよ
こっちが出してそれを否定する形じゃないと仕様だせないんでしょ？
で？中間コードはどう出力するの？

837 ：名前は開発中のものです。：2008/07/22(火) 07:13:18 ID:k2uoxLls

ところでまだ仕様決めで止まってるよね？
いつになったらデザパタの話になるの？

838 ：名前は開発中のものです。：2008/07/22(火) 12:41:13 ID:lqkc6SFE

構文解析をしないなどとトンデモを言い出すID:k2uoxLlsが話を止めてると思われ。
仕様が決まってないからわからないってのも見苦しい。。
CかPascal風って指定されてたらとりあえず構文木までは考えられるだろう？
まぁ2chだからへこたれずにえらそうな口ぶり叩くのは結構だけど、
その程度の常識すら持ってないことは恥じた方がいいよ。

お前が使えるプログラミング言語って何？
JavaやC#あたりが使えるならデザパタの使いどころなんていくらでも実例で教えてやれるよ。

839 ：名前は開発中のものです。：2008/07/22(火) 19:02:02 ID:D7I1DdfG

はぁ？
いきなりお前の常識いわれてもね
わけわかんない
俺の常識ではデザパタなんか信仰してる奴はオブジェクト指向を理解できてないってのは上のほうに書いた通りだけどね

ところで、ここまで全然デザパタの話が出てこないけど
こんなんで人に説明できんの？
さっきから全然進んでないけど？笑

さっさとデザパタ使って設計してみろよ

840 ：名前は開発中のものです。：2008/07/22(火) 20:02:43 ID:YDynM3nZ

連レスしまくる奴は頭に血が昇っちゃってるから
レス返したところで話にならない

相手の頭が冷えるまで放置がbest

841 ：名前は開発中のものです。：2008/07/22(火) 21:35:15 ID:lqkc6SFE

そうだな。
また話そらしてるし。

842 ：名前は開発中のものです。：2008/07/22(火) 21:43:11 ID:Twvs+lsL

>>836
> で？中間コードはどう出力するの？
設計どうするのかという質問に対して ID:itzBDsJr が >>772 で「そのままクラスに
したらいいよ」と言われていたので、実演して頂くのがよろしいかと思います。

あとクラス設計に関しては、唯一の正解というのはないから、別に間違ってるとか
言うつもりはないよ。（そもそも、それは理論的に動かないだろ、というのは別）

ただ、そこで出てきたクラス設計に対して具体的に議論するときに、デザパタを
共通言語として使うとか、あるいは設計を見直す一つの基準として利用する方法を
実演できればなと思っております。

843 ：名前は開発中のものです。：2008/07/23(水) 00:50:33 ID:jVy4QnhU

いやいや、目的と手段が逆転して
使えそうなところだからという理由でデザインパターンを適用するカスが
少なからず存在しているという事実はまさにタスクシステムであると言えよう
使った後どうなるかまで考えられない奴にデザインパターンは無駄だし
アーキテクチャなんて声に出すことも許されぬぞよ

844 ：名前は開発中のものです。：2008/07/23(水) 00:53:15 ID:Ggpkpx1w

だって使ってみないとわかんないんだもん。

845 ：名前は開発中のものです。：2008/07/23(水) 00:55:32 ID:jVy4QnhU

本棚作る目的でねじをどう使うかという話が
ねじをどうやって作るかという話になってしまったのが笑えるところだろう
あえて口出しせずに見守っていたが、やっぱりセンスないなw
黙ってみているとどうやって鉄を作るかという話に発展しそうなので
このまま続けてくれたまえ

846 ：名前は開発中のものです。：2008/07/23(水) 01:12:16 ID:jVy4QnhU

使ってみないと判らない人は設計のセンスがないからさ
無理に設計能力を伸ばそうとせずに
それ以外の技術を伸ばした方がいいぜ
小規模なプログラムなら設計なしで強引に書いてもなんとかなるもんだからな
中規模ぐらいまで強引に実装できるようになれば
それはそれで価値のあるプログラマだ

847 ：名前は開発中のものです。：2008/07/23(水) 02:59:51 ID:ZCUkFON2

>>842
は？仕様が決まってないって話なのにいきなりズレたこといわないでよ

848 ：名前は開発中のものです。：2008/07/23(水) 11:08:58 ID:l9AUHAux

じゃあおれが決めてやろう
中間コードはCOMET II 用で
ファイル形式はelfで。
これでOK？
デザパタを一切使わない設計に期待しているよ。

849 ：名前は開発中のものです。：2008/07/23(水) 12:35:30 ID:fGe0JihC

デザインのパターンを・・・一切・・・使わない設計・・・！！！

つまり今までにない完全に独創的で新しい設計ということだな

850 ：名前は開発中のものです。：2008/07/23(水) 13:42:13 ID:vkUSy46V

>>110からたった２ヶ月で800越えか

851 ：名前は開発中のものです。：2008/07/23(水) 19:44:09 ID:ZCUkFON2

>>848
その仕様がなにか知らないけど
いままでに決まった仕様に沿った内容なの？

まさか、テキトーにいってんじゃないよね？

852 ：名前は開発中のものです。：2008/07/23(水) 20:21:14 ID:Pe/qXrZJ

死ねばいいのにね。

853 ：名前は開発中のものです。：2008/07/23(水) 20:52:12 ID:HMainoZl

>>851
> その仕様がなにか知らないけど
COMET II は情報処理技術者試験のために作られたハードウェア仕様で、
実機は存在しない。レジスタ型 16bit CPU だから、実際にゲームに組み
込むとなったら

1) レジスタ・主要演算の 32bit 化
2) 浮動小数点数演算への対応
3) SIMD命令への対応 (単精度浮動小数点数演算 x 4)

ぐらいの拡張はした方が現実的かな。

レジスタ型の仮想マシンなら、いっそ Lua 5 のようにレジスタウィンドウを
使って引数渡しに伴うスタックアクセスを減らし、レジスタ数 256 本に
増やして、ローカル変数大杉でレジスタ割り当てに失敗したらコンパイル
エラーにしちゃうぐらいの割り切りでも良いとは思う。

あとはスクリプトの用途や VM の仕様にもよるが、割り込み機能も
欲しくなるかもな。まぁ、使ってて必要になったら後から拡張すれば
良いと思うけど。

ELF は…知っとけ。PlayStation 系の開発やるときに、さんざんお世話に
なってるだろ。

854 ：名前は開発中のものです。：2008/07/23(水) 21:57:30 ID:ZCUkFON2

>>853
それはいいけど
いままでの会話をすべて無視してなんでそんな話しだすの？

855 ：名前は開発中のものです。：2008/07/23(水) 22:49:41 ID:MeekYGu4

>>853
>ELF は…知っとけ。PlayStation 系の開発やるときに、さんざんお世話になってるだろ。

FreeBSD3～もね

856 ：名前は開発中のものです。：2008/07/23(水) 23:15:51 ID:fNE8bAsp

つーかSystemV->Linux->*BSD系に流れて
ELFはUnix系ではもはやデファクトでは？

857 ：名前は開発中のものです。：2008/07/23(水) 23:34:56 ID:fHPaBTiX

ELFってLinuxだけの規格じゃなかったんだな
BSDはいまだにa.out形式使ってそうなイメージ

858 ：名前は開発中のものです。：2008/07/23(水) 23:42:56 ID:49AhZYtL

>>857
GNU binutils が a.out サポートしてくれなくなったので ELF に移行しますた。

859 ：名前は開発中のものです。：2008/07/24(木) 02:13:20 ID:OnRrUiS0

ID:ZCUkFON2 がこれから分析する対象物の仕様をまとめてみた。
すばらしい分析を期待してる。
口だけじゃないところを見せつけてやれ！

---

ゲームに組み込むためのスクリプト言語を作る

[仕様]
入力はASCIIテキストデータ。
ASCIIテキストは次の文法を持つ。
- C の freestanding 版から構造体・共用体とポインタ抜いたもの。
1) 動的メモリ管理 (new, dispose) は不要
2) 入出力関数 (write, writeln, read, readln) は不要
3) C++ で記述してあるゲーム本体側のフリー関数を呼び出すための仕組みを用意する
　この関数は、開発中にどんどん増えていく
4) 分割コンパイル不要
5) 単純なスタックマシンあるいはレジスタマシンで実行できる中間コードに変換すること
　（ゲームプログラムでの実行速度向上のため）
6) リバースエンジニアリング対策として、ソースコード中のシンボルは極力残さない
7) (どっちかというとコンパイラより実行時の問題だが）マルチスレッド対応

出力は、中間コードとしてCOMET II(CASL II)のマシン語。
中間コードの実行系は考えなくてよく、ELFファイルとして出力して終わり。

860 ：名前は開発中のものです。：2008/07/24(木) 05:58:48 ID:l33hdtup

>>859
で？
正直、俺にはその仕様が互いに
矛盾を生んでいるかどうかまで判断できないし
まったくやるつもりもないけど

そこまで細かく決めて
どういうクラスを抽出してどういう順序でデザパタの使い方を説明するつもりなのか
プランを出してよ

こないだから全然デザパタの説明をするところまでいきついてないじゃん

861 ：名前は開発中のものです。：2008/07/24(木) 06:07:49 ID:l33hdtup

そもそもスクリプトの話ってスクリプト自体の仕様の複雑さを盾にして
デザパタの説明ができないを逃げるためにそんな仕様だしてきた臭がするんだよね
だってこないだから全然デザパタの説明まったくする気ないと言っていいぐらいの態度だし

しかも、他との関連がないところまで閉じてるのに
これ以上設計にこだわるところがすげーアフォだと思う

なんの要素が出てきても設計につまることはもうないでしょ？

結局、どんなに複雑になっても

スクリプト→字句解析→構文解析→中間コード→インタプリタ→各種オブジェクトへの命令

の流れが決定していて必要なデータもわかってるし
関連もインタプリタが吐き出す命令の先にしかないなら
このクラスの設計は後は作りながらつめていく程度でもう問題ないでしょうが

この話がいや違うっていうならまずポイントをいってくれ「ぷｗなにもわからないんですねｗ」系のレスじゃ
こっちもレスのしようがない

862 ：名前は開発中のものです。：2008/07/24(木) 08:24:49 ID:q53lO+wj

>>861
> なんの要素が出てきても設計につまることはもうないでしょ？
口だけでなく、そろそろやって見せないとダメでしょ。分析終われば
設計なんて「そのまま」できると言い切ってたんだし、簡単なんで
しょう？

> 字句解析→構文解析→中間コード
おおざっぱな処理の流れはその通りだけど、そこからクラスを切り出して
関連を見極めていく（＝OOD での設計）作業しないと、まだ実際にコードを
書き始められない。

たとえば、C, Pascal 系の言語だと、字句解析と構文解析は情報の
流れは双方向になるのが一般的。構文解析の結果としてシンボル
テーブルに変数・関数名を登録して、それを字句解析ルーチンで
利用する。

そうすると、少なくとも「シンボルテーブル」クラスみたいなものが
出てきて、これをどう関連づけるかは議論の余地があると思うん
だよな。ファサードにするのかシングルトンにするのかとかさ。

ID:l33hdtup は、設計は「そのまま」できるそうなので、どうやるのか
期待してるけど。

863 ：名前は開発中のものです。：2008/07/24(木) 16:58:44 ID:lu8D7EIy

話が具体的になってきたね。興味深い
煽り合いで終わらない事を期待

864 ：名前は開発中のものです。：2008/07/24(木) 18:07:32 ID:rYsctoQh

>>846
お前さ、頭おかしいんじゃねえの。
設計なんて、経験則の塊みたいなもんだろが。
お前は人にものを教えるセンスがない。口をつぐんでいろ。
うっとおしいんだよ。

865 ：名前は開発中のものです。：2008/07/24(木) 20:06:59 ID:aCGqGBH0

>>844
何をしたら分かるのかっていう点では
コピペして使っただけじゃわからないだろうな
パターンはテクニックではなく「言語」だから
漢字書き取りみたいな真似を何度やっても
パターンの生まれたのと同種の課題に直面した経験がなければ
理解はできないだろう
実装ばっかりじゃなく動機の項にもっとリスペクトを払ってほしいな

866 ：名前は開発中のものです。：2008/07/24(木) 20:08:08 ID:l33hdtup

>>862
>口だけでなく、そろそろやって見せないとダメでしょ
俺が考慮できていない部分があるなら言ってよ
ただ、それは仕様を追加する形でって話になると思うよ
この仕様でやることっていったらもうこれだけでしょ？

考慮漏れなら具体的に指摘してくれない？
無いものを想定して無駄な汎用性なんて作る意味ないんだから

867 ：名前は開発中のものです。：2008/07/24(木) 20:08:51 ID:l33hdtup

>>865
それだともうお手軽とか万人のって意味ではカタログ化は失敗だったってこと？

868 ：名前は開発中のものです。：2008/07/24(木) 20:28:36 ID:aCGqGBH0

>>867
言語であるがゆえに使用者の理解が不完全でもそれなりに「使える」
使えるっていうのは言語として役目を果たすことができるって意味でね
テクニックとして利用していいことがあるっていう意味じゃなくてね

869 ：名前は開発中のものです。：2008/07/24(木) 20:41:16 ID:/W9QFH2y

カタログめくりながら使えそうなテクニックをとりあえず試してみるのが好きなんだけどな。
「このテクを使えば貴方のプログラムの性能が30％アップ！！(当社比)」みたいなワクワク感がたまらない。

870 ：名前は開発中のものです。：2008/07/24(木) 20:49:06 ID:fW8G9awG

同時に2つも3つも話題を平行して話すもんじゃねぇぜ。
今は結局デザパタの話をしてるでいいの？

871 ：名前は開発中のものです。：2008/07/24(木) 20:49:36 ID:SJ4kGGE/

まだ連レスやめてないんだ

デザパタって、よくある形に名前をつけただけなんだから、
適した形に変形させて使うのは当たり前。

ってことがまずわかってないんだろうな

872 ：名前は開発中のものです。：2008/07/25(金) 01:48:31 ID:CqwgQ9cb

つまり

> スクリプト→字句解析→構文解析→中間コード→インタプリタ→各種オブジェクトへの命令

で分析終了、詳細な設計は自明だから省略ってことか。

デザパタを説明する側は構文解析以降の中身が本題だと思っているのに、
そこを ID:l33hdtup はスルーするからかみ合わない。

おそらく、ID:l33hdtup は構文解析において何がオブジェクトになるべきか見えていないのだろう。
単純に文字列の置き換えを繰り返すだけの処理でなんとかなると思ってるようだ。
そんな生易しいものじゃないよ。

この点ですでに「対象物の構造どおり分析した結果をクラスにする」というのができていないんだよ。
このスクリプトの例のように抽象的なものを対象にする場合デザインの仕方は幾通りもありえる。
車はタイヤとハンドルをhas-aの関係で持っていて・・のようにはいかない。

873 ：名前は開発中のものです。：2008/07/25(金) 01:56:51 ID:CqwgQ9cb

ID:l33hdtupにデザパタの説明するためにもっと単純な例にしよう。

文字列クラスを作ることなった。
さてどうする？

とっかかりだから正解はなし、自由に設計してよ。
その後、特定の問題解決のために改造していこうと思う。
基本的なメソッドだけでいいから。
C++、C#、Javaあたりでよろしく。

874 ：名前は開発中のものです。：2008/07/25(金) 02:03:52 ID:yGUQzIBd

どうやってスクリプトを実装するかよりも
なぜどこにスクリプトを使うかの方が重要だと思うけど
そんなことはどうでもいいことだ
スクリプトを導入すれば何かすごいんだぜという言葉を信じて
適用して、なんだか実装が増えただけでいいことはなかったぜという
数多の屍の声が聞こえるが
そんなことはどうでもいいことだ
だから、あえて言おう
タスクシステムを導入すれば何かすごいんだぜ

875 ：名前は開発中のものです。：2008/07/25(金) 06:21:32 ID:EQBL+69o

>>872
ここまで具体的に言ってるのにまだそんなこといってるの？
具体的に何が足りないって言えよ
全然、話が進まないじゃん

876 ：名前は開発中のものです。：2008/07/25(金) 08:30:05 ID:gpMhzAIq

>>875
クラス図

クラスとして何を切り出して、その間の関連をどうするのか決めないと
コーディングできない。

877 ：名前は開発中のものです。：2008/07/26(土) 07:11:19 ID:NbK1Tsil

黙ったのかつまらない話だった
スクリプトの設計って笑わせてくれるよ
特徴も何も提示せずに設計なんてあるわけないだろw
適当なスクリプト言語なんて何も考えずに適当に作ればいい
拡張性の高いスクリプト言語の設計
エラーに強いスクリプト言語の設計
高速に動作するスクリプト言語の設計
のような話にはならなかったな、くだらない揚げ足取りばかりで
本当につまらない人達ですわ、おほほほほw

878 ：名前は開発中のものです。：2008/07/26(土) 09:40:11 ID:gIOOb9bB

>>877
そんなのあるわけない
汎用的なスクリプトなんて必要ない
もし、そんなものがあったとしても
ちっちゃいプログラムにそんな複雑なもん導入する馬鹿なんて消えてなくなったほうがいい
だいたいそんなスクリプトもしバグッたらそいつしかデバッグできない

どっちかというと
簡単な仕様でなんにでも使えたほうがいい気がするけどね
タブ、スペース、キャリッジリターン、リターン、カンマあたりをデリミタにして
なんでもできるほうがプログラムも簡単でいいと思う

ここで上のほうで出してた
インタプリタのくせに字句解析と構文解析が複雑で前後の文をみないと
そのキーワードの意味が確定できないような
仕様は正直ゲームに向いてないと思う
変数を宣言された、配列を宣言された、構造体を宣言されたとか
もう正直、お前、何が作りたいのかと・・・複雑な処理はC言語のほうにまかせてスクリプトはそれを実行できたらそれでいいんじゃないかと・・・

デザパタ云々言ってたけど本当に必要なのは
仕様の実現に必要な機能とそれを実現するために
必要なコストが理解できていることだと思う

879 ：名前は開発中のものです。：2008/07/26(土) 14:25:52 ID:PPmEaFGQ

>>878
あからさまな釣りに答えてやるなよ

880 ：名前は開発中のものです。：2008/07/27(日) 09:50:18 ID:1ENZqqIw

なんて言うか、話についていけない、、、

881 ：873：2008/07/27(日) 10:32:04 ID:K8t5mvQz

文字列の設計もできないの？
なんだよそれ

882 ：名前は開発中のものです。：2008/07/27(日) 12:23:58 ID:lCBclQ6o

わからないものはわからないでいいんだよ
わかったようなことを言う奴ほど騙される
ゲーム脳やマイナスイオンなんかと同じ
それがタスクシステム
誰もそれを使うメリットを明確に言うことができない
ただ周りがすごそうと言ってるから使っているだけ

>>881
おまえバカだろ、自覚したほうが向上する機会が得られるだろうが
お前ごときではそれも望めないな
ボールくらい誰でも作れるだろ
でも、サッカーボールもバスケットボールもテニスボールも
全てボールだが全く違う
目的ごとに作るものなんてのはいくらでも変わる
お前は何も理解できない、他人の話も理解しようとしない
物の違いも判らない、ただくだらない虚栄心を満たすためだけに
他人を見下して優越感に浸るだけ
なんだよそれ

883 ：名前は開発中のものです。：2008/07/27(日) 15:38:47 ID:4i7Zed7z

全ての書籍に目を通しているわけではないが、
個人的にはタスクシステムについては、以下が指南書だな。

>>7
＞■逆引き本
＞逆引きタスクシステム
＞http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1169-X

上の書籍名は間違っており、正しくは「逆引きゲームプログラミング」だが、
キャラの移動、当たり判定はもちろん、
タイトル表示、オプション設定、格ゲーの隠しキャラの扱い、
RPG、カードゲームに至るまで、
トピック毎の全サンプルが全てタスクシステムに乗っかっているから、
皮肉ってるのか？

トピックが豊富で退屈しない。
全体はスパゲッティだが、部分部分のコードは解決法として参考になる。

スレ冒頭のWebサイトはともかく、その他の殆どの本は、
タスクシステムには全く触れてないのとちがう？

884 ：名前は開発中のものです。：2008/07/27(日) 20:13:21 ID:qGLc5Q1K

>>878
> インタプリタのくせに字句解析と構文解析が複雑で前後の文をみないと
> そのキーワードの意味が確定できないような
> 仕様は正直ゲームに向いてないと思う

そうは思わないなぁ。

エフェクト作成用のスクリプト言語として、俺が最初に作ったスクリプト言語は
マクロアセンブリみたいな「構文解析簡単」「使うために必要な知識最小限」の
やつ。
プロジェクト序盤は良かったんだが、エフェクトが高度になってスクリプトの
ソースが長くなるに従い、可読性の低さと再利用性の低さがネックになって
スクリプトのデバッグが大変だった。

その反省を踏まえて、後で C 言語ライクな LALR(1) + シンボルテーブルを
使うタイプの言語を作ったんだが（配列や構造体・ポインタはなし）、こっちは
スクリプタの初期教育コストが多少高くついたけど、後半の開発効率の高さで
報われた。
逆に問題になったのは、スクリプトでライブラリが書きためられたが、あまり
高度な最適化を実装してなかったので、速度が落ちたこと。結局、いくつか
使用頻度が高いライブラリを C++ で書き直して、スクリプトからは、それを
呼び出せるようにして乗り切った。

885 ：名前は開発中のものです。：2008/07/27(日) 23:57:43 ID:6tHhtazc

とりあえず100レス前あたりから読んでどんな内容か概略書くわ

886 ：名前は開発中のものです。：2008/07/28(月) 00:38:57 ID:pQ/Ku1z0

>>885
おねがいします
５行以上のレスを飛ばしてたら、ほとんど読めてない俺

887 ：名前は開発中のものです。：2008/07/28(月) 00:44:33 ID:H3XajAOv

>>780にここまでの概略あり。

>>766あたりからスクリプトの仕様考えようぜ。
(以下、時々デザパタの話が出つつ、過度に抽象的、または逆に限定的過ぎる話が続く。)
>>861結局スクリプト→字句・構文解析→中間コード→インタプリタ→オブジェクトへの命令何だよ
>>862じゃあつくれよ
>>872 >>861はデザパタがわかってない阿呆。
以下有益な情報も特になく、残った燃料で罵り合い。

なんかレスを追ってくと過剰に複雑な仕様を定義しようとしてる。
素で「ゲームエンジンプログラミング」と同等かそれ以上のスクリプト関連仕様を作ろうとしてる。
そりゃ不毛な話になるだろってもんだ。

888 ：名前は開発中のものです。：2008/07/28(月) 01:43:13 ID:t8hIlc4I

おれが見てた感じだと、

- タスクシステムの話からMVCの話題がでる
- そこにデザパタ否定者(A)あらわる
- 続いてそいつにデザパタの使い所を教えようとする人たちが現れる
- 例としてスクリプトの処理系の場合をあげる
- Aがそんなの閉じた処理？だからデザインする必要がないという
- それに加え仕様がはっきりしないから考えられないとも言う
- よってたかって仕様が詳細化w
- Aは結局デザインする必要がないと言う主張を繰り返し話に乗ってこない
- どうでもよくなってきてgdgd

だな。
まぁ正直なところAをいじって楽しんでたよな、お前らw
誰もAがスクリプトの処理系を作れるとは思ってなかっただろw

889 ：名前は開発中のものです。：2008/07/28(月) 11:12:39 ID:oWkIHcxy

デザパタ否定派は、そもそもデザイン自体を否定しているつー結論？

890 ：名前は開発中のものです。：2008/07/28(月) 12:40:17 ID:IEYvhaoV

バカの一つ覚えみたいに
知っているパターンを使えそうな箇所を見つけると、すぐに使う人がいるから

891 ：名前は開発中のものです。：2008/07/28(月) 13:33:43 ID:MvrMmBqL

そんなにタスクシステムが好きなら関数型言語をやるべき。
Haskellでやれ

892 ：名前は開発中のものです。：2008/07/28(月) 14:58:43 ID:DLaHpqww

何事もチャレンジだよ諸君。

893 ：名前は開発中のものです。：2008/07/28(月) 15:53:26 ID:iELvMsPQ

switch使わずにif文とな！？

894 ：名前は開発中のものです。：2008/07/28(月) 17:26:36 ID:9jl+r+is

>>888
議論を収束させずにわざと放置されるようにして
その状態をみて何をか言わんとするやりかたは好きじゃない
俺がやられたらもれなく無視するよ

895 ：名前は開発中のものです。：2008/07/28(月) 18:55:04 ID:t8hIlc4I

>>894
おれに言われてもw
スクリプトの例を出した人はまじめに説明しようと思ってたと思うよ。
だいたいどういうネタで説明しようとするのか予想がつくし。
ただA君には例がよくなかった。
最後の方の文字列の例は単純でいいと思ったけどなぜかこれにも反発したのは理解できん。
感情的になって議論する気がうせていたんだろうか。

896 ：名前は開発中のものです。：2008/07/28(月) 20:14:49 ID:W7cjwzrR

>>895
俺は無理だと思うよ
デザパタの説明できた奴ってみたことないし

897 ：名前は開発中のものです。：2008/07/28(月) 23:01:31 ID:t8hIlc4I

>>896
A君だねww
おれ議論するつもりないからw

898 ：名前は開発中のものです。：2008/07/28(月) 23:36:42 ID:W7cjwzrR

>>897
自分の意見を人と戦わせると負けちゃうからでしょ？
そうやって逃げてばかりいると技術者としてどんどん弱くなっていくよ
別に君だけにいえることじゃないけど
なんか最近掲示板にくる人みてると新しい価値観を知るのが怖いってのが
見えるような人ばっかりだね

そんなに不変的なものによっかかって生きてくのが好きなら技術者なんて辞めちまえばいいのに
って思う

ちょっと意見出すとすぐに逃げるしね
人と議論して戦わせないと強くならないし、伸びていかないぞ

会社にくる新人もみんなこんな感じ
どういう理由でそうやってるの？って聞いても全然自分の意見を言えないし
必ず後だしジャンケンで様子見決め込んでから相手の意見を出させてそれに対しての「感想」しか言わない
プログラムも設計ができるできない以前に必要なことと、それにあった仕様を自分で考えて提示できない
できないからデザパタみたいなパターンがお好きなのかな？
そのパターンで今後でてくるすべての仕様を強引に捻じ曲げて当てはめようとしても限界あるぜ

899 ：名前は開発中のものです。：2008/07/28(月) 23:55:33 ID:xeGnfa43

>>898
> そうやって逃げてばかりいると技術者としてどんどん弱くなっていくよ
この文章に続けて、技術論ではなく精神論語るってのは、どういう冗談？

900 ：名前は開発中のものです。：2008/07/29(火) 00:18:31 ID:sunKVfGn

>>899
？？
逃げるなってのは精神論じゃないのか？

901 ：名前は開発中のものです。：2008/07/29(火) 00:18:47 ID:k1c5jdwC

>>899
こんなもんに頼ってこんな程度の態度しかとれないのは精神的な部分が大きいと思ったんだけど違うの？

902 ：名前は開発中のものです。：2008/07/29(火) 00:19:36 ID:BXX1E+Vq

デザパタを教えてもらう立場なんだから謙虚になれよ。
構文解析知らない程度の人が何言っても強がりにしか聴こえない。
そりゃデザパタを知りたくないのなら勝手に吼えてりゃいいよ。
でも知りたいんだろ？
せっかくお題出してもらってんのにことごとく逃げてるのはお前だよ。

903 ：名前は開発中のものです。：2008/07/29(火) 00:24:17 ID:sQXNHg8a

>>898
もう飽きてきた
逃げてんのはお前だろｗｗｗって言って欲しいんでしょ

904 ：名前は開発中のものです。：2008/07/29(火) 00:43:53 ID:kU/rSVMT

>>895
始めから議論なんかするつもりの無い奴もいるさ。
つまりいじってるつもりでいじられてたと。

実のある話をしたいなら話の通じる奴だけ相手にして
それ以外は無視した方がいいんじゃね。
どうしても合わない奴がいるのも現実だし。
いじって遊ぶなとは言わないけどさ、本懐を忘れない程度にほどほどに。

905 ：名前は開発中のものです。：2008/07/29(火) 01:00:46 ID:k1c5jdwC

>>884
可読性がネックになるまで複雑なスクリプトになってしまうのが原因だと思うね
そんな複雑なもんできるならC言語で追加しやすいようにしたほうがよかったんじゃない？
どうせそれをスクリプトで呼べばいいんでしょ？
企画の人でも、設計やるわけじゃないんだし、あんまり複雑なのはC言語で書いちゃったほうが早いと思うけど
なので俺はC言語で追加しやすいようにしてスクリプトの仕様はできるだけ軽くなるようにした

タブ・スペース・カンマ・リターン・キャリッジリターンのデリミタでできるのがまず条件

これ以上意味無いのに構文解析を中間コードに落とさないとどうにもならない
その手間ってのがアフォらしくてね

ちなみに俺は変数の宣言とかすら煩わしかったので
変数はローカル用変数（関数抜けると初期化）としてL0000～LFFFFまで
グローバル用変数としてG0000～GFFFFまで用意して
グローバル用の変数はエクセルで管理してるけどね（セーブデータもG0000～GFFFFまで保存するだけ）
定数はT0000～TFFFFまでとかほかS0000とかH0000とか色々あるけど
ゲーム中にずっと残るのはエクセルのほうで一覧で管理（もし、わかるように書きたいときはコメントに書く）
こうやって連番でつけてる分実行時にはデバッグモードでリアルタイムですべての値を確認可能にできる
C++仕様にすると宣言されるまでわからないっしょ？
E0000～EFFFFまではゲームの状態フラグとか・・・ま、色々

言語の仕様よりこういう知恵のが大事だと思うけどね
C＋＋の仕様にスクリプトの仕様を近づけることにあまり意味を感じない
C言語の構造体レベルですら意味を感じない
１００個ぐらい値をチェックしたい・・・とかなったらスクリプトで書かないでC言語で処理書いて
それをスクリプトから呼べと言いたい

とするとほとんどのスクリプトはちょっとした分岐や関数を
ただ並べただけのようなスクリプトにしかならないと思うけどね

俺はデバッグすら苦労しないようにした（つもり）多分ね、すくりぷたがほしい言語と俺等の認識する高級言語（多分使いやすい？）ってのに差がある

906 ：名前は開発中のものです。：2008/07/29(火) 01:37:48 ID:JlhAZyyY

ここ半年ぐらいタスクシステムを調べてるが未だにわからん。
が、デザパタの具体的なパターンは、ぐぐればいくらでも出てくるし
デザパタそのものはどういう概念・思想・目的なのか、また具体的なパターンはどういうものなのかってことは別に難しいことじゃないだろう。

後今更だが、デザパタの話はこっちの方が適所な気がする。

ゲームにおけるデータ構造・クラス設計・パターン2
http://pc11.2ch.net/test/read.cgi/gamedev/1211544659/l50

つーわけでうちはタスクシステムの話に戻ることを切に願うぜ。

907 ：名前は開発中のものです。：2008/07/29(火) 01:38:37 ID:XocvgfO0

>>905
> タブ・スペース・カンマ・リターン・キャリッジリターンのデリミタでできるのがまず条件

「～のデリミタでできる」の意味がわかりません。それらの文字で、何ができてればいいの？

908 ：名前は開発中のものです。：2008/07/29(火) 03:15:25 ID:/Y0trEh0

>>905
まさかと思うが、スクリプト中に
G0000 = 100
とか書くのか？

909 ：名前は開発中のものです。：2008/07/29(火) 06:09:06 ID:k1c5jdwC

>>908
そう、でもコメントはしっかり書くけどね
その代わりにエクセルで一覧になってるから
意味はすぐにわかる、んでもってデバッグモード実行時にはリアルタイムで値も見れる

変数　値　備考
G0000 1 テストフラグ０
G0001 0 テストフラグ１
G0002 1 テストフラグ２
　・
　・
　・

ってな一覧が見れる

はじめはプログラムの仕組み的に別に連番じゃなくても
なんでも動いたんだけど
企画の人間がこっちのがいいっていうからこっちになって
じゃ、いっそこれで役割もわけちゃうか？ってなってG～とかT～とか名前がついた

910 ：名前は開発中のものです。：2008/07/29(火) 09:14:45 ID:F10Z/Jo2

>>905
> そんな複雑なもんできるならC言語で追加しやすいようにしたほうがよかったんじゃない？
スクリプトから C++ の関数を簡単に呼べるようにするのは、必須だね。

俺の場合はスクリプトコンパイラで C++ を一部解析できるようにして、
スクリプトから呼ぶ関数についてはプロトタイプ宣言を取り込めるように
しといた。

前に、引数の数とか型とか合わない系のバグで、プロジェクト終盤の
忙しいときにプログラマがスクリプトでバッグに付き合わされた苦い
経験があるんで。

ちなみに、エフェクトのスクリプトだと

main()
{
　　// プレイヤーの右手座標を取得
　　vector pos = CharGetPos(CHAR_PLAYER, BONE_RIGHT_HAND);
　　// パーティクルを 16 個発生させる
　　instance effect = EffCreateSparkParticle(pos, 16);
　　// パーティクルの寿命を設定（1秒間でアルファ値を 0 に）
　　EffSetAlphaTo(effect, 0.0, 1.0);
　　// スクリプトの実行を1秒間待ってから終了
　　sysWait(1.0);
}

こんな感じになる。CharGetPos, EffCreateSparkParticle, EffSetAlphaTo あたりが
C++ の関数を呼び出すところで、sysWait はスクリプトの組み込み関数。
CHAR_PLAYER, BONE_RIGHT_HAND あたりは C++, スクリプト共通のヘッダ
ファイルで #define してある定数。

911 ：名前は開発中のものです。：2008/07/29(火) 09:34:46 ID:F10Z/Jo2

>>909
イベントとかフラグ管理系のスクリプトは、そんな感じの設計も
アリかもしれんね。

俺はどちらかというと、エフェクトとか、キャラクタの行動に貼り付けて
「1秒後にヒット判定」なんつー用途がメインだったので >910 みたいな
仕様にしといた。

この手のスクリプトは、けっこうループとかマルチスレッドとか使いたく
なるんだよな。マルチスレッドは難しいって印象があるけど、排他制御
絡まなければ、スクリプタでも難なく理解できる人が多かったよ。

912 ：名前は開発中のものです。：2008/07/30(水) 00:08:14 ID:HczhbirA

>>909
いろいろ現場のノウハウ詰まってそうだね。スクリプトのサンプル見たいな。

あと、スクリプトから C, C++ の関数呼ばせる部分てどうしてる？　最近 luabind 見て、
変態チックな文法だけど使いやすそうだなぁと思ってる。

913 ：名前は開発中のものです。：2008/07/30(水) 02:48:57 ID:DTsRp+ns

>>912
俺は>>909 じゃないが、>>909はスタックベースのＶＭじゃないっぽいし
関数の引数や戻り値の処理は実装してないんじゃね？

それかGとTがグローバルとテンポラリだと仮定すれば、
テンポラリをスタックっぽく使って引数や戻り値、呼び出し元ＰＣを積んでいくとかしてるのかな

914 ：名前は開発中のものです。：2008/07/30(水) 12:18:00 ID:wmPIhqZi

ざらっと最近の書き込みみたけど、

デザパタ(GoF)ってさ、
互いに関係しあうAとBっていうクラスがあったときに、
クラスAの実装を１文字たりとも変更することなくクラスBをクラスCと取り替えて、
動作を変更・拡張することができる。
っていう系統のことに気をつけてるパターンが多いよね。

そうしておかないとクラスAは「そのまんま」再利用可能な「部品」にならないからね。

そういうことにあんま気を使わないプロジェクトばっか経験してるなら、
ピンとこないかもしれんね。

ゲームとか、１回限りのコードばっかなら割とどうでも書けるし。

915 ：名前は開発中のものです。：2008/07/30(水) 15:41:55 ID:NzOUZbdl

一回限りの使い捨てで作らないと、無駄にリソースを使う部分が増えるケースが多いし

916 ：名前は開発中のものです。：2008/07/30(水) 16:33:07 ID:DTsRp+ns

無駄なＣＰＵパワーより無駄なマンパワーですね
わかります

917 ：名前は開発中のものです。：2008/07/30(水) 20:29:26 ID:b4B33Ihv

>>912
F0000～FFFFFが関数になってる
プログラム側の処理は
switch(index){
case 0:
　　　F0000の処理する関数(引数の文字列の束);
　　　break;
case 1:
　　　F0001の処理する関数(引数の文字列の束);
　　　break;
　　・
　　・
　　・

こんなん
関数から何か出力があるときは実行後にO0000～OFFFFのどっかに入る
スクリプトの仕様は
F0000 引数１・・・；
「；」があるまで引数
前はI0000～IFFFFまでが引数だったが
I0000 = 0
I0001 = 5
I0002 = 6
I0003 = 7
F0000
とか非常に縦に長く、偉く評判悪かった

918 ：名前は開発中のものです。：2008/07/30(水) 20:57:46 ID:dYj7Afpj

関数ポインタの方がいいんじゃねーか？

919 ：名前は開発中のものです。：2008/07/30(水) 21:13:53 ID:HczhbirA

>>917
なるほど。たとえば >910 のスクリプトを書き直すと、こんな感じ？

.def CHAR_PLAYER = 1
.def BONE_RIGHT_HAND = 2

; プレイヤーの右手座標を取得
F0000 CHAR_PLAYER BONE_RIGHT_HAND
L0000 = O0000 ; x
L0001 = O0001 ; y
L0002 = O0002 ; z

; 放射状に移動するパーティクルを 16 個発生させる
F0001 L0000 L0001 L0002 16
L0003 = O0000

; パーティクルの寿命を設定（1秒間でアルファ値を 0 に）
F0002 L0003 0.0 1.0

; スクリプトの実行を1秒間待ってから終了
F1000 1.0

920 ：名前は開発中のものです。：2008/07/30(水) 22:17:46 ID:b4B33Ihv

>>919
まあ、そんな感じじゃね？
さらにいうと

.def CHAR_PLAYER = 1
.def BONE_RIGHT_HAND = 2

こんな生易しいキーワードはねぇよｗ
キャラなんてIDで十分だろ
複雑なことやりたきゃC言語で関数作れってスタンスだし

> プレイヤーの右手座標を取得
こんなのスクリプトでやらせるかな～ｗ
すでにエキサイトしてて何やってんのかわからん開発現場になってね？
昔、オンラインのゲーム作ってるときに
３ヵ月後の第３金曜日の日付をこの仕様のスクリプトで計算した猛者がいたがあいつはアフォだと思う
みたいなノリにすでに入ってる希ガス
だから、いっしょにC言語も弄れるようにしておいたほうがいいわけでな

スクリプトは所詮時系列で何かを表現したいときのイベントリストでしかない
けどな俺んとこの場合

921 ：名前は開発中のものです。：2008/07/30(水) 22:42:38 ID:HczhbirA

>>920
> > プレイヤーの右手座標を取得
> こんなのスクリプトでやらせるかな～ｗ
モーション屋さんの発言力があるところなのでｗ　まぁ、実際
それが評価されて売れてるから良いんだけどさ。

エフェクトも、わりとキャラの骨に貼り付けとか多いんだよね。
汎用関数で骨位置取れるようにして、そのパラメタ使いまわす
ような設計にしておかないと、ま、いろいろ面倒なので。

922 ：名前は開発中のものです。：2008/07/31(木) 11:45:11 ID:xjprKWud

>>920
> > プレイヤーの右手座標を取得
> こんなのスクリプトでやらせるかな～ｗ
代わりに、どんな感じでやってるの？

俺の場合だと、アクション系のゲームで良くあるパターンで、モーション再生し始めて

　0.5秒後　剣の根元 p から先 q に向かって光の玉（2Dスプライト）が、x の速度で走る
　1.0秒後～1.5秒後　剣の位置を曲線補完して軌跡を表示。徐々にアルファ値が小さくなって y 秒で消える
　1.2秒後～1.4秒後　当たり判定発生　プレイヤーを中心として半径 z の範囲

なんつのが良くあるけど

　p, q は位置はだいたい決まってるけど、実際に表示させてから「もう少し先」「もう少し根元」と
　調整入る可能性大で、x, y, z も実際に動かしてみて決める

と、詳細は見てから調整ってなるとスクリプトの出番。

たとえば、このケースだと剣の根元と先にモーションのボーン埋め込んでおいて、
実行時に、その位置をスクリプトで取れる＆オフセットを計算できるようにしておく。
（さすがに行列演算とかは意識させないようにする）

モーション屋さんとエフェクト屋さんは別の人なので、エフェクト表示のためだけに
骨位置調整してモーション作り直してもらうのは手間なのと、このぐらいの計算は
サポートしてないと、いちいちプログラマが介入しないと作れないっつー機会が
多くなりすぎ…っつーことでこんな仕様で今までやってきたんだが、他のやり方に
ついて良い知恵があれば聞いてみたい。

923 ：名前は開発中のものです。：2008/07/31(木) 15:48:25 ID:M2LQ0a0O

そこでタスクシステムの出番ですよ

924 ：名前は開発中のものです。：2008/07/31(木) 19:19:31 ID:hVl8MelT

>>922
そういう描画まわりのことならモデリングソフトのプラグインのが絶対楽
数値なんて設定しないでマウスでタイムライン上に配置したほうが楽だろ

925 ：名前は開発中のものです。：2008/07/31(木) 19:46:40 ID:OuDD7nqS

>>922
使ってるツールとかワークフローとかゲームによって事情が違ってくるからアレなんだけど

＞エフェクト表示のためだけに骨位置調整してモーション作り直してもらうのは手間なのと

うちは3Dツール上でモデル側のスケルトンにくっついてる武器やエフェクトの基準ボーンの
位置や姿勢を調整してもモーション作り直しになっちゃうことはないかな
モーションキーが入ってない末端のボーンだからいじくっても動きには何も影響しない

それと、エフェクト付きアニメーションを3Dツール上でプレビューできて
ボタンひとつでゲーム実行中の実機にもロード＆反映できる環境だと
3Dツール上でほとんど調整してしまったほうが楽になる

926 ：名前は開発中のものです。：2008/07/31(木) 19:47:48 ID:OuDD7nqS

モデル側の→モデルの

927 ：名前は開発中のものです。：2008/08/01(金) 14:34:41 ID:+NwxS8oZ

>>925
> 位置や姿勢を調整してもモーション作り直しになっちゃうことはないかな
モーション作り直しというか、モデリングツール立ち上げで出力し直し。

Maya とかライセンス料高いので、必要最小限しか確保してないので、
持ってる人のところに作業依頼が行くことになる。

やっぱりツールに持ってく方向が良いのかなぁ。

モデリングツールで作りこめる環境があればそれで
環境が無ければ、
　よく使うヤツに関しては実機上で動くエディタ作って調整可能に
　個別対応だが数が多いヤツはスクリプトで書けるように
　特殊で数も少ないヤツは C++ で書いちゃえ

っツー感じで。

928 ：名前は開発中のものです。：2008/08/01(金) 18:57:52 ID:V2PwGrEE

作り直しになっちゃうのは最終出力だけにデータを混ぜようとするからで
ちゃんと変更されても調節が効くような仕組みにしておけばいいと思う

929 ：名前は開発中のものです。：2008/08/13(水) 16:10:15 ID:NN6cYi75

話題なさそうなので投下。

ttp://marupeke296.com/GDEV_No3_TaskSystem.html
このページのタスクの使い方が参考になると思った。
特にタスク内部にデータ置いちゃうと他タスクとの共有がしづらいから
タスクの外に出してしまうという概念が。
他のページにサンプルソースコードもあったし、
タスクの拡張性の弱さに詰まってる人は改善のとっかかりになるのでは？

930 ：名前は開発中のものです。：2008/10/06(月) 01:45:59 ID:UGCzB4IP

…。

931 ：名前は開発中のものです。：2008/11/01(土) 10:21:35 ID:IuSgJyHu

タスクシステムにクラスを使うのってどうなの？
タスクのデータ長が不揃いになっちゃうから、メモリにフラグメントが発生するよね？
せっかくタスクシステムを使っているのに、意味がなくなっちゃうんじゃないか？

932 ：名前は開発中のものです。：2008/11/01(土) 10:59:16 ID:PaHjD1FU

タスクシステムの利点って、データ長の切りがよかったり、フラグメンテーションが
発生しないことだったのか？

933 ：名前は開発中のものです。：2008/11/01(土) 11:02:04 ID:i+zLcx90

メモリのフラグメントが心配なら、使い終わったオブジェクトをプールして再利用すればいいじゃない。
タスクシステムとは関係無いと思う。

934 ：名前は開発中のものです。：2008/11/01(土) 11:35:52 ID:IuSgJyHu

同じ種類のクラスでしか再利用は出来ない
メモリだけ別途確保したとしてもデータ長が違うから再利用できない

タスクシステムっていうのは
　　・メモリ管理
　　・タスク管理
の2種類から構成されている
アマチュアPCゲームはゲームの規模に比べてメモリ量が無制限と言えるほど多く
速度もシビアには求められない為、メモリ管理の必要はない
また、弾幕STG等キャラクタの数・種類が多いゲームが増えているのでタスク管理については重要性が増している
そのせいか、タスクシステム＝タスク管理と思われているが、
そんな利用法だとあの複雑怪奇なシステムを使うメリットが半減してる

935 ：名前は開発中のものです。：2008/11/01(土) 12:56:14 ID:YmfIaKZ8

いや出来るだろ
タスク構造体にデータを包含させるにしても最大長で確保することになるし、
それならクラスの最大長で確保した配列をプールにしても同じことだろう

936 ：名前は開発中のものです。：2008/11/01(土) 12:58:26 ID:i+zLcx90

>>934
その理屈だと、構造体ですらアウトだろ？
一体どうやってメモリ管理するの？

937 ：名前は開発中のものです。：2008/11/01(土) 22:06:18 ID:7IlujbnF

弾幕シューティング作ってすごいと思われたのはX68000までよねーｷｬﾊﾊﾊﾊ

938 ：名前は開発中のものです。：2008/11/02(日) 02:26:58 ID:lL29+zD2

＞ID:IuSgJyHu

なにこのキチガイ。タスク厨ついに狂った？元々狂ってたけど輪をかけて狂った？

＞タスクシステムにクラスを使うのってどうなの？
＞タスクのデータ長が不揃いになっちゃうから、メモリにフラグメントが発生するよね？
＞せっかくタスクシステムを使っているのに、意味がなくなっちゃうんじゃないか？

クラスを使うとタスクのデータ長が不揃いになってメモリにフラグメントが発生するの？
構造体を使うとインスタンスのサイズが不揃いになってメモリに断片が発生するの？

タスクシステムって何なの？バカなの？救いようの無いバカなの？
固定長メモリプールすら想定の範囲外なの？どこの石器時代の話なの？
むしろ固定長メモリプールは石器時代の石器といえるよ？
タスクシステムは石器時代のお猿が振り回す木の棒なの？戦えるの？

939 ：名前は開発中のものです。：2008/11/02(日) 02:34:56 ID:lL29+zD2

>>934
＞同じ種類のクラスでしか再利用は出来ない
＞メモリだけ別途確保したとしてもデータ長が違うから再利用できない

え、じゃあタスクシステムって何なの？バカなの？
固定長メモリプールですら出来ることが出来ないシステムなの？
固定長メモリプールなんてノイマン型コンピュータが誕生すると同時に
生まれたバクテリア並のコードだけどタスクシステムはそれすらできないの？

940 ：名前は開発中のものです。：2008/11/02(日) 03:14:48 ID:lL29+zD2

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

タスクシステムって何なの？さっきまでの話から想像するに
バクテリア並みの原始的なメモリ管理すらできないゴミみたいだけど
それでもメモリ管理をしてることになってるの？本当に管理してるの？
メモリ管理してるしてる詐欺じゃないの？

＞アマチュアPCゲームはゲームの規模に比べてメモリ量が無制限と言えるほど多く
＞速度もシビアには求められない為、メモリ管理の必要はない

というか固定長メモリプールに出来ることすら出来ないメモリ管理なんて
あってないようなものだから必要ないのは端から明らかだよね？

＞また、弾幕STG等キャラクタの数・種類が多いゲームが増えているのでタスク管理については重要性が増している
＞そのせいか、タスクシステム＝タスク管理と思われているが、

メモリ管理なんてしてないも同然なんだから、残る「タスク管理」とやらしか価値なさそうだよね？
どうやらタスクシステムとやらの価値は「タスク管理」にかかってるみたいだね？「タスク管理」って何？

＞そんな利用法だとあの複雑怪奇なシステムを使うメリットが半減してる

タスクシステムとやらは「あってないも同然のメモリ管理」を削っただけでメリットが50%も激減するの？
じゃあ残る「タスク管理」とやらもあってないも同然の糞コードじゃない？おまけに奇奇怪怪なの？
生きてる価値ないんじゃないの？死ぬの？

941 ：名前は開発中のものです。：2008/11/02(日) 03:17:30 ID:lL29+zD2

ここまで分かったこと。タスクシステムとは

　(1)あってないも同然のメモリ管理　　…　タスクシステムの価値の50%を占める
　(2)奇奇怪怪のタスク管理　　　　　　…　タスクシステムの価値の50%を占める

で出来ている。(1)はあってないも同然だから価値0。それとほぼ等価の(2)も価値0。
よってタスクシステムの価値は0+0=0。

タスクシステムって何なの？死ぬの？

942 ：名前は開発中のものです。：2008/11/02(日) 03:29:17 ID:lL29+zD2

あ、奇奇怪怪じゃなくて複雑怪奇なんだね。ごめんね。
価値がゼロに等しいのに複雑怪奇ってどんな気分？生きるの？

943 ：名前は開発中のものです。：2008/11/02(日) 08:02:14 ID:asCDTQDW

マッチポンプ乙

944 ：名前は開発中のものです。：2008/11/02(日) 11:51:59 ID:uhdLgPq4

あほかよ。どちらも。

945 ：名前は開発中のものです。：2008/11/02(日) 12:00:25 ID:TNeoharl

>>931
固定長のメモリを確保するoperator newを定義すればいいだけ。
っていうか、C++で効率の話を書いてる本には、必ず載ってるネタだと思うが。

946 ：名前は開発中のものです。：2008/11/02(日) 14:19:46 ID:VtL2ElaE

Javaでも問題ない？

947 ：名前は開発中のものです。：2008/11/03(月) 01:32:32 ID:S8mU9FlP

メモリプールは再発明せずにboostのを使いたまえ。
つか弾幕シューごときのオブジェクト量でいまどきメモリプールとか必要ないけど。

948 ：名前は開発中のものです。：2008/11/06(木) 00:16:34 ID:u8lLg0Ce

で、結局なんで938は怒ってるのかよくわからないんだが。

それはそれとして、知人からタスクシステムって言葉を教えられて
いろいろ調べてみて、ためしにひとつゲームを作ってみようかと
思うんだけど、このスレで相談してもいいのかな？

C++とかもよく理解できてないんで、勉強をかねて SDL + OpenGL +
タスクシステム + C++ で作ってみようかなと思ってるんだが。

949 ：名前は開発中のものです。：2008/11/06(木) 00:50:27 ID:EfOKB7UU

構わんが
その前にその知人とは距離を置いたほうがいい

950 ：名前は開発中のものです。：2008/11/06(木) 01:16:44 ID:flH79zx7

>>948
タスクシステムはまともに定義されてもいないし
固定した共通認識があるわけでもない
極めていい加減な言葉。
だからタスクシステムと呼ばれているもののテクニックを
参考にする事はいいとおもうけど
タスクシステムでと言われると首を傾げる。

951 ：名前は開発中のものです。：2008/11/06(木) 01:18:09 ID:u8lLg0Ce

>>949
その知人はもう遠くにいっちゃったんで、距離は置けちゃってるんだが
タスクシステムっていうだけでそんなに言われるものなの？

952 ：名前は開発中のものです。：2008/11/06(木) 01:30:36 ID:u8lLg0Ce

>>950
>タスクシステムはまともに定義されてもいないし
こんな隔離スレっぽいところですばやいレスがあるのに驚いたw
そういや定義云々でけっこうもめてた感もあるな。

印象論ですまんけど、俺のいまんところの認識では

・アプリケーション内部で擬似マルチタスクを実現する手法のひとつ
・プログラムのループを一部開放して、複数のサブルーチン（死語？）をつけはずしできるようにしたもの
・if～else/switchのネストよりはましかもしれない。

ってところかなあ。まあ、俺が駄目PGなんで、自分が考えたものよりマシかもしれん、
ってだけなんだが。

953 ：名前は開発中のものです。：2008/11/06(木) 11:58:35 ID:q/CP8wrK

>>952 で合ってるだろ。

954 ：名前は開発中のものです。：2008/11/06(木) 12:44:17 ID:Tr7oUC7Q

＞そういや定義云々でけっこうもめてた感もあるな。

定義すら出来ないタスク擁護派の虚を付く形で一方的に蹂躙されてたね
タスクシステムという単語を耳にしたら「俺俺システム」とか「俺の発明した至高のオナニーシステム」
とでも置換したほうが理解しやすい。定義できるはずもない。ざまぁ

955 ：名前は開発中のものです。：2008/11/06(木) 12:56:48 ID:Tr7oUC7Q

＞擬似マルチタスク

マルチタスクの要件を満たしてる例がひとつもなかったような
擬似ですらない。単なる似非だろう。天と地の開きがある

＞・プログラムのループを一部開放して、複数のサブルーチン（死語？）をつけはずしできるようにしたもの

印象論というか日本語でおｋ

＞・if～else/switchのネストよりはましかもしれない。

過去に出てきた例を見る限り、どのオナニーシステムも
可読性の面ではどれも凶悪といっていい水準だったな

956 ：名前は開発中のものです。：2008/11/06(木) 14:03:57 ID:yOFGd/wG

haskellやadgaでタスクシステムが実装できれば定義したも同然

957 ：名前は開発中のものです。：2008/11/06(木) 14:35:49 ID:kq5uaoNw

>>952
隔離スレっぽいんじゃなくてID:Tr7oUC7Qみたいな子を隔離するスレ

>>954
権力的に偉い人が好んで使う「国益」という言葉も
具体的な内容については大きな揺らぎがある。
偉い人に喧嘩売る気がないのなら
定義できないことをあまり悪く言わない方がいいと思うんだ。

958 ：名前は開発中のものです。：2008/11/06(木) 15:16:03 ID:q/CP8wrK

>>955
まずおまえが「マルチタスクの要件」とやらを定義してみてくれ

959 ：名前は開発中のものです。：2008/11/06(木) 15:41:18 ID:Tr7oUC7Q

最低でも
　・スケジューリング
　・コンテキストスイッチ
　・タスク間通信

擬似を名乗るならせめてこれぐらいは欲しいね
で、擬似タスクとかタスクシステムを自称してるコードで
コンテキストスイッチができてるものはほとんど見ない

FSMリストの走査・更新してタスクシステムばんじゃい！ばっかだろ

960 ：名前は開発中のものです。：2008/11/06(木) 15:51:13 ID:Tr7oUC7Q

>>957
＞国益～

他人を諭すのに安易に分けの分からん例え話を始めるようなら
この老害本格的に焼きが回ってんなー思われるから言わない方がいいと思うんだ

961 ：名前は開発中のものです。：2008/11/06(木) 18:38:39 ID:q/CP8wrK

じゃぁコンテキストの保存ができないマルチタスク、とでも呼ぼうか。
あんたの「擬似」の定義に従って、だけど。

962 ：名前は開発中のものです。：2008/11/06(木) 19:12:24 ID:Tr7oUC7Q

擬似の意味が分からないなら辞書で調べてね
本来の代物がウリにしてる「基本的なサービス」すら提供できないにも関わらず
擬似と名乗るのは半島文化か何かかね？素直に似非と認めたほうがしっくりくるぜ？

ついでに似非も辞書で調べましょう。納得ですね？

＞コンテキストの保存ができないマルチタスク

コンテキストスイッチできないマルチタスクシステムは果たしてマルチタスクシステムなのか？
まぁどっかの例え好きのオッサンなら「チンポ付いてない男。でも心は男ですから！男です！」
とでも反論するんだろうね

963 ：名前は開発中のものです。：2008/11/06(木) 20:02:31 ID:q/CP8wrK

ああ、特定2ちゃんねらーでもあったか。人間のクズだな。相手して損した

964 ：名前は開発中のものです。：2008/11/06(木) 20:08:41 ID:Tr7oUC7Q

はい、敗北遁走宣言来ました

965 ：名前は開発中のものです。：2008/11/06(木) 20:10:08 ID:q3x+LI10

ﾏｼﾞｷﾁ

966 ：名前は開発中のものです。：2008/11/06(木) 20:38:55 ID:6uLCJgnb

タスク信者がんばれがんばれ何でそこで諦めちゃうんだよやれば出来る出来るがんばれがんばれ
世間はさぁ冷てぇよな。みんな君のタスクシステムへの思いを感じてくれねぇんだよ
どんなに頑張ってもさぁ、何で分かってくれねぇんだよって思うときあるのよね

でも大丈夫、分かってくれる人はいる。そう、松浦尊師に付いて来い！

ただいま尼オクで聖典「シューティングゲームアルゴリズムマニアックス」好評販売中！
買わなければ仏罰が下って地獄に落ちるよ。さぁ浄財を奉納して極楽浄土へいらっしゃい

967 ：名前は開発中のものです。：2008/11/06(木) 21:50:36 ID:w1bQOqdR

次スレまだ～？ﾁﾝﾁﾝ

968 ：名前は開発中のものです。：2008/11/06(木) 22:04:02 ID:lvyck+uw

>>961
> じゃぁコンテキストの保存ができないマルチタスク、とでも呼ぼうか。
そんな汁のない味噌汁みたいな名前つけられても…

969 ：名前は開発中のものです。：2008/11/06(木) 23:56:19 ID:slS/2L3k

よーしお兄さんが書き逃げしてあげるぞー。

【マルチタスク】
プリエンプティブなマルチタスクOSではスケジューラがプロセスをタイムスライス（短い時間）ごと分割して実行する。
処理がタイムスライス内で終わらない場合、タイマ割り込みによってコンテキストスイッチが発生する。
他にも割り込みはあるけどとりあえずここまで。
で、コンテキストスイッチとは現在のCPUのレジスタ等の状態を保存し、次に実行する処理のためにレジスタ等の状態を復元する処理のこと。

【タスクシステム】
全てがタスクリストに含まれているとするなら。
１フレーム内での行う全ての処理＝タスクリスト
１フレーム内での行う全ての処理＝タスクリスト＋描画処理
１フレーム内での行う全ての処理＝タスクリスト＋当り判定等＋描画処理
１フレーム内での行う全ての処理＝タスクA＋タスクB＋…＋タスクZ＋当り判定＋描画処理
１フレームの時間は大抵は1/60秒とか1/30秒とか、１フレーム内で終わらなかったときは描画がスキップされる。
だからコンテキストスイッチは不要では。

970 ：948：2008/11/07(金) 00:09:50 ID:t//oE7rA

あー、また怒ってるよw なんか恨みでもあるの？>> 959
どこかで時分割も擬似マルチタスクだっていうのを見たこともあるんで、そういわれりゃマルチタスク風くらいでいいかな？
俺的にはエターナルブリザードシステムが気に入ったけど。

マルチタスクの定義はまあ、確かにそうだけど、それ、アプリケーションが
自前で実装するようなものかな？あー、「システム」ってのが気に入らないのかな。

>・プログラムのループを一部開放して
ここでもでてきたけど、
while ( keep_going ) {
update_chara();
update_stage();
render_all()
}
みたいなループだと処理順も固定になるところを、個別の処理を配列／リスト化して
動的に切り替えられるようにしてあるわけでしょ？
少しは自由度は高いと思うけど、メリット・デメリットは微妙かなあとは思う。

971 ：名前は開発中のものです。：2008/11/07(金) 00:15:48 ID:6KHA8D9T

>>959は最近どっかでマルチタスクを勉強してきて教えて回りたいんだろ。
ここはそういう話するところじゃないからね。
また別のところ行ってやってね。

972 ：948：2008/11/07(金) 00:43:39 ID:t//oE7rA

>だからコンテキストスイッチは不要では。
いや、マルチタスク処理、と考えれば、タスクが勝手にスイッチされてくれるほうが
各タスクで処理を戻すとか考えずに記述できるぶん見通しはよくなると思う。

でもそう思ってマルチスレッドで組むとスレッドの同期とか排他とか必要になって
あんまりシンプルにならない罠。

973 ：名前は開発中のものです。：2008/11/07(金) 01:08:41 ID:PkFbpCU8

>>970
そういえば文章心理学っていう単位とったけど難しくてよく分からなかったよ
あとついでにエターナル「フォース」ブリザードシステムだったような気がするよ

＞マルチタスクの定義はまあ、確かにそうだけど、それ、アプリケーションが
＞自前で実装するようなものかな？

そういうこと。IA32でいうところの特権命令群に触れる立場に無い、たとえばWindowsの
ユーザーモードのプログラムコードで、わざわざマルチタスクシステム用意する価値ないよ

＞>・プログラムのループを一部開放して
＞ここでもでてきたけど、
＞while ( keep_going ) {
＞update_chara();
＞update_stage();
＞render_all()
＞}
＞みたいなループだと処理順も固定になるところを、個別の処理を配列／リスト化して
＞動的に切り替えられるようにしてあるわけでしょ？
＞少しは自由度は高いと思うけど、メリット・デメリットは微妙かなあとは思う。

↑の例で、ゲームの仕様で初めから処理優先順位が静的と確定しているならば
動的にするメリットはないだろうね。どう転んでも不要と分かりきってる自由度を
与える行為は有毒だしデメリットでしかないよね。
ところで「タスクシステム」というのはそういう不要な自由度を与える事を回避できない
代物なの？このスレを読む限り「タスクシステム」を熱愛して提唱している人の話は
単なるリスト巡回UPDATEでしかないという印象を受けるんだけど

>>971
つ>>958

974 ：名前は開発中のものです。：2008/11/07(金) 01:15:41 ID:PkFbpCU8

訂正

＞そういうこと。IA32でいうところの特権命令群に触れる立場に無い、たとえばWindowsの
＞ユーザーモードのプログラムコードで、わざわざマルチタスクシステム用意する価値ないよ

そういうこと。IA32でいうところの特権命令群に触れる立場に無い、たとえばWindowsの
ユーザーモードのプログラムコードで、わざわざマルチタスクシステム用意する価値は
ハードウェアリソースが貧弱だった頃は無かったよ

でも、ハードウェアの進歩でソフトウェア処理によるコンティストスイッチが実用的なケースが
増え続けているよ

975 ：948：2008/11/07(金) 01:44:47 ID:t//oE7rA

>わざわざマルチタスクシステム用意する価値ないよ

これはケースバイケースじゃないか？まあ、俺が駄目駄目なんで偉そうなことは
いえないけど、ゲーム上のオブジェクトって独立して動きつつ、互いの情報を
参照したりするでしょ？
システムの提供するサービスで全部実現するのは理想かもしれないけど、
マルチスレッドは追っかけるのも結構大変だし、マルチタスク風、実はシーケンシャル
な処理ってその点はわかりやすかったりするよ？

>ゲームの仕様で初めから処理優先順位が静的と確定しているならば

本職のゲーム屋じゃないんでなんともいいにくいけど、
その仮定は理想かもしれないけど、現実には程遠いような気がw

基本ロジックを作っておけば、いろいろなタイプのゲームに対応できる
（というのも売りらしい）んなら、まあ、便利なんじゃないの？

＞不要な自由度を与える事
開発者が用意して開発者が利用する分にはあんまり問題じゃないような気がするけど。

976 ：948：2008/11/07(金) 01:51:27 ID:t//oE7rA

>>974
？タスクシステムに肯定的なのか否定的なのかちょっとわかりにくい。

977 ：名前は開発中のものです。：2008/11/07(金) 02:01:50 ID:0eofhGUn

タスク＝リスト巡回UPDATEでＦＡだろ
それ以上でもそれ以下でもない

俺はタスク擁護派だが、アンチは誰と戦ってんだよｗ

978 ：969：2008/11/07(金) 02:03:49 ID:0ZMEybut

反撃レス内みたいなんで

wikiの内容からするとタスクシステム＝擬似マルチタスクということになる。
http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%AB%E3%83%81%E3%82%BF%E3%82%B9%E3%82%AF
ノンプリエンプティブ・マルチタスク
各タスク自身が、短い時間間隔でOSに処理を返す方式によって実現されているものを、ノンプリエンプティブなマルチタスクあるいは疑似マルチタスクという。

>>972
敵１体ごとスレッド作るとか無理じゃね。
あんまりシンプルにならないとかじゃすまないと思うが。

>>973
単なるリスト巡回UPDATEでしかないよ。
不要な自由度はデメリットかもしれんがC/C++で実装してたら別にどうとでもなっちゃうだろ。
C/C++の不要な自由度のおかげで実装に苦労できる。色々な実装があってみんないい。
とはいわんけど。

979 ：948：2008/11/07(金) 02:10:14 ID:t//oE7rA

まあ、ただ 974 がいいたいのが、世間wでは GPGPUを使った物理演算だの、
マルチコアに最適化された並列処理だとか言ってる時代に、ちまちまと
古いコーディングテクニックとかやってると駄目だ、っていう話ならわからんでもない。
PS3あたりの大規模ゲームとかはそうなのかもなあ。

980 ：名前は開発中のものです。：2008/11/07(金) 02:21:09 ID:0eofhGUn

>>948
とりあえずここ人いるのは分かったし
質問があればみんなケンカしつつも答えるんじゃないかね

古いやり方も理解のために経験しとくのは俺はいいと思う
知らん方がいいって人もいるけどさ

981 ：948：2008/11/07(金) 02:27:16 ID:t//oE7rA

>>980
てなわけで、いまんとこ
ttp://www.tnksoft.com/reading/classgame/index.htm
のサンプルをSDL+OpenGLで置き換えたサンプルを作ってるところなんだよ。
まとまったらどっかに上げて批評してもらう、とかどうかと思ったんだが、
それじゃただのおんぶにだっこかな。

982 ：名前は開発中のものです。：2008/11/07(金) 02:59:03 ID:0eofhGUn

いんじゃないすかね
わざわざDX9からSDLに移植すんのも
全体を一通り触ることになるだろうから勉強になるとおも
ソースもざっと見、小さくて見通しがいい良いサンプルかと

つかやる気あるねー>>948は。ひとりでもあっという間に上達しそう

983 ：名前は開発中のものです。：2008/11/07(金) 09:12:48 ID:QKzI3Kjp

>>975
メインループは C++ ネイティブコードで書いたシングルスレッド、ただし
その上で非プリエンプティブのスクリプト仮想マシンを複数動かす形に
するけどな。

非プリエンプティブなので、同期の心配とかはない。実行順序だけ気に
しとけば良い。

技術的には、C++ 側もコンテクストスイッチするようにできるけど、そこまで
やるメリットを感じないなぁ。むしろ、デバッグ辛くなりそうだし。

984 ：948：2008/11/08(土) 00:43:22 ID:YKZ7JNVs

とりあえず、タスクシステムで作ったサンプルをでっち上げてみた。
実行ファイルとデータだけだけど、やりたいことを見てもらうのにいいかなと。
抽象的な議論が苦手なんだよね。ソースはもう少し整理して公開しようかと。

ttp://uproda11.2ch-library.com/src/11132771.zip.shtml
よかったら見てみてください。ウィルスチェックはしてるけど、一応自己責任で
お願いします。

985 ：948：2008/11/08(土) 00:44:27 ID:YKZ7JNVs

げ、DLキーは task です。

986 ：名前は開発中のものです。：2008/11/08(土) 00:50:44 ID:YKZ7JNVs

>スクリプト仮想マシンを複数動かす形
そうすれば不用意な自由度を与えなくてすむわけか。973がいいたいのもそのあたり？
プログラマとレベルデザイナとか役割分担するのには必要かもね。

987 ：名前は開発中のものです。：2008/11/08(土) 01:42:18 ID:rZ00PGZ7

スレ的にはソースが無いと意味が無いのでは。
まぁソースをうｐしたら、それを肴にして荒れまくるのは目に見えてる。
だから俺は正座して待つぜ。

988 ：名前は開発中のものです。：2008/11/08(土) 02:01:27 ID:95q+SJ2O

>>978
協調的マルチタスクシステムって大抵はコンテキストスイッチくらい面倒見てくれるけどな
世界で一番売れた協調的マルチタスクOSであるWindows3.1もそう

989 ：978：2008/11/08(土) 11:30:43 ID:jrTPhNiJ

>>988
コンテキストスイッチはタスクシステムでは不要というかもう実装されてるでしょ。
タスク自体がデータと振る舞いを持ってるわけだから、
タスクAの処理をしてるときはタスクAのデータ領域を参照するし、
タスクBに処理をしてるときはタスクBのデータ領域を参照するでしょ。
割り込みについてのことなら重い処理作ったら描画がスキップされるだけだから必要ないと思う。
ファイルIO等の重い処理は別スレッドに分けるとかで大抵解決する。

990 ：名前は開発中のものです。：2008/11/08(土) 19:56:49 ID:xBkNDkUK

>>989
> コンテキストスイッチはタスクシステムでは不要というかもう実装されてるでしょ。
ない。

コンテクスト = スタック + レジスタ値だけど、所謂タスクシステムなるものは
メンバ変数やタスクコントロールブロックと名付けた独自領域にステートを
保存し、制御が移るたびに自前でそこから状態を復元する必要がある。

991 ：989：2008/11/08(土) 20:29:38 ID:jrTPhNiJ

>>990
OSでいったらコンテキストスイッチはスタック＋レジスタ値だけど
タスクシステムでいったらタスクのデータ領域
タスクのデータ領域といっているのは、>>990のいうメンバ変数やタスクコントロールブロックと名付けた独自領域と同じものです。

992 ：989：2008/11/08(土) 20:33:10 ID:jrTPhNiJ

途中で書き込んでしまった。
>>990
コンテキスト＝状況だからOSでいったらスタック＋レジスタ値なんだけど
タスクシステムならデータ領域＝メンバ変数やタスクコントロールブロックと名付けた独自領域が処理しているタスクに応じて切り替わっているから
最初から実装されていることになるんじゃない。

993 ：名前は開発中のものです。：2008/11/08(土) 21:51:27 ID:xBkNDkUK

>>991
> OSでいったらコンテキストスイッチはスタック＋レジスタ値だけど
> タスクシステムでいったらタスクのデータ領域
そんなオレオレ定義されても、話が混乱するだけだが･･･

994 ：989：2008/11/08(土) 22:32:13 ID:jrTPhNiJ

>>993
そういうことをいいたいんじゃないのか、すまんかったよ。
コンテキストスイッチしたいってことはタスクシステムをマルチスレッド対応にしたいということでいいのか？
なかなか大変そうだけどやる価値はあるのかもしれない。
オレには無理そうだな。

995 ：948：2008/11/09(日) 00:29:19 ID:nWf5qLS5

ソースと実行ファイルをまとめてうｐしますた。
VC6のプロジェクトになってます。
五千パイ型、なにとぞご指導のほどをおながいします。
といってもサンプルを置き換えただけなんで意味ないかもしれんけど、一応。

ttp://uproda11.2ch-library.com/src/11133038.zip.shtml
DLキーは task です。

試した限りではまあまあ面白くプログラムできそうな感じではあるけど。

996 ：名前は開発中のものです。：2008/11/09(日) 00:51:49 ID:G/ueWH6s

>>995
ゲームプログラミングで難しいのは、実行優先順位の管理より、オブジェクト間の
相互参照。タイミングがらみのバグが出やすい。

これだと、実質的にグローバル変数 (static CGameObject::objectlist & CreateEnumeration) で
管理してるようなものだから、むしろ手間かかりそうな気がするが。

997 ：名前は開発中のものです。：2008/11/09(日) 00:51:52 ID:S2s0HGZS

>>995
軽く眺めた程度だが、これを元にしてるのか
ttp://www.tnksoft.com/reading/classgame/engine/01/013.php

タスクシステムの説明を見るたびに思うが
実行順位とやらは本当に必要か？必要なら何に使うのか？

そのページでは「キャラクターの重ね順などに柔軟に対応できる」と説明されているが
それはタスクの実行順位でまかなうべきことなのか？

998 ：名前は開発中のものです。：2008/11/09(日) 00:55:07 ID:S2s0HGZS

新スレ立てようとしたが俺のホストは規制されてた
誰かよろ
隔離スレは必要だからな

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

part2 http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/
part1 http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

999 ：名前は開発中のものです。：2008/11/09(日) 11:52:18 ID:+pjnJyQQ

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

http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/

1000 ：名前は開発中のものです。：2008/11/09(日) 12:45:35 ID:JVmF+6vb

1000!

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。