Think about how to improve performance for "laggy" clients (predominantly low-end Android phones)

[lazerwalker]

Our Play Store ratings are crappy, and a lot of the written reviews complain about how laggy the game is. Presumably we're not going to spend time optimizing the game (other than maybe #200), but just upping the minimum OS version we support might be effective at filtering for only allowing newer devices that have a better chance at a baseline of performance.

Not sure how I philosophically feel about this. Assuming we aren't actually going to make the game perform well on shitty phones, there's a conceptual question about whether we should just let people try anyway, or actively say "no, the experience doesn't meet our bar".

[orta]

Can we detect in some wat and only show 50 birds?

[lazerwalker]

That's a good call. Believe we're sending the API version up to PlayFab — should be easy to expose that in a friendlier way to our JS.

As with all things Android, would be great if we had a test device. I thiiink all my shitty Android tablets are too old to even run the game.

[lazerwalker]

A thought for a more platform-agnostic way: I wonder if Phaser can give us a live FPS count we can use to throttle number of birds

[orta]

http://www.html5gamedevs.com/topic/36250-how-to-know-the-current-fps-in-phaser-3/?do=findComment&comment=207795

[orta]

See for a possible route 53e36c4

[lazerwalker]

There's now a "Quality" setting in settings, defaulting to "high".

"Low Quality" means we only show the top 60 birds, and don't draw ghost bird attire.

I'd like to figure out a way to detect poor performance and set this automatically. Phaser's FPS detection seems unreliable.

Additionally, #231 will let us show attire in low quality mode, Presumably in Low Quality mode we forgo the idea of "loose" attire and just bake ALL attire into the single sprite, whereas High Quality mode leaves loose attire as discrete sprites

[lazerwalker]

So! Phaser's FPS counter's a bit broken.

Now: if you have "auto" quality set, what I do is, when you first play a royale game in a session, I manually calculate a janky version of the FPS: for the first N frames of the update loop, I store the timestamp delta from the previous frame, and then average that.

If it's below a certain number (a fuzzy magic number tested on my desktop, my iPhone XS Max, my shitty Android phone, and Stephen's good Android phone), we immediately switch to low quality mode, and also set a flag that means all future games in this session (= until the JS game restarts, it's a variable stored in memory but not localstorage) will use low quality mode.

There's a slight performance hit to doing this test and then enabling low quality mode, as opposed to just starting with low quality mode. It's slight enough that I'm okay doing this test, especially given the way we then proactively enable low quality mode the rest of the session.