敵アルゴリズム

ようやく、敵を登場させるシステムの骨組みが完成。

あと、敵の絵やらアルゴリズムもどんどん追加していくだけ。

敵のアルゴリズムは、スクリプト化する派とプログラムでいく派が居ると思いますが、私は後者。
以下のように、アルゴリズム関数を関数配列で管理して、キックする感じでやっています。
STGの場合、このやり方で作る方がスクリプトのシステムを作るよりも効率が良い気がします。

敵アルゴリズム以外の部分が、まだ、色々とできてませんが。
敵のドット絵とか。
上のキャプチャはSHOT03のドット絵の流用物なので、若干・・・というより、かなり浮いている。
（このままでは流石に使えない）


システム的な面では、爆破やら、敵弾やらがノータッチ。


とりあえず、爆破パターンのドット絵はSHOT02の頃から使っているものを流用しようとしていますが、爆破ギミックは少し凝らせたいので、結構時間が掛かりそう。個人的に、爆破はシューティングの華だと思っているのですが、割とそういう議論をあまり聞かない・・・と、思っていたら、2chに専用スレッドがあり、色々な意見が見れて面白かったです。色々と参考にしながら試行錯誤してみようと思います。

敵弾も割と重要だし厄介。
ちなみに、弾幕STGにするかは微妙です。
個人的に高速な弾を高速な自機で避けるのが好きなので。
ただ、高速な弾主体にすると、必然的に自機狙いや自機外し（つまり、真っ直ぐに飛ぶ弾）が中心になってしまうから、それは避けたい。今回はもっと多彩な弾を飛ばせるようにするつもりです。
ですが、アクション・パズルゲームにはしたくない。
アクション・パズルゲームが嫌いな訳ではないですが。（寧ろ、好きな方）

STGにおける敵情報のデータ設計

シューティングゲーム（STG）の作り方を解説しているサイトは数あれど、敵のオブジェクト情報をどのように設計するかについて言及しているサイトは割と見かけないような気がするので、軽く解説しておきます。

そんなん、単純に構造体で管理だろJK

・・・かもしれませんが、この部分のデータ設計を予め如何に適切におこなっておくかで、ゲームの表現の幅が大分変わります。私はそのことを、SHOT01～SHOT03（３作品）の開発での失敗を経て実感しています。

まずは、実際に設計中のデータ（実物）を見た方がイメージが沸き易いかと思います。

なので、現在開発中のSHOT04で作成途中のデータ構造を例示します。

クラス構造としては、敵、オブジェクト、パーツの３種類。

E-Rで表記すると、

• 敵：オブジェクト＝１：ｎ（最大８）
• オブジェクト：パーツ＝１：ｎ（最大８）

という感じ。
つまり、１匹の敵は最大64パーツ（8^2）持てます。
数は今後、コロコロ変わっていくんでしょうけど。

実は、SHOT01の頃は単純な１個の構造体で敵を表現していました。
ただ、それだと当り判定が複数個所に分かれるような場合、処理が面倒になります。
そこで、SHOT02とSHOT03では、１つの敵を複数のオブジェクトで表現する感じにしました。
ただ、それでも処理が厄介な部分があったので、今回は、敵、オブジェクト、パーツの３層構造のスキーマを定義。（予定）

オブジェクトには、有するパーツ数＋パーツ情報を定義します。
例えば、グラディウスの多節足の敵の場合、根っこの部分、胴体の部分（複数）、頭の部分みたいなパーツをグループ化したものが、ひとつのオブジェクトになります。

それなら、オブジェクトとパーツだけ（２層構造）で十分だ・・・と普通は考えます。
（だから、SHOT02とSHOT03はその形態にしました）

ただ、例えば多節足を２本持っていて、足単位でパーツ破壊できるような敵（足×２＋本体）というものを作ろうとするとプログラムが複雑になってしまいます。だから、オブジェクトを更にグループ化した、クラス（Enemy）を追加・・・という訳です。これで、どんなものでも簡単な処理で表現できる筈。まだ、作ってないから確証は持てませんが。

ちなみに、クラスだとかスキーマだとか、オブジェクト指向の用語を使っていますが、プログラム言語はCのみです。私は、C++やJavaが大嫌いなんですが、オブジェクト指向の考え方自体は、重要だと思っています。（ついでに、iPod touch化するときにもに楽になる筈）

背景

背景がクロマティだと寂しいので、マップ機能を実装。

以前、GAME06という名称で作っていたアクションRPG（※開発断念）用に作ったマップエディタとマップシステムを、シューティング用にカスタマイズして作るだけだから、システム自体は一瞬で作れました。

問題は、リソース（チップセットの画像）。

私には絵心がほぼ無いので、ハムコロサマさんの素材あたりを使いたいところですが、フリーゲームで使うのならともかく、商売で作っているものに他人の著作物を使うのは（現時点の使用許諾は未確認なので、実際にダメかどうかは定かではないですが）トラブルの元なので、下手ですが、自分で描くことにしました。
地面の線路（のつもり）と、飛行機のサイズを影の大きさから計算して見てみると、明らかに寸法がおかしかったりしますが、気にしない方向で。

ちなみに、飛翔鮫みたいな感じの左右スクロールはしない方向です。
左右固定（＝東方と同じ方式）。
左右スクロールのプログラム自体、簡単に作れるのですが、マップを作るのが（広い分）面倒だし、ゲームバランスの調整も面倒になるので、左右は固定です。
要するに手を抜きます。

GW中には、ステージ1のみのトライアル版（無償）をマーケットに流したいから、開発効率優先で。

上下移動（実装）

上下移動を実装してみました。
かなり良い感じです。

少なくとも、Android市場に出回っている作品の中では、随一の操作性で、尚且つ全盛期（90年代）のシューティングゲームを求めるコアなシューターが満足できる水準のモノを仕上げることが出来ると思います。（たぶん）

問題は、コアなシューターがAndroidユーザーの中に居るかどうかですが。
たぶん、そんなに居ないんじゃないかと思っています。
満足のいく水準に達している作品が想像以上に少なかったので。
ただ、潜在的にはかなり居ると思っていますが。
というのも、Androidはデフォルトが縦画面（＝シューティング専用）なので。

とりあえず、この作品の１面が出来た段階のβ版（トライアル版）を無償で市場に流してみて、様子見をしてみるつもりです。そして、売れそうな感触だったら本気で作り、そうでなかったら、このゲーム（SHOT04）の開発はヤメにして、別路線を探るつもり。

ニーズが無くとも、完成させる可能性も大ですが。