The Rise and Fall of the Hobbyist Game Programmer By James Hague Jump to an Archived Issue! 2.15: Livin' With The Sims 2.14: To the Extreme 2.13: Not Just a Passing Wind 2.12: It's Not Easy Being Green 2.11: Inside Origin Systems 2.10: Game Networking 101 2.9: Tell me a Story 2.8: Anatomy of a Video Game 2.7: 1999 loonygames Awards 2.6: PC Fight Club 2.5: Paul Steed '99 2.4: Sounds From All Over 2.3: Kicking Back with a Bear 2.2: End of the Line 2.1: American McGee's Alice ----- Volume 1 ----- 1.41: Put a Little Love... 1.40: Game Programming... 1.39: More loonygames @ E3! 1.38: loonygames at E3! 1.37: The ReRuns Issue 1.36: Inside Raven Software 1.35: Waking Graeme Devine 1.34: Writing the Game 1.33: Totally Tribal 1.32: Under His Skin 1.31: The Glory of G.O.D. 1.30: Chillin' w/Jason Hall 1.29: Extreme Annihilation 1.28: Adventures in ASCII 1.27: Serious Brass Ones 1.26: Two Programs... 1.25: The Unreal Cliffy B! 1.24: Gimme Your Money! 1.23: Old Crusty Gamers 1.22: Bugs! 1.21: 2001 1.20: Can't Please Everyone 1.19: The Rise and Fall... 1.18: romuluSngan HoH! 1.17: A Very Geeky Christmas 1.16: 5 Years of Doom! 1.15: Tune Up Your Game! 1.14: NT + Games = ??? 1.13: Blue and Levelord... 1.12: When It's Done! 1.11: Hangin' With John Romero! 1.10: Still Sick of Games 1.9: Gettin' Odd with the loonies 1.8: LAN Parties... 1.7: The Community Summit 1.6: DRAW Pardner! 1.5: Taking Aim at Paul Steed 1.4: Play Where You Like! 1.3: *Special Duke Issue* 1.2: Are You Sick of Games? 1.1: Chris Taylor Gets Some! 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. (continued on next page)