[MUD-Dev] Maintaining fiction.
Neil Brown
neil_1_brown at yahoo.com
Sun Jun 3 12:46:50 CEST 2001
--- Paul Schwanz - Enterprise Services <Paul.Schwanz at Sun.COM> wrote:
> Neil Brown replied:
>> During our design sessions we constantly come up with great ideas
>> that would add realism to our game, and the vast majority of the
>> time those ideas fall victim to one of three frustrating
>> conditions:
[snip]
> I don't think that realism should be necessarily pursued for its own
> sake, but "realistic" solutions will likely be seen as much more
> intuitive and believable, certainly providing a greater chance for
> immersion that less realistic solutions. Additionally, where we are
> attempting to solve the same sort of problems with constructing a
> world or facilitating community that have already been solved by
> reality's Designer or addressed by real societies, I think we would
> be wise to take note.
I'm not sure I get the distinction here - we're pursuing realism
specifically to have a more realistic, intuitive, and believable game,
but while doing so, we're also trying not to destroy the fun. So I
suppose while we are, in fact, pursuing realism for its own sake,
we're doing so with the caveat that not all realistic features can or
even should be considered for a project such as this.
As for reinventing the wheel, mostly what we're doing is compensating
for corners we're forced to cut by not being able to model up the real
world perfectly and make alterations to that model to suit our needs.
This house of games we're building is all smoke and mirrors, and
precious few of those when compared with reality itself. We have to
chink up the walls with whatever we can muster, and it may or may not
be as realistic as we might like.
>> 1) Something I'll call "learning curve baggage" - The player must
> Perhaps the solution would be to implement realism while allowing
> the player to choose whether to pursue it from a player or a
> character perspective. In other words, if the player is interested
> in learning the details of forging a sword from scratch and managing
> the process in keeping with their character's current skill level,
> let them. On the other hand, if they are not interested or have
> grown tired of the detail work, let them instruct their character to
> manage the details for them. In this way, the fun factor will
> increase for some, but others are not forced to do busy work *as a
> player*.
This would also be a great addition, but if you wander too far outside
learning curve bagage territory, you fall into the pit traps of
balance:
* I want to bake swords! *
Let's take the sword forging example. To over-simplify a little,
let's say that you have a) The EQ-like easy-bake forge where you pop
in all the ingredients and <DING!> out pops a sword, and b) The forge,
anvil, quench tanks, charcoal pile, etc etc, where, in order to forge
a sword, you need to maintain proper temperatures for the forge and
quench tanks, as well as time each step properly or risk churning out
yet another expensive crowbar.
If the goal is to produce a sword and sell it for money of some kind,
and both methods result in the same end product, then who in their
right mind wouldn't take the Betty Crocker approach? The guys
churning out easy-bake swords will quickly out-produce the guys who
are doing the fiddly bits.
So let's assume that in order to fix this, you make both methods take
the same amount of time. I believe that Betty Crocker will win again
simply because it's easy and there's nothing to be gained by doing
things the hard way.
In both cases, I believe you will have spent a load of coding hours
working up a great forge simulator that's never going to be used.
One possible other side of the coin is to have the manual-forging
method allow you to produce a better quality product. Now the manual
guys can out-perform the Betty Crockers product-wise, and there's your
balance issue. Do you allow the easy-bakers to bake more swords than
the manual guys? By how much? How much better are the forged swords
than the easy-baked swords? etc etc.
( Incidentally, there's a great article on real sword-making on
www.howstuffworks.com )
>> 2) "Exploitability" - How easily the creative player can use this
>> feature to gain easy exp/wealth/whatever with little or no risk
>> to himself/time invested. People will take the easiest path they
>> can
> I'm interested in the assumption that gains should be tied closely
> to risk and time invested. This seems like an intuitive approach
> and probably one that I would take myself, but perhaps the concept
> bears further exploration. Why should gains be tied to risk and
> time invested? (And should these investments be character or player
This goes back to the "path-of-least-resistance" - people will take
the path to their goals offering the least resistance they can find.
To over-simplify again, if you make a skill that increases with use,
and all you have to do is push a button for it to increase, then
everyone will get blisters pounding on that button until their skill
is maxed out ( I'm not counting the blisters as risk ;). The bottom
line is that if you just hand feed skills, exp, and/or money to
players, they will eat them up until they're fat and bloated and then
they'll whine about how dull and un-challenging your game is. The
only sensible course of action is to limit the doling out of points
somehow while not making it next to impossible to get anywhere in the
game.
Obviously there's little risk in baking bread unless you count burning
your finger on the oven or the financial risk of buying the
ingredients, so you need to incorporate some way to throttle how fast
the skill increases or you'll wind up with a bunch of first level
master chefs. The quick solution is to make it take x time units to
bake bread, and y bread-baking tries for your skill to increase. Even
so, if you're not careful, you'll get people who will script up bread
baking and get their skill points essentially for "free".
A risk example could be the sneak skill. I suppose it's a rather
subjective assumption to make, but IMHO, your sneak skill should go up
more if you do it successfully getting past something for whom you
would be a nice snack were it to notice your presence than if you do
it successfully getting past something that really couldn't care if
you were there or not. Having a rule like this pretty much precludes
people scripting up something to increase their sneak skill since
they'd have to have a some damned good AI to deal with the failures.
> centric?) Is this something inherent in games, or is it more a
> reflection of our real-world experience insinuating itself into our
> game design? I tend to suspect it is the latter. In other words,
> it seems that you might be saying that some implementations of
> systems intended to promote realism actually end up detracting from
> realism in other areas.
They can, definitely. The best example I can think of off the top of
my head is probably the in-game economy. Just about every skill, and
every item looted from someplace has at least a small effect on the
economy, and yet the economy is nowhere near as complex as real life,
so trying to implement other realistic economy-affecting features can
have disastrous consequences. Let's say you implement a
value-localization system, so an item from city A is worth more in
city B because it's not local. Now you have the ability for players
to be traders. They load up their horses with city A widgets and hoof
it across the map to city B. The journey takes them a couple hours,
not a couple weeks, they don't have expenses associated with actually
making the journey ( food, shelter, protection, tolls, wagon repairs,
etc ), and unless your economic system supports market saturation,
they can make that same trip day in, day out turning a profit each
time. Pretty soon, they're very rich traders. I guess you could
argue that they earned it, but with that sort of easy moneymaking
venture present, you've opened yourself up to having a lot of
super-rich players and eventually devaluing your currency. In
reality, these traders did make a profit, but it took a long time to
do it, and the truly rich ones didn't do it themselves anyways, they
paid subordinates to handle the actual journey-making for them.
> Your "realism feature cascade" is also an interesting concept. I'd
> like to hear more about it. Do you have some design examples?
Ok, let's see if I can come up with one...Take plate mail, chain mail,
and the mace for example. Let me outline the thought process:
Designer 1: Hey, maces do more damage to you if you're wearing chain
than they do if you're wearing plate.
Designer 2: Great! Let's code it up so that if you get hit with a
mace and you're wearing chainmail, you take 2x damage!
Designer 1: Uh oh...what happens when someone's mixes it up and is
wearing a chain vest and plate everywhere else? You can bet if I
have a mace I'm going for his chest like it had a big bullseye
painted on it.
Designer 2: Oh...Ok, let's add targeted attacks.
Designer 3: Hey! No fair, now he can go for my chest specifically,
but I can't block it specifically!
Designer 2: Ok, let's add targeted blocking.
Designer 3: If I block my chest, is the AC on my legs worse?
Designer 2: Yes, we'll make it so that your AC is worse if you block
something else specifically.
Designer 3: When do I get to choose where I'm blocking?
Designer 2: Uhh...
Designer 1: When do I get to choose where I'm attacking
Designer 2: Uhh...
Designer 1: Hey, can I fake an attack so it looks like I'm going for
his chest, but then I swing for his legs?
Designer 2: Uhh...
Designer 3: Okok...If I have a shield in my left hand, and a sword
in my right hand, can I hold the shield over my chest, and keep the
sword in a low guard to protect my legs, while hopping from foot to
foot to provide a moving target?
Designer 2: That's it...I need a beer.
You can see where this is going - straight to hell in a handbasket.
At this point it's often useful to step back, figure out which thread
of discussion spurred this evil nightmare, and lop it off with extreme
prejudice. Then you can start over and try to come up with something
that won't drive your developers and players insane.
> Are we sure that realism is the problem and not that we just haven't
> yet nailed down a good design for certain systems within the game?
I'm not sure ANY systems are truly nailed down yet :) - everything
seems to be tied to everything else in some fashion, so it's more of a
"cooperative settling" rather than a nailing down process in a lot of
cases.
>> 3) The "Ass Factor" - How will the grief players use this feature
>> to annoy or otherwise corrupt the gaming experience for others.
> real world. It seems that online gaming reveals a human nature more
> reminiscent of Golding's _Lord of the Flies_ than of Brooke Shield's
> _Blue Lagoon_. :-P
That seems to be the unfortunate case, and designing for the grief
players in a commercial venture really lessens the experience for all
those people who would choose not to abuse a more robust system.
>> Agreed. Fake death is a fiction breaker. However, real death is a
>> fun-breaker for a lot of players, especially the casual gamers. We
>> need to keep those players interested in our game and not feeling
>> like they've just wasted a month of their time because all their
>> hard work just got his head chopped off by that hill giant they
>> didn't see while they were on their way back to town for the night.
> I think there are a number of issues here.
[snip]
> Personally, I don't particularly care for the way we do it. It
> seems like we do a sort of 'bait and switch' routine, although that
> isn't an entirely appropriate analogy. It isn't really that
> consequences are avoidable in most cases, but we *act* like there
> are certain consequences while we all know (wink, wink) that the
> *real* consequences are much different.
> "Oh no! Your character died! Isn't this terrible and dramatic!"
> (wink, wink)
> "Psst. You can revert to a saved game or resurrect and receive
> only a negligible penalty for your 'momentous' decision to attack
> a Balrog."
> Bleah.
[snip]
I don't know that I would call the penalties I've witnessed to be
negligible. The loss of a truckload of experience or even a whole
level in some games is a pretty big blow. I would rather have that,
however, than have the game tell me in so many words, "Sorry chum, you
just died and have to come back as your 15 year old son. You have to
explain to all your friends who you are. Your reputation as First
Knight of King Whassizname is gone, your sword training is gone,
you're back to making nails and horseshoes in your forge, and, oh, all
that fine equipment your pappy was using can't be recovered because
the Balrog melted it down to make a backscratcher. You're starting
from square one, boyo. Have a nice day." This will not keep people
coming back to play our game. We have just broken the trust between
player and service provider - we nullified the last x amount of time
they spent playing our game, and I wouldn't expect them to be happy
about it.
I constantly strive to remind myself, often with a nice, refreshing
slap in the face by another member of our design team, that this is a
game we're building, not a pre-industrial simulation. At the very
heart of what we're trying to accomplish with all this window dressing
is something that itself is not even remotely "realistic". Let me
list some things that aren't real with the genre I'm developing for:
- Our players are wandering around killing things that nobody in the
real world has ever seen with his own eyes.
- The creatures often die and come back to life a little while later
with no explanation!
- People are often killing these creatures using magic! Anyone who
has actually shot a lightning bolt and killed an angry zombie,
please step forward, I'd like to shake your hand ( The OTHER hand,
not the one with the lightning bolt, thanks ).
- Characters can take epic year-long journies around the known world
in a couple of hours of real-life time
- Our characters usually don't need sleep or rest
- Our characters can often carry enormously ponderous loads of items
and equipment while still able to fight with panther-like grace
- Our world is populated almost entirely with heroes of legendary
proportions
- Our characters can exchange a full set of plate mail for another
full set of plate mail he had stored on his back BY HIMSELF, WHILE
FIGHTING a horde of angry orcs.
...the list goes on. Personally, I'm ok with most of this because
it's a game we're playing, and such sidestepping from reality is
expected.
If you take that into perspective, I really do not see the problem
with having people be resurrected...Provided they come back as the
same person they died as, you can wrap it up in any story you like,
but in the end, it's just resurrection. I really like the save game
analogy. It's a single-player save in a multi-player world. The fact
that the save points are taken care of for you at the most opportune
time ( just before you die ) is just a handy feature. Heck, maybe
having people be able to save their character once an hour wherever
they want would be useful, I dunno.
[snip]
> creatures around go scurrying for cover? Why is the hill giant
> interested in lopping off a non-aggressive character's head in the
> first place? Can't the character outrun the hill giant? Are there
> ways for a character to grow or for a player to reach his goals that
> don't involve venturing into hill giant infested areas?
Well, I was really bringing up the hill giant to make a point - it
could just have easily been a bandit hidden in a tree shooting an
arrow through the eye of our hero. The point is that it was quick,
the player didn't have much of a chance, and now he's dead. If he's
resurrected with a minor penalty, he'll grumble a bit and get over it.
If he's perma-dead, your PR department is probably going to hear about
it.
[snip]
> For graphic games, I agree that text descriptions are not ideal. In
> fact, I'd expand that to say that I don't think that text based
> quest or plot developments are ideal either. For some reason, when
> I am playing a graphically based game, I feel that I am suspending
> my play to read text. Maybe that's just me, though.
I agree - I would rather everything be presented to me with movie-like
atmosphere, keeping the immersion going strong ( a la Black & White
). Unfortunately, that is a far larger undertaking for a MMORPG than
for a single player venture. I don't even know if that volume of
content is realistic yet. I can see the stickers on the box now: "20GB
Hard Drive Included!!" ;)
[snip]
> drop to their side and hang limply. Maybe a character whose leg is
> wounded performs an animation in which its leg buckles and then it
> regains its balance, but demonstrates less mobility.
All good suggestions. As I was saying, we don't intend to have any
blood-squirting happening, and having a creature limp or fall over
would provide good visual cues as to what is going on.
[snip]
> Merchant clicks on "reject terms" button to close out first
> interface, then clicks on his own "offer yield" button and drags 200
> gold pieces into the interface. Bandit clicks on "accept yield" and
> once again, neither he nor the merchant can attack each other for a
> specified time period, but the merchant may still report the crime.
Not a bad idea - hopefully we've gotten this far without messing up
our economy to the point that anyone over level 10 has so much cash
available that the terms offered by your NPCs are a drop in the
bucket, but someone just starting the game can barely afford bread.
On the other hand, this is all well and good for bandits, but what
about things that are really quite anti-social like undead? I'd have
to be a few tomatoes short of a thick, rich paste to try and pay a
zombie not to work me over with that rusty axe he's carrying. And if
you're going to have at least one type of creature that you can't
surrender to then the entire perma-death problem needs to be addressed
otherwise everyone will just hit a website before playing, grab the
latest list of 'anti-social critters', and avoid them like the plague.
Sorry for another long post everyone.
-o-
Neil
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list