21 Dec, 2012, Rarva.Riendf wrote in the 61st comment:
Votes: 0
Quote
Players attitudes are normally reflected by the staff. If you don't put forth the effort in advocating constructive feedback, then you will always get the same bad feedback like the quoted comments above.


You must be new.
21 Dec, 2012, Runter wrote in the 62nd comment:
Votes: 0
Listen more to where players spend their time than what people complain about. Most players just aren't capable of even determining what the problem that causes their poor experiences is. They don't understand the implications of changes like you should as someone who spends massive amounts of time designing and testing. So please yourself first. Don't design by committee. Take feedback as a way to put context on your own experiences as a user. You'll get a satisfactory resolution to your problems this way.
21 Dec, 2012, Famine wrote in the 63rd comment:
Votes: 0
plamzi said:
Famine said:
Players attitudes are normally reflected by the staff. If you don't put forth the effort in advocating constructive feedback, then you will always get the same bad feedback like the quoted comments above.


Ah, the joys of being a MUD dev! Not only do you work your ass off for nothing, but also if the vast majority of your players are selfish idiots–know that it's your fault! :)

Famine, I'm curious to see the player base you have cultivated, where everyone discusses game ideas at the level of PBS and NYTimes commentators, never veering from the vision they all share about how to make their favorite game better. Got links?


Not everyone will follow the same path of course, but the idea is to steer the influential people towards that path of constructive input on your game. My experience in those areas have been for several MUD's over the years, but mostly on MMOG's that I've worked on for the past 7 years like Age of Conan and the most recent The Secret World.

I think using online forums like for the example, World of Warcraft, is a bit silly. Like I said, not everyone will follow the same outline, especially for large-scale games. MUD's on the other hand, they have an insane advantage over most large-scale games. That's because they are smaller and even in some cases, have a family oriented feel to them because of how close the community is to one another. In those MUD examples, you can gain a lot more ground in cultivating your community and steering them down a path you want that can benefit the feedback process better than most.

That's just my opinion though. I'm just a firm believer of building everything from the end user rather than just looking at myself.

Runter said:
Listen more to where players spend their time than what people complain about. Most players just aren't capable of even determining what the problem that causes their poor experiences is. They don't understand the implications of changes like you should as someone who spends massive amounts of time designing and testing. So please yourself first. Don't design by committee. Take feedback as a way to put context on your own experiences as a user. You'll get a satisfactory resolution to your problems this way.


If you're not listening to what players hate about your game, then you're doing it all wrong. Complaining about something has nothing to do with determining the problem or having to understand the implications of change. Again, that's on you as the developer to consume and digest the complaint to make the high-level decision on whether or not it is a problem and what the implications of that change actually means. Once that happens, the best developers actually return that decision back to the end user to A) let them know you are listening and B) give them some return feedback on the complaint in terms of you or your teams action (i.e.: transparency).

Cheers!
21 Dec, 2012, Rarva.Riendf wrote in the 64th comment:
Votes: 0
Quote
I'm just a firm believer of building everything from the end user


Well nothing stops you…but you won't convincing me most are as dumb as their socks and that their opinion worth as much as anyone turds, and that the rest already agree you since they stay in your game.
21 Dec, 2012, Famine wrote in the 65th comment:
Votes: 0
Rarva.Riendf said:
Quote
I'm just a firm believer of building everything from the end user


Well nothing stops you…but you won't convincing me most are as dumb as their socks and that their opinion worth as much as anyone turds, and that the rest already agree you since they stay in your game.


Do you run a MUD with that attitude? If so, which?
22 Dec, 2012, Rarva.Riendf wrote in the 66th comment:
Votes: 0
I run Arcane nites, an old mud that died a long time ago for political reason among the staff (I was just a player then) and a lack of a good coder in it anyway, but still the players that are left like my changes (except the one that relied on loopholes or bugs I fixed). I dont advertise for it since I am the only coder (and active imm as a matter of fact) so I could not maintain a healthy community anyway. And it is heavily biaised towards pk as well. PVM content is not my priority.

I implemented a ton of ideas from players but only the one I thought would not disrupt anything else. And I explain why I will not implements some stuff as well. (ie:everytime they want an uber killing skill as a goddam cleric…or cry that their ninja dont have as many attacks as a warrior, or etc etc etc).

Now what is your mud…since you asked mine.
22 Dec, 2012, Famine wrote in the 67th comment:
Votes: 0
Rarva.Riendf said:
Now what is your mud…since you asked mine.


