Imaginary Realities 1998 November Edition
Third and final issue of 1998.
Summary of "Beyond Player Killing" by Sayeed
November, Continued from last month...
There are lots of strategies for lowering the PK count on a server that allows PvP.
Common PK implementation "limit the area(s) where Player Killing is possible by coding in the game engine to either neutralize damage done, limit who can attack or be attacked, or simply disallow PvP combat in Player vs. Player Combat ("-PvP") forbidden Locations."
PK-Switches allow the rooms or areas in the MUD to have a boolean PvP that determines if PvP is allowed in the room or area. Removing all PvP preventes the role-playing of super villians, and can hurt game play. Also, having PvP areas next to non-PvP areas may result in abuse of the non-PvP areas.
Allowing players to turn on PvP, requiring a quest to turn on PvP, or requiring players to role-play a monster class/race to PvP are common PvP measures.
Town guards could swarm players of ill repute.
Loot based measures, include limiting looting of Player Kills is another common measure, either by allowing the ghost to keep some gear/treasure, or preventing looting all items on the corpse. Other measures include, limiting monster looting of player corpses, limit looting of defenders but not attackers or evil characters, prevent looting of lower level than winner.
Here are other techniques for limiting Player Kills.
- Mark loot as "stolen" and only allow certain in-game buyers to "fence" stolen items and only in limited quantities.
- Limit the number of times a player can be PK'ed per day.
- Allow high level players to take on the role of a monster or a PvP'er.
- "Text Filtering- Allow characters to tag themselves Role Player, Non-Role Player, or Both and only allow their character to see text from other players similarly flagged."
- Have roving guards patrol roads and paths, attacking evil players.
- Have high level "good" players gain the ability to track "evil" players.
Summary of "Guide to Roleplaying" by Jarok
1998 November, Jarok was from Aarinfel MUD
Learn roleplaying by doing it.
To roleplay, you must first create a rough character, and then build the character's depth over time though interaction with events and other players. Being in character is "a form of improvisational theater."
Make roleplaying sessions cooperative. "Each player should try to balance their desire to push forward their own agenda with the right of the other players to express themselves and promote their own ideas."
Proactively create situations for your character and other characters to shift the MUD's world in directions that help every player move forward the plot of the MUD. Make up tiny bits of plot instead of just reacting to everyone else. "One of the telltale signs of a good role-player is how well they weave their plots and ideas into those of the rest of the mud."
Summary of "Rule making of roleplaying" by Michael A. Hartman
1998 November, Jarok was the main administrator and author of Threshold RPG.
Bad rules ruin great games.
In RPGs, names "are one of the first things someone sees when they interact with other players." If you want a consistent RPG feel for your game, you need to police names players choose in a consistent and firm fashion.
In Character (IC) communications in the game add to the immersive RPG experience. Keep IC and Out of Character (OOC) communications separate. "When people are inside your world, they should be acting like their character." Keep a dedicated OOC channel for non-IC communications. Make the OOC channel muted by default for a more IC RPG experience especially for new players.
Keep numerical information away from players. Knowing the exact combat formulas is distracting the the realness of the role playing. Discussions of such information should be limited to the OOC channel.
"Any system of rules, whether they are written for a roleplaying game or anything else, should be consistent both in design and application." Also, explain to players what rules they broke when correcting undesired behavior in the game.
Keep interpretation of your rules flexible so as to avoid "rules lawyers" from bending strict interpretations to their advantage and annoying you and average players.
Summary of "The search for identity" by Scatter ///\oo/\\
1998 November, "Scatter is the net-identity of a real person who hides somewhere in the UK. Being an enhanced personality, Scatter is much more helpful and friendly than the real thing and so is the best one to contact."
Many MUD's encourage roleplaying in-character (IC) and discourage out-of-character (OOC) behavior on the MUD server. Whether the player roleplays a character that is an enhanced version themselves, or plays an reverse image of their real-life self, the character they play tells a lot about them.
"One of the keys to a successful role-play game is for all the players to stay in-character and respond to other players' characters rather than to the other players themselves. This is the downfall of many face-to-face role-play games as a group of friends respond to the friends they know so well much better than to the dwarf veteran on the character sheet. A mud on the other hand can make it possible to know absolutely nothing about the players behind the other characters, and likewise have them know nothing about the real you." Anonymity makes it easier to roleplay, because players have less fear of being associated with behaviors in-game that they would never do in real life.
Moral implications arise when roleplaying is used to hide one's identity for malicious purposes. The question arises, "is using an alias [online] really pretending to be someone else or just an admission that you are someone else online?" Maybe you are both the online and real life versions of yourself.
Another potential pitfall of roleplaying, is relationships. If a player is roleplaying a different gender, but extends any relationships past the bounds of the game's roleplaying, strong negative emotions by other players could be encountered. "Role-play relationships are only okay as long as all parties involved really are role-playing."
Summary of "The Writer's Block" by Daniel McIver
"Daniel McIver is Gototh, Lord of the Ram domain on Discworld"
"An obvious easy way out for the area builder when they run out of inspiration is to go to great lengths in explaining how boring and non-descript the player’s surroundings are." Avoid describing rooms as boring. Instead, describe the boring things in the rooms. Descriptions of peeling paint and tree bark provide atmosphere to a room, and occasional humor. Use lots of adjectives, and consult a thesaurus when describing common features.
Avoid too much ASCII art. If you want lots of art, use a MUD interface that supports real pictures. "Text-based games aren’t good at showing graphics, and the appeal should really come from nicely written and presented text." Limit ASCII art to signs and occasional maps.
Summary of "Waltzing on with the mud client" by Andy Lewis
Andy Lewis was a player on Nanvaent, admin of Discworld and creator of Rapscallion MUD client.
Andy named his MUD client "Rapscallion" because of the medieval feel of the word, and with hopes that it would take on the connotation of MUD client with familiarity -- which it seems to have done. He avoided looking at existing MUD clients to encourage his own ideas and original approach to dominate Rapscallion's design.
"In reality, a mud client is nothing but a user interface, designed to suit any number of back-ends (muds) and with very few standards that can be depended upon. So it is essential that a client be as easy and efficient to use as possible." Using the Keep It Simple Stupid (KISS) approach leads to better software design. The mapping system in Rapscallion typifies this approach and benefitted from a simpler approach than other mapping systems.
Andy released the first version of Rapscallion MUD client in May 1997. Feedback was complimentary, and included bug reports/feature requests. He released 18 updates between May and November. Using feedback and feature requests, Andy realized he needed to redesign the next version of Rapscallion from the ground up using the experience he now had.
"Fred Brooks sums it up nicely in The Mythical Man-Month ... One of the decisions to be made when developing a new piece of software is whether or not to first build a throw-away version as a trial run. Brooks points out that this question is wrong - you'll always build a throwaway. The question is whether or not the throwaway is the one you'll give to your customers."
Are LPMuds dead? by Geoff Wong
LPMud driver development has slowed or stopped. Is Java a better solution for MUD engine development than LPC?
An LPC to Java compiler could be built with an LPmud emulation library. Java has concurrency. LPC does not. Java has better type checking than LPC. LPmud handles hot fixing existing code better than Java. LPmud has a MUD specific library. Java's libraries are made for general programming. Java has a better selection of development tools and IDEs than LPC. LPmuds are more stable than JVMs. LPmud does not have the large community support that the JVM has, so maintaining LPmud is difficult.
"In conclusion I don't think LPC is dead yet, but without significant injections of highly quality energy it is certainly on the decline."
Summary of "Assumptive and Suggestive Roleplaying" by Cayti Feric
Cayti owned Evolution and was a player on Aarinfel.
"Strengths and weaknesses provide that 3rd dimension to roleplaying, actions being the first and reactions being the 2nd." Listing the character's strengths and weaknesses helps avoid the character suddenly being able to do anything they see other characters doing. Weaknesses provide a way to create tension that needs resolving. Having weaknesses that conflict with goals of the character creates tension. Weaknesses make characters more believable and interesting to be around.
When describing what your character does, don't assume the response/reaction of the other player characters. Let each player character respond to what is happening to them, rather than assume their responses. "Being suggestive is saying what your character does, being assumptive is saying what your character does, and how it affects others."
Create hanging plots to add suspense/mystery to the ongoing campaign. Show a character doing something out of normal with no immediate explanation, or provide other clues, hints or yet-to-be-explained events that lead to a future resolution several days or weeks later.
Summary of "Comparative Skills" by St.Toad
Mobiles and players should have no differences other than the players have some control over the actions of their characters.
Traditional skill systems that use percent chance of success work well until used against opponent's skills. Then percent chance based skills fail to handle advanced skills pitted against over players skills. Also, advanced skills versus low skills don't take into account that low skills should rarely succeed against advanced skills, not just succeed a percentage of the time.
"Comparative systems work, as their name suggests, by comparing the skills of the attempter's and the resister's to work out which of them is successful. This has the benefit of making the result dependent upon the relative skills of the combatants, not upon their absolute skills." This leads to:
- Fast fight resolutions
- Handles skill disparities better
- High damage from attacks is not needed to make more skilled attackers more likely to win
Comparative skill systems allow for unlimited leveling of skills, rather than capping skills at 100%. Leveling of skills can be throttled by giving a certain number of practice sessions per level with a limited number of skill point to be distributed between their skills. This prevents characters from over-leveling all of their skills instead of concentrating on specialties. Also, make learning already leveled skill cost more training sessions or points to making gaining higher skill levels more challenging.
Ultimate goal of Comparative Skill Systems is to place the emphasis on skill leveling instead of character leveling. This should result in better roleplaying instead of killing everything in sight to level the character.
As an example, Cthulhumud used the following system for combat and magic:
Attack roll: level + weapon_skill + open_d100 Defense roll: level + defense_skill + open_d100
If greater than 95 was rolled on the d100, then another roll of the d100 was added. If less than 5 was rolled, then another another d100 was rolled and the second d100 result was subtracted from the total result. "Those familiar with Role-playing games may recognize certain similarities between this system and Iron Crown Enterprise's MERP and RoleMaster systems."
Summary of "Even movies have directors" by Richard Bartle
Richard ran MUDII and was co-editor of the Journal of Mud Research.
"Without a director, a movie would be a sloppy mixture of competing artistic views." Likewise, a book with several authors needs an editor to make the presentation consistent. MUDs rarely have the equivalent of an editor or director. They are thrown together with competing themes and atmospheres.
Putting one person in charge of artistic vision in a MUD will result in a better, more cohesive, and immersive experience for players. However, strong editorial control is not likely to happen in a free MUD. "You can't tell someone who's designing for your mud out of the goodness of their heart that what they have produced is shoddy, or out of context, or incomplete, or unoriginal, or jarring. If you do, they will go away in a huff - they don't HAVE to help you at all."