Baies pas mûres

 

Eh si, il me reste encore des gribouilles du 1er Janvier 2022 à poster ... dont cette idée d'un berry-bat pas encore mûr qui essaie de se s'attaquer à Bilou mais qui reste attaché à sa branche ... qui a bien fait rire les gens qui l'ont vu, d'ailleurs.

Mais pourquoi, me direz-vous peut-être ? Eh bien outre son rôle de bow-wow rigolo, ces baies encore vertes sont plus dures et pourraient donc rester à trainer sur le sol une fois assommées par un saut. Quelque-chose qui pourrait se révéler utile dans les montagnes, par exemple, où les Applemen ne poussent pas...

There are sketches in a notepad, which were drawn on new year's day two years ago and that haven't been blogged yet. This is one of them. J.L.N and I were revisiting the green zone baddies and came up with a variant of the berrybat that isn't ready to leave the vines. 

It would play a bit like a bow-wow, it would be green, to show it isn't matured, and it will likely be a challenge to animate, especially if I want the vines to be a bit flexible (at least, flexible enough to justify they cannot suport Bilou's weight). But they would be harder than their matured, flying counterpart, meaning that they would stay around once stunned, could be picked up and thrown on things to stun them.

Il était aussi question de s'en servir pour faire enfler certains piafs et s'en servir comme plate-forme.

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)

Scorpeye... Enfin!

 Oui, je l'avoue, j'ai été lent. J'ai été distrait (au sens attention détournée). J'ai été démoralisé par cette "carapace" qui ne voulait pas faire demi-tour à chaque fois ou qui faisait des demi-tours intempestifs. J'ai douté, de cet empilement de couches qui devait me permettre de laisser des personnes non éduquées au C++ de bricoler aussi leur propres personnages. Sauf que tout ça, c'est bien joli mais que quand vous avez un dysfonctionnement quelque-part, le débugger vous balance des instructions machines alors que le problème est dans le bytecode qu'elles interprètent. Et mon "inspector widget" (pas encore fonctionnel dans le projet 3 rooms) est loin de valoir ddd.

It's been a long time, I have to admit. I've been slow to get things running; I've had lost the hope that I could get that scorpio-shell turning back when it hits a wall... and only when it hits a wall. It felt like I had built a Jenga stack of complexity in order to have a 'simple' interpreter for state machines. But a language is never less complex than the tools you provide to debug it. And Inspector Widget fell short when trying to explain the issue (partly because it is surprisingly not yet working on Dreams.nds)

Une intuition pendant mes vacances ... j'ai retracé la machine d'état de mon scorpion-cyclope. J'ai bien identifié deux ou trois incohérences, mais rien qui ne conduise au bon comportement une fois corrigé.

Oui, je sais aussi, par rapport à ce que je bricolais sur le côté pendant mes semaines de vacances, c'est maigre. C'était des vacances un peu ... particulières.

Puis hier, j'ai repris la machine d'état de pendat. Lui aussi, il réagit quand il fait demi-tour en se prenant un mur. Et il n'est peut-être pas parfait, mais il marche en général bien mieux que cette satanée carapace.

Alors que scorpeye tentait de reconnaître l'absence de sol à l'aide d'un testpoint, pendat se contentait de "dire" "ah bin si la vitesse horizontale est tombée à zéro, c'est qu'on s'est pris un mur. Sinon, c'est qu'on a plus de sol. C'est forcé."

I found only a small evening of ndsdev during my summer holiday this year, and I used it to map the state machine of Scorpeye. It helped me finding a few weird stuff, but it would not make things run properly enough, unfortunately. Then I realised past Inktober that I already had a 'working' monster that bounced off walls. That was the running pendat. And I started mapping its state machine too (granted, after all these years of dsgametools, I should have given myself a tool to make that automatically). To my surprise, it almost never used the same tricks to perform the same task.

For instance, I used a TestPoint below scorpeye to tell me whether there was ground underneath when it claims it failed to slide on the ground. But this is unreliable because it checks only one point to decide for ground while the WalkController checks the whole surface. Instead, the pendat would test whether it came to a halt horizontally. If it did, that means there has been a wall. Otherwise, it bets there's no ground left.

Same with fall/slide transition: the scorpeye tried to use a testpoint to know whether it FAILed because of a ground. Pendat code author (past self) knew the only thing that can make GobGravityController FAIL was a ground. Being stopped by a wall triggers an event. That means no testpoint validation is required.

Finally, I gave myself an extra variable (there are still plenty available for scorpeye) to remember the sliding speed so that we can bounce walls without having to rely on an ImpactController to save the last speed, because so far I don't think GobWalkerController is an ImpactController. It requires to double some states (like left-thrown vs. right-thrown), but that should not be a big deal.

Still, there's one thing that I'll need to fix with unit testing: from times to times, being stopped by a wall while 'walking' doesn't make the move FAIL, but it does clears the speed. Pendat doesn't suffer for that because it has an "increase horizontal speed" statement in its running states that prevents the speed to stay null. I had to add the same statement to the shell, but it shouldn't be required. that's a todo item for XMAS, I guess.

Il me fallait un double-état pour la carapace lancée, une variable supplémentaire pour retenir la vitesse à la place de la 'variable d'impact'... ce genre de choses. Mais il y a un élément suspect. Pour qu'il n'y ait aucun soucis, je suis obligé de mettre une instruction forçant la carapace à accélérer. Sans ça, il reste des situations dans lesquelles je retrouve ma carapace toujours dans l'état "on glisse vers la droite" mais avec une vitesse nulle est un mur juste à ça droite.

Comme si GobWalkerController avait un bug qui l'empèchait parfois de signaler l'échec (FAIL) même si la vitesse tombe à zéro. ça, ce sera une tâche pour un test unitaire.

Funghi v2.0

 Bon, il est temps que je blogge les cogitations de nouvelle année, vous ne croyez pas ? Je m'étais installé pépère dans le canapé pour récupérer un peu, agenda-cahier sur les genoux histoire de faire un peu le tri de ce qui doit encore être dit et ce qui doit être transférer dans la nouvelle année, mais c'était compté sans J.L.N.

