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…

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?

Got skillz?

Any good software developer is always on the look out for new techniques or tools. But when was the last time you actively cultivated your social skills?

Does this sound unecessary? We’re coders after all, dealing with syntax and pixels, right? Well consider this. Our games are nothing until we’ve put them into the hands of our players. It’s a social contract we have with the players to offer them a fun and engaging experience.  And most importantly, if they don’t like it, you’re up the proverbial creek without a paddle.

If we’re going to make our game great, we need to see it’s effect on potential players. For the best results, we need to do it early and often to avoid wasting time on ideas and implementations that just aren’t good.

So, assuming you’re buying into this argument so far, the next step is to get some feedback from players. Giving and receiving feedback is very difficult to do well, and it’s a skill that continually needs to be trained and refined, alongside your other mad skillz.

Giving feedback

Giving feedback can be difficult – you need to let the game developer know what doesn’t work, but without leaving them whimpering in a corner when you’re done. The trick here is to think of a hamburger’s fluffy buns. The idea is that you wrap the “meat” of your concerns in between a nice couple of “fluffy” buns to soften the blow.

Example:
“Your game crashes all the time and is unplayable.”

Example:
” I like what you’ve done with the art style, and I can see a lot of promise in your game Mega Zombie Ninja Defense HD. However, I’m having trouble with the game quitting unexpectedly on me. It happens fairly regularly at the start of each level and is making it difficult to get into the game. I’m keen to get further into the game, please let me know if I can help in tracking down the problem.”

So, both of these comments say basically the same thing right? But which would you rather receive from a beta-tester? Here’s a few key points:

• The first example comes across as a personal attack on the developer, mainly through the use of the word “Your”. It’s the written equivalent of stabbing your finger at someone to make a point. The recipient of this comment immediately becomes defensive and unwilling to take on board your comments.
• Also in the first example, the phrases “all the time” and “is unplayable” are absolute (rather than subjective) statements about the game that may not be true. “Crashes all the time for me“ may be true, but can you really speak for all the other testers playing the game?
• In the second example, the initial compliment puts the developer in a receptive frame of mind, ready to listen to your concerns – establishing a dialogue. Talking about “the” game rather than “your” game makes for an objective discussion, rather than an emotional one.
• Expressing the problem in terms of “my experience” means you’re open to the possibility that it’s not the developer’s fault – perhaps you’ve updated to a new OS reveision that they haven’t had a chance to test yet, or perhaps you’re jailbroken phone running a Linux kernel may have something to do with the issues you’re having.
• You’ve knocked the guy down and given him a kick in the guts, telling him his code crashes (even if it’s true, it’s not nice to hear), so wrap up by saying something nice to pick him up off the ground again feeling positive about what needs to be done.

There’s more at stake here than just being all new age and caring. It’s about being able to get to the heart of a problem and fixing it. The fact that it can help build a stronger relationship with someone is just a nice side effect.

It is better to give than to receive

OK, so let’s say your the king of fluffy bins, and people love you as a beta tester because you give honest, helpful feedback. Now it’s your turn to send a build out to a handful of testers.  It’s hard.  You’re feeling a bit nervous – hoping they love the game, terrified that they won’t. And then you get this:

“Man this sucks, couldn’t you do any better?”

Ouch. What can you do? First off, try not to take it personally. You asked for peoples opinions, you have to be prepared to take the good with the bad. If people only offer praise, you’re game will suffer for it. Just watch American Idol some time if you don’t believe me. All those poor people who can’t sing to save themselves.  I can just imagine their well meaning family telling them “You’re fantastic, you can do anything you want to do”.

OK, so we’ve gotten over the initial shock of the feedback. Now it’s time to ask yourselves “Why did this person have such a bad experience?” There’s obviously a problem here, and you need to develop the skill to find out what’s going on. This is where the “Five Whys” technique comes into play. Let’s imagine how the conversation could go:

“Man this sucks, couldn’t you do any better?”

“Wow, I’m sorry it didn’t go so well for you, can you give me an idea of what went wrong?”

“I just couldn’t get into it.”

“Why was that, was it too hard? Did the controls make sense?”

“It was OK until I reached the first platform, I just couldn’t get up onto it.”

“Why was that, were you double jumping?”

“Double jumping? You can do that?”

