1998Q2/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev] There can be.. only ONE! -->
<!--X-From-R13: Dvpuneq Ibbypbpx <YnHveNqvny.cvcrk.pbz> -->
<!--X-Date: Wed, 15 Apr 1998 18:03:01 +0000 -->
<!--X-Message-Id: 35356836.35EB#dial,pipex.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199804150131.SAA164769#under,engr.sgi.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] There can be.. only ONE!</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:KaVir#dial,pipex.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
      text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">

  <font size="+4" color="#804040">
    <strong><em>MUD-Dev<br>mailing list archive</em></strong>
  </font>
      
<br>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00180.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00182.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00167.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00184.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00181">Author</A>
&nbsp;|&nbsp;<A HREF="#00181">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00181">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] There can be.. only ONE!</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] There can be.. only ONE! </LI>
<LI><em>From</em>: Richard Woolcock &lt;<A HREF="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</A>&gt;</LI>
<LI><em>Date</em>: Wed, 15 Apr 1998 19:08:54 -0700</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
J C Lawrence wrote:
&gt; 
&gt; On Sat, 11 Apr 1998 18:26:30 PST8PDT
&gt; Matt Chatterley&lt;matt#mpc,dyn.ml.org&gt; wrote:
&gt; 
&gt; &gt; A PK-only game set in an arena which is randomly built each time a
&gt; &gt; 'game' starts. The only form of persistance in your character are
&gt; &gt; the name (basically the fact that the character exists), and your
&gt; &gt; score (number of kills, number of deaths, login time).
&gt; 
&gt; ala Tron et al.  The really interesting parts of these sorts of
&gt; projects (to me) are in the game-world controls.
&gt; 
&gt; &gt; Weapons are strewn throughout the arena, players pick them up and
&gt; &gt; use them as they run around maiming and generally destroying each
&gt; &gt; other. When a player dies, his equipment held is randomly
&gt; &gt; redistributed around the arena, and the player is placed in a 'safe'
&gt; &gt; room until they choose to re-enter the game.
&gt; 
&gt; I'd be tempted to do something amusingly dynamic to help keep players
&gt; on their toes:
&gt; 
&gt;   -- The size of the world is dynamic and proportional to the number
&gt; of players.
&gt; 
&gt;   -- When the world resizes to fit the new/current player base size
&gt; it, the world also remaps to a *NEW* map.  The choice of map is based
&gt; on the size of the player base, and is predictable (ie XXX player base
&gt; == YYY map with the mappings and the maps well documented).

A predictable map would result in long-term players having an advantage.
Ever played Doom2 against someone who knows the areas better than you?
Predictability and stability can become boring over time.

&gt;   -- When the remapping occurs all players are informed of the fact
&gt; (despite the fact that they see the world change about them).

Are you talking about something like:

   A stone wall slides out of the ground, blocking the east exit.

   [x second delay]

   The ceiling shimmers for a moment, then fades out of existance.

   [x second delay]

   The ground crumbles beneath your feet.  You fall downwards...

Or more like:

   [long delay]

   The world seems to shift and distort around you!
   A stone wall slides out of the ground, blocking the east exit.
   The ceiling shimmers for a moment, then fades out of existance.
   The ground crumbles beneath your feet.  You fall downwards...

It would be more interesting IMO to have a constantly shifting world...

&gt;   -- The map then proceeds to change.  I envision an abstract world
&gt; with moving walls and floors, visual landmarks which can be oriented
&gt; on over large distances, etc (very Tron-like).  The key is that while
&gt; the base starting map for that is (presumably) well known, it very
&gt; quickly is no longer true.  Changes to the map would be both player
&gt; created as well as in-game sourced.

How about really obscure maps?  A quick example of something I coded by
accident...My mud uses x/y/z coords for dynamic rooms, but I've also left 
the option in to map static rooms over a specific location (so that I can
have pretty descriptions if I so wish).  One unintentional side affect of
this is that you can actually map a room onto different x/y/z locations.
This means that you could, for example, have a map like:

