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.

In which George tries something new, is impressed, but still insists on doing things the old fashioned way…

OpenGL 2.0 – An apology

OK, let’s get this out of the way.  I haven’t got very far with the shader / GL v2.0 side of things.  However I have been busy.  My current day job is teaching a summer school course at the local University.  I’m lucky enough to get to teach Game Design.  For one of the lectures I wanted to do a case study of a commercial engine.  Unity seemed like a good choice, mainly because it’s cheap, reasonably powerful and cross platform – good options for budding game makers.  So rather than working on game code for Faerie I’ve gone back to prototyping ideas with Unity.  And it’s been great fun…

Getting Started with Unity

If you haven’t seen or heard of Unity before, here’s a quick run down.  It’s a cross platform engine that runs on PC, Mac, Web, iOS and most consoles.  It consists of an editor that is reminiscent of a 3d modelling package crossed with a programmer’s IDE.  Game Objects are dragged into the scene and arranged, terrains and vegetation can be added.  Game Objects in Unity work using a component model.  In other words, a ‘car’ as such is just a collection of components that each do their own thing – mesh, mesh renderer, physics collider, particle systems, transforms and so on.  These objects can also be built into hierarchies – a car and its wheels for example.

So far so good, but how do we write our game logic?  One type of component is a script component.  You can work in Javascript, C# or a version of Python.  Each script has a number of predefined hooks that let you interact with the game world.  The two main ones are Start() and Update(), which let you control initialisation and per-frame logic.  Other hooks include responding to collisions, handling mouse events and so on.  There’s a lot of power in this very simple system, as code typically sits alongside the object it acts on.  Variables declared as public become visible in the IDE, making tweaking game play trivial.

Getting started though is something that, for a coder like me, felt very strange.  The Unity site comes with a great collection of detailed tutorials that show off a lot of the engine’s power.  And this was part of my problem getting started.  The tutorials tend to mainly be of the “Here’s a mostly completed game, now let’s add some more stuff” variety.  Going through these you don’t really get a solid understanding of how things fit together, simply because there’s so much there.

Eventually though, I did find one tutorial on scripting that started from an empty scene.  From there, I was able to get to grips with adding one thing at a time.  After this, things started to fall into place and I found it much easier to make some progress.  There’s a lot of reference material on the Unity site – take your time to sift through it and find the tutorials that work for you.

Prototyping Faerie

Once I had a basic grasp of what was going on, it was time to build a prototype of Faerie.  One thing that Unity is very good at is prototyping – adding objects into a scene and attaching simple scripts to them is very straight forward.  User input, selecting objects and collision detection is all handled for you, leaving only the actual game logic to be written.

Faerie’s made up of a surprisingly small set of objects.  We have a collection of differently coloured leaves falling down the screen, which can be joined into a chain by tapping on them.  Complete a chain before it touches the ground and you score points and also fill up a ‘magic’ meter.  Miss enough leaves, or have a chain hit the bottom of the screen and your magic meter drops down.  If it hits 0, then it’s game over.  Fill it up and the combo / power up magic starts to happen.

Fumbling my way through the Unity API it took me about half a day to get the basic game play up and running.  Here’s a couple of screenshots, taken as I went.

Obviously it’s very primitive, but the basic game mechanic is in there and it feels fun.

After a little tweaking of variables to get the basic balance of the game reasonable, I packaged up a build and sent it to Sam for his thoughts.  Then followed a fairly lively Skype conversation regarding what needed to be fixed.  One thing that becomes very obvious when you do this sort of prototyping is that feedback for the user is not a luxury, it’s essential – even at as early a stage as this.  When the game world is made up of red and green rectangles the player needs every possible help to know that their actions are having an effect.

Tomorrow’s job is now to take Sam’s ideas and mine and work them back into the prototype.  This should be pretty fun as it involves trying different types of power ups.  There will be a few standard ones (slow down time, score extra points etc), but I’m keen to try out a few fun ones, like auto-chaining or perhaps something to do with Unicorns.  Definitely something to do with Unicorns.

