Eleven, Flash, HTML5, and You

It has been asked numerous times, both from inside and outside the project (it got asked so much in Slack that I finally had to append to one of our channel topics a statement informing readers that we are not, in fact, rebuilding the client), why Eleven is using Flash instead of HTML5 to build the game client. We appreciate the concern, and as a matter of fact, have discussed the topic fairly extensively. I myself have tried to answer the question many times, in many places, but have never really taken the time to provide a comprehensive rationale for our continued use of Flash.

I suppose the first misconception I’ve seen floating around is that using Flash allows a quicker path to launch, but absolutely no other benefits. From my perspective, the opposite is true. By sticking with Flash for the game client, we actually gain numerous advantages. I’ll address the most obvious (speed of development) first, followed by the two most common concerns people see with Flash (performance and mobile), then discuss the technical hurdles we would face implementing a game client in HTML5, and finally discuss what matters most to me personally: providing an experience on par with that offered by Glitch.

The most obvious advantage gained from continuing to use the Flash client is speed of development. The very first milestone our team accomplished (way back in November, but time has flown and it feels like we’ve progressed so far since what seems like a rather short time ago) was the successful compilation of the Glitch client as provided to us by Tiny Speck. For those who are curious, the process is something like this. My method differed slightly, but the essence is the same. It’s not necessarily a complicated thing to build, but the fact that building the complete client was still a process that took hours to figure out meant that we were dealing with quite the complex beast. It’s about half a million lines of code, and rewriting it would take a significant investment of time. We’re by no means in a rush, but people would like us to open in a (reasonably) timely manner, and we’re trying not to waste your time (as I’ll continue to explain in a bit); HTML5 offers no practical benefit, but numerous downsides, anyway. 🙂

Next up are performance concerns: What are the performance implications of Flash versus HTML5? Not being much of an optimization guru myself, a cursory look at the Glitch client, which still feels like it should run better on the rMBP I bought a couple of months back, would lead one to believe there’s much room for improvement. And maybe there is. However, that improvement would most likely be found by tweaking the Flash client, as opposed to switching to HTML5, which is hardly the performance savior it’s been depicted as. A quote from Cal (Bees!) of Tiny Speck:

“flash is a bit of a performance hog” – try running the same graphics in html5 and you’ll find that flash has very very good performance. unless you’re going to rewrite the client in unity/native-code then flash is going to give you *much* better performance than html5

While I’m in full-on TS-quoting mode, I should also mention the pathway Jono has mentioned for optimizing the Flash client:


“the memory leaks are in the game client, it needs a lot more object pooling”

the game needs 3/4 GB minimum”

We cache assets in memory indefinitely too”


Suffice it to say, the Flash client could use some work, but in general, the client works, and in the grand scheme of things, works well, so it’s not on the list of things that’s holding us back from launch, at least in my perspective.


Next up is the relationship between Eleven and mobile devices. In short, such a relationship would mean certain disaster. MMO’s generally are not something you want to implement on a mobile device. Once again in the words of Cal (and taking another opportunity to shamelessly plug Slack – its search functionality has made finding all these quotes a piece of cake):


you can compile some flash to ios/android, but:
1) adobe have given up on that
2) it was built for very simple stuff anyway
3) glitch requires high bandwidth / low latency that you generally don’t get on phones
4) it’s very cpu/gpu intensive with lots of very large textures
5) mmos aren’t really possible under ios app store guidelines – the content & behavior needs to be built into the app
6) typing & playing on a tablet is pretty terrible
glitch is not a game that was designed for or could work (as-is) on mobile
In short, an MMO, especially a social MMO like Glitch, is not something you’d want to play on a mobile device. The experience would be awful, and it would also discourage the social behavior we’d like to encourage. Speaking from personal experience, I frequently remoted into my web server from my phone to chat with people in Glitch, and it was almost impossible to hold a fluent conversation. We seek to offer a pleasant experience, and supporting mobile devices would degrade that heavily.


