Post
by Bjørn » 03 Feb 2005, 15:50
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.
)
. I will read more closely after sleep, but so far it looks fairly good (since attacks, movement, etc. still need to be documented).
