Training
Servers and clients
I know that you are really anxious to start working at your MORPG, but before doing that, we need to discuss and understand the basics of the client/server architecture. The concept shouldn't be that hard to grasp, because the Internet itself relies on servers and clients.
Let's begin with a real-life client/server code snippet.
Okay, I'll admit that this first project doesn't go too many things, but what do you expect from a few dozens of lines of code? Still, this snippet shows how the server/client pair works. Servers are the game masters, if you will, while clients will only execute the servers' instructions. Most servers are dedicated computers that have huge CPU and memory resources, because they run most of the code. Clients are regular computers, which are utilized by people to play games.
If you think that your client's (computer's) actions will always have direct consequences in a MORPG game, you should think again: in fact, each client sends information to the server, which will then tell the clients where (and if) their fireballs will show up in a level, for example. So, even if you have lightning fast reflexes, your projectiles may be delayed quite a bit because of server lag. Things can work quite well for clients/servers that utilize a local network, but they can quickly get out of control for MORPG games that are played over the internet. Don't worry, though; we will discuss two effective lag compensation methods in one of the next tutorials.
Back to our code: to run the program as a server, build the executable, and then start it using the -sv (server) command line parameter. Then, you can start as many clients as possible by running the exe file using the -cl (client) parameter.
The image above shows the typical client/server architecture for a MORPG game; you can see that the clients will communicate with a server that's hosted in the cloud. It is always the preferred solution, because it frees game developers from mundane tasks such as patching their servers, preventing hacker attacks, and so on.
As you know, clients can't communicate directly. In other words, even if you (player1) think that you're firing your fireball towards player2's model, you are only sending a firing signal to the server, which will determine if your fireball's coordinates match player2's model coordinates. If they do, the server will decide that this is a hit, so it will tell player2 to decrease its health. So, the client/server game architecture doesn't work like a peer-to-peer connection.
The simple code snippet above was written with a single goal: to show you that any MORPG has different code sections for clients and servers. While it is true that some code will be run by both the server and its clients, there will always be code sections that will only run on the clients, and sections that will only run on the clients.
Before ending this tutorial, I want to highlight the importance of low frame rates for online-based multiplayer games. Modern computers can now run detailed games at hundreds of frames per second, and this is a good thing. It would be a huge mistake to run the server at its maximum frames per second, though. If the server's frame rate were set to 200 fps, for example, it would have to send and receive 200 data packets each second. This may sound like a good idea, but it can create huge problems, because some clients won't be able to keep up with the frequent data requests due to latency, poor Internet connections, low-end hardware, and so on.
The solution is simple: keep the server's frame rate in the 30...60 fps range. Your code will need to work harder by using interpolation and other advanced techniques, but the end result will be a MORPG game that plays fluidly for most people.
Need help with code for your MORPG? I can help!
