5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名前は開発中のものです。:2007/12/04(火) 04:51:53 ID:bGSXJYb0
タスクシステムについての議論、相談、質問、雑談などのスレです

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

331 :名前は開発中のものです。:2008/06/14(土) 23:46:49 ID:ykCKUlgy
>>329
だから、それを表現したいなら
「タスク」じゃダメなんじゃない?
ってのが>>321の言いたいことだろ

332 :名前は開発中のものです。:2008/06/14(土) 23:47:19 ID:ykCKUlgy
>>330
逆に管理できる方法を書いてみたら?

333 :321:2008/06/15(日) 00:20:13 ID:RDtyKsgS
今度は100行超えたwwww
もう夜遅いので中途半端だけどカキコ

>>327
実はその代わりを探すために今日2chを見てたのです。。。

まぁでも、タスクシステム使っててもゲームを作ることはできるので必要なデータはそろっているはずで、
あとはvoid Task::update(void)という過度な抽象化を取り払ってしまうだけで結構おさまりよくなるかなとは思ってます。
グローバル変数使う時点で既にカプセル化も絶縁もできてないし消しても特に悪影響無いかと。

例としてSTGの場合のコードを即興で書いてみます。自分の中でもまだ不明確なので書きながら具体化w

1、まずは処理抜きで、データ構造だけでのゲーム構成要素を洗い出す。
struct {
  uint32_t time_count;
  std::list<Player_t *> players;
  std::list<Enemy_t *> enemys;
  std::list<PlayerBullet_t *> player_bullets;
  std::list<EnemyBullet_t *> enemy_bullets;
} GameObjects;

struct {
  InputDevice input_device;
  std::vector<TextureResource *> textures; //本当はResourceManagerクラスとか作る
  DXGraphicsDevice graphics_device;
} Devices;
(続く)

334 :321:2008/06/15(日) 00:23:24 ID:RDtyKsgS
(続き)
2、データ構造間の関係性を洗い出す。
・Player_tはenemysと座標が重なったら爆発
・Player_tはenemy_bulletsと座標が重なったら爆発
・Player_tはplayer_bulletsを生成する(少なくとも生成タイミングを生成する)
・Enemy_tはenemy_bulletsを生成する
・Player_tはinput_deviceの入力に従って動く。
・enemysはtime_countが規定値になったら画面に出現する(enemysにnew Enemy_t追加でも可)
・...

3、1と2の実装方法を考える。
  カプセル化を念頭にグローバル変数的なアクセスは避ける。
  オブジェクト内で完結する処理はなるべくオブジェクト内で済ませる。
  オブジェクト間の調停が必要なあらオブジェクトの外側、例えばメインループで書く。
  無理に対象オブジェクト内のどれかでやろうとしない。
class Game {
private:
 struct _GameData {
   uint32_t time_count;
   std::list<Player_t *> players;
   std::list<Enemy_t *> enemys;
   std::list<PlayerBullet_t *> player_bullets;
   std::list<EnemyBullet_t *> enemy_bullets;
 } _GameData;
 struct Devices {
   InputDevice input_device;
   std::vector<TextureResource *> textures; //本当はResourceManagerクラスとか作る
   RenderManager render_manager;
   DXGraphicsDevice graphics_device;
 } Devices;
(続く)

335 :321:2008/06/15(日) 00:26:29 ID:RDtyKsgS
(続き)
public:
 void update()
 {
   foreach player (players) {
    foreach enemy (enemys) {
     if (player.hit_test(enemy)) { // void Task::update(void)以外のメソッド使える!
       player.damage_increment(); // void Task::update(void)以外のメソッド使える!
     }
    }
   }
   ...
   foreach player (players) {
    player.update(); // damage_increment()反映、前フレームの入力に従って移動等
   }
   foreach enemy (enemys) {
    enemy.update();
   }
   ...
   foreach player (players) {
    for (int i = 0; i < player.num_of_generate_bullet(); i++) { // void Task::update(void)以外のメソッド使える!
     player_bullets.push_back(new PlayerBullet_t(座標と方向とかショット種別とか), 優先度?); //システム化したい。Iterator? 構造体のリスト渡し?
    }
   }
   foreach enemy (enemys) {
    enemy.update();
   }
   ...
(続く)

336 :名前は開発中のものです。:2008/06/15(日) 00:26:33 ID:fgJN+8Ya
>>330
update() で別インスタンスを参照したいクラスの増加に応じて
対応するグローバル変数と登録削除処理が増えるなんて、
もうやってられないでしょ。

337 :321:2008/06/15(日) 00:30:52 ID:RDtyKsgS
(続き)
   foreach player (players) {
    player.draw(&render_manager);
   }
   foreach enemy (enemys) {
    enemy.draw(&render_manager);
   }
   ...
   foreach enemy (enemys) {
    render_manager.render(&graphics_device);
   }
   ...
   foreach player (players) {
    player.input(input_device); // void Task::update(void)以外のメソッド使える!
   }
   ...
 }
};

こんな感じでいけたらいいなあと。・・・あれ? update()必要ですね。。。
まぁでもvirtual void Task::update(void)=0の実装じゃなくて具象クラスのvoid Player::update(void)なので勘弁して。

おっきな変化点はゲームオブジェクトの外側から「void Task::update(void)以外のメソッド使える!」ってとこです。
うれしいところもそこに尽きます。それだけです。
でもそれだけのことなのに「void Task::update(void)」にしばられてるとグローバル変数使うとか動的キャストでもしないと実現できなかったので
自分的には大発見なのです。なんかGame::update()を見てると関係無いと思ってたデザインパターンとか適用できそうな気がしてきたしいいことずくめ。
(続く)

338 :321:2008/06/15(日) 00:37:24 ID:RDtyKsgS
(続き)
これは蛇足っぽいですが、タスク関係で思いついたので。
・Game::update()にずらずらオブジェクト間にまたがった処理書くの嫌ならforeach1個を1つのTaskとして実装するのもよいかも。
 2の「データ構造間の関係性」の項目1つ1つに相当。
 Taskとして切り出す単位がデータオブジェクトの区切りを全くシカトして処理単位で切り出してるとこがミソ。
 入出力、アルゴリズムが決まりきってればvoid update(void)でも事足りる。
 データ構造はオブジェクト指向で管理、振る舞いはそれ以外の思想で管理と分けるなら我慢できる気がする。UMLも複数の図使うし。
・Game::update()の開始からplayer.update()を呼ぶループより直前までの処理は
 ループ毎に並列に実行可能かも、ループ毎にTask化できるかも、とか考えてくと面白そう。
 ttp://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm とか参考に。

#あと >>321 のcharasはobjsの間違いです

339 :321:2008/06/15(日) 01:50:12 ID:RDtyKsgS
>>329
> >>321はそれちがうってことを言いたいのかなあ。
そうです。

タスクって実は処理するデータの単位じゃなくて処理の単位で区切らないといけないんじゃね?とか
ゲームオブジェクトというデータの区切り方とタスクという処理の区切り方って全く関係ないんじゃね?というのが言いたいことです。

ゲームオブジェクトは構造を、タスクは構造間の振る舞いを規定するということにすると素直に感じられる気がするとか、
ゲームオブジェクトというデータ中心の観点、それからタスクという処理中心の観点というのは
クラス図と状態遷移図みたいに異なる観点であって、クラス図のゲームオブジェクト内に状態遷移図の情報を
きれいに突っ込むの無理じゃねみたいな感じ。
1000行以下のちっちゃい例題プログラム程度なら1状態遷移を1メソッドで表現とか可能かもしれませんが。

タスクは処理区切りという観点で考えると、設計はデータ構造区切りでの分析を先行してやりたいかなぁ、慣れてるし、とか
処理区切り先行でプログラム組み立てるとかって何それできるの? 数学とかLISP方面? 俺無理。
という思考の流れでタスクをゲームプログラムの主軸に据えるのってどうなのよと思い至りました。

>>330
1、グローバル変数が増える
2、グローバル変数を参照する箇所もたくさん増える
3、脳みそパーン
・・・すみません。もう寝ます。

340 :名前は開発中のものです。:2008/06/15(日) 02:01:57 ID:zJaLEBLM
それってタスク限らないんじゃないか。

