Three.js로 만든 야구 sweet spot 판정 시각화

판정 로직보다 먼저 정해야 하는 카메라

Batting Lab을 만들면서 가장 먼저 부딪힌 문제는 알고리즘이 아니라 카메라였습니다. 같은 sweet spot 판정이라도 카메라가 어디에 있느냐에 따라 사용자는 “정타였는데 안 맞았다”거나 “빗맞은 것 같은데 홈런이 나왔다”고 느낍니다. 시각 정보가 손맛을 만듭니다.

실제 야구 중계처럼 측면 카메라를 두면 입체감은 좋지만 임팩트 순간 거리감이 모호해집니다. 반대로 정면 카메라는 거리감은 명확하지만 사용자가 “언제 휘둘러야 하는지”를 읽기 어렵습니다. Wandcade의 Batting Lab은 두 시점을 살짝 절충한 비스듬한 후방 카메라를 기본으로 사용합니다.

sweet spot은 점이 아니라 영역입니다

실제 야구에서 sweet spot은 점이 아니라 짧은 구간입니다. 게임에서도 sweet spot을 한 점으로 설정하면 너무 가혹해서 헛스윙이 반복됩니다. 그래서 Batting Lab은 sweet spot 주변에 약간의 허용 반경을 두고, 그 안에서 거리 비례로 타구 품질을 결정합니다.

시각적으로는 sweet spot이 어디에 있는지 사용자가 알 수 있도록 살짝 강조된 톤을 입혔습니다. 동시에 너무 강조하면 게임이 쉬워 보이기 때문에, 일정 거리 이상 벗어나면 빗맞은 느낌이 명확히 들도록 사운드와 카메라 흔들림을 같이 줄였습니다.

• sweet spot은 점이 아니라 일정 반경의 영역으로 둡니다.
• 거리 비례로 타구 품질이 부드럽게 변하도록 만듭니다.
• 정타·빗맞음·헛스윙의 피드백을 시청각으로 명확히 구분합니다.
• 판정에 영향을 주는 값은 화면에서도 시각적으로 드러나야 합니다.

충돌 검사보다 “지나간 거리”가 더 유용한 이유

처음에는 배트 메시와 공 메시의 실제 충돌 검사를 시도했습니다. 정확하지만 두 가지 문제가 있었습니다. 첫째, 60fps에서도 빠른 공은 충돌을 건너뛸 수 있습니다. 둘째, 실제 충돌이 일어났더라도 사용자가 입력한 타이밍과 미묘하게 어긋날 수 있습니다.

그래서 Batting Lab은 “스윙이 가장 sweet spot에 가까웠던 순간”과 “공이 스트라이크존을 지나간 순간”을 같이 보고, 두 값의 차이로 결과를 결정합니다. 이 방식은 빠른 공도 안정적으로 잡고, 사용자 입력과 결과 사이의 인과 관계가 명확해집니다.

피드백은 점수가 아니라 다음 스윙의 힌트

판정 결과만 숫자로 보여주면 “왜 빗나갔는지” 알기 어렵습니다. Batting Lab의 결과 화면은 배트와 공의 위치 관계, 임팩트 각도, 타구 방향을 같이 보여줍니다. 사용자가 다음 스윙에서 무엇을 바꿔야 하는지 떠올릴 수 있어야 반복 플레이가 의미 있어집니다.

게임은 정확한 채점기가 아니라 학습 장치라는 관점이 도움이 됐습니다. 사용자가 한 번 실패하더라도 “다음에는 어떻게 해보자”는 마음이 들면 자연스럽게 한 번 더 누릅니다.

관련 글