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
|
Message formats of libtdegames:
-------------------------------
There are two different communication layers, using their own protocols:
- the message layer (KMessageIO, KMessageServer, KMessageClient)
This is used to send messages from one client (i.e. KGame object)
to an other one, to a group of other clients, or to all the clients
connected to the KMessageServer. The messages are arbitrary blocks
of data, of an arbitrary length.
This layer is an underlying protocol that isn't game specific at all.
You shouldn't need to know the message format of the packets. If you
want to extend the protocol, have a look into KMessageServer API
reference for a complete list of message types.
- the game layer (KGame, KGameIO, KPlayer)
This layer uses the message layer to send its specific message packets
between the objects of the game.
This layer contains the game specific messages (e.g. addPlayer, setupGame).
The rest of this file describes this layer.
Game Layer Messages:
--------------------
Application Cookie 16 Bit
Version 8 Bit
MsgId 16 Bit
SenderId 16 Bit
ReceiverId 16 Bit
Userdata
The format of the messages is used internally and there is usually no reason why
you have to know what it is used for. But as usually != always here are some
comments on the format. Note that KGame is under development and the content of
this file could be obsolete. Please result the sourcecode for up-to-date
information.
Application Cookie is used to identify the application. This prevents a
chess game from talking to a poker game.
Version is the version of KNetworkGame, sender and receiver must be of the same
version.
library note: this could be a limitation, as KGame should be backward
compatible. Maybe change to version must be >= KNETWORKGAME or something less
restrictive
MsgId specifies the kind of the message data (see below).
SenderId is the id of the KGame/KPlayer object which sent the message, it is
coded like this: the lower 10 bits specify a player and the upper bit
represent the game id shifted by 10 bits. So we get
Id=playerId | (gameId<<10);
ReceiverId is the id of the receiver of the message. It can be either
a player, a game or a broadcast. For a broadcast the Id is set to 0
in the other cases the coding is as with the senderId
Userdata is the data of the user (wow ;-))
MsgId UserData
---------------------------------------------------------
IdMessage user defined
IdSetupGame Q_INT32 isServer
Q_INT32 maxPlayers
Q_INT32 newid (id for the new game)
Q_INT32 cntR (virtual player nunmber)
Q_INT32 cntT (tagged player number)
TODO: Changed
IdContinueSetup: TODO
IdSendPlayer Q_INT32 omit how many tagged players for replacement
TODO: Changed
IdGameSave Save(msg)->Load(msg)
IdAddPlayer rtti
gameid() of the owner
player->Save(msg) -> player->Load(msg)
IdRemovePlayer Q_INT16 playerid
IdError Q_INT32 errorcode
TQString errortext
IdGameStatus Q_INT32 status
IdPlayerProperty Q_INT16 propertyId
user defined -> the property
IdGameProperty Q_INT16 propertyId
user defined -> the property
IdPlayerInput user defined
|
