Acorn Heroes

In which George shows off some really ugly screens, ponders OpenGL and answers an important question…

Screens!

I mentioned in a previous post that one of the first things I like to do when starting a new project is get the basic flow from screen to screen sorted out.  First off, I looked around at games I enjoyed to see what they do well.  In particular I’d like to let the player jump straight into the game with the minimum of fuss.  Ninjump, one of my current favourites, is a good example to copy here.  The main menu has three buttons that let you jump straight into a game (there are three different game modes).  Also, I like their pause screen, which only has two options: resume or main menu.  So without further blather, here’s the first draft…

The first screen is the loading screen, using a placeholder image.  It gives you an idea of an effect I want to use in game – the background scene is initially grey and lifeless.  As the player starts stringing together chains and combos, splashes of life come into the background, adding colour and excitement as the player does well.  The main menu has three large buttons, one for each game play mode:

• Survival mode – keep going for as long as you can, score as many points as you can.
• Time Limit mode – much like the Sprint mode in Linkoidz , the aim here is to score as many points as possible in a set time frame – great for people who love scoring mega-combos.
• Challenge mode – this one is a little less defined, but will probably require the player to get specific combos in a given time.  If they can get the required chain(s), they get a time bonus to keep going.  There’s still plenty of room to re-think this idea later.

Now I know that previously I’ve talked about a minimum viable product.  So why include three game modes?  The simple answer is that if I’m to have a free version of the game, then the full version has to add something extra.  Hence three game modes instead of one.  However, while the modes are reasonably distinct from a gameplay point of view, there’s not a lot of difference in them from a coding point of view.  So I’m hopeful that for a small amount of work I can significantly increase the game’s value from a player’s point of view.

Otherwise the main menu is fairly standard.  The new ticker will incorporate ideas from a great post by Markus.   All of the extra screens (options, help etc) will be single page screens with a back button to return to the main menu.  In each screen, the brightly coloured background is an OpenGL view.  The current plan is to use this to render subtly animated backgrounds for all the screens.

All of these screens are implemented using standard UIKit views and controllers.  I have an overall controller that maintains a stack of screens, and new screens can be pushed on to the stack, the current screen can be popped or a new screen can replace the existing stack.  It’s a nice simple mechanism, but it means I can, for example, have a settings screen that can be reached from the main menu or the pause screen, and when the settings screen is closed it can just ‘pop’ itself leaving the original screen behind.  While none of the screens are in any way pretty, they’re functional so I can hook in more detail as we go.  Next up though it’s time to get some basic rendering code up and running…

OpenGL v1.1 or v2.0?

So last week I said I would need to decide between the two possible versions of OpenGL.  Supporting both is a headache I don’t need, so it’s one or the other.  In the end, I’ve chosen to go with 2.0, for the following reasons:

• I’m planning to support only iOS 4.0 and up, simply to keep things under control.  I’ve read recently that the number of devices running older versions of iOS is surprisingly small – maybe 10%.  By supporting only iOS 4, there is potential to use lots of useful frameworks – Accelerate, gesture recognizers, Game Center and so on.  It also means that most of the target devices will support OpenGL ES v2.0
• I have a lot of experience with ‘old school’ OpenGL, but far less with shaders.  This is something I want to learn more about.
• I’m a programmer, not an artist.  By using a shader based engine, I have the opportunity to use my technical skills to give me an edge over purely sprite based games.  It’s a chance to produce a look and a style that can’t easily be matched with simpler sprite based engines.
• There’s a number of cool effects I have in mind that will be difficult to implement with a fixed function pipeline.  I plan to revel in the freedom 2.0 gives me like a pig in muck.

Ok, so maybe there are more rational arguments that could be made in favour of using 1.1, but in this case my personal motivation will be much higher using a shader based renderer.

I’m hopeful that by next week I can share some of my initial progress with the new OpenGL.  There’s a lot more to do before I can get pixels on screen and I’m learning as I go, but a basic plan of attack is starting to form in my mind.

