여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.
질문이 있으시면 방명록에 글을 남겨주세요.
서문
게임의 방향성과 세부 장르에 따라 어떠한 형태의 스킬을 사용하는가에 따라 시스템의 차이가 있겠지만 전투가 포함된 대부분의 게임은 장르를 불문하고 스킬을 활용한다. 특히 RPG계열 장르에서는 매우 중요하게 여겨지며 코어 시스템(Core System)으로 분류되는 핵심기능이다.
※. 일반적인 RPG에서의 코어 시스템은 스킬(Skill), 아이템(Item), 캐릭터(Actor), 퀘스트(Quest) 시스템을 기반으로 제작된다. 물론 각 시스템의 범주가 매우 넓기 때문에 저 4가지 시스템만으로 게임이 완성되는 것은 아니다.
이렇듯 스킬은 매우 중요한 시스템 중 하나이기 때문에 게임의 방향성과 성격에 따라 다양한 형태로 개발될 수 있다. 그래서 여기서 이야기하는 스킬 시스템이 모든 RPG게임의 표준 정답이 될 수 없다는 점에 대해서 양해 부탁 바란다.
스킬 시스템 관련해서 이 글을 작성하고자 했을 때 어떠한 형태로 설명하는 것이 이상적 일지에 대한 많은 고민이 있었다. 특정 게임을 지목하여 시스템을 역으로 기획하는 형태의 설명이 좋을까? 아니면 개인적으로 어떠한 게임을 만들 것이라는 가정하에 필요한 시스템을 설계하고 이를 설명하는 양식을 따르는 것이 좋을까? 여러 생각과 고민이 있었지만 결론은 개인적으로 실무에서 사용한 경험이 있으며 개발 및 운용에 성공한 시스템을 기반으로 왜?(Why), 무엇을?(How), 어떻게?(What) 스킬 시스템이 만들어졌는지에 대한 설명하고 시스템을 구성하는 개념을 전달하는 것이 언젠가 이 글을 읽는 당신에게 도움이 될 수 있을 것이라는 믿음으로 실제 직접 기획하고 실무에서 활용된 기능을 위주로 설명하고자 한다.
본 문서에서 다루는 스킬 시스템은 일반적인 RPG장르의 게임에서 범용적으로 사용 가능하다고 자부한다. 그리고 만약 당신이 필요하다면 이를 기반으로 담당 프로젝트에 맞는 시스템으로 개선하거나 확장이 필요할 경우 기능을 추가하는 것 만으로 대부분의 시스템 설계를 마무리할 수 있다. 단 나는 당신이 본 문서에서 제안한 형태로 시스템을 따라 만드는 것이 아닌 이를 만들기까지의 생각하는 방식과 시스템화되어 가는 과정 그리고 필요한 것들에 대하여 이해하고 자신만의 시스템을 만들 수 있기를 바란다.
마지막으로 본 문서에서는 철저하게 개인적으로 만들었던 시스템에 대한 부분만을 설명한다. 좋은 스킬을 만드는 방법이나 기획적인 창의적인 아이디어는 논의하지 않는다. 일반화되어 있는 스킬 시스템을 게임에서 제어하기 위한 시스템을 위한 부분을 설명하기 때문에 좋은 기획을 공부하고 싶거나 기획서를 쓰는 법을 공부하고 싶다면 다른 문서나 책을 찾아보는 것을 권한다.
만약 당신이 좋은 기획자 그리고 기획서에 대하여 관심이 많다면 개인적으로 추천하는 책은 아래와 같다.
게임 아키텍처&디자인 - 데이브 모리스, 앤드류 롤링스
게임 기획의 정석 - 타이난 실베스터
나는 왜 이 일을 하는가? - 사이먼 시넥
백곰 심리학 - 우에키 리에
틀리지 않는 법 - 조던 엘렌버그
유시민의 글쓰기 특강 - 유시민
문장 강화 - 이태준
글쓰기의 전략 - 정희모, 이재성
스크럼 - 켄 슈와버, 마이크 비들
스킬 시스템이란?
당신이 만약 내 기준의 일반적인 게이머라면 “일반 공격”과 스킬 공격을 구분할 수 있을 것이다. 물론 이를 구분하지 못한다고 해서 큰 문제가 되지는 않는다. 하지만 게임 기획자를 목표로 한다면 누군가 대화를 할 때 상식적으로 통용되는 부분에 대한 지식은 기본적으로 가지고 있는 것이 좋다.
대부분 “일반 공격(평타)”의 경우 매우 기본적인 공격으로 통용되고 “스킬”의 경우보다 강력하고 화려한 기술로 설명될 수 있다.
<평범한 공격인 일반 공격(좌)과 화려한 연출과 강력한 효과를 가진 스킬(우) 정도로 구분할 수 있다.>
하지만 좋든 싫든 당신이 이 글을 읽고 있다면 시스템 기획자 혹은 시스템 기획에 대한 이해가 필요한 상태일 것이다. 그리고 시스템 기획의 기본은 필요한 것을 “정의(Define)”하는 것으로부터 시작된다.
그렇다면 일반 공격과 스킬의 차이는 무엇이고 이는 어떻게 구분할 수 있을까? 시스템 기획자라면 감성이 아닌 기능으로 이를 정의할 수 있어야 한다. 일단 일반적으로 게임에서 볼 수 있는(확인 가능한) 부분을 비교하여 상호 차이점을 알아보자.
n. 일반 공격과 스킬의 차이 비교
| 분류 | 일반 공격 | 스킬 |
| 애니메이션 | 고유 모션 있음 | 고유 모션 있음 |
| 이펙트 | 이펙트 연출 있음 | 이펙트 연출 있음 |
| 추가 효과 | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
| 사용자 조작 | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
| 레벨(성장) | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
| 피해 범위 | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
| 재사용 시간 | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
| 캐스팅 시간 | 상황에 따라 제공됨 | 상황에 따라 제공됨 |
<확인 가능한 정보를 기준으로 본다면 일반 공격과 스킬은 시스템적으로 동일함을 알 수 있다.>
다소 파편화된 정보이기는 하지만 이를 통해 우리가 추론(Inference)할 수 있는 부분을 정리하자면 일반 공격과 스킬은 기능적으로 차이가 없음을 알 수 있다. 기능적으로 차이는 없지만 우리는 UI 또는 게임에서의 활용 방법의 차이로 인하여 “일반 공격”과 “액티브 스킬”이 분리되어 있다는 차이점은 알 수 있다.
※. 정확하게는 시스템 적으로 일반 공격과 액티브 스킬 분리 여부는 내부 시스템을 확인하지 않는 이상 알 수 없다. 다만 우리가 확인할 수 있는 부분에서 정의(Define)할 수 있는 범주 내에서의 결정이다.
그렇다면 시스템에서 정의하는 스킬이란 무엇일까? 까다롭게 정의하자면 개발된 코드에서 스킬에 정의된 자원을 사용하는 시스템으로 정의할 수 있지만 일반 기획자가 그 정도의 스킬 클래스를 정의할 필요성은 없다. 기획자가 정의를 내리자면 “효과 제공을 통해 대상의 상태(Actor or Object State)를 변경하거나 보유 스탯(Actor or Object Stat)에 영향을 주는 시스템” 정도로 정의할 수 있다.
※. 이는 굉장히 중요한 개념이고 스킬 시스템의 핵심이다. 시스템적 정의는 기능이 게임 내 어떠한 영향력을 행사하고 메커니즘(Mechanism)의 개발 방향과 정체성을 결정하기 때문이다.
스킬 시스템 종류
스킬 시스템을 구성하기 전 프로젝트에 필요한 시스템의 형태가 무엇인지 생각해 볼 필요가 있다. 개인적인 경험으로 스킬 시스템은 단일 데이터와 분할 데이터 형태 둘 중 하나의 형태로 구성된다.
<생소한 내용이지만 기능을 하나의 테이블로 통합하느냐 아니면 분할해서 사용하는지 차이가 있을 뿐이다.>
n. 단일 데이터 방식
-. 스킬을 제어하기 위한 시스템 테이블이 1개이고 모든 기능이 하나의 테이블을 중심으로 설계된다.
-. 스킬의 표현 또는 기능의 차이에 따라 추가 테이블이 필요할 수 있지만 가장 기본이 되는 기능은 스킬 테이블 1개로 관리된다.
-. 단일 데이터 방식의 장점은 스킬 기능을 확인하기 위해 여러 테이블을 고려할 필요가 없다는 점과 하나의 테이블에 다양한 기능이 추가되어 있기 때문에 중복 데이터가 최소화되어 데이터 관리에 편리하다.
-. 단점으로는 스킬 시스템이 1개의 테이블로 통합되어 있기 때문에 개별 스킬에 사용하지 않는 데이터 칼럼 또한 포함되어있어야 하기 때문에 지나치게 테이블 칼럼이 많거나 복잡하게 되어 가독성과 관리에 어려움이 있다.
n. 분할 데이터 방식
-. 각 스킬의 용도에 따라 기능을 분리하고 이를 제어하기 위한 시스템을 별도로 생성한다.
-. 스킬의 기능에 따라 시스템 테이블이 구성되며, 각 기능은 상호 연계하여 참조를 통해 기능을 호출할 수 있다.
-. 분할 데이터 방식의 가장 큰 장점은 각 스킬의 특정 기능에 따라 별도로 개발되기 때문에 병렬 개발이 가능하며 각 필요에 따라 시스템을 조합하여 규칙만 잘 설정되어 있다면 추가 개발 없이 테이블 조합만으로 다양한 스킬을 만들어 낼 수 있다.
-. 분할 데이터 자체가 참조를 통해 상호 시스템을 호출하는 형태이기 때문에 데이터 구조가 다소 복잡하고 전체 시스템에 영향을 주는 추가 요소를 개발할 때 생각하지 못한 부분에서 기능이 제대로 동작하지 않을 수 있다.
각 시스템은 구성에 따라 장점과 단점이 분명하기 때문에 어떠한 형태가 더 좋은 시스템인지는 분명하지 않다. 시스템 설명만 놓고 보면 장기적으로 분할 데이터 방식이 더 유용해 보이지만 개발 비용이 크게 들어가고 시스템의 복잡성이 증가한다. 반대로 단일 데이터 방식은 초기 빠르게 개발이 가능하며, 필요할 경우 추가 개발을 통해 시스템을 확장할 수 있는 장점이 있다.
단일 데이터 방식의 경우 게임의 특징에 영향을 많이 받는다. 개인적으로 이러한 시스템을 사용할 때는 게임 내 스킬이 단순하며, 기능의 조합을 통한 확장이 필요하지 않을 경우 선호된다. 반대로 분할 데이터 방식의 경우 시스템 개발 이전까지 명확한 스킬에 대한 방향성이 정해지지 않거나 향후 다양한 스킬을 추가 개발 없이 생산해야 할 필요성이 있을 때 선호된다. 본 문서에서는 범용적으로 사용 가능한 스킬 시스템을 설명하기 위해 분할 데이터 방식을 기반으로 스킬 시스템 기획에 대하여 설명하고자 한다.
※. 분할과 단일 두 개 모두 스킬 시스템을 구성하는데 특별한 기술적 차이는 거의 없다. 다만 스킬의 기능을 용도에 따라 분리해서 사용하여 필요할 경우 다른 스킬 시스템의 기능을 호출해서 사용해야 할 때 외부 데이터(다른 시스템 테이블) 정보를 참조하는 형태의 차이일 뿐이다. 반대로 단일 데이터 방식의 경우 참조가 필요할 경우 테이블 내부에서 내부 데이터를 참조하는 형태로 구성하면 된다. 이렇듯 단일과 분할은 그냥 데이터 표현 자체의 차이일 뿐이지 기획적으로 크게 다르지 않기 때문에 어떠한 시스템이 더 우월한지 여부를 따질 필요는 없다.
스킬 시스템 개념
일반 적으로 게임 내 스킬은 “단일 효과를 제공”, “상태이상 효과를 제공”, “지정된 위치에 효과를 제공”, “날아가는 형태의 효과를 제공” 정도의 4가지 시스템 형태를 기반으로 조합을 통해 다양한 형태의 스킬로 게임에 표현된다. 이렇듯 패턴화 된 스킬 효과를 기준으로 기능을 분리하면 아래와 같다.
n. 스킬 기능에 따른 시스템 개념
| System Class | Skill System | Description |
| 단일 효과를 제공 | Skill Value Data | 스킬의 기본 정의를 위한 시스템 |
| 상태이상 효과를 제공 | Effect Data | 상태이상 효과를 정의하는 시스템 |
| 지정된 위치에 효과를 제공 | Summon Object Data | 특정 대상을 소환하거나 지정하기 위한 시스템 |
| 날아가는 형태의 효과를 제공 | Projectile Data | 투사체 기능을 제어하기 위한 시스템 |
개념적으로 스킬의 분류는 4가지 시스템으로 분할할 수 있음을 알 수 있다. 그렇다면 실제 분할된 기능은 어떠한 형태로 활용될 수 있을까? 아래는 World of Warcraft 오리지널의 전사 스킬 중 하나인 천둥 벼락 스킬이다.
스킬 정보만으로 여러 가지 기능이 필요함을 유추할 수 있지만 지금은 표시된 단 2개의 기능에 집중하도록 하자 스킬은 주위 적을 강타하여 피해를 입히고 일정 시간 동안 특수한 효과를 공격받은 대상에게 제공한다. 여기서 주변 적에게 즉시 피해를 입힌 기능은 Skill Value Data를 통해 제공하는 단일 효과이다. 그리고 일정 시간 특수한 효과를 제공하는 기능은 상대상의 상태를 변경하는 Effect Data 시스템을 이용하여 표현할 수 있다. 이것을 데이터 테이블 형태로 표현하면 아래와 같은 형태로 시스템을 구성할 수 있음을 예상할 수 있다.
스킬의 직접 효과는 Skill Value Data를 통해 제어되고 해당 스킬 효과가 발동될 때 Effect ID Link에 참조된 Effect ID를 호출하여 정의된 특정 효과를 제공한다. 즉 Skill Value Data의 Value에는 123이라는 값이 등록되고 참조된 Effect ID를 보유한 Effect Data는 30초간 대상의 공격 속도를-10% 감소시키는 효과를 제공한다.
이렇듯 스킬의 용도에 따라 각 기능을 분리하여 필요할 경우 참조(호출)를 통해 시스템 조합이 가능하다면 다양한 형태의 스킬을 만들어 낼 수 있는 장점이 있다.
System State
전체 시스템을 보다 세부적으로 다루기 이전에 우리는 스킬과 그 효과에 대한 부분을 시스템적으로 구분해야 할 필요가 있다. 스킬은 효과를 가지고 있지만 스킬과 효과는 어떻게 분리되는 것일까? 쉽게 이야기하면 스킬의 기능적 부분과 해당 스킬이 제공하는 효과를 시스템 적으로 분리해서 생각해야 한다는 점이다. 일단 스킬이라는 기능 하나만으로 상당히 많은 시스템을 포함해야 한다.
예를 들면 스킬의 재사용 시간(Cool Time), 사거리(Distance), 스킬 이름(Name), 스킬 설명(Description), 메커니즘(Mechanism), 스킬 자원(Memorize Resource)등 스킬을 사용하거나 그 용도에 따라 다양하고 복잡한 시스템이 포함되어 있다. 앞서 분할 시스템 형태로 디자인하기 위해 우리는 스킬이 동작을 위해 필요한 기능과 효과를 분리하는 개념을 이해해야 한다.
※. 스킬의 효과와 기능을 분리하는 부분은 시스템 테이블의 복잡성을 줄이고 1개의 스킬이 다수의 효과를 사용하거나 동일 효과의 중복 데이터를 최소화하기 위함이다.
<하나의 스킬이 동작하기 위해서는 사용자 제약 및 사용 조건을 제어하기 위한 다양한 시스템이 필요하다.>
그리고 이러한 시스템 분할은 시스템 상태(System State)에 따라 필요한 기능별로 시스템 테이블로 설계된다. 시스템기획에서 상태(State) 구성과 구분은 매우 중요하다. 이러한 상태 개념은 시스템 구성에 매우 중요하기 때문에 잘 기억이 나지 않는다면(시스템 기획 개념)을 한 번 더 읽어보기 바란다.
스킬의 상태는 기본적으로 스킬 사용 전과 스킬 사용 후 결과에 대한 두 가지 상태로 구분할 수 있다. 그리고 각 상태에 따라 시스템 동작에 필요한 기능이 다르다. 그리고 이러한 기능을 분리한다면 2개의 시스템 테이블이 필요하다는 것을 알 수 있다.
※. 물론 System State 구성은 이보다 더 복잡하다. 하지만 여기서는 시스템 테이블 구성을 위해 간단하게 개념적인 부분만 짚고 넘어가도록 하자.
<스킬의 사용 전 상태에서 사용하는 시스템과 스킬 사용 후 필요한 시스템으로 구성할 수 있다.>
이렇게 두 개의 시스템 테이블이 필요한 이유를 알게 되었다. 그렇다면 이제 각 시스템의 용도를 정의하고 필요한 시스템 테이블 칼럼(System Table Cloum)을 을 구성해 보도록 하자.
n. 용도에 따른 시스템 테이블 구성
| System Table Name | Description |
| Skill Basic Table | 스킬 구성 및 동작에 필요한 매커니즘과 제약 사항을 설정한다. 모든 스킬은 Skill Basic Table을 통해 생산된다. |
| Skill Operation Table | Skill Basic Table에 등록된 스킬이 동작했을 때 제공해야 하는 결과값을 설정한다. Skill Basic Table의 조건에 따라 발동된 스킬은 Skill Operation 정보를 참조하여 게임 내 스킬 효과를 제공한다. |
스킬 기능에 따른 시스템 개념 항목을 살펴보면 스킬 분리 형태는 총 4개의 시스템이 필요하다고 설명했다. 이 내용과 앞서 설명한 시스템 상태에서 정의된 사항을 종합해 보면 스킬 시스템 구성을 위해 Skill Basic, Skill Operation, Effect Basic, Effect Operation, Summon Object Basic, Summon Object Operation, Projectile Basic, Projectile Operation으로 구성된 총 8개의 시스템 테이블이 필요하다는 것을 예상할 수 있다.
<본 문서에서 다루는 스킬 시스템은 총 8개의 시스템 테이블을 활용한다.>
시스템 테이블의 수량이 다소 많다고 생각할 수 있다. 하지만 본 문서에서는 스킬을 구성할 때 기능별 참조 형태로 다른 시스템을 호출하는 형태를 활용하여 조합을 통해 하나의 스킬을 만들어 낼 수 있도록 하는 것이 그 목적이기 때문에 각 시스템의 독립적인 기능 설정을 위해 위와 같은 형태로 구성되었음을 밝힌다. 물론 당신이 필요하다면 제안된 시스템 테이블의 수량을 줄이고 보다 효율적인 형태로 테이블을 구성할 수 있다.
<전체 시스템은 Operation Table을 통해 각 시스템을 상호 호출할 수 있도록 설정될 수 있다.>
이러한 시스템 형태는 기능별로 분리되어 있는 시스템을 종합하여 하나의 스킬로 사용할 수 있으며, 스킬의 사용 후 효과 발동 이후 각 시스템 상태 조건에 따라 다른 기능을 연속적으로 호출할 수 있기 때문에 기획자의 상상력과 시스템 이해도에 따라 다양한 스킬 표현이 가능하기 때문에 최초 개발 이후 추가 개발에 대한 비용 절감 또한 가능하다.
물론 이러한 시스템은 장점만을 가지고 있는 것은 아니다. 시스템의 참조 형태에 따라 복잡성이 증가하고 각 시스템은 순환 참조를 통해 무한 반복하는 형태의 데이터 오류를 발생시킬 수도 있다. 그리고 아무리 유연한 시스템이라 하더라도 필요할 경우 추가 시스템 개발은 불가피하다. 그럼에도 이러한 시스템을 제안하는 것은 해당 시스템이 완성된 이후 추가 개발에 대한 투입비용 절감 기획자의 역량에 따른 다양한 스킬 조합 등 조금 큰 규모의 게임에서 활용성이 더 뛰어나기 때문이다.
(아무리 큰 프로젝트라 하더라도 라이브 이후 서비스 안정화 단계에 이르면 인력 감축은 불가피하다. 인력 감축 이후 장기적으로 서비스 유지를 위해서는 개발 비용을 최소화해야 하는데 이러한 유연한 시스템은 추가 개발(프로그래머) 없이 다양한 시스템 기능을 활용할 수 있는 기반이 될 수 있다.)