home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ee!bloc1469
- From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: IPC and shared memory
- Date: 6 Jan 1993 23:29:21 GMT
- Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
- Lines: 29
- Message-ID: <1ifq0hINNak2@uwm.edu>
- References: <1ib8dmINNesj@uwm.edu> <paulk.33x6@terapin.com>
- NNTP-Posting-Host: 129.89.2.33
-
- In article <paulk.33x6@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
- >I was talking about the specific example of a multiuser BBS game. In
- >that case it's easy enough to guarantee that the semaphore will
- >always exist until the last process accessing it exits.
-
- Interesting. So why not just have a server process which does the
- tracking of stuff, and use either spawned slaves, or use a separate
- binary for a slave and have the server send you a pointer to it? That
- enables you to do LOTS of things by having the "master" know
- everything that's going on, and having the slave be that user's
- interface to the world. One could write slaves that are nothing more
- than "windows to the world" for the users of the bbs. More
- importantly, one could write "AI slaves" as seen in muds, robots if
- you will, or perhaps highly intelligent monsters. It all depends on
- how you're designing the game, but it does sound as if you could
- benefit from having a master process with either subprocesses (perhaps
- your bbs could call an AREXX script which launched a slave or
- something) or as separate slaves (the more complex but more powerful
- solution).
-
- Who knows. :)
-
- Greg
-
- --
- (: (: (: (: Have you overdosed on smileys today? Why NOT!?! :) :) :) :)
- (: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run :)
- (: Thy will be done, At Commodore as it is at Apple" -Dan Barrett :)
- (: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
-