<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.23067">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi there,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Yes, I should be able to easily enough. All that'll 
happen is you'll hear the footstep at once, and then you'd be silently pushed 
back to your original location if the server refuses your move. Could be a bit 
of a confusing situation though, since we have to wait at least one roundtrip to 
get the result of our move. And should these things be sent 
reliably?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Kind regards,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Philip Bennefall</FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> 
  <A title=jsprenkle@gmail.com href="mailto:jsprenkle@gmail.com">Jay 
  Sprenkle</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=philip@blastbay.com 
  href="mailto:philip@blastbay.com">philip@blastbay.com</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, November 24, 2010 1:48 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [ENet-discuss] Best 
  practises for synchronizing states</DIV>
  <DIV><BR></DIV><BR>To combat lag in some games they send a packet indicating a 
  player will move, then while waiting for the server to validate the movement 
  predict the new player position, and render it to show the user. If the server 
  doesn't get the update or refuses it then the local position is corrected. You 
  might have seen the 'rubber banding' effect.<BR><BR>Can you do something 
  similar with sound? <BR><BR><BR>
  <DIV class=gmail_quote>On Tue, Nov 23, 2010 at 9:00 PM, Philip Bennefall <SPAN 
  dir=ltr><<A 
  href="mailto:philip@blastbay.com">philip@blastbay.com</A>></SPAN> 
wrote:<BR>
  <BLOCKQUOTE 
  style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex" 
  class=gmail_quote>
    <DIV bgcolor="#ffffff">
    <DIV><FONT size=2 face=Arial>Hi all,</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>This is a fairly lengthy email, so I apologize 
    in advance.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>I am relatively new to ENet. I have integrated 
    it in my game engine and have successfully written a game which is working 
    perfectly. It is one of those finger twitching action games where speed is 
    of the utmost importance and delay is the most evil thing in the world. The 
    way I do it is to keep sending the entire state for a player to the other 
    party unreliably. The other client then works out the events that "must" 
    have occured by looking at the differences between the last known state and 
    the new one. This is far from a perfect solution as it neither scales well 
    nor provides for very readable code. Here's a summary of how I'm handling 
    things:</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>The game is a shooter where you run a round on 
    a 1d grid firing rocks at your oponent's palace. When a rock hits a square 
    on the other side it'll quickly begin piercing its way through until 
    that section of the wall crumbles. During that time, the other player may 
    use their hammer to defend the section.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>I wrote an internal layout description for 
    myself before I started coding, which I then followed to ensure proper 
    handling of all possible situations.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>---Start of Internal 
Description---</FONT></DIV>
    <DIV><FONT size=2 face=Arial>The way in which this game communicates over 
    the network is fairly simple. The two players have a direct connection 
    established between one another, and they send out their player state 
    roughly 30 times a second. This player state contains the current x 
    position, the current throwing position which is -1 if nothing is being 
    thrown, and then a list of all the squares on that player's side. For each 
    square, two values are stored. The first is the current resistance which is 
    20 on max, and 0 if the square is destroyed. The second one is crumbling 
    speed which is 0 if the square is not currently crumbling, and a value in 
    milliseconds otherwise. This value is used to measure if two or more rocks 
    have been thrown on the same square.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>When a new state is received from the remote 
    player, we have to analyse this information in order to determine what 
    changes that have occured and if we need to take any action.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>If a new x position is received, we simply move 
    the player's local variable to this square and play a footstep 
    sound.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>If the new throwing position is different from 
    our old one, we can take a few actions depending on its value:</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>1. If the new one is greater than -1 and the 
    old one is -1, the remote player threw a rock at us. we play the throwing 
    sound in the appropriate location, but take no other action.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>2. If the new one is -1 and the old one is 
    greater than -1, we can assume that the remote player hit us and start the 
    crumbling sequence for that square on our end. Naturally if our square is 
    already crumbled, the remote player will not get any hit notifications from 
    us. </FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>3. If they both are greater than -1, we can 
    assume that the remote player hit us and so we activate that sequence as 
    above. We can also assume that the remote player made a new throwing attempt 
    in another location and that we didn't see the -1 state that came prior to 
    it probably because of lag, and so we play another throwing sound in the new 
    location.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>After this, we go on to scan the game board and 
    do the following for each square:</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>If the new resistance is greater than the old 
    one, the remote player hammered and so we play that sound.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>If the new resistance is lower than the old 
    one, we can take four actions.</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV><FONT size=2 face=Arial>
    <DIV><BR>1. If the new resistance is 0 and the old resistance is greater 
    than 0, the square just broke so we play the appropriate sound and forget 
    about it.</DIV>
    <DIV> </DIV>
    <DIV>2. If the old crumbling speed is the same as the new one, this was a 
    normal crumbling step and so we play the appropriate sound.</DIV>
    <DIV> </DIV>
    <DIV>3. If the old crumbling speed is 0 and the new one is greater than 0, 
    this was a new hit so we react accordingly.</DIV>
    <DIV> </DIV>
    <DIV>4. If the old one is greater than the new one and the new one is 
    greater than 0, this was a new hit on the same square.<BR></DIV></FONT><FONT 
    size=2 face=Arial>---End of Internal Description---</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>I realize that this is a lot of very game 
    specific information, and that's exactly my point. This all seems like a 
    very dirty hack to me, and I was wondering if any of you can suggest a 
    better and more scalable way of doing this while still keeping latency to an 
    absolute minimum?</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>Thanks in advance for any help!</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV>
    <DIV><FONT size=2 face=Arial>Kind regards,</FONT></DIV>
    <DIV><FONT size=2 face=Arial></FONT> </DIV><FONT color=#888888>
    <DIV><FONT size=2 face=Arial>Philip Bennefall</FONT></DIV></FONT>
    <DIV><FONT size=2 face=Arial>P.S. I should perhaps mention that this is a 
    game for the blind; entirely based on sound, which is why sounds are 
    mentioned all over the place rather than 
    graphics.</FONT></DIV><BR>_______________________________________________<BR>ENet-discuss 
    mailing list<BR><A 
    href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</A><BR><A 
    href="http://lists.cubik.org/mailman/listinfo/enet-discuss" 
    target=_blank>http://lists.cubik.org/mailman/listinfo/enet-discuss</A><BR><BR></BLOCKQUOTE></DIV><BR><BR 
  clear=all><BR>-- <BR>---<BR>"Is real reporting dead?  News at 
11!"<BR></BLOCKQUOTE></BODY></HTML>