1998Q2/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev] There can be.. only ONE! -->
<!--X-From-R13: [ngg Qunggreyrl <znggNzcp.qla.zy.bet> -->
<!--X-Date: Thu, 16 Apr 1998 02:20:30 +0000 -->
<!--X-Message-Id: Pine.LNX.3.96.980416030748.2472C&#45;100000#mpc,dyn.ml.org -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 35356836.35EB#dial,pipex.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:matt#mpc,dyn.ml.org">
</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="msg00189.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00191.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00196.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00186.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00190">Author</A>
&nbsp;|&nbsp;<A HREF="#00190">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00190">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>: Matt Chatterley &lt;<A HREF="mailto:matt#mpc,dyn.ml.org">matt#mpc,dyn.ml.org</A>&gt;</LI>
<LI><em>Date</em>: Thu, 16 Apr 1998 03:19:50 +0000 (GMT)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:neddy#itl,net">neddy#itl,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Wed, 15 Apr 1998, Richard Woolcock wrote:
&gt; J C Lawrence wrote:
&gt; &gt; On Sat, 11 Apr 1998 18:26:30 PST8PDT
&gt; &gt; Matt Chatterley&lt;matt#mpc,dyn.ml.org&gt; wrote:
&gt; &gt; 
&gt; &gt; &gt; A PK-only game set in an arena which is randomly built each time a
&gt; &gt; &gt; 'game' starts. The only form of persistance in your character are
&gt; &gt; &gt; the name (basically the fact that the character exists), and your
&gt; &gt; &gt; score (number of kills, number of deaths, login time).
&gt; &gt; 
&gt; &gt; ala Tron et al.  The really interesting parts of these sorts of
&gt; &gt; projects (to me) are in the game-world controls.

[Snip]

&gt; &gt; I'd be tempted to do something amusingly dynamic to help keep players
&gt; &gt; on their toes:
&gt; &gt; 
&gt; &gt;   -- The size of the world is dynamic and proportional to the number
&gt; &gt; of players.
&gt; &gt; 
&gt; &gt;   -- When the world resizes to fit the new/current player base size
&gt; &gt; it, the world also remaps to a *NEW* map.  The choice of map is based
&gt; &gt; on the size of the player base, and is predictable (ie XXX player base
&gt; &gt; == YYY map with the mappings and the maps well documented).
&gt; 
&gt; A predictable map would result in long-term players having an advantage.
&gt; Ever played Doom2 against someone who knows the areas better than you?
&gt; Predictability and stability can become boring over time.

Yeah. This is bad. This is also why I don't want the maps to be 'written
down' anywhere - I want the game to generate them when appropriate. No
reason why this can't be enhanced as hinted at in the following..
 
&gt; &gt;   -- When the remapping occurs all players are informed of the fact
&gt; &gt; (despite the fact that they see the world change about them).
&gt; 
&gt; Are you talking about something like:
&gt; 
&gt;    A stone wall slides out of the ground, blocking the east exit.
&gt; 
&gt;    [x second delay]
&gt; 
&gt;    The ceiling shimmers for a moment, then fades out of existance.
&gt; 
&gt;    [x second delay]
&gt; 
&gt;    The ground crumbles beneath your feet.  You fall downwards...

This is something that I really like, to be honest; the world constantly
changing makes the environment much more challenging. Add in the odd NPC
(acting just to flesh out the action during slow periods), and traps both
naturally occuring and pre-set by other inhabitants, and you have quite an
interesting environment.
 
&gt; Or more like:
&gt; 
&gt;    [long delay]
&gt; 
&gt;    The world seems to shift and distort around you!
&gt;    A stone wall slides out of the ground, blocking the east exit.
&gt;    The ceiling shimmers for a moment, then fades out of existance.
&gt;    The ground crumbles beneath your feet.  You fall downwards...
&gt; 
&gt; It would be more interesting IMO to have a constantly shifting world...

Yes, the former is for me, more desirable.
 
[Snip map example]

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

Yeah. I'm thinking along some ideas JCL dropped, actually, and pondering
the world being set over a number of themes (with higher 'tech' items not
functioning in lower tech areas), compressed together. This'd mean that
various obscure effects could fit into certain places. The game premise is
bound to be a bit tenuous and bizarre anyway, so why not throw in fun
things?! :)
 
