AnacroniA MUD

Av4 technical information

The MUD is written in the Perl programming language.
Perl is a highly-capable, feature-rich programming language with 23+ years of development, and a massive amount of plug-in modules on the CPAN.

Av4 is meant to be a "sandbox" MUD implementation, which allows a developer to simply download the code, install the various required Perl modules, and have an easy to develop and deploy Multi User Dungeon. It will also be used as the codebase behind the MUD "Anacronia".

Anacronia - as a MUD - had been online during the turn of the last century, and aimed to create an environment where a player would be able to find themselves in various "eras" at different times throughout the setting's history, from what would be a medieval setting, through a modern-age era, to a space-travel era. The codebase that Anacronia was running on was not malleable enough to provide this, so in time the MUD closed and various rewrites started: one in C++, and this one, the fourth in its history, in Perl. This should also be the last rewrite.

Av4 uses the following Perl modules in order to be concise, fast, and as extendable as possible. A profiler is used at various times during the development, to ensure these modules perform as well as they can. The architecture has already been changed from POE to AnyEvent because of this, for example.

• Class::XSAccessor creates screamingly fast getters/setters for the game objects. This is used by anything from the TelnetOptions and User objects, to the online Help system.
• AnyEvent is the magic which allows the MUD to be really responsive and handle many connections. Rather than using a select-based loop to handle I/O, it uses an asynchronous I/O loop. Few tasks in the MUD are performed synchronously: usually an action is initiated and a callback is created which in turn outputs things to the user or performs specific actions. Using AnyEvent allows the I/O part of the MUD to be as fast as it possibly can. This wouldn't be entirely possible without the following modules, though:
• AnyEvent::Gearman Allows the aforementioned AnyEvent to asynchronously ask a task to be performed by a Gearman worker. Many tasks which take a long time to be performed are therefore offloaded to a separate worker process, which returns the results to the caller via a callback, which in turn displays output to the user or performs actions. This helps in keeping the I/O loop running as fast as it can be.
• AnyEvent::Memcached Allows AnyEvent to asynchronously request a memcached server for the value possibly associated with a key. The MUD uses memcached for data which can be expensive to compute and the value of which does not change often. For example, the help pages are "ansified" once and then kept in the cache, as "ansifying" several of them may take longer than fetching the pre-ansified version from the cache.
• Inline::C Allows some timing-sensitive parts of the MUD to be written in C, and to be callable directly by the higher-level Perl code. Parts of the ansification (specifically, the part that translates parts of the colour keywords to the correct ANSI value) are done in Inline::C and silently compiled and used. Many NYTProf runs did indeed show that the older Perl implementation for the routine was too slow and a cause of concern, and the current C implementation is fast enough to cause no concerns.

Av4 Supported Protocols

Many MUDs nowadays use a number of Telnet options to enhance their users' experience. Examples include the "Telnet GA" sequence, sent after a MUD prompt, to signal the client that the user is able to enter a command, or "COMPRESS2" (also called "MCCP2") which allows the MUD to compress the game data, and save bandwidth.

Av4 supports the following telnet options:

• MCCP2: initialization support. All incoming connections are asked to state whether they can support MCCP. Upon receiving a positive answer from the client, the MUD will start sending compressed data to the client. Av4 gathers statistics about how much data is sent to mccp2 connections, to non-mccp2 connections, and overall. The command stats displays these statistics. TODO: tests must be made to ensure that if the client chooses to end the MCCP2 session, the data is properly flushed and communication resumes using the non-compressed method.
• GA: prompt support. After sending a prompt, the MUD will send the IAC GA sequence to alert the client that it's able to accept more input.
• NAWS: client width and height support. Av4 probes all incoming connections to request whether they are able to provide the server with the width and height (in characters) of the client. This information is then gathered whenever changed on the client side, and available to the Av4 code. Currently it is simply displayed using the who and stats commands. TODO: text should be formatted to fit the client's width. The height can also be used to create a pager to be presented to the client.
• TTYPE: first terminal name support. Av4 probes all incoming connections to request whether they are able to send the server their terminal name. This can be xterm, mushclient, zmud, and others. Currently this information is only shown on the stats command. No further probing is done: the specification allows for the client to send -- when probed -- more than one terminal type. Av4 uses the first one, and asks no further. TODO: in the future it may be used to create client-specific overrides.

Av4 is slowly starting to support the following telnet options:

• MXP and MSP: limited to probing only. Av4 probes all incoming connections to request whether they are able to support MSP and MXP. The connection is then flagged accordingly. Currently neither are used, save for a @mxp command used for testing on-line.
• ATCP: limited to probing only. Support for this is currently on the feature-atcp Git branch. Av4 probes the client for ATCP and allows testing by using the @atcp command to send and display information using the ATCP protocol. Remote editing is on the roadmap and will likely be one of the first things to be implemented using this protocol.
• ATCP2: If enough MUD clients will support it, it will be supported.

Av4 used to support but will likely drop support for the following telnet options:

• MCP: Not many clients have support for it, and its remote-editing features (the only reasons that really made it stand out) are currently better served by the ATCP protocol.

Command queue

Av4 uses a novel command queue parser, with weights and delaying. This allows a user to queue up commands and query their status via the commands command. Queued commands are executed by priority: this allows a user to query the command queue, as the command "commands" has quite a high priority. The queue is implemented so that a mage will be able to execute "meta" commands such as "help" or "stats" while memorizing a spell. It also paves the way for different queues "slots", which will allow a user to separately queue up offensive and defensive commands, and have them executed as soon as the related queue slot becomes free.