Cards as a metaphor for a MUD database

In working on various abortive projects to create a more modern MUD (usually in Ruby), I've thought about what stopped me. Part of the problem is the vagueness of the proposal: "create something as good as what's already out there". I was tempted to load down my new model with features: objects and properties and methods, security, multithreaded user applications...

I realized lately that I wasn't following Unix philosophy, and that Unix has been successful and popular precisely because of those attributes. So I started fresh.

Instead of a nebulous idea of a database of objects, I am creating a Mud whose object model resembles a collection of TCG-type playing cards, such as Magic: the Gathering. This is not to say that I'm implementing a collectible card game as such.

There is a deck - a set of cards, and an understanding of how to persist those cards to some sort of backing store.

There are cards - each one with a unique identity within the deck.

There are rules - either generic rules like "room", or card-specific rules like what happens if you pick up THIS green glowing gem. Each card has a set of rules attached to it. In code terms, rules are the methods and attributes associated with an object.

There are hands - collections of cards meant to fulfill a specific purpose.

I don't intend to elaborate much past this. If, for example, we want to implement complex verbs or commands, we do that by creating an action card and associating it with a room or other object. When the command parser gets a command and figures out what to do with it, it builds a hand out of the cards in the system's action list, the player action list, and the player's current location's action list. Once we add an inventory system, it can look there as well.

The point is that we should start with a simple, flexible tool and let other modules of the overall system use that tool, rather than building a large featureful interface that doesn't lend itself well to extension.