15 Dec, 2012, quixadhal wrote in the 21st comment:
Votes: 0
Here's one from WileyMUD!

Realistic hunger and thirst effects:

In Theory, your character should need to eat and drink to stay alive, so having bad things happen if you fail to do that make the game more immersive.

In Practice, having to buy or obtain food and drink is a money or time sink, and having to remember to type "eat bread" or "drink water" every so often is an annoyance usually solved by client-side triggers.

While it is a funny thing to have your character be starving or dying of dehydration, and somehow manage to crawl back to town to buy food or water and survive, it's equally annoying to be killed by a random low-level critter that stumbles upon you and slowly chews your leg off while you're too weak to fight back.

The current trend in graphical MMO's is to relegate food and drink to the category of added self-buffs. The idea being if you remember to buy and eat carrots, you can gain improved stealth detection. To add to the playability, they often implement a crafting system of cooking recipes, so perhaps you can combine spinach with olives, pasta, and cheese to great a greek salad which improves your strength, wisdom, and dodge ability for a set amount of time.
15 Dec, 2012, donky wrote in the 22nd comment:
Votes: 0
Rarva.Riendf said:
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.
I think your final point is well put, and a good one. But I do not understand what you mean by the second sentence. Let me describe what we did on my MUD, which never opened, and perhaps you could relate it to that.

We implemented many realistic systems. Body parts and positioning. Containers with realistic item locations. Rooms with positioning, where you had to cross the room to use the exit at the other side. Construction of objects out of parts, and the ability to take them apart. Whether you were piecing together layers of clothing with wear commands, or making a sword by doing all the steps, this was supported. But we never conceived that the player would deal with manually doing all the commands to interact with all the realistic elements we had implemented. We thought it was obvious that this was simply a silly way to do it, and that abstracting it away to make it as easy, or easier, than the standard systems was the way to go. If we couldn't come up with usable abstractions, then we wouldn't have bothered with realistic equipment.
16 Dec, 2012, KaVir wrote in the 23rd comment:
Votes: 0
donky said:
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.

My intention for this thread was to describe "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". I realised that some people might take offence at my comments, so I added a large disclaimer to stress that I was referring to my personal opinion of specific implementations, and not all implementations.

So when you asked "Are you saying that it can only ever be done in an annoying way?" and "Is it possible this is done from your perspective", it seemed apparent that you hadn't read my disclaimer.

Yes, it is possible to create better implementations - that's why every feature I've listed includes a "proposed solution" for a better implementation. And yes, they're all written from my perspective, as I stated very explicitly in the first post.

These are just my personal opinions based on specific implementations I've seen, nothing more. There is no need to get defensive, particularly if your own implemention differs from those I've described.
16 Dec, 2012, Rarva.Riendf wrote in the 24th comment:
Votes: 0
donky said:
We implemented many realistic systems. Body parts and positioning. Containers with realistic item locations. Rooms with positioning, where you had to cross the room to use the exit at the other side. Construction of objects out of parts, and the ability to take them apart. Whether you were piecing together layers of clothing with wear commands, or making a sword by doing all the steps, this was supported. But we never conceived that the player would deal with manually doing all the commands to interact with all the realistic elements we had implemented. We thought it was obvious that this was simply a silly way to do it, and that abstracting it away to make it as easy, or easier, than the standard systems was the way to go. If we couldn't come up with usable abstractions, then we wouldn't have bothered with realistic equipment.


Unless you would force someone to remove his armor before changing his shirt, you are not talking about realism but 'believable' simplification of a real world situation.
16 Dec, 2012, quixadhal wrote in the 25th comment:
Votes: 0
Zork had this in the classic mailbox example, right at the start of the game.

You are told there's a letter in the mailbox. You *can* type all the tedious commands to "open mailbox; get letter; open letter; read letter", but you can also just "read letter". The game happily prints "You read the letter [after getting and opening it]."

In other words, if you have a clothing system with layers, and you want to change your undershirt, it's pretty obvious you have to remove your outer layers of clothing first, then wear the new shirt, then put the other layers back on. There's no need to force the user to type all that… just do the checks to ensure they CAN perform each action, and make it take however long it takes to do each one in sequence.

Letting the game do the obvious prerequisite steps in no way makes the game system less realistic, just less tedious for the player.
16 Dec, 2012, Rarva.Riendf wrote in the 26th comment:
Votes: 0
quixadhal said:
Letting the game do the obvious prerequisite steps in no way makes the game system less realistic, just less tedious for the player.

That would be true if it showed all the step (even if you dont have to type the orders) What if you have a 'noremove' armor ? Will you let him change his shirt ?
16 Dec, 2012, Igabod wrote in the 27th comment:
Votes: 0
quixadhal said:
Zork had this in the classic mailbox example, right at the start of the game.

I still have this game on my 1985 Tandy computer. It was actually my first introduction to text-based games. That and Hitchhikers Guide to the Galaxy and Leather Goddesses of Phobos. So much fun.

quixadhal said:
… just do the checks to ensure they CAN perform each action


That answer your question Rarva?
16 Dec, 2012, Rarva.Riendf wrote in the 28th comment:
Votes: 0
Igabod said:
quixadhal said:
… just do the checks to ensure they CAN perform each action

That answer your question Rarva?


Err yep missed that part.
But realistic behaviour leads to forcing you to sleep, eat (cook , go to the shop and find food (buy it, work to get money, etc), go to the bathroom, pee poo etc…(why realism for some stuff and not other…)
That's my point. At one point you have to restrain yourself.
16 Dec, 2012, Kjwah wrote in the 29th comment:
Votes: 0
Rarva.Riendf said:
Igabod said:
quixadhal said:
… just do the checks to ensure they CAN perform each action

That answer your question Rarva?


Err yep missed that part.
But realistic behaviour leads to forcing you to sleep, eat (cook , go to the shop and find food (buy it, work to get money, etc), go to the bathroom, pee poo etc…(why realism for some stuff and not other…)
That's my point. At one point you have to restrain yourself.


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. I already have to get up to use the restroom and it's not awesome in real life, it's not going to be awesome in the game. The challenge is finding the right balance of realism and fiction for your own game.

I like to try and add a lot of realism to my projects, doesn't make it right but it doesn't make it wrong either. :D
16 Dec, 2012, quixadhal wrote in the 30th comment:
Votes: 0
Yes, but why would you make the player manually perform most of those actions?

I think you guys forget where MUDs came from, the old classic D&D paper RPG. I'm sure there were a few terrible DM's who insisted their players announce themselves doing all that stuff too, but for the most part it's assumed you do "normal" stuff during downtime and when making camp for the evening.

So, eating, going to the bathroom, etc… those are all trivial details which the player's character will do whenever they need to be done, provided they have the ability to do so. There's no need to make the player type commands to do it. If they have money and are in town, they'll likely buy food when they're hungry. If they're in the woods, they'll likely hunt/fish/gather during short breaks, or at the beginning of the evening's camp.

That brings us to sleep. You've lumped it in with the others, but really… it's a different thing. If you want the player characters to need to sleep, you have to make a few decisions about how you want to do that. First, do you want to start stacking up penalties if they go without sleep for too long? Probably a good idea, since sleeping isn't something a player will likely WANT to do in a game. Next, do you want sleep to take only a moment, or do you want it to take actual game time? Most MUD's have opted for the former choice, because most players don't want to have to walk away from the game for 10 minutes (or however long 8 hours of game time is on the wall clock).

But, let's back up a second… why did D&D require sleep? How did your DM handle it? In my campaigns, the party had to settle down to camp each night (or day, depending), and that time was used to cook, clean, do field repairs, memorize and pray for spells, and finally actually sleep. Generally you set watches, and most nights were a series of dice rolls as each hour passed, to see if anything or anyone stumbled upon you. In an uneventful night, that took a few minutes. If something happened, it was a new mini-adventure.

Now, back to MUDs. There is no DM, but you can still do the random dice rolls for wandering encounters. But, the problem here is that a MUD isn't single player. In D&D, the DM can say "the night passes without incident", and 8 hours flows by. Here, you either have to have the disconnect that "sleep" really only takes a few minutes, or you have to make the player sit there for X real-time minutes so they stay in sync with the rest of the game world.

Or do you?

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.

My point here is, don't make the players do things that are boring. If you want some aspect of realism modeled, either do so transparently so it works but they don't have to worry about it… or make it enjoyable in some way.
16 Dec, 2012, KaVir wrote in the 31st comment:
Votes: 0
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. I already have to get up to use the restroom and it's not awesome in real life, it's not going to be awesome in the game.

There's no reason why it can't be entertaining, it depends entirely on how you implement it.

I once heard of a mud with a toilet where players regenerated exceptionally fast - however only one person could be in the room at a time, so players would often queue up outside, waiting for their turn.

In my own mud, the Bat Form power allows you to transform into a cloud of bats. With no weapons (or even limbs) it was difficult to think up different combat options, so I added one that sprays your opponent with guano, corroding their armour.

My argument isn't that realism is bad. It's that realism shouldn't come at the expense of fun. If you're adding realistic features that improve the game, that's great. If you're added realistic features that have no impact on the game, then while I might question your priorities, it's not really a problem. But I disagree with adding features that make the game frustrating purely on the basis that they're "realistic".

Eating, drinking, sleeping, even defecating, are not implementations. They're not even design concepts. They're simply the thematic justifications for design concepts. Most muds use them to justify gold sinks, but all those messages about eating, drinking, hunger and thirst are nothing more than cosmetic fluff for a frustrating feature. Eating, drinking and sleeping don't need to implemented in an annoying way.
17 Dec, 2012, Kjwah wrote in the 32nd comment:
Votes: 0
KaVir 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. I already have to get up to use the restroom and it's not awesome in real life, it's not going to be awesome in the game.

There's no reason why it can't be entertaining, it depends entirely on how you implement it.

I once heard of a mud with a toilet where players regenerated exceptionally fast - however only one person could be in the room at a time, so players would often queue up outside, waiting for their turn.


To be fair, I was speaking about actually having to stop, use the restroom, have it described as you do it and then move on. Sure, it could be funny but it's not something someone is going to want to have to do in a game constantly(Generally, I'm sure there's plenty of people that would love "Fecal MUDder"). Giving a benefit such as extra regen without actually describing what's going on is one thing, actually having to stop to defecate for no other reason than it just needs to be done? As someone who generally tries to add too much realism to my projects, that just seems going a bit too far.

I do mostly agree that realism isn't bad and shouldn't come at the expense of fun but I do have to say it depends on the goal of the game and the type of players you are trying to attract. :)
17 Dec, 2012, Igabod wrote in the 33rd comment:
Votes: 0
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 a really cool idea. I would enjoy a mud with that feature quite a lot. But I think dream-world should be an optional thing. You should have to prepare for it before going to sleep. Like you would have to spend a couple minutes meditating and light a candle or something first so you can prepare your mind for controlling your actions during sleep. That way players would be able to just sleep in order to regen health or they can go into dream-world and spend their allotted time per day in there. Maybe make it so that you can only gain mystical powers (magic etc.) by entering the dream-world and completing tasks there.
17 Dec, 2012, Famine wrote in the 34th comment:
Votes: 0
I have to say, there is a number of items listed here I would not consider a feature. Like for example, class/race combinations is not something I would ever consider a feature. While it may benefit the end user a great deal to have the option to choose diverse class/race combinations, I would not go out and say that's a feature. It's not really distinguished enough in my humble opinion to be a feature. Sure, semantics to some, but features normally are held to a higher standard too. But, maybe that's just my background in AAA game development talking as opposed to my MUD development.

Anyways, I wanted to point out that all game mechanics have flaws. The best solutions are normally player driven in terms of how your end users utilize those mechanics. Every player base is different, and sometimes the end results are different too. For example, what may be popular in terms of class/race on your MUD, may be different than what's popular on a similar MUD with the same class/races. Statistically, it may not make much sense because one is clearly stronger than the other. However, how players utilize the combinations may not factor in any of those stats either. So, players generally follow and learn from one another. When one player is in the same example dominating with a specific class/race–regardless if you feel it's statistically good or bad–then it triggers a chain reaction where others follow and learn from that player until someone else discovers something better. Thus, a change (or solution as you're all dubbing it for some unknown reason) may not lie in the class/races themselves, it may lie in how your end users actually discover the advantages and disadvantages of your game mechanics. Changes may be as simple as providing a tooltip that insights players why certain class/races work or don't work and etc.

Just food for thought before you all start analyzing everything on paper again and shoot yourselves in the foot thinking everything needs a solution based on what you think is bad or good.
17 Dec, 2012, KaVir wrote in the 35th comment:
Votes: 0
Kjwah said:
I do mostly agree that realism isn't bad and shouldn't come at the expense of fun but I do have to say it depends on the goal of the game and the type of players you are trying to attract. :)

Can you give an example of a type of mud where realism should come at the expense of fun - an example of frustrating features that should be implemented purely because they're "realistic"?

Famine said:
I have to say, there is a number of items listed here I would not consider a feature. Like for example, class/race combinations is not something I would ever consider a feature.

Classes and races are both cosmetic fluff for the same general design goal - arbitrating the capabilities of different characters. Most people would consider "classes" and "races" to be features, but if you design them in such a way that they always go together in pairs (elf-mage, dwarven-warrior, halfling-thief) then you effectively end up with a combinated "class/race" feature - classes and races can no longer be viewed as two independently viable features.

Famine said:
Anyways, I wanted to point out that all game mechanics have flaws. The best solutions are normally player driven in terms of how your end users utilize those mechanics.

All game mechanics have pros and cons, but some work out much better or worse than others, and sometimes the true significance of a feature doesn't become apparent until you've seen it in action. That's what this thread is all about - specific features I've seen and/or implemented myself, what I think their goal was, what actually happened, and alternative solutions I'd recommend for reaching the original goal.

Players can reveal the problems with a feature, but they are not a "solution" in their own right, except in very specific cases.

Famine said:
Changes may be as simple as providing a tooltip that insights players why certain class/races work or don't work and etc.

No, that is simply a workaround for a design flaw, it doesn't address the underlying problem.
17 Dec, 2012, Kjwah wrote in the 36th comment:
Votes: 0
KaVir said:
Kjwah said:
I do mostly agree that realism isn't bad and shouldn't come at the expense of fun but I do have to say it depends on the goal of the game and the type of players you are trying to attract. :)

