08. 게임 시스템 설계

게임 시스템 디자인의 이해

게임을 만들 때 시스템 디자인은 매우 중요한 영역이다.
게임의 재미가 단순히 캐릭터 , 스토리 , 그래픽에서만 나오는 것이 아니라 , 플레이어가 어떤 규칙 안에서 행동하고 어떤 결과를 경험하는지에 따라 결정되기 때문이다.

시스템 디자인은 게임의 구조와 규칙을 설계하여 플레이어가 따라야 할 법칙과 개발에 필요한 기준을 정리하는 작업이다.
게임 안에서 무엇이 가능하고 , 어떤 조건에서 어떤 일이 발생하며 , 그 결과가 어떻게 이어지는지를 설계하는 과정이라고 볼 수 있다.

---

시스템 기획

시스템 기획은 게임의 구조와 규칙을 설계하는 일이다.
플레이어 입장에서는 “어떻게 플레이해야 하는가”를 알려주는 기준이 되고 , 개발자 입장에서는 “어떻게 구현해야 하는가”를 판단하는 기준이 된다.

시스템 기획에서는 단순히 기능 목록만 정리하는 것이 아니라 , 다음과 같은 흐름을 함께 고려해야 한다.

 

먼저 기획 의도가 필요하다.
이 시스템을 왜 만드는지 , 어떤 재미를 주기 위한 것인지 설명할 수 있어야 한다.

 

다음은 구현 방식이다.
기능을 어떤 입력과 출력으로 구성할지 , 어떤 조건에서 동작할지 , 어떤 데이터가 필요한지 정리해야 한다.

 

그리고 실제 효과도 중요하다.
이 시스템을 통해 유저가 어떤 재미를 느끼는지 , 어떤 행동을 하게 되는지 생각해야 한다.

 

마지막으로 검증 과정이 필요하다.
기획한 시스템이 실제로 의도한 재미를 만들고 있는지 확인해야 한다.
이를 위해 다른 게임 사례를 참고하거나 , 시뮬레이션 문서를 만들거나 , 프로토타입과 플레이 가능한 버전을 통해 테스트할 수 있다.

---

시스템 디자인에서 다루는 항목

시스템 디자인은 크게 구조 , 규칙 , 시퀸스 , UI 로 나누어 생각할 수 있다.

 

 

 

ⓐ 구조

 

구조는 콘텐츠를 구성하는 시스템의 구성 요소를 의미한다.
각 요소가 어떤 속성을 가지고 있는지 , 어떤 행동을 하는지 , 어떤 상태를 가지는지 , 서로 어떻게 연결되는지를 정리한다.

유저 관점에서는 순환 구조 , 핵심 사이클 , 자원과 보상 구조 등이 구조에 해당한다.
예를 들어 “전투 → 보상 획득 → 성장 → 더 어려운 전투 도전” 같은 흐름은 유저가 경험하는 구조다.

개발 관점에서는 객체 지향 설계, 컴포넌트 구조 , 데이터 테이블 , 리소스 구조 등이 포함될 수 있다.
기획자가 말하는 구조는 플레이 흐름뿐만 아니라 실제 구현 방식과도 연결된다.

 

 

 

ⓑ 규칙

 

규칙은 유저의 행동과 게임 세계의 반응을 정하는 약속이다.
플레이어가 어떤 행동을 했을 때 게임이 어떻게 반응하는지 , 어떤 조건에서 결과가 발생하는지를 정의한다.

유저 관점에서는 규칙이 재미와 감정 , 행동을 유도한다.
예를 들어 공격하면 대미지가 들어가고 , 특정 조건을 만족하면 보상이 지급되는 구조가 여기에 해당한다.

개발 관점에서는 객체의 행동 방식 , 객체 간 메시지 전달 , 상태 전이 , 예외 처리 등이 규칙이 된다.

 

 

 

ⓒ 시퀸스

 

시퀀스는 시간적 흐름에 따라 진행되는 게임의 순서다.
어떤 행동이 먼저 일어나고 , 그다음 어떤 처리가 이어지는지 정리한다.

유저 관점에서는 콘텐츠 사용 순서가 시퀀스가 된다.
예를 들어 퀘스트 수락 → 목표 수행 → 보상 수령 같은 흐름이다.

개발 관점에서는 특정 행동의 실행 순서 , 콘텐츠 실행 시 객체 간 메시지 전송 , 서버와 클라이언트 간 통신 흐름 등이 포함된다.

 

 

 

ⓓ UI

 

UI는 유저와 게임이 상호작용하는 공간이다.
입력과 출력이 이루어지는 부분이며 , 규칙과 구조를 유저가 이해할 수 있도록 보여주는 역할을 한다.

