![]() |
Guidelines for an RPI mud.
Here's what I think the guidelines are for an RPI mud, seeing as how there's been a decent amount of discussion related to it recently. Maybe this forum can clear up answers, brings up more questions, and direct discussion into one thread.
1. Permdeath: This is not disputed, 99% of all RPI players/admins will agree to this. 2. Description-based: Meaning there are no names displayed, you need a short description, main desription, and long description. Also characters need to be well-described as well as with a good background. 3. Account based: RPI muds should use accounts to keep track of their playerbase, as well as their characters. Considering this, RPI muds should only allow 1 character active on players accounts at any given time. Accounts also allow the staff of the RPI to make notes and keep track of your characters you've played so that in the future perhaps you will be considered for a special role based on these notes. 4. No levels: Since levels are an OOC concept, RPI's should not have them. 5. Extensive, player controlled emote system - Players may create open-ended, custom emotes and have commands to help create these emotes. Stock emotes are not present. 6. Slower Paced World: RPIs should have a slow pace to the game in order to allow for and promote extensive emotes and reactions between players. This should be accomplished by slow paced combat and crafting systems and promoted heavily by administrators. 7. Items are descripion based: No Swords of Ultimate Doom, or Spears of Destiny. Every item has a description much like players are forced to have. 8. Immersive code: Via scripting an RPI mud should but isn't necessarily required to have various things that immerse the experience of the player, such as coded echoes that happen at certain times of the day, the sun setting, the sun rising. Also room descriptions should have a day description as well as a night description. 9. Mechanics Based World: Coded systems should be in place for most gameplay systems such as combat and crafting, and these systems are fully supported by code. This will help differentiate it from more MUSH/MUX type games. 10. Open PK - An RPI mud must have an open PK system that allows for PK at any time and any place. 11. No Global OOC channels: This is debateable. |
Re: Guidelines for an RPI mud.
That's the best list I've seen yet.
I would leave off #10 and #5. Honestly, if you don't require it, don't put it on the list. I would also change #6, 7, and 9. 6) Extensive, player controlled emote system - Players may create open-ended, custom emotes and have commands to help create these emotes. Stock emotes are not present. 7) (Dump realism. Slower pace doesn't denote realism in any shape or form.) Rewrite follows: Slow-paced world - RPIs should have a slow pace to the game in order to allow for and promote extensive emotes and reactions between players. This should be accomplished by slow paced combat and crafting systems and promoted heavily by administrators. I'd also add one: Mechanics based world - Coded systems should be in place for most gameplay systems such as combat and crafting, and these systems are fully supported by code. This will help differentiate it from more MUSH/MUX type games. --------- You're a brave man for posting the list, so I'll forgive you for skimming my posts and flying off the handle. |
Re: Guidelines for an RPI mud.
I agree for the most part.
You make a few good points, I edited my post down a bit and changed a few things. |
Re: Guidelines for an RPI mud.
Feel free to have "No levels" as a requirement, but you are making a mistake when you say "they are an OOC concept."
Levels are extremely realistic and have tons of real world analogues. I will give one example and stop there, for the sake of brevity: E-1 - Private E-1 E-2 - Private E-2 E-3 - Private First Class (PFC) E-4 - Corporal (CPL) E-5 - Sergeant (SGT) E-6 - Staff Sergeant (SSG) E-7 - Sergeant First Class (SFC) E-8 - Master Sergeant (MSG) E-9 - Sergeant Major (SGM) (yay! time to remort and become an officer, or pick my epic class, or some other game-like similar thing) => O-1 - Second Lieutenant (2LT) O-2 - First Lieutenant (1LT) O-3 - Captain (CPT) O-4 - Major (MAJ) O-5 - Lieutenant Colonel (LTC) O-6 - Colonel (COPL) O-7 - Brigadier General (BG) O-8 - Major General (MG) O-9 - Lieutenant General (LTG) 0-10 - General (Gen) I understand why some folks don't like levels. But saying they are "OOC" or "unrealistic" is patently absurd and false. If you are listing requirements for RPIs, you don't have to justify the reasons. If that is a requirement, then just say: 4) No levels. We don't like them. |
Re: Guidelines for an RPI mud.
I don't think you're comparing apples to apples there to be honest, Threshold.
Ranks in an organization are -not- the same thing as player levels as instantiated in D&D and most MUDs with the kinds of 'levels' we're talking about here. Ranks are an external thing granted by an organization, and they only have any importance if other people recognize them. For instance, start your own one-man organization and bestow the rank of "God Emperor" upon yourself. You won't actually be any more powerful, in any way, since nobody else will recognize it. Ranks, such as military ranks, are nothing more than titles that are backed up solely by the fact that some other people will recognize that rank and respect it (try ordering a fleet around when you're only a major, for instance....nobody is going to respect your rank enough to follow that order as majors don't get to command fleets). Further, a rank may be taken away at any time by the organization that granted it. Even a general can be stripped of his command by a single order. Gaining a rank grants you no instrinsic personal powers. You do not magically become capable of lifting a heavier object or thinking through a brain teaser when your rank changes from lieutenant to captain. Player levels as used in MUDs, on the other hand, are presented as something intrinsic to a person (in a way that makes sense as a game mechanic, but really seems like a fairly OOC concept). Simply being "level 50" inherently grants you more power than being "level 10", and it is presented as being part of you rather than simply a label. Things intrinsic to you are presented as having suddenly and inexplicably changed when your level changes. Suddenly you can get hit by a sword more often before you die, typically, for example, or suddenly you have the capacity to be more skillful at something or learn more than you did an instant previously. It's pretty hard to see that as anything other than an OOC artifice invented to allow people to measure their achievements easily (something people like doing, but something which is much fuzzier in reality). |
Re: Guidelines for an RPI mud.
Fine. No levels. We don't like them..
They are still an OOC concept. What am I a level 10 PHP administrator? Come on. You can't gauge things with levels, it's best to simply list the skill PHP and my knowledge upon the skill is either not known, I simply see the skill in my skills list or there are a few adjectives to show the player where they stand with that skill such as beginner, journeyman, master, whatever.A Also repeat Logos post. Nothing else to say. |
Re: Guidelines for an RPI mud.
The only comment I would make after some research and visiting the RPIMUD site is that it should be very clear that these Guidelines set forth in this thread are specifically Delerak's opinions. The RPIMUD site has several paragraphs of what some of the differences between a mud and rpimud are and how most RPIMUD's (from their site) are based on a DIKU modified code.
It is important to note this since alot of the definitions of RPIMUD are opinions of the creators and do not necessarily reflect easier roleplay or quality roleplay. If anyone would like a new thread based solely on RPIMUD definitions taken directly from that site I would be happy to do so and give commentary on the same. If no one really cares, I'd rather not take the time to do such extensive work. These comments above should in no way reflect a good or bad opinion of the Delerak's Guideline's only that his Guideline's are specifically his opinion. |
Re: Guidelines for an RPI mud.
This is true. I'm hoping other people will chime in though and give feedback, that way we can compile a real list of what the general community feels what embodies an RPI and what doesn't.
|
Re: Guidelines for an RPI mud.
No need, NW. I already did that here. :)
I should note that the listed owner of the site is no longer the person who runs it now. There's a new-ish team on board, and they're working on sprucing things up, I believe. That's very nice to know. Seriously, I know you guys must be wondering why I even care since I don't use the RPI tag and wouldn't use it even if every bit of my game fit every spec RPIs had for personal reason. I mostly just care because it affects roleplayers in the gaming community, and that's my community! |
Re: Guidelines for an RPI mud.
1. Permdeath - agreed, no qualifications, other than there might be instances in which a character would get resurrected - such as in the case of bug abuse by the character's killer or a game-side error.
2. Description-based: I feel that "well-described" and "good background" should be replaced with "a staff-approved description and background fitting with the game's IC history and setting." "Well" and "good" are just a bit too subjective, and getting too deep into proper punctuation and grammar and sentence structure could cause the #2 guideline to go on for pages and pages :) 3. Account based: I would personally simplify this: RPIs are one character per account, with one account allowed per player at any given moment. 4. No levels - just leave it like that: No levels. 5. Extensive, player controlled emote system - Players may create open-ended, custom emotes and have commands to help create these emotes. Stock emotes are either nonexistent or inconsequential (added that last bit, because sometimes brevity is best, such as "nod" or "smile."). 6. Slower Paced World: I'm not sure about the wording of this. I understand the intention, but saying "slower" is comparative. Slower than what? And how slow is too slow? And "should" have a crafting system - I've seen some crafting systems that are so complex that they detract from RP rather than add to it. No idea how to fix it but I think this point needs to be worked on. 7. Items are descripion based: I would say items must all have descriptions. Not be description-based, because that would make them part of a mush, not an RPI. Items in RPIs for the most part have coded functions. Unless they intentionally don't (such as "a huge boulder that you can't climb and just sits there doing nothing but we wanted it there for you to look at). 8. Immersive code: I would simply say: The code must support the roleplay, rather than the roleplay managing to exist despite or around the code. 9. Mechanics Based World: Agreed. 10. No visible "experience" points; obviously code in all games is numeric by nature, everything is boolean if you get down to it. But players in an RPI have no need to see the number of points required before they get a boost to this or that skill. Once again it goes to the code supporting the RP rather than the RP existing despite the code. |
Re: Guidelines for an RPI mud.
For the sake of discussion, please understand that if I did not list something, I agree with it.
Description Regulation present - Players are required to provide a detailed background and description for themselves. All character descriptions and backgrounds are reviewed and approved by the staff. Single Character Requirement - All players may play only one character at any given time. Your character must die or be retired before you can create an new one. I agree. This one gave me fits on how to phrase it. I didn't want to say "Slow" because that has a somewhat negative connotation to it. What about the following? Controlled Paced world - The game is designed to promote a pace that allows players ample time to create detailed emotes/poses. All systems, including crafting and combat, should be designed to create this pace. I think this should totally be nixed. It's completely subjective and a matter of opinion on what one person feels like supports their RP. You also don't need a list that's bogged down by opinions rather than serious, non-subjective requirements. Numberless experience system - Experience gained by RPI characters should be denoted solely via written descriptions. Leave off the "code supporting the RP" stuff or any opinions when you create this list. That's a total matter of opinion on whether or not it supports or detracts from RP. Well, that is unless you want RPIs to keep sounding like a list of personal preferences and judgment calls. |
Re: Guidelines for an RPI mud.
Actually, in a lot of operating systems and software packages, that is exactly what you would be. Your security level would be a number and it would directly reflect the amount of trust, capability, and access you are given.
Human beings are absolute fiends for classifications, rankings, and categorization. To say such constructs are fake or unrealistic is to ignore absolutely everything around you in the world and in life. If you don't like them, fine, just say you don't like them. I can completely understand that. But they are extremely realistic and have real world analogues. Now, if you are talking about people running around the game saying: "I am a level 10 fighter" then I can understand a little more what you are saying. But levels as a behind the scenes abstraction are not fake, "OOC", or unrealistic whatsoever. |
Re: Guidelines for an RPI mud.
What if the level is behind the scenes and the player never knows what their level is? Still a no-no? I am trying to get a handle on this anti-level thing. To me levels are an abstraction that is no different, better, or worse than skill levels. They are just numbers behind the scenes used to represent and adjudicate game mechanics. The salient point is whether or not such things are visible in numeric form to players (levels, skill levels, xp, etc.) rather than the mechanics themselves. Also, assuming you guys are serious about improving these definitions, it really is time to come up with a better term/acronym/whatever. RPI is extremely generic, and sounds more like someome saying "RP, but better than everyone else" when in fact RPI is really just a feature set some people prefer. |
Re: Guidelines for an RPI mud.
Got another one that I think MUST go on the list:
Open PK - An RPI mud must have an open PK system that allows for PK at any time and any place. Explanation: The reason that this has to exist is that death should be a real possibility in player vs. player conflicts. Systems that have opt-in or flagged PK shouldn't be permitted. It's a given that there should be RP reasons behind PKs, but we're assuming that RPI players are there to be RPing, not PKing people for kicks. Thus, we'll keep it simple. |
Re: Guidelines for an RPI mud.
Just some quick thoughts before I turn my attention to dinner. Mmmmmm...food!
Not completely true. There are examples in both combat and other areas which do not allow ample time for detailed emotes or even any emote at all. A pair of good examples would be falling and death. Both can be role-played around but at times circumstances simply do not allow for it. With the use of a climb skill, it is possible for a player to fail the skill check, resulting in a fall. The effect is sudden, as a fall would be. Additionally, it is possible for there to be areas where fall rooms exist. Stepping into them immediately sends a player into a fall to the room "below". Now, while a player can identify the potential for a fall and emote accordingly, once the actual fall is activated, they do not have the opportunity to emote before the action occurs. Some RPIs, SoI was the first I believe, use color to denote fall rooms (if the direction north is red in the exits list, it's a fall room), this allows a player to emote the necessary emotes before executing the command. However, given that the player can not ascertain what may lie beyond the fall (outside a notion based off of the present room's description), most are loathe to RP such an action. Hence, most falls occur due to unintentional causes and no emotes accompany them. Likewise death typically does not afford one the ability to control the pace. A classic personal example I can give is a guy who walked up to the gates of an enemy fortress. He was immediately spotted by the NPC guards in the watch towers who hailed down a rain of a dozen arrows into him. Dead near-instantly, as he should be for doing such a thing and given the nature of the response. Thus, use of the term "all systems" is not accurate in describing RPIs. Rather than the word "experience", I would suggest aptitude, ability, or another like term which is not used by many MUDs to denote a completely different thing the way "experience" is. That's really the heart of it though. The original RPIs were massively re-written code, so much so that aside from some familiar syntax and commands, they were almost indistinguishable from their original codebase. Rather than "RP", I would however suggest the term "code supporting the world design" to delineate it from "world design supporting the code". That would be a factual description of the process by which the code came into being. It was designed to support the features of the world design (Harshlands' world is based off the Harn gaming system world, Armageddon's gameworld has similar P&P roots). The design and implementation of perma-death code is a classic example of this. While permadeath is a feature, the "code follows world design" is a philosophy, but both are part of the defining characteristics of RPI. Concern for others and for the community is a noble concept. I rarely question why someone cares. I typically question when people say they don't care. ;) Take care, Jason Mmmmmm...food! |
Re: Guidelines for an RPI mud.
Maybe not military ranks (although that's arguable because surely, in theory, someone with a higher rank is better at their job than someone with a lower rank) but things like belts in martial arts are very analogous to levels in my mind. A black belt karate master is, in nearly all cases, going to be stronger, faster, fitter, and able to take more punishment than a yellow belt student. I'd have to agree with Threshold and say just because you don't like levels doesn't mean they can't be applied in a wholly-realistic RP way.
Actually, the same could be said about permadeath. For some reason a lot of people equate "good RP" with "realistic RP", where realism is based on how real-world it is, and that's just not true. If your world happens to be one, for instance, where everyone has a clone and their mind is instantly transported to it upon death, as long as the RP of the players is in keeping with the world then there's no reason permadeath has to be part of an RPI. For people who say "it's not realistic because there's no way of getting rid of someone" well, it might not be realistic when applied to real-world concepts, but good RP is surely gameworld-based and if that world has no death can you really sneer at it and say it can't be RolePlay Intensive? |
Re: Guidelines for an RPI mud.
I knew I was forgetting something. I totally agree.
|
Re: Guidelines for an RPI mud.
To say that a game requires a "slower" pace is simply a crutch being used because a player can't type fast enough to react to a situation or the environment around them. It is a lot like being pumped up with painkillers and trying to deal with a conveyor belt. Does anyone think that a real life soldier under fire in a foxhole in Afghanistan is in a "slow" or "controlled" environment? Effective communication in any kind of environment is a skill in itself.
SOME people can type as fast as they can speak, others can't. This same problem exists even on graphical muds, hence the usage of Ventrillo and other speech programs for combat-intensive and other "special" situations.This is also why a good number of commands in muds are abbreviated. As for levels...life is made up of patterns and numbers; there is math everywhere, completely invisible to most. I could sit down and speak to someone about my management experience/ability for an hour and still not get them to understand (for whatever reason). However, if I say, "On a scale of 1 to 10, I'm an 8," anyone that can speak English will likely understand right away. Quantifying oneself with numbers in any fashion isn't unrealistic at all, they are simply a tool to understanding. I might be an "A" student, have a 1650 SAT score, have a 185 IQ, etc. These are all ways of personally quantifying myself. Heck, in traditional D&D, a character's intelligence score multiplied by 10 was supposed to represent one's IQ. Since I have been a gamer for years, I often quantify myself with levels by how many years I have spent in any particular field (level 6 soldier, level 13 manager, etc.). |
Re: Guidelines for an RPI mud.
The problem with lag-free, fast-paced environment is it doesn't allow time for roleplay, emotes, and it isn't realistic. To be able to run from one end of the mud to the other in under 1 minute is not realistic at all, hence the reason for delays when you move. Saying it's because people can't type fast enough is ridiculous, I type 140 WPM and I would never play a delay-free roleplay mud, it's unrealistic and doesn't cater to the RPI player.
Also using levels on an RPI is again unrealistic, the only way you know you're an 8 on a scale of 1 to 10 is self-knowledge. Our knowledge of ourselves is something that makes us unique, it allows us to say that, the question is should every character know how powerful they truly are? Does any boxer or fighter, or police officer ever truly know how good they are? If they practice every single day, yes. They do, but not in terms of code. If I practice with my gun everyday and hit the bullseye 20 times out of 25, I know I'm a pretty good shot, but by no means do I know the potentenial of everyone else compaerd to me, and where I stand on that potential scale of numbers. When you use levels, you're telling the players, this is how powerful you can get, and now you know where you stand: when you don't give them levels to go by, it increases the realism, of now knowing how you stand compared to others, and you yourself not truly knowing unless you practice with the character everyday and know that he's getting stronger. Also skills might have adjectives to describe how good you are in that skill. |
Re: Guidelines for an RPI mud.
I still disagree, forcing any pace in a game is simply a crutch, period. If one's goal is to create the "illusion" of space and distance, so be it.
Your argument for not using levels is justifying WHY levels and structure ARE placed in any game; so that everyone is being judged/measured and set within the delineated structure in a "fair" relation to eachother (the other players) by an outside party (the implementors/game masters). The core argument here is whether levels and other numbers should be used (i.e. viewable to players) or not, so that immersion is maintained. |
All times are GMT -4. The time now is 11:31 AM. |
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright Top Mud Sites.com 2022