As a Roblox developer, it is currently annoying for onboarding developers & me sometimes to figure out what platform players are on.
Having all the ways to determine what platform it is under one method :GetPlatform() instead of using
GuiService:IsTenFootInterface
UserInputService.TouchEnabled
UserInputService.KeyboardEnabled
UserInputService.AccelerometerEnabled
UserInputService.GyroscopeEnabled
UserInputService.GamepadEnabled
I think MACS donât have a mouse2 or a ctrl button? This causes users to request an option to crouch with C and aim down sights with Q. I could have this turned on automatically if I detect them on a mac.
Also, a new developer might be confused on how to figure out how to check if they are on xbox, because its under GUIService away from everything else.
Why is it disabled? I donât think itâs super privacy breaking if I know they are on a MAC or PC, Android or iPhone. If roblox can see these, why canât I?
This is fair ^ Doesnât mean a solution canât be found though
Just for reference for people who may not know, this is a recent version of how to get the platform. (Includes the recent-ish change with touchscreens) Itâs pretty silly how many services and weird checks we have to use. & good point from mightybaseplate about the mac controls
local GuiService = game:GetService("GuiService")
local UserInputService = game:GetService("UserInputService")
function getplatform()
if (GuiService:IsTenFootInterface()) then
return "Console"
elseif (UserInputService.TouchEnabled and not UserInputService.MouseEnabled) then
--touchscreen computers now have touchenabled so make sure to check for lack of mouse too
--also, not all phones/tablets have accelerometer and/or gyroscope
local DeviceSize = workspace.CurrentCamera.ViewportSize;
if ( DeviceSize.Y > 600 ) then
return "Mobile (tablet)"
else
return "Mobile (phone)"
end
else
return "Desktop"
end
end
to allows developers to detect OS, platform and/or device. What makes Roblox so special in this regard? As someone else said, this is âbubble wrappingâ the API for safety.
Analytics are important. Different users behave differently, and operating system is just one more segment by which a player-base can be measured. This isnât a matter of privacy either, since this kind of information tells you absolutely nothing useful about someone. Plus, it can be sniffed anyway.
The fact that thereâs a metric crapton of different devices with different capabilities is actually an argument in favor such a feature to be exposed. More OSes/platforms/devices etc means more work for the people doing it the wrong way (detecting platform and setting up input). Abstraction via available peripherals is obviously the way to go, nobodyâs arguing that. We have that feature already.
I donât buy for a second the âthereâs bad use casesâ argument because if we really restricted features based on how they could be misused weâd have no features at all. Frankly, I think itâs insulting because it send the message that all Roblox developers are too naive to use the feature correctly when this is most certainly not the case.
The feature already exists. Literally the lowest amount of effort it would take to make this feature available to everyone. Weâve probably wasted more time talking about this than it would take to actually let people use this.
Thereâs really no security risk involved with allowing developers know what platform someone is on. Not only is the feature useful for analytics, but itâs also quite useful when coding in platform-specific functions, such as the previously mentioned Mac problem.
Another important use of this could be user interfaces.
With this, you can make a separate mobile interface, separate pc interface, etc.
This would allow developers to optimize the screen real estate in a much better way.
You can make the buttons on mobile bigger. (Scale and UI constraints wonât cut it.)
You can make buttons etc. that would normally on pc take up part of the screen, completely fill the mobile screen. You can simplify menus too etc.
I should also mention that for this, the device detection shouldnât need much more than âDesktopâ, âConsoleâ and âMobileâ. (Maybe tablet?)
Iâve seen games like MeepCity optimize their UI for phone for example. The only way to do such a thing as of right now is to use those hacky methods as described above.
In other words, it would enable developers to make responsive UI without any hassle.
The strawman argument of âJust use UserInputServiceâ is nullified when talking about multi-platform games, such as FPS games.
You donât want console players going against PC players in a first person shooter.
Plus, itâs practically impossible to funnel players into specific servers for that specific device - a PC user could cheat into an Xbox - only lobby by using a gamepad. TenFootInterface also seems problematic because what happens if theyâre playing Roblox on a PC thatâs connected to a TV?
You also run into the issue with the possibility of Roblox going on PlayStation - UIS isnât going to cut it.
I encourage you to think about the reasons behind this. It is true that some input devices provide a competitive advantage over others, e.g. keyboard/mouse is typically better than a gamepad. However, there is not a 1:1 connection between platforms and input devices. As of late last year, Xbox One players can use a keyboard/mouse with their console (I believe Roblox is looking into adding support for this). Similarly, PC players can use a gamepad. Many industry games are starting to do input based matchmaking for this reason.
So any argument that says âI want to segregate my players based on platform because of a competitive input type advantageâ seems like a suboptimal solution. Instead, segregate your players based on input type.
Alright, yeah. I see your points regarding why platform detection could be bad.
However, how would we detect a userâs platform so they get the correct buttons to show up? I.e. if Playstation 4 is ever added to the Roblox ecosystem. At that point, there would need to be some kind of specific device detection in place. Or possibly even direct-driver detection so you could get PS4 buttons on PC, or N64 buttons on PC if for some reason youâre playing with an N64 controller.
Not really, they would probably just add another input mode for the different controller layout, or perhaps some new keycodes, or both, or something entirely different that lets you distinguish between those controller layouts. You would not want the device check because then youâre excluding people who use the PS4/other controller through another device.
Currently, itâs only available on Xbox, and you can use GuiService:IsTenFootInterface() to detect if the user is on a console (and thus Xbox). If it were ever available on another console, Iâm sure an API would be added to distinguish between the two.
I am making this claim due to one of the requirements for Xbox compatibility being this:
If on a platform like PS4, I imagine the same guideline would apply; therefore, I see it being reasonable to add some API to distinguish between the two.
However, thatâs not the case currently.
At the moment, you can also use UserInputService:GetLastInputType() and UserInputService.LastInputTypeChanged() to distinguish if the user is using a gamepad or keyboard/mouse. From there, you can dynamically switch your UI to either show Xbox controls or keyboard/mouse controls. Same goes for Touch controls. But you can use IsTenFootInterface() to shortcut this and assume to always show Xbox controls.
Note: It is way more user-friendly to use the LastInputType method as opposed to simply checking if a gamepad is connected, because a user might have a connected gamepad but still be using keyboard/mouse.
I find coding for UIS to be really confusing. When I was coding my interface for Redshift Arena to be compatible with Xbox controls, the buttons wouldnât show up on Xbox, but would show up on PC if you were using a gamepad.
Also, wouldnât driver-detection for input devices be better? Or could that open up security problems?
As stated previously before, a user could plugin in an N64 controller, PS4 Controller, XBX Controller, or even a NES controller and have the proper buttons show up for that device, if the developer supports it.
Of course, Iâm not entirely sure if this is even possible for Roblox to add, but it would still be a cool feature, and could be done if Roblox added in a list of all possible gamepads into an API, among other input devices.
That probably means you are messing with GamepadEnabled which you should never use for input changing/setup, or you were not correctly updating the input mode whenever it changes. You should detect the last input type using UserInputService.LastInputTypeChanged and UserInputService:GetLastInputType(). Your game will be most reactive when you can literally switch input mode at any time, no matter what device you are on or what input mode was initially selected.
Probably best to let the engineers figure that one out. As developers weâd just want an API member that lets us distinguish between layouts.
Iâd like to create a companion app for my game based in the same Universe as my game⌠Without actually being forced to make a companion app for my game⌠Or a new universe⌠for my game. See if I were able to discern between a mobile user, a pc user, and an xbox user⌠I could simply disable most of the need for rendering, and simply show a UI that lets players do things like be able to manage their inventory, repair their ships, or travel to a destination in x amount of time. All from the comfort of their phone while on the go. And when they actually get on the game on their PC. They would be able to actually see that the changes they made on the companion app actually made a difference.
But at this point Iâd have to implement it within an entirely different universe, which means that accessing the main games datastore would be out of the question. And since Universe Scripts seem to look past Universe to Universe communication. Iâd literally have to implement an external server just to get this functionality. Which could easily be obtained by simply knowing what type of device the user is on. Or I could do conditionals based on assumptions and hope no one falls in the in between.
All of this, simply because I donât need to know the device type. At this point making a companion app albeit probably against the TOS is easier. Doesnât make sense in my opinion.
Itâs insane that weâve been having this argument for roughly 3 years⌠The fact that Roblox wants to hide and block developers from certain services should NEVER be a thing. Let developers make mistakes so they know what to do in the future! Thatâs how people learn in the first place! Trying to safeguard (or âbubblewrapâ as others have said) is ridiculous for a company striving to be a creative platform. There are certain cases where this is necessary, but some, like GetPlatform(), is kind of ridiculous.
I understand the main argument that developers will associate platform with input if GetPlatform() is unlocked, but I donât think the majority of the large games on Roblox would even use it that wayâŚ
One of the main reasons people want this is to distinguish between the deviceâs performance & for analytics, not necessarily for their input.
For example, mobile devices (the majority of them) have a lower quality than most PCs. In my game, I wanted to change how I modify lighting in order for it to actually be seen by mobile. I use a sort of soft strobe light in parts of the game, but since lower quality levels donât update lighting fast enough, it is impossible to even see these lighting changes at all. Compared to the lowest level of PCs, you can still barely see some of the changes, but at least you CAN see it.
We, the developers, should be given access to platform information based on the following :
The ability to create specific analytics by platform (because Roblox still barely provides us with any device-specific analytics to this day)
The fear that developers will think platform INSTEAD of input is invalid. The same exact mistake can still be made RIGHT now⌠Trust me, Iâve made this mistake with the methods we have now, and Iâve learned from it
We should have the ability so we can future-proof our game for the addition / removal of platforms. If you release GetPlatform() early, people can code their future projects with the mindset that there may be future additions ahead. This helps on changing the user interface and everything to match the platform they are using (again, input is not the same as platform, but you can still change the way the input prompts LOOK on different platforms, as others have mentioned)
As CloneTrooper put it;
The answer shouldnât be:
We can do it ourselves with one method, why should we rely on the hacky way and ADD another method to the mess it already is?
Why make your developers rely on messy code when you can just unlock a single method to simplify everything? Seems like the fear of #2 is so much that youâd rather have your developers work around systems to achieve what they wantâŚ
I hope this is a reasonable argument in favor of unlocking GetPlatform(). Just because I would love to actually get a different argument from Roblox if they believe there is an actual reason to safeguard this functionality.
I cannot overstate this: you should not be correlating unrelated factors with device type. ESRB ratings are not tied to device type, it just happens to be that the Xbox app has a certain ESRB rating. This information should be available through a different API, because Xbox does not have to be the only device with that rating. If a different platform is added to Roblox that also has a certain ESRB rating, you wouldnât want to do âif Xbox or NewThing thenâ, youâd just want to do âif ESRB thenâ and have it automatically support new devices that have those policies active.
The mistake developers make is that they correlate unrelated properties to devices. Unlocking any kind of device type detection API would significantly increase this problem. We should be teaching developers to use input type and screen size detection (you can do this yourself right now, today), and we should have separate feature requests for other properties like certain ESRB ratings.
Same here, it is a different feature request: you want a way to request some more details about the current lighting quality. This is not a mobile-only thing. If a player is on a crappy laptop, they might see the same lighting setting, but your game wouldnât handle that case because youâd only be checking for mobile. On the other hand, if I have a high-end iPhone, you might be doing corrections that donât have to happen.
Building code off of a specific platform makes your game non-future-proof, not more future-proof. You support addition / removal of platforms when your code only takes into account input types and screen sizes.
Platform-specific code is what is messy code, not the code where you reactively respond to input and screen size changes. Refer to first quote response
TLDR; we need to stop correlating unrelated properties with certain device types. Knowing device type is only useful for analytics. (And that should probably be its own feature request)
What if the API to get a playerâs device type/model was server-only? This would be a big enough hurdle to prevent misuse in most cases, and would also make using this data for analytics more straightforward.
Surely ProximityPrompts are a great use case for platform detection now?
When building custom prompts, it make sense to show the âCommandâ (â) icon in place of CTRL when the player is on a Mac, as one example of how the same keys can have different symbols/names per platform (I believe Alt is also called âOptionâ on a Mac in the US, which would also require checks against the LocalizationService).
GuiService.IsWindows exists, but is deprecated, and only tells us whether the platform is or isnât Windows, which doesnât really help outside of Studio.
Nope, doesnât really make sense. I can hook up a Mac keyboard to an iPad and then the game should prompt me with â rather than touch icons or Ctrl if Iâm using that Mac keyboard.
Everything should be based on input mode. Roblox can provide mac/other keyboard layouts as separate input devices maybe. But it definitely doesnât make sense to map certain platforms to certain inputs, itâs just plain incorrect.
