Designing Your Game

I'm sure you're as eager as hell to start developing a game, but before you get into some code again, you need to work through how to design a great game.

Just because J2ME games are smaller than their big-system cousins, developing them isn't necessarily a walk in the park. Completing a commercial-grade J2ME game typically takes two to three months of hard work. No, really; let me say it again. If you're serious about making a great game, it's going to take months. You're not going to get anything good done in a few weeks.

Although this timeframe pales in comparison to the 2 to 3 years of development time for average PC games, you're still making a significant investment to develop your game. Therefore, it's important to be as sure as you can about the quality of your game before you run off and develop it.

Having said all that, one of the great aspects of J2ME projects is the short development timeframeusually only a few months. Instead of working (or slaving) away for years on only a small facet of a game project, a J2ME programmer can work on all aspects of a project and have an end always in sight. Short projects are typically easier to manage and cost far lessand, to be honest, it's easier to stay interested in a project for a few months than it is for a few years.

Because projects are short and labor is the most significant part of development costs, you can go from idea to completed (hopefully revenue-generating) product in a few months using a small team (or even alone). This isn't an "indie" pipe dream; it's possible to develop something as good as (or better than) products from some of the best studios in the world. The best part is, you can do it by yourself, part-time, using only a broken pink crayon …okay, maybe you need a computer, too.

The low cost of development (and by cost I mean time as well as money) lets you be far more creative with your game design. With a reasonable toolset and basic game programming skills, the sky is the limit on the design of your game. The low cost means if the design isn't working, you're wasting a few weeks or months, not a few years.

The Platform

