Les livrables

Faites fonctionner l’exemple et montrez une ou deux modifications représentatives de votre exploration : changement du comportement du personnage, modification d’une salle, ajout d’une interaction simple…

Pour chaque exemple choisi :

• Expliquez le comportement initial et le changement recherché.

• Montrez le résultat dans Godot.

• Repérez la scène, les nœuds ou le script concernés.

• Expliquez les modifications et la manière dont vous les avez vérifiées.

Un extrait court ou une vue de la scène suffit pour soutenir l’explication. Chaque membre doit pouvoir expliquer sa propre exploration si une question lui est posée ; sélectionnez collectivement les exemples montrés à l’oral.

Appuyez-vous sur le document de design en cours de rédaction. Expliquez qui le joueur contrôle, ce qu’il doit accomplir, les difficultés qu’il rencontre, comment il gagne ou perd et comment il recommence.

Utilisez un croquis ou une maquette pour montrer un exemple de salle et expliquer le principe de leur assemblage. À ce stade, une explication de votre intention suffit : le générateur de votre jeu sera développé au Sprint 2.

Distinguez les fonctionnalités essentielles des idées optionnelles. Identifiez les scènes, scripts et ressources que vous comptez réutiliser, leurs sources et les adaptations envisagées.

Terminez par les points à valider avec les encadrants : faisabilité d’une mécanique, taille du jeu, choix encore incertain… Les retours alimenteront la version du document de design remise après la présentation. La préparation des backlogs aura lieu lors des séances suivantes.

Montrez comment commencer une partie, déplacer le personnage, sauter, rencontrer les obstacles et utiliser les interactions essentielles. Faites apparaître une victoire, une défaite et le redémarrage d’une partie. Préparez des parcours courts pour tenir dans le temps disponible.

Vérifiez notamment que les collisions fonctionnent et que recommencer réinitialise correctement le personnage et les éléments du niveau. Signalez les comportements encore incomplets.

Présentez brièvement les éléments principaux du projet, puis choisissez une réalisation à expliquer : contrôle du personnage, interaction, gestion de la fin de partie, redémarrage… Distinguez ce qui a été repris du projet fourni, adapté ou développé par l’équipe.

À partir du Sprint Backlog initial, résumez ce qui est terminé, partiellement réalisé ou reporté. Expliquez les écarts et les décisions prises pour conserver un jeu jouable.

Illustrez la répartition du travail et l’intégration avec un exemple concret reliant une issue, les modifications et une vérification. Présentez une difficulté significative et l’action retenue pour la suite.

Présentez une partie courte en conditions normales, avec les commandes et les retours destinés au joueur. Identifiez ensuite ce qui change d’une génération à l’autre.

À l’aide d’un schéma ou de quelques modèles de salles, expliquez :

• Comment un chemin relie l’entrée à la sortie.

• Comment les salles sont choisies et leurs ouvertures reliées.

• Comment plusieurs modèles produisent des niveaux différents.

• Comment vous vérifiez que le personnage peut réellement parcourir le chemin.

Montrez deux générations différentes. Choisissez aussi un exemple de vérification d’un passage : hauteur du saut, largeur de l’ouverture, obstacle ou transition entre salles.

La démonstration illustre les principes du sujet. Quelques cas réussis ne suffisent pas à garantir toutes les générations : expliquez les vérifications réalisées et les limites encore connues.

Faites la démonstration des opérations suivantes :

• Activer le mode de développement et montrer comment son activation est signalée.

• Lire la graine du niveau, puis la saisir pour retrouver le même niveau dans la même version du jeu.

• Relancer rapidement un niveau ou une partie.

• Utiliser l’aide au test retenue par votre équipe : invulnérabilité, accès direct à une situation ou autre commande simple adaptée au jeu.

Montrez où ces commandes sont documentées et comment revenir au jeu normal. Précisez la version à tester et les instructions pour la lancer sous Windows, macOS et Linux. Le guide de lancement complet doit être prêt pour ce livrable, afin que les deux autres équipes puissent utiliser le jeu en autonomie pendant le Sprint 3.

Concluez sur le travail du sprint : fonctionnalités prêtes, éléments partiels ou reportés, difficultés résolues et problèmes connus. Indiquez les situations qui méritent une attention particulière lors des tests par les deux autres équipes.

Vérifiez que les membres des deux autres équipes peuvent consulter et cloner le dépôt, accéder au commit de référence et lire les instructions de lancement.

Pour chaque jeu, identifiez le commit testé, la version de Godot et les systèmes utilisés. Si plusieurs versions ont été testées, précisez à quelle version correspond chaque résultat.

Présentez votre démarche commune, puis les adaptations propres à chaque jeu. Expliquez la répartition du travail et les choix effectués pour couvrir les deux jeux dans le temps disponible.

Distinguez les scénarios exécutés de ceux qui restent à tester. Présentez les limites rencontrées, notamment lorsqu’un problème bloquant a empêché d’autres vérifications.

Sélectionnez quelques résultats représentatifs pour chacun des deux jeux. Pour chaque problème présenté :

• Identifiez le jeu concerné et les conditions de reproduction.

• Comparez le résultat attendu au résultat observé.

• Expliquez les conséquences pour le joueur et la priorité proposée.