341 :名前は開発中のものです。:2008/06/15(日) 02:15:26 ID:4um+jjiN
複数パスの処理を明示的に組み立てられるタスクシステム(ライクなもの)を作ればいいんじゃね?
と言い捨て


342 :名前は開発中のものです。:2008/06/15(日) 03:16:28 ID:kCeJLpX+
ここまで読んでも結局よく分かりませんでしたが(頭固くてごめん)、
>>331を元に推察すると
「これまでこのスレでタスクと呼んでたものをオブジェクトと呼びましょう、
それによって実装もこんなに変わりました!」
ってことでしょうか?


343 :名前は開発中のものです。:2008/06/15(日) 03:46:46 ID:fgJN+8Ya
抽象化して具体的な型を失うと、具体的な型に応じた処理が書きにくくなるという
あたりまえのことに気づいた。

本人がそう捉えているかどうかは別にして、そういうことに見える。
データの区切りと処理の区切りの話は、たぶん問題の本質じゃない。

344 :名前は開発中のものです。:2008/06/15(日) 04:22:06 ID:3r3JLp6V
設計についての文句は別にないが、Gameクラスにリストをすべて突っ込んで
「グローバル変数がなくなった!」というのは詭弁ではないか?
タスクシステムでも、リストをひとつのクラスにまとめておけば、
オブジェクトが何種類増えようがグローバル変数増えないじゃん。

つか、全てのゲームオブジェクトをタスクとして作るのなら、
>>321 で言うGameObjectは、種類が増えるたびにリストを増やすんじゃなくて
タスクリストからそのオブジェクトのリストを取得する関数を作るべきじゃないかと思った。
例えばこんな風に。(先にリスト化するにしても、ラッピングはすべきかと)
class Bullet : public Task {
public:
  static const int TARGET_PLAYER = 0x01;
  static const int TARGET_ENEMY = 0x02;
  bool check_target(int target) const {
    return (this->target & target) != 0;
  }
};
void search_bullets(std::list<Bullet *> &list, int target) {
  for (std::list<Task *>::iterator i = tasks.begin(); i != tasks.end(); ++i) {
    Bullet *bullet = dynamic_cast<Bullet *>(*i);
    if (bullet != 0 && bullet->check_target(target)) {
      list.push_back(bullet);
    }
  }
}

std::list<Bullet *> list;
search_bullets(list, Bullet::TARGET_PLAYER); // 自機に当たる弾を取得

345 :名前は開発中のものです。:2008/06/15(日) 13:45:30 ID:rp8a8YLA
>>343
>抽象化して具体的な型を失うと、具体的な型に応じた処理が書きにくくなるという
>あたりまえのことに気づいた。
あるな
こっちの処理のが複雑なのに擬似タスクなんてやってる場合じゃねぇと思う

