[Unity] Invoke C# Events를 이용한 InputManager만들기 - 1 -

InputManager의 다양한 구현방법 중 Invoke C# Events를 소개하고자 한다.

Send Messages를 이용한 구현은 다음 포스팅을 참고하자.

 

[Unity] New InputManager로 플레이어 이동 구현하기

 

이번 프로젝트에서는 Finite State Machine (유한 상태 머신) 기법으로 플레이어의 움직임을 구현핬다.

 

[Finite State Machine]

finite는 한정된이라는 뜻으로 infinite의 반대라고 생각하면 되겠다.

Finite State Machine(이하 FSM)은 유한한 상태 집합을 가진 시스템을 모델링하는 개념이다. 각 상태는 특정 조건에서 다른 상태로 전환될 수 있다. 상태 전환은 이벤트나 조건에 의해 트리거된다. 특정 문제를 해결하기 위한 방법을 제공하는 개념으로 디자인 패턴으로 간주될 수 있다. 전통적인 디자인 패턴은 객체 지향 설계 원칙에 따라 반복적으로 사용되는 솔루션을 정의하는 반면, FSM은 시스템의 상태와 전이에 중점을 둔 모델링 기법이다.

 

 

<FSM의 구성 요소>

상태 인터페이스(State Interface), 구체 상태 클래스(Concrete State Classes), 컨텍스트(Context)객체

 

 

<FSM의 장점>

 

1. 직관적인 설계

 FSM은 시스템의 상태와 상태 간 전이를 명확하게 정의하여 시스템의 동작을 쉽게 이해하고 설명할 수 있다. 상태 다이어그램 등을 통해 시스템의 상태 전이를 시각화 할 수 있어, 설계와 디버깅이 용이하다.

 

2. 유지보수 용이

 모듈화 - 각 상태와 전이를 독립적으로 관리할 수 있어, 시스템의 일부를 수정할 때 다른 부분에 미치는 영향을 최소화

 확장성 - 새로운 상태나 전이를 추가하는 것이 비교적 쉬움

 

3. 일관된 상태 관리

 상태와 전이가 명확하게 정의되어 있으므로, 시스템의 동작이 예측 가능하고 일관성있다.

 상태 전이가 명확히 정의되어 있어, 문제 발생 시 원인을 쉽게 추적할 수 있음

 

 

<FSM의 단점>

 

1. 복잡성 증가

 상태 수 증가 - 시스템이 복잡해짐에 따라 상태와 전이의 수가 급격히 증가할 수 있어 관리가 어려워진다.

 상태 폭발 - 특히 많은 상태와 전이를 가진 시스템에서는 상태 폭발(State Explosion) 문제가 발생할 수 있다.

 

2. 유연성 제한

 FSM은 사전에 정의된 상태와 전이에 따라 동작하므로 유연한 동작이 필요할 때는 한계가 있을 수 있고, 실시간으로 동적 상태와 전이를 번경해야 하는 경우에는 FSM의 적용이 어려울 수 있다.

 

3. 복잡한 전이 로직

 상태 전이가 복잡해질수록, 각 전이 조건을 관리하고 구현하는 것이 어려울 수 있고, 상태 간의 전이가 많아질수록 상태 간 의존성이 증가하며, 시스템의 유지보수가 어려워질 수 있다.

 

4. 성능 문제

 각 이벤트마다 상태를 검사하고 전이를 처리하는 오버헤드가 발생할 수 있어, 성능에 민감한 시스템에서는 문제가 될 수 있다.

 

 

 

 

기왕 FSM에 대해 공부한 김에 디자인 패턴 중 상태패턴(State Pattern)에 대해서도 알아보자.

[ State Pattern(상태패턴) ]

State Pattern(이하 상태 패턴)은 객체의 행동이 그 상태에 따라 달라지는 경우를 캡슐화하는 디자인 패턴이다.

상태 패턴을 사용하면 객체가 내부 상태(Animator의 Layer)에 따라 다른 방식으로 행동할 수 있도록 설계할 수 있다.

 

 

<상태패턴의 구성 요소>

 

1. Context(컨텍스트): 현재 상태를 나타내는 내부 상태를 가지고 있으며, 상태 전환을 관리한다.

 

2. State(상태): 상태 인터페이스를 정의하며, Context의 상태에 따라 다르게 행동하는 메서드를 선언한다.

 

3. ConcreteState(구체적인 상태): State 인터페이스를 구현하여 각기 다른 상태에서의 행동을 정의한다.

 

 

<장점>

 

1. 상태 변화를 명확히 표현

 상태  변화 로직을 명확하게 분리하여 코드를 이해하기 쉽게 만든다.

 

2. 유지 보수 용이

 새로운 상태를 추가하거나 기존 상태를 수정할 때, Context 클래스의 코드 변경 없이 상태 클래스만 수정하면 되므로 유지 보수가 용이하다.

 

3. 가독성 향상

 상태별로 분리된 클래스로 인해 코드의 가독성이 향상된다.

 

 

<단점>

 

1. 클래스 수 증가

 각 상태마다 별도의 클래스를 만들어야 하므로 클래스의 수가 증가한다.

 

2. 복잡성 증가

 상태가 많아질수록 전체 구조가 복잡해질 수 있다.

 

3. 상태 전환 로직 분산

 상태 전환 로직이 여러 상태 클래스에 분산되어 있어 전반적인 흐름을 이해하기 어려울 수 있다.

 

 

체감상 처음 플레이어가 움직이도록 세팅하기까지 과정이 제일 힘들었다. 계속 Class를 만들고 변수를 타고 타고 들어가서 확인해야 하는 번거로움이 있어 전체적인 밑그림이 그려지기 까지 코드의 이해가 힘들었지만, 그 뒤로 추가 기능들을 구현할 때마다 Ctrl+C,V로 Override하기만 하는 내 모습을 볼 수 있어서 좋았(?)다.

즉, 확장성이 있다는 메리트가 가장 좋았고, 각 상태별로 스크립트를 생성해서 작성하여 스크립트를 관리하기 쉬웠다.

 

State Machine에 대한 자세한 설명은 아래 유니티 공식문서를 참고하자.

 

Unity - Manual: State Machine Transitions

 

여기까지 유한 상태 머신(FSM)과 상태 패턴에 대해 알아보았다.

다음 2편에서는 Input Manager의 C# Events를 FSM으로 구현해보자.