(GDC) 어새신크리드 오리진: 월드 디자인 데이터의 모니터링과 검증

---

원제: Assasin's Creed Origins: Monitoring and Validating of World Design Data

원문 주소:
https://www.gamasutra.com/view/news/358056/Video_Monitoring_and_validating_world_design_data_in_Assassins_Creed_Origins.php

Gamasutra 2020.02.12 Posted

강연자: Nicholas Routhier

강연자 약력: https://ca.linkedin.com/in/nicholas-routhier

---

1. 요약

• 대규모 프로젝트에서 Daily Automated Testing Process의 필요성, 적용 사례, 효과에 대한 강연.

 

2. 본문

2.1. 필요성

수작업으로 데이터 검증하려면, 검증 단 1회!에 20명 이상의 인력이 2달 넘게 붙어야 함.

• Assasin's Creed Origins의 버그를 색출하고 대처하는 작업은 기존의 방식으로는 너무 큰 비용이 든다.
• 120제곱킬로미터에 달하는 스케일을 가졌기에, 검증할 데이터가 많기 때문이다.
• 또한, 상호의존/배타적이어야 기능하는 오브젝트가 다수 존재하고,
  프로젝트 규모 상 많은 인력이 동시에 많은 작업을 진행하므로 버그가 발생하기 쉽다.
• 따라서, 잦은 간격으로 빠르게 빌드를 모니터링하고 데이터 검증할 수 있는 방법이 필요하다.

 

2.2. 발생하는 문제들

2.2.1. 절차 생성 상의 문제)

• 짚라인 중간에 나무가 절차생성될 경우, 짚라인을 이용할 수 없다. 
• 짚라인의 경사가 너무 가파를 경우, 애니메이션이 자연스럽지 않게 되어 플레이어 경험을 해칠 수 있다.

2.2.2. 메타 AI 상의 문제)

• AI의 경로 노드는 네비게이션 메쉬 위에 있어야 제대로 동작함.
• 레벨 작업이나, 프랍 배치 시 이러한 AI 노드가 고려되지 않고 작업되기 쉽다.
• 예를 들어, 레벨디자이너나 레벨아티스트가 노란 부분처럼 방패 프랍을 추가했을 때, AI 노드가 간섭받는다.
• 해당 프랍의 배치 때문에, AI 동작이 불가능하게 된다.

대규모 협업 환경에서는, 이렇듯 의도치 않은 버그가 생기기 쉽다.

• 어쩌면, 다른 스튜디오에서 작업하는 프랍 모델러가, 위의 버그를 제보 받는다면?
• 프랍의 Collision을 수정하게 될 경우, 해당 프랍은 월드 전체에 공용으로 사용되므로 어디선가 문제가 발생한다.

 

• 엔진프로그래머가 교체되거나, 엔진 업데이트가 있었다면?
• 의도치 않게 모든 경사면의 네비게이션이 사라졌을 수도 있다.
• 아래 그림과 같이 어떤 NPC도 발리스타 등의 구조물을 이용할 수 없게 된다.

누구나 각자 다른 이유로 의도치 않게 시스템을 망가뜨릴 수 있다.

2.2.3. 그래서)

• "망가진 시스템이 왜 생겼고, 몇 개나 있는가"를 트래킹할 수 있는 시스템이 필요하다.
• 이 모든 것을 검증하고 테스트하는 데 시간을 보내기보다, 문제점을 찾아낼 수 있는 물건을 원했다.

 

2.3. Daily Automated Testing of World Design Data

2.3.1. 개념)

• Inputs에 대한 Data Analysis 결과를 Outputs화한다는, 심플한 프로세스다.

2.3.2. Inputs)

• 수작업으로 배치된 모든 데이터
• 절차생성 데이터
• 네비게이션 메쉬 데이터
• 코드 (게임플레이 / 엔진 /기획의도^[각주:1])

2.3.3. Data Analysis)

 

 

• AnvilScript라는 것을 이용해, 에디터와 엔진 내의 모든 기능과 오브젝트에 쿼리^[각주:2] 가능한 환경을 구축했다.

 

• 3개의 테스트 타입이 존재했다.
• 분석 결과는 참 / 거짓의 형태로 반환되어, 문제가 있음 / 없음을 가려낸다.

