I have been making controls for a fighting game for a while now, and I have run into an issue where I am unsure of what should I determine as too important for the client to handle.
What I’ve determined is:
Controls (Movement / Jumping) is too response driven for the server to maintain
Combat mechanics are too important to give the client (Hitboxes and the like), yet needs to be responsive as well (Animations/Sounds).
After looking at the “Laggy Cannons” demo on the wiki. I am unsure of where to put the bulk of my combat controls.
For things like combat, you generally get the best results from doing it both on the server and the client. Detect on the client while storing past positions of players on the server. When the client tells the server they hit someone, verify that they could have made that attack with the past positions. Instantly show on the client, but only replicate on the server and to other clients if it’s legitimate. This prevents them from attacking others unless it’s possible for them to legitimately do as well. They can auto-target still, but they can’t shoot through walls by spoofing remote data.
As for auto-targeting/similar, don’t even bother trying to prevent that on the client. If they wanted to, they could run arbitrary code completely independent of yours that moves their mouse over targets’ heads and clicks. The only thing you can do is check to make sure they don’t have perfect accuracy (i.e. every hit position is the exact center of the head), but good exploiters will intentionally be somewhat inaccurate to make legitimate/artificial accuracy indistinguishable.
You have to simply accept that anyone cheating in a combat game is going to utterly dominate, no matter how careful you are with your netcode.
You should aim to minimise the number of people who can figure out how to cheat, and quickly ban those who succeed.
Cheaters generally have little to no programming skill. More than the average Robloxian, but that’s not saying much.
So, you can eliminate the majority of cheaters by having the exploits in your code not be easy to understand, or be difficult to take advantage of.
For example, in an FPS game, instead of having damage(target, amount) as a RemoteEvent you instead have hit(target, bullet), destroying the serverside bullet and damaging the target.
This means that a cheater would have to be competent enough to write a script that finds the nearest enemy, and change the gun so that every time it fires the bullet it creates instantly hits that enemy.
The vast majority of cheaters can’t do this, and cheaters are already pretty rare.
So, by adding a programming skill requirement to cheating, the already tiny number of cheaters is reduced to the tinier subset of those who can program.
You can expect a flood of PMs if such a cheater shows up and starts ruining everything, your choice as to whether you ban immediately or investigate if they’re actually cheating.
If you ban them, they’ll likely make an alt.
However, if a player has an account less than a week old and they’re absolutely dominating in your game, they’re obviously cheating, so you can automatically ban them.
I wish TF2 would do this. Low ranking snipers at the top of the leaderboard are always aimbots, and vice-versa.
So, with these countermeasures, the only time a cheater won’t be prevented or automatically dealt with is the extremely rare occasion when a competent programmer decides to cheat using their main account.
I disagree with this being a good approach. It just adds a layer of abstraction on top, it doesn’t actually change the authority of the client. Security through obscurity is not real security.
Here is how I would do it:
The client should apply the hit effects locally (particles, sound, whatever you have) and inform the server about that they think they have hit someone. The server will then perform some simple or complicated (depending on your stage of development) checks to determine if the hit was feasible (not through walls, not coming from a different position as the shooter at the time of shooting, and that the shooting direction matches, etc). If the hit is deemed feasible, the server applies damage accordingly which is then replicated to all clients. If it was not feasible, it does not apply damage, and no damage is replicated.
TLDR: server-side checks, server is the authority.
That’s not a good idea. There is no way to infer that they are using cheats if they’re really good at the game. They may have played similar games before, or are intentionally using an alt to play, etc.
I’ve never seen a case of cheating that isn’t handled by my strategy, with the exception of competitive players who use really subtle cheats that can’t be prevented by good netcode anyway.
You may object to autobanning new accounts that do absurdly well in case there are new accounts that legitimately do absurdly well, but those simply do not exist.
When a newbie is achieving a score that even an experienced player is unlikely to get, they’re either:
A: An alt created to cheat.
B: An alt created to “smurf”, only applicable to games with ranked matches. (“Smurfing” is when a player who is extremely good at a game makes a new account so they can play against newbies. It’s considered cheating, since it’s a player avoiding the ranking system so they can dominate everyone on the server)
The massive elephant in the room, IMO, is that the built-in Roblox humanoid scripts are designed around clients having network ownership over their character. Even if you are doing everything right (like running all the hit detection on the server) the fact is that clients still have total control over their character’s physics simulation and Roblox will happily accept any changes they do to their CFrames and broadcast it to other players.
I was looking into ways to make a proper server-authoritative control scheme and the best I could come up with based on my experiments was:
pass character network ownership to server
Create a version of the control and animate scripts that sends/receives RemoteEvents so it can run on the server.
Locally, each client would then hide their server-controlled character and create a local-only clone.
Inputs are then applied right away on the local character while they are sent to the server, who applies them to the real character. The client will correct their local character if it deviates too much from the server-side character.
This is a lot of work, but it would match the way “big boy games” do server-client simulation.
Banning isn’t always the solution as it can be called a “temporary” solution or a “quick solution”. The best solution is to stop further problems which is to patch the problem.
Someone probably has multiple alts that are more than a year old (like myself as an example) or someone could just be great at the game. That seems stereotypical and unreasonable from what you’re saying. What if a legit player got banned just for “being good” at the game? That player would be upset.
The most reasonable solution to aimbots getting on the leaderboard (from what I know) is to enable the leaderboard for players that have a playtime of more than three days. That isn’t the best solution as it doesn’t actually patch the problem but it is reasonable and temporary (because obviously a player could just play it for three days and then get on the leaderboard). It might be possible to patch the problem, you just have to think.
Legit players would only ever be autobanned for smurfing, since autobans only apply to new accounts.
Plus, I don’t think you realise how high you can set the autoban threshold while still autobanning every single cheater using a new account.
If a game is well-balanced, there shouldn’t be anyone getting a kill every few seconds and never dying, no matter how skilled they are.
You could make autobans apply to accounts up to a year old and you’d still never have false positives.
Anyone who thinks you can’t consistently distinguish an aimbot from a great player based on their stats has clearly never seen an aimbot.
Oh I see now, makes sense. It’s basically impossible for a player to kill each player every second without dying. That’s something I did not think about. Although it would probably require a lot of testing and balancing to make sure the system doesn’t throw a false positive. I like how you thought of that, really great solution.
Exploiters could delay a few seconds to combat with the anti-cheat but then it isn’t really an aimbot and it reduces the “cheating” as it isn’t as fast as killing players every second; I like your solution. To add onto that, the script would also detect if you haven’t died after a x amount of kills in a x amount of time which would make bypassing the anti-cheat very difficult. Even if they do manage to bypass in someway, it isn’t really “cheating” and becomes pointless of using an aimbot. Scripting this will take a lot of time and effort as it has to not make any false positives and at the same time, kill the cheaters.
If an exploiter happens to delay their aimbot- If a player happens to kill a lot of players in the server because the players in the server are not very good. To stop that very good player from being banned, it is possible to make a complex code to “rank” each player’s skill. For example, if a really skilled player is killing each player in the server because they’re not very good at the game, then the skilled player isn’t cheating. This can also apply vice-versa.
I know that exploiters won’t really delay their aimbot and it can become pointless because it isn’t as fast of killing someone but these are all possibilities (e.g. snipers). The majority of aimbotters will kill players every second, that’s just the main problem. Once you have the main problem resolved, you can then look for smaller problems. Smaller problems may not even be worth resolving. I just thought I should mention the possibilities. What I said may have some problems but nevertheless I do like to mention them all anyway.