Can you give an example of a type of mud where realism should come at the expense of fun - an example of frustrating features that should be implemented purely because they're "realistic"?


World building and crafting intensive games. In fact, I've been working on one for around ten years now. It's not my project but I've worked on it for so long now, it feels like it. :) I don't agree with a lot of the systems(I want it more realistic haha) but once we're finished with another project we're doing, we're going to shift focus back to this(or at least he will) and beta will not feature combat but world building. Farming, crafting, hunting, building cities, discovering basics of the world and whatnot.

After years of playing online games, there's one thing I've learned. There's a market for everything. People love to be punished(or rewarded from their view)… Some people like complex crafting systems, some like hard and complex combat sytems others(like most of the gaming community as of late) feel entitled to just have everything. It's sad to see it coming but the days of fun and challenging games is close to an end. :(
17 Dec, 2012, KaVir wrote in the 37th comment:
Votes: 0
Kjwah said:
KaVir said:
Kjwah said:
I do mostly agree that realism isn't bad and shouldn't come at the expense of fun but I do have to say it depends on the goal of the game and the type of players you are trying to attract. :)

Can you give an example of a type of mud where realism should come at the expense of fun - an example of frustrating features that should be implemented purely because they're "realistic"?


World building and crafting intensive games. In fact, I've been working on one for around ten years now. It's not my project but I've worked on it for so long now, it feels like it. :) I don't agree with a lot of the systems(I want it more realistic haha) but once we're finished with another project we're doing, we're going to shift focus back to this(or at least he will) and beta will not feature combat but world building. Farming, crafting, hunting, building cities, discovering basics of the world and whatnot.

