That’s why I’m trying out something different.  I’ve always liked isometric turn based games (XCom – UFO: Enemy Unknown being the classic) and now I’ve got some resources at my fingertips, I’m getting the team to put together an isometric strategy game made primarily for the iPhone.  But here’s the different part – I don’t want to develop this game in secret until the end.  I think it’s important to show what kind of things go on behind the scenes and to allow players to give feedback early and often.  And I’ll be letting some parts be totally influenced by the fans.

To start it off, a name has to be chosen for the new game.  All submissions welcome. Head over to http://game.jseuss.com/ for more info -it’ll be up soon.  The person who comes up with the winning name will get an App Store Promo Code for Pegs In Space, and also for the new game once it’s released.

Anyhow, what better reason than to share some things I’ve learnt along the way starting with …

Scope

Before writing any application you need to set a goal that is both realistic and achievable.  And this seems to be more important for games than any other genre. For some reason, people who like playing games, think that equates to liking/being good at writing games.  If you’ve never written a game before it’s probably no surprise that you shouldn’t try to write an epic FPS with realistic gameplay and story line.  But a lot of people fall into the trap of underestimating the effort to produce a simple turn based strategy, or even more common, some sort of RPG.  

If you’re completely new to the scene, try something a little easier.  Graphics and artwork will either cost you money or time (or both) so pick a game that’s both easy to draw and easy to write.  Many solitaire games are very simple and will give you an idea of how to process and transition between game states (I’ll talk about this later).  It’ll also allow you to play with visual effects without the need for high responsiveness.

 From there you can create board type games with a computer opponent, introducing AI, then perhaps branch into games with levels where object management comes into play.  The choice is yours really.  But remember to keep adding to your past experiences and release every app you build.  

But to get back to the point, keep your apps simple, with only a few features that are new to you and stick to the plan.  Release your app and start another rather than adding ‘one more thing’ until you have a big messy pile of code.  

Next post I’ll be talking about different ways to approach reuse so each app is much easier than the last.

Although incredibly simple to use, the Audio Services should really only be used for one off alerts or sounds, and never as the sound effect backend of a game or similar. 

Like most Apple APIs, they use the technique of lazy loading.  That is, don’t bother doing anything like setting up audio buffers etc until you actually call the API into action for the first time.  This is useful for faster loading apps, and a smaller average memory footprint. 

But the downside to this is that the first time you try to play a sound, the Audio Services will be initialized and your app will pause for tenths of a second.  After this, however, all will be fine. 

A better way to go is to use OpenAL to handle audio playback.  It is much more flexible, and allows you to call the initialize function when your application loads, to avoid delays when you actually want sound to be played.  

The best place to start with this is to look at the Apple ‘Crash Landing’ example.  It includes a ‘SoundEngine’ module that can pretty much just be copied into your applications for use.  Remember to include the OpenAL framework though.

Largely it’s my fault.  I should have done my research upfront. But with all the talk of the OpenGL ES 2.0 standard, I started to assume that it was supported on the iPhone.  After three hours of learning about vertex and fragment shaders in OpenGL ES 2.0, and writing a few to render a 2D blob for my upcoming iPhone physics engine (more on this later..) I got stuck trying to make it work on the iPhone itself.  

Not surprising really.  The hardware in the iPhone only supports the OpenGL ES 1.1 standard, and as such the API has no calls to any vector or fragment program related goodness.  

Lucky for me, I was just trying to do some shadows and shading of 2D sprites, so I could kinda fake it using some blending and scaling, but I guess the more adventurous effects will just have to wail until the next iPhone generation or later. 

So before you end up crossed armed and sulking as hard as you can at your computer, only do things based on the 1.1 standard, not the 2.0.

There are so many apps out there for the iPhone that are doing some pretty graphics/algorithmically intensive stuff.  Most are right on the money when it comes to responsiveness, but some are just woeful!    

