A couple of weeks ago we moved to a new house and it has severely limited my ability to do much coding. The boss (my darling wife) has a list of jobs I need to do around the new place that is keeping me busy.
Whilst trying to keep up with the growing task list of jobs I have had a chance to reflect on a few items that have recently been bothering me.
Producing Android versions of my games
I first wrote Operation Typhoon specifically targeting Android. The main reason was I was more familiar with Java, I had just finished an online course on using LibGDX and also it seemed easier to actually get a game published to the Play Store compared to say iOS. I also knew that Joni Nuutinen was having some success publishing his wargames there. As an aside, if you like wargames then you really should check out his games http://www.conflict-series.com/ – they don’t look fantastic but the AI is good and he has a great range. His games are a major reason I decided to try making my own games.
To date Operation Typhoon has had just over 10000 downloads and about once a month I get an email from a player of the game commenting on how much they enjoy it. That is always a great motivator!
The problem is price. Android gamers do not expect to pay much for games and indeed many expect them to be free. The average price for a premium (meaning you have to pay for it) game is around the $2.99 – $3.99 range.
Operation Typhoon is free but that is not the case for Kursk – Battle at Prochorovka which is a bigger game with more quality and depth. I tried various price ranges in the first week of publishing the game but even at $3.99 I had very few sales (Less than 20). Also, I did not feel good as I was charging $9.99 for the iOS version and $12.99 for the PC version. Why should an Android user get it for so much less? At the moment the price is $9.99 on Google Play and I have had zero sales.
Therefore at the moment there is little incentive to support Android users aside from the goodwill it generates.
Producing iOS versions of my games
I had read that similar to my experience above with Android it was very much the same for iOS games. No one expects to pay much for mobile games anymore. This is the reason many of the big development studios now produce free to play mobile games but with in-app purchases or advertising. They know they cannot make money selling a game but they can make money with in-app purchases. I don’t believe that model would work with my games – what in-app purchases could there be (Maybe I could sell divisions!)? Also I don’t want advertising in my games. Can you imagine an advertisement popping up after every combat!>
So with the above in mind I was not expecting much from an iOS version of my game but since LibGDX allows me to produce one with little extra development cost I published an iOS version and priced it at $9.99 which matched the prices that Slitherine Games generally sell their iOS games for.
I have been pleasantly surprised by how well the iOS version of the game is doing. At the present time iOS sales make up 20% of total sales. Now don’t get the wrong idea – right now my games just about cover the cost to make them. If I told the wife I was quitting the day job and we were going to live off money from my games she would have me committed to a mental asylum quicker than you could roll two six-sided dice!
Using LibGDX
I really love LibGDX. It allows a lot of development control over how I do things whilst making it easy for me to write in Java and produce games that will work on Android, iOS, PC and Mac.
But since using it I have started to hit a couple of limitations – I cannot put my games into Microsoft store (Java-based games don’t meet their submission criteria) and I cannot use it to produce games for many of the other game platforms (PS4, Xbox etc).
Also with the lack of success on Android do I really need to use Java as my main programming language?
Should I look at something like Unity to develop my games going forward? I had read that Unity was not great at supporting 2D type games and in addition I read that Slitherine had hit limitations on working with the platform (https://www.pcgamesn.com/catching-up-with-slitherine-what-a-difference-a-year-makes) – its one of the reasons they are working on an in-house engine called Archon so they can have something better suited for wargame development.
I had previously looked at Unity but I didn’t particularly like the Development environment and it seemed like it was very heavily focused on 3D games.
In-game help
In the recent review (http://www.wargamer.com/reviews/review-kursk-battle-at-prokhorovka/) of Kursk – Battle at Prochorovka by wargamer.com one of the comments was “Documentation is dispersed. Basic game controls are explained on the first screen; terrain effects, unit information, sequence of play, and other controls are detailed in an on-screen slide show. Further details are in a Dropbox download, Steam community guide and patch notes.”. I actually did write a complete PDF on how to play the game and published this to Steam. However I don’t think anyone knows it is there. It took me a while to figure out where it was!
I do provide some in-game help but it’s not sufficient and actually hard for me to update due to the way I designed it.
My original intention was that I provide just enough help to get a player going. For that I think it works ok but its not enough for someone that likes to read a manual of instructions. In addition I want to provide support to non-english speakers and that means having the ability to localize the text.
I looked at the “Unity of Command” game to see how they provide help in game and actually they don’t – if you click on the main menu Manual option you get taken out of the game to a website where there is a PDF file to read.
Personally I would prefer a player does not need to leave my game to read the instructions. So I am coming to the conclusion I need to rewrite the help in my games and allow for it to be easily localized and editable. I can also provide a separate PDF version of the game either on my website or as part of the install of the game.
Operation Typhoon
As I have mentioned in previous blogs, I wrote Operational Typhoon to test the market for my style of wargames and to prove to myself I could write and publish a game. The game proved to be a success with these two objectives in mind but it has also now become the Poster Child for my games. Players of the game have told me they have brought Kursk – Battle at Prochorovka based on their enjoying Operation Typhoon.
This causes a problem for me. Operation Typhoon, whilst good as a free game, is not at the same polished quality as Kursk and could really benefit from an update to bring it more in line with the way my games look and feel. Its also free so any work on it does not directly generate income to cover development costs (such as graphics). However, indirectly it leads to income as I know that some players of the game go on to buy Kursk – Battle at Prochorovka.
So at the very least I need to provide it with the same menu system I have for Kursk – Battle at Prochorovka, the ability to auto-save games and a small tidy up of the map edges (remove the black hexagon edges). At a later date I should provide some AI (the most requested feature).
In Summary
Looking at what I have written above I am going to action the following:
- Drop support for initial releases of my games on Android. It’s just not economical to support the platform. Maybe after a couple of years of a game being available on other platforms I will feel more comfortable with releasing them at a cheaper price on Android
- Improve in-game help
- Investigate if Unity is now at a level where it can support my type of games and move to that as my development engine.
- During some downtime (I am thinking Christmas) update Operation Typhoon