&gt; &gt;   -- All objects except players have a limited use-based lifespan.
&gt; &gt; Thus there is a resource management game in hoarding and using ones
&gt; &gt; resources to best effect.
&gt; 
&gt; If its pure pk, why not make player lifespan dependant on kills?  Kill
&gt; your opponent, drain their lifeforce, live for another X hours...

Heh, heh. An adaptation of the 'highlander' idea, really - your life-force
determines how strong you are (a single uni-stat system), and leeches away
over time. It runs out, you die. You kill someone and you absorb theirs.
Gives you longer to live, and makes you stronger, for a time.
 
&gt; &gt;   -- As objects decay and are destroyed, new objects are popped
&gt; &gt; elsewhere in the world.  The pop locations are very non-deterministic,
&gt; &gt; and dependant on the current map etc.
&gt; &gt; 
&gt; &gt;   -- The game never actually resets.  The map keep changing, and
&gt; &gt; objects appearing, being used, and re-popping.
&gt; 
&gt; Yup that sounds pretty good...

This is necessary, I think, really; giving the game stops and starts as I
originally intended would be very disruptive. Note that there will of
course be no quit command. After you disconnect, you should become an NPC
(simplistically controlled), until eliminated.
 
&gt; &gt; &gt; Players are given the option of joining one of several running teams
&gt; &gt; &gt; (colours? something more interesting?), or playing solo.
&gt; &gt; 
&gt; &gt; Nahh, boring.
&gt; &gt; 
&gt; &gt;   -- Make the team concept a player based and derived thing, and then
&gt; &gt; make it anonymous.
&gt; 
&gt; *nods* that would work.  Allow any player to start their own team, and
&gt; allow them to set various options to customise their team...perhaps team
&gt; leaders could chose from a selection of advantages and disadvantages which
&gt; would be passed on to their team members?

Sounds very nice, actually, but what sort of plusses and minuses can you
allow to be configurable in an environment which by its nature has very
few stats?

As is I have: strength, hitpoints as statistics. I can add 'speed' if its
a coordinate grid, and also 'eyesight', which gives four, I suppose. :)

&gt; &gt;   -- All new players are anonymous and de facto solo.
&gt; 
&gt; How anonymous?  Everyone looks identical?

No big glaring 'newbie!' signs, no preferential treatment, no nice newbie
kits. Drop them straight in with no announcements, after they read the
help. Contemplating having accounts which you log into, and then you
select a character name (either from a list, or just enter one at
go-time), and only storing statistics against that account. Noticeboards
and such accessible from account-level, but no notion as to which
character is which account..
 
[Snip]

&gt; &gt;   -- How a new player goes about ensuring that they are recruited for
&gt; &gt; a team as vs being cannon fodder is their problem.
&gt; &gt; 
&gt; &gt;   -- Of course a player may thus be a member of many teams and play
&gt; &gt; all against each other.
&gt; 
&gt; Not sure about that, the mud might well turn into a free-for-all rather
&gt; than group tactics...

The mud begins as a free-for-all; the team notion is a temporary fixture.
For those who follow the 'highlander' series and show (ack, I have to stop
using this for examples, I really do), There can be only one. Duncan &amp;
Connor are friends - but in the end, if they were the only two left, and
on the same team, they'd have to fight it out anyway.
 
&gt; &gt; &gt; The size of the arena alters with number of logged in players, from
&gt; &gt; &gt; a minimum (5x5?) to a maximum (25x25?), adding approx 1x1 for every
&gt; &gt; &gt; player, to spread the action out a little.
&gt; &gt; 
&gt; &gt; I think the game would work best if the world preserved a great
&gt; &gt; possibility for surprise.  Large area effects, both player-created and
&gt; &gt; game-created are one idea here.
&gt; 
&gt; Definately...well planned ambushes should win over toe-to-toe hacking
&gt; matches.

Yup. If there are very few stats, and all characters are similar except
for kit, getting the drop and having superior numbers will be a big plus.
Being able to cut off escape routes will be handy, too.
 
&gt; &gt; &gt; The 'game' ends and the arena is recreated once each hour with a
&gt; &gt; &gt; current 'winner' being named as the person with the most kills per
&gt; &gt; &gt; death in that time.
&gt; &gt; 
&gt; &gt; Nahh -- just have a running tally with a public scoreboard.
&gt; 
&gt; Why not have both?  Have the matches restart every so often...but keep
&gt; track of overall scores.