346 :名前は開発中のものです。:2008/06/15(日) 14:11:00 ID:KmbefDXz
class Bullet : public Task {

347 :名前は開発中のものです。:2008/06/15(日) 14:15:57 ID:KmbefDXz
ミスった

class Bullet : public Task {
}
;
じゃなく
class Bullet : public Sprite, Task
{
}
;
みたいに必要な場合だけMix-inしてみるとか。
たくさんの弾幕が協調して動くみたい処理なら
class CompositeBullet : public Task
{
  list<Bullet*> bullete_list;
}
;
ダメかね?わかりづらい?

348 :名前は開発中のものです。:2008/06/15(日) 16:37:11 ID:9+3p1uWs
原子による世界構造を体言してるだけで
システムとしてはTaskなり大きすぎる抽象性は機能を為さない
不釣合いに広範囲からアクセスされることが大域変数の邪悪性だとしたら
不釣合いに広くをカバーしてしまう抽象性というのも同様に邪悪なんじゃないかね

349 :321:2008/06/15(日) 16:50:12 ID:RDtyKsgS
>>340,343
はい、そうです。今まで気づきませんでした。なんでだろ。

>>341
データ構造が既に別途確立した上での話ならありかと。

>>342
大体そんな感じです。
タスク(Commandパターン?)はデータ構造を記述できない。だからプログラムの大黒柱になりえない。
もっと抽象度下げたデータ構造を記述可能なものを用意してそれを大黒柱にしよう。
そうしたらタスク使わなくてもなんか記述できちゃうからタスクいらないよね、って感じです。

でもデータ構造と処理フローの2柱がプログラムには必要と考えると処理フローの部分に
タスク(というかCommandパターン)を適用可能かもしれません。

350 :名前は開発中のものです。:2008/06/15(日) 18:45:50 ID:n3ZqdSRd
タスクシステムこそがデータ構造であり、リスト構造。

351 :321:2008/06/15(日) 18:47:15 ID:RDtyKsgS
>>344
> 設計についての文句は別にないが、Gameクラスにリストをすべて突っ込んで
> 「グローバル変数がなくなった!」というのは詭弁ではないか?
データは全部引数経由で必要な時に必要なだけ渡すように構成可能だと思います。
具体的には >>335 のplayer.hit_test(enemy)の部分。衝突判定のつもりですが、
敵1体のデータだけが渡されています。その他の必要の無いリスト、Devicesの情報は
渡っていません。常に全情報が公開されてるわけではないので無くなってる(無くせる)と言っていいと思います。

> タスクシステムでも、リストをひとつのクラスにまとめておけば、
> オブジェクトが何種類増えようがグローバル変数増えないじゃん。
タスクシステムでは0にできないと思います。
できたとしても必要最小限の引数渡しができないと思います。
Task::update(Game *)みたいなグローバル変数的なデータの受け渡しが必要かと。
タスクから能動的に情報取りに行くんじゃなくて外部から受動的に情報渡されるのを待つ感じです。
カプセル化できるので結構使い勝手良くなるんじゃないかと思ってます。
まだ思ってるだけで実装確認してませんが。

> つか、全てのゲームオブジェクトをタスクとして作るのなら、
> >>321 で言うGameObjectは、種類が増えるたびにリストを増やすんじゃなくて
> タスクリストからそのオブジェクトのリストを取得する関数を作るべきじゃないかと思った。
確かにその方がリストが1つになってきれいな感じですね。
でも私dynamic_castとか例外とか好きじゃないんです(未サポートコンパイラ的な意味で)。
たとえイベント通知とかで見かけるunionとenumのtypeの組み合わせ的な実装だったとしても、
言語が用意してくれてる静的な型システムという利点を自ら捨てるようなのはあまり好きじゃないです。
よく知らないんですが、もし静的な型システムに替わる保証方法が存在していて、リスト走査の無駄を
許容可能なCPU速度もしくは上司wなら後は好みの問題かも知れません。

352 :名前は開発中のものです。:2008/06/15(日) 20:20:52 ID:fFyG+ObX
もし自機追尾弾とかが必要になったら、追尾弾だけbullet.update(player)とかやるの?
オブジェクトの種類を増やしたらメインループが一気に肥大化しそう。

できれば、新しい種類の敵を作ってもenemy.update(), enemy.hittest(), enemy.draw()
の3つは統一させて、メインループの変更は不要にしておきたいな。
そっちのほうが敵を作るときも処理内容だけに専念できるし、無理してグローバル変数を
削る必要はないと思う。
(グローバル変数にするべきかどうかはよく考える必要はあるけど)

353 :名前は開発中のものです。:2008/06/15(日) 20:24:58 ID:3r3JLp6V
なんでhit_testの引数とupdateの引数を比較してるの?
タスクリストを使ってても、衝突判定関数に渡すのは判定対象のオブジェクトだけだろうし、
>>335のやり方でも、update内で必要な情報は、呼ぶ側からは確定できないんじゃない?
updateのときか、ゲームオブジェクトを作るときかは知らんけど、
struct _GameData への参照、もしくはそこから情報を得るためのインターフェイスが
必要になると思うんだけど。

後半については、「全てのゲームオブジェクトをタスクとして作るのなら」という前提の話だから。
タスクとして作る(極端な抽象化を施す)のであれば動的キャストは避けられないと思うし、
動的キャストを無理矢理避けて、すべてのオブジェクトを別々のリストに入れておくなら、
そもそもタスクとして作る意味がない。
というか、型を静的に判断したいのに、なぜTaskを継承する道を選んだのか……?

354 :321:2008/06/15(日) 21:29:52 ID:RDtyKsgS
ども321です。そろそろななしに戻ります。
最後に、私は「タスクに飛びついて無駄に複雑なコード書いた初心者」で
「なんかおかしくね?まだまだゲーム内容シンプルでつまんない段階なのにプログラム複雑すぎね?」
と悩んで、ごく最近原因はタスクであろうと思い至りました。思い至っただけで何も実装確認してません。
即興でコード片でっちあげましたけど、あれ本当に動くかわかんないです。

ただ、タスクはデータ構造が規定できないというのが弱点なのはいえると思います。
タスクはCommandパターンだとして考えると、Wikipediaの「デザインパターン (ソフトウェア)」に
  1 GoFによる23のパターン
    1.1 生成に関するパターン
    1.2 構造に関するパターン
    1.3 振る舞いに関するパターン
って書いてあってCommandパターンは振る舞いに関するパターンだったので、
生成と構造に関することがらは不得意なんじゃないかと。

「Commandパターンだけじゃねえ、タスク「システム」だぞ! 構造規定も入ってる!」という話でも無い限り、
タスクシステムの他にゲーム用のデータ構造を独自に定義する必要があって、
それらデータ構造間のデータやり取りとタスクというもののすり合わせについても考える必要があるので
無駄に複雑になっているのかと。特にすり合わせの部分の増加分。

つなぎ、振る舞いの部分はマルチCPU対応とかの(俺的)未開拓領域があるのでタスクシステムの生きる道が見つかりそうな気もします。
まぁ、ハードウェアに合わせないといけない低レベル層だとか、独自スクリプト処理系とか独自通信プロトコル処理系みたいな
処理毎の内容は変化しないけど実行順番は変化するという環境では普通に生き残ると思いますが
(タスクシステムがというよりCommandパターンがですが)。

355 :名前は開発中のものです。:2008/06/15(日) 21:32:34 ID:RDtyKsgS
>>347
それで目的の処理が苦もなく実装可能ならありかも。
でもBullet1つで複数のSprite使いたくなった時どうしようとか、
CompositeBulletを複数階層に渡って構築してったらタスクリストの存在意義が薄れてくとか
なんで俺がタスクリストとCompositeBulletの住み分けで悩まないといけないんだとかになりそう。
もしタスクリストに統一するとグローバル変数地獄、
CompositeBulletにPlayerとかEnemy入れてったらタスクシステム廃止と変わらない気がとか。


356 :名前は開発中のものです。:2008/06/15(日) 22:00:54 ID:RDtyKsgS
>>350
こんな感じ?
enum TaskType {
 PLAYER,
 ENEMY,
 BULLET,
 BINARYDATALOADER,
 RES_PIC,
 RES_ANIM,
 RES_SOUND,
 RES_BGMPLAYER,
 ...
};

class Task {
public:
 enum TaskType get_type()=0;
 void update(void)=0;
};

std::list<Task *> tasks;


これは予想外・・・。なんだこれ。
LISPをほんの少し参考にした独自中間コードのインタプリタ+リソースマネジャー?

なぜか異次元という言葉が頭に浮かんだ。。。
これが本当のタスクシステムだというなら
最初にタスクに飛びついたのはまずった気がする。自分の趣味じゃない。

357 :名前は開発中のものです。:2008/06/15(日) 22:25:39 ID:rp8a8YLA
>>352
それって結局メインループで解決すべき複雑性を
個々のオブジェクトに移して余計問題を複雑にしてるだけのような希ガス
各オブジェクトなんかに問題をばら撒いたら転移した癌細胞のごとくどうしようもない
状況になるって直感でわからんか?センス悪いな

メインループを意固地に固定することにこだわる方向は間違っている
そうじゃなくて複雑になるメインループをうまく管理する方向にいくべきだったと俺は思うぞ

>>354
>「なんかおかしくね?まだまだゲーム内容シンプルでつまんない段階なのにプログラム複雑すぎね?」
感がいいな
そのセンスを大事にしたらいいと思う

358 :名前は開発中のものです。:2008/06/15(日) 22:42:25 ID:RDtyKsgS
>>352
> もし自機追尾弾とかが必要になったら、追尾弾だけbullet.update(player)とかやるの?
私なら敵弾全部でbullet.update(player)とやりそう。私もある程度は抽象化したいです。楽だし。
まぁでも、chase_bullet.target_point(player.get_position_center())とかはそれはそれでありかも。
面倒だけどエンバグ少なそう。

> オブジェクトの種類を増やしたらメインループが一気に肥大化しそう。
増えますね。ここがタスクシステム(というかCommandパターン)の出番なのかもしれません。
例えばループごとにタスク1個ずつ作るとか。まだ具体的な対策考えてません。

> できれば、新しい種類の敵を作ってもenemy.update(), enemy.hittest(), enemy.draw()
> の3つは統一させて、メインループの変更は不要にしておきたいな。
virtual void Enemy::update(Player *)=0; みたいな感じですよね?
ありだと思います。

359 :名前は開発中のものです。:2008/06/15(日) 22:56:28 ID:G2pedMq+
>>356
インタプリタはいい線。
TCBなんて用語からするとOSから借りてきた技術だろう。
>4-5

360 :名前は開発中のものです。:2008/06/15(日) 22:57:19 ID:3r3JLp6V
敵はEnemy、弾はBulletからの継承でいいだろ。それは自然な抽象化だと思うが。

>>354
「タスクシステム=Commandパターン」についてちょっと説明してほしい。
GoFでいうなら、Adapterパターンあたりじゃない?

361 :名前は開発中のものです。:2008/06/15(日) 23:00:18 ID:RDtyKsgS
>>353
私は動的キャストと例外は使いません。使い方知らな(ry
静的な型システムの保証範囲広げたいので。
> というか、型を静的に判断したいのに、なぜTaskを継承する道を選んだのか……?
それしかやり方知らなかったからです。
修破離の修の段階でした。今は破の段階?だといいんですが、ほんとかなー

>>357
あざーーっす

#...5年前にゲーム開発を始めて今週ようやくTaskの弊害に気づいたという事実は胸の内にしまっておこう

362 :名前は開発中のものです。:2008/06/15(日) 23:08:49 ID:rp8a8YLA
>>358
メインループを整理する方向でプログラム組んだほうがいいだろ?

ゴジラとメカゴジラがいたとして
それらがぶつかり合ったときの処理は
ゴジラにもメカゴジラにも書いてはダメだろ
ぶつかった後のリアクションは当然それぞれに書くけど

ゴジラとメカゴジラの戦うフィールドなりなんなりでするべき処理であって
ゴジラの処理でもメカゴジラの処理でもない

オブジェクト指向的に考えても戦うフィールド(仮)のサブルーチンにしかならない出来事だと思うぜ

自機、敵、弾、オブジェクト指向ではこんな単位で分けることまでしかやってないっしょ?
戦うフィールドのサブルーチンは
昔のC言語よろしくコツコツ関数化して書かなきゃいけねぇんじゃねぇかなーと思うよ俺は

363 :名前は開発中のものです。:2008/06/15(日) 23:24:10 ID:RDtyKsgS
>>360
Wikipediaを見ながら何となくCommandかなーって思ったからです。
今見るとIteratorもそれっぽい気がしなくもないです。
要はフィーリングです。

#私は上司から「お前は詰めが甘い。突き詰められてない」とよく言われますが
#趣味ならそれでも怒られない。趣味サイコー!

Adapterは戻り値の存在が重要な意味を持つんじゃないでしょうか。Wikipediaぱっと見た感じ。
Commandは戻り値はどうでも良くて、実行したということが重要な感じ。ぱっと見。

364 :名前は開発中のものです。:2008/06/15(日) 23:40:01 ID:azsLMlHb
デザインパターンなんてそのまま当てはまることのほうが稀じゃない?

365 :名前は開発中のものです。:2008/06/15(日) 23:54:37 ID:3r3JLp6V
根拠がないんだったら、それを前提として論を展開するのは止めたほうが良いかと。

366 :名前は開発中のものです。:2008/06/15(日) 23:58:51 ID:rp8a8YLA
>>365
どうせだったら

「デザパタの〜とそこがちがう、だからあの説明の〜はこの部分でおかしい」

って話をしてほしい

367 :名前は開発中のものです。:2008/06/16(月) 01:07:19 ID:HtcJzfTs
>>359
TCBってTask Control 「Block」なんですね。
RAM領域をBlockに小分けして管理しやすくしてると。
異次元からカッコイイ!に印象が変化しました。バイナリアン カッコヨス
C++じゃなくてC言語で書きたい気分。拡張子は*.cで。

こんな感じですよね
・RAM領域は0x00000000〜0x0010000(64KByte)で、
そのうち0x00008000〜0x00100000(32KByte)までをTCB1個あたり1Kbyteを32個で管理したいって時に
下記TCB_Infoを0x00008000に割り当てる。

typedef byte[1024] TCB_t; /* typeとかもっと詳細に定義しとくのかも */

struct {
  TCB_t[32] tcb_vector;
  std::list<TCB *> no_used_blocks;
  std::list<TCB *> used_blocks;
}TCB_Info;

プールするあたり、Flyweightパターンかな。
でもアプリケーション層であるゲームの根幹には置きたくないですね。OSがやればいいのにみたいな。
プロセス管理とメモリの動的確保を1つのシステムでお手軽に実装可能なのはいい感じ。
でもメモリ使用効率は悪いし型システム使えないしで、最初の一歩って感じかな。
私組み込み系なので黎明期の開拓のロマンを感じるし自分でOSの下の層を実装することになったら
最初は使わせてもらうこともあるかもしれないけど、改善の余地は十分あるって感じ。

>>365
デザインパターンの本立ち読みしてがんばれ。フィーリングでなんとかなるはずだ。
俺は寝る。既に明日遅刻の予感がしている。やばい。上司怖い。超やばい。

368 :名前は開発中のものです。:2008/06/16(月) 01:20:06 ID:HtcJzfTs
>>367
リストがRAMはみ出てたwwww
詰めあめぇwww

369 :名前は開発中のものです。:2008/06/16(月) 01:22:53 ID:PSleqKIe
年寄りのスレ流し読みESPレス
>>356
>LISPをほんの少し参考にした独自中間コードのインタプリタ+リソースマネジャー?

違和感の正体が何となく見えてるようね。開発規模に適したコーディングスタイルというものがあり
タスクシステムとか呼んでるそれをまともに運用するには高いイニシャルコストを支払う必要があるのね。
今みたいに出来合いの優秀な統合開発環境も、というかまともなコンパイラもデバッガも機材も無かった
貧弱開発環境時代、そしてマシン語を直接読んでデバッグするような人間が珍しくも何ともなかった時代
↓のようなスタイルは低コストで受け入れられたけどね、今は違うのね
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

15年近く前、マシン語読めて当たり前とかいう時代では既になくなってて、上のようなレガシーな
コードを効率的に運用するためには様々な周辺グッズとかや支援ツールが必要になってた。
ゲームコードコンパイラ、テキスト画面ベースのグラフィカル(笑)なデバッガ、テストツール、
メモリ可視化ツール、非プログラマ向けの様々なエディタ、などなど。そういったものを設計・開発・
テスト・実戦投入・運用した。当時はお金払っても手に入らないものばかりだったので作った。
君らが道端で拾ったタスクシステムとか呼んでるコード断片ね、それ単体だと何の価値もないのよ。
それを生かすのに必須となる支援ツールのセット、統合開発環境、分業のためのワークフロー
そうしたノウハウと組み合わさって初めて意味を成すの

個人製作の趣味者向けに分かりやすく一言で言えば
VisualStudioを素のままで使うつもりなら>>328でやるほうが遥かに小回りが効いて良い。
それを理解したうえでタスクシステムじゃなきゃ嫌だい!ってんならもはやカルトってことで

がんばれ

370 :名前は開発中のものです。:2008/06/16(月) 02:11:14 ID:rSqKWN6I
なんか定義があいまいなまま議論してる気がする

「タスクシステムライクなもの」という言葉を以下のように定義する
・「複数の状態を持ち、状態ごとに別の処理を行える」という特性のあるタスククラスを持つ
・タスククラスから派生した形でゲーム内のほとんどのオブジェクトを実装する
・毎フレーム、存在するタスクを何らかの順序に基づいて逐次実行する
・実行順序や回数に関しては内容に応じて適当に工夫する。
・タスクは親子関係を持ち、親タスクをOFFにすると子タスクも自動的にOFFになる、親子ツリーごと削除のようなことが可能。


371 :名前は開発中のものです。:2008/06/16(月) 02:11:38 ID:rSqKWN6I
を、書きたいこと書く前に投稿しちゃったorz

372 :名前は開発中のものです。:2008/06/16(月) 02:27:29 ID:rSqKWN6I
で、今までどっちかというと>>328風味なプログラム作ってたんだけど、
だんだんクラス作成のオーバーヘッドが重くなってくるから、
ちょっとしたエフェクトのためのクラスとかを作りづらくなってくるのね。

そういう意味では「タスクシステムライクな」構造(>>370)にしておくことで、
規模が大きくなってきたときとか、GUIとスプライトが入り乱れたりとか、
細かい変なエフェクトクラスをいろいろ作る場合には便利なのかなと思ってきた。

(ただし、今のところ処理の実装をスクリプトでやる方向だけど・・・。)

373 :名前は開発中のものです。:2008/06/16(月) 02:30:41 ID:rSqKWN6I
ちなみに、 >>370 の定義の内容だと、
WindowsのHWNDまわりとか、3Dのシーングラフなんかも微妙に似た構造かもしれない。
どっちかというとそっちを参考にしてる度合いが強いので。

374 :名前は開発中のものです。:2008/06/16(月) 02:31:43 ID:I3VGe9XK
>>372
エフェクトクラスのインスタンス生成が重いのなら、そこだけ高速化するべき。
メインループとか外部の構造を変える必要はない。

375 :名前は開発中のものです。:2008/06/16(月) 02:36:11 ID:rSqKWN6I
>>374
すまん誤解させた。
速度じゃなくて、クラス作成の工数のオーバーヘッドね。
ソースツリーのいろんなところをいじくらないとちゃんと動かないという。

376 :352:2008/06/16(月) 03:01:56 ID:hw017bwB
タスクシステム関係ないけど

>>358
そんな風にやってたら、途中で追尾弾追加するためだけに他の敵弾bullet1, bullet2, ...にも
update(player)を追加しないといけなくなるから面倒じゃないかな。
最初から完全に仕様が決まっていればいいけど、俺みたいに気まぐれに作ってるとなぁ。

自機と敵弾とか影響しあうオブジェクトは一部しかなくても、どのオブジェクトも同じ空間に
あってそれぞれが影響しあう可能性はいくらでもあるし…
(ゴジラの処理内容に戦車が関係なかったとしてもゴジラから戦車を見えなくする必要はないし
 ゴジラが気まぐれで戦車を壊し始めたりするかもしれない)
と開き直ってお互いが参照しあえるようにしてます。
ちょうどfield.player, field.enemyListみたいに

>>357
俺はメインループからの関数呼び出しをできるだけ統一させたいって言ってるだけで、
メインループでのupdate(), hittest(), draw()以外の処理を禁止してるわけではないですよ。

377 :名前は開発中のものです。:2008/06/16(月) 03:48:31 ID:PSleqKIe
>>375
エフェクトとは
 エフェクトデータ
  ・必要なメディア(音声、アニメーション、etc)名の一覧(トラック)
  ・再生手続きを記述したタイムテーブル(タイムライン)
 エフェクト再生クラス
  必要なときにリストに再生リストにインスタンス生成&再生リストに登録
  指定されたデータセットを指定された場所で指定された時間に再生
  再生終了したら再生リストから削除してインスタンス破棄

細かい変なエフェクトクラスって具体的になんだ?
ソースツリーのいろんなところをいじくらないと、って具体的にどこだ?

>>328方式で「ソースツリーのいろんなところをいじくらないとちゃんと動かない」
たって、増える余地があるのはせいぜい専用リストの作成と削除の2箇所くらいだ

378 :名前は開発中のものです。:2008/06/16(月) 03:50:31 ID:PSleqKIe
眠くて日本語ぬっこわれてるな

×必要なときにリストに再生リストにインスタンス生成&再生リストに登録
○必要なときにインスタンス生成&再生リストに登録

何はともあれ、いろんなところをいじくる必要がある例としてあげるには
向いてない気がするよ



379 :名前は開発中のものです。:2008/06/16(月) 04:31:23 ID:rSqKWN6I
自分で言い出しといて用語が誤解を与えるのはすまんね・・・

>>372 でエフェクトといってるのは、いわゆる簡単にデータ化できるものじゃなくて、
それぞれクラス化するしかないようなものをまとめてエフェクトと呼んだ感じ。

具体的に挙げろというと案外思い出すの難しいんだけど・・・
たとえばマウスで行動を指示するときのマップ上のインジケータみたいなものとか、
キャラの残像みたいなものとか・・・ まあ、そういった、単純にデータ化できなくて、プログラムの処理が噛んで、
しかも他のものと一緒くたにするにはおさまりが悪いような、そんなもの。

> >>328方式で「ソースツリーのいろんなところをいじくらないとちゃんと動かない」
> たって、増える余地があるのはせいぜい専用リストの作成と削除の2箇所くらいだ

そもそもそれらを「タスク」的なものともとらえていなかったから、
専用の関数を直接呼び出したり、
キャラ用クラスの内部メンバとかにおさまったりもしたわけですよ。

380 :名前は開発中のものです。:2008/06/16(月) 07:41:06 ID:JnidzRuD
>>376
それが意味無いと思う
なんで記述を統一しようとするの?
メインでやるべきことを強引にほかに移してまで
やるいみ無いでしょ

381 :名前は開発中のものです。:2008/06/16(月) 11:48:50 ID:F6aM01P1
>>328
オブジェクト同士の判定はベタで書く必要があるだろうけど、
move() と draw() の呼び出しはそれぞれ一本ずつにまとめられそうな気がする。

全オブジェクト.move();

自機x敵hit();
自機x弾hit();
敵x弾hit();

全オブジェクト.draw();


382 :名前は開発中のものです。:2008/06/16(月) 13:00:35 ID:m0I6lFOP
>>381
まとめようとするのが害なんだって
という話をしてるんだろ

383 :名前は開発中のものです。:2008/06/16(月) 17:32:04 ID:OzKcYXUg
まとめない場合描画順は深度指定で描画ライブラリに任すのだろうか

384 :名前は開発中のものです。:2008/06/16(月) 19:24:10 ID:JnidzRuD
は?
描画順なんてこんな処理に依存してちゃ駄目だろ
drawは登録だけしてソートは後でじっくりやれ

385 :名前は開発中のものです。:2008/06/16(月) 20:39:24 ID:PSleqKIe
>>370
>タスクシステムライクなもの
それはタスクシステムライクではなく、もっと別の、より適切な呼び方があると思うのね。

>・「複数の状態を持ち、状態ごとに別の処理を行える」という特性のあるタスククラスを持つ
FSMの一言で済む

ライクとか擬似とか現代風とかのバリエーションを唱える人間は過去に何人も見たが
どれも新たな俺解釈俺定義俺拡張でしかなく、10レス先にはそんなもの誰も覚えてないのね

386 :名前は開発中のものです。:2008/06/16(月) 21:15:29 ID:HtcJzfTs
>>369
カッコヨス。テラカッコヨス。

387 :名前は開発中のものです。:2008/06/16(月) 22:20:00 ID:HtcJzfTs
>>370
多分こんな感じ?
・バージョン1:動的キャスト使用バージョン
std::list<Task *> tasks;
class Task {
public:
  virtual void get_type(void)=0;

  virtual void update(void)=0;
  virtual void hit_test(Hit_st *);
  virtual void draw(void) {}
  //その他メソッドを具象クラスで定義
};
task_add(Task *);
task_del(Task *);
task_update_all_task();


388 :名前は開発中のものです。:2008/06/16(月) 22:20:55 ID:HtcJzfTs
(387続き)
私はこんな感じのをタスクシステムと思ってた。
・バージョン2:動的キャスト非使用バージョン
struct CommonData {
  InputManager inputmgr;
  GraphicsManager gramgr;
  HitManager hitmgr;
  SoundManager sndmgr;
  SceneManager scenemgr;
  ...
} common_data;
class Task {
public:
  virtual void update(void)=0; //ここでcommon_dataにアクセス
  virtual void draw(void) {}
};
class TaskManager {
private:
  std::list<Task *> tasks;
public:
  add(Task *);
  del(Task *);
  update_all_task();
};

多分バージョン1は言語処理系を参考に、バージョン2はOSを参考にしてるんだね。
おもしろす。
でもバージョン1は既にCが、バージョン2はWindowsなりフレームワークなりが既にあるんだから
わざわざ自分で独自スクリプトもしくはPCエミュレータを作る必要無いよね。
周辺知識は付くけどゲームの完成には寄与しないよ。
..と今、5年間の暗黒時代の経験からくるフィーリングを受けた

389 :名前は開発中のものです。:2008/06/16(月) 22:27:30 ID:PSleqKIe
>>379
>マウスで行動を指示するときのマップ上のインジケータみたいなものとか

いわゆるHMD、視界内に記号をオーバーレイする仕組みと思うけど
記号はゲーム内仮想空間上に存在しない=物体(エンティティ)との「相互」作用ない。
スクリーン上の映像から何らかの作用を受ける

だから仮想空間上のエンティティと同じリストには入れる必要がない
どんな組み方だろうと「他の物と一緒くたにするにはおさまりが悪い」と言える。
マウスカーソルが絡む記号はTerrain::GetFromScreen(スクリーン座標)のように
取得される地形情報を元に表示されるというだけで、他の記号と大差ない

>残像

当該ボーン(ペアレントしたオブジェクト。剣とか)の姿勢情報を数フレーム分保持し
フレーム間の姿勢情報を補間して残像モデル(トライアングルストリップ)の頂点情報を
更新して加算合成表示する何らかの機構のことだとすると
IK同様に割りと頻繁に使うものだからデータ側で指定できるように、例えばボーンや
オブジェクトのアトビュートに残像についての項目を加えたりして、実際の再生処理は
アニメーション再生クラス内に隠蔽されるだろう。
残像はエンティティではないから、仮想空間上のエンティティと同じリストに入れる必要がない
どんな組み方だろうと「他の物と一緒くたにするにはおさまりが悪い」と言え

390 :名前は開発中のものです。:2008/06/16(月) 22:30:11 ID:PSleqKIe
る。

391 :名前は開発中のものです。:2008/06/16(月) 22:34:10 ID:HtcJzfTs
>>372
その道はいつか来た道(5年位かけて)
そしてそろそろ去りたい道・・・

自分がプログラマでコード読み書きが可能なのにスクリプト作りたくなるってのはどこかおかしい。
既存のスクリプトシステム使って、本当にやりたかったことか考え直すのがお勧め。もしくはRubyとか。
それで満足したらラッキー!

でももし「もっときびきび動いてアクション系にも使えるスクリプトシステム作るんだ!」って思ったならば
「もっといろいろ機能削って手抜きして融通利かない特化・劣化バージョンを部分再発明して速度だけは上げるんだ!」っていうのと同じかと。
しかも既存のスクリプトシステムって描画にアセンブラとか駆使してたりするみたいだから追い越すの結構しんどそう。
そもそも追い越すんじゃなくてゲーム作りたいんだし、全然楽になってないと思う。

やっぱ真正面からコード上での対策をどうにか考えた方が良いかと。
そして私にも教えてください!私も知りたいですその対策!!マジで!!!

#「スクリプト作って!」って誰かに頼まれたのならやってもいいかも。
#でも、「お前プログラム作るの遅いし出来もつまんねえから俺が制御書くわ、どいてろ!」って言われたのと同義じゃね?
#「なんでもいってみろ!俺がすぐ実装してやる!」くらい言いたくね? なんかくやしくね?

>>373
「ハード」ウェアに適した構造を参考にすると「ソフト」に動けなくなると思う。
ハード側に合わせたデザインパターン(Commandパターン)って決まりきった処理しかできないと思うよ。

392 :名前は開発中のものです。:2008/06/16(月) 22:43:37 ID:HtcJzfTs
書き込む文章間違えた

>>372
タスクシステムは最初の1, 2ヶ月は結構すいすい設計進むけど、
その後は体調が絶好調の時に少しだけ機能追加ができる程度にまで
作業効率が落ち込む。
お勧めしない。

でも自分はバージョン2でやったんだけどバージョン1はもうちょっとやりやすいのかもね。
3,4ヶ月位はなんとか持つのかも。グローバル変数の弊害の壁まで。
どっちも人海戦術じゃなきゃ小規模なゲームしか作れなさそうだけど。
(作業効率の低さから来る気力の減衰度合い的な意味で)

393 :名前は開発中のものです。:2008/06/16(月) 22:46:17 ID:PSleqKIe
>>373
過去にタスクシステムライクと称する何かをシーングラフ的だと表現した人間がいたが
あれも結局はシーングラフ的ではなくシーングラフそのものだった。
タスクシステムというカビの生えた古のローカル用語を無理やり持ち出す必要性が
微塵もなかったのね

394 :名前は開発中のものです。:2008/06/16(月) 22:54:33 ID:Vsm26JrC
シーングラフとかFSMとか
タスクシステムのパクリ元となる技術もどんどん紹介して欲しい

395 :名前は開発中のものです。:2008/06/16(月) 23:01:28 ID:PSleqKIe
>>387
>>388
それが何でタスクシステムと呼ぶのか分からないんだが。
↓の要件を満たしているのか
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html

>>387>>388はエンティティのリスト巡回UPDATEとか僕のforeachをする機構だと思うが
それが何でわざわざタスクシステムなどというカビの生えた古のローカル用語を発掘して
再利用する行為と絡められるのかが分からないんだ

396 :名前は開発中のものです。:2008/06/16(月) 23:18:51 ID:HtcJzfTs
>>376
自分もきまぐれに作ってるのですが、タスクシステム単体じゃきつかった。
今はこんな感じでどうにかうまくまとまらないものかなぁと考えてます。
class Game {
private:
 Player player;
 std::list<EnemyBullet> enemy_bullets;
 std::list<Gozzila> gozillas;
 std::list<MechGozzila> mech_gozillas;
 ...
public:
 onFrame()
 {
   foreach behavior (tasks) {
     behavior.execute(game_objects);
   }
 }
(続く)
#コード書くと改行制限がががが

397 :名前は開発中のものです。:2008/06/16(月) 23:20:13 ID:PSleqKIe
>>394
パクリ、パクられという話をしてるのではないのねー
GoFの権威や教条を素直に受け入れるだけの度量があるなら、他の権威や教条の産物
計算機科学の分野で公知の技術用語も公平に幅広く受け入れてもいいと思うのね

タスクシステムなんていうカビの生えきったローカル用語にいまさら無理やり存在価値を
見出そうとするのは、何らかのカルトか、単に頭の引き出しが小さいかのどちらかだと思うのね。
総本山ですら既に使ってない廃れた言葉だなんて知ったら信者はきっと発狂すると思うけど
勉学に励む若い子は我に返ってもっと見識を広めていったほうがいいと思うのね

398 :名前は開発中のものです。:2008/06/16(月) 23:20:20 ID:HtcJzfTs
(続き)
 onInit()
 {
   tasks.push_back(new Player_EnemyBullet_Hit(&player, &enemy_bullets));
   tasks.push_back(new Player_Gozzila_Hit(&player, &gozzilas));
   tasks.push_back(new Gozzila_MechGozzila_Hit(&gozzilas, &mech_gozzilas));
   tasks.push_back(new InputPad_Player_FPSBattleScene(&inputmgr->get_pad(), &player));
//   tasks.push_back(new InputPad_Player_Field(&inputmgr->get_pad(), &player)); //切り替えはこんな感じでできたらいいなぁ
   ...
   tasks.push_back(new Player_Render_Draw(&player, &render));
   tasks.push_back(new EnemyBullets_Render_Draw(&enemy_bullets, &render));
   ...
   tasks.push_back(new Render_D3DDevice_Sort(&render));
   tasks.push_back(new Render_D3DDevice_Render(&render, &d3ddev));
//   tasks.push_back(new WaitNextFrame()); //onFrameもいらなくできる!?
 }
}

タスク(というかCommandパターン?Iterator?)が生き残ってるとこがこのスレ的に
おいしい落としどころ

399 :名前は開発中のものです。:2008/06/16(月) 23:23:17 ID:HtcJzfTs
>>395
http://web.archive.org/web/20041009222313/www.hh.iij4u.or.jp/~peto/Games/games_top.html
はなんかIEで見れないので今Firefoxインストール中です。
まだ見てないのです。

400 :名前は開発中のものです。:2008/06/16(月) 23:26:55 ID:HtcJzfTs
明日はさすがにもう遅刻できないので
もう落ちます。明日見ます。

401 :名前は開発中のものです。:2008/06/16(月) 23:29:52 ID:HtcJzfTs
>>397
やっぱりカッコヨス

402 :名前は開発中のものです。:2008/06/16(月) 23:31:05 ID:PSleqKIe
>>399
文字エンコードがshift-jisなのねー
表示→エンコード→日本語(Shift-JIS)で見れるのね

403 :370-373:2008/06/16(月) 23:46:38 ID:rSqKWN6I
>>385
>それはタスクシステムライクではなく、もっと別の、より適切な呼び方があると思うのね。

じゃあどう呼ぶべきかな。Gems漁れば何かあるかな?

>ライクとか擬似とか現代風とかのバリエーションを唱える人間は過去に何人も見たが
>どれも新たな俺解釈俺定義俺拡張でしかなく、10レス先にはそんなもの誰も覚えてないのね

バリエーションというよりは、例のURLの「タスクシステム」でできること、やりやすいことを
少なくとも犠牲にせず、タイプセーフなモダンな環境で実装する、というのが
方向性かなと思う。
ただし、環境全体の高速化があるので、速度面・メモリ面でいくらか妥協するのは問題ないと思う。

そういうものが既に存在するなら是非紹介してほしい。
おそらくちゃんとゲーム作ってるメーカー内ではそれらしきものがあるはずだけど。

404 :名前は開発中のものです。:2008/06/16(月) 23:48:35 ID:7mOquyOO
このスレの空気は、庭先で日曜大工なお父さんが
近所のガチムチ現役大工に相談に行ったら本気で説教されてる感じだな

日曜デザインパターン教室を誰か開講汁

405 :370-373:2008/06/16(月) 23:57:04 ID:rSqKWN6I
>>389
>「他の物と一緒くたにするにはおさまりが悪い」と言える。
当時のシステムでは、「キャラ」「地形」「エフェクト」みたいに、それぞれクラスがあって、
>>379 で書いたようなものはうまくその中に入らなかったんで、
他のクラスのメンバに入ったりとか、独立した関数コールとかになっちゃってたわけだ。

でも、「画面表示を持っていて、処理を持っていて、親子関係がある」
という物体のリストには、案外うまくおさまるのではないか、と。

406 :370-373:2008/06/17(火) 00:11:38 ID:4bQeTGvs
>>391
えっと、スクリプトの話はあまり深くいきたくなかったので括弧で囲ったのね。
まず、スクリプトのVM自体を自作はしないっす。
上のほうで少し出てるけど、タスクの処理をマイクロスレッドで書いたら楽だよねっていうあたりを
追求してみているところです。

ただし、スクリプト・マイクロスレッド特有の書きやすさの点を除けばC++で実現可能なものなので、
ここではそっちの話をしたいなと。

> >>373
> 「ハード」ウェアに適した構造を参考にすると「ソフト」に動けなくなると思う。
> ハード側に合わせたデザインパターン(Commandパターン)って決まりきった処理しかできないと思うよ。

Windowsの上でHWND使って実にさまざまなことが実現されていると思うんですよ。
あと概念として参考にしているだけで、パクっているというわけではないです。
ゲームの実装がもっと簡単になるようにっていうのが方向性です。

どの部分を「ソフト」にするかというのがC++での抽象化の腕の見せ所じゃないですかね。

407 :名前は開発中のものです。:2008/06/17(火) 00:50:27 ID:GN/jFPWe
>>395
ゲームオブジェクトをタスクと捕らえてそれを管理する機構を総称してタスクシステムって呼んでるんでしょ。
そんな風にLogicianLordのタスクシステムにばかり固執してるのはおじさんだけだと思うよ。
皆、ゲームオブジェクトの効率的な若しくは面白い管理方法を探るためにこのスレを見ているのだと思うし、
ただ「タスクシステム」という言葉をさげしむ文章なんか見てもノイズと一緒だし意味ないから辞めてね。

408 :370-373:2008/06/17(火) 00:53:04 ID:4bQeTGvs
>>393
自分もこれまで、「タスクシステム」とか、うぜえ!C++のほうがいいやん!って思ってたほうなんで、
気持ちはわかるんだけど、そこそこ経験積んでからよく見直してみると、
なかなかゲーム特化で工夫されてるなと思うもので。
(ただし、メモリ節約、CPU節約については現代ではそこまでやらんでもと)

なので、「タスクシステム」が結局どういう要素によって構成されていたか、
という考察もなしに捨て去るには惜しい概念だと思うのですよ。
とっくにそれは終わっているというのであれば、どっかまとまった資料が必要かと。

その上で、完全に旧タスクシステムを上回る能力を持つライブラリ・フレームワーク、
もしくはそれを構築するためのノウハウが存在しなければと。

で、まずは >>370 あたりが叩き台にならないかなと。

409 :名前は開発中のものです。:2008/06/17(火) 00:58:39 ID:Y/642oqK
>>408
ならんでしょ。

> ・タスククラスから派生した形でゲーム内のほとんどのオブジェクトを実装する
これやると、基底クラスが超リッチになるのがオチ。一般的には、実装継承せずに
インターフェースを多重継承しといた方が変更しやすい。

410 :名前は開発中のものです。:2008/06/17(火) 01:19:58 ID:GN/jFPWe
前にGems5を立ち読みしてて「コンポーネントベースのオブジェクト管理」ってのがちょっと気になったんだよな。
参考になるかは分からんけど気になる人は読んでみてくれ。
日本だと殆どヒットしないから海外の関連リンクでも張っとくわ。
http://www.google.co.jp/search?hl=ja&lr=&q=%22component+based+object+management%22&start=0&sa=N

411 :名前は開発中のものです。:2008/06/17(火) 01:38:18 ID:MdkHWajA
明日も遅刻しそうなのに頭がかっかして寝られない。

>>406
ほんとごめんなさい。
391は無かったことに、もしくは392の後に括弧つきの蛇足として書いたものとして
受け取っていただけるとありがたいです。

>>403
会社のコードを2chにさらすとか普通道義的にできない。
コードじゃなくて言葉でさわりのヒント出すとか、
批判して初心者遠ざけるよう仕向けるとかしかできないと思う。

412 :名前は開発中のものです。:2008/06/17(火) 01:44:23 ID:MdkHWajA
>>395 (ども、見れました)
オリジナルの存在を知った後ならば1つの歴史を上書きして消すのは忍びないとか、
別の言葉にしようかなと感じるところはある。

でも「タスクシステム」は既に定義された言葉なんてことを知らなければならないなんてことはない。
仕事をする単位の名称としてTask, Process, Job, ...いろいろあるなかでたまたまTaskを選んで、
どこかでみたタスクシステムという名前が「かっこいいから」という理由だけで
俺プロジェクトに採用されても不思議ではない。下のようにスコープが異なる。

ギャラクシアン() {
  タスクシステム は TCBリスト;
  ...
}
俺様ゲームシステムその1() {
  タスクシステム は エンティティのリスト巡回UPDATE;
  ...
}
俺様ゲームシステムその2() {
  タスクシステム は 僕のforeachをする機構;
  ...
}
タスクは仕事Windowsでも「タスク」マネジャーという名前で一般的に聞きなれている。
その聞きなれたことばを使った「タスクシステム」という響きはネーミングとして魅力的。
中身とか別にどうでもいい。あとそもそもギャラクシアンって何?(的な世代)
私がはまったのもリスト巡回UPDATEであって、TCBリストではない。
カルトな人でもいまさら新規でTCBリストにはまりこむ人いない。もう問題ない。

413 :370-373:2008/06/17(火) 02:12:32 ID:4bQeTGvs
>>412
まあ、なんとなくあなたが「タスクシステム」という名前でforeach{ update() } に
妙にこだわっている点が見えたので >>370 を書いてみたわけだけど。

TCBリストが古い手法だというのは認識した上で、
それを現代C++の上で実現する手法の一部として、リスト巡回updateが存在して、
それを含むオブジェクト指向風味の方法を駆使して
旧タスクシステムを含むいにしえの技の持っていたメリットを享受する、そしてデメリットは排除する。

そういう流れの中で話をしたいかな。僕は。

414 :名前は開発中のものです。:2008/06/17(火) 04:01:27 ID:JZDPJ/Qk
>>403
え、ただのゲームループでしょ

>>412
>タスクは仕事Windowsでも「タスク」マネジャーという名前で一般的に聞きなれている。
>その聞きなれたことばを使った「タスクシステム」という響きはネーミングとして魅力的。
>中身とか別にどうでもいい。

うむ。これがタスクシステム厨の実態、本音だろうな。正直なのは評価できる。
タスクシステムというネーミングへのこだわりは中二魂を心地よく刺激するから。
ただそれだけなのだ。お子様の言葉遊びだということが鮮明になるのは良い

415 :名前は開発中のものです。:2008/06/17(火) 04:16:34 ID:fUrGiP0Z
「タスクシステム」という呼び方が気に入らないだけなのか?

416 :名前は開発中のものです。:2008/06/17(火) 04:25:44 ID:JZDPJ/Qk
>>411
会社のコードを2chにさらすのは同義的な問題ではなく
一般的に労働契約の中で秘密保持義務を課しているから。
公知の技術情報をダラダラ書く分には何の拘束も受けない

417 :名前は開発中のものです。:2008/06/17(火) 04:36:03 ID:JZDPJ/Qk
>>415
タスクシステムは、とあるゲーム会社の特定のスタッフ同士だけの固有名詞だった。
具体的な「実装」にわざわざ「名前を付ける」この行為は、例えば自作のコンバータやエキスポータに
「減色くん」とか「モーション平滑くん」とか「圧縮番長」とか「ニ○マ○イザー」とか
「エターナルフォースブリザードシステム」とか命名する程度の遊び心。洒落なんだ。

身内でどう呼ぼうが自由であるし好きにすればよいんだが
何の事前説明もなく公衆の場で「これはエターナルフォースブリザードシステムですね」
とか語り出す人間がいたら頭がおかしい人だと思うのは当然の話だろう

418 :名前は開発中のものです。:2008/06/17(火) 04:37:22 ID:JZDPJ/Qk
×スタッフ同士だけの固有名詞だった
○スタッフ同士だけで使っていた何かの固有名詞だった

419 :370-373:2008/06/17(火) 04:51:23 ID:4bQeTGvs
>>414
>え、ただのゲームループでしょ

リンク辿ってみた?
>>412 の人の呼ぶ「タスクシステム」の話じゃないのでよろ。
それともあなたの言う「ただのゲームループ」は実は相当に洗練されたシステムのことなのか?
だったら詳しく教えてくれ。

420 :名前は開発中のものです。:2008/06/17(火) 04:53:47 ID:ZH96Nhjs
>>417
実装に名前を付けるのが「デザインパターン」なんだぜ。
タスクシステムではなく、○○パターンと名付けてあげれば
みんな納得するかもしれない。

というわけで、俺が名前を考えてあげた。
タスクシステムパターン(笑)

421 :名前は開発中のものです。:2008/06/17(火) 04:56:55 ID:JZDPJ/Qk
ゲームの基本的な仕掛けはFSMの相互作用をシミュレートすることなんだ
仮想空間内に配置されたエンティティ(FSM、自己駆動粒子)同士の相互作用を
固定時間刻刻みの数値積分している

ところで科学技術計算の分野、特に分子動力学の分野では70年代よりずっと前から
近傍分子同士の相互作用を、運動方程式や支配方程式を離散化して適当な
差分スキーム(ゲームならオイラー法とかベルレ法ね)を選択して数値積分することで
分子の振る舞いをシミュレートしたりしていた
その基本的な実装はリスト内の要素を巡回しながら数値積分していくもので
近傍探索コストの削減と並列計算のための階層型領域分割なども昔から行われていた。
ゲームにおける要素は自分の意思で自在に動くという特殊なものだが、巡回しながら
UPDATEしていくという点で分子シミュレータのそれと基本的な構造は同じだ

422 :名前は開発中のものです。:2008/06/17(火) 05:09:18 ID:JZDPJ/Qk
現在ではFSMアプローチの数値解析手法は様々な分野に応用されている
ライフゲームしか思いつかない人もいるかもしれないが、流体、粉体
車の渋滞、大規模災害時の火災、などなど、例をあげればきりが無いが
それらはどれも時間ステップ毎に要素巡回UPDATEしてループする
プログラムでありゲームのそれと基本的に同じだ。FSMの基底に
記述されたインターフェースの仕様も、誰が書いても大差ないものだ

423 :名前は開発中のものです。:2008/06/17(火) 06:01:08 ID:fuXKuiFY
連投規制にかかった

ゲームのそれと酷似した基本構造のソースコードがあらゆるジャンルで日々作られてる。
そうした事実は井の中の蛙にしてみれば無視しても済ませられるどこか遠い世界の話
なのかもしれない。だが、君らのような懸命なるゲーム開発者にとってはどうなのか。
別に他所の分野の流儀に何が何でも批准しろと言ってるのではない。GoFのそれを
知識として受け入れる脳容量があるなら、もう少し他の分野ものぞいてみてはどうかと

>>420
そうだ。そしてGoFのデザインパターンがなぜ通用するかというとそこに権威があるから。
タスクシステムパターンを普及させるにも権威が必要だな。権威による布教がなければ
エターナルフォースブリザードシステムと同じカーストから抜け出すことは決してない。
名無しのタスクシステム厨は権威なんて要らんと強がるだろうが、まぁ強烈なカルト教団なので
信者同士で「普及してる!普及してるよー!」と幸せ回路発動してホルホルするくらいはできるが
その先はない

424 :名前は開発中のものです。:2008/06/17(火) 06:02:06 ID:fuXKuiFY
話はそれるが、技術情報を発信し布教する権威としての日本人ゲーム開発者は少ない。
布教といえばカーマックたんだが、彼率いるID Softwareが公開してるMOD開発用ソースや
フルソース内のコメントに散見される彼ら流の造語の数々は海外MODコミュニティに限らず
広く普及し認知されてる。エンティティ周りのソースを眺めながら参考にしてみてはどうだろうか?

そんなわけでゲームプログラム関連の公知の技術用語の大半は海外発だ。(別にどうとも思わないが)
CEDECで日本人も沢山情報発信してるけど主催してるCESAは各セッションで使われたスライドの
PDFを参加者以外には配布しないし講演者の多くも自らのサイトで再配布することに積極的でない。
彼らは「布教」とか「提唱」することにあまり興味がないのかもしれない。(別にどうとも思わないが)

425 :370-373:2008/06/17(火) 10:32:05 ID:4bQeTGvs
>>421
その例では均質な粒度の物体を扱うことに特化しているように思うので、
ちょっと問題領域が単純化しすぎるのではないか。

>>422
離散シミュレーションとかいう領域のものかな・・・
あれは見た感じ非常にゲームライクな見た目のものだよね。シムシティとかそんな感じで。
そういう意味では、ゲームと同様のシステムが有効に使えるのもありうる。
ただソースコードレベルの実装手法がそこらに落ちてるかどうか?

ゲームでは、「シーン」のような大きな粒度まで扱えるシステムであるべきと思う。
それとシミュレータではGUI的なものは扱うデータの範囲の外かもしれないが、
ゲームではそれらもやはり同じ枠の中で扱えるとベター。

>>424
今ちらっとquakeまわりのソース見てみたんだけど、
ネットゲーだとエンジン側はGUIとかエフェクトとかを無視して実装できるから、
上記シミュレーションと似たような状況ではあるね。
quake2 engine: edict_t(?)  quake3 engine: gentity_t(ゲームエンティティ)
どちらにしてもモンスターとプレイヤーを扱うもの。あとソースはC(not C++)。

今後のゲーム用フレームワークは、ネットワーク化を常に念頭においた構成になっている
必要があるのかもしれないが・・・。

欧米製のゲームで、ボタン・ウィンドウとかインタフェースまわりにファンシーな効果がついてることが少ないのは、
「タスクシステムライクなもの」の不在のせいもあるんじゃないか、と思ったりするわけよ。
まあ、ゲームの本質じゃあないにせよ、日本人は手触りを重視するし。

426 :名前は開発中のものです。:2008/06/17(火) 14:20:10 ID:uHMmvplh
ここはタスクシステムのスレだし、タスクシステムでいいじゃねーか。
外でタスクシステムについて知らんやつに使ったら、スルーされるだけだ。
俺はデザインパターン知らないからスルーしてるがな。


…デザパタ本買ってこよう。

427 :名前は開発中のものです。:2008/06/17(火) 16:13:08 ID:OzqeTbhG
>>426
古いし情報も少ないけど話をあわせるには十分かも。
ttp://www.objectclub.jp/technicaldoc/object-orientation/handbook
1〜3だけあればいいんじゃね。実装例はぐぐるとたくさん出てくる。

428 :名前は開発中のものです。:2008/06/17(火) 22:41:30 ID:MdkHWajA
>>410
ttp://www.radiumsoftware.com/0307.html#030702
ここにそれっぽい記事が

429 :名前は開発中のものです。:2008/06/18(水) 00:40:55 ID:tfU1zVm/
>>414
たしかにゲームプログラムって描画まわり以外は
あんまりきっかりとした名前の付いた技術ってないからね
タイトルがあって公式があって・・・って参考書にでもできそうな
もんにすがりたいのはわかるな

実際はなにもねぇけどなw
ファイルが読み込める、文字列が処理できる、計算式をプログラムで表現できる
とか地味ーで言葉にするのも難しいぐらい小さく当たり前なことが積み重なって技術を構成してるからな
だから、毎日勉強してる奴としてないやつとで差がついたときにその差が表現できない

長年PGやってるやつでもこれがわからない奴をよく見る
だから、よく春になると
「ゲー専卒PGなんか無意味、PCなんか使ったことなくても大卒なら1年で・・・」
とかいう言葉が掲示板で飛び交うけどこれもそんな気がするだけで
いかにゲー専PGであっても積み上げたもんがたしかなら1年そこらで追いつかれることはほとんどない
名称のある技術を一通り教えてすべてを教えた気になってもやはり戦力にはまだならない

つまり、何が言いたいかというと

「あんまり、見えるもんにばっかりすがってても良い事無いぜ」

ってことよ

430 :名前は開発中のものです。:2008/06/18(水) 00:44:09 ID:o+kcLTJo
>>3 のページを見て自分的に見習いたい点、考えるべきと思う点
・小さくて単純な関数をたくさん作ろう
・グローバル変数は使わずにワーク領域を使う(自前メモリ管理のnew, deleteを使うと同義?)
・他タスクへの読み書きの方向性は制限をつけること
・シーン管理、当たり判定、入力管理、得点管理、プレイヤーの死亡判定などもワーク単位を使用する。
 また、同一の実行優先度決定機構の仕組み上でその実行順序を規定。
・タスクリストは抽象クラスのリストでもあるし具象クラスの複数のリストでもある点。
 タイプセーフにどう実現したら良いのか。リスト複数本持つ?
 そうするとリスト巡回アップデートや複数リストにまたがるインタフェースの一括実行はどうする?
・他タスクに影響を与えるタイミングはフラグセットしてタスク巡回完了後に一括反映などする、削除も同様。

改善すればどうにかな点
・ワーク単位によるキャラクタ表示手法の標準化(アニメーション含む描画の簡単化、代償としてワーク領域1つにつきキャラクタ表示1個の強制)

どうだろか

441 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)