And finally, what does success mean to me?

Noel asked me an interesting question after my first post:

I tried to answer in 140 characters or less, and failed miserably, so here’s a more detailed answer, split into two parts.

Financial success

Sam and I set up Acorn Heroes as a part time business outside of our day jobs.  This has obvious disadvantages in terms of time available, but it removes the absolute necessity of covering our mortgages through App sales alone.  Which is good, looking at our current sales to date  So financial success for us isn’t just a matter of surviving as Indies, it’s more of a sliding scale:

• Level One – Not failing.  The first level of success is just to reach the finish line and publish Faerie.  Of all the levels of success, this is the most important!
• Level Two – Pocket Money for gadgets! The second level is about making enough money to cover our costs (web hosting, developer’s license) with enough left over to, say, by an new iDevice each, or perhaps new MacBooks.  So we’re talking about a few thousand dollars in app sales.  With a bit of a nudge we should hit this mark this year.
• Level Three – Successful enough to up our game. We are a 2 person team, and unfortunately we’re both programmers.  We’re fortunate enough to know some great artists and designers, but not yet successful enough to afford to pay them.  Having enough money attached to a project to cover outsourcing art, design and music tasks would be a huge boon.
• Level Four – Financial freedom! Every Indie’s dream, the chance to work on your own project’s without worrying where the next meal is coming from.  Making enough in sales to cover a year or more in terms of salary.  Anything beyond this is gravy.

But money’s not everything, which brings me to…

Personal success

One of the main reasons I started working on my own iDev projects is that writing software for other people can get a little tiresome.  I was well into my thirties and the idea of making the software I want to make and selling it to and interacting with the end user directly has a huge appeal.  So in terms of personal success…

• Level One – Not failing.  See above.  That first copy sold to a person I don’t know yet is a wonderful ego boost to a man with my insecurities.
• Level Two – Positive feedback. An extension on the first level is when I get a chance to have positive interactions with customers, either through twitter, reviews or email.
• Level Three – Critical Acclaim. Receiving a positive review in the press, particularly from the likes of Touch Arcade, Kotaku or TUAW would be a defining “We’ve made it” or “We can do it!” moment.
• Level Four – The “You did this? effect. I think for me the ultimate success would be knowing that tens of thousands (or more) people had bought my game and were playing it often.  The  best part would be the moment someone I’ve just met shows me their favourite game, and it’s the game I wrote.  For me, professionally, I think that would be a highlight.

So I hope that answers your question Noel!  I guess my sense of success comes from having the freedom to make games at all.  From there on it just gets better.  Faerie is built around a theme and game mechanic that should have reasonably wide appeal.  Really now it’s just up to me to implement it well and get the word out there.  As one of my friends like to say, “It’s all over bar the typing”…

We’re currently prototyping some ideas for our next game. This time round we’re looking to do something fun with light and dark. Unfortunately the fixed OpenGL pipeline has a fairly standard look to it, and we can’t move to using shaders in OpenGL 2 without alienating a large number of people (including ourselves – our personal devices are both iPod Touches).

So as well as game play ideas, we’ve been prototyping the tech we’ll need to bring our world to life. The game will be 2d, but we really want to find a good way to render lights and shadows to create a dark, threatening experience.

After some Google-ing I found a good starting point over on GameDev.net. The basic idea is that each light is rendered into a buffer (the alpha buffer in this case), and then any shadows are rendered on top, blacking out the light. The alpha buffer is then combined with the scene geometry to add colour to the scene.

Fairly quickly I was able to get the basic algorithm up and running. The problem though is that each light requires rendering a screen’s worth of data, and frame rates drop drastically after adding more than 2 or 3 lights. So I started looking around for other options.

One idea that appealed was to render all the lights into a single buffer, and then use a single pass to lay this back over the scene. The problem here is that we can’t just render each light’s shadows into the buffer as black.

