New TMW Server

[nym]

Hey everybody, i back! (Yes, that means i can be assigned tasks now HammerBear )

I was just looking at the job tracker, and it seems like a few of the jobs would require some extra coding for Athena (or would be a pain to implement). Things like magic attacks, ranged normal attacks etc.. While it would be possible, it seems like alot of trouble when we are intending to write a new server for The Mana World. I suggest that we maybe increase the priority of a new server which will be custimized for The Mana World. We should also work on a design document about the protocol and different aspects of the server, allowing easier transitioning from Athena to it.

Any suggestions? It would probably be harer converting to a new server later on due to the fact many features which are to be implemented are done via Athena.

[Bjørn]

Yeah we can increase the priority of our own server. There are at least these two things to be taken into account:

- To spread both bandwidth and CPU usage, we want to allow multiple servers to serve the same world simultaneously, to different groups of players.
- The protocol should consist of small packages, sent at low frequency. This could be helped a lot by using a different kind of player control than currently in place.

I've been thinking about server and client side scripting but it's probably best to keep the scripting server side and make the protocol flexible enough for our needs. Ultimately I'd like an object oriented approach where messages are passed from server side object to client side object and the other way around, but this could yield too much overhead.

So then the protocol will probably be like the currently used RO one, in that it consists of a list of messages together with specifications about when they can be expected or when they should be sent. A small start would be:

Client to server:

MSG_LOGIN { username, password }
MSG_WALK { x, y }
MSG_ATTACK { charId }
MSG_USE_ITEM { itemId }
MSG_USE_OBJECT { objectId }
...

Server to client:

MSG_MAP { mapName / mapId }
MSG_OBJECT_INFO { objectId, x, y, type }
MSG_CHAR_INFO { charId, x, y, health, maxHealth, ... }
MSG_PATH { charId, path } // Could be string encoded like "U2RD3L"
MSG_CHARGE { charId1, charId2, damage }
...

Specifying these messages can't be done without making assumptions about the implementation. In the above I was already assuming the client will only control one character. However in the case of pets that can be given commands the MSG_WALK and MSG_ATTACK will also need to pass the charId of the one that walks or attacks to the server.

I've probably made some errors in the messages above. To be more sure it'll work in practice we also need to write use-cases where client and server interact.

I think the implementation both on client and server side is best done using callbacks that are registered to handle certain message types. And then we should probably use SDL_net to abstract away from the OS-specific socket layer to write portable network code the easy way.

[Bjørn]

I've added a more elaborate document about this to CVS. It should become available in ViewCVS within a few hours, developers can check it out through SSH already.

Link to ViewCVS: tmw/docs/server.txt

[nym]

Looks like a good start . I will read more closely after sleep, but so far it looks fairly good (since attacks, movement, etc. still need to be documented).

[Bjørn]

Keep in mind that link above is to version 1.1. We're at 1.5 now, with minor changes made.

[maci]

yeah the server thingy has a lot of informations i read it this morning and agreed to almost everything there...
i guess there was on thing i didnt but i forgot it lol
maybe i will read it again