移動開発環境

Androidコンパイル環境の移動開発環境を準備しようと思っていたけど、スッカリ忘れていた。。。
というより、Android SDK自体が重過ぎる。
とりあえず、Eclipseを使っていないから大分マシな方ですが。
しかし、Android SDKだけでもかなり重い上に、NDK、Ant、Cygwinも軽くは無い。

でも、無理してAndroid SDKの移動環境を作る必要は無いかもしれません。
私の場合、VGE上で動作するようにWindowsで開発すればよいだけなので、チープな環境（ノート）に無理してAndroidのビルド環境を作る意味が無いであろう・・・と、思います。

体験版公開までやらなければいけない作業は、
(1) タイトル画面作成
(2) スコアシステム作成
(3) 1面後半（中ボス後）作成
(4) １ボス作成

一応、どれも実機が無ければ作成できない訳ではない。
上記(4)の作業については、実機が無いと調整が難しいですが、大枠についてはWindowsオンリーで問題無い（ハズ）。

ちなみに現在、(1)を作成中。

残作業は、デモプレイの画面を付けたりする作業など。

デモプレイというのは、タイトルで暫く放置しておけば勝手に始まる、STGでお馴染みのアレ。

デモプレイを入れる目的は、HowToPlay（遊び方）を短時間で端的に使えるため。

HowToPlayは言語差を考慮してこのデモプレイのみ。

デモプレイを付けるには、リプレイ機能を一通り作らないといけないから、やや大変です。

体験版では、リプレイ機能自体は使用不可にしますが。

体験版は、パーミッション不要にしたいので、ファイル保存系の機能は全般的に入れない予定。

あと、どうでも良いですが、タイトルは、Atomic Laser→NOKOGI Rider（ノコギライダー）に変更。

しかし、シューティングっぽくないタイトルだ・・・レースゲームと勘違いされそう。

販売する国と地域

開発中のSTGを販売する国／地域をどうするか・・・という問題があります。
消費間接税が色々と厄介なので。

日本の場合は問題無いです。
日本の消費税は、基準年度の課税売上が1,000万円を超えない限り、課税対象とはならないので、まず、問題にならない筈なので、まず気にする必要はありません。（そこまでの収益を上げるには、100円の収益のゲームなら10万本以上・・・だから、まず無理ぽです）
万が一、必要になっても、日本での手続きならちゃんと意思疎通ができるから問題ありません。
（確定申告ぐらいしかやったことありませんが）

問題は、海外の消費間接税。
例えば、欧州の付加価値税（VAT）は、年間売上が10,000€を超える場合、海外の事業者でも支払う必要があるようです。確か、日本の消費税は、海外の事業者が日本で販売した場合、非課税になったと思いますが。

物理的なモノの取引であれば水際（＝税関）でチェックが働くから、制度上問題ありませんが、電子商取引の場合、物理的なモノが無いから、完全に事業者側の自己申告に頼るしかないので、制度上問題があります。つまり、善意者の過失を防ぐ手段が無いことが問題です。例えば、国内の取引であれば、（自国の）法律を知らないでは済まされませんが、消費間接税については相手の国の法律によるものなので、どちらかというと知らない方が普通です。

ちなみに、Appleの場合、（EUのVATが問題になるのは有名な話しなので）Appleがその辺りを代行してくれるようですが、Googleの場合、その辺りのことは、各デベロッパに○投げという契約になっています。
どっちが正しいのかは微妙。
取引の公平性という観点で、Appleのやり方が正しい気がしますが。
というより、そうしないと税の面でクリーンな取引は不可能なんじゃないかな・・・と、思います。

さて、どうしたものか。

Invader Block 2 was uploaded in SOFTPEDIA

Invader Block 2（Windows版）が、SOFTPEDIAさんという海外サイトで配布開始されたようです。
http://games.softpedia.com/get/Freeware-Games/Invader-Block.shtml

Download.comの紹介文は私が書いたのですが、上記はSOFTPEDIAのライターさんが紹介文を書いてくれました。意思疎通する程度の英語を書いたり読んだりするのは概ね問題無いのですが、英語圏の方の感覚にマッチした書き方は分からないので、助かります。
「アルカノイド＆スペースインヴェーダーにインスパイアされたファンゲーム」
とのこと。
なるほど。

アップロードから数分程度しか時間が経っていないのですが、もう、15本ぐらいDLされたようです。
これで、ちょっとは海外でも（Android版が）売れるかな。
まぁ、売れる売れないは別として、色々な国の人に遊んで貰えるだけでも嬉しいものです。

スクリーン仕様変更

開発中の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ステージあたりのザコ敵数って果たして何種類ぐらいなのか・・・

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

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