Design your app for localization from day one

Something which had been more of an afterthought for me in the past had been Localization, I figured there were enough english speaking iOS users out there for my business to be profitable. In retrospect this was a rather uncultured and closed minded view considering how big my audience could potentially be and how little it could cost me to reach them.

Here are a few tips for early development to make the localization process easy and painless:

• Consider the dialog early, every word works out to around 9 cents per language (using professional translation services), if you can keep your dialog short and maybe replace some words with common symbols like arrows then it will make things cheaper
• Plan to use a professional translation service, they are rather cheap and while google translate is reasonably good you will miss out on a lot of dialect and detail which can be rather embarrassing for your company and lead to demands for refunds. It will also kill your chances of getting featured (Apple love to feature well localized apps!).
• Whenever you create a NSString while programming, don't forget to do it as a NSLocalizedString(@"",@"") and actually leave a detailed note in the second parameter where there is room for confusion. For example: If the text is "Ok", then leave a note about what you are agreeing to with this text as certain things are agreed to in different ways in different languages. Also if you have abbreviations like "m" for meters, make sure you let the translator know with a note.
• Don't worry about populating your Localizable.strings file as you go, it's a waste of time as using genstrings can do this automatically.
• Plan to localize towards the end of your development cycle, most translators are quick and last minute updates or changes can be time consuming.
• Don't forget about your app name, store description, key words, in-app purchases, game center achievements and leaderboards. They all need to be localized for a complete experience.
• Don't forget about images or data in plists which may contain words.

Ok, so you have kept your strings short and minimal to reduce costs, you have run genstrings to prepare your localizable.strings file. What next? 

You need to decide what languages you need, it is recommended to localize in:

English, Spanish, French, German, Italian, Portuguese, Chinese (Simplified), Chinese (Traditional), Russian, Korean and Japanese.

You may want to do some market research first to see how popular the subject of your app will be in those regions. You may find that your game only really applies to English speaking countries or on the other hand you may find that Korea is 80% of your world market. If you are still unsure, its not that expensive to cover your bases and do all of the above.

Now that you have decided on your languages, it's time to pick a translation service. I like to use iCanLocalize. They are very affordable, very quick and allow for lots of communication with the translators so you can get your translation done with the right context and style of your app. They also have a review process where another translator checks the translations done to ensure impeccable quality. You can also send them your .strings files and they can return them in the same format for easy implementation.

It's good to keep Google Translate handy too for unimportant quick translations. Be sure to check the context is as accurate as possible even with these simple translations.

Follow these tips and localizing your apps should be as painless as it has been for me in my latest app which goes on sale in two to three weeks time.

Implementing better iOS game menu strategies

One of the biggest mistakes I've ever made is designing a menu structure poorly. It lead to a 100,000 downloads and counting app making a grand total of $6. 

My mistake? Building a primarily multi-player game where the menu gave focus to the single player (late addition and less refined) content, made it difficult to find tutorials and makes in-app purchases unattractive and even difficult to find.

The menu was beautiful but it didn't do it's job, it didn't quickly and simply show the user what they wanted to find. It didn't lead the user where they needed to go, it didn't fast track the user to the game itself. Huge problems given minimal consideration.

So what makes a good menu structure?

Take me too the game

If it takes more than 2 taps to get from the menu to the game, it's taking too long. One game that especially impressed me was Jetpack Joyride by Halfbrick. The game has both a minimal and extended menu, the first time you play you are given 1 option "Tap anywhere to begin", you can't focus more on taking the player to the action than that!

Set the focus point

Having your important buttons bigger and and more central than the other options instantly makes the player focus on that option. If you need to have a more extensive menu structure then it guides the user through a default set of options by simply following the biggest buttons.

Develop your menus with your monetization strategy

A lot of developers favor having a separate store on their main menu where players can go through and find additional content they wish to buy. Something to consider is mixing your in-app content with the actual games content. Such as allowing players to buy "Save Me" tokens at the point of them failing in the game itself, kind of like adding coins at the continue screen of an arcade game. If you have a character select screen why not add your locked in-app purchases to the list as well.

Keep it simple

So many apps fail this step but it is by far the most important. If you don't need an option or level of menu options then cull them, cull as much as possible, give the player the bare minimum number of options. Use prototyping and design software to layout and revise your interface. Keep iterating and removing things that aren't needed. This will not only cut down on development time but make the players experience smoother.

I cannot stress enough that last point about keeping it simple, draft up your concept menu structure, revise it and work through it with a handful of different people until everyone you talk to is comfortable with it and feels that your users will be as well.

I've gone through this process thoroughly with my next upcoming (February) game and hopefully I will have some good statistics of how the experience has been improved.

Some great SpriteKit resources

In order to start getting some games on the store quickly with my challenge I'm having to cram a lot of SpriteKit knowledge.

It seems everyone has a different idea of how things are done and surprisingly some of the most experienced iOS developers I've seen are still using old methods of doing things, possibly because they are coming fresh from Cocos2D.

Right now I have 5 different sample projects open with different implementations of an entity class, as I observe each of them I have been using ideas I've liked and trying to write the code as robust as possible, at times it sort of feels like music, like a different person would have a completely different interpretation of what is good or bad but neither are technically wrong.

