I want to have a rule associated to a whole kind of objects:
Things have a rule called instructions.
So that I can programatically follow those rules, while looping through lists, or visible objects, or whatever:
follow the instructions of the noun.
Writing with Inform provides this example, “for completeness”:
A food has a rule called the food effect.
(...)
The food effect of carrots is the bright-eye rule.
This is the bright-eye rule: now the player is bright-eyed.
What this code says is: the rule is another rule, the other rule is this. This two-liner is ugly. Directly writing This is the food effect of carrots rule: now... doesn’t compile. Does anyone know a more elegant way of doing something like this?
I believe storing rules as properties is only really useful if the objects may change freely which rule they are associated with during play. If this is not what you need, then (as the introduction to the example points out) it’s easier to create a thing-based rulebook, which would allow you to write out the rules concisely:
Food effect rules is a food based rulebook.
A food effect rule for carrots:
say "yummy."
Food effecting is a food based rulebook.
Food effecting carrots:
say "yummy."
And even if you do need some objects’ instructions to vary dynamically: as long as most rules are static, the conventional (and easier) way is to write a rulebook anyway. For those objects that need more dynamic behavior, their rule just checks some variables, or some (non-rule) properties of the object in question, to decide what to do.
My next worry is about performance. I know it’s not very hard to make Inform slow, and I’m planning to have a “food based rulebook” with probably a few hundred individual rules (related to a few hundred individual “food” objects). I’ve checked that I can do follow the food effect rule for carrots, but I still worry that this kind of structure might have a bad overhead.
I would agree that it’s not very hard to make Inform slow, but not by just having a lot of distinct rules. If you look through the really bad performance issues previously discussed in this forum, it’ll usually boil down to something like this:
There’s an operation that’s already relatively expensive when done once, e.g., route finding (with a reasonably big map), or high-caliber text processing, or looping through all objects in the game to find one matching a description.
For one reason or another (e.g., being invoked from scope computation or another common activity) that operation is performed hundred or thousand times per turn.
While there are some discussions raising the same concern you have, I’ve never seen an actual report of performance problems due to too many rules.
Note that even if you have 1000 rules and Inform picks between them by always checking the conditions for every rule in order of precedence (this is in fact more or less what happens in Inform 10.1), that “only” costs you those 1000 checks (plus whatever work the applicable rules actually do). You could, in theory, write very complex conditions that make this costly. But for something like Food effect rule for carrots: ... the check “is the parameter value the carrots object?” is ultimately just a handful of cheap I6 operations. It’s not exactly free to add more and more such checks, but it’s one of the cheaper things you can do in an Inform game. It may start mattering if you follow the same rulebook many times per turn, but that also multiplies the cost of the actual work in the applicable rule, which may be equally or more expensive. Plus, if you have that many distinct rules then you probably also have a few hundred objects, and that has historically been much more likely to cause performance problems for myriad reasons.