1 --- 2 --- 4 --- 1
      |
      1 --- 3 --- 5

This means that Bubba could walk onto the map (from the left), drop a pie,
walk three rooms east, and be back in the first room with the pie.  Another 
player might walk in from the south-east, walk west twice, and they would be 
in the same room as Bubba.  Should Bubba walk west (into room 4), and the 
other player try to follow, they would find there was no exit that way.

Just imagine the chaos you could cause if each player/team had their own
'version' of the map ;)  You could also have things like deathtrap rooms,
anti-gravity rooms (fall upwards), pits (fall downwards), teleportation
rooms, and so on...depends how obscure you want the world to be.

&gt;   -- All objects except players have a limited use-based lifespan.
&gt; Thus there is a resource management game in hoarding and using ones
&gt; resources to best effect.

If its pure pk, why not make player lifespan dependant on kills?  Kill
your opponent, drain their lifeforce, live for another X hours...

&gt;   -- As objects decay and are destroyed, new objects are popped
&gt; elsewhere in the world.  The pop locations are very non-deterministic,
&gt; and dependant on the current map etc.
&gt; 
&gt;   -- The game never actually resets.  The map keep changing, and
&gt; objects appearing, being used, and re-popping.

Yup that sounds pretty good...

&gt; &gt; Players are given the option of joining one of several running teams
&gt; &gt; (colours? something more interesting?), or playing solo.
&gt; 
&gt; Nahh, boring.
&gt; 
&gt;   -- Make the team concept a player based and derived thing, and then
&gt; make it anonymous.

*nods* that would work.  Allow any player to start their own team, and
allow them to set various options to customise their team...perhaps team
leaders could chose from a selection of advantages and disadvantages which
would be passed on to their team members?

&gt;   -- All new players are anonymous and de facto solo.

How anonymous?  Everyone looks identical?

&gt;   -- Players may be tagged by other players as members of their team.
&gt; This fact is private to the members of that team.  ie if you see a
&gt; character which is a member of a team you are in, he is identified as
&gt; such.  If you share no team memberships, then there is no such
&gt; identification.

Hmmm...

&gt;   -- How a new player goes about ensuring that they are recruited for
&gt; a team as vs being cannon fodder is their problem.
&gt; 
&gt;   -- Of course a player may thus be a member of many teams and play
&gt; all against each other.

Not sure about that, the mud might well turn into a free-for-all rather
than group tactics...

&gt; &gt; The size of the arena alters with number of logged in players, from
&gt; &gt; a minimum (5x5?) to a maximum (25x25?), adding approx 1x1 for every
&gt; &gt; player, to spread the action out a little.
&gt; 
&gt; I think the game would work best if the world preserved a great
&gt; possibility for surprise.  Large area effects, both player-created and
&gt; game-created are one idea here.

Definately...well planned ambushes should win over toe-to-toe hacking
matches.

&gt; &gt; The 'game' ends and the arena is recreated once each hour with a
&gt; &gt; current 'winner' being named as the person with the most kills per
&gt; &gt; death in that time.
&gt; 
&gt; Nahh -- just have a running tally with a public scoreboard.

Why not have both?  Have the matches restart every so often...but keep
track of overall scores.

&gt; &gt; Next, the setting. Several ideas occur at this moment in time:
&gt; 
&gt; &gt; 1. Highlander - various weapons available - the time-period, and
&gt; &gt; thus style of kit, changes from game to game at random, and to
&gt; &gt; 'kill' an opponent, you must behead them (you become slightly more
&gt; &gt; effective at fighting for every kill until you die).
&gt; 
&gt; Worse:  Different areas of the game have different (well posted)
&gt; equipment requirements.  High tech objects won't work in some areas,
&gt; will work in others etc, and similar for other objects.  Key: ensure many
&gt; mid-class weapons will work in many (but not all) areas.  Also ensure
&gt; that the geographic distribution of such restrictions varies wildly as
&gt; the world remaps across population changes.