It's an interesting world of 2D development to be working in, here are a few tools I've found along the way which have been useful:

• SKPhysicsBody Generator  - This website is great, you can drag in an image then draw a polygon and get the code straight away to put it in your app. I even took this a little further by making a simple spreadsheet tool which prepares the results for a plist and method to loop through creating the physics body from a plist file.
• Kobold Kit - I haven't used it myself by this looks promising and I will probably be implementing in at least some of my apps when it reaches version 1.0.
• iOS Games by Tutorials - This book has been a fantastic learning reference, I've picked up a lot of useful information and their additional tools are great. Easily worth the price. (Disclaimer: I am affiliated with the Ray Wenderlich Team).
• Cartoon Smart on Udemy - I love the work these guys do, while their Obj-C is still back in Cocos2D land, their examples are fairly top notch and its really good to learn something from a different perspective than just RW.
• Apportable -  While I am yet to try it, Apportable sounds like a high quality and reliable way to convert your Sprite Kit projects in to a format usable on the android platform. If it works then you have just increased your market size with minimal effort.

5 things Apple could do to make Game Centre better.

Apple are known for their ability to look at something and see why it is good, not just from a technology perspective but the user experience and joy of each individual tiny action. One area I feel they have struggled though is Game Centre, here are a few ways I think they could improve it:

1. Cumulative Gamer Score  - Each game centre game has achievements but there is actually very little incentive to go out and grab a heap of games in order to boost your cumulative total of gamer points. It's gotten better in iOS7 but still a long way off being perfect. The Gamer Score needs to be a bigger feature and everywhere.
2. Better Friend Management - Why not integrate with Facebook, twitter, contacts, etc to build up a large friends list of gamers who you can invite and challenge to games? Then take it a step further to show their gamer score and some other details on their contact page and integrate game invites and special sharing of custom game events via iMessage.
3. Allow Developers to Share certain Content in GameCentre App - We all have the little game centre app on our phones but it is rarely visited. Apple need to find a way to boost it's usefulness by allowing for news, deals, content offers to appear on a "wall" like feed. This feed can also show significant game events like someone getting an achievement or sharing a high score / screenshot.
4. Party Functionality - Now that MFI controllers are coming it is fair to say iOS is stepping up it's game. Wouldn't it be great if you could have something like a group FaceTime call with 3 or 4 friends then, switch to a match of a FPS game with all of them in the same group and continue talking maybe even with a PiP.
5. Allow Developers to Be Your Advertisers - This really isn't hard, if games were able to integrate more fluently with game centre and show players their cumulative gamerscore, what friends they have online, what their friends are playing, do they have room in party, etc. There are so many ways developers can promote services of game centre and it will only encourage more people to use it.

While I understand a lot of these features have probably been denied in the past because it would take away from their overall goal of having a phone or tablet for all purposes, not a heavily game orientated platform, these changes might help people discover portable gaming and how great it can be.

I'm sure they are watching what Microsoft and Sony have been doing with their latest consoles and I hope they plan to learn from their trials.

New years progress report

2014 has kicked off and so have I on the 12 games in 12 months challenge. I chose a simple game to start off with and it is kind of more of a training tool for cashiers than an actual game.

Progress has been good though and I hope to get it out within just a few weeks so as to have plenty of time to work on Februarys project as it will most likely be more difficult.

I'm trying to decide on the format for the book, I want to explain all the core functionality fairly well so the menu template will most likely be a separate project.

To keep things as simple as possible I will most likely be working towards making these projects very property list heavy so you can get started with less hard coding.

Handling SpriteKit node positions

When SpriteKit was announced one of the features which really got my excited was the high compatibility between iOS and OSX. The demo project displayed at WWDC and then made available from the dev centre later even had a project which contained both iOS and Mac OSX versions.

One thing that SpriteKit seems to be lacking though is a universal control for positioning assets. While this isn't exactly hard to create there are an awful lot of ways to go about creating it and exploring which is the best is a long process.

Things to consider:

• You will need to predicate a lot of the code to check if the compiler is compiling in OSX or iOS.
• For the tool to be useful you will need to to be able to scale up and down screen co-ordinates and / or screen percentages, take in to account landscape / portrait orientation AND allow for fine tuning with offsets.
• Don't forget to allow offsets for 4 inch screens.
• Handle scaling, shuffling, etc on Mac OSX.
• Do you want objects that are resized to keep their aspect ratio.
• Varying anchor points.
• Need to account for the future, such as error handling for unknown screen sizes, allowing room for changes and improvements in SpriteKit.

These are all very important and intertwined, so why even make a helper class to handle them? Well, there would be an awful lot of space taken up in our app by code if we re-wrote or copied and pasted every time we wanted to position or size an object.

It's also handy to be able to update these methods from the one place should code change in the future rather than digging through every single point you positioned an object.

The helper class I've been working on returns a CGPoint or CGSize depending on the parameters you pass in to the method. The co-ordinates you pass in are based on 3.5 inch iPhone screens and they are scaled based on the current screen size and fine tuning offsets.

The class isn't perfect and needs a lot of refinement and testing but I plan to release it on GitHUB after my first app using it is released in January. Any advice or points I may have missed would be most appreciated while I test this helper class out.