New Alpha Build Available

It's been a long time between builds, we we are pleased to release a new alpha version of Kingdom's End for everyone to try.  Check out the link to the right.

The game has a bunch of new features, but is still a long way from completion.  In particular, there are a lot of place holder graphics.  Once the design has been finalised, we'll be getting a proper artist in to complete the look.  Please bear this in mind when you're testing it out.

We'd love to hear what people think of the game - good or bad!  At this stage, we're focusing on the actual game play mechanics and making it as fun as possible.

There's still a lot of work to be done, but the end is getting closer!

24-Oct-2012

Github for one...

While I'm doing client work, I always use version control software to keep all the different files locked away and secure.  With PeopleSoft, there are tens of thousands of files, so it's kind of important not to loose track of them.  With my own iOS development, however, I've always avoided using git or the like as I didn't see the benefit.  After the game hack at iOS Dev UK, I've changed my tune and now think it's a great idea!

My approach was always to do manual version control.  I'd just have a bunch of whole directory copies of a project and every now and then I'd clone the whole thing.  As it was just me working on these projects, this worked fine.  If ever I had a slip up, I could just go back to the last version in the backup directory and manually sort things out.

The one issue I had with this was switching between my Mac Book and my Mac Mini.  It was always a bit hair raising when I copied the whole directory from one machine to the other.  The first step was usually to delete the whole thing on the target machine, which was always scary.  I did try setting up a local server, but this never quite seemed to work and was a bit annoying.

During the game hack, however, our team relied heavily on Github to share all our source code.  Previously, when I did use git, it was through the git built into XCode.  That worked OK, but I found I spent more time battling it than using it properly.

This all changed when I started using the stand alone Mac client.  Sure, it has it's flaws, but OMG, when it works, it works well!  With a few button press, you can commit your latest changes, backup the whole project to the web, then distribute it to all your machines.  WOW.  Until I saw this in action, I never saw the point of this type of version control, but when you add in off site cloud backups and internet based distribution, it's magic!

To get things working, you need the Github client from mac.github.com and a Github account.  The slight catch is that the free account only allows you to create public repositories.  To create the private ones that you really want, you need to subscribe.  After using it for a week now, it's definitely worth the $7 a month I'm paying.

As I mentioned, a great feature is that all your code is backed up to the cloud.  This is as huge comfort if you're worried about off site backups.  It's also an amazingly useful way of looking at your past commits and hence prior versions of your code.  Doing the same within XCode can be a bit of a pain, but the simple web interface allows you to look at your code in a really simple way.  Great stuff!

There are a few annoyances with git.  Sometimes it adds things to your project it shouldn't - things like the position and layout of your windows and other project type preferences.  Merging branches can also be a pain and can lead to the corruption of the project file.  This is easily fixed using a text editor, but it's a bit of a pain.  A few googles on using .gitignore sorted most things out, so it's not a show stopper.

In the space of a week, I've gone from wondering why you would bother with the overhead of version control to using it regularly to actually make my work easier.  Great stuff!

Using UIKit with Cocos2d - iOS and Mac!

I was at the excellent iOS Dev UK conference last week and a few people talked about combining the power of cocos2d with the features of UIKit.  This made a lot of sense to me.  Cocos2d is great at graphics and such, but it's a real pig for certain basic behaviours.  For example, I've been putting off adding a feature to my latest game that allow you to edit the name of the players.  The thought of writing a text field control from scratch was a bit daunting.  I now know I can just use a UIKit edit box and avoid all the heavy lifting!

Adding UIKit controls is surprisingly easy.  The cocos2d app Director sets up the screen a regular UIView to display the Open GL stuff.  All you need to do is add a child to this view, then all the standard UIKit stuff can be used.  So easy!

I'm yet to see if there's any performance hits in using this approach, but since it's only going to be used in the menu part of the game, this won't be a problem.

After getting the UIKit working, I next turned to using the equivalent Cocoa controls for the Mac.  This turned out to be a little trickier.  Unlike the iOS Open GL view, the Mac version does NOT allow any child views to be added to it.  D'Oh!

After hunting around for ages, I eventually scraped together some code to do it.  Basically, it involves creating a new NSWindow with a NSView inside.  You then add this window as a child of the root window.    I place it at the top of the view stack and make it transparent, so the user doesn't realise what's going on.  All your Cocoa controls can then be added to the NSView.

There were a few gotchas with this.  First of all, if you add a Window without any chrome (window title, open/close etc),  OSX handily disables all edit functions!  That took me AGES to work out what was going on.  To get around this, all you need to do is sub-class the Window and add a single function that tells OSX to allow editing.  So bizarre!

I'm still working out a few kinks with this approach, but I'm now able to use standard OS controls for editing text, which is amazing. I'll post a complete project with examples on github once I get a nice clean project running.

Random Territory Name Generator

I decided to add a bit of pizazz to the game.  I haven't had much time lately to work on the game, so I decided to add a nice simple feature that will add a bit of charm to the game.  I've created an algorithm for generating random territory names!

My ultimate goal is to create a map editor with the game and allow users to share their maps with other players.  Better still, if the random map generator creates a particularly good map, you can share it with other users.  As part of this, I thought it would be nice to give each territory a name.  That way, if you wanted to recreate the Risk map, you could actually ensure the wobbly bit on the right is labelled "Kamchatka".

For the randomly generated maps, I wanted some randomly generated names.  My first thought was just to create a random group of letters.  After a little hunting on the net, however, I found this wiki page: List of generic forms in place names in the United Kingdom and Ireland.  This is a great list that shows the root word origin for a lot of common UK place names - Toponymy as the cool kids call it.

This list breaks out the common parts of many places names.  I knew a few of these - "Chester" comes from the Latin word for Camp.  "Bourne" is the place where a river starts.  It also had heaps of other ones - "bre" for hill, "combe" for valley and "drum" for ridge.

I pulled out the list and came up with an algorithm that randomly concatenates two elements from this list.  Below are some cool names it generated:

• Drumcott
• Kilham
• Pitness
• Tarnstow
• WinTilly

They all sound suitably British and perfect for my fantasy game!

I can now display to the user that they've built a castle in Kilham, rather than just that forest territory on the left!  Simple, but 5% more charming!

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.