반다이 남코에서 철권 프로젝트를 담당하는 분의 설명 내용을 간추렸습니다.

철권 6와 철권 태그 토너먼트 2는 PS3 기반의 아케이드 기판으로 구동했는데, 태그 토너먼트 2의 경우 2대 2, 총 4명의 캐릭터가 나오기에 PS3의 성능으로 힘든 경우도 있었다고 합니다. 그래서 동적으로 해상도를 바꾸는 가변 렌더링 시스템을 도입했다고 하는데요.

철권 7은 하이엔드 PC 아키텍처를 쓴 아케이드 시스템 보드인 ES3를 쓰기에, 여기에 맞춰 그래픽 표현도 높였다고 합니다.

반다이 남코는 자사 게임 엔진인 NU 라이브러리가 있어, 나루토 얼티밋 스톰, 죠죠의 기묘한 모험 등의 게임을 개발했지만 철권 7에선 이를 쓰지 않았다네요. 이유인즉슨 철권 7의 출시 예정일과 NU 라이브러리의 차세대 버전 완성 스케줄이 맞지 않아서.

여러 게임 엔진을 검토했지만 하이엔드 그래픽을 위해 언리얼 엔진을 쓰기로 했습니다. 이 결정을 2013~2014년에 했는데, 당시엔 언리얼 엔진 4가 막 발표됐던 때라 채용 실적과 안정성이 검증되지 않았습니다. 아크 시스템 웍스도 안정성을 높게 평가해 길티기어 Xrd SIGN에서 언리얼 엔진 3를 쓰기도 했지요.

그래서 약간의 위험을 무릅쓰고 언리얼 엔진 4를 쓰기로 했다네요. 결정적인 건 에픽 게임의 실시간 데모인 엘리멘탈과 인피트레이터. 물리 기반 렌더링으로 그래픽 표현이 대폭 상승, 캐릭터와 배경의 수준을 모두 높일 수 있었다고 합니다. 철권에 자주 등장하는 화려한 이펙트 표현도 GPU 파티클 시스템으로 한정 더 높일 수 있을 거라 판단했다고.

언리얼 엔진을 쓰는 건 성공과 실패 모두 반다이 남코에게 좋은 경험이 될 것이라 판단해서 도입한 것도 있다고 합니다.

또 PS4, Xbox One, 다이렉트 X 11 기반을 지원하는 범용 게임 엔진이라 게임 이식도 쉽다는 점도 작용했습니다.

하지만 나온지 얼마 안된 게임 엔진이라 업데이트가 많이 나올 것이고, 그때마다 다른 미들웨어와 호환성 문제가 생기지 않을지, 게임 데이터에 문제가 생기지 않을지 불안한 점도 있었습니다.

또 철권 7 개발팀에서 해결할 수 없는 문제가 생기면 에픽 게임에서 얼마나 지원할 수 있를지도 불안했는데, 에픽 게임 재팬의 지원 능력이 언리얼 엔진 3보다 훨씬 나아져서 괜찮을 것이라 판단했다고 합니다.

그리고 가격도 협상.

다음은 비주얼 아티스트인 기무라 켄지의 설명입니다.

비주얼 섹션 팀의 구성.

처음에는 20명으로 시작해서 나중에는 40명으로 늘렸습니다. 협력사까지 감안하면 60명 이상. 언리얼 엔진 4를 써서 게임을 만든다면 20~30명 정도.

2013년 9월에 프로젝트를 시작하고 11월에 언리얼 엔진 4의 검증을 시작, 2014년 1월에 언리얼 엔진 4를 정하고 3월 말에 기술 검증, 4월에 제작 개시, 7월에 정보 공개, 10월에 테스트. 2015년 3월에 출시. 1년이 걸린 셈입니다. PC 기반 시스템으로 개발해서 구동했기에 시간을 줄일 수 있었습니다.

비주얼 컨셉

제작 볼륨.

기술적인 이슈에 대해 리드 프로그래머가 설명했습니다.

언리얼 엔진 4는 계속해서 발전하는 것이기에 다소 위험 부담이 있습니다. 이를 위해 언리얼 엔진 4의 모든 기능을 쓰는 게 아니라 순수한 그래픽 엔진(렌더러)로만 쓰기로 했습니다. 반대로 말하면 엔진의 모든 기능을 쓰지 않으니 아깝기도 한데, 그래도 언리얼 엔진 4에 문제가 생겼을 경우 렌더러만 다시 하면 되니까 일정 지연을 최소화할 수 있습니다.

