| By Paul Panks |
||
| December 28, 2005 08:00 AM EST | Reads: |
16,066 |
I often wonder what happens to data when it gets erased. Just where does it go? What happens to it? Does it "vanish" completely, or does it still exist somewhere, perhaps in the memory bank of the expanding universe?
My theory is this: everything that is erased has been recorded by time
and, given enough technology to go backwards, we should be able to
recover lost data (if we are able to travel backwards to the point
before it was "permanently" erased, that is).
Quantum Mechanics Meet "Panks Mechanics"
Most of
the data I have lost over the years resulted from poor handling of
disks, hard drives, and outright stupidity. But one program, which is
still dear to my heart, continues to haunt my own memory banks. I call
such foibles "vanishing bits."
Some 10 years ago I created a fairly complex text adventure (one of my first large programs) on the Commodore 128 computer. I named it "WESTFRONT TO APSE." Much of this game has been lost to the ravages of time, but from what I do recall it was a most remarkable game. I was only able to recover a (much) earlier version of the game and recoded it from memory. Perhaps 50% of it ended up being "as it was." Perhaps not. But I still long for that original game, which was erased due to my use of the Save-With-Replace command in Commodore 2.6 DOS (common on the Commodore 1541 disk drive).
There are many stories behind the development of this game. First, there were the countless hours spent reading TSR Hobbies "Advanced Dungeons & Dragons Beginner Module 1" and the companion "Player's Handbook." Without these two books, Westfront would probably never have existed.
Second, there were ideas from popular myth and culture incorporated into the game play. I also attribute Westfront's existence to playing Magnetic Scrolls "The Pawn" during the Commodore's heyday. That game served as the basis for both the layout and structure of my humble text adventure.
Next, there were the self-beta testing sessions, mostly spent in frustration with squashing bug after bug after bug! This would consist of pressing the RUN/STOP and RESTORE keys repeatedly throughout a programming sessions. Eventually the keys wore down and I had to get my Commodore 128 repaired. Ugh!
Finally, I remember the humorous look on my cousin's face when he played the game for the first time:
Ryan: "Why can't I examine anything?"
Paul: "Oh, you just examine _objects_ in the game..."
Ryan: "Oh, okay...hey, what's the wine for?"
Paul: "You drink it"
Ryan: (drinks wine) "Okay, I'm now in Smurf Village. How the heck did _that_ happen?"
Paul: "Keep playing, it gets better..."
Another individual whom beta-tested my game was my other
cousin, Tim McLaughlin. He had a fun time exploiting the bugs in the
game to his advantage:
Tim: (issues a GO NORTH command) "Okay, I just moved north."
Paul: "You can use abbreviations, you know."
Tim: "Really? Coooollll."
Paul: "Try typing: GO NO instead of GO NORTH."
Tim: "Okay. Oh, neat! I like that feature! Can I pick up the tree?"
Paul: "No."
Tim: (issues a GET TREE command in the forest) "It says 'OK.'"
Paul: "Huh? Check your inventory."
Tim: (INVENTORY command reveals that he now has the TWO-HANDED SWORD) "What the heck?"
Paul: "Wait a minute!"
The development of the game progressed from a simple two-word parser (courtesy of an issue of COMPUTE!'s Gazette) to the remodeling from the initial C64 version and finally into the form described at the beginning of this article. In time, I managed to play a MUD online via telnet, and I then modeled the Village Shop after it (or at least I tried). This proved unremarkable, as there were several bugs in the Shop routine of the game.
I also discovered that the WIELD command tacked on a "(wielded)." Text string to the end of any item that the player attempted to wield. This led to a most frustrating error:
inventory
You are carrying:
BACKPACK.
LANTERN.
TWO-HANDED SWORD (wielded).(wielded).
Despite the bugs in the game, Westfront had some redeeming play value in that it taught the end user patience. Sorely lacking in the game was thorough or even partially complete instructions. There was a nice introduction, to be sure, but the HELP command during game play displayed six terrible suggestions, among them:
Needless to say, both Ryan and Tim scoffed at the HELP command's usefulness!
Most of the game took place in three cities across Norway: Oslo, Trondheim, and Stavanger. I also added Bergen and Flora Island later on during the development of the game (which, from memory, took at least eight months). The game even included a sprite title ("WESTFRONT") and function key controls for the most common commands: GO NORTH, GO SOUTH, GO EAST, GO WEST, INVENTORY, MAP, SAVE, and HELP.
The MAP command displayed a three-dimensional view of the landscape, which included a holographic-like map display of the area's topography (including the relative height of the surrounding mountains in comparison to the main land).
The eventual program, WESTFRONT TO APSE, occupied exactly 206 blocks on disk. This was equivalent to 51.5 kilobytes of raw data (not including the associate equates stores in the sequential data file WESTDATA [74 blocks long]). All in all, the game occupied over 80 rooms while boasting some 80 objects and monsters. For a game written in BASIC, it was quite advanced. However, 10 years after I completed the game, I have since written well over 30 adventures in languages ranging from BASIC to HLA (High Level Assembly).
Although I managed to re-create much of it (thanks in no small part to programs such as "The Disk Doctor 4.0" and the Epyx Fast Load cartridge), I still believe (somewhere) that the original program exists "out there" in the expanded universe. Like all programs or memories, I believe everything we do is stored in a universal memory bank accessible only by traveling to points relative to the original events in time. Perhaps, as those who have undergone a Near-Death Experience (NDE), such recordings are still available to us. Or perhaps not.
It all depends on the universal condition we all share: being human. For if we can recover programs by simply re-creating the conditions that led up to their existence, we can also recover lost parts of ourselves as well. We all have "vanishing bits" that haunt us, whether they are programs or memories. We just need to find them again, to know why they haunt us still.