Web Master's Note: This article was originally written for games played on a computer bulletin board system (BBS). For this reason, some of the issues described apply only to that setting. However, most of the advice in this article is general enough to enhance any remote role playing, be it by mail, e-mail or any other medium. And beyond that, the article makes for some fun reading.

1) Getting Set:

First, a GM who wants to run a game should give the name of his game. If there are several games running, and BBS user Sabrtooth wants to run a game of ADVANCED DUNGEONS & DRAGONS (TM) 2nd edition, he should call it "Sabr's AD&D II" game to distinguish it from any other games running concurrently. Or a fancy descriptive title having to do with the story can be used, such as "Sword of Zeldar". Whatever.

This GM should of course PLAN his game ahead just like an ordinary RPG, then place an announcement in an appropriate message-area that he is offering to run such a game. The GM could introduce this game in textfiles stored in a file-area which describes several key things about the game: the game rules used, the story background, details on the character generation method (with the necessary rules for doing this, unless the game is a common one for which all players have their own copy of the rules), and if necessary some details on the combat rules. Ideally, the players in a BBS RPG won't be worried so much about dice-rolling or other "statistics" which occur in a face-to-face RPG. The GM will free up players from any "number chores", however players must still have a clear idea what their characters can and can not do, from looking at the number ratings for their character and how these numbers are used by the game rules.

The GM should collect the names of players who show interest in trying this game. Then, to help start the players, the GM should upload more carefully written textfiles concerning the character generation rules and the general operating rules of his game (e.g. he will only "update" the game situation Thursdays and Sundays, but will answer questions any time), house rules, a textfile representing a character sheet which the player must fill in a precise format, etc. The GM should get the players to generate characters. Again, if the game is well known such as AD&D it may be that most players will already have the full rules at home. For more obscure games, or games with variant rules, the GM will have to write up longer textfiles explaining these rules (especially character generation rules; other rules sections can be covered in less detail. Don't over-do it!)

Character sheets are mostly for the GM's information: at home the GM should make paper copies of character sheets and game notes, and the GM handles all the dice-rolling. For the players, the GM only summarizes combat results once he's sure the players have specified verbally what their characters are going to do. NOW HERE'S THE IMPORTANT PART: Textfiles about the game go into the file-area because they are lengthy. However, the actual GM-player conversations which constitute the game itself go into their own message-area controlled by the GM. Depending on your BBS, the GM must ask the System Operator (SysOp) to open a new message-area (or reassign an older one from an outdated topic). This message-area should have a new title beginning with the letters "RPG:"; in the example above, "RPG: Sword of Zeldar".

2) The Game's Message-Area:

This message-area is now the game area as such, and if the system permits it, the area can pass under the control of the user who is the GM for the game. In this message-area the GM can read, write and even edit messages. Editing messages is useful for several reasons: to delete old messages having to do with the game set-up before anything is played, to eliminate statements irrelevant to the game ("Hey, did you see that new movie..."), and in general to present a "cleaner" message-area in case a newcomer wants to join and has to read the game so far.

The GM draws up an official list of the users who can play in his game; these gain access to that particular message-area where they can both read and write messages. If the system permits, the GM can actually specify who gets what kind of access, or he may have to get the SysOp to set this up. A "spectator" is any system user not in the game, who has access to that message-area only to read the messages but not to write in it. Role-playing games have never been much of a spectator sport, but even a spectator can have fun reading the messages (which, in a BBS RPG, tell an ongoing science-fiction or fantasy story).

In this way, the GM can "control" his game by controlling the message-area. After characters have been generated by the players, the GM kicks off the game by leaving a descriptive message about what happened to the players' characters to get them involved in this story, and the players respond to it by saying what they will have their characters do next. Where necessary, if the GM has a particularly long description to do, he can write it up as a textfile, store it in the file-area and mention this fact to the players.

Here are some general principles to BBS RPGs:

1. Give a clear title to the game and the message-area to distinguish it from any other game, e.g. RPG: PARANOIA (TM), or Draconian's Dungeon of Dreadful Denizens.

2. Give titles to your messages and files which clearly hint at the content of the message, e.g. PARCHRGN.TXT for the character generation rules for a certain PARANOIA variant, "PARANOIA: Character Generation Rules" for a message announcing that the textfile on this topic is available, or "Slip-R-EEE hides in shadows" for a message during play where the player of the PARANOIA character "Slip-R-EEE" describes what Slip-R-EEE does next...

