-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathText Based Game Protocol.txt
165 lines (116 loc) · 5.41 KB
/
Text Based Game Protocol.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
Text Based Game Protocol v1.0
-----------------------------
The Text Based Game Protocol is an application layer protocol running over
TCP, providing game controling, user controling, and other functions. In
this document, we will specify the structure and function of the protocol.
This document is not quite rigorous. For anything not mentioned here, please
refer to the source code.
1. The Packet Structure of TBGP
The TBGP packet structure is as follows:
|<------ 4Bytes ------>|<-2 Bytes->|<-2 Bytes->|
+----------------------+-----------+-----------+
| 0x5 0x5 0xa 0xa | service | pkt_len |
+----------------------+-----------+-----------+
/ Data* /
+----------------------------------------------+
* Theoretically, the data section can support 65535 bytes at most. But
practically, the data section mostly does not exceed about 1024 bytes.
All numeric fields are stored in network byte order. Aka Most significant
byte first.
0x55aa - The first four bytes are always 0x55aa, to identify the TBGP
packet.
service - An opcode to tell the client/server to take proper action. The
possible service are listed in the service section of this
document.
pkt_len - A two-byte value, in network byte order, stating how many bytes
are in the data section of the packet.
data - The data section is pkt_len bytes long and depends on the service
section to interpret.
2. Services
There are 8 known services at the moment, although more may exist. All
known services are listed below along with the hex values that they
correspond to.
SERVICE_LOGIN = 0x01
SERVICE_LOGOUT = 0x02
SERVICE_NAMELIST = 0x04
SERVICE_CHAT = 0x08
SERVICE_GAMEREQUEST = 0x10
SERVICE_GAMEON = 0x11
SERVICE_GAMEREFUSED = 0x12
SERVICE_GAMEOP = 0x18
SERVICE_FAILED = 0xff
Most of the service codes should be self explanatory. Those that aren't are
listed here:
SERVICE_FAILED - A kind of packet the server use to inform the client that
the client has sent some invalid packet.
3. Game Operation
When game is on the client and server will constantly exchange data and
control messages. The service of the packet is always SERVICE_GAMEOP. And
the details will be transfered in data section. The data section's structure
of gameop is as follows:
|<-2 Bytes->|
+-----------+------...------+------...------+
| OPCODE | User1 status | User2 status |
+-----------+------...------+------...------+
The details of user status will not be discussed in this document.
The opcode is specify the action of the attacker. The possible opcode is as
follows:
GAME_CHR_CREATE = 0x00
GAME_PHYSICAL_ATTACK = 0x01
GAME_MAGICAL_ATTACK = 0x02
GAME_MISS = 0x04
GAME_CRITICAL_HIT = 0x08
GAME_RETREAT = 0x10
GAME_CONCEDE = 0x11
GAME_WIN = 0x80
GAME_LOSE = 0xc0
These options can be combined to interpret various meanings.
4. Requests & Responses
4.1 Login
The first packet sent from the client is log in packet. This consists a
username whose length is 32 bytes at most.
Service: SERVICE_LOGIN
Data: Username(32 Bytes)
When a user is logged in, the server returns a series of usernames, which
represent the online users. The accurate number of names can be calculate
with pkt_len section.
Service: SERVICE_NAMELIST
Data: Username(32 Bytes)...
4.2 Chat
A logged in user can send message to an online user or to all the online
users. The server's behaviour depends on the pkt_len: if there's no specify
username. then the server will forward the message to all the online users.
Otherwise the server will only forward to the user in the data.
Theoretically the server can forward message to a series of users.
Service: SERVICE_CHAT
Data: Chat String(ends with NULL) + Username(32 Bytes)...
4.3 Fight Game
4.3.1 Game Start
When a user would like to start a game with another online user, the client
will send a game request packet to the server, which includes the username
of the rival. The server will forward the request. And the server will
forward the game on packet to tell the user the game request is accepted.
If the other user refused to join in the battle, he must send a refuse
packet back.
Service: SERVICE_GAMEREQUEST
Data: Destination Username(32 Bytes) + Source Username(32 Bytes)
Service: SERVICE_GAMEON
Data: Destination Username(32 Bytes) + Source Username(32 Bytes)
Service: SERVICE_GAMEREFUSE
Data: Destination Username(32 Bytes) + Source Username(32 Bytes)
4.3.2 Ongoing
The client and the server will constantly exchange the game operation packet
unless the game is settled or one quits. For the first round, both of users
should exchange GAME_CHR_CREATE packet to confirm own character.
Service: SERVICE_GAMEOP
Data: [OPCODE] [attacker's status] [defender's status]
Service: SERVICE_GAMEOP
Gameop: GAME_CHR_CREATE
Data: [User Status]
4.4 Invalid Operation
Since the server is working like a state machine, for a certain state if the
receiving packet has no next state the server will send a failure packet to
client to inform the mistake.
Service: SERVICE_FAILURE
Data: none (pkt_len = 0)
** For more details, please refer to the source code. **