Penser mobile d’abord

Tu as construit, sécurisé et publié l’Obby des Nuages. Mais sur quel appareil tes joueurs vont-ils le lancer ? Selon la documentation officielle de Roblox (page « Mobile input »), la majorité des sessions Roblox se jouent sur des appareils mobiles (« The majority of Roblox sessions are played on mobile devices »). La page « Test on hardware » ajoute que la majorité des joueurs utilisent des appareils mobiles peu puissants. Un obby qui tourne parfaitement sur ton PC peut donc ramer, chauffer ou devenir injouable au doigt. Dans ce module, tu vas apprendre à mesurer et à corriger tout ça. On commence par changer de réflexe : penser mobile d’abord.

Pourquoi le mobile change tout

Ton ordinateur de développement est presque toujours bien plus puissant que l’appareil de tes joueurs. La page « Test on hardware » de la documentation le dit clairement : si tu testes uniquement sur ta machine, tu testes pour la minorité de ton public.

Voici les quatre grandes contraintes d’un téléphone ou d’une tablette.

La mémoire

La mémoire vive (RAM) d’un téléphone est limitée, et Roblox n’y a pas accès en entier : le système et les autres applications en gardent une partie. Quand un jeu en demande trop, le système le ferme brutalement. C’est ce qu’on appelle un plantage par manque de mémoire (out of memory, OOM).

Le processeur et la carte graphique

Un PC puissant peut « encaisser » un script mal optimisé sans que tu remarques rien. Sur un téléphone modeste, le même script fait chuter le nombre d’images par seconde (FPS, frames per second). Par défaut, les jeux Roblox visent 60 FPS.

La chaleur

Quand un téléphone chauffe, il réduit volontairement la vitesse de son processeur pour se protéger. C’est le thermal throttling (bridage thermique). Ton jeu peut tourner correctement pendant deux minutes, puis ralentir petit à petit.

L’écran et les doigts

Un petit écran (5 ou 6 pouces de diagonale, soit 13 à 15 cm environ), des doigts qui cachent une partie de l’image, pas de souris ni de clavier : l’interface et les contrôles doivent être pensés pour ça.

Des contrôles tactiles confortables

Sur mobile, Roblox affiche par défaut un joystick virtuel en bas à gauche et un bouton de saut en bas à droite. La plupart des joueurs mobiles jouent avec leurs deux pouces : un sur le joystick, un sur le saut.

Les zones réservées

Les coins inférieurs gauche et droit sont réservés aux contrôles par défaut. N’y place jamais d’information importante ni de bouton : il serait caché par le pouce, ou déclenché par erreur au milieu d’un saut.

Les zones accessibles au pouce

Un bouton que l’on utilise souvent doit rester à portée de pouce. La documentation donne un bon exemple : un bouton placé à 40 % du haut de l’écran est facile à atteindre sur un téléphone, mais presque inaccessible sur une tablette, dont l’écran est bien plus grand. Teste donc les deux formats.

Une interface lisible sur tous les écrans

Au module 5, tu as construit l’interface de l’obby (compteur de pièces, boutique) avec des tailles en Scale. C’est la bonne base. Quelques points à vérifier spécialement pour le mobile :

• Les zones de sécurité. Les téléphones récents ont des encoches (notch) et des découpes pour la caméra. Roblox ajoute aussi sa barre de boutons en haut de l’écran (menu, chat…). La propriété ScreenInsets d’un ScreenGui règle la zone de sécurité (safe area) de son contenu. Sa valeur par défaut, CoreUISafeInsets, garde ton interface à l’écart des encoches et de la barre de Roblox. Garde-la pour toute interface avec des boutons.
• Le texte. Un texte lisible sur un grand écran d’ordinateur (en 1440p, par exemple) peut devenir illisible sur un petit écran. Utilise un UITextSizeConstraint (contrainte de taille de texte) pour qu’il ne descende jamais sous une taille minimale.
• Le contraste. Une interface claire posée sur un ciel clair (c’est le cas de notre obby dans les nuages !) devient vite illisible en plein soleil. Ajoute un fond sombre semi-opaque ou un contour au texte.
• La taille de l’écran. La propriété GuiService.ViewportDisplaySize classe l’écran en Small (la plupart des téléphones et tablettes), Medium (ordinateurs) ou Large (télévisions).

Adapter l’interface au mode de contrôle

La propriété UserInputService.PreferredInput indique le mode de contrôle principal du joueur : Touch (tactile), KeyboardAndMouse (clavier et souris), Gamepad (manette)… Elle change en direct, par exemple si un joueur sur tablette branche une manette Bluetooth.

Ce LocalScript agrandit le bouton de la boutique quand le joueur joue au tactile :

-- Nouveau LocalScript « AdaptationMobile », placé dans StarterGui > InterfaceObby
-- (le ScreenGui du module 5, à côté de ScriptInterface).
-- InterfaceObby contient le TextButton « BoutonBoutique » créé au module 5.
local UserInputService = game:GetService("UserInputService")

local interface = script.Parent
local boutonBoutique = interface:WaitForChild("BoutonBoutique") :: TextButton

-- Tailles en Scale : une fraction de l'écran, pas des pixels
local TAILLE_TACTILE = UDim2.fromScale(0.2, 0.12) -- plus grand pour le doigt
local TAILLE_CLAVIER_SOURIS = UDim2.fromScale(0.15, 0.08) -- la taille du module 5

