로직을 데이터 모양으로 표현한 간단한 스킬 시스템

더 나은 쿠폰 서비스에 대한 아이디어 기록을 읽고 온라인 MMO 게임에서 스킬, 퀘스트, 업적 등 로직을 데이터 모양으로 만들어 팀에 여러 스탭들이 데이터를 양산할 수 있도록 하는 개발과 비슷하다는 생각을 했습니다. 또 상태에 따른 대미지 계산 파이프라인과 비슷하다는 트윗도 읽었는데 스킬 시스템을 예로 들어 온라인 게임 쪽에서 비슷한 상황을 처리하는 요령을 설명하겠습니다.

이커머스에서 쿠폰이 겪는 문제를 거칠게 요약해 서로 다른 시점에 서로 다른 대상을 근거로 하는 조건 여러 개가 일치할 때 쿠폰이 동작하는 로직을 만들어야 하는데 이를 항상 하드코드로 개발할 때 여러 가지 문제가 생기므로 이를 데이터 모양으로 기술할 수 있도록 간단한 언어로 만들어 쿠폰 요구사항을 발주하는 스탭들이 직접 쿠폰을 디자인할 수 있게 하는 아이디어로 이해했습니다.

온라인 MMO 게임의 스킬 시스템은 게임 안에서 개체들 사이에 일어나는 상호작용 거의 대부분을 기술하는데 사용됩니다. 개발 초기에 플레이어캐릭터와 몬스터 사이에 대미지를 주고 받는 과정을 스킬 데이터구조로 만들어 확장하기 시작하면 나중에는 포션을 마실 때 플레이어가 받는 체력 증가 효과나 1개월 짜리 유료 아이템의 버프 효과 역시 스킬 데이터구조를 사용해 기술하기에 이릅니다.

이 간단한 가상의 스킬 시스템은 대략 ‘스킬’ 데이터구조와 ‘스킬이펙트’ 데이터구조로 구분합니다. ‘스킬’은 게임 상의 누군가(플레이어캐릭터, 몬스터, 소환수 등)가 스킬 사용을 시도할 때 사용 조건과 타겟팅 조건, 그리고 스킬이 발동될 때 사용할 ‘스킬이펙트’로 구성됩니다.

스킬을 사용하려면 먼저 스킬 사용을 시도할 때 조건을 확인해야 합니다. 현재 플레이어가 이 스킬을 소지하고 있는지, 스킬에 걸려 있는 레벨 조건은 일치하는지, 마나는 충분한지, 같은 스킬이나 같은 스킬 계열의 글로벌 쿨타임은 끝났는지, 같은 계열 스킬을 사용할 수 없게 만드는 디버프에 걸려 있지 않은지 등을 확인해야 합니다. 각 단계마다 스킬을 사용할 수 없다면 단계에 해당하는 메시지를 표시하고 스킬 사용을 멈춥니다. ‘마나가 부족합니다.’나 ‘레벨이 부족합니다.’ 같은 메시지가 이 과정에서 표시됩니다.

스킬을 사용할 수 있다면 이어서 스킬을 시전할 대상이 유효한지 확인해야 합니다. 흔히 타겟팅 시스템이라고 부르는데 스킬 시전 대상 역시 여러 단계에 걸쳐 확인해야 합니다. 먼저 스킬 사용 대상이 제대로 타겟팅 되었는지 확인합니다. 타겟은 스킬 메커닉에 따라 플레이어 캐릭터 반경 내, 타겟팅 인터페이스를 통해 가리킨 대상, 타겟팅 인터페이스를 통해 가리킨 바닥 등이 있습니다. 다음으로는 사용 대상이 스킬의 최대 사거리 안에 있는지 확인하고 대상이 아군인지 적군인지 확인합니다. 특히 아군과 적군 구분은 상황에 따라 달라질 수 있어 별도 판별 로직을 통해 스킬 사용 시점 및 피격 시점마다 확인해야 합니다.