The answer here is to calculate the shadows for a light and incorporate them into the mesh used to render the light – i.e. instead of, say, a circular triangle fan for a light source, we generate a mesh for the circular fan minus the shadows.

So, after a few false starts I managed to get the basic algorithm working, and you can see its development in the screen shots on this page. The good news is that we can have large (double digit) numbers of lights in a scene, all casting shadows and all able to be moved or turned on and off dynamically each frame. Currently performance is about 45fps on a 2nd gen iPod Touch, but I’m fairly confident that can be drastically improved with some basic optimisation.

Once I’ve got the code properly under control, I’ll write an article covering the technique in some depth, if people are interested.

The last screen shot here shows the algorithm working at the moment. I still need to add spot lights rather than point light sources, but that should be a fairly simple thing to add. There’s a couple of bugs still to iron out too, but I think it proves the concept well enough to let us move onto prototyping other parts of the game. The addition of textures makes a huge difference too. While this is still very rough, I think there’s some real promise here, and can’t wait to start building the game that makes the most of it!

There’s one type of system that’s present in almost all games, and yet has very little functional value. It’s pure bling. I’m talking about particle systems and, when well designed, they can add greatly to the character and style of a game. When implemented well, a particle system can be applied to a wide variety of effects – rain, fire, explosions, blood, splashes, smoke and even some that might not be so obvious, such as grass or footprints.

Particle systems also lie between the realms of artists and programmers, so they make an appealing option for a company built around two programmers with limited artistic abilities!  So in this article (and the ones that follow on from it) I’ll jump on the bling train and discuss the design, implementation and optimisation of a particle system engine for the iPhone. Here’s my want list of features from a design point of view:

• The ability to manage a wide range of types of particle systems.
• Creating a new particle system should require a minimum of coding, and rely on the underlying engine to handle the more mundane tasks, such as rendering, frustrum culling, memory management and so on.
• Particles should be able to act as emitters, generating new particles (or maybe even entire particle systems?)
• Rendering should be as fast as is feasible – the more particles we’re able to render, the more we can achieve visually.

From a technical point of view, there’s a lot of issues to address:

• Designing base functionality that can be easily extended with the minimum of code.
• Avoiding frequent memory allocation (this can be a significant performance killer).
• Choosing between point sprites (fast) and textured quads (more flexible).
• Fast floating point operation – particle systems typically involve massive numbers of vector operations.
• How to store and hand off data to OpenGL for maximum efficiency - because of a particle systems dynamic nature, we’ll be resubmitting our vertex data every frame.

So, armed with a set of design goals, it’s time to do some hunting around for inspiration.  One of the better articles out there is this one by John Van Der Burg.  Also, Apple offer some handy tips for good OpenGL performance on the iPhone here.  There’s also some useful tips in various Game Programming Gems books.

Wow, look at me still talking when there’s science to do.  I’ll wrap this up here and get some coding done so that I can have something pretty to show off next time…

*Update* Brandon Mantzey very kindly pointed out a glaring bug in the code accompanying this post… Never fear, I’ve tracked down the idiot responsible (me), and it’s all good now. The bug was actually two bugs – first I was confusing the width in pixels of a character’s texture and the space it takes on screen. Secondly I was working from the bottom left corner of a string, where as I should have been working from the top left. Thanks Brandon for encouraging me to fix this! The link in the paragraph below now has the updated code.

A bit of a change of pace this week as we dive into something more technical.  Code that accompanies this post can be found here, and is free for you to use as you see fit.

While OpenGL provides a lot of graphical power, it’s typically at a fairly low level, giving the programmer a set of tools with which they can build higher level, more useful code.  Rendering text is one example of this.  Pretty much every OpenGL application needs to put text on screen at some stage.  But with no built in font rendering support, we’re left to our own devices.  In this blog I’ll show you one easy way to get text on screen. We’ll end up with something like the screen shot on the right.
(continue reading…)