RSS

TADS

03 Feb

For text-adventure fans confronting the emerging reality of a post-Infocom world, AGT was a godsend, allowing amateurs for the first time to create games that at a quick glance might appear to match those of Infocom. Still, AGT was far from the answer to every prayer, for the fact remained that it would have to be a very quick glance indeed. David Malmberg, the developer of AGT, was ingenious and motivated, but he was also a self-taught programmer with little background in the complexities of programming languages and compiler design. He had built AGT by adding to Mark Welch’s profoundly limited GAGS system for creating generic database-driven text adventures a scripting language that ignored pretty much all of the precepts of good language design. What he had ended up with was almost a sort of technological folk art, clever and creative and practical in its way, but rather horrifying to anyone with a deeper grounding in computing theory. The best argument in favor of AGT was that it worked — basically. While the system was undoubtedly more capable than anything that had been available to hobbyists before, it still didn’t take much poking at an AGT game before the rickety edifice’s seams began to show.  A number of authors would push the system to unforeseen heights, in the process creating a number of classic games, but it was obvious that AGT could never work quite well enough to create games as polished as those of Infocom. To do that, a language would be needed that was truly designed rather than improvised. Enter Michael J. Roberts with his Text Adventure Development System, or TADS.

Roberts had first started programming on his school’s DEC PDP-11 system in the 1970s at the age of 12, and thereafter had ridden the first wave of the PC revolution. In those early days, text adventures were among the most popular games there were. Like so many of his peers, Roberts studied the BASIC listings published in books and magazines carefully, and soon started trying to write adventures of his own. And like so many of those among his peers who became really serious about the business, he soon realized that each game he wrote was similar enough to each other game that it made little sense to continually reinvent the wheel by writing every one from scratch. Roberts:

It occurred to me that lots of the code could be generalized to any adventure game. So, I tried to write a little library of common functions — the functions operated on a set of data files that specified the vocabulary words, room descriptions, and so on.

This was a nice approach in some ways; the idea was that the game would be described entirely with these data files. The problem that I kept running into was that I’d have to write special-purpose functions for certain rooms, or certain commands — you couldn’t write an entire game with just the data files, because you always had to customize the library functions for each game. What I really wanted was a way to put programming commands into the data files themselves, so I didn’t have to modify the library routines.

Once you start putting procedural code into data files, you essentially have a programming language. At first, I tried to avoid the work of writing a real language interpreter by making the language very limited and easy to parse. That was better than just the data files, but it was tedious to write programs in a limited language. I eventually saw that you really needed a good language that was easy to use to be able to write decent games.

Roberts, in other words, was discovering for himself the limitations and inelegancies that were inherent to a system like AGT — the limitations and inelegancies of grafting a scripting language onto a generic database engine.

But it wasn’t until he went off to the California Institute of Technology that his experiments progressed further. Despite his official status as a physics major, Caltech offered plenty of opportunity for a motivated young hacker like him to immerse himself in the latest thinking about programming languages and compiler design. In the air all around him was computer science’s hot new buzzword of “object-oriented” design. By allowing the programmer to gather together data and the code that manipulates that data into semi-autonomous “objects,” an object-oriented programming language was an ideal fit for the problems of constructing a text adventure. (Indeed, it was such an ideal fit that Infocom had developed a heavily object-oriented language of their own in the form of their in-house adventure-programming language ZIL years before the buzzword came to prominence.) Following yet another trend, Roberts based his new adventure language’s syntax largely on that of C, the language that was quickly become the lingua franca of the world of computer programming in general.

On the theory that a worked example is worth a thousand abstractions, and following the precedent I set with my article on AGT, I’d like to show you a little bit of TADS code taken from a real game. You may want to refer back to my AGT article to contemplate the comparisons I’m about to make between the two languages. Taken together, the two articles will hopefully lead to a fuller understanding of just how TADS evolved the text-adventure-programming state of the art over AGT.

