Re: Network protocol for Expert QotW #23

Rick Measham <[email protected]> writes:

> #----------------------------------------------------------------------- 
> EXTENSION 2
> Write a split engine/interface tetris game
> #----------------------------------------------------------------------- 
>
> In this version of the quiz the interface should be split from the
> engine. Two interfaces should be able to link to a given engine, one
> for each player.  (Optionally, extra interfaces may connect but only
> to view the game, not play)
>
> The interface should connect to the engine via a network socket.
>
> The command set should be standardised so your interface can plug into
> my engine or vice versa.

So if this is to be so, we really ought to flush out the network
interface a bit first.  Among other things, I see no indication of how
the server tells the player two client what the three pieces are that
it is choosing among.

First off, let me propose this.  Note that this is just a proposal for
discussion; I expect it to be changed:

- all network traffic for this game is done via TCP.  (Though given
the specifics of the problem, I can see a case being made for UDP)

- all commands travel back and forth as \r\n-terminated lines.  For
compatibility with possibly broken implementations, every
implementation SHOULD also accept lines terminated with a single \r or
a single \n, but MUST generate lines ending in \r\n.  As an
implementation detail, everyone should probably arrange things so that
their sockets are flushed after each command/response.

- when the server starts up, it will open two (at least) listening
sockets, one for the first player and one for the second.  Optionally,
it may open up a third socket for spectators to connect to.

- when a client connects to the server, it will be given one of these
lines:

PLAYER1 [Comment]
PLAYER2 [Comment]
SPECTATOR [Comment]

The space before "Comment" is optional if Comment is the empty string.

- At any point, either the server or the client may give a line of the
form:

INFO [keyword] [value]

This line should be matched with something equivalent to:

if ($line =~ /^INFO (\w+) ?(.*)/) {
  $keyword = $1;
  $value = $2 || "";
  # handle INFO line
}

Clients and servers should accept unrecognized keyword values, though
they should either do nothing with them or simply repeat them verbatim
to the user.

At the moment, there are no keywords which must be accepted, though
that may change with discussion - I welcome suggestions.
Specifically, we may decide that some sort

I will define these keywords:

INFO NAME name

Sent client->server, set this client's player name to "name".

INFO PLAYER1 name ipaddress
INFO PLAYER2 name ipaddress

Sent server->client, these tell the clients about each other.  Note
that the server MAY send the "PLAYER1" message to both players.

INFO BOARD ncolumns nrows

Tells the client about the board size of the current game.  Presumably
that will have been set on the command line that started the server or
by some sort of as yet undefined metaserver protocol before
client connection.

INFO LEVEL n

Sent server->client.  "n" is a base 10 number.  Sent to indicate the
start of level n.

INFO SCORE nnn

Sent server->client.  The server thinks that the current score is
"nnn".

Other suggestions?  I though about "INFO COMMENT" that is sent either
way and causes the server to broadcast the message to all clients to
allow spectators to kibitz, but I don't want this turning into a
full-blown IRC server.

Maybe something that would allow the server to state which INFO
messages are supported?

- Any client (including spectators) may send to the server the command

REFRESH

After seeing this, the server should respond with a total board
diff. - that is, respond with a line as though the entire board had
changed.  Note that this may produce very long lines.

The server MAY delay its response until the next time it would send a
board diff. anyway, at which point it MUST send the entire board.  The
server may also ignore this command if it is sent too frequently by a
given client, although it should allow a client to send REFRESH once
every 10 seconds.

- The server will send this to the player2 client to indicate that it
must choose the next piece:

CHOOSE #$&

where the three characters following the space correspond to responses
"ONE", "TWO", or "THREE".  The server may also send this to the
player1 client, though the player1 client is free to ignore it.

- The server will send this to indicate the end of a game:

END
INFO SCORE nnn

Where "nnn" is the final score.  (INFO SCORE is optional, but
recommended)

After this line, the server and clients may send other INFO messages,
but no more game messages.  Server or client may disconnect at any
time after the END line.  As a matter of defensive programming, the
server SHOULD disconnect after some period of inactivity from the
clients, and should also have some maximum time-after-END after which
it disconnects anyway.

We should still define messages that the server can send in case of
some client error.  What happens if a client connection is just lost?
This should probably not be an INFO message unless the server should
be able to recover from having a player disconnect.  (Since INFO
messages may be ignored by clients)  But at this point, I'm out of
free ideas and must go have ideas in exchange for money.  If no one
else has any suggestions by tonight, I'll revist this question.

>
> The client will send the server commands on each keypress:
>
>         LEFT
>         RIGHT
>         DOWN
>         ROTATE
>
> A second client (for player 2) can send:
>
>         ONE
>         TWO
>         THREE
>
> to indicate the selected piece. In the split game (where the two
> players are using different clients) there is no requirement for
> player 1 to see the three options given to player 2 until one becomes
> the 'next block'.
>
> The server will send the client diffs of the game board. The following  
> change would be transmitted as:
>
>         D03 D02 B03#B02#
>
>   4|&&        |  |&&        |
>   3|& ##      |  |&##       |
>   2|& ##      |  |&##       |
>   1+----------+  +----------+
>     ABCDEFGHIJ    ABCDEFGHIJ
>
> The format of the message string is:
>
>         ($col,$row,$piece) =~ /([A-J])(\d\d)([\Q#@%*&+$\E])/
>
> #----------------------------------------------------------------------- 
> REFERENCES
> #----------------------------------------------------------------------- 
>
> Screenshot of original tetris:
>
>         http://www.mobygames.com/images/shots/original/1018986079-00.gif
>
> History of tetris (from Atari's point of view -- there was a court
> battle):
>
>         http://www.atarihq.com/tsr/special/tetrishist.html
>
> Javascript Implementation of the game if you've never played it:
>
>         http://www.js-games.de/eng/games/tetris