'시간이 너무 길어서 쉬움' 테스터 의견을 시뮬레이션으로 검증해 퍼즐 목표 시간을 30% 줄였다

같은 플레이 기록에 배율 8개를 대 보았습니다

화살표 매듭풀기의 목표 시간(par)은 화면 위에서 줄어드는 카운트다운이지만, 0이 지나도 판이 끝나지 않습니다. 대신 별 3개는 실수가 화살표 수의 12분의 1 이하이면서 목표 시간 안에 끝냈을 때만 줍니다. 목표 시간을 줄이면 별 3개를 받는 사람이 줄어드는데, 얼마나 줄어드는지는 레벨 구간마다 달랐습니다.

시뮬레이터에는 플레이어가 둘 있습니다. 일반 플레이어는 화살표를 무작위 순서로 하나씩 확인하고(한 개에 120ms), 숙련 플레이어는 방금 탭한 곳에서 가까운 순서로 확인합니다(60ms). 탭에 걸리는 시간은 Fitts 법칙(목표가 멀고 작을수록 오래 걸린다는 식)으로 계산하고, 손가락이 옆 칸을 누르는 오터치와 막힌 화살표를 잘못 누르는 실수도 확률로 넣었습니다. 1~1,100레벨에서 7레벨 간격으로 158개를 골라 레벨마다 일반 30번, 숙련 15번씩 풀게 한 뒤, 그 기록 하나에 배율과 하한 후보만 바꿔 가며 별을 다시 매겼습니다. 배율 후보를 두 묶음으로 나눠 두 번 돌렸고, 각각 5초와 3초쯤 걸렸습니다.

목표 시간은 구간 안 레벨들의 중앙값입니다. 같은 기록에서 일반 플레이어의 중앙값은 41~200레벨 41초, 201~500레벨 93초, 501~1100레벨 188초였고, 숙련 플레이어의 별 3개 비율은 모든 배율에서 67 / 71 / 77%로 같았습니다. 41~200레벨은 0.7에서도 일반 별 3개가 1.0과 같은 50%입니다. 이 구간에서는 목표 시간 안에 든 실행이 88%에서 84%로 줄었는데도 별 3개는 그대로였으니, 목표 시간을 넘긴 실행은 대부분 이미 실수 조건에서 별을 놓친 실행이었습니다.

에이전트는 목표 시간이 '약 2배'라고 보고 45%를 권했습니다

테스터 의견은 11개 항목이었고, 목표 시간은 4번이었습니다. "시간을 더 단축시키기 - 시간이 너무 길어서 쉬움"이라는 말 뒤에 "시간 다되면 처음부터 다시 시작이나 광고보기 팝업"을 띄우자는 제안이 붙어 있었습니다. 운영자가 14시 41분에 이 목록을 붙여 넣자, 에이전트는 2분 뒤 코드를 확인한 결과로 목표 시간이 일반 사용자 중간 풀이시간의 "약 2배", 숙련자의 "약 3.5배"라고 답했습니다. 같은 답에 든 예시는 화살표 22개 판의 목표 54초, 일반 41초, 숙련 24초였습니다. 그 숫자로 계산하면 1.3배와 2.3배입니다.

에이전트는 '약 2배'라는 판단을 근거로 "모든 판의 목표 시간을 약 45% 단축", 곧 목표를 일반 사용자 중간값 수준으로 내리는 안을 권했습니다. 운영자는 14시 54분에 이 안을 골랐습니다. 시간이 다 되면 실패하는 판은 월드마다 1~2개로 한정하는 조건이 함께 붙은 선택지였습니다.

45%를 걸러 낸 것은 몇 분 뒤 에이전트가 작업 카드에 적은 완료 조건이었습니다. 카드에는 "시뮬레이션으로 밴드별 별3 비율 재계산: 숙련 60~75%, 일반 25~40%"가 들어갔고, 에이전트는 코드를 고치기 전에 그 계산부터 돌렸습니다. 0.55에서 501~1100레벨 일반 플레이어는 목표 시간 안에 끝낸 실행도, 별 3개도 1%였습니다. 41~200레벨에서도 목표 40초가 일반 중앙값 41초보다 짧았습니다.

원래 목표 시간은 41~200레벨에서 일반 중앙값의 1.6배(65초 대 41초)였지만 501~1100레벨에서는 1.4배(265초 대 188초)였습니다. 판 하나의 비율로 전체 배율을 정하면 여유가 적은 뒤쪽 구간이 먼저 중앙값 밑으로 내려갑니다. 테스터의 말에서는 방향만 받고, 얼마나 줄일지는 구간별 별 3개 표를 보고 정하십시오.

