「ロックマンモバイル」で思うUIやデータ保全の難しさ

個人的にはロックマンはプレイしたことがないのですが、最近iOS/android向けがリリースされたそうで。

しかし、どうも評価がよくないようです。

海外でのレビューもご紹介。

「今週出た悲惨な『ロックマンモバイル』は何が悪かったのか？」

タイトルからわかる通り、ボコボコです。

2つのレビューで共通する最大の問題は、操作感が悪いこと。フレームレートが不均一になってしまうように見えます。

実のところ、現代のコンピュータは非常に高性能になっているものの、それはスループット的なもので、レイテンシなどの面では、色々な層での仮想化やバックグラウンドタスクにより、昔より守りづらいと思います（ARM Cortex-Mなどマイコンクラスを使ってハードリアルタイムにするか、もっと上位のCPUでもソフトリアルタイムにすればいけますね）。

ところで、ars technicaの記事の末尾にある「Promoted Comment」が興味深いですね。真偽は不明ですが。

（記事中で言及のある）ロックマン2 iPhone版を2009年に実際に作っていた者です。

実は、2009年のものは移植版でもエミュレータでもありませｎ。私はBREW上のC言語版を渡され、それをObjective-C/C/OpenGL環境に移植したんです。

（訳注）BREWはQualcommが作った携帯電話向けアプリ環境。日本ではau（EZアプリ）が採用。

移植に使ったコードはオリジナルではありません。元コードの開発チームは、イチからゲームを作り、素材はネット（sprites.co.ukなど）から取得したものです。私たちは日本のCapcomに問い合わせましたが、彼らはオリジナルの素材を一切残していないとのことでした。

私は、古いガラケー向けの非常に出来が悪い版をもとにiPhone向けを開発するよう指示されました。私たちの元の版に欠けていたボスやステージ、素材、敵などは追加しました。敵の動きも、なるだけオリジナル版に近づけるよう再現したつもりです。

2009年のiPhone版は、2つのリリースがありました。1つは、ロックマンのジャンプすらおかしい（三角形の軌跡でジャンプしてしまう）もの、もう1つは95%の完成度のものでした。

ところで、記事中の、（今回のiOS/android版アプリの）サイズが（元を考えると）大きすぎるというコメントについては、簡単に説明してもいいのですが：

OpenGLのテクスチャは、インデックスカラー（CodeZine、Wikipedia）が使えないため、ロックマン自身の状態に応じて、あるいは敵のバリエーションとして色を変えるのに、単にインデックスを1つ追加するのでは済まず、それぞれのスプライトをアニメーションの各フレーム分全て準備しなければならず（なお、私たちが元にした版ではロックマンは約20個の部分に分けられていました）、しかもそれを16パターンぐらい用意する必要がありました。また、MIDI風の方式による（データ量の小さな）音楽再生もできないので、代わりにOgg Vorbis形式で保存しました（当時はMP3プレイバックに使える良いAPIがなかったのです）。

（訳注）ファミコンはPSG音源だが、音程などを数値で与えるためMP3やOggよりMIDIに近い。

常に60fpsで動かすには、かなりの努力が必要でした。なお私はCapcom MobileがBeelineに改名する前に退職しました。ちなみに、同スタジオは最近解散しました。

くどいようですが、真偽は不明です。とはいえ、これが本当なら、まるでテレビ創世記の番組が放送局に残ってないのと似ていますね。

1回作ったものが、意外なほど後まで参照されることがあることを考えると、なんとかデータはバックアップをとっておきたいものです。自分が「大したことない」と思うと、つい消したり捨てたりしてしまいますが。