The game we’ll be looking at this time is Ditch Day Drifter, a perfectly playable standalone adventure that was also used by Mike Roberts as his example game for TADS learners. Once again following my AGT precedent, I’ll focus on that most essential piece of equipment for any old-school adventurer: a light source. Here we see Ditch Day Drifter‘s flashlight.

flashlight: container, lightsource
    sdesc = "flashlight"
    noun = 'flashlight' 'light'
    adjective = 'flash'
    location = security
    ioPutIn( actor, dobj ) =
    {
        if ( dobj <> battery )
        {
            "You can't put "; dobj.thedesc; " into the flashlight. ";
        }
        else pass ioPutIn;
    }
    Grab( obj ) =
    {
        /*
         *   Grab( obj ) is invoked whenever an object 'obj' that was
         *   previously located within me is removed.  If the battery is
         *   removed, the flashlight turns off.
         */
        if ( obj = battery ) self.islit := nil;
    }
    ldesc =
    {
        if ( battery.location = self )
        {
            if ( self.islit )
                "The flashlight (which contains a battery) is turned on
                and is providing a warm, reassuring beam of light. ";
            else
                "The flashlight (which contains a battery) is currently off. ";
        }
        else
        {
            "The flashlight is off. It seems to be missing a battery. ";
        }
    }
    verDoTurnon( actor ) =
    {
        if ( self.islit ) "It's already on! ";
    }
    doTurnon( actor ) =
    {
        if ( battery.location = self )
        {
            "The flashlight is now on. ";
            self.islit := true;
        }
        else "The flashlight won't turn on without a battery. ";
    }
    verDoTurnoff( actor ) =
    {
        if ( not self.islit ) "It's not on. ";
    }
    doTurnoff( actor ) =
    {
        "Okay, the flashlight is now turned off. ";
        self.islit := nil;
    }
; 
 

Unlike the case of our AGT example, for which we had to pull together several snippets taken from entirely separate files, we have here everything the game needs to know about the flashlight, all in one place thanks to TADS’s object-oriented design. Let’s step through it bit by bit.

The first line tells us that the flashlight is an object which inherits many details from two generic classes of objects included in the standard TADS library: it’s both a container, meaning we can put things in it and remove them, and a light source. The rest of the new object’s definition fleshes out and sometimes overrides the very basic implementations of these two things provided by the TADS library. The few lines after the first will look very familiar to veterans of my AGT article. So, the flashlight has a short description, to be used in inventory listings and so forth, of simply “flashlight.” The parser recognizes it as “flashlight” or “light” or “flash light,” and at the beginning of the game it’s in the room called “security.”

After this point, though, we begin to see the differences between TADS’s object-oriented approach and that of AGT. Remember that adding customized behaviors to AGT’s objects could be accomplished only by checking the player’s typed commands one by one against a long series of conditions. The scripts to do so were entirely divorced from the objects they manipulated, a state of affairs which could only become more and more confusing for the author as a game grew. Like those created using many other self-consciously beginner-friendly programming languages, AGT programs become more and more of a tangle as their authors’ ambitions grow, until one reaches a point where working with the allegedly easy language becomes far more difficult than working with the allegedly difficult one. Contrast this with TADS’s cleaner approach, which, like Infocom’s ZIL, places all the code and data pertaining to the flashlight together in one tidy package.

Continuing to read through the TADS snippet above, we override the generic container’s handling of the player attempting to put something into it, specifying that this particular container can only contain one particular object: the battery. Then we specify that if the player removes the battery from the flashlight when the flashlight is turned on, its status changes to not lit — i.e., it goes out.

Next we have the flashlight’s “long description,” meaning what will happen in response to the player attempting to “examine” it. TADS allows us to insert code here to describe the flashlight differently depending on whether it’s on or off, and, if it’s in the latter state, depending on whether it contains the battery.

