1 Introduction

La présente page donne des précisions par rapport au micro-projet JIN4 qui, cette année 2024-2025, pourra être réalisé en binôme ou en monôme (2 maximum).

2 Contraintes par rapport au projet

• Votre application doit être réalisée avec Visual Studio, CLion ou Visual Studio Code.

• Votre code doit contenir au moins une hiérarchie de classe.

• Vous devrez montrer un diagramme UML des classes mises en place dans votre jeu.

• Votre code doit gérer correctement la mémoire.

• Votre code doit contenir des tests unitaires faits avec GoogleTest.

• Votre code doit mettre en oeuvre au moins deux Design patterns. Avant de blêmir, souvenez-vous que :

  • Tout au long de CSC4526, vous avez déjà utilisé 3 design patterns :

    • Factory qui vous a permis de créer différents types de Shape,
    • Composite qui vous a permis de spécifier qu’un Group était composé de Shape,
    • Prototype qui vous a servi à cloner vos objets dans l’exercice “Outil de visualisation” ;

  • Lors d’UV précédentes, vous avez probablement expérimenté les patterns Observer, Strategy ou State (rafraîchissez-vous la mémoire avec cet article), bien utiles dans le cadre du développement d’un jeu ;

  • Loïc JOLY considère que Singleton est un anti-pattern (voir dans le Moodle CSC4526 ses commentaires à ce sujet ; chercher “Quelques mots de Loïc Joly au sujet du design pattern Singleton”).

• Vous devez utiliser GIT tout au long de votre projet, en créant votre projet sous github. Veillez à donner accès à votre GIT à Loïc Joly et Michel Simatic.

• Votre code peut s’inspirer des Game programming patterns, même si nous ne sommes pas sûrs que vous aurez le temps de lire ce site pourtant passionnant.

3 Bibliothèques externes

Votre application doit être développée avec SFML ou Qt.

NB : Votre application ne peut pas être développée avec :

• Thor, car cette extension de SFML n’a pas évolué depuis 3 ans et ne semble donc pas compatible avec SFML 3.0.
• Unreal Engine (même en codant en C++ et non en Blueprint). En effet, le C++ Unreal Engine présente des différences avec le C++ standard (par exemple, un ramasse-miettes comme l’explique l’article “Unreal C++ vs. Standard C++”) qui vous empêcherait de montrer dans votre projet que vous avez acquis certaines compétences à la fin de ce cours.
• Godot, car nous redoutons que la puissance de ce moteur vous empêche aussi de montrer que vous avez acquis certaines compétences à la fin de ce cours (notamment si vous pratiquez GDScript).

Par ailleurs, votre application doit intégrer au moins une autre bibliothèque externe (que vous pouvez prendre ou non dans la liste ci-dessous). Elles vous permettront d’aller encore plus loin dans la réalisation de votre jeu :

• Box2D : Moteur de physique 2D pour les jeux. HelloWorldBox2D.zip est un projet contenant un “Hello World” Box2D, compatible avec cmake.
• Dear ImGui, un outil graphique utilisé notamment par Ubisoft (par exemple, dans Ghost Reckon, en parallèle de leur moteur de jeu) pour permettre des interactions en vue du debug de leur jeu. ExempleImguiSFML.zip contient un exemple mixant SFML et Dear Imgui via le binding avec SFML.
• Machine à états finis. Il existe de multiples bibliothèques :
  • Finite State Machine (fsm) est simple.
  • Meta State Machine (MSM) est très (voire trop) complet.
• JSON : Bibliothèque de Niels Lohmann ou éventuellement rapidjson. Cette page vous permet de comparer JSON et XML.
• Photon : Middleware de communication pour les jeux. Ce TP vous permet d’entrer dans Photon et vous fournit un exemple de projet compatible avec cmake.
• pugixml : Parser XML. Cette bibliothèque vous permettra d’exploiter aisément les données de configuration de votre jeu, stockées dans un fichier au format XML. SampleGoogleTestPugixml.zip est un projet contenant un exemple d’utilisation de pugixml , compatible avec cmake.
• Tiled map editor et tmxlite sa bibliothèque d’exploitation en C++ pour construire des niveaux de jeu. Tmxlite_SampleSFML.zip est un projet contenant l’exemple SFML de tmxlite, compatible avec cmake.
• ENet, couplé à Cereal (pour sérialiser les données à échanger), est un logiciel de communication bas niveau adapté au jeu vidéo. ENet_Cereal.zip contient un exemple d’utilisation de ces deux bibliothèques avec un (ou plusieurs) client(s) qui envoient des messages à un serveur chargé de les renvoyer en écho.
• A l’extrême rigueur (vu la taille de votre projet, ça semble un très gros marteau pour écraser une mouche), vous pouvez utiliser SQLite, un (petit) moteur SQL pour stocker des données en local. SQLite_example.zip est un projet contenant un exemple SQLite, compatible avec cmake ; attention : cet exemple ne compile actuellement que sous Windows.

