Ce billet est le premier d'une série où je vous parlerai de quelques points techniques sur le jeu.
Comme vous vous en doutez, derrière un jeu fluide et joli, il y a du boulot, et je vais vous montrer ce qui se passe derrière votre bel écran full HD. Ce post est assez détaillé, et même si je m'efforce d'être clair, il est destiné aux curieux étant un minimum dans la technique !
Alors je vais commencer, au hasard, par la physique. Oui, la physique ! Cette belle et douloureuse physique, qui se montre toujours sous ses plus beaux jours pendant le prototypage, pour au final se transformer en monstre vert fluo à neuf têtes pendant la production.
Comme vous vous en doutez, derrière un jeu fluide et joli, il y a du boulot, et je vais vous montrer ce qui se passe derrière votre bel écran full HD. Ce post est assez détaillé, et même si je m'efforce d'être clair, il est destiné aux curieux étant un minimum dans la technique !
Alors je vais commencer, au hasard, par la physique. Oui, la physique ! Cette belle et douloureuse physique, qui se montre toujours sous ses plus beaux jours pendant le prototypage, pour au final se transformer en monstre vert fluo à neuf têtes pendant la production.
Une des fonctionnalités de Wooden Sen'SeY est de pouvoir avoir des caisses un peu partout, qu'on puisse pousser, marcher dessus, et détruire. C'est quelque chose qu'on a décidé très tôt, au stade de prototype. On s'est dit : "Hey, on a un vrai moteur physique bien puissant, on peut mettre 14000 caisses sans problèmes !". Première erreur.
Un peu plus loin, après le début de la production, on s'est rendu compte que le jeu ramait violemment pendant les premières secondes d'un niveau :
Utilisation du CPU en fonction du temps au démarrage d'un niveau |
Tous les pics jaunes moches, là, c'est le moteur physique qui n'en peut plus. Au bout d'un moment, ça se calme...
Pour comprendre ce qui se passe, il faut expliquer une optimisation interne du moteur physique : le repos des objets. Au bout d'un certain temps, quand un objet physique ne bouge presque plus, le moteur le met en état de repos : sa position n'est plus calculée, et il ne se réveillera que si il est touché par quelque chose d'autre. C'est génial, ça permet d'avoir pleins d'objets posés partout, tant que seuls certains bougent, les performances sont excellentes.
Le problème, c'est qu'avant d'être décrété au repos, l'objet doit se stabiliser. Ce qui veut dire que pendant le début du niveau, tous les objets physiques qu'il contient, je dis bien tous, sont actifs, jusqu'à ce qu'ils soient assez stables pour se mettre au repos. D'où les pics d'utilisation CPU au début d'un niveau.
Première idée fumeuse : c'pas grave, je vais juste les placer à peu près correctement, les forcer à se mettre au repos au démarrage, ils se réveilleront quand je les pousserai ou que je taperai dedans ! Deuxième erreur.
Le problème, c'est qu'avant d'être décrété au repos, l'objet doit se stabiliser. Ce qui veut dire que pendant le début du niveau, tous les objets physiques qu'il contient, je dis bien tous, sont actifs, jusqu'à ce qu'ils soient assez stables pour se mettre au repos. D'où les pics d'utilisation CPU au début d'un niveau.
Première idée fumeuse : c'pas grave, je vais juste les placer à peu près correctement, les forcer à se mettre au repos au démarrage, ils se réveilleront quand je les pousserai ou que je taperai dedans ! Deuxième erreur.
Je m'en doutais, mais bon, ça valait le coup d'essayer ! En fait en règle générale le moteur physique n'aime pas qu'on touche à la main aux positions des objets. Ce qui fait que quoi que l'on fasse, on est soit trop loin, soit trop proche de la position que le moteur aurait calculé par lui-même. C'est grave docteur ? Oui !
- Si les deux objets sont trop proches, le moteur physique va considérer qu'ils rentrent en collision. Il les fera se repousser (donc se réveiller) et souvent on les retrouve à l'autre bout de la scène.
- Si les deux objets sont trop loins l'un de l'autre, le moteur ne va pas comprendre qu'ils sont les uns sur les autres. Ce qui amène à des situations très drôles (pas pour nous, m'enfin...) où on a une pile verticale de caisses, on casse celles qui sont en dessous, mais celles du dessus ne sont pas réveillées et flottent en l'air....
Vous avez vu, je fais flotter une caisse. Avec ma hache ! |
Ce qui, vous me l'accorderez, n'est pas top, mais alors là pas top du tout.
Ce qu'il faut donc, c'est pouvoir forcer tous les objets à s'endormir dès le lancement, mais avec des positions calculées par le moteur physique, sans placement à la main. Là, on a mis les mains dans le cambouis.
On a créé un petit outil qui n'a l'air de rien, mais qui enregistre ce qui se passe niveau physique. On lance le jeu dans un mode spécial : pas de joueur, pas de checkpoints, la plupart des scripts désactivés, toute la physique à l'état brut. Là, l'outil enregistre ce qui se passe. Une fois que tous les objets sont au repos, il copie leur position, et les sauvegarde.
C'est moche hein. Mais qu'est-ce que ça marche bien ! |
Du coup, tout est positionné aux petits oignons, et après quelques hacks de derrière les fagots, beaucoup de tests et de soirées très longues, le moteur physique est content, nous aussi, plus de lag au démarrage !
Aucun lag physique au démarrage ! C'est ça qu'on appelle la classe mon petit José. |
Voilà, c'est tout pour cette semaine. J'espère que ça vous a plu, n'hésitez pas à dire ce que vous en pensez. Stay tuned !
-- L'équipe Upper Byte, qui cuit le gâteau. The cake is not a lie ! It's so delicious and moist.