RUA!
- this game use a
15 * 15
board. - two player in a game, use
black
orwhite
chess. white
chess always play first.
- game svr running, two player ready.
- player snd
[msg_reg]
to svr. - svr return
[msg_result]
to player. - if failed, change reg info and back to #2.
- player snd
[msg_request]
to svr. - svr return
[msg_room_list]
to require room list. - player snd
[msg_room_oper]
to create or join a room. - svr return
[msg_result]
to player. if failed, back to #5. - player(we call A later) create the room will be its owner, and use black chess by default.
- A can snd
[msg_chess]
to choose a chess type. - svr return
[msg_chess]
to all player to set chess type. - another player in room(we call B later) snd
[msg_state]
to set or cancelready
state. - svr snd
[msg_state]
to all player with B's state. - when B ready, A can start one match.
- A snd
[msg_request]
to svr for starting game. - svr return
[msg_game]
to all player with a start sign. - from A start, players snd
[msg_move]
to svr, and svr snd[msg_move]
to all player. - when game end after snd a
[msg_move]
, svr snd[msg_game]
with an end info to each player. - after rcv
[msg_game]
, player snd[msg_room_oper]
tostay
orexit
the room. if no onestay
, room would be destroy. if only one playerstay
, he will be new room owner. if all playerstay
, winner will become new room owner. - back to 9.
-
here was 5 states of player,
init
idle
,room
,game
,ERR
- when a player connect svr, this player will went into
init
state. - in any state, when a player lose connection to 'svr', or use too many illegal operations that reach svr's limits, player went into
ERR
state, and svr will end session with player.
- when a player connect svr, this player will went into
-
in
init
state player can only do registry.- player was expected to snd
[msg_reg]
with a unique player name. - svr rcv msg, and check msg type and player name. then return a
[msg_rslt]
with reg result. - if reg succ, player went into
idle
state. if failed, back to #1.
- player was expected to snd
-
in
idle
state player can request [room list], orcreate/join
a room. and maybe can request [room info] in future.- request [room list]
- player snd
[msg_request]
withroom list
code. - svr return
[msg_roomlist]
to player.
- player snd
create
a room- player snd
[msg_roomoper]
withcreate
code and room info(name and maybe psw). - svr try create room, and return
[msg_result]
with result code and msg. - if succ create a room, player went into
room
state, and own the room created.
- player snd
join
a room- player snd
[msg_roomoper]
withjoin
code and room info(name and maybe psw). - svr try put player into room, if succ, return
[msg_roominfo]
to all player in room. - return
[msg_roominfo]
withjoin
sign to A, return[msg_roominfo]
withowner
sign to B. - if failed, return
[msg_rslt]
to player with error code and msg. - if succ join a room, player went
room
state.
- player snd
unreg
- request [room list]
-
in
room
state we call a player A who own the room, and call another player B. player canexit
room in this state;B can change ready state;when B ready, A can change his chess type(black or white), andstart
a game. and maybe akick out
in future. when a playerjoin/exit
the room, another player will rcv[msg_roominfo]
. when A exit room, B become a new A. when all player exit, the room will be destroy.exit
room- player snd
[msg_roomoper]
withexit
code. - svr return
[msg_result]
. if another player exists, svr snd[msg_roominfo]
. - player who exit room went into
idle
state.
- player snd
- 'ready/unready`
- B snd
[msg_state]
with state code(ready/unready). - svr return
[msg_state]
to all player in room.
- B snd
- change chess
- A snd
[msg_chess]
with a chess type. - svr return
[msg_chess]
to each player with this chess type. - exp: A snd
[msg_chess(black)]
, svr return[msg_chess(black)]
to A,[msg_chess(white)]
to B.
- A snd
start
game- A snd
[msg_request]
with game start sign. - svr check status, if fail, return
[msg_rslt]
with error code and msg. if succ, return[msg_game]
with start code. then all player went intogame
state.
- A snd
-
in
game
stateblack
chess go first. players put chess one by one. until a player win, or no more space in board.- player movement
- a player snd
[msg_move]
with coord. - svr check movements, if fail, return
[msg_rslt]
to this player. - if succ, svr return
[msg_result]
with succ sign, return[msg_move]
with chess type and coord to another player.
- a player snd
- game end
- svr rcv a valid movement, and returned msg to player.
- if a player won or no spaces remain in board, game snd
[msg_game]
withwin/lose/draw
sign to player. - all player went into
room
state.
- player movement
first, devide server into 2 parts, I call game svr
and match svr
. as their name, a game svr
handle player
and room
operations, like login in
or join/create room
. and, match svr
handle gomoku matches.
all msg between svr and client contains token
and session
fields.
now svr only contains client registration, no user management.
when a client register to game svr
successfully, svr return a token
to the clients.
if tcp connection closed or timeout without unreg
operation, this associated player will be marked as lost
.
clients can snd a new reg
msg to svr with its token to reconnect to svr.
but, when a client reg
to svr with a token, but this token associate to a 'connecting' user, or no user, svr will also generate a new token for it.
session
was used to identify requests and its response. for exp, client snd a request to get exists roomlist, and svr snd a response back to client. but before the roomlist response snd to client, there may be other same type msg snd to client. so, when client snd a request, mark it with a session id. svr will return response with same session id. then client can locate the msg needed.
token
and session
use u64
data type, and use -1
for invalid value.
game svr
handle player registration
, room operation
, and maybe some statistics in future.
game svr
has almost nothing changed in interaction.
game svr
listen to a fixed tcp port.
operations:
- register
snd
msg_register
rcvmsg_result
- unregister
snd
msg_unregister
(not implemented) rcvmsg_result
- room list
snd
msg_request
rcvmsg_roomlist
- create room
snd
msg_oper
rcvmsg_result
- join room
snd
msg_oper
rcvmsg_result
rcvmsg_room_info
(owner) - leave room
snd
msg_oper
rcvmsg_result
rcvmsg_room_info
(remain player) - change state
snd
msg_state
rcvmsg_result
rcvmsg_room_info
(owner) - change chesstype
snd
msg_chess
rcvmsg_result
rcvmsg_room_info
(guest) - start game
snd
msg_game
rcvmsg_result
so in game svr
, svr rcv following msgs:
msg_register
msg_unregister
msg_request
msg_oper
msg_state
msg_chess
msg_game
and snd following msgs:msg_result
msg_roomlist
msg_room_info
in some situation, some msg does not contains all infomation.
for example, a msg_room_info
do not need room name or psw.
a match
comes from a room in game svr
.
now, match svr doesn't use different process or connection.
to identify a match, use a fixed session id.
when room owner snd a msg_game
to svr. svr generate a match from the room, and generate a session id(match id), and snd msg_game
to players with this session id.
maybe i will really seperate match server and game server in future. but, not now. when i need a distributed svr, maybe i will do that.
client | | connect | register |
idle <-------------- |
---|
cr |
o<- g<- ------------- |
ct |
...
may cause some problems.
all msg would be serialized in json format, and wrap with <>
.
a msg packet would seems like <{'key':'value'}>
.
- catch
C-c
signal to shutdown svr. - connection reuse for game svr.
- statistics of game.
- reconnect?