(참조)Lineage2m 개발 사례 언리얼 오픈데이 2019 발표.

역자의 말.
이건 번역이라고 하기엔 애매한 상황인데 2019년도에 유투브 프레젠테이션을 들으면서 영어로 적어놓으려고 몇 번을 들으면서 텍스트로 정리 한 내용을 다시 한국어로 변역 한 것입니다.

 

에픽게임 언리얼서브밋 2019 . 리니지2M 언리얼엔진 사용 사례 발표.

엔씨소프트.

발표: 김종현 클라이언트 총괄 매니저.

Theorem: JP.Lee

요약.

내용을 관찰하고 맥락을 더 쉽게 정리한다.

리니지2M 언리얼 엔진4 사용.


개발 완료 전에 발표된 내용입니다.

편안한 마음으로 들어주셨으면 좋겠습니다.

콘텐츠를 간략하게 소개합니다.

프로젝트 소개와 언리얼 엔진을 선택한 이유.

이번 프로젝트에서 ue4를 선택하게 된 계기와 언리얼 엔진을 사용하면서 여러 방향에서 직면했던 어려움을 극복한 과정을 이야기하겠습니다.

 

발표자 소개.

김종현, 20년 경력의 리니지2M 클라이언트 사업부 총괄.

 

간단한 프로젝트 팀 소개.

게임 콘텐츠는 제외하겠습니다.

기술적으로 가장 큰 특징은 단일 채널 서버의 심리스 오픈월드 게임입니다.

서버 기술적인 이야기인데, 여러 채널로 서비스되지 않고 하나의 채널에서 1,000~1,000명이 하나의 채널에서 전투를 할 수 있도록 구현해야 합니다.

실제로 10km * 10km의 지형을 구현하고 끊김 없이 구현해야 합니다.

프로그래머 팀의 평균 연령은 37.7세입니다.

언리얼 엔진을 선택하게 된 동기.

원래 리니지 2는 언리얼 2를 사용했습니다.

굳이 속편에 언리얼을 사용할 이유는 없었지만, 맥락상 언리얼 엔진을 사용하는 것이 타당해 보였습니다.

언리얼 엔진의 가장 큰 장점은 오픈소스라는 점입니다.

유니티의 경우 엔진 내부의 소스는 볼 수 없지만 라이선스 비용으로 10억 원 정도를 지불하면 소스코드도 볼 수 있습니다.

개발하면서 문제가 생기면 인터넷에 가보거나 지원팀에 요청을 해도 장담할 수 없으니까요.

제가 언리얼 엔진을 선택한 가장 큰 이유는 소스코드를 볼 수 있다는 점이었습니다.

방대한 소스코드를 다 볼 수 없을 정도로 방대하지만, 제 분야에서는 소스코드를 볼 수 있다는 점이 가장 큰 장점이었습니다.

앞서 말씀드린 대규모 오픈 월드를 구축해야 했는데, 예전부터 랜드스케이프 툴셋이 좋았고, 지속적으로 업데이트되는 월드 컴포저도 심리스 월드를 구축할 때 좋은 기술적 선택에 큰 영향을 미쳤습니다.

다음으로 언리얼 엔진을 선택한 후 겪었던 어려움과 고뇌, 고민에 대해 이야기하겠습니다.

언리얼 엔진을 선택한 후 가장 먼저 고민한 것은 인력을 선발하는 것이었습니다.

프로젝트가 시작된 지 1년 반이 지났습니다.

훌륭한 개발자는 도구를 탓하지 않습니다. 이런 말이 있습니다.

저는 이 말이 확실히 맞다고 느꼈습니다.

당시만 해도 언리얼 엔진으로 모바일 게임을 개발해본 사람이 거의 없었거든요.

사람을 찾는 과정에서 좋은 분들은 대부분 유니티를 사용했지만 언리얼 엔진을 사용해본 적이 없었는데, 입사 후 모두 언리얼 엔진 개발에 적응해서 문제없이 진행할 수 있었습니다.

결국 좋은 개발자는 어떤 엔진이든 빠르게 적응하는 것 같아요.

사람을 구할 때 운이 좋아야 하는 것 같습니다.

다음으로 걱정되는 것은.

엔진이 수정되지는 않을까요?

