A 99-player last-bird-flapping battle royale

I wonder if it might make sense to completely kill the ghost birds, and the top-left "what position you are!" display for Daily Trial.

I feel like it'll help differentiate the two modes, making trial feel more like a quiet personal high score thing, as opposed to a thing you're doing with other people. From a conceptual standpoint, it also helps drive home the Royale idea that a ghost bird is an actual real live human player, since we don't really pretend in Trial mode that the ghosts are live.

Thoughts?

Would be very little integration work (a single PlayFab method, plus either a little custom native work or integrating PlayFab native SDKs), and would give us profile syncing across devices for free.

Low-priority, as we don't currently properly support tablets, but /shrug

Once #19 is done, we'll cache downloaded builds of the game.

But if the user opens the app for the first time with no network connection, right now nothing will happen.

Two options:

1. We include a cached build of the game they can play

2. We display a dedicated screen saying "hey, you need network connection to get the latest data" and don't let them do anything.

I thiiink the latter makes more sense, it'll be easier and I'm okay saying we dont' care about this usecase too much.

When we reject your name (too short / inappropriate / eventually because it's already taken), we should show a text reason instead of just outlining the box red.

Just the color isn't great for accessibility, plus more possible reasons = more confusing.

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".

We don't need to figure out the logic of when to show it now, but it probably makes sense to thread through an API to JS so that we can push this later without an app update.

(to throw out a logic proposal: if you've played at least 10 games, and hit a personal best score in either Royale or Trial, or after 30 games if neither of those has happened)

Besides your score/ranking, we want to make a big deal out of you losing a life.

We probably also want a big "play again" button. (We arguably also want this for Royale mode?)

The web vibration API isn't supported in Mobile Safari, so we probably want to build our own Swift API and expose it in the WKWebView.

It's supported in Android Web views; TBD how we want to handle that.

Places to check:

• Look in Playfab to see if we have users with no displayname set
• Check in the client if there's some reason we'd be rendering 'undefined'
• Check the replay upload and migration scripts to see if there's some way we'd be setting bad data

I think if you die and tap rapidly it shouldn’t activate the share button That accidentally comes up a bunch because it’s where my finger was while I was tapping

h/t @doctorpangloss

Playfab free tier has a limit of 100 on any individual user's inventory.

We can store what inventory they've unlocked in a JSON blob in UserData, which we have a ton of. We're already fetching UserData in many places, so this won't incur extra network traffic.

I think this is technically client-writable, which means it's easier for users to fake this. There maybe a way to turn that off.

Definitely do this for actual unlocked inventory. We might be able to get away with leaving unopened eggs as consumable items, but then we need to make sure we're sweeping away old eggs.

• [x] Rewrite functions to use Azure Functions, deploy to Azure, test they work
• [x] Remove references to Firebase in the main codebase, and update URLs
• [x] Confirm access controls mean the seed JSON files are publicly-downloadable
• [x] Stop the new functions from blowing up the non-function compilation pipeline with tsc errors
• [x] Manually test updateAttire function
• [x] Manually test openConsumableEgg function
• [x] Figure out how to give Orta access to the Azure resource groups
• [x] Port server tests over
• [x] Confirm that the migration script properly works
• [x] Do a one-time migration of JSON data for the hourly seed downloads
• [x] When https://github.com/PlayFab/NodeSDK/issues/105 is fixed, remove npm / git submodule hack from functions dir
• [x] Fix Azure Function CLI deploy to deploy functions AND migration task
• [x] Add Azure Function deploy command to top-level package.json
• [x] Set up Azure static site hosting for both staging and prod
• [x] Remove all traces of Firebase from codebase
• [ ] Figure out why iOS app has a white border around the game when pointed at the Azure-hosted version
• [ ] Figure out why Azure static site hosting requires me to go to flappyroyale.io/prod/index.html instead of flappyroyale.io/prod/ (which is important, since the former would require us to push out new builds of the native apps via the App Store / Play Store)
• [ ] Build and manually test Android app
• [ ] Test Azure CDN right after a deploy to make sure our cache-busting strategies are working
• [ ] Move DNS records for both staging and prod
• [ ] Merge everything into master
• [ ] Maybe: download all firehose bucket data from Firebase, potentially upload to Azure firehose bucket

Previously, all modal prompts were Phaser scenes that couldn't be displayed over HTML forms, so there are a bunch of prompts (e.g. in the royale lobby if you have no lives) that would, on triggering them, take you to a fake main menu screen that just showed the prompt.

We now have proper HTML-enabled modal prompts, so we can switch all these over.