adv3lite design decisions

I’m struggling to understand why some of adv3lite was done the way it was. For example, as with adv3, I could just define the “me” object as

me : Actor

But the documentation for the player character for adv3lite is routinely this:

me : Thing
  isFixed = true
  proper = true
  ownsContents = true
  person = 2
  contType = Carrier

What the documentation doesn’t seem to bother addressing is the most obvious question: Why would I do that? Why would I avoid deriving “me” from Actor? Or, better, why would I make “me” a Thing and then re-add the parts of the Actor class that make it so that the “me” object acts like an Actor? There’s one part mentioned about how you can do this to be “minimalist.” But what’s being described is actually the opposite of that. Calling a person-type object a thing-type object does not make it minimalist. Having to specify less (not more) is what makes something minimalist.

Also, little changes here and there seem to have been done for no good reason. For example, why change ‘roomName’ to ‘roomTitle’? Beyond adding yet one more inconsistency between adv3 and adv3lite, it arguably makes more sense to have a room “name” than a room “title”. Yet in other places, logic indicates a “name”: such as “DarkName”, “roomnameStyleTag”. There are a lot of other inconsistencies. Admittedly small in and of themselves, I suppose.

Looking at it purely from design orthogonality principles, it would have been quite easy to make a lot more compatibility between the two libraries to make transitioning easier and I have no clue why that wasn’t done. But, then again, I suppose if that was done, you could argue it would have been easier to just modularize adv3 rather than create a new library.

I sort of get what you’re talking about there. I brought this up before, albeit slightly differently. See:

Those conversations, as you can see, often went nowhere productive. Keep in mind that is more likely due to my own lack of ability to articulate my points well enough.

In classes I’ve taught, where I’ve used TADS 3, there was no concern about the “complexity” of the Adv3 library, defeating much of the purpose of Adv3Lite for many people. In fact, Adv3Lite was more often than not seen as a complication not worth exploring.

However, this being said, there are, in my view, some demonstrably nice things that Adv3Lite introduces. But, as you’ve noted, the inconsistencies here and there make them a bit problematic to port directly to Adv3 in a lot of cases.

What I’ve found people often needed was simply a bit more of a refined map to Adv3, rather than a new library entirely. The good news, of course, is that nothing is stopping anyone from continuing to use Adv3 just as it is and, thus, never considering Adv3Lite at all. It is also possible, via some juggling of code bits, to retrofit some of the better aspects of Adv3Lite into Adv3.

So how exactly do you go about that? There’s no guide to all of the little micro-changes made to make it easy to backport logic. So do you just plug something back in, see what breaks, and go from there?

If this is the direction it was going, I see why TADS sort of dropped off the radar compared to Inform. Consider me a sad TADS 2 veteran.

Well, for example, if you look at postures.t, you’ll see it uses one of the new elements that you found (roomTitle), in lines like this:


That would be roomName in adv3. One of the key changes is the use of a single ‘vocab’ property intead of ‘vocabWords’. And you can see some of those differences reflected in the templates. And that can help you figure out what to look for in some cases.

Noted. :slight_smile: Keep in mind, adv3 is still very powerful on its own. You really don’t need anything that adv3lite does. And if you do find something interesting, like the rules module or something, those are usually easier to backport to adv3 because they are are using intrinsic aspects or are using bits of the overall libraries (system or otherwise) that weren’t changed.

[size=150]Side Topic / For What It’s Worth:[/size]

As far as the “direction it was going”, adv3lite in TADS and usage of TADS vs Inform are entirely orthogonal, I believe.

Consider that Inform has a wider ecosystem overall. Its web-based solutions are much easier to use and deploy with, widening the audiences you can reach. (I just did a series of blog posts using Inform 7 and the web-based interpreters. That’s something I could not have done as easily in TADS.) And Inform has an IDE approach that is functional across operating systems and one that, at least arguably, has the least cognitive friction. Inform, in my opinion, simply out-competed its parser-based alternatives.

CYOA-style, or choice-based, alternatives are (to me) orthogonal to the TADS / Hugo / Inform ecosystem. But they are clearly gaining in popularity and seeing a lot of innovation and, I would argue, often have an easier learning curve.

