Rédiger le document dont la prochaine version a besoin
Un document de conception de jeu doit expliquer quoi construire, quoi exclure et comment savoir si le prototype fonctionne. Pour le développement assisté par IA, ses sections les plus utiles décrivent des règles concrètes, les commandes, les limites du périmètre et les vérifications d’acceptation. Un long résumé de l’histoire ne permet pas de déterminer si un objet peut être compté deux fois ou ce que Recommencer doit réinitialiser.
Ce guide utilise un seul exemple pédagogique : Rain Route, un petit jeu de livraison avec un robot. Son GDD, ses prompts, sa modification et ses tests concernent tous le même jeu proposé. Il ne s’agit ni d’un projet réellement généré ni d’une expérience utilisateur rapportée. Le processus montre comment relier les décisions à l’implémentation sans prétendre que la version proposée existe déjà.
Copier ce mini-GDD rempli
Rain Route, version de conception 0.1.
Concept : un robot transporte des colis de souvenirs à travers un pâté de maisons sous la pluie.
Joueur et plateforme : une personne seule, sur navigateur de bureau avec clavier. Viser une première session d’environ cinq minutes comme objectif de conception, pas comme résultat mesuré.
Promesse et piliers : navigation calme, destinations lisibles et petits choix d’itinéraire. Privilégier des retours clairs plutôt que des systèmes supplémentaires.
Boucle principale : prendre un colis au dépôt, marcher jusqu’à la porte numérotée correspondante, le livrer et revenir chercher le suivant. Trois livraisons donnent la victoire.
Commandes et caméra : caméra fixe en vue de dessus. WASD ou les flèches déplacent le robot. E prend ou livre un colis dans la zone d’interaction indiquée. R recommence après une victoire. Afficher les instructions à l’écran.
Règles : un seul colis peut être porté. Les livraisons ont lieu dans l’ordre : portes 1, 2, puis 3. E à la mauvaise porte affiche un message sans retirer le colis. Chaque livraison correcte augmente le compteur une seule fois. Appuyer plusieurs fois sur E ne peut pas recompter une livraison déjà effectuée.
Carte et défi : un pâté de maisons, un dépôt, trois portes, une traversée de flaque et un détour au sec. Dans la flaque, la vitesse est réduite à la moitié de la vitesse normale. Pas de perte de vie, d’ennemis ni de défaite au chronomètre.
Retours : afficher la destination actuelle, le colis porté et les livraisons effectuées. Utiliser des numéros de porte distincts et une confirmation visible de livraison. L’ambiance de pluie doit rester discrète ; prévoir une commande de coupure du son.
Périmètre technique : un prototype pour navigateur, sans comptes, sauvegardes dans le cloud, réseau, achats, cartes supplémentaires ni système de déblocage. Recharger démarre une nouvelle partie. Utiliser des formes originales simples jusqu’à ce que la boucle passe les tests.
Victoire et réinitialisation : après la troisième livraison, afficher un panneau de victoire. R remet le robot, le colis, la destination, le compteur de livraisons et le panneau de victoire dans leur état initial.
Question de revue : un nouveau joueur peut-il effectuer la première livraison en utilisant uniquement les instructions visibles ?
Étape 1 : transformer le GDD en une demande de réalisation
Utilisez le document comme entrée, pas comme preuve d’implémentation. Avant de l’envoyer, vérifiez les contradictions entre le périmètre, les commandes et la condition de victoire. « Recharger démarre une nouvelle partie » exclut une promesse de livraisons persistantes ; « un seul colis » exclut une file d’inventaire cachée. Tranchez ces décisions dans le GDD au lieu de laisser l’implémentation deviner. Un premier prompt adapté serait :
Crée Rain Route à partir de la version de conception 0.1. Implémente d’abord uniquement la carte, le déplacement, la prise du colis au dépôt et la livraison à la porte 1. Garde les autres portes visibles mais inactives. Affiche la destination actuelle et l’état du colis porté. Utilise des formes originales simples. N’ajoute ni effets météorologiques, ni déblocages, ni chronomètre de défaite, ni mécaniques supplémentaires. Explique les composants modifiés et comment tester la prise, l’interaction à la mauvaise porte, la livraison correcte et les pressions répétées sur E.
Limitez cette première demande à une tranche de livraison. Son résultat doit permettre d’examiner une interaction complète avant de multiplier les destinations. Si le parcours ne peut pas être terminé avec les commandes documentées, corrigez cette tranche au lieu d’agrandir la carte.
Étape 2 : relier les exigences aux tests dans le même jeu
Attribuez de courts identifiants aux règles importantes et conservez-les dans le prompt, les notes et le relevé de test :
| Exigence | Action dans Rain Route | Résultat attendu |
|---|---|---|
| R1 : un colis maximum | Appuyer deux fois sur E au dépôt | Un seul colis reste porté |
| R2 : destination correcte uniquement | Aller à la porte 2 avec le colis 1 | Un message apparaît ; le colis reste porté |
| R3 : livraison comptée une fois | Livrer à la porte 1 puis appuyer plusieurs fois sur E | Le compteur reste à un |
| R4 : progression ordonnée | Effectuer les trois livraisons | La destination avance 1 → 2 → 3 ; la victoire apparaît une fois |
| R5 : ralentissement dans la flaque | Chronométrer le même trajet balisé dans et hors de l’eau | La vitesse dans la flaque correspond à la moitié spécifiée |
| R6 : réinitialisation complète | Appuyer sur R après la victoire | Position initiale, mains vides, zéro livraison, aucun panneau de victoire |
Consignez les observations réelles dans un journal d’exécution distinct avec la version du build et l’environnement. N’ajoutez un statut tel que réussite, échec ou bloqué qu’après avoir effectué l’action. Si la première tranche échoue à R2, corrigez cette interaction avant de demander trois livraisons. Décrivez la séquence d’entrées assez précisément pour qu’une autre personne puisse reproduire l’échec.
Étape 3 : étendre la boucle, puis ajouter l’ambiance
Après la réussite de la première livraison, demandez les portes 2 et 3 ainsi que les états de victoire et de réinitialisation. Réexécutez R1 à R4 et R6. Demandez ensuite le ralentissement dans la flaque et vérifiez R5 sans modifier la logique de prise.
Ce n’est qu’une fois ces règles validées que vous devriez ajouter les visuels de pluie et une ambiance sonore discrète. Vérifiez que la pluie ne masque pas les numéros ou marqueurs d’interaction et que la coupure du son fonctionne. Si l’effet météo rend la carte illisible, réduisez-le au lieu d’accepter une ambiance au détriment de la promesse faite au joueur.
Étape 4 : mettre à jour le GDD lorsque les preuves modifient une décision
Supposons qu’un futur test montre que les joueurs ne remarquent pas la destination actuelle. Il s’agit ici d’une observation hypothétique, pas d’un résultat. Une modification ciblée demanderait un libellé de destination plus visible tout en préservant l’ordre des portes et les règles de livraison. Retestez la même question sur la première livraison avec un nouveau joueur.
Consignez la décision comme version 0.2, expliquez pourquoi elle a changé et reliez-la à l’exigence et au build concernés. Gardez les décisions antérieures accessibles afin qu’un ancien résultat de test ne soit pas pris pour une preuve concernant une nouvelle règle. Une exigence révisée doit indiquer quelles vérifications précédentes réexécuter.
Lorsqu’une modification générée casse une exigence antérieure, revenez en arrière ou isolez-la. Signalez l’exigence en échec, l’entrée exacte, le résultat attendu et le résultat réel. « R3 compte deux fois après plusieurs pressions sur E » est plus exploitable que « le prototype semble avoir des bugs ».
Utiliser SEELE entre la spécification et le journal de test
SEELE prend en charge la création de jeux en langage naturel et les modifications itératives portant sur le gameplay, les scènes et les ressources. Fournissez le mini-GDD comme entrée de conception, puis demandez une tranche d’implémentation limitée. Le résultat utile est un build candidat à comparer au même document, pas un remplacement du jugement de conception ni un relevé de test terminé.
Pour chaque suivi, nommez l’exigence modifiée et celles qui doivent rester stables. Demander un libellé de destination plus clair ne devrait pas introduire silencieusement un chronomètre ou changer l’ordre des portes. Reliez document, prompt et résultat observé par version pour qu’une description soignée ne remplace jamais le comportement réel.
Utiliser le GDD pour commencer la réalisation, pas pour la retarder
Un GDD utile réduit la distance entre une décision et sa vérification. Rain Route a besoin d’une règle de prise claire, d’un ordre des destinations et d’une définition de la réinitialisation avant d’avoir besoin d’un résumé plus long de son histoire. Gardez le document court, mais rendez les règles assez précises pour qu’une autre personne puisse juger le même build.
Copiez la spécification dans SEELE et demandez la première tranche de livraison. Gardez le document, le build fonctionnel et le journal de test alignés par version. N’étendez le périmètre que lorsque les règles existantes du même jeu résistent à l’implémentation et aux modifications, et mettez à jour le GDD lorsque les preuves changent une décision.
Relier la conception à une vérification jouable
Ce tableau organise les vérifications proposées dans l’article. Il ne présente pas les résultats d’un test effectué.
| Élément du GDD | Question à laquelle il répond | Exemple de vérification d’acceptation |
|---|---|---|
| Joueur et commandes | Qui joue et comment agit-il ? | Un joueur sur ordinateur peut déplacer le robot avec les commandes clavier spécifiées. |
| Objectif et périmètre | Que doit-il se passer dans cette version ? | Le joueur peut livrer le colis spécifié dans la scène définie. |
| Règles et limites | Que se passe-t-il lorsqu’une règle est déclenchée ? | Une livraison ou une prise est comptée uniquement comme le prévoit la conception. |
| Échec et reprise | Que se passe-t-il lorsque le joueur ne peut pas terminer la tâche ? | Le comportement d’échec ou de redémarrage prévu ramène le jeu à son état documenté. |
| Journal des modifications | Quelle décision a changé et pourquoi ? | Consigner l’observation, la règle modifiée et le résultat de la nouvelle vérification. |
FAQ
Quelle longueur doit avoir un GDD de prototype ?
Il doit être aussi court que possible tout en résolvant les prochaines décisions d’implémentation. L’exemple rempli précise périmètre, commandes, règles et tests sans constituer une bible de production. Ajoutez des sections lorsqu’elles changent ce qu’une personne construit ou vérifie. Une règle d’interaction manquante coûte plus cher qu’une page absente sur l’histoire de fond.
L’IA peut-elle rédiger le document à ma place ?
L’IA peut rédiger des sections et révéler des ambiguïtés, mais vous devez décider des règles et vérifier leur faisabilité. Demandez-lui d’identifier les exigences contradictoires et les critères d’acceptation manquants. Ne considérez pas un document soigné comme une validation du plaisir de jeu, de la qualité d’implémentation, des droits sur les ressources ou de capacités produit non vérifiées.
Quelle différence entre le GDD et le journal de test ?
Le GDD énonce les comportements et décisions prévus. Le journal de test consigne ce qui s’est produit dans un build et un environnement précis. Reliez-les tout en les gardant distincts : une attente formulée comme réussite n’est pas un test réussi. Lorsque les observations justifient une modification de règle, mettez explicitement à jour la conception et réexécutez les vérifications concernées.
Une liste de contrôle de chapitre pour un GDD plus grand
Ajoutez des sections uniquement lorsqu'elles guident une décision pour la prochaine version. Commencez par le public, la plate-forme et le pitch d'une phrase. Suivez la boucle principale, les commandes, la progression, le monde ou la narration, les contraintes artistiques et sonores et les exigences techniques. Pour chaque fonctionnalité concernée, indiquez son propriétaire, la plus petite preuve jouable et un test que l'équipe peut réexécuter. Déplacez les idées facultatives vers un backlog distinct.
