I am currently developing a MMORPG with a friend. He is writing the server side code, and I am writing the client side. After reading an earlier post, I realized that our system for walking was incorrectly done, and would cause lag. We currently have the client send the server a walk packet, and the server sends back the new coordinates. As stated in an earlier post, this would cause a lot of lag, and we have decided to use the method where the client sends the server its new coordinates instead of waiting for the server to send current coordinates. I understand how this will work, however I have a question about how to send/receive data from players around you. For example, the whole player structure with the player''s characterstics, straights, etc. is around 2k. This is fairly large, and is unnecessary to send more than once. Instead, update packets should be sent (if I am wrong on this, please suggest a better approach). This leads me to my question. If I, the client, am moving on the map and sending my current coordinates to the server, how will the server be able to send back information about players around me in time? Since there will obviously be some kind of lag between the client and server, players around me would appear too late, since the client will have no lag. How can I compensate for the lag between the server and client? My only idea right now is to have the server send information about players earlier than needed. It would send player information ahead of time, for example 20 units away, so that by the time I walk 20 units forward, I will already have information about that player. Is there alternative methods? Thank you for any help.

quote: Original post by B4
I am currently developing a MMORPG with a friend. He is writing the server side code, and I am writing the client side. After reading an earlier post, I realized that our system for walking was incorrectly done, and would cause lag. We currently have the client send the server a walk packet, and the server sends back the new coordinates. As stated in an earlier post, this would cause a lot of lag, and we have decided to use the method where the client sends the server its new coordinates instead of waiting for the server to send current coordinates.

Sorry, but the new way seems worse than the old way, but for different reasons.

You cannot trust the client. In this case, you can''t trust it to send you valid coordinates.

If the client gets to decide on its co-ordinates, it becomes trivial to cheat. Hacking such things is very easy for people with a little time on their hands. The only safe way to do it, is to send a movement request to the server which the server then verifies. The client can render this movement instantly as if it took place, to reduce the appearance of lag, and move you back in the unlikely case of the server rejecting your movement request. Assume innocence/correctness on the part of the client, but check everything to ensure this is so.

So, instead of sending a move request and waiting for the server to return the new location (slow), or sending the new coordinates and having the server ''trust'' you (insecure), you send a movement request, and the server either sends back a minimal acknowledgement each time, or only replies with coordinates when the movement fails. That way, you keep your server-side movement authentication, but without the overhead. The client makes the assumption that its movement request will succeed, but can undo this in rare situations.

As for your latency issues, this is just something you have to accept happens. Even if you can predict stuff, it can still be wrong, and so sometimes things will happen that shouldn''t and people will appear to be somewhere they aren''t. That''s just how it is. Even if we get light-speed communication soon, there will still be too much lag between Europe and Japan (for example) to play beat-em-up games across the net.

You can do some prediction of travel paths by interpolating previous changes of position and so on, but you still need to resync these with the ''real'' position every so often from the server. Look up stuff on "dead reckoning".

Sorry, I forgot to mention that with my new method of movement, the server would still be check the player''s location. It will check the rate of movement, and in what timeframe they made these moves (or something similar). This should prevent cheating or hacking. Thank you for the advice, and please let me know if I am still missing something using this method.

As for how much and when to grab info about the other players/NPC's this depends on the amount of interaction that you have with the player/NPC at the time. You might be able to get away with sending all the info once as the player/NPC enters your 'zone' and then just make update changes but it seems that you may be sending lots of information that isn't needed. For example would you want to send across all the persons stat information? As mentioned by Kylotan you can't trust the client 100%, its there as a window into the game world so all the processing for actions (ie. fighting, leveling etc) should be handled at the server my system for it would work something like this.

We enter the zone, the zone is empty so we explore around sending out movement packets which the server validates somehow (your movement within a timeframe is nice).

Then Player A enters the zone, as he is now in the area that we can render the server immediately sends the information to render that character plus things like name, rank, guilds. Basically the things required to display the character and any info that would show on or above the char (like name over peoples heads).

Now both players explore the arena sending out update's to the server. The server validates these responses and sends out an update to each of the clients about each others positions. Filtering this output with dead reckoning methods (ie. Cubic Splines) allows you to plot movement positions at more than the update rate thus making movement appear smooth.

Player A attacks us, the server validates this and tells us whats going on. Now we both start swinging at each other/drinking potions/casting spells all this info is sent to the server which validates the actions being taken (for example within range to strike with weapon, enough mana/energy/whatever to cast the spell) It then calculates the effects of whatever happened and sends the information back to both parties involved. This continues until something breaks the fighting.

Add another player into the equation and you see that you have another person to keep updated. But you'd need to limit the amount of info you send to them as well.

[EDIT: Correct obvious errors :D]

Edited by - meh on August 22, 2001 6:07:10 AM

Client side movement is fine, but make sure you have a good system in place that does some sanity checks against the last time the client sent the server it''s position, where that position was, the delta time between then and the current update, and the delta distance between the two. Make sure that gets logged and/or kicks the client when that happens.

As for sending player info, just send the player structure when a player enters the zone or the info changes. Give every player in the zone a unique ID and use that when identifying their movement / combat / whatever.