TLDR: As game makers, we should stop arguing about whether to use HTML5 or Flash and use the best parts of any browser technology to make the best games possible.
Just when I thought the whole “HTML5 vs. Flash” nonsense had withered away, a link to this piece of propaganda infographic percolates through my Twitter feed glorifying Flash as the clear champion in the realm of browser-based gaming. It’s no surprise, considering this was created by a Flash game portal, but I am not here to prop up either side of a silly debate. Rather I argue that treating these two intersecting technologies in diametrical opposition to one another hinders us from making the best games possible in the browser.
Flash is awesome.
Ever since the Flex SDK (well most of it anyway) became open-source in 2008, the tools for making Flash games have been available to anyone. You can use any text-editor to write your code and are not required to use the Flash IDE to compile or debug Flash SWFs. There are a wealth of libraries for handling physics and such, good documentation, and some great frameworks designed just for building games.
HTML5 is awesome.
The work being done to push the capabilities of browsers is really impressive. Looking back a year ago, it’s amazing to see how far browsers have come. JavaScript development is trivial, requiring no compilation and minimal tools. Heck, the browser itself can be your IDE. JavaScript has been around for so long and used for so many things, there’s quite a bit code out there to learn from and libraries to use. And work continues — rapidly — to expand the feature set of browsers.
Focus on creating the best experience.
What I propose is that we apply the principles of progressive enhancement to our use of browser technology to create games. We can see this already happening with the use of polyfills to “fallback” to Flash, Java, etc. when a browser doesn’t support a particular feature natively (e.g. Web Audio). This requires a bit more planning and always working with the lowest common denominator in mind, but in a sense we’re working on creating a flexible codebase that ports itself to various platforms, rather than requiring partial or complete re-implementations. I’m not exactly sure how this works, but I’m working through these challenges as I develop Dig Deep Dungeons, since one of my goals is to make the game playable on as many platforms as possible.
Years ago, being disappointed in a lack of gamepad/joystick support in Flash, I built an experiment using Pure Data to convert standard joystick input to Open Sound Control, and piped it into Flash using FLOSC. And it was awesome. We’re so used to thinking monolithically about what we use to make games (Flash OR Unity OR Canvas OR…) we’re missing an opportunity to make really interesting mash-ups in the browser that are greater than the sum of their parts. And we’re denying ourselves the ability to respond to an expanding audience on an array of devices.


