スクリーン仕様変更

開発中のSTGのスクリーン仕様を大幅に変えることにしました。
私が開発しているゲームエンジンは、「240x320の仮想ビデオメモリ領域をアスペクト比を保った状態で最大限に拡大し、画面中央に配置する」という仕様です。

Androidの場合、最も画面領域の小さい機種が240x320（QVGA）だという事情もありますが、個人的にQVGAが一番ゲームが作り易いし、ちょっと粗い感じの画面が好きだという事情が一番大きいです。もちろん、その部分の仕様は変更しません。

仕様変更するのは、「画面中央に配置」という部分。
具体的には下図のような感じに仕様変更します。

端末画面の縦横比が４：３（VGAやQVGAなど）の場合、画面目一杯拡大される形になります。
しかし、現状、市場に流通しているAndroidは、殆ど１．５：１（iPhoneと同じ比率）です。
１．５：１の画面の中に４：３の仮想スクリーンを、アスペクト比を保った状態で最大限に拡大すると、必然的に画面の上下にBLANK（余白）が発生します。

そして、そのBLANKを上下に均等分配していたものを、下に纏める形にします。
もちろん、仕様変更前の方がカッコイイんですが、背に腹はかえられぬ事情があります。

BLANK領域にも当然ながらタッチ判定があるのですが、現状仕様だと、プレイ中に誤ってHOMEボタンやRETURNボタンを押してしまう可能性が高そうだったので。つまり、誤ってホーム画面に戻ってしまったり、ポーズしてしまう誤操作が、かなりの高確率で発生してしまいます。（今日、昼休み中のテストプレイで数回、発生）

INVADER BLOCK2のように、左右移動だけなら発生することはほぼ無いですが。
しかし、開発中のSTGは、上下移動はよくするので、目を瞑れない程度のレベルで誤操作してしまいます。

という訳で、画面下にタッチ用の余白を確保することにしました。
まぁ、iPhoneの勢力からして、Androidの主流が再び４：３に戻ることは無いだろうと期待しつつ。

っていうか、そもそもボタンを画面下に持ってくる設計がそもそも微妙な気がしますが。
ハードウェアのボタンは画面上でも全然困らないです。
ゲーム以外のアプリでも、ボタンが画面下にある所為で操作ミスすることがありますし。

そういう操作ミスをし易いアプリを操作する場合、基本的に逆さまにして操作していｒ...
・・・これを書いていて気付いたのですが、画面を上下逆表示する機能があれば、良いんじゃない？という神が掛かったアイディアを思いつきました。（ちなみに、重力判定は重いからoffにしているので、ソフトウェア的に実装する必要があるから、若干面倒ですが、無理ではないです）

状況

開発中の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」と概ね同じノリだと思います。
エスプレイド的な要素はほぼ無いと思いますが。

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