ゲーム移植百花繚乱ものがたり

最近、ゲームの移植って増えてきてますよね。。

「なんでこの会社の移植ってこうなんだろう」って議論になることも多い気はします。

何年もゲーム移植erみてると千差万別いろいろあって意外に面白いので、おおまかな各手法をなんとなくでまとめてみました。

移植手法１:ソースを譲り受けて移植する

一番思い浮かびやすく、一見(?)ホワイト仕事に見えるのがオリジナルゲームタイトルのソースやリソース（画像・音）を引き取って移植するパターンです。
PS1とかPS2をPS5向けに移植みたく、新しいハードに合わせてコピーするなどで多いイメージです。

ただ、条件があって

・そもそもソースがある
・リソースもそろってる
・コンバーターも当時のものがある

など好条件じゃないとなかなかうまくいきません。

また、一見ソースがあるからオリジナルの挙動を再現しやすいように思えますが、ソースを書いた人や企画、データ作成の意図を読み取る力が必要になります。
前任者が近くにいる、もしくはオリジナルのものを作った人が行う場合はまだマシですが、もしそれらの人が存在しない場合は想像しながらだったり、その場で新たな解釈を作業者が生み出す必要があったりします。

リソースもまとまっていたとしても、どの箇所でどのように使うのか？設計図があいまいなプラモデルを組み立ててるような地道な仕事をひたすら行っていきます。

コンバーターに関して言えばプラットフォームが変わればほぼ確実にオリジナルのものは使えず、これも元の意図を汲み取って再作成する必要があります。
ここに関しては翻訳するのに近いかもしれません。

メリットとしては

・ソースを知れば改変が可能、追加要素もできないことはない
・時間をかければ新しいプラットフォームに最適化もできる

などがあります。

ソフトのアップデートもできるのでコンテンツ寿命を延ばすこともできるようになります。

移植の技術レベルとしてはコストが低いですが、コミュニケーションや想像力の部分ではコストが高くなりがちです。

移植手法２:エミュレーターを作って ROM イメージを動かす

最近よくあるひと月、もしくは１、２週間程度でバンバン移植されてるシリーズはよくこの手法が使われていることが多いです。

元のプログラムソースや、リソースは一切必要とせず。実際に稼働していた実機の ROM (ゲームソフトやゲーム基板)から吸い出したものをほぼ改変せずに使うことが多いです。

作成するソフトは、例えばファミコンのカセットから吸い出した ROM イメージを動作させるエミュレーターを作成するのが主です。

メリットとしては

・吸い出してエミュレーターで動かすので１度できると同じプラットフォームのものが早い（ひとつファミコンエミュができれば後に続きやすい）
・販売してたり開発後の ROM (カセット)が有ればプログラムソースもリソースも要らない
・量産が早い
・データを流して動かしてるだけなのでオリジナルを作った人の意図や企画意図なども関与を抑えて、かつオリジナルのテイストに近く提供できる
・総じてひとつひとつがコストが安くてソフトの販売価格が下げることができる

対してデメリットは

・大きな改変ができない
・エミュレーターを作成するのにコストがかかる上アップデートが必要
・新しいゲーム性や時代にあったゲームテイストの変化などは行えない
・ROM バイナリに対しての知識が必要(ファミコンの CPU 構造を熟知してる必要がある)

などがあります。

コスト安く早いのでレトロゲームを安く楽しみたいニーズにあっているので最近メインな手法のひとつになっています。

しかし基本的にはエミュレーターの上で動いているため、たまに遅延やオリジナルの再現度が低いなどソース受け取りよりも低品質になる場合も発生しやすいです。

移植手法３:ROM イメージを イマドキなソースに変換する

ROM 吸い出しだと改変ができない、ソース受け取りするには条件が足りない、と言う場合でも、ユーザー満足度を上げるためにより一つ上の移植を行いたい場合もあったりします。

そういう場合によく使われるのが ROM から吸い出したバイナリを 逆アセンブルし、更に C/C++ などのモダンなプログラムソースに置き換えるパターンもあります。

ゲームエンジン Unity の IL2CPP という手法で似たようなプラットフォーム最適化を行っています。

IL2CPP のしくみ - Unity マニュアル

メリットとしては

・一度C/C++に変換してからプラットフォームごとにコンパイルするのでエミュレーターと違って挟まっているものがなく動作が速い
・わかりやすいソースに変換するので新たな要素やゲームテイスト、新ゲームモードまでの改変がダイナミックに行える
・クオリティも高く、より感覚的にオリジナルに近いゲームを作り出すことができる
・オリジナルのプログラムやリリースは要らない

などがあり、いいことづくめに見えますが、デメリットとしては

・ソース受け取りのようなオリジナル制作者の意図を解析する作業が少しはいってくる
・元プラットフォームの知識と移植先のプラットフォームの知識両方がより必要になってくる(アセンブラからC/C++まで理解が必要)
・コストが総じて高くなっていく

などのものが考えられます。

単純な過去作のコピーではなく、付加価値はつけやすくなるのでこの手法を選択してる場合もあります。

その他ゲーム移植法

あんまり主流ではないけどユニークなゲーム移植法もありました。

アセンブラを読んでイマドキなソースを手で書く

前述のものはコンバータを作成して機械的におこなうのですが、過去のアセンブラソースを目視して、最近つかわれるプログラム言語C/C++等に手で書き起こすという手法もあったりします。アセンブラにもC/C++にも知識がある熟練エンジニアがひとりで行うなど、小規模なプロジェクトであったりします。

古いソースをイマドキなソースに変換する

機械的に変換を行うのですが、スマートフォンなどでは C#(Unity)が主流なため、C/C++ → C# と変換するツールを作成したり購入したりして大まかな変換をしてから手で直す、という手法もあったりします。PS2 のドラゴンクエスト８をスマートフォンへの移植の際はこの手法が使われたそうです。

アセンブラからの変換に比べると文章変換に近いですが、効率的に目的に果たすためには有効にも思えます。

移植の手法は各社得意なのをひとつだけ持ってる

これらの移植手法はひとつひとつ思想が違うので、全部の手法を１社でやってることはほぼなく。大体１個の手法を軸に会社のワークフローを組み立ててることが多い気はします。

「この会社、移植安くて早いんだけどたまに遅延とか気になる」とか「こっちの会社の移植はすごく質が高いんだけど、リリースタイミングが」「なんで同じ移植なのに価格違うんだ?」というのもこれらの手法が起因してる部分は多い気はします。

でも、ゲーム移植も大変だし各社頑張ってるので生暖かく応援していってほしいものです。。