シューティングゲーム製作技術総合　２機目

**名前は開発中のものです。** · 04/01/10 21:07

ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り？
それは「シューティングゲーム製作」・・・。

このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK！

ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。

■ 前スレ

シューティングゲーム製作技術総合
http://bbs.gamdev.org/test/read.cgi/gamedev/1056635103/

**名前は開発中のものです。** · 04/02/08 02:23

流れに割り込むけど
SCORE SOLDIER -WINTER FESTIVAL 2004-のソースがいつの間にか上がってたから
見てみたが、すごいな。まさに富豪的プログラミング。
まあちゃんとプレイ出来て面白ければ、中で何してようが関係ないんだけど。

**名前は開発中のものです。** · 04/02/08 02:42

メンテとステージづくりが楽ならどんなプログラミングスタイルだろうがﾏﾝｾｰしちゃうかも

**名前は開発中のものです。** · 04/02/08 03:25

1ステージにどのくらい時間かかる？

**名前は開発中のものです。** · 04/02/08 09:34

>>300
そうそのとおり！

**名前は開発中のものです。** · 04/02/08 09:47

>>301
ぅぉ！データの定義にマクロアセンブラを利用するとは
そんな手があったのか

この書き方は、元々コンシューマの人なのかな？
あまり富豪的に見えなかったのは、俺がPCどっぷりだからか？
しかし、この見事なデータ駆動っぷりは見習わねばならん

**名前は開発中のものです。** · 04/02/08 13:30

プログラミング言語のマクロ機能は字句解析器としてけっこういけるね
使い慣れてる点も強み
実は俺もシューティングじゃないけど同じ方法使ったことが

**名前は開発中のものです。** · 04/02/08 14:56

俺はパーサーまで自力で書いちゃってるけど、
かなり無駄な労力だなあと思うことはあるなあ
テキストファイルから読み込めるようになれば
調整段階までいけばコンパイルしなくていいから便利

**名前は開発中のものです。** · 04/02/08 15:05

現在ゲーム製作のための擬似（マルチ）タスクシステム(クラス)を作っています。

そこで質問なのですが、

１．キャラクタを動かす場合、基本的に

　　各キャラクタのタスクを生成→キャラクタ移動タスク（座標の移動）→
　　　→当たり判定タスク→描画タスク

　　という流れになると思うのですが、
　　当たり判定タスク・描画タスクで、
　　各キャラクタの座標をどのように取得すればよいか悩んでいます。

　　座標は各タスクのワークエリアにもっています。
　　今、思いつくのは、

　　　　１）当たり判定クラス・描画クラスを別に作って、
　　　　　　各キャラクタの座標を登録する形式にして、当たり判定タスク・描画タスクが、
　　　　　　自動的に処理するようにする。

　　　　２）各タスクのリストを順にたどっていき、タスクの属性（敵・味方等）を元に、
　　　　　　各タスクのワークエリアから座標を取得する。

　　です。
　　
　　なにかよい方法はないでしょうか？

**名前は開発中のものです。** · 04/02/08 15:06

２．タスクシステムは、双方向リストで動的にメモリを確保・開放しています。
　　動的確保のため、タスクの生成・削除が多いとメモリが虫食い状態になってしまいます。
　　
　　静的配列を使った方がよいのでしょうか？

　　ただし、静的に確保するためには各タスクのデータ構造は構造体で定義しなくてはいけないため、
　　（クラスだとポインタを使うのと代わりないため）
　　外部から操作される可能性がでてきてしまいます。

　　それを考えると、
　　やはりクラスを使って動的に確保したほうがよいでしょうか？
　　

３．現在、各タスクの登録時には実行する関数を登録しています。
　　関数ではなく、基本となるタスククラスを継承した各クラスを登録したほうが、
　　
　　コンストラクタ・デストラクタを自然に使えるので実装も簡単なのですが、

　　ただし、そうすると、タスク内でタスクをチェンジした場合に、
　　タスクの情報（座標等）を引き継ぐことができません。

　　そのへんがクリアできれば、クラスの利点を生かしたタスクシステムが作れそうなのですが。

長くなってしまいましたが、ぜひ、アドバイスをよろしくお願いします。

**名前は開発中のものです。** · 04/02/08 15:07

２．タスクシステムは、双方向リストで動的にメモリを確保・開放しています。
　　動的確保のため、タスクの生成・削除が多いとメモリが虫食い状態になってしまいます。
　　
　　静的配列を使った方がよいのでしょうか？

　　ただし、静的に確保するためには各タスクのデータ構造は構造体で定義しなくてはいけないため、
　　（クラスだとポインタを使うのと代わりないため）
　　外部から操作される可能性がでてきてしまいます。

　　それを考えると、
　　やはりクラスを使って動的に確保したほうがよいでしょうか？
　　

３．現在、各タスクの登録時には実行する関数を登録しています。
　　関数ではなく、基本となるタスククラスを継承した各クラスを登録したほうが、
　　
　　コンストラクタ・デストラクタを自然に使えるので実装も簡単なのですが、

　　ただし、そうすると、タスク内でタスクをチェンジした場合に、
　　タスクの情報（座標等）を引き継ぐことができません。

　　そのへんがクリアできれば、クラスの利点を生かしたタスクシステムが作れそうなのですが。

長くなってしまいましたが、ぜひ、アドバイスをよろしくお願いします。

**名前は開発中のものです。** · 04/02/08 15:49

私の独断と偏見による意見ですが…

