A "suggested" topic. These provide suggestions for things the player might want to ASK or TELL another actor about. At certain times (specifically, when starting a conversation with HELLO or TALK TO, or when the player enters a TOPICS command to explicitly ask for a list of topic suggestions), we'll look for these objects in the actor or actor state for the actor to whom we're talking. We'll show a list of each currently active suggestion we find. This gives the player some guidance of what to talk about. For example:

>talk to bob
"Excuse me," you say.

Bob looks up from his newspaper. "Yes? Oh, you again."

(You'd like to ask him about the black book, the candle, and the bell, and tell him about the crypt.)

Topic suggestions are entirely optional. Some authors don't like the idea, since they think it's too much like a menu system, and just gives away the solution to the game. If you don't want to have anything to do with topic suggestions, we won't force you - simply don't define any SuggestedTopic objects, and the library will never offer suggestions and will even disable the TOPICS command.

If you do want to use topic suggestions, the easiest way to use this class is to combine it using multiple inheritance with a TopicEntry object. You just have to add SuggestedTopic to the superclass list for your topic entry object, and give the suggested topic a name string (using a property and format defined by the language-specific library) to display in suggestions lists. Doing this, the suggestion will automatically be enabled whenever the topic entry is available, and will automatically be removed from the suggestions when the topic is invoked in conversation (in other words, we'll only suggest asking about the topic until it's been asked about once).

Topic suggestions can be associated with an actor or an actor state; these are topics that a given character would like to talk to the associated actor about. The association is a bit tricky: suggested topic objects are stored with the actor being *talked to*. For example, if we want to suggest topics that the player character might want to ASK BILL ABOUT, we store these suggestions with *Bill*. We do NOT store the suggestions with the player character. This might seem backwards at first glance, since fundamentally the suggestions belong in the player character's "brain" - they are, after all, things the player character wants to talk about. In practice, though, there are two things that make it easier to keep the information with the character being asked. First, in most games, there's just one player character, so one of the two actors in each association will always be the player character; by storing the objects with the NPC, we can just let the PC be assumed as the other actor as a default, saving us some typing that would be necessary if we had to specify each object in the other direction. Second, we keep the *response* objects associated with the character being asked - that association is intuitive, at least. The thing is, we can usually combine the suggestion and response into a single object, saving another bunch of typing; if we didn't keep the suggestion with the character being asked, we couldn't combine the suggestions and responses this way, since they'd have to be associated with different actors.

class SuggestedTopic :   object

Superclass Tree   (in declaration order)


Subclass Tree  


Global Objects  


Summary of Properties  

associatedTopic  curiositySatisfied  fullName  location  name  suggestionGroup  suggestTo  timesToSuggest 

Summary of Methods  

associatedTopicCanMatch  associatedTopicIsActive  associatedTopicTalkCount  findEnclosingSuggestedTopic  findOuterSuggestedTopic  fromEnclosingSuggestedTopic  initializeSuggestedTopic  isSuggestionActive  noteSuggestion 



Our associated topic. In most cases, this will be initialized automatically: if this suggested topic object is also a TopicEntry object (using multiple inheritance), we'll set this during start-up to 'self', or if our location is a TopicEntry, we'll set this to our location. This only needs to be initialized manually if neither of those conditions is true.

Have we satisfied our curiosity about this topic? Returns true if so, nil if not. We'll never suggest a topic when this returns true, because this means that the player no longer feels the need to ask about the topic.

The name of the suggestion. The rules for setting this vary by language; in the English version, we'll display the fullName when we show a stand-alone item, and the groupName when we appear in a list group (such as a group of ASK ABOUT or TELL ABOUT suggestions).

In English, the fullName should be suitable for use after 'could': "You could <fullName>, <fullName>, or <fullName>".

In English, the phrasing where the 'name' property is used depends on the specific subclass, but it should usually be a qualified noun phrase (that is, it should include a qualifier such as "a" or "the" or a possessive). For ASK and TELL, for example, the 'name' should be suitable for use after ABOUT: "You could ask him about <the lighthouse>, <Bob's black book>, or <the weather>."

By default, we'll walk up our 'location' tree looking for another suggested topic; if we find one, we'll use its corresponding name values.

Set the location to the actor to ask or tell about this topic. This is the target of the ASK ABOUT or TELL ABOUT command, NOT the actor who's doing the asking. This can also be set to a TopicEntry object, in which case we'll be associated with the actor with which the topic entry is associated, and we'll also automatically tie the topic entry to this suggestion.

Because we're using the location property, you can use the '+' notation to add a suggested topic to the target actor, state objects, or topic entry.

no description available

the ListGroup with which we're to list this suggestion

The actor who *wants* to ask or tell about this topic. Our location property gives the actor to be asked or told, because we're associated with the target actor - the same actor who has the TopicEntry information for the topic. This property, in contrast, gives the actor who's doing the asking.

By default, we return the player character; in most cases, you won't have to override this. In most games, only the player character uses the suggested topic mechanism, because there's no reason to suggest topics for NPC's - they're just automata, after all, so if we want them to ask something, we can just program them to ask it directly. Also, most games have only one player character. Games that meet these criteria won't ever have to override this. If you do have multiple player characters, you'll probably want to override this for each suggested topic to indicate which character wants to ask about the topic, as the different player characters might have different things they'd want to talk about.

The number of times to suggest asking about our topic. When we've asked about our associated topic this many times, we'll have satisfied our curiosity. In most cases, we'll only want to suggest a topic until it's asked about once, since most topics only have a single meaningful response, so we'll use 1 as the default. This should be overridden in cases where a topic will reveal more information when asked several times. If this is nil, it means that there's no limit to the number of times to suggest asking about this.


associatedTopicCanMatch (actor, scopeList)actor.t[1351]

is it possible to match the associated topic?

associatedTopicIsActive ( )actor.t[1345]
is the associated topic active?

associatedTopicTalkCount ( )actor.t[1348]
get the number of previous invocations of the associated topic

findEnclosingSuggestedTopic ( )actor.t[1227]
find the nearest enclosing SuggestedTopic parent

findOuterSuggestedTopic ( )actor.t[1242]
find the outermost enclosing SuggestedTopic parent

fromEnclosingSuggestedTopic (prop, defaultVal)actor.t[1263]
get a property from the nearest enclosing SuggestedTopic, or return the given default value if there is no enclosing SuggestedTopic

initializeSuggestedTopic ( )actor.t[1320]
initialize - this is called automatically during pre-initialization

isSuggestionActive (actor, scopeList)actor.t[1282]
Should we suggest this topic to the given actor? We'll return true if the actor is the same actor for which this suggestion is intended, and the associated topic entry is currently active, and we haven't already satisfied our curiosity about the topic.

noteSuggestion ( )actor.t[1359]
Note that we're being shown in a topic inventory listing. By default, we don't do anything here, but subclasses can use this to do any extra work they want to do on being listed.

TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3