게임 기획의 공간

게임 기획과 강의 그리고 포트폴리오

게임 기획/시스템 기획 이론

6. 게임 시스템 기획 개념잡기

니코틴휘날리며며 2024. 1. 5. 10:24

시스템 기획 개념

모든 게임 내 시스템은 범용적 개념으로 일종의 상태(State)를 가지고 있다. 이 상태는 조건(Condition)에 따라 다른 상태로 전환될 수 있는데 이 과정에 이벤트(System Event)인풋(Input) 그리고 아웃풋(Output)이 필요하다. 전등과 스위치가 있다고 생각해 보자 스위치는 OnOff 상태를 가질 수 있다. 그리고 스위치의 상태에 따라 전등이 켜지거나 꺼질 수 있다. 이러한 변화를 대상의 상태 변화라고 한다.
. 여기서 주의 깊게 봐야 하는 부분은 전등과 마찬가지로 스위치도 상태가 변화한다는 점이다. 이렇듯 시스템이 동작할 때는 현재 상태에서 다른 상태로 전환되는 것을 기본으로 한다.

 

▶. 상태(State)
모든 시스템은 상태라는 개념을 가지고 있으며, 이 것은 현재 대상이 어떠한 형태로 존재하고 있는지를 정한다. 시스템의 동작에 따라 현재 상태가 다른 상태로 전환되는 개념을 이해할 수 있어야 한다.
-.
상태는 조건(Condition)이 설정되어 있으며, 이를 만족했을 때 지정된 다른 상태로 변경된다.
-.
아래 그림과 같은 전등의 경우 스위치의 ON or OFF 조건에 따라 전등의 상태가 A->B로 전환된다.

<스위치의 조건에 따라 전등의 상태가 변화한다. 그리고 스위치도 조건에 따라 상태가 변화한다.>

 

▶. 이벤트(System Event)
시스템의 상태가 변하기 위해서는 인풋(input) 필요한데 인풋이 발생하는 시점(시간)을 이벤트(System Event) 발생 시간이라고 한다. 이벤트 발생 시점이 되면 조건에 따라 인풋 또는 아웃풋이 동작한다. 그림과 같이 전등 스위치의 상태가 변경되는 시점(시간)이 이벤트 발생 시점이며, 이때 인풋(스위치를 누르는 행위)이 발생한다. 이벤트는 시스템에서 자동으로 발생시키거나 유저 조작을 통해 발생할 수 있다.
 -.
대부분의 이벤트는 인풋이 또는 아웃풋이 발생해야 하는 시점의 시간을 이벤트(System Event)라 한다.
. 전등 스위치가 30초에 한 번씩 상태가 변경된다면 시스템에서 이벤트를 발생시키는 것이며, 사람이 직접 눌러야 한다면 유저 입력을 통해 이벤트가 발생하는 것이다.

<그림과 같이 스위치가 눌리는 시점이 이벤트 발생 시점이 된다.>

 

▶. 인풋(Input)
이벤트 발생 시점에 특정 정보(명령)가 입력되고 이를 통해 지정된 대상의 상태가 변경될 수 있다. 이와 같이 정보가 입력되는 행위를 인풋(Input)이라 한다. 정보는 유저 또는 시스템을 통해 제공받으며, 그림과 같이 스위치의 상태가 변경된다. (스위치를 누르는 행위 = 정보(명령))를 정보 또는 명령이라 한다. 이러한 정보가 입력되는 행위를 인풋이라 한다.
. 인풋 정보(명령)는 스위치의 On 또는 Off 상태를 말하는 것이 아니다. 시스템에서의 인풋은 스위치의 상태가 변경되는 정보(명령)가 실행(입력)되는 상황을 이야기한다. On/Off는 스위치의 상태이며, 이 상태를 변경하는 정보(명령)의 인풋(Input)은 다른 개념이다

<유저 또는 시스템의 명령이 전달되고 On 또는 Off 상태로 전환되는 이때 입력되는 정보가 인풋이다.>

 

▶. 아웃풋(Output)
인풋을 통해 정보가 입력되면 시스템의 상태가 변경된다. 이것을 아웃풋(Output)또는 결과(Result)라고 한다. 모든 시스템은 이벤트 시점에 발생한 인풋 정보를 통해 아웃풋(또는 결과)을 발생시켜야 한다. 전등을 다시 예를 들자면 스위치에 정보가 입력되고 그 결과로 전등이 켜지거나 꺼지는 아웃풋이 발생한다.

<스위치에 들어온 정보(인풋)에 따라 그 결과인 전등이 켜지거나 꺼지는 상태 변화인 아웃풋이 발생한다.>