The penultimate reason for our decision to stick with Flash (and the part of this post that [finally] includes the cool screenshot you’ve probably been waiting for, and may well have skipped through the rest of the article to find) is that the Glitch client is a technical marvel, that would be next to impossible to replicate. But, you say, shortly after The End of the World, there were various HTML5 remakes of small parts of the game! True. But some of the more difficult parts to re-implement are the ones you don’t see. Namely, LocoDeco, the Eleven/Glitch level editor.


As you can see, it’s a fairly complex tool, and possibly one of the more advanced things ever done with Flash (I’m not the only member of our team to have made this observation). Its use is reminiscent of Photoshop in a way (and having used Photoshop most certainly helps one figure it out). Even if HTML5 were more mature as a technology, I highly doubt something like this would be possible to implement in it (as it is, it’s a testament to the coding prowess of Tiny Speck that they managed to create such an advanced design tool in a platform originally designed to play simple animations on web pages).


Finally, there’s the reason for sticking with the Flash client that matters the most to me personally. It’s why I’m so passionate about this particular issue. In order to deliver an experience that “feels” like Glitch, we need to use the Flash client. Even if it came at some cost in other areas, that’s priceless. We need things like the physics engine baked into the client to work exactly as they were, or things just won’t feel right. If we thought we could’ve done this without the myriad resources Tiny Speck released into the public domain, we could’ve started much earlier (and yet, we probably wouldn’t be nearly as far along as we are now – building an MMO from scratch is nigh-impossible). And using the client TS so graciously provided to us, that can happen. I think Kukubee put it best a couple of weeks ago when we demonstrated our progress to a few of the folks at Tiny Speck:


Kukubee: “damn motherfather, this is glitch!”


And that’s exactly what we’re going for. Nothing less. We’ve discussed it time and again, but if we wish to provide a quality experience, it’s the only way to go forward. I suppose that ultimately, I don’t get the affinity toward HTML5. Presumably what everyone really wants is the Glitch experience they know and love, and we’re trying to deliver that in the best way possible.

