8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / C64-128BBS / FRPDOC.TXT < prev next >

Wrap

Text File | 2019-04-13 | 27.3 KB | 617 lines

FFRP.BBS DOCUMENTATION FILE ------------------ Fantasy Role Playing BBS Designed by: SpLiTiNfInItY INTRODUCTION One interesting activity which has developed on BBS systems in recent years has been a special type of game playing known as Role Playing Games. In fact, sometimes these games of Dungeons & Dragons or Traveller become so popular they earn their own sub-board. In other cases, the SYSOP disallows these games because they cause the message base to fill (or scroll) too rapidly. It was during one of these denials from a SYSOP that insperation struck. The BBS was very popular and a group of users decided to get a game of Dungeons and Dragons going on one of the sub-boards. Immediately the SYSOP put a stop to it, saying that the message base would scroll to quickly, and that his BBS just wasn't the place for it. This was all probably true, but it did get me thinking; thinking of what place WAS right for it. That night, at about 2:00 am I began working on a BBS program totaly dedicated to Role Play Gaming. I was motivated enough to work straight through for two days until a fairly operable version was up and running. The program was fairly crude from the storage capacity stand point. I had expected a limited response, assuming that only a small percentage of the BBS users in my area were playing Role Playing Games. I was wrong. The instant popularity over-ran my program. The user log overflowed in a week and the message base capacity proved fairly limited. But the board itself, the concept, was a hit. So, during slow hours (which were few), I began work on a more powerful version of the program. Nearly a year later I decided to re-write it once more, from the groud up and release it into FREEWARE. This version of the program is much more powerful than my first, but a bit less powerful than my second. The trade off for power, is the ablity to handle information easier with less work from the SYSOP. The older versions required various mantiance programs and wasn't suited for any other but the program's author (me). Secondly, this version can work with a variable drive configuration, whereas the earlier ones were stuck with my setup. Overall, the look and feel of the program has changed little. FRP.BBS is designed to let users run Role Playing Games effectively using a BBS as the media. Each game which is running has it's own private message base and files. Users can become Game Masters and form their own games, and/or be players in other games. The program is not just a modified BBS program, but a totaly dedicated, built from scratch, program for Role Playing online. Various tools and files allow Game Masters to run their games easily in a BBS environment. Needless to say, a knowledge of Role Playing Games (RPGs) is a prerequisite for a SYSOP of this BBS, as well as any Game Masters. But because RPGs are easy to learn from a player standpoint, many users who have never heard of Dungeons & Dragons can jump right in and start playing with only skimpy rules and concepts. Role Playing on a BBS has distinct advantages vs. the normal method of playing: in person. Because a game of D&D may take several days to complete even one adventure, players cannot always meet at the same time. Using this program, players and Game Masters can communicate their turns at their convenience. Generaly there is a set turn rate, maybe once a week on firday, or whatever. Using this method, players can discuss their move for the week and then let the party leader give the GM their decision on friday. The following monday the GM will have the results of their actions posted and the game continues. This is obviously a much slower process, but with some small modifications to the rules it works fine. Suggested modifications will be discussed in due course. Some games do move faster by having turns every-other day. This is sometimes a frantic pace, but these are usually less involved games with fewer players. THIS DOCUMENTATION FILE This file will give you the important information you need to operate FRP.BBS. Information on such things as Role Playing Games and running a BBS will not be covered, as they tend to be a prerequisite for this program. Not all functions of the BBS program are covered, but instead, the general flow of operation is explained. That is, how games are formed, run and carried out. You will have to play around with the program to see how it actualy operates. Lastly, some techinical information for programers will be discussed. EQUIPMENT NEEDED FRP.BBS works with the following: Commodore 64, Commodore 128 (In C64 mode) 1560, Westridge, Totaltellecomunications (modem64) modems (or compatible) Up to 3 disk drives as follows: 1 single 1541 disk drive (or MSD SD-1) 2 1541 disk drives (or MSD SD-1s) A dual disk drive such as the MSD SD-2 SFD-1001, 8050, 8250 drives will work as well A third drive is supported for special file storage called CHRONICALS, explained later. If an IEEE interface is required locate it under ROM. If a driver is needed, it can be located from $ce00 up. A printer is optional. It must be serial, device 4. NOTE: Modems using negative line control or no line control are not supported, such as the Mitey Mo, Commodore 1660 and Hayse. (future version might!) FILES NEEDED: 1] FRP.CREATOR This program allows you to set up the BBS files and change various aspects of the BBS as necessary. 2] FRP.BBS is the main BBS program. 3] SHORTML is the machine language routines used by FRP.BBS. FRP.BBS will load in SHORTML when it is RUN. These files should all be on one disk, but this disk is not to be the main storage disk of the BBS. The disk which the BBS program will use is called the SYSTEM DISK. The SYSTEM DISK will be the one in the drive when the BBS is running, and will NOT contain any of the three program files (for sake of disk space). FRP.CREATOR Load and run this program first. Press any key to move from the title pages to the functional part of the program. Much of the information you will be giving will require that you have read the rest of this documentation first. The FRP.CREATOR will write a file to the disk when you are done using it. For this to happen you must exit the program with the EXIT PROGRAM menu option, not just by turning off the computer! FRP.CREATOR will also write out the help files. This was done so that you would not have to download a large amount of files. You can return to the FRP.CREATOR program later on and change original settings, but some of the DRIVE CONFIGURATION settings should never be changed once they are set and being used. These will be discussed. RUNNING FRP.BBS After setting up the BBS with FRP.CREATOR, load in the main BBS program and run it. Make sure SHORTML is on the disk when you run the program. After it loads in the machine language you will see the title page (creative isn't it_). This is when you switch the PROGRAM disk with the SYSTEM DISK. Hit RETURN after doing so. WAITING FOR A CALL The display which follows is where the BBS is waiting for a caller. You will see several windows holding various information and menu selections. The menu selections only operate while this screen is being displayed. When you first get to this screen you will be asked for the DATE and TIME. You will also be asked for the date and time if you go to TERMINAL mode (upon returning) because TERMINAL mode disables the clock. (NOTE: If the DATE or the TIME is accurate, enter zEROS (0) and they will be left unchanged.) The BBS will be online if your board was set to FULL TIME (from the FRP.CREATOR program). If you have it set to PART TIME, it will be off line. If this is incorrect, just hit L to toggle it. If the BBS is offline, it will NOT answer the phone. A PART TIME board will go offline and online at the speciffied times. Notice the [V] VALIDATE DISK option in the menu. USE IT! FRP.BBS uses SEQ files a lot, and due to tiny errors in Commodore DOS, SEQ files may disappear if the disk is not VALIDATED occasionaly. [F] FAKE RING is used for testing purposes. Connecting another computer directly and using this key will let you see how it works from REMOTE vs. LOCAL mode. The BBS satistics window contains information which SYSOPS like to keep track of. The averages are reset when you stop the program, but the other information is saved on the disk. ONLINE SPECIAL NOTE: LOCAL and REMOTE mode allow for slightly different operation. From LOCAL mode some options are avalible which are not from REMOTE mode. This helps prevent crashing of the program and unathorized use of some sections. Special Control: Messages/files can be ABORTED with the SPACE BAR or CTRL-C. Their output can be paused with CTRL-S with any key continuing. Type Over, and Function Keys: When a user is online, you are able to TYPEOVER them. Also, you can use Function Keys to cause certain things to happen. They are: F1] Give a troublesome user an interesting message! F2] Force a user off the system. F8] Go into CHAT with the user PRIVACY MODE: The left arrow key, at the top left of the keyboard is used to toggle PRIVACY mode. This will blank the screen (not clear it) but leave the volume on. Hitting it again will restore the screen. This only works correctly while a user is online, don't do it from LOCAL mode. If the key seems not to function, hit it repeatidly until it is detected. Chat Mode: When you enter Chat Mode, you will be give this short menu of function key options: F1] Raise user's access F3] Lower user's access F5] Set user's time left to 30 mins. F7] Exit Chat Mode In addition to those, here are the others: F2] "Whatcha' need_" F4] "Go voice, okay_" F6] (clears screen) "Hold on a sec..." F8] "Goodbye!" Because time left on the system is constantly lowered, you may need to use F5 to set it to 30 mins just before exiting Chat Mode (assuming you want them to stay on the system). USERS: You can set the number of users allowed in the FRP.CREATOR program. It is suggested that you use no more than 400, and between 100 and 300 is generaly all you may need. DO NOT LOWER THIS VALUE ONCE THE USER LOG IS STARTED. (Raising it will do no harm, but lowering it after users have started to logon will do damage to the user file). Users are identified by a USER ID#. The ID# is directly related to their record number in the USER FILE, which is a RELative file. NOTE: ID# 1 is reserved for the System Overlord (or SYSOP). Therefore, you must logon to the system FIRST. Each user has 9 independent access levels. 8 of these access levels refer to their status on individual games being played. The last one referes to their SYSTEM ACCESS LEVEL. For all 9 access settings, there are these values: 0] VISITOR 1] PLAYER 2] CHRONICAL KEEPER 3] LEADER 4] GAME MASTER 5] System Overlord (SYSOP) Access 5 is reserved for the SYSOP only. Each of these levels will be explained in the MESSAGE BASE section of this documentation. All users start at access level 0. As SYSOP you will be validating some users to access level 4 (Game Master). They in turn are responsible for validating users requesting access to their games. This is discussed in the BEING A GAME MASTER section of this documentation. MESSAGE BASE: FRP.BBS contains 9 message bases. Eight of them are dedicated Game Play boards; private message bases on which games are conducted. The last is the Electronic Mail message base. Although the message bases are seperated, the actual messages are stored in a single physical message base, with each message identified by a message base number. In this way Email and Game messages are stored identically. The message base messages are stored in SEQuential files with a single RELative file used as a DIRECTORY KEY. FRP.BBS will store 100 messages per disk drive, for a maximum of 200 messages. 200 messages is a fair amount of storage for this type of BBS program, although a standard social or special interest BBS would certainly require a larger message base. The message base automaticly deletes the oldest message when it becomes full to make room for new ones. Because the individual messages are orginized by a KEY file, they can be looked up and identified quickly. Email and messages sent to a specific user are brought to that user's attention at logon. FRP.BBS keeps track of the highest message number each user has read ON EACH MESSAGE BASE. Therefore, if they logon and then logoff (or drop carrier) they will not lose any NEW messages. They will remain NEW until the user actualy reads them. Each Game Board message base is private. Only the players and the Game Master of that game (and the SYSOP of course) can post messages on their message base. Any user is allowed to read from a message base and see how a game is progressing. A user is given POST access to a message base when their access level for THAT game board is above VISITOR (level 0). BECOMING A GAME MASTER: Now that you have an idea of how user information and messages are stored on FRP.BBS, understanding how games are run will be easier. When you first put up FRP.BBS there will be no OPEN games. You will probably want to get some people to be Game Masters right off, or you may want to run your own game. Here is an outline of the procedure: I Request that users who want to be Game Masters send you a description of their experience and what game they want to run. II Validate selected users to Game Master access (see validating users). Give the Game Masters instructions on how to Form and run their game on FRP.BBS III Game Masters must FORM their game. When they do this, they will be asked to write an advertisment for their game which users can view when decideding which games to join. IV Game Masters will soon get REQUESTS TO JOIN GAMES from players. A response is important, wheather the user is accepted or not. V The Game Master then validates users who he wants to be in his game and adds them to his game's ROSTER. This small outline details how games are set up. Choose Game Masters well, they must be able to handle responsiblity. VALIDATING USERS: As SYSOP you will be validating users to higher access levels. Usualy you will only validate Game Masters and leave the player validation up to them. This method has proven very sucessful and is much easier on the SYSOP. Changing a user's access level can be done in three ways: 1] While the user is online you can raise/lower their access level from Chat Mode using the Function Keys. 2] Using local mode, logon as the user you want to validate. Go to the [U] USER info section and the [S] USER STATS section. In local mode you can change their access level (and handle) from there. From remote, this is not possible. After logging back off their access level will be written to the disk, and because of the way NEW messages are marked, they will not lose them by doing this. 3] Game Masters have limited ablity to raise a user's access level. When they add a player to their game they are asked which level the user should have: 1] Player 2] Chronical Keeper or 3] leader. Of course this only applies to the game the GM is running. COMPONENTS OF A GAME: Each game board has these components: 1] A message base for game play. 2] A Game Bulletin, which the GM creates. 3] A Chronical of the game. 4] A ROSTER of game players. Game Bulletin: The Game Bulletin is like the main bulletin, but is retrieved while in a specific game's message base menu area. The GM can post any vital information here for players. Chronical: The Game Chronical requires a bit more explination. Generaly, a Chronical is a popular enhancment to game play consisting of a record of an adventure's events. Depending on how it is used, a Chronical can be a colorful story which is written as the game's adventure goes along. Usually this is the case, and when a game ends the Chronical is sent out to all the users in a newsletter. Because a single Chronical can be quite long, a large amount of disk space is required. Therefore the Chronical section is optional, and can be disconnected in the FRP.CREATOR program. If it is used, IT IS SUGGESTED THAT AN ENTIRE DISK BE DEDICATED TO JUST GAME CHRONICALS! Players who are validated to Chronical Keeper are generaly in charge of entries in the Chronical, but a game Leader or the GM can also do this. NOTE: Printing of a Chronical requires a SEQ file to PRINTER program, or a TERMINAL program which can do this. The EDITOR in FRP.BBS cannot handle a large Chronical do to memory limitations. Roster: The GM should enter players into his game's ROSTER as they enter the game. The roster will hold the user's handle, ID# and a word or two about their character (such as, FIGHTER or WIzARD). The ROSTER is the best place to find a user's ID# if you have forgoten it. Generaly it is faster than using the [F] FIND USER ID# if you know which game he/she is in. Further, the ROSTER is a necessary tool in keeping track of players and their characters. RUNNING A GAME ON FRP.BBS: It is important that Game Masters have a good idea of how the system works, and how they must modify their game to fit the BBS media. This section will outline some of the basics of running a game on FRP.BBS, but it is up to you to pass it along to the Game Masters. Forming A Game: A game can be formed by anyone with Game Master access, so long as there is an open slot for a game. When a Game Master chooses to form a game he/she will be asked to write an advertisment which players can view. It may be a good idea to outline to potential Game Masters exactly what should be included in the ad. Here are the usual items found in an ad: 1] Title of Game and Adventure 2] Description of Game if it is an original one or an uncommon one. 3] A description of the adventure or if it will be an ongoing game. 4] Wheather player's can bring their own characters 5] A description of how turns will be taken 6] What experience is necessary (if any). 7] What info to include in their REQUEST to Join. Game Status: Each game can have one of these status settings: 1] EMPTY No game in that slot. 2] OPEN A game accepting players. 3] CLOSED A full game, no more players needed. 4] RESTRICTED Only INVITED players need apply to join this game. 5] LOCKED A game which has just ended. All games start off EMTPY. When a Game Master forms a game it is set to OPEN. If he wishes, he can then RESTRICT it. Restricting of games is rarely used except for special events, such as play offs. A Game Master can CLOSE his game when he has enough players to get started. Although a game is CLOSED, a Game Master can still add players, but they will have to REQUEST to Join via. Email. When a game ends, you (as SYSOP) must LOCK the game. When a game is locked that slot will remain unused until you UNLOCK it. While it is LOCKED, players who logon and who were on that game will be notifed that the game has ended, and their access level for that game will be reset to 0. Therefore, you must leave a game LOCKED long enough for all the players to be notified, otherwise they will end up with access to the new game which starts in that slot. How Games Can Be Modified: Modifing games is not to difficult. Generaly a Game Master will need to change two areas of a Role Playing game: COMBAT: Melee would be painfully slow in a RPG on a BBS. So to keep things moving, a Game Master will usually take care of all combat himself. To make it fair, he/she will request a Strategy & Taticts statment from each player which outlines how their character will fight (in general terms). Important battles or large campaigns will usually be fought with a combination of the normal and the modified rules. PROBLEM SIzE: Adventures on a BBS should take on a larger scale than a normal adventure. Small things such as picking a lock on a chest shouldn't be covered, but rather how a particular castle should be assulted. Characters should be in charge of armies rather than just a short sword and a shield. Obviously characters will want to go off in search of fame and fortune, and such adventures will take on a more personal level; this is okay, but should be the exception rather than the rule. Such adventures usualy move to slowly to keep the players attentions and thus the game fails. Email vs. Message Base: Because each game has it's own message base, it should be used. Sometimes a game might seem to move into Email where no one knows much of whats going on. Some games have all their characters seperated with only a few knowing that the other even exists (in game terms). These games work, but are very boring to people watching the game progress. Don't have to many of these types of games going on. One or two would be fine, and maybe interesting, especially when the characters do meet. Managing Games: As SYSOP you will be in overall charge of what goes on. This is a major responsiblity. Mainly you will be explaining how games are run on FRP.BBS to experienced RPGers, and also the concepts of RPG to those who never heard of it. Patience is the key here. Don't expect games to get started right away. It usually takes at least a week for a game to get organized and underway once an ad is up. Try not to let players and Game Masters get in over their head. No one should GM more than one game expecially if they are playing in another! There just isn't enough time for it. Players can usualy get by playing in more than one game, but if it gets over two there will be problems. Closing A Game: When a game is over you will need to do a little housekeeping. First KILL the game so that it will be LOCKED. Next KILL all the messages in the game's message base. The ROSTER will automaticly be killed. Delete the game's bulletin and chronical. Usually the chronical is worth keeping in some form or another, a newsletter is one popular idea. Time On System The biggest complaint from user's will probably be about how busy the line is. Social boards are just as busy, but getting on them is not as manditory as it is on FRP.BBS. Game Masters need time to take care of their game, and players need to get their moves in. Although FRP.BBS is set up to handle Part Time operation, it is not recommended unless you only allow one or two games to be going at one time. SYSTEM MANAGMENT This section will discuss the file handeling portion of FRP.BBS which only the SYSOP has access to. System Files There are 4 system files which user's will be given at certain points in the program: 1] HELLO This is the first message they will see. 2] NEW USER This should explain about FRP.BBS and any rules. 3] BULLETIN The daily bulletin. 4] GOODBYE The logoff message. All four of these you will be reqired to create. A section in FRP.BBS is set up for this. From the [F] FILE section, go to the [S] SYSTEM file area. From there you can create and edit all the system files (and others). FRP.CREATOR will write the help files and a file called WHATDOIDO. WHATDOIDO is a small overview for people who want to join or form a game. You can modify it as you wish, along with the help files. One suggested modification is to the EMAIL menu which includes [O] OTHER EMAIL. Only you can use this function, and you may not want users to be aware of it. NOTE: file names are in lowercase. Text Entry/Editor The editor in FRP.BBS works on a line number system. It can handle 65 lines by 35 characters. The editing functions include inserting/deleting lines. Replacing lines, search & replace and hardcopy. [H] HARD COPY is only possible from local mode and make sure you have the printer hooked up and on! PROGRAM NOTES AND QUIRKS: * You can skip the HELLO and BULLETIN files by pressing the S key instead of RETURN at the appropriate prompts. * There is no other backdoor password other than the one you specify in FRP.CREATOR program in FRP.BBS. * FRP.BBS will send line feeds. Most terminals that do not require them filter them out anyway. * DO NOT CHANGE DRIVE CONFIGURATION after the message base has begun. This DOES NOT apply to adding a drive for the Chronicals. * Setting the number of calls allowed per day to 0 in FRP.CREATOR will allow unlimited calls per day. * If a user is ONLINE when the system is going OFFLINE (for PART time boards only), the user will be informed but not bumped off the system. TECHNICAL NOTES: FRP.CREATOR is written in BASIC and is not compiled, nor should it be. Tacked onto the end of FRP.CREATOR is raw data consisting of help files, character set, and other info. Therefore you CANNOT modify this program without damaging it. There should be no attempt to compile it either, it requires no extra speed anyway. FRP.BBS is written in BASIC and complied with Skyles Blitz! BASIC compiler. It can be de-Blitz!ed, but the resulting code will not be RUNable do to the way de-Blitz! decompiles. The source code for FRP.BBS uses all but a few bytes of BASIC memory when uncompiled. Modification is difficult, but REMark statments can be eliminated to make room. The source code should be avalible on CompuServe CBM310 at some point in the near future. ALWAYS compile FRP.BBS if you make any modification. Only Blitz! compiler will interact with the machine language routines properly. FILES in FRP.BBS are SEQuential and in the format of: 35 characters ending in a carridge return. No special treatment of commas, collens or quotes is necessary; a machine language disk LINE INPUT routine handles them properly. For them to be exceptably by the EDITOR in FRP.BBS, they must fit these criteria and not be longer than 65 lines. FREEWARE NOTICE: FRP.BBS and it's support programs are FREEWARE products. They are not for resale, but instead are to be given out freely. By releasing this program in this way, I hope that people who find the program usefull will send me a donation so that I can continue to produce other programs and enhancments to this one. If it is of no value to you, pass it along. If you would like to send a donation, send a Check or Money Order to: Deep Pan Software co. #3 Fairway ct. Florissant MO 63033 Make Checks or M/O payable to either: David Whatley or Deep Pan Software Thank you very much, and have fun with the program. AUTHORSHIP CREDITS: FRP.BBS was written by: David M. Whatley aka: SpLiTiNfInItY CIS PPN: 72257,2256 (C) Copyright 1985, Deep Pan Software co.