[모아이는내려찍고싶다] 2. 짜릿한 손맛 깎기

1편에서는 모아이는내려찍고싶다를 Hook, Simple, Juicy 관점으로 정리했습니다. 한 문장으로 줄이면, 이 게임은 누르는 행동 하나를 심리전과 강한 피드백으로 키우는 게임이었습니다.

그 다음에 제가 가장 오래 붙잡은 것은 코드 구조 자체보다 손맛이었습니다.

원터치 게임은 입력이 적기 때문에, 버튼 하나가 조금만 답답해도 바로 재미가 죽습니다. 반대로 점프 높이, 낙하 속도, 내려찍기 타이밍, 착지 판정이 딱 맞으면 플레이어는 같은 버튼을 계속 누르고 싶어집니다.

그래서 이번 글은 LÖVE 클라이언트에서 짜릿한 손맛을 어떻게 깎았는지에 대한 기록입니다. 내부 캐릭터 컨트롤러에서 이동, 점프, 벽 미끄러짐, 코요테 타임, 점프 버퍼, 내려찍기 상태를 계속 조정하며 플레이 감각을 다듬었습니다.

먼저 움직임을 이루는 값들을 함께 봤다

손맛은 감각이지만, 결국 숫자로 구현됩니다.

캐릭터 움직임에는 여러 값이 얽혀 있습니다. 이 값들은 하나씩 따로 좋은 숫자를 찾는 방식으로 정할 수 없었습니다.

제가 계속 만진 것은 결국 이런 값들이었습니다.

• 이동 속도
• 중력
• 점프 힘
• 벽 점프 힘
• 벽 미끄러짐 속도
• 코요테 타임
• 입력 버퍼
• 회전 시간
• 착지 딜레이

점프 힘이 커지면 내려찍기를 누르고 싶은 타이밍이 달라지고, 중력이 강해지면 피격 판정이 더 갑작스럽게 느껴집니다. 이동 속도와 벽 미끄러짐 속도는 거리 싸움의 리듬을 만들고, 회전 시간과 착지 딜레이는 내려찍기가 얼마나 과감해도 되는지를 정합니다. 입력 버퍼를 넉넉하게 주면 조작은 편해지지만, 너무 넓으면 내가 의도하지 않은 내려찍기가 나가는 것처럼 느껴질 수 있습니다.

그래서 플레이테스트를 하면서 계속 본 것은 숫자 하나가 아니라 누르고 싶은 타이밍이 생기는지였습니다.

버튼 하나에 상태를 여러 개 숨겼다

플레이어가 보는 입력은 하나입니다. 하지만 내부에서는 상태에 따라 전혀 다른 행동으로 갈라집니다.

벽에 붙어 있으면    -> 벽 점프
물속 공중이면       -> 물속 점프
땅 위면             -> 점프
발판을 막 벗어났으면 -> 코요테 점프
공중에서 한 번 더 누르면 -> 내려찍기

이 구조가 중요한 이유는 단순합니다. 플레이어는 "지금 눌렀다"라고 느끼지만, 게임은 그 순간을 점프할 순간인지, 공격할 순간인지, 참아야 하는 순간인지로 해석해야 합니다.

저는 원터치 조작이 얕아 보이지 않게 만들고 싶었습니다. 버튼은 하나지만, 그 버튼을 누르는 위치와 타이밍에 따라 의미가 달라져야 했습니다.

코요테 타임과 점프 버퍼는 친절함이 아니라 납득감이었다

원터치 게임에서 가장 불쾌한 순간은 내가 눌렀는데 게임이 못 알아들은 것처럼 느껴지는 순간입니다.

그래서 코요테 타임과 버퍼를 넣었습니다.

• 코요테 타임: 발판을 막 벗어난 직후의 입력도 점프로 인정합니다.
• 내려찍기 버퍼: 공중에서 조금 일찍 누른 입력을 잠깐 기억했다가 내려찍기로 이어줍니다.

이건 게임을 쉽게 만드는 장치라기보다, 플레이어의 의도를 더 정확하게 받아주는 장치에 가깝습니다. 특히 모바일에서는 손가락이 화면을 가리고, 터치 타이밍도 키보드보다 둔합니다. 그래서 판정을 빡빡하게만 만들면 실력 문제가 아니라 조작 불쾌감이 됩니다.

제가 원한 것은 느슨한 판정이 아니라 납득 가능한 판정이었습니다.

원웨이 플랫폼은 심리전을 만드는 장치였다

모아이는내려찍고싶다에서 원웨이 플랫폼은 단순한 발판이 아니었습니다. 이 게임의 가위바위보를 만드는 핵심 장치였습니다.

높은 곳에 있는 플레이어는 기본적으로 이점을 가집니다. 아래 플레이어를 보고 내려찍을 수 있고, 상대는 위쪽을 의식해야 합니다.

하지만 내려찍기는 항상 정답이 아닙니다.

내려찍기를 시전하면 한 바퀴 회전하는 동안은 무적에 가깝게 들어갈 수 있지만, 빗나가면 착지 딜레이가 생깁니다. 아래 플레이어가 그 심리를 읽고 피하거나, 오히려 점프로 타이밍을 꼬면 위에 있던 플레이어가 불리해질 수 있습니다.

