03 Feb, 2010, KaVir wrote in the 1st comment:
Votes: 0
I enjoy seeing what features other muds have implemented, but I find 'bad' features just as interesting as 'good' ones. We frequently see people advertising what they consider to be their best features, but their unsuccessful features tend to get swept under the carpet, or have their failings glossed over.

Sometimes a feature sounds pretty good when you're designing it, but after seeing it in action you really wish you hadn't added it. Sometimes you look at other people's muds, and you can understand why they decided to add a particular feature, but after seeing it in action you're really glad you didn't add it to your own mud!

Disclaimer: Obviously much of this is down to personal opinion. But as I'm the one posting, I'm going to share my opinions of specific implementations of features that I have seen that I dislike, along with my opinion of why someone might add such a feature, and the solution I would use if I wanted to achieve that same goal. Responding with "feature X doesn't always work like that" is missing the point - because if it doesn't work like the implementation I've seen and described, the chances are it's not the implementation I'm criticising, and therefore the better response would be "another solution to feature X that I've seen is…"


Feature 1: Remorting

Description: Various 'remort' classes are available. To join a remort class you must first reach the top level in a regular class, at which point you can restart at level 1 in a stronger remort class.

The theory: Existing game content gets reused, giving the players more things to do after reaching maximum level, and the new remort classes provide additional variety.

In practice: Players are forced to more or less restart from scratch if they wish to progress beyond a certain point. If they don't do this, they'll be at a disadvantage in the long-term.

Proposed solution: Provide variety through subclass specialisation (i.e., you branch out at a certain level instead of returning to level 1). If you want players to reuse the content, then make the classes sufficiently unique and interesting that players will want to create a different character of each class.


Feature 2: Advancement based on class/race strength

Description: Certain classes and/or races are more powerful than others. This is balanced against a higher exp cost per level, resulting in slower progress for the more powerful characters.

The theory: Players can choose to create characters based on their playing style and how much time they're willing to invest. A hardcore player might choose to create a powerful character, while a casual player might create a weaker one.

