This article outlines best practices for Roblox game development across multiple platforms.
Unlike some game engines, Roblox is inherently cross-platform — players can discover and play games on a PC, then later pick up their phone and continue playing where they left off. In most cases, Roblox games should be accessible and enjoyable on all platforms, versus being optimized for one platform and just “basically functional” on others.
Recent stats cite that over 55% of Roblox game sessions are on mobile, so you should focus a proportionate effort on building a great mobile experience. When planning your UI and controls, consider the following:
Just because a GUI fits perfectly on a PC screen doesn’t mean it’s as functional on a smaller mobile screen. For example, the color customization tiles in this GUI become small and cramped on a phone:
In contrast, a slight redesign of the GUI offers a positive user experience on both PC and phone:
On mobile devices, the
/articles/customizing game controls#mobile-controls|default controls occupy a portion of the bottom-left and/or bottom-right corners of the screen. When you design the game UI, avoid placing important info or virtual buttons in these regions.
/articles/customizing game controls#mobile-controls|reference), the on-screen controls can vary slightly. Remember to design your UI around this possibility.
Most mobile players use two thumbs — one on the virtual thumbstick/DPad and one on the jump button. Depending on the physical size of the device and the player’s hands, “reaching” too far from the bottom corners becomes uncomfortable or impossible, so you should avoid placing frequently-used buttons outside of the green zones.
Comfortable thumb zones differ between phones and tablets since tablets have a larger screen. Remember that a button placed 30% below the screen’s top edge is easily reachable on a phone but almost unreachable on a tablet.
A more reliable way to position custom buttons is in direct relation to the jump button. The following code fetches the position of the jump button and creates a placeholder
ImageButton above it:
Screen space is considerably smaller on mobile devices, so you should show only the most vital information during active gameplay. For example, if there’s a special player action to open doors, it doesn’t make sense to constantly show an “Open Door” button — instead, the button should appear only when the player is near a door and disappear when they’ve moved a certain distance away.
In some cases, it’s necessary to know the player’s current device in order to adjust the UI, show action buttons/reminders, etc. For instance, if a player approaches a treasure chest and there’s an action bound to collecting the gold, you may want to show PC players an on-screen T key icon but show mobile players an active “Collect” button.
ModuleScript, placed within
ReplicatedStorage and renamed to PlayerInputModule, can be used to fetch the player’s input type, after which you can adapt the UI layout or context as suggested above.
UserInputService/GetLastInputType|UserInputService:GetLastInputType()method instead of just checking whether the device has an input "capability" like touch. This is because a PC player may prefer using their mouse and keyboard, even if their PC has touchscreen functionality, and your UI should respect the active input type.
Once the PlayerInputModule script is in place, you can get the player’s last input type from a
LocalScript as follows: