Imaginary Realities 1999 September Edition

Summary of September 1999 issue of Imaginary Realities. Imaginary Realities was an ezine dedicated to MUDs.

Summary of "Applying a MUDpack" by Chris Caines

Chris was an experienced MUDder under the name of Arzac. Later he wrote a comic.

A humorous commentary of the MUDding trends, players, and the author. The author played MUDs (Discworld) nearly continuously from 1993 to 1999. After which he to a step back, re-evaluated his life, and promptly started making a weekly comic strip about how funny MUDding really is. The comic was called Mudpack.

"My long-winded point is simply, mudding is funny! It is funny for you because you know what a Womble is, or you know what it is like to be up at 3 AM because you have been killing a Rat for the last 4 hours and you are damned if you are going to give it up now. But do not forget it is also funny to other people, usually because they do not understand what a cabbage is for."

Summary of "Mud Governments" by Griffin

MUD-like games are usually classified by the type of game play that occurs on them: social, PvP, role-playing, etc. A novel approach to classifying these types of games would be to classify them by government type. The classification would be more of society/community than game play.

Some MUD governments are made up of builders and/or admins, only. Some have players that have an in-theme government (ie star fleet command). Others have out-of-theme governments by players.

If you have an MUD government solely run by one supreme admin, you have a government that can act quickly and decisively. Also, you have the chance of abuse of power. This form of government works until the MUD grows too big for one sovereign to handle.

If the government is run by a team or counsil of builders/admins then you have "an oligarchy, a system based on a relatively small power elite that makes all key decisions." Mortals (players) may even join this council, depending on the MUD. This sort of government often comes with secrecy to keep internal differences from the players.

These types of governments are often quick to handle issues. However, they are prone to faction conflict and nepotism. They can govern larger player-bases than the single-person government.

Adding even more people in power to handle growing population of a MUD, tends to result in lots of rules to keep corruption in check. These MUDs can become very bureaucratic and legalistic, very easily ruining the experience for new players.

Another approach is to allow votes, or purchase of in-game resources associated with desired outcomes. For example, buying coding time to have certain game features worked on. "The strength of such a mud is the high level of player participation, the risk is a form of populism that can marginalize the smaller or less powerful groups."

Very complex government types with elected mediators have been tried with some success. These MUDs "have attempted to set up complex mechanisms of consensus decision making, typically coupled to plebiscites as ways to resolve issues that cannot be brought to consensus. Such muds tend to become very "political", as participants are expected to invest a considerable amount of time into collective decision making."

These government types mentioned above, typically are out of character (OOC) with the MUD themes. There are government types that are more in character (IC).

IC governments often have little or no democratic features. While an absolute leader is often accepted in the MUD realm, they are looked on with a fair bit of suspicion.

"I wonder whether the democratization of OOC mud governments is not only politically preferable, but even a better basis for more subtle IC game play."

Summary of "Reviewing Muds" by Selina Kelley

Selina reviewed MUDs for The Mud Connector.

Reviewing MUDs is hard, even when it's fun. The author doesn't like giving bad reviews, even when deserved. And whether you give a good review or a bad review, you'll still get hate mail from players and ex-players of the MUD.

The best approach to writing MUD reviews is, have a thick skin and write honest reviews. "Some people cannot understand constructive criticism, and any negative aspect of their Mud you point out will be seen as a direct attack, but regardless of their reaction, you should never fudge the truth to soften the blow." However, some wizards and admins actually act on the review and make positive changes to their MUDs.

Reviewing a MUD without letting personal biases taint your review is difficult. The author often returns to a previously reviewed MUD at the admin's request, when they want updates reviewed. "Regardless of how I may or may not be burned by it, I consider it an accomplishment when I complete a review as honestly as possible."

Summary of "The Lessons of Lucasfilm's Habitat" by Chip Morningstar and F. Randall Farmer

Originally from "The First Annual International Conference" and "Cyberspace: First Steps".

Habitat was a 3D world inspired in part by Vernor Vinge's True Names. The front end was for Commodore 64 and the backend was QuantumLink. The choice was purely financial and contractual.

The players had avatars controlled through a joystick. Word balloons displayed the text they typed. Habitat had 20,000 in-game locations. Habitat had ATMs, vending machines, and its own economy.

A host of objects could be carried in hands or pockets. These included books, drugs, keys, and even magic wands.

Habitat used object-oriented models, kernel handling of memory, telecommunications and other state-of-the art 1990's tech.

The backend maintained the world state, and updated the client for display purposes.

Habitat was built on several core prinicples:

• The environment MUST by multi-user in nature to create "richness, complexity and depth", because AI's weren't available to do the job.
• Use of network bandwidth must be minimal, because, ... well, ... modems.
• All data as objects was essential.
• Platform is unimportant.
• Standards for transport protocols for data are vital.

"There were two sorts of implementation challenges that Habitat posed. The first was the problem of creating a working piece of technology -- developing the animation engine, the object-oriented virtual memory, the message-passing pseudo operating system, and squeezing them all into the ludicrous Commodore 64 (the backend system also posed interesting technical problems, but its constraints were not as vicious). The second challenge was the creation and management of the Habitat world itself. It is the experiences from the latter exercise that we think will be most relevant to future cyberspace designers."

The biggest complexity of Habitat is introduced by the 20,000+ players online. By the time Habitat had reached 50 players, the engineering team crossed the complexity threshold and were over their heads in holes and rough edges in the game. Scaling was a big issue. Tens of thousands of players meant the need for 10's of thousands of houses and a massive number of interesting places to visit. Whole towns and forests needed designing to avoid cramming everyone into the same space.

