Hey,
Im experimenting with… well… how do you call it… just like an Online Role-Playing game, but my question is how I can create a fast networking system for that?
For example, can I let it directly contact a MySQL database somewhere on some server?
Or do I need to create a program that runs on some server and that keeps sending the location of each player to the client?
What is the best/fastest way to do this?
Security wise, you need to set up your server code to interact with the database locally.
You can’t connect directly to the MySQL database without exposing sensitive information.
Abstractly, the best way to do networking for a multiplayer game is to create a Send and Recieve function for both the client and server, make sure they are synchronized by tagging the packets sent. The client only allows manipulation of values that are on the server. No values should ever be dependent on the client if they are important to gameplay, or there will be exploits.
So theClient sends a packet to the server saying something like “Update Location 123, 456” and the server sends back a message saying “accepted”.
During this, the server also goes to the player record in the MySQL database, writes “123” for the x position, “456” for the y position.
Basically, the only thing you want open to the client is a strictly formatted connection with the server. Then design the server to interpret the data it recieves… if too much or improperly formatted data is consistently sent, shut off the connection.
That way, whatever you have on the server is secure, no sensitive MySQL connections are exposed, and the game is made secure.
That deals with security only, however…
Optimizing involves prediction. Basically, you need to figure out both how to minimalize the amount of data being sent back and forth by the client and server, and use the server to predict things like intended player moveTo location, whether or not a player will attack a monster, so on and so forth.
They key is abstracting behaviors as much as possible until an actual event occurs, at which you readjust or restart your prediction routine. Game mechanics called bottlenecks are used to aid in prediction algorithms, such as a narrow canyon… if only one player can pass through at a time, it limits the possible actions of what can be done without imposing a “fake” limit on the player.
Look up “networking for multiplayer games” on google and you’ll turn up a boatload of good information.
Thanks for the information.
So I just need to program (in C++ or anything else) a server program that keeps sending data to the Client (encrypted).
(Can a program open multiple connections with multiple clients?)
and in my game I need to create a system that sends the position every 1/10 second or so.
You want to do a role playing game, right?
Then you won’t need to update the position of a player every 1/10 second.
In fact you won’t even need a regular update on any data.
1st of all, movement in a RPG is easy to predict. A player will just click somewhere in the world where he wants to go. So you won’t need to watch every step of this player. You’ll just tell everyone to start a Lerp interval. If you’re clever in programming you will only need to transmit 4 values for that.
It’s the same with weapons… weapons are fired in one direction only, so use an interval.
And of course, a server can handle multiple connections. And you don’t need to encrypt your data, except maybe for a username/password combination.
encrypting data is a process that will slow down your performance. And encrypted data is bigger than the original data. So why would you want to encrypt the game data anyway?
You can also write a dedicated server with panda. Therefore you can use the network code that comes with panda on server and client.
Thanks!
But… it’s not a click-n-go game. Its just like an FPS. You use the arrow keys to walk.
And… any hacker could easily change the data if he interrupts the connection between the server and the client, couldn’t he? So wouldn’t it be good to encrypt it? (by my own very-fast encryption routine perhaps?)
Well if you want to play safe on this, your best bet is NOT encryption, but a serverside check of the info the client sends to you. Instead of wasting resouces and banwidth on encrypting and decrypting, you might want to check serverside if it is possible to do what the client send to you (like not accepting a step trough a wall or making sure the distance traveled since last update was possible with the current physics settings.
you can still use Lerp intervals even for FPS.
And with a lerp interval you can avoid some kind of cheating.
For example, if your client woud have to send his posiotion every 1/10 then he also could send a position somewhere in the map (teleporting).
And encryption will be of no use, as your game will be available in source.
And even if your game would be a compiled C programm there are still ways to decompile it. You can’t avoid that your client software will be hacked (well probably it won’t, depends on the popularity of the game). This is the reason why an encrypted connection makes absolutely no sense. despite the fact that nobody will ever try to hack the connection (because it makes no sense at all) your encryption would fail, because a cracker will find a way to take a look at your encryption algorithm.
The rule is not to trust anyone but your server.
ok!
But… how do I do that?
Just send the keypresses to the server or something like that?
Have the client send a vector on move events, and a rotation on turn events.
Move events are clicks, rotations are movement with left and right keys.
The vector is 2 points… for mouse movement, it’s easy, use a start and target location. For a keyboard vector, set the target point X meters in front of the character’s current position.
Rotation events are similar, you just need 2 values sent to the server, representing the speed of your rotation and the direction… 0 for left, 1 for right or something like that.
It’s a simple operation for the server to combine those two variables and predict the ending location, or a pathing node, in order to relay correct information to the other clients. Also, your players get the benefits of both point and click movement and WASD movement.
The server should be the final arbiter of speed, as well. The client can calculate little things like startup and slowdown speed… as far as the server is concerned, however, you could just do a simple single rate that is slightly slower than what the player sees on screen.
Also, because RPG’s like to have variable movement speeds (centaurs are faster than humans, unless humans have a run buff, etc., ) keep a list of absolute run values to scale a players movement on. That way, the client never has to send it’s runspeed, it just has to send a trigger to the server to alert that a change in the runspeed has been made. If the server verifies the change, then it sends back a flag to client which lets it know that it’s Flash Gordon time.
You could also look into optimization routines based on location within your world… people will generally run on paths and roads moreso than across terrain. If you offer a benefit to running on roads as opposed through thick grass, that ensures that you have a very specific trail the player will most likely follow. In those instances, you can have the server predict the entire route, in disparate, overlapping vectors. If the player follows the entire path, then no further calculation needs to be done and the server can use cached static data to accomplish it’s updates. If the player leaves the beaten path, however, you can resume normal path prediction based on immediate player input.
Since the input method is event driven, you want to have a limiter on the client(so someone’s not allowed to send a million clicks through to the server in a one minute period) and a queue on the server so it can prioritize and steward it’s CPU time in a reasonable manner.
Ideally, you should have an extremely minimal packet size, and once a degree of synchronization is achieved with the server, it can prioritize client communications. Nobody really cares if the facing of other players in the game is 100% accurate. If it’s accurate within a degree or ten, it’s good enough to look and feel real. Adjust your prediction routines accordingly… in those situations where sloppiness can be ignored or completely overlooked, then focus more CPU time on the situations that matter, like collision detection, or realtime clashes of swords, armored mounts, and spells exploding enemies into little bits.
More lag between clients means you need to gear your prediction algorithms’ priority to serving the slower clients. Higher bandwidth and less lag for a client means you have to do less prediction and can assign more real-time updates.
Even on a 56k, you should be able to send that data easily, so long as you format it correctly.
Even with a single kilobit, you have 1000 bits with which to send data. If you cannot create a packet structure with 1000 bits (1000 on/off flags, 100 10-bit flags, etc.), then you’re probably sending too much data. Use logic to structure the flags as much as possible. You could then realistically shoot for a .5 second refresh rate, even on slower connections (depending on how good your prediction algorithms end up being.) note: I don’t include chat with this… chat can eat up a much larger chunk of bandwidth, but you can use a more efficient queue system with less of a refresh rate to deal with load balancing for chat.
Then… once you’ve optimized your packet structure based on all the possible flags and triggers the client and server needs for communication, implement a cyclic redundancy check to verify the data sent.
Basically, you create a checksum that creates a semi-unique signature of the data in question. If the client performs the checksum and the checksum doesnt match, it means one of two things… the data was corrupted or wrong, or the checksum was corrupted or wrong. First, recalculate the checksum, and if it turns up wrong again, send a small notice to the server, like “Packet #XXXX failed”. The server should have it’s own set up for handling such errors. If it was simply a movement or ambience update, non-critical to gameplay, then the next packet sent will do just as well to update the client. If the client missed a significant packet, such as being attacked, taking damage, someone opening a trade, or some other important event, then the next packet sent needs to be adjusted to re-send that data.
And so on, and so forth… error correction, optimization by only sending gameplay important information, and minimalist interfaces can give you a good structure and a good usage of bandwidth.
Thank you for your help! I really appreciate it 
And, for the chat, I might have another server for that or so…
You may also look to an existing middleware like for example Arianne on sourceforge.net. they got a Tick Based client server architecture with a python interface.
Personnally i don’t use it because my own style of game does not requires hundred of players at the same time…
For a few players , with not too much action, simple distributed object framework can be an option ( like DOPY(no more supported) or PYRO)
The tradeoff is between the ease to integrate the multiplayer into your game (ex DOPY, 3 lignes of code to automatically distribute your existing python class) and the level of performance tuning you can achieve (client side prediction, packet optimisation).
I think the biggest issue is the inconsistency detection by server with rollback of previous consistent state …