Hacker News Reader

Comment by Animats | Hacker News Reader

Nice. You have to choose between fast and realistic. If you run one fix, 15 seconds, behind real time, and compute a route between the last two fixes, the paths will look good. But, as the author points out, when you order a car, nothing will move for the first 15 seconds. The author doesn't say how they dealt with that.

This is an old problem in multiplayer games. The usual solution is that the sending client predicts the position linearly from the last two fixes, and when the actual position differs from the prediction by some constant amount, it sends an update. The receiving end uses the same prediction algorithm, so its positions match the sending end with a maximum error of the same constant amount, (plus some additional error due to lag.) Updates are also sent periodically in case one gets lost, but those are not frequent.

Incidentally, Uber's display of cars on a map on the home screen is totally fake.

View on HN

I might be wrong but I think you're sort of confusing the way game multiplayer works for the local player, and for the other players they see.

If we're talking FPS games:

The local player is moved instantly based on their local inputs, and the server will also move them using the same rules. The local player will be corrected in any case where they don't match.

For other players that the local player sees, extrapolation in twitchy multiplayer games like FPSs is notoriously bad as the players are so hard to predict, so usually you have them running e.g. 100ms behind so you can (hopefully, depending on latency) interpolate between two data points from the server instead of trying to guess the future at all. So you still have the "behind real time" problem. The only reason the local player can avoid that is they have the benefit of local inputs. In an Uber sense they are the car.

Obviously that's a problem in games too, because now the player is shooting someone who's behind where they are on the server, so they miss. Latency Compensation fixes that - having the server rewind time to see what the client would have seen. But that won't help the cars-on-a-map problem.

Having said all that, I do agree with your point. Taking a couple of old data points and extrapolating from there should work pretty well for the cars problem. You'll see them snap back when they stop at intersections though.

I find programming games in general, esp FPS, fascinating because their real time requirement is so critical big lag in request/response, dealing with hotspot in code.

Why can't the driver phone be connected to rider via peer to peer. Driver sends position updates to rider in almost real time while occasional batch updates to server.

The fanciness regarding position, why not show a halo like most gps apps showing degree of accuracy?

You could all show a slight tail of previous path to give an idea of direction and speed.

I think the current uber/lyft ui experience is subpar and can be improved.

How about the opposite: Show the car with a nice interpolation using the last two positions, but with an extrapolation arrow with the point located where you think it is now. Then when the system thinks the car is moving fast and it actually comes to a quick stop, it can cut down the extrapolation arrow instead of moving the car icon backwards, and it shouldn't look as weird.

How do you do P2P? There needs to be an intermediate. You can't just ask the rider to open up some port. They need to subscribe to a channel they both can communicate over, so we are back to the server owned by Uber / Lyft. But I don't think this matters to end-users. As a frequent user, I only care whether the car will arrive on time and whether it is on the opposite side of where I am waiting...

Server can be initial handshake initiator and then p2p can take over. Webrtc already does this.

From talking to an uber engineer, he said that it's not fake, it's just delayed.

In my experience, I'd suggest it's delayed something like a month or two...

(Not that I've got a dog in the fight any more, don't forget today's the day to delete Uber!)

Why would they display a month old data on your home screen? Either it's realtime/delayed by a small amount of time or it's fake.

He told me it was more like 30 seconds.

If you think it's real, go to a big open space where you can see lots of empty roads, and turn it on.

Honestly I think they should do something combining the linear interpolation between data points with acceptance of the delay. Just animate between consecutive received data points, and for the first 15 seconds, replace the car with some animated sprite that visually suggests "your driver is here and is starting to come get you, even though this sprite is staying in the same place".

Thought: the customer's app probably has access to the accelerometers in the phone - maybe use that to trigger the animation of the driver moving off (the assumption that he starts moving in the same direction as he arrived would probably be "good enough". I suspect there's likely to be some reasonable numbers to use as an estimation of how quickly to animate the movement on the map based on accelerometer data and basic assumptions/measurements of how quickly drivers typically move away from a pickup.

Are you completely sure that it is fake?

Reply on news.ycombinator.com