Nightingale의 도약: Inflexion Games가 개발 중 UE4에서 UE5로 업그레이드한 방법

엔진 업그레이드 관리 프로세스

블루프린트 프로젝트의 경우에는 엔진 업그레이드 과정도 매우 간단합니다. 업데이트할 코드가 없으니 새 엔진 버전에서 프로젝트를 로드한 다음, 어떤 에셋 오류가 발생하는지 확인하고 엔진에서 문제가 되는 부분을 수정하기만 하면 됩니다.

코드 프로젝트 업그레이드는 더 복잡한데, 여기서는 그 부분을 살펴볼 것입니다. 핵심은 엔진을 얼마나 커스터마이징했느냐입니다. 엔진을 수정하지 않았다면, 앞서 말했듯 업그레이드 또한 매우 간단합니다. 하지만, 엔진을 많이 수정했다면 업그레이드는 훨씬 큰 노력을 기울여야 하는 작업으로 돌변합니다. 저희 상황은 그 중간쯤이었고 다음 사례가 업그레이드 프로세스 관리에 도움이 됐습니다.

엔진 차이 관리하기

엔진 차이를 관리하면 코드 충돌 병합 프로세스가 간소화되므로 엔진 변경사항을 마크업하고 추적하는 데 도움이 됩니다. 나이팅게일의 경우 다음 프로세스를 따랐습니다.

• 모든 엔진 변경사항을 승인자 그룹이 검토합니다. 저희의 경우 승인자들은 엔진 업그레이드를 처리하는 프로그래머이므로 유지관리하기 어려울 것 같은 변경사항을 분류할 수 있습니다.
• 저희는 최대한 많은 변경사항을 에픽에 푸시할 것을 권장합니다. 언리얼 엔진에 기여를 참조하세요. 이렇게 해서 저희는 향후 출시에서 코드 차이를 제거할 수 있습니다.
• 모든 변경사항은 코드에 태깅되고 Jira 티켓으로 추적됩니다. 그 예는 다음과 같습니다.

// NTGL_BEGIN - NTGL-1234 - [IMPROVEMENT] 초기화되지 않은 변수 수정
// int IntVar;
int IntVar = 0;
// NTGL_END
 

• 차이는 다음과 같이 분류합니다.
  • [IMPROVEMENT] - 에픽에 전송하기 적합한 변경사항
  • [TEMP] - 일반적으로 다음 주요 엔진 업데이트까지 일시적으로만 필요한 변경사항
  • [PREPORT] - 향후 업데이트에서 풀링한 변경사항
  • [DIVERGENCE] - 게임 출시에 필요하지만, 에픽에 푸시하기에는 적합하지 않은 변경사항(저희는 보통 이런 변경사항은 피하려 합니다)
• Jira 티켓 덕분에 UDN 링크, 변경사항이 필요한 다른 작업 링크 및 변경사항을 제거하는 데 필요한 작업과 같이 변경사항을 중심으로 한 추가 컨텍스트를 추적할 수 있습니다.
• 차이를 엔진 업데이트에 쉽게 병합할 수 없으면 저희는 보통 저희 쪽의 변경사항을 빼고 새 코드를 중심으로 그 부분을 다시 구현하거나 변경사항을 아예 포기합니다.  

통합 프로세스

엔진 업데이트 작업은 처음에는 간단합니다. 에픽의 Github에서 업데이트를 받아 엔진 폴더 아래의 모든 파일을 교체하고 P4V를 통해 오프라인 작업 레컨사일을 하기만 하면 됩니다. 하지만, 엔진 코드를 변경하는 순간 업데이트 작업은 제어 불가능한 작업으로 돌변합니다.

저희는 Perforce의 스트림 디포를 활용하여 다음과 같은 브랜치를 확립했습니다.

디포/스트림	설명
//ue4/release-4.27 //ue5/release-5.0	수정 안 된 UE4/UE5 출시의 미러
//ntgl/dev	팀 대부분이 작업하는 메인 개발 스트림
//ntgl/integrate	엔진 업데이트를 병합하는 자손 개발 스트림 이 스트림은 모든 문제가 해결될 때까지 깨진 상태가 될 것으로 예상됨

