Hack Your Dunjonquest

My "map the Dunjonquest games" project was going fine until I hit level 8 of Hellfire Warrior. Not only does it feature some tricky "room connection" puzzles in the middle of the Great Plain, but it does not provide you with any room numbers. Even though I knew I'd still be able to solve the puzzle, it reduced my chances of ever being even remotely certain that the whole level was mapped. What would be the point of a half-assed job?

Well yeah, there'd be a point, but it would still be discouraging. So tonight I dove back into the Hellfire Warrior code -- which is very similar to the Temple of Apshai code -- and made a few changes.

Here are the things I've learned by poking around (literally). Some of them are generalizations based on Hellfire and Apshai that I haven't fully checked, so take them with a grain of salt.

The Files

"Temple of Apshai" contains the following files:

TEMPLE.PRG - The Innkeeper program
TEMPLE.DUN - The Dunjonmaster program
TEMPLE.PT1 to .PT7 - Files .PT3 to .PT6 are the data for levels 1-4, but the other .PT files are a mystery to me: character set data? Treasures? Traps? I haven't looked closely.

"Hellfire Warrior" is a bit more complicated, but the main files are:

INN - The Innkeeper program
DM - The Dunjonmaster program
HELLFIRE.5 to .8 - Levels 5 to 8.

There also appear to be different character sets for each level, and perhaps colour data for each level (since the levels ARE different colours).

The Code

The Innkeeper and Dunjonmaster programs are written in ATARI BASIC, with a few machine language routines that I think are for loading the custom character set and drawing the dungeon.

Here are some important things to remember when looking through the code.

• It's atrocious. Just sayin'.
  
• Variables that start with the letter U are really constants that represent numbers...U1 represents the number one, U10 represents ten, etc. This was a common way to conserve program memory, because the ATARI BASIC interpreter tokenized variables but treated every number as a separate piece of memory.
• The code is full of PEEKs and POKEs, because all character and level data is stored directly to memory addresses, not usually -- as you'd expect -- in variables. This allows the data to persist when the Innkeeper switches to the Dunjonmaster and vice-versa, but it's extremely difficult to untangle.
• Variable KA represents the memory address where the level data begins, and KB represents the address where the character data begins. In "Apshai," KA is page 103 (103*256) and KB is KA+2251.
• Much character data is also mirrored in variables, and the program swaps between the variables and memory occasionally, which might explain some wacky behaviour.
• Each level contains sixty (Q) rooms, but not all levels utilize every room. Judging by the file sizes (identical) I assume that the unused rooms are just full of padding.

Important Variables

• L: Character level (see below).
• O$: A string of all the commands that can be entered.
• MSTR: The line number for monster routines (7000).
• KF: The direction the character is facing (1 = up, 2 = right, 3 = down, 4 = left, I think).
• YA: The character's vertical position.
• XA: The character's horizontal position.
• TA: Fatigue.
• WC: Weight carried.
• PC: Wounds.
• PH: Maximum wounds.

Experience Points

One of the more mysterious aspects of both "Temple of Apshai" and "Hellfire Warrior" is how experience points are evaluated. You are told the number of points you have, and the "Book of Lore" says that you will benefit from a greater number of points, but it's difficult to figure out HOW.

Here's some insight. The programs DO check your "level" during combat, and characters with a higher level definitely get an edge in the calculations. Some stats also go up when you return to the Innkeeper with a higher level than you previous had (in a circuitous and bizarre chain of statements that I haven't bothered looking closely at).

How do you know when you've gone up a level? That would be nice to find out, wouldn't it? For some odd reason the programs never tell you, but the number of experience points you need to have for each level is 1000 times the square of the level number. So:

Level 1 = 2000
Level 2 = 4000
Level 3 = 9000
...
Level 20 = 400,000 etc.

The highest number of experience points you can get is 16,000,000.

Note that certain things in the game (like potions) can silently raise your stats, which might APPEAR to be a level bonus but isn't really. Also, "Hellfire Warrior" (at least the ATARI version) seems to have a bug where the Innkeeper gives you different numbers for your stats when you arrive from the ones you see when you return to the dungeon, and this discrepancy persists, as though the arrival stats are unmodified and the exit stats are modified by bonuses. Weird.

