[내일배움캠프 41일차] 상태관리자 State Machine

1. 오늘의 할 일

State Machine 이라는 걸 알아보자.

 

2. 유한 상태 기계(Finite State Machine, FSM)

: 유한한 상태를 조절하는 기계.

게임에서 캐릭터가 가지는 상태는 무한하지 않기 때문에, Finite(유한)한 상태를 조절하는 기계라는 뜻을 가지고 있다.

@: ? 그럼 그냥 State Machine이라고 하면 되지 굳이 Finite를 붙여야 하나?

: 그래서 보통 스크립트에서는 StateMachine이라고 쓰는 것 같긴 하다.

 

아무튼 세상에 절대라는 것은 없고, 혹시 또 무한 상태 기계(Infinite State Machine)이라는 게 존재할지도 모르니까 FSM이라고 그대로 사용하도록 한다.

(그리고 보통 저렇게 나누면, 진짜 존재하기도 하더라.)

 

그래서 FSM의 역할이 뭔데?

상태를 조절해준다. (재차)

그것이 전부이긴 하지만, 조금 더 세세하게 말하자면 상태와 상태 간 전환을 기반으로 동작하는 기반 시스템이라고 하는 게 더 정확하다.

말로 설명하면 좀 복잡하니까, FigJam에서 쓴 걸 그대로 가져왔다.

 

시작! 하면 Idle이 되고, Idle에서 움직이면 Walk나 Run이 된다. 

가만히 있다가 점프하면 Jump 상태가 되고, 올라갔다가 내려올 때는 Fall 상태가 되고.

점프한 상태로 공격하면 Attack 상태가 되고, 공격을 연달아 하면 Combo상태가 되고.

Combo를 하다가 밀려서 떨어지면 Fall이 되고, 바닥에 다시 닿고 달리면 Run상태가 된다.

마치 🏴🏳️🏴🏳️청기백기 청기백기

 

사실 양이 적으면 if-else문이나 Switch case가 더 빠르고 쉽다. 이것들은 굳이 스크립트를 많이 만들 필요도 없고, 그냥 가볍게 휙휙 바꿀 수 있다.

State Machine을 만들면 각 State Base를 만들고 각 State 별로 구조를 짠 스크립트를 만들어야한다.

 

하지만 Switch-case나 조건문은 그럴 필요 없이 바로 코드를 집어 넣으면 그만.

다만 단점은, 너무 늘어나면 case만 화면을 꽉 채울 정도가 될 것이고, 코드가 오염되기 쉽다는 점이다. 더군다나 중간에 로직을 잘못 쓰면, 로직이 돌아가다가 중간에 이상한 방향으로 빠지기도 쉽다.

심지어 길어지면 길어질수록 가독성도 떨어지고, 어떻게 정리해야할지 위치 찾기도 어려워진다. 지금 위에 구조만 해도 case가 7번까지는 나와야한다.

나 혼자 쓰면 그나마 낫지만, 만약 로직을 짜야 하는 사람이 더 많아진다면?

=> 각자 나름대로 신경 써서 지킨다고 해도, 아차하는 순간 망가지기 부지기수이다.

 

그럼 FSM은 뭐가 다른가?

안정성이 좋다.

서로 다른 class에 구현하기 때문에 객체 지향도 되고, 통제 가능한 변인을 이용해서 원하는 아웃풋을 만들어낸다.

나는 저기에 양방향으로 그려놨지만, 한 방향으로만 작성했을 경우에는 반드시 그 흐름을 따라 가기 때문에 설계가 꼬일 일이 없다.

 

처음 빌딩을 완료하면 그 다음부터는 그 기반을 가지고 생성하면 되기 때문에, 각각의 상태가 명확하고, 상태간 전환이 일관되게 관리된다.

복잡한 동작을 상태, 전환 조건으로 나누어 구현하게 되므로 코드 유지보수가 용이하다.

=> 추가도 쉽고, 빼기도 쉽다. 만약 기존에 기본, 걷기, 달리기만 있었다면, Jump에 대한 것만 일부 추가하는 것으로 로직을 구현할 수 있다.

 

그럼 이걸로 뭘 만들 수 있는데?

: Player 혹은 Enemy의 행동 로직, 디버깅할 때 쓰는 사람도 있는 모양이다. (Error가 나면 State를 변경시키는 식으로)

3. 마무리 

 

사실 데이터적인 부분으로 넘어오면 어느정조 자신이 있다....고 생각한다. (개인)

하지만 강의 내용이 꽤 길었고, 이걸 직접 따라가기엔 시간이 제법 오래 걸렸는데.

일단 목표는 Player의 State를 마무리하고 이를 이용해 개인 프로젝트를 만들어내는 것이다.