Le fight club, version cflags

Last summer, I started reworking collisions in my game engine. The idea was to be able to define groups, so that e.g. collision-based communications between a stunned blador and its feet would never interfere with a bouncy branch and things it bounces away. Sure, there was way to do that already, by assigning them separate collision flags, but I've long ran out of these, forcing me to make weird groups and combinations.

Oui, parce que bon, ça fait maintenant un moment que j'ai ouvert la branche "new-cflags" dans laquelle on a la possibilité de définir des groupes de collision, et je m'en suis même servi pour gérer les portes, mais si je veux permettre à un appleman de rebondir contre les autres applemen tout en passant "à travers" les petits vers, je me retrouve devant un imbroglio avec la question épineuse "je le mets où, mon nouveau flag ? et est-ce que ça coince ?"

With recent work on the appleman, I wanted to make a distinction between "weapon-sensitive area, from a light object" and "weapon-sensitive area, from a heavy objects", but I wouldn't know how to encode it anymore. So far, the groups had only been used to implement the doors, but felt like it was time to define a new group, to deal with every collision that deals damage to entities in the game... which I finally decided to call the "fight" group.

Alors c'était l'occasion de se demander "et si en fait on faisait un groupe pour toutes ces actions qui retirent des points de vie à un des objets ?". Petit à petit, hein, en vérifiant qu'on ne casse rien (et donc, forcément avec une vidéo Screenshot Saturday où tout d'un coup, on passe à travers les branches au lieu de rebondir et à travers les pommes sans qu'elles ne se doutent de rien...)

Un nouveau G_FIGHT donc (j'ai un peu chipoté pour trouver le nom du groupe puis le Fight Club s'est rappelé à mon bon souvenir, tel une évidence inévitable). Peu à peu, les différents scripts-personnages sont convertis en nettoyant les vieilleries comme les scripts avec des valeurs numériques plutôt que des combinaisons de symboles. Puis arrive le moment crucial de réactiver la branche-qui-rebondit, et là, je me rends compte que garder dans G_FIGHT l'action principale F_STOMP, celle que Bilou utilise jouer à Super Mario assommant un goomba, ça ne va pas marcher. ça va imposer aux zones de collision destinées à être de simples plate-formes de faire partie du Fight Club alors qu'elles n'ont même pas de "points de vie". D'autant plus problématiques qu'on a aussi des flags du type F_PLATFORM pour, par exemple, empiler des taille-crayons sans qu'ils n'infligent de dommages.

It wasn't that straightforward ... I mostly broke everything first and then repaired things one after another. Last week, for instance, only the woodworm would still interact with Bilou. but now the code is cleaner and I think everything is repaired ... I may to a bit more time travelling to check the blador / tiled pencils interaction ... it looks like it isn't working as good as it did previously.

Then a few things just did not resume working, like jumping higher when you press the JUMP button while bouncing on a branch ... mostly because some hit areas needed to be duplicated and transition depending on them needed to be reassigned to the new area. Current GobScript doesn't make that easy to refactor. 

Ah, and yeah, below is a snippet of what the area collisions look like now.   