In practice: Stronger characters require massive amounts of grinding to progress, but are actually easier to play (because they're stronger than mobs of their own level), and once everyone reaches maximum level the strong characters will dominate the game. In effect, if you wish to play competitively you're required to grind a strong character through an excessive number of unchallenging fights.

Proposed solution: It's okay for some classes/races to be more difficult or time-consuming than others (as long as players are warned in advance), but they shouldn't be 'stronger' or 'weaker' than other choices. Some players will take the more difficult option for the prestige value, and if you want further incentives you should look into ways of making the difficult classes/races stand out from a "coolness" perspective.


Feature 3: Full multiclassing

Description: Characters can earn levels in every class.

The theory: Players aren't forced into a single role chosen at the start, but can instead mix and match levels from all of the classes as they advance, based on whatever they feel like at the time.

In practice: If you don't level all your classes, you'll be at a clear disadvantage against those who do. This effectively results in the top level characters all being the same. Furthermore, because you have access to the abilities of every class, there is no incentive to create new characters to try out different classes - meaning each player will typically only experience the game content once. As everyone can tank/heal/etc, there'll be little need for group-play, unless you're simply recruiting raw numbers to hurl at a large mob.

Proposed solution: Design a proper classless system, using a skill tree/web to encourage specialisation while also allowing a fair degree of diversity (i.e., so that each character can do something particularly well, but they can also have a diverse range of lesser abilities).


Feature 4: Unlimited advancement

Description: There is no theoretical maximum level - you keep improving your character forever.

The theory: Players get bored when they reach maximum level. This ensures they've always got something to do.

In practice: With no 'maximum level' goal to aim for, gameplay turns into an endless grind.

Proposed solution: Find something else to entertain your top level players.


Feature 5: Random magic items

Description: Mobs drop random magic items, or perhaps preassigned item types but with random bonuses.

The theory: The randomised bonuses ensure that (almost) every item is unique, giving players an incentive to keep hunting for better equipment.

In practice: Competitive players feel obliged to spend countless hours farming mobs, in the hope of getting something better. Endless gameplay soon becomes endless grind.

Proposed solution:

Still working on this one, but options include reducing the random element, improving crafting options, and providing players with a means of trading instead of grinding for the bonuses they want.


Feature 6: Fully manual combat

Description: Players can fully control their actions in combat, entering both offensive and defensive commands to indicate the actions their character should take.

The theory: Many people find automated combat boring. Manual combat is much more interactive, and rewards player skill over character skill.

In practice: As combat becomes more and more complex, it becomes increasingly difficult for the player to react in time. If you reach the point where the players are required to write scripts in order to compete, then you've effectively gone back to an automated combat system with the added drawback of a higher entry barrier for new players.

Proposed solution: Don't require players to make complex lightning-fast decisions, because otherwise they'll always come second place to a trigger. You cannot stop people writing scripts, but you can reduce the value of scripts to the point where most people don't bother with them. One option is to remove the complex decisions (eg automate defences), another is to increase the thinking time (eg turn-based combat).


Feature 7: Automated quests which reward quest points

Description: Players complete various automated quests in return for quest points, which can be used to buy various enhancements.

The theory: Quests provide a break from the grind of killing mobs, giving players something else to do.

In practice: Players require quest points to buy the enhancements, which in turn are required to stay competitive, meaning that quests soon turn into a second layer of grind.

Proposed solution: Either have the quests reward regular exp, or provide another way to earn quest points. Alternatively, have the quest points used for non-enhancement bonuses such as fancy titles and renamed equipment.
03 Feb, 2010, Kline wrote in the 2nd comment:
Votes: 0
I guess I'll address the features in your list that I are currently implemented in my own code.

Remorting
Players can remort, but it is a second tier of classes beyond their mortal levels. There is no starting at level 1 again, it's just another stepping stone on the path toward the final level. Typical Ack derived games go Mortal (5 classes) -> Remort (2 classes) -> Adept (1 size fits all). Remorts typically fall in line with mortal classes, and while players are not restricted in choice, they typically choose to advance in the same fashion as their mortals due to the skills aligning better with their stats and being able to learn abilities to a greater degree. So Warrior -> Knight, Mage -> Sorcerer, etc. Some people do the opposite, though, to try and create a more balanced character instead of something so specialized.

Advancement based on class/race strength
I just recently implemented something slightly similar to this. During creation when players choose a race they can view all the stats/details of each race before they pick. Each race is assigned a "suggested order" of classes from best to worst. If you stick to this order 1:1 you have a 10% reduced cost to level (per class) and all skill caps are increased 10%. Every step you deviate from the suggested order is a 10% penalty in higher exp costs and lower skill levels. So if you're willing to take a 2-3% increased failure rate on a few skills and pay a bit more exp to level, it's still possible to mix/match your own creations how you want to, if you believe that will leave you the strongest in the end (based on certain race stat caps, or racial bonuses, etc).

Full multiclassing
I recently did away with this, as I didn't like how homogenized people were due to it. Previously there were 5 mortal, 5 remortal, and 1 adept class choice (see point 1 of how advancement works). You got 5/2/1; so mortal classes were devauled in that everybody had the same skillset and there was only minimal specialization in the remortal tier. To rectify this all races now only get 3 mortal classes (so we are to a 3/2/1 system) except Humans, which get 4, due to having no other racial skills or bonuses. Every class was also given a unique ability or bonus if it is your primary or first class. IE: When a Warrior lands a crit they do 2.5x the damage on that hit while a regular player only does 1.5x; Mages occasionally get a free spell cast; Healers get 10-15% reduced mana cost on healing spells..etc. I haven't ran numbers on the balance of the unique bonuses, but I'm certain it wouldn't be hard to tweak to where every choice had its own advantage given certain situations. Also, with adding distinct armor types only usable if you know the skill, people may have to pick classes differently depending on the armor type and the bonuses it grants they want to wear. A Mage may want to remort into Knight, for example, to wear plate armor and have more hitpoints and survive more blows in PVP. Or they may not, and choose to stick with the cloth armor they normally wear.

Automated quests which reward quest points
I have this feature too, but the quests reward qp, exp, and a small sum of money. There are also quests that players can request from a quest master and are randomly generated for them to hunt something, gather things, etc. These manually assigned quests also grant qp, exp, and a small sum of money, but the rewards are greater than the automated system due to the increased difficulty. QP may also be rewarded for immortal run games, events, or MUD-wide deathmatches.
03 Feb, 2010, KaVir wrote in the 3rd comment:
Votes: 0
Kline said:
I guess I'll address the features in your list that I are currently implemented in my own code.

Looks like your solutions are pretty much the same as mine, except for the full multiclassing issue, which you solved in a different way.

Personally however I would only use the term "remort" to refer to a system where you literally "re"-mort(al) back to the start.
03 Feb, 2010, Kline wrote in the 4th comment:
Votes: 0
Here's one I dislike (sorry for not including any earlier, didn't have any fresh in my mind :)

