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.

0a. APMSG_NEWS { "line1\nline2\n..." }
0b. APMSG_RESOURCES { "http://download.themanaworld.org/", B number, S*number filename }

0b. PAMSG_RESOURCES_REQUEST

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_CREATE { "name", B hair style, B hair color, B gender, W*6 stats }
    APMSG_CHAR_CREATE_RESPONSE { 0 }

    (if character created)
    APMSG_CHAR_INFO { B slot, S name, B gender, B hair style, B hair color,
                      B level, W money, W*6 stats }

2d. PAMSG_CHAR_DELETE { B index }
    APMSG_CHAR_DELETE_RESPONSE { 0 }

2e. PAMSG_CHAR_SELECT { B index }
    APMSG_CHAR_SELECT_RESPONSE { 0, S(32) token, "gameserver", W port, "chatserver", W port }
    PGMSG_CONNECT { S(32) token }
    GPMSG_CONNECT_RESPONSE { 0 }
    PCMSG_CONNECT { S(32) token }
    CPMSG_CONNECT_RESPONSE { 0 }

Notes

The usefulness of unregister is disputed. Also, if we actually want to allow people to delete their own account, then they should be required to re-enter their password to do so. --Bjørn 23:39, 20 August 2006 (CEST)

The news and resources sending is currently only a proposal. Do we agree with having the server send this data instead of the client getting it from an external source? And should the client request it or should the server send it to any connecting client? --Bjørn 23:39, 20 August 2006 (CEST)

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)