Design pattern (in TADS3/adv3) for accessing Topics without an Actor or Consultable

Authoring TADS
1

Is there a standard design pattern for using Topic and/or something like ConsultTopic, only without hanging them on an Actor or Consultable?

What I want is something like an abstract >DEFINE [something] command, where [something] matches a Topic’s vocabulary and the responses are something like a ConsultTopic.

So my first pass is something like:

tFoo: Topic 'foo';
tBar: Topic 'bar';
tBaz: Topic 'baz';

widget: MultiLoc, Intangible, Consultable
        initialLocationClass = Room
        dobjFor(ConsultAbout) {
                verify() {}
        }
;
+ConsultTopic @tFoo "The answer is foo. ";
+ConsultTopic @tBar "The answer is bar. ";
+ConsultTopic @tBaz "The answer is baz. ";


DefineTopicAction(Define)
        execAction() {
                local m;

                if(gTopic == nil) {
                        reportFailure('Nope. ');
                        exit;
                }
                m = gTopic.getBestMatch();
                if(m == nil) {
                        reportFailure('Different nope. ');
                        exit;
                }
                replaceAction(ConsultAbout, widget, m);
        }
;
VerbRule(Define) 'define' singleTopic : DefineAction
        verbPhrase = 'define/defining (what)';

This works, but it feels kinda like a kludge. Is there a cleaner way to handle this kind of thing that I’m missing?

2 Likes
2

Felt bad no one was engaging this, so I took a peek. I quickly convinced myself that there is no way you didn’t ALREADY look under these rocks, but in the interests of muting the echo, here’s my (cursory) take.

ConsultAbout as a verb does two things.

  1. It uses the Consultable class to finalize the Topic list via its filterTopicmethod in turn invoking the Consultable’s resolveConsultTopic method
  2. The Consultable (which is both a Thing and a TopicDatabase) dobjFor(ConsultAbout)THEN invokes handleTopic from TopicDatabase to print the topic entry.

So, it seems to me that your very similar functionality would need to recreate both those steps (though I am unclear exactly how critical step 1 actually is). At which point the fairest question is, “But Consutlable already does those, why bother?”

Leading me to conclude that your implementation is probably the most elegant! The only potential ‘Improvement’ I could think of (without trying, so maybe not possible) would be to define DEFINE as a ConsultAboutAction, with no singleDobj in its vocab, and a DefaultDobj that always selects widget

I think then, that the most direct answer to your general question

Is “make it a TopicDatabase and use handleTopic… along with whatever checking and pruning Consultable is already doing”?

1 Like
3

Yeah, the specific example I slapped together can be improved. I was more wondering if there were alternate general approaches I was missing, like if there was something similar to the stock footnote implementation only for arbitrary keywords or something like that.

What I want is almost the adv3 hint system, but non-modal. But I also haven’t fiddled around much with the hint system because I’m handling most hinting in-game, both via NPCs (dispensing hints in conversation and/or being able to accomplish/bypass some puzzles upon request by the player), and via in-gameworld meta-hints (bathrooms in the game are sources of fourth-wall breaking information about game mechanics). And invisiclue-like external hints.

But apart from that kind of thing I also want a couple of in-game references. Like if a description mentions the pediment over the entryway, >X PEDIMENT will provide a description of it, but not necessarily a definition of what a pediment is. So I want something like >DEFINE PEDIMENT that’ll tell the player all about the nomenclature of architectural entablature…and that none of it is gameplay-relevant. And then I similarly want to provide a reference for in-game people, locations, and so on. Not a quest log or journal, but as a mechanism for doing things like the player finds a brochure from the Chamber of Commerce and reads it, it says, “You learn a number of facts about the town’s history,” and then when you encounter a statue of Cornelius Q. Cornsquatter in the town square the player can consult further information about the statue without having to hunt up the brochure, or having had it spelled out in a tedious lore dump when initially reading the the pamphlet.

All of the latter kinds of things are basically just a database with gameplay-keyed topic availability. And there’s a fair amount of overlap (although not 1-to-1 correspondence) with conversational topics for the “real” NPCs. So I was assuming that Topic was what I wanted, but I assume a lot of wrong things so I figured it was worth asking.

2 Likes