The Rise and Fall of the Hobbyist Game Programmer
By James Hague
or a small percentage of enthusiasts, there's always been the calling to jump from just playing games to creating them. It's crazy, of course, because the rush of playing a great game doesn't carry over to spending twenty straight hours in the basement trying to figure out why a level initialization routine fails ten percent of the time. But those that persisted, they drove the industry in its early days.
I remember reading about Mark Turmell - and others whose names I've forgotten--who were somehow inspired to design their own games, and then sit down and figure out exactly how to turn them into something their friends could actually come over and play. Those were fantastic feats that started the chatter about computer games becoming a new art form. One person, one vision, and six months later a finished product that was snapped up by a publisher--pure creation. A new alternative for would-be novelists.
The dream is still alive in these days of 32-bit processors and 3D accelerators, but over the years the reality behind it has quietly slipped away and few have stopped to notice.
In 1981, personal computers were in the thick of their 8-bit heyday. Not only are we talking about an 8-bit 6502--a processor with one primary register and no multiply instruction--running at less than 2 megahertz, but it was still acceptable, though just barely, to write games in BASIC. Now don't get me wrong, BASIC was the downtrodden interpreted language that it still is, but it shipped with every Apple II and Atari 800, and was the obvious choice for budding programmers.
As a rule, BASIC games were flaky and slow, but listings for such games appeared in popular magazines for readers to spend hours typing in, often ending up with no more than a simple, choppy, Pac-Man clone. Many BASIC games even ended up on store shelves or being sold through the Atari Program Exchange.
It is difficult to comprehend the technology involved in writing a game in Atari BASIC. Even with a processor that could only deal with 8-bit integers, all variables in Atari BASIC were stored in a six-byte floating-point format. Adding two floating-point numbers could easily take a hundred instructions or more. Consider a simple statement like "POKE 1536,0"--which old-timers will realize puts a zero into memory location
1536. Both numbers, 1536 and 0, were stored as six-byte floating-point values. At run-time they were both, unnecessary as it may seem, converted from floating point to integers, requiring obscene amounts of computation, before the simple act of storing an 8-bit zero into memory. This is on top of the language being interpreted in the first place.
Other operations could be similarly horrible. "GOTO 2000", which would jump to line number 2000, did a linear search through all line numbers in the program to find the target line. As programs got longer, so did the amount of time for the search. Even the "NEXT" in a "FOR...NEXT" looping structure did such a scan, rather than remembering where in memory the loop started. No wonder assembly language was considered the only real option for pro-quality titles.
So how, with all these obstacles, did hobbyists manage to write their own interesting and original games?
One big reason was that lots of good documentation was readily available (Atari was persnickety early on, but quickly got over it). You could buy official and easily understandable hardware manuals, including the complete source code for the operating system (all 10K of it). You could buy a spiral-bound paperback at Waldenbooks for $12 with the annotated source code for Atari DOS 2.0. The Atari 800 shipped with a sizable and easy-to-follow book about learning BASIC. The Commodore 64 came with a thick manual that listed the hardware registers and explained how to use sprites. Magazines commonly printed source code for complete games, both in BASIC and assembly language. Two or four pages of dense source were relatively easy to comprehend, with a little study.
The other reason is that everything was simpler. A programming language or assembler came on an 8K or 16K cartridge with a thin manual and was rarely updated; you could pick up a language and keep using the same version for five years. Graphical elements were usually monochrome or two or four colors. Displays could be created using redefined character sets, an entire screen only requiring 480 bytes--even a full bitmapped screen was only 8K. Sprites were supplied in hardware and could be moved by stuffing values in registers. Scrolling could be done in a similar way (you could do multi-directional scrolling on an Atari machine with only 2-5% of the CPU).
Such simplifications and small numbers led to other simplifications like being able to convert tilemaps by hand and not having to deal with external data files. Or by being able to choose colors by trial and error, because there were only 128 to select from (sixteen colors with eight brightness levels of each). If nothing else, you could keep a picture in your head of exactly where everything was and how it worked, avoiding the strange bugs that peer through multiple levels of complex tools and frameworks and operating systems that are common today. The end result was that you could focus on the game you were writing without too many distractions.
|Credits: Illustration © 1998 Mike Sanzone. The Rise and Fall of the Hobbyist Game Programmer is © 1998 James Hague. All other content is © 1998 loonyboi productions. Unauthorized reproduction is strictly prohibited, dangit.|