*ponder* I quite like the 'continuous gameplay' idea, rather than stopping
and starting at intervals. Perhaps put in a mechanism by which a player
can bring about the end of a 'game' - winning a certain number of straight
victories, applying an item, etc.
 
&gt; &gt; &gt; Next, the setting. Several ideas occur at this moment in time:
&gt; &gt; 
&gt; &gt; &gt; 1. Highlander - various weapons available - the time-period, and
&gt; &gt; &gt; thus style of kit, changes from game to game at random, and to
&gt; &gt; &gt; 'kill' an opponent, you must behead them (you become slightly more
&gt; &gt; &gt; effective at fighting for every kill until you die).
&gt; &gt; 
&gt; &gt; Worse:  Different areas of the game have different (well posted)
&gt; &gt; equipment requirements.  High tech objects won't work in some areas,
&gt; &gt; will work in others etc, and similar for other objects.  Key: ensure many
&gt; &gt; mid-class weapons will work in many (but not all) areas.  Also ensure
&gt; &gt; that the geographic distribution of such restrictions varies wildly as
&gt; &gt; the world remaps across population changes.
&gt; 
&gt; You could go for a totally alien approach.  Completely unfamiliar equipment,
&gt; areas, 'things'...imagine a world where nothing seems to make sense, where
&gt; reality changes all the time.  Allow players to generate ALL aspects of their
&gt; characters from a list of balanced options; two arms, two legs and a head
&gt; would be a possible choice of course, but not necessarily the best.  Suction
&gt; feet would be useful for players who enjoy fighting upside down (standing on
&gt; the ceiling), while the more ariel-based players would use wings (bad for
&gt; tunnel crawling though).  Nightvision would be handy for those who hang around
&gt; in the dark areas of the map, but really annoying if they wanted to venture
&gt; into brighter locations.  Most players would probably want at least a couple
&gt; of legs, although purely water or air-based characters wouldn't need to.  An
&gt; armoured exoskeleton could help the more pure-combat-based characters, but
&gt; would be a death warrent if someone set a pit trap over water (unless you had
&gt; gills)...etc, etc...characters shouldn't improve over time, but there is no
&gt; reason at all that they should all be the same.

Fascinating. You create a character from a series of menus at go-time, and
this defines certain properties which affect what you can and can't do,
and how well you perform at certain tasks, as well as special abilities.
Unsure if I'd use it, but its still fascinating. You could even make the
characters 'robots' of some fashion, composed of a selection of elements,
and have the equipment take the form of add-on and replacement parts. Ooh.
I like that.
 
&gt; &gt; &gt; Pondering tying this into a coordinate system, rather than standard
&gt; &gt; &gt; 'rooms'. Unsure. Thoughts from the floor?
&gt; &gt; 
&gt; &gt; Seems almost necessary.
&gt; 
&gt; Agreed, no advantage doing it any other way.

Thats me finally sold on just writing a scratch server in Java.

-- 
Regards,
	-Matt Chatterley
Spod: <A  HREF="http://user.super.net.uk/~neddy/spod/spod.html">http://user.super.net.uk/~neddy/spod/spod.html</A>


</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00181" HREF="msg00181.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
<UL><LI><EM>From:</EM> Richard Woolcock &lt;KaVir#dial,pipex.com&gt;</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00189.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00191.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00196.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00186.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00190"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00190"><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>Re: [MUD-Dev] There can be.. only ONE!</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<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
<UL>
<LI><strong><A NAME="00198" HREF="msg00198.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>, Thu 16 Apr 1998, 17:26 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00196" HREF="msg00196.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>, Thu 16 Apr 1998, 17:10 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00190" HREF="msg00190.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>, Thu 16 Apr 1998, 02:20 GMT
</LI>
</ul>
<LI><strong><A NAME="00186" HREF="msg00186.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>, Thu 16 Apr 1998, 02:05 GMT
<UL>
<LI><strong><A NAME="00195" HREF="msg00195.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>, Thu 16 Apr 1998, 16:57 GMT
<UL>
<LI><strong><A NAME="00207" HREF="msg00207.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>, Fri 17 Apr 1998, 22:33 GMT
<UL>
<LI><strong><A NAME="00208" HREF="msg00208.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>, Sat 18 Apr 1998, 00:20 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</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>