100층짜리 3D 로그라이크를 만들다가 플레이 피드백을 두 개 받았습니다. 그중 하나가 이거였어요.

“몬스터랑 싸울 때 카메라가 흔들려서 멀미가 나요.”

타격감 좋으라고 넣은 화면 흔들림이었는데, 정반대 효과를 내고 있었습니다.

1. 원인은 “장치가 아니라 조합”이었습니다

화면 흔들림 자체는 흔한 기법이고 잘못된 게 아닙니다. 문제는 이 게임의 다른 설계와 조합됐을 때 생겼어요.

카메라 셰이크는 원래 한 방짜리 연출입니다. 큰 타격이 들어갈 때 한 번 흔들리고 잦아들죠. 그런데 이 게임은 자동 발사입니다. 적을 조준하면 알아서 계속 쏘고, 명중도 끊이지 않아요.

그래서 평타가 맞을 때마다 흔들림 값이 조금씩 더해졌고, 잦아들 틈 없이 전투 내내 시점이 진동했습니다. 한 번 흔들리는 건 타격감인데, 계속 흔들리는 건 그냥 멀미입니다.

2. 흔들림을 없애되, 타격감은 남겨야 했습니다

그냥 지우면 때리는 맛이 사라집니다. 그래서 무게를 옮기기로 했어요. 시점을 움직이는 대신, 세계가 반응하게 만들었습니다.

맞은 자리에서 바닥에 충격 파문이 퍼지도록 바꿨습니다. 화면은 미동도 안 하고 지면만 반응해요. 기존에 있던 히트스톱(순간 정지)은 그대로 뒀습니다. 정지는 화면을 움직이지 않으니까요.

3. 부작용인 줄 알았는데 오히려 이득이었습니다

바꾸고 나서 예상 못 한 걸 발견했습니다. 흔들림은 화면 전체라 “어디서 터졌는지” 정보가 없었어요. 반면 파문은 좌표가 있습니다.

그래서 내가 적을 때린 자리와 내가 맞은 자리가 색과 위치로 구분되기 시작했습니다. 정보량이 늘어난 거죠.

이것 때문에 함수 인자도 바꿨습니다. 방향 벡터를 받던 걸 좌표를 받도록요.

4. “정말 카메라가 안 움직이는가”를 어떻게 확인했나

여기가 재밌었던 부분입니다. “느낌상 괜찮은데?“로 끝내고 싶지 않았어요.

개발용 훅을 만들어서 전투 없이도 파문을 한 발 터뜨리고, 렌더된 화면을 PNG로 회수해 픽셀 단위로 비교했습니다. 결과는 이랬어요.

• 파문 프레임의 변화는 플레이어 중심 반경 57~70px에 집중 (대조군은 중앙값 598px = 화면 가장자리)
• 전체 변화 픽셀은 92만 중 1.9천, 즉 0.2%

화면 전체가 흔들렸다면 변화 픽셀이 이 정도일 수가 없습니다. 카메라가 안 움직였다는 증거가 숫자로 나온 거죠.

💡 배운 것 & 주의할 점

• 팁: 연출 기법은 혼자 평가하면 안 됩니다. 셰이크가 나쁜 게 아니라 “자동 발사 + 셰이크”가 나빴어요. 도입할 때 “이 게임에서 이게 얼마나 자주 발동하지?“를 먼저 계산해보세요.
• 주의할 점: 멀미·피로 같은 체감 문제는 결국 사람이 확인해야 합니다. 저는 픽셀 대조로 “카메라가 안 움직인다”까지는 증명했지만, “그래서 멀미가 실제로 가셨는지”는 실제 기기에서 사람이 해봐야 알 수 있는 항목으로 따로 남겨뒀습니다. 자동 검증이 닿는 곳과 안 닿는 곳을 구분해두는 게 중요해요.

정리

버그 신고 한 줄이 결과적으로 코드를 더 좋게 만들었습니다. 흔들림을 지우기만 한 게 아니라, 정보가 더 많은 연출로 바꾼 거니까요.

그리고 “고쳤다”고 말하기 전에 숫자로 확인하는 습관이 생겼습니다. 눈으로 봐서는 미묘한 차이를 놓치기 쉽더라고요.

---

태그: #게임개발, #threejs, #React, #로그라이크, #게임연출, #타격감, #UX, #클로드코드, #자동검증, #인디게임