Hey, so I was just thinking about which way would be optimal when I dig into programming this.
So, there’s a leaderstat called Money. Every time the user clicks this button on their UI, it’ll increment their money.
Now, I obviously figured it’d be easier just to call a remote event to the server to increment that value each time the user clicks…but that could be a lot of calls, and I’m not sure if it’d be more efficient to increment a variable within the code each time the user clicks, and then update that over to the server every so amount of seconds, but that could possibly open the door to exploitation, and there’s also the idea of how to save it if the player leaves, and it hasn’t updated yet.
Either way, I’m just looking for advice here. Thanks!
No clicker game is safe from autoclickers, that’s the nature of the game. What I would recommend is having click processed on the client, but sanity checked on the server.
So you could do what you said here
and then simply check that amount of clicks divided by the time they happened in is not an unreasonable amount, and if it is then roll back to before the last sanity check
You could invoke the server lets say, every 5 seconds with data showing how many times you clicked the button during that time, and then compare the total data between the server and client to fix any errors. This should reduce lag to an extent.
Also, make sure (on the server) to check if the data is acceptable, too. For example, don’t allow a client to be able to gain 500 coins in one second just because they clicked 500 times.
EDIT
Similarly to what @snorebear commented, you could use data from clients to work out their average CPS, or use a standard area of acceptable CPS values. There will always be a way for people to go around this system, but there’s not much you can do after that.
Problem here is the standard click ratio that you want to use. Because if someone just happens to click really fast, it’ll simply set it back. That can be especially painful for high incremental checks like @UltimateRaheem is suggesting. However, having it set to high will permit certain autoclickers. Truth be told, you’ll just have to have a medium in this or not have it at all.
Calling a remote every time a user clicks shouldn’t be a problem at all for the server. Multiple front page games are able to operate smoothly while receiving hundreds of calls a second from players firing a remote every heartbeat.
My game I’m currently working on receives up to 2400 calls a second without much of performance impact.
I agree with this, too! I’m beginning to tackle projects using a lot of BindableFunctions and BindableEvents. They really simplify your work and help you visualise what’s going on. @Zomebody even said that it’s almost like service programming, which I like!
I think it really depends on what callback you attach on the server.
If the callback is expensive and takes time to complete, then you may end up with exhausting your invocation queue quickly, as the server can’t handle all the events. This is always bad.
How many times a second? I’m pretty sure you would end up with performance problems firing a remote event over 2000 times a second. Unless your server callback was an extremely light task, firing 2400 times a second is not reasonable.
You could potentially record the time difference between clicks, and if it’s the exact same every time you can be more certain that the clicks are fraudulent.
You could also only set it back if there were multiple fraudulent “click sets” in a row, to avoid false positives.
That would be a poor decision on the basis that we are assuming the client is a human being. As we know, people tend to make mistakes and the click rate will change from time to time. It could be fatigue, adrenaline, etc.
If you’re intending to use constant click rates as an indicator of autoclickers, don’t leave this as your only defence.
It makes a lot of assumptions.
First of all, if you check the click rate on the server you’re going to have your check messed up by network latency. The remote event takes a volatile amount of time to reach the server, making the check useless.
Secondly, even if we were in a perfect universe where the remote takes no time to travel, a dedicated cheater (I refrain from calling an auto click user an exploiter because what they are doing does not fit the definition of exploitation) could create an auto clicker which randomises the click rate, but still keeps it very high. This makes the check useless again.
Finally, if you do the click rate check on the client, the cheater could become an exploiter and simply delete the local script handling the check.
In short, this check will not solve the problem of auto clickers. In fact, it may not do anything at all, for the reasons I outlined.
Any data recorded, such as time between clicks, would be collected client side, to take latency out of the equation, and then checked on the server.
With the systems I have proposed, an abnormal click rate for a couple of seconds would not be enough to create certainty that the client is cheating.
The LocalScript “handling the check” would also be the script detecting clicks for genuine gameplay reasons, so good job cheating if you’ve deleted it.
The actual script “handling the check” would be server side, as I’ve stated a number of times.
No clicker game ever has a foolproof defence against auto clickers.
It’s also worth considering that it might not be worth trying to stop people with auto clickers. Unless their success has a direct impact on another player’s game play experience (very rare in clickers) there’s no real harm in letting them enjoy the game in their own way, which could even increase player retention!
If the localscript is handling the actual clicking mechanic, will it not be doing this by attaching events? After an event is attached, even if the script it was created in is deleted, the event remains attached unless disconnected by code. The exploiter could still delete the script without consequences. Please correct me if the mechanic relies on the script constantly running.
Also, even if the auto clicker detection system uses events, the exploiter can disconnect them. An exploiter can do anything a localscript can. And, disconnecting this event will not disconnect those concerned with handling input.
Which it will.
Games are designed to be competitive. Even if somebody enjoys using an auto clicker as their experience, they gain a reputation in the game’s community which they do not deserve.
I think that letting your game get a reputation for being “welcoming to exploiters” is not a good demographic. It could even be seen to be encouraging cheating.
Right, that’s what I was saying. All I was stating in my post was that, in fact, that particular method has a lot of flaws. And if you remember my first sentence:
There’s nothing badly wrong with the mechanism, just it needs to be coupled with something else to be as effective as it could be.
“Don’t leave this as your only line of defence”
I apologise for the excessively long post, I had a lot to say.
That would depend on the script which does not exist yet, making it rather difficult for me to explain how it works - but it would require a huge insight into the game’s development to work out how to continue playing the game without the scripts that run the game.
Not all games are designed to be competitive, least of all casual clicker games.
Cookie Clicker, Clicker Heroes, Ad Venture Capitalist - all these games do nothing to stop a user from clicking a million times a setting, other than getting quite laggy. They still have brilliant reputations because if a user wants to play legitimately, they can! And if they want to use an autoclicker to help save time, they can do that too. It’s basic game design man.
I do, actually. You mentioned not to
as the only line of defence which, as I’ve said a number of times now, the system I’ve proposed throughout this thread would not do.
Good, then we reached an agreement. That was all I was attempting to clarify all along, the reasons why the system is inadequate on its own. That is not to say it is a bad system, just one which is, so to say, a piece of the jigsaw puzzle.
I wouldn’t say that we’ve reached an agreement, as we seem to have the same point of view on this the entire time, which you failed to notice up until this point. I admit I was getting quite irritated because it did not seem like you were even fully reading my replies, but I do apologise for the passive-aggressiveness in my last reply, which I’ve now edited.
However, I have not made any comments about you personally and have criticised only your ideas, which I disagree with on many bases, something I’m comfortable saying in a forum designed for the sharing and critiquing of ideas, not just for formal debate.
A clicker game would most likely not have an expensive callback for updating a player money.
2400 times a second is correct, it actually could go up to 3000 based of other things going on in other parts of the game. Of course, the callback is extremely lightweight and doesn’t do any performance intensive tasks. As I stated in the first paragraph, a clicker game probably won’t be need much code to update the amount of money a player has.
Out of interest, is this in play solo, or multiplayer? If you’re firing the event for every player in, for example, a 10 player server, you’re receiving 24000 events every second to handle.
If this only works in play solo, then it wouldn’t be any use in a production game and would most likely end up in the invocation queue being exhausted, as I said earlier.
The game can have a max of 40 players on at once. Each player is sending a string of data the server every renderstep to replicate the camera’s current rotation to all other players. I’ve already tested it in game with 39 other players and it doesn’t hinder server performance to a noticeable degree.
It’s actually a common method that some FPS games use to have the player’s body tilt towards whatever their mouse is currently looking towards.
One thing I’d like to mention, I saw this pretty nifty method of auto-clicking prevention on a clicker game I’ve played in the past,
(this is just an example I mocked up for the sake of this post)
After a set amount of time, this notification window would appear and would prevent any clicking until it was dismissed, the button placement was also randomized so it was unpredictable.
Pressing no would remove you from the game to stop any cheaters macroing, etc…
Take and experiment with this as you will, this is just something I remembered.
