Other users jump ahead, then snap back on update.

[JTxt]

Used an empty channel for testing, just one other user. The other user would continue to move past, until the next update.

Perhaps use a form interpolation. I would trade a little delay for smooth motion.
I'm not versed in this problem, but perhaps something based on springs and velocity would look better than a linear interpolation. (like is used on the example on pubnub.com) The new update point attracts the avatar. But the avatar has a little mass so it may curve to the new location, instead of sharp turns.

[kanaka]

If you fire up two clients on the original (1110.n01se.net) you won't see that problem unless you have really bad client latency. WebSocket connections have very low round-trip latency (assuming your net connection has decent latency). With HTTP streaming mechanisms you can get server to client latency down fairly low (on average), but client to server latency will always be quite a bit higher due to connection setup.

But I think there is an additional problem with the pubnub version. Even with the current low number of connections (there seem to be less than 30 activate avatars right now) it still seems that the vast majority of updates are not going through and sometimes only in one direction or the other.

[JTxt]

@kanaka, 1110.n01se.net: var send_poll_interval = 150;

pubnub: var send_poll_interval = 600;

And I agree that not all updates are received from PUBNUB. Perhaps a throttled VM?

I would eliminate updates to/from users not seen. #5 and have random spawn points at other interesting locations when load is high.

Even the n01se.net version is a little jerky. I don't think updates have to be even quite that fast if good interpolation is used.

[kanaka]

@JTxt, the pubnub server/servers would have to be REALLY throttled to be causing the high loss of messages that I see.

With the original I think you are probably seeing a couple of things:

• First, Chrome has some render pauses that cause the client side to be a bit stuttery occasionally. I think this is probably a GC pause issue. Recent firefox doesn't seem to have that problem (and I know they've done a lot of work in that area) although the frame rate is consistently lower so it's not as smooth overall.
• The other problem is that the angle at which other balloon guys are displayed is not interpolated so it causes movement to appear more twitchy than it really is (because the local avatar is rendering more frames for the angle change that for other avatars).

[stephenlb]

Hi @kanaka and @JTxt,

You are bringing up good points regarding throttling. We are noticing a lot of general {"id":"blahfoo"} message coming through with not status on position or state. This would make it seem that messages are dropping when in fact the client is just not sending anything. There could be some code to be checked out there.

Also regarding network based animation here is a collated list of items we collected over the years that we have worked with on animation systems over the network.

Animation Principals for Networked Gaming

• Dead Reckoning
• Deterministic Lockstep
• Jitter Buffers
• Object Authority Pattern (OAP)
• Authoritative Client
• Unsynchronized Clocks
• Loosely synced Clocks
• Client Side Prediction
• Latency Compensation
• State Streaming VS Input Streaming
• Floating Point Discrepancy
• Sequence Numbers
• Predictive Corrections
• UDP/TCP Acknowledgements (ACK)
• Preventative TCP Flooding
• Latency Detection

Network Programming For Gaming

• http://gafferongames.com/networking-for-game-programmers/
• http://gafferongames.com/game-physics/networked-physics/

Implementing these types of animation principals will be beneficial and you will approach industry quality multiplayer applications. There is a lot to do!

[kanaka]

@stephenlib Looking at the pubnub version, I can confirm that the {"id": foo} style messages make up the majority of the messages that the client receives. In the original version, bare {"id": foo} messages only come from the server to a single client when they connect. The "id" field is not stored in the main avatar map and that's where all sends are generated from. This appears to still be true even in the current pubnub version. So those messages are either coming from the pubnub service or from the pubnub WebSocket shim layer.

I instrumented the pubnub WebSocket shim in the client code and it appears that the calls to send() are VERY bursty. E.g. 7 or so messages go out rapidly and then there is a delay of 5 seconds and then another bunch go out. Looking at the Chrome network debugger confirms this. That only seems to explain part of the problem though because with two browser tabs connected I still seem to be missing most of the messages that are sent by each client. I.e. client 1 clearly sent a message (or thought it did up to the pubnub endpoint) but client 2 never receives it.

If you connect two separate browser tabs to http://1110.n01se.net you'll see that interactivity and latency is quite good. With my net connection I've measured round trip latency averaging about 100ms (min 60ms, max 180ms). It could easily be much lower but the server is intentionally collecting messages and only sending out updates every 75ms in order to keep CPU use very low (AWS t1.micros get unhappy if you have even moderate CPU for more than a few seconds).