Pipeline de jeu Roblox
Un jeu, du début à la fin, avec validation du développeur à chaque porte. Cette compétence est le chef d’orchestre : chaque phase nomme la compétence ou l’outil qui fait le travail, ce que cette phase doit produire et comment savoir qu’elle est terminée. Ne réécrivez pas ce que ces compétences disent déjà ; chargez-les lorsque leur phase commence.
SK = ce dossier de compétence. PB = un éventuel playbook personnel : un dossier
(<playbook>/) de leçons génériques classées dans des dossiers thématiques tels que
game-design/, building/, engineering/ et thumbnails/. Si vous n’en avez pas
encore, ignorez les pointeurs PB ci-dessous et commencez-en un lorsque des leçons se présentent.
Les compétences compagnons nommées ci-dessous (studify, roblox-ui-maker, roblox-vfx,
roblox-game-score, claude-music, une compétence de conseil en conception,
jest-luau, scrapling, agent-browser) et la boîte à outils meshlab
(github.com/zriptic/roclicks-skills, dossier meshlab/) sont optionnelles. Si l’une
d’entre elles n’est pas installée, réalisez cette phase directement avec les mêmes « produit » et porte.
Avant toute chose
- Trouver ou créer le dossier du jeu :
<projects>/<slug>/. CopiezSK/templates/GAME.mddedans sous le nomGAME.md. Ce fichier est la source unique de vérité : état des phases, décisions, identifiants de lieu et d’univers, identifiants de ressources, questions ouvertes. Mettez-le à jour à la fin de chaque phase et à chaque décision prise. Une nouvelle session sur ce jeu commence par la lecture deGAME.md. - Lire la mémoire pour ce jeu et les règles permanentes du développeur. Le résumé
des règles se trouve dans
SK/references/rules.md; les faits mesurés sur le moteur et les outils sont dansSK/references/gotchas.md. Lisez les deux avant le premier appel Studio. - Trouver le Studio : utilisez un seul serveur MCP Studio pour toutes les modifications (cette
compétence a été écrite pour le serveur MCP
robloxstudiode la communauté ; le serveur officiel intégréRoblox_Studion’est utilisé que pourupload_image). Vérifiez quel lieu est ouvert avant chaque écriture : il y a souvent plusieurs lieux ouverts avec le même nom par défaut. - Planifier les phases que vous allez exécuter pour cette demande et dites-les en un seul message : phase, ce qu’elle produit, quelle compétence. Ignorez les phases dont la demande n’a pas besoin. Une refonte d’un jeu existant commence à la phase 0 avec « étude » ; une toute nouvelle idée commence à la phase 0 avec « concept ».
Les phases
| # | Phase | Produit | Compétence / outil |
|---|---|---|---|
| 0 | Concept / étude | pitch + analyse de référence dans GAME.md | une compétence de conseil en conception, SK/references/study-a-game.md, scrapling / agent-browser pour la recherche |
| 1 | Conception + économie | PLAN.md : boucle principale, progression, monétisation, chiffres ; une simulation de rythme | compétence de conseil en conception, PB/game-design/*, un script sim/ (Python ou luau) |
| 2 | Monde | Carte dans Studio, style de stud, chaque pièce visible un modèle meshlab | meshlab (SK/references/meshlab.md) ; le code de disposition place les modèles cuits ; PB/building/* pour les idées de disposition |
| 3 | Modèles | Chaque accessoire, bâtiment, véhicule et équipement de personnage sous forme de modèles meshlab, cuits en MeshData | meshlab (SK/references/meshlab.md, agents de modélisation en parallèle) ; sculpture SDF pour les créatures ; Meshy/Blender uniquement si le développeur le demande (SK/references/models.md) |
| 4 | Systèmes | Luau serveur/client : données, remotess, boucle, produits | PB/engineering/*, jest-luau pour les tests, CLI luau pour la logique pure |
| 5 | UI | Chaque écran, d’abord HTML, puis un ScreenGui réel | roblox-ui-maker (toujours ; lisez son LESSONS.md) |
| 6 | VFX | Effets de particules pour chaque moment clé | roblox-vfx (lisez son LESSONS.md) |
| 7 | Audio | Signaux musicaux + SFX, SoundGroups | roblox-game-score, claude-music* ; conservez vos identifiants de sons UI réutilisables vérifiés comme décrit dans SK/references/rules.md |
| 8 | AQ | Liste des défauts corrigés ; captures d’écran ; chronométrages de boucle | SK/references/qa.md |
| 9 | Lancement | Miniatures, icône, produits, lieu publié, analytique | SK/references/launch.md |
| 10 | Opérations en direct | Analytique lue, prochaine mise à jour planifiée | SK/references/launch.md (analytique), compétence de conseil en conception |
Les phases 2 à 7 peuvent se chevaucher une fois la phase 1 approuvée : un monde et son UI n’attendent pas l’un l’autre. Les systèmes (4) verrouillent l’AQ (8).
Portes de phase (ce que « fait » signifie)
- 0 → 1 : le développeur approuve le pitch et la boucle principale en une phrase chacun.
- 1 → construction :
PLAN.mdapprouvé par le développeur ; la simulation montre le rythme qu’il souhaite (première amélioration en moins d’une minute, première renaissance dans la fenêtre cible, aucun temps mort). Les chiffres viennent de la simulation, pas des intuitions. - Chaque phase de construction : vérifiée par des mesures et des captures d’écran, pas par
« ça compile » (voir
qa.md). Montrez des captures d’écran au développeur, demandez, et écrivez les retours dans leLESSONS.mdde la compétence concernée (UI, VFX) ou dans la mémoire. - 8 → 9 : la boucle se joue du début à la fin dans un playtest sans erreur dans
get_runtime_logs, disposition mobile vérifiée, 12+ captures d’écran à hauteur de joueur examinées. - 9 : rien ne devient public sans le « oui » explicite du développeur (publication, téléchargements, produits développeur, changements de prix).
Exécution des phases en parallèle (voies)
Pour une grosse avancée, utilisez des sous-agents en arrière-plan comme voies (outil Agent), un par
phase indépendante : monde, UI, VFX, audio. Les règles et les invites de voie prêtes à l’emploi sont
dans SK/references/lanes.md. Studio est une ressource partagée unique : une seule voie écrit
sur un lieu donné à la fois ; les autres préparent des fichiers (UI HTML, textures, modèles, musique)
et les remettent pour importation.
Toujours
- Style stud par défaut sauf si le brief ou la référence dit autrement.
- Des particules, pas des objets 3D, pour les effets.
- UI d’abord en HTML, icônes uniquement issues du pack d’icônes choisi pour le projet, jamais d’émojis.
- meshlab construit tout ce qui est visible (règle du développeur) : monde, accessoires,
véhicules, équipement. Les pièces seulement pour les collisionneurs invisibles, déclencheurs,
sièges et points d’apparition. Cuisez en MeshData, et le client reconstruit + ApplyMeshes
(
SK/references/meshlab.md). Pas de modèles gratuits. - Vérifiez par vous-même avec des captures d’écran et des mesures avant de montrer au développeur.
- Demandez avant de dépenser (crédits Meshy, téléchargements, produits facturés en Robux) et avant toute action publique.
- Poussez le Luau via
.rbxmx+import_rbxm, jamaisset_script_sourcepour quoi que ce soit contenant\ndans les chaînes (gotchas.md). - Enregistrez chaque décision, identifiant et leçon :
GAME.mdpour ce jeu, mémoire pour les faits inter-jeux,PBpour les leçons génériques (pas de noms de jeu ni de secrets là-dedans).