Diku-wait / Artificial Lag
Description: Diku's are known for a WAIT_STATE applied to the player after each command use. The more powerful the command, the longer the wait. This delays the player's next command from processing for X amount of time. To the player, this just feels like a slow connection.

Theory: We don't want players to spam their strongest ability nonstop to win.

Practice: Players end up feeling like the MUD is lagging or have a command queue stacked so deep they are unable to properly react in an emergecy, ie: when a fight takes a turn for the worse.

Proposed Solution: I kept a minimal amount of this delay on things like movement (I'm talking < 1s in most cases) so that I could still allow spells like 'slow' to actually 'slow' a player in different aspects. All communication commands have no delay (though I may later make an auto-squelch after X chats in Y time, to prevent malicious spamming, if it becomes an issue). Combat commands are split in an offensive/defensive cooldown system. Stronger attacks place your O or D on cooldown for longer. Spells also function in a similar manner in that you 'cast <spell> <target>' and your character begins chanting the spell, free to interrupt the process by moving or doing other actions, and the spell casts once the timer is complete.
03 Feb, 2010, Kayle wrote in the 5th comment:
Votes: 0
I can't think of any MUD features that haven't already been covered… But the title of the thread made me think.. You know what else looks good on paper and horrible in practice?

Communism.
03 Feb, 2010, Lyanic wrote in the 6th comment:
Votes: 0
Great post, KaVir. I agree with 90%+ of it. I'm also happy to say that I didn't succumb to a single one of those design traps in my own game. Does that mean my game has no features that sounded better in theory than they are in practice? No. Actually, I would be interested in hearing opinions on that from people who have played The 7th Plane (Kayle, for instance). I know of at least two. Maybe I'll post those, along with some others I've seen on other games, later. Right now, though, I'm going take a nap…
03 Feb, 2010, elanthis wrote in the 7th comment:
Votes: 0
In terms of MUD-land and not RPG-land in general, my biggest gripes are really UI issues.

Colorful Rainbows are Colorful

Description: Builders and coders end up using color in all kinds of ways to try to give a visual representation of the subject being described. Examples include having titles like "Red Baron Inn" where the Red is in red, or a "striped lizard" where each letter alternates between two colors. Sometimes they try to use color to portray gameplay information, such as putting mob names in different colors based on difficulty tier and using the same set of colors for object names based on power tier.

The Theory: Use of colors in descriptions makes the game more "graphical" and hence easier to understand and play.

In Practice: The colors become meaningless overall, draw the players eye from the important details to unimportant flair (much like putting a blinking neon sign over an unimportant detail in a graphical game), or end up making differentiating between two distinct entities harder than if they were both without color.

The Solution: Take a class on art appreciation, color theory, human-computer-interaction, web design, game level design, or human sensory biology. Learn how the human eye processes colors, shapes, movement, and text, and how the brain interprets those signals. Learn how to use color to organize information and direct human recognition of patterns.

Shell-like Commands

Description: The UNIX-shell is awesome, and scripting is awesome, and programming is awesome, so the MUD should take commands that read like a complicated domain language. This can range from literal script-like UIs to command interfaces that are simply very terse and rely heavily on special characters and formatting to communicate player desires to the engine.

The Theory: The use of numbers and formatting in commands keeps commands small and easier to type, and lets players play faster.

In Practice: The learning curve is very high, commands are difficult to document and explain concisely, and players still end up using aliases anyway.

The Solution: Use a more natural, English-like approach to commands. A new player can grasp the meaning behind "give <item> to <person>" much easier than they can grasp "give <person> <item>". More English-like commands also reduce the need for special characters to denote boundarious, as the proper verbs and prepositions (like "to") automatically provide separators between object and indirect-object while the command-like interfaces end up needing {} around words or other cryptic separators. Also, clearly analyze the use and importance of your game's commands, and ensure that the most common and most important commands are short and easy to learn, and provide-built in aliases to short-hand them further for players comfortable with such things, e.g. have a built-in alias of "go northwest" to just "nw". For things like referencing specific objects, prefer formats like "my second sword" versus "2.sword" or so on. You can offer terser commands for players comfortable with such things (some players accustomed to Diku-MUDs might even demand such shorthands), but they should be optional fallbacks, not the primary UI. With a properly-paced game, the longer commands are not an issue, and the sensible aliasing will reduce the impact.

Information Overload

Description: As much information as possible is given to the player at all times. The prompts have 5+ terms, room descriptions are large, every character, item, and exit in the room is given a full sentence of description in the output, and character sheets and other information commands present full pages of statistics, bars, and descriptions.

The Theory: The more information the player has the better decisions he can make. The more descriptive the room descriptions the more immersive the game will be.

In Practice: Text is slow, and most of the information is boring. The player is generally interested in only a very small portion of the information at any given moment in time, and dumping as much as possible to his screen simply forces him to shift through it all and find the bits he wants. The descriptions are possibly appreciated by newer explorer-personality players but are most often ignored by everyone else. Overly complex game systems require a very high learning curve for the player to process all of the numerical information present and makes decisions regarding skills or equipment very time-consuming and stressful.

The Solution: Describe rooms succinctly, leaving in only the important details, a single distinguishing landmark (which can often be just a different room title), and eschew extraneous fluff details. Objects and characters should present any and all truly important information about them solely in their (short) name. Use color to differentiate between hostile mobs and friendly mobs or players, so a player can instantly see if there's a threat in the room without reading through a long list. If there is an important difference between two swords, don't call both them "sword" with a description to differentiate them, but instead call one "longsword" and the other "shiny sword" (as an example). Reduce game system complexity to the point that a player can learn and understand the system with only a reasonable investment and so that deciding between +10STR and +8CON doesn't require popping onto forums and debating for 6 hours about the mathematical advantages for either compared to a certain skill build on a particular class within a certain level range in a specific zone when Mars is within a 37% alignment with Saturn, and thus reduce character stat screens to smaller data sets that can be easily looked over and understood at barely more than a glance.
04 Feb, 2010, David Haley wrote in the 8th comment:
Votes: 0
elanthis said:
Reduce game system complexity to the point that a player can learn and understand the system with only a reasonable investment and so that deciding between +10STR and +8CON doesn't require popping onto forums and debating for 6 hours about the mathematical advantages for either compared to a certain skill build on a particular class within a certain level range in a specific zone when Mars is within a 37% alignment with Saturn, and thus reduce character stat screens to smaller data sets that can be easily looked over and understood at barely more than a glance.

These are separate issues: the consequences of making this choice over that choice, vs. reducing the amount of data presented (or relevant to) character stat screens. It's not like reducing the number of stats automatically makes the choice between stats easier to figure out.
06 Feb, 2010, elanthis wrote in the 9th comment:
Votes: 0
Quote
These are separate issues: the consequences of making this choice over that choice, vs. reducing the amount of data presented (or relevant to) character stat screens. It's not like reducing the number of stats automatically makes the choice between stats easier to figure out.


Yeah, I realized I had tangented off into a separate issue, but was too lazy to separate them out. :p I should leave that tangent out entirely since it's a general game issue and not a MUD-specific issue. But hey, tangents and me go together like gin and lime juice. Mmm.

The gist of the point was that MUD output is limited and you should be able to present all necessary information, and if you can't, you need to reduce the amount of necessary information to what can be displayed. A graphical game actually has more leeway here since you can pack a lot more information into a graphical display; take the best laid-out MUD character sheet you've ever seen, and then let that skilled designer do a graphical version, and you'll see how the extra flexibility either (a) lets them pack in more information, (b) lets them simplify the character sheet's layout to be even more readable, or © can just make it look better and more interesting and actually engage players that don't normally care much about such things.

Yet another reason I'd like a standard CSS-like layout and display engine through ZMP in a MUD client… can do so much more that way.
08 Dec, 2012, KaVir wrote in the 10th comment:
Votes: 0
Here are another three I posted on MudLab but forgot to repost here:

Feature 8: Realistic equipment manipulation

Description: There's no concept of inventory - instead, an item that's picked up is moved to one of your hands, and can then be placed into a container you're wearing. Equipment is also layered, so that you have to wear your underpants before you can wear your trousers, and then wear a codpiece after that.

The theory: Magic "floating bubble" inventories are unrealistic, and layered equipment adds both cosmetic and strategic elements to the game.

In practice: Moving equipment around becomes a painfully frustrating chore.

Proposed solution: Either stick with inventories as an abstraction, perhaps with some thematic or cosmetic justification, or use containers and make the distinction invisible to the player (by automatically moving equipment into and out of your worn containers). Layered equipment is a nice feature, but forcing players to remove layers before they can wear/remove something underneath is annoying - either automate it, fake it (with cosmetic messages) or ignore it.


Feature 9: Tag-based character recognition

Description: You don't see the names of other players, only a short description. However you have access to a command that allows you to 'tag' someone with a name of your choice - so that if someone introduces themselves as 'Bubba', you can literally tag them as 'Bubba' and that's the name you'll see from that point on.

The theory: From a roleplaying perspective, it doesn't make sense that you'd automatically know people you'd never met - but equally, a character would remember many of the people they'd met, regardless of the player's memory. The tagging system allows you to identify people you've met previously, whether by name (after roleplaying an introduction) or action (eg tagging someone "the mugger" after they've mugged you, so that you'll remember them next time).

In practice: It gets really confusing trying to keep track of different people, particularly when players lie about their names - "Have you seen Bubba?", "Who's Bubba?", "That guy you were chatting with this morning!", "That wasn't Bubba, that was Boffo", "No, Boffo is the guard", "No, the guard is Biffo", etc.

Proposed solution: Only allow characters to introduce themselves by their real name (if secret identities are an important part of the mud, allow players to create a limited number of alternate identities with different names). Perhaps allow tagging for flags ("killer", "thief", "mugger", etc), but don't use it as the primary means of identification.


Feature 10: Paired race/class combinations

Description: Elves make the best mages, halflings make the best thieves, orcs make the best warriors, etc.

The theory: Each race is good at different things, and each has its own unique niche.

In practice: If you don't pick the right race for your class, your character will be inferior to those who do; you can either play an "elf mage" or a "rubbish mage". At this point, races are no longer really a choice, they're effectively part of the class - or a permanent mistake that'll cripple your character.

Proposed solution: Ideally, each race/class combo should be equally viable. Perhaps the orc warrior is stronger than the elven warrior, but the elf should be able to compensate in some other way (such as agility). If you really don't want certain races to be good at certain classes then either ban it outright (eg dwarves can't be wizards), compensate in some other way (eg dwarven wizards are weaker spellcasters than most wizards, but also better fighters) or replace it with a new race-specific option (eg a geomancer class that's only available to dwarves).
08 Dec, 2012, KaVir wrote in the 11th comment:
Votes: 0
And here's one inspired by a post on the FutureMUD forums, where they seem to be implementing a lot of developer toys.

Feature 11: Differently sized equipment

Description: Items and characters have different sizes, and you can only wear equipment if it fits (depending on how stretchy the item is).

The theory: Realism!

In practice: Players can't use most of the loot they find.

Proposed solution: Realism shouldn't come at the expense of fun. Equipment sizes can be glossed over, or used for cosmetics for dynamic object descriptions, but don't add features if all they do is make the game frustrating.
08 Dec, 2012, plamzi wrote in the 12th comment:
Votes: 0
I can't agree more.

To this I'd like to add that, in general, there are precious few features that can add realism and fun at the same time. Harmless realism is very hard and it's only with utmost caution that you can navigate the whole realism minefield.

Lately, I've been thinking that anyone advocating "realism for its own sake" should start by contemplating the following:

1. Unavodable permadeath.
2. Characters spending a couple of months healing after each serious battle wound.
3. Removing all magic.

Hopefully, by the time you get to #3, you will remember that "non-realism" is a big part of the reason games are fun, and you'll be cured.
08 Dec, 2012, Rarva.Riendf wrote in the 13th comment:
Votes: 0
Quote
Proposed solution: Either stick with inventories as an abstraction, perhaps with some thematic or cosmetic justification, or use containers and make the distinction invisible to the player (by automatically moving equipment into and out of your worn containers). Layered equipment is a nice feature, but forcing players to remove layers before they can wear/remove something underneath is annoying - either automate it, fake it (with cosmetic messages) or ignore it


Ok let see how you deal with that though: Stealing of objects is only accessible if they are not in containers. You may say:only show what is stealable to thieves. But that is the point: everything is, unless hided in container, and the reason is once you are in a fight, access to container is taking more time than acessing your direct inventory.
Want to drink a potion while in fight, either you have it right at hand (but risk of have it stolen the second before you get in fight and not realize anyone did) or hide it in a container well tied to you, but make it less available.

Objects can be damaged by the breath of a dragon, you can protect the container from fire put everything in it and close it, making them protected all at once.

I have a personal container that can store an infinite number of objects, but at a point it becomes to heavy to be carried around. You can drop it whereever you want, and only you,or the one that steals your key, or the one you give a copy of key can see it. You lose the ability of stealing stuff from it.

I probably have other special use for container but just thought of those one.

But I allow people to carry whatever number of object they want 'on themselves', I consider those objects just being magically tied to them by magic, floating around for their direct use. Magic is part of the world anyway.
But container do add gameplay that would not be possible withtout them (or so I think, I would have no idea how to do what I described without them)

Quote
Feature 9: Tag-based character recognition

In a world populated by a thousand mobs but only a few players, it is easy to say that those are heroes, so are known by their name by everyone, mobiles included, so those can give their description name to whoever ask. Problem solved. :)
13 Dec, 2012, KaVir wrote in the 14th comment:
Votes: 0
Rarva.Riendf said:
Ok let see how you deal with that though: Stealing of objects is only accessible if they are not in containers.

