A potpourri of iOS game programming lessons 

The development of my game Kondrian is coming to an end.

Here is a miscellany of what I think we’re useful lessons, each too small to warrant a blog post:

  • Each of the levels in Kondrian can be 100 x 100 tiles wide. It’s simple enough  to only draw the tiles when they are on screen, but I also created a scheme a bit like UITableviewCells in a UITableview in order to conserve memory. There are in fact only about 200 tiles (depending on whether its an iPhone or iPad) created, and they are reused when they go off screen. Reusing usually involves giving the tiles the appropriate texture for a tile potentially appearing onscreen in the direction that the player is moving.

  • All sprites (and the vertices, indices, VBOs VAs) are created at startup.
    When a sprite is needed it is de-queued and enabled, only enabled sprites are updated and drawn. No on the fly malloc-ing or creation of gl buffers.

  • All enemies within a specified distance of the player are in a local group, once in a local group the enemy stays in that group until it is disabled/enqueued (for example killed). Enemies outside this group have a simpler update process – so no collision detection with other moving sprites (but still with the background – walls), no AI, no accompanying sprite updates (eg shadows, shields) and of course they are not drawn.

  • glprogram seems to be slightly  faster than using GLKBaseEffects  - certainly my shaders are much simpler than the default one by GLKBaseEffect. However sometimes the profiler erroneously reports repeated gl calls (eg glUniformMatrix4fv() thinking that the same uniform is being updated within the same draw cycle – but it isn’t.

  • Lower device utilisation does not necessarily lead to improved frame rate – eg setting view.contentScaleFactor to 1.0 for the iPod touch4G brings device utilisation under 25% – but the FPS would often still drop below 55.

    Doing no drawing would keep it at 60fps. This issue could have been caused by slow framebuffer loads – a common reported error on the iPod touch 4G (perhaps caused by my code or the GLKViewController) – Perhaps the device utilisation is independent of this issue – e.g. it could be just a bandwidth issue, the pipe might not be big enough – and the device does not have to work that hard to fill it. For the moment I am blaming GLKViewController. I am however not changing it,just reverting to 30fps for older devices.

  • The update delta given by the GLKViewController  when running at 30fps seems really inaccurate, with a device utilisation of 13-15% the delta is sometimes 1/15 of a second. I think this is a reporting error not reality. The velocity of the player is multiplied by the delta, so with changing delta (with varying frame rate) the velocity should appear constant – but it is in fact quite jittery. Setting these possible anomalous delta reports to 1/30 creates a much smoother movement. This suggests to me that the actual frame rate is the preferred 30 fps not the 25-35 FPS often suggested by the delta. Instruments does not pick this up it says its a constant 30 FPS – perhaps because it only happens one frame in ten.  This issue does not occur at 60fps the delta seems accurate, the movement smooth.

  • Using custom UIGestures attached to invisible views placed on top of the main GLView works very nicely, and the invisible views do not seem to affect FPS.

  • I went through about ten different player movement control systems – just one of those things you have to try out. I still get complaints about how hard it is to control compared to Jetpack Joyride. This is not a one tap game however.

  • Game Center – this book:

    makes it easy, although it provides no solution to the constant reauthorising after entering foreground (after fast app switching).

  • Flurry is very easy to embed – lots of useful information tracking – of course don’t do any Flurry calls at critical action times. Playtomic didn’t work with ARC, and they didn’t respond to my emails.

  • Finally, sitting next to an artist is five times more productive than working with one remotely, one can iterate through ideas much more quickly, many ideas bounce back and forth leading to much better results.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>