[MUD-Dev] PvP and teamspeak?

szii at sziisoft.com szii at sziisoft.com
Thu Oct 14 22:48:37 CEST 2004


Matt Mihaly wrote:

>> There's definitely good reasons to prevent Teamspeak, which gives
>> some players a significant out-of-game advantage. I don't think
>> you should try to control for things like good organization,
>> which all players are (theoretically) capable of.

> But that's not true. There are vastly differing levels of
> intelligence, capability, and social IQ at work. If having an
> "out-of-game" advantage (a bullshit distinction to begin
> with. Holdover from sloppy thinking about what roleplaying is, in
> my opinion.) is something to prevent, your only solution will be
> to take all control of the avatar out of the hands of the player,
> run it with identical server-side AI, and just let the player
> watch what his or her avatar does. Anything else brings
> out-of-game advantages like available free time, intelligence,
> organizational acumen, etc into the game.

Individual player skill, intelligence and free time are SINGLE
character traits which have little impact if they're an opponent.
Relaying troop strengths and positions has a HUGE impact on the
entire battle and not just a single player/character.

The "out-of-game" advantage is an implicit "you bring yourself and
your skills to the game."  I've known leaders who can't play for
crap but who're social-rats and can lead nations.

However, when you start "cheating" (bypassing LoS) with VoxComms...
well, what's the difference between that and my running a packet
analyzer on your data stream?  Or breaching your servers to acquire
that data.  What if I have a faster 'net connection than you do, and
I syn/ping flood you to slow/kill your connection? They're all "out
of game advantages" but they're not "bullshit distinctions" and each
have various levels of ramifications, both in-game and out of game.

-Mike/Szii
_______________________________________________
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