오픈소스 개념이기 때문에 소스코드를 보고 변경할 수 있다는 점은 있지만, 실제 변경을 하면서 개발하는 것과는 다릅니다.

일단 엔진을 수정하기 시작하면 엔진 업데이트에 발맞추기 위해 추가 작업이 엄청나게 많아집니다.

그래서 걱정이 되는 부분입니다.

저희는 내부적으로 최소한의 수정만 허용하는 정책을 수립했습니다.

하지만 엔진 소스를 보면 소스를 수정하고 싶은 욕구가 생기는 것은 당연한 일입니다.

예를 들어 엔진 API를 사용하다 보면 일부 함수나 변수가 비공개로 차단되어 있는 경우가 있는데(왜 그런지 모르겠지만...), 그 중 하나를 해제하면 편리하게 사용할 수 있다고 생각합니다.

작업을 하다 보면 엔진 소스를 한번 건드리기 시작하면 방대하게 수정된 소스들이 넘쳐나기 쉽습니다.

하지만 그런 욕구를 조절하는 것이 언리얼 엔진을 잘 사용하는 방법 중 하나라고 생각합니다.

빌드 및 배포.

어느 쪽이든 엔진이 수정되었으므로 빌드하고 배포해야 합니다.

소스 빌드 배포 방법과 인스톨 쉴드 배포 방법 두 가지가 있습니다.

저희는 설치 빌드 방식을 선택했습니다.

많은 인원이 투입되는 MMO 개발 시스템이기 때문에 배포 속도보다는 안정성을 고려했습니다.

언리얼의 XGE를 사용하여 빌드합니다.

이걸 사용하지 않으면 개발 속도가 너무 떨어지므로 XGE를 사용해 주세요.

셰이더 컴파일이 100배 빨라집니다.

반드시 공유 DDC를 사용하세요.