１．に関して。そーいう実装方法は止めたほうがいいかなぁー？
無理に複雑な実装方法を選んでプログラムを複雑にしてるという印象です。
もっとオブジェクト指向的に考えてみては如何でしょうかね。

2，3に関して。最近のPCは性能が良いので動的メモリ確保しても問題ないけども、
気になるようなら、オブジェクトの基底クラスを作って、
operator new/deleteのオーバーライドを考えてみては。

**名前は開発中のものです。** · 04/02/08 15:58

そうそう、タスクループに拘りすぎると、ろくな目にあいません。（ｗ
ゲームを実装するためにタスクループの考え方があるのです。
タスクループ上でゲームを実装するにはどうすれば？とは本末転倒。

**名前は開発中のものです。** · 04/02/08 16:10

>>308
俺も昔同じようなところで悩んだな。
結局、良い方法思いつかなかったけど。
１の当たり判定は、全てのキャラ移動→一括して当たり判定
ってのをしていた。そうしないと変な判定するんで。
２は、結局動的で押し通した。その際になるべく、
虫食いにならないようにタスクの生成順番と
削除のタイミングを注意した。
デバッグ用途も含めて、new/deleteはオーバーライドしてたけど、
タスクごとのオーバーライドはしなかった。
やってもいいと思う。
３は、そもそもタスクの切り分け方を従来の方法と
変えてしまったんで、普通に継承して問題なかった。
実装の仕方が違うと思うのでなんとも。

**名前は開発中のものです。** · 04/02/08 16:18

アドバイスありがとうございます！！

やはり、汎用的なタスクシステムを作るより、
ゲームにあわせてクラスを構成したほうがいいですかね。

ただ、クラスのみを使ってつくるとした場合、
基底キャラクタクラス（敵１クラス）から派生した各キャラクタクラス（敵１－１、敵１－２等）を作るとして、

結局は、グローバルな変数（またはクラス）等で、各派生クラスを管理しなくてはならないですよね？

グローバルな配列の各要素に、各派生クラスを結びつけて、
その配列を元に各派生クラスのメンバにアクセスする等でよいのでしょうか？

**名前は開発中のものです。** · 04/02/08 16:36

そんなとこかと。
俺ならclass World(＝ゲーム世界全体を表すシングルトンクラス)を作って、
そいつにキャラクタを保持させる、という感じですかね。
class World { list<Character*> m_characters[NUM_CHARA_TYPES]; };
特化させてクラス別リストを用意するとか、色々と方法はあるかと。

**名前は開発中のものです。** · 04/02/08 16:40

>>314
俺は管理タスク（クラス）を用意した。
管理タスクからすべてのキャラクタタスクにアクセスする形。
アクセスは、キャラクタタスクの先頭へのポインタだけを持っていて、
あとは、リスト構造（リングバッファ）で辿る形。

**名前は開発中のものです。** · 04/02/08 18:00

みんなアニメーションのデータ構造は
どんな感じにしてる？

**名前は開発中のものです。** · 04/02/08 18:07

アニメーションと一言で言っても
2Dと3Dの違いもあれば、拡大縮小回転や口パクアニメなんかもあるわけで
なんと答えていいか分からんのだが

**317** · 04/02/08 18:26

2Dのアニメーションです

**名前は開発中のものです。** · 04/02/08 18:28

とりあえずグラディウスの時代からある敵弾アニメを例にとってみようか

敵弾オブジェクトごとに、アニメ用カウンタが用意されてる
表示関数で、そのカウンタを使ってアニメ

ここまでは基本だよな
あとは使う言語によるかな。

**名前は開発中のものです。** · 04/02/08 18:34

2Dでアニメーションというと普通のキャラクタアニメーションでそ？
悩むところではないと思うんだけど。

RPGツクールみたいに32*32限定でいいならソーステクスチャを32*32で区切って左上から番号振る。
アニメ順序にあわせてIDを配列で並べて、ついでにアニメ速度とかを定義とかすればいいし。
汎用性持たせるならソース上の矩形ごと並べてしまうとかでもいいし。

**名前は開発中のものです。** · 04/02/08 18:34

テクスチャ1枚に複数絵を用意してUVで切り替え

**名前は開発中のものです。** · 04/02/08 19:03

グラフィックデータ（テクスチャなりサーフェイスなり）は
どこに配置させてどうやって参照させるのが賢いのだろうか…
いつも悩んでます。

**名前は開発中のものです。** · 04/02/08 20:35

>>316

自分もタスククラスとタスクマネージャークラスを作っています。
たしかに、先頭のタスクのアドレスを取得すれば、
リストをたどっていけますが、
どうもいまひとつの気がしてやってませんでした。

ようは、
　１．先頭タスクのアドレスを取得して、
　２．次のリストへのポインタを取得する、を繰り返す
ってことですよね？
結局、外部からタスクの内部を参照するわけであって…。
総当りの上に、書き換えられる可能性もあるわけですよね。
そう考えるとやっぱりクラスを使ったほうがいいのかぁ。

**名前は開発中のものです。** · 04/02/08 20:37

以上をふまえた上で質問です！

もしクラス版のタスクシステムを作ったとしても、
（クラスを登録して、タスクを生成・削除・チェンジするタスクシステム）
座標計算と当たり判定・描画処理を独立してやることを考えると、
（座標計算と判定・描画を同関数内でやると、すりぬけ、が発生するため）
関数版のタスクシステムと同じく
　１．座標情報等のデータをグローバルで持つか、
　２．各クラスのアドレスをグローバルで持って参照するか
しないといけないわけで、
タスクシステムでつくる意味がほとんどないわけですよね？

