I'm starting to develop a new MMORPG and before I get too far into development, I want to do some research on what the best way is to have perfect or almost perfect synchronization.
In the past, I have just been sending keystrokes to the server (and then to other clients). When Player "A" presses the <right> key, it will end up on other clients and will begin to simulate the dummy player based on what keys are pressed.
This way is surprisingly accurate, but not quite accurate enough for what I need. In my new MMO, I'm going to be adding PvP which means players need to have good synchronization so they can have an optimal fight. It won't look good when you swing your sword but the slight delay causes you to miss since the opponent is already too far away in pixels (this is a 2D game by the way).
I've been playing a game called League of Legends lately, and the whole game is based around PvP. They have a perfect online engine set up that provides optimal fighting and no jumps or delay and everything seems to be very accurate and synchronized. Maybe someone has some information on how they did this so well? From what I read on their forums, they said the whole game is simulated on the server and the clients are basically used to "animate" what the server is simulating. It's a start but I still don't know the details on how they got all of the players synced perfectly.
So I'm here to take any advice, information or links you may have related to the subject so I can provide a lagless experience for the players when my game is released.
Thanks for reading and I appreciate anyone who takes the time to answer! :)
Perfect or Almost Perfect Synchronization
I don't know much about networking but I've found some things you migth want to read:
link 1
link 2
link 3 (gamedev thread)
the basic idea of many server-client based games is: a server keeps the state of the world, clients send events to the server (e.g. button pressed), server sends updates to the clients one in a [a certain timestep].
There are more approaches to this problem, all with there own advanteges. There are also some techniques that can be used to improve the client-server system such as interpolation.
(btw: perfect synchronization does not exist, all you can do is cover up that you are somewhat behind) <- this last statement is not entirely true, sorry (see next post by Antheus)
[Edited by - flammable on August 10, 2010 7:12:06 AM]
link 1
link 2
link 3 (gamedev thread)
the basic idea of many server-client based games is: a server keeps the state of the world, clients send events to the server (e.g. button pressed), server sends updates to the clients one in a [a certain timestep].
There are more approaches to this problem, all with there own advanteges. There are also some techniques that can be used to improve the client-server system such as interpolation.
(btw: perfect synchronization does not exist, all you can do is cover up that you are somewhat behind) <- this last statement is not entirely true, sorry (see next post by Antheus)
[Edited by - flammable on August 10, 2010 7:12:06 AM]
Quote:Original post by flammable
(btw: perfect synchronization does not exist, all you can do is cover up that you are somewhat behind)
Sure it does, it is just commonly impractical. Input-based methods in general tend to keep all peers in perfect sync.
To be pedantic, that requires a somewhat lenient definition of "perfect sync". The theory of relativity makes the absolutely rigorous definition fairly impossible. Even if you guarantee that everybody will see exactly the same things, you can't guarantee that they will start seeing them at precisely the same time.
I am guessing that by "perfect" here, we are just meaning that everybody gets exactly the same state updates, and each update is seen by all players within a very small time window? (eg. RTS lockstep system.)
I am guessing that by "perfect" here, we are just meaning that everybody gets exactly the same state updates, and each update is seen by all players within a very small time window? (eg. RTS lockstep system.)
Quote:you can't guarantee that they will start seeing them at precisely the same time
To be really, *really* pedantic, within the limits of relativity and jitter imposed by the system (which is down to a single screen refresh frame of difference, if you're careful), you *can* guarantee that everyone who participates see exactly the same thing.
You of course have to make sure that you design your code for a fixed frame rate (say, 60 Hz), and make sure that everybody uses computers that can actually render everything at that frame rate, or some people will be off by at least a frame or two.
Also, if everyone sees exactly the same thing, then that means that they all see the same user interface interactions, cursor movements, camera, etc. Would you create multiple cursors for multiple players? I'm red, you're blue, and text/menus I select are red, text/menus you select are blue? That would enable kind-of interesting gameplay, but really wouldn't scale to an MMO setting. Also, in MMOs, you often want different people to have different points of view, and potentially be in totally different parts of the zone, which means they by necessity have to see different things.
So, after poking fun at the definitions of "sync" and "perfect" and "equal" and "same," let me offer some actually useful advice:
1) Users will have to compensate for the latency of their swing. Else, there's no way to avoid cheating. (See the "1,500 archers" article)
2) If you don't think users will cheat on the client, you can make it as fast and accurate as you want, and simply send the outcome of each attack to the server. That means the other end has less time to parry and stuff, of course, which heavily penalizes people with low ping (LPBs).
3) I suggest using the RTS model, and design your attack animations such that they include "wind-up" that only plays on the attacking player's side. The duration of the "wind-up" time is the maximum round-trip latency you will allow between client and server. For example, with 500 ms wind-up, you can have at most 250 ms to the server, and 250 ms back (which probably 90% of all potential players would fall within).
Players will have to start attacking in time enough that they will hit the other player even if he moves. Even with a real sword, your opponent will move while you're swinging.
There are some posts about how to network a fighting game on this forum, which may contain some suggestions that might help.
1) Users will have to compensate for the latency of their swing. Else, there's no way to avoid cheating. (See the "1,500 archers" article)
2) If you don't think users will cheat on the client, you can make it as fast and accurate as you want, and simply send the outcome of each attack to the server. That means the other end has less time to parry and stuff, of course, which heavily penalizes people with low ping (LPBs).
3) I suggest using the RTS model, and design your attack animations such that they include "wind-up" that only plays on the attacking player's side. The duration of the "wind-up" time is the maximum round-trip latency you will allow between client and server. For example, with 500 ms wind-up, you can have at most 250 ms to the server, and 250 ms back (which probably 90% of all potential players would fall within).
Players will have to start attacking in time enough that they will hit the other player even if he moves. Even with a real sword, your opponent will move while you're swinging.
There are some posts about how to network a fighting game on this forum, which may contain some suggestions that might help.
Author
Wow flammable I took a quick look at those and they look like they will be a big help! I haven't read them in full detail yet but I'll do that as soon as possible. They look quite interesting :)
Isn't this where delta time would have an effect?
Wow these are great suggestions. I wondered about having the client check for any opponents to hit, or sending a packet to the server and the server could check if a player is "within range" of any opponents.
I like the concept about the 500ms wind-up, however what about the times where your attack must be instant (like instant-cast spells)? There would have to be a work around for that..?
You guys are providing me with some great ideas!
Here is a small idea I've been thinking of:
1) Player 1 Swings sword
2) Packet arrives at server 200ms later
3) Server checks where ALL other opponents were 200ms ago
The Server would only be a few hundred milliseconds off from the opponents client. This may or may not be a good way, but I would love to hear any suggestions or if you see any flaws in the concept. Although if my math is correct, and someone is on a 500ms latency, that's ~ 31 frames (on a 60Hz game) and possibly many pixels off depending on the speed of the player. Like you said, users should be able to compensate for lag as long as the movement is SMOOTH and not all choppy/jumpy.
I hope I'm making some sense and not just rambling :D
[Edited by - TrieBr on July 16, 2010 2:58:51 PM]
Quote:and make sure that everybody uses computers that can actually render everything at that frame rate, or some people will be off by at least a frame or two.
Isn't this where delta time would have an effect?
Quote:
3) I suggest using the RTS model, and design your attack animations such that they include "wind-up" that only plays on the attacking player's side. The duration of the "wind-up" time is the maximum round-trip latency you will allow between client and server. For example, with 500 ms wind-up, you can have at most 250 ms to the server, and 250 ms back (which probably 90% of all potential players would fall within).
Wow these are great suggestions. I wondered about having the client check for any opponents to hit, or sending a packet to the server and the server could check if a player is "within range" of any opponents.
I like the concept about the 500ms wind-up, however what about the times where your attack must be instant (like instant-cast spells)? There would have to be a work around for that..?
You guys are providing me with some great ideas!
Here is a small idea I've been thinking of:
1) Player 1 Swings sword
2) Packet arrives at server 200ms later
3) Server checks where ALL other opponents were 200ms ago
The Server would only be a few hundred milliseconds off from the opponents client. This may or may not be a good way, but I would love to hear any suggestions or if you see any flaws in the concept. Although if my math is correct, and someone is on a 500ms latency, that's ~ 31 frames (on a 60Hz game) and possibly many pixels off depending on the speed of the player. Like you said, users should be able to compensate for lag as long as the movement is SMOOTH and not all choppy/jumpy.
I hope I'm making some sense and not just rambling :D
[Edited by - TrieBr on July 16, 2010 2:58:51 PM]
Quote:what about the times where your attack must be instant (like instant-cast spells)?
You can show the instant spell casting effects, but defer the results until they're known. Like, show the fire and smoke, but don't change the hitpoint meter until the result comes back.
This is what most FPS games do (because gunfire is more or less instant).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
