09/02/02 19:47:53 9tvsUBOz
ひとりでやってるよ
19:名前は開発中のものです。
09/02/02 19:51:25 cShVBku0
>>18
書き込み制限つらそうだなｗ
20:名前は開発中のものです。
09/02/02 19:53:17 /OtqrHae
このスレは俺が粘着してるから他のスレで楽しんでください。
21:名前は開発中のものです。
09/02/02 20:08:25 ZmvZOOAJ
>>12
> まあ、数人のタスク信者を２人で撃退したからね当然といえば当然だな
お前には、自分が撃退されることもわからないのか。こんな基地外珍しいな。
22:名前は開発中のものです。
09/02/02 20:27:51 4iEjv7V2
ID:cShVBku0がコテになるっていうなら俺は消える。
そしてコテになったら即あぼ～ん設定してあげるよ。
23:名前は開発中のものです。
09/02/02 20:33:59 cShVBku0
ＩＤあるんだからさっさとあぼーんしろよｗ
そしたら前スレの俺の武勇伝をあることないこと脚色して書き込むからさｗ
24:名前は開発中のものです。
09/02/02 20:35:30 4iEjv7V2
IDあぼ～んしちゃったら何がなんだかわからなくなるじゃん
25:名前は開発中のものです。
09/02/02 20:56:02 v0zAXoNG
まともに議論したいんだったら、mixiとか使って
基地外は排除しちゃえばいいんじゃない。
26:名前は開発中のものです。
09/02/02 21:00:59 riEYZJpX
よーしじゃあmixiに移動だ
でどこ？
27:名前は開発中のものです。
09/02/02 23:59:31 SpnGISw5
>>12
数人っていうか１人のように思う。
それと、疲れちゃったプログラマをからかい続けるのは感心しない。
そろそろやめとけば？
なんか効き目が強い。多分本当に病気だ。
それでもやっぱタスク使ってて何か引っかかるものがあるからこのスレに来てるんだろうし
28:名前は開発中のものです。
09/02/03 00:23:33 az8GBqBA
■■■■■■■■■■■■■ スレ主が真性基地外であることが発覚したため終了 ■■■■■■■■■■■■■■■■
29:名前は開発中のものです。
09/02/03 00:30:03 lrih8mAc
>>27
いいんだよ
そいつの次の成長なんてタスクシステムを捨てた先にあるのは明らかなんだから
それに他の初心者がこんなもん妄信しはじめたらどうする
それに程度の低い書籍の悪影響もあるだろうな
ベタ書きを極度に馬鹿にするあまり
書かなければならない処理があるということの説明を怠った
独学ばっかりしてて会社でも誰ともやりとりがなければ誰にも指摘をうけないだろうな
前スレで引数の話を始めにしたが
引数が無い関数のがよく見える
とか言い出しやがった
明らかにレベルが低いというか危険レベルだろ
オブジェクト指向云々の前になぜプログラム言語が制限をつける形で成長してきたのか？
そこからすでにわかってねぇそんなレベルだった
型ってなんで必要なのか？引数ってなんであるのか？グローバル変数ってなんでダメなのか？
そういうところを一つ一つ考えなおさなきゃ次へいけないだろ
俺の周りにはたまたま教えてくれる人間がいたんだけどね
30:名前は開発中のものです。
09/02/03 10:35:48 az8GBqBA
注意！！ >>29 = 真性基地外のため、初心者は騙されるな！！！
31:名前は開発中のものです。
09/02/03 12:02:10 vWXRMn0/
とりあえず
URLﾘﾝｸ(sdc.sun.co.jp)
昔のC++には含まれていたtask.h(task library)
今の標準にはない
32:名前は開発中のものです。
09/02/03 19:50:07 +ZtfpvwK
近代的タスクシステムの構築
URLﾘﾝｸ(d.hatena.ne.jp)
33:名前は開発中のものです。
09/02/03 20:20:13 bfgGLsQE
>>32
いい記事だとおも
34:名前は開発中のものです。
09/02/03 21:10:48 jRNhtvu7
linus先生からのお言葉
URLﾘﾝｸ(tabesugi.net)
35:名前は開発中のものです。
09/02/03 21:24:50 lrih8mAc
>>32
どうせなら前スレでボコボコにされたタスク信者のために
明示的な引数の記述についてもコメントしてあげればよかったのにｗ
20090203とか今日だしよｗ
どうせみてんだろ＞やねうらお
36:名前は開発中のものです。
09/02/03 21:29:31 xRxybyai
>>32
>それではタスクシステムは現代においては不要なのかというとそうでもなく、
>成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
> 「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり(以下略)
現代的に仕立て直しても有用性がデバッガの存在という１点のみか。
まずは一番最初にデバッガ完成させないと有用じゃないんだな
37:名前は開発中のものです。
09/02/03 22:02:41 az8GBqBA
や ね う ら お、はじまったな！
38:名前は開発中のものです。
09/02/03 22:29:12 XllhY44u
ここは空気読んでたすくしすてむはクソだ！って言っとけばいいのか？
39:名前は開発中のものです。
09/02/03 23:38:52 eseY0VNG
>>31
コルーチンライブラリだね。コンテキストの保存と切り替えしてるね
Win32APIのFiber
protothreads
Luaのコルーチン
Squirrelのスレッド
などなど
これらに相当するものでしょ
40:名前は開発中のものです。
09/02/04 00:36:43 bPux8EGG
>>31
へー。C++標準にコルーチンを組み込む動きがあったとは知らんかった
コルーチン＝協調的マルチタスクだから task.h なんだろうね
でもリンク先に「タスクシステム」とか書いてあるし、嫌タスク派に名前が悪いと怒られないか心配だなｗ
検索したらC++トランスレータ時代(1985年頃)のマニュアルが参考文献として上がってたわ
"A set of C++ classes for co-routine style programming"
by Stroustrup, B. and Shopiro, J. E.
in Chapter 2 of the C++ Library Manual
URLﾘﾝｸ(www.softwarepreservation.org)
41:名前は開発中のものです。
09/02/04 01:31:33 NUZzb6Kr
>>40
＞名前が悪いと怒られないか心配だなｗ
それは大丈夫じゃないかな
複数のジョブを協調的に並行処理・逐次処理する仕掛けになってるから
ユーザーはプログラムの中にsleep()とかを挟みこむだけでおｋ
job()
{
while(1)
{
…
sleep();
foreach(…){
…
sleep();
}
…
sleep();
}
}
sleep()とかを挟みこむだけでライブラリが半自動的にタスクに分割してくれる
コンテキストの保存と切り替えを全部面倒みてくれる。スケジューリング機構も
一応入ってる。>>2とは雲泥の差だよ
42:名前は開発中のものです。
09/02/04 02:19:05 bPux8EGG
>>41
そこはただの軽口だから、そんな真面目に説明されてもね
つか君はコルーチンを説明するフリをして>>2をけなしたいだけだろｗｗ別にけなしていいけどさｗ
まあストラウストラップ先生の書いたクラス群はシステムの名に値するみたいだし
今度からコルーチンシステムと呼ぼうかなー
関係ないけどやねうらおは絶対ここチェックしてるよなｗ
やねうらお対ひらしょータスク戦争勃発ｗ
43:名前は開発中のものです。
09/02/04 03:52:12 zoy9itGC
やねうらおはこんな場末のスレ、見てないだろ
>>32 は、前スレまでの議論よりずっとずっと先を行ってるから
彼にとってはこんなスレ、見る価値もないんでねーの？
さすがにこれは天晴れと言わざるを得ない
44:名前は開発中のものです。
09/02/04 04:04:25 YtdnZlpb
>>43
みてないとか嘘だろ
だって「ごった煮」とか前スレ特有の言葉だしてきてるし
わざわざ見てますよアピールしてんだからかまってやれよｗ
でも前スレで話題に上がった引数に関して触れてないのはいただけないな
無視なら「そんなもんは無視」って名言してくれるだけでもスタンスわかっていいんだけど
別にいい悪いも正解不正解もないわけだし
45:名前は開発中のものです。
09/02/04 21:49:37 mLZ417D5
>39
protothreadはコンテキスト保存してないよ。
46:名前は開発中のものです。
09/02/04 23:51:04 Tig/dZbl
>>32
親切心から、敢えてコメントさせてもらうと・・・
アマチュアゲームプログラマ未満だな。
まともにゲーム製作を経験した人間が書いた記事とは、到底思えない。
これ誉めちぎっている奴の狙いって何なんだろ。
一部の明らかにテンションが違う応援団は、スルーするのが基本なのか？
47:名前は開発中のものです。
09/02/04 23:58:11 iOg8fZiC
ほめちぎってる応援団なんてどこにいるんだ
48:名前は開発中のものです。
09/02/05 00:10:20 e5oU/vxX
>>46
是非、どこかのブログで反論頼む！
49:名前は開発中のものです。
09/02/05 00:31:46 9DTLfrVW
やねう先生の近代的なタスクの話を読んでみたけど、
boost::shared_ptrとかunordered_mapとか実装が近代的というだけで、
やってることは古典的だよね（そういう趣旨だから当然だけど）。
ってことで、Mix-in好きのオレが近代的なタスクを考えてみた。
古典的タスクシステムをupdate巡回リストであると仮定すると、
タスクとはすなわちフレームをまたいだ継続的処理の抽象化だと考えることができる。
継続処理を今風に考えれば以下の３種類に分かれるはずで、
どれが良いかはケースバイケースで異なる。
//（１）毎フレーム呼ばれる古き良きタスク（負荷が小さい。排他処理不要）
class PeriodicalTask {
public:
virtual void update() = 0;
};
//（２）コルーチン動作するタスク（負荷は中程度。排他処理不要）
class CooperativeTask {
public:
CooperativeTask(size_t stackSize);
virtual int call() = 0;
};
//（３）ネイティブスレッド動作するタスク（負荷が大きい。排他処理必須）
class PreemptiveTask {
public:
PreemptiveTask(size_t stackSize);
virtual int start() = 0;
};
50:名前は開発中のものです。
09/02/05 00:32:17 9DTLfrVW
ここでは描画オブジェクトとタスクは無関係だと考えて、以下のクラスを用意する。
無関係とするのは、描画オブジェクトが必ず継続処理を必要とするわけではないからだ。
//描画オブジェクト
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 を選ぶのは明らかにオーバースペックで排他処理が面倒になるが、
やりたければそれもまあ可能だ。
51:名前は開発中のものです。
09/02/05 00:32:50 9DTLfrVW
タスクと描画オブジェクトが無関係な理由はもう一つある。
例えば以下のように、描画オブジェクトでなくても継続処理をしたい場合があるからだ。
//テクスチャ画像を波打たせるトランジション
class RippleTextureTransition : public TextureTransition, public CooperativeTask {
public:
int call();
};
とまあこんな感じはどうだろう。モダンっぽくね？
52:名前は開発中のものです。
09/02/05 00:46:05 /BuTmFOA
1,2,3を混ぜたい時はどうするんだ？
単一の巡回呼び出しでは呼べないぞ、それじゃ。
というか、3は明らかに不要だろ。
taskの更新処理は1と2以外にないだろ。
53:名前は開発中のものです。
09/02/05 00:48:58 e5oU/vxX
>>49
何か勘違いしているように思える。
(1)に限らず、(2)でも(3)でも毎フレーム呼び出されると思うのだが。
54:名前は開発中のものです。
09/02/05 00:53:46 /BuTmFOA
>53
3は論外だが、普通に実装すれば1と2はきちんと呼び出し元に帰るから問題ないんじゃね？
55:名前は開発中のものです。
09/02/05 01:01:17 e5oU/vxX
>>54
(2)は、1フレームごとに呼び出し元に戻らないのか？戻らないとしたらいつ戻るんだ？
そもそも1フレームごとに呼び出し元に戻すためにcoroutineにしているんだろ？
わけがわからん…。
56:名前は開発中のものです。
09/02/05 01:27:02 9DTLfrVW
>>52
単一の巡回呼び出しですべて巡回させる必要はないと思う。
もちろん共通のタスクプライオリティを実装して単一巡回にしてもいいのだけれど、
ここではタスクの呼び出し順序に依存しないコーディングを前提としてみた（３はそもそも処理順序を付けられないし）。
んで、今までの慣例的なゲーム開発手法で考えると確かに３は使わないように思えるが、
これから先の開発手法（ＭＴフレームワークとか）もにらんだ話であるし、
「タスク＝フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。
ただ、現状では貴重な資源であるネイティブスレッドを本当に他と同列に扱えるかというと難しいとは思う。
>>53
いや、３はただのスレッドだよ。２は、なんかごめん。確かに混乱するかもなこれ。
call() は毎フレーム（コンテキスト差し替えの上で）呼ばれる関数で、call() の中では yield し続けると思ってくれ。
57:名前は開発中のものです。
09/02/05 01:37:27 e5oU/vxX
>>56
毎フレームcallが呼び出されるなら、結局呼び出し側(タスクシステム)からしてみれば、
単なるメソッド呼び出しなわけで、その実装の詳細(coroutineで書かれているか/いないか)は
どうでもいいのでは？
だから、(1)と(2)でinterfaceを変更する意味がわからない。
どう見ても共通のinterfaceで良いように思える。
58:名前は開発中のものです。
09/02/05 01:42:57 e5oU/vxX
>>56
> 「タスク＝フレームをまたいだ継続的処理の抽象化」という観点から同列に扱っている。
についてだけど、タスクはフレームをまたぐが、少なくとも1フレーム以内に制御はいったん呼び出し側に
戻ってこないと困ると思うのだが。
ID:9DTLfrVWは何かここを勘違いしているような気がする。
そもそもスレッドを割り当てるのは、呼び出し側で制御すべき問題であって、
スレッド一つ割り当てて実行させたいからと言って呼び出される側のタスクが勝手に
スレッドを作っていいわけではない。
ここまではわかってる？
59:名前は開発中のものです。
09/02/05 02:02:00 9DTLfrVW
>>58
んー、古典タスクの定義にこだわりすぎだと思うんですが
あくまで近代的タスクという思考実験なので・・・
暇な時に簡単な参考実装でも作ってみようかな
>タスクは(略)1フレーム以内に制御はいったん呼び出し側に戻ってこないと困ると思うのだが。
１と２は戻ります
３は戻りませんが、ユーザプログラムはそれを分かって３を使うわけなので困らないと思いますよ
>そもそもスレッドを割り当てるのは、呼び出し側(タスクシステム)で制御すべき問題であって、
スレッドの割り当てはユーザプログラムが制御すべき問題であって、
呼び出し側(システムプログラム側)ではない、という考えでこうなっています。
ＭＴフレームワークではシステム側で各スレッドにタスクを振り分けて負荷の分散を
行っているらしいのでそういう場合は仰るとおりですが、
それを前提にすると１と２も排他処理必須になるのでちょっと複雑になりすぎるかなと。
60:名前は開発中のものです。
09/02/05 02:11:55 e5oU/vxX
>>59
> ３は戻りませんが、ユーザプログラムはそれを分かって３を使うわけなので困らないと思いますよ
戻らないということは、そのスレッドは呼び出し側で生成したスレッド
そのまま使い切ることになるのだから、「呼び出し側(システムプログラム側)では
ない、という考えでこうなっています」と明らかに矛盾してるんだが。
61:名前は開発中のものです。
09/02/05 02:23:22 9DTLfrVW
CreateThread()というAPIがあるとして、誰がCreateThread()を呼ぶかと言う話なら
それはシステム側になると思いますけど、
作成タイミングもスタック容量もユーザプログラムが制御するのだから別に矛盾してないと思いますよう
それより、なんか疑問点を出されているというより粗探しをされている気がする
どうして突っかかられてるのかが分からないなあ
62:名前は開発中のものです。
09/02/05 02:38:16 e5oU/vxX
>>61
粗探しをしているつもりはないので、疑似コードなり何なりを出してもらえれば
協力はさせてもらうが。
threadというのは生成に時間がかかるものであって事前に作ってpoolingして
おくのが普通であって、stack sizeなんか都度指定されたらpoolingしている
threadが使い回せない。
つまり、(3)でスレッドを割り当てて欲しいときにstack sizeの指定はいらない。
タスクシステムからのupdate呼び出しのなかでスレッドを割り当てて欲しいときに
threadPooler.Run(boost::function(&MyClass::Worker));
とするだけのことではないか？
だから、(3)を、普通のタスク(1),(2)と区別する意味が俺にはよくわからないのだが…。
63:名前は開発中のものです。
09/02/05 03:06:56 WlW8taMc
とりあえずどんな問題を解決したいのか明らかにしてからコード書いてください。おねがいします。
64:名前は開発中のものです。
09/02/05 03:10:28 9DTLfrVW
>>62
なる、プールされたスレッドってのは考えてなかったです
例に挙げられたコードも分かりやすいと思いますが、
とりあえず>>49の方向でそうした実装を取り入れるなら、
PreemptiveTask のコンストラクタがスタックサイズを引数に取らないようにして、
内部的にプールされたスレッドを使い回すようにすると良さげかもですね
それか、必ずプールされているのも都合が悪いことがありそうだから
PooledPreemptiveTask のような新しいクラスにそうした実装を組み込むか
とりあえず、その辺はより実装に近い部分なので、ゆっくり煮詰めていくたぐいの話ではないですかね
１、２、３をそれぞれ区別するのは、使い手側から見た時に混同せず
明確に区別すべきものだからです（コーディング方法もそれぞれ異なるし）
>>62はシステム側の都合から見てるから区別不要に思えるんじゃないかな
>>63
え、おれ？ごめん
ということですいませんが、そろそろ寝ます
敗北宣言
65:名前は開発中のものです。
09/02/05 03:50:41 MYSEarFY
近代的タスクシステムの構築(2)
URLﾘﾝｸ(d.hatena.ne.jp)
66:名前は開発中のものです。
09/02/05 04:12:57 Ib2V0W+J
やねうらおの方からきますたｗ
まあ、ゲームオブジェクト管理周りをどうするかは作るもん次第、銀の弾丸なしってことで、
それはプログラマの仕事がなくならないってことで、いい話なんじゃね。
67:名前は開発中のものです。
09/02/05 07:42:18 V08fWeRa
やねも昔ほど強く言わなくなってるな
実は必要無いってもう気付いてるな
そもそもタスクシステム、コーティングの手間しか削らない割に記述の複雑さは一級品だからな
ベタガキで誰でも読めるソースになるならそのほうがいいだろ
長い期間強く組む為には構造は単純でないと駄目なんだよね
68:名前は開発中のものです。
09/02/05 07:42:24 /BuTmFOA
>64
1,2,3を混ぜて巡回呼び出ししたい場合というのが存在するから、同一I/Fから呼び出せないと困るぞ。
例えば、全てのtaskにコンテキスト保存が必要では無い場合に一部taskは1で作成するとかな。
69:名前は開発中のものです。
09/02/05 17:15:53 tABpRsfL
>>32
現代じゃなくて近代なのか。ずいぶん遠慮がちに書くのだなぁ。最初から後退戦か
敗北主義を匂わせれば、相手は正面から斬り付けるのを躊躇うはず、という計算が
見え隠れすんなぁ
＞いまの視点(2009年)で見たときに拙著(ASIN:4798006033)にて不足している部分を補足するため
今までは利得がどこにあるのかを決定的に見誤っていた、と白状したほうが高感度アップな
＞成熟したタスクシステム(タスク自体のデバッグを支援するタスクデバッガのような環境を含めて
＞「タスクフレームワーク」と呼ぶほうがふさわしいかも知れない)は、ゲーム開発において依然として有用であり
それにしてもタスクフレームワークとか鼻クソみたいな造語を作るの好きな人が多いな
ビデオゲーム開発のためのフレームワークなんだろ？
ビデオゲームというのは何かしらの時間ステップで何かしらの逐次処理（数値積分など）を
繰り返すもの。そしてその処理は複数。だから並行処理ないし並列処理することになる
どんなものであれ、その内部でジョブステップ（タスク）が駆動するなんて当たり前のこと
ありふれたこと。むしろないほうがおかしい
なのにビデオゲーム開発のためのフレームワークの看板にタスクを掲げる
つまり【タスク】が他のフレームワークには存在しない特徴でありウリだと思い込んでる
タスクというキーワードに何か特殊な意味・特定の実装（>>2とか）を連想し、それ以外は
タスクではない、という視野狭窄・自己中・ド田舎ルール・カルト信仰が見え隠れするね
つまりタスク厨
タスクというキーワードに対する思い入れの強さ。これは>>2、松浦本ベースの劣化
トンデモ情報による刷り込みがやねうらおにも及んでいた可能性を示唆する
70:名前は開発中のものです。
09/02/05 20:01:26 1mXFjsrF
何と戦っているんだ？
71:名前は開発中のものです。
09/02/05 20:05:59 tABpRsfL
>>32
＞現代において、タスクシステムを実装するなら、もう少しタスク間通信を抽象化してタスク側から
＞タスクシステムが保持しているlistには直接触れないようにするべきだが
今度は近代じゃなくて現代なのか
はっきり言っちゃうよ。それは時代ではないんだよ。それは開発規模に応じた普遍的な要求なんだよ
例えば大所帯でRPG作るとき、みんながジョブエントリ・タスクエントリのコンテナに直接触れたらどうなる
わかるよな？
15年以上前にはビデオゲームの世界にさえジョブモニタやタスクモニタといったものが存在した
これは汎用機や組み込みシステムのモニタやOS（RTOS）が大昔に進んだ道を踏襲しているに過ぎない
32bit機が登場した頃には中堅どころでさえブクブクと膨れ上がるゲームのボリュームに汲々としており
ジョブを記述するユーザー（スクリプタ含む）にジョブエントリやタスクエントリのコンテナへの自由な
アクセスを許可するなんて蛮勇以外のなにものでもないケースは珍しくなくなっていた
一定以上の規模になればユーザーを中枢から隔離するなんて時代を問わず当たり前のこと
CだのC++だのアセンブリ言語だの関係ない
これを【現代】の流れというなら、それはやねうらおの内なる世界における歴史的系譜を辿る際に
現代の1ページに登場するとある事変に過ぎず。やねうらおの個人的出来事に過ぎない
『やねうらおの歴史 ～やねうらおの近代そして現代～』というタイトルで出版したほうがいい
みんな買うよ
72:名前は開発中のものです。
09/02/05 21:33:53 HwyPz9yB
ID:tABpRsfLはなんでそんなに日本語が不自由なの？
73:名前は開発中のものです。
09/02/05 21:44:34 sYm6Gfdu
タスクというキーワードに対する思い入れｗｗｗ
74:名前は開発中のものです。
09/02/05 21:48:23 Kg6Z2A1M
やねが今回タスクシステム（なにそれ？）を語りだしたときに
それがどういう規模のゲーム開発のお話なのか、という部分には
一切言及しなかったよな
この手のお話には必須の大前提なんだけどバサーリ省いた
あらゆる規模にタスクシステムとやらいうものが適用するメリットがあると
考えてるんだろうかね
もうこの時点で彼のタスクシステム（はぁ？）論は敗北確率急上昇だろ
とても残念だ
少人数・ないし一人のプログラマによる小規模開発ではベタ書きのがいい
彼の言うタスクフレームワーク（あ？）とかいうもの。こいつを構築するために
支払うイニシャルコストがペイできる分岐点ってもんがあるわけ
やねはここを見積もってないんだろうね
75:名前は開発中のものです。
09/02/05 21:56:59 Kg6Z2A1M
誰と作るのか。何人で？そいつらの戦闘力はいくつ？期間は？実装対象は？
開発機材は？既存のライブラリとかのリソースは？買っていいの？
こういうファクターを丸無視してコーディングスタイルとか設計の是非を語ろうったって
解なんて出やしない。だからやねがエロゲ作ってるならエロゲ話のことだと言えばいいんだよ
PC用3Dエロゲにおけるタスクシステムの有効性について
とかな。あ、3Dは駄目なんだっけこのオッサン
76:名前は開発中のものです。
09/02/05 22:06:28 Kri4Crxo
やねうや夫は2Dオヤジだから一般化して語れないぞ
あとゲーム専用ハードのゲーム開発経験もないんじゃないかな
77:名前は開発中のものです。
09/02/05 22:39:01 tABpRsfL
やねうらおさんってコンシューマ畑とも縁遠いのか。それは失礼した
DSで死にそうになってるフェードアウトハゲが10年単位の周回遅れで
発明した独自理論を得意げに語ってるのかと思ってた
エロゲの人ならこういう発見もアリなんじゃないかな。煉獄へようこそ
78:名前は開発中のものです。
09/02/05 23:02:22 AceVSe0N
>>36
前々スレから散々におわせていたことをようやく認識した
ということだろうね
IDだのハンドル云々の話は10年近く前にファミベのよっしんが記事を書いてる
URLﾘﾝｸ(www2.tky.3web.ne.jp)
アーケードやコンシューマと無縁なやねなら確実に読んでると思うんだけどね
参考リンクとして貼りゃいいのに
よっしん氏が呼んでるタスクシステムという代物と>>2は同一ではないよな
>>2はタスクリストとかいうものを周期的にナメまわしてバッチ処理するだけ
「はいこれでオシマーイ。あとはお前らにお任せだっよーん」みたいなゴミカス
最近じゃこれだけでタスクシステムってことで通用するんだから
タスクシステムはタスクの相互作用なんて気にする必要まったくないわけ
変な通信機能盛り込むなよ
79:名前は開発中のものです。
09/02/05 23:10:23 yvQde++7
>>74
URLﾘﾝｸ(d.hatena.ne.jp)
に
> すべてのゲームにタスクシステムが必要なのではない。
はっきりと書いてあるのに
> あらゆる規模にタスクシステムとやらいうものが適用するメリットがあると
> 考えてるんだろうかね
とは、とても残念な理解力ですね。
80:名前は開発中のものです。
09/02/05 23:15:47 /BuTmFOA
>74
> 彼の言うタスクフレームワーク（あ？）とかいうもの。こいつを構築するために
> 支払うイニシャルコストがペイできる分岐点ってもんがあるわけ
> やねはここを見積もってないんだろうね
逆に、一人で開発してるなら何やってもイイと思うけどね。
81:名前は開発中のものです。
09/02/05 23:45:46 /BuTmFOA
>12
> update();
> で動くのと
> update(jiki,teki,tama,unko);
> で動くのとじゃ
> プログラムとしては絶対に下のがいい
普通に考えると、visitorに共通コンテキストを持たせてコンテナ内のタスクを巡回処理させる。
引数で渡すなんて愚の骨頂。
82:名前は開発中のものです。
09/02/06 00:09:26 wGKtGJau
>>81
>>12＝スレ主＝基地外が前スレで判明している。触るな危険。
83:名前は開発中のものです。
09/02/06 00:12:08 H1z7Q+5u
>>81
引数のない関数ってどうよ？
お前、自分が使ってみろって言われたときのこと考えろよ
84:名前は開発中のものです。
09/02/06 00:15:46 4xm8YBEc
>83
おまえvisitorの意味判ってないだろ。
85:名前は開発中のものです。
09/02/06 00:18:56 H1z7Q+5u
>>84
関係ないね
大事なのは引数で渡すことによって関数無いで変更される恐れのある
インスタンスを明確にすること
お前のような素人はデザパタの前にＣ言語でも勉強しろ
なにせ引数もよくわからずグローバル変数で渡してるぐらいの低知能なんだからなｗ
86:名前は開発中のものです。
09/02/06 00:19:44 4xm8YBEc
>85
やっぱり判ってないのかw
87:名前は開発中のものです。
09/02/06 00:20:01 1vVyPOFv
釣りにしか見えない
88:名前は開発中のものです。
09/02/06 00:20:20 H1z7Q+5u
>>86
引数の有効性はわかったかね？
89:名前は開発中のものです。
09/02/06 00:23:00 H1z7Q+5u
>>86
前スレよろしく
今回も俺が特別に教えてあげよう
上のupdate()は関数内で何にアクセスしてるのかまったくわからないが
下のupdate(jiki・・・）はアクセスしてるインスタンスを引数に絞ることができる
（グローバル変数を使わないという規約を守れば）
これによってデータの安全性が保障されるというわけだよ
君のようにコーディングの効率ばっかりとって
引数もわからんような低知能は俺と話すようなレベルにないということがわかったかね？
90:名前は開発中のものです。
09/02/06 00:26:08 ux7UjNgY
>88
ここまでムキになるということは、>12=スレ主ってヤツかwww
修正コストとか考えたこと無いんだろうなぁ。幸せなヤツw
91:名前は開発中のものです。
09/02/06 00:26:51 1vrKKSIM
ID:H1z7Q+5uが噂のスレ主だな
一人だけ極端にレベルが低いのにその自覚なし
92:名前は開発中のものです。
09/02/06 00:28:03 Cfc6lR6P
こらこら、触るな危険といってるだろうに。
93:名前は開発中のものです。
09/02/06 00:31:12 ux7UjNgY
>89
> 下のupdate(jiki・・・）はアクセスしてるインスタンスを引数に絞ることができる
笑っちゃうなwww
ということは、ID:H1z7Q+5uはtaskの種類によって引数が変わることが前提か。
もしかしてtask保持コンテナも別に持つ派なのか？
例えば敵タスクがあったとして、雑魚敵Aと雑魚敵Bが異なるコンテキストを必要とする場合とか
考えたこと無いのか？ 雑魚敵Ａと雑魚敵Ｂで最小公倍数的な引数を取るupdate関数をつくったら、
それはID:H1z7Q+5uが>89で言っていることと矛盾するって気づかないのか？
94:名前は開発中のものです。
09/02/06 00:34:26 1vVyPOFv
残念なスレ主と遊ぼうのスレはここですか？
95:名前は開発中のものです。
09/02/06 00:52:39 nWDkACnD
押すなよ！ 絶対押すなよ！
96:名前は開発中のものです。
09/02/06 00:53:38 ZPF/rc3n
>>80
その一人開発ってことは趣味の世界の話でいいよな？
プロの一人開発ったってフリーランスという名のプーでもなければ
自分一人の問題じゃねーし、他と折り合い付けないと会社つぶれるしな
>>2ベースのゲロゲロフレームワークなんて誰も使いたがらないから作らないよ
で、趣味野郎でオナニーフレームワーク？これもあんま意味ないよ女子高生
大多数のパンピースペックの趣味プログラマは無難にサクっとゲーム一本
作りあげる方法を模索する
パンピースペックの趣味野郎がオナニーフレームワークとかいうハマリ道に
進んだら大半は生きて還ってこれん。終わり無きライフワークになるだろ
まぁそれはそれで楽しい人生なのかもね。否定はしない
ゲームではなく部品を作ることに情熱燃やして技巧に走って茨の道へ突進して
何年もの歳月をかけて山篭りして誰にも使われないフレームワークを構築する人生
悪くない。でもその結果が>>2ベースのゲロゲロシステムじゃな。成仏できんの？ｗ
97:名前は開発中のものです。
09/02/06 00:59:04 1vrKKSIM
96もスレ主じゃね？こいつ本当に頭おかしいんだな。
98:名前は開発中のものです。
09/02/06 01:00:52 ZPF/rc3n
引数君と一緒にすんなハゲ
99:名前は開発中のものです。
09/02/06 01:05:33 1vrKKSIM
>>98
じゃあ、この残念な引数君にも何か言ってやってくれ
100:名前は開発中のものです。
09/02/06 01:17:02 ZPF/rc3n
引数君がアンチタスクだということは知っているが、前スレ終わりごろの
議論の内容がよくわからん
俺は>>2＝チンカスゴミカス だと思ってるが引数君とは批判のベクトルが違うようだ
彼は数種類のクラスに共通のインターフェースを与え、共通のコードから呼び出す
というメカニズムを全否定してるのだろうか？だとしたらそれは仮想関数の全否定であり
わけわからん
引数君の主張内容がよく分かってない
101:名前は開発中のものです。
09/02/06 01:25:06 1vrKKSIM
>>100
>>12
102:名前は開発中のものです。
09/02/06 01:29:48 ZPF/rc3n
あぁ？
103:名前は開発中のものです。
09/02/06 01:34:39 1vrKKSIM
引数君の主張なら>>12のリンク先を見れば十分わかると思うんだが、わからないのか？
それとも、あんたも日本語の残念な人か？
104:名前は開発中のものです。
09/02/06 01:39:11 ZPF/rc3n
俺は前スレの>>823だ。何なら他の発言も発掘してこようか？
105:名前は開発中のものです。
09/02/06 01:43:50 OdnmQxD5
引数君の方がまだ技術に近い話をしてる分マシだな。
もしかして彼はひらしょー氏の言うデータと処理の分離を
超まわりくどく主張しているのかな。
106:名前は開発中のものです。
09/02/06 01:50:49 1vrKKSIM
>>104
前スレ823か。
引数君よりは能力的にマシだということはわかるが、説明がくどく、わかりにくい。
俺はこんな内容の薄い、回りくどい説明を読むのはまっぴらごめんなので、さいなら。
107:名前は開発中のものです。
09/02/06 02:08:15 EVIE955W
ESP能力に問題があるID:1vrKKSIM は
すべてのアンチタスクがスレ主に見える病気を克服するべき
108:名前は開発中のものです。
09/02/06 02:09:41 ZPF/rc3n
超能力能力か
109:名前は開発中のものです。
09/02/06 02:12:05 EVIE955W
くっ…。どうして「お前はバカを克服するべき」って言ってくれないの？
内容の薄い、回りくどい指摘を読むのはまっぴらごめんなので、さようなら
110:名前は開発中のものです。
09/02/06 07:38:45 RQ4iGJCo
お前等馬鹿は、プログラミングで一番時間がかかるのはどこですか？
と聞かれてコーディングとは絶対に答えないくせに
コーディングの手間ばかり減らすことに執着している
なかなか読めないプログラムってなんだ？
構造が複雑なプログラムじゃないの？
お前等馬鹿は全く逆のことを自己満足のためにやっているオナニストだ
プログラマならせめて理詰めで動けよ
お前等凡人から理性まで抜いたら猿と変わらないだろ
111:名前は開発中のものです。
09/02/06 09:47:48 SpEabv2C
>>32
えーと、この人ってイイ歳した何者なの？プロ？パソゲー専門なんじゃない？
＞ビデオゲーム黎明期においては、オールアセンブラで書くことが普通だったので、
＞std::listのような便利なコンテナがあるわけでもなく、技巧的な方法でstd::list
＞みたいなことを実現していただけ
えっえー？この人のいうビデオゲーム黎明期っていつごろのお話なのかな？
70年代？だったらまずZ80アセンブリで>>2を書いてみればいいのに。おかしな人だよ
16bit機時代？intrusiveなコンテナを使った理由がオールアセンブラだから？本当に？
最近は想像だけで昔話を書いても教科書になるのかしら？
どこのゲー専の子が犠牲になるのかしら。ちょっと可哀相ね
知らないことは知らないって言えばいいし、足を使って取材しに行けばいいと思う
んで、頭下げて監修してもらえばいいと思う。このままじゃあんまりだよ
＞古典的なタスクシステムにおいてはタスクに番号(プライオリティ)が振られており
＞番号を指定して特定のタスクのポインタを得ることが出来た
えっえー？つーか古典的タスクシステムってなんじゃい？ファンタジーゾーンなの？
112:名前は開発中のものです。
09/02/06 10:34:43 wGKtGJau
>>111
あんた、何かがしゃべり方がキモイんだけど。
それはそうと、相手は年収何千万もある凄腕のプログラマらしいので、
技術的な反論は是非どこかのブログでやっちゃってください。
113:名前は開発中のものです。
09/02/06 21:26:12 +KF0MHRv
タスクシステムでグローバル変数使うから駄目だって意見が多いけど、
でも見渡してみると、ウィンドウズのウィンドウだってそういうしくみだしなぁ。
114:名前は開発中のものです。
09/02/06 22:07:10 H/Ui7lv7
エロゲー製作は大変ナリよ
URLﾘﾝｸ(d.hatena.ne.jp)
115:名前は開発中のものです。
09/02/06 22:31:40 RQ4iGJCo
>>113
ウィンドウ同士であまりやりとりしなくてもあの複雑さだぞ
リストコントロール２つを連動させるだけでもやばいくらいの手間
基本的にウィンドウズの作り自体関連がたくさん生まれる処理に向いてない
あくまでも独立した動作が前提
116:名前は開発中のものです。
09/02/06 22:36:12 nWDkACnD
>>113
そう思ったのなら両方とも自分で実装してみて比較検討だ！
でも数千行レベルでは使いやすかったやり方が数万行レベルでも同じように使いやすいままかどうかはまた別問題だ！
そこは注意な！ 王道はグローバル変数使わないことだぞ！
117:名前は開発中のものです。
09/02/06 23:12:31 ux7UjNgY
また引数クンの登場か。
>93について、具体例を挙げて答えてよ。
118:名前は開発中のものです。
09/02/06 23:44:30 H1z7Q+5u
>>117
はぁ？何言ってるのかわからない
俺が言いたいのは関数に引数つけろってそんだけだけど？
コンテキスト？は？
そんなもん使った時点で負けだ馬鹿
設計死んでるんだよ
俺の価値観ではそんなもん使った時点で負け
void*となにも変わらない
119:名前は開発中のものです。
09/02/06 23:45:58 H1z7Q+5u
まあ、用は固定でない引数に意味がないんだよね
俺の価値観からすると
120:名前は開発中のものです。
09/02/06 23:53:12 4xm8YBEc
>118
> はぁ？何言ってるのかわからない
じゃ、具体的に質問するけど、雑魚敵Aと雑魚敵Bに関係性が出てきたらどうするの？
例えば雑魚敵Aは雑魚敵Bを殺すことがある、となった場合に、雑魚敵Aのupdate関数の引数に
雑魚敵Bのリストを渡すの？
121:名前は開発中のものです。
09/02/07 00:21:27 lLkuERdr
>>120
>雑魚敵Aのupdate関数の引数に雑魚敵Bのリストを渡すの？
それをやってはダメ
哲学的になるけど
基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
つまり雑魚敵ＡＢに書くべき処理ではない
このアクションはあくまでも雑魚敵Ａと雑魚敵Ｂが存在する空間で起こったことであって
それをシーンクラスとしたらそこに書くべき処理じゃねぇかな？
オブジェクト指向的にはよ
俺はオブジェクト指向原理主義者（テロリストではないｗ）だけど
基本的にオブジェクト指向を変な解釈をしないとしたら
種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ
122:名前は開発中のものです。
09/02/07 00:23:19 UFXAc++2
>121
> 種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
> それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
> そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
> 昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ
今はっきりわかった。キサマはクズだ。
123:名前は開発中のものです。
09/02/07 00:30:10 lLkuERdr
>>122
なんでだよ
いいこと教えてやったのに
何がどうダメなのか言ってみろ
勉強になるぞ
なにせ俺は１０年以上もやってんだからな
124:名前は開発中のものです。
09/02/07 00:32:45 NuBn44S3
10年以上ワナビー君ですかwww
ヒッキーニートで親のスネカジリ。楽しそうですねwww
125:名前は開発中のものです。
09/02/07 00:35:05 lLkuERdr
>>124
不毛な会話したくないんだ
どこがどうダメなのか思ったこと言ってみろ
なんとなく漠然とある自分にとっての常識なんて大抵間違ってる場合が多いぞ
126:名前は開発中のものです。
09/02/07 00:38:14 NuBn44S3
>125
雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
20種類くらいなら、RTSとかだと当たり前にいるぞ。
127:名前は開発中のものです。
09/02/07 00:38:49 XPRCk6pD
というか、どういえばいいんだろう。
あっちのスレでも書いたんだけど、どの処理を誰が担当するかが難しいわけであって、
タスクシステム云々、グローバル変数云々はあんま関係ないと思うんだが。
たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
128:名前は開発中のものです。
09/02/07 00:39:00 qvO9PNvj
ヒッキーだが有能なゲームプログラマの発言＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞（越えられない壁）＞＞＞無能な社会人もどきヘタレグラマの妄言
それがここのルールだ。覚えておきな。
129:名前は開発中のものです。
09/02/07 00:39:49 lLkuERdr
>>126
そりゃ当然それだけの処理が必要になるだろうね
仮にプログラムの組み方が変わったところで
その数が少なくなることは絶対にないからね
それを踏まえて何が問題？
130:名前は開発中のものです。
09/02/07 00:40:05 qe8S2N76
>雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
>20種類くらいなら、RTSとかだと当たり前にいるぞ。
ダブルディスパッチ
131:名前は開発中のものです。
09/02/07 00:41:54 XPRCk6pD
>>126
その莫大な組み合わせを纏めるかどうかは書く人の力量次第だが、
書く場所としてはシーンクラスが良いのでは？ってはなしだろ。
お前が読解力ないだけ。
132:名前は開発中のものです。
09/02/07 00:42:20 lLkuERdr
>>127
全部シーンだろうな
133:名前は開発中のものです。
09/02/07 00:43:44 NuBn44S3
>128
ヒッキーで無能はどこにいるんだ？
134:名前は開発中のものです。
09/02/07 00:46:56 XPRCk6pD
>>132
となると、シーンクラスが肥え太って困る。
モジュール化する何かいい方法は無いですか？
オブジェクト指向ってのは、オブジェクト(リソース)の管理は上手いんだが、
オブジェクトとオブジェクトの関連の記述には向いていないんだよなぁ。
135:名前は開発中のものです。
09/02/07 00:48:05 qvO9PNvj
>>133
居たら教えてくれ。
136:名前は開発中のものです。
09/02/07 00:48:40 cn84NiHO
>>79
どうでもいいけど、やねうらおの文章の引用部分さ
> すべてのゲームにタスクシステムが必要なのではない。
これ文脈読めばわかると思うけど、規模じゃなくて種類の話だよね
あと、残念な○○っていう表現が大好きなブログがあるよね
137:名前は開発中のものです。
09/02/07 00:49:07 lLkuERdr
>>134
ないね
オブジェクト指向ではそこが限界
原理主義者の俺が言うんだから間違いない
後はＣ言語風味にうまく分離して書くしかない
138:名前は開発中のものです。
09/02/07 00:50:51 UFXAc++2
>137
> ないね
単にモノを知らないだけだな。
139:名前は開発中のものです。
09/02/07 00:51:10 e1gHG0fD
>>127
衝突したかの判定はシーンクラスで、衝突に伴う処理は
オブジェクト同士のメッセージ交換ってのが俺のやり方だな。
140:名前は開発中のものです。
09/02/07 00:55:40 UFXAc++2
>127
物理エンジンで本物っぽく動かすつもり？
それとも2Dのマリオやソニックみたいに、それっぽく動けばいいの？
141:名前は開発中のものです。
09/02/07 00:55:51 lLkuERdr
>>138
関連をオブジェクトに見立てて・・・とか馬鹿なこと始める気？
俺、そういうの読み手にわかりにくくなるだけであんまり意味ないと思うぜ
折角オブジェクトが誰にでもわかる表現にするためにオブジェクト指向を使ったのに
変にトリッキーな解釈（関連＝オブジェクトだ！）してわかりにくくしたら
本末転倒じゃね？
って勝手に関連＝オブジェクトの話するだけこいつ馬鹿だなー的
先読みをしてみたけど言いたいことあってる？
142:名前は開発中のものです。
09/02/07 00:56:33 XPRCk6pD
でもちょっとまって。
この流れでいくと、タスクシステムで行うべきことは、
・描画順序の管理
のみ、ということになるな。
その他の処理はすべてシーンクラスで行うと。
晴れて、タスクシステム＝グラフィックエンジン
ということになり、みんな幸せになると。
143:名前は開発中のものです。
09/02/07 00:56:47 hO/vsQBF
>>127
俺なら重力は重力クラスが担当、衝突は衝突クラスが担当するようにする。
重力に引かれたい奴は重力クラスに登録するように！
144:名前は開発中のものです。
09/02/07 00:56:49 vE7+xmqT
オブジェクト指向的には、当たり判定は関連をクラス化すればおｋ
145:名前は開発中のものです。
09/02/07 01:00:11 vE7+xmqT
>>127
石に重力が働くというのなら地面みたいなものがあるはずだから、
石ー重力ー地面としてこの重力をクラスにすれば使いまわしも出来ていい
146:名前は開発中のものです。
09/02/07 01:03:06 UFXAc++2
>143
つ 【オールドタイプの魂】
147:名前は開発中のものです。
09/02/07 01:04:31 cn84NiHO
>>121
＞基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
＞雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
＞つまり雑魚敵ＡＢに書くべき処理ではない
YES
＞それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
シーンでも神でも何でもいいけど、ゲーム世界の物理現象の調停者ｗが
介在し、結果を双方（作用する２体）に通知するというのは全くもって普通
珍しくない
148:名前は開発中のものです。
09/02/07 01:06:44 lLkuERdr
ていうか目をさませ
もしオブジェクトが２０種類いてそれぞれが関連をもつとしたら
少なくとも
a=オブジェクトの状態の数の総和
aC2（aの中から２つ選んだときの重複のない組み合わせだっけ？）
の数だけ処理を書かなきゃいけないことには
どう組んであろうが変わりはないんだぞ
>>147
なんのメリットがあってそんなわかりにくい書き方をするんだ
無駄だろ
149:名前は開発中のものです。
09/02/07 01:09:32 lLkuERdr
あ、aC2じゃ同じオブジェクト同士が抜けてるなｗ
150:名前は開発中のものです。
09/02/07 01:10:08 XPRCk6pD
>>145
重力をクラス化するのは個人の趣味だろうが、
使いまわせるかどうかは怪しいな。
細切れの小さなクラスが1000個ぐらいあって、
それぞれにそれぞれが関係しあって一つの生態系をなし、
結果としてゲームになっている・・・とか。
そういうのって想定外の仕様変更には弱いからなぁ。
まぁゲームの方向性にも寄るのだろうが。
151:名前は開発中のものです。
09/02/07 01:13:32 cn84NiHO
>>148
ゲームワールドをゲームエンジン内部で時間発展させてるからさ
衝突イベントでユーザー定義のコールバック関数が呼ばれるやつだ
152:名前は開発中のものです。
09/02/07 01:14:32 UFXAc++2
>147
普通に考えてそれか。
じゃ俺も普通に考えてみるかな。
雑魚敵Aが雑魚敵Bを攻撃して殺す場合、Aは攻撃判定用不可視オブジェクトXを作成する。
BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。
攻撃判定用不可視オブジェクトを必要に応じて複数作り、それぞれ攻撃する側はそれを作成し、
攻撃を受ける側はそれに対する応答処理を書く。
シーンクラスには、雑魚敵コンテナと同じレベルで攻撃判定用オブジェクトのコンテナを追加して、
そこで相互の判定をする。
153:名前は開発中のものです。
09/02/07 01:22:50 lLkuERdr
>>151-152
いや、だから全然わかってねぇな
なんかお前等変な組み方してるけど
関連の処理を仕様である分、全部書かなきゃいけないことは変わらないんだろ
なんでわざわざ間になんか挟むの？
なんか得になんの？金もらえんの？
素直にシーンオブジェクトに必要な数だけ処理かけよｗ
何をどうしたくてそんな複雑な仕組みにするんだｗ
オブジェクトＸなんていきなり見てお前のそれ誰が理解してくれるんだよ>152
どうせドキュメントもかかねぇしよまねぇだろ
っていうか手間増やしてるしｗ
154:名前は開発中のものです。
09/02/07 01:26:57 XPRCk6pD
>>152
不可視オブジェクトXの受け渡しは誰が行うんだ？
155:名前は開発中のものです。
09/02/07 01:30:03 lLkuERdr
ちなみに俺はオブジェクト指向原理主義者であると同時に
Ｃ＋＋をはじめとするオブジェクト指向言語が大嫌いなんだ
だってなんのメリットもねぇよこの言語ども・・・ｗ
だってよ・・・処理が集中・複雑化するのってシーンクラスみたいなところであって
別に個々にオブジェクト単位にできる部分は誰も苦労してねぇよマジで
ってみんなにはないしょだよｗ
ってところで>>147につけたレスは内容まちがってたな俺
すまんこ
156:名前は開発中のものです。
09/02/07 01:30:17 NuBn44S3
>153
> なんでわざわざ間になんか挟むの？
雑魚敵が増えた時の修正が少なくてすむ。
攻撃判定オブジェクトを間に挟むことで、複数種の雑魚敵が同属性の攻撃だしても、一つの攻撃判定オブジェクトとの
関連処理に還元できる。
157:名前は開発中のものです。
09/02/07 01:32:09 vE7+xmqT
>>150
使いまわすってのはコード的にって事ね
数が多い場合は面倒くさいけど一個一個やっていくしかないなぁ
上位概念のオブジェクトを作れるんであればいいけど
STGでいうなら弾 - 衝突 - 敵 では無くて 自機 - 弾判定 - 敵みたいに
158:名前は開発中のものです。
09/02/07 01:36:16 cn84NiHO
>>152
＞Aは攻撃判定用不可視オブジェクトXを作成する。
そう。AABBとか、高速飛翔するならカプセル、線分を空間上に射出するわけだ
Xがそのうちどっかのバカに命中（得点ゲット）したときの通知が欲しけりゃ
おまえらの大好きなオブジャーバーパティャーンでXにAを登録するやつだ
subjectはX。observerはA
＞BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。
まぁ、何かが自分に衝突したら呼ばれるコールバック関数（オブジェクト）を
登録してるわけだから、その中でユーザー独自の死ぬ処理を入れるわけだ
炎を吹いて墜落するなり、爆発四散するなり好きに振舞え
159:名前は開発中のものです。
09/02/07 01:37:24 lLkuERdr
>>156-157
>雑魚敵が増えた時の修正が少なくてすむ。
だからならないって
必ず仕様の分だけ処理かかなきゃならないんだよ
（それが汎用デフォルト処理に挿げ替えられるかどうかは別として）
>使いまわすってのはコード的にって事ね
コード的なんて気にすんなマジで
関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
３０回コピペして終わる程度の使いまわしなら３０回コピペする気でいろ
そのぐらいでちょうどいい
160:名前は開発中のものです。
09/02/07 01:38:36 XPRCk6pD
>>155
いや確かにそのとおりだと思う。
ただ、シーンクラスみたいなところに処理が集中するのは、
ゲームにオブジェクトとオブジェクトの関係が多いからだと思う。
一般アプリやツールは、リソースの管理がメインなので、
オブジェクト指向も役に立つのだろう。
161:名前は開発中のものです。
09/02/07 01:39:17 dNGvkNLd
ID:lLkuERdrはド素人だろ。こんなクルクルパーは相手にするだけ無駄。
162:名前は開発中のものです。
09/02/07 01:43:47 NuBn44S3
>159
> >雑魚敵が増えた時の修正が少なくてすむ。
> だからならないって
> 必ず仕様の分だけ処理かかなきゃならないんだよ
新規雑魚敵が今までの他の雑魚敵と同じ攻撃を出すのなら、それと同種の攻撃判定オブジェクトを
作成するだけで終了。
オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
163:名前は開発中のものです。
09/02/07 01:45:32 lLkuERdr
>>160
一般のアプリだって同じだよ～ｗ
絶対にボタンとかツールバーの処理なんてウンコぐれーだろ
メイン画面の処理の強烈さといったらない
メインに集中してなくても絶対にどっかに偏るｗ（ツールウィンドウとか・・・）
部品は平均２００行程度しかないのにメインで１０万越えで放置されてるソースとか多いぞｗ
164:名前は開発中のものです。
09/02/07 01:48:10 hO/vsQBF
>>146
もれなくリストに登録しておいた。
>>121
もしBがAに殺された時、「うわああああ！」って悲鳴を上げるなら、
その悲鳴を上げる動作はBでやるべきだと思う。
AがBを殺した時、「やっほお！！」って喚声を上げるとしたら、それはAが行うべき内容だろう。
シーン（あるいは調停者）がやるべきことと言ったら、Bに対して「お前はAに殺された」ってメッセージを送ることと
Aに対して「お前はBを殺した」ってメッセージを送ること。
なんかややこしくなってきた。
皆えらいわ。
165:名前は開発中のものです。
09/02/07 01:48:40 XPRCk6pD
>>158
今、攻撃判定用「不可視」オブジェクトXって言ってるのだから、
弾をXにしてしまうと、弾が不可視になって困る。
弾が飛ぶってのなら、弾は普通のクラスにすべきだろう。
で、弾と雑魚敵Bの間で攻撃判定用不可視オブジェクトXをやり取りする・・・と。
なぜインターフェイスでやらないのか。攻撃判定用オブジェクトとか馬鹿げてるよ。
166:名前は開発中のものです。
09/02/07 01:58:57 lLkuERdr
>>162
>オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
基本的にはそうだと思ってるし、そうでなければおかしいと思ってる
第一、お前が書かない処理はどうなるんだ？
プログラマならこれが答えられなければダメだろ？
それとお前がしてるのはあくまで仕様の話であって設計の話ではない
決まっていない仕様をむりやりプログラムの仕組みで解決しようとしている
必ずすべての組み合わせ分の関連を把握するべき
その上で共通な処理を共通であるように書いたらいい
（デフォルトを「何もおきない」としたら何も書かなければいい）
ちなみに俺はオブジェクトごと必ず関連をすべて書き出している
雑魚敵Ａｘ雑魚敵ＢがいたとしてＡのステータスが３種類、Ｂのステータスが２種類だとしたら
Ｂ１ Ｂ２
Ａ１ Ｓ１ Ｓ２
Ａ２ Ｘ Ｘ
Ａ３ Ｘ Ｘ
Ｘ はなにもおきない
Ｓ１は爆発
Ｓ２は押される
とかねｗ地道にｗ実際はもっとでかくて多いぞｗゾッとするぐらいな
例えばステータス１から２にうつるときのステータス１－２が問題になったりねｗ
書き出してるっていってもそこまで明確でもないんだよね、それでも見える分ぐらいはやるべきだと思ってる
167:名前は開発中のものです。
09/02/07 02:00:43 NuBn44S3
>165
不可視ってつけたのはちょっと余分だったかもな。別に可視でもいいんだ。STGの場合は、
弾という可視の攻撃判定オブジェクトを介して敵と自機が攻撃しあってるわけだ。
例えば格闘ゲームでパンチなりキックなりするばあい、攻撃判定の瞬間だけ拳や足先に
不可視の攻撃判定オブジェクトを作るというのはよくやること。この場合は、その攻撃判定
オブジェクトに『威力』なり『方向』なりの属性を与える。攻撃を受ける側は、その『威力』なり
『方向』なりを攻撃判定オブジェクトが当たった位置と一緒に見て、それぞれのダメージモーションを
再生したりダメージ処理に移行する。
波動拳（のような何か飛び道具）なら、可視の攻撃判定オブジェクトになるだけ。
スクリューパイルドライバー（のような何か近接巻き込み方攻撃）なら、巻き込み範囲を持つ不可視の
攻撃判定オブジェを作って、それにそれぞれへのコールバックを持たせる。当たったらコールバックを
よんで攻撃側・被攻撃側それぞれに対してモーション発動なりなんなりをする。
168:名前は開発中のものです。
09/02/07 02:00:43 cn84NiHO
>>165
＞不可視
あ、この部分は見落としていた
>>152は「一瞬で目標に到達するレーザーみたいな攻撃（視覚効果なし）」
を想定してたのかな
169:名前は開発中のものです。
09/02/07 02:02:12 NuBn44S3
>166
ガンバレw
努力の人はさすがにすごいと思うよw
学習できない無能はもっとすごいと思うけどねw
170:名前は開発中のものです。
09/02/07 02:03:15 XPRCk6pD
>>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();
}
とかすれば処理は纏められるだろ。
で、どう纏めるかは問題ではなく、これをどこに書くかが問題なんだ。
171:名前は開発中のものです。
09/02/07 02:04:03 cn84NiHO
>>167
格ゲのAABB当たり判定か。把握
172:名前は開発中のものです。
09/02/07 02:06:52 NuBn44S3
>170
で、どこに書くの？
間にオブジェクトを介在させる場合は、書くべき場所はひとつしかないけどね。
173:名前は開発中のものです。
09/02/07 02:15:06 cn84NiHO
>>166
＞ Ｂ１ Ｂ２
＞Ａ１ Ｓ１ Ｓ２
＞Ａ２ Ｘ Ｘ
＞Ａ３ Ｘ Ｘ
＞
＞Ｘ はなにもおきない
＞Ｓ１は爆発
＞Ｓ２は押される
あれ。当たり判定表はアリだと思うが…
174:名前は開発中のものです。
09/02/07 02:26:27 XPRCk6pD
>>172
シーンクラスが良いのではないかということになってる。
>>167
オブジェクトを作るのは、インスタンスを複数にするためであって、
処理を纏めるためではないと思うぞ。
175:名前は開発中のものです。
09/02/07 03:15:44 cn84NiHO
>>174
シーンが肥え太る？ゲームエンジン（神）が肥え太ってんだよ
肥え太ったゲームエンジン（神）が作りしシーン
その中での現象に関して肥えた神にお願い・お祈り・お伺いするためのインターフェース
これをシーンが提供してる。それだけのことだ
神と交信するためのインターフェース（シャーマン、イタコ）は色々ある
物理エンジンにしかアクセスできないインターフェースとか
どのインターフェースを使えるかはゲームオブジェクト（アクター）によりけり
あとおまえやねうらおじゃない？睡魔に耐えてたらESPが冴えてきたぞ
外れてたらごめんね。もし当たってたら一言言わせろ
あんたさー知りもしない昔の話を捏造してペラペラしゃべってる暇あんなら
一次情報にアクセスしてきっちり裏取れよな
あれじゃネット発のタスクシステム都市伝説の怪文書がまたひとつ増えただけじゃん
松○とドングリだろ。悔しくないのか？足使えよ足
ネットとか２ちゃんで怪情報かき集めて本書くな
176:名前は開発中のものです。
09/02/07 03:17:17 cn84NiHO
アンカーミスだ。>>134な
ばいばい
177:名前は開発中のものです。
09/02/07 03:31:08 dNGvkNLd
>>175
横レスですまんが、やねうらおに関しては、
遠藤さんとも面識があるみたいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
吉村さんとも知り合いみたいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
岩谷さんが取り上げるぐらいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
彼は2chなんか端っから相手にもしてないだろう。
自分の説が正しいと思うなら是非どこかのブログで
今回の記事に反論してみてくれ。俺はそれを楽しみにしている。
178:名前は開発中のものです。
09/02/07 03:42:55 lLkuERdr
今回の記事は魅力ないでしょうよｗ
前スレでタスク信者が詰まってたところ全部無視だものｗ
179:名前は開発中のものです。
09/02/07 03:46:47 dNGvkNLd
俺はweak_ptr使って実装するっての一つにしても為になったがな
まあ、あの記事から何も学べない奴は学習能力がアレなんだろうな
180:名前は開発中のものです。
09/02/07 03:56:42 zBw0rbcy
ID:lLkuERdrは10年以上プログラムやってて( >>123 )、
C++が使えない( >>125 )ってぐらいだから、まあ、本当にアレなんだろうけどな・・
181:名前は開発中のものです。
09/02/07 04:20:56 lLkuERdr
>>179-180
あんたが複数ＩＤを使えるのはもうわかってるよ
このスレのはじめのほうでもやってただろ？
でもいいの？
あんた自分より賢い人には絶対にたてつかないクズじゃん
俺なんかに噛み付くと反撃が痛いんじゃない？ｗ
182:名前は開発中のものです。
09/02/07 04:26:54 XPRCk6pD
weak_ptr とかはもうすでにみんなやってるでしょ。
そこはそんなに。本質とは違うというか。
別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。
全般にわたって高速化のことしか書かれていないが、そんなの正直どうでも良い。
ってのが感想。
183:名前は開発中のものです。
09/02/07 04:52:05 dNGvkNLd
>>182
> 別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。
それは、何かweak_ptrを勘違いしてそうだな・・。
OnDeleteTaskのときに、被参照ポインタをどうやって無効にするんだ？
184:名前は開発中のものです。
09/02/07 04:55:04 dNGvkNLd
>>181
> あんた自分より賢い人には絶対にたてつかないクズじゃん
それは、俺を他の誰かと勘違いしてねーか
俺はC++わからないとか、デザパタわからないとか、
そんなド素人と話しても得ることがないから、そういう奴とは話さないだけだよ
185:名前は開発中のものです。
09/02/07 05:10:37 XPRCk6pD
>>183
class my_task : public task
{
task *m_ptask1;
public:
virtual void OnDeleteTask(task *ptask)
{
if(m_ptask1==ptask){ m_ptask1=NULL; }
}
};
186:名前は開発中のものです。
09/02/07 05:15:04 dNGvkNLd
>>185
ああ、言わんとしていることはわかったし、あんたはまともなプログラマに属すると言えるとは思うが、
そのコードだとオブジェクトの削除はO(N^2)になるよな。
俺の現場ではそんなコードは全然現実的じゃないんだが。
あんたは本当に数万オブジェクトの出てくる規模のゲーム書いたことあるの？
187:名前は開発中のものです。
09/02/07 05:18:34 XPRCk6pD
ただ、これらの話題で絶対出てくるのが、
オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。
188:名前は開発中のものです。
09/02/07 05:20:49 dNGvkNLd
もちろん185の実装は別に間違っちゃいないので、俺の183は発言を撤回する。
185があまり良くない実装だと理解した上で確信犯的にやっているんだろうから。
189:名前は開発中のものです。
09/02/07 05:24:50 dNGvkNLd
>>187
> オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。
(そういう議論が発生するのはわかるが)それは、変じゃないだろう。
被参照ポインタの無効化というのは、そもそもそういうものだから。
190:名前は開発中のものです。
09/02/07 05:43:13 XPRCk6pD
>>186
まぁ10000も出すとなぁ・・・
ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
つーか、10000もオブジェクト出すって、何のゲームよ。
191:名前は開発中のものです。
09/02/07 05:54:06 dNGvkNLd
>>190
> ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
weak_ptrと同性能のものを自前で書くだけでも結構大変だと思うがな。
少なくとも現場のプログラマがやるのは時間の無駄で車輪の再発明以外の何物でもないと思うのだが。
> つーか、10000もオブジェクト出すって、何のゲームよ。
いまどきの3Dのゲームでは、足や手のパーツごとに接触判定を持っていて、それぞれのパーツが
独立していて、それぞれがC++のオブジェクトになってたりするのだが。
192:名前は開発中のものです。
09/02/07 06:30:12 XPRCk6pD
いや、ま、どういうか。
再発明だろうがなんだろうが、あまりどうでもよくて、
要するに、そういうところで困ってる人はいないだろうと。
余談だが、
そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。
昔weak_ptrのようなものを使ったコードも書いたことがあるが、釈然としなかった。
だって、lock出来るときと出来ないときでコードが分岐するなんて、変だ。
そういう仕組みに頼ってると、オブジェクトの所有権がどこにあるのかわからないコードになりがち。
オブジェクトは作ったやつが削除すべきという結論に達したが。。
193:名前は開発中のものです。
09/02/07 06:46:43 dNGvkNLd
>>192
> そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。
そんなことはない。
シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
子分は親分のポインタを保持していてはいけないのか？違うだろ？
そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。
194:名前は開発中のものです。
09/02/07 06:49:26 dNGvkNLd
>>192
> オブジェクトは作ったやつが削除すべきという結論に達したが。。
これも全くのでたらめ。
シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
ボスはザコより先に逝っちまうことがあるだろ。
ザコから参照されているからボスはいつまでもオブジェクトを解放しないのか？違うだろ。
オブジェクトの所有者は、そのオブジェクトを生成した奴(ボス)にあってはいけないんだ。
もしそう設計しているならそれは設計上の誤り。
195:名前は開発中のものです。
09/02/07 07:11:16 XPRCk6pD
>>193
>シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
>子分は親分のポインタを保持していてはいけないのか？違うだろ？
>そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。
親分も子分も、シーンクラスが管理すればよい。
>シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
>ボスはザコより先に逝っちまうことがあるだろ。
なぜボスがザコを生成する必要がある？
シーンクラスがザコを生成、削除すればよい。
Cのmallocにはweak_ptrのような仕組みは用意されていないが、世のプログラムはちゃんと動いている。
windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
なのにゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
だけど止めはしない。weak_ptrをつかってゲームを書いてみるといい。きっと後悔するから。
196:名前は開発中のものです。
09/02/07 07:23:17 dNGvkNLd
>>195
> 親分も子分も、シーンクラスが管理すればよい。
うわ。それはひどい。なんか、またド素人と話している予感。
子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
どんな依頼コードを書くの？それ書いて見せてくれないか。
> windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。
197:名前は開発中のものです。
09/02/07 07:27:41 Smy/5DJP
シューティングでボスとザコが居て、ボスとザコが何故か紐で繋がってたとする。
紐の管理はボスとザコのどちらですべきか？
答えはどちらでもなく、
ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。
198:名前は開発中のものです。
09/02/07 07:28:38 dNGvkNLd
>>195
> ゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
「ゲームではweak_ptrに頼らざる得ない」なんて俺は言ってないからな。
weak_ptrを使えば簡単に書けるものを、馬鹿が車輪の再発明したり、weak_ptrを知らないがために
複雑な設計になっていたりすると言ってるだけなんだが。
199:名前は開発中のものです。
09/02/07 07:37:27 dNGvkNLd
>>197
> ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。
まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は？
200:ID:XPRCk6pD
09/02/07 07:40:43 Smy/5DJP
ID変わってしまったけど、俺がID:XPRCk6pDな。
>>子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
>>あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
>>どんな依頼コードを書くの？それ書いて見せてくれないか。
依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大親分クラスを作って
そっちで管理する。
>>何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。
ハンドルは同じ値が再利用される可能性もあるわけで。
201:ID:XPRCk6pD
09/02/07 07:50:35 Smy/5DJP
>>199
>まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は？
好きにすれば？
複数のクラス同士が双方向にコミュニケートするような状況さえ回避できれば、
あとは考えることなんてないね。
202:名前は開発中のものです。
09/02/07 07:55:22 dNGvkNLd
>>200
> 依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大> 親分クラスを作ってそっちで管理する。
まあ、それでも組めなくはないのであんたが実際にゲームを書けないとは
言うつもりはないが、しかし、あんたは、大きなゲームを作ったことがなさそうだな。
オブジェクトが無数に出てきて広大なフィールドを歩けるタイプの
汎用的な3Dエンジンなんかを作れば俺が言ってる意味がわかると思うんだが。
まあいいや。お互い意見が対立しているわけでもなさそうなので、俺はもう寝る。
203:名前は開発中のものです。
09/02/07 08:17:52 lLkuERdr
>>200
俺もシーンクラスに書く
その設計でいいと思うぜ
ID:dNGvkNLdは普通に頭悪いだろｗ
質問攻めしてるけど明らかに予想外の答えにうろたえてるだろｗ
204:名前は開発中のものです。
09/02/07 08:28:02 dNGvkNLd
>>203
C++すら使いこなせないド素人は黙ってな
205:ID:XPRCk6pD
09/02/07 08:57:06 Smy/5DJP
>>202
そういうコテコテしたプログラムも書いたことがあるが、今では間違いだったと考えている。
少し前までは私も「オブジェクトは自立しているべきであり、周りの状況を判断し、自分で行動すべきだ」、
と考えていた。私もまだ若かったし、C++がそういう設計思想であることも手伝って、そういう勘違いをした。
作ってみたらうまくいかず、考えてみたら、オブジェクト同士の関係を見落としていることに気がついた。
ゲームはオブジェクト同士が関係しあって初めてゲームになる。
そこを重点的に記述できないことには楽しいゲームを作ることは難しい。
昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では？
206:名前は開発中のものです。
09/02/07 09:17:54 dNGvkNLd
>>205
> 昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では？
それは、全然的外れだろう。
本当に現場のことは何も知らないんだな。
せいぜい同人ゲーでも作ってなよ。
207:名前は開発中のものです。
09/02/07 09:21:58 lLkuERdr
>>206
苦しくなると話の趣旨と違うところだけつまんで
人格批判からレスの全部否定に入るっておきまりのパターンなのなｗ
208:名前は開発中のものです。
09/02/07 09:29:38 dNGvkNLd
>>207
C++すら使いこなせないド素人はこなくていいよ
209:名前は開発中のものです。
09/02/07 10:06:26 iAQtrtU5
c++使わなければどうでもいい話題ばっかだな
210:名前は開発中のものです。
09/02/07 10:18:48 hO/vsQBF
>>192
deleteされたポインタを直接参照しているオブジェクト全てにその旨通知するように設計したいと思った。
>>193
子分::親分からの指令(親分へのポインタ) みたいなメソッド作って、
子分は親分からの指令があった時だけ、親分へのポインタを参照しながら協調動作すればいいんじゃね。
子分が親分のポインタを持つ必要は無いよ。
>>197
ボスと雑魚は紐なんか無視して、それぞれ独立に動いていい。
紐は自分のグラフィックを表示しつつ、ボスと雑魚に対して「これいじょう伸びないよ」的な力(or メッセージ)を与える。
それ以外の点では、紐は普通の登場キャラと同じような扱いで良いと思う
シーンクラスに何か特別なことを書く必要なんて無いよ。
211:名前は開発中のものです。
09/02/07 10:51:31 lLkuERdr
>>210
どっちにしてもシーンみたいなクラスあったほうがいいじゃん
212:名前は開発中のものです。
09/02/07 11:11:23 lLkuERdr
>子分は親分からの指令があった時だけ、親分へのポインタを参照しながら
子分のクラスなんだから子分の処理だけで完結したいと思わないんか？
カプセル化っていうの？
213:名前は開発中のものです。
09/02/07 11:13:45 hO/vsQBF
>>211
うん、あった方が良いと思う。
実際にシーンクラスが何を担当するのかはここに居る人それぞれが全く違うイメージを持ってそうだけど。
214:名前は開発中のものです。
09/02/07 11:47:33 hO/vsQBF
>>212
子分は親分と協調し、親分は子分と協調するのだから、
お互いに通信しあう仕組みは必要で、完全に分離するのは不可能だと思う。
ふと思えば、俺の方法だと、子分が死んだことを親分はどうやって感知するんだって思ったw
215:名前は開発中のものです。
09/02/07 15:40:54 NuBn44S3
>174
おまえはタスク=ゲームオブジェクト派か。
プログラミングなんて、正しく動くなら何やったっていいんだよ。くだらない価値にこだわってると
伸びないぞ。
216:名前は開発中のものです。
09/02/07 16:25:49 21jTa7Aw
シーンクラスって作る価値があるのかね
シーンってメニューやスコアやRGPならフィールドや戦闘なんかのことだろ
一つのゲームに必要なシーンなんて十もないんじゃないか
そしてそれぞれのシーンに共通点なんてほとんどない
共通しているのはデータ取得メソッドみたいなのだけ
各シーンは遷移するけどstateパターンを適用しても
メリットはほとんどない
そんなどうでもいい部分を考えている暇があるなら
うんこでもして寝てしまえ
このうんこ野郎ども
217:名前は開発中のものです。
09/02/07 18:36:36 vE7+xmqT
>>216
2個以上なら作る価値はあると思うがね
218:名前は開発中のものです。
09/02/07 19:39:16 21jTa7Aw
なんでもできちゃうクラスみたいなのを作るからバカになる
つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし
なんでも作ればいいってもんじゃない
二つしかないクラスに親クラス作ってクラスが三つになって
すごいんだぞーとかバカじゃねーの
ばーかばーかしんじゃえ
そんなとこに柔軟性持たせる暇があったらうんこでもしてろ
うんこうんこ
219:名前は開発中のものです。
09/02/07 19:48:57 B+kDbAoq
なんでもできちゃうクラスみたいなのを作るからバカになる
つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし
なんでも作ればいいってもんじゃない
三つしかないクラスを統合してクラスが二つになって
すごいんだぞーとかバカじゃねーの
ばーかばーかしんじゃえ
そんなとこに柔軟性持たせる暇があったらうんこでもしてろ
うんこうんこ
220:名前は開発中のものです。
09/02/07 20:03:53 lLkuERdr
>>214
だからシーンに書けよｗ
221:名前は開発中のものです。
09/02/07 20:08:26 VeizsAKm
シーン。。。
222:名前は開発中のものです。
09/02/07 20:10:02 qvO9PNvj
>>219
でもよ、
「あれもしなきゃ、これもしなきゃ」って状況で、修正作業が発生して、
２回だけでも同じ修正作業をやるのって、憤慨「ウガアーゥアーッ！！」状態にならね？
C++使ってるなら、template（汎用クラス）の親クラスは使わな損々。
223:名前は開発中のものです。
09/02/07 20:22:54 21jTa7Aw
シーンをまたがって修正しなければならない項目なんてほとんどないから
考えるだけ無駄
メニューと戦闘のシーンでの共通項目なんてあるのかよ
メニューと戦闘で使う共通キャラのモーションがおかしいから修正だぜ
サブクラスにしておいてよかった俺天才超天才
なんて場面は百年に一度しかねーよ
どうしても作りたければ似たようなシーンで共通の親クラス持てばいい
何度も言う、そんなくだらないコードを書く暇があるなら
うんこしているほうがまし
うんこをしていると新しいアイデアが生まれると過去の偉人も言ってた
224:名前は開発中のものです。
09/02/07 20:43:13 hO/vsQBF
>>223
>共通項目
それはつまり、タスクシステムのことだと思うよ！
225:名前は開発中のものです。
09/02/07 20:47:22 B+kDbAoq
>>222
？
親分クラスと子分クラス間の通信をシーンクラスが受け持つなら
シーンクラス１箇所で修正済むんじゃない？
>>223
シーンクラス否定したり肯定したり、立場がワカンネ
もしかして否定したいのって「シーンクラス」じゃなくて
「抽象化されたシーンを統一的に管理するクラス」？
226:名前は開発中のものです。
09/02/07 20:47:40 21jTa7Aw
すげぇぜタスコシステム
共通項目がない、なんの関係もなかった複数のオブジェクトを
無理やり関連付けやがった
やべぇな、俺には真似できねぇぜ
227:名前は開発中のものです。
09/02/07 20:48:43 qvO9PNvj
「シーン＝メニューと戦闘」の入出力の具体が不明だが、
ウンウンきばっている段階（＝設計の段階）で、
なんであれ抽象化できる部分はなるべく抽象化しておくんじゃねえの？
期限が決まっている状況であれば、なおのこと、それくらいの安全策は取るよな。
228:名前は開発中のものです。
09/02/07 21:01:07 21jTa7Aw
>>227
一気に食おうとするな分けろ
夏休みの宿題なんてものは毎日少しずつやるもんだ
共通点なんて無理に抽出してもそれはオナニーだ
シーンごとに分けろ、目標を分けろ
メニューだけ作って完成させろ
戦闘だけ作って完成させろ
最後に適当にくっつければいいだけだ
全部同時に作って完成させる能力もないくせに
一度に全てをこなそうとするな
俺らは凡人だから、凡人にふさわしいやり方がある
規模の増大が複雑さのインフレを招くのは常識
それを回避するためにそれぞれの規模を抑えて
できるだけ分離して開発するんじゃねーか
完成した複数のシステムをできるだけ触らないようにしてくっつければ
それでいいんだよ
俺らは天才じゃねーから
スーパー天才のやねうらお連中の言うことなんて聞かなくてもいいんだよ
俺らは凡人だ、凡人には凡人にふさわしいやり方がある
そして余った時間を使って
スーパーウンコタイムを楽しもうじゃないか
存分に
229:名前は開発中のものです。
09/02/07 21:01:45 B+kDbAoq
>>227
そして実装も終盤に差し掛かった段階で唐突に仕様変更が入り
抽象化して見えなくしておいた情報を使うために苦しむんですね
わかります
230:名前は開発中のものです。
09/02/07 21:05:45 qvO9PNvj
>>229
仕様変更に柔軟に対応できるような抽象化を見極めるのもワザのうち。
231:名前は開発中のものです。
09/02/07 21:09:34 lLkuERdr
そんなのするから無駄に時間がかかるんだよ
って俺の１０年以上の経験が言ってる
232:名前は開発中のものです。
09/02/07 21:13:12 B+kDbAoq
>>229
そう、ワザ要るよね
初めてのゲームジャンルとかだとまだワザが足りないから完全には見極め切れない
全く抽象化しないか本当にかるーくしとく位でちょうどいい
233:232
09/02/07 21:14:49 B+kDbAoq
まちがえた
>>230
234:名前は開発中のものです。
09/02/07 21:22:28 21jTa7Aw
どこにでもいるんだよ
将棋やってるのに穴熊を囲うことだけを考えて
大局を見ずに
穴熊が出来たと思ったら既に敗戦濃厚な戦局になっていたという
そういうおばかさんが
タスクシステムにこだわったところで
3Dを出来るようになるというわけではないということを
超天才が身を持って教えてくれた
この教訓を未来に生かそうではないか諸君
そしてうんこを私に
235:名前は開発中のものです。
09/02/07 21:25:18 qvO9PNvj
亀レスだが・・・
>>159
俺も、タスク間通信は、独立した当たり判定モジュール（クラスで実装）に任せている。
でもなあ・・・。
＞関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
＞３０回コピペして終わる程度の使いまわしなら３０回コピペする気でいろ
＞そのぐらいでちょうどいい
言っていることはすごく分かるんだが、俺の場合、共通化する努力は続けているって感じだな。
ゲーム中のキャラの相互作用なんて、大体が抽象レベルでは、似通ったプリミティブな交差判定に落ち着くから、
共通化できるところは共通化しておくと、使い回しが利くんだよな。もちろんキャラの魅力は半減するが。
未出のメンバ構成のプロパティを持つキャラを追加する場合は、新規に作らざるを得ないよね。
当たり判定の共通化を突き詰めたゲームってなんだろな？
一昔前に乱発されたベルトコンベアアクションみたいなものか？
最終成果品としては、単調な作業を強いられるゲームだったよな。
最近の3Dゲーも、相互に影響しあうロジックが単調なのが多いな。
236:名前は開発中のものです。
09/02/07 21:54:35 WyIbglrc
綺麗だと思ったタスクシステムの実装って関数型言語で作られたプログラムくらいしかないな
現行のC++やJavaは言語そのものがスマートじゃないもの…
いくら頑張っても泥臭さは残るし、作った本人が胸を張ってもやっぱり泥臭さは残ってる
アンチがいるのは理想論に近い良い手本がそこらに転がってないせいもあると思うし、あまり邪険にしないでやってほしい
237:名前は開発中のものです。
09/02/07 23:03:54 36NfOdFl
クックック。世の中には手段の為なら目的を選ばないどうしようもない奴がいるんだよ。
諸君。私はタスクシステムが好きだ。
（以下略）
238:名前は開発中のものです。
09/02/07 23:10:25 B+kDbAoq
話題循環に飽きた俺が勝手に今後のスレ行き先予想
1.現状維持
アンチタスクシステム派がタスクシステム派の不備を指摘し続ける。
ずっとアンチのターン。あと10～15年位？（根拠は無い）
2.タスクシステム派勝利
タスクシステムをそのまま維持した上で弱点を補強するような改善策が
どっかからか出てきてアンチタスクシステム派が納得してスレから去る。多分無い。
3.「タスクフレームワーク総合part5」になる
タスクシステムの利点？であるデバッガ等々の外部ツールを必須装備とし、
その作り方を初心者に優しく指南。
利点強化によるごり押しでアンチを一掃。多分無い。
4.「タスク系総合part5」になる
アンチ勝利。part1から欠陥があると指摘され続けても「そこはお前の技術力が足りないせいだ」
的なコメントばっかり続くのを見て初心者が冷めた。
ただ、既存のタスクシステムは捨てるものの、
「タスクシステムもタスクフレームワークもだめぽorz
でもMTフレームワークがあるさ！」
「タスクシステム総合＝task system総合＝タスク系総合だ。文句あっか」
みたいな流れで「タスク」という概念の在り方・使い道を模索する方向に。
マルチコアCPU当たり前になってきてるしね。
5.スレから人がいなくなる
不況で、、、とか、
ゲーム製作より動画製作のがおもしれぇｗ、とか
いちアンチとしては4あたりに行ってくれると気兼ねなく去れるんだ。
っていうかむしろその辺議論したいんだ。
239:名前は開発中のものです。
09/02/07 23:16:17 Smy/5DJP
しかし、タスクシステム自体は描画順の管理という大仕事があるから必要だよなぁ。
240:名前は開発中のものです。
09/02/07 23:22:01 Smy/5DJP
というか、アンチ派はどうやって描画順を管理しているのか。
241:名前は開発中のものです。
09/02/07 23:23:10 Qq/VuJ9k
描画順って何だ
3DならZバッファで終了とかじゃねえの
242:名前は開発中のものです。
09/02/07 23:24:20 dNGvkNLd
>>241
3Dでもエフェクトや半透明は描画順が必要だよ。
あんた、3Dのまともなプログラム、やったことなさそうだな…。
243:名前は開発中のものです。
09/02/07 23:27:28 Qq/VuJ9k
>>242
なるほど把握した
ﾄﾝ
244:名前は開発中のものです。
09/02/07 23:35:33 UFXAc++2
>238
> いちアンチとしては4あたりに行ってくれると気兼ねなく去れるんだ。
素直に『アンチタスクシステム総合スレ』でも立てたらイイジャナイか。
245:名前は開発中のものです。
09/02/07 23:38:11 UFXAc++2
>240
その辺は描画エンジンが描画順を制御するようにしてる。
タスク（というかゲーム内の各要素）の更新順と、それらの描画順は正直関係ない。
246:名前は開発中のものです。
09/02/08 00:29:39 +GgCMkwp
>>245
タスク（というかゲーム内の各要素）と描画エンジンが扱う各要素のクラスは共有？
247:名前は開発中のものです。
09/02/08 00:48:21 9yKZ63FM
>>246
>>245ではないがそんな無駄な仕組みにはしないほうがいいだろ
248:名前は開発中のものです。
09/02/08 01:00:09 buJH1feo
>>238
オレはいち擁護派だが普通に４に行って欲しいね
同じことを続けていれば、なんだっていずれ通用しなくなるのは当たり前
古き良きタスクは穏便に「古典タスク手法」の棚に収めて、新しい合意を作っていけばいい
どう考えても４が建設的だろう
オレがアンチを叩く理由は単に非建設的だからだし
249:名前は開発中のものです。
09/02/08 01:08:11 /7HQNkAm
3Dできるやつでタスクシステム賞賛してる奴っているのかどうかに関心がある
3Dできないレベルの奴がキャンキャンほえても所詮雑魚
サイヤ人とスーパーサイヤ人ぐらいの差がある
3Dでのタスクシステムの実例とやらをこの目でみてみたいものだ
250:名前は開発中のものです。
09/02/08 01:09:52 gynQYFxx
3Dできる奴できない奴とか言ってる時点で・・・
251:名前は開発中のものです。
09/02/08 02:34:19 2s89IpB8
3Dになったところで何ら変わらないよ
252:名前は開発中のものです。
09/02/08 03:03:37 ydU34I03
タスクシステムって決まった定義がないからなぁ…
しかも前提によって最適なタスクシステムは異なる。
シューティングとアドベンチャーで最適なタスクシステムは違うだろうし
携帯とかファミコンレベルのチープ環境と、PCやPS3クラスのリッチな環境とでは最適なタスクシステムも違うだろ。
前提が違うのにたった一個のシステムがベスト！ってのはありえん。
253:名前は開発中のものです。
09/02/08 03:12:20 HPpX5vQi
タコスはやっばりメキシコで食うのが一番だと思う。
254:名前は開発中のものです。
09/02/08 04:05:03 L1xVTjvz
ムーチョス・グラシアス！！！
255:名前は開発中のものです。
09/02/08 04:20:27 g+SgJHl1
>>252
この中の「タスクシステム」を「システム」に置き換えてもまったく意味は変わらない。
ほんと、意味の無い言葉だよ。
256:名前は開発中のものです。
09/02/08 08:34:14 mZ7S8TgR
3Dが全くダメなばかりにいつも後続のガキ共に鼻で笑われてきた2Dオヤジ
2Dオヤジにとってタスクシステムとは、プライドを保つための最後の砦だった
心の支えだった。自己のアイデンティティを投影してまで愛していたんだ
なのに、お前らときたら…
257:名前は開発中のものです。
09/02/08 10:46:39 PqcaRaMD
>>256
2Dやってた世代が現役の現場なんてあんまり残ってないと思うが…
仮に残ってたとしたらやっぱりその世代がタスクシステム周りをやるのが妥当だと思う。
3Dが最新技術だから、ってのではなくタスクシステムは作るのに経験が必要だから。
3D、コリジョン、物理エンジン、AI、etc...はゲームの全体から見たらガワの部分。
ゲームの状態遷移やオブジェクト管理をするタスクシステム的なものはガワではなく屋台骨部分で、
この部分はゲーム毎に最適なものが異なり、設計するのには部分だけでなく全体を見通せるだけの経験が必要。
まぁ、いわゆるメインプログラマーの仕事の範疇。
3Dやシェーダー周りはプログラマの花形っぽくみられるジャンルだから若者には人気なんだけどね。
258:名前は開発中のものです。
09/02/08 11:23:33 9yKZ63FM
そんなもん構築するだけ時間の無駄なんだけどねｗ
259:名前は開発中のものです。
09/02/08 11:32:03 2s89IpB8
そんなもん構築するだけ時間の無駄って思ってる奴は三流なんだけどねｗ
260:名前は開発中のものです。
09/02/08 11:44:16 PqcaRaMD
>>259
まぁ、テトリスサイズのゲームならタスクシステム構築とかしなくても作れるけど
ある程度大きいものだとそれなりの管理システムが無いとなぁ
日曜大工で犬小屋を設計図も柱も無しで作った人が
家やビルも同じように作れる、と思ってるのかもね。
261:名前は開発中のものです。
09/02/08 11:51:17 HiTeQllp
では
３Ｄでタスクシステクを採用している漏れが最強で敬われ存在なのだな
まあ精々がんばりな
３Ｄができないorタスクが理解できない下賤者ども
262:名前は開発中のものです。
09/02/08 12:49:10 9yKZ63FM
>>261
じゃあ、>>12(前スレの>>824付近)からはじまるタスクシステムの欠点についてはどうなの？
タスクシステムなんて使うからバグが増えるんだけど？
263:名前は開発中のものです。
09/02/08 15:04:22 L1xVTjvz
また引数クンかwww
264:名前は開発中のものです。
09/02/08 15:15:51 eFHTuswi
自分が理解できてないことを判断できないやつって、根本的に開発に向いていないよね
265:名前は開発中のものです。
09/02/08 15:20:07 L1xVTjvz
例えば、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点について具体的な解答をしてもらいたいものだな。
266:名前は開発中のものです。
09/02/08 15:32:54 L1xVTjvz
あぁ、もうあと2点。
3. tekiAとtekiBをteki_baseから派生させるのは、是か非か？
4. teki_baseにupdate仮想関数を作成して派生クラスで実装する方式を取らないのは何故か？
もあわせて聞きたいね。
267:名前は開発中のものです。
09/02/08 15:51:32 /7HQNkAm
スーパーサイヤ人が最強だろ、雑魚め、クソが
よくよく考えてみるとクソクソ連呼するDBはなかなか下品だな
十年前に偉大なる将軍やねうおらさまと喧嘩した奴が
3D使いこなしているのを見て、やねうおらというひとは
この十年間何をやって痛んだと疑問に思ったが
そんなことは些細なことだと思った、
科学よりも宗教の方が強い世の中じゃからな
目的目標を欠いた設計論なんてクソの役にもたたぬよ
0.0001ミリの誤差も修正できる神業を極めたところで
家を建てる設計の助けにはならん
268:名前は開発中のものです。
09/02/08 15:54:55 L1xVTjvz
>267
全然最強じゃない。
URLﾘﾝｸ(www38.atwiki.jp)(%E3%83%89%E3%83%A9%E3%82%B4%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%AB)
269:名前は開発中のものです。
09/02/08 16:15:03 gX7P2DSs
>>267
本題に関係ないツッコミで申し訳ないが
科学は宗教の一分野として発生した
これ豆知識な
270:名前は開発中のものです。
09/02/08 16:19:34 9yKZ63FM
>>265
俺、ID:lLkuERdrだからテキトーにこのスレからＩＤとって
まず思想を読んでみてくんない？
271:名前は開発中のものです。
09/02/08 16:20:45 /7HQNkAm
大局話してる最中に細部語り出す奴ってうざいよねー
細部語ってる最中に大局話し出す奴ってうざいよねー
何が言いたいかって言うと俺最強俺超天才
定義を明確にしない限りいくらでも攻撃できるし
定義を明確にしない限りいくらでも逃げつづれられるぜ
タスクシステム最強カルト最強
3Dなんかできなくてもタスクシステムさえあれば
スーパーサイヤ人だ
神の奇跡を信じよ、それがタスクシステムである
3Dはできないけどタスクシステム最強である
272:名前は開発中のものです。
09/02/08 16:27:03 iVlGRjYy
>>242
Zソートすればいいだろ
予めグループ化して描画するのはタスク云々とは関係がないし
273:名前は開発中のものです。
09/02/08 16:28:49 1so7d3Ot
お前ら、人に仕事割り振ってもらわないと、自分では何もできないタイプだろ？
274:名前は開発中のものです。
09/02/08 16:29:22 L1xVTjvz
>270
ok。
クズは失せろ。
275:名前は開発中のものです。
09/02/08 17:04:08 KsHb+JeN
タスクシステムとか気取った物言いしてるからどんな高尚なもんかと思ってみれば、
何のことはねぇ、MediatorパターンとObserverパターンを組み合わせただけじゃねえか、
アホらし。すかしてんじゃねえよ、ぼんくら共が！
276:名前は開発中のものです。
09/02/08 17:06:27 L1xVTjvz
デザパタやタスクを銀の弾丸か何かと勘違いしてないか？
277:名前は開発中のものです。
09/02/08 17:11:51 lbrou4Vq
パスタといえば俺ば明太子パスタが一番好きだな
278:名前は開発中のものです。
09/02/08 17:18:44 +p9NdvYA
ループさせすぎｗ
書いてるの同じ人だろｗ
279:名前は開発中のものです。
09/02/08 17:27:25 /7HQNkAm
この無限ループを味わいたくなければ
タスクシステムなんてわけのわからない幻想は捨て去るんだな
無限ループで苦しむ時間を3Dの勉強に費やせば
ポリゴンの一つもレンダリングできるようになる
やねうおら大先生みたいにわけのわからない長文を書いて
わけのわからないタスクシステムの解説を書くような老後をっ
送りたいならばそれも止めはしない
それも人生よ
タスクシステムはイディオムのようでイディオムではなく
デザインパターンのようでパターンではなく
フレームワークのようでフレームワークではないのだよっ
思い知ったか、このメスブタどもめ
280:名前は開発中のものです。
09/02/08 17:41:19 6h7R5+5k
>>265
少し違う話になるが、複雑な状態をもつインスタンスは外部から状態遷移させると危なくないか?
俺は外部からはメッセージ送るまでに留めて、実際にメッセージ処理して状態遷移するのは、個々のインスタンスに任せる。
これだと処理が1フレーム遅れたり、場合によってはメッセージ捨てられることもあるんだが、それでも外部から状態の詳細隠蔽できる利点を優先してる。
281:名前は開発中のものです。
09/02/08 17:41:21 +p9NdvYA
あなたややねうらお先生みたいにわけのわからない長文を
書くような大人にはなりません。
282:名前は開発中のものです。
09/02/08 17:52:59 /7HQNkAm
やねうらお大先生様は自分の過去を正当化するために恥を上塗りしているだけ
俺はそう思う
ただ長く理解しづらいまわりくどいわけのわからないことを書いて惑わすだけ
定義も何もない、ただそれっぽいことを誰にも理解できないように書いて
適当に権威のありそうなものを付け加えて
ごまかしているだけ、子供のいいわけ、自己保身を計っているだけ
あの人は小説家にでもなればいいよ、回りくどい文章を書いて
1を100に水増しして本を書いて適当に売ってればいいよ
タスクシステム語ってる連中の気に食わない点の一つとして
定義を明確にしようとしない
設計の話だと思って設計の話をすると
急にイディオムの話に切り替えやがるし
それに合わせてイディオムの話をしていると
また急に設計の話に戻しやがる
結局何をやってるかわかってないから、適当に話をつなげるしかないのだろう
自分たちが過去やってきたことを無駄にしたくないという思いが
タスクシステムを正当化しなければならないという
何が言いたいのかというと、つまり私は空腹だということだ
283:名前は開発中のものです。
09/02/08 17:55:52 iVlGRjYy
IGDAあたりがタスクシステムはこういうもの
って定義してくれりゃ…
IGDAってセミナー案内以外何かやってるんか？
284:名前は開発中のものです。
09/02/08 18:54:27 2s89IpB8
やねうらお大先生は、年収数千万の天才プログラマなんだから
ゲー専みたいな馬鹿の集まり、相手にしなくてもいいんじゃね？
285:名前は開発中のものです。
09/02/08 19:28:37 /7HQNkAm
ゲー専みたいな馬鹿の集まりを金づるにしてるから年収数千万なんだよ
俺が気に食わないのはやねうらお本人よりも
それを無自覚に賞賛している信者連中の方
考えることを放棄している
三年毎に取り巻き信者が一掃されてるのが笑える
難しくて凄そうで権威のあるやねうらお大先生の言うことを
理解したような風に賞賛すれば俺も近いレベルの有能プログラマになれるんだ
といったところか、おこぼれクレクレ君
本当に理解してないからメリットとデメリットも知らないし
適用すべき箇所がどこなのかも知らない
だからとりあえず使ってみて、満足して
布教して、さらに満足する
これをこうやったらこうなってここが良くなるってのが全くない
手に入れたぞ、使うぞで完結している
それを自覚できないから、多少難しい観念を理解することはできない
つまり3Dは複雑すぎて手が出ない、又はすぐに挫折する
でも俺優秀俺天才って言いたい、そう他人に思ってもらいたい
その願望をかなえるための夢のシステム
それこそがタスクシステム
男のロマン
巨乳大好き
おっぱい最高
そういうことだ
286:名前は開発中のものです。
09/02/08 19:33:57 /7HQNkAm
ゲー専の扱いがひどいなと思ったので追記しておくけど
ゲー専にも学校ごとに二、三人ぐらいは優秀なのがいるよ
逆に優秀な大学出てても、ろくにプログラムかけないで口だけのもたくさんいる
IPAの岡田くんは最高だがな