[MUD-Dev] There can be.. only ONE!

[J C Lawrence]

On Sat, 11 Apr 1998 18:26:30 PST8PDT 
Matt Chatterley<matt at 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).

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

  -- 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.

  -- 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.

  -- As objects decay and are destroyed, new objects are popped
elsewhere in the world.  The pop locations are very non-deterministic, 
and dependant on the current map etc.

  -- The game never actually resets.  The map keep changing, and
objects appearing, being used, and re-popping.

> Players are given the option of joining one of several running teams
> (colours? something more interesting?), or playing solo.

Nahh, boring.  

  -- Make the team concept a player based and derived thing, and then
make it anonymous.  

  -- All new players are anonymous and de facto solo.  

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

  -- 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.  

> The size of the arena alters with number of logged in players, from
> a minimum (5x5?) to a maximum (25x25?), adding approx 1x1 for every
> player, to spread the action out a little.

I think the game would work best if the world preserved a great
possibility for surprise.  Large area effects, both player-created and 
game-created are one idea here.

> 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.

> Next, the setting. Several ideas occur at this moment in time:

> 1. Highlander - various weapons available - the time-period, and
> thus style of kit, changes from game to game at random, and to
> 'kill' an opponent, you must behead them (you become slightly more
> effective at fighting for every kill until you die).

Worse:  Different areas of the game have different (well posted)
equipment requirements.  High tech objects won't work in some areas,
will work in others etc, and similar for other objects.  Key: ensure many
mid-class weapons will work in many (but not all) areas.  Also ensure
that the geographic distribution of such restrictions varies wildly as 
the world remaps across population changes.

> Pondering tying this into a coordinate system, rather than standard
> 'rooms'. Unsure. Thoughts from the floor?

Seems almost necessary.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...