Finally, we override the generic light source’s handling of the player turning it on or off, to tie the written description of these actions to the specific case of a flashlight and to reckon with the presence or absence of the battery. Again, note how much cleaner this is than the AGT implementation of the same concepts. In AGT, we were forced to rely on several different versions of the flashlight object, which we swapped in and out of play in response to changes in the conceptual flashlight. In TADS, concept and code can remain one, and the steps necessary to implement even a huge adventure game can continue to be tackled in relative isolation from one another.

Instructive though it is to compare the divergent approaches of the two systems, it is important to state that TADS wasn’t created in reaction to AGT. Computing communities were much more segregated in those days than they are today, and thus Roberts wasn’t even aware of AGT’s existence when he began developing TADS. Beginning as a language tailored strictly to his own needs as a would-be text-adventure author, it only gradually over the course of the latter 1980s morphed in his mind into something that might be suitable for public consumption. What it morphed into was, nevertheless, something truly remarkable: the first publicly available system that in the hands of a sufficiently motivated author really could create text adventures as sophisticated as those of Infocom. If anything, TADS had the edge on ZIL: its syntax was cleaner, its world model more thorough and consistent, and it ran in a virtual machine of its own that would prove as portable as the Z-Machine but was free of the latter’s brutal size constraints.

As TADS was rounding into this very impressive state, Roberts set up a company with a friend of his named Steve McAdams. In tribute to Roberts’s degree in physics, they called it High Energy Software, and, following in the footsteps of David Malmberg’s little AGT enterprise, planned to sell TADS as shareware through it. Version 1.0 of TADS was released in September of 1990, alongside two games to show it off. One was the afore-referenced freebie example game Ditch Day Drifter, while the other was Deep Space Drifter, a bigger game released as a shareware product in its own right. Both games tread well-worn pathways in terms of subject matter, the former being yet another “life at my university” scenario, the latter a science-fiction scenario with some of the feel of Infocom’s Starcross. Both games are a little sparse and workmanlike in their writing and construction, and some elements of them, like the 160-room maze in Deep Space Drifter, are hopelessly old school. (It’s not a maze in the conventional drop-and-map sense, and the puzzle behind it is actually very clever, but still… 160 rooms, Mike? Was that really necessary?) On the positive side, however, both games are quite unusual for their era in being scrupulously fair — as long, that is, as you don’t consider the very idea of a huge maze you have to map out for yourself to be a crime against humanity.

But undoubtedly the most ambitious and, in their way, the most impressive of the early TADS games came not from High Energy Software but rather from a pair of University of Maryland students named David Leary and David Baggett, who started a company they called Adventions to sell TADS text adventures via the shareware model. Of all the folks dabbling in shareware text adventures during the early 1990s, it was Adventions who made the most concerted and sustained effort at building a real business out of it. Their flagship series came to encompass three big unabashed Zork homages — Unnkulian Underworld: The Unknown Unventure, Unnkulian Unventure II: The Secret of Acme, and Unnkulia Zero: The Search for Amanda — alongside Unnkulia One-Half: The Salesman Triumphant, a free snack-sized sampler game.

When the first Unnkulia game was released remarkably quickly on the heels of TADS itself — Mike Roberts can’t recall for sure, but believes Leary and Baggett likely developed it with an early beta copy of the system — it stood as easily the most immediately impressive amateur text adventure ever. The text was polished in a way that few text-adventure developers outside of Infocom, whether amateur or professional, had ever bothered to do, being free of the self-conscious meta-textual asides and atrocious grammar that had always marked the genre. Adventions’s text, by contrast, looked like it had actually been proof-read, and possibly several times at that. Likewise, the game took full advantage of the sophisticated TADS world model to offer puzzles of an intricacy that just wasn’t possible with a tool like AGT. The first Unnkulia game and those which followed were almost in a league of their own for some time in all these respects.

