tldr; my first iOS game made me $35k

Hmmm. So all is quiet in hiive HQ right now while I take care of the (non-game) projects that actually pay the bills!

I've also discovered that I'm not very good at writing blog posts when I don't have much to write about. That should change soon, as there are two fairly exciting things in the pipeline...

One is that my friend and colleague, Joe Hall, has taken it upon himself to convert Creatures & Castles to Android. That's the best kind of conversion work! The kind that doesn't involve me lifting a finger!

Secondly is that I am in the process of planning for the next game, codenamed Creatures & Castles 2... (original, I know). Hopefully, I should be able to build upon the modest success of the first game to make sure that the second game is even better... During the process of writing the first game I learnt a lot about the importance of polish - especially in the iOS space.

As much as it pains me to say it, Creatures & Castles was rushed. I had a limited time-frame in which to get it complete and out of the door, and it wasn't until about version 1.5 that the level of polish started to approach what it should be. I'd still like to go back and revisit it to increase that, and I probably will. Joe has some great ideas for the Android version that - should it come to fruition - I fully intend to backport (or at least get Joe to do it for me, because I'm a lazy ass).

Anyway, here's a snippet of information for those that like iOS financials:

Not including the value of my time, I'd estimate that I spent about $7,500 of my own cash producing Creatures & Castles. Most of this was spent on art and tools, with a small amount spent on music and incidental advertisement.

As of today, the revenue received from the App Store is $2,622 - not a huge quantity, and in fact it represents a net loss of approximately $5,000. However, thanks to winning 2nd place in the 2010 Best App Ever puzzle game category for the iPad version, the game attracted outside interest that directly resulted in an additional $40,000 worth of revenue. I imagine that this is the exception rather than the rule, but overall my first iOS game made a raw profit of $35,000. Now, if you factor in the value of the time I spent on it, that rapidly trends to zero, but seeing as it was a spare time project, it did okay... If I could repeat that kind of performance a couple of times a year (with the associated exponential increases due to increased public awareness of hiive games), I think I could make a living on it. For the time being though, I will not be giving up the day job.

At this point, I will leave you with a sneak preview of the two versions of the main character art from the pending sequel.

 


Which version do you prefer?

Accelerating ImpactJS With WebGL

First of all, I want to say that I am not claiming any significant credit for this. The cake was already for the most part complete. I just spread a little icing and added a cherry on top.

One of the problems with the implementation of HTML5's Canvas on the Mac is that it is not hardware accelerated (at least in Chrome, which is what I test with). Consequently, all of the drawing to the canvas is done in software, which is a shame seeing as on most computers there is a perfectly capable graphics card sitting idly by while the processor does all of the work. The end result was that my top-of-the-line MacBook Pro struggled to get 30-40fps which a two year old crappy laptop running Windows (which has a hardware-accelerated canvas in Chrome) got a smooth 60fps. Hell, even Windows Chrome running in VMWare on my Mac got 60fps.

Creatures & Castles for the Chrome Web Store uses the ImpactJS framework, which has a rather useful plug-in system to override and replace core parts of the functionality. A while back, the creator of ImpactJS tweeted that he had played with Corban Brook's WebGL Canvas Wrapper API created in Javascript. The only catch was that it did not support alpha. Luckily, there was a fork here by FuzzYspo0N (Sven Bergström) which had implemented limited transparency in an older version of the original project.

It was simple enough to look at the shader modifications in the alpha-enabled version and apply them to the absolute latest version of Corban's original. I even extended the alpha support to other drawing types supported by canvas (e.g. line and shape) so that the alpha was respected by all of the API calls (at least all that I have tested). Okay, so that's the icing... How about the cherry?

I extracted the plugin from the ImpactJS demo game here, but I wanted a plugin for ImpactJS that would automatically probe to see if the browser supported WebGL and fall back to standard 2D if it did not. Well, with the current implementation of the WebGL wrapper, it throws an exception if WebGL is not supported. (Note: I'm not to keen on using this as a detection mechanism, and may well improve this in future). In any case, with all of the browsers I've currently tested it on, the plugin has the desired effect of using WebGL if it's available and falling back to Canvas2D if not. It's a bit quick and dirty, but it works.

The end result? A smooth 60fps on my MacBook Pro. Hooray!

The code can be found here. Suggestions for improvements and any bug fixes are welcome!

Just for completeness, here is the obligatory before and after comparison:

Before (standard Canvas 2D)

After (WebGL)

A Few Words on Polish

I wasn't kidding when I said that preparing to release a game is almost as much work as developing the bloody thing in the first place! For the past few hours I've been creating banners and incidental graphics galore!

Large Advertising Banner

Small Advertising Banner

As I stated in the last blog post, Google need to work on their Chrome Web Store upload process. That's not to say it's bad by any means, but it could use a bit of polish.

Polish; now there's a word. One of the things that I discovered while I was working on the Web version of Creatures & Castles is that you only really get one shot at polish. A nebulous concept, difficult to define it may be, but we all know when we've played a polished game vs. an unpolished one.

With the iPhone version, I had a limited period of time (two months self-imposed deadline) to get the product out into the app store. As you can imagine, the first version that got out there was pretty rough around the edges. But "That's okay," I thought. "I'll add polish in future updates."

There are two things wrong with that. One is obvious; You never get a second chance to make a first impression. By the time I'd released it, it was pretty much too late to add polish. For maximum impact, the polish should have been there first and I should have delayed the release until it was.

Secondly, and this one is a little less obvious; by the time I got to adding in polish, I made the classic mistake of getting confused between polish and features. I added new and shiny features to the game without taking the time to really round off the ones that were already there. From discussion with other developers, I've come to the conclusion that this is fairly common.

Not only that, but to really polish something, it has to be planned in from the beginning. It's not something that can be crammed in at the last moment without a fair amount of re-architecting. That was a mistake I made with the iPhone version. I learnt from that mistake and did not repeat it with the Web version, which has a lot more polish. It's still not perfect, but nothing ever is. Given unlimited time and resources, I could have polished it much more.

Still, we learn from our mistakes. As I'm always telling my son: "Smart people learn from their mistakes; smarter people learn from other peoples' mistakes".  So when it comes to polishing your game, learn from my mistake... Plan it in advance.

The Language Barrier

If you look closely at the right-hand side of the above image, you will note that Creatures & Castles is available in several languages. That's not strictly true - there's really no change to the in-game text as of yet. No, currently the only thing that has been localized is the web store listing, and that's because I've been advised that it's a good thing to do for visibility. Well, I suppose it is! 

However, up until a couple of days ago, I had no idea how to go about getting my stuff translated into a handful of languages in a hurry... I mean, I've got a bunch of friends and family around the world that could cover some of the bases, but that would have taken a while to orchestrate. Meanwhile, I'm supposed to be going live this Tuesday!

By some bizarre coincidence, a routine sweep of my inbox turned up an unsolicited email I'd received a few months back offering translation services via this company. Normally I delete this kind of crap, but for some reason in this case I didn't... Probably because the guy who had emailed me had taken the time to look at my game, figure out how to contact me, and suggest what needed localization, as well as offer of a discount to get me started. (Basically, if you're going to send me unsolicited email, and I happen to need the services you have on offer, this is the right way to go about it).

Anyway, to cut a long story short, $90 and two hours after I signed up for the service, I had my store description text (144 words) translated and independently proof-read in five languages. Most impressive! Hopefully all of the text is correct, as short of further independent checking, I'll not know until it's in the store.

This is the way the internet is supposed to work! I need something done, I find someone to do it, and a couple of hours and a few dollars later it's done. Awesome! 

Readying the launch

I'd forgotten how getting ready to launch a game was almost as much work as writing the bloody thing in the first place - particularly on a new launch platform that I'd never used before.

In this case, the platform in question is the Chrome Web Store... Much like other Google products, it lacks the polish that other more 'consumer-experience-minded' companies (such as a certain fruit-themed computer manufacturer) have achieved, but nonetheless it's serviceable.

Prepping my app for test was simply a matter of adding an icon, a formatted JSON file and then zipping it and uploading via a fairly simple dashboard. On the whole, it all went pretty smoothly except for a few minor things...

Firstly, everything was crammed onto one page; it was a little confusing seeing what I was supposed to fill in where (but maybe that's just me getting old and frazzled). My feeling is this should have been spread over a number of pages.

Secondly, while the upload instructions were fairly simple, they kept referring to a crx file (even though I was uploading a zip file). I gather that the zip file is turned into a crx file by the upload process, but this wasn't exactly clear...

Thirdly, it wasn't clear at any point whether I was making a 'hosted app' or a 'packaged app'. It turned out I was making a hosted app, but none of the links I turned up were particularly helpful for turning it into a packaged app. The link I did find that told me how to change the manifest file was singularly unhelpful, as it did not explain how to troubleshoot errors.

So for now, Creatures & Castles will be a hosted app. Hopefully, I'll be able to get it packaged up soon. As it is the Chrome Web Store upload process could use a bit of an overhaul to make it clearer what's going on.

Lastly, there is apparently a bug in the developer test install process. My app refused to install from the Chrome Web Store test page. A bit of creative Googling told me that this was a known bug, and the trick to fix it was to remove the '/developer' part of the URL.

Gripes and Complaints

In just under a week, assuming all goes well, I'll be launching a version of Creatures & Castles on the Chrome Web Store.

For me, this was very much a learning experience. And as part of that learning experience, I can report that HTML5 in combination with JavaScript is very very close to being ready for primetime.

Almost, but not quite... As far as canvas support goes, Google Chrome, IE9, Safari and Firefox 4 all seem to have the bases covered. I ran into no significant cross-platform issues. Performance was more than acceptable - especially on Windows - even though I was making fairly heavy use of alpha blending. It's a shame that Mac Chrome doesn't offer hardware acceleration on the Canvas.

The biggest hindrance to the development of the game was JavaScript itself. Being more used to strongly typed languages that enforce data types, program structure and variable names, the freedom offered by JavaScript is more than enough rope to hang yourself with; for Creatures & Castles I was fortunate in that I had a version of the game written in a strongly typed language to as a template. Apart from that, I'd have to say that if the web version of the game has a class hierarchy, it is enforced only in my head.

There are tools such as Monkey that provide a more structured language (and can export to a number of target platforms including HTML5). I did not have time to test this tool, but the results look quite promising. I suspect it will be more useful as a prototyping tool than anything else. However given the pedigree behind it, I wouldn't be unduly surprised to see it used for more.

What Is really needed is for JavaScript to be given an industrial strength overhaul to add true object orientation, type safety and polymorphism. Personally, I would love to see something based on C# used as a JavaScript replacement, but I don't think I'm likely to be seeing that any time soon.

Coloring Fun...

If you read my blog posts about tinting you will know that I spent an inordinate amount of time ensuring that the color tinting of graphics looked about right as compared to the iOS OpenGL version.

For some reason or other (i.e. the information just isn’t out there or – more likely – I couldn’t find it) it’s very hard to find details of the exact color blending/tinting algorithm used by OpenGL. Any information that is out there doesn’t produce results anywhere near what I expected to see as compared to my existing iOS app.

This began a fairly protracted period of trial and error to see if I could at least approximate what I was seeing with the OpenGL blending.  I searched for information online and tested out several different algorithms and their variants, but nothing seemed to look right. In the end I sat down and worked some things out from first principles and – after a bit of tweaking and discussion with techie friends – I ended up with something that closely approximated the OpenGL effect.

As development of the HTML5 version continued, and managed to port across more of the levels and thus got a much better idea of how close the tinting approximation was. As such, here is a comparison of the iOS OpenGL-based tinting (left) versus the HTML5 Canvas-based tinting (right). I don’t think I did too badly at all:

iOS vs Web – Control Issues

With the iOS version of Creatures & Castles, the control system was pretty much decided from the start. As I mentioned previously the high concept for the game was “Flight Control in a maze” so it was clear from the outset that the game would involve dragging a path for the main character to follow. And so it did, with some additional refinements added later due to beta tester feedback (such as restoring the last drawn path if the player died, and allowing players to undo a portion of a path).

The Web version presented a different challenge. I’ve covered this in a prior post, but to recap; clicking and dragging a mouse pointer is not a comfortable control method for an entire game. For this reason, I chose to have the player click and set waypoints along a path instead of having to drag out the entire path.

This process worked pretty well, but there still seemed to be something missing compared to the intuitiveness of the iOS version. In order to remedy this, I asked my artist to create some context sensitive icon overlays for display over the cursor when certain actions could take place.

 

From left to right these are: Cancel Remaining Path, Set Waypoint, Use Object, Take Object, Emergency Stop and Go. Of these, the only one that has no corollary in the iOS version is the Emergency Stop. For some reason, when designing the iOS version, I had it in my head that the player should – for better or worse – be forced to continue on the path once they have started it. With hindsight, this was a mistake; it served no purpose other than to prolong any mistake the player may have made and force them to quit and restart the level. Better instead to give them the additional option of performing an emergency stop and then continuing the path with the ensuing ten-footprint penalty. As such, I will be back-porting this feature into the iOS version forthwith.

Sound with SoundManager2

HTML5 audio doesn't seem to be much use as of yet, and I've been advised to use SoundManager2 as my audio library for the HTML5 version of Creatures & Castles.
For those of you unfamiliar with the library, it's basically a Javascript to Flash bridge wrapper that uses a small Flash application to handle playing sounds.
Note that it does have beta support for HTML5 audio but, honestly, it's not worth using (yet). Besides, why bother with a wrapper library such as this if you're just going to tell it to use HTML5 Audio anyway.

In any case, the API is fairly straightforward (although the reference documentation can be a little obtuse). It seems to be a fairly low level library; there is no built in cross-fade or anything like that (at least not that I saw), but it does perform its basic job admirably.
That is, it will load sounds and play them in an effective cross-platform manner.

There is one caveat I ran into that I think I will cover here. In many cases in the game, I want to be able to simultaneously play multiple copies of the same sound. There is a sound object property that can be set for this (autoShot, I believe), but with the default initialization parameters for the soundManager object this has no useful effect. In order to be able to play multiple copies of the same sound (without actually physically loading multiple copies), you have to explicitly set the soundManager.flashVersion property to 9 (as opposed to the default value of 8) in the SoundManager2 initialization section.

It took me a while to figure this one out as, although it is in the documentation, it's not explicitly obvious. Hopefully this will save some time for others with the same problem.

Tinting in ImpactJS, Part 3

So, it seems that some people are reading this blog. Which is nice.

Recently, I was asked to come up with an example for usage of my ImpactJs tinting plugin (downloadable here).

Well the first prerequisite for usage is to own ImpactJS, which is purchasable from here. When you have this installed and configured correctly, then you can drop the imageTinter.js into the ImpactJS plugins directory.

Once this is done, make sure you add 'plugins.imageTinter' to the requirements section of your main game class.

From there, you will be able to use various overloaded forms of the init method for ig.AnimationSheet and ig.Image that allow you to specify a tint color and tint alpha. Support is also provided for tinting a background map using setLayerTint method of the ig.BackgroundMap class.

Note: As long as any new images are instantiated as part of the init methods of the respective owning classes (rather than instantiated prior to the init method) then the images should be stored in the ImpactJS-provided image cache using a tint-friendly key format.

There is still some manual plumbing that needs to be done by the developer to fully integrate the tinting into ImpactJS, but this should certainly be enough to get started.

On Game Design

As you may or may not know, Creatures & Castles was originally designed for the iPhone.¹
As a platform iOS interested me because it seemed like the perfect platform to support a small development. It has the advantage over PC game development in that unless (like Notch's Minecraft) you happen to be very lucky, a PC game stands little to no chance of garnering any significant attention without a significant spend on marketing and development, as well as a fairly large team of programmers, artists and musicians to produce a game acceptable to the market at large.

Similarly, although they are of a comparable form factor and power to the iOS devices, hand-held consoles such as the Nintendo DS (and variants) have too high a barrier of entry for the casual developer² due to the ridiculous cost of their development kits, the stringent 'chicken-and-egg'³ developer program entry requirements and bone-headed refusal to support homebrew development - presumably due to a misplaced fear of piracy (which would happen anyway - homebrew support or not). It's a shame. I would have liked to have seen Creatures & Castles on the DS range of hardware. I think it would have worked pretty well.

In any case, back to iOS. With iOS, we have a powerful device (but not so powerful that a single developer can't develop a quality game), a consistent programming interface and a cost of entry for developers of less that $100. Couple that with a vast installed user-base and a well-established storefront, and it's fairly clear to see why the world and his dog is developing apps for iOS (and to a lesser extent Android and WP7).

The most interesting part of the challenge with developing a game for iOS is that the form factor and user interface is virtually unlike any other platform. Attempting to produce a game with 'standard' (e.g. joypad-based) controls is, to me, an unimaginative and intellectually barren exercise. Games such as  Flight Control, Cut the Rope, UFO on Tape and Doodle Jump have successfully married unique and innovative use of the iPhone hardware with simple and compelling games - and as such, have gone on to great and deserved financial success.

With this in mind I tried to make best use of the hardware when I came up with the design for Creatures & Castles. The high concept was "Flight Control in a maze". Possibly not the best high concept ever, but it was good for a start. The aim of the game was for the player to use their finger to trace a path of magical footprints for the hero to follow safely to the exit, using timing and skill to get there in the minimum number of steps. The best score is obtained by reaching the exit in one go; it is possible to break the path up into multiple segments, but a 10 footprint penalty is assessed for each segment. This last point is particularly important.  I did not want the player to get stuck on ANY level. It always annoys me when I buy a game and cannot access all of the content I paid for because I can't get past a particular point. As such, in Creatures & Castles, it's easy to get past any of the levels by using multiple path segments. The catch is that your score will suck.

So the control system as designed is remarkably simple:

• Drag from the hero to create a path.
• Touch the hero to set him/her moving along that path.
• Touch the undo button to undo a path.
• Touch a collected object to use it.

It's not perfect - particularly when it comes to tracing paths through the maze on the iPhone screen. It can be a bit small and fiddly, so I added the ability to use a two-finger pinch to zoom. Not the best possible solution, I'm sure, but by no means the worst.








¹Actually, it was originally designed as an online multiplayer game similar to the current rash of Facebook societal games, but that's another story. I gutted my original design to come up with a simple iPhone game instead.)
² This may well be something that Nintendo and Sony come to regret with time unless they have a change of heart.
³ With few exceptions, they will not even consider applications from 'first-time' developers without a significant track record.

Revisiting tinting

So, if you look closely at my screenshot from the post before last, you'll notice that I was talking about tinting images on-the-fly. I did a bunch of research on the web to see how other people were tinting their images. After some time, I discovered that the standard tinting algorithm used was as follows:

- where c is the color component (r, g, or b).

Applying various tints gives the following results. The original is on the left, and the tinted version is on the right:

Note that the colored text is supposed to have a black outline. Clearly, this will not do - no matter how brightly it is tinted, it should still retain internal details.

I spent some time playing around with various different blending schemes using different color spaces until I came up with the following modification:

This modification is the same as the previous, except that the tint alpha value is multiplied by the luminance of the source pixel. Thus, the darker the pixel the less it is tinted. This produced results as follows:

Now, this looks pretty good on the letters. The black outline can clearly be seen. However, if you look very closely at the red lettering, there is a faint grey outline visible between the black and the red. This is because the luminance is too low at that point to allow any significant tinting. However, it is still light enough such that the lack of tint can clearly be seen. In general, it seems that luminance alone isn't enough to get us an interesting tint.

It turns out that this has a fairly simple solution. The problem is that the luminance isn't increasing quickly enough for us - the linear relationship between how much we tint and how bright the source pixel is is not quite suitable. What we need instead is a tint level that increases much faster as the luminance increases. To fix this, I chose to multiply by the square root of the luminance. ("Wait," I hear you say, "Square root? Surely that will be smaller?" Well in this case no. The square root of a number between 0 and 1 is larger than the number itself. E.g. the square root of 0.25 is actually 0.5.) 

The adjusted equation now looks like this:

Anyway. Enough mathematics. The result looks like this:

And the full-screen tint looks like this:

Which looks just about right. Now, the big question is, why was this information not easy for me to find online? Was I just searching for the wrong stuff, or is it something that everybody already knew apart from me?

The updated javascript ImpactJS plugin can be downloaded here. 

Staying in touch - Or Not, As The Case May Be

This week I've been working on getting the basic game control framework in place. If you've played Creatures & Castles on the iPhone or iPad (and if not, why not - go and buy it immediately!) you'll have noticed that the character is controlled by tracing the character's route using the player's finger to lay a path of magical footprints.

Touching and dragging is a natural operation on the touch-sensitive screen of the iDevices. The most direct way to translate this across to the HTML5 version would be to have the player click and drag the path. However in practice it's a colossal pain in the ass, so I decided to implement a different system for controlling the main character. I'm in the process of prototyping a simple system where left-clicking will create a path between the character and the position of the cursor - as long as there isn't an intervening wall. Holding down the right mouse button undoes the path, which removes the need for a separate undo button as in the iDevice version.

It's not quite perfect, and I still have some tweaks and experimentation to perform before I'm 100% happy with it, and after that the core game will be in place. Then it will be time to start fleshing out some of the in-game enemies and the scoring system. From there, I'll work my way out to the supporting features such as the title screen, level select screens and other ancillary features. In fact, the reasons behind my choices to develop the game from the inside out would make a good topic for my next post.

Tinting images in ImpactJs

For Creatures and Castles, I make a lot of use of tinting, as mentioned in the previous post. Now, I could take the lazy way out and just create a bunch of pre-tinted assets for the HTML5/Javascript version, but that's probably not the best way to go.

Instead I decided to dig into the way ImpactJS works and create a plugin that allows the developer to specify a tint color and alpha value on load.

To cut a long story short, I overrode the prototypes of init, load, and reload on the ig.Image class to allow me to specify an initial tint. At first I thought that overriding the init would be sufficient (I added optional tintColor and tintAlpha parameters). However, ImpactJs has inbuilt image caching that uses the path to the image file as the cache key. Consequently, the overrides of load and reload were also required to make sure that tinted images did not use the same cache key (I simply appended the tint color and alpha to the path to construct a new cache key).

The last piece of the puzzle was to override the ig.Loader end function to apply all of the specified tints to the image as they were loaded. Note that I used someone else's color conversion code; I left their attribution intact, of course.

The plugin code is as follows. Save this javascript file [UPDATED: See this post] in the lib/plugins directory. It's not quite perfect yet, but I'll come up with tweaks and usage examples next time.

New Things, Old Things, and Old Things Made New

In late September, I started writing an iPhone/iPad game called Creatures & Castles using Monotouch. I decided not to use Objective C for two reasons. One of these was that I wasn't a fan of the syntax and design; it felt archaic and semi-obsolete. The second reason was that by using C#, I had the potential to port it to more platforms with fewer changes, should I feel the need.

My wife recommended that I put it forward for the 2010 Best App Ever awards, and so I did, resulting in a satisfactory second place in the iPad category to Mobigame's excellent Edge. Up until that point, sales had been a fairly flat five sales per day. Following the award, sales peaked for a few days at over one hundred copies per day. Not super, but fairly pleasing.

Anyway, an HTML5/Javascript conversion was suggested to me. I thought that it might be fun to give it a try. The ImpactJS javascript library was recommended as a potential framework for an HTML5/Javascript conversion of the game so I took a look. My Javascript is a little rusty these days, so it took me a while to get my head round it, but so far it's been a dream to use. As long as one stays within the boundaries of what it supports, development is a dream. For some aspects of Creatures & Castles, I'm going to have to step outside those boundaries. I'm not sure how easy that will be, but I suspect any difficulties will be due to be rustiness rather than any defects in ImpactJS.

Anyway, after only three days, I've already got levels with baddies moving around in the correct formations showing up in a browser. No user interactivity as of yet, but that's coming. I made a fortunate choice to store all my level information in xml, so conversion to the ImpactJS Weltmeister level format was as simple as adapting my C# level loading classes to spit out correctly formed JSON level files that load right into Weltmeister. I did have to add some code to my javascript entities to handle features such as waypoints (that define the entities paths), but that was a fairly trivial process.

More tricky will be the tinting. In order to create graphical variety in the original C# version, I used OpenGL to tint levels with different shades. There's no clean and simple way to do that in the ImpactJS library, so over the next day or so I'll be implemented a custom image loader that will tint images as they are loaded. Once this is done, I'll submit it as a ImpactJS plugin for others to use (assuming it's not a total hack).

Creatures & Castles in HTML5 glory.

Hello World

Funny thing about contracts. They sneak little things in without you noticing...

I'm apparently contractually obligated to maintain a blog about my super-secret project which obviously will no longer be super-secret when I reveal all....

But that can wait until tomorrow.

Ooh. Tingly anticipation... Can you feel it?