I've implemented such features in the past as well, but I still focused on making them fun. I certainly never felt the need to make them more frustrating and less fun.

Kjwah said:
After years of playing online games, there's one thing I've learned. There's a market for everything. People love to be punished(or rewarded from their view)… Some people like complex crafting systems, some like hard and complex combat sytems others(like most of the gaming community as of late) feel entitled to just have everything. It's sad to see it coming but the days of fun and challenging games is close to an end. :(

I couldn't disagree more. While there's certainly a bigger market for simple games, I've seen nothing to suggest that players no longer want their games to be "fun". In fact I'm struggling to think what possible target audience such a game could have - if people don't like having fun, why would they play games in the first place?

My reading recommendation for the day: Theory of Fun for Game Design by Raph Koster.
17 Dec, 2012, Runter wrote in the 38th comment:
Votes: 0
Some of this discussion is quite confounding. If you like realistic, complex, onerous systems then it's probably because you think such things are fun. Fun isn't a universal quality of certain designs. We tend to design games that we (and like-minded) would enjoy playing, but within that realm there are right and wrong decisions. There are decisions that make you (and like-minded) enjoy the game less. There are correct decisions that increase that enjoyment. Without science you will not even figure out what those things are, and science is measuring tomorrow what you think unmeasurable today. These types of threads with empirical reasoning are precisely what good design is all about, and [after questioning] it's the surest path to making better decisions in the future. So thanks for that.
17 Dec, 2012, Kjwah wrote in the 39th comment:
Votes: 0
KaVir said:
Kjwah said:
KaVir said:
Kjwah said:
I do mostly agree that realism isn't bad and shouldn't come at the expense of fun but I do have to say it depends on the goal of the game and the type of players you are trying to attract. :)

