We have already seen that games can be quite large in size. Optimization is something a game designer can do to help decrease the demands of his program on a user's calculator. A game maker may choose to swap out routines or functions with ones that require less memory or remove parts that are unnecessary. This is all part of the optimization process.
Repetitive coding, for example can be replaced with some sort of a loop. Take, for instance, the program below:
:ClrHome :Circle(0,0,1) :ClrHome :Circle(0,0,2) :ClrHome :Circle(0,0,3)
ClrHome is a 2-byte token; the others are one byte each. That makes the above program 32 bytes long. Now take a look at this:
:For(A,1,3) :ClrHome :Circle(0,0,3) :End
This program is only twenty bytes long, a savings of 12 bytes over the above example, or over a third of the program! Twelve bytes may not seem like much, but applied to the entirety of a large game, it does make quite a difference.
Optimization can be a daunting task for someone who is not familiar with the intricate nature of the command options available. For this reason, I will provide some rules to optimization. Remember, that there are two main reasons to optimize: for speed and for size. Oftentimes, these are redundant, but not always.
Goto command when necessary.The optimization process never ends. Any time you find something that you can change to make your program smaller and faster, you're back in the game.
The debugging process is the most grueling part of the game design process. It involves finding and correcting issues that cause the program to malfunction. The easiest of the issues to resolve are the ones that trigger errors. But some of the issues we will be looking for will not yield errors. These are the trickiest to catch, but we will take a look at them in due time.
There is a vast array of run-time errors, issues that can arise from improper code. TI-Basic, our language of choice here, is great for this because the calculator will tell you where the error is.
Syntax errors indicate that you typed something invalid into the program, such as an extra comma or period, or placed a quotation mark into a string. Selecting 2:Goto in the error menu will scroll to the line of the program on which the error occurred.
Argument errors indicate that here are too many or too few arguments for a function, or one argument is of the wrong type. Again, selecting 2:Goto in the error menu will take you to the error's location.
An archive error means a variable you called cannot be read because it is in the user data archive. Again, you can use 2:Goto to find the source of this error.
The undefined error means a variable you're using doesn't exist. You can use 2:Goto with this, as well.
Label errors are more difficult to debug because they do not have a 2:Goto option to help you find the source of the error. You must locate the sector of code manually, locate the undefined label and determine what to add there.
There are no separate classes of logic errors. This is because all logic errors have the same things in common and have the same effects. Logic errors are especially prevalent in game programming, where the variety of variables and the length of the code can often lead to many simple mistakes.
A logic error occurs when the program does not throw an error, but some improper coding causes it to act improperly. A logic error is hardest to pinpoint, as it occurs when variables intermingle in a way that throws one or more of them off. For instance, using X and Y in games that utilize drawing commands will cause a logic error. Logic errors cannot be located via error breaks. To fix them, mentally follow your coding and determine what needs to be changed. The best method of doing this is to place pauses in segments in the program. Use that to break the execution on the segment that is causing the error. Triggering a break takes you to the section of the program that was running when it threw the break error. From there, search for the problem.
