2020-08-23 (originally 2012-05-25)
Scepter of Goth, also spelled Sceptre of Goth, was the first commercial multi-user role-playing game (RPG) and the first commercial multi-user MUD. It was originally written by Alan E. Klietz. For interaction it used simple line-at-a-time text commands and also displayed results as text, similar to the single-playr Colossal Cave Adventure and Zork. Although other settings were implemented with the software, it usually implemented a fantasy setting in the fictional city of “Boldhome”. Scepter of Goth influenced many multiplayer games that came after it, particularly the Swords of Chaos and Mordor series of MUDs. Scepter can be seen as one of the key ancestors of today’s massively multiplayer online role-playing games (MMORPGs).
I was the lead Scepter developer for InterPlay in the mid-1980s, where I modified it, maintained it, and added various capabilities to it. However, a lot of information about Scepter of Goth has disappeared from the Internet since InterPlay folded. I have repeatedly requested for permission to post historical records, to no avail.
I think Scepter of Goth was an important part of the history of gaming. So here I will try to record some of that information, for posterity. From here on I’ll refer to myself in the third person, to make it easy for people who want to cut and paste quotes. (Exception: I’ll refer to myself as “I” in the “Dunjon Master (DM) Commands” section.)
In 1978 Alan E. Klietz wrote a multi-player game called Milieu using Multi-Pascal on a CDC Cyber operated by the Minnesota Educational Computing Consortium. The MECC CDC Cyber was used by some high school students and some state colleges in Minnesota for educational purposes. Most CDC mainframes had only “128K words (60 bit words) of memory and 110/300 baud teletypes or modems.” Playing on a faster connection, 2400 BPS or the rare 9600 BPS could give some advantages in game play. It was inspired by the single-player computer games Colossal Cave Adventure and Zork, as well as non-computer RPGss such as Dungeons & Dragons.
This date is confirmed by Michael J. Tresca’s The Evolution of Fantasy Role-Playing Games page 114 which states that, “Alan E. Klietz produced Milieu in 1978. High school students across Minnesota were given access to the mainframe for educational purposes.”
Milieu may have been the first multi-player role-playing game (RPG) in the world. The other contender for that role is Multi-User Dungeon (MUD), developed in the UK by Richard Bartle; it was also developed in 1978. Bill Wisner believes that Milieu probably predates MUD (Wisner). However, it is especially difficult to determine which came first. Thus, as best can be determined, both Milieu and MUD should be identified as the first multi-player RPGs in the world. Scepter of Goth was the first commercial one, as we’ll see.
Klietz ported Milieu to an IBM XT in 1983, naming the new port Scepter of Goth. Scepter of Goth supported 10 to 16 simultaneous users, typically connecting in by modem, and ran on the QNX operating system (a Unix-like operating system) on an IBM XT running at 4.77MHz. Some documentation on old versions of QNX is publicly available. It was programmed in the C programming language, using non-portable QNX extensions for 8086/80286 memory segmentation.
Scepter of Goth was the first commercial multi-player RPG in the world, because it was running and had paying customers in 1983. Michael J. Tresca’s The Evolution of Fantasy Role-Playing Games page 114 states that, “Klietz transitioned the game to an IBM XT in 1983, which supported up to 16 players simultaneously over the modem, and renamed it Scepter of Goth. It was the first commercial MUD, run by GamBit.” Richard Bartle also notes that Milieu was ported to an IBM XT in 1983 and renamed as Scepter of Goth. Bob Alberti recalls putting in a Christmas theme in 1983 where the town mayor was changed to Santa, orcs became rapid reindeer, and so on. The players were officially called playtesters, but these playtesters paid to play Scepter, so Scepter was clearly commercially available in 1983 (Per an unpublished email from Bob Alberti Jr. to David A. Wheeler dated 2012-05-20). Bob Alberti provided me, on 2012-05-21, a snippet of Alan’s accounting code from 1983 (as an image) - this is additional evidence and shows how GamBIT could charge for usage.
On 2012-50-20 Alan Klietz filled me on some of the legal details. The software was running in 1983. At first Bob Senior was cashing checks (probably using a personal checking account). The software then became the key asset of GamBit Multi Systems, a shell corporation that used to be a restaurant. The DBA and restated Articles were filed February 10, 1984; this restart changed the corporation from being restaurant. The corporate registration was for a business type “Business Corporation (Domestic) MN Statute 302A”, file number: 2X-821. The filing history was as follows:
* 02/07/1977 Original Filing - Business Corporation (Domestic)
* 02/07/1977 Business Corporation (Domestic) Business Name
* 02/10/1984 Business Corporation (Domestic) Business Name
* 02/10/1984 Business Corporation (Domestic) Restated Articles
* 10/10/1991 Administrative Dissolution - Business Corporation (Domestic)Other commercial contenders came later. The first commercial implementation of Essex MUD (the other likely contender) wasn’t up until 1984 by Compunet. CompuNet was a UK-based network primarily for Commodore 64 users, which licensed MUD1 and ran it from late 1984 until 1987. Richard Bartle’s MUD1 was running at Essex in 1983, but not with paying customers. Note that Klietz was unaware of MUD1 at the time Scepter of Goth was initially developed; this is why it was initially difficult to figure out which came first. Mark Peterson’s “Realm of Angmar” started as a clone of Scepter, and it appeared in 1984, so clearly Scepter came first. Another early commercial multi-player RPG was Island of Kesmai, a multiplayer RPG that used roguelike pseudo-graphics, but Kesmai wasn’t launched on CompuServe until 1985 (significantly after Scepter). In short, Scepter of Goth was the first commercial multi-player RPG.
Scepter was first owned and run by GamBit (of Minneapolis, Minnesota), founded by at least Klietz, Bob Alberti (Senior), and Bob Alberti (Junior). Scepter of Goth was handled as a franchising business: franchisees paid for the right to run the system in a certain area, and a system was provided to them. Franchisees then administered the system and collected fees from users. Users would then dial in to play; while a franchisee could accept calls from outside their local phone call area, the extra charges this imposed on users meant that users tended to use the franchisee that was local or at least closest to them. Each franchisee would set their rates; most charged a certain fee per hour (typically $2-$4 per hour), since only a limited number of users could play simultaneously. GamBit also had an unfinished advanced MUD by Klietz called Screenplay, but this was never widely deployed. A history of GamBit shows some of the key documents from GamBit’s history.
GamBit’s assets, including Scepter and Screenplay, were then sold to InterPlay (of Fairfax, Virginia). InterPlay continued to sell franchises as well as maintaining its own nationwide chat system (ProtoCall). InterPlay’s lead Scepter developer David A. Wheeler modified and maintained Scepter, adding a number of capabilities and fixing various bugs to improve its stability.
As a result of this franchising business model, several Scepter of Goth systems ended up running in various locations, including at least ones in the following locations: Minneapolis, Minnesota; Austin, Texas; Chicago, Illinois; Ottawa, Canada; Fairfax, Virginia; West Valley City, Utah; and Bowie, Maryland. The system also included electronic mail, bulletin boards, a separate chat system, and some other facilities, but the game itself was the primary draw for its users. At a time when most Bulletin Board Systems (BBSs) only allowed one person to log in at a time, larger dial-in services had few interactive services, and Internet access was rare, Scepter was a startling new development to many. It was also accessible to anyone, not just those at one or two universities, so it was seen and used by a variety of people.
Unfortunately, Interplay president Denny Flanders was charged and eventually convicted for tax evasion (for actions unrelated to the company), and was sentenced to jail. Although InterPlay could show that its revenue was increasing and when it would start turning a profit, the venture capitalists who had funded InterPlay were not willing to wait, and pulled their remaining funds. Once the funds were pulled, InterPlay immediately went bankrupt, and Scepter was no longer widely available.
Scepter influenced other work that followed after it. In particular:
Many MUDs and MMORPGs, commercial and noncommercial, are inspired by and use ideas from a variety of sources to develop their own work – including ideas from Scepter. In particular, Scepter helped demonstrate that it was possible to develop such multi-player games, and that there was a commercial demand for them.
Those few people who had the privileged status “Dunjon Master” (now more typically spelled as “Dungeon Master”, and always abbreviated DM) could execute a set of special privileged commands that modified the game’s status. DMs could create, modify attributes (including location), and remove things. The technical term “things” was a collective term for rooms, objects, monsters (non-player characters), and players. These DM commands were typically used to create new or modified areas for the players to explore, so that the players (paying customers) would have a reason to keep returning.
DM status was not earned through play, but had to be specially granted by the system’s administrators. Typically the franchise owner, and a very few others, would have this status. DMs operated as referees, and the difference between a good and bad franchise often depended on the capabilities of the DMs.
The expectation (at least by InterPlay) was that at least one DM would be online most of the time while players were connected. DMs would be alerted of certain events, or do occasional spot-checks, and were expected to occasionally act in ways that would make the paying players’ experience more fun. The DMs typically did not constantly monitor the system, but would be alerted when certain actions occurred. For example, rooms could be set so that DMs would be automatically notified when a player entered them. Other actions, such as making a wish, would also alert DMs (so the DM could determine how to respond to the wish). DMs could then perform a variety of actions. For example, they could make it appear that a monster could fully understand language and have the monster perform arbitrary actions. DMs could also create monsters and objects on the fly to create an interesting setting. DMs could essentially take control of monsters-making them do and say as the DM pleases. Many DMs were very benevolent and acclimated newbies to the MUD. Many DMs spent their time creating new worlds and monsters as well. If a DM had anticipated a complex action, the DM could execute a script of their own design on command.
DMs’ occasional actions made the game appear far more varied and “intelligent” than any software could manage by itself.
Scepter was not fully programmable by the DMs, or even by the franchisees (who only received the executable files). Instead, rooms, monsters, players, and objects had a large set of attributes that could be set by DMs; these values influenced the underlying engine. On the positive side, this made it fairly easy for non-programmers to create situations as complex as the underlying software would permit. On the negative side, this meant that many complicated scenarios could not be implemented by the system itself, but instead would have to be implemented by online DMs. This limitation was in part because of the limited computing power available at the time, and was one of the limitations removed by its never-completed successor ScreenPlay.
The game did support a number of settable attributes that was extensive for a game of its time; combinations of attributes were used to achieve various useful effects. Monster attributes included block (tries to prevent player from leaving the room), follow (follows the player), guard (completely prevents player from picking up anything in the room), magic (cannot be harmed by non-magic weapons), spell casting (can cast spells), undead (can be turned), and rust (weakens player’s primary weapon or armor). The object type had many different subtypes (such as door, key, armor, weapon, teleport device, money, chest, and so on), and each subtype had a set of attributes peculiar to that subtype. For example, a teleport device had the attribute for where it would teleport to, and (optionally) what room the user had to be in before it would work; this meant that players would need to decipher clues on where they had to go to use the device.
All things had the attribute “description”, the text shown when looking at the thing. Descriptions could be multivalued; a description beginning with the slash character “/” was followed by multiple descriptions, each separated by a slash. When a multivalued description was to be displayed, one of the values was randomly chosen. Multivalued descriptions were used to vary the descriptions so that they would not be so repetitive. This feature was also used to simulate examining an object: if there were 4 identical descriptions for an object, plus a different description that gave a clue, then a user might need to look at an object several times before obtaining the clue.
In any MUD, a major challenge is handling resets. In Scepter, when a player entered a room that was not in memory, the room would be loaded into memory and set as necessary, with any (live) monster stored in the room (a “permanent” monster) set to their maximum health. Once a player no longer was in a room, it would be eventually retired from memory and that status would be saved back to disk. “Permanent” monsters that were still alive were written back. If a DM directly placed a permanent monster in a room, and the monster died, it simply stayed dead without any automatic reset; if a DM wanted to revive the monster, the DM had to send a command to do it.
Scepter was designed to allow easy displays of settings (for later reloading), so DMs would often simply store in a file the commands to reset a given area, and then load that file when they wished to reset an area. This was consistent with the notion that DMs were often online anyway; the goal was to simply make it easy for DMs to issue the commands to reset an area when the DM determined that was the right thing to do. Rooms could be set to periodically generate a random monster from a list (which would not be permanent), and monsters could be set to generate a set of treasures when killed, and these lists were separately maintained. Thus, a room in an “ice castle” might point to a list of different cold-related monsters, and killing the monster might produce one of a set of cold-related treasures.
Smart DMs would soon learn to store their commands in fiies, and then send those files whenever they deemed it appropriate. This partly compensated for its lack of scripting; the files stored by DMs, who reused them as appropriate, provided some of the functionality that scripts would have provided.
Scepter had Dungeons & Dragons-like role-playing, combat, character classes, and levels. The normal classes were cleric, fighter, lady (female only), magic-user, paladin, ranger, and thief; it also had the special classes assassin and barbarian, which could not be directly selected by players. As with other similar games, killing monsters or obtaining certain items gave a player “experience points”, and a sufficient number of experience points would grant the player’s character a higher level (which granted more hit points and power). Combat occurred blow-by-blow; if a player’s “vitality” (also termed hit points) dropped below zero, they died; death would cause the character to lose one or two levels, and reappear at the standard starting point for the game. Vitality would slowly regenerate until it reached maximum vitality; the maximum vitality increased when a level was gained.
Typical single-player adventure game text commands were accepted, such as “north” to go north, “get X” to get object X, “inventory” to show the list of current carried items, “drop X” to drop carried item X, and “attack X” to attack monster or player X. The command “follow X” would cause the player to follow player or monster X; this command was used to form groups of players.
The game had a built-in system for magic. Casting a spell required a certain number of “magic points”, which like vitality slowly regenerated up to a maximum number of magic points for the character. Some spells could only be cast by certain character classes, and a character could not cast a spell until they had “learned” it (from a scroll or another character). Casting a spell also required entering a chant (a text phrase); a DM might occasionally change a chant, making the spell unusable to everyone until the characters had figured out the new chant (typically by solving riddles in adventures). The most powerful spell (castable only by high-level mages) was “wish”, which permanently cost one point of constitution and sent the wish’s text to a DM to determine how to respond to it. DMs were obligated to maintain game balance, and Scepter’s lack of programmability meant some wishes could not be exactly granted, but wishes to create a specially powerful weapon, or to create an extraordinary magical “home” for the player and/or his friends, could indeed be granted.
Scepter had several mechanisms to prevent powerful player characters from constantly killing significantly weaker player characters. Such killing was considered very undesirable because it would drive paying customers away; players would generally complain about “unfair” fights. Some rooms were set as being “safe rooms” (where players could not attack each other), including the locations where new players began. Some doors had attributes that limited the minimum and maximum levels of characters who could go through them. Scepter also had a mechanisms to penalize certain kinds of player-on-player killing. In earlier versions, player-killing was occasionally followed by creation of an unkillable monster called the “Revenant”, who would attack the killer until the other player was also dead. In later versions, if a player with a much higher level killed another player’s character, a “ghost” of the low-level character with power equal to the killer would appear and attack the killer; no experience points were granted for killing the ghost.
The typical setting used in Scepter of Goth was a fantasy setting involving the town of Boldhome and outlying areas. Adventurers would meet in Boldhome, buy or sell equipment, and set out to adventure. Dungeon Masters would occasionally create new areas in which to adventure, or modify those areas. One oft-used motif in many franchises was that the primary shop (“Sharkeys”) was considered illegal by the Boldhome authorities, so it was constantly being closed by the Boldhome police and reopening somewhere else, requiring players to look for clues for its new location. (The typical notice said, “By Order of the Boldhome Police: This illegal establishment has been closed…”). Boldhome included a newspaper stand; the newspaper reported various things including obituaries (noteworthy deaths, including text by the player about his character’s demise). Other important locations included a combat arena and training areas for each class.
Before its closing, InterPlay worked with Margaret Weis and Tracy Hickman to create a Dragonlance-based environment, but this was never as popular as the Boldhome environment.
Many areas were explicitly designed to require multi-character groups. Areas might be designed so that a set of different classes was required to succeed, or only a low-level character could get a key (while only a high-level character would succeed against a certain monster). This was often accomplished by inserting portals into the area; portals could be set to require specific class, or to require minimum and maximum levels. This encouraged the formation and sustainment of groups.
Typical Scepter games involved a mixture of combat and puzzle-solving, with players talking with each other and working together so they could succeed. Puzzle-solving was considered an important part of Scepter games, and these puzzles were supported by several mechanisms. For example:
One challenge in any multi-player game is how to form working teams. This was especially challenging in a text-only format, where users are expected to type in commands; if a player moves, how does the system know which other players or monsters should also move? Even more importantly, the solution should be easy to understand and use.
The solution in Scepter, which worked marvelously well, was the “follow” command. A user could simply state who they would follow; that player or monster might in turn be following another. This meant that groups could fluidly join each other, or separate, without complex commands.
David A. Wheeler completely rewrote the code for the “follow” command, because there were many subtle complications the original code did not implement correctly. For example, since some creatures might (or might not) be able to see certain others, what was reported might be quite different for each observer. The original code would occasionally report the wrong information, or even crash. Since the “follow” command was the fundamental mechanism for creating multi-player groups, and multi-player groups were the key thing that disinguished Scapter from games like Zork, rewriting the command was worth doing. Since groups were quite common, this one improvement helped make the game as a whole work better.
On May 15, 2012, Alan E. Kleitz sent to me (David A. Wheeler) a few sample transcripts that showed some examples of Scepter in operation. These are available here: scepter-sample1, scepter-sample2, and scepter-example.
This section describes the various commands available to DMs, in particular the various parameters (attributes) that could be set to create various effects. This material is based on “The Dunjon Master’s Editor User Manual” by Interplay, Inc., copyright 1985-1986.
I (David A. Wheeler) don’t have the rights to release the manual, sadly. However, I believe I have the rights to release the material below. Although copyright covers expression, facts themselves cannot be copyrighted. I have rewritten the material in this section so that it is expressed differently, and merely describes some of the same facts. Even if was determined that this material overlapped another’s copyright, I believe that sharing this material is a fair use, per 17 U.S.C. § 107. It is released for purposes of criticism, comment news reporting, teaching, scholarship, and research. Here are comments about how it meets the four parts of fair use:
Scepter of Goth underwent continual change, so this is really information at an arbitrary point of time late in its development. It’s not even really consistent, e.g., sometimes “Barbarian” is listed as a class — and sometimes it is not.
Users could type in normal commands like “get OBJECT” or “north”. A DM had a player character, but that character had the “ZZ” (aka DM) parameter set so that the player had a long list of additional privileges.
DMs had a number of additional special commands, all beginning with “*”. These were:
The most important command was *edit, which entered a mode that let DMs make arbitrary changes to the world (a DM could create, delete, modify or show anything).
Scepter by itself was limited in what it could do, but a common DM trick was to use *nonexistant and then wait for players to do something “interesting”. For example, some rooms were set as NO=true (notify); a DM would be alerted when a player entered that room (such as a bar or a quest end). The DM could then use *send, *say, and *yell to display interesting responses, as well as the *edit commands to change things in interesting ways. A good DM, by doing this judiciously, could make it really fun to play.
The *edit command entered the Scepter Editor, which let DMs show and change the world at run time. This had four basic commands: create, delete, modify, and show.
Here are the commands, and some examples:
I believe LOCATION could be omitted, in which case the location was the current room. I believe you had to put a comma before any statistics if you did this, so that it wouldn’t be interpreted as a location; e.g., create monster orc, lvl=4, hi=30. This may have been a later addition.
Show had a “brief mode” and a “verbose mode”. The verbose mode would show everything in detail, and was good for new DMs, but the brief mode is what DMs normally used. The brief mode would show the data in the form that could be used to re-create the object, so you could capture that in a file for later reuse.
When creating or modifying things, a DM would set the statistics (aka parameters or attributes) that would cause the desired result. So you needed to know about the various attributes you could set.
There were several main types, especially player, monster, room, object. The “object” type had a parameter that was confusingly named TY (type), which determined the subtype of the object. I will list the room parameters first, since they are the simplest.
Here were the room parameters:
Room numbers varied from 1 to 4095, and rooms weren’t really created, they were just modified.
Rooms 1-30 were special and never left memory:
One of the gimmicks in the game was that Sharkey’s (the shop) was illegal, so it was always getting closed and then re-opened somewhere else. This set up endless questing to find the shop. One of the description files at one point read:
By Order of the Boldhome Police: This illegal establishment has been closed. Anyone attempting to open this door will be killed by a trap. Signed: Boldhome Chief Guardsman.
Another read:
Reward: Sharkeys opened temporarily in the backroom of the mercantile! He has been shut down again. A reward of 10 gold pieces is offered for information leading to his PERMANENT capture! Boldhome Police
One odd thing about Scepter is that the privilege of being a DM was not connected to a person/user, but to a player-character via the ZZ parameter.
Some key statistics (vitality, fatigue, and magic) were primarily assigned based on the class and level. Note that the “hit points” of other games are, in Scepter of Goth, two values for players (fatigue + vitality). A level 1 player would have certain stats, and these values would be added at each level. So a level 5 player would have 5 times the default values of the level 1 player, for a given class. For example, a level 6 fighter should have vitality= 6 * 8 = 48, fatigue= 6 * 14 = 84, magic= 6 * 2 = 12, so here’s how the DM could reset the stats of online player “fred”:
modify player fred, MV=48,VI=48,MF=84,FA=84,MM=12,MA=12
The following table shows the values for each class:
| Class | VI (vitality) / MV | FA (fatigue) / MF | MA (magic) / MM |
|---|---|---|---|
| Barbarian | 10 | 15 | 1 |
| Cleric | 7 | 11 | 4 |
| Fighter | 8 | 14 | 2 |
| Lady | 6 | 9 | 3 |
| Magic User | 7 | 10 | 5 |
| Paladin | 11 | 8 | 3 |
| Ranger | 7 | 11 | 3 |
| Thief | 7 | 10 | 3 |
| Level | Experience |
|---|---|
| 1 | 0 |
| 2 | 512 |
| 3 | 1024 |
| 4 | 2048 |
| 5 | 4096 |
| 6 | 8192 |
The required experience points continue to double up to 21st level. A player can’t go beyond level 21 just through the game mechanics.
Monsters, aka non-player characters (NPCs), had many parameters. A key parameter was PE (permanent); monsters from random encounters had PE=false, and eventually got erased if a room has no players, while permanent monsters got saved to disk. If a player attacks it, key parameters included HI (hit points) and LVL (level).
The monster parameters were typically grouped into basic, primary, and secondary parameters.
Parley settings included: - 0 : No reaction - 1 : Sell object (from treasure list) - 2 : Negative reaction - 3 : Positive reaction - 10: Teleport player to one of the rooms in 30-300.
There were various guidelines for setting the EXP value. The suggested guideline was to set the experience point value as:
EXP = HP + Table(level) + bonus
Where Table(level) converts the monster level to experience as follows:
| Level | Experience |
|---|---|
| 1 | 10 |
| 2 | 20 |
| 3 | 30 |
| 4 | 40 |
| 5 | 50 |
| 6 | 90 |
| 7 | 200 |
| 8 | 300 |
| 9 | 1000 |
| 10 | 2000 |
| 11 or more | 3000 |
The recommended bonus is based on the number of:
| Monster level | Bonus |
|---|---|
| 1-5 | (PA + 2 * SA) * (HP / 10) |
| 6-8 | (PA + 2 * SA) * (HP / 10) * 2 |
| 9 or more | (PA + 2 * SA) * (HP / 10) * 6 |
Two parameters controlled object names:
All objects had the following parameters:
Objects have an “object type” TY (which is confusing, because things have a basic type as well: object, monster, player, room). The object types are: armor, blunt (weapon), card, chests/containers, door, key, magdevice (aka magicaldevice), misc, money, none, pole (weapon), portal, scroll, sharp (weapon), shield, teleportdevice, thrust (weapon), treasure.
Note that many items had limited uses. Armor had armor hits (AH), magic devices had charges left (CH), and so on. This ensured that players weren’t all-powerful, and thus made things more interesting.
The following describes the parameters for each object type.
This is a special magical device used by DMs that allows the user to teleport to any person in the game. It’s not intended for use by players.
It is activated using:
use card on PLAYER
See also portal objects. The larger the weight, the harder it is to SMASH. If the door is not magic (MA=false) then a magic-user may be able to get through using the PASSDOOR spell. If a door is magical, has lock type of 1000, and weighs 1000 pounds, then it cannot be opened by any player.
Doors are seen on both sides.
Traps are not triggered if they are opened with a matching key. A special key is the DM master key (UL=1000); a key with this UL value unlocks any locked door or container.
These were used for magic wands, potions, and similar spell-casting devices. If a player says drink OBJECT, the item affects the player. There is no intelligence or level requirement on the use of a magical device.
This example creates a 2-charge fireball wand:
create obj wand in chest in 3001,ty=magdevice,magic=true,spell=3,value=1000,charges=2
Portals are one-way connectors. You can then GO or ENTER a portal. A portal needs a TO value. See also door objects.
These use the DI parameter, described above.
Players can use EXAMINE to figure out what the scroll will do. A player can READ a scroll to cast a spell (on a player, monster, or object). Once read, the scroll disappears (a scroll is basically a one-charge item). Scroll minimums for intelligence and level are somewhat lower than spell-casting, but if they are not met, nothing happens (the scroll is not ruined).
These are sometimes used like special keys to access special areas like the Thieves’ lair. Usually the departure room is set, so it will only work from one room; the player may need to work out clues to figure out where a teleportdevice works.
A teleport device need not be magical.
The teleport device sends the recipient to exactly one room, and perhaps from only room, while the teleport spell sends the recipient to a random room between 30 and 300.
Players have skills in each of the four types of weapon. Weapons can be repaired (i.e., have strikesleft increase) at the repair shop (room 18) as long as “strikesleft” is more than 0. There’s a 50% chance that the repair will be botched if the weapon is magical or has MH more than 30.
A DM can create/modify/show/delete a “description”, which is just an indexed string of text typically used for long descriptions. Description #1 is the login text, description 101 is the spell chant for vigor, and rooms have description numbers of room#+10000. If slashes are in a description, it is treated as a separator, and a random one of the separated descriptions is selected on each use. A “” can be used to insert newline. So to change the long description of room #123: > modify description 10123 “/in a dark alley./”
A DM can create/modify/show/delete an “mlist”, which is a number-indexed list of monster attributes. Each mlist entry sets up a monster for a random encounter. Monster #1 is special; it is the “revenant” to counter player-killers. You can set monster mlist #240 like this:
modify mlist 240,NA=bear, …
The revenant (mlist #1) by default had these settings:
NA=revenant,LVL=1,HI=30,MH=30,DEF=T,BL=T,FO=T,GU=T,ATK=T,… PE=F,EXP=25,UN=T,DRAIN=T,RUS=T,TR=0
A DM can create/modify/show/delete an “mindex”, which is a number-indexed a list of 1-6 numbers. Each of those numbers refers to an mlist entry (above). Typically you would then set a room’s ENCOUNTER value to this mindex value.
modify mindex 10 241,242
Using mlist and mindex makes it easy to create a lot of randomness that still makes sense.
Similarly, a DM can create/modify/show/delete an “olist” which is a number-indexed list of attributes to set an object, and an “oindex” which lists 1-6 olists when an object shows up randomly. These are often used for treasure; a monster would have its TREASURE value set to an oindex; the oindex in turn lists 1-6 different possible treasures as olist values. (Of course, if a monster already carries specific items, then those items become available to others if the monster dies.) Olist items 1-20 are for sale in the weapon shop; olist items 21-40 are reserved for sale in the (never implemented) magic shop.
The spells in basic Scepter are:
There are also special commands:
Only clerics can cast heal, bless, or turn. Only mages (magic-users) can cast protect, disintegrate, enchant, or wish. An oddity is that mages could curepoison at level 1, but clerics couldn’t until level 2.
Here is when a given class can cast a given spell (“-” means never):
| Spell | Mage | Fighter | Cleric | Paladin/Ranger/Lady | Thief |
|---|---|---|---|---|---|
|
1 | 1 | 1 | 1 | 1 |
|
2 | ||||
|
2 | 6 | 3 | 4 | 5 |
|
4 | 8 | 5 | 6 | 7 |
|
1 | 1 | 1 | 1 | 1 |
|
1 | 5 | 2 | 3 | 4 |
|
5 | ||||
|
1 | 5 | 2 | 3 | 4 |
|
5 | 9 | 6 | 7 | 8 |
|
10 | ||||
|
5 | 9 | 6 | 7 | 8 |
|
5 | ||||
|
6 | ||||
|
2 | ||||
|
5 | 9 | 6 | 7 | 8 |
|
4 | 8 | 5 | 6 | 7 |
|
3 | 7 | 4 | 5 | 6 |
| Identify | 5 | 9 | 6 | 7 | 8 |
| Turn | 1 |
A player must learn a spell before casting it, either by being taught the spell or by examining a scroll. Once learned a spell is not forgotten. The player must also type in the chant for a spell to cast it, which means the player must also find out what the chant is. The default chants are:
| Spell | Chant |
|---|---|
|
I return vigor |
|
Thy wounds are mended! |
|
Ball of fire fly to thee! |
|
I command you to glow with energy! |
|
Ouch! That hurt! |
|
Let thy fluids run pure! |
|
I disrupt they molecular structure! |
|
Be thou confused utterly! |
|
Let me go to someplace new! |
|
This is the last time I want to change this chant! |
|
I refuse to be stopped! |
|
I infuse you with magical dweomer! |
|
Your soul is now pure again! |
|
You are being watched! |
|
I denigrate thee for all to see! |
|
May thy blood fester in thy veins! |
|
More than one hundred proof! |
Here is the full list of possible player commands: accept, appeal, attack, backstab, block, break, bribe, brief, buy, cast, catalog, circle, climb, clock, close, d (down), down, draw, drink, drop, e, east, echo, end, enter, examine, exit, experience, feint, file, follow, get, go, health, help, hide, hint, hit, hold, identify, information, inventory, kill, leave, list, lock, look, lose, n, north, offer, open, out, panic, parley, parry, pawn, picklock, put, quit, read, repair, return, run, s, save, say, search, sell, send, smash, south, status, steal, strike, suicide, take, talk, teach, thrust, track, train, turn, u, unlock, up, use, w, wear, west, where, who, wield, yell.
Attack hits were determined as follows: if random(20) > level(player) - level(monster) + 10 + factor, then hit, else miss. There is an 8% chance of double damage in an attack, and 1% chance of a fumble. The factor is computed as follows (added unless stated otherwise):
I’m sure that armor class affected this too, but I don’t see that noted in the documentation I have.
Scepter was mostly commercially abandoned after InterPlay folded. Some specific instances did keep running afterwards, and there were some brief efforts to update the software to newer hardware. However, its original source code was tied to very specific older hardware, which made it hard to port the software to newer hardware. For example, the Scepter source code routinely used QNX C extensions for 80286 mode, enabling it to reference pointers that used different segment registers (using “-}” instead of “->”). Since these kinds of pointers were not in standard C, the code would not compile on anything else. In addition, a number of tricks were used to make it fit in the small amount of memory, storage, and processing available.
Scepter could have been ported, but other many other rapid changes made it hard to justify financially (and made it even harder over time):
Various sites ran for a while after Scepter folded. Tony Anderson reported to me on 2012-10-31 that after InterPlay folded, Chicago ran for 6 months or so, Minneapolis ran for at least a year or two, and Texas seems to have kept running until 2003-04 (month uncertain). However, many franchises only had rights to run the executables, and did not have the source code.. which meant that as technology changed, and as old equipment failed with no spares available, it became harder to keep them running.
In 2014 some enthusiasts (Wayne Jensen and Corey Anderson) inherited a Scepter / Teleplay machine (with all the modems and so on) and got the software somewhat running (buggy, but running).
That said, though, Scepter in general disappeared. Its disappearance was so thorough that these kinds of games became known as MUDs, even though MUD only became commercially available after Scepter of Goth. A sad end, really. MUD was a worthy program, and I do not mean to take anything away from Richard Bartle’s fine work, but Scepter should be included when the history of multiplayer games is discussed.
Indeed, Bartle (who created MUD) thinks the same thing. He noted in 2015 that few people will have heard of Alan Kleitz (who wrote most of the original Scepter of Goth code) or Bob Alberti (Who wrote much of the original game world), yet if “it hadn’t been for a series of catastrophic episodes of bad luck and mismanagement, we could well have been calling MUDs SOGs instead… there are current in-development MMOs that can trace their family tree directly back to Sceptre of Goth. In particular, Camelot Unchained is a descendant of Dark Age of Camelot, which is a decendent of Dragon’s Gate, which is a descendent of Aradath, which Mark Jacobs (lead designer and sometimes sole programmer on all of these) wrote because he was inspired by Sceptre of Goth… All of this is history that needs to be recorded. It’s just not right for pioneers to be forgotten merely because they didn’t make millions from it.” Bartle2015.
I (David A. Wheeler) believe that David Wertheim bought the rights to Scepter in 1988, and I believe he lived in Pittsburgh. I have tried to contact him, to no avail.
I have had occasional contact with Emory Hackman, a lawyer who acted as the bankruptcy trustee for InterPlay. On 2007-06-20 I asked Emory to try to contact whoever currently held Scepter rights, so that I could get the right to post the user manual on the web. I never heard back, and without that permission I cannot post the real materials (since they would hold the copyrights).
Copyright has an excessively long term today, and no one without rights can release the source code even if they have it. Of course, over time storage media fail. Many, many works will be lost forever because of copyright’s excessively long copyright. For Scepter of Goth, that would be a sad end to a bright beginning.
Happily, that appears to not be the case.
Scott Johnson has found that Scepter of Goth appears to have been released to the public domain. Everything seems to be in order, and I have no reason to disbelieve the report. After all, it is not commercially viable. I think it’s an important piece of history, and I’d like for it to not be lost from history.
The GitHub directory shelches/scepter appears to contain a version of the source code of Scepter of Goth. There were many versions, and it’s not clear what version this was based on. It also doesn’t include a game world (which made it interesting). Still, this at least makes a version of the information available to the world.
I have various copies of materials that I had when I was a developer of Scepter of Goth (including databases and such). Now that I have strong evidence that it’s been legally released, it appears that I can work to share those other materials.
Literally millions of people play multiplayer role-playing games today. My hope is that this material will help set the record straight on an important part of its history.
This text is released under the Creative Commons Attribution-ShareAlike License (CC-BY-SA).
I wrote this material in the Markdown language, and then used pandoc to convert it to HTML. The markdown text is available.
The history of this text is complicated; I wrote most of the Wikipedia entry of “Scepter of Goth”, and portions of the text above is derived from the 2011-09-17 version of that article. Since it’s all the CC-BY-SA license, it doesn’t matter. This document has a lot of additional material based on “The Dunjon Master’s Editor User Manual” by Interplay, Inc., copyright 1985-1986. I don’t have the rights to release the manual, but facts cannot be copyrighted, so I can release the facts of that manual even though I cannot release the manual itself.