summaryrefslogtreecommitdiffstats
path: root/libtdegames/kgame/messages.txt
diff options
context:
space:
mode:
Diffstat (limited to 'libtdegames/kgame/messages.txt')
-rw-r--r--libtdegames/kgame/messages.txt93
1 files changed, 93 insertions, 0 deletions
diff --git a/libtdegames/kgame/messages.txt b/libtdegames/kgame/messages.txt
new file mode 100644
index 00000000..c42d2d91
--- /dev/null
+++ b/libtdegames/kgame/messages.txt
@@ -0,0 +1,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
+ QString errortext
+
+IdGametqStatus Q_INT32 status
+
+IdPlayerProperty Q_INT16 propertyId
+ user defined -> the property
+
+IdGameProperty Q_INT16 propertyId
+ user defined -> the property
+
+IdPlayerInput user defined