온라인게임만큼 최적화가 중요한 게임도 없다. 유저마다 전부 다른 PC 사양과 인터넷 속도, 많은 사람들이 있다보니 언제 어떤 일이 일어날 지 모르는 서버 등등. 사방을 둘러봐도 지뢰 투성이기 때문이다.
<블레스>같이 개발을 오래한 게임은 이 최적화에 아주 민감하다. <블레스>는 6년 이상 개발이 지속된 게임. 가뜩이나 '살아있는 세계'를 표방하며 판을 크게 벌인데다가, 클라이언트 안에는 폐기돼서 쓸모 없어진 애셋, 누군가의 예술혼으로 쓸데없이 고퀄리티(≒리소스를 잡아먹는)인 오브젝트가 가득했다. 이것이 그대로 라이브가 된다면? 말 그대로 세계 멸망이었다.
<블레스> 팀은 대대적인 최적화 작업에 나섰다. 필요 없는 리소스를 폐기하는 것은 물론, 있는 리소스도 통폐합하고 이펙트도 나눠 쓰는 처절한 다이어트였다. NDC 16에서 공개된 '블레스 그래픽 최적화 – 이제 그래픽 리소스 6년의 묵은 때를 제거할 때' 강연을 정리했다. /디스이즈게임 김승현 기자
먼저 가혹한 다이어트 과정을 이야기하기 앞서, <블레스>가 처한 상황에 대해 정리할 필요가 있다. <블레스>는 당초 '살아있는 세계'를 표방하며 세계 묘사에 공들인 게임이다. 월드 크기는 기존 언리얼엔진 사용 게임의 약 5배, 이것이 심지어 심리스 월드로 구현되어 있다. 그러니까 유저가 이동할 때마다 서버가 실시간으로 지역을 연산해야 된다는 의미다.
여기에 도시 간 이동수단인 '와이번'은 '빠른 비행 수단'이라는 특징 덕에 심리스 월드의 부하를 더욱 가중시켰다. (빠르면 로딩 속도도 빨라야 하고, 높으면 한번에 보이는 곳도 많으니까). 이외에도 한껏 욕심부린 커스터마이징, 유저 퀘스트 상황에 따라 맵이 달라지는 인스턴스 존 등등, 오픈이 다가오니 폭탄이 한두 군데가 아니었다.
여기에 MMORPG 특성 상 언제 어디서 모일지 모르는 군중, 그동안 미처 처리 못한 폐기 애셋이나 쓸데없이 고퀄리티인 애셋까지 감안해보자. 실제로 <블레스> 개발팀은 시운전에서 특정 구간에 'CPU 래그(Lag)'이 발생한 것까지 목격했다. 서버가 아니라, CPU가 데이터 부하를 못 이겨 래그를 일으킨 것이다.
결국 <블레스> 개발진은 테크니컬 아티스트팀을 중심으로 대대적인 리소스 다이어트 작업에 들어갔다. 다음은 그 처절한 다이어트 기록이다.
■ 일단 다 묶어! 마스터 머터리얼과 데칼
일단 최우선 과제는 리소스 자체를 줄이는 것이었다. <블레스>는 일단 텍스처(3D 모델링 위에 입혀 캐릭터의 색이나 질감을 표시하는 껍질) 숫자를 대폭 손봤다. 기존에는 몬스터 종류에 따라 텍스쳐가 하나씩 사용되는 방식이었다. 그 덕에 몬스터의 특성이나 개성에 걸맞은 세세한 묘사가 가능했지만. 게임이 읽어 들여야 할 데이터가 무지막지하게 늘어났다.
개발진은 고심 끝에 몬스터들에게 기성품(?)을 입히기로 결정했다. 몬스터 하나를 이루던 텍스쳐를 피부, 갑옷, 무기 등으로 분리한 후, 몬스터마다 이것들을 적절하게 조합하는 방식이다. 예를 들어 기존에는 똑같이 도끼를 든 몬스터라도 종류에 따라 도끼 모양이나 무늬가 조금씩 달랐는데, 다이어트 후에는 같은 도끼를 쓰게 되었다.
이런 것이 몬스터와 지형, NPC 가리지 않고 광범위하게 적용되었다. 그랜드캐니언을 꿈꿨던 어떤 협곡은 이 때문에 밋밋한 주름을 가지게 되었고, 어떤 몬스터는 비중이 작다는 이유 만으로 머리부터 발 끝까지 기성품으로 둘둘 감싸졌다.
심지어 <블레스> 스토리텔링의 핵심인 인스턴스 존도 다이어트 대상이 되었다. 정확히는 인스턴스 존에 적용되는 각종 날씨 효과가 원인이었다. 안개나 연기, 피바다 등을 연출하는데 쓰이는 '데칼'이 너무 많은 것이 문제였다. 결국 이것도 비슷한 효과끼리 통폐합되고, 패턴만 조금씩 달리하는 식으로 바뀌었다. 디테일 대신 효율성을 선택한 셈이다.
하지만 자기 작품이 예쁘게 보이고 싶은 것은 모든 창작자들의 마음. 텍스쳐 숫자까지 제한하며 다이어트를 시작하자 별별 꼼수가 다 나오기 시작했다. 누군가는 마스크 텍스쳐 하나에 명도값(!)을 달리한 문양을 입혀 재활용했고, 누군가는 아예 텍스처 대신 누드 기반으로 작업하기도 했다. 텍스처 다이어트에서 살아남기 위한 필사적인 몸부림이었다.
■ 쓸데없는 고퀄은 모두 삭제! 애니메이션 시퀀스와 액터·이미터 수량
애니메이션도 문제였다. 애니메이션이란 결국 캐릭터 모델이 움직이는 것을 저장한 데이터인데, <블레스>에는 이것이 너무도 많았다.
직업 애니메이션이야 어쩔 수 없다고 치더라도, 탈 것이 문제였다. <블레스>에 존재하는 탈 것은 100단위. 이것들 탈 것에 맞춰 다 애니메이션을 만들면 지금까지의 작업이 도로아미타불이었다.
개발팀은 꼼수를 썼다. 모든 애니메이션을 다 저장하지 않고, 일부는 특정 포즈에서 옷의 움직임만 추려 그럴싸한 모습만 보여주자는 것. 그 결과, 탈 것 수백 종에 필요한 애니메이션 용량을 대거 줄일 수 있었다.
그런데 이렇게까지 했는데도 특정 애니메이션들의 용량이 이상할 정도로 컸다. 용량 큰 리소스들을 체크하다 보니 전말이 드러났다. 바로 개발진의 쓸데없는(?) 예술혼이 문제였다.
한 고양이는 어찌나 섬세하게 만들어졌던지, 숨 쉴 때마다 허파가 부풀고 털이 움직였다. 장식품 주제에(?) 혼자서 어지간한 몬스터급으로 리소스를 먹었다. 이 고양이는 결국 2개 모션만 가진 평범한 고양이로 교체됐다.
어떤 던전은 너무 자주 래그가 걸려 데이터를 뜯어보니 샹들리에의 초와 촛불이 하나하나 별개의 오브젝트와 이펙트로 구성되어 있었다. 심지어 생긴 것도 조금씩 다 달랐다. 예술혼이 아깝긴 했지만, 이것도 눈물을 머금고 통폐합했다.
■ 이렇게 된 이상 오토를 돌린다! 스트리밍 환경설정
심리스 월드를 만든다는 것은, 캐릭터가 이동할 때마다 일정 범위의 지역 데이터를 매번 로딩한다는 의미다.
가뜩이나 오브젝트도, 텍스쳐도 많은 <블레스>다 보니 이동 자체가 부하를 주는 경우도 많았다. 부하 원인도 다양했다. 눈에 보이기엔 그냥 끊기는 것뿐이지만 어디서는 그래픽카드가, 어디서는 CPU가, 어디서는 서버가 비명을 질렀다. 문제는 이것을 확인하려면 유저가 직접 모든 지역을 이동하며 초당 프레임(FPS)를 체크해야 한다는 것. 그것도 다른 게임의 5배는 되는 월드를.
개발진은 고민 끝에, 그들에게 문제를 준 원흉 중 하나인 '와이번'을 부려먹기로 결정했다. 방식은 간단했다. 와이번을 캐릭터 높이까지 끌어내린 후, 머리에 카메라를 단 후 AI에게 꼼꼼히 세계일주를 하라고 시킨 것. 물론 카메라에는 CPU, 그래픽카드, 서버 등의 부하를 측정하는 장치가 달렸다.
솔직히 손이 많이 가는 오토였다. 처음에는 하룻밤 돌리고 나니 부하 때문에 게임이 뻗어 있기도 했다. 이것이 해결된 뒤에는 너무도 많은 데이터 때문에 순찰 범위를 좁히기도 했다. 그렇게 몇 번을 헤딩하다 보니 부하가 걸리는 지역이 확실해졌다.
이 뒤부터는 인내력 싸움이었다. 최저사양에 맞춘 시뮬레이터를 만든 후, 숫자를 하나하나 넣어가며 CPU, 그래픽카드, 서버에 대한 부하를 조사했다. 그렇게 수십 번 숫자를 넣은 후에야 적정 너비의 심리스 월드 로딩, 적정 수의 필드 오브젝트, 적당한 가시거리를 알아낼 수 있었다.
■ 과하면 조석과 게비스콘이 됩니다. LOD와 프락시매쉬
이렇게 직접 리소스를 줄이는 작업 외에도, 툴을 이용해 부하를 줄이는 작업도 병행됐다. LOD(Level of Details)와 프락시매쉬가 대표적이다.
LOD는 카메라가 가까이 있을 때와 멀리 있을 때 보여주는 디테일을 달리해 부하를 줄이는 기술이고, 프락시매쉬는 캐릭터 로딩이 끝나지 않았을 때, 임시로 간단한 모델링을 보여줘 부하를 줄이는 기술이다. 둘 다 '툴' 딴의 기술이기 때문에 개발진은 비교적 편하게 작업을 끝마칠 수 있었다.
하지만 다이어트 할 때는 천군만마와 같았던 이 기술이, 막상 서비스를 시작하자 발목을 잡았다.
판테라 남성 캐릭터에게 심폴리곤(LOD 작업툴 중 하나)의 버그로 카메라를 멀리하면 턱이 갑자기 '사각턱'이 되는 현상이 발생했다. 덕분에 판테라 남성 캐릭터는 문제가 해결될 때까지 '조석'(…)으로 불리었다. 물론 문제는 툴이 아니라, 개발진이 직접 수작업으로 해결했다.
공방전 등 대규모 콘텐츠가 처음 시작됐을 때는 프락시매쉬 때문에 욕을 봤다. 개발진이 예상했던 것보다 많은 사람이 몰린 탓에, 유저 눈에는 전부다 시퍼런 프락시매쉬 모델링이 보이는 것. 널디 넓은 필드에 시퍼런 캐릭터들이 가득 보이는 것은 너무도 이질적이었다.
결국 개발진은 로딩이 완료되지 않았을 때 보여줄 캐릭터 모델을 새로 만들어야 했다. 배포 준비 과정에서 미처 체크 못한 에러가 문제였다.
■ 싸움은 끝나지 않는다, 배포 준비
사실 위에 이야기한 것처럼 리소스를 덜어낸다고 하더라도 일이 끝난 것은 아니다. 남은 리소스를 종합해 하나로 묶어야 하고, 통폐합으로 생긴 구조 상의 구멍도 메워야 하기 때문이다.
때문에 이런 대규모 다이어트 과정은 대규모 업데이트 같은 철저한 배포 준비가 필요하다. 개발자끼리 작업물이 꼬이지 않게 모든 작업을 스톱시키는 것은 기본이다. 이후 리소스 리스트를 기반으로 빠진 것 있나, 혹은 중복 작업된 것 있나 체크하고 빠진 건 채워 넣고 중복된 것은 통폐합시킨다.
이렇게 하나로 묶은 후 시뮬레이션을 통해 바뀐 리소스 중 쉐이더 빠진 것 있나, 라이팅 맵은 잘 적용되었나 등을 체크한다. 특히 이 과정에서 중요한 것은 통폐합 중 생긴 '로딩 구멍'을 메우는 것이다. 워낙 리소스 통폐합이 잦다보니, A-B-C 순으로 불러와야 하는데 B가 없어져 이후 과정이 막히는 등의 일이 수시로 벌어진다.
이렇게 마지막 체크도 끝나고 관련 부서에 옮기면 '1차 작업'이 끝난다. 이제 ‘조석턱’이나 ‘게비스콘’과 같은 미처 발견 못한 버그와의 싸움, 그리고 영원히 끝나지 않을 최적화 작업이 남아있다.
