Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site sdccs7.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!ittvax!dcdwest!sdcsvax!sdccs7!ee163aca
From: ee163aca@sdccs7.UUCP
Newsgroups: net.games.rogue
Subject: How about Multiplayer Rogue?
Message-ID: <1194@sdccs7.UUCP>
Date: Mon, 16-Apr-84 04:55:47 EST
Article-I.D.: sdccs7.1194
Posted: Mon Apr 16 04:55:47 1984
Date-Received: Tue, 17-Apr-84 07:33:09 EST
Organization: U.C. San Diego, Computer Center
Lines: 81

[]

	Is anyone interested in the idea of a multiplayer rogue?  Not that I    
want to write such a beast (I haven't any sources anyway.) , but perhaps the 
original authors might find my ideas interesting.

	I don't think that it would be as hard to program as you might think.
Several players could be in the dungeon at once, and they could be treated as
*Special*  monsters as far as the other players are concerned.  Since monsters
can carry and drop items in some rudimentary fashion already, I don't think 
this will be a problem.  Fighting between players could be handled in the same
way as fighting with monsters is.  Since monsters can't be on the same the same
space as you are, I would think that any collisions between players could be 
handled without much trouble ( There is that stepping on an Orc Bug in 5.3 but 
bear with me).

	The main problem I see is maintaining a single dungeon for all players.
My guess would be that each player would have his own process running rogue, and
he would access a global data-structure holding the dungeon for all the players.
Whenever a player makes a movement or drops an object the global dungeon would
be updated.  But, this leads to some interesting problems:

- How often is a new dungeon generated?

	My guess is every day or two, otherwise players would know the dungeon
	too well, and take advantage.  This suggests that game saving will only
	be allowed for the time between updates, and that only the player's
	position and possesions will be saved.

- Won't the upperlevels of the dungeon become depleted of resources as
	players make their way down?

	This is a tricky problem, because players will arrive, die, or win
	at any given time.  My solution would be to add items to a level as
	soon as a new player climbs down the stair to that level.  This still
	leave a problem of more than one player on one level at a time.  The 
	one who was there first might take all the items before the other gets
	a chance.

- What do you do with a player's possesions when he dies?

	I want to leave the possesions (including the gold) right where the 
	player dies so other players can find them.  In the lower levels,
	where everyone gets killed, there will be a jackpot of all the good 
	stuff people carried down.

- There is only one amulet of Yendor.

	This makes it even more fun, everyone will fight over it! 

Some interesting playing styles might be used:
 
- Players could cooperate in killing the monsters.

- Players could fight.

	If one guy has the amulet, the others might gang-up on him an kill him
	to get the amulet, and his gold.

- Players could trade items between themselves.

	This would be implemented by having one player drop an object, and the
	other pick it up.  You could even sell objects by having one player drop
	gold (or an agreed upon item) and the other dropping the item that is
	being sold.  Of course, one guy could cheat the other by picking up the
	object before giving his object.  These kind of disputes could be 
	settled with a fight.  I can hear it now: "Your gold (rings,wands,etc.)
	or your life!".

- Players might be allowed to talk to one another.

	If they aren't in the same (physical) room, there would have to be some
	mechanism to talk to another player so that they could cooperate or 
	trade.  If you were in trouble (ex. dying of starvation) you could shout
	for help.
	( This could wake up all the monsters on the level, possibly. )

This all sounds like a lot of fun to me, anyone else have any ideas?
Anyone want to write it?  Are you listening: Ken Arnold, et all?

Paul van de Graaf	U.C. San Diego		sdcsvax!sdccs7!ee163aca