I am fully aware that Roblox isn’t interested in giving devs the ability to see the players current platform, but unfortunately there is a usecase where this is needed.
As a Dev, if we want to show xbox buttons or playstation buttons based on the platform type, we effectively have to use a hack like this:
function IsPlaystation()
return UserInputService:GetStringForKeyCode(Enum.KeyCode.ButtonA) == "ButtonCross"
end
Otherwise I wouldn’t be able to show/hide the correct gamepad icons that I’ve purposefully given the player (ex below)
I’m not alone in this issue, I’ve talked to other devs who use similar hack workarounds as the only other option is to use the coregui gamepad buttons which can really limit creative expression.
I had to solve this problem as well for my button class and Virtual Valley Games’s games. My hack relies more replacing individual images when they are requested, as opposed to performing a global check for the platform. I think a better way of describing this feature request is we need an official way to provide platform-specific button icons, because figuring out and testing my solution is just too much work to provide themed buttons.
Shouldn’t the request be to check what kind of controller the player is currently using? If a player wants to use their Xbox controller with their PC (AKA me, although not on Roblox), just requesting platform won’t cut it.
It would also be great if Roblox could let us embed gamepad buttons in TextLabels or the like. Many of us have to resort to having to create ImageLabels with the buttons alongside the text for tutorials or tooltips and this leads to a lot of aligning work in UI especially considering screen scaling.
Yes, but this would also be clunky. What if you had a very long tutorial sentence that wraps around several lines but you needed to put a gamepad image in the center of the sentence? Throw in automatic text scaling because every devices’ screen resolution is different it may end up looking different and ugly than the one you’re using to create the UI and test with.
local userInputService = game.UserInputService
local textlabel = script.Parent
local key = Enum.KeyCode.ButtonA
local mappings = {
ButtonA = "A",
ButtonCross = "Cross"
}
local mappedKey = userInputService:GetStringForKeyCode(key)
local text = mappings[mappedKey]
textlabel.Text = text
This API finds a PS DualSense compatible controller.
It doesn’t detect the console at all, since that controller could be connected to anything. (a PC, a phone etc.)
In theory you could combine it with " IsTenFootInterface" for a somewhat better detection, but I wouldn’t recommend it.
What are you trying to accomplish by detecting an individual console?
Generally we are moving to more abstraction and don’t want you to think about the underlying platform at all in your code.
While I agree in principle with the whole “abstract over the underlying platform” idea, in practice these abstractions can only go so far before they start to break down.
Yes, we can and should design our game features to compensate for different screen sizes, input peripherals, etc. but there’s a point where the underlying platform differences becomes too great for a blanket abstraction to appropriately handle them all.
What buttons should we tell the player to press? What should our UI look and control like? What players should we match-make together to keep the game fair?
These are all platform-dependent questions on how our game features should behave that can only be properly solved if we know what the underlying platform is like. GetStringForKeyCode is good, but wait, I wanted an entirely different button layout depending on the controller. Using Camera.ViewportSize is fine for scaling UI, but wait, the screen is on a console TV and it’s too far away to see anything small.
…not to mention that even Roblox’s own engine features are woefully inconsistent depending on the client’s platform. ParticleEmitters and Beams still get unconditionally throttled and can straight up disappear on low graphics settings. Roblox’s acoustic audio beta purposefully breaks on devices where performance is a concern. Hell, even highlights still don’t render on some old phones from what I’ve heard.
Point is, we still have to work around these platform-specific inconsistencies (some of them like graphics throttling are literally impossible to solve other than building a new system from scratch) and Roblox’s stance that they need to baby-lock our ability to detect these cases because we might make crappy games is downright disrespectable besides being logically flawed. We’re competent enough to spend thousands on advertisement, I think we can use information about the underlying platform responsibly.
You just need to detect the current input and output method to implement the GUI for example.
We will give an RDC presentation on how to implement abstracted x-platform UX.
to baby-lock our ability to detect these cases because we might make crappy games is downright disrespectable besides being logically flawed.
We feel like it is respecting the community when we solve these problems for you and not require you to think about the underlying platform limitations.
That’s where I disagree, there are underlying platform limitations that are too large for a generic solution to work. Sometimes these are rooted fundamentally in the genre of our game, like a fast-paced FPS, where there’s no magic that’ll make it fun to play on touchscreen. That’s ultimately why we can choose what platforms our games are accessible to in the first place.–our gameplay features are fundamentally platform-dependent.
I want to reiterate that we’re not asking for what specific platform the client is on like “Windows 11 on a Surface Pro” or whatever–that is almost categorically useless. We just need information about what the platform is like in regards to our core gameplay features, like what controller they’re using for input binding or what kind of display setup they have.
The ideal UI layout for a 1920x1080 desktop monitor vs the ideal layout for a 1334x750 phone screen vs the ideal layout for a 3840x2160 console TV are going to be so dramatically different that they almost always require an exclusively separate UI tree1. That is just the matter of the fact. The idea that we can design our UIs once with a few constraints and change it a little depending on input won’t cut it. We need a foolproof way to determine our client’s needs so we can properly compensate for them.
I think the large majority of frontpage games don’t actually do this (despite it being common practice outside Roblox) because they’re really only targeting a specific platform for their audience, even if they still ‘support’ other platforms. Games like Doors/Pressure are more focused on desktop and so their UIs figuratively and literally don’t scale well on smaller phones. The opposite case is also true but more subtle; games like Grow A Garden have humongous UIs for mobile that appear extraneous on PC.