철권 7의 게임 코어는 언리얼 엔진 4와 독립된 모듈로 개발됐지요. 플레이어의 입력 제어를 받아 스크립트 처리, 캐릭터 상태 이동 제어, 캐릭터 애니메이션 계산과 제어, 충동 판정과 카메라 제어 등이 모두 독립된 모듈입니다.

렌더링 엔진은 와이어 프레임 표시로 대체해도 여전히 작동합니다. 나중에 NU 라이브러리의 차세대 그래픽 엔진이 나오면 그걸로 대체하는 것도 가능. 이와 함께 별도의 미들웨어도 같이 사용했습니다.

업계 표준과도 같은 UI 디자인 툴 미드웨어인 스케일폼을 썼는데요. 철권 7의 개발은 언리얼 엔진 4.1에서 시작해 4.4로 출시됐지만, 4.5에서 언리얼 모션 그래픽 UI 디자이너 설계 툴이 추가됐습니다. 그러니 그 전에 출시를 위해 UI 설계는 다른 툴을 썼어야 했지요.

사운드는 Wwise를 썼습니다. 언리얼 엔진 4에 사운드 제작 시스템이 없고, 사운드 개발팀이 요청한 것이기도 합니다. 동영상 코덱은 Bink 2를 사용.

이렇게 언리얼 엔진 4와 독립된 모듈의 코어는 서로 연동되도록 통합할 필요가 있습니다.

캐릭터 액션 애니메이션은 언리얼 엔진 4의 애니메이션 시스템에 사용자 정의 노드 형태로 넣었습니다.시점 제어(게임 카메라)도 철권 7 개발 팀이 자체 개발한 모듈로서 언리얼 엔진 4의 카메라 제어를 대체하도록 했습니다.

이 외에 입자 효과, 사운드, 지형과 배경과의 충돌 정보 조회, 이벤트 발생시 엔진에 통지 등도 전부 독자적으로 개발했습니다.

게임 진행 부분도 독자 개발했습니다. 언리얼 엔진 4의 엔진루프에 통합해 언리얼 엔진 4의 제어 부분이 따로 나와 게임 진행을 제어하는 식입니다.

배틀 스테이지의 구현이나 로딩의 경우, 게임이 끝날 때까지 배틀 스테이지를 PersistentLevel로 돌리고, 대전 액션이 끝나고 다른 배틀 스테이지를 가져올 경우 언리얼 엔진 4가 읽기 중에 비동기로 다른 작업을 수행하도록 했습니다.

그래서 오브젝트가 아무것도 없는 더미 데이터인 배틀 스테이지를 루트 레벨로 설정하고, 게임에 쓰이는 실제 배틀 스테이지를 더미 위의 서브 스테이지로 구현하는 변칙적인 방법을 썼습니다. 즉 각각의 레벨은 공간적으로 연결돼 있으나 데이터 관리는 그렇지 않다는 식입니다. 그래서 로딩을 하기 위해 게임 플레이가 멈추지 않습니다.

다만 이렇게 해서 전체 로딩 시간이 길어지거나 초기화 단계에서 부하가 높아지고 프레임 속도가 불안정할 수도 있습니다. 이는 ES3 기판의 운영체제인 윈도우 임베디드 파일 캐시 시스템에 로드 데이터를 넣어 해결했습니다. 사실 언리얼 엔진 4의 동적 로딩 후 첨부하는 문제는 4.8과 4.9 버전에서 개선이 됐다고 합니다.

배틀 스테이지의 데이터를 모두 캐시에 올리려면 25GB의 메모리가 필요하기에 관리가 복잡해지며, 지금도 개선점을 찾고 있는 중입니다.

철권은 복장과 액세서리의 커스터마이즈가 가능합니다. 그래서 캐릭터의 3D 모델을 각 부위별로 관리합니다.

처음에는 성가시다고 여겼으나 언리얼 엔진 4의 기본 기능을 황요하니 간단하게 해결됐다고 합니다. 언리얼 엔진 4에서 각각의 캐릭터에 공통된 스켈렉톤 구조를 설정하고 거기에 각각의 부위 모델을 끼워나가게 됩니다. 이 경우 CPU 처리가 늘어날 것이라 예상했으나 실제로는 그렇지 않았기에 이대로 결정.

철권 7은 일본 게임답게 반투명 효과를 많이 씁니다. 머리카락이나 옷자락 등을 그릴 때 주로 쓴다네요.

