状況

開発中のSTGが予定通り、中ボスまでできて、あと色々と細かい画面エフェクト系のシステム周りも作っておき、無事Androidへのポーティングも完了。これで、ウィークデーも会社でデバッグができます・・・疲れた。

今回のゲームは、Windows（マウス）よりもAndroid（タッチパネル）の方が断然操作し易い。
InvaderBlock2は微妙にWindowsの方が操作し易かったのですが。
やっぱり、マウスだと左クリックしっ放しという状態は結構疲れるのかもしれません。
なので、Windows版をタダで配ってAndroid版を売るパターンは止めにしようか悩みどころです。

今回は、ステージ型のSTGなので、Android上で体験版を配るのみでも良いかもしれない。
フリーで作って配ったアプリ（VGS Chiptune Music）は、何も宣伝しなくても50本以上ダウンロードされたので、フリーであれば、配るだけでも宣伝効果があるようですし。


しかし、ここ数ヶ月、土日も仕事をしているような感じなので、GWにはゆっくり休みたいところ。

当り判定のつけかた

ようやく、中ボスを作成する作業に入ります。
まだ、色々と完成していない部分はありますが、今日中にとりあえず中ボスを作成しておき、Androidで中ボス戦まで遊べる状態にしておけば、ウィークデー中でも会社の休み時間などに調整ができるので、中ボスまで作ることを優先で。

ちなみに、中ボスの当り判定ですが、下図の紫枠のような感じになります。

私のSTGシステムの場合、１体の敵キャラクタはパーツ、オブジェクト（パーツ集合）、クラス（オブジェクト集合）という３層のデータ構造で表現しているので、パーツを上図の紫枠のように分割し、パーツ単位に当り判定します。
当り判定の範囲はパーツ単位で枠よりも小さくしたり、無判定にすることが可能。
そして、敵の耐久力はオブジェクト単位という感じです。

中ボスは、登場中に他の敵キャラクタが登場しないので、パーツを細かくして細かい当り判定をできるようにしよう・・・と、思ったら、パーツのハードリミット（１２個）を超えてしまったので、ハードリミットを１６に拡張しました。実は、パーツのハードリミットを拡張しても、処理性能への影響が無いので、もっと多くしても良いのですが、多くしてしまうと、ROMファイル（プログラムを除くデータ情報を格納したファイル）のサイズが大きくなります。

ちなみに、現時点のROMファイルのサイズは、1,312,322byte。
プログラム本体のサイズは、551,936byte。
合わせて1,864,268byte。（1.78MB）
APK（ZIP）に圧縮すると、600KBぐらいです。

気にする程、容量が膨れ上がっている訳ではないですが、「無駄データは１バイトでも少なくしたい」と思うのがプログラマの性癖です。BGMをoggとかmp3にしてしまうと、平気で数10MB～数100MBになりますが、やはり、それは気分が良いものではありません。

システム周り

STGの開発状況は、１面中ボスの手前まではできました。
中ボスを作る前に、難易度やゲームシステム周りに色々手を入れてます。

難易度的には、前３作と比較して大分落とします。
一応、EASY/NORMAL/HARDの３ランクを準備しますが、
・EASY = Elementary向け
・NORMAL = Soldier向け
・HARD = Ninja向け（私が楽しめる難易度）
という感じになる筈。

ゲームシステム的には、ボンバーが無いので、代わりに設けている回避処置（LASER）のルールを色々と弄って、良い感じになるようにしています。
当初、レーザー中は完全無敵にしようと思っていたのですが、それだと色々とバランス崩壊してしまうので、上手い感じになるように色々と調整してます。今の所、かなり流動的にルールが変化しているので、確定的なことは何も言えませんが。

一応、GW中には体験版（１面のみ）をリリースしたいのですが、できるかどうかは今のところ五分。
ザコ 敵が現状、まだ５種類しか居ないし。
ただ、ザコ敵の種類はあと１種類ぐらいで丁度良いかも・・・と思い始めてますが。
そういえば、SHOT03の時も、１面で作ったのは６種類だった気がします。
当初、１ステージ10種類ぐらい＆各ステージで流用無しで作ろうかと意気込んでいましたが。