So combined with that, it’s likely that not too many parser-based alternatives are going to ultimately command much attention. You’re probably going to have one that “rules the roost” and sees the most engagement. That happens to be Inform and, again, I feel that’s because it ultimately out-competed its friendly competitors. It innovated more broadly and, importantly, made that innovation consumable by varying skill levels. (I suppose in that one sense, that’s where adv3lite faltered in terms of helping TADS gain traction, which is what my quoted/referenced posts earlier were about.)

I personally greatly enjoy programming in TADS. But if I were writing a game that I wanted to distribute as widely as possible and as easily as possible to as many people as possible, while having the widest possible community support, TADS would not be my first choice.

If you honestly think all that, you should probably take a look at my “Extension Pain” post in the Inform area.

I don’t want to go into philosophical debate, I just want to note that although the purpose of adv3lite is to provide simplified library for TADS it was not produced by taking adv3 and stripping down complicated parts but rather building the new library from ground up. At least this is my impression. At least the difference in vocabWords is because the adv3lite is built on top of entirely different parser called Mercury which Mike Roberts prepared.

One drawback of hosting TADS interpreter on server and communicate game output over internet is the need to be online all the time you play a game. On the other hand I really enjoy the ability to use all the bells and whistles of modern browsers (HTML/CSS/JS) in webplay and having everything under my control. Where is your blog, what you can’t do as easily?

This probably more than other reasons. Whatever for real or for looking more approachable to beginners.

Some, but by no means all. My recollection (it’s been a year since I did any IF at all) is that adv3lite includes Inform-style scenes and regions, which can’t easily be back-ported into adv3.

The reason why the me object requires a bit more definition is because the adv3lite class library is intentionally shallow. This avoids the awkward situation where a class you’re using is inheriting from two or more base classes, which can result in unexpected behavior.

Other changes, such as stringing all of the vocabulary together in one chunk, are, in my view, debatable.

Sheesh, my apologies for the extremely delayed response to this!

The blog series was here: … teractive/

Basically, however, what I did was provide the web-based interface for each iteration of the exercise. For example:

Not only did having the published source text right on hand make it a fun and interesting exercise, but the extremely light-weight approach to providing a browser-based solution was critical in being able to produce numerous versions quickly, with an absolute minimum of back-end supporting infrastructure. I literally just had to copy a directory to my server and everything worked. I don’t think that’s even remotely possible with TADS, but I’m more than happy to be corrected on that.

Thanks, so the need is to be able to embed web play game into page on your website where it will sit inside your design beside your menu and such. TADS’s answer to webplay is different than Inform’s, it doesn’t have pure JavaScript interpreter which could be copied into static web pages but instead have a possibility to run a server to serve a game. That is for sure out of reach of non-technical people, but TADS community provides public game servers, so the real problem is that TADS’s webui frontend is currently not able to run in an iframe due to some JS bug. Ok, I will definitelly look into this at some point.

You once again mentioned your problems with TADS webui in another thread so I’ve finally taken a look at it. TADS webui wasn’t designed to be run inside an iframe, but it seems not much trouble to make it work. There is a file util.js in webuires folder in which the following changes seems to resolve most of the problems:

[code]— util.js.orig 2014-08-03 13:16:01.000000000 +0200
+++ util.js 2017-10-08 22:46:43.000000000 +0200
@@ -14,6 +14,7 @@

// my page name, as I’m known to the server
var pageName = “”;
+var sameOrigin = false;

