| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- articulation body
- 티스토리챌린지
- GetComponent
- 유니티 sparkmain(clone)
- 디지털트윈
- 최단거리 알고리즘
- Unity
- dropdown
- list clear
- 크루스칼
- 너비탐색
- removeAll
- 최소신장트리 mst
- sparkmain(clone)
- navisworks api
- raycast
- 오블완
- unity korea
- C#
- 드롭다운
- Simulation
- 습관형성 #직장인자기계발 #오공완
- 깊이탐색
- unity sparkmain(clone)
- 행동트리
- sparkmain(clone) 무한생성
- dfs
- 유니티
- 트리구조
- readonly
- Today
- Total
낑깡의 게임 프로그래밍 도전기
42일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 본문



오늘은 유니티에서의 충돌 판정에 대한 강의를 들었다. 충돌 판정은 단순히 “부딪혔다/안 부딪혔다”를 확인하는 기능이 아니라, 게임에서 물리적인 사실감을 결정짓는 핵심 요소다. 이를 위해 Rigidbody와 Collider의 존재가 필수적인데, Rigidbody는 오브젝트에 물리 연산을 적용해 중력이나 힘에 반응하게 만들고, Collider는 눈에 보이지 않는 경계선을 만들어 충돌 영역을 정의한다. 이 두 가지가 모두 있어야 물리적으로 자연스러운 충돌이 가능하다. 다만, 단순 영역 감지나 트리거 이벤트만 필요하다면 Rigidbody 없이 Collider만 두는 것도 가능하다. 여기에 Constraints(프리즌) 기능을 활용하면 특정 축의 움직임이나 회전을 고정해, 불필요한 물리 변화를 방지할 수 있다. 예를 들어 캐릭터가 기울어지지 않게 Z축 회전을 고정하는 식이다.
흥미로웠던 부분은 충돌이 항상 100% 보장되지 않는다는 점이었다. 유니티의 물리 연산은 프레임 단위로 처리되기 때문에, 프레임이 낮아지면 오브젝트가 한 번의 연산 사이에 너무 멀리 이동해 서로를 ‘통과’해 버릴 수 있다. 특히 속도가 빠른 탄환이나 이동체는 이 문제가 두드러진다. 이런 경우 Rigidbody의 Interpolate 옵션을 활성화하면, 실제 물리 연산은 프레임 단위로 이뤄지더라도 화면에서는 더 부드럽게 보간된 위치로 움직여 충돌 누락을 줄일 수 있다. 그리고 필요하다면 이동 로직을 ‘프레임 단위 이동’이 아니라 ‘물리 업데이트(FixedUpdate) 기반 이동’으로 바꾸어, 프레임이 떨어져도 충돌 계산이 정확하게 동작하도록 보완할 수 있다.
결국 오늘 배운 건, 충돌 판정이 단순한 기능이 아니라 ‘게임의 속도, 프레임, 물리 설정이 서로 맞물린 결과물’이라는 점이었다. 단순히 Rigidbody와 Collider를 넣는 데서 끝나는 게 아니라, 오브젝트 특성에 맞는 물리 옵션과 프레임 대응 전략까지 고민해야 안정적인 충돌 처리가 가능하다는 것을 얻을 수 있었다.


오늘부로 58클립을 들었다.
내일도 파이팅!
'인강 후기' 카테고리의 다른 글
| 44일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 (3) | 2025.08.13 |
|---|---|
| 43일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 (4) | 2025.08.12 |
| 41일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 (9) | 2025.08.10 |
| 40일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 (3) | 2025.08.09 |
| 39일차 : '한 번에 끝내는 유니티&C# 게임 개발 초격차 패키지' 강의 후기 (6) | 2025.08.08 |