Building: Basic Building Instructions
Introduction
This document is intended as a beginner's guide to building on MusicMUD, the Cryosphere's MUD engine. It will explain enough about the internals of MusicMUD to allow you to understand the rest of the documentation.
Target Audience
This document is intended to be read by people who wish to build on the Cryosphere, or who are interested in experimenting with the MusicMUD engine.
If you fall into this category and you don't understand the contents of this document, then it is too complex. This is a bug - please report it.
Test site
This advice really only applies to the Cryosphere : if you are running your own MusicMUD this sort of decision is up to you!
The Cryosphere would typically run three copies of the mud simutaneously - "Live", "Test", "Dev". Live is the main mud and is designed to be 100% stable.
Test is a staging instance, which will be used for testing the exact release that is planned to become the new live.
Dev is where building takes place and is designed to be 90% stable. It may significantly advance. When it is time to upgrade, a release of the MUD will be cut from dev, and then deployed to Test. We will then test on Test. Fixes may take place. When it is deemed suitable Live will be updated to the version then on Test.
Note that on account of the server migration we are currently operating with a nonstandard arrangement. Live is on our old host, and our new host features "Staging", which is intended to become the new Live soon.
All building should usually happen on Dev. If you notice a minor bug on Live which you are able to fix, you should do so on Dev. If you feel the bug is important enough to be fixed now, instead of at the next swap, tell someone and it will be transferred over.
MusicMUD Structure
Everything is an object
Everything in the game is an "object". A player is an object, a mobile is an object, scenery is objects, items you can carry are objects. Some more quite abstract things are represented as objects as well; but we'll save that for later.
The key thing here is that is no fundamental difference between a player, a mobile, a room or a door. All in-game items you can interact with are "the same". They vary by the properties and flags that they have.
Properties
The data about an object is stored in properties inside that object. Properties are (usualy) small pieces of data associated with a named "key". Properties can be of several types.
Strings
A string is some text. For example, the description on an object is held
in the "desc.internal" property. You can see that by typing "stat object desc"
Our colour codes are described here. Note that some of them are semantic tags, as we allow user colour scheme customisation.
Ints
Int is short for integer - a number.
Flags
Flags aren't properties. You can't use "change" or "delete" on them. You need to use the flags command on them
Arrays and maps
MusicMUD 3.2 has support for more complicated separate being properties; this was being migrated from an earlier
system where you could set a list using properties called, for example auto.count set to 2 and
auto.0 and auto.1
to the first and second elements.
Instead, you would now set auto to an array as follows: [{"item": "item_id"}]. These
properties use a
well-known format known as JSON.
Tree structure
All objects have a single owner (or "parent", if you prefer). This determines
where in the mud the object appears. The owners are also objects and
therefore have an owner. The only exception to this is the "@musicmud" object
which is at the "root" of the tree. An object can have many "branches" (or
"children") below it.
Zones
Typically, @musicmud contains zones, zones contain rooms and rooms contain
objects. Objects can also be containers (imagine a box) and contain more
objects. A zone is a single, autonomous, area of the mud. For example, level
2 of the station has its own zone, as does Livingstone city.
We overload the word "zone" to mean two things currently... both in the sense of containing; but also every object has a property "zone", which is which zone owns it for the purposes of saving, loading, and resets. This may be different from the zone in which is is physically located. We are considering replacing one of the usages of zone.
Make
The "make" verb makes new objects using a menu system. It asks you questions about what sort of object you want.
Boot
The "boot" verb removes objects. Be careful, once it's gone, it's gone. You must never, ever use boot on static objects on the Live site. This will result in grevious retribution from the admins. Our only undo is source control.
Displace/Goto
These commands move objects around in the mud. They have a number of sanity and security checks so you can usually use these with impunity and not worry too much.
Set/Unset
"Set" changes the contents of an object's properties. It knows what properties are strings and which are numbers and contains enough sanity checking to stop stuff getting too broken. "Unset" will completely remove a property from an object. You won't be able to set/unset everything, but this should be more than adequate for building purposes.
Unreset
When you move or change the state of an object, it will be automatically returned to its original state and position following a reset. Unresetting and object will 'fix' it in its current state and position, and regardless of what happens to it, it will always return to its current state and position when reset.
Chint/Chstr
There are some properties which "set" doesn't know about, or does know about but has security and sanity restrictions and therefore won't let you modify. Chint and Chstr are lower-level commands and contain very few sanity checks. You shouldn't need to use these commands (indeed, you may not even have access to them) - use set instead. If you find something which set can not do, submit a bug report.
Chown
Chown is a low-level command used for moving objects around the mud. It has fairly high level restrictions, but it doesn't do anything useful you cannot do yourself using displace or summon.
Delete
Delete is the low-level counterpart to unset, which will remove any attribute from and object. This can potentially cause serious damage, and so in general you should be using unset.
WebMake
[FIXME: document it when it's done :) ]