Epilogue

I'm going to assume that if you are reading this, you've read most if not all of this book. To you, I say congrats! I would also like to hear from you with comments and suggestions. You can reach me at the following e-mail address:

• < justin @infinitumdesign.com>

It's been a long journey, but there is still more to cover. Whole sections ”if not whole books ”could be written on subjects in Flash I didn't even mention. The Flash IDE is packed full of helpful tools and commands if you dig into the documentation and experiment. The subjects of AI and physics, which we have only touched on, can be lifetime studies.

Now comes the most difficult part of your study. You must learn what makes a game fun and how to incorporate that into your games. Most of the games in this book were developed to demonstrate certain techniques and strategies involved with how the hard parts are done. As such, they don't always have all the small details that take games to the next level.

Fun games evolve with a great deal of effort, tuning and refining, and extra details. Implementing the final details is where a lot of developers fall short and end up with weak games. The developers who go the extra mile to refine the game to add to the experience are the ones who end up with fun games.

Chapter 11's game Pachinko is the best example of this. The engine works, but it feels like it is missing something. To add fun, we could make millions of flashing lights, spinning dials, and crazy sound effects. Then we would need to give the user many different goals to move through. When the user got balls into certain pockets, things would change and open other pockets, and so on. Maybe we could make an overall theme in which some kind of movie plays, but only in pieces so that the user must solve the game to see the entire thing. Each goal completed brings the user closer to some final event.

In addition to adding elements to your game, many games are strong or weak based on simply tweaking settings. Do you start out with too many balls? Does the speed of the ball falling feel right? Are certain targets too easy or too hard to tweak? I've always found that a good game is easy enough to draw you in for a few minutes but provides a challenge fast enough so that you do not get bored.

Now we're starting to get a game design that might be fun to play. With another couple of hours of brainstorming, the new Pachinko design might be really great. But the implementation of that game is going to be significantly larger. Consider that the existing Pachinko code is less than 300 lines. A more complete implementation could be two to three times longer. With such a drastic difference in code length, you start to see the cost of making games that are fun. Fortunately, the benefits of a compelling game will always outweigh the costs involved.

Now that you've made it through all the games in this book, you should have all the coding tools you need to start making your own games. I highly encourage you to come up with all the fun game ideas you can, but if you are looking for a convenient outlet for your bourgeoning game-development skills, I suggest that you take one of the games from this book and continue its development. Regardless of whether you develop your own game ideas or take these games further, I would be excited to see your end result!