Being on the cutting edge of cell phone game development is extremely fun. 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. 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. This feature focuses on two very different handsets that pleasantly surprised us by running our J2ME (mobile Java) games the first time around.
November 25, 2002
Author: by Oliver Maio
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 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.
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
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.
The Nokia 6310i and the Nokia 3650 also differ in the application sizes they allow. The 3650 can actually hold a 4 Mb game, although a game that large would take up the phone’s entire flash memory. On the other hand, the 6310i is limited to 30 kb. Let us be more specific since for games on this cell phone every single byte matters. The 6310i is limited to 30,720 bytes. This is 30,720 bytes for all the resources for the game, including code, graphics, and sounds.
Given the size restrictions on the 6310i, optimizing games for size on this phone is extremely important. Luckily, the 6310i is fast, so developers can focus on size optimizations and sacrifice speed optimizations. Centerscore optimizes our code by flattening out the class structure and writing tight code sometimes at the expense of readability. We also optimize our graphics by tweaking out unneeded pixels. But the best way to cut the size down as much as possible is to design the game from the start to reuse code and graphics where possible.
Even with our best planning, to stick as many features as we can into a 30,720 byte game, we often will fight for the very last byte. We’ll take out unused letters, like “z” and “x” from our custom font sets, we’ll rewrite the help to be as tight as possible, and we’ve even considered shortening soft button titles to squeeze the game down to size. In fact, these were all modifications we made to Victory Lap where the addition of last minute features, like a branded mMode logo, caused the game to go over 30 kb. Every add-on required fiercer and fiercer optimizations.
Fortunately, with the 3650, we’ve never had this problem. But even then, its still important to keep a game lean so users have the fastest download time possible. In our CS Soccer game, we utilize standard techniques, like image flipping and cutting the field into key pieces to minimize the size of the game.
So once you have a game that is small enough to fit on a phone, actually putting the game onto the phone comes into play. Downloading a game onto a phone may seem trivial, but when you’re making frequent changes to debug a game on a phone, having an easy download mechanism is very important.
A download mechanism that Nokia phones thankfully avoid is Over The Air (OTA) delivery. Certain members of our team will flinch at the mention of these three words Unfortunately, some phones require OTA as the only available mechanism for testing. OTA has many difficulties, like caching of web content, repeated typing of URLs on a phone keypad, and slow delivery speeds. These difficulties cause some OTA processes to take at least fifteen minutes per download. That is assuming that your phone even functions in your office area. Our office doesn’t have good T-mobile service, so in testing OTA, we’ve had developers standing outside in the middle of the street, downloading games to a phone. Multiply this against the dozens of builds sometimes required to work around phone specific problems and on cold nights you may have one frozen, sore thumbed developer. These Nokia phones do not force developers to endure this pain.
For the 6310i, we use the Nokia Developer’s Suite to very quickly and painlessly beam the game to a phone via infrared. To ease the process, we always use laptop IR ports which are orders of magnitudes more efficient than PC IR add-ons. A typical download of a maxed out 30k game will take less than 10 seconds. For the 3650, we use Bluetooth to drag and drop files over to the phone. With Bluetooth, a 64 kb game also downloads in under 10 seconds. Once set-up, both IR and Bluetooth work extremely well.
One would think that cell phone manufacturers would make information on their phones very easy to find, but this is rarely the case. We often spend more time tracking down basic phone information, like screen size and image transparency support, than we do making the decisions with the information we’ve gathered. Some manufacturers will only make certain APIs, like vibration, open to a limited amount of publishers. So whether you’re starting out or have a dozen wireless titles under your belt, developing for open APIs is the easiest way to go.
Besides being good phones to learn development on, there are also legitimate business reasons to target the 6310i and the 3650 first. The most obvious reason is one that you’ve probably seen on street corners every day – Nokia phones are everywhere.
Another helpful fact to consider is that Nokia guarantees that future phones will be based on similar specifications as the 6310i and the 3650. They’ve done this by splitting their current and future line of phones into sets known as series. So games that run on these phones will run on future Nokia phones without modifications.
The three series that are relevant to Java phone developers are the series 30, the series 40, and the series 60. The 6310i is a series 30 phone – all which will have 96x65 pixel sized screens. The 3650 is a series 60 phone built on top of the Symbian platform, but always capable of running J2ME games.
Our team does caution other developers to wait for the series 40 phones to mature a little more. You can run simple games well on current series 40 phones, but if your game uses more than modest amounts of memory it will need to be redesigned with better memory management. Its best to do this after you’ve already had the satisfaction of running the game on other phones.
Also an impressive line up of manufacturers, like Siemens, Panasonic, and Samsung, are licensing the series 60 technology. This means that the Series 60 will very likely become the future de facto standard for intelligent phones. For cell phone developers, this means we will finally have a common set of APIs to develop for without having to hop scotch through a land of mixed APIs. This is very cool.
We hope our comparison of the Nokia 6310i and the 3650 gave a good understanding of different issues cell phone developers face. There is no doubt the 3650 is a better phone, but even though it may be an uglier phone, the 6310i is still a worthy gaming phone.
Phones will be even better when manufacturers, like Nokia, open up J2ME access to infrared and Bluetooth on the phones. Massive multi-player games over the network will be popular, but we think in person, one on one challenges will be just as popular. There’s just so much satisfaction in seeing a friend laughing and beating them in person. When we were playing head on head snake with two Nokia phones, one developer kept laughing and teasing that his opponent kept on crashing into the walls. The biggest laugh came when we found out he was the one crashing into the wall!
We hope the time will soon come when we can combine the techniques we’ve discussed above with local network calls. We can’t wait to laugh and play networked games on our own 6310i’s and 3650’s.
Read more about:
FeaturesYou May Also Like
