home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / amiga / datacomm / 5831 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.1 KB
  1. Path: sparky!uunet!decwrl!csus.edu!netcom.com!netcomsv!terapin!paulk
  2. From: paulk@terapin.com (Paul Kienitz)
  3. Newsgroups: comp.sys.amiga.datacomm
  4. Subject: Re: multiuser environment (via modem)
  5. References: <cg.0cu9@ami-cg.UUCP>
  6. Message-ID: <paulk.186k@terapin.com>
  7. Date: 21 Aug 92 17:17:48 PST
  8. Organization: BBS
  9. Lines: 30
  10.  
  11. > I can't send you sources, but I can provide some information. What
  12. > I do in AmigaMUD is have a single server process and multiple
  13. > client processes, which communicate over Amiga Exec message ports.
  14.  
  15. I once did some hacking on a multiuser mainframe game, and this sort
  16. of thing CAN be managed with no central server.  The game I worked on
  17. did everything by cooperation between the users' separate processes,
  18. by means of a division-of-labor which specified when a process could
  19. make up its own mind about when something happens successfully, and
  20. when it would have to take some other process's word for something
  21. having happened.  For example, in this game, when you shoot at
  22. someone else's spaceship your own process decides whether it was a
  23. hit or not, and the other guy's process just gets the news "You've
  24. been hit (x) hard."  By being careful about who has responsibility
  25. for what, you can eliminate the need for a server.
  26.  
  27. The core of this game was a big chunk of shared data accessable to
  28. all the processes, protected by a semaphore, so all the processes
  29. were tightly coupled through a shared picture of the world.  That
  30. would be difficult to manage through a modem.  I don't know how
  31. difficult it would have been to do that game with messages, since the
  32. machine in question didn't have decent messaging anyways.
  33.  
  34. The division-of-labor principle would apply more strongly when messages are
  35. used, I think.  It would be, like, whoever decides first that he can move into
  36. a given square would send out messages telling everybody else they can't. 
  37. Except in that particular case you'd need some kind of way to lock out
  38. overlapping moves.  One player on a slow data link would slow EVERYONE down if
  39. he had to acknowledge every attempt to get such a lock, which might be required
  40. if the thing was really decentralized.
  41.