Develop

When Nokia asked us to develop a suite of casual connected games for use on Java-enabled mobile phones, we were of course elated about an opportunity to show the company what we could do.

We had already built several games that ran on Nokia phones, including a game suite that was preloaded onto one of the company’s new handsets last year. But this was the first time that we would be working with Nokia’s SNAP Mobile group.
The assignment was to develop a set of connected mobile games – to be named Pocket Party – that would push the limits of J2ME technology to show what was possible using the SNAP Mobile platform.

One thing that we knew going into this project was that the aggressive development schedule would be a real challenge: ten games in ten months. So we literally started work the next day.

Ramping up
Octopi was a small company, with just five developers, so the first order of business was to staff up. Some people thought that finding experienced developers quickly in the middle of the Arizona desert would be a problem. But we already had about a dozen people waiting in the wings. We’re located near the University of Arizona, in Tucson, and have some very good contacts among the faculty and students. Over the course of the program we built up a team of about 15 programmers. Everyone we hired is still with us today, I’m happy to say.

While we were building a team, we also began working on our own internal schedule for producing this project. In the beginning, our intent was to develop all ten games simultaneously. But this turned out to be unrealistic. For one thing, the SNAP Mobile API was still in beta, so there were some technical hurdles that needed to be overcome that kept us from really going full speed.

What we ended up doing was staggering the development phases so that we were working on just four games at a time. In the end, this strategy saved us time and money. You really want your first game, or first set of games, to pay for your learning curve. By limiting your mistakes to the front end of the project, you can apply what you have learned to the rest of it without paying a high price.

Something else that we did at the beginning of the project that sped things up later was identifying all the common code areas among the different games. As much as possible, we wanted consistency and common functionality across all the applications because they were going to be marketed together. Around 80 to 90 per cent of the functionality that the SNAP Mobile platform offers – including logging in and out, dealing with account information, challenging buddies, game lists, chatting – is represented within this common area of the code.

A very nice thing about the way that SNAP Mobile works is that you don’t have to use the entire feature set. You can pick and choose just what you need and forget about the rest. We used this same strategy to create a separate module that could be dropped into each game. It contained most of the functions we would be using in the suite. We could turn features on or off, depending on what the individual game requirements were. As the SNAP Mobile API evolved and changed, we were able to focus on changing that one module and it automatically updated all the games.

It took us about three months to finish the initial set of games. Along the way, we made mistakes that necessitated throwing out code that we had spent weeks writing. But we also learned some valuable lessons and we completed the final three sets in about the same length of time it took to do the first one. By the time we got to the fourth set of games, we had cut the development time down to just over two weeks.

Creative coding
One challenge that we had to deal with every day of the project was creating as small a footprint as possible. Writing game code for a mobile phone is like trying to squeeze a size 13 foot into a size nine shoe. Things get very tight. Naturally, SNAP Mobile wanted to have as many features as possible in these games. But they also wanted them to run on as many handsets as possible. So the rule was that we had to keep everything within 128K, which meant we had to engineer the code to be as small as possible. In 90 per cent of the computing world, saving bytes is insignificant. But in mobile gaming, it can mean the difference between success and failure.

Traditional Java programming, where you use a more object-oriented approach to model the various aspects of your game as separate classes, won’t work here. Sometimes you just have to fit everything into the same class file, which can be very difficult to do when you want to keep your source code as clean and organized as possible.

So we got very creative with the utilization of space in these games. We built each application in such a way as to make the most of each existing graphic. When a background was symmetrical, for instance, one clever little trick we used was to store just half of it and then flip it to draw the other half of the screen.

No one shortcut or technique will get you where you want to go. It’s a combination of little tricks and techniques that work together to shrink the code down. For example, we came up with a small tool to run all our graphics through several different optimization routines, resulting in the smallest possible rendition. It helped us save anywhere from 100 bytes to 2KB or 3KB.

That was a gift to us because it meant that we could uncomment a section of code that we had disabled, or add a new graphic or enhance an existing one, to the application. You never want to utilize too little space on a mobile phone, or too much of it; the sweet spot is right at that 128K limit.

There were a lot of features that we wanted to add to these games. Things like chat history, an enhanced chat experience and more sophisticated avatars. We ended up with a relatively simple and straightforward chat function and standard avatars with a few facial expressions and a simple logic that decides the appropriate expression. But as the code footprint of mobile phones increases, functions like this will continue to improve. Right now they had to be sacrificed for more important functions.

Casual questions
Overall, I think there has been a lot of give and take on this project. Right at the beginning, SNAP Mobile told us that Octopi would be acting as their guinea pig. We would be the first ones to implement and test many of the features they were adding into the API. And in fact we were the first developers to use the token system, and the first to work with their upload/download system, and their SortStart matchmaking service.

Sometimes we were flying by the seat of our pants. Situations occur when you are playing a connected mobile game that you simply don’t run into with a single-player stand-alone game.

How do you deal with connection drops when you go through a tunnel? Do you pause or end the game? From a game-player’s perspective, does this count as a loss or a tie? From a developer’s point of view, how to you recover from this event?
We couldn’t just Google for answers to these questions because there aren’t a lot of people out there making multiplayer games for phones.

So we worked very closely with the team at SNAP Mobile, who spent a lot of time with their handsets wrapped in tinfoil trying to duplicate connection problems. They offered us a lot of encouragement and support. This cross-pollination of ideas is a very good thing when you are breaking new ground. Between the hard work of the Octopi team and the SNAP Mobile team, we usually ended up coming up with a pretty good solution.

www.octopi.com
snapmobile.nokia.com