On the other hand, though, the Unnkulia games strike me as curiously unlikable. You can get a good idea of their personality just by looking at their names. If the name Unnkulia — be sure to say it out loud — strikes you as hilarious, congratulations, you may have found your new favorite series. If it instead just strikes you as stupid, as it does me, perhaps not so much. (I admit that my attitude may be affected by having to type the damn thing over and over again; no matter how hard I try, I just can’t seem to remember how to spell it.) Much of the humor inside the games for some reason involves “cheez” — and yes, it’s spelled just like that. The humor has always been, at best, polarizing, and I have no doubt on which side I stand. In addition to just not being all that funny, there’s a certain self-satisfied smugness about the whole enterprise that rubs me the wrong way. At the risk of over-personalizing my reaction to it, I’ll say that it feels like the work of two young men who are nowhere near as witty as they think they are. In short, there’s something about these games that I find insufferable.

In terms of design, the Unnkulia games are an equally odd brew. It’s clear that they’ve been quite rigorously tested — another thing that sets them apart from most text adventures of their era — and they’re free of mazes, guess-the-verb puzzles, and the other most-loathed aspects of their genre. Yet the puzzle design still isn’t all that satisfying. There’s an obsession with hiding objects behind, under, and inside unlikely things — an obsession which is ironically enabled by the TADS world model, which was the first to really allow this sort of thing. Sometimes, including in the very first room of the very first game, you even have to look twice to find everything. Hiding surprises in plain view is okay once or twice, but Baggett and Leary lean on it so hard that it quickly starts to feel lazy. When they do get more ambitious with their puzzles, however, they have a tendency to get too ambitious, losing sight in that peculiar way so many text-adventure authors have of how things actually work in a real physical environment. Let me offer a quick example.

So, let’s set up the situation (spoilers ahoy!). You have a bronze plate, but you need a bronze coin to feed to a vending machine. During your wanderings in search of that among other things, you come upon the room below. (These passages should also convey some more of the, shall we say, unique flavor of the writing and humor.)

Inner Temple of Duhdism

This chamber is the temple of Duhdism, the religion of the ancients. It's rather a letdown, after all Kuulest told you about it. A small altar with a round hole in the center is in the center of the chamber. Carved in stone on the far wall is some writing, the legend of Duhdism. The only exit from this chamber is back to the east. You feel at peace in this room, as if you could sleep here - or maybe you're just kind of bored.

>read writing
"The Legend of Duhdha and the Shot to Heaven:

One fine summer day, Duhdha was loading a catapult with rocks. When his students asked what he was doing, the great Duhdha just smiled and said, "Something real neat." Soon, the catapult was full, and Duhdha pulled the lever as his students looked on. The stones crushed the annoying students, leaving the great man to ponder the nature of mankind. Not only did the rocks eliminate distraction from Duhdha's life, but they fell to the ground in a pattern which has since become a standard opening for the intellectual game of "Went." Since then, the altar at the Temple of Duhdha fires a small stone into the air soon after a worshipper enters, to honor Duhdha - who taught his students not to ask stupid questions and to pretty much just leave him alone."

>x altar
The altar is about two feet by one foot, and about three feet tall. There's a small round hole in the exact center of the top surface. The altar is covered with rock dust. There's nothing else on the Duhdist altar.

>z
Time passes...
A rock shoots into the air from the hole in the altar, shattering on the ceiling and spreading rock dust on the altar.  From the outer chamber, you hear the old monk cry "Praise Duhdha!."

We obviously need to do something with this rock-spewing altar, but it’s far from clear what that might be, and fiddling with it in various ways offers no other clues. Putting things on it has no effect on either the thing that’s just been put there or the rocks that keep flying out — except in the case of one thing: the bronze plate we’re carrying around with us.

>put plate on altar
Done.

>z
Time passes...
A rock shoots from the altar at high velocities, puncturing the plate in the center. The rock shatters on the ceiling, spraying rock dust. You hear a tinkling sound as a tiny bronze disc falls on the floor. From the outer chamber, you hear the monk shout "Praise Duhdha!"


