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

[Matt Chatterley]

On Tue, 14 Apr 1998, J C Lawrence wrote:
> 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.

Yeah. From the administrative/maintenance point of view, its this sort of
thing which is interesting to me too. From the player point of view, the
carnage is fun. Another possible 'theme' which occurs is something along
the lines of the old 'Smash TV' video game.
 
> > 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.

I definitely want to do something similar, to ensure there is never vastly
too great a region for too few players - for such a game to work, PC
contact must be frequent.
 
>   -- 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).

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

So basically, the map changes, but the changes from map to map are exerted
over an extended period of time?
 
>   -- 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.

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

But for me, roughly not keeping in balance - if I were working (as I am
currently thinking of doing) to hour-long games, I would want the balance
to tilt to increase the damage possible towards the end.

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

This is an alternative, of course. :)
 
> > 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.  

*cower*

I was certainly not intended to 'publicly' announce new players - thats
like hanging a bullseye around their necks.
 
>   -- 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.  

IOW, more or less leaving teams as a largely social construct with no game
mechanics or anything similar to fix them together. Very desirable,
actually. What is a guild? This is. ;)
 
> > 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.

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

Equally feasible. More so, infact.
 
> > 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.

Heh, Heh. I quite like this actually.
 
> > Pondering tying this into a coordinate system, rather than standard
> > 'rooms'. Unsure. Thoughts from the floor?
> 
> Seems almost necessary.

It certainly seems to be a lot more interesting than the 'rooms' approach.
Hmm. More and more leaning towards just writing this in Java, rather than
building an LPC lib.

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html