You could go for a totally alien approach.  Completely unfamiliar equipment,
areas, 'things'...imagine a world where nothing seems to make sense, where
reality changes all the time.  Allow players to generate ALL aspects of their
characters from a list of balanced options; two arms, two legs and a head
would be a possible choice of course, but not necessarily the best.  Suction
feet would be useful for players who enjoy fighting upside down (standing on
the ceiling), while the more ariel-based players would use wings (bad for
tunnel crawling though).  Nightvision would be handy for those who hang around
in the dark areas of the map, but really annoying if they wanted to venture
into brighter locations.  Most players would probably want at least a couple
of legs, although purely water or air-based characters wouldn't need to.  An
armoured exoskeleton could help the more pure-combat-based characters, but
would be a death warrent if someone set a pit trap over water (unless you had
gills)...etc, etc...characters shouldn't improve over time, but there is no
reason at all that they should all be the same.

&gt; &gt; Pondering tying this into a coordinate system, rather than standard
&gt; &gt; 'rooms'. Unsure. Thoughts from the floor?
&gt; 
&gt; Seems almost necessary.

Agreed, no advantage doing it any other way.

KaVir.

</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00190" HREF="msg00190.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>
<ul compact><li><em>From:</em> Matt Chatterley &lt;matt#mpc,dyn.ml.org&gt;</li></ul>
<li><strong><A NAME="00188" HREF="msg00188.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>
<ul compact><li><em>From:</em> Vadim Tkachenko &lt;vt#freehold,crocodile.org&gt;</li></ul>
<li><strong><A NAME="00184" HREF="msg00184.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>
<ul compact><li><em>From:</em> J C Lawrence &lt;claw#under,engr.sgi.com&gt;</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00167" HREF="msg00167.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence &lt;claw#under,engr.sgi.com&gt;</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00180.html">Re: [MUD-Dev]  META: Web site backgrounds and readability</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00182.html">[MUD-Dev] Personality modelling</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00167.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00184.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00181"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00181"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><strong><A NAME="00136" HREF="msg00136.html">There can be.. only ONE!</A></strong>, 
Matt Chatterley <a href="mailto:matt#mpc,dyn.ml.org">matt#mpc,dyn.ml.org</a>, Sun 12 Apr 1998, 01:06 GMT
<UL>
<LI><strong><A NAME="00137" HREF="msg00137.html">Re: [MUD-Dev]  There can be.. only ONE!</A></strong>, 
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Sun 12 Apr 1998, 01:46 GMT
<UL>
<LI><strong><A NAME="00140" HREF="msg00140.html">Re: [MUD-Dev]  There can be.. only ONE!</A></strong>, 
Matt Chatterley <a href="mailto:matt#mpc,dyn.ml.org">matt#mpc,dyn.ml.org</a>, Sun 12 Apr 1998, 11:59 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00167" HREF="msg00167.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 15 Apr 1998, 01:31 GMT
<UL>
<LI><strong><A NAME="00181" HREF="msg00181.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
Richard Woolcock <a href="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</a>, Wed 15 Apr 1998, 18:03 GMT
<UL>
<LI><strong><A NAME="00184" HREF="msg00184.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 15 Apr 1998, 21:24 GMT
<UL>
<LI><strong><A NAME="00189" HREF="msg00189.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Thu 16 Apr 1998, 02:18 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00188" HREF="msg00188.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
Vadim Tkachenko <a href="mailto:vt#freehold,crocodile.org">vt#freehold,crocodile.org</a>, Thu 16 Apr 1998, 02:10 GMT
<UL>
<LI><strong><A NAME="00191" HREF="msg00191.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 16 Apr 1998, 03:31 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>