Acorn Heroes

In which George is welcomed back into the fold after a long time in the blogging wilderness…

iDevBlogADay

First off, it’s nice to be back and contributing to iDevBlogADay.  When Miguel first kicked this off I don’t think anyone ever expected it to be as successful as it has been.  So a big thank you to Miguel and everyone who has contributed or been a reader.

What’s that?  Never heard of iDevBlogADay?  Never mind, welcome anyway!  Chances are if you’re reading this you have an interest in iOS development, and you should check out iDevBlogADay.com – there’s a wide range of articles covering all aspects of iOS including coding, design, marketing, art and more.  If you are specifically interested in game development, I can also recommend altDevBlogADay, which covers game development in general.

Faerie?

Part 6?  Faerie? If this is the first time you’ve come to this site, then you may be wondering what Faerie is.  Faerie (place holder name) is my next game project for iOS, and I’m documenting the process as I go.  Each article is reasonably stand alone, but if you’re interested in starting at the beginning, the first article can be found here.

Paper Prototyping

Last time, I described the process of using Unity to do some rapid prototyping of Faerie’s basic mechanics.  What I forgot to mention was that there was a stage before this that was even more rapid and most definitely lower tech.  It involved nothing more complicated than some paper, a die and some poker chips.

It may seem strange to prototype an action/puzzle game this way, but in fact it worked surprisingly well.  And it was fast.  Getting a code prototype up and running takes time, even for the fastest / best prepared coder.  Working on paper I had the basics ready to test in about five minutes, and was able to iterate several versions of the mechanics in an hour.

The first step was to decide how to represent the game’s mechanics in a turn based way.  I used different coloured poker chips to represent different coloured leaves from the game – leaves are ‘chained’ together to form combos, with the player losing points / life if an unfinished combo touches the ground at the bottom of the screen.  The initial rule set was something like this:

• Leaves fall d3 + 2 inches each turn (i.e. roll a die, halve it and add 2).  This there was one roll per turn, applied to all leaves uniformly.
• Introduce a new leaf each turn with a randomly chosen colour.
• The player can then take one action, either to select a new leaf to add to a chain or to ‘finish’ a chain.
• A chain must contain only leaves of the same colour, otherwise it is invalid and all the leaves are destroyed.
• A finished chain is scored based on length (1 point for the first leaf, +1 for the second, +2 for the third, +3 for the fourth and so on).  This value is then multiplied by the value of the chain’s colour (1 for red, 2 for green and 3 for black)
• Leaves that hit the ground are removed from play, and if they are part of a chain, all leaves in the chain are destroyed.

It’s taken longer to type those out properly than it did to set the game up and start playing.  You may be wondering why the leaves move a random distance each turn.  This was introduced to add a degree of uncertainty in the player’s mind as a replacement for time pressure / reaction times that will be present in the real time version of the game.

As it stands, this wasn’t fun – it was lacking goals, end game conditions, balance and more.  But what became immediately apparent was that the core fun element in the game was choosing which pieces to select and when to finish a chain.  So I iterated on the ideas a little, introducing or modifying rules to maximise this aspect of the game.  Over the next hour or so I was able to try out the following changes:

• Different coloured leaves fall at different rates.  High value leaves fall faster – this gives the player a tough choice between the easy, low scoring option or taking a chance on the faster, high scoring colours.  My initial intention had been to simply make valuable leaves less common, but I like the speed variation much more.
• I added the option to make ‘rainbow’ chains, that is a chain that includes different coloured leaves, so long as the chain has the same number of each colour.  In other words 2 red + 2 green or 1 red + 1 green + 1 blue are both valid, 1 red + 2 blue is not.  Adding these in gives the player a ‘bail out’ option if they can’t make the chain they intended to.  A nice reward for fast thinking players.
• Tweaking of leaf speeds / points values and player actions.  It was possible to very quickly balance the game – spawning twice as many leaves, allowing the player two actions a turn and so on made the game play much better.
• Experimenting with end-game conditions.  One thing that’s not immediately clear from the basic mechanic is how the player can lose or end the game.  I tried a few ideas and chatted to Sam before settling on the idea that the player has a ‘magic’ meter that fills up as the player scores points.  Fill it up to unlock combos / power ups.  The negative is that the magic meter empties with every leaf that hits the ground, and empties even faster when a chain hits the ground.  When the meter is empty, it’s game over.

So, in about two hours at most, I was able to test and iterate the basic logic of Faerie without once touching a keyboard.

Give it a go!

Paper prototyping can be tried with almost any game idea.  It’s a great way of looking at the core mechanics of your game without the computer colouring your perspective!  It takes very little time, and can be done with pen, paper and a little imagination.  You really have no excuse for not trying it!  If you’re interested in developing your paper-prototyping skills, I can thoroughly recommend Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber.  Each chapter in this book looks at different aspects of game design and how they can be prototyped in a non-digital environment.  You’ll be surprised at how well many genres, first person shooters for example, can be adapted to work with pen and paper and a few counters.

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!