Heureusement, j'avais prévu de garder une portion des flags "neutres" (CFLAGS_LONE_FLAGS), valables qu'il y ait accord sur les groupes ou non. On pourra donc mettre la branche dans le groupe G_GROUND (qui n'existe pas encore) dont F_PLATFORM ferait partie et lui ajouter un "ah, oui, on prend F_STOMP aussi, même si ça ne fait pas vraiment partie du groupe". Certaines des zones de collisions ont dû être dédoublée (une avec G_FIGHT, l'autre sans), un petit défaut dans la réécriture quand ça arrive et on se retrouve avec des branches qui ne rebondissent plus aussi bien qu'avant ... un petit schéma, un peu de ddd et ça se remet en place. Le code pour tester deux zones de collisions ressemble donc maintenant à

 cflags GobArea::test(const GobArea *o, GameObject *g, cflags mask, GobCollision* gc) const {
     if (o==this) return 0;
     cflags group = mask & CFLAGS_GROUP_MASK;
-    if (group && (flags & CFLAGS_GROUP_MASK) != group) return 0;
+    if ((flags & CFLAGS_GROUP_MASK) != group) mask &= ~CFLAGS_IN_GROUP_FLAGS;
     if ((mask & flags & CFLAGS_EXPR_MASK)==0) return 0;
 
     // congratulations: you may compare coordinates, now.
     

edit: there was one last thing I had spotted that wouldn't work as expected: sticking dumbladors on pencil spikes. Especially, the dumblador might still wake up. So I dug the good old SchoolRush and checked what happened. Verdict: the dumblador *might* wake up there too, but it looks like it's much more unlikely to happen due to terrain geometry.

LEDS ... The forgotten branch

I completely forgot to tell you about that patch from early June that allowed to see clearly the space occupied by larger monsters in LEDS. And I forgot to pull it from "the cube" and to push it on sourceforge, too.

It did not work exactly how I hoped though, so there was still some manual tweaking to get those bouncy branches properly aligned with the tiled tree when I assembled the tree, and I even figured out why. But well, June was fairly crowded IRL.

I even missed to mention that when testing the new tree at my fairy's birthday, my brother almost immediately soft-locked Bilou by just trying to walk from a tiled branch to the sprite branch. It took me some time and a good deal of DDD to realise what was happening: the bouncy-block hidden within the branch would only progress in its state machine if something was falling on it but in this very case, Bilou isn't falling. So Bilou did the transition to the "soft-landing" state while the thing he's landing on ignored him altogether.

So I'm taking a moment this morning to try a patch I think was still required: seeing some random collision box will not help you craft your level. What you need to see is the bounding box of the object, the one that materialize its presence in the world.

...

edit: Ah. Yeah, of course. I'll have to push that new patch, else I'll start hunting for it again when I'll want it running on NDS for more map patching ^^"

Funghi vs. Appleman

Funky Funghi, un des plus anciens personnages de la Green Zone sur DS, vient de se ramasser une pomme. Jusqu'il y a peu, la pomme serait juste passée à travers, mais alors que ce blog va sur ses 20 ans d'existence, j'ai rajouté les quelques lignes de code script qui manquaient pour que l'interaction proposée début 2022 devienne une réalité: on va pouvoir dégager les champignons du chemin à coup de jets de pommes.

Throwing apples around is a bit more fun since they've started rolling when hitting the ground, but one thing has felt odd so far: seeing the appleman crossing the path of a bouncing Funghi without triggering any effect. Since early 2022, I had the idea that we could have Bilou *bouncing* when hitting the hat of Funghi rather than being hurt, and that implied of course that a thrown apple should bounce as well. It was now time to implement that.

Post by @PypeBros@mastodon.social

View on Mastodon

Ah, and yeah, I've played a good deal of the original Rayman, including throwing fist at bouncy plums and yin-yan balls to make them reach the place I wanted them to be. With all this new bounciness, Funghi is no longer just a hazard and you might actually want him to be *somewhere* rather than just wanting him away. Some of the initial ideas -- such as having the hat deflecting apples and only the foot being the target to hit if you want him moving -- quickly proved unpractical, and uselessly tricky to do, especially for a World-1 interaction.  

Bon, j'avoue que comparé aux "prunes rebondissantes" de Rayman, on est sur quelque-chose de nettement plus détendu: Funghi ne risque pas d'aller rebondir contre un mur et de revenir vous écrabouiller. Il ne reçoit que la moitié de la vitesse de la pomme et ralentit de moitié à chaque rebond. Juste ce qu'il faut pour passer d'une souche à "entre les deux souches" en une pomme. Mais ça devrait être marrant quand-même vu qu'il y a moyen de ramasser à nouveau la pomme et de la lancer une fois de plus. D'autant plus que maintenant, il va aussi être possible de rebondir sur le chapeau de Funky Funghi! (c'est peut-être encore un peu fort, d'ailleurs).

Post by @PypeBros@mastodon.social

View on Mastodon

La solution à laquelle je suis arrivé à coup de débuggeur d'expression est un rien intimidante ... entre autres parce qu'elle dérive de la collision destinée à faire rebondir Bilou, et que pour Bilou, je voulais que l'angle change selon qu'on arrivait plutôt sur le bord ou sur le centre de Funghi, comme s'il était vraiment un bumper de flipper. Pour ça, on va préparer deux valeurs et les combiner avec | dans le byte haut et le byte bas d'un entier 16-bit avant d'écrire le tout dans la 10e variable de Funghi avec :a. C'était rigolo avec l'appleman, mais ça devenait compliqué d'y ajouter le transfer d'énergie ... donc au final, pour l'appleman, Funghi agira toujours comme un mur qui absorbe 50% de sa vitesse horizontale et n'a aucun n'effet à la verticale. Et sur l'énergie absorbée, la vitesse acquise par Funghi est moitié moins importante que celle qu'avait l'appleman ce qui nous permet de calculer qu'un Funghi pèse à peu près 2 Applemen ;P

state0->state0 on found$apple [C_THROW we 0 >= w0 0 < & &]
                  (w0 2/ ~ $ff00 & w1 256 / $ff & | :a w0 4/ v0 + :0)
state0->state0 on found$apple [C_THROW we 0 < w0 0 > & &] 
                  (w0 2/ ~ $ff00 & w1 256 / $ff & | :a w0 4/ v0 + :0)

I ended up with something simple for Funghi/Apple interaction: half of the speed of the appleman (w0) is transferred to Funghi, and the other half is bounced back. But since Funghi is bigger, the half it takes only result in 1/4th of the speed. Not pushing him very far, I'm afraid. And well, that's only the part w0 4 / v0 + :0. All the things that happen before are reusing the "protocol" defined for throwing things where the thrower decides of the direction of the thrown object I already used for dumblador. The X speed and the Y speed will be set in the 10th register of funghi with :a and later used by the appleman with

$RTHROWN->$LTHROWN on hit0 [C_THROW wa 0 < &] (wa $ff00 & :0 wa 256 * :1)

Mais dans le code de l'appleman, j'ai quand-même gardé un code générique qui se contente d'appliquer le vecteur-vitesse qu'il trouve dans la 10eme variable de ce qu'il a heurté. ça pourra me permettre par la suite de faire en sorte que les branches rebondissantes puissent elles aussi renvoyer les applemen ^_^. Petite subtilité: la transition hit de l'appleman est testée avant la transition found de Funghi mais c'est found qui fournit le vecteur vitesse que hit va utiliser. c'est pour ça qu'il y a un test qui s'assure que wa < 0, pour que lors de la première frame de collision, l'appleman conserve sa trajectoire pendant que Funghi calcule l'impact. A la 2eme frame, wa est défini et la trajectoire de l'appleman pourra changer.

Et pour la collision Bilou/Funghi, c'est la distance entre le centre des hitbox (we) qui va déterminer l'angle de l'impulsion que Funghi va nous imposer, entre (-3,0), (-2,-1), (-1, -2), (0, -3) 

The idea inintially was to use the same behaviour as the one I coded for Bilou, where the angle you're bounced depends on the position you hit Funghi on. That's decided in Funghi's script with

state0->state0 on found$bilou [C_THROW we 0 >= &] (we 4/ 256* we 4/ 3 - $ff & | :a)

where we is one of the collision-specific parameter (rather than an internal variable of the collided object) containing the center-to-center distance between Bilou and Funghi, ranging from -24 to +24. At the very edge of Funghi, you'll get bounce horizontally by (+-3, 0), and at the center of his hat, you'll be bounced by (0, -3). In between, you could get (+-2, -1) near the edge and (+-1, -2) near the hat. And yup, it's got the overall expr_1 256* expr_2 $ff & | shape again to put both together in a single variable.

I still had to do something for how static Funghi looks when hit by something. My first attempt failed because transanims with characters that are made of a single sprite, and so far, Funghi was still like that. But behold, Funky Funghi 2.0, remade in AnimEDS after I separated hats and feet, so that I can animate it more freely, at in-between frames of some sort, etc.

It doubles the amount of memory it takes, but I think it's worth it. 

Il me restait un truc à régler: Funghi donne l'impression d'être en béton et que rien ne peut lui arriver même quand on rebondit dessus ou qu'on lui lance une pomme. J'aurais bien essayé de réutiliser l'animation "rebondit au sol" dans un sens ou dans l'autre, mais Funghi est toujours un "SimpleGob" premère génération, et je ne leur ai manifestement jamais ajouté le support des transanims.

Je profite donc de la p'tite canicule du week-end pour redécouper un peu Funghi dans le Sprite Editor, refaire ses animations dans AnimEDS et rajouter un "fait rebondir un truc qui arrive du haut" ainsi qu'un "fait rebondir un truc qui arrive sur le côté". Ce n'est pas spectaculaire, mais ça donne plutôt bien quand-même.

Make it exist first,

You can make it good later. It's an ongoing meme in the gamedev community, and it's perfectly capturing what I intend to do with the "Green Zone" levels.  The map is very crude, most of the areas use repetitive patterns of the same block, it feels dull to "play" and I don't even have graphics for the key or the closed door ... but at least, I can check whether we can reach branches, cliffs, leap over holes and the like.

Il y a un meme qui est occupé à faire le tour des groupes "gamedev": un trait qui reboucle plus ou moins sur lui-même entourant un pâté de couleur accompagné de la légende "commence par faire en sorte que ça existe". En vis-à-vis, l'image d'un cercle aussi propre sur lui que s'il sortait d'inkscape ... avec la légende "tu pourras l'améliorer plus tard". Et c'est vrai que c'est assez pertinent: combien de projets ont tourné à rien parce que leur dévelopeur à cherché à atteindre l'inaccessible étoile trop tôt ? En plus ça colle assez bien avec le planning que je me suis fixé pour l'été: faire une version minimaliste de chacun des niveaux qui hantent le cahier-bleu-du-redesign pour voir si Bilou sait atteindre les différents objectifs ou si je dois envisager des mécanisme "d'aide à la conduite" du genre de ceux utilisés dans MainFrames. Et tant mieux si le niveau me sert aussi de bac à sable pour valider le fonctionnement des portes.

Files are being swapped back and forth between the computers and the DS, as I bring together the fixed bouncing branches, geysers and updated applemen. Unfortunately, the level editor is currently unable to show us invisible gobs (workaround: done), and with doors and branches, I start to have a higher number of them ... It also has restrictions on how to link items that I'll like to get rid of later on.

There's something though, that I don't really like about the current state. It's crude. There's no beauty in the way it looks. There's not much fun in the way it plays. Monsters feel placed randomly on uninteresting surfaces. The forever-in-progress "level two" -- with its geyser and huge trees -- makes me feel prouder than this.

Je transfère donc un script dans un sens, un spriteset dans l'autre, je passe du temps dans l'éditeur de niveau pour que ce "Green Zone 1: L'Arbre Creux prenne forme... Forme, mais pas vie. J'avoue que c'est un peu décevant cette austérité, cette absence d'objectif et de gameplay... et je me suis surpris à apprécier de retomber sur le niveau-en-chantier ou la salle de test qui me paraissent tellement plus accueillants bien que totalement inachevés.

On y est !

Enfin ! Un peu de bidouille, un sprite qui doit encore être invisibilisé, mais j'ai enfin les physique voulue pour cette branche rebondissante! Dites-moi ce que vous en pensez, mais moi, je suis plus que satisfait par son mouvement ^_^

Euh ... non, je n'ai pas grand-chose de plus à en dire, en fait... mais bon, ça traine depuis tellement longtemps que je voulais marquer le coup avec un p'tit post qui reprenne l'image. 

Je ne suis pas sûr que ça mérite de ré-uploader un .nds ... je vais plutôt me faire un jus et me mettre au lit. Ciao tutti ;)

