[로블록스]#16 - 상태(State) 중심 게임 설계

[로블록스]#16 - 상태(State) 중심 게임 설계

Unity에서는 Asset Store에서 에셋을 받아도
“최소한 이상한 짓은 안 하겠지”라는 믿음이 있다.
하지만 로블록스에서는 그 믿음을 버려야 한다.

---

 

 

1. “지금 게임은 어떤 상태인가?”

실전 로블록스 게임에서 가장 중요한 질문은 이것이다.

지금 게임은
어떤 상태(State)에 있는가?

이 질문에 답하지 못하면 모든 시스템은 각자 따로 움직이기 시작한다.

 

 

 

---

2. Unity의 StateMachine vs Roblox

Unity에서는 Animator StateMachine이나 직접 만든 FSM에 익숙하다.

로블록스에서도 개념은 동일하지만, 대상 범위가 다르다.

• Unity: 캐릭터 / 오브젝트 중심
• Roblox: 게임 전체 흐름 중심

즉, 캐릭터가 아니라 서버가 상태를 가진다.

 

 

 

 

---

3. 가장 기본적인 게임 상태 예시

대부분의 로블록스 게임은 아래 상태를 크게 벗어나지 않는다.

WAITING   -- 대기
READY     -- 준비
PLAYING   -- 플레이 중
RESULT    -- 결과 처리
RESET     -- 초기화
    

중요한 건 상태 수가 아니라 명확함이다.

 

 

 

---

4. 상태가 없을 때 벌어지는 일

• 게임 중인데 새 플레이어가 참가
• 결과 화면에서 입력 가능
• 보상이 두 번 지급
• UI와 서버 로직 불일치

이 문제들의 공통점은 단 하나다.

“지금 뭘 해도 되는지”가
정의되어 있지 않다.

 

 

 

---

5. 상태 중심 설계의 기본 규칙

• 모든 행동은 상태에 종속된다
• 상태 전환은 서버만 한다
• 클라이언트는 상태를 따른다
• UI는 상태의 결과다

이 규칙만 지켜도 구조가 놀랍도록 안정된다.

 

 

 

---

6. 서버 상태 관리 예시 구조

GameState = {
    Current = "WAITING",
    TimeLeft = 0
}
    

서버는 단 하나의 상태(State)만 관리한다.

그리고 모든 시스템은 이 값을 기준으로 행동한다.

 

 

 

---

7. UI는 상태를 “보여주기만” 한다

초보 단계에서 가장 많이 하는 실수는 UI가 상태를 결정하게 만드는 것이다.

버튼이 게임을 바꾸는 게 아니라,
상태가 버튼을 바꾼다.

UI는 상태를 표현하는 결과물이다.

 

 

 

---

8. 상태 전환이 명확해지는 순간

상태 중심 설계를 도입하면 이런 질문들이 쉬워진다.

• 지금 입력을 받아도 되는가?
• 보상을 지급해도 되는가?
• 새 플레이어를 받아도 되는가?
• UI를 열어도 되는가?

답은 항상 같다.

“현재 상태가 허용하는가?”

 

 

 

---

9. 개발자가 반드시 버려야 할 생각

• UI 버튼이 흐름을 제어해야 한다
• 각 Script가 알아서 판단하면 된다
• 상태는 귀찮아서 나중에

로블록스에서는 이 생각들이 곧 구조 붕괴로 이어진다.

 

 

 

---

10. 상태(State) 설계 핵심 요약

• 게임은 항상 하나의 상태를 가진다
• 상태는 서버가 관리한다
• 모든 행동은 상태에 종속된다
• UI는 상태의 표현이다
• 상태가 구조를 지킨다

 

 

 

---

11. 다음 글 예고

다음 글에서는 데이터 중심 설계(Data-Driven)를 다룬다.

“하드코딩은 언젠가 반드시 터진다”

---