[로블록스]#12 - Part & Physics(물리)

[로블록스]#12 - Part & Physics(물리)

로블록스를 하다 보면 반드시 이런 순간이 온다.
“왜 이 물체는 튀고, 왜 저건 가만히 있지?”
이번 글에서는 로블록스 물리의 핵심, Part / Anchored / Constraint / Network Ownership를 Unity 개발자 관점에서 정리한다.

---

 

 

1. Roblox 물리는 Unity와 철학부터 다르다

Unity의 물리는 엔진 중심이다.

로블록스의 물리는 네트워크 중심이다.

로블록스 물리는
“누가 계산하느냐”가 제일 중요하다.

 

 

 

---

2. Part는 물리의 최소 단위

로블록스에서 물리 연산의 기본 단위는 Part다.

• Position / Size
• Anchored
• CanCollide
• Mass
• AssemblyLinearVelocity

여러 Part를 묶어도 물리는 결국 Part 단위로 계산된다.

 

 

 

---

3. Anchored = “물리 계산에서 제외”

Unity 개발자는 Anchored(고정)를 “IsKinematic(물리 시뮬제외 but 충돌 감지는 가능)” 정도로 생각하기 쉽다.

하지만 로블록스에서 Anchored는 더 강력하다.

Anchored
=
물리 시뮬레이션 완전 제외

• 중력 영향 없음
• 충돌 반응 없음
• 힘 적용 없음

맵, 바닥, 고정 구조물은 무조건 Anchored가 기본이다.

 

 

 

---

4. Weld vs Constraint (이게 진짜 중요)

로블록스에서 Part를 연결하는 방법은 크게 두 가지다.

방식	설명
Weld	완전 고정
Constraint	물리 관계 유지

Unity로 치면:

• Weld = Transform 병합
• Constraint = Joint 계열

 

 

 

 

---

5. Constraint를 써야 하는 이유

Weld는 편하지만 물리적으로 “죽은 구조”다.

움직임이 있는 구조라면 Constraint를 써야 한다.

• HingeConstraint (회전)
• BallSocketConstraint (관절)
• SpringConstraint (탄성)
• AlignPosition / AlignOrientation

“움직여야 하면 Constraint,
안 움직이면 Weld”

 

 

 

---

6. Network Ownership – 튐(갑자기 날아감)의 원흉

로블록스 물리 버그의 80%는 Network Ownership 때문이다.

물리 연산은 서버 또는 특정 클라이언트가 담당한다.

• 서버 소유
  • 보안이 중요한 연산
  • 보스, 중요 퍼즐 등
• 플레이어 소유
  • 반응성이 중요한 연산
  • 차량, 탑승물, 물리 기반 무기 등

캐릭터 근처 물체가 갑자기 튀는 이유는 소유권이 넘어가기 때문이다.

 

 

 

---

7. 안정적인 물리 설계 기본 원칙

• 고정 구조물은 Anchored
• 움직임은 Constraint로 표현
• 불필요한 Unanchored 최소화
• 네트워크 소유권 의식
• Part 개수 줄이기

로블록스 물리는 정교함보다 안정성이 우선이다.

 

 

 

---

8. Unity 개발자가 가장 많이 하는 실수

• 모든 Part를 Unanchored로 둔다(Unity의 static 오브젝트!!!)
• Weld로 움직이는 구조를 만든다
• 물리를 매 프레임 직접 제어한다
• Network Ownership을 무시한다

이 실수들은 “왜 튀는지 모르는 게임”을 만든다.

 

 

 

---

9. Part & Physics 핵심 요약

• Part는 물리의 최소 단위
• Anchored는 물리 제외
• 움직임은 Constraint로
• Network Ownership 의식
• 안정성이 최우선

 

 

 

---

10. 다음 글 예고

다음 글에서는 필수 Services 10선을 다룬다.

“검색하지 말고,
아예 외워라”

---