crocform #1

You may remember I had plans for a larger variety of platforms in the desert/pyramid zone of Bilou Dreamland. There's a second flavour of the crocodile-inspired platform that I barely shown so far, but which got a significant role to play in the work-in-progress level design. Unless you have some sandfall around, it is merely behaving as a "disappears after some time" platform. With sandfall, it adds "respawn" to the mix.

Last week end, I finally got to the point where I wrote some script to give it existence in the ongoing 3-room demo. There's a thing that went significantly wrong, though: Bilou couldn't notice when the platform is gone.

La pyramide, c'est l'endroit idéal pour des plate-formes un peu particulières. Qui croulent, par exemple. Ou qui changent d'orientation. Mais quand j'ai voulu faire un p'tit essai dans ma démo actuelle, Bilou est resté gentiment à attendre que la plate-forme revienne, flottant dans le vide. En réalité, il me manque un évènement capable de "décrocher" Bilou de la plate-forme: puisqu'elle existe toujours, pour le jeu, on peut toujours marcher dessus.

Il y aurait plusieurs moyen de régler: Bilou peut déjà se faire "propulser" par une collision (hic: seulement s'il n'est pas au sol). Les dumbladors empilés détectent quand l'un d'eux s'en va (hic: seulement grâce à un contrôleur dédié et l'ajouter ici décalerait tous les évènements de Bilou). Au final, c'est le contrôleur testant si on est sur une plateforme que j'étends pour qu'il puisse tester un bit d'état de l'objet auquel on est attaché..

I've had a similar issue with dumbladors when time came to 'stack' them: when one recovered, those stacked on top of it had somehow to detect they'd no longer have a platform behind them. It would be trivial if the gameobject implementing the platform was destroyed, but here it stays around.

• extend dumblador's extra gobbit(when 7.1) to Bilou
• trigger an extra "throws up" temporary hitbox when flapping down the platform
• implement it all with brand new "larger animated blocks" feature, not with a sprite, because that platform doesn't truly "move".

The temporary hitbox seemed to be the least-resistance path, so I gave it a go. But unfortunately, it led nowhere. Mostly because the already-implemented collision I was trying to reuse (that use to make Bilou bounce of erasers, for instance) is only tested in states where Bilou is airborne. Here, I'd need it in states where Bilou is supposed to be on the ground.

Yet, I hesitate going for an additional micro-controller gobbit (despite it already has C++ code) because that would introduce new events to deal with. I'd rather have the onpath controller be able to fire an event when the platform-object it is attached to signals it is no longer a platform, the same way the controller can signal the object no longer exists.

I could try having some automated test into 'onpath' that would ensure the current state of the 'platform' object still has the area active and using the proper flags, but that would require extra care if I don't want Bilou to behave weirdly when the platform turns back or does any state transition that don't actually imply losing its 'platform' behaviour.

reality check: using onpath(when w7.2); (from the worst-possibly-named commit)