Read on Twitter
After seeing Flash die last year (RIP), I wanted to see how it is to release a game in a mobile browser in 2021. 
Here’s why I think mobile browsers are deliberately designed & engineered to make this process as hard as possible. (long thread) https://twitter.com/any_user/status/1355112166207205379?s=20
Here’s why I think mobile browsers are deliberately designed & engineered to make this process as hard as possible. (long thread) https://twitter.com/any_user/status/1355112166207205379?s=20
Originally, OKO was made with openframeworks. I wasn’t involved in the original development in 2012, when @nadyasuvorova made it as a student project and Pierre Rossel wrote the code. I later helped make the game retina ready, to freshen up my C++ skills.
In Dec 2020, Apple decided to remove the game from sale, since it wasn’t updated for a while. Also, it was broken, because of some recent iOS changes. Fixing some of the glitches required an update of openframeworks, but after doing that new bugs appeared, as it always happens.
I was not very motivated to go through old C++ code. Also, I was a little annoyed (not the first time!) of Apple to make me work for nothing. In the light of flash dying, I was thinking about how to preserve the game in a more accessible way, outside of closed platforms.
OKO is a simple puzzle game, so I thought it would be a great candidate for conversion into a web game. My initial thought was, that apart from not being able to earn money by selling a game, there is (or should be) no real technical hurdle to porting it.
Based on the idea of making it easy to preserve, I also wanted to keep the tools as simple as possible (no game engine or graphics framework). The basic setup of the game was ready pretty quickly. I built the gameplay with a 2D Canvas context, the UI with html/css/svg.
I won’t write about the state of javascript/html/css here, that’s a whole other story. The OKO gameplay consists mainly of a single image masked by differently sizes rotating circles as puzzle pieces. After a few tweaks here and there, everything was running.
I was working on my external non-HDPI screen. The first time I opened it on my laptop HDPI screen, the game was running at 5 fps. Great. For some reason, Canvas 2D is incredibly slow at drawing high-resolution images, on all browsers, desktop and mobile.
I thought it may be the masking that is slow, but even just drawing one full-window (rotated) image was killing the frame rate. “Use WebGL if you want faster drawing” was the most common advice I read.
I didn’t want to use WebGL for something simple as drawing a few images. After reading up on it, it seemed like that's just the way it is and no one cares. I’d be able to use WebGL, but something simple like that shouldn’t require using a low-level graphics API.
In the end my solution was to use SVG for rendering, instead of Canvas, which for some reason is much faster on most (not all…) browsers. It was running ok on desktop browsers and also on mobile browsers in the first tests. Everything was fine? No, not at all.
Just after playing for a few minutes, on iOS devices, the frame rate dropped to around 1 fps for a few seconds, then recovering to a playable state. It happened every time, without exception, always somewhere between 1 and 3 minutes into the game.
I first suspected it was something related to garbage collection, but that wasn’t it. The profiler showed just that drawing gets slower and slower, until it recovers magically. I couldn’t understand what was happening, so I let it rest for a few days.
With a fresh mind, I tried removing all the things that could impact the drawing. After removing basically everything, it was the SVG preserveAspectRatio attribute that caused the massive framerate drop. Removing the attribute solved the problem immediately.
The two more accessible rendering techniques in browsers both have major (and pretty random) performance issues. I can’t see how there’s any good reason for that, except lack of interest or active neglect. Remember, I’m only trying to draw a few images on the screen.
In 2007, I learnt coding with flash (AS3). If somebody would have told me at the time if I want to move some images smoothly, I should better learn a low-level graphics API, I’m not sure if I’d do what I do now. Apparently, computers got more complicated in the last 13 years.
All the technical problems were solved, but there were still some issues with interaction and viewport. The obvious one: You can’t have a true full-screen web-app on mobile. There’s the option on iOS to create an “app” out of your website, but that still leaves the status bar.
And that doesn’t give you any control to lock the orientation. Also, on both Chrome Android and iOS Safari, it’s still impossible to fill the browser window consistently. If mobile browser vendors wanted it to be a games platform, it would be an easy thing to fix.
You can’t imagine how hard it is to disable all the “standard” web functionality like scrolling, selection feedback etc. On iOS, I haven’t found a way to disable the long-press feedback vibration. If you make a game that requires holding a touch, you just have to live with that.
On iPad, there’s at least the possibility to go to fullscreen mode, but that seems to be not intended for interactivity, as any swipe immediately closes the full-screen mode again. The basics you need in a touch based game, touch and drag on the full screen is just not possible.
Reading through some Webkit threads and other random comments, it seems like it’s a mix of passive and active neglect that makes things like they are now. If there would be any incentive by browser vendors to change any of this, it would be relatively straightforward to fix it.
The sad (although not new) truth is, companies like Apple and Google have zero incentive to make it easier to create web-based fullscreen experiences. They do as little as possible to pretend they support web technologies, while deliberately not improving the user experience.
I don’t really know what to do about all this: A browser is still the most accessible way to share an interactive experience. Html just never replaced flash and it sucks. Anyway, if any browser devs read this, I’m happy to be proven wrong in my perception of this!