Also, 10's of thousands of players are going to have a vast array of interests, not just the same interest repeated 50,000 times. "Most activities, however, involved some degree of pre-planning and setup on our part -- we were to be like the cruise director on a ocean voyage, but we were still thinking like game designers." Activities planned and built out for weeks were often finished by the players in hours. Some players never got to participate, they were over so fast. The result was most players did not have a good experience at activities. Unexpected outcomes were standard.

A new approach of letting the players decide the design worked better. They watched what the players were doing, and modified the software to help them to more of it. Another approach was to give suggestions to the community that the community did not know the software could do. This also worked well. What never worked was assuming the developers could tell the players what they would do.

Murder and theft were allowed in the game to provide conflict and drama. Habitat had very few rules to begin with. 50% of the players were fine with PvP and the other 50% felt it needed to stop. Eventually, cities became safe spaces where theft and murder could not happen.

"One of the outstanding proponents of the anti-violence point of view was motivated to open the first Habitat church, the Order of the Holy Walnut (in real life he was a Greek Orthodox priest). His canons forbid his disciples to carry weapons, steal, or participate in violence of any kind. His church became quite popular and he became a very highly respected member of the Habitat community."

A voting system was added and the position of Sheriff was added. Soon the first virtual sheriff was elected. The sheriff did not get any actual power to arrest players, because the first simulation was shutdown.

The important takeaway is that a government can be evolved in-game, if the rules allow it to be. The game does not need a fixed government before game play begins.

Players cheat. Players take advantage of bugs. Sometimes the players think bugs are features, so innocently cheat. Never trust anything coming from a client's computer. Not everyone can be trusted.

Not allowing players to create regions and game features meant the developers were a technical and diversity bottleneck. Encourage creative involvement by the players. Get suggestions and feedback directly from the players.

In-game interaction must, Must, MUST!!! stick to the theme and rules of the world. Extraordinary, problems can result in wonderful in-game experiences for many players.

For example, in one event, DEATH (a sysadmin avatar) was killed (multiple times actually) and dropped a one-shot gun that players were not supposed to have. One solution taken was the admins forcing the player give back the gun. Much hard feelings and hate spawned from this solution.

Another solution attempted was a large ransom, and theatric exchange happening in the town square--all completely in theme. The result was a sensation that all the players loved and heard about.

Habitat was followed by "Club Caribe" in America, and "Fujitsu Habitat" in Japan.

"We feel that the defining characteristic of cyberspace is the shared virtual environment, not the display technology used to transport users into that environment."

Summary of "The Model Economy" by Scatter ///\oo/\\\

Scatter ran Dawn Whispers MUD.

Economy is ignored in most MUDs, with values of items assigned, and seasoned players becoming immensely rich. The rich players can afford anything in the MUD, and tend to gift massive amounts of gold to new players making the economy dysfunctional even for new players.

Limiting bank accounts annoys players and doesn't prevent them from harvesting vast amounts of gold at will. Creating expensive items like elite equipment, customize rooms, or guild halls encourages harvesting without fixing the underlying economic issues. Training costs limit gold of newer players, but becomes a non-issue as they become more powerful.

A cost of living that just barely offsets the time and means needed to acquire wealth creates a good economic balance. Some possible costs of living that can be implemented include:

• Taxes
• Rent - "not meaning the old inventory-rent idea that still crops up occasionally but rather things like renting rooms or houses within a city to personalize and live in"
• Wear - items/equipment need replacing and repairing
• Followers - include a cost to hire mercenaries/bodyguards

"The remainder of the excess income can often be mopped up by desirables - things that players want (but don't need), and ideally that are either temporary and have to be replaced or cause more ongoing expenses. For example, a player that wants a horse to ride around upon needs to pay for stabling, food and services of a groom in addition to the cost of purchasing the animal."

You could eliminate banks, or require the rent of a vault or guards to protect items and gold. Banks might not be fully secure. Maybe require installation of a safe to protect treasure and items.

Gold must enter the MUD at about the same rate as gold is used and leaves the MUD.

Summary of "Who's Who? A look at Character Sharing" by Kethry

Kethry played on the Mystic Adventures MUD.

Character sharing has strongly opinioned opponents and proponents.

Benefits include, being able to try out character types without a big commitment. Also, being able to use skills of characters that cannot be found in the current online population. It also staves off boredom for experienced players. Another benefit is splitting up the boring parts of leveling up or long quests. Also, it allows people to show friends what the MUD is like without going through the long process of character creation and leveling.

However, issues arise from sharing characters, including resentment by veteran players who see a new player that got everything for free. Also, the player sharing the character may no longer enjoy playing as a new character because they miss the power of the leveled character.

Other in-game issue arise, such as lost equipment or experience, users that want their character back from an unwilling sharer, and even changed passwords, deleted characters, or disciplined shared characters. The original owner of the character may be very unhappy with what happened to their account when they were away, and funnel that anger towards the admins that refuse to intervene.

Then there are the in-game social consequences of not knowing if the current player of the character is the same person you have already met. The original owner can log in to find people angry that them without any clue why. The issues of MUD security and governance come into play if the character is a builder or government official in the game.

The author suggests a ban on shared characters is best. "While there are benefits to the players with sharing characters, there is no benefit to the mud itself, and sharing characters can damage a mud."