I had the pleasure of giving a presentation at the onGameStart 2012 conference in Warsaw, Poland. The title of my talk was “Insert Coin to Continue”. A gentle nod to the fact that lots of game developers do actually need paying in order to carry on creating great games! I wanted to share my experiences and results of working in the HTML5 game sponsorship market. The Flash world is well served by sites like FGL and blog posts detailing income and strategies. But very little exists for HTML5 games, hence the choice of topic for my talk. This article will cover most of my presentation for those who weren’t able to attend.
Client games vs. Indie games
As a company we develop HTML5 games for both clients and ourselves. The reason is both financial and practical. Client work simply pays better right now. And the more of it you do, the more doors it can open to other bigger and more interesting projects. In my experience this is no different to any other platform. But there are obvious benefits of making your own games:
- It’s your own IP! There is value in establishing a brand and common IP even in the relatively small scale sponsorship world.
- You can make anything. This is important – no matter how awesome your clients are you are always working within set brand guidelines. They’ll never really allow you to do truly anything you want. But when you build for yourself this restriction is removed. You have to be careful of course, as great as Dinosaur Chicken Rock III might sound to you, if you want to get sponsors it needs to appeal to the wider market too.
- There is the very real chance of long term income. I’ll cover this later in the article, but ad revenue and ‘game rental’ can build up substantially over time, where as most client work is a one-off payment.
The benefits are obvious. As well as getting to flex your design muscles in your own way there are significant long term benefits as well. Lots of companies started out by mixing client and indie work only to find that the income from their indie endeavors was enough to leave the client side behind (Nitrome are a good example of this). So let’s explore how you turn this passion into income.
Before we go any further …
It’s important to understand that from this point on we are discussing HTML5 Mobile Browser games only. There is next to no market (in my experience so far) for desktop HTML5 games. In that area Flash still dominates. I’m also not going to cover mobile apps made in HTML5 and then wrapped with a package like CocoonJS or Ejecta. If you want to go down this route then be my guest, but you compete with the likes of Electronic Arts, Epic Games, Square Enix and tens of thousands of other developers. Go fight that battle if you wish
So from now on you should understand we’re talking about mobile browser games and all the limitations that entails. If you’ve done any research into this area you’ll know about the issues we face on mobile platforms. Poor rendering speeds, browser UI getting in the way, unbelievably shit audio support (Web Audio in iOS6/Android resolves this, but not for the millions of handsets already out there). It’s a fragmented and difficult market to work in – so why on earth do we do it? Quite simply because it’s the only way to play games here and there’s a real demand for it as you’ll see.
Setting expectation levels to ‘realistic’
Given what I’ve just said about device limitations you had to understand what sort of games are in the market today. You’ll see a lot of arcade games, often clones of popular 80s video games such as Galaxians and Breakout. There are also a lot of Flash to HTML5 ports and these vary in quality tremendously. Our own games in this area are quite simple side-scrolling platform games or puzzle games. There’s a feeling that the reason most of the mobile browser games are so basic at the moment is because no experienced game devs are building on the platform. This is only partially true – the biggest thing holding us back are restrictions imposed by the devices themselves. The quality is definitely rising however.
Screen shots from one of our own IP games: Nutmeg
Once you’ve decided what type of game you’re going to make and have gone through the process of building and testing across multiple devices it’s time to sell it.
I’ve made my game, what next?
Now your game is ready there are a number of things you can do:
- Play the App Store lottery. As mentioned earlier you can wrap it and app it, cross your fingers and hope for the best. There’s a real issue with JS (and Flash) games on Android especially where if you don’t put it into the App Store / Google Play yourself, someone else will! They’ll steal your game from a site, put their own ads in and upload it. This happens all the time, so it makes sense to just beat them to the punch.
- Self Host it. Create a web site around your game, or if the game doesn’t warrant a site all for itself create your own mobile portal and put your games up there. Natural discovery, cross linking and social promotion can all lead to traffic and income from mobiles ads.
- License it to sponsors. Which is what the rest of this article is about.
What type of Game Sponsors are out there?
I’ve split the sponsor market into 5 key areas:
These are the most ‘traditional’ form and very common in the Flash world. Lots of sites that have considerable desktop traffic are noticing spikes in mobile traffic to their portals. And what do visitors get when that happens? Broken Flash content on most devices (and all devices going forward). These portals have started applying the same business model to HTML5 games as they do to Flash ones: buying non-exclusive licenses for fixed amounts. In the Flash world this is often known as “site lock sales” but it’s one of the primary means of income for HTML5 developers – lots of little sales adding up.
As an aside it’s worth mentioning here that there is absolutely no market at the moment for exclusive HTML5 games. You don’t get bidding wars for new titles like you do with Flash. Everything is non-exclusive based. You’re simply providing content for the portals – they don’t use your games for seeding or customer acquisition outside of their own sites.
Primary payment type: Fixed price non-exclusive licenses
These are similar to games portals except they are often operated by telecoms companies and network operators who charge their members a subscription fee to access their content, or include the cost within their phone bundle package. Your games are used as content on these sites, but because they are paying to play these companies will often ‘rent’ your game from you. So for every month your game is on their site they’ll pay you a fixed amount.
Primary payment type: Game rental and Fixed price licenses
This is a growing space in mobile browser games and there are several well established companies in this sector already. A distribution partner is a company that will take your game, agree an ad revenue split percentage with you, and then seed your game out onto their network. In Flash a similar model can be found at Mochi Media – the difference is that these companies carefully curate both the games that go out and the partners who receive them. They target certain genres of game to certain portals.
Some distribution partners allow you to use your own ad code in your game. For example in several of our games we use Google Ads and insert this into a hidden div element. We then insert the distribution companies ad code into another hidden div, and based on an agreed percentage we show/hide the div each time we display an ad in-game. The benefit of this is that we get paid by Google, not the distribution partner, and we know the stats are 100% accurate. Another benefit is that we can try different ad networks in the same game. So every time an ad is displayed on the main menu it shows an advert from Google, but an end of level ad might show an AdMob banner instead.
Sometimes the partner company handles all of the ads and you simply receive a revenue report from them at the end of the billing period. In this case they are responsible for paying you. There are benefits to each approach, but the one thing I will say now is that the mobile ad market is vastly different to the desktop one in terms of revenue. Engagement on mobile ads is significantly higher than desktop ads and our HTML5 games constantly eclipse our Flash game ad revenue every month, despite getting a mere fraction of the number of plays.
Primary payment type: Ad Revenue Share
Multiplayer and Social Services
There are two routes here. First of all are social networks such as Mocospace who look for games that have strong shop / virtual currency / in-app purchase elements. All those things most of us love to hate They will then share a percentage of that in-app income with you. Each site offers different rates and of course their own APIs to implement! The problem with this approach is that you need to build a game that real people are willing to hand over real money to enjoy. Obviously the simple platform and arcade games mentioned earlier don’t fall into this category. The game needs to be socially engineered from the start and have exceptional production values to make people want to part with their money on your in-apps. That doesn’t mean you shouldn’t try it, but please do your research first before embarking on a large build. My first question I’d ask any potential partner would be “how much will I actually make?” – get some real figures from them. If they can’t or won’t provide any, ask yourself why you think that is. If you’ve good (or bad!) experience with this in HTML5 games please leave a comment or email me privately so I can update this post.
Primary payment type: In-app Revenue Share
There is another growing area that I’ve combined into this section, but that may warrant splitting out as it becomes more established. That is multiplayer companies who want games for their networks. They have spent time building up an infrastructure and API and you need to integrate your game with that. Different companies have taken different routes – for example Gamorlive are tackling real-time 2-player arcade games, whereas FunSockets have cornered the turn-based card and board game market. Revenue works differently based on the company. Some will do ad rev share, some pay for the development cost as a one-off, others will even do a ‘pay per play’. Naturally your game has to fit a multiplayer model (most don’t!) and you need to arrange a deal that suits you up front, as all the APIs are different and none are trivial to implement.
Primary payment type: Ad Revenue Share and Pay Per Play
This is a slightly different in that you cannot plan for it, but it’s worth including. Basically a brand license is when a company has seen your game and thinks it will fit with a campaign they are running, so they pay to license the game from you. Sometimes you insert their branding or re-skin the game entirely, other times you just hand it over and they do the work. It’s worth listing here because HTML5 game developers who understand the mobile market are far and few between at the moment, so digital agencies and ad companies are having real trouble sourcing new games for their campaigns, so if they see one they like which is a good fit they can often pay well. This has certainly happened to me several times. Just make sure that it’s easy to find out from your game who made it – so a nice clear company logo on your menu somewhere, and a clear route to email you once they land on your web site.
Primary payment type: One-off brand payment
Yes, they have rules! They all vary but the following are very common requests from games portals:
- No outbound links! This is common in the Flash market as well, but essentially there should be no links in your game that takes players away from the portals site.
- No analytics. Very often a portal doesn’t want you to know how much traffic they get, so request that analytics of all kind are removed.
- No remote files. The game should be a self-contained package. I.e. a single js file, html and a bunch of media. It should not pull in assets remotely.
- Fire and forget. Very often you just bundle up a zip file containing the game, send it to the sponsor and that’s it. No further updates are allowed.
Now you can argue about any of the above points with them, and if you really needed to update a game after launch lots of them will accommodate this. But on the whole be shocked if any (or all!) of the above are requested from you.
Some other things they ask for, but which you absolutely should either challenge or ask for extra money include:
- Translation. If they want the game in a language you don’t have they should provide the copy deck and pay a little extra for your work.
- Highscore / Leaderboard APIs. This isn’t as prevalent as in the Flash world, but they do exist, and believe me some of them are TERRIBLE! Never agree to implement an API for free without first getting example code from them.
- Change the game title. You’ll be surprised how often this is asked for. Again either say no or ask for money to cover the graphics and code change.
Given everything said above how does it break down into actual earnings? Here’s a chart showing what a typical HTML5 mobile browser game can expect to earn. The game has to be of a good quality and/or a popular genre.
These figures are different to the ones given in my presentation because I came back and spoke to a number of other developers to get their results. I then aggregated them to get more of an industry average.
Some important points to consider:
- The Distribution and Rental figures are based over 12 months.
- The average non-exclusive sponsor price is $500. Some push for $400 and others will get you $1000, but on the whole $500 is about average right now. My original slides had a higher value here but it was skewed by a sponsor who’s not currently active (Spil) so I removed that and re-balanced it.
- There are no multiplayer or social stats in here, if you have some then please contribute.
What can we learn from this?
Well you’re not going out and buying that Ferrari just yet, but it’s definitely a real and viable source of income – especially if it’s supplanting client work. But there are some important points we can take away from this that I now adhere to when making a game:
- Keep your dev time low. Don’t allow more than 100 hours worth of build time per game. This ensures my average return per hour is $100. It doesn’t always work out like that of course, some games simply take longer than others, but if you’re planning on some monster epic project – think very carefully first, as it’s entirely possible you won’t make that money back again for a long time, if at all.
- If you outsource your art then make sure it’s cheap! Don’t spend more than $750 on art and make sure you work with an artist who understands mobile sizes.
- Quality matters. More and more developers are coming into the market and are pushing the quality bar up ever so slightly. Make sure you keep an eye on sites like marketjs just to see what other developers are making – and strive to be sure your games are that little bit better than the rest. If the genre is an old one then make sure the game is polished to perfection.
But my absolute biggest take-away should be that you ought to think long-term re: income. I’ve just 3 games released at the moment, but the monthly ad income and rental from those alone pay the mortgage every month and have done so for most of the year. Think about that for a second. It’s real tangible income and it happens while you’re asleep. I know that’s the “dream” scenario for any developer (no pun intended) but it’s not uncommon, several other HTML5 devs I know experience similar results.
Top Tips when dealing with Game Sponsors
Use simple English! A lot of the portals we deal with are not based in native English speaking countries. Keep your emails short and to the point – treat them like twitter! Especially if English isn’t your native language either. The easier the email is to read the more chance you’ll have of a deal.
Don’t haggle (much). If a portal says “we usually only pay $x” then think twice before agreeing. Stick to your guns and don’t be scared of walking away.
Use common sense. If something sounds too good to be true, it probably is. If you’re being offered a great ad rev share deal and all you have to do is integrate this horrendous API then do some homework first – ask them how much a typical game will earn or what their pay-outs were last quarter. If they can’t or won’t tell you then ask them for money to cover the API work.
Watch out for non-payers! This is hard as it only comes from experience, but there are plenty out there I’m afraid.
Remain professional. You represent HTML5 game developers as a whole when you deal with a company, so do so respectfully please
How the hell do I find these sponsors?
I covered this part in my presentation by explaining that I run a private forum for HTML5 game developers, where we talk about business leads and put up our list of sponsors for all to share. In my presentation I made an open invitation to anyone in the audience who wanted to join to send me an email. I’m not yet willing to make that same offer publicly as the forum thrives on being a small and close-knit community. But if you feel that you are an exception drop me a line and sound me out. In the mean time I offer you the following sites that you should investigate:
BoosterMedia. The biggest distribution network out there. Ad revenue based deals but exceptionally good returns. These guys are well worth talking to!
SoftGames. If you have a quality game, especially one that may do well in China, then contact them. Also if you’ve got a game with in-app purchases.
Kimia. They offer game rental deals and one-off license deals.
But make sure you have a web site and list your games on it! You’ll then get sponsors contact you. On average I get one new sponsor email every 2 weeks. Some of them never come to anything and some of them do, but it’s still just business sense to do.
This should get you started. Also keep an eye on Google News for large gaming portals moving in to the HTML5 or mobile space. AOL’s Games.com is a good example of a company doing this who are offering ad rev share and projected massive visitor figures, but they’re by no means alone.
I find this an interesting comparison to the Flash market. There is definitely the option to make bigger lump sums of money from Flash (exclusive licenses), I won’t deny that, but there’s also real opportunity to make equivalent money from an HTML5 game to a mid-tier Flash one, which is quite exciting really!
39 ResponsesLeave a comment
Make yourself heard
All about Photon Storm and our
HTML5 game development services
- Tutorial: Making your first Phaser game
- Phaser 1.1.3 "Arafel" has landed with a shadery splash
- My HTML5 Game Development In-depth session at the Montreal International Games Summit 2013
- Phaser 1.1 is released! New API docs, 150+ examples and hundreds of updates
- Phaser 1.0 and the journey we took to get there
- Wide-eyed, quacky, flappy, pre-school adventures!
- We're now Nintendo Approved Wii U HTML5 developers
- Our largest HTML5 game to date: Wolfblood: The Mystery of Stoneybridge for CBBC
- Assembloids comes to the Atari XE
- Whattaheck: The HTML5 demoscene
Filter our Content
- Cool Links
- Flash Game Dev Tips
- Game Development
- Geek Shopping
- In the Media