각각 배치 측정 / AI네트워크 테스트 / 로케이션 테스트

 

2.3.3.1. 배치 측정

• 각 오브젝트들의 타입을 분류하고, 타입 별 측정 필요 항목을 지정해 테스트
• 처음엔 4개의 타입 뿐이었지만, 총 22개의 타입이 존재하게 되었다. 

 

2.3.3.2. AI 네트워크 테스트

• AI 노드가 네비게이션 메쉬 위에 없으면, 그것을 오류로 판단한다.
• 각 NPC에 지정된 "X로 이동해라"라는 이벤트는 X라는 Station을 필요로 하는데, 
  NPC 스폰 지점에서 각 Station으로 이동 가능한 경로가 있는지를 체크하여, 없으면 오류로 판단한다.

2.3.3.3. 로케이션 테스트

• Assasin's Creed Origins에는 "로케이션"이란 개념이 존재한다.
• 기획 의도에 따라 특정 데이터가 어느 로케이션에 소속된 것인지 검증한다.
• 예를 들어, 하단 그림은 1개 로케이션에서 오류가 난 항목을 Output으로 반환한 것이다.

2.3.4. Outputs)

• 테스트 결과는 엑셀, 이메일, 아틀라스로 프로젝트 내에 공유된다.
• 엑셀은...

• 이메일은...

 

• 아틀라스는 Ubisoft 자체 개발 툴으로, 게임 월드를 만들기 위한 구글 맵스.
  버그를 시각화해서 보여주기 때문에, 아주 빠르게 버그를 캐치하고 수정할 수 있다고 함.

뻘건 부분이 문제가 있는 배치 상태라고 한다.

2.3.5. 이터레이션)

 

2.4. 효과

2.4.1. 빠른 검증 속도)

게임 내 모든 데이터 검증 단 세 시간.

2.4.2. Then & Now)

• 버그의 능동적 대처
  예전에는 버그를 쌓아 두다가, 어느 포인트에 색출하여 대처하는 형태였음.
  또한, 문제의 범위를 특정하지 못한 채 현상만 발견할 뿐이었음.
  하지만, 매일 버그를 문제 원인과 함께 메일로 리포트받게 되면서,
  발생한 버그의 원인에 대해 능동적인 대처가 가능해졌다.
• 개발에 할애할 수 있는 시간이 늘어남
  예전에는 지정된 숫자의 QC를 통과하고 나면, 데이터를 Lock하고 더 이상 건드리지 않았음.
  매일 자동 테스트가 가능해지면서, 컨텐츠 제작자들이 더 많은 시간을 컨텐츠 제작에 할애할 수 있게 되었음.
  이러한 이터레이션은 게임 퀄리티의 상승으로 이어짐.
  
  
• 버그 색출의 정밀도 증대
  QC 부서가 모든 버그를 단 번에 찾아내는 방식에서,
  매일 테스트를 돌려 반복적으로 버그 색출하게 되었음.

2.4.3. 정량화 데이터의 확보)

• 정량화된 데이터는 관리될 수 있음.

2.4.4. 안정적인 디버그)

• 버그 색출 시기를 앞당겨, 까다로운 버그들에 대처할 시간을 확보할 수 있다.

2.5. 강연자 자신의 소감

• 프로덕션의 이른 시기부터 시행하면 매우 효과적이다.
• 테스트가 잦은 주기로 이루어짐으로써,
  테스트 후 "문제 없잖아? 이 일은 해결!" 이라고 느끼는, "잘못된 낙관"에 빠지지 않을 수 있다.
• 자동화 이후, 이메일을 쓰는 시간이 줄어 작업 능률 향상.

2.6. 앞으로 보완할 것

• Velocity Chart를 만들어, 버그 처리에 대한 현황을 체크할 수 있도록 만들기
• 만든 후 데이터 검증을 시행하는 것이 아니라, 만드는 단계에서 에러 방지할 수 있는 방법 찾기

---

1. 기획의도란, 게임 내의 각 장소가 어떤 타입이고, 어떤 행동이 가능한지에 대해 기입된 엑셀파일이었음. [본문으로]
2. 데이터베이스에 정보를 요청하는 것 [본문으로]