Client Side Prediction

http://secondlife.com/vote/index.php?get_id=739

Has client side prediction been discussed before?

It seems like every network action-based game (FPS's, racing games, etc) all use client-side prediction. Why doesn't SL?

I'd like to see client-side processing of the avatar and the vehicle the avatar is riding (basically, whenever controls are attached.) This would fix most of the problems with vehicles and avatar motion, since in essense, the client would do the processing instantly and shove the updated coordinate data back to the server.

I know there would be some issues: what happens when two avatar-objects collide, for example? But those wouldn't be any worse than similar issues now, and the gains would be well worth it.

What do you guys think?

I could be wrong, but I think SL already does this - or did this. And that's why vehicles would seem to drive on for 100's of meters, through bridges, through buildings, through land... only to snap back at the point which they lost connection or lagged with the server. The client would take the current trajectory and assume the vehicle was still moving, in a straight line usually, until a corrected coordinate could be received from the server.

What DoteDote said. The client sorta already does this, just not as well as it arguably should.

Pretty easy to see that it does, too. When you lose connection with the sim, your avatar keeps going.

yea, boring but good indication really easy to see when my net is laggy

then we need IMPROVED prediction.

The straight-line thing is really just interpolation, which is different than prediction.

Interpolation is: My client FPS is 40, but I'm only getting 20 updates/sec from the server. So the client calculates the "in-between" frames and puts moving objects where they would go if they continued at the same rate they were moving.

This is not what I'm talking about with CSP.

CSP involves having the same basic physics engine on the client that is on the server. The client would process the same information the server is processing and update the display as fast as the computer could handle it. In fact, there's no reason that the client couldn't calculate its own physics and tell the server where the client's avatar is and what it's doing - exactly the opposite of what's happening right now.

This would mean that the client would also have to process LSL scripts in parallel with the server... thinking about this, this would be a good thing for performance. Attachments and vehicle scripts would always run as fast as possible, and they would not affect anybody else's performance.

This would also improve server performance: with no need to process physics, time dialation would basically go away. The only bottleneck then would be bandwidth, and if all the sims already share the same bandwidth, we could probably fit a few hundred avatars on one sim, instead of only 30 or so.


The "trigger" to move physics and script execution to the client could be the attach event or the take controls event.. either function could move LSL execution and physics processing to the client.

I created a proposition

http://secondlife.com/vote/index.php?get_id=739