주제: 마비노기 모바일의 카메라 시스템 설계도 - 독자적인 컴포넌트 시스템 위에서 다시 구현하는 3D 게임 카메라 시스템 설계
강연자 : 정찬우 - 데브캣 부팀장
발표분야 : 프로그래밍
권장 대상 : 게임 클라이언트 프로그래머(주니어)
관심태그 : #프로그래밍 #카메라 #시스템 설계
[🚨 강연 주제] 이 세션은 유니티의 '시네머신(Cinemachine)'을 사용하지 않고 프로젝트 고유의 자체 컴포넌트 시스템과 세밀한 연출 디렉션에 맞춰 독자적인 카메라 시스템을 구축한 개발기이다. 카메라 시스템을 파라미터, 모디파이어, 비헤이비어, 디렉터 등 역할을 세분화 한 작업 과정과 카메라 셰이크 샘플 보정, 타임라인을 연동한 연출 등 자체적인 카메라 트랜스폼 기반 포스트 이펙트 구현 노하우를 공유한다.
게이머들에게 있어 쾌적한 게임 플레이를 하는데 조작감 만큼 중요한 것이 바로 '카메라(시점)'이다. 카메라가 플레이어가 원하는 시점을 제대로 비추지 못하거나, 특정 장면을 제대로 담아내지 못한다면 몰입감을 저해시킬 수 있다. 마비노기 모바일의 카메라 시스템을 설계한 정찬우 부팀장은 카메라의 중요성을 언급하며, 게임에 최적화 된 카메라를 제공하기 위해 유니티의 '시네머신(Cinemachine)'을 사용하는 대신에 독자적인 카메라 시스템을 설계 했음을 설명했다.
'마비노기 모바일'이 자체 카메라를 가지게 된 계기
정 부팀장은 보통 유니티 프로젝트라면 시네머신을 사용하는 것이 일반적인데 마비노기 모바일은 그렇지 않은 이유로 발표를 시작했다. 그는 마비노기 모바일이 시네머신을 사용하지 않은 이유로 크게 두 가지를 꼽았다. 하나는 마비노기 모바일이 독자적인 자체 컴포넌트 시스템을 사용한다는 것이고, 나머지 하나는 시네머신을 사용하게 되면 엄격한 틀에 맞춰야 하기 때문에 분량과 복잡성이 커진다는 것이다. 마비노기 모바일의 자체 컴포넌트와 시네머신을 연동하려고 들 경우 데이터를 주고받기 위한 복잡한 '브릿지 레이어'가 필요해져 개발 분량과 복잡도가 기하급수적으로 늘어날 위험이 있다고 정 부팀장은 덧붙였다.
그래서 마비노기 모바일 팀은 게임 내에서 카메라라는 것은 한 번 사용되고 끝나는 기능이 아니기 때문에 마비노기 모바일에 어울리는 카메라 시스템을 설계하여 반복 튜닝과 유지 보수를 용이하게 하기로 결정했다.
정 부팀장은 카메라 시스템은 "적당히 알아서 예쁘게"가 아닌 "마지막 수동 조작으로부터 X초 뒤, 어떤 각도로 움직이면 카메라는 어떻게 반응하고 어떻게 멈춰야 한다"는 명확한 의도와 디테일이 요구되고 이러한 이유로 플레이 감각 튜닝과 카메라 통제권을 온전히 가져가기 위해서 자체적인 카메라 시스템을 설계했음을 이야기했다.
자체 카메라 시스템 이렇게 개발됐다.
정 부팀장은 자체 카메라 개발 과정에 있어 '파라미터 분해와 직관성 확보', '모디파이어와 비헤이비어의 설계', '디렉터 시스템의 역할', '빠른 이터레이션을 위한 에디터 개발' 등을 꼽았다.
우선 파라미터 분해와 직관성 확보로 카메라의 최종 위치와 트랜스폼을 날것으로 다루지 않고, 타겟으로부터의 거리, 각도, 오프셋 등 직관적인 변수(CameraRigProperty)로 분해했다. 덕분에 카메라 간의 부드러운 전환(블렌딩) 연산이 훨씬 수월하게 진행됐다.
회전, 지형 충돌 감지, 투샷 등 단일 기능을 처리하는 최소 단위인 모디파이어가 어디서든 재사용할 수 있도록 내부 상태를 일절 가지지 않는 정적 클래스로 강제했으며 특정 상황을 비헤이비어가 모디파이어들을 조합해 구조를 취할 수 있게 했다.
그런 다음 최종 조율자인 디렉터가 현재 게임 상태에 맞춰 우선순위가 가장 높은 카메라를 선택하고, 목표값이 급격히 변하더라도 부드럽게 이어지도록 스무딩 처리를 더해 뚝뚝 끊기는 현상을 방지하도록 설정했다.
그는 "카메라 튜닝은 변수 하나를 바꾸고 느낌을 확인하는 반복 작업의 연속"이라 말하며 개발 과정에서 매번 게임을 재시작하는 낭비를 없애기 위해, 게임 실행 중에도 실시간으로 값이 적용되는 커스텀 에디터를 개발했음도 언급했다. 그 과정에서 에디터 UI에 "몇 초 동안 타겟 Y축 고정"과 같은 기획서의 설명식 문장을 그대로 녹여내어, 기획자와 프로그래머 간의 소통 오류를 줄이고 직관적인 튜닝이 가능케 했다고 이야기했다.
또한 유니티와 마비노기 모바일의 C# 코드간의 근본적인 행렬 규격 차이로 인해 렌더링이 깨지는 난관을 극복한 과정도 설명했다. 내부 연산은 모두 C# 기준으로 통일하고, 최종 엔진 전달 직전에만 유니티 규격으로 변환하는 방식으로 철저히 통제했으며 값의 이상을 추적하기 위해 기즈모(Gizmo)와 그래프를 화면에 직접 띄우는 시각화 디버깅을 적극 도입해 개발 속도를 끌어 올렸음을 팁으로 전했다.
자체 카메라 구현 과정에서 극복한 문제점과 이점
마지막으로 정 부팀장은 자체 카메라 구현 과정에서 극복한 문제점과 이점에 대해서 설명했다.
가장 큰 예시로 프레임 저하를 극복한 카메라 셰이크를 꼽았다. 타격감을 위해 카메라 트랜스폼에 사인 그래프 진동을 더하는 방식을 사용했는데 이때 기기 사양에 따라 프레임이 떨어지면 진동의 고점을 놓쳐 흔들림이 밋밋해지거나 한쪽으로만 쏠리는 현상이 발생했다고 전했다. 그러면서 자체 시스템이기에 샘플링 위치를 강제로 보정하고 진동 방향을 뒤집는 트릭을 로직에 직접 심어, 어떤 환경에서도 묵직하고 일관된 타격감을 보장할 수 있게 설계했다고 설명했다.
클리핑 없는 오프셋 프로젝션을 적용하여 카메라가 억지로 이동하다 땅에 꽂히거나 벽을 뚫는 부작용을 완벽하게 차단했음도 언급했다. 타임라인 연동 이펙트를 통해 기획자가 스킬 타임라인에 직접 수치를 입력하고 편집할 수 있도록 개방하여, 프로그래머의 개입 없이도 다채로운 연출이 쏟아져 나오는 파이프라인을 구축했음도 시사했다.
마지막으로, 결국 이러한 자체적인 카메라 시스템 개발로 스파게티 코드의 위험을 방지하고, 기획자의 의도를 게임 내에 100% 구현해내는 든든한 토대가 되었음을 강조했다. 그는 마비노기 모바일처럼 게임과 카메라가 강하게 얽혀있고 세밀한 조정이 필요하다면, 자체 카메라 시스템 구축은 충분히 투자할 가치가 있는 훌륭한 선택지라 말하며 발표를 마무리했다.
Charliee@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
