Setting up…

I won’t go into all the details of setting up a Testflight account, it’s fairly well covered on the site.  What you will need to do is set up one or more ‘teams’ for beta testing.  Once you’ve done this, it’s time to investigate Testflight’s upload API.

Automated uploading

Most pages on the Testflight site have a set of links at the bottom, one of which is ‘Upload API’.  This page gives details of how you can upload a build programmatically.  You’ll need to find a few details – an api token and a team token.  Both of these can be found by following links off the Upload API page.  Once you’ve got these, we can use curl to handle the communication with Testflight .com:

curl http://testflightapp.com/api/builds.json 
  -F file=@yourapp.ipa 
  -F api_token='your_api_token' 
  -F team_token='your_team_token' 
  -F notes='This build was uploaded via the upload API' 
  -F notify=True 
  -F distribution_lists='Your Team Name'

And that’s all there is to it!  I’d recommend trying this from the command line until you’re happy that builds are uploading correctly, then simply drop this command line into your build system as a final build step.

I’ve been using this for a while and it works well.  The first time you create a build, your testers receive an email – if they read the email on their device, they’ll get instructions for setting up Testflight on their iDevice.  Having done this once it becomes a one click process for testers to get new builds.  Not only that, but you as the team leader will know who has downloaded the build, and on what device!

Just a few of issues…

Overall I’m really happy with Testflight as a system.  There are some things to be aware of though:

• Testflight only works on newer devices / OS versions (4.0 and later, I believe).
• I’m not clever enough to interpret the results of curl to determine if an upload fails, so currently I get a ‘build succeeded’ even if the upload fails.  If anyone can offer some advice on how to do this, I’d appreciate it.

I hope you find this useful – I know I do – one click to go from Source Control to having a new build in tester’s hands?  Magic.

If I had the chance, what would I tell my younger self?  What has worked out well for me and what would I do differently?  Here’s a few of the things I came up with.  What would you add?

Failure is not the thing to be afraid of

Some of the world’s most successful people have had massive, public failures – but it hasn’t stopped them.  Yes failure is painful and embarrassing.  But it’s also a great teacher, making us wiser and stronger.  Perhaps more importantly though, if we never fail, then we’re not taking any risks.  Tackling challenges that may be too much for you are where we get a chance to excel and surprise ourself and others.

Always have a backup plan

I have spent many years working in live television, covering sports events.  It was not uncommon to be adding new features to the software on site the night before the event.  I’ve arrived in foreign countries with broken computers.  I’ve turned up at events and lost a day because no one knew we were coming and so we had no space to work, no power to work with.  I’ve had machines die at 2am the day before we’re live.  This teaches you a few of things:

1. Some deadlines simply can not move, so you must be adaptable.
2. Always have a backup option.  You may not get as much done as you hoped.
3. Worry early so that you don’t have to panic late.

Plan your work to try and deliver in an iterative fashion.  Planning to deliver everything at once, on deadline is just plain stupid.  Working without source control is just plain stupid.

There is no better time than now

It’s taken me far too many years to realise that my dream is to work for myself, on the projects I want to work on.  I’ve learnt a lot working for other people and I enjoy being part of a team.  But after a while the urge to show the world what you can do, to craft something that’s all yours becomes very strong.

My point is this.  It’s hard to do that once you have a mortgage and a family (and a dog, cat, rabbit, guinea pigs, chickens and goldfish).  When you’re young you have a great opportunity to move quickly and try things out.  Also, we live in an age where it’s never been easier to get your product in front of customers – make the most of it.

You will be wrong, often

There’s no shame in being wrong.  It happens.  Accept that it happens and move on.  Keep your ego in check and always keep in mind that the people you work with probably aren’t stupid either.   Often arguments are caused because two people are so caught up in their own opinion that they forget they’re on the same team, trying to achieve the same goal.

Mistakes will happen and you don’t always make the best choices.  Learn to prototype ideas quickly.  Learn to leave a buffer in a project plan to handle the unexpected.  Tackle the biggest challenges first to avoid surprises.

Always learn more

Learn new languages, frameworks and techniques.  Read iDevBlogADay and altDevBlogADay!  Challenge yourself not to stagnate.  If you find yourself criticising another platform, maybe it’s time to dive in and learn more about it.  One thing I can promise you is that the work environment and tools you use today won’t be the ones you use in 10 or 20 years.  Don’t end up a dinosaur.

There are difficult or petty people in this world – deal with it

