データ格納方式の改善

一つ前の日記で、「失敗したなぁ～」と思っていた部分を残す必要は無いので改善。
良質なモノ作りをするコツは「思い立ったら即行動」です。

まずは、Windows版を修正。
Windows版のInvaderBlockV2を構成するファイルは次のようになりました。

ファイル構成

• IBLOCK.EXE: Windows版VG-Engineを組み込んだInvaderBlockV2実行モジュール
• ROMDATA.BIN: 画像データ（独自形式）+音声データ（独自形式）
• LOG.TXT: 実行ごとにラップラウンドするログファイル（RAM-DATA）
• SCORE.DAT: ハイスコア情報を保持するファイル（RAM-DATA）

だいぶスッキリしました。
これで、Android版のJavaコードもスッキリと書けます。

ROMDATA.BINというのがファイルを纏めたヤツです。
.BINというのは独自形式。
これは、昔作ったシューティングゲーム（SHOT03）で採用した方式です。
ソースコードは99%そのまま流用できました。

ちなみに、.BINファイルに圧縮されている画像データ＆音声データも独自形式。
独自形式ばかりだから、ハッカーが解析するのが面倒かも。
一応、簡単な独自処理の暗号化処理をやっているので。
面倒なアルゴリズムは使っていないので、見る人が見れば、すぐに解読できますが。全世界向けに公開するゲームとなると、面倒なアルゴリズムを使うと、実装以上に面倒なことにもなりかねませんし。

なお、全て独自形式にしておけば、プラットフォーム間の移行性が高くなります。
もちろん、独自形式のレコード仕様の設計方式次第ですが。
「設計方式」というと大層なモノに聞こえますが、ポイントは、

• エンディアンの考慮
• バウンダリ調整の考慮

程度の一般的なことだけで十分。
その二点さえ抑えておけば、プラットフォーム間でのデータ互換性は概ね保たれます。

意外と面倒くさいリソースの扱い

Androidの場合、独自形式の読み込み専用データファイルは、コンテキスト上のRawResourceという領域（正確にはzip形式に圧縮したapkファイル内にあり、AndroidJVMがそれをアプリケーション・コンテキストの一部として扱う）で保持していて、それを取得してFileReadStream等で読み込むのですが、それが意外と面倒くさい。

上記の説明内容からして、明らかに面倒臭い訳ですが。
ただ、面倒なのはJNIからそれを読み込ませる方法。
結局以下のような形で、実装。
簡単に解説すると、

• RawResourceの内容を読み込むextractResource関数というのを実装
• バイト配列形式で読み込みsetResource（独自JNI関数）でCヒープに展開
• Cヒープでは、リソース名(getResourceName)をキーとした線形リストで保持

という感じ。

ちょっと失敗したなぁ～と、思っているのは、独自形式のファイルを１つのファイルに纏めて、それだけJava経由でCヒープに展開すれば良かったか・・・という点。

グラフィック系統のAndroid化

VG-Engineのグラフィック系統のAndroid移植に難産中。
技術的なところの疑問は綺麗に解消しているのですが、「どの方式でいくか」で。

一般的に、画像処理性能が求められるAndroidプログラムの場合、OpenGLを用います。
しかし、OpenGLは3D専用だからやめました。
もちろん、巷ではOpenGLを使って2Dゲームを作っている方も多いと思います。
それらを否定するものではありません。

OpenGL非採用の原因は、ビデオメモリをロックしてメモリ内容を転送する手段が無いこと。
一応、テクスチャ画像をロックして、テクスチャ領域へメモリ内容を転送し、ポリゴン経由で出力する手段も無くは無いでしょうけど。

しかし、それを用いて画面全体分（240x320）の大き目の画像表示する性能が、果たして実用に耐え得るものなのか・・・が、疑問。ついでに、テクスチャのサイズが一片につき2のn乗でなければならない制約が引っ掛かりました。（つまり、私が目的とする使い方を想定した仕様ではない可能性が高い）

という訳で、SurfaceView+AndroidBitmap+Canvasを用いる方式で実現する方向性に切り替え。
（その決断をするための判断材料を得るのに難産しました）

とりあえず、グラフィック部分のみのJava側の実装はアッサリ完了。
折角なので、晒しておきます。

■アクティビティの実装
単純にスクリーン設定をしてサーフェースビューをコンテントビューに設定するだけ。

■サーフェースビューの実装

div class="separator" style="clear: both; text-align: center;">

ちょっと長いですね。
コンストラクタで仮想VRAM情報のAndroidBitmapを作成し、メインループ（スレッド）関数で仮想VRAM情報を更新する関数を呼び出し、その結果をカンバスクラスのビットマップ書き込み関数で更新する感じです。

