Responsiveness (Input-lag caused by networking is not acceptable.)
Exploiter proof (If someone is able to, for example, increase the speed of the car, the exploiter will win every time.)
You might already have figured out where I’m going with this. If you want to have responsiveness, you want the player to take NetworkOwnership of the vehicle. Doing this, however, will make it easier for exploiters to modify it. They could increase speeds, turn constraints faster than they should etc.
I don’t think it would be a good idea to make the car completely server-sided (and have the client send controls to server) because this will cause unacceptable lag in a racing game.
So I would have to add server-sided checks to check if anyone is exploiting. How would I go about doing such a thing? Will checking the speeds also work if they teleport the vehicle? (Will they even be able to do that?) And will I have to make my own collision scripts too? What about laggy players? Will I get many false positives?
Any tips that can lead me in the right direction will be highly appreciated.
Just do all the vehicle movement locally. It really doesnt matter considering that w/o the client owning the physics it would move laggily anyways. replicate stuff like sound pitch and etc manually.
You could send information to the server about the vehicle or character position, then check if the previous data and the new replicated data are not too far apart. That way you can check who is actually going too fast. You can do the same for rotation values as well. Check the rotation and have a simple match function to check if they rotated to fast. Sure, exploiters might be able to go a little faster but won’t be able to go to fast as that will probably be noticeable.
The other thing you can do is set everyone’s max speed and turn rate to a specific value every second or half a second using the server. You can also do this locally but if an exploiter figures that out, they may change that value as well. However this is unoptimised and is usually a last resort.
This would not affect exploiters. The technique you mentioned is better predictions about where a vehicle on another client will be, regardless of whether the vehicle is going normal speeds or ten times as fast after being changed by an exploiter.
My point is that he wouldn’t have to give network ownership, which means he could keep them server sided, and theoretically keep them away from exploits. The best thing to do in my opinion would force all cars to run off stats in ServerStorage or somewhere else secure.
Yes but server sided is bad, you get input lag like in Human: Fall Flat and the game does not run smoothly (due to server load) and from server sided actions replicating. The whole point of network ownership is to avoid that. The issue with every game is that exploiters will exploit. The only prevention you can try while keeping the game playable is some server sided checks and maybe a few client ones assuming some dont destroy the script.
My Feature Request suggestion is to have predictive pathing, similar to GTA V does for their races. It works pretty well. It’s never going to be perfect, but it’s more acceptable than the alternative.
Assuming a client action cannot be predicted, the other clients will always be at least the latency of the acting client’s upload latency plus the receiving client’s download latency behind the acting client. This is the lowest latency that can be obtained without allowing direct peer-to-peer connections, but that is a security/privacy issue.
The best you can do to reduce latency’s impact is to intelligently hide this on client systems (interpolation and extrapolation). When a client receives another client’s action, it should interpolate the current position to current position the object owner has. This can be done using timestamps and mathematical formulas. The players with less latency will be at a slight advantage. If you perform calculations on the server that take latency into account to rebalance the playing field (allowing players experiences to be impacted by other player’s latency), then players can exploit the system by introducing artificial latency. You could try to catch the exploits, but the industry has learned from sad experience that it becomes a never ending cat and mouse game. As a game owner, you can only do so much with what players bring to the table. They will be negatively affected by their latency, or negatively impacted by exploits and/or development time to patch exploits.
Now, as for the issue of client or server ownership. Client ownership makes each player see their own movements quickly, but because they receive their own movements quicker than other player’s movements, the effective latency between the players is greater. If the server owns the objects, then some of the effective latency between the player’s is reduced but introduces latency between a keypress and visual/audio feedback. This makes for a poor user experience. I would do my best to reduce the effective latency by altering the speed of actions based on a player’s latency.
Server Ownership
While this could be done with client ownership, it is more secure and easier to implement when setup with server ownership. When a client sends an action, it immediately starts performing the action visually, but the action is slowed down by the ratio of the client’s download latency over the clients upload latency and download latency. By the time the action’s effect gets back to the client from the server, it will be in approximately the correct state. This allow the user to get immediate feedback without reducing the effective latency between players.
Not using the ratio, any increases/decreases to the ratio, or error in the predicted latency, will mean that the action becomes extrapolated and ends up ahead/behind of the state it should be in when the official action comes back from the server. This may be fine, but the client state should be interpolated to the official server state. If the client continues to perform actions then the distance between the client state and the official state will continue to grow, so a function should be include to increase the speed of the interpolation to keep the distance managed. If there is strict adherence to the ratio I gave, then this distance will only increase due to error in the latency prediction (which hopefully should be negligible). An increase in distance means an increase in effective latency. So, keeping as close to the ratio as possible without impacting the user experience is desirable.
Since these operations are performed on the server, security is also guaranteed. Now, you may want to transfer ownership of objects when it can be safely done without giving players any advantage / benefit. An easy example of this is Aesthetic objects. Gameplay objects dependent upon distance to players can also have their ownership safely transferred until they are within range of a player.
Client Ownership
Another method would be to perform all operations on clients. Not only is this less secure than running core gameplay mechanics on the server, but it also means that the effective latency between a player and players around them is increased. You could have the client perform the same ratio slow down as described above to fix the effective latency issue, but that leaves us with an implementation almost identical to running the core gameplay mechanics on the server but without security, making it more difficult to implement (you have to run lots of checks for security, and possibly play a cat-mouse game with exploiters).
If anyone else has better methods, please let us know!
Here are some similar and fairly recent topics for reference and ideas:
Yes that makes sense however there is still the problem where the load on server is increased from any calculations you are doing for all of their vehicles or whatever as opposed to doing it locally where each client has their own load. There is still also the problem with connection (lag spikes on client end) and server lag as well as ping causing input to be delayed more than usual and making inputs hang (for example steering wheel stuck in one direction when server has lag spike). A lot of games do client control (actual ones included) and it is for a reason. In my previous example, you can see the problems with server based physics/control in that game I had mentioned. Sure everything is more accurate but it is typically harder to play and is really hard to make work efficiently, rapidly, and without physics and input latency (at least for the driver of the vehicle). The issue is you need to balance security with playability.
The concept is unavoidable and the decisions you make can change how the game works and how it feels. A lot of things can occur such as gun spamming, teleporting, speed cheating, and more. That is why however, report systems and checks exist. Also, you cannot predict what a client is going to do before they do it so unless you are interpolating values, the ratio wont really help. Also a simple replication method would be to send sounds and other items to server (or values such as brake amount) and have server set the values (while clamping them with a range and also while simultaneously setting it clientsided). This is an example of what I do for my vehicle system. This works for servers with 40+ people and such and the game runs fluidly (aside from the desync). I have a vehicle config available to both client and server which allow me to check the values and interpret them. You can also potentially reach a request limit if the user spams controls (unless you prevent that by keeping an array of input data that is sent every few ticks instead of sending it immediately) whereas i only send my replication data every few ticks so there is not really a way that would happen. I want the game to look smooth and amazing for the person who is playing it, and this requires a bit of sacrifice but it pays off in the end if thats what youre going for.
In practice I’d expect this to be most objects, besides the vehicles, and road sections/obstacles near players. I don’t think this would ever become a performance issue.
You are talking about multiple situations here, but I actually think that some of them are where server ownership really shines.
If a client lags when the client owns an object, then other clients see them rubberband/teleport. This also allows the client to break regular gameplay logic, and may set off exploit checks. When clients own the objects, an exploit can be indistinguishable from latency issues. The client with latency spikes will also see all other clients rubberband/teleport no matter if the client or server owns the object.
If the server lags, then no matter if clients or the server owns objects, all users have a poor experience because all communications, both when clients or the server owns objects, stops. If clients’ own their own objects, then clients’ can’t see eachother’s input and when the server unfreezes everyone teleports and mass havoc ensues and people crash into eachother. If the server owns objects, then the server will have to send out an update and has some options when it resumes. It can either tell the clients to resume from the last position before the server went down, or allow clients to teleport like in the client owned objects example. Perhaps it could handle is some other way – the game is its oyster and it can decide how to handle it, since it has all the information! With the client owned model, it doesn’t make sense for the server to be making these decisions, although it could politely ask clients to do what it wants or face being marked as an exploiter. (Heaven forbid they don’t comply in time due to a temporary loss of connection…)
Basically the only difference between server and client ownership is that it is easier for the server to decide how to remedy the situation. But why is the server lagging in the first place? That sounds like the root of the problem and should be avoided.
I’m gonna call you out on this one. While I can’t look at game source code, I hope articles online give a good representation of what is done in games. Most articles are on peer-to-peer vs client-server models with an authoritative server, and they still prefer client-server models even though a peer-to-peer model has less latency than what we can do on Roblox.
When I type “client or server control for racing games” in google I get these articles (in this order) as results:
Most of these articles describe client-side prediction of what the authoritative game server state will be when they receive the server’s response. This is exactly the method I have described, the ratio being used to predict that game state.
I think this shows that perhaps my explanation was bad, as it seems you have misunderstood. The ratio is used client side to interpolate what the authoritative game state will be when the server’s response gets back. In the authoritative server state the player will continue driving forward for a bit longer, then turn and travel faster and by the time the server’s response gets back to the player then the player moving slightly slower will be in the same position as the authoritative response, plus or minus latency estimation errors. The ratio isn’t about predicting what players will do.
In similar discussions on this forum, many seem to agree with you. But I disagree, and Google seems to agree with me. I havn’t found an article that supports client ownership on a client-server model, but would have posted it if I did. If you do find one, please don’t hesitate to post it so both sides are represented!
A lot of games do this hence why vehicles work offline and why they have little to no input lag and also why people can teleport noclip and speed with them. Same with shooter games. Also what I was talking about by inputs hanging I mean it would be increasingly difficult to drive the vehicles. If you want an example of a server controlled chassis I made, this is it (After playing for some time the input may start to lag for a small while). Compare this to the performance, less lag, and detail going on in my client based chassis. The issue is that, again, security and playability need to be balanced. There are so many problems with doing too little on client and doing too much on client. Having a game entirely server based usually never works unless the connection is really good and consistent. Another issue is with the fact that the server is a relay in order to protect people and because they do not have a specific host. This concept is also easier to set up in a game where the connection is practically direct. For something like a roblox game a lot of the physics would have to be rescripted manually.
Have you considered that exploiters can make your game less fun for everyone else that is playing?
Exploiters killing people, winning races by making vehicles faster, etc.
By the way, if you say you don’t care, why even bother posting on a 3-year-old post?
Because I’m working on a racing game as well and this is relevant.
I don’t care to the extent that the exploiters don’t ruin the fun. The point being I’d rather focus on performance than safety checks.
I’d also add a report system that would store 50 reports from a player and if they’ve been reported too many times they get kicked out of the game forever.
We are still pushing for this issue. Not possible to get this lag fixed and now that Roblox has steered away (pun not intended) from using the classic tank chassis, I don’t think it’s ever going to happen. If you are reading this now. Might as well move on.