[MUD-Dev] PvP Systems

J C Lawrence claw at kanga.nu
Sun Feb 18 00:23:33 CET 2001


On Sat, 17 Feb 2001 23:17:33 -0800 
John Buehler <johnbue at msn.com> wrote:

> J C Lawrence writes:

>> While I agree, this assumes that the creative work is singular
>> and non-aggregate.  In the case of large-world MUDs, which is
>> implied by large populations, it is almost necessarily aggregate
>> as players will, by nature, attempt to create their own stories
>> (and thus art) within, on, and beside what you do.

> And if they lack the tools to do so?  And if they are informed
> that those tools will not be made available to them?  

I posit that if they can occupy a location and communicate, they
have the requisite tools.

> I'm hoping that people's desires to do the sorts of things that
> you're talking about will be sated by the games that you and
> others will be constructing.

This is certainly part of the approach that Dr Cat is taking with
Furcadia.  Tools are not present, strong adminstrative control, and
a strong presentation of a "cute" milleua (tho not teletubbies) that
simply fails to begin to interest many classical grief players.

Cat: Would you mind commenting here a bit on how Furcadia has been
going?

> It's just that I don't have a recognized voice here.

I would hardly say you're unrecognised, its just that's there not
much chorus behind you.  Frankly, I'm glad you others help stop the
list from solidiying into cliche'd orthodoxy.

>>> Although your comment about time is undoubtedly meant to mean
>>> 'as the months elapse', it occurs to me that I might run my game
>>> such that it is open from something like 3PM until 1AM each day.
>>> The park actually closes at the end of each day.

>> Oooo!  *That* could be interesting (tho dreadful on the
>> international scale).

> Dreadful from the standpoint of trying to have enough deployments
> worldwide, or dreadful in that North American deployments would be
> running at very inconvenient times for overseas players?

Yes.

> Note that I'm going for a bit of a hybrid approach.  The NPC
> 'wranglers' run many NPCs and so actively oppose the players in a
> controlled way.  The NPCs aren't able to do everything that a
> player can do, of course, and when it comes to one-on-one
> encounters the NPCs will rely on their AI.  But the NPCs will be
> more dynamic and intelligent than any game AI could normally
> produce.  NPCs attacking will use more sophisticated strategies.
> Changes of routine will be introduced by the wrangler as they see
> opportunities.

An approach that has been mentioned on the list a couple times is
splitting such a game into two levels on opposite sides.  Loosely
the idea is a standard MUD (say with no PK support) with players
combatting the maurading hordes of NPCs.  However, the NPCs, rather
than being controlled by primitve AI or paid handlers, are in fact
the controlled by the players of a Real Time Strategy game played by
a different set of players.  Thus, the individual players, at a
strategic level, are figthing another human player playing an RTS,
and at a tactical level the normal wimpy AI bumph.  Similarly the
RTS players combatting the maurading/chaotic (to their eyes) MUD
players at the strategic level (who generally just appear as
excessively crazy/individuated opponents)..

>> Players are intended to be the bugs between the rock and the hard
>> place.  They are the default prey species for the rest of the
>> game, and the game is a far more effective predator than the
>> humans, with their intelligence, could ever hope to be.

> Sure, and that's obviously going to be an effective strategy for
> providing a particular form of entertainment.  

One hopes.

> It's a fairly high level form of entertainment that some folks
> will just find too intimidating.  

Heck, I find it intimidating.  My average lifespan before being
chomped (last time I had something that semi-ran) was under 5
minutes (I was playing with having basilisks have allergic reactions
to human pheremones).

> Some chunk of our population isn't prepared for truly predatory
> settings.

Which is the best bit.  I figure another large section will be
turned off by the 360 degree single eye view (all horizontal lines
display as hyperbolic sections etc) will chase away a good many
others.

>>> I would absolutely define a grief player in that way.  I won't
>>> hit the market with an open enrollment game until the internet
>>> solves the identity problem.  I simply don't need the money more
>>> than I care to deal with the corresponding customer support
>>> problem.

>> Whoa boy.  I'm one of those working on the side of ensuring that
>> that "problem" is not solved.

> Although off topic, I only want the mechanism to be there.  

While I know the exceptions (and there are many) and the problems
with questions of unique identity, credit card transactions would
seem to do most of that, and certainly as much of that as I'd want
to see done.  Yes, you can't tell if two accounts are the same
person, only that some number of registrations are one person
(duplicate account #, name, and mailing address) and not that some
other number of other registrations may not also be the same person
(different bank account # etc),  

Going past that requires the ability to uniquely identify humans in
regard to their 'net and financial transactions: the ability to take
discrete transactions (financial or otherwise), and demonstrably
derive that the same human was (not) involved in both no matter that
the human in question did not wish the transactions linked or
transparent to each other (doesn't matter as to positive or negative
-- one by elimination gives the other).  I'm not espousing universal
anonymity, but (using digital signatures as an example because their
machics are so clear cut and well known) there is a massive
difference between being able to prove that I, for the electronic
definition of "me", digitally signed a given document, and being
able to prove that two different documents signed by two different
digital keys were both siged by the same human (I'm using different
digital keys to define different digital identities).

Should that happen it would be a catastrophically Bad Thing.

ObNote: Yes, I'm aware of and agree with Bruce Schneier's
observations that something being digitally signed does not mean
that the owner of that key was the one to sign it, or that that
signature was not compelled etc etc etc.  This is why I define
"digital key" above as equal to "digital identity".

> You can stick to internet activity that permits anonymity, but I
> want to have the tools to be able to require player identity
> information.  

Fair dinkum.  I have no problem with the following equation:

  PlayerX is played by a human who can be reached at email address
  y at z and is paid for by bank account data QQQ.

I simply have a problem with:

  PlayerX is played by a human who can be reached at email address
  y at z and is paid for by bank account data QQQ.

  PlayerZ is played by a human who can reached at email address r at t
  and is paid for by bank account WWW.

  I am able to conclusively demonstrate that the same human is
  responsible for PlayerX and PlayerZ despite none of the above
  referenced data being common between them.

> I'm in the camp of anonymity being - to use your approach - a Bad
> Idea.

Oddly enough I'm no great fan of anonymity, and consider it highly
over-rated.  What I'm defending against is the ability to absolutely
identify.  If you want to put it into sound bite terms, I'm against
the technology being present to establish a universal and
inescapable means of identifying the human behind a transaction.
The potential and invitation for abuse is just too high.

Humanity hasn't grown up enough for that.

<<We're also drifting way off topic>>

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
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