Projet en C - Jeu de Domino
Dernière réponse : dans Programmation
Voilà, après avoir terminé un projet sur linux, nous avons un nouveau projet à réaliser. Le but est de concevoir un jeu de domino en langage C. En fait, on souhaite écrire un programme en langage C permettant de jouer aux dominos contre l'ordinateur.
Quelques indications:
Il y a 28 dominos et 7 par joueurs (2joueurs)
C'est celui qui a le domino le plus fort qui commence
Chaque joueur doit garder ses dominos cachés
Lorsqu'un joueur n'a pas de domino à jouer, il passe son tour.
Le permier qui a posé tous ces dominos à gagner
Si personne ne pose tous ses dominos, c'est celui qui en a le moins qui gagne.
Notre professeur nous a dit d'utiliser exclusivement les listes
En fait, j'ai beaucoup de mal à démarer et j'aimerai pour l'occassion avoir un peu d'aide, voire quelques pistes pour démarer.
Merci :-)
Quelques indications:
Il y a 28 dominos et 7 par joueurs (2joueurs)
C'est celui qui a le domino le plus fort qui commence
Chaque joueur doit garder ses dominos cachés
Lorsqu'un joueur n'a pas de domino à jouer, il passe son tour.
Le permier qui a posé tous ces dominos à gagner
Si personne ne pose tous ses dominos, c'est celui qui en a le moins qui gagne.
Notre professeur nous a dit d'utiliser exclusivement les listes
En fait, j'ai beaucoup de mal à démarer et j'aimerai pour l'occassion avoir un peu d'aide, voire quelques pistes pour démarer.
Merci :-)
Autres pages sur : projet jeu domino
Lassé par la pub ? Créez un compte
Ben moi je vais te dire un truc générique qui marche à tous les coups (et qui font réduire le nombre de bugs)
Etape 1: Ecriture d'un document de spécifications: tu reprends l'énoncé et tu y ajoute ce qui n'y est pas (comme les règles par exemples) en indiquant comment le joueur va jouer (en couvrant un maximum de possibilités)
Etape 2 : écriture d'un document de conception: tu prévois toutes les fonctionnalités qui découlent des spécifications. Par exemple, tu auras une fonction qui change de joueur, une qui vérifie si le programme est terminé, etc. Le tout en précisant les points d'entrée et de sortie des fonctionnalités.
Si tu trouves de nouvelles fonctionnalités en intéraction avec l'utilisateur (le joueur), tu mets à jour ton document de spécifications.
Etape 3: bon tu peux enfin programmer. Tu prends le document de conception et tu codes ce qu'il y a écrit dessus. Si tu vois des problèmes techniques, tu mets à jours ton document de conception.
Etape 4: Tu fais un document de test en y mettant le plus grand nombre de tests possible (on peut reprendre le document de spécifications pour imaginer ces tests. Seulement après avoir notés tous les tests, tu les passes et tu corrige les bugs.
A la fin tu remet ton exécutable, tes documents de spécifications, conception et tests et tu auras une très bonne note (pas la peine de donner le code source si les documents sont bien fait ;-) )
Etape 1: Ecriture d'un document de spécifications: tu reprends l'énoncé et tu y ajoute ce qui n'y est pas (comme les règles par exemples) en indiquant comment le joueur va jouer (en couvrant un maximum de possibilités)
Etape 2 : écriture d'un document de conception: tu prévois toutes les fonctionnalités qui découlent des spécifications. Par exemple, tu auras une fonction qui change de joueur, une qui vérifie si le programme est terminé, etc. Le tout en précisant les points d'entrée et de sortie des fonctionnalités.
Si tu trouves de nouvelles fonctionnalités en intéraction avec l'utilisateur (le joueur), tu mets à jour ton document de spécifications.
Etape 3: bon tu peux enfin programmer. Tu prends le document de conception et tu codes ce qu'il y a écrit dessus. Si tu vois des problèmes techniques, tu mets à jours ton document de conception.
Etape 4: Tu fais un document de test en y mettant le plus grand nombre de tests possible (on peut reprendre le document de spécifications pour imaginer ces tests. Seulement après avoir notés tous les tests, tu les passes et tu corrige les bugs.
A la fin tu remet ton exécutable, tes documents de spécifications, conception et tests et tu auras une très bonne note (pas la peine de donner le code source si les documents sont bien fait ;-) )
Moi entre l'étape 2 et 3 je mettrais l'écriture du plan de test, et à l'étape 4 le passage des tests.
Cette méthode permet de tester ce que l'on a conçu et pas ce que l'on a codé. Cela est d'autant plus efficace quand le développement n'est pas fait par les concepteurs (et quand les développeurs prennent certaines libertés quand ils ont du mal ou la flemme pour faire certains points).
Cette méthode permet de tester ce que l'on a conçu et pas ce que l'on a codé. Cela est d'autant plus efficace quand le développement n'est pas fait par les concepteurs (et quand les développeurs prennent certaines libertés quand ils ont du mal ou la flemme pour faire certains points).
ouais c'est vrai que l'écriture avant le codage c'est surement mieux (faudra que je teste ça lol).
Le problème du fait que les développeurs omettent des tests ne vient pas, à mon avis, du fait qu'ils aient la flemme.
Je pense que ça vient surtout du fait qu'on a le même point de vue et qu'on teste finalement ce qui est censé fonctionner: on ne trouve que des erreurs d'inatention, et pas les erreurs dues aux oublis de cas d'utilisation. On code sans penser à un cas particulier alors on a un forte probabilité de passer à côté lors du test.
C'est vrai que du coup, le faire avant le codage pourrait permettre de trouver quelques-uns de ces problèmes avant.
Du coup, je pense que ça vient de là qu'on trouve les tests ennuyeux puisque qu'on sait ce qu'on teste et on pense, a priori, qu'il vont passer.
Le problème du fait que les développeurs omettent des tests ne vient pas, à mon avis, du fait qu'ils aient la flemme.
Je pense que ça vient surtout du fait qu'on a le même point de vue et qu'on teste finalement ce qui est censé fonctionner: on ne trouve que des erreurs d'inatention, et pas les erreurs dues aux oublis de cas d'utilisation. On code sans penser à un cas particulier alors on a un forte probabilité de passer à côté lors du test.
C'est vrai que du coup, le faire avant le codage pourrait permettre de trouver quelques-uns de ces problèmes avant.
Du coup, je pense que ça vient de là qu'on trouve les tests ennuyeux puisque qu'on sait ce qu'on teste et on pense, a priori, qu'il vont passer.
Lassé par la pub ? Créez un compte
