Back in the 1980’s, when I used to spend way too much time playing games on my Apple IIGS (and earlier, my Apple IIe), one of my favourite games was Fortress, by SSI.
Fortress gave me a small game board where I would fight it out against one of several computer AI’s, where a game consisted of 21 turns, and whoever controlled most of the game board at the end was the winner.
One of the things I loved about Fortress was the way the AI’s got smarter with time. When you first started playing, it was easy to win, but after a few games, it became more challenging. This kept me coming back to Fortress as I felt I was playing against something that basically learnt as I did.
As a programmer/developer, my mind is rarely idle, and I always have a project on the go. In the 1994 I thought it would be neat to rewrite Fortress for the Apple IIGS, using higher resolution graphics.
I started doing this with the ORCA/Modula-2, which I had recently brought to the Apple IIGS with publishing help from The Byte Works and some connections at Apple.
As part of writing this blog post, I’ve run up my Apple IIGS environment (yes, I still have all of it) within the wonderful Sweet16 emulator and found that code:
I hadn’t realised just how much of the game I had written. I thought I’d only written a bit of the game logic, however it turns out I’d written a lot of the UI as well, as can be seen from when I ran it. The AI’s hadn’t been written but the basic building blocks were there.
The funny thing is, I have the code; I have a compiled binary that I can run, but I can’t remember how to re-compile the source code anymore. I’ve got a build script there, but my memory fails to help me out.
One of these days I should bring all that code out, and store it somewhere safer.
Around this time, I got distracted and much of my home based projects took a back seat, Fortress included. My work took me away from Apple development entirely for around 15 years.
So Fortress GS was left on a floppy disk (or two) in a box of backup floppies along with everything else.
Then, in 2012, after I’d been back developing for Apple hardware again for a few years I got the bug again, and, having recovered my entire Apple IIGS development environment from hundreds of floppies and some second hand SCSI drives (my how they’ve grown; did you notice the size of the “M2” hard drive above?), I was able revisit Fortress GS.
I ported the guts of the code to Objective-C and wrote a basic prototype to show to another developer at the time as a proof of concept. This one was really basic, but it allowed me to place moves for both sides by tapping the screen.
I showed this to a designer I knew at the time who thought the idea was great, but suggested that it would be more interesting with a hexagonal grid rather than the rectangular one.
I toyed with the idea at the time, but I did nothing with it; I had other projects happening, and I wanted to focus on my educational apps.
Moving up to 2016, and the release of the Apple TV, I launched my latest educational app, Tap Tangram (which I later launched as Classroom Math Drills), and due in part to my failure to recognise that I’d missed my target, and the complete lack of featuring by Apple, the app never gained any traction and failed at launch.
That left me wondering what to do next, and then it occurred to me to reboot the Fortress app idea once again. I’d also recently read a most-excellent blog article by @redblobgames about manipulating hex grids in software, so my mind was abuzz with what I could do with it.
Enter World of Hex, my latest, and final attempt to reimagine the classic Fortress for iOS and the Apple TV.
I started out just playing with the hexagonal grids code that I wrote as a port of the code provided by @redblobgames and getting the basic board working with the underlying move computations.
Once I’d done that, I sat down and brainstormed how I wanted the app to work; how the game would play and during this process, I asked myself:
“What if, rather than a simple rectangular grid of cells, we had a map of the world as a map of hexes?”
And then I got going.
“What if, the terrain was somehow represented in this 2D map of hexes. Rather than try to represent the 3rd dimension as a true 3rd dimension, colour the hexes to represent the terrain.”
and
“Hmm. how many cells?”
“Earths land surface area: 150,000,000 km2”
“If we say each hex has a real world “size” of 1km, then we need to be able to map out 150 million hexes eventually. Even if they aren’t all being used by players, we need a way to know where on the earth a hex maps to land.”
“So, what is probably easier, is to map the entire planet with hexes, and then mark some as usable land, and others as ocean, unusable land, etc. that means a lot more hexes in the database though. It means millions of hexes to cover the planet completely. too many.”
“Will performance be an issue? yes.”
And so it went; with performance an issue and no real idea at that point of how to make it all happen I went hunting for others that had build a world of hexes. I needed to get an idea of:
- Could I get the basic mechanism to work on an iPhone
- How many hex tiles would I need to build a reasonable approximation of the Earths land areas?
- How would it perform if I built a model with all those tiles?
After some searching with Google, I happened upon the wonderful Hexasphere.js by Rob Scanlon. This gave me hope. If this could be done in a browser, then I could do it.
So I set about to port his Hexasphere javascript code to Objective-C to see what I could achieve.
This is where I started to hit upon the boundaries of my knowledge of 3D modelling and SceneKit. I also found myself struggling with some of the math concepts involved, having to trust in these people that obviously handle it better than I.
I did get Hexasphere working, though it was extremely slow because every hexagonal tile was being implemented as a separate SceneKit node. It did work, but it just wasn’t going to cut it for a production quality game. At this point I was using very large hexagonal tiles, so the tie count was still quite low. Once I increased the resolution of the model, there would be a lot more.
I ended up posting a question or two on the Apple developer forums and the Games Stack Exchange. These helped me better understand how to improve the performance of my 3D model however I was still hitting problems in that the on-screen representation of the Hexasphere was not high enough quality.
I spent several weeks working on it and getting some great help from colleagues who knew math, and 3D rendering far better than I. The end result of that was a perfectly rendered Hexasphere using only 4 SceneKit nodes that rendered at a full 60fps on devices as old as the iPad2. The change was to put all of those tiles into a single model, and to colour them individually via the shader and it’s inputs.
I finally had what I needed to get on with the game.
At this point it was just a matter of bringing all of the pieces of the puzzle together and making them work well.
For this game, the main pieces were:
- The hexasphere code
- The Hex Grid code
- SceneKit and SpriteKit
- CloudKit (iCloud based database)
I’ve already spent enough time on the hexasphere and hex grid, so I’ll try to restrict the rest of this post to the hurdles I had finishing off the app and bringing it all together.
SceneKit and SpriteKit
Apple’s engineers have done a wonderful job of these two API’s. Having developed most of my apps with Cocos2D, the transition to SpriteKit and SceneKit was pretty painless. The primary difference for me was the coordinate system.
The main reasons I went with Apple’s frameworks this time were:
- I wanted to be able to render the 3D world, which Cocos2D wouldn’t do.
- I also wanted to branch out and learn something new.
That said, the trick was that I needed to be able to overlay my 2D game components on top of the 3D components. After a little research I discovered that Apple had kindly given us an “easy” way to do this via the overlaySKScene property of the SCNView class.
This works remarkably well however it does introduce some problems because there are bugs in the Apple frameworks (at least, there are at the time I write this). I found that there are some things, like animations of the SpriteKit nodes that need to be forced to be done within the SceneKit renderer thread. It seems that Apple use a multi-threaded renderer for SceneKit/SpriteKit and some operations that you’d expect to be thread safe, aren’t.
With a lot of help from Apple Developer Technical Support, I found and fixed this problem and filed a bug report #32015449 (github project) accordingly.
Another issue related directly to the use of overlaySKSCene was an incompatibility with the tvOS focus engine (it basically doesn’t work). I ended up having to port a focus engine I’d written for Cocos2D on tvOS and enhance it to work with World of Hex. I’ve also filed a bug report for this issue: #30628989 (github project).
Apart from this, SceneKit and SpriteKit work a treat and have made my life so much easier.
CloudKit and iCloud Integration
Once I’d decided to expand the original game beyond a single game board, and to allow people to play games in a world of game boards I needed a way to store the game boards in the cloud so that everyone sees the same thing.
When I started to develop this idea my family and I were enjoying Pokemon GO for the novelty it provided. As a user, one of the things I really didn’t like about Pokemon GO was the way it forced users to either associate our existing Google account with the app, or to create a brand new Google account just for the game. There were other options, but they all involved forcing the user to log into a specific account, just for the game.
So I looked at Apple’s CloudKit which is just one part of the whole iCloud service layer that Apple has been building and developing for years now. One of the beauties of CloudKit is that for every person using an iPhone or iPad that is logged into iCloud, an app integrating CloudKit will just work because there’s no explicit login required.
This is what I wanted. On the whole, the CloudKit integration was very straight forward and it does just work.
I really enjoyed the ease with which Apple have allowed us to define our database structure via the CloudKit dashboard, make changes and even migrate those changes from development to production environments painlessly.
If there is one thing that I found lacking it is that in the dashboard, there is no way to simply remove all existing data without also wiping the database model itself.
Conclusion
World of Hex has grown far beyond what I originally set out to write. It’s nothing like my original attempt back in 1994 on the Apple IIGS, and even my really early brainstorming of last year differs somewhat from what I’ve built.
One of the reasons I build these apps is for the challenge and to keep my active mind busy. I certainly don’t make much of an income from them (though, mind you, I wouldn’t complain), so there’s a lot of satisfaction in having an idea realised and released into the world. Yes it can be crushing when it doesn’t take off, but, as I mention in the credits scene within World of Hex (can you find it?), “Never Give Up”.
Learning some of the quirks of Apple’s frameworks has certainly been a challenge. Cocos2D has been wonderful to work with over the years, and in some ways it’s more mature and easier to work with than SpriteKit, however SpriteKit’s deep integration is hard to pass up now that I’ve learnt it.
SceneKit offers some pretty amazing functionality from my point of view. I remember, as a teenager back in the early 80’s having a book with some algorithms for 3D line art animation that blew me away at the time. Being able to draw a model in your fave modelling tool, drop it into Xcode and have it on a device screen in minutes is insanely great. For developers out there that think its tough work creating an app, you have no idea how spoilt you are.
If you’ve read through all this, then thanks for staying till the end. It grew somewhat longer than I’d planned.
Here it is, my World of Hex. I hope you take the time to have a game, and that you enjoy it.
World of Hex is now available in the App Store.
So, I’ve been working on the tvOS port of Tap Tangram (due out, March 17!) and have a few observations. As some know, I like to use Cocos2D for my apps; it gives me a huge degree of flexibility for building the UI and doing what I want in the app.
One of the things I’ve been doing in apps for the past year or so is providing a lot of configuration options for the player, and what I’m finding now is that the UI I typically build for this on iOS just doesn’t work on tvOS.
Tap Tangram Player Editor
For one thing, the focus engine on tvOS does not like to play with non UIKit buttons and so on. If I have a name field which tends to use UIKit under the covers, I end up with a single UIKit object on the screen, and the rest are my own Cocos2D buttons and switches.
Now, back before the new Apple TV went on sale, I put a lot of time into producing a focus engine for Cocos2D that mimics Apple’s engine (you’ll find it in the tvOS branch of Cocos2D v2.2
here). It works really well, and I’ve used it in both
GALACTOBALL and
Tap Times Tables. It’s not quite as clever as Apple’s one, but it works quite well and has a flexible API.
I’ve updated this API to work with the latest version of Cocos2D, and have been integrating it into Tap Tangram, however on this player editor, tvOS won’t play nicely because it wants you to do everything it’s way.
The end result is that the UITextField is given focus by tvOS even when I don’t want it to. Apple, for reasons of their own have made it really difficult to control the focus engine in our user interfaces. It’s all UIKit, or no UIKit, unless you can find some tricky workaround.
In this instance I have not been able to find a work around that is satisfying. It feels clumsy.
So what to do?
Write a brand new UIKit Player Editor, that’s what!
After mulling over my nice UI and wondering how to squeeze that tvOS square peg into my Cocos2D round hole I realised that even if I got it to work, my UI just didn’t make as much sense on the TV. I look at those switches, and I want to flick them. I look at the slider and I want to slide it. On tvOS, this just doesn’t make sense because it’s not a touch interface even if you are using the Siri Remote.
So I decided to start from scratch, and write a basic UIKit UI for the player editor.
As soon as I started to lay it out I discovered that on tvOS, some of the user interface features we know and love, are missing. There is no UISlider. There is no UISwitch. How was I supposed to put a toggle switch on screen if Apple haven’t given us one? I took a look at the Settings app on the TV. Pretty much everything is done via tables. Toggles are simple table cells that when clicked, toggle their state.
I can do that for all those switches, but what about the slider? Well, at the moment, it looks like I will have to implement this as a cascading picker so that when the user clicks on “Maximum Value” it will change to a simple picker. It means less flexibility for the user, but ease of use.
The up shot of doing it this way is that I no longer have to worry about the focus engine because tvOS will do everything for me. The down side is that I’m going to have this screen (or two) that although very functional and easy to use, it will not look in any way consistent with the rest of the app.
In summary…
So, either way I have to make compromises. Do I stick with my own look and feel, and find a way to make it work, or do I take the “easy” path, use UIKit and accept that it just won’t look as nice (in my opinion)?
I’ll continue to experiment as I move forward. Unfortunately, the main game screen of Tap Tangram is a really really complicated combination of scrolling areas, buttons, and tangram pieces that can flip, rotate and be moved. I can’t take the UIKit approach there, so whatever I do on the Player Editor screen, I’m still in for some fun.
I’m about to embark on a collaboration with another developer. We want to create something new and fun. One of the first things to crop up is the tools that we use. In the interests of documenting what I use, I thought I’d write it as a blog post for all.
One of the amazing things about software development is that we developers can be very passionate about what we use, and how we use it. Some developers love getting their hands dirty by doing all the hard stuff themselves. Some like the ease of point-and-click programming (and there are some of that wouldn’t call that programming, but we’re probably being snobbish).
Me? I’ve been around long enough now to have got my hands dirty on a whole bunch of things over the years. I started out with AppleSoft Basic on an Apple IIe, and progressed through a whole suite of tools and languages until the Apple IIGS was discontinued in the mid-nineties. I could go on about those days and the years between then and the current “App” development wave, but that’s not what this post is about (if you want to hear more about the “good old days”, then let me know via comments; if there are enough then perhaps I’ll take a stroll down memory lane).
I won’t attempt to compare what I use against what others use here; this is simply a write-up of what I use, and briefly, why.
I would like to point out though that this post is probably best for other developers, or budding developers. I will use terms and jargon here and there that won’t mean much to non-developers.
Programming
Perhaps it’s something to do with my age and where I’ve come from, but I like coding by hand. Don’t get me wrong, I’m happy for an IDE (Integrated Desktop Environment) to do some simple stuff for me, but for a lot of it, I’m more than happy to type things out from scratch. The act of typing in code, even what might be template code to others, connects me with what I’m doing; it’s an opportunity to construct the tapestry as I work, to think as I type. Having a lot of it done for me means that typically, I’m allowing the tool to dictate limits and sometimes, it’s own design, on what I am creating. Coding by hand means that the limits are my own.
For iOS App development, my coding environment of choice is Apple’s Xcode. This is a terrific, free, IDE that comes with absolutely everything a developer needs to code an app and submit it to the App Store. Now I say everything, and it’s true, but in reality there are things like images, icons, sounds, documents, etc that also help to make up an app, and creation of those falls to other tools.
Xcode is freely available from Apple at: https://developer.apple.com/xcode/downloads/
Apple has traditionally encouraged the use of Objective-C for all development. Most developers either love or hate Objective-C. I actually enjoy it as a language. When Apple introduced Swift in 2014, I was a bit surprised. I knew that lots of people don’t like Objective-C, but I didn’t think people would be so happy to see a replacement. Swift has so far managed to fail to capture my attention. I have no desire thus far to change; Objective-C works, and works well.
App User Interface
Apple, for the iOS environment pushes it’s own UIKit and I’ve used this in several of my apps. It works well, and it’s very powerful. I don’t however like to use UIKit for the educational apps, and games that I create. For these I have used Cocos2D. I’ve been using Cocos2D since it was version 0.99. It’s now up to version 3.3. Most of my educational apps use version 2.2 of Cocos2D, though future apps will most likely use version 3.3 or later.
If you want a copy of the Cocos2D version (based on v2.2) that I use, visit: https://pkclsoft@bitbucket.org/pkclsoft/accessiblecocos2d.git
This GIT repository contains an entire Cocos2D project that I put together to demonstrate the use of Apple’s Accessibility API in conjunction with Cocos2D.
Going forward, Cocos2D is now integrated into a new IDE called SpriteBuilder, which is freely available at: http://www.spritebuilder.com, SpriteBuilder provides a very powerful environment that allows you to design the UI of your app in a way that can be built for both iOS and Android. I have yet to test/try the Android side of things, but feedback from other developers who have used Apportable which has been integrated into SpriteBuilder, has been very encouraging.
To build an app starting from SpriteBuilder, for both iOS and Android, you will need the Apportable Xcode plugin, available from: https://store.spritebuilder.com/products/spritebuilder-android-plugin-starter
SpriteBuilder creates, from your design, and entire Xcode project that you can then add code to, and build for submission to Apple. They integrate well, and the powerful thing is that once you open up the Xcode project, you can forget about SpriteBuilder if you choose and hand code the rest of the app. I really is, for me, a good blend of the two.
If I’m building a UIKit app, then I do everything in Xcode.
Code Management
When I first started working with Xcode, I used “cvs” to manage and control the various versions of my code. It worked well, but in the years since then, the development world has moved on. These days, the trendy choice is “git”, and for me, it’s a good choice. It works well in a local environment, and I’m able to set up remote environments so that I can easily backup my code to a file server, or the cloud.
For code version control using “git” I used SourceTree, by Atlasssian. SourceTree is available for free from: sourcetreeapp.com It’s a great tool, very powerful and integrates beautifully with a cloud based service called BitBucket, also by Atlasssian. I use BitBucket because I can create unlimited private repositories for free, and it’s very handy for sharing code with other team members. I use SourceTree on my Mac to manage daily commits of code, and then push those commits to the cloud or a file server periodically so that I have backups.
Artwork
For a lot of my apps, I’ve created most of my own artwork. Until late last year I did all of this using a free app called “GIMP“. It’s a great tool, and for people, like myself, who work on a very low budget, it works well. It’s cross platform and there’s even a version on iOS called ArtStudio (though they don’t call it GIMP, when you look at it’s feature set, and menu structure, I’m convinced that’s it’s built from a GIMP codebase).
With the new version of Money Up, I moved to the Adobe Creative Cloud suite, and Photoshop. Whilst I enjoyed GIMP and became proficient using it, I now really enjoy the power provided by Photoshop and the higher quality outputs achieved by using Vector based shapes for the drawings. GIMP is a raster based editor, and as such, is unable to export cleanly scaled images in the same way.
Sound and Music
Before I mention the tools I use on my Mac to edit sounds and music I want to mention two websites I use to source most of my sounds and music:
incompetech.com – This is a wonderful site by Kevin MacLeod who shares a vast library of his original royalty-free music. I’ve used a number of pieces from this site; the ability to browse using a terrific filter makes life much simpler.
freesound.org – This site is a powerhouse, full of sound recordings. Be careful to observe the licenses attached to individual recordings.
For most of my sound editing, I use Audacity, a free and yet, very powerful sound editor. When I needed to clean a large number of sound recordings for Money Up however, I used Audition CC, part of the Adobe Creative Cloud suite. For me, it’s not as intuitive as Audacity however it’s very capable, and some things are easier to do.
I always export my sounds as “AIFF” files, but I don’t use those within the apps that are submitted to Apple. Most apps don’t need high quality sounds, especially for simple sound effects. What I do, is run a short script over all of my “AIFF” files, to convert them to “CAF” files which take up less space, but still sound just fine on an iOS device.
This script comprises:
#/bin/sh
FILES=`find . -name \*.aiff`
for F in $FILES;
do
DF=`basename -s .aiff ${F}`
echo "Converting ${F} to ${DF}.caf"
afconvert -d aac -f 'caff' -b 65536 "${F}" "${DF}.caf"
done;
Video Creation
I’ve previously written here about how I create my App Preview videos. Here is a link: http://www.pkclsoft.com/wp/creating-an-app-preview-my-way/
Dollar Up is now just over 2 months old. As a developer I’m especially proud of this app, not so much for what I’ve done within it technically, but for what the app can do for people.
The main reason I wrote Dollar Up was to help out. A teachers aid/assistant wrote to me and asked if I was in a position to write some apps for Special Needs students. Whilst I wasn’t able to do everything she asked, I was quite excited at the prospect of writing an app that had the potential to really make a difference.
So I came to an agreement with the teachers aid who provided a lot of input into the initial design and layout of the app that I would build it at no cost to her or her school, and provide her with as many copies as she needed. I got to own the app itself, and consequently any proceeds from sales.
Over the next 3 months I spent most of my development time (which means spare time as this is not my main job) putting Dollar Up together. My understanding was that there was a genuine need for an app that helps to teach basic money skills to people with learning difficulties such as Down Syndrome or Autism.
This was to be my first foray into Special Needs education. Over that first month I learnt a lot about what makes an app easier to use for people with special needs. Make buttons bigger, allow students an option to retry a question, etc.
One huge lesson was that my perception of what people can grasp and understand was centred around my own experiences. That is to say, I had no comprehension of just how much I take for granted in this world. The simple fact that some students couldn’t be expected to grasp or learn concepts like numbers over 10 rocked my world. More than one night I’d get an email explaining this sort of thing to me, and I’d turn to my wife, shaken and unable to get on with the programming. It takes time to absorb this sort of thing for me. Whilst I’m by no means the smartest guy out here developing apps, I’m so used to being able to do these simple things, that comprehending just how ignorant I am of those around me left me more than a little upset.
This learning experience did one thing; it galvanised my desire to do this app, and do it well. I wanted to make a difference, to help fill a gap in the app store, and provide Special Needs teachers around the world with a tool they could use.
In the past, with one notable exception, I’ve done all of the work on my apps; the code, the artwork, the sounds, everything. I work to a shoestring budget. Some say that my apps suffer from this; that if I spent the thousands they do on artwork I’d do better. They may be right. With Dollar Up, I decided to use my little income from the other apps in my portfolio to pay for voice work, and some artwork.
Initially Dollar Up was just for Australia, but it became clear that there was a demand for it in other countries as well, so I started researching where to get permission to use images of coins and banknotes from other countries. In some cases, like the UK and Canada, this proved to be a long process involving a number of emails and in one case phone calls to sort things out. Eventually I had the permission I needed. I never set out to make much money from Dollar Up so it was important that the various institutions understood that.
At release, on the 7th of February, Dollar Up supported 7 lessons with 5 currencies (Australian, US and Canadian Dollar, UK Pound, and Euro). A week later, I added a 6th currency (New Zealand Dollar) because I’d heard via @TheAppyLadies that there is a strong Special Needs community there. Since then, there have been 2 more updates, adding at least 9 new features the most recent of which is the ability to extend the app using the iPad’s built-in camera.
During the last few weeks prior to the first release, I distributed Dollar Up to over 30 beta testers around the world. This was invaluable, not just for fixing things and improving the app; it showed me that people really were looking for an app to help them teach their students or children money skills. It heartened me and confirmed to me that I had done the right thing taking the time to write Dollar Up.
On the day the app was released I remember having a coffee with my wife. During that coffee my phone was buzzing away with messages and tweets showing support for the app. It was an affirming moment for me.
In all of this my expectation was that by supporting all of these currencies I would see some interest from the key markets of Australia, US and UK. Whilst I included the Euro as a currency, I didn’t expect a lot of interest from Europe because the verbal/audio feature of the app is English only.
One thing to note; if you work with currencies other than “Dollars”, don’t let the name of the app put you off . If you select Pounds or Euros as your currency, then the app will intelligently use the correct terms through all of the lessons, both on screen and via the audio prompts.
What has surprised me the most is that the UK has proven to be the quietest. As the graph to the left shows, the US is by far the strongest market, but the UK falls into the bucket at the bottom.
Sales haven’t been huge, but I never expected them to be, and it’s not why I wrote the app in the first place.
I had however thought that the spread of sales would be more uniform. My hope with this post is that by telling the story of the apps development, I can try to give it a human side. I’d very much like to reach more people and schools with Dollar Up; I want it to help. If people don’t know it’s there, they can’t use it and it can’t help.
If you represent an English speaking school that uses, or wants to try the “Next Dollar Up” method to teach money skills then perhaps “Dollar Up” can help. If you’d like a promotional copy of Dollar Up to try, please write to me at support@pkclsoft.com. Explain which school you represent, what your needs are and if I can I’ll help out with a free copy or two. Of course, I only have limited numbers of these so I’d really prefer to provide them to schools where the potential to reach more students is higher.
A month ago I was riding high. I’d been through a wonderful weekend where I promoted my math apps via the wonderful App Friday and appadvice.com sites as a part of trying to launch my new game Claustrophobic.
I wrote about that experience in The Power of Promotion. I even spoke about it (rather clumsily, I might add) at a local Cocoheads meeting (video).
I’ve been really amazed at the longer term results of that promotion.
Whilst Claustrophobic has failed to capture the interest of the gaming public, both of my math apps (though primarily Tap Times Tables) have improved their sales on a day-to-day basis. Whilst I’ve not made any money at all from Claustrophobic, the act of promoting the math apps via App Friday and appadvice.com has paid off to the extent that my costs of development (apart from time) and marketing for Claustrophobic have now been covered.
To give you an idea of the before/after for my sales:
So you can see, that whilst I’m not getting rich, the difference is quite obvious.
After a couple of weeks with Claustrophobic in the store, it became quite obvious that I had to do something to try and get the game moving. I had got about 2000 downloads in that first week where it was free, but by looking at game center, I could see that people were uninstalling the game at a rate of about 10 per day. Not good. I wanted people to play it and have fun.
One user was happy enough to write a review in iTunes and provide me with some very useful feedback about the game. After some very detailed discussions online, I got to work and made a raft of improvements to the game play. This user was an experienced game developer and player, and the help was invaluable.
Here is an image showing the rather dismal rankings after launch. Certainly not the sort of graph an app developer wants after a launch:
So with a new version done, I readied it for release, and got it into the store. I then scheduled the app to go free on the 22nd of February, and let the kind people at appadvice.com know about it.
Whilst I wasn’t going to promote via App Friday this time, I thought I could get a good boost from appadvice.com and get the game in front of a lot of people. My hope was that they would enjoy it and get the word out.
Here is where it got a little frustrating for me. When we schedule an app price change, the price change starts in the first country to tick over that midnight boundary into the date we’ve scheduled. This makes sense, but it only has an effect if the people in that country notice.
All app developers know how important it is to get ratings, reviews and rankings in the US app store. Another thing that is important about that US app store is that it also has a huge infrastructure of support websites such as appadvice.com, 148apps.com, gamezebo.com, etc. These sites are all US focused, so when they say something, they say it in US time.
What does this mean? Well, even though Claustrophobic was free in Australia from midnight on the 22nd, no-one seemed to know. OK, so it’s my job to let people know, but hang on, isn’t that what appadvice.com was going to do? Well yes, but not in Australian time.
So for a whole 24 hours in Australia, nothing basically happened.
And then the US woke up…and so did the rest of the world…
Notice how clearly that jump is at midnight on the 23rd (Australian time)?
Now I can’t be sure exactly what time appadvice.com post their links and update their appsgonefree app with the new data, but it’s pretty amazing to watch an apps ranking go from nowhere to everywhere so suddenly.
Looking at this, we can see that in the US, Claustrophobic quickly jumped to around #55 in the Games/Action (iPad) and around #100 in Games/Action (iPhone). It then stayed there until the app went back to paid.
As I mentioned above, it was really quite frustrating to see what whilst the app was free for some time leading up to the US hitting the 22nd, there were plenty of other countries that simply didn’t know that they could get the app for free.
I guess that to a large extent this shows my lack of marketing skills, as it should have occurred to me to look for sites like appadvice.com in other parts of the world and coordinated things a lot better. Sometime on Saturday this hit me and I reached out to Kristin Heitmann of www.apppmedia.com, one of my friends in the ParentsWithApps community who had previously posted about experiences in Germany.
Kristin kindly sent me some links to app promotion sites in Germany, and I started working. Of the three sites I contacted only one actually responded, and that was APP gefahren
They were very quick to respond and offered to promote my app via a push to their customers. Initially the offer was as a paid-for service but after some discussion, they very kindly offered to do the push for free to help me out. My hope was that I would get a nice bump in Germany and I’d be able to give something back.
Prior to the push by APP gefahren, Claustrophobic had peaked in Germany at a rank of about #110 as shown below:
Once the push went out, there was a definite jump in rankings:
So whilst appadvice.com is great for high rankings in the US and other countries like Canada, it was clear that to get that extra boost in countries like Germany it’s just as important to have other sites like APP gefahren in on the action as well.
So what actually happened to the downloads? Did Claustrophobic got nuts like the math apps?
Sadly no, but I think that the main reason for this was nothing to do with how I promoted the game; I think it was more that it was a game. The whole “game” category in the App Store has soooo many more apps, and competing in such a large market is not easy at the best of times.
Education, as I’ve said before, is a much better market to be in just at the moment. The selection of apps in the Education category is far smaller, and it’s much easier to get noticed if you frequent the right sites, and make yourself known.
Getting visibility in the games universe is hard. Gamers are a tough crowd. They love their games; they expect a lot from them. There are some very impressive game houses out there producing awesome visuals that build up the expectations of the gamers. It’s not easy to get noticed in that environment without something new.
To be honest, I still think that Claustrophobic, whilst not in the league of a lot of other games out there, has something new; something I haven’t seen anywhere else. I still think it has potential (as does Jennifer Allen at 148apps.com). Version 1.1 saw a lot of changes, and the next version, 1.2 which I’m working hard on will bring a number of new features to the game as well.
So, how many downloads?
These took my ailing 1900 game centre players to just over 5000. As I write this, that is down to 4600 players, with about 110 players each day. It’s great to see people getting better scores; it shows that they are actually playing the game and playing it over and over. Apart from wanting to earn something from the game, I’m really hoping that people genuinely enjoy it.
So where to from here? Version 1.2 is moving along nicely. It’s going to incorporate a whole bunch of things that have been asked for by users via reviews (there are some truly wonderful reviews in iTunes, and by wonderful I don’t just mean positive). It will also become the starting point for an educational game.
I also have a huge new feature, but I’m not sure if I can pull it off technically. If I can, I think it will be a game-changer. Watch this space.
If you’ve found this information helpful, the please feel free to share, or to let me know via a comment. Here are a few links to people that have helped me out. If you’ve helped me and I’ve missed you, let me know and I’ll add you in.
