Organiser son jeu : services, Models et Folders

Ton niveau commence à se remplir de Parts. Sans rangement, tu auras vite des dizaines d’objets nommés « Part » dans le désordre, et tes futurs scripts ne sauront pas les retrouver. Cette leçon t’apprend comment Roblox organise un jeu, à quoi sert chaque grand service, et comment ranger l’Obby des Nuages dès maintenant pour ne pas le regretter au module 3.

Le data model : l’arbre de ton jeu

Tout ce qui compose un place (Parts, scripts, lumières, sons, interfaces) forme un grand arbre appelé le data model. C’est exactement ce que montre l’Explorer. Chaque élément de cet arbre est une instance (un objet) : toutes héritent de la même classe de base (le « modèle » commun à tous les objets), Instance, qui leur donne des propriétés communes comme Name (le nom) et Parent (le parent).

Le moteur de Roblox se sert de ce data model comme source de vérité : c’est à partir de lui qu’il simule et affiche le jeu sur l’appareil de chaque joueur.

Parents et enfants

Dans l’arbre, chaque objet a un parent (l’objet qui le contient) et peut avoir des enfants (les objets qu’il contient). Une Part posée dans le monde a pour parent le Workspace. Si tu la ranges dans un dossier, son parent devient ce dossier.

Quelques manipulations utiles dans l’Explorer :

• clique sur la flèche à gauche d’un objet pour déplier ou replier sa branche (maintiens Shift pour tout déplier d’un coup) ;
• fais glisser un objet sur un autre pour changer son parent ;
• clic droit puis Hierarchy › Select Children pour sélectionner tous les enfants d’un objet ;
• Ctrl+Shift+V (Paste Into) colle le contenu du presse-papiers à l’intérieur de l’objet sélectionné.

Quand tu supprimes ou déplaces un parent, tous ses enfants le suivent. C’est ce qui rend le rangement si puissant : déplacer un dossier déplace tout ce qu’il contient dans l’arbre.

Les services à connaître

Au premier niveau de l’arbre se trouvent les services : des conteneurs fournis par Roblox, chacun avec un rôle précis. Le moteur s’attend à trouver certains objets dans certains services : un script mal placé peut tout simplement ne pas s’exécuter.

StarterPlayer contient deux dossiers importants :

• StarterPlayerScripts : ses scripts sont copiés dans les PlayerScripts du joueur à son arrivée ;
• StarterCharacterScripts : ses scripts sont copiés dans le personnage à chaque apparition, donc à nouveau après chaque mort.

Tu croiseras aussi ReplicatedFirst (des objets envoyés aux joueurs avant tout le reste), SoundService ou TextChatService. Pas besoin de les maîtriser maintenant.

Certains services sont masqués par défaut pour garder l’arbre lisible. Un clic droit dans l’Explorer puis Show Services… permet de les afficher.

Folder ou Model ?

Pour regrouper des objets, tu as deux conteneurs. Ils se ressemblent dans l’Explorer, mais leurs rôles sont différents.

La PrimaryPart d’un Model

Quand tu déplaces ou tournes un Model, Studio s’appuie par défaut sur le centre de sa boîte englobante. Tu peux désigner une PrimaryPart : la Part de référence que suivent le point de pivot et la boîte englobante du Model. Pour la régler :

1. sélectionne le Model dans l’Explorer ;
2. dans Properties, clique sur la propriété PrimaryPart (le curseur change) ;
3. clique sur la Part voulue dans l’Explorer.

C’est surtout utile quand des scripts déplacent un Model, ou quand ses Parts sont reliées par des articulations. Les personnages des joueurs sont d’ailleurs eux-mêmes des Models.

Bien nommer ses objets

La documentation officielle le résume ainsi : nomme toujours tes objets de façon descriptive, pour les retrouver et les modifier facilement. Pour l’Obby des Nuages, on adopte les conventions suivantes :