// the generic noun we use to refer to this program in error messages
// (game, story, program, …)
@@ -65,7 +66,10 @@
function utilInit()
// if we have a parent, ask the parent for my name

  • if (window.parent && window.parent != window)
  • try { sameOrigin = ==; }

  • catch(e) { }

  • if (window.parent && window.parent != window && sameOrigin)
    pageName = window.parent.pathFromWindow(window);

    // detect the browser version
    @@ -733,7 +737,7 @@

    // if we have a parent window, ask it to look for a default
    var par = window.parent;

  • if (par && par != window)
  • if (par && par != window && sameOrigin)
    // there’s a parent window - pass the request up to it
    par.setDefaultFocus(desc, fromWin);
    @@ -837,7 +842,7 @@

    // if we have a parent window, propagate the click

  • if (window.parent && window.parent != window)
  • if (window.parent && window.parent != window && sameOrigin)
    @@ -2986,7 +2991,14 @@
    // find the top-level window
    var w;
  • for (w = window ; w.parent && w.parent != w ; w = w.parent) ;
  • for (w = window ; w.parent && w.parent != w ; w = w.parent)

  • {

  •    try
  •    {
  •       if( != break;
  •   }
  •    catch(e) { break; }
  • }

    // if there’s no path, get the top-level window
    if (!path)
    @@ -3188,7 +3200,7 @@
    function debugLog(msg)
    // send this to our parent window, if we have one

  • if (window.parent && window.parent != window)
  • if (window.parent && window.parent != window && sameOrigin)
    Most simple way is make webuires folder in your game source code folder and copy util.js here making the necessary changes.

There is only one error remaining, it is reported in embedded error log about inaccessible href property, but browser doesn’t report error location so I still can’t find the source of the problem. The error seems harmless, game works AFAIK correctly. Maybe someone will be more successful than me and will find the error.

But the point is, once you fix the util.js, you can compile game for webui and on your webpage made in ordinary HTML hosted anywhere you can add something like:

<iframe src="" width="800" height="600"></iframe>

You will replace for your own domain and your game file. Will this help you? Is this what you want to achieve?

I appreciate your work on this. My initial concern, when contrasting Inform 7’s approach and TADS 3’s, was simply that with Inform I didn’t have any dependency on anything once deployed. By that I mean I could literally put an entire folder on my server and that was it. I was relying on no cloud solution, no databases, etc. That single folder contained the game, the interpreter, and the web page that allowed the game to be played in the browser. Literally everything was on my server and in just one folder. (That also allowed me to easily host multiple versions of the games, which were, in my case, incremental living examples.)

The contrast was when I read the TADS 3 documentation and it was talking about having PHP and MySQL (or SQLite). I now realize that I can host the game file and have point to that, which is something I quite simply missed or glossed over. This is similar to how (apparently) I could host an Inform 6 file and have a reference to that in an url. But note that with Inform 7 – apparently contrasted even with Inform 6 – I don’t even need that reference; everything is stored on my server of choice.

But I think any we work all of us do to make TADS more accessible or even just accessible in different ways is beneficial. Your work here is certainly an example of that, in terms of providing options. In fact, I can see a lot of use for this for some of the material I’m putting together.

I’m getting close to getting the dos tads3 interpreter to run in js-dosbox

Character set is still munged though.

I find this thread thought provoking. I am still very new to IF development. I played IF in the early days of computing, as early as Adventure and Trek on teletype terminals back in the 70s. As I move into formal retirement, I need someplace to channel my interests. I stumbled back into interactive fiction while thinking of ways to develop abstract reasoning and high order thinking skills is public school students. A non graphic means to stimulate learning may be a good vehicle to reach those goals for some students.

I have a modest background in programming. In the last several months, I have surveyed the IF development learning material for the various developer tools I have found. A parser based system holds the most utility for my needs. I expect to use Twine for the early stages of development. That also provides an entry level means of sharing my “story/puzzle tools” with young students. I have experimented with both TADS 3 and Inform 7. An earlier post in this thread commented that Inform 7 has cornered the market with its more modern plain language development system, flexibility with post development game play and an extensive developer community.

For the last month or so, I have been experimenting and learning TADS 3. The syntax and object oriented approach is a good approach for me. When I switched to the adv3lite library, I was even more impressed and my learning accelerated. However, after reading this thread, I went back and again did some experimentation with Inform 7.

I am so impressed by the resources available to IF authors today. All of the them are incredibly polished for their intended purpose. I wish that I had come back to interactive fiction years ago. For my purposes, TADS 3 in conjunction with adv3lite is the best solution. It compliments my previous experience, learning style and needs. I have no problem setting up a server to provide game play. Inform 7 initially seemed to be the best learning path, but Tads is much easier to learn based upon my prior knowledge of programming.


FWIW, I agree. Not that I’ve done any IF authoring lately … and also, I’m known to be partisan. But while I7 does provide some deep and powerful programming constructs (once you dig into the I6 layer), and while some people (Zarf among them) love the rule-based approach to program design, the primary appeal of I7 has always seemed to me to be to those who have no background in programming and just want to write an interactive story. I’m strictly a fumble-fingered amateur programmer, but I find that syntax and library of T3 much more natural than “natural” language programming.