ON POSSIBLE CODING APPROACHES [PAGE 2]

ON THE MATTER OF THE INTERNAL CHRONOLOGY

ON THE MATTER OF BUILDING

ON THE PROBLEM OF GREETING STRANGERS BY NAME

ON THE MATTER OF MUTTER

ON ATTACKING THE PROBLEM OF SITTING IN A BAR ALL DAY

ON THIS PAGE

ON CUSTOMIZING YOUR CODE [Guest Speaker]

ON REINVENTING THE WHEEL [Guest Speaker]

PAGE 3

ON POSSIBLE ATTRIBUTES TO INCLUDE IN A FINGER COMMAND

ON THE MATTER OF LANGUAGES

Send feedback on these pages HERE .

CUSTOMIZING YOUR CODE

NOTE : This material was kindly contributed by Rhonda Peters , aka Saidar@Tales_of_Ta'veren Mush.

The servers in the MUSH family (MUX, PennMUSH and TinyMUSH) are very generic. On the one hand, this is one of their strengths, as it allows each game created with that server to have customized coded commands that meet the needs of that specific game and its theme. On the other hand, it means that you have to give some thought to what your game needs and figure out how to provide it.

Terms
-------

It may be helpful to begin by defining some code-related terms.

Hard Code: Hard code refers to the server, the program that runs the game itself. The basic commands like "say" and "look" are a part of the server and are common to all games that use that server. The server code is written in a programming language like C, and then compiled to make an executable file. If you know the programming language, it's possible to modify the uncompiled source code. Modifications could be as simple as changing the text output you see when you type a command like @chown, or as complex as adding in your own commands or functions. Theoretically, well-programmed changes to the source code will run quicker and more efficiently than doing the same commands in soft code.

However, there are some issues to consider before you modify the source code. New versions of the servers come out fairly frequently. To upgrade to a new version, you'd have to go in and make your hard code modifications again. If you no longer have someone on your team with hard code knowledge, you'll have to choose between continuing with your old server version or losing your custom commands when you upgrade. MUSH servers are complex pieces of programming, unless you're very confident in your programming skills and take the time to familizarize yourself with the server, it's probably safest not to make hardcode enhancements.

Email lists for hard code hacking and some of the servers are available, there's information on this page:

http://www.pennmush.org/~talek/mushinfo.html

Soft Code: Soft code is code created with the programming language built into the server, and implemented from within the game itself. It can be as simple as a short-form command you set on yourself to quickly wave to people, or as complex as a coded system like +mail. A soft code email discussion list is available, there's information on joining on this page:

http://www.pennmush.org/~talek/mushinfo.html

Globals: Global commands are commands that work anywhere on the MUSH and are added on top of the standard server commands. Globals are usually added through soft code, and are often prefixed with a + to make them easier for people to recognize. Commands like +finger and +mail are globals. There's more information on globals below.

Psychocoder: A psychocoder is someone who's adept with soft code and feels comfortable creating complex coded systems like combat or +mail.

How Much Code?
---------------------

Before you begin adding code to your game, you should spend some time thinking about what kind of code and how much of it your particular game will need. These are some of the issues to consider:

* Code Resources

It's very important to consider the resources you have now, and that you're likely to have in the future. Even if you're going to have minimal code and use systems that are publicly available, your admin team needs at least one person who is competent with code to install and maintain those. It's probably safest not to look at creating a lot of custom code unless you have at least one psychocoder available. Even if you have one now, make sure you have a contingency plan in case s/he resigns before completing the code, or isn't there in the future to maintain it. Coders are often in short supply, don't assume that you can just post an ad on a newsgroup and instantly find a replacement if someone retires.

* Efficiency

If you have a lot of complex coded commands, it can affect the speed at which your game runs because the server has to do a lot more computations. This is even more of a factor if your game has a lot of players or runs on a machine with low resources. Excessive or poorly coded commands can result in lag in those situations.

* Nature of the Game

When considering your code needs, keep in mind the nature of the game you're trying to create. If your game is one with an emphasis on consent role-playing or with minimal conflict, it might be a mistake to devote a lot of time and resources to coding combat and chargen systems. If your game is one where characters have abilities that can best be reproduced through game effects, your players might expect or want to see those coded.

* Theme

Would your chosen theme be better served by having some aspects of it coded into the game? For example, on a Babylon5 MUSH, players might expect to see a communications system like the BabCom. Some Pern MUSHes add a command like +pair that will tell the user who the rider of a specific dragon is, which can be a handy RP aid.

