Jump to content
  • Advertisement

GBN

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

1 Neutral

About GBN

  • Rank
    Newbie

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    Production
    Programming
    QA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I actually found a post on here that may shed some light on some of my confusion I will study this and see where it goes. Thank you
  2. I am trying to make something fast paced with precise collisions and a similar feeling to Stick Fight. I do not have enough experience to visualize and know what the correct answer for something like this is. So even when physics is non-deterministic corrections can be applied and still make for a smooth experience? I am struggling to understand the process and picture the flow chart of making corrections feel smooth if they need to happen often.
  3. Hello everyone! Recently I have been beating my head against the wall trying implement and learn more about client-side prediction with rigidbodies in Godot and I have a few concerns on how I should be approaching this. Is client side prediction impossible if physics is non-deterministic? I assume this to be true if we cannot predict the SAME exact outcome from every action. Are rigid bodies in engines such as Godot and Unity something to avoid when trying to synchronize games over the network? I did some research on this and found some older posts from the past 5 years or so recommending against using Unity's built-in physics due to it not being deterministic, I am wondering if it is the same with Godot or not. Regardless of the above, at this point I would assume coding the physics myself would be a lot easier and provide a lot more certainty when troubleshooting synchronization problems over the network. I feel like I have made a fundamental error in using rigidbodies and would really appreciate any feedback on this. Thanks a bunch in advance!
  4. That was a PERFECT analogy for understanding this better. That makes sense. So if the server is behind and thus gives players nothing recent to correct their position with I imagine this is where jitter would occur, even with interpolation. Thanks again for your responses.
  5. Hey Matias, Thank you so much for clearing that up and for the tip on that article in the web archive. I did not notice the inconsistencies of the smaller cubes, only the consistency of the larger one. There was no reference to client side prediction so I had assumed the only thing that had changed between his previous simulation was the input buffer. It is an action game taking inspiration from Stick Fight and as of right now I have snapshot interpolation implemented (un-optimized). I am currently trying to learn and work through all of my problems as they come along. It seemed that the input buffer would be needed regardless, and probably even a snapshot buffer for the same reasoning? So the server would have to process twice as fast as the information it receives? I will do more research on this rather than bombard you with more questions now that I have proper direction. My initial goal was to try and get both simulations as close to matching as possible but I was just looking at the wrong solution for that. Time to learn about extrapolation it seems! Thank you again for the response, very helpful.
  6. Hello everyone, I am fairly new to programming and gamedev having only just started at the beginning of this year. My goal is to make a multiplayer physics platformer. One of the videos I have watched over and over is the GDC - Networking for Physics Programmers by Glenn Fiedler. Even after doing so I just cannot seem to fully grasp the concept and result of input buffering. When a client sends input to the server for the server to run the physics simulation, if we implement a buffer on the server for lets say 100ms will this not add to the delay between what we see on client and server? If it takes 50ms for the server to receive input from the client and then the server buffers it for another 100ms will that not bring the rendering of what the server and what the client sees further apart? I feel like I am misunderstanding something because 6 minutes in or so Glenn shows his simulation after implementation of input buffering and the outcome is the opposite of what I would think it would be, it is almost identical on both ends even with UDP 250ms round trip and 25% packet loss. I would think that input buffering only solves jittering and the delay between client and server simulation is resolved by client-side prediction, am I wrong on this? Thank you in advance!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!