リプレイ保存機能

リプレイ保存機能が完成。
あと、サウンドミュート機能も。
タイトル画面はこんな感じになりました。

直前にゲームオーバーになった情報があれば、「SAVE REPLAY」を選択できます。

「LOAD REPLAY」を選択すると、ロードするリプレイデータ・スロットを選択する画面になります。

リプレイデータ・スロットは、ファイル形式でSDカードに保存されています。
なので、ネットで公開したり、他人の神プレイを好きな時に再生できたりします。
この機能があれば、プロモーション動画の作成も大分楽になるという開発者側のメリットもあります。

ただ、タッチパネルだと入力情報がジョイスティックと比べて多いから、必然的にデータサイズが大きくなってしまう・・・（リプレイデータは最大、約4MB...普通にプレイすれば100KB前後だと思いますが）

Android版のサウンドシステムが完成

Android版VG-Engineのサウンドシステム完成。
大分楽でした。
OpenXXシリーズ特有の手続きの面倒臭さはありましたが。

それでも「楽だった」と思ったのは、ストリーミング再生するシステムを実装するのに必要な処理を、DirectSoundみたいにマルチスレッド化する必要が無かった為です。
つまり、OpenSL部分の理解は面倒でも、独自システム部分の実装は簡単ということ。


何はともあれ、これでほぼ完成しました。
公開までの残作業は、

（１）プログラム的な部分
①スコア保存処理の修正（assetにする必要がある）→sdcardに変更(2/26)
②リプレイ保存＋再生機能の追加（これは当初予定には無かったけど、やってて欲しくなった）
③音声ミュートをタイトル画面で設定できるようにする
④ブランドロゴの挿入（これは要らないかも）
⑤最終点検


（２）事務的な部分
⑥正式な署名の準備
⑦アイコンの準備
⑧紹介文（英語）執筆
⑨紹介動画の録画

あと１～２週間ってとこか。

APIレベル引き上げ

サウンド制御のAndroid移植をしていて大きな穴が発覚。
どうも、C言語でOpenSL/ESを利用する場合、APIレベルを10以降にしなければならないらしい。

今まで、最低動作環境をAndroid2.2以降にしてました。
しかし、APIレベルを10にしてしまうとAndroid2.3.3以降になってしまう・・・。
別に、私が2.2に愛着がある訳ではないですが。
（日本では）2.2が最初に普及したので、2.3.3以降にするのはかなり微妙。

何より、Android2.3.3以降を前提とするのなら、NativeActivityにしなかったのが悔やまれる。
ただし、NativeActivityだとCanvasの使い方がよく分かりませんが。
NativeActivityは、色々とかゆい所に手が届かない。


Javaの方（AudioTrack）を使う方法もありますが、Javaだとメモリの扱いがCと比べて難しいので、バッファリング等の処理をGCを発生させずに作りこむのが、私のJava知識だと無理そうなので、Java部分ではサウンド処理は１ステップも書かせたくない・・・と考えています。
恐らく、Javaでサウンド処理を組むと、GCが多発してストレスの溜まるゲームになる筈。
パズルゲームなら良いですが、アクションゲームでは致命傷です。

やはり、Javaはキライです。
コンピュータのプログラムを作るのに向かない言語だから。
コンピュータのプログラム以外のものを作るためのプログラム言語＝存在意義なし。
Javaでプログラムを作り続けると効率性の悪いプログラムしか作れなくなる＝存在価値なし。
唯一のメリットは、保守性が悪く、将来システム障害の引き金になる可能性が極めて高い、ハイリスクなプログラムを比較的短い期間で作ることができることのみ。

あとは作るだけ

Androidマーケットへのデベロッパ登録や、口座登録などの事務処理が完了。
デポジットの確認が難儀でした。
口座登録をすると、その口座にGoogleからデポジットという物（小額の現金）が振り込まれるので、その金額を確認＆入力して初めて登録完了になります。

しかし、通帳に最後に記帳したのは約７年前で、記帳できる余白があと１行しか無い状態。
必然的に、デポジットを確認するには窓口に行かなければならないから、非常に面倒です。
なので、気合で記憶を掘り起こして、ネットバンキングのパスワードを思い出し、確認しました。
（ちなみに、ネットバンキングにログインしたのは約３年ぶり）

まぁ、色々と面倒でしたが無事済んで良かったです。
あとは作るだけ・・・と思ったのですが、商品を登録する画面に妙な記述が。。。

[抜粋] マーケティング除外
Android マーケットや Google 所有のオンライン/モバイル サイト以外ではアプリケーションを宣伝しません。この設定への変更が有効になるまでに 60 日程度かかることについて了承しています

上記の項目がデフォルトでチェックされている意味がサッパリ分からない。

「チェックを入れる」ということは、甲（Google）に対する乙（私）の意思表示という意味になります。
なので、主語は必ず「乙(=私)は」です。

つまり、「マーケティング除外」とは、
①乙は、当該物件（アプリケーション）につき、甲サイト以外での宣伝をしない事に同意する。
②乙は、この設定への変更を有効にするのに60日程度の期間を要する点につき、同意する。
という契約だと解釈できます。