“Yeah, just triple tap the player again after he’s jumped. Did you read the instructions at the beginning of the game?”

“Oh those, I kinda skipped through the last seven pages.”

“Fair enough, maybe I should look at shortening them down a bit. Triple tap may be a bit tricky too, I guess I could look at using a tap and hold or something. That shouldn’t take too long to fix. If I sent you a new build, would you give it another go?”

“Sure, sounds good”

Wonderful, a happy ending. With a little effort on our part, we’ve turned a flippant, unhelpful response into some valuable information:

• If a player can’t master double jumping, the game is unplayable.  Is it really that important a skill for our game?
• Triple tapping is a pain.
• Our “how to play” instructions are too long.
• Maybe we should put the first time the player is required to double jump further into the first level?
• Perhaps we can shorten the instructions and break them up into smaller chunks, delivered as needed rather than all at once?

All that from “Man this sucks, couldn’t you do any better?” . The idea of “five whys” is to strip away the superfluous and get at the heart of a problem.

Wrapping up

A bullet list to wrap up:

• Avoid being personal (using “you”), unless you’re talking about yourself (“I think”).
• Think of it as a puzzle to solve objectively.  The answer is there, you just need to develop the techniques to find it.
• “Never attribute to malice that which is adequately explained by stupidity.” A person who’s gone to the effort of offering criticism may have a valid problem they don’t know how to communicate.
• Your harshest criticism is also you’re greatest opportunity for improvement.
• Be wary of feedback from friends and family – avoid asking what they think – rather ask them for ways to help you improve and fix the game.

So, maybe there is something to being nice after all. Mastering the art of giving and receiving feedback may seem unimportant at first, but it’s one of the most valueable tools you have.

What do you think?

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!

Some days it’s hard to think of something to write about, and other days something just falls in your lap. Happily this week it was the latter. It all started with Miguel (as these things often do) – a.k.a. @mysterycoconut on Twitter – posting this article about connecting to an iDevice via telnet while running your App. Using this technique it becomes possible to rapidly tweak parameters on the fly or in fact do all sorts of crazy stuff.

Needless to say I jumped on this idea to aid in tuning my current game prototype. I’ve just reached the stage where rapid tweaking of variables is going to help focus and refine the game play. Miguel suggests hooking a Lua scripting engine into your code, but I thought it would be fun to create my own, plus most of my code is C++ (rather than Objective-C) and I’ve found binding Lua to C++ to be a fiddly process in the past.

The corresponding code for this article can be found here. Note that the DebugServer code comes from Miguel’s article, and the AsyncSocket code comes from here.   I’ve added a minimal amount to Miguel’s code to pass received commands on to the DebugUtils functions found in Debug.[h|mm]. I haven’t had time to create a complete sample project, but the code provided should drop into any existing code base with minimal fuss. If the coding style looks a little strange, you may want to also read this and this.

So, let’s start at the end and work backwards, which I often find to be an effective technique. When tuning a game we spend a lot of time tweaking variables and constants – maximum speed, rate of fire, gravity, item prices, animation durations etc. Wouldn’t it be nice to open up a telnet session to your App and enter a command like “gravity = -8”? Alternatively, maybe there’s a set pattern of enemies that causes a rare bug. Wouldn’t it be nice to enter a “SetupWeirdEnemyPattern” command for easy testing?

So, we have two common scenarios – tweaking a variable and executing a function that alters the game state in a slightly more involved way. The code below allows us to do this. Variables and functions can be “registered” and given a name, which we can then use to adjust values or execute functions via our telnet connection. To make it simple to pass in parameters to these functions, we pass in a set of text parameters using argc and argv, just like the main() function of a C++ program.

Let’s have a look at the public interface to this code:

typedef bool (*DebugCommandFunc)(int argc, char *argv[]);

namespace DebugUtils
{
    void Initialise();

    bool ProcessCommand(const char *command);

    bool RegisterCommand(const char *commandName, DebugCommandFunc commandFunc);

    bool RegisterVariable(const char *variableName, bool *var);
    bool RegisterVariable(const char *variableName, int *var);
    bool RegisterVariable(const char *variableName, float *var);
}

Not much there, is there? The guts of it is in the ProcessCommand() function, where we pass in a string, and magic happens. Or, to provide an example:

bool ResetGameCommand(int argc, char *argv[])
{
// Do stuff here to reset the game state
}

