アプリの信頼を得る方法

先日、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に殺られちゃうんじゃないかなぁ～・・・と想像しました。
ついでに、プレイ中にホームに戻りたいことも無いことは無かろうと思いますし。

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

ヘリのハネ

シューティングといえば、ヘリ。
ヘリといえばシューティング・・・

・・・というぐらいのヘリ厨なんですが、そういえば、未だ嘗て、自作STGにヘリを出してなかった。
なので、今回は出します。
という訳で、ササッと作画。

ヘリのハネですが、＋状のものと、×状のものの２パターンだけでOK。
これだけでかなり自然な回転アニメーションになります。
適当なSTGの画面キャプチャを見れば分かると思いますが、皆、こんな感じです。
ゲームによっては、残像を少し付けた感じのものもありましたが。
まだ動かして確認していないので、動かしてみて、物足りなかったらつけようと思います（残像）。
何れにせよ、機械的なエフェクトで作画ができるから簡単。

PAUSE画面

そういえば、今回のAtomicLaserではポーズ画面を入れようと思っています。
実装中ですが、画面は↓こんな感じ。

スプライト表示が消える仕様です。
スプライト表示も残して画面を暗転する仕様にすることもできなくもないけど。

ちなみに、ホームボタンor戻るボタンのどちらを押してもポーズ画面にする仕様にするつもり。
あと、Windows版は画面フォーカスを失ったときもそうした方が良いかな。

ポーズ画面を入れる理由ですが、リセット（VGEのハードリセット）を入れる事が目的です。
InvaderBlock2の場合、1プレイ時間がものすごく短いので、心理的に不要だったのですが、シューティングの場合、ソフトリセットが無いと流石にマズイかなぁ・・・と、思ったので。
シューティングの場合、本当はソフトリセットが無い仕様の方が上達できるんですが・・・やはり、コンシューマ機向けのゲームだと有って当然だし、無いことを不快に思う人も結構居るはずでしょうから。私自信、アーケードゲームで育った人間で、コンシューマゲームは殆どやったことが無いから、ポーズ画面の必要性をあまり感じて無かったりします。

Androidのcharは符号なし

とりあえず、AtomicLaserをAndroidでコンパイルして動かしてみました。
写真は、デバッグ専用のタブレットで動かしたものですが、スマホでも問題無く動きます。

Windows→Android移植作業の過程で、Androidのプラットフォーム固有バグを、また発見。

どうも、AndroidのCでは、charが符号付き8bitの整数値ではないらしいです。
符号付き8bitの整数値同士の計算であれば良い（２の補数だからオーバフローにより期待値が得られる）けど、キャストして演算すると変な結果になってしまいます。

例えば、
------------------------------
char c = -1;
int i=0;
i+=c;
printf("%d\n",i);
------------------------------
という計算を行った場合の標準出力結果は、
Windows → -1
Android → 255
という風になります。

Linuxの仕様かも。
仕事でプログラムを組むときは、8bit符号整数は使わないので、詳しくは未調査です。
ゲームの場合、大量のデータを管理するとき、敢えて8bit符号整数を使う事がよく有りますが。（例えば、リプレイデータなんかの場合、処理効率よりもデータ量を少なくする事の方が重要だから、-128～127の範囲に収まる保存値は8bitで管理したりします）

これのお陰で、内部関数の仕様を大分変える必要がありました。。。
今の内に気付けただけでもラッキーと思っておくべきか。