David J Prokopetz

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.

For instance: If the horse attempted to eat the player, it would first need to remove them.

I'm always up for clowning on Inform's world model, but in this particular case the implications of the "can't eat worn items" rule with respect to horse ridership are less interesting to me than trying to work out what concrete game design objective could possibly be served by defining the player character as both wearable and edible in the first place.

@moddeydhoo replied:

Inform is apparently used pretty heavily in certain segments of the mainstream gaming industry as a rapid prototyping tool; much of its recent development has been aimed at serving that audience, rather than traditional interactive fiction, though the latter obviously benefits from the fact that it's still in development at all.

(Like, why do you think Inform has this big fancy IDE with all these enterprise-level features while every other IF platform barely has a manual? It's certainly not for the benefit of your average hobbyist!)

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.

For instance: If the horse attempted to eat the player, it would first need to remove them.

I'm always up for clowning on Inform's world model, but in this particular case the implications of the "can't eat worn items" rule with respect to horse ridership are less interesting to me than trying to work out what concrete game design objective could possibly be served by defining the player character as both wearable and edible in the first place.

I think one of my favourite domain-specific programming quirks is how, in Inform, code for rideable vehicles is non-portable to rideable animals (and vice versa) because the former are implemented via the "supporting" relation, and the latter, the "carrying" relation, meaning when you're riding a horse you're technically in the horse's inventory.

You'd think that would count as being equipped.

Owing to the way Inform's default equipment system works, having the horse equip the player would require the player to be defined as wearable, which has several implications.