제가 만들고 싶었던 것은 복잡한 커맨드 싸움이 아니라, 점프할까, 내려찍을까, 참을까의 짧은 심리전이었습니다.

디버그 모드 만들기

플레이테스트 중에 꽤 불쾌한 문제가 있었습니다.

원웨이 플랫폼 위에 한 명이 서 있고, 아래에서 다른 플레이어가 점프했을 때 그 점프한 사람이 바로 피격 판정이 되는 문제였습니다.

플레이어 입장에서는 공격을 한 것이 아니라 올라가려는 행동에 가까운데, 결과가 바로 피격으로 나오면 불합리하게 느껴집니다. 이런 순간은 게임의 재미를 깎아먹습니다.

문제는 자동 이동 상태만으로는 이 상황을 안정적으로 재현하기 어렵다는 점이었습니다. 그래서 디버그 메뉴에 Character Control을 만들었습니다.

수동 컨트롤 모드에서는 자동 이동을 끄고, 방향키나 A/D로 두 캐릭터를 원하는 위치에 세울 수 있게 했습니다.

P1: 좌우 방향키 + 위 방향키
P2: A/D + W

이 모드 덕분에 플랫폼 위/아래 상황을 반복해서 만들 수 있었습니다. 자동 플레이 중 우연히 나오기를 기다리는 대신, 문제가 되는 위치를 직접 만들고, 판정이 납득될 때까지 계속 확인했습니다.

손맛을 다듬을 때 제일 위험한 말은 "느낌상 이상하다"입니다. 느낌은 중요하지만, 그것만으로는 고칠 수 없습니다. 그래서 충돌 기즈모도 함께 켰습니다. 디버그 메뉴의 Box 토글은 플레이어 몸통과 공격 sweep hitbox를 화면에 그려줍니다.

단순히 박스가 겹쳤다고 바로 맞는 것이 아니라, 공격자가 이전 프레임이나 현재 프레임에서 피격자보다 위에 있었다고 납득 가능한지를 같이 봤습니다. 내려찍기 판정, 일반 낙하 판정, 이동 중 sweep 판정, 피격 박스 여유를 분리해서 계속 다듬은 이유도 여기에 있습니다.

이 값들은 "맞게 만들기"보다 맞았을 때 납득되게 만들기 위한 값이었습니다.

불쾌감이 없는 판정 만들기

원웨이 플랫폼은 일반 벽처럼 막지 않았습니다. 아래에서 위로 올라갈 때는 통과하고, 위에서 아래로 내려올 때만 착지하게 했습니다.

핵심은 이전 프레임의 발 위치가 플랫폼 위쪽에 있었을 때만 착지로 인정하는 것이었습니다. 그래야 아래에서 점프하는 플레이어가 플랫폼 아래에 걸리지 않고 통과합니다.

이 작업을 하면서 느낀 것은, 게임의 재미를 만드는 과정이 항상 무언가를 더하는 일은 아니라는 점입니다. 오히려 많이 한 일은 깎는 일이었습니다.

• 점프가 너무 낮으면 답답해서 올린다.
• 점프가 너무 높으면 내려찍기 타이밍이 늘어져서 줄인다.
• 내려찍기가 너무 강하면 착지 딜레이를 둔다.
• 판정이 너무 빡빡하면 맞췄다는 감각이 죽는다.
• 판정이 너무 후하면 억울하게 맞는다.
• 원웨이 플랫폼에서 올라오는 플레이어가 바로 맞으면 불합리하다.

저는 충돌 판정이 플레이어에게 의도된 결과처럼 느껴져야 한다고 생각했습니다. 실제 코드는 사각형과 숫자와 조건문이지만, 플레이어가 보는 것은 "내가 왜 맞았는지"입니다.

그 질문에 답하지 못하는 판정은 손맛이 아니라 불쾌감이 됩니다.

다음 문제: 서버 권위 모델에서도 이 손맛을 지킬 수 있을까

여기까지는 클라이언트 안에서 손맛을 깎는 이야기였습니다. 입력을 빠르게 받고, 점프와 내려찍기를 즉시 보여주고, 충돌 기즈모로 판정을 다듬으면 로컬에서는 꽤 짜릿한 감각이 나옵니다.

하지만 멀티플레이에서는 여기서 문제가 생깁니다.

클라이언트가 모든 것을 바로 결정하면 손맛은 좋지만, 두 플레이어의 화면에서 결과가 달라질 수 있습니다. 반대로 서버가 양쪽 플레이어의 위치와 액션을 확정해서 보내주고, 클라이언트가 그걸 그대로 그리기만 하면 공정성은 설명하기 쉬워지지만 한 프레임 늦게 반응하는 듯한 둔함이 생깁니다.

결국 다음 질문은 이것이었습니다.

서버가 판정을 확정하면서도, 클라이언트의 짜릿한 손맛을 얼마나 지킬 수 있을까?

다음 글에서는 이 문제를 WebSocket 기반 서버 권위 모델, 스냅샷, 클라이언트 보정 관점에서 정리합니다.

3편. WebSocket 멀티플레이: 서버 권위 모델과 스냅샷 입력은 클라이언트에서 즉시 보여주고, 판정은 서버에서 확정하기 위해 WebSocket과 스냅샷 보정을 설계한 기록입니다. a4room.com/blog/moai-wanna-slam-devlog-03-websocket-authoritative-server