좋은 UI는 단순히 보기 좋은 화면이 아니라 , 시스템의 상태와 결과를 유저가 쉽게 파악할 수 있도록 돕는다.

---

MDA 프레임워크 ( Mechanics , Dynamics , Aesthetics )

게임 메커닉스를 이해할 때 자주 사용되는 개념 중 하나가 MDA 프레임워크이다.

 

Mechanics는 게임을 구성하는 공식적인 규칙과 구조를 의미한다.
예를 들어 전투 규칙 , 이동 방식 , 보상 공식 , 성장 시스템 등이 여기에 포함된다.

 

Dynamics는 플레이 과정에서 유저의 선택과 행동으로 나타나는 실제 흐름이다.
같은 규칙을 가지고 있어도 유저가 어떻게 활용하느냐에 따라 다른 플레이 양상이 만들어질 수 있다.

 

Aesthetics는 유저가 느끼는 감정과 재미다.
긴장감 , 성취감 , 몰입감 , 경쟁심 , 탐험의 즐거움 등이 여기에 해당한다.

 

흥미로운 점은 유저와 개발자가 게임을 바라보는 순서가 다르다는 것이다.

 

유저는 보통 감정과 재미를 먼저 느낀다.
Aesthetics → Dynamics → Mechanics 순서로 경험한다.

 

반면 개발자는 원하는 감정과 재미를 만들기 위해 Mechanics부터 설계한다.
Mechanics → Dynamics → Aesthetics 순서로 기획한다.

 

결국 개발자는 원하는 Dynamics를 유도하기 위해 Mechanics를 설계해야 한다.

---

구조의 이해

게임 시스템의 구조는 크게 기능과 재료로 나누어 볼 수 있다.

 

기능은 게임 안에서 실제로 동작하는 부분이다.
전투 , 이동 , 성장 , 강화 , 상점 , 퀘스트 같은 시스템이 기능에 해당한다.

 

재료는 시스템을 구성하는 콘텐츠다.
이 재료는 다시 데이터와 리소스로 나눌 수 있다.

 

데이터는 수치와 값이다.
예를 들어 몬스터 체력 , 아이템 가격 , 스킬 대미지 , 강화 확률 등이 있다.

 

리소스는 실제 파일 형태의 재료다.
이미지 , 모델링 , 사운드 , 애니메이션 , 이펙트 등이 여기에 해당한다.

 

시스템 기획자는 기능 , 데이터 , 리소스가 어떻게 연결되는지 이해해야 한다.

---

객체 , 매니저 , 이벤트 구조

시스템을 설계할 때는 게임을 구성하는 요소를 더 작은 단위로 분해해서 생각할 수 있다.
그 대표적인 방식이 객체-매니저-이벤트 구조다.

이 구조는 게임 안의 요소들이 어떤 역할을 가지고 , 어떻게 상호작용하며 , 어떤 책임을 나누어 갖는지 이해하는 데 도움이 된다.

 

 

 

객체

 

객체는 데이터와 기능을 가진 개별 단위다.
게임 안에서 콘텐츠화할 수 있는 재료들이 객체가 될 수 있다.

예를 들어 플레이어 캐릭터 , 몬스터 , 아이템 , 스킬 , NPC 등이 객체에 해당한다.

객체는 보통 다음과 같은 요소를 가진다.

• 기능
• 객체의 데이터
• 구성 리소스
• 리소스 구조
• 상태

예를 들어 몬스터 객체라면 체력 , 공격력 , 이동 속도 같은 데이터가 있고 , 공격 행동 , 피격 행동 , 사망 처리 같은 기능이 있다.
또한 모델링 , 애니메이션 , 사운드 , 이펙트 같은 리소스도 연결될 수 있다.

 

 

 

매니저

 

매니저는 객체를 통합하고 관리하는 역할을 한다.
유저 관점에서는 콘텐츠 단위로 나뉠 수 있고 , 개발 관점에서는 특정 시스템을 관리하는 단위가 될 수 있다.

예를 들어 전투 매니저 , 퀘스트 매니저 , 인벤토리 매니저 , 이벤트 매니저 등이 있다.

매니저의 주요 역할은 다음과 같다.

 

1. 객체를 등록하고 삭제한다.
몬스터를 생성하거나 제거하고 아이템을 추가하거나 삭제하는 과정이 여기에 해당한다.

 

2. 상태를 갱신한다.
쿨타임 감소, 체력 회복, 강화 성공 여부 반영처럼 시간이 지나거나 조건이 충족될 때 상태를 바꾼다.

 

3. 조건을 판단한다.
스킬 사용 조건 , 퀘스트 완료 조건 , 강화 확률 체크처럼 특정 행동이 가능한지 확인한다.

 

4. 이벤트를 발생시키고 관리한다.
조건과 반응이 연결된 사건을 처리한다.

 