Javaは反吐が出るほど大キライなので、Java実装はこれにてほぼ完成です。
可能な限り、Javaでは書きたくありません。
あとは、不可避な事情が発生した場合に限り、必要に応じて最小限の実装を追加するだけ。

やり込む

InvaderBlockのWindows版を公開する場合、昔作ったInvaderBlock(2009年版)とは別ゲームとしてVectorに登録しようと思っているので、InvaderBlockV2に名称を改めることにしました。
「改める」と言うのがはばかれる程度のマイナーチェンジですが。

で、肝心のAndroid環境へVG-Engineを移植する作業は不調。
ポーティングはやるべきことが決まっているから苦手です。
InvaderBlockV2のデバッグ・・・という名の遊ぶ作業に夢中でした。

とりあえず、最大で32,680点をたたき出しました。
ちなみに、ステージ（ラウンド）は全５面。
まだ、実力では２面をクリアしたことがないけど、良い感じの難易度だと思います。

得点のシステム的には、

• 打撃得点（初期値10pts～お札を5枚取る毎に10pts増加）
• 破壊得点（ヒット数×10pts）
• お札得点（ヒット数×100pts）
• クリア得点（お札数×100pts）
• ヒット数はステージ毎にリセット
• お札数は累積

という感じに落ち着きつつあります。
まだ、若干調整するかもしれませんが。

序盤は見た目も派手だし得点を稼げるヒット数の高いパターンを狙うのが吉です。しかし、終盤は序盤から溜め込んだお札の数に応じて打撃得点とクリアスコアが大きくなるから、必ずしも多段ヒットを狙うことがハイスコアを狙う秘訣ではない・・・という感じ。（多段ヒットで倒せば、それだけお札が大きく散らばってしまうから、それだけ回収率が悪くなってしまいます）

デバイスとの同期

ようやく、Android上で動くものを開発する前準備が整いました。
・・・が、やはりAndroidのエミュレータ上で開発するのは色々と面倒。
エミュレータが遅すぎなので。

そこで、実機とPCをUSB接続で同期し、PCでコンパイル→実機転送という方式に切り替え。
この方が、エミュレータでデバッグするよりも楽。

実機（LenovoのIdeaPadA1）のWindows7(64bit)用のUSBドライバを探すのにちょっと手間取りましたが。
正規のLenoveサイトだとサッパリ見つからないかったので、以下のフォーラムから入手。
http://forums.lenovo.com/t5/IdeaPad-Slate-Tablets/Ideapad-A1-Windows-7-USB-Connection/td-p/587655
http://www.tinybeetle.us/A1_USB_Driver_20110816.zip

有志制作のドライバ？
アメリカ語が達者ではないので、よく分かりませんが。

ランキングをどうするか

とりあえず、InvaderBlockが一通り完成。

スコアアタック主体のゲームなので、当然、ローカルでのスコア保存には対応。
下図のように、１位～１６位まで。

しかし、本当はネットランキングに対応させたい。
Androidならそういう環境が整っているかなぁ～と、思ったりしていましたが、不明。
まだ、よく調べていませんが、たぶん、無いでしょうねぇ。
ある程度、余剰収益が出たら、iPhone化の後でサーバを立てる計画。
たぶん、それは無理だろうなぁ～と、思ってますが。

追記：完成というのは、VG-Engine上で動くほうのゲームのことで、VG-EngineのAndroid移植は未だです。

計画～どう公開するか

ようやく、InvaderBlockゲーム本編の実装が完成しつつあります。
ゲーム本編が完成したら、いよいよVG-EngineをAndroid移植する作業。
VG-Engineの仕様は固まっているので、移植は流れ作業みたいなものです。

それが完成後にどのように公開していくのかが悩ましい。
完全無料でポンと出すのでも良いです。
ですが、折角だからちょっとお小遣いを稼ぎたいという淡い欲望もあります。
VG-EngineをiPhone/iPod touchに移植する設備投資費用に充てたいので。
しかし、無名個人が出す＆ろくにマーケティングしないソフトが１本でも売れるのかが疑問。

という訳で、

• Android版(1): 無料＆広告（アフィリエイト）有り
• Android版(2): 1$程度の広告無し
• Windows版: 完全フリー（Android版を紹介するマーケティング用）

という３本立てで出そうかと検討中。
Windows版はオマケみたいなもんなので削るかも。

さらにその先の課題としては、

• VG-EngineのiPhone/iPod touch移植
• VG-Engineの機能拡張（音声合成＋PSGエミュレーションなど音声関連の強化）
• 他ゲームの開発＋公開

他ゲームについては、今回のInvaderBlockの公開方法を去就する予定。
予定は未定ですが。
まずは、目先のゲーム仕上げ+Android移植が優先。