Mud.getState()

Someone (Kirill) told me today I should post occasionally about the overall status of the MUD, as in, what features are in, what's blatantly missing, and such. What kind of game is it right now, and what level of maturity has it reached? I don't know a good format for it, but I do love lists...

Logging in

I know it sounds pretty basic, but you can log in to the MUD using telnet. Once in, you can type commands and things happen!

Multiple users at once

Another basic sounding thing. More than one person can be logged on to the MUD at the same time. Making this work turned the MUD into a multi-threaded server, with all the concurrency problems that come along with it. I probably have some race conditions and deadlocks in my code.

Linkdeadedness

Players who go linkdead (sever TCP connection without actually logging out of the MUD) will show up as linkdead, and when they reconnect, they will be attached to the already logged-in character. Making this work increased the flexibility of the networking stack and a few layers above it.

Communication commands

Players can communicate with each other using global chats (the ooc command, seen by everyone logged on) and in-room chat (the say command).

Movement

Players can walk from one room to another. There are only a few rooms, but the proof of concept of moving is demonstrated.

Looking

Players can look at what's in a room, look at a given person, mob, or item. They can look inside a container and see what's in it. They can look in their inventories and see what items they're carrying.

Object (dealie) manipulation

Players can pick up, drop, and destroy items. Players can get items from inside of containers. Players can pick up items that others have dropped.

Killing mobs

Players can slay mobs on the spot. This is only interesting because the MUD has to remove the mob from the game world.

Snooping / controlling

Players can snoop other players. Basically, they see everything that the other player sees, including the commands they type in exactly as they type them.

More interestingly, a player can snoop/control a mob. Once attached, the player sees from the mob's eyes and any commands he types in instead control the mob. It's a neat way for players to use NPCs to interact with other players, for role playing purposes. In later stages, the snoop command will be reserved for privileged users (immortals).

Descriptions

Players can edit their own descriptions using a simple in-game text editor that offers commands like appending a line, deleting a line, etc..

Targeted commands

This is actually kind of cool. Players can target their commands at a variety of targets:

• look cover
• look "barn cover"
• look 1.cov
• look 2.cov
• drop all
• drop all.cov
• get all.cov 2.sack
• look 1.

Variable delay commands

There is a command queue for each player, into which all the commands they type go. Different commands have different delays. For example, the look command completes very quickly, but (arbitrarily) the jump command (which right now does nothing more than echo a message) takes approximately 4 seconds to complete.

When a long command is going on, if the user types more commands, they all wait until the currently executing command finishes. There's an exception here: something called a "fast" command, which can jump right to the head of the queue. Somewhat arbitrarily, the emote command (think: "/me runs in a circle") is "fast", so even while you're jumping, you can type an emote to describe how you're jumping.

If you have several commands in your queue, the ~ command clears your queue. So if you just typed in a whole ton of slow commands and you change your mind, just use ~, and after the currently executing command finishes, whatever you typed in after the ~ will be at the head of your queue. This is actually a pretty standard feature for MUDs, and a necessary one in my opinion.

Creation

A proof of concept creation system is in place. When a user types in a username that's not in the MUD's database of players, they're taken into a wizard-style creation, where they're asked a series of questions leading up to the creation of their new character. Right now it's quite skeletal, but it demonstrates the capability of forking off the login process to a creation process, the wizard-style questions, and the creation of a new character based on the answers to the questions.

Rebooting and such

The MUD can be shut down using the shutdown command. This saves all players to disk and cleanly boots all the network connections, shuts down the main loop, etc., before finally terminating the ruby interpreter.

The MUD can be rebooted using the coldboot command. This basically performs a shutdown followed automatically by starting the ruby interpreter the same way one would manually from the command line. It's fairly primitive.

The cool feature is that the MUD can be rebooted on the fly using the hotboot command. Network connections are not severed, but all MUD code and areas are reloaded. This can be used in probably 95% of the cases, takes only a few seconds, and users might not even notice that it took place.

The hotboot can't be used when making modifications to the hotboot code itself, to the format of some of the internal data of the hotboot system, or possibly changing the XML format of data files. In general, it is both fast and danger.

Loading and saving world data from/to files

All dealies, rooms, and mobs are loaded from XML files on disk. Also, changes made to a player, including aliases, inventory, and so on, are saved to files too.

Color!

Everyone loves color! Using a familiar method from other muds, users can enclose text almost anywhere with mini-tags like {r and {x to display text in color.

Logging

There's a few decent methods internally for logging comments. Comments are logged with the file, line number, and function that generated them, which is handy. There's a method for asserting and another method for printing a stack trace from a given point, to help track down bugs. Generally, though, it's pretty primitive.

Eventos

Messages and notifications of things are passed as objects to listeners, like the room you're currently in, which can in turn forward them if need be. This allows for communication using object data rather than strings, which then in turn can lead to better mobprogs.

Tests

Not really a feature per se, but very useful in development. There are a number of tests in place to help catch regressions if I make code changes.

Aliases

Users can create fairly complicated aliases that are persisted with their player. These aliases can even be chained.

Socials and Pmotes

There is a fairly involved parsing system in place to support socials and pmotes (which are kind of the same thing), in which the player can use various directives embedded in their text to interpolate targets' short descriptions, names, etc.., even going so far as to properly use the grammatical case.

If I make major modifications, I will add things to this list.