(Explanation about the first two characters) |
(Added client state diagram for illustration) |
||
Line 9: | Line 9: | ||
== Login sequence == | == Login sequence == | ||
The client starts with connecting to the account server. This server allows the client to register or login, to manage the characters in an account and to select a character to play. | The client starts with connecting to the account server. This server allows the client to register or login, to manage the characters in an account and to select a character to play. The client goes through a number of states during this sequence, which are detailed in the diagram below. Once either the <code>GAME</code> or <code>EXIT</code> state is reached, the role of the account server has ended. | ||
[[Image:Client state diagram.png|600px]] | |||
<pre> | <pre> |
Revision as of 16:43, 20 August 2006
Here be documented our own communication protocol. For the latest list of all messages and their contents, see defines.h.
Server structure
When we talk about the server, we mean the combination of several services that will run in parallel. The account server (A) handles player accounts and their characters. The game server (G) handles the maps, beings and items. Finally the chat server (C) handles chat channels. In order to eventually balance the load on processing and bandwidth, and also to be prepared for hardware failures, we envision the possibility to run multiple of the same server.
The first two characters in the name of each message tell us from where to where the message is sent. The player's client is identified by a P.
Login sequence
The client starts with connecting to the account server. This server allows the client to register or login, to manage the characters in an account and to select a character to play. The client goes through a number of states during this sequence, which are detailed in the diagram below. Once either the GAME
or EXIT
state is reached, the role of the account server has ended.
1a. PAMSG_REGISTER { L version, "username", "password", "email" } APMSG_REGISTER_RESPONSE { 0 } 1b. PAMSG_LOGIN { L version, "username", "password" } APMSG_LOGIN_RESPONSE { 0 } (for each char) APMSG_CHAR_INFO { B slot, S name, B gender, B hair style, B hair color, B level, W money, W*6 stats } 2a. PAMSG_UNREGISTER { } APMSG_UNREGISTER_RESPONSE { 0 } 2b. PAMSG_LOGOUT { } APMSG_LOGOUT_RESPONSE { 0 } ... 2c. PAMSG_CHAR_SELECT { index } APMSG_CHAR_SELECT_RESPONSE { 0, token, "gameserver", W port, "chatserver", W port } PGMSG_CONNECT { token } GPMSG_CONNECT_RESPONSE { 0 } PCMSG_CONNECT { token } CPMSG_CONNECT_RESPONSE { 0 }
Movement and combat
Protocol in development, see article about the being movement system.
Switching maps
While walking around the player will come upon locations that bring him to other maps. It is possible that the new map is hosted on another game server. Since the game servers are not connected to each other, they will ask the account server for the details of the other server and for a magic token. This information will then be sent to the client along with the map change message.
1a. (if the map is not on the same map server) GAMSG_PLAYER_MAP_CHANGE { newmap } AGMSG_PLAYER_MAP_CHANGE_REPONSE { 0, token, "gameserver", W port } GPMSG_PLAYER_MAP_CHANGE { "mapname", x, y, B new server [, token, "gameserver", W port] } (if the map is not on the same map server) PGMSG_CONNECT { token } GPMSG_CONNECT_RESPONSE { 0 }
Chatting
1a. PCMSG_CHAT { "message", channel } 1b. PCMSG_ANNOUNCE { "annoucement" } 1c. PCMSG_PRIVMSG { "username", "message" } 2a. CPMSG_ERROR { error } 2b. CPMSG_ANNOUNCEMENT { "annoucement" } 2c. CPMSG_PRIVMSG { "username", "message" } 2d. CPMSG_PUBMSG { channel, "username", "message" }
Notes
Maybe it would be nicer to have the annoucements simply occur on a special dedicated channel. This would make implementation easier. Also, I think it's fine to also send a username for these messages. --Bjørn 12:44, 26 July 2006 (CEST)