릴리스 층 멈추기 레일 제작 로그

높이보다 착지 폭이 먼저였다

릴리스 층 멈추기 레일은 좌우로 움직이는 층을 아래 레일 위에 멈추는 게임이다. 처음에는 높이만 보고 싶은 화면이 되기 쉬웠다. 하지만 실제 판단은 높이가 아니라 착지 폭이다. 이번 층을 어디에 놓으면 다음 층이 얼마나 남는지, 잘려 나가는 폭은 얼마나 되는지가 더 중요하다.

그래서 화면에 착지 레일, 남을 폭, 잘림 폭을 더 분명히 넣었다. 초록으로 살아남는 폭과 붉게 잘리는 폭이 같은 계산을 쓰게 하고, 결과 문장도 높이 자랑보다 "착지선을 얼마나 봤는지"를 말하게 했다.

고친 흐름

스태커는 타이밍 게임이라 설명을 길게 붙이면 오히려 약해진다. 화면 위에서 바로 읽혀야 한다. 그래서 텍스트를 늘리는 대신 보이는 선과 색의 역할을 나눴다. 초록은 다음으로 남을 폭, 붉은색은 사라질 폭, 기준선은 착지해야 하는 자리다.

상품 사다리가 아니라 착지 판단으로 둔다

스태커형 게임을 참고하면 쉽게 상품 사다리나 잭팟 느낌으로 간다. 높이 올라갈수록 보상이 커지고, 한 번 더 하면 큰 결과에 가까워지는 구조다. 하지만 이 Play는 그런 방향이 맞지 않았다. bobob.app의 Play는 결제, 계정 성장, 누적 보상 없이 짧게 눌러보고 끝나는 작은 작업장 표면이어야 한다. 그래서 `deploy-stacker`는 높이 자랑보다 착지 판단을 남기는 1분 게임으로 둔다.

이 표는 기능을 줄이기 위한 변명이라기보다, 게임의 성격을 지키는 장치다. 같은 움직이는 블록이라도 보상 사다리를 강조하면 방문자는 계속 올라가야 한다고 느낀다. 반대로 착지선과 잘림 폭을 강조하면 방금 손을 뗀 위치를 복기하게 된다. 지금 필요한 것은 후자다.

제작 로그로 묶은 이유

스태커 관련 짧은 글은 드래그감, 착지 미리보기, 작은 커밋 같은 메모로 나뉘어 있었다. 각각은 작업 기록으로 유효하지만, 공개 목록에서는 흩어져 보인다. 이 Play의 핵심은 "멈추는 순간 무엇을 봐야 하는가"다. 그래서 관련 메모를 이 제작 로그에서 하나의 판단으로 묶는다.

검증할 때는 결과 화면보다 조작 직전 화면을 먼저 본다. 멈추기 전에 남을 폭이 보이는지, 실패했을 때 잘림 폭이 이해되는지, 모바일에서 손가락 입력이 너무 늦게 먹지 않는지를 본다. 높이를 많이 쌓는 것보다 억울하지 않게 실패하는 쪽이 더 중요하다.

보관한 메모에서 남긴 것

처음에는 스태커를 바꿀 때마다 짧은 메모를 따로 남겼다. 하나는 착지 미리보기, 하나는 드래그 조작이었다. 둘 다 실제 수정 기록이지만, 따로 읽으면 "표시 하나를 넣었다" 또는 "손 위치선을 넣었다"로 끝나기 쉽다. 대표 글에서는 그 둘을 아래처럼 같은 판단으로 합쳤다.

이렇게 묶으면 글의 중심도 바뀐다. "기능을 추가했다"가 아니라 "타이밍 게임에서 사용자가 실패를 받아들이려면 무엇을 먼저 봐야 하는가"가 된다. Play를 만든 쪽에서도 다음 수정을 고를 때 더 쓸모가 있다. 새 표시를 붙일지 말지가 아니라, 그 표시가 멈추기 전 판단을 돕는지, 멈춘 뒤 결과와 이어지는지, 모바일 손가림을 줄이는지를 보게 된다.