• Présentez une piste de correction lorsqu’elle est étayée ; distinguez une cause confirmée d’une hypothèse à vérifier.

Les démonstrations de bugs, captures d’écran et courts extraits vidéo sont encouragés. Pour un cas lié à la génération, indiquez aussi la graine et les actions effectuées.

Présentez également les comportements vérifiés qui fonctionnent. Si peu de bugs ont été trouvés, appuyez votre analyse sur les scénarios effectivement exécutés. Distinguez les défauts observés des suggestions d’amélioration.

Les résultats des deux jeux et leur synthèse doivent être prêts pour la présentation. Le délai du samedi permet de finaliser le rapport après les échanges.

Expliquez comment les retours du Sprint 3 ont été triés et priorisés. Montrez ensuite une partie représentative du jeu corrigé.

Pour quelques corrections significatives, présentez :

• Le problème initial et son issue.

• Le changement réalisé et le lien vers les modifications.

• La vérification effectuée en reprenant le scénario de reproduction.

• Le résultat obtenu et les autres comportements vérifiés pour repérer un éventuel problème introduit par la correction.

Examinez les rapports des deux équipes de test et regroupez les signalements qui concernent un même problème. Créez ou complétez vos issues de correction dans votre propre projet, en indiquant les liens vers les rapports et les identifiants des fiches correspondantes.

Créez une page itch.io par équipe, accessible au public et entièrement gratuite pour le 12/06/2027.

Elle doit présenter :

• Le nom du jeu et une courte description de son principe.

• Des captures représentatives, l’objectif du joueur et les commandes.

• Les instructions de lancement des téléchargements.

• Les crédits, les sources des éléments réutilisés et la version publiée.

• Les systèmes et navigateurs réellement testés.

La jaquette et la bande-annonce doivent compléter cette page au plus tard le 19/06/2027.

Proposez quatre versions du même jeu :

Les versions téléchargées doivent fonctionner sans installer Godot. Indiquez les éventuelles différences entre versions.

Pour publier la version web :

1. Exportez depuis Godot vers index.html.

2. Créez un ZIP avec index.html à la racine et tous les fichiers produits par l’export, en conservant leurs noms et leur organisation.

3. Sur itch.io, choisissez le type HTML et configurez ce ZIP comme jeu jouable dans le navigateur.

4. Ajoutez séparément les trois archives téléchargeables, avec le système correspondant clairement indiqué.

Téléchargez chaque archive depuis la page et testez-la sur le système annoncé. Vérifiez la version web dans deux navigateurs sur ordinateur, par exemple Firefox et Chrome : lancement, commandes, affichage, son et possibilité de terminer puis de recommencer une partie.

Testez les accès sans être connecté au compte qui a publié le jeu. Toutes les versions doivent correspondre au commit final identifié sur GitLab. Le README conserve aussi les instructions pour ouvrir le projet dans Godot.

Dans l’activité Produit final, pour le 12/06/2027 :

• Le lien cliquable vers le commit exact du produit final sur GitLab.

• Le lien vers le README à cette même révision.

• Le lien cliquable vers la page itch.io publiée, avec la version web jouable et les téléchargements Windows, macOS et Linux disponibles.

Dans l’activité Supports promotionnels, pour le 19/06/2027 :

• La jaquette au format PDF, prête à imprimer.

• Le lien cliquable vers la bande-annonce sur YouTube.

• Le lien cliquable vers la page itch.io complétée avec ces supports.

Effectuez un dépôt par équipe dans chaque activité. Ces deux dépôts alimentent la note commune enregistrée dans l’activité de soutenance finale.

Après la vidéo, présentez votre équipe et situez brièvement le projet : son objectif, le travail en équipe et le temps disponible. Expliquez ensuite le principe du jeu, ses commandes essentielles, ce qui permet de gagner ou de perdre et ce qui le rend intéressant.

Pendant la démonstration, expliquez ce que le public doit observer.

Pour les aspects techniques, choisissez des exemples accessibles, comme un schéma d’assemblage des salles ou l’évolution d’une mécanique. Expliquez les termes nécessaires. Les membres du public doivent pouvoir comprendre l’intérêt de vos choix sans connaître Godot ou Spelunky.

Utilisez la jaquette et la page itch.io pour présenter le jeu et indiquer comment l’essayer. Vérifiez que la version montrée correspond à celle annoncée dans votre support.

Faites le bilan de l’ensemble du projet avec quelques exemples concrets :

• Une décision importante sur le périmètre ou les priorités.

• Une difficulté technique ou d’organisation et la manière dont elle a été traitée.

• Une évolution du jeu issue d’un test ou d’un retour reçu.

• Une amélioration de la répartition du travail, de l’intégration ou des vérifications.

• Les contributions des membres et les compétences développées.

Expliquez ce que ces expériences vous ont appris et ce que vous feriez différemment lors d’un prochain projet. Situez les événements pour que le public comprenne leur contexte. Les liens vers GitLab dans le PDF permettent de retrouver les exemples si une question demande un détail.

Le Scrum Master assure le fil conducteur. D’autres membres peuvent expliquer une réalisation, une décision ou un apprentissage et participer à la démonstration. Tous doivent pouvoir répondre sur leur contribution.