+++++++++++++++++++++++++++++++++++++++++++++
                Tales from the Code Front -
         Special Delivery: 5,000 Mailboxes in TADS
                      by Neil deMause
       +++++++++++++++++++++++++++++++++++++++++++++
            Originally printed in XYZZY Magazine

Always, it came back to the mailboxes.

I am not a computer programmer. Before I decided to learn TADS and
finally program the text adventure game I had been mulling over
for years ("MacWesleyan"), my last programming experience had
been in BASIC, on my Tandy Color Computer (with 16K RAM upgrade!)
that disappeared into my parents' closet somewhere in the early
1980s.

Still, I was doing okay - TADS is a very logical system, and
helpfully spits back yards of error messages at you to let you
know what you're doing wrong - until I got to the mailboxes.

Here's the scenario: A post office in a campus student center. In
the post office, a wall covered in mailboxes (5,000 of them, to be
exact).  Only one of them is yours; the rest are just there are
window dressing, and to thoroughly befuddle you until you discover
how to find out your mailbox number. All I needed, then, so far as
the programming was concerned, was to make two mailboxes, one
yours and one not (which would stand in for all the other
mailboxes) - or maybe even just one mailbox, which wouldn't let
you open it unless you gave it the right number. But how to make
an object that would respond to any sentence of the form "VERB
mailbox NUMBER"; this was my dilemma.

At the suggestion of the editor of this fine journal, I took my
dilemma to the denizens of the rec.arts.int-fiction newsgroup.
Surely, these programming experts would have come up with code for
something as simple as a bunch of mailboxes?

My first response, from a well-known TADS programmer, mounted to a
list of ways *not* to do it: make "mailbox" an article (which he
called "pretty evil"), make "mailbox" an adjective of the object
NumObj ("this seems dangerous"). Ultimately, he said I should try
to use TADS' Preparse function, a fabulously powerful tool that is
as incomprehensible to me as Linear B.

My next message came in the form of an e-mail missive from someone
in Finland whose name appeared to be entirely made up of random
numbers and letters. (I've heard that this is common among
European Net accounts. It must be just one of those Continental
things that we Americans can't understand, like national health
care.) Though this person was undoubtedly well-meaning, his (her?)
suggestions were complicated by the fact that his English syntax
was about as good as my TADS code - a nice try, but ultimately
just leaving me scratching my head and blurting out error
messages.

Finally, to my rescue rode none other than MJR - Michael J.
Roberts, the always-helpful creator of TADS. The obvious solution,
he said, was to add an entirely new class of object,
numberedObject, that would do what I wanted. Unfortunately, that

would require rewriting the parser to handle the new syntax; he'd
get back to me when it was ready.

Meanwhile, I had hungry beta-testers who couldn't care less about
the nuances of TADS code - they wanted their mailboxes, and they
wanted them now! I tried various workarounds, including the
suggestions that the famous game designer had said were bad ideas.
(He was right. They were.) Finally, I simply diverted all action
from NumObj while in the Post Office to the mailboxes: now if you
typed "OPEN 2000," it would try to open the mailbox with a "value"
of 2000, and would only succeed if it was your mailbox, and so
openable. For those players who insisted on typing a more sensible
sentence like "OPEN MAILBOX 2000," I programmed in a special error
message telling them how to phrase their request so that my bad
programming could make sense of it.

This worked - most of the time. About one time out of ten TADS
refused to recognize even properly phrased sentences. I began
warning my beta-testers that the mailboxes were a "work in
progress."

Another week, and another message from MJR. The new parser was
ready, and new code for numberedObject. This employed a trick: you
could have only one object (in my case, one mailbox), and TADS
would make a *copy* of the object, with a value set to the number
that was input. This way, a minimum amount of coding could result
in a different response depending on what mailbox you specified.
This could be it! I got it downloaded, changed the coding...

And it crashed. Over and over again.

Back to MJR for *another* new version of the parser. Fingers
crossed, I ran the compiler, and started up my game. Cautiously I
entered the post office.

> UNLOCK MAILBOX 2000

It unlocked.

>OPEN MAILBOX 2000

It opened. There, inside, was the postcard I had placed there!  My
long quest had ended! I happily open and shut the mailbox, removed
the postcard and put in back inside.

Where, as Ensign Chekov would say, "it wanished." Gone, without a
trace. The subroutine that deleted the duplicate mailbox at the
end of the command sequence had efficiently taken my postcard with
it, and there was no getting it back.

As XYZZYnews went to press, I was still waiting for an answer from
MJR on this latest problem. I'm sure he'll have one - he's a smart
guy.  Meanwhile, my mailboxes sit there, happily gobbling up
anything a hapless adventurer chooses to insert into their gaping
maws.

Sometimes I wish my parents had never bought me that Tandy in the
first place.


Ed. note: I'm happy to report that MJR came through in the clutch,
the mailboxes now work as planned, and Neil now has only fond
memories of his Tandy.
















                              - o -