Time for a short break from Faerie stuff this week.  For three months at the end of last year I was contracted to work on a game for Runaway in conjunction with National Geographic.  We had a fairly simple brief – build a game around based on the TV show “Clash of the Continents“.  Clash was about a space traveller who, traveling at the speed of light, returns to Earth to find that some 250 million years have passed.  What has changed and why?  Is there any trace of Humanity?  Are the continents even recognizable?

The show is a great look at the changes our planet undergoes on a time scale that we can barely imagine.  We had three months, and a small team.  What sort of iPhone / iPad / Flash game could we create in that time?

The resulting game is called Puzzle Planets.  It’s an action / puzzle game where you need to create planets from the core outwards in three stages – adding tectonic plates, pulling continents out of the water and finally creating a stable environment for life.  If you want to know more you can see a gameplay video here, or get it on the iTunes store here.

But if you’re reading this article, chances are you’re mainly interested in iOS development.  Let’s have a look at how the project went.  The final team was comprised of four programmers (not all full time, and not all at the same time), three artists a UI/UX designer and a creative director / project manager, plus support from National Geographic.  The code base uses OpenGL and mostly C++ (see notes on my current coding style here).  3d assets were built in Cinema 4d and exported as .obj files before conversion into final game form using a custom-made level editor tool.  The game’s creatures and UI were built in Illustrator and the textures, backgrounds etc mostly came from Photoshop.

On the project management side of things we used Google Docs for all documentation and SVN for source control.  Hudson was used to handle CI and AdHoc builds.

What went right

Working with artists

It’s been a while since I worked on a team with great artists and I’d forgotten how much of a joy it can be.  Puzzle Planets required tight co-operation between code, 3d models, Vector and Pixel based art.  Our tile sets for the game were built flat, sitting at the origin.  These were then loaded into the level editor for the game and oriented / deformed to the shape of a sphere before being saved out in a game-specific format.  Textures were created that tiled nicely on both hexagons and pentagons (necessary in this case to smoothly tile a sphere).

Some coders and artists struggle to work in a cross discipline environment, and to those people I say learn to communicate, learn to understand the processes used by the ‘other side’.  You will benefit and your team will benefit.

Choice of tools

We went straight to OpenGL for our graphics layer, rather than working with an engine such as Cocos 2d.  Although it meant writing a lot of boilerplate code it also gave us the flexibility to do odd and unusual things with meshes and textures.  This sort of freedom made it easy to iterate and refine the look of the game.  Building the user interface for the game in UIKit was a good choice too.  It became very easy to drop in new interface elements with minimal fuss.  Adding new views was also a simple process.  Limiting ourselves to OpenGL ES v1.1 (and ignoring the shader based v2.0) also kept the task manageable.

Later in the project we started using Particle Designer and Texture Packer.  I only wish we’d adopted them at the outset.  Particle Designer not only supports game engines such as Cocos2d, but also provides sample OpenGL code.  This made dropping Particle Designer effect files into the game trivial.

I’ve talked about Hudson at length before.  It is so easy to set up and tinker with.  Creating AdHoc builds was simple and automatic.  We used Dropbox to distribute new builds and the system worked very reliably.  Next time I’ll look at ‘over the air’ distribution options to make getting test builds out even simpler.

Partnership with National Geographic

There’s not much to say hear except the National Geographic were a great team to work with.  They gave us the freedom to experiment and trusted us to make good choices.  We had to make a number of difficult decisions to make along the way – altering time frames, removing Flash support and so on.  All up we had a very supportive and positive environment to work in.  Communication was via email or weekly phone conferences and it worked very well.  Using Dropbox allowed us to easily share and update concepts, documentation and AdHoc builds.

Custom Level Editor

Puzzle Planets made use of a custom-made level editor.  It was an iOS app that only ever ran on the simulator due to memory constraints.  It’s some of the ugliest code I’ve ever written.  But it works, and it made the process of designing and balancing levels simple.  It also meant that our creative director could design levels with minimal technical help, so iterating through level designs became a rapid process.

