HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Today we have new gaming platforms. There are games for wireless phones and PDAs. Some calculators, watches, messaging pagers, and other handheld devices are also capable of supporting games. The purpose of this article is to apply basic game design principles to these devices.

I've worked as a designer and producer of electronic games since 1979. My first electronic game design was for a game watch (Game Time by GCE, circa 1981-82). I've designed handheld game LCDs, board games, dice games, and games for videogame consoles, computers, and the Internet. I'm not a programmer. The ideas in this article are based on general principles of game design - not on details of the technology.

When designing games for a new gaming platform, the first fact you must face is the constraints of the system. These platforms aren't generally intended to support games. These devices can't do what a PC or set-top console can. But that's okay.

In fact, it's more than okay!

With the capabilities of PCs and consoles increasing by leaps and bounds, the game designer has been pressured to make increasingly complex games. But on a constrained system, expectations are lower, so the pressure is off the designer to deliver complexity. You can look at these constraints as limitations that force you into simpler game play. Or you can see these constraints as a license to make simpler games. And in my opinion, the simplest games are usually the best.

The Specifics
Here are the main areas you have to consider when designing a game for a constrained platform:

  • Target audience
  • Graphics
  • Sound
  • User interface
  • Memory storage
  • RAM capability
  • Other special limitations or capabilities of the system
  • Target audience
  • Who's writing the checks
Let's consider each area in detail.

Target Audience
First, picture your audience naked. Okay, enough of that. Now picture them with clothes on, playing your game. Where are they? Why are they playing your game? Who are they? How old? What gender? What income bracket? What nationality and language? Be realistic, not idealistic, in this consideration.

Constrained gaming devices are typically portable. Your end user might be standing in line at Starbucks. Or maybe sitting at a bus stop (hmm, no - maybe a taxi stand or airport). Think of more examples where your user is while playing your game. "Where" and "why" go hand in hand.

The user of one of these new devices is probably an adult. An adult, most likely male, with money to spend on electronic gadgets. An "early adopter." These are mostly folks who spend a lot of their time multitasking. Not a moment is wasted: every idle moment affords the busy multitasker an opportunity to check text messages or stock prices... or to play a game. So how about this for a wacky idea: a game that requires the player to use those multitasking skills. A game that can be played in one-minute increments, in-between other tasks.

If your research shows that teen girls are increasingly using game-capable pagers, it might make sense to design a girl game for those pagers. But the teen girl demographic has historically been dismal for games. You might surprise everyone and break the historical trend (and garner headlines and big bucks), but is that really the hill you want to die on? Of course, if some company comes to you and offers to pay you to design/develop it, that's another matter.

Anyway, once having thought through who your target audience is, you probably have a few initial game ideas you want to explore. The next step is to consider the technical aspects, after which you may have to rethink your ideas, culling and/or refining them.

When working with a constrained platform, get all the information you can about the graphics capability of the system. There are some PDAs that support hundreds of colors, but right now the widest audience will be found for wireless phones, PDAs, and some types of multipurpose pagers, usually with black-and-white displays.

Consider the size and resolution of the display. One of the worst-case scenarios today is a Nokia phone with a black-and-white display capability (or should I say "limitation") of 90x40 pixels. 3G (third-generation) phones will surely be better than that; 4G will likely be even better. But all in due time.

Can your system display animated graphics, or do you have to work with still images only? Is it black-and-white, or can it support color, or shades of gray?

Using the smallest readable font, how many letters can you fit across the display? Does the system come with a font, or do you have to design one? Is your font variable-width or fixed-width? I once worked on a Game Boy game with a Japanese company. They had translated the game's story text into English, which was to be displayed in a text window, two lines by 16 characters wide. The text hadn't been written with this limitation taken into consideration; the user would have to click endlessly to read the lengthy text, sometimes just to read the final word of a sentence in an otherwise empty window. There was no question of enlarging the text window or shrinking the font, so it fell to me to rewrite the text to fit more compactly in the window.

Find out what your system is capable of visually, and make adjustments to your game as needed.

Maybe your user is a college student, playing a game rather than listening to a boring lecture. Or a guy in a cubicle, trying not to broadcast the fact that he's taking an unsanctioned game break. If so, the user will want to have the ability to disable sound. But it's important to have sound in your game. Every action in the game should be accompanied by a sound.

Find out what the system is capable of. What kind of sounds can it play? Can it play music? Can it play multiple sounds simultaneously? Often it's the case, with a constrained platform, that the answer to the last one is "no." It often occurs that two game sounds need to be played at the same time. So it's necessary for the sounds to be prioritized so that the more important sound is heard.

Let's say your game has a sound to indicate that the player character is walking, and a sound to indicate the death of the player character. If the player character is walking when he gets killed, it's the death sound, not the walking sound, that needs to be heard.

The highest-priority sound in your list is the "game over" sound; you can figure out the rest from there.

User Interface
Consider the methods by which your user can interact with your game. If you've seen other games on your platform, consider using a similar interface scheme. That way, players of other games don't have to learn a whole new paradigm when picking up yours.

Phones have a 12-button dial and a couple of other buttons, not all of which are available to you for game play. There's no joystick or mouse. You'll need to check which buttons can be used for the game. What will happen if somebody calls while the user is playing? How can the player get out of the game to make or take a call? Typing text is a pain on a phone; try not to make the user do stuff that isn't fun.

Palm-style PDAs have a stylus, and a couple of other buttons. The stylus should be the main input mechanism - probably the sole input mechanism - for the game.