Important Line Numbers

• 5000: Parses input at each turn.
• 5100: Movement.
• 5300 and higher: Other actions.
• 7000: Monster stuff.

Unfortunately, many other routines -- various drawing and sound stuff, for instance -- is tucked away wherever it would fit. Lots of it is in the first hundred lines and is GOSUB'd to frequently. Presumably it's there because the earliest lines run fastest in ATARI BASIC.

Hacking the Program

It's easy enough to stop the program during operation (just press BREAK). To get back to the normal character set:

GRAPHICS 0

To reposition the coloured vertical bars (the remainder of the P/M graphics which represent you and a monster):

POKE 53248,0
POKE 53249,0

After you've made your changes, continue the program nicely with:

GOTO 5020

Make Mapping Easier

Here are some changes you can make to the "Hellfire Warrior" Dunjonmaster program to make mapping easier.

To force it to always print room numbers (which it skips for all levels numbered 6 and 8):

65 POSITION LS,U4:? "ROOM NO.:";

To always reveal a secret door when you (E)xamine a wall:

5701 IF PEEK(K+NT)=U3 THEN POKE K+NT,U2:RF(KF-U1)=U1:GOTO 5710

To always reveal traps when you (S)earch:

6300 IF PEEK(NP+KR)>U0 THEN GOSUB 670:GOSUB 679:GOTO MSTR

The last two might work in "Temple of Apshai" as well.

Jobs: WATFAC

In the summer of '90 I had an amazing opportunity that I mostly squandered: I spent a few months working at WATFAC, the Waterloo Foundation for the Advancement of Computing.

I got into this because my computer science teacher at the time (Savio Wong) recommended me for their yearly student work program, which required some level of aptitude for computer programming. Not knowing C I was at a bit of a disadvantage, but I WAS a little BASIC wiz and I had some experience with dBase III, which would turn out to be the big asset.

What they wanted us students to do was to learn how to use the new software they were developing: Application Creation Made Easy (ACME). It was -- for the time -- an amazing package that integrated with their WATCOM SQL engine and a specially built "Foundation" library, and was supposed to do exactly what it said: make it easy for companies to create applications, particularly the types that were front ends for data storage.

Basically, you built a database using WATCOM SQL, and then you went into ACME to add a user interface for it. This interface was -- strangely and perhaps fatally -- built in a spreadsheet, where each cel represented a page. It was up to you -- the application developer -- to place fields for displaying and entering data, and buttons that the user could press, and write the behind-the-scenes code that controlled the flow throughout the program.

The first thing *I* did with it was create an interactive adventure that allowed the player to explore the WATFAC building, because it was a very strange place to work. Formerly located on the corner of University and Phillip (where "The Marble Slab Creamery" is now), it was a refurbished bank, complete with a vault in the basement where we ate our lunch. The whole place was a rigged-up nightmare of tiny rooms and running cables.

In addition we were occasionally overseen by Wes Graham, patron saint of Waterloo computing, wonderful and just a tad eccentric. During his bizarre orientation speech he used an "onion" metaphor to describe the way layers of information are peeled back, but then he got frustrated when he realized that onions don't have the cores that his metaphor demanded. This lead to us lowly co-ops -- so often with free time on our hands -- creating a grand mythology: Wes didn't want to "advance computing," that was just a front for his REAL project: the sinister development of a peach/onion hybrid called "The Ponion."

All of the games, drawings, and stories we made were based around the Ponion mythology. This was better than what the co-op University students were doing: playing battlechess across the local area network. WE never got caught (because our fun and games were created with company tools and looked like work) but when THEY got caught there was absolute hell to pay (and a memorable lecture to the whole group about teamwork and work ethic).

My problem was that I'd been placed in the only large room in WATFAC, a conference area that I called "the circus." This room hosted about twenty computers and was where all the nerdiest computer students were...and me. These guys were hardcore, they smelled a bit, they had loud voices and yawking laughs; the archetypal computer nerds. Since I was several years younger and I DID NOT KNOW C, there were frequent attempts to denigrate me, and equally frequent attempts by me to explain to them that they should try to straighten out their hygiene and their social problems, and never any work getting done because they were all yelling about the jokes in the latest Math newsletter.

