[MUD-Dev] Types of game

Travis Casey efindel at polaris.net
Sun Sep 21 19:54:59 CEST 1997


Adam Wiggins <nightfall at user2.inficad.com> wrote:
>[Caliban:]
>> On Sat, 20 Sep 1997 07:22:18 PST8PDT, Matt Chatterley

>> The distinction I draw here is as follows. A hack and slash game
>> actively encourages anti-social behavior (fighting and killing). A
>
>Again, see the above.  I don't agree.
>IMO, adventure is the most anti-social.  See my previous gripes about LPs.
>Of course, I consider pick-pocketing other people (particularly my friends)
>to be both fun and perfectly social.  Naturally this doesn't work if people
>aren't 'in' to that aspect of the game.  For that matter, I played a fair
>amount of multi-player Doom years ago, and I recall it being extremelly
>social.  Or go down to the Mac lab at the university I used to attend:
>you'll always find a gaggle of bespeckled nerds playing Marathon that are
>more than happy to let you hop into their game.  They have a grand old time
>blowing each other away.  This only works, of course, if you consider
>social to be interacting with others.  If social is only 'Wow, we're such
>good friends, I'm so glad' than I guess this doesn't work.

Perhaps "positive-valued social activities" and "negative-valued social
activities" are better descriptions, although I must say they're much too
long.  At least that terminology would recognize that one can be "social"
and not be a nice person.

>I strongly disagree.  Adventure games could be multi-player or not, and
>it makes no difference.  In fact, you're better off with someone looking
>over your shoulder helping you figure out puzzles than you are with another
>player in the game-room with you, since most puzzle-oriented games
>frown upon players working together on solving quests, and certainly
>disallow any sharing knowledge of previously solved quests.

That's not a problem with puzzle-solving itself, though -- just with the
way the mud in question allows it.  The idea of non-repeating quests has
been discussed here many times -- if a mud were to implement it, it would
eliminate the problem of knowledge sharing, or at least mitigate it.

It's perfectly possible to set up puzzles that *require* multiple players to
complete -- however, then you run into problems with players who prefer to
play solo.  Since I'm one of them, I wouldn't like that.  :-)  The best
solution, IMHO, would be puzzles which are easier to handle with multiple
players, but are possible for one player.

>Players play the game you make.  I'll say it before and I'll say it again:
>calling someone a power-gamer or an RPer is about as silly as accusing
someone
>who happens to be eating at a mexican restaurant a Mexican.  When I'm on
>a hack and slash mud, I powerplay.  When I'm on an RP mud or playing
Rolemaster
>with my friends, I role-play.  Trying to force players to role-play on a
>game not designed with this element at its core won't work.  If players
>aren't playing the game the way that you desire/think it should be played,
>then you need to check your design, not the players.

IMHO, this is a straw man argument.  Of course no one power-games or RPs or
whatever 100% of the time, but that doesn't mean that those aren't useful
classifications; some people *prefer* one of those modes of play, and it can
be useful to label them, *if* you remember that that doesn't mean they'll
*always* play that way.  To draw a parallel, my wife is a country music fan,
but that doesn't mean she *only* listens to country music -- just that it's
what she usually chooses to listen to.

For that matter, almost everyone on this list can be usefully classified as
a "mud developer" -- but I'm certain that no one on this list spends 100% of
their time developing muds.
--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
     '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html





More information about the mud-dev-archive mailing list