I'm working on my new project that's a RP/PvP MUD entitled, "Shadowmore". Previously worked on the resurrection of Devil's Silence, a long-standing PvP ROT MUD since the 90's. Haven't had much time recently to work on more MUD projects because I've been working on bringing a few MMOG's to market worldwide.
29 Dec, 2012, Kastion wrote in the 68th comment:
Votes: 0
I think one of the biggest drawbacks to the common remorting system is the reuse of content. If your MUD has a quest system of sorts in place that isn't auto-generated Kill X or Deliver X to Y and actually has unique quests with at least a touch of story then this is the perfect time to put something like that to use. If you can have a series of class-specific quest lines that will open up and give the player fresh content, or even some new areas or minor gameplay mechanics that will open up to remorted players then this can alleviate some of the issues I have with remorting. Regardless of access those things it still feels like a cop-out if you have to get to max level with a class just to remort into something else and retain nothing from all your previous hard work.

I've seen multi-class systems that work well where the additional classes that you can take on are limited in what they give you compared to your base class but still allow you to either be versatile or specialized. The ones I have seen work well in my opinion usually have a slew of classes available to everyone as well as a handful that are specific to the base class. I think a tiered system like Kline described is a good way to go about it.

I agree with Kline on the Diku-based WAIT_STATE comment - it is something I used in the past as I started out with Diku codebases and always disliked it. Using an event system for something like magic for example (start casting a spell, wait a few seconds, do more casting stuff like incantations or gestures, wait a few seconds, apply the affect of the spell) is great but if you're using WAIT_STATEs instead of just preventing other spells or abilities from being used then this becomes frustrating. Allow interrupting an action if you want but don't make any input cancel the action and don't use "artificial lag" as Kline put it to prevent input after an action.

I'm a fan of the classless/leveless systems but with a large number of options it can become overwhelming. If unlimited advancement is thrown into the mix with this it becomes difficult for players to find concrete goals to strive for. The way I see it you have to make it very easy for players to set goals they will want to achieve. If they have to think hard to set goals, they feel overwhelmed by choices, or they feel there ARE no goals they can set because advancement is limitless and there is nothing to do but get stronger and stronger and grind then it will become increasingly difficult to keep players interested.

I've always been very particular about manual combat systems… If you can make an intuitive command scheme and utilize an event system to delay and notify a player of an action long before the action actually occurs then it will keep them involved and engaged. The problem arises, as KaVir stated, when you over complicate it and/or have the flow of combat move too fast for a player to react. They will start to rely on scripts and triggers and it will be no different than automated combat. If the system is dynamic enough and the gameplay mechanics are well thought out then a manual combat system can become a unique experience and become one of the biggest draws to your game for some players.

I agree with what elanthis said about commands and as I mentioned your command scheme is important. I think being able to write out your commands in plain english - in the same way you would think of doing the action in your head - is key in doing this, but I also think it is important to accommodate users familiar with the medium and stick to existing conventions. The best way would be to go both routes and have more than one syntax for your commands.

The whole introduction system for remembering people by names you assign I have found to only be useful in heavily RP-enforced MUDs where RP is the most important element. If you're not an RP MUD it feels cumbersome and out of place…

About the hunger and thirst affects that quixadhal mentioned, again only in a heavily RP-enforced MUD have I seen this work. For example in Armageddon MUD where the harshness of the world is suppose to come into play and there is perma-death it suits the theme and works well.