다만 언리얼 엔진 4의 Deferred Rendering은 G 버퍼 스테이지에서 다각형에 광원 처리와 음영 처리를 해서 출력합니다. 라이팅과 쉐이딩을 나중에 하기에 지연(deferred) 렌더링이라고 하는데, 이렇게 귀찮은 방법을 쓰는 이유는 동적 광원을 무제한으로 배치할 수 있어서입니다. 반면 반투명 오브젝트를 쓰기 어렵다는 단점도 있지요.

반투명 오브젝트는 그 너머로 물체가 비춰보여야 하기에 순서대로 그려야만 하는데 Deferred Rendering은 반투명 오브젝트를 염두에 두지 않은지라 렌더링 순서를 정할 수 없습니다. 그래서 철권 7은 언리얼 엔진 4를 고치지 않고 반투명 표현을 하기 위해 한가지 방법을 고안했는데요.

반투명 요소

불투명 요소

반투명+불투명 

먼저 불투명 오브젝트를 Deferred Rendering로 그려내는데 이때 폴리곤이 반투명을 포함하는지 판정, 만약 그렇다면 적용된 텍스처를 참조해 그 텍스처의 불투명 영역만 이 Deferred Rendering 패스로 렌더링합니다. 언리얼 엔진 4는 반투명 오브젝트에 대한 라이팅/쉐이딩을 동시에 실시하면서 그려나가는 고전적인 Forward Rendering 구조인데, 이 때 반투명을 포함한 폴리곤 영역만 그려나갑니다.

즉 불투명과 반투명이 섞인 다각형(머리카락이라던가)은 Deferred Rendering으로 불투명을 그린 후 Forward Rendering -순서대로- 그려나갈 때 반투명을 그립니다. 즉, 불투명/반투명이 섞인 폴리곤은 두번 나눠서 렌더링한다는 것입니다. 이 방식을 구현할 때는 서로 섞이는 부분의 폴리곤 데이터를 이중화해야 하는데, 이는 3DCG 소프트웨어에서 언리얼 엔진 4로 내보낼 때 가공 처리를 한다네요.

머리카락과 새틴 원단 등의 광택 반사 표현은 이방성 반사 표현을 활용했습니다.

또 배경 조명과 상관 없이 캐릭터의 실루엣을 선명하게 보여주기 위해 캐릭터 전용 광원을 구현했습니다.Deferred Rendering은 해당 장면의 지오메트리를 먼저 그리기에 특정 3D 모델 전용 광원으로 쓸 수 없습니다. 어떤 장면에 광원을 두면 그 광원은 범위 안에 들어오는 모든 것을 비추거든요. 물리적으론 이게 맞는 말이지만.

그러나 철권 7에선 다른 캐릭터에게 영향을 주지 않는 캐릭터 전용 광원 효과를 넣었습니다. Deferred 렌더링의 G 버퍼 생선 단계에서 캐릭터를 그릴 때, 캐릭터 전용 광원의 ID 번호를 기록하고, 라이팅/쉐도우 단계에서 ID 정보가 기록된 픽셀은 그 ID 번호에 해당되는 광원으로 비추도록 했습니다.

언리얼 엔진 4를 이용한 개발을 돌이켜보면 자주 버전업이 이루어지면서 이걸 따라가기가 어려웠다고 합니다. 엔진 스펙이 바뀐 것도 있고, 여기에 따라 기존 컨텐츠가 작동하지 않는 경우도 있었다네요.

언리얼 엔진 4의 버전업이 이루어지면 미들웨어의 버전업도 이루어져야 합니다. 그러다보니 언리얼 엔진 4의 최신 버전이 나와도 플러그인 업데이트가 있을 때까지 기다리는 경우도 있었다고 합니다.

철권 7이 완성되기 2달 전에도 언리얼 엔진 4.4로 바꿨다고 하며 이때도 많이 고생했다네요. 이러한 노고 끝에 나온 결론은 기능 향상과는 별도로 기능과 스펙은 그대로 두고 버그 수정만 이루어진 안정적인 버전을 원했다고 하는데, 과연 현장에서 나올법한 의견입니다.

또 예상보다 언리얼 엔진 4의 기능에 놀랐던 것은 노드를 이어가면서 프로그래밍을 할 수 있는 언리얼 엔진 4의 비주얼 스크립팅 도구 BluePrint였다고 합니다. 프로그래머가 아니어도 복잡한 처리가 가능하고 성능에서도 부족함이 없었다네요.