UE5로 업그레이드를 시작하기 전에 최종 UE4 버전(//ue4/release-4.27)을 통합된 스트림에 병합하여 리비전 히스토리를 확립해야 합니다. 아직 4.27을 사용하고 있지 않다면, 한 번에 여러 버전을 뛰어넘는 것도 고려해 볼 수 있습니다. 저희 경험으로는 한 번에 버전 하나씩 점진적으로 업그레이드하기가 더 쉬웠습니다.

그런 다음, 다음과 같이 release-5.0 브랜치를 설정합니다.

• p4 copy //ue4/release-4.27 -> //ue5/release-5.0 (초기에 4.27 사본으로 생성됨)
• 공식 릴리즈에서 //ue5/release-5.0 콘텐츠 업데이트

이제 업데이트 및 병합 단계가 시작됩니다.

1. 개발 스트림의 모든 변경사항을 통합 스트림으로 병합합니다.
   • 콘텐츠 변경사항과 충돌이 있다면 콘텐츠 크리에이터의 작업물이 손실되지 않도록 항상 개발 스트림의 변경사항을 수용합니다.
2. 원하는 언리얼 출시 버전을 별도의 Perforce 디포에 미러링합니다(예: //ue5/release-5.x).
   • 이 미러는 수정되지 않은 상태로 유지되어야 하며, Perforce의 리비전 히스토리에서 엔진 변경사항을 추적하는 역할을 하며 병합 단계에 도움을 줍니다.
3. //ue5/release-5.x ->//ntgl/integrate로 병합/통합합니다.
4. 병합 충돌을 해결하고 제출합니다.

위 단계는 수동으로 완료할 수도 있지만, 스크립팅을 통해 자동화하면 수고를 크게 줄일 수 있습니다.

업데이트를 병합한 다음에는 엔진 업그레이드 작업을 다음과 같은 개별 단계로 세분화할 수 있습니다.

5. 코드 프로젝트 생성과 관련된 경고 및 오류 수정
6. 컴파일 및 링크 오류 수정
7. 에디터 및 쿠킹 오류 수정
8. 자동 테스트 실패 수정
9. 게임 버그 수정

자동화

자동화에 투자하면 업그레이드 프로세스 간소화에 큰 도움이 됩니다. 이상적으로는 통합 스트림에 대해 반복 가능한 빌드 프로세스를 실행하고 모든 것이 제대로 작동하는지 검증한 다음 개발 스트림에 통합하는 것이 좋습니다. 다음과 같이 저희에게 도움이 됐던 몇 가지 추가 영역이 있습니다.

• 포괄적인 자동 테스트 툴세트에 투자하고 관리하면 수동 테스트를 진행하기 전에 많은 문제를 파악할 수 있습니다. 저희의 경우, 처음 UE5로 전환할 때 자동 테스트를 통해 UE4의 피직스 엔진과 UE5의 카오스 피직스 간에 많은 불일치를 발견할 수 있었습니다.
• 스크립트를 작성하면 릴리즈 미러링 프로세스와 다양한 병합 단계를 매우 빠르게 진행할 수 있습니다.
• 게임을 쿠킹하기 전에 에셋 유효성 검사를 실행하고 모든 블루프린트를 컴파일(-run=CompileAllBlueprints)하는 자동화 검사를 추가하면 에셋의 추가 문제를 포착하는 데 도움이 됩니다.
• 개발 스트림과 정확히 동일한 빌드 프로세스를 통해 통합 스트림을 자주 실행하면 최종 병합 전에 숨어있던 엣지 케이스를 포착할 수 있습니다.
• 대규모 플레이테스트를 할 수 있도록 통합 스트림의 테스트 빌드 배포 시스템에 투자하면 게임 관련 문제를 일찍 발견하는 데 도움이 될 수 있습니다.

팁과 트릭

업그레이드 진행 프로세스를 간소화하기 위해 저희가 따르는 다양한 팁을 모아 보았습니다.

• 주요 엔진 업그레이드를 진행할 때 파일 대부분은 자동으로 해결되지만, 수만 개의 변경사항이 포함된 체인지리스트가 남게 됩니다. 다음 p4 명령을 사용하면 수동으로 해결해야 할 파일을 별도의 체인지리스트로 분리할 수 있습니다.

p4 -F %localPath% resolve -n | p4 -x - reopen -c [new changelist #] 
 

• 컴파일 및 링크 오류를 수정할 때는 -DisableUnity로 컴파일합니다. 이러면 언리얼 빌드 툴에서 여러 .cpp 파일을 하나의 파일로 만드는 컴파일 최적화가 비활성화됩니다. 컴파일이 더 오래 걸리지만, 컴파일 문제 추적이 훨씬 쉬워지고 include 구문 누락과 관련된 문제도 파악할 수 있습니다.
• Github를 통해 언리얼 엔진을 받은 경우, GitDependencies.exe에서 얻은 파일을 채울 방법을 정해야 합니다. 개발자가 이러한 파일을 개별적으로 업데이트할 수도 있지만, 저희는 이러한 파일을 미러 자동화 스크립트에 통합하여 자체 Perforce 미러에 제출했습니다.
• 언리얼 엔진의 지원 중단 경고는 주의해서 살펴봐야 합니다. 올바른 프로젝트 업그레이드 방향을 제시하는 경우가 많기 때문입니다. 컴파일 경고를 0개로 유지하면 이러한 지원 중단 관련 내용을 훨씬 쉽게 파악할 수 있습니다.
• 통합 스트림에 모든 에셋을 포함한다는 것은 필요한 경우 개별 에셋을 업그레이드할 수 있다는 뜻입니다. 저희는 개별 에셋 업그레이드를 많이 할 필요가 없었지만, 이러한 에셋이 메인 개발 스트림에서 정기적으로 수정되는 경우 관리가 번거로울 수 있습니다. 이 문제에 도움이 될 몇 가지 제안 사항이 있습니다.
  • 개발 스트림에서 최소한의 엔진 변경사항만 선별하고 개발팀에서 그 에셋을 업데이트할 수 있다면, 충돌 발생 가능성을 제거할 수 있습니다.
  • 커맨드릿을 사용하여 그 에셋을 업그레이드할 수 있다면, 각 병합 이후에 실행되는 커맨드릿을 빌드하여 모든 관련 에셋을 최신 상태로 유지할 수 있습니다. 일반적으로 이러한 에셋은 최신 버전의 에디터에서 다시 저장하기만 하면 됩니다.
• 에픽에서는 릴리즈가 초기 프리뷰 상태에 들어가기 전에도 릴리즈 브랜치에 액세스할 수 있게 해줍니다. 그러면 예정된 릴리즈 병합을 미리 시작하고 한 번에 병합하는 코드의 범위를 좁힐 수 있습니다. 마찬가지로, 개발 라인에서 매일 병합을 하면 어려운 병합을 바로 인터셉트할 수 있으므로 관련 개발자와 협력하여 문제를 해결할 수 있습니다.
• 마켓플레이스나 기타 벤더의 타사 플러그인에 의존하는 경우, 이러한 플러그인이 업데이트될 때까지 조금 기다리는 것이 좋습니다. 저희는 이러한 업데이트에 앞서 업그레이드하려 할 때가 많은데, 그러면 조금만 기다리면 '그냥' 받을 수 있는 플러그인을 업데이트하기 위해 노력을 더 들여야 합니다.
• 새로 엔진을 업그레이드할 때마다 정말 유용한 기능도 몇 가지 추가됩니다. 이런 새 기능을 바로 활용하고 싶지만, 저희 목표는 항상 게임이나 개발자 워크플로에 의미 있는 변경사항을 최대한 적게 적용하는 새 엔진 업데이트를 초기에 푸시하는 것입니다. 개발 스트림에서 업그레이드가 안정적이라고 확정한 다음에야 새 기능을 시험해 볼 수 있습니다.

 

언리얼 엔진 5의 이점

루멘과 나나이트로 업그레이드하면 정말 굉장하리라고 생각했습니다. 게임의 반사광이 더 정확해지고 폴리곤 예산이 대폭 늘어나는데, 누가 이걸 마다할까요?

버추얼 섀도 맵도 활용해 보고 싶었기에 나나이트로 프로젝트를 변환하는 데 시간이 오래 걸렸습니다. 언리얼 엔진 5는 나나이트 에셋과 비나나이트 에셋 간의 상호 호환성을 지원하므로 에셋을 점진적으로 변환할 수 있었고, 변환 과정에서 완전한 플레이 경험을 제공할 수 있었습니다. 즉, 나나이트를 사용하도록 에셋을 더 변환할수록 버추얼 섀도 맵의 성능이 향상되므로 이러한 변환을 수행하면 게임의 수행 방식을 이해할 수 있다는 이점도 있습니다.

개별 에셋의 변환 프로세스는 다음 카테고리 중 하나에 속하는 경향이 있습니다. 

• 이미 퀄리티가 상당히 높은 에셋은 해당 메시에서 나나이트만 활성화했습니다. 
• 일부 에셋은 더 높은 퀄리티로 재작성했을 때 이점이 있기에 나나이트를 염두에 두고 리빌드했습니다. 
• 저희 게임의 플레이어 제작 건축물에는 플레이어가 건축물을 배치함에 따라 투명하게 렌더링되는 커스텀 셰이더가 있었습니다. 나나이트는 불투명 오브젝트만 지원하므로, 메시가 이러한 특수 모드에 있을 때 비나나이트 투명 메시로 돌아가는 시스템을 구현했습니다.

5.0에서 5.2로 버전이 업그레이드되면서 엔진의 여러 기능이 개선된 것을 알았습니다. 볼류메트릭 클라우드 렌더링이 개선됐고 루멘을 사용한 폴리지 렌더링도 개선됐습니다. 결국 나나이트와 루멘, 버추얼 섀도 맵 조합으로 상당히 인상적인 비주얼을 만들 수 있었습니다.