コンパイラがKernel32.libを見けられなかったり
二重deleteにしばらく気づかなかったりしましたが
わたしはげんきです。
STG製作中。敵を表示することが出来ました。
というわけで管理方法のメモ。
長文注意。
ひとまずは敵クラスを記述。これがないと始まらない!
早いうちに用意したほうがよさそうなパラメータを用意。
存在フラグ、初期化フラグ、座標、当たり判定の半径、移動ベクトル、
移動パターン、敵の種類、体力、画像 …あたりかしらん。
class Enemy : public Circle //Circleに座標とか入ってる
{
public:
Enemy( double x, double y, double r );
virtual ~Enemy();
private:
bool exist_, initFlag_;
int hp_, hpMax_;
int pattern_, kind_;
Vector move_;
Pictset *graph_; //Pictsetは画像管理クラス
};
クラスができたら、生成時に情報を入力する機能が必要です。
まず、敵の情報を書いたcsvファイルを用意しておきます。
今は、登場する時間、初期位置、移動パターン番号、種類、HPが書いてあります。
これをゲームに読み込む必要があります。
また、その情報を保持するものが必要です。
登場する時間だけ保存して、登場のたびに読み込むのはちょっと現実的じゃありませんからね。
というわけで、「敵オーダー構造体」を用意しました。
敵1匹分の注文書、というイメージです。 敵も、注文書も1つではないので、コンテナに保存する必要があります。
今回はイメージのつかみやすい"list"を採用。
また、注文書の解決、つまり敵の生成は、敵の各パラメータに注文書の値を代入するイメージでいけそうです。
さて、注文書には「敵の登場する時間」が書いてあります。
ということは、ゲーム開始からの時間を記録する変数(カウンタ)が必要です。
だからといって、そのカウンタがグローバル空間に野放しって言うのも嫌な感じ……
よく考えたら、敵と注文書のリストも野放し状態ですね。
それらを処理する関数も必要です。
こんなふうに密接な関わりのあるものどうしは、まとめるのが常です。
というわけで、敵と注文書の解決を担当するクラスを作ってしまいましょう。
ということで生まれたのが「敵タスククラス」。
「タスク」という呼び方が不自然ですが、リストを2つ持って、カウンタを持っているただのクラスです。
class EnemyTask
{
public:
EnemyTask();
virtual ~EnemyTask();
void load();
void run();
private:
int count_;
std::list list_;
std::list order_;
};
run関数は、処理メイン。
敵を生成したいときは、情報をload関数で読み込んで、
毎ループrun関数を呼べばいい、って寸法です。
あー、かなり長文になってしまったので、続きは希望があれば。
私の方はこれから自機ショットのモジュールを作ります。