DebugUtils::RegisterCommand(“ResetGame”, ResetGameCommand);

And later, through a telnet connection, we enter “ResetGame”, which in turn calls:

DebugUtils::ProcessCommand(“ResetGame”);

And, just like magic, we reset the game state.

Or as another example, we could register a game variable, say…

DebugUtils::RegisterVariable(“gold”, &gameState.pileOfDubloons);

And then, through the telnet connection, we can tweak this value mid-game, by entering:

“gold = 10000”, or “gold *= 2.0”

I’ve intentionally kept this system as simple as possible, but there’s a lot of power here. It’s very simple to register variables or add short pieces of code that can be run as needed. Just a few examples – turning on debug drawing to see bounding boxes of physics objects, changing the value of gravity or a jump pack’s thrust, loading an arbitrary level, turning off collision detection – the sky’s the limit.

The key thing here is to let you spend as much time as possible refining and tuning your game, because as Jesse Schell describes in his excellent book The Art of Game Design: A book of lenses:

The Rule of the Loop: The more times you test and improve your design, the better your game will be.

In other words, by removing the code-compile-run stage from tuning our game, we can create a better game in less time. Hopefully this code, combined with Miguel’s will provide a simple way to help you refine and debug your game.  Happy tuning!

P.S. I was planning to include a description of how I used TDD (Test Driven Development), but figured this post was long enough. If it’s something you’re interested in though, leave a comment or drop me a note on Twitter (@GeorgeSealy) and I’ll put together an article.

P.P.S. Yes, there’s a few things that could be added to this code to make it even more useful. At the moment it’s not possible to pass a parameter that’s a string with spaces or new lines in it. To do this, you just extend the tokenizing code to respect quoted parameters like “This is a string”.

P.P.S. I’ve resisted the temptation to allow more complex calculations such as “percentComplete = 100 * itemsFound / totalItems”. Most of the time all you want to do is tweak values. If you need this much power, hook in Lua as Miguel suggests, don’t roll your own as it becomes increasingly difficult to maintain as a project matures.

P.P.P.S. I’ve also just realised one of the more useful things I’ve left out – if you just supply the name of a variable on its own, then the variable’s value should be either returned via telnet or printed out using NSLog or similar.  There’s nothing worse than finding the perfect value for something and then being unable to see what it is!

P.P.P.P.S. The observant amongst you may have noticed that the link to Jesse Schell’s book is an Amazon Affiliate link, meaning if you follow that link and subsequently purchase something I may get a small commission. I will only ever put such links to books that I have bought myself or at least read cover to cover and would recommend.

Perhaps I expect too much?

I was playing the demo of Torchlight the other day.  It’s a beautiful game – art and game play honed to near perfection.  So why after a couple of hours of playing did I feel hollow inside?  What was I doing?  Why?  Was this even fun?  I love this sort of game – I lost vast quantities of time to Diablo, and enjoyed it.

So what’s the difference here?  Here I was, avidly collecting loot, leveling up and so on, flying through enemies with happy abandon.  I think that ultimately that’s all there was to it.  Fight / loot / fight / loot.  Where was my motivation and back story?  Where was the momentary pause to plan my attacks before diving through a door to tackle the nasty boss monster?  Half the time I didn’t even register that I was fighting a boss until I was picking over his corpse.  What level was I on?  What made this one stand out from all the others?

I’ve felt this way before, playing Bunni Bunni, designed by Danc, who’s blog is an inspiration and well worth reading.  I found myself playing it to completion, but was left with nothing of value to take away from the experience.  It’s a carefully constructed task / reward structure, tuned to the point where conscious thought dissappears.  It’s akin to grind in MMO’s.  Don’t even get me started there.

When designing games, we talk about addiction as if it’s a good thing – the ultimate goal.  If that’s the best we can do, I need to find another hobby.  Fortunately, there’s still plenty of scope for story telling (Dragon Age), exploration (Small Worlds) and deep strategy (Galactic Civilisations II) and simple beauty (Braid, Aquaria).

I guess what I’m saying is that with a family and work, my spare moments playing games are precious to me.  Playing a game ‘just to fill in time’ is pointless.  I want to have an experience, one that I’ll reflect on later as worthwhile.  I really wanted to like Torchlight, but I just can’t.

Or is it just me?  Let me know what you think…