2026–2027

Le jeu doit proposer :

• Un personnage contrôlable.

• Un objectif compréhensible et des obstacles à surmonter.

• Des conditions de victoire et de défaite.

• La possibilité de commencer une partie, de la terminer et de recommencer.

Les commandes doivent être compréhensibles et les événements importants doivent donner un retour visible au joueur.

Le niveau est composé de salles préparées à l’avance, dont les ouvertures permettent de passer d’une salle à l’autre.

Un chemin doit relier l’entrée à la sortie. Plusieurs modèles de salles doivent permettre de varier les niveaux.

Vous pouvez adapter les dimensions de la grille, le nombre de salles et leur contenu à votre jeu.

La variation des obstacles ou des éléments à l’intérieur des salles peut compléter ce principe lorsque la génération de base fonctionne.

Le dépôt GDQuest contient plusieurs démonstrations.

Récupérez le dépôt et importez le fichier godot4/project.godot dans Godot.

Ouvrez ensuite la scène random_walker/random_walker.tscn et exécutez cette scène.

Cet exemple permet d’explorer un personnage de plateforme et l’assemblage de portions de niveaux préparées à l’avance.

Vous pouvez réutiliser et adapter les scènes, les scripts et les ressources du projet fourni.

Dans votre dépôt :

• Indiquez les sources des éléments réutilisés.

• Conservez les mentions et les licences associées.

• Identifiez vos adaptations et vos propres ajouts.

• Soyez capables d’expliquer les éléments que vous utilisez.

Le fichier de licence du dépôt GDQuest précise les conditions de réutilisation : licence MIT pour le code et CC BY 4.0 pour les ressources artistiques et sonores.

Pendant les trois séances d’autoformation :

• Lancez le projet et observez son fonctionnement.

• Repérez les scènes, les nœuds et les scripts principaux.

• Identifiez comment les actions du joueur sont prises en compte.

• Réalisez de petites modifications et observez leurs effets.

• Notez vos questions et les difficultés rencontrées.

Chaque membre doit pouvoir expliquer une modification qu’il a réalisée.

L’équipe prépare également une proposition de jeu : concept, règles principales, éléments réutilisés et périmètre minimal.

Au livrable 0, vous présentez votre compréhension du projet fourni et votre proposition. Les retours reçus permettent ensuite de préciser le document de design.

La compréhension technique et les modifications de l’exemple sont évaluées au livrable 0 ; le concept et le périmètre sont évalués dans le document de design remis après les retours.

Consulter les consignes du document de design.

Réalisez une première version avec un niveau conçu manuellement.

Cette version doit permettre de :

• Contrôler le personnage et parcourir le niveau.

• Utiliser les mécaniques essentielles du jeu.

• Rencontrer des obstacles ou des situations de difficulté.

• Gagner ou perdre une partie.

• Recommencer après la fin d’une partie.

La génération automatique n’est pas exigée pour ce sprint.

Si cette première version fonctionne et que le temps le permet, vous pouvez commencer à explorer les fonctionnalités suivantes.

Consulter le guide de travail en équipe avec Git et Godot.

Ajoutez la génération des niveaux et complétez les fonctionnalités essentielles du jeu.

À la fin du sprint, les deux autres équipes doivent pouvoir lancer le jeu, comprendre comment jouer et effectuer une partie complète.

Prévoyez un mode de développement permettant de :

• Afficher la graine utilisée pour générer le niveau.

• Saisir une graine pour retrouver le même niveau dans la même version du jeu.

• Relancer rapidement un niveau ou une partie.

• Accéder facilement aux situations à tester, avec un outil adapté au jeu : invulnérabilité, accès direct à un niveau ou autre fonctionnalité simple.

Documentez les commandes de ce mode et rendez son activation visible.

La graine est une valeur utilisée pour initialiser la génération aléatoire. Elle permet de retrouver un niveau lorsque la génération est reproductible.

Pour décrire un problème, indiquez également la version du jeu et les actions effectuées. La graine seule ne décrit pas tout ce qui s’est passé pendant la partie.

Chaque équipe teste les jeux des deux autres équipes et prépare un rapport comprenant une section par jeu.

Répartissez le travail pour examiner les deux jeux dans le temps disponible. Pour chacun, préparez des scénarios couvrant les fonctionnalités essentielles et consignez les résultats obtenus.

Les bugs sont décrits sous forme de fiches dans votre rapport de tests : version testée, étapes de reproduction, résultat attendu et résultat observé. Ajoutez la graine, une capture ou une courte vidéo lorsque cela aide à comprendre le problème.

Vous ne créez pas d’issues dans les projets des équipes testées. Chaque équipe exploite les rapports reçus pour organiser ses corrections.

Le rapport présente, pour chaque jeu, les points satisfaisants, les problèmes prioritaires, les améliorations utiles et les limites des tests. Distinguez les causes vérifiées des hypothèses et des pistes de correction.

Consulter le guide des tests et du rapport.

Analysez les retours reçus et choisissez les corrections prioritaires.

• Corrigez les problèmes qui empêchent de jouer ou perturbent fortement l’expérience.

• Vérifiez les corrections en reprenant les scénarios qui avaient révélé les problèmes.

• Améliorez la clarté des commandes et des retours au joueur.

• Apportez les dernières finitions compatibles avec le temps disponible.

• Mettez à jour les instructions et les documents du projet.

Au livrable 4, présentez un produit fini, cohérent et fiable.

Le jeu est terminé au livrable 4. Préparez maintenant :

• La publication du jeu sur itch.io, avec une version jouable dans le navigateur et les téléchargements Windows, macOS et Linux.

• Une jaquette et une bande-annonce pour présenter le jeu.

• La soutenance, destinée à un public qui peut découvrir le projet.

Vérifiez l’accès au jeu et le lancement des versions distribuées. Les dernières corrections doivent rester mineures et être vérifiées.

Consulter les consignes de consolidation et de soutenance.

Le dépôt GitLab doit contenir le code, les ressources nécessaires au jeu et les documents de travail.

Le guide de lancement complet doit être prêt pour le livrable 2, puis maintenu à jour. Il doit permettre de :

• Cloner le dépôt et retrouver la version présentée.

• Identifier la version de Godot et les éventuelles dépendances.

• Ouvrir le projet et lancer le jeu sous Windows, macOS et Linux.

• Comprendre les commandes du jeu.

• Utiliser le mode de développement lorsqu’il est disponible.

Vérifiez ces instructions à partir d’une nouvelle copie du dépôt.

Le document de design doit rester cohérent avec le jeu réalisé. Mettez-le à jour lorsque les règles, les mécaniques ou le périmètre évoluent.