Most J2ME game designers start out as PC or console designers (even if they're amateurs). This leads to the most common mistake made by new J2ME developersdesigning a game based on PC concepts rather than MID ones. If you're in that category, let me open the Almanac of J2ME Game Design and tell you a few things againand this time I really want you to listen. The screens are tiny; the input is slow to respond; the keys are hard to handle; you can't use simultaneous key presses; the JAR and memory size will severely limit your graphics, sound, and level resources; the CPUs are slow; and above all, you can't rely on the emulator to tell you whether the game is running well!

If you're not listening now, you will be exactly 54 percent of the way into development when you get your first java.lang.OutOfMemory exception! These concepts are fundamental to designing a good game. Meet them head on and work around them; don't try to ignore them or hope that players will just use the PC emulator for your game. J2ME games are great fun to make and play, but only if you work within the true constraints of the device.

Minimum Requirements

Before you start designing you need to decide quite early on the basic MID required to play your game. For most types, this comes down to three minimum requirements screen size, color support, and JAR size.

Deciding on screen size is a reasonably easy exercise. Most gaming-class MIDs are greater than 100 pixels square, so this is a reasonable starting point. In later sections you'll review how to develop games to dynamically adjust to the size of the device. Although this is a good idea, it is only effective to a certain degree. You need to establish a minimum size in order to set the basic dimensions of your graphics. Keep this a little loose at this stage; when it comes to the technical implementation you can adjust the size if there's a good reason to do so.

So suppose your minimum screen size is around 100 x 100 pixels. The next decision is whether to design the game for color. If you drop the monochrome graphics from your design, you're potentially limiting quite a portion of the market. Do you really care, though? The vast majority of new phones are color. Are people who still buy monochrome mobiles the sort of people who buy games? I recommend designing a game for color from the ground up. If the game is a commercial success in the color phone market, you'll likely be invited to port the game to lower-end devices anyway (assuming this is practical).

The minimum JAR file size a MID can handle is again something with which you can be a little flexible. However, setting a general indication is a good idea at this stage because it will focus the design on the largest limitation. My absolute minimum size is usually 64 KB. Anything after that is an optional extra the game has to be able to live without in the low-end versions. Now just to clarify, that means in order to run our game the MID must support a JAR size of at least 64Kanything less and the game won't run.

Reference Device

Next you need to choose a reference device. This won't be the only device you support it's just the device chosen to serve as the primary target platform. The reference device you choose should not exceed (at least by much) your minimum requirements. Most importantly, choose a device on which you really like to develop. (Having access to the real phone is a bonus as well.)

Due to their extensive J2ME hardware support, excellent online resources, great phones (and emulators), consistent platform, and obvious commitment to gaming, the first annual Marty award for preferred reference device goes to ...the Nokia Series 40 (crowd roars).

You'll notice I haven't picked a particular phone model. That's because the folks at Nokia are kind enough (and smart enough) to categorize all their devices into different series.

The Series 30 are small, monochrome screen devices with limited resources. The next step up, the Series 40, has a 128 x 128 pixel color display and a maximum 64-KB JAR file size (although many support larger sizes). You can see a typical Series 40 device in Figure 8.2. This is perfect for your needs at this stage. The next level up, the Nokia Series 60, is also an excellent platform, but the features are a little too far beyond your minimum requirements for it to be a practical reference device.

As you saw in Chapter 6, Nokia's LCDUI toolkit provides a host of great features, including access to the full screen area, transparency, and imaging tools such as rotation and reflection. These are important features for which you'll specifically code when you do your device porting. For now, though, you'll be sticking to only those features supported by the standard MIDP.

Platform Setup

That's basically it for deciding what type of platform you need to support. Requirements such as minimum screen capability and JAR size are not set in stone. The important thing is to have a solid starting point from which to base your design.

Now that you have a basic platform, you should take a little time to set up your development environment by obtaining your reference device's emulator and work through any sample applications the emulator includes.

When you're ready, you can move on to figuring out what sort of game you want to make.

What Makes a Good Game?

And so we come to the ultimate question: What makes a game addictive? Why is one game just a bit more compelling than another? Understanding this is probably the key to whether your game will be a huge success, yet another shooter clone, or a sad reject nobody wants to dance with. There are five requirements to make a game greatit must be fun, addictive, compelling, cool, and above all, commercially successful.

Goals

The absolute number one thing a great game needs is goals. Present players with as many as you can simultaneously, and then progressively reward them as they achieve things. Even better, increase the challenge of goals as you go.

For example, a good game will present a power-up to a flying spaceship, and then reward the player for picking it up by enhancing his ship (and maybe including some groovy new weapon-fire graphics as well). This will give the player an immediate goal to acquire the next power-up, and you've established a goal just by presenting the power-up in the first place. This alone will make a good game. But a great game will take this further by making the next power-up a little harder to getmaybe you have to shoot down a certain number of enemies to get it. This way, you're not only giving the player goals, but you're also expanding those goals as he progresses. This always makes for highly addictive game play.

Some types of goals are inherent in many gaming genres. Action games, for example, set the goal of the player getting through to the next level. The goal is for the player to progress past the obstacles you place in his path, and his reward is seeing those cool new areas.

Balance and Completeness

A good game needs to balance the progression through challenges and rewards. Players have an expectation of how much time it will take to complete a game. (It's surprisingly short for most J2ME gamestypically two to five play hours.) You need to present them with content at a steady pace. You should think of it a little like a tapturn it on too fast and you'll give away too much of your game early on. I know the temptation will be to start your player with those rapid-fire Vulcan cannons, but there's no need. The player will prefer to earn them along the way anyway. Start off slowly and use your content (game play elements) as a reward in a progressive manner.

Game balance also means not making things too difficult too quickly. Players need a challenge, but it can't be so great that they get frustrated and give up. The opposite is even more the case; if a game is too easy, a player will give up even faster than if it's too much of a challenge. So how do you know when you've struck the right balance? Easyjust play the game from the start and measure whether things are too difficult or easy as you go. (Having friends play the game is also a great idea.) If this sounds like a lot of work, you're rightit is. Play testing and game balancing are difficult and very time-consuming processes, but they make the difference between fun and frustration.

Originality

I'm sorry to say it, but game players generally don't want new gamesthey want better versions of previously great experiences. A truly original game might be a groundbreaker, but the chances are against it being commercially successful even if it's fun. So does that mean your game should just be a clone of others? Hell noyou have to make your game a new experience for players, but try to take a workable formula and then just push out the edges a little. The more successful you become at development, the more you'll be able to push those edges, and the more original your game will be.

Technology

Games are a unique medium because they have such a strong mix of technology and entertainment. Technology, however, is not the entertainment; it's just the mechanism that delivers it to the player. Contrary to what might seem like popular opinion, people don't play games because they are technically superior. Players might see the latest 3D rendering trick as cool, but only because it means better content and therefore better entertainment value for them.

However, technology is one of those things you can't get wrong. A great game requires great technology. It needs to run smoothly, look good, and deliver the game's entertainment value without a hitch. In other words, it should be so slick that the player never has to think about it.

Don't get caught up in technology too much. If you want to push the boundaries a little, make sure you don't try it on your first game. And when you do, add a few slick things to a new game and keep everything else tried and true. Nothing will kill your motivation faster than endless crash bugs and nightmare math problems.

The Inspiration

Designing a J2ME game is a difficult exerciseironically, I find that the more I do, the harder it seems to getso be prepared to commit some serious mental energy over a reasonable period of time to come up with a solid design for your game. The good news is that this time is more than worth it. The beginnings of a hit game lie in coming up with a realistic, workable, and entertaining design. I guarantee the final game won't be the same as the original plan. This is a good thing, but it's important to get things off on the right foot with a design that reflects the foundation of what makes your game good.

The first step to any good design is a little thing called inspiration, and the best source of that is (you guessed it) other games. Go out and play all the J2ME emulator games you can find. Then go buy some commercial games for your phone and play them to the end. (No, really, I mean itdon't just play the demos!) This will give you design inspiration and provide a technical benchmark from which to work. As a bonus, you'll see the sort of quality a commercial game requires, the length of the game, and technical implementations. You'll also get the basic feel of players' expectations.

While playing some of these games, you might come across what seem to be strange limitations or other peculiarities. Don't dismiss these immediately! There are some great developers out there, so take note of how things are commonly done. Even if you think it's a bit weird (or you just think you could do far better), there's usually a good reason why things were done that way. Keep the platform limits in mind when you are reviewing games.

Visualize Things

Once you have a good dose of inspiration, you need to settle on the type of game you want to make. Above all, pick something that you're excited aboutsomething you have no doubt will be great fun to play (and hopefully develop). If nothing leaps out, by all means start with something standard, like an action game.

After you have an idea for your game (even if it's pretty vague at this stage), move on to creating a mock-up of the core play screens. Try to keep things as close to the actual scale of the game as possible. This is worth quite a bit of time because you'll be mentally working through a great deal of how the game feels as you create the mock-up. Then you can move on to other screens that involve different game scenarios. When you do, try to imagine how the game would feel if you were really playing it. Don't worry if you find this hard at first; it's something you'll get better at with practice. While you go through this visualization process, note the top ten things that really kick in the design. (This list can change often.) What is really great about this game? If you struggle to come up with ten, then think twice about the design.

Keep the list of good game-design practices in mind as you work through your design. What goals can you set for the player? How does the game progress through stages? What motivates the player to keep going?

As you move along, don't worry too much about the technical implementation. You need to be aware of basically what's possible, but for now stick to designing the basic concept of your game, and then build up a list of game features you'd like to have. Keep these ideas modular so that when you get to the technical implementation, you can add or remove components easily.

If the game still works for you after this type of visualization (I usually find about one in five makes it past this level), then get someone else off whom you can bounce the idea. Another programmer or artist is an excellent choice for this. If the design still comes up good after they've shredded it a bit (hopefully they're now excited about the game as well), then you can move on to creating a design document.

The Design Document

Writing a design document is traditionally not a great deal of fun. For most PC games, they tend to be long-winded, jumbled messes that don't help anybody, including the author. But they're still a required tool in the game-design process for two reasons. First, the process of creating a design document forces you to consider many of the aspects of your game design that you likely skipped over in those excited 2:00 a.m. debates. It all sounded good at the time, but in the cold light of a structured design, you'll quickly find that some aspects just don't work as well as you thought they would. Second, a good design document serves as a background reference for your game. Anybody who works on the project can quickly come up to speed on your idea by reading the document. I include my Top Ten Things That Kick about This Game section as well. Periodically rereading the list can be motivating and help keep you focused on the things that make your game fun.

Design documents also bring some order to development. It's only natural to break the game into sub-modules as you progress through the design. This will help you organize the development later.

While working as a game producer, I used to receive design documents from budding game developers. It amazed me how long, overly complicated, and boring they tended to be. We're in the games business! A design doc should be fun, easy to read, and above all, make you wet your pants about the game. Leave the deep discussion on UI issues or sound system implementation notes to the technical specification (if you even decide to have one).

The easiest way to write a good design doc is to keep it short. For J2ME games, this is especially easy because the games just don't have the breadth of features to fill ten pages, let alone 200. Start with the idea of writing two to three pages; if the doc ends up slightly longer, that's okay. But it should be concise, fun, and above all, make you remember why you really want to make this game.

To get started, write down all your ideas, but don't let yourself become caught up in the format, structure, wording, or grammar. Just blast away as though you were explaining the game to another game addict. If something doesn't make sense, don't worry too much; just keep banging away with all those ideas. Leave the editing and structuring until after you have the bulk of the content. The most organizing I do at this point is putting a heading on each idea section.

After you've laid down everything, go back and organize the document into the following broad sections.

• Introduction. Write a two- to three-paragraph sales pitch on the game. Don't try to fit in everything in detail; just lay down a broad overview of what you're trying to achieve. At the end of this section, make a top-ten list of the things that really sell the game idea. Remember, keep it short.

• Setting. Describe the setting for your game. You might find this works better as part of the introduction. For J2ME games, settings are usually quite simple anyway.

• Game Play. Describe the basics of game play. Where does the player start? How do they progress through the game? This is where you need to organize things into the goals and rewards you're presenting to the player. I tend to list these in connected series, such as all the power-ups and how to get them. If your game has different levels or areas, list these and feel free to describe the setting, challenges, and any other interesting ideas along the way.

• Interface. Outline the user interface and game controls, such as the main menu items and their functions, along with all the in-game control keys. You might find that a simple storyboard showing the progression from splash, menu, and game screen helps as well.

• Features. List any features or ideas you have not covered in previous sections, such as online high scores or a random level generator.

• Platform. Detail the minimum requirements and reference device details. List any ideas on future features you'd like to take advantage of on different phone models.

• Resources. Create a summary list of all the sound, graphic, and level resources you think your game needs. Then estimate the size of each resource and total the amount at the end. If you're not sure about the size, go mock up some graphics and save them as PNGs. The total size needs to be quite a bit less than the total JAR size to leave room for the class files.

  Also consider making some of these resources optional. Maybe you can reuse graphics by overlaying decal sprites. I guarantee you'll run out of JAR space, so try to get an idea early on about what you absolutely can't live without.

• Tech Notes. List any technical implementation notes or ideas you have. Don't talk about the obvious; just describe anything special you want to do.

As you work through your design document you might find that some aspects become frustrating or confusing. Don't ignore these; the reason you're doing this in the first place is to force you to think through your idea properly. If there are issues now, you're far better off resolving them on paper than after you've started coding.