Programming conventions

Naming conventions

Elei-Dras MUD engine is a very complex application and has a large number of libreries. So it is a necessiry to impose a rigid naming convention, in order to understand as quick as possible what I am working with.

File conventions

All files must be easy to recognize:

Type, variables and constants convention

Types, variables and constants have a specific convention.


Variables and Constants

I use here the term Constant also for variables which are valorizes in the code (i.e. CWorldCommands) even if they are defined as var and not as const;

Common used local variables

In my functions and procedures I commonly use some variables; here is a list og them and their common (but not exclusive!) use:


TToken is a type defined as string[60]; it is designed to contain unique, mnemonic identifier for every recordset in the game. Note that all tokens are supposed to be in capital letters, and the engine itself will capitalize all tokens when it reads them from files.

Tokens are used while reading the databases in order to identify elements and connect them. In example, an Iron Sword, in the database has the IRON token in the <material> field. This defines internally that the sword is made in Iron.

Note that this system is developed in order to avoid rigid dependences. For example, if my DB defines COPPER and IRON as metals, and I put PLATINUM between them, the system stais coherent.

It would be impossible to do the same linking through an index reference. So, be extra carefull when you manage TToken variables.

Note that every decodeable recordset must have a TOKEN or FlagName(deprecated) field.


The MUD time is managed in a different way respect the standard time. So special managing procedures are needed. The TMUDTime is an int64 value. Note that an year is made of 12 mounts of 30 days each; this is hardcoded, so you cannot modify it without recompiling; I'm also studiing a way to do that in a more personalized way using a TCalendar class.

Note that the world time passes only if the server is active! The ratio between MUD time and time in the real world is defined in the .cfg file and can be changed; do it only when you start a new server 'cause it could have bad effects on all the characters!.


Here i put a list of folders; the root is the folder where you unzip the project:

List of liberies

EleiDras uses a set of libreries developed for the project itself as long as some controls and libreries from the Jedy Project.

Libreries from Jedy Project (please do not modify this libreries, and keep them updated from the official site)

Libreries from controls developed for EleiDras, installed via \Source\MUD_Components\MUD_Components.dpk

Libreries for EleiDras project are (you can find them in the source folder):


Constants is a very important library for the EleiDras codebase. Here you can find all constants but also populating, decoding, encoding and explicit functions.

AddxxxFromString procedure

This is a standard class of procedures (Value:String) that populates constants'arrays from .csv files;

DecodexxxFromString function

This is a standard class of functions (aString:String):yyyy; that searches for a Token in the given constant list; it is used to connect data.

EncodexxxFromString function

This is a standard class of functions (aValue:yyyy):string; that returns the corresponding token for the given value.

ExplicitxxxFromString function

This is a standard class of functions (aValue:yyyy):string; that returns the name of the object with the given index.

Communication protocol

EleiDras uses a special client/server communication protocol. This can grant, in example, the compelte translation of commands ans special keywords, graphical support for the creation of the characters and other nice functionalities.

A normal transmission (such as a plain text description) is always sent in plain ANSI text (7 bits). Also character codes are completely literals.

Text format protocol

All text transmitted to and from EleiDras Codebase Servers is in ANSI 7 bit encoding. But special non ANSI characters such as text formatting are possible using the EleiDras Text Encoding. Encodings are used for variables, special characters or text commands such as color change and format change.

All encodings start with a special character:

All the above uses ; as an end of command delimitation.

Special characters

The encoding itself is very similar to the HTML encoding and it works the same way. For example, if you want a “&” to be displayed by the client, you should replace it in the sent text with a “&amp;” sequence. If you need an “Á” then the code is “&Aacute;”.

Most of the standard codes are implemented, but not all. In addiction, for internal use we included the following codes:

&perc;This code is needed to display a “%” character, as long as that character is reserved for management uses;
&lff;This code is provided for forcing a line feed character; note that the transmitted text is epured by multiple spaces and line feed or from feed characters, just as a standard HTML text, so you need this character to force a from feed;

All codes are case sensitive! Keep in mind when you use them, or you could obtain defective messages.

Server variables

Server variables are replaced before sending the text with special contents, such as the character name (§char_name;) or the user internal name (§plr_name;). You can find all of those examples in the entering_screen.xml file.

The following is a list of all implemented server side variables:

§mudname;Name of the MUD server
§mud_mail;Administrative email
§boot_date;Start time of the current session
§first_start;(Not yet implementer) date of the first running of the MUD server.
§wait_days;Number of inactivity days; if you do not make your first succesful connection in the pas N days after your account is created, it will be automatically removed.
§revision;MUD codebase revision
§plr_name;Player internal name
§plr_pwd;Password; yes, it is, so do not spit at me; it is used for the confirmation mail even if you can put it where you want;
§char_name;Name of the currently selected character;