そう考えると、タスク自身のワークエリアをなくして、
データ類はグローバルな配列で別個で管理するほうがいいんですかね？
単なる関数ポインタを使ったテーブルジャンプみたいになってしまうけど。

**名前は開発中のものです。** · 04/02/08 20:50

ttp://www.interq.or.jp/black/minami-m/

↑にクラスを使った基本的なタスクシステムがありますが、
これって、当たり判定・描画処理を各タスクごとに行ってるんで、
すりぬけや、思わぬ動作を引き起こす可能性がありますよね。

そう考えると、一番いいのは、
各クラスを割り当てた管理配列等を、forループ等で処理したりでしょうか？？

なんかわけわからなくなってきました(T_T)

**名前は開発中のものです。** · 04/02/08 21:12

>>324
書き換えられる可能性ってのはないと思うけど、
そもそも書き換えられて困るから、一括処理な訳で。
リスト構造にしてる意味は、動的生成な訳で、
それをやめるなら、配列でいいかと。
グローバルにする意味はあんま感じないな。
Singletonって意味ならそうだけど。

**名前は開発中のものです。** · 04/02/08 21:23

>>326
それ読んでないけど、処理が終わったタスクとのみ
当たり判定を行っていけば、タスクごとの当たり安定でもできると思う。

**名前は開発中のものです。** · 04/02/08 21:26

>>324-326
迷っておりますなｗ

まず一つ言うが、>>326のタスクシステムはCのタスクシステムよりうんこだから無視せい。ｗ
真にCのタスクをC++に移植するならば、
ワーカークラスのインスタンスポインタとメソッドポインタのペアをリスト化しなきゃならん。

個人的には初心に戻ってオブジェクト指向的に考えることを勧めるよん。

キャラクタはどんな情報をもち、何をするのか？→位置情報を持ち、移動や描画を行う
class Character {
　Vector2 m_pos;
public:
　Vector2 getPosition() { return m_pos; }
　virtual void move() = 0;
　virtual void render() = 0;
};

キャラクタのリストは誰が保持するのか？→ゲームの世界が保持して管理する
ゲームの世界はどんな機能がある？→世界の時間を一定量進めるとか、世界全体を描画するとか
class World {
　list<Character*> m_characters;
public:
　updateOneFrame() { for(...); it->move(); }
　renderScene() { for(...); it->render(); }
};

こんなんでよいではないか、と思うけどネェ。

**名前は開発中のものです。** · 04/02/08 21:28

って当たり安定ってなんだよ orz...

あ、あと、当たり判定に関して言えば、
ソートとかして高速化は必須な気がしてきた。
それ考えると、配列のがいいかもしれないな。
俺はそこまでせずに作るの辞めてしまったけど。

**名前は開発中のものです。** · 04/02/08 21:32

>>327

管理タスクからタスクにアクセスする処理はどのようにしていますか？
参考にさせてください。
先頭タスクのから、順にたどっていくんですよね？
各キャラの移動タスクは独自のワークエリアに座標を書き込むとして、
当たり判定タスク等で、

　Temp = 先頭タスクのアドレス;
　while(Temp <> null);
　 {
　　Work = (EnemyRecord)Temp->WorkArea; //敵パラメータ構造体にキャスト
　　（各種処理）

Temp = タスク->次のタスクへのポインタ;
}

みたいな感じでワークエリアを順に取得して処理してるのでしょうか？

**名前は開発中のものです。** · 04/02/08 21:44

>>328

ですが、各タスクはタスク内で別の関数にチェンジすることを考えると、
タスク内での判定処理等はあまりよくない方法のような気が…。
実行優先度を自ら把握して管理することができれば問題ないでしょうけど。

>>329

用語がいまひとつわかないです(>_<)
実は、Delphiなんです ;>_<;

ゲームのためのシステムの構築となると、
参考資料が少なすぎて…（泣