しかし、一般的なSTGの1ステージあたりのザコ敵数って果たして何種類ぐらいなのか・・・

怒首領蜂の１面は、
①緑戦車（小）
②赤戦車（小）・・・恐らく、アルゴリズムは①と同じ
③小型ヘリ
④中型飛行機（丸っこいやつ）
⑤大型戦車
⑥ポッド？
⑦中ボス
⑧大ボス
だったと思います。
記憶違いがあるかもしれませんが。

やはり、ザコ＝６種類がベストかな。

アプリの信頼を得る方法

先日、Androidアプリの許可（パーミッション）に関する記事で「Googleが登録審査すべき」みたいなことを書きましたが、今朝やってたNHKの番組で専門家の人が、「それはまず無い」というような感じのことを言ってました。まぁ、Googleのスタンスからして、私もそれはほぼ無いだろうと思ってます。

アプリをダウンロード時の注意点について、専門家の意見を纏めると、
(1) ユーザがアプリインストール時にちゃんと許可（パーミッション）をチェックすべき
(2) 他のユーザが書いているレビューを参考にすべき
(3) なるべく安全なマーケット（キャリア提供のマーケット）だけ利用すべき
という感じ。
大筋ではこんな感じのことを伝えている番組でした。
（若干、私の脳内変換が入っているかも）

私が配布するアプリには、当然悪意は一切無いのですが、その点を第三者から信頼して貰う手段として、キャリア提供のマーケットで配るというのが有効かな・・・と、思いました。そこで、au Marketへアプリを登録する手段を調べてみましたが、au Marketへのアプリ登録者は原則的に日本国内に登記されている法人である必要があるようです（au Market利用規約の第5条3項2号を参照）。ただ、法人じゃなければダメ（＝必須要件）ではなく、例外が有るようですが。（あくまでも、例外なので「法人限定」という解釈で問題無いと思います）

現状、法人限定という点がちょっとハードルが高い。。。

上記以外の方法で、アプリの客観的信頼を得る方法としては、iPhone版を作って販売するのもそこそこ有効かも。アップルは、（審査が厳しいか否かは別にして）登録するアプリを審査しているようなので。

マルチプラットフォーム化は、開発者に技術力がそこそこ要求されるのがネックですが、幸い私には、それが問題にならない程度の技術（エミュレータを作れる程度の技術）なら有るので、ネックになる事が何も有りません。なので、今作っているSTGが完成したら、そのSTGとInvaderBlock2のiPhone版を作ろうと考えています。

ちなみに、私が開発しているAndroidアプリは全て、VGEという独自システムの上で作っていて、その独自システムはかなりチープな環境でも動作できる設計にしているから、iPhoneへの完全移植は容易です・・・たぶん（一応、iPhone移植を見越して論理ハードウェアを設計しているつもり）。

VGE（Video Game Engine system）というのは、CPUエミュレーションの無いエミュレータみたいなものです。実在する模倣対象のハードウェアが存在しないので、エミュレータというのは用語として適切では無いかもしれませんが、要するに、画面・入力・音声の要素部分を抽象化したものです。（下図のようなもの）

ちなみに、VGEの実在ハードは存在しませんが、自主制作（趣味）でこのVGEの仕組みを搭載した、携帯型ゲーム専用機（ハード）を作りたい・・・という野望が有ったりします。だから、VGE＝エミュレータというのは、強ち間違いではありません。「鶏が先か、卵が先か」という話しです。

ヘリ旋回

ヘリを旋回させた時のハネの座標を計算する作業が終了。

何のこっちゃ？
ですね。

ヘリが回転（旋回）する時、主翼（一番大きいプロペラ）の中心点を軸にして機体を回転させるのですが、その際に本体と尾翼の位置を求める作業です。

具体的には、以下のロジックのposを埋める作業。

/*  *----------------------------------------------------------------------------  * ヘリの向きを変える  *----------------------------------------------------------------------------  */ static void heri_roll(struct Enemy* e,short d) { static const short pos[9][4]={ {7,5,15,1} ,{5,5,5,3} ,{5,8,-2,14} ,{10,5,2,24} ,{6,11,8,30} ,{8,10,21,31} ,{10,8,30,23} ,{10,7,32,12} ,{10,5,27,2} }; int p; e->obj[0].pt[0].n+=d; while(e->obj[0].pt[0].n<31) e->obj[0].pt[0].n+=9; while(39<e->obj[0].pt[0].n) e->obj[0].pt[0].n-=9; p=e->obj[0].pt[0].n-31; e->obj[0].pt[0].x=pos[p][0]; e->obj[0].pt[0].y=pos[p][1]; e->obj[0].pt[1].x=pos[p][2]; e->obj[0].pt[1].y=pos[p][3]; }

