Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

by Noureddine Abdel Mélik Gueddach -
Number of replies: 5

Bonjour,

Les fichiers test E14.txt et E15.txt contiennent des Erreurs de collision joueur-obstacle et balle-obstacle respectivement.

Cependant, notre programme détecte une erreur de lecture bien avant, à savoir :

Par exemple, dans le fichier E14.txt :

Le 4e paramètre (count) est égal à 53 pour le 2e joueur. Or, dans le define.h, on a un #define MAX_COUNT 20. Ceci étant, nous vérifions que cette valeur est bien inférieure ou égale à 20. Ainsi, comme 53 > 20, le fichier contient une erreur et on termine la lecture avec une erreur custom parce que ce genre d'erreurs n'est pas prévu dans le fichier error.h

En effet, si l'on ne détecte pas et traîte pas cette erreur, cela provoquera des problèmes inattendus dans la suite de la simulation et l'on ne peut donc pas l'ignorer même s'il n'y a pas d'erreur prévue à ce sujet dans le error.h

Nous demandons donc de réévaluer la situation svp!

Merci d'avance.

In reply to Noureddine Abdel Mélik Gueddach

Re: Rendu1, incohérence des fichiers test / MAX_COUNT n'est pas dans la liste des tests à effectuer / mauvaise interprétation de MAX_COUNT

by Ronan Boulic -

Nous avons fourni la liste des tests à effectuer et le programme de démo pour comparaison.

Le compteur MAX_COUNT est le temps maximum que doit attendre un joueur avant de pouvoir tirer.

Il nest pas interdit d'avoir une valeur supérieure à MAX_COUNT pour un joueur. Lorsqu'une telle valeur existe cela veut dire que le joueur peut lancer sa balle.

In reply to Noureddine Abdel Mélik Gueddach

Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

by Noureddine Abdel Mélik Gueddach -
Oui mais si MAX_COUNT est 20, je ne vois que vient faire le mot MAX dans MAX_COUNT si on a le droit d'avoir un Count plus grand que MAX_COUNT...
In reply to Noureddine Abdel Mélik Gueddach

Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

by Noureddine Abdel Mélik Gueddach -
Update, je pense avoir compris : il y a un compteur qui est incrémenté à chaque tic du jeu et si ce compteur est plus grand que 20, on a le droit de tirer. Si l'on ne tire pas à 20, le compteur continue d'être incrémenté
Cependant, cette démarche n'est pas optimale et peut amener à des bugs obscurs à long terme. En effet, si l'on laisse tourner un jeu qui utilise ce genre d'algo suffisamment longtemps, on finit par atteindre la limite max des int et ça donne des résultats inattendus, expérience faite.
In reply to Noureddine Abdel Mélik Gueddach

Re: Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

by Saad Himmi -

Salut

L’overflow n’est pas un problème car il peut être évité de plusieurs manières différentes.

On pourrait imaginer un traitement différent du compteur entre la lecture initiale et la simulation.

Ou encore un attribut « ready to fire » qui dépend de Count.

Ceci dépend de votre développement.

(Personnellement, je pense qu’en général, utiliser >= MAX_COUNT est toujours plus sûr que == MAX_COUNT si cela ne pose pas de problème dans le reste du code d’etre plus grand que 20.)

In reply to Noureddine Abdel Mélik Gueddach

Rendu1, incohérence des fichiers test /!\IMPORTANT/!\

by Noureddine Abdel Mélik Gueddach -
Ce que je veux dire par là, c'est qu'on ne doit incrémenter le compteur que si l'on a : count < MAX_COUNT, normalement.
Ainsi d'une pierre 3 coups :
- on évite d'avoir des nombres gigantesques.
- on n'a pas d'information inutile (si on est plus grand que Max, être à 25 ou à 4799372 sont 2 informations différentes amenant au même résultat)
- Max_Count garde une sémantique correcte et logique. En effet, permettre en tte légalité à une variable d'être plus grande que MAX brise tout le sens de ce mot, et réduit la lisibilité du code. Un choix plus pertinent si l'on veut suivre cette approche est de le déclarer par exemple comme : MIN_COUNT_BEFORE_SHOOT et non pas MAX.
Et pis pourquoi créer un problème d' overflow et l'éviter ensuite si l'on peut l'éviter de base, et traiter la même information de 2 manières différentes réduit la logique intrinsèque au code.