Dev Tool Unity 6 · Windows · XInput

A tool for designing and
testing fighting game inputs.

FightInputDDR reads a real controller in the background and shows, step by step, whether a motion input landed and why. Pick a game and character from the in-game selector, then just play — every move in that character's kit is graded live, no menu-diving required.

What the tool sees, live · Tyrant Rave632146H
HS
[recognized] Tyrant Rave — facing: Right — confirmed after step 2 — 6/6 PASS
Thumbnail
FID
FightInputDDR · Motion Input Grading Tool

A Unity 6 dev tool that reads a real fighting-game controller through XInput and grades whether a motion input — like a half-circle super or a charge move — was actually executed correctly, in real time, against a per-character movelist.

Abstract

What this is for

FightInputDDR is a Unity-based tool for understanding fighting-game motion inputs, built for two audiences at once: developers who need to test how forgiving or strict their move recognition is, and players who want to see exactly where an input like a half-circle super or a charge motion is going wrong. It reads a controller directly through Windows' XInput API — bypassing Unity's window-focus gating — so it keeps working even while a separate game, like Guilty Gear Strive, has focus.

An in-game selector picks a game and character, then swaps between them live; each movelist is authored as an external JSON file, so adding a character doesn't require touching code. Three modes read the same live input: DDR-style, for learning where each input lives; motion-trial, for running one move at a time; and passive detection, which needs no button press — it recognizes the start of any known move from either facing and reports whether it lands. The build is validated against two Guilty Gear Strive characters, Sol Badguy and Slayer, including Slayer's Dandy Step follow-up cancels. All overlays scale consistently on any monitor or aspect ratio.

Three modes

DDR, trial, and passive detection

Each mode looks at input a different way, but all three read the same live controller — nothing simulated, nothing replayed.

Mode 01
DDR Mode
Single inputs scroll down lanes and get judged Perfect / Good / Miss against a timing line — a proof-of-concept for teaching where all twelve inputs live before moving to real motions. Functional, but the timing judgment isn't tuned yet — still rough.
Next
Mode 02
Motion Trial
step 1 — forward
step 2 — down-forward
step 3 — down
step 4 — down-back
Runs a character's actual move list as an explicit, button-triggered trial — MotionJudgmentSystem.StartTrial — with per-step pass/fail and timing diagnostics against each step's window. Kept in the project for manual, one-move-at-a-time dev testing; enable it by hand in the Hierarchy.
Working
Mode 03
Passive Detection
[recognized] Tyrant Rave · L
[PASS] step 6/6 · 0.083s
[fail] step 3 timeout
The default mode. No click required — pick a character in the selector and just play. Continuously watches the live stream, auto-recognizes the start of any known move from either facing, and reports even on failed or abandoned attempts, filtering incidental presses before confirming.
Working
How it works

Why it can watch the game and itself at once

01Direct XInput, not Unity's Input System
Gamepad reads go through a P/Invoke wrapper around xinput1_4.dll instead of Unity's Gamepad class — specifically to bypass window-focus gating, so the tool keeps reading input while Guilty Gear Strive holds focus.
02One tracker per move, both facings watched
The passive detector spawns a tracker for a move the instant its first step is satisfied, watching both facings of every asymmetric move simultaneously — but only one active tracker per move at a time, so a half-circle motion's overlapping directions across facings can't spawn false rival candidates.
03Confirm-after-N filtering
An attempt is only reported once it's progressed a configurable number of steps (default 2) — so incidental presses that happen to match a move's first input, like ordinary crouching, never get logged as a real attempt.
04JSON-driven characters, swappable live
Each character's movelist is a JSON file in StreamingAssets, parsed at runtime — no recompiling to add a move. The in-game selector reads a catalog of these files and calls into the detector to swap the watched character on the fly, including "any of" follow-up steps like Slayer's Dandy Step, which accepts any of the four attack buttons as a valid cancel.
05Facing-direction agnosticism
Right-facing: ForwardLeft-facing: Back
Right-facing: Down-FwdLeft-facing: Down-Back
Up / Downunchanged
Buttonsunchanged
Moves are authored once, always assuming the character faces right. MotionMirror flips directional chords at grading time, so the same move data grades correctly from either facing without duplicating a single move.
Preview

Screenshots

Live captures from the Unity Editor Game view. More will be added as new characters and modes land.
Tyrant Rave and Volcanic Viper move windows awaiting input, with the game/character selector open below
Sol Badguy's move windows, idle, with the game/character selector open below
Passive detection grading Tyrant Rave as a pass and Volcanic Viper as a fail, with per-step timing
Passive detection grading live — Tyrant Rave PASS, Volcanic Viper FAIL with per-step timing
Slayer's Dandy Step and Last Horizon move windows, with Last Horizon passing and the selector showing Now testing: Slayer
Slayer's Dandy Step follow-up window and Last Horizon (PASS)
Demo

See it in use

About two minutes: the game/character selector, DDR mode, a motion trial, and passive detection recognizing Sol Badguy's and Slayer's moves — including Dandy Step follow-ups — from both facings during a real Guilty Gear Strive session.

What's next

Roadmap

Done
Passive attempt detection. Continuous recognition with no explicit trigger, filtering incidental presses.
Done
Facing-direction agnosticism. One authored move now grades correctly from either facing.
Done
JSON-driven movelist authoring. Character move data now lives in external JSON files, parsed at runtime — no more hand-building per-step data in the Inspector to add or tweak a move.
Done
Game/character selector. An on-screen picker chooses a game, then a character, and swaps the live-watched movelist on the fly — no scene edits needed to test a different character.
Done
Resolution-independent UI. Every OnGUI overlay now scales off a shared reference resolution, so layout and text size stay consistent on any monitor or aspect ratio instead of shrinking or clipping.
DDR mode tuning. The lane-based timing judgment (Perfect/Good/Miss) is functional but not well-tuned yet — needs another pass before it's as reliable as the other two modes.
More characters. Guile and/or E. Honda from Street Fighter, to cover charge-motion inputs and rarer double-down (⬇⬇) inputs that Guilty Gear Strive's roster doesn't exercise.
Later
Calibrated grading against real game recognition. A passive, comparative loop — predict inputs, correlate with player-reported success in-game — to close the gap between the tool's grading and what the actual game recognizes as a landed move. Deliberately avoids any input injection into the game itself.
Later
Canvas-based UI. Replace the legacy OnGUI debug overlays with a proper Canvas interface, including a visual step strip in place of the text log.
Who built this

Team

?
Your Name
Solo developer · Design, engineering, tools
Built end to end in Unity 6 as a personal project for CS 325. Focused on making motion-input grading actually run against a live game session, not just a recorded clip.