▶. 조건(Condition)
시스템이 동작하는 기본은 상태(State)를 변경하는 것이다. 상태 변경을 위해서는 필연적으로 조건 규칙이 필요하며 이것은 인풋 또는 아웃풋을 통해 제공받을 수 있다. 시스템은 상태 변경을 위한 조건이 항상 필요하며, 이것을 규칙 또는 시스템 룰 등이라 부른다.
-.
스위치는
[누르면 스위치의 상태가 ON 또는 OFF로 변경]이라는 조건을 가지고 있다.
-.
전등은
[스위치의 상태가 ON일 경우 전등은 켜진다.]라는 조건을 가지고 있다.
-.
전등은 스위치의 상태에 변화를 인풋으로 정보를 제공받고 아웃풋으로 켜지거나 꺼진다.

<스위치는 정보 인풋을 통해 상태 변경 반면 전등은 스위치의 상태를 인풋으로 제공받아 상태가 변경된다.>

 

인풋과 아웃풋 그리고 이벤트와 상태에 대한 개념을 이해할 수 있어야 한다. 모든 시스템은 이러한 조건을 이용하여 동작한다. 또한 이 과정에 다양한 변수를 추가해 게임 테스트에서 오류를 찾아낼 수 있다.

 

시스템 예외 처리

모든 시스템은 정해진 규칙에 따라 동작하며, 이를 절차적 진행이라 한다. 하지만 아쉽게도 모든 시스템이 절차에 따라 사용되거나 동작될 수만은 없다. 시스템이 매우 복잡하거나 다른 시스템과 연계되는 경우 예상하지 못한 이벤트 발생으로 인하여 시스템이 정상적으로 동작하지 않은 경우가 있다. 이런 상황을 규칙에 포함하거나 개발 테스트 단계에서 발생된 문제를 추가로 시스템 규칙에 포함하는 경우가 있는데 이를 예외처리라 한다.

전등을 다시 예를 들어보자면 시스템 이벤트 시점에 인풋으로 스위치의 상태가 On으로 변경되었다. 정상적인 상황이라면 전등이 켜지는 상태로 전환되어야 하는데 전등의 상태가 완전히 전환되기 전에 새로운 인풋 명령으로 인하여 스위치의 상태가 Off로 변경되었을 때 아웃풋의 결과는 어떻게 되어야 할까?

<정상적인 아웃풋(결과)이 발생하기 다른 명령의 난입으로 인해 어떠한 결과를 출력할지 알 수 없다.>

 

절차적 진행에 따라 전등은 이전 명령을 수행하기 위해 켜져야 한다. 하지만 전등의 상태는 스위치의 상태 조건을 따라야 하기 때문에 스위치의 상태가 OFF라면 전등은 꺼져야 한다. 아직 이전 명령에 대한 아웃풋이 처리되지 않아 전등의 상태가 어떻게 되어야 알 수 없다. 이렇게 새로 난입한 명령에 대한 별도 처리가 정의되어 있지 않기 때문에 시스템이 비 정상적으로 동작하거나 최악의 경우 프로그램이 다운될 수 있다. 이러한 상황을 방지하기 위해 시스템 기획을 진행할 때 아래와 같이 별도 예외 처리 사항들을 고려해야 한다.

▶. 전등
-. 불이 켜지거나 꺼질 수 있는 2개의 상태를 가지고 있다.
-.
전등의 상태 변화는 스위치의 조건에 따라 변경된다. (On = True : 전등 켜짐 / Off = False : 전등 꺼짐)
-. 스위치의 상태는 전등의 상태가 완전히 전환되기 전까지 새로운 유저 입력을 받지 않는다.예외처리)

 

▶. 스위치

-. 유저 입력을 통해 On 또는 Off 상태로 전환된다.
-.
유저 입력 1회당 현재 상태에서 다음 상태로 전환되며, 상호 상태가 스위칭된다. 스위치의 상태는 전등의 상태가 완전히 전환되기 전까지 새로운 유저 입력을 받지 않아야 한다.

시스템에서 전등과 스위치를 정의할 때 스위치에 대한 예외 처리 항목을 추가하였기 때문에 동시에 2개 명령어 수행에 대한 문제점을 해결할 수 있다. 이렇듯 시스템 설계 단계에서 규칙의 흐름이 항상 절차적으로 진행되지 않은 상황을 고려할 수 있어야 한다.

. 시스템의 복잡하거나 실시간으로 반응해야 할 경우 다양한 예외처리 사항이 발생한다. 모든 상황을 감안할 수 없겠지만 절차적으로 설계된 시스템 규칙에서 그렇지 않은 상황을 항상 경우의 수로 염두해야 한다.


여러분들의 구독과 공감(♥)은 저에게 큰 힘이 됩니다.

질문이 있으시면 방명록에 글을 남겨주세요.