Resource Guide

Being on the cutting edge of cell phone game development is exciting, but it can also be frustrating when the hardware does not match initial expectations. Normally, game developers have a fair idea of what type of code their target hardware can handle. However, when you are trying to stay at the forefront of an industry that introduces new handsets every few months, you do not have this luxury. In fact, our game development team, Centerscore, is often asked to start developing games for handsets that do not even exist yet. In these cases, the games are feature complete before prototype handsets are even available for testing. Then, all too often, we find out that the handset is worse than expected and we spend days re-engineering and wrangling the game onto a phone. But sometimes, the unexpected happens and the game just works.

This feature focuses on two handsets that pleasantly surprised us by running our J2ME (mobile Java) games the first time around. We still needed to specialize our games for these handsets – Java, especially for cell phones, is never write once, run everywhere. These two phones span the extremes of the Java cell phone market. One represents the small screen, standard phone market, while the other competes in the large screen, smart phone market. Yet it is precisely because these two phones are so different in appearance that developing for both these phones is a great way to learn what cell phone development is all about.

The Ugly Duckling and the Swan

The 6310i is the ugly duckling of cell phones. It has a black and white screen that at 96x65 pixels is barely big enough for action based games. This phone has the standard layout for phone keys with no additional directional pad. From initial appearances, it seems odd that games, outside of snake, can even run on this phone.

In contrast, the Nokia 3650 is a big, beautiful swan of a phone. It has crisp, colorful graphics on a wide 176x208 pixel screen. It also has a big, easy to use directional pad that is great for games. The key pad itself is unusual, not following a traditional phone key layout. This means the number keys can’t be used for traditional directional movement. Instead the directional pad must be used as the primary controller. When we demo games to clients, we demo on this phone.

Yet, despite their very different outward appearances, both phones seem to have similar J2ME virtual machines that support games remarkably well. Besides running J2ME quickly, both phones also have ample amounts of heap memory. Speed and memory are the two technical factors our team considers the most in designing a game for a cell phone. Since both the 6310i and the 3650 have a good amount of both, they allow developers to focus more on game design and less on optimizing code.

Even Ms. Pac Man had More Room

A large part of cell phone game design centers around the screen size of a phone. The other day, our team played with Ms. Pac Man while waiting for dinner and realized that game had more pixels to work with than we do! Plus it had color. With a nice LCD, the Nokia 3650 can beat Ms. Pac Man where color depth is concerned, but the 6310i pales in comparison with its black and white pixels. Also, the 3650 has one of the largest screens out there, while the 6310i has one of the smallest screens.

In designing games for the 96x65 pixel screen size of the 6310i, every pixel counts. This is especially true when creating sprite objects, like the cars in Victory Lap. Internally, our team would argue over the size of the cars. Our artist pushed for larger cars so he could have more pixels to flesh the cars out with. Other designers pushed for smaller cars, so that there would be more screen space for viewing the upcoming parts of the track. Eventually we settled on a peaceful middle ground. One thing we did agree on from the start was that scrolling was necessary. By giving players scrolling, they are able to immerse themselves in a much larger game world. This is why all our 6310i games to date are scrolling games.

In contrast, when designing games for the Nokia 3650, we have been fine with creating both a mix of scrolling and fixed screen games. Color allows us to use every pixel much more effectively for small sprites. Plus, the large size of the screen allows us to create rich, deep backgrounds, that PC, console, and even handheld game players are much more used to. A fixed screen color puzzle game, Logjam, we created for Tira Studios has a full waterfall background built into the game. We were surprised when we saw how well the game turned out on the bright pixels of the 3650.

Obviously we prefer working with the large color screen of the 3650, as opposed to the smaller, “uglier” screen of the 6310i. After all, even with good design, the type of screen does limit the type of game that can be created for the 6310i. But partner the right type of game with solid design and you can still create a great game

Constant Design

When we first started developing games, we would create detailed design documents for each game. However, as we worked with both the 6310i and the 3650 we learned that the design process spans the whole cycle of the game -- from idea conception all the way into QA. With the 6310i we had to redesign parts of the game due to constraints of the phone, while with the 3650 we had to redesign the game due to higher expectations of the phone.

Our first experience with the 6310i was in transforming a concept demo into a full top down racer called Victory Lap. When we first put our demo onto the phone, we thought we’d encounter major performance problems. But instead of the game slowing down, the game actually sped up!

Based on this success, we felt comfortable designing out the entire game. We decided to add features, like permanent skid marks into the game. We also designed new tracks for the game. The first would be a simple oval, while the next two would be far more complex. Things were going well.

Once the game was feature complete, we started to code the new tracks into the game. Then the game crashed. As we debugged the problem, we realized the problem had to do with the size of the new tracks. In order to allow the skids to stay permanently on the track, we drew the track onto one large offscreen image and then drew the skids directly onto this image. The offscreen image created for a 400x300 pixel oval track was fine, but our more complex tracks created offscreen images that were too large for the phone’s heap memory. Our design exceeded what the phone could handle.

Since we did not want to give up the detailed skid marks, we opted to keep our big offscreen image and design new tracks that would fit these new size constraints. Even for a good phone, we had to modify the design of our game when it was already feature complete. (It turns out later that on other phones which typically have even less heap memory, we had to pull skidding out completely.) Luckily, our publisher, Versaly Games, was very easy to work with and open to all the last minute changes we have had to make to our games.

A similar design change occurred when we decided to move an action based soccer game onto the Nokia 3650. In this case, the phone actually provided more than we expected! We had developed a soccer game that was designed to use standard soft button features that Java provides. However, when we put our game on this phone with its huge screen, we realized that our game is not as competitive if it does not take advantage of the phone’s full screen – a feature that Nokia phones supports. In fact, we have discovered that in certain cases, games on the 3650 will not be certified unless they use the full screen.

Adding full canvas to a game after it is already written requires significant rewriting of the code. The playable area goes from 176x144 pixels to a full 176x208 pixels. A wider screen impacts both graphics changes as well as gameplay changes. However, since we did not have the handset from the beginning we did not realize the significance of the change. Now we design games with full screen from the start. Like all new, emerging fields, cell phone gaming requires constant design and constant learning from your mistakes.

_______________________________________________________

30, 720

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2002 CMP Media LLC

privacy policy | terms of service