3 :
名前は開発中のものです。 :2009/02/02(月) 06:56:14 ID:lhNqT94l
前スレで判明したことだが
>>1 だけが異様に初心者でおまけに日本語が不自由で
一人だけ言っていることのレベルが低すぎて無駄な議論をすることになる。
ゲ板は
>>1 のための日本語教室ではない。
よって我々はこのスレは放棄する。
■■■■■■■■■■■■■ 終 了 ■■■■■■■■■■■■■■■■
4 :
名前は開発中のものです。 :2009/02/02(月) 07:37:01 ID:P5kryGXr
ありゃりゃw うわーん!もうこねぇよ!的書き込み? 前スレでとっちめ過ぎたか(笑) 強くイキロ
初心者でも日本語不自由でも構わないが、そのことを全く無自覚なのが致命的
>>3 俺も同感。こんな基地外の面倒見切れねぇ。
■■■■■■■■■■■■■ 終 了 ■■■■■■■■■■■■■■■■
埋めてみる
さすが
>>1 さん。
>タスクシステムはごった煮ソースになるので
>ほぼ全クラスを一括インクルードしなければ動かないとかかなり糞
とか他の人と言うことが違う。
憧れるわ〜。
俺のヒーローインタビューがまだ続いてるのか
まあ、数人のタスク信者を2人で撃退したからね当然といえば当然だな
忘れないように前スレの勇姿を貼っておこう
http://pc11.2ch.net/test/read.cgi/gamedev/1226199100/824-974 824 名前:名前は開発中のものです。[sage] 投稿日:2009/01/31(土) 02:30:33 ID:2y83CUUn
デザインパターンで安全にタスクシステムを構築できるということについて
具体的に否定できるヤツは一人もいないなw
ファビョって否定してるやつが数人いるようにみえるがID変えてるだけのアホが一人なんだろうな。
826 名前:名前は開発中のものです。[sage] 投稿日:2009/01/31(土) 02:44:15 ID:rIovvj90
>>824 安全には無理でしょ
明示的な引数がない時点でプログラムの作法云々なんてもう
気にしない組み方だと思うけどね
update();
で動くのと
update(jiki,teki,tama,unko);
で動くのとじゃ
プログラムとしては絶対に下のがいい
上は結局、その関数で何が必要なのか要素がまったくわからない
アクセスしているものを知るには中身のプログラムを読むしかないし
■■■■■■■■■■■■■ 終 了 ■■■■■■■■■■■■■■■■
このスレはすでに終了しています。
糸冬了
>>13-16 お前もしかして1人でやってんの?(笑)
でひゃひゃひゃひゃw
ひとりでやってるよ
このスレは俺が粘着してるから他のスレで楽しんでください。
>>12 > まあ、数人のタスク信者を2人で撃退したからね当然といえば当然だな
お前には、自分が撃退されることもわからないのか。こんな基地外珍しいな。
ID:cShVBku0がコテになるっていうなら俺は消える。 そしてコテになったら即あぼ〜ん設定してあげるよ。
IDあるんだからさっさとあぼーんしろよw そしたら前スレの俺の武勇伝をあることないこと脚色して書き込むからさw
IDあぼ〜んしちゃったら何がなんだかわからなくなるじゃん
まともに議論したいんだったら、mixiとか使って 基地外は排除しちゃえばいいんじゃない。
よーしじゃあmixiに移動だ でどこ?
>>12 数人っていうか1人のように思う。
それと、疲れちゃったプログラマをからかい続けるのは感心しない。
そろそろやめとけば?
なんか効き目が強い。多分本当に病気だ。
それでもやっぱタスク使ってて何か引っかかるものがあるからこのスレに来てるんだろうし
■■■■■■■■■■■■■ スレ主が真性基地外であることが発覚したため終了 ■■■■■■■■■■■■■■■■
>>27 いいんだよ
そいつの次の成長なんてタスクシステムを捨てた先にあるのは明らかなんだから
それに他の初心者がこんなもん妄信しはじめたらどうする
それに程度の低い書籍の悪影響もあるだろうな
ベタ書きを極度に馬鹿にするあまり
書かなければならない処理があるということの説明を怠った
独学ばっかりしてて会社でも誰ともやりとりがなければ誰にも指摘をうけないだろうな
前スレで引数の話を始めにしたが
引数が無い関数のがよく見える
とか言い出しやがった
明らかにレベルが低いというか危険レベルだろ
オブジェクト指向云々の前になぜプログラム言語が制限をつける形で成長してきたのか?
そこからすでにわかってねぇそんなレベルだった
型ってなんで必要なのか?引数ってなんであるのか?グローバル変数ってなんでダメなのか?
そういうところを一つ一つ考えなおさなきゃ次へいけないだろ
俺の周りにはたまたま教えてくれる人間がいたんだけどね
注意!!
>>29 = 真性基地外のため、初心者は騙されるな!!!
32 :
名前は開発中のものです。 :2009/02/03(火) 19:50:07 ID:+ZtfpvwK
>>32 どうせなら前スレでボコボコにされたタスク信者のために
明示的な引数の記述についてもコメントしてあげればよかったのにw
20090203とか今日だしよw
どうせみてんだろ>やねうらお
>>32 >それではタスクシステムは現代においては不要なのかというとそうでもなく、
>成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
> 「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり(以下略)
現代的に仕立て直しても有用性がデバッガの存在という1点のみか。
まずは一番最初にデバッガ完成させないと有用じゃないんだな
や ね う ら お、はじまったな!
ここは空気読んでたすくしすてむはクソだ!って言っとけばいいのか?
>>31 コルーチンライブラリだね。コンテキストの保存と切り替えしてるね
Win32APIのFiber
protothreads
Luaのコルーチン
Squirrelのスレッド
などなど
これらに相当するものでしょ
>>40 >名前が悪いと怒られないか心配だなw
それは大丈夫じゃないかな
複数のジョブを協調的に並行処理・逐次処理する仕掛けになってるから
ユーザーはプログラムの中にsleep()とかを挟みこむだけでおk
job()
{
while(1)
{
…
sleep();
foreach(…){
…
sleep();
}
…
sleep();
}
}
sleep()とかを挟みこむだけでライブラリが半自動的にタスクに分割してくれる
コンテキストの保存と切り替えを全部面倒みてくれる。スケジューリング機構も
一応入ってる。
>>2 とは雲泥の差だよ
>>41 そこはただの軽口だから、そんな真面目に説明されてもね
つか君はコルーチンを説明するフリをして
>>2 をけなしたいだけだろww別にけなしていいけどさw
まあストラウストラップ先生の書いたクラス群はシステムの名に値するみたいだし
今度からコルーチンシステムと呼ぼうかなー
関係ないけどやねうらおは絶対ここチェックしてるよなw
やねうらお対ひらしょータスク戦争勃発w
やねうらおはこんな場末のスレ、見てないだろ
>>32 は、前スレまでの議論よりずっとずっと先を行ってるから
彼にとってはこんなスレ、見る価値もないんでねーの?
さすがにこれは天晴れと言わざるを得ない
>>43 みてないとか嘘だろ
だって「ごった煮」とか前スレ特有の言葉だしてきてるし
わざわざ見てますよアピールしてんだからかまってやれよw
でも前スレで話題に上がった引数に関して触れてないのはいただけないな
無視なら「そんなもんは無視」って名言してくれるだけでもスタンスわかっていいんだけど
別にいい悪いも正解不正解もないわけだし
>39 protothreadはコンテキスト保存してないよ。
>>32 親切心から、敢えてコメントさせてもらうと・・・
アマチュアゲームプログラマ未満だな。
まともにゲーム製作を経験した人間が書いた記事とは、到底思えない。
これ誉めちぎっている奴の狙いって何なんだろ。
一部の明らかにテンションが違う応援団は、スルーするのが基本なのか?
ほめちぎってる応援団なんてどこにいるんだ
やねう先生の近代的なタスクの話を読んでみたけど、 boost::shared_ptrとかunordered_mapとか実装が近代的というだけで、 やってることは古典的だよね(そういう趣旨だから当然だけど)。 ってことで、Mix-in好きのオレが近代的なタスクを考えてみた。 古典的タスクシステムをupdate巡回リストであると仮定すると、 タスクとはすなわちフレームをまたいだ継続的処理の抽象化だと考えることができる。 継続処理を今風に考えれば以下の3種類に分かれるはずで、 どれが良いかはケースバイケースで異なる。 //(1)毎フレーム呼ばれる古き良きタスク(負荷が小さい。排他処理不要) class PeriodicalTask { public: virtual void update() = 0; }; //(2)コルーチン動作するタスク(負荷は中程度。排他処理不要) class CooperativeTask { public: CooperativeTask(size_t stackSize); virtual int call() = 0; }; //(3)ネイティブスレッド動作するタスク(負荷が大きい。排他処理必須) class PreemptiveTask { public: PreemptiveTask(size_t stackSize); virtual int start() = 0; };
ここでは描画オブジェクトとタスクは無関係だと考えて、以下のクラスを用意する。 無関係とするのは、描画オブジェクトが必ず継続処理を必要とするわけではないからだ。 //描画オブジェクト template <class DrawContext> class DrawingObject { public: virtual void draw(const DrawContext& dc) = 0; }; 描画用リストは CompositeDrawingObject クラスが管理する。 インターフェイスは自明な気がするので省略。 さてゲームの主人公マリオをどう表現するかというと、 //マリオ class Mario : public DrawingObject<DrawContext2D>, public PeriodicalTask { public: void draw(const DrawContext2D& dc); void update(); }; このようにMix-inして作る。ここでは PeriodicalTask を Mix-in したが、 マリオの継続処理を CooperativeTask でコーディングしたければそれを選んでも構わない。 PreemptiveTask を選ぶのは明らかにオーバースペックで排他処理が面倒になるが、 やりたければそれもまあ可能だ。
タスクと描画オブジェクトが無関係な理由はもう一つある。 例えば以下のように、描画オブジェクトでなくても継続処理をしたい場合があるからだ。 //テクスチャ画像を波打たせるトランジション class RippleTextureTransition : public TextureTransition, public CooperativeTask { public: int call(); }; とまあこんな感じはどうだろう。モダンっぽくね?
1,2,3を混ぜたい時はどうするんだ? 単一の巡回呼び出しでは呼べないぞ、それじゃ。 というか、3は明らかに不要だろ。 taskの更新処理は1と2以外にないだろ。
>>49 何か勘違いしているように思える。
(1)に限らず、(2)でも(3)でも毎フレーム呼び出されると思うのだが。
>53 3は論外だが、普通に実装すれば1と2はきちんと呼び出し元に帰るから問題ないんじゃね?
>>54 (2)は、1フレームごとに呼び出し元に戻らないのか?戻らないとしたらいつ戻るんだ?
そもそも1フレームごとに呼び出し元に戻すためにcoroutineにしているんだろ?
わけがわからん…。
>>52 単一の巡回呼び出しですべて巡回させる必要はないと思う。
もちろん共通のタスクプライオリティを実装して単一巡回にしてもいいのだけれど、
ここではタスクの呼び出し順序に依存しないコーディングを前提としてみた(3はそもそも処理順序を付けられないし)。
んで、今までの慣例的なゲーム開発手法で考えると確かに3は使わないように思えるが、
これから先の開発手法(MTフレームワークとか)もにらんだ話であるし、
「タスク=フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。
ただ、現状では貴重な資源であるネイティブスレッドを本当に他と同列に扱えるかというと難しいとは思う。
>>53 いや、3はただのスレッドだよ。2は、なんかごめん。確かに混乱するかもなこれ。
call() は毎フレーム(コンテキスト差し替えの上で)呼ばれる関数で、call() の中では yield し続けると思ってくれ。
>>56 毎フレームcallが呼び出されるなら、結局呼び出し側(タスクシステム)からしてみれば、
単なるメソッド呼び出しなわけで、その実装の詳細(coroutineで書かれているか/いないか)は
どうでもいいのでは?
だから、(1)と(2)でinterfaceを変更する意味がわからない。
どう見ても共通のinterfaceで良いように思える。
>>56 > 「タスク=フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。
についてだけど、タスクはフレームをまたぐが、少なくとも1フレーム以内に制御はいったん呼び出し側に
戻ってこないと困ると思うのだが。
ID:9DTLfrVWは何かここを勘違いしているような気がする。
そもそもスレッドを割り当てるのは、呼び出し側で制御すべき問題であって、
スレッド一つ割り当てて実行させたいからと言って呼び出される側のタスクが勝手に
スレッドを作っていいわけではない。
ここまではわかってる?
>>58 んー、古典タスクの定義にこだわりすぎだと思うんですが
あくまで近代的タスクという思考実験なので・・・
暇な時に簡単な参考実装でも作ってみようかな
>タスクは(略)1フレーム以内に制御はいったん呼び出し側に戻ってこないと困ると思うのだが。
1と2は戻ります
3は戻りませんが、ユーザプログラムはそれを分かって3を使うわけなので困らないと思いますよ
>そもそもスレッドを割り当てるのは、呼び出し側(タスクシステム)で制御すべき問題であって、
スレッドの割り当てはユーザプログラムが制御すべき問題であって、
呼び出し側(システムプログラム側)ではない、という考えでこうなっています。
MTフレームワークではシステム側で各スレッドにタスクを振り分けて負荷の分散を
行っているらしいのでそういう場合は仰るとおりですが、
それを前提にすると1と2も排他処理必須になるのでちょっと複雑になりすぎるかなと。
>>59 > 3は戻りませんが、ユーザプログラムはそれを分かって3を使うわけなので困らないと思いますよ
戻らないということは、そのスレッドは呼び出し側で生成したスレッド
そのまま使い切ることになるのだから、「呼び出し側(システムプログラム側)では
ない、という考えでこうなっています」と明らかに矛盾してるんだが。
CreateThread()というAPIがあるとして、誰がCreateThread()を呼ぶかと言う話なら それはシステム側になると思いますけど、 作成タイミングもスタック容量もユーザプログラムが制御するのだから別に矛盾してないと思いますよう それより、なんか疑問点を出されているというより粗探しをされている気がする どうして突っかかられてるのかが分からないなあ
>>61 粗探しをしているつもりはないので、疑似コードなり何なりを出してもらえれば
協力はさせてもらうが。
threadというのは生成に時間がかかるものであって事前に作ってpoolingして
おくのが普通であって、stack sizeなんか都度指定されたらpoolingしている
threadが使い回せない。
つまり、(3)でスレッドを割り当てて欲しいときにstack sizeの指定はいらない。
タスクシステムからのupdate呼び出しのなかでスレッドを割り当てて欲しいときに
threadPooler.Run(boost::function(&MyClass::Worker));
とするだけのことではないか?
だから、(3)を、普通のタスク(1),(2)と区別する意味が俺にはよくわからないのだが…。
とりあえずどんな問題を解決したいのか明らかにしてからコード書いてください。おねがいします。
>>62 なる、プールされたスレッドってのは考えてなかったです
例に挙げられたコードも分かりやすいと思いますが、
とりあえず
>>49 の方向でそうした実装を取り入れるなら、
PreemptiveTask のコンストラクタがスタックサイズを引数に取らないようにして、
内部的にプールされたスレッドを使い回すようにすると良さげかもですね
それか、必ずプールされているのも都合が悪いことがありそうだから
PooledPreemptiveTask のような新しいクラスにそうした実装を組み込むか
とりあえず、その辺はより実装に近い部分なので、ゆっくり煮詰めていくたぐいの話ではないですかね
1、2、3をそれぞれ区別するのは、使い手側から見た時に混同せず
明確に区別すべきものだからです(コーディング方法もそれぞれ異なるし)
>>62 はシステム側の都合から見てるから区別不要に思えるんじゃないかな
>>63 え、おれ?ごめん
ということですいませんが、そろそろ寝ます
敗北宣言
65 :
名前は開発中のものです。 :2009/02/05(木) 03:50:41 ID:MYSEarFY
やねうらおの方からきますたw まあ、ゲームオブジェクト管理周りをどうするかは作るもん次第、銀の弾丸なしってことで、 それはプログラマの仕事がなくならないってことで、いい話なんじゃね。
やねも昔ほど強く言わなくなってるな 実は必要無いってもう気付いてるな そもそもタスクシステム、コーティングの手間しか削らない割に記述の複雑さは一級品だからな ベタガキで誰でも読めるソースになるならそのほうがいいだろ 長い期間強く組む為には構造は単純でないと駄目なんだよね
>64 1,2,3を混ぜて巡回呼び出ししたい場合というのが存在するから、同一I/Fから呼び出せないと困るぞ。 例えば、全てのtaskにコンテキスト保存が必要では無い場合に一部taskは1で作成するとかな。
>>32 現代じゃなくて近代なのか。ずいぶん遠慮がちに書くのだなぁ。最初から後退戦か
敗北主義を匂わせれば、相手は正面から斬り付けるのを躊躇うはず、という計算が
見え隠れすんなぁ
>いまの視点(2009年)で見たときに拙著(ASIN:4798006033)にて不足している部分を補足するため
今までは利得がどこにあるのかを決定的に見誤っていた、と白状したほうが高感度アップな
>成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
>「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり
それにしてもタスクフレームワークとか鼻クソみたいな造語を作るの好きな人が多いな
ビデオゲーム開発のためのフレームワークなんだろ?
ビデオゲームというのは何かしらの時間ステップで何かしらの逐次処理(数値積分など)を
繰り返すもの。そしてその処理は複数。だから並行処理ないし並列処理することになる
どんなものであれ、その内部でジョブステップ(タスク)が駆動するなんて当たり前のこと
ありふれたこと。むしろないほうがおかしい
なのにビデオゲーム開発のためのフレームワークの看板にタスクを掲げる
つまり【タスク】が他のフレームワークには存在しない特徴でありウリだと思い込んでる
タスクというキーワードに何か特殊な意味・特定の実装(
>>2 とか)を連想し、それ以外は
タスクではない、という視野狭窄・自己中・ド田舎ルール・カルト信仰が見え隠れするね
つまりタスク厨
タスクというキーワードに対する思い入れの強さ。これは
>>2 、松浦本ベースの劣化
トンデモ情報による刷り込みがやねうらおにも及んでいた可能性を示唆する
何と戦っているんだ?
>>32 >現代において、タスクシステムを実装するなら、もう少しタスク間通信を抽象化してタスク側から
>タスクシステムが保持しているlistには直接触れないようにするべきだが
今度は近代じゃなくて現代なのか
はっきり言っちゃうよ。それは時代ではないんだよ。それは開発規模に応じた普遍的な要求なんだよ
例えば大所帯でRPG作るとき、みんながジョブエントリ・タスクエントリのコンテナに直接触れたらどうなる
わかるよな?
15年以上前にはビデオゲームの世界にさえジョブモニタやタスクモニタといったものが存在した
これは汎用機や組み込みシステムのモニタやOS(RTOS)が大昔に進んだ道を踏襲しているに過ぎない
32bit機が登場した頃には中堅どころでさえブクブクと膨れ上がるゲームのボリュームに汲々としており
ジョブを記述するユーザー(スクリプタ含む)にジョブエントリやタスクエントリのコンテナへの自由な
アクセスを許可するなんて蛮勇以外のなにものでもないケースは珍しくなくなっていた
一定以上の規模になればユーザーを中枢から隔離するなんて時代を問わず当たり前のこと
CだのC++だのアセンブリ言語だの関係ない
これを【現代】の流れというなら、それはやねうらおの内なる世界における歴史的系譜を辿る際に
現代の1ページに登場するとある事変に過ぎず。やねうらおの個人的出来事に過ぎない
『やねうらおの歴史 〜やねうらおの近代そして現代〜』というタイトルで出版したほうがいい
みんな買うよ
ID:tABpRsfLはなんでそんなに日本語が不自由なの?
タスクというキーワードに対する思い入れwww
やねが今回タスクシステム(なにそれ?)を語りだしたときに それがどういう規模のゲーム開発のお話なのか、という部分には 一切言及しなかったよな この手のお話には必須の大前提なんだけどバサーリ省いた あらゆる規模にタスクシステムとやらいうものが適用するメリットがあると 考えてるんだろうかね もうこの時点で彼のタスクシステム(はぁ?)論は敗北確率急上昇だろ とても残念だ 少人数・ないし一人のプログラマによる小規模開発ではベタ書きのがいい 彼の言うタスクフレームワーク(あ?)とかいうもの。こいつを構築するために 支払うイニシャルコストがペイできる分岐点ってもんがあるわけ やねはここを見積もってないんだろうね
誰と作るのか。何人で?そいつらの戦闘力はいくつ?期間は?実装対象は? 開発機材は?既存のライブラリとかのリソースは?買っていいの? こういうファクターを丸無視してコーディングスタイルとか設計の是非を語ろうったって 解なんて出やしない。だからやねがエロゲ作ってるならエロゲ話のことだと言えばいいんだよ PC用3Dエロゲにおけるタスクシステムの有効性について とかな。あ、3Dは駄目なんだっけこのオッサン
76 :
名前は開発中のものです。 :2009/02/05(木) 22:06:28 ID:Kri4Crxo
やねうや夫は2Dオヤジだから一般化して語れないぞ あとゲーム専用ハードのゲーム開発経験もないんじゃないかな
やねうらおさんってコンシューマ畑とも縁遠いのか。それは失礼した DSで死にそうになってるフェードアウトハゲが10年単位の周回遅れで 発明した独自理論を得意げに語ってるのかと思ってた エロゲの人ならこういう発見もアリなんじゃないかな。煉獄へようこそ
>>36 前々スレから散々におわせていたことをようやく認識した
ということだろうね
IDだのハンドル云々の話は10年近く前にファミベのよっしんが記事を書いてる
http://www2.tky.3web.ne.jp/~yosshin/memo/000213.html アーケードやコンシューマと無縁なやねなら確実に読んでると思うんだけどね
参考リンクとして貼りゃいいのに
よっしん氏が呼んでるタスクシステムという代物と
>>2 は同一ではないよな
>>2 はタスクリストとかいうものを周期的にナメまわしてバッチ処理するだけ
「はいこれでオシマーイ。あとはお前らにお任せだっよーん」みたいなゴミカス
最近じゃこれだけでタスクシステムってことで通用するんだから
タスクシステムはタスクの相互作用なんて気にする必要まったくないわけ
変な通信機能盛り込むなよ
>74 > 彼の言うタスクフレームワーク(あ?)とかいうもの。こいつを構築するために > 支払うイニシャルコストがペイできる分岐点ってもんがあるわけ > やねはここを見積もってないんだろうね 逆に、一人で開発してるなら何やってもイイと思うけどね。
>12 > update(); > で動くのと > update(jiki,teki,tama,unko); > で動くのとじゃ > プログラムとしては絶対に下のがいい 普通に考えると、visitorに共通コンテキストを持たせてコンテナ内のタスクを巡回処理させる。 引数で渡すなんて愚の骨頂。
>>81 引数のない関数ってどうよ?
お前、自分が使ってみろって言われたときのこと考えろよ
>83 おまえvisitorの意味判ってないだろ。
>>84 関係ないね
大事なのは引数で渡すことによって関数無いで変更される恐れのある
インスタンスを明確にすること
お前のような素人はデザパタの前にC言語でも勉強しろ
なにせ引数もよくわからずグローバル変数で渡してるぐらいの低知能なんだからなw
>85 やっぱり判ってないのかw
釣りにしか見えない
>>86 前スレよろしく
今回も俺が特別に教えてあげよう
上のupdate()は関数内で何にアクセスしてるのかまったくわからないが
下のupdate(jiki・・・)はアクセスしてるインスタンスを引数に絞ることができる
(グローバル変数を使わないという規約を守れば)
これによってデータの安全性が保障されるというわけだよ
君のようにコーディングの効率ばっかりとって
引数もわからんような低知能は俺と話すようなレベルにないということがわかったかね?
>88 ここまでムキになるということは、>12=スレ主ってヤツかwww 修正コストとか考えたこと無いんだろうなぁ。幸せなヤツw
ID:H1z7Q+5uが噂のスレ主だな 一人だけ極端にレベルが低いのにその自覚なし
こらこら、触るな危険といってるだろうに。
>89 > 下のupdate(jiki・・・)はアクセスしてるインスタンスを引数に絞ることができる 笑っちゃうなwww ということは、ID:H1z7Q+5uはtaskの種類によって引数が変わることが前提か。 もしかしてtask保持コンテナも別に持つ派なのか? 例えば敵タスクがあったとして、雑魚敵Aと雑魚敵Bが異なるコンテキストを必要とする場合とか 考えたこと無いのか? 雑魚敵Aと雑魚敵Bで最小公倍数的な引数を取るupdate関数をつくったら、 それはID:H1z7Q+5uが>89で言っていることと矛盾するって気づかないのか?
残念なスレ主と遊ぼうのスレはここですか?
押すなよ! 絶対押すなよ!
>>80 その一人開発ってことは趣味の世界の話でいいよな?
プロの一人開発ったってフリーランスという名のプーでもなければ
自分一人の問題じゃねーし、他と折り合い付けないと会社つぶれるしな
>>2 ベースのゲロゲロフレームワークなんて誰も使いたがらないから作らないよ
で、趣味野郎でオナニーフレームワーク?これもあんま意味ないよ女子高生
大多数のパンピースペックの趣味プログラマは無難にサクっとゲーム一本
作りあげる方法を模索する
パンピースペックの趣味野郎がオナニーフレームワークとかいうハマリ道に
進んだら大半は生きて還ってこれん。終わり無きライフワークになるだろ
まぁそれはそれで楽しい人生なのかもね。否定はしない
ゲームではなく部品を作ることに情熱燃やして技巧に走って茨の道へ突進して
何年もの歳月をかけて山篭りして誰にも使われないフレームワークを構築する人生
悪くない。でもその結果が
>>2 ベースのゲロゲロシステムじゃな。成仏できんの?w
96もスレ主じゃね?こいつ本当に頭おかしいんだな。
引数君と一緒にすんなハゲ
>>98 じゃあ、この残念な引数君にも何か言ってやってくれ
引数君がアンチタスクだということは知っているが、前スレ終わりごろの
議論の内容がよくわからん
俺は
>>2 =チンカスゴミカス だと思ってるが引数君とは批判のベクトルが違うようだ
彼は数種類のクラスに共通のインターフェースを与え、共通のコードから呼び出す
というメカニズムを全否定してるのだろうか?だとしたらそれは仮想関数の全否定であり
わけわからん
引数君の主張内容がよく分かってない
あぁ?
引数君の主張なら
>>12 のリンク先を見れば十分わかると思うんだが、わからないのか?
それとも、あんたも日本語の残念な人か?
俺は前スレの
>>823 だ。何なら他の発言も発掘してこようか?
引数君の方がまだ技術に近い話をしてる分マシだな。 もしかして彼はひらしょー氏の言うデータと処理の分離を 超まわりくどく主張しているのかな。
>>104 前スレ823か。
引数君よりは能力的にマシだということはわかるが、説明がくどく、わかりにくい。
俺はこんな内容の薄い、回りくどい説明を読むのはまっぴらごめんなので、さいなら。
ESP能力に問題があるID:1vrKKSIM は すべてのアンチタスクがスレ主に見える病気を克服するべき
超能力能力か
くっ…。どうして「お前はバカを克服するべき」って言ってくれないの? 内容の薄い、回りくどい指摘を読むのはまっぴらごめんなので、さようなら
110 :
名前は開発中のものです。 :2009/02/06(金) 07:38:45 ID:RQ4iGJCo
お前等馬鹿は、プログラミングで一番時間がかかるのはどこですか? と聞かれてコーディングとは絶対に答えないくせに コーディングの手間ばかり減らすことに執着している なかなか読めないプログラムってなんだ? 構造が複雑なプログラムじゃないの? お前等馬鹿は全く逆のことを自己満足のためにやっているオナニストだ プログラマならせめて理詰めで動けよ お前等凡人から理性まで抜いたら猿と変わらないだろ
>>32 えーと、この人ってイイ歳した何者なの?プロ?パソゲー専門なんじゃない?
>ビデオゲーム黎明期においては、オールアセンブラで書くことが普通だったので、
>std::listのような便利なコンテナがあるわけでもなく、技巧的な方法でstd::list
>みたいなことを実現していただけ
えっえー?この人のいうビデオゲーム黎明期っていつごろのお話なのかな?
70年代?だったらまずZ80アセンブリで
>>2 を書いてみればいいのに。おかしな人だよ
16bit機時代?intrusiveなコンテナを使った理由がオールアセンブラだから?本当に?
最近は想像だけで昔話を書いても教科書になるのかしら?
どこのゲー専の子が犠牲になるのかしら。ちょっと可哀相ね
知らないことは知らないって言えばいいし、足を使って取材しに行けばいいと思う
んで、頭下げて監修してもらえばいいと思う。このままじゃあんまりだよ
>古典的なタスクシステムにおいてはタスクに番号(プライオリティ)が振られており
>番号を指定して特定のタスクのポインタを得ることが出来た
えっえー?つーか古典的タスクシステムってなんじゃい?ファンタジーゾーンなの?
>>111 あんた、何かがしゃべり方がキモイんだけど。
それはそうと、相手は年収何千万もある凄腕のプログラマらしいので、
技術的な反論は是非どこかのブログでやっちゃってください。
タスクシステムでグローバル変数使うから駄目だって意見が多いけど、 でも見渡してみると、ウィンドウズのウィンドウだってそういうしくみだしなぁ。
>>113 ウィンドウ同士であまりやりとりしなくてもあの複雑さだぞ
リストコントロール2つを連動させるだけでもやばいくらいの手間
基本的にウィンドウズの作り自体関連がたくさん生まれる処理に向いてない
あくまでも独立した動作が前提
>>113 そう思ったのなら両方とも自分で実装してみて比較検討だ!
でも数千行レベルでは使いやすかったやり方が数万行レベルでも同じように使いやすいままかどうかはまた別問題だ!
そこは注意な! 王道はグローバル変数使わないことだぞ!
また引数クンの登場か。 >93について、具体例を挙げて答えてよ。
>>117 はぁ?何言ってるのかわからない
俺が言いたいのは関数に引数つけろってそんだけだけど?
コンテキスト?は?
そんなもん使った時点で負けだ馬鹿
設計死んでるんだよ
俺の価値観ではそんなもん使った時点で負け
void*となにも変わらない
まあ、用は固定でない引数に意味がないんだよね 俺の価値観からすると
>118 > はぁ?何言ってるのかわからない じゃ、具体的に質問するけど、雑魚敵Aと雑魚敵Bに関係性が出てきたらどうするの? 例えば雑魚敵Aは雑魚敵Bを殺すことがある、となった場合に、雑魚敵Aのupdate関数の引数に 雑魚敵Bのリストを渡すの?
>>120 >雑魚敵Aのupdate関数の引数に雑魚敵Bのリストを渡すの?
それをやってはダメ
哲学的になるけど
基本的に雑魚敵Aが雑魚敵Bを殺す現象ってのは
雑魚敵Aの中の処理でも雑魚敵Bの中の処理でもないでしょ?
つまり雑魚敵ABに書くべき処理ではない
このアクションはあくまでも雑魚敵Aと雑魚敵Bが存在する空間で起こったことであって
それをシーンクラスとしたらそこに書くべき処理じゃねぇかな?
オブジェクト指向的にはよ
俺はオブジェクト指向原理主義者(テロリストではないw)だけど
基本的にオブジェクト指向を変な解釈をしないとしたら
種類の異なる(=クラスの違う)雑魚敵A、雑魚敵B、雑魚敵C、雑魚敵Dといたとして
それらの関連、つまりAxB、AxC、AxD、BxC、BxD、CxDの関連は全部シーンクラスに書くべきじゃないのかな?
そこはオブジェクト指向は手伝ってくれないと思うんだけどね(原理主義者的には)
昔ながらのC言語風味に書いたほうがうまくいくと思うよ
>121 > 種類の異なる(=クラスの違う)雑魚敵A、雑魚敵B、雑魚敵C、雑魚敵Dといたとして > それらの関連、つまりAxB、AxC、AxD、BxC、BxD、CxDの関連は全部シーンクラスに書くべきじゃないのかな? > そこはオブジェクト指向は手伝ってくれないと思うんだけどね(原理主義者的には) > 昔ながらのC言語風味に書いたほうがうまくいくと思うよ 今はっきりわかった。キサマはクズだ。
>>122 なんでだよ
いいこと教えてやったのに
何がどうダメなのか言ってみろ
勉強になるぞ
なにせ俺は10年以上もやってんだからな
10年以上ワナビー君ですかwww ヒッキーニートで親のスネカジリ。楽しそうですねwww
>>124 不毛な会話したくないんだ
どこがどうダメなのか思ったこと言ってみろ
なんとなく漠然とある自分にとっての常識なんて大抵間違ってる場合が多いぞ
>125 雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww 20種類くらいなら、RTSとかだと当たり前にいるぞ。
というか、どういえばいいんだろう。 あっちのスレでも書いたんだけど、どの処理を誰が担当するかが難しいわけであって、 タスクシステム云々、グローバル変数云々はあんま関係ないと思うんだが。 たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、 ・石に重力を働かせる処理 ・石と石の衝突処理 ・石とマップの衝突処理 は、それぞれどのクラスが担当すべきだろうか。
ヒッキーだが有能なゲームプログラマの発言>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>(越えられない壁)>>>無能な社会人もどきヘタレグラマの妄言 それがここのルールだ。覚えておきな。
>>126 そりゃ当然それだけの処理が必要になるだろうね
仮にプログラムの組み方が変わったところで
その数が少なくなることは絶対にないからね
それを踏まえて何が問題?
>雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww >20種類くらいなら、RTSとかだと当たり前にいるぞ。 ダブルディスパッチ
>>126 その莫大な組み合わせを纏めるかどうかは書く人の力量次第だが、
書く場所としてはシーンクラスが良いのでは?ってはなしだろ。
お前が読解力ないだけ。
>128 ヒッキーで無能はどこにいるんだ?
>>132 となると、シーンクラスが肥え太って困る。
モジュール化する何かいい方法は無いですか?
オブジェクト指向ってのは、オブジェクト(リソース)の管理は上手いんだが、
オブジェクトとオブジェクトの関連の記述には向いていないんだよなぁ。
>>79 どうでもいいけど、やねうらおの文章の引用部分さ
> すべてのゲームにタスクシステムが必要なのではない。
これ文脈読めばわかると思うけど、規模じゃなくて種類の話だよね
あと、残念な○○っていう表現が大好きなブログがあるよね
>>134 ないね
オブジェクト指向ではそこが限界
原理主義者の俺が言うんだから間違いない
後はC言語風味にうまく分離して書くしかない
>137 > ないね 単にモノを知らないだけだな。
>>127 衝突したかの判定はシーンクラスで、衝突に伴う処理は
オブジェクト同士のメッセージ交換ってのが俺のやり方だな。
>127 物理エンジンで本物っぽく動かすつもり? それとも2Dのマリオやソニックみたいに、それっぽく動けばいいの?
>>138 関連をオブジェクトに見立てて・・・とか馬鹿なこと始める気?
俺、そういうの読み手にわかりにくくなるだけであんまり意味ないと思うぜ
折角オブジェクトが誰にでもわかる表現にするためにオブジェクト指向を使ったのに
変にトリッキーな解釈(関連=オブジェクトだ!)してわかりにくくしたら
本末転倒じゃね?
って勝手に関連=オブジェクトの話するだけこいつ馬鹿だなー的
先読みをしてみたけど言いたいことあってる?
でもちょっとまって。 この流れでいくと、タスクシステムで行うべきことは、 ・描画順序の管理 のみ、ということになるな。 その他の処理はすべてシーンクラスで行うと。 晴れて、タスクシステム=グラフィックエンジン ということになり、みんな幸せになると。
>>127 俺なら重力は重力クラスが担当、衝突は衝突クラスが担当するようにする。
重力に引かれたい奴は重力クラスに登録するように!
オブジェクト指向的には、当たり判定は関連をクラス化すればおk
>>127 石に重力が働くというのなら地面みたいなものがあるはずだから、
石ー重力ー地面としてこの重力をクラスにすれば使いまわしも出来ていい
>143 つ 【オールドタイプの魂】
>>121 >基本的に雑魚敵Aが雑魚敵Bを殺す現象ってのは
>雑魚敵Aの中の処理でも雑魚敵Bの中の処理でもないでしょ?
>つまり雑魚敵ABに書くべき処理ではない
YES
>それらの関連、つまりAxB、AxC、AxD、BxC、BxD、CxDの関連は全部シーンクラスに書くべきじゃないのかな?
シーンでも神でも何でもいいけど、ゲーム世界の物理現象の調停者wが
介在し、結果を双方(作用する2体)に通知するというのは全くもって普通
珍しくない
ていうか目をさませ
もしオブジェクトが20種類いてそれぞれが関連をもつとしたら
少なくとも
a=オブジェクトの状態の数の総和
aC2(aの中から2つ選んだときの重複のない組み合わせだっけ?)
の数だけ処理を書かなきゃいけないことには
どう組んであろうが変わりはないんだぞ
>>147 なんのメリットがあってそんなわかりにくい書き方をするんだ
無駄だろ
あ、aC2じゃ同じオブジェクト同士が抜けてるなw
>>145 重力をクラス化するのは個人の趣味だろうが、
使いまわせるかどうかは怪しいな。
細切れの小さなクラスが1000個ぐらいあって、
それぞれにそれぞれが関係しあって一つの生態系をなし、
結果としてゲームになっている・・・とか。
そういうのって想定外の仕様変更には弱いからなぁ。
まぁゲームの方向性にも寄るのだろうが。
>>148 ゲームワールドをゲームエンジン内部で時間発展させてるからさ
衝突イベントでユーザー定義のコールバック関数が呼ばれるやつだ
>147 普通に考えてそれか。 じゃ俺も普通に考えてみるかな。 雑魚敵Aが雑魚敵Bを攻撃して殺す場合、Aは攻撃判定用不可視オブジェクトXを作成する。 BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。 攻撃判定用不可視オブジェクトを必要に応じて複数作り、それぞれ攻撃する側はそれを作成し、 攻撃を受ける側はそれに対する応答処理を書く。 シーンクラスには、雑魚敵コンテナと同じレベルで攻撃判定用オブジェクトのコンテナを追加して、 そこで相互の判定をする。
>>151-152 いや、だから全然わかってねぇな
なんかお前等変な組み方してるけど
関連の処理を仕様である分、全部書かなきゃいけないことは変わらないんだろ
なんでわざわざ間になんか挟むの?
なんか得になんの?金もらえんの?
素直にシーンオブジェクトに必要な数だけ処理かけよw
何をどうしたくてそんな複雑な仕組みにするんだw
オブジェクトXなんていきなり見てお前のそれ誰が理解してくれるんだよ>152
どうせドキュメントもかかねぇしよまねぇだろ
っていうか手間増やしてるしw
>>152 不可視オブジェクトXの受け渡しは誰が行うんだ?
ちなみに俺はオブジェクト指向原理主義者であると同時に
C++をはじめとするオブジェクト指向言語が大嫌いなんだ
だってなんのメリットもねぇよこの言語ども・・・w
だってよ・・・処理が集中・複雑化するのってシーンクラスみたいなところであって
別に個々にオブジェクト単位にできる部分は誰も苦労してねぇよマジで
ってみんなにはないしょだよw
ってところで
>>147 につけたレスは内容まちがってたな俺
すまんこ
>153 > なんでわざわざ間になんか挟むの? 雑魚敵が増えた時の修正が少なくてすむ。 攻撃判定オブジェクトを間に挟むことで、複数種の雑魚敵が同属性の攻撃だしても、一つの攻撃判定オブジェクトとの 関連処理に還元できる。
>>150 使いまわすってのはコード的にって事ね
数が多い場合は面倒くさいけど一個一個やっていくしかないなぁ
上位概念のオブジェクトを作れるんであればいいけど
STGでいうなら弾 - 衝突 - 敵 では無くて 自機 - 弾判定 - 敵みたいに
>>152 >Aは攻撃判定用不可視オブジェクトXを作成する。
そう。AABBとか、高速飛翔するならカプセル、線分を空間上に射出するわけだ
Xがそのうちどっかのバカに命中(得点ゲット)したときの通知が欲しけりゃ
おまえらの大好きなオブジャーバーパティャーンでXにAを登録するやつだ
subjectはX。observerはA
>BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。
まぁ、何かが自分に衝突したら呼ばれるコールバック関数(オブジェクト)を
登録してるわけだから、その中でユーザー独自の死ぬ処理を入れるわけだ
炎を吹いて墜落するなり、爆発四散するなり好きに振舞え
>>156-157 >雑魚敵が増えた時の修正が少なくてすむ。
だからならないって
必ず仕様の分だけ処理かかなきゃならないんだよ
(それが汎用デフォルト処理に挿げ替えられるかどうかは別として)
>使いまわすってのはコード的にって事ね
コード的なんて気にすんなマジで
関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
30回コピペして終わる程度の使いまわしなら30回コピペする気でいろ
そのぐらいでちょうどいい
>>155 いや確かにそのとおりだと思う。
ただ、シーンクラスみたいなところに処理が集中するのは、
ゲームにオブジェクトとオブジェクトの関係が多いからだと思う。
一般アプリやツールは、リソースの管理がメインなので、
オブジェクト指向も役に立つのだろう。
ID:lLkuERdrはド素人だろ。こんなクルクルパーは相手にするだけ無駄。
>159 > >雑魚敵が増えた時の修正が少なくてすむ。 > だからならないって > 必ず仕様の分だけ処理かかなきゃならないんだよ 新規雑魚敵が今までの他の雑魚敵と同じ攻撃を出すのなら、それと同種の攻撃判定オブジェクトを 作成するだけで終了。 オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
>>160 一般のアプリだって同じだよ〜w
絶対にボタンとかツールバーの処理なんてウンコぐれーだろ
メイン画面の処理の強烈さといったらない
メインに集中してなくても絶対にどっかに偏るw(ツールウィンドウとか・・・)
部品は平均200行程度しかないのにメインで10万越えで放置されてるソースとか多いぞw
>>146 もれなくリストに登録しておいた。
>>121 もしBがAに殺された時、「うわああああ!」って悲鳴を上げるなら、
その悲鳴を上げる動作はBでやるべきだと思う。
AがBを殺した時、「やっほお!!」って喚声を上げるとしたら、それはAが行うべき内容だろう。
シーン(あるいは調停者)がやるべきことと言ったら、Bに対して「お前はAに殺された」ってメッセージを送ることと
Aに対して「お前はBを殺した」ってメッセージを送ること。
なんかややこしくなってきた。
皆えらいわ。
>>158 今、攻撃判定用「不可視」オブジェクトXって言ってるのだから、
弾をXにしてしまうと、弾が不可視になって困る。
弾が飛ぶってのなら、弾は普通のクラスにすべきだろう。
で、弾と雑魚敵Bの間で攻撃判定用不可視オブジェクトXをやり取りする・・・と。
なぜインターフェイスでやらないのか。攻撃判定用オブジェクトとか馬鹿げてるよ。
>>162 >オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
基本的にはそうだと思ってるし、そうでなければおかしいと思ってる
第一、お前が書かない処理はどうなるんだ?
プログラマならこれが答えられなければダメだろ?
それとお前がしてるのはあくまで仕様の話であって設計の話ではない
決まっていない仕様をむりやりプログラムの仕組みで解決しようとしている
必ずすべての組み合わせ分の関連を把握するべき
その上で共通な処理を共通であるように書いたらいい
(デフォルトを「何もおきない」としたら何も書かなければいい)
ちなみに俺はオブジェクトごと必ず関連をすべて書き出している
雑魚敵Ax雑魚敵BがいたとしてAのステータスが3種類、Bのステータスが2種類だとしたら
B1 B2
A1 S1 S2
A2 X X
A3 X X
X はなにもおきない
S1は爆発
S2は押される
とかねw地道にw実際はもっとでかくて多いぞwゾッとするぐらいな
例えばステータス1から2にうつるときのステータス1−2が問題になったりねw
書き出してるっていってもそこまで明確でもないんだよね、それでも見える分ぐらいはやるべきだと思ってる
>165 不可視ってつけたのはちょっと余分だったかもな。別に可視でもいいんだ。STGの場合は、 弾という可視の攻撃判定オブジェクトを介して敵と自機が攻撃しあってるわけだ。 例えば格闘ゲームでパンチなりキックなりするばあい、攻撃判定の瞬間だけ拳や足先に 不可視の攻撃判定オブジェクトを作るというのはよくやること。この場合は、その攻撃判定 オブジェクトに『威力』なり『方向』なりの属性を与える。攻撃を受ける側は、その『威力』なり 『方向』なりを攻撃判定オブジェクトが当たった位置と一緒に見て、それぞれのダメージモーションを 再生したりダメージ処理に移行する。 波動拳(のような何か飛び道具)なら、可視の攻撃判定オブジェクトになるだけ。 スクリューパイルドライバー(のような何か近接巻き込み方攻撃)なら、巻き込み範囲を持つ不可視の 攻撃判定オブジェを作って、それにそれぞれへのコールバックを持たせる。当たったらコールバックを よんで攻撃側・被攻撃側それぞれに対してモーション発動なりなんなりをする。
>>165 >不可視
あ、この部分は見落としていた
>>152 は「一瞬で目標に到達するレーザーみたいな攻撃(視覚効果なし)」
を想定してたのかな
>166 ガンバレw 努力の人はさすがにすごいと思うよw 学習できない無能はもっとすごいと思うけどねw
>>162 だから処理纏めたいときは普通はインターフェイスとか使うの。
オブジェクトのやり取りなんかしない。
class X{ public: virtual void hoge()=0; };
class A : public X{ public: void hoge(){} };
class B : public X{ public: void hoge(){} };
for(int i=0; i<tasks.size(); ++i){
X *x = dynamic_cast<X *>(tasks[i]);
if(!x){ continue; }
x->hoge();
}
とかすれば処理は纏められるだろ。
で、どう纏めるかは問題ではなく、これをどこに書くかが問題なんだ。
>170 で、どこに書くの? 間にオブジェクトを介在させる場合は、書くべき場所はひとつしかないけどね。
>>166 > B1 B2
>A1 S1 S2
>A2 X X
>A3 X X
>
>X はなにもおきない
>S1は爆発
>S2は押される
あれ。当たり判定表はアリだと思うが…
>>172 シーンクラスが良いのではないかということになってる。
>>167 オブジェクトを作るのは、インスタンスを複数にするためであって、
処理を纏めるためではないと思うぞ。
>>174 シーンが肥え太る?ゲームエンジン(神)が肥え太ってんだよ
肥え太ったゲームエンジン(神)が作りしシーン
その中での現象に関して肥えた神にお願い・お祈り・お伺いするためのインターフェース
これをシーンが提供してる。それだけのことだ
神と交信するためのインターフェース(シャーマン、イタコ)は色々ある
物理エンジンにしかアクセスできないインターフェースとか
どのインターフェースを使えるかはゲームオブジェクト(アクター)によりけり
あとおまえやねうらおじゃない?睡魔に耐えてたらESPが冴えてきたぞ
外れてたらごめんね。もし当たってたら一言言わせろ
あんたさー知りもしない昔の話を捏造してペラペラしゃべってる暇あんなら
一次情報にアクセスしてきっちり裏取れよな
あれじゃネット発のタスクシステム都市伝説の怪文書がまたひとつ増えただけじゃん
松○とドングリだろ。悔しくないのか?足使えよ足
ネットとか2ちゃんで怪情報かき集めて本書くな
今回の記事は魅力ないでしょうよw 前スレでタスク信者が詰まってたところ全部無視だものw
俺はweak_ptr使って実装するっての一つにしても為になったがな まあ、あの記事から何も学べない奴は学習能力がアレなんだろうな
ID:lLkuERdrは10年以上プログラムやってて(
>>123 )、
C++が使えない(
>>125 )ってぐらいだから、まあ、本当にアレなんだろうけどな・・
>>179-180 あんたが複数IDを使えるのはもうわかってるよ
このスレのはじめのほうでもやってただろ?
でもいいの?
あんた自分より賢い人には絶対にたてつかないクズじゃん
俺なんかに噛み付くと反撃が痛いんじゃない?w
weak_ptr とかはもうすでにみんなやってるでしょ。 そこはそんなに。本質とは違うというか。 別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。 全般にわたって高速化のことしか書かれていないが、そんなの正直どうでも良い。 ってのが感想。
>>182 > 別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。
それは、何かweak_ptrを勘違いしてそうだな・・。
OnDeleteTaskのときに、被参照ポインタをどうやって無効にするんだ?
>>181 > あんた自分より賢い人には絶対にたてつかないクズじゃん
それは、俺を他の誰かと勘違いしてねーか
俺はC++わからないとか、デザパタわからないとか、
そんなド素人と話しても得ることがないから、そういう奴とは話さないだけだよ
>>183 class my_task : public task
{
task *m_ptask1;
public:
virtual void OnDeleteTask(task *ptask)
{
if(m_ptask1==ptask){ m_ptask1=NULL; }
}
};
>>185 ああ、言わんとしていることはわかったし、あんたはまともなプログラマに属すると言えるとは思うが、
そのコードだとオブジェクトの削除はO(N^2)になるよな。
俺の現場ではそんなコードは全然現実的じゃないんだが。
あんたは本当に数万オブジェクトの出てくる規模のゲーム書いたことあるの?
ただ、これらの話題で絶対出てくるのが、 オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。
もちろん185の実装は別に間違っちゃいないので、俺の183は発言を撤回する。 185があまり良くない実装だと理解した上で確信犯的にやっているんだろうから。
>>187 > オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。
(そういう議論が発生するのはわかるが)それは、変じゃないだろう。
被参照ポインタの無効化というのは、そもそもそういうものだから。
>>186 まぁ10000も出すとなぁ・・・
ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
つーか、10000もオブジェクト出すって、何のゲームよ。
>>190 > ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
weak_ptrと同性能のものを自前で書くだけでも結構大変だと思うがな。
少なくとも現場のプログラマがやるのは時間の無駄で車輪の再発明以外の何物でもないと思うのだが。
> つーか、10000もオブジェクト出すって、何のゲームよ。
いまどきの3Dのゲームでは、足や手のパーツごとに接触判定を持っていて、それぞれのパーツが
独立していて、それぞれがC++のオブジェクトになってたりするのだが。
いや、ま、どういうか。 再発明だろうがなんだろうが、あまりどうでもよくて、 要するに、そういうところで困ってる人はいないだろうと。 余談だが、 そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。 昔weak_ptrのようなものを使ったコードも書いたことがあるが、釈然としなかった。 だって、lock出来るときと出来ないときでコードが分岐するなんて、変だ。 そういう仕組みに頼ってると、オブジェクトの所有権がどこにあるのかわからないコードになりがち。 オブジェクトは作ったやつが削除すべきという結論に達したが。。
>>192 > そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。
そんなことはない。
シューティングで、子分より親分が先に倒されることは普通にありえるだろ?
子分は親分のポインタを保持していてはいけないのか?違うだろ?
そういうとき、どういうコードを書くつもりでいるんだ?コードで示してくれ。
>>192 > オブジェクトは作ったやつが削除すべきという結論に達したが。。
これも全くのでたらめ。
シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
ボスはザコより先に逝っちまうことがあるだろ。
ザコから参照されているからボスはいつまでもオブジェクトを解放しないのか?違うだろ。
オブジェクトの所有者は、そのオブジェクトを生成した奴(ボス)にあってはいけないんだ。
もしそう設計しているならそれは設計上の誤り。
>>193 >シューティングで、子分より親分が先に倒されることは普通にありえるだろ?
>子分は親分のポインタを保持していてはいけないのか?違うだろ?
>そういうとき、どういうコードを書くつもりでいるんだ?コードで示してくれ。
親分も子分も、シーンクラスが管理すればよい。
>シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
>ボスはザコより先に逝っちまうことがあるだろ。
なぜボスがザコを生成する必要がある?
シーンクラスがザコを生成、削除すればよい。
Cのmallocにはweak_ptrのような仕組みは用意されていないが、世のプログラムはちゃんと動いている。
windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
なのにゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
だけど止めはしない。weak_ptrをつかってゲームを書いてみるといい。きっと後悔するから。
>>195 > 親分も子分も、シーンクラスが管理すればよい。
うわ。それはひどい。なんか、またド素人と話している予感。
子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
どんな依頼コードを書くの?それ書いて見せてくれないか。
> windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。
シューティングでボスとザコが居て、ボスとザコが何故か紐で繋がってたとする。 紐の管理はボスとザコのどちらですべきか? 答えはどちらでもなく、 ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。
>>195 > ゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
「ゲームではweak_ptrに頼らざる得ない」なんて俺は言ってないからな。
weak_ptrを使えば簡単に書けるものを、馬鹿が車輪の再発明したり、weak_ptrを知らないがために
複雑な設計になっていたりすると言ってるだけなんだが。
>>197 > ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。
まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は?
ID変わってしまったけど、俺がID:XPRCk6pDな。 >>子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、 >>あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。 >>どんな依頼コードを書くの?それ書いて見せてくれないか。 依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大親分クラスを作って そっちで管理する。 >>何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。 ハンドルは同じ値が再利用される可能性もあるわけで。
>>199 >まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は?
好きにすれば?
複数のクラス同士が双方向にコミュニケートするような状況さえ回避できれば、
あとは考えることなんてないね。
>>200 > 依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大> 親分クラスを作ってそっちで管理する。
まあ、それでも組めなくはないのであんたが実際にゲームを書けないとは
言うつもりはないが、しかし、あんたは、大きなゲームを作ったことがなさそうだな。
オブジェクトが無数に出てきて広大なフィールドを歩けるタイプの
汎用的な3Dエンジンなんかを作れば俺が言ってる意味がわかると思うんだが。
まあいいや。お互い意見が対立しているわけでもなさそうなので、俺はもう寝る。
>>200 俺もシーンクラスに書く
その設計でいいと思うぜ
ID:dNGvkNLdは普通に頭悪いだろw
質問攻めしてるけど明らかに予想外の答えにうろたえてるだろw
>>203 C++すら使いこなせないド素人は黙ってな
>>202 そういうコテコテしたプログラムも書いたことがあるが、今では間違いだったと考えている。
少し前までは私も「オブジェクトは自立しているべきであり、周りの状況を判断し、自分で行動すべきだ」、
と考えていた。私もまだ若かったし、C++がそういう設計思想であることも手伝って、そういう勘違いをした。
作ってみたらうまくいかず、考えてみたら、オブジェクト同士の関係を見落としていることに気がついた。
ゲームはオブジェクト同士が関係しあって初めてゲームになる。
そこを重点的に記述できないことには楽しいゲームを作ることは難しい。
昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では?
>>205 > 昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では?
それは、全然的外れだろう。
本当に現場のことは何も知らないんだな。
せいぜい同人ゲーでも作ってなよ。
>>206 苦しくなると話の趣旨と違うところだけつまんで
人格批判からレスの全部否定に入るっておきまりのパターンなのなw
>>207 C++すら使いこなせないド素人はこなくていいよ
c++使わなければどうでもいい話題ばっかだな
>>192 deleteされたポインタを直接参照しているオブジェクト全てにその旨通知するように設計したいと思った。
>>193 子分::親分からの指令(親分へのポインタ) みたいなメソッド作って、
子分は親分からの指令があった時だけ、親分へのポインタを参照しながら協調動作すればいいんじゃね。
子分が親分のポインタを持つ必要は無いよ。
>>197 ボスと雑魚は紐なんか無視して、それぞれ独立に動いていい。
紐は自分のグラフィックを表示しつつ、ボスと雑魚に対して「これいじょう伸びないよ」的な力(or メッセージ)を与える。
それ以外の点では、紐は普通の登場キャラと同じような扱いで良いと思う
シーンクラスに何か特別なことを書く必要なんて無いよ。
>>210 どっちにしてもシーンみたいなクラスあったほうがいいじゃん
>子分は親分からの指令があった時だけ、親分へのポインタを参照しながら 子分のクラスなんだから子分の処理だけで完結したいと思わないんか? カプセル化っていうの?
>>211 うん、あった方が良いと思う。
実際にシーンクラスが何を担当するのかはここに居る人それぞれが全く違うイメージを持ってそうだけど。
>>212 子分は親分と協調し、親分は子分と協調するのだから、
お互いに通信しあう仕組みは必要で、完全に分離するのは不可能だと思う。
ふと思えば、俺の方法だと、子分が死んだことを親分はどうやって感知するんだって思ったw
>174 おまえはタスク=ゲームオブジェクト派か。 プログラミングなんて、正しく動くなら何やったっていいんだよ。くだらない価値にこだわってると 伸びないぞ。
216 :
名前は開発中のものです。 :2009/02/07(土) 16:25:49 ID:21jTa7Aw
シーンクラスって作る価値があるのかね シーンってメニューやスコアやRGPならフィールドや戦闘なんかのことだろ 一つのゲームに必要なシーンなんて十もないんじゃないか そしてそれぞれのシーンに共通点なんてほとんどない 共通しているのはデータ取得メソッドみたいなのだけ 各シーンは遷移するけどstateパターンを適用しても メリットはほとんどない そんなどうでもいい部分を考えている暇があるなら うんこでもして寝てしまえ このうんこ野郎ども
218 :
名前は開発中のものです。 :2009/02/07(土) 19:39:16 ID:21jTa7Aw
なんでもできちゃうクラスみたいなのを作るからバカになる つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし なんでも作ればいいってもんじゃない 二つしかないクラスに親クラス作ってクラスが三つになって すごいんだぞーとかバカじゃねーの ばーかばーかしんじゃえ そんなとこに柔軟性持たせる暇があったらうんこでもしてろ うんこうんこ
なんでもできちゃうクラスみたいなのを作るからバカになる つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし なんでも作ればいいってもんじゃない 三つしかないクラスを統合してクラスが二つになって すごいんだぞーとかバカじゃねーの ばーかばーかしんじゃえ そんなとこに柔軟性持たせる暇があったらうんこでもしてろ うんこうんこ
シーン。。。
>>219 でもよ、
「あれもしなきゃ、これもしなきゃ」って状況で、修正作業が発生して、
2回だけでも同じ修正作業をやるのって、憤慨「ウガアーゥアーッ!!」状態にならね?
C++使ってるなら、template(汎用クラス)の親クラスは使わな損々。
223 :
名前は開発中のものです。 :2009/02/07(土) 20:22:54 ID:21jTa7Aw
シーンをまたがって修正しなければならない項目なんてほとんどないから 考えるだけ無駄 メニューと戦闘のシーンでの共通項目なんてあるのかよ メニューと戦闘で使う共通キャラのモーションがおかしいから修正だぜ サブクラスにしておいてよかった俺天才超天才 なんて場面は百年に一度しかねーよ どうしても作りたければ似たようなシーンで共通の親クラス持てばいい 何度も言う、そんなくだらないコードを書く暇があるなら うんこしているほうがまし うんこをしていると新しいアイデアが生まれると過去の偉人も言ってた
>>223 >共通項目
それはつまり、タスクシステムのことだと思うよ!
>>222 ?
親分クラスと子分クラス間の通信をシーンクラスが受け持つなら
シーンクラス1箇所で修正済むんじゃない?
>>223 シーンクラス否定したり肯定したり、立場がワカンネ
もしかして否定したいのって「シーンクラス」じゃなくて
「抽象化されたシーンを統一的に管理するクラス」?
226 :
名前は開発中のものです。 :2009/02/07(土) 20:47:40 ID:21jTa7Aw
すげぇぜタスコシステム 共通項目がない、なんの関係もなかった複数のオブジェクトを 無理やり関連付けやがった やべぇな、俺には真似できねぇぜ
「シーン=メニューと戦闘」の入出力の具体が不明だが、 ウンウンきばっている段階(=設計の段階)で、 なんであれ抽象化できる部分はなるべく抽象化しておくんじゃねえの? 期限が決まっている状況であれば、なおのこと、それくらいの安全策は取るよな。
228 :
名前は開発中のものです。 :2009/02/07(土) 21:01:07 ID:21jTa7Aw
>>227 一気に食おうとするな分けろ
夏休みの宿題なんてものは毎日少しずつやるもんだ
共通点なんて無理に抽出してもそれはオナニーだ
シーンごとに分けろ、目標を分けろ
メニューだけ作って完成させろ
戦闘だけ作って完成させろ
最後に適当にくっつければいいだけだ
全部同時に作って完成させる能力もないくせに
一度に全てをこなそうとするな
俺らは凡人だから、凡人にふさわしいやり方がある
規模の増大が複雑さのインフレを招くのは常識
それを回避するためにそれぞれの規模を抑えて
できるだけ分離して開発するんじゃねーか
完成した複数のシステムをできるだけ触らないようにしてくっつければ
それでいいんだよ
俺らは天才じゃねーから
スーパー天才のやねうらお連中の言うことなんて聞かなくてもいいんだよ
俺らは凡人だ、凡人には凡人にふさわしいやり方がある
そして余った時間を使って
スーパーウンコタイムを楽しもうじゃないか
存分に
>>227 そして実装も終盤に差し掛かった段階で唐突に仕様変更が入り
抽象化して見えなくしておいた情報を使うために苦しむんですね
わかります
>>229 仕様変更に柔軟に対応できるような抽象化を見極めるのもワザのうち。
そんなのするから無駄に時間がかかるんだよ って俺の10年以上の経験が言ってる
>>229 そう、ワザ要るよね
初めてのゲームジャンルとかだとまだワザが足りないから完全には見極め切れない
全く抽象化しないか本当にかるーくしとく位でちょうどいい
233 :
232 :2009/02/07(土) 21:14:49 ID:B+kDbAoq
234 :
名前は開発中のものです。 :2009/02/07(土) 21:22:28 ID:21jTa7Aw
どこにでもいるんだよ 将棋やってるのに穴熊を囲うことだけを考えて 大局を見ずに 穴熊が出来たと思ったら既に敗戦濃厚な戦局になっていたという そういうおばかさんが タスクシステムにこだわったところで 3Dを出来るようになるというわけではないということを 超天才が身を持って教えてくれた この教訓を未来に生かそうではないか諸君 そしてうんこを私に
亀レスだが・・・
>>159 俺も、タスク間通信は、独立した当たり判定モジュール(クラスで実装)に任せている。
でもなあ・・・。
>関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
>30回コピペして終わる程度の使いまわしなら30回コピペする気でいろ
>そのぐらいでちょうどいい
言っていることはすごく分かるんだが、俺の場合、共通化する努力は続けているって感じだな。
ゲーム中のキャラの相互作用なんて、大体が抽象レベルでは、似通ったプリミティブな交差判定に落ち着くから、
共通化できるところは共通化しておくと、使い回しが利くんだよな。もちろんキャラの魅力は半減するが。
未出のメンバ構成のプロパティを持つキャラを追加する場合は、新規に作らざるを得ないよね。
当たり判定の共通化を突き詰めたゲームってなんだろな?
一昔前に乱発されたベルトコンベアアクションみたいなものか?
最終成果品としては、単調な作業を強いられるゲームだったよな。
最近の3Dゲーも、相互に影響しあうロジックが単調なのが多いな。
綺麗だと思ったタスクシステムの実装って関数型言語で作られたプログラムくらいしかないな 現行のC++やJavaは言語そのものがスマートじゃないもの… いくら頑張っても泥臭さは残るし、作った本人が胸を張ってもやっぱり泥臭さは残ってる アンチがいるのは理想論に近い良い手本がそこらに転がってないせいもあると思うし、あまり邪険にしないでやってほしい
クックック。世の中には手段の為なら目的を選ばないどうしようもない奴がいるんだよ。 諸君。私はタスクシステムが好きだ。 (以下略)
話題循環に飽きた俺が勝手に今後のスレ行き先予想 1.現状維持 アンチタスクシステム派がタスクシステム派の不備を指摘し続ける。 ずっとアンチのターン。あと10〜15年位?(根拠は無い) 2.タスクシステム派勝利 タスクシステムをそのまま維持した上で弱点を補強するような改善策が どっかからか出てきてアンチタスクシステム派が納得してスレから去る。多分無い。 3.「タスクフレームワーク総合part5」になる タスクシステムの利点?であるデバッガ等々の外部ツールを必須装備とし、 その作り方を初心者に優しく指南。 利点強化によるごり押しでアンチを一掃。多分無い。 4.「タスク系総合part5」になる アンチ勝利。part1から欠陥があると指摘され続けても「そこはお前の技術力が足りないせいだ」 的なコメントばっかり続くのを見て初心者が冷めた。 ただ、既存のタスクシステムは捨てるものの、 「タスクシステムもタスクフレームワークもだめぽorz でもMTフレームワークがあるさ!」 「タスクシステム総合=task system総合=タスク系総合だ。文句あっか」 みたいな流れで「タスク」という概念の在り方・使い道を模索する方向に。 マルチコアCPU当たり前になってきてるしね。 5.スレから人がいなくなる 不況で、、、とか、 ゲーム製作より動画製作のがおもしれぇw、とか いちアンチとしては4あたりに行ってくれると気兼ねなく去れるんだ。 っていうかむしろその辺議論したいんだ。
しかし、タスクシステム自体は描画順の管理という大仕事があるから必要だよなぁ。
というか、アンチ派はどうやって描画順を管理しているのか。
描画順って何だ 3DならZバッファで終了とかじゃねえの
>>241 3Dでもエフェクトや半透明は描画順が必要だよ。
あんた、3Dのまともなプログラム、やったことなさそうだな…。
>238 > いちアンチとしては4あたりに行ってくれると気兼ねなく去れるんだ。 素直に『アンチタスクシステム総合スレ』でも立てたらイイジャナイか。
>240 その辺は描画エンジンが描画順を制御するようにしてる。 タスク(というかゲーム内の各要素)の更新順と、それらの描画順は正直関係ない。
>>245 タスク(というかゲーム内の各要素)と描画エンジンが扱う各要素のクラスは共有?
>>238 オレはいち擁護派だが普通に4に行って欲しいね
同じことを続けていれば、なんだっていずれ通用しなくなるのは当たり前
古き良きタスクは穏便に「古典タスク手法」の棚に収めて、新しい合意を作っていけばいい
どう考えても4が建設的だろう
オレがアンチを叩く理由は単に非建設的だからだし
249 :
名前は開発中のものです。 :2009/02/08(日) 01:08:11 ID:/7HQNkAm
3Dできるやつでタスクシステム賞賛してる奴っているのかどうかに関心がある 3Dできないレベルの奴がキャンキャンほえても所詮雑魚 サイヤ人とスーパーサイヤ人ぐらいの差がある 3Dでのタスクシステムの実例とやらをこの目でみてみたいものだ
3Dできる奴できない奴とか言ってる時点で・・・
3Dになったところで何ら変わらないよ
252 :
名前は開発中のものです。 :2009/02/08(日) 03:03:37 ID:ydU34I03
タスクシステムって決まった定義がないからなぁ… しかも前提によって最適なタスクシステムは異なる。 シューティングとアドベンチャーで最適なタスクシステムは違うだろうし 携帯とかファミコンレベルのチープ環境と、PCやPS3クラスのリッチな環境とでは最適なタスクシステムも違うだろ。 前提が違うのにたった一個のシステムがベスト!ってのはありえん。
タコスはやっばりメキシコで食うのが一番だと思う。
ムーチョス・グラシアス!!!
>>252 この中の「タスクシステム」を「システム」に置き換えてもまったく意味は変わらない。
ほんと、意味の無い言葉だよ。
3Dが全くダメなばかりにいつも後続のガキ共に鼻で笑われてきた2Dオヤジ 2Dオヤジにとってタスクシステムとは、プライドを保つための最後の砦だった 心の支えだった。自己のアイデンティティを投影してまで愛していたんだ なのに、お前らときたら…
257 :
名前は開発中のものです。 :2009/02/08(日) 10:46:39 ID:PqcaRaMD
>>256 2Dやってた世代が現役の現場なんてあんまり残ってないと思うが…
仮に残ってたとしたらやっぱりその世代がタスクシステム周りをやるのが妥当だと思う。
3Dが最新技術だから、ってのではなくタスクシステムは作るのに経験が必要だから。
3D、コリジョン、物理エンジン、AI、etc...はゲームの全体から見たらガワの部分。
ゲームの状態遷移やオブジェクト管理をするタスクシステム的なものはガワではなく屋台骨部分で、
この部分はゲーム毎に最適なものが異なり、設計するのには部分だけでなく全体を見通せるだけの経験が必要。
まぁ、いわゆるメインプログラマーの仕事の範疇。
3Dやシェーダー周りはプログラマの花形っぽくみられるジャンルだから若者には人気なんだけどね。
そんなもん構築するだけ時間の無駄なんだけどねw
そんなもん構築するだけ時間の無駄って思ってる奴は三流なんだけどねw
>>259 まぁ、テトリスサイズのゲームならタスクシステム構築とかしなくても作れるけど
ある程度大きいものだとそれなりの管理システムが無いとなぁ
日曜大工で犬小屋を設計図も柱も無しで作った人が
家やビルも同じように作れる、と思ってるのかもね。
では 3Dでタスクシステクを採用している漏れが最強で敬われ存在なのだな まあ精々がんばりな 3Dができないorタスクが理解できない下賤者ども
>>261 じゃあ、
>>12 (前スレの
>>824 付近)からはじまるタスクシステムの欠点についてはどうなの?
タスクシステムなんて使うからバグが増えるんだけど?
また引数クンかwww
自分が理解できてないことを判断できないやつって、根本的に開発に向いていないよね
例えば、tekiAとtekiBがいたとして、teki_baseから派生させるとする。 class tekiA : public teki_base { ... }; class tekiB : public teki_base { ... }; それぞれが自機と関係性があるとし、そしてそれぞれが関係するワークを引数として持つ、 tekiA::update( jiki, mahou_kougeki ); tekiB::update( jiki, boss_cho_tsuyoi ); という関数があったとする。 1. このupdate関数の呼び出しはどのようになるのか? 2. tekiAがjikiの状態を変更したら、tekiBにとってそれは予期せぬ変更でないのか? 引数クンには、この2点について具体的な解答をしてもらいたいものだな。
あぁ、もうあと2点。 3. tekiAとtekiBをteki_baseから派生させるのは、是か非か? 4. teki_baseにupdate仮想関数を作成して派生クラスで実装する方式を取らないのは何故か? もあわせて聞きたいね。
267 :
名前は開発中のものです。 :2009/02/08(日) 15:51:32 ID:/7HQNkAm
スーパーサイヤ人が最強だろ、雑魚め、クソが よくよく考えてみるとクソクソ連呼するDBはなかなか下品だな 十年前に偉大なる将軍やねうおらさまと喧嘩した奴が 3D使いこなしているのを見て、やねうおらというひとは この十年間何をやって痛んだと疑問に思ったが そんなことは些細なことだと思った、 科学よりも宗教の方が強い世の中じゃからな 目的目標を欠いた設計論なんてクソの役にもたたぬよ 0.0001ミリの誤差も修正できる神業を極めたところで 家を建てる設計の助けにはならん
>>267 本題に関係ないツッコミで申し訳ないが
科学は宗教の一分野として発生した
これ豆知識な
>>265 俺、ID:lLkuERdrだからテキトーにこのスレからIDとって
まず思想を読んでみてくんない?
271 :
名前は開発中のものです。 :2009/02/08(日) 16:20:45 ID:/7HQNkAm
大局話してる最中に細部語り出す奴ってうざいよねー 細部語ってる最中に大局話し出す奴ってうざいよねー 何が言いたいかって言うと俺最強俺超天才 定義を明確にしない限りいくらでも攻撃できるし 定義を明確にしない限りいくらでも逃げつづれられるぜ タスクシステム最強カルト最強 3Dなんかできなくてもタスクシステムさえあれば スーパーサイヤ人だ 神の奇跡を信じよ、それがタスクシステムである 3Dはできないけどタスクシステム最強である
>>242 Zソートすればいいだろ
予めグループ化して描画するのはタスク云々とは関係がないし
お前ら、人に仕事割り振ってもらわないと、自分では何もできないタイプだろ?
>270 ok。 クズは失せろ。
タスクシステムとか気取った物言いしてるからどんな高尚なもんかと思ってみれば、 何のことはねぇ、MediatorパターンとObserverパターンを組み合わせただけじゃねえか、 アホらし。すかしてんじゃねえよ、ぼんくら共が!
デザパタやタスクを銀の弾丸か何かと勘違いしてないか?
パスタといえば俺ば明太子パスタが一番好きだな
ループさせすぎw 書いてるの同じ人だろw
279 :
名前は開発中のものです。 :2009/02/08(日) 17:27:25 ID:/7HQNkAm
この無限ループを味わいたくなければ タスクシステムなんてわけのわからない幻想は捨て去るんだな 無限ループで苦しむ時間を3Dの勉強に費やせば ポリゴンの一つもレンダリングできるようになる やねうおら大先生みたいにわけのわからない長文を書いて わけのわからないタスクシステムの解説を書くような老後をっ 送りたいならばそれも止めはしない それも人生よ タスクシステムはイディオムのようでイディオムではなく デザインパターンのようでパターンではなく フレームワークのようでフレームワークではないのだよっ 思い知ったか、このメスブタどもめ
>>265 少し違う話になるが、複雑な状態をもつインスタンスは外部から状態遷移させると危なくないか?
俺は外部からはメッセージ送るまでに留めて、実際にメッセージ処理して状態遷移するのは、個々のインスタンスに任せる。
これだと処理が1フレーム遅れたり、場合によってはメッセージ捨てられることもあるんだが、それでも外部から状態の詳細隠蔽できる利点を優先してる。
あなたややねうらお先生みたいにわけのわからない長文を 書くような大人にはなりません。
282 :
名前は開発中のものです。 :2009/02/08(日) 17:52:59 ID:/7HQNkAm
やねうらお大先生様は自分の過去を正当化するために恥を上塗りしているだけ 俺はそう思う ただ長く理解しづらいまわりくどいわけのわからないことを書いて惑わすだけ 定義も何もない、ただそれっぽいことを誰にも理解できないように書いて 適当に権威のありそうなものを付け加えて ごまかしているだけ、子供のいいわけ、自己保身を計っているだけ あの人は小説家にでもなればいいよ、回りくどい文章を書いて 1を100に水増しして本を書いて適当に売ってればいいよ タスクシステム語ってる連中の気に食わない点の一つとして 定義を明確にしようとしない 設計の話だと思って設計の話をすると 急にイディオムの話に切り替えやがるし それに合わせてイディオムの話をしていると また急に設計の話に戻しやがる 結局何をやってるかわかってないから、適当に話をつなげるしかないのだろう 自分たちが過去やってきたことを無駄にしたくないという思いが タスクシステムを正当化しなければならないという 何が言いたいのかというと、つまり私は空腹だということだ
IGDAあたりがタスクシステムはこういうもの って定義してくれりゃ… IGDAってセミナー案内以外何かやってるんか?
やねうらお大先生は、年収数千万の天才プログラマなんだから ゲー専みたいな馬鹿の集まり、相手にしなくてもいいんじゃね?
285 :
名前は開発中のものです。 :2009/02/08(日) 19:28:37 ID:/7HQNkAm
ゲー専みたいな馬鹿の集まりを金づるにしてるから年収数千万なんだよ 俺が気に食わないのはやねうらお本人よりも それを無自覚に賞賛している信者連中の方 考えることを放棄している 三年毎に取り巻き信者が一掃されてるのが笑える 難しくて凄そうで権威のあるやねうらお大先生の言うことを 理解したような風に賞賛すれば俺も近いレベルの有能プログラマになれるんだ といったところか、おこぼれクレクレ君 本当に理解してないからメリットとデメリットも知らないし 適用すべき箇所がどこなのかも知らない だからとりあえず使ってみて、満足して 布教して、さらに満足する これをこうやったらこうなってここが良くなるってのが全くない 手に入れたぞ、使うぞで完結している それを自覚できないから、多少難しい観念を理解することはできない つまり3Dは複雑すぎて手が出ない、又はすぐに挫折する でも俺優秀俺天才って言いたい、そう他人に思ってもらいたい その願望をかなえるための夢のシステム それこそがタスクシステム 男のロマン 巨乳大好き おっぱい最高 そういうことだ
286 :
名前は開発中のものです。 :2009/02/08(日) 19:33:57 ID:/7HQNkAm
ゲー専の扱いがひどいなと思ったので追記しておくけど ゲー専にも学校ごとに二、三人ぐらいは優秀なのがいるよ 逆に優秀な大学出てても、ろくにプログラムかけないで口だけのもたくさんいる IPAの岡田くんは最高だがな
>>282 >ただ長く理解しづらいまわりくどいわけのわからないことを書いて惑わすだけ
>定義も何もない、ただそれっぽいことを誰にも理解できないように書いて
>適当に権威のありそうなものを付け加えて
>ごまかしているだけ
あるねー
そういうのやねうらおだけじゃなかったけどね
昔は多少わかりにくくても考えながら聞いてやったけど
いまって時代が変わったってのもあるよね
もう別に奴等の言うことをわざわざ理解してやる義理も必要もないし
情報が氾濫しすぎてて何かしゃべっても説明責任はてめぇの方にあんだよバーカ
で終わる話にもなってるからそういうのに騙される奴も減ってきたよね
相手を煙にまける環境っていうのは相手側が説明を理解しなきゃいけない立場であるときしか役に立たない
いまは2chですらそういうの華麗にスルーされて終わりだしねw
前スレでもどっかのエライ人系(英文w)のリンク貼ったレスは全部無視だしねw
ID:/7HQNkAm 独演会はもう終わったのか まぁしかし、 奴のマイナスの社会的影響は大だな。 奴の原稿にダメ出し出来ない出版社も無能だが。
なぜタスクシステムごときでここまで荒れるんだ? ゲームを一本でも自作したことあるやつなら何らかのタスク管理システムは作ったことあるだろ。 で、このシステムはここが便利だったとかダメだったとか、いろいろなジャンル作ってく中で 洗練されたシステムが作れるようになってくもんだ。その程度のもの。
part3から追ってる限り壮絶なアンチがいるみたい
引数クンx2とobserverクンがひとりいるっぽい。
・タスクという名前が気に入らない ・ゲームオブジェクトを抽象化できない ・タスクシステムを使っている現場でひどい目にあった アンチの理由は大体こんなとこかな。 3番目は稀に、タスクシステムを使わない、自分なりの方法を確立してる人もいるっぽいけど、 それを啓蒙するわけでもなく、罵詈雑言に終始しているので、まあ、同じ穴のムジナかと。
>>289 そうそう、そうなんだよね。
いいとこはのこして、今のゲーム制作で問題あるなら変えていけばいいだけのことで、それを何と呼ぼうがどうでもいい。
そんなことすら理解できないバカが一人か二人騒いでるだけなんじゃないの?
そうそう、そうなんだよねって、よっぽど気があうのね? おまいは井上香美か?
ポエマーは愛されてるな
・問題 ・解決策としてのフレームワークの仕様 ・フレームワークの設計と運用ルールと実装 分けて考える必要がある。 アンチは、もっぱら実装の局部的な問題をもってして、 全部を否定しようとしているだけ。 基地害オナニー独り芝居。 タスクシステム使って酷い目にあったっていうのは、 単に運用ルールを確立・周知していなかったからじゃないのか、という気がする。
じゃあ、大局的なこととして
タスクシステムを使うことによって何のどんな問題が解決するの?
これをはっきりさせてよ
っていうと全くまともなレスが帰ってこないからなw
んで
>>282 の内容に戻るとw
引数で渡すのもきめえ。 キャストするのもきめえ。 Setter/Getter作るのもきめえ。 グローバルで通信するのもきめえ。 ピザな神に任せるのもきめえ。 てな感じで同じく悩み続けてる俺にはここ最近の話はとても参考になってる。 だからもっとやれ。ただし脳内じゃなくてちゃんとわかるようなコードつけてな。
299 :
名前は開発中のものです。 :2009/02/08(日) 22:37:30 ID:/7HQNkAm
いやいや 俺はごく基本的で大局的な見解しか示してない 局部的な話は一切していない さぁ、タスクシステムを大局的に語るがよい 又は3Dでタスクシステムを使うがよいww 偉そうな名前を持った偽科学は消毒だー
>>298 オブジェクト指向の常識に従う限り
ゲームのシーンクラスの肥大化を防ぐ手はねーよ
トリッキーな解釈をして関連をクラスにするとか
ってのは一つの逃げ道かもしれねーな
ただ、それをしたところで俺の上のほうのレス(ID:lLkuERdr)を読んでもらえば分かると思うが
書かなければならない処理の絶対数はどんな組み方をしても変わらない
俺はこれでも10年以上やってきたので設計思想で
できることとできないことが判別できるようになった
だから迷いがなくタスクシステムを糞だと言い切れる
もし、他の可能性を探すならオブジェクト指向を覆すような新しい設計思想が必要
>297 オマエは煽るふりをして自分の理解できないところを質問しているだけだろwww
>300 関連の総数が爆発するのは、不味い設計しているからだ。 そういうのはそもそもゲームの仕様からして不味い。 それをそのまま唯々諾々と実装するようなID:9yKZ63FM=ID:lLkuERdrは馬鹿の見本。
>>301 いままでこれが説明できた人間はいないぜ
無理すんなよw
>>297 「大局的」の意味がよく分からんが。
あくまで、たとえばの話として・・・
○問題設定
プレイヤーキャラを常に画面上に存在させておき、プレイヤーの操作に反応させる。
一定時間ごとに、ライバル・キャラを画面上に発生・消滅させる。
キャラ接触の結果として、随時、火花を画面中に発生させる。
火花は発生後、画面上でアニメーションさせて1秒後に消滅させる。
ライバル・キャラ、火花は複数同時に存在し得るものとする。
画面上での全キャラのFPS当たり移動スピードや、火花アニメのFPS当たり状態遷移スピードは、固定とする。
火花は画面上最前面に表示されるようにする。
(その他細かいルールは割愛)
この問題を解決する方法の一つとして、タスクシステムの存在意義がある。
ところで問題は、それこそ色々あるから、そんなこと聞くだけ野暮だと思うが。
>303 自分が知らないものは存在しないも同然かww
>>302 は?もうお前のくだらない戯言に騙される奴はいないんだよ
オブジェクトが20個あってそれぞれが影響しあうなら
当然それだけの処理がいるの
設計をどうこねくりまわしたってその数が減ることは物理的にないんだよw
>>296 >タスクシステムを使うことによって何のどんな問題が解決するの?
タスクを管理できる。ただそれだけ。
タスクシステムを使わずにタスクをどーやって管理するの?
switch/caseかな?
まぁ、どんな方法だろうとタスク管理をするシステムをタスクシステムというんだから
ゲームにタスクがある以上タスクシステムが無いというのはありえないと思うが。
>>305 は?ちょっと聞くけど
使わないで組んだこと1度でもあるの?
>>307 頭悪すぎ
まず、タスクシステム使わなきゃタスクって単語すらでない
のに何が聞きたいの?
タスクシステム使う前提で話してどーすんだよ
理屈でモノを考える力をどっかに捨ててきたのか?お前
>306 > 設計をどうこねくりまわしたってその数が減ることは物理的にないんだよw キサマの設計のクソさ加減は、>121見れば判るからwwwww
310 :
名前は開発中のものです。 :2009/02/08(日) 23:00:40 ID:/7HQNkAm
>>304 いや、タコスシステムとやらを使わなくても書けるだろ
タスコシステム使ったらどういう恩恵が得られるのかってーのに興味があるんだよ
普通の人々は
早くなるーだの、コードが短くなるーだの、読みやすくなるーだの、拡張しやすいーだの
そういうことを聞いてるわけだ
書けるんだよ書けるんだよって、書ければいいのならHSP使った方が手っ取り早い
>>308 >まず、タスクシステム使わなきゃタスクって単語すらでない
OSのマルチタスクってタスクシステムの話かな?
タスクってのは「処理の単位」以上の意味は無いから
ゲームに処理がある限り「タスク」は存在するんだけどね。
ID:9yKZ63FMの主張は、「mediator」と一言言えば済む話に見えるけど なんか違うことを言ってるんだろうか
>>307 タスクとかいう言葉を何の定義もなく使うところがキモいです。
たとえば
>>304 を実現するのに普通の人はタスクなんて使わないので
管理の必要もないわけでさ。
と書こうとしたら
>>308 に書かれてた。
>>306 は、
マリオがクリボーに触れたときの処理と、ノコノコに触れたときの処理は別々に書くのか。
>>313 ギャラがやゼビウス時代の古典的ナムコタスクシステム(関数ポインタ+ワーク)や
マルチコアのジョブ時間管理やりソース共有管理まで行うMTフレームワークレベルのものも
広義のタスクシステムなんだけど。
これらを一切使わずに
>>304 を実現できる普通の人っているのか?
それとも何か特定の1つのタスクシステム実装についてのみ語っているのか?
>>315 オレはアンチじゃないけど
「広義のタスク」が何を指すのか不明では?
>>49 の「タスクとはすなわちフレームをまたいだ継続的処理の抽象化」を言ってる?
広義の話するなら広義と書こうぜ。 収拾つかなくなるだろ。 古典的ナムコタスクシステム(関数ポインタ+ワーク) これをウンコを管理するウンコシステムと呼んで区別しよう。 話はそれからだ。 アンチが叩いてるのはこのウンコの部分なんだから。
>317 > 古典的ナムコタスクシステム(関数ポインタ+ワーク) 『コンテキスト保存によるフレーム間の継続性』が抜けてるぞ。
>>310 トムヤムクンプロセッサってのは聞いたことしかないから、よく知らん。
結局、並列動作処理フレームワークの実装がブラックボックス依存なんじゃねえの、それって。
ブラックボックス依存で構わないんだったら、ネガキャンするなと言いたい。
とりあえず、描画タイミング、ゲームオブジェクトの移動、当たり判定なんかの処理は一定間隔で行いたい。 だから、単純なゲームのとあるシーンは以下のようになる。 while(1) { 描画 ゲームオブジェクトの移動 当たり判定 時間調整 } 次にタイトル画面を表示するシーンが欲しいなと思ったら、もう一つループを追加する while(1) { 描画(タイトル画面表示) キー入力 時間調整 } シーンの数だけループができた。 じゃあ、このループを一般化して、ハードコーディングではなく、外部からのスクリプト読み込みなどで 動的に生成できないかと悩んでみると、タスクシステム(っぽい何か)に行き着いた。
>>318 ただのFSMではなくコルーチン&スケジューラが実装されていたのなら
そう書いてもらったほうが分かりやすい
>>298 指標をいくつか決めて実装手法ごとに○×付け。一番○が多いのを使う。
これでいいんじゃね?
どういった表現方法使ったってどうせ全部「データの受け渡し」であることには変わりない。
概念的には一つのことを実現しようとしてるだけ。
もし引数の概念が無い言語ならグローバル変数使わざるを得ないし、
グローバル変数の概念が無い言語なら引数使わざるを得ないかもしれない。
この辺の手法の差異なんて言語に左右されるような瑣末なこと。
C++ではたまたまいろいろな手法が利用可能だけども
概念的には「データの受け渡し」だけが目的なんだから、
CPU使用時間とかメモリ使用量とかソース可読性とかそういった瑣末な指標によって選択すればいい。
「C++におけるデータ受け渡しの実装手法はどれが一番概念的に優れてるか」とか悩むのは
そもそも問いかけの選択からして間違ってる。どれも概念的には「データの受け渡し」で同一のもの。比較不可。
優劣が付けられるのは前述の瑣末な指標で比較した場合のみ。
C++がやれること多すぎて悩むの疲れたのならいっそもっと選択肢少ない言語に変えてみたら?
Cとかに。わりと本気で。
#レスなげえ、俺きめえ。ごめんね
C縛りは問題の本質を考える上でいいと思うが 納得しない人たちもいると思う オレはC++大好きデザパタ大好きだが、自戒をこめてこの言葉を君たちに C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが簡単に生産されるようになってる。 正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、 それ自体、C を使う強力な理由になりうる。 -- Linus Torvalds
「ホットスーププロセッサ」・・・チッ、気取った名前付けやがって。 「タスクシステム」を批判できる立場にねーだろ。
>324 いやいや、作ったソフトにどんな名前をつけるかは作者の権利だ。 それについてどうこう言うのと、『タスクシステム』という名前についてアレコレ言うのは 違う気がするぞ。
>>325 悪い、ちょい嫉妬しただけだ。
大人げなかったな。
いや、落ち着いて逝こうぜ。
329 :
名前は開発中のものです。 :2009/02/08(日) 23:49:52 ID:/7HQNkAm
タスクシステムとやらにこだわる人は HSP使った方がいいよ、資源の無駄 かっこつけてC++なんて使う意味ないって 俺かっこいい超天才C++使いこなす俺超天才って言って 一ヶ月かけて作ったゲームも HSPなら三日で作れるから 所詮タスクシステムなんてその程度 DSL的アプローチとしてはHSPの方が有益 タスクシステムはうんこ うんこに指差してうんこって言って何が悪い これはうんこじゃないやいって言ったところで それはうんこだ うんこうんこ
あぁ、ウンコが何か吠えているw
>>328 いっぺん表作っちゃえば二度と悩まなくて済むよ
処理時間短縮重視ならこれ、メモリ使用量極小を狙うならこれ、
とかって簡単に決定できる
まぁ、大体PCならメモリとかCPUなんて潤沢に使えるから気にせず
コードの可読性だけでさくっと決めていい気がするけど
>>315 普通にできるだろ
馬鹿かお前大丈夫か?
ていうか一度でも組んでみてから言ってくれよ
つーか、お前、タスクシステム云々がどうとかそういうところこだわる前に
プログラマとしてヤバイだろw
実際HSPでもシューティングゲームぐらい作れるしな。
HSPで済むならそれを使っておけばいいんだよ。 適材適所。
>>315 なーにが広義のタスクシステムだ。バッカじゃねーの?このカッペ野郎
毎度毎度テメェの都合でローカル用語の解釈を変えてんじゃねー
あと"ジョブ時間管理"とか訳のわかんねー用語を発明すんな
お前いつもそんなふうに新しい用語をクリエイトしながら他人とお話しするの?
>>320 こ
タイトル画面や戦闘シーンは、相互依存がほとんどなく、インスタンス数もたかが知れてる。また処理パターンが仕様変更で変わる可能性がある。
そういう用途には、std::list<> に virtual void exec() だけ実装したクラスのインスタンスを入れておいて、定期的に呼び出してやれば良い。システムと呼ぶ程のモノじゃないがな。
一方、プレイヤーや敵キャラなどは、上の前提条件が成り立たない。相互依存が多く、処理も一度「移動、ヒット判定、死亡判定」と決めたら、まず変更しない。
困難なポイントが違うので、解決策も必然的に変わってくる。
>>335 >あと"ジョブ時間管理"とか訳のわかんねー用語を発明すんな
まだ君の頭では理解できないことかもしれないけど
”MTフレームワーク”でググって勉強してみれば意味が分かるかもね…
もうちょっと違う切り口から。 今、ゲームを ウィンドウ と DirectX と ゲーム管理 と ゲームオブジェクト の4つに分けて考える。 データの流れ(処理の流れ)に着目すると、 DirectX → ウィンドウ ↑ ↓ ゲームオブジェクト ← ゲーム管理 という関係が成り立っている。 ウィンドウと入力と出力に分解すると、 ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out) となり、<入力>→<プログラム>→<出力> という昔ながらのシンプルなモデルになる。 ところがここにオブジェクト指向の概念(データ構造でプログラムを分解する)を導入すると、 ウィンドウ→DirectX→ゲーム管理→ゲームオブジェクト となり、前述のデータの流れ(処理の流れ) ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out) と相反してくる。 この問題を解決するには、データ構造とデータの流れ(処理の流れ(制御構造))をそれぞれ別々に記述できる C言語が最強ということになる。カプセル化なにそれ。
わけのわからない例題は読みたくないという人へ。 プログラムの三大要素は ・データ構造(struct、etc) ・制御構造(function、etc) ・定数(define、etc) である。 それぞれ別のものだから、別々のところに別の方法で別々に作成するのがCスタイル。 一方、データ構造に合わせて制御構造と定数を分断し、すべてデータ構造に括り付けるのがC++スタイル。 当然、C++スタイルでは制御構造は制御的に意味のないところで分断される。 また、C++には制御構造をどこでも分断できるようにするためのナイフが用意されていて、それが仮想関数。 プログラマは仮想関数を使いデータ構造にしたがって制御構造を分解する。 晴れて本来一つのまとまった処理だったものがあちらこちらに散らばる。
>>341 今一度C++で何が起こったか考えるべき。
データ構造と制御構造と定数はそれぞれ別々のもの。
一つに纏めようとするのはナンセンス。
MVC 知らない奴は サヨウナラ
MVCとか的外れもいいとこ
定数を分ける意味がわからん
> ウィンドウ→DirectX→ゲーム管理→ゲームオブジェクト >となり、前述のデータの流れ(処理の流れ) > ウィンドウ(in)→ゲーム管理→ゲームオブジェクト→DirectX→ウィンドウ(out) >と相反してくる。 ミドルウェア(グローバル関数)→ゲーム管理(シーンクラス)→ゲームオブジェクト(クラス群)→ミドルウェア こうならいいのかな。よく分からんけど。
>>345 C++とかだと、定数は、
class C
{
private:
enum{ HOGE_MAX=10, PIYO_SIZE=100, };
public:
enum{ ERR_MEM=1, };
};
とかするのが美徳とされている。
>>336 それは、プレイヤーや敵キャラのループはハードコーディングしかありえないって意味?
あるいはループとは違う仕組みとか。(タイマ割り込みとか)
>>339-340 それは単なるプログラミングスタイル(表現)の違い。
Cを始めとする手続き型言語を用いたプログラミングでは処理を始めから最後まで小説のように一本の線で書くことが得意。
それに対しC++やJavaを始めとするオブジェクト指向な言語によるプログラミングでは地図のように、オブジェクト間にはりめぐらされる道(ネットワーク)によってプログラムを表現しようとする。
だからソースを上から順番に読めば全体が理解できるとかいう話では無くなる。
C++で書かれたプログラムの全体を理解したいのであれば、クラス図(UML)でも書き起こすと良いと思うよ。
Doxygen対応のコメント書いておけば自動生成できるし。
>>346 ゲームオブジェクト(クラス群)→ミドルウェア
の部分はどうなってるの?
1.ミドルウェアはグローバルであり、どこからでもアクセスできる。
2.ミドルウェアへのアクセサは処理の都度、引数でもらう。
3.ゲームオブジェクトはミドルウェアへのアクセサを内部に保持している。
(ゲーム管理クラス経由、など間接的な場合を含む)
351 :
名前は開発中のものです。 :2009/02/09(月) 18:07:00 ID:pOUPLq7j
で? なんかごちゃごちゃ長いけど タスクシステムが何の問題の何を解決するのかでたのかい?
>>348 >それに対しC++やJavaを始めとするオブジェクト指向な言語によるプログラミングでは地図のように、
>オブジェクト間にはりめぐらされる道(ネットワーク)によってプログラムを表現しようとする。
あなたは「オブジェクト指向では地図のように〜〜」と言うが、その理由までは考えないのか。
また、そういう性質はゲームに向いていると思う?
「地図のようにはりめぐらされるネットワークによってプログラムを表現」したい?
それに例えオブジェクト指向でも、地図のようにはりめぐらされるネットワークは決して歓迎されていない。
>>350 データ構造よりもデータの流れ(処理の流れ)
ミドルウェア(グローバル関数)→ゲーム管理(シーンクラス)→ゲームオブジェクト(クラス群)→ミドルウェア
を重視した設計だね。
354 :
名前は開発中のものです。 :2009/02/09(月) 18:51:16 ID:ixLiaNv+
次の新説 タスクシステムは実はフレームワークだったのだよ なにー!?
>>338 > まだ君の頭では理解できないことかもしれないけど
http://www.google.co.jp/search?hl=ja&q= "ジョブ時間管理"
"ジョブ時間管理"との一致はありません
google様が聞いたことねーっつってるわけ。意味わかる?
お前はそんだけ奇特な用語をポコポコ発明してるわけよ
自覚ねーの?ワナビーだから?知ったかクンだから?巣篭もりしてっから?
とっとと部屋から出ろよバーカ
で、もしかしてお前、ジョブスケジューラとかジョブスケジューリングのことが言いたいの?
だったら何で
>”MTフレームワーク”でググって勉強してみれば意味が分かるかもね…
何でMTフレームワークでググって勉強とかいう超絶的に頭悪そうなお話になるのかな?
ジョブスケジューラとかジョブスケジューリングってもっと汎用的な、OSの概念だよねぇ?
MTフレームワークのお勉強?低学歴ワナビーは紹介記事を読んだだけでお勉強になるの?
おめぇそんなんで何かを知っちゃった気になれるわけ?ワナビーが背伸び発言するには十分なの?
356 :
名前は開発中のものです。 :2009/02/09(月) 18:59:43 ID:ixLiaNv+
タスクシステムは何なの イディオムなの? デザインパターンなの? フレームワークなの? それとも、それらを超越した存在、神いわゆるGODなの? それとも、新しいプログラミング言語のプロトタイプなの? それとも、やっぱりただのうんこなの? 謎は深まるばかりだ "working time management" マイナーなつづりだな、きっと一部の選ばれしものだけが読める 論文かなんかで秘密裏に発表されているんだろう 俺ら凡人に対してそんな高度な言葉を使うなんて 普通に嫌な奴だな
>>275 mediatorやobserverがゲームプログラムの中に登場するというなら問題ない
タスクシステム(
>>2 )の中にmediatorやobserverがあるというなら知能障害確定だな
ねーよ。どこにも
前スレで
>>2 はオブサーバーだとか言って喚いてたバカに何度も何度も何度も
何で?何で?何で?何で?何で?何で?何で?何で?何で?何で?何で?
と質問責めにしたが、まともな返事は返ってこなかった
>>357 帰ってきてたじゃん
アレだろ?
更新タイミングはメッセージじゃね?
って返答だっただろ?
んでそうだよ→ちがうよ→そうだもん→ちがうもん・・・以下ループ
で終わったじゃん
俺は当事者じゃねぇけどw
ビデオゲームにおけるジョブ。ジョブを分解したタスク
タスクという内部の処理単位を扱う何らかのシステムであるわけだ
>>2 はビデオゲームにおけるあらゆる処理を1/60[sec]で起床させる
何で?何で?何で?何で?何で?何で?何で?何で?何で?何で?
バカ?バカ?バカ?バカ?バカ?バカ?バカ?バカ?バカ?バカ?
ほれ。これに答えた奴は一人もいねーよ
機械語で組んでた頃のテクニックの代替手段なんて今はいくらでもあるんだから好きに作ればいいのに
だよねぇ
362 :
名前は開発中のものです。 :2009/02/09(月) 23:04:12 ID:ixLiaNv+
タスクシステムは、こびりついて流れないうんこみたいだ すげぇむかつく 設計の本読んで初めてタスクシステム詐欺に騙されたと気づいたときには 無意味なクソコードを何ヶ月も書いていたあのいまいましい思い出と共に うんこと一緒に流れてしまえ いまだにタスクシステムを擁護している連中は 俺から見ると、やっと流したウンコを拾ってきてまたこびりつけるような奴だ このクソいまいましい観念は俺が3Dを覚えるときにも邪魔しやがった 本当に俺の前に立ちふさがるうんこだった このうんこは除去しなければならない
「オブジェクト指向(Object-Oriented)という言葉は私が作った。そのとき、C++ を想定していなかったことは確かだ」
>>287 >そういうのやねうらおだけじゃなかったけどね
>昔は多少わかりにくくても考えながら聞いてやったけど
>いまって時代が変わったってのもあるよね
>もう別に奴等の言うことをわざわざ理解してやる義理も必要もないし
>情報が氾濫しすぎてて何かしゃべっても説明責任はてめぇの方にあんだよバーカ
説明責任かー。前スレでそれ絶叫してシカトされまくってたタスクバカがいたなぁ
自分に都合の良いウソを語る奴には説明責任を追及しないくせに
自分に都合の悪い事実を語る奴に説明責任を追及するタスクバカ
例えば、タスクバカにとってタスクシステム(
>>2 )ってのはゲーム業界固有の秘儀!至宝のテクニック!
であらねばならなかったわけなんだが、その根拠レスな確信を揺るがしかねない歴史的事実には
頑として抵抗して耳を塞いでたな。ほんとカルトってこえーわ
んで、「それはスレ違い!スレ違い!タスクステムと関係ないから関係ないから!」って一人で騒いでたね
>351 なんか今日は違う流れっぽい。
ウンチタスク厨(=アンチタスク厨)に聞きたいんだけどさ、
>>2 の代わりとなるわかりやすい原型を紹介してくんねーかな?
「普通に書く」っていうけど、その実態がよく分からんから、
普通の人に、鼻つまみモノ扱いされるんだと思うぞ。
タスクシステムについては、
>>2 で最も初歩的な原型が示されているわけだしさ。
367 :
名前は開発中のものです。 :2009/02/09(月) 23:58:01 ID:ixLiaNv+
コマンドをリストに突っ込んでるだろだろーが それを万能のフレームワークのようにありがたがって無意味に誇張して 本質を語る邪魔をする、全て捨てろ、それは錬金術だ 今の体系的なパターンに含むことも出来ない過去の遺物だ タスクシステムをありがたがっている奴は 設計の本なんて一冊も読んだことがないだろ、DSLすら知らないだろ 過去の栄光にすがっていると自覚しろ わしの若いころはこうじゃった、だからお前もこうしろって じじいかよ、性質の悪い爺かよ 役に立たない上に新しい観念を考えるときに邪魔にしかならない 最初に覚えるべきことじゃない、それは博物館に飾って置いておくだけのもので 実用するべきものじゃない うんこー
while ( true ) { wait_vblank(); 自機.update( ... ); foreach ( 敵 in 敵リスト ) 敵.update( ... ); foreach ( 弾 in 自弾リスト ) 弾.update( ... ); foreach ( 弾 in 敵弾リスト ) 弾.update( ... ); checkCollision_自機vs敵弾( 自機, 敵弾リスト ); checkCollision_自機vs敵( 自機, 敵リスト ); checkCollision_敵vs自弾( 敵リスト, 自弾リスト ); } とかやっていくんじゃないの? これでも出来ないことは無いよ。
369 :
名前は開発中のものです。 :2009/02/10(火) 00:11:36 ID:KBLQ7wOO
>>368 その部分を汎用的にすることを止めれば
すなわちタスコシステムを使わないという選択肢を取れば
使える手が増える、増えるワカメぐらいに増える
それが様々なパターン、フレームワークの選択に繋がる
そこを汎用的にすることに執着することが、もっとも愚かしく
そして考えの浅さを露呈している箇所である
そこを隠しても大きなメリットはない
男の乳首と同じだ、わざわざ隠すような所ではない
お前らは乳首を隠してパンツはいてない
そういう間抜けなことを他人に強要しているのだよ
君たちはノーパン信者なんだよ
何も知らない奴に乳首を隠せノーパンに目覚めよと言っている
恐ろしいカルトなのだよ
>>367 否定的見解はよくわかった。
だがしかし、
>>2 に代わる初歩的原型は具体的に無いということだな。
>>368 それって実質タスクシステムじゃん。
>369 > それが様々なパターン、フレームワークの選択に繋がる じゃ、タスクというパターンを選択してもいいんだ。 よかったな、お前ら>1-1000
>>370 いや、原型が
>>368 なんじゃね? もうベタベタまんまの原型なんじゃね?
で、
>>368 を↓という風に美しくまとめたのがウンコシステムじゃなかったっけ?
while ( true )
{
wait_vblank();
foreach ( ウンコ in ウンコリスト )
ウンコ.update( ... );
}
んで、↓みたいなのはウンコ同士のつっつきあいで表現するんだろ?
ウンコがウンコを生成したり消滅させたりしながら。
checkCollision_自機vs敵弾( 自機, 敵弾リスト );
checkCollision_自機vs敵( 自機, 敵リスト );
checkCollision_敵vs自弾( 敵リスト, 自弾リスト );
違ったっけ?
違ったらスマン。
なんでリストを一つしか持たないって仮定してるんだろう?
>>370 >それって実質タスクシステムじゃん。
うん
実質は同じだ。データのやりとり。
違うのは可読性。
実質は同じ。
違うのは可読性。
実質は同じ。
違うのは可読性。
>>371 タスクはOK
マルチスレッドの単位もスレッドだし。
だがタスクシステム。てめーはダメだ!
class BaseTask { virtual void update( Context& ); }; typedef list< BaseTas* > TaskList; class JikiTask : public BaseTask { ... }; class TekiTask : public BaseTask { ... }; typedef list< TekiTask* > TekiList; class JidanTask : public BaseTask { ... }; // 自弾全部管理してるタスクだと思えw class TekidanTask : public BaseTask { ... }; // 敵弾全部管理してる(ry ==== TaskList tasks; JikiTask jiki; TekiTask teki[100くらい]; TekiList tekis; JidanTask jidan( 100くらい ); TekidanTask tekidan( 弾幕系なので2000くらいw );
tekis.append( teki全部 ); tasks.append( jiki ); tasks.append( teki全部 ); tasks.append( jidan ); tasks.append( tekidan ); while ( true ) { wait_vblank(); foreach ( タスク in tasks ) タスク.update( context ); 当たり判定( jiki, tekis, tekidan ); 当たり判定( jidan, tekis ); } とかはイカンのか?
なんか tasks.appen( teki全部 ); が一つ余計だな。
378 :
名前は開発中のものです。 :2009/02/10(火) 00:41:18 ID:KBLQ7wOO
c = a + b; これをタスクシステムに投入すると list.add(a).add(b).add(new C(a, b)).execute(); c.execute() { value = a + b; } こうなる dという要素をこのリストに突っ込む場合 abcがdに干渉されないのであれば d.execute()を適当に実装すればよい 干渉するのであればabcのexecuteを修正する よって追加に強いというメリットはないと断言できる コマンドのメリットである追加に強いというメリットはない ないのだよ これじゃあコマンドパターンの意味がないじゃないか この屈辱、コマンドに対する屈辱 コマンドパターンがかわいそうだ タスク信者はコマンドパターンに謝れ、あやまれよぅ
>>374 >>368 は局部的な実装をちょこっとだけ厚化粧しただけ。
その程度の可読性有り難がってどうすんだよ。
必ずしも個々のオブジェクト(タスク)の発生と消滅のタイミングが整然としている、
例えば60フレームごとに、全タスクが一斉に発生・消滅してるわけじゃないじゃん。
つまり発生と消滅のタイミングが、微妙にずれていることにより、カオスが表現できる。
しかしカオスな状態を裏方で制御する努力は、
>>2 でも
>>368 でも変わりがない。
つまりさ、
現実を見ろ、
タスクシステムに立ち向かえ、
カオスを克服する運用ルールを見極めろ、
ってことだよ。
『可読性が悪い』って言ってるのは、『オレ頭悪いからワカンネぇしwww』って言ってるのと実質同義?
381 :
名前は開発中のものです。 :2009/02/10(火) 00:53:47 ID:0//SUk3r
可読性を軽んじる香具師は職人オナニープログラマー
実質同じ? いや、やっぱ同じじゃないと思うぞ。
主従関係があるとないとでは全然違う。
要素が要素に直接干渉し、要素がさらなる要素を生成消滅させるのと、
リストを扱う奴が要素同士の関係を管理して、要素を生成消滅させるの、
違うよな。
>>336 がFAでいいと思うがな。
>タイトル画面や戦闘シーンは、相互依存がほとんどなく、インスタンス数もたかが知れてる。また処理パターンが仕様変更で変わる可能性がある。
こういう部分で
>>2 を使うことには何の異論もない。
「相互依存がほとんどなく」ってのがポイント。
タスクシステムとかいう単語を見るとな、全部ウンコリストの中でやっつけようというイメージがあるんだが、ちゃうの?
ちゃんと使い分けしてるんならそれは否定しない。
>>2 は否定する。全部一緒だから。
あぁ、そういえば昔 仮想関数とか関数ポインタとか使うと 可読性が悪くなってデバッガで追えなくなるから 全部switch/caseで書けって言ってたプログラマが居たなぁ…
>>379 馬鹿じゃね。
>例えば60フレームごとに、全タスクが一斉に発生・消滅してるわけじゃないじゃん。
>つまり発生と消滅のタイミングが、微妙にずれていることにより、カオスが表現できる。
それのどこがカオスなの?寿命管理なんて、結局自クラスで閉じてるジャン。
そんなことより、例えば、宇宙に漂う星々を観賞するソフトをタスクシステムで作ることを考える。
星をタスクで実装したとして、各星の間に働いている万有引力はどう記述するの?
現実を見るのはお前だな。
>384 厳密にやるならワークをそれぞれ2つ持って、フレームごとにフリップだろ。 面倒だったら一つ一つ更新して、n+1がnを参照してもn+1を参照しても対して問題が無い様にするさ。 どこまで誤差を容認できるか知らんけど。
>>384 そーいうタスクの実行順序が結果に影響する場合は
実行時間単位でタスク状態のスナップショットを取って相互参照はそのスナップショットを参照、
という方法で擬似的に「いっせーのせ」をやる方法を物理演算系ライブラリでよくやってる。
>>373 >
>>2 に代わる初歩的原型
初歩的原型?
>>2 が?どーこがだよ
なんだこれ。ジョブエントリのリストを周期的にナメナメしてバッチ処理するだけ
なんでこれがゲームプログラムの初歩的原型なんだよ。バカこくでねーよ
・おめぇ、何か処理したかったら必ず先頭にTCB(は?)を入れたデータ構造にしろよ
・おめぇが書いた処理はどんなものだろうと必ず1/60[sec]で周期的に呼び出すからな。覚悟しろよ
・俺に呼び出された後はてめぇの責任で全部やりな。俺は何にもしらねーからな
こういうちゃんこ鍋ポーリングヘンテコプログラムをゲームプログラムの原型とかほざく理由を書け
で、何でか知らないが僕タスクシステム!って言って紹介してる糞は揃いも揃って ユーザーのあらゆる処理単位のデータ構造にTCBとかいうものをねじ込んでるよな ・サブルーチンアドレス ・プライオリティ ・連結リストのパラメータ みんな仲良くなーぜかこういうものを押し付けてきやがる。なーんでなんで?どうして? おまけにこれが日本ビデオゲーム業界黎明期の秘儀であるなどと権威付ける。正気か? だったら何度だっていってやる。RAM4KBにROM数十KBにBGやOBJを出力する回路を 積んだZ80マイコンボードでこれ組んでみろよ。ほれ そして、この仕組みをそのまんま ・64bitマルチコアCPU ・数GBのメインメモリ ・ローカルメモリ数百MB搭載のGPU(DSP)カード こういう環境上で律儀に真似しようとするのはなーんでなんで?どうして?
>387
>
>>373 > >
>>2 に代わる初歩的原型
> 初歩的原型?
>>2 が?どーこがだよ
俺のレスに突っ込みかよw
>>385 >>386 それは論点が違う。書き方が悪かったかな・・・
>宇宙に漂う星々を観賞するソフトをタスクシステムで作ることを考える。
>星をタスクで実装したとして、各星の間に働いている万有引力はどう記述するか。
この問題の論点は、タスクシステムにおいて、タスク間にまたがる処理はどこに書くのか?。
>391 とりあえずこの問題に限定するけど、フリーの物理エンジンの実装見たことある?
>>388 >こういう環境上で律儀に真似しようとするのはなーんでなんで?どうして?
そのまま同じコードで実装して使ってるところは無いと思うけど。
特にC++が主流になった現場では。
まぁ、同じ考え方のシステムはスペックにあった実装されて使われてるけどね。
スペックに関係なくゲーム作るうえで処理のプライオリティ付きでゲームの状態遷移によって出し入れできるタスク管理は便利だから。
他にいい方法があれば淘汰されてるだろうけど、この考えのシステムを淘汰できるような物は今のところ無いみたいだしね。
>388 FPSなんかは、全部仮想関数でupdateを持つEntityクラスのサブクラスにしてたりするよ。
>395 答えが全部書いてあるから、見てみるといいよ。
>>396 逃げるなよ。絶対書いてないと断言できる。
今ここで示して見せてくれ。
位置と速度を分離して、万有引力は個々の更新で処理しない。 万有引力は距離関係ないけどまぁ有効距離を設定したとして、一つ一つの星にかかる引力を合計して その星の質量から加速度と速度を計算する。 で、単位時間(多分1フレーム)あたりの移動量がでるから、それを位置に加算するだけ。
>>393 >>394 数値積分の(代表的な、最小の)タイムステップとして例えばリフレッシュレートを選択し
そのタイムステップで可視属性のエンティティの処理を周期的に呼ぶというのは問題ない
アニメーション処理など、表示系の処理はリフレッシュレートに同期させないと美しくないからだ
>>2 が腐ってるのは「あらゆる処理をちゃんこ鍋リストに入れてリフレッシュレートを基準に
周期的にバッチ処理して起床させる」というトンチンカンプログラムだから
>>398 >一つ一つの星にかかる引力を合計して
どこで合計するの?誰が合計するの?星タスクの中でやるの?
結局、タスクシステムの外で計算するしかないんじゃないの?
>>394 例えばFPSのエンジン。これのエンティティのMODを作る人間がユーザーとしよう
エンジンは内部ではBSPなりPVSで空間領域分割しているがMODの開発者は
そんなこたしらねーわけ
可視範囲内にいる脅威のデータをくれっていえばエンジンはくれるわけ
例えば視界のコーン(or視錐台)を渡して、最近傍のバカのデータをよこしてくれる
俺が使ったのはそういうエンジンだった
敵AIを作る奴の目的はレベル内の敵性物体の掃討であり、それを適切に連携しながら
行なうことだ。
タスクシステムってのは
脅威の情報くれ ⇒ エンティティのちゃんこ鍋リストあげるからテメェで探せバーカ
こういうもの
>>399 画面のリフレッシュレートは特にウィンドウモードの場合まちまちだから、
ゲームロジックのFPSと描画のFPSが別々になることがある。
例えば、ゲームロジック60FPS、描画72FPSとか。
この辺のギャップを滑らかに埋める仕組みを作るのは結構面倒。
俺の自作描画エンジンはそれを勝手に面倒見てくれるように作ってる。
それすら実装されてないのにタスクシステムとか言われても・・・ねぇ。
>エンティティのちゃんこ鍋リストあげるから あ、これですらないわ。全処理のちゃんこ鍋リストだわ。ははーは
>>402 >画面のリフレッシュレートは特にウィンドウモードの場合まちまちだから、
YES。フルスクリーンであろうと指定したリフレッシュレートにしてくれない
ポンコツビデオカードがまかり通ってた時代もあるしな
>ゲームロジックのFPSと描画のFPSが別々になることがある。
YES。そのとおり。そしてリフレッシュレートが既知であろうとなかろうと
AIを作る奴にイベント駆動システムを提供することだってある
これはゲームエンジンが階層型スケジューラをサポートしている
>>399 >「あらゆる処理をちゃんこ鍋リストに入れてリフレッシュレートを基準に周期的にバッチ処理して起床させる」
これ、FPS単位では無いけどタイムシェアリングのOSのスレッド管理と同じような考え方だね。
タスクシステムもスリープ状態とか、スレッドのようなフラグ付けして使うのはよくある実装。
独立した時間軸のある処理を複数持ちたい、となるとスレッドなりタスクシステム的なものが必要になるわけで。
で、ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に無駄なのでもっと簡素なシステムを使ってると、
そんな感じじゃないのかな。
別にそんなトンチンカンでは無いと思うけど。
タスクシステムで出来ることを全て網羅していてもっとスマートな方法があるならそれを使えばいいんだろうけど…
今まで見たことあるのは結局タスクシステム+αしたようなタスク拡張システムで、パラダイムの違うのは見たこと無いなぁ…
>ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に >無駄なのでもっと簡素なシステムを使ってると、そんな感じじゃないのかな ん。違うな。やねちゃんではないな 協調的マルチタスクシステムがタスクシステム的だとか言わんよな。彼なら 眠気を我慢してる状態でごにょごにょ長文を読むとみんなやねに見えるから困る 寝る
やねちゃんは、にちゃんなんか歯牙にもかけないでしょJK
>>405 >これ、FPS単位では無いけどタイムシェアリングのOSのスレッド管理と同じような考え方だね。
>タスクシステムもスリープ状態とか、スレッドのようなフラグ付けして使うのはよくある実装。
FPS単位とかよくわかんないけどさ
オラが村の自慢の生娘のウンコ(タスクシステム)に似てるとかドーデモイーわけ
所詮はローカル用語。お前さんの自慢のタスクシステムなんて誰も興味ねーし
お前さんが自慢のウンコを職場内でタスクシステムと呼んでようがドーデモイーわけ
俺がバーカバーカって言ってるのは公衆の前でタスクシステムとして布教されている
>>2 そして
>>2 を超すごいオーパーツだとか可搬性と再利用性に優れたミラクル秘儀だとか
祭り上げてる(いた)バカ共
あと、定義不明瞭なオラが村のローカル用語(タスクシステム)を引っ張り出して擁護するイナカッペ
誰もてめぇのひりだしたウンコの名前の良し悪しの話なんてしてねーから安心しろ
>>405 >独立した時間軸のある処理を複数持ちたい、となるとスレッドなりタスクシステム的なものが必要になるわけで。
いやだからそのタスクシステム的ってナニ?意味わかんねーのよ
なんでそういうオラが村のローカル用語を駆使するの?自覚ある?ない?
まずお前のいうそのタスクシステムってやつを説明してくれないと
ホント意味わかんねーから
>で、ゲームの場合はオブジェクト毎にスレッド立てるなんてのはパフォーマンス的に
>無駄なのでもっと簡素なシステムを使ってると、 そんな感じじゃないのかな。
もうチンプンカンプンだよ
お前さんは一体ナニが作りたいの?協調的マルチタスクシステムが作りたいの?
だったら何でそれが
>>2 になっちゃうの?コンテキストスイッチはどこ?目的と実装は一致してるの?
何度も言うけど、一体ナニが作りたいの?ゲーム作りたいんじゃなかったの?目的変わった?
>>405 >別にそんなトンチンカンでは無いと思うけど。
ちゃんこ鍋リストに全てをぶち込んでバッチ処理がしたいんであれば
>>2 はトンチンカンじゃないな
ちゃんこじゃなくてウンコ鍋だったっけ
>タスクシステムで出来ることを全て網羅していてもっとスマートな方法があるならそれを使えばいいんだろうけど…
網羅する必要?どこにあるの?ねーよ?まず、ゲームは
ちゃんこ鍋リストに全てをぶち込んでバッチ処理する必要ねーから
でもお前はある。しかもタスクシステムが出来ることが他にもあるという。
網羅できないと駄目だと。じゃあこれについて語ってくれないか?
お前のタスクシステムで出来ることを全て網羅的に説明してくれ
逐一、それが
>>2 である必要がないことをみんなが説明できるぞ
>今まで見たことあるのは結局タスクシステム+αしたようなタスク拡張システムで、パラダイムの違うのは見たこと無いなぁ…
たしかに
>>2 は強烈なウンコパラダイムだな。ウンコパラダイムシフトってのは巻き糞なのかな?
あーん出勤の時間だ。ばいばい!
>>411 >ちゃんこ鍋リストに全てをぶち込んでバッチ処理する必要ねーから
まったくその通りだなw
>400 だから『個々の更新で処理しない』って書いてるでしょ? 中じゃなかったら外でやるしか無いじゃん。 >401 そこまで判ってるなら言うこと無いよ。 実行巡回リスト以外に、必要な各種コンテナを追加すればいいだけ。 だいたいその存在目的が違うのに、なんで『ごった煮リスト』からEntityの検索をしないといけないんだ? > 脅威の情報くれ ⇒ エンティティのちゃんこ鍋リストあげるからテメェで探せバーカ オマエの邪推だろ。 実行巡回リスト以外に管理しているものがあるとか想像できない、その貧しい発想がダメだな。
>>2 について採決を取ろうか。
話がぶれすぎ。
ウンコ信者は
>>2 をよく見て、それに含まれていないものを勝手に追加したり「想像しろ」とか言わないように。
>>2 について決着がついたら、更なる進化系ウンコを提示してもらおう。
あと、質問には単純明快に答えてほしいな。
「どこで?」と聞かれたら「ここで」と答えよう。
「他のソース見たことある?」とか「フリーのソース見ればわかる」とか「こう計算する」とか「中ではない(だから外だ。でもどこかは言明しない)」ではなく、
明確にどこかを示してほしいもんだ。
416 :
名前は開発中のものです。 :2009/02/10(火) 19:16:53 ID:KBLQ7wOO
対話は無理じゃないのか タスカーの目的は保守だから逃げたり煙に巻くことだけを考えている だからごまかせればそれでいい、逆に揚げ足取りを狙うだけ 自分からサンドバッグになるほどバカじゃないだろう
やねうらおの人生みたいだな
418 :
名前は開発中のものです。 :2009/02/10(火) 19:35:00 ID:KBLQ7wOO
>>2 のいくつかについて
使い方だけが記述してある
使う理由や、使うことで得られるもの等は書かれていない
3Dではレンタゲ絡むから単純にコマンドリストにしてソートして描画は無理
一つをレンダリングした後にそれを加工して他に適応するような
複雑な手順が必要となるから、ほぼ間違いなく複雑になる
これを見てくれ、何かが色々とおかしい
>長所は次の通りです。
> * ジャンルを問わず様々なゲームに適用できる
> * 並列処理をうまい具合に実現できる
> * ゲームの流れを自然な形で表現できる
> * 大規模なゲームも開発できる
> * タスクごとに独立しているため、複数人で開発できる
無理やりメリットを列挙した感が伝わってくるよ
419 :
名前は開発中のものです。 :2009/02/10(火) 19:48:28 ID:KBLQ7wOO
俺の主観 > * ジャンルを問わず様々なゲームに適用できる ジャンルごとに最適な作り方を模索しようぜ 木造一戸建ての家と鉄筋コンクリートのビルを同じ手法で作らなくてもいいじゃないか > * 並列処理をうまい具合に実現できる そのうち、インテルが優秀なコンパイラを作って解決してくれるようになるさ GPUの並列処理では使えない、全く役に立たない > * ゲームの流れを自然な形で表現できる 自然な流れといったら、俺にとってはDSL、内部でも外部でもいいけど DSL的アプローチとしてはHSPをそのまま使った方が比較できないほど有益 > * 大規模なゲームも開発できる 使わなくても出来るだろう "大規模なゲームを簡単に開発できる"と書かないあたり良心的 > * タスクごとに独立しているため、複数人で開発できる クラスで見かけ上分離しても、データのやり取りで 相互依存関係が存在しているので独立しているとは断定できない 近い箇所でわざわざ分けずに、サブシステムで担当分けろ
420 :
名前は開発中のものです。 :2009/02/10(火) 19:55:43 ID:rFLiGfwY
タスクは少しでも処理を稼ぎたい時くらいしか使わないな。 あと、クラスとタスクを勘違いしてる奴が多いな。
銀の弾丸なんかありゃしないんだから、好きなように書けば良い。タスクシステム使いたければどうぞ。 イヤならそれで構わない。 というスタンス。 もっといろんなソースを読めばいいのに。そこいら中に転がってるんだし。
422 :
名前は開発中のものです。 :2009/02/10(火) 20:58:01 ID:KBLQ7wOO
Golden Hammer ジャンルごと、ゲームごとにルール、論理は異なる にも関わらずなぜ共通の処理を用いようとするのか なぜそこまで固着できるのか、それ以外を否定し続けなければならないのか もはやカルト的、ゲーム脳的、マイナスイオン的 これは広義のタスクシステムなのだよっと言って 俺まで仲間にされたんじゃあ、たまったものではない 今こそ、そのこびりついたウンコを便器の奥に流し去るとき
ジャンルごと、ゲームごとにルール、論理は異なる にも関わらずなぜタスクシステムを否とするのか なぜそこまで固着できるのか、それを否定し続けなければならないのか もはやカルト的、ゲーム脳的、マイナスイオン的 これは絶対的に醜悪なシステムなのだよっと言って 悪魔の仲間にされたんじゃあ、たまったものではない
くっそー、Kindle2欲っしいなぁ。
誤爆スマン
>>384 >それのどこがカオスなの?
ある時点で、n個のキャラが発生し、だんだん大きくなり、5秒後きっかりに消滅する。
これをnキャラ分同時に繰り返すのが非カオスな状態。
一方、発生時刻、大きくなる時間、消滅時刻をnキャラ全てでずらしてやる。
これを各キャラ別に繰り返すのがカオスな状態。
どうせお前のクソ生産物は、この程度のカオスも実装してないんだろ。
>各星の間に働いている万有引力はどう記述するの?
まず、空間を適当なグリッドに分けてやる。
そして、(z断面数×仮想重力場2次元配列×n方向断面)×2スロットを管理するタスクを、最低プライオリティで
登録。
スロットは1つが【更新用】、もう一つが【参照用】。
各星タスクが呼ばれる際に、付近の【更新用】重力場配列n方向分の値を、遠小近大で所定の範囲を足し算更新する。
足し算する値の大きさは、星の重さごとに異なるものとする。
同時に、【参照用】重力場配列n方向分の直近の値を合成して、加速度ベクトルを決定、自速度に加速。
仮想重力場2次元n方向分のスロットの【更新用】と【参照用】は、フレームごとに切り替える。
【参照用】スロットは毎フレーム、0で全初期化。
タスク登録処理部で、星タスク登録時に、重力場タスクへの参照を渡しておく。
バカはすぐ馬鹿と口にする。むじゅかちい問題よりも簡単なタスクシステムから始めた方がいいんじゃないでちゅか。
>>387 >(
>>2 )ゲームプログラムの原型とかほざく理由を書け
ボケが記事読めや、ググレカスチンカスが。むいて洗えや。
>>2 は、万里ゆうじ氏が、業界現場で使われていると書籍で紹介していた初歩的タスクシステムともおおよそ同じ。
くだんね 結局、関連の実装がすごく苦しそうじゃん 自機、敵、弾の例でそれぞれ単体テストが普通にできなさそう 自機のソースだけ動かしたいのに敵も弾ももってこないと動かないんでしょ?
>426 最近はこういうのも『カオス』って言っちゃうんだ。
429 :
名前は開発中のものです。 :2009/02/10(火) 22:37:10 ID:KBLQ7wOO
実装の方法を述べるのが得意で なぜそれを実装しているかという理由を考慮していない 実装したらどういうメリットとデメリットがあるのか考えていない
431 :
名前は開発中のものです。 :2009/02/11(水) 00:32:00 ID:+7H05QpI
>業界現場で使われていると書籍で紹介していた初歩的タスクシステム NASAが開発した新技術で作られた商品です プロも愛用しているこの商品 今回はなんとこの値段でご提供します おおおー なんだよ、その詐欺臭い言い回しは
>431 今なら、このタスクシステム利用したフレームワークも付いて、お値段なんと9割引!
>>430 世の中夜勤帰りで朝から寝てる人だっているんだよ?
引っ越しの時ちゃんと挨拶行った?
顔合わせたら軽く会話するとかしてちゃんとコンタクト取り続けてる?
日頃からそういうコミニュケーションが取れてればいつ洗濯機を回していいのか
いつ静かにしなければならないのか
迷惑を掛けないように生活出来るはずなんだが
Golden Hammer アンチパターン タスクシステム
>>433 ちなみに、監視していると告げる行為は
ストーカー認定されますのでご注意ください
しかもリストがひとつずれてるし、おまえバカだろ
レスが切れたか タコスシステムもついに終わりか 長い戦いだったな
こんなちっぽけなネットの片隅で勝利宣言しても、不毛だと思うけどなあ…。 なんで反対派は口が悪い上に、 相手を言い負かすことにこんなに力を注いでるんだろう。 別に間違ったことは言ってないのに、 言いたいことが曇ってて反感買いやすいし。 ただ口喧嘩がしたいだけなのかなあ。 現実じゃストレス溜まってるのかね。
437 :
名前は開発中のものです。 :2009/02/12(木) 12:41:59 ID:iaB+mZ78
でもタスクシステムがなんの問題を解決するのか一度もでてないよね
438 :
名前は開発中のものです。 :2009/02/12(木) 12:44:58 ID:V7VMrK+q
>2にあるだろ
レガシーーィィィィィ DXライブラリ信者がこの板で多いのも頷ける
>>437 どんな問題を解決するのかという問いには問題が発生する場合との比較が
内在していて問題が発生する場合がなければ答えられない。
よってまず非タスクシステムではどう書かれていて
どんな問題があるのかを調査する必要がある。
441 :
名前は開発中のものです。 :2009/02/12(木) 15:45:22 ID:efZR4RxD
世界一の戦士が軍に所属していても、世界制服は出来ないのと同じ 優れた戦術はいくら積み重ねても、簡単に戦略を覆すことはできない 戦略なき集団(盗賊など)に対しては優れた戦術だけで潰すことは可能 所詮タスカーは盗賊程度を相手に戦う村の英雄止まりというわけだ 意味は違うけどローカルヒーローというアンチパターンもあったな タスカーはタスクシステムが戦術に属するのか戦略に属するのかを明確にしない 仮にタスクシステムが戦術であるとするなら上記の通り 戦略であるとするならば、実装例を重視すべきではない にもかかわらず、実装に固着するタスカーは行動が矛盾している それは理解不足が要因であると断定せざるを得ない すなわち、タスカーはバカで無能である 最後に挑発して和解の道を潰しておきましょうか この意味すらも理解できないだろうけど
> 世界制服は出来ないのと同じ 一行目から誤字。すごく馬鹿が書いているみたいなのでそこで読むのやめてNGリストに入れた。ばいばい。
443 :
名前は開発中のものです。 :2009/02/12(木) 16:08:08 ID:efZR4RxD
>でもタスクシステムがなんの問題を解決するのか一度もでてないよね 売名目的ぐらいしか思いつかない 自分の知名度を向上させるにはどうすればいいかという問題を解決できそうだ 自分ではよくわからなくてもまわりが凄い凄い言ってれば なんだか凄そうに見えるという人間の心理を応用した いわばカルト的人民掌握術と言える 実際に、ゲーム脳やマイナスイオンの偽科学もそれで普及した タスクシステムをわざわざ持ち上げるのは、その恩恵にあずかりたいから 自己顕示欲と無知、それが連鎖してタスクシステムは一大宗教勢力となった タスカーが全力でタスクシステムを守る理由も 自分の過去を正当化するため、又はその恩恵にあずかりたいから 典型的なカルトに洗脳された信者の行動と類似する
444 :
名前は開発中のものです。 :2009/02/12(木) 16:14:27 ID:efZR4RxD
>一行目から誤字。すごく馬鹿が書いているみたいなのでそこで読むのやめてNGリストに入れた。ばいばい。 黙ってNGに入れないということは 読んだという事実 でも反論する余地がない、又は反論する知識知能がない 揚げ足を取りたいという願望 他者にもNGを呼びかけたい 挑発したい これらの意図を読み取れる、あんたの心は見え透いている 透け透けなのよ 次は、もう飽きた寝ると言うんだ 何度も何度も繰り返しそう言うんだ そして俺がいなくなるのを見計らって、またタスクシステムを布教するんだ
>でも●●●●がなんの問題を解決するのか一度もでてないよね 売名目的ぐらいしか思いつかない 自分の知名度を向上させるにはどうすればいいかという問題を解決できそうだ 自分ではよくわからなくてもまわりが凄い凄い言ってれば なんだか凄そうに見えるという人間の心理を応用した いわばカルト的人民掌握術と言える 実際に、ゲーム脳やマイナスイオンの偽科学もそれで普及した ●●●●をわざわざ持ち上げるのは、その恩恵にあずかりたいから 自己顕示欲と無知、それが連鎖して●●●●は一大宗教勢力となった ●●●●が全力で●●●●を守る理由も 自分の過去を正当化するため、又はその恩恵にあずかりたいから 典型的なカルトに洗脳された信者の行動と類似する
アンチタスク派はどうしてこんな基地害ばっかりなんだろうな
>440 どんな問題を解決するかという問いかけを意味あるものにするには 問題意識の共有も必要だよ。コードのスマートさなんてあいまいで 捉え所の無い審美的主張がありうる話題のときは特にね。 そうでないと好き嫌いで終わる話を無駄に続けることに。 荒してる人はそれを承知で挑発してるのかもしれんが。
448 :
名前は開発中のものです。 :2009/02/12(木) 19:09:11 ID:efZR4RxD
>アンチタスク派はどうしてこんな基地害ばっかりなんだろうな わかっている 議論や正論に負けたカルトは、対象をキチガイ認定して、数の力で押す ならば問おう 外人が書いた本にタスクシステムの記述はあるのか? パターン本にタスクシステムの記述はあるのかと 権威を傘に威張る奴は奴は権威に弱いという 日本ローカルな権威であるタスクシステムも 世界的な視点では、所詮日本のローカルパターンに過ぎない タスカーは世界的な権威に負けたのだよっ
レスが基地外じみてるせいで無視されている事に何故気づかない
だってよ、「アンチタスク派=基地害」ってのはホントのことじゃん
>>447 あんたには悪いけどな、俺としてみりゃ
内容が伴ってさえいれば口調が悪かろうがドーデモイーわけ
内容が伴ってさえいれば口調なんざ枝葉末節の些細な問題なわけ
内容が伴ってさえいれば口調なんざそいつの目印、そいつのお好みの芸風、フレイバーでしかないわけ
内容の無い一行レス、罵詈雑言レッテル貼りの一行レスを張る奴なんざ気にするな。無視しとけ
そいつらは、気に食わない相手を論破したくても脳みそが付いてこない哀れな低脳だ
言うに事欠いた時点でそいつ自身は詰んでるのに、大人しく引き下がる勇気の無い、低脳ゾンビだ
論理的に死んでるのに、でも悔しくて仕方なくて、だから相手の態度にウダウダブツブツ文句たれて
一行レス(腐れウンコ)を投げつけるしか成す術のない惨めな低脳腐れウンコゾンビだ
ひらしょーさんひらしょーさん言ってるアンチタスク気取り
やねうらおさん松浦さんさん万里ゆうじさん言ってるタスカー気取り
こいつらは等しく無価値な、内容の無い一行レスで吠えるだけの犬っコロだ
文句言っても消えやしない。いくらでも湧いてくる。今日も湧いてるな
>>442 >>445 >>446 >>449 >>450 ほれ。お前らの感想を聞かせろよ?脳みそついてんだろ?
>>2 はobserver patternだと思う?思わないよな?思うなら
>>359 に答えてみ?
>>2 はゲームプログラムの初歩的原型だと思う?思わないよな?思うなら
>>387 >>388 に答えて
452 :
名前は開発中のものです。 :2009/02/12(木) 20:33:34 ID:iaB+mZ78
いま、タコスシステムが団地妻の叫び声をあげながら死んでいきましたとさ
ageポエマーはコテつけなはれ
454 :
名前は開発中のものです。 :2009/02/12(木) 21:30:45 ID:efZR4RxD
あーあ、偉大なる天才プログラマやねうらおさんからも タスカーの方々からも嫌われちゃいました>< 俺の言ってることはどんなに有益でもきっと受け入れられないだろうな というわけで、タスクシステムに疑問を持ってる人や タスクシステムを嫌っていて模索している人に DSLを紹介、知ってる人も多いと思うけど 内部DSL, 外部DSLあたりで検索すれば出てくる これはいいぜ、タスクシステムと違って wikiに書かれてるし(タスクシステムは残念ながらw) 外国の人も議論しまくってるし、観念的にもそれほど難しくない 使わなくても知っているだけでかなり有益な情報 お勧め 俺がお勧めした時点で、俺を嫌ってる人は DSLへのハードルが高くなっちゃったね、ごめんね 俺、性格悪くてごめんね、ポエマーでごめんね
なんかタスクっていう技術概念を、完成されたなんにでも使える万能薬みたいに思ってる馬鹿なおじさんがいるね^^ ここではみんなかまってくれておじさんも楽しそうだね^^
>でもDSLがなんの問題を解決するのか一度もでてないよね 売名目的ぐらいしか思いつかない 自分の知名度を向上させるにはどうすればいいかという問題を解決できそうだ 自分ではよくわからなくてもまわりが凄い凄い言ってれば なんだか凄そうに見えるという人間の心理を応用した いわばカルト的人民掌握術と言える 実際に、ゲーム脳やマイナスイオンの偽科学もそれで普及した DSLをわざわざ持ち上げるのは、その恩恵にあずかりたいから 自己顕示欲と無知、それが連鎖してDSLは一大宗教勢力となった DSLスカーが全力でDSLを守る理由も 自分の過去を正当化するため、又はその恩恵にあずかりたいから 典型的なカルトに洗脳された信者の行動と類似する
内容ありゃ口悪けりゃいいなんて嘯く輩はいっぱい見てきたけど、 やっぱり面白がられてるだけだなあ。突付けばすぐ反応してくれるし。 そういうのは何らかの権威がある身元のはっきりした人が言うから意味があるんであって、 ネットの片隅の名無しが言っても説得力なんて皆無なんだよね。 こういう事いうと「分かってくれるやつだけ分かればいい」なんて強がるけど、 そんなん身内でお互いを褒め合って慰めあってる ネット上の一山いくらの連中と大差ないわけで。 ブログかmixiでやれって感じだ。
でもタスクシステムがなんの問題を解決するのか一度もでてないよね
459 :
名前は開発中のものです。 :2009/02/12(木) 22:19:35 ID:efZR4RxD
お勧めのドメイン固有言語をバカにされちゃいましたっ>< くやしいっ……でも感じちゃう、ビクビクッ DSL凄いんだぞー、マイクロソフトなんかの大企業が 研究したり論文書いてたりツール作ったりしちゃうんだぞー タスクシステムなんてWIKIにすら載ってないじゃんかよー ばーかばーかちんじゃえ
【DSL】 # デジタル加入者線の略。 # プロレスラー、リングパフォーマードラゴンソルジャーLAWの通称。 # ニンテンドーDS Liteの略称。 # Damn Small Linuxの略称。
461 :
名前は開発中のものです。 :2009/02/12(木) 22:38:49 ID:efZR4RxD
このスレにひどいいじめっこがいますっ>< DSLって言ったらdomain specific languageドメイン固有言語のことに決まってるじゃないかよー 試行錯誤が必要な問題領域を、可読性を高く記述するために必要なんだよー タスクシステムなんて一番重要な部分の柔軟性を奪って複雑にしてるだけじゃないかよー
>437 タスクシステム(>2の中身とは違うナムコ式の)で製作されたゲームが何本もあるという事実を どうかんがえているんだろう? 過去にタスクシステム(という名の何か)でモノが作られたという事実と、今それらしい影が見当たらない という事実は別物なんだがな。
>>462 当時はメモリ空間64KBで、
・自動変数、なにそれ?
・アセンブリ言語以外ありえない
・アドレス決め打ち上等
・複数のインスタンスで同一のメモリアドレスを共有
(インスタンスの寿命が重複しないように、人間が考えて割り振り)
・自己書き換えカコイイ!
という世界だよ。
その状況においては、メモリ断片化を避けた動的メモリ確保、複数フレームに
またがるコンテクスト保持(コルーチン)を実現したナムコのタスクシステムは、
煩雑な手作業によるメモリ割り振りを回避し、処理の柔軟性も向上させる
優れた解決策だった。
今はメモリ豊富なんだし、コンパイラがいろいろ面倒見てくれるんだから、そっち
使うだろ。どうしてもアセンブリ言語で組みたいってのなら止めないが、コンパイラが
提供する型チェックの機能や最適化など全部窓から投げ捨てる羽目になるぞ。
>>462 >>2 の中身とは違うナムコ式のタスクシステム?
そんな馬鹿な!
>>2 は日本ビデオゲーム業界黎明期に開発されたスーパーテクです!
ギャラクシアンが起源です!
やねちゃんなんてパックマンやゼビウスをリバースエンジニアリングして
本を書いたんだぞすごいだろーって日記で豪語してるんだからね!
上のほうでやねちゃんは偉大なプログラマ達と仲良しの凄い人ですよーって
紹介してくれた優しい人がいたでしょ?
やねちゃんは
>>2 のCodezineの記事をタスクシステムの教科書と呼んでるよ!
どうだ参ったか!
466 :
名前は開発中のものです。 :2009/02/12(木) 23:26:24 ID:efZR4RxD
ジョブコンの目的はコードの可読性を高めるってことみたいだな DSLの目的も似てる ほとんどの人はこれを模索していたはずだった 一方タスクシステムは可読性を無視して、目的を失い迷走した ジョブコンは広義のタスクシステムだよっ って誰かが言うんだろうな、恥の上塗り 昔の人もいい言葉を残している 君子豹変、小人革面
分かってくれるやつだけ分かればいい タスクシステムは素晴らしい。夢と希望に溢れているよ それに比べてひらしょーはどうだ 新清士によればひらしょーには夢も希望もないんだそうだ。全くその通りだね タスクシステムをなにそれ?なんて言う人が夢や希望を語れるはずがない!
>>464 タスクシステムとジョブコンを混同するなんてあんまりだね
誰がどう見ても タスクシステム>>>(越えられない壁)>>>ジョブコン ですよ!
ジョブコン?なにあれ?スタックを弄繰り回す変態、超ド変態プログラムじゃん!
可読性のためとかいってアクロバティックなことやってホルホルしてただけじゃん!
>>451 >
>>2 はobserver patternだと思う?思わないよな?思うなら
>>359 に答えてみ?
三下のタスカー共がダンマリを決め込んでるから俺が答えてやる!
何度だって言ってやる!
>>2 がオブザーバー・パターン?大変な思い違いだ!
順序が違う!オブザーバー・パターンというのはタスクシステムのおいしい部分を
全て取り払った劣化タスクシステムパターンなのだ。GoFは全くバカな奴らだ
ConstrainedTaskSystemだと前スレで言っただろう。あれは間違いだ
Observer Pattern とは Brain Damaged Task System Pattern なんだよ
分かったか!参ったか!
いいか、馬鹿どもよくきけ お前等、オブジェクト指向だの、デザインパターンだのいってるが 結局、お前等の使ってるタスクシステムは 自機のソースに敵の処理も弾の処理も書くから 自機のソースだけもってきて単体テストもすることができない=カプセル化全くされてない ゴミシステムだ わかったらさっさと 「参りました、いま、すごく恥ずかしくて死にたい気分です」 って3回、大声で復唱して糞して寝ろ
>>451 >
>>2 はゲームプログラムの初歩的原型だと思う?思わないよな?思うなら
>>387 >>388 に答えて
これも三下のタスカー共がダンマリを決め込んでるから俺が答えてやる!
ドアホめ!犬畜生め!
タスクシステムがゲームプログラムの初歩的原型?それはちょっと語弊があるね!
>>2 は上位タスクシステマーになれる優性遺伝子を保有する限られた選ばれた初心者が
読むことが許される究極の栄養満点の初歩的原型だ!
そんじょそこらのどこの馬の骨かも分からない劣等の子の初心者が使うことは許されない
下郎共め!ひれ伏せ!したーにー!したーにー!分かったか!
まあ、名前さえタスクシステムじゃなかったらどうでもいいわ。 暴走族と同じでな、馬鹿に「こりゃカッコいい!」と勘違いさせる要素があるのがマズイ。 珍走に倣って「ウンコシステム」と呼ぼうぜ。 そしてこの呼び名を布教させよう。 タスクシステムのせいで「タスク」という単語がずいぶん汚染されたよな。 腹立たしいことだ。
>>470 Cだけで書いてるけど、自機の中に敵の処理はない。
自機の弾の発射だけはしてる。
474 :
名前は開発中のものです。 :2009/02/13(金) 00:22:58 ID:Dzt9fUT0
で、結局どう書くのよ。 タスクもアンチタスクも作品出さないよね。 もしかしてこのスレには私みたいなワナビーしかいないの?
>>474 典型的には、メインループはこんなもんだろ。
for (;;) {
ProcessInput();
ProcessFileIO();
player.Update(*this);
for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::Update, ::_1, boost::ref(*this));
if (player.Finished())
break;
HitCheck();
backGround.Draw();
player.Draw();
for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::Draw, ::_1));
WaitVSync();
}
DQ9はタスクシステムを使っていないから発売延期になったんだよ! DQ9でタスクシステムを使っていたら、去年の年末には発売されてたに違いない!!! とかいう人とか、 DQ9はタスクシステムを使ってるから発売延期になったんだよ! DQ9でタスクシステムを使っていなかったら、去年の年末には発売されてたに違いない!!! とかいう人ばっかりだな、このスレは。
>>475 前の方で話題になってたオブジェクト間の相互作用はどうなってるの?
そこのthisに他のオブジェクトを返す関数を持たせてるの?
>で、結局どう書くのよ。 >タスクもアンチタスクも作品出さないよね。 DSL的に書けばいい、調べればコード例も載ってる 解決したい問題領域を必要最小限にシンプルに書けばそれがDSLのコードになる それ以外のノイズを含めたものは別のメソッドに追い出す 処理と描画を一まとめに書くかどうかはフレームワーク次第
>>477 例えば、星と星の間に働く万有引力の話なら、メインループのどこかに、
for(int i=0; i<size; ++i)
for(int j=0; j<size; ++j)
{
if(i==j){ continue; }
/* ここで万有引力の処理をする */
}
なんかを挟めばいいんじゃない?
>>477 そう。もうちょっとまともに書くなら
struct EnemyInterface {
// プレイヤーの位置を取得
virtual bool GetPlayerPos(Position* pos) const = 0;
};
class Scene : public PlayerInterface, public EnemyInterface {
public:
virtual ~Scene() {}
void MainLoop() { /* この中でさっきの for(;;) {} 相当の処理 */ }
// プレイヤーの位置を取得
virtual void GetPlayerPos(Position* pos) const;
private:
Player player_;
std::list<Enemy> enemies_;
};
とでもして、プレイヤーを追跡する敵を作りたければ次のように書く。
void Enemy::Update(EnemyInterface& scene) {
Position pos;
scene.GetPlayerPos(&pos);
// 自分の位置を pos に近づくように更新
}
これだと Enemy::Update, Player::Update から呼ばれる処理を EnemyInterface,
PlayerInterface で細かく指定できるから、予期しないタイミングで変数の値が
変更されて orz となる事が減る。特に、仕事分業するときに役立つ。
変わったsceneだな。通常のsceneは "scene is-a player" "scene is-a enemy"じゃなくて "scene has-a player" "scene has-a enemy"だから 集約を使うんだが シーングラフってそういうもんでしょ
あー EnemyInterfaceというのはSceneInterfaceForEnemy PlayerInterfaceというのはSceneInterfaceForPlayer なのか。スマン
483 :
名前は開発中のものです。 :2009/02/13(金) 07:33:41 ID:zbAaxVah
>>473 それは駄目だ
自機は自機のソースだけで動くようにしろ
関連はシーンに書くようにしろ
無理やりでもそう組め
>478 > 解決したい問題領域を必要最小限にシンプルに書けば 言ってることは、タスクシステムとあまり変わらんなw
>478 DSLをうたいつつ実体がタスクシステムなものがないとは限りませんし 見当違いのものを見て誤解してしまうとお互いに不幸ですから 具体的にそのコード例を希望します。 URLや論文名でそれが掲載されている資料を指し示してくださっても結構です。
486 :
名前は開発中のものです。 :2009/02/13(金) 12:43:14 ID:zbAaxVah
ドラゴンソルジャーLawがどうかしたって?
DSLをフレームワークっていう言葉に置き換えてもあまり意味が変わらないような気がする
488 :
名前は開発中のものです。 :2009/02/13(金) 17:57:13 ID:zbAaxVah
また、新ワード連発して言葉の定義で煙に巻く気だな そーはいかねぇんだよ やねうらお二世 DSLは明確なソース記述例がでるまで ドラゴンソルジャーLaw以外の解釈を認めない
で、コンテキスト保存と復帰で継続性を持たせる実装は、結局関係ないことにするの?
490 :
名前は開発中のものです。 :2009/02/13(金) 21:22:01 ID:JLcOgyKP
やねちゃんもDSLについてほんの少しだけ 他人の記事パクって書いてるから読んでみろよ 何かが違う、本質を理解しているのかといわれれば 理解しているように見えて全く理解していないようにも見えるけど 実際のところやねちゃん本人は理解しているんだえへんと 言うだろうけど、やっぱり俺の主観では理解しているようにはみえないけど 本人がそういうんだからそういうことにして置いてあげるのが 人情ってモノじゃないかなと思う今日この頃であった 何がいいたいかというと、うんこしながら考える
>>489 アセンブリ言語ならともかく、C++なら小細工せずにメンバ変数で良いんじゃない?
コルーチンが欲しいところは、スタックレスVMとスクリプト言語。
スクリプトはとりあえずナシでいかないか? contiuationが無い場合は、protothreadなり何なりでFSMにするしかないか。メンドクサイな。
ふー、やっと追いついたのね。それにしてもこのスレの伸びはすごいのねー
バカアホ連呼の楽しい泥仕合が繰り広げられていて新作ポエムを投下する
タイミングがなかなか見つからなくて悔しいのね
1/17のID:1fr/EvSg以降ご無沙汰なので話の流れがよくわからないんだが
『GPU(DSP)カード』っていうフレーズを見た瞬間ちょっと寒気したのね
何かの意図があってコピペしてるのか?まぁいいけど
>>490 ポエマーの称号はあなたにお譲りします。というかファンです
DSLとか高属性市民が使いこなしてそうなナウいカッコいい言葉を聞くと 反射的に劣等感を覚えるおじさんはこの話題にコメントするのビクビクなんだが アセンブリ言語やC言語コードに変換してくれるプリプロセッサを用意して ゲームコードを楽に記述してもらえるようにする一工夫も外部DSL(?)なのかな? デバッグ情報も吐いて、デバッガーの画面にゲームコードも出しちゃうやつ
酔っ払ってて駄目だわ ×アセンブリ言語やC言語コードに変換してくれるプリプロセッサを用意して ×ゲームコードを楽に記述してもらえるようにする一工夫も外部DSL(?)なのかな? ゲームコードをアセンブリ言語やC言語コードに変換してくれるプリプロセッサを用意して ジョブを楽に記述できるようにする一工夫ってあるじゃない? あーいうのも外部DSL(?)なのかな 寝る
DSLの明確なソースが出る前に長いレスつけてる奴もやねうらお2世と同じ DSLはドラゴンソルジャーLaw以外の解釈を認めない
497 :
名前は開発中のものです。 :2009/02/14(土) 00:41:01 ID:vvv9+ke/
俺をやねちゃんと同類にしないで欲しいね 人によってDSLのレベルは異なるんじゃないの 古い3D迷路探索に特化し、適当なアルゴリズムを外部で書くなら if (ここはゴール) 終われ; else if (前は壁) 右向け; else 進め; という感じが俺DSL ただ、こういう風に書くには不向きなOSや言語だったのが不幸の始まり 試行錯誤していった結果、妙な方向に特化した副産物が タスクシステムということだろう コルーチンのおかげでようやく道が開けた
>>497 駄目だ
そんなあいまいな回答許さん
DSLとはこうだ!
と言い切れ
言い切れないならはじめからDSLなんて言葉自体出すな
話が進んでから「実はそれ違いますーw」とか言い出すに決まってるだろ
いままで何度くだらない繰り返しをしてきたと思っているんだ
>ゲームコードをアセンブリ言語やC言語コードに変換してくれるプリプロセッサを用意して >ジョブを楽に記述できるようにする一工夫ってあるじゃない? >あーいうのも外部DSL(?)なのかな そういうことじゃないの、超高級言語だから 論理的な部分から余計なものノイズを全部取り除いたものを 何らかの形で表現できればそれが一番欲しかったもの 常に理想的なDSLがあればいいけど 実際は、コストを考慮してある程度の妥協は必要になるから マクロや、より自分の理想に近いものを見極める必要はあるけど コルーチンがあればC++でもそれなりにいいものは出来ると思う テンプレートやプリプロセッサやSEDなんかで軽く変換するだけでも十分 しなくても可読性を出来る限り高くすれば十分読みやすいのは書ける スクリプトにしなくてもRPGツクールみたいなツール作ってもいいし ドローソフトで描いた絵をSVGをそのままGUIに使えるようなツールを作る手もあるだろうし 色々と考える余地があるから柔軟でよいのではないかと思う
>駄目だ >そんなあいまいな回答許さん >DSLとはこうだ! >と言い切れ いいんだよ実装は柔軟で、様々なパターンを適用できるから 問題領域を可能な限り簡単にするという目的さえ見えていればそれでいい タスクシステムは目的が見えてないからおかしいのだよ そのくせ、実装に介入してくるから柔軟さが大きく欠けていた それで複雑になって実装時間が長くなるという最悪のデメリットが発生した
>>499-500 ほら、また定義に関する議論になるだろ?
この糞野郎
だから辞めろって言ってるだろ
お前は技術者でもなんでもないただの糞だ
誰もてめーのいうことなんて聞いてねーよ
育ちが悪いな
なんでそうやって曲解して答えるくせが体に染み付いてるの?
根っからの詐欺師だな 誠意もなんにもなくて頭に糞しか詰まってないなら さっさとプログラマなんて辞めて 儲かる業界いけよ このチンカス野郎
残念だけど、私の書いたことの九割はどこかの本なんかに書いてあったことを そのまま文を崩して書いているだけなのだよ 挑発気味に書いているのは、安易な挑発に乗るおばかさん達をひきつける目的と わざと挑発に乗る性格の悪い人達をひきつける目的があるからだよ そしてこう書くことで、俺の手のひらに乗ることに嫌悪を感じて 書き込まなくなる人も少しはいるのだろうなと推測してみたり >なんでそうやって曲解して答えるくせが体に染み付いてるの? 俺が天才だから超天才だから ちなみに挑発の後に質問しても、感情的に書きなぐるつもりはないよ 俺は、君の発言の目的しか見てないから、怒る理由がない わざと挑発に乗るのも面白いけど 最後に ……とミサカは挑発します って感じに文にかかる目的を書いてくれると君の思考が公開されて面白い と、ミサカは要求します バカという言葉も、不快だったり不快でなかったりするだろ それは、発言者のその言葉に目的があるからだよ そのバカという言葉の目的を見ることが出来れば もっと幅広いコードも書けるようになるかもしれないね 俺ってやさしいだろー
DSLがどれほどのものか気になったのでちょっと調べてみたけどなんだか食指動かないなぁ 組み込みスクリプトでいいや俺。Squirrel可愛いよ。Squirrel
>>480 シーンが複数あるときはそれぞれが>475のようなものを持ちますか?
言い替えると共通部分はどうしますか?
想像できたのは親シーンを継承してテンプレートメソッドパターンか
別の管理するものを作ってそれに投げるかですがそれ以外がありますか?
それとも現実にはそんなに共通部分は無いですか?
現実での鬱憤をネットに篭って発散させてると、 こんな気持ち悪い人間が育つのだなあ。
まあ、ゲー製なんて低脳の集まりだからな まともなプログラマなら、もっと高収入が望める仕事やるだろ
速度だけならypsilon schemeが組み込みスクリプトで最速らしいぜ
>>510 ・×reflesh ○refresh
・std::vectorだとinsert/deleteがO(N)になるけどオブジェクトが増えてくるとまずくない?
・挙動は、defineマクロじゃなくboost::functionで定義できるようにしようよ
・ifで定数との比較のときに定数を左に書くのはCのころの慣習で、いまや==と=を間違えても
コンパイル時に警告が出るのだから、これはやめたほうがいい。
・2オブジェクト間の挙動を実装するのにループが2重になってるけど、これを改善しないと
オブジェクトが増えてきたときに困りそう。
・structにtypedefは不要。どうせCとしてコンパイルすることはないんだから、こんな書き方やめたほうがいい。
・Operandでvoidの関数の末尾で書いているreturnは何か意味があるの?
・staticでOperandListを持っているのがダサイね。static禁止!
まあ、意図は伝わったし、その意図は大変いいと思う。
今後のさらなる改良を期待します。
>std::vectorだとinsert/deleteがO(N)になるけどオブジェクトが増えてくるとまずくない? 空きインデックス保持&削除時NULL代入式なのでO(1)のはず・・・ >2オブジェクト間の挙動を実装するのにループが2重になってるけど、これを改善しないと >オブジェクトが増えてきたときに困りそう。 でもまぁそういう処理を行うというアプリ側の仕様だからなぁ。 オブジェクトは型ごとにリストアップしているけど、 型の種類が増えると、型自体の検索のオーバーヘッドがどうなるかというのはちょっと心配だ。 なんせdynamic_castはむちゃくちゃ重いからなぁ。 すべての型へのキャスト可不可テーブル作って高速化って手はありそう。 >structにtypedefは不要。 マジでしらんかった。勉強になりました。C++すげー >staticでOperandListを持っているのがダサイね。static禁止! うーん、これに関しては、static使わないとなると、引数を持ちまわらないといけなくなるから勘弁ねがいたい。 OperandListの切り替え(バンク切り替えみたいに)が出来る仕組みを用意して、お茶を濁そう。 ゲームの場合は事足りるでしょう。 もしくはデータに親子関係をつけたりして、型以外でも検索できるようにするか。理想はSQL。
>>512 >>std::vectorだとinsert/deleteがO(N)になるけどオブジェクトが増えてくるとまずくない?
>空きインデックス保持&削除時NULL代入式なのでO(1)のはず・・・
そこまで見てなかった。ごめん。
一時的にオブジェクトを1万ぐらい作って、その99%がdeleteされた場合、
すかすかのstd::vectorが残るのでgarbageは何らかの条件でやったほうがいい気はするけど
まあ、それはそれやね。
> 型の種類が増えると、型自体の検索のオーバーヘッドがどうなるかというのはちょっと心配だ。
> なんせdynamic_castはむちゃくちゃ重いからなぁ。
型ごとに分類するため一回traverseしていいなら、dynamic_castなんか使わずに
typeidでそのアドレスで分類したほうが速いでしょう。
>>structにtypedefは不要。
>マジでしらんかった。勉強になりました。C++すげー
うん
struct XXX
{
};←最後型名とか書かない。
どうも、あなたのソースは書き方がC++としては素人っぽいので、
C++をもう少し勉強しよう。
>>512 >>staticでOperandListを持っているのがダサイね。static禁止!
>うーん、これに関しては、static使わないとなると、引数を持ちまわらないといけなくなるから勘弁ねがいたい。
なんで?
TaskSystemがOperandListを持っているなら、素直に
taskSystem.AddOperand(boost::function…)
↑これ指定するだけのことだけど、これがそんなに嫌?
>>514 「taskSystem」はグローバル変数?
とにかく、OperandListがプロセス中で唯一になれば、あとはどうでも。
516 :
名前は開発中のものです。 :2009/02/14(土) 12:02:55 ID:AT9MJLSn
で?ソースは何を主張せんが為のものなの? また、目的も計画性も無しにとりあえず組んでみた? 会社だったらその作業に誰にどんな理由で金払わせるの? 説明してよ
会社でタスクシステムなんて使わないんだから関係ないでしょ。
>>516 まーたプロ気取りお説教君がブリブリしてるのか
その学生さんが投下したネタの趣旨くらい適当にESPで汲み取ったれや。な
爪先立ちのワナビー君とかモバゲ底辺のクズにはそんな心の余裕はないかい?ん?
>>516 他のクソ・パターン?・サンプルにも突っ込んでやれよ。
520 :
名前は開発中のものです。 :2009/02/14(土) 12:29:11 ID:AT9MJLSn
違うな 問題はその意味不明な行動理由だよ 毎回毎回目的もなく脊髄反射的に動いて後から自分の行動に理由付けするから わけわからない方へいくんじゃないの?
それでいいんだよ。 自他に害及ぼさない限りにおいて。
>>520 おめえ、前スレで頭鈍いせいで話に付いてけなくて説明責任!説明責任!とか
吠えてたバカタスカーだろ
>>515 > 「taskSystem」はグローバル変数?
> とにかく、OperandListがプロセス中で唯一になれば、あとはどうでも。
なぜそれがグローバル変数だと思うのだ・・。それはある意味やばいぞ。
グローバル変数もstatic変数もまともなC++のクラス設計では使わないし、使う必要もないのだが。
class GameMain
{
TaskSystem taskSystem;
void Start()
{ ... }
};
int main(...)
{
GameMain().Start();
return 0;
}
こうなってると思ってくれ。
>>523 最後のGameMain().Start()はGameMainのテンポラリオブジェクトを作ってそのメソッドを呼び出しているのか。
お前、C++の相当のマニアだな?
526 :
名前は開発中のものです。 :2009/02/14(土) 13:56:13 ID:vCXBLjPV
なんかタスクシステムって言葉にトラウマのあるのが湧いてるスレだな。 昔C言語の話題で「ポインタなんて難しい言葉つかってえらそーに! そんなの使わないでもプログラム組めるんだよ!」と涙ながらに吼えてるのを 見たことがあるが… 彼は今もポインタという言葉にトラウマを抱えて生きているのだろうか。
>>526 そのお話とタスクシステム話はどう結び付くんだい?
ポインターは意味が明らかなわけだが、タスクシステムはどうよ?
みんな俺俺プログラムだよな。定義不明瞭。みんなバラバラ
なーんてというと『いや共通項は
>>2 だから。実装付きできちんと定義されてるし。ナムコだし』と擁護&釈明してくる
じゃあと
>>2 に共通する謎仕様、謎実装を追求すると今度は
『オイラのタスクシステムは違う』
『現代的タスクシステムはもっとすごい(はず)』
とか逃げる
じゃあやっぱローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー
というと、『言葉狩りがしたいだけか。名前が気に入らないだけだろ』と知能障害をきたす
パープリンすぎてトラウマになるな
>>523 それだと他所の関数や他所のクラスがtaskSystemへのポインタを知るための仕組みが居るから困る。
taskSystem(の中のOperandList)は、ぶっちゃけデータベースだからプロセス毎に一つあればそれでよい考え。
やりたいことは、
ゲーム中で使うデータ(オブジェクトなど)は全部データベースに登録する。
データを処理するときは、データベースにリクエストする。(このとき排他処理も自動的にかける)
リクエストに引っかかったデータはすべて並列的に処理される。(データが多い場合は各コアで並列に)
ねらいどころは、
排他処理の自動化。データ構造に基づいてロックをかけるのでデッドロックしない。
処理の自動並列化。
すべてのデータがデータベースに登録されているので、データ構造が明確。
処理の流れが基本一本道なので、どこで誰がなにをしているかすぐ分かる。
>>527 > みんな俺俺プログラムだよな。定義不明瞭。みんなバラバラ
> じゃあやっぱローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー
何か権威から定義付けされてない言葉は公衆の場で使うな、ということかい?
たとえばデザインパターンが生まれる前からあれらのアルゴリズムはみんな俺俺実装で使われてたし
その時代に彼らは自己流な命名で呼び合ってた。むしろGoFみたいに定義されてる方がマレ。
ふつーにゲーム作ったことあるプログラマなら「タスクシステム」と言われれば
どんなことをしたいシステムなのかだいたい想像つくし。よほどの新人でもない限りその程度で事足りる。
現場ごとにのローカル定義用語なんて開発現場じゃいくらでもあるよ。
それらを厳密に定義した言葉じゃないと認めん、なんて言ってたら社会生活おくれんだろ。
まぁ、ここは開発現場じゃなくてゲーム作りたくて挫折した人とかもいて
何かコンプレックスを刺激されるのかもしらんが、そんなトラウマになるほど思いつめなさんな。
>排他処理の自動化。データ構造に基づいてロックをかけるのでデッドロックしない。 これは無理か。 ・データベースへのリクエスト時はデータベース全体をジャイアントロック。 ・しかし、リクエストそのものは並列実行される。 こうだな。
>>528 > ぶっちゃけデータベースだからプロセス毎に一つあればそれでよい考え。
データベースにしてもサイトごとに仮想化して何個も用意するじゃん。
ゲームにしても、全然別の2つのゲーム(例えばミニゲームを2つだとか)を動かしうるなら、
そんな何の関係もないオブジェクトを同じOperandListに登録するのは嫌だし、無駄だ。
> それだと他所の関数や他所のクラスがtaskSystemへのポインタを知るための仕組みが居るから困る。
それは実装技術が足りてないだけだろ。
一体、どういうコードを想定してんだ?
ちょっとソースを例示してくれ。俺が書き直してやる。
>>529 >何か権威から定義付けされてない言葉は公衆の場で使うな、ということかい?
人と会話するときはきちんと相手の話を聞こうや
それが文章なら、質問する前によく読み返そう
大人の常識でしょ?というか学校で教わったでしょ?
自分で引用した文くらいちゃんと読もう。な。
はい、では大きな声で復唱しましょー
『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー 』
『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー 』
『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー 』
『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー 』
脳みそに染み渡った?質問どうぞ
うー…なんと気持ち悪いスレだ…
>>532 まぁ落ち着けや。
別にポインタ分からなくてもプログラムは作れるし
タスクシステム分からなくてもゲームは作れるさ。
君に理解できないことを他人が理解できたからって君が劣っているわけじゃないよ。
人間には個性があるんだから。君にしか出来ないことがあるかもしれない。
涙を拭いて外に出よう。
535 :
名前は開発中のものです。 :2009/02/14(土) 15:23:33 ID:vvv9+ke/
タスカーごときがデザインパターンを語るなよ デザインパターンは良く出る形でメリットがあるものを厳選している タスクシステムは良く出る形だがメリットがないものを実装だけ俺俺定義している デザインパターンの本で実装があまり重視されていないのは メリットデメリットや問題解決などの方が重要だから 一方タスクシステムは実装ばかり重視されてそれ以外がない よって同一のものではない、形だけが近い別物となる ちなみにアンチパターンには該当してるみたいだけどね、タスクシステム 次はC++イデオム話ですか、やれやれ イディオム話をするってことはどうやらフレームワークの話ではないらしい
>>534 あれあれ?そうあってほしいの?そう思い込みたいの?
自称大人なのに言うに事欠いて妄想世界にイっちゃうの?
脳内世界で願望を実現して心穏やかになったところ悪いんだけど、何度も聞くよ?
>>529 読んでね。脳みそに染み渡った?
で、↓の疑問は氷解した?
>何か権威から定義付けされてない言葉は公衆の場で使うな、ということかい?
もちろん氷解したよね?
なんですぐこういう流れになるんだか。
次はアンチが
>>510 を書き直すターン。
>>510 よりも良くなればアンチの勝ち。
良くならなかったらタスカーの勝ちだな。
外とは裏腹に陰湿低能気圧が発達しているな
結局言葉遊びか。外に出ろ
>>534 わろた
>次はアンチが
>>510 を書き直すターン。
>
>>510 よりも良くなればアンチの勝ち。
>良くならなかったらタスカーの勝ちだな。
負けました、コード見たけど何がなんだかよくわからなかった
俺の知能じゃあ理解できないや
それにしてもタスクシステムはとっても便利な気がします
まさに神に選ばれた超天才のみが使いこなせるという
伝説の剣、そういわゆるゴッド神装備であることを痛感いたしました
俺は凡人だから使わないだろうけど
天才の方々は頑張ってください
凡人の俺はシェーダーでもいじってます
541 :
名前は開発中のものです。 :2009/02/14(土) 17:13:51 ID:AT9MJLSn
で?結局、なんのためのソースだったの? また、目的もなくとりあえず組んじゃった? そういう行動改めた方がいいよ 自分では頑張ってるつもりなのにいつも結果に結び付かない状態になるよ ソース読んであれこれ評価してる奴もおかしい 目的もなにもわかってないのになんであーだこーだ言えるの? テキトーに気分で評価してテキトーなコメント入れてない? ちゃんと目的を満たしているかどうかが評価ポイントじゃない?
>>540 あの程度のコードすら読めないとはよっぽど馬鹿なんだろうな
タスク派とかアンチタスク派とか以前にプログラマとして失格
お前みたいなクルクルパーに絡まれるやねが気の毒だ
>>541 お前みたいなクルクルパーもこのスレにはいらないからどっか行ってくれ。
>あの程度のコードすら読めないとはよっぽど馬鹿なんだろうな >タスク派とかアンチタスク派とか以前にプログラマとして失格 >お前みたいなクルクルパーに絡まれるやねが気の毒だ おっしゃるとおりです くやしいっ、でも感じちゃう、ビクビクッ
まじめに評価すると 問題領域がちょっと微妙な気もした 描画とロジックを混在させるのはまぁ、みなかったことにして ロジックが細切れで、流れは見づらくないだろうかと思った 計算する部分を重視して、それがどう組み合わされているのかの部分が ブラックボックス化するのには何か意味があるのでしょうか 俺にはその辺の意味が理解できなかった まぁ、アンチタスカーで敗北者の俺の意見なんて無視していいよ タスカーは神いわゆるゴッドなのだから気にするな
お前らいつまでやねうらおに絡んでるんだw
>>545 > 描画とロジックを混在させるのはまぁ、みなかったことにして
本当に馬鹿なんだなぁ。あれがあのフレームワークの真骨頂なのに。
あのフレームワークは、オブジェクトのinteractionを定義できるようになっているから、
描画すらも、Windowとobject(画面に表示すべき物体)とのinteractionとして定義できるってことだ。
なんで一番大切なところを見なかったことにするかな…
あんたはクルクルパーなんだから、アンチタスカーなんかを名乗ってくれるなよ。
アンチタスカーがみんなクルクルパーだと思われるじゃん。
何度でもいうよ で?結局、なんのためのソースだったの? 意味不明な行動してんじゃねーよ いきなりソースもってきて「どうよ?」とか馬鹿か、頭おかしいのか?
>>510 おもしろい
void Loop() の相互作用が一覧で見れるってとこがかなりいいね
俺的難点を挙げるなら、「Tasksystem.h」何やってんだかワカンネェ orz
というあたりか。
・staticで定義された唯一のリストにデータを一緒くたに持ってる(型を気にせず)
・TASK1()とかTASK2()とかの引数に指定された型を元にリストから対象データを検索して処理を適用してる
この2点の意図を読み取るのがやっとだった。
演算子の意味づけ変更しちゃうともうC++じゃないね。俺的ゲーム用汎用スクリプト言語って感じ。読めない(俺が)。
他にはデータの保持方法がリストに全突っ込みってのがいいのか悪いのか判断がつかない。あまり問題は無い気もするが。
全体通してみると相互作用が見やすいという利点があって、逆に明確な悪いとこは今すぐ思いつかない。
データアクセス時に検索処理が間に入る分だけ、普通に変数定義しまくって変数名で直接アクセスするよりも重そうだなという程度。
ゲーム部分の可読性は高いし、性能が問題になったらデータ定義方法変えればいい話だし、かなりいけてる気がする。
今までのタスクシステムよりは断然こっち使う方が良い。先につながる。
ちなみに俺はアンチタスクシステム派です。
>>548 頭がおかしいのはお前。あのレベルのソースすら読めないならプログラマの資格なし。
低脳がほざくんじゃねえ!
>>510 ごった煮リストにすることの利点が、相互作用を
"ちゃちゃっ"と記述ことにあるんだよ
と解釈したのだけれど、自分は結構面白く感じたし、、
十分利点になると思う
速度はどうなの?とか実装的問題は賢い人がなんとか解決するとして。
すると、中身でごった煮になっていない方法もありえるのかも
因みに自分もアンチ
553 :
名前は開発中のものです。 :2009/02/14(土) 19:00:13 ID:vvv9+ke/
>本当に馬鹿なんだなぁ。あれがあのフレームワークの真骨頂なのに。 おっしゃるとおりバカでございます 有名なフレームワークの名前は一通り存じてございますので 名前をおっしゃっていただきさえすれば理解することもできましょうが なにぶん、新種のフレームワーク事情にうといものでして 名前もわからないと何がなんだかわからぬのでございます 問おう、何のフレームワーク? これだけ、罵ったんだから当然知っているだろうし答えられるよね(はーと)
>>553 何言ってんのかわからん。
510をフレームワークと呼んで何が悪いんだ?
>何言ってんのかわからん。 >510をフレームワークと呼んで何が悪いんだ? 何言ってるんですか フレームワークといったらMVCやDocument-Viewなんかのことですよ 基本ですよ、知らないはずがないじゃないですか もし、知らないでフレームワークフレームワークきゃはきゃは言ってたら馬鹿ですよバカ 新種のフレームワークなら名前を付けてください名前を 既存のフレームワークのような口ぶりで語るから 有名なフレームワークと勘違いしたじゃありませんか あやまってください、お天道様にあやまってください あやまれよぅ><
なんか実例出されてアンチがみんな卑屈になってるな… 結局、言葉遊びで批判はできるけどプログラムで証明することは出来なかったということか。
>>547 >> 描画とロジックを混在させるのはまぁ、みなかったことにして
>本当に馬鹿なんだなぁ。あれがあのフレームワークの真骨頂なのに。
あのフレームワークて何?まさか
>>2 ?
描画?真骨頂?OBJやBGを出力してくれる回路積んでた当時の話?
OBJの描画処理つーても基本的にはOAM(OBJの属性情報を入れるRAM。位置とかパターン番号とか)の
指定位置を書き換えるだけ。更新、状態遷移が確定したついでにOAMの指定位置を書き換えてたってだけ
真骨頂?は?
>あのフレームワークは、オブジェクトのinteractionを定義できるようになっているから、
>描画すらも、Windowとobject(画面に表示すべき物体)とのinteractionとして定義できるってことだ。
何いってるのこのバカタスカーは?頭蓋の中に何入ってるの?うんこ?
>>557 基地外死んでくれ。
あのソースすら読めないならプログラムを語る資格はあんたにゃ無い。
>>559 なんであのフレームワークとか言うんだ?
本人がタスクシステムつー名前付けてるんだから
>>510 のタスクシステムて呼んであげればいい
>>2 との共通部分はごった煮ってだけだけど
作者の意思は尊重されるべき
>>560 ああ、そういう意味なら、勝手に呼び変えて悪かった。
わしゃばかじゃけぇ、英語はよぅわからんのぅ アーキテクチャパターンの話だと思ったんじゃがのぅ 違ったようじゃのぅ、何の話をしておるのかさっぱりじゃのぅ しかし、そのスーパータスクシステムフレームワークを使う効能は なんじゃろのぅ わしゃいなかものじゃけぇ、ようわからん
>>562 無理に理解する必要無いでしょ。特に必要性を感じてないなら。
別に他の方法で実装することもできるんだし。
自分のスキルにあった好きな方法で作ればいいんでない?
いくつかゲーム作ってれば、そのうち「あぁ、ここで使えば便利かも」って思える日が来るかもしれないし。
ゲームのタスクシステムなんて必要性を感じて、あれば便利だと思う人が使えばいいだけのもの。
誰も使用を強制なんてしてないよ。個人で作る範囲ではね。
564 :
名前は開発中のものです。 :2009/02/14(土) 20:04:51 ID:vvv9+ke/
>>563 なるほど、あんたがやねうらおさんか又はそれに類する人ですね
タスクシステムはカルトや偽科学と同じ有害なもので
関わったものをほぼ間違いなく不幸にするだろう
カエルとびをすれば足腰が鍛えられるよって言う時代もあっただろう
焦って高い技能を取得しようとしている人を騙して(本人にその自覚はないだろうが)
あのおかしなパターンの使い方のくせを身に付けさせてしまったら
まともなパターンの使い方を覚える枷となる
ゼロからやるよりも長い時間を費やすことになるだろう
そして、あなたは長い時間をかけて嫌われていくのだろう
自らの無知を自覚せず行動するものは多数の者を傷つけるのだろう
あんたは何もわかっていない、又はわかっていて騙している悪人だ
私はあんたに要求する、黙るか、もっと考えろと、そして私欲を捨てろ
うんこでもしながらよく考えるんだな
>>564 あのな
あんた一つの目的を達成する方法は一つしか無い、と考えてるのかい?
別にタスクシステムの考え方は万能じゃない、一つの方法に過ぎんよ。
使えるときには使う、他の方法がいいときは他の方法を使うって柔軟性が無いと
プログラマなんてできんよ。
方法はたくさん知ってるほうが有利だろ、タスクシステムを頭に入れたら
頭の中それだけになって他の方法を入れられないような鶏頭なら別だが…
>>552 シンプルな相互作用と、シンプルなインスタンスなら簡単に書けて良いけど、
ちょっと規模が大きくなると辛そうな気はするな。
たとえば FPS だと、ヒット判定は総当りではなく BSP なり何なりで空間分割しないと
キツいが、こうなると TASK2() 使えない。もちろん"タスク”の枠組みでも書けなくは
ないが、ベタ書きより複雑になったら意味ないので。
メンバ変数全部 public も辛いかなぁ。アクセス保護の観点では、Star と Windows の
相互作用では m_x, m_y, m_w を readonly でアクセスしたいが、TASK1(Star) では
メンバ変数全部 read/writeしたい。
あとメンバ変数直接アクセスする仕組みだと、分割コンパイルにも支障が出るかなぁ。
処理が全部 Loop() に集中するから、こいつは Star や Window など全クラスの
定義を知っている必要がある。
また、Star などが単純で状態をほとんどもたないなら良いんだが、状態が複雑になると
外から直接メンバ変数を書き換えるのは危ない。たいていの場合、ヒット判定して、ヒット
してたら双方にメッセージを送っておくだけで、すぐには処理しない。で、後で自分の
Update() 処理の中でメッセージを受け取ってきて、自分の状態とメッセージを照合して
状態遷移する。
この辺の仕組みを入れようとすると、逆に複雑になりそうな気がする。
最後に欠点じゃないけど、タスクの派生クラスをどう扱うかは悩みどころだ。たとえば
Star を継承した Blackhole があったとして、こいつは TASK2(Star,Star) で参照される
べきか無視されるべきかの指定はあったほうが良いと思う。
>>564 ポエマーいい加減死んでくれ
プログラムが読めない低脳がプログラム語るんじゃねえ
>>556 寝言は寝て言え
たとえば、アンチタスクシステム側である俺が何故一貫して『
>>510 のタスクシステム』を
一切叩かないかというと、それが
>>2 とは提供する機能も実装も異なり、そして思想レベルでも
>>2 とは異質だから
たまたま同じタスクシステムという名、固有名詞を産みの親より授かった実態の全く異なるプログラムでしかない
俺の攻撃対象である
>>2 とそれを誉めそやして猿まねしてる石器人とは異質すぎる
>>568 実装も思想レベルでもありふれたタスクシステムと変わらないと思うが。
510の実装のキーポイントは、型を指定しての列挙だろう。
タスクのinteractionを書けるが、それにしても2つの型を指定して列挙してforeachを2重に回して
書いているのと何ら変わりがない。
これらの必要性は従来のタスクシステムでも散々言われてきたことだ。
>>567 そいつはうんこうんこ言う詩的な便意君だろ
うんこが詰まると思考も詰まる体質なのかしらんが言動の水準が不安定だな
>>568 あれ?
いつのまにか俺俺タスクシステムは攻撃対象から外れたんだ。
まぁ、それなら話は早い。
今時
>>2 と同じコードを使った古典的実装の化石なんてまずお目にかかれない。
今使われてる自称タスクシステムはほとんど拡張された俺俺タスクシステム改だよ。
>>2 だけが限定なら見えない敵と戦うだけ時間の無駄だからやめとけ。
>>566 >ヒット判定は総当りではなく BSP なり何なりで空間分割しないと〜
型から判別するのが方針である以上、判別がそれと違う方法を取る空間分割は
確かにこれに入れないほうがいいと思う
>メンバ変数全部 public も辛いかなぁ。
これは上手くやればなんとかできないだろうか........できないか
列挙と処理を一緒にやっちゃってるから、ここらへんに歪みがでてるんだろうな
列挙だけやらせて、その結果を使ってその別の場所に放り込むように
したほうがいいかもしれない
見た目はとっても面白いんだけれどもなぁ
>>572 おいおい。書いた本人は、C++は素人なんだからそんなところ突っ込んでやるなよ。
本当は、2つの型の相互作用させるのにしても、510のソースのように単純に
ループを2重に回すと要素数の2乗に比例する時間がかかるから、
指定された2つの型のものを1回のtraverseで、個々のvectorにでも格納して、
そのvector同士に対してfunctorを呼び出してやったほうがいいに決まってる。
だけど、まあ、そのへんは、コンセプトデモってことで別にいいんでね?
>>566 > 最後に欠点じゃないけど、タスクの派生クラスをどう扱うかは悩みどころだ。たとえば
> Star を継承した Blackhole があったとして、こいつは TASK2(Star,Star) で参照される
> べきか無視されるべきかの指定はあったほうが良いと思う。
510は前者の実装。後者の実装にしたければ、dynamic_castしているところをtypeid
の比較に変更するだけ。
まあ、そのへんは突っ込んでも仕方ないかと。
ああ、すまん。
>>573 は 572に言うべきことじゃないな。566に言うべきだな。
> メンバ変数全部 public も辛いかなぁ。アクセス保護の観点では、Star と Windows の
> 相互作用では m_x, m_y, m_w を readonly でアクセスしたいが、TASK1(Star) では
> メンバ変数全部 read/writeしたい。
これに対してな。
>>573 >だけど、まあ、そのへんは、コンセプトデモってことで別にいいんでね?
>>510 は目的なんか何も言ってないんだけど?
>>576 あのソースが本チャンで使えるものだと思ってるなら、お前は頭おかしい。
>>576 > for(size_t _i1=0; _i1<_size; ++_i1)\
> for(size_t _i2=0; _i2<_size; ++_i2)\
> {\
> if(NULL==dynamic_cast<Operand1 *>(Operand::OperandsList[_i1].Head())){ continue; }\
> if(NULL==dynamic_cast<Operand2 *>(Operand::OperandsList[_i2].Head())){ continue; }\
ここにしても、一つ目のifを2つ目のforより手前に書けばいいものをわざわざ内側に書いてるのは
わかりやすく見せるためだけであって、速度的な観点からすれば無駄以外の何ものでもないんだが。
これがコンセプトデモで無いなら何だと思うんだ?
>>571 アンチが反応するのは
「タスク=ゲームオブジェクト」システム
俺俺タスクシステムか、C++なんちゃってタスクシステムか、
>>2 かは関係無い。
アンチタスク派が
>>510 のプログラムを見て寝返ったのは面白いな。
まあ、510のプログラムすら読めないクルクルパーは論外としてな。
アンチタスク派はそもそもタスクシステムを何だと思ってたんだろうかな。
型を指定しての列挙は例えば、やねですら何度もしつこいぐらいに書いているのに。
http://d.hatena.ne.jp/yaneurao/20090203 やねの提唱するタスクシステムでも、510の書き方が出来るわけで、彼にしても
こういう書き方をすることも含みに持たせているのにそれすら
このスレのアンチタスク派はわかってなかったんだろうな。
まあ、結局、こうだろ。
俺>>(超えられない壁)>>やね
>>510 >>(超えられない壁)>>このスレのアンチタスク派
581 :
名前は開発中のものです。 :2009/02/14(土) 21:27:52 ID:vvv9+ke/
> ID:vCXBLjPV バカな奴、墓穴を掘ったな 俺の言葉で語るということは、俺のフィールド上に上がるも同然 フレームワークを選択する場合に必要な情報というものもあるだろう というわけで、タスクシステムのメリットとデメリット等を 教えてもらおうか
>>581 なんか知らんが510のプログラムすら読めないポエマーは引っ込んでろ。
>>571 文盲妄想更年期障害脳軟化タスクオヤジか
てめえはまず俺の質問に答えろ
>あれ?
>いつのまにか俺俺タスクシステムは攻撃対象から外れたんだ。
おめえはまず両目の瞼と眉を洗濯バサミで挟んで
>>527 を100回読み返しな
巡回ナメナメは得意なんだろ?ナメるように読め
俺は、議論で窮すとてめえの都合で狭義(は?)だの広義(はぁ?)だのの
新解釈をクリエイトして逃げ回ってるタスカー気取りのカス共が大嫌いなんだよ
>>583 そいつはどうでもいいから、俺と遊んでくれ。
510のプログラムについてもっと建設的に語り合おうぜ。
>>571 >まぁ、それなら話は早い。
>今時
>>2 と同じコードを使った古典的実装の化石なんてまずお目にかかれない。
>今使われてる自称タスクシステムはほとんど拡張された俺俺タスクシステム改だよ。
おい、また妄想か?てめぇの身の回りのローカル情報か?検証可能なのか?
悪いこた言わねー。黙って目を皿のようにして過去ログ読み返せ
ほれ、21世紀にもなって松浦本や逆引き本で嬉しい嬉しいて喜んでる奴いんじゃねーか
今もが泳いでそうな奴がそこらにいるんじゃないか?あ?
>
>>2 だけが限定なら見えない敵と戦うだけ時間の無駄だからやめとけ。
てめえに都合の悪いクリーチャー共の存在を無かったことにしようとしても無駄だからやめとけ
誰もタスクシステムのメリットデメリット、存在意義を教えてくれませんっ><
>>2 を読んでみても実装方法しか書いてありませんっ><
しかも、
>>2 は違うとまで言われましたっ><
「それは広義のタスクシステムだよ」とわけのわからないことを言われましたっ><
フレームワークの話だと思っていたらイディオムの話でしたっ><
イディオムの話だと思っていたらやっぱりフレームワークの話でしたっ><
海外ではまったく見かけられません、有名な本にも載っていませんっ><
プログラム読めるのになぜか読めないことにされていますっ><
挙句の果てに、なぜか集中攻撃を食らいますっ><
>>586 あんたは510のソースを読めなかったんだから、あと半年ほどROMってなよ。
>>587 ちょっと待て
今ネトゲやりながらだから頭使うレスできない
忘れてはならない タスクシステムを使うことによって何のどんな問題が解決するの?
木を切ったことのないやつに ノコギリのメリットとデメリットを説明するには骨が折れるなぁ… タスクシステムの考え方はゲーム作るうえで便利だから、というのは 自分で経験して体感するのがいいと思う。 数当てゲームとか○×ゲームみたいな小さいゲームじゃなくて ステージ制シューティングとかそれなりに複雑なゲームを作ってみるといいんでないかな。 タスクシステムを使うにしろ使わないにしろ、そーいったシステムの必要性は理解できるようになると思う。 もっといい実装があるなら使わなきゃいいだけの問題だし。 ゲ製作技術に居るってことはゲーム作りたいんでしょ? たぶんここで屁理屈こねてるより有意義だと思うぞ。 まぁ、それが出来ないコンプレックスからタスクシステム憎しになってるなら もう何も言えんが…
>>591 で?誰のなんの質問に答えた気になってるの?
馬鹿じゃないの
593 :
名前は開発中のものです。 :2009/02/14(土) 21:54:23 ID:vvv9+ke/
>>565 ID:vCXBLjPV さんへ、お元気ですか、私は元気です
>あんた一つの目的を達成する方法は一つしか無い、と考えてるのかい?
俺は天才なので数多の戦術から最適な戦略を模索します
>別にタスクシステムの考え方は万能じゃない、一つの方法に過ぎんよ。
>使えるときには使う、他の方法がいいときは他の方法を使うって柔軟性が無いと
>プログラマなんてできんよ。
>方法はたくさん知ってるほうが有利だろ、
だから俺はずっとそう言ってるでしょうが
>タスクシステムを頭に入れたら
>頭の中それだけになって他の方法を入れられないような鶏頭なら別だが…
選択するときに必要な情報がない、全くない、誰も答えない
何度も聞いてるのにタスカーはみんな無視、誰も答えない
メリットとデメリットがわからないものを選択肢に入れろと?
何をバカなことを、わはは
それさえ答えてくれれば話は進む
さぁ、遠慮せずにメリットデメリット等の
タスクシステム特有の情報を惜しむことなく我輩に告げるがよい
チンチン、まだー?
>>591 そんなことどうでもいいから510読んだ感想でも書いてよ。
>>577 問題は、コンセプトを維持したまま本チャンで使えるように改修できるかどうかだな。
俺は、あの"タスク”はネタとしては面白いが、使える場面は極めて限られると思う。
ちょっと複雑な処理をしようと思うと、逆に枷になる。
ネタとしては面白い。
596 :
名前は開発中のものです。 :2009/02/14(土) 22:00:50 ID:vvv9+ke/
>>591 結局、答えられないんじゃん
うちの宗教に入るメリット?
うーん、とりあえず入っちゃって考えればいいよ
さぁ、入会だ
だってよ、ふぅ危ないところだったぜ
こっちは質問は明確でずっとそういい続けてきたのに
タスカーはみんな無視してきた、ずっとだ
何がいいたいかと言うと
ばーかばーかちんじゃえ
お前等馬鹿どもにいいことを教えてやろう
何をやるにも目的をはじめにおかない
自分のとった行動の理由を後で考える
とった行動の優劣の判別ができない・させない
これらは他にどんなことができる奴であろうが技術者として最悪だ
何も生み出せない
この先素質や直感だけじゃ解決することができないような仕事をやるハメになるだろうよ
そんときにこの有様ではなにもできない
成長しねぇっつの
>>510 が出てきたときにソースがあるってだけで飛びついて
目標もなにもねぇのに評価なんてはじめた馬鹿は何か考えて評価したのか?
目的がわからねぇのにてめぇ、何を評価しようとした?
手段のためには目的を選ばず
何か発見があったら儲けもん程度の軽い気持ち
>>597 目的って、あのソース見て目的がわからなければ相当の低脳だろ。
プログラム一行でも書けんのか?
プログラムかけねぇヤシはすっこんでろ。
>>510 のねらいって本当に達成できてる?
> 処理の流れが基本一本道なので、どこで誰がなにをしているかすぐ分かる。
これを達成しつつ、
> 処理の自動並列化。
これを実現したいということだよね。
そのためにデータ共有を制御したいということだよね。
> ・データベースへのリクエスト時はデータベース全体をジャイアントロック。
これは分かる。
> ・しかし、リクエストそのものは並列実行される。
意味不
ロックされてるのに?
もしロックしてるやつが書き込みしてたらReadOnlyですら保証されないよね
あと、
> すべてのデータがデータベースに登録されているので、データ構造が明確。
メモリ上の情報だけでなくデバイスもデータとして扱うとデータ間に依存関係あると思うんだ。
DirectXデバイスとTextureとか。その辺不明確では?
>>510 のコードの半分も理解してない(読めない)俺が間違ってる?
>>600 そうやって明確に答えずに変な解釈ばっかりするからこのスレはこんな有様なんだよ
そうだと思ってたことが実は違うなんてことは頻繁に発生する
わかった気になるのが一番怖い
ためしにお前がどう考えたのか
>>510 に確認とってみろ(別人かどうかは知らんけどなw)
コードから読み取るにしても説明があった方が読み取り易くなるし誤解も減るからあった方がそりゃあった方がいいでしょう 同じコードから読み取れるものが皆同じってのはちょっとありえないと思うわぁ
>>598 本気でその状態で怖いわ
ジャンプにナ○トってカオスな漫画があるけど
このスレも全く同じようなカオスな状態で全然笑えない
プログラマでこれかよって感じ
>>599 それは技術者にとって負債にしかならない
折角叩き台にソース張られたのに、 苦し紛れに罵倒するだけで、結局プログラム的な反論がほとんど無いのかよw 口汚くても有意義な情報が見られるかもと思ってpart1から見てたのに、 アンチタスク派にはホントがっかりだわ。最初から最後まで口だけか。 もーそうやって一生罵倒してろよ。 お前らはもうソレしか出来ないんだから。 やっぱゲ製板の住民だよ、お前ら。
>>606 だからぁ
そうやって主旨を横にどかして感情だけでしゃべるなよ馬鹿
本当にプログラマかてめーは
今日の飲み会盛り上がりましたね!?
って妙な確認とってくる新人かてめーはw
ソース自体を公開するのはいいよ
でもそのソースの目的を明確にしてもらわなきゃなにも判断できないだろ
>>603 ども。やっぱり。
というかもう
>>566 で危ないって書いてたんすね
さっき読んだ時はなんか難しいこと言ってんなー、位で理解できてなかった
目的なら
>>528 に書いてあるんじゃないの
正直俺も
>>601 同様の疑問を持ったけど
C++は参照透明な純粋関数型言語ではないので、副作用だのオブジェクトの破棄だのが
色々ネックになりそうに見える
単なるISAMならともかく
まともなRDBなどでは読み取り一貫性のようなものを保障するためには
相当にしち面倒くさいことをやっているが
>>609 は?
俺にはメリット(=目的でなきゃ駄目だろ?)がまったく見えねー
>>528 に書いてあるのはただの処理内容だろ?
やりたいことは〜って文章からまったくつながってねぇよ
C言語やる前に日本語どうにかしろよレベルだろコレ
>>610 >排他処理の自動化。データ構造に基づいてロックをかけるのでデッドロックしない。
>処理の自動並列化。
>すべてのデータがデータベースに登録されているので、データ構造が明確。
>処理の流れが基本一本道なので、どこで誰がなにをしているかすぐ分かる。
これはメリット=目的だと受け取っていいんじゃないの?
できてるかどうかはともかく、ね
目的は一つが原則だよっ それを達成するための手段はいくつあってもいいけど その手段それぞれにメリットデメリットがある タスクシステムも手段の一つに過ぎない さっ、教えてくれ
>>611 は?どれが?
そもそも1つじゃなくてなんでたくさんあるの?
例えばな
「自動化」
ってあるけど
自動化はわかった
で?何がいいの?
ってなるじゃん
機能を並べただけなんだよ
それとそのメリットって
>>2 と比べてこのソースは〜って話?
それとも普通の組み方と比べてこのソースは〜って話?
この文の説明が抜けた >そもそも1つじゃなくてなんでたくさんあるの? まず、大まかにそんなにたくさん主旨があるのはおかしいだろ それ、全部目的なの? 仮にそれのどれが欠けた場合に失敗なの? それの1つでも残れば他にどんなデメリットが出ても成功なわけ? 一つに絞れよ
んなこと俺に言われても知らんがなw ちゃんとpros/consが網羅されいるとも、分析/評価としてちゃんとしてるとも 別に俺は思わないしね つっかかる相手を間違ってないか?
また止まる、実装の話のときは止まらないのに 確信に近づくと止まる、メリットデメリットを聞くと止まる そして日付が変わってIDが変わる 今までの話はなかったことにして、話題を変えてまた実装の話 これの繰り返しだよ 代わりをよこせといってる人がいたからDSLを持ってきたのに 無視しやがるし、ちくしょうめ
>>610 俺の目的はゲーム作りの型を身に付けること。これで十分だろ。
まさか2chに来ておいて統一見解求めるつもりは無いよな?
修破離の修を独学でやるには既存の型を学ぶのが手っ取り早い。
そしてそこにC++なんちゃってタスクシステムがあった。だから飛びつく。
全くの初心者がいたとして、運しだいではこういったこともありえる。ただそれだけの話。
それこそ何を目的に何を問題として提起しているのか。
タスクシステムの根本思想が「タスク=ゲームオブジェクト」と腐っていようと、
規模の増大に耐えられない虚弱で捻じ曲がったシステムであろうと、
本当の初心者がたとえミニゲームであっても実際にゲームを完成させることが可能という点で
目的は達成可能な手段ではある。
目的を達成可能な手段がそれしか見つけられないならば、
たとえ先の無い最悪な手段でもあると分かっていても使うやつは使う。
他人ができるのはよりましな手段を残しておく位だと思うが
なぜその議論自体を止めようとするのか。
先達のいない孤独な入門者が必死にゲーム製作への道を模索してようやく腐れタスクシステムを見つけたときに、
それは糞だ。だから使うなと言い放ってまた路頭に迷わせるのと、
それは糞だ。だからもっとましなこっち使えと言うのと、
一体あなたはどちらを今実施しているのか。そういう話。
俺としては「タスク≠ゲームオブジェクト」な養成ギプスシステムを作ることまで邪魔するのは許せない
>>617 ふつーに書けば良いだけだと思うんだが…
何をそんなに悩むのかが分からん。
620 :
510 :2009/02/14(土) 23:44:17 ID:V87nWtWS
ネタばらしすると、 ・タスク → データに格下げ ・foreach → タスクに格上げ ってだけなんだけどね。 なんせタスクシステムっていう名前が悪かった。 タスクなんて言うから、データに処理をくくりつけたくなってくる。 タスクなんて呼ばず、データなりリソースなりというもっと低レベルな名前にしておけば、 そこに処理を括り付けようなんていう厨発想は消える。 変わりにforeachをタスクと呼びかえ、適当なマクロ定義して、 「ここに処理を書けば自動で並列化できますよ」と提灯ぶら下げとけば、みんなそっちに書く。 かくして世の中は平和になる。タスクシステム論争終わり。めでたしめでたし。
for文わかったー! 配列とりあえずわかったー!(気がするー!) 定義と宣言の違い、わからないー! ポインタ、全くわからないー! というレベルを想定してみよう。そして頭は中か下程度。 頭いい人とか身近に先達がいるという幸運なケースは除いて考えるのがミソ。
>>617 なんだかよくわからないけど
俺が知りたいのはタスクシステムのメリットデメリットであって
君の目的ではない
長々と書いてもらってすまないが見当違いなので
話題そらしされてるのかと錯覚してしまったよ
以下略
>>564
>>622 お前はプログラマ失格なんだから出てくんな
頭のいい人なら 目的と手段ぐらいは明確にできると思うよ 手段の利点欠点ぐらい明確に知っていると思うよ 頭のいい人はすごいからきっとできるよ、できるよ 俺は頭が悪いから教えて欲しいよ、欲しいよ タスクシステムのメリットとデメリットを教えてください また失格言われました><
>>616 おいおい、
>>2 は図も使って紳士的に説明努力もしているサイト群だぞ。
ドラゴンソルジャーLaw(笑)だかDouteiSeniorLoliconだか、何だか知らねえが、
キーワードだけって、なんじゃそりゃ?
全然、筋通してねえじゃねえか。
考え甘いんちゃうか?
>>2 の説明努力が不足しているなら、それも補ってくれよ?
手前のクソは成分が違うって言いたいんだろ?
あぁ?
>>620 結構良かった
何人かこれで攻めていくんじゃないかと思う。
難しくて謎めいてるあたりもそそるかもしれないしね。
>>622 だから無意味で無害なパターンが必要とされてるの
初心者以外にとっては無意味でいいの。無意味で当たり前だから価値があるの。
627 :
名前は開発中のものです。 :2009/02/15(日) 00:20:01 ID:/3SpaYGW
なんでタスクシステムのメリットデメリットを教えてくれないのさ
みんな俺だけ仲間はずれにして、泣くぞ
>>625 前に同じこと書いたけど
>>2 にはメリットデメリットが書いてないし
そのときも誰もメリットデメリットを教えてくれなかったし
推測しろという、不親切過ぎるだろ
補えって言うくらいだから、使ってる人は知ってるんでしょ?メリットデメリットを
まさか知らないで使っているわけないよね
誰でもいいからタスクシステムの
メリットとデメリットを教えてください
いじわるしないで教えてください、お願いします
ハハン、自分で考えろ メリットデメリット→相対的な話
Q.タスクシステムのメリットとデメリットを教えてください A.ハハン、自分で考えろ ……俺はどうすればいいんだろう
>>627 お前が一行もプログラムの書けないポエマーなのは十分わかったから、もう出てこなくていいよ
>>630 メリット、デメリットを出せって奴は俺もいるぜ
比較対象が出てこない限り、 アドバンテージ云々って話にはならんだろ
>比較対象が出てこない限り、 >アドバンテージ云々って話にはならんだろ DSL タスクシステムがフレームワークに類するのかどうかわからないけど フレームワークはいくつかある 比較対照はたくさんあるけど タスクシステムの基本的な事がわからないのでなんとも言えない それに比較対照がなくても、大きいメリット一つぐらいはわかりそうなものだが Q.タスクシステムのメリットとデメリットを教えてください A.ハハン、自分で考えろ なんだかこのやりとりが気に入ったw
DSLつっても色々あんぞ boost::protoでevalできるものは全てDSL(*)って言えるし、さらに(*)すらDSLの一部だぞ
タスクシステム的発想を継承していないゲーム用並列動作処理を、 比較対象として出してみ。 そうすればメリット、デメリットの話もできるだろう。
>>635 DSLのメリットとデメリットはわかる
色々あるなら全部比較対照にすればいいから
比較してタスクシステムのメリットとデメリットを教えてもらいたい
>>636 タスクシステム的発想というものがさっぱりわからないけど
DSL
プログラム入門以前の人 ・メリット:なんだこんな簡単な仕組みでゲーム作れるんじゃん。やっぱりな。これなら自分でも覚えられるぞ! とか、 おれのSTG(もどき)が動いた! といったあたりまでゲーム製作が推進可能となる ・デメリット:わりと最悪の部類に入る設計思想でした。もう一歩も先に進めません。という時期が来る ベテラン(?) ・メリット:デバッガとか周辺ツールが便利らしい ・デメリット:デバッガとか周辺ツールを自分で作るらしい。あと、抽象化を見極めるワザが必要らしい。 タスクシステムに設計パターンとしてのメリットは無いね。 Byアンチ
>>637 DSLとやらと比較したいんだったら、自分で比較作業やればいいじゃないか。
それを他人にさせようとするなよ。
ただしタスクシステム批判するなら、根拠となる比較作業結果を明示する。
>532 > 『ローカル用語だな。公衆の場で何の事前説明もなくタスクシステムとか語られても意味わかんねー 』 > 脳みそに染み渡った?質問どうぞ つまりアンチタスクシステム厨というのは、自分にとって理解できないものに対して『俺は何が理解できて いないか理解できていないぞ』と公衆の場で叫ぶキチガイと言うことか?
>>641 mainにwhileがあって中で星の数だけ処理をforで回す…と。
初心者がC言語習って最初に作るミニゲームとかはこーなるだろうなーと。
これでブラックホールとか自機とかさらに複数の要素が加わったら全部の要素をこのwhile内にハードコードで追加して巨大化していくのかな?
タスクシステムなら新しい要素をタスクに登録するだけで、スクリプトとかから動的に要素を増減できるけど。
さらに、ゲームだとタイトルとかコンフィグとか、デモとか、ボーナスステージとかステージ毎に違う仕掛けがあるケースはどう書くのかな?
一個のメインループの中にswitchとかで切り分けて無理やり全部詰め込む?
それとも全ての要素の組み合わせごとにメインループを分ける?
…ってことは見苦しいからやりたくない、って思ったプログラマがタスクシステムを作ったんだけどね。
タスクならメインループは一個。タイトルやゲームも要素の増減もタスクで処理可能。
頑張って非タスク作るって、結局アンチはその程度のことも分かってないプログラマだった、という証明になってるんだが…
まぁ、たまたまこのアンチのレベルが低いだけで、まさか全部のアンチがこんなレベルのプログラマじゃないよな?
>>504 オレも最初そう思ったw
Squirrel可愛いよSquirrel
タスクからSquirrel呼んじゃうよ(まあ俺はタスク使わんけど)
んで、まじめにDSLという(Java/Ruby界隈中心に広まった?)言葉の定義を調べてみたが、
どうやら外部DSLはSquirrelやLua、XML、JRuby、Groobyのようないわゆる組み込み言語を指すらしい
で、内部DSLというのはyacc/bisonやboost::lambda、Lispのマクロ機能、
アスペクト指向トランスレータに見られるような言語自体のメタ的拡張手法を指すようだね
煽るつもりはないが、内部DSLがゲームのなにを解決するのか分からないなあ
しかもタスクの問題範囲と競合してるようにも見えない
どういう風にゲーム開発に活用しているんだろう?モナディウスとか?
>>642 売り言葉に買い言葉なのは分かるが、安全なところから他人のコードを叩くなよ
>>643 まあ、アンチの代表格が、510のプログラムさえ読めなかった低脳ポエマーだったことが発覚したので仕方ないんじゃね?
あと説明責任君とか。510のプログラム見てわからないなら、プログラマを語るなと言いたいんだが。
>>642 だから、こんなサンプルじゃそーゆーのを俺がどう書くのかわかんねーだろ?w
だから、自機、敵、弾のサンプルのがいいって言ってるのに
>>645 ならこのサンプル出す意味無いんじゃね?
タスクシステムの比較対象にすらなってないし。
俺は
>>641 のほうが良いと思うぞ。
単純で読みやすい。
whieループの中の「〜タスク」は別関数に切り出して欲しいが。
こんな簡単な問題をなんで変なマクロでくくって、ややこしくするのかが理解できん。
>>510 タスクシステムが理解できないのではなく、
簡単な問題をわざわざ複雑に解く理由が分からんと言っている。
事実、
>>641 のコード量は
>>510 の半分程度になってるだろ。
抽象化コストがまるでペイしてないという実例として有意義だと思うが、どうかな。
>>504 DSL具体例出してくれてありがとう。よく分かったよ。
Squirrelな俺にとってはいつのまにか外部DSL派だったわけね。
スクリプトにタスク概念入れると処理の一貫性や可読性やらの諸問題で、
タスク使わない派に戻りました。今のところコルーチンでFAな感じ。すげえし読みやすい/書きやすいよ。
もしコルーチンで記述できない/処理が重い問題にぶち当たればタスクに戻るよ。その辺は柔軟に考えている。
ゲームっつっても、小規模STGなのか大規模RPGなのか、2D/3Dなのかネットワーク対応/非対応なのかにもよって変わってくるだろうし
理論と実践は異なるってことだよだな。銀の弾丸は無いよ。
各自好きなの使えばいいじゃん。
>>649 こんなんじゃ納得できないと思うな奴等w
結局オブジェクトも1種類しかないし
種類が増えたときにごった煮が役に立つを思ってる奴等でしょ?w
なんで
>>510 なんかに飛びついてたのかわからないけどw
>>648 それは庭いじりしか知らない人がハサミで十分だから
ノコギリの必要性が理解できないと言ってるのと同じ。
サンプル規模のプログラムでタスクシステム使うのは庭いじりにノコギリ使うようなものだが
>>642 のような実際のゲーム規模では必ず遭遇する問題にはタスクシステムかそれに変わる何らかのシステムが無いと
こんなベタ組みじゃやってられんよね、ということだ。
>>652 絶対、かわんねぇよ
だって書かなきゃいけない処理って決まってるじゃん
書かなきゃいけない処理の一覧書き出して
タスクシステムで書かなくてよくなる処理を○でもつけてみろw
自機、敵、弾ってあってそれぞれが関係するなら
自機x敵、自機x弾、敵x弾の関連の処理は絶対に省略できないってw
アフォでもわかるべ〜w
冷静になって考えてみろよw
>>653 >タスクシステムで書かなくてよくなる処理を○でもつけてみろw
タスクシステムは書かなきゃいけない処理を書かなくてもよくするためのものじゃないぞ。
そもそもそんなシステムは無いだろ。
関係するオブジェクトの増減やゲームの状態推移を統一した扱いにできて便利、ぐらいのもの。
自機、敵、弾だけで完結できるほどシンプルなサンプルレベルのなら使わなくてもいいんでない?
>>649 抽象化するコストって、TaskSystem自体は再利用できるんだから、たくさんゲームを作るなら
ゼロに近づいていくんだが。
まさかあんたは一本だけゲームを作って一生を終えるつもりか?
>>654 >タスクシステムは書かなきゃいけない処理を書かなくてもよくするためのものじゃないぞ。
>関係するオブジェクトの増減やゲームの状態推移を統一した扱いにできて便利、ぐらいのもの。
はぁ?じゃ、何がメリットなんだよw
さっさと言えよ
とりあえず
>>510 のサンプルなんてなんの役にも立たないってわかった?
目的もなく動いたって無駄なんだよ
ホント馬鹿だな
無駄、呼吸してること自体が無駄
>>510 のサンプルに飛びついてたゴミはすべて無能
>自機、敵、弾だけで完結できるほどシンプルなサンプルレベルのなら使わなくてもいいんでない?
だから、そういうだろwお前等w
>>510 のサンプルはなんの意味もねーって言ってるのに
わかんねぇかなぁw
>自機、敵、弾ってあってそれぞれが関係するなら >自機x敵、自機x弾、敵x弾の関連の処理は絶対に省略できないってw 処理が似たり寄ったりなら、そこはクラスの「抽象化」の一言で済むんじゃない? タスクの範疇じゃないでしょ。タスクについて勘違いしてるよ〜
>>656 >はぁ?じゃ、何がメリットなんだよw
>>642 でタスク使えばこーかける、ってのが出てるけど。
これじゃ理解できないかな?
まぁ、メリットデメリットが理解できないなら使わなければいいだけなんだが。
誰か君にタスク使うよう強要してるの?
>>657-658 うーん?
何?言ってることさっぱりわからない
苦し紛れに意味わかんないこと言わないでよw
何を言っているのか分からないのなら、デザインパターン/クラス設計についてもうちょっと勉強してくれ。 GoFのデザインパターンとか、その辺から見てみるといいよ。 あくまでタスクは状態遷移のためのもので、データの抽象化等とか根本的に違うっしょ。
>>660 えーだって結局
>>510 のサンプルはなんの意味もなしてないわけでしょ?
あのソースにあれこれ言ってた人はどこ行ったの?
俺はまだ510のサンプルはぱらっとしてしか読んでないが、 従来のタスクよりは、可読性について大幅に改善していると思うよ。 今までのタスクは処理が飛びまくるから目で追うのが大変だったからね。
>>663 >>510 タスクシステムを使ったサンプル(実装例として意味ある)
>>641 何も使ってないサンプル(実装例として意味無い)
だけの話でしょ…
というか、タスクシステムごとき単純な考え方を煽りじゃなく本当に理解できないとしたら
プログラマとしてどーかと思うぞ。
まあ、抽象化された部分がコストに見合った働きをするならOK。
扱う問題が巨大になったとき、
>>510 版と
>>641 版でどれほどの差が出るかなんだが。
なんかあるの?
単にタスクシステムの分だけオーバーヘッドになってるように見えるんだけど。
>>510 を使えば使うほど何らかのコストが浮くのかな?
一体何がラクになるのだ。
どんな問題を解決しているのだ。
もともと制御部っていうのは本質的に複雑だから再利用は難しい。
汎用的にすればするほど中身がなくなっていく部分。
「ドラクエ風ゲームエンジン」「横シューエンジン」「スト2風格ゲーエンジン」「アンリアル風エンジン」
ここまで的を絞って3〜4本量産してようやくペイするってところじゃないか。
マルチスレッドに注目したMTフレームワークなんかは、デバッグのしやすさや移植しやすさも売りにして抽象コストをキッチリ回収している。
実行環境/開発環境として、実行/開発において誰もがぶち当たるありふれた問題を一手に引き受けて解決している。
単にforループで済む部分を別のやり方でやって偉ぶっているわけではないので混同しないようにな。
>>510 これはHOW。結局タスクシステムはどの問題を解決しているのか。
ただのforループ以上の何があるんだ。ただのforループに勝ってるのか。
そうでないならforループを使うほうが遥かに良い。単純明快説明不要でコスト0だ。
>>620 「ここに処理を書けば自動で並列化できますよ」
まず、何がどう自動なんだか分からない。
実のところ、何も自動化されていない。
>>661 お取り込み中のところ横からで済まないが
>>641 のソースだが、明らかに元のソースより読みにくい。
forがロジック部に出てきてるのだとか、null判定してcontinueしているのとか
Starの空きを探す部分だとか。
結局、
・もし事前に510のタスクシステムが存在していてこの開発コストが0だと見なせるなら、
641のコードのほうが工数が多いのは明らか。
・もし事前に510のタスクシステムが存在していてこの開発コストが0だと見なせるなら、
が成り立たないなら641の書き方でいいんじゃね?とは思うけどな。
>>665 で?
>>510 と
>>641 は大して変わらないソースになったけど
これがオブジェクトの種類が増えていくとどう変わる?って展望があるのかな?
そーゆーことが言いたいなら少なくともそういう色の出てるソースじゃないと意味ないよね?
つまり、この時点では
>>510 はなんの意味もない、そういうことだよね?
>>667 >
>>641 のソースだが、明らかに元のソースより読みにくい。
なんか言い出しちゃったよw
結局、アンチって 明確なデメリットがあるからアンチとか 他にもっといい方法があるからアンチ ってわけじゃなく そもそも経験不足でメリット・デメリットや使いどころが想像つかないけど 他の人は理解してて悔しいからアンチ って感じにしか見えん。 自分の好みに合わないなら使わなきゃいいだけなのにねぇ…
>>666 > 「ドラクエ風ゲームエンジン」「横シューエンジン」「スト2風格ゲーエンジン」「アンリアル風エンジン」
> ここまで的を絞って3〜4本量産してようやくペイするってところじゃないか。
そう簡単な話じゃないんだ。
これは現場の俺から言わせてもらえれば、
エンジンを作ったり設計したりしてるのは賢い連中なのよ。
それぞれのゲームを作ってるのはもっと質の悪い、単価の安い、なんと言うか・・まあ、皆まで言わすな。
だから、プログラムのうち、難しい部分と簡単な部分とを切り分けて、難しい部分を賢い連中に
担当させるのは、理にかなってるんだよ。
>>650 組み込みスクリプトには2種類のメリットがあると思う
1.フレームをまたいだ継続処理の記述が平易にできる
コルーチンがもてはやされるけど、実はコルーチンでなくても
コンテキストを保ったままフレームをまたげる実装であれば良い
そういう意味では目新しいものではなく、今までも各社独自でこのようなスクリプト実装は行っていた
2.データをソースコードの外部に出すことができる
Game Programing Gems1巻で最初に触れられるのがこれ(データ主導設計)
今風に言うとXMLよりJSONだよね的な話だが、もちろんコレも新しいものではない
こうして見ると、結局コルーチンもデータ主導設計もDSLと同じで、
それと意識されることなく昔から使われていた手法だよね
考え方に名前を付けるのは必要なことだけど、普及しはじめるとHYPE化するのはどうしてなんだろう
みんな銀の弾丸が欲しくてHYPEに踊らされすぎなんじゃないか?
#もちろん"タスクシステム"もHYPEであり、タスク厨はそれに踊らされ、アンチはそれを嫌うクセに別のHYPEに群がるんだ
非タスク版は車輪の再開発すぎるっしょ。
わざわざ
>>510 から戻した理由がわからん……。
>>672 なかなか深い観点だ。恐れ入った。
業界人じゃないから昔の話とか全然わからんけど、色々と工夫していたみたいね。
いまからゲームを作るのであれば、コルーチンで書く書かないはスクリプターのセンスに任せるとして、
データの外部化については正直必須だと思うんだ。
その辺をしっかり作っておけば、準汎用で使いまわしが便利な資産になる感じだと思ってる。(完全に汎用ではないけど)
HYPE化はしかないんじゃない?
タスクに代わる実装には選択肢が多々あるから、
1択に絞れる(1択に絞れる方法が存在する)のならそれに依存したいとおもうのは仕方ない。信仰宗教と代わらんね。
結局、実際にいろいろ使ってみて自分でレビューするしかないな。 作るゲームの規模や種類によっても違ってくるだろうし、 万事での最善も最悪も無さそうだ。 実際にある程度の規模のゲーム作って 議論してるやつがどれだけいるか知らんがなあ。
1000行以下なら構造無しで気合でどうにかなる
1000行程度から5000行程度ならタスクシステム導入でもなんとかやりすごせる
30000行程度ならタスクシステムは糞。完全に開発ストップ。
>>641 的に書くとこから再出発。
100000行程度、、、組んだこと無い
>>641 よりタスクシステム導入した方が良いとかいうやつ、30000行以上のもの書いたことあるのか?
また話変わるぞ?
そんな小手先の技術じゃどうにもならなくなる時が来るはずなんだが
なぜそこまでたどり着かないのか不思議
行数で手法を変えなくてはならないのは タスクシステム以前に設計が糞なだけだろ
>>678 タスクシステムは設計の範疇にいれないんだwww
設計じゃないならなんなんだよwww
昨日
>>510 面白い面白い って言ってた奴だけど、
自分も同人で50Kオーバーの作品を作ったことあるけど、
総ステップと、タスクが使えるかどうかは、
>>670 と全く同じ考え。
タスクシステムは歪みがこの程度のサイズで出てくる。
行数で、手法を変えるというよりも、タスクでやるのが、無理になってくる。
>>677 3万行って、ソースで言えばたったの1MBぐらいだろ?
10万行規模のソースのあるプロジェクトに関わったことがないって、どこの弱小ゲームメーカーだよ。
ちょっとした規模の商用ゲームなら、ライブラリの一部だけでも3万行ぐらいあるだろうに。
タスクシステムに限らんが、使うに値するところには使えばいいんだ。
まあ、たいていのゲームは大規模になってくると、そのゲームに特化したエンジンにせざるを得ないので
汎用的で使い回しの利く部分は減っていくのは仕方ないが。
規模が大きくなるとタスクで使えなくなるのは同意。
タスクシステムは規模が大きくなるにつれ処理を追うことが困難になりやすい。
(そのためにタスク管理やタスク監視のデバッグメニューを実装する必要も出てくる)
そんな中
>>641 に戻すのも手だが、それなら初めから組み込みスクリプト使うかな。自分なら。
複雑な組み込みスクリプトってさ、
CGエフェクトのハードコーディングを避ける目的に使うくらいじゃねえの?
ある程度、個々のタスクの動作の選択肢が限られているからこそ、
>>2 をより一層抽象化できるというか。
タスクシステムの動作原理を継承しているよな。
50万行規模の某シュミレーションで全てタスクで実装してるのを見たことあるが。
決して見やすいソースでは無かったけど、不可能では無いわな。
ゲームのモード用メインループタスク階層。敵や味方のオブジェクト用タスク階層。
メニューシステムタスク階層とか、分割統治方式で使ってたが。
他にはswitch/caseの状態を階層化して管理してる某ステップ方式とかも見たことあるが
どれも規模が大きくなると悲惨なことには変わりなかったなぁ
ただ
>>641 は何のシステムも無しに力技でベタに作ってく方法だから、そもそもタスクが使えんほど
大きなコードではまったく話にならんよ…
組み込みスクリプトは洋3Dメジャータイトルで積極的に採用されている。
例えばLuaの適用ゲームはこんな感じ。
http://en.wikipedia.org/wiki/Lua_ (programming_language)#Applications
どの程度使ってるのかは、ゲーム内によって異なるので定かではないが、
CEDECでスクエニの中の人が発表していた内容では、
WiiのFFCCというゲームの開発ではSquirrelを使っていて、
コード比はプログラム3割スクリプト7割だってさ。
>>684 それは意図が全然違うじゃん
スクリプトは処理を企画に渡せるってだけでしょ?
書かなきゃいけない処理はまったく変わらない
スクリプトを話題に出してる時点で意味不明
>>687 スクリプトだと中間言語経由になるから、高速な相互影響処理には向いてないよね。
>WiiのFFCC
FC世代RPGの厚化粧版か。
>コード比はプログラム3割スクリプト7割
プリミティブな次元では従来のゲームからの変革はなし。
VFXだけ肥大といったところか。
タイトルの詳細をチェックしていないので、テキトーなこと言ってるけど
結局、タスクシステムは必要ってことだ。
もちろん書かなくちゃいけないコードは変わらないよ。 減ったりも増えたりもしない。 まずは、フレームワークとスクリプトを完全に分けます。 で、スクリプト言語の持っているコルーチンに頼って、 スクリプト実装者がゴリゴリ書く。 仕事も責任も分担できる。オススメです。
その『○万行を超えたらタスクで管理するのがムリになってくる』っていうのは、結局FSMにするのが ムリになってくるってことだろ?
>>691 じゃあ、この場所で出す話題として適切なの?どうなの?
それともその話題はタスクシステムのメリットデメリットに直結するものなの?
ちゃんと考えて発言してよ
>>693 俺の考えは、アンチタスク派で、
タスク派がコード量でプログラムが肥大化して可視性が悪いよというのであれば、スクリプト使え
ってこと。
ちゃんと考えて発言してないように見えるかい?
アンチタスク派に一つ聞きたいんだが、例えば自機選択式のSTGがあったとして、機体それぞれの jikiについての関数は当然別々に書くんだよな? 違うの?
>>695 今後ゲーム開発はスクリプト使う方向に行くだろうし、
それ自体は賛成だけど
タスクシステムの上にスクリプトが乗っかるのか、スクリプトの上にタスクシステムを構築するのか、って感じで
スクリプト自体はタスクシステムの有無とはまた違う話だよね。
間接的にデータ駆動でコード中の複雑性が減ってタスクシステムでもコード見通しがよくなるね、という程度の話なのかな?
まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…
>>696 処理よっては別になるかもわからんねぇ
敵のパーツを奪って武器・装甲を強化するタイプの自機と
経験値蓄積型のパワーアップをするタイプの自機ぐらいの違いがあると
もうプログラム自体共通部分を探すほうが難しいぐらいになるかもしれんし
まあ、仕様によるかな?
何が来てもいいように別にしておくのがいいな
もし、共通部分があったとしてもたかが数箇所(自機分)でしょ?
>>697 スクリプトだけでタスクは乗らないです。
どっちも載せたりすると直感的に分かりづらくなる。
フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
>まぁネイティブコードの量は減るから見通しは良くなりそうだけど、スクリプトの分量が増えると
>ネイティブコードと中間コードの二系統をメンテする手間で結局あまり変わらない気もする…
これは同意です。1人で実装するとなると2倍手間になりそうですが、そこは明確な作業分担でできるってことで。
スクリプトのメンテはスクリプトの動的ロードを実装すれば、プログラム実行中でも即座に反映されるようになるから便利ですぜ
アンチです。
>>696 ごめん。よくわからない 多分自分の理解力不足だけれど
タスクでもそうでなくても、jikiを別々には書かないかと。
タスクにした場合と壮でない場合で、その点に違いが出るの?
>>699 >フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
オブジェクトの粒度をどの単位にするかにもよるけど
例えば敵の弾一個一個につき協調スレッド、ファイバー、マイクロスレッド、のどれかの生成、破壊を繰り返すの?
そりゃパフォーマンス的に厳しいんでないかなぁ…
協調スレッド、ファイバー、マイクロスレッドのどれも普通のスレッドに比べればかなり軽いけど
タスクシステムの関数コール同等の負荷とは比べ物にならないぐらい重いし。
まぁ、十年後のPC環境なら全然問題ないレベルの負荷かもしれんが。
>698 じゃ、自機が変更されると言う仕様を実装すると、それぞれの機体別jikiをswitch〜caseで 分岐して呼び分けるわけ? >700 じゃ、jikiの内部で、機体によって処理をswitch〜caseで分岐するわけ?
>>701 コルーチンはスクリプト言語が実装してくれてるから、スクリプト内で使うんです。
(LuaやSquirrelがスクリプトの実行順に関して、協調型のスレッドをスタック型で内部実装してくれている)
コルーチンの生成にはちょっとコストが掛かるので、一度作ったら再利用して呼び出すことで無駄をなくしますね。
パフォーマンス的に厳しいデメリットに関しては、ネイティブ側で対応します。
(例えばSquirrelはC++のクラスをオブジェクトとして持つことも出来ます)
>703 スクリプト上のコルーチンの中から呼んでるC/C++関数の中でyieldしたい場合は?
話はすれ違ってるが設計は多分同じだ。
擁護派 :本来スクリプト言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている
アンチ派:本来ネイティブ言語を適用すべき箇所に絞ってタスクシステムの導入可否の話をしている
どちらもスクリプト言語を適用すべき箇所まで
>>641 で組むとは考えてないだろうし、
どちらもネイティブ言語を適用すべき箇所までスクリプト化すべきとは考えてないだろう。
多分論点はここかな
論点1:「ゲームエンジン部分=ネイティブ言語の相互作用記述+スクリプト言語解釈部」は意見一致してるよね?
論点2:「個々のスクリプト→個々のタスク」というのも性能UPが必要ならありでは?
アンチはネイティブ言語を全廃してスクリプト言語に置き換えるべきとは言ってないと思うし、
擁護派はネイティブ言語の相互作用記述を分解してタスクに置き換えるべきとは言ってないと思う。
>>702 まだ理解し切れていないのだけれど、
普通に継承使っては駄目ですか?
>>702 どう変更されるかによるなぁ・・・
例えば、自機Aが後方に下がるシーンと自機Bが変わりに前方に出てくるシーンなんか入る日には
もうインスタンス2ついるわけだし操作がユーザにあるって点以外はすべてが別処理じゃね?
ペカっと光ってチェーンジ!でよくてもやっぱり変更が怖いから完全に別にオブジェクトだな・・・俺なら
>>703 スクリプト内で対応しているコルーチンならコンテキストスイッチとか無いからパフォーマンスは大丈夫かもね。
でもそうなるとスクリプト管理オブジェ同士の依存関係が有る場合、状態取得とかで同期処理が必要になるが…
>706 いや、別にそれでいいけど、このスレに約一名C++ワカランチンが常駐してるから、最底辺にあわせて 判りやすいレベルで話した方がいいかと思って。 じゃ、共通部分をtemplateにしてvariantsをfactoryから作るようにして対応するんだ。 常道だよね、やっぱり。
C++わからんとか、510のプログラム読めんとかは、ゲームなんか悠長に作ってる場合じゃねぇだろ。 はじめてのCでも猫でもわかるでも読んで出直してくるべきじゃね?
>>709 そんなことして共通部分が共通でなくなっちゃったら大変だぜ
俺は継承はやらないほうがいい派
メンバで持つ派
>712 そんなのは結局、どこまでをまとめて一つのクラスにするかの問題だから、瑣末なことだよ。 作ったものを修正せずに済むとか思ってるほうが間違いだ。たとえメンバにしたとしても、 それを分離修正する必要があれば同じこと。
>>709 あ、すまん 継承って軽く書いてしまったけれど、
自分も
>>712 と同じく、コンポジションとかいうの派
>>708 そこが一番のネックですね。
スレッドは協調型のみですので普通のスレッドのような並列処理に関しては、
同期処理が保障されていないです。
(基本はシングルスレッドのみで実装しているので試してみたことがない)
並列可能なスクリプト言語は今後の課題ですね
>>713 上の修正が末代まで来るのがやだから、集約使うのではないの?
集約のメリットは、その部分を丸ごと交換できること。 修正の手間はさほど変わらないよ。とくに機能を分離する場合はね。
>>715 あれ?
>フレーム間をまたぐ処理の場合は、コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)を使います。
ってことはフレームをまたぐオブジェクトが複数ある場合は必然的に
並列処理が必要になるんだよね?
>並列可能なスクリプト言語は今後の課題ですね
となってしまうとその方法(コルーチン)では使い物にならないんじゃない?
結局、スクリプト使ったゲームで一部データ駆動されてるものも
オブジェクト単位ではタスクシステムなりに乗っかってスクリプトのupdate部分がオブジェクト数分定期的に呼ばれる
という実装なんじゃないかな。
でないとマルチスレッドの複雑性の問題をスクリプトが抱え込むことになるような…
実際の話、C/C++のcoroutine使うにしてもスクリプトのcoroutine使うにしても、それが中断してる最中に 内部の状態変更要求を外から通知された場合、どう処理するかが問題。 実行途中のcoroutineを強制的に終了したとしても大丈夫かどうか。
>>715 は現状ではシングルスレッド&コルーチンを使っているんじゃないの
マルチプロセッサでのネイティブスレッドとは違って並列処理にはならないので
同期制御の類は要らないはず
時分割された処理の継続をあからさまにFSMのような形で実装するのと
違って、自然に書けるのがコルーチンの利点で、プログラムカウンタや
スタックのリストアを処理系がやってくれる
>>715 が「課題」と言っているのは、マルチコアでのパフォーマンスが求められる
ようになった場合にどうするか、という類の話では
遅レスだが、
>>699 >コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド)
ってのは結局・・・
//万里ゆうじ氏が著書で紹介していたタスクシステムを参考
struct Task
{
//(1) データ更新・描画処理用関数ポインタ
void (*Update_n_Draw)(Task*);
//(2) データ記録用バッファ。場合によってはメンバ変数に分解して固定。
char WorkBuf[WOKK_BUF_SZ];
//以下省略
: //タスク・チェーン結合用ポインタ
};
上のタスクシステムで言うところの、
1.Task構造体の生成・破棄
2.(1)の関数の切り替え
3.(2)のメンバ変数への分解
の処理パターンを、ある程度、限定・抽象化して、スクリプト駆動でルーチン化してるだけなんじゃね、実質?
コルーチンの生成・フレーム間維持・破棄のために、結局バックグラウンドで、タスクシステムが必要でしょ。
データのまとまりって言うのは、結局構造体だ。
全然違うよw
>>718 >>720 で合ってます。
現在の組み込みスクリプト言語はシングルスレッド仕様で、
マルチスレッド化やマルチコアの恩恵は受諾できないと思います。
>>723 そーなると結局
コルーチン同士のリソース同期処理はどうなったの?
これはスクリプトの仮想マシンがシングルスレッドかマルチスレッドか、というのとは
別の話なのだが。
コルーチン同士のリソース同期処理?? 同期処理はLuaやSquirrelの仕事ですね。こちらが意識する必要はないです。 そもそも走っているスクリプト解釈スレッドは1つだけです。 複数のコルーチンをつくり、中断/再開を行うことで擬似マルチスレッドっぽいことはできますが、あくまで擬似です……。 あくまでコルーチンはコードの見晴らしの為だけに使います。(使うのも使わないのもスクリプト実装者の裁量による)
>725 > 2.(1)の関数の切り替え のあたりが違う。 >コルーチン(いわゆる協調スレッド、ファイバー、マイクロスレッド) でFSM的なものを書くのは、関数ポインタなりswitch〜case使うなりするよりも面倒な時がままある。 特に外から状態が変更されるような場合は。 普通に、外から影響を受けないsequentialな処理を途中でyieldさせつつ、しかも並列に実行したい 場合には効果ある。 だから使う対象をよく観察すること。
>>727 つまり相互影響処理の無いタスクってことだろ。
関数の切り替えは、スクリプトで駆動されたタスク種類によって切り替えるという意味。
>728 関数ポインタは、FSM的な状態変数の代替という意味ではない、と言うこと?
>>729 さっきの例ではそう考えていた。
ところで、FSMっていうのは、例えば、
弱気→(攻撃を受ける)→好戦的→(さらに叩かれる)→発狂→・・・
みたいなタスクの状態メンバ変数の仕様がネットワーク化した場合に、
状態切り替え処理の複雑化を吸収するパターンだろ。
>>730 みたいな本質的な状態遷移は素直に状態遷移として書くのがよいでしょう
コルーチンで楽になるのは、継続を実現するために
FSMを使わなければならないようなケースではないかと
Xをやって→nフレーム寝て→Yをやる
みたいなのを、ある関数(コルーチン)の中に
単に三つの文を繋げて記述できるか
FSMとして書かなければならないかの違いは大きい
で?なんかタスクシステムと関係あるの?
フレーム間をまたぐような連続した処理を書きたいときはコルーチンという手もあるよって事だよ コルーチンを使うのは、タスクでもいいし、非タスクでも良い それにより見通しの良いコードが書ける ってだけ 自分は以前はタスク派だったのが、スクリプトとコルーチンを扱うことで、 アンチタスク派になりました。 (タスクが絶対必要ってわけじゃなく、無くてもコードが書けるよね。 タスクシステムでも別にいいけどさ、正直読みづらくねぇ? という意見)
DSLはスクリプトと同義じゃないよ DSLで紹介されている言語はDSLに近いということ DSLは理想言語、直感的に書ける言語、又はツール、簡単に手早く書ける言語 コストの問題でDSLに近いスクリプトがよく利用されているという つまり、DSLについて考えるということは 出来る限り簡単に、出来る限り速く書くことを考えるということ よくわからないけどそういうこと
DSLは難しい。スクリプト≠DSLであり、スクリプト≒DSLなんだよね。 すまんが実装例が無い現状ではDSLは良く分からない。 しかし、ゲームプログラマが考える範疇ではないことは理解できた。
問題は結婚にも似てるよね。 1.箱入り娘派。全部親が取り持つ。当人同士は直接接点を持たない。完全カプセル化。 2.お見合い派。仲介屋が縁を取り持つ。以降は当人同士の問題。半カプセル化。 3.恋愛結婚派。自分たちで勝手にやってよ。アンチカプセル化。
出来ちゃった婚派と不倫泥沼略奪婚派が無いな。
>>735 //敵のアルゴリズム定義
//aは動くで、bは止まる。
#define ZAKO_ALGORITHM_DSL "abaaababaaaabababaaab"
#define BOSS_ALGORITHM_DSL = "aaaaaaaaaabababaaaba";
〜〜〜
teki *zako = new teki(ZAKO_ALGORITHM_DSL);
teki *boss = new teki(BOSS_ALGORITHM_DSL);
みるからにタスクシステム関係ないな
まぁ要するに所謂データは全部DSLってことだよ。 文字列にしろPCMにしろmp3にしろjpgにしろ実行バイナリにしろ。
>>738 説明してもらってすまんw
思ってたのとさらに違って、よりわけ分からんくなった
データ主導設計をさらに超えて、アルゴリズムやAIもデータ主導で記述しろってことかな?
全てDSLで渡したとして、どこかでDSLを解釈しなくてはならない箇所ができるから、そこのコストがゲームではネックになってるってこと?
あのごちゃごちゃしたC++のタスクシステムを作る能力があるんだったら HSPで高い完成度を目指して作った方が速いし完成度も高いのが作れるDSL的に考えて 熟練した職人がのこぎりとプライドを捨てて、チェーンソーを使えば ものすごい出力を得られるだろう C++は実用的な言語ではなくて、亀仙人の甲羅だと思っている 脱ぎ捨てたときに初めてその真価を発揮する
正規表現や埋め込みSQLも一種のDSLと捉えられるようだから
>>738 はDSLと言っていいんじゃないのかな
正直DSLの適用範囲は非常に広いように思う
タスク信者完全に論破されもんだから DSLとかいう新ワード使ってスレを流そうと必死な奴がいるなw
DSLは問題領域を限定して、その領域の問題を解決するために理想を追求する 弾幕の軌道という問題を解決する手は数多にある そのままコードを書く マクロで書く スクリプトで書く ドローソフトで軌跡を描く 弾幕ツールを作って出力する 自動軌跡生成プログラムを作って出力する 考えられる限りの手段の中から、コストを考慮して、最適なものを選択する 難しいものをできるだけ簡単に書ければ 大量のリソースをできるだけ簡単に作ることができるなら その問題領域をDSLとして書く意味が大きくなる
>>742 > C++は実用的な言語ではなくて、亀仙人の甲羅だと思っている
> 脱ぎ捨てたときに初めてその真価を発揮する
ああ、それはマジでそれは実感するわ・・
俺、C++を10数年やってんだけど、たいていの他の言語がプーだな。
他の言語、ちょろ甘すぎる。
>>742 HSPではDSL用のコンパイラを書きにくい。
HSPでやり始めると、言語としてHSPしか使えない。
>>642 > これでブラックホールとか自機とかさらに複数の要素が加わったら全部の要素を
> このwhile内にハードコードで追加して巨大化していくのかな?
ふつーに書く場合、まずゲーム全体を
1) ゲーム全体で利用する、比較的低レベル(システム寄り)の内容
例:非同期ファイル I/O 管理とか、デバイス管理など
2) 独立性が高く、ユーザから見た「実行中の内容」を反映する単位
例:タイトル、デバッグメニュー、ミニゲーム
「シーン」とか、ウチの社内だと「タスク」と呼ばれてる
3) シーンを構成する個々の要素
例:プレイヤー、体力ゲージ、エフェクト
と 3 レベルに分けて考える。
メインループは 1 の処理と、状態に応じてどれか特定のシーンの更新処理を
呼び出す。更新処理の結果、シーンの遷移が必要になるかもしれないので、
それはシーンから戻り値か何かで取れるようにしておく。
コードはこんな感じ。
void Game::MainLoop() { // 1) の処理実行 AsyncFileIO::GetInstance().Update(); Pad::GetInsstance().Update(); // 状態に応じてシーン実行 switch (scene_) { case SCENE_INIT: title_.reset(Title::Create()); scene_ = SCENE_TITLE: break; case SCENE_TITLE: switch (title_.Update()) { case TITLE_DEMO_BEGIN: title_.reset(); demo_.reset(Demo::Create()); case TITLE_GAME_START: if (title->GetGameMode() == GAMEMODE_SINGLE_PLAYER) { } // 以下略 }
シーンは、シーンを構成する各要素のコンポジションになる。 SceneDemo::Update() { player_.Update(*this); for_each(enemies.begin(), enemies.end(), boost::bind(&Enemy::Update, ::_1, boost::ref(*this)); // ヒット判定など } ヒット判定など、シーン更新時に必要になる処理は 1) シンプルならシーンの Update() 関数に直接書く (player_.Update() とかね) 2) ちょっと複雑になってきたら、Scene のプライベートメンバ関数に分割 3) もっと複雑なら、別クラスを用意して、そっちに処理を分ける とする。3 の例としては、たとえば敵とプレイヤーのヒット判定を行う (総当りではなく BSP とか使って) ような処理が考えられる。そうすると、SceneDemo はこんな感じ。 class SceneDemo { Player player_; std::list<Enemy*> enemies_; HitManager hitmgr_; void AddEnemy(const EnemyCreateInfo& info) { Enemy* enemy_ = Enemy::Create(info); enemies.push_back(enemy); hitmgr_.add(enemy); } public: void Update(); };
自分も
>>748 の書き方で必要十分だと思う。支持しますわ
>>696 1) ぜんぜんベツモノなら別クラスにして、シーン側からもまったく別扱い
2) 外から見た振る舞いは同じ (public メンバ関数は同じ) だが中身がぜんぜん違うなら
純粋仮想関数を定義した共通の基底クラスを用意して、それを継承して作る。シーン側からは
基底クラスを介してしか見ない。
3) 中身もほとんど同じでパラメタぐらいの違いから、単一のクラス。パラメタ部分だけスクリプトか
設定ファイルに切り出す
>>748 当たり判定クラスは、その中の1)に入るのかな。
>>738 それは
>>643 によれば外部DSLだよな
内部DSLを使うべきだと言っていた人とは別人か?
SAFE_RELEASEマクロとかが内部DSLだね。DSLって便利だね!!
うわw 確かにそうだけど
それだと怪しいマクロまみれの
>>510 も内部DSLだしw
おれイヤだよ21世紀にもなってそんなパラダイムw
DSLは資料読む限り現実路線に見えるんだけど、
アランケイ教の頃のOOPと同じでなんか信者がうさんくさいw
757 :
名前は開発中のものです。 :2009/02/16(月) 07:27:13 ID:lrLQRr8L
さて、今週はタスク信者をどうボコボコにしてやろうか
758 :
名前は開発中のものです。 :2009/02/16(月) 07:41:29 ID:lrLQRr8L
今回も新ワード出して定義論争に持っていこうとしているがそれが通用したのは前時代まで 今は説明できなきゃただの詐欺師 新ワード出てきても論争なれてないやつは触るなよ こういう無駄な勝負は何もにちゃんだけじゃねーぞ 会社でもそういう霞ヶ関風味の腐った人間ってのはたくさんいる ちゃんとしたメルヘンブレイカーにまかせないと負けるぞ ではこのスレの主旨をもう一度 で?タスクシステムのメリットって何?
>>748 乙。
もう750超えたのか。誰かpart1-4をまとめてくれないかな。
また次スレで不毛なループが発生するのが面倒だ。
>>510 や
>>641 、その他の住人が書いてくれたコードも残しておきたい。
俺はやらんが、誰かやってくれ。
タスクって分岐を関数アドレス指定にすることで処理を稼ぐテクニックのことじゃないの?
>>760 処理を稼ぐって何だよ。実行バイナリの容量削減?処理速度の向上?
どっちにしろ現代のPCでは全くの無駄な努力どころかむしろ余計なお世話だけどな
関数アドレスのLUTを使うことで条件分岐を高速化できるに違いない こういう固定観念に縛られたオールドタイプが若者をカルトへ誘う
おじいちゃん「私たちが20台の頃はね、たった1つのswitch文をケチる時代だったんじゃよ」
ボトルネックじゃないところで頑張っても誤差の範囲。 つーか、switch文でテーブルジャンプ利かせるほうが関数ポインタより速いと思うが。
だからもうタスクシステムなんて誰も使ってねーよ
766 :
名前は開発中のものです。 :2009/02/16(月) 18:15:54 ID:lrLQRr8L
駄目だな 十年は次スレが立たないぐらい タスク信者ども、ボコボコにしてやろ
俺主観での今までのまとめ Q.タスクシステムのメリットとデメリットを教えてください A.ハハン、自分で考えろ Q.タスクシステムの代わりがないだろ、文句言うなら代わりをよこせ A.コルーチン、DSL、各種フレームワーク Q.あーあー見えない聞こえなーい タスクシステムとは、ジョブコンを無駄にいじって 何がなんだかよくわからなくなったものではないかという説 タスクシステムは3Dの描画についてはまったく使い物にならないようだ 全角英数使うなこのバカやろう
>>760 >処理を稼ぎたい
君は
>>420 かな?
>>2 はジョブエントリのリストを舐めて、関数アドレスを使って処理を次々にディスパッチしていく仕組み
つまりバッチ処理の仕組みでしかないわけだが、この仕組みをどのような処理群に適用しているのか
教えてほしい
検索してメリットを探したけど サイトごとに違っているから困る 全部を信じるならば、万能フレームワークという結論になった 弱点なんてないぜ、トレードオフなんて知ったことじゃないぜ 銀の弾丸を見つけたよ
タスクシステムって車で言うと、MT車に当たると思うんだ。
MT車は車の運転を楽しみたい人、スポーツ感を味わいたい人用のもの。
同じように、タスクシステムもプログラミングを楽しみたい人、スポーツ感を味わいたい人用のものだとおもう。
初心者用MT操作説明サイトが有っても良いように、
>>2 みたいな初心者用タスクシステム説明サイトが有っても良いと思う。
それに対して文句を言うのは、
今日日F1でもパドルシフトなのにMTってなにか意味あるの?とか、
家やホテルがあるのにわざわざキャンプするのってなにか意味あるの?とか、
ロープーウェイがあるのに登山するのってなにか意味あるの?とか、
買ったほうが安いのになんでDIYするの?とか、
言ってるのと同じで、何も分かってないのに分かったふりしたがる、大人ぶりたい子供のすること。
タスクシステムは大人のスポーツなんだから、ガキがごちゃごちゃいうなよ。
771 :
名前は開発中のものです。 :2009/02/16(月) 21:27:46 ID:GBQgPfdG
>HSPではDSL用のコンパイラを書きにくい。 >HSPでやり始めると、言語としてHSPしか使えない。 外部的にはその通りで 内部的にはDSLをHSPのコードに変換するという手がある プリプロセッサ的な解決方法、マクロと言うのだろうか
乞食は食べることに必死だから、食えるときに食わないのはバカだという、 一方人間様は食べることに必死じゃないから、平気でダイエットしたりもする。 もう、立場がそれぐらい違うわけ。 多くの人にとってプログラミングってのは、単に趣味や遊びでしかなく、 数独やジグソーパズルと同じ感覚。 むしろそんな低俗なことで飯食ってる人が居るのが信じられない、何でそんなに必死なのかも分からない。 プロ野球選手が草野球をやってる人をつべこべ批判してたら、それって痛いだろ。 そういうこと。言われたほうは内心では「野球しか出来ないくせに」と思ってる。
>>770 残念だがタスクシステムは燃費最悪のダンボールカー。トラバントみたいなものだ
工作精度の低い2stエンジンで環境に全く優しくなく、煙モーモーあげる癖にスピード全く出ない
しかし走行音が激しいため、物凄く頑張ってくれてるような錯覚を覚える
手作り感抜群で品質は不安定。製造年月日が新しければ新しいほど品質が悪くなる
大半は車体強度不足で安全基準を全く満たしていない。事故るとよく燃える
あらゆる点がタスクシステムと符合している。「通」気取りにしかオススメできないゴミだ
現代社会でタスクシステムを使うというのは、現代社会でトラバントを使うようなものだ
公衆の前でタスクシステム凄いと叫ぶのは、高速の追越車線をトラバントで走る俺凄い!と同じだ
レトロ趣味の変態オヤジの愛車ノロケ話に付き合うと大渋滞が発生する
縁日に屋台でワイワイ射的をやってたら、 知らない猟師のおじちゃんが、撃ち方にケチをつけてきた。 そんな構図。
例えば、タスクシステムとやらで弾幕3DSTGの全OBJの1タイムステップ分の時間発展を計算するとしよう
…⇔[ザコ敵A]⇔[通常弾]⇔[閃光(粒子)]⇔[通常弾]⇔[通常弾]⇔[閃光(粒子)]⇔[ザコ敵B]⇔…
あるタイムステップではこういうちゃんこ鍋循環リストをペロペロシコシコナメナメすることになるね
何故このちゃんこリストはOBJの種類別でソートされてないのかって?そりゃ3Dゲーだからさ
>>2 のちゃんこリストはOBJの種類でソートされてるように見えるが実は深度ソートなんだね
そもそもスプライト機ではOBJの重ね合わせがOAM内での並び順によって決定されていた
典型的なちゃんこリストはOAM内の属性配列にpush_backする順序でソートされた
典型的な2DSTGでは重ね順(深度)=OBJの種類だった、というわけだね
さて、上のちゃんこの並び順でいくと、ザコ敵Aの処理が終わったら次は通常弾だ
サブルーチンアドレスを使って処理を呼び、『Δtの等速直線移動を計算』し、処理を返した
通常弾の処理が終わったら次は閃光だ。これもほぼ同様の手続きで処理
閃光の処理が終わったら次は通常弾だ。これもほぼ同様の手続きで処理
こうなるわけ
『Δtの等速直線移動を計算』。たったこれだけの処理をするために
>>2 の仕組みを使う。WHY?
これが処理速度を稼ぐための行為だというなら、鎖国中の独裁国家のファンタジーみたいなものだ
>>774 HSPer(俺)が縁日に屋台でワイワイ射的をやってたら、
自称猟師のおじちゃん(=タスクシステマー)が現れ、撃ち方にケチを付けてきた
そんな構図
>>773 >工作精度の低い2stエンジンで環境に全く優しくなく、煙モーモーあげる癖にスピード全く出ない
>しかし走行音が激しいため、物凄く頑張ってくれてるような錯覚を覚える
>手作り感抜群で品質は不安定。
要するにDIYってことだろ。
日曜大工のなにが悪い。手作りでなにがわるい。あくまで趣味なわけ。
本職ではちゃんと社会のお役に立ってる。
むしろゲームなんて役にたたないのだから好き勝手で良いだろ。
ダンボールカーで公道を走るわけではない、庭を走るだけだ。
あえて合理的でないタスクシステムを使うことによって、 余裕を見せ付けていると言ってもいい。 秋の紅葉を写生しながら楽しむ。写真で良くね?じゃない。もう時間の使い方が全然違うわけ。 まさに貧乏暇なし。
好みの問題ってレベルじゃないからここでデバッグ/アンチウィルス作業してるんだ。 信者の洗脳を解こうと頑張ってるんだよ。 本職でこれをやられると時間と金の無駄だから非常に迷惑。 日本経済が傾いてる時に、こんなアホなことを現場でやられたんじゃ困る。 本職じゃないならいいよ。
>758 ハナから理解する気の無いバカに説明する暇人も、そう残ってないだろ。
>本職でこれをやられると時間と金の無駄だから非常に迷惑。 >日本経済が傾いてる時に、こんなアホなことを現場でやられたんじゃ困る。 本職の人は困るだろうね。本職以外の人にとっては、 金儲けしなければならない立場であるにもかかわらず、 タスクシステムなんて使っちゃうような低脳の集まりの業界の未来なんて 知ったこっちゃないしな。まさに滅ぶべくして滅んでるだけだし。 そもそも、ゲームなんて社会の役にたたないんだから、そんなもので飯食おうと思うほうがどうかしてる。 社会の役にたたないってことは、それは趣味ってことだ。普通ならそう考える。たとえそこに市場があったとしてもな。
>775 > あるタイムステップではこういうちゃんこ鍋循環リストをペロペロシコシコナメナメすることになるね 相変わらずリスト一つで管理してるつもりになってる構ってチャンかw > 典型的な2DSTGでは重ね順(深度)=OBJの種類だった、というわけだね うわぁ…w > 『Δtの等速直線移動を計算』。たったこれだけの処理 うわぁ…www
>>777 歴史と記憶の捏造が始まった?
タスクシステムを褒め称えてきた自称プロ達の行ないを矮小化&無毒化&美化しちゃダメだよ
2003年以降、
>>2 はプロのスーパーテクとか言って本気で広めてた自称プロ、沢山いたね?
自分に都合の悪いことを全部無かったことにしちゃねー
HSPerは配列厨なんだけど、タスクシステマーに「プギャー。知らないの?」されたことあるよ
それまでフリゲや同人でちょこちょこ出してきたけど、こういう日曜大工にタスクシステム(
>>2 )
なんて使った試しない。マジこのオッサン死ねばいいのにって思った。リア厨だから仕方ないね
ちょっと前のコミケで売った弾幕STGはタスクシステマーが見たら怒り狂うような簡素なコードだったよ
>>778 君、タスクシステム派にとって物凄く迷惑な、無能な味方なんじゃない?
なんで趣味でしか通用しない玩具ですって認めちゃうの?
アンチじゃないの君?
ID:Bs7zALYvってもしかして リアル金持ちはリボを使う。リボはリアル金持ちのステータス。一括払いを使う奴は貧乏人 とかいう超理論を展開していた某板の住人さんかしら?
>タスクシステムを褒め称えてきた自称プロ達の行ないを矮小化&無毒化&美化しちゃダメだよ
>2003年以降、
>>2 はプロのスーパーテクとか言って本気で広めてた自称プロ、沢山いたね?
>自分に都合の悪いことを全部無かったことにしちゃね
その自称プロはよっぽどの低脳なんだから放っておけばよい。
「プロのスーパーテク」なんてのは、厨を釣るための餌だよ。
プロとかスーパーとかテクとか、針みえすぎ。
なんちゃらProって名前のついてる商品が一杯あるだろ。あれと一緒だよ。
実際にはプロはあんなもの使わない。
>コミケで売った弾幕STGは
売り物にタスクシステムを使わないのは当たり前。
>>788 針じゃないよ。何なら過去ログ、Cマガのタスクシステム特集記事でも読めばいいよ
自分だけはまともな、良識的なタスク派だとか言ったって信じないよ
ギャラクシアン起源の由緒正しいプロテクです、使わないとカッコワルイ!とか叫んで
広めるような毒虫共に利用されるイタタタシステムなら、悪いけど名前ごと抹殺されたほうが世のため
厨房的にはそういう発想に至る。汚物は消毒したいお年頃だから仕方ないね
さて、あえて合理的でないリボ払いを使うことによって、
(金利払いをする)余裕を見せ付けていると言ってもいい。
秋の紅葉を写生しながら楽しむ。写真で良くね?じゃない。もう時間の使い方が全然違うわけ。
まさに貧乏暇なし。
yahoo知恵袋
http://etail.chiebukuro.yahoo.co.jp/qa/question_detail/q113605506 リアル金持ちだからできる、余裕の金利払いだそうです。ID:Bs7zALYvと馬が合いそうだね
>785 自分の間違いに、本気で全然気づいてないのか?
>>790 間違いだと言い切れる根拠をお願いします
まさか、あなたは究極の狭義の正しいタスクシステムをご存知の方ですか?
ぜひご教示ください。私の認識はきっと間違っているのでしょう
>>789 「プロのスーパーテク」なんて言葉が釣りじゃなきゃ一体なんだって言うんだろう。
この世に真顔でこんな言葉使うやつがいるとでも?
ライターに騙されたやつは本気だっただろうけどな。
ライターってのは読者の精神年齢に合わせて記事書くからな。
あとさ、リボ払いの件だけど、なに言ってるのか意味が分からない。
無駄なことに金をつかうのは単に成金趣味なだけ。
無駄なことに時間をつかうのが余裕のある人。
ただし、利害関係が出てくると仕事モードになって目の色が変わるが。
>791 その変り身、キモイw 煽っといて今更何言っちゃってんのwww
>>792 何きみ?誰を擁護してんの?ありえなくね?何故タスクシステムの名誉に固執するの?
誰かを演じてるの?松浦乙とか言ってほしいの?だったらコテ付ければ?
HSPerの厨房の俺でもアンタが何を守ろうとしてるのか全く分からない
利害関係が出てきたから仕事モードになって目の色が変わってるんじゃない?
でないとタスクシステムを必死に庇おうとするアンタの行動は理解できない
俺の行動原理は簡単。厨房だから。配列最高。タスクシステムなんてゴミ
こんな無様(
>>2 )なものが未だに持てはやされてるのは見るに耐えない
ガソリンぶっかけて信者も道連れにして全部燃やして墓標でも立てとけばいい
それがタスクシステムへのせめてもの供養になるだろう
>毒虫共に利用されるイタタタシステムなら、悪いけど名前ごと抹殺されたほうが世のため う〜ん、基本的にずれてるんだよなぁ。 そもそも、ゲーム自体が「抹殺されたほうが世のため」なわけで。 そういう、どうでもよい役にたたないものを暇つぶしで作るんだから、 タスクシステムはむしろ最適ともいえる。
>>793 ねーねー、HSPerにナメられるってどんな気分?教えてくんない?
君ってさ、C++は亀千人の甲羅だとか言う話を勘違いして解釈して
C++10数年使ってる俺ってストイックカッコヨスゲェとか考えちゃう
>>746 みたいな人と同類なの?
だったらこの状況って死にたいほどの屈辱なんじゃない?
>>795 >そもそも、ゲーム自体が「抹殺されたほうが世のため」なわけで。
何言ってるの?優等生発言する俺かっこいい状態なの?
>そういう、どうでもよい役にたたないものを暇つぶしで作るんだから、
>タスクシステムはむしろ最適ともいえる。
あー、もしかしてお前、ゲーム完成させたことないけど
ゲーム作ってる俺すげぇクリエイターな俺すげぇ状態を楽しむ人?
そういう趣味は否定しないぜ?
そういや前々スレでタスク擁護派の一人が「ゲーム作ったことない」って口滑らせてたね
ゲーム作れないし勿論完成させたことないけどタスクシステム擁護する俺かっけー状態
を楽しむ趣味もあっていいんじゃない?
>>794 俺は誰の見方でもないよ。お前らの脳みそがバグってるから直してあげてるだけ。
時間を無駄に使ってな。
>俺の行動原理は簡単。厨房だから。配列最高。タスクシステムなんてゴミ
どうしてゲーム自体はゴミだと考えない?最高に役にたたないのに。
ゲームは良くてタスクシステムはダメって理屈が分からない。
普通に考えれば、どっちも同じぐらいどうでも良いことなのに。
>>797 「抹殺されたほうが世のため」云々って先に言い出したのはお前だろ。
俺はお前の程度に合わせただけだ。
>796 やっぱり煽りしか出来ないのかw 自分で調べるとか出来ないゆとり?
横槍ですまんが、人格批判は関心しない 非タスク派もタスク派もしっかり討論していって論破してやってくれ
>2とか松浦とかCマガとか見て「タスクシステムってサイコー♪」とか「タスクシステムなんかクソだ」とか 真顔で言ってるバカって、ホントに救いようが無いねw
>>798 >どうしてゲーム自体はゴミだと考えない?最高に役にたたないのに。
おもんなかったれす。おもろかったれす。そういう感想文をもらえて俺もたのしい。シンプル
娯楽を否定するなら共産国家に行けばいい。すぐ隣にあるでしょ?早くいきなよ
>ゲームは良くてタスクシステムはダメって理屈が分からない。
ゲームは誰が楽しむものなの?プレイヤーが楽しんでくれるんだよ
タスクシステムは誰が楽しむものなの?自分自身が楽しむんだよ
後者は合理性に欠けた単なるオナニー。自室に篭ってやってりゃいい
「愛しいしと、俺のタスクシステム、まじすげぇ。。。ハァハァ。。。シコシコ。。すっげぇテクニシャン。。。ウッ」
公開オナニーほど不快なものはない
どうでもいい2chで どうでもいいゲームについて どうでもいいタスクシステムについて どうでもいい奴と どうでもいい議論をして どうでもいい時間をすごしてるくせに、 タスクシステムだけは受け入れられないってのは意固地だ。 効率を求めるならゲームなんて作らなければ良い。 もともとゲームってそういうものだろ。
>おもんなかったれす。おもろかったれす。そういう感想文をもらえて俺もたのしい。シンプル >娯楽を否定するなら共産国家に行けばいい。すぐ隣にあるでしょ?早くいきなよ タスクシステムという娯楽を否定しているのはお前のほうだろ。 おれはゲームは趣味なんだから好きにやればよいと言っている。
>803 > 公開オナニーほど不快なものはない 自虐? ここ、嘲うところ? wwwww
タスクシステムがオナニーだと気づいても、 ゲーム製作がオナニーだとは気づかない脳みそ。救いようがないな。
あの、、、仕事でゲーム製作することもありますよ……
>>805 >タスクシステムという娯楽を否定しているのはお前のほうだろ。
目障りにならない程度に隅っこでウジウジやってる分には否定しないよ
エラッソーにプロ気取りがタスクシステムタスクシステムとか叫んでりゃ
ぶっ潰したくなるさ。HSPerが偉そうにしてると叩かれるだろ?同じこと
お前は糞ゲーを叩くなって言ってる似非平等主義者、共産主義者と同じ
糞プログラムを叩くなって?ないないないない
>809 自分が理解できないものは破壊したくなる。 ガキの衝動ですかwww
>>807 いいえ。リア厨時代に作ったゲームが
フリゲスレで公開処刑になったこともあるけど俺は元気です
洗礼を受けて、甘んじてそれを受け入れて、改善して、また出して
そういう繰り返しがオナニーだというなら、あきらめるさ
あんたは、タスクシステムがそうした洗礼を受けることを嫌ってる
それが理解できない。気持ち悪い似非平等主義だよ
>>810 早く理解してない部分を指摘してみろよミジンコ
お前ら喧嘩はよくないぞー
>ID:EEKBitmg = ID:u/rbw6HO アンチタスクスレでも立ててそっちでやれば? EDだから、自分が代わりにスレ立てとはいかないけど。
悪かった いつもは紳士的厨房なんだけど今日はついカッとなっちゃった
『紳士的厨房』って言葉は、存在してもいいものなんだろうか? なんか矛盾。言葉遣いは丁寧で、でも思考は厨房ってことなのかな? ま、それはそれとして、今までに『アンチタスクスレ』みたいなものって立ったことあるの? part4から見始めてpart3の過去ログ読んで、その頃からずっとアンチ派vsそれなりに受け入れ派で やり合ってるみたいだけど。
ここがタスク派とアンチタスク派の遊び場だってことを知らないなんて… ひどくない?追い詰められると出て行けって。それはないと思う だったらタスクシステムの楽園スレを作ればいいと思う。殴りこむけど
HSP使いのクルクルパーが吠えてると聞いて
俺はHSP使いがタスク論争に来るなんてすごく度胸があると思うんだが 本当に居たら絶対話に付いていけないと思うもん
HSPみたいなクソ言語では、 「いわゆるタスク」みたいな処理ってそもそもできないんじゃねーの?
HSPにも関数のポインタ相当のものが有れば作れるのかな? っと思ってちょっと調べてみたけど、ぱっと見では無いようですね〜
HSPerは何も分かってない。 ゲームってのは、一般的にそんな切磋琢磨する分野じゃないんだよ。 そういう熱いエネルギーは皆の役にたつもっと有効な分野に使えばよい。 ま、それが出来ないからゲームごときで吼えるんだろうけど。 クソゲー結構。糞プログラム結構じゃないか。息抜きで作ってるのにカリカリするのは嫌だ。 業界人的にも、使える奴と使えない奴の見分けがついて好都合じゃないか。 タスカーは泳がせておけばよい。本当のことを教えてあげる必要はない。競争だからな。
いや、HSPは構造体ないから・・・・
え、HSPには構造体が無いだと! それはちょっと驚きだわ ゲーム作るのに構造体って無いとすげえ不便(というか作るの無理)だと思うんだが あー。ちょっと遊びでDLしかけたけど止めますわ
ちょっと見てみたけど、 関数ポインタやクロージャの類もやはりなさげ。 HSPでタスク不可能だろ。 しかし、なんでHSPerがなんでこんなに必死にタスクを否定するんだろか? 実装不可能なんじゃ、良し悪しがわかるはずもないだろ。
HSPってCやポインタが理解できないレベルの人でもゲーム作りに 参加できるからゲーム作成の裾野を広げる意味で有意義な言語だと思ってたけど あんまり敷居が低くなると弊害も出てくるんだな…
リア厨時代に2chがあるって事は相当若い方なんだろうかねぇ 中学の頃はPC88で5インチFDだった俺の時代と考え方が異なるのも仕方が無いわ
タスクシステムなんてただの道具、使いたきゃ使えばいいだけだし、 他に便利な道具があれば使わなければいいだけ。 なんでアンチタスク派なんて存在するのか不思議だったけど そもそもタスクシステム自体を使えない環境ってのがあったわけね。 すっぱい葡萄というやつか。
俺は若いうちこそC/C++だと思うんだ HSPで才能の伸びを制限してしまうよりは、 Cで苦しんでポインタで躓いて、C++のOOPで悩んで、 Win32APIやDirectXや3D計算や物理学などを勉強して、 一人前のゲームプログラマになっていってほしい
なんか問題のHSP使いはコンプレックスの固まりって感じがするわ
コンプレックス感じる必要なんてないんだぜ?みんな同じ道を歩んできたんだから
>>830 いや、HSPで先にプログラムの楽しさを覚えた方がよくね?
10代くらいの若い頃にCみたいなひたすら挫折する言語をやるのは賛成できんなー
昔のBASIC使いがやりこむと自然とアセンブリに手を出したように、
HSP使いもやりこむと自然にC++やJava、Rubyなんかへ手を出すと思う
つか、自分だって昔はベーマガとかプロポシェとか読んでただろ、このオッサンどもw
HSPerとか言ってる人はネタでしょ 語彙がメインフレームっぽい…… かなりのオッサンだと思う
>>827 >>829 >>830 んー、HSパーは前スレの
>>174 なんだけど、あれどう思う?質問ある?
なんでHエスパーは他の言語が使えないって思い込んじゃうんだろう。そう思い込みたいのかな?
拡張プラグインを使えばHSPスクリプトで書いたユーザー定義命令(サブルーチン)のポインタを取得できる
自作の拡張プラグインからHSPスクリプトを呼び出せる。つまりHSPスクリプトのコールバック関数が作れる
俺は衝突イベントでHSPスクリプトを呼び出してる。何がどんだけの速度で自分に当たったか、が入力
ゲーム固有の処理、体力を減らす、増やす、モーション切り替え(倒れる、死ぬ、復活、etc)等の結果が出力
自作の拡張プラグインはIrrlichtとBulletライブラリの機能をHSPで利用するための橋渡し役
元々はE3D使ってたんだけど色々思うところあって自作することになってしまった。今でもE3Dは使ってる
HSPを酸っぱい葡萄だと思ってない?食わず嫌いは良くないよ。玉葱はいいよ
>>832 高専の指導教官から色々教わってるから
このスレで出てきたメインフレームのOSのこと聞いたら色々教えてくれた
あとインターフェース3月号やるから嫁って言われた。面白かった
あとSTGスレの
>>181 あたりも俺。何か質問あればどうぞ。返信は遅くなるけど
おまえは俺がHyperTalkerだった頃にそっくりだぜ! とりあえず、その自称はやめた方がよくね? 自意識過剰なLisperとかSmalltalkerみたいで将来きっとこっぱずかしくなると思うんだが 普通にHSPプログラマでいいじゃん
HSPプッギャーとか言いそうなタスカーが反応しやすいように わざと名乗ってるだけだから。いつもは大人しい良い子です
ざっと読んだ限りでは、タスクシステムより酷いような。 >俺は衝突イベントでHSPスクリプトを呼び出してる。何がどんだけの速度で自分に当たったか、が入力 >ゲーム固有の処理、体力を減らす、増やす、モーション切り替え(倒れる、死ぬ、復活、etc)等の結果が出力 >自作の拡張プラグインはIrrlichtとBulletライブラリの機能をHSPで利用するための橋渡し役 衝突イベントをHSPで処理する意味が分からない。Cでやっちゃダメなの?
>>838 それ元々はC/C++のゲームだったんだよね
HSP使いの友人がMOD作りたいっていうから
無理矢理HSPで処理を噛ませるようにした
>俺は衝突イベントでHSPスクリプトを呼び出してる。 とか書くから、いつもそうしてるのかと勘違いした。 でも、HSP使うメリットって一体何?
ああ、そういうことか。 わざと非合理的な方法でゲーム作ったことをアピールするためか。 結局タスカーといっしょじゃん。
>>841 作用に関する処理、イベント処理をスクリプトで記述できるようにするというのは
別に非合理ではないけどな
否定するには材料不足。勇み足
他人に記述してもらいやすいように工夫する必要、需要があるからそれを行う
これはごく自然なこと
カーゴカルトのタスク信者に欠如する行動動機が彼にはある。タスク信者とは明らかに異質。遥かに正常だ
程度の問題で、中道と思ってる人から見ればどっちもカルト。
CもHSPも同じ手続き型言語なんだから、Cより機能の劣るHSPのほうが使いやすいってことはないだろ。 マクロ一つとっても、Cの方が柔軟性あるから、スクリプト書くにしてもHSP使うぐらいならC使うだろうなぁ、普通は。
>ぶっ潰したくなるさ。HSPerが偉そうにしてると叩かれるだろ?同じこと って自分で言ってたくせに、 偉そうにしてて叩かれると、ムキになって反論するのかw
環境がWindowsしかないのなら別にHSPでもいいさ。好きにするがいい。 ただ残念なことにHSPは言語として認められているかといわれるとそこは疑問だ。 2年ぐらい前にうちの人事でHSPで作ったゲーム持ってきたヤツが居て笑いものにされていたのを思い出した。 いくらHSPで高度な事をやったとしても、業務では使えないよね。 HSP(笑)といわれてしまうのは仕方が無いぜ。 けどフレームワークがあって、組み込みスクリプトとしてHSPを使うのなら、俺は賛成派です。 最も底辺なスクリプターのレベルに合わせてやれるし、マニュアルも豊富だしね。 個人で複数人でのゲーム製作なら有意な選択肢だと思う。業務ならLuaやSquirrel使うだろうけどな。
>>846 そうそう。少しでも関数にたどり着くオーバーヘッドを少なくしようとすると、タスクが必要な時代があったんだよ。
太古のコンパイラはswitchがジャンプテーブルを生成してくれないもんだから、switch分岐がタブーとされていた。
条件分岐の多いゲームにおいて苦し紛れに出て来た呪われた子がタスクシステムなんだよ。
今は、現場でも新人教育の場でもタスクシステムなんて言葉は出てこない。
(携帯畑は知らないが、据え置きの設計でタスク使ってるのは見たことがない)
シーン管理やイベント管理がボトルネックになる箇所では無い時代になってもなお、
タスクシステムを”プロの技法”として讃えるのはいささか疑問があるでしょうね。
で、執筆者もそれを分かっていてタスクが古い技法であることを明記している場合がほとんどだとおもうぜ。
850 :
名前は開発中のものです。 :2009/02/17(火) 10:29:08 ID:5AsmfnlE
で、実際に速度計ったらタスクシステムの方が速いっていう
もちろんタスクと非タスクだとタスクの方が速いだろうさ。ただ誤差の範囲でしかない。 他にネックな箇所はいくらでもある。 その誤差レベルの高速化の為に人員を費やし、バグの温床を作るのであれば、 タスクを選択しないという時代になったわけよ。
>>848 最底辺に合わせるのなら、パラメーターだけでやった方が良くない?
teki *akaiteki = new teki(0xFFFF0000);
teki *kuroiteki = new teki(0xFF000000);
スクリプトっていっても、Luaなんて汎用的すぎてCと変わらないと思うんだよなぁ。
マップとかもテキストエディタで編集できるのがクールでいいね。
例)横スクロールのマップ
? @@@@@@@@@
@@@@@@@
vv *
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
これだって言語の一種だし。
いや、タスクシステムが速いとか言ってる人居るけど、明らかに遅いよ。 動的関数呼び出しが速い訳ないじゃん。 switchがどうとか言ってる人も居るけど、ごった煮リスト使わないならそもそも分岐すらいらないし。 for(int i=0; i<size; ++i) { array[i].x += 1; } for(int i=0; i<size; ++i) { array[i]->update(); //←これ仮想関数ね } どっちが速いかなんて考えるまでもない。
ああ、swtichをあくまでシーン冒頭から呼び出し限定して考えていたけど、 シーンを階層化すれば無駄なswitchも減らすことも0にすることもできるよね タスク分割を仮想関数を呼びまくるレベルまで細かくしたのなら重いだろうね いくらタスク使う場合も関数はそこまで細かくしないと思いますぜ
細かく出来ないなら、タスクシステムなんて意味なくない? タスクシステム使っといて、 シューティングの弾幕は数が多いからタスクシステムで管理せず配列で、とかありえないだろ。 何のためのタスクシステムなのか意味が分からん。 それにタスクの数が少なくても、2重ループすれば2乗、3重ループすれば3条だよ。 え、2重ループなんて使わないって?ヒント:当り判定
>>852 最終的な外部データの形としてはパラメータだけ置換させる程度の留めるのが理想だわな〜
(底辺のラインがどの程度か難しいが)Luaも結局のところCと同じぐらい複雑ではあるのは確かですね。
デザイナーが容易に扱えるようにスクリプト化しても、
結局はプログラマしか理解できていない/弄れないってのは本末転倒だよね。と反省している。
だから過去の遺産だよ。 仮想関数なんていう高級な仕様は存在せず、 C++がコンソールで使えない時代で、CもしくはASMで書いてた話なんだって。 速度を稼ぐためには仕方が無かったんだ。分かってくれ。
HSPしか使えないクルクルパーはどこ行った?
859 :
名前は開発中のものです。 :2009/02/17(火) 16:51:29 ID:5iQxaPu6
860 :
名前は開発中のものです。 :2009/02/17(火) 18:07:11 ID:dYjC/tB6
まさかタスクシステムを使う理由が速度とは恐れいった(笑)
861 :
名前は開発中のものです。 :2009/02/17(火) 18:38:49 ID:rv15b0x5
素のHSPとCを比べればHSPの方がDSLに近いよ HSPでウィンドウに文字を出すなら mes "hello world" Cで同じようなコードを書くなら MES("hello world"); でもさ、Cの場合は前準備がものすごく必要になるだろ それだけ前準備してやっとHSPと同じ条件になる バカらしくないの? 確かにCの方が言語として多機能だろうけど 使わない機能なら、存在していないのと同じこと 一つの手段にこだわりすぎて、他の手段が見えてないのは ちょっと視野が狭すぎる 一年間ぐらい便所に引きこもってうんこでもしながら考えてみる事をお勧めする
862 :
名前は開発中のものです。 :2009/02/17(火) 18:59:10 ID:dYjC/tB6
そんな恥ずかしいの使うぐらいならFLASHのアクションスクリプト使う
863 :
名前は開発中のものです。 :2009/02/17(火) 19:20:26 ID:rv15b0x5
言語をブランドだと考えるスイーツ脳には 俺の思想など理解できまい おまえら雑魚が言語にこだわって時間を浪費している間 俺はゆっくりと十分に睡眠を取るだけだ
HSPしかできない奴がえらそーに言うのはやめたほうが…
引数君(スレ主)に説明責任君 510のソースすら読めない自称プログラマのアンチタスク君 同人ゲーしか作ったことがないのに自信満々にタスクシステムを否定する奴とか 3万行ぐらいのソースしか書いたことがないくせにプロきどりの奴とか 最後に極めつけはクルクルパーのHSP使いか このスレ、本当にネタに困らないな 頭のおかしい奴、大集合だ この分ならまだ3スレぐらい行けそうだな
HSPのお勧めゲームの動画なり紹介してみ。 話はそれからだ。 全く期待してないけどな。色んな意味で。
俺の言っていることは全て反論の余地がないから 反論できなくなって主観で罵倒する程度しか手がないのだろ そして、相手に情報を出させて揚げ足取りを狙うだけ それらも俺にあっさりと見抜かれる 愚かである、そして哀れである なんなら怒ったふりでもしてやろうか わはは
なんでゲームの動画をみる必要があるんだよ 何を作るかじゃなくてどう作るかがここの話題じゃないのか
HSPとやらのパフォーマンス見るには、 成果を見るのが一番手っ取り早いだろうが。 いいんだよ別に。初めっからミジンコも期待してなかったから。
HSPとCだと言語レベルではそんなに変わりないって。 構造体が使えないぶんHSPの方が使いにくい。 DSLっていったら、マップデータとか、iniファイルとか、そのレベルで初めて効果が出てくるわけで、 HSPですら豪華すぎる。
iniファイル→設定 マップデータ→マップ Xファイル→メッシュ png→画像 mp3→音 C→メイン HSP→?
>853 その比較に意味があるのかどうか、聞いてみたいところだ。 array[i].x+=1といった固定の処理しかしないなら確かに速いのだろうが、現実的にはそれだけで 済まないだろ。 >855 いまどき実直に二重ループで当たり判定するのは、素人でもありえない様な気がするが…。
>ドメイン特化言語(DSL:Domain Specific Language)とは、 ある特定の種類の問題に特化したコンピュータ言語のこと。 ではHSPは一体どの特定の種類の問題に特化してるっていうの? ゲーム?構造体も無いのに? HSPは総合的にみれば厨問題に特化した言語で間違いない。
>>873 現実には、クラスごとにarrayを用意するから問題ない。処理固定で良い。
876 :
869 :2009/02/17(火) 22:32:25 ID:w3hFLKWn
>>870 パフォーマンスは多義語だから何を指しているかわからないけど
生産効率とか実行効率を指しているなら上げられている動画を
みるだけじゃわからなくね?
ちなみにIDでわかると思うけどHSP使いの人ではない、ただの横槍
>875 まぁ、PCでメモリが潤沢にあればそれでもいいかもね。
>>876 何にしろ、ぱっと見、すごかったら興味が湧かね?
まずは興味じゃね。
HSPの人はついにC言語批判に入ったか。ある意味すげえな。 使わない機能ってほとんど無いだろ? みんなCじゃ足りないからC++/STL/Boostまで使ってますよ。 Windows環境でゲームに特化した言語であるHSPの方が記述量が減るのは正しいよ。 ウィンドウにたった1行表示させるだけでも、ウィンドウクラス登録->ウィンドウ生成->メッセージ処理->HDC取得->描画 と手間だらけだわな。 HSPでたった1行で書けるのは50行にもなってしまうのを悲観するのも分からんでもない。 でも、MFCやWTL使えばその労力も減るでしょ。 ライブラリのほとんどはCを基準に作ってあり、積み重ねられてきた言語としての拡張性が雲泥の差だよ。
>ではHSPは一体どの特定の種類の問題に特化してるっていうの? >ゲーム?構造体も無いのに? >HSPは総合的にみれば厨問題に特化した言語で間違いない。 DSLのことについて何も知らないだろ、マクロも知らないバカは黙ってろ >HSPの人はついにC言語批判に入ったか。ある意味すげえな。 Cを批判した覚えはない、DSLの説明を補足しただけだ >みんなCじゃ足りないからC++/STL/Boostまで使ってますよ。 君は視野が狭いね 俺はあらゆる言語と、あらゆるツール それ以外のことまで視野に入れて考えますよ 言語とライブラリの使用方法だけ考えていればいいなんて楽ですね 何も考えなくていいから
HSPしか知らないクルクルパーが吠えてやがんのな こんな、このクルクルパーと遊んでやれ あと3スレぐらい、このクルクルパーで引っ張れそうだ
DSLとマクロ、と言われるとLispですかと思ってしまう cppぐらいだと、正直あんま妙ちきりんなマクロはヤメテと言いたい Cのマクロの珍妙技のっけたような本、昔は出てたと思うけど 今はネタ扱いでない?
>880 > 俺はあらゆる言語と、あらゆるツール > それ以外のことまで視野に入れて考えますよ ガンバレ(棒 キミはやれば出来る子だ(棒
あらゆる言語とあらゆるツールを視野に入れた結論がHSPかよw HSPクンはDSLの定義を何か勘違いしてると思うよ。 調べなおそうねw
>>841 うちの研究室は指導教官含めてHSP使いが多いから別に非合理的じゃない
実験装置の制御にもHSPを使ってたりする
HSP⇔拡張プラグイン⇔デバイスドライバ⇔PCIバスの制御ボード⇔実験装置
計測終了、エラーで中断、などを写メで知らせてくれる
>DSLのことについて何も知らないだろ、マクロも知らないバカは黙ってろ CとHSPならCの方がマクロが強力だから、 DSL構築するならCの方が良いね。
>>886 それは、日本人は日本語を話す人が多いから、コンピュータ言語はひまわりが良い、
と言ってるようなものだぞ。
>>848 >けどフレームワークがあって、組み込みスクリプトとしてHSPを使うのなら、俺は賛成派です。
ありがとう
>>888 何を言ってるのか分からない
使う奴らの多数意見でHSPがいいっつー環境だからHSPを選択した
それだけのこと。ちなみに第2位はRuby。ツクラーも多いから
>>889 お前の研究室の台所事情なんて皆知らないし、聞きたくも無いわけ。
お前の研究室で何か物を作るという特定の種類の問題に特化したコンピュータ言語がHSPだったってだけだろ。
だから、
>>874 でも、HSPのことを、厨問題に特化した言語だって予め言っておいたんだ。
それに対するお前のレスがこれ
>>880
>>890 いや、それ別人なんすけど。。。
DSL?なにそれ?食べられるの?
ウンコきばって思考する詩人の発想なんて知らない
>>891 ちょっとまってくれ。ややこし。
HSP野郎は二人も居るのか?
>>891 用に書き換える。
お前の研究室で何か物を作るという特定の種類の問題に特化したコンピュータ言語がHSPだったってだけだろ。
HSPがゲームに適しているかどうかとは別問題。
ここはお前の研究室の台所事情について話し合うスレではない。
しかし、まさかHSP使いが二人も居るなんて。
コテ付けてくれなきゃ見分けがつかん。
>>892 つ
>>841 ↑これよく読んでもらえれば分かると思うのだが
>>841 は何をもって非合理といってるのか、その理由を書いていない
だから俺は、HSPを選択したことを非合理だと言ってるのかなーとESPし
とりあえず
>>886 のレスをした。それだけのこと
あと、IDコテ付けてるんで。よろしく
>>893 その前にお前なんでこのスレでHSPの主張をしてるん?
HSPのスレにいけよ
めちゃくちゃたくさんスレあるっぽいじゃん
まぁ過程はどうあれ、 >うちの研究室は指導教官含めてHSP使いが多いから別に非合理的じゃない は、裏を返せば、一般的にはHSP使いなんて少数派だから、 非合理的だと認めているようなものだというのは分かるよね。 別に数が多けりゃ正しいって議論をしたかった訳ではないのだが、 少数派みずから多数決を肯定するような議論展開をするなんてな。 そりゃもしこの世にHSP使いしか居ない状況だったら、ゲームもHSPで作るさ。 でもそんなガラパゴス諸島での経験を元に2chで議論展開されてもなぁ。 いやいや、研究室の皆も、HSPも使えるけど、CもC++も使えるんだ! それでも皆がHSPが良いっていったんだ!! っていうんなら、また話はややこしいが。
そもそもHSPはゲーム用ライブラリが標準でついてくるってだけで、 言語そのものを見比べた場合、Cに勝っている部分は無いよな。
>>895 >は、裏を返せば、一般的にはHSP使いなんて少数派だから
>別に数が多けりゃ正しいって議論をしたかった訳ではないのだが
>少数派みずから多数決を肯定するような議論展開をするなんてな。
>そりゃもしこの世にHSP使いしか居ない状況だったら、ゲームもHSPで作るさ。
>でもそんなガラパゴス諸島での経験を元に2chで議論展開されてもなぁ。
>
>いやいや、研究室の皆も、HSPも使えるけど、CもC++も使えるんだ!
>それでも皆がHSPが良いっていったんだ!!
>っていうんなら、また話はややこしいが。
(;・∀・)?
ID:EEKBitmgはHSPerだけど、HSPがゲームに適しているとは考えてない、ってことでよいの?
>898 さりげなく一文抜いて小細工して引用するなよ。
もうHSPはいいだろw HPSは安全バサミみたいなもんだ 切れ味いいし怪我しないし悪くないんだが お仕事でやってる大工のおじちゃんたちに 安全バサミを使え、良い工具だと認めろと言っても怒鳴られるだけ ちなみにタスクはあれだな。十徳ナイフ ごてごてして使いにくいからちゃんとしたナイフとかドライバーとか買えよ 付属のドライバーでネジ回すとか変なとこで頑張らなくていいんだよ今の時代
いまだにタスク信者な奴は
>>510 と
>>641 をちゃんと比較したのか?
それでも信者のままなら哀れを通り越してキモイな。
脳内の想像にしかない存在にキモいキモい言うバカw
>>904 クルクルパーはお前だろw
本当に
>>641 みたいにかけるコードを
>>510 にして喜んでるアフォなら
いままで何やって生きてきたのかと虚しくならないか?w
>>905 クルクルパーはお前。
>>667 がわからないとはお前こそ本当にプログラマか?
一行でもプログラム書けんのか?
>>906 はぁ?
で、やったことはfor文をマクロに変えただけみたいな
ウンコソース?プププwウケルーw
>>907 for文をマクロに変えただけのようにしか見えないとは
お前の目は潰れてんでねーの
>>908 でもソースみるとそれしか違いがないよね?w
>>910 そいつ馬鹿だから「明らか」とかアフォなこと言ってるけど
全然「明らか」じゃねーしw
実際はソースが物語ってるように
>>641 のがわかりやすい上に
誰でも理解できるから保守もしやすい
>>911 明らかじゃないと思うのはお前のプログラミング経験が浅いから。
クルクルパーはプログラミングする資格がない。
>>912 説明できないほうが悪いでしょ?
仮にも技術板なわけだし?
異論あるの?
>>914 なんで工数が増えるの?
なにで工数カウントしてんの?
とか
>>667 に出てきた単語そのものに疑問が尽きない
はっきりいって
>>667 は日本人ですらない可能性がある
>>915 はっきり言って667すら読めないお前は中国人だと思う。
今度は、667すら読めないキチガイアンチが登場か こりゃ、あと2、3スレは行けそうだな
>>917 ここは日本語教室じゃねーでな
金払って教えてもらって来いよ、この中国人風情が
920 :
名前は開発中のものです。 :2009/02/18(水) 17:16:15 ID:b7s8KJ/b
お前がidを変えられることはわかってんだよ
922 :
名前は開発中のものです。 :2009/02/18(水) 17:24:54 ID:b7s8KJ/b
で?工数はなんで増えるって?
667に書いてあるじゃん 馬鹿じゃねーの
924 :
名前は開発中のものです。 :2009/02/18(水) 17:30:30 ID:b7s8KJ/b
説明になってないでしょ
コードは
>>641 のがすくないよ
>>667 で指摘する問題がコード量からみた工数を上回ることを説明しろ
コードは510のほうが少ないだろ。本当、お前馬鹿だな。 タスクシステムの工数は0とみなすということは、そのコードは0とみなすわけだから。
>>925 ほうほう
んで、その比較に一体なんの意味が?w
プログラムを書いたことのない人が見て理解できるようなものこそ 理想的な可読性の高いプログラムだと思う よくわからないプログラムは書き換えたくない ここはアセンブラで書いた方が速いですよって人とは リポジトリを共有したくないです 俺が死にます
>>927 linusじゃないけど、べったりなコードしか読めない、書けない人が
プロジェクトに参加しても邪魔なだけ。
>>928 ダメ
どんな天才であろうが数には勝てない
>>929 参加させるにも最低限のレベルがあるだろ。
>>931 給料の高い奴なんてめったにいねぇし
常時おいておくコストがそもそも無駄
その辺にいるようなのを必要なときに必要な期間だけ
必要な人数を集めたほうが圧倒的に楽、コストも低い
超難解で凄腕PGしか理解できない
その辺のアフォを集めてきてもすぐに触れる
誰が見ても明らかだろう
まだわからないか?
わざわざ難解なコードを書くPGは末期
自分の保身のためにコードを書いてるやね○ら○みたいな奴
こうなったらもうPGなんてやめたほうがいい
>929 クズは何人集まってもクズだ。
>>932 > 自分の保身のためにコードを書いてるやね○ら○みたいな奴
彼はお前の10倍ぐらい年収がありそうだけどな
>>932 言っていることはわかる。
しかし、抽象的な話だが、一般論としてプログラムで実現できる効率性に限界はあるのかな。
プログラムで実現できる効率性の限界がたやすいものであれば、数には勝てないというのは正論だと思う。
ちょっとした複雑なプログラム作るにしても、短時間で堅牢な動作を実現するプログラマもいれば、
長時間かけてもグダグダなのしか作れないのもいるじゃん。
プログラムにより確保する作業補助ツールや、本体プログラムの設計や実装作業。
これらに効率性の上限はないと思う。
一方、素材生産も時間かかるけど、むしろこちらの方がセンスの差が現れやすい。
ところで一般論として、稼ぎが多いからといって、無差別に尊敬できるわけではない。
あくまで一般論。
一般論としてなら稼ぎが10倍あれば、10倍以上の能力があるということだと思うけどな。 あくまで一般論として。
一般論として、尊敬できる能力とそうでないものがある。 あくまで一般論。
稼ぎが多いから尊敬しろだなんて誰も言ってないけどな なんで勝手に、尊敬とすり替えるのか あんた、頭大丈夫?
939 :
510 :2009/02/18(水) 23:06:59 ID:Xkqn3VRg
510を書いたものだが、510については私に質問してくれ。 ちなみに私はタスク信者ではない。 それから510のキモは、forループをマクロにした部分にあるわけではなく、 各オブジェクトを何処からでも参照できるようにしたこと、 そのための画一的手法を提供したこと、 自動並列処理への余地を残したこと、 にある。 タスクシステム=DBという視点で見て、 ゲームにDBは必要か否かを議論するのが有効かと。
一般論さ。 気にすんな。
ちなみに510を書いたのはタスクシステム=DBということに気がついて欲しかったから。
>>941 DBのつもりなら、staticで値持つの勘弁してくれ。
DBがシステムに1つしか無いだなんていつの時代だ?
>>935 正直、俺はあまり差がでないって考えてる
仮に会社で仕事を割り振るときに
「お前、すごいから2倍ね」
って仕事わたされて本当に2倍できるか?って話
どんな天才でも、まず、不可能だと思う
すごいすごいいっても実際に比べてみるとその程度
それともう一つ
そもそも、実はプロジェクト全体からみて開発時間に
占めるお金の割合ってのがはっきりいってカスだから
そーユー部分に金かけてもしゃーないって理由がやっぱ大きいからね
ちょっと別の話題だけど
スクリプトも微妙でしょ?w
スクリプト作れて整備するほど優秀な人間1人飼うより
プログラムほどほど組める人間大量に雇っちゃってベタ貼りで美味くいくとしたら?
どっち?って結論としてはどっちでもよくない?w
>>943 せっかく510が来てるんだから、クルクルパーは引っ込んでな
>942 しょうがないだろう。 このスレにはタスクを全てまとめた一つだけのリストで管理していると勘違いしているバカが わんさか居るんだ。
>>941 ゲーム内パラメータ類の管理としてはDBも有りだけど。
なんとなくDBっていうと記録・検索ってイメージで
タスクシステムが対象としてる時間軸で対象オブジェクトの状態推移や生成・消滅が頻発するケースの場合
あんまりDBの考え方は合わないような気がする。
まぁ、表示用オブジェのリストやコリジョン用リストなどを種類別に簡易SQLで取得とか、DBの検索機能に限った
考え方としては面白いけど…
DB必要ならDB使えばいいだろ……。
また、DBにするメリットも考えず「やってみました→メリットは後で考える」か? アフォ技術者いい加減にしろ 目的もなしに行動するな キチガイがかよ すべてが無駄 まったく大成しねぇ する要素がねぇ
>>948 どんだけ阿呆なんだ
お前、普通のDB使ったことないだろ
>>939 >タスクシステム=DBという視点で見て、
>ゲームにDBは必要か否かを議論するのが有効かと。
これはゲームによるとしか言えないんじゃね。
一般化してなんにでも適用できる話じゃないよね。
タスクシステムはDBというより ゲームに特化したActor Modelの一実装例、としたほうが自然かと。 タスクシステム自体では何も定義されてないため実装依存で千差万別になってる メッセージパッシングに関する議論とか、Actor Modelとして見た場合のほうが分かりやすい。
ホントこんな給料泥棒技術者うんざりするな とりあえずやってみてメリットは後で考えますとかふざけるのもいい加減にしろって思うよ DBにするのが目的です はぁ?馬鹿じゃねぇの DBにして何がよくなるからDBにしたのか?ってそこを考えずに まずDBにするのかよw チョーウケルw
>各オブジェクトを何処からでも参照できるようにしたこと、 どこからでも参照できるようになることがメリットとは思えない。 なので、 >そのための画一的手法を提供したこと、 これもメリットとは思えない。 >自動並列処理への余地を残したこと、 この「自動」の意味が分からないんだよな。 結局クラス作ってリストに入れるんだよね。 どの辺の労力の肩代わりを指して「自動」と言ってるんだろうか。 「これが、こうなる」という風にズバリ示してもらえないかな。
その前にだれか次スレ立てろ矢
何やっても勃たねぇ。 誰か代わりに頼む。
>>956 お前は510のソースすら読めなかった給料泥棒ではないか。
>>943 遅レスだが、
>仮に会社で仕事を割り振るときに
>「お前、すごいから2倍ね」
>って仕事わたされて本当に2倍できるか?って話
>どんな天才でも、まず、不可能だと思う
別にプログラムに限った話ではなく、個人差はあるんじゃね。
俗にプログラマの生産性のバラつきは、非常に大きいとも言うよな。
>スクリプト作れて整備するほど優秀な人間1人飼うより
>プログラムほどほど組める人間大量に雇っちゃってベタ貼りで美味くいくとしたら?
>どっち?って結論としてはどっちでもよくない?w
後者の場合、結局、マトモな責任感持ってる奴が、全部見直して修正とかいう羽目になるんじゃね。
個人的には、ことプログラムに関しては、単純作業にブレークダウンできるものは、手足れが一気にやった方が早くて品質も守れる気がするな。
スクリプトは微妙な調整バランスを何回も行うのに便利 1行変えるたびにいちいちコンパイルしてたらキリが無いんだよ
>>939 へー。これは意外だね
HSP厨おこちゃまの俺をうんこ詩人と勘違いして、コテ付けてる俺にコテ付けろとか要求し
それを違うと指摘してあげると、今度はやたらネチネチと執拗にHSP使ってることに絡んでくる
チョー嫌なオッサンだなー、と思ったら。あれが
>>510 なのかー。面白いな
HSP嫌いの頭コチコチオヤジの脳みそが出してくる解が
>>510 ?趣味野郎のコードだね
964 :
510 :2009/02/19(木) 00:34:45 ID:Qg2fxa2U
ゲームでDBを使う理由は、特定の条件にマッチするオブジェクトを列挙する機能を一箇所に纏めるため。 だけど、実はもう少し野望がある。 何処から誰が何に参照可能かどうかを定義するため、 今までの、「データ構造」「制御構造」「定数」に加え、新たに「参照構造」というものを作り、別途定義する。 参照構造を作るメリットは、今まで制御構造の中に散らばってしまっていたオブジェクト間の参照の定義を、 一箇所に纏めることが出来ること。参照構造がプログラムのすべてを決める。参照構造はプログラムの設計書といえる。 今までこんな大事なものが制御構造にまぎれてプログラムのあちこちに散らばってしまっていたわけだ。 また、何でもかんでもオブジェクトに括りつけようとするオブジェクト指向とは全く正反対の考え方であり、 ゆえに、従来型タスクシステムとも正反対の考え方といえる。 >この「自動」の意味が分からないんだよな。 いちいち説明するまでも無いと思っていたが。 自動並列処理ってのは、処理の自動並列化ってこと。 マルチスレッドでパフォーマンス稼ぐこと。
>>963 お前は頭おかしそうだから、このままコテにしといてくれ。
>>941 で、タスクシステム(
>>2 )は実はDBだったんだ説が生まれたのか
まーたタスク信者が一般化・抽象化しまくって何がなんだか分からないこと言い出してるな
一般化・抽象化してタスクシステムを再解釈・再定義しようと躍起になるのってタスク信者の
十八番だったよね?
なにが『ちなみに私はタスク信者ではない』だ。タスクカルト教団の模範的振る舞いじゃん
歯も浮いてるしヅラも浮いてんだよオッサン。気付いてねーの?
>>966 コテにしてくれているようだな 感心感心
>>964 > 自動並列処理ってのは、処理の自動並列化ってこと。
510と自動並列化の間には、越えられない壁が見えるが…
>マルチスレッドでパフォーマンス稼ぐこと。 いや、稼げてないんですけど。 シングルスレッドで動いているようにしか見えないし、マルチ化しやすい構造でもないだろ。 仮にパフォーマンスが稼げてるとして、これをやるとやらないとではどんだけ違うの? >自動並列処理ってのは、処理の自動並列化ってこと。 だからさ、ただの並列化と「自動」並列化の違いって何。 その差分を示してくれと言っているんだが。
タスクシステムをゲームに特化したActor Modelと見た場合、 タスクシステムはオブジェクト間のメッセージ方法を定義していない点で不完全だけど ここを定義してないってのが実はタスクシステムが今まで生き延びてきたミソで Actor Model一番の難問をゲーム側の実装に投げてるわけ。 Actor Modelは並列計算モデルとしてはごく王道な考え方。 実装が汚くアンチが攻撃するメッセージ部分などの問題点は実はタスクシステムではなくゲーム側実装です。となるから。 まぁ、アンチにこれよりスマートな並列計算モデルは提示できんだろうし、攻撃してもそこはタスクシステムの本質じゃない、となる。 信者もアンチも頭の中のタスクシステムがみんな違う理由は「タスクシステムは定義が不完全だから」だ。 つまりこんな宗教論争は永遠に終わらんということだ。
つOpenMP
>>971 それスレッドをポータブルに使う”ルール”で
並列計算モデルじゃないから。
まぁコンパイラに指示するだけで、並列計算を真面目にやるのならMPIかねぇ。 ゲームのフレームワーク部に真面目にMPI使うなんて気が狂いそうだ
>>968 だから「自動並列化への余地を残した」って。
まぁ並列化はどうでも。流行みたいなものだから取り入れたってだけだし。
>966
> で、タスクシステム(
>>2 )は実はDBだったんだ説が生まれたのか
そこまで曲解できるオマエの頭の中身を見てみたいwww
当たり前だろ。俺は良い子だからな ウンコきばって思案する詩人と一緒にされちゃ適わないからね 昨日は輪講で時間が余ったんでDSLとは何か。HSPはDSLなのか について指導教官を交えて皆で討論した DSLとはDamn Sophisticate Languageではないか、という説が有力となり ならばHSPはDSLであることに疑う余地はない。という多数意見でまとまった 指導教官はFORTRANもDSLであると強く主張したが賛同は得られなかった RubyこそDSL、StarRubyマンセー、と主張するツクラーも若干名いたが HSP使いの数の暴力により封殺された
>>969 分からない奴だな。
・ただの並列化
→手動でスレッド作成して手動で仕事割り振り。
・自動並列化
→予め作成された幾つかのスレッドに自動で仕事割り振り。
ごちゃごちゃ言ってないで、MPIでも勉強して来い
>>974 > だから「自動並列化への余地を残した」って。
それなら、タスクシステムw も「自動並列化への余地」とやらは残ってるな。
ここにいるタスク信者ってやっぱアマチュアorアマチュアと大差ない水準の底辺プロが多そうだね
学生の俺でも分かる。俺と同じ臭いがする。無知の臭い。
世界を知らず、既出も何も知らない。車輪の再発明して俺tuee状態を楽しむタイプだ。
HSP使いは常にこの状態だからよく分かる
HSP使いと大差ない無教養・無知の底辺層の民こそがHSPを執拗に毛嫌いする
というのは知ってけど、再確認できた気がする
>>510 はかなり無知なアマチュアだ。たぶん俺と歳は大差ない。
ただ、この人はおそらくは、俺と違ってゲーム作った本数は物凄く少ない、orゼロだと思う
ゲーム作って誰かに遊んでもらって感想聞いたりするより、ゲームの仕組みに固執する系の人だと思う
サクっと作り捨てのゲームプログラムをガシガシ作って周りの連中に遊んでもらって
これここつまらん俺が改造してやる、ほれどうだ、あー、おー、なにー、みたいなこととは
無縁の人っぽい
MPIならMPIと最初から言えばいいのにな。
しかも全然MPI関係なくね?
>>510 の中にMPI関係ありそうな部分て、どこ?
MPIは鬼門だ 夢を見て何人ものPGが死んでいった やめておけやめておけ
HSPがDSLだっつーんなら、一体何の特定の問題を解決するのに特化した言語だっつーんだよ。 >DSLとはDamn Sophisticate Languageではないか、という説が有力となり >ならばHSPはDSLであることに疑う余地はない。という多数意見でまとまった その思考過程が意味が分からん。 天才とは、先天的に常人をはるかに超えた能力を持った人を言うという説が有力となり、 ならば俺が天才であることに疑う余地は無い、と同じことを言ってるぞ。しかも多数決て。 確かにHSPは ・ゲーム作りたい ・お金ない ・スキル無い という特定の問題を解決するのに特化した言語だがな。
>>980 いやおまえ、みんな別にHSP叩いてないし、
むしろ優しく勘違いをさとされてるんだぞ?w
自分の言い分が通らないから全員底辺とか、どうなのよそれw
>>964 >ゲームでDBを使う理由は、特定の条件にマッチするオブジェクトを列挙する機能を一箇所に纏めるため
ちょっと待って。このタスク信者は何をボケかましてるの?
HSP使いの厨房の俺でも、学内RPGとか作るときに既存のDBMを
組み込んだりするわけだけど、そんな低レベルなことをお前は今発見したわけ?
つーか、話が摩り替わってない?タスクシステム=DBなんだろ?なんで?池沼?
すまんが学内RPGって何のことだ?ジャンルが分からん…
>>985 全員だなんて言ってない。声がでかい奴がHSP叩いてるだけ
いい歳したまともな大人は、HSP使ってるガキンチョ相手に
クソ言語だあーだこーだとか言わない。華麗にスルーする
>>980 俺も高校性のころは作ってたサ。
ただ、今風のゲームは規模が大きすぎて趣味で作るにしては資本がかかりすぎる。
だから方法論ぐらいしか遊び場が無いんだよ。
それに、ゲームで飯食うなんて嫌だから、アマチュアで結構。
>>986 既存のDBじゃねぇっつーの。
いちいち自分が知ってる単語が出てくるたびに自分が分かる範囲で拡大解釈して突っ込んでくるな。
>>989 ゲハ板で妄想でウダウダ知ったかブリブリっ子してるチンマンコ共と同じじゃん
クリエイター気取りっていう趣味があるのは知ってるけど、なんなの君らって?
何も生み出さないんだけど、作る過程を研究してる俺ってクリエイターみたいな
気分だけ楽しむ自称クリエイター。タスク信者なんtえ、永遠に終わることのない
山篭りして、ロクなもの生み出さずに歳ばかり重ねて人知れず朽ち果てるタイプじゃない?
なんでこういう頭でっかちのオッサンがこういう板のこういうスレでデカイ面して
HSPを叩くのか全く理解できない。2ちゃんってすげえな。口先野郎の中年ばっか
>>990 はぁ?
あんたゲームでDB使うのが新規性に富む、野望と野心に溢れたフロンティア
みたいに考えてるんだろ
DBがハンドメイドのものか既存のものかに一体何の重要な違いがある?
あとさ、シーングラフの中から、条件にあったオブジェクトを高速に列挙する
それをお前はDBだとかあんた言ってるんだろ?
そんな機能、シーングラフを扱うライブラリなら大抵入ってるじゃん
or用意に組み込めるようなトラバーサのインターフェースを提供してるじゃん
>>983 うぜぇんだよ。三下
ネタにマジレスとか正気か?マジでキチガイなんじゃね?
>>510 は従来型タスクシステムの正反対だし作者はタスク信者じゃない上にアマチュアだという。
このひどい徒労感はどうすりゃいいんだ。
一応
>>2 は化石みたいなもので実際使ってるやつはいないからクソ、
っつーことはタスク信者が言ってたから終了でいいよな。
で、新たにレベルアップしたカスタムウンコシステムが
>>510 だと思っていたのに、
なんか違うと言って逃げられた。
もうアマチュアしか残ってないのかな、タスカーは。
現場で使ってる人、まだいる?
突き放し方が高校生のそれではないと思っていたが。まぁこういうことも有る。がんばれ俺。
>>995 そうだな。こういうこともあるさ。ドンマイ。頑張れQg2fxa2U
>>995 なに?もうギブアップ?俺のせりふがプロっぽく見えるなんて
相当にレベル低いな
あとさ、高専は高校であって高校ではない。高専でぐぐれ。ナメてんのか
あとさ、輪講の内容がネタなんだよ。わっかんねーやつだな
あと、気付いてないと思うけど、俺はID:q8lA0UPYな
>>510 を庇ってたアンチタスク。寝返ったとか言われてたけどなw
1000 :
名前は開発中のものです。 :2009/02/19(木) 02:33:47 ID:PSw+2OVR
1000なら、タスクシステムはジョブコンという名で受け継がれる。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。