Also, can anyone explain to me what it means that Inform is rules-based? How does that differ (for someone who only understands T3), and what does that allow you to do that T3 can’t do?
Sure does, it just calls them “phrases” instead. It even has higher-order functions.
1 Like
True. I suppose my comment was misleading. My apologies.
This is perhaps why Inform 7 drove me a little nuts - I kept thinking: “I know how to do what I want to do in a more traditional language.” I can understand, though, how the natural language approach works for someone who thinks about composing a story in a different way.
For me, TADS was very natural. Want to make an object drinkable? That is trivially inherited from the Thing class. In my day job, I am always preaching less OOP because I think it is overused in my corner of the industry. But in the case of adventure games, it seems a logical fit.
1 Like
I’m bad at describing things like this, but I’ll try with an example:
Let’s say I want to define a new way for a thing (say the Elvish Sword) to print its name. Well, I’d write a rule to do that, like:
Rule for printing the name of the Elvish Sword:
say "A really nice Elvish Sword";
but then I want it to appear differently in a particular room:
Rule for printing the name of the Elvish Sword in the Troll Room:
say "A really nice Elvish Sword (glowing)";
but then I want a rule for swords in general:
Rule for printing the name of a sword:
say "A sharp sword";
Inform then chooses which to call based on specificity – i.e., the second gets called before the first, which gets called before the third.
So they have some of the flexibility of overloading methods, or overriding methods in subclasses, but they can do more, as evidenced by the “in the Troll Room” example.
3 Likes
Nothing, really. They’re both Turing-complete 
4 Likes
I don’t know Tads at all, but I think it mostly just allows you to separate the source code differently. Like the second code block in Making the Items do Something from Getting Started in Tads 3, in Inform you might say Instead of taking the skull when the rock is not on the pedestal: say "poisoned arrows shoot from the walls"; end the game or something like that. It wouldn’t necessarily be an if statement with all the branches in one place. Which…can be both good for adding extra exceptions later and bad for finding all the possible ways a command can go, I guess?
So “rules” for what happens in particular situations instead of inherited methods and conditions to do different things when they get called in particular situations, basically
2 Likes
The adv3 and adv3Lite libraries are written in a traditional OOP style, but there’s no reason someone couldn’t write a new library system that would run on the TADS VM. That said, it would be an epic level of effort to re-implement what already exists and is considered battle-tested code.
2 Likes
It’s not the natural language that attracts me to Inform 7. In some ways it would be a better language if it eliminated a lot of the natural language stuff and just kept the central language concepts. The natural language stuff works well in the declarative parts, but less well in the imperative parts.
3 Likes
Indeed. Takes a little discipline to organize everything in a way that you can trace them out later.
3 Likes
The Index helps out a lot in that regard, listing out the rules that will be considered for each action.
3 Likes
They’re rarely used (other than texts including substitutions, which are technically functions returning a text) but you can declare all kinds of functions as properties if you really want them!
I realized recently that this trick to include invocation of arbitrary phrases in adaptive text along with the item described providing an equivalent to self pretty directly creates traditional methods… albeit with the substantial limitations that they can’t take parameters or return a value other than text.
Lab is a room.
To say @ (ph - phrase): (- if (0==0) {ph} -).
An object has a text called the method.
Alice is a person in the lab.
The method of Alice is "[@ try the item described jumping]".
when play begins: say the method of Alice.
And there’s also my even more tortuous former effort at OOP.
But the thing that exercise made me realize is that I7 offers the equivalent via rulebooks; it’s just inside-out (and somewhat verbose).
Let’s take a traditional OOP-y thing: you have a class with an attribute with an associated reader for that attribute. But then you want a subclass whose method overrides the parent class method and does something dynamic instead of just returning the attribute.
Uninspired example:
[ just syntactic sugar for `<K> produced by the X rules for Y` ]
To decide what K is a/-- result of/-- a/an/-- (r - an M based rulebook producing values of kind K) on/of/for/with a/an/-- (v - a value of kind M):
(- ResultOfRule({r}, {v}, true, {-strong-kind:K}) -).
A thing has a number called the @temperature.
The @temperature of a thing is usually 10.
A hot-thing is a kind of thing.
Thermometer is a thing based rulebook producing a number.
Thermometer for hot-thing (called the hottie):
rule succeeds with result 100 * @temperature of the hottie.
Last thermometer something (called the thermometee):
rule succeeds with result @temperature of the thermometee.
To decide what number is the temperature of (t - a thing):
decide on the result of thermometer for t.
The microsun is a hot-thing.
when play begins:
say "[temperature of player].";
say "[temperature of microsun].";
1 Like
@JoshGrams and @rileypb , I appreciate the effort and I kind of get ya but I guess without seeing more substantial code side by side I don’t really see how it’s different (other than syntax) from
class Sword: Thing
printName { say(‘a sword); }
;
elvishSword: Sword
printName { if(player.isIn(trollRoom)) say(‘an elvish sword (glowing)’);
else say(‘an elvish sword’); }
;
1 Like
I haven’t read the whole thread but usually when people say “Inform 7 is better than other languages because it’s rules-based”, they’re usually comparing it to ADRIFT, Quest, Adventuron, and other languages that typically do code for single item interactions and don’t support a ton of rules (although some of those languages have made big strides recently).
TADS, Inform, Dialog and Hugo are the four that are rules-based and generally of equal value and flexibility.
4 Likes
In my personal subjective view of history (which isn’t totally accurate), Inform became more popular than TADS early on because it compiled to the z-machine format used by Infocom, which had a ton of interpreters available. It remained popular later on because TADS didn’t have good options for web play. Now I think people are just unfamiliar with it.
I doubt there’s any real difference between the languages besides those things and personal preference.
4 Likes
I just want to say I’m planning on doing my next game in TADS, after Spring Thing. Or at least my next game other than the ones that are sitting unfinished on my harddrive.
5 Likes
I think the need for a single-purpose interpreter for full sound and image support in TADS holds it back. I’m sure that many people open the games in their 'terp of choice, which is probably not QTADS.
That is a requirement, isn’t it? I know some games need QTADS for something.
I’m speaking only as a player, of course. I have no experience with TADS as an author, and probably never will.
3 Likes
It’s becoming less-so, as more terps are supporting more features from HTML TADS.
Ideally, a TADS author should keep different capabilities of interpreters in mind when developing, and not require a specific one. Mostly because if you’re not doing that, then you’re unlikely to be screen-reader-friendly, too, among other accessibility features.
My game is ideally played on QTADS, but if you’re using a screen reader or a simple terminal, then it’ll still play just fine, and re-arrange the wording and output of certain things accordingly.
3 Likes
I’m not talking about screen reader support, which I just expect in 2023. I’m talking–unscientifically, I admit–about the way people open IF story files without any special prompting or guidance.
1 Like
Right, and what I’m saying is that a TADS author should have awareness of this environment, and assume players will open a TADS game in any interpreter at all.
The only reason why I mentioned screen reader support is because:
That sort of thing is an expected standard to meet. So if an author is keeping that sort of thing in mind anyway, then…
…QTADS should never be required for anything, unless the author is doing something very experimental and niche. But at that point, they aren’t aiming for widespread convenience for players, anyway.
Note, I said “ideally”; not “required to be”. I’m expecting players to be using Parchment, so I’m primarily developing for that.
Same thing as “ideally this song should be played on studio monitors”, while expecting 99% of the listeners to be playing a song on dollar-store earbuds or out of their phone speakers.
3 Likes