Finally ... Finally, I've got my bouncing branch working with the intended "furblock" physics. Almost everything else is said in the previous post, and you also have a download link there to try the physics on the original furblock ... But this has taken so long, I wanted it to have its own post.

edit: there was a little issue left: if you watch the animation closely, you'll note that the branch makes an extra wobble one time, and no such thing on the next time. It wasn't intended at first, but it felt nice when happening, so I made an extra "smaller wobble" animation to use as a transanim in the "throw->idle" transition. But it still had that odd/even behaviour, doing it only every other time. It turned out that when Bilou lands on the branch during a transanim, it did not reset the transanim flag. This is a desirable feature when making transition animations for Bilou mid-air, but not here. there's an extra anim2.force script line I can add to say "this animation (big wobble) may interrupt any ongoing transanim", but its implementation was apparently broken. Should be fixed now.

edit+: OMG. I just stumbled upon the original bouncyBranch.xcf discussed in the first post... timestamp is 24-08-2020 ^^"

Un furblock qui a du ressort

ah. Voilà qui est mieux... Le saut est amorti, puis le bloc re-propulse Bilou en l'air une fois dans la phase à gravité positive. J'ai encore un glitch temporaire à régler, mais au moins Bilou ne se met plus à rebondir dans le vide une fois sur deux. Alors je suis sûr que vous avez d'essayer ça, donc.

And give it a try yourself. I finally have a bouncy block that is bouncy the way I want, dampening your fall, kicking you up when it is back.

