Category: Post Mortem

Post Mortem: Wicked Lair

Posted by – December 21, 2014

So here i am, almost one month after Wicked Lair launched on both the IOS Appstore and Google Play. I think enough time has passed to reflect on it and figure out what to take away from the whole experience. This will be lengthy post so strap in. (Or look at the index and just jump to the points that interest you – i wont judge)

Since i am sure some you want to look at game, here are the links to the store pages:

Google Play: https://play.google.com/store/apps/details?id=com.stefanpratter.wickedlair

IOS: https://itunes.apple.com/us/app/wicked-lair/id930146392?mt=8&ign-mpt=uo%3D4

Index

  1. What went wrong
  2. What went right
  3. IOS Appstore – Thoughts
  4. Google Play – Thoughts
  5. Downloads and Revenue
  6. Important lessons learned

1. What went wrong

Bit off too much for a first project. You read it again and again, when – especially small – indie developers write the post-mortem of their undertakings. “Ran out of time”, “Had to cut features”, “Underestimated effort required”. Even being very, very cautious when conceptualizing the features for the game, i still ran out of time in the end and nearly worked myself into a major burnout. I ended up cutting 3 additional dungeon types (20% of content) from the final release so i could keep my deadline (and my sanity). For those interested, the timeline i gave myself for this project was 4 months.

Monetization. I am on the fence with this one, but i am putting it in this section because ultimately i am fairly unhappy with the result. The approach of doing a demo model with full content unlock via IAP didn’t really scale enough and revenue as a result is fairly sobering (Check Section 5 for numbers). I am on the fence because i dont have different approaches yet to compare, but i have a feeling that ads or even charging up front might have worked out better in the end – considering the amount of press coverage and downloads the game got.

Leaderboards. The leaderboards are full of cheaters. All day every day. And while there are some obvious values that stick out like a sore thumb, Wicked Lair is a game that is fairly difficult to hard cap in order to get rid of those bogus entries automatically – that means i get to kick cheaters off the IOS leaderboards regularly.

Google play doesnt let you manage it at all – it lets you hide players, but they dont provide an interface for it in their dev tools which means you need to write your own solution for it using their API. In the end i decided i dont really care all too much at this point for it to be worth the effort, but i think its astounding that such an important functionality isn’t integrated in their developer console.

No tutorial. I made the mistake of thinking that a tooltip hint system would be enough to educate users on how to play the game, it is a fairly simple game after all – at least on the surface. Turns out that i am wrong and a tutorial would have probably gone a long way. I am sure a good part of the 1 star reviews the game got was because of people not knowing what to do.

2. What went right

The development process in general. I am fairly happy with how the development process in general worked out, thanks to unity. It is a robust engine that’s incredibly suitable for projects like these. I learned C# in the process – which is a nice side effect and could be useful in the future.

The artwork. Being a programmer, any artwork i produce that looks decent is a win. I am happy on this front, with reservations. Doing the artwork was a major contributor to my almost-burnout near the end. I can draw something that looks ok, but it takes me a long time, and that really drained me after a while.

Press Coverage. I think this worked fairly well. I emailed 6 of the major mobile game review sites and 3 of them did a piece on Wicked Lair. And while Touch Arcade didn’t do a review,Wicked Lair was number 1 in their Hot Games list for about 2.5 days. All the reviews were positive for the most part. I attribute the majority of the release date downloads to this. Also getting covered by 3 major sites kinda caused it to spread out to smaller review sites automatically.

Outsourcing Sound and Splash Image, App Icon. These two things are the only things i outsourced, and in both cases the artists delivered great results! The splash image was made by 2d-dungeon.com and the soundtrack was made by Schematist (you can find him on facebook easily – check him out).

3. IOS Appstore – Thoughts

Silly requirements and slow iteration. These are the two things i take away from the IOS submission process. All the media – screenshots, video etc. – needs to follow their exact requirements, which is ok in hindsight, but was extremely frustrating when going into it without being aware at first, because i already had a bunch of shit made that i needed to reformat to get them to accept it.

Furthermore for preview media, it seems to depend on the reviewer on what is acceptable and what isnt. There was one point where an update was rejected on grounds of the media not meeting their expecations, when it hadn’t really changed from the original submission – which was accepted. They did change their mind after i talked to them about it, but the whole thing still took three days to resolve.

In general the review process seems to take about 10 days. Which sucks when you discover annoying bugs that need to be fixed. I understand that their is a “priority submission” type of thing, but i think you only get to use those on game breaking issues.

In general i dislike the amount of time it takes, but it might not be so bad after seeing some of the issues i had on the google side.

4. Google Play – Thoughts

Nice developer tools, quick iteration, dumb rating system. Their developer console is great, and the ability to have alphas and betas for your apps is much more streamlined than on the IOS side (which they only recently introduced with their test-flight system) – it worked great in getting regular updates to a group of testers and help significantly in discovering bugs.

It takes about 2 hours to push an update of the app and have it be available for download in production. Which is great because it lets you iterate quickly, for bugs as well as new features. However – at least in my case – there is a fairly annoying downside to this.

Every time a new version is uploaded users get to rate it. With quick iteration it means users get to rate a lot (doesn’t matter if you just push a quick bugfix or something major), which generally speaking sounds like its reasonable. However it turns into a major issue when users start to abuse this to hold your rating hostage in order to push for their – sometimes inane – demands.

There is this one guy who at the point of this writing is responsible for about 17% of the 1 star ratings on the game, with every update he would demand that the game be made free and rate 1 star. I made sure to flag all of them as spam, but so far it doesnt seem to counteract it at all, meaning the average rating of the game has suffered just because of this one person. I dont even want to think about what several of these types of users would do. I emailed google about it and have yet to hear back from them.

5. Numbers

From Nov 25. – Dec. 20

November 25 - December 20
Store Downloads IAPS Sold Revenue (after store cut) Conversion
IOS 14700 909 $611 6.1%
Google Play 9295 490 $310 5.2%
Total 23995 1399 $921 5.8%

A lot of the downloads happened in the first week. After that it gradually decreased, now it gets downloaded maybe 300-400 times (both stores combined). Daily revenue (after store cut) has slowed to about $10-15. It will be interesting to see where it stabilizes out, if it stays $15/day for a while at least it’d pay for the unity license … which would be nice.

6. Important lessons learned.

There is a reason everyone tells you to be cautious about starting off too big – I think there is always going to be problems like that, unless you’re extremely generous with the time you allot to your project – e.g. take whatever seems reasonable to you and double it. Seriously. Things will happen that will slow you down. Things that you can’t necessarily control.

The monetization model i chose was flawed. So here’s the thing folks, in hindsight i believe the monetization model i chose was flawed and incompatible with the mobile market – at least in the genre i chose.

You are dealing with a customer base that has been educated to expect “free” to mean “free” with some in game currency purchasing thrown in. While i am sure that there are some legitimate 1 star reviews from folks that got frustrated by not knowing what to do, simply didn’t like the game or had some technical issues, i am also convinced that a good part of them came from people feeling slighted by me charging for the remaining content.

It’s almost like that by tagging the game as free and then asking for content unlock through IAP they feel like i wasted their time, they expected a free game with 100% of the content available to them.

It might be that i overcharged as well, im not sure about that. However most people that bought one expansion also bought the second one, so maybe not. I can’t say for certain – i believe those who wanted it for free would have complained either ways.

Do the fucking math. The harsh truth is that i could have seen that this monetization model is flawed had i done the math in the first place. I feel extremely silly about it now. The thing you need to understand is that by all accounts 5% conversion rate (eg 5 purchases made for 100 downloads) is fairly decent. So even with this decent conversion rate and purchases priced at the cheapest tier (0.99$) i would need around 2000 downloads a day every day just to be able to live off of it.

Let’s not even talk about recouping my expenses (about 3.5k not counting the salary i gave up by working fulltime on the game for 4 months).

I could have figured this out before hand. And so can you, so please if you are working on something right now, whichever monetization model you apply, do the math and be honest with yourself. Getting 2000 downloads a day in a market as saturated as mobile appears to be extremely difficult. I don’t say this to shit on your dreams, but to make sure you think about it.

Post Mortem – Solar Rocket

Posted by – June 27, 2014

feature

Post Mortem about the IOS / Android Game, Solar Rocket

Tools used: Unity3D, Photoshop, webgl

Time spent: 1 Week

Status: Just released to Google Play Store – Solar Rocket

Introduction

This was supposed to be a quick first project – getting my feet wet, so to speak. The main mission here was to get myself acquainted with the process of publishing an app to Google Play and the Apple Appstore.

I chose to make a simple arcade game where you have to navigate a rocket past asteroids and devious alien-laser-shooting-spaceships  to leave the solar system (and essentially keep going until you die).

Original? Hardly. But a good entry project :)

Why is it a good entry project

  1. Because i figured i could accomplish the required logic fairly fast.
  2. It didn’t require me to draw any sprite animation frames (besides an explosion and some exhaust flames and those are easy!)- which is a big deal since i do my own artwork, and not only does having to do animation take a shit load of time, i am also not very good at it.

Initially the plan was to use webgl wrapped in a native application to accomplish cross platform compatibility, but that became unreasonable halfway through the project, and i ended up switching to unity and starting from scratch 3 days in.

What went wrong – webgl woes.

So, as mentioned, my initial idea was to make the game using the webgl context of HTML5 canvas. My main reason being that i come into this from years of experience working on web applications, so naturally in combination with the prospect of easy cross platform compatibility, webgl appeared to be an attractive solution. I would write the game in webgl and then wrap it a native android / ios app so i could put it in their respective app stores.

