<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] There can be.. only ONE! -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Wed, 15 Apr 1998 21:24:27 +0000 -->
<!--X-Message-Id: 199804152124.OAA168693#under,engr.sgi.com -->
<!--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:claw#under,engr.sgi.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>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00183.html">Previous</a>
| <a href="msg00185.html">Next</a>
]
Thread:
[ <a href="msg00181.html">Previous</a>
| <a href="msg00189.html">Next</a>
]
Index:
[ <A HREF="author.html#00184">Author</A>
| <A HREF="#00184">Date</A>
| <A HREF="thread.html#00184">Thread</A>
]
<!--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>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Wed, 15 Apr 1998 14:24:03 -0700</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 11:26:45 PST8PDT
Richard Woolcock<KaVir#dial,pipex.com> wrote:
> J C Lawrence wrote:
>> On Sat, 11 Apr 1998 18:26:30 PST8PDT Matt
>> Chatterley<matt#mpc,dyn.ml.org> wrote:
>>
>> > A PK-only game set in an arena which is randomly built each time
>> a > 'game' starts. The only form of persistance in your character
>> are > the name (basically the fact that the character exists), and
>> your > score (number of kills, number of deaths, login time).
>>
>> ala Tron et al. The really interesting parts of these sorts of
>> projects (to me) are in the game-world controls.
>>
>> > Weapons are strewn throughout the arena, players pick them up and
>> > use them as they run around maiming and generally destroying each
>> > other. When a player dies, his equipment held is randomly >
>> redistributed around the arena, and the player is placed in a
>> 'safe' > room until they choose to re-enter the game.
>>
>> I'd be tempted to do something amusingly dynamic to help keep
>> players on their toes:
>>
>> -- The size of the world is dynamic and proportional to the number
>> of players.
>>
>> -- When the world resizes to fit the new/current player base size
>> it, the world also remaps to a *NEW* map. The choice of map is
>> based on the size of the player base, and is predictable (ie XXX
>> player base == YYY map with the mappings and the maps well
>> documented).
> A predictable map would result in long-term players having an
> advantage.
Yes, this is deliberate and seen as a Good Thing.
> Ever played Doom2 against someone who knows the areas
> better than you? Predictability and stability can become boring
> over time.
Quite. This is also why while the initial map as set due to the
population change is known, documented, and fixed, it then evolves
resaonably rapidly from there (one could make the map modification
rate proportional to the player death rate). This way the old timers
have a large advantage immediately after a population change, but then
must increasingly rely on topical knowledge (as must the rest of the
player base).
>> -- When the remapping occurs all players are informed of the fact
>> (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...
My preference would be for #2, possibly with a presenation ala:
> l
...description...
Suddenly the world shifts and wrenches, and implodes! There is
a flash! Something twists in a way the universe was not meant
for, and then..
> l
...description of new location...
The server-side implementation would initialise the new map in the
background and then *BLINK* iterate across all players and translate
them to their new positions in the new map (all carried objects of
course following). The old may can then be safely desctructed in the
background. If need be you can also do the translation of players
between the maps gradually -- they'll likely never notice, and if they
do its easy to explain away.
This has the general benefits of not requiring the players to suffer
while the new map is being built-up, or the old one torn down. For
them its instantaneous. Its also easier to design new maps for as you
then don't have to do the translations from every map to every other
map (what happens if 100 players suddenly log on or off the game? 50?
10? 5? 150? You are going to need translations between all your
maps with #1).
The other nice thing about this approach is that all players are
equally disoriented. While they may know the new map (do a WHO, count
number of players, look in table, get map for new world, done), they
initially (all) have no idea where they are in it. Scurry time --
much like lifting a rock on a scorpion nest.
> It would be more interesting IMO to have a constantly shifting
> world...
That's the idea -- but also that upon shifts players who orient
sufficiently quickly will have a good idea what the map looks like.
Idea: Any death causes the surrounding area for a radius which is a
function of the kill/death ratio of the newly dead to be remapped to
the map of a world distant (player-count distant) inversely
proportional to the time since the last remapping. Thus, killing a
successful character causes a very large portion of the surrounding
world to suddenly change. The sooner you kill him after the last
world-wide reset, the more alien the map in the changed area will be
(actually its really only a randomity function, not a delta, but hey).
>> -- The map then proceeds to change. I envision an abstract world
>> with moving walls and floors, visual landmarks which can be
>> oriented on over large distances, etc (very Tron-like). The key is
>> that while the base starting map for that is (presumably) well
>> known, it very quickly is no longer true. Changes to the map would
>> be both player 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:
Did you catch the discuccion late last year on my old areas of
Fortress Fract, The Blue Grass Path etc? I used tricks like this (and
others far far worse) there. I'll expound if there's interest.
> 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.
Yup.
Lambert's comment of using DOOM or Quake wad files also seems
pertinent here.
>> -- All objects except players have a limited use-based lifespan.
>> Thus there is a resource management game in hoarding and using ones
>> 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...
Mostly because I like careful snipers and assassins.
>> -- All new players are anonymous and de facto solo.
> How anonymous? Everyone looks identical?
Yup, or at least identical within the class of their character type
(species or whatever).
>> -- How a new player goes about ensuring that they are recruited for
>> a team as vs being cannon fodder is their problem.
>>
>> -- Of course a player may thus be a member of many teams and play
>> all against each other.
> Not sure about that, the mud might well turn into a free-for-all
> rather than group tactics...
My suspicion is that carefully orchestrated group tactics coordinated
by in-game comms equipment (realtime overhead maps, team-private
channels etc) would be enough to heavily encourage team play while
keeping the interest alive for the skulkers and snipers. It would
tend to make the weights in favour of tactics. Strategy would never
really apply.
>> > The 'game' ends and the arena is recreated once each hour with a
>> > current 'winner' being named as the person with the most kills
>> per > death in that time.
>>
>> 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.
Mostly because I see no reason to have artificial resets or pacing to
the game. Sure, make it and endless melee and then periodically post
the current scores, "As of XXX time the scores for the previous hour
were..."
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</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="00189" HREF="msg00189.html">Re: [MUD-Dev] There can be.. only ONE!</A></strong>
<ul compact><li><em>From:</em> Vadim Tkachenko <vt#freehold,crocodile.org></li></ul>
</UL></LI></UL>
<!--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 <KaVir#dial,pipex.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00183.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00185.html">Re: [MUD-Dev] META: Web site backgrounds and readability</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00181.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00189.html">Re: [MUD-Dev] There can be.. only ONE!</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00184"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00184"><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>
<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
<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>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
