NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/amiga/datacomm/5801

Internet Message Format | 1992-08-19 | 4.4 KB

Path: sparky!uunet!portal!lll-winken!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!ami-cg!cg
From: [e-mail] (Chris Gray)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: multiuser environment (via modem)
Message-ID: <[e-mail]>
Date: 20 Aug 92 03:22:46 GMT
References: <[e-mail]>
Organization: Not an Organization
Lines: 75

In article <[e-mail]> [e-mail]
(Chris Klaus) writes:

>Hello. I am looking for source code or information pertaining to a multi-
>player or user environment inwhich there is a graphical representation.
>
>    I'd like to see something like a MUD but based on ASCII characters
>moving around on the client.  I'd like to see how the src code deals with
>handling each person's input and updating the information on each person's
>client.

I can't send you sources, but I can provide some information. What I do in
AmigaMUD is have a single server process and multiple client processes,
which communicate over Amiga Exec message ports. The server is responsible
for maintaining a consistent idea of what the world looks like, where
players are, etc. The clients are responsible for details of how to talk
to the player. It is the clients that would, in your case, know what kind
of control sequences to use to get the player's terminal or computer to do
the right things on the screen.

Exec message ports allow any number of messages to be queued up on them, and
it is easy to pull them off one at a time. Normally, each such message
contains a 'return address' message port, to which the server should send
any reply to this message.

So, let's imagine that you have 5 players in your game, all of them visible
in the same area of the world (so they all show up on all player's screens).
Two of the players try to move into the same place at roughly the same time.
Their client programs send a message to the server requesting the move.
Because the Amiga locks such accesses to messages, one of the requests will
'win' and get to the server before the other one. That one is allowed to
do the move, and the server will tell all clients to update their screens
to show that move. The server then processes the next request, and will
have to tell that player (and perhaps the others too) that the move failed.
If the system is fast enough (shouldn't be a problem with a reasonable
game programmed in a compiled language), then the failing player won't see
any significant pause (unless he's connecting at 300 baud!) between his
screen showing the first player moving in, and his message saying he can't
move in.

The messages themselves should be fairly simple, e.g. a byte telling what
kind of action is requested or what kind of thing to do on the player's
machine, followed by a binary form of the needed parameters. Inside the
host machine, messages will be completely reliable, but that will not be
the case over modems, so you would want the client programs to keep a record
of what their player's screen should look like, so the player can request
a redraw if the screen gets garbled. The server shouldn't be involved at all
in such an operation.

In a bit more detail (I don't know how much of this kind of thing you've
done, so I'm being verbose!), the situation described might go like this:

    - player 1 hits the 7 key on his keypad to move up-left.
    - his terminal transmits the appropriate escape sequence for that hit
    - sequence arrives on the host machine in the client for that player
    - client program decodes the escape sequence into the command to move
    up-left, and sends a couple of bytes saying that in a message to
    the server process.
    - player 2 does something similar, with similar results (the escape
    sequence may be different if the terminal/computer differs)
    - player 2's request is sent to the server
    - server is woken up from it's Wait call by the arriving message, gets
    the message and processes it.
    - server updates it's view of what the world looks like, and sends out
    messages to each client program, requesting that they send sequences
    to their remote terminals/computers to update the display to show
    the move.
    - server processes next request on its message port, that from player 2
    - server sends failure message to player 2's client program, which then
    flashes a message on that player's screen

Whew! I AM verbose. Lemme know if you want MORE!

--
Chris Gray   ualberta!ami-cg!cg   or   [e-mail]