As you can see there're also sensitive informations. So, PLEASE, do not abuse this codes.

Client commands/variables

Client variables are simply something like that: %n;. They are used mainly in the response protocol. If a variable is not decoded, then it is simply erased before the text is displayed (so you would not find a %1; placed in a reponse because a replace was not provided).

Client text commands are more complex to deal with:

All text commands are defined in the string: ';,'#255'#:/tcbiur'; #255 is indeed a binary character and is used to introduce a binary parameter; it is not part of ANSI charset for the reason that binary contents cannot be placed in text files, so you haven't to need to use it!

The following are recognized commands:

tcInvalid0There's an error in the decoding of the commandCannot be inverted
tcEndCommand;1Command terminatorCannot be inverted
tcNextConnamd,2Separator among commands; sometimes it is ignored, but is always used when commands has parameters Cannot be inverted
tcSepBin#2553Binary data(ignored); Cannot be inverted
tcSepHex#4Used to specify that the parameter is specified as a set of hexadecimal data; by now it is used only with colors; Cannot be inverted
tcSepStr:5the following text up to the next tcEndCommand or tcNextCommand must be conisdered as a string Cannot be inverted
tcCloseFunction/6This inverts the following functionCannot be inverted
tcTextColort7Changes the current color of the text client; from now on all characters are written with the specified color; reset the foreground color to clSilver;
tcBGColorc8Changes the current background color of the text client; from now on all characters are written on the specified color; reset the background color to clBlack;
tcBoldb9Writings are bolt from now on clear the bold attribute of the text
tcItalici10Writings are italic from now on clear the italic attribute of the text
tcUnderlineu11Writings are underlined from now onclear the underline attribute of the text
tcResetr12Resets all text attributes including colors and formatting;Cannot be inverted

When a color is sent in binary format, te command is followed by binary “#4” character if the color is a system color (ibgr) or by “#3” character if it is in rgb format (rgb); “i” means index byte, “r” is for red byte, “g” for the green byte and “b” for the blue byte; note that “#3” and “#4” are also the dimensions of the color variable in bytes;

Special communication protocol

Special data are transmitted between client and server using special non printable commands; this are binary commands of course and are used for priority communications and silent information exchange. In Example, this protocol is used to identify the client and server revisions, but also to identify players and populate pre-game menues or information pages, and even to visualize the wilderness map.

EleiDras MUD codebase make a massive use of that protocol, because it permits to lacalize commands and outputs with great ease and without recompiling the sources.

This language is a key resource of the project, so it is important to understand it well before changing the I/O protocol!

Generic language

Every communication writte in the special communication language is delimited by an initiator and a terminator defined in the constants: utils.StartCommandLong, and utils.EndCommandValidator.

There's no need to define longer strings, because the usual buffer is around 8000 characters, so longer commands cannot be received correctly. Furthermore, string longer than 1000 characters can cause a huge amount of lag, so they must be avoided whenever possible.

Each command has a header formed by an initiator choosed between StartCommandShort and StartCommandLong, followed by the byte containing the command, and a parameters control character, for a total of 3 bytes. If the parameter control character is utils.ParamEnd this means that no parameters are provided and after we will find the EndCommandValidator.

If there're parameters, then we will use the utils.ParamStart followed by the length of the whole data; for a short command is a byte value (8 bits), and for a long command is a word (16 bit). After this value we will find the data buffer itself terminated with ParamEnd character and EndCommandValidator.

The following schema explains the protocol



Parameters are ment to be in binary format, but beware, you must know by yourself which parameter you put in the string; protocol management functions do not do any check at all! So, if you send a byte you can try to read a word, and this can have unpredictable results!

Of course it is very possible to create a sound protocol that checks at least the parametes size and reports abuses or errors, but this will mean that we should use extra transmission band for this! If there're hackers' attempts then we will provide it, but by now we prefer the quickest way.

Parameters are divided in 3 categories:

  1. normal: are sent just as images of the memory they required, so a byte will be sent as a binary byte, a word as 2 binary bytes and so on;
  2. strings: are sent enclosed in quotes
  3. binary: a word (16 bit) containing the datasize is sent before the buffer

Each parameter then is followed by a terminator, that can be the ParamEnd character, if the parameter is ment to be the last one, or the ParamSep character; if the extraction function does not find this character at the end of the parameters returns false to advise that something is not right.

The command is one of the following list:

The special characters used to manage commands are the following:

Constant nameValueMeaning
utils.ParamStart:there are parameters
utils.ParamSep,there are parameters
utils.ParamEnd#4no parameters

As long as the same characters are choosen there's no need to respect the previous association, or unwanted behaviours can occur.

Commands protocol

Responses protocol