-
Notifications
You must be signed in to change notification settings - Fork 61
Websocket Prediction Spike #1220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
This is an intended behavior that preserves network traffic and reduces computing costs. It's a minor benefit, but keep in mind you won't see the ghost during gameplay and it won't actually affect anything. This is because as soon as any motion or collision occurs, the steady state has been interrupted, and the server who owns the authoritative "correct" position can issue a snap correction if the client's slight offset results in a largely different collision (all of which occurs in ~3 frames, not noticeable). |
Chorus detected one or more security issues with this pull request. See the Checks tab for more details. As a reminder, please follow the secure code review process as part of the Secure Coding Non-Negotiable requirement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this model seems like a pretty solid proof of concept, and the websocket style seems to work pretty well. Hard to say how it scales right now though but concept proven
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solid proof of concept, certainly happy with this. Will move to schedule a meeting once we have everything for multiplayer testing done so that we can plan what arch we want to go with.
Client-Side Prediction Spike: Fast Input/Visual with Server Correction
This PR contains multiple elements:
/client-prediction-spike
containing a client-side prediction system that meets the spike requirements as specified by the ticketTest Stack
Included is a client-side prediction system that shows how to improve input responsiveness while keeping server authority. The client immediately applies movement using physics when inputs are received, while the server calculates the same positions and validates and corrects the predictions when they diverge from the server's decision. The client and server are essentially doing the same thing, but now the client's job is to make the game more responsive, and the server's job is to prove and validate the client action.
The spike server features:
The spike client features:
This spike does not feature:
Quick Setup
Prerequisites:
Installation
cd client-prediction-spike npm install
Run
The server will start on port
3000
by defaultIndependent Tests
To verify the functionality, carry out the following tests:
Prediction Responsiveness
Correction Behavior
Network-Distrust
Measured Metrics
All metrics observed on Windows with 100ms artificially spoofed ping
Latency
Corrections
Performance
Based on these metrics, client-side prediction provides big ux improvements with little cost. The correction behavior is almost entirely unnoticable on moderate networks.
Integration into Fission
These are thrown together code fragments that could serve as a basis for hooking this implementation into Synthesis.
Prediction System Integration
The multiplayer system should be extended to support client-side prediction:
Physics Integration with Prediction
Extend the physics to support prediction (we r cooked):
Input System Integration
Modify the input system to support sequence numbering:
Global Configuration Changes
Dependencies
Modifications to
package,json
:Build Configuration
Modifications to
vite.config.ts
:Environment Configuration
Add prediction settings to environment configs:
Considerations and Optimizations
Beyond the missing features, these are things that should probably be implemented before predictive multiplayer goes public.
Performance Optimizations
Production
This concludes the Spike PR.
Do not merge
.