動画を投稿完了

InvaderBlock2の動画を投稿完了。
http://www.youtube.com/watch?v=ecYfLS14WZc&feature=youtu.be


URLダイレクトアクセスで見れる設定なので、多分上記リンクからなら見れる筈。
Androidマーケット公開時にフルアクセスにします。


しかし・・・画質が、粗い。
YouTubeエンコで30FPSになったので、フレーム間隔で表示しているものが、見えたり、見えなかったりしているし・・・まぁ、良いか。

ちなみに、１回撮影後に画面の細かい仕様変更をしたため、TAKE-2です。
あと、ゲームは実機ではなくWindows版です。（カメラが無いので、Android版は録画できない...）

宣材なんだから、もっとシッカリ編集したいところですが、動画編集系のツールは持っていないので、未編集のノーカット放送でお届けしています。（ゲームのプレイはリプレイ再生ですが）
そもそも、開発機のメインPCのCPUがAtomなので、動画編集など無謀。。。

InvaderBlock2のリリース予定日

３月１日リリース予定です。

残す作業は、

⑤最終デバッグ
⑧紹介文（英語）執筆
⑨紹介動画の録画

明日、会社が休みなので、⑨（動画）は今日～明日中にはできる筈。

⑤（最終デバッグ）は、バグらしいバグはもう無いので、Windows版の方でデバッグコードを仕込んで、通常ではありえないケースの検証をしたりします。これも今日、明日中には完了する筈。

一番の難関は⑧（英文）。

⑧（英文）は、会社の英語が得意な人（TOEICが900点台？の人）にお願いする予定。
私も一応、英検４級をもっているので、そこそこデキるんじゃないかと思っていますが、念のため。

今回の開発での唯一の他力本願部分。

煙草一箱で引き受けていただく請負契約を口約束で締結済み。

あとは、Android版の公開が完了次第、ホームページに紹介ページを作って、Windows版（無料）の配布を開始する準備とか。ちなみに、Windows版はVectorに掲載する予定なので、掲載は早くとも３月中旬頃だと思います。

Android特有のバグ

今回、Windows版を最初に開発し、Android版へ移植という開発プロセスで開発してきました。
総括してみると、Windows/Androidでのプラットフォーム誤差というのは、大して無いです。
なので、この開発プロセスが一番生産性が高いんじゃないかな？と、思っています。

唯一、悩んだWindows/Android間のプラットフォーム誤差は、
タッチを離した瞬間の座標情報
です。

Windows版の場合、デバイスの入力にマウスを用います。
そして、

• マウスのクライアントウィンドウ内での座標情報をタッチ位置
• マウスの左クリックの状態をタッチ有無

という感じで入力情報を取得していました。

で、ゲーム中のボタンなどについては、タッチを離した瞬間（１フレーム）を判定機会とします。
その時、タッチを離した瞬間の座標情報が当り判定する位置となります。
マウスの場合、タッチ状態（左クリック）を離しても、座標情報は生きています。
しかし、Android（タッチパネル）の場合、タッチ状態を離すと座標情報も死にます。

冷静に考えてみれば、当たり前のことなんですがね。
しかし、このバグ原因を究明するのに結構時間が掛かりました。（２時間ぐらい）

---

まぁ、上記の問題はプラットフォーム依存コード（=VG-Engine）で吸収できます。
なので、VG-Engineの設計ミス。

こういうマイクロな問題を単純な「アプリケーションのバグ」ではなく「設計ミス」と認識することが、共通プラットフォームエンジンを作る上では重要な考え方になります。両方とも同じバグですが、プラットフォーム共通化エンジンの代表格であるOS設計ベンダーというのは、得てしてそれを「アプリケーションのバグ」という・・・ある程度、仕方の無い事情もありますが。

その他の事（グラフィックやサウンド等の純粋なハード依存部分）は、仮想的なエンジンを自前で作れば、割と簡単にプラットフォーム共通化ができます。（それが大変な訳ですが）

今回設計したプラットフォーム依存コードのWindows/Android各々の規模を見てみると、

• Windows+DirectX → 1030行(C++)
• Android → 533行(C) + 229行(Java) = 762行

という感じ。

つまり、Windows+DirectXのプログラミング知識があれば、Androidの方が必要な知識（情報量）が少ない分、楽。
恐らく、iPhone化ならもっと簡単なんじゃないかな。想像ですが。
Objective-C（＝Apple専用言語）というのが厄介ですが、Cのソースコード互換性を100%保っていてくれれば、別に大きな問題ではないと思います。（iPhone化を見越して、プラットフォーム非依存コードはすべてC++ではなくCを使うようにしていたりする）

リプレイ保存機能

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

直前にゲームオーバーになった情報があれば、「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日程度の期間を要する点につき、同意する。

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