Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Animate Multiplayer Cursors

liveblocks.io

Post reply on HN
Print view View original

41–50 of 64 posts

Re: How to Animate Multiplayer Cursors

#41

Post by franklampard »

Sohcahtoa82 wrote: post #40
paulryanrogers wrote: post #30

These are pointers and not cursors, unless I misunderstand. Cursor made me think of sharing tmux or IDE text sessions.

Not only is this is needless pedantry, it's also incorrect, making it a very typical HN comment. It is not uncommon to refer to pointers as "mouse cursors" or shorten it to just "cursor". In fact, Wikipedia considers pointers to be a subset of cursors. https://en.wikipedia.org/wiki/Cursor_(user_interface)#Pointe... "In computer user interfaces, a cursor is an indicator used to show the current position for user inter…

Exactly. In css this is exactly called

cursor:pointer/crosshair

Re: How to Animate Multiplayer Cursors

#43

Post by paulryanrogers »

Sohcahtoa82 wrote: post #40
paulryanrogers wrote: post #30

These are pointers and not cursors, unless I misunderstand. Cursor made me think of sharing tmux or IDE text sessions.

Not only is this is needless pedantry, it's also incorrect, making it a very typical HN comment. It is not uncommon to refer to pointers as "mouse cursors" or shorten it to just "cursor". In fact, Wikipedia considers pointers to be a subset of cursors. https://en.wikipedia.org/wiki/Cursor_(user_interface)#Pointe... "In computer user interfaces, a cursor is an indicator used to show the current position for user inter…

Is it so needless? Perhaps I'm misremembering but the distinction was at least useful in the past as GUIs evolved out of TUIs.

If they had said pointers there would be no confusion.

Re: How to Animate Multiplayer Cursors

#44

Post by HWR_14 »

LeifCarrotson wrote: post #28
HWR_14 wrote: post #22

Earlier quoted context omitted.

Honestly, I don't see why you'd need to batch it ever 100ms. Sure, you don't want to send a mouse movement every time an event triggers, but surely 30fps looks smooth and won't overload the system.

You can't reliably send, fail, retry, and confirm receipt of a TCP packet in 33ms over arbitrary Internet connections. 8ms is right out. I can get 200us over a local EtherCAT realtime industrial IO network, but that's with careful management of well-isolated single-machine network conditions and it just doesn't work with a cellular modem for download and oversubscribed residential cable for upload. Assuming latency o…

You're confusing latency with throughput.

I don't need to reliably send the TCP packets in 33 ms. I just need to be able to start sending a packet every 33ms. Assuming sending, acking, etc is non blocking and uses few enough resources asynchronously it's fine.

Re: How to Animate Multiplayer Cursors

#45

Post by Aeolun »

cousin_it wrote: post #9
jewel wrote: post #6

There's another approach that might work better. Instead of sampling the mouse position every 100ms, you'd save off all the mouse positions, and then send the latest batch every 100ms. The other side would then replay the exact positions, just delayed by 100ms. It'll end up with the same latency as these motion smoothing approaches, while only using slightly more bandwidth.

Yeah, wanted to say the same thing. If latency is the only problem, just batch up the updates and replay on the other end. If bandwidth also becomes a problem, only then start compressing the data. But to be honest, if we can stream video over the internet, we surely have enough bandwidth to stream cursor positions.

I think this is one of those situations where “just because we can doesn’t mean we should” applies.

The marginal benefit of exact cursor positions is so low that sending all that data still feels like a waste.

Re: How to Animate Multiplayer Cursors

#46

Post by Aeolun »

Sohcahtoa82 wrote: post #39
gernb wrote: post #37

Earlier quoted context omitted.

Am I missing how that would work? That's an exponential increase in bandwidth needed to send all the mouse positions. 1 position per 100ms per player vs 10-30 per 100 ms per player. Those positions all have to be propagated to other players. so in the first case, 10 players = 10 positions per 100ms. In the 2nd case is 100-300 positions per 100ms.