まぁ、①は別に分からなくもないです。（納得できるか否かは別として）
チェックを外せるということは外せば問題無いので、問題ありません。

問題は②。「この設定への変更」の「この設定」部分の解釈。
これは、
(1)デフォルトでチェック状態になっている設定
(2)登録時に行った設定
の二通りの解釈ができます。
(1)の場合、重要事項に該当するので、登録前に事前に通知しなければ無効にできる旨で訴訟すれば認められると思います。なので、(2)と解釈するのが自然。

とりあえず、(2)という風に解釈して、チェックを外した上で堂々と説明文に「Windows版をVectorでフリー配布中です」と宣伝しておけば、仮に私に錯誤があれば審査段階で弾かれると思うから問題無いと思います。

しかし、こういうやり方はあまり（というか「かなり」）良くないので、ググってみたところ以下の記事を発見しました。
http://d.hatena.ne.jp/adsaria/20110518/1305734496
上記ブログによると、これは「Googleが宣伝することについて」の制約事項らしい。

確かに、文章からは誰が宣伝することについてか、何れでも解釈は可能でした。
なので、上記ブログの通りに解釈を改めると、
①乙は、甲が当該物件（アプリケーション）につき、甲サイト以外での宣伝をしない事に同意する。
②乙は、甲がこの設定への変更を有効にするのに60日程度の期間を要する点につき、同意する。

これならスッキリ納得できる。
なので、これが正解でしょう・・・多分。
英語は、こういう部分が曖昧な言語だから苦手です。
（一応日本語ですが、英語をそのまま訳した感じだから、ほぼ英語）

指が疲れなくなった

ちょっとした工夫により、InvaderBlockがタッチペンを使わなくても指が全然疲れなくなりました。

そもそも、何故、疲れたのか？
という点について、考察が甘かった。
実は、肉体的に疲れたのではなく、精神的に疲れていたようです。

元々の仕様は、タッチの変化（スライド）量をバーの移動量としていました。
つまり、下図のような感じ。


だから疲れた訳です。「nピクセルもスライドしなければ、バーがnピクセル動いてくれないっ!!><」
という感じで、精神的に。
一応、指を動かす動作で肉体も疲労しますが、精神的な疲労の方が一般的に厄介。

そこで、タッチしている位置をターゲットとしてバーを移動させる形に仕様変更（バーの移動量をタッチで示すのではなく、バーが移動すべき位置をタッチで示すように変更）したところ、Androidでプレイしても全然疲れなくなりました。

ゲーム画面中では、目標位置がパッと見て分かり易いように、タッチしている間、青色のラインを表示する感じにしました。

公開準備は焦る必要がなかった

一応、Androidマーケットへアプリを公開するのに必要な準備を一通り済ませました。
即日でできるから、焦って今やる必要はなかったかも。
第一、まだアプリは完成してないし。

昔、Vectorでシェアウェアのプログラムを公開するための手続きをやったときは、２週間ぐらい掛かった気がしたので、前もってやっておきました。

Androidの場合、開発アカウント作成、販売アカウント設定、口座情報の登録がそれぞれ分かれていて、開発アカウント作成（※25ドル必要）と販売アカウント設定は即日でできます。

口座情報の登録完了には、デポジット確認が必要なので、３～５営業日程度掛かるかもしれませんが、恐らく振込み発生のタイミングで問題無い状態であれば問題無い筈。
なので、有償アプリであっても、即日公開が可能じゃないかと思います。

ちょっと大きな問題

小一時間ぐらい、Android版のInvaderBlockを遊んでいて気付いた問題・・・
スライドしまくっていると指が疲れる。

ん～・・・仕様です。
タッチペン推奨ということで。
こればっかりは、どうしようもない。（仕様だけに）

ソフトウェア的なボタンを実装しているゲームも結構有ります。
でも、私が遊んだ限り、ソフトボタンは使い難いものばかりだったので、気が乗らない。
何というか、「押している」感が無いので、精神的に不安定になります。

音を鳴らして誤魔化しているものもあるけど。
でも、やはり聴覚というのは、触覚と比べて脳に伝わる刺激が弱いものだから、申し訳ない程度の解決要素にしかなりません。

iPod TouchやAndroidで決定的にマズイのは、十字キー＋４ボタン程度のゲーム・インタフェースをハードウェア的に標準搭載していないこと。
まぁ、ゲーム機ではないから、当然ですが。
（私はゲーム（開発）でしか使ってないけど）

動いた

スクリーンのタッチ検出処理を実装したところ、完全に動作するようになりました。
まだ、音は出ないけど。
ちょっとパッド（バー）の位置が下過ぎたので、指と重なって邪魔だったから、ちょっとだけ上の方に移動する程度の修正をしました。
体感的には、Windows版と概ね同じ感覚。
こうなることは想定済みでしたが、完璧です。
これでようやく、Androidで遊べます。

あとは音をつければ本当に完成。
そろそろ、Androidマーケットに登録する手続きを調べたほうが良さそうです。

