Skip to content

Research

An Adaptive Coding Game Platform for 3D Hair-Cutting Robot Simulation

HCR is a teaching platform and a research instrument at the same time. Every attempt produces a scored, replayable program against a calibrated item — which is the data an adaptive model needs, generated as a by-product of playing.

Framing

Two problems, one system

Pedagogical

A class moves at one speed

Robotics teaching is bounded by hardware cost and supervision, so a cohort receives a single fixed sequence. Ability within that cohort is not fixed, and the mismatch shows up at both ends of the distribution.

Measurement

Programming ability is hard to score

Unlike a multiple-choice item, a program has an unbounded response space and a continuous outcome. Standard adaptive testing machinery assumes neither, so the instrument has to be adapted rather than applied.

Contributions

What is new here

  1. 01

    Adaptive selection over a generated item bank

    Challenges are not a fixed list. They are generated from item families, calibrated, and selected by Fisher information at the learner’s current ability estimate — so the bank grows without a human authoring each level.

  2. 02

    Guaranteed-solvable generated items

    Procedural generation and reachability are in tension: a plausible-looking target may be unreachable. Solving each candidate before it is served converts that from a hope into a precondition.

  3. 03

    Continuous scores in a dichotomous estimator

    Programming performance is continuous; the estimator available is not. An order-preserving remap around a per-item mastery threshold preserves the ordering while keeping the raw score intact for analysis.

  4. 04

    Determinism as a fairness property

    Server-side replay and travel-derived time estimates mean a result does not depend on the client’s hardware — a requirement for using the score competitively or diagnostically.

Method

How the adaptive layer is built

After every attempt the platform re-estimates how the learner is doing and picks the next challenge to match. Finish comfortably and the next one is harder; struggle and it steps back. One level per student, not one level per class.

Model

Two-parameter logistic

Ability θ on a logit scale, item difficulty b, discrimination a. The guessing parameter is fixed at zero: the response space is a program, not a set of choices, so there is nothing to guess into. Estimating a third parameter here would fit noise.

Response

The program is the response

A learner’s Program IR is replayed server-side and scored. The normalized score is remapped around the item’s mastery threshold τ so that “above τ” and “mastered” coincide, then passed to the estimator. The raw score is persisted separately.

Selection

Information, then exposure control

Candidates are ranked by information at the current θ and then exposure-capped, so learners at the same level do not all receive the same items and the bank is not burned through.

Generation

Difficulty as a target, not an outcome

Item families are parameterised by features that predict difficulty — clearance, reachability strain, budget pressure, loop structure — and solved for a target b. A candidate whose reference solver finds no solution is rejected at generation.

Calibration

Provisional until it has evidence

A new item enters provisional: exposure-capped and excluded from ability updates that count. Once it has responses, difficulty is refit by Newton iteration on the marginal likelihood with θ held at posterior means.

Ability is treated as a single composite θ in this version, with dimension tags recorded on every response for reporting. A genuinely multidimensional model is the obvious next step and is not claimed here.

Validity

An item nobody can finish measures nothing

The obvious way to build a level is to draw the haircut you want and hope the arm can manage it. One of our own early challenges asked for 91 pieces of hair when the arm could reach 20 — unwinnable, and nothing in the level said so.

Now the solver runs first. A candidate target is swept against the collision-free joint space, then handed to a reference solver; anything the solver cannot finish is rejected at generation and never served. The solution becomes the level’s reference cost and reference time.

The reachable set is established by sweeping the collision-free joint space and taking the union of every voxel the tool can contact. The sweep is expensive, so it is computed once and cached as a fixture; both directions are tested — that a replayed reference solution is solvable, and that a dead-zone target is not.

The failure that motivated it

91target voxels requested by a hand-drawn challenge
20reachable by the arm under head-clearance constraints

A learner attempting that item would have read a structural impossibility as personal failure — and the ability estimate would have absorbed it as evidence.

Reproducibility

What a result depends on

Deterministic generation

Hairstyle generation is a pure function of the challenge configuration. The same configuration yields the same voxel set in the same order — no randomness anywhere in the pipeline.

Server-side replay

Competitive scores come from replaying the submitted program on the service, never from a number the browser reports.

Estimated, not measured, time

Execution time is derived from joint travel and configured speeds, so it is a property of the program rather than of the machine that ran it.

Frozen wire contract

The scoring and program types are shared verbatim between the app and the service, and the protocol evolves additively — old clients keep working.

Publications

Related work from the group