Ben Humphreys

Computational linguistics researcher at Kyoto University, focussing on machine translation. Also learning Japanese, Korean, French and other badassery.
(日本語版)

June 2, 2012 at 3:16am

It’s 3:15am. I’m up because I spent 3 hours playing the Kerbal Space Program. Just the demo. The video above features even more awesome stuff.

Space + Building + Explosions = Addictive

April 25, 2012 at 1:15pm

First Boco Fan Art

The 6-year-old son of James’ coworker apparently really loves Boco, and made this so we could make some more levels more easily. We never expected anything like this when we made the game.

I’ve got the biggest smile right now.

March 21, 2012 at 5:20pm

Making Boco

Boco logo big

Six months ago, my good friend James and I decided to make an iOS game. It’s finally finished, and so here are some of the prototypes and thought processes we went through in making the game.

It might make more sense if you play the game first, it’s available now on the App store. Thanks :)

Prototyping

The first prototype I made was in Javascript and HTML. I literally knocked it together in an afternoon, with the aim of creating a level editor. It didn’t fulfil this role in the end, instead we we found it was easier to plan out levels using pieces of paper. But the time wasn’t at all wasted, the code I wrote to deal with game logic was easy to port into Objective-C, and saved a lot of time when we implemented “for real”. The tricky little logical bugs were much easier to debug in real-time with JavaScript than they might have been with the XCode debugger.

  • Don’t forget pen and paper for prototyping.
  • That said, HTML/JS is amazing for quick prototypes.

▼ 1) HTML prototype.

HTML Prototype

▼ 2) D-pad, temporary graphics.

iPad

▼ 3) Prototype using original 8-bit graphics with D-pad using on-screen iPhone simulator.

iPhone prototype

No text

We decided early on in the design process to have no text in the game at all. It seemed a logical decision, to maximise laziness. No text, no localisation. So it would let anybody play the game.

However the difficulty in communicating ideas to the player without text was harder than we thought. Showing users that they have completed a level without a simple “Complete” required a little thought, and

There are two exceptions to the rule. You have to write a description of your application on the App Store, so you end up using English anyway. We also used English on the Credits and Game Complete screens.

  • No text means no localization, saving you time.
  • Communicating via images alone is harder than we first thought.

Gameplay Design

We put navigation buttons (forward, back, reset) at the top of the screen, where they are in most of the native apps. We initially had 20 levels, but weren’t sure how to subdivide them. We settled on splitting them into 5 stages, with 4 levels each. We wanted users to be able to try other levels if they got stuck on one, so unlocking each stage in a block, would let them try For the interface, we chose to present a simple drop-down box for completing a level, and let the user progress to the next available level within that stage (set of 4 levels). This let users stay ‘in the zone’.

Once all levels in a stage are complete, users are shown a modal window that covers the middle of the play area, and brings them back to the main menu. The main menu then shows the next set of 4 levels unlocking in an animation. We chose to bring users back to the level select menu and show them this to make their level progression clear, and give them a sense of completion upon finishing a set of 4 levels.

Control

Our first prototypes in Objective-C used a simple D-pad as the control scheme. It was the easiest to implement at first, and worked well with the mouse interface we were using. When we started developing on-device, we tested swiping and found it faster and more suited to the touchscreen than using a direction pad.

Graphical Theme

As a simple puzzle game, the game graphics were a completely blank canvas. I started with neon green and pink, with a simple “8-bit” theme, but it didn’t seem to have any sort of depth or feel to it.

James was creating the first sound effects for the game at around that time, and one he chose had a very natural, mystical sound that immediately brought to mind ancient temples and jungles.

I’m a big fan of writing systems, in particular the Aztec and Mayan script that I’d read about in Lost Languages. Using the Mayan symbols as a starting point for the decoration, I changed from a digital to a stone-like theme. James

The final part of the design phase was creating a logo.

  • Get inspiration by exposing yourself to as wide a variety of things as possible, not just other games.

▼ Level select design progression. Added more details, more depth, more colour.

Level select progression

▼ Icon design progression.

Icon design progression

Sound

(Written by James)

Making the music was the start of our Mayan theme. I wanted to go for something ambient and without rhythm, so I pulled up some indian flutes and strings and put together a first incarnation of the main music, which has stayed the same more or less throughout.

At the time we also had some basic high-frequency ‘blip’ movement sounds, but these didn’t go with the Mayan theme that was emerging. So I rustled up some short, bassy stone sounds. I wanted something like the block moving sounds in the original Tomb Raider games. The stone sounds gave the blocks ‘weight’ and made them much more enjoyable to push around.

The menu forwards/backwards sounds were relatively easy. I wanted to quite obviously link the two together, so I decided to make the backwards sound use exactly the same drums (and in the same combination) as the forwards sound, but in reverse order.

  • Sounds are powerful ways of enhancing the user experience, but can detract if used incorrectly
  • Relative volume levels for sound FX and music are crucial
  • The sound must convey the feeling of the action

Beta Testing

We went through two stages of testing. At first we kept the latest version installed on our phones and tried them out on our friends. Unlike remote betas, this let us actually watch our users try the app for the first time. Handing it to people with no explanation, and seeing them try to work out the interface was the most useful. People’s learning curves were very different, depending on their familiarity with touch devices, or their logical thinking skills (scientists fared better than arts majors). From this we made the buttons more obvious, added a mandatory tutorial stage, and made the level progression more obvious to the user.

Tutorial versions

Summary

Making a game is fun! Make your prototype as simple and as quickly as possible. Then get it working on-device for a great boost in morale :) Test it on all your friends, both technical and non-technical. Be inspired by everything around you. Play off ideas from other team-members and other parts of the game design, be it sound, graphics or gameplay.

If you found this interesting check out the game on the App Store!.

September 4, 2011 at 10:49am

I <3 Fez

August 23, 2011 at 4:56pm

From Machinarium, one of the most beautiful soundtracks I’ve heard.