色がおかしかった原因

先ほどの記事で、色がちょっとおかしかった原因が判明。
凡ミスでした。
スプライトの仮想VRAMをAndroidBitmapに設定するのは、ちゃんとAndroid用のパレットテーブル（16bitカラー）を咬ませていたのに対し、BGの仮想VRAMを設定するときに誤ってWindows用のパレットテーブル（32bitカラー）を咬ませていたのが原因。

という訳で、修正して実行したところ、問題解決。
AndroidでもちゃんとWindowsと全く同じ画面が表示されました。

ちなみに、現時点でのVG-Engine+InvaderBlockのソースコードのファイルは次のような構成になっています。

それぞれのファイルの意味は、

1. Android.mk: ndk-buildをするためのmakefile
2. com_suzukiplan_IBLOCK_IBLOCK.h: javahで生成したJNIヘッダ
3. game.c: InvaderBlockの処理
4. NUL: ndk-buildをした時に生成されるゴミファイル
5. vge.h: VG-EngineのAPIを使うためのヘッダファイル
6. vge_a.c: VG-Engine本体（Android版）
7. vge_w.c: VG-Engine本体（Windows版）※Android版ではビルドしない
8. vgeapi.c: VG-EngineのAPI
9. vgeint.h: VG-Engine本体とAPI間で共用する内部データ定義等のヘッダファイル

灰色の網掛け部分は、私が作ったファイルではなく、自動生成物です。
今回のVG-EngineのAndroid対応で作っているソースはvge_a.cのみ。
その他のソースは、Windows版から1行たりと修正していません。

要するに、Windows版とAndroid版の動きは全く同じです。
なので、今後、InvaderBlockV2のスクリーンショット等を掲載するときは、Windows版のものを載せます。

（補足）
先ほどの記事では、（テンションが高かったため）携帯でタブレットの写真撮影をし、メールでPCに飛ばし、それを載せていたのですが、私の携帯は従量課金制なので勿体無い。ついでに、携帯のSDカードは、バッテリーを外さないと取れないという、素晴らしく使い難い設計（iida製のPLYという機種）なので、SDカードに保存したデータをPCへ持ってくるのも面倒くさい。

初画面表示～テンションが上がらざるを得ない

きたぁーーーーーーー！！！


はじめて、Androidの画面にInvaderBlockのタイトルが表示されました。
ただ、パレットのbit演算（24bit→16bit変換）をミスっているらしく、画面の色が変な感じですが。
それでも、画面が概ね想定通り表示されてくれたので、テンションが上がらざるを得ません。

フレーム速度は、63～62fpsで安定しています。
音声処理を追加したとしても、VG-Engineの性能面での問題は全く無さそうです。

データ格納方式の改善

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

まずは、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移植が優先。

Windows版の扱い

InvaderBlockのWindows版の扱いをどうしようか結構迷います。
もちろん、Android版については完成したら迷うことなく公開しますが。

課題は２点ぐらい。

①入力系統
Androidで遊ぶことを想定したゲームだから、入力は当然タッチパネルを想定してます。
Windows版はマウス。
マウス専用ゲームというのは若干抵抗があるような気がしてます。
BAMBOO TOUCH等を使えば、ほぼAndroidと同等の操作性だと思いますが。
（BAMBOOはペンのやつしか持っていない・・・ペンだと滑りが微妙）

②DirectX9
元々、Windows版はデバッグ用途だから、画像系は扱いが簡単なDirectX9で作ってます。
しかし、DirectX9のランタイムはWindowsにプリインストールされていません。
大方の環境で遊ぶ場合、End User Runtimeのインストールが必要なので面倒です。

公開する場合、プリインストールされているDirectX8用に作り直したいけど、DirectX8のSDKは持っていないし、公式なサポートも終了しているから、正規ルートでの入手はできない。
公式がサポートしていない以上、どうこういっても仕方がないですが。
DirectDrawで作り直すとか・・・・は、面倒くさい。。。

ゲームシステム～ドット効果

ちょっと、ボールの軌道が追い難いかも。
Androidでのプレイを想定すると尚更。
という訳で、ボールの残像を表示。

この残像を表示するのと同じ仕組みを使って、ついでに背景で星を表示してみたり。
少し分かり難いですが、残像自体の残像も入れてみたり。
静止画だと分かり難いですが、結構美しくアニメーションしてます。
この残像は、いわゆるパレットアニメーションってヤツですね。

これで若干難度が緩んだかも。
私のゲームは全般的に、難度が高すぎるので、適度に調整していきたいです。

ゲームシステム～ボーナス

侵略者を撃破すると、ボーナスアイテムを出すようにしてみました。

ボーナスアイテムをパッドに当てれば、現状の最大HIT数×10点が入るという具合。
今の最大HIT数を確認するため、左下に現状の最大HIT数を表示。

これで、欲望に忠実な人にとって、ゲームの難度があがったかも。
稼ぎ要素として大分幅が広がりました。
まだまだやりたい事が多いのですが、如何せん、平日は時間が少ない。。。