Production Code with Unity?

So it’s probably fair to say I’m pretty happy with Unity.  It’s a well put together system and well worth a look.  I’ll definitely do a lot of prototyping with it.  But for production code I’ll still go with C++ and OpenGL for now.  Maybe I’m a masochist, but I like to know the specifics of what my code is doing, and to have the ability to tweak at the low level.

In which George gets called a lazy git and discovers himself in a deep hole, holding a shovel and wondering how he ended up in this trap again…

Analysis Paralysis

I don’t know if that’s a well known phrase or if I just made it up, but it perfectly captures what happened to me over the last week and a bit.  Last time, I mentioned I was moving on to look at OpenGL ES 2.0.  That’s where the trouble started.  Although I’ve done a lot of work with OpenGL over the years most of it has been using the fixed function pipeline, or if shaders became involved it was in addition to a predominantly fixed function set up.  This makes moving to OpenGL ES 2.0 a bit of a shock.

Why?

Because to maximise OpenGL’s adoption on mobile hardware, a lot of useful functionality has been ripped out by the Khronos group.  This isn’t a bad thing as such, but it does mean that a developer needs to supply code to handle things that the ‘full’ version of OpenGl handles for you.  One shining example is that there is no matrix stack or utility projection matrix code.  In fact the programmer needs to supply matrix information, vertex and fragment shaders in all cases – there is no default option to fall back on, no glPushMatrix(), glTranslate() etc.

So, there’s a fair bit of overhead involved in getting that first triangle on screen.  And this is where the trouble starts.  My typical desire is to write ‘good’, ‘reusable’ code.  But not having a working grasp of the best way to structure shader based code, this is not easy to do.  So a gradually tightening loop develops as I think, read and design a good solution.  Note that there’s no ‘do’ stage in the last sentence.  The more you think, the more cases you try to cover, the worse it gets.  You get nowhere.

So, long story short, not much has happened over the last week, although I have found some really good articles about component based design and sorting of graphical elements:

• Dynamic Components by Terence Cohen
• Fix your time step! by Glenn Fiedler
• Object messaging by Marcin Chady
• Ordering graphics calls by Christer Ericson

Note that all these links come from a great altDevBlogADay article by Marttin Pichlmair.  If you haven’t checked out altDevBlogADay yet, you really should as there’s lot’s of fantastic information coming from industry professionals.

So, a warning before you find yourself becoming an Architecture Astronaut:

Learning by doing.  This is the only practical way to tackle an unfamiliar technology.

Thoughts on shader based OpenGL

Having realised my mistake I have started to make a little progress. Between the Apple sample code and the OpenGL ES 2.0 Programming Guide, it’s fairly simple to get basic shader code up and running.  A note on the programming guide – it is an invaluable reference, but not a particularly easy introduction to the topic.

My first challenge was to pull the shader data out into a struct and provide some helper code to go with it.  That’s mostly working now, with a ‘ShaderEffect’ struct combining both vertex and fragment shaders into one object.  When the ShaderEffect object is initialised I also pull out the required attributes (colour, texture coordinates etc) for the shader.   This allows my mesh rendering code to activate only those attributes that are required, even if the mesh itself contains extra data.  All that’s left is to bind the shaders at render time and render your mesh.

Philip Rideout’s Shader Wrangler code is also a great help here, making it simple to combine shaders into a single ‘effect’ file and avoid loading the same shader multiple times.  So my effect file currently contains both vertex and fragment shader in one place.  Next up, I’ll add a ‘setup’ section as well, which can control things such as blending and culling modes.  The plan here is that rendering becomes a simple case of saying ‘here’s an effect, here’s a mesh now render it’, with all of the standard OpenGL state stuff being handled automatically.