Le p'tit bonhomme venait de se rendre compte qu'une SpongeBop, si on la repeind en vert, ça fait comme une branche d'arbre et que donc on pourrait en mettre dans la forêt! Il n'a pas tort, mais j'ai voulu vérifier ce qu'il connaissait déjà des autres habitants de la forêt de Bilou. Après tout, à part quelques parties de Apple Assault, il n'a pas encore eu beaucoup de contact avec la green zone.

Il y a Funky Funghi, notamment. Le champignon sauteur. Si je permets de ramasser les applemen à la manière des dumblador dans School Rush, que se passe-t-il quand on lance une pomme sur un Funghi ?

Sketches in this post were actually drawn on January 1st, while I was brainstorming Green Zone with my nearly-9-y.o. son. He's been mostly playing the School Zone so far, and only bits of Apple Assault. So little that he suggested I put a green spongebop as a spidey-branch platform of some sort.

At my first drawing of Funky Funghi, he'd almost immediately suggest that we can jump on his hat and use it as a platform to climb higher. Not a bad idea, but completely incompatible with the Commander Keen-inspired, decades-old setting where the whole funghi is highly toxic and that any contact should be avoided. But that was at a time where a Manic-Miner clone was considered.

L'idée de base, celle de la version BASIC, c'était que le champignon était ultra-toxique. Tiré assez directement de Commander Keen, je dois bien dire. Le moindre contact est dangereux pour Bilou. On ne peut même pas lui sauter dessus.

Mais bon, avec le recul, pour un premier niveau, c'est peut-être un peu exagéré. Je n'irais pas pour autant jusqu'à proposer que l'on puisse monter sur la tête de Funky Funghi et s'en servir comme plate-forme. Ce n'est pas franchement dans le caractère du personnage d'accepter ça.

Pas question non plus de permettre à Bilou de simplement 'pousser' Funky Funghi comme il le ferait avec un encrier (même si je n'ai toujours rien implémenté de la sorte ^^")

Faire se déplacer un ennemi sauteur invulnérable en visant correctement, voilà qui promet d'être fun. En tout cas, c'était fun dans Rayman.

I still would like to avoid a platform-like behaviour -- I even already have another mushroom design for that. And I now have throwable monsters in the rest of the game, meaning it would be good that we could pick up and throw applemen in Green Zone (that was the plan from long ago, before I came up with Apple Assault mechanics). That means something fun is bound to happen if you throw an apple at a funghi. Right ?

I bet being able to knock the otherwise-camping mushroom to an alternate location should be both fun and interesting (I take it from Rayman). But beware, said my bro: we don't want to end up locking the progression by poorly "chosing" where we put the funghi. And with an all-toxic one, chances that we lock ourselves are much higher. Especially with limited supplies of applemen in the level.

Mais contrairement à Rayman, on joue ici avec des "munitions" limitées. Il ne faudrait donc pas que l'on bloque un Funghi dans un coin du niveau où il peut nous empêcher définitivement d'avancer! Une solution pratique contre ça, évidemment, c'est de placer un 'trou à champignon' au bout de la zone-bac-à-sable dans laquelle il est prévu de le déplacer. Quoi qu'on fasse, il ne peut aller plus loin et on a remplacé "passer par-dessous l'obstacle" par "passer par-dessus l'obstacle", qui est en théorie plus accessible.

Final thought: if Edward is true claiming that goomba were picked mushroom-bumper-shaped because that should suggest the players they'll be safe jumping on them, making my bouncy-funghi hurt you when you stomp him won't be a neat way to teach the players they're in a traditional platformer when they're playing level 1 of Bilou's Dreamland. (not to mention that mushroom=bumper has been over-used in all platformers after that, to the point that it's almost more natural to try using them that way than trying to eat them and expect to grow or shrink, nowadays).

So let it be bouncy. But only his hat (foot is still toxic and you shouldn't try to push Funghi like you'd do with inkjet). And bumping you to the side as well. If you want to have a Funghi ride, you'll have to master it first. Else all you'll get will be a funghi-rodeo. 

Mais tout ça devient secondaire si - une fois déplacé - Funky Funghi devient utile. Bon, comprenons-nous: ça reste un PNJ peu fiable et dangereux sous les bords. Disons par exemple que son pied reste toxique (on ne le pousse pas à la main) et redoutable (on ne reste pas trainer en-dessous). Mais son chapeau, lui, avec sa jolie tête de bumper pourrait ne réserver aucune vacherie et agir effectivement comme un bumper. Mais un qui soit susceptible de nous propulser vers l'arrière ou vers l'avant si on ne le prend pas bien comme il faut. Bref, un bumper qui amène une touche d'imprévu pour le joueur inexpérimenté, une touche de challenge pour le paddawan, et une variable supplémentaire à intégrer pour le Maître.

A méditer.

A implémenter ;)

Oh!? A post! A shell !? Progress ?

I know it's been a long time. Would you like an explanation ? It's a nice one, with Persian princes and oversea travels and unicorns. Maybe even a dragon!

Anyway, I finally got some code refactory completed so that more 'controllers' can record impact speed into script-friendly variables. That at last allow me to code whether a scorpeye shell should bounce or not when it can no longer keep moving the way it was.

Salut! Vous êtes toujours là ? Bien! Merci ^_^ Allons-y, alors. J'ai enfin repris mon projet NDS, finalisé cette classe GobImpactController dont dérive maintenant GobGravityController, mais aussi GobFreemoveController, ce qui devrait (enfin) permettre à cette satanée carapace de scorpion de faire demi-tour quand elle se prend un mur.

Enfin, ça aurait suffi sur un sol lisse et infini. Mais j'avais justement un trou dans mon miniveau de test, j'ai donc pu chipoter un peu plus avec les testpoints, pester sur le fait que le contrôleur de chutes signale un event quand on se prend un mur (plutôt que d'annoncer l'échec du mouvement, vu qu'on peut toujours continuer à tomber ... dans un sens, c'est logique).

