There’s a fascinating conversation from TADS’s own Mike Roberts over at http://community.livejournal.com/tads3/1202.html about creating an easy-to-learn-and-use alternative to TADS3’s built-in library, a library sizeable enough that it has its own name and acronym, “adv3”.
The conversation is restricted to livejournalers, so I’ll quote Mike’s opening salvo here before putting in my two cents:
I’m not a user of TADS (2 or 3 – but not for a lack of trying), but observe a few rough corners after working elbow-deep in Inform’s.
-
Inky made the observation that simulating darkness isn’t really needed nowadays, and I agree. We have a larger contingent of sight-impaired players to whom darkness-as-impediment is a joke. Inform has something like 5 Activities dedicated to what is, at the most basic, a boolean property on a room. Talk about swatting a fly with a Buick.
-
Inform’s library irritates me in that it doesn’t keep sight & sound differentiated. Just because an NPC is trapped in a container doesn’t mean the player can’t talk to them, but it’s a pain in Inform. The built-in conversation actions are geared toward seeing/touching, not hearing. Sense-passing has been important to TADS, and dialogue depends on one of those senses.
-
TADS’s strong suit is having some sort of dialogue system that’s ready to go. I think that’s crucial for any I-F system worth its salt, and while I understand Inform’s hands-off approach, I would definitely want that even in a pared-down library.
-
My personal WIP uses command history, and I code normal inform stuff using “if we have Xed the Y” all the time, which is basically the same thing. Except TADS’s is more generalized – one could imagine the equivalent of “if we have Xed the Y after Xing the Z” as being built-in to TADS. Such if-statements are crucial to adapting text to player agency.
-
Anything that understands more of what the player enters. See Aaron Reed’s Inform extensions regarding a kinder, smarter parser hand. Parsing possessives is an oft sticking point for Inform coders – especially since they theoretically are just a hint to disambiguation routines.
-
Inform’s LOOK command has always seem too large and opaque to me. Jeff Nyman wrote a tutorial that only dealt with it, IIRC. Aaron Reed called for a modification to LOOK I enshrined in the Mentioned In Room Description extension. I don’t know how complicated TADS’s LOOK is, but, yeah.
-
Working with writers, I see a common pattern of they wanting a piece of text to appear right around time X in any plausible method. I recently had an issue in that I wasnt’ supposed to have NPC follow the PC, but the NPC should deliver important quip Q 2 turns after NPC#2 said something to PC & NPC, but if the PC immediately left before the 2-turn timer triggered then he’d miss it. So the writer says ‘well it’s ok to follow a little while until Q is delivered’. So I find myself rather that working from cause (the circumstances) toward effect (the quip) like in a sim, I’m working from effect (the quip) and only using fancy coding to insert/narrate a linking, plausible cause (following if not in location, deduction if trigger was never set, simple say otherwise). (I realize that’s a verbose and vague complaint, but its the best I could do.)
I don’t know how TADS wants to position itself. If it wants to be the simulation-heavy dev tool, then perhaps a leaner library isn’t appropriate. But it has a lot of programming features such as the dynamic stuff which make possible new kinds of interaction.
Theoretically.