So, not much achieved this week, but progress is being made by focusing on the small steps and not the big leaps.  Hopefully I won’t need @mysterycoconut to call me out as a lazy git again next week…

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”…

In which George lays out his initial project structure with the best of intentions, knowing full well that it’ll get all messy one way or another…

Every journey begins with a single step…

Yes I have been working on Faerie on and off for a while now, but this week marks the writing of the first actual lines of production code.  It’s an exciting time.  You have a blank canvas on which you can paint wonderful, clean, elegant and powerful code.  At least that’s how it starts.  Over time entropy, corner cases and flaws in your initial design have a tendency to muddy the code base.  But for now there’s wonder, cleanliness, elegance and the potential for power.

So where do we start?  For me it begins with the layout and structure of the project.  If you’re not a coder, you may want to skip all this technical stuff – I won’t be offended!  If you are a code nerd like me, perhaps this will be interesting to you, or maybe you can see flaws in the way things are laid out, or would like to share how you set up a project.  I’d love to hear what you think!

Stay on target!

The Faerie codebase contains four targets (at least for now).  The first target is the actual Faerie project.  It builds the Faerie app.  This target contains all the resources we use – textures, sounds and music, string resources, nibs and the like.  However this target contains virtually no code, just main.mm.  Why is this?

The answer is unit testing.  All the game code goes into a static library with the exciting name of GameLib.  By putting the code into a static library, it’s possible to unit test all the game code.  And it’s unit testing that comprises the other two targets in my project.  One is a static library containing the the UnitTest++ framework, and the last is an executable target that links the UnitTest++ framework, GameLib and all out test code.  I’ve described this set up previously if you’re interested in the details.  The advantage of setting up the code this way is that our actual app doesn’t need to include any testing code, yet we are able to test the exact library that is used in the game itself.  So the target structure looks like the image below.  Note the final step in the Faerie target, which runs the GameLibTests executable with every build – very handy!

There is one issue we need to address however.  Our nib files need to be in the Faerie target to ensure they’re included in the app itself.  And for testing purposes, all the view controller code is in the GameLib library.  This causes a problem because the linker doesn’t know that it should get the view controller code from GameLib, and so we get errors when the nibs are constructed at run time.  To fix this, it’s necessary to add the following to our “Other Linker Flags” setting for the Faerie target:

-force_load "$(BUILT_PRODUCTS_DIR)/libGameLib.a"

What about the code?

I find it very hard to create a new project from scratch, so I start with the OpenGL template and rip out the stuff I don’t want and reorganise the rest into a layout that suits me  Here’s the basic layout:

These groups in XCode are matched with an identical file layout on disk.  XCode doesn’t require this, but I find it too confusing if they differ.  As you can see, the Faerie folder contains basically no code.  It’s GameLib that has all the good stuff.  Acorn is all the standard code I carry from project to project – code to handle maths, loading textures, playing sounds and more – all that low level stuff.  GameLogic gets all the game specific code, and Views contains all the view controllers for my nib files.  Why the split between GameLogic and Views?  The main reason is that my view controller code is (by necessity) largely Objective-C, while the rest of my code is (as much as possible) pure C++, so it seems reasonable to keep them apart.

The Resources folder contains all the game assets, sorted by type and/or purpose.  By the time the game is done, there’ll be a lot of folders and a lot of files in here, so it’s good to keep them organised.

A simple trick to add a little polish

Here’s something truly simple that you can do in any app for a little extra style.  On startup, our app shows Default.png (or equivalent), and then once the main view is loaded it ‘cuts’ straight to the main view.  Wouldn’t it be nicer if we could smooth out that transition?  It turns out it’s easy to do.  Simply add a UIImageView to your main window, sitting above everything else.  The UIImageView should fill the screen and contain Default.png.  So what happens is that the main app loads and seamlessly replaces the loading screen with an identical screen, but one that we have control over.