16 thoughts on “Eleven, Flash, HTML5, and You”

  1. Fantastic article, thank you for explaining the decision to stick with Flash. I know a lot of people were curious, since TS claimed the downfall of Flash as one of the reasons they closed the doors. This makes sense, though — I can’t fathom how much time it would take to rewrite it all in HTML5.

  2. While I do understand the reasons to stay with flash, one glaring issue does have me sighing at it. Memory leaks were just a think that couldn’t be worked out because of the flash base. This was a problem on my older computer, yes, but more it was an issue for my friends who didn’t have beefy pc’s. they could play for an hour, perhaps two, and then would have to stop before the memory leak/bloat would literally lock up their system.

    The problem and beauty of Glitch’s graphic style is that it looks simple at first, but is amazingly complex when you get down to it. I hate thinking too heavily about the business sense aspect of things, but it was one of the reasons that Glitch had to shutter. To keep the game from going under again, bills are to be paid (one of the issues was that all the flash-based resources caused a heavy load on servers, which meant higher server costs). The nature of the graphics and the core gameplay is deceptively simple, which means new customers are going to expect it to run on their system, be it an android device, a laptop, or an older pc. The official glitch app helped bridge that gap… but I don’t know if that was released into creative commons as well. Either way, if the only answer for new people is “we can’t do that because of the platform”, then their response can very well be “oh, well tell us when the platform changes then”, and move on.

    Another aspect of this is that to keep the game active (besides appropriately sending the word out- one of the unfortunate failings the original game had), is new content for purchases and/or if you’re keeping the subscription model over micro-payments. This also adds to server load and- you know where I’m going with this. Any way you cut it, eventually you’re going to need to clean out the code.

    While I understand that this way is faster for you, and less painful to work with the editor, if I have a choice between something that takes longer to make but lasts longer, or something that will be out sooner but possibly crumple under it’s weight in a short while… I’d want the former. If that means somehow beating the tar out of the flash code until it behaves somehow, or working in another format, I’ll take whatever works.

    1. We’re certainly not denying the existence of memory leaks. I’ve experienced them plenty of times, and as an avid GoC player, I had to reload the client every few games to get it running smoothly enough to play it well. Jono himself admits to them. And as I’ve referenced already, he’s also given some suggestions on how we can deal with them. I can’t promise that it’ll happen soon or even “soon,” as it can’t be said that it’s keeping us from a preview release, or even a future “1.0” launch (as our primary goal for that is to deliver the game as it existed previously), but it’s certainly something we’ll look into for the long term.

      Your second paragraph asks about compatibility issues among platforms, if I’m not mistaken. The game itself simply isn’t compatible with mobile devices (okay, that’s not entirely true, as I have been able to *start* loading the game on an Android tablet, but could never successfully get it to finish), and it’s sort of a fact of life that any developer has to evaluate. A team will evaluate their prospective audience, try to support as many platforms as possible, but ultimately have to make decisions as to whether supporting a given platform is worthwhile. If you own, or know anyone who owns, a Windows Phone device, you’ll most likely be familiar with this scenario. It’s missing a *lot* of apps and games, simply because developers don’t find the platform worth the effort.

      All decisions have tradeoffs. In economics, it’s known as an opportunity cost (correct me if I’m using the term incorrectly; my knowledge of economics is limited to a course I took in high school…). When I wrote this blog post, I knew there would be disagreement. But had we decided to go with HTML5, and had I stood here before you posting the rationale for that instead, we would still meet with resistance, most likely about a subpar game experience that just doesn’t feel right. We had to decide, as a team, which camp we would fall into, and we did (also, as quoted above, Cal himself recommended that we stick with Flash, and he made numerous persuasive arguments, both from the performance perspective, and the mobile device support perspective).

      The grass always seems greener on the other side.

  3. > I don’t get the affinity toward HTML5

    I can’t speak for everyone who loves HTML5, but for most of us it’s the fact that it’s a standard. Not a very mature standard yet, and there are many kinks to work out, but still a standard. It brings the web back to its hippy roots, dishing out hugs to all devices and all platforms. Flash came at a time when HTML couldn’t do what we needed to be done, so it was a necessary evil. Standards-based web development with HTML5 will vanquish that evil.

    That said, I get why you would stick with Flash, I probably would have as well. A fully equivalent HTML5 client would be the ideal, and perhaps we’ll have this one day, but for now resurrecting the Flash client is clearly the most pragmatic approach.

  4. Copper Wiley mentioned a subscription model using micro transactions. I’ve never actually played the game before, so does Glitch require a monthly payment to play?

    1. There was a subscription model that was entirely optional. The original creator of the game was adamant that those paying would not get any game play advantages. There were extra decorations, clothes, and vanity features that came with the subscription, along with a few other practical things like teleport tokens (the ability to teleport via map).

  5. I would be willing to pay a monthly subscription to keep it afloat, and I’m sure I’m not alone, especially after the trauma of losing Glitch in the first place.

    1. We haven’t discussed funding (in depth) yet, but (optional) paid subscriptions are certainly a possibility. I know they didn’t generate enough revenue to work for TS, although we believe we can operate on far fewer funds (my estimate is about $1k/month if we had as many players as Glitch did).

  6. Hrmmm. If the project is meant to remain open source, I don’t see why you couldn’t fork various pieces like the level editor and have people work to port them to HTML 5, I suspect that challenging as it may be, it might force a bit of innovation for everyone and the game in the end might be better for it. I know that they have a port of doom somehow recompiled into javascript and running on WebGL. If that’s possible I don’t see why things couldn’t be tweaked to get everything moved over. And once again, I mean in parallel, no sense in dropping the original client.

    1. Since the client is completely open source, if someone had the ambition, I’m sure they could work to port it into HTML 5. That said, it’s not within the scope of our project at this time, and I don’t foresee it being part of the project in the future unless things change dramatically enough to force it.

  7. I’m a web developer with a good amount of JavaScript experience and I’m a big advocate of HTML5 in general. However, I can’t see why people don’t understand this decision and how big an undertaking it would be to port the game compared to connecting up the pieces that Tiny Speck released and getting the original version working again.

    I’d love to see a new client written around web standards in place of Flash but I think the approach of taking the path of least resistance right now is absolutely the right one. So many projects like this are too ambitious and end up burning people out before they can deliver anything. From what I’ve read it sounds like you’ve made great progress already and I look forward to seeing Eleven up and running.

Leave a Reply