I support this idea. The ability to check the platform being run on is important for tailoring the player experience aside from controls, and detecting the input type or screen size or any other metric is often not what people are looking for. As stated these are already tracked on the website so clearly have importance and the question should therefore be “Why not?” not “Why?”.
And you shouldn’t be concerned that the existence of something may lead to bad practices because its the developer’s job to avoid bad practices. As the creator of a platform your job should be to provide the means to do the job easily with good practices, not stamp out the possibility of the use of bad ones. As it stands the ability to do things like check the input type, etc. easily with good practices is provided already, this would simply be a way to do another thing properly with good practices, rather than with bad practices.
Can you elaborate a bit more on this? What is the expected result by default for each device type? And it still doesn’t seem like a solid solution overall, since by no means is it implied that such a method would help tell the user what platform they are on. I guess I’m just confused overall why a more explicit way of doing this can’t be added.
Because like you just said so yourself, it’s already possible to find out which platform someone is on. If people want to use bad practices and check for / ignore controls based on platform, they can already do it. Locking UIS:GetPlatform() doesn’t stop what you’re trying to avoid and only results in people using hacky code whenever there’s a legitimate use case for knowing the user’s platform.
Personally, I’d like to use the user’s platform for analytics. Yes I can already check their platform, but it’s super hacky and I don’t like having bad code. Example: PC players play this map the most, and mobile (phone and tablet) players play this map the most. Why? Does the most-mobile-played map have better handling than the other maps? What can I do to other maps to make them as liked as the most-mobile-played map?
Yes, that’s pretty much exactly what I was going to say. I think it’s worse practice for people to have to write hacky code to detect the platform (and the assumptions made based on factors like screen size & connected input devices may not be guaranteed to be correct), rather than just having a simple method that’s guaranteed to return the correct platform.
Exactly, because the way it currently exists, people are using bad practices, which always does and always will outweigh the possibility of using bad practices.
If I want I could always multiply by looping addition. You don’t remove loops because of this, you give easy access to a proper and efficient multiplication method that has the exact intended effect. This effectively prevents any good developer from using the bad practice of looping addition without actually removing the means to do it.
In the future windows could change with the win10 app (defaulting to touch when in tablet mode, etc.)
Platform is not exposed because we haven’t seen a good use for it. Some people suggested analytics, but what does that get you? If you know a lot of people play on android for example, what will you do with that info? Make your touch controls better? Can’t you just track what types of input your users are using? Also track how big the screen your users are using? Both of these will give you more granularity into who your users are.
There might be a good reason out there (I suspect there is), but the arguments presented so far don’t convince me you get something extra out of knowing what platform your users are on. Type of screen and type of input seem to give you everything you would need. We could probably do more in the type of screen department, I agree.
I have a proposal to expose GuiService:IsTenFootInterface(), which would return true anytime you are running on a screen that is meant to be used about ten feet away from the user (think consoles, appletv, etc.). We could do more to expose physical size of the screen your code is running on as well. If we expose the ability to detect input types and screen sizes, what could you do with knowing your game is running on windows? android? iOS? a potato?
Platform types set a standard. Yes, I could split up my analytics and save data based on screen size and input type. At that point I’d end up splitting analytics based on input type and then group each input type based on screen size, but then I’d end up with what I started with. Sure, my data is stored by input type and screen size, but all I’ve accomplished is finding a roundabout way to sort data by a precedent already established by platforms.
Also, following that logic, why are game stats in terms of platform? Why display PC, Tablet, Phone, and XBox? Why not display based on input type and screen size?
Edit: Tbh, delving into what developers should and shouldn’t do – what’s “good” practice and what’s “bad” practice – for something so small seems super unnecessary. Even if people misuse it, it’s not that big of a deal. “Misuse” is subjective to begin with on top of that. It’s silly to lock a method just because you disagree with other developers on how it should be used. It’s one thing if unlocking it would result in developers making some assumptions which would break with future updates, but that’s not the case here. In fact, using input to determine platform is what will cause code to break in the future e.g. if TouchEnabled started to return true for touch-based laptops and everyone’s code that thought TouchEnabled == mobile started breaking.
Once again, the importance of platform is already demonstrated by the website analytics showing platform data. And clearly developers here see a good use for it and are asking for it. So, again, why not include it?
Quenty nailed it on the head. Exposing the device type means developers will invariably assume that the player is using whatever input their device comes with rather than peripherals. Analytics is a decent use case but it’s probably not worth it considering how misused this feature would be.
Trying to bubble-wrap features is not the right way to stop that. There are a million things that can be misused in the ROBLOX API and another million ways those things can be misused. GetPlatform is the odd one out, and locking it unlike the countless other API members that can be misused, preventing any proper use, is dumb.
I (and most other developers) already used it wrongly at first. The input should change dynamically, meaning you can connect/disconnect your game controller to use a keyboard/mouse on the fly, however a lot of games on ROBLOXForXbox didn’t do this (Bird Simulator, Davidii’s game, etc) the only ones who I believe did this correctly were Tiny Tanks and Perilous Skies. So yeah It’s not as if this isn’t an issue already.
I can theme input icons / text i.e. if a user is on Mac I can say press “Cmd + C” and show the symbols for those and if they’re on Windows I can say press “Ctrl + C” and show the symbols for those. If on XBox I could show an XBox controller when I need to show users which button to press, and when not on XBox but using a controller, I can show a generic controller
Reward special items based on platform (e.g. give XBox users a special weapon skin) to entice users to play on specific platforms. ROBLOX did this in one of the egg hunts for instance
Targeted product display. People who use iOS products might be more willing to buy a product if it seems super sleek and trendy (how iOS products are advertised) while someone on XBox might be more willing to buy a product if it makes them feel like a badass (XBox stuff is generally marketed this way) – by owning a specific platform, a user has already communicated that they’re susceptible to specific marketing tactics, and by knowing which platform they’re on, we can take advantage of that
There are your use cases. Use cases coming from one person over the course of a couple minutes. I’m sure others have different use cases, and I can come up with more with more time thinking if that’s not enough. I’ll continue to add new use cases to this thread over time until GetPlatform is unlocked if that’s what it takes to convince you that there are enough use cases.
The point of mentioning those use cases is to show that there are use cases worthy of unlocking GetPlatform so detection doesn’t have to be done hackily, but thanks for mentioning that.
Hey, I have a good reason for it.
How am I supposed to filter my game to meet ROBLOX’s Xbone ESRB if I don’t know what platform I’m running on? My game has blood/gore, which isn’t allowed, so I have to apply a local filter to the game so that I can keep the game on there, while allowing users to still experience what they please on other platforms because it isn’t restricted.
while not userInput.GamepadEnabled do
userInput.Changed:wait()
end
while not game:FindFirstChild("OneStatFrame",true) do
if not userInput.KeyboardEnabled then
break
end
wait(1)
end
This code is a gross hack, and I shouldn’t have to do that to verify if I’m on a console or not
Relying on a set of inputs ins’t really a good idea for platform detection (imo).
Ex:
Controllers (mostly) work with Android. If someone can confirm if a keyboard case does/does not work, I could use that info,
Also, what happens if it suddenly becomes true for anyone with a touch screen on a laptop (ex: my Lenovo Yoga 2 for an example).