Anyway, our REAL purpose at the company was twofold: to be beta testers for the ACME software, and to write full-fledged applications using it that could be demonstrated to local companies like Bell Telephone and the Waterloo Public Library. We were each randomly assigned an application that a company had shown interest in, and unfortunately I got the one I was least passionate about: a tracking program for expense accounts, under the watchful eyes of a local insurance company. It also had the worst name of them all; while others got names such as "InfoBook" and "InfoList," mine was "InfoExp." Difficult to say, even more difficult to enjoy doing.

What I remember most about this process was the attention given to the user experience, particularly in relation to hotkeys. There were few standardized hotkeys back then -- F1 for help was the only function key that had any real meaning across programs -- and the management quickly saw the necessity of standardization. So everybody brainstormed and came up with hard-and-fast rules for what each function key would do in every "Info" program, and we stuck to it.

Another thing I remember about the user experience was trying to organize data onscreen in a way that was friendly AND informative. While the other kids in "the circus" were outperforming each other trying to hack the ACME boot program with C in order to add esoteric and impossible-to-maintain features, I introduced my one innovation: ASCII graphics to create boxes around lists and to separate data from instruction. Simple and effective, but nobody had thought of it before. Within days everybody had a sheet of ASCII codes at their desks.

At the end of it all we had to give presentations of our programs to the companies themselves. I think I've blocked my presentation from memory -- not bad, but not great either -- but I DO remember the presentation that Mike gave.

Mike was the most obnoxious co-op there -- every day he'd make an endless string of bad computer jokes, along the lines of "Database engine won't start? Pour some gas in it! Hyuk hyuk hyuk! Right into the floppy drive! Hyuk hyuk!" -- and his application was for book filing and reference. He used to brag about how fantastic his presentation would be, and when he stood up there in front of the Waterloo Public Library board I saw an obnoxious, pushy braggart become a confused and stuttering fool. Plus all the books in his sample database were by Gary Gygax. Fail.

Eventually the job was over. I got a nice paycheck, a nice evaluation, and a nice reference, plus a free copy of ACME that I used as supplementary income (by creating a locker assignment application for our highschool).

What I remember most, however, is something I haven't even touched on: it was the first time I lived away from home. The parents of my friend Jeff -- who was also in the program -- owned student housing in the university ghetto, and they allowed Jeff and I to stay in an empty house while they renovated it. I remember many evenings mowing the lawn and painting the railings.

Looking back, it seems to me that I enjoyed this "moving out" experiment very much. My parents would drop in occasionally, and I spent some time wandering around the city and hanging out with Waterloo friends. This was when some women had been sexually attacked on the university campus, and I remember little groups of calm vigilantes wandering around campus and checking student IDs.

I also remember the first time I learned not to leave a kettle boiling when you leave for work. I remember playing Dragon Spirit obsessively at Flynn's arcade during lunch hour -- just to escape the airless, windowless lunch-vault -- and also that my Kate Bush obsession had reached its peak: my paychecks were going to vinyl bootlegs from Encore Records, and I picked up my first Peter Gabriel album (III) when I learned that Bush had done vocals for it. My mind was blown.

Now WATFAC is gone, and WATCOM is only really remembered for their compiler (though children of The ICON will remember WATCOM BASIC). Looking back, I think that ACME failed because it was released around the same time as Visual BASIC, and while ACME was more powerful it was also much harder to use. I'd love to see the program again someday.

And Wes Graham? When I went to the University of Waterloo many years later I was thrilled to see him as a "special guest" in a FASS show, playing a janitor. Everybody cheered. Now there is a road named after him.

Bless you, Wes, and your elusive Ponion.

BARTH

Last year at this time I subjected myself to a gruelling "Barthathon," an attempt to read every John Barth book in chronological order. Read the posts if you want to know how THAT turned out.

I can't see myself ever reading another book by Barth, but I DID run across an interesting thing in "The Best of Creative Computing," published in 1976.

