숫자 사과 합 10 지우기 제작 로그

짝만 찾으면 너무 금방 식었다

숫자 사과 합 10 지우기는 보드에서 숫자를 이어 훑어 합이 10이면 지우는 게임이다. 처음에는 1+9, 2+8 같은 짧은 짝이 먼저 보였다. 이해는 쉽지만, 이 흐름만 있으면 게임이 금방 계산표처럼 변한다. 내가 원한 것은 "두 숫자 짝찾기"보다 손으로 길을 찾는 느낌이었다.

그래서 여러 번 작게 고쳤다. 보이는 합 10 후보를 넣고, 힌트 사과를 보드 위에 표시하고, 드래그 중 합계와 넘침을 바로 보여주고, 잘못 지나간 칸은 되돌아 쓸 수 있게 했다. 하나씩 보면 작은 변경이지만, 묶어서 보면 같은 목표를 향한다. 손이 멈추지 않게 하고, 실패해도 바로 복구하게 만드는 것이다.

변경 묶음

개별 변경 메모를 전부 Blog 목록에 펼치면 숫자는 많아 보인다. 하지만 처음 읽는 사람에게는 비슷한 짧은 글이 반복된다. 이 제작 로그는 그 메모를 하나의 흐름으로 묶는다. "왜 이 작은 변경들이 필요했는지"가 보이면 짧은 메모 여러 개보다 한 페이지가 더 낫다.

보관 메모를 합친 기준

짧은 메모 10개를 다시 보면 거의 같은 질문을 반복하고 있었다. 이 게임은 더 많은 규칙을 붙이는 일이 아니라, 손이 지나가는 순간마다 화면이 같은 말을 하게 만드는 일이었다. 그래서 대표 로그에는 기능 이름보다 판단 기준을 남긴다.

이 표를 남기는 이유는 짧은 글을 숨기려는 것이 아니다. 각 메모는 실제로 작은 수정의 흔적이지만, 공개 목록에서 모두 같은 무게로 보이면 "비슷한 개발 메모가 열 개"처럼 보인다. 대표 글에서는 이 열 개를 하나의 제작 판단으로 묶는다. 심사나 첫 방문자 관점에서는 수정 횟수보다 한 게임을 어떤 기준으로 다듬었는지가 더 중요하다.

이 기준으로 보면 합 10 게임은 숫자 퍼즐이라기보다 손길을 읽는 게임에 가깝다. 사용자는 모든 조합을 계산하고 싶어서 들어오는 것이 아니다. 눈에 들어온 사과를 훑고, 손을 떼기 전에 성공인지 아닌지 느끼고, 틀렸다면 바로 고쳐서 한 번 더 훑고 싶어 한다. 대표 로그가 이 흐름을 설명해야 짧은 수정 메모를 따로 열지 않아도 된다.

가장 중요했던 판단

카운터판처럼 보이는 요소를 줄인 것이 컸다. 진행 숫자, 선택 배지, 남은 상태를 너무 많이 보여주면 게임이 손으로 훑는 퍼즐이 아니라 관리표처럼 보인다. 그래서 숫자는 필요할 때만 보이고, 보드 위의 드래그 길과 성공 반응을 우선했다.

• - 합계는 드래그 흐름 안에서 바로 보인다.
• - 넘치거나 부족한 상태는 손을 떼기 전에 알려준다.
• - 긴 합 10 묶음은 짧은 짝보다 더 기분 좋게 반응한다.
• - 실패는 기록보다 현재 손길 위에서 먼저 보인다.
• - 1분 동안 이어지는 흐름을 깨는 설명은 줄인다.

이 기준 때문에 결과 화면도 조심했다. 점수보다 먼저 "어떤 식으로 길을 봤는지"가 나와야 한다. 단순히 많이 지웠다는 말보다, 짧은 짝과 긴 묶음을 같이 봤다는 피드백이 더 맞다.

너무 친절한 힌트를 피한 이유

합 10 게임은 작은 차이로 피곤해질 수 있다. 힌트가 너무 강하면 자동 풀이처럼 보이고, 너무 약하면 숫자 찾기 숙제가 된다. 지금은 보드 위에 후보를 보여주되, 직접 드래그하는 손맛을 남기는 쪽으로 맞췄다.