Obviously in order to "make the distinction invisible to the player" you'd need to make multiple changes. If you have a "steal" command that normally takes from the inventory, you'd need to have it take from containers. If you have a "enter" command that lets you climb into someone's inventory, it should instead move you to one of their containers, and so on.

Rarva.Riendf said:
In a world populated by a thousand mobs but only a few players, it is easy to say that those are heroes, so are known by their name by everyone, mobiles included, so those can give their description name to whoever ask. Problem solved. :)

Yeah, choosing not to implement the feature at all is also an option, but I was trying to propose other solutions as well. The feature itself can be quite nice, it's just that particular implementation which didn't work out very well (I've implemented both types of introduction system in the past, although I currently use neither).

KaVir said:
And here's one inspired by a post on the FutureMUD forums, where they seem to be implementing a lot of developer toys.

It looks like they're now going to implement feature 8 (realistic equipment manipulation) as well. To be fair, I used to think that was a cool feature too, it was one of those things I had to implement for myself before I realised how annoying it is.
14 Dec, 2012, donky wrote in the 15th comment:
Votes: 0
KaVir said:
It looks like they're now going to implement feature 8 (realistic equipment manipulation) as well. To be fair, I used to think that was a cool feature too, it was one of those things I had to implement for myself before I realised how annoying it is.
Reading this thread leaves me with more questions than answers.

Are you saying that it can only ever be done in an annoying way? Are you saying that someone couldn't do it in a way that not only wasn't annoying, but fleshed out the game in interesting and "playable" ways? If someone reads one of your "bad decisions", can they really accept the "in practice" problems without context? Is it possible this is done from your perspective, and is as a result not entirely helpful because it is subjective and no-one can fully understand the reasoning, in the way you do? If done in an objective way, with "in practice" described through backed up case studies, could people better grasp the standard ways in which these "bad decisions" have turned out, so as to avoid them?

I know that not all "bad decisions" are those taken in making "stock-like" MUDs, but I think if one were to list the "stock-like" qualities for different "stock archetypes", then one could make a fair list.

Opening a MUD takes a lot of work, and relies on persistent efforts which might wax or wane. Is it wrong to make "bad decisions" if taking the standard path helps maintain momentum, focus and interest and actually gets one to that open stage? How many people have veered from the path, because they didn't want to make some of those "bad decisions" and because of this lost focus, and never made it? If one accepts that one can take the standard path and make "bad decisions", then can't one do it with a view to refactor those "bad decisions" into a "good" form? Is there a body of MUD players who accept those "bad decisions" because it provides a standardised experience, which they are used to? What are the repercussions with respect to player acceptability, of changing a standard "bad decision" to a unfamiliar "good decision" approach?
14 Dec, 2012, KaVir wrote in the 16th comment:
Votes: 0
donky said:
Are you saying that it can only ever be done in an annoying way?


KaVir said:
Disclaimer: Obviously much of this is down to personal opinion. But as I'm the one posting, I'm going to share my opinions of specific implementations of features that I have seen that I dislike, along with my opinion of why someone might add such a feature, and the solution I would use if I wanted to achieve that same goal. Responding with "feature X doesn't always work like that" is missing the point - because if it doesn't work like the implementation I've seen and described, the chances are it's not the implementation I'm criticising, and therefore the better response would be "another solution to feature X that I've seen is…"
14 Dec, 2012, Igabod wrote in the 17th comment:
Votes: 0
Donky, he wasn't asking everybody to agree with him. Nor was he asking everybody to just take his word as the final say in the matter. From my perspective he was just trying to spark a conversation and possibly get others to contribute their own experiences. This is a way for developers to learn from the mistakes of others and to get an outside perspective on some key features. This thread could even provide people with solutions to the common problems if people participate in it the way it was intended rather than taking the righteous and indignant stance that you seem to have taken.
14 Dec, 2012, Rarva.Riendf wrote in the 18th comment:
Votes: 0
Quote
Are you saying that it can only ever be done in an annoying way?


I will talk for me, but I would say yes. Push realisitic eq manipulation, means you have to push for realistic object carrying, at the risk of being incoherent, totally breaking the suspension of disbilief.
Then you enter the word of simulation. Fine if you want to do one. (I dunno of any 'succesful' game having a realistic object manipulation system, be it a text or graphical one)
If that many good game designer, for more than 30 years could not get a good one. I think it means something.
15 Dec, 2012, donky wrote in the 19th comment:
Votes: 0
Igabod said:
Donky, he wasn't asking everybody to agree with him. Nor was he asking everybody to just take his word as the final say in the matter. From my perspective he was just trying to spark a conversation and possibly get others to contribute their own experiences. This is a way for developers to learn from the mistakes of others and to get an outside perspective on some key features. This thread could even provide people with solutions to the common problems if people participate in it the way it was intended rather than taking the righteous and indignant stance that you seem to have taken.
What righteous and indignant stance is that? I asked some honest questions I was curious about. I am happy for Kavir to develop or advocate developing any way he wants, but that doesn't mean I shouldn't seek to find out some information for my own purposes just because you're going to read something negative into it.
15 Dec, 2012, donky wrote in the 20th comment:
Votes: 0
KaVir said:
donky said:
Are you saying that it can only ever be done in an annoying way?


KaVir said:
Disclaimer: Obviously much of this is down to personal opinion. But as I'm the one posting, I'm going to share my opinions of specific implementations of features that I have seen that I dislike, along with my opinion of why someone might add such a feature, and the solution I would use if I wanted to achieve that same goal. Responding with "feature X doesn't always work like that" is missing the point - because if it doesn't work like the implementation I've seen and described, the chances are it's not the implementation I'm criticising, and therefore the better response would be "another solution to feature X that I've seen is…"
I have no idea what your point is, Kavir. In future, rather than just cutting and pasting some text, can you please state it directly - a short sentence would suffice. This does not relate in any way I can understand to what my intentions were when I made mine. Even not responding, or saying "That direction of discussion is not interesting to me." is more helpful.

To be clear about what I am most interested in, ignoring any general thoughts that I may have included in my original post.. I have no interest in claiming realistic equipment can ever not be annoying. I have no interest in coming up with solutions. What I would like to know, what would help me better understand how to make a MUD avoiding these bad decisions, is to get insight into the experiences you base your problems above on. Every one of your decisions has vague claimed problems. Your statement which I was originally curious about, that realistic equipment will always be annoying, was also a vague allusion. I do not believe that your claims are false. I do not care to take this thread into a direction where I challenge you on any elaboration you make.

Your reply asks for existing solutions to be mentioned. But you haven't provided this level of detail for the problems. If you don't wish to help me, and likely other less experienced game designers, get a better understanding of why these were problems, then that's your prerogative. In no way do I demand this, or cast aspersions if you choose not to. But I know from the times we have engaged in the past that you are an experienced developer whose opinions I give credence, and based on that I hope you'll understand that you elaborating on your experience is something I can learn from. You just alluding to it with no detail whatsoever is not. And that's fine too, your time is your own, not something to be spent writing because I ask it on the internet.

This post includes a lot of qualifications about my intentions, because unfortunately this sort of thing seems necessary to avoid misinterpretations and drama.
0.0/74