23 Feb, 2008, drrck wrote in the 1st comment:
Votes: 0
In your opinion, where is the line drawn between "real" and "too real" when it comes to MUD features?

I see all kinds of discussions across multiple forums about seemingly cool features like weather, temperature, jobs, perm-death, and the like, but they all beg the same question: how far is too far? Should players be required to do tedious, menial things, simply because it makes a certain system more true-to-life? Should the entire focus of a game be on fun with no regard to reality whatsoever? Is there a happy medium somewhere between these two extremes, and if so, to what degree?

To hit on a few of the most popular examples, here are my takes…

Weather - I think this is a toss-up depending on implementation. I've seen weather implementations that were little more than cyclic rain/thunderstorms every X game days in random places. On the other hand, I've seen weather implementations that went so far as to have low and high pressure areas that moved dynamically across the game, causing thunderstorms, tornadoes, hurricanes, firestorms, etc. Personally, I don't know that having such an accurate representation of weather adds anything to the game outside of immersion, perhaps, but from my experiences, it's usually just ignored by a vast majority of players.

Jobs - I have yet to see someone present the concept of in-game jobs in a desirable way. I think the entire reason for playing a game (that is what your MUD is, right?) is to escape reality - not clone it. That said, there are many aspects of a game that can be modeled after real-life without losing that feeling of detachment. Jobs just happen not to be one of them, in my opinion. There are other, more creative (read: fun) ways of building an economy and making money, like betting on jousting tournaments or stealing coins from people in a crowd.

Menial tasks - By this, I'm referring to eating, drinking, sleeping, and other such activities. Sometimes they can be OK, with valid in-game benefits (such as restoring HP while sleeping, or gaining a spell effect from drinking a magical potion), but excluding this, I think requiring players to do such things just for RP purposes is absurd. Sure, it may be 4am game time and every sane creature should theoretically be asleep, but why force it? It's just not fun to have your regeneration slowed because you're "tired", or have your health steadily decline because you haven't eaten in a while. Just because you can doesn't mean you should, even if it "makes sense".



What do you think?
23 Feb, 2008, David Haley wrote in the 2nd comment:
Votes: 0
For starters regarding simulation, I'm a firm believer in the idea that if the player won't notice it, there's no point simulating it. So you don't need to simulate every "real" detail of a system if you can make it look like you are as far as the player is concerned.

That said, I think you're establishing a slightly inappropriate dichotomy between "fun" and "realistic". In your initial question you present them as being on opposite ends of a single spectrum, which is not necessarily the case. For example, different people like different things so it doesn't necessarily make sense to ask this question in general. Some people find it fun to micromanage every last detail; some people don't want to have to deal with anything but exactly what they want to do. Additionally, something can be quite fun yet quite realistic, or quite boring despite being unrealistic.

Eating/drinking is an interesting example, actually. It can be a useful gameplay mechanic to require adventurers to be prepared to some extent before wandering off into the wilderness. But does that mean you need to force people to get the food from their pack and eat it? Would it not suffice to have the character automatically eat if food is present?

Weather is another interesting example. There is, to some extent, a "why do I care?" question that is very relevant. Some people like seeing credible weather. Others couldn't care less. You won't hurt anything (other than your own development time) by adding weather in this case. But if weather actually means something, for instance if weather affects gameplay in a non-trivial manner, then players will have good reason to care. (E.g. should we attack the enemy in the snow, rain or sun … etc.)

Jobs are interesting, too, and I think it again has to do with what different people like. There are people who like building up crafting empires and making money with a "job" selling things to other people. You clearly aren't one of them, but that doesn't mean nobody likes it. Think of city-builders, I suppose: the whole point of those games is to build up little worlds based on various forms of trading and clockwork that seem to fall into your category of uncreative and boring and yet the games sell quite well.