Not only that, it also allows buffering of your JUMP commands so that you get a high-jump if you press and hold the JUMP button anytime while the furblock is dampening. JLN managed to get a high jump on any of his attemps. (of course, he is disappointed that it isn't possible to use the glitch to charge even more jump power and make a super-jump taking you out of the map into a super-secret area :P)

Et si on appuie sur le bouton de saut au bon moment (c'est à dire n'importe quand pendant qu'on est sur le bloc), on part en super-saut. Hahaa... On est prêt pour ramener ça sur la branche aussi...

$BACK->$IDLE on event2 [v1 256 <] ($VTHROWN(0) 0 :1 0:6); // 1 
$BACK->$IDLE on event2 [v6 0 <=] ($VTHROWN(0) 0 :1);      // 2
$BUMP->$BACKLAST on event2 [v6 1 =] (v1 2 / :1 v6 1 - :6 $DIR(D_DOWN));
$BUMP->$BACK_ on event2 (v1 2 / :1 v6 1 - :6 $DIR(D_DOWN));  // 4

$BACK->$BUMP on event2 (v1 2 / :1 $DIR(D_UP) $VTHROWN(VTHROWN 3 * 2 /);

$IDLE->$BUMP on hit0 [w1 0 >] ($VTHROWN(200) w1 512 m :1 $DIR(D_UP) 3:6);
$BACKLAST->$BACK_ on hit0 [w1 0 >] ($VTHROWN(200) w1 512 m 2 * :1 3:6);

The little glitch we still observe is linked to the BACKLAST state. Normal cycle alternates between BUMP where Bilou can stay landing on the block (think as "compressed" state) and BACK where Bilou would be ejected ("expanded" state). There may be up to 4 such oscillations before the block comes to a halt. A former glitch happened when Bilou would fall back while we're in BACK state and react as if it hit an eraser although it isn't close enough.

BACKLAST was intended to fix this: it let the block oscillate one last time, but it doesn't feature the hitbox that would propel Bilou up. Of course, that does not work alone, so I also added a transition that restart a cycle if Bilou still shows up, exactly as if we were idle. But we cannot simply do BACKLAST->BUMP, else we will screw up how the "on grid" controller decide where we should transition.

My last glitch came from the speed division on line #3, that makes each oscillation smaller than the previous one: if we keep the last line's expression identical to that of $IDLE->BUMP, the speed will almost immediately be very low, and we might not hit and propel as intended, hence the additional 2 * to compensate the division that is about to occur as soon as we've reached the "default" position of the block. (still, I'll have to cross-check the collision coordinates: it doesn't feel right that it need that much fine-tuning...)

update: okay, works for the branch as well. Just took 1 or 2 hour of tuning...

furblock de montée

La dernière tentative d'améliorer la branche s'est plus ou moins soldée par un échec constructif. Puisque le week-end de montée m'offre un peu de répit, je vais partir sur une idée qui m'est venue en passant en revue les autres jeux avec des éléments de gameplay similaire: commencer par me faire un "bloc-note" à la SMB3, qui se concentre sur le mécanisme, pas sur l'animation. Et une fois que le mécanisme sera validé, je fait la même chose avec un objet invisible.

So trying to combine physical motion and animation for the bouncy branch proved to be a bad idea. Rolling back. I'll keep my satisfying animation and combine it with an invisible block behaving like the "note block" of Super Mario Bros 3 instead. And I'll prepare that with non-invisible block in an easier-to-test environment, that is the pyramid room.

• premier fix: je dois retirer les zik.import de mon script pyrat.cmd: ces commandes sont propres à la "trhee rooms demo" qui pré-charge un module de base (bilou.xm) et runMe ne connaît pas (encore) l'équivalent, même après recompilation du dernier modèle
• deuxième fix: runMe a besoin d'un "../spriteB.spr" explicite pour aller chercher le nouveau fichier (et pas un vieux fichier de SchoolRush dans efs:/moving/spriteB.spr ^^")
• 3eme fix: ma petite anim' faite à la main doit utiliser la SpritePage 8+2 (parce que le fichier bilou.spr préchargé contient 8 pages)

Bon on y est. J'ai un "furblock" dans le niveau-test de la pyramide. Je saute dessus et il s'enfonce bien puis ... il décole vers l'infini et au-delà (ç.à.d  -2147483648). Ah oui, et il n'a encore un tête de fury que sur DS, pas sur l'émulateur. 

J'ai utilisé pour le réaliser un nouveau contrôleur "grille" qui indique si on est repassé au "bloc" suivant, histoire de passer d'un état "repoussé vers le haut" à un état "repoussé vers le bas", et que le bloc finisse par se stabiliser à sa position d'origine. Mais manifestement, ça ne marche pas encore.

There have been a few "setup" issues, leading to a few TODO items to be processed later (this season?) in my notebook, like runMe not supporting the multi-music commands and the lack of "translate to that sprite page" macro for multi-spriteset that leads to annoying magic numbers. But I have to admit that even with that done, the behaviour was fairly surprising. Well, on the DS, the "furblock" did a downwards bump and then skyrocketed to negative numbers: I needed something to fire an event when the original position has been reached. And that thing could be the "grid" controller that was part of my "how to code bosses" arsenal.

But even with that, the resulting behaviour is emerging and perplexing. I guess I haven't found the proper set of rules yet.

Et nous voilà le week-end d'après encore plus au calme, ce qui m'a permis de décortiquer avec InspectorWidget le comportement émergeant (mauve) et de trouver les corrections (bleues) nécessaires pour que ça marche pour de vrai ;)

Special thanks fly to Wye for his SMW-remake-howto video and how it reminded me that the Springy note block exists in first place, and how they were perfect match for the feature I was looking after. ^_^

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.

Houba!

Le Marsupilami en jeu vidéo!

Okay, since you don't speak French, I guess I need to introduce the Marsupilami first. It's a fictional animal starring in some of the most popular Belgian comics of the 70s-90s. It is mostly yellow with a very long tail (about 8m for an adult) and the comics show him doing all sort of tricks with it, like lasso foes, punch nasty guys, use it as a spring to bounce higher ... I guess you've got the idea. There are 2 main marsupilamis character, one who has been brought back with heroes and act as a super-smart pet, and a wild one, who staid in the jungle in a fictional South-American country. Both like to play jokes (but aren't complete clowns), both are strong and smart and protect their loved ones. 

Distribué par Microïds, ceux qui avaient publié Nicky Boom (et plein d'autres titres auxquels je n'ai pas joué). Moi, je suis grand fan (exigeant, mais fan quand-même) du Marsu de Franquin et j'ai donc craqué pour ce titre qui pourrait presqu'être catégorisé "Donkey Kong Country Honoris Causa" tant il en reprend les codes: jusqu'aux "tonneaux-propulseurs-volants" (ici incarnés par des toucans), aux fruits piquants géants, les cavernes-défi-cachées et le dash-roulade-qui-permet-donne-un-double-saut. 

Since the 90s, there have been cartoons and video games about the Marsupilami, but usually they made a fool out of him and couldn't capture the essence of the comic character. And since I'm a huge fan of the original design and character, it was a showstopper. But hey! some French publisher added a Marsupilami title from some French studio to the Nintendo Switch store and from the teaser videos, it seems to play like a Donkey Kong Tropical Freeze DLC level. So I've lets-go-purchased it to see what it looked like.

Bref, au niveau gameplay, c'est validé. Pas aussi original que le travail de Apache Software sur Mega-Drive, mais ce n'est pas forcément une mauvaise chose: manette en main, le jeu de 1995 était grandement confus, comme si on avait voulu transposer un Sokoban en jeu de plate-forme en empruntant les morceaux manquants dans Lemmings. Pas top.

Côté esthétique, c'est du grand art! Le must de ce qu'on peut attendre d'un jeu de plate-formes 2D à l'heure actuelle. On a le choix entre trois personnages mais ils se jouent tous de la même façon. Aucun ne ressemble vraiment au Marsu phare de Franquin ni même aux bébés-marsu du tome "Le pollen du Monte Urticando". Il m'a fallu un moment pour m'y faire, mais je crois que le truc, c'est que qu'on joue avec les bébés devenus marsu-ado. Comme Franquin n'en a jamais dessinés (afaik), ça donnait la liberté aux artistes d'Ocellus Studio pour avoir un graphisme moderne, un niveau de détail adapté à la technologie utilisée et une personnalité qui convient à la narration. Bingo.

On a visual standpoint, it is a success. The environments are well-defined, characters are well-animated and their are quite matching the original creation although not looking exactly like the beloved comics. And the developers used a clever trick to get some distance with the comic: you're not playing any of the iconic grown-up marsus, nor any of the cute marsu babies starred in the 4th book. Well, actually, you're playing any of them three, but they're no babies anymore ... yet they aren't grown up yet.  They're at the marsupilami equivalent of "Son, you're getting close to be a man now" age where farmboys usually see their origin and destiny revealed and set up on a quest to save the world.

On a gameplay standpoint, this is close to DKC:TF the same way Shovel Knight is close to Megaman. The core mechanics are identical, there are a few twists here and there to make it feel fresh, although you wouldn't call it "a novel experience". And considering how the previous game from '95 failed at being fun or even entertaining by being so obscure, it is rather a good thing.

Premier élément sur lequel j'aimerais m'attarder: les "champignons" rebondissants, puisque je suis moi-même occupé à faire rebondir une branche. Restez par-dessus ces "champis", et vous rebondissez automatiquement, encore et encore, à la hauteur d'un saut ordinaire (qui n'est pas bien grande pour un marsu, celà dit). Si votre bouton de saut est enfoncé au moment du contact, vous partez pour un maxi-rebond. Le timing n'a pas d'importance. Maintenez le bouton enfoncé pendant 2 minutes et vous ferez des maxi-rebonds pendant 2 minutes.

