Merci pour cette question technique qui a plus d'implications qu'il n'y parait.
Depuis le premier semestre nous savons qu'en informatique il faut prendre en compte les questions d'arrondi et d'erreurs accumulées du fait des calculs. C'est pourquoi nous avions indiqué qu'il ne faut jamais faire un test d'égalité entre deux valeurs en virgule flottante.
Un peu plus tôt ce semestre nous avons vu une seconde illustration de ce problème d'arrondi avec la sauvegarde formatées dans un fichier : le fait de demander d'écrire un fichier en format ASCII plutôt que de sauvegarder la valeur binaire brute des variables produit en général un arrondi. On accepte cette "faiblesse" parce qu'on veut pouvoir consulter le fichier sauvé avec un éditeur de texte ou créer un nouveau fichier avec un éditeur de texte.
Si on n'utilise pas de marge pour décider du contact alors il va se passer ceci: on aura des cas où 2 joueurs sont très très proches mais pas encore "au contact" au sens mathématique du terme (cas d'une marge nulle) => si on décide de sauvegarder cet état du jeu qui semble sans collision, les valeurs arrondies sauvegardées dans le fichier peuvent produire une configuration qui produira une détection de collision au moment de relire ce fichier et empèchera de lancer la simulation. Et cela est d'autant plus vrai qu'on ajoute une marge ML au moment de la lecture.
C'est pourquoi le donnée demande d'utiliser une marge MJ pendant le jeu qui est deux fois plus grande que la marge ML utilisée pendant la lecture. De cette manière, même avec le problème de l'arrondi, on pourra relire un fichier sauvegardé parce que la lecture appliquera une marge plus petite et ne trouvera pas de collision dans l'état initial au moment de la lecture.