Like that: 1EJXTh4HMAE It's a classic clip that was actually shared in LAN parties quite often. I think I still have it somewhere on a HDD. Yes, the time before UA-cam was a thing
Yeah for sure. So much work goes into the (mostly) seamless multiplayer experiences we all play nowadays, and I think most people take it for granted how ingenious the systems that make it possible really are. Working with multiplayer stuff for the last ~4 years has really changed how I view games :P
@@tomweiland i was following a tutorial and it had 35 errors here is the tutorial i followed: ua-cam.com/video/oyvt7RacVoo/v-deo.html here is the code: using System.Collections; using System.Collections.Generic; using UnityEngine; public class PlayerMovement : MonoBehaviour { public bool CanMove = true; public CharacterController PlayerController; [Header("Camera")] [SerializeField] private Camera playerCamera; public float MouseSensivity = 5f; public float XRotation = 0f; [Header("Walking Params")] public float WalkSpeed = 4f;
Haha I'm glad you like it! Despite what this video seems to suggest, I do think that anyone that's interested enough can certainly learn at least the basics of networking :)
This is very relatable. Great video. Whenever I tell people about how annoying it is, I don't feel like they comprehend the full extent of it. Even this video didnt fully give it justice. It's feels like you are slowly driven mad by some eldritch god. Stuff stops making sense but it kinda does, sometimes... You start to understand why online games seem so limited sometimes. Make sure to take care of your mental health. Take breaks and do other stuff that gives you joy and purpose in life.
For sure. This stuff can really bend your brain around... And yeah, mental health is something to be aware of when dealing with this madness. Although honestly 90% of the last 3 months that I "spent working" on this were actually spent either enjoying the summer or procrastinating tackling this problem 😅
3 роки тому+4
It's like quantum physics. But with better excuses.
Latency is worse than you think. Your processor has the speed of a 486 if you disable its caches. It is essentially playing a multiplayer game with itself since RAM is so hideously slow and instructions are pipelined over multiple clocks. Memory has kept up on bandwidth by taking many memory cells that operate slowly and multiplexing their output into something with a high clock frequency; but latency is scarcely better than 1998 because the individual cells are still slow. Even if latency of RAM was 1 clock instead of hundreds of clocks your CPU is pipelined; this means every instruction is chopped up into many stages and microops which can execute in parallel or out of order. Multiple instructions that use the same resources can be in flight at once as long as they are in different stages or in a different execution unit. To get around the latency problem the CPU is executing instructions out of order; as long as they don't depend on a prior result; and for every branch (think while-loop, if statement or for-loop) it is predicting if that branch will be taken or not and executing instructions on that basis. If ever it is wrong it needs to undo hundreds of instructions and their effects on several levels of cache as well as RAM which all have different latencies. And it gets worse; for legacy reasons the CPU has few registers and it is getting around this by renaming registers on the fly and having more physical registers than it has software addressable registers. So if you put the result of a calculation in EAX and store its value to RAM, then write something else to EAX and use that to do another computation; your CPU is aliasing EAX to different physical registers and trying to execute those things in parallel. Now there are also multiple cores which are using the same cache (L3 and RAM) in parallel and there are multiple levels of cache that have to be kept synchronized and the bigger they are, the slower they are. And this is hardware; so this either works perfectly on the first try when you release it to the consumer or you are down billions of dollars if you release a defective product that has to be recalled. High performance processors are pure nightmare fuel.
Oh Jesus, my notifications reminded me of this cringe comment I made 2 years ago. I learned a ton since then. It can definitely help if keep things simple and rely on existing systems and tools to sync stuff. But even with a lot more experience, my comment still holds truth. Always remember to code defensively! Also log errors and important events.
Switching from a physics based system to a simple parenting system when stepping onto the ship is actually genius. I had a stupid grin on my phase when i saw that part in the video cause i was also like "wait, how does one fix this actually?". And then my brain was like: "ah of course, why did i not think of that!" :D
It's an okay solution, but it has its issues. The jitter when getting on and off the boat being one, but I also foresee it complicating things when I get around to dealing with lag compensation. I'm strongly considering just predicting the ship's movement as well-that'd avoid the problem in it's entirety and is probably a simpler, easier to maintain solution 🤔
@@tomweiland Why not incorporate some allowed error margin for the client calculation on the server and be like "ah yes this sounds within the realm of possibilities, hereby I declare you not a cheater and I accept this update"
@@lock6562 Most likely, but as long as you give them a sort of "Vector3D positional_errors_accrued" variable that slowly returned to (0,0,0), you could see if someone gets too many errors in quick succession is probably cheating. With that, people would only be able to hack in a very small advantage at best since the rate of their advantage is limited to not accede the resetting speed of the positional_errors_accrued or it's max value.
Hey, I ran into similar issues while developing pantropy. We had the player move on ground and flying/moving bases here are my tips: 1. DO NOT use a rigidbody to move your player. Physics movements are never equal on server and client. Use a CharacterController instead. The characterController.move function is always accurate and the player will move an equal distance on server and client. 2. Don't use the characterController for ground collisions. Use a raycast and keep the player a given distance away from the ground. Move the player downwards if the ray doesn't hit anything. 3. Set the player's transform as a child of a moving object (like your boats) on server and client when he enters it. You will not have any weird physics glitches thanks to the "groundray". Hope these helped, this wroked for me flawlessly.
1. The problems I've been dealing with aren't related to a lack of physics determinism. You can actually make Unity's physics deterministic on the same machine by enabling the "enhanced determinism" option in the physics setting, and I've really only been developing & testing with both client and server on my computer. I also want to be able to easily apply forces to players, and I don't like how the CharacterController is basically a black box-no idea of/control over what goes on under the hood. 2. Again, not really a fan of CharacterController in general. 3. Making the player a child of the boat would give largely the same result that I ended up with at the end of this video. When getting on and off boats it would still jitter, and I kind of prefer my solution because I really didn't want the player to be a child of the boat. Thanks for taking the time to make suggestions though :)
I did actually come back for this advice, and I did use it. In standard cases, this would be a perfectly fine solution. Unfortunately, my case turned out not to be standard.. of course.
As a UA-cam commenter with absolutely zero game coding experience, this seems fairly good 👍, thank me later and yes I know my opinion is highly sought after
Try using a downward SphereCast and/or CapsuleCast over a single Raycast. While that solution seems to work for you, there are many scenarios where it can break. A great example are slopes. Granted, if you use the CharacterController component, slopes are automatic. But if you make your own kinematic character controller, you need to detect slopes on your own. Using something like CapsuleCast provides fantastic results. But I'm not gonna lie, creating a kinematic controller is probably the hardest thing I've ever done is game dev. It still doesn't even work tbh. There is SO much math involved. At least I learned a ton lol.
I tried making a multiplayer fps and gave up because of these things. It's really hard to conceptualize what this sort of entails until after it starts bending you over.
> Spend forever making functioning multiplayer game/modes. > Half the playerbase only plays singleplayer. Social anxiety, the hardest challenge of all.
@@tomweiland The boats sound like they make it significantly harder. I believe sea of thieves switches players to local coordinates for the ship. Do you think that is similar to your duplicate ship approach?
I personally use Unity and like it a lot, but I haven't used Unreal Engine so I'm probably at least a little bit biased. I think the most important difference is the programming languages they use-Unity uses C# which I _love,_ while Unreal uses C++ which is apparently one of the hardest programming languages to learn. You can use blueprints in Unreal instead of C++ which is like visual scripting, but I've never really been a fan of that. Both engines can be used to do a lot of the same things, but I'll probably always recommend Unity because it uses C#.
@@juju8470 I've worked in Unity and Unreal and as Tom says coding in C# is really nice and C++ usually is a slower and more tedious process and yes its difficult to get into. Unreal has a lot of build in systems similar to unitys monobehaviour but its so massive and that can be really hard to get into, so lots of trail and error early on. Blueprints is actually also pretty enjoyable to work with until you have to make massive system for your game, it can get rough to keep track of the code. Unreal also offers a lot of shortcuts and more dedicated support for artists, and level designers to get going. Unreal also has a more integrated multiplayer systems, haven't touched it myself but compared to unity its very much an engine feature. Imo I've had less issues working in unreal on a engine error level, and the experience has been smoother working in unreal but Im still much more comfortable with unity.
@@tomweiland Be aware of using Unity networking library to develop multiplayer games, they change the API every several years mainly because not many people use it. I think it's totally not necessary, they just have to improve the API not abandon it! Unreal use the stratege and it works just fine.
These problems are why I probably wouldn't recommend a multiplayer game for a first project (unless it's local multiplayer). It's a real headache to figure out the proper way for networking in games, and when you're also doing everything else for the first time, it becomes a whole lot to handle.
0:16 Yeah its such a good feeling when you rewrite all of that code but in a different way beause you thought your other way is stupid and didn't work BUT! then you see that you didn't type () or added an extra space Great video btw Hope we can see more videos soon. Love the progress so far Good luck!
Yeah it's always nice when issues are quick one word fix...except when you spent 3 days trying to _find_ the issue in the first place :P Glad you enjoyed the video-I'd definitely prefer not to go another 3 months before the next one, so hopefully soon!
This is a great video. Very good and clean explanation of an otherwise very complex topic. A few things from my several years experience: - there's no need to "compare" for misprediction... just overwrite with server data and resimulate forward (maybe this is what you do already) with the local input buffer... - for moving boats, and all moving platforms in that sense, it gets trickier because you could place the boat in predicted timing as well (if you also predict/rollback physics, which you can do), but this would create a problem for proxies (view of other players) as they are generally on interpolated time. One thing that may work for proxies is to predict just their gravity and move-with-platform part... But in either case or solution you will loose one thing, which is the capability of doing accurate lag compensation... but that is another story...:)
Thanks for watching :) You're right about not needing to compare positions-I don't actually do that in my code, but since I didn't want to get into the whole rewinding-and-resimulating part I figured that'd be the easiest way to explain what happens from there in a single sentence. I definitely thought about predicting the boat movement as well, but that would've then meant also predicting the waves, and it sets the precedent of having to predict anything that moves which the player might end up standing on. Then again I suppose I've set a similar precedent in the sense that if I want to avoid jittering on other moving objects, they're going to need "proxies" as well...
Fancy to see you here, I asked you about how you networked redmatch 2 in steam comments a while ago. Been a rough learning for me but fun nonetheless. Seeing this video just adds a layer of terror to the ordeal but it will be done...
Glad you enjoyed it! I can at least see the light at the end of the tunnel now, so maybe take it as inspirational with strong warnings about what you're getting yourself into? :P
Godspeed my friend, that's why I'm sticking to single player for the foreseeable future! Also the music that kicks in at 0:30 made me think That Chapter and I was worried someone was going to end up dead by the end of the video
I am soo happy I kept it ad 2d without physics and to something where single milliseconds don't matter that much. I really am feeling with you though, network-code is the worst to debug. Especially if you went insane like me and introduced multi-threading in the process, please just end my eternal suffering.
You are doing great work man. The fact that you have gotten this far this quickly already puts you light years a head of others in the industry. To top it all off you are teaching yourself all this. That puts you even farther. I can't wait to see any tutorials that you (hopefully) put out for the new netcode.
It's interesting to hear your experiences with implementing multiplayer. I'm writing a multiplayer game myself in Unity but it's simultaneous turns on a grid-based map so I'm not feeling the pain of realtime play, I'm sure I'll discover my own pains as I progress though. Anyway, I always liked this quote from Michael Abrash's Black Book on reducing player latency in Quake - Reduced latency also often makes for more frustrating play. It’s actually not hard to reduce the latency perceived by the player, but many of the approaches that reduce latency introduce the potential for paradoxes that can be quite distracting and annoying. For example, a player may see a rocket go by, and think they’ve dodged it, only to find themselves exploding a second later as the difference of opinion between his simulation and the other simulation is resolved to his detriment.
Yeah, hiding latency introduces a whole other set of problems to deal with...can't wait! It's very wise of you to work on a game that doesn't require realtime play 😂
@@tomweiland Yeah, well actually no, I should have edited that. It is realtime but not realtime realtime. As in the players move in realtime simultaneously during their turn but they're restricted to a grid so I don't have to worry about little annoyances like physics and collisions. I've probably got it easy compared to you but there's still plenty to think about. It is at the same time both a 'fun' challenge and an interesting learning experience.
As a person who's just jumped into the ship of game development, I've decided that I want to make a multiplayer game at some point. So, I will absorb all of the videos that you have with issues and explanations/solutions to these issues. I've subscribed waiting for for the next video lol
Yo, you finally got into the same problems I have been working on for the past 3 months. I was almost getting angry seeing you not having to deal with any of those. 😂
@@tomweiland Jittering is not a bug, it's a feature. It defines the status of chaos of the world making the player feel the uncertainty and instability of life. Latency also is important, it teaches the player to wait and have patience or to take initiative and get a better connection.
This was a really good video Tom. Great video editing as well. You can see the effort you put in. Good luck with the continued efforts and we all look forward to more updates in the future!
Sorry for enjoying watching your struggles on UA-cam :D Keep trying, it will eventually succeed (if it doesn't drive you mad). Remembers me when my friend and I had had to use an obscure front framework and the correct data wasn't showing, it took us 3 weeks of heavy sweating and nightmares to discover it was expecting some weird null instentiatiation with no data to work...
I think if/when I eventually finish this game, I will build a singleplayer game next. Or at least a multiplayer game that doesn't require hiding latency to ensure a good gameplay experience. Maybe a top down RTS or something 😂
"You realize that you didn't read the documentation properly". Oh, if only! I can't even begin to count the hours I've wasted on following incorrect documentation.
"Take 2 days to fix the error" Me trying to upload my game to google play from past 2 days 1. Keystore 2.some random arc64 3.150mb limit 4. api time taken 1- week
I did laugh with you at a couple of points. Streaming gaming services can't come fast enough. Your description is excellent, I think it was wise too stop before you got into estimating latency and forward calculating at the server. "Time streams" was a great phrase. Still enjoying your vids, sorry it's being such a pain.
Glad my humor hasn't been stripped of me along with my sanity 😂 I'll figure it out eventually, I have the bulk of the pain out of the way now, so I at least see the light at the end of the tunnel :) I'm hoping I explained things well enough with enough visual aids to keep people interested even if they're not familiar with programming and multiplayer.
I mean that's nice I guess...but totally useless in my case. A generic prediction solution would have the exact same issues on boats that I'm having, so I would end up needing to heavily modify it (at which point it'd probably just be easier to write my own). I'm also using Unity and don't plan on switching-I like C# and don't feel like learning C++ right now, and blueprints are quite unappealing to me. It's also worth noting that Unreal's netcode out of the box is really only good for small arena shooters with less than like 20 players (my game is not one of those). Epic themselves had to make modifications to get Fortnite to be able to handle 100 players on the same map.
@@tomweiland Yeah that's true, the MMORPG Ashes of Creation is being made on UE4 and they had to make their own proprietary networking to make UE4 capable of supporting a massive concentration of people (the Massive on MMO :P)
@@Hunsenbargen I would think this is mostly about reducing fidelity. Players that are far away don't need 60 updates per second or even 30. Even 1 update per second will go very far as long as they are running in a somewhat straight line or turning smoothly. You therefor only need to send frequent updates if they are doing something unexpected. As the number of players increases the naive solution is an O(N^2) problem.
I was going to say. A lot of these issues (not all) are solved in UE out of the box. I actually found it very easy to set up a multiplayer replicated movement model.
Hey Tom! Has been a while since I dropped in to watch a video by yours. It changed, in a good way. You made me chuckle and it was informative. Keep up the work, mate!
*Check out the next devlog:* ua-cam.com/video/cYLnVp1ngwA/v-deo.html So yeah...this is where I've been for the last 3 months (although I did also enjoy the summer a bit). Thanks for watching :D If you're interested in learning more about client prediction/reconciliation, check this out: www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html
Wow bro. Just wow. You've ran into your first major learning curve I'd say. Prior to this you've done splendidly and really.broufht something great to the table. Now though. Your gonna have to learn how the big guns do it i suppose. Why not contact aome AAA companies and ask about it through their human resources. The Internet is obviously failing to provide decent documentation for you. So ask how the big guys do it. Might be a few neat tricks they use thar you can implement. Just a thought bro. I'm not even gonna attempt networking until next years project. Was thinking about starting with your tutorials
@@BadBanana definitely not the first learning curve 😅 There's also plenty of resources out there on how prediction/reconciliation should work, but virtually nothing about how to ensure it works while standing on moving objects like ships. The only other game that comes to mind which would have had to deal with this is Sea of Thieves, but I'm about 95% sure they solved it the same way I did (with a "proxy" for the boat).
This is actually a great explanation why standing on a vehicle in any multiplayer game like Battlefield series was always normally fine, but when it was moving, things would go spasmatic and probably end in phasing through the vehicle or dying for no reason.
Makes sense-as long as it's not moving, you don't experience the effects of objects from different "time streams" interacting. Once it moves though, 💩 hits the fan :P
Best choice I made when creating my multiplayer game was switching over to Unreal. I've used Unity for years, learning all the ins and outs, but it lacks the tools for multiplayer development. Unreal has a ton of great features for multiplayer like profiling, viewing net corrections (aka where you f'ed up), controlling multiple players and simulating latency and packet loss. The cons are that it can be tough to find documentation on stuff and there are some videos out there that give bad advice (such as using blueprints for multiplayer; DON'T use blueprints for player movement, C++ is the correct way). Luckily, there are great videos out there that give awesome advice on how to do it properly.
Unfortunately I love C# and don't really want to spend a ton of time learning C++ just so I can use Unreal's multiplayer. Also, while I haven't used Unreal's netcode myself, I've talked to others who've said it's really not as great as most people make it out to be. Either way though, I'm not sure their out-of-the-box solution would take care of the problem I had here, so it's very possible I'd just end up having to solve the same issue, just this time using a language and engine that I'm not at all familiar with.
Hahaha I haven't even tried multiplayer yet, but I feel your pain. It's always some small error that you spend most of your time trying to fix.. Nice video!
@@tomweiland hahaha, you're the man tho, i really appreciate your work, i can watch your tutorials to understand a bit more about how things are done. Keep it up! :)
@@tomweiland sorry was a late night message ☕️ I meant we’ve started to look into client predictions as we are building a multiplayer element to our game - turns out to be a bigger can of worms than we expected 😖😂
I mean client prediction itself is still _relatively_ okay. The problems really come in when you need it to work on another moving object like a boat...
If I understand game networking correctly, there are 2 general approaches of syncing client's state with server's state. 1) Delayed input - you submit input and wait until your world state is set by server. It allows world behave smoothly on all clients, but your inputs are now less responsive. 2) Client prediction - you submit input and instantly simulate what should happen. Server then modifies your past world state and you reapply your input history, effectively correcting the present. It makes your inputs responsive, but since each new modification skips some of it's personal time, sudden events now look abrupt unless you somehow awkwardly interpolate them. Or instead of reapplying history you could accumulate error between client's and server's predictions, and then slowly/instantly use it to displace values. You can use both of them, each for it's own system. Delayed input may be used for walking around, and client prediction - , with "server feedback" part possibly omitted, - for moving your head around. And only in cases when ping is above 30-40 ms differences between those two methods become clear to a user. With first approach you'll have slower inputs, and second one will make everyone around you walk a bit weirdly. First approach is simple to implement, and second one requires you to remember an input chronology, timeline of entities that can move and are near you; but it also allows for competitiveness in platformers or shooter games (although it takes some extra cpu). ================= Also, some notes: - You have to account for high-ping cases. Ping changes over time - it may suddenly skyrocket and then fall down, and it isn't always low between two computers of the very same country. Be cool and expect the unexpected. - Not everything at all times should be broadcasted to everyone. You should only frequently update objects/features, that are close to respective clients and are hardly predictable. And you also shouldn't forget to have even minor details updated from time to time (positions, lists of existing entities), or else you may end up with severe desync. Especially if you often use UDP. - Server world state may intentionally lag behind players (or players may simulate ahead of time) just to accumulate player inputs and resolve conflicts when two players press key practically at the same time. - When some continuous non-physical state (eyeAngle, walkDirInput) is received by client, it should be interpolated or extrapolated. - Server may calculate some events (headshotting someone) from perspective of what player had seen during input submission. This is called lag-compensation, and should not be used when player's ping is far too high. And it may be useless if server-state stays behind on timeline, and so it knows what both players were doing during the headshot tick (or so I think). =================
Yeah latency itself is annoying, but on top of that you have to account for a lot of unpredictability-ping fluctuations, lost packets, duplicate packets, etc.
I think player movement can be handled locally, but if the player moves beyond the sphere of allowable mismatch and for too often, it can be verified more and more by the server. I used something like a "suspicion" tracking variable, where someone speed hacking or teleporting quickly finds their movement entirely server-authenticated. So it trusts the client initially, but the trust can be lost for a time. Multiplayer coding is absolute hell, just getting a game to finally accept connections was a whole endeavor...
The problem is that checking speed or distance traveled doesn't account for things like collisions, and those metrics really say very little about whether the movement is "acceptable". A system like that wouldn't catch someone who's walking through a wall, or someone who slows their gravity down so they fall slowly, and making the system capable of detecting those things essentially requires simulating all of the movement logic on the server. At that point, it's arguably easier and less work to just give the server full authority, and by doing so you'll also avoid dooming yourself to playing the cat & mouse game of hackers finding ways to exploit/evade your detection systems and you having to react. At the end of the day it just comes down to what tradeoffs you want to make-I prefer giving cheaters as little chance as possible to gain an advantage :P
Before you got to the part where you wanted to get back to the practical side of things 4:13, I immediately thought "why not use a decimal data type and clamp the position to the nearest median? The difference is negligible." Also, to fix your new problem, it starts off with how you tackle the problem. First off, depending on your set up, the water becomes the parent and the objects such as ships and the terrain to walk on become the children of the sea. When the boat sails out to the sea and hits a certain local distance in the water, the land itself moves away from the boat and the water instead; This has the server calculate the position of the static land (and local position of the player), not the boat.
_"I immediately thought 'why not use a decimal data type and clamp the position to the nearest median? The difference is negligible.'"_ What exactly would this accomplish/solve? _"When the boat sails out to the sea and hits a certain local distance in the water, the land itself moves away from the boat and the water instead; This has the server calculate the position of the static land (and local position of the player), not the boat."_ Are you suggesting that I make the boat stationary and move the land and water around it in order to make it _look_ like the boat is the one moving? That sounds _at least_ as complicated as the solution I ended up with, and it has many more problems. What should happen if one player is standing on a boat and another is on land? What should happen if there are 2 boats? Which one should everything move in relation to?
I had the same problem when I created my first multiplayer game too, but I found out that letting the player move only after getting the move message from the server worked better than trying to predict the player’s future position on both the server and the client at the same time. The process was: player presses W -> sends it to server -> server check if the move is valid and instantly sends back command to tell client to move the character. The latency can be forgiven because most of the time it happens in less than one frame. That way, I can focus on reducing the message size instead of trying to correct the player position, which is a dead end.
Waiting for a response from the server before moving quickly leads to an experience that is sufficiently unresponsive for it to feel awful. A 50ms round-trip time is plenty for the delay to be noticeable, and I'd argue that it's unreasonable to expect most players to have less than that, especially when you factor in the added delay from your tick rate (lower tick rates mean bigger gaps between ticks, which effectively increases the time it takes for the server to respond) and from slightly buffering positions so you can interpolate them and have the movement look smooth. Players with powerful rigs and high refresh rate monitors will also be more likely to notice delays than players whose monitors max out at 60hz. _"The latency can be forgiven because most of the time it happens in less than one frame."_ This is just not true in my experience, unless you're testing with the server and client on the same network. At 60hz you have a frame time of ~16ms, and the vast majority of your players will almost certainly not have a round trip time that's less than that. Someone with a 144hz monitor will have a frame time of just ~7ms, so even if they somehow had a mere 25ms round trip time on their connection, at least 4 frames would pass before they see the result of a key press.
interesting idea with syncing the player position relative to the boat, but you could skip the floating boat, just synch a parent id + relative position over the network!
The problem with that is that it doesn't account for the discrepancies/delay in the boat's rotation, which would still lead to jittering/mispredictions an various situations. That's part of the reason why I went to the trouble of adding a "proxy" boat-it doesn't need to rotate so it just avoids that issue entirely.
5:09 Little tip for recording long texts where you run out of breath: take little stops inbetween to breathe and cut it out in editing so you have a more chill recording experience :)
Sounds like fun :D Sorry you went through these issues but this was very informative! It starting to sound like the Marvel Multiverse with all the client and server prediction stuff haha. Glad you got a lot of the latency/jitters fixed, at least with a single player in!
You probably want to keep your control over the server, but if you ever decided to switch to Photon, it has an option for extrapolation to enable Photon's server to predict where a player's transform may be in its Photon Transform View Classic documentation. I'm unsure of how well this will work for your game, but in case you weren't aware of this option, thy has presented it.
I had a very similar experience working on a multiplayer FPS i never ended up finishing. I avoided the issue with player-movement by using a character controller, however, I was having lots of issues with rigid-body projectiles. It was such a pain in the head I ended up scrapping most of them.
Hmm, you must have had a different problem then, because using the CharacterController instead of a rigidbody controller wouldn't change anything. I'd still have the exact same issues...
My niave solution is to move the client position x% closer to the server position. It'll be smooth and generally not noticeable unless there's a significant difference. And since it averages the two systems (client and server) should get back in sync. This is mostly theory at this point tho.
The problem is that the client is simulating ahead of the server, so if you don't correct fully then your starting point for future tick is still incorrect and will lead to larger divergences more quickly. What you _can_ do is fully correct the player's collider/state, but add a bit of delay to the visual so you can smoothly interpolate to the new position.
Basic dead-reckoning problem, easy solution actually. You always use the client to determine their own position, the server's job takes the incoming movement data to determine velocity maps while testing to ensure players are within margin of where they should be given timestamps of their updates and relay those maps to other players.....then the clients can tween the values against current positions and increase/decrease speeds as needed in order to pinch position faster for sighting other players. Any "pinpoint accuracy" measurements can be checked by the server through the same tween algorithms to determine if the player actually was "on target" to another player during that timestamp. Since velocity maps are checked against timestamps, speed hacks are found quite easily. Auto-aim bots are not as easy with this, but that can be checked based on precision movement checks through obstructions. No jitter, no forced movements, and everything is quite smooth. The only downside is clipping of players when tweening values if they get too close to other objects when making turns....you could use a spline tween, but it can look unnatural sometimes.
You say there's an "easy solution", but then proceed to describe what arguably sounds _more_ (certainly not less) complex & time-consuming to implement, while being less secure...but if that's how you want to do it, go ahead :P I'm also not sure that it makes much sense to apply the term _dead-reckoning_ to first person player movement, given that players can literally turn around and start going in the opposite direction on a dime-unlike boats, cars, planes, etc.
@@tomweiland code it, you'll realize what the "easy" part is. DR is what they call it, I don't know why, I really don't care, it's like 10 lines of code. Have fun.
you need to rethink your architecture if the boat is not working out properly. World of Warcraft did zeppelins. I am sure it wasnt easy but it is possible. 1) try doing everything in ticks 2) try doing everything in deltas with deterministic state machines
It's not inherently an architecture problem-the issue of how to deal with moving platforms (which is what my boat effectively is) in multiplayer is widely-recognized as a very common problem with no real solutions that work for all scenarios. I've never played WoW so I'm not familiar with how the zeppelins work, but depending on the restrictions you place on players while on board the problem can be very easy to solve. For example, simply restricting the player's ability to get on and off the platform/zeppelin to the times where it is not moving would allow you to just sync the player's relative position with no issues (as long as it only rotates around the Y axis). Another approach is to have clients predict the position of the platform so that it exists in the same "time stream" as their local player objects, but this will then cause problems with how players see other players interacting with said platform unless you predict other players' movement as well (which is tricky business since you don't have their inputs in real time). I will probably try the platform/boat prediction method in the future, but the point is that every approach to solving this issue has downsides and tradeoffs. Which of those you're willing to make depends heavily on the game and specific use case. Simply "doing everything in ticks" (I already am) or "in deltas" doesn't solve the issues that come with objects from different "time streams" interacting.
Awesome video! Yeah multiplayer is a real though one. I personally have not tried multiplayer in Unity3D but tried it in JME3 with SpiderMonkey. But it looks like you are almost perfecting it. Keep it up! :)
It's definitely a different vibe. Once you get used to it, there's still always things to learn in order to optimize, etc. Object oriented programming, server is king! Replication is there just to test patience. Hahah! Good luck out there game devs.
i am big fan of games that can use multiplayer criatively like clash royale that transfer a simple card info and the position in the field and even if you lag the server do the recalculations and sincronizes the players, it moves so simple info but works so well for a vs mobile game that is awesome
I think the solution for boats is to use the origin of the boat as a temporary world origin while you are on it. Also, your waves must be driven by a deterministic algorithm, like a noise function, and sync the input used in the function across players. That way, the boat movement will be smooth since it is calculated on the client and the waves will mostly all be the same. Look at how Valheim implemented this.
I want to avoid predicting the boat movement though because the more things I make the client predict, the more likely it is for mispredictions to happen, which will result in more corrections. Also, predicting boats and other physics objects would severely complicate the reconciliation system because suddenly I'd have to rewind the whole simulation, not just the local player (which is currently the only simulated physics object on clients).
That's why I chose to do LAN multiplayer. That way, if a cheater is stealing your fun you can just go to him and punch him in the face.
😂
Like that: 1EJXTh4HMAE
It's a classic clip that was actually shared in LAN parties quite often. I think I still have it somewhere on a HDD. Yes, the time before UA-cam was a thing
@Bunny99s I remember learning why you shouldn't set your drive on a subwoofer. Also to make backups
@@richardwelsh7901 will it get wiped?
Smart Man!
"Give a man a software he will enjoy it, teach him to code he'll never enjoy in his lifetime'
-Suz Tzu art of coding
Probably gonna go die of a truth overdose, brb.
Give a man a game and he will be happy for a night. Teach him how to make games and he will never be happy ever again
If this is the case games would stop existing
@@caronfernandes4625 exactly. That’s why games don’t exist.
That's why I never learned it from school, it was just not fun
Players unfortunately don’t now about all these complications…
Yeah for sure. So much work goes into the (mostly) seamless multiplayer experiences we all play nowadays, and I think most people take it for granted how ingenious the systems that make it possible really are. Working with multiplayer stuff for the last ~4 years has really changed how I view games :P
@@tomweiland True
They b like : where content
@@038alpha precisely 😅
IF ONLY THEY KNEW !!! 😭😭😂😂
"It doesn't work and I don't know why "
"Now it works and I don't know why"
-every programmer's cycle in a nutshell
The former is frustrating and the latter is fear-inducing 😂
DELETE THIS
to relatable to be said out-loud
This is my last 3 months in a nutshell 😆
And I'm only through the building system and inventory and connecting ui 😆
@@tomweiland i was following a tutorial and it had 35 errors
here is the tutorial i followed: ua-cam.com/video/oyvt7RacVoo/v-deo.html
here is the code:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class PlayerMovement : MonoBehaviour
{
public bool CanMove = true;
public CharacterController PlayerController;
[Header("Camera")]
[SerializeField] private Camera playerCamera;
public float MouseSensivity = 5f;
public float XRotation = 0f;
[Header("Walking Params")]
public float WalkSpeed = 4f;
private void Awake()
{
Curser.lockState = CurserLockMode.Locked;
}
public void Update()
{
Move();
HandelCamera();
}
private void Move()
{
if (!CanMove)
return;
Vector3 moveDirection = transform.right * Input.GetAxisRaw("Horizontal") + transform.forward * Input.GetAxisRaw("Vertical");
PlayerController.move(moveDirection * WalkSpeed * Time.deltaTime);
}
public void HandelCamera
{
XRotation -= Input.GetAxis("Mouse Y") * MouseSensivity;
XRotation = Mathf.Clamp(XRotation, -90f, 90f);
playerCamera.transform.localRotation = Quaternion.Euler(XRotation, 0f, 0f);
float YRotation = Input.GetAxis("Mouse X") * MouseSensivity;
transform.Rotate(new Vector3(0f, YRotation, 0f));
}
}
Thank you so much for making this. Ever since release its my go to video when players ask "Why don't you just add online"
LMAO 🙌
Hi neverjam
@@mangolover1 Hello
"Just do the thing." - Your boss.
no way its the spiderheck
I fricken love this channel! Anyone that can do networking is a god.
Haha I'm glad you like it! Despite what this video seems to suggest, I do think that anyone that's interested enough can certainly learn at least the basics of networking :)
@@tomweiland Completly true! 4 Months back i knew literally nothing and your tutorials helped me a lot! Im not using it for games tho
I agree
Even if it's photon?
Networking is nowhere near as complicated as game design imo
"What better way to fix a bug than working around it?"
-Every Programmer Ever
Exactly :P
Yeah because that won't possibly go horribly wrong after a month into the thick of it😂😭
Making it a feature.
It's not a bug, it's a feature
This is very relatable. Great video.
Whenever I tell people about how annoying it is, I don't feel like they comprehend the full extent of it. Even this video didnt fully give it justice.
It's feels like you are slowly driven mad by some eldritch god. Stuff stops making sense but it kinda does, sometimes... You start to understand why online games seem so limited sometimes.
Make sure to take care of your mental health. Take breaks and do other stuff that gives you joy and purpose in life.
For sure. This stuff can really bend your brain around...
And yeah, mental health is something to be aware of when dealing with this madness. Although honestly 90% of the last 3 months that I "spent working" on this were actually spent either enjoying the summer or procrastinating tackling this problem 😅
It's like quantum physics. But with better excuses.
Latency is worse than you think. Your processor has the speed of a 486 if you disable its caches. It is essentially playing a multiplayer game with itself since RAM is so hideously slow and instructions are pipelined over multiple clocks. Memory has kept up on bandwidth by taking many memory cells that operate slowly and multiplexing their output into something with a high clock frequency; but latency is scarcely better than 1998 because the individual cells are still slow. Even if latency of RAM was 1 clock instead of hundreds of clocks your CPU is pipelined; this means every instruction is chopped up into many stages and microops which can execute in parallel or out of order. Multiple instructions that use the same resources can be in flight at once as long as they are in different stages or in a different execution unit. To get around the latency problem the CPU is executing instructions out of order; as long as they don't depend on a prior result; and for every branch (think while-loop, if statement or for-loop) it is predicting if that branch will be taken or not and executing instructions on that basis. If ever it is wrong it needs to undo hundreds of instructions and their effects on several levels of cache as well as RAM which all have different latencies. And it gets worse; for legacy reasons the CPU has few registers and it is getting around this by renaming registers on the fly and having more physical registers than it has software addressable registers. So if you put the result of a calculation in EAX and store its value to RAM, then write something else to EAX and use that to do another computation; your CPU is aliasing EAX to different physical registers and trying to execute those things in parallel. Now there are also multiple cores which are using the same cache (L3 and RAM) in parallel and there are multiple levels of cache that have to be kept synchronized and the bigger they are, the slower they are.
And this is hardware; so this either works perfectly on the first try when you release it to the consumer or you are down billions of dollars if you release a defective product that has to be recalled. High performance processors are pure nightmare fuel.
It happens delete the glitchy function and rewrite from scratch spent two days trying to debug nuked the code and redid it all of a sudden it works.
Oh Jesus, my notifications reminded me of this cringe comment I made 2 years ago. I learned a ton since then. It can definitely help if keep things simple and rely on existing systems and tools to sync stuff. But even with a lot more experience, my comment still holds truth. Always remember to code defensively! Also log errors and important events.
The best thing is swapping a semicolon for a Greek question mark in a friend's code
That is _evil..._
@@tomweiland Look at mimic by reinderien. But don't touch it, or it may plunge your soul into darkness.
You my good man, are the devil's right hand man.
; ;
Switching from a physics based system to a simple parenting system when stepping onto the ship is actually genius. I had a stupid grin on my phase when i saw that part in the video cause i was also like "wait, how does one fix this actually?". And then my brain was like: "ah of course, why did i not think of that!" :D
It's an okay solution, but it has its issues. The jitter when getting on and off the boat being one, but I also foresee it complicating things when I get around to dealing with lag compensation. I'm strongly considering just predicting the ship's movement as well-that'd avoid the problem in it's entirety and is probably a simpler, easier to maintain solution 🤔
@@tomweiland Yea i guess that makes sens. But it's still a novel solution to safe on resources imo!
@@tomweiland Why not incorporate some allowed error margin for the client calculation on the server and be like "ah yes this sounds within the realm of possibilities, hereby I declare you not a cheater and I accept this update"
@@gzxmx94 I mean that would still allow for speed hacks and whatnot they would just be slower
@@lock6562 Most likely, but as long as you give them a sort of "Vector3D positional_errors_accrued" variable that slowly returned to (0,0,0), you could see if someone gets too many errors in quick succession is probably cheating. With that, people would only be able to hack in a very small advantage at best since the rate of their advantage is limited to not accede the resetting speed of the positional_errors_accrued or it's max value.
Hey, I ran into similar issues while developing pantropy. We had the player move on ground and flying/moving bases here are my tips:
1. DO NOT use a rigidbody to move your player. Physics movements are never equal on server and client. Use a CharacterController instead. The characterController.move function is always accurate and the player will move an equal distance on server and client.
2. Don't use the characterController for ground collisions. Use a raycast and keep the player a given distance away from the ground. Move the player downwards if the ray doesn't hit anything.
3. Set the player's transform as a child of a moving object (like your boats) on server and client when he enters it. You will not have any weird physics glitches thanks to the "groundray".
Hope these helped, this wroked for me flawlessly.
1. The problems I've been dealing with aren't related to a lack of physics determinism. You can actually make Unity's physics deterministic on the same machine by enabling the "enhanced determinism" option in the physics setting, and I've really only been developing & testing with both client and server on my computer. I also want to be able to easily apply forces to players, and I don't like how the CharacterController is basically a black box-no idea of/control over what goes on under the hood.
2. Again, not really a fan of CharacterController in general.
3. Making the player a child of the boat would give largely the same result that I ended up with at the end of this video. When getting on and off boats it would still jitter, and I kind of prefer my solution because I really didn't want the player to be a child of the boat.
Thanks for taking the time to make suggestions though :)
This is great advice thank you, I will be using this!
I did actually come back for this advice, and I did use it. In standard cases, this would be a perfectly fine solution. Unfortunately, my case turned out not to be standard.. of course.
As a UA-cam commenter with absolutely zero game coding experience, this seems fairly good 👍, thank me later and yes I know my opinion is highly sought after
Try using a downward SphereCast and/or CapsuleCast over a single Raycast. While that solution seems to work for you, there are many scenarios where it can break. A great example are slopes. Granted, if you use the CharacterController component, slopes are automatic. But if you make your own kinematic character controller, you need to detect slopes on your own. Using something like CapsuleCast provides fantastic results. But I'm not gonna lie, creating a kinematic controller is probably the hardest thing I've ever done is game dev. It still doesn't even work tbh. There is SO much math involved. At least I learned a ton lol.
The most honest insight I have seen into what it’s like to develop a game
😅
I tried making a multiplayer fps and gave up because of these things. It's really hard to conceptualize what this sort of entails until after it starts bending you over.
😂
> Spend forever making functioning multiplayer game/modes.
> Half the playerbase only plays singleplayer.
Social anxiety, the hardest challenge of all.
Brilliant to see you've got this going! Client prediction was a major reason why I gave up last time I tried networking.
It's definitely not a fun problem to be solving, and of course I had to make it even more complex for myself by having moving boats in my game 😂
@@tomweiland The boats sound like they make it significantly harder. I believe sea of thieves switches players to local coordinates for the ship. Do you think that is similar to your duplicate ship approach?
That cliff hanger tho! I was on the edge o' me cap'n seat. Great video like always matey :p
I can't tell if the pirate speak is improving or getting worse every time 😂
I just made my first game in unity, and honestly the coding part seems kinda intimidating but i'm somehow enjoying the learning process.
Congrats! It can definitely be intimidating at the beginning, but I'd say it's definitely worth it :)
Do you guys recommend unity or unreal engine? I’m completely new and I want to get into game development.
I personally use Unity and like it a lot, but I haven't used Unreal Engine so I'm probably at least a little bit biased.
I think the most important difference is the programming languages they use-Unity uses C# which I _love,_ while Unreal uses C++ which is apparently one of the hardest programming languages to learn. You can use blueprints in Unreal instead of C++ which is like visual scripting, but I've never really been a fan of that. Both engines can be used to do a lot of the same things, but I'll probably always recommend Unity because it uses C#.
@@juju8470 I've worked in Unity and Unreal and as Tom says coding in C# is really nice and C++ usually is a slower and more tedious process and yes its difficult to get into. Unreal has a lot of build in systems similar to unitys monobehaviour but its so massive and that can be really hard to get into, so lots of trail and error early on. Blueprints is actually also pretty enjoyable to work with until you have to make massive system for your game, it can get rough to keep track of the code. Unreal also offers a lot of shortcuts and more dedicated support for artists, and level designers to get going. Unreal also has a more integrated multiplayer systems, haven't touched it myself but compared to unity its very much an engine feature.
Imo I've had less issues working in unreal on a engine error level, and the experience has been smoother working in unreal but Im still much more comfortable with unity.
@@tomweiland Be aware of using Unity networking library to develop multiplayer games, they change the API every several years mainly because not many people use it. I think it's totally not necessary, they just have to improve the API not abandon it! Unreal use the stratege and it works just fine.
These problems are why I probably wouldn't recommend a multiplayer game for a first project (unless it's local multiplayer). It's a real headache to figure out the proper way for networking in games, and when you're also doing everything else for the first time, it becomes a whole lot to handle.
Yep, 100% agree.
Agree! it's always good to learn the basics and then go for the multiplayer aspect after
I wouldn't even recommend local, as it makes playtesting way more of a pain.
0:16 Yeah its such a good feeling when you rewrite all of that code but in a different way beause you thought your other way is stupid and didn't work BUT! then you see that you didn't type () or added an extra space
Great video btw Hope we can see more videos soon. Love the progress so far Good luck!
Yeah it's always nice when issues are quick one word fix...except when you spent 3 days trying to _find_ the issue in the first place :P
Glad you enjoyed the video-I'd definitely prefer not to go another 3 months before the next one, so hopefully soon!
This is a great video. Very good and clean explanation of an otherwise very complex topic.
A few things from my several years experience:
- there's no need to "compare" for misprediction... just overwrite with server data and resimulate forward (maybe this is what you do already) with the local input buffer...
- for moving boats, and all moving platforms in that sense, it gets trickier because you could place the boat in predicted timing as well (if you also predict/rollback physics, which you can do), but this would create a problem for proxies (view of other players) as they are generally on interpolated time.
One thing that may work for proxies is to predict just their gravity and move-with-platform part... But in either case or solution you will loose one thing, which is the capability of doing accurate lag compensation... but that is another story...:)
Thanks for watching :)
You're right about not needing to compare positions-I don't actually do that in my code, but since I didn't want to get into the whole rewinding-and-resimulating part I figured that'd be the easiest way to explain what happens from there in a single sentence.
I definitely thought about predicting the boat movement as well, but that would've then meant also predicting the waves, and it sets the precedent of having to predict anything that moves which the player might end up standing on. Then again I suppose I've set a similar precedent in the sense that if I want to avoid jittering on other moving objects, they're going to need "proxies" as well...
I love how it just ends xD
haven't had to deal with server authority before, looks like a lot of fun ;) enjoy your next few weeks fixing more bugs!
"Fun". Yes, that...
Fun, so fun still exists
Fancy to see you here, I asked you about how you networked redmatch 2 in steam comments a while ago. Been a rough learning for me but fun nonetheless. Seeing this video just adds a layer of terror to the ordeal but it will be done...
@@kodi0223 xD Glad you're having fun!
@Limeify lol thats great
can't tell if i'm inspired to make a game or heavily deterred
love the videos!
Glad you enjoyed it! I can at least see the light at the end of the tunnel now, so maybe take it as inspirational with strong warnings about what you're getting yourself into? :P
Great video, Tom! Really enjoyed this one, and I love how you're so concise and clear with everything you say! Awesome work :D
Really glad you enjoyed it :D
ayoooooo
icoso spotted in the wild?
nice :D
hope you're doing good man
I feel your pain Tom, good luck with fixing the issues!
Your game looks sick :D
Thank you :D
just found you because of this video and got sucked into the rest of your videos watching your progressing of your game. Gave me inspiration man!
That's awesome! Glad to hear you've enjoyed the videos :)
Godspeed my friend, that's why I'm sticking to single player for the foreseeable future! Also the music that kicks in at 0:30 made me think That Chapter and I was worried someone was going to end up dead by the end of the video
A wise choice 😅
Great thumbnail :)
Lol only just started watching and it’s already great
Glad to hear it :D
I am soo happy I kept it ad 2d without physics and to something where single milliseconds don't matter that much. I really am feeling with you though, network-code is the worst to debug. Especially if you went insane like me and introduced multi-threading in the process, please just end my eternal suffering.
Multi-threading is asking for trouble 😂
You are doing great work man. The fact that you have gotten this far this quickly already puts you light years a head of others in the industry. To top it all off you are teaching yourself all this. That puts you even farther. I can't wait to see any tutorials that you (hopefully) put out for the new netcode.
Thanks for the kind words, that means a lot to hear :)
Oh my god that is the most hacked together solution I've seen in a long time. I love it!
😅
It's interesting to hear your experiences with implementing multiplayer. I'm writing a multiplayer game myself in Unity but it's simultaneous turns on a grid-based map so I'm not feeling the pain of realtime play, I'm sure I'll discover my own pains as I progress though. Anyway, I always liked this quote from Michael Abrash's Black Book on reducing player latency in Quake - Reduced latency also often makes for more frustrating play. It’s actually not hard to reduce the latency perceived by the player, but many of the approaches that reduce latency introduce the potential for paradoxes that can be quite distracting and annoying. For example, a player may see a rocket go by, and think they’ve dodged it, only to find themselves exploding a second later as the difference of opinion between his simulation and the other simulation is resolved to his detriment.
Yeah, hiding latency introduces a whole other set of problems to deal with...can't wait!
It's very wise of you to work on a game that doesn't require realtime play 😂
@@tomweiland Yeah, well actually no, I should have edited that. It is realtime but not realtime realtime. As in the players move in realtime simultaneously during their turn but they're restricted to a grid so I don't have to worry about little annoyances like physics and collisions. I've probably got it easy compared to you but there's still plenty to think about. It is at the same time both a 'fun' challenge and an interesting learning experience.
As a person who's just jumped into the ship of game development, I've decided that I want to make a multiplayer game at some point. So, I will absorb all of the videos that you have with issues and explanations/solutions to these issues. I've subscribed waiting for for the next video lol
I'm hoping to upload a new one in the next few weeks 🤞
Good luck with your game dev journey!
Yo, you finally got into the same problems I have been working on for the past 3 months. I was almost getting angry seeing you not having to deal with any of those. 😂
Why try solving problems when you can just _avoid_ them instead 😅
@@tomweiland Jittering is not a bug, it's a feature. It defines the status of chaos of the world making the player feel the uncertainty and instability of life. Latency also is important, it teaches the player to wait and have patience or to take initiative and get a better connection.
Ah yes...patience. Precisely what the gaming community is known for...
Nice video, keep trying with the multiplayer, you'll get there eventually.
Yep, I can at least see the light at the end of the tunnel now, so I'm hoping things will start getting less frustrating 😅
Wow! Amazing video. From the beginning to the end I was engaged and entertained. The only thing that could've improved this video was your jawline.
_Epic_ 🙌
I really appreciate learning from your experiences. Thank you so much for sharing your progress.
I'm happy to! Thank _you_ for watching :D
This was a really good video Tom. Great video editing as well. You can see the effort you put in. Good luck with the continued efforts and we all look forward to more updates in the future!
Thanks, really glad you enjoyed it! I definitely think this was my best video, despite being about a topic that can easily be very boring.
Good thing channels like this exist that talks about painful topics, having a beer beside you does wonders 🤣
😂
The pain which every gamer and program feels
rip my guy
It's been a looong 3 months 😂
Great video and I've actually been confronted with this issue today too...
My solution is very game specific, but it works out pretty well
Nice, glad you enjoyed it :)
Making multiplayer games with Unity is just a pain, it's so simple if you're aware of networking basics in Unreal ^^
🤷♂️
just amazing man , love this channel , ur multiplayer series was amazing , i loved it , ty so much
Thanks for the kind words, glad you're enjoying the channel!
Don't lie. DO NOT lie. No one said coding would be fun 😂
Touché :P
Coding is fun for m-
Sorry for enjoying watching your struggles on UA-cam :D Keep trying, it will eventually succeed (if it doesn't drive you mad).
Remembers me when my friend and I had had to use an obscure front framework and the correct data wasn't showing, it took us 3 weeks of heavy sweating and nightmares to discover it was expecting some weird null instentiatiation with no data to work...
"3 weeks of heavy sweating and nightmares" should be part of programmers' job descriptions 😅
Man, I am glad I'm only doing singleplayer.
I think if/when I eventually finish this game, I will build a singleplayer game next. Or at least a multiplayer game that doesn't require hiding latency to ensure a good gameplay experience. Maybe a top down RTS or something 😂
Or you can try building coop games where the client-side authority is usually enough
Thanks for the link to the articles. Very helpful.
Great!
Oh if only the players knew what we go through to make the multiplayer experience at least on the "acceptable level".. #PrayForNetDevs
True. I think we are under-appreciated :P
"You realize that you didn't read the documentation properly". Oh, if only! I can't even begin to count the hours I've wasted on following incorrect documentation.
The pain 😫
"Take 2 days to fix the error"
Me trying to upload my game to google play from past 2 days
1. Keystore
2.some random arc64
3.150mb limit
4. api
time taken 1- week
😬
Thanks for the heads up. I find struggle in every corner so I'm not surprised
Good luck :)
I did laugh with you at a couple of points. Streaming gaming services can't come fast enough. Your description is excellent, I think it was wise too stop before you got into estimating latency and forward calculating at the server. "Time streams" was a great phrase.
Still enjoying your vids, sorry it's being such a pain.
Glad my humor hasn't been stripped of me along with my sanity 😂
I'll figure it out eventually, I have the bulk of the pain out of the way now, so I at least see the light at the end of the tunnel :)
I'm hoping I explained things well enough with enough visual aids to keep people interested even if they're not familiar with programming and multiplayer.
@@tomweiland you explained it well enough for me to not build my own!!! 😂
LOL
Your wisdom clearly exceeds mine.
Nice solution for the boat moving calculation!
Thanks, though it's a mess. If I come back to the project I'll definitely be switching to just predicting boat movement on clients.
The irony that UE4 does movement prediction for you with very little effort. You just tell the server and client to move. And it solves the rest.
I mean that's nice I guess...but totally useless in my case. A generic prediction solution would have the exact same issues on boats that I'm having, so I would end up needing to heavily modify it (at which point it'd probably just be easier to write my own). I'm also using Unity and don't plan on switching-I like C# and don't feel like learning C++ right now, and blueprints are quite unappealing to me.
It's also worth noting that Unreal's netcode out of the box is really only good for small arena shooters with less than like 20 players (my game is not one of those). Epic themselves had to make modifications to get Fortnite to be able to handle 100 players on the same map.
@@tomweiland Yeah that's true, the MMORPG Ashes of Creation is being made on UE4 and they had to make their own proprietary networking to make UE4 capable of supporting a massive concentration of people (the Massive on MMO :P)
@@Hunsenbargen I would think this is mostly about reducing fidelity. Players that are far away don't need 60 updates per second or even 30. Even 1 update per second will go very far as long as they are running in a somewhat straight line or turning smoothly. You therefor only need to send frequent updates if they are doing something unexpected. As the number of players increases the naive solution is an O(N^2) problem.
I was going to say. A lot of these issues (not all) are solved in UE out of the box. I actually found it very easy to set up a multiplayer replicated movement model.
Hey Tom! Has been a while since I dropped in to watch a video by yours.
It changed, in a good way. You made me chuckle and it was informative.
Keep up the work, mate!
Glad to hear you like what has changed :D
"They" is every single non-programmer ever.
You may have a point 🤔
*Check out the next devlog:* ua-cam.com/video/cYLnVp1ngwA/v-deo.html
So yeah...this is where I've been for the last 3 months (although I did also enjoy the summer a bit). Thanks for watching :D
If you're interested in learning more about client prediction/reconciliation, check this out: www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html
Wow bro. Just wow. You've ran into your first major learning curve I'd say.
Prior to this you've done splendidly and really.broufht something great to the table.
Now though.
Your gonna have to learn how the big guns do it i suppose.
Why not contact aome AAA companies and ask about it through their human resources.
The Internet is obviously failing to provide decent documentation for you.
So ask how the big guys do it.
Might be a few neat tricks they use thar you can implement.
Just a thought bro.
I'm not even gonna attempt networking until next years project.
Was thinking about starting with your tutorials
@@BadBanana definitely not the first learning curve 😅
There's also plenty of resources out there on how prediction/reconciliation should work, but virtually nothing about how to ensure it works while standing on moving objects like ships. The only other game that comes to mind which would have had to deal with this is Sea of Thieves, but I'm about 95% sure they solved it the same way I did (with a "proxy" for the boat).
Hey to hype the game you should try recording the gameplay and uploading it
Did you use interpolate at movement? This a little trick can help you
@@myfantasycool yes.
This is actually a great explanation why standing on a vehicle in any multiplayer game like Battlefield series was always normally fine, but when it was moving, things would go spasmatic and probably end in phasing through the vehicle or dying for no reason.
Makes sense-as long as it's not moving, you don't experience the effects of objects from different "time streams" interacting. Once it moves though, 💩 hits the fan :P
Bro, I feel you so much rn, I am literally stuck at client prediction in my own game right now xd
Oof, good luck!
Best choice I made when creating my multiplayer game was switching over to Unreal. I've used Unity for years, learning all the ins and outs, but it lacks the tools for multiplayer development. Unreal has a ton of great features for multiplayer like profiling, viewing net corrections (aka where you f'ed up), controlling multiple players and simulating latency and packet loss. The cons are that it can be tough to find documentation on stuff and there are some videos out there that give bad advice (such as using blueprints for multiplayer; DON'T use blueprints for player movement, C++ is the correct way). Luckily, there are great videos out there that give awesome advice on how to do it properly.
Unfortunately I love C# and don't really want to spend a ton of time learning C++ just so I can use Unreal's multiplayer. Also, while I haven't used Unreal's netcode myself, I've talked to others who've said it's really not as great as most people make it out to be. Either way though, I'm not sure their out-of-the-box solution would take care of the problem I had here, so it's very possible I'd just end up having to solve the same issue, just this time using a language and engine that I'm not at all familiar with.
Now i understand why there was a weird lag when i jump off from boat Vanilla Wow.
Possibly :P
Hahaha I haven't even tried multiplayer yet, but I feel your pain. It's always some small error that you spend most of your time trying to fix.. Nice video!
Yeah, the small things always cause the biggest problems...glad you enjoyed the video :)
Great video! Despite being much shorter, it was definitely your best!
I agree! Analytics seem to be reflecting that too, it's doing twice as well as my videos usually do in the first 12 hours :)
@@tomweiland glad to hear that! I hope to see more like this.
wow the end got me dying lmfao, my everyday struggle and im not even as good as you.. It's a pain.
Welcome to multiplayer game dev 😂
@@tomweiland hahaha, you're the man tho, i really appreciate your work, i can watch your tutorials to understand a bit more about how things are done. Keep it up! :)
Funny, we made the exact same decision recently !! We’re going to onboard a networking specialist in our second release probably ! Nice content !
Wait, the exact same decision as what?
@@tomweiland sorry was a late night message ☕️ I meant we’ve started to look into client predictions as we are building a multiplayer element to our game - turns out to be a bigger can of worms than we expected 😖😂
I mean client prediction itself is still _relatively_ okay. The problems really come in when you need it to work on another moving object like a boat...
@@tomweiland yes we don’t have that issue so much.. for now….
You're really good with analogies!
Thanks 😅
If I understand game networking correctly, there are 2 general approaches of syncing client's state with server's state.
1) Delayed input - you submit input and wait until your world state is set by server. It allows world behave smoothly on all clients, but your inputs are now less responsive.
2) Client prediction - you submit input and instantly simulate what should happen. Server then modifies your past world state and you reapply your input history, effectively correcting the present. It makes your inputs responsive, but since each new modification skips some of it's personal time, sudden events now look abrupt unless you somehow awkwardly interpolate them. Or instead of reapplying history you could accumulate error between client's and server's predictions, and then slowly/instantly use it to displace values.
You can use both of them, each for it's own system. Delayed input may be used for walking around, and client prediction - , with "server feedback" part possibly omitted, - for moving your head around.
And only in cases when ping is above 30-40 ms differences between those two methods become clear to a user.
With first approach you'll have slower inputs, and second one will make everyone around you walk a bit weirdly. First approach is simple to implement, and second one requires you to remember an input chronology, timeline of entities that can move and are near you; but it also allows for competitiveness in platformers or shooter games (although it takes some extra cpu).
=================
Also, some notes:
- You have to account for high-ping cases. Ping changes over time - it may suddenly skyrocket and then fall down, and it isn't always low between two computers of the very same country. Be cool and expect the unexpected.
- Not everything at all times should be broadcasted to everyone. You should only frequently update objects/features, that are close to respective clients and are hardly predictable. And you also shouldn't forget to have even minor details updated from time to time (positions, lists of existing entities), or else you may end up with severe desync. Especially if you often use UDP.
- Server world state may intentionally lag behind players (or players may simulate ahead of time) just to accumulate player inputs and resolve conflicts when two players press key practically at the same time.
- When some continuous non-physical state (eyeAngle, walkDirInput) is received by client, it should be interpolated or extrapolated.
- Server may calculate some events (headshotting someone) from perspective of what player had seen during input submission. This is called lag-compensation, and should not be used when player's ping is far too high. And it may be useless if server-state stays behind on timeline, and so it knows what both players were doing during the headshot tick (or so I think).
=================
^I didn't write it just now, it's something I entirely made a year ago
Yeah latency itself is annoying, but on top of that you have to account for a lot of unpredictability-ping fluctuations, lost packets, duplicate packets, etc.
I use a quantum entangled network card for my laptop, it has no latency. Then I just coded my game as if it was a split-screen game. 10/10.
Where do I get one of those :P
0:59 lol my ethernet cable came loose and made the video buffer while he was talking about latency
What a strange coincidence :P
I think player movement can be handled locally, but if the player moves beyond the sphere of allowable mismatch and for too often, it can be verified more and more by the server.
I used something like a "suspicion" tracking variable, where someone speed hacking or teleporting quickly finds their movement entirely server-authenticated.
So it trusts the client initially, but the trust can be lost for a time.
Multiplayer coding is absolute hell, just getting a game to finally accept connections was a whole endeavor...
The problem is that checking speed or distance traveled doesn't account for things like collisions, and those metrics really say very little about whether the movement is "acceptable". A system like that wouldn't catch someone who's walking through a wall, or someone who slows their gravity down so they fall slowly, and making the system capable of detecting those things essentially requires simulating all of the movement logic on the server.
At that point, it's arguably easier and less work to just give the server full authority, and by doing so you'll also avoid dooming yourself to playing the cat & mouse game of hackers finding ways to exploit/evade your detection systems and you having to react. At the end of the day it just comes down to what tradeoffs you want to make-I prefer giving cheaters as little chance as possible to gain an advantage :P
Before you got to the part where you wanted to get back to the practical side of things 4:13, I immediately thought "why not use a decimal data type and clamp the position to the nearest median? The difference is negligible." Also, to fix your new problem, it starts off with how you tackle the problem. First off, depending on your set up, the water becomes the parent and the objects such as ships and the terrain to walk on become the children of the sea. When the boat sails out to the sea and hits a certain local distance in the water, the land itself moves away from the boat and the water instead; This has the server calculate the position of the static land (and local position of the player), not the boat.
_"I immediately thought 'why not use a decimal data type and clamp the position to the nearest median? The difference is negligible.'"_
What exactly would this accomplish/solve?
_"When the boat sails out to the sea and hits a certain local distance in the water, the land itself moves away from the boat and the water instead; This has the server calculate the position of the static land (and local position of the player), not the boat."_
Are you suggesting that I make the boat stationary and move the land and water around it in order to make it _look_ like the boat is the one moving? That sounds _at least_ as complicated as the solution I ended up with, and it has many more problems. What should happen if one player is standing on a boat and another is on land? What should happen if there are 2 boats? Which one should everything move in relation to?
I feel your pain, and I haven't even started making my game multilayer
Oof.
I started, but hoping my game doesn't have anything complicated to run into these issues! lol
I had the same problem when I created my first multiplayer game too, but I found out that letting the player move only after getting the move message from the server worked better than trying to predict the player’s future position on both the server and the client at the same time. The process was: player presses W -> sends it to server -> server check if the move is valid and instantly sends back command to tell client to move the character.
The latency can be forgiven because most of the time it happens in less than one frame. That way, I can focus on reducing the message size instead of trying to correct the player position, which is a dead end.
Waiting for a response from the server before moving quickly leads to an experience that is sufficiently unresponsive for it to feel awful. A 50ms round-trip time is plenty for the delay to be noticeable, and I'd argue that it's unreasonable to expect most players to have less than that, especially when you factor in the added delay from your tick rate (lower tick rates mean bigger gaps between ticks, which effectively increases the time it takes for the server to respond) and from slightly buffering positions so you can interpolate them and have the movement look smooth.
Players with powerful rigs and high refresh rate monitors will also be more likely to notice delays than players whose monitors max out at 60hz.
_"The latency can be forgiven because most of the time it happens in less than one frame."_
This is just not true in my experience, unless you're testing with the server and client on the same network. At 60hz you have a frame time of ~16ms, and the vast majority of your players will almost certainly not have a round trip time that's less than that. Someone with a 144hz monitor will have a frame time of just ~7ms, so even if they somehow had a mere 25ms round trip time on their connection, at least 4 frames would pass before they see the result of a key press.
interesting idea with syncing the player position relative to the boat, but you could skip the floating boat, just synch a parent id + relative position over the network!
The problem with that is that it doesn't account for the discrepancies/delay in the boat's rotation, which would still lead to jittering/mispredictions an various situations. That's part of the reason why I went to the trouble of adding a "proxy" boat-it doesn't need to rotate so it just avoids that issue entirely.
5:09 Little tip for recording long texts where you run out of breath:
take little stops inbetween to breathe and cut it out in editing so you have a more chill recording experience :)
Thanks, but it was honestly just a joke :P
@@tomweiland considering how often I need to cut down my audio, I honestly related too much to see the joke 🤣
Us old hats remember Internet 0.4 beta, before the latency feature was added
The good old days :P
Sounds like fun :D Sorry you went through these issues but this was very informative! It starting to sound like the Marvel Multiverse with all the client and server prediction stuff haha. Glad you got a lot of the latency/jitters fixed, at least with a single player in!
Welcome to the Unnamed Pirateverse 😂
You probably want to keep your control over the server, but if you ever decided to switch to Photon, it has an option for extrapolation to enable Photon's server to predict where a player's transform may be in its Photon Transform View Classic documentation. I'm unsure of how well this will work for your game, but in case you weren't aware of this option, thy has presented it.
Wait, it predicts the location of _other_ players? That's normally a major no-go in first person shooter games...
@@tomweiland I see, I've never needed to use the option myself, so thanks for letting me know
I had a very similar experience working on a multiplayer FPS i never ended up finishing. I avoided the issue with player-movement by using a character controller, however, I was having lots of issues with rigid-body projectiles. It was such a pain in the head I ended up scrapping most of them.
Hmm, you must have had a different problem then, because using the CharacterController instead of a rigidbody controller wouldn't change anything. I'd still have the exact same issues...
Glad to see you're back.
Yeah...only took 3 months :P
@@tomweiland progress is progress, my dude.
Ran into this few months back and its hell , i hope you make a detailed video about prediction for just the player movements
Yeah, I'm considering _maybe_ covering it in a tutorial at some point in the future 🤔
My niave solution is to move the client position x% closer to the server position. It'll be smooth and generally not noticeable unless there's a significant difference. And since it averages the two systems (client and server) should get back in sync. This is mostly theory at this point tho.
The problem is that the client is simulating ahead of the server, so if you don't correct fully then your starting point for future tick is still incorrect and will lead to larger divergences more quickly. What you _can_ do is fully correct the player's collider/state, but add a bit of delay to the visual so you can smoothly interpolate to the new position.
That last part gave me goose bumps, and not the good ones...
😬
I don't really understand how the solution of the second boat not moving works but that's cool as hell that it does.
😅
Basic dead-reckoning problem, easy solution actually. You always use the client to determine their own position, the server's job takes the incoming movement data to determine velocity maps while testing to ensure players are within margin of where they should be given timestamps of their updates and relay those maps to other players.....then the clients can tween the values against current positions and increase/decrease speeds as needed in order to pinch position faster for sighting other players. Any "pinpoint accuracy" measurements can be checked by the server through the same tween algorithms to determine if the player actually was "on target" to another player during that timestamp. Since velocity maps are checked against timestamps, speed hacks are found quite easily. Auto-aim bots are not as easy with this, but that can be checked based on precision movement checks through obstructions.
No jitter, no forced movements, and everything is quite smooth. The only downside is clipping of players when tweening values if they get too close to other objects when making turns....you could use a spline tween, but it can look unnatural sometimes.
You say there's an "easy solution", but then proceed to describe what arguably sounds _more_ (certainly not less) complex & time-consuming to implement, while being less secure...but if that's how you want to do it, go ahead :P
I'm also not sure that it makes much sense to apply the term _dead-reckoning_ to first person player movement, given that players can literally turn around and start going in the opposite direction on a dime-unlike boats, cars, planes, etc.
@@tomweiland code it, you'll realize what the "easy" part is. DR is what they call it, I don't know why, I really don't care, it's like 10 lines of code. Have fun.
You can fix the jump when going on and off boats with a sigmoid function to interpolate between the positions
Yes, interpolation would be able to hide most of the jitter in most circumstances.
you need to rethink your architecture if the boat is not working out properly. World of Warcraft did zeppelins. I am sure it wasnt easy but it is possible.
1) try doing everything in ticks
2) try doing everything in deltas with deterministic state machines
It's not inherently an architecture problem-the issue of how to deal with moving platforms (which is what my boat effectively is) in multiplayer is widely-recognized as a very common problem with no real solutions that work for all scenarios.
I've never played WoW so I'm not familiar with how the zeppelins work, but depending on the restrictions you place on players while on board the problem can be very easy to solve. For example, simply restricting the player's ability to get on and off the platform/zeppelin to the times where it is not moving would allow you to just sync the player's relative position with no issues (as long as it only rotates around the Y axis).
Another approach is to have clients predict the position of the platform so that it exists in the same "time stream" as their local player objects, but this will then cause problems with how players see other players interacting with said platform unless you predict other players' movement as well (which is tricky business since you don't have their inputs in real time).
I will probably try the platform/boat prediction method in the future, but the point is that every approach to solving this issue has downsides and tradeoffs. Which of those you're willing to make depends heavily on the game and specific use case. Simply "doing everything in ticks" (I already am) or "in deltas" doesn't solve the issues that come with objects from different "time streams" interacting.
Awesome video! Yeah multiplayer is a real though one. I personally have not tried multiplayer in Unity3D but tried it in JME3 with SpiderMonkey. But it looks like you are almost perfecting it. Keep it up! :)
Haha yeah it's definitely a bit crazy once you get into the deep end :P
It's definitely a different vibe. Once you get used to it, there's still always things to learn in order to optimize, etc. Object oriented programming, server is king! Replication is there just to test patience. Hahah! Good luck out there game devs.
Yeah multiplayer is a whole different arena :P
Thumbnail is awesome xD
Haha great :P
i am big fan of games that can use multiplayer criatively like clash royale that transfer a simple card info and the position in the field and even if you lag the server do the recalculations and sincronizes the players, it moves so simple info but works so well for a vs mobile game that is awesome
I mean when you only need to deal with card spawn positions, that makes life a whole lot easier 😅
If you manage to solve your problem with ships you should add splashes when the ship bounces downward into the water.
Yeah I'll do that eventually :)
Honestly I had at least 2 good laughs with your jokes, thanks man.
The pain is shared :)
Glad to hear it :D
I think the solution for boats is to use the origin of the boat as a temporary world origin while you are on it. Also, your waves must be driven by a deterministic algorithm, like a noise function, and sync the input used in the function across players. That way, the boat movement will be smooth since it is calculated on the client and the waves will mostly all be the same. Look at how Valheim implemented this.
I want to avoid predicting the boat movement though because the more things I make the client predict, the more likely it is for mispredictions to happen, which will result in more corrections. Also, predicting boats and other physics objects would severely complicate the reconciliation system because suddenly I'd have to rewind the whole simulation, not just the local player (which is currently the only simulated physics object on clients).
I feel your pain man, and what I tried to do was much more primitive :D
😅
The first 30 seconds resonate with me so much
Haha I figured many people would be able to relate :P
Best devlog vídeos on youtube.
I'm honored 😅
Great video, thanks for sharing. Funny as well, which helps 😃
Glad you enjoyed it!
It's painful how relatable this is, how the video ends in basically failure and a long list of issues to fix in the morning xD
Hahaha :P
I really feel you.... Had the same issues in the past.
I can't wait until I can also talk about this stuff in past tense 😂
Awesome video Tom!
Thanks for watching!
It might be very difficult but once you fix a problem it's so satisfying. And then there's 20 other problems after you fix one
99 little bugs in the code,
99 little bugs.
Take one down, patch it around
127 little bugs in the code...