summaryrefslogtreecommitdiffstats
path: root/libtdegames/kgame/messages.txt
blob: 5a313f722a42b57cad6143cfef8a19fa2ee201f6 (plain)
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