3. KEEP TO THE SUBJECT OF THE GAME in the messages; don't discuss movies or other topics with other users. It is too easy for someone to strike up a conversation, and this leaves a string of messages which has nothing to do with the game. The GM should caution the players to discuss these topics in the other, non- game, message-areas, and maybe even transfer the offending messages to the proper message-area.

4. The GM should submit an official list of players with both their user names on the system and the names of their characters to the SysOp, in BBSes where the SysOp must allow access to users to the game's message-area.

5. It may be possible for a user to leave messages in the game message-area under different names. Sometimes this would be convenient: a user can write under his own user name to ask a GM a question, and under the character's name to describe what he has decided his character will do next. But this would be complicated; the system would have to ensure that only the player of Slip-R-EEE could leave messages under that name, so no one else speaks for his character.

   In any case, the GM will consider a message as a player's official move only if it begins with the name of the character: "Slip-R-EEE will pull the fire alarm..." There is a chance that anything less than a direct reference to the player represents "thinking out loud" by the player, and that should not be considered: "Maybe I ought to pull the fire alarm." "I'll pull it if all the others are safely out of the corridors..." Players should get into the spirit of the game and refer to the characters as living, interesting beings. Don't start messages simply with "I will..."

6. A player or a GM may choose to reply to a given message, but on most systems that is handled by a R(eply) command and it will carry over the old message-title as the title for the new one. If there's a change of subject, this would be inappropriate, and the user should change the title instead of leaving it as-is. Even if an "old" title gets carried along, it may be possible for the GM to edit the titles of messages after they are written.

7. On most BBSes, a user can choose to read only "new" messages (i.e. messages written since the user was last on the system). Depending on the system, this option can be done automatically for a number of message-areas at a time using a command called "quickscan", "newscan" or a similar name.

8. In systems where the players can write messages under their user name OR their character name, the GM can similarly use his user name to talk to the players as players, and a fanciful name like "God" or "Narrator" for messages which describe what happens to the characters next, based on all decisions the users have announced about their characters. To show that the game has officially "advanced", the GM can leave messages or even whole textfiles with titles starting with "Scene 1", "Scene 2", etc.

9. On multi-line BBSes, there may be a "chat area" or "teleconference" where several different users can type words to each other "live". This could be of great use to speed up a certain part of the game, but only if all players are present and the GM writes up a short summary of what happened as a message, after this session.

These principles should help to run a smooth game. If despite everything the players lose interest in a game and it becomes "inactive", the game can be stopped and a different one started in the same message-area. On the other hand, a very active game can have new players join in under the approval of the GM. But remember, the more players in a game, the more inter- player conversations, which may slow down the game as decisions are reached by consensus.

3) Organized Messages:

Here are some hints for helping to organize a game and to maintain a good message-area:

PLAYERS: Players should take advantage of any automatic systems on the BBS which alerts them to new messages in the message-area. Learn the commands to access only the "new" messages or to do a "quickscan" of several message-areas at once. If the system doesn't have anything like this, players may have to keep track of messages by message numbers. Similarly, players should be on the alert for new files uploaded into the system which have to do with the game.

Players should also warn the GM about any limits to their computer which causes problems in following the game. For example, some die-hard Commodore users use only 40-character lines instead of 80-character; a Macintosh user might not have a file-compression utility like ZIP, and so on. It is up to the players to work things out with the GM so that all messages and files can be followed.

PLAYERS MUST READ ALL NEW MESSAGES right down to the end before making any replies. If they reply to some of the earlier messages, new scenes may appear or new points may be raised by other players in later messages which make their reply inappropriate. Stay up-to-date about the game!

GAME MASTERS: The GM should set up his message-area "cleanly". There should not be a string of messages which are disorganized and incomprehensible or irrelevant to the game. The first message in the message-area should explain that there is a role- playing game being played here. The GM may invite people to join in this game. One early message should list the titles of textfiles stored in the file-area which have to do with this game. The GM should use care in designing the textfiles and making sure they cover essential topics. For example:

INTRO.TXT: Game Introduction
CHARGEN.TXT: Character Generation
COMBAT.TXT: Combat Rules (brief)
GEOBACK.TXT: Geographical Background
KYELDAR.GIF: Color map of the Land of Kyeldar
HISTBACK.TXT: Historical Background
SCENE1.TXT: Scene 1, opening scene of the game

Depending on his audience, the GM may not always need to write a whole textfile for a given topic. Update the message as you add more files to the list, and include any file access numbers or the date the file was added, if the system needs that to find a file.