*** Your score has just changed. ***

When you reach this solution either by turning to the walkthrough or through sheer dogged persistence — I maintain that no one would ever anticipate this result — you might then begin to wonder what physical laws govern the world of Unnkulia. In the world we live in, there’s no way that the flying rock would punch a perfect hole neatly through the middle of a bronze plate that happened to just be lying on the altar. Without something to hold it in place, the plate would, of course, simply be thrown into the air to come down elsewhere, still intact. The ironic thing is that this puzzle could so easily have been fixed, could have even become a pretty good one, with the addition of a set of grooves or notches of some sort on the altar to hold the plate in place. Somehow this seems emblematic of the Unnkulia series as a whole.

Like everyone else who dreamed of making a living from shareware text adventures, Leary and Baggett found it to be a dispiriting exercise, although one certainly can’t fault them for a lack of persistence. With some bitterness — “It’s disappointing that although there are so many IF enthusiasts out there, so few are willing to pay a fair price for such strong work,” said Baggett — they finally gave up in time to release their final game, 1994’s very interesting The Legend Lives! — more on that in a future article —  for free before exiting from the text-adventure scene entirely.

The same dispiriting lack of paying customers largely applied to makers of text-adventure languages as well. Mike Roberts estimates that his rate of TADS registrations peaked “on that same order” as David Malmberg’s pace of 100 AGT registrations per year, or “maybe a little lower. I’d remember if it had been much higher because I’d have been spending all day stuffing envelopes.” Whatever their respective rates of registration, far more AGT than TADS games continued to be released in the early 1990s. While that may have struck some — not least among them Mike Roberts — as disappointing, the reasons behind it aren’t hard to divine. AGT had a head start of several years, it had an annual competition to serve as an incentive for people to finish their games, and, perhaps most of all, it presented a much less daunting prospect for the non-programming beginner. Its kind and gentle manual was superb, and it was possible to get started making simple games using it without doing any programming at all, just by filling in fields representing rooms and objects. TADS, by contrast, offered a manual that was complete but much drier, and was on the whole a much more programmer-oriented experience. The initial learning curve undoubtedly put many people off who, had they persisted, would have found TADS a much better tool for realizing their dreams of adventures in text than AGT.

Some time after the Adventions guys and David Malmberg gave up on their respective shareware products, Roberts and his partner Steve McAdams also decided that they just weren’t making enough money from TADS to bother continuing to sell it. And so they made TADS as well free. And with those decisions, the brief-lived era of shareware interactive fiction passed into history.

But, despite the disappointments, Mike Roberts and TADS weren’t going anywhere. Unlike Leary, Baggett, and Malmberg, he stayed on the scene after giving up on the shareware thing, continuing to support TADS as open-source software. It took its place alongside a newer — and also free — language called Inform as one of the two great technical catalyzers of what some came to call, perhaps a little preciously, the Interactive Fiction Renaissance of the mid- to late-1990s. So, I’ll have much, much more to write about TADS and the games made using it in years to come. One might even say that the system wouldn’t really come into its own as a creative force until Roberts made that important decision to make it free.

Still, the importance of TADS’s arrival in September of 1990 shouldn’t be neglected. Somewhat underutilized though it may initially have been, it nevertheless remained the first development system that was capable of matching Infocom’s best games. If the amateur scene still largely failed to meet that lofty mark, they could no longer blame their technology. On a more personal note, the emergence of Mike Roberts on the scene marks the arrival of the first of the stalwarts who would go on to build the modern interactive-fiction community. We’re still in an era that will strike even most of the most dedicated fans of modern interactive fiction as murky prehistory, but some people and artifacts we recognize are beginning to emerge from the primordial ooze. More than a quarter of a century later, Mike Roberts and TADS are still with us.

