🚀 go-pugleaf

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