With Your First Game out of the way, it’s time to start thinking about your next game. It seems reasonable to come up with at least one more dice-related game because you have all those three-dimensional dice renderings and the code to make it bounce around realistically.
So, then, without knowing exactly which game to write next, what you need to do is grab the dice-related code out of the first project and bring it into the second project. The first reaction that strikes many programmers (especially inexperienced ones) is to copy the old project to a new project, hack out all the undesired code, and start over using some of the code from the first project as the starting point. Although this accomplishes the task and may even be easier in the short run, coding in this way can lead to nasty problems down the road. What if, for example, somebody finds a bug in the die-rolling code? For example, somebody reports that the die occasionally gets stuck when it bounces directly into the upper-right corner. After lots of careful debugging, you determine the cause of this bug and that the fix requires a fairly big rewrite to one of the routines. You finally get the bug squashed. Now, how many projects are you going to have to go back into and make the same fix?
Even if you decided to copy the die-rolling code from the first game into a second project, this task is hard because the die-related code is scattered all over the first project. The code contains declarations at the top of the project, bitmap setup code in the form’s Load event, and several methods specific to the die rolling. You’d have to remove these individual pieces from the first project to copy them to the second project.
This lack of organization is only one problem with the die-rolling program as it currently exists. Here’s another—what if your next game requires two dice rolling around? Or three? If you’ll recall, most of the dice information resides in some “loose” variables that are fields on the Form class of the game. What organization would the code take if you wanted to have two dice? Would you simply double the number of loose variables (dieXPos1, dieyPos1, diexPos2, dieyPos2, and so on)? Or, perhaps you’d switch to arrays (diexPos(0) and dieyPos(0)).
Whether you’ve guessed it by now, this is a problem screaming out for an object-oriented solution. There should be a Die class in the program because the die is a “thing” in the program. One (perhaps overly) simple rule when writing an object-oriented program is to look for the “nouns” in a program and convert those nouns into classes. This is especially true if the nouns in question will be occurring in pairs or groups. By turning the die into a Die class, the program can merely instantiate two Die objects when you require two dice. This solution also scales upward—if some crazy game requires 1,000 dice, then the project could instantiate 1,000 Die class instances.
So, the object-oriented solution looks like it will handle the multiple dice problem. How about the organization problem? Well, if you can place all of the die functionality into a class, then you can probably find any bugs in that functionality in the Die class code, which you’ve separated from the rest of the program. If, for example, the die occasionally gets stuck in the upper-right corner, you’d know that the Die class—a specific part of the program—is behaving incorrectly. This eliminates the need to hunt for the bug in other parts of the program. Furthermore, if the Die class is compiled into something called an assembly (its own DLL file) and multiple files share that assembly, then fixing the bug in that one class will fix it in all programs that use it.