스킬 사용 조건과 대상이 모두 유효함을 확인한 다음에는 이들에게 적용할 ‘스킬이펙트’를 실행합니다. 일반적으로 스킬이펙트는 실행될 때 스킬과 달리 독립적으로 조건을 확인하지는 않지만 독립적인 타겟팅 시스템을 포함하고는 있습니다. 가상의 체인 라이트닝 스킬이 있습니다. 플레이어 캐릭터가 마나를 소모해 적에게 전기를 발사하고 여기에 맞은 대상이 주변의 다른 대상에게 2단계에 걸쳐 전기를 전파하는 스킬입니다. 대상은 플레이어 캐릭터의 실린더로부터 20미터 안에 있어야 하고 적군이어야 하며 항상 정확한 대상에게만 사용할 수 있어 대상이 없는 땅바닥에는 사용할 수 없습니다.

스킬을 발사하면 타겟팅 한 첫 번째 대상에게 3초 동안 1초에 한 번 ‘전기 대미지 레벨 3’ 디버프를 주는 ‘감전 1’ 스킬이펙트가 실행됩니다. ‘감전 1’ 스킬이펙트는 이어서 피격자로부터 반경 10미터 안에 있는 적군에게 ‘감전 2’ 스킬이펙트를 부여합니다. ‘감전 2’ 스킬이펙트는 대상에게 ‘전기 대미지 레벨 2’ 디버프를 주고 피격자로부터 반경 5미터 안에 있는 적군에게 ‘감전 3’ 스킬이펙트를 부여합니다. ‘감전 3’ 스킬이펙트는 대상에게 ‘전기 대미지 레벨 1’ 디버프를 주고 끝납니다. ‘전기 대미지 레벨 #’ 디버프는 원거리 전기 대미지 연산 공식에 의해 대미지를 구해 대상의 체력을 감소 시킵니다. 대미지 연산 공식에는 대상의 버프 및 디버프, 스킬 시전자와 피격자 사이의 레벨 차이, 피격자의 장비에 따른 대미지 증감 규칙을 포함하고 있습니다.

사실 이런 상황에서 가장 빨리 스킬을 개발하는 방법은 이 로직 일체를 하드코딩하는 것입니다. 하지만 위에서 설명한 여러 단어 조각들로부터 예상할 수 있듯 체인 라이트닝 스킬은 이와 비슷하면서도 또 조금씩 다른 수많은 다른 스킬 중 하나일 뿐입니다. 가상의 파이어볼 스킬은 체인 라이트닝 스킬과 아주 비슷하지만 ‘화염 계열 대미지’를 주며 피격자가 입은 갑옷은 ‘전기 계열 대미지’를 잘 막아 주지만 ‘화염 계열 대미지’에는 취약할 수 있습니다.

가상의 게임에는 클래스 10개와 각 클래스마다 사용할 수 있는 스킬 30개가 있습니다. 여러 스킬을 개발하기 위해 전투디자인팀의 클래스 담당자가 스킬 로직을 위에서 설명한 형식의 데이터로 기술하는데 팀에 따라 다르지만 요구사항이 크게 변하는 초기 단계에는 스킬 저작도구를 갖추지 못하고 엑셀에 로직을 기입하곤 합니다. 상황에 따라 엑셀에 스킬을 코딩하는 개발 환경은 게임 서비스가 끝날 때까지 유지될 수도 있습니다.

스킬, 스킬이펙트, 버프 및 디버프를 각기 다른 엑셀 파일이나 각기 다른 워크시트에 기술하는데 팀에 따라 한 셀에 전기 대미지 레벨 1의 형식으로 기입하게 하기도 하고 전기 대미지(1)이나 전기 대미지, 1의 형식으로 기입하게 하기도 합니다. 위 체인 라이트닝 사례에서 스킬 하나는 서로 다른 세 가지 스킬이펙트를 차례로 실행하는데 이 때는 각 스킬이펙트를 서로 다른 행에 기입한 다음 각 스킬이펙트 칼럼 중 하나에 '이어서 실행할 스킬이펙트 번호'를 기입해 이들이 연속으로 실행되도록 합니다.

