How To Do Client Prediction [Unity Tutorial/C#]
Вставка
- Опубліковано 19 чер 2024
- Welcome to this Unity Tutorial where we go over Determinism, Fixed Tick Rate, Client Prediction, and Server Reconciliation. Deterministic Programs and Fixed Tick Rate are more theory but really important to understand in order to implement Client Prediction & Server Reconciliation. I then go into how to code Client Prediction & Server Reconciliation in C#.
This code can be adapted with Mirror Networking, MLAPI (Unity's Multiplayer Networking Solution), or any custom networking solution as I tried to make it generic.
The code can be found on GitHub github.com/Ajackster/ClientPr...
Feel free to leave a comment if you have questions and I'll get back to them ASAP. Love you homies.
0:00 Welcome
0:17 What is Client Prediction?
0:34 What is Server Reconciliation?
1:01 What is Determinism?
2:02 How To Solve For Time When Doing Client Prediction?
2:52 How To Implement Fixed Tick Rate
4:11 How To Implement Client Prediction
9:26 How To Implement Server Reconciliation
10:56 All Done! - Наука та технологія
BUG FIX: If you are getting an "Outside Bounds Of Array" error In the HandleServerReconciliation function - there is a bug in the code I wrote. You have to use bufferIndex for the inputBuffer array, rather than just the tickToProcess. I updated the code on Github with the fix (link in description)
This is the best tutorial for this stuff on the site, hands down. To get this up and running so quickly is AWESOME!
This is so far the best tutorial I have ever seen to understand how actually internally ticks and prediction works! Thanks for making the code super simple and clear explanation! Subscribed!
Thank you soooooo much!!!!! I've been struggling to figure this out for so long and I finally got it because of you! I had no idea I couldn't use fixed update to keep my ticks and now that I changed it I finally have something working. You helped so much and I can't wait to see what videos you make next!
Awesome so glad to hear :)
You should be able to just use FixedUpdate though. It is actually doing something similar as what @Ajackster is doing for the loop. Multiple fixed updates can happen in a single "frame". Each fixed update will have the exact delta time you can change in the settings. If you check the actual time, you'll see that the times these updates are ran, are not spaced exactly delta time apart, but for physic simulations it doesn't matter, as long as it's ran the exact number of times it should have ran since the last frame, so enough simulations are being processed. No idea why it's stated in the video that fixed update should not be used for this.
Thank you very much. You have been very helpful in a very important matter. I haven't seen many people helping with such specific issues.
Just wanted to thank you for this, many articles and such explaining the what and how but not the why. I appreciate the time you took to make this :)
I’m glad it helped and makes things more clear :)
Very very cool video. I loved your style of little by little showing the code and describing the purpose of each variable.
I'm glad you enjoyed :)
I got same info, just a bit detailed, from a books, but this video actually explains everything you have to know to understand a whole logic of CSP. Very recommended video for everyone that still has no clue how it works.
Great vid man. Was super easy to follow, thanks for going into so much detail about how the fixed tick rate works.
Thanks! I'm glad it was helpful :)
Thanks for the vid! I was definitely feeling in need of some inspiration for this part of my project.
Keep in mind that if you simply "drain the entire input queue" on the server every tick, the client can trivially speed hack by sending extra input packets.
To prevent this, you should roll up inputs on the clients side and only send 1 rolled up input per tick (though you usually send the last N rolled up inputs for redundancy to defend against packet loss), along with a sequence number.
Then, on the server, only process a single sequence number worth of input. If the next sequence number you expected isn't available in the server-side input buffer for that client, it means some packets were lost, and you can either repeat the last known inputs for this tick, or simply process tick as if there were no inputs (though this should be very unlikely if you are sending the last N inputs in each packet, and probably means the client has DC'd).
dude, i think that is what's happening to mine. the client is so fast than in server. Can you give a little more detail about this?
what does it mean when you say to "roll up"?
Thank you so much sir. It was such a usewful video!
This was precisely what I needed. thank you so much!
Unity examples: "here is how we bang rocks together"
@Ajackster: "here is how we implement some of the most crucial gaming concepts in an understandable way"
Very high quality video man!
Thank you that means a lot! :)
YOU ARE AMAZING DUDE THANK YOU SO MUCH
thank you very much for the tutorial, I was in need of this, soon I will test it! +1 subscriber :)
Awesome! Let me know the results
That is really good and advanced video
damn bro this is exactly what i needed!
Would be wonderful if you could have covered networked physics because there's practically no videos on that topic, and you also explain everything very well
Hey Foxyz! Networking physics would be similar to this - the thing you'd really have to work with is using a deterministic physics engine. Unity's physics system is not deterministic so you'd have to find another solution. I felt like overhauling the physics engine in Unity seemed like a lot for this particular video. Perhaps in the future I'll make one.
In the meantime, Rocket League (networks physics for competitive play) did a lecture at GDC a couple years ago explaining in detail how they did a lot of things. If you're interested in the subject, I highly recommend watching the lecture.
And thank you for the compliment :)
8:32
HandleTick method should be redone. if the client sends commands too often (during speedhack or duplicating packets) on the server side the player will move very fast like in hl1 or cs 1.6, I solved this problem by buffering client commands and executing them at the time of 1 tick execution, but because client ping is not constant; commands from the buffer will be executed quickly or slowly. the client will simulate movements faster than the server, so it is necessary to execute several commands per tick, this method increases performance and is safe. the buffer can be limited by the maximum number of ticks per second
Do you mind showing your code for this? i discovered the same issue today by accident and am thinking through a fix.
Isn't that Michael from Peaky Blinders. I didn't know he is giving programming tutorials! Thanks Michael xD
I'm having an issue in the HandleReconcile function. Inside the while loop when I try to Process movement, the tickToProcess is outside the bounds of the array. I assume I've missed a "% BUFFERSIZE" somewhere but I'm not certain. Any chance you could lend a hand?
Sure thing - do you have a code gist where I can take a look at your HandleReconcile function?
The culprit could be different things so tough to say but assuming the code is replicating what I have here github.com/Ajackster/ClientPredictionTutorial/blob/master/Assets/Scripts/Client.cs#L112 - it could be a problem with the data the server is sending to the client (maybe latestServerState.tick is a bad #?) but hard to say.
Feel free to put code here or if you want my Discord is Ajackster#2382 can also send me code there
Hello there, what are you up to?
Nice implementation! I must say it's clever! Do plan on making some ticking system?
Thanks! :)
Not sure if I'm understanding question correctly but I made some fixed tick code for the tutorial
Hey Ajackster. The tutorial has been super helpful so far, I'm using it to implement into a rollback system for my 2D game. However, I've run into a problem with the reconciliation part. I'm using a physics based movement controller, and I keep getting rubberbanding / stuttering with Reconciliation on almost every frame, regardless of similarities in simulations. I've tried increasing the position error comparison value but still get sharp corrections that feel bad to play with. How can I fix this?
Thanks!
No problem!
Hey! So im currently at a Point where i do the Client Prediciton and dont send it to the Server or anything like this. When i move my Player (using character controller) my objects in the scene jitter a little bit. They jitter depending on the Tick Rate (higher less jitter) is this because the player is moving and the renderer catches up?
Thoughts on keeping client just ahead of server? Sudden tick adjustments? Or varying timescale to increase or decrease the clients current tick?
Having trouble making my own solution.
I just realized that there should be two reconciliation sections. There is the server state and client state that need to be in sync and the server should have authority. However isn't there a second piece the client input and the server input and the client should have authority. The server input would be driven by some predictive model of player behavior. If there are these two reconciliation steps which step should go first?
I'm just thinking out loud now, but essentially the issue I'm trying to solve is the time it takes for inputs to get to the server. Without server side client input prediction, the player will experience some jarring movement.
I tried it using Mirror and it worked, got a few question though, if I have a skill that changes the position, for example a blink skill, and with a laggy network condition, the client's position would be different from the server's position, reconciliation will not be able to solve this, as they will end up in a different position, what are you suggestion? should I just reset the currentTick and dequeue all input, and force server's position to client before blinking? or is there another way?
Hi Ajackster, found your channel few days ago.
Nice style of videos! I predict you can be a big channel some time in the future.
I got a few questions:
1. Which tool do you use to edit your Videos? and put the effekts in like the clock etc...?
2. Have you heard of newly created UNITY RiptideNetworking from TomWeiland (another youtuber)?
For me as a beginner his RiptideNetwork is much more easier to understand and use, than the build in unity network.
Also he has a very nice discord with lots of unity and other programmers.
I reached a state where i maybe need some client prediction and server reconciliation... that was when i found you channel.
Greetings from Germany!
Hey thanks for the kind comments and the questions!
1.) I use Adobe Premiere Pro to edit my videos, for the clock effect specifically I just used a clock stock video with a green screen background and used an effect called “Ultra Key” to remove the green.
2.) I have heard of it through his vids but haven’t tried it yet. In the current state of networking libraries for unity I personally think Mirror is the best but will need to try Riptide also to get a better opinion. The new built-in Unity one seems too new and buggy atm.
I’m glad you enjoyed the vid! Feel free to ask any other questions you may have and I’ll do my best to answer :)
@@Ajackster riptide best trust me
@@barj I'll have to try it out
p.s. nice to see you here - your latest vid is actually the inspiration for the vid I'm working on rn :)
I have implemented everything mentioned in the video, but I still have an issue, because I am using a rigidbody-based controller, the inputs are processed at the same time the reconciliation is done. This causes jittering. How do I fix this?
So we'll explained!
So do multiplayer first person shooters use a fixed tick rate? Wouldn't that make the client feel locked at say - 60hz - when a client could theoretically run at 240hz with a good monitor and gpu? If the fixed tick rate still applies in that situation, how do you keep it while still gathering client inputs at the faster rate?
Am I right to say this wouldn't work with Unity's physics since it isn't deterministic? Or will this still work but with some glitches when it attempts to predict* and warp the object back because of the non deterministic physics?
thank you
Good tutorial one comment. About 8 - 10 years ago i was taught that modulo was the slowest operation followed by divide. It may have changed a bit as processor add new instructions sets. But i suspect it may still be a bit slow. (Dont have time to look it up but you night want to check )
Thanks :) Interesting, it seems like yes that still is the case I didn't know. AFAIK and it isn't much of a problem for this use case.
If it did become a problem I'd have to look into different way of implementing the buffers but doesn't seem to be affecting performance.
This will have the player's input latency depend on tick rate, right?
Wouldn't that be a bit problematic for responsiveness? A player playing on a 144hz monitor, will always have tick rate input latency.
Can that be mitigated by maybe recording all inputs between ticks, predicting and sending them all?
Thanks man. It helped me a lot to implement client prediction to my project. However, I have jittery movement on the client side. I assume that is coming from when client simulate physics with the current input and reconciling at the same time. Is there any solution to fix this? Or any idea why this happens?
Are you using it with Photon?
Hi, thanks so much for this video! I have a question: if we are only sampling the user input on each tick, wouldn't this result in the user input feeling laggy when the tick rate is lower than the frame rate? Like if the tick rate is 30 and the user is playing at 60fps, wouldn't their character only move every other frame? Do you have any good techniques for dealing with this issue beyond just increasing the tick rate?
Hey! Wow good point - the current method presented does not address this problem.
From a game design perspective you could maybe have some animation or something take place immediately and then move the character next frame. If the tick rate is 30 that means at most it should take 33 ms to start actually moving so it could just be part of the game.
For a legit technical solution - I’d have to do more experimentation. Just off the top of my head I’m wondering if you could just start moving the player immediately after receiving input and start the tick system on the client after receiving input. Then the server receives input tick for specific client and does its update in it’s tick system. The client and server tick system wouldn’t necessarily be in sync anymore so you’d run into another problem with state being synced (would probably have to reconcile.)
Or maybe something where client calculates how much it has until next tick and moves correct amount and reports how much time client has until next tick to server so that server could use that deltaTime to calculate updated state but server would have to use some max deltaTime since it could theoretically be vulnerable to cheats.
Idk really rough ideas would have to experiment.
@@Ajackster thanks for getting back to me, since I left the first comment I've experimented with a few different methods, and what I've ended up with works pretty well for me.
I have two different tick rates, a server side tick rate, which determines how often game snapshots are sent to the client and a client side 'tick rate', which is much faster, and sends the user input to the server on this tick.
Since user input data is a significantly smaller packet, for me it's about 12 bytes, we can get away with sending them much more frequently, I send them on every frame without any issues.
Since we send these inputs much more frequently on the client side, it resolves the user input issue rather nicely, and let's me have really smooth user input on a server that only sends snapshots 10 times per second!
You can find out a bit more about this approach on the Unity youtube channel, the video is called "Deep Dive into networking for Unity's FPS Sample game"
@@Airyz hey! I have the same issue with my game, can you please elaborate more on how you fixed it? :)
@@McBlueskai sure, was there any part in particular that was confusing to you?
@@Airyz yes, how do you resolve the input from the client if the tick rate is different? (lets say your client's tick rate is 60 ticks per second and the server is lets say 30). I am trying to understand it but can't get my head around it 😅
Is this same concept being used by Photon Fusion?
What about implementing hit-detection with ray cast and etc?
Hey I noticed that currentTick is only ever increasing. Would this cause any issues if a game is ran for too long? Great video!
It shouldn’t be a problem. The circular array should always go back after you reach the buffer size and for your currentTick to get to max int or uint, your game would have to be running for thousands of hours for the tick rate.
You could calculate how long but if you’re using uint for currentTick I calculate it’d take almost 20,000 hours of consistent ticks at 60 fps to reach max uint.
At that point you most likely will have other issues where you need to restart server (servers are generally rebooted with new builds etc. every week or so), or if you really want to you could just reset the tick rate at a certain point.
Glad you enjoyed :)
Why should I multiply my movement by min time between ticks rather than delta time? Surely you still need to take delta time into consideration? Sorry - I just can't get my head around how this works - could someone explain it to me?
How to make sure that tick rate wont get out of sync? Server could be overloaded with work and it wont tick at specified rate.
So how would determinism work in the event a player casts a spell? Unlike moving, this would be an action that may or may not fail. Does the client decide if it is successful first? Then if it is, predict the spell animation and send that input to the server for processing? Would this make the client authoritative? Or maybe I'm overthinking it and it's just like movement. In any case, what would be the ideal route to take for these types of actions where there are many factors for success? Randomness is nondeterministic. Thanks for your video!
Spell failure would happen on the server. There's no need to predict it.
I assume you mean you would have a random chance the spell succeeds or fails? You could use a seeded random value and make sure the server and client use the same seed.
hello thank you so much for this! Already been loving your vids! anyways, i tried this on a dedicated server architecture and i dont know why but the player on client is faster than the player in server. why is that?
Are you using Time.deltaTime instead of minTimeBetweenTicks?
What about collisions with other objects that have been mispredicted as well?
Thank you for this awesome tutorial, It was great but you didn't talk about syncing server and client ticks. this is a huge problem and if the server tick is bigger than the client tick it causes lots of problems when we're doing reconciliation. How we can fix that?
When the client connects, send your current time to the server. Then have the server respond with both the client time it received and its current time. When the client receives that packet, you can calculate the RTT (round-trip time) as the packet.client_time - client.now(). If you then add 1/2 of that RTT to packet.server_time, you'll get a pretty good estimate of what time it is on the server right now.
This sync will be good forever unless your RTT changes significantly, in which case you may want to re-calculate the server time with your newer 1/2 RTT, but on most stable connections the variance will be small enough that this isn't necessary.
Good tutorial on Client Prediction!!
But I believe this will not completely give the smooth playing experience. Here you are using a constant delay of 0.02 Seconds while sending the input to mimic network latency, but working with actual network this value will be fluctuating, lag will never be constant, I just tried using a random value in this place in your code and movement were jittery. I am facing such issue in my multiplayer game that I am working on. Any help on this will be greatly appreciated.
Thanks you.
In my project there are movable objects that get simulated on the server side. This is obviously non-determenistic but is there any way to get around that?
I’m assuming you’re talking about something similar to the ball in Rocket League? It’s not owned by a particular player but rather owned by the server
If so, you can still do prediction (that’s what Rocket League does) you just won’t need an input buffer and rather you’d need some request for the client to the server that the player is trying to move the object
2:54 - wouldnt it be better to use fixedupdate when producing ticks?
So you could run into slight problems with FixedUpdate but I'm not sure how often you'd actually run into them. You pretty much create your own timestep because if a client or server for some reason took longer to process a FixedUpdate than the time, you'd be able to process all the frames it missed in the future (since we have the ability to process multiple frames). It's a little confusing but I followed along this article gafferongames.com/post/fix_your_timestep/
Hey. Can someone confirm I understand this correctly? Assuming the same client server cubes setup as at the end of the video the client cube is the client player position position on his game-client (server position with prediction) and the server cube is the client players position on the server. Correct? Sorry for the dumb question, but I've been trying to understand this enough to implement it in NetCode for the past few days and I'm slowly (or not so slowly) loosing my mind.
PS. I guess that is what happens when ones experience with networking is http req and sql queries not taking too long.
A bit late, but:
1) Client gets input, stores input in array, moves the cube (you see that in "client" screen) and send the pressed key to the server.
2) Server reads client's pressed key, moves the cube (you see that in "server" screen). It uses the same function as client, so gets the same result. Sends the result to the Client
3) Client reads the Server's result and compares to it's own result. If equals: all good, disregard, go to 1). If not equal, set server result for tick "serverResultTick", set tick = serverResultTick + 1, and go to 1.
In this approach both the server and the client process the same thing (unless you try to cheat in the client setting a different position for your player. If that's the case, when the client contrasts its values with the server ones, it will rollback and correct using the server values.
I'm also having your web & sql background so I understand how you feel :'D
This is a solid way to start off, but it is ignoring one very important thing: When re-simulating, you need to re-simulate the whole scene and not just the object that is off. Otherwise you will not have correct movement collisions in the past and the outcome in the present will still be wrong.
See here for more information: ua-cam.com/video/ueEmiDM94IE/v-deo.html
Resimulate everything in the entire scene for every player? That sounds like a lot...
@@JesseTheGameDev Not really the entire scene, but every dynamic object that can be collided with. I think his point is that more than player objects need to be predicted & reconciled.
U can't just use the fixed update for the fixed tick rate?
Does this work with Photon Pun?
The inputBuffer inside HandleServerReconciliation is a tad strange to me. My understanding is that HandleServerReconciliation will ONLY be executed on the server. After all Client Prediction is used to reduce latency in Server Authoritive systems. We did not initialize the inputBuffer variable for the Server neighter is it even present on server.cs. It seems we're trusting the client to decide when to use Position reconciliation, which is strange to me.
It is actually the opposite, the client will reconcile with the server states in HandleServerReconciliation thus it is only executed on the client
The server never reconciles, it doesn't have to, it is right
I'm using client server architecture. I applied it. It's very useful. But my client and server are not in the same project. Can you help me how can i edit this for this situation?
The only part you should need to change is 1) where we send the input state to the server and 2) where we send the movement state to the client.
These should be changed to whatever networking protocol you’re using to send messages back and forth.
You also would just have the server code live on server and client on client.
Lemme know how it goes :)
As long as the client is not cheating, the server could just validate that the received positions and move commands would result in movement within a error margin, and not interfere with the clients updates.
I thought the whole point of this method is to prevent cheating
@@alecz3843 You can prevent cheating by making a very complex prediction system, (at the cost of client side lags, and long dev times) or prevent cheating by detecting cheaters by the server, and kick them out.
And if the game is not a large E-Sports title, its better to use simpler solution.
Also this would only counter direct manipulation of the mechanics. But not things like wall hacks or aim bots.
Brooooooooooooooooooo
I would give you a million likes if i could
Hey
Thank you so much for this. I was trying to do this with Unity Netcode and it worked but there is minor issue, my characters body is jiterring and Idk why, I have characters Rigidbody on characters hip bone and I am doing hips.AddForce(myVector)
Can you please help me with this jitter issue?
@@purp40 Okay so I tried again but now character just first fly then falls down the ground, Idk what's happening (Unity Netcode). I have my client and server script on player object and in server I am checking if its server, only then it would run.
@Purp40 Okay so this issue is only happening in host not on client
@@purp40 okay I solved it too but now rotation of character is off😭😭
Character is facing at wrong direction and at same time it's trying to correct it's rotation but unable to do so
I am so sorry to disturb you and thank you for helping me
@@purp40 So I did the same thing except I did rotation through InputPayload . So I should just send Quaternion rotation to client prediction and directly apply those rotations? Like transform.rotation = rotation in ProcessMovement?
@@purp40 So youtube is deleting my comments whenever I am trying to post a link. I tried impementing your way, its better but still bad. I posted a forum on unity so could you give me your discord or mail so that I can send you that link for unity forum?
I think this is a wrong implementation, because you handle all client input in one tick on server side, this way we don't need a server reconciliation because the errors in position will never happen. Server will just update client when there is input to update, but the rest of the clients will see player standing in place and then jumping few positions.
Great tutorial, however you should maybe remove the "in 2022" from the title. This technique has been used for years, and will likely be used for years to come.
Has anyone adapted this to mirror?
I have used Mirror with this approach in some projects but similar concept should be applicable to any networking framework.
From a high level you just need to change the way client and server send the states to each other (ClientRpc and Command) and do some entity interpolation for other transforms that aren’t yours (you won’t be able to use Mirror’s NetworkTransform)
I’ll try to lay out the steps for Mirror:
1.) You can’t use NetworkTransform components if you’re trying to do prediction so remove them
2.) Update Client SendToServerState function to [Command]
3.) Update Client OnServerMovementState to [ClientRPC]
4.) Update Server OnClientInput to [Command]
5.) Update Server SendToClient to [ClientRpc]
6.) Lerp transforms for predicted players that aren’t yours (to smooth out the position updates since they’ll only be getting position updates at server tick rate)
Hope this helps! I don’t have the code readily available right now, otherwise I would share it with you.
@@Ajackster thanks I'll give it a shot at some point
@@Ajackster will this be suitable for rigidbody based player movement?
@@BlizzardZGaming good question. Afaik Unity’s physics engine is non-deterministic so I believe you’d have problems regardless of what networking framework you were using.
I’d do more research into it though, I’ve never tried with rigidbodies
@@Ajackster Thanks for the info!
This seems wrong... server should not process all client inputs in one tick. It shoud process them one by one.
8:24 something seems off there. It's assuming all the input messages belong to the same tick, but the queue may contain "tick 1" from certain clients and "tick 2" from some others for example. Then it will only broadcast "tick 2".
I've noticed a few assumptions here and there. I guess it's for the sake of simplicity, but in a real world situation there may be some issues. I could be wrong though, of course.
Im sorry this is too much for my brain 😂
Thanks for the vid but your face is way too close to the camera 😆 It's quite jarring.
Thanks!