대부분의 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 호출과 마찬가지로 나머지 게임 코드에서 사용되는 논리 값을 입력으로 표시하여 문제를 부분적으로 관리할 수 있습니다. 예를 들어 모바일 디바이스를 확대/축소하는 핀치 제스처는 바탕 화면의 +/- 키 입력으로 대체될 수 있습니다. 입력 함수는 줌 요소를 지정하는 플로트 값을 간단하게 반환할 수 있습니다. 마찬가지로 모바일에서 두 손가락 탭을 사용하여 바탕 화면의 오른쪽 버튼을 클릭하여 바꿀 수도 있습니다. 하지만 입력 장치의 프로퍼티가 게임의 필수 요소라면 다른 플랫폼에서 해당 장치를 개조할 수 없습니다. 이는 게임을 전혀 복사할 수 없거나 입력 및/또는 게임플레이를 광범위하게 수정해야 한다는 것을 의미합니다.
이 입력은 핸드 헬드 장치의 이동성에서 파생되므로 데스크톱에서 의미있는 대안은 아닐지도 모릅니다. 하지만 일부 사용 사례는 간단히 표준 게임 제어를 반영하고 아주 쉽게 복사할 수 있습니다. 예를 들어 운전 게임은 모바일 디바이스의 틸트(가속 센서로 결정)로부터 스티어링 제어를 구현할 수 있습니다. 이와 같은 경우 입력 API 호출은 대개 교체하기 쉽기 때문에 가속 센서 입력이 키 입력으로 대체될 수 있습니다. 하지만 입력을 재조정하거나 다른 입력 방법을 고려하여 게임의 난이도를 변경해야 할 수도 있습니다. 장치를 기울이면 키를 누를 때 보다 속도가 느려지고 결과적으로 화면에 집중하기가 더 어려워 질 수 있습니다. 이로 인해 게임이 모바일 디바이스에서 마스터하기가 더 어려워 질 수 있으므로 게임플레이 속도를 늦추거나 레벨당 더 많은 시간을 허용하는 것이 적절할 수 있습니다. 게임 코드는 이러한 요소를 쉽게 조정할 수 있도록 설계해야 합니다.
모바일 디바이스는 필연적으로 메모리, 스토리지, CPU 성능이 데스크톱 컴퓨터보다 떨어지고 성능이 충분하지 않기 때문에 게임을 이식할 수 없는 경우가 있습니다. 어떤 경우에는 리소스의 문제는 관리할 수 있지만, 데스크톱 시스템에서 성능의 한계까지 올린 게임을 모바일 플랫폼에 이식할 후보로 적합하지 않습니다.
현재 모바일 디바이스는 영화 재생을 위한 하드웨어 지원에 크게 의존하고 있습니다. 그 결과 재생 옵션은 제한적이며 MovieTexture 에셋이 데스크톱 플랫폼에서 제공하는 유연성을 보장하지 않습니다. 영화는 휴대폰에서 전체 화면으로 재생할 수 있지만 게임 내에서 개체를 텍스처링하는 데 사용할 수있는 범위가 없습니다(예: 게임 내 TV 화면에 영화를 표시할 수 없음). 이식성 면에서 소개, 컷씬, 지침 및 기타 간단한 프레젠테이션을 위해 영화를 사용하는 것이 좋습니다. 하지만 영화를 게임 세계에서 볼 수 있어야 한다면 모바일 재생 옵션이 적절한 지 고려해야 합니다.
비디오, 오디오 및 질감조차도 많은 스토리지 공간을 사용할 수 있으므로 게임을 이식하려면 이 점을 명심해야 합니다. 스토리지 공간(다운로드 시간에 해당하는 경우도 있음)은 일반적으로 데스크톱 컴퓨터에서는 문제가 되지 않지만 모바일에서는 그렇지 않습니다. 또한 모바일 앱 스토어에서는 제출된 제품의 최대 크기에 제한을 두기도 합니다. 게임 개발 과정에서 이러한 문제를 해결하기위한 계획이 필요합니다. 예를 들어 공간을 절약하기 위해 모바일에 대한 에셋의 축소 버전을 제공해야 할 수 있습니다. 또 다른 가능성은 애플리케이션의 초기 다운로드의 일부가 아닌 대규모 자산을 필요할 때 다운로드할 수 있도록 게임을 설계해야 할 수도 있다는 것입니다.
“데드” 오브젝트에서 사용되지 않은 메모리를 복구하는 작업은 Unity에 의해 자동으로 처리되며 데스크톱 컴퓨터에서는 눈에 띄지 않게 발생합니다. 하지만 모바일 디바이스의 메모리 및 CPU 성능이 낮으면 가비지 컬렉션이 더 자주 발생할 수 있으며, 걸리는 시간이 성능에 더 많이 영향을 미칠 수 있습니다(게임플레이에서 원치 않는 일시 중지 등). 게임이 사용 가능한 메모리에서 실행 되더라도 가비지 컬렉션 일시 중지를 피하기 위해 코드를 최적화해야 할 수도 있습니다. 자세한 내용은 메모리 관리 페이지에서 찾을 수 있습니다.
데스크톱 컴퓨터에서 잘 작동하는 게임도 복잡도가 높다면 모바일 디바이스에서 프레임 속도가 떨어지는 문제가 발생할 수 있습니다. 따라서 프로젝트가 모바일 플랫폼으로 복사될 때 효율성을 높이기 위해 특히 주의가 필요할 수 있습니다. 효율성을 높이기 위한 여러 가지 간단한 단계가 매뉴얼의 이 페이지에 요약되어 있습니다.