• Un nom qui dit ce que c’est : PlateformeDepart, NuageDecor, plutôt que Part ou Model.
• Majuscule à chaque mot, sans espace ni accent : KillBricks, Pieces. Les noms affichés aux joueurs pourront avoir des accents, mais les noms d’objets que tes scripts utilisent restent simples.
• Des noms uniques parmi les enfants d’un même parent, surtout pour les objets que tes scripts chercheront.
• La bonne casse, toujours : pour Roblox, Checkpoints et checkpoints sont deux noms différents. Le tutoriel officiel le rappelle : une faute de majuscule suffit à casser un script.

Retrouver un objet avec la recherche de l’Explorer

Le champ de recherche en haut de l’Explorer (Ctrl+Shift+X) est bien plus puissant qu’il n’y paraît :

• plateforme : tous les objets dont le nom contient ce mot (sans tenir compte des majuscules) ;
• is:Part : toutes les Parts ;
• Anchored=false : toutes les Parts non ancrées. Parfait pour vérifier ton obby avant un test !
• Plateformes.* : tous les enfants directs de l’objet nommé Plateformes.

L’organisation de l’Obby des Nuages

Voici la structure que nous allons suivre pendant toute la formation. Crée dès maintenant les dossiers du Workspace, même vides : les modules suivants les rempliront.

Workspace
├── SpawnLocation          (le point de départ)
├── Plateformes            (Folder : toutes les plateformes, rangées par zone si besoin)
├── Checkpoints            (Folder : des Parts nommées "1", "2", "3"… — module 3)
├── KillBricks             (Folder : les pièges qui éliminent le joueur — module 3)
└── Pieces                 (Folder : les pièces à ramasser — module 3)
ReplicatedStorage
├── Remotes                (Folder : la communication client/serveur — module 4)
└── Modules                (Folder : les ModuleScripts partagés, comme Config — module 3)
ServerScriptService        (les scripts du serveur)

Les checkpoints seront nommés par leur numéro d’étape (1, 2, 3…) : un script pourra ainsi savoir à quelle étape correspond chaque checkpoint simplement en lisant son nom.

Aperçu : pourquoi les noms comptent pour les scripts

Tu apprendras à écrire du code au module 3. Mais regarde déjà comment un script retrouve un objet : par son chemin dans l’arbre et par son nom.

-- Script (côté serveur) à placer dans ServerScriptService
-- Aperçu : chaque ligne sera expliquée au module 3.
local Workspace = game:GetService("Workspace")

-- On attend que le dossier « Plateformes » existe dans le Workspace, puis on le récupère
local dossierPlateformes = Workspace:WaitForChild("Plateformes")

-- GetChildren renvoie la liste des enfants directs du dossier
local plateformes = dossierPlateformes:GetChildren()

-- Le signe # donne le nombre d'éléments de la liste
print("L'Obby des Nuages contient " .. #plateformes .. " plateformes")

Si tu renommes le dossier plateformes (sans majuscule), ce script ne le trouve plus : WaitForChild attend indéfiniment et, au bout de 5 secondes, l’Output affiche un avertissement d’attente infinie possible. Un simple renommage peut donc casser un jeu entier : choisis tes noms tôt et n’en change plus.

📌 Ce qu’il faut retenir

• L’Explorer montre le data model : un arbre d’instances où chaque objet a un parent et des enfants.
• Chaque service a un rôle : Workspace (monde 3D), ServerScriptService (scripts serveur), ReplicatedStorage (partagé), ServerStorage (stockage serveur, scripts inactifs), StarterGui, StarterPlayer, Lighting, Players.
• Folder = ranger une catégorie ; Model = un objet physique composé, avec une PrimaryPart possible.
• Des noms descriptifs, uniques et sans accent ; la casse compte.
• La structure de l’Obby des Nuages (Plateformes, Checkpoints, KillBricks, Pieces, Remotes, Modules) servira dans tous les modules.

📚 Sources et pour aller plus loin

• Data model — services, Folders et Models
• Explorer window — hiérarchie, Folders, recherche
• Models — création, PrimaryPart, comportements
• Greybox a playable area — rappel sur la casse des noms
• Instance — FindFirstChild et WaitForChild (référence API)
• Services — récupérer un service avec GetService