Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would say that the biggest issue you are running into here is that you have made the movement of the sprite synchronous with an asynchronous operation. Both your draw cycle and your movement actions should be decoupled from the AJAX response. Record all of the movement of the sprite client side and send differences to the server. The server can validate the differences to ensure that the sprite has not moved farther than it should have. If the server and the client disagree about the position of the sprite above some threshold the sprite can be moved to a position that is correct. In general the server and the client should agree that the sprite can have moved from the last known point to the new point.</p> <pre><code>Here is some very crude psudo code to illustrate the concept. Client: Packet = {startPoint:{x:1, y:1}, endpoint:{x:5 y:7}); sendPacket(Packet); Server: If(abs(Packet.startPoint - Packet.endPoint) &gt; minPoint){ fixPoint.x = Packet.endPoint.x – minPoint.x; fixPoint.y = Packet.endPoint.y – minPoint.y; Return {moveValid: false, fixPoint: fixPoint} }else{ Return (moveValid: true) } </code></pre> <p>This will work well in compensating for simple latency and will also detect cheating by the client. If there is extreme latency you will end up with frequent “teleporting” of the sprite especially if the requests start getting processed out of order when the latency is greater that the frequency you are sending requests.<br /><br /> Most online games use sockets directly and can send much lighter packets than HTTP which you are stuck with in JavaScript, so you will need to explore the bounds of the concept to see where the thresholds will land with JavaScript and AJAX.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload