List inputs and important states
Make rows for mouse, touch, keyboard and pen only when those inputs are supported; add columns for press, movement, release, cancellation, focus loss and resize. For a drag game, test an ordinary release and a pointercancel. For a keyboard game, test simultaneous keys and focus leaving the page. The matrix should reflect actual mechanics, not a generic device checklist.
Record the device, browser, viewport and steps when a test fails. Devtools can emulate screen sizes, but not every hardware behavior or system gesture. Use a real touch device for a touch-first game and check page scrolling around its surface.
Repeat after layout changes
Run the same short test after changing canvas size, orientation, menus or responsive breakpoints. Confirm that pointer coordinates still map to game coordinates and that focus still reaches the intended element. A game may pass initial input tests and fail after a resize because its display transform changed while hit testing retained old values.
Repeat tests after changing canvas size, orientation, menus or breakpoints. Confirm pointer coordinates still map correctly and focus reaches its intended element. MDN documents Pointer Events across mouse, pen and touch; use pointerType to organize cases, not as a substitute for testing.
Questions about testing game input devices
Is browser input emulation enough?
Emulation is useful for repeatable layout checks but may not reproduce hardware and operating-system gestures. Test on real devices for the input modes the game supports.
How many devices should I test?
Choose devices that cover the supported input types and meaningful layout extremes. Record browser and viewport details so failures can be reproduced rather than relying on an arbitrary device count.