게임의 '최적화'는 언제나 치열한 싸움이다. 게임의 원활한 구동을 위해서는 반드시 해야 하는 작업이고, 용량을 줄이기 위해서도 필요하다. 그러나 이 과정에서 '퀄리티'가 떨어지면 게임의 경험이 나빠질 수 있기 때문에 조심스럽게 해야 할 부분이기도 하다. 최적화는 사실상 퀄리티와의 전쟁이라고도 할 수 있다.
개인적으로 과거 인터뷰에서 '메이플블리츠X'의 최적화 사연을 들었던 경험이 있다. 언리얼4 엔진을 이용해 제작해서 사실 어느 정도 최저 사양을 높게 잡았을 줄 알았는데 갤럭시S2에서 구동은 되긴 된다고해서 상당히 놀랐던 기억이 있다. 당시에는 간략하게 설명만 들었었는데, 이번 NDC에서 그 과정에 대해서 좀 더 상세하게 들어볼 기회가 있었다.
넥슨 메이플블리츠X 개발실의 권승진 개발자는 이번 NDC에서 '메이플블리츠X 최적화 일지 - 언리얼 엔진에서 최저사양 낮추기'라는 주제로 자신이 진행했던 '메이플블리츠X'의 최적화 경험에 대해서 공유했다.
'메이플블리츠X'는 게임과 장르의 특성상, 카메라 시점이 '고정'이다. 그래서 화면에서는 맵이 많은 부분을 차지하고, '맵'이 시야에서 항상 보이게 된다. 내부 개발팀에서는 그래서 이 '맵'을 좋은 퀄리티로 만들기를 희망했다. 하지만 이렇게 만들어진 맵은 매우 큰 리소스를 차지했고, 이 퀄리티에 대해서 대립이 있을 정도였다.
리소스가 지나치게 거대했기에, 최적화는 반드시 필요했다. 그래서 권승진 개발자는 다른 아이디어를 냈다. 맵에서 '움직이지 않는' 오브젝트들을 미리 구워서 표현하는 방법이다. 먼저 PC 버전에서 최고 해상도로 맵을 구현하고 이를 'ColorMap'과 'DepthMap'의 두 객체로 구분해 파일로 저장, 게임에서 불러오도록 했다.
이 방법으로 맵 자체는 매우 가벼워지는 효과를 얻었고, 300만 개에 달하던 와이어 프레임은 2개 수준으로 인식이 될 정도였다. 이렇게 맵의 움직이지 않는 오브젝트들을 배치하고, 여기에 추가적으로 다이나믹 오브젝트들을 배치하여 맵의 렌더링 비용이 크게 감소했다. 게다가 'DepthMap'으로 맵을 나누었기 때문에, 다이나믹 오브젝트들의 그림자 또한 구현하기가 쉬웠다. 양쪽 모두 만족스러운 결과를 얻었던 것이다.
다음은 UI의 문제였다. 카드 배틀이라는 장르 특성상, 게임 내에서 UI의 비중이 매우 높은 편이였다. 이 부분도 부하가 매우 높은 편이었고, 최적화 이전에 프로파일링의 결과는 전체 드로우콜(DrawCall)의 80%가 UI 일 정도였다. 물론 이는 배칭(Batching, 같은 속성을 모아서 그릴 수 있는 일종의 일괄 편집 기능)을 전혀 고려하지 않은 부분이었다.
언리얼에서는 코드들이 배칭을 잘 하도록 유도해주는 게 핵심이었다. 배칭을 위해서는 특정한 '조건'들이 모두 맞아야 하는데, 실질적으로는 텍스처와 레이어가 걸림돌이 된다. 텍스처는 결국 아틀라스(Atlas)로 해결이 가능해, 최종적으로 문제가 되는 부분은 바로 레이어였다.
배칭의 조건을 맞추기 위해서는 결국 효율적인 레이어 아이디(Layer ID)의 관리가 필요했다. Hoizental Panel, Vertical Panel, Grid Panel에 속한 레이어들은 배칭이 상대적으로 잘 되는 편이지만, Overlay 및 Canvas Panel의 레이어에서는 배칭이 깨지는 부하가 많이 발생한다.
이는 사실 개발 초기부터 관리해야 할 문제였지만, 메이플블리츠X의 경우는 이미 어느 정도 개발이 되어 있던 상황이라 당장 리모델링을 하기에는 비용이 너무 컸다. 그래서 비용이 많이 드는 UI는 무리하지 않고, 할 수 있는 선에서 레이어의 수를 최적화하기로 결정했다.
최적화를 하지 않았을 경우 총 176개의 레이어와 180개의 배칭이 이뤄졌지만, 최적화를 하고 난 이후에는 레이어는 71개, 배칭은 75개 수준으로 크게 줄어들었다. 같은 UI임에도 드로우콜은 100 정도 감소했고, 시간 역시 8ms를 줄일 수 있었다. 언리얼 엔진의 기본 기능만 이용해도 꽤나 큰 최적화가 이뤄졌던 것.
그래도 개발팀은 이 수준으로 만족할 순 없었다. 여전히 드로우 오브젝트가 많은 편이라, '메이플블리츠X'가 저사양에서도 만족스러운 구동을 보여주지 못했기 때문이다. 그래서 한 객체당 열한 개가 있는 드로우 오브젝트가 있는 카드에 눈을 돌렸다.
UMG(언리얼 모션 그래픽 툴’을 말하는데 언리얼 엔진에서 UI를 제작할 수 있는 ‘슬레이트’ 기능을 대폭 개선한 버전)를 텍스처 한 장으로 만드는 기능을 새롭게 개발했는데, 이는 마침 비슷한 기능이 있었다. UwidgetComponent라는 기능인데, 이 기능은 3D 공간에 위젯을 표현할 수 있는 기능이었다.
그래서 이 기능을 응용, UwidgetComponent와 스태틱 텍스처 생성 기술을 융합해 UMG를 텍스처 한 장으로 만드는 새로운 기능을 에디터에 추가했다. 언리얼 엔진은 오픈소스를 사용해서, 에디터의 기능을 추가하는 게 크게 어려운 일은 아니었다. 결과적으로 1장당 11번이었던 드로우콜을 카드는 총 5장에 7번까지로 크게 줄일 수 있었다.
이렇게 어느 정도 게임의 최적화가 이뤄졌을 무렵, 또 다른 난항이 찾아왔다. 바로 최저사양의 문제였다. 메이플블리츠X는 1차 CBT 당시 갤럭시S5를 최저사양 기준으로 정했었고, 2차는 최적화를 거쳐 갤럭시S4까지 진행했다. 2차 CBT를 마치고 나서 충분하다 싶었는데...
그래서 결국 앞서서 설명했던 방법도 시도를 해보고, 옵션을 끄고 드로우콜을 줄이는 시도를 했음에도 갤럭시S3의 사양에 맞추기는 쉽지 않았다. 일단은 구동이 되는 게 중요하다고 판단해 결국 퀄리티를 좀 깎아내기로 결정했다.
일단 가장 먼저 시작한 작업은, 디바이스의 프로파일을 새로 만드는 것이었다. 최저사양용 DeviceProfile을 새롭게 정의하고, 이에 부합할 시 최적화된 버전으로 작동하도록 하는 작업이 이뤄졌다.
다음은 Vertex의 개수를 제한해 최적화를 진행했다. OpenGL ES 2.0만 지원하는 구형 기기들은 Vertex가 제약이 있기 때문에 자체적으로 Vertex의 기준을 정해야 했다. 갤럭시노트2 기준으로 Vertex 1000/ Bone 50 정도의 유닛을 12기를 재생하니 약 26~27 FPS를 보여주는 상황이었다.
총합은 20,000 이하의 Vetex로 가지도록 기준을 마련했다. 이어서 새로운 태그를 만들어서 꼭 필요하지 않은 UI의 꾸밈은 저사양 기기에서 작동하지 않도록 처리하니 오브젝트가 총 14%정도 감소하는 효과를 얻었다. 이 두 작업으로 인해 저사양 기기에서의 처리량이 크게 줄어들었다.
다음은 LOD1(Level Of Detail)패키지를 만드는 과정이었다. 언리얼은 자체적으로 멀티 텍스처 포맷을 지원하는데, 갤럭시S3를 지원하기 위해서는 갤럭시S4 이상에서는 필요 없던 ETC1 포맷을 사용해야 했다. 하지만 ETC1포맷은 문제가 알파 채널을 지원하지 않는다는 점이었다. 그래서 정상적인 패키지의 용량은 830MB 정도였는데, ETC1 포맷으로 처리하니 패키지의 용량이 1.4GB까지 되어버렸다. 거기에 실제 메모리 사양도 거의 9배까지 왔다. 당시는 CBT가 코앞으로 다가왔기 때문에, 모든 UI를 바꾸기엔 늦어버린 상황이었다.
그래서 저사양용 패키지의 텍스처 면적을 1/4수준으로 줄여서 용량을 압축하기로 했다. 마침 언리얼 엔진에는 이와 비슷한 역할을 해 줄 'Texture Bias'라는 기능이 있었다. 이를 활용해 패키징을 진행하니, 확실히 퀄리티는 좀 떨어졌지만 용량은 원래 패키징과 비슷해졌다.
퀄리티는 분명히 떨어지긴 했지만, 효과는 대단했다! 아예 구동조차 되지 않던 스마트폰 저사양 기기에서 게임이 돌아갈 수 있었던 것이다. 다만 문제는 이렇게 초 저사양용 기기용 패키징을 만드니 오히려 중급 기기에서 게임이 좀 원활하게 구동하지 못하는 에러가 있었다.
권승진 개발자는 향후 이런 부분을 좀 더 수정해서 중급 기기에서도 원활한 게임 구동이 될 수 있도록 조절을 할 것이라고 설명하며, 열심히 만든 게임이니 많은 분들께 소개할 수 있길 바라며 최적화를 진행할 수 있었다고 소감을 전하고 강연을 마쳤다.
Lavii@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
