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.
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.
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:
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.
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.
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.
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.