Perhaps it’s the promises of fame and fortune that seems synonymous with iPhone programming, but many developers new to Objective C are doing straight ports or just writing plain ObjC code until their app ‘works’ then just release it.  There seems to be a feeling that if an app is slow, the device just can’t handle it.  

I’ve been stepping through the hoops of (relatively) computationally heavy apps at the moment with the creation of a generic physics engine for use in a bunch of 2D based games.  Because it was my first app with serious algorithms in it, I didn’t give optimization much thought. And if you believe most ‘Good Software Practice” guidelines, that was a good thing. (optimize last, or you’ll be optimizing things that need no optimization at all.)

But perhaps some thought is necessary.  At the beginning, it’s very nice to go down the path of using pure ObjC throughout your code.  Let’s face it – it has a nice set of design features that make you feel like you’re on a fluffy cloud rather than the hard stainless steel bench of C.  And if you’re particularly sick like me, [you setLovesSquareBrackets:YES]. But of course the nice features of ObjC come at a cost, and the biggest one is the passing of messages.  C/C++ programmers often forget that when invoking a method on an object in ObjC, you are actually passing a message to the object which has to be converted into a function call at runtime.  Great for flexible, extendable libraries – bad for speed.

So you can either start your development with core components using plain C calls, or you can do what I did and wait until the ‘end’ and use the profiler.  The ‘Instruments’ tool in conjunction with remote iPhone SDK debugging is great.  You can actually run the app on the device and get statistics about what you’re app is doing and when – without a huge penalty to performance.  

Take a typical recording and keep an eye out for the msg_send call, and how much time is spent there.  You may actually find that you’ve introduced a dependency lock that’s slowing things down or you may have an update timer that’s just being ridiculous and updating a billion times a second. 

But if you find out that a lot of time is spent calling msg_send, all hope is not lost.  You can still do some optimizations that help out.  For the other things I’ll talk about them later. 

In simple cases, you do some of the internal work of ObjC yourself and cut out the middle man (sourced from here):

-naive {
  for(i=0; i<50000000; i++)
    [obj hello];
}

-optimised {
  typedef id (*hello_t)(id, SEL, ...);
  hello_t ref = [obj methodFor:@selector(hello)];
  for(i=0; i<500000000UL; i++)
    ref(obj,@selector(hello));
} 

which will work in a lot of cases.

But sometimes, you just have to revert to C.  Go back to the profiler and see what’s happening.  If there are still a lot of msg_send calls clogging up your execution time, then you’ll have to strip out the offenders and just write C functions.  It’s really not that bad..

This post comments on the problem and some work arounds, and this is what I’ve found:

Problem:

A few devs out there have noticed the following symptoms

• The accelerometer will not respond via the delegate at all in your app about 5% of the time when running your app
• When combined with OpenGLES surfaces, the first drawn frame will be drawn between every new frame drawn to the surface.  This results in a flickering effect where a ‘ghost’ of your initial drawing is interlaced with your normal frames.  

Although some have reported these two problems being one and the same, I found them to be quite separate. I think many people are using the accelerometers+OpenGLES for games, and because the problems happen infrequently they seem related.  I could be wrong of course.  For the same reasons I could just be imagining that they aren’t related.

Work-arounds (not really solutions):

Accelerometer not working

For the accelerometer, many have found (and I have too) that the problem seems to go away if you set the update frequency and delegate much later on in your app.

[[UIAccelerometer sharedAccelerometer] setUpdateInterval: (1.0 / kAccelerometerFrequency)];

[[UIAccelerometer sharedAccelerometer] setDelegate:self];

Typically, you’ll call the above lines in

 - (void)applicationDidFinishLaunching:(UIApplication *)application

but that’s what causes the problems. Anyones best guess is that it just takes too long for the accelerometer to get ready some times and it just ignores your set delegate request. 

Flashing graphics

I can’t confirm that this fix works, but some have reported that using kEAGLColorFormatRGBA8 instead of kEAGLColorFormatRGB565 on your OpenGLES surface will stop it happening.  I’ll give it a try and post my results here. If anyone can confirm or deny this fix, we’d love to hear from you.