It is almost always undesirable from a user interface perspective to ask for help disambiguating a topic phrase. In the first place, since all topics tend to be in scope all the time, we might reveal too much about the inner model of the story if we were to enumerate all of the topic matches to a phrase. In the second place, topics are used in conversational contexts, so it almost never make sense for the parser to ask for clarification - the other member of the conversation might ask, but not the parser. So, we'll always filter the list to the required number, even if it means we choose arbitrarily.

As a first cut, we prefer objects that are physically in scope to those not in scope: if the player is standing next to a control panel and types "ask bob about control panel," it makes little sense to consider any other control panels in the simulation.

As a second cut, we'll ask the actor to filter the list. Games that keep track of the actor's knowledge can use this to filter according to topics the actor is likely to know about.

Determine if the object is in scope. We consider any vocabulary match to be in scope for the purposes of a topic phrase, since the subject matter of topics is mere references to things, not the things themselves; we can, for example, ASK ABOUT things that aren't physically present, or even about completely abstract ideas.

Resolve the topic phrase. This returns a ResolvedTopic object encapsulating the resolution of the phrase.

This default base class implementation simply creates a resolved topic list with the whole set of possible matches undifferentiated. Subclasses for specialized actions might want to differentiate the items in the list, based on things like the actor's knowledge so far or what's in physical scope.