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.