Problems with Lag and Object Persistence in Multiplayer Plugin

First off, lag/latency is something that is going to exist and is not physically possible to get rid of. Designing for multiplayer and net code are about how to manage and hide it from each peer and host.

Local input prediction is one part of it on the peer side. An input from the peer will take time to be sent to the host and more time for the host to update the peer with what happened as a result of the input. The result is when a peer does something, nothing visually gets updated locally until that communication completes. Local input prediction hides this lag by allowing the peer's objects to update and move immediately upon inputs, and gradually correcting the position after receiving what actually happened on the host from the host.

Reducing client delay isn't always a good thing - it's a lag management system on the host side. The client delay allows for a buffer time for the host to receive inputs from peer, because it takes time for peer inputs to be sent to the host, and also more importantly because latency is not a stable, set amount - it changes all the time. The client delay is how long the host has to collect actual received inputs from peers before updating the game. If the client delay is exceeded by lag, that means the host has to guess (interpolate, another lag management feature) at what the peer actually sent. When the guess and the actual input are different, you'll have a desync and correction = visible rubber banding and lag. It's often preferrable to wait for the actual input when possible to prevent desync. TLDR: what this means in the end is that you want your client delay to be at least longer than the time it takes for the host to receive each input from the peers, or even better the last two inputs from the peers so there's an extra buffer/backup time, because as I mentioned before latency changes constantly. (For more detail regarding timing, note that ping ms is actually the round trip time, so only half of that one way, and also don't forget to add in the maximum time between client input updates, which don't occur every tick.

Regarding your "offline" disc accessories, assuming you mean those are not synced and displayed locally for each peer and host (which is the correct choice if they have no direct involvement in gameplay logic), it's a simple matter of positioning them when and where you want them on all peers and the host. Because they don't need to be communicated across the network, it is impossible for them to "lag". If you have them set to the disc position locally every tick, it will be at the discs visible position every tick.

The type of multiplayer (PvP, Co-op or both) significantly influences how you should design your network architecture.

Co-op Gameplay

For co-op games, you can prioritize a smoother experience by allowing player-authoritative movement control instead of sending inputs to a server for validation. This approach reduces input delay and completely eliminates rubber banding for the controlling player's character. However, this comes with the trade-off of increased vulnerability to cheating since the server does not enforce strict authoritative decisions. But you can still mitigate cheating with periodic server-side sanity checks if needed.

PvP Gameplay

PvP games demand a stricter balance between responsiveness and fairness. Using input prediction can minimize the perceived delay for players but may introduce rubber banding if inaccuracies occur due to latency discrepancies. The challenges are more pronounced when:

• Players interact with shared objects, like a ball(or disc in your case?!) in a "soccer" game. Here, discrepancies in latency mean each player effectively operates in slightly different past states of the game.
• Without robust client-side prediction for actions like shooting or kicking, noticeable delays can occur. On the other hand, over-reliance on prediction can cause jarring corrections, such as mid-air direction changes for a ball when the server updates its position.

To address these issues in PvP

• Server-Side Buffers: Maintain a buffer of recent game states and allow clients to send their inputs with timestamps. The server processes these inputs by replaying the buffered state closest to the client’s perspective. (rewinding time to the scenario the player was facing at the time)
• Client-Side Interpolation: Instead of rendering server positions directly, clients interpolate positions over time. This smooths out sudden corrections.
• Input Prediction: Allow clients to predict their own actions (moving/shooting/kicking) while the server maintains ultimate authority. The server sends corrections that you will have to hide as good as possible without being disruptive.

Ultimately, the optimal approach depends on your game's specific requirements.

So it's up to you to find the right balance between responsivness, accuracy and fairness. In any scenario you will have to try to hide the time-offset as good as possible. And possibly even prevent players from joining if their ping is so high that it would influence other players gameplay.

The solutions described above are already provided by the multiplayer plugin. And described in more detail here: https://www.construct.net/en/courses/online-multiplayer-construct-12 However, if you feel it doesn’t offer you enough control, you can develop your own implementations to better suit your needs. ( for example: still using the multiplayer plugin, but not relying on the automated interpolation from the "sync" feature )

For co-op gameplay scenarios i offer a paid beginner and more advanced template in Construct's Asset Store (with a demo). They can give you a clear idea of how such setups might look in action.https://www.construct.net/en/users/92570/everade/asset-store