local function adapterInterface()
	if UserInputService.PreferredInput == Enum.PreferredInput.Touch then
		-- Au doigt : un bouton plus grand, plus facile à toucher
		boutonBoutique.Size = TAILLE_TACTILE
	else
		-- Souris ou manette : un bouton plus discret suffit
		boutonBoutique.Size = TAILLE_CLAVIER_SOURIS
	end
end

-- On adapte une première fois au lancement…
adapterInterface()
-- … puis à chaque changement de mode de contrôle (manette branchée, etc.)
UserInputService:GetPropertyChangedSignal("PreferredInput"):Connect(adapterInterface)

Remarque l’approche : on ne vérifie pas en boucle si le mode de contrôle a changé, on réagit à un événement. C’est une habitude clé pour les performances, on y reviendra à la leçon 4.

L’orientation de l’écran

Par défaut, un jeu Roblox s’affiche en paysage et se retourne quand le joueur tourne son téléphone : c’est la valeur LandscapeSensor de StarterGui.ScreenOrientation. Pour un obby, c’est le bon choix : garde-le, sauf raison précise.

Tester avec le Device Simulator

Studio contient un simulateur d’appareils, le Device Simulator. Depuis septembre 2026, il prend la forme d’une barre d’outils au-dessus de la vue 3D. Tu l’ouvres depuis le menu Test › Device Simulator.

L’annonce officielle de l’équipe Studio sur le DevForum (publiée le 9 septembre 2026, mise à jour le 16 octobre 2026) indique qu’il est sorti de bêta et disponible pour tout le monde. Pourtant, en octobre 2026, la page de documentation affiche encore un avertissement « beta ». Si l’outil n’apparaît pas dans ton Studio, active New Device Simulator dans File › Beta Features, puis redémarre Studio. L’interface évolue vite : si elle diffère un peu de cette description, fie-toi à la page officielle.

Ce qu’il permet :

1. Choisir une catégorie d’appareil : Phone (téléphones et tablettes), Desktop, Console, Headset (casques VR).
2. Choisir un modèle dans le menu de l’appareil. Les téléphones sont classés en Flagship (haut de gamme), Mid-range (milieu de gamme) et Entry level (entrée de gamme).
3. Tourner l’appareil avec le bouton Rotate.
4. Simuler le tactile à la souris : un pincement (avec rotation) se fait avec Alt + glisser, un déplacement à deux doigts avec Alt + Shift + glisser.
5. Changer d’appareil pendant un test, sans arrêter la partie.

Le menu Display scaling est très utile. En mode Physical size, l’écran simulé est affiché à sa taille réelle : tu vois tes boutons aussi grands qu’ils le seront dans la main du joueur. Pour que ce mode soit exact, Studio doit connaître la taille de ton moniteur : l’option Calibrate physical scaling te fait aligner une image avec une carte au format carte d’étudiant.

Les limites de la simulation

Le simulateur vérifie très bien l’affichage et les contrôles. Il ne dit rien de fiable sur la mémoire ni sur les vraies performances : pendant un test dans Studio, ton PC fait tourner à la fois le serveur et le client. Pour ça, il faut un vrai appareil.

Tester sur un vrai appareil

Pas besoin d’un laboratoire. Un téléphone Android modeste, même ancien, suffit pour commencer. La documentation recommande de choisir au moins un appareil de référence (baseline) représentatif de tes joueurs et de tester dessus tout au long du développement.

1. Publie ton jeu (même en privé, comme au module 1) et lance-le depuis l’application Roblox du téléphone, connectée à ton compte.
2. Affiche les statistiques : dans le menu Roblox, onglet Settings, active Performance Stats. Une barre affiche FPS, mémoire et ping (le temps d’aller-retour d’un message entre ton appareil et le serveur, en millisecondes).
3. Joue tout l’obby, en touchant chaque bouton de l’interface, en pleine lumière si possible.
4. Teste la chaleur : joue 10 à 15 minutes d’affilée. Une baisse progressive des FPS indique un bridage thermique.
5. Note tout : on construira une vraie fiche de mesure à la leçon 5.

📌 Ce qu’il faut retenir

• Selon la documentation Roblox, la majorité des sessions se jouent sur mobile, et la majorité des joueurs ont des appareils peu puissants : mémoire limitée, processeur plus lent, surchauffe.
• Les coins inférieurs de l’écran sont réservés au joystick et au saut (c’est pour ça que le BoutonBoutique du module 5 est au bord gauche, à mi-hauteur) ; garde tes boutons à portée de pouce.
• Garde ScreenInsets sur CoreUISafeInsets et utilise PreferredInput pour adapter l’interface au mode de contrôle.
• Le Device Simulator vérifie l’affichage et les contrôles, pas la mémoire ni les vraies performances.
• Teste régulièrement sur un vrai appareil de référence, avec des sessions de 10 à 15 minutes.

📚 Sources et pour aller plus loin

• Mobile input — documentation Roblox
• Test on hardware — documentation Roblox
• Design for performance — documentation Roblox
• Device Simulator — documentation Roblox
• Annonce officielle de l’équipe Studio (Full Release) : New Device Simulator Toolbar and Network Simulator (DevForum)
• Network Simulator — documentation Roblox
• Position and size (zones réservées et zones du pouce) — documentation Roblox
• Cross-platform development — documentation Roblox
• ScreenGui (propriété ScreenInsets) — référence API