I’ve been spending some more time thinking about the Erlang MUD, namely, how all the data is going to be structured. The last time I worked on it (a week ago?) I was rewriting the rewrite to use records instead of tuples for all the user/room data. In Erlang, “records” are basically structured tuples crossed with dictionaries, so the tuple is composed of a bunch of key->value pairs.

I need to use records, because it makes everything play nice with Mnesia later down the road.

I’ve also given some more thought to some designy things. I’ve always liked the idea of games within games, and hell, why not make this a meta MUD? To do this, we’ll define an environment, making each environment independent.

What this implies is that each user account is associated with (possibly) an independent entry in the user-data table for each environment that user has been in. I actually don’t think this adds much complexity to the code; given there will exist a table for user data, I can just change the table key from the user_id to a tuple { user_id, env_id } and, possibly, add in another table mapping each user_id to the env_id to load at login.

There’s still a couple of design issues which need to be considered, namely, transitions between environments. When you transition into an environment, does it get pushed onto a per-user environment stack? Or does it take the place of the last environment completely? This is important for defining what happens when the user “exits” the environment (or, if they can exit it). I think the solution I’m playing with in my head uses both methods for different ends.

The need behind this feature is to meet one of the themes of the game – realities. Each environment essentially represents a different reality. How you define reality, however, is something which is up for interpretation, thus the above problems.

How about some use cases.

Assume your player goes to sleep, for example, and has a dream. This dream might manifest itself by spawning another environment as a child to the environment the character was already in. The character interacts with this environment, does some stuff, and then wakes up. They exit the dream environment and re-enter the unchanged parent environment.

Another approach might be to use the environments for a mini-game, like gambling. The problem with this is that the gambling environment needs to get the state of the player. One approach is to make a copy of the player state and pass that into the environment, then restore the old player state when the player leaves. The problem with using this for gambling is that the affects on the copied player state will probably need to be propagated back to the parent state, to reflect any winnings/losses made.

Anyway, tl;dr, I need to think about it some more. I think there’s a lot of benefits with any approach (like having support for independent player-managed environments on external hosts running non-Erlang applications, etc), but we’ll see.