I’ve made a similar request in the past, but I’m coming back with a more refined request.
Sometimes it can be very useful to tell what type of device a user is on (such as console, PC, mobile…). However, there is currently no way to explicitly check and see what device the user is on. And so game devs are forced to do hacky tricks to figure out what device the user might be on. I emphasize “might” because it is not a guarantee and there are holes in the logic.
My proposal:
Player.DeviceType [enum]
Enum.DeviceType:
Console
Desktop
Mobile
Tablet
These enums would best reflect the configuration options that users get when configuring their games on the website. If a user can select the device from there, then it makes sense that such device information should also be available in-game.
This would also help a lot when dynamically configuring a game within different environments. For instance, on XBox, there should be no keyboard controls showing. Currently, the way to do this is to check to see if a gamepad is connected and keyboard isn’t, and then hide/show the appropriate UI control elements. See the holes in that logic though? What if I want desktop users to still use gamepads but also have keyboard controls too? Also, what if the desktop user just happened to not have his keyboard hooked up yet? Now I have to listen for peripheral changes just to properly configure my UI on the fly. It would be so much easier just to have a simple property exposing the device type.
Would a player on PC with a gamepad connected be considered to be on console?
I’m a tad confused as to why this Enum type would solve the problem of the player connecting and disconnecting various input methods - changing all icons from keyboard-centric to console-centric images would still require an additional check of whether the player is on a certain device, much like you currently have to do with GamepadConnected and GamepadDisconnected etc.
But in principle I would love this to become a thing, I’ve found myself wishing for an easy way to detect what platform a client is using for a while.
Nope. Still desktop. Whether or not a user has a gamepad connected should not be directly linked to them being on console. Especially due to the higher restrictions of XBox compared to anything else.
The point is that device detection should have nothing to do with what input things are connected. The issue here is that this is currently the only way to get an idea of the device.
Oh I see what you mean now and it makes total sense for that to be true.
In one of my games I display messages to players on ‘xbox’ that the Xbox port is in the testing phase; yet this also is shown to users with a gamepad on PC, calling them an xbox player in the process.
Another similar use case was showing mobile ads to users and having to detect if they were on a device with a touchscreen - not a reliable way of going about it.
This seems like a solid proposal. Here’s my current solution to this problem, an input-mode system that swaps based upon categorized inputs.
Which toggles inputs based upon the current state of the UI. You can see this in progress her, as I switch from arrow-keys to WASD to game-pad.
Note that a single DeviceType is not enough to determine input type UIs. For example, the control scheme of your game may be different for arrow-keys than WASD. Here are several rules I maintain with my UI:
All input schemes are valid at all time
Show the UI for the most recently used input-scheme
This means attaching a gamepad will toggle the gamepad UI, but it doesn’t mean keyboard is now disabled.
You have to be careful with this proposal because DeviceType does not always indicate control scheme (PCs may have touch screens, Phones can have attached game-pads, Consoles may have a bluetooth keyboard).
An enum like this starts to lock developers into a “develop for one device” mentality, whereas we are really developing for a host of dynamic input types and devices.
UserInputService:GetLastInputType() and UserInputService.LastInputTypeChanged should do everything you need. If you query this at the beginning of your game it defaults to best control schemes for each platform you are on, even if the user has not input anything yet.
I have yet to hear a compelling reason to unlock these, and I am reluctant to do so because this can lead to bad habits (Enum == Xbox so I only need to worry about gamepad, or Enum == Windows so I only need to worry about Keyboard/Mouse).
Matchmaking. I’d rather try and link players on similar devices so that if the controls are more natural on one input device that player won’t get an unfair advantage. You could argue this is down to input type, but playing with a touchscreen on a tablet is very different to playing with one on a phone.
Optimization. A mobile device may not be able to handle a large game that a PC or Console would be able to run. I can therefore remove smaller details in order to make the game playable on their device rather than stopping them from playing completely.
Likewise what if a portion of my game isn’t suitable for mobile? Perhaps I want mobile players to be able to customize their character but not actually play the game itself.
Furthermore locking a ‘harmless’ feature based on bad-habits seems like bad practice to me. It should be up to the developer to make the mistakes and not the platform.
I remember when I was doing strobe II work the game couldn’t have any mention of PC or PS4 controls or anything that wasn’t xbox related. Content filters are set up based on the idea that you have no keyboard and no touch screen enabled, so you must be on a console.
In the event roblox ever ports to PS4 or WiiU or something, there is no way to tell what console you’re on based on those current methods for defining if you’re playing on a console. I’m sure PS QA would have a fit if a bunch of roblox games had Xbox controls, same way the Xbox QA folks did. A similar idea applies to mobile or desktop because of keyboard and control differences.
I partially agree with the laziness and bad habits argument, but knowing the platform would be a serious help for future and current development in regards to user experience.
You could query screen size? We normalize DPI on mobile devices so the larger the resolution the larger the device. This may change someday, but if that is the case I’d like an API to get physical screen size or something along those lines. Either way, you can say the same thing about different phone sizes too (iPhone 5s screen is way smaller than a Nexus 6P).
Maybe @zeuxcg can chime in here, but generally I think we want to avoid you having to do these kinds of optimizations.
I could be wrong, but this seems like you would want a separate instance then for mobile players, and could teleport other players to the actual game when a round starts/they enter a new area/etc. Other option is separate games for types of input.
I agree only if the tradeoffs make sense. If we gain something significant from our top devs with the feature, generally we side with making it open knowing that it can be used poorly.
If we ever go to PS4/WiiU/etc you can be sure we will have APIs to help you distinguish what kind of controller you are using so you can prompt controls correctly.
This could even be said of keyboard controls because our input standardizes to US QWERTY layout, although the layout the user is using maybe be different.
Separate games means data can’t be shared across platforms. So if I play on Mobile then on PC I will have two entirely different saves. (It goes without saying everything should be kept in one game though). I could possibly teleport players to a mobile instance but I’d need to know they are on mobile which I would only be able to do with this API.
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.
