Flash Player: A Declining Asset?


I’m working at a technology startup and today I am talking to one of the founders. He looks at me and says, “Our main product is a declining asset.

This is the product that generates 90% of our revenue and pays both of our paychecks. It’s the one that made our company a success, put us on the map.

Uh oh.


If you watched the Digital Media section of Adobe’s recent analyst meeting, you know that Adobe is putting a lot of focus on HTML5. Their recent announcement regarding dropping mobile web browser support for Flash Player caused a lot of turmoil, too, along with a shift in direction for the Flex SDK, their enterprise app framework.

If you look at the marketplace and the technologies at play, it seems that Adobe has realized that Flash’s position in the marketplace is eroding, that the erosion probably can’t be stopped, and they need to treat Flash as a declining asset. Just to review, here are some reasons that Flash’s position is eroding:

  • The many 3rd party mobile, native, and web-targeted development tools like Corona, Moai, Unity and others.
  • Non-Adobe Flash runtimes like Scaleform, Iggy. Companies like The Behemoth have their own Flash-compatible runtimes, too.
  • And of course the big one – HTML5. It can handle more and more enterprise apps, animation/multimedia content, and 3D. Browser vendors are in competition but increasingly targeting Flash-like capabilities.

Long term, HTML5 and other non-Flash technologies are unlikely to go away. Adobe may as well be proactive about owning the space rather than fight an unwinnable battle to keep everyone on Flash.

One more point to consider: Flash is made up of three big pieces. You have the tools, like Flash Builder and Flash Pro. You have the runtime, like the web plugin, the standalone player binaries, and AIR for desktop and mobile. And finally, you have the platform itself – the file formats, AVM specification, compilers, and APIs that define the behavior of Flash content.

They are all independent to a greater or lesser degree. The only part that probably wouldn’t migrate to HTML5 is the actual runtime (but see Gordon). And Adobe has been rumbling about compiling AS3 to JS/HTML5 and supporting C via Alchemy 2.


Now, the funny thing about that conversation from four years ago is that, because of the mental label of “declining asset” we assigned, (at least) two interesting things happened. First, the company got acquired and tried to diversify into a couple of new markets. Second, I along with a few other guys left the company and went on to start a new one.

But the “declining” product continued to make more money than ever before. And in fact, it lives on today, despite the original company getting liquidated by its owner when the diversification strategy didn’t work out. So what does it mean, exactly, to be a declining asset?

I think “declining asset” is a label you put on something to help you make decisions. In Adobe’s case, the decision they made was to move their long term focus toward HTML5 and away from Flash Player.

There are some important things to keep in mind with the communities that develop around technologies and products. First, realize that the conversation is often dominated by the vocal minority – so what is said most often and loudest often doesn’t reflect on the actual needs of your user base. Second, realize that the people who post on your forums are emotionally invested in the product, have it as part of their identity, and they will be deeply unsettled by any signs that support is fading. Finally, realize that users often have a limited perspective. Community members are not tracking major market trends, they are looking at how they can meet their immediate needs (like getting contract work or finishing a specific project).

In other words, the community tends to act like a mob.

And I saw no better example of this than when I was on a group video chat last week and saw Flash professionals practically weeping, calling out Adobe representatives, demanding, threatening to break up, over these announcements. It was more like seeing your drunk friend vent over his ex-girlfriend than it was watching a group of well-respected developers discuss their future. Everything is in a turmoil, it’s the end of the world, everyone is screwed, etc.


Ok, but that isn’t actually the end of “Flash” as a whole. Probably. Even though it really sounds like it. Let me explain.

Adobe has a ton of outs from this situation that let them preserve their and your investments. The most obvious out is replacing Flash Player with HTML5. You export from Flash Pro or Flash Builder and it runs directly on HTML5. In fact, they have been inching towards this in different forms for a while now (the conversion tool on Labs, Edge, Muse, etc.).

Even if they drop AS3 and go with JS, their tools can still be useful. If Flash Pro can still create banner ads and interactive experiences for a large audience, who cares what the output runs on? Life will continue relatively unchanged for a lot of Adobe customers.

There’s also a more subtle out:

HTML5 has its weaknesses. Lots of them. But public opinion supports it. Maybe it’s just a Betamax vs. VHS difference. Or maybe HTML5 is doomed due to the conflicting goals of vendors and the difficulty of the implementation task.

Maybe HTML5 ends up being great for less demanding uses – like basic enterprise apps, ads, motion graphics, etc. – but can’t get it together for highly demanding and integrated stuff like games. Adobe can keep Flash around and focus specifically on the game use case – which, by the way, is also highly beneficial for non-game apps, since they tend to use subsets of game functionality – and get as much value from it as possible for as long as possible.

Between the games angle and inertia, Flash could remain relevant for years. It could even end up totally dominating that space for a long time to come, even as HTML5 takes over the bottom of the market, due to being able to be more focused and agile.


Let me add two caveats. First caveat: At some point you can only expect so much out of a platform – you can’t get a guarantee that it will remain relevant for ten years. Even proven, still-relevant technologies like C have had their death announced many times. At some point you just have to say, “well, N years more relevance is good enough and I’ll re-evaluate in a year.”

