[MUD-Dev] The grass is always greener in the other field

Matthew Mihaly diablo at best.com
Fri Dec 17 21:45:58 New Zealand Daylight Time 1999


On Fri, 17 Dec 1999, J C Lawrence wrote:

> On Thu, 16 Dec 1999 18:02:36 -0800 (PST) 
> Matthew Mihaly <diablo at best.com> wrote:
> 
> > Yes, absolutely I care! I care because the players care! 
> 
> Do they really?  Will they remember or really be bothered that they
> put in a sword of stats X/Y/Z and that not one of the swords they
> pulled out *quite* matches that, but that they all come somewhere
> close?

Darn right they do. Most players know _exactly_ the stats of their
favourite swords. If they get a sword with particularly good stats, they
would be furious to have it reduced, as the distribution is a bell curve,
and getting ahold of a good sword is a fantastic thing for
them. Example: The average steel longsword in Achaea has damage modifier
of 100, to-hit of 150, and speed of 150. They are fairly expensive, as
they are, after all, longswords, but not particularly so. A nice pair of
diamond earrings would run you more. However, boost those stats by about
17%, and suddenly we are selling them for a lot of real money (we sold 4
at our last auction, at an average price of US $274.75). So if you are a
player, and you manage to get your hands on a particularly well-forged
sword with stats of, say, 108, 161, 160, you are going to be _damn_
possessive of that sword.


> Which is not what I wrote.  The set of 50 swords has a distribution
> model which the resulting aggreggate ur-objects can maintain.  There
> remains the possibility of putting 49 mediocre swords and one
> known-excellent sword into the pile and then pulling out 50
> almost-mediocre swords, but that's definitely a corner case that I
> suspect your players will overlook, and if not, that can be handled
> by your aggregate object observing and refusing to aggregate objects
> with non-median values.

I think you vastly underestimate the analness of players, or at least our
players (and that's not an insult to them. I would be similarly outraged
to be affected by your suggestion were that to happen to one of my players
in Achaea.) 

> 
> > A player expects, reasonably so, that sword #438 will have exactly
> > the same stats today as tomorrow. I suspect I may be
> > misunderstanding you though, as this seems obvious to me.
> 
> I rather doubt that this is true, especially when they are dealing
> with 50 swords as versus just a couple.

Well, in my experience in most certainly is true. I am quite sure my
players would be extremely annoyed to find their groups of weapons being
averaged together stat-wise (and I don't like it design-wise either, as I
like there to be a disparity in the quality of things).


> > Hmm, yes, I see what you are saying, but I'm not sure it is worth
> > it. Many of the items in Achaea are differentiated by a number of
> > stats (in the case of vials...type of vial...there are 20 types,
> > what's in the vial, how much of whatever is in it is left, how
> > long efore it decays, what sigils may be attached to that
> > individual vial (ie are in that vial's inventory. That's not
> > actually stored on the vial itself though. Just a pointer on the
> > attached items.), who made the vial, and so on.
> 
> Which my first tendency at representation would probably be a base
> object which contains an attribute list of modifiers.  The list
> would be of various length, and would contain references (pointers
> if you wish), to the modifiers to the basic object type (the sigils,
> type variations, yada yada).  You can then collapse all reasonably
> equivalent vials (same modifier list) to merely being references to
> the same base object and modifier list, instantiating only when an
> object deviates from the base by more than N (local lists on
> references of modifier over-rides).
> 
> Of course you'd have to do some statistical profiling of your vial
> distribution to see if this would save anythinng.

Yeah, I see what you are saying. I suspect it would probably save some
space, but in our case at least, the amount of memory it would save
probably isn't worth redoing the way things work so fundamentally. Still,
I appreciate the idea, thanks.
--matt




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list