Programming Games On Computers With Limited Memory

Charles Brannon, Editorial Assistant

It's sometimes a challenge, but very good games can be written for computers with small amounts of free memory. If you're programming on an unexpanded VIC, Atari, Sinclair, or pocket computer or any other system with few bytes of RAM, these suggestions are worth remembering.

One of the most valuable elements of a computer system is its volatile memory, RAM. This "workspace" holds the program you're working on, its variables, and even the screen display and "system software." Managing memory efficiently becomes vital when writing games of any complexity.

There are many programming tricks you can use to save memory. The following list contains some of my favorite techniques – and many more can be intuited:

• Emphasize color and change. Any kind of movement will generate excitement. And don't forget sound. Sound effects can add sparkle to your program very economically. Most computers use no extra memory for sound. Various combinations of FOR/NEXT loops usually suffice for simple, yet pleasing, sound effects.
• Use "keyboard" graphics, or low-resolution graphics, imaginatively, and you can save thousands of bytes more than when you use a high-resolution screen. Remember that color changes are as important as movement to stimulate the eye.
• Abbreviate text and prompts. Avoid using players' names. Use their initials if possible. Unless unfeasible, never put written instructions into a program. Don't overuse strings, especially when a little math will permit the use of numeric variables. Both of these statements will extract the rightmost character of a number:

  A = VAL(RIGHT$(STR$(N), 1))
  A = 10*(N/10-INT(N/10))
  

• Limited RAM does not permit the luxury of easy-to-follow programs. Use REM statements sparingly (or not at all), to document subroutines or obscure program segments. You can write in REM statements on a paper listing of your program Use short variable names (not applicable to Atari). If you use a long constant more than once, such as 3.1415927 for pi, define it as a variable (PI = 3.1415927). This technique can save six bytes per use on the Atari, even for simple constants like 0.
• Compact program lines. Each use of a colon can save from three to five bytes, depending on the computer. Don't use spaces when entering a program, unless your computer automatically deletes spaces (e.g., Atari BASIC) or unless they are necessary for proper interpretation.
• Simplify coding. If a certain routine or formula is used more than once, generalize it into a subroutine or defined function (DEF FN if your computer's BASIC has this command). Don't have long sections of IF/THEN statements. For example: you can use "boolean arithmetic" to reduce the space-wasting IF/THEN statement. Try this line on computer: PRINT 1 = 2. Your system whould return with 0, indicating a "false" answer. Now try: PRINT 2*2 = 2 + 2. It should return either 1 or -1, meaning "true" (non-zero, 2*2 = 4 = 2 + 2). You can convert statements like:

  IF A > 0 THEN A = A-1
  

  to:

  A = A-(A > 0), or A = A + (A > 0)
      if your computer returns a -1.
  

• Program control can be simplified with statements like ON/GOTO. Break your task into blocks. Each block performs a discrete task, and a given block can "call," or use, another block. Not only is this structured programming technique easier to use, but it also saves memory by encouraging you to develop tight, fast "blocks." A bonus is that you can often use these programming building blocks in other programs.
• Don't overlook machine language. It's well worth learning, and the benefits you reap in high speed, programming techniques, and overall efficiency can repay your effort many times. "Hybrid" programs of both BASIC and machine language let you enjoy the best of both worlds.

If worst comes to worst, you can use a technique called "chaining," where one program loads and runs the next. This technique is prone to problems and is awkward to use. On tape, the programs must be contiguous, and the second program can not return to the first. Nevertheless, chaining is valuable for "initialization" code such as loading character sets or machine language, displaying the game's rules at the start, or reading or defining variables (if your BASIC permits chained programs to share variables). Chaining permits you to run programs of almost any size.