1 ：
名前は開発中のものです。：
タスクシステムで～す。
http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98 あらすじ
新しいシステムが大好きなゲームプログラマの元に、二人組の詐欺師が
プロのゲーム開発者という触れ込みでやって来る。
彼らは何と、馬鹿や自分にふさわしくない仕事をしている者にはメリットが
理解できない不思議なシステムを紹介してくれるという。
プログラマは大喜びで紹介されたとおりに実装する。
他のプログラマにメリットを聞かれた時、自分がこれまで慣れ親しんだ
コードを正当化してくれるはずのメリットが説明できない。プログラマは
うろたえるが、そのシステムを自慢げに見せた後輩プログラマたちの手前、
本当の事は言えず、ありもしないメリットから目をそらさせるため
「馬鹿には理解できない」と言い続けるしかない。後輩は後輩で、自分には
メリットが理解できないもののそうとは言い出せず、空気を読んで目をそらす。
プログラマはメリットもないシステムに増築を重ねて開発終盤に臨む。
火消しプログラマも馬鹿と思われてはいけないと同じようにそのシステムを
使い続けるが、その中のまだ空気を読めていなかった新入りが、こう叫ぶ。
「このシステム邪魔だよ!」
5 ：
名前は開発中のものです。：2010/10/02(土) 16:46:55 ID:ivfidkIQ
タスクシステム最高や！
>2をチラ見しただけだが、主人公や敵やアイテムを同一の抽象クラスの継承で作って、
抽象クラスの配列で全部を管理する、ってのはタスクシステムとやらにあたるのか？
だとしたら俺は知らずに使ってたな。
んじゃ、納得できるまともな資料ないのかよ
タスクシステムを理解はできるが
特に新しくもない、びっくりすることもない、普通の汎用システムかなと思った
今のゲームでは０フレーム割り込みや、指定したタスクの削除、優先順位の変更とかが加わってるから ここの資料は古い
普通て
実行単位を抽象化したもの
基本的概念は今でも通じる
しかし抽象化が人によって１００人１００通りあって、ののしりありの状態
これでは発展しない
まとめ役が必要ではないだろうか
>>11 のように人格非難を行い、人権尊重を行わない環境では前向きな議論ができない
似たようなものに、ジョブやタスクなどあるが、これらを参考に１００％ではないが、納得できる抽象的にコード化できる人物が必要ではないか
そして、オープンソースにすることによって、より多くの人に使ってもらえて、さらなるフィードバックが行われ、より改善されていくのではないだろうか
今までは、タスクを一定の決まった業務名で決めきっていたが、今は抽象化というあいまいな言葉で表現するので、なかなか理解されにくい
おそらく C,アセンブラ時代のシステムと思われるが、メモリが大量に使えるようになった今ではもっと応用できるようになるのではないだろうか
＼ ／
￣￣￣￣￣￣￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＿＿＿_
／ ＼
/＼＿＿_／＼ ..／ ⌒ ⌒ ＼
／ ／ ヽ ::: ＼ ／ （●） （●） ＼
| （●）, 、（●）、 || （__人__） |
| ,,ノ(、_, )ヽ、,, |＼ ｀ ⌒´ _／
| ,;‐＝‐ヽ .:::::| | ＼
＼ ｀ニニ´ .:::／ .| | | |
／｀ー‐--‐‐―´´＼―┴┴―――――┴┴――――
.ｎ:n ｎｎ
nf|｜| | | |^!n ＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
ｆ|.| | ∩ ∩|..| |.| ＞ ＜
|: :: ! } {！ ::: :| ＜ NO THANK YOU ＜
ヽ ,イ ヽ :イ .＞ ＜
￣|／∨∨∨ＷＷＷＷ∨∨∨＼|￣
>>14 「ジョブ」や「タスク」は std::fucntion (boost::function) に、
それを集めたコンテナは std::list や std::map に抽象化および汎用化
されているだろ。しかもオープンソースで。仕様も明確に文書化されて
おり、関連情報も Web 上に関連情報もたくさんある。結果、もっと応用
できるようになっている。
これでもまだ何か問題ある？
歴史は繰り返すｗ
>>16 それをつかったタスクシステムを早く見せてみろ。
能書きはいいから早くやれ。
>>18 typedef std::function Task; typedef std::multimap<int, Task> TaskSystem;
レスが遅いっていう意味じゃないのか
うおーおちるｗｗｗ
落ちていいんじゃない
保守
27 ：
名前は開発中のものです。：2011/01/19(水) 04:08:40 ID:N8paXvut
いってみたらすでに論破されてた
名前からして不明瞭。
そこに嫌な匂いを見出せるのは、
ある程度苦労したプログラマ。
これが島国さんやnyaxtさんの書いた記事だったりすると反応違うんだろうなｗ
ゲーＰＧはネームバリュー（ハッタリ）に弱い人間少ない気がする
むしろ、俺がそいつを粉砕してやるぜ的な
PCエロゲ界の貴公子の近代的～が唯一の参考文献としてあげられてるのは
「私の話は眉に唾をたっぷり塗りたくってから読んでください」というシグナルだろ
メモリアロケーションとタスクコントロールの都合をゴチャ混ぜにしてる時点で
ウェブ上に幾度となく流布されてきたアマチュア発の怪文書の仲間入り
いいかげんCEDECで白黒はっきりすべき
なぁなぁで適当なセッションばっかやってるんじゃねーよ
このぐらいのトラップはあったほうがいい
理解はできるが それほどはしゃぐほどのしろものじゃぁないと思う ＞ タスクシステム
いやそれじゃまったくわかってない
アセンブラレベルで組んでたら当然このようなシステムになると思う ＞ タスクシステム
なので、今の１G単位のファイル扱い時代には、
>>3 にあるとおり邪魔すぎる
しかも
>>2 のリンク先のとおりに組んでたら１００％環境に依存したものができるね
構造化設計がきちんとできれば、別に困らない
ちょっとしたところを書かせても、
ちょっと見通しよく書いてくれる人と、
ちょっと見通し悪く書いてしまう人が居るね。
元々はアセンブラレベルで簡単なコルーチンを実現するシステムだった（ジョブコン）。
いつのまにやら、C言語で実装されコルーチンではなくなって、コールバック管理システムになり、
いろいろごてごてと御利益の能書きが追加された。
これはひどい
ツイッターは宮崎県の東国原元知事でもやってる
タスクシステム、っていう名前からして臭いわな。
便利なフリした機能の癒着やごった煮を連想させる。
ツイッターやってる一般人ってキモイよな
ツイッターやってる一般人がというか、たいした情報でもないのに情報発信源気取りでしゃべってるのがキモいんだと思う。
あまつさえ斜め上の内容だからなおさら。
タスクシステムとまったく関係のないやりとりをする こいつらがキモイ
もはや根絶の時期がメインの話題になるぐらいのものでしかない。
てか、まだ使ってる人居るのかネェ。
だいたい、プログラム自体が処理を実行順に並べたもの「そのもの」なんだから、
自前で処理リスト持って、毎フレーム逐次実行する意味が分からないよな。
まるでバーチャルマシンじゃん。
void do_tasks(){ task1(); task2(); task3(); /*←タスクリスト*/ }
↑こんなん作っておいて、毎フレーム呼びだしゃ良いだけだもんなぁ。
バカはつかわなくていいよ
みんなでプログラムしようぜ とみんながやる気になる
みんなでいろいろな意見が出され、いろいろ議論される
とても活発、いろんなスレがたてられる
実際につかわれはじめ、みんな期待する
実用化されたものが発売、みんなキター状態
これを見たマスコミが これはすごいともてはやす
マスコミの情報を見て、やじうまがあらわれる
タスクシステムのすごさを報道
バカには理解できない そのうえ、数は多い
こんなもの何の役に立つんだ 根絶してしまえ ← いまここ
つまりバカほど・・・おっと もはやまともな奴は静かにしてるな
釣りはもっと上手くやれよ
タスクシステムは
抽象的には
発生する大量のオブジェクトを
動的に一元管理・実行できるってのがすべてだと思うんだけど
逆にこれ以外の方法で大量のオブジェクトを扱える設計は
何が考えられますか？
コード中のあちらこちらでメモリ領域確保してたら
わけわからなくなりませんか
>>57 全部「タスク」の名の下にごちゃまぜになってるほうがわけわからなくなりませんか？
「～のコンテナ」を必要なだけ必要なところに置けば十分で、さらにそのほうがコンテナの
スコープが狭まり、個別に名前付けが行われるぶんコードは読みやすいはずです。
コンテナが分かれていれば、特定のオブジェクト郡にだけ適用できる最適化を局所的に
行うこともできるようになります。（ここは挿入削除が頻繁だから list で、ここでは
要素数がずっといっしょだから vector で、などなど）
逆にコンテナがまとまっていた場合、そもそもそういった最適化が不可能になってしまうか、
できたとしても全体に影響が波及してしまうことになり、危険度が上がってしまうでしょう。
> コード中のあちらこちらでメモリ領域確保してたらわけわからなくなりませんか
逆に、なぜ「わけわからなく」なってしまうのかを追究してみたいところです。
>>58 過疎っぽいからレスつかないかと思った。ありがとう
>「～のコンテナ」を必要なだけ必要なところに置けば十分で
というのがまさしく、気になるところで、例えば
擬似コードですが
class enemy ｛
Tama tama[];//唯一の参照保持コンテナ
弾発射（）｛
//３つ発射しちゃうぞー
tama.add(new Tama());
tama.add(new Tama());
tama.add(new Tama());
｝
}
というような実装を単純にしてしまうと
enemyが弾が消える前に破壊されて
deleteされるような事態になったら
おかしなことになりかねませんよね
当然、こんな場当たり的な領域確保できないわけで、
弾のコンテナのスコープはどこがいいのか、
どう管理するんだ、というような話になると。
つづく
60 ：
名前は開発中のものです。：2011/03/02(水) 16:34:46.21 ID:VVBDgu3W
つづき
>コンテナが分かれていれば、
>特定のオブジェクト郡にだけ適用できる最適化を局所的に
>行うこともできるようになります。
というのが、結局のところ
http://d.hatena.ne.jp/alwei/20110117/1295290033 のタスクシステムの解説記事の中の
■その他の問題 で、
>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>管理面でも速度面でも良くなったりします．
というふうにタスクシステムの範疇から出てないのかな、と。
長くなって申し訳ない。
>>59 > 当然、こんな場当たり的な領域確保できないわけで、
「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
仕様が出てきたから不都合が発生したという話にしか見えません。
それがたとえば「弾」ではなく enemy と共に破壊される「角」とかそういう
オブジェクトであれば何も問題はなかったのです。
> 弾のコンテナのスコープはどこがいいのか、
> どう管理するんだ、というような話になると。
そういう話になるでしょうけども、だからといって「タスク」も「システム」も
カスりもしません。
典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ
ではないでしょうか？
>>60 >>タスクの数が異常に増えたりする際は複数のタスクリストやコンテナに分けた方が
>>管理面でも速度面でも良くなったりします．
>
> というふうにタスクシステムの範疇から出てないのかな、と。
「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
ことでしょうか？
それを完全に否定する材料は持ち合わせていませんが、それが言えたからと
いって何になるのか、何がうれしいのか、わかりません。
>>61 どうしてもレスが長くなってしまう。。
>「当然」ではないでしょう。「弾が消える前にenemyが破壊される」という
>仕様が出てきたから不都合が発生したという話にしか見えません。
いやいや、さすがにそれはちょっと…
シューティング以外でも魔法でも矢でもエフェクトでもダメージ表示でも。
> 典型的には「弾のコンテナはもうひとつ外に持っとくか」という話になるだけ ではないでしょうか？
それって、enemyのコンテナの隣に弾のコンテナってイメージでいいんですかね。
80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>ことでしょうか？
結局、
いわゆるタスクシステムとの違いが
「敵と弾を分離してるだけ」とか、
「シーンクラスとかキー入力処理クラスまで
同じコンテナのタスクとして扱うのは
気持ち悪いから、別処理にする」程度の話なら
タスクシステムのような方言の多い設計技法の実装としては
よく見かける気がするんですよね。
つづく
つづき
それを指して「これはタスクシステムではない！」ってのは
正直に言うと得るところがないです。
むしろ知りたいのは
その範疇には収まらない設計はあるのだろうか、
あったら知っておきたいなと思って、
>>57の
>逆にこれ以外の方法で大量のオブジェクトを扱える設計は
>何が考えられますか？
と聞いたわけです。
知らない以上、うまく言えないんですが
コンテナが不要なデザインパターンみたいなものとか
存在するのかなと思って。
うれしいとかうれしくないとか別にないです。
>>63-64 > いやいや、さすがにそれはちょっと…
何でしょう？書いてもらわないとわかりませんよ。
> 80種類の敵がいたら80個コンテナ作って自機との命中判定のために80個の
> 参照作って、なんてのは考えにくいから「敵コンテナ」に統合しますよね。
どちらにもメリット・デメリットがあるでしょうから、そうするかもしれませんし、しないかもしれません。
ただし、少なくとも僕が「タスクシステム」と聞いてイメージするようなグローバルなリストに統合することは
無いでしょう。
>>「オブジェクトをコンテナに入れたら、それはもうタスクシステムだ」という
>>ことでしょうか？
...
> タスクシステムのような方言の多い設計技法の実装としては
> よく見かける気がするんですよね。
つまり、答えは yes ということですかね？そういうことなら「タスクシステム」などという不明瞭な
言葉は使わず、はじめから「コンテナ」と言って欲しいところです。
> それを指して「これはタスクシステムではない！」ってのは
> 正直に言うと得るところがないです。
何かを指して「これはタスクシステムではない！」などとは言ってません。
ただ、仕様に沿ってコンテナを用意しただけのコードを指して「これもタスクシステムですね？」などと
言われれば「知らんがな。何なの？」となります。
> コンテナが不要なデザインパターンみたいなものとか
そんなものを探すことに意味があるとは思いません。
>>65 うーん、そういう結論かｗ
なんにせよ、つきあってもらってありがとね
過去ログみてたら、良いこと書いてあったので貼っとく
タスクシステムは嫌いだけど、ここにタスクシステムのメリットが示されてると思うわ
タスクシステム総合スレ part5
http://2chnull.info/r/gamedev/1234977661/874-880 874,880的な理由でタスクシステムを採用するのはありだと思う
ゲーム開発に最初から完成された仕様を求めるのは難しいからな
ただ、仕様が完成されている（面白さが実証されている）ゲームに対して
タスクシステムを採用しようという意見には賛成できないがね
>>68 その場合は「タスクシステムを採用する(ｷﾘｯ」などとは言わずに、
「わりと何でも入るごった煮リストを予備で用意しとくよ。
設計に悩んで対応が間に合わなくなりそうだったら、とりあえず
ここに入れて済ませても良いよ。
でもなるべくデバッグ始まるまでには片付けるように考えてね。」と
正直に言って欲しい。さらに言えばそのごった煮リストにアクセスする
インターフェースのコメントに書いておいて欲しい。
70 ：
名前は開発中のものです。：2011/03/05(土) 12:11:49.38 ID:3H1ntObt
内容自体は別にいいとも悪いとも思わないんだけど
所詮設計手法であるにもかかわらず
タスクやらシステムやらたいそうな名前付けてるのに問題があるよな
そもそも、さっき出てきた、敵やら弾やらは、ゲームオブジェクトであって、タスクではないだろ。
なのにタスクシステムとかいうから・・・もうそっからしていかれてる。
ノンプリエンプティブなタスクです。
SPUのようにメモリが共有できないプロセッサで有効な手法ってありますか？？
>>73 問題も挙げずに手法もクソもあるか。
何が問題なの？それはこのスレに関係あるの？
お前が頭悪い
メモリが共有されてないのが問題だろ
タスクシステムは並列化でも関係あるし
>>75 共有されてないメモリを何らかの「手法」で共有しちゃおうって話だったの？
そりゃ無理だｗ
あほか
まーC++で一番簡単なのは、
template< typename _t > &obj_list(){ static std::list< _t * > inst; return inst; }
とかやって、テンプレートにシングルトンの型リスト作ってもらって、
obj.itr = obj_list< obj_t >().push_back( &obj );
って感じで型リストに登録して、
for( std::list< obj_t *>::iterator itr=obj_list< obj_t >().begin(); itr!=obj_list< obj_t >().end(); ++itr )
{ /*処理*/ }
って感じで型ごとにforeach回してやりたい処理して、
obj_list< obj_t >().erase( obj.itr );
って感じで登録削除する、やり方かなぁ。
処理の優先順位って、実際には型にくっついてる場合が多いし、型ごとのリストで十分なことが多い。
for文が煩雑に思えるのなら、マクロ使えばいいし、
attachやdetachも、テンプレート関数使えば、型推論が効くし、
コールバックにならないから、引数固定になることもないし、
型ごとにリスト持つからダウンキャストも発生しないし、
制御フローは書いた順そのものだから、可読性も高い。
手っ取り早くゲームを作りたいホビープログラマには打って付けだと思う。
>>79 タスクシステム関係なくね？スレ違いじゃね？過疎ってるからいいけど。
あとシングルトンは死ね。
81 ：
名前は開発中のものです。：2011/05/07(土) 02:25:37.71 ID:FaGHlUhW
アマチュア発のオカルト怪文書だね
>>83 foreachの並列化なんて超簡単じゃん。
みんな、オンラインゲームを支える技術つまて本読んだ？
タスクシステムが紹介されてるな。
実際のオンラインゲームでも使われてるんだな。
具体的に何が？ｗ
とりあえず買ってきたけど何頁だよ
タスクシステムってlistにオブジェクト突っ込んでイテレータでぐるぐる回しながら処理を実行させるだけのことだろ
90 ：
名前は開発中のものです。：2011/09/03(土) 21:11:50.72 ID:rKhpPrRf
タスクシステムか・・・なつかしいな
ゲームオブジェをどんな構造でまわすか、って悩むのはゲームプログラマなら
みんな通ったことのある壁の一つだよね。
最近は情報があふれてるからこの辺までは定石のお勉強で到達できるけど
ここから先が自分で考えられる人か教わらないとできない人か、の登竜門な感じ。
ゲームプログラマ向きじゃないのはここで詰まったまま脱落するんだよね。
まぁここを超えてももっと高い壁がまだまだ続くんだけどね・・・
で「タスクシステム」を極めることが目的じゃない、と気付き、
使い回しの効く便利ルーチンをいくつか作るに止めるか、
なぜか目的を忘れてハマるか、という分岐があるんだけどね。
92 ：
名前は開発中のものです。：2011/09/05(月) 04:56:06.83 ID:qHGk9if0
ゲームの仕様、開発言語、対象マシンのリソースと制限、納期とメンバーのスキル、etc...
タスクシステムの扱う範囲はゲームのコアアーキテクチャに関係してくる
最適解がコンテキスト依存な問題の典型。
これらコンテキストは作ろうとしているゲームによって千差万別だからネットで一般解を聞いても
ケースバイケースという一般論しか返ってこない。
さらに「タスクシステム」ってゲーム業界で慣習的に呼ばれてるだけで
実装はゲームによって全然別物。
ってことで結局サンプルソースとかで実装されてるタスクシステムと言われる
ものを参考にでもして作る予定のゲームにあわせて自分で考えて実装しろや、となる。
そんで、あれ、もしかして、これ要らなくね？となる。
型ごとにリスト用意して、任意にforeach回すだけ。
>>93 レベル（ステージ）毎に必要な型のforeachを実行する関数を用意するわけか。
レベルデザイン時の柔軟性が失われないか？
もしくは全ステージで同じ型出すと、ステージ色が失われないか？
コールバックさせるupdate関数の引数が固定になる方が柔軟性が損なわれる。
そうだよな
必要な情報ってオブジェクトごと違うのにそこをわざわざ統一しちゃうのは
逆に必要な情報が関数みてわからなくなっちゃう
ホーミングミサイルで更新にターゲットが必要ならそれが必要な情報とわかるように
むしろ引数で明示するべき
その情報がなければこの関数は実行できないよと
これがプログラムの基本なんだよ
書泉でゲームプログラムフェアってのやってたから「何とかでつくるシューティング」とか
何冊か立ち読みしたら6冊中4冊でタスクシステムの説明とそれ使ったゲームがのってた。
PHPのやつとAVGの二冊はタスクシステムじゃなかった。
>>92 の言うようにC++とかJavaとかObject-Cとかで実装は別々だったけど、作るゲームにあってるなら
タスクシステム使って。
ポインタや参照使えない言語使う、とかタスクシステムが合わないゲーム作るならほかの方法で実装すれば
いいんじゃないかな。
>>95 書籍で紹介されているタスクシステムでは、個体情報を含むメモリブロックへの参照をメンバに含む
構造体ポインタを引数経由で渡して、個体情報特有の構造体にキャストしている。
むしろ何でもありで、情報のやり取りの柔軟性が損なわれることはない。
>>96 呼ぶ側は呼ぶことしか行わない方が、分かりやすい。
また例で言うとターゲットが存在しない場合の条件分岐を、呼ぶ側にしわ寄せ実装する必要が出てくる。
生存および消滅の過程や、何をターゲットにするかは、対象リストへの広域なインターフェースを用意して、
個体タスク内で自律的に行わせる。
基本と言い切るのは勇み足じゃないか？
>>98 バッカ
全然関係ない
ちゃんと引数で渡すようにすれば何が何をやるべきかちゃんと見えてくる
なんにも見えないのは年がら年中そうやってオブジェクト同士の関連を面倒だからって
端折ってるからなにも分析できないなにも進歩しない
書籍にソースコードを全て載せるぐらい小さいゲームや、iphoneとかandroidのミニゲームみたいに
ゲームの状態推移がほとんどなくてゲームオブジェも簡単に全て把握できる、みたいなシンプルなゲームなら
タスクシステムのような単純な仕組みで実装する、って判断も十分合理的かと。
どんなアルゴリズムにしろアーキテクチャにしろ、適した用途と適さない用途はあるわけで。
>>99 がどんなハードでどんな仕様のゲームを想定してるのかは本人しかわからないけど
想定しているゲームの仕様には適さないと思うならタスクシステムじゃなくもっとそのゲームに適した仕組みで
実装するのが現実的だと思うけど。
型ごとにリストを用意して、
必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
引数も関数名も自由に決めれるし、
書いた順に実行されるから、
タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
タスクシステムってタスクを順番に逐次実行するんでしょ？
でもプログラムって放っておいても逐次実行だよ？
void do_tasks(){ task1(); task2(); }
って書いとけば、それそのものがタスクのリストだよ？
わざわざ動的にタスクのリストを用意して逐次実行する意味ってあるの？
それじゃまるでインタプリタやVMだよ。それも碌な制御構造もない貧弱で直線番長な。
折角C言語やC++にはif文やらなんやらの立派な制御構造があるのに、
タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
言語の持つ折角のメリットを殺しちゃうことになるんだよ？
update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
動的にタスクのリストを用意するから、
ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
わざわざそんな茨の道を行く必要は無いんじゃないの？
＞タスクシステムにありがちな、実行順のソートとかワケワカラン処理も要らないし。
上であげてるゲームでは実行順のソートとかワケワカラン処理は必要ないケースだし
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
単純なゲームだから引数にコンテキスト渡すだけで解決。
＞ソースコードを読んだだけではタスクの実行順が分からないってのもマイナスだね。
ソース2～3個で完結してるようなゲームだし、普通のプログラマなら十分把握できるでしょ・・・
あと、タスクだと敵出現のシーケンスは、データ読んでその種類のタスク生成してくっつけるタスクの原理を
うまく使ったシンプル実装。
これを逐次駆動でタスクよりシンプルに実装できるのかな？
タスクの方法より短くシンプルなコードでSTGの弾、エフェクト、敵AI切り替え、ボス、敵のシーケンス化、等々を
実装できるのならその方法でもいいかもしれないけど・・・
書籍のサンプルでは上記全てタスク実装で1個のソースにして綺麗にまとまってたから、逐次ベタ書きで
これよりシンプルに短くこの仕様全て実装するのは難しいと思うけど。
STGのサンプルの大多数タスクシステムを採用してるのはそれなりに合理的な理由があると思うよ。
実行順のソートが必要ないなら、なおさら動的にタスクリストを持つ必要ないじゃん。
ソースコードにベタでtask1(); task2(); task3()って書いてけよ。
なんども言うけど、ベタで書いたほうが、タスクシステムよりよっぽどシンプルなんだ。
型ごとにリスト用意して、必要に応じてupdateってのは、
名前すら付いていないほど、普通に考えりゃそうなるだろうってやり方。
だから、単純さを武器にタスクシステムを薦めるのは可笑しい。
タスクシステムは、最終ビルド後、製品出荷後で、
後からプログラムを拡張したいときなんかに使われるような、それなりに高度なやり方。
プラグインやMODやドライバなんかで使われる手法。
その必要も無いのに使うものではないんよ。乱用なんよ。コールバックの乱用。
list<弾*>弾リスト; list<エフェクト*>エフェクトリスト; list<敵*>敵リスト、list<ボス*>ボスリスト;
foreach( 弾リスト ) { update( 弾 ); }
foreach( エフェクトリスト ) { update( エフェクト ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( ボスリスト ) { ボス->シーケンス(); }
な？簡単だろ？
型情報も殺さないし、引数も自由だ。
複数処理を型に跨って順不同に呼ぶことだって出来るぜ？
foreach( 敵リスト ) { 前処理( 敵 ); }
foreach( 弾リスト ) { 前処理( 弾 ); }
foreach( 敵リスト ) { 敵->AI(); }
foreach( 弾リスト ) { update( 弾 ); }
foreach( 敵リスト ) { 後処理( 敵 ); }
タスクシステムだと言語本来が持つ制御構造を殺しちゃってるから、
こう言うことが難しい。
敵->AI();とか書いちゃったけど、実際には
敵->AI( 敵 ); だな。ごめんごめん。
ついでに。
foreachを多重ループにすれば、相互作用の記述も簡単。
タスクシステムですると破綻しかねん処理だ。
foreach( 敵リスト ) //二重ループ
foreach( 弾リスト )
{
当たり判定とか相互作用的なもの( 弾, 敵 )
}
逐次実行の書き方って...本気でこのコードでゲームを最後まで書くっていってるの...？
まぁこー書かないとコード追えないって言ってるから、しょうがないのかもしれないけど...
タスクシステムで実装されたSTGゲームは書籍なりネットなりでいろいろコードみれるけど
この方式で最後まで完成したちゃんとしたSTGのコードって今まで一つも見たことないな。
論より証拠で、どんなものになるかぜひ完成したものを見せてほしいな。
一応書いておくと、話題に挙がった、タスク = ゲームオブジェクト なタスクシステムのほかに、
タスク = 純粋な処理 なタスクシステムもある。
一見良さそうだけど、種類の違うタスクを同じコンテナに混ぜ込んじゃうから本質的には何も変わらない。
コンテキストが必要なタスクの場合、
タスクのコンテキスト構造体を作って型ごとにリストで管理。
foreach( タスク1のリスト ){ タスク1の処理( タスク1 ); }
foreach( タスク2のリスト ){ タスク2の処理( タスク2 ); }
コンテキスト不要なタスクの場合、タスク=関数。
foreach( 敵リスト ){ タスク1( 敵 ); }
foreach( 敵リスト ){ タスク2( 敵 ); }
こうした方が良い。
>>108 なんでゲームやSTGに限ろうとするの？
ほとんどのアプリが、型ごとにリスト持ってて、必要に応じて更新ってスタイルだよ？
4mf44gCTだけど、みんなのエネルギーもらってるみたいで楽しいよ。
>>99 繊細なんだな。俺は煽るつもりはなかったんだ。
>>101 ＞必要に応じてforeach回す方法の方がタスクシステムよりシンプルだよ？
いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
解決策としては、むしろ以下の方針で、ソースの透明性確保の努力をするべきじゃないか？
１）呼ぶ側の構造をできるだけシンプルにする。
２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
３）個体同士の相互作用のメカニズムを統一して単純化する。
上の方針を守っている限り、柔軟性のあるいわゆる「タスクシステム」の方が有利だと思うんだが。
>>106 ＞タスクシステムだと、タスクを前から順番に実行することしか出来ないから、
＞言語の持つ折角のメリットを殺しちゃうことになるんだよ？
＞update関数の引数が固定になっちゃって、これも言語の機能を殺すことになるよ？
言語の「メリット」「機能」というのが曖昧だな。
本質ではないかもしれんが、
>>106をみると敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
このように分ける必然性がわからない。
むしろハードコーディングにより、このように分けてしまうと柔軟なレベルデザインの妨げになるような予感がする。
あと誤解しているが、書籍などで紹介されている「タスクシステム」は、タスク登録時に優先順位（Priority）により各個体の実行順序を制御できる。
だから実質的に、同種の個体で実行順序をグループ化することも可能だ。つまりこれまでID:+MWn67Ig / 2Lv+in6pが提起している「制御構造」の問題は解決されている。
>>110 なぜタスクシステムを使うべきでないケースでタスクを使うことを考えるんだろう...
>>100 の前提のとおり、タスクシステムにしろどんな仕組みにしろそれを使うケースは
それが合理的なケースだけ、というのは当然でしょう。
なにか否定している理由は合理的な考えから出たものとは違うみたいなので
これ以上続けても意味のある結論は出なさそうですね...
これはもう石頭でどうしようもない。物事を勘違いしたまま突き進んじゃってる。
>いずれにせよ個体の種類と量が増えると、人間の頭ではワケワカメになると思うんだが。
ワケワカにならないように、違った型のオブジェクトを同じリストに突っ込まないようにするわけで。
ワケワカでOKってことはないでしょ？
>敵クラスについて、前処理、AI、後処理と分けていて、非常に複雑な印象を受ける。
>このように分ける必然性がわからない。
敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
一回ずつオブジェクトをupdateでなめなめして、それで全ての処理が終わるとは限らないだろ？
>タスク登録時に優先順位（Priority）
それは、違った型のオブジェクトを同一のリストに入れるから必要になる仕組みであって、
苦肉の策であることを分かって言ってるのか？
そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
>１）呼ぶ側の構造をできるだけシンプルにする。
物事は上流で解決した方が良い。
>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
言ってる意味が良く分からんが、あえてエスパーすると、メモリアロケートの話ならアロケーターの仕事。
>３）個体同士の相互作用のメカニズムを統一して単純化する。
上流(メインループ部)を直接改造できる状況下においては、
相互作用は上流でするべき。
>>114 逆にタスクシステムを使うべきケースって何？
ああいったコールバックシステムは、
上流部が固定されている場合だけだと思うんだけど。
ゲームはメインループ部を自由に触れるよね？
リリース前なんだから。
>>115 おい、煽るなよｗ
＞ワケワカ
>>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
俺はそうなる事態を予見して、解決策を提案したんだが。
＞敵クラスの前処理とAI処理の間に、他クラスの別処理が入ってるのが味噌。
率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
＞そしてそんな貧弱な制御構造で、言語本来の制御構造と対等に立てるとでも？
例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
もっと「言語本来の制御構造」のメリットが出ている例を挙げてもらいたいな。
所詮は場末の小競り合いだ。
落ち着いて逝こうぜ。
>>117 >>116のような記述がズラーーーーーーと並んだら、ワケワカメになるとは思わないか？
そこにズラーーーと書いてあることが、格ゲームオブジェクトのupdate関数に移るだけだから同じこと。
むしろ、分散されて余計わけが分からなくなる。
>率直に言うと、複雑な相互作用メカニズムになっているという気がするな。
あえて例で上げたまでだからね。
だけど、一回のupdateで全ての更新が終了するとは限らないだろ？
>例で示されている要件は、タスクシステムでもクリアされているんじゃないか。
二回のupdateが必要な場合はどうするの？
a->update1(); → 何かの処理 → a->update2();
C言語本来の制御構造なら、やりたいことをやりたい順で書けば済む。
タスクシステムだと、タスクシステムの仕様に制限される。
>>116 ＞物事は上流で解決した方が良い。
上流のフローは、単純でなければいけない。
その解決策は、先に書いた通り。
＞>２）個体の状態の両端末、すわなち生存・消滅に関わるメカニズムを統一して単純化にする。
＞言ってる意味が良く分からん
生存＝個体がタスクリストに登録されている状態
消滅＝個体がタスクリストに登録されていない状態
＞相互作用は上流でするべき。
詳しく。
レベルデザインの足かせとならないか？
＞逆にタスクシステムを使うべきケースって何？
確実に言えるのは、メモリリソースが希少な場合だろう。
＞ゲームはメインループ部を自由に触れるよね？
そんなに簡単にいじれるかな？
どんな触り方を言ってるのん？
>>118 ＞一回のupdateで全ての更新が終了するとは限らないだろ？
これ具体例教えてもらえないか？
ところで（書籍ででている）タスクシステムでも、（この議論の流れでは反則になるかも知れんが）
ちょっといじれば各個体にupdateを2つ持たせることは可能だぜ。
優先順位を2つ持たせることも可能だ。
メインループで登録リストを2回なめることになるが。
ひさしぶりにタスクシステムな人が来たみたいだな。
まずは
>>2-4 あたりを読んで、それでもまだ何か言いたいんなら、まぁがんばって。
>>105 俺はお前を支持する
こっちのほうが１０００倍楽
タスクシステムの起こすバグはハンパじゃない
>>105に書いてある内容は本来書き並べないといけない処理なんだよ
必要に応じてわかりやすい単位で関数に分けることは必須だけど
これをタスクシステムにしたら実行しないとこの順番がわからないとか
開発がホント酷いことになる
派遣で色々と会社まわったけど
タスクシステムを使わないところはバグの数が１０分の１ぐらいだかんね
タスクシステム使ってるようなところはバグ数がプロジェクトで３万（万？はぁ？）とか
明らかに数字がおかしい
もともとはアセンブラ時代のテクニックだろうよ
CPUやメモリ資源もない時代。
１．ゲームオブジェクトを統一的に扱う。
２．アラインメントを考慮したメモリにやさしい固定長のオブジェクト
３．固定長のオブジェクトを柔軟に扱うためのプロセスアドレスの保持
今の時代は
１は継承で可能。２は資源的にちっとやそっとの無駄は気にしない。
３は今で言うところのメンバ関数とか関数ポインタ。
今の時代なら、
>１．ゲームオブジェクトを統一的に扱う。
はテンプレートでしょ。
ジョブコンの説明を確認すればわかるが、非常に単純化されたコルーチンのようなものの
メカニズム、というのが元の姿。
違った種類のジョブを単一リストで管理する理由はないね。
上流の呼び出し部分が出来合いのもので、
改変が許されないのなら別だが。
タスクシステム大佐：
「私のフレームワークはデリケートにチューニングされている」
違った種類のモンを一端混ぜておいて、
場合によっちゃあ後から分別するんだから間違ってる。
別に扱いたいのなら、別に持っておけば十分だし簡潔。
>>92 で言ってることが全てなんだろうな
メンバーのスキルが「型固定で全てのフローをコードに直書きしないとソースが読めない」
みたいなレベルの場合はタスクシステムとか関数ポインタ使うとバグだらけで完成しないだろうし。
その場合はタスクシステムは使わないのが正解だろう。
Unreal Engine等の近頃のメジャーなゲームフレームワークの場合はタスクやアクターを使っていて
「敵やアイテムを型固定にしてコードに直書き」なんて作りはありえないけど
プロじゃなくて同人とかなら無理してスキルに合わない方法を背伸びして使わずに
自分のスキルで使える範囲の言語のフロー構造だけで作る、という結論は間違っていない。
タスクシステム = 上級者用 ？？？
これはこれは。
132 ：
名前は開発中のものです。：2011/09/11(日) 00:03:27.99 ID:Y7Irx4Sl
タスクシステムが上級者用なんて、まさかwww
タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ただそんな単純な仕組みでも、つかうと手に負えなくなってバグが直せない、
みたいな超初心者なら、もっと単純な方法で作るのが正解だ。
hello worldの次のステップのプログラマならifとswitchだけ、ぐらいで
つくるのが適切。
俺はタスクシステムに逃げちゃう設計者は根性がないと思うけどね
この構造がダメなのはみんなうすうすわかってんだよ
>>132 > タスクシステムなんてゲームプログラマなら使えて当然の基礎中の基礎。
ということにしたいのですね。
>>3
>>97 のようにタスクシステムを使って最後まで完成されたゲームは
沢山あるから書籍にしろネットにしろタスクシステムのサンプルには困らん。
完成してゲームという最終成果が出ている以上、そのゲームで必要な機能は
満たしているわけだし。
根拠が「根性」で出せるサンプルが foreach～だけ、みたいなのよりかは
採用するにしろしないにしろ、タスクシステムの例の方が参考価値がある。
ゲームを完成させたこともない人の言う「みんながうすうす」って言葉には
正直言ってこれを覆すだけの説得力が無い
>>135 「タスクシステム」と言って具体的に何のことを指してるのかよくわからないから、
ネットのほうの「タスクシステムのサンプル」をいくつか URL で示してもらえませんか？
>>136 >>92 を見ればその答えがわかると思うね。
その上で疑問に思うことがまだあるなら個別にコンテキストを明示
して聞かないと無意味。
>>137 つまり「タスクシステム」と言って指しているものは具体的にはわからんし状況によって変わりうる、
ということでしょうか。そんなもの役に立ちませんし「基礎中の基礎」だなんて具体的な技術である
かのように言えるわけないですね。なんかおかしいですね。
現実的に多くのゲームで「タスクシステム」と命名されてる構造が使われてるわけだ。
それを「共通じゃないから無意味」と結論するのは勝手だけどその行為もまったく無意味。
参考になるかどうか、現状のコンテキストから判断して適切に参考にして
作るゲームに役立てることの方がはるかに有意義。
>>138 書籍などで紹介されているもは、タスクシステムの一般化された形態であり、
あとはアーキテクトが、場合に応じて、一般化形態から出発して特殊化するんじゃないかな。
一つのキャラを完成させるために上流も下流もいじる必要があるとなったら、
それこそ到達点が低くなる。
力を注ぐ必要のある要素は、キャラの基本的な出現消失の管理以外に一杯ある。
出来るだけ、いじらなきゃいかんソースの場所減らそうって目的で、
メインループ内を抽象化したのがタスクシステムじゃないか。
一方、上流のタスクシステムのアーキテクチャを改修すれば、当然、下流側への影響は絶大なわけで、
>>133は、ヘッポコアーキテクトが、途中で無責任改修やっちゃった事例なんじゃないか？
そんな奴はフレームワークに何使っても、むしろ何をやってもｗ上手くいかないんじゃないかと想像が膨らむ。
>>139 そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
後を絶たなくて困るんですが、あなたのいう「タスクシステム」がそういうクソの山とは違うと
いうのなら
>>136
142 ：
141：2011/09/11(日) 01:44:12.94 ID:P9u9NThf
「後を絶たなくて」は言いすぎですね。今ではだいぶ稀になってますね。
>>141 ＞そういって自作コンテナや自作アロケータや無茶なキャストを下手に参考にされる人が
書籍や何かでいくらでも簡単に手に入るサンプルをみても全てクソだと思うなら
君がゲームの仕様に適したもっと適切な構造で実装すればいいだけだ。
「僕にはアーキテクトを決める権限は無いけどタスクシステムと命名されたクソしすてむ
で作らされたおかげでバグだらけ（涙）」って愚痴ならご愁傷様としか言えんが。
タスクシステムを一般的に語るなら、要はCなどの構造化言語がgotoを封じたもんだから、それに代わる状態遷移方法が必要なわけ。
そこでメインループというものを一般化し、キー入力イベント、敵の動き、当たり判定などの処理のセットを入れ替えることで状態遷移を可能とした。
でもgotoと同じく各状態への遷移が自由なためにスパゲッティになりやすい。
タスクシステマーのレベルが下がってきてるな。
そもそも、
update(){ task1(); task2(); }と処理を静的に書き並べていくことと、
実行時にタスクのリストを動的に生成して、逐次実行することに、
構造的な差はあまり無い。
ただ、後者は言語の持ってる型や制御構造といった機能を殺す。
アセンブラ時代に考えられたものだから、高級言語との相性は考えられてない。
>>144 ご大層なもん作らんでも、ごく普通のステートマシンの実装法でいいだろ
>>146 ごく普通のステートマシンってなんだよ。
ifやswitchをメインに構成された状態遷移ならともかく、
関数やクラスのポインタを扱うstateパターンとか、ごく普通のステートマシンのことを
タスクシステムと呼んでタスカーたちは崇め、奉ってるんだと思ったんだけど違うの？
全然違うね。
ステートマシンであることと、ごった煮リストであることは、なんら関係が無い。
>>144-148 つ
>>135 タスクシステムでそのゲームに必要な仕様を全て満たして完成されたゲームが
現実に多数存在する以上、せめてタスクシステムで作られたのと同じゲームを
別の実装で全て移植してみてそのコードの優劣を比較、ぐらいやらないと
根拠がお花畑すぎてちょっとなぁ・・・
童貞がリア充に女の口説き方を説教してるみたいで見ていて痛々しすぎる。
童貞のリアリティの無い妄想レベルのupdate()～みたいな程度の低いサンプル出されても
経験のある人間からしたら「ああ、この人一度もゲーム最後まで完成させた経験が無いんだなぁ」
ってバレちゃうだけ。
PHP信者が必死で主張する「PHPをdisるべきではない理由」にそっくりだなw
ごった煮システムを別の視点から見ればそれはステートマシンそのものであり、
一つのシーンを形作るタスクのセットを入れ替えることで状態を表現する。
副作用を許すような、普通のプログラム、普通のプロセス、普通のゲーム、は、
それ自体がステートマシンそのものだろ。ごった煮リストであるかどうかは関係ない。
ごった煮リストってのは、型関係なく、単一リストに何でもかんでも入れてる状態。
たとえ型や種類ごとに綺麗に整理整頓して分けてリストに入れていたとしても、
ステートマシンはステートマシンだわな。
>>149 タスクシステムは全てのタスクを単一リストで管理するけど、
それを複数リストに分けろと言っているだけなんだから、
これが可能であることは、プログラマなら誰でも分かるわな。
タスクシステムで書かれてないゲームも多いぞ。
とくに海外製のゲームなんかはベタで書かれていることが多い。
気になるんだったら、探してみたら？
というか、何かリストで管理しようとしたとき、
型ごとにコレクトしていくのって、割と普通じゃないか？
型によっては木構造とかで管理したいかもしれないし。
画一的に全てを同じタスクリストで管理ってのはどうかと。
タスクシステムはゲームに特化した状態管理の枠組みや方針、レイヤー、仮想環境ともいえるものを提供する。
>>153 ＞タスクシステムで書かれてないゲームも多いぞ。
わざわざ海外のゲームなんて探さなくても大昔のベーマガ時代から
ベタで書きなんて珍しくもないよ・・・
数当てゲームとかね。
しかし、
>>92 >>97 あたりに書いてあることをほんとに何一つ理解できてないんだねぇ
コンテキスト依存で実装考えるって当然のことを理解できる知能があればそんな
見当違いなこと言い出さないはずだけど。
まぁ、それをその当然のことを前提にしちゃうとどう見ても勝ち目が無いから
馬鹿のふりして話題そらして逃げてるんだろうけど。
ちなみ海外と言えばUnreal EngineやCryEngineのactorはタスクのごった煮とやらと
本質的に同じ。型固定でifとswitchだけ、なんて牧歌的な作りは影も形も無いけど、
それについてはどんな逃げ方をするのかな？また話題そらし？
偉そうなタームを並べちゃってw
現代言われている「ゲームエンジン」が、もはやタスクシステムとはぜんぜん違う
ものであることには目をつぶって「あれもこれもシステムだもん」とかw
結局その逃げ方しかできんのか。つまらんな。
taskもactorも逐次実行じゃないよ？ほら？どうした？ｗｗｗ
タスクシステムとはぜんぜん違う？どのタスクシステムとは違うのかな？
AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の
ゲームエンジンに本質的な違いがあるならその違いを言ってごらんよ。
その前にタスクシステムは普通の書き方のなんの問題を解決してるのか聞いてみたい
単に面倒なだけだと思うんだけどｗ
形勢不利だから話題そらしで逃げるつもりみたいだけど残念。
>>157 の答えを早くくれないかな。
actorが逐次実行なのはいいのかな？ゲームフレームワークも全否定？
タスクとゲームエンジンの本質的な違い、「ぜんぜん違う」と断言できるなら当然答えられるよね？
皆が話してる「タスクシステム」って何なの？
それは本質ではない、という逃げは万能だもんな。
はいはい、あんたの勝ちですよw
＞あんたの勝ちですよw
典型的だなｗｗｗ
「もう来ねえよ!ウワァァン」が足りないぞ？
>>160 ごった煮リストにインスタンスをすべてぶち込むシステム
なんだけど
明らかに取り出すときにそのぶち込んだものがなんであるか判定する必要があってやたらと面倒なんだ
しかもバグる
実行順序も制御きかねぇし
俺に言わせりゃ、actorなんか使うのはアホだけど、
それでも、フレームワークが社外製で、
メインループを触ることが出来ないっつーんなら、仕方ない。
ちょうどOSのウィンドウやドライバがそうなっているようにな。
新しいアプリやドライバ書く度にカーネル触って再コンパイルってわけにはいかないからな。
どうしてもコールバック前提の非同期処理になる。
だから、メインループ部に改変不可なフレームワークを導入するのはお勧めできないな。
メインループはゲームに合わせて自分で書いたほうがよい。
描画エンジンやサウンドエンジンや物理エンジンは外部ライブラリに任せてしまえば良いけどね。
典型的な勝利宣言バカだろ、おまえが
>>164 え？お前んとこって全部追加部分はdllかなにかで書いてるわけ？ゲームなのに？
そうでないならタスクシステムはいらないっていってる？
なんか特殊じゃね？
>>165 ＞はいはい、あんたの勝ちですよw
なんてみっともない白旗自分から上げといて
もう一度参上できるとはすごい勇気だね。
普通ならとても恥ずかしくて出てこれないよｗｗｗ
で？答えは出た？ｗｗｗ
>>163 実行順の制御は出来る場合が多い。
ただ、普通にtask1();task2();って並べて書いてくのと何も変わらないし、
ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
if文やfor文といった高度な制御構造を持てない直線番長だし、
高級言語では当たり前の機能の型も死ぬし、
実行効率もベタで書いたコードより速い訳ではないし。
>>158も言っている様に、ここまでの話の流れで、
だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
まったく使う理由が無い。
> だれも之と言ったタスクシステムのメリットを挙げてない。(し、実際無い)
> そのくせ、高級言語の持つ「型」と「制御構造」という2大機能を殺すわけだから、
> まったく使う理由が無い。
それなのに
>>167 のように完全に勝ったつもりでいるんだぜ？
キチガイここに極まれりだな。
>>135-161 で見事なまでに完全論破してるね・・・
型云々とか逐次実行とか言ってるのは
>>157 に答えられない以上
惨敗確定だｗｗｗ
どこが？
>>157 > AndroidやiPhone用のプログラム本にのってる近年のタスクシステムと近年の
さらっと流しかけたけど、これマジか？どの本にそんなの載ってるの？
>>172 俺的にはタスクシステムと同じかなー。
個人的にはこう言う仕組みってあまりメリット感じなんだよね。
それでも規格とドキュメントがしっかりしている分、ずいぶんマシだけど。
意味不明なんだよ
だってごった煮にしたから各update側には余計なもんが流れてくるから仕分けしないといけないし
一旦まとめる意味がまったくない
論破とか言われてもこの事実が覆る情報なんて一つも出てないじゃん
だからオナニーなんだろ？(笑)
正直に僕のオナニーを見てって言えよ
アセンブラ時代にフレームワークとして、
自前でちょっとこーいう枠組みを用意しちゃうよ、ってんなら理解できる。
だってそこには、型も、クラスも、リストも無いんだから。
ポインタ覚えたてのころにやると、何か得体のしれない黒魔術みたいでカッコいいじゃん
よく分からん…けど動いたスゲーって感じで
>>2のTCBは子供騙しでありロマンだよ
タスクシステムとUnreal Engine の actorの違いはドキュメントの有無。
ドキュメントがあるぶんactorの方がはるかにマシだが両方ごった煮には変わりないのでどちらもメリットは理解できない、と。
で、taskにしろactorにしろメリットがわからない、といってる人の目から見るとそれが何で動いてるのかわからない
何か得体のしれない黒魔術のように見えている、と。
で、ifとswitchだけ使って全て逐次実行でベタ書きしないとバグだらけになって作れないと主張している、と。
まとめるとこんな感じになるな。
Unreal Engineはレンダリング、コリジョン探索の両方を扱う枠組みを与えてくれるんだろ？
しかも、それぞれにしっかりした実装があるってんならメリットはまさにそれのことだろう？
自力でレンダリングや衝突を頑張っても、わりと汚くなって性能なんてお粗慢なんだから。
レンダリングやコリジョン探索を扱う枠組はUnreal Engineの一部ではあるが
アーキテクト上actorとは別階層の話だ。
レンダリングやコリジョン探索の実装があるならメリットは理解できる、というなら
同じようにタスクシステム上にレンダリングとコリジョン検索を扱うフレームワーク実装があれば
そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？
ん？
> そのフレームワークのメリットを理解できる、ということになるが、それでいいのかね？
いいのかね？ と言われても…。タスクシステムだろうと、Unreal Engineだろうと、
それ以外のなんかであろうと、一定の評価を得たライブラリの実装があれば、
それは評価できるし、使えるんならメリットだろう？ それだけのことを言ったつもりだが。
ちなみにこのスレで発言したのは
>>180が初めてだよ。
ほう、これが初めての書き込みね。そーいうことなら大変失礼。
ま、普通の人間はメリットについて当然そう考えるわな。
＞普通にtask1();task2();って並べて書いてくのと何も変わらないし、
＞ソースコード見ただけじゃ、何がどの順で動くのか分からないし、
とかでtaskもactorも全てメリットが無い、みたいな考えをするアレと一緒にされたら
誰でも不快だよな。大変失礼、謝るよ。
といいつつ、メリットは書き込まれない。一度も。
例えば、レンダリングエンジンやコリジョンエンジンが搭載されているタスクシステムがあったとして
とても便利だったとする。
でも、それらからタスクシステムを無くすともっと便利、
もしくは、有っても、あえてタスクシステム部は使わない方がもっと便利、
なわけだから、やっぱりタスクシステムは要らないって話になる。
そもそも、タスクシステムに描画エンジンやコリジョンエンジンをくっ付ける必要はないしな。
タスクシステム、描画エンジン、コリジョンエンジン、サウンドエンジンが
それぞれ選択的に利用できるようになってた方が、必要に応じて選べて便利だ。
そんで、タスクシステムだけ使わないのなw。
アンリアルエンジンのActorも使わなければ良いだけの話。
真性のアレのお出ましか。
＞メリットは書き込まれない。一度も。
今までのログや
>>2 のリンク先からいくらでも長所、メリットが
明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような
特殊学校級の真性君に根気よく説明するサリバン先生みたいな
聖人じゃないんだ、ゴメンネ。
＞アンリアルエンジンのActorも使わなければ良いだけの話。
世界でミリオンタイトルをいくつも出してるゲームエンジンを
使ってる優秀な人たちは君とは何故か違う考えみたいだけど、
君にとっては自分の頭で理解できないものを使わない、ってのは
正解だとは思うよ。
ソースロンダリングはいいって。
さっさとメリット挙げたら？
>>186 > 今までのログや
>>2 のリンク先からいくらでも長所、メリットが
> 明記されてる箇所が見つかるのに”一度も”とか断言しちゃうような
それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
より汎用的で粒度の高い現代的な手法の選択的な組み合わせで置き換えられるから、
今さらタスクシステムなんて作る必要はないよね。
ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
タスクシステム独特の長所だろう。
すでに出てるんなら URL 貼るだけでもいいんだから、出してもらえないだろうか？
タスクシステムのメリットはあがらない絶対だ
真性のアレ、はどう見てもおまえなんだが。
現代的なゲームエンジンのことなら「ゲームエンジン」と呼べばいい。
過去いくつも、全くそれに及びもつかない実例がある「タスクシステム」なんて呼称で、
現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
どう見ても真性のアレ。基地外タスクシステム信者。
>>188 ＞それらの長所・メリットは、仮想関数をはじめ標準コンテナや関数オブジェクトなど、
へぇ、「それらの長所・メリット」ってことは君は少なくともメリットがあがってるのを知覚できるぐらいの知能はあるんだね。
＞ここで出せ出せといわれているのは、こういう他の手段での置き換えが利かない
でも「他の手段がある＝メリットが無い」の論理的な間違いを認知できるだけの知能は無いみたいだね。
>>190 ＞現代的なゲームエンジンまで含ませよう、だなんていう発想をするおまえが、
ほぅ、つまり
＞アンリアルエンジンのActorも使わなければ良いだけの話。
みたいな真性ちゃんと一緒にするな、と言ってる訳ね。www
そしてやっぱりタスクシステムのメリットは挙がらない。
＞タスクシステムのメリット
一言でいえば抽象化。
まあ実際に抽象化によだれ垂らして魅力を感じる人種なんてごくわずかだよな。
タスク=処理なんか抽象化して、一体何をしようって言うの？
何か目的があるなら、その目的のエンジンでも作って外部に追いやったら良いだけでは？
例えば描画エンジンやサウンドエンジンや物理エンジンみたいに。
>>191 > でも「他の手段がある＝メリットが無い」の論理的な間違い
そこに突っかかってたの？
たぶんそういう意味でメリットを出せと言ってた人はいないと思うよ、ということを説明
したつもりだったんだけど。
で、結局「タスクシステム独特の長所」を挙げないということはつまり、「いくらでも」と
言ってたタスクシステムの長所、メリットっていうのはすべて他の（より汎用的でｒｙ）手法で
置き換えられるものである、と解釈していいのかな？
何も不思議じゃない。
//俺らのメリット算出方
foreach( A_list )
foreach( B_list )
{
compare( A, B );
}
//彼らのメリット算出方
foreach( task_list )
{
task->merit();
}
思考回路が元々違うんだよ。彼らは他とのかかわりにメリットを見出さない。スタンドアロンこそ至高。
>>195 ＞で、結局「タスクシステム独特の長所」を挙げないということはつまり、「いくらでも」と
＞言ってたタスクシステムの長所、メリットっていうのはすべて他の（より汎用的でｒｙ）手法で
「タスクシステム独特の長所」と「タスクシステムの長所」が都合よく混同されてるのはわざとかな？
それとも馬鹿だから矛盾に気づかないから？どっちかな。
まぁ「他の手段がある≠メリットが無い」と当たり前の前提の前では
そうごまかすしか無いんだろうねぇ・・・
だめだｗ会話にならねぇ
色々なジャンル、仕様、言語、ハード制限上でtaskなりactorなりのメリットを利用した
アーキテクチャで動く完成されたゲームが多数存在するわけだ。
で、これらの明示されたメリットが間違いであることを証明するためにはそれら全てのケースを、
他の手段の実装で元と同じ仕様を完全に満たせること、さらに実装コスト、CPU消費リソース、メモリ消費量、
生産性、その他諸々がtaskやactorを使うより良い値になることを証明する必要がある。
どれか一つでもそれが出来ないとそのケースではメリットが「ある」ってことになるからね。
「独自じゃない」「他の手段が存在する」ってのはそもそもメリットの有無とは無関係。
ってことで、あげられたメリットの間違いの証明よりしく。
とりあえず
>>2や
>>97にタスクのメリットの明記や説明とそれで完成されたゲームがあるからその辺から。
あとactorのメリットも否定してるみたいだから最新のミリオンタイトルでの証明もねwww
でないと「メリットが無いなんて言った僕が間違ってました、許してください（泣）」
って謝るか、また「誰も（僕に理解できる）メリットをあげられない」って真性知恵遅れの
ふりをするしかなくなるから。www
また逃げたか。
「明示されたメリット」とか「あげられたメリット」とか、もうね。
おまえわざとやってるだろ。
俺恐竜飼ってるんだ！！
マジだよ！
見せてやらないけどマジだよ！
どんな恐竜か言えないけどマジだよ！
今日もタスクシステムのメリットはあがらない絶対だ
なんか「ぼくのかんがえたさいきょうの」が、この基地外の脳内では、
タスクシステムという言葉の前に付いてるんだな、多分。
えーと、アクタモデルって非同期なんですが、タスクシステムで
非同期呼び出しを抽象化してる文献ってあります？
あるなら示してね。示せなければおまえの言ってることは脳内だと決定だから。
>>204 関係のない話だ
示せたところでタスクシステムのメリットの話とはほど遠い
カプコンのMTフレームワークってタスクシステムで実装してるんじゃないの？
個々のタスクを象徴化することで、マルチスレッド化の際に、処理に関係無くタスクをスレッドに割り触れるのと、個々のスレッドの負荷に応じて、タスクの再割り当ても容易に実現できるじゃないかな？
あと、タスクって単位にすることで、個々のタスクの処理時間を現道に管理することが出来るから、プロファイラーで、チューニングする場合も、負荷原因の分析が容易に実現できるじゃないか
↑現道→厳密
＞まあ実際に抽象化によだれ垂らして魅力を感じる人種なんてごくわずかだよな。
これを繰り返すのは悲しいぜ。
「あれはダメ」「これはダメ」なんてNG発言テンプレ繰り返していると、
浅はかな奴だなと思われてしまうぞ。
自分のやりやすいやり方でやればいいと思うよ。
>>206 上のほうのあったま悪ぃ奴等が考えたライブラリ使うほうの身になってみろってのｗ
的代物と予想
デビルメイクライとか人気有り気なゲームにも使われてるんだろうか？
>>199 taskだろうがactorだろうが適切に使われた場合のメリットを否定することは誰にもできない
あんたの勝ち
個人的にはタスクシステムというバズワードにあまり良い印象は無いけど
さすがにUnreal Engineまで否定したり単発IDでメリット絶対にあがらないとか連呼する馬鹿と同類にはなりたくない
ダメなもんふんだんに使っててもそれを上回るもんがあれば使うんじゃね？
だからといってダメな箇所はやっぱりダメだろ
>>206 「タスク」ってのは一般的な用語だから、それを使うゲームエンジンもあるだろう。
しかし、タスクという用語が使われているからと言ってタスクシステムと言うな、と。
タスクシステムという用語は
>>2 のように過去にさんざ俺様システムを指して使われてるから。
Unreal Engineはコンセプトじゃなくて、クオリティが買われてるんじゃね？
しっかり動いて、表現力もあるからじゃね？
で、タスクシステムならではの価値って何？
ハッキリしたメリットってやっぱり無いのか？
無限遠方の0地点との比較なら、どんなものでも存在しているだけで+になるから
かならず存在しているものには全てなんらかのメリットはあるんだけど、
そんな遊びに興味は無い。
他の何かと比較してこそ有用なメリットが浮かび上がる。
その意味でのタスクシステムのメリットは未だに挙がってない。
タスクシステムのメリットとやらを知ってる奴が、
こうだよ、これだよ、と示してくれたら十分だと思うんだが…。
それを言うことすら困難で大変でめんどくさくてしょうがないほどの、
ビミョーな言いにくい、不明瞭なメリットしかないのか？
いままでの挑戦者は全員「日本語でおｋ」って感じの奴等ばっかりだなｗ
>>216 ＞無限遠方の0地点との比較なら、どんなものでも存在しているだけで+になるから
”僕の脳内だけにあるすごい逐次処理”は完全な0。ってことは認めちゃったのね。
＞かならず存在しているものには全てなんらかのメリットはあるんだけど、
と
＞他の何かと比較してこそ有用なメリットが浮かび上がる。
って自分で言っていて矛盾してることに気づかないなかしら。
お仲間のタスク懐疑派にすら呆れて見捨てられるだけのことはある。救いの無いお馬鹿さんだね。
無限遠方の0地点は宇宙すら存在していないような、何も無い世界。
それに比べれば、タスクシステムにだってメリットは有る。
だけど、お前は、「"僕の脳内だけにあるすごい逐次処理”は完全な0」というが、
実際には、0ではないし、タスクシステムよりもメリットがある。
タスクシステムはアセンブリ時代に作られたもの。
俺の言う、「型や用途ごとにリストを分けて、制御構文で制御を記述」は、
アセンブリ時代より後に生まれた高級言語の機能を利用した方法だから、
前者より洗練されてる。より無限遠方の0地点より遠い。
もし、そこをお前が言うように0地点の基準とするならば、
タスクシステムはマイナスになってしまう。まさにメリットなし。
後半は、
メリット≠有用なメリット
いつもの意図的な読み飛ばし乙
＞実際には、0ではないし、タスクシステムよりもメリットがある。
それは今のところ何の証明もされてない坊やの脳内だけに存在する妄想だね。
>>199 ＞他の手段の実装で元と同じ仕様を完全に満たせること、さらに実装コスト、CPU消費リソース、メモリ消費量、
＞生産性、その他諸々がtaskやactorを使うより良い値になることを証明する必要がある。
続きは妄想じゃ無いと証明できてからだね。
>>220 ＞メリット≠有用なメリット
こんなおもろいもの見落としたわ。思わず吹き出しちゃったよｗｗｗｗ
何このギャグｗｗｗ
メリットと有用なメリットの違い、ぜひ詳しく解説してほしいなｗｗｗ
あー、やめろやめろ
結局、タスクシステムのメリットとかでてこないなら話続けなくていいから
次の挑戦者さんどうぞ↓
>>211 が呆れて見捨てるのもわかるよ
＞さすがにUnreal Engineまで否定したり単発IDでメリット絶対にあがらないとか連呼する馬鹿と同類にはなりたくない
負けが確定すると単発IDでメリット出せってワンパターンに逃げまわる負け犬。
たしかにこんな真性馬鹿と同類にされるなんて屈辱だよなｗｗｗ
挑戦者 ＝ タスクシステムの理解に挑戦している童貞（笑）↑
>>225は
>>223向けな。
余りにもしょーもない方向に行っていたから、
まさか相手にする人が出てくるとは思わんかった。
>>221 悪魔の照明をさせたいのだろうが、その手には乗らんよ。
お前はメリットも述べず、ディメリットを否定することもせず、
ひたすらあおって相手が「メリットが無い」と書き込むのを待っていただけだろ。
お前は自らが「メリットが無い」と言う言葉をひたすら繰り返すことで、相手に刷り込ませて、
発言させるのを待っていただけなんだな。今読み返して分かった。
>>222 無意味な比較に基づいてはじき出されたメリットに有用性は無いだろ。
何も無いよりはマシだ、とかね。本当に何も無いのならそうだが、
実際には高級言語を使えるのが当たり前なわけで。
それの機能を無いものとして、メリットを説いたところで通用しないだろ。
俺は初め、
「タスクシステムを使わずにベタで書いたほうがよい」って書いていただけなのに、
相手か繰り返し、「メリットが無い」って言葉を繰り返すものだから、
勝手に立場が出来上がって、そのまま「メリットが無い」って発言しちゃったんだよな。
仕組まれたな。
単に、タスクシステムでかくより、
高級言語で型ごとにリスト持って制御構文で制御する方が良い、
と言っておけばよかったのか。そうすれば悪魔の照明も必要ないな。
メリットって言葉は例の彼が一番使ってる訳で、初めはそんな話誰もしてなかったんだよな。
要は、相手にはディメリットがあって、こっちにはこういうメリットがあります、と言えば良いわけか。
つーか、まぁ普通そう考える罠。
そこを捻じ曲げてくる彼の手法には正直感服した。
二重否定を使って、言葉を刷り込むのな。こういうのはディベートとかで習うんかねぇ。
>>228 ＞「タスクシステムを使わずにベタで書いたほうがよい」って書いていただけなのに、
結局同じことを言ってるねぇ・・・
それは今のところ君の脳内だけの仮定で何も証明されてないから。
>>199 の証明よろしく。これは君の妄想でなければ実在するはずの二つの実装の有益性の比較だ。
現実に実行可能だし悪魔の証明とは構造が違うねぇ。
しかもこのスレには珍しく有益だ！ｗｗｗ
＞メリットって言葉は例の彼が一番使ってる訳で、初めはそんな話誰もしてなかったんだよな。
おやおや、「彼」ねぇ・・・・
ではその「メリット君」とやらはこのスレ公認の真性お馬鹿さんということにしておきますかｗｗｗ
悪魔の証明といえば
こっちは君が言った言葉の矛盾を追求していただけですがねぇ
その結果悪魔の証明になったのは君の最初の前提が間違ってるからなんだけどね
「タスクシステムを使わずにベタで書いたほうがよい」
この一文で君は自分から悪魔の証明にはまっているんだよねぇ・・・
この文のどこが間違ってるかわかるかな？
ヒントはこの文の「よい」が「好みだ」なら特に間違いにはならないということだ。
「よい」とするならこの文にはあるものが欠けている。
で、メリットって何？
>>230 >>199の証明をする必要は無いよ。
だって初めから高級言語の型と制御構造の機能を 殺す/殺さない について言及している訳だから。
>>101-102を読めば分かるけど、誰もCPUリソースやメモリリソースの話はしてない。
如何にシンプルに記述するか、初めから記述性を問題にしている。
それへの反論で、お前が突然勝手に変なこと言い出したんだから、
自らが
>>199に基づいてタスクシステムのメリットを証明したら？
メリットが「有る」と主張する者がそれを示すべきである。
>>233 つまり君の言う「タスクシステムを使わずにベタで書いたほうが”よい”」ってのは
メモリ使用量もCPU効率も生産性も悪いけど「シンプルに記述することができる」
ってだけの話なのね。シンプルに記述ってのも怪しいもんだが、まぁ
君の言う「よい」がそういう意味限定なら君の頭の中だけでは成立するかもねぇ・・・
普通のプログラマはそんな意味で「よい」とか使わんなぁ
>>235 「タスクシステム」がメモリ使用量やCPU効率や生産性を改善してくれると言いたげだな。
それなら「タスクシステム」を使わない場合のコードと使う場合のコードを挙げてそれを
示してくれよ。
手段のアドバンテージというのは絶対的なものではない。
目的・条件・状況に応じて、ある手段にアドバンテージが発生したり消滅したりする。
そしてもちろんアドバンテージは使用する人間のスキルや特性にも依存する。
「タスクシステムを使うメリットが無い」
→「ﾎﾞｸﾁﾝは、タスクシステムのアドバンテージを活かせる問題を経験したことが無い」
→「タスクシステムのアドバンテージを活かせるだけの十分なスキル・特性がﾎﾞｸﾁﾝにはない」
ｗｗｗ
「メリットを示せ」
→「ﾎﾞｸﾁﾝのスキル・特性・問題意識が劣っていることを証明しろ（ｶﾞｸﾌﾞﾙ」
ｗｗｗ
「記述性を問題に」
→「ﾎﾞｸﾁﾝにわかる記述で解決できる問題しか、問題と認めません」
ｗｗｗ
ﾜﾗカスなや。相変わらず不毛だな。手を動かせ。
「悪魔の証明」とか使っててカッコいいとか思ってんのかね。
相変わらず引き籠り臭がひどいな。
何が問題かは自分で決めろよ。
誰かが言っていたが、何が問題なのか人に聞いているようじゃダメだな。
>>234 実際そうなんだよね。無いことの証明の義務は無いからね。
でもそんなこといっちゃかわいそうでしょ。
相手さんは、有ることの証明すら出来ないか、
もしくは有っても小さすぎて言えない立場なんだから。
>>235 >メモリ使用量もCPU効率も生産性も悪いけど「シンプルに記述することができる」
「ベタ書きがメモリ使用量もCPU効率も生産性も悪い」は、俺は言って無い。
初耳だし、お前の意見だからお前が保証しろよ。俺は知らん。
おい、ID:MCs54x4G よ。
俺の相手ばっかしてないで、ID:MCs54x4G の相手してやれよ。
真性の相手するの好きなんだろ？
>>236 効率が良くなるか聞いたら「誰もCPUリソースやメモリリソースの話はしてない。」
って否定したから良くはならんのだろう、と思っただけだがぁ？
別にこちらはタスクシステムが何かよりも優れてるなんて一言も言ってない。
タスクシステムよりベタ書きが「よい」って言い張るやつがいたから
普通のプログラマとして効率なり何なりが良くなるというなら証明はあるのかね？
と聞いただけだ。
あと「シンプルに記述できる」と言い張るなら結局
>>199と同じように
シンプルに記述できることを示して見せないとねぇ・・・
まぁ普通に考えれば何の前提条件もつけずに「よい」とか「わるい」とか
断言しちゃうプログラマは思い込みの激しいお馬鹿さんとして遊ばれる運命なんだがｗｗｗ
今日もタスクシステムのメリットはあがらない！絶対だ！
だれかタスクシステムでなんかつくってうぷしろよ
インベーダゲームとか
それをたたき台にはなししようぜ
前に星がキラキラするサンプルを
タスクシステムと普通の書き方で比べたことがあったんだけど
タスク側はこの書き方は違うだのあーだこーだごちゃごちゃいうだけで何も進展しないで終わったよ
>>237 は今後独自フィルターを通して現実を見る事を宣言したようですｗ
>>243 うわぁ・・・まじかよ
ゲーム一本どころか星がキラキラするサンプル程度のものすら
タスクシステム使ったら実装できないって底辺ゲー専生徒以下のレベルの子だったのね・・・
前からタスク使うとバグだらけで作れない、とか何か得体のしれない黒魔術とか、
言ってることに違和感があったんだけどそーいうことか。
で、ifとswitchだけ使ってプログラム作れと粘着してたのね。
やっと納得できたがレベルが低すぎてまじで呆れた。
まぁ匿名掲示板だからどんなレベルの人が書き込んでもいいんだけどさ、
君のレベルならまず本屋のゲームプログラムコーナーにでも行って
適当にタスクシステム使ったサンプルのってる本を一冊、最初から最後まで
通してちゃんと勉強するのがいいと思うよ。こんなスレで粘着してる暇があるなら・・・
>>245 いや、ちゃんとレスを読めばわかると思うんけど
俺はアンチタスク派
今日もアンチは殻に閉じ込められたままで成長することはない！絶対だ！
>>247 それはむしろタスク派だろ
タスク以外の組み方した上でやってるのかと・・・
久しぶりに覗いてわろた。ざーっと読み通したんだが
この挑戦者くんは前スレのハード君だね
相変わらず成長がほとんどないので驚いている
まぁ元気そうで何よりだよ
しかしアンチはなんでタスクシステムに粘着するんだろうな。
「タスクシステムのこの有用性は、こういうやり方で代替できる」って代替案を示すわけでもない。
そもそも有用性が無いと思い込んでいるんだったら、そもそもスレに来なきゃいいのに。
そうすればわざわざスキル・センス・経験の無さを露呈することもないだろうに。
どんな得があるんだろうな。
まあ見ていて笑えるからどうでもいいけど。
いつまでたってもメリットを示せないのも笑えるよｗ
示せないけどあるんだよ！ ってのはｗ
組み込みでタスク使ってるけど便利じゃん
ゲームのタスクは不便なの？
>>251 > 「タスクシステムのこの有用性は、こういうやり方で代替できる」って代替案を示すわけでもない。
少なくとも
>>188 で一度は示されてるように見えるんだが
>>188とか意味わかんないな
俺は具体的な代替案っていったら
>>105だと思う
もっともスタンダードな方法であってなぜこれでダメなのか？
タスクシステムでなくてはならないのか？ってのはみんなに考えてほしいと思うな
＞タスクシステムでなくてはならないのか？ってのはみんなに考えてほしいと思うな
タスクシステムでないとならない、なんて誰一人言ってないけど、誰と戦ってるの？
アンチは「タスクシステムを使わずにベタで書いたほうがよい」って断言してるけどwww
A「XはYよりよい」
B「へぇ、で、その根拠は？」
A「え...（汗）、お、お前がYのメリットを出せよ！」
B「お前頭大丈夫？」
今こんな感じ。
>>257 いいんだよこのスレのテーマはタスクシステムなんだから
>>256 >>105書いた者だけど、レスありがと。
本来もっとも普通のかき方のはずなのに、ここではなぜかアウェーなんだよね。
例ではシンプルに型ごとに突っ込んでるが、
さらに細分化して用途ごとに分けても良いし、
OOPならインターフェースごとにコレクトしても良いし、
速度命の部分は配列でやってもよいし、
ツリーにしても良いし、foreachを並列化しても良いし、と、
コンテキストに合わせて自由にデータ構造とアルゴリズムを記述できる。。
制御にしたって、二重ループを当たり前に書けるから、相互作用だって簡単だし、
型が死んでなく、オーバーロードが効くから、
テンプレートでダックタイピングしても良いし。
>>257 またソースロンダリングか。
散々根拠は書き込まれてるだろ。
それを無視してお前がCPUのリソースやらメモリ効率やらの話を持ちかけたんだから、
まずはお前がタスクシステムでのそれらの優位性の根拠を挙げろよ。
>>258 タスクシステム板だからタスクシステムと言えば理論が破綻してようが
矛盾してようがなんでもOKという理屈ね。で、
>>203 になると
>>259 タスクシステムよりベタ書きが適しているケースなんていくらでもあるだろうけど
「タスクシステムよりベタ書きがよい」と宣言しちゃうと
タスクシステムを使った全てのケースでベタ書きが優れていることを証明しないと
間違ったこと主張してることになるからねぇ・・・
＞本来もっとも普通のかき方のはずなのに、ここではなぜかアウェーなんだよね。
君がここでアウェーな理由、まだ理解できてないみたいだね
君の言ってることは「僕は個人的にタスクシステムよりベタ書きが好き」ってだけ。
赤ん坊じゃないんだから「自分の好きなこと」≠「世界中でよいこと」ってのを理解
できるぐらいは成熟しようよ。
>つまり君の言う「タスクシステムを使わずにベタで書いたほうが”よい”」ってのは
>メモリ使用量もCPU効率も生産性も悪いけど「シンプルに記述することができる」
↑の君の書き込みはどうするつもり？
一言もCPU効率etcには言及してないのに、
お前が勝手に付け加えたんだから、お前の意見ってことで良いんだよな。
ベタ書きでそれらが劣ることを証明してよ。
CPU使用率etcはお前しか言及してない話だから、
お前が何とかしろ。
やれやれ・・・
普通プログラマにプログラム上の話でAの方法よりBの方法が良いって言ったら、何て聞かれると思う？
で、
>>240 追い詰められたから千日手で逃げきるつもりみたいだけど・・・
そんなこと繰り返してるから
>>211 みたいにお仲間にも見捨てられるんだよ。
追い詰められて千日手なのはお前の方だ。
最近口数が多いようだが、自分のことばかり述べてるな。
>普通プログラマにプログラム上の話でAの方法よりBの方法が良いって言ったら、何て聞かれると思う？
AよりBの方が記述性や可読性が良いと言えば、
発言に対する反論なり同意なりが返ってくるのが普通だと思うが。
言及していないCPU使用率ｅｔｃについて証明しろ、などと、
筋違いな話題を振ってくるのはお前だけだろう。
他人の発言には明確な証明を要求するが、
自分の発言には証明どころか根拠すら示さない。
これではね。
＞＞AよりBの方が記述性や可読性が良いと言えば、
＞＞発言に対する反論なり同意なりが返ってくるのが普通だと思うが。
で、その反論
>>240「で、その根拠は？」でアンチは逃げちゃったんだよねぇ・・・
可読性の証明。よろしく。
可読性を証明するにはまずタスクシステムである程度複雑なコードを別の方法でシンプルに書けることを示さないとね。
はじめからシンプルなコードだけ出してもそれがタスクシステムより優れているという比較として成立しないから。
＞＞自分の発言には証明どころか根拠すら示さない。
あのさぁ、どっちが優れてるとか主張してるのはそちら、こっちはそちらの主張の根拠を聞いてるだけで
「タスクシステムが何かより優れている」なんて主張してないんだな。主張してないものを証明しろって言われてもねぇｗｗｗ
まさに
>>257 AよりBの方が記述性や可読性が良い、理由はこれこれ。
↓
同様に、CPU使用率etcにおいても効率が良いことを証明しろ。
↓
CPU使用率etcについては言及していない。
その話題に持ち込むのなら、まず、Aの方がCPU使用率etcが良い根拠を述べろ。
↓
Aの方がCPU使用率etcの効率が良いとは言ってない。
↓
???
根拠は
>>101-102で示しているわけだが。
根拠を述べていない事にソースロンダリングするのは止めてくれる？
たしかに証明はしていないから、そこをつつけば良いのに。
可読性を証明しろ、ってのはかなりの無茶振りなわけだが、
それでも、可動性でタスクシステムと勝負する構図な訳だから、
その程度のハンデがないと成り立たないわな。
これからも何か書き込まれるたびに「それを証明しろ」と書き込み続けると良いよ。
キ○ガイなんだな、って知れ渡るだけだから。
>>269 ＞たしかに証明はしていないから、そこをつつけば良いのに。
つ
>>240 証明できないから逃げ回ってるんでしょ？
タスクシステムのメリットは今日も出てこない。
なぜ答えられないのだろうか？ そこにヒントがある気がする。
タスクシステムだと、動的関数呼び出しの数が増える。
もし減らすのなら、減らした分ベタに近づく。
タスクシステムだと、キャストが増える。
もし減らすのなら、減らした分ベタに近づく。
つまりタスクシステムとベタ書きを比べると、
少なくとも、、動的関数呼び出しの数とキャストの数は
タスクシステムの方が多いことになる。
かなりの無茶振りなのに、それなりな証明が出来てしまう事実。
あとは、可読性と動的関数呼び出しと型キャストの関連性をつつくしかないけど、
どうする？一応普通のプログラマ気取りのお前的には、
ここをつつくのは流石に難しいんじゃない？普通じゃなくなっちゃうよ。
>>270 証明が不可能なことなんてはじめからわかってるんだがねｗｗｗ
アンチにしろ信者にしろ、自分から穴にはまってるキ○ガイがいたら
穴を埋めてあわてるのを眺めて楽しみたい衝動にかられるってもんだ。
信仰が邪魔して穴から出てこれないから一方的に嬲れるしｗｗｗ
まぁ悪趣味なのは認めるがそれが2chだｗｗｗ
「タスクシステムを使わずにベタで書いたほうがよい」は無条件には成立しないのに
アンチにはその簡単なことが信仰のせいで見えないから穴から出てこれないんだよね。
ネタばらしかよ。つまんねーな。
>>273でエサ撒いてやったよ。さぁもう一仕事がんばれ。
さすが挑戦者。不可能とわかっていて挑戦するとはさすがだね！ではさっそく。
＞タスクシステムだと、動的関数呼び出しの数が増える。
＞タスクシステムだと、キャストが増える。
この二つはどこから沸いて出たのかな？君の脳内妄想？
証明よろー
減らせばそれだけベタに近づくから。
不可能な証明をこういった形で書けてるだけでも凄いことだよ。
数学的な証明とは言えなくとも、明確な根拠たりうる。
これでもまだ不十分だと言うなら、それは言い張ってるだけでは？
不十分な根拠が欲しいね。
どっちでも実装者が実装したいほうを選べば良いんじゃないですか？
タスクシステムにはタスクシステムのメリットがあるだろうし、ベタ書きにはベタ書きのメリットがあるだろうし。
だからさ、それぞれの実装方法をソースレベルで紹介して下さい。
タスクシステムっていう名前が可笑しくてしゃーない。
↑批判はいいから、少し黙ってろ、な？
＞タスクシステムにはタスクシステムのメリットがあるだろうし、
ないんだな、これが
↑じゃあベタ書きのメリットを上げてみてくれないか？
>>281 だいたいメリットが無いって言ってるやつに限って、ないことを証明して見せろって言っても、そんなの出来るわけないって言うんだろ？だったら少し黙っててくれないか？実装をソースレベルで紹介してもらって、それを自分で確認してみれば、それぞれの使いようも分かるだろ？
お互いに批判ばっかりしてても始まらんだろ？
ちったぁ冷静になれよ。どうせこんなカススレ見てるやつは俺も含めて、30代、40代の死人みたいな奴らなんだからさ、落ち着けや。
>>277 ＞減らせばそれだけベタに近づくから。
わーお、これが
＞タスクシステムだと、動的関数呼び出しの数が増える。
＞タスクシステムだと、キャストが増える。
の証明？減るって自体がそもそも君の脳内妄想でしょ。
聞かれてもいない脳内妄想垂れ流しはやめて
聞かれたことに答えてね。
ちなみにタスクシステムに対するベタ書きのメリットは可読性だけですって逃でた時点で
「タスクシステムを使わずにベタで書いたほうがよい」は成立しないことが確定しちゃったんだけどね。
まぁ逃げた先の可読性で追い詰められてる雑魚にはまだ先の話だけど。
>>188 ＞より汎用的で粒度の高い
「より」って部分をｋｗｓｋ
＞現代的な手法の選択的な組み合わせで置き換えられるから、
＞今さらタスクシステムなんて作る必要はないよね。
枯れている方が使いやすい。
>>259 ＞さらに細分化して用途ごとに分けても良いし、
＞OOPならインターフェースごとにコレクトしても良いし、
＞速度命の部分は配列でやってもよいし、
＞ツリーにしても良いし、foreachを並列化しても良いし、と、
＞コンテキストに合わせて自由にデータ構造とアルゴリズムを記述できる。
↑これらはタスクシステムでもできるよ。ツリーもプライオリティで可能。
むしろ抽象化されている分、タスクシステムの方が自由度が高い。
＞制御にしたって、二重ループを当たり前に書けるから、相互作用だって簡単だし、
↑これもタスクシステム関係ないが、二重ループは慎重に最小化したいもんだね。
＞型が死んでなく、オーバーロードが効くから、
＞テンプレートでダックタイピングしても良いし。
↑？？？。これ詳しく終えくれないか。
タスクシステムのメリットは今日も出てきません。
明日も明後日もきっと出てきません。なぜでしょうかｗ
void *にすることを「抽象化」って言うの、おじちゃん？
芸は身をタスク
>>289 そいつぁ型の放棄じゃよ。
同時に、あとでまた区別しなおす必要を負う使いにくい何かじゃよ。
292 ：
名前は開発中のものです。：2011/09/19(月) 14:40:40.15 ID:N3rIS0ol
>>273 なんのための抽象化だよ。
タスクつかってもキャストなんほとんどしねえから。
今本屋で手にはいるタスクシステム使ったサンプル本って
みんなC++で仮想関数使ったりJAVAで実装されたりしてるから、
voidとかキャスト使ってるタスクシステムの例って見たこと無いな・・・
C++とかJAVAとかが無い時代はそうだったのかな？
この人ずいぶん古い時代の知識しか無いんだね・・・
わるいけど、具体的に書名挙げてくれないかな？
ていうか、具体的な書名なしに「本に載ってる」って言っても、
一切信じないから。
voidにキャストって、cでの実装方法？
>>294 ＞一切信じないから。
ほぉ、このアンチはvoidやキャストをしないタスクシステムがこの世に存在することを
一切信じていないのか。
タスクシステムのメリットが無いとかベタ書きの方が良い、と粘着してたのは
タスクシステムには必ずvoidやキャストがあるから、という前提なのね。
ではぜひ
>>293 には具体的な書名を上げてもらわないとな。
voidやキャストを使わないタスクシステムの載った具体的な書名が一冊でも上がった時点で
このアンチの考え全てが間違った前提に立った愚かな思い込みだった、と証明されるわけだからｗｗｗ
>>296 関係ない話してない？
タスクシステムのメリット以外の話しないでくんない？
他の人も悪いけど
>>297 ギャラリーに詰まれてること指摘されて黙ってろって噛み付くなんて
小物っぽくて最高にかっこ良いね！。あんたビビリ過ぎｗｗｗ
「一切信じないから。」なんて痛いセリフはいた後に具体的な例が出ちゃったら
俺だったら恥ずかしくて生きていけないｗｗｗ
とどめの一手楽しみだなーｗｗｗ
>>296 お前どっちの見方だよww
たとえC++でも、
ITaskなんつーインターフェース作って、
毎フレームupdate仮想関数が呼ばれる～～とかしちゃってさ。
他タスクとのコミュニケートはどうするんだよって話だよな。
updateメソッドの引数は固定、なおかつ、
タスクシステムの握ってるタスクはタスク型にキャスト済み。
コンストラクタで貰ってメンバ変数で握っとく方法も、
ゲームみたいに相互作用の相手がころころ変わる状況では無理がある。
書名マダー？
303 ：
名前は開発中のものです。：2011/09/20(火) 22:59:43.53 ID:FpVb+7di
>>301 ほかのタスクとのメッセージはテキストで送るか、専用の黒板を用意するといいよ。
305 ：
名前は開発中のものです。：2011/09/21(水) 11:16:06.93 ID:UwsdqtFd
>>293がいつまでたっても書名を出さないから近所の家電屋行ったついでに立ち読みしてきてやったぞ。
「弾幕」ってのに「タスクシステム」の説明とそれ使った実例が、
「iOSで作るシューティングゲーム」「そのまま使える iphoneゲームプログラム」ってのには
actorだったけど、やってることはactor基底クラス連結してupdate仮想関数回してるという
まぁ逐次とかif/switchだけどはほど遠い方法のが載ってた。
JAVAのやつは見つかんなかったけどJAVAでゲームっていうとAndroid系かねぇ？
で、みんな言語の機能にある継承やら仮想関数やら使ってvoidやキャストとやらとは当然無縁。
>>294 ＞一切信じないから。
で？「一切信じない」はずのものは何だっけ？
>>306 せっかく読んだのなら、それらの構造のメリットがどう説明されてたのか報告してくれたらよかったのに。
「タスクシステムを使ったサンプル本」は「みんな」なんだろw
しかしこのアンチ、
>>301 ＞タスクシステムの握ってるタスクはタスク型にキャスト済み。
継承クラスから基底クラスへキャストが必要だと思ってたり
void*とか何とか、C++まともに使えるならとても出てこないセリフ連発するあたり
こいつの言ってる「言語の機能を使って」云々ってifとかswitchとか全てC言語の機能限定だし、
あきらかにC++とか新しい言語の機能は理解できていないプログラマの発言だよね。
>>293 ＞この人ずいぶん古い時代の知識しか無いんだね・・・
ってのが図星で
「（そんな僕の知らない言語機能があるなんて）一切信じないから。」
って意味なら過去の発言全て説明がつくな。
で、現代のJavaやC++で継承を使ってupdateに全部詰め込む利点は？
311 ：
名前は開発中のものです。：2011/09/22(木) 21:26:48.80 ID:CkJX0+Oi
君は小さな差異しかないキャラクターを抽象的に扱メリットはないともうすかね？
>>309 タスクシステムの握っているタスクが、タスク型にキャスト済みだから、
その後どうあがいても元の型に戻すにはダウンキャストが必要。
それから、void*云々は俺の書き込みじゃない。
>>311 その、「小さな差異しかないキャラクター」だけに、共通部を抽出した基底クラスを用意したら？
ITaskとかしちゃうと、抽象度が高過ぎて旨みないぞ。
仮にJavaで言うObjectクラスのようなことがしたいのだとしても、
そんな最基底部にフレーム毎updateメソッドは要らないだろ。
大雑把すぎ。
タスク戦士は相変わらず思いつき仕様ばかりたれるな
んでまったく意味ないのｗ
お前等のやってることもやってきたことも所詮こんな程度
モノなんて作れないだろｗ
314 ：
名前は開発中のものです。：2011/09/22(木) 23:11:44.85 ID:CkJX0+Oi
まあ正直ライフタイム、生成、廃棄、の管理をTaskと呼ばれるものに内包するか、
簡素化して外側に出すかの差でしかないとおもうんだがどうなのよ？
>>314 単純すぎ、単純な物しか作ってないだろｗ
>>312 ＞タスクシステムの握っているタスクが、タスク型にキャスト済みだから、
ダメだこいつ、やっぱりC++の基本も継承の意味も全然わかって無いじゃん・・・
その低レベルの脳内妄想を完全否定する具体的な書名が出てるんだから
まずそれを読んで脳内妄想垂れ流すのをやめてみたら？
つーかお前タスク以前にOOP理解できてないから本の内容は理解できないのか。
入門C++みたいな本が先かもね。ｗｗｗ
＞それから、void*云々は俺の書き込みじゃない。
void*とか低脳なこと言う馬鹿とは一緒にするなってか？おやおや、馬鹿と馬鹿の切り捨てあいかよ。
数少ないアンチ同士、仲良くすればいいのに。同レベルなんだから。ｗｗｗ
メリット云々に関しては
>>257 の状況は変わらず。
そもそもアンチの主張の証明に関してタスクのメリット云々は無関係だし
何にせよ主張に関して証明責任があるのは主張をしてる側だけ。
まぁそれでも「メリット出せ」しか繰り返せない理由は明白だがｗｗｗ
人格否定するメリットないから
技術論ぶつけ合ってよ
だれかタスクシステムでなんかつくってうぷしろよ
インベーダゲームとか
それをたたき台にはなししようぜ
いいだしっぺの法則が発動しました
タスクシステムなんかで作りたくない。
>>317 で、タスクシステムのメリットは？ｗ
> 何にせよ主張に関して証明責任があるのは主張をしてる側だけ。
メリットが有ると主張はできないと？ｗ
タスクシステムがどんなもんかしらんし
有用性を説いているやつにつくってもらいたいな
たしかにリンク先に長所箇条書きされてるしなぁ・・・
> では、日本のゲーム業界で古くから用いられている、タスクと呼ばれるテクニックを紹介します。
> タスクの歴史は古く、NAMCOがギャラクシアンを作るときに考案されたとの説が有力ですが、
> 定かではありません。この業界では、同業他社への転職はあたりまえです。タスクも、それを
> 知るプログラマーと共に、各社へ伝わっています。但し、スタンダードと呼べる程には広まって
> いません。至って原始的なものですが、現在でも実用的だと言えます。
どう見ても信仰ありきです本当にありがとうございました
何がどう「従って」「現在でも実用的」なのか。むちゃくちゃな文章だな。
現在でも実用的な根拠がないよね
「現在でも実用的だと言えます」の根拠も無いか、
あるいはボンヤリしすぎてるｗ どこでもいっしょか？ｗ
タスクシステムのメリットあげるのはそんなに大変か？ｗ
331 ：
330：2011/09/25(日) 11:22:58.12 ID:ua4wI3HO
いかん、リロードしてなかった(´･ω･`)ｽﾏｿ
「従って」
もしかして ： 「至って」
「アクションゲームアルゴリズムマニアックス」ってのにもタスクシステムの紹介とそれ使ったゲームが。
「ゲームコーディング・コンプリート 」は洋書らしくactorという名前だったけど
「actorはゲームで状態が変わるオブジェクトの総称でレースゲームの車もアドベンチャーのロウソクも全てactorである」とか、
このスレのタスクアンチが見たら泡吹いて発作起こしそうなこと書いてあったな・・・
この本の作者はMSやEAで最新ゲームのリードプログラムを長年やっていて、その経験から出た言葉らしいけど
２chのこのスレに粘着してるような脳内スーパーゲームクリエイターと完全に違うこと言ってる理由は・・・やっぱりアレだよなぁ・・・
うん、でもまったくメリットの説明が書いてないねｗ
すごいゲームをあげてメリットの説明になるなら逆にとんでもなくダメなゲームを上げたら
デメリットの説明になるのかな？
本にもリンク先にも長所・メリットが明記されてるけど、
それをあえて見なかったことにしないと話ができないのはその存在を認めちゃうと
否定できないのが君の頭でもわかるから。かわいそうに。
お仲間にも呆れられて見捨てたられた単発ID君にはもうそれしか手が無いのだろうね・・・
そんなに自己紹介されても困る。お前そのものじゃねーか。
タスクアンチじゃなくて、タスクシステム懐疑派じゃねーのせいぜいｗ
マジでメリット出てくるのかどうか怪しいもんだ。釣りかもしれんぞこれ。
メリットは無いという前提を隠してのらりくらりと釣られてるのかもしれんぞ。
今日もタスクシステムのメリットは出ない
絶対だ
今日もっていうか今週もだな
来月も挙がらないと思うけど
いろんなプログラム本に載ってるぐらいだから、ゲーム作る参考として十分役立つんでない？
>>335 リンク先の長所ってのはこれのことかな
>長所は次の通りです。
>・ジャンルを問わず様々なゲームに適用できる
>・並列処理をうまい具合に実現できる
>・ゲームの流れを自然な形で表現できる
>・大規模なゲームも開発できる
>・タスクごとに独立しているため、複数人で開発できる
確かに誰もこれ否定できてないね。
void*とかキャストとか可読性とかは結局何の証明もできなかったし。
少なくともタスクシステムは色々なゲームで使われて実績があるし、
実際のコードが載った書籍もいろいろ存在して参考資料として価値があるけど
否定してる人たちの言うことはみんな現実味の無い想像上の反発だけで
タスクシステムのような具体的で有益な資料が何も出てこないよね。
タスクシステムもActorも普通にゲーム作る手段の一つとして使えばいいだけだと思うけど、
粘着して荒らして何がしたいんだろう？
食い付きやすい撒餌来たぞｗ
さすがにこれは否定できなきゃプログラマ失格といえる
項目が混じってるから頑張れよアンチ共
「べた書き」というちょっと野暮ったいが誠実な言葉。
「タスクシステム」というちょっとオサレっぽい空虚な言葉。
ふとした印象だから突っ込むなよ。
「タスクシステム」なんて言葉は使わないのが正解
「タスクシステム」という単語ありきの話には首を突っ込まないのが正解
「タスクシステム」みたいな用語をいまだに使ってるサイトや書籍は無くなるのが正解
で？なんで現在でも実用的なの？
>>306 みたいにiphoneやipad向けプログラム本にも載ってるんだし、
最新モバイル向けゲーム製作でも使えるって現在とても実用的かと思うけど
現在では実用的ではないと思う根拠は何？
>>346
>>340 参考にしてゲームを作るのはいっこうにかまわないが、何が必要なのかわかってないのに
とりあえずタスクシステムを作り始めたり、無節操にいろんな機能を詰め込んだモジュールに
「タスクシステム」と名付けて何か説明した気になったり、モジュール分割の可能性や
標準ライブラリ適用の可能性を軽視したり、「タスクシステム」という言葉の周辺で多く見てきた
そういう間違いはもう次の世代には繰り返してほしくない。
>>348 抽象的で曖昧モコたる見解だな。全く参考にならん。
アンチの存在理由を正当化するためにも、もう少し整理してくれないか。
「もう次の世代には繰り返してほしくない」てのが本意なら、本望じゃないか？
>>337 ＞タスクアンチじゃなくて、タスクシステム懐疑派じゃねーのせいぜいｗ
なるほど、つまり「タスクシステムを使わずにベタで書いたほうがよい」
みたいな低脳アンチはもう完全撃破されて駆逐されたから残ってるのは
「タスクシステムなんて嫌い、あ、今のただの僕の印象だから虐めないで、お願い（泣）」
みたいな情けない懐疑派しか残ってないということねｗｗｗ
>>340 「もうやめて！アンチのライフはゼロよ！」ｗｗｗ
あーあ、みんな
>>257 なのがわかってるから空気読んであえてメリット出さないでおいたのに・・・
真性馬鹿が書き込みできる唯一の希望を潰すなんて、残酷だねぇｗｗｗ
＞タスクシステムもActorも普通にゲーム作る手段の一つとして使えばいいだけだと思うけど、
そのとおり、まっとうなプログラマならどんな仕組みにしろ道具に囚われてアンチになったりしない。
道具の一つとして使えるときに使うだけ。
何にせよアンチになったり信者になったりするのはプログラマとして劣った人間の証拠。
しかもタスクシステムなんてプリミティブな道具のアンチになるってどれだけ劣等種なんだかなｗｗｗ
>>348 お前が言ってるのはみんなアーキテクトが出来ないヘボプログラマが自爆したって話しで基本的に
タスクシステム関係ないじゃん。適材適所を考えなければどんな道具でも怪我するっての。
それで恨みもってアンチになるなんて完全な逆恨みじゃん。
結局「僕がプログラムで酷い目にあったのは僕がヘボだからじゃない！タスクシステムのせいだ！」
って信じたいだけでしょ。残念ながらその妄想は潰されちゃったみたいだけどｗｗｗ
＞そういう間違いはもう次の世代には繰り返してほしくない。
お前が下らない逆恨みで粘着アンチしてるよりは、参考のコードや動作説明を本やネットに残して技術伝えてる
タスクシステムの方が何倍も次の世代のためになるっての。
アンチ共があまりにも不甲斐ないから食べやすい餌が投入されてるな
もはや絶滅危惧種とも言われる典型的なアマチュア・タスク信者ID:Ug+FvKVP。養殖モノかもな
アンチに狩りを教えるために半殺しの獲物を与える飼育係の人でもいるのかもしれないな
おや？ID:Ug+FvKVPの書き込みはアンチにとどめさしちゃったみたいだね。
ほら、
>>351が
「僕は半身不随になるまでフルボッコにされてもう怖くて二度と逆らえません！
だれか！僕の仇を討って下さい！たすけて！」って弱音はいて泣いてるぞｗｗｗ
だれかこの腰抜けの仇を討つアンチは残ってないのか？早く出て来いよｗｗｗ
>>352 codezineの記事を庇って戦うか・・・随分なマゾプレイをするんだな
>>347 それっておかしくない？
じゃあ、ダメなゲーム挙げて実用的でないよって言ったら実用的でなくなるのかと
構造的には明らかに意味ねーんだよ
こいつを導入したところで解決する問題はなにもない
むしろ逆に問題が増える
>>105でいいーんだよ
ていうかむしろ
>>105で書かないとゲームオブジェクト同士の関連処理を書くときにやたらと複雑になる
一番多い処理はオブジェクト同士の関連だってのに
可能性として、N個オブジェクトがあればN*Nの関係があるわけだからな。
>>356 可能性を考えるとn*nじゃすまない
２つとは限らないじゃん
たいへんだアンチ諸君！君たちが出来なかったnxnの関係があるオブジェクト同士の関連処理を
問題なくシンプルに解決してゲームをバグなく完全に最後まで完成させた実例がたくさんあるよ！ｗｗｗ
つ
>>306 >>333 実在する完成された実例があるのに対して脳内妄想だけじゃ反論にすらならん。
>>354 おかしいのは君の頭。君の理屈で言えば
「箸ではスープが飲めないから実用的でない。スプーンでは肉が刺せないから実用的でない。」
ってのが成立するけど。これは間違い。
で、みんなに「みんな素手で食事しろ！」とわめいている君を周りの人は狂人だと思ってる、と。
まさにこのスレのアンチのことだなｗｗｗ
> n*n
ん？ネタか？
>>356,
>>358 それとも高校数学も落第点だったゲー専あがりかFラン四大出か
>>357 おまえはN体の押し競饅頭もできなさそうだな。論外。
普通に関数の引数が3つ以上になることは多々あるね。
foreach( 弾リスト ){ func( システム, 弾, 自機, );
とかな。
ベタ書きの「引数自由」の利点だね。
> ＞タスクシステムの握っているタスクが、タスク型にキャスト済みだから、
> ダメだこいつ、やっぱりC++の基本も継承の意味も全然わかって無いじゃん・・・
> つーかお前タスク以前にOOP理解できてないから本の内容は理解できないのか。
で、この始末はどうするの？
「タスクシステムの握っているタスクが、タスク型にキャスト済みだから」
これの何処が間違ってるの？
ID:wQFOp1sgが沈黙したところを見ると、初歩的な間違いを認識する程度には
知能があるアマチュア・タスク信者という設定らしい。そういう設定のキャラを演じてる
ということで話をあわせてやるから元気出せよな
>>348 ＞参考にしてゲームを作るのはいっこうにかまわないが、何が必要なのかわかってないのに
＞とりあえずタスクシステムを作り始めたり、無節操にいろんな機能を詰め込んだモジュールに
＞「タスクシステム」と名付けて何か説明した気になったり、モジュール分割の可能性や
＞標準ライブラリ適用の可能性を軽視したり、「タスクシステム」という言葉の周辺で多く見てきた
何が必要なのかわかってないのに作り始めたり、無節操にいろんな機能を詰め込んだり
モジュール分割の可能性や標準ライブラリ適用の可能性を軽視したりって
そんな作り方してたらどんな方法でもどつぼにはまるだろ・・・
タスクシステムとは根本的に無関係なそのプログラマが低レベルってだけの話だ。
まぁポインタ使えないヘボプログラマがメモリ破壊したりOOP理解できないヘボプログラマが
何でも一個のクラスにしたりってケースでは「やつにはポインタやクラスは使わせるな！」と
言いたくなることは理解できるが、それはその「ヘボプログラマが使えない」のであって
「ポインタやクラスが使えない」ってアンチの結論は明らかに頭のネジが外れてるだろ。
だいたいポインタだろうがクラスだろうがタスクシステムだろうが、
その程度の低レベルなことは問題なく使いこなせてあたりまえ。
そのレベルに達しない奴がゲーム製作の現場にプログラマとして入ることが間違ってる。
そーいうダメプログラマはちゃんと教育し直すか、それでもダメならスクリプタやデバッガに
配置転換させるのが普通。
低レベルプログラマにあわせてポインタやクラスやタスクシステムを使わない、なんてしてる
開発現場見たことねーよ。
>>363 いきなり話し飛ぶならアンカーぐらいつけんとわけわからんぞ？
>>365 「「タスクシステム」と名付けて何か説明した気になる」のだけはヘボプログラマ認定しないんだｗ
ごちゃごちゃ言ってるけど、何の意味も無い書き込みだよ。
端的に、タスクシステムの、物事のタスクへの抽象化は、度を越えたアップキャストなんだよ。
普通は、可能な限りダウンキャストの必要ない程度の抽象度に留めるものなんだ。
避けることの出来ないOO設計の要なんよ。
ITaskなんてのは、情報量が希薄過ぎて、抽象化の仕事しないのよ。
設計も仕事してないのよ、名前に反して。
ただ、メインループがサードパーティー製で、改変不可な場合は別ね。
複数のインターフェースを実装できるんだから好きにすればいいじゃんw
まあ頑張ってw
結局
>>340で終わった話だな。
アンチの具体性皆無でワンパターンな脳内妄想も飽きた
373 ：
372：2011/09/29(木) 00:07:43.71 ID:YTRn9+LX
>>371 すいません。アンカーを間違えてしまいました。
372 は 371 宛てです。
>>367 難しく考えすぎじゃないか？
だいたい一目商用ゲームの動き見りゃ、キャラや当たり判定の実装なんて想像がつく。
当たり判定にしたって、精々、円・矩形・点・球か、たまに直方体・線くらいだろ。
なんでこの程度のモンがタスクシステム化できねーんだよ。
しかし一方で、抽象化に頼りすぎるのもマンネリ化の温床になるのかもな。
商売だと、タスクシステム抽象化をうまく使って、タイトルの量産体制敷かないと採算取れないんだろうな。
>>374 新しい概念「タスクシステム化」が現れた！
ぜひ何のことか説明して欲しい。
>>375 おめでとう！、そりゃ大変だな！
ﾂﾏﾝﾈ
>>376 どういうことなの・・・
まあ、勢いで反論してみたくなったんだろうなあ、ってことで、いいんですけどね。
>>377 文章難しかったかね。気の毒だが、まあ気にスンナ（クスクス）。
豆腐メンタルのアマチュア・タスク信者もまた元気出てきたようだな
「タスクシステム抽象化」
うむ。いいかんじにぶっとんできたな。このスレはこうでなきゃ。
>>367 薬でもキメてるのか？って文だな。
しかも要約すると「僕タスクシステム嫌い」の一文に収まる意味しか無い。
そして嫌いの根拠は完全に思い込みだけの妄想。君の趣向を表明されても何の意味も無いよ・・・
＞ごちゃごちゃ言ってるけど、何の意味も無い書き込みだよ。
まさにその通りの文章なんだけど
「今から書くことは何の意味も無いよ」って宣言してから書く理由はラリってるから？
ワロタ
まぁしかしcodezineの記事自体がもう色々あれなので
これを砦として防衛戦を展開、死守するってのはやはり苦しそうね
>>367はcodezineの記事のタスクシステムを叩いてると解釈できるし
>>382はcodezineのタスクシステムだけがタスクシステムだと思うなよ
と反論してるように解釈できる。
>>382は事実上codezine防衛ラインを
放棄してしまって、煙幕を展開して予備陣地（俺のタスクシステム）まで
後退しているんじゃないかなぁ
codezineはどうでもよくね？
物事を単純化するために抽象化するのは良く行われる行為だけど、
タスクって観点で抽象化するのは筋が悪いよね、ってだけで。
高級言語が無かった昔ならいざ知らず。
抽象度が高過ぎて情報量が希薄なんだよ。
全てのオブジェクトに共通の基底クラスを用意して、
自動コレクト→デバッグ云々は結構なんだけど、
そこにフレーム毎更新用updateメソッドまで付けるのはやり過ぎ。
そんな制御の根本を最基底部に作っちゃってどうするの？
なんでもかんでも同一視するのは、
名前に反して全然システマティックじゃないね。
タスクシステムで俺定義出し始めたら終り
だってお前の俺タスクなんて誰もみたことねーもん
>>306 >>333 が存在するのに「俺のタスクシステム」なんて
見えない敵をいきなり創造するのはいくらなんでも苦しすぎないかい？ｗｗｗ
そもそもアンチはcodezineのタスクシステムについてすら根拠の無い
妄想垂れ流すだけで何一つ反証できてないからなおさら無理があるねぇ
>>386 ＞そんな制御の根本を最基底部に作っちゃってどうするの？
その理屈だとタスクシステムだけでなく
Unreal Engineのactor、UnityのGame Object、Flashのムービークリップ・・・等々も
全てアウトだけど、これら全て実績があり普及もしてるという矛盾は君の頭の中では
どう解釈されてるんだい？
>>389 客寄せパンダでしょ。
JavaもGenericsを用意したわけで。
ところで、
>>363の件はどうなった？
Javaは、後になって、わざわざ、恥を忍んで、Genericsを、用意した。
これが今の流れ。メインストリーム。
ゲームエンジンの中でも一番下らん機能を挙げて実績どうのこうの言ってる暇があったら、
もっと世間に目を向けた方が良さそうだね。
やはりタスクシステムを構築して、量産体制で市場のパイを侵食。
他の俗世間はどうでも良い。
タスクシステムを軸に、全ての事象が俯瞰できる。
これが今の流れ。メインストリーム。
乗り遅れちゃだめだ！
>>390 ＞客寄せパンダでしょ。
わぉ、何というか・・・ここまでくるともう言葉出ないや
アンチ君の脳内では
「taskもactorもGame Objectもmovieclipも客寄せパンダで実際は使われずにみんなifとswitchだけで作ってるにちがいない！」
となってちゃってるのね・・・
>>363は仮想関数があるのに何でアッパーキャスト云々、あったんだけど
ここまで頭のレベルが違いすぎると言葉が通じる気がしないわ・・・
まぁ・・・いろいろがんばってくれや。
かみ合ってない事実を有効利用した者勝ちという無常ｗｗｗ
>>389 それ自体にはなんの意味もないじゃん
ただ、あるってだけで
発想が逆なんだよ
なんでそのもの自体に対しての評価を下せないの？
全体主義的な発想やめろよ
この業界、セミナー詐欺のおかげでオブジェクト指向なんて役に立つかどうか怪しい技術が
蔓延しちまってるんだから結果からメリットを探す行為をやめろ
普及してる＝役に立つでは決してない
OOPが分かってない子が一生懸命頑張っても無駄ってことが良く分かった
引数君だから仕方ない
>>396 ooが分かる？は？
あんな詐欺に引っ掛かってるからタスクシステムなんか信仰しちゃうんだろバーカ
アンチの問題解決意思不在の主張にとことん付き合うとか、よほど暇なのかね。俺はとうの昔に飽きたよ。
それはともかくOOP疑うとか、まいったまいったｗ
>>386 ＞そこにフレーム毎更新用updateメソッドまで付けるのはやり過ぎ。
＞そんな制御の根本を最基底部に作っちゃってどうするの？
＞なんでもかんでも同一視するのは、
＞名前に反して全然システマティックじゃないね。
主張らしきものは書かれているが、一字一句、適切な表現かどうか根拠が怪しい。
論理展開もなっていない。全く意味が無い。
>>395 SSをアップして、タスクシステムやOOPが不要であるという主張を実証してもらえないか？
>>395の成果品や結果としての表現能力にむしろ関心がある。
今度はオブジェクト指向に抱き合わせる戦略ですかw
>>400 タスクシステムのメリットも出てないのにね(笑)
オブジェクト指向もタスクシステムも共通点が多すぎる
セミナー用のクソ技術だけあって実態をつかませないところは見事だな
10年前ならともかく今OOPに全く理解がないというのはヤバい
ただし、定年間近のハード屋さんなら許すッ！
オブジェクト指向やタスクシステムで理詰めで工数を減らしてみろ
絶対できない
それはこの仕組み自体がなんにもやらないから(笑)
仕様が減るわけじゃない
教養の無さがヤバいw
アンチ君＝引数君＝OOPわからない子、なのね・・・
タスクシステムのメリットわからないのは、抽象化がわからない、
OOPもわからない、というのが根本、と。
なんかもうタスクシステム以前の話になってきてるし、アンチ君のいるべき
スレはここじゃなくてプログラマー板のOOP関連のスレじゃないかな。
そこで「君たちはセミナー詐欺に騙されてる！目をさましてOOP以前にもどるんだ！」
って啓蒙活動するのがいいかと思うよ。
OOP関連のスレならタスクシステムみたいにニッチじゃないからそれなりに人もいるだろうし
もしかしたら同じ症状の子がいて友達になれるかもしれないよ？
そうすればこんな過疎板でID変えながら必死に一人で戦う必要も無いんじゃないかな。
>>405-406 どうした？
ちゃんと理詰めで反論してみろよ
何が抽象化だバーカ
抽象化でモノ作れるのか？
ちゃんと脳みそついてるなら使って考えろよ
いい加減騙されてることに気がつけよ！
＞抽象化でモノ作れるのか？
>>306 >>333 OOPやタスクシステムと違いお前にはモノを作ることも理詰めで反論することもできない。
おまえは逃げ回ってお前の頭の中にしか存在しない妄想を吐いてるだけだ。
>>408 まあ、メリットが出るなら俺も反論できるけどね
物事ってのはまずメリットを主張してそれに対してそうじゃないって反論ができるけど
なんもかんもないんじゃ何もいいようがないよね？
オブジェクト指向の抽象化だっけ？
抽象化がどうしてメリットになるのかつきつめて考えるとなにもなくなるぜｗ
ちょっと深く考えてみなよ
少しでいいんだ自分に説明できることちょっとでもいいから出してみなよ（なにもないからｗ）
タスクシステムにしてもそうだよね
クラス開けてみると大抵なんにもしてない
動作だけみるとvoid*となんも変わらない糞クラスでしょ？
オブジェクト指向もタスクシステムもそういうセミナー詐欺の道具なの
おｋ？
時間かけて勉強したのは残念だろうけど本当になにもなにもないからｗ
>>340 まだ逃げるか？
codezineのメリットからも反論できず逃げ出したクズが
>>410 それ俺へのレスでいいの？
少なくとも
>>340に書いてあるのはメリットでもなんでもねぇよ
だって根拠がねぇじゃんｗ
タスクシステムはこういう性質をもっているから→
>>340なんでしょ？
んじゃ、タスクシステムってどういう性質もってるの？
って部分がないまま「ハイ、これがメリットです」なんていえないよね？
んでこういう性質をもってるって部分はタスク派にとっては
俺タスクで説明を逃げたい部分なんだよ
組ようによってどうにでもなるから話が危うくなってきたら抽象レベルを上げたり下げたりして
できること調節して話をはぐらかしてるだけ
技術者なら正面から向き合えよ
そういうセミナー技術に騙されちゃダメだ
タスクシステムなんてなーーーーーーーーーーーーーんも中身のない糞システムなんだよ
ほら、かかってこいよ！
いつまでまたせるの？
オブジェクト指向もタスクシステムもそういうセミナー詐欺の道具
その技術で動く実装が存在し技術的にも商業的にも成果を出していると言われるが
そんなものは生まれてから一度も見たことが無いし理解も出来ないので信じる根拠が無い、と。
アンチ君にとってはそーいう感じね。
で、世間のプログラマがみんなそろってOOPに騙されてるけど頭のいい僕だけは騙されないぞ、と。
君に必要なのは根拠じゃなくて教育だ。
でもここに君レベルの人間を一から育て直すような博愛精神と暇をもてあました人はいないよ。
やはり君はまずプログラマ板のOOPスレに行くべき。そこならサリバン先生みたいな博愛精神あふれる人もいるかもしれない。
この板は君には場違い。いろんな意味で。
>>413 お前はタスクシステムのメリット探してこいよｗ
お前は目の前にメリット出されてるのに認識できないだけ。理解できるだけの基礎が無いから。
残念ながら能力の無い人間に一から基礎を教育してやるほど博愛精神は無いんでね。OOP板に行け。
ID:MAW55fGGがやっぱり最後は
>>3の論調にもっていく件についてｗ
staticおじさん VS システム厨の対決が見られると聞いて
>>3 ってOOPのこと言ってたのかｗｗｗ
>>413 見た後に
>>3 見ると完全にギャグだな
しかし今までのスレで単発IDだったのに指摘されたとたんID固定しだして露骨すぎｗｗｗ
さすがにこんな過疎板にOOPやクラスまで理解できない真性馬鹿が二匹もいるわきゃないから
アンチって結局一人だったんだなｗｗｗ
>>419 アンチって タスクシステムアンチのこと？
それなら相当たくさんいると思うけど、俺ROMが多いから。
>>420 おやおや、OOPアンチ君は君の同類かい？
あえて指摘するのもどうかと思ったが
>>368みたいなレベルの人は、
とりあえずここから去ったほうがいい。こんなクソスレでもお前にはまだ早い。
まあタスクシステムとかOOPの特徴を今更聞いて来るとか
低脳過ぎる奴は邪魔だよな
自己申告乙
OOPもいざ説明しろとなると難しいな。
借りてきた言葉を朗読するに留まる。
OOPで実現しようとするモジュール性は、
非OOPでも部分的に満たせてしまうから。
OOPは、プログラミングその物のデザインパターン見たいな物だから、
経験の積みによる実感が分かりやすい。
やっと足し算がわかるようになった子供に
「因数分解ってのがあるらしいけど足し算があればそんなのいらないよ、みんな騙されてるだけ」
って言われた感じだな。
これをこの子供に一言で理解させられる人なんて当然皆無だけど。当然因数分解が不要ということでは無い。
基礎をすっ飛ばして一言の説明で理解させられたら数年間の学校教育や教師なんて必要ないしね。
世の中には基礎や能力が無い人間には説明できないことの方が多いよ。
説明＝教育になるケースは特に。
で、理解できる基礎が無い人間には比喩で言うぐらいしか無いわけだけど、それだと
「誰も僕にわかるように一言で説明できない！やっぱり因数分解やOOPは裸の王様だ！」
とお馬鹿な子供に泣きながら粘着されてる感じかな。
ものの捉え方を学ぶというのは適性が必要だよな
ダメな人は一生分からないかも
どうわめいたところでタスクシステムの利点の説明には全くならないけどな
>>431 タスクという単位を追加したり削除したりできるということじゃないの？最大の利点は。
アセンブラ時代にそんな仕組み（というほどのもんでもないが）があったら便利じゃね？
アセンブラ時代はストレートに書いたらモジュール化がめんどくさかったのよ。
いい方が悪いな。いわゆる、システムで規定（規制）すると、見通しが良くなるといった方がいいか。
いまは、OOPのほうが見通しが良くなる。
追記、アセンブラは、ほんとに何でもあり、何でもできる、gotoどころじゃないほど自由。
だから、システムを決めるだけで、生産性が上がるのよ。
スレがスゲー伸びてるな。
一応断っておくけど、型ごとにリストのベタ書きの人は俺で、
セミナー君とは別人な。
セミナー君の気持ちは分かるが、感覚的な書き込みは2chでは通じないぜ？
それなりの根拠を書かないと、煽り屋と同レベルになっちまうぜ。
OOP云々の話はスレ違いだが、あえて変わりに補足しておくと、
マルチメソッドの無いOOPLは、不完全な代物だから、
随分思考や思想が捻じ曲がるところがあって、
それに不快感を覚えるのは正常だろう。
また、それらの不快感はある種タスクシステムにも通じるものがある。得てして左巻きな。
そうはいってもOOPの言語機能は武器になるから、分かっててうまく使う分にはOK。
これといった利点が無いのにディメリットばかり目立つタスクシステムと違う。
>>437 C++のオーバーロードはマルチメソッドと言えるのかどうか聞かせてくれ。
それから、ベタ書き=if/swtchとソースロンダリングしようとしている人が居るが、
俺はそんなことは一言も書き込んでない。
「型や用途ごとにリストを持つ」、と述べたのみ。
関数ポインタや仮想関数やインターフェースや差分プログラミングを否定した覚えは無い。
むしろ、そういった細かな対応をするための、型ごとコレクトだ。
型にはインターフェースも含まれるし、インターフェースは複数持つことが出来るから、
複数のリストからオブジェクトが参照されるのも有り。
いたって普通のプログラミングスタイル。
>>438 オーバーロードは静的なマルチメソッドとして機能するね。
これとテンプレートを組み合わせて、ダッグタイピングしたり、C++はかなり柔軟だね。
動的じゃないのが残念だが。
単一ディスパッチのOOPLが不味いのは、
プログラマがオブジェクトの性質を、そのオブジェクト自身で決定しようと躍起になってしまう点だろう。
中二病的というか、男の子のロマンと言うか、なんというか。
実際には、メソッドはオブジェクトのメンバの整合性を保つためのsetter/getter相当だけで良かったり。
というのも、環境内のオブジェクトの性質は、周りとの関係で決定されるものだから、
性質の大部分はオブジェクトの外からじゃなきゃ決定できなかったり。
行間や空気の話。
良かった、危うく敵対しそうになったよ^^
あーちょっと訂正。
ダッグタイピング→ダックタイピング
使う人が不味い前提だと何でも不味いな
codezineの記事はどうでもいいと誰かが言ってて、これに異を唱えなかったけど
今、データ構造と制御構造がごちゃまぜになってる何かを批判してる人は具体的に
何の実装を指して批判してるの？
それともまさかまーた自分に都合のいい妄想の産物をタスクシステムと脳内定義して
シャドウボクシング始めてる？手応えがない理由はそこにあるんじゃないの？
> 自分に都合のいい妄想の産物
それシステム厨のことだろw
タスクシステムの、曖昧ではない定義とそのメリットは、
今まで一回もこのスレで示されたことはないし、
今後一切示されることもない。
既に示された、これが定義で決定、これがメリットで決定、
というのがあればスレ番とレス番を示すべき。
codezineのメリットからの流れで追い詰められてOOPまで否定して
>>413 で終わったのに、アンチって学習能力0だね・・・
>>439 ＞俺はそんなことは一言も書き込んでない。
お仲間の切捨てか過去の主張を無かったことにしたいのかしらんが。
void*とかif/switchとかOOPとかセミナー詐欺とか、負けるたびに
「俺はそんなこ言ってない、そんな真性馬鹿と一緒にするな！」ってパターン
繰り返してるけど、飽きない？
で？アンチでまだ残ってるのは
「iOSでタスクシステム使ってる書籍が具体的に出てるなんて嘘だ！
アセンブラ時代の技術ということにしておかないと負けちゃうから！」
ってお馬鹿さんかな？これもすぐに「そんなこ言ってない」って同じパターンになるんだろうな・・・
そしてまたメリット出ない。
メリット厨が相手をして欲しそうにこっちを見ている！
アンチは同士として責任もってこのメリット真性馬鹿をOOP板まで送り届けてくれんかね。
でないと「あんな馬鹿と一緒にするな」って言い続けることになるぞ？
切り捨てた無能な仲間でもお前らの仲間なんだからさ。
またまたあ
そういうえらそうなことはメリット出せてからいってくださいよｗ
こっちは絶対出ないってわかってますけどねｗ
結局、メリットは出ない。
> iOSでタスクシステム使ってる書籍が具体的に出てるなんて嘘だ！
具体的なメリットが説明できなくても書籍に載ってたらＯＫという判断基準も、
さすがタスクシステム使いだよね。
ずっと池沼のターンw
メリット厨→
>>409→
>>340→
>>411（粘着メリット厨が壊れていることが判明）→
>>413 この流れはテンプレにしようぜ。
過去ログ見ればわかるが、粘着メリット厨は数年前から同じことを言って粘着してるぞ。
下（粘着アンチ＝スキッツォフレニア）は無視して、上を目指すことに合意してくれるよな。
メリット君はアンチの飼い主責任で引き取ってもらいたいところだがねぇ・・・
アンチ同士、似たようなレベルってことで通じ合うんじゃない？
OOPはセミナー詐欺、とかこちらとはいろんな意味で違いが大きすぎて
言葉が通じる気がしないから。
で？
タスクシステムのメリットが出てない状態でこの話進むの？
>>455 下アンチがメリット君＝セミナー君で
上アンチが
>>437のベタ書き君＝引数君というキャラ設定なのかね。
正直あまり違いが感じられないんだがｗｗｗ
アセンブラ君は上下どっちのキャラなんだろうな？ｗｗｗ
下アンチのお出ましだぞ。上アンチは責任もって介護しろよｗｗｗ
＞セミナー君とは別人な。
って同一人物とは見られたくないんだろ？
メリット大好きのシャンプー君まだ頑張ってたのか・・・成長なさすぎだろ
懲りない上に新たにセミナー君という称号まで授与か。おめでとう、おめでとう
ふんふん
んで、タスクシステムのメリットは出たの？
>>458 ＞下アンチがメリット君＝セミナー君で
「上」はその他全てのベクトルという設定だったんだが。
粘着メリット厨だけは、はっきり「下」と言える。
いい歳こいてあわれだな→粘着メリットじいさん
結局メリット出ず。
くだらん展開になってきたな。
あえてメリットを挙げるなら、実行順の動的制御だろう。
ただ、その最たるもののZソートは今や描画エンジンとしてモジュール化するのが当たり前だし。
最早、これといって実行順を動的に並べ替える必要性も無いんだよね。
というか、シーケンシャルに記述するために、わざわざ描画エンジンやサウンドエンジンを外部に追いやった訳で。
そういった流れの中で、タスクシステムの必要性を挙げるのは難しいだろう。
だって、頑張って有効例挙げたところで、
「その機能、モジュール化して外部に追いやれば？」
って言われちゃうの分かりきってるもんね。
煩雑化する箇所が局所で済むし、要求が具体的だから最適なアプローチが出来るし。
ペロッ・・・これはハード屋くん
>>464 進歩ねーのな
× タスクシステムの必要性を挙げるのは難しいだろう
○ 僕のタスクシステムの必要性を挙げるのは難しいだろう
この訂正を否定するなら言及してる対象はこれだと明確に指定しような
>「その機能、モジュール化して外部に追いやれば？」
と言われるほど、モジュール化に問題があるのが最大の欠点だろ。
それを、正しい指摘だと受け取れなとは、なぜに？
>>464 codezineの記事を前提に話をすると、とか、正直に前置きすりゃいいものを・・・
毎度欲張って絞込み条件なしに「タスクシステムは～」とかほざいてっから足元すくわれんだよ
こんだけ特徴的な過ちを何度も懲りずに繰り返してるところ見るとなんか池沼くせぇな
特定の目的を持ったタスクシステム→正しい名前をつけて外部に追いやれば？
汎用タスクシステム→ゴミ。
これで終わっちゃうんだから、仕方ない。
アンチ君の考える見当違いな問題とは無縁の実例
>>306 >>333 は選び放題なのにな。
アンチ君は自分の脳内にしか存在しない憎っくきヘボタスクシステムって見えない敵と戦ってるだけだよな。
Ａ「他人の頭で考えたタスクシステムは問題なく実装されて稼動しています。
僕の頭で考えたタスクシステムは問題だらけで実装すらできず妄想だけの存在です。
やはりタスクシステムは使えない！」
Ｂ「使えないのはタスクシステムじゃなくてお前の頭だろ」
で
>>257 につながる、と。
うんうんわかるわかるよー
で？
タスクシステムのメリットは出たの？
タスクシステムのメリットも出せないくせに長文だけは一丁前とかやめてよね
自分のレスを大事に使いまわす姿は、
自作フレームワークになんたらシステムという名前を与えるのに似てる。
>>473 引数に入れてるものが同じなら同じ結果しか出ないだろ
タスクシステムは違うけどね(笑)
こういうコンテキストの著しくわかりにくい「僕のタスクシステム話」の難読性をみるに
こいつのひり出すコードも相当ひどそうである
セミナーで好んで紹介されてるとかマジ？
手法の一つなだけで商業的なもんじゃないだろ
> セミナーで好んで紹介されてるとかマジ？
一体どこにそんな書き込みがあるんだい？
まさかセミナー君(OOPわからないから全否定しちゃってる残念なオジサン。引数君)の
世迷言を誤読した上に間に受けちゃったりしてないよね？
「○○君」
レッテル張りからスタートする思考法である。
なんたらシステムという大層な名前もさも似たり。
まるで成長のない人間が名無しで延々と繰り言を並べてんだから
記号付けされんのはごく必然なことなんだけどなｗ
勝手に名前付けられて気に食わないなら自分好みのコテつけな
>>479 うんうん
で？
タスクシステムのメリットは？
メリットおじちゃんはもう死んだと思ってたw
タスクシステムのメリットが出てくるまで俺は君たちを殴るのをやめない！
このおじさんは24時間張り付いてるのが凄いよなwww
その生活のメリットを聞きたい
しかし詰まらんスレに成り下がったものだなぁ。
昔は真性タスクシステマーがポエムなソースコードを貼り付けて、
皆でフルボッコって楽しいスレだったんだがな。
絶滅しちまったのかねぇ。
真性メリットおじさんではダメですか
セミナー行ったらFor文ってのをやたら勧められたぜ！
Forは宗教的なもんっぽいからみんな使っちゃダメだぜ！
>>484 あんたら苛めるからタスクシステマーが怯えてしまったんじゃないかｗ
今ではソースどころか、メリットすらあげなくなっちゃったぞｗ
タスクシステムスレなのになｗ 決してタスクシステムの詳細を語らないｗ
このスレ全てが
>>257 の1レスで完璧に説明されちゃってるからな。
で最後に「メリット、メリット・・・アウアウアー」としか言えなくなった
廃人が一人取り残されました、と。
ほらｗ 今日もメリット出ないぞｗ
アマチュアプログラマです。古典タスクシステムをC++で作成して使っています。
基本クラスはインスタンス化は不可にして、用途ごとに継承した型を使っています。
パッド入力、ファイル操作、スレッド操作、描画プリミティブ、サウンドプリミティブ、ゲームオブジェクト
をタスクで回しています。
古典にない独自要素としては以下の通り。
(多くのタスクシステムではすでに当たり前になっているとは思います)
・次/前ポインターの他に子供ポインターを持っている
深さ優先で実行され、グループ化の単位にしています。
また、ある種の命令(表示オフセット等)を伝達させています。
・子供ポインターのリストの処理の前後に実行される仮想関数を持っている
Begin～(特定のタスク群)～Endのような構造の呼び出しを行っています。
>>489 >>488の証明乙
>>490 質問なのかわからんけど
ターゲットプラットフォームと作ってるジャンルと規模、製作人数と製作目的とかの説明があったほうがいいんじゃないかね。
まぁアマチュアでC++だとプラットフォームはWindows＋DirectXだろうけど。
>>491 プラットフォーム:Windows(XP)＋DirectX(9.0)
ジャンル:3Dダンジョンアクション
規模:面クリ方式で12ステージ程度、通信無し
製作人数:プログラマー１人(無料素材のみ)
製作目的：プログラムの勉強と趣味を兼ねて
ベタで書いていて行き詰まると自然とタスクのような形態になる気がする。
メリットの説明にはならないけど。
＞ベタで書いていて行き詰まると自然とタスクのような形態になる気がする。
まぁそうだね。ゲームでtaskやactorは定番だし。
ちなみに過去に最後までゲーム作った経験はあるのかな？
もっと規模の小さい2Ｄゲームとか。
>>493 落ち物パズルとノベルゲームですね。
パズルゲーの時はオールベタだった。
ノベルゲーでタスクの感覚というか作法が身についたような気がした。
(補足)
＞落ち物パズルとノベルゲームですね
これらはC++ではなく、Cで作りました。
ノベルゲーはCでタスクもどきを作りましたが、
最近C++を覚えてあらためてタスクを書いたら、
記述が実に簡単になってびっくり。
おや？ｗ この流れで出るか？まさかのメリット！！
いきなり最初に3Dのオリジナルアクションで何ステージもあるもの一人で作ろうとすると
モデリングやらテクスチャやらアニメやら大量のマップやらレベルデザインやらゲームデザインやらで
プログラム以外の作業量が膨大で途中まで作って終わりという危険性が高いけど・・・
過去にいくつか最後までゲーム完成させてるなら必要なコストの見積もり感覚もあるだろうし、大丈夫かな。
3Dアクションだとモデル表示からアニメーション処理、敵AIや仕様によっては物理演算とか、あと意外に
コツがいるカメラアングル等々、超えなきゃいけない壁が沢山あるから
基底のタスクシステムは手早く実装して先に進まないとね。
まぁ完成するようがんばってください。
タスク関連で疑問があれば
>>306 >>333 あたりの気になるところたけ立ち読みでもすれば
他のゲームでどう実装、解決してるか参考になるかと。
うんうんわかるわかるよー
で？
タスクシステムのメリットは今日もでないの？
>>497 ありがとう。くじけないでがんばるよ。
----
タスクシステムそのものの話題になるよう願ってネタ提供
自分タスクシステムではどんな型もtaskリストのループは基本クラスの仮想関数Updateを呼んでます。
継承した型でオーバーライドするUpdateの中で、その型に固有のUpdate_typeを呼んでいます。
これで基本型から継承型へのdynamic_castを回避しています。
(続き)
ゲームオブジェクトはUpdate_typeの中でメンバ関数ポインターをテーブルで呼び出して振る舞いを切り替えています。
class GAMEOBJ : TASKBASE {
enum STATUS {
STATUS_MOVE,
STATUS_JUMP,
STATUS_MAX,
} status;
void Update( void ) {
Update_gameobj();
}
void Update_gameobj( void ){
(this->*TASKGAMEOBJ::function[status])();
}
void gameobj_move( void );
void gameobj_jump( void );
static void (*GAMEOBJ::function[STATUS_MAX] )( void );
};
それはさ
どこでタスクシステムのメリットと繋がるのかまず説明してから出してよ
無駄だからｗ
んー・・・
一般にジャンプとか移動の単位の状態推移は結構変更が入りやすい＆キャラによってルールが違ったりするから
継承の元の方じゃなくもっと末端に近い側に持つのが普通なんじゃないかなーと思ったり。
まぁどんな仕様のゲームかわからんので何ともいえんが。
「カエルの国」ってゲームでゲームオブジェがもれなくジャンプする＆移動とジャンプの
推移が共通ルールで処理できる、とかならそれもありかと。
クラス継承が深くなりすぎず、コードが冗長になりすぎず、実行コストが高くなりすぎず、
ゲームの仕様を実装する一番シンプルな切り口を見つけられるといいね。
王様はステキな服を着ているよ！
どんな服かは言えないけどね！
ステートと処理をカプセル化したりする
>>492 > ベタで書いていて行き詰まると自然とタスクのような形態になる気がする。
「ベタで書く」の何が気に入らなかったから「タスクのような形態」にしたの？
>>499-500 >継承した型でオーバーライドするUpdateの中で、その型に固有のUpdate_typeを呼んでいます。
意味不明すぎる。Updateの中に直接書いちゃだめなの？
直接書いても、ダイナミックキャストは必要ないぞ。
上の方でダウンキャストト云々の話が出たのは、
複数のタスク間でのコミュニケート時の話だぞ。
例えば当たりの有ったタスク間で何らかの処理をする場合など。
タスクシステムの持ってるのはタスク型にアップキャスト済みだから、
タスクシステムから渡される自分以外のタスクは全てタスク型になる。
だから、何らかの相互作用処理をする前にはダウンキャストが必要だねって話。
それから、一人で作ってるなら尚更タスクシステムの必要性無いぞ。
複数人で作ってるから、共同作業するために何らかのフレームワークがって話でもあるんだぞ。
あと、
>>490見ると、処理順に関して色々工夫しているようだけど、
処理順がデータ構造だけで決定されるってのも、きっと後で痛い目見るぞ。
確かにデータ構造に沿って処理していく類もあるが、
具体的なゲーム製作に取り掛かれば、それ以外のフローが欲しくなったりするものだぞ。
今どう思ってるか知らないけど、
例えば、自分から一番近くに居る敵をロックオンしたい場合はどうするつもり？
俺ならITargetインターフェースを作って、リストにコレクトしとくぞ。
OOP一般で使われるベーシックなやり方だ。
>>508 ＞それから、一人で作ってるなら...
次に別のもの作るときに備えてなんとなくそうした。
＞俺ならITargetインターフェースを作って...
それ頂きました。その段階に至ったらそう作る。
そうやって、結局、型やインターフェースや用途ごとにリストを持つ羽目になるよ。
何かするたびに、相手のタスクをタスクリストからサーチするのは馬鹿らしいからな。
終いには、処理順がタスクの保持構造に括り付いてるのがマゾ制限にしか感じられなくなる。
書いた順に動くのが一番。なるたけそれを維持する努力をした方がいい。
例外もあるが、例外は例外として対応すりゃいい。
まぁ、もう頭の中に想定してる設計はあるんだろうから
それで作ってみるのがいいんじゃないかね。
具体的にここの処理で困ってる、とかの話が無いからそれぐらいしか言えん。
結局タスクシステム使うにしろ別の方法で作るにしろ一番あっていると考えられる
方法で作るしか無いし。
何かの方法しかダメ、とな何かは絶対ダメ、とか手段の柔軟性が無い狂信的な考えに
はまらないで適材適所で考えられる人間が優秀なプログラマ。
タスクは更新のタイミングを伝えたり、実行順を制御するのに使えば役に立つ
それ以外に使おうとするとこの人がリピートしてるようなアホなことになる
514 ：
sage：2011/10/09(日) 02:33:36.58 ID:IiQk0xOC
>>511 ＞何かするたびに、相手のタスクをタスクリストからサーチするのは馬鹿らしいからな。
ここ詳しく聞きたい。
リソースがもったいないって事？
リストだったら線形サーチをせにゃならん。
O(n) だから、n 個のオブジェクトの全てについて、それぞれで相手を探して、とかやったら、
簡単に O(n*n) になっちまう。
>>509 >あんまりよく覚えていない。
ここに理由がないんじゃ技術者失格だね
よくわからないからとりあえずそれっぽい注射打っとけとかいってる医者がいたら怖くて仕方がないだろ？
バーカ死んでろ
「タスクのような形態」という表現から察してやれよｗ
これにかぎらずデザパタだったりしたときも、
「～パターンみたいな」「～パターンの亜種」「独自拡張した○○パターン」とか、
技術用語を曖昧に使いたがったり、独自用語を平気で繰り出してくるのは、
「タスクシステム」と一緒の問題を感じる。
以上メリットおじさんがお送りしました・・・
せめてソースや引用元明示して議論してくれ。
これだから日本のゲームのレベルは低いんだよ。
>>519 ＞せめてソースや引用元明示して議論してくれ。
taskやactorはソースや引用元
>>333 みたいに明示してるし、そもそもactorは
海外で使われてるものだしなぁ・・・
あぁ、セミナー君のことを言ってるのかな？
たしかにソースや引用元を要求すると何も答えらずに「お前がメリット出せ（涙）」
しか繰り返せないようなお馬鹿さんはレベル低いけど、彼は日本のゲームとは関係無いだろ。ｗｗｗ
そう、そしてactorはタスクシステムだ、と必死で強弁するおバカさん程のバカはおるまいw
actorはactor、タスクシステムはタスクシステムだけど、
どちらも同じ問題を抱えているから、ここでは一緒に扱っても良いと思う。
ゲームオブジェクトに基底型を持たすのは勝手だけど、(デバッグや通信の手段)
updateメソッドはイラネーだろ。
メインループ部を自由に触れて、単一アプリで完結してるのに、
コールバックでキックしてもらう意味は無いよ。
おや？今日もタスクシステムのメリットは出ませんか？ｗ
>>515 なるほど。
>>2のCodeZineのソースを見ると指定したグループのタスクを返す
TaskEx::GetTask関数があって、それでタスク間のやりとりを行っているのだけれど
実装がまさに線形サーチだったので問題あるのかなと。
タスクの型や数が少ないから不都合がないのかな？
>>522 機能を組み込む度にメインに修正入れてそうだなｗ
↑悪いけど、それが普通の開発手法だから。
てか、システムの中枢に手を入れてるにも関わらずメインの変更はなしで
その代わりに各オブジェクトへの影響は把握しきれませんって状態に陥ることがあるからタスクシステムっていうか
引数void*のごった煮は怖い
これはタスクシステムに限らない
グローバル変数で値やり取りしてるシステム全部がそう
馬鹿の作ったシステムはなんでもかんでもこんな感じ
各タスクが全くの独立した代物なら問題ないが、
それではゲームにならんからな。
自分は毎フレームupdate呼びますんで、後は各自勝手にやってくださいwww
ではねぇ。リーダー不在のチームだよ。
>>526-528 純粋関数型言語信者のOOP批判に似てて笑った
Haskellでゲーム作ってみたら？お前に向いてそう
反論になってないって
フツーはOOPを使うなりして、ライブラリとして外部に追いやって、
そこを固定にして使うもんだ。
mainおよび、ゲーム本体側はそれを使う側。
使う側は自分勝手な文脈でもって、
自由にライブラリを呼び出すべき。
タスクシステムってのは全体をごっちゃにしてサポートするんだろう？
イヤな予感しかしないんだが。
>>526 まさか肯定されてるとはｗ
本人が苦に思ってなさそうだからそれでいいと思うよ
面倒に鈍感なのも一つの才能だから大切にね
なるたけ上流で解決した方が話が早いんだ。
仕事でも、話が部署間を跨る場合は上に掛け合うものだ。
会社の仕組みがそうなってるから、
どの道新しい機能を追加する場合は上の人に調節してもらわなきゃならんから、
メインループ部を書き換えるタイミングはあるんだよ。
xnaを使ってるんですが、GameComponentを継承すると何か問題ありますか？
http://msdn.microsoft.com/ja-JP/library/bb203873(v=XNAGameStudio.20).aspx
やっちゃってるなぁ。
まーXNA的には、このフレームワーク部を使う/使わないは自由だからな。
本当にUpdate一発だし、
(普通せめて、更新/当たり判定/補正、ぐらいにフェーズ分けするよなぁ。Update一発で処理完結とかw)
しかも出来合いのものだから改変不可だろうし、使うと速攻で地獄行きだな。
例え生粋のタスクシステマーでもこんなもんは使わねぇだろうよ。
ページの下の方の「ゲーム サービス」とかマジ意味不明だな。
どうせ型で引っ掛けるんなら、ファクトリー+シングルトンで良いじゃん。
俺GameComponentは継承させて使わなかったなぁ。あんなくっさいもん使えるかよ。
XNAは数学周りのライブラリ、描画音楽再生等のフレームワークとして使ってる。
ゲーム固有のオブジェクト群は自前で整理させてる。
描画と衝突判定それぞれに、固有の構造で保持させてる。
おやおや、アンチ君の中ではXNAのGameComponentもタスクシステムのお仲間ということで攻撃対象か。
taskもactorもGameComponentもGameObjectもMovieClipもOOPもセミナー詐欺ってかｗｗｗ
アンチ君は世界中敵だらけだな。お忙しいことで。
「世界中が間違ってる！みんな騙されてる！僕だけが正しい！」って思い込むのは疲れないかい？
そのうち電波が聞こえてきて病院に入れられそうだなｗｗｗ
>>534 ＞ゲーム コンポーネントは、GameComponent クラスから新しいコンポーネントを派生させて作成します。
って公式ドキュメント書いてあるからそれに従えばいいんじゃない？
>>535 XNAでのゲームループは専門外でよく知らんかったがこの説明文で設計者がどんな想定でコンポーネント設計したか、は一発でわかった。
多くのゲームで見ることの出来るパターンを共通化してXNAでの車輪の再発明をさせたくないのね。
固定ステップのゲームループでタスクのupdateとdrawを分けてフレームスキップ処理って、タスクシステム使ったゲームの王道パターン。
＞ページの下の方の「ゲーム サービス」とかマジ意味不明だな。
MSのXNA設計者が想定してることがアンチ君の頭ではまったく理解不能ということね。
理解して反対してるわけじゃなくて理解できないから反対。ゆえにその理由を聞かれても
>>257 で相手にメリットを聞くしかできなくなる、と・・・で、理解できない現実を認めると自分が
馬鹿だという事実も認めなきゃいけなくなるから粘着するしかない、と。やれやれ・・・
> 固定ステップのゲームループでタスクのupdateとdrawを分けてフレームスキップ処理って、タスクシステム使ったゲームの王道パターン。
え？ｗ ちょｗ だんだんタスクシステムの貧相な姿が見えてきたなｗ
＞え？ｗ ちょｗ だんだんタスクシステムの貧相な姿が見えてきたなｗ
見えてきたって・・・まじで何にも理解できて無いんだな・・・www
アンチの頭の中ではタスクシステムって「何だか理解できないすごい素敵なもの」になってるのかね？
だから粘着できるのか。タスクシステムごとき単純なものに・・・
ぼくのかんがえてるさいきょうのタスクシステム、の青写真を示すほうが先だろw
やっぱり今日もタスクシステムのメリットは出なかったね！
君の脳内妄想の見えない敵を出せと言われても・・・そんなもの君の頭の中にしか存在しないし。
とりあえず病院行けば？
タスクシステムやOOPはセミナー詐欺！とか君の症状は診断してもらえば病名がつく症状だと思うよ。
>>542 >>539のいう王道パターンが理解できたから貧相って言ったんじゃないの？
とりあえず噛み付いただけなんてお前は野犬かよｗ
死んでいいよ
>>540 タスクシステムの、タスクが何なのか、システムが何なのか、
そっからして分からんからねｗ
いまだにタスクシステムてｗ
市ね
XNA作りやすそうだな。可変フレームにも対応しているのか。
タスク個体関数をUpdateとDrawに限定して特殊化しているわけだな。
VB.NET感覚で出来ちまいそう・・・。
それに引き替え万年童貞メリットときたら、日本の恥部だな。
×日本の恥部
○恥部
メリット爺さんは、人類とは無縁の存在だったな。
OOPまで否定しちゃってるアンチ君にはかなわないけどなぁ・・・
OOPもtaskもUnrealEngineのactorも、UnityのGameObjectもFlashのMovieClipもXNAのGameComponentもって
噛み付き過ぎだろ・・・全敗中なのにさらに敵を増やすなんて、何がしたいんだか。
アリンコにとっては小さな道具でも倒すべき巨大な敵に見えるのかね。見てる世界の大きさが違いすぎ。
データ構造と処理の順番は切り離したらタスクはもっとつかいやすくなるよ。
相手を必死で矮小化するの図ｗ
必死になるまでもなく、
もともとメリ爺の発言の節々に卑屈さ、矮小さが現われているんだが。
まさか自覚しないのかｗｗ
お前はゲーム制作どころか、やはり人間のどの営みとも無縁な存在だな。
ほらなｗ
へぇ・・・セミナーアンチ君にも自分が矮小って認識できるぐらいの知能はあるんだ。
略ｗ
いつもの流れだとアンチ君はこの後単発IDで「メリットメリットォォォ（泣）」とつぶやくん発作をおこすんだけど・・・
そろそろ病状が発祥するかな？
メリットといえばリンスインシャンプーってみかけなくなったな。
可変フレームレートは、Gameクラスで行われている。GameComponent関係なし。
Gameクラスを継承して、Game.UpdateとGame.Drawにそれぞれ処理を書けばOK。
GameComponentは単なる散らかし屋さん。
優先順位に従って毎フレームUpdateを呼ぶ以上の機能は持ってない。
ここが惑星パンドーラであれば、
バンシーとダンスする試練にたどり着くまでに余裕で脱落ｗ
子育てなど夢のまた夢。一生子供として扱われるメリット爺さん♪
質問する場所間違えた感じですけど、
とりあえずGameComponentを継承するやり方で特に問題はなさそうですね。
このままゲーム制作を続行したいと思います。ありがとうございました。
ほら、どうするんだ？
性悪が適当なことばっか言って煽るから、
>>563こんなこと言ってるぞ。
まー痛い目にあうのも勉強か。
一つだけ助言しとくと、普通は最低限、
1．とりあえず全部更新してみる。
2．不都合が起こってないか全てチェックして、結果はメンバに一時保存しとく。
3．2の結果を受けて、不都合が起こっている場合は補正をかける。
程度のフェーズがあるものだぞ。無論ゲームの仕様にもよるがな。
Update一発でどうやって切り抜けるつもりだ？
出来合いのフレームワークゆえ、改変すら効かんぞ。
とは言っても、どうせ聞かないんだろうから、好きにやってみ。
メインにUpdateやDrowのループが有るからと言って、タスクシステムではない。
Draw・・・
おう、こまけーなｗ
>>564 なるほどー、デフォのGameはそういうところが弱いかもですね。
ただ、全コンポーネントを巻き込む必要はないので、
親コンポーネント作って範囲内でやるようにします。
はいはい、ゴミは黙ってようねｗ
メリットおじさん閉店のお知らせ
>>570 だいたい君そういうの精査できるような判断基準もってるの？ｗ
ないでしょ？
ないからわからないしやってみようとも思わないから疑問すらわかないんでしょ？
ゴミは君のほうねｗ
花王のメリットは使うと禿げたり皮膚炎になるらしいよ
俺使ってた（´；ω；｀）
原液で使うとどの洗剤も濃過ぎなんだけどな
結局あれってさ、よくゆすぐことのほうが大事かもね。
だって量的にはそっちのほうが決定的だろ。
もともと悪い成分なんて微量なんだから。
メリットって、フケだらけになるよな。
今日もタスクシステムのメリットは出ない、絶対だ
俺がタスクシステムだ
タスクシステムに両親でも殺されたんだな
お前も死ねば良かったのにｗ
>>578 それ昔から言われてるよなｗ
フケ用シャンプーは逆にフケ出るの法則。
マジレスすると、普通に薬の副作用もそうなってるのがほとんどな。
喘息の薬の副作用は喘息に、
アトピーの薬（副腎皮質ホルモン）の副作用はアトピーに、
欝の薬の副作用は欝に、
まぁ出来るだけ薬品は摂取するな。
薬の副作用とシャンプーのメリットは出ても
タスクシステムのメリットは出ない、絶対だ
／ヽ,,)ii(,,ノ＼
／（○）))((（○）＼ さっさとメリット！
／:::::⌒（__人__）⌒:::::＼ メリット、メリット、メリット！！
| ヽ iｌ´ |r┬-|｀ｌi ｒ |
＼ !ｌ ヾｪｪｲ ｌ! ／
: : : : : : : :.._ _ ＼
: : : : : : : ´⌒＼,, ;、､､／⌒｀ |
: : : : ::;;（（ ・ ）::::ﾉヽ::::::（ ・ ））;;::: | うおおおおぉぉぉぉぉぉああぁぁあああ！！！！
: : : : : : ´"''", "''"´ |
: : : : : : . . （ ＼j ／ ）/ ／
＼: : : : : : :.｀∨トエエイ∨ ／
／ヽ: : : : : : : :∧エエ∧ : : : : : イ＼
: : : : : : : : : :.｀`ｰ- -‐'"´ ＼
慌てる乞食はもらいが少ない、を地で行くメリット君であった・・・
メリットはあるよ！
どんなメリットかは絶対に言えないけどね！
今日もタスクシステムのメリットは出ない、絶対だ
>
>>583 多重債務みたいだな。
一見便利そうに見えて、副作用で余計手間が掛かる。
どこかでも聞いたような話だな。
お前等鼻炎の薬には注意しろよ。
鼻詰まりを一時的に直すスプレーみたいなの。
あれやってると鼻の内側の粘膜が厚くなってきて、
さらに詰まりが底上げされるから、
スプレー頻度増加、粘膜厚み増加で地獄見るぞ。
耳鼻科のセンセも呼びかけてるみたいだから慎重にな。
結局焼きゴテいれて部位を切除するしかねえんだよな。
明日もタスクシステムのメリットは出ない、絶対だ
何故、タスクシステムのメリットが出せないのか？
タスクシステムのメリットはあるよ！
どんなメリットかは絶対に言えないけどね！
見てわからんモンキーは聞いてもわからんとは、よく言ったモンよのう。
しかし大人の階段登れない害毒ジェネレータ、未来永劫童貞メリット爺さんを、不毛な粘着に駆り立てている動機は一体何なんだろうな。
これまでに上げられた理由：
・単に知能が低いだけ
・スキッツォフレニア
・両親をタスクシステムに殺された <-New!
・自分のことを人間と勘違いしている被検動物モンキチ <-New!
↑メリットを出さない代わりにキーボードカタカタした労力乙ｗ
人格を攻撃し始めたら討論は終わりだ
メリット君は人格以前の問題。ただの荒らしだし。
粘着アンチの荒らしが「人格攻撃するなよぉぉぉ（泣）」って言ってもねぇ・・・
過去スレ見てまだ自分がそんなこと言える人間だと思うならほんとに病気だよ。君。
なんか言ってるね。
タスクシステムの載ってる書名が出たあたりからメリット坊やは
単発IDでメリットメリットつぶやく以外何も出来なくなったからな・・・
現実VS妄想じゃ始めから勝負にならんよ。妄想は精神科医にでも聞いてもらうんだね。
こういう思い込みがタスクシステムを支えてるのかもしれんね。
>>600 書名が出てもそこでメリットがどう説明されているのか挙げないと意味無いじゃん。
>>596 ホントだよな
こんな無駄な長文書いてないでさっさとメリット書けってのな(笑)
*** 基地外の朝は早い ***
「まぁ好きではじめた仕事ですから」
最近は良いメリットが取れないと愚痴をこぼした
まず、素材の入念なチェックから始まる。
「やっぱり一番うれしいのはお客さんからの感謝の手紙ね、この仕事やっててよかったなと」
「毎日毎日温度と湿度が違う 機械では出来ない」
何故、メリットが出せないのか？
メリット職人www
必死にメリット集めて何作るんだよw
>>606 おい、ガラクタ職人
メリットのないもの集めてお前こそなに考えてる？
そういうことはメリットが無い証明をしてから言ってくださいよ
現状はお前の寝言が無視されてるだけじゃんｗｗｗ
「無い」を証明しろと申すか？ｗ
それをすべきは「有る」と主張する側。
じゃあ何も証明されてないのにガラクタと言っちゃったのはやはり寝言ということかな？
何も証明されてないならば、「メリットが出てない」という主張は正しい。
「出てない」と「無い」は違うだろ・・・マジ馬鹿？
出てないけど「有る」と申すのか？ｗ
で、そこから先はまた口をつぐみなさるのか？ｗ
ま、無意味な会話はやめてっと
じゃあデメリットなら出せるの？
結局今日も出ねぇ('A`)
また明日来よっと。
しばらくFPSやってるから、じっくりまとめてくれていいからねｗ
こんなので撃退完了かよｗ
結局、メリットもデメリットも「出ない」。
無意味なスレ。
媒体に出ているアドバンテージ引用しても、理解できんのだから、まあ、アレだな
例の「お前がそう思うんならそうなんだろうな、お前ん中で花（AA略
メリット爺さんは現実病気だから、月並みな煽り文句がシャレにならんｗ
粘着アンチのくせにデメリットの一つも出せずに逃走するメリット職人の手際に吹いたわ
>>564 不具合って何？
誤差？ ぬるぽ？ それとも何？
文盲じゃなきゃこのスレでメリット出てないなんて言えないだろう
>>398が（自分の頭で理解できるような）メリット出せないって言ってるだけでしょ
そりゃ無理だわwww
OOPすら理解できないんだもんwww
おはようお前等ｗ で、メリットは出てきたかい？
メリットは出てるけど
君の頭で理解できるメリットは出てこないよ！残念www
出てる出てると言うけれどｗ
OOPといっしょで君の目には存在が見えないんだ
「OOPなんて裸の王様だ！みんなセミナー詐欺に騙されてる！」って泣いてれば？www
世界中のプログラマが哀れみの目で見てくれるよ。メリッット君www
OOPとタスクシステムは違うだろｗ OOPに謝っとけよｗ
おやおや、ではOOP云々いってるメリット君は完全に間違ってる、ということでOKね。
あれ？アンチがいなくなったぞ？www
OOPのメリットも言えと言われたら言いにくいな。
あえて言うならポリモがもたらすオブジェクト単位でのモジュール性、
カプセル化がもたらす内部の保護、クラスベースならクラスというもんがもたらす新たな整理の軸、
クラスライブラリを用意するにしてもクラス階層というもんがクラス群を整理して理解を助ける。
関数型やりこんでる人からしたら不吉な匂いだろうが、変数と関数くっつけて、
抽象化したモノとして扱っちゃうってのは、結局人間の思考にとって無理が無いから受け入れられたんじゃないかなと、今は思う。
メリットはこれだ、ときっぱり示すことはできんが、ぐだぐだ言うとこうなった。
こんな感じだと思うがどうよ。お前等が思うOOPのメリットって何よ。
うんうんわかるわかるよー
で？
タスクシステムのメリットはでたの？
アンチは間違ってるって認めたのにまだ何か言ってるよ・・・？
「アンチに言い分はもう何も残っていません。全て間違いでした。このスレにたくさん出てるメリットは
僕の頭では理解できません。誰か僕の頭でもわかるようにメリット教えてください」って
なんだかここまでくると哀れだな・・・
メリットもデメリットも何も理解できないならスレ違いだから去れば？
今日もタスクシステムのメリットは出ない
絶対だ
つまらんな、主張は全部論破されてもうアンチですら無くなったのに
メリットメリット言って粘着するだけって。
人工無能でももう少し面白いぞ。君は安物RPGの村人か？
まぁこれはものすごく典型的な2ch負け犬荒らしの特徴だけど、そろそろ飽きてきたな。
タスクシステムのメリットはもう出ないだろｗ
OOPのメリットについて語ろうずｗ
基地外乙
>>630がメリット君の精一杯なんだよなｗｗｗ
無能なりに頑張ってるって感じ？
明日もタスクシステムのメリットは出ない
絶対だ
タスクシステム職人の朝は早い。
つまらん死ね
アンチはアンチでなくなったとか言い出した。
その発想が怖いわ。
タスクシステム以外のメリットなら俺に聞いてくれｗ
なんか答えてあげられるかもしれんぞｗ
今日もタスクシステムのメリットは出ない
絶対だ
メリット前に出てたじゃんｗ
こいつ的には出てないことになってるらしい
相手するだけ無駄だよ
きっと、あまりにも恥ずかしいメリットだから挙げられないんだよ。
基本、処理の実行順は明白なのに、何故か処理のリストを持って動的ソート。
基本、相互作用が多いのに、何故かマルチプロセス風の設計。
基本、1フレーム完結の同期処理なのに、何故か擬似マルチスレッド。
アホみたいなメリット上がってきたらどうするよ…。
おいおいおい…っていう感じの。
自演乙。もう少し頭使いなよ
ところが、自演ではないのだなぁ
んおーっ？
やっぱり今日も出てねーじゃねーか…。
そうやって積極的に発言してくれる人は清々しいねぇ。
強調性のあるタイムスライシング問題の解決ってのは現時点では意味不明だけど。
ならば説明を求む
メリット来たwww
強調性って、協調性の誤変換？
どちらにしても意味不明なんだが。
つーか向こうのスレ、池沼の集まりだな。
こっちのスレの方が意外にマトモだ。
困ったな。
お前はいろいろなスレに迷惑を掛けてるんだな
あー分かった。協調的マルチタスク(ノンプリエンプティブ・マルチタスク)
って言いたかったのかな。
でも、それ、OSの話題だよね。アプリケーションへのCPUリソースの分配方法。
アプリケーションは応用ソフト、つまり、OSから見るとプラグインなわけだけど、
単体アプリのゲームで、そんな制限のキツイ手法を取り入れる必要はあるのかね。
アプリは各自独立が前提だけど、ゲームオブジェクトは相互作用が多いし。
処理順に関する見解も違うよね。OSのマルチタスクは本当にどの順で実行しても良い訳で。
というよりまずは、ここまで粘って結局出たメリットが、
本当に
>>653でいいのかどうか確認したいんだがｗ
タスクシステム信者息してないｗ
巷のッモルピグはタスクシステム使ってますか？
>>653 業務系職業PGなんざ保身第一の無能役立たずばかりで、0.00000000001%も使える奴いねえよ。
あんなノイズ砂漠をさすらう気はないぜ。
別にゲ製のお前らのことを褒めているわけじゃないぞ。
>>661 OS仕様がゲームの仕様と似ているんだろ。
＞アプリは各自独立が前提だけど、
ゲームオブジェクトも基本は然り
＞ゲームオブジェクトは相互作用が多いし。
OS上アプリであっても相互作用は多い。
コピーペースト、ファイルやデバイスに対するアクセス権限、アプリ間対話。
＞処理順に関する見解も違うよね。
処理順とはすなわち描画順。デスクトップ上ウィンドウの描画順
＞OSのマルチタスクは本当にどの順で実行しても良い訳で。
完全に独立しているゲームオブジェクトであれば、どの順に実行しても良い。
ミドルウェアと連携するOSアプリには、マルチタスクの制約が当然かかる。
すなわちOSは、タスクシステムのメタファーであり劣化版。
タスクシステムこそアルファにしてオメガ。
ッモル・・・
タスクシステムの起源は韓国ニダ
ピグ！！！！！
誰だよム板からこんなゴミ連れて来たのは
反論する気も無くなるな。ネタだろうけど。
672 ：
666：2011/10/20(木) 22:34:45.47 ID:I5BnZctQ
ムイタなんてシラネ
獣の数字666・・・
>>666 書いたの俺じゃないけど横からレス
>ゲームオブジェクトも基本は然り
いや基本的にツリー構造だし
そもそもインスタンスを表現するだけで「ワールド」（すべての親？）がいないと
基本レベルで存在すらできないじゃん
ライトもカメラもないとそもそも描画すらできないし
この辺ですでに依存度高いと思う
>OS上アプリであっても相互作用は多い。
>コピーペースト、ファイルやデバイスに対するアクセス権限、アプリ間対話。
こんなのタイミングが明確だしそもそもゲームの「多い」とは桁が違う
ミリ秒単位で必要なのがゲームだけど業務アプリはウィンドウズのメッセージの振ってくるレベルで十分対応できる
>処理順とはすなわち描画順。デスクトップ上ウィンドウの描画順
意味不明
主旨と関係ないならレスしないほうがいいかと
>完全に独立しているゲームオブジェクトであれば、どの順に実行しても良い。
それは存在しないよね？
マップが用意された時点でもうマップとの関連があるわけでさ
ゲームで一番複雑で気をつけて管理しなきゃならないのは
間違いなくオブジェクト同士の関連の処理
オブジェクトごとにクラスにまとめてもなんのメリットもない
まして、別スレッドで動かすことにメリットなぞあるはずもない
エクセルの行にオブジェクト、列にパラメータならべてエクセルで管理するように
ゲームオブジェクトをデバッグできる環境にあたったことがあるが
本当にほしいものはまさにそれ
タスクシステムなんてノーサンキュー
ッモル・・・
それ、流行んねーから
676 ：
幻獣666：2011/10/21(金) 07:36:43.29 ID:hkMDEZmO
おいおい、ちょ、ま、（ボソッ）世界人口・・・
いやなんでもない。
＞いや基本的にツリー構造だし
Windows系のウィンドウアプリの話になるが、
VisualStudioに付属のツールSpy++で、ウィンドウ構成見たことあるか？
無数のウィンドウがツリー構造になっていて、描画順にも関係している。
＞そもそもインスタンスを表現するだけで「ワールド」（すべての親？）がいないと
＞基本レベルで存在すらできないじゃん
アプリだって、親OSがいないと存在できないぞ。
基本的にOSにAPIでサービス要求して、もろもろの構築をしてるんだが。
＞ミリ秒単位で必要なのがゲームだけど業務アプリはウィンドウズのメッセージの振ってくるレベルで十分対応できる
なんか論点がずれてきている気がするな。
相互干渉が起こる時間間隔の相対的な大きさは関係ない。
どれだけ複雑な相互干渉が起こりえるかが問題じゃないか。
＞こんなのタイミングが明確だしそもそもゲームの「多い」とは桁が違う
無数のウィンドウがあるから、かならずしも明確とは言えないぞ。
もちろん明確にするために仕様を整理する努力は必要だが、それはゲームでも同じ。
他にもコメントしたいが、最後に一点だけ
結果的にタスクシステムの解決力を、OSと比較して持ち上げているように解釈出来るような出来ないような、
所謂なんだっけか、「ヤンデレ」というやつかｗｗｗ
>>676 >無数のウィンドウがツリー構造になっていて、描画順にも関係している。
タスク同士の話じゃなくなってるじゃん
自分の有利に話たいからってもう頭おかしいだろ
>アプリだって、親OSがいないと存在できないぞ。
タスク同士の話じゃな（ｒｙ
>相互干渉が起こる時間間隔の相対的な大きさは関係ない。
はぁ？
>どれだけ複雑な相互干渉が起こりえるかが問題じゃないか。
ゲームのが圧倒的に複雑だよね
業務アプリはせいぜい振ってくるメッセージで十分
>無数のウィンドウがあるから、かならずしも明確とは言えないぞ。
どうしたの？ｗ
レアケースだけあげて逃げられる話じゃないでしょ？
> タスクシステムの解決力
すげー単語が飛び出してまいりましたよオマイらｗ
ピグ！！！！！！
池沼の類か
どうやっても「っもｒｐｇ」にしか変換できない
流行らんな。これは。
OSのプロセスのスケジューリングとタスクシステムに関する話だったはずなのに、
なぜかウィンドウの描画の話にすりかえられてるな。
OSのウィンドウ描画は言うまでもなく、ゲームで言えば、描画エンジンの話だ。
タスクシステムとは関係ない。
描画エンジンは、非同期に実行される描画コマンドをスケジューリングするシステムで、
こっちはタスクシステムと違って用途が明確だし、、
しかも互いの描画オブジェクトは相互作用しないのが前提。
サウンドエンジンも然り。
オブジェクト同士の相互作用が主な、ゲームオブジェクト更新部とは性質が異なる訳。
森羅万象はタスクシステムの掌の上にあるというのに
君はゲームオブジェクト限定のお粗末システムの話をしていたのか
森羅万象は、万有引力や静電気力などの相互作用で成り立っているのだ！
これらの力の源やメカニズムは現代物理学ですら解明されていない。
森羅万象は、神の手の介入を許すのだ。
新たな理解は新たな謎を生む。神は、死なんのだ。
ついに気が狂ったか
わずかな個体差はあるだろうが、神様から見たらどいつもこいつも頭の構造差なんて大したことないぞｗｗｗ
まあ見解の相違はあるだろうが、ツンツンしないで落ち着いて逝こうやｗ
ザックリ言やぁ
＞割り込みタイマー方式プリエンプティブ・マルチタスク → 可変描画フレーム対応タスクシステム
＞ノンプリエンプティブ・マルチタスク → 固定描画フレーム対応タスクシステム
みたいなもんだろ。
>>682 ＞OSのプロセスのスケジューリングとタスクシステムに関する話
確かにWindows上で存在する無数のウィンドウは、アプリごとに単一プロセスに属している。
単一プロセス内の処理は、基本はイベント駆動でOSが詳細に口をはさむことは無い。
（この側面は、ゲームオブジェクトが抱える問題のメタファーでもあるだろう）
しかしOS上アプリが各自独立かというと、そうでもない。
ファイル入出力やメモリ消費量など、どうしても共有から免れない側面がある。
いろんな相互干渉の可能性を考慮しないと、安定動作せず売り物にならないじゃん。
しかもそもそもOSがインスタンスを割り当てている（←どこかで見たな、この図式ｗｗ）。
そういうわけで、OSもプロセス調整には課題があり、アプリ独立というのは幻・・・
ウム。
皆の衆もタスクシステム道を精進してくれ給え。
＞割り込みタイマー方式プリエンプティブ・マルチタスク → 可変描画フレーム対応タスクシステム
＞ノンプリエンプティブ・マルチタスク → 固定描画フレーム対応タスクシステム
全然違うだろ・・・お里が知れるぞ。
>しかしOS上アプリが各自独立かというと、そうでもない。
>いろんな相互干渉の可能性を考慮しないと、安定動作せず売り物にならないじゃん。
OSのプロセス管理では、あなたの言うとおり、各プロセスが極力干渉「しない」方向で努力している。
プロセス固有の仮想アドレスも、ファイルIOのスケジューリングも、ページスワップも、
全部、各プロセス間でお互いが干渉するのを防ぐための仕組み。
OS上のアプリが各自独立して動くためにOS側が用意した仕組みなわけ。
一方ゲームでは、各オブジェクトが相互作用する方向で努力しなければならない。今はそっちの話題なわけ。
副作用を許す環境で相互作用するわけだから、処理の順番が非常に重要になってくる。
この場合、タスクシステムによるプライオリティー管理よりは、書いた順そのままにシーケンシャルに処理が走る方が好ましい。
とうとうタスク信者も終りか・・・
長い戦いだったな
こんな役に立たないもん背負わされてさぞ大変だったことだろう
ッモル・・・
>>687 言ってることは概ね分かるんだけど、一点だけ、「副作用」ってのがよくわからない
>>688 別に戦いじゃないからｗ
俺は単に好奇心だったなぁ。
チラッといくつかの記事をよんだりしたことがあるが、
メリットについてはひたすら疑問だったんで。
メリットあるというのなら、具体的に熱く語ってくれるもんかと思ってた。
しかし最後まで一言も語らなかったのは、これまた不思議だけども。
・・・ッモル・・・
お前らもうインテルのTBB使えよ・・・
>>690 そいつは『タスク＝ゲームオブジェクト』とか『1タスク＝1ゲームオブジェクト』という
固定観念に勝手に縛られたまま何年も停滞してる自称ハード屋君だから
あまり真に受けないほうがいい
タスクとはゲームオブジェクト（敵キャラとか弾とか）だという先入観に凝り固まってるよな
まぁそういう紹介のしかたをしてるアマチュア発のタスクシステム怪文書が2000年以降
ネットや雑誌（Cマガ）や書籍で氾濫したからそう思い込むのも無理ないんだけどさ
カーゴカルトの素人に騙される素人は気の毒だとは思う
>>695 んー。まぁ仮にご本人さんがそういう意図で書いてるのだとしても
> 副作用を許す環境で相互作用するわけだから、処理の順番が非常に重要になってくる。
これはピンと来ないなぁ・・・。もう少し詳しく書いてほしいなぁ
それに、なにやらプライオリティキューの各要素（処理）間には従属性が必ずあるというか
プライオリティキュー内での要素の位置関係＝（処理の従属性にもとづく）処理の順序
（処理の手続き）を表現してるのだという先入観が見え隠れするなぁ。ESPだけどさ
プライオリティキューのプライオリティは順序ではなくて順位なんだよねぇ
>>697 頭悪いからそんなレスしかできないんだな
順位だって順序だってかわんねぇだろボケ
早く死ねよ
>>697 てか、もう勝負モードに入っちゃってるでしょ？
まったく議論のポイントになりえないところをつついて
そこにテコいれして相手の人格から叩こうとしてるでしょ？
もう技術者やめちゃいなよ
君、そういうのやるたびにスキル下がっていってるの気がつかないの？
そういうの周囲の人間はみんなわかってんで
わざわざ指摘しないけどかなり滑稽で恥かしいんだぜ
>>698 順序なら同一プライオリティ値のタスクが複数あることは許されないよねぇ。それでいいのかい？ｗ
ボケとか早く死ねとかリアルでいつも言われてフラストレーション溜まってるのか知らないけど落ち着こうな
アンチ共が言うに事欠いて発狂し始めたなｗｗｗｗｗ
>>700 どっちでもいいじゃん
どうせ役に立たないんだからｗ
ID:FlvSeSt3
可哀想に…
ID:FlvSeSt3君の自傷行為的自己紹介癖には困ったものだな・・・
・・・ッ・・・モル・・・
>>699 勝負モードに入っちゃったとか言われてもよくわからないよねぇ。俺は解決力クンとは違うからさ
> まったく議論のポイントになりえないところをつついて
> そこにテコいれして相手の人格から叩こうとしてるでしょ？
よくわからん前提条件で話を進めてるからとりあえず話の腰を折って確認してるだけさ
「ボクの筋書きから逸脱する話は許さない」みたいな反応されてもさ、知らんがなそんなの
繰り返し聞くけど
> 副作用を許す環境で相互作用するわけだから、処理の順番が非常に重要になってくる。
これはピンと来ないなぁ・・・。もう少し詳しく書いてほしいなぁ。ここ重要なんだよねぇ
それとも俺がESPした
>>697は図星だったのかな。まぁこういう反応が返ってくるってことは
概ね当たりってことでいいのかな
ピグ！！！！！！！
708 ：
G.E.666：2011/10/23(日) 05:18:04.85 ID:Xjvemc8L
地平線に消える瞳には、いつしかまぶしい漢の光・・・
>>687 ＞一方ゲームでは、各オブジェクトが相互作用する方向で努力しなければならない。
各オブジェクトの相互作用を最大化ってのは同意。
ニューロンスパークが同意ｗ
＞副作用を許す環境で相互作用する
↓
＞だから、処理の順番が非常に重要になってくる。
↓
＞この場合、
＞ × タスクシステムによるプライオリティー管理
＞ ○ 書いた順そのままにシーケンシャルに処理が走る。
タスクシステムのプライオリティは静的な設計下で設定するもんでないか。
タスクシステム。それはニューロンスパーク打ち上げ花火のために。
あの人の目がうなづいていたよ、別れも愛の一つだと・・・
一人寂しくｹﾀﾞﾓﾉﾉｽｳｼﾞ『R-Type666』の夢でも見るか・・・
>>706 書いた本人じゃない人に聞いてどうするの？
基の文章を書いたのは俺ね。
手続き型言語の相互作用で処理の順番が重要になるのは当たり前だと思うが。
>>694 たとえ、『1タスク＝1ゲームオブジェクト』ではない、
つまり、『タスク=処理』な、本式のタスクシステムでも、結局同じこと。
種別の異なる処理を同一リストで管理する理屈は無い。
描画用のコールバックと、サウンド用のコールバックを同一リストで管理したりはしないだろ？
同じこと。
返信無しか。寝てるのかな。
まー詰まらんことにESP働かせる暇があるなら、
真っ先に本人かどうかの確認をすべきだな。
>先入観が見え隠れするなぁ。ESPだけどさ
先入観を持ってるのはお前だった訳で。(俺と思って返信した訳でしょw)
ESPという先入観を使って、相手の先入観の指摘。
そのくせ、本人確定はハズレ。疑うべきを疑わないでESP。まさに先入観。
相手を批判したつもりが、全部自分の自己紹介でしかないという、
いつものお前のお決まりのパターン。たまには回りも見たら？
そろそろタスクシステムのメリット出た？
アンチの異常性はその生活リズムにもあらわれてますね。こわいです＞＜
>>710 いや、先入観で語ることが悪いと言ったわけじゃないんだよねぇ
それ先入観だよねぇ、って確認してただけさ。確認できればそれでいいのよ
意味不明瞭なタスクシステムというバズワードを、それが指す対象を
予め絞り込むこともなく、何やら怪しげな前提条件を暗黙知ということにして
あーだこーだ言ってるってことで本当にいいの？ってこと
毎度毎度わかりやすい逃げ道を用意してくれて優しいなぁ、痛み入るなぁ、と
"意味不明瞭なタスクシステムというバズワード"
ありがとうございますフレッシュなお言葉頂戴いたしました！
モルッ！
ピ、ぴぐぅぅぅぅぅ！
>>709 自称ハード屋君はアンチを装ったタスク信者だからわかりやすいなｗ
＞たとえ、『1タスク＝1ゲームオブジェクト』ではない、
＞つまり、『タスク=処理』な、本式のタスクシステムでも、結局同じこと。
本式かどうかは知らねーな。本式だと思うなら別に構わねーけどなｗ
＞種別の異なる処理を同一リストで管理する理屈は無い。
同一リストで管理ってのは何がどう管理してるのか知らねーが
例えば、限られた処理時間を上手に活用して
(各種)演算リソースに処理を上手に充填せにゃならんという要求があるときに
何かしらの仕組みが一括して手配師の役をやる状況ってのも当然あるわけで
そういうのが全くもって見えねーってんならただ単に見識が狭いってことだろがよ
理屈が無いんじゃねーんだって。見えてねーってだけ
＞描画用のコールバックと、サウンド用のコールバックを同一リストで管理したりはしないだろ？
＞同じこと。
なんでコールバックとか言い出すのかしらねーが
どうせ上に同じことだろな。低レベルのタスクディスパッチャーが見えてねーってだけだろ
管見自慢もたいがいにしとけっての
アンチの知見が足りなさすぎて呆れられて蹴っ飛ばされる毎度おなじみの展開です。こわいです＞＜
>>717 は？なに？タスクシステムにメリットがあるっていってる？
メリット爺は要介護のようです
処理の優先順位なんて鶏が先か卵が先かの違いしかないのに、
そこまで固執する必要はあるのか？
処理順に依存してるからでしょどうせｗ
やる気が皆無なだけなんだけどな
どっかのバカがてんこ盛りで出したバグ、
全部こっちのせいにされてやってられるかっつうの
そういやうちの職場タスクシステム使ってるよ
便利だからあるんなら使わない手はないと思うけどな
処理順序で思い出したけど
こないだ処理順序の問題でバグだしたばかがいるんだけど
こっちが仕様段階でこう作れっていったの無視して勝手に作って
コードレビューで指摘したのに無視して
あげくの果てに現地で問題発生させやがって
で、いった台詞が設計が悪いからだの複雑だの、
こっちゃ普通の設計しかしてねえよ
ダブルポインタすら分からねえ、てめえらのレベルが低すぎるんだっつうの
表示をソートするためにリストビューを二つ使ってるんです！
…あほか、それくらいいっこでやれよ
このバグはこっちのコマンドに対する装置ソフトの反応が遅かったからです！
…装置が反応したの確認してから次の処理にはいれよ
装置にセンサーがついてないと確認になりません！
…てめえセンサーなんか見てねえだろうが
ポーリングで通信するのは負荷が高いんです！
てめえがノーウェイトでポーリングすっからだろうが
以上を指摘すると、
昔からそうなんでおかしいのはそっちです！
…知らねえよ
以上愚痴
もういいかげんいやだ
門処会議で他人のバグをさも自分が出したかのように報告させられて
まるで俺が悪いみたいにされて。
こっちは一件もバグたしてねえんだよ！
汚名返上と思ってあほみたいな時間から会社いってでばっぐして作った装置なのに
ほんとやってられるかっつうの！
なにこれ？メリットおじさんの小説？
タスクシステムを便利だと言ってるから違うんじゃないかな。
そっちで引き取ってね。もうこないだろうけど。
プライオリティをタスクごとに設定する処理はマジで鬼
絶対にバグまみれになる
っていうか、出来てる思ってもできてないことが多いと思う
また、確認する方法もないうえに他のオブジェクトが引き金になってさらに処理が増えることもあるので
バグらないわけがない
そもそもベタで書けばそんなことする意味もないし無駄な苦労なんだよね
タスクシステムであってもオブジェクト同士の関連処理はベタで書いたらいいんじゃないか？
それだけでかなりのバグを抑えることができると思う
ッモル・・・
ピグッ！ピグッ！！
>>730 ターゲットのアーキテクチャ、計算粒度、回転数、並列性抽出・コード再構築の難易度or工数、etc
状況に応じて最適解は変わるわけだが。適宜選択するもんだろが。ループアンローリングで十分なら
それはそれで何か事情あるんだろ。ベクトル化しやすい部分だけちょちょっと最適化する程度で十分とかさ
前スレで自称ハード屋君がベクトル型スパコンレベルの命令レベルの並列化こそゲームに最適なんだ
みたいなことほざいててワロタけど、もしかするとそういうハードに向いてる事情でもあるんじゃないか
理論的にプライオリティじゃむりなんだよ
ワンフレに何度もくるんだから
タスク＝ゲームオブジェクトで1タスク＝1ゲームオブジェクトなゴミシステムでなければ
そういう意味不明な話にはならんわな。タスクがゲームオブジェクトの実体になってんだろ
悲惨だな
× タスクがゲームオブジェクトの実体になってんだろ
○ タスクがゲームオブジェクトの実体になってて、なおかつ
（活性）ゲームオブジェクトのリストが実行キューになっちゃってんだろ
だったらこっちにぐだぐだいうな
ひどい言いぐさなことだけあやまる
>>735 PS3がクソだからってあたらないでよ。SPERSのことは忘れろ。
およしよそういうの。ゲハ脳君
ごめんごめん
お前ら恥ずかしいわ
メリット爺さん死亡説
×勝利
○敗北
ということにしたいのですね
結局、タスク派はメリット出せなかったじゃんな
メリット爺さんは簡単に釣れるなw
と、全く意味のない勝ち誇りしかできないのですねわかります
まったくだな
メリットじいさんとかいってるけど
じゃ、お前はプログラマでなんにもメリットないもの延々と作ってるのかよって思う
サルじゃねぇんだから実現方法が複数でたらちゃんとメリットデメリット出して検討せなあかんよ
メリットなんていらんかったんや！
宗教だから信じるだけでよかったんや！
そうだよ。
メリット言い出すなら、所詮娯楽産業でしかないコンピュータゲームなんかに関わるべきではないし、
こんなスレにも来るべきではない。もっと有意義に自分の時間を使った方がいい。
もともと今が楽しけりゃそれでいい人たちの集まりなんだよ。
タスクシステムも、後々で楽しようってのは実態とはかけ離れた都合のいい言い訳で、
実際には妙案を考えるのが楽しいってだけの代物。
朝から寝言乙
タスクシステムではないゲームオブジェクト管理方法って何があるの？
単なるリストにタスクシステムなどという名前を付けるから笑われる
760 ：
名前は開発中のものです。：2011/11/09(水) 20:01:46.90 ID:BETkdj1i
タスクシステムって名前はやめてアクターシステムにでもすっか。
タスク＝ゲームオブジェクトな糞システムなら、アクターの方が正しい名前だな。
どっちかっていうと「システム」のほうがおかしいだろ。
タスクリストとかアクターリストならまだ意味が通じる。
実体がその意味に沿っているかどうかは別として。
>>762 ものすごくピンポイントで同意ｗ
いちいち「システム」などというから不思議なんだよな。
余計なコードを書く馬鹿
765 ：
名前は開発中のものです。：2011/11/10(木) 13:39:00.46 ID:mf//zsJw
システムは必須だろ！！ｗｗｗ
いらないシステム
アクターはアクターでアクター理論があるので、例によって10年後ぐらいに
禍根を残す気がするが。
しかもそっちは言い出しっぺの大先生が本家Wikipediaで我田引水しまくって
ブロックされたといういわく付きw
768 ：
名前は開発中のものです。：2011/11/15(火) 15:21:53.59 ID:NXG9Qx7w
アクタースク理論システムでいいじゃねえか。
アクターの場合は、タスクシステムで言うところの、
タスク=ゲームオブジェクト状態なのは決定なんでしょ。アクターって言うぐらいだし。
気の毒だね。
気の毒だねぇw
ただのコールバックがぶら下がったリストで、全く形式化も抽象化も考えられてない
シロモノなのに、そういう何の根拠もない権威付けに必死になるあなたが。
771 ：
名前は開発中のものです。：2011/11/17(木) 14:05:17.47 ID:l3TDlxQm
>>770ふむふむ、君のタスクシステムとはどんなもんなんだい？
>>770 挑発的な言葉は問題だが、タスクシステムの一般的な概念の説明としては今までで一番しっくりきた。
774 ：
名前は開発中のものです。：2011/11/18(金) 16:07:38.80 ID:XcNlMUga
アクタースク理論システムでいいじゃねえか。
Unityが扱っているシステムは何て呼ぶの？
あれがアクターシステムってやつ？
>>775 「Unityが扱っているシステム」と呼ぶのでは何が不満なの？
そもそもそれはほんとうに「システム」なんて呼ぶべきものなの？
>>776 Unityのモデルがウチで採用しているモノに近いので、一般的に何て呼ばれるのかが聞きたいんだけど。
別にXXXシステムと呼ばれていなくても構わない。
要するにタスクシステムってソフトウェアアーキテクチャのひとつなのかね
>>754 凄い共感できる。アクロバティックなアルゴリズム考えるの楽しい
中級者以上になると、タスクシステムの不自由さが鼻につくもんだがな。
だからこそ、ほとんどの上級者は口を揃えて、初級者はあんなもの
気にしなくていい、って言うんだろうな。
782 ：
名前は開発中のものです。：2011/11/21(月) 21:20:43.55 ID:njH+eGAB
「そんな物は気にしなくていい」だから俺の考えたフレームワークのタスククラスを継承してゲームオブジェクトを作る便利なシステムを活用してくれたまえ。
自称初心者じゃない奴の、デメリットバリバリシステムには閉口する。
そういう奴の下に付くお前が悪い
お前のこといわれてるのにｗ
手続き型言語のプログラムは変更、保守、再利用しづらい
いまはいろんな無料のフレームワークがあって、たった1日でゲームが作れちゃう時代
なるべく生産性の高いやり方がこれからのゲーム開発の方向性だと思うな
１日でゲーム作った気になる
プログラム部分は昔からそんなもんでしょ
結局アクターにしろタスクシステムにしろ業界内で慣習的にそう呼ばれてるって現実に
何かトラウマが刺激されちゃう子が火病ってるってだけだったみたいね。
「日本海じゃない！東海って呼べ！世界中が日本海って呼ぶのは間違ってる！」みたいな感じ？
いや、このタスクつーか
はじめに作った人間が定義するゲームオブジェクト（？）単位でできるスレッド（？）的なものが
ガッツリ開発するときに異常に邪魔になるって話
ゲームで本当に複雑になる部分はオブジェクト同士の関連であって
各オブジェクトを独立動作させる部分はそんなに難しくないって話
でも本来充実するべき環境はオブジェクト同士の関連の制御なのであるにも関わらず
基底部分の作り手はなぜか各オブジェクトを独立動作させることに重点をおいてしまって
関連の実装が異常に面倒になってしまう恨みごと
アクターとかタスクとかは聞くけど
オブジェクト同士の関連をサポートした機能は名前すら聞いたことはないよね？
って話
俺は別にオレオレタスクシステムでも関連の制御に気を配ってあればいうことないと思う
でもそれはそっちのけで変なゲームオブジェクト独立動作フレームワークみたいな無駄なもん作ってあると
かなりイラッっとくる
お前の脳みそはもういらんなｗって本人の目の前で言えるぐらいｗ
まぁ誰もが一度は通る（優秀な奴なら通らない）
中二の道ってことですなタスクシステムってやつぁ
斜め上の国の人が日本海で火病るのは彼らの哀れで惨めな歴史からくる歪んだ劣等感が原因だけど
タスクシステムって聞いただけで火病れる奇特な人は
＞はじめに作った人間が定義するゲームオブジェクト（？）単位でできるスレッド（？）的なものが
「僕の頭じゃタスクシステム（？）なんてまったく理解できません」って人が歪んだ劣等感から逆恨みしてるのが原因っぽいね。
で、どっちも劣等感からその現実を直視できない、と。
「日本海にしろタスクシステムにしろ、すでに名前が広まってるし。君たちの劣等感だけの問題でいちいち大騒ぎしないでくれるかな？」
というのが周りの反応、ってところも同じだな。
＞かなりイラッっとくる
＞お前の脳みそはもういらんなｗって本人の目の前で言えるぐらいｗ
まぁ、優秀な人間はタスクシステムみたいな小さな話にいちいちイラついて火病るような暇なことはしないわな…
ゲームで本当に複雑になる部分はオブジェクト同士の関連であって
こんなゲームオブジェクトの並列動作なんかじゃねぇってことは強調しておきたいね
相変わらずレベル低くてなにより
>>790 電子レンジで猫を乾かそうとするようなもんだなｗ
道具は目的に応じて使い分けましょう・・・
だがお前たちは言うのさ
「こッ、これがタスクシステムの力かッ！」
「なッ、なんで涙が出てくるんだッ！」
？涙にむせびながらな
注：「ッ」はGANTZのノリで
アーッ！、文字化けしやがったッ！
＞？涙
「？」部分は○の中に男
まぁタスクシステムみたいな古いやり方に固執するのは老害だけってことでＦＡだよね
タスクシステムってだけで火病する人には世界がそーみえるんだねぇ・・・
タスクシステムのやり方に固執してる人なんて見えない敵と戦ってご苦労なことで。
「日本人が日本海に固執してるのは帝国主義だからニダ！」っていわれたときと同じ感じだな。
別に日本海に固執してるって意識の日本人はいないだろ、そこは世界的に日本海と言われてる、
という客観的事実を言ってるだけで。
関係ないことを長々と書くけど注目したいのはここだよね
【ここ】
ゲームで本当に複雑になる部分はオブジェクト同士の関連であって
こんなゲームオブジェクトの並列動作なんかじゃねぇってことは強調しておきたいね
タスクシステムって存在自体にトラウマがあって火病してる人に
「オブジェクト同士の関連って本質的にタスクシステムと違うレイヤーの話じゃね？」
とか技術的な指摘をいくらしても馬の耳に念仏。
火病してる根本的な原因は技術や事実じゃなくて劣等感が原因だから。
斜め上の国の人に「帝国主義って本質的に日本海と関係ない話じゃね？」
って事実を言って「そうニダか！わかったニダ！」とはならないのと同じ。
劣等感から火病してる人に客観的事実を言っても
「日帝の陰謀ニダ！」「誰もメリット出せないニダ！」って火病ってまともに
話できなくなるところまでそっくり・・・
相手を韓国人とみなしたいという真理ｗ
ν速+に帰れよ
804 ：
名前は開発中のものです。：2011/12/19(月) 17:29:51.83 ID:QpVAtjMc
>オブジェクト同士の関連をサポートした機能は名前すら聞いたことはないよね？
メッセージシステムをみんな作ろうとしてたよ。
それだとオーバーヘッドが多くなりがちだから、大体はGameMasterに
参照してもらいたいオブジェクトを登録しておくことにして解決していると思う。
早い話管理オブジェクトに黒板を用意して必要な人は診ておいてねって方式だよね。
>>804 タスクシステム（笑）なネーミングはないよね？
806 ：
名前は開発中のものです。：2011/12/21(水) 19:24:17.78 ID:oDGPXJWH
>>805 タスクシステムの一部として実装されようとしていたからそれには名前がつかなかったんだよ。
まず、お前のタスクシステムを定義しろ
結局タスクシステムが正義でFA。
>>789 でループに入る前にexitしてるから以下全てデットコードじゃね？
Ａ「タスクシステムごときに火病るのは馬鹿」
Ｂ「僕、馬鹿なんで何言ってるのか分かりません」
一応会話は成り立ってるのか？ｗｗｗ
813 ：
名前は開発中のものです。：2011/12/29(木) 23:50:09.07 ID:Q5DloCDi
とりあえずタスク的な機構でギャラクシアンとか平安京エイリアンぐらいのゲームでも作ってよ。
それをベタ書き？で移植してみればいいじゃない
>とりあえずタスク的な機構でギャラクシアンとか平安京エイリアンぐらいのゲームでも作ってよ。
>>97 >>306 >>333 タスクシステムで作られたソースコードつきゲームなんて誰でも簡単に入手できるし選び放題でしょ？
「僕、小学一年生だからお小遣いじゃ買えません。それに僕の頭じゃ何書いてあるか分かりません」
とかでも無い限り。
タスクシステムか、懐かしいな。
でも今時タスクレベルでフルスクラッチってあんまり使う機会無いんじゃないかな。
今からやるならUnityでGameObjectの使い方でも学んだほうが有意義なような。
結局ミドルウェア使ってもそこら編が気持ち悪いならタスクシステムを自前で実装する事になるんだよね。
PSPとかDSレベルの旧世代携帯機だと、最新のミドルウェアが動くといっても
ミドルウェア動かすだけでメモリ半分持っていったり速度的に話にならなかったりで
技術デモ程度なら動くけど製品作るレベルには使えません、ってケースが珍しくないからな。
PSPのゲームでタスクシステム使ったタイトルあったけど、あれはマスター週でも定時帰りできたほど
品質安定してたし、枯れたハードには枯れた技術が合うんでないかな。
>>817 その「タスクシステム」とやらはどんなもので、それによってどんな問題を解決あるいは
未然に防ぐためのものだったのか、聞かせてもらえまいか。
さぁ？作ったチーフプログラマがタスクシステム作ってどうにかした、言ってたけど。
あいにく別チームのプロジェクトなんでコードまで見てないから詳しくはしらんがそんな奇抜な
ことはしてないんじゃないかな。本に載ってるような一般的なタスクシステムかと思われ。
開発初期に既存のミドルウェア使うことも検討したけどそれではPSPで60fpsキープ必須と
ステージ中の読む込みはNGというそのゲームの要求仕様を満たせなかったそうな。
こっちのチームが徹夜してるところ隣チームの彼らが納期間に合ってマスター週に定時帰り
できてメーカーチェックも一発OK、だったらしいからその技術的判断は正解だったのかと。
それ本当にミドルウェアがタスクシステムに入れ替わって解決する問題か？ｗ
まぁ、そのチーフプログラマってのは変人といえるほど変わった人だけど
プログラムに関してはずば抜けてスキルの高い人でその点は信用できる。
彼がそのゲームの要求仕様には他の方法よりタスクシステムが適している、と
判断したんならたぶん正しい判断だったんじゃないかと・・・
事実ミドルウェアではメモリ不足や速度が出ない、という問題は解決されて
特にトラブルも無くゲーム完成したわけだし。
ところでタスクシステム使ったゲームが作られると何か問題ある？>820
俺は
>>820じゃないけど
タスクシステムがなんの役に立ったのかそれだとわかんなくねぇか？
？？？
役に立つ云々の質問の意図がよくわからんのだけど
タスクシステムっていったら普通はゲームオブジェの生存管理とか処理の定期的実行とか
に使うと思うが・・・何か違う話？
>>823 タスクシステムを使ったときと使わないときとで何が変わったか説明できる？
？？？
使わないときって？
タスクシステムの使い方の説明をしてほしいの？
すまんがマジで何を聞きたいのかわからないんですが...
>>825 タスクシステムを使ったときと使わなかったときとで何か解決した問題はあるかい？
827 ：
820：2012/01/08(日) 00:29:22.14 ID:ePcRrssD
>>821 > ところでタスクシステム使ったゲームが作られると何か問題ある？
？
さぁ？そもそも別プロジェクトだからMTGとかも出てないし
決定の経緯とか細かいことまでは知らんけど。
チーフが同期なので昼メシ時にそんな話しを聞いたぐらい。
ただ実力も実績もあるプログラマがそう決めてプロジェクト
が成功した、という事実があるだけ？
>>821 >ところでタスクシステム使ったゲームが作られると何か問題ある？>820
それじゃ大問題ニダ！
タスクシステムで火病ってるウリが馬鹿だと証明されてしまうニダ！
って問題があるんじゃｗｗｗ
？？
見えないニダ！聞こえないニダ！ｗｗｗｗ
>>828 おいおいｗ
そうやってなんでもかんでも「テキトー」に決めてるとそのうち痛い目にあうよ
タスクシステムをちゃんと評価するためには
タスクシステムを使って組んだときのソースと
タスクシステムを使わずに組んだときのソースを
見比べてタスクシステムが解決した問題をキチンと評価しなければならない
オブジェクト指向もそうだけど
こういう設計思想が仕様を解決することって実は０でしょ？
組まなければならない項目は１項目たりとも減ることはないわけで
ちゃんとこういうのしっかり評価しないとダメだと思うんだよねプロなら
いや、決めた人はちゃんとミドルウェアと技術検証した結果決めたんでしょ
俺は別プロジェクトだから詳細は知らされてないけど。
で、その結果成功したんだし問題ないのでは？？？
大問題ニダ！ウリの愚かさが証明されてしまったニダ！！！ｗｗｗ
哀れですなぁｗｗｗ
単発IDの言い訳まだー？ｗｗｗ
>>832 つーか、同じゲームを別の方法で書いて見ないとちゃんとした
検証じゃないって、そんなバカな。
そんな非効率なことしてるゲーム会社見たことねぇよ。言ってることが
あまりに現実離れしてて理解できない。
>>836 そんな大規模なもんはいらねぇよ
傾向がわかる規模で十分だろ
ちょっとは頭使えよ
タスクシステムみたいな枯れた技術の新規検証なんてそもそも必要性ないだろ
ミドルウェアの性能調査して使えなければ他の候補の中から条件にあうタスクシステムが
選ばれた、ってだけだと思うぞ？？？
「タスクシステム（？）なにそれ、使い方も有用性も僕の頭じゃ理解できなーい」
ってお馬鹿さんには必要なんだとよｗｗｗ
まぁ馬鹿すぎて自分で調べる能力が無いから「誰か俺にメリット教えてぇぇぇ（泣）」
って粘着してるけど。
過去ログみたらこのお馬鹿さんの笑える過去が見れるぞ！
「オブジェクト指向？そんなのセミナー詐欺！」とかｗｗｗ
まぁ、ゲームプログラマに変人は多いし変なこだわりもってるのも
珍しくないけど、プログラマとして選択肢を減らす方向のこだわり
はあんまり生産的でない気がするな...
何かタスクシステムと直接関係ないスレ違いみたいなんで去ります。
>>832 >ちゃんとこういうのしっかり評価しないとダメだと思うんだよねプロなら
メリット君は間違いなくプロじゃないでしょｗｗｗ
プロは問題なく完成させてマスターして成果出したらしいよ？君と違ってｗｗｗ
「メリット理解できない」って無能な人が使いこなして成果出してる人に何言っても説得力皆無
誰もそんなこと言ってないじゃん
ただ、導入するにあたってメリットもデメリットも知らないものを
ホイホイ入れてしまうのもどうかと思うぜ
って意見なんだけど
なにか間違ってること言ってるかな？
>誰もそんなこと言ってないじゃん
あれー？恥ずかしい過去は無かったことにしたいのー？ずいぶん弱気になってｗｗｗ
まぁ可哀想だから言わないでおいてあげるよｗｗｗ
結局タスクシステムもゲーム作成の手段の一つとして使えるときに使えばＯＫ。
タスクシステムってだけで火病ってメリット坊やは惨敗して居なくなりましたとさ。
でFAね。
ID:pICb4u7H
こいつだけスゲー場違いｗ
845 ：
名前は開発中のものです。：2012/01/08(日) 07:27:25.31 ID:47gceSkO
>>843 >結局タスクシステムもゲーム作成の手段の一つとして使えるときに使えばＯＫ。
別に煽らなくてもこれだけでいいだろ
>>843 >結局タスクシステムもゲーム作成の手段の一つとして使えるときに使えばＯＫ。
これの使用の有無を決定する際の判断の話をしてるんだけど？
仮にタスクシステムになんにもメリットがなかった場合は使わないほうがいいわけだよね？
横レスだが
下のように書いてあるがこれじゃ足らんのか？
＞既存のミドルウェア使うことも検討したけどそれではPSPで60fpsキープ必須とステージ中の読む込みはNGというそのゲームの要求仕様を満たせなかったそうな。
＞ミドルウェアではメモリ不足や速度が出ない、という問題は解決されて特にトラブルも無くゲーム完成した
＞決めた人はちゃんとミドルウェアと技術検証した結果決めたんでしょ
＞俺は別プロジェクトだから詳細は知らされてないけど。
>>847 明らかにタスクシステムだからできたことじゃないってかなりのうんこＰＧでもわかるだろそれｗ
それって悪魔の証明って言うんだって、死んだ曾じいちゃんが昨日言ってた！
＞ID:aiZ4RIv6
いつも思うんだけどよ、
タスクシステムの他にどんなやり方があるんだよ。
「普通に組む」とか抽象的でタスクシステム未満の出来そこない回答で、はぐらかすのは無しな。
抽象的にするのは、実装だけにしてくれやｗ
>>848 >>847の文面からすると「明らかにタスクシステムだからできたこと」になるが。
これが分らんのは、相当なウンコヒトモドキだなｗ
メリット坊やって重度のアスペなんじゃね？www
何それ？
ぜんぜん「明らかにタスクシステムだからできたこと」の否定になってないっすよ？www
負けを認めろよ。見苦しいぞwww
>>852 ＞タスクシステム未満の出来そこない回答で、はぐらかすのは無しな。
>>853 いや、大真面目だよ
逆にこれで何か困ることあるの？
>>853 あれ？よく考えるとその返答はおかしくない？
タスクシステムだからできたことの説明はまだなされていないし
>>852は
>>850の
>タスクシステムの他にどんなやり方があるんだよ。
への返答な
君の
>ぜんぜん「明らかにタスクシステムだからできたこと」の否定になってないっすよ？www
この文章自体はよくわからない
タスクシステムだからできたことは挙げられていない
挙げられてないんじゃなくて君がアスペだから理解できないか
負けを認めたくなくてはぐらかしてるのか、どっちなんでしょうなぁ
まぁどちらにしろ憐れですなwww
>>857 え？
じゃ、どこに「明らかにタスクシステムだからできたこと」が書いてあるの？
もちろん返答は
タスクシステムには△△という特徴があって
その特徴を利用して○○を実現できました
って返答になることを期待していいよな？当然
>>858 あ、俺もこいつそんな感じしたｗ
19:53:10に19:54:54ねぇ・・・何ともわかりやすいｗｗｗ
>>858 自己紹介乙！
泥棒は周りがみんな泥棒に見えるって言うけど・・・
もう少し工夫したら？
いつも追い詰められると単発IDで荒らすだけってワンパターンっすよｗｗｗ
>>856 ＞タスクシステム未満の出来そこない回答で、はぐらかすのは無しな。
メリットメリットってワンパターンな逃げしてないで
>>847 に逃げずに答えてみろよ屑。
まぁそれが出来ないからゴキブリみたいに必死に自演して逃げ回ってるんだろうがなｗｗｗ
あぁ、「僕の馬鹿だから理解できません」ってのは否定じゃねーぞ？ｗｗｗ
また逃げたかｗ
>>865 だからそれとタスクシステムとなんの関係があるんだよｗ
>>867 ・・・もしかして逃げてるんじゃなくて真性のアスペ・・・？
ほんとに理解できないの？
まじで
>>847が理解できないなら同情ものだが。馬鹿のふりしてるだけだよな？
>>858 意図的に結託してるわけじゃないんだがｗ
妄想へ・・・いや想像力たくましいなｗｗ
その想像力で、タスクシステムを使わないで、どんなゲームを作っているのか知りたいｗ
タスクシステムなんて所詮道具の一個に過ぎないよ。
そんなものでいがみ合う暇があるならどんな道具使ってもいいから
ゲームの一本でも完成させたほうが生産的かと。
結果を出せる変人は許されるけど、口だけの変人に居場所は無いよ。
871 ：
名前は開発中のものです。：2012/01/08(日) 21:29:06.98 ID:h+d0rp0g
>>852 そのやり方だと
RPGパートがあるアクションゲームとか
そこまで行かなくてもちょっと通常のゲームとは違うボーナスステージとか
作るだけで大変になりそうな気がするんだけど。
タイトル画面、メインのゲーム画面（状態や演出の変化があまりなく単純なの）、オプション画面
ぐらいなら何とかなるかもしれないけど。。
>>871 気がするだけだよね
やってみたことないよね
タスクシステムで組む地獄を知っていたら
引数書くぐらい本気でどうってことない
こりゃ真性アスペだな・・・
今まで何度フルボッコにされても「メリットォォォ（泣）」って粘着するのは
いたぶられるのが大好きなドＭなんだろうと思って相手してたけど・・・・
タスクシステムで上手くいった事例を突きつけれれても「そんなの地獄だ（泣）引数しか方法は無いんだ」
って現実逃避を繰り返す可哀想な真性君だったとはな・・・
まぁ君の頭が不自由なのは君のせいじゃないかもしれんからしょうがないけど、
悪いことは言わんからとりあえず病院行って医者に診てもらえ。手遅れになる前に。
あつものに懲りてなますを吹くというやつかね。
まぁ、まずい使い方したらタスクシステムは地獄を見るのは本当だけど
タスクみたいなプリミティブな技術はみんなそんなものだぞ。
技術を正しく使えなかったのならその技術を恨まずにどうすれば
正しく使えたのか、何が間違っていたのかを考えないといつまでたっても
同じことの繰り返しなんじゃないかな。
結局タスクシステムもゲーム作成の手段の一つとして使えるときに使えばＯＫ。
そして可哀想なメリット君は早く病院へ行きましょう。
でFAね。
メリット君の症状は精神科で診断してもらえば病名が付く症状だぞ。マジで・・・
たしかに可哀想ではあるな。
可哀想だけど僕は精神科医じゃないからどうにもできないんだ。
ごめんよメリット君・・・ｗｗｗ
逃げｗ
わざわざ宣言しなくてもいいから、行っておいで、病院に・・・
今日も出ない、とｗ
>>872 ないけど
昔就職活動用に横スクロールのシューティング作ったけど
その程度の規模でもベタで書くと見通しがどんどん悪くなって辛くなって来たから
途中で書き直した記憶あるけど。
君の方が作れる気がするだけなんじゃないの？
訂正。
＞途中で書き直した記憶あるけど。
途中でタスクシステムのような形に書き直した記憶あるけど。
>>885 サンプル画像見ただけでダメそうなのがわかるな
if文の中にだらだらと条件ベタで書いてるのなんて見てらんない
どういう条件なのか赤字で説明する前に
適切な名前つけた関数にパックしろよ
上にも下にも続いてるようだし
どうせでっかい関数にだらだらだらだらと
プログラム書いてあんだろ
同人でDL数10人ですか。中身も作りかけの未完成品、と・・・
何というか、同人で作り始めて結局完成出来なかったけど捨てるよりはコード公開して
「ゲームの作り方を解説」って言えば少しでも売れるかも、って感じですね。
サンプル画像のコード見る限り何と言うか・・・
上で出てたタスクシステムの載ってる本の整理されたコードにくらべて
素朴でいいですね。敵の種類分だけforが羅列してるところなんか
昔のベーマガのBASICとかHSPで作ったサンプルゲームみたいでアマチュアリズム
あふれるところとか。
って、え？何？わざわざ出張してきてまで出したタスクシステム未使用ってがんばってもこのレベルなの？
まさかこのレベルと比べてプロが作ったPSPの市販ゲームにダメ出しとか、さすがに冗談だよね？
いやぁ、なかなかユーモアのセンスありますなｗｗｗで？本当のコードはどこ？ｗｗｗ
>>886 >if文の中にだらだらと条件ベタで書いてるのなんて見てらんない
こんなのいちいち関数にしてたら一体いくつ関数作らないといけないんだ？マジで
>>887 >素朴でいいですね。敵の種類分だけforが羅列してるところなんか
これが一番だと思うよ
Ｃ＃だから体験版の実行ファイルを逆アセできるよ
難読化もかけてないから自分でもっとスマートに書けると思うならやってみれば？
んでＤＦ使って比較してみ？
タスクシステムがいかにくだらない機能かわかるからｗ
ちなみにＣ＃の逆アセの仕方わかんねーとかそういうのはもうお話からしないｗ
Taskやactor使わないとこんなスパゲティコードになって
結局ゲーム完成できなかったよ、ってサンプルでしょ、これは。
>>889 え？まさかマジだったの？
方やPSPでトラブル無く完成、方や同人ですら完成できず。でも優れてるのは同人の方って
頭大丈夫？
あ、大丈夫じゃないからいう結論になるのかｗｗｗ
>>891 そうやって逃げてないでタスクシステム使ってコード書き直してＤＦで比較してみろって
１０００行程度だから半日もあればできるよ
いかにタスクシステムがくだらない機能なのかわかる
ん？
>難読化もかけてないから自分でもっとスマートに書けると思うならやってみれば？
もしかしてこれ君が作ったの？
メリット坊や＝ＰＧぐま？
PGぐま：週休３日（土日水）、１５時定時の世の中を目指すおっさん
って・・・
うわぁwww
>>892 現実から逃げているのはどちらの方かなｗｗ
そこまで確信があって工数（半日）も見えているのなら、
サクッと「くだらない」方式に変換してみせて、
不毛なお前自身の闘病生活に終止符を打てばいいのではないかな？
ほれ、やってみ？ｗｗｗ
>>895 でも、それじゃ納得しないでしょ？
自分のタスクシステムでやってみればいいじゃない？
それともタスクシステムで組むと異常に面倒臭いの？ｗ
>>895 そうやっていつも逃げてて手を動かさないから
なにも見えてこないんじゃない？
なにかをやってみて判断したことないでしょ？
雑誌やネットでいいといわれる技術のほとんどは役に立たないんだから
自分で判断する目をつけないとダメだと思うよ
んでゲーＰＧにとってその初っ端はタスクシステムになっちゃうってだけの話
>>888 外部に見えてないファイルローカル関数だったり
privateな関数ならいくらあったって問題ないだろ
きちんとしてれば処理系の限界行く事もない。
ソースファイル数だって千や万単位の場合もあるのに
何言ってんの？
>ＩＴ業界を目指す御馬鹿な人たちへ
>くっそ、俺のことか！
>超つまんねーぞ、マジつまんねーぞ
>やめとけマジで
>しかも馬鹿になる
>人としゃべる機会少ないから人としゃべれなくなるぞ
>派遣ばっかだから生活の基盤がいっつもふらふらしてて
>結婚できねーぞ
>技術的にもつまんないからね
>プログラム組んでものを作る楽しさが・・・とかそういうの一切ないから
>そして夢もない
これ君の日記なの？
>>897 >>898 いや、そういうif文のカッコの中身をいちいち関数にするの？ってこと
そこに書いてあったほうがよくない？
>>899 そうだよ
んで俺等はマイクロソフトなどのライブラリ作成側じゃない
ゲーム部分なんてのは用意された機能を使う側だから汎用性なんて考えなくていいんだよ
エクセルのマスを埋めるようなプログラムスタイルが正解なんだよ
当然マスに同じ値は何度も入るだけど同じ値が入ってることを明確するほうが大事なことなんだよ
こういうの嫌ならライブラリ作成側にまわらないとダメだね
ゲームはあくまで使う側
エクセルのマスに同じ値が入ってることを無駄だといいはる奴はいないでしょ？
同じであることを明確にするのが俺等に必要なこと
>>900 ＞
>>898 ＞いや、そういうif文のカッコの中身をいちいち関数にするの？ってこと
＞そこに書いてあったほうがよくない？
そのプロクラムの例だと
赤枠の注釈がなければ俺には意味がわからないが
もし
if(プレイヤー.攻撃受付中か())
って書いてあれば俺でも意味がわかる。
（日本語なのは考えんの面倒いからな)
フラグ一個ぐらいの判定とかNULLかどうかの判定とかならまだしも
条件か2つ3つあるのにベタで書こうなんて発想はないわ
そういうのを可読性が低いって言うんだよ。
細かいところに気を使わないやつとは仕事したくないね。
仕事しなくてもプログラムだけ回ってくることがあるのが泣けるけど
>>901 >細かいところに気を使わないやつとは仕事したくないね。
だったら
これ↓ちゃんと書けば？
>if(プレイヤー.攻撃受付中か())
>って書いてあれば俺でも意味がわかる。
>（日本語なのは考えんの面倒いからな)
自分で言ったことも面倒でできない奴が何を言ってるのか？
実際は関数がもう一つできてしまっておき場所に困るｗって問題もさらにできるだろうな
そういう子ルーチンもちゃんと上流から追ってこれれば意味もわかるけど
お前のは基本タスクシステムのグローバルアクセスだから
なんかよくわからない関数がその辺に無様に散らばってるってソースになんだろｗ
んで引数で渡すのも面倒だからやらないわけで
タスクシステム使用とタスクシステム未使用の判断も面倒だからやらないわけだよね
君の性格をよくあらわしているじゃないかｗ
>>900 >そうだよ
メリット坊や＝ＰＧぐま決定なのね・・・
なんかルサンチマンあふれる日記でVIPPERのステレオタイプを絵に描いたような人物像ですな。
で、タスクシステム板で「メリットメリット」って荒らしてるＰＧぐまさん、超ぱねぇっす！www
敵はＡ.Ｂ.Ｃの3種類だけ、影響するのはプレイヤーとだけみたいな超単純なサンプルケースでも
「中がごちゃごちゃになってきたので分ける」みたいになってますが！
普通の市販ゲームみたいに敵種類数百でプレイヤーだけでなく敵同士とかその他オブジェと
影響しあう仕様だったらベタ書きとやらでどう作るつもりだったんですかね！ＰＧぐま師匠ｗｗｗ
taskとかactorならオブジェの”同時生存数”の線形で関連が増えるけど！
当然ベタ書きだとこれより少ない関連で処理できるんですよね！師匠ｗｗｗ
まさか数百の敵種類分のforを羅列ですか！？ｗｗｗ
┐(´ｰ｀)┌
>>900 何かこの理屈だとエクセルマクロも使うな、ってことになりそうだな。
結局プログラミングの技法論などただの水掛け論で
これまでの実績でしか語れないんだよな
>>896 ＞でも、それじゃ納得しないでしょ？
俺を納得させる工数を予想できていて、手順も熟知してるんじゃないのか？ｗｗ
＞タスクシステム使ってコード書き直してＤＦで比較してみろって
＞１０００行程度だから半日もあればできるよ
＞いかにタスクシステムがくだらない機能なのかわかる
ほれ、遠慮せんでええ。やってみ？ｗｗ
自分と向き合ってみ？ｗｗｗ
>>904 仮想関数でも使えば？
別に基底クラスがタスククラスである必要はないよね。
>>909 何いってるんすか！そんなの全然ベタ書きと言わないっすよ！
それじゃ名前が違うってだけで中身タスクシステムと一緒じゃないっすか！
ＰＧぐま師匠はtaskもactorもOOPも、みんなセミナー詐欺って言うほどの漢っすよ！
そんな軟弱なこと許してくれるわけ無いじゃないっすか！！
師匠ならベタ書きでタスクなんかかなわない書き方の奥義を披露してくれますよ！！ｗｗｗ
粒度が全然違うよ。
>>907 実績だぁ？
ちょっとPSPのゲームで使われて成功したり昔から色んなアーケードゲームで使わて実績あったり
何冊も解説本が出てたりするからって調子のってんのかぁ？
師匠は夢も技術もない、派遣で結婚もできない、人としゃべれな馬鹿で簡単なサンプルゲーム
一本すら完成できない、これまでの実績と言える物なんて何一つ無い男だけどなぁ
OOPとかいうセミナー詐欺に騙されてる世界中の軟派なプログラマとは格が違うんだよ！格が！まさに別格！
ちょっとこいつに見せてやってくださいよ！師匠！
ベタ書き一つで生きてきた本当の漢の生き様ってやつを一つ！ｗｗｗ
>>911 粒度とか言いだす時点で今まで主張してたことが間違いだって
言ってるようなもの。forで固定関数を引数渡しするベタ書きだから
バグだらけにならないんだろ？で、taskもactorもgame objectも否定
してたのに。
対象の問題に合わせて適応的に適当な粒度で抽象化することに意味がある。
一辺倒にtaskとかしたところで意味無し。
>>914 なんだと？それじゃあ
>>847を理解できずにケチつけてる師匠がただの馬鹿って言ってるのと同じことだろ！
師匠の悪口は許せねぇ！謝れ！師匠に謝れ！！ｗｗｗ
>>914 >一辺倒にtaskとかしたところで意味無し
上に上がってる例はちゃんと検証してタスクシステム採用した結果成果が
出てる例ですが。その事実を認められずに現実逃避したあげくに一辺倒に、
なんて見えない敵を妄想されても...現実から逃げているとしか。
>>908 は？
いや、君を納得させる結果は君しか出せないでしょ？
どうせこっちがどう組もうが文句つけるんでしょ？
さすがに次の１手はお前が打つしかないんだよ
さっさとやれよ
>>917 どこいってたんですか師匠！
師匠のいない間になめた連中が師匠の悪口言いたい放題ですよ！
さぁ、はやく
>>904 を師匠秘伝のベタ書きで解決して
こいつらを見返してやしましょうよｗｗｗ
>>917 まだグダグダ言って逃げているのか。
＞いや、君を納得させる結果は君しか出せないでしょ？
＞どうせこっちがどう組もうが文句つけるんでしょ？
要するに自信がない＝敗北宣言か？ｗｗ
繰り返しになるが、
＞俺を納得させる工数を予想できていて、手順も熟知してるんじゃないのか？ｗｗ
さっさと自分と向き合えよ？ｗｗｗ
>>919 そうやっていままで自分はなんの検証もしないで
技術を身につけたつもりになってただけのクズだろお前
だから実際に学んだ技術がどうだ？って言われると
いっつも検証を他人にまかせて自分では何もしない
てめーの納得するタスクシステムなんざてめーしか知らねぇだろ
どうして俺がわかるんだよ
馬鹿なこというな
>>920 ＞そうやっていままで自分はなんの検証もしないで
＞技術を身につけたつもりになってただけのクズだろお前
＞
＞だから実際に学んだ技術がどうだ？って言われると
＞いっつも検証を他人にまかせて自分では何もしない
ブーメラン乙。
＞まだグダグダ言って逃げているのか。
＞俺を納得させる工数を予想できていて、手順も熟知してるんじゃないのか？ｗｗ
＞さっさと自分と向き合えよ？ｗｗｗ
>>920 どうしたんですか師匠！
そんな言い訳はいいからはやくベタ書きの奥義でやっつけてくださいよ！ｗｗｗ
これじゃ師匠が逃げ回ってるみたいでめっちゃかっこ悪いですよ！
敵やら弾やらプレイヤーやら、所謂ゲームオブジェクトは型や用途ごとにリストに掘り込む。
コンテキストの必要な処理(状態を持った処理)も同じように型や用途ごとにリストに掘り込む。
メインループから各リストを参照して更新処理を実行する。
このとき、呼び出しの形態が仮想関数だったり動的関数だったりは、設計次第。
すきにすればよろし。
ただ、上記方式のタスクシステムとの相違点は、
・プライオリティー変数などによる、処理のスケジューリングが無い。
・呼び出し形式が自由。(引数自由。動的静的インライン等自由。)
一方で、描画やサウンドのようにスケジュール物や非同期物は、
ライブラリを使うか作るかして外部に追いやる。エンジンなどと呼ばれることが多いね。
なめるのもいい加減にしろよ?
それのどこがベタ書きなんだよコラ
そんなタスクシステムに毛がはえたみてぇなシロモノ
師匠の言ってたベタ書きと完全に別物じゃねぇか。ひよってんじゃねえぞコラ
どうしてもタスクシステム基準で考えちゃうんだｗ
そりゃ
>>885の方法で
>>904答えるのは不可能だからなぁ
そう逃げるしかないんだろうけど、タスクシステムとは
プライオリティや呼び出し形式が必須って謎ルールは
どこから湧いて出たのかね？出どころを教えてくれ。
師匠!このヘタレをしめてやってくださいよ!
こいつ師匠の最高奥義、ベタ書きを何にも理解してないっすよ！
って師匠！なに泣いてるんすか！どーしちゃったんすか！師匠!www
>>926 >普通の市販ゲームみたいに敵種類数百でプレイヤーだけでなく敵同士とかその他オブジェと
>影響しあう仕様だったらベタ書きとやらでどう作るつもりだったんですかね！ＰＧぐま師匠ｗｗｗ
敵種類数百ってデビルメイクライでもそんなにいないのに
>>927 いい加減ウザくなってきた
そこまで煽るなら自分の作ったものも出すべき
この板何も作らないのに口ばっか出すやつ多すぎ
pgぐまは知らないけどさすがに不快になってきた
タスクシステムっていやみさかい無く噛みついて、いざ論破されたら
みっともなくメリットメリットって荒らしてる人間が煽られて
泣きながら「おまぇの作ったものも出せよぉ」って・・・
惨めにもほどがあるね。自分から喧嘩売ってんだから完全な自業自得。
思い込みが強い。自分に都合のよい想像で現実を補ってきたんだろうな。
>>928 つまり謎ルールは自分に都合のよい妄想。
そしてどちらにしろ
>>885ではダメってことでFAになったね。
最近はVisualStudioの単体テスト作成するのに引数強制させられるけどな
スレが伸びてるから目を通したら腹抱えてワロタ
管見自慢もたいがいにしとけよとは言ったが、自称ハード屋師匠、これはあんまりだろ
PGぐまって2chの他のスレにも
>>885張って宣伝してんのな。
で3000円で売ろうとしてボロクソに言われて値段下げて・・・
タスクシステム使わないことが何のウリになってるのか知らんが
これほとんど詐欺じゃね？騙されて買った被害者が可哀想。
>>935 詐欺じゃないじゃん
タスクシステム使わない実装が見たいって需要があるんだから
>タスクシステム使わない実装が見たいって需要があるんだから
何がタスクシステム使わない需要だよ
>VisualC#によるアクションゲームの作り方を解説します。
>いままでゲームの作り方をチュートリアル式に解説した本がなかったため出してみました。
みたいにゲーム作成初心者を騙して釣っておいて
中身は未完成品の屑ソースで使ってるのは既にMicrosoftが開発中止してるC# Managed DX・・・
>まったく売れないｗ
>っていうか、いまよく考えると売れたら売れたで不安だわーｗ
>誰にもテストしてもらってないしねｗ
>しかも、俺Unity中だからそっち興味ねーしｗ
>Unityはじめたらまったく興味がなくなってしまってｗ
おぃおぃ、こりゃいくらなんでも最低すぎるだろ。
騙されて買った被害者が10人はいるみたいだし。
まじめにゲーム作ろうとしてる初心者が最初にこんなのに手を出したら
それこそ悲劇だ。
あれか？タスクシステムに噛みついて荒らしてたのはこれの営業のつもりだったのか？
>>937 動かないなら詐欺だけど
それは体験版で動作確認できるじゃん
体験版動かなかったら買わなきゃいいわけだし
ベタ書き師匠はUnityを使うようになった
これはもう彼の敗北宣言と受け取ってもいいよな
やたら伸びてて楽しそうだな、と思ったら昔ゲームエンジンスレに沸いた基地外が出張って来てたのか
メリット坊や＝ＰＧぐまに吹いたｗｗｗ
PG ぐまのレベルは超えたもの作らないと就職はできないね
シーン遷移やカメラワーク、3D技術含めて
いまだに2D作品作ってくる学生いるけどそんなんじゃ採用率ほぼ0だってわからないんだろうか
いや、そこは問題じゃねえよ。
2Dでもきちっと作ってあったほうが評価するし。
そもそも2D、3Dも先生が作った便利はミドルもどきを改造して作ってんだもん。
>>940 Unity上でベタ書きって・・・
>>885 とのアーキテクチャ上の共通点皆無じゃん
PGぐまのいうベタ書きってforと関数使うってだけの話だったのね。アホくさ
>>945 なにいってんだ？
updateに書けばちゃんとベタ書きできるだろ
俺の頭は高性能じゃねぇからあのイベント群を駆使してゲーム作るのは不可能なんだよ
>なにいってんだ？
す、すいませんっした！
Unityに夢中になってる師匠がUnityの仕組み使ってゲーム作れないほど低能だってことすっかり忘れてました！
師匠の頭のレベルを超えたこと言ってしまって申し訳ありやせんっした！師匠！www
数年後、Unityスレには「僕の頭で理解できるメリットは出ない、絶対にだ！」
と叫ぶPGぐまの姿があった…
ぷげらwwwww
>>943 今時のゲー専ではUnity課題に使ってるし、イベント使えずにベタ書きでしか作れないなんて
レベルの学生はそもそも卒業できんよwww
ま、仮にそんなレベルの学生がいたら、「お前将来こうなるぞ」ってこのスレ見せれば
正社員として雇ってもらえず、派遣で生活安定しなくて結婚もできなくて技術的にも
つまらない低レベルの仕事しかさせてもらえず、2chで荒らししてフルボッコにされる
哀れな男の末路って事例として反面教師にはなるかもね。
なんかすげーコンプレックスあんのはわかった
多分自分のことなんだな...
師匠、生きてる？
必殺技の「単発ID自作じえーん」「メリットォォー」をまた見たいなぁwww
>>953 師匠ってことはもしかしてゲーム買ってくれたんですかね？
まだバカが生きてたか
アンチ＝メリット坊や＝PGぐま＝馬鹿
ってことでFAか・・・
メリットを挙げられないタスクシステムはゴミ。
PGぐま
さすが師匠！Unityのイベント群も低脳には使いこなせないから
（師匠にとって）メリットの無いゴミですよね！ｗｗｗ
いいかお前ら！師匠は
＞俺の頭は高性能じゃねぇからあのイベント群を駆使してゲーム作るのは不可能なんだよ
ってレベルの低脳だからベタ書き以上の複雑なことは認識できないんだ！
難しいメリットは無効だからな！
今までの挑戦者は普通の頭の人間が理解できる程度のメリットしか出してねぇ！
それじゃ師匠の限られた脳みそでは理解できねぇんだよ！
さぁ！師匠の頭でも理解できるメリット出して見やがれ！
これが完全無敗の師匠の最高奥義！「メリット」だ！！！ｗｗｗ
>>959 師匠ってことはもしかしてゲーム買ってくれたんですかね？
今まで2chでいろんなアンチを見てきたけど
こんなに一方的なアンチ惨敗は初めて見た
ここまで馬鹿なアンチは2chでも珍しい
え？ｗ
一本釣り乙
一匹しかいない生け簀で入れ食い状態ｗｗｗ
は？
もうやめて！くまちゃんのHPはゼロよ！ｗｗｗ
タスクシステムのメリットは出てないけど勝利を掴み取ろうと手ごろな相手を見つけた感じ？
この流れなら技術的な話にはなりそうもないし、都合がいいんだろう。
見苦しさは増すばかりだからこれでいい。
どうしてタスクシステムのようなメリットの見えない技術を崇拝してしまうの？
見えない相手と戦ったり、何かとそういうのが好きなんだろ。
何かを自分の都合のよいように想定して得意げになってしまうことが。
このお馬鹿さんがtaskやactorやeventやOOPを使えないのは、メリット云々は関係なくて
＞俺の頭は高性能じゃねぇからあのイベント群を駆使してゲーム作るのは不可能なんだよ
ってのが理由だからなぁ・・・
普通のレベルの人間なら理解できるメリットの話してもこのお馬鹿さんから見たら
「（僕の低能な頭では）メリットの見えない技術」で終わるのはさんざん既出だし。
で、普通の人ならなら「僕の頭が悪いから理解できません」で終わる話だけど、彼の頭の中では
「僕には理解できない。でも僕は馬鹿じゃないはずだ！taskやactorやeventやOOPはセミナー詐欺だ！」
となってしまう、と。普通の人から見たらその理由も明白だけど。
>>972 じゃあ、タスクシステムのメリットを説明してみろよｗ
君の頭の性能ではtaskもactorもeventもOOPもメリットは無いよ。
よかったね、正しさが証明されてｗｗｗ
おうちに帰ってママに「裸の王様」でも読んでもらいな。くまちゃんｗｗｗ
>>974 ハハハｗ
説明できないぐらいすごいものなんだねｗ
ACMやIEEE CSに、アクターの論文もオブジェクト指向の論文もイベントドリブンの論文も山ほどあるが、
「タスクシステム」の論文があるとは聞いたことがないな。
リアルタイムOSのタスクについての論文も山ほどあるが。
>>974 > 君の頭の性能ではtaskもactorもeventもOOPもメリットは無いよ。
なんかしらんが一緒にすんなよｗ
actorとイベントと、とくにOOPに謝っとけよｗ
基本的にフレーム単位の同期処理が前提のゲームにタスクシステムとかいらんだろ。
リストやポリモが無かったら、ああいうものにも立場はあっただろう。
ポリモなんかいい機能だと思ってるうちは一生初心者のまま
オブジェクト指向なんていらないと思っている、って初心者を脱してない証拠だよねー
>>981 はて？
ぶっちゃけ、大真面目な話、本気でなんの役に立つのだろうか？
理論的に説明できる？
>>983 そうやってすぐ逃げるところとかタスクシステム信者っていつも卑怯だよな
>>985 どこに利点が書いてあるの？
特徴だけだろ
チューリング完全なら皆同じ 厨、系のバカかな？
そんなことよりも、ほとんどの処理が一フレーム毎に同期するゲームプログラミングで、
タスクシステムのような仕組みが本当に必要なのかどうか、だろう。
俺もタスクシステムのような擬似マルチタスク的なことをすることはあるが、
その場合は、からなずといって良いほど、処理完了時間が明確でないような、「非同期」な処理に対してだぞ。
>>988 「タスクシステム」とか「タスクシステムのような擬似マルチタスク的なこと」とか、
何のこと言ってるのかよくわかんないからコードで示してくれたほうが実りのある
回答がもらえる可能性がいくらか高くなると思うよ。
>>989 それカプセル化の利点だよね
頭おかしいの？
>>991 リンク先数行くらい読めよｗ
> オブジェクト指向プログラミングとは ... 一般的に以下の機能や特徴を活用したプログラミング技法のことをいう。
> ・ カプセル化 (振る舞いの隠蔽とデータ隠蔽)
> カプセル化（カプセルか、encapsulation）とは、オブジェクト指向を構成する概念の一つ。
>>992 え？
だからオブジェクト指向の利点は？
非OOPLでもカプセル化できる、の話ならもう聞きたくない…。おなかいっぱいだ。
>>993 理論的にとか言い出したやつがこれだよ。もう知らん。
>>995 だって書いてないじゃん
いままで君のまわりは君が大好きな人間ばかりの集まりだったんだろうけど
俺はそうじゃないからわざわざ君の言いたいことを組んでやる義理はない
しかもそれだと
カプセル化＝オブジェクト指向
みたいでカプセル化さえすれば他のメリットはないの？
って感じじゃん
したらまた違うって付け足しをはじめるんだろ？
それをこっちを汲んでやる義理は１つもないよ
言いたいことがあるなら自分の言葉で説明するべきだろ
逃げだの何だの言ってレスさせるのは
馬鹿な荒らしの常套手段だから無視するべき
そういうやつは自分の非を認識できないから
延々と噛み付きつづける
分かった上で構ってるなら別に良いけど
ところで誰か次スレ頼む
隔離スレが無くなるのは困る