두 메모를 대표 로그에 합치면서 남긴 기준은 하나다. 사용자가 멈추기 전 본 정보와 멈춘 뒤 받은 결과가 서로 같은 말을 해야 한다. `stacker-landing-preview-note`는 계산을 정리한 메모였다. 초록 남을 폭과 붉은 잘림 폭이 결과 기록과 어긋나면 성공과 실패가 억울해진다. `stacker-drag-align-note`는 입력 감각을 정리한 메모였다. 마우스나 터치로 맞추는 동안 손 위치선이 보이지 않으면 사용자는 "내가 끌어 맞췄는지, 그냥 클릭했는지"를 구분하기 어렵다.

실제로 다시 켜서 보는 순서

이 Play를 확인할 때는 첫 층을 바로 멈추지 않고 몇 번 일부러 늦게 누른다. 잘리는 폭이 붉은 면으로 보이는지, 살아남는 폭이 다음 층의 기준으로 이어지는지 보기 위해서다. 타이밍 게임은 성공했을 때보다 실패했을 때 더 많은 정보를 준다. 실패 장면이 납득되면 사용자는 다시 누를 수 있고, 실패 원인이 보이지 않으면 금방 닫는다.

모바일에서는 손가락이 블록을 가리는 문제가 생긴다. 그래서 결과 문장보다 조작 중 레일을 먼저 확인한다. 터치 영역이 충분한지, 움직이는 층이 손가락 아래에서 사라지지 않는지, 한 번 멈춘 뒤 다음 층으로 넘어가는 속도가 너무 급하지 않은지 본다. 데스크톱에서는 Space 입력과 클릭 입력이 같은 상태를 만드는지도 확인한다.

확인할 때는 성공 판정만 보지 않고 아래 순서로 일부러 흔들어 본다.

• - 첫 층을 중앙에서 조금 빗나가게 멈춰 붉은 잘림 폭이 실제로 보이는지 본다.
• - 두 번째 층에서 남은 폭이 좁아진 상태로 이어지는지 확인한다.
• - 마우스로 끌어 맞춘 뒤 손 위치선과 실제 멈춤 위치가 어긋나지 않는지 본다.
• - 터치에서는 손가락이 현재 층을 가릴 때에도 착지 레일과 안전 폭이 남아 있는지 본다.
• - Space, Enter, 클릭, 드래그가 모두 같은 판정 흐름으로 결과 화면에 기록되는지 본다.

이 검증 순서가 필요한 이유는 스태커가 겉으로는 아주 단순해 보이기 때문이다. 단순한 게임일수록 작은 어긋남이 크게 느껴진다. 화면에서는 살았다고 느꼈는데 결과에서는 끊겼다고 말하면 다시 플레이할 이유가 줄어든다. 반대로 실패했더라도 붉은 폭, 초록 폭, 다음 층 폭이 이어지면 "다음에는 조금 더 안쪽에서 떼야겠다"는 생각이 남는다.

화면에서 통과해야 하는 기준

마지막으로 이 Play를 볼 때는 점수보다 장면의 순서를 본다. 첫 화면, 조작 중, 멈춘 직후, 결과 문장, 관련 링크가 같은 규칙을 말해야 한다. 한 곳이라도 높이 경쟁이나 보상 사다리처럼 보이면 이 게임의 중심이 흔들린다.

이 기준을 적어두면 다음 수정도 덜 흔들린다. 새 효과를 넣기 전에 먼저 묻는다. 이것이 멈추기 전 판단을 돕는가. 멈춘 뒤 결과와 같은 계산을 쓰는가. 모바일에서 손이 가려도 보이는가. 이 세 질문에 답하지 못하면 지금은 넣지 않는 편이 낫다.

대표 글로 남기는 이유

이 글은 단순 업데이트 기록이 아니라 스태커형 Play를 어떻게 읽히게 만들었는지 설명한다. 착지선, 남은 폭, 잘림 폭은 앞으로 비슷한 arcade Play를 만들 때도 반복해서 쓸 판단 기준이다. 그래서 작은 drag 메모를 따로 제출하기보다 이 제작 로그 하나를 대표로 남긴다. 검색으로 들어온 사람이 코드를 보지 않아도 “이 게임은 높이 자랑보다 착지 판단을 보게 만든다”는 방향을 읽을 수 있어야 한다.