에이전트는 15시 6분에 다시 물었습니다. 선택지는 30% 단축(권장, 일반 별 3개 30~50%, 숙련 67~77%), 35% 단축(뒤쪽 일반 12~27%), 45% 단축(처음 안, 뒤쪽 일반 1~9%) 셋이었습니다. 0.75와 0.8도 계산했지만 선택지에는 넣지 않았습니다. 운영자는 18시 44분에 30%를 골랐고, 10분 뒤 들어간 커밋은 배율 0.7과 함께 하한도 20초에서 15초로 내렸습니다.

긴 목표 시간은 설계 문서가 정한 값이었습니다

10월 2일 설계 문서(05)는 목표 시간을 넘겨도 실패하지 않고 세 번째 별만 잃게 정했습니다. 근거로는 Candy Crush가 2018년 5월에 시간제 레벨을 모두 제거했다는 팬 위키 요약(원문은 접근이 막혀 읽지 못했다고 문서에 적혀 있습니다)과 Two Dots 도움말의 "Two Dots is not timed!"를 들었고, 기존 포지셔닝인 '편안한 퍼즐'(00 문서)을 따랐습니다.

풀이 시간 모델 문서(06)는 회귀식에 1.42를 곱해서 일반 플레이어가 평균 30%의 시간을 남기도록 한도를 정했습니다. 10월 3일 1,000레벨과 무한 모드 확장(1.1.0)의 확인 게이트(G1)도 "일반 평균 남은 시간 30% 이상"을 요구했습니다. 큰 판에서는 화면이 하나 늘 때마다 더하는 시간 PAR_SCREEN_S가 있는데, 스펙이 준 범위는 2~4초였습니다. 모델에서 화면 하나당 카메라 이동과 화면 밖 확인에 12.4초가 들었고 2~4초로는 남은 시간이 13~22%에 그쳐서, 이 값은 19초로 동결됐습니다(632adb5).

이 19초는 G1 보고서의 "Spec deviations" 절 1번에 이유와 함께 적혀 있습니다. 작업 규칙 문서(09b)에 이런 줄이 있었기 때문입니다. "Never weaken a test to make it pass. If the spec looks wrong, record it under 'Spec deviations' in your final report, with the reason." G1 보고서 판정표에는 파트 3 일반 평균 남은 시간이 30.6%(기준 30% 이상)로 적혀 있습니다.

모델의 상수는 실제 사용자로 맞춘 값이 아닙니다. 06 문서는 탐색 속도와 탭 시간을 시각 탐색과 Fitts 법칙 연구에서 나온 범위로 골랐고, 막힌 화살표를 잘못 누를 확률은 "추정치, 텔레메트리로 보정 필요"라고 적었습니다. 05 문서도 출시 뒤 레벨마다 실수 없이 클리어한 기록의 70번째 백분위(P70)로 목표 시간을 바꾸자고 했지만, 10월 4일에는 그 데이터가 없었습니다.

시간 초과 실패는 본편에 넣지 않고 보스 타임어택으로 보냈습니다

테스터 제안의 뒤쪽 절반, 시간이 다 되면 처음부터 하거나 광고를 보게 하자는 부분은 그대로 받지 않았습니다. 14시 44분 질문의 두 번째 선택지가 바로 그 안("월드 2부터 전 판 실패", 31레벨부터)이었고, 에이전트는 보상형 광고 노출은 늘지만 차분하게 푸는 사용자가 떠날 위험이 있다고 설명을 붙였습니다. 그날 작업 카드에는 장르 상위 앱 두 개가 스토어 문구에 "타이머 없음"을 내세우고, 하드 타이머와 광고 +60초를 쓰는 앱은 하나였다는 조사 결과도 적혔습니다.

진짜 제한 시간은 그날 밤 미니게임으로 들어갔습니다. 23시 15분 커밋(89dc35a)은 25레벨마다 나오는 미니게임 넷 가운데 하나로 보스 타임어택을 넣었고, 여기서는 시간이 다 되면 지고 보상형 광고로 30초를 더 받을 수 있습니다. efe26ae 본문에도 "Missing par still never fails a level."이라고 적혀 있습니다.

0.7에서도 앞쪽 구간과 숙련 플레이어는 완료 조건 밖이었습니다

