Unity Input Action Maps: Kontexte, Control Schemes und persistentes Rebinding

Absichten vor Tasten benennen

Eingabecode lässt sich leichter warten, wenn das Gameplay eine Absicht wie Interagieren, Lenken oder Bestätigen anfordert. Eine physische Taste ist eine Möglichkeit, diese Absicht auszudrücken. Zunächst eine kleine Liste von Absichten anlegen und festlegen, welche davon gleichzeitig verfügbar sein sollen. So bleibt ein Menü-Shortcut nicht versehentlich ein Bewegungsbefehl, nachdem sich die Oberfläche geändert hat.

Die Ebenen unterscheiden

Eine Action stellt eine Eingabeabsicht dar, ein Binding verbindet sie mit Controls, und eine Action Map fasst Actions zusammen, die gemeinsam aktiviert werden können. [1] Control Schemes ordnen Binding-Gruppen bestimmten Geräteanforderungen zu; sie ersetzen nicht die eigene Richtlinie für Gameplay-Kontexte. [2] Diese Konzepte entsprechen dem Stand von Input System 1.14. Kontextnamen getrennt von Gerätenamen halten, damit Gamepad- und Tastaturnutzer denselben Spielzustand erreichen können.

Einer Komponente die Verantwortung übertragen

Einen einzelnen Context Owner entscheiden lassen, welche Gameplay- und Interface-Maps aktiv sind. Andere Komponenten nutzen Actions, statt eigenständig konkurrierende Maps zu aktivieren. Bei PlayerInput die Actions des jeweiligen Spielers verwenden; mehrere Komponenten können private Kopien eines gemeinsamen Action-Assets besitzen. [3] Map-Wechsel zusammen mit Pause- und Possession-Wechseln protokollieren, damit sich Eingabeprobleme anhand eines kurzen Ereignisprotokolls reproduzieren lassen.

Beispiel: Bedienung eines Frachtkrans

Eine Spielfigur geht zu einem Kran und setzt sich in dessen Sitz. Die Walking-Map wird deaktiviert, die Crane-Map aktiviert, und eine bewusst gewählte Pause-Action bleibt verfügbar. Beim Verlassen des Sitzes wird dieser Wechsel umgekehrt. Ein Gamepad-Stick und Tastatur-Bindings drücken beide die Bewegungsabsicht des Krans aus, ohne dass der Gameplay-Code des Krans angepasst werden muss. Während eines Rebind-Bildschirms die betroffene Action aussetzen und anzeigen, welches Binding gerade geändert wird. Den Abbruch definieren, unzulässige Controls zurückweisen, Konflikte nach einer sichtbaren Richtlinie behandeln und auf jedem Ausstiegspfad den vorgesehenen Map-Zustand wiederherstellen. Das Verlassen des Bildschirms sowohl über die Abbrechen-Schaltfläche als auch durch Schliessen des gesamten Menüs testen.

Persistenz und Grenzen

Binding Overrides lassen sich mit SaveBindingOverridesAsJson serialisieren und mit LoadBindingOverridesFromJson wiederherstellen. [2] Diese Daten im gewählten Speichersystem ablegen und einen Weg bereitstellen, um auf die Standardwerte zurückzusetzen. Die Einstellungen versionieren, wenn sich ausgelieferte Bindings ändern, weil ein alter Override das vorgesehene Layout unter Umständen nicht mehr beschreibt. Zwei lokale Spieler, das Wiederverbinden von Geräten, gehaltene Controls bei Map-Wechseln und wiederholte Rebind-Sitzungen testen. Ein korrekter Binding-Pfad belegt weder, dass der richtige Spieler das Gerät besitzt, noch dass die Map aktiviert ist, noch dass die Oberfläche das tatsächlich wirksame Binding anzeigt.

Quellen

1. Input System 1.14: Actions — Unity Technologies.
2. Input System 1.14: Action bindings — Unity Technologies.
3. Input System 1.14: Player Input component — Unity Technologies.