A Free-First Approach: Thoughts On Mobile Game Monetization
I’m finishing up my first new mobile game in a while. I need to figure out how to monetize it. I wish there was a group or forum with other mobile game creators where I can talk about this stuff, but I haven’t found one. So I’ll talk about it here and maybe come to a conclusion. Or, maybe my thoughts will help someone else.
The most obvious way to monetize is to simply charge for the game up front. This was the original method, and has been around since day one. The problem is that with so many free and free-to-try options, you won’t get that many people to pay for something up front. Sure, if it has a big brand name in front of it, or you can afford to spend a lot on marketing, you can break through that. But for a small indie developer with no brand name content, you’ll just see zeros.
Soon after the app stores got going around 2008 or so, the second monetization method started up: advertising. This is what I use for most of my games. You allow a network, like Google AdMob, to place banners or interstitial ads in your game, the user is annoyed, and you get a steady income. This allows you to keep the game free, so more people will at least try it out. But it sucks from a design and user experience standpoint. Plus, the one network that did this really well, Apple’s iAd, doesn’t exist anymore. AdMob only pays a fraction of what iAd did.
Most big mobile games make money through in-app purchases. From a game design standpoint, you can have nice purchases like game levels or more content. But that’s not the model that really makes money. The big apps all sell in-game currency or objects. Often, you need these to advance, or at least advance quickly, in the game. The hope users get addicted to the game and then fork over the bucks. This works great when you have a ton of users and marketing money. It also requires a deep game with a lot of internal content. Small casual games can’t really do it as well, which is why it has never really worked for me.
So here’s where I am going with all of this. I have a new game to launch. I can just stick ads in it. Or. I can just charge for it. The first one may work, but I hate it and it really complicates the design. Also, when I first launch the game I can’t expect to have too many people playing, which means I won’t be seeing any real revenue anyway. So why not start with no ads, and then add them later if the game gets popular? This should increase the chances that the game is a success, right?
Or, if I plan on charging for it, I know it will be a failure right away. No one will pay $3 or even $1 for a game they have never heard of from a company they have never heard of, with no reviews. But if I start it out for free, I can always charge for it later, right? So why not start it for free, and if it fails then it would never have worked as a paid app anyway. But if it succeeds and gathers some reviews and downloads, then I can switch to charging for it.
Or, I can do in-app purchases. But that would require the development of a lot more content. I’ll need new game modes, features, etc. But I can start it out as a free app and then add all of that content later on. At that point I can start charging for the new content.
So all three monetization methods seem to work with a free-first approach. I put the game out for free. Then I can decide whether to charge for it, put ads in it, or add content. Heck, I can do all three. People that downloaded it for free can’t complain (though they will). And I can make one of the in-app purchases to remove the ads.
So a free-first approach is just the logical approach. But then why don’t I see it more often? Maybe I’m just not looking for it. Maybe these free-first games have already moved on to the paid/ads/in-app stage by the time I see them.
And there is one more advantage to the free-first method. There is a halo effect when a game does well. People will seek out other apps from the same developer, partially because the app store shows them. So if the game does well I should see an increase in ad revenue and sales from my other games even while this new game is free.
OK. I think I have talked myself into launching my new game as a free and ad-free app. We’ll see how it goes.
The iPhone X Is Not a Good Gaming Device
So I recently went on high alert after getting an email from AdMob saying that we all need to update our apps so the ads aren’t messed up on the iPhone X screen. This was a few weeks before the iPhone X existed in the world. But we only had 2 weeks after that release to make the changes. In the past it took Apple up to 2 weeks to approve changes, so this seemed like a panic situation.
I would get my iPhone X on Nov 3 and work all that weekend to update my apps so they didn’t violate this AdMob edict. The penalty for failure could be that AdMob kicks me out and my app revenue comes to a halt. So I even spent some time before Nov 3 getting ready by adding code to move the ad down a bit. But I could only do so much until I had the phone in my hands. A feature in Animate/AIR that allowed you to use the iOS simulator from Xcode was broken in the current version, so I couldn’t even guess as to the size of the “notch” at the top of the iPhone X’s screen or the depth of the corner curves. I just nervously tracked my iPhone’s shipment progress and waited.
Turns out, I didn’t have to worry at all. Apps that are not optimized for the iPhone X’s screen simply show in a rectangular window that fits well inside the notch and corner curves. It actually tries to maintain the screen ratio of the iPhone 6/7/8. So all of my games worked fine and the ads weren’t obscured. All that worry for nothing.
But I decided to update some of my games anyway. That way at least they used the whole iPhone X screen.
Well, it turns out the iPhone X is a horrible gaming device. The reason is it is a very vertical screen. Instead of 16 by 9, it is 19.5 by 9. Yeah, that tall.
I guess if I were to develop a game for that screen size, it would be fine. But I make games that have to work at the 4 by 3 ratio of the iPad. I can sometimes stretch them out a bit for iPhone users. But to go from 4 by 3 to 19.5 by 9 is … well, more than a bit of a stretch.
And it gets worse. No home button, right? So there is this new “home indicator” line that appears at the bottom of the screen. And by bottom, I mean the bottom at the current orientation. So a horizontal game, like most games, will have this line taking up 40 pixels or so at the bottom. That makes the remaining space even thinner. So you end up with something like 2436 pixels across and 1085 vertically. To put a 4 by 3 game in there means tons of space to the left and right are blank.
And the notch itself isn’t helping. To center the game, but not try to use the “ears” at the sides of the notch, means that there will be a corresponding blank patch on the right as well.
Now if I had one game that I worked on. One game that I poured my development hours into and maintained and care for. Well, then I would probably have separate screen designs for the iPad, iPhone 6/7/8 and iPhone X. I’d work carefully to optimize the design for each.
But I’ve got 25 games or so, some of which bring in only a few pennies. So I’m not going to do that. And I’m willing to bet that even big development companies with major games aren’t going to make a custom iPhone X design either. The result will be to make the iPhone X an even worse game phone.
New and Improved Isn’t Always Better
Can you spot the problem with the title of this post? “New and Improved” is just “Improved” as the “New” is redundant. So “Improved Isn’t Always Better” is the real statement. But the definition of improved is “better.” So improved is, in fact, always better.
But nonetheless this exact statement was one made by a player of my jigsaw puzzle game, which I just converted from Flash to HTML5. In doing the conversion, I made sure that it as, in fact, improved. Included every feature of the old game, added new features and options, improved the quality of the images, and by simply converting to HTML5 I made the game playable to millions more people who do no have Flash installed.
What this person really meant to say, was “I do not like change.” The new game is different than the old one. There’s a subtle difference in the shape of the pieces, for instance. They have been playing the same game for years and now suddenly it seems unfamiliar to them.
It is a valid feeling. And very human. I have dealt with as a developer all of my professional life. Make a change to software, and even if it is clearly an improvement in every measurable way, there are people who will complain because they don’t want change.
But things need to change. It is very obvious here, with Flash being more and more hated and approaching its official retirement, that I need to move the game to HTML5. As a mind experiment I think of this person in 4 years suddenly finding that the game doesn’t work for them anyway. “Well, you didn’t want me to change it, so I didn’t. And now Flash is gone and you can’t play the game.” Or, maybe they read a blogger who spews hate for Flash and decide to uninstall it to find themselves in the same situation, but sooner.
So as a developer, I’m the one who has to bend. I can’t ask the user to do that. So I explain the changes, explain why they are necessary, and leave it at that. If I can’t convince the user that the new situation is better, then I have to let them go. It know it will be better for a majority of the current users, and all of the future users. So I press on.
What Flash Means To Me
Many people are cheering the recent news that Adobe is discontinuing the Flash browser plug-in by 2020. People associate Flash with annoying web ads, dangerous security threats, overly animated sites, and pages that don’t load on mobile devices. They have many reasons to hate Flash.
But let me tell you what Flash means to me. It started back in 1995 when I began to use Shockwave (Flash’s older brother) to create web-based games and other content. Up to that point, if you wanted to create your own software and earn a living doing so, you needed to find a way to distribute it. Without a publisher and without getting into retail shops, your best bet was a meager shareware existence, which only worked for a handful of developers.
But once you could use browser plug-ins to put software on web pages, then you had instant access to a worldwide market of users.
I wanted to be a game developer. I wanted to make my own games, not work at a large studio. Shockwave, and then Flash, gave me the ability to create my games, put them up on my own sites, and then people could play them. It opened up a whole world to me. It gave me a career.
By 2000 I had switched from using the aging Director/Shockwave development environment to the new and growing Flash environment. This lighter plug-in eclipsed Shockwave and made my games available to even more players. Companies from all over the world would come to me and hire me to build Flash games. Sometimes it would be for entertainment, and sometimes it would be for an educational project. I had a team of about 10 working on these projects. I wrote three books on this subject that helped thousands of other developers create Flash games.
Our Flash games were good clean fun. They were the reason you were at a web page, not the annoying ads at the top. They provided countless hours of joy for people, and many of these games are still being played at my sites today.
Flash is very powerful. It is basically an entire development environment inside a rectangle on a web page. The more power something has, the more potential for being exploited. If Flash was just a video playback engine, then it probably could have been made very secure. But it would not have been a tool I could have used, and may not have made any impact on the web at all. In the end, Flash probably wasn’t as insecure as people thought, as long as people kept it updated. I’m sure Windows was a far greater attack vector over the years than Flash.
Another problem was that websites would use Flash when it wasn’t necessary. If all you wanted was one piece of information from a website, then having to go through a longwinded Flash animation at the start was annoying. But that’s a problem caused by the designer and developer, not Flash.
If you never played web-based games, then maybe you only saw Flash as an annoyance. If you bike everywhere, cars are just pollution-generating road hazards, right? But don’t discount the millions of people that played, and continue to play Flash games today. And don’t discount people like me that saw Flash as a way to create great content and earn a living.
There’s a Lot You Can Learn From 404s
So I made some changes to one of my WordPress sites recently that updated some of the URLs for some very old posts on the site. Nothing would have broken on the site itself, but if someone had posted a link directly to a post a long time ago, it could now lead to a 404 error. In fact, any reasonably-aged site could have broken links like this as things change over time.
So I thought about tracking the 404 errors with a simple script. Sure I could have accessed the server’s logs to do this. But I thought it would be easier to add some code to the 404.php page on the site and have a simple log of just the 404 errors, with just the information I needed.
Here’s the PHP code:
< ?
$url = $_SERVER["REQUEST_URI"];
$agent = " ";
$ua = $_SERVER['HTTP_USER_AGENT'];
if (strpos($ua,"Googlebot") !== FALSE) $agent = "go";
if (strpos($ua,"bingbot") !== FALSE) $agent = "bi";
if (strpos($ua,"DuckDuckBot") !== FALSE) $agent = "du";
if (strpos($ua,"YandexBot") !== FALSE) $agent = "yb";
if (strpos($ua,"Yahoo! Slurp") !== FALSE) $agent = "ya";
if (strpos($ua,"Baiduspider") !== FALSE) $agent = "ba";
if (strpos($ua,"Sogou") !== FALSE) $agent = "so";
if ($f = fopen(ABSPATH."404log.txt","a+")) {
fwrite($f,date("ymd H:i:s")."\t". $agent."\t". $url."\n");
fclose($f);
}
?>
So the bulk of the code looks at the user agent and tries to tag the biggest spiders out there. I wanted to know if any of these were still looking for old links. Having a simple “go” for Google and “ya” for Yahoo was a lot easier to read than the whole big user agent string.
So then I looked at this file after a few hours. I could see that some renamed URLs were going to be a problem, so I added rewrites for those in the .htaccess file. But I also uncovered some interesting things.
First, I noticed calls for an “apple-app-site-association” file, which I was missing. Turns out this is used when an app accesses URLs on a server. I have an app that does this, but for some reason I never realized that this special file would make things work more smoothly. Here’s all the info you need about it: Support Universal Links.
Also, there were hits for apple-touch-icon, which you can read about here. Look at the section entitled “Look ma, no HTML!” to see how to make these without adding anything to your web pages. The important thing to note is that anyone can turn any web page into a bookmark that appears on the home screen of an iPhone or iPad. You don’t have to have any app, developer relationship with Apple or anything. And a home screen bookmark will look for and try to use a variety of apple-touch-icon files.
I also noticed lots and lots of hackers/bots trying to do things they shouldn’t. They are trying to directly access things inside of plug-ins that I don’t have. I can imagine that they are trying to gain access via exploits. I’m learning a lot about what they are trying to do by just looking at what they are trying to access.
On a happier note, I saw a few 404 errors for things in a “.well-known” directory. That led me to learn about about Well-Known Uniform Resource Identifiers.
It was definitely worth a look to see which URLs were creating 404 errors. I’m continuing to gather them in a log to see what else I may find.