C'est simple, c'est direct, c'est prévisible. C'est exactement ce qu'il me faut pour un niveau 1. Et c'est un des choix qui font que ce Marsu est plutôt bien adapté aux plus novices qui n'auraient pas réussi à aller plus loin que le monde 2 de Tropical Freeze (je ne parle même pas de Returns). Pas que le jeu soit enfantin (toutes les recettes de Rayman Origins pour adapter la difficulté au joueur sont reprises) mais il ne cherche pas à faire dans la Grande Quête. 3 mondes + 1 monde caché, et voilà.

From a game design perspective, there are two items I want to keep track of. The first is how easy and intuitive the bouncing elements are in the game (compared to that tricky-to-use bouncing branch in my own demo). Just stay on the thing and you'll make small bounces (about the height of a regular jump). Have the jump button held down and you'll make huge bounces. That simple. No need to press it again everytime you touch the bouncy thing (mushrooms ?). No need to time your button presses against the position of your character on the screen. Just. Hold. It. Down.

Autre élément de gameplay qui mérite qu'on s'y arrête, ce sont les anneaux-pour-s'accrocher. Aucune tentative pour habiller l'objet ici: ils sont à peu près aussi discrets que des blocs-question dans le royaume champignon. Ils s'éclairent en vert quand votre marsu est à la bonne distance et une simple pression sur le bouton d'attaque nous y accroche alors quasi-instantanément. On est ensuite tiré jusqu'à l'anneau ou on restera accroché, statiquement jusqu'à l'appui sur le bouton de saut.

Une séparation des rôles (Y=accrocher, B=quitter-et-sauter) qui est vraiment la bienvenue et qui évite les fausses manoeuvres même quand on s'embrouille dans ses boutons: appuyer sur Y à nouveau quand on est déjà accroché n'a ici aucun effet.

The game also provides an interesting answer to "how to HOOK to things". Here, hooks are plainly identifiable as such ... almost as artificial as Super Mario Bros question blocks. It gets a green glow if you're in range to trigger the HOOK mechanics. If you press the attack button, it will almost immediately (less than 50ms) reach for the hook with its tail and will then start zooming towards it along the straight line drawn by the tail. You won't leave the hook by pressing the attack button again: you'll have to use the JUMP button for that. A nice protection against accidentally leaving the hook when there's no ground to catch you.

Should there be multiple hooks in the range, the direction you indicate with the left stick will select which hook is targeted. Only that hook gets the green glow. That works most of the time, but may trap you in some of the latest levels where the hook you're leaving is falling down or about to move into spikes. Because yeah, those flying hooks will come into a good number of variations that I'll have to study later and the same mechanics are also used for the shooting birds that replace DKC barrels.

Dernière petite touche sympa: appuyer sur le bouton d'attaque pendant qu'on marche va déclencher une attaque-roulade (comme dans Donkey) alors que l'utiliser quand on est à l'arrêt déclenche un "coup de poing" avec la queue du marsu terminée par un gros noeud (sa signature dans la BD). pas de risque donc de se mettre à partir en avant avec un dash involontaire, résultat trop fréquent dans la série DKC. Ultime subtilité, mitrailler le bouton d'attaque pendant qu'on marche permet de rester dans un dash infini, qui pourrait se finir mal quand on arrive au bout d'une longue plate-forme avant un passage où il faudra plutôt s'accrocher. Et la subtilité la voilà: dans cette situation, les concepteurs ont presque systématiquement placé une ou deux caisses en bout de course. Le marsu ne peut pas rouler à travers les caisses: il se retrouve stoppé net. Et si le joueur continue son mitraillage malgré tout, marsu -- maintenant à l'arrêt -- donne un bon coup de queue dans les caisses, récupérant leur contenu, mais reste immobile malgré tout.

