Par ailleurs, le problème de fluidité de Neverball n'est pas lié au langage mais juste à l'implémentation du moteur physique.
Dans la version 1.4.0, il n'y avait pas ce problème, cependant le comportement de la balle n'était pas assez constant d'une machine à une autre, ce qui pouvait poser des problèmes pour la compétition : un film (replay) enregistré sur une machine pouvait produire un résultat sensiblement différent sur une autre. Par exemple, si le joueur attrape une pièce en la frôlant, elle pouvait ne pas être prise sur une autre machine (pas cool).
De plus, cet ancien moteur pouvait causer une différence de quelques centièmes de secondes sur un même parcours. Ceci a été observé plusieurs fois sur des niveaux très basiques où la trajectoire optimale est la ligne droite vers la sortie. Les meilleurs performances se battent souvent au centième de seconde...
La correction du moteur a consisté à le rendre déterministe, càd qu'il est maintenant censé produire toujours le même résultat pour une même séquence de contrôle en entrée. Techniquement il a fallu rendre constant l'intervalle de temps entre 2 états internes du moteur, plutôt que dépendant des performances de la machine.
Au niveau réalisme de la simulation on y perd un peu, mais au niveau gameplay / compétition, on y gagne.
Par contre, ça a causé le problème de fluidité. Elviz l'a résolu dans Nuncabola en procédant à des interpolations d'états du jeu. Par contre personne dans l'équipe n'a été capable d'en faire autant pour Neverball (limites dans les compétences en maths).
[^] # Re: Performances
Posté par Mehdi Yousfi-Monod . En réponse à la dépêche Nuncabola, un Neverball en Java. Évalué à 5.
Par ailleurs, le problème de fluidité de Neverball n'est pas lié au langage mais juste à l'implémentation du moteur physique.
Dans la version 1.4.0, il n'y avait pas ce problème, cependant le comportement de la balle n'était pas assez constant d'une machine à une autre, ce qui pouvait poser des problèmes pour la compétition : un film (replay) enregistré sur une machine pouvait produire un résultat sensiblement différent sur une autre. Par exemple, si le joueur attrape une pièce en la frôlant, elle pouvait ne pas être prise sur une autre machine (pas cool).
De plus, cet ancien moteur pouvait causer une différence de quelques centièmes de secondes sur un même parcours. Ceci a été observé plusieurs fois sur des niveaux très basiques où la trajectoire optimale est la ligne droite vers la sortie. Les meilleurs performances se battent souvent au centième de seconde...
La correction du moteur a consisté à le rendre déterministe, càd qu'il est maintenant censé produire toujours le même résultat pour une même séquence de contrôle en entrée. Techniquement il a fallu rendre constant l'intervalle de temps entre 2 états internes du moteur, plutôt que dépendant des performances de la machine.
Au niveau réalisme de la simulation on y perd un peu, mais au niveau gameplay / compétition, on y gagne.
Par contre, ça a causé le problème de fluidité. Elviz l'a résolu dans Nuncabola en procédant à des interpolations d'états du jeu. Par contre personne dans l'équipe n'a été capable d'en faire autant pour Neverball (limites dans les compétences en maths).