In the end of the day, if something is irrelevant to the game, it probably shouldn't be there. If the only purpose for something is to create tasks that give no reward and serve no purpose, you probably don't want that thing in your game. That doesn't mean that all realism should go – it means that realism should be preserved if it serves a point, and pointless realism should be discarded.
23 Feb, 2008, KaVir wrote in the 3rd comment:
Votes: 0
DavidHaley said:
In the end of the day, if something is irrelevant to the game, it probably shouldn't be there.


While I agree with that sentiment to a certain extent, I think it's important to consider what exactly is meant by "irrelevant".

Weather with no in-game affect, dynamic descriptions, fancy combat messages, etc - these are all examples of cosmetic fluff which is irrelevant to the actual gameplay. Yet they can make or break a mud just as much as the mechanics.

Optimisations and rewrites of the underlying code are something else that might be considered irrelevant from the perspective of the player - indeed, they're unlikely to even notice. But such changes can improve the performance of the mud (thus lowering your hosting costs) and make it easier to extend the code in the future (increasing your development speed).

Even in the case of features which the player can't see, and which don't improve the overall performance of the mud, there's still a reason to justify adding it: Because you, personally, want to do so. If the mud is a hobby, and you're writing it for your personal satisfaction, then you should implement the things you want to have. If you really enjoy designing "cool" low-level solutions, then do so (although you might want to consider releasing your mud as a codebase rather than running it as a game).