Final gameplay sweetness: in many places, you're invited to make a long roll by mashing the attack button. since the roll is actually a dash, you might end up doing one press too much and end up past the edge of the current platform. Hopefully, the level designers thought it wouldn't feel fair and typically end such platforms with a crate. The crate might just contain one fruit but most of all the crate cannot be rolled through. And if you happen to hit the attack button again while stopped by the crate, you'll trigger the Marsu's signature move: punch with a tail-knot, crashing the crate and opening the way.

SMBW: Retournement

Une des premières mécaniques que j'ai vraiment appréciées dans Mario Wonder, ce sont les roulhippos. Je les range dans la même catégorie que les wallcreepers de Link Between Worlds ou le liquide rebondissant de Sonic Mania: on prend un élément de gameplay qui a bien cassé les pieds des joueurs sur les 30 dernières années et on lui donne enfin la possibilité de prendre sa revanche.

Et ici avec ces hippos mauves qui n'auraient pas dénoté dans Super Mario Land 2, c'est carrément sur les trous-sans-fond que Mario prend sa revanche ... c'est à dire sur son ennemi n° 1: la gravitation. Et pas qu'un peu puisque les trous ainsi bouchés se transforment en tremplins particulièrement puissants.

First wonderful mechanics in the game is the rolling hippos, and how they transform something truly annoying (bottomless pit) into something fun to interact with (a bouncy area). This is the same kind of flip-the-challenge move that was happened with the blue liquid of Sonic Mania, but it's of course something Nintendo people themselves are familiar with since this reminds the wallcreeper remastering of Link Between Worlds. Many further "wonders" of the game will also act as flippers, like allowing to walk on the background or ride / swim lava.

Monde 1 oblige, envoyer promener un hippo est plutôt simple: il suffit de lui sauter dessus. Notez au passage que s'ils peuvent se montrer piégeux (cogner un hippo renvoie Mario assez fort en arrière), ils ne sont pas blessant, chose plutôt rare au royaume champignon fleurs.

Mais les Roulhippos ne sont pas le seul moment où ce Mario Wonder renverse les règles, et les "prodiges" seront une occasion pour fournir ce genre de plaisir au joueur, comme ici où Yoshi se retrouve non seulement immunisé contre le feu mais aussi capable de nager dans la lave et d'utiliser les coulées plus denses comme des plateformes mobiles...
 

tuning de branche ...

Ben ça aura été une semaine de gros débugging pour ... pas grand-chose au final. Enfin, la bonne nouvelle c'est que la branche rebondissante a bien évolué. On avait quelque-chose de peu logique le mois dernier, là, j'ai repris le contrôle.

Le premier truc, c'était de re-définir le timing des interactions entre la branche et Bilou: quand on tombe dessus, la branche s'abaisse d'abord, puis nous envoie vers le haut. Evidemment, c'est seulement pendant la phase "remontante" de l'animation de la branche qu'on a envie qu'elle puisse propulser Bilou.

Il y a déjà (et depuis longtemps) ce qu'il faut pour ça dans AnimEDS, mais j'avoue qu'au moment de créer l'animation, j'avais un peu oublié comment ça marchait. En fait, au moment où on active le mode 'box', la ligne du temps en bas l'écran permet d'indiquer dans quelles frames la boîte est active.

A week spent in debugging because I had forgotten how my tools define over what part of the animation a collision box is active. I had also forgotten that the same keyword 'area' describes the sensitive-and-passive role of a collision for 'sprites' and the offensive-and-active role for special blocks.

Well, at least, it's almost clean now. I should be able to build a new demo version next week-end. But first, I will have to make a check list of the things that are still a bit weird in the current state.

Mais quand j'ai voulu faire les essais avec cette nouvelle animation, plus rien ne marchait. Enfin, la branche détectait l'arrivée de Bilou, provoquait un rebond et activait son animation, mais impossible de se faire projeter en l'air.

Tout ça parce que j'ai mélangé deux mots-clés dans la définition des blocs interactifs (dont la gomme-qui-rebondit qui a servi de modèle à la branche): dans les définitions de machines d'état, area introduit une zone sensible (et passive) pour les collisions alors que test introduit une zone offensive (et active). Pour les blocs spéciaux, il y a un seul mot-clé -- area -- mais il définit une zone offensive. Je l'avais oublié. Du coup, j'ai passé les soirées en mode 'guru meditation' ... pour rien.

Je ferais bien une nouvelle démo pour fêter ça, mais il y a deux ou trois trucs louches aux entournures ... je vais repasser par la case "faire une todo list", donc.

I did some playtesting with J.L.N and *deline ... They mostly wouldn't fall off the branch (I made sure that one wouldn't happen too often), but it wasn't obvious to them how to make big jumps. The thing is you don't need to press JUMP when stomping the branch, but *when it throws you back*. Maybe I should trigger a 'super-throw-back' if player hit JUMP when stomping ? so you don't have to bother too much about bumper timings in level 1 ?

ça boume, vieille branche ?

Bonne nouvelle: j'ai enfin ma branche rebondissante. Je suis plutôt satisfait du résultat. A un détail près: les couleurs. Je pensais au début que j'avais pêché la mauvaise palette parmi celles de green.spr, mais j'ai du me rendre à l'évidence: ma petite animation utilise les couleurs de l'autre fichier. Je n'ai encore utilisé que des sprites "tout simples" en dehors de l'école, et j'ai forcé leurs palettes directement dans le script qui définit leur comportement. Pas moyen de faire ça avec les animations binaires de MEDS. Et si je désactive cette astuce, j'ai aussi des couleurs bizarres pour tous les monstres précédents.

Yeah. I've got one first objective met: I have branch-that-bump bumping. Just one last thing to be fixed: it doesn't use the proper palette. I thought I was merely missing some adjustment number in my script, but I had to admit the bare truth: the only reason why school zone had proper palettes for monsters is that Bilou's palettes were split from the School Rush file. It took a few tries to get palette patching working right, but it ended up easier to do than I had foreseen.

ça paraissait improbable, cela dit: après tout les animations du niveau 'school zone' s'affiche correctement. Il doit forcément y avoir une ruse de chargement que je n'ai pas encore prise en compte. Bin non. bilou.spr et school.spr partagent la même palette, c'est tout. C'est aussi bête et sot que ça.

Modifier les palettes au chargement dans l'animation n'est pas trop difficile, heureusement.

