ほとんどの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 コールをラップするメリットはこのようなクラスは,ひとつのソース ファイルに集約されて,結果的に簡単に見つけられて置き換え出来ます。しかし入力関数をゲームにおける論理的な意味に沿って作ることがより重要なことです。これによってゲームのコードを特定プラットフォームの特殊な入力手法から切り離すことが出来ます。例えば,前述のGears()関数を修正して実際の入力がモバイルデバイスの画面タッチから受けるように修正出来ます。整数を使用してギアを選択するのはあらゆるプラットフォームで十分に機能しますが,プラットフォーム固有のAPIコード残りのコードと混ぜることは問題の種です。プラットフォーム固有のコンパイルによって,同じソース ファイルにある入力関数の様々な実装を組み合わせ,手動による置き換えを回避することは便利かもしれません。
Input.GetMouseButtonXXX 関数はモバイルデバイスでは実際に“マウス” がないにも関わらず,理屈に合った明白な解釈がなされるように設計されています。画面でのシングルタッチは左クリックとして返され,Input.mousePosition プロパティは指が画面をタッチしている間はタッチの位置を戻します。これはつまり簡単なマウス操作のあるがデスクトップとモバイルプラットフォームで同様に移植出来るということです。当然,実際の変換はもう少し分かりづらいものです。デスクトップのゲームはひとつのマウスボタン以上を活用出来て,モバイルゲームは画面上の同時マルチタッチを検知出来ます。
APIコールと同様,この問題は入力を論理的な値で表現することによって一部は管理が出来ます。例えば,ピンチ ジェスチャーによってモバイルデバイスでのズームはデスクトップで＋／－キーで置き換え出来ます。入力関数は単ズームに関するfloat値を返すことが出来ます。同様にしてモバイルデバイスのダブルタップをデスクトップの右クリックを置き換えることが出来ます。しかし,もし入力デバイスのプロパティがゲームに統合されたものであると別のプラットフォームで再度モデル化することは出来ないかもしれません。すなわちゲームは完全にポートすることが出来ないか,または入力および／またはゲームプレイの大幅修正が必要となることを意味します。
これらの入力はハンドヘルド デバイスのポータビリティに由来するものであり,デスクトップでは意味ある代替手段はないかもしれません。しかしいくつかのケースでは単に標準的なゲーム制御を踏襲しているのみであり,この場合にポートする,ことはかなり容易です。例えばカーレースではステアリング制御をモバイルデバイスの画面の傾き（加速度センサーなより判断）で実装するかもしれません。このようなケースでは入力APIコールは比較的置き換えが容易であり加速度センサーの入力はキー入力などで置き換えます。しかし入力を再度カリブレーションしたり,異なる入力方法によってゲーム難易度を変更することが必要かもしれません。デバイスを傾けるのはより遅く全体的ににキー入力より骨が折れる作業となり,画面に集中することはが難しくなったりします。結果としてモバイルデバイス上の方がマスターすることが難しく,ゲームプレイをもう少しゆっくりにするか,レベルで許容するラップタイムを緩めるなどした方が適切かもしれません。このためにはこれらの要素の調整が容易に出来るようなゲームコードの設計が必要となります。
モバイルデバイスは必然的にメモリ,ストレージ,CPUパフォーマンスがデスクトップマシンより劣り,パフォーマンスが十分でないために,ゲームをポートすることご出来ない場合があります。いくつかのケースではリソースの問題は管理出来ますが,もしデスクトップマシンでも性能限界まで引き出そうとしている場合はモバイルプラットフォームにポートする候補として不向きです。
現在,モバイルデバイスは動画再生をするときはハードウェアサポートに強く依存しています。実際には再生オプションが限定されていて,MovieTextureアセットがデスクトッププラットフォームで提供する柔軟性は提供されていません。動画はモバイルでフルスクリーン再生出来ますが,ゲームのオブジェクトのテクスチャとして使用することはスコープ外の仕様です（例えばゲーム内のテレビ画面に動画を映すことは出来ません）。ポータビリティの観点では,動画を導入部,シーンのカット,説明,および短いプレゼンの中で使用するのは問題ありません。しかし,ムービーがゲーム世界と同居して表示する必要がある場合はモバイルの再生オプションが適切か考慮が必要です。
動画,音声,さらにはテクスチャは多くののストレージ容量を使用するかもしれず,ゲームをポートするときはこれを意識する必要があります。ストレージ容量（多くの場合ダウンロード時間とも関連する）は典型的にはデスクトップマシンでは問題となりませんが,モバイルでは状況がが異なります。さらにモバイルのApp Storeは提出した製品に容量制限を加えることがあります。これらの懸念を解消するにはゲームの開発時のプランニングが必要かもしれません。例えばで容量カットしたモバイル版のアセットを用意して容量の節約をする必要があります。
“死んだ” オブジェクトからの未使用メモリ回復はUnityにより自動的にハンドリングされていて,デスクトップマシンで気付かないうちに 行われます。しかし低いメモリおよびCPU処理能力のモバイルデバイスではガーベージコレクションはより頻繁に行われ,パフォーマンスにより甚大な影響を及ぼすこと（ゲームプレイのなかで不要な待機の要因となる,など）があります。たとえゲームが利用可能なメモリの範囲で実行されても,それでもコードを最適化してガーベージコレクションによる待機を避ける必要がある場合があります。詳細については メモリ管理のページ を参照下さい。
デスクトップマシンでスムーズに動作するゲームがモバイルデバイスで十分なフレームレートが出ない理由として,モバイルCPUがゲームの複雑さに耐えられない場合があります。効率的なコードであることはモバイルプラットフォームへポートするときは特別に注意を払う必要があります。いくつかの簡単なステップにより効率をあげる方法はマニュアルの ここ で要点をあげています。