Testers said the time was "too long, so it's easy": checking that with a simulation before cutting puzzle par times by 30%

Eight par scales applied to one set of simulated runs

Par in Arrow Knots is a countdown at the top of the screen, but nothing happens when it reaches zero; the level keeps going. It matters for stars: a three-star clear needs at most one mistake per 12 arrows and a finish inside par. Shorter par means fewer three-star clears, and how many fewer depends on where in the game you are.

The simulator has two players. The casual one checks arrows in random order at 120 ms per arrow; the skilled one checks outward from its last tap at 60 ms. Tap time follows Fitts's law (far and small targets take longer), and mis-touches and taps on blocked arrows happen with set probabilities. The agent took every 7th level from 1 to 1,100 (158 levels), ran each 30 times as the casual player and 15 times as the skilled one, then rescored the same runs under each candidate scale and floor. The candidate scales were split into two batches and run twice, taking about 5 and 3 seconds.

Par figures are medians across the levels in each band. In the same runs the casual median was 41 s for levels 41-200, 93 s for 201-500 and 188 s for 501-1100, and the skilled three-star rate was 67 / 71 / 77% on every scale. On levels 41-200 the casual three-star rate is 50% at both 1.0 and 0.7: runs inside par fell from 88% to 84%, yet three-star clears did not move, so the runs pushed past par were mostly runs that had already lost the third star to mistakes.

The agent called par "about 2x" the casual median and proposed a 45% cut

The testers' list had 11 items; the timer was item 4: shorten the time because it is too long and therefore easy, and when time runs out, restart the level or show the watch-an-ad prompt. The operator pasted the list at 14:41 KST. Two minutes later the agent, having read the code, answered that par was "about 2 times" the casual median solve time and "about 3.5 times" the skilled one. The example in that same answer was a 22-arrow board with a 54 s par, a 41 s casual median and a 24 s skilled median. Those numbers give 1.3 and 2.3.

Working from that "about 2x" figure, the agent recommended cutting every par by about 45%, bringing par down to roughly the casual median. At 14:54 the operator picked that option, which also limited real time-out failures to one or two levels per world.

What stopped the 45% was a done-condition the agent wrote onto the task card a few minutes later: "recompute 3-star rates per band by simulation: skilled 60-75%, casual 25-40%." The agent ran that check before touching the code. At 0.55, casual runs on levels 501-1100 finished inside par 1% of the time and earned three stars 1% of the time. On levels 41-200, par (40 s) dropped below the casual median (41 s).

Par was 1.6 times the casual median on 41-200 (65 s against 41 s) but only 1.4 times on 501-1100 (265 s against 188 s). A single scale taken from one board's ratio pushes the later bands, which had less slack, under the median first. Take the direction from testers, and pick the amount from a per-band three-star table.

At 15:06 the agent asked again with three options: a 30% cut (recommended; casual three stars 30-50%, skilled 67-77%), 35% (later-band casual 12-27%) and 45% (the first plan; later-band casual 1-9%). It had also simulated 0.75 and 0.8 but did not offer them. The operator chose 30% at 18:44, and the commit ten minutes later applied the 0.7 scale and lowered the par floor from 20 s to 15 s.

The design docs made par generous on purpose

The October 2 design doc (05) made par a soft countdown: run past it and you lose only the third star. It cited a fan-wiki summary saying Candy Crush removed its timed levels in May 2018 (the doc notes the original page was blocked and never read) and the Two Dots help page line "Two Dots is not timed!", and it followed the game's earlier positioning as a relaxing puzzle (doc 00).

The solve-time model doc (06) multiplied its fitted formula by 1.42 so that casual players would have 30% of the clock left on average. The October 3 check gate for the 1.1.0 expansion to 1,000 levels plus an endless mode, called G1, required the same thing: casual mean time left of at least 30%. Big boards add a per-screen term, PAR_SCREEN_S, which the spec allowed to be 2-4 s. The model spent 12.4 s per extra screen on camera pans and off-screen checks, and 2-4 s left only 13-22% of the clock, so the term was frozen at 19 s (632adb5).

