Please fix the networking.
I love the skills system.
I like the world and the environment.
I love the friendliness of the other players.
But the absolutely awful networking is a game breaker.
I am looking for a game to play with my wife, and I am happy to pay to play - I paid WoW subscriptions for years - but no way am i going to pay, or even play, a game that gives me "Please Wait" dialogues every 10 minutes or so and "FS lost" at least twice a week. And FS lost means that I can't play anymore. I have to quit the game and then, because there's no connection when I log off, the login server refuses to let me log in again because it thinks I already am, and refuses, absolutely refuses, to change its mind.
Loads and loads of other games can get it right, why can't Ryzom?
Support pointed me at a post that basically blamed it on ISPs using bandwidth shaping. Well my ISP swears blind, and are subject to huge fines if caught lying, that they do no bandwidth shaping of any sort at all on anyone.
Since Ryzom is open source I thought I would look at the source code and see if I could spot anything obvious that might help, but I stopped when the documentation stated that TCP development was underway and UDP was planned for the future, when I have been told, and can tell, that the game uses UDP, and if the networking were still under development, no-one could play.
Here are some suggestions, from a software engineer with 17 years experience including a lot of network software experience:
1) When you try and log in, the login server should tell the game to log off anyone already logged in and should then allow the login. This means that people who get disconnected can reconnect rather than getting locked out until the login server reboots/crashes/decides to change its mind.
2) Use TCP. For the love of software, why would anyone write a protocol that runs across the internet and uses UDP. You aren't even numbering the damn packets, are you? That's why you get rubberbanding. Packets 1 and 3 get through, so you run forward nicely, and then packet 2 arrives a bit late, saying that you're actually 5 yards back, so then your position gets reset. Not necessarily the reason or even the only reason, but very likely. With TCP, if the connection gets laggy then you hang a bit, but after a few seconds all the packets arrive all at once (in effect) and you get a brief bit of fast forward and then all is well.
3) Don't give up unless you really really cannot reconnect, and in that case log the character out! The "FS lost" message in the network window is a sure sign that the game client is likely to hang if you aren't careful, and it never ever recovers, so why not simply log the character out and put them back to the character selection screen, and if you can't retrieve a list of clients then push them back to the login screen. Don't simply hang. And retry the connection at least 3 times, with a reasonably short timeout on each try, say 2 seconds.
4) Inform the user. In game ping is 200, actual ping is 30. What on earth does "FS lost" mean anyway? Why must I "Please Wait". None of these messages means anything.
5) Do NOT buffer data. According to the, probably incorrect and certainly out of date, documentation on the networking, data is buffered at both client and server, and sends are suppressed until a certain time has passed or a certain amount of data is available to send. This is meant to be a realtime game! i'd even consider disabling Nagle's algorithm on TCP connections! And Nagle's algorithm is more sophisticated than what is suggested by the doucmentation.
6) Sort out the design of having a separate login server. It shouldn't be hard to come up with a good design.
I appreciate that running a server with hundreds of clients can be tricky on the bandwidth and other such things, but even a relatively simple, straightforward, server would perform better than this and form the basis for additional tuning and tweaks as issues were found. Reading the documentation it sounds like someone came up with an unnecessarily complicated design with unnecessary "sophistication" that just wrecks the game for me, and probably for a lot of others too. Keep it simple. TCP, asynchronous (non-blocking) sockets, possibly use one thread to transfer data between read/write buffers and sockets and other thread(s) to process the data out of the buffers (I always used one thread to do the whole lot, but with multi-core processors these days, multi-threading makes a lot more sense).
I'm a busy man with a busy family life, but I am happy to offer what assistance and advice I can. Somewhere I even have a little C++ code that handles writing C++ message objects to a socket, written low level (direct Berkeley sockets APIs rather than C++ sockets classes) so it's easy to get direct and detailed control if you later need to tune the performance. I wrote it for a P2P framework I was working on a while back. I'd be happy to share it.
This game has a lot of potential, but a real time online game HAS to have perfect networking and not glitch all the time under normal operating conditions.
I love the skills system.
I like the world and the environment.
I love the friendliness of the other players.
But the absolutely awful networking is a game breaker.
I am looking for a game to play with my wife, and I am happy to pay to play - I paid WoW subscriptions for years - but no way am i going to pay, or even play, a game that gives me "Please Wait" dialogues every 10 minutes or so and "FS lost" at least twice a week. And FS lost means that I can't play anymore. I have to quit the game and then, because there's no connection when I log off, the login server refuses to let me log in again because it thinks I already am, and refuses, absolutely refuses, to change its mind.
Loads and loads of other games can get it right, why can't Ryzom?
Support pointed me at a post that basically blamed it on ISPs using bandwidth shaping. Well my ISP swears blind, and are subject to huge fines if caught lying, that they do no bandwidth shaping of any sort at all on anyone.
Since Ryzom is open source I thought I would look at the source code and see if I could spot anything obvious that might help, but I stopped when the documentation stated that TCP development was underway and UDP was planned for the future, when I have been told, and can tell, that the game uses UDP, and if the networking were still under development, no-one could play.
Here are some suggestions, from a software engineer with 17 years experience including a lot of network software experience:
1) When you try and log in, the login server should tell the game to log off anyone already logged in and should then allow the login. This means that people who get disconnected can reconnect rather than getting locked out until the login server reboots/crashes/decides to change its mind.
2) Use TCP. For the love of software, why would anyone write a protocol that runs across the internet and uses UDP. You aren't even numbering the damn packets, are you? That's why you get rubberbanding. Packets 1 and 3 get through, so you run forward nicely, and then packet 2 arrives a bit late, saying that you're actually 5 yards back, so then your position gets reset. Not necessarily the reason or even the only reason, but very likely. With TCP, if the connection gets laggy then you hang a bit, but after a few seconds all the packets arrive all at once (in effect) and you get a brief bit of fast forward and then all is well.
3) Don't give up unless you really really cannot reconnect, and in that case log the character out! The "FS lost" message in the network window is a sure sign that the game client is likely to hang if you aren't careful, and it never ever recovers, so why not simply log the character out and put them back to the character selection screen, and if you can't retrieve a list of clients then push them back to the login screen. Don't simply hang. And retry the connection at least 3 times, with a reasonably short timeout on each try, say 2 seconds.
4) Inform the user. In game ping is 200, actual ping is 30. What on earth does "FS lost" mean anyway? Why must I "Please Wait". None of these messages means anything.
5) Do NOT buffer data. According to the, probably incorrect and certainly out of date, documentation on the networking, data is buffered at both client and server, and sends are suppressed until a certain time has passed or a certain amount of data is available to send. This is meant to be a realtime game! i'd even consider disabling Nagle's algorithm on TCP connections! And Nagle's algorithm is more sophisticated than what is suggested by the doucmentation.
6) Sort out the design of having a separate login server. It shouldn't be hard to come up with a good design.
I appreciate that running a server with hundreds of clients can be tricky on the bandwidth and other such things, but even a relatively simple, straightforward, server would perform better than this and form the basis for additional tuning and tweaks as issues were found. Reading the documentation it sounds like someone came up with an unnecessarily complicated design with unnecessary "sophistication" that just wrecks the game for me, and probably for a lot of others too. Keep it simple. TCP, asynchronous (non-blocking) sockets, possibly use one thread to transfer data between read/write buffers and sockets and other thread(s) to process the data out of the buffers (I always used one thread to do the whole lot, but with multi-core processors these days, multi-threading makes a lot more sense).
I'm a busy man with a busy family life, but I am happy to offer what assistance and advice I can. Somewhere I even have a little C++ code that handles writing C++ message objects to a socket, written low level (direct Berkeley sockets APIs rather than C++ sockets classes) so it's easy to get direct and detailed control if you later need to tune the performance. I wrote it for a P2P framework I was working on a while back. I'd be happy to share it.
This game has a lot of potential, but a real time online game HAS to have perfect networking and not glitch all the time under normal operating conditions.