Tablet Screenshots

Tablet Screenshots

In July of 2015 I purchased (for testing purposes) a very cheap low specification tablet from my local K-Mart outlet (at 6am in the morning mind you).

It is a no name brand tablet with a very low speed processor (quad core) and low memory (512MB).  

Recently I have played my game on it (quick battles only) in offline mode (I refuse to connect this tablet to the internet for the simple reason that the hardware itself has built into its OS an advertising scheme that means everytime a new screen opens advertising pops up even on applications that don't include advertising - such as my game).  

The tablet is not great but is pretty good for under $100 - it plays the game though the load times are quite long which is to be expected.  It has a few issues with sound - the volume seems too low, and behaves differently than the audio volume on my Samsung devices (phones).  But then audio seems to behave differently on the LG phone I own as well (different entirely again - volume settings seem to be linear on some and logarithmic on others).

Having a larger screen to play with however is beautiful.  On the low spec tablet my game downscales textures and reduces the quality of the background nebula so that the game will run fluidly on a low spec device however they still look pretty impressive.  I have attached below a series of screengrabs from my tablet. In each of them I have played around with the camera settings a little to position it in a nice spot.

Here are the screenshots. I really like this game.

You will note I have mainly focused on two of the factions in the game, I really love the ships on those two factions (which are the factions in the lite version as well).

AI Flight Behaviours - A Learning Machine Part 2

Machine Learning Part 2

As of January 15 (today) I've had a look at the AI players' battle statistics to get an idea of how well they are performing.

In my opinion they are performing admirably well, more so now that one of my users won the campaign.

The AI players in my game, as discussed before, improve over time as human players play the game and the AI learns from the human players.

As such their percentage chance of victory in any battle hovers around 66%, about two thirds of the time the AI player will win the battle.  This is great - if a football team had a 66% chance of victory they'd be over the moon.

The reason for the high figures is because the AI in my game learns from other players.  When a human player does well the AI player copies the flight behaviours and settings of the quality human players and tweaks the settings slightly to add a bit of variety to the settings.

As a result, with one of my users playing the full campaign and winning easily, the AI has now improved and as I've seen in my back end stats - it is very difficult to win against now.

So the AI for my game learns - and it learns quickly.  It has rapidly become a tough cookie to beat.

Well done AI opponents, I am well pleased with your learning. A+

AI Faction | Battles Won | Battles Fought | Percentage Mars | 63 | 91 | 69 AioSenti | 58 | 85 | 68 EarthHope | 44 | 66 | 66 Hushami | 56 | 85 | 65 Outlanders | 51 | 82 | 62

Some Metrics and Comments About Rankings

Some Metrics

Here are some basic figures about my game that have come to light since making the full game free of charge to users.

The Lite version of the game has seen a daily install rate of about 6 installs per day - this has been fairly consistent with a slight increase over the 3-4 month period the game has been available for.

The Full version, since being made free, has had an average of 14 installs per day - also a consistent figure.

This is during periods when there is no advertising. The value spikes considerably when advertising is active. 

Each user appears to use the game for an average of about 2 to 3 days before ceasing activating the game.  The average user visits the front page of the game about 12 times during the lifetime of the game. (4-5 per day).

On average about 55 users play the game each day. This is of a total install base of about 160 - so on average one third of my users currently are active each day.

Some notes about monetisation strategies for this game.

Monetisation strategies typically require high volumes of users.  Either a high volume of users or a high activity with a moderate volume of users is required. As such - my game has neither (in my opinion) to be worth monetising.  

Unless the daily average users increased by a factor of about 30x it is most likely not worth the effort to place advertising within the game.  

Monetisation strategies such as IAPs are not of benefit either since the game is typically played for a short duration (a few days) and my design does not really cater to IAPs since there is nothing that really is suitable as a saleable item in the game.

What I have noticed however is that no matter what method I use for promoting and advertising the game - the organic install rates for both free and paid has remained fairly constant and consistent.  

In terms of ranking in the app store charts the game sits at what I consider about 4th tier.

The tiers that I have identified in the app store rankings can be broken down into the following:

Tier 1 -

50,000 installs minimum, most apps are above the 100k mark with many in the millions.

Tier 2 -

10,000 installs minimum, with most apps hovering around the 50k mark.

Tier 3 -

5,000 installs minimum, with most apps hovering between 5 and 10k.

Tier 4 -

Everything below 5,000 installs.

This is a rough guide to how the app store ranks apps. Note there are exceptions and sometimes these exceptions are very weird - especially in the lower Tiers (apps with 1 install in the 3rd tier sometimes, and apps with 10,000,000 installs in Tier 4).  

My own app currently sits in Tier 4. I estimate that without advertising it will take approximately 2 years to reach  Tier 3 and may never reach Tier 2.

Product Virality

Product Virality

The term 'virality' with apps, youtube clips, songs and so on refers to the explosive exponential spread of a product that far exceeds the amount of effort and money spent on marketing.

It may be derived with the following mathematical model.

dU/dt = Total Rate of Accumulation of Users = Rate of Gain - Rate Of Loss

Rate of Loss we have already shown to be approximately equivalent to -aU where a is a measure of the quality of the app. This is a rough figure.

For the simplistic purposes of this model we shall express the Rate of Gain as equal to:

b + cU where b is approximately constant based on app store rankings and so on, while c is related to the likelihood of a person sharing the product with a friend or another person.

Therefore we get an equation for our rate that looks something like this:

dU/dt = b + cU - aU

          = b + (c-a)U

Now, this first order differential equation will result in either an exponential curve that asymptotes to a flat curve or which exponentially explodes with time.

It all depends on whether (c-a) is positive or negative.

The meaning of (c-a) is the difference between the likelihood of the app being shared with friends to the likelihood of the app being uninstalled at any given time by a user.

So the key to having a viral app would appear that it has to be a product that is sufficiently high quality to keep 'a' small and sufficiently remarkable to have a high likelihood of being shared with another person.

For most of us mere mortals c is extremely low and a is small but not anywhere near as small as c.

The value of b is ultimately irrelevant with respect to a viral app although the ratio of b to a is the approximation of the equilibrium install value of a non viral app and so in that sense b matters.

Causing 'a' to be a low value is not too difficult as long as you are capable of making a quality product.

The real interesting thing lies in making something that has a non negligible c value - that is the key.

The difference is either a flat curve at equilibrium or exponential increase.

An Explanation of My User Retention Term

User Retention (part 2)

This will be a fairly short post but in it I hope to explain simply and clearly one of the terms in my function that describes rate of user acquisition (and loss).

In my function described earlier dU/dt = f(t) + g(m,e,t) - aU the term -aU may seem a little mysterious to some readers.

If we remove the first two terms that represent growth due to organic and advertising methods we shall look at the case where an app has been withdrawn from sale and no further promotion is taking place. In such a case the function becomes dU/dt = -aU

What this tells us is that the rate of loss of users is proportional to the number of users we have, by a coefficient of proportionality labelled 'a'.  

To understand it think of it much like radioactive decay which follows a similar mathematical model.

At a particular time there are 'U' total users with the app installed.  We do not know when each user will uninstall the app but we do know that it is a fairly random event - a user could uninstall the app at any time and the likelihood of them doing so at any given time is shown by the value of 'a'. Large values indicate a high likelihood, low values indicate a lesser chance of uninstall.

As such - the more users you have the more likely that at any given time 1 of them will uninstall the app.  If you double the number of users, by probability, you double the rate at which users uninstall the app.

This is what leads to the exponential decay curve those of you who are developers will see when you have finished a promotional period for a product as users gradually fall away and uninstall the app.

It is perfectly normal and mostly unavoidable. 

I hope that helps understand the model I use to describe app user retention and loss.

A Useful Metric

A Useful Metric

I was playing around with the numbers with my metrics and came across a meaningful calculation that I felt was quite revealing about the usage of games/apps (more so on mobile devices than PC but it would hold equally as well with these but the results would look different).

Typically things like DAU, MAU an stickability are thrown around along with D7 retention and so on.

This is a similar metric that is dead easy to calculate and gives away a fair amount of information on how your product is being used in the marketplace.

Take a particular period of time, eg 10 days.
Obtain the total number of unique users of your product in that time (separating by IP address while not a perfect fit will work)...eg 100 users.
For each day in that period count the number of unique users (use the same method, ie IP address - note any errors due to IPs being reassigned etc will even out in the wash)...eg

Day 1 10 users, Day 2 15 Users, Day 3 5 Users, Day 4 25 Users etc etc...sum them all up.

Divide the sum of your daily unique users (each day) by the total users for the period, call this figure D.

D is the average number of days, for the period, that users use your app for.

It will range between a minimum value of 1 and a maximum value of the period being looked at.

Something to note - this figure is amazingly stable. Unlike stickability which uses monthly active users - you can use figures from the entire life of your product to get an average value as most likely it won't change (once the product itself is stable).

The figure is similar in nature to the D7 retention and other figures like it and gives a rough idea of how engaged your users are with your product.

My own app has a value greater than 2 but less than 2.5. This means that most users use the app on the day of install, the following day and a handful use it the 3rd and subsequent days.

This is fairly normal - from what I've seen of various curves usage of games and apps is such that the fall off from install to inactive happens fairly quickly typically - especially on the mobile market, less so on desktop but it still occurs with a similar pattern on desktop.

So to summarise:

U = Total Users For Period
V = Sum of Daily Unique Users For Same Period (as U)
D = Avg Days Spent On App Per User = V / U

Simple characteristic to determine values - IP Address of User.

Results - Close to 1 = poor quality, Higher is better.

Stages of Development

Over the course of 2015 my game interface went through a number of developmental stages.

The first stage was my initial concept when I was putting the game flow together.  It was terribly ugly but was never intended to look pretty - it was merely the flow from screen to screen in the game.

The second stage was when I attempted on my own to make the game prettier. As a programmer I was pretty impressed with my programmer art.  It was still dog ugly though. See below.

In May a family member linked me up with a Melbourne based artist who took my concepts and reworked them into something a lot prettier. I am very thankful for the work Brandie did on my game. The financial cost was well worth it to get some professional looking graphics in my game.

I can very much recommend Brandie as a quality artist who is reliable and professional (and very supportive while I was in hospital too!)  Having professional artwork done makes all the difference to the quality of the final product.