A few weeks ago, I wrote admiringly about the groundbreaking, orientation-independent interface of my favorite iPhone game, Dizzy Bee.
I shared my admiration with the folks at Igloo Games, and got a response from Nathan, the designer and developer behind Dizzy Bee, the company’s first product. He agreed to answer a few questions for me, sharing some of the process behind this innovative game and UI.
Scott: How many others did you work with to create the final product?
Nathan: Three total. I did all of the programming and design. Art was handled by my good friend, and the sounds were contracted out.
How did the concept for the game originate? Can you describe your process for evolving the concept and new ideas?
The game started as a twist on a labyrinth game. I felt there would be a lot of accelerometer-based flat games, so I decided to try a vertical version. (Many people seem to prefer to play it flat, though.) I’m a big fan of character-based action, so I like to put eyes on just about everything—rather than balls and holes, I wanted to have good guys and bad guys. I felt like controlling multiple good guys would be really compelling, so I started with that. It wasn’t clear what was going on, who the main character was, and what you were trying to do, so I decided we’d have a main character to draw your focus, and we would build toward controlling multiple friends—that’s were the cages were born. Then we put in the basic bad guy that moves almost the same as you, and we knew we had a game. After that, it was just playing with different physics aspects to make unique characters. The birds just have a maximum speed that they go, so they kind of fall slowly. The big guy is much larger and heavier than you, so he doesn’t fit in certain places. I tried tons of different enemies/objects out. The ones I could make a cool stage out of stayed, and the rest were tossed.
Once you had the idea for the game play UI (which uses only the accelerometer as input), how did you start thinking about the UI elements that appear between stages?
I often have to make temporary art while I’m prototyping things. I felt I could draw a blob and call it an island, so that’s where the island/sea concept came from. I had originally gone for a more novel approach for unlocking stages. I had wanted each island to have a theme and a port city. After you complete the port city (kind of an introduction to that island), you could play any level on that island. So after beating the first island you would have 3 new port cities, and if you beat those right away you would have 12 new levels to try. I still like the idea, but the difficulty ramping wasn’t working. People would find a stage that was way too difficult, and the unlocking of islands wasn’t really a reward at all, so I changed it to a more traditional progression.
As for the Results Screen, I wanted good replay value, so I decided on 3 things to grade people on. [The three scales that determine one’s score are: fruits saved, flowers collected, and percentage of fruits that exited the level in a chain—meaning, they were saved at the same time. See screenshot above.] I wanted those to be very prominent. Also, if the fruits lived or not and if they chained or not are very important, so I wanted that to be visually represented as well. The rest I just left up to my artist, and what you see is what he came up with.
How would you describe the Dizzy Bee UI?
It’s an up-less spinny UI. As I was making the game, I took care to make sure that nothing after the splash/loading screen had an “up”. The dialog boxes originally could be rotated 360 degrees as well, but unfortunately I couldn’t get the refresh going fast enough to make them smooth, so I had to settle for 90-degree increments.
Another thing I like to do with UIs is take one theme and apply it to everything. For example, I made a level editor in Mario vs Donkey Kong 2, and in that there were lots of things that would scale up and down with an elastic type effect, finally settling on the correct size. In Dizzy Bee, all of the UI elements are like a spinner on a nail with a weight at the bottom, so they like to keep some momentum and eventually settle in the right spot. Also, each weight is a little different, so each individual element moves slightly differently.
What terminology did you use internally to describe all these elements? I tend to use “UI” to refer to more traditional interface elements, like the text and tap-able buttons that appear outside of the stages.
I use UI very broadly to mean anything that’s not the in-game action. There are a few terms to specify which part more closely. I use front end to describe any title screens/credits/file selectors. Level select is the island/sea section screen. HUD is anything that is shown while playing the game, such as players’ lives or health. (Incidentally, Dizzy Bee has no HUD.) Pause menu for… well, you know. Lots of companies use these same terms in different ways, which has caused me some confusion in the past.
I’ve called it an “orientation-independent” UI. Were you or others on the Igloo team thinking in those terms, or did you use other language to describe what you were building?
I was just thinking in terms of Dizzy Bee is an “up-less” game, but I looked back at an old e-mail, and I also used the term “orientation independent”. There are a lot of things I do during development that I question if anyone will even notice. Thanks for recognizing it, and pointing it out.
