Module fit 

Whether a game’s controls fit a target (ADR-0008 §3): on each screen, the required actions it declares (Screen::actions) must bind to distinct inputs the target’s profile offers.

controls_fit is the check, pure: a target’s profile, the default buttons the game plays it with (the keymap file’s table named after the target, KeymapDef::target_buttons) and the screens’ actions in, every FitProblem out. It fails when:

• a binding uses an input the profile lacks: a button it doesn’t have, a chord it doesn’t list, a system menu item beyond its slots;
• a required action a screen declares has no input the profile offers;
• two required actions of one screen share an input.

What counts as an input is the profile’s: its buttons (a crank’s notches among them, CrankForward and CrankBack), and each chord it lists as one more. What doesn’t: long and double presses (a keymap can’t say them), chords the profile doesn’t list, the system’s own buttons (no keymap can name them: the Playdate’s Menu and Lock, the Deck’s Steam and Quick Access), and the system menu’s items (SystemMenu0 and on), which may hold optional actions only. The engine never folds actions onto fewer buttons to make a game fit: the game redesigns the screen.

GameControls holds a game’s keymap and screens for shuyi check --target, which asks it through the Controls trait, by target.

Structs

FitProblem

A way a game’s controls don’t fit a target, naming what it is about.

GameControls

A game’s keymap and its screens, for the check on every target.

ScreenActions

One screen’s actions, as the check sees them.

Enums

FitRule

Which rule a FitProblem breaks.

Traits

Controls

A game’s controls as shuyi check --target checks them, by target (shuyi_cli::GameTools::controls).

Functions

controls_fit

Whether the controls of layout (a target’s default buttons) fit profile on each of screens: every problem, the layout’s first (in action order), then each screen’s in the order given (see the module docs).