🚀 go-pugleaf

In article <1992Apr8.164336.2791@clark.edu> aaron@clark.edu (Aaron Auseth) writes:
>I'm attempting to make a multiplayer dungeon game like nethack, except it is
>real-time, and it is running on a PC network (NOVELL).  I have a good portion
>of the standalone dungeon part done, but I'm to the part of passing some
>data to the other players PC's....

What sort of development tools (C compiler, function libraries, etc.)
are you using to develop this game?

In article <1992Apr9.151128.1804@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes:
>
>In article <1992Apr8.164336.2791@clark.edu> aaron@clark.edu (Aaron Auseth) writes:
>>I'm attempting to make a multiplayer dungeon game like nethack, except it is
>>real-time, and it is running on a PC network (NOVELL).  I have a good portion
>>of the standalone dungeon part done, but I'm to the part of passing some
>>data to the other players PC's....
B
>
>What sort of development tools (C compiler, function libraries, etc.)
>are you using to develop this game?

I'm using TURBO C++ and NWAPI's for IPX messaging (haven't figured out SPX).
I've written some VIDEO stuff in asembly for speed.  The game is text based
using generated font symbols and a scrolling map.  

My problem is keeping track of all the data on several machines without
significantly slowing down the environment.  I've decided to use different
sockets for each level of the game so that if Player1 and Player2 are on
different levels they don't have to sift through the IPX packets.  I currently
have a 100 X 100 map and up to 50 monsters and unlimited items.  My first 
(and only) attempt was to have each PC keep it's own copy of the map and data.
The first PC to enter the game would move the monsters and send the new
positions to the other PC's.  I only allowed 20 monsters to move per cycle
which cut down on the IPX packets, yet processing only 20 packets, updating
the monsters, and redrawing the screen took longer than expected.  I have since
rewritten my display routines to make them faster.  I still haven't addressed
changing levels (with multiple players).

Here is a sample scenario:  Player1 is on level 5 when Player2 comes down the
stairs.  How does Player2 get the data for the level?

1)  Player1 can send the data through *several* IPX packets.  Player2 would
    pause until he received enough data to start displaying the map and
    monsters.  (I don't want to slow Player1 down since he is actively playing
    the game, but Player2 can wait several seconds to change levels).
    
    Since I have to send the map/monster data in small blocks to Player2, how
    do I make sure that when Player2 finishes receiving all the data he has
    the latest uptodate data?  Monsters will have moved since the data was
    first sent from when the last of the data was sent.

2)  Have a dedicated PC that will move the monsters and items.  Store the
    maps on disk.  Player2 would load the map and pause until it received
    all of the monster and item locations, then continue.  Player1 would
    have nothing to do with Player2 (they would see eachother still).

    The problem here is I can only scrape up an old 8088 machine and if
    40 people were playing on 40 different levels, I can't expect an 8088
    to keep track of (50 x 40) 200 monsters as well as keep 40 map levels
    in memory.  The 8088 wouldn't beable to move the monsters fast enough
    to make the game interesting.

Option #1 is my personal choice, but I'm not sure how to send the data 
properly.  Option #2 I think is too slow, it would be better to have each
of the 40 players moving their own monsters.

I'm hoping someone will give me some good ideas on how to accomplish the 
"option #1" data transfer to another player.  I haven't seen anything like
what I'm doing except for a UNIX game that had non-scrolling screens.

The situation you describe sounds almost exactly like the one I had to deal
with when writing Galactic Trader, a multi-player VAX/VMS game.  

In Galactic Trader one has a lot of planets (equivalent to your levels), each
of which can contain multiple players as well as a set of non-player ships
(equivalent to your monsters).  In the current incantation of Galactic Trader,
all communication except startup is through message passing between players (analagous to your distributed network) - there is no priviledged server process (as most Unix style multi-user games would have). 

What you are actually building is a distributed system and you will need
appropriate protocols for handling the addition of a player, deletion of a
player, etc...

In Galactic Trader trader, a scheme I've found to work well is implement 
each planet (read level) as a ring.  Updates occur at periodic intervals
(eg every 1 second) and are initiated by the ring master (the players are
kept in a sorted list the first in the list is the master).  An update consists
of moving those ships (read monsters) who are controlled by yourself and then
passing the data to the next player in the ring.  This player fetches the
updated data, does his update on the data (ie updates those ships responding to
himself) and passes the data on to the next player.  This continues until
all players have received the update.  I found this ring based
approach to keep contention down to a mininum.  The ring master establishes
a lock on the ring at the start of the update and releases the lock when the
update has circulated all the way around the ring.  A new ship jumping into
a planet (read player entering a level) has to acquire a lock on the ring
in order to be in the ring (ie this can only be done while an update is not
in progress).  I handle the locking through a distributed locking protocol
which involves a player wanting a lock broadcasting a lock request, and then
waiting for all other players to respond with either "locked" or "unlocked".  
If all players respond "unlocked", the player can grab the lock, otherwise 
the player broadcasts an "unlock public" and waits a random interval before
trying to acquire the lock again (each player maintains 2 lock bits associated
with each planet - a private and public bit that indicate whether or not the
planet is locked by the player and whether or not there is a pending lock
request for that resource).  Leaving the ring turns out to be easy - a player
waits for the update to come around to him and then removes himself from the
ships array and then passes the data on to the next player.

The only tricky cases revolve around handling errors - if a ring master 
crashes out of the game for intance, recovery protocols have to ensure that a new ring master is chosen to restart the ring (error recovery is handled through watchdog timers which fire if a certain time period passes without an update).

I hope this gives you some idea at least of some of the issues involved in
designing this type of fully distributed game - there are other issues revolving
around the addition of new players to the game, startup of the game, etc...
Some form of distributed locking protocol is required for all but the simplest of distributed applications - I would suggest you start by writing some simple
routines to lock and unlock resources, pass data around, etc...  I wrote a
set of low level routines to perform functions such as a ADD_PLAYER,
DELETE_PLAYER, ENTER_RING, EXIT_RING, LOCK_RESOURCE, UNLOCK_RESOURCE, etc...
which I then call from the actual game code...

Good luck - writing such a game is quite a challenge but very rewarding when
you get to see it all in action...

Stephan Meier
Internet: meier@ad.enet.dec.com
Bitnet:  jydy@crnlvax5.bitnet