28 mai 2024
La présente page donne des précisions par rapport au micro-projet JIN4 qui, cette année 2023-2024, pourra être réalisé en monôme (imposé) ou en binôme.
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 :
Shape,Group était composé de Shape,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.
Votre application doit être développée avec SFML, Thor, Qt ou bien Unreal Engine (en codant en C++, pas de Blueprint).
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 :
cmake.cmake. Il utilise le binding avec SFML.cmake.cmake.cmake.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.
.\CMakeLists.txt
.\mainLauncher
.\resources
.\src
.\unitTestsmainLauncher\CMakeLists.txt contient les lignes (anciennes versions de TP) :add_custom_target(copy-resources ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/visage.xml)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/visage.xml
DEPENDS ${CMAKE_SOURCE_DIR}/resources/visage.xml
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_SOURCE_DIR}/resources/visage.xml
${CMAKE_CURRENT_BINARY_DIR})add_custom_target(copy-resources ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/resources)
file(GLOB RESOURCES CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/resources/*.*)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/resources
DEPENDS ${CMAKE_SOURCE_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${RESOURCES}
${CMAKE_CURRENT_BINARY_DIR}/resources)
add_dependencies(mainLauncher copy-resources)resources sera stocké dans un dossier resources accessible par votre exécutable. Donc, pour accéder à un fichier ressource, dans votre code C++, pensez à préfixer le nom de votre fichier ressource par resources/ (avec un seul “s”).cmake de ce document..\unitTests\CMakeLists.txt :add_custom_target(copy-resources-unitTests ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/resources)
file(GLOB RESOURCES CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/resources/*.*)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/resources
DEPENDS ${CMAKE_SOURCE_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${RESOURCES}
${CMAKE_CURRENT_BINARY_DIR}/resources)
add_dependencies(unitTests copy-resources-unitTests).gitignoreLe 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 directory used by Visual Studio for project generation
.vs
build
out
# Ignore directories used by CLion for project generation
.idea
cmake-build-debugVous éviterez ainsi de stocker inutilement dans votre dépôt GIT des informations liées à la construction de votre exécutable.
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 :
mainLauncher\CMakeLists.txt, pour spécifier que votre exécutable mainLauncher 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(mainLauncher PUBLIC src pugixml sfml-system sfml-window sfml-graphics sfml-audio sfml-network)src\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(src PUBLIC pugixml sfml-graphics)unitTests\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 src pugixml sfml-system sfml-window sfml-graphics sfml-audio sfml-network)cmake dans votre répertoire buildopenal32.dll est requis)En appliquant la section précédente, il se peut que vous ajoutiez la bibliothèque audio SFML qui requiert la DLL openal32.dll sous Windows. Vous pouvez vous contenter d’installer cette bibliothèque à partir de l’installateur situé en https://www.openal.org/downloads. Mais toutes les personnes qui cloneront votre projet devront aussi faire cette installation !
Aussi, nous vous proposons la méthode suivante :
lib_openal32 qui est au même niveau que votre fichier CMakeLists.txt principal.mainLauncher/CMakeLists.txt les lignes :if(WIN32)
file(GLOB_RECURSE DYNAMIC_LIBS CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/lib_openal32/${ARCH}/*.dll)
file(COPY ${DYNAMIC_LIBS} DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
endif()Avec cette méthode, plus besoin d’installer la bibliothèque openal32.dll.
Par ordre décroissant d’importance :
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 :