Even as mesh formats or tile models changed, the basic level editor remained able to take a level definition file and generate game-ready models.  At worst, we had to re-load and re-save each level if some aspect of the file formats changed.  This could normally be accomplished for all levels in a few minutes.

Early prototyping

Our initial designs were over the top and incredibly ambitious.  We put a lot of time and effort into prototyping game ideas, UI designs and concept art.  Typically we’d turn over or iterate several times a day on new prototypes.  With each prototype a number of team members would look at the new idea and provide feedback.  This was essential, as we had no ‘standard’ reference to follow with the design of Puzzle Planet’s mechanics.  Puzzle Planets combines a number of familiar mechanics, but the exact combination and blend on a spherical surface took a lot of careful thought.

Anyone who puts a game design on paper and says it’s good is either a genius or misguided.  Make prototypes, play them and iterate repeatedly – it’s the only way to get to the core of a good game.

What went wrong

Slow start

The Clash show covers a period of 250 million years.  An iPhone game normally comprises periods of game play that last for just seconds.  Our brief was very loose, with plenty of room for “Wouldn’t it be cool if…” scenarios.  We lost the best part of a month thinking all sorts of ideas for games – adventure-based mystery epics with the player trying to unravel the planet’s past.  There was much talk of animating continental movement over time, movie sequences and more.

It was a great time, with lots of wonderful ideas.  But in hindsight we spent a great deal of time on the big ideas without first focussing on the ‘second to second’ game play that’s critical to a good game.  It wasn’t until we focussed on the size of the team, the time frame and the unique aspects of the device in question that we started to narrow in on fun gameplay.  We eventually ended up with a tight gaming experience, but it took a lot of false starts to get there.

Those “Gosh darned” provisioning profiles

Apple’s set up for code signing is a major pain at the best of times.  Adding new devices for testing was always a time of trepidation.  Working through iTunes Connect is reasonably straight forward, it’s what happens when the new profile hits XCode that gets painful.  The problem is that placing the new profile in the correct place wasn’t enough.  Neither was loading the project and pointing it at the new profile.

Eventually we settled on the following reliable method (after a lot of gnashing of teeth!):

• Download new profile, put it in the appropriate directory.
• Quit XCode
• Open the project file in a text editor
  • Search for any reference to provisioning profiles and delete that line
  • Save project file
• Re-open project in XCode and re-assign required profiles.

It’s a simple enough fix, but far too manual.  I thought I’d left my days of hand editing project files behind with Visual Studio 2005.  Hopefully XCode 4 will be better at this.

Reaching too far

With such a short time frame, there would have been a good argument for taking a well known game play mechanic and adding a twist to it.  Or sticking to 2d.  Or use an existing engine such as Cocos 2d or Corona.  Or concentrating on a single device (rather than Flash, iPhone and iPad).  It would have been a very good argument, but for better or worse, we were determined to craft something unique and beautiful.  I think that ultimately we succeeded – Puzzle Planets is fun to play, and the race against the clock or your friends adds a wonderful frenetic pace to the game.

It also forced us to delay shipping the game by three months.  Trying too many new things is not a bad idea as such, but you need to accept that new things take time.  If we had reduced the scope of the game in some manner we could have hit our Christmas target.  Although after EA’s lock out of the charts over that period, perhaps it was as a good thing that we shipped late.

Gimbal lock

One problematic area of the UI throughout the project was how to handle moving the ‘camera’ around the poles.  There are two main options.  The first is to represent movement in two dimensions – side to side and up/down.  This means a swipe sideways always spins the planet around, and a swipe up / down tilts the planet.  This is nice and logical for most people.  The problem is that it gets weird at the poles and the only real option is to clamp the up/down movement so that you can’t ever go ‘over the top’.  This limitation can get very annoying at times, particularly in Stage 3 when the player is trying to get to a disaster on the other side of the planet, and the fastest route would be to go via the poles.

