Table of Contents generated by magnetikonline/markdown-toc-generate
There is a client and he's sending info to a server that he wants to play a game. I'm convinced there is no sense of doing long-term rooms which should be stored in a database for a long time. Initially, let's assume the single game will take 10 minutes on average. Clients will not disconnect from the server during a game. If they do, this will be interpreted as a surrender, the second user will be disconnected and the room will be destroyed. I have an idea of making the named queues. So there is a public queue named 'public' and every player that wants to play with random another player should join it. But if there're players that want only to play with each other, they can join a queue with another (of course the same) name and they will be added to their private queue.
There is the first packet that informs the willing of the user to join a named queue. Let's name it JON (JOiN) packet. And there have to be specified the name of the queue that he wants to join.
When another user joins the same queue, the new room is being made. And therefore there is sent an STT (STaTe/STaTus) packet which informs about a state of the whole board, whose is a turn, did someone win and who won.
Additionally, a client can send a request for an STT packet. Let's name it a GET packet. So when the server gets a GET packet, it responds with an STT packet.
When a client wants to send a move, he sends a SET packet with x and y coordinate of a field that the user wants to set a mark on.
The server can respond with a BAD packet when the move was not compliant (with the rules of the game), an ERR packet when an error on the server occurred (e. g. IndexError and alike) or a DBG packet with some diagnostic info which can be helpful to debug the whole system.
- get the name of the queue that the user wants to join
- send a JON packet with the name of the queue (the default is
public
, all is case sensitive of course) - wait for an STT packet and render the received board when he gets it
- when the board was rendered and the user clicked a field, send a SET packet with coordinates of the field
- when he gets a BAD packet, show info (pop-up or something) with a communication error message (because the client hopes that everything was good and the server thinks in the other way, so there was something with communication between a server and a client)
- when he gets an ERR packet, show info about a server error
- when he gets a DBG packet and the option of "viewing diagnostic info" was checked, show the received message
Let's use JSON.
Let's say that every packet is the same form, for example:
{
"status": 0,
"method": "GET",
"params": {},
"time": 1583857011
}
status
(integer) is the current state of the sender. Currently, it has no sense, so there can be an integer used for debugging purposes.method
(string) is the name of the packet's method. So it's its type, what the sender wants us to inform about. Necessarily it should be three letters, each in upper case.params
(object) is all things related to the given method.time
(integer) is the current local time of sending the packet. Formatted in UNIX timestamp, UTC, for diagnostic purposes.
the request of joining to the queue
room
(string) - the name of the queue that the user wants to join (default:"public"
, but it should be mentioned in the packet)
e. g.
{
"status": 0,
"method": "JON",
"params": {
"room": "public"
},
"time": 1584009226
}
the info about the room and the board
board
(string) - the string with the board, next rows of the board, made of ASCII characters: 'X', 'O', '-'
so the second char ofboard
is a field with x=1 and y=0bigBoard
(string) - the string with the big board (the wins on subboards (3x3 boards)), next rows of the board, made of ASCII characters: 'X', 'O', '-' or '+' when there was a draw
so the second char ofbigBoard
represents the subboard which would be marked with 1 (seemarked
)whoWon
(string) - who won the game (e. g."-"
- no one,"X"
,"O"
or"+"
- there was a draw)you
(string) - your mark (e. g."X"
or"O"
)move
(string) - whose turn is it (e. g."X"
or"O"
)lastMove
(nullable object) - in which field the last mark was placed ornull
if there was no last move (so this will be the first move)x
(integer) - the x coordinate of the fieldy
(integer) - the y coordinate of the field
marked
(integer) - the marked subboard (so that where should be next move done);or -1 if no subboard is marked (so the move can be done anywhere). It's an integer between -1 and 8 inclusive.012 345 678
e. g.
{
"status": 0,
"method": "STT",
"params": {
"board": "XO-XO-----O-X------O-X------O-X---------------------------X----------------------",
"bigBoard": "OX-------",
"whoWon": "-",
"you": "X",
"move": "O",
"lastMove": {
"x": 3,
"y": 2
},
"marked": 6
},
"time": 1585054444
}
The client can get an STT packet anytime, so he can get it right after connecting to the server without sending a JON packet. So it would be nice that the client can interpret and render the board mentioned in the STT packet and show it then.
the request of an STT packet
- no params
There can be no GET packet sent and the client can receive the STT packet. Usually, the server sent an STT packet when only the state of room changes so there is no need to send a GET packet. But if the client wants to get sure that nothing changed, he can send a GET packet.
the request of making a move, placing a mark in the specific field
-
x
(integer) - the x coordinate of the field -
y
(integer) - the y coordinate of the field# x
y012
345
678
0
1
2- - -
- - -
- - -- - -
- - -
- - -- - -
- - -
- - -3
4
5- - -
- - -
- - -- - -
- - -
- - -- - -
- - -
- - -6
7
8- - -
- - -
- - -- - -
- - -
- - -- - -
- - -
- - -
e. g.
{
"status": 0,
"method": "SET",
"params": {
"x": 4,
"y": 4
},
"time": 1584009226
}
the info that the move was incorrect (there was no your turn, in the selected field there is a mark already, the room is won)
msg
(string) - additional info
the info about the server error
msg
(string) - additional info
the additional info that does not affect the game
msg
(string) - additional info
the request of a POG packet
- no params
the reply to a PNG packet
- no params
the info about the unsupported stuff (unrecognized method or alike)
msg
(string) - additional info
the info about the version of the using software
protocolVersion
(string) - the version of the supported protocolname
(string, optional) - the name of the using softwareauthor
(string, optional) - the name of the software authorversion
(string, optional) - the version of the softwarefullName
(string, optional) - the description of the software (name, version, sitepage...)nick
(string, optional) - the nick of the user, used to the identify users; matching regex^[A-Z][A-Z0-9_]{2,29}$
fullNick
(string, optional) - the nick of the user (utf-8 of course)
e. g.
{
"status": 0,
"method": "VER",
"params": {
"protocolVersion": "v1.0",
"name": "tic-tac-toe-9x9-mobile",
"author": "Pikne-Programy",
"version": "v0.0.0.1",
"fullName": "tic-tac-toe-9x9-mobile\nv0.0.0.1\nhttps://github.com/Pikne-Programy/tic-tac-toe-9x9-mobile",
"nick": "NIRCEK_2103",
"fullNick": "Nircek (Marcin Zepp)"
},
"time": 1584009226
}
this is the minimal example:
{
"status": 0,
"method": "VER",
"params": {
"protocolVersion": "v1.0"
},
"time": 1585566364
}