인지 요소(Factor) 확립
추상화된 시스템이 보다 구체화되었다면 필요한 각 인지 요소(Factor)를 확인할 수 있다. 이렇게 정리된 인지요소는 데이터 테이블과 시스템 제어를 위해 필요한 기능으로 활용된다. 하지만 기능에 포함되지 않지만 시스템 구성에 꼭 필요한 추가 인지 요소가 있으며, 본 문서에서는 이를 하위 요소(Sub Element)라 한다.
▶. 하위 요소(Sub Element)
인지 요소로 정리된 구체화된 기능 정보를 제외하고 시스템 구성에 필요한 추가 인지 요소를 말하며 순수 시스템에서 활용하기 위한 항목이다.
※. 인지 요소(Factor)와 하위 요소(Sub Element)로 구분했지만 실제 업무에서 하위 업무 개념은 사용하지 않는다. 이해를 돕기 위해 본 문서에서만 언급되는 개념이다.
캐릭터 시스템을 구성하고 A라는 캐릭터 데이터를 추가했다고 가정해 보자. 여기서 중요한 부분은 코드에서 A라는 캐릭터를 호출하기 위해서는 먼저 A가 어디에 데이터가 등록되어 있는지 알 수 있어야 한다. 이는 현실에서 내가 편지를 보낼 때 봉투에 적는 정보 중 하나는 편지를 받을 사람의 주소인 것과 같이 시스템에서 특정 정보를 찾기 위해서는 해당 데이터의 주소가 필요하다. 그리고 데이터 주소의 역할을 하는 것은 캐릭터의 고유 ID값으로 사용할 수 있다.
※. 현실에서의 주소는 동일 지역 내 중복된 값이 없다. 이것은 주소 자체가 절대적인 고유 정보임을 뜻하며 시스템에서 데이터를 호출하기 위해 주소로 사용되는 ID값 또한 절대적으로 고유 값이라는 것과 같은 원리이다.
이미지와 같이 Actor ID 10000를 기준으로 Actor Data Table의 ID컬럼에 동일한 값을 추적하여 해당 라인에 등록된 캐릭터 정보를 호출할 수 있다. 이러한 시스템 기능에 포함되지 않는 하위 요소를 확립하기 위해서는 데이터적 관점을 통해 시스템이 동작하기 위해 필요한 것들을 인지요소에 포함시키는 연습이 필요하다.
※. 지금은 인지 요소 내 기능으로 분리되지 않는 추가 하위 요소가 있다는 부분만을 이해하면 된다. 데이터의 검색과 테이블은 데이터 테이블 설계 단계에서 다시 이야기하도록 하자.
인지 요소 개념 정리
인지 요소가 정리되었다면 각 요소의 개념과 이를 설명하기 위한 정보를 작성한다. 이는 개발자가 인지 요소에 대한 이해를 돕기 위해 작성되어야 한다. 예를 들면 ‘Attack Power는 캐릭터의 공격력이다.이라 정의했을 경우 공격력이 게임 시스템에서 어떻게 사용되는지에 대한 정보를 포함해야 한다. 가볍게 생각할 수 있는 내용이지만 같은 단어라도 다르게 생각할 수 있기 때문이기도 하며, 개발자에게 이해를 돕기 위해 개념과 역할을 명확하게 정의해 주는 것이 좋다.
■. 캐릭터 기본 스탯 구성
| Factor | Info | Description |
| Attack Power | 캐릭터 공격력 | 캐릭터의 기본 공격력으로 스킬 사용할 때 피해 계산에 사용된다. -. Actor Stat Data Table의 Attack Power는 레벨에 따라 성장한다. |
| Defense Power | 캐릭터 물리 방어력 | 캐릭터의 물리 방어력으로 적 공격에 대한 물리 속성 피해 계산할 때 방어율로 환산되어 사용 -. Actor Stat Data Table의 Defense Power는 레벨에 따라 성장한다. |
| Spell Resistance | 캐릭터 마법 방어력 | 캐릭터 마법 방어력으로 적 공격에 대한 마법 속성 피해 계산할 때 방어율로 환산되어 사용 -. Actor Stat Data Table의 Spell Resistance는 레벨에 따라 성장한다. |
| MaxHP | 캐릭터 최대 체력 | 캐릭터의 보유 가능한 최대 체력으로 Max HP이상 체력을 보유할 수 없다. -. Actor Stat Data Table의 MaxHP는 레벨에 따라 성장한다. |
<캐릭터의 스탯 정보를 설명한 것과 같이 인지요소(Factor)를 정의하고 기능과 역할을 설명할 수 있어야 한다.>
정리된 인지 요소 개념의 각 항목은 차후 데이터 테이블 구성시에 사용되는 Table Column으로 사용된다. 이렇듯 인지 요소와 하위 요소를 잘 정리해서 필요한 데이터를 구성할 수 있고 각 테이블 컬럼(인지 요소)에 어떠한 정보를 입력하고 시스템에서 활용할지 정의할 수 있다.
인지 요소 동작 원리
정리된 인지 요소는 기능과 개념 정리를 통해 자신만의 역할을 부여받는다. 이제 본격적으로 인지 요소가 시스템에서 절차적으로 동작했을 때 어떠한 역할을 수행하는지 정보를 제공한다. 이는 개발자가 시스템을 구현할 때 실질적으로 참고하는 내용이며, 시스템 기획서의 핵심이다. 개념적인 내용으로는 실제 개발 진행이 어렵기 때문에 동작 원리 및 규칙 그리고 예외 사항에 대한 정밀한 원리 설명이 필요하다.
-. 인지 요소 동작 원리와 역할의 설명이 어렵다면 3가지 원칙에 따라 설명해 보자.
-. 동작 원리를 규정하는 것은 시스템 내에서의 규칙을 설정하는 것과 같다. 다만 규칙을 설정할 때는 규칙(Rule)과 정책(Policy)을 구분해야 한다.
※. 예외처리에 대한 개념이 잘 이해되지 않는다면 시스템 예외 처리 항목을 다시 한번 확인하자.
■. 동작 원리 설명
| 분류 | 개념 | Description |
| 왜(Why?) | 기획 의도 | 인지요소를 이용하여 유저 또는 시스템에 어떠한 영향을 주기 위해 개발하는지에 대한 이유를 설명 |
| 무엇을(How?) | 기능에 따른 변화 | 인지 요소가 동작했을 때 게임 내 어떠한 변화가 오는지 설명 |
| 어떻게(What?) | 제어 방법 | 개발된 기능을 어떻게 시스템에서 제어할지를 설명 |
대부분의 인지요소는 이 3가지 전부 또는 1가지 이상을 이용하여 설명할 수 있다. 여기서 한 가지 짚고 넘어가야 할 부분은 기획 의도는 전체 시스템 또는 콘텐츠에 적용되는 것으로 생각할 수 있는데 모든 기획의도는 기획자의 의도에 따라 설계된 모든 항목에 담겨 있어야 한다.
■. 동작 원리 설명 예제(캐릭터 등급)
| 분류 | Description |
| 왜(Why?) | 최대 레벨까지 성장한 캐릭터의 레벨 상한선을 해지할 수 있도록 하여 유저에게는 추가 성장과 재화 수급의 목표를 제공하고 누적 재화 소비를 유도할 수 있도록 한다. -. 랭크 확장에는 동일한 캐릭터가 필요하며, 이를 통해 중복 캐릭터 소비를 유도 -. 최대 레벨 확장으로 추가 성장 재화 파밍 및 소비처를 제공 |
| 무엇을(How?) | 캐릭터가 최대 레벨에 도달했을 경우 랭크를 시켜 최대 레벨 제한을 확장할 수 있다. -. Actor Group ID로 그룹화된 캐릭터 정보의 현재 자신의 캐릭터의 Grade값 +1증가한다. -. 캐릭터의 랭크 정보 표시(별)에 +1증가한다. -. 변경된 Grade값을 참조하여 Actor Max Level이 확장된다. |
| 어떻게(What?) | 캐릭터의 등급을 상승시키기 위해서는 Out Game “랭크 업” 콘텐츠를 이용 -.랭크업 시스템에서 요구하는 재료 및 랭크업 대상 조건을 만족해야 한다. |
등급에 대한 정보는 왜? 무엇을? 어떻게 해서 동작하는지 정의되었다. 그렇다면 캐릭터의 각 등급은 어떻게 제공해야 할까? 그것은 인지 요소 중 하나인 Grade 정보를 시스템에 포함해야 한다.
■. Min Table: Grade
Actor Data Table의 Grade컬럼의 Enum으로 등급캐릭터 등급 설정이 가능하다.
| Table | Column | Type | Value | Key | Description |
| Actor Data |
Grade |
Enum |
0 | None | 보유 등급 정보 없음 |
| 1 | 1 | 1랭크 | |||
| 2 | 2 | 2랭크 | |||
| 3 | 3 | 3랭크 | |||
| 4 | 4 | 4랭크 | |||
| 5 | 5 | 5랭크 |
※. Min Table에 대한 내용은 일단 그냥 참고만 하도록 하자 데이터 설계는 향후 더 자세하게 다룬다.
시스템 예외처리 대상으로는 Min Table: Grade의 Value와 Key항목을 보면 등급에 포함되지 않는 0:None가 있는 것을 확인할 수 있는데 이는 Actor Data를 사용하지만 등급 정보를 가지면 안 되는 대상이 데이터로 등록되어야 할 때 사용되는 특별한 기능이다. 그리고 이것 또한 기능의 동작원리를 설명할 때 언급되어야 한다.
시스템 규칙과 정책
모든 시스템은 정상적인 동작을 위해서는 규칙(Rule)이 필요하다. 그리고 이를 활용하는 내부적인 협의가 정책(Policy)이 필요하다. 시스템을 설계하다 보면 간혹 규칙과 정책의 차이를 혼용해서 사용하는 경우가 있는데 이를 정확하게 구분하여 기획할 수 있도록 해야 데이터 관리에 혼선을 줄일 수 있다.
▶. 규칙(Rule)
시스템이 동작하기 위해 필요한 제약 사항으로 개발이 완료된 이후 변경되거나 규칙 외 방식으로 사용해사용 안 되는 것을 말한다. 규칙을 어겼을 경우 시스템은 동작하지 않는다.
▶. 정책(Policy)
설정된 시스템 규칙 안에서 내부적인 협의를 통해 데이터를 관리하기 위한 협의이다. 시스템을 운영/관리에서 가급적 지켜져야 하는 가이드라인으로 정책을 위반한다고 해서 시스템이 잘못 동작하지는 않는다.
규칙과 정책의 구분은 Actor ID를 이용하여 설명할 수 있다. Actor ID는 데이터에서 고유한 값으로 다른 값과 중복되어 사용될 수 없다. 그리고 Actor ID 10000 ~ 20000 대역은 Player Character이 사용하고 30000 ~ 50000 대역은 Monster에서 사용한다. 여기서 중복될 수 없는 내용은 Actor ID에 대한 규칙이다. 이를 지키지 않았을 경우 시스템은 동작하지 않으며, 변경했을 때 시스템에 많은 영향을 줄 수 있기 때문에 가급적 변경할 수 없다. 반대로 특정 대역은 데이터를 작업할 때 내부적으로 ID중복 이슈를 최소화하고 ID에 따른 Actor 정보를 관리하기 위해 내부적인 ID 사용 정책으로 개발 환경에 따라 언제든지 변경될 수 있다. 규칙은 시스템 기획서에 꼭 포함되어야 하지만 정책은 필수 포함 사항은 아니다.
규칙 설정
시스템에서 사용되는 기능을 한 번에 모두 규칙을 설정하여 설명하게 되면 지나치게 길고 복잡한 내용으로 상대가 이해하기 어려울 수 있다. 필요한 기능별 규칙을 간소화하여 이해하기 쉽도록 짧게 설명하자.
| 스킬 사용 규칙 | 규칙 간소화 |
| 스킬을 사용하려면 재사용 시간이 0인 상태로 활성화 되어있어야 한다. 그리고 대상이 스킬의 사거리 안에 들어있을 경우 스킬 아이콘이 활성화되며 스킬을 사용할 수 있다. 스킬이 사용되면 애니메이션이 동작하며, 연결된 스킬 효과를 제공하며, 스킬 재사용 시간이 동작하여 일정 시간 스킬을 사용할 수 없다. | 스킬 재사용 시간 -. 스킬을 사용하면 Skill Data Table의 CoolTime컬럼에 설정된 시간 동안 스킬을 사용할 수 없다. -. 스킬 재 사용 시간이 동작하면 아이콘은 비 활성화 상태를 유지한다. -. 스킬을 사용 후 애니메이션에 등록된 스킬 Hit Event가 동작하면 스킬 재사용 시간이 동작한다. -. 스킬 재사용 시간 도중 스킬 사용을 시도하면 “지금은 사용할 수 없습니다.”와 같은 시스템 메시지를 출력한다. |
| 스킬 사거리 -. 스킬은 Skill Data Table의 Distance컬럼의 거리 내 지정 가능한 타겟의 체력이 1이상이어야 한다. -. 스킬 사거리에 도달하지 못한 타겟이 설정되어있을 경우 스킬 아이콘이 비활성화 되며 스킬을 사용할 수 없다. -. 스킬을 사용할 수 없는 상태에서 사용을 시도하면 “지금은 사용할 수 없습니다.”와 같은 시스템 메시지를 출력한다. |
|
| 스킬 애니메이션 -. 스킬이 정상적으로 동작했을 경우 Skill Data Table의 Animation컬럼에 등록된 Anim이 동작한다. -. Skill Anim에 등록된 Hit Event 시점에 지정된 스킬 효과가 In Game에 발동된다. -. Hit Event이전에 스킬 사용에 방해를 받을 경우 스킬이 사용이 취소될 수 있다. |
규칙을 설명할 때는 문장으로 한 번에 풀어내거나 가급적 구어(口語)체를 사용하지 않도록 주의하고 문어체 중심중심 사용하는 것이 문서를 읽는 사람이 더 이해하기 쉬우며 기능은 개별로 구현되는 형태가 대부분이기 때문에 기능별 규칙을 설명하는 것이 개발에 더 유리하다. 또한 하나의 기능에 상반되는 플래그형(Flag) 규칙을 사용하지 않는 것을 권장한다.
■. Flag Rule
청기 백기 게임을 기억하는가? 플래그형(Flag) 규칙이란 그 게임과 같이 하나의 좌/우 깃발의 상태에 따라 기능이 변경되는 것을 말한다. 간단한 예를 들어본다면 “스킬 재 사용 시간은 Skill Type이 ActiveSkill(Flage_1)이며 ActiveType이 Player(Flage_2)인 상태에서 스킬이 사용된 World Type이 NormalMap(Flage_3)이어야 동작한다.”라는 규칙을 설정했을 때 실제 스킬 재 사용 시간 시스템이 동작하려면 Flage1 ~ 3번의 모든 조건을 만족해야 동작할 수 있다.
비록 예제가 이해하기 쉽지는 않지만 플래그형 규칙의 가장 큰 문제점은 시스템이 동작하기 위한 규칙이 현재 기획되는 시스템이 아닌 외부 조건에 따라 변경될 때 문제가 발생한다. 이러한 문제는 시스템이 동작하지 않을 경우 원인을 찾기 어렵거나 다른 데이터 변경으로 인하여 기존 시스템에 영향을 줄 수 있기 때문에 가급적 사용사용 않는 것을 권장한다.
※. 플래그형 규칙이 꼭 필요한 경우가 있다. 그러니 무조건 잘못된 시스템이라는 생각보다는 상황에 맞춰 자신이 어떠한 규칙을 설정해야 하는지 잘 생각하고 판단해야 한다.
인지 요소 데이터
인지 요소 확립 및 동작 원리의 정리가 완료되면 시스템에서 활용할 Data Table의 Column정보로 활용되며 각 Table Column에 어떠한 정보가 등록되는지 정의해야 한다.
※. 아직은 데이터 테이블에 대한 정확한 정보가 없기 때문이 이해하기 어려울 수 있다. 다음 단계에서 시스템 데이터 테이블 설계에 대해서 보다 자세하게 알아보자.
게임 시스템 구성을 위한 데이터적 관점 기능의 구체화 인지 요소 확립과 동작 원리에 대한 내용을 담고 있지만 실제 기획 업무는 이 모든 것이 단계적으로 진행되지 않고 동시복합적으로 진행된다. 시스템 기획 방식은 개인 취향, 장르, 개발 환경 등의 다양한 변수가 있으며, 프로젝트 상황에 따라 형식과 내용이 변경될 수 있다. 하지만 표현 용어의 차이는 있으나 대부분의 시스템 기획을 하는 형태와 결과물은 유사하기 때문에 시스템 기획에 필요한 각 요소를 개념을 이해하고 활용할 수 있기를 바란다.
여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.
질문이 있으시면 방명록에 글을 남겨주세요.
'게임 기획 > 시스템 기획 이론' 카테고리의 다른 글
| 10. 게임 시스템 데이터 테이블 만들기 (0) | 2024.01.25 |
|---|---|
| 9. 게임 시스템 기획 데이터 테이블 이론 (1) | 2024.01.23 |
| 7. 게임 시스템 기획 컨셉의 구체화와 기능 분리 (3) | 2024.01.05 |
| 6. 게임 시스템 기획 개념잡기 (4) | 2024.01.05 |
| 5. 게임 시스템 기획 이론 (2) | 2024.01.03 |