Je vous aurais bien mis une vidéo de tout ça, mais à 1Mo la vidéo de 10 secondes ... les plus irréductibles sont invités à la regarder sur twitter.

Oh, granted, there's been pitfalls. The fact that moving along the ground fails when you hit a wall while falling down and hitting a wall just creates an event, wasn't exactly welcome-back-to-coding-friendly.

But well, there it is. There it bounces. Unless you throw it straight into a floor+wall corner or on some odd location on the sand. I'll need more runME+InspectorWidget to find out what is going on there. Or maybe some more muad'dibugging ?

freemove ou pas

Bon, le week-end était bien chargé et la semaine qui commence risque d'être du même accabit, mais j'avais quand même trouvé le temps de modifier la configuration de runMe pour corriger l'affichage des sprites 32x16 et du même coup pouvoir utiliser InspectorWidget convenablement. Il est temps que je trouve pourquoi les carapaces de Scorpeye ne font pas demi-tour quand elles rencontrent un mur.

Et on dirait bien qu'une des raisons, c'est que j'ai utilisé pour cet état-là le contrôleur "freemove". (oui. encore;) Et freemove n'a pas le code C++ qu'il faut pour 'rapporter' la vitesse à laquelle on se déplaçait au moment où une collision avec le terrain a empéché un déplacement d'avoir lieu. Or c'est cette valeur qu'il faut utiliser pour faire le demi-tour.

Despite a week-end with a good deal of events, I managed to fix runME so that it could too display 32x16 pixels sprites properly. That unlocked the use of InspectorWidget to find out why scorpeye shells won't bounce when they hit a wall.

Apparently, the core reason for that is that the GobFreemoveController I use for sliding shells is unable to tell at what speed it was moving when there had been an impact with the wall. As a consequence, the script handling state transitions cannot properly program the new speed. And yes, that is very similar to an issue I've had with 'swimming' state for Bilou not so long ago. That sounds like I should refactor something so more state controllers can report impact speed...

Bref, soit un contrôleur comme 'walker' ferait l'affaire, soit il faut que je prévoie quelque-chose d'autre. peut-être que 'sauver la vitesse actuelle si le déplacement en cours n'est plus possible' devrait en soi être un contrôleur autonome dans la chaîne ?

Ou je met une vitesse 'hard-codée' pour l'instant ?
 

des sprites 32x16 ?

Le support des sprites rectangulaires, c'est pas encore une grande réussite dans GEDS. En chipotant un peu, on parvient à avoir une planche de sprites verticaux ou horizontaux dans SEDS. Ils sont quand-même édités sur une grille carrée, mais soit.

Les choses sont déjà un peu plus louches dans AnimEDS, où de curieux résidus viennent se placer par-dessous un sprite 32x16. ça gâche un peu l'effet, mais disons qu'on s'en serait accommodé le temps de d'un ennemi ou deux.

There is somehow way to introduce non-square sprites in my SpriteEditor (with those 'new W(ide)' and 'new H(igh)' buttons), and the NDS hardware definitely has support for them, but let's face it: none of the game engine or Animation Editor was half ready for a 32x16 scorpeye 'shell'

Mais le moteur de jeu a l'air de perdre complètement les pédales, lui.

Une petite réactivation de l'afficheur-de-sprites finit par me pointer le problème: je suis déjà au bout des 1024 sprites possibles dans ce nouvel environnement... enfin, pas exactement. Je n'ai pas encore saturé les 128K de mémoire disponibles pour les sprites, mais seulement les identifiants disponibles.

J'ai déjà joué avec ça pour l'éditeur de sprites, mais le moteur de jeu, visiblement, n'était pas prêt non-plus pour ça ... ça va faire un gros commit ...

You see: it really doesn't make sense. We get parts of Bilou heads instead of getting our expected shell, and the shape isn't even rectangular. Part of it is because the engine cannot change the shape of a 'limb' for a compound character while playing (changing states doesn't let you break that rule). If you're rectangular on your frame one, you're rectangular all your life long. Another part of it is because I'm hitting the tile number limit. I thought SchoolRush was already using 128K of VRAM for sprites, but it seems I was wrong and everything used to fit the default 64K. Only the background tiles had been increased. Anyway, the Makefiles didn't like it, but it is now expanded to 128K. Anything else ? Yep. size = 16 + mode = wide gives you 32x8 sprites. Not 32x16. That explains the lone stripe I had in the final attempts.

Un autre soucis visible sur l'animation: les tailles de gobs pour une page donnée ne peuvent pas être changées en passant d'une animation à l'autre. Et j'avais gardé la première version 32x32 pour l'animation "immobile". Du coup, les autres animations tentaient aussi d'utiliser du 32x32 même quand les images à charger étaient en 32x16.

Ah, et j'ai probablement sous-estimé l'existence des sprites 32x8, ce qui fait qu'encore après tous ces patches, il me manque la moitié de ma carapace ...

Les piles momies animées.

Au milieu d'un mois de dingues, j'ai quand-même réussi à améliorer un peu les graphismes de mes piles-momies et à faire une petite machine d'état qui fonctionne.

En fait, maintenant que j'y pense, pour ceux qui arrivent à atteindre la plate-forme là-haut, on peut même essayer de voir ce que ça donne de sauter par-dessus. Allez, ça mérite une démo téléchargeable, ça.

It's been a tough month. Let me tell you, when release-day came out on 24th, packing a binary with some new stuff to offer to you all was the last thing I had in mind (just before I'd fell asleep. Or maybe just after). But I still managed to improve a bit the undead-cell graphics, mirror the animation and give it a state machine so that it can be placed in levels. It isn't interacting with anything yet, just checking whether it should turn back at the edge of platforms, but there it is. You can practice tricky jumps if you feel so ;) The downloadable .nds finally made it to the Internet.

