Construire le premier niveau et le publier

Tu sais construire, ranger et tester : il est temps d’assembler le premier niveau de l’Obby des Nuages et de le publier. Cette leçon termine le module 1 avec un vrai résultat : un parcours jouable, enregistré sur ton compte Roblox, que tu pourras faire essayer à quelques amis. Elle prépare aussi le module 2, où tu apprendras à faire écrire le code de ton jeu par Claude Code. Ce n’est que la version 0.1, et c’est très bien ainsi : un jeu publié tôt s’améliore bien plus vite qu’un jeu parfait qui reste dans un tiroir.

Le plan du niveau 1

Reprends le cahier des charges du module 0. Pour ce premier niveau, vise :

• une zone de départ sûre et lisible, avec la SpawnLocation ;
• six à huit sauts qui commencent très facilement et deviennent un peu plus exigeants ;
• une plateforme d’arrivée bien visible, qui donne envie d’y aller.

Pas encore de pièges, de pièces ni de checkpoints : ils arrivent au module 3, construits avec Claude Code une fois ton atelier installé au module 2. Ton seul objectif ici : un parcours agréable à parcourir avec les commandes de base.

La zone de départ et la SpawnLocation

La SpawnLocation est l’endroit où les personnages apparaissent en rejoignant le jeu, et où ils réapparaissent après une mort. C’est une Part particulière : tu la déplaces, la redimensionnes et la colores comme n’importe quelle Part, et elle doit être ancrée.

Ses propriétés utiles pour l’instant :

Si plusieurs SpawnLocation sont valables pour un joueur, Roblox en choisit une au hasard. Garde donc une seule SpawnLocation au départ. La documentation montre qu’on peut aussi utiliser des SpawnLocation comme checkpoints grâce aux équipes ; dans cette formation, nous construirons nos checkpoints par script, ce qui nous laissera plus de contrôle (module 3).

Un obby dans le ciel

Pour un vrai obby dans les nuages, supprime la Baseplate (sélectionne-la dans l’Explorer, puis appuie sur la touche Suppr, Delete en anglais) et monte ta zone de départ en altitude. Un joueur qui rate un saut tombe alors dans le vide.

Que devient-il ? Le Workspace possède une propriété FallenPartsDestroyHeight : sous cette altitude, le moteur retire automatiquement les Parts qui tombent, ainsi que le Model qui les contient quand sa dernière Part disparaît. Le personnage du joueur, qui est un Model, est donc retiré. Comme la réapparition automatique est activée par défaut (propriété CharacterAutoLoads du service Players), le joueur réapparaît sur la SpawnLocation après un court délai (RespawnTime, 5 secondes par défaut). C’est la « chute » classique d’un obby, sans aucun script.

Construire les premiers sauts

Quelques repères de distance

• L’unité est le stud, environ 28 cm.
• Par défaut, un personnage marche à 16 studs par seconde (propriété CharacterWalkSpeed de StarterPlayer).
• La puissance du saut se règle aussi dans StarterPlayer. Selon la configuration de ton place, Studio y affiche soit CharacterJumpPower (50 par défaut), soit CharacterJumpHeight (une hauteur de saut, 7,2 studs par défaut). Pour la version 1, garde les valeurs par défaut.

Roblox ne publie pas de « distance de saut idéale » : la bonne distance dépend de la forme des plateformes, de leur hauteur et du ressenti que tu veux donner. La méthode fiable, c’est de placer, tester, ajuster. Le tutoriel officiel insiste sur ce point : si les premiers sauts sont trop difficiles, des joueurs risquent d’abandonner au lieu de continuer.

La méthode pas à pas

1. Dans le dossier Plateformes, crée la plateforme de départ, assez large pour que plusieurs joueurs y tiennent.
2. Règle le palier de déplacement sur 1 stud, puis duplique la plateforme (Ctrl+D) et déplace la copie avec Move. Commence par un écart court, sans dénivelé.
3. Place la caméra juste avant le saut, lance Test Here, essaie le saut plusieurs fois, puis arrête le test.
4. Ajuste l’écart, la hauteur ou la taille de la plateforme, et teste à nouveau.
5. Répète pour chaque saut en augmentant une seule difficulté à la fois : un peu plus loin, ou un peu plus haut, ou une plateforme un peu plus petite.
6. Glisse une plateforme de repos (plus large, sans difficulté) après deux ou trois sauts : le joueur souffle avant la suite.
7. Termine par une plateforme d’arrivée plus grande, d’une couleur différente.

Varier sans compliquer

Les formes de Parts suffisent pour varier le parcours : des cylindres posés à plat pour des plots ronds, des wedges pour une petite rampe, une TrussPart pour une échelle. Un enchaînement de formes différentes rend le parcours plus vivant, même avec des sauts simples.