Flexible!

I remember how adding bounciness to the erasers bumpers felt and how I immediately wanted to have some erasers all over the games to be bouncing as much as I could. So wouldn't it be a shame if the branches of the Green Zone were all static platforms while they could be slightly bouncing you higher instead?

Les gommes qui rebondissent, c'était bien gai. Surtout quand elles se sont mises à bouger en réagissant à notre présence, au point que j'avais envie d'en rajouter partout dans le jeu. Du coup, en repassant sur le level design de la green zone, je me suis dit que ce serait dommage que les branches des arbres restent raides comme des piquets alors qu'elles aussi pourraient nous propulser dans les hauteurs. Oh je ne parle pas d'un bumper à la Sonic, mais si ça pouvait nous faire monter déjà de 1.5 blocs de plus que le saut standard (3.5 blocs), ce serait chouettos.

 Note that I don't meant to change them into Sonic-like bumpers. I said "slightly higher", like your jump would be 5 blocks high rather than 3.5, but still high enough to make the trip fun, and the top of the trees higher to reach without cluttering the screen with leaves.

I don't know yet whether I can do that with animated tiles alone or whether I need to switch to sprites while animating, and then back to tiles à la Super Mario brick blocks.

And before I'll dig deeper into such technical thoughts, I wanted to check what it'd look like. Apparently, just lifting tiles up and down by 1 pixels would produce a decent effect. That was quite some month ago. (you can't notice it, but there are two frames (one full-low and one full-high) merged into that picture).

Après un petit essai en torturant une ancienne capture d'écran, la première question sur laquelle je me penche c'est "tiles ou sprites". En clair, la branche va-t'elle se comporter comme un 'monstre' fort peu mobile ou une pente un peu bizarre. Avec un effet correct rien qu'en décalant d'un pixel de plus à chaque prochain tile, que je n'ai malheureusement pas 'filmé'.

Depuis, j'ai eu l'occasion de faire un test avec AnimEDS -- beaucoup moins concluant -- et de recompter le nombre de fois qu'une telle "branche" est présente dans les différents niveaux déjà réalisés pour la Green Zone. A savoir un maximum de 4. A ce stade-là, je peux franchement tolérer une approche "100% sprites". Même pas besoin de passer d'une image "décor" à une image "sprites" à la demande comme pour les bloc-question de Super Mario quand on les bouscule. En tous cas, pour Bilou's Dreamland, je vais prendre le risque de supposer que je n'ai pas besoin de faire des optimisations là-dessus.

Last week, I did some more tests with AnimEDS but I couldn't come with a convincing animation for the branch (modeled as some set of green balls). Also, I counted how many such 'branches' I have in existing Green Zone levels, and there is at most 4 of them per level. So there is no real pressure to do this 'made of tiles' rather than 'made of sprites', so the upcoming Bilou's Dreamland game will be a test of whether doing such level elements with sprites is a working strategy.

Et du coup, si c'est du "tout Sprite", pourquoi ne pas se faire plaisir et coder quelque-chose à base d'une animation d'un 'squelette' qui indiquerait où placer les sprites plutôt que d'animer à la main ? Avec un angle égal entre chaque segment, on a un rendu assez fidèle de 'branche qui plie'. En variant la valeur de l'angle, on peut redresser la branche, etc. tout ça fait des schémas assez sympa à dessiner...

I think I'd also check whether such things can be animated based on a coded skeletton rather than with pre-built pixels. Or at least I could be tempted to do that, but it could turn out to be a bad move, despite it having some definitive appeal. Dedicated pixels could provide better motion that code-driven shifts of still pictures.

I mean, look at those neat diagrams where adding a constant alpha angle at each segment produces a nicely curved branch, and how applying a weight at the middle of the branch only curves one half, and let the other half unchanged. And how having a maximum-alpha threshold will affect how easily the branch bends with weight.

But ultimately, the object isn't that big. It might turn out that weight-at-the-edge only differs from weight-in-the-midle by a few pixels. And similarly, a 'big bounce' and a 'small bounce' might differ only by not using extreme frames.

Mais ce n'est pas forcément l'approche qui donnera l'animation la plus sympa. En particulier compte tenu du fait que la branche à animer n'est pas bien longue.

Cogitons un peu. Si je donne une pente d'1 pixel de dénivelé au bout de 8 pixels en avant pour le premier segment, le 2eme segment, devrait avoir un dénivelé de 2:8, puis on sera à 3:8, et ainsi de suite. Avec cette valeur de alpha, une branche de 6 segments de 8 pixels peut déjà s'approcher d'une pente à 45°.

Mais surtout, ça me donne une manière facile de tracer ce genre de courbe dans SEDS et de tester des animations de baguettes diverses (raides comme une latte ou souples comme une branche de sapin) à partir de 4 valeurs de courbure et une inclinaison maximum à 4:8 (valeur à partir de laquelle il faudra 'raccourcir' le traît de 10% pour tenir compte de sa diagonale).

School Rush update

At last, here comes an update on School Rush. Still featuring the 4 levels from last year, but with improved gameplay (especially through slightly increased gravity), improved game feel and a starting level that is more fair. I dub it "splashed" release because most of these changes were suggested by the author of Splashers ;-)

Voici enfin une mise à jour pour School Rush. Toujours les même 4 niveaux que la fois dernière, mais avec un gameplay amélioré, plus de petites animations sur les objets interactifs (gommes et bonus) et un premier niveau plus accessible même en mode normal. Et vu que la grande majorité de tout ça m'a été recommandé par l'auteur de Splashers, je baptise cette release "splashed" ^_^