Animating the Undead Cell

 

I admit one of the reason for playing Epic Mickey again was to see how they had dealt with the sands and desert things in the Agrabah level, but I was far from imaginating that it would unlock my animation issue for the UndeadCell. One of the ennemies we face in the game is a mushroom species that has level-themed variation.

J'avoue: une des raisons pour lesquelles j'ai rejoué à Epic Mickey, c'est parce que j'ai réalisé qu'il y avait là la meilleure version graphique de l'univers d'Aladdin, tout en sable fluide et pierres jaunes. Quoi de mieux comme source d'inspiration pour ma pyramide bilouteuse ? Mais je ne m'attendais pas à ce que ce soit le champi-turban qui me serve le plus de source d'inspiration.

Conveniently enough, the sprite table was available on the Spriter resource, but let's be clear: if you can rebuild the animation from the sheet, you're the original animator. But at least, there was one thing I could extract from it: the sine motion for the pot of the character and the fact that the 'hat' more or less follows the slope of the sine. Colors for the turban are h30s18v99, h31s40v87, h27s51v75, h29s60v62, h25s59v55, just in case I wouldn't be satisfied with the current ones.

So I tried to sketch that and it looked nice on paper. I redrawn it in my SpriteEditor and it looked interesting (although I couldn't loop 'walking' animations properly). Getting it to work in AnimEditor was a bit harder: you can lock a sprite in the world while you're animating the rest, but the undead cell has no thing such as a foot that could be locked and moved backwards (pushing the rest of the character forward) like dumblador had.

C'est que, voyez-vous, l'animation actuelle de la pile-momie est tellement peu concluante que je ne l'ai toujours pas intégrée dans le niveau-test. Mais ce champi mélange pixel art et technique d'animation "cartoon-ancestrale" qui me montre la voie à suivre. Je gribouille donc une sinusoïde qui servira de repère. Je note que dans leur animation, l'orientation et l'étirement du chapeau suit la pente de cette sinusoïde. Je fais de même.

Il y a encore une 'pose iconique' dont je veux m'inspirer: cette manière dont le personnage fait une courbe montante au moment de se redresser. Comme s'il se déplaçait en utilisant le poids de sa coiffe qu'il laisse d'abord tomber vers l'avant puis qu'il doit courir pour la redresser telle la pile de livre de Lagaffe.

Hopefully, while animating in SEDS, I made the character actually move within its 32x32 frame. Part of why it moves now is because I kept that, but scrolled the frame backwards so that the eye always remained at the same spot within the bounding box.

So here it is, in a "how it started / how it is going" sort of animation (from a file beamed before I could fix the forward motion). As you can see, it still need to be significantly polished, and I got barely any time to work on it this week, as my kid had to finish a show-and-tell for school.

ça me fait pas loin de 11 étapes d'animation pour la pile qui avance. de 32x32 chacune, mais bon j'ai 256K de sprites à ma disposition... ce serait dommage de faire le gripsou et ne pas en profiter à ce stade-ci.

J'ai du chipoter un peu pour trouver comment adapter le mécanisme de 'verrouillage de sprite' qui avait bien marché pour dumblador sur un personnage qui ici n'a pas de pied. Est-ce la bonne vitesse ? Bah, dans le pire des cas, je la mettrai sur du sable qui coule, et ça justifiera une vitesse plus élevée, hein ;) La voir revenir en arrière dans les premiers temps de son développement m'a donné l'idée que la vitesse d'écoulement du sable devrait être telle qu'elle reste immobile à contre-courant.

edit: ouaip. C'est bien beau tout ça, mais une animation qui "marche" dans AnimEDS n'équivaut pas forcément à une animation qui marche dans le jeu. En particulier, l'éditeur joue en réalité l'animation à la vitesse indiquée, forçant le déplacement correspondant. Le moteur de jeu, au contraire, asservit l'animation au déplacement. Ce qui donne ici une pile qui reste immobile un long moment puis joue presque toutes ses frames d'un coup parce que j'ai abusé du 'mov#1' et du 'mov#0' (enfin, je crois).

Devant ou au-dessus ?

 Pas mon masque, hein. La carapace de scorpion quand Bilou la transporte. Celle qui doit me permettre de faire quelques petits moments-koopa dans la pyramide. La logique voudrait qu'on la transporte au-dessus de la tête de Bilou, comme les Dumbladors et les éponges dans School Rush.

Mais voilà, je me souviens bien qu'un des trucs que je trouvais dommage dans Super Princess Peach, c'est la manière dont elle ramassait les carapaces pour les tenir par-dessus sa tête avec son ombrelle, la laissant du coup vulnérable à une attaque frontale du plus élémentaire goomba. Je préfère de loin la technique de Mario qui peut se protéger (voire foncer dans un ennemi sans hésitation) dès qu'il a ramassé une carapace.

Should Bilou carry throwable scorpion shells in front of him, like Mario and Diddy or should he carry them over is head like Donkey and Princess Peach ? Both Twitter and my bro agree: over-the-head is better. It sure looks better: the shell is too large to be handled any other way. Plus, other carry-me items in the game already gets carried I can't forget however that I preferred the experience of in-front in all the games I played so far. It shields you against incoming foes, let you find hidden areas without taking any risks and avoids functional blind spots when you're throwing them.

Idem dans la série DKC: une des choses qui fait que j'ai toujours préféré jouer Diddy plutôt que Donkey, c'est que Donkey porte ses tonneaux au-dessus de lui. ça les rend à la fois moins utile comme bouclier et comme détecteur de passages secret: Diddy peut se contenter de s'approcher du mur alors qu'avec DK, il faudra s'approcher pas trop et lancer le tonneau (ou alors, on se baisse et on dépose le tonneau, quitte à le reprendre si on a fait chou blanc)

