wasaunders@watdragon.UUCP (Parallel Hair???) (03/27/86)
Being fairly new at the unix game I have a question to ask of all you Whee-Zards out there ... actually it is more of a problem than a question, but anyway ... I would like to set up a time-sharing system (a small one). One of the things I would like to do is to include a multi-user game which I have been thinking of writing. The events during the game are to take place in real time, so one possible architecture for the software would be to have one games master, with player processes forked from it. When someone logs into my system they are given a CI (shell, whatever ....) - if they want to play the game how can I associate the player process with their port, and then restore their CI when they are one playing? Thanks in advance to any of you who reply... -- Alec Saunders watmath!watdragon!wasaunders "Parallel hair???? Who needs it!"
wasaunders@watdragon.UUCP (Parallel Hair???) (03/27/86)
>are given a CI (shell, whatever ....) - if they want to play the game how >can I associate the player process with their port, and then restore their >CI when they are one playing? > | | read "done playing" -- Alec Saunders watmath!watdragon!wasaunders "Parallel hair???? Who needs it!"
gwyn@brl-smoke.UUCP (03/30/86)
In article <698@watdragon.UUCP> wasaunders@watdragon.UUCP (Parallel Hair???) writes: >Being fairly new at the unix game I have a question to ask of all you Whee-Zards >out there ... actually it is more of a problem than a question, but anyway ... > >I would like to set up a time-sharing system (a small one). One of the things >I would like to do is to include a multi-user game which I have been thinking >of writing. The events during the game are to take place in real time, so >one possible architecture for the software would be to have one games master, >with player processes forked from it. When someone logs into my system they >are given a CI (shell, whatever ....) - if they want to play the game how >can I associate the player process with their port, and then restore their >CI when they are one playing? Assuming you plan to use UNIX: You can't in general attach a terminal to an already-running process, so your best bet is to have a game master process that reads a FIFO, socket, or (if you don't have FIFOs or sockets) a locked known file to get slave data (part of which for a new slave would be information on how to send data back to the player), and start up a fresh slave player process when a new player enters the game. Games like this have been distributed publicly, for example on USENIX tapes. One that was popular at JHU was called "search". Termination of a fork/execed process from the shell will return to the shell automatically; no magic required there.
levy@ttrdc.UUCP (Daniel R. Levy) (04/03/86)
<Oh oh here it comes. Watch out boy, it'll chew you up! \ Oh oh here it comes. The LINE EATER! [TAH ta-ta]> In article <2204@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: >In article <698@watdragon.UUCP> wasaunders@watdragon.UUCP (Parallel Hair???) writes: >>I would like to set up a time-sharing system (a small one). One of the things >>I would like to do is to include a multi-user game which I have been thinking >>of writing. The events during the game are to take place in real time, so >>one possible architecture for the software would be to have one games master, >>with player processes forked from it. When someone logs into my system they >>are given a CI (shell, whatever ....) - if they want to play the game how >>can I associate the player process with their port, and then restore their >>CI when they are one playing? >Assuming you plan to use UNIX: You can't in general attach a terminal >to an already-running process, so your best bet is to have a game master >process that reads a FIFO, socket, or (if you don't have FIFOs or sockets) >a locked known file to get slave data (part of which for a new slave >would be information on how to send data back to the player), and start >up a fresh slave player process when a new player enters the game. (Also presuming Unix) What about a user invoking a process by command from his/her shell which sends a signal to the master, which then knows to look to see who logged on, and fork a child who can then open() the player's terminal? (Or the master could even do the open() and all the I/O itself, but pretty soon it would run out of file descriptors, not to mention being VERY busy.) The process that the user invoked to notify the master would then sleep indefinitely, allowing the game process to have uninterfered use of the user's terminal, until the game ended for that player, whereupon the game program would kill the sleeping placeholder (or send it a signal to let it voluntarily exit so the user doesn't see "Killed") to let the user get back to the shell. Could that work reasonably? >Games like this have been distributed publicly, for example on USENIX >tapes. One that was popular at JHU was called "search". Is this the same "search" which was posted to net.sources.games a week or so ago? -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/06/86)
In article <820@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >What about a user invoking a process by command from his/her shell which >sends a signal to the master, which then knows to look to see who logged >on, and fork a child who can then open() the player's terminal? Not everybody who logs in is necessarily playing the game; you end up using IPC to indicate the playing terminal in any case. I also am not fond of using signals for IPC; they are unreliable. I see that AT&T proposes to adopt Berkeley-style reliable signals in the future, though. I wonder if they solved the signal-during- fork/exec problem. By the way, Issue 2 of the SVID is very nice; good work, guys. >(Or the master could even do the open() and all the I/O itself, but pretty >soon it would run out of file descriptors, not to mention being VERY busy.) This is a problem you have to solve anyway. The master has to send data to all the screens or their servers somehow. One of the nice things about FIFOs is that one can close them and open them again later (although this is fairly high overhead in this application). >Is this the same "search" which was posted to net.sources.games a week or >so ago? I think so. They don't allow us to read all newsgroups here.