Globals
~~~~~~

Whatever the nature of your game, you're going to need at least some globals.

The Master Room
----------------------

To make a command global all you do is drop an object coded with the command into your master room. For TinyMUSHes, the master room is set up in the MUSH configuration file. Kynn Barlett has created a sample, annotated .conf file for people to look at as an example of what you can do in the .conf.

ftp://ftp.idyllmtn.com/pub/mud/mushcode/Kynn/Config/default.conf

Here's a few general tips for keeping your master room efficient:

* ONLY keep coded commands in the master room. Separate out non-command information like help files onto separate objects. Keep those objects in another room, or store them within an object in the global room. Every time someone types a non-standard command the game will search everything in the global room to see if there's a match to the command. You can help the game run more efficiently by storing non-command stuff elsewhere.

* Keep your master room secure. Keep it floating, and don't set it jump_ok. The only people you want to allow in the master room are wizards. The master room on Tales is set to check everyone that enters for the W flag. If you don't have that flag, it kicks you out.

* Don't hang around in the master room. The master room should not be used as the wiz hangout. Anyone who goes into the master room should be uselocked, or the commands set on the player will act as globals while he's in the master room. (Wizards should always be uselocked, anyway.)

* Make periodic @decomps of your globals, and give a copy to more than one admin for safe-keeping. Even if you make backups of the entire game, accidents can happen. There have also been instances where admin have gotten angry and destroyed things when they've quit a game. Information on how to make @decomps is available:

http://www.dreslough.com/dee/MUSH/decomp.html

What Globals Do You Need?
------------------------------------

While some of your globals may be customized to your game's individual needs, there are commands that the majority of MUSH players will expect to see on pretty much every game. Unless there's a reason why these would not be suitable for your particular game, you should probably have these. The good news is that versions of these are publicly available (see next section), you won't have to code them yourself unless you'd like to.

* mail

A mail or messaging system that allows people to communicate with each other even when they aren't online at the same time is very important. MUX comes with a mail system, but the other servers need to have mail added as a global. BrandyMail is probably the most popular publicly available +mail system, and many players are familiar with its use.

* finger

+finger returns basic information about a character, and is used a lot by players. The information included in +finger varies from game to game, but usually includes name, gender, alias, current location, date of last connection and character position. It may also include email, WWW page, short description, whether the character has unread +mail, plan/quote (a space for a player quote or statement) and vacation (place to note planned absences).

* bulletin board system

Bulletin boards allow players to communicate with the whole game to post TP announcements, job openings, etc. Most players find these very useful as a way to get in touch with lots of people easily, and keep up-to-date with what's happening on the game as a whole. Myrddin's +bb system is pretty popular, and is available at:

http://www.best.com/~merlin/mc.bb.html

* communication system

Not all games install comm channels, but most do. Players enjoy these as a way to talk OOCly, and they can be useful for giving groups like factions or areas a more community feel, or as a way to get questions answered, etc. However, some players feel channels are disruptive to RP, so there are cons to consider before installing these.

* +where

Also called +ppl and other things on some games. This command lists the location of all players not set UNFINDABLE, so people can find where others are gathered for RP.

* +staff/+admin/+wizards/+helpers

A command that allows players to list who's available to help with questions is very useful.

* +help

The documentation for global commands is customarily available via the +help command. Great code isn't very useful if people can't figure out how to use it, so good, clear documentation for all of your globals is vital.

These globals are fairly wide-spread and many players like to use them, but they aren't universal and might not be appropriate for a particular game.

* Places/Tables

This global allows room owners to set up virtual locations in a room, like tables in a restaurant, benches in a park, etc. Players using Places can simultaneously hold private conversations with others in their Place and public conversations with everyone in the room. Places are pretty popular with players, and can mean a reduced need for rooms and objects on a game.

* +view/+detail

These allow players to set and view expanded descriptions on rooms, objects and/or themselves. For instance, someone might set up a +view of a painting in a room, or a ring on themselves. This is useful for the MUSH because it'll cut down on the need people feel to create objects just to give them @descs people can read.

* mp/multi-page

A command that allows people to page more than one person at a time is very useful and much appreciated by players.

* mutter

Mutter comes packaged with the Places code. Mutter allows people to whisper something to another with a chance that others in the room will overhear portions of the conversation. The majority of MUSHers use and enjoy mutter, but there is a minority who find it irritating and believe it should be RP'd, not coded.

* +time