Du coup, j'ai fait un p'tit poll sur twitter pour voir un peu vos avis ... Majoritairement en faveur du 'par dessus la tête', visiblement. ça paraît raisonnable. J'imagine qu'on devrait pouvoir garder un côté "bouclier" en s'abaissant pendant qu'on porte la carapace, façon Blues Brothers / Tic & Tac. Il faudra par contre que je sois attentif à ne pas laisser trop de "zone morte" au moment du lancer pour éviter le défaut de DK, en particulier si je veux être efficace contre des ennemis à peine plus hauts que Bilou.

I think I can fix the shielding issue with some duck-while-holding that would reduce Bilou's hitbox and increases the odds that the shell takes the hit instead.

I'll need to take care of the functional blind spot. The shell should leave at a speed high enough that it feels 'fast' to the player (might be the other issue with Super Princess Peach's throw move). I sure can't afford the blind spot to be as large as in DKC (anything between Kong and banana on the picture above is out of the barrel's reach)

edit: Maybe my memories of Super Princess Peach are skewed. Re-playing it a few minutes didn't give me that feeling that koopa shells were broken, and one reason for that is that Peach also gives a (short-range) umbrella attack while throwing. 

Possibly the real issue is with button mapping: you use PICK UP to take the shell, but if you use the same button again, you'll drop an harmless shell rather than throwing it as a long-range attack. And if you press the ATTACK button instead of PICK UP when you don't have the shell with you, you risk of destroying the shell instead of getting a weapon. None of this should occur with Bilou, hopefully. And when you see that the shell in Princess Peach has lowered by more than 1 block within the first 4 frames of animation. Low enough to hit any possible monster with almost no build-up time.

Big Caterpillar

There has to be boss fights in Bilou Dreamland. I cannot work around that: my son won't let me do with a puzzle part where you're trying to avoid sting-like and claw-like hazard and pretend that 'yeah, the boss was behind the wall. You made it!".

The first encounter in-game will have to be against Big Caterpillar, holder of the Growth Stone, one of the eldest design for the game. Its design hasn't evolved that much over the years: it still should have some reds and greens. It still should look angry and crawl towards Bilou to squash him. But I'm wondering how it should best attack and what should be its weakest points. I might want to make its overall shape look more like the "chenillard" monster that my brother used here and there in his original levels.

Bon, pour ce prochain jeu, pas d'échappatoire: il faudra des Boss. Pour le premier qu'on rencontrera, au moins, j'ai de la matière. Depuis le tout début du personnage, il y a des croquis de chenilles géantes. Il a même eu droit à sa bande son! C'est dire ! ... Et il faudra qu'on les combatte. Je ne m'en sortirai pas avec une course-poursuite ou une salle-super-puzzle pleine de pinces qui sortent des murs. J.L.N voudra un affrontement en bonne et dûe forme! Alors autant ne pas attendre la dernière minute pour s'y mettre.

In the comic much like in the BASIC game, you knock the boss down by stomping its head. Various attacks would protect the head with the rest of the body, forcing you to wait for an opening, and when you eventually land your stomp, the boss turns red for some time and can't be attacked again before it cools down.

But as you noted, Big Caterpillar has sorts of bull horns. If form fits function, that means you should rather try to avoid jumping on its head. I need to find something else. Hours spent fighting against Moldorm in '90s Legend of Zelda titles immediately suggest aiming for the tail, which would be fine if the only way you have to attack is jumping. But Bilou can also throw things, and aiming for a grounded target will likely not be a very interesting task. I'd like to have something more subtle.

Par contre, ça ne donne pas forcément une réponse aux deux questions critiques: comment attaque-t-il et comment fait-on baisser sa barre de vie ? Dans la BD (ou le combat dure royalement deux pages) et dans le jeu BASIC, le point-faible de Big Caterpillar, c'est sa tête. Sauf que depuis la BD, il a chopé des espèce de cornes de taureau, et donc c'est le signe pour les joueurs de ne pas se risquer à lui tomber dessus.

Quand j'ai voulu proposer un nouveau design pour le "chenillard" (une monstre figurant dans les premiers niveaux dessinés par mon frère, sans nul doute inspiré du monstre-chenille de la Marble Zone), j'ai suivi mon instinct de chevalier d'Hyrule et j'ai mis son point faible sur la queue: taper sur sa tête ne sert à rien d'autre qu'à l'énerver. Ça ne marchait pas trop mal tant qu'on limite les attaques au saut, mais après School Rush, Bilou a acquis assez définitivement la possibilité de lancer des ennemis à la figure d'autres ennemis. On ne va pas revenir là-dessus. Comme je prévois de permettre à Big Caterpillar de se dresser façon Pokey avant d'attaquer, ça rend son point faible très vulnérable à un lancer de pomme pépère depuis le sol. Je dois cogiter un peu tout ça, donc.

When it comes to the 'look', Big Caterpillar depicted in the comic isn't very refined. Rough clay balls of alternate shade and only then a horned head. But that was years before 'bubble bats' turned into 'berry bats' ... And a stunning piece of art by Franek last year made me realize that my boss could look gorgeous if I tried to make it made of berries too.

I'll have to try tonight and see whether I can come with something along these lines...

Reste le look. Celui de la BD était très générique. Celui du jeu BASIC tout autant. On aurait pu affronter une chenille faite de boules de plasticine verte que ça n'aurait pas fait une grosse différence. Mais ça, c'était avant l'introduction des berrybats (ou, comme J.L.N aime à les appeler, les chauves-souris-baies :D). Pourquoi du coup ne pas essaier de faire comme si notre boss-chenille était lui aussi fait de fruits vivants ?

La démo de Février

ça n'aura pas été une semaine facile, loin de là. Heureusement, il n'y avait pas trop de travail à fournir avant d'avoir une meilleure gestion de la physique dans l'eau. je peux donc vous proposer comme prévu une nouvelle démo avant d'aller chercher la remplaçante de ma voiture déclassée ...

To be honest, I had little hope I could actually provide you a new version of the 3-rooms demo with fixed swim mechanics, given how much thing I had to fix over the evenings last week. Hopefully, there was only minor changes to implement and thus, the new demo is there anyway. Enjoy.

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 ?

