シューティングゲームチャレンジ ＃5

～敵をジグザグに動かす～

ここのところずっと、敵機を滑らかにジグザグに動かす方法を考えている。
どれが一番応用が効いて、効率的か。
円周の座標を求める方法を使ってY座標を求めるのが良いかなと。
円運動はY座標だけを見れば波運動と言えるので、このY座標と、まえの記事の真っ直ぐ飛ぶ動きのX座標を合わせて使えば、滑らかなジグザグ運動が実現できそう。

なんか、思ったのは数学の基礎は必須ですな。
わりと好きだし、学生時代は得意科目だったけど。
3Dゲームを想像すると、さすがに頭が痛くなる(笑)

シューティングゲームチャレンジ ＃４

～敵機表示～

試しに敵機を表示するプログラムを実装した。
動きは最も単純なパターンで、画面の右端から左端へと真っ直ぐ飛んでゆくものだ。

敵移動関数
１フレームごとに敵機のＸ座標をspeedに入っている数値分引く。
画面の左に消えたら、座標を初期化。

敵データ初期化関数
敵機のＸ座標を画面右端へ。
Ｙ座標は画面の枠の範囲内で乱数で決める。

上記の関数と、敵データの構造体を追加し、画面表示関数に敵機を表示する命令を加えた。


















敵の座標を動かす敵移動関数は、敵の動きのパターン分必要になる。
こんな感じで試しながら、ジグザグや、自機へ向かって来るなど、必要なパターンを少しずつ増やしてゆくつもりだ。

敵、敵、って言ってるけども、まだ当たり判定が無いので敵になっていないのが現状だったり・・・（笑）

実は敵機のグラフィックパターンは今の段階でクルクル回転するアニメーション分のデータも含んでいる。
アニメーションさせる処理をしていないので、ハンドルの最初の絵が表示されるだけなのだ。
せっかく描いたので、次回はアニメーションに挑戦してみよう。

実行ファイルを。
ソーステキストも同梱です。
http://multip.net/view/3DVMXP6CpQ
ダウンロードや実行方法は＃2の記事を参照してください。

シューティングゲームチャレンジ ＃3

～自機の移動範囲を制限する～

前回のプログラムだと、自機が画面の外まで飛んで行ってしまうので、移動範囲に制限をつけました。
自機のサイズは64×64ドット、画面サイズは640×480ドット。
Ｘ、Ｙ座標共に、マイナス方向は０以下になったら0に、プラス方向は画面サイズ－64以上になったら、画面端から64引いた位置に補正するようにプログラムを追加します。

ここで問題が、自機は左右方向は64ドット幅いっぱいに描いたので問題ないのですが、縦方向は使用されていない空白幅が存在します。
画面サイズから64ドットで補正すると上下方向には、まだ移動できそうな隙間が出来てしまうのです。
これを直すには、自機の画像データを縦幅いっぱいいっぱいになるようにサイズ変更するか、補正をかけるポイントを変更するしかないでしょう。
僕は楽な方、つまり後者を選びました。
自機の画像データを見て、上下方向の隙間のドット数を確認し、それに合わせて「画面端にきましたよ」って判断する座標をずらしたわけです。


















ソースはこんな感じ。
自機移動関数のみの変更です。
操作に対して、座標を加減した後、その座標（自機）が画面外に出ていないか判断し補正する　if　文を付け加えています。

シューティングゲームチャレンジ ＃２

～自機を表示してみる～

とりあえず自機を表示して動かせるようにしました。
この辺は、既に勉強済みの部分なのでスンナリです。
が、ソース的には微妙に進化してまして・・・。

最初から自機に関するデータを構造体でまとめてる。
メインループには関数の呼び出しと、フレームタイムの管理のみが置かれ、様々な処理は関数によって行われる。

この辺を最初から考慮してプログラムを書けるのは、ぷよ再現の時に後から数値をいじったり、処理のアルゴリズムを書き換えなければならなくなったとき、どんなソースにしとけばいじりやすいか学べたからだと思います。












まだまだ寂しい画面・・・。
自機も縁取りのみ。
それはドット絵の手抜きですが（笑）。




自機のグラフィックは３パターンで、上昇、下降中は絵が変ります。
移動は１フレームあたり、Ｘ，Ｙ共に４ドット。
自機の動きに関しては、ジャンプのような重力の働く動作があるわけじゃないので、ベクトルとかの概念を取り入れず今のままで行けるんじゃないかと思ってます。
当たり判定とかは未知の領域なので、その辺まで行った時にどうなるかはわかりませんが。

あと、前回のプログラムでは、１フレーム１７ミリ秒を超えると強制終了するようにしていたんですが、このおかげで僕の環境では時々１７ミリ秒を超えることがわかりました（笑）。
そんで、この強制終了の処理を外して、１７ミリ秒以下だったら必要分ウェイトをかけるって処理にしました。
感覚的に表現するなら、「59ＦＰＳキープできなきゃ強制終了じゃあー！」から、「できるだけ59ＦＰＳキープしてね」って感じになりました。
デバッグすると開発環境の下の方に出てくる出力ウィンドウに「１フレームの時間17msec」って表示されてるんで、平均的には59ＦＰＳになってるんじゃないかと思います。

まだまだ寂しい画面の、初歩的な処理ですが、Ｃ言語初心者の方も見てることを想定して、プログラムソースのテキストファイルも同梱した実行ファイルを置いておきます。
http://multip.net/view/oYhVgWM41Y
↑のリンク先、四角い枠内の下の方にある『ダウンロード』をクリックするとダウンできます。
zipファイルなので、+Lhaca等で解凍してからフォルダ内のexeファイルをダブルクリックで実行できます。
ＥＳＣキーでプログラム終了です。
操作は矢印キーとゲームパッド両方に対応していますが、今回はシューティングゲームなんで、今後の事も考えてゲームパッドを推奨しときます。

シューティングゲームチャレンジ ＃1

～１秒間のフレーム数を管理する～

はい、タイトル通りです。
２作目は横スクロールシューティングゲームに挑戦してみます。

敵をどう動かすか。
画面のスクロールはどうするか。
当たり判定はどうするか。

今考えられる範囲では、この辺が壁になりそうです。
ちょっと無謀な気もしますが、失敗しても勉強にはなるでしょう。
ぷよぷよのときと同じく、必要な知識をそのつど得ながら頑張ってゆこうと思います。

目標は、
１ステージをボスまで完成させる事。
大好きだった初代Ｒ－ＴＹＰＥの１面のギミックを可能な限り実装する事。
って感じです。

まず、今回は１フレームの時間をしっかり管理してゆこうと思ってます。
ぷよの時は落下速度などを時間で管理していましたが、１ループの時間、つまりＦＰＳについてはまったく意識していませんでした。
と言うわけで、まだ何も処理の入っていないメインループに、ループにかかる時間を一定にする処理を先に入れてしまいました。
このやり方が一般的に正しいのかどうかはわかりません（笑）。
















まずループスタート時の時刻をstarttimeと言う変数に入れときます。
そしてループの最後の時刻をendtimeと言う変数に同じように入れときます。
ループにかかった時間はendtime - starttimeとなります。
あとは17（ミリ秒）からループにかかった時間を引いたぶんWaitTimer関数で処理を止めます。

これで１ループにかかる時間は、中でどんな処理がされようとも、17ミリ秒を超えない限りは１７ミリ秒で統一されるはずです。
１秒は1000ミリ秒なので、このループは約59ＦＰＳってことになります。・・・よね？（汗）