Spatial and alternative interfaces
Spatial and specialized input requires calibration, clear action confirmation and a way to continue after signal loss. Each overview separates player actions, state changes and alternative rules. Examples are hypothetical design scenarios, not claims about a named game. A prototype check states an observable question for the next iteration. Existing detailed references remain separately linked from the direction map.
No matches
Change your query or reset the filters.
Mechanics and variants
1VR grabbing, gestures and hand manipulationOverview and example ↗Spatial grabbing links hand pose to a virtual object through contact start, holding and release rules.4
Mechanic variants
- Direct grabbing requires close contact.
- Distant rays select remote objects.
- Two-handed actions derive orientation from two points.
- Release transfers an estimated throwing velocity.
Design example. A player holds a housing with one hand and turns an axis-constrained crank with the other. Prototype check: Test lost hand tracking and controller alternatives so objects do not launch unexpectedly when tracking returns.
2VR locomotion, bodies and room-scale spaceOverview and example ↗VR locomotion connects physical pose to virtual routes while maintaining understandable space boundaries and turning methods.4
Mechanic variants
- Teleportation selects a validated destination.
- Continuous movement assigns speed to a separate axis.
- Snap turning changes orientation in steps.
- Room-scale movement uses the available physical area.
Design example. A player inspects a bench by stepping physically and travels between rooms using selected teleport controls. Prototype check: Test seated play, recentering and tracking-boundary changes without requiring a physical step for completion.
3Breathing, pulse and biosignalsOverview and example ↗Biosignal or breathing input changes a game parameter from a measured feature while preserving calibration and voluntary opt-out.4
Mechanic variants
- Breathing rhythm controls a fictional object's expansion.
- Pulse input uses an actually available sensor.
- Smoothing reduces random measurement jumps.
- Manual substitutes preserve play without biosignals.
Design example. A virtual sail opens with a comfortable breathing rhythm that can be replaced by holding a button. Prototype check: Test consent, signal loss and personal calibration; a game indicator must not present medical conclusions.
4Musical instruments and specialized controllersOverview and example ↗Specialized controllers translate familiar performance gestures into game actions through explicit event mappings.4
Mechanic variants
- Notes select actions through a mapping table.
- Event strength modulates values when supported.
- Pedals change modes or sustain effects.
- Calibration aligns input latency with music.
Design example. A music controller's keys open gates in sequence while a pedal holds an opened passage. Prototype check: Test actual event formats, simultaneously held notes and a keyboard substitute when the controller is absent.
5Steering wheels, pedals, joysticks and cockpitsOverview and example ↗Cockpit input distributes control across axes, pedals and switches with consistent ranges and neutral states.4
Mechanic variants
- Wheels set angles within their supported range.
- Pedals expose separate or combined values.
- Levers preserve an absolute parameter position.
- Profiles map functions to a specific device.
Design example. A game truck uses a wheel and two pedals while buttons replace a missing third axis. Prototype check: Test end-stop calibration, combined axes and multiple devices; force feedback needs separate capability support.
6Light, projections, surfaces and interactive installationsOverview and example ↗Installations connect participant positions and physical surfaces to projected responses through stable spatial alignment.4
Mechanic variants
- Calibration aligns camera and projection coordinates.
- Touch selects a region on a physical surface.
- Shadows become controllable play objects.
- Several participants share one interaction area.
Design example. A projected river crosses a table and moving physical blocks changes its virtual water route. Prototype check: Test projector movement, camera occlusion and lighting changes with an explicit recalibration mode.
7Physical objects, markers, NFC and QROverview and example ↗Physical tokens provide identifiers or poses that a game maps to a specific object and permitted action.4
Mechanic variants
- QR codes select records by a read identifier.
- NFC requires a supported reader and accessible channel.
- Geometric markers provide observed poses.
- Physical figures can encode a limited property set.
Design example. A QR card adds an item to a local collection and rescanning opens its existing record. Prototype check: Test unknown tags, repeat reads and missing NFC access in the target environment with an explicit selection alternative.
8Text input, commands and conversational interfacesOverview and example ↗Command interfaces translate text or speech into constrained actions and expose interpreted intent and execution results.4
Mechanic variants
- Grammars define supported verbs and objects.
- Clarification resolves ambiguous target names.
- Confirmation separates recognition from important actions.
- History permits repeating or correcting a command.
Design example. “open the airlock” requests a choice between two airlocks instead of randomly executing one interpretation. Prototype check: Test unknown commands and misinterpretations; free wording should not hide actual action limits.
Sources and examples
Sources support particular techniques or methodology, not every family variant. Design examples and mechanic combinations are illustrative.
- Khronos: OpenXR
Primary XR interface standard. Hand-tracking and extension support depend on the runtime; the standard does not guarantee arbitrary biosignals or NFC.
- MDN: WebXR Device API
Documentation of web XR interfaces and compatible-device discovery; browser and capability availability is limited.
- Android Developers: Sensors overview
Sensor-type context, including heart-rate signals with suitable hardware; not a promise of biosignal access in a browser.
- W3C: Web MIDI API
Primary draft standard for MIDI events, inputs and outputs. Actual access and controller format require separate checks.
- MDN: Gamepad API
Device-axis and button context; not a guarantee of arbitrary wheel, pedal or force-feedback support.
- OpenCV: Geometric transformations
Primary image-coordinate transformation documentation, including perspective transforms; part of surface-calibration context.
- Android Developers: NFC basics
Primary Android NFC-tag documentation; not a claim of NFC availability in every phone or web application.
- Inform 7
Primary open-source interactive-fiction and text-action language project; context for constrained command vocabularies.
CC BY 4.0 · gamemechanics.pro contributors