As a Roblox developer, it is currently too hard to capture meaningful platform information in scripts for custom analytics, primarily: device model name and total RAM capacity.
If Roblox is able to address this issue, it would improve my development experience because I would be able to:
Check the most frequently used devices on my experience to know exactly which test devices I should purchase to verify those experiences on (e.g. iPhone 7), which will help me to ensure the largest segments of the playerbase can run the game without issues
Analyze this information in ways which Roblox’s analytics can’t - for instance, looking at the relation between device model name and custom metrics like average time-to-crash, and setting up remote alerts for sudden crash rate increases on certain cohorts
Note that my studio has already proven that we would not use an API like this for bypassing input abstractions, as we have already implemented generic input handlers into all of our experiences. If this is a widespread concern maybe values could be hidden through Secret objects.
CaptureService:GetDeviceInfo() seems to provide some relevant device information based on another user’s screenshot I found but it’s locked.
At the moment we have no plans to support reading the actual device a user is on. This is to help ensure that games remain cross platform compatible going forward.
As far as the analytics side, there is the analytics dashboard that can help provide some of the info you are looking for. At the moment, we don’t expose more granular breakdown of device usage unfortunately.
I think we should re-examine the assumption that it detracts from cross-platform development. Game engines which implement similar APIs such as Unity’s SystemInfo and Unreal’s FGenericPlatformMisc don’t suffer the cross-platform incompatibility problem which is often described about here - developers across the board use the platform-agnostic input and UI systems in those engines despite the existence of the platform info APIs.
But if this is still believed to be a possible issue, then Secret objects - which already exist in Roblox - seem like a good way to hide the value at runtime until it is sent to an external analytics server, as the use case for this API is custom analytics.
Given the above, is there a good reason why you believe a platform info API like this shouldn’t exist?
The Roblox analytics dashboard is too limited for the foreseeable future and I don’t want my studio to be held back by it. If I wanted a new graph showing specific platform information, or a more granular breakdown of device information, I would have to create feature requests for each one and wait months or years for the request to be approved or denied, then implemented. Then, I would likely want further queries on the data. What to ask from the data is not always clear - future queries are often informed by past queries.
I would see more innovation if my team were given freedom to access this information and use it in our custom analytics. That’s why I am making this feature request.
Roblox needs to drop the hand-holding shenanigans if they ever hope for this platform to mature. Categorically blocking useful APIs because “developers could make crappy games with them” is such an overwhelmingly irrational policy that it shouldn’t even be entertained. It’s utterly embarrassing to work on a “cross-platform” engine that won’t even let us know what platform the client is on.
The message here is clear: Roblox doesn’t trust that we can make good games. They think they have to baby-lock features so we don’t make oversized UIs with them, while also giving us the responsibility to spend thousands of dollars on advertisement.
On a platform that pays creators over a billion dollars in a year, where individual creators and experiences are making millions of dollars, where businesses are being created, where experiences are being bought and sold for in extremely large deals, it’s not very reassuring to hear that we still need the training wheels.
Any creator that utilizes this and negatively impacts the multi-platform success of their experience should own the consequences.
There should be a path to this being possible, just like you can enable HttpService, cross-experience teleports, and server-side loadstring.
