This content has been marked as final. Show 7 replies
send() is fully reliable, which means lost packets will delay the entire stream until they are re-sent successfully.
Perhaps you should only send a packet when the ball collides with the bat and send the angle, speed and location of which the ball hit the bat. With this small amount of data the receiving client would have enough to calculate the trajectory and speed of the incomming ball. A tick counter would have to be set up and synced between the two clients.
This suggestion might be irrelevant anyways as it doesn't seem flash is ready for this type of real-time interaction. In a lot of real-time multiplayer games the server (or one of the clients) is the absolute authority on what happens in the game world. For instance, in an FPS a player might shoot another but by the time the server receives this data it has to rewind the game and check where everything was when the command was sent before confirming a hit. In good network conditions this is hardly noticable due to clever techniques for covering it up. With something like pong this strategy would be a lot more unforgiving if a network delay were to occur.
Just out of curiosity, what are these clever techniques isurgey?
keep in mind that there are two factors affecting communications between two endpoints: speed (bits per second, what i assume you mean by "good velocity"), and latency (delay, round-trip time).
if your game is structured such that a round-trip communication has to happen before the ball can move, and you are assuming the round-trip time is nearly zero (as it is on a LAN), then performance will be acceptable on the LAN but be unacceptable as soon as you have any network delay. as soon as you're talking about going over the Internet, you're going to see end-to-end delays ranging from a few milliseconds to tens of milliseconds to potentially hundreds of milliseconds, depending on the locations and providers serving the two endpoints.
Entity interpolation/extrapolation and lag compensation are some of the methods. Essentially the client renders at a set time interval (say 100ms) behind the data it receives which allows it to fill in the gaps and make the movement of objects appear smooth. If it runs out of data can extrapolate for a very short period by predicting an object's current location based on it's past trajectory.
This means that a player must always see the game world as it was 100ms ago plus the time it takes for data to reach it. Any commands given (for instance shooting) are executed on the world as it was when the player saw it and the server compensates for this, updating other clients accordingly.
Although this can give rise to situations where a player could be killed even after taking cover, such things are usually only noticable under heavy lag due to the almost imperceptable time differences involved.
For a more in-depth explanation see here : http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Thanks, this is cool stuff. So do you think that this 100ms lag time would work in a mortal combat style situation where each player would be fighting the other a tenth of a second ago?
Possibly, although Mortal kombat has different requirements to an FPS. It might seem strange, but an FPS doesn't rely as much on instant feedback. If someone gets shot they continue to play for the short while until the message reaches them that the server says they should be dead. It's not very noticeable, partly because of the relatively small delay and partly because most players will percieve the time they died as being the time their screen says so.
With mortal kombat you need to account for blocking and countering attacks. If an attack is blocked or countered the client won't know this until it receives all data concerning the game-state and this effects both the visual output and future of the game quide considerably. Wheras with an FPS a bullet hitting you can't be blocked, dodged or countered in this way. The kill or hit command is final if the server says it is.
But perhaps if you designed a game around these requirements it could be done. I think the Xbox 360 version has online multiplayer so it must be possible at some level.
First, Thanks to everybody
We have made a new version of the online sample “pong”
Let me explain a little:
In the previous version we were trying to implement a generic architecture to develop the game in single player and then convert it to multi-player. This architecture must allow have games with a high synchronicity level. That was the reason for implement in a first state the game in a round-trip algorithm as says Michael Thornburgh.
We have demonstrated that Flash Player gives peer-to-peer communications with the performance indicated in the paper proposed by isurgey ( http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking )
In this new version we have used the techniques proposed in the same paper to improve the performance.