기본 패턴
text
Idle -> Run -> Jump -> Fall -> Land설명
- FSM은 "지금 이 객체가 어떤 mode에 있는가"를 명확하게 다루는 구조입니다. 플레이어 이동, 적 AI, 메뉴 흐름, 퀘스트 단계처럼 현재 상태에 따라 가능한 입력과 전이가 달라질 때 특히 잘 맞습니다.
- 초보 단계에서는
if와bool몇 개로도 버틸 수 있지만, 상태 수가 늘수록 전이 조건이 흩어지고 "이 상태에서 저 입력이 왜 먹히는지"를 추적하기 어려워집니다. 상태 패턴은 이 복잡성을 객체나 명시적 전이표로 끌어내는 데 의미가 있습니다. - 핵심은 상태 수를 늘리는 것이 아니라, 상태 경계를 분명하게 정의하는 것입니다.
Jump와Fall을 나누는 이유는 이름이 예뻐서가 아니라, 허용 입력과 애니메이션, 판정 규칙이 실제로 다르기 때문입니다. - 반대로 모든 flag를 FSM으로 바꾸면 과합니다. 무기 장착 여부, 버프 존재 여부처럼 동시에 겹쳐 존재하는 정보는 별도 상태 데이터나 태그가 더 자연스러울 수 있습니다.
- 좋은 FSM 카드는 "상태 목록"보다 "전이 조건"과 "상태별 책임"이 먼저 보여야 합니다. 결국 버그는 대부분 상태 정의 자체보다 전이 경계에서 터집니다.
짧은 예제
text
Idle 상태에서는 attack, move 입력 허용
Jump 상태에서는 ground-only action 금지
Land 상태에서는 짧은 recovery 후 Idle 전이빠른 정리
| 항목 | 핵심 포인트 |
|---|---|
| 잘 맞는 문제 | mode가 분명하고 전이 규칙이 있는 시스템 |
| 대표 대상 | 플레이어 상태, 적 AI, UI 흐름, 퀘스트 단계 |
| 설계 핵심 | 상태 이름보다 전이 조건과 책임 경계 |
| 과한 적용 | 겹쳐 존재하는 속성까지 모두 상태로 만들기 |
| 자주 나는 버그 | exit/enter 처리 누락, 잘못된 전이 허용 |
주의할 점
상태 수를 세밀하게 나누는 것보다, "이 상태에서 무엇이 허용되고 무엇이 금지되는가"를 먼저 문장으로 정리하는 편이
훨씬 중요합니다. 정의가 흐리면 FSM도 결국 if 더미가 됩니다.
참고 링크
1 sources