ヘリは、９パターン（４０度）で作ったから、中々面倒でした。


ヘリ本体のスプライトサイズが32x32、主翼が48x48、尾翼が16x16という具合にパーツ毎にサイズが違うので、ズレを座標計算するのが中々めんどいです。

座標のズレを必要としない画像パターンを最初から準備すれば楽なんですが。
ただ、そうすると無駄にパターンサイズが大きくなってしまいます。
つまり、メモリ効率が悪くなります。
あと、スプライトサイズが大きいほど、処理も食います。


そういえば、上のキャプチャを取って初めて気付きましたが、プロペラの影の座標がズレてる・・・
影は、スプライトの1/2サイズなので、ズレ座標も1/2しなければいけないけど、それが漏れていたっぽい。早めに気付けて良かった。画面キャプチャを取ってみて初めて気づくバグが稀によく有るので、この開発日記を書く作業は結構有意義かもしれません。

タイトルの付け方

開発中のゲームのタイトルですが、一応、タイトル画面の画像を貼り付けたとき、「Atomic Laser」と書いてあったかもしれませんが、「Atomic Laser」にするつもりは無いです。流石に、それではダサ過ぎるので。

タイトルってかなり重要だと思います。

一応、候補に挙がっているのは、幾つかあります。
今のところ最有力候補は、SHOT04 - NO・KO・GI Rider （ショットゼロヨン・ノコギライダー）

VGS Chiptune Musicを作ったとき、ノコギリ波の波形名を表示する際、表示領域が足りなくて、「NOKOGIR」という略記にしたのですが、「ノコギルって何かカッコ良くない？」という感じです。

あと、このゲームの２面で使用予定の音楽（のピスコラ版）をピスコラの曲投稿サイトに投稿した時、
「'80年代戦隊ヒーローモノっぽい」
という評価を頂いたので、ノコギル＋戦隊っぽい何か・・・ということで、Nokogi Riderです。

ただ、Nokogi Riderだと見栄えがカッコ悪いから、「NO・KO・GI Rinder」です。
「E・S・P Rade」と概ね同じノリだと思います。
エスプレイド的な要素はほぼ無いと思いますが。

今のところノコギリ的な要素が皆無なのが難点。
結構気に入っているのですが。

PAUSE画面（その２）

現在開発中のSTGにポーズ画面を入れる修正を、Androidでも実装。

やり方としてはシンプルに、
http://techbooster.jpn.org/andriod/ui/4109/
上記URLで紹介されているBACKキーの入力を取得する方法で、BACKキーが押された時、デフォルト動作（アプリを停止）せずに、ポーズ画面に移行する感じにしました。

あと、HOMEキーを押した時は、ポーズ画面に移行しつつ、バックグラウンドに移行する形になります。
本当は、HOMEキーでもポーズ画面にしようとしたのですが、HOMEキーの入力情報はアプリで取得できないようなので、デフォルト動作（バックグラウンドに移行）しつつ、ポーズ画面に移行することにしました。

まぁ、HOMEキーもBACKキーと同じ動作することも不可能ではないと思いますが、このデフォルト動作（バックグラウンド移行）を変えるのは、結構危険と判断しました。というのも、例えばプレイ中に電話が掛かって来るといった割り込み動作がHOME相当の処理になりそうな気がしたので。
なので、この部分に手を入れてしまうと、優先度が高い割り込み操作が入ったときにKillManagerに殺られちゃうんじゃないかなぁ～・・・と想像しました。
ついでに、プレイ中にホームに戻りたいことも無いことは無かろうと思いますし。

忘れかけてましたが、一応スマホって電話なんですよね。
だから、電話用途で使われる可能性を排除しちゃいけないと思います。（一応）
電話としてのスマホの魅力は皆無ですが。