Jump to content
  • Advertisement

Nantuk

Member
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Nantuk

  • Rank
    Newbie

Personal Information

  • Interests
    Business
    Design
    Production
    Programming
  1. Thanks for all the info on Quake 3. That sounds like good advice, I should take a look at Quake 3 to see how they did what they did.
  2. Thats fair, I guess it really depends on the game. Its probably time for me to jump feet first in and see what is best for me. I'll start with the simulating the client ahead of the server method, and build off of that. Thanks for all your help!
  3. Thanks for the reply, this helps a lot. I think the simulation is pretty close to 100% deterministic, but I will for sure regularly correct player movement. I think to do otherwise would be asking for de-syncing trouble. Discarding old packets in method 2 makes sense, and assuming the last input is sustained for the future also makes sense. I was not aware that Valve's Source Engine did rewinding for late arriving input on the server (method 1). I have read that it does a sort of rewind in order to see if a player's ray-cast bullet hit anything (outlined in link1, and link 2), but nothing on the topic of the server rewinding the entire simulation for something like a player's movement input. I know the client basically does this, for locally predicting the input, but should the server? I really want to clarify this, because before I go implementing a globally rewindable server, I want to ensure it is a good strategy to do so. I see that GGPO does this, but it would typically be between 2 players. I plan on supporting upwards of 16-32 player. In your opinion, is allowing the server to rewind to account for late movement input packets generally recommendable?
  4. Hello Game Dev! Sorry if I'm beating a dead horse with this thread, but I'm making a fast paced action networked game, and I'm having trouble wrapping my head around some things. Namely, how should the server handle ticking player input packets that arrive at the server at an incorrect simulation steps, as a result of network lag, lag jitter, and inevitably imperfect time synchronization algorithms. I'll start by outlining my understandings, and I would be eternally grateful to anyone who can shed some light on what I'm missing. For the sake of simplicity, I'm assuming the client has synchronized to the server's clock in some respect, and bundles a "suggested simulation step" that the input ought to be executed on by the server. I've read a few threads here, and a lot of the documentation that exists out there. As far as I can tell, there are 2 main methods to rectify inputs arriving at the server at incorrect times: method 1. allow the server to rewind time and re simulate the game for late arriving input packets. This would allow late inputs to still have a chance of being simulated. The server would only allow rewinding to some maximum amount of time, to help curb cheating, and undesirably large jumps in the simulation for other players. method 2. synchronize the client's clock forward of the server's clock by half of round trip time (RTT/2), plus some constant (c) to account for jitter in lag. So in total, (RTT/2) + c. Then, when the input arrives at the server, it arrives on time most of the time. If the input arrives earlier than it needs to, it can be buffered at the server until the appropriate simulation step to execute the input. As far as I can tell, method 1 has the benefit of minimizing any sort of input buffering for players with good pings, but is a very heavy handed solution, and might cause frequent jumps in a given client's simulation. Method 2 seems to be a nice simple solution, would provide nice smooth simulation, but introduces a sizable lag for a given player's input to be seen by other players. I suppose I have 3 main questions on this topic, and I would be a very happy boy if I could get some help on them: 1. Is method 1 a widely used approach? It seems like it introduces a massive amount of work, as a result of the server and clients having to correct their simulation state, all the while introducing potentially jittery movement. 2. I get that method 2 can buffer early input packets, but how does it account for late arriving input packets? I get that the server should acknowledge the late input packet in some way to let the client know it should adjust its simulation time, but would it drop that late arrived input? would it execute it, but at the CURRENT frame? What if there are 2 or more late inputs? 3. Am I missing any other solution? Are these 2 methods the widely used methods for handling state and input on the server? I can imagine a combination solution of method 1 and method 2, is this advisable? Thanks in advance for all of your time! I feel very stuck on this, and will send all the karma your way for any help. In the mean time, I'll keep reading forum posts, to see if this has come up before. *edit* wording.
  • 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!