Jump to content
  • 0

[Learn] Server side


Sbonkers

Question

Hello everybody!

I am an operating systems programmer with some experience in writing low-level material and handling simultaneous/parallel computations in C, C ++ and Rust, but I have never written any network software that could be worthy of this name, nor something related to the world of video games.

I would like, as a hobby, to learn about this world in order to implement a brand new server written completely in Rust.

I would like to have your advises and, moreover, to know where to move the first steps to understand how a Metin2 server works, what are the main design errors that you think have been made and what you would expect from a server designed for modern needs.

Thanks!

Link to comment

7 answers to this question

Recommended Posts

  • 0
  • VIP
On 5/6/2021 at 11:37 AM, Sbonkers said:

to know where to move the first steps to understand how a Metin2 server works, what are the main design errors that you think have been made and what you would expect from a server designed for modern needs

Huhh thats a little bit too much to ask. Back in its time the solutions they made for various problems were acceptable due to the hardware limits, but nowadays the whole server is utterly trash. The question is more like what is okay for modern needs.

But to be a little more specific, here is some of the most annoying problems:

  • No serverside checks for some critical game mechanics. There are numerous stuff that depends on the client, and therefore can be easily faked. For example when you attack, the client calculates the positions your attack would hit, and there is only a distance check on serverside if you really hit that entity. There is no other kind of checks, like combo, direction, or more fine tuned stuff. Nowadays it should be completely independent from the client, the server should determine every attack/movement, and the client should just receive the results.
  • No standard packet protocol. The game uses some homemade messy hardcoded tcp network code, where the headers/packets can be messed up easily. Something like google protobuf should solve this problem. Also due to the use of tcp there are noticable delays in movement/attacks so that should be replaced with reliable udp aswell.
  • The cores are single threaded (except the mysql working threads) and to spread the load across the cpu multiple cores are being used (so it means that best case you have one map / cpu core (which obviously very rare in production servers)). But on farmmaps especially on server openings there are large amount of players and sometimes it noticeably draws performance, and literally nothing you can do about it, since you cannot make it use more cpu threads. Because of this higher cpu clock speed is usually prefered over more cpu threads when selecting hardwares for metin servers.
  • Love 1
  • Good 1

The one and only UI programming guideline

Link to comment
  • 0

Thank you very much @masodikbela

So, basically, you're telling me that a MMO server should handle autonomously all the game mechanics using UDP, while TCP should be reserved only for things like item shop and chat system? Concerning multithreaded code, this isn't an issue at all, given my own experience and Rust compile time safety checks. Lastly, I've read something about protobuf, and as far as I can tell, this kind of things is already implemented in a few well known crates for rust, so neither this one should be an issue.

Now, let's tackle the main problem, Metin2 server knowledge. Do you have any suggestions on where should i go/what should I do in order to gain some expertise on it?

Once again, thank you!
🥰

Link to comment
  • 0
  • VIP
On 5/14/2021 at 12:29 PM, Sbonkers said:

So, basically, you're telling me that a MMO server should handle autonomously all the game mechanics using UDP, while TCP should be reserved only for things like item shop and chat system? Concerning multithreaded code, this isn't an issue at all, given my own experience and Rust compile time safety checks. Lastly, I've read something about protobuf, and as far as I can tell, this kind of things is already implemented in a few well known crates for rust, so neither this one should be an issue.

Well as far as I know its not really a good practice to use UDP and TCP together (its better to use only one) except if it really make sense. In our case the main connection would be the UDP one, so we should somehow find and bind the TCP connection to the same stuff in order to keep a track to our main character, which is necessary for example handling normal chat packet (need position to only send that to the nearby players).

On 5/14/2021 at 12:29 PM, Sbonkers said:

Now, let's tackle the main problem, Metin2 server knowledge. Do you have any suggestions on where should i go/what should I do in order to gain some expertise on it?

Well its always hard to start these kind of things and there is not much help I can provide for this. Maybe the best way to do it is just to start right away coding something. It could be an already public system or anything, the key is to have a goal, like "whenever I kill a monster I want the server to give me an item and write me something in the chat". Then you just split it to subtask like:

  • How can I catch if a character dies?
  • How do I know it was killed by a player?
  • How do I know the dead character was a monster?
  • How do I give item to a character?
  • How do I send a chat message?

And by doing this you can already see various parts of the server, including CHARACTER class, ITEM class, some netcode and many others. Oviously the more complicated the idea the more parts of the server you can explore that way.

The one and only UI programming guideline

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.