The BYOND MUD Engine

A library to quickly generate online inhabitable "rooms".

Contents

Introduction

Mud

proc

WelcomePlayer()

WelcomeNewPlayer()

GotoStart(mob/Player)

StorePlayer(mob/Player)

SavePlayer(mob/Player)

RemovePlayer(key)

LocateRoom(roomid)

var

repop_period

roomtypes

actiontypes

room

var

roomid

north_exit

south_exit

east_exit

west_exit

population

repop_delay

action

var

udesc

desc

odesc

hidden

proc

Action()

SetName(Name)

exit

var

dest

blind

teleport

logout

export

var

address

password

designer_genes

This is the backbone for a basic Multi User Dungeon (MUD). The world consists of a network of interconnected rooms in which players can interact with each other and the virtual inhabitants. It supports a lot of on-line creation/configuration but is also intended to permit easy integration of new code.

This library does not define a combat system. Everyone has their own opinions about how that should work, so you get to define that part yourself! Using this library will help you get straight to game issues without having to develop basic save/load and administrative features first.

The main data types defined here are /Mud, /room, and /action. In addition, /obj/designer_genes is defined to provide "builders" the ability to modify the world.

Custom types may be defined under /room, /action, /obj, and /mob. These will automatically become available to builders using the various creation verbs (new_room, new_action, and new_object).

As a convenience (when starting a new world or taking over an old one) a player running the mud locally (in Dream Seeker) will automatically be given "designer genes".

Multi-server worlds may be created by linking several MUD servers together. This is done by creating an export action to send players to another server. The remote world must have a matching import object to permit the transfer. The import object can restrict access via password, address, both, or neither.

Rooms may be created at run-time or defined in the code. Run-time rooms will be automatically assigned a positive numerical id. Coded rooms may either be hard-coded (negative room id) or soft-coded (positive room id). Hard-coded rooms will not be stored in the mud save file and therefore any changes made to them at run-time are only temporary. Soft-coded rooms, on the other hand will be written to the save file, so run-time changes will be preserved (but future code changes to them will be ignored).

