Preventing exploting from client side minigames

If I’m running a minigame on the clients side, and I want to do as little server side checking as possible (as in only call the server when the minigame is done) how can I prevent exploiters from just using absurd numbers to call to the server to get huge points?

function PizzeriaMinigame:StopGame()
	MinigameFinished:FireServer('Pizzeria', PizzasComplete)
end)

Basically on the server I’d take the 'PizzasComplete and times it by a cash value and give the player their reward

-- Just a quick example
MinigameFinished.OnServerEvent:Connect(function(player, minigame, amount)
    PlayersCash = PlayersCash + (amount * 5)
end)

What can I do to stop an exploiter from just saying they’ve made a million pizzas? I don’t wanna have to fire an event everytime a pizza is made and keep a tally on the server for each individual players, scores, etc.

2 Likes

You could add some kind of a timeout in a middle while they are creating those pizzas. Just time yourself how long you are creating a pizza and add a timeout like your time shows. I hope this helps.

1 Like

Just an idea, but maybe you could add a boolean that identifies that the RemoteEvent being fired is valid or something. So for example, in the LocalScript inside the FireServer parameters, add a True boolean. Then, in the Server Script, have an if-statement that identifies if the boolean is true. Basically, like this:

--Local Script
function PizzeriaMinigame:StopGame()
    MinigameFinished:FireServer('Pizzeria', PizzasComplete, true)
end)

--Server Script
MinigameFinished.OnServerEvent:Connect(function(player, minigame, amount, isValid)
    if isValid then
        PlayersCash = PlayersCash + (amount * 5)
        -- whatever other code goes in after
    end
end)

Another idea is to just keep the amount of money being given a fixated amount stated in the Server Script but not sure how you are going about with the distributed amount.

An exploiter can just put that variable in and bypass that.

3 Likes

All I can say is that you should be trying to handle all the important stuff on the server and just use the client as a way to show the Player what’s going on with the server through a Gui or a winning screen.

1 Like

I don’t want to have to fire a remote event every time a player makes a pizza tho to the server tho. The games completely controlled on the clients end.

Unfortunately because of the way you’ve setup the game on the client so far I don’t believe there is any way to combat exploiters here.

If I think of one I’ll let you know.

1 Like

As ArticGamerTV said, you can stop exploiters from saying they created a million pizzas by sanity checking the result at the end - whenever a player starts a minigame, record the time on the server using os.time, and at the end work out how long they were playing by subtracting the recorded timestamp from the current one.
If the player claims to have cooked more than 2 pizzas per second (or whatever you think the fastest a human can cook a pizza is), they’re exploiting.

If you want to keep the server mostly uninvolved, that’s about as far as you can go.
Putting more of the minigame’s logic on the server lets you include more checks that the player’s inputs are all possible, but exploiters can lie about anything their client does, so the exploiter can always send well-crafted remotes and inputs to play the minigame perfectly.

4 Likes

If you want to prevent exploiters from abusing your game, you need to do sanity checks on the server and log specific actions.

I don’t see the problem with logging each pizza a user has made on the server. There is literally no downside to that and is the only way to prevent someone from abusing the Minigame.

If I had an event that fired every time a pizza was made a player could just fire that event a hundred times to the server. There’s no way for me to do any checks on the server for how many pizzas a players made. The pizzas spawn in on the client

I’d be careful with this.

A common mishap in a developer’s exploit checking is believing players are only as good as the developer is.
Some people are just really, really good at certain things that are hard to believe. Striking them down for having near-exploit level techniques or skill is a really negative thing to be doing. Especially if the game is targeted to kids, and some smart adult excels in it.

TLDR, if you do this method make sure you don’t underestimate people too much

2 Likes

You could then use that information to store it in a table or something so that whenever the event is fired the player gets stored and if they get an absurd amount then you could act accordingly. However, I agree with @lysandr on what they are saying about keeping the limit on a reasonable level.

The limit is 30 pizzas, so I already am checking on the server to make sure that the highest a player can make is 30, but an exploiter could still just start the game, fire event for 30, rinse repeat

If your minigame is simple enough, log the input actions of the player on the client and handle the entire minigame on the client. Once the minigame is done locally, send the table of input actions to the server and have the server run a simulation with the input actions to determine the real score.

Add a cooldown for how fast you can do the minigame and you want to add some more server checks to verify if the person is actually doing it legit which will slow them down a bit.

1 Like

This is what I have written first but okay, I agree with you men.

Yea I was agreeing with you cause I don’t really know what else you could really do.

I mean yes it’s easy, simple and also useful to create this. It’s not really complicated in other words.

Here is a little suggestion, you could have a local script copied into the player when the mini game starts (Or during the mini game) as a little check to see if they are making pizzas too fast. If you can copy it without the exploiter knowing, that could be used. The best protection would be remote events and having server sided checks.

Exploiters can modify anything client side. Period.

This method would work as a temporary band-aid, but could easily be worked around. Exploiters can prevent remote event data from sending, send certain data, and even modify local scripts.

1 Like