Un parcours lisible

Dans un obby, le joueur doit comprendre en un coup d’œil où aller et où il peut poser les pieds. Quelques principes de lisibilité, couramment appliqués par les créateurs d’obbys :

• Du contraste : des plateformes de couleur franche se détachent bien sur un ciel clair.
• Un code couleur cohérent : une couleur pour les plateformes sûres, une autre pour l’arrivée. Réserve une couleur vive, par exemple le rouge, aux futurs pièges du module 3, et ne l’utilise jamais pour une plateforme sûre.
• Une direction évidente : le parcours doit se lire depuis la zone de départ, la prochaine plateforme toujours visible.
• Pas de piège visuel au début : les plateformes invisibles ou trompeuses frustrent les nouveaux joueurs. Garde-les pour plus tard, si tu en mets.

Vérifier avant de publier

Avant chaque publication, fais ce rapide contrôle :

• toutes les plateformes sont ancrées ;
• tout le parcours est faisable avec Test, depuis le départ ;
• l’Output ne montre aucune erreur rouge ;
• aucun modèle de la Toolbox ne contient de script suspect ;
• les objets sont rangés et nommés.

Pour le premier point, voici une commande à lancer dans la Command Bar : elle affiche le chemin complet de chaque Part non ancrée du dossier Plateformes.

-- À exécuter dans la Command Bar, en dehors d'un test
local dossier = game:GetService("Workspace"):FindFirstChild("Plateformes")
if dossier then
	for _, objet in dossier:GetDescendants() do
		-- On ne garde que les Parts dont Anchored vaut false
		if objet:IsA("BasePart") and not objet.Anchored then
			-- GetFullName donne le chemin complet, par exemple Workspace.Plateformes.Saut3
			print("Non ancrée : " .. objet:GetFullName())
		end
	end
	print("Vérification terminée")
end

Si seul « Vérification terminée » s’affiche, tout est ancré. Tu peux aussi taper Anchored=false dans la recherche de l’Explorer, comme vu dans la leçon 3.

Publier ta première version privée

Publier enregistre ton place dans le cloud de Roblox et le lie à ton compte. Au moment de la rédaction, voici la marche à suivre décrite par la documentation :

1. Arrête tout test en cours (sinon Publish est grisé).
2. Ouvre File › Publish (raccourci Alt+P, ⌥+P sur Mac).
3. Dans la fenêtre Game details, remplis le nom (par exemple « Obby des Nuages »), choisis le genre, écris une courte description. Tu peux ajouter une icône et une miniature dès maintenant ou plus tard (module 8).
4. Clique sur Save. Roblox crée ton jeu dans le cloud, avec un identifiant unique.

Ton jeu apparaît maintenant dans le Creator Dashboard (create.roblox.com, rubrique Creations), d’où tu peux le rouvrir dans Studio sur n’importe quel ordinateur.

Privé par défaut

Un jeu publié est privé par défaut : seuls toi et les personnes ayant un accès en modification peuvent y entrer. Pour recueillir de premiers avis, le menu File › Invite early testers permet d’inviter jusqu’à 10 amis d’une tranche d’âge compatible avec la tienne (les règles exactes dépendent de ton âge et sont détaillées sur la page officielle). Si tu n’as pas encore fait de vérification d’âge (age check), Roblox te la demande à ce moment-là. Ces testeurs voient un filigrane qui leur rappelle qu’il s’agit d’un aperçu, et les règles de la communauté s’appliquent toujours.

Save to Roblox ou Publish ?

Une fois ton jeu publié, deux commandes du menu File envoient ton travail dans le cloud :

• Save to Roblox enregistre une nouvelle version du place, sans la rendre disponible aux joueurs ;
• Publish enregistre une version et la livre aux joueurs : c’est elle que chargent les nouveaux serveurs (les serveurs déjà ouverts gardent l’ancienne version jusqu’à leur fermeture ou leur redémarrage). Studio te demande alors un nom de version et des notes.

La documentation ne présente pas cette différence en une seule phrase, mais elle en découle : les notes de version sont obligatoires à la publication « pour suivre ce qui a été livré aux joueurs », et une version restaurée n’atteint les joueurs qu’après une publication.

Pour sauvegarder ton travail en cours, Save to Roblox suffit. Pour livrer une version aux joueurs (même à tes seuls testeurs), utilise Publish.

L’historique des versions

Roblox conserve les versions enregistrées et publiées de ton place. La fenêtre Version History (menu Window › Version History) les liste, avec des filtres par date, par type d’enregistrement ou par collaborateur.