Links between coded rooms may be specified via room id or type. If room types are used as links, only one instance of the target type should ever be made (so remember to remove them from the roomtypes list so designers don't re-use them). A room that is targeted in the code but that is not pre-assigned an id will be implicitly created and assigned a unique positive id.

Rooms may be linked together using built-in directional exits (north, south, east, and west) or custom action exits.

Room population lists contain object types that are created whenever the room is "repopped". You can use custom types defined in the code, or you can modify objects at runtime and add them to the room's "pop" list.

The /Mud data type handles various system-wide operations, such as saving/loading the world and individual players. There is a single global instance of /Mud in the variable mud so you can easily access its procedures and variables.

See also:

LocateRoom

Format:

mud.GotoStart(mob/Player)

This is called automatically when a player logs in, so you may never need to explicitly use it. Here's an example where it may come in handy...

Example:

See also:

SavePlayer

RemovePlayer

logout action

Format:

mud.StorePlayer(mob/Player)

StorePlayer() writes a player to a savefile and deletes the mob. By default, this happens automatically when players logout, so you only really need this if you override that behavior.

Example:

See also:

StorePlayer

RemovePlayer

logout action

Format:

mud.SavePlayer(mob/Player)

SavePlayer() writes the player's savefile. By default, this only happens in StorePlayer(), which is called when the player logs out, and which destroys the player's mob in the process. If you are worried about game crashes, you could save the player more often.

Example:

See also:

StorePlayer

SavePlayer

logout action

Format:

mud.RemovePlayer(key)

RemovePlayer() may be used to destroy a player's savefile.

Example:

See also:

room

Format:

mud.LocateRoom(roomid)

This may be used to turn a roomid or room type into a reference to the actual room.

See also:

WelcomeNewPlayer()

This procedure is called when a player logs in. By default, it displays a simple welcome message.

Example:

You could make it display a "message of the day" from a file, play a trumpet fanfare, or anything you want.

See also:

WelcomePlayer()

This procedure is called when a player logs in for the first time (ie they do not have a savefile). By default, it displays a simple welcome message.

The following example makes this behave the same as the normal welcome message.

Example:

See also:

repop_delay var (room)

Default value:

1000 (100 seconds)

This is the time (in 1/10ths of seconds) between repop cycles. Individual rooms may be set to repop every cycle or less frequently.

This is a list of all room types that may be created by builders at run-time. By default, all room types defined in the code are in this list. If you create any that are for one use only, you should remove them from this list.

Example:

This is a list of all action types that may be created by builders at run-time. By default, all types defined in the code are in this list.

The room data type is derived from /area. Rooms are the containers in which everything takes place. They have built-in directional exits (north, south, east, and west), which may link up to other rooms. In addition, you may add any number of actions and creatures or items.

Rooms may be created in the source code, or at run-time using designer genes. The value of roomid for a particular room determines whether changes made by builders at runtime are saved.

Example:

Each room has a unique numerical id. Hard-coded rooms have a negative numerical id. Run-time changes made by builders are not saved for hard-coded rooms, allowing them to always be directly affected by changes to the code. Soft-coded rooms have a positive numerical id. Run-time changes are saved and therefore future code changes to such rooms may be overwritten by the savefile information.

The special id 1 is the default starting point for players.

See also:

exit (action)

The built-in directional exits link one room to another. The arrow keys may be used to move into a particular exit. You can also click on the exit in the View panel or type its name on the command line.

Example:

In the code, room exits may be assigned to room ids or room types. This is one of those cases where you can take advantage of DM's "relative path" notation to refer to other room types. We could have replaced .Lamp_Post with an absolute path /room/Lamp_Post, and it would have the same effect.

See also:

repop_delay

This is a list of object types that get created in this particular room.

Example:

See also:

population var (room)

Default value:

2

Every repop_delay cycles of repop_period, the contents of the room is restored. Only items that have been destroyed are re-created.

The /action data type is a special type of object that adds a verb to the room in which it exists. The object itself is invisible to ordinary players--they just see the verb.

While you are free to add verbs directly to rooms in the source code, actions have the advantage of runtime configurability. They also show up in the View panel (unless you hide them), which makes it easier for players to notice them.

In the source code, actions are typically created in the room's New() proc. You can also create them at run-time using designer genes.

Example:

There are several types of pre-defined actions (including the logout action demonstrated above). You can easily define new ones in the source code.

Default value:

0

Setting this to 1 will cause the action to be removed from the View panel. It is still accessible as a verb.

See also:

desc var (action)

odesc var (action)

This is the description seen by the user alone when executing the action.

Example:

See also:

udesc var (action)

odesc var (action)

This is the description seen by everyone (at the original location, in case that changes) when executing an action. It is preceded by the name of the player when displayed at run-time.

Example:

See also:

udesc var (action)

desc var (action)

This is the description seen by everyone else other than the user (at the final location, in case that changes) when executing an action. It is preceded by the name of the player when displayed at run-time.

Example:

To change the name of an action, you cannot just set its name variable directly. You have to call SetName(). This renames the verb attached to the (invisible) action object.

This procedure is called when a player executes the action. You only need to override it if you are defining a completely new type of action.

The following example defines a type of action that is visible to everyone in the world, as opposed to the normal actions which only operate within the same room as the user.

Example:

See also:

blind var (exit)

dest var (exit)

north_exit var (room)

Exit actions are for special types of room exits that do not work as simple directional exits. That might just be because you want it to have a different name, or because you want a description to be displayed when the user uses it.

Example:

See also:

teleport exit

dest var (exit)

Default value:

0

Setting this to 1 causes the exit to be "blind". That means the destination of the exit will not be displayed in the View panel as it is for normal exits. This is the default behavior for "teleport" exits.

See also:

blind var (exit)

dest var (exit)

This type of exit is "blind" by default. That simply means that the destination of the exit is not displayed in the View panel as it is for normal exits.

See also:

blind var (exit)

north_exit var (room)

This is the location where the user will be moved after executing this action. Like the built-in direction exits on rooms, this value may be assigned to a room id or a room object type.

For an example, see /action/exit.

The logout action writes the player's savefile and logs them out of the game.

The export action sends a player from one world to another. The target world must have a matching import action.

The following example creates a bi-directional link between worlds that appears to the player to be almost just like a regular exit from one room to another.

Example:

This is the network address of the target world where the player gets sent.

This is the authentication password used by the remote world to limit player imports to only authorized senders. If the import action does not specify a password, this is, of course, unnecessary.