Jump to content
  • Advertisement

Synergi

Member
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

108 Neutral

About Synergi

  • Rank
    Newbie
  1. I need an example timeline where you show what happens on the client and server as I don't exactly know what you mean? 
  2. Ok to nail this down, I was doing a lot of research about this topic and didn't find a proper solution. So I designed a mix of both and I share this with you: 1) We use both techniques Rewinding and Correction 2) We mix them in a very clever way Rewinding has the negative of becoming unfair to other clients if rewinded to far Prediction can be always wrong if no rewinding is applied. So both systems have a negative. But we can remove them mostly when mixing them cleverly. When dealing with such systems you normally have a snapshot interpolation system on the clients to render the world in past for lag compensation. This gives us also other possibilities. Normally you delay the past for 100ms (depends on your Snapshot rate 100ms delay = 20/s) We can use this 100ms delay. So we have to set the following rules for our system: 1) If a package arrives and the timestamp is only <50 ms behind we can rewind and resend the state to the clients 2) If a package arrives and the timestamp is > 50ms && < 100ms we can rewind the last state and assume the client is moving since 100ms so we rewind the previous state to have actually moved 50ms and the next is going to be also 50ms moved. Then we resend the previous state 3) If a package arrives and the timestamp is > 100ms we have to correct on the client for the amount Above 100ms. So we combine rule 2 with a correction on the client above 2. 4) The resend states are marked as a resend so they are special states 5) If a client has a action that needs hit detection on the server as an example he sends the stateID with it. If on the server the state was already corrected but as the Client sent the non corrected state we do the collision against the non corrected one to be fair as the other client hasn't received the corrected state. With these rules we can ensure that our prediction system is 100% correct if delay is <100ms and if we have a delay above 100ms we only have to correct the amount above 100ms. and here we can decide between snapping and interpolation corresponding to amount we are off. Lets say we are only on 110ms delay we could interpolate the last 10ms but if we are on 200ms delay we would snap. I think the system I created is very well. If you find something that is better of not logic please tell me.
  3. Ok I think the best approach currently is to rewind on the server to the time of press and inside the package the client sends to the server containing the timestamp to rewind to, I simply crypt this area of the message or something like that. I can't find any other solution other then rewinding on the Server. 
  4. BTW thank you for spending your time to help, I'm just so frustrated that I don't find a solution that I may sound rude x) sr if so
  5. This sounds wonderful with rewinding on the server to the synced timestamp. I did think about this before I tried to go full authorative. But this could be so easily hijacked from a hacker. As an example have 2 characters Race a given distance. The Hacker could now hijack the timestamp of the package and just instead of saying it was at 500 could change it to 450. Now the Server rewinds to 450 and lets the hacker run 50 ms earlier then the other. The hacker will always win. On games like RocketLeague or Smite where you have a Grand Prize of 100k I simply don't believe that their system would be that easy to hijack. I totally understand that such knowledge on howto properly solve such a problem isn't spreaded like the standard authoritative concepts, but there has to be a website that demonstrates how it is done. That is the internet x)
  6. That's probably less common of a situation than you might think. Round-trip latency tends to be pretty constant over short timescales.     So you would say, that if I compare the Snapshot from the Server with the Snapshot the client if the difference delta is less then sigma I Ignore the difference and let my prediction be correct? Or do I correct always and live with a really terrible prediction system? I mean please do not misunderstand me. But when you check games like RocketLeague or Smite they have a fast paces 3d enviromet. How do they do such things?
  7. Ok I can understand the concept of if a package arrives really late I could still give the Client a chance to accept this package by rewinding on the server a bit.  But how would you take care of packages being sent to the server with a slightly different delay like lets say Client -> MoveForward -> 500MS (ping 50ms) Server -> MoveForward ACK -> 550ms Client -> Sprint -> 550ms (ping 55ms) Server -> Sprint ACK -> 605 So the Client thinks he is walinking 50ms and then sprinting but on the server he is walking 55ms and then sprinting? I mean I could always slowly interpolate back to the correct state, but pls don't misunderstand me, why should I predict something that I know will be wrong? x)
  8.   Wouldn't this approach destroy the authoritative idea of a server? I mean the client could force a high latency to have the advantage of seeing the past and reacting to it with a rewind on the server. Wouldn't that be a possible attack for cheaters?
  9. Hello GameDev Community, this is the first time, I look forward on contacting you for help, but I really need you as I'm currently totally stuck. Not a single Tutorial Like GafferGames, MPDev, ... was able to explain me what I'm doing wrong and I'm currently really stuck. The issue I currently face is quite obvious, I know for sure in beforehand that my client side prediction is for 100% wrong. But I need to do it do simulate zero latency for the user. But in the end it is wrong and I have to correct the user. So yeah I'm completely stuck. Something in my network design is really bad to not properly fit Client Side Prediction. In the game engine I use (and mostly every other game engine), movement is explained in a given speed * time. So let's say Speed is something like 5m/s. So Entities move at an amount that is dependent on the time and speed. The time is very important as this is also a realtime 3D game. I read most of the good tutorials out there in the wild internet about good authoritative networking but I can't spin my head around client side prediction and server concealment. Please don't misunderstand me, I know for sure that this is needed to simulate zero latency and also ignore the RTT for the change to upon based upon the Input. But: Every Input that triggers an Action that is depending on the previous one (which are most) will be wrong predicted. Let me explain this with an example: Server runs at 10 Ticks per Second. So in between each SnapShot is a delay of 100MS. Let's say the client currently interpolates in between the states 500ms and 600ms. The RTT is 100ms so the ping is 50ms. So as we interpolate on the client side in between 500-600 Snapshot the server is on 650ms. Now the client sends the button press "W" that triggers the movement forward action. This arrives at the server at 700ms. The client will start running at server time 650ms. The server sends back the ACK of this action with the server time 700ms as this is where the server marks the character to run. Now the client can mark the 700ms world state he will receive with his 650ms Snapshot of his position to now if the predicted state is correct. Now the client send at 700ms the action "SPRINT" to the server. This triggers double speed. This time the package of the input to server takes not 50ms instead it takes 100ms to arrive. so the Server will send an ACK with 800ms. So to summarize:   Client -> 650ms MoveForward -> Server -> ACK @ 700ms (Ping 50ms) Client -> 700ms Sprint -> Server -> ACK @ 800ms (Ping 100ms) So on the clients predicted state we run for 50 ms and then sprint. But on the server state we run for 100ms and then sprint. This example is just blown up. For a real world scenario this would be more like the ping is 50ms then 55ms then 48ms. So every time the latency jumps around and is never the same. Knowing this, I know for sure, that my predicted states will be 100% wrong. I will have to correct them. So what am I missing here that I can't wrap my head around this? Most authoritative game has a client side prediction as the latency would be too noticeable. But it can't be that they always correct the predicted state. In fact a good prediction system has the least correction amount. So please help me to see what I miss x)
  • 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!