Capabilities and permissions
A game must distinguish a client implementation from hardware that is actually available and permitted. Keep a useful touch fallback where the game can support one.
| Capability | Current implementation | Validation limit |
|---|---|---|
| Touch gamepad | Browser, iOS and Android | Native app connection/rendering checked; focused touch assertions still being completed |
| Physical controller input | Browser Gamepad API, Apple GameController and Android input events | Real external pads are not available in this workspace |
| Gyroscope/accelerometer | Native client input paths and supported browser events | Real-phone axes, calibration and permissions need hardware checks |
| QR scanning | Native camera scanners; browser scanner where secure camera APIs are available | Real camera quality/focus has not been tested |
| Private roles, text, drawing and keypad | Built-in view renderers | Game rules and targeting have automated checks |
| Phone haptics | Native output handlers and touch feedback | Device-specific feel is not verified |
| Camera input for games, AR, microphone and light | In product scope; capability adapters and permission design need completion | Do not advertise these as shipping merely because a phone has the hardware |
| Desktop pointer/keys/media | Explicitly approved companion path | OS permissions and platform limits apply |
A browser's camera, motion and other APIs can require HTTPS and a user gesture. A local HTTP controller can still provide base touch input. Use the phone's normal camera to open its join QR when in-page scanning is unavailable.
Request only what the game needs
Tell the player which capability is requested and which game/server receives the data. Camera or microphone access must not start merely because a QR was scanned. Stop capture and release output when the player leaves, backgrounds the app or revokes permission.
Do not treat a native client as permission to expose arbitrary platform APIs to third-party software. Apple/Google policy, operating-system restrictions and the client's declared capability set remain separate checks.
The SDK's extension points keep room for camera/AR, audio, light and future sensors. Unsupported features must report that result and offer the game's declared alternative; they must not silently simulate hardware output.