So while I agree that features should be carefully considered before being added, I don't think it's necessarily that easy to pigeon-hole them into "relevant" and "irrelevant"; the relevance depends on both the requirements of the individual game and on the goals of the individual developer.
23 Feb, 2008, Kayle wrote in the 4th comment:
Votes: 0
Oddly enough, we just had this discussion not too long ago on MW. And the whole thing was sparked by my decision to include a system that required players to only be able to log out at an inn to preserve the safety of their equipment. (Samson's Rent snippet, for those curious.) They still have the option of logging out anywhere, but when they do, they run the chance of having some, or all, of their more important gear being stolen by theives or bandits, or if they don't have the money to pay for the rent charges they lose it.

Some of the staff was arguing that it would only serve to push people away. And make them not want to continue playing if they lost their gear. Others would argue that it wasn't common practice and shouldn't be done. Obviously, this second argument was garbage and I tossed it out, nothing on MW is really common practice anyway, But the first argument I had to consider, because my point is not to drive players away, but make them think about the consequences of running around in high end gear with no regard for it's safety.

In the end we chose to implement it, for both the realism factors, and because it would be one more thing that set us apart from other Smaug muds.

So while I agree with David, I also agree with KaVir, because in the instance of optimization, it might not mean much to the players, but it's going to lower resource usage, and on some hosting services thats a good thing. I think it's important to look at pros and cons of any significant change. Weigh the two and see which one makes a bigger difference. If the Pros far outweigh the cons. Go for it. If the cons outweigh the pros, It might not be such a great idea.

Another thing to take into consideration is your players. When you think to add new things take a look at your players, and see what they enjoy spending their time doing. Do they sit around and talk a lot? Sit around and roleplay? Are they out exploring every inch of every area making maps and notes of where key information is? Are they out running in groups killing every mob in sight? These are the things you need to look at on your mud. If you have a lot of people just sitting around doing nothing, maybe it's time to ask them what they'd like to see come, what would make them get out and enjoy the game. If you'd like to steer things away from the hack'n'slash and give them other things to do, you might look at what the ones that are always killing things are doing, find out from them what they would like to see on the side of killing things, what would make them do things other than run tough mobs all the time. The explorer is the easiest to satisfy, just keep adding new areas, maybe give them a command that would allow them to do their mapping inside the game, and they draw it on a piece of paper or a map in their inventory.

When you think of what is too far, you need to not only look at your personal preference, but at the preferences of your players as well. It is, after all, them you're trying to please.
23 Feb, 2008, drrck wrote in the 5th comment:
Votes: 0
DavidHaley said:
For starters regarding simulation, I'm a firm believer in the idea that if the player won't notice it, there's no point simulating it. So you don't need to simulate every "real" detail of a system if you can make it look like you are as far as the player is concerned.

That said, I think you're establishing a slightly inappropriate dichotomy between "fun" and "realistic". In your initial question you present them as being on opposite ends of a single spectrum, which is not necessarily the case. For example, different people like different things so it doesn't necessarily make sense to ask this question in general. Some people find it fun to micromanage every last detail; some people don't want to have to deal with anything but exactly what they want to do. Additionally, something can be quite fun yet quite realistic, or quite boring despite being unrealistic.



Interesting points. I think I probably should have clarified that I was trying to establish the range between "fun" and "realistic, but not fun". I agree that things can be both fun and realistic (and some of these are even fun because they're realistic). Of course, as you pointed out, the definition of "realistic, but not fun" will also vary from player to player.

DavidHaley said:
Eating/drinking is an interesting example, actually. It can be a useful gameplay mechanic to require adventurers to be prepared to some extent before wandering off into the wilderness. But does that mean you need to force people to get the food from their pack and eat it? Would it not suffice to have the character automatically eat if food is present?


Exactly. Most MUDs that I've seen require that you do such tasks manually, but I haven't yet figured out what the justification for this is. Usually, you don't gain anything from them; the sole reason for doing them is to prevent the bad things that happen when you don't. I, personally, think that's a good sign of a broken system.

DavidHaley said:
Weather is another interesting example. There is, to some extent, a "why do I care?" question that is very relevant. Some people like seeing credible weather. Others couldn't care less. You won't hurt anything (other than your own development time) by adding weather in this case. But if weather actually means something, for instance if weather affects gameplay in a non-trivial manner, then players will have good reason to care. (E.g. should we attack the enemy in the snow, rain or sun … etc.)


This is also a good point, but I think the bigger question is: does the fact that there is a reason to care necessarily mean it's a good feature to have? For example, if you're likely to get frostbitten when attacking enemies in the snow, that's obviously a reason to care, but there doesn't seem to be any benefit from attacking in fair weather, outside of the fact that you won't get frostbitten. This seems like the same conundrum as the eat/drink situation.

DavidHaley said:
Jobs are interesting, too, and I think it again has to do with what different people like. There are people who like building up crafting empires and making money with a "job" selling things to other people. You clearly aren't one of them, but that doesn't mean nobody likes it. Think of city-builders, I suppose: the whole point of those games is to build up little worlds based on various forms of trading and clockwork that seem to fall into your category of uncreative and boring and yet the games sell quite well.


Well, I was more referring to the requirement of jobs, rather than the option. I agree that different people find different things fun in this regard, but should those who don't be forced into it, simply because it's more realistic? I think not, but several games that I've played seem to disagree.


KaVir said:
Even in the case of features which the player can't see, and which don't improve the overall performance of the mud, there's still a reason to justify adding it: Because you, personally, want to do so. If the mud is a hobby, and you're writing it for your personal satisfaction, then you should implement the things you want to have. If you really enjoy designing "cool" low-level solutions, then do so (although you might want to consider releasing your mud as a codebase rather than running it as a game).


I would generally agree, as long as these solutions have no effect on players; however, what if one of your cool ideas for a low-level solution involves bringing about a feature that most players would find tedious and annoying? Does your desire to create the feature outweigh the desires of your playerbase (strictly speaking as a game administrator - not just a codebase designer)? A lot of administrators design/code their MUDs as a hobby and out of personal satisfaction, but they also want to maintain a functional game that people actually play as well, so there has to be some balance between implementing what you want vs. what they want (in the cases where the two don't coincide). I guess I'm just trying to find out to what degree this balance is struck from those who have actually administered MUDs (I've only coded thus far).

Kayle said:
I think it's important to look at pros and cons of any significant change. Weigh the two and see which one makes a bigger difference. If the Pros far outweigh the cons. Go for it. If the cons outweigh the pros, It might not be such a great idea.


This may be a good rule of thumb, but what if the con equates to players leaving your game? What if by adding a feature, you'll drive away 10 veteran players, but gain 30 new ones as a result? I don't think it's always necessarily as cut and dry as weighing pros and cons, and takes a lot more consideration into what you want your game to be and who you want playing it, as a result.
23 Feb, 2008, David Haley wrote in the 6th comment:
Votes: 0
KaVir said:
Weather with no in-game affect, dynamic descriptions, fancy combat messages, etc - these are all examples of cosmetic fluff which is irrelevant to the actual gameplay. Yet they can make or break a mud just as much as the mechanics. (…)

Yes, what I meant by irrelevant is something that players won't notice. Cosmetic improvements aren't irrelevant (assuming they get noticed). As for code optimization, I view that as a different category entirely, separate from gameplay features. And sure, if it's something the coder really wants, then fine, it's just important to realize it's not for the game, it's for the coder (and as drrck points out, the coder should also realize that it might be harmful to the game to do things that are enjoyable – but then the coder just needs to figure out what is more important to him/her; either way is fine, it's just important to be aware of it).

(Actually, to get a little philosophical perhaps, code optimizations can be considered under the same category. For starters, players will notice speed improvements, or at least, will notice slow-downs that would happen without the improvements. Also, players will notice a faster feature development time. So really, from this point of view, those come under the same definition of "relevance". If you tweak the code and it neither changes performance nor reduces maintenance time, arguably you've kind of wasted your time.)

drrck said:
For example, if you're likely to get frostbitten when attacking enemies in the snow, that's obviously a reason to care, but there doesn't seem to be any benefit from attacking in fair weather, outside of the fact that you won't get frostbitten.

Well, it was just an example, perhaps a poor one. I was trying to get at the idea of adding additional strategy to the game. Some strategic elements might be simply annoying, though, I agree.

drrck said:
Well, I was more referring to the requirement of jobs, rather than the option.

Oh. Well, sure, then… requiring adventurers to have jobs seems a little silly! You're out slaying monsters, saving villages, and then you have to bake bread for the market?? :lol:
23 Feb, 2008, KaVir wrote in the 7th comment:
Votes: 0
Kayle said:
They still have the option of logging out anywhere, but when they do, they run the chance of having some, or all, of their more important gear being stolen by theives or bandits, or if they don't have the money to pay for the rent charges they lose it.


You mean players still have to pay rent, even if they're camping out in the middle of nowhere?

drrck said:
Usually, you don't gain anything from them; the sole reason for doing them is to prevent the bad things that happen when you don't. I, personally, think that's a good sign of a broken system.


Many features are designed to prevent bad things happening to you - armour, shields, defensive skills, protective spells, healing powers, etc. A mud where nothing bad can ever happen to you would be boring, and in my opinion a mud which didn't give you any way to prevent bad things happening to you would be broken.

drrck said:
This is also a good point, but I think the bigger question is: does the fact that there is a reason to care necessarily mean it's a good feature to have? For example, if you're likely to get frostbitten when attacking enemies in the snow, that's obviously a reason to care, but there doesn't seem to be any benefit from attacking in fair weather, outside of the fact that you won't get frostbitten. This seems like the same conundrum as the eat/drink situation.


It seems pretty reasonable to me - you attack in fair weather to avoid the risk of frostbite, much as you might attack during the day to avoid visibility penalties, or on a plain to avoid foliage penalties, or using a stiletto to avoid heavy armour, or with a large shield to protect against archers, etc.

drrck said:
Well, I was more referring to the requirement of jobs, rather than the option. I agree that different people find different things fun in this regard, but should those who don't be forced into it, simply because it's more realistic? I think not, but several games that I've played seem to disagree.


Whatever you implement, some people will hate it. Now personally I chose to make eating completely optional, but not every feature can easily be implemented that way. Trying to cater to the masses is almost guaranteed to result in a rubbish game that few enjoy, so sometimes you've just got to bite the bullet and make a decision.

drrck said:
I would generally agree, as long as these solutions have no effect on players; however, what if one of your cool ideas for a low-level solution involves bringing about a feature that most players would find tedious and annoying? Does your desire to create the feature outweigh the desires of your playerbase (strictly speaking as a game administrator - not just a codebase designer)?


That's up to each individual administrator to decide for themselves. It's also worth noting that even "tedious" features can have their uses; as much as many players will complain about them, and as counter-intuitive as it may at first seem, the fact is that such features often tend to result in a larger playerbase. Players are more likely to hang around after the honeymoon period if they feel they've heavily invested in a game, and blood, sweat and tears are perhaps even more effective than hard cash in that respect. You just have to make sure the game is enjoyable enough to offset the tedium.
23 Feb, 2008, Conner wrote in the 8th comment:
Votes: 0
To me it really all boils down to one thing, who you're making the game for.

Kayle said:
When you think of what is too far, you need to not only look at your personal preference, but at the preferences of your players as well. It is, after all, them you're trying to please.

In my case, I cater to players who favor what I do because I'm making my game according to what I like and what I want to be in there. Sometimes my players will make a suggestion for something that they'd like to see added that I hadn't considered or changed in a way I hadn't thought of and I'll happily add that to my to-do list, but ultimately I'm making the game for me. If I happen to find eating to be something enjoyable in a game, my game will have mandatory eating, if I find it's a "Menial task", I'll eventually remove it from my game or make it optional.

KaVir said:
drrck said:
Well, I was more referring to the requirement of jobs, rather than the option. I agree that different people find different things fun in this regard, but should those who don't be forced into it, simply because it's more realistic? I think not, but several games that I've played seem to disagree.


Whatever you implement, some people will hate it. Now personally I chose to make eating completely optional, but not every feature can easily be implemented that way. Trying to cater to the masses is almost guaranteed to result in a rubbish game that few enjoy, so sometimes you've just got to bite the bullet and make a decision.

drrck said:
I would generally agree, as long as these solutions have no effect on players; however, what if one of your cool ideas for a low-level solution involves bringing about a feature that most players would find tedious and annoying? Does your desire to create the feature outweigh the desires of your playerbase (strictly speaking as a game administrator - not just a codebase designer)?


That's up to each individual administrator to decide for themselves. It's also worth noting that even "tedious" features can have their uses; as much as many players will complain about them, and as counter-intuitive as it may at first seem, the fact is that such features often tend to result in a larger playerbase. Players are more likely to hang around after the honeymoon period if they feel they've heavily invested in a game, and blood, sweat and tears are perhaps even more effective than hard cash in that respect. You just have to make sure the game is enjoyable enough to offset the tedium.

I agree with KaVir, it's a matter of taste, and who's taste is determined by who you are making the game for.

KaVir said:
drrck said:
Usually, you don't gain anything from them; the sole reason for doing them is to prevent the bad things that happen when you don't. I, personally, think that's a good sign of a broken system.


Many features are designed to prevent bad things happening to you - armour, shields, defensive skills, protective spells, healing powers, etc. A mud where nothing bad can ever happen to you would be boring, and in my opinion a mud which didn't give you any way to prevent bad things happening to you would be broken.

Again, as KaVir points out, a game is not broken because it offers features to avoid bad things or even if it has bad things that can happen to you for failing to take appropriate counter-measures if that's the way the code was set to work, instead it's simply geared for a type of player who prefers that.

KaVir said:
drrck said:
This is also a good point, but I think the bigger question is: does the fact that there is a reason to care necessarily mean it's a good feature to have? For example, if you're likely to get frostbitten when attacking enemies in the snow, that's obviously a reason to care, but there doesn't seem to be any benefit from attacking in fair weather, outside of the fact that you won't get frostbitten. This seems like the same conundrum as the eat/drink situation.


It seems pretty reasonable to me - you attack in fair weather to avoid the risk of frostbite, much as you might attack during the day to avoid visibility penalties, or on a plain to avoid foliage penalties, or using a stiletto to avoid heavy armour, or with a large shield to protect against archers, etc.

I agree with KaVir on this point too. While Drrck's viewpoint is perfectly valid for his game, it would be totally off on my game as my game is intended for folks who share my perspective. If I were to implement these sorts of things (and I have considered it, especially the frostbite and heatstroke sort of concerns…) then I see no reason not to take it to the extent of also including factors, like KaVir mentioned, such as visibility (let's players have a use for fog spells and such, though I think foliage, to me, seems like part of visibility.. maybe a slight possible damage absorption factor as well…), shielding, armor weight/type issues, and so forth. They do more than just add realism to me, they also add combat considerations and challenge.

DavidHaley said:
KaVir said:
Weather with no in-game affect, dynamic descriptions, fancy combat messages, etc - these are all examples of cosmetic fluff which is irrelevant to the actual gameplay. Yet they can make or break a mud just as much as the mechanics. (…)

Yes, what I meant by irrelevant is something that players won't notice. Cosmetic improvements aren't irrelevant (assuming they get noticed). As for code optimization, I view that as a different category entirely, separate from gameplay features. And sure, if it's something the coder really wants, then fine, it's just important to realize it's not for the game, it's for the coder (and as drrck points out, the coder should also realize that it might be harmful to the game to do things that are enjoyable – but then the coder just needs to figure out what is more important to him/her; either way is fine, it's just important to be aware of it).

(Actually, to get a little philosophical perhaps, code optimizations can be considered under the same category. For starters, players will notice speed improvements, or at least, will notice slow-downs that would happen without the improvements. Also, players will notice a faster feature development time. So really, from this point of view, those come under the same definition of "relevance". If you tweak the code and it neither changes performance nor reduces maintenance time, arguably you've kind of wasted your time.)

Here again I have to ask who you're making the game for. If you're doing it all strictly for the players then you're right, unless those code changes impact the players somehow you're probably wasting your time, though some code changes do impact players even though they'll never notice it. For example, changes to ensure stability…
On the other hand, if you're making the game for your own benefit, to improve your programming skills, for example, then any change you make is a waste of time only if it is redundant to your learning, and then you could consider it "practice". Not all of us are professional programmers who run a mud as a part-time distraction, some of us actually only program for our muds…

DavidHaley said:
drrck said:
Well, I was more referring to the requirement of jobs, rather than the option.

Oh. Well, sure, then… requiring adventurers to have jobs seems a little silly! You're out slaying monsters, saving villages, and then you have to bake bread for the market?? :lol:

I do share this opinion, if the "jobs" aren't optional they're sort of breaking the game for me, but again it's a matter of taste. Having the job could be, in itself, the escapism factor for some folks if it's not the same job that they do in real life or maybe even if it is the same job provided some facet is different like having no manager above you telling you that you can't do things your way, for example…

(sorry for not taking these all in order of actual appearance, in fact, I haven't even responded to all the points among the previous posts that I was going to, but this was already getting longish and I kept debating which parts were more worth chiming up about to begin with…)
24 Feb, 2008, drrck wrote in the 9th comment:
Votes: 0
KaVir said:
Many features are designed to prevent bad things happening to you - armour, shields, defensive skills, protective spells, healing powers, etc. A mud where nothing bad can ever happen to you would be boring, and in my opinion a mud which didn't give you any way to prevent bad things happening to you would be broken.


Point taken, although I was more referring to bad things whose only purpose in the game is to penalize players for not doing menial tasks. In my opinion, protecting yourself from harm is not menial, since it's a rather huge part of what makes a MUD a MUD. If you removed damage and all the ways to protect yourself from it, your game would be fundamentally changed in a huge way (relative to removing eating/drinking, anyway).

@Conner:

Administrators adding/removing/changing features on their games based solely on their own tastes is actually what prompted me to start this thread. While it's definitely their right to do whatever they want to do, I've witnessed a pretty great game go down the drain (in terms of player support, respect, and participation) because of it.

I, personally, don't want my game to take the same route, but neither do I want other people dictating what I do with my own creation. While I want creative freedom, my ultimate goal with this project is still to create a game that lots of people like to play. It does me no good in the end to have a perfect game that nobody likes.

Have any of you compromised on things that you really wanted to add/remove/change in your game simply because your players disagreed? If so, to what extent?
24 Feb, 2008, Kayle wrote in the 10th comment:
Votes: 0
KaVir said:
You mean players still have to pay rent, even if they're camping out in the middle of nowhere?


No, if they camp out, they don't pay rent, but they run the risk of thieves or bandits roaming by and looting some of their things while they're sleeping. They need to worry about paying rent if they go linkdead, or use the autoquit stuff which gives them a 33% chance to lose all rent qualifying items if they can't pay.
24 Feb, 2008, Darwin wrote in the 11th comment:
Votes: 0
drrck said:
Administrators adding/removing/changing features on their games based solely on their own tastes is actually what prompted me to start this thread. While it's definitely their right to do whatever they want to do, I've witnessed a pretty great game go down the drain (in terms of player support, respect, and participation) because of it.
I too have seen this happen. It's still a great game, just not as great as it used to be. There have been many features implemented that are aimed at adding more restrictions against the players. This, to me, seems counter-productive to increasing the number of players that will enjoy the game.
24 Feb, 2008, KaVir wrote in the 12th comment:
Votes: 0
drrck said:
Point taken, although I was more referring to bad things whose only purpose in the game is to penalize players for not doing menial tasks. In my opinion, protecting yourself from harm is not menial, since it's a rather huge part of what makes a MUD a MUD. If you removed damage and all the ways to protect yourself from it, your game would be fundamentally changed in a huge way (relative to removing eating/drinking, anyway).


That's true for the majority of muds, although technically there's nothing stopping someone from creating a mud without combat, or even one which where the main focus of gameplay is the creation and consumption of food.

It's really only a matter of scale - combat usually has a large impact on the game, while food usually has a small impact. But in my opinion, from a game design perspective, if a feature which causes "bad things" is worth having then so are the appropriate countermeasures.

Of course the difference between "good things" and "bad things" can also be very much a matter of perspective. Does eating food give you a period of time where you can heal 2hp per second instead of the normal 1, or does being hungry half your normal 2hp per second healing rate?

A while ago I added a system whereby players earned a certain number of "boost points" per day, which could be spent to earn 2.5 times the normal amount of exp for a limited number of kills. This was originally added to reduce botting, by giving a bonus for casual play - and the players at the time viewed it as a "good thing". But later players took the boosts for granted, treating boosted kills as the standard exp rate and considering unboosted kills to be a "bad thing".

drrck said:
Have any of you compromised on things that you really wanted to add/remove/change in your game simply because your players disagreed?


No. I'm open to suggestions, and invite players to make convincing arguments for features they'd like to have - in fact many of my features were shaped by player input - but there have been a few cases where people have requested things that compromised my vision of the mud. In such cases I've told the players "no" (although I do explain why I won't add said features).
24 Feb, 2008, drrck wrote in the 13th comment:
Votes: 0
KaVir said:
Of course the difference between "good things" and "bad things" can also be very much a matter of perspective. Does eating food give you a period of time where you can heal 2hp per second instead of the normal 1, or does being hungry half your normal 2hp per second healing rate?

A while ago I added a system whereby players earned a certain number of "boost points" per day, which could be spent to earn 2.5 times the normal amount of exp for a limited number of kills. This was originally added to reduce botting, by giving a bonus for casual play - and the players at the time viewed it as a "good thing". But later players took the boosts for granted, treating boosted kills as the standard exp rate and considering unboosted kills to be a "bad thing".


Haha, I suppose you're right. I never really looked at it like that. I guess the consensus on which is the case would depend heavily on when a player is introduced to the system. It would probably be better for everyone if features like this were all added very early on in the development of the game, so that players don't have time to get used to the "old way".
24 Feb, 2008, David Haley wrote in the 14th comment:
Votes: 0
KaVir said:
Of course the difference between "good things" and "bad things" can also be very much a matter of perspective. Does eating food give you a period of time where you can heal 2hp per second instead of the normal 1, or does being hungry half your normal 2hp per second healing rate?

This is a good way around the food problem IMO. It's not forced, and you can play reasonably by ignoring food, but it's a bonus if you do eat food.

Morrowind/Oblivion used food as healing (health and/or fatigue, usually the latter) devices, except that the healing was so small that really you were better off using potions. Instead, food was better used as ingredients for potions…
drrck said:
It would probably be better for everyone if features like this were all added very early on in the development of the game, so that players don't have time to get used to the "old way".

Richard Bartle makes the point that if you're going to introduce a feature that fairly heavily impacts gameplay, you really want to do it before you go public with a game. It is much easier (in terms of player acceptance) to change the parameters of a system later on, rather than to all of a sudden introduce it. An example is an upkeep cost on items.

Conner said:
On the other hand, if you're making the game for your own benefit, to improve your programming skills, for example, then any change you make is a waste of time only if it is redundant to your learning

Again not to get philosophical but I think that falls under the same understanding of irrelevance. If something is not contributing to your goals, you shouldn't be doing it. Of course, your goals can vary. It's just important to know what the goals are. If the primary goal is to learn and explore coding techniques, and decisions are made subservient to that, one should not be surprised if the MUD doesn't have players. If the primary goal is to learn, that's ok. But if, after all, having players is nice, then a mistake was made along the way.
24 Feb, 2008, KaVir wrote in the 15th comment:
Votes: 0
DavidHaley said:
KaVir said:
Of course the difference between "good things" and "bad things" can also be very much a matter of perspective. Does eating food give you a period of time where you can heal 2hp per second instead of the normal 1, or does being hungry half your normal 2hp per second healing rate?

This is a good way around the food problem IMO. It's not forced, and you can play reasonably by ignoring food, but it's a bonus if you do eat food.


The point I was trying to make is that both approaches are mechanically exactly the same - you heal at 2hp per second if you eat, and 1hp per second if you don't. It's only the perception that changes - whether eating is a "good thing", or being hungry is a "bad thing".
25 Feb, 2008, Fizban wrote in the 16th comment:
Votes: 0
I'm probably a masochist, but if simulating something in anyway increases the enjoyment of the mud (for the players) then I feel that it is worth doing.
25 Feb, 2008, David Haley wrote in the 17th comment:
Votes: 0
That's not being disputed though. The suggestion was that if simulation doesn't change anything, then it's not worth it (modulo learning concerns etc.)
25 Feb, 2008, drrck wrote in the 18th comment:
Votes: 0
How about permanent death? Too real or can it be feasibly done without alienating players?
25 Feb, 2008, David Haley wrote in the 19th comment:
Votes: 0
I think it depends on what purpose you're trying to accomplish. Is it just for the sake of being realistic? Then no, I don't think it's a good idea. PermDeath can serve useful purposes, but I don't think it should be adopted merely for the sake of realism.
25 Feb, 2008, drrck wrote in the 20th comment:
Votes: 0
DavidHaley said:
I think it depends on what purpose you're trying to accomplish. Is it just for the sake of being realistic? Then no, I don't think it's a good idea. PermDeath can serve useful purposes, but I don't think it should be adopted merely for the sake of realism.


My purpose for adding it would be to have more of a consequence for death. As-is, I think a lot of games promote dying as just another facet of playing, going so far as to even have a lot of content only available to those who are in the "after life" or whatever. While I don't want to make the game too hard, so to speak, I definitely don't want players throwing caution to the wind and being careless with their characters either.
Random Picks
0.0/174