(Sources: SynTax issues 17 and 36; SPAG issues 5 and 33; Mike Roberts’s interview for Jason Scott’s Get Lamp documentary, which Jason was kind of enough to share with me in its entirety. And my thanks to Mike Roberts himself, who answered many questions personally via email.

Ditch Day Drifter and Deep Space Drifter are available on the IF Archive for play via a TADS interpreter. The Adventions games are available there as well.)

 
 

Tags: , ,

35 Responses to TADS

  1. Matt Wigdahl

    February 3, 2017 at 6:53 pm

    I never wrote a complete game with it, but TADS landed me my first job out of college.

    I was one of those few actual shareware registrations back in the day — I paid the pretty-steep-at-the-time $50 (if I remember correctly) registration fee for TADS 2.0 and spent a good amount of time going over the manual and example code. Finishing up my degree and getting married knocked me off course from doing any major development with it at the time, but when I interviewed at a firm that was just getting started with C++ programming, I was able to credibly explain object-oriented concepts based Chapter 2 of the manual and my brief exposure to TADS example source despite the fact that I had never seen a line of C++ at that point.

    So thanks very much, Mike, both for the great software and for the solid overview of basic OO fundamentals you provided in your documentation!

     
  2. Lisa H.

    February 3, 2017 at 7:38 pm

    Still, AGT was far from the answer to every prayer, for the fact remained that it would have to be a very quick glance indeed.

    Heyyyy, are you saying my 16-year-old stab at an AGT game was less than wonderful?

    Is it Unnkulian, or Unkuulian? I’ve previously always seen it spelled the latter way. Google is giving me about equal numbers of results for either, so *shrug* but it seems to me that if that other character is named “Kuulest”, then it should be “Unkuulian” (given the wordplay they apparently both are supposed to be).

    Adventions’s text, by contrast, looked like it had actually been proof-read

    My goodness! *clutches pearls*

    You’re right, I didn’t anticipate the rock acting as a punch (!) for the bronze plate. TBH, adding something to fix the plate in place wouldn’t fix the physics problem for me; I’m having a hard time picturing the rock being able to punch through a bronze plate (and if it did it would tear, not make a perfect disc, etc. etc.). Maybe giving the player a bronze lump instead and using the high-velocity rock to smash it flat against the ceiling, and oh my, it’s a passable disc? Still not very likely, but seems slightly more intuitive to me, anyway.

     
    • Jimmy Maher

      February 4, 2017 at 8:00 am

      The games themselves, which we have to take as the definitive source, spell it “Unnkulian.” As I said in the article, I had to check this literally every time I needed to type it. In spite of that, you still prompted a brief moment of panic with this comment. ;)

      Putting some sort of a holder on the altar wouldn’t necessarily make the puzzle perfect in simulational terms, but I do think it would make it that much more plausible, and, more importantly, would do much to make it realistically soluble by giving a vital clue of what the player should be doing. We have to take whatever we can get sometimes…

       
      • Martin

        February 4, 2017 at 11:25 pm

        Never played the games but is their any explanation for those awkward Unn* names? The first thing I thought of is those weird names that get given to undiscovered elements but they use the unun* prefix.

         
        • Lisa H.

          February 5, 2017 at 4:20 am

          Well, if “Kuulest” is presumably “Coolest”… Unnkulian is presumably “Uncool-ian”?

           
    • Sebastian

      May 22, 2020 at 12:55 pm

      Maybe they should have gone with a giant hammer instead of the catapult. It would actually work for the puzzle and lend itself to stupid jokes about getting hammered.

       
  3. David Cornelson

    February 3, 2017 at 7:49 pm

    I remember talking to Mike on the phone around 1993 to order a copy of TADS. I still have all the materials. I never got far in TADS because at that time I was still a procedural programmer. Inform was slightly easier to understand and I gravitated to it, but I was still ridiculously excited when I got the little TADS package in the mail.

     
  4. Joey

    February 3, 2017 at 8:18 pm

    Late 1990.. Hmm, that’s around the same time LamdaMOO was released. Its OO language allowed objects and rooms to be programmed in-world. Don’t know if you plan to cover MUDs and MOOs at all, but that’s an interesting congruency.

     
  5. Stephen Norris

    February 3, 2017 at 8:50 pm

    Excellent article!

    It’s hard to remember just how fragmented the computing world was back then, even in Usenet-connected academia (where I was at the time).

    I had no idea TADS was a thing, but I managed to find MDL (and later DDL) and eventually Inform through Usenet.

    I must admit that even now, TADS syntax looks both verbose and opaque – and this is from someone who worked on operating systems in C back in the 90s. I think a lot of it is the (to me) bizarre choice of method names – “ioPutIn”? Really? And then the dual of that is Grab – which is a much clearer (and more memorable) name, but they’re like a pair of methods named by two different teams.

     
    • Jimmy Maher

      February 4, 2017 at 8:02 am

      It never struck me that way. But then I still like Java a lot, which is often accused of being ridiculously verbose if not opaque.

       
      • Alex Freeman

        February 4, 2017 at 8:58 pm

        I personally like Basic’s syntax the most generally speaking since different blocks have distinctive ends like END IF or LOOP as opposed to almost everything ending with a right brace. However, I seem to be in the minority.

         
  6. whomever

    February 3, 2017 at 8:59 pm

    Hey, I still have my Tads manual from registering it (somewhere). Never finished any of my games, but that’s my fault, not its.

     
  7. Tramboi

    February 3, 2017 at 9:03 pm

    I just feel like I’ve seen MUCH worse puzzles in praised games than the coin stuff.
    Don’t ask me which, though.

     
    • Alex Freeman

      February 4, 2017 at 5:09 am

      Which ones? ^_^

       
  8. Andrew Plotkin

    February 3, 2017 at 9:47 pm

    “But exactly when did TADS become freeware?” “That is really not a level of detail that this blog post needs, Zarf.”

    (I went and looked. Tads 2.2.1, released in October of 1996. I thought there might have been a gap between “TADS goes freeware” and “source code release”, but no, those were the same event.)

     
    • Ian Webb

      February 4, 2017 at 4:12 am

      And here, along with the simple fact that there’s little money to be made from authoring systems, my recollection is that Inform probably pushed Mike toward open source.

      TADS always felt like a well designed system, and Inform’s rise to the top was (as Graham has said) as much due to the existence of “Curses” and the “coolness factor” of compiling to the Z-machine.

       
    • Jimmy Maher

      February 4, 2017 at 8:04 am

      I’m slightly embarrassed to admit I never tracked down the hard date myself, and it surprises me a bit. I would have guessed 1993, the same year Adventions gave up and David Malmberg stopped supporting and selling AGT. I never would have guessed that TADS became free *after* the IF Comp got started. Made an edit to reflect this. Thanks!

       
      • Felix

        February 4, 2017 at 9:30 am

        Ah, that would explain why the first few IFComps had a separate category for TADS games: since TADS was still shareware at the time, that sort of implied that authors using it had more serious intentions, and therefore worked at a different level. Not that I think it was such a big difference in practice, but the decision at least makes sense now.

         
  9. Jonathan Blask

    February 3, 2017 at 10:20 pm

    Exciting stuff. In the upcoming post where you inevitably mention the Masterpieces of Infocom compilation, I hope you acknowledge how its inclusion of games from the first IF Comp led many to the existence of r*if and the IF community. At least, it did for me, and I imagine several others have a similar experience.

     
  10. Alex Freeman

    February 4, 2017 at 5:12 am

    Ah, yes, TADS. I remember settling on that after looking at AGT and Inform. AGT didn’t seem like a significant labor saver compared to C++ (which is what I was originally thinking of using), and Inform seemed rather esoteric to me at the time. TADS nicely resembled C++ (and I would argue actually has better designed OO features), so I quickly settled on it.

     
  11. Jubal

    February 4, 2017 at 7:17 pm

    “Duhdism, the religion of the ancients”

    Wait, it invented Dudeism a full eight years before The Big Lebowski came out?

     
  12. mrob

    February 4, 2017 at 7:52 pm

    I don’t consider the bronze plate puzzle unfair. It’s basic cartoon physics, like running through a wall and leaving a perfect outline. I haven’t played the games but it’s well suited to the tone of the extract you posted.

     
    • Martin

      February 4, 2017 at 11:32 pm

      I agree, as you explained it, that’s the first thing I thought of.

      If the stone was made of diamond and launched at a high enough speed, would it be able to punch through the bronze or would it just shatter?

      I guess it made no sense when you really look at it but it doesn’t reach a level of being unfair in my opinion.

       
      • Felix

        February 5, 2017 at 2:19 pm

        Diamond shatters easily in real life. It’s hard, but not tough. It would still be cartoon physics. :)

         
  13. ZUrlocker

    February 5, 2017 at 2:02 am

    I also bought the shareware version of TADS 1.0 and also the upgrade to 2.0. As a language, I thought it was very well designed, though it didn’t have an integrated development environment (IDE) or too many bells and whistles. The documentation was also good, though I never got very far in my attempts at IF until Inform7.

     
  14. Nathan

    February 8, 2017 at 5:01 am

    There are a few TADS 1.0 games on the archive, but does anyone have a terp?

     
    • Jimmy Maher

      February 8, 2017 at 8:42 am

      The standard TADS 2/3 interpreter will play TADS 1 games as well.

       
  15. jourget

    February 9, 2017 at 5:54 pm

    I don’t have a lot of experience with IF, so many of your articles have been eye-opening for me. If you would have asked me a few years ago, I would have said that gaming followed a fairly linear progression over the decades, moving from games that one person could bang out over the course of a weekend to modern AAA titles that have movie-level budgets and development teams numbering in the hundreds. I’d have said that it’s only been in the last few years that digital distribution and crowdfunding have allowed the indie Renaissance that’s brought us games like Firewatch and Gone Home.

    All of which is a long-winded way of saying that it’s fascinating to realize that small-scale development never went away, and has coexisted along with the increasing budgets and scope of mainstream games all along. I hope you continue bouncing back and forth between these two narrative threads all the way. Great stuff.

     
  16. Rowan Lipkovits

    February 11, 2017 at 4:48 pm

    If memory serves correct, TADS is the language in which Bob Bates is writing his new text adventure (with his kickstarted funds presumably going to the task of making TADS games portable for mobile systems). If that’s the case, then the accidental convergence of these two narrative threads is some true serendipity!

     
  17. hcs

    March 19, 2017 at 10:04 pm

    “And so they made TADS as well free.”
    Free as well?

     
    • Jimmy Maher

      March 20, 2017 at 8:34 am

      Either would work, but I prefer the feel of the original construction.

       
      • Jacen

        April 8, 2017 at 3:52 pm

        “And so they made TADS as well free.”

        Just saying, this made me raise an eyebrow and reach for the red pen as well, but you the boss, boss.

         
        • Steve Pitts

          April 17, 2023 at 3:55 pm

          Six years later and I choked on it too, but…

           
  18. Sam L-L

    March 10, 2018 at 1:03 am

    I found your blog last week and have been binge-reading it ever since – I greatly appreciate the research you put into this series, and the entertainment level of your writing!

    In the clearly traditional spirit of readers making pedantic grammar & spelling suggestions in the comments, I felt perhaps I should write in that the preferred abbreviation of the California Institute of Technology is “Caltech”, not as you have it here “CalTech”. (It’s a very common error…)

    Thanks, and I look forward to continuing the rest of the series!

     
    • Jimmy Maher

      March 10, 2018 at 2:08 pm

      Thanks!

       

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.