5. 데이터를 저장하거나 전송한다.
현재 상태를 저장하거나 서버에 데이터를 보내는 일도 매니저의 역할이 될 수 있다.

 

 

 

이벤트

 

이벤트는 조건과 조건에 따른 변화를 연결하는 시스템이다.
어떤 사건이 발생했을 때 그 결과가 연속적으로 이어지는 구조라고 볼 수 있다.

예를 들어 다음과 같은 상황이 이벤트다.

• 플레이어가 몬스터를 처치했다.
• 퀘스트 목표가 갱신되었다.
• 아이템을 획득했다.
• 체력이 0이 되어 사망 처리가 발생했다.
• 강화에 성공해서 장비 능력치가 변경되었다.

이벤트는 객체와 매니저 사이의 흐름을 연결한다.
객체는 속성 , 행동 , 상태를 가지고 있고 , 매니저는 그 상태를 제어하며 , 이벤트는 조건에 따른 변화를 이어준다.

---

규칙의 이해

게임의 규칙은 시스템이 작동하는 기준이다.
규칙이 명확해야 유저도 결과를 예측할 수 있고 , 개발자도 기능을 구현할 수 있다.

규칙을 구성하는 요소는 다음과 같다.

 

첫 번째는 조건이다.
언제 발생하는가를 정의한다.
예를 들어 “체력이 0이 되었을 때” , “퀘스트 아이템을 5개 모았을 때” 같은 조건이다.

 

두 번째는 결과다.
조건이 만족되었을 때 어떤 일이 일어나는지를 정한다.
예를 들어 “사망 처리” , “보상 지급 ”, “다음 퀘스트 개방” 같은 결과가 있다.

 

세 번째는 상태다.
게임 안에서 지속되거나 변화하는 데이터 목록이다.
예를 들어 전투 , 중독 , 버프 , 탈출 , 유지 같은 상태가 있을 수 있다.

 

네 번째는 제약 조건이다.
규칙이 진행되는 데 필요한 제한이다.
예를 들어 하루 1회만 보상을 받을 수 있다거나 , 특정 레벨 이상만 입장할 수 있다는 조건이 여기에 해당한다.

 

다섯 번째는 예외 사항이다.
특정 상황에서 일반 규칙과 다르게 적용되는 규칙이다.
기획서에서는 예외 처리를 반드시 함께 고려해야 한다.

---

좋은 규칙 설계

좋은 규칙은 먼저 명확해야 한다.
유저와 개발자가 같은 방식으로 이해할 수 있어야 하며 , 애매한 표현이 적어야 한다.

 

또한 일관성이 있어야 한다.
같은 조건에서는 같은 결과가 나와야 한다.
규칙이 상황마다 다르게 느껴지면 유저는 시스템을 신뢰하기 어렵다.

 

예측 가능성도 중요하다.
유저는 자신의 행동이 어떤 결과로 이어질지 어느 정도 납득할 수 있어야 한다.
결과를 예측할 수 있어야 전략을 세우고 선택의 재미를 느낄 수 있다.

 

물론 규칙은 재미를 만들어야 한다.
단순히 논리적으로만 맞는 규칙이 아니라 , 플레이어에게 선택과 고민을 제공해야 한다.

 

밸런스도 필요하다.
규칙은 특정 선택만 지나치게 유리하게 만들면 안 된다.
여러 선택지에 나름의 당위성이 있어야 유저가 고민할 수 있다.

 

마지막으로 예외 상황을 고려해야 한다.
실제 게임에서는 기획자가 예상하지 못한 상황이 자주 발생하므로 , 특수 상황에서 어떻게 처리할지 미리 정리하는 것이 좋다.

---

마무리

시스템 디자인은 게임의 구조와 규칙을 설계하는 작업이다.
플레이어가 어떤 행동을 할 수 있고 , 그 행동이 어떤 결과로 이어지며 , 게임이 어떤 방식으로 반응하는지를 정리하는 과정이라고 볼 수 있다.

 

좋은 시스템 기획은 기획 의도 , 구현 방식 , 기대 효과 , 검증 방법이 함께 정리되어야 한다.
또한 객체 , 매니저 , 이벤트 구조를 통해 게임의 구성 요소를 분해하고 , 규칙과 시퀀스를 통해 실제 동작 흐름을 구체화해야 한다.

 

게임의 재미는 단순히 아이디어에서만 나오지 않는다.
그 아이디어가 어떤 구조와 규칙으로 구현되고 , 유저에게 어떤 경험으로 전달되는지에 따라 달라진다.

그래서 시스템 디자이너는 “무엇을 만들 것인가”뿐만 아니라

• “어떤 조건에서 동작하는가”
• “어떤 결과를 만드는가”
• “유저가 어떤 재미를 느끼는가”

까지 함께 고민해야 한다.