08 — Going Further

Four topics that turn course knowledge into shipping knowledge — plus the VR picture.

Switching action maps (menus vs gameplay)

The cleanest pause implementation you'll ever write:

actions.FindActionMap("Player3D").Disable();
actions.FindActionMap("UI").Enable();

Gameplay keys go dead, menu keys go live, and no script ever asks "but are we paused?". PlayerInput.SwitchCurrentActionMap("UI") does the same in one call. Design rule: maps are modes — Player, UI, Vehicle, Dialogue.

Rebindable controls

The Input System ships this nearly for free:

rebindOperation = jumpAction.PerformInteractiveRebinding()
    .WithControlsExcluding("<Mouse>/position")
    .OnComplete(op => { op.Dispose(); SaveBinds(); })
    .Start();                      // "press a key..." listening starts

// Persist across sessions (JSON string — PlayerPrefs works fine):
string binds = actions.SaveBindingOverridesAsJson();
actions.LoadBindingOverridesFromJson(binds);

Full walkthroughs: samyam's rebinding video and this written guide with persistence. The official Warriors sample includes a polished rebinding screen worth dissecting.

Local multiplayer

The PlayerInputManager component + a player prefab with PlayerInput: when a new device presses a button, a new player joins, gets that device assigned exclusively, and (optionally) a split-screen camera. Control schemes from 03 - The Input Actions Asset are what make device pairing work. This is a weekend project on top of this kit's platformer — two squares, two gamepads.

Touch, and why the Puzzle map is your template

The Point/Click pattern already handles single-finger touch. For gestures (pinch, swipe, multi-touch) look at Enhanced Touch (EnhancedTouchSupport.Enable() → Touch.activeTouches) — but exhaust the action-based route first; it covers more than you'd think.

Virtual Reality — what changes (preview of a future course)

We'll cover VR properly later; here is the honest map of the differences:

Same foundation. XR controllers are Input System devices; bindings like <XRController>{LeftHand}/triggerPressed work in the same Actions editor, and everything in lessons 01–04 transfers directly.
Different layer on top. Real VR projects don't hand-bind triggers. The XR Interaction Toolkit (XRI) package supplies pre-made action assets (grab, teleport, UI ray, turn) and interactor/interactable components built on them — see the XRI input docs. You configure and extend those actions rather than authoring from scratch.
New input kinds. Head/hand poses (position + rotation via <XRHMD>/centerEyePosition etc., driven by TrackedPoseDriver), grip/trigger as analog axes, and hand tracking — there is no "pointer position on a screen"; pointing is a ray from a tracked hand.
Interaction replaces navigation. Drag-and-drop becomes physically grabbing (XRI's XRGrabInteractable ≈ our Draggable, XRSocketInteractor ≈ our SnapSlot — the concepts you just learned, in 3D); "look" is your actual head; movement is teleport or smooth locomotion with comfort options.
Plumbing. VR needs the XR Plug-in Management + OpenXR packages and per-headset setup — that's the real install lesson of the future VR course.

Mental model to carry forward: the Input System is the alphabet; XRI is a phrasebook written in it.

Reference recap

Back to 00 - Start Here