Meilleure branche

Voilà déjà un moment que j'y cogite: faire en sorte que la branche-qui-rebondit soit plus facile à utiliser. Dans sa version actuelle, on doit appuyer sur le bouton de saut au moment où elle nous propulse, pour bénéficier de la hauteur maximale. ça ferait bizarre de se voir propulser plus tôt, l'ennui c'est qu'entre les deux Bilou nous fait un petit rebond casse-pied.

A few notes on how the bouncy branch should be adjusted. But I wanted to try at least one thing before starting to discuss it: couple branch animation and motion so that the actual position of the "solid" hit box of the branch would change over time.

With that done, I could switch Bilou to a "land on soft ground" state where some button press are frozen in time, and when the branch will eventually reach the animation frame where a "throw up" collision can happen, player's JUMP input wouldn't be ignored.

Une des stratégies que je veux mettre en place, c'est donc de lui rajouter un état "atterri sur quelque-chose de mou" pendant lequel il attendrait que l'animation de la branche se termine et atteinge les images où on propulse Bilou.

J'aimerais évidemment que Bilou suive le mouvement de la branche pendant ce temps-là, et c'est en tentant de corriger ça que je me suis retrouvé bloqué par un gros bug pendant les vacances des enfants. Une de mes stratégies pour ce suivi, c'est de faire en sorte que la hitbox "solide" de la branche se déplace au fil de l'animation, un peu comme le faisait le petit ver jaune, premier personnage animé sur DS.

There is "animation/motion" coupling feature in my AnimEDS. It has been introduced so that feet stick to the ground ... But unfortunately, the animation of the branch wasn't drawn with that in mind. AnimEDS expect you to make your walking cycle with the "main body" of your character at fixed position, with hand and feet moving around. Then you'd show one feet and say "this one should be pinned to its position, and all the rest will move around. The bouncy branch was drawn in the other way round: the leaves part (that the hitbox should follow) is moving around and the wooden part (which should be pinned) is already sticking in its position.

Mais la branche, elle est réalisée dans AnimEDS dont les mouvements sont un peu différents. Rééditer chaque position de chaque étape d'animation, ce serait franchement pénible. Mon plan B, ce serait donc de m'inspirer de la plate-forme invisible qui empêche Sonic de tomber trop vite dans le pétrole de Oil Ocean, et générer un objet invisible qui fasse attendre Bilou pendant que la branche, qui ne serait plus solide, termine son animation.

I pushed it to the state where I actually have the animation triggering motion when playing, but it makes the whole branch detach from the tree and move down. Hopefully, I have a plan B : do something like the invisible platform hidden in the Oil Ocean of Sonic. There, it catches you and moves down slowly, allowing you to jump back. Here, it would do the move Bilou is supposed to do. It would be spawn when Bilou hits the branch, too.

edit: je ne voulais pas rester sur un "oah, ça va être trop dur", donc je l'ai fait. 20 minutes de bidouille dans AnimEDS à utiliser les petites croix pour réaligner le bas du feuillage à chaque image, retenir "3 vers le haut, un vers la droite" et appliquer le même décalage à la main à tous les éléments. C'est pénible, mais avec le DPAD, c'est possible de le faire de manière précise.

Ensuite, j'ai récupéré le .spr sur PC et un petit coup de débuggeur m'a permis de comprendre pourquoi using momentum(y to 1024 by 64) ne modifiait jamais la vitesse: j'avais écrit les valeurs pour le pseudo-pad dans le mauvais "registre" du gobscript ^^". Je corrige donc ça aussi et je me retrouve enfin avec une branche qui bouge quand on tombe dessus, synchronisant sa position (pour les collisions) et son animation. Sauf que c'est pathétique.

La dynamique de l'animation est complètement cassée: tantôt la vitesse que Bilou lui imprime est trop élevée et on passe des frames, tantôt les mouvements accumulés sont inutiles parce que l'animation fait demi-tour et on reste "gelé" sur la même étape jusqu'à ce que la vitesse négative soit devenue telle que la suite de l'animation va elle aussi être jouée à trop grande vitesse. Et ça, c'était avant que je ne vienne modifier certaines étapes pour forcer l'utilisation d'un délai cassant au passage la propriété 'position finale = position initiale" ce qui explique que la branche remonte petit à petit dans l'arbre au fil des cycles.