Working with others is hard.  It’s at least as hard as the technical challenges you deal with, so put some effort into being good at it.  Working so-operatively is a skill you can develop.  Some people are harder to work with than others.  You might be That Guy.  Learn how to communicate clearly and without letting your emotions get in the way.  Work on solutions, not problems.  Be polite and always treat people with respect – especially the difficult ones.  You never know whio you’ll be working with or depending on in a couple of years.  Life is funny that way.

There’s no silver bullet here, it’s hard work but the effort will pay off, I promise you.

You are so much more than a coder

This is the big one.  Don’t believe that you’re just the tech guy.  Get out of your ivory tower and learn about what your colleagues do.  Know enough about Photoshop to take images from artists and get them into a usable form.  Understand how artists build models so that you can teach them (in their own terms) what can and can’t be done inside a game engine.  Talk to designers about flow and layout, and why moving that text two pixels to the left is so important.

Understand enough about business to know the effort that goes into giving you a pay cheque each fortnight.  Practice estimating tasks and tracking time spent to better understand what you can or can’t achieve in a given time frame.  Write documentation or reports to share knowledge with clients or customers.  Write a blog!  Speak in public.

Not only will this make you a better person, but others will enjoy working with you and helping you out when needed.  And when you make that transition to management, or all-in-one Indie developer, you’ll be much better prepared.

And one more thing…

Enjoy yourself.  Work hard and treat difficult problems as a fun challenge to crack.  Only boring people get bored.

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.

Bad Habits

It’s true.  I have been known to write bad Open GL code.  By bad I mean simple, immediate mode code.  I learnt GL programming on SGI machines that cost a fortune and weighed more than me.  In this world, writing rendering code was fairly simple – call glBegin(), pass a bunch of vertices one at a time and call glEnd() when you’re done.  Need things to run a bit faster?  Wrap it in a call list.  It was easy and fast enough for most situations.

What this style of programming tends to lead to is having drawing calls and GL state changes littered throughout the code base.  It is simple, but it can also be confusing, particularly when it comes to changing GL’s state – blending modes, enabled vertex arrays and so on.  GL has a lot of different state variables, and if you forget to return one to its expected value life can get interesting in unexpected ways.

With the move to Open GL ES v2.0 (GL v2 from here on), it seemed like a good time to kick a few bad habits.  Along the way, the plan was to create a more flexible, efficient and reliable rendering system.

Something to aim for…

After some thought, I came up with a some goals that described what I wanted to achieve:

• I’m sick of managing GL’s state ‘by hand’.  I want to be able to say ‘this effect needs these states set’ and rely on the underlying system to handle this efficiently and automatically.
• Drawing calls should be combined into batches automatically.  Especially in a 2d sprite based renderer, made up of lots of small elements, this is extremely important and can have a huge impact on rendering speeds.
• Draw calls should be sorted to render correctly (back to front in general) and also to minimise state changes.
• Component-based techniques should be used to lay out data for best memory usage (minimising cache misses).
• Shaders should be highly configurable (and also the meshes that they render).
• High level game objects should have full control over specific details  - do they use physics or not, do they consist of one sprite or many, what shader do they use and so on.

10,000 foot view

After a few days holiday last week, things are starting to come together.   GL v2 is a streamlined beast.  There is no fixed function pipeline at all – no matrix stack, no lights – we have to provide it all in the form of shaders.  This freedom is wonderful and extremely powerful.  It also requires a lot of bits to fit in place before you get that first triangle on screen.  I’ll try to give a general overview of how things fit together.  The system is built on three main ideas – effect files, aggregating components and delayed render calls.

Effect Files

The idea behind an effect file is simple.  It should contain all the information we need to render a mesh.  In GL 2 terms, we need a vertex and fragment shader at a minimum.  I’ve also added state information such as textures used, blending mode, cull mode and so on.  These are all stored in a single file and retrieved / parsed using Philip Rideout’s glsw code.

Components

There’s a lot of great, detailed articles out there about component based engines.  This isn’t one of them.  But the basic idea is this.  Let’s say our Elephant game object needs to move with gravity (he’s sky diving) and respond to collisions (he may forget to open his parachute) He’ll also be rendered with four sprites (body, head, tail and hat) and a particle system (he farts a lot).

We could store his position, velocity, sprite data and so on all in one structure, but this can lead to inefficient memory use.  Instead, we build a game object out of components of different types (physics, sprites etc).  The elephant game object contains references to a physics component, sprite components and a particle system component.  All our physics components are stored in a single contiguous chunk of memory, sprites are stored in a similar large array as are the particle systems.

Why is this a good idea?  Just ask Mike Acton.

Delayed Render Calls