Next, users will leave a string of messages saying, "I want to join your game". The GM can correspond with each player and help players generate characters and answer questions; all the preliminary stuff. Then, the GM should prepare a "character sheet" for each player, written in a standard format and storable as a textfile. Players' character sheets are considered public information to all (unless for example you want to hide "alignment" or other hidden details).

Make the sheets a well laid-out display, readable also in 40-character format. That is, lines which are part of paragraphs are still readable in 40-character, but lines which consist of special statistic lines should not take up more than 40 spaces (e.g. "STR: 16 INT: 12...") There may be a limit to the number of lines in a message, but if there is a "byte limit" instead then the way the sheet is written to accommodate 40-character computers does not take up any more memory. Design a compact "sheet" which fits in the message-area. The GM may also upload character sheets as textfiles, but since character sheets will change during play, it would be harder to upload a new textfile than to edit an existing "sheet" in the message-area. One solution is to keep a textfile of ALL character sheets, one after the other, and edit and replace it only after every logical pause in the adventure.

If possible, the GM should give or mail out to each player some hardcopy sheets relevant to his campaign. He could send out color copies of a map of the game-world, charts summarizing the game rules for skills and combats (but only where permission to photocopy is printed), and other fact-sheets about his campaign.

BEWARE OF SYSTEM CLEAN-UPS, which automatically erase messages beyond a certain age, or erase the first messages after the message-limit to a message-area is reached. Depending on the system, the GM can make important messages like the game introduction and character sheets "permanent" and not subject to the nightly clean-up no matter how old they are or how low in the message stack. If not, he could find a way to back up a copy of the message contents as a file.

GMs should not, however, be afraid to delete old messages which have outlived their usefulness, such as discussions with players in the course of generating a character (only the final character sheet is important). This would maintain a clean and concise message-area for spectators to read through quickly and easily. In any case, always assure players that messages are deleted only after they have been acted upon.

4) Setting the Pace:

You may have a BBS RPG that's well set up technically, but it may still fail because the game "bogs down" if the proper pace isn't established. RPGs played by BBS depend heavily on how interesting the GM's descriptions are. One important factor is that the GM must advance the game regularly at some agreed-upon frequency, say, twice a week. He may log on more often and even answer players' questions every day, but the actual frequency of the game "updates" should be regular so that players know what to expect and will respond in that time-frame. If a player can't leave messages that often or misses a few times, then the GM must run that player's character as an NPC at those times.

The GM must also keep things interesting by not waiting for every little decision on the part of the players. In a face-to- face game, the constant two-way communication makes it easy to specify every little detail, but this is not the case in a play- by-BBS game. The GM must go ahead and act based on what the players have specified are the "standing orders" for the characters (how that character would act during combat, choice of weapon, the level of trust toward strangers, etc.) The players may lose a little control over the details of their characters' actions, but this will free them from small routine decisions and allow them to concentrate on the really important game situations. The faster pace will in the end make things more fun for the players. Compare the following:

WRONG WAY:

GM: O.K., 20-foot-long corridor ends in a door. It is locked.

FILKSONG DEMONBANE the PseudoPaladin (1 week later): I have a bad feeling about this.

MICHAEL WILSON the Thief (5 days later): I can unlock the door. Let's see, I have Pick Pockets at -7%, Find Traps at...

GM (4 days later): You manage to unlock the door. But everyone give me a marching order to confront anything on the other side. (2 weeks of debate follow)

FILKSONG: Okay, we're arranged. What do we see?

BETTER WAY:

GM (all in the same message): You walk carefully along this dank stretch of corridor. Rats and even smaller shadowy things scuttle away from you on the dimly-lit floor. Ahead you see a standard-sized door with a rusted lock. "I'll handle this easily," boasts Michael Wilson the Thief. He fits a standard lock-pick to the lock but howls in pain as a spark flies across onto his fingers. He's burned <>

Sobered, the other characters bandage Michael's hand and steel themselves to open the door. <> As they open the door, they are startled by the face of a terrible, slimy Mugrunk Beast which shrieks at them!

What do you do next?

(The players then give some "standing orders" like the positioning and preferred weaponry of their characters, and describe the characters' standard attack form, maneuvering, and special actions which they specify if something changes. This may take the form of "contingency planning" or "if...then" statements such as, "If the Mugrunk limps away, my character Filksong won't pursue but will lob arrows into its back..." The players should try to think ahead; the more they think of various contingency plans, the easier it is for the GM to run combat and the GM won't have to slow the game down asking for details later.)