Document de design
Définir ensemble le jeu que vous souhaitez réaliser.
Le document de design sert de référence à toute l’équipe : il décrit l’expérience proposée, les règles du jeu et les limites du projet.
Privilégiez un document court et concret, avec des listes, des exemples et quelques croquis lorsque cela facilite la compréhension.
Le document de design est une production évaluée collectivement : l’équipe construit la proposition et répartit sa rédaction. Il ne fait pas partie des 15 documents de suivi attribués individuellement.
Ce qui est évalué¶
Consultez la grille du document de design sur Moodle avant de préparer le document, puis avant le dépôt. Elle porte sur :
Le concept et les règles du jeu.
L’organisation des niveaux.
Le périmètre et les éléments réutilisés.
L’utilité du document après les retours du livrable 0.
Le concept et le périmètre sont discutés au livrable 0 pour vous aider à les préciser ; ils sont évalués ici.
Prenez en compte les retours : expliquez les ajustements retenus ou pourquoi un choix est conservé. Un choix déjà pertinent n’a pas besoin d’être modifié pour satisfaire la grille.
Quand le préparer ?¶
| Étape | Travail attendu |
|---|---|
| Pendant l’autoformation | Explorer le projet fourni et préparer une première proposition de jeu. |
| Au livrable 0 | Présenter cette proposition et discuter des choix avec les encadrants. |
| Après les retours | Prendre en compte les échanges et remettre le document sur Moodle. |
| Pendant les sprints | Mettre à jour les choix qui évoluent avec le projet. |
La version révisée est à remettre le 10 octobre 2026, selon les modalités du calendrier.
Un document qui évolue
Vous n’avez pas besoin d’avoir résolu toutes les questions dès le livrable 0. Indiquez clairement les choix retenus, les idées encore à discuter et les points à vérifier.
Lorsque le projet évolue, mettez à jour les sections concernées. Le document doit décrire le jeu que vous développez réellement.
Les tâches et leur avancement sont suivis dans GitLab Issues. Le document de design explique ce que vous voulez construire et pourquoi.
Que doit-il contenir ?¶
Indiquez en tête du document le nom du jeu, éventuellement provisoire, le nom de l’équipe et la date de mise à jour.
| Partie | Question principale |
|---|---|
| Concept | Quelle expérience proposez-vous au joueur ? |
| Règles et déroulement | Que fait le joueur pendant une partie ? |
| Niveaux | Comment les salles et les parcours sont-ils organisés ? |
| Présentation et réutilisation | Comment rendre le jeu compréhensible et sur quoi allez-vous vous appuyer ? |
| Périmètre et questions ouvertes | Que pouvez-vous raisonnablement réaliser ? |
1. Concept du jeu
Présentez en quelques phrases :
L’univers ou le thème du jeu.
Le rôle du personnage et son objectif.
L’expérience recherchée : exploration, précision, prise de risque, réflexion, etc.
Ce qui donne une identité à votre proposition.
Le jeu doit respecter les contraintes du sujet : plateforme 2D, solo, avec Godot, puis génération des niveaux à partir de salles prédéfinies.
2. Règles et déroulement d’une partie
Décrivez :
Les actions principales du joueur et les commandes envisagées.
Les obstacles, dangers ou interactions nécessaires au concept.
L’objectif d’un niveau et la progression dans une partie.
Les conditions de victoire, de défaite et de redémarrage.
Ajoutez un court exemple de situation de jeu pour rendre les règles concrètes.
Choisissez peu de mécaniques, mais assurez-vous qu’elles fonctionnent bien ensemble.
3. Organisation des niveaux
Expliquez comment vous comptez organiser les salles :
Leur rôle dans le parcours.
Les ouvertures permettant de passer d’une salle à une autre.
Le principe reliant l’entrée à la sortie.
Les variations envisagées entre deux parties.
Ajoutez un croquis simple d’une salle ou d’un assemblage de salles. Il doit aider à comprendre les déplacements et les passages.
Précisez ce qui permettra au joueur de parcourir le niveau : compatibilité des ouvertures, hauteur des sauts, position des obstacles, etc.
À ce stade, une explication du principe suffit. Le Sprint 1 utilise un niveau conçu manuellement ; la génération est attendue au Sprint 2.
4. Présentation du jeu et éléments réutilisés
Décrivez les éléments nécessaires pour comprendre et utiliser le jeu :
Les informations affichées au joueur.
Les retours visuels ou sonores utiles pour comprendre ses actions.
La direction visuelle envisagée, avec des références si nécessaire.
Indiquez également les éléments que vous prévoyez de réutiliser :
Scènes ou scripts du projet fourni.
Graphismes, sons ou autres ressources externes.
Adaptations envisagées pour votre jeu.
Donnez les liens vers les sources et indiquez les licences ou crédits à conserver.
Des ressources simples ou provisoires conviennent. Des illustrations originales et des maquettes détaillées ne sont pas nécessaires pour ce document.
5. Périmètre et questions ouvertes
Distinguez clairement :
Les éléments essentiels : nécessaires pour obtenir un jeu cohérent et répondre au sujet.
Les éléments optionnels : à envisager si le temps le permet.
Les questions à résoudre : choix encore ouverts, difficultés techniques ou hypothèses à vérifier.
Identifiez les principales difficultés et expliquez comment vous pourriez simplifier le jeu si nécessaire.
Le périmètre doit tenir compte du temps consacré à l’autoformation, à la coordination, aux tests, aux présentations et à la documentation.
Il n’est pas nécessaire de recopier le Product Backlog ou de détailler ici toutes les tâches des sprints.
Format et dépôt sur Moodle¶
Conservez le document dans le fichier docs/design.md
du dépôt GitLab de votre équipe.
Les images éventuelles doivent également être présentes dans le dépôt et s’afficher correctement dans le document sur GitLab.
Pour le rendu, déposez sur Moodle :
Le nom de l’équipe.
Un lien permanent vers la version remise du document.