• Ajoute des notes : File › Save to Roblox with Notes (Ctrl+Alt+S, ⌘+⌥+S sur Mac) enregistre une version avec un nom et une description. Exemple : « v0.1 : 8 sauts, sans pièges ».
• Restaure une ancienne version : dans Version History, clique sur ⋮ à côté de la version voulue, puis Open Local Copy. Dans la nouvelle session, utilise File › Save to Roblox As pour écraser le place. C’est aussi possible depuis le Creator Dashboard (Configurations › Places › Version History › Restore).

Restaurer une version ne la publie pas : si le jeu est public, il faut ensuite la publier.

Travailler à plusieurs : Team Create (aperçu)

Team Create est la fonctionnalité de Studio qui permet de construire et de coder à plusieurs, en temps réel, sur le même jeu. Voici l’essentiel, d’après la documentation actuelle :

• Le bouton Collaborate, à droite du mezzanine, ouvre la fenêtre de gestion des collaborateurs.
• Pour un jeu qui t’appartient, tu peux donner l’accès Play à n’importe qui, mais la permission Edit seulement à tes amis Roblox.
• Au moment de la rédaction, collaborer avec d’autres créateurs demande une vérification d’âge, et la collaboration est limitée par défaut aux tranches d’âge compatibles. Tu peux utiliser Team Create seul sans cette vérification.
• Pendant une session collaborative, Studio enregistre automatiquement le projet dans le cloud toutes les quelques minutes (la documentation indique quatre ou cinq minutes selon les passages, au moment de la rédaction), et chaque collaborateur a une couleur qui montre ce qu’il sélectionne.
• Les commentaires (bouton Comment à droite du mezzanine, raccourci C) permettent d’épingler une remarque sur un objet du niveau.
• Le mode de test Team Test permet de tester ensemble.

Les conditions d’âge et de permissions évoluent : vérifie toujours la page officielle avant d’inviter quelqu’un.

La suite : scripter avec l’IA

Ton premier niveau est construit et publié. Jusqu’ici, tout s’est fait à la main, et c’était voulu : pour diriger une IA dans Studio, il faut d’abord connaître Studio. Au module 2, « Scripter avec l’IA : piloter Claude Code », tu changes de façon de travailler :

• tu installes un atelier de pro : le code du jeu en fichiers sur ton ordinateur (avec l’outil Rojo), un historique de versions de ces fichiers (avec Git, qui complète l’historique des versions de Roblox), Claude Code relié à Studio et des outils qui vérifient automatiquement le code ;
• tu écris le fichier CLAUDE.md de l’Obby des Nuages, la fiche qui décrit ton jeu et ses règles à l’IA ;
• tu apprends à écrire des prompts précis, à découper le travail en petites tâches, puis à relire, tester et déboguer ce que l’IA produit.

Ensuite seulement, au module 3, arrivent les kill bricks, les pièces et les checkpoints : construits avec Claude Code, et expliqués ligne par ligne pour que tu saches lire et vérifier ce que l’IA a écrit.

📌 Ce qu’il faut retenir

• La SpawnLocation est le point d’apparition : neutre, ancrée, une seule au départ.
• Supprime la Baseplate pour un obby dans le ciel : sous FallenPartsDestroyHeight, le personnage est retiré et le joueur réapparaît automatiquement.
• Construis les sauts par la méthode placer, tester (Test Here), ajuster, une difficulté à la fois, avec un code couleur lisible.
• File › Publish (Alt+P) lie le jeu à ton compte, qui reste privé par défaut ; Save to Roblox sauvegarde, Publish livre aux joueurs, Version History garde et restaure les versions (restaurer ne publie pas).
• Team Create permet de collaborer ; permissions et vérification d’âge sont à vérifier sur la page officielle.
• Au module 2, tu apprends à faire construire la suite par Claude Code, avec des prompts précis, puis à relire et vérifier le code produit.

📚 Sources et pour aller plus loin

• Create and publish games and places — publication, accès privé, early testers, sortie publique
• Roblox Kids and Select — exigences pour toucher les moins de 16 ans
• Version History — notes, restauration
• Collaboration — Team Create, permissions, conditions d’âge
• SpawnLocation — référence API (Neutral, Duration, Enabled)
• Workspace — FallenPartsDestroyHeight (référence API)
• Models — destruction des Parts tombées sous FallenPartsDestroyHeight
• Players — CharacterAutoLoads et RespawnTime (référence API)
• Release game updates — anciens serveurs et redémarrage après publication
• StarterPlayer — vitesse et saut des personnages (référence API)
• Work with parts — conseils sur la distance des sauts d’un obby
• Test and save — publier depuis Studio
• Claude Code — comptes acceptés et installation (documentation officielle)
• Conditions d’utilisation d’Anthropic (Consumer Terms) — âge minimum