Rules are a declarative way of describing meaningful events in your story.
They are made up of 3 parts: a "trigger", a set of "conditions", and a set of "changes" to apply if the rule matches. Each time you call findMatchingRule, the engine will test all of your rules against the provided trigger and the current state of your story world, and will find the best matching rule (if one exists).
Rules are weighted based on how specific they are, so you can "override" a more generic rule by making a more specific rule that will also match.
It is possible to create generic rules (using MatchAny) to control basic story logic, and more specific rules to flesh out the story.
See how the rules are defined in the full working example.
Unique ID for a rule. These ids will be returned when a matching rule is found.
All of the rules in your "rule book" that define your game logic.
Finds the rule that best matches against the provided trigger (entity ID) and current world model. If multiple rules match, this chooses the "best" match based on the most specific rule. In general, the more conditions, the more specific.
Call this any time the player "interacts" with an entity in your game, supplying the ID of the entity that was interacted with.
While the trigger is intended to match one of the entity IDs defined in your world model, you could also programmatically call this at any time with any string, as long as there is a rule with a matching trigger. This can be useful for "abstract" events that you want to respond to, like "wait" or "next day".
Assigns a "weighting" to a rule. Used internally.
A declarative rule describing the conditions in which it should apply. Specifically, it defines a trigger and a list of other conditions that must be present. All of these are described by
EntityMatchers. All rules are tested on each player interaction, and the highest weighted matching rule will be returned. You can then apply the specified changes.Note that
Rules are extensible records, meaning that you can add other fields to them in your game. For example, you could add anarrativefield to add a story text to use when the rule matches, or asoundto play, etc. All of these "side effects" would be handled in your game code. Alternatively, you could use the returnedRuleIDto lookup side effects in a separate data structure. This design follows the Entity Component System (ECS) design pattern.