캐릭터가 죽고 화면에 사망 애니메이션이 나오는 도중에 성격이 급한 플레이어가 리스폰 버튼을 연타하는 경우가 있습니다. 이때 게임에 따라서 캐릭터가 사망 포즈를 갖추기 전에 살아나는 경우도 있고 그렇지 않은 경우도 있는데요.
이는 우연이 아니라 리스폰 입력을 처리하는 방식의 설계 차이입니다. 이번 글에서 이 2개의 방식을 파이썬 프레임 시뮬레이션을 통해 직접 검토해보겠습니다.
1. 사망 애니메이션도 게임의 일부
인디 게임 개발자 니콜라에 베르베체는 GDC 유럽 2015 강연에서 사망 애니메이션 하나를 완성도 있게 만들기 위해서 에셋, 코드, 사운드, 화면 흔들림, 파티클 효과까지 얼마나 많은 작업이 들어가는 지를 실시간으로 보여주었습니다. 그만큼 해당 애니메이션은 개발자가 애를 써서 만드는 연출인데요.
리스폰 버튼 클릭 한 번으로 이 연출이 중간에 뚝 끊겨버린다면 그 동안의 힘든 작업이 의미가 없게 됩니다. 그렇기 때문에 실제 게임 개발 업계에서는 해당 애니메이션이 재생되는 동안 들어오는 여러가지 입력들을 어떻게 처리할 것인가를 중요한 설계 포인트로 잡고 있습니다.
2. 두 가지 구현 방법
이 문제를 처리하는 방식은 총 두 가지로 나누어 볼 수 있는데요. 하나는 리스폰 버튼을 클릭하는 즉시 현재 애니메이션 재생이 어떻게 이루어지고 있는지와 상관없이 곧바로 리스폰 상태로 바꿔버리는 방식입니다.(아래에서는 이를 네이브 버전이라고 칭합니다.)
구현이 매우 쉽기 때문에 처음 게임을 제작할 때 아무 생각 없이 짜면 대부분 이러한 방식이 됩니다. 또 다른 한 가지는 사망 애니메이션이 재생되는 동안 들어온 리스폰 입력을 즉시 처리하지 아니하고 큐에 담아두었다가 애니메이션이 마지막 프레임에 도착하는 순간에야 캐릭터가 다시 살아나는 구현 방식입니다.(아래에서는 락 버전이라고 칭합니다.) 격투 게임에서 애니메이션 구간 동안 특정 입력을 받아뒀다가 취소 가능한 시점에서 그대로 효력을 발동시키는 입력 버퍼링과 구조가 아주 비슷합니다. 쉽게 요약하자면 다음과 같습니다.
- 버튼을 눌러도 살아나지 않음.
- 버튼을 누르면 살아나짐.
3. 직접 구현 후 비교해보기
이번 포스팅에서는 실제로 프레임 단위에서 이것이 어떻게 다르게 작동하는지 파이썬을 이용해 두 가지 구현 방식을 각각 비교해보았는데요. 60fps 기준 0.5초(30 프레임)짜리 사망 애니메이션을 만들고 다시 살아남 버튼이 1프레임부터 40프레임까지 다양한 시점에 눌러졌다고 가정하고 각 구현 방식에서 실제로 다시 살아나는 시점을 프레임 단위로 측정하고 기록해보았습니다.
네이브 버전에서는 다시 살아남 버튼이 클릭되면 프레임이 곧바로 전환 프레임이 되기 때문에, 입력이 6프레임째에 들어오게 되면 애니메이션은 30프레임 중 6프레임인 20.0%만 재생된 채로 잘려나갔습니다. 입력이 15프레임째에 들어오더라도 전체 애니메이션의 절반인 50%만 보여준 채 캐릭터가 다시 살아나졌습니다.
그러나 락 버전에서는 동일한 조건에서 애니메이션이 항상 30프레임을 전부 재생시킨 뒤에야 캐릭터가 다시 살아나졌고 입력이 비교적 일찍 들어올 수록 그만큼 대기 시간이 길어졌습니다.(6프레임째 입력 시 24프레임을 더 대기한 뒤 살아나짐) 그리고 둘 다 애니메이션이 끝나는 시점인 30프레임 이후에 입력이 들어오면 차이 없이 곧바로 전환이 되었습니다.
4. 뭐가 더 좋은 방식일까?
이 질문에 대한 정답은 게임 장르에 따라, 그리고 게임 개발자의 성향에 따라 다르다고 할 수 있습니다. 빠른 리스폰이 중요한 재미라고 할 수 있는 로그라이트나 아케이드 게임에서는 애니메이션의 완성도보다 즉각적으로 캐릭터가 살아나는 것이 훨씬 더 중요할 수 있기 때문에 네이브 방식이 나쁘지 않은 선택입니다.
하지만, 사망 애니메이션 연출 자체가 긴장감이나 서사의 일부인 게임에서는 락 버전과 같이 애니메이션을 끝까지 보게 하는 것이 플레이어의 만족도를 높이는 데에 유리합니다. 하지만, 락 버전을 쓰되 캐릭터가 다시 살아나기까지의 대기 시간이 너무 길면 “플레이어의 입력이 씹혔다, 즉, 입력되지 않았다.”라고 오해를 받을 수 있기 때문에 버튼 아이콘 깜빡임 같은 짧은 피드백을 주는 경우가 많고 이를 많은 전문가들이 권장하고 있습니다.
5. 현실 조건과의 차이점
제가 이번 글에서 코드로 재현해낸 것은 리스폰과 사망 애니메이션이라는 두 상태만 단순히 다룬 모델입니다. 실제 게임에서는 카메라 워크, UI 페이드아웃, 사망 이펙트처럼 쳇바퀴처럼 동시에 맞물려서 돌아가는 시스템이 더 많고 이들 각각이 입력에 어떻게 반응할 지 설계를 따로 해야 할 필요가 있습니다.
또한 이번 실험에서는 입력을 딱 한 번만 큐에 담는 것으로 단순하게 진행하였는데 실제로는 플레이어가 게임의 리스폰 버튼을 연타하는 상황까지 깊게 생각하여서 중복 입력을 무시하는 처리도 함께 필요하다고 할 수 있습니다.
6. 총정리
캐릭터가 죽는 애니메이션 중에 리스폰 버튼을 누르면 무슨 일이 생기느냐는 결국 게임 개발자가 입력을 어떻게 처리하고 언제 반응할 것인지를 얼마나 자세히 설계했는지의 문제였습니다.
피상적으로 보았을 때는 사소해 보이는 이 처리 하나가 게임의 반응성을 높일 것인지 아니면 애니메이션의 완성도를 지킬 것인지를 결정하는 중요한 요소입니다. 작은 게임을 하나 만들 예정이신 분들이라면 새로운 효과를 추가하기 전에 앞서 것들을 한 번 점검해보는 것이 완성도를 높일 수 있으니 한 번 확인해보실 것을 추천드립니다.