Other PDAs, and some pagers (like the Motorola PageWriter) have QWERTY keyboards. Keyboards are both good and bad when it comes to gaming. The good thing is there's already a game interface "language" that's been established that you can use. The bad thing is that too many game input buttons can make things confusing for the player. Limit the use of the keyboard to the most logical and intuitive keys, and let the player configure them (and make it easy to find the config menu).

Consider how the user can exit the game, go do other tasks, and come back. Consider how the user can quit a game that's going badly and start over. Your game must be intuitive; your user won't be carrying an instruction booklet everywhere. There shouldn't be a need for an instruction booklet at all.

Data Storage
As a designer, I don't necessarily need to know exactly how many bytes of data the platform can hold, but to know whether it's "very little" or "fairly roomy" helps me put things in perspective. Can your game system support the kinds of features you initially envision for your game? For example, can it store the graphics for multiple screens? Can it store animations and sounds and game logic?

Not being a programmer, it took me a long time to realize the difference between data storage and RAM, and the impact it has on a game. For the nontechnical designer, RAM size impacts how much stuff can go on during a particular level or stage of your game. Your game doesn't need to load into RAM any sounds not used in the current level, for instance. Once again, get an idea of how much RAM is available, and what impact it will have on your initial basic idea.

Other Limitations
All your dreams for your game idea will probably be dashed once you work out what you can't do on the intended platform. In this case, just close your eyes... imagine the world from the other side of the mirror... and figure out what you can do.

Look for inspiration in new games like EA's Majestic. Find new play paradigms that take advantage of what the hardware was designed for. Calculators are good for math: think about math games and puzzles. Wireless devices that have a QWERTY keyboard would be good for text-based games, involving sending and receiving messages. Palm-type PDAs let you write by hand and touch any part of the display with a stylus. This can be better even than a joystick or mouse for solitaire gaming.

A wireless phone may not be able to support streaming video (not now, anyway - maybe 3G phones will be able to). But think for a second. There's a streaming medium that phones are good at: audio. That's what phones were designed for in the first place. How about a game that involves listening, or maybe even speech input? If you're designing a two-player game, maybe there's a way to use the players' voice mailboxes as part of the game play. Phones let you hear, talk, and connect to the Web - or to other gamers - from anyplace. And you might not stay in the same place as you do it. Some systems can even detect and track your proximity to other specific phones (e.g., other players) in real time. While you may see possibilities for connecting multiple gamers through wireless phones, for now perhaps you should limit your thinking to two players max. The world isn't yet ready for Massively Multiplayer Wireless Phone Gaming. Well, even if it is, the technology isn't quite there yet.

MGI, 3G, PS2, i-Mode
Every wireless phone is different, and every phone network uses different standards and protocols. Progress is being made on wireless gaming all the time. But "progress" doesn't necessarily mean that one universal standard is coming anytime soon.

In July 2001, Ericsson, Motorola, Nokia, and Siemens announced they'd joined forces to create a standard for multiplayer wireless gaming. The name of this joint effort is "the Mobile Games Inter- operability Forum" (MGI). This effort won't do much for users of today's wireless phones. Rather, the standard will apply to 3G networks and phones. Don't expect to see developer kits on this until 2002.

In addition, NTT DoCoMo is involved in an effort with Sony and six other wireless companies to develop a wireless gaming service based on Sony's PlayStation 2 system (Hint: It's sure to be better than WAP; no hints yet as to how it'll compare to 3G). NTT DoCoMo and Sega are also working on games that will link i-mode phones to Sega arcade games.

Whatever the system, get the specs, and you can design a game for it.

Target Audience
This isn't a mistake: I intentionally listed "target audience" twice. If you're wearing a hardhat, please take it off for a moment while I hammer this in: you must consider the target audience first.

It's unlikely that any grandmas will be playing your PDA game. And it's unlikely that many kids will be playing your game, since we're talking about hardware used by adults. The main users of the devices under discussion are early adopters. Early adopters might enjoy games involving money, or cutting-edge technologies, or time management.

And finally, you also need to think about...

Who's Writing the Checks?
The typical game designer (at least, for the constrained platforms we're discussing here) is not necessarily going to be selling the game directly to the end user. Wireless games are billed and tracked by phone services, not by game companies or game programmers. What's the business model in your case? You need to know.

Where's the money coming from for your project? Perhaps a PDA manufacturer hires you to design a game that takes advantage of the features of a new PDA they want to tout. Perhaps your assignment is to make an advergame, a regular game that contains product placements or billboards for a company interested in selling its products to the audience playing your game.

Your client is the company that's paying you to produce this game. That company, not the end user, is your direct customer. Remember the old adage, "The customer is always right." If you want to make money designing and/or developing games, you need to listen to the client's requirements and desires, and deliver accordingly.

First you start with the known parameters: the capabilities of the system, the preferences of the target audience, and the thinking behind the hand that writes the check.

Don't try to make the platform do things it wasn't designed to do. Rather, try to find ways to have fun with those special capabilities it was designed to do.

Because the constraints of these devices don't allow you to make a Myst or a Quake, you are freed to go back to the classic purity of small, simple games.

To discuss this article go to www.sloperama.com/advice/bulletinbd.htm.

Editor's Note: For all of you wrinkling up your nose because this is an article on design, don't be too quick to wreck your rugged good-looks. If you're developing games for constrained devices, then there's a chance you'll be involved to a degree in game design. In fact, I suspect a lot of you will be wearing both design and development hats in your game development efforts.

Tom Sloper was designing games back when Man was still trying to figure out how to roast those prime haunches of mastodon meat... okay, that's an exaggeration, but he was certainly around close to the beginning of things, in terms of the games industry. Where better to learn than at the feet of the master?

Author Bio
Tom Sloper produced and designed games at Activision for 12 years, and is now consulting and designing independently. [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.