The most important part of designing a game is in the planning process. Often, how well you plan you game determines how long it takes to finish, how large it is, how organized it is, and how much of it you will need to fix later. In planning a game, the first thing you should do is write down what you want to accomplish. This can be one thing or many things, depending on how complicated your game is going to be.
The next thing you should do is think about what data you need to collect and choose variables to use. Remember, once you decide to use a variable for one thing, it should not be used for anything else unless you're sure they won't cause conflicts. Just remember never to use the variables X or Y in games that use the graph screen, as the OS uses them as well when updating the graph. Lists are very useful as arrays, especially since you can give them a unique name such as LMYLST so that no other program tampers with them.
Then start laying out your program. Plan out the structure of your program so you can figure out where to put your loops and conditionals. Once you know where everything is going to be, you are ready to move on.
Now you can actually code the game. This may or may not be the lengthiest part of the process, depending on how long it takes to debug. In this stage, you actually figure out how to make things the way you wanted them to work when you were planning.
Sometimes, it can get hard to write one large program. When you need to go to a particular part of the code, long programs take longer scroll through, and this can quickly become annoying. To make coding easier, you can divide your game into sections, each in a separate program, then put it all together after the coding and debugging's done.
The uses of TI-BASIC in game design, the stuff we've all been waiting for, are listed in the next chapter. The next chapter will not discuss all portions of TI-BASIC but only those commands that are relevant to game design.
The final and most annoying part of the game design process is the debugging stage. In this process, any errors are removed from the program, and it is optimized to run faster or take up less memory. Not all programmers will find this easy. I often find myself taking longer to debug a game than I did to design it. While some errors are easy to find because the calculator can throw an error and point to its location, some errors are less visible. This is because there is nothing actually wrong with the code (the syntax). Instead, there is something wrong with the way the program works, which causes things to work differently than you expect. For example, a program that uses the variables X or Y will find that things glitch up as soon as they try drawing commands, since the OS modifies X and Y when drawing. It's issues like these that frustrate programmers.
