How to Localise your iPhone/iPad game on the cheap...

As I mentioned in my previous post, there are a quite a few traps you can fall into when localising your game or app.  Of equal importance, however, is getting all that text translated in the first place.  How can you get your game translated without spending a fortune?

The obvious solution is to use an on-line automated translation service, such as Google Translate.  This will work, but I don't think anyone expects it to be a 100% perfect translation.  For my sins, I have used this service to translate some of the more languages my game supports, such as Malay and Indonesian.  For a big market, you need something much better.

My solution is to use oDesk.  It's a web site that allows anyone to post a job and anyone to reply to it.  For my first translation, I had no idea what I was doing.  All up, my text came to about 2,000 words.  The game is was translating, Honey Pot was a simple puzzle game.  I figured this is the sort of game that is popular in East Asia, so my first targets for translation would be Chinese, Japanese and Korean.  I placed an ad on oDesk at a price of US$50.00 for each translation.  That comes out at about 2.5 cents a word, which is about average from what I can gather.

I was instantly swamped with a huge number of Chinese language translators.  Wow.  Maybe this wouldn't be so hard.  Confusingly, I had very few Korean and Japanese translators come to the party.  Eventually I managed to select a translator for each language and gave them all a week to get it done.

The people doing the work were students studying in the relevant countries.  I hoped this would enable them to do a spot on translation.  I wanted the text to be informal and quite relaxed.  Who better to do it than native speakers, I thought!

I prepared a word document that listed all the text to be translated.  I had two columns - one for the text to be translated and then a column for the translation.  For most phrases, I also included some explanatory text, so that the translator could put the text in context.  For example, "Next Piece" is almost meaningless by itself, so I had some text to explain that the game was played using different shaped blocks and this would be a heading over where the next piece to be played would appear.  It almost seemed that the shorter the piece of text, the longer the explanation would have to be!  I figured it's all about context, so the more information I could give the translator, the better the result would be!

After a week, the Chinese and Korean translated reported back with complete translations.  They had a few questions to clarify some expressions, but generally they had the information to get the job done.  Success!

I then had a horrible though - how could I tell if the translation was correct?  I couldn't even read the characters, so I had no idea!  My only solution, was to run the text into Google Translate and see if the translation in English matched what I had put it.  Generally speaking, it all matched.  I also tried it the other way - I put my English text in and made sure that the translation wasn't just a dump of the Google Translate text.

After another week, I had heard nothing from the Japanese translator, despite numerous attempts at communication.  This is the problem with oDesk.  When it works, it works well, but there's nothing you can do when the other end goes silent.  In the end, I cancelled the contract, re-advertised and got a good translation done.

As soon as I released the localised version, downloads went through the roof!  I think the combination of my cute graphics and the local language really encouraged people to download the game.  Alternatively, it could just be that there are so few native Chinese iPhone apps that people will download any old rubbish if it's in their own language!  Either way, downloads tripled and I deemed the whole exercise a smashing success.  It was super cool to see my app on the charts in China and Japan!

The exception was Korea.  Zero downloads!  It turns out, that at the time, Apple was banned from selling games in Korea.  D'Oh!  I probably should have researched that first.  Oh well...

In later editions, I used the same approach to translate the app into Thai, Spanish, German, French, Italian and Arabic.  Each time a new language was added, downloads in the relevant territories surged.  For subsequent translations, I dropped the going rate to $20, which still resulted in a huge number of applicants.  At this price range, some of the translations were noticeably rubbish and had to be thrown away, but I think overall that was a great price to use.

So there you go.  $20 a pop for each language and the world's your oyster.  I still have no idea if any of my translations are actually laced with profanities or baby talk, but the locals don't seem to mind.

Avoid my mistakes when localising your iPhone/iPad app

One of the great things about the iOS (iPhone/iPad) world, is the geographic spread of users.  Everyone around the world is in love with Apple, from the US to China and everywhere in between.  This means a huge audience for your game, but it also means a huge number of languages to deal with.  How on earth do you reach all those users who don't necessarily speak your language?

The first game I developed was a cute Tetris type clone - Honey Pot.  It was my foray into iOS development.  The aim was to learn iOS programming, become fabulously wealthy and retire to a life of luxury.  As part of this dream, I was aiming to try out every piece of functionality that Apple offered, just to see how it works.  One thing I looked at, was how to localise the application for different languages.

Unlike some platforms I've used in the past, Apple has built localisation into the core of the iOS experience.  When done properly, the user sets their preferred language, then all the applications magically convert to the language.  It's designed to be simple and works well.  They've also given the ability to add different languages to iTunes as well, so people when shopping for apps see descriptions in their own language.  Great stuff, but how does it work?

At a basic level, Apple allows developers to store language specific versions of all assets that might be different for each language.  This obviously includes text, but it also includes images as well.  The idea is some images might be culturally specific and what's appropriate in one culture might be bad in another.  Within XCode, you can specify different versions of assets for each language you support.

The first thing I noticed, is that all my messages were stored as embedded text all over the place.  I added localisations into the game at a late stage.  Bad move.  This meant I'd have to do a piece of logic every time I wanted to display a message to the user.  Lots of work, with not much fun!

The sensible way of doing it, is to use a string file - Localizable.strings.  You create one string file for each language and it's a simple task of just updating the text appropriately.  Ray Wenderlich's team has a great tutorial here: How to Localize an iPhone App.

The other problem I ran into, was my superb artist had rendered a whole bunch of buttons for me, with lovely text embedded onto the image.  This was a problem.  I needed a version of the button for every supported language!  This was a pain to maintain, as well as making the executable much larger than it needed to be!

My solution, was to develop a little library that took my base image (minus the text) and added the custom text on top.  Perfect.  Using one image file, I can now have as many images as I like.

