Today I'm focussing my blog on iOS trials and tribulations. The basic steps of designing a game when working with iOS.
These are pretty simple things, and should be apparent, but .. having played a fair number of iOS games.. they're not always done!

Note, this isn't really about my actual development, as such, more the train of thought that generates the end result.
In a future bloggy thing, I might focus more on the what/where, than the how/why that this does. Let me know if this is a good thing or not, 'cos I'm honestly not really a bloggy type of person, and...
IMO, this is just a 31 year old having a bit of a rant, but if you feel different, let me know!

Anyhoo, here we go!-=-=-

Stage One : Proof of Concept

For those of you that are following my iOS escapades, you'll have noticed a much larger selection of in-dev games than actual released ones.
I'm very fussy about what does and doesn't work on my iPod. Big giant onscreen buttons aren't exactly my thing, so as much as I'd love a JNKPlat iPhing, it's probably not happening without Just the right
contol method.
But I've tried.
The Proof of Concept stage is all about trying things out, figuring out what does and doesn't work in your hands.

The quicker you can test this, the more tests you can achieve, and the better a game you'll end up with as a result.
Only the good games survive to stage two!

To help me in my quick-tests, I developed a small "menu/game/scores" framework, which you can find here. Easy Coco is made up of Cocos2D's template, along with a typically JayCode set of quickly cobbled together extras. From there it's a case of finding the right game, and then taking the framework forward to make a full game.
To test an idea, simply copy the folder, slap in some sprite images, code up a test, play! (you'll still need a Mac, an iPhing and a Dev License to try it all out properly!!)

Stage One complete!!

If the game feels right, keep it and move onto Stage two. If not, probably best to try something else!

Stage Two : iPhing conversion

The game's now running on an iPhing, but it's still looking like a cobbled together mass of temporary sprites.
At this point, I'll spend some time switching through possible sprites, playing with audio, and even building the basic level structure of the game.
Graphics and Sound aren't always apparent, and what with me being a shit artist, are usually hard to reach, but I'll try to make things that fit together nicely, so that my game doesn't look someone who's trying to make "really nice" sprites. I've ranted enough about "really nice" sprites. People who use a 3D modeller, make lovely looking models, then try to turn them into little sprites that are anti-aliased to f'k, and stick out a mile from the really shoddy backgrounds.
My games don't look like a work of art, but I'm hopeful that they don't look truly awful!

Anyway, if a game has reached Stage Two, chances are it'll also make it to stage three, but, off the top of my head, there are three games which haven't made that transition yet.

NinjaDuck got stuck.
Although it plays well enough, the gameplay wasn't quite as "gamey" as I'd have liked. It has something missing, and I've yet to find it. Either that or it's the added complication of throwing the balls. It's hard to get it "just right".

Microbes got stuck, too.
It works, it plays, but it's all a little too repetitive, without having too much of a challenge. In short, it's quite boring! This needs fixing before we can hit stage three.

Blockman is an entirely different issue...
The game works, the game plays, but I just can't seem to bring myself to release a game which would only ever have a great big "Play!" button as it's menu!
It needs a proper menu, but... What!?!
It'll probably end up like Sheep's menu, with a nice scrolly set of levels, or something..!
Blockman Gets More had a great big scrolling menu with worlds and things. That was ok, but.. probably TOO big.
Something inbetween.

Other things to consider are the game's length. Keep in mind the game will be running on a phone, so games oughta be short wherever possible. If the player needs to complete 5 really big levels before they can safely quit, that's a no-no!
SpikeDislike kinda breaks that a bit, to be honest. Great big long
levels, and It rarely saves.. It occasionally won't multitask
properly, either, oddly quiting between switches. Nobody's mentioned
that, though, so we'll pretend it's fine

Your menus should be swift, and flow quickly. If the player has to take a minute getting from level 1 to level 5 on the menu, you've done it wrong.
Finding the sweet spot where a menu is swift, but not complicated, is something I'm quite terrible at, so I apologise for any baffling menu options that might have occurred as a result of my attempts!

Stage Three : Preparing

Along with a proper menu, a good iOS game needs to work as expected! Bugs must be vanquished.

Stage Three is the annoyingly lengthy bit of the process.

Double check all designed levels, test all buttons, be sure nothing goes odd if you jump from menu to menu, and if you have the time/patience, see how well you do with a complete restart.
How far can you get, is it too hard, etc.

If you haven't yet tested multitasking, do it now before it's too late!
In a perfect world, you'd be testing on a iPad, too, but we'll forget about that until you can afford one. Assume Cocos2D knows what it's doing, and cross your fingers!

Make your game's icons, write a blurb for the AppStore, get everything packaged, then compile..
Then Clean the build, erasing all the crap...
Then compile again..

Stage three is full of annoying little pitfalls, and should be choc-a-block with testing.
Once you're happy with everything, you then need to go through Apple's "wonderful" system of chaos to get the thing uploaded..
Nnnngh...

But when it's done, it's done.
You've got a week before they get around to reviewing it, so once it's uploaded you should playtest your game over and over, looking for random freakish bugs. If you find anything, you'll have the time to reject your app, and upload it again.

App Gets!

Should your game do well, or if you feel the need, adding extra chunks falls under a none-specific Stage Four, whereby you add new levels, features and settings and things.
The MAJOR rule here, though, is not to damn well break everything.

Players scores should be left intact, levels should flow the same way, new powerups shouldn't knacker the early gameplay, things like that.

It's sometimes tricky to do, and you'll occasionally end up apologising for breaking your own game's logic due to a powerup that might require a few levels to be rebuilt, or a slight change in the game's scoring system, but try the best that you can, and your players will be happier for it.

Once all is done, and everyone is happy, head back to step one, and do it all again.

App Making is fun.
Even if Apple do make you jump through hoops to get there!