숙련 플레이어의 별 3개 비율은 배율 0.5에서 1.0까지 한 번도 움직이지 않았습니다. 숙련 실행은 어느 배율에서든 97~99%가 목표 시간 안에 끝났고, 별을 놓친 이유는 실수였습니다. 1~40레벨 일반 별 3개도 56%(0.5에서 55%)로 거의 그대로였습니다.

작업 카드의 완료 조건과 맞춰 보면, 0.7은 201~500레벨(38%)과 501~1100레벨(30%)의 일반 플레이어에서만 25~40% 안에 들었습니다. 1~200레벨 일반은 50~56%, 501~1100레벨 숙련은 77%로 범위 밖이었습니다. 커밋 본문에는 "casual 3-star 30-50%"까지만 적혔고, 실수 허용치(STAR3_DIV 12)는 이번에 건드리지 않았습니다.

표본은 구간마다 크기가 달라서, 1~40레벨은 레벨 6개(1, 8, 15, 22, 29, 36)뿐입니다. 시간 초과가 곧 실패인 판에는 이 방식을 그대로 쓰면 안 됩니다. 목표를 중앙값에 맞추면 절반이 지게 되니, 05 문서의 타임어택은 제한 시간을 중앙값의 1.3배로 잡았습니다.

플레이 기록을 저장하고 배율 후보로 다시 채점하는 순서

1. 게임과 시뮬레이터가 같은 목표 시간 함수를 쓰게 합니다. 이 저장소의 pace.py는 앱의 Pace.kt에서 상수를 읽어 그대로 계산합니다.
2. 플레이어 유형 둘 이상으로 레벨 표본을 돌려 실행마다 (클리어 여부, 시간, 실수)를 저장합니다.
3. 숫자를 보기 전에 구간별 별 3개 목표 범위부터 적습니다.
4. 저장한 기록에 배율과 하한 후보를 바꿔 적용하고, 구간마다 목표 중앙값, 일반 중앙값, 목표 안 비율, 별 3개 비율을 한 표로 뽑습니다.
5. 사람에게는 선택지 2~3개를 뒤쪽 구간 숫자와 함께 보입니다.
6. 상수를 바꾸면 레벨 데이터의 목표 시간 열을 다시 만들고, 검사점 테스트와 전 레벨 대조 테스트를 같은 커밋에서 갱신합니다. efe26ae는 검사점 13개(L1000은 380초에서 270초로)와 1,100레벨 표를 함께 고쳤습니다.

그날 스크립트에서 별을 다시 매기는 식은 아래와 같습니다(변수 이름만 풀어 썼습니다).

def par(base, scale, floor):
    t = base * scale + AUTOSTART_SLACK_S   # 첫 탭 전 5초
    return min(max(round(t / 5) * 5, floor), PAR_MAX_S)

three_star = cleared and time <= par(base, scale, floor) and mistakes <= arrows // 12

한판블록의 난이도를 같은 방식으로 봇에게 먼저 풀려 본 기록은 블록 퍼즐 난이도 설계: 지지 않는 게임을 시뮬레이션 봇으로 고친 과정에 있습니다.

남은 일

실제 사용자의 별 3개 비율은 아직 재지 못했습니다. 2026년 10월 27일 점검에서 GA4의 level, stars, world 맞춤 측정기준이 전 기간 (not set)으로 나왔습니다(화살표 매듭풀기 level_up 1,258건). 앱이 정수 값을 숫자 파라미터로 보내서 잡히지 않는 것으로 보이고, 다음 릴리스에 문자열로도 함께 보내는 안이 올라가 있습니다. 0.7 적용 뒤 G1 판정을 다시 돌린 기록은 아직 없습니다(보고서는 10월 3일 이후 그대로).

자주 묻는 질문

다른 AX 노트

• 화살표 퍼즐 1,100판을 만든 역구성 생성기와 G2 게이트
• 퍼즐 게임 첫날 이탈 분석: 기기별 이벤트 순서와 판별 계산으로 찾은 첫 장의 벽 4판
• 블록 퍼즐 난이도 설계: 지지 않는 게임을 시뮬레이션 봇으로 고친 과정
• Android assets를 미리 gzip한 실측: APK 이득은 0, .pack.gz는 .pack이 되어 FileNotFoundException
• SKT 판매 삼성 폰에서 market://을 열면 스토어 선택 창이 뜬다: Play 패키지부터 지정하기
• addOnCompleteListener(this)가 onStop에서 지운 리스너 때문에 스플래시에 멈춘 버그

게임 개발 글 전체 보기 · AX 노트 전체 보기