Just to make things fun, I was using a pre-rendered font atlas everywhere.  Using the great Glyph Designer, you can create some cool looking fonts to match your game.  This worked amazingly well, up until I ran into Unicode character sets - Chinese and Japanese!  Cocos2d limits the size of your sprite sheets to being 1024x1024 (if you want to support older iPhones).  When you put in all the characters in the Chinese character set, you soon run out of space!

To get around this, I had to do some pretty tedious manual work.  First of all, I dumped all the characters required into a single file, then pulled out the set of unique characters.  These were then the only characters I used in Glyph Designer.  Every time I added some new text, I had to make sure all the required characters were in the character set.  Not much fun!  The end result was some pretty text, but it was a lot of work!

So, these are my three recommendations if you intend on localising your iPhone/iPad app:

• Always, always put all your text into a separate file.  Resist the temptation of putting any user facing text into a hard coded string
• Design your buttons with localisations in mind.  Never render your text onto graphics.  Always add the text on later
• Bear in mind unicode character sets - Chinese, Japanese, Thai and Arabic in particular

As a result of localising my puzzle game Honey Pot, I have about 50% of my downloads from China and another 15% from Japan.  Prior to localising my game, I got very few downloads outside European countries.  Definitely a good result!

So, how do I get my text translated?  More on that next time!

I can't draw, where do I get graphics from?

OK, I'll be honest.  I can't draw.  Not event a bit.  My artistic talent peaked at finger painting and has been on a slow downward spiral ever since.  If you're creating games, however, graphics are kind of important.  Well, probably VERY important.  What to do?

My first approach, which has worked amazingly well, is to get someone else to do it!  I placed a small ad on gumtree.com asking for a recent art school graduate to help me out with some graphics.  I couldn't promise fame or fortune, but I did promise a share of the spoils from what would be a truly awesome game.  I thought a 20% share was about right.  My game wasn't going to be that graphically intense, so I would need a lot more code than I needed graphics.

This relationship worked (and works) well.  My artist gets some exposure to the world of iPhone development and I get some superb graphics in return.  The first game we did, Honey Pot managed to sell quite well and both myself and the artist got some money out of it!  It was a great learning exercise for both of us.

What I learnt from this, is what level of detail I need to provide the artist in order for them to do their work.  They need to know quite a few technical details - size and depth of image, colour palette size etc.  I also needed to communicate clearly how my animations would work, how many frames I would need and what transitions I had in mind.

One headache we managed to avoid is a common one - file names and versioning.  What should the files be called and what's the most recent version?  It turned out it was much easier for me to rename all the files rather than the artist.  I had a particular naming scheme in mind which the art package didn't really like.  As a result, every time I got some new files, I had to run them through a quick rename process.  This was a little overhead, but it allowed the artist to be more productive and left the grunt work to me, which I automated.

Versioining was overcome by a diligent application of versioned directories.  If you're not careful, you could end up losing files by accidentally copying old files over new files.  I had a policy of never deleting anything, so this part was easy.

For my next project, which was on a commercial footing, I was working with a new artist.  This opened my eyes to a whole new way of working.  I was used to receiving nice zipped archives of .png files clipped precisely to the correct size.  The new artist didn't work that way.  Instead, I received fully fledged .psd files.  All the graphics I needed were in there, but I had to go in and chop them out myself.  This lead to quite a steep learning curve, as I was no expert in Photoshop.  I thought I knew how to use it, but as I struggled to get out the files I needed, I ended up reading quite a few online tutorials on how to do what I thought should be simple tasks.

That taught me an important lesson, even though I would never be creating any artwork, I needed to know my way around Photoshop.  It was a case of Photoshop or die!

In retrospect, I think this was an inefficient way of working.  It makes much more sense for the artist to use their tools to export all the required data.  After all, they're the experts in the tool, so they can do the required work in a fraction of the time I could.

I also struggled with explaining to this artist the precise technical requirements of the work.  They were amazing at coming up with the graphics, had brilliant ideas on design, but didn't really get that I needed a 32x32 pixel tile that would tessellate seamlessly over a plane and interlock nicely with 12 other tiles.  Eventually we got there, but there was a lot of hair pulling on both sides!

For my latest game, I wanted a bunch of anime type characters drawn.  I knew this would be a lot of up front work, so I did something radical - I paid someone!  I am a big fame of oDesk.  This allows anyone to advertise a job and have anyone around the world apply for it.  I managed to find an amazingly gifted artist in the Philippines who created the amazing fairy/goblin art my new game uses.  Sure, I had to pay him by the hour, but he was so fast and so talented I think the result was worth out.  Due to his professionalism, working remotely and giving directions just by emails was fine.

I found the best way of communicating an idea was to google about until I found some images that evoked the style I was looking for.  He then went crazy, came up with a bunch of ideas, which we then refined.  It was a great working experience and one I would recommend.

So there you have it.  It is possible to create graphically lovely games without creating the graphics yourself.

The Joys of Test Flight

If you're an iOS developer and you don't use Test Flight  testflightapp.com  you need to start immediately!  The site does two things really well.  First of all, it allows you to recruit test users for your app.  You can do this by passing out a URL for example: http://bit.ly/HJxYmd or via an email.  Best of all, if the email is read on an iPhone, the user can install all the bits and bobs necessary to run it.  No more mucking about with provisioning profile installs.

The other thing it does, it streamline the distribution of new releases.  When a user signs up, you can quickly copy their device details over to iTunes connect and update the relevant provisioning profile in record time.  Then when you create a new build, an email can be sent out to all the registered users.  Great stuff.

Best of all, the site is free to use!  Pretty darn good if you ask me!