(gameplay and story migrated to latest release

How to play

Get the NDS image and play it on your homebrew-ready console or in an emulator, such as DeSmuME. See this page if you need extra explanation/instructions for running homebrews.

MapAnim : done

Once again, properly mapping the codebase before starting to program got a loong-delayed-feature added to the engine within an afternoon. The code was actually written bottom up, starting with the revision of the "clearblock" function up to the script parsing code. 

I love so much the new little bounces and stars, I couldn't play the game without them anymore :P

Et donc les voilà, ces petites étoiles qui accompagnent la disparition des bonus et cette gomme rebondissante que l'on me recommandait. Je vais bien vite me refaire une version de School Rush qui intègre tout ça, parce qu'on y prend terriblement vite goût ^_^

Le nouveau système me permet aussi d'affiner un peu le comportement de la gomme rebondissante: elle ne projette plus Bilou immédiatement en l'air: au départ, elle n'est qu'un détecteur et devient un rebondisseur uniquement avec la première étape d'animation. Du coup, ça permet au joueur de mieux ajuster ses mouvement avec ce qui se passe dans le jeu (enfin, je trouve). 

QuickLinks: implementation notes and early specification sketches. 

A block too far.

Dix blocs à franchir ... Ce second obstacle continue à rebuter, mais ça devient plus facile à gérer. Dans la version g88, il était indispensable d'arriver avec la bonne vitesse sur une petite gomme. Sauter trop tard (en courant), c'était l'échec assuré. Ne pas courir, c'était arriver à coup sûr trop court.

I guess many have cursed that row of pencils in the g88 "anniversary" level. One thing I wanted to fix is that not only it required a master-level of the RUN and JUMP mechanics, but it did not provided a way for the player to build that mastery. Jump too late, and you'll end in spikes. Fail to run, and you'll realise quite late that you don't have the speed to clear the jump.
I experimented two approaches that make the obstacle easier to clear: the first one is widening the bouncing zone, which in turn reduces the stress on the timing. The second was to move the bumper away from the pit, so that missed attempts can be cancelled by the player.

Pour rendre ce saut plus facile à apprivoiser sans en tuer la difficulté, et maintenant que Bilou peut courir de façon fiable, il y a 2 choses sur lesquelles je peux jouer. D'abord, la largeur de la zone-bumper: un bumper plus large donne plus de souplesse au joueur sur le moment où il va sauter. Ensuite, un "filet de sécurité" entre le bumper et le début des crayons. De cette façon, le joueur qui a mal jugé de la distance de son saut garde une possibilité de revenir en arrière.

These two adjustments to the level make it more learning-friendly, but most of the challenge remain. Either you manage to RUN-JUMP as desired, or you find the alternate, safier route. For the next release, I'd like to grant player with the ability to feel empowered and have a laugh at the challenge, by power-ups, of course. You could either start the level with 5 hitpoints or pick one (random?) power-up before you enter it. That could be done through some form of DASH mechanic, or possibly a way to break more easily through that chalk-barrier, etc. Of course, I wouldn't have a "fix-them-all" item: if you get the ability to undermine _some_ challenges, you'll have to rely solely on your skills on others.


Enfin, avec l'augmentation de la vitesse que Bilou peut atteindre en courant, il est possible de passer par-dessus les pointes des crayons simplement en courant et en sautant, y compris en prenant "par le haut". Celà n'empèche que pour une prochaine release, il serait intéressant de proposer des "power-up" au joueur qui lui donnerait la liberté de bouder l'obstacle, même sans le contourner par le haut.

Entretemps, j'ai pris le contrôle de la course de Bilou, de sorte que je gère la vitesse maximale qu'il peut atteindre (suffisante pour franchir les 10 blocs de justesse sans l'aide de la gomme) et qu'on peut se mettre à courir en faisant un double-dash dans une direction (à la Kirby) ou en donnant une impulsion vers le bas pendant qu'on marche ou donnant un coup de R.

Deep Ink Pit gameplay

 Nous voici à la frontière entre le "monster design" et la conception du gameplay. L'aspect et l'idée de base pour spongebop sont définis, mais il reste à préciser comment le joueur va interagir avec ce "monstre".

I recovered and digitized some sketches that describe the intended gameplay for Deep Ink Pit. I make the distinction against "monster design" as we start here thinking in terms of user input, skills required and goal to achieve.
The core idea is to bounce from one Spongebop to the next to climb up as high as possible. That leaves us 3 things to define: what happens by default when Bilou and a Spongebop collide, how can he climb up higher and is what are the contrary motions.

 Sans action de la part du joueur, Bilou rebondit sur les éponges, mais toujours des petits bonds. Pour s'élever plus haut (et donc progresser dans le jeu), il faudra ré-appuyer sur le bouton de saut au moment du contact. Chaque rebond augmente la portée du saut suivant, que l'on reste sur la même éponge ou que l'on enchaîne les éponges.

If the player stays idle, Bilou will bounce again and again on the sponge's "head". To gain jump height, it is necessary to press the JUMP button timely when you hit the sponge. By chaining timed jumps, the height for the next jump keeps increasing.


Au départ, j'avais prévu qu'un trop grand nombre de saut sur une même éponge casse son élastique, mais en fait, cela n'apporterait rien au gameplay puisqu'on a déjà l'encre qui monte dans le rôle de la "motivation pour avancer".

Spongebop's thread may break. I originally thought it would break "after n bounces", but that doesn't really convince me. I'd rather have the thread breaking if Bilou comes with an "excessive" down speed".

Je garde donc ces fils cassables mais uniquement si la vitesse de Bilou est trop grande lorsqu'il heurte l'éponge.

That fundamentally means that there won't be anything like "walking on a spongebop", despite its appaerance in "platforms" posts. Still, for "the adventure", I know that players will need help, as staying aligned with a swinging sponge proved feasible, but demanding. Imho, the proper approach would be to allow Bilou to GRAB the sponge by pressing the 'PUNCH/THROW' button timely (on contact) and holding it. That means Bilou wouldn't be capable of grabbing sponges when carrying something, which imho is an interesting cancel for widening the skill range the game will test. And for Deep Ink Pit, we could easily imagine a "enable GRAB" power-up to be collected.

Reste à intégrer le balancer des éponges, histoire de rester cohérent avec l'aventure. Il sera pratiquement nul au départ pour augmenter au fur et à mesure de la progression du joueur.
Pas moyen de "marcher" sur les éponges donc, au final, mais ce serait sympa de s'y accrocher de manière plus ferme, et puisque c'est le bouton B qui permet d'attraper les taille-crayons pour les lancer, autant faire de B le bouton par lequel on s'agrippe pour suivre le mouvement. Du coup, celui qui (dans le jeu complet) voudra passer une éponge en gardant son taille-crayon en main devra le faire "à la dure" sans compter sur son bouton B. C'est un "cancel" dans le jargon de Kirby Kid :P