It’s weird, I know, but it does work!
I won’t got into crazy detail about why targeting WebGL on mobile devices is a thing we’re doing. We have our reasons, but there are some weird quirks that don’t seem well documented anywhere, so I thought I’d share what we’ve learned so far. I’ve also been looking for an excuse to start a blog, so here we are!
Input - Controller & Keyboard
The problem
Keeping in mind that this is targeting mobile, touch is obviously going to be the main input, however I wanted to allow design to implement alternate input methods, mostly for accessibility reasons.
When experimenting with this, the setup I was using was hosting the Unity build on my local network and loading the game through an iOS app using a webview. For a while no matter what I tried, it would not show controller or keyboard inputs (connected via bluetooth). Initially I dismissed the focus being a problem because I was tapping on the game first before trying.
The solution
Tapping the game does not put the canvas in focus. Even if nothing else is on the page, the user must manually initiate focus of the Unity canvas. Easiest way to do this naturally is put a HTML/CSS overlay over the game first with a “Tap to start” prompt. This overlay is actually a button which when tapped, hides itself and sets the canvas as focus. Once done, control & keyboard input works exactly as expected, to the point a user wouldn’t know its running in a web browser.
The slightly odd discovery that lead to this is noticing when using the PWA template for Unity’s WebGL with development mode turned on. The template adds a “stop profiling” button in the bottom left corner. Only when tapping this did the controller magically work.
I knew focus would be a thing… But my wrong assumption was that tapping the game would also focus it. I guess Unity must be capturing the tap rather than the “web page” its running on. Strange one.