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で管理したりします）

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

todo

本日は有給休暇。
試験後は必ず有給休暇を取っていますが、試験が半ボイコット状態なので、若干後ろめたいです。

敵弾や敵＆敵弾との当り判定、自機の爆破などを実装。
敵弾は、敵と概ね似たような感じの別のデータで管理することにしました。

あとは、
・ザコ敵の種類を追加（現状３対のみ。１ステージ８種類ぐらい欲しい）
・敵弾の種類を追加（現状、自機狙い/自機外しと固定方向弾の２種類のみ）
・中ボス
・ボス
・ゲームオーバー処理
・ステージクリア処理
・スコアシステム
が主だった作りこみ系の作業か。

ちなみに、ランクはEASY/NORMAL/HARDの３種類。
EASYは、「ナメんな！」というぐらい楽にするつもり。
HARDは、「ふざけんな！」というぐらい難しくするつもり。

そういえば、まだAndroidで一回もコンパイルしたことが無いので、そろそろ、一度実機で検証をしてみる必要があるかも。前回、InvaderBlock2を初めてWindows→Androidに移行した時、色々とトラブったので。
特に、入力系統が想定通りにできるかどうか、早めに確認しておかないとマズイことになります。

タイトル画面

タイトル画面（仮）を作成。
概ね、InvaderBlock2と同じメニューになります。

実は、普段ゲームを作るとき、タイトルはゲーム本編が完成後に作っているのですが、後で作る方が面倒なので、先に作っておくことにしました。先に作っておく方が、色々と便利。

まだ、画面上の何処をタッチしてもゲームスタートにしかなりませんが。
評価版では、プラクティス以外全部使える状態にするつもりです。


全然関係ありませんが、今日は情報処理試験でしたが、午前２のみ受験して帰宅。
次の秋は、午前１を受けなければいけないけど、割と朝には強いので問題ありません。
なんというか、時間配分を間違えました。
微妙に時間が掛かる計算問題が２問ほどあったのですが、ウッカリそれらをじっくり解いてしまい、後半猛スピードでとりあえず全問回答・・・という典型的なダメパターンでした。明らかにサービスっぽい問題が後半に多かったのですが、そういう問題にジックリ時間を取らなかったから、イージートラップに引っ掛かってしまったものが多そう。あと、用語で微妙に記憶が曖昧なものも多かったです・・・これは、単なる勉強不足。
こういう場合、恐らくギリギリ６割に届かない程度の解答率になるので、時間が惜しいと思い帰宅。
午前が落ちていて、午後が手応えあり・・・というパターンは避けたいところです。
午前は即日で公式回答が出る＆合格ラインが決まっているので無常です。（昔は相対評価でしたが）
仮に午前が受かっていても微妙な気分になりますが。

Androidアプリの「許可」について

Android端末を使っている知り合いが、アプリの許可（パーミッション）について知らなかったことに驚きました。

許可（パーミッション）の情報は、GooglePlayとかでアプリをダウンロードする時に表示されます。
インストール済みのアプリについては、アプリの管理画面から確認することができます。

ちなみに、私が配布しているアプリで使用している許可は、
・INVADER BLOCK 2 → ストレージ
・VGS Chiptune music → なし
です。

ストレージというのは、SDカードへのファイル書き込み許可です。（以下）

---

ストレージ

USB ストレージのコンテンツの変更/削除、SD カードのコンテンツの変更/削除

USBストレージへの書き込みをアプリに許可します。SDカードへの書き込みをアプリに許可します。

---

※ストレージの許可は、スコア＆リプレイをSDカードに記録する目的で付与しています。

危険な許可の代表例は、「携帯のステータスとIDの読み取り」とか、「連絡先データの読み取り」など。
私のアプリでは（不要だから）設定していません。

連絡先の管理をするアプリであれば、「連絡先データの読み取り」（＆書き込み）が必須なので、連絡先の管理をするアプリをダウンロードする場合、「発行元が本当に信頼できるか？」という点を、利用者の責任で十分に確認してからダウンロードする必要があります。

今、世間で「the Movie」なるタイトルを冠するアプリが、連絡先の情報を抜き取って何処かに送りつけていた事件が起こってますが、それらアプリが「連絡先データの読み取り」の許可を必要としていることは、ダウンロード時に表示されていたようです。

私はそれらのアプリをダウンロードしようとしたことが無く、プレスから得た情報ですが。（ソースは以下）
http://www.itmedia.co.jp/enterprise/articles/1204/13/news113.html

もちろん、アプリの発行元が悪意をもって情報を抜き取っていたことはほぼ確実だと思うので、悪いのはそのアプリの発行元だということはほぼ間違いないと思います。ただ、ネットワークアクセスをするにも関わらず、ネットワークアクセスについての許可が表示されなかった点はAndroidの脆弱性だと思いますが。

また、「利用者に何も過失が無かった」とは言えないように思います。
アプリの許可（パーミッション）について、「何故こんな許可を必要とするのか？」という疑問があるアプリは、一切ダウンロードすべきではないです。
特に、「連絡先データの読み取り」については、「利用者本人だけでなく、利用者の友人や家族などの情報へのアクセスをアプリに許す」ということを意味しているから、十分に注意する必要があります。

あと、Googleもそういう点（不可解な許可の設定）については、審査すべきだと思います。
もちろん、目視での確認が必要になるので、相応のコストが掛かると思いますが、それは必要支出だと思います。
その程度の審査でも、やっていれば今回のケースは事前に防げた可能性が高いので。
（動画を見るのに連絡先を参照する意味が全く無いので）
もちろん、人間による審査だから100%確実ではないかもしれませんが、「審査を行っている」という点が重要。
今のままでは、「審査すら行っていない」という点で、Googleに過失責任がある気がします。