이런 데이터구조는 대략 지난 20여년에 걸쳐 MMO 게임의 스킬, 퀘스트, 업적 등을 표현하는데 일상적으로 사용되며 조금씩 개선 되어 왔습니다. 팀에 따라 스킬, 스킬이펙트, 버프 및 디버프의 연결 관계를 시각화한 도구를 제공하기도 하고 엑셀 형식으로 표현하기 상당히 난해한 구조를 별도의 스크립트로 기술할 수 있도록 하기도 합니다. 다만 시간이 흘러 성능 문제가 생기면 가장 먼저 데이터 모양으로 바뀌는 것이 이 스크립트 모양으로 기술된 로직이어서 엑셀 모양으로 기술된 데이터를 끝까지 유지하는 보수적인 접근을 더 자주 만났습니다.

이런 개발 방법은 오랜 시간에 걸쳐 검증되었지만 개발이 진행됨에 따라 엉망이 되는 상황을 피할 수는 없었습니다. 개발에 참여하는 게임디자이너나 엔지니어가 항상 스킬이펙트와 버프 및 디버프에 사용될 각 컴포넌트를 설계하는데 익숙하지 않았고 또 개발기간은 항상 부족했습니다. 그래서 개발에 관여한 스탭에 따라 각 기능은 더 이상 쪼갤 수 없는 바람직한 형태로 개발되기도 하지만 때에 따라서는 그 시점의 편의에 따라 이미 존재하는 컴포넌트 몇몇의 기능을 포함하거나 이들과 일부 기능이 겹치지만 나머지 기능은 겹치지 않는 미묘한 컴포넌트를 만들어내 엑셀 파일에 복잡한 코멘트를 따라야만 예상대로 동작하는 스킬을 만들어낼 수 있는 상황을 자주 겪습니다. 또 스킬이펙트나 버프 이름이 2014_겨울이벤트_빙결대미지_레벨3 처럼 의도적으로 여러 컴포넌트를 묶은 형태로 개발되기도 합니다.

더 나은 쿠폰 서비스에 대한 아이디어 기록에서도 단점으로 한번 만든 컴포넌트를 삭제할 수 없음을 꼽고 있는데 이렇게 한 번 만들어진 스킬이펙트나 버프 및 디버프는 설계가 잘못되었다고 해서 삭제하고 다시 만들기가 아주 어렵습니다. 아직 개발 중이라 하더라도 게임 내 온갖 장소에서 스킬이펙트가 광범위하게 사용되고 있어 잘못 설계된 컴포넌트를 변경하거나 삭제함에 따라 광범위한 오동작을 일으킬 수 있고 또 이 오동작을 바로잡기 위한 비용이 높습니다. 이런 상황이 반복되다 보면 위에서 예를 든 가상의 체인 라이트닝 스킬에서 사용하는 전기 계열 대미지 디버프와 거의 비슷하지만 조금씩 다른 디버프 수 십 개가 있는 상태로 서비스를 진행하게 되며 세월이 흐름에 따라 부실한 문서화와 계속된 담당 스탭의 변경에 따라 똑같은 역할을 하는 컴포넌트 여러 개가 서로 다른 이름으로 개발되어 있기도 합니다.

이런 단점이 있지만 로직을 데이터 모양으로 표현해 게임디자이너 수준에서 게임 동작을 확장할 수 있게 하고 스킬을 양산해야 하는 상황에 여러 게임디자이너를 투입할 수 있는 장점을 포기할 생각은 없습니다. 때문에 데이터에 로직을 직접 표현하는 입력 방식은 앞으로도 느린 발전을 거치며 계속해서 사용될 거라고 예상합니다.