What can we learn from "Flappy Bird"?

My first encounter with Flappy Bird was checking the App Store's top free games list one morning then promptly wonder what on earth was going on. I could not understand how this game was top of the charts and why his other mini-games and rival games with "Flappy" in the title were not far behind.

The following controversies were also incredibly baffling, everyone loved this challenging yet very simple game, I could not work out why and for the most part, neither could anyone else. The creator himself also seemed very shocked by his instant fame and fortune, I really have to give kudos to the guy for how he has taken it all. He really is a nice bloke who quite simply wasn't in it for the money, just making fun games.

So what can we learn from the whole Saga?

  • The nature of the App Store can be unpredictable, the precise events which have lead to the explosion of this game are untraceable. It went viral so quickly and so strongly I don't think anyone could have predicted it.
  • Time != Sales, this point scares me. Flappy Bird was created in just a couple of days (hell, I made a version of Fish Slapped which emulated Flappy Bird and the total conversion took less than 4 hours). Sometimes these mini-game experiments can yield good results, even if the game is quite difficult.
  • Be prepared for success. Someone has to get lucky and have their product go viral some times. Be prepared for potential success by keeping your business in order and being in control of your social media.
  • Advertising is a great business model for mini-games. The developer was making 50k a day in google ads, that is incredible!

Most importantly, there really isn't anything we can learn from this experience. Just need to take it for what it is and keep working on making great games wether they be large scale or as small as flappy bird.

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.

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.

5 Possible Uses for Notography iOS

As I've said before, it is sometimes hard to sum up what "Notography" does easily but I can definitely tell you some potential ways that it could become an essential tool on your iOS device which you can't live without!

1) Building Inspections - If you work in the property market or are a real-estate agent then you will need to take a lot of photos. Sometimes it may be hard relating all of these pictures back to their respective properties, especially if you are giving them to someone else to document. Notography can record the date / time and geocode an accurate address and print it directly on the photo, so all the proof is right there.

2) Live Blogging an Event - If you are at an important event or function as a journalist you need a way to get your content out there and fast, what you don't want is someone else to rip off your content or to post something which looks unprofessional. With Notography you can have your presets set up the day before so that all you have to do is snap and share instantly. It will put your companies copyright information or watermark on the images before sending them, it is quick so you aren't taking your eyes off the action and can auto-enhance the images so they look great and professional.

3) Photo Diary for Holidays - The quick snap and share is great for capturing your adventure without being taken out of the adventure, the different filters and date/time stamps, location details, etc can really help you recall where a photo was taken later and make it look like you are having a great time! Custom text means you can set up titles like "Canda 2014" so you can remember exactly which holiday you were on.

4) Water / Power Meter Inspections - This may seem like an odd item to have on the list but being able to have a static inspection number and automatically geocoded address means its very easy for those back in the office to process.

5) Concept Design Artist - Easily watermark every image you photograph, you can also choose the save the original image on your phone so it is maintained without layered text or filters. This gives you a sharable copy and safe original for later use. 

Any occasion where you want to prepare templates for your photos before hand so that you can instantly automate the process and choose to share via social media, email, airdrop, etc. 

Any occasion where you need to automate useful text to remember where and when the photo was taken.

Any occasion where you want to protect your copyright and/or produce a professional looking image every time you take a photo.

What does the introduction of MFi game controllers mean for developers?

Another WWDC and another swag of great feature and framework updates for iOS and Mac OSX. The introduction of Sprite Kit and update of Game Center is a much needed step in the right direction for producing more and better games on iOS but one feature that really interests me is the introduction of MFi game controllers. 

In the past if developers wanted to be able to support controllers on their iOS games they would have had to use 3rd party bluetooth controller which pretty much just emulated a keyboard being attached. This wasn't bad but it also wasn't overly popular and had limited use. The iCade was a popular devices along with the iControlPad, there was even an app so you could use a second iOS device as a controller called Joypad. All of these systems were fairly easy to implement, the problem is though not many developers did, instead opting to focus on the built in tools like accelerometer and on screen controls. 

So the introduction of controllers that are easy to implement to a consistant standard is a pretty cool thing. What do developers have to think about though?

Opportunity

Very soon when kids go to their apple stores or local electronics store they will start seeing some very interesting controllers on display, there might even be demo units out for kids to have a play on. They will probably sell reasonably well and in the short term if there are only a handful of games which support these controllers then you have a huge opportunity to boost sales of your apps. 

It's also an opportunity to do things differently, there has always been a gap between games based on consoles and those based on touch devices due to the difference in controls. This is no longer such an issue. 

People don't remember all the products that do great things, only the ones that do them first. 

Balance

Gameloft also released a controller once for use with their games, it's sales were pitiful but that may just be because it only worked on a very small selection of their games. One thing that really stood out on their first person shooters though was that it was much easier to aim at something with a controller than with the touch screen, just like it is easier to drive a car with a controller than an accelerometer. 

There is a huge balance risk here as the control scheme could potentially change the difficulty of the game quite heavily and reaching a mid point is hard work. In a first person shooter you may have to have higher aiming assists and racing games may need more powerful driving assists, etc. You also run in to the problem that the Wii had with Mario Cart by designing it to work with those annoying plastic wheels, the game became so simplified that it just wasn't fun to play with a controller, there was no depth and nothing exciting about driving.

Reaching a midpoint where both playing with the device or with a controller feels equal will be the hardest thing developers need to deal with.

Hybrid Controls

One idea Apple seemed keen to push was using the controller for some things but then using the screen or accelerometer when it makes sense to. The case controllers that keep the device in the centre could make use of this fairly well. 

To me, it seems like something worth exploring. That same theory is what made the Nintendo DS a very popular console before the rise of iOS gaming, so it is definitely an area worth exploring. I'm sure finding a new and exciting hybrid control scheme would be a great way to get featured by Apple. 

The challenge here is supporting gameplay when a controller isn't actually connected, you need to be able to design it in a way so that the two control elements don't get too jumbled when you are just playing on the single screen. 

Don't forget the screen!

While controllers are cool, not everyone will use one and not everyone who uses one will take a controller everywhere they go. You should still offer the alternative of onscreen controls or similar and unless you specify your app is controller only fairly clearly and have good reason for it, your app would probably be rejected. 

Airplay

Imagine you have a computer or iDevice with an Apple TV and controller in the house, you can pretty much emulate a console experience! Playing the game live on TV with your controller while the computer or iDevice handles the game like a console.

Optimising your game to run over airplay could extend sessions of play quite significantly, don't believe me? Try comparing the average play time of a kid sitting in front of a TV playing a game to that of a kid sitting in their bedroom on an iDevice. More play time means more iADs presented, more in-app purchases bought and more feedback on your product.

Cool! So how do I get started? 

If you are a registered developer you can get started right now, the only issue you will have is that you will have a small testing window to see if it is all working. The first controllers come out in fall around the same time as iOS7. 

One final thought... 

If you can now share the same achievements and leader boards over both OSX and iOS and share game data and state information via iCloud between OSX and iOS AND use the same controller for both OSX and iOS AND use Sprite Kit to developer games that will work with the same code on both OSX and iOS.... doesn't it seem like the era of true mobile gaming has begun where you can start, stop and pick up your game / match from where ever you are and whatever device you are on? The first game to take TRUE advantage of the opportunities Apple have provided, will be pretty damn awesome!