My older brother came up with a system for MUDS years ago he called DOOR (Door Object Or Room.)
EVERYTHING in the MUD is a DOOR. DOORS have two properties:
(1) They can contain other DOORs
(2) They can contain regexp commmands that run scripts.
I added one concept which was two regexp lists, an "inner" command list and an "outer" command list.
You throw strings at objects as commands. The match order AIR was follows:
(1) OUTER commands of my children
(2) INNER commands of my Parent
(3) OUTER commands of myself.
This simple structure allowed for virtually EVERY action necessary in a MUD. If you want some examples, describe a few scenarios at me and I'll show you how it decomposes into DOORs
A simple example is a lighting example.
Outer command "look" on the character is a script that prints my parent's description.
A dark room has an inner command "look" that prints "The room is dark." This has precedence (see above).
A torch has an outer command "look" that prints the description of my parent's parent. So this overrides the dark room when placed in the inventory of the character.
While one *could* simply look for a torch object in the player's inventory in the room "look" command, this would mean that the room would have to have apriori knowledge of all light sources. By using the DOOR paradigm the torch can be created after the fact and the dark room need know nothing about it.
