The Development Process

After you've completed the design document, you're ready to begin development (assuming you still want to create the game). Next I'll review a little about how you should tackle the development process.

Creating a Prototype

Rather than just leaping in to develop the entire game, at this point you should aim to create a working prototype. The point of a prototype is to prove the viability of the game's design. Your aim should be to mock up how things should work. Don't worry about splash screens, menus, saving the games, or even proper artjust throw something together with basic game play. The goal is to prove the game works before you commit serious resources.

If you're starting from scratch without an existing game code base to work from, then a prototype can take quite a bit of time50 percent of your total project time is not unreasonable. There's no problem with this because most of your prototype code will be reusable in the final game, anyway.

After playing with your prototype, you'll typically have to go back and revisit the design. Some aspects of the game will work, and some won't. Be very conscious of what's fun, and cut or rework the things that don't come up well.

Developing the Game

When you're satisfied that your prototype game is on the right track, you can start to flesh out things like graphics, levels, bosses, and everything else that makes a kick-ass game. The order of development is up to you, although I prefer to concentrate everything on the core game play and then wrap up by doing the splash, menus, save/load, and other little touches at the end.

While you are developing, you need to keep a close watch on your JAR size. As you add graphics and classes (and even methods), the amount of space you have left will decrease. Being aware of the differences in size as you progress will help you track the effects new features will have, and will also trigger the space alarm bell.

When the JAR is about 80 percent of its maximum sizeit's surprising how fast you can get to this limityou need to seriously consider whether something is worth adding. If you're working on the core of the game play, you also need to reserve quite a bit of space for the menus and splash screen. (A good splash graphic could easily cost 7 KB to 10 KB of JAR space by itself.) Also keep in mind that some distributors or carriers will require a small amount of space for their own uses (such as copy protection).

One of the great things about J2ME development is that projects end! You will reach a point, usually before you've finished even half of the features you planned, where you just run out of CPU cycles, JAR space, memory, or all of these combined. If you haven't spent literally years on PC game development projects, you can't know how great it is to actually wrap up a game and move on to something else. With J2ME development, you have to! There's no space to add anything (even new methods) without removing something else. Wrap it up and send it off; then move on to the next project.

Finish What You …

A final word of development advice: If you've never done any professional game development, let me let you in on a little secret. You're going to fail. Trust me. No matter how great you are (and I'm not saying you're not great), the reality of actual game production is something you can only experience firsthand. The chances of creating a commercially successful game the first time around are very low. Your goal for your first production should be to learn as much as you can about the process. To accomplish this, I would strongly recommend taking things all the way through to completion. Even if the game is not good enough to really do that well, there's a huge difference between a half-completed, might-have-been-great game and a finished, average game. The secret to making great games is to make bad games first.

Being successful at writing games is very much about the reality of game production. How good a game can you really make? How long will development of all those features take? How does the game finally come together? It's all about understanding what's practically possibleand more important, what players want out of a great game. The way to gain that understanding is pretty easyfinish some games.

Games are very complex beasts (yes, even J2ME games), so as you near the end of production, you're going to end up with something. It's not going to be what you designed, but it will be a game. (Hopefully it will be something like your design, although you'd be surprised how much a game can change during production.) It's only as the game matures into reality that you can appreciate the one factor that decides whether you have succeeded or notis it fun to play?

Taking a game to completion involves a great deal of work (usually about ten times what you originally thought it would take). Following through on a single production lets you see the full breadth of problems faced at each stage of production. If you give up partway through your next game, you'll likely succeed right up to the point where your previous game failed. At this point you'll run into an issue you didn't encounter before. Understanding the complexities of implementing a save game feature, adding sound, localizing for different languages, or just performing the endless tweaking you need to balance the game experience…. All these issues sound easy in isolation, but at the end of production (or what you think should be the end of production), these things can become frustrating nightmares. The moral of the story is, try to wrap up the game, whether it's a great game or not, before you move on to your next project. Next time around you'll get everything right because you'll know what to expect.

All right, I'll get off my soapbox now. Now let's go over what sort of game you're going to make.