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.

Related posts:

1. In Review : Symbol6 by Gogogic