Yeah but stop and think about how little bandwidth it still is. X and Y can easily be 2 bytes each, 4 bytes total. 100 samples per second is a mere 400 bytes per second. You could do it from a dialup modem from the early 90s!

You could, but I think for most web applications the authors wouldn’t think about binary encoding. So you’d end up with something like:

  {“x”:50,”y”:56}
Encoded as a UTF8 string, which is 15 bytes, x100 is 1.5kb/second/participant.

Ok, I guess that’s still not that much.

Re: How to Animate Multiplayer Cursors

#47

Post by Aeolun »

LeifCarrotson wrote: post #28
HWR_14 wrote: post #22

Earlier quoted context omitted.

Honestly, I don't see why you'd need to batch it ever 100ms. Sure, you don't want to send a mouse movement every time an event triggers, but surely 30fps looks smooth and won't overload the system.

You can't reliably send, fail, retry, and confirm receipt of a TCP packet in 33ms over arbitrary Internet connections. 8ms is right out. I can get 200us over a local EtherCAT realtime industrial IO network, but that's with careful management of well-isolated single-machine network conditions and it just doesn't work with a cellular modem for download and oversubscribed residential cable for upload. Assuming latency o…

What we need is UDP websockets! Isn’t that what WebRTC is though?

Re: How to Animate Multiplayer Cursors

#48

Post by Aeolun »

tomovo wrote: post #31
capableweb wrote: post #29

Earlier quoted context omitted.

> This is analogous to player position in any multiplayer game. Not sure. Multiplayer games are easier to predict player movement. Once someone starts moving forward, you can predict that they'll move forward for a little while, start turning, continue forward and so on. Add in physics (like the motions/movements of a car, or the running of a human) and there will be constraints the player can't break (when you stop…

The real fun starts when online players start shooting at each other. How to decide if a hit was fair AND make it look believable for both parties to minimize outrage?

> AND make it look believable for both parties to minimize outrage?

Call of Duty MW2 used to replay what your opponent saw, after your death. That always made an inexplicable death much easier to swallow.

Of course, they probably had to add that feature since they did away with dedicated servers, but it was still nice.

Re: How to Animate Multiplayer Cursors

#49

Post by cableshaft »

stevenfabre wrote: post #25
cableshaft wrote: post #14

Earlier quoted context omitted.

I'm super interested in this. I have a few interactive articles I'd like to make, but I'm not sure what tech to use for it to make it relatively quickly and without taxing the page too much. Was thinking maybe the Phaser game framework, but that might be too heavy, especially if there needs to be 7 or 8 of them on the same page.

We build our interactive visuals with React and embed those into the mdx file for the blog post. I made note for us to write a blog post about it. Stay tuned :)

Already learned something. Wasn't aware of mdx and it looks right up my alley, thanks for mentioning it. I look forward to your blog post!

Re: How to Animate Multiplayer Cursors

#50

Post by somehnacct3757 »

capableweb wrote: post #29
somehnacct3757 wrote: post #20

This is analogous to player position in any multiplayer game. One additional parameter to keep in mind is how real-time does your simulation of remote players need to be? If you don't need real-time positioning there's a whole other dimension of shortcuts you can take by introducing what amounts to a 'streaming delay'. In a lot of these apps the cursors can't interact with each other so you have no need for real-time…

> This is analogous to player position in any multiplayer game. Not sure. Multiplayer games are easier to predict player movement. Once someone starts moving forward, you can predict that they'll move forward for a little while, start turning, continue forward and so on. Add in physics (like the motions/movements of a car, or the running of a human) and there will be constraints the player can't break (when you stop…

It's very common for games to deal with erratic input from keyboard controls. Consider player position in a moba or fps where two humans are responding to each others' presence (footsie.)

The penalty for a wrong prediction is rubber banding, so if you can get away with streaming their past at high latency, I would avoid predicting at all.

That's the model often used by async PvE games (think social games, invest/express, etc) and I think that approach would map best onto SaaS presence features.

Post reply on HN