A filter is a piece of code that runs before an action, to determine whether it should be allowed or modified. The first use of this feature is a filter for taking objects from containers. If the container is closed (something the TAKE verb has no knowledge of), the container filter makes sure execution doesn’t continue (and an appropriate response is generated).
It’s a valuable feature, but a bit rough around the edges.
Filters Now
- Easy to set up, works fine for simple cases
- Behavior for multiple filters is undefined (that’s bad)
Filters Later
I need to expand the feature set to handle more complex situations. Primarily:
- More advanced feature constraints (e.g. “filter for
TAKEfrom a container in the Cave”). Right now a filter runs for all actions matching the given verb. - Handling of multiple filters in a predictable way. I don’t have a firm solution for this yet. The simplest way to handle it is a prioritized list, but the relative priority of two filters isn’t necessarily the same in all situations.
There are also a couple use cases I’ve been considering, for which filters might be applicable. For example, setting a rule for an action like “when entering the Cave while holding food” would be a challenge in the current system.