Si vous trouvez une autre bibliothèque externe intéressante, SVP, postez ses références sur le Discord JIN4 pour la partager avec vos collègues et pour que nous complétions la présente liste.

4 Quelques ressources

• Facilitez-vous l’architecture de votre jeu en consultant les Design patterns, voire les Game programming patterns.
• Usez et abusez le Discord JIN4.
• Pour réaliser votre diagramme UML, utilisez plantuml ou tout autre outil que vous voudrez bien partager avec vos collègues et encadrants.
• FAQ C++ pour aller encore plus loin dans votre C++

5 Quelques conseils

5.1 Structure de votre projet

• Recopiez la structure des fichiers/répertoires de l’étape 4 de l’exercice “Outil (simplifié) de visualisation” (soit vos répertoires, soit ceux du corrigés) dans un répertoire qui contiendra votre micro-projet.
• Exploitez votre répertoire micro-projet selon la procédure Construire un projet C++ avec cmake.
• NB : Si vos tests unitaires ont besoin d’accéder aux fichiers ressources, pensez à modifier le fichier src/unitTests/CMakeLists.txt comme indiqué dans l’étape 3 de l’exercice “Outil (simplifié) de visualisation”.

5.2 Fichier .gitignore

Le fichier .gitignore est un fichier texte qui doit être placé à la racine de votre projet. Il permet de spécifier les noms des répertoires et les fichiers qui doivent être ignorées par GIT (il n’y aura donc pas de suivi de version pour eux). Cf. cette documentation pour plus d’informations.

Dans le cas de votre micro-projet, nous vous recommandons de créer un tel fichier (avec un éditeur de texte) pour qu’il contienne au minimum les lignes :

# Ignore directories used by CLion for project generation
.idea
cmake-build-debug
# Ignore directory used by Visual Studio for project generation
.vs
out
# Ignore directory used by Visual Studio Code for project generation
.vscode
build

Vous éviterez ainsi de stocker inutilement dans votre dépôt GIT des informations liées à la construction de votre exécutable.

5.3 Bibliothèques SFML

Jusqu’à présent, vous n’avez eu besoin que de la bibliothèque graphique de SFML. Pour votre jeu, il est probable que vous utiliserez également ses fonctions sons, réseau ou autre. Vous aurez alors des erreurs à l’édition de liens, car il vous manquera des définitions de fonctions SFML. Faites alors les opérations suivantes :

• Dans ./CMakeLists.txt, demandez la génération des bibliothèques SFML dont vous avez désormais besoin en mettant ON au niveau des lignes concernées dans :

option(SFML_BUILD_AUDIO "Build audio" OFF)
option(SFML_BUILD_NETWORK "Build network" OFF)

• Dans src/main/CMakeLists.txt, pour spécifier que votre exécutable main utilise toutes les bibliothèques SFML, ajoutez-les à la ligne target_link_libraries() (NB : nous recommandons de ne mettre que les bibliothèques SFML dont vous avez besoin : ainsi, vous limitez la durée de l’édition de liens et la taille de votre exécutable) :

target_link_libraries(main PUBLIC lib_core pugixml sfml-system sfml-window sfml-graphics sfml-audio sfml-network)

• Dans src/core/CMakeLists.txt, pour spécifier que vos fichiers sources dans src peuvent référencer les fichiers d’include de SFML, ajoutez sfml-graphics à la ligne target_link_libraries() (a priori, il n’y a pas d’autres bibliothèques à mentionner) :

target_link_libraries(lib_core PUBLIC pugixml sfml-graphics)

• Dans src/test/CMakeLists.txt, pour spécifier que votre exécutable unitTests utilise toutes les bibliothèques SFML, ajoutez-les à la ligne target_link_libraries(unitTests...) (NB : nous recommandons de ne mettre que les bibliothèques SFML dont vous avez besoin : ainsi, vous limitez la durée de l’édition de liens et la taille de votre exécutable):

target_link_libraries(unitTests GTest::gtest_main lib_core pugixml sfml-system sfml-window sfml-graphics sfml-audio sfml-network)

5.4 Recommandations pour le README.md de votre Github

Le fichier README.md de votre site Github doit au moins contenir les informations suivantes :

• Une petite description de votre application/jeu,
• Un petit mode d’emploi pour utiliser votre application/jeu (en particulier, les touches à utiliser),
• Si possible, une ou plusieurs copies d’écran, voire un lien vers une vidéo Youtube d’une session de jeu,
• Une explication de comment générer le code de votre application (n’hésitez pas à référencer la procédure Construire un projet C++ avec cmake).

6 Prochaines étapes