Rendering efficiently on modern graphics hardware requires that we reduce the number of state changes and drawing calls to a minimum.  One way to do this is to batch up similar individual elements into a single mesh.  To do this, each graphical element has a ‘key’ value that gets added into a big list, which is then sorted using qsort().  The key is created based on the element’s depth in the scene, the effect used to render it and so on.  Christer Ericson describes this idea brilliantly.

What does this do?  It allows us to iterate over all our rendered elements once, adding them to the list.  After sorting, the elements are not only ordered for correct rendering, they are also clumped into groups of similar elements, allowing us to avoid unnecessary state changes.

The Main Loop

Glenn Fiedler has a great article on setting up your main game loop to best handle physics calculations.  The guts of his discussion is that you should always ‘step’ forward your physics calculations using a fixed time step, even if this doesn’t match the amount of time that’s passing in between frames.  This means that for a given frame, we may step forward our physics simulation once, twice or more.

Let’s take an example.  Suppose that since the last frame 25 ms has passed.  If our physics time step is 10 ms, we advance the physics simulation twice (20 ms) but what do we do with the extra 5 ms?  If we stop at two physics steps, or go for three, we’ll get stilted, jerky animation.  Glenn’s answer is to take the third step, but then interpolate between the second and third step.  Glenn explains it much better than I can at 10 minutes to midnight so go read his article.

Here’s an example of what my main game loop ends up looking like:

void GameUtils::Update(Game &game, float deltaTime)
{
    if (game.state.isInProgress && !game.state.isPaused)
    {
        if (deltaTime > 0.25)
        {
            deltaTime = 0.25;	  // Keep deltaTime from spiking
        }

        game.loop.accumulator += deltaTime;

        // Update physics
        while (game.loop.accumulator > game.loop.dt)
        {
            game.state.gameTime += game.loop.dt;
            PhysicsUtils::Step(game.physics, game.loop.dt);
            game.loop.t += game.loop.dt;
            game.loop.accumulator -= game.loop.dt;
        }

        // Interpolate physics state...
        PhysicsUtils::Interpolate(game.physics, GameLoopUtils::GetAlpha(game.loop));

        // Update all game objects here, including updating sprite positions based on
        // physics data.

        DrawOrderList drawList;

        // Add all sprites to draw list
        const Sprite *spritesArray = game.sprites.list.Data();
        for (int i = 0; i < game.sprites.list.count; ++i)
        {
            const Sprite &s = spritesArray[i];
            unsigned int key = DrawOrderUtils::CreateKey(s.layerId, game.sprites.componentId, s.effectId);

            DrawOrderUtils::Add(drawList, DrawOrderElement(key, &s));
        }

        // Likewise add particle systems and text...

        // Finally, sort and render in batches...
        DrawOrderUtils::Sort(drawList);
        RenderComponentUtils::Render(drawList);
    }
}

But wait, there’s more!

Actually there isn’t, at least not this time.  There’s a lot of detail I’ve missed, far too much to pack into a single post.  Hopefully I’ve given an overview of how the system works.  Next time I’ll concentrate on one part of the system and describe it in more detail.  If there’s one aspect in particular you want to know more about, or that needs better explanation, please let me know in the comments below!

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.

It’s simple.  All proceeds for the next week from the following apps (iOS and Mac) will go directly to the Red Cross relief effort.  For more details, go to http://www.appappeal.co.nz/.  There are some great apps here, and you’ll be directly helping the thousands of people affected by this disaster.

Apps involved in the appeal include:

Chopper 2 – Majic Jungle Software – Universal App + Mac OS

Top Dog: Farmyard Adventures - Flightless – iOS

Scarlet and the Spark of Life: Scarlett Adventures Episode 1 - Launching Pad Games  – iOS

Sheepish –Pixelthis –  iOS

MiniMonos Flight –Minimonos – iOS

Acorn Money –Acorn Heroes – iOS

Bird Strike –PikPok – iOS

Ancient Frog HD –Ancient Workshop  - iPad

Twenty Chinups –SoftwareX – iOS

Sleepmaker Waves, Sleepmaker Rain, Sleepmaker Storms, Sleepmaker Streams, Sleepmaker All in One and Sleepmaker Wildlife -SoftwareX – iOS

Dejal Simon, Dejal Time Out, Dejal Caboodle, Dejal BlogAssist – Dejal – Mac OS

Please help us spread the word by telling people about http://www.appappeal.co.nz/.

I’d also like to offer a vote of thanks to Jos from PikPok games and all the others who have been involved in putting this together so quickly.  And to everyone affected in Christchurch, we’d like to say Kia Kaha, we are all with you in this horrible time.

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.

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…

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

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!