Anybody who grew up during the beginning of the 8-bit personal computer glut will remember those awful BASIC programs that tried to be INTERACTIVE. Written at a time when average people were still getting used to the idea of computers in general, a program that would ask you your name and then play "Guess My Number" seemed like magic...

...until you learned a bit of BASIC and saw that it was just smoke and mirrors. Those programs were intended for absolute beginners who had no idea about how computers worked, and I imagine even those beginners got sick of the concept pretty quickly (though "ELIZA" and "Animal" were special).

In the quest to make computers friendly, programmers in the '70s often tried to make them seem creative, at the same time tossing an educational bone to keep their programs from getting deleted off the mainframe. Larry Press' article "Computers in the English Curriculum" absolutely reeks of this stuff.

Page two of the article shows the output of a program called "BARTH," meant to emulate some of Barth's interactive-reader experiments from the '70s. It's much the same as all the other programs of its type -- enter verbs, nouns, and adjectives, which are embedded into print statements to create a nonsense story -- but DOES have the distinction of being perhaps the only John Barth video game ever created.

Incidentally, Margaret Chisman's "Producing Computer Poetry" is another example of creative-educational computer blah, notable most for how far we've come in our concept of computing (and how quickly we lost our naivete). My favourite article in that issue of Creative Computing, however, is one by Wes Thomas, in which he becomes extremely annoyed by precocious children at a computer fair.

This is SO bizarre:

I Am Here in Oolite

No, I haven't mysteriously vanished. I'm afraid that my mind has been grabbed by the iron fist of Oolite, and for the moment I can't escape.

I've always been fascinated by space travel in its most mundane sense: getting from here to there. I just can't grasp the distances between planets, let alone solar systems, let alone GALAXIES. It amazes me that it's all unexplored, in the way that people must have been amazed by (and attracted to) "darkest Africa" and the poles, before we found out it was all pretty much normal, just harder to get to.

So give me a game where I can explore a "universe," and I'm happy. Make it a game where the travel is mind-numbingly dull -- watching your destination approach over half an hour while your fellow ships travel around you -- and I'm THRILLED. Give me the ability to ADD to the universe with custom MODs, and I widow my blog (and my cat) so I can study the modding language and create mysterious ghost ships and space-age Voyageurs.

As if this wasn't enough, Oolite's universe is also procedurally generated, a process that has obsessed my slightly-autistic mind since I was a child, watching computer-landscapes blossom from the union of a number seed and an algorithm. You needed to think about these things when you had only 64K to play with.

Once I've explored its boundaries and gotten frustrated by the scripting languages, I'll probably put aside Oolite and never play it again. I already can't believe that I'm willing to sit for ages watching a planet get slightly bigger, while my cat cries "love me!" from the floor. But sometimes I get hooked on these things, and since this weekend was a scheduled "no-bar" interval this is the perfect time to indulge myself.

So I'm sorry that the blog hasn't been updated. I'll make it up to you soon with ANOTHER new obsession, which is a surprise and infinitely more social.

The Wumpus 2000 Blip

Many of the little projects I work on end up disappearing without a trace. They're sort of like elaborate paper boats that I spend years playing with, and then I launch them down the stream, and that's it. The only person who cares about the boat ends up being me.

I get particularly gratified when somebody finds one of my boat projects to be useful. This doesn't happen often...but it DID happen this month.

Someday I'll write a series of posts about the web stats for my site, but for now I'll say that I noticed a huge uptick in downloads of my Wumpus 2000 game. I finished the game in 2004 and released it to the world, but other than a few baffled comments and a sort of ambiguous review in SPAG #41, the game disappeared without a trace. The only people liable to notice it -- fans of Interactive Fiction -- were bound to be turned off by its compulsive, repetative, largely plotless nature. Wumpus 2000 was an unapologetic "cave crawl," and cave crawls aren't considered the cream of the IF-crop...especially not the sort that I made.

But now, three years later, Wumpus 2000 has made an online blip. Somehow Anna at Dessgeega Blog picked up the game and wrote a complimentary review about it, and I think she summed up its potential appeal:

wumpus 2000 - too vast and random for memorization - asks the player to devote that bit of attention and labor - in this age of flash games designed to be played and forgotten during a lunch break - and to reclaim the rewards of mapping a virtual world by hand: the written record of a game and the ownership of an experience.

As somebody who loves MAPPING games even more than I enjoy PLAYING them, I can't help but agree. I was particularly thrilled to see a smidgeon of a Wumpus 2000 map drawn IN SOMEBODY ELSE'S HANDWRITING! Not to mention the subsequent comments from people who have actually played (and even finished) the game.

Simonc over at GameSetWatch picked up on the Dessgeega post and actually said:

[Wumpus 2000] I suspect is the kind of experimental text adventure which can influence wider game design concepts from its odd niche.

I LOVE my odd niches! And apparently Wumpus 2000 is "old skool," like, even older skool than its two close companions -- Roguelikes and IF -- because of the complex, randomly-generated map and total lack of graphics or cardinal directions.

Picking up from the Dessgeega and GameSetWatch posts, Maggie Green of Kotaku wrote "Back to the (Hand Drawn) Future? (With Wumpus 2000)," and this post got splashed all over the place on RSS feeds. She expressed what the average player probably thought: "Cartography not being my thing, I can only envision hours of frustrating game play." Somewhere around there, Vash posted an ENTIRE transcript of a Wumpus 2000 game (click here and type "prev" if you're feeling brave), and it looks like he found the game almost as annoying as I find his blog navigation system.

So here's hoping that Wumpus 2000 DOES find its niche. I don't have hopes for a new genre of W2K clones, but I suppose stranger things have happened! I mean jeez, people still collect ASCII sigs, for goodness sake.

alloc! init!

For the third time now I am tackling Aaron Hillegass' "Cocoa Programming for Mac OS X." I've finally reached the farthest point that I'd reached previously ("Bindings and NSController"), but this time I actually understand what's going on. Mostly.

I'm realizing something that I think the book glosses over: the AppKit framework -- the classes you use to communicate with the OS X GUI -- is quirky. Understanding what you're doing involves knowing all of the bizarre ways your code needs to interact with AppKit. For the methods in any particular class you have to know what it returns, what it retains, what happens if you send it nil...and you also need to know which methods it delegates to other objects...

I'm sure that for common classes this becomes second nature. But when I see inconsistencies in Hillegass' code, and he doesn't explain why they're there, a bit of research reveals that it's due to a class quirk...a quirk I wouldn't have known about if *I* were writing the code.

I was in a rage tonight, trying to figure out why he allocates memory for and initializes SOME objects, but not others. I think it's because some of these objects -- the ones you use often for temporary reasons, like NSString -- can allocate and initialize for themselves, since they're immutable and they'll be autoreleased as soon as the method ends anyway.

Speaking of releasing, I'm not even thinking about that yet. The knowledge that (as Hillegass basically says) some methods retain objects and some don't, and you just need to learn which does which, is not exactly heartening.

But I do have to say: wow, this is elegant. The way that all these objects lock together, sharing their duties in such a logical way, is a miracle of design. I love it!

Until I get stuck again...

Objective-C and Letting Go

While suffering insomnia last night I realized something strange about my personality: I'm afraid to physically "consider and experiment." At some point in my life I lost the joy of playing in sandboxes. So now, whenever something needs to be done and I don't know how to do it, I'm afraid of fiddling with it until I figure out how to "fix it."

Oh, I'll RESEARCH it, or I'll lie in bed worrying about it and trying to find an answer, but when it comes to actually sitting down and physically interacting with it: no way.

I only realize this now because I'm starting to get over it. I first noticed a change when I moved into my new apartment: so many things needed fixing that -- somehow -- I found it in myself to actually stand around and figure out how to fix them. The gross bathtub, the screen doors, the furnace, the wonky lighting fixtures...and then my new cosmetic foundation, and now learning to program in Objective-C: in all of these cases I've just sat down and started messing around until I've figured it all out.

I realized this last night while taking advantage of my sleeplessness to continue learning Objective-C. I've tried to learn the language three times in the past, and every time I've simply stopped when I no longer understood what was going on.

But this time I'm doing something that I realize is unlike myself: I'm taking my existing knowledge and saying "what happens if I do THIS?" then just trying it out to see what happens. In the past just THINKING about this sort of experiment would have made me unreasonably (and somewhat subconsciously) anxious: I'd have insisted on following the book, and the only time would have "struck out" on my own was when I had some serious result in mind...and if the result failed, I would have given up on it all out of a sense of failure and embarassment.

So what's changed? I think the greater responsibilities in my new job, and my need to learn a new skill and set of applications as I go has something to do with it. Feeling proud of my apartment and wanting to "fix it" is another reason. In any case, this is a good thing because I've just gotten a new (and girlier) haircut that will require experimentation to get right. Just in time!

And why was I so afraid to "physically experiment" in the past? Beats me. Maybe I got an electrical shock from a Fischer Price toy while in the crib.

Development Development

When I got my first REAL computer -- an Atari 400 -- I certainly enjoyed the games, but what I REALLY wanted to do was learn how to program. I've never tried putting into words WHY programming/developing appeals to me, but today I ran across this quote:

If you can program your computer, here is a tiny universe in which you can be God. Within the realms of expression that the computer can provide, you can build a world, define its laws, and watch the universe unfold. As your whim dictates, you can intervene at any time, and if you desire, the history of the universe can be changed and rewritten at will. Such a power this is!

That sums it up perfectly, and since it was written by Gregory Yob -- most famous for "Hunt the Wumpus," a game concept which fascinated me enough to create a mammoth new version of it -- it resonates deeply for me.

Anyway, I started with Atari BASIC. I dabbled a bit with Assembly but I was too young and I didn't have the patience. In highschool I was weaned on to structured programming with WATCOM BASIC, and even though I excelled at programming my total lack of math aptitude scared me away from a Computer Science major...though I did take an entry-level course at University (where I learned and then forgot TURING), and another entry-level college course in C.

Meanwhile I'd been hacking away at Inform, which introduced me to object-oriented programming. Since Inform was designed for writing "Interactive Fiction," the object-oriented approach made perfect sense: all the elements of the "world" are objects, which the "player object" can pick up, carry around, interact with, put inside other objects, etc. But even though I grew accustomed to classes, methods, and instance variables, I was never prepared for the next step:

Objective-C, the language of choice (apparently) for Mac OS X developers. My Mac came with a full development suite and reams of documentation, so why not learn this new language? I'd already done object-oriented programming with Inform and I knew a bit about pointers from that course in C, so I figured it would be a breeze.

But it hasn't been. I have trouble conceptualizing pointers, particularly as they relate to the huge library of classes that come with OS X. Never before have I had to retain and destroy objects. And, most importantly, it's clear that while I understand the "how" of object-oriented programming, I've never grasped the "why" of object-oriented DESIGN.

So I went online to find a book specifically about design. I figured there'd be THOUSANDS. It turns out there are enough to give me a selection to choose from, but they're all specific to particular languages I'm not using, or -- and here's the catch -- they're textbooks, and therefore ridiculously expensive.

I finally settled on "Applying UML and Patterns" by Craig Larman, but I'd never pay $75 for it, particularly since I know the high price isn't due to the content so much as an attempt at making a profit above the number of copies sold at campus bookstores every year. Why should I suffer for that? I KEPT my textbooks (at least the good ones). So I turned to ebay.

And that's where the weirdness started. There are a LOT of copies of this book for sale on ebay, and most of them are 1/10th the price...but they come from China. Which made me suspicious, especially when I saw inconsistent page counts and comments like "all illustrations in black and white" and "we promise all important text is in English." Coupled with lots of negative buyer comments and long shipping times, I decided this all sounded too creepy; there must be some sort of bootleg textbook thing happening in China.

The sellers on abebooks look more reputable; they're from Japan, and they're selling "International Editions" that are somewhat more expensive. They say they contain "the same text as the American version" but they're also 200 pages shorter. Hmmm?

Finally I realized that there were a few ebay stores selling an OLDER (and shorter) edition of the textbook, so I finally bit the bullet and bought one. But I still wonder: what's with the Chinese textbooks? Also, why can't somebody write a generic book on this subject that doesn't cost $75? And how on earth can I conceptualize a program where even the NUMBERS are objects? Gah!