Then, it’s a simple case of fading our Default.png image out, revealing the main view underneath, using a bit of code like this in your update loop:

float deltaTime = (float)gameClock->GetFrameDuration();
if (!loadingDefaultView.hidden)
{
    defaultViewFadeOut -= deltaTime / fadeDuration;

    if (defaultViewFadeOut < 0.0f)
    {
        defaultViewFadeOut = 0.0f;
        loadingDefaultView.hidden = YES;
    }
    else
    {
        loadingDefaultView.alpha = defaultViewFadeOut;
    }
}

*UPDATE*

Miguel, the mighty @mysterycoconut pointed out that this could also be done using standard animation calls in UIKit, so here’s an alternate version that gets executed in the viewDidAppear method…

- (void)hideLoadingDefaultViewDidStop
{
    loadingDefaultView.hidden = YES;
}

- (void)viewDidAppear:(BOOL)animated
{
    if (!loadingDefaultView.hidden)
    {
        [UIView beginAnimations:@"Hide loading screen" context:nil];
        [UIView setAnimationDuration:fadeDuration];
        [UIView setAnimationDelegate:self];
        [UIView setAnimationDidStopSelector:@selector(hideLoadingDefaultViewDidStop)];
        loadingDefaultView.alpha = 0.0f;
        [UIView commitAnimations];
    }
}

So what’s next?

I think after all this generic setup, it’s about time to add some actual game code, right?  Well the first thing I like to get going in a project like this is the flow from screen to screen, so that’s the next job on my list, adding the nibs and view controllers for the main menu, game, pause screen, credits and so on.  It won’t be pretty, but the aim is to get all the required buttons and such in place and working so that I can navigate around the app.  I find this to be a nice psychological stage to reach because, once done, I have a ‘complete’ app, and all I have to do is fill in the gaps!

After that, I need to make a key decision – OpenGL ES v1.1 or 2.0?  I think that 2.0 will win out, but I’ll delay that decision for another post!

A beginning is a very delicate time.

Know then that it is the year 2011.  The mobile space is ruled by the App Store.  In this time, the most precious substance in the Appverse is a successfully implemented game idea.  A successful App extends the Indie lifestyle.  A successful App expands possibilities and opens doors.

Ok, I think that’ll do, enough butchering of a great movie.

I have previously talked about my game-in-waiting Faerie.  Currently, Faerie is a simple game mechanic that has been prototyped and ‘just’ needs to be turned into a finished game.  Starting things has never been a problem for me.  But seeing them through to the end is a lot more difficult.  And so I have a plan.  A plan so cunning you could put a tail on it and call it a weasel.

The Plan

1. As of this post, Faerie officially enters production.  I can’t promise it will be a rapid process, but it is my plan to make demonstrable progress every week.
2. To add incentive for me to keep it up, I’ll write about the process as I go.  Posts will vary in nature, some technical, some design based, some will be about art style and some will be about marketing.  It is my intention to be as open and up front about the whole thing as possible.
3. If I fail to live up to my promises in 1) and 2) above, I fully expect to be harassed by you, my friends and readers, and to be called a lazy git.

As Sam Beckett would say, “Oh boy!”.  Here’s hoping this works.  If not, people seem to enjoy watching a train wreck so I hope it provides an interesting read either way

MVP

So there’s this new-fangled idea going around about “Lean Startups”.  But one of the key ideas for a lean startup is the idea of identifying your Minimum Viable Product.  In other words, what is the minimum product you can produce that is of sufficient worth that your customers will be willing to pay for it.  For someone with tight time constraints like me, identifying the MVP for Faerie makes a huge amount of sense.  It’s too easy to fall into the trap of trying to incorporate every great idea from every other game out there.  That way leads to madness, and stagnation.

So, what does my MVP look like?  Here’s the current idea:

• Game mechanics – a never-ending series of different coloured objects fall from the top of the screen.  The player creates chains of these objects as they fall.  Chains must either be all of the same colour, or all different colours.  Chains score points based on the rarity of the colours used and also the length of the chains formed.  If an unfinished chain reaches the bottom of the screen, it’s game over.  The player tries to last as long as possible, amounting as high a score as possible.  Ninjump and geoSpark are good examples of these kinds of games.
• Variety – to avoid things getting boring there will also be a number of ‘power ups’ that fall down.  Tapping one of these will, say, slow down time, or activate a points multiplier, or create an auto-chainer, or… It should also be possible to activate combo-like scoring by creating chains in quick succession.
• Audience – I want kids to be able to play the game and have fun, but I also want more serious gamers to find plenty to challenge them.
• Aesthetic – for various reasons, I’ve always seen the falling objects as being leaves falling in a magical woodland – chaining them together is a game played by Faeries (hence the name), and the result of scoring well is to bring life to the woodland in the background.  I’d love to pull off a sort of line drawing and water colour feel to the game.  See the image below by Linda Ravenscroft for an example of the kind of style / colours I’d like to work with.  I’m no artist, so this would indeed be a challenge!  How can I convey a similar feeling / impression with meager skills?

This image is from a great tutorial over at http://www.artgraphica.net

In terms of features, this is what I believe would make a worthy game, with everything non-essential removed (the plan is to add more in as updates, once Faerie has been successfully launched):

• Single ‘endless’ game mode
• Seamless in-game tutorial
• Players can choose one of three levels of difficulty to start on Easy (Kids), Medium (Normal Player) or Hard (Hardcore Master Gamer)
• Scaling level of difficulty as the game goes on
• Gradual introduction of more types of game object over time (as in Tilt to Live, geoSpark, Linkoidz etc)
• Satisfying visual and aural feedback – the player needs to enjoy the process of putting together chains – the game should make them feel like a Minor God of Leaf Chaining.
• Online leader boards, or in some form the ability to brag to your friends.
• Dynamic music that gets more frantic as time goes on.
• All standard iOS behaviour works as expected – save and resume, multitasking, player’s music plays in preference to game music and so on.

I think that’s it.  It doesn’t sound like much, but even given my minimalist goals, I still want the game itself to feel stylish, fun and well polished.

Here’s the thing…

This is the part where I’m going to hit you up for a favour.  What I’m hoping for by conducting this process in the open is to get feedback from everyone.  Is the game good?  Does it suck?  Have you thought of a cool power up?  Would this game work better with Space Marines than Faeries?  Should I use a swipe gesture instead of a double tap? Whatever your thoughts are, I’d love to hear them as we go.  I can’t promise everyone’s ideas will make it into the game – that way lies madness.  But what I hope to achieve by throwing this project open to the world at large is to take this rough idea of a game and reduce it to an elegant, streamlined and fun game.  The more opinions I can get, and the earlier I can get them, the better this game will be.

So, my first question to you is: does the MVP sound viable?  Is it enough, or does it need something more before I can justify asking $0.99 or $1.99 for it?  Even at this stage, is there something that could be cut back on?  And a second question: what of the game’s theme / aesthetic (faeries, woodland scenes, water colour rendering) – does it sound promising / appealing?

A Commitment

Which brings us to today…

Faerie

So, let me introduce Faerie (a working title).  It’s still in the very early stages of development, but it’s had encouraging feedback so far from people who have seen it.

Goals

Theme

Art Style

Mechanics

Faerie began as a desire to make a game that my kids could play that still felt challenging to play as an adult.  Combining Bejewelled style scoring with geoSpark (App Store link) style action was the plan, although I’m happy to say the resulting mechanic is quite different now – including elements from Tetris, Whack-a-mole and Bejewelled.  This is perhaps the most sensitive area for me, so I’ll leave it at that.

So when’s it ready?

So, not quite the ‘Full’ Monty, but now you know what I’m working on, please bug me to get it done before my kids grow up!