やっぱりCですかね…。
CはDOSのTurbo C++でとまってます(--;

**名前は開発中のものです。** · 04/02/08 21:48

>>331
管理タスクがタスクにする状況って例えばどんな時ですか？

**名前は開発中のものです。** · 04/02/08 22:01

>>333

316に対するレスだったんですが、

つまり、キャラの移動・当たり判定・描画を例にとると、
タスク処理の流れは、

　　１．移動タスク
　　　　（移動タスクはキャラクタ数分、存在し、
　　　　　各タスクは自分のワークエリアに座標を書き込む）
　　２．あたり判定タスク
　　３．描画タスク

となると思うのですが、
移動タスクでは、ワークエリアに座標を書き込みます。
そして、当たり判定タスク・描画タスクでは、各キャラの座標を参照して処理するわけです。

リンクをたどるということですが、
たぶん、次のようなことですよね？

**名前は開発中のものです。** · 04/02/08 22:03

>>332
ごめん、俺はDelphi全然知らんから文法に関する記述はなんとも言えんわ。
とにかく、タスクは目的ではなく手段なんだから、それに捕らわれてはいけないよん。

**名前は開発中のものです。** · 04/02/08 22:07

各タスク（ＴＣＢ）のアドレスがわからないと、ワークエリアを参照できないので、
　１．管理タスクが、登録されている一番最初のタスクのアドレスを返す。
　２．そのアドレスをたよりに、次々とタスクをたどっていく。

316のような方法にするには、
まず、先頭タスクのアドレスがわからなければ、リストをたどれません。
タスク管理クラスが先頭タスクのアドレスを返す処理をしないといけないわけです。

えーと、つまり、
外部から各タスクのワークエリアを参照するには、リストをたどる必要があるわけで、
そのリストのたどり方の実装の仕方を聞きたかったわけです。

わかりにくい説明ですね(>_<)

**delphian** · 04/02/08 22:15

ややこしいので暫定的に名前つけます(--;

>>335

329のクラスの読み方は、

class Character { //キャラクタークラス
　Vector2 m_pos;　//位置情報を持つ型の変数
public:
　Vector2 getPosition() { return m_pos; } //位置情報を返すメソッド
　virtual void move() = 0;　//オーバーライドして使う。移動メソッド
　virtual void render() = 0;　//オーバーライドして使う。描画メソッド
};

でいいでしょうか？
このクラスを継承して、各キャラクタのクラスを作るんですよね？

**delphian** · 04/02/08 22:18

>>335

class World {
　list<Character*> m_characters;　//各キャラクタクラスのリスト
public:
　updateOneFrame() { for(...); it->move(); }
　renderScene() { for(...); it->render(); }

ここで、for(...); it->move(); 等がわかりません。
delphiとの文法の違いによるせいだと思いますが。
各キャラクタクラスのmoveメソッドをすべて呼び出す、
ということなのでしょうか？

**名前は開発中のものです。** · 04/02/08 22:31

>>337
あと、俺なら、CharacterクラスはTaskクラスから継承させるけど、
この辺は、実装次第かな。

>>338
updateOneFrame() { for(...); it->move();
は、331と同じ意味です。
そもそも331でキャストする必要はないけど。
何か古いタスクシステムに頭が固まっているような。

**名前は開発中のものです。** · 04/02/08 22:32

>>337 は、合ってます。

>>338 は、ごめん、そこ面倒でかなり素っ飛ばしてた。
STL知ってることを前提で書いてたので…。正確にはこんな感じ。

class World
{
　list<Character*> m_characters;

　void moveAllCharacters() {
　　for( list<Character*>::iterator it = m_characters.begin(); it != m_characters.end(); it++ ) {
　　　Character* target = *it;
　　　target->move();
　　}
　}

　void checkCollision() { /* まあ適当に… */ }

public:
　void updateOneFrame() {
　　moveAllCharacters();
　　checkCollision();
　}
};

ちと具体的過ぎてアレだが、俺のプログラムは大筋でこんな感じです。

**名前は開発中のものです。** · 04/02/08 23:03

蛇足だけど、俺はCharacterクラスはTaskクラスからの派生じゃないと思ってるよ。
何故ならタスクとは「誰が何をするのか」ということで、キャラクタは仕事ではなく"誰"の部分。
だからCのタスクリストをC++のソースで移植するとしたらこうなるんじゃないかな。

class Worker { };
typedef void Worker::(*Work)(); // Workerクラスのvoid method(); の形のメソッドポインタの型＝Work

class Task {
　Worker* m_worker;
　Work m_work;
public:
　void execute() { m_worker->(*m_work)(); }
};

class TaskList {
　list<Task> m_tasklist;
public:
　void executeAllTask() { for(...) it->execute() }; //また手抜き
};

タスクリストは仕事を保持しているだけで、オブジェクトのリストは保持していない。
全ての敵キャラや敵弾を参照したいときにタスクリストを使うとおかしな話になるのは、
この辺を混同してるのが原因かなーと思ったり。

**名前は開発中のものです。** · 04/02/08 23:14

その通りなんだが、
その誰が必要ない部分をタスクとして管理するわけよ。
そのための継承。
全てをタスクでするわけではないよ。

**delphian** · 04/02/08 23:16

>>340

ＳＴＬ、、、
見かけたことはありますが、よく知りません。
イテレータってのもよくわからない…。
ちょっと調べてきます。

ようは、つまり、、、
タスクシステムを持ちいらずとも、
リストとクラスを使えば、似たようなことができるんですね！！
しかも、この方法はオブジェクト指向という感じがします。

１．キャラクタークラスを作って、それをオーバーライドして、
　　各キャラクターをつくる。
　　キャラクターごとの動作、描画登録を記述する。
２．管理クラスを作って、
　　そのクラスがそれぞれのキャラクターなどをまとめて管理する。
（各キャラクタの移動メソッドと描画メソッドを呼び出す）

ということですね？

**名前は開発中のものです。** · 04/02/08 23:23

自機弾タスクの優先度を0x1000～0x1FFF、敵タスクの優先度を0x2000～0x2FFFの範囲に生成すると決めておいて

TCB* tama = 一番先頭のタスクのアドレス;
while( tama->prio < 0x1000 ){
　tama = tama->next;
}

TCB* enemy = 一番先頭のタスクのアドレス;
while( enemy->prio < 0x2000 ){
　enemy = enemy->next;
}

while( tama->prio <= 0x1FFF ){
　while( enemy->prio <= 0x2FFF ){
　　GameObject* t = (GameObject*)(&tama->work);
　　GameObject* e = (GameObject*)(&enemy->work);
　　if( hitcheck(t->rect,e->rect) ){
　　　t->hitflag = true;
　　　t->hitflag = true;
　　}
　　enemy = enemy->next;
　}
　tama = tama->next;
}

とか考えているのですがどうでしょうか？>334&>ALL

**delphian** · 04/02/08 23:31

>>344

やはり、そのように優先度で管理する方法が一般的ですかねぇ。
自分のタスクシステムは属性フラグを用意してあるので、
その属性フラグを使って処理することもできます。

このようなタスクシステムだと、
タスクのデータを保持したまま、
別のタスクにチェンジできるのがいいですよね。

>>340 >>341のような方法もオブジェクト指向という感じでいいですが、
チェンジタスクができないのが、唯一の難点のような気がします。

キャラクタごとにクラスを継承して作れば対応できる気もしますが、
どうなんでしょう。

**名前は開発中のものです。** · 04/02/08 23:33

二重ループのenemy = enemy->next;辺りがおかしいですね

それからこの板は古典的タスクシステム＝悪みたいな風潮があるようなので
趣味だけでひっそりやっていくことにします
さようなら

**名前は開発中のものです。** · 04/02/08 23:48

>>342
それは主語がない(クラスに属さない)処理が存在する、ということでいいですかね？

>>343
そういうことだと思ってます。タスクが目的ではなく手段だってのはそういうことです。

>>344
衝突判定中のenemyポインタを保存しといて各弾についてenemyを復元しないと駄目よん。

**名前は開発中のものです。** · 04/02/08 23:51

俺は古典的手法も悪くないと思うけどね。実用になればいいんで。
より直接的である、という古典的手法のメリットと富豪プログラミングの相性も良い。
古典的手法を飽きるまでやるのも入門に向くし。
飽きたら抽象度の高いものでちょっと頭をパズル向けに使って楽をすればよい。

いきなり理想論でたたみかけて初心者を煙に巻くのはオタクさんの悪い癖だ。

**delphian** · 04/02/08 23:53

とりあえず、古典的タスクシステムにしろ、オブジェクト指向のタスクシステムにしろ、
ようは、リストをたどって、各タスク（各クラス）を順に処理していくってことになりそうですね。

それで、当たり判定まではよいとして、描画でどうするべきか…。
描画は、同じく順にリストをたどって各キャラを描画していけばいいと思うんですが、、、
たとえば、当たり判定により自機と敵が衝突した場合、、、

古典的タスクシステムでは、自機タスクなり敵タスクなりを、
当たり判定のときに、チェンジタスクで爆発タスクに切り替えればいいですよね？？
と同時にフラグを立てて、
描画タスクでは、フラグによって描くキャラを変えればいい、んですよね？（＾＾；

>>340
のようなシステムの場合は爆発等に移行するにはどうすれば…

**名前は開発中のものです。** · 04/02/09 00:13

>>345
>>340のは出来ないね。オブジェクトの状態をオブジェクトの内部で保持してオブジェクトの内部でswitch。
>>341のは古典的タスクをC++に移植しただけなのでタスクチェンジできるよ。Task::m_workにメソッドを代入。

>>348
全くどの発言内容もご尤もだと思います。俺オタクだな…
ただこの方法が一番初心者に向いてると思うから書いてるわけで。
タスクってそれ自体はわかりやすいけど実際にコード組むと混乱の種にならない？
(実際に最初の質問の種はタスクから発生してるものだと思うし)

>>349
オブジェクトに衝突したことを知らせるためには、
オブジェクトにOnConflictという関数を持たせればOKだよ。
衝突したら、例えばこんな感じで。
enemy->OnConflict( shot );
shot->OnConflict( enemy );
後は各関数内で適当に状態移行。

**delphian** · 04/02/09 00:14

>>341

あ、これはもしかして、次のようなことですか！？

Workerクラスを継承して、各キャラクタクラスを作る。
Workは各キャラクタクラス内で使う処理メソッド。

これらを含めてタスククラスとする。

Workerクラス内で変数等を宣言、各処理メソッドを必要数分書く。

処理の変更の際には、m_workのみを書き換えれば、
変数等を保持したまま、処理のみを変更できる。

実行、処理の変更等は、TaskListクラスが管理する。

ということでしょうか！？
文法がdelphiと違うので、はっきりとはわからないのですが、
もしかしてそういうことですか！？

**名前は開発中のものです。** · 04/02/09 00:24

>>351
大体合ってる。古典的タスクを使ってるなら馴染みやすいと思うんだけど…
補足するとTaskはTaskListに登録する際にハンドルとして受け取るような感じかな。
んでTaskクラスにsetWorkMethodが付くから処理の変更はTaskクラスでやります。
TaskListクラスにsetAllTaskWorkMethodみたいのを付けてやれば一気にEndとかもできる。

あと>>348にも言われちゃったのでどのやり方がいいとか言うのはやめることにします…

**名前は開発中のものです。** · 04/02/09 00:26

>>346
（･∀･) 人（･∀･)ナカーマ

**delphian** · 04/02/09 00:33

>>352

なるほど！！
クラスを使ったタスクシステムはできないと思ってたのですが、
こんな方法もあるんですね！！
この方法なら、タスクが自分で自殺とかもできそうですね。

2ch.には初めて書き込んだのですが、
詳しく教えていただいて、ありがとうございます！！

Delphiでも応用できそうなので、ちょっと一から作り直してみます！

あ、

＞補足するとTaskはTaskListに登録する際にハンドルとして受け取るような感じかな。

この一文がよくわからないのですが、これはどういう意味でしょうか？？

**名前は開発中のものです。** · 04/02/09 00:41

ややこしいこと言ってしまった…。
list<Task>っていうのはTask構造体(＝ポインタではない)のリストなので、
そのリスト上のTask構造体のポインタをハンドルとして受け取るということです。

**delphian** · 04/02/09 00:45

>>355

なるほど…。

ちなみに、タスクが自殺やチェンジする場合、全タスク実行後に処理したいので、
（削除済みのタスクへの不正なアクセスを防止するため）
その場合、Taskクラスではフラグを立てるだけにして、
TaskListのexecute時に削除等すればよいということですよね！

**名前は開発中のものです。** · 04/02/09 00:51

そういうことになります。

うーん、ぶっちゃけてC#のDelegateですね。

**delphian** · 04/02/09 00:58

>>357

typedef void Worker::(*Work)(); // Workerクラスのvoid method(); の形のメソッドポインタの型＝Work

delphiで↑のような型の宣言ができるかどうか…、
それが一番の問題ですが、これさえできそうなら、
クラスを使ったタスクシステムができそうです！

タスクシステムを使わない、クラスでの処理の構成もわかりましたし、
なんとか、今よりはスマートになりそうです。

また、わからなくなると思いますが、
そのときはアドバイスもらえればと思います。
今日は寝ようと思います。
また、結果報告します！
ありがとうございました！！

**名前は開発中のものです。** · 04/02/09 01:03

１日でスレすすんでてびびった

うちのは >>340風。
case文だらけが嫌になって、stateパターンを導入するも、
溢れ返った状態を記述しきれず泥沼化。
リファクタリングしようと、共通部分を is-a、 has-aでくくりだして、
フラットな状態遷移マシーンから、複雑な階層化状態マシーンに。
把握しきれずに、頭おかしくなりそうになった。

古典的タスクも考慮して組んで見たい今日この頃です。

>>354
Delphi使いはC++も読めると、世界が広がりますよ
考えようによっては、(C++ + Delphi)分の情報が得られるわけで

**名前は開発中のものです。** · 04/02/09 01:11

>>358
すれ違いになっちゃうけど

Delphiだとこうかな？
type
　TWorkerMethod = procedure of object; // クラスの procedure Method(); の形のメソッドポインタ型

　TTask = class
　　FWorker: TWorker;
　　FWork: TWorkerMethod;
　　:

クラスのメソッドへのポインタは、"of object"をつけてね

**delphian** · 04/02/09 07:26

>>360

ありがとうございます！
これで、できそうです！

>>350

追加で質問です。お願いします。
ちなみに、>>341の方法で実装したとして、
各クラスごとにタスクにあたる各メソッドを書くので、
リストへの登録・チェンジができるのは、登録したm_workerとそのクラス内のメソッドのみになるってことですよね？

あ、m_workerの登録を変えれば、他のクラスのメソッドにもチェンジできるのかな？？
でも、それだと、変数が保持されないか…。

各クラスで共通で使うタスク（メソッド）があるときは、各クラスごとにメソッドをかかないといけないわけですよね？

**名前は開発中のものです。** · 04/02/09 12:06

登録クラスとは別クラスのメソッドを呼ぶ必要はありません。
クラスのメソッドは所属するクラスに密接に関わる関数だから。
もし別クラスのメソッドを呼ぶような必要がでてきたのならば、
それはそのクラスにあるべきメソッドではないということです。

それから各クラスで共通に使うメソッドがあるならば、それは基底クラスで定義します。
タスクにメソッドを登録するときは基底クラスのメソッドを登録すれば問題ありません。

余談ですが341の方法は基底クラスの仮想関数を登録すると派生クラスの仮想関数が呼ばれます。
ややこしいので↓を見て実行すると分かりやすいかも。こちらもソースコードがややこしいことになってます…
http://www.emit.jp/prog/prog_cpp0.html

**Delphian** · 04/02/09 12:48

ということは、>>341の方法では、共通のタスクは使えないということですか？

共通の関数を仮想関数として基底クラスに書いたとして、タスクリストに登録ししても、
実際、呼ばれるのは派生クラスの仮想関数ということですか？

つまり、派生クラスの仮想関数を登録するのとかわらない、ってことですか？

共通のタスクを使うにはどうすればいいんでしょうか？

質問だらけですみません(>_<)

**名前は開発中のものです。** · 04/02/09 12:52

基本中の基本だけど、基底クラスで仮想関数を定義しても
派生クラスでオーバーライドしなければ基底クラスの関数が呼ばれるよ。
というか初めから基底クラスで仮想関数として定義しなければ
派生クラスでオーバーロードしても派生クラスの関数は呼ばれないよ。

**Delphian** · 04/02/09 13:57

ぁ、そうですよね。

オブジェクト指向を勉強しはじめて、一ヵ月ならないもので(>_<)

ちょっと混乱してしまいました。
仮想関数をオーバーロードすると派生クラスの関数が呼ばれて、
仮想関数として定義しないと、基底クラスの関数が呼ばれるんでしたよね。

**名前は開発中のものです。** · 04/02/09 14:50

どうでもいいけどオーバーロードとオーバーライドは別物だよ
googleで双方の単語入れて検索してみればすぐわかる

**Delphian** · 04/02/09 15:48

ぁ、すみません、間違えました。

全然違いますね。

とりあえず、帰ったら今日まで覚えた知識でクラス版タスクシステムをつくってみようと思います。

**名前は開発中のものです。** · 04/02/09 18:17

どうでもいいんだけどさ、ドット絵で透明感（背景が透けて見える等）を出すことは出来るの？

**名前は開発中のものです。** · 04/02/09 18:25

>>365
Delphiなら virtualなメソッドを、派生クラスでoverrideつけないで再定義すると、
警告出るからすぐにわかるよ

>>368
半透明つかえないのが前提だよね？
VSYNC同期前提でよければ、抜き色で市松模様にして交互に表示する
もしくは、単純に表示/非表示を繰り返す
同期取らなくてもそれっぽく見えるけど、ちらついてしょうがない

**名前は開発中のものです。** · 04/02/09 19:15

表示/非表示は楽な割に高い効果があるね

場合によっては、赤青非表示　のように
補色と非表示を組み合わせて
輝きのある半透明感を出すのもいい。やりすぎるとドギツイだけになるので注意

市松模様もそのうちやってみてえなあ

**名前は開発中のものです。** · 04/02/09 19:27

点滅は処理落ちに弱い。
素直にアルファ使おうよ

**Delphian** · 04/02/09 19:31

type
TWorker = class
end;

type TWork = procedure of object;

//タスククラス
type
TTask = class
protected
FStat: TStat; //タスクステータス
FPrio: Word; //処理優先度
FDelay: Cardinal; //待機フレーム数
FPrev: TTask; //前タスクへのポインタ
FNext: TTask; //次タスクへのポインタ

FKill: Boolean; //キルタスクフラグ
FChng: Boolean; //チェンジコールフラグ

FWorker: TWorker;
FWork: TWork;
FAttr: Word; //タスク属性（ユーザーが自由に使用できる）

public
constructor Create(Worker: TWorker; Work: TWork);
destructor Destroy; override;
procedure Execute;
end;

**Delphian** · 04/02/09 19:34

>>341 >>372

こんな感じになったんですがどうでしょうか？
タスククラスにワーカークラスを登録する場合、
あらかじめ生成したワーカークラスを引数として渡して登録したほうがいいのか、
それとも引数にクラス型を渡して、タスククラス生成の中でワーカークラスを生成したほうがいいのか、
どうしたらよいでしょうか？

次から次にわからないことが…

**Delphian** · 04/02/09 19:53

class Task {
　Worker* m_worker;
　Work m_work;
public:
　void execute() { m_worker->(*m_work)(); }
};

の部分は

class Task {
　Worker* m_worker;
　Work m_work;
public:
　void execute() { m_worker->(*m_work)(Task); }
};

にした方がいいですかね？
じゃないと、処理メソッドの中で自殺等できませんよね？
でも、処理メソッドの中でdelete Taskとかされたらこまりますよね…

**名前は開発中のものです。** · 04/02/09 20:45

>>374
その必要はないよ。
ちなみに俺も数年前はソレと同じやり方でやってたんだけどね

タスクを登録するときタスクリストでTaskのインスタンスを作るんだけど
そのインスタンスのポインタを登録関数の戻り値としてやって、
それを各ワーカーが保持しておけば何時でも参照できるよ

**Delphian** · 04/02/09 20:52

>>375

実装の段階になると、壁にぶちあたりまくって、
タスクはやめようかと思ってきました（＞＿＜）

登録関数がインスタンスのポインタを返すとしても、
登録したタスク（クラス）の外部では保持できても、タスクの内部では保持できませんよね？

**名前は開発中のものです。** · 04/02/09 21:00

各ワーカーの初期化関数中からタスクリストに登録すれば問題ありませんよ。

**Delphian** · 04/02/09 21:12

>>377

つまり、ワーカークラス（を継承した各クラス）のコンストラクタでタスクリストに登録するということですか？
で、ワーカークラスを生成すると、自動的に自らをタスクリストに登録するような構造にするということですか？

なんか、そういう手間を考えると、やはりクラスとリストを使ったほうがいいのかなぁ…
汎用性はなくなりますけどね…

クラスを使ったタスクシステムや、>>329 >>341のような方法の載った
サイトや本がありましたら、教えてください。
C++でもかまいませんので…

**名前は開発中のものです。** · 04/02/09 21:33

大体そういうことです。回りくどいですがこれには色々と理由があるんで…。
タスクシステムを辞めた理由の中にはそういうのもあります。

具体的に実装方法が載っている本のことは知らないけど、
私はABA Gamesさんとこのゲームのソースコードがいいかなと思います。
shot.cなんか読んだら、なんだ、こんな簡単なことなのか、と思うんじゃないかな。
ゲーム自体も名作なので一押し。

**名前は開発中のものです。** · 04/02/09 21:34

ごめん、プログラムの名前書くの忘れてた。noiz2saです。
http://www.asahi-net.or.jp/~cs8k-cyu/windows/noiz2sa.html

**名前は開発中のものです。** · 04/02/09 21:40

ってCじゃん
>181がC++でやってたみたいだが、消えてるし

**名前は開発中のものです。** · 04/02/10 00:11

俺の実装方法は、タスクを処理の基本パターンとして、
親タスクから小タスクへどんどんタスクを生成して、階層上に回す。
状態はStateパターンの亜種で実装。破壊とかね。
管理は親タスクで、その管理はその親タスクで。
こんな感じの実装だったな。
利点はタスクによる処理の一貫性が得られる点と、
どの階層からでもタスクを再構築できる点。
オブジェクト指向とは相反する。
当然最良の方法でもない。

**名前は開発中のものです。** · 04/02/10 05:03

画面にNOW　LOADINGとかの画像なりを表示させつつ
その間にデータを読み込むというのはどうやったらできますか？

使っている言語はC言語です　よろしくおねがいします

**名前は開発中のものです。** · 04/02/10 05:31

必死で考えて考えて考えたやつ→作れる
すぐ諦めて訊くやつ→無理

383、内容が薄すぎる。
自分で考えたんならもうちょっと建設的な質問ができるはずだぞ

**名前は開発中のものです。** · 04/02/10 08:03

画面にNOW　LOADINGとかの画像なりを表示させつつ
その間にデータを読み込めば良い

**名前は開発中のものです。** · 04/02/10 08:07

自機を動かしながら、敵を動かすのと同じやり方でいいでしょ
それともマルチスッドレにしたいのかな？

**名前は開発中のものです。** · 04/02/10 09:04

マルチ的手法とか、リアルタイム的手法とかいろいろ考えられるね。
NOW　LOADING処理表示中に、細切れにしたデータを逐次読み込むか、データ
読み込み中にNOW　LOADING処理を逐次呼び出すとか。

後者が楽だと思うけど、俺は画面処理を軸にしたいから前者の方が好きかな。

**名前は開発中のものです。** · 04/02/10 09:08

>>383
CreateFile 非同期で検索汁

**Delphian** · 04/02/10 12:58

>>379

ぁ、ワーカークラスのコンストラクタでタスクリストに登録すると、
継承したクラスごとに優先度とか変えられないですね。

そういういろいろややこしくなることを考えると、
やっぱりゲームごとにクラス作っていこうと思います。

みなさん、ありがとうございます！

**Delphian** · 04/02/10 17:06

ぁ、コンストラクタに引数もたせれば、いいんですよね(;^_^A

実際、タスク使ってつくる人より、
普通にクラスを使ってつくる人のほうが多いんですかね？

C++でいいのでゲームプログラミングでおすすめの本があったら、
教えてもらえるとありがたいです。

できれば中高度くらいで…
3Dものは作る予定ありません。

**名前は開発中のものです。** · 04/02/10 22:49

ああん、コンストラクタとかタスクとかクラスとか何話してんだか全然わかんないポ

**名前は開発中のものです。** · 04/02/10 23:12

動けば問題ないよ、面白ければ問題ないよ

**名前は開発中のものです。** · 04/02/10 23:13

>>391
まずプログラムの基礎を勉強するべきかと。

この辺の本とか、
http://www.amazon.co.jp/exec/obidos/ASIN/479800314X/ref=sr_aps_b_/249-6758129-5407516
http://www.amazon.co.jp/exec/obidos/ASIN/4798006033/ref=pd_bxgy_text_2/249-6758129-5407516
C++の便利な使い方も書いてあるので読め。

**名前は開発中のものです。** · 04/02/10 23:30

コンストラクタもタスクもクラスもわからなくても
古典的手法でガレッガや怒蜂は十分作れるYO

本が合う人は本でやってみるのもいいと思う。
もしそれでできなくても挫けるな。
どんな泥臭い方法でも、まずは動いて遊べるゲームを一つ完成させることだ。

一つもできないうちからウダウダやってると限りある人生ムダにすることになるぜ

**名前は開発中のものです。** · 04/02/11 00:54

まず、泥臭い方法で作る。
で、もっと良い方法ないかなと模索する。
結果、タスクなりオブジェクト指向なりに行くと。
タスクに関してアセンブラと少ないメモリで少しでも
すっきりした形で作ろうした結晶のひとつ。
いきなり理解しようとするのが間違っている。
オブジェクト指向しかり。

**名前は開発中のものです。** · 04/02/11 01:03

自分で問題に直面してみないと分からないことは多いからね

**名前は開発中のものです。** · 04/02/11 13:33

Cとタスクの一本槍人生。
WS→GBAと渡り歩いたら必然的にこうなったような。

しかしC++を覚えにくくなるという諸刃の剣。
結城浩尊師が御本を執筆なさる日を待っているとかいないとか。

**名前は開発中のものです。** · 04/02/11 14:20

int x[MAX];
int y[MAX];
int kind[MAX];
for (int i = 0; i < MAX; i++) { ... }

こういうBASIC時代の身も蓋もない実装を、アセンブラやCで正常進化させていけば、
勝手に古典的タスクに行き着きますな。
俺も含めて、すべてのオヤジゲームプログラマが辿った道でしょう。
んでもってC++覚えたらゲームオブジェクトやらエンティティやらシーングラフやら
OO的アプローチで取り組んでみると。

歴史をそのまま辿ってるので、今どきのわきゃーモンにとって効率のいい道かは……
まあ、若いんだし、回り道してみてもいいんじゃない？と思うけどね（ｗ

**Delphian** · 04/02/11 16:05

>>398

とりあえず、ここでアドバイスをいただいて、
オブジェクト指向でのゲームプログラミングについて、
わかってきました。

同じキャラクタが簡単に複製できるのでよいですね！

もう一歩レベルアップしたいのですが、
それは、あたり判定、、、（？）です。

シューティングというか、アクション要素の強いものにするつもりなんですが、
どういう方法をとればいいのかわかりません。

**Delphian** · 04/02/11 16:06

画面は斜め上からの見下ろしタイプ（？）で、
移動とか描画のイメージとしてはボンバーマンをイメージしてもらえると、
わかりやすいかと思います。

たとえば、１キャラ３２×３２のサイズだとして、
１キャラ単位の移動の場合には、
（右に移動するときは、８ドットずつ描画。
　１キャラサイズ分移動するまでは操作できない）
キャラの座標を元に、スプライトを優先度順に描画して、
当たり判定も座標位置から処理することができますよね？
（この場合、当たり判定というより、座標からのチェックですね。）

これをドット単位の移動にしたい場合、
どうすればよいのでしょうか？

シューティングゲーム製作技術総合 ２機目

シューティングゲーム製作技術総合　２機目