• 27/05/2025 17h15-17h45 : Présentation du micro-projet
• 28/05/2025 14h30-16h00 : Présentation (5’) par les monômes/binômes des premières idées sur chaque projet (pas de slide)
  • Planning
    • 14h30 : Binôme 1
    • 14h36 : Binôme 2
    • 14h42 : Binôme 3
    • 14h48 : Binôme 4
    • 14h54 : Binôme 5
    • 15h00 : Binôme 6
    • 15h06 : Binôme 7
    • 15h12 : Binôme 8
    • 15h18 : Binôme 9
    • 15h24 : Binôme 10
    • 15h30 : Binôme 11
    • 15h36 : Binôme 12
  • Contenu présentation
    • Grandes lignes de votre application (1-2’ maxi)
    • Lien avec le sujet
    • Si possible, quelles bibliothèques externes envisagez-vous d’utiliser ?
    • Difficultés pressenties
    • NB : c’est à cette séance que vous devez fournir un accès GIT aux encadrants JIN4.
• 28/05/2025 - 17/06/2025 (Discord JIN4) : Assistance au développement de votre projet
• 17/05/2025 23h55 : Livraison de votre code (afin que l’équipe encadrante ait le temps de regarder votre code)
• 19/06/2025, 9h00-12h15 & 13h30-16h15 : Soutenances / Revues de code
  • Durée de 26’ par projet.
  • NB : vous devez être présent·e à toutes les soutenances (sauf pour les personnes qui m’ont prévenu d’une contrainte majeure).
  • Déroulement
    • Sans transparent, mais avec votre machine
    • Démonstration de votre jeu
    • Démonstration des tests unitaires que vous avez effectués
    • Présentation de votre diagramme UML des classes
    • Pour le monôme ou chaque membre du binôme, le point de code dont vous êtes le·a plus fier·e
    • Pour le monôme ou chaque membre du binôme, le point de code qui vous pose le plus question
    • Questions / Réponses
  • Planning des soutenances (l’ordre de passage est imposé pour les 2 premières soutenances ; pour les autres soutenances, l’ordre de passage est libre) :
    • 09h00 : Soutenance de Mmes Havy / Siniavski
    • 09h28 : Soutenance de MM. Ben Lahcen / Lucas
    • 09h56 : Soutenance du monôme/binôme 3
    • 10h24 : Soutenance du monôme/binôme 4
    • 10h50 : Pause
    • 11h05 : Soutenance du monôme/binôme 5
    • 11h33 : Soutenance du monôme/binôme 6
    • 12h01 : Soutenance du monôme/binôme 7
    • 12h27 : Pause déjeuner
    • 13h40 : Soutenance du monôme/binôme 8
    • 14h08 : Soutenance du monôme/binôme 9
    • 14h36 : Soutenance du monôme/binôme 10
    • 15h02 : Pause
    • 15h20 : Soutenance du monôme/binôme 11
    • 15h48 : Soutenance du monôme/binôme 12
    • 16h14 : Evaluation CSC4526/JIN4 par les étudiant·es
    • 16h45 : Fin
• 19/06/2025 16h15-16h45 : Evaluation CSC4526/JIN4 par les étudiant·es

7 Grille d’évaluation (en cours d’affinage)

Par ordre décroissant d’importance :

1. Fonctionnement de l’application
   • Pas de bug majeur
   • Bonne gestion de la mémoire
   • Bonne gestion des performances
2. Qualité de votre code
   • Le diagramme UML présenté fait sens
   • Absences de grosses maladresses
   • Le code est documenté.
   • Les tests unitaires font sens.
   • Design patterns utilisés.
   • Éventuel(s) Game programming patterns utilisé(s)
3. Livraison du code en temps et en heure
4. Bonne utilisation de GIT
5. Bonne utilisation de 1 bibliothèque externe (en plus de SFML ou Qt)
6. Qualité du jeu
   • Lien avec le sujet
   • Gameplay
   • Finition

8 Sujet

Avant de vous dévoiler le sujet, tenez compte de cette remarque préliminaire : une fois que vous aurez le sujet, vous allez avoir des idées de réponse. Hé bien, faites une “purge”, c’est-à-dire éliminez les 5 premières idées qui vous viennent. En effet, ce sont les idées les plus évidentes, donc les idées les plus susceptibles d’avoir été trouvées par d’autres collègues, ce qui serait dommage.

Et le sujet de cette année est :

• Pour celles·ceux qui veulent développer une application interactive qui n’est pas un jeu vidéo, pas de contrainte particulière (hormis le fait que l’application permet de vérifier votre maîtrise des Acquits d’Apprentissage Visés, cf. grille d’évaluation).
• Pour celles·ceux qui veulent développer un jeu vidéo, voici le thème que doit respecter votre jeu : “L’agriculture : La pire erreur de l’histoire de l’humanité ?”. Si vous voulez approfondir ce sujet, voici quelques références :
  • Article “The worst mistake in the history of the human race” de Jared Diamond et sa traduction en français.
  • Extrait du livre “Sapiens : une brève histoire de l’humanité” de Yuval Noah Harari
  • Image tirée de la BD “Sapiens”