Kjwah said:
Why realism for some stuff and not for other stuff? Because, while realism can add fun(depending on the type of game you're making, not all games are the same) some things people just don't want to live out.

Depending on the type of game you're making - certain gameplay mechanics work well given the proper context.

quixadhal said:
Here's an idea. Suppose you require sleep, and it really does take X hours of gametime. You *could* do that and implement dreaming as a way to give the player something to DO for that time. In a dream, players could still gain XP, but no loot items, and wounds would be healed as soon as they woke. Of course, if you die in a dream, you die in real life too. But, the players would always have the option to type "wake" and try to wake themselves up… the downside being they then can't get back to sleep for the rest of the night.

That's an amazing idea take something menial and boring and turn it into great gameplay, props man.
29 Dec, 2012, plamzi wrote in the 69th comment:
Votes: 0
Just today I remembered a good example of a change that we implemented for better reasons than realism, that also happened to be realistic. We already had long-term NPC followers whose gear was auto-saved along with players'. And we had just imped NPC races for other reasons. So I thought that we could add different wear slot configs, e. g. arachnids could not wear rings but could wear 4 pairs of leg armor. The goal was to lengthen the hunt for the perfect follower set, and in general to increase the number of possible sets.

Quix's example with sleep and KaVir's toilet anecdote illustrate that you can stack even the most unfun bit of realism in a way that will make it less boring. That doesn't mean that you should. For any feature A I consider, I ask myself if it will make the game more fun for more players than feature B. It is not often that the more realistic feature wins…
30 Dec, 2012, Kjwah wrote in the 70th comment:
Votes: 0
Kastion said:
Kjwah said:
Why realism for some stuff and not for other stuff? Because, while realism can add fun(depending on the type of game you're making, not all games are the same) some things people just don't want to live out.

Depending on the type of game you're making - certain gameplay mechanics work well given the proper context.


Well, of course it depends on the type of game you're making. That's why it's in what you quoted.
30 Dec, 2012, Tijer wrote in the 71st comment:
Votes: 0
the problem with players is they whine bitch and complain when things aren't being changed… and the second you work on changing stuff in your mud, they whine bitch and complain because you are doing changes…

Since starting running my own muds in 1997, i have gone through all of the stages, and at the end of the day it comes down to that players are guests, you ALLOW them to connect to the MUD, and you can simply stop allowing them to connect to your
mud whenever you so wish.
30 Dec, 2012, plamzi wrote in the 72nd comment:
Votes: 0
Tijer said:
the problem with players is they whine bitch and complain when things aren't being changed… and the second you work on changing stuff in your mud, they whine bitch and complain because you are doing changes…

Since starting running my own muds in 1997, i have gone through all of the stages, and at the end of the day it comes down to that players are guests, you ALLOW them to connect to the MUD, and you can simply stop allowing them to connect to your
mud whenever you so wish.


There are many things that players of free games will never understand, and the guest situation is one of them. It's probably true for any free online game, but I feel that due to diminishing numbers many mudders have grown especially fond of assuming that they are a great boon to any MUD they honor with their presence. I often find myself engaged in precarious balancing acts with old-timers who demand special treatment because they've played for this many years, and they'll leave unless <<fill in the blank>>. I don't negotiate with 'terrorists' but these kinds of situations have a huge demoralizing effect on me, as much as I try to put it past me.

What KaVir mentioned earlier, that it's very important in an enthusiast project for the dev him/herself to have fun, is another thing players just don't understand. If they did, they would know that whining is extremely dangerous. If you work hard for nothing, and you don't even get a pat on the back for it, then you'd be tempted to just shut down the game and pick up another hobby, as I'm sure it has happened to numerous servers.

Yet another thing players (even the good eggs) don't get is that there is no general shortage of ideas in the world. The shortages are in dedication, time, skill, etc., not ideas. A big part of the reason why we code our own game is so we can implement our ideas, not theirs :) And frankly, most players are simply not qualified to contribute ideas about game mechanics, since their view is so limited, not to mention biased. They are, by contrast, extremely qualified to speak about usability issues, so I often find myself implementing UX feedback as soon as I get it.
31 Dec, 2012, Kastion wrote in the 73rd comment:
Votes: 0
Kjwah said:
Well, of course it depends on the type of game you're making. That's why it's in what you quoted.

I think you misunderstood, I wasn't arguing against what you said - I was agreeing with you which is why I quoted and repeated what you said verbatim…
plamzi said:
Yet another thing players (even the good eggs) don't get is that there is no general shortage of ideas in the world. The shortages are in dedication, time, skill, etc., not ideas. A big part of the reason why we code our own game is so we can implement our ideas, not theirs :) And frankly, most players are simply not qualified to contribute ideas about game mechanics, since their view is so limited, not to mention biased. They are, by contrast, extremely qualified to speak about usability issues, so I often find myself implementing UX feedback as soon as I get it.

While a lot of times you are presented with unfeasible or even game-breaking suggestions when it comes to modifying existing features - in regards to functionality and not the numbers/calculations I tend to listen to the player then run it by a few other players and staff members to see if they agree. I rarely listen to game mechanic suggestions as like you said when you only see part of the picture you don't understand why things are the way they are. I don't flat out ignore my players and I will look over the numbers and calculations from time to time to confirm whether or not their worries warrant some action but the majority of the time it's not warranted.

As far as usability I agree with you completely plamzi, modifying or adding new syntax and simplifying commands - these are the kind of suggestions that I more often than not will go through with.
31 Dec, 2012, Kjwah wrote in the 74th comment:
Votes: 0
Kastion said:
Kjwah said:
Well, of course it depends on the type of game you're making. That's why it's in what you quoted.

I think you misunderstood, I wasn't arguing against what you said - I was agreeing with you which is why I quoted and repeated what you said verbatim…


I did misunderstand you, good sir!


On an off topic note, your name seems really familiar.
Kastion said:
plamzi said:
They are, by contrast, extremely qualified to speak about usability issues, so I often find myself implementing UX feedback as soon as I get it.


As far as usability I agree with you completely plamzi, modifying or adding new syntax and simplifying commands - these are the kind of suggestions that I more often than not will go through with.


This a million times over. I don't know how many games I've been on where simple suggestions such as these are rejected for reason like, "I don't feel like it" or "it's not important".
60.0/74