Motion Intent Engine

Question

A wrist, hip, or shoulder moving in one frame is not yet a command. How can a game distinguish an intended move from camera noise, ordinary posture changes, and stale observations?

Approach

A provider-neutral pose frame crosses from native capture into Unity. Neutral calibration provides a person-relative reference; normalized geometry and time-based evidence feed stateful recognizers rather than fixed pixel thresholds.

The source implements seven intent types: move left, move right, crouch, punch left, punch right, block, and jump. The experimental Runner bridge maps only the four movements its game understands: left, right, jump, and crouch/slide.

Integration boundary

The iOS Apple Vision provider is implemented, while the experimental Runner path defaults to MediaPipe with Demo Assist. The bridge checks calibration, tracking, intent phase, order, and a bounded pending queue before attempting a game action. Recognition, bridge acceptance, and actual controller response remain separate observations.

Evidence

Source-level and deterministic test coverage exist for calibration, recognizers, provider boundaries, and Runner mapping. Historical packaging and process liveness are recorded, but neither a successful automated test nor app launch proves physical gameplay acceptance.

What remains open

The current research record still notes readiness and quietness edge cases, correlated jitter, and slower-cadence behavior. A bounded human-operated pose and gameplay comparison is needed before claiming reliable, low-latency control.