A Game Dev’s Story, Part IV: Sixty-Four

Posted by Rampant Coyote on February 17, 2012

When released, the Commodore 64 was quite simply mass-produced awesomeness. We didn’t really know it at the time… it was just another “home computer” released in a sea of competitors. It came from a company that had specialized in business systems (the name was “Commodore Business Machines,”), with one weak home computer entry (the VIC-20, for which William “Captain Kirk” Shatner was the spokesperson). However, they did “get” the key to the home computer market: It had to kick butt at playing games, but masquerade as a “serious” machine to justify its purchase price.

I’ll probably talk more about the “C-64” in a few months when it’s 30th anniversary of release really swings around. But in September 1982, when I finally received one of the first machines, it was incredible. Sixty-four kilobytes of RAM… although only about 50K was actually addressable using BASIC. Still – that was fifty times what I was used to. Sixteen colors. Sprites with hardware collision detection. A really decent version of BASIC. Full-screen editing. An incredibly powerful sound chip – the SID chip – that could give the Atari sound chip a run for it’s money.  Atari-style joystick ports. Cartridge ports. An RS-232 interface port. The only significant downside to the entire system was an incredibly slow disk drive, the 1541. But for me, it was a dream machine.

Upon release, software for the C-64 was in short supply. This wasn’t a situation destined to last very long. But since I didn’t have much money to buy games anyway – and nobody I knew yet had a C-64 either – I was left to my own devices to get some entertainment value out of the machine. And with 64K, a decent implementation of BASIC, a beefy machine, and a couple of books filled with Creative Computing’s game listings, I was pretty much set.

I typed in Wumpus I and Wumpus II. Star Trek. Hockey.  Sea Battle. Checkers. Nomad. And a half-dozen little games played on a grid (whether displayed or described in text coordinates). I debugged the games when I learned I’d typed them in wrong. I tweaked them. And I wrote my own. Either way, I learned.

Between Wumpus and Nomad, I figured out how to create data structures for nodes representing locations.  This was key in me figuring out how to do an adventure game. Rather than having every “room” be a section of code that called a parser subroutines, I could have most of the game data-driven with a generic system. Bingo! I was learning. And one night, I put it all together in a little adventure-esque game. Well, not even a game, so much as a game space. It was simply a dungeon of about a dozen rooms. But it had a very basic parser, the “dungeon” was fully data driven, and it had potential. And the whole thing came together at once. I remember the music that was playing on the radio (volume turned down low) at the time when it all worked… it was a Saga’s “Wind Him Up.” Like “Queen of Hearts” was linked to playing Asteroids and Pac-Man, that song has ever since been linked to that feeling of victory when making games for me.

That opened up the flood gates for me, conceptually. Not just for adventure games, but for all kinds of games. Remember, I was still entirely self-taught, and had only been working in a very limited programming environment before. Now I was finally understanding how programming in general was supposed to work – the ideas of separating code and data, keeping code very reusable (and maintainable), and so forth. I was still working with BASIC, so GOTO and GOSUB commands remained the order of the day on the spaghetti-code menu. But at this point, I was able to start doing some pretty complicated games.

My only two “finished” adventure games were ones I entitled, “Dungeons of Doom” (yeah, yeah, I know) and “The Secret of Red Hill Pass.”  Dungeons of Doom was the first, and in retrospect was pretty horrible. It had limited character-based graphics to illustrate objects in certain rooms, plus a few sound effects and other special effects (like ugly, flashing color backgrounds).  The parser was limited, and I think I only allowed the player three inventory items at a time.  The puzzles were primarily figuring out what item defeated what monster. The spear was for the minotaur, the muzzle was for the dragon, etc. The trick was the hand grenade, which was able to destroy every monster in the dungeon, but one of the monsters was invulnerable to everything but the hand grenade. So if you used the hand grenade against anything else, you could never win the game. I kept score, so it was possible to earn a higher score rather than “complete” the game, but it was a pretty atrocious design. I hope I’ve learned a thing or two since then.

Dungeons of Doom consisted of about 26 rooms, in total. The Secret of Red Hill Pass was, as I recall, almost ninety rooms. It could best be described as “Zork Lite.” I totally cribbed from Colossal Cave and Zork on that game, though it still had plenty of original ideas as well. The game took place in an abandoned manor (and the dungeon beneath it) along the titular pass. I don’t think there really was a “secret” to Red Hill Pass other than the adventure-filled manor. But the parser was pretty good – not quite up to Zork standards, but superior to some of the other popular text adventures of the time.

One project I undertook (mirrored by hundreds if not thousands of other D&D fans with programming know-how) took the random dungeon generator from the back of the Dungeon Master’s Guide, plus random monster tables, plus some custom object interaction code, and created a giant random-dungeon generator. The whole thing would print out with room and event numbers over literally hundreds of sheets of tractor-fed dot-matrix printing.  The rooms had simple descriptions, monster encounters which you could run solo, and actions which you could take, choose-your-own adventure style, leading you to a new room or event number you could then look up on the sheets. Due to the cost of printer paper, I only made about three full-sized dungeons this way, but it was actually possible for me to kinda-sorta play through a solo D&D game this way. Yeah, not as cool as a fully playable RPG on a computer, but it worked. And it was a fun – and educational – exercise.

I also made dozens of unfinished games.  I had a 3D perspective party-based RPG that was playable enough that friends came over and played the thing. I guess you could say this one was marginally “finished” in that it was playable, but I really just stopped working on it after a while. I had dozens of game clones I’d written that rarely got past the point of being tech demos. I had early attempts at cloning and re-imagining favorite arcade games of the era. My Missile Command-inspired game had flying saucers that were flitting around launching bombs at various angles, for example.

I eventually had the chance to play many of the games I had jealously read about. While this is generally a good thing – certainly a great inspiration for me – it was a lot easier to play games instead of writing them. This remains the case today. Some days, writing games is a lot more fun than playing them. Other days… not so much.

Pretty soon, I did run into some of the limitations of the C-64. Speed, memory, etc. And I actually kinda-sorta had a software business at the time. More on that in the next installment.

Filed Under: A Game Dev's Story, Game Development, Retro - Comments: Read the First Comment



top