Can you give an example of a type of mud where realism should come at the expense of fun - an example of frustrating features that should be implemented purely because they're "realistic"?


World building and crafting intensive games. In fact, I've been working on one for around ten years now. It's not my project but I've worked on it for so long now, it feels like it. :) I don't agree with a lot of the systems(I want it more realistic haha) but once we're finished with another project we're doing, we're going to shift focus back to this(or at least he will) and beta will not feature combat but world building. Farming, crafting, hunting, building cities, discovering basics of the world and whatnot.

I've implemented such features in the past as well, but I still focused on making them fun. I certainly never felt the need to make them more frustrating and less fun.

Kjwah said:
After years of playing online games, there's one thing I've learned. There's a market for everything. People love to be punished(or rewarded from their view)… Some people like complex crafting systems, some like hard and complex combat sytems others(like most of the gaming community as of late) feel entitled to just have everything. It's sad to see it coming but the days of fun and challenging games is close to an end. :(

I couldn't disagree more. While there's certainly a bigger market for simple games, I've seen nothing to suggest that players no longer want their games to be "fun". In fact I'm struggling to think what possible target audience such a game could have - if people don't like having fun, why would they play games in the first place?

My reading recommendation for the day: Theory of Fun for Game Design by Raph Koster.


I was going to separate the quotes but there's no real reason to, I agree with you, no reason to make them more frustrating than fun.

Maybe I worded it wrong, I didn't mean there's not going to be fun in games but the challenge part I stand by. Games aren't about fun and challenging and exciting and awesome, it's about what appears to be fun because it's addicting until they get you hooked. It's why those facebook micro-transaction games worked well. They weren't fun, they just knew how to be addicting and now big publishers are catching on and incorporating such tactics into AAA titles(Look at the boost in DLC since those facebook games).

Or maybe I'm just paranoid. :p

EDIT: Thanks for the book suggestion though, looks like a good read, going to check it out. :D
17 Dec, 2012, Famine wrote in the 40th comment:
Votes: 0
KaVir said:
All game mechanics have pros and cons, but some work out much better or worse than others, and sometimes the true significance of a feature doesn't become apparent until you've seen it in action. That's what this thread is all about - specific features I've seen and/or implemented myself, what I think their goal was, what actually happened, and alternative solutions I'd recommend for reaching the original goal.

Players can reveal the problems with a feature, but they are not a "solution" in their own right, except in very specific cases.
Famine said:
Changes may be as simple as providing a tooltip that insights players why certain class/races work or don't work and etc.

No, that is simply a workaround for a design flaw, it doesn't address the underlying problem.



I think you misunderstand what I mean. I'm saying through the players is a action (or solution as you dubbed it). Think of it as you being the doctor and your players being the patient. The action is through what the patient conveys as his or her symptoms. Possible actions (or solutions) are implemented based on those conveyed symptoms. They are not implemented based on assumptions without seeing the patient first. You cannot simply give all patients with similar symptoms the same action and hope it goes away basically. Every patient is different, every action is different and not just a solution.

It's important to understand that you are not fixing the mechanics. You're improving them based on the needs of the end user. If you take the approach of mechanics being broken from just your point-of-view (or expertise), then you're no longer making a game for the end users, you're making a game for yourself. Insert ivory tower and developer sitting on top where you are both giving the symptoms and the actions (or solutions).

Just to make it clear. I don't like the use of solutions for improving existing game mechanics. Solutions belong to bugs. So, if you're wondering why I keep avoiding the terminology, then that's why. The proposed features you listed are not broken in my opinion. They are working as they were intended to be designed. You may not agree with them, but that's surely doesn't justify them as needing a solution as if they were. I think the programmer in you is showing too much when you talk about design sometimes KaVir. :smile:
Random Picks
20.0/74