That 19 s is item 1 under "Spec deviations" in the G1 report, with its reason, because the workstream rules (09b) said: "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." The G1 report's check table lists part 3 casual mean time left at 30.6%, against a 30% minimum.

None of the model's constants were fitted to real players. Doc 06 took search and tap speeds from ranges in visual-search and Fitts's-law studies, and marked the chance of tapping a blocked arrow as "an estimate, to be calibrated with telemetry." Doc 05 planned to reset each level's par to the 70th percentile of real mistake-free clears after launch, but on October 4 there was no such data.

Time-out failure went into a boss time attack, not the main levels

The second half of the testers' suggestion, failing the level when time runs out, was not adopted as asked. It was option two in the agent's 14:44 question ("every level fails from world 2", i.e. from level 31), described as more rewarded-ad views but a risk of losing players who like to solve calmly. The task card that day also recorded the agent's market check: the top two apps in the genre advertised "no timer" in their store text, and one app used a hard timer with a +60 s ad.

A real time limit went into the code that night as a mini game. Commit 89dc35a at 23:15 added four mini games every 25 levels, one of them a boss time attack where the clock can run out and a rewarded ad buys 30 more seconds. Main levels still never fail on time; efe26ae's message says: "Missing par still never fails a level."

Even at 0.7, early levels and skilled players missed the done-condition

The skilled three-star rate did not move between scales 0.5 and 1.0. Skilled runs finished inside par 97-99% of the time on every scale; mistakes were what cost them the third star. Casual three stars on levels 1-40 also stayed at 56% (55% at 0.5).

Against the task card's done-condition, 0.7 was inside 25-40% only for casual players on levels 201-500 (38%) and 501-1100 (30%). Casual players on levels 1-200 sat at 50-56% and skilled players on 501-1100 at 77%, both outside the range. The commit message says only "casual 3-star 30-50%", and the mistake allowance (STAR3_DIV 12) was left alone.

The sample is thin at the start: levels 1-40 contributed six levels (1, 8, 15, 22, 29 and 36). If running out of time fails the level, don't tune to the median, since that fails half of all attempts; the time attack in doc 05 set its limit at 1.3 times the median.

Storing simulated runs and rescoring them per candidate scale

1. Make the game and the simulator use the same par function. Here pace.py reads its constants out of the app's Pace.kt, so the model plays the shipped numbers.
2. Run a sample of levels with at least two player types and keep (cleared, time, mistakes) for every run.
3. Write the target three-star range per band before you look at results.
4. Rescore the stored runs under each candidate scale and floor, and tabulate per band: median par, casual median, share inside par, and three-star rate.
5. Give the person deciding two or three options, each with its later-band numbers.
6. When the constant changes, regenerate the par column of the level data and update the checkpoint tests and the all-levels comparison in the same commit. efe26ae changed 13 checkpoints (level 1000 went from 380 s to 270 s) along with the 1,100-level table.

The rescoring in that day's script centres on these lines (variable names spelled out):

def par(base, scale, floor):
    t = base * scale + AUTOSTART_SLACK_S   # 5 s before the first tap
    return min(max(round(t / 5) * 5, floor), PAR_MAX_S)

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

We also had bots play a block puzzle before players did; that write-up is Block puzzle difficulty: how simulation bots caught a game you could never lose.

What's left

We have not measured real players' three-star rate yet. An October 27, 2026 check found the GA4 custom dimensions level, stars and world reading (not set) for all time (1,258 level_up events in Arrow Knots). The app appears to send these integers as numeric parameters that the dimensions don't pick up, and sending them as strings too is proposed for the next release. There is no record yet of the G1 checks being rerun after 0.7 (the report is unchanged since October 3).

FAQ

More AX notes

• A reverse-construction generator and the gate behind 1,100 arrow-puzzle levels
• Puzzle game day-one churn: per-device event timelines, exact board math and four walls in chapter one
• Block puzzle difficulty: how simulation bots caught a game you could never lose
• Pre-gzipping Android assets, measured: zero APK savings, and .pack.gz became .pack with a FileNotFoundException
• A market:// link opens a store chooser on SKT-sold Samsung phones: set the Play package first
• A splash that never moved on: addOnCompleteListener(this) and onStop

All notes on Game development · All AX notes