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を使うようにしていたりする）