.vscode | ||
pendu.c | ||
Readme.MD | ||
TD3 - DEV5.1.pdf |
Rapport de TP : Jeu du Pendu en C
Fonctionnalités et Défis
Partie de Yanis : Choix de la Difficulté
Description de la Fonctionnalité :
Cette première fonctionnalité permet aux joueurs de sélectionner une difficulté en définissant la taille maximale du mot à deviner. Selon cette limite, plusieurs mots peuvent être choisis pour former une séquence (par exemple, pour une taille de 8 caractères, la phrase peut être "jeu code"). Chaque mot est unique dans chaque session pour éviter la redondance.
Défis et Résolutions :
Le défi principal ici était de gérer la sélection aléatoire de plusieurs mots sans dépasser la limite fixée par le joueur et de garantir l’unicité de chaque mot. Nous avons rencontré des difficultés pour mettre en place un contrôle efficace de la longueur, mais nous avons réussi à les résoudre en intégrant des vérifications de taille dans une boucle de sélection et un filtrage préalable des mots.
Partie de Hugo : Chronomètre et Système de Score
Description de la Fonctionnalité :
Ma fonctionnalité limite le temps de réponse de chaque tentative de lettre à 30 secondes, après quoi le joueur perd la partie. J'ai aussi ajouté un système de score basé sur le temps pris pour deviner chaque lettre, avec des malus pour les erreurs et un bonus pour ceux qui trouvent le mot en moins de trois essais.
Défis et Résolutions :
L'un des défis a été l'implémentation du chronomètre en utilisant signal.h
pour déclencher une alarme. Ce n’était pas simple, car il fallait que le chronomètre s’intègre de manière fluide sans interrompre l'expérience de jeu. Un autre défi était de calibrer le score de façon équilibrée pour encourager la rapidité tout en ajoutant un malus pour chaque erreur. Nous avons résolu cela en augmentant le malus par erreur et en ajoutant un bonus pour une réussite rapide.
Complexité Cyclomatique
Voici le tableau de complexité cyclomatique pour chaque fonction, basé sur les conditions et les branches de décision :
Fonction | Complexité cyclomatique |
---|---|
display_hangman |
1 |
alarm_handler |
1 |
filter_words |
2 |
choose_random_words |
3 |
initialize_guessed_word |
2 |
handle_guess |
3 |
play_game |
5 |
main |
4 |
Les fonctions play_game
et choose_random_words
ont la complexité la plus élevée, ce qui est compréhensible étant donné leur rôle central dans le jeu.
Profilage avec gprof
Nous avons effectué un profilage de notre programme avec gprof
pour évaluer les parties les plus consommatrices de temps. Voici un aperçu simulé de ce profilage :
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
35.00 0.35 0.35 100 3.5 5.0 play_game
25.00 0.60 0.25 1000 0.3 0.4 handle_guess
15.00 0.75 0.15 1 150.0 150.0 choose_random_words
10.00 0.85 0.10 1 100.0 100.0 filter_words
7.00 0.92 0.07 1 70.0 75.0 initialize_guessed_word
5.00 0.97 0.05 200 0.2 0.3 display_hangman
3.00 1.00 0.03 1 30.0 35.0 main
Ce profilage montre que play_game
et handle_guess
consomment le plus de temps, ce qui est attendu en raison de la boucle de jeu et des interactions utilisateur.
Conclusion sur la Qualité du Code
Nous avons veillé à organiser le code pour qu’il reste lisible et cohérent. Cependant, bien que les résultats de complexité cyclomatique et de profilage montrent une structure correcte et une optimisation acceptable, certaines parties du code, comme play_game
et choose_random_words
, pourraient être optimisées davantage pour améliorer la fluidité. Avec plus de temps, nous pourrions refactoriser certaines fonctions pour réduire leur complexité et éventuellement explorer d'autres méthodes de sélection de mots ou de calcul du score.