Les bonus s'emmèlent...

J'étais tout content de voir que Bilou savait aller dans l'eau, et je ne me suis pas rendu compte qu'il y avait un soucis avec les bonus: on pouvait carrément marcher dessus. Quelque-chose lié à la nouvelle propriété F_START_FALLING, sans doute ... sauf que non. c'est surtout lié aux bytes 'regarde à côté'.

C'est que l'ancien moteur de jeu utilisait le numéro du 'bloc spécial' pour décider s'il devait être solide ou non, et la fonction qui indique la 'hauteur du sol' essayait toujours de faire comme ça. L'ennui, c'est que j'ai utillisé les codes 0xfc à 0xff pour les fameux 'regarde à côté' qui permettent aux blocs spéciaux d'être des blocs, et pas juste des pavés de 8x8.

Jan.24. Managed to have Bilou switch to 'swim' state when it gets in contact with F_WATER tiles. It's as swimple as $LFALL->$INWATER on fail [H WATER ?] ...

Jan.25. It uses the new H GobExpression 'operator' that puts type of the tile under character's hotspot on stack, where it can later be compared with a constant flag (WATER). That operator will expect an elevation value on the stack first. like [2 H WATER ?] to tell "check 2 pixels above the hotspot"

But this is not the point of this post. The point is, looking at the video I captured (bottom left on the toot panel below), I noticed I was walking on disappeared apple before going into the water.

Jan.29. When you pick up a bonus, a MapAnim is spawn, that will edit graphics to get that sprinkling animation. It should clear "properties" as well, as soon as you get in contact with the collectible.

Yet, the change to newmeta changed what 'cleared' means on the map. Now, the clear value 0 means 'lookup World::properties[0] to know what you can do'. Another trap was that, when checking ground height, you might find yourself on one of the new "lookup one tile left" or "lookup one tile up" that are used to make special *blocks* of adjustable size (not just special mini-squares of 8x8 pixels). If that happens, code was still lacking "locate the actual block defining corner" and then use that special blocks's properties set to decide whether it has ground or not.

Pas le choix, donc: ici aussi, il faut retrouver le 'coin actif' du bloc spécial et aller chercher ses propriétés dans le BlockInfo correspondant.

