Unity の API とプロジェクト構造のほとんどは、サポートされているすべてのプラットフォームで同等であり、プロジェクトを他のデバイスで実行できるように再ビルドできる場合があります。しかし、ハードウェアやデプロイメソッドの根本的な違いにより、プロジェクトの部分によってはプラットフォーム間で移植できない場合があります。このページでは、クロスプラットフォームに関する一般的な問題と、その解決策を紹介します。
プラットフォーム間での異なる動作のもっとも良い例は、ハードウェアによって提供される入力方法です。
Input.GetAxis 関数は、デスクトッププラットフォームでキーボードとジョイパッドの入力を統合するのに便利です。この関数は、タッチスクリーンでの入力に依存するモバイルプラットフォームには適していません。デスクトップの標準キーボード入力は、入力したテキストをモバイルデバイスに移植することにのみ適しています。他のプラットフォームに今後移植することを検討している場合は、入力コードに抽象化のレイヤーを追加することができます。例えば、ドライビングゲームを開発しているのであれば、独自の入力クラスを作成し、Unity の API コールを独自の関数でラップできます。
// Returns values in the range -1.0 .. +1.0 (== left .. right).
function Steering() {
return Input.GetAxis("Horizontal");
}
// Returns values in the range -1.0 .. +1.0 (== accel .. brake).
function Acceleration() {
return Input.GetAxis("Vertical");
}
var currentGear: int;
// Returns an integer corresponding to the selected gear.
function Gears() {
if (Input.GetKeyDown("p"))
currentGear++;
else if (Input.GetKeyDown("l"))
currentGear--;
return currentGear;
}
API コールを 1 つのクラスでラップして、1 つのソースファイルに配置することで、コールの検索や置き換えが容易になります。入力関数は、ゲームでの入力の論理的な意味に合わせて設計してください。これは、特定のプラットフォームで使用される特定の入力方法と、ゲームコードの他の部分を分けるのに役立ちます。
例えば、実際の入力方法がモバイルデバイスの画面タッチになるように、上記の Gears 関数を変更できます。選択されたギアがすべてのプラットフォームで動作することを整数で表すことはできますが、プラットフォーム固有の API コールを他のコードに混ぜてしまうと、問題が発生する可能性があります。プラットフォームに依存するコンパイルで、同じソースファイルにある入力関数のさまざまな実装を組み合わせることにより、手動スワップを省くこともできます。
Input.GetMouseButtonXXX 関数は、モバイルデバイスで明らかに解釈できるように設計されています。画面は単純なタッチを左クリックとしてレポートし、Input.mousePosition プロパティは、指が画面に触れている限り、タッチの位置を示します。簡単なマウス操作のゲームの多くは、デスクトップとモバイルのプラットフォーム間で、透過的に動きます。
変換はそれほど単純ではないことがほとんどです。例えば、デスクトップ向けゲームでは複数のマウスボタンを使用できて、モバイル向けゲームでは画面上の複数のタッチを同時に検知できるとします。このような場合には、入力を論理的な値で表し、それを他のゲームコードで利用しきます。
例えば、モバイルデバイスでズームするための摘むジェスチャを、デスクトップで +/- キーを押す操作に置き換えるには、ズーム係数を指定する Float 値を入力関数で返すことができます。同様に、デスクトップでの右ボタンクリックをモバイルでの 2 本指タップに置き換えることもできます。ただし、入力デバイスのプロパティがゲームに不可欠な要素であると、別のプラットフォームでそれらを作り替えられない場合があります。つまり、ゲームを移植できなかったり、入力やゲームの大幅修正が必要になったりする可能性があるということです。
これらは、ハンドヘルドデバイスが持ち運べるために派生した入力方法であり、デスクトップにはそれらに相当する有意義な手段がない場合があります。ただし、ユースケースによっては、ゲームの標準制御が単純なミラーによって簡単に移植されます。例えば、モバイルデバイスの傾きを加速度センサーが検知するステアリング制御をドライビングゲームに適用するとします。このような場合に、入力 API コールは通常では簡単に変更できますので、加速度センサーによる入力をキー操作に置き換えることができます。
ただし、入力方法に合わせて、入力を再調整したり、ゲームの難易度を変えたりすることが必要となる場合があります。デバイスを傾けるには、キーを押すよりも大きく動く必要があるため、画面に集中することが難しくなります。モバイルデバイスでゲームを使いこなすことが難しくなるのであれば、ゲームプレイの速度を遅くするか、レベルごとの制限時間を長くすることが妥当であるかもしれません。そのためには、これらの要素を調整するゲームコードを設計する必要があります。
モバイルデバイスでは、デスクトップマシンに比べて利用できるストレージ、メモリ、CPU の能力が低いため、ゲームの移植が難しい場合があります。その理由は単純で、性能の低いハードウェアでは望ましいパフォーマンスを得られないからです。デスクトップハードウェアの能力を最大限に活用するゲームは、モバイルプラットフォームへの移植には恐らく適していません。
ビデオ、オーディオ、テクスチャが多くのストレージ容量を使用することがあります。ゲームを移植するには、ストレージを有効に管理する必要があります。ストレージの容量は、ダウンロード時間に影響することも多く、デスクトップマシンで問題になることは通常ありませんが、モバイルデバイスでは制限されることがあります。モバイルアプリストアが、提出されるプロダクトの最大サイズを制限することはよくあります。ゲーム開発中にこれらの懸念への対策を立てなければならない場合があります。
例えば、容量を節約するために、モバイル用に簡略化したバージョンのアセットを提供する必要があるかもしれません。大きなアセットをアプリケーションの最初のダウンロードに含めるのではなく、必要に応じてダウンロードできるようにゲームを設計する必要があるかもしれません。
Unity は、使用していないオブジェクトから未使用のメモリを回収する処理を自動的に行うため、デスクトップマシンではそれに気づかないかもしれません。しかし、モバイルデバイスではメモリや CPU の能力が低いため、ガベージコレクションが頻繁に発生し、パフォーマンスに影響を与え、ゲーム中に不要な一時停止を発生させます。使用可能なメモリでゲームが動作したとしても、ガベージコレクションによる一時停止を避けるために、コードの最適化が必要となる場合があります。
詳細は、マネージメモリ を参照してください。
ゲームがデスクトップマシンでは円滑に動くのに、モバイルデバイスではフレームレートが低くなるのは、モバイル CPU がゲームの複雑さに十分に対応できていないからです。プロジェクトをモバイルプラットフォームに移植するときには、コードの効率に注意してください。