I would like to give mobile players a special advantage against PC players in my game, so I would like to check if a player is on mobile when they join the game. Unfortunately, I am only able to check this on the client, and I don’t want exploiters abusing this.
Here is my attempt at checking if a player is on mobile whilst making it hard for hackers to abuse.
Would something like this work? I generate a new remote function on the server every time a player connects and I invoke it before the exploiter can edit the localscript.
Our setup would look something like this:
The server script would contain the following code:
local Players = game:GetService("Players")
local PlayersOnMobile = {}
Players.PlayerAdded:Connect(function(player)
--create the new remote and put it somewhere where the client can see it
local newRemoteFunction = Instance.new("RemoteFunction")
newRemoteFunction.Parent = game.ReplicatedStorage
--let it know about the new remotefunction
local LocalScript = player.PlayerGui:WaitForChild("LocalScript")
LocalScript.ObjectValue.Value = newRemoteFunction
--fire the remote to check if the player is on mobile
local isOnMobile = newRemoteFunction:InvokeClient(player)
print(isOnMobile)
--put it in our list of mobile players
if isOnMobile then
PlayersOnMobile[player] = true
end
--destroy the remotefunction and LocalScript
newRemoteFunction:Destroy()
LocalScript:Destroy()
end)
The local script would contain the follow code:
local UIS = game:GetService("UserInputService")
local ObjectValue = script:WaitForChild("ObjectValue")
local RemoteFunction = ObjectValue.Value
RemoteFunction.OnClientInvoke = function()
return not(UIS.KeyboardEnabled)
end
I’ve tried it out and it seems to work, I just want to know how easy it is to bypass this.
Code that’s directly reliant on a player’s “device type” is considered bad on Roblox. Device type can’t be checked to begin with, you can only check what kind of input a user is capable of passing or has passed. Lack of a keyboard input type available does not imply a mobile device.
You don’t need an “exploiter friend” to break rules to test the integrity of your own code, you could throw this into a LocalScript and run it yourself. It’s also making you reliant on their shallow testing results to determine if your source is ok but fails to account for any dedicated exploiter who potentially might be able to - I don’t doubt it - spoof the properties of UserInputService and give back a tampered response.
Number one mistake is making the client the source of truth for a system in your experience that directly affects gameplay. It’s naïve to believe exploiters don’t have a way around and that you have a shot of winning against them on their own machine.
I don’t remember if mobile controls are created on the server or not, but if they are, you can check for the existence of and then use them to see if they are on mobile. If that doesn’t work, you can wait a minute or so for the player to move, and then if they have variance in their speed compared to other players, it has to either be mobile or console. Finally, your last resorts would be either testing for the existence of mobile-only server objects and properties or using AI to watch the player
s behavior for a small amount of time to see if they are on mobile. There are many ways you can check, but it is highly recommended to not use remote functions that invoke the client for information due to the fact that the client can straight-up lie, give a bad value in an attempt to error the server script, or yield the invoke indefinitely.
Immediately as the client loads, fire a remote indicating their device type (pc, console, mobile) and as soon as that value is set for their device type on server, lock it so that it can not be overwritten. No exploiter will be able to inject their exploit in time to fire that remote before your script.
This isn’t a good solution either. I’d argue that most of the exploiting community is kids who can’t script, but a nice sized chunk of exploiters are smart enough to bypass your security idea by setting their device type before joining the game.
Definitely a complex task to do, but once someone figures out your games weakness, depending on how popular it is, they will mass spread a script or method to abuse it.
Considering I’ve been doing this in my games for the past 2 years and not one person has ever exploited it once and having a 100% success rate I’d say its a very good solution.
Not sure what you use device type for but if you broadcast to everyone that you give advantages based on spoofable device type values, exploiters will start flocking to your games if your games have a big playerbase.
You can still attach a keyboard to a phone. A laptop can still have a touch screen and a gyroscope. You can never be certain of the player’s device, and I believe this is by design.
Generally you should not give players advantages based on their input method.
I don’t think you understand the fact that the server is being informed of the client type immediately as the client joins meaning the client does not have time for an exploit to run
Some exploits (first that comes to mind is Synapse X) have an auto-launch and auto-execute feature which injects into a modified client before the game window pops up.
Not true. Exploiters have full admin permissions over their system, and you have close to none. They could simply freeze the process, inject the code before it even runs and connects to the server, and change the device type ad-hoc OR just change their device variable like BullfrogBait said.
It is like he said if it’s a big game and it is competitive it could be worth it for them. Not to mention, there are MANY Roblox trolling channels that do exploit for videos, and if it gets them an extra 100k views, they WILL do it.
Big games don’t give mobile players an advantage (say for some showing mobile player above their head)
If you really want your mobile players to have a good experience with the game design the controls in such away that modal devices for all sizes and types can play without frustration. That is what I think you should be focusing on. Don’t focus on giving mobile players an advantage.
