Device Detection - API & Enums

Feature Requests Engine Features
1

Game dev is challenging, and while making User Interfaces, thinking of User Experience, button layouts, button behavior, etc. The device a Player is using requires explicit attention and directs unique pathways of development.

As a Roblox developer, it is currently too hard to, accurately determine/know what device a Player is using.

Current methods I have seen and used to detect devices include
Big thanks to - qDevice - A utility for getting user devices - Roblox

Mobile:
UIS.TouchEnabled or UIS.TouchEnabled + ScreenSize
This Can create false positives if a player is on Laptop with a Touch Screen
Further, the new ROG Ally x will be classified as a mobile device.

Console:
GuiService:IsTenFootInterface()
Straight forward, but kind of hidden, I didn’t know this even existed for about 2 years.

Computer:
not UIS.TouchEnabled & not GuiService:IsTenFootInterface() ~ I guess?

ROG Ally x
No idea yet

I’ll Included Controllers here

local BUTTON_A_KEYCODE= Enum.KeyCode.ButtonA
Gamepad is an Xbox Controller
UIS:GetStringForKeyCode(BUTTON_A_KEYCODE) == "ButtonA"

Gamepad is a PlayStation Controller
UIS:GetStringForKeyCode(BUTTON_A_KEYCODE) == "ButtonCross"

The returned string from BUTTON_A_KEYCODE dynamically changes in GetStringForKeyCode at runtime?
Feels like something we need to stumble upon.

Most of these methods, especially to a new developer, are hidden or strange behaviors to stumble upon. Most are in UserInputService another thrown into GuiService, and we have to trust these methods are accurate enough.

Since the addition of, Input Action Service, PreferredInput, and ViewportDisplaySize, these are and is the way forward. But developers still don’t have the full picture.
We need a layer deeper for specific Device Detection.

If Roblox is able to address this issue, it would improve my development experience because:

  • Developers would not have to jump through hoops and stumble upon existing methods to accurately determine what device a Player is using.
  • Improve development time and productivity
  • Let us focus on making games, not hacking device detection
  • Increase trust that the device a Player is using is correct!
  • Remove false positives

Side note:
I found DeviceForm | Documentation - Roblox Creator Hub
But it looks like this isn’t used anywhere inside Roblox.

UIS.DeviceForm – would be :ok_hand:

Thanks for reading.
Looking forward to hearing your input.

3 Likes
2

The point of what they’re trying to design is that you shouldn’t need to know what specific device you are running on, the game should be agnostic to a variety of different form factors and configuration sets. Tying it to specific platforms is bad engineering that will cause you lots of forward compatibility headaches down the road.

5 Likes
3

Keep in mind using GuiService:IsTenFootInterface() shouldn’t be thought of as “is the user on console”, but instead as a reasonable expectation of “how far is the user sitting away from the screen”. This function is located in GuiService because its intended use case is Gui-related; Some interfaces may need adjusting depending on whether the user is “ten feet” from the screen, as is expected on console, vs. two feet or less, as is expected on other platforms.

4

The inability to check exact device/form factor is an intentional restriction we do not plan on lifting.

See Cross-platform development | Documentation - Roblox Creator Hub for tips and tricks.

3 Likes
5

bit inane innit? let’s just say… you have a platform specific bug that allows a cool visual effect but completely blinds… let’s just say mobile players (and you want mobile players to be able to play your game), well then you have to disable that effect for specifically mobile players via a localscript, wuh oh looks like someone doesn’t get the cool visual effect on the intended platform and are now SAD because they have a weird laptop

6

While I do agree that there are a multitude of outstanding platform-specific bugs that we as developers have to look out for, giving an API to determine what platform/device the client is on wouldn’t really be a good solution.

For starters, these are bugs, even though they might be half a decade old and act functionally like intended behavior. Providing an API solely for developers to patch verified bugs wouldn’t be that great, since it would essentially be a cheap band-aid fix to the more serious issues at hand. If anything, an API should be seen as a last resort.

Secondly, it would set a bad precedent for how these cases are expected to be resolved. Since there would be an officially endorsed way for developers to resolve these bugs, there would be no compelling reason for engineers to fix them. Highlights don’t render on old phones? That’s a bummer, but the developer is expected to program around that, so fixing that is a low priority now.

Finally, knowing what platform the device is on wouldn’t even allow developers to work around these issues in the first place. Decals have weird z-fighting on old Android devices? What are you going to do, disable all decals on platforms labelled ‘Mobile’? Even if Roblox provided very low-level information about what the system is, there’s no way you could possibly take care of every single case the engine throws at you.

So, if you’re still in the camp of adding APIs for developers to fix these bugs, the proposed API wouldn’t even be useful to that cause.

Now there are a few exceptions, such as Acoustic Simulation and ParticleEmitters. For the former, the client not supporting acoustics for performance reasons is a possible case we should have the ability to account for. For the latter, there needs to be a way to prevent ParticleEmitters from throttling due to quality level changes.

However, none of these would be better solved with an API for getting the device type. They would need to be handled in a case-by-case manner.

2 Likes
7

You shouldn’t be relying on bugs or unintended behavior in order to do things to begin with. That’s something Roblox goes out of their way to steer developers away from doing.

3 Likes
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.