If your game has its own calendar or runs on accelerated time, it's handy to provide a command players can use to figure out what the current IC date and time of day is so they can incorporate that into their RP.

* +compass

The +compass command displays a compass rose or similar graphic that shows the direction of the exits out of the current room. (This only works if the exit is setup with directional aliases.) Some players find this helpful for navigating the MUSH landscape.

* ooc/ic

Some games implement "flags" to indicate when a character is in IC or OOC mode. The player sets the current mode through use of ic/ooc commands. On other games, an 'ooc' command is used to make an OOC say or pose to set it apart from RP, like this:

[OOC] Bob says, "I'm just acting in character, I'm not really mad at Tom."

* Login Watcher

A fair number of people like to know when others are logging on or off so they can watch for their friends. Some games implement a system that will announce logins to everyone on the game, or set up a login channel on the comm system people can join if they want to see when others log on or off. Some people want to know this badly enough that they'll code their own version if it isn't on the game. (If you put up a login watcher system, make sure it's optional, since there are also people who don't want to know and consider it spam.)

* Multi-Descer

A lot of people like to be able to change their characters' clothing for different RP situations. A multi-descer allows people to store and set different descriptions for themselves. A lot of people will code their own or port one over from another game, so some MUSHes find it easier to just provide a multi-descer as a global, or as parent code in a free code room.

* Multiple Guest Switcher

The TinyMUSH server allows a game to designate more than one character as a Guest in the .conf file. However, it does not dynamically switch between these, players have to log into the different guests using the correct name and password. Since most people type 'guest guest' to connect to a Guest character, you can end up in a situation where you have more than one person inhabiting a guest body at the same time. Some games install soft code that will dynamically switch between the guests, so that if Guest1 is occupied, the next visitor to connect is logged into Guest2, etc.

* Coder Globals

There are a handful of globals designed to make coding a little easier. These are:

+cpattr - copy an attribute from one object to another

+mvattr - move an attribute from one object to another

+pairs - check that all the brackets are closed in a piece of code

+grep - search an object's attributes for a particular string

+scan - search an object for a $ command matching a string

ON REINVENTING THE WHEEL

NOTE : This next chapter is principally aimed at helping you avoid "reinventing the wheel" for the umpteenth time in your coding, by listing places where other people's solutions to a wide range of problems have been made publicly available. These listings and explanations were also provided by Rhonda Peters , aka Saidar@Tales_of_Ta'veren Mush.

Publicly Available Code
-----------------------------

Over the years, a lot of coders have released their global code for public use on any game. You may want to begin by seeing which of these systems might meet your game's needs, as it would be faster and easier than coding everything you need from scratch.

Kynn's MUSHcode Index	http://www.idyllmtn.com/~kynn/mushcode/
Kynn's index allows you to search for and download publicly-available MUSH/MUX code. It includes code for comm channels, dynamic space, bulletin boards, security cameras, and a host of others. There are also links to list all the indexed code by category, author and name.
M&E; MUSHcode Archive	http://gargoyle.uhall.du.edu/mushcode/
M&E;'s archive includes a brief description of each code object, as well as a link to download a copy. Most of the objects are global or admin code, but there are others as well. The global code includes +chat (a comm system), +detail and +view, a multi-descer, a multiple guest system, +help, +pairs, Places & Mutter, a weather system, +where and several others.
Living Fiction's Globals	http://www.dreslough.com/dee/MUSH/globals.html
A copy of the globals used on Living Fiction MUSH is available for download from this page. Globals include +finger, +where, +suggest, +poll, and a few others.
MUX-in-a-Minute	http://www.amtgard.com/~marvin/#MIAM
The MUX-in-a-Minute package includes a number of globals, allowing MUX admins to quickly set up the basics.
Myrddin's MUSH Code Repository	http://www.best.com/~merlin/mushcode.html
Includes Myrddin's very popular +bb system, a newsformater and a mushcron.

Code and Command Reference
~~~~~~~~~~~~~~~~~~~~~~~

Wizards have access to additional commands, and some standard commands may work a little differently for wizards. Even if you're an accomplished coder, if this is your first time as a wizard, you should familiarize yourself with the wizard commands.

Non-coding wizards should learn the basics of general and wizard commands, and be careful about command use until they've done so. For instance, if a wizard does a very broad @search on a large and busy game, it can drag the game to a halt for several minutes. Wizards have the ability to @chown, @link and @dest anything, regardless of who owns it.

The following are useful resources related to code and commands: