[🐣질문] FSM형식으로 구현하려는데 의문이 들어요

[익명(220.78)]

FSM이 각 상태에 대해 클래스로 만들어서 상태의 변화, 그리고 그에 따른 행동을 전부 도맡아 시키는 거라 알고있어요.

예를 들어 대기와 걷기라는 상태를 추가하려면 둘 간의 상태 변화 조건을 각 클래스 안에 넣어줘야 해요. 만약 그림과 같은 상태에서 점프라는 상태를 추가하려면 대기와 걷기에서 점프로 이어지는 상태 변화 조건을 또 넣어야 해요.

여기서 의문이 들기 시작합니다.

전 향후에 스킬을 더 만들어서 여기에 추가하려고 하는데, 이대로라면 추가된 스킬 상태에 대한 클래스와 기존에 있는 클래스 간의 상태를 적어야 하는데, 추가될 때마다 적어야 하는 양이 늘어날 거라 생각합니다.

전 FSM을 디커플링하려고 공부했는데, 뇌 속 시뮬레이션을 하면 디커플링은 커녕 점점 서로 엮입니다. 

이게 어쩔 수 없는 건가요? 아니면 다른 좋은 방법이 없을까요?

[sighpie(sighpie)]

난 FSM 몇번 써보다가 거미줄 되는거 보고 답답해서 현재 상태에서 변수 on/off 하고 사용 가능한 쪽에서 판정하는걸로 쓰고 있음 1~10프레임 애니메이션이라 치면 'isSkillUsable', 'isCancelUsable' 같은 틱마다 false로 초기화되는 변수를 만들어서 8~10프레임에 true로 주고 스킬마다 isSkillUsable만 사용 가능 조건으로 할지 isCancelUsable도 사용 가능 조건으로 할지 정하는 방식을 썼음

[익명(220.78)]

[sighpie(sighpie)]

FSM은 트리거가 일일히 표현돼서 점점 복잡해지는듯. 무슨 키를 누르면 어떤 상태로... 이런건 모션이 몇개 없는 게임에서나 될듯함

[연어(smosal)]

https://neulsang-day.tistory.com/30

[연어(smosal)]

이런저런 개념은 여기글이 잘정리되있네

[익명(220.78)]

HFSM은 책에 예시가 적혀있어서 알 것 같은데, BT는 처음보내요. 좋은 정보 감사합니다.

[익명(220.78)]

bt가 결국 저 변환 조건을 root에서 전부 처리하는거죠?

[연어(smosal)]

아님. BT에대해선 댓글로얘기하는거보다 구글링해서 좀 더 공부해보샘. 추천에셋으로는 Behavior Designer - Behavior Trees for Everyone 에셋스토어에 찾으면나오고 유튜브 영상으로 설명도 올라와있음. 메뉴얼읽어봐도 도움될것임. 기본 개념자체는 공유하니

[연어(smosal)]

개인적으론 HFSM~ 이라고 표현한 저런 그룹화된 FSM은 큰의미는 없다고봄. 어차피 저것도 비대해지면 같은문제를 공유하고 기존의 FSM이나 그게그거로 만들어져있던거나 다름없어 보인다 생각함. BT의 경우는 AI같은데서 사용하기 좋다는데 무거워보여서 아무데나 남발하긴 부담스럽게 느끼고있음

[연어(smosal)]

유니티 메카님 에니메이터도 이러한 FSM 구조같은지라 같은 문제점들을 공유함. 크기가 비대해지는만큼 유지보수가 불가능할정도로 얽혀버린 육망성 그리기 미로찾기 하고있게 될것임

[연어(smosal)]

그럼 정답이뭐냐. 하면 모든 케이스에 맞는 완벽한 단하나의 정답은 없다고 봄. 만드려는 기능의 크기 요구사항에따라 일장일단이 있는 선택들의 연속이니까.. 그저 설계를 잘해서 잘써야합니다.. 라고밖엔

[연어(smosal)]

추천할만한 솔루션으론
https://boycoding.tistory.com/262
참고해서 MonsterLove FSM 한번 구경해보셈

[익명(220.78)]