처음부터 모든 합 10 후보를 전부 보여주면 보드는 퍼즐이 아니라 정답 표시판이 된다. 반대로 힌트를 없애면 판이 듬성듬성해진 뒤 손이 멈춘다. 그래서 한 조합만 노란 테두리로 보여주고, 드래그 중에는 내가 고른 경로가 우선 보이게 했다. 힌트는 길을 대신 그려주는 장치가 아니라, 막판에 아직 볼 만한 길이 남았다는 신호여야 했다.

보너스도 같은 기준으로 다뤘다. 긴 묶음과 연속 성공에 작은 반응은 주지만, 큰 팝업이나 별도 규칙 설명은 늘리지 않았다. 사용자가 읽어야 하는 규칙이 많아질수록 1분짜리 게임의 속도는 느려진다. 이 Play에서 필요한 것은 복잡한 성장 시스템이 아니라, 손으로 길을 훑었을 때 그 길이 바로 읽히는 상태다.

검증하면서 본 장면

대표 로그로 남기려면 "재밌어졌다" 같은 말보다 확인 장면이 있어야 한다. 이 Play는 특히 화면 피드백과 결과 기록이 같은 말을 하는지 봐야 했다.

• - 8을 담은 뒤 4를 지나가면 손끝에는 넘침이 보이고, 손을 뗀 뒤 기록도 넘침으로 남는지 본다.
• - 힌트 사과가 떠 있어도 드래그를 시작하면 내가 고른 경로가 먼저 보이는지 본다.
• - 되돌아 쓸기로 마지막 사과를 빼면 합계와 말풍선이 바로 줄어드는지 본다.
• - 세 개 이상으로 10을 만들었을 때 보너스가 손을 떼기 전에 보이는지 본다.
• - 성공한 자리에 짧은 링이 남되, 다음 드래그를 가리지 않는지 본다.
• - 모바일에서 손가락이 사과와 말풍선을 가릴 때도 합계와 상태를 읽을 수 있는지 본다.

이 장면들은 개별 archive 메모를 다시 열지 않아도 대표 로그 하나에서 확인할 수 있어야 한다. 짧은 메모는 작업 순서의 흔적이고, 대표 로그는 사용자가 실제로 보는 장면을 기준으로 다시 묶은 글이다. 그래서 검증도 파일 개수로 보지 않고, 보드 위 피드백, 결과 기록, 모바일 손가락 가림, 힌트 강도 같은 사용 장면으로 본다.

이 확인은 검색 노출만을 위한 일이 아니다. 방문자가 Play를 열었을 때도 같은 차이가 난다. 짧은 글 여러 개가 "고쳤다"를 반복하는 것보다, 대표 로그 하나가 어떤 장면을 보고 왜 고쳤는지 말해주는 편이 훨씬 믿을 만하다.

대표 로그로 남길 만한 이유

이 게임은 단순히 합 10을 찾는 규칙보다 “손으로 길을 훑는다”는 감각이 더 중요하다. 그래서 개별 메모를 각각 공개 목록에 남기면 핵심이 흩어진다. 힌트, 되돌아 쓸기, 성공 흔적은 다른 기능처럼 보여도 모두 같은 질문에 답한다. 사용자가 손을 떼기 전에 판단할 수 있는가.

검증할 때는 쉬운 짝과 긴 경로를 나눠 본다. 쉬운 짝만 계속 보이면 계산표가 되고, 긴 경로만 강요하면 피곤해진다. 둘이 섞여야 1분짜리 퍼즐로 남는다. 이 기준은 앞으로 비슷한 드래그 퍼즐을 만들 때도 다시 쓸 수 있다.

앞으로 더 본다면 새 규칙을 먼저 붙이지는 않을 것이다. 모바일 손가락 경로, 막판 힌트 노출 타이밍, 판이 막혔을 때 새 판으로 넘어가는 박자를 먼저 본다. 숫자 사과 게임은 거대한 시스템이 아니라 작은 반응의 합으로 좋아진다. 그래서 이 대표 로그는 열 개의 짧은 수정 기록을 지우는 대신, 그 수정들이 향한 한 가지 기준을 남기는 쪽에 가깝다.