The other option is to use quaternions, an alternate representation which doesn’t have this issue and allows a free range of movement.  Sounds perfect, right?  The problem here is that spinning around the world in arbitrary directions means that you lose any sense of ‘up’.  It’s very possible to return to a point you’ve visited previously and discover that what was up is now facing down.  This can make it harder for the player to recognize features on the planet, but it’s even worse in Stage 1.  In Stage 1 a piece of the planet hovers in front of you and you must spin the planet to find the right place to drop the piece.  Using quaternions there was no easy way to ensure the piece was in the right orientation to drop in, even if it was in the right place.

Neither option suited us very well, but ultimately we went with the first system.  It works well 98% of the time, but it still annoys me.

Trying to support Flash

Our initial brief was to provide a game on both Flash and iOS platforms.  We spent a lot of time trying to find a 3d platform that works well in Flash.  Generating scalable game objects that could look good when rendered in either hardware (iOS) or software (Flash) was a challenge.  Ultimately there’s a reason why there are no good 3d Flash games.  Six months later and we finally have WebGL entering circulation.  I’ve been waiting for a good 3d solution for the Web since 1999 – I think it’s finally here.

In the end we dropped Flash support and the game is substantially better as a result.

Summing up

Puzzle Planets is a great little game, far removed from the original concept we had.  I had a great time working on it and the feeling of putting a polished, successful game (in the Top 100 Games overall in the UK, Australia and Canada and Top 200 in the US) on the App Store is wonderful.  Not everything went to plan, but then it never does.  Above all, this project has reminded me, yet again, that change is constant.  You can’t ignore it, rather you must embrace it and develop techniques that allow you to handle and respond to change.

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?

Obtaining a Fix

The Pragmatic guys frequently run special promotions, and it’s quite common to get up to 50% off many titles.  In particular if you sign up and then recommend a friend to sign up, you’ll both immediately get 40% off coupons to redeem on any purchase.  If you don’t have any friends who are sufficiently book-nerdy like you and me, drop me a line at george.sealy ‘at’ gmail.com and I’ll send you an invite so we can both enjoy a discount

Some Great Books

The Art of Game Design : A Book of Lenses

Beginning iPhone 3 Development: Exploring the iPhone SDK

User Interface Design for Programmers

Game Engine Architecture

The Pragmatic Programmer: From Journeyman to Master

My Name is George

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…

Symbol6 is a stylish puzzle game from Gogogic in Iceland. The game combines elements of Tetris and Missile Command in a novel package.

The game revolves around a large hexagon that fills about half of the screen. Within this hexagon are six (later seven) smaller hexagons, each with a unique symbol on it. As the game starts, you have to rearrange these symbols to match symbols that fly in from the edges of the screen. Match them up and you get points (and you can build up combos as you go). Miss a symbol, and you lose some life.

The game rapidly becomes more frantic, throwing more symbols at you, as well as adding a seventh symbol for you to juggle. In addition, you also get incoming ‘bombs’ which can cause all sorts of trouble, such as randomly rearranging your symbols. To fend these off, you need to rotate the iPhone to put up a shield. Managing this while fending off waves of incoming symbols becomes a significant challenge.

One thing that stands out is that Symbol6 is a beautiful game. The presentation and polish is top notch. Gameplay is simple to grasp but very difficult to master. A lot of thought has gone into the game’s design and it shows.

The game is quick to get into, and suits short play sessions. Having to rotate the device to deflect incoming bombs helps to break up the gameplay and provide variation. I found that the difficulty ramps up very quickly. The game starts off slow, then there’s a patch where you feel nicely in control of your destiny before you finally end up fighting desperately to keep yourself alive. It would be nice to see that middle part of the game last a little bit longer, as it is during this time that the game is most fun.

One issue I had is that while playing the game, it’s hard to know how well you’re doing. The transition from one level to another goes by largely unnoticed – I feel that giving the player a chance to take a breath, check their score and relax before throwing them back into the game would aid the pacing of the game greatly.

So, is Symbol6 worth the paltry sum you’d pay for it on the App Store? Absolutely. It’s an elegantly designed game that feels at home on the iPhone platform.