Everything was well, and on the end of the second day i had a prototype of the game that was about 75% finished, it was performing reasonably enough on my HTC One – it wasn’t completely smooth but hovered somewhere in the 40-50fps range – that i decided it was time to start looking into packaging it for appstore release.

Android studio here i come. Getting the javascript files to load in their WebView element was easy enough.

First test – well that’s odd, this looks like its running at 10fps.

Thirty minutes of google-fu later it turns out that Google had introduced a new webview in KitKat 4.4.2 based on chromium that’s actually much faster than their old webview – however, for whichever reason they did not enable hardware acceleration for the canvas element, so my precious webgl game was wheezing really bad while running up a hill.

So not only was KitKat 4.4.2 completely fucked, but turns out there is actually quite a few web relative performance issues spread out through the various android versions throughout jellybean and kitkat (note: i didn’t actually test this, just quoting what i read on various more or less reliable websites in my search for a solution)

Queue CoocoonJS

So turns out there is this nifty solution called CoocoonJs which is a cloud based compiling service that will take your webgl/html5 game, render it in their customized webview – which is supposedly fast on all android versions >4 – and compile it all into a package you can then comfortably add to the app store.

Sounds pretty good, and after fiddling for a couple minutes  getting my code to play nice with their webview, i was ready for compilation baby.

Only i never actually got to the point.

There were a couple things which caused me to ponder long enough …

  1. They require a premium account in order for you show any ads in your game – which is setup through their API
  2. You don’t get the android project, but the final apk package.
  3. For some reason i felt really hesitant having to rely on this just to get my webgl working properly.
  4. Not sure how i feel about uploading all my shit to their service.
  5. I couldn’t get their canvas+ solution working at all (needed for IOS release) (it refused to load .gif files, changed them to pngs which made the whole app 10 times larger, and then it loaded the images but distorted and glitching)

… to be hit by this:

YO IOS got webgl?

Oh IOS doesnt even support webgl in their native webview right now. It’s planned for IOS8 tho, so rejoice.

At this point i was in full rage mode and decided to go to bed.

The next day i decided to give unity3D a shot. Things took a turn for the better.

What went right – Unity

So Unity. Before we get to the light at the end of the tunnel, there is still a couple issues:

  1. I don’t know C# and their javascript implementation looks quite different then what i am used to from web development.
  2. I don’t know C#
  3. I had 4 days left of the time i allotted myself for this project.

Daunting? A bit. Regardless seeing as webgl probably still needed a good year to be properly supported across a reasonable device range, unity – with its build to all platforms goodness – seemed like a good alternative route.

After a few frustrating hours of initial learning curve extravaganza i was well on my way, picking up C# on the way.

3 days later the game was published to Google Play Prod :)

What went right – Sounds

Sounds are a plenty in the Unity Asset Store as well as at sounddogs.com. In addition to that it also happened to be that one of my close friends had made an old soundtrack years ago (1999?) that seemed to fit surprisingly well.

So not only did the game end up with sound effects but also with a track of background music. Unexpected!

What went soso - Graphics

I am happy with the way the visuals of the game turned out, but in the end i was too slow to meet my deadline, so the game over screen looks rather horrendous :) At least i had time to make some funny graphics that were displayed depending on what killed you

.gameover-aliengameover-asteroid

Also i do like the way Jupiter looks when you fly past it.

jupiter-fly-over

To be determined – Difficulty

I have yet to see whether the difficulty is tuned right. Im not sure. I want the game to be challenging, leaving the solar system by going past Pluto should be earned by skilled “piloting”, but i am scared that it is a bit too hard even early on.

Right now getting to Jupiter seems fairly difficult.

To be determined – Google Play Services

So the whole idea of using google play services to provide leaderboards and achievements sounds very neat. Implementing it is also straightforward. However i did find it laggy at times – eg. unlocking an achievement would lag the whole game for a split second. Which is kind of annoying in any game, but in this kind of genre a split second lag can kill you especially when you are further in and difficulty is higher.

It might be worth it to implement an in house leaderboard / achievement system instead, doesn’t seem like it would take too long. Are there any other benefits to integrating google play services? I haven’t looked.

Closing Thoughts

All in all i am happy with the final result. I will probably stick to unity for a bit, i quite like it. My heart still beats for webgl as well, but i feel like it might not be quite where it needs to be yet.

I was impressed with the way the Google Developer Console was set up, it seems very well integrated, from allowing to set up alpha / beta testing for your app (through google play store) to error reporting for crashes and application-not-responding errors.

Next i need to figure out how to build for IOS and windows phones. Then i need to look into marketing options. As of this writing the game has been released for 12 hours without any downloads. Which was to be expected, as there is a ton of competition, with lots and lots of new apps entering the playingfield daily

Expect further updates on how the game is doing and what i am doing to get the word out in the future.

Thanks for reading :)

Posts about Solar Rocket