Second caveat: Maybe Adobe screws the pooch and that’s that. Maybe they cut too many resources from Flash. Maybe they don’t build good stuff on HTML5. Maybe they ruin everything. So don’t bet the farm. Make sure you learn a few different technologies well. It will make you a better developer, even if you still just do Flash work day to day. And you’ll sleep easier knowing that if worst comes to worst you have an out. I’ve never seen a successful programmer regret having learned a new language or paradigm.

I don’t think Adobe is making bad decisions, just difficult ones.

Bottom line: Flash is a declining asset, but declining assets aren’t dead or even out of the fight. Everyone needs to look at technologies on their merits and see if it’s a good fit for your needs. There are a lot of places where Flash will continue to be a good fit for a while to come – and the places where it is ambiguous deserve careful consideration regardless of Adobe’s stated plans.

(Thanks for reading! If you liked this article, please consider voting it up on HackerNews or Reddit)

Blast From The Past: Blitz3D Models in Torque

I found some old screenshots on a backup, and uploaded them to my Flickr account.

As I was filing them away, I looked back in my .plans at GarageGames and realized that I had never talked about it publicly. At least, the site search didn’t turn anything up. Well, I think it’s probably safe to do so now. 🙂

Way back in April of 2005, I wrote a Blitz3D loader in Torque for Adrian Tysoe. It loaded Blitz3D files, with all their texture and material data, and it did polysoup collision, as well. This was several years before I released the OPCODE-based poly soup resource, which I think is now (in some form) in the official Torque codebase.

Montage from Blitz3D Loader Work

I love seeing how graphics code comes together, so I thought I would share this with the world – you might like clicking through the images and seeing how each step changed things. By far the biggest pain point was parsing the (sometimes obtuse) Bitz3D format. The format might be a pain, but in the hands of a good artist like Adrian, it gave really solid results. This was all before shaders were mainstream, of course, but still – the sand had a nice specular highlight, there was lots of clever texture layering, and the whole thing was pretty fast to render.

The more interesting aspect to doing the B3D loader was the prevailing opinion in the Torque community at the time that loading a non-DIF/DTS format was impossible – as was deviating from the collision models those formats used (convex polyhedra mostly). I’m not quite sure where they got this idea, but it was awfully frustrating at times to see people beat their brains out on those formats when there might be better options for their specific situation.

Partially, I did this project to prove to myself that I wasn’t just bullshitting people when I said that writing a loader/renderer was easy (certainly easier than canceling your project because another format wasn’t working for you!). It took me a month or so of part time hacking to get it all together. It didn’t animate, but it was just for environments – DTS is actually an awesome format for characters, and the 3Space runtime is very tight, one of the best parts of Torque in terms of features. (Aside: I hope they get a good Collada->DTS converter as the main pipeline sometime soon!)

Two years passed before anyone put polysoup in without rewriting the rest of the engine to use some other physics SDK. Actually, I ended up being the one to integrate polysoup with DTS. :-/ I was surprised no one else beat me to it! I brute-forced it – every triangle as its own convex. Torque ran this approach like a champ as long as you didn’t feed it tiny triangles. Did the same trick again when it came time to write Atlas1 collision a few months later, but that wasn’t really “polysoup” in a meaningful way for anyone since it only imported heightfields.

It’s interesting to me that the current Torque maintainer (and all around good guy) Matt Fairfax wrote loaders for .3DS, Quake3, and Unreal formats, and the maintainers that came before me (Rick Overman, Mark Frohnmayer, and Tim Gift) have also done things of this nature (in fact, they are at least partially responsible for DIF and DTS). I guess you don’t get to hold the reigns of TGE unless you’ve written a couple 3d renderers/loaders.

I think in total I’ve done 4 loaders with renderers – Blitz3D, Chunked LOD (for Atlas 1), Atlas2, and OBJ. Really, OBJ doesn’t count. Every graphics programmer in the universe has hacked up a OBJ loader – from Carmack on down.

In conclusion? I guess there are a few morals to draw from this nostalgia-inspired post:

  • Keep shots from your old projects. It’s fun to reminisce! I have a few hundred shots from Atlas development that might be fun to write about some day…
  • Don’t be afraid to buck common knowledge and go out in a technical direction no one thinks is feasible. Try it small and if it works, keep going.
  • Do projects for fun! Good stuff will always find an opportunity for reuse – be it some code, or a technique, or even a fresh perspective. The ideas and techniques I came up with for this project ended up helping me for years to come. Working with Blitz3D’s format helped me see Torque’s approaches in a fresh light.


Edit: Adrian Tysoe posted on GarageGames about his side of this experience – here’s what he had to say:

Heh, I remember working on this with you. I figured they were the starting point for some of the later torque advancements. Just wish that the DTS had been updated to support more than 1UV. Was pretty fun to work with and performance was decent.

The worst part was trying to match invisible torque terrain collisions to .b3d meshes just to get the nice water blending around the edges. The terrain used the coldet collision for the actual character and weapons etc.

Was pretty neat and I enjoyed having 2UV’s to playwith so I could bake my own lightmaps in 3dsmax of gile[s], in many ways the most useful thing to make TGE rendering look a bit nicer.

Here’s a couple more pics the project Jeremy and I started using it.