Unity 최적화 작업 후에... #1

뭐 제목은 거창하지만 어떻게 보면 1인 개발로 만들고 있는 하이퍼 캐주얼 류의 2D 모바일 게임을 최적화하고 느낀 점을 적을까 합니다. 용량이 크거나 복잡한 3D 게임이 아닌지라 상대적으로 어려운 내용보다는 기본적인 개념에 중점을 두고 이야기 할까합니다.

전에는 최적화라면 프로그램 최적화 만을 생각했는데 1인으로 리소스 제작, 기획, 프로그래밍을 하다보니 프로그램 최적화 만이 게임이라는 관점에서의 최적화는 아니라는 생각이 들었습니다.

여기서는 최적화한 내용 중 인상 깊었던거 중 비프로그래밍 적인 것을 #1에, 프로그래밍 적인 것을 #2에, 설정 관련된 것을 #3에서 이야기 할까 합니다.

입력에 따른 게임 난이도 최적화 
제가 만든 게임은 터치로 적과 폭탄을 부시는 게임입니다. PC 마우스 기반으로 빠르게 만들고 개발이 어느정도 완료된 후에 터치 기반의 모바일로 테스트 및 최적화하는 개발 프로세스를 사용 하였습니다. 
이 개발 프로세스의 문제는 PC 마우스 기반과 모바일 터치 기반의 차이점으로 인하여 발생하는 난이도 차이를 반영하지 못한다는 것이었습니다. 막상 터치로 게임을 해보니 마우스에 비하여 너무 빠르게 입력을 할 수 있는 관계로 전반적인 게임의 난이도가 낮아지는 현상을 겪었습니다. 여기에 폰과 패드의 화면 크기에 따라 적이나 폭탄의 크기와 손가락의 화면 이동 범위에 따른 난이도의 변화도 존재하였습니다. 또한 상대적으로 모바일 기기의 성능에 따라 얼마나 게임을 원활히 플레이할 수 있는 가에 따른 난이도 차이도 나타났습니다.
결과적으로 모바일로 테스트 및 최적화를 하면서 난이도를 높이는 쪽으로 재조정해야만 했습니다. 
터치로 인한 문제는 터치 기반의 모바일 기기에서 난이도가 낮아지는 현상이 있었습니다. 하지만 만약 패드를 사용한다면 반대로 가상 패드를 사용하는 터치 기반의 모바일 기기에서 난이도가 올라가는 현상이 발생할 듯 합니다. 
만약 새로운 모바일 게임 개발을 하신다면 게임의 프로토타입 단계에서 상대적으로 고성능부터 저성능까지, 작은 화면의 폰에서 부터 큰 화면의 패드까지 테스트를 하여 입력에 따른 난이도를 측정하여 보는 것도 좋을거 같습니다. 또한 중간 중간 테스트시 이런 여러 기기에서 플레이 하여 난이도를 조정하여 보는 것도 좋은거 같습니다.

화면 크기에 따른 최적화
폰과 패드, 안드로이드와 아이폰 이렇게만 구분해도 화면 크기나 해상도는 4종이며 실제 발매된 기기를 기반으로 구분한다면 간단히만 구분하여도 십여가지 이상의 화면크기와 해상도가 나올 것입니다. 저의 개발은 유니티를 기반으로 하였고 유니티의 에디터 상에서 실행 해상도를 변경하는 것만으로도 많은 화면 관련 문제를 해결할 수 있었습니다. 그런데 실제 모바일 테스트 작업을 하다보니 유니티는 안드로이드나 iOS 빌드를 선택해야만 새롭게 보이는 해상도 들이 있었습니다. 
저는 최적화 작업을 할 때 상대적으로 고성능인 아이폰 기반의 iOS를 가장 나중에 하였는데 12인치 기반의 아이패드 같은 경우는 워낙 고해상도이고 화면 비율이 틀리다보니 화면 배경에 빈공간이 나오는 문제가 발생하였습니다. 다행히 좌표체계는 게임의 해상도에 상관없이 실행되도록 한 관계로 특별히 문제가 발생하지 않았습니다. 문제는 배경의 빈공백을 어떻게 처리해야 하는가에 대한 것이었습니다. 대부분의 해상도를 지원하는 배경 해상도를 변경할 때 새로운 문제가 발생할거 같아 배경을 수평으로 늘리는 식으로 해결하였습니다. 수직은 유니티 엔진이 맞혀주는 관계로 별도로 수정할 것은 없었습니다. 모바일은 크기에 비하여 상대적으로 고해상도인 관계가 많아 늘린 배경이 크게 이상하다고 느껴지지는 않았습니다.
유니티의 UI는 모바일 UI에서 흔히 지원하는 기준점 기반의 위치와 화면 크기에 따른 상대적 크기를 지원하여 주어 해상도 변화에 따라 일정한 모습을 보여줍니다. 하지만 해상도 보다는 화면 비율에 따라 UI가 이상하게 보이거나 약간의 화면 충돌의 모습을 가지는 것이 보여 수정하여야만 했습니다.
게임을 개발할 때 그래픽이나 UI를 담당하시는 분들은 전체적인 게임을 테스트할 때 다양한 해상도, 특히나 유니티 같은 경우 안드로이드나 iOS를 추가할 때 나오는 해상도들에서 그래픽이 어떻게 나오는지 보는 것도 중요한 거 같습니다. 프로그램이 크고 복잡하면 이것도 나중에 발견하고 수정하려면 일정이 지연되는 이유가 될 수 있습니다.

다국어 지원에 따른 최적화 
만든 게임은 하이퍼 캐주얼 기반의 2D게임으로 액션에 포커스를 둔 관계로 글의 사용은 최소화 하였습니다. 덕분에 글이라고 해봐야 몇 십개도 되지 않습니다. 처음에는 쉬운 영어라 영어로만 표시해도 되겠다고 생각했습니다. 그렇지만 이정도의 영어도 싫어하는 사람도 있겠다는 생각이 들어서 한국어, 일본어, 영어를 지원하도록 만들었습니다.
우선 다국어를 지원하려면 그 만큼 지원하는 폰트가 필요합니다. 저는 구글 Noto Sans 한국어 폰트에서 일본어와 일부 일본 한자를 지원하는 관계로 한국어 폰트를 사용하였습니다. 하지만 이렇게 적은 글과 겨우 3개 국어 지원하는데도 UI가 깨지거나 어색해지는 현상이 발생하였습니다. 이유는 언어에 따라 문자열의 길이가 틀려서 였습니다. 
다음으로 다 개발한 뒤에 다국어를 지원한 관계로 코드와 UI에서 다국어 관련 내용을 추가하는 것도 한 일이었습니다. 
게임을 개발할 때 프로토타입이 끝나고 정식으로 개발할 때는 다국어를 기본 지원하도록 코딩하는 것이 좋을 듯 보입니다. 그리고 UI가 어색해지는 것은 중요 UI를 개발할 때 기본적으로 지원하는 다양한 언어에서 테스트해보는 것도 좋을 거 같습니다. 물론 현실적으로는 한 언어의 개발이 끝난 뒤 다국어 지원시 해보겠지만 말입니다.