Deuxième farce (voir l'animation): une fois le bonus effacé, il a laissé derrière lui un bloc à travers lequel il est possible de continuer à tomber, mais aussi de continuer à marcher. La faute cette fois au tableau des propriétés pré-encodées pour les blocs à définition indirecte (prévus pour les physiques particulières, essentiellement).

edit: if you don't have a twitter account, here's what the videos looked like:

à l'eau ?

J'imagine que ça devait être la prochaine chose à faire: s'assurer que Bilou sache rentrer dans l'eau et que les mouvements quand il s'y trouve soient différents de ceux dans l'air. C'est encore assez primitif, mais ça commence à marcher.

Let's dive in: the last demo was nice, but it sure felt awkward to have the water behave as a solid platform. I suppose it's a mandatory to-do item before I release something new: make sure the water feels more like water. It will be perfectible, of course. I don't intend to make it look more like water at this iteration, but at least ensure that I can detect when Bilou is entering water and make him act differently. And that is slowly getting in shape... 

J'ai finalement pris l'approche envisagée dans mes notes de l'an dernier (ou 2 ans ?): une bande de tiles haute comme Bilou qui autorise à la fois de tomber et de nager. La surface est dessinée à peu près à mi-hauteur de cette bande.

Du coup, quand Bilou rencontre enfin de "l'eau profonde" dans laquelle il n'est plus possible de tomber, il est déjà capable de nager là où il se trouve.

ça ne fonctionnerait pas aussi facilement avec un personnage plus gros comme ce poisson, mais on y est pas encore, au gros poisson (je n'en ai même pas dans mes cartons pour 'Dreamland', alors ...)

trivia: the animated gif above is about 100KB. The one I initially captured was over 1.5MB due to scrolling. I had to create a 'dontmove.cmd' object and give it the focus so I could capture the proper sequence. If you look carefully above the water surface, you can spot it.

There's one thing I'd like to get fixed soon: when you reach back the surface, you're stopped straight. That should not happen, but I do not seem to be able to fix it with a transition. This is a job for a revived "muad-debugging" session: it would let me see step by step why no transition is taken by re-playing the think() function after I detected yspeed == 0.

edit: I'll have to write a dedicated 'in-water' controller: hacking with 'increase' and 'freemove' doesn't produce anything convincing even after freemove is fixed so that it fails at the surface.

ç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.

Le fruit-bouffi

Dans un ancien post, j'avais des piafs-saucisses-plate-formes. Dans un autre, j'ai des piafs-copains-qui-nous-transportent-à plusieurs...

I've got an old post where birds have been stretched and helium-inflated so they could be used as walkable platforms, and another, more recent one where birds have birdish shapes and use ropes to carry the player -- but you need many of them if you don't want to fall down.

What if I could get the new-one turn into the old-one for some specific locations, as result of a key-and-lock interaction ? A possible key would be something you can feed the bird with, but isn't exactly part of their diet. Maybe a raw berrybat ?

Et si on pouvait faire transformer un piaf-copain en piaf-plate-forme ? par exemple en lui faisant avaler quelque-chose qu'il ne digère pas vraiment ...

Une chauve-souris-baie pas mûre, par exemple, qu'on aurait été pêcher dans une caverne de la montagne ...

à creuser.

It would introduce a valid reason for having caves in addition to peaks within those mountains (bats like caves more than peaks).

Slopes Landed.

I think I got it working. There was one major flaw in my earlier design: stating that you can F_FALLTRHU a slope implied that you could no longer walk on it, as the walking controller tests for solid ground by checking whether it would be possible to fall down from the current location. Oh, not much. Just one pixel is enough to claim that you cannot walk anymore.

But the technique used for terrain collision detection -- cando() -- assumes that we only do a move if we can do it over all the tiles covered during the move. That means the slope tiles should both allow us to fall through them (until ground height, at least), and not allow to start falling through them. To get that solved, I had to split the flag, having one bit telling whether we can start falling (F_START_FALLING) and one telling whether we can keep falling. Walker controller tests one of these bits, gravity controller tests the other one.

Then I had another issue, not properly computing the ground distance to see whether the move we cando actually remained over the ground. Let Bouli explain that...

We were at old position (ox, oy) and will move our 'hot spot' (the one that is kept in contact with the ground on uneven grounds) to (hx,hy). In order to know whether we're find with slope-landing, we compare hy - oy with the 'ground distance', which is construct with an appropriate sum of tile.groundheight() calls.

But groundheight() gives us a value relative to the bottom of the corresponding tile. -8 means the whole tile is solid. -2 means the first 2 pixels of the tile are solid, the rest is air. 0 means the whole tile is air. That was quite quickly remembered and accounted for. The other part to take into account is that the start of the darkblue 'vertical motion vector' may be anywhere within the first tile. If we're in the 4th pixel of the tile and the last pixel of the tile is solid, then only hy - oy < 3 are uninterrupted moves.

Land on Slope

There are many things that got fixed over my holidays, and many things that remain to be done before I can claim the 3 rooms "done". I had to pick one for the last week-end ... it seemed wise to pick something that I'd likely not have enough focus to work on during the evenings of a regular week. "Land on slopes" seemed the right one to pick.

So far, only the "walk" (behaviour) controller is aware of slopes. For the rest of the code, the world is all made of square tiles, and the properties of a tiles are homogeneous over that square. The result is that if you try to land from a jump on sloped ground, you're very likely to end up floating over the ground until you start walking.

I gave it a first try yesterday, opening the debugger, seeing what happens when I'm entering such a tile, designing a patch, compiling it, trying it, discover that it wouldn't work, refine it, and repeating the cycle. Over and over.

It wouldn't work. First because the slope tiles couldn't be fallen through. There's no need to try working around it: they *must* be made fall-through. Second because slopes are currently complemented by walk-through-but-don't-fall-through blocks that ensure smooth walk, but interfere with falling. I had that discussed with the Undisbeliever in the past, as it was a difference between our implementations, and the solution will be to replace them with a 'sloped' ground that actually is square.

But the ultimate reason of my failure is that I was trying to provide a solution for 'fall on the sloped ground' as if we'd have the last row of tiles all made of F_SLOPE tiles. The reality is much more diverse: there are so many 'corner' cases that we can hardly call them 'corners' at all.

I have a replacement design sketched, which I'll give a try in the afternoon. Amusingly, it looks a lot like what (I've understood) happens in Sonic the Hedgehog engine: consider the whole column of tiles on top of the desired 'new hot spot position' and figure out the 'ground height' in that column. Then make sure the move planned so far doesn't work past the ground.

Do that every time. If done right, it doesn't matter how many sloped tiles were encountered when checking that we cando() the move.

Well, that was the plan, but for some reason, it is not yet quite working. And for some (possibly other) reason, it managed to break walk-on-slopes despite my care to avoid so.

edit: fixed

Les Capris et tutti quanti.

Avec les enfants qui veulent aussi jouer, les niveaux plus longs et une fonction "prendre une vidéo en jouant", je suis moins tenté sur Switch de mettre mon jeu en pause et de commencer à parler/redessiner quelque-chose. Quand je le fais quand-même, c'est souvent pendant que les enfants jouent, et donc des petits schémas techniques griffonnés plutôt que des croquis.

Mais l'an dernier, j'avais quand-même pris le temps de passer en revue mes vidéos de Donkey Kong Tropical Freeze pour voir un peu ce qu'il y avait de particulier comme type de plate-formes mobiles (avec évidemment la Peaks Zone en tête).

C'est aussi vers DKTF que je me suis orienté il y a quelques jours pour essayer de trouver des idées de 'niveau aérien' et c'est en voyant la tempête du niveau 3-3 emporter tout et n'importe quoi que j'ai réalisé que "bah, en fait, j'ai pas besoin de me creuser la tête pour trouver des animaux succeptibles de faire plate-forme volante: il suffit que je dise qu'il y a des courants d'airs et que je trouve des choses assez légères pour se faire emporter. C'était le premier "débloqueur".

Puis en bas de la feuille j'ai commencé à dessiner ces arbres tout tordus et leur branche m'ont donné envie de tendre des cordes entre les deux pour que Bilou puisse passer dessus. C'était l'élément de level design qui m'avait manqué jusque là.

It's been 2 years since I decided to have a 'mountains peaks zone' for Bilou's Dreamland, and even before that, I had ideas to use sheep/goat-like monsters to populate it (plus birds). But none of this led to any monster design or level design post. I just couldn't come up with anything to draw. Hopefully, it changed lately. It all started with a funny tree I draw on a sketch while collecting gameplay ideas from Donkey Kong: Tropical Freeze videos (and other possible videos about 'air world', btw). It had hook-like branches, with no leaves on it. It was appealing for a string bridging from one to another. It felt natural that Bilou would use that string to move from one place to another when there's nothing 'floating' inbetween...

I tried to imagine what could prevent him from doing so. Like a tightrope dancer. I tried to recycle my goat-idea and had fun giving it a Ice-Kirby pose. It seemed to work like magic. It's not an evil opponent, just someone who happens to be dangerous for you, in this case because you happen to have missed that you're on a circus-training area. The idea was working well, so it was time to pick up proper pens, proper paper and start drawing that for real.

Une fois la corde tendue et Bilou accroché dessus se posait la question: qu'est-ce qui pourrait le mettre en danger. J'avais depuis longtemps l'intention de mettre des espèces de bouquetins dans la montagne. Une influence du premier Rayman.

Ça s'est mélangé dans ma tête avec une posture de Kirby-patineur avec son pied en l'air. Ah, ce serait tellement plus facile pour Bilou s'il avait une formation de funambule ...

Mais pour un bouquetin, ça devrait être un jeu d'enfant, non ? Une fois cette idée dessinée, je savais que je tenais le bon bout.

Restait à voir si tout ça est assez "Bilouteux". J'entends par là, est-ce qu'on se sentira sur la planète des chauve-souris-baies et des crayons soldats ? Les rochers troués comme du gruyère sont rigolos, les arbres sont bien quand ils sont nus mais un peu plus classiques avec leur look de palmier quand ils ont encore leurs feuilles.

Probablement que Joke trouverait que tout ça manque de champignon. Alors j'ai repris mon dessin et j'ai gribouillé des chapeaux de champignons par-dessus tous mes feuillages d'arbre. ça marche. c'est même ce que j'ai de plus convainquant pour justifier les "feuilles parasols" servant de plate-formes volantes. Alors allons-y: ce seront des hybrides arbres/champignons dont le chapeau se laisse emporter par le vent pour aller disséminer plus loin une fois qu'il est bien mûr.

So I started drawing all the stuff I had barely sketched so far, leafless trees, ropedancing goats, watching goats, large flying structures brought up by upwards winds ... a bit too big for a single leaf given the trees size. You'll notice that this early sketch also features sorts of 'beaks' within the rock. That's something I had noted to lead to interesting look, but which doesn't seem to work well with the 'cheddar-holes'. And I definitely want to keep cheddar holes :P

Later on, on a walk, I realised that a pal known as 'the BilouMaster' would likely suggest that the scenery needs more mushrooms. So why not claim that those trees have mushroom-like tops instead of leaves ? That would give me free 'floating platforms in upwards winds', free umbrella-like thing to hold while a goat is ropedancing and contribute to the overall 'Bilou, not earth' feeling of the area. I overdrawn my sketch a bit .. it seemed to work. I kept it.

A ce stade, j'ai repris ma liste de plate-formes spéciales dans DKTF. La première, c'était une plate-forme qui se met en mouvement en fonction de la position de DK sur la plateforme: à gauche, elle part à gauche; à droite, elle part à droite.

ça marche impeccablement avec un chapeau de champignon. En fonction de la hauteur des colonnes d'air, de leur intermittence ou non, je peux construire un niveau aussi varié que la traversée en montgolfière de DKC2.

DKTF propose un joyeux nombre de variations sur ce thème, avec de l'électricité ou des plate-formes incomplètes, mais une des plus remarquable, c'est peut-être celle qui la combine avec la mécanique "s'accrocher" introduite dans Donkey Kong Returns.

Ça tombe bien: j'ai justement envie de faire de "Dream Land" le jeu où Bilou peut justement s'accrocher à tout et n'importe quoi. aux branches des arbres, aux racines souterraines, au cous des bestioles qui infestent la pyramide ... Et évidemment aux cordes des ponts de cette nouvelle zone.

Alors du coup, ça nous donne une manière bien plus intéressante d'utiliser la combinaison 'une corde transportée par deux oiseaux: Bilou au centre, les charges sont réparties et la corde s'élève emportée par les deux oiseaux. Si on se décale d'un côté, ça augmente la charge pour l'oiseau correspondant et on dévie de ce côté tout en descendant lentement.

It felt like it was the right time to pick up my never-blogged list of original kind of platforms in Donkey Kong: Tropical Freeze, and see whether I could match them with things that would work in the newly defined Peaks Zone.

A platform that starts moving left or right as you move to its left or right, for instance. That could be a floating mushroom top. Another one where you're hanging instead of landed ? Well, since "I don't see why Bilou wouldn't use the ropes" would work well here too. When there are just 2 birds and one rope, they're just strong enough to lift him if Bilou's weight is equally distributed. Otherwise, you'd dift in one direction (and slightly slide down).

Mais revenons à nos bouquetins. Un autre petit schémas de plate-forme que j'avais dans mon cahier montrait une bascule avec un obstacle à pic passant d'un côté à l'autre.

Alors bon, on ne va pas vraiment commencer à rajouter des boules à picots ici (je n'ai pas les fruits géants de DK pour le justifier), mais dans la catégorie 'obstacle à roulette', je peux profiter de l'idée "font leur cirque pour introduire un autre type d'acrobate.

et le voilà. Irrésistible. Adorable mais redoutable.

Can the new goats also be used in some DK-like platform mechanics ? Sure! There was one about a platform that tilts back and forth and makes a spiky hazard roll left and right along with its movement. We can sure find something that rolls in a circus setting, right ? Just add a happy goat/sheep thing on top of it and voilà.

And while I was telling all that to my brother, I've got a flash-vision of happy goats appearing from the bottom of the screen as if there was a hidden trampoline and you could make your way by carefully bouncing from one goat-back to the next. 

Puis en racontant tout ça à mon frangin hier me vient l'idée d'un passage où on voit tout simplement des bouquetins surgir du fond de l'écran, faire leur petite pose et retomber. On doit passer à dos de 'mouton' pendant ce temps-là.

au moment de le dessiner, vu que je n'ai pas de "fond d'écran" pour masquer ce qui se passe, j'ajoute à nouveau une corde. il rebondissent dessus comme sur un trampoline. Un clin d'oeil à Sleepwalker.

Autant dire que ça aussi, il vaudra mieux que ça n'arrive pas pendant que Bilou est suspendu à la corde.

Of course 'a hidden trampoline' isn't something easy to draw, so I replaced it by a string. A string you should better not try to use because you can't hold to a strumming string. There were more platforms styles in DKTF, of course, like that giant flower that starts bending when you lose its center, but there's already a good deal of things to implement here, isn't it ?

Il en reste, évidemment. Je n'ai pas essayé de convertir les fleurs géantes qui basculent, celles qu'on déplie en se suspendant à un truc qui pendouille ni les tours de plate-formes qui s'enfoncent (et donc se déroulent) quand on marche sur l'une d'elles. Mais bon, je crois qu'on peut dire qu'il y a déjà de quoi voir venir, non ?