Flox is phasing out - a Post Mortem
Daniel Sperl on December 5, 2019First things first: the reason for this blog post is a major heads-up: I’m going to have to shut down Flox around August 1st, 2020. Yikes.
I’m aware that this might mean a major hassle for the remaining users of Flox – depending on how much use you make of the service. Believe me, I didn’t take this decision lightly.
In a nutshell, Flox didn’t work out because of some wrong assessments on our side in regards to the App Engine (pricing, vendor lock-in), Adobe (AIR investments), and our self-inflicted pricing strategy (which was honorable, but doomed).
Actually, I think this is the perfect moment to take a step back and do a “post mortem” about the whole project. While I’ve been rather silent about Flox for a while, it’s been up and running for over six years now, and it has seen its share of ups and downs in its lifetime.
I hope you’re not in a hurry - it’s a rather long story! Let’s start at the beginning.
Flox – the no-fuzz Game Backend
Back in 2012, my friend Holger and I made a big step: we decided to become independent and work full-time for our company Gamua. Adobe had just started to give us funding for Starling, so we had some regular cash coming in and – heck, we just wanted to follow our passion.
We quickly decided that Starling should always remain free and Open Source; a promise that holds true to this day. However, relying solely on Adobe for our income was not an option, either – we needed some other source of revenue, and it should ideally tie in well with Starling.
It’s hard to imagine nowadays, but the idea of providing a game backend as a service was quite new back then, and there wasn’t much competition (yet). The idea felt just right, too: most mobile games need some kind of backend, and we knew we were able to create something really special – flexible and easy to use, just like Starling.
Hosting
Since we were just a team of two, handling the servers ourselves was not an option. You never know beforehand how much traffic a game will create, and how quickly! If there was a customer with a really successful game (which we hoped!), we needed to be able to cope with that.
Thus, Google’s “App Engine” sounded like a perfect fit for us. In the App Engine, you write code using a specific set of Google APIs, interacting with specific services for database, caching, etc. A server app compiled like that would then be uploaded to Google’s server farms – automatically scaling to deal with any storm that might come.
Pricing was a little challenging, because running code on the App Engine is not cheap; but like all IT products, prices were bound to go down sooner or later (right?). Furthermore, once you committed yourself to using it, you couldn’t easily migrate away – the code was hand-optimized to get the most out of Google’s APIs, after all.
Still, with the knowledge we had back then, I think our decision to use the App Engine was sound. Holger worked his software architecture magic on the server side, and I hacked away the ActionScript API – and mid 2013, we had a soft launch with a great feature set. Feedback was very positive and lots of Starling developers gave it a chance. Scaling worked just as we hoped, too: with a few quickly-fixed exceptions, Flox really delivered its promise.
ActionScript Next vs. Creative Cloud
After a while, though, the outlook deteriorated. Part of the issue was Adobe’s shift in focus: when we started Flox, “ActionScript Next” was still on the way, and there was a feeling of excitement in the community. AIR had a great future ahead of it!
Alas, just a few months later, Adobe buried any of its game development ambitions. Anything that didn’t fit into the money-printing machine called “Creative Cloud” was moved into the shadows. The community noticed, of course, and it was clear that usage of Starling – and with it: Flox – had had its peak behind it.
In other words: it was clear that Flox could not survive from the revenue coming in from Adobe Flash and AIR users alone. At first glance, this doesn’t sound too problematic; the Flox-API is REST-based, so we could theoretically provide APIs for any game engine or computer language we wanted. However, outside of the Adobe ecosystem, we were suddenly swimming in a whole different ocean, with competing services (that had, in the meantime, sprung up like mushrooms) backed by companies like Facebook or Amazon, with low prices and big free tiers. We had tied ourselves to the expensive App Engine and couldn’t easily get away.
Ranting about the App Engine
I mentioned before that pricing on the hosting market was always bound to go down, right? You know, Murphy’s Law and so forth. We were mistaken. To this date, the App Engine prices are exactly the same as they were seven years ago. To the cent.
Oh, and you’d think with the hundreds of dollars we pay Google each month, they’d provide you with any help you need, right? Well, think again: to get someone to actually talk / chat / email to you personally, you need some ridiculously priced extra package. As a fellow, tiny company, you’re not worth their time. Instead, kindly use the public issue tracker or mailing list and watch your questions being ignored.
Payment modalities
I know, now it sounds like I’m putting the blame everywhere but on Holger and me. Of course, we’ve got lots of reasons to blame ourselves, too!
For example, both of us detest subscriptions, so we wanted to offer our users something that’s more transparent and fair. That’s why we came up with the “Operations” system.
In a nutshell, everything you do with Flox has a price in “ops”. Submit a highscore? One op. Save an entity? One op, etc. Then you’d buy a pile of ops, and the bigger the pile, the cheaper one op. Simple!
If you wonder why no one else is using this model for a SaaS business: it’s hard to earn money with it. The truth is hard to admit, but most mobile games nowadays are not a huge success. In other words: most games don’t require many ops each month. So we earned no money with the majority of games. A big majority.
Besides, even though the model is really fair, it’s still a tough sale psychologically. Think of a (made up) subscription service that offers you one million requests per month for 10 USD. While you read this, your brain already started to divide those two numbers to get to the price per operation, which will be (spoiler alert) really cheap.
However, what you don’t see as easily is that it’s very unlikely for you to end up anywhere near those one million requests. You’re either far below (which means one request will be very expensive), or you chicken out when you get anywhere close that million and move to the next tier, to be sure your game doesn’t have any downtime.
That’s how the subscription system works: the big number unsuccessful games actually provide those companies with a regular income stream from users that cause almost zero costs.
In our ops-scheme, on the other hand, each single op had to have a price that pays for our Google costs, at least. This will always feel more expensive to our mammal brains, no matter how well we explain this on the website.
Holger moving along
In the end, after having invested about two years into Flox, we decided that we’d rather not restart development on a different server stack. Instead, Holger left Gamua and is now working full-time in a different company (the very successful Dynatrace).
Since then, Flox has been let running as a service for our Starling user base, mostly. On average, revenue and Google costs mostly canceled each other out, with a tendency towards being negative – but Adobe’s funding for Starling made sure it could stay active.
Phasing Out
As you all know, though, Adobe isn’t providing me with a “base income” any longer. Thus, I’ve long pondered about what to do with Flox. Thankfully, it mostly just worked, without much special time commitment on my or Holger’s side (who still helps in his spare time). As long as it stayed that way, I could leave it running.
However, just like anything in life, software is not safe from decay. APIs become deprecated and are eventually shut down, and that’s what’s happening now with the App Engine SDK. After July, 30th, 2020, any software using that SDK (and I quote Google) “might no longer work”.
For me, that was the sign that it’s time to pull the plug on Flox. Migrating to a new SDK is not feasible for me, and frankly: I don’t think it makes much sense. There are great alternatives (e.g. Firebase) that have – thanks to our community’s great ANE developers – excellent support in AIR.
Migration
Don’t get me wrong, I know it’s always tough to migrate to a different backend. Some of you might have to face a similar fate as I have, and remove a game from sale altogether, because changing the code and resubmitting an old app often means a lot of work in all kinds of areas (new SDKs, new app requirements, etc). That sucks!
But there’s simply no way around it, I’m afraid.
To help migration, I’ll soon provide a small tool that you can use to download your player data; that should be a good starting point to import into your backend of choice. Watch the Starling forum for updates, or send me a quick email if you need any help!
Nevertheless, I want to thank everyone who used Flox over the years and provided feedback and support! While it wasn’t a financial success, I’m still really proud of Flox’ ease-of-use and “no-fuzz” approach, so I’ve learned to look back at this endeavor in high spirits.
Hey, and on the upside: Flox’ end hasn’t come through the typical “acquisition by evil multi-billion-dollar corporation” story, right? That must be worth something, karma-wise. 😇
All the best, folks!
P.S.: In other news, January might bring a small update to Starling. Nothing fancy, mind you, but some proof that it’s still being loved and supported. In the meantime: Happy Christmas!