Baike.dev
Connexion
> 返回资讯列表
news_article.exe
Mon test de déterminisme a passé pendant des mois tandis que les deux constructions jouaient des jeux différents

Mon test de déterminisme a passé pendant des mois tandis que les deux constructions jouaient des jeux différents

My determinism test passed for months while the two builds played different games

2026年8月1日14 次浏览来源:Dev.to 阅读原文

J'ai compilé le moteur de règles d'un jeu Android expédié au navigateur. Même Java, deux compilateurs. Puis j'ai vérifié si les deux étaient d'accord. Ils ne l'ont pas fait — et le test que j'avais déjà eu pour exactement cela avait été vert tout le temps. La même commande deux fois : vert contre le moteur actuel, puis contre l'enregistrement engagé de la construction cassée. Jouez comme une session de terminal si vous voulez sélectionner le texte. La configuration Les règles vivent dans un module sans Android sur son chemin de classe, ce qui me permet de les compiler une deuxième fois avec TeaVM et exécuter la même logique sur une toile dans un onglet de navigateur. Une course ensemencée doit être reproductible. Donnez la graine 42 du moteur et une séquence fixe d'entrées, et vous devriez obtenir le même jeu à chaque fois — c'est ce qui rend un run replayable et deux constructions comparables. Voilà...

J'ai compilé le moteur de règles d'un jeu Android expédié au navigateur. Même Java, deux compilateurs. Puis j'ai vérifié si les deux étaient d'accord. Ils ne l'ont pas fait — et le test que j'avais déjà eu pour exactement cela avait été vert tout le temps. La même commande deux fois : vert contre le moteur actuel, puis contre l'enregistrement engagé de la construction cassée. Jouez comme une session de terminal si vous voulez sélectionner le texte. La configuration Les règles vivent dans un module sans Android sur son chemin de classe, ce qui me permet de les compiler une deuxième fois avec TeaVM et exécuter la même logique sur une toile dans un onglet de navigateur. Une course ensemencée doit être reproductible. Donnez la graine 42 du moteur et une séquence fixe d'entrées, et vous devriez obtenir le même jeu à chaque fois — c'est ce qui rend un run replayable et deux constructions comparables. Voici ce que j'ai effectivement obtenu, même graine, mêmes entrées: JVM navigateur premier obstacle x, cadre 60 405,426 304.426 toujours en vie au cadre 360 oui non score final 9 6 Pas une différence d'arrondi. Un jeu différent. La cause est ennuyeuse. La défaillance de l'essai ne l'est pas. utilisé . Son algorithme est spécifié jusqu'aux constantes — vous pouvez lire le générateur congruent linéaire exact dans le Javadoc. Donc une graine devrait nommer exactement une séquence. Mais mon code n'exécutait pas cet algorithme. Il était en cours d'exécution quelle que soit l'implémentation de l'exécution fournie, et TeaVM n'est pas le JVM. La spécification décrit ce qui fait; elle ne force pas la réimplémentation d'un runtime étranger à correspondre. La correction a pris dix minutes : écrivez le LCG à la main pour que les deux constructions exécutent le même arithmétique au lieu de faire confiance à ce qu'elles feront. La partie intéressante est le test. Le test qui n'aurait pas pu l'attraper, j'avais un test appelé . Il a couru le moteur deux fois, avec la même graine, et a affirmé que les résultats correspondaient. Il a transmis sur chaque commit, y compris chaque commit pendant lequel la construction du navigateur jouait un jeu différent. Ça devait passer. Il tourne le moteur deux fois au même moment. Un test en forme de qui ne peut pas observer un désaccord entre les runtimes

> 分享: