The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
As the year comes to an end, we at Lost Decade Games like to take a step back to see what kind of progress we’ve made. One of the (few) unique aspects about our game studio is that we have chosen HTML5 as our development platform, a highly controversial technology. Let’s take a look and see how HTML5 has served us this year.
How was HTML5 as a platform?
Technology is arguably the most important consideration when choosing a platform to develop on. If the tech is too hard to work with, it could compromise one’s ability to ship a quality experience. If the tech isn’t stable and robust, surely it’ll crack under the pressure of a large gaming audience!
The good news is that HTML5 on desktop is “ready” for prime time. Using the fantastic open source framework node-webkit, we’ve been distributing desktop binaries on Windows, Mac OS X, and Linux for most of this year. All of our video, audio, input, and rendering demands have been met by HTML5. Performance is reasonable, development is fast, and our customers’ feedback has been overwhelmingly positive.
I’m happy to report that our current mountain of problems on desktop has nothing to do with the technology, and everything to do with design, marketing, and distribution. The same problems everyone has!
To distribute our HTML5 games on Google Play and the iOS App Store, we use Ludei’s CocoonJS, which is an impressive and powerful product. Our HTML5 games work great for the most part, but performance can be a problem if your game is doing tons of computing or image compositing (which games tend to do). Simple 2d HTML5 games can be made quickly and efficiently, and distributed on native mobile stores. We’re very close to that “holy grail” of easy cross-platform development, and it’s pretty great.
HTML5 tooling has a long way to go. Flash developers are accustomed to having a rich IDE at their fingertips, and many of these developers making the move to HTML5 may be sorely disappointed by the lack of mature tools available.
We’ve been iterating on our own internal tools for about three years now, including a full-featured game engine, build scripts, and a skeletal animation editor. These things we’ve built for ourselves are good enough for our specific purposes, but studios new to the HTML5 scene will likely want to use pre-existing tools.
Regarding engines, ImpactJS was the leader of the pack in 2013, despite the $99 USD price tag. Phaser has been picking up steam as an open source alternative, and there are many other solid choices. The tooling has a long way to go, but things are looking bright for the future, with offerings like Intel’s XDK and PlayCanvas’s cloud-based IDE pushing forward every day.
How did we make money?
As with any technology, there are many different approaches to monetizing software. HTML5 doesn’t really have any limitations here, as it’s perfectly capable of supporting premium downloads, F2P with IAP, subscription models, or probably any other crazy scheme. That said, monetizing consumer products is hard, and this year it was worlds easier to make money with HTML5 games through B2B deals.
Below is a pie chart breakdown of our revenue from 2013:
Contracts are primarily what kept us afloat in 2013. This essentially equates to other companies that have either already figured out the best way to monetize HTML5 games or (more often) they are flush with capital and eager to experiment in the space. These contracts tend to pay similar to what we used to make as web developers in Silicon Valley, but they also take up the lion’s share of our time. It’s closer to “employment” than we’d like to be, and probably where a lot of indies find themselves these days.
There’s lots of interest in HTML5 from companies with money, and from what we’ve seen, they’re spending more on contracts each year.
HTML5 gaming portals are popping up everywhere. They typically pay a one-time non-exclusive licensing fee for a quality mobile HTML5 game, ranging drastically in price. From what we’ve seen, an individual license could earn between $350-$2k USD, depending on the quality of the game and success of the partner. (These numbers will likely decrease as more developers saturate the market.) Many portals offer revenue split only, from which we’ve never seen better pay than the one-time fee.
These licenses seem like easy money on the surface, and once in a blue moon they are. The vast majority of licenses, however, end up being bloody time vampires. Portals usually want support for a dozen or more devices, going back as far as Android 2.1 and iOS 3 (these devices are slow and have pitiful audio support). Since many of these portals are brand new, they tend to be very volatile. We’ve experienced companies switching contacts multiple times, pivoting away from HTML5, and even shutting down entirely during discussions.
These issues make it difficult to actually profit from licenses. Still, licenses were the easiest way to make money with HTML5 games in 2013.
Developing and marketing HTML5 games directly to consumers? Good luck! You’re in the same crowded market as the rest of the world. HTML5 has some advantages, such as being able to provide a demo instantly in the browser, but are demos even worthwhile for developers? We got a big spike in this category by running our Kickstarter for
Crypt Run A Wizard’s Lizard earlier this year. Additional sales have all come through Humble widgets and IAP.
What games did we make?
One way to measure the effectiveness of a platform is to look at how productive its developers have been. So what was our output from 2013? Here is an incomplete list of the games we made:
- Lava Blade (turn-based strategy RPG, launched via our own Humble widget)
- Rampart Rush (unreleased, got tied up in publishing deals)
- Retreat to the Jeep! (Indie Speed Run 2013 entry)
- Midtown Mayhem (unreleased, also tied up in publishing deals)
These games were developed while handling dozens of licenses and creating many prototypes to sharpen our skills and tools. Additionally, throughout almost the entire year we were developing A Wizard’s Lizard in one form or another. Any studio can always be more productive, but we’re satisfied with what we were able to build on HTML5 this year.
I believe 2013 was the year we started to see the gradual transition from experimental HTML5 games to production-quality HTML5 games. The tooling has a long way to go, but the money is there if you do quality work. Overall, it was a good year for HTML5 gaming.