(https://docs.unrealengine.com/en-US/Engine/Basics/DerivedDataCache/index.html)

CI 툴은 필수입니다.

하지만 젠킨스는 권장하지 않습니다. 무료라는 점을 제외하면 정신 건강에 좋지 않습니다.

Team City와 같은 도구에 비용을 지불하세요.

정말 쉬워집니다.

버전 업데이트?

업데이트는 시간이 될 때마다 이메일로 보내드립니다.

내용을 보면 좋은 것들이 많이 업데이트되어 업데이트하고 싶은 충동이 생깁니다.

하지만 조금만 기다려주세요.

메이저 빌드가 업데이트 된 경우 즉시 업데이트하지 말고 1 ~ 2 주 정도 기다렸다가 메이저 빌드 업데이트의 핫픽스 버전이 나오면 업데이트해도 늦지 않습니다.

실제로는 메이저 버전이 올라가면 업데이트하지 말고 업데이트 기능을 별도로 평가합니다.

정상적으로 작동하면 다음 업데이트 시점을 검토합니다.

개발팀의 방침은 ~.3 단위로 업데이트하는 것으로 결정되었습니다.

간단한 회고입니다.

저희는 언리얼 엔진 4.17 버전으로 시작했습니다.

4.19 버전에서 랜드스케이프 LOD 등이 개선되었지만, 언리얼 엔진 4.20과 언리얼 엔진 4.21에서도 많은 업데이트가 있었습니다.

포트나이트 출시 이후에도 많은 업데이트가 있었습니다.

위의 두 버전에서 모바일 게임 부분도 업데이트가 많이 되었습니다.

하지만 실제로 업데이트를 해보면 알겠지만 너무 많아서 신경이 쓰였습니다.


PBR?

PBR에 대해 간단히 이야기해보겠습니다.

PBR이 모바일에서 제대로 구현되는지 보여주는 것이 목표였습니다.

위 그림에서 왼쪽은 아트팀의 요구에 맞춰 직접 수정한 언리얼 엔진 4.17 셰이더 버전이고, 오른쪽은 ES-3.1의 언리얼 엔진 순수 모바일 셰이더를 적용한 결과입니다.

OpenGLS-2.x와 OpenGLS-3.1은 큰 차이가 있습니다.

OpenGL-2.x에서는 원하는 결과물을 표현할 수 없어서 고민이 많았습니다.

이때 회사 임원진 및 사업부서들과 많은 논의를 거쳐 좋은 결론을 내렸고, 과감히 gles-2.x를 버리고 하이엔드 모바일 하드웨어로 방향을 잡았습니다.

ES-2.x 레벨 모바일 셰이더를 ES-3.1을 최대한 활용할 수 있는 레벨로 업그레이드했습니다.
서브스턴스에서 작업한 결과는 게임에 표시된 상태와 최대한 가깝게 설정됩니다.
기본 및 공통 머티리얼은 가능한 한 단순하게 만들어졌습니다.
PBR을 사용할 때 중요한 점은 다양한 유형의 머티리얼을 사용하는 것보다 가능한 한 단순하게 사용해야 한다는 것입니다.

메가스캔과 같은 실제 아트 에셋을 최대한 많이 구매합니다.
엔진 프로그래머가 도움을 줄 수 있지만 아트 팀의 이해와 기술이 중요합니다.
제 생각에는 PBR을 잘 사용할수록 셰이더 프로그램이 해야 할 일이 줄어듭니다.

두 이미지를 보면 일반인들은 잘 모를 수 있지만 자세히 보면 광원 처리 부분에서 많은 차이가 있습니다.

퓨어 버전의 셰이더(오른쪽)는 조금 짧게 처리했기 때문에 광원 처리가 제대로 되지 않았습니다.

어두운 부분에서 살짝 흐려지거나 사라지는 것들이 모두 개선되었습니다.

 

왼쪽은 수정하지 않은 언리얼 엔진 4.17 PBR 모바일 셰이더, 오른쪽은 저희가 수정한 리니지2M PBR 셰이더입니다.

두 결과물의 텍스처 해상도는 동일합니다.

이 버전을 바탕으로 아트 디렉터, 아트 팀원들과 상의한 결과 개발을 진행해도 괜찮다는 피드백을 엔진팀에서 받았고, 본격적으로 개발에 착수하게 되었습니다.


언리얼 엔진 4.17 당시에는 기능 레벨이 저장되지 않아서 문제가 많았습니다.

지금은 대부분 업데이트가 되었습니다.

이 부분은 제가 직접 만들었습니다.

랜드스케이프 레이어의 한계로 인한 수정과 당시에는 없던 셰이더를 추가로 개발했습니다.

모바일 게임에서 사용하기 어려운 SSAO 부분은 최적화해서 옵션으로 개발했습니다.

그리고 라이트맵을 사용하지 않았습니다.

오픈 필드에서는 라이트맵의 효과가 미미했고, 셰이더 용량 등을 고려했을 때 라이트맵 없이 개발하기로 결정했습니다.

하지만 개발 당시 던전의 라이팅 효과를 어떻게 할지에 대한 논란이 많았습니다. 처음에는 던전 개발 부분에 라이트맵을 사용하려고 생각했지만, 개발 과정이 복잡해 라이트맵을 사용하지 않기로 결정했습니다.

하지만 이 부분은 개발자와 아티스트가 많은 고민과 고민을 통해 라이트맵 없이도 비슷한 효과를 낼 수 있도록 구현했습니다.


저희 게임은 와이드 오픈 월드이기 때문에 랜드스케이프 퀄리티가 좋아야 했습니다.

지금 보이는 화면처럼 넓은 시야를 확보하는 것이 목표였습니다.

시야각은 약 1.5km입니다.

보통 다른 프로젝트에서는 랜드스케이프를 잘 사용하지 않았습니다.

하지만 저희는 랜드스케이프를 사용했고 지금은 많은 업데이트를 통해 충분합니다.

월드가 넓은데, 보통 유저는 결국 텔레포트로 이동해야 하는데 로딩 부분을 잘 처리해야 하거든요.

저희 회사의 요청은 게임에서 로딩을 없애달라는 것이었습니다.

다시 생각해보면 로딩이라는 느낌을 없애는 것입니다.

이렇게하려면로드 된 유닛을 조각으로 나누는 것이 가장 중요합니다.

그러나 넓은 세상이기 때문에 작업하기가 어렵습니다.

이 부분은 자동화할 수 있어야 합니다.

또한 월드 컴포지션은 평소에는 큰 작업을 하지 않지만 오픈월드 개발 시에는 조각난 데이터를 자동으로 처리할 필요가 있습니다.

참고로 퍼시스턴트 레벨 부분에 문제가 있는데, 모바일 게임 환경에서 퍼시스턴트 레벨을 새로 전환하는 것은 비용이 매우 많이 듭니다.

그래서 루트 퍼시스턴스 레벨을 하나만 생성하고 나머지 데이터는 그 안에 에셋을 불러와서 사용하는 방식을 선택했습니다.

청사진을 요약한 것입니다.

개인적인 생각입니다.

청사진은 재앙입니다.

협업의 어려움.
구조화하기 어렵다.
가독성이 나쁘다.
프로그래머들은 싫어합니다.
블루프린트는 축복입니다.

누구나 쉽게 접근할 수 있습니다.
빠른 컴파일 속도.
빠른 개발 주기.
게임 디자이너가 좋아할 것입니다.
그래서 정책적으로 블루프린트는 최소한으로 사용했습니다.

기본적으로 사용되는 BP를 사용했습니다 (ANIM BP 또는 위젯 BP와 같이 반드시 사용해야하는 BP가 있습니다).

개인적으로는 아예 사용하지도 않았습니다.

굳이 써야 할 상황이 있다면 복잡한 로직을 추가하지 않기로 했습니다.

가끔 기능을 빠르게 프로토타이핑할 때만 사용하긴 하지만 거의 사용하지 않습니다.

간단한 도구를 추가하거나 프로토타입을 구현할 때를 제외하고는 정책으로 최소한의 용도로만 사용됩니다.

저희는 이 정책을 선택했지만 팀마다 상황이 다르기 때문에 각 팀에서 상황에 맞는 판단을 내리면 됩니다.

언리얼 엔진의 공식 지원 버전은 C ++ 14입니다.

저희의 경우 14이지만 최신 사양은 언리얼 엔진과 잘 맞지 않았습니다.

예를 들어 비주얼 스튜디오에서 컴파일하면 잘 작동합니다. 하지만 GCC나 CLANG으로 컴파일할 때는 특히 템플릿 부분에서 문제가 많이 발생했습니다.

그래서 저희는 정책적으로 최신 C ++ 표준을 사용하지 않기로 결정했습니다.

언리얼 엔진 4.21에서는 STL을 거의 사용하지 않았고, 실험 클래스에서만 사용했으며 빌드 시에는 거의 STL을 제거했습니다.

결론적으로 STL을 사용하지 않기로 결정했습니다.

STL을 사용해야 하는 경우 로케이터를 언리얼 엔진 메모리 매니저에 올바르게 연결해야 문제가 없습니다.

얼마 전에도 업데이트 히스토리에 대해 이야기했지만 포트나이트의 성공 이후 모바일 부분에서도 많은 업데이트가 이뤄졌습니다.

엔진도 성능도 좋아졌지만 하드웨어도 단시간에 많이 발전했습니다.

소프트웨어는 어떻게 사용하느냐에 따라 속도가 느려질 수 있지만 하드웨어는 충분히 신뢰할 수 있을 정도로 빠릅니다.

아직은 안드로이드폰과 아이폰을 비교할 수밖에 없지만 아이폰의 하드웨어 성능은 좋습니다.

이 점은 삼성 갤럭시폰 개발자들도 인정한 부분입니다.

아이폰은 하드웨어뿐만 아니라 OS도 더 좋습니다.

하지만 안드로이드 개발자들도 아이폰처럼 안정적으로 업그레이드하기 위해 노력하고 있습니다.

일반적으로

언리얼 엔진 4.21 이후로는 확실히 모바일 게임 개발에 유용한 엔진이라고 할 수 있습니다.

그 전에는 유니티가 모바일 분야에서 매우 라이트한 엔진이었다고 생각하는데, 언리얼 엔진 4.21 이후에는 모바일 게임 개발에서 충분히 좋은 엔진이 되었다는 점을 말씀드리고 싶습니다.

이번 발표는 2019년 4월에 열린 에픽게임 언리얼 서밋 2019에서 엔씨소프트 리니지2M 개발팀이 발표한 내용을 참고하여 작성했습니다.

언리얼 엔진의 최신 업데이트 내용은 포함되지 않았습니다.

콘텐츠 끝.