Training
Real-time MORPGs
Okay, so we've learned quite a few things about RPG game development, the client/server architecture, chat systems and turn-based games so far. It's time for out first real-time multiplayer game demo, which will create a sphere model that can be moved around independently by each client. We are just setting up a basic, and yet solid foundation for a MORPG in this article, of course; feel free to check out this forum thread for a good list of additional advice and resources.
The code for our basic game is fully optimized, fat-free and lightning fast. Here's the source for the entire project.
Well, I'd say that the code doesn't look THAT scary. To keep it short and easy to understand, I had to simplify some things, though. The sphere entities are moved directly, by changing their x and y coordinates, for example, so they don't perform any collision detection. Of course, this type of movement isn't suitable for real-life games, in which player models must collide with the terrain, other players, their projectiles, and so on. I did this on purpose, because I wanted to help you understand how real-time client/server data exchange works without building a complex, hard to understand project.
Function main() does most of the job; it limits the frame rate to 60 fps, loads the level, sets a proper camera position, and then it creates a red ball on the client computer(s) and a blue one on the server.
The key thing to understand from this small project is the fact that all the sphere entities are controlled by the server. We can't move the client entities independently, and then expect to see the server keeping them all in sync, for all the clients. We can't move the client entities independently, and then let the server know what happened after that, because by doing this we risk getting the game entities out of sync as soon as one of the clients loses its connection with the server (even for a few frames/data packets).
So, the only valid method of keeping the entities in sync when we are building a multiplayer game is to let the server most of the job. Basically, the clients will only do unimportant things (player model animations, for example) and the server will take care of the things that really matter.
Here's another demo which is based on the previous project and implements local player model animations.
This time the players animate using either their "walk" or "stand" animations, depending on which keyboard keys are pressed, but they will only use local (client) resources to do that. The only information that they're sending to the server is their x, y, and z coordinates, which are stored in the entities' first three skills, and are needed by the server to perform the required collision detection operations.
Clients send their positions using the send_skill instruction each frame; if you plan to create a MORPG that allows thousands of players to run the game at the same time, you may need to send this data less often and allow the server to interpolate player's/client's positions. We will discuss this method in a future tutorial.
This concludes our real-time multiplayer example. You now have a solid, fully functional coding foundation that can be used for your own MORPGs. We still need to learn how to optimize our code for clients that utilize poor Internet connections, but if everything goes as planned, we will do this in the next lesson.
Need help with code for your MORPG? I can help!
