共用方式為

Unity 게임의 윈도우 스토어 포팅 강좌 2/6

  • 發行項

1. 총 6개중의 2 번째 세션 입니다.

 

2. 포팅과 관련해서 생각을 할 것이 크게 보면 세 가지로 1) 하드웨어, 2) 플랫폼에 고유한 API, 그리고 3) 플랫폼에 특별히 있는 기능들을 활용하는 것입니다. Light up 부분은 Developing 2D & 3D Unity… 강좌에서 다뤄졌으니 참고하면 좋겠습니다.

 

3. 포팅 시에 신경 써야 할 부분이며, 이에 대한 것들은 다른 플랫폼으로 포팅 할 때도 마찬가지 입니다.

 

4. Feature Detection은 경우는 플랫폼에 따라서 지원하는 하드웨어 및 기능이 다르기 때문에, 이에 대한 것을 확인하고 게임에 적용하는 것이 필요합니다. 이 부분을 하드코딩 해두면 크로스플랫폼에서 구동 시에 작동을 안하는 상황이 발생할 수 있습니다. Dynamic screen size/resolution은 플랫폼 별로 매우 다양할 수 있으니, 다양한 환경에서도 동작할 수 있도록 개발하는 것이 필요합니다. 그리고 #define 구문을 통해서 플랫폼에 특화된 스크립트를 작성할 수 있습니다. 또한, 크로스 플랫폼을 지원하는 플러그인을 사용할 수도 있고, 만들 수도 있습니다.

 

5. Unity 런타임을 윈도우 스토어와 윈도우 폰 앱에서 구동하는 내용 입니다.

 

6. 유니티 에디터와, 윈도우폰 8, 그리고 유니버셜 앱(WP8.1, Win8 & 8.1)에서 컴파일러와 런타임이 차이가 있습니다.

 

7. Mono는 닷넷 프레임워크의 부분집합이고, 닷넷 코어 역시 닷넷 프레임워크의 부분집합입니다. 하지만 이 둘은 공통이 아닌 부분이 있어서, 윈도우 스토어에서 구동되는 Unity에서는 사용할 수 없는 Mono 클래스들이 있습니다.

 

8. Windows Runtime (WinRT)는 윈도우 스토어 앱을 위해서 디자인된 새로운 Windows API 입니다. Native Code로 쓰여졌고, CLR 언어, C++, Javascript 에 노출되어 사용할 수 있습니다.

 

9. IO나 윈도우에 특화된 부분 등은 Windows Runtime을 통해서만 사용 가능한 것이 있습니다.

 

10. WinRT를 통해서 .NET Core와 Mono의 차이를 더 줄일 수 있습니다.

 

11. 여전히 차이가 있는 클래스에 대해서는 해결하는 방법을 설명합니다. 클래스 익스텐션이나 파셜클래스를 활용 할 수도 있습니다. System.IO의 경우 Windows.Storage로 swap해서 사용하며, System.Net의 경우는 유사한 기능을 하는 API를 활용합니다. 네트워크를 위해서는 상용인 Photon 라이브러리를 사용하는 것도 고려할 수 있습니다.

 

12. Mono로 컴파일해서 닷넷으로 구동하는 경우에는 Unity 쪽에서 이 과정에 대한 추가적인 처리를 해줍니다.

 

13. Unity에서 처리하는 과정은 Serialization Weaver를 거쳐서, Reference 를 rewrite을 하고, Assembly 를 Convert 합니다.

 

14. 특정 플러그인을 Unity 가 프로세싱하길 원치 않는 경우에는 Unprocessed Plugins에 포함시키면 됩니다. 그리고 그 플러그인에서 UnityEngine.dll을 참조하면 안됩니다. 하지만 대부분의 경우 이렇게 하는 경우는 없을 것으로 생각합니다.

 

15. C#과 Javascript가 같이 쓰인 게임(예를 들면 angrybot)의 경우 Windows Phone 8의 경우는 Mono로 컴파일 되기 때문에 기본적으로 작동을 한다. 하지만 Windows Store의 경우는 Use .NET Core Partially를 선택해야 작동합니다.

 

16.Windows 8이나 Universal 로 선택했을 경우에 컴파일은 세가지를 선택할 수 있습니다. 'Use .NET Core' 의 경우는 C#이 Microsoft 컴파일러로 컴파일 되기 때문에, 인라인 스크립트로 Windows Runtime APIs를 호출 할 수 있지만, JS 클래스에서 볼 수 없습니다. '.NET Core partially'에서는 플러그인 또는 일반 에셋에 있는 C# 스크립트가 Mono 컴파일러로 컴파일 되기 때문에 Windows Runtime을 참조할 수 있습니다. 그리고 Mono로 컴파일 된 C#은 JS 스크립트에서 볼 수 있습니다. None을 선택하면 모두 Mono 컴파일러를 사용하며 인라인으로 WinRT 타입을 호출 할 수 없습니다.

 

17. Unity 게임이 구동되는 윈도우 하드웨어에 대한 부분을 이야기하겠습니다.

 

18. 윈도우폰 하드웨어는 상대적으로 제한된 하드웨어 구성을 갖고 있습니다. 게임 개발자 입장에서는 맞춰야 할 대상이 적어지는 장점이 있다고 할 수 있겠죠. CPU는 스냅드래곤 S4 듀얼코어, 그래픽은 최소 Direct X 레벨 9_3을 지원한다고 가정하고 개발할 수 있습니다. 메모리는 현재 최소 512MB부터 2G까지 나와있습니다. 비용이 저렴한 폰의 경우 512MB 메모리를 갖고 있는데요, 고급 게임의 경우는 512MB 디바이스에서는 원활하게 구동되기 어려울 수 있으므로, 개발시 지원 여부를 선택해야 합니다. 해상도는 기본으로는 800x480을 최소로, 1920x1080까지 지원하고 있습니다. 센서는 Accelerometer, Light, Proximity는 기본으로 포함되지만, Gyro와 Magnetometer의 경우는 선택적이라서 지원하지 않는 디바이스도 있습니다.

 

19. Windows Phone 앱의 경우는 하드웨어나 소프트웨어 특정 기능을 사용하기 위해서는 app의 manifest에서 이를 미리 선언해주어야 합니다. 이로 인해 사용자가 해당 하는 기능을 앱이 사용한다는 것을 설치 전에 알 수 있습니다.

 

20. 윈도우 폰에는 뒤로가기 버튼이 있습니다. 윈도우 폰에서 뒤로 가기 버튼을 누르면 이전의 앱이나 화면이 나오거나, 모달 UI를 없애는 동작을 합니다. 홈 화면에 있고, 모달 UI가 보이지 않는 상황이면, 뒤로 가기 버튼을 누르면 앱은 종료됩니다. 유니티에서는 뒤로 가기 버튼을 처리하며, KeyCode.Escape 와 매핑합니다. 뒤로 가기 버튼이 눌리고 Application.Quit 가 호출되면 앱에서 벗어나게 됩니다.

 

21. 뒤로 가기 버튼은 Windows Phone 의 코드에서는 자동으로 UnityApp.BackButtonPRessed() 메소드를 호출해 주게 됩니다. Unity 코드에서는 백버튼 처리를 반드시 해야합니다. (종료, 뒤로 가거나, 모달 UI를 없애거나…) 백버튼 처리를 하지 않으면 윈도우폰 스토어 인증에서 통과하지 못하게 됩니다.

 

22. 유니티 4.5+이상에서 윈도우폰과 윈도우에서 키보드 지원을 GUI 통해서 합니다. TouchScreenKeyboard 클래스를 통해서 프로그래밍적으로 접근을 할 수도 있습니다. (윈도우에서 keyboard.area는 지원되지 않으며, 초기화 후에 keyboard.active 설정은 더 이상 필요치 않습니다.)

 

23. 윈도우폰에서는 메모리 제한이 있습니다. 디바이스에 따라서 메모리 크기가 다르면 이에 따라서 하나의 앱에서 사용할 수 있는 메모리 크기가 다릅니다. 512MB의 경우는 manifest 설정을 이용해서 Windows Phone 8.0의 경우 최대 180MB까지 설정할 수 있습니다. Windows Phone 8.1의 경우는 185MB로 조금 더 커집니다. 180MB가 게임을 구동하기에 불가능한 경우라면, ID_REQ_MEMORY_300 을 manifes에서 설정해서 512MB 디바이스에서 해당 앱이 구동되지 않도록 할 수도 있습니다. Windows Phone 8.1에서 쓰는 AppX manifes에서는 minDeviceMemory 를 추가해야 합니다.

 

24. 윈도우폰의 메모리 관련 팁을 몇 가지 드리면 1) 가장 낮은 사양의 디바이스에서 테스트를 해보는 것, 2) Unity profiler를 사용해서 어느 것이 메모리를 많이 사용하는지 찾는 것, 3) DXT1 또는 DXT5로 텍스춰를 압축하는 것, 4) 오디오 메모리 사용을 'Stream from disc'로 설정해서 줄이는 것 등이 있습니다. (낮은 사양의 디바이스를 구매하기 어렵다면 에뮬레이터를 활용할 있습니다.)

 

25. 텍스춰 압축은 DXT1과 DXT5가 있는데, 각각에 따라서 지원하는 내용이 다릅니다.

 

26. 윈도우 폰에서 메모리 관련으로 전체메모리, 애플리케이션의 현재 메모리 사용량이나 피크 메모리 사용량을 볼 수 있는 API가 있습니다.

 

27. 메모리 도구로 윈도우에는 Task Manger, Xperf를 사용할 수 있고, 윈도우폰에서는 Windows Phone Power Tools를 쓸 수 있습니다. Unity 프로라면 profiler를 폰과 윈도우 모두에 사용할 수 있습니다.

 

28. 메모리 관리를 위해 애셋 번들을 쓰는 방법도 있는데, 다양한 해상도를 지원하는데 쓰기 좋고, chunk 를 활용할 수 있습니다.

 

29. 윈도우폰에서 오디오에 대한 내용을 알아보면, debug 빌드에서 지직거리는 소리가 나면, master 빌드로 해보길 바랍니다. 또한 디바이스에서도 테스트해보길 바랍니다. (에뮬레이터로 판단하기는 어려울 수도 있습니다) 메모리를 최대화 하기 위해서는 stream from disk를 이용해 보길 바랍니다. 그리고 윈도우 폰에서 쓸 수 있는 미디어 코덱을 확인해야 합니다.

 

30. Unity에서 이외 하드웨어(터치, 마이크로폰, 자이로&가속도 센서, 웹캠, 위치 센서)에 대해서 처리하는 것은 동일하기 때문에 특별히 윈도우폰과 윈도우에서 따로 처리할 것은 없습니다.

 

31. 윈도우폰에서의 화면 비율과 해상도는 네 가지가 있습니다. 유니티 게임의 경우 전체 화면 모드로 동작한다고 가정하고, XAML에서는 (절대적이 아닌) 논리적인 화면 단위를 사용합니다.

 

32. 입력은 윈도우 스토어의 경우는 키보드, 마우스, 터치, 가속도/자이로 센서, 카메라, 마이크, 컨트롤러가 있고, 윈도우폰의 경우는 터치, 가속도/자이로 센서, 카메라, 마이크, 뒤로 가기 버튼이 있습니다.

 

33. 윈도우 하드웨어에 대해서 살펴보면, 그래픽은 Direct X Level 9_1부터 Direct X11까지 지원합니다. (Surface RT가 Level 9_1인데, 9_1과 9_3에 큰 차이가 있지는 않음.) 해상도는 1024 x 768 이상으로 굉장히 다양할 수 있고. 320 x 768 사이즈로 줄어들 수도 있습니다. 입력은 키보드, 마우스, 터치 및 컨트롤러를 사용하고, 센서는 추가적으로 추가적으로 사용할 수 있습니다. (Surface RT의 경우 빛, 가속도, 자이로, 컴파스가 있음)

 

34. 윈도우 역시 윈도우 폰처럼 개발자가 하드웨어나 소프트웨어에서 사용하는 기능들에 대해서 manifest에서 선언해줘야 합니다.

 

35. 윈도우의 화면 비율과 해상도에서 일단 최소는 1024x768이라고 생각합니다. 320x768이나 500x768로 줄어들 수 있는데, 이 경우에 게임을 유지하도록 하기 어렵다면 간단히 일시 정지하는 것도 좋습니다.

 

36. 스크린사이즈를 변경 처리하는 것에 대한 코드는 위와 같습니다. 화면 사이즈 변경 이벤트가 일어 났을 때 화면 가로 사이즈가 500보다 작은 경우에는 게임을 멈춤하고 그렇지 않을 경우에는 멈춤을 해제하는 코드입니다.

 

37. 정리하면 런타임이 다르다는 것을 이해해야 합니다. 에디터는 Mono이며, 구동되는 디바이스는 .NET이다. 포팅하는데 신경쓸 것은 윈도우폰의 경우 메모리, 백버튼을 고려해야 하며, 윈도우는 입력장치(키보드, 마우스)를 고려해야 합니다.

Comments

  • Anonymous
    January 02, 2015
    혹시 윈도우애저에 MSDN Custom Services 란 구독이 있는지요?