Hang on!

It's one of the key mechanics I'd like to bring into my new game: being able to catch hanging things and hanging as well. It was a fun move in Commander Keen, it was amazingly expanded in Fury of the Furries and Mickey Magical quest ... And last week-end, I went on to try and get it prototyped.

I started with a summary of how Bilou can hang below spongebops in School Rush ... something we don't see a lot in the blog, mostly because Bilou is supposed to *ride* the sponges, not hang under them. Hanging was added as an "else" branch of another "else" branch:

when you hit the "HANDS" button mid-air, Bilou does a roll move trying to grab what's nearby. that is AIRGRAB state. The original idea was to test what was *below* him and either pick-up a dumblador or ride a spongebop... but the move shows the hand grabbing in front and rear directions as well ... so it would feel natural that Bilou could grab a sponge even if he's on the same horizontal line, like in the sketch on the left. Yet, snapping Bilou on top of the sponge from this location felt glitchy.

Bon, j'ai un p'tit Bilou suspendu sur une page de mon cahier-agenda depuis le début 2024 ... j'en ai un autre sur la bannière du blog ... je crois que l'appel du pied est assez clair: il serait temps de prototyper un peu ça, d'autant que cette fois ci, ce ne sont pas les coins de niveau où s'accrocher qui manquent dans le livre-secret-du-level-design.

Et pour "commencer simple", l'idée était de faire subir à Bilou le comportement des éponges. tout en réutilisant un des états codés pour l'interaction avec les éponges: rester suspendu (la feinte). Chose qui m'a tout de même demandé de me replonger dans pas mal de gobscript, parce qu'à la base, il est prévu que Bilou s'accroche *par-dessus* les éponges, et pas qu'il pende en-dessous. Le côté "pendu" n'a été rajouté que dans les derniers 20% du projet, entre deux séances de playtesting parce "bin, oui, c'est vrai au fait: pourquoi Bilou ne pourrait-il pas rester suspendu s'il était trop bas pour escalader l'éponge au moment ou la joueuse a appuyé sur (B) ?"

So instead, Bilou will enter AIRHOP move, getting an automatic double jump and automatically tracking the sponge's position. That feels fairly naturally when playing, that gives you a sort of "fair second chance" but it might fail anyway: you may fall below sponge's position again without having reached the "riding spot", with no hope of catching up. and *that* is the time when we finally switch to HANGING. 

There will be other objects to hang to in the game, especially bookmarks, vines, and the like. Some of them could be entities like spongebop (maybe moving a bit less), but sometimes it might also be nice to have tiles you can hook to. I have code to make some tiles react to collisions with the player, but that was not enough: the hitboxes used to detect spongebop explicitly search for baddies. And because I'm testing 3 areas over the course of the animation, I'm out of options to also test for friendly areas (which has been the case for all pick-ups so far ^^"). But hitting a tile can trigger an animation, and it can spawn an entity with proper hitboxes so that Bilou could hook to *that*. You couldn't really hook to a tile, anyway, because the BlockArea created during the collision test is immediately recycled, so you could not attach to it. 

Mon idée était ensuite d'utiliser un type de bloc spécial pour servir de point d'accroche, et d'aller "poker" quelques blocs de ce genre à des endroits bien sentis de la map "green" de la démo. ça non plus, ça n'a pas fonctionné comme j'espérais. Entre autres parce que quand Bilou cherche à s'accrocher à quelque-chose pendant sa pirouette-en-l'air, il cherche parmi la liste "EVIL" ... et les blocs interactifs, eux se présente automatiquement comme des "HERO".

Bon, ce n'est pas bien grave: puisque je voulais que Bilou s'attache au point d'ancrage, il fallait de toutes façons que j'introduise un GOB (game object) généré à partir du bloc spécial, un peu comme les scintillements qui suivent Bilou quand on ramasse un smiley bleu. Ce gob pourra être dans la liste que l'on veut. Pour éviter qu'on ne génère des quantités ridicules de gob-points-d'ancrage, on va (enfin) utiliser une animation de la map elle-même pour désactiver puis réactiver les propriétés du bloc pendant que le gob est présent. Exactement le comportement des blocs-question de SuperMario quand on les coup-de-boulise.

So the plan was the following: a new special block that would react to GRAB action. When that happens, it trigger the animation that actually leaves graphics untouched (with "spr0 ffff") but turns the physical tile into "plain fall-through" for 5 frames, and then restore the tile as "block 07" (thus interactive) again. Quite the kind of thing that SuperMario question blocks do on a daily basis, actually.

(It turned out meanwhile that using sprite 'ffff' did not work as intended, so I ended up adding a bbox statement to that animation -- effectively making it a special 8x8 tile rather than a 16x16 special block -- and fixed the code that plays mapanim so that "props" instruction is executed immediately rather than cached until the next "spr0" instruction)

anim9 spr:2 {
   spr0 7      # visuals for the "tile replacement",
   delay 5     # here just a Bilou hand ...
   done
}

state63 :anim9 {           # behaviour for that hand :
   using freemove          # just stay there, 
   area 0 (0,0)-(8,8) 1010 # accept GRAB hits.
}

state62 :anim9 {   # should have been the persistent state when Bilou hooked...
   using freemove
}

state63->state62 on found 0 [wc $1010 ?] (t) # detecting the actual hook-up hit
state63->nil on done                         # and disappear otherwise

using shgob(state63 is e:=1:6) as 6          # a special action to spawn the hooked hand
                                             # oh ... and it's an evil hooked hand.
block 06 {
    is gndhook "ff3c7cfebe2a2a00"  # the special tile 
    area (0,0)-(7,7) 1010          # will also detect GRAB hits
    on hit [t] (x6) :anim6         # and the 'x6' will invoke shgob registered 'as 6'
    props fc0
 }

That should have done it. I could see the hand showing up, and getting away, but I couldn't ever hook to it. I couldn't get an evidence of why it failed, but I believe it is rooted to the fact that bilou's own bbox must overlap the tile in order to trigger the "on hit" transition. but since all the hitboxes with the GRAB flag tend to be off-center, the second collision (with state63 entity) doesn't occur because there's no overlap.

Alors oui, je vous balance le script directement dans le browser. Parce que ça ne fonctionne pas. Enfin, après avoir corrigé la gestion de l'animation pour ne pas dépendre des changements d'affichage (qui expliquent le bout de terre manquant dans le screenshot là-haut), ajouté une "bbox" à l'animation (pour que le code sache qu'il ne doit manipuler que 8x8 et pas 16x16), je finis par avoir un objet qui est créé tandis que le bloc devient inactif puis se réactive ... le hic, c'est que il faut pour ça que le "corps" de Bilou soit en contact avec le bloc interactif alors que ce sont ses *mains* qui vont essayer de l'attraper. Et la zone à attraper est réduite à 8x8, de toutes façons mal positionnée... bref, je n'y arrive que 1 fois sur 5-6, donc le joueur n'y arrivera pas.

Il vaut bien mieux que je me décide à dessiner un graphisme dédié (une racine ?) et que je fasse juste un GOB dédié... il y aura des import/exports mercurial à faire ... 

At some point I thought "hmm. I'll just have the little tile be a 8x8 hitbox in the middle of a 24x24 special box, that will do the trick", but it wouldn't work either: that 24x24 region around the corner of a pillar (for instance) would have "jump-through ground" on one tile, and "air" everywhere else... how could a single "props" instruction fix that ? okay, I could introduce "props(-1,0) fc4" to change one specific tile of the block but that sounds like the coding equivalent of "just stab me now" ... 

So, likely, I should forget about that "hook to tile" thing, accept that there's very little hookspots in the Dreamland levels anyway and kickstart my NDS to draw some root sprite in green.spr ... 

Spongebop-lifts

Entre les améliorations de mes outils de base pour qu'il redeviennent fiables, le tri de mes listes youtube et la lecture de ce chouette texte sur Mario World, je récolte les idées en vadrouille succeptible de faire un bon dernier-niveau-vertical pour cloturer School Rush.

Not being able to immediately start with the new level gives me the opportunity to let comments from "reverse design" and miscellaneous youtube video percolate in my mind to come up with building blocks for the vertical level of School Rush. For instance, Spongebop "moving platform" doesn't really fit a one-screen-wide level. It would be better to have it as an elevator. Good thing is that I actually have all the core logic ready, and just need at most one extra controller.

Ici, c'est SpongeBop qui s'y colle, reconverti en ascenceur ... la logique qui lui permet de se balancer en arc de cercle offre déjà tout ce qu'il faut pour détecter s'il faut accélérer ou décélérer le mouvement. L'ascenceur aura un mouvement un peu plus élastique qu'une traditionnelle plate-forme d'un Mario, mais ça ne me gène pas vraiment.

Riding Hints

Riding spongebops is not really a primary move in School Rush but still, it is important to know about it if you want to master the game. I managed to fit one more hint picture for the "magic book" on the bottom screen.

It was a bit more complicated to got it working this time: I needed a timer within the Hud so that we fall back to another hint when we stop bopping on a sponge. But as soon as you realize it is not the job for Bilou's state machine, the problem almost solves itself alone.

Si j'ai bien fait mes calculs, il est possible de terminer School Rush sans jamais avoir besoin de s'accrocher à une éponge. Celà dit, pour celui qui veut aller plus loin que juste "avancer dans le jeu" et a envie de devenir un Maître Bilou, savoir qu'il est possible de s'accrocher aux éponges est indispensable. Voilà donc une petite image supplémentaire pour le livre-interactif qui se déclenche lorsque Bilou rebondit sur une éponge.

Je voulais que l'image disparaisse automatiquement quand on aurait plus besoin d'elle. Ça aurait pu être quand Bilou retombe au sol, par exemple. Mais en fait, vu qu'il peut y avoir autant de rebonds qu'on veut et vu le nombre de variante pour "atterrir" qui existe dans la machine d'états de Bilou, le mieux c'est finalement que le retour à l'ancienne image soit géré directement par la classe HUD.

edit: that yellow mark on Bilou's head is the first step towards temporary sparkles when Bilou grabs a power-up that is now completed.

Bon pour le son!

Ok les gars: accrochez-vous bien à vos baskets, voici toutes les captures animées dont mon frangin aura besoin pour me faire la "palette sonore" de School Rush, ré-appliquant le procédé qu'il a mis au point avec Lazy Cow pour son jeu "PowerGlove" récompensé au concours de RGCD.

I tried several ways to get the right sound effects for Bilou: School Rush, and I ended up with the following observation: it must be tested both against the background soundtrack and against the in-game timing (and possibly the look) of the action. On the other hand, I'm not convinced that "playing" it is actually needed. So, following the advice of my brother, I captured an avalanche of animated gifs to be used as basis.

On va dire que ça compte comme "release d'anniversaire", mais j'espère avoir pour le courant des vacances de Pâques une release stable avec un vrai menu de sélection du niveau de difficulté.

Given the real-life interference of the last days (Brussels attacks seems to have damaged my laundry machine), this will be my birthday-gift-to-the-Internet for this year... but I now have all the pictures I wanted to implement the "difficulty selection" bottom screen, and I should have that built somewhere next week.

edit: quicklink to the latest download if you enjoyed this

Throw down.

Implemented a nice little feature, suggested about one year ago by my nephew: throwing things downwards. This way, when you're carrying a spongebop, you can save yourself from a deathly ink pit by throwing down the spongebop you're carrying... and safely landing on it.

Aah ... un petit ajout rondement mené. Ce sera un peu chaud à maîtriser (bas + B pendant un saut), mais ça permettra au joueur qui le tente de se sauver inextrémis d'une mort par noyade en lançant un SpongeBop transporté vers le bas pour atterrir dessus plutôt que de tomber dans l'encre.

Vieux vieux pixels ...

Quand je vous disais qu'au début de l'aventure de Bilou, je réalisais mes décors sur des feuilles millimétrées. Je vous ai retrouvé le tout premier "tileset" de la green zone...

Here come some oldies ... tiles on a millimeter-grain sheet of paper, waiting to be converted into list of numbers. 

That's how you develop video games when you're allowed to use the computer at most 1 hour a day... and don't have a colour screen. 
Monsters were designed in the same way, but it wasn't easy to make sure animations would work well. That's why I shifted to modular animation instead for the BASIC version.

Et en bonus, le tout premier appleman, le boss de la green zone et SpongeBop du temps où elle trainait par terre.

spongebop virtual walls.

One evening after the other, my "visual todo list" for School Rush is painting in green. Just like dumblador, Spongebop now has limits, including a virtual floor that will prevent Bilou from falling further when the Spongebop gets jammed. All you can do then is throwing it away to get loose.
L'avantage de cette carte des "todo", c'est que j'ai plus facile de faire une petite avancée chaque soir. Ce soir, c'est essentiellement la "cage invisible" qui empèche Bilou de s'écarter arbitrairement de l'éponge qu'il transporte.
Allez, je suis presque prêt à attaquer les power-ups.

edit: ... check, prêt pour les power-ups ^_^

Air Grab

On s'approche, on s'accroche ... Les travaux sur les zones de collisions contrôlées depuis l'éditeur d'animations portent enfin leur fruits. Il y a maintenant un état dédié dans le comportement de Bilou pour "je pirouette en l'air pour attraper quelque-chose".

At last, the track for controlling hitbox activation through animation is paying off. I have been able to give Bilou a dedicated state where he's checking three directions for something to pick or ride on. I intend to use that both to ease swinging on spongebops and allowing high-paced dumblador grabbing. In the "anniversary level", using spongebop to move along was planned as the hard path. The way that the skilled player would prefer because it leads to faster results as opposed to wandering on the ground. They still had that role when I added "*deline's level" as preliminary experience to the "true level" of the school zone, but the levels are definitely more fun to play when you mastered spongebop riding (left alone the 'sponge jump'). So I want to make more players try to use them.

• Dedicated "grab-mid-air" animation and gameplay state makes it obvious to the player that something happen, and how it spans in space-time.
• The animation itself is fun. J.l.n, my 2-year-old boy goes laughing when he realize he can press A/B buttons to make Bilou roll mid-air in a flash. And fun is important in a video game: that's our primary reward.
• Moving from demanding hitbox (purple one on picture below) to welcoming hitbox (light-blue one) will make it more open to learning.
• You'll still have to learn how your speed evolves with the swing if you want to reach high places or gain stupendous momentum. The potential for power-play is not lost.

Au-delà de la performance technique, l'idée est d'agrandir la marge de manoeuvre des joueurs qui veulent s'accrocher à une éponge. J'ai tenté de reporter sur l'image ci-contre la marge de manoeuvre avant (en mauve) et après (en bleu clair). En rendant le fait d'attraper l'éponge moins élitiste, j'espère -- selon les conseils de KirbyKid -- les rendre aussi plus amusantes.

Une chose, par contre, n'a pas changé: Bilou est toujours centré au-dessus de l'éponge quand il s'y accroche. Du coup, agripper une éponge alors qu'on arrive à côté d'elle produisait un décalage brusque de Bilou. Je tente donc un élément inédit dans le gameplay: une transition pendant laquelle Bilou, roulé en boule pirouette pour revenir par-dessus l'éponge mais dans une forme de pilotage automatique. Il est déjà lié à l'éponge et se dirige automatiquement vers elle, même si elle fait demi-tour et s'y accroche dès qu'il entre en contact avec elle.

I had one concern, though, about the immediate coordinates update that makes Bilou appear centered on top of the spongebop immediately after you hit its side with your hand. Piet and Pierrick, both co-author of the very first Bilou game, suggested that I should "cheat a bit with physics so that the game gets easier for the player", but I'm not confident with such approaches. Yet, it wouldn't be fun to get merely a bounce if you hit the spongebop from the side when trying to grab, so I give a try something new in Bilou's behaviour: temporary automatic control. When you'd expect Bilou to grab and climb the spongebop, he'll actually do it by a rolling bounce in the air where he'll mag(net)ically align to Spongebop position and start riding when reaching the proper position. Accelerations faster than what you could reach manually are tolerated in this state, and all you have to do is hold the (B) button down and hope for hitting no ceiling.

I'll submit that to the S-testing team tomorrow. That may be the biggest improvement since the release of "School Rush" game. Stay tuned.

Amélioration Spongebop ...

Je me suis amusé l'autre jour à imaginer comment les SpongeBops pourraient être plus interactives dans le jeu. Les faire flotter sur l'encre, bien sûr, mais aussi les transporter comme les dumbladors. Et pourquoi pas s'en servir également comme d'un "parapluie" contre les jets d'encre ?

So far, we can grab spongebops while they're swinging, and use them to reach higher places ... but that requires significant learning of the game mechanics. Dumbladors can be used to detach them but so far, it doesn't bring much difference. I wanted to add "carrying" and floating, which is now ongoing. I'd also love to make carried sponge a protection against falling ink droplets...

• [done] pick up and throw spongebop
• [done] spongebop floats on ink
• [done] ink droplets stops on spongebop
• [done] pendat turns back when walking into a spongebop.
• [todo] floating makes spongebop move up and down
• [done] stands on floating spongebop. Don't bounce.
• [done] better physics when thrown
• [done] Bilou stays hung when Spongebop is jammed.
• [done] blador-like virtual walls to avoid Bilou holding the spongebop from far away.

Kirby Kid's Advice: Inconsistent Spongebop

Inconsistent interactions with yellow things. The yellow swinging enemies are neat looking and they have neat physics to them. But interacting with them is very inconsistent and too complicated. It's hard to stay on top of them. It's hard to get the big jump off of them. And the momentum of their swing doesn't transfer to the player at all.

Let's first see what "inconsistent" means in this context. Kirby Kid validated the two definitions I formulated as below:

A mechanic is consistent with regards to 2 object if

• applying it the same way on the two objects leads to the same result. E.g. slashing something with the sword breaks it into bits in Zelda series. That works on bushes, jars, skulls and even rocks in some games.
• when it leads to different result, the objects shall be sufficiently different so that the player can easily tell what result it will get from passive analysis of the object. E.g. Jumping on an ennemy in SMB always attacks the ennemy unless the ennemy has spikes on his head. Moreover, the ennemy will always be defeated unless it is shelled.

A gameplay element (applying mechanic A on object B) is self-consistent if

• it always produce the same result (e.g. bounce by 3 blocks height)
• when producing different result, the player can relate the cause of this difference to visible difference of state. E.g. a spring that may be loose or compressed will throw you higher if compressed.

Pour corriger mon éponge-qui-se-balance, aussi connue sous le nom de "Spongebop" ou "Bop, l'éponge", je vais avoir un peu plus de mal. Kirby Kid lui a diagnostiqué un problème de manque de cohérence, ce que je peux traduire de la façon suivante: il n'existe pas de manière claire de savoir quel sera le résultat d'un rebond ou d'un balancer qui fait intervenir l'éponge. Kirby Kid mentionnait aussi le fait qu'il est difficile de déterminer si l'éponge va nous repousser vers le côté où si on va pouvoir atterrir dessus. La difficulté principale sera psychologique: dès les premiers coups de crayons, "Bop, l'éponge" est un personnage (et pas une plate-forme) au comportement erratique. Il sera utile, mais il faudra s'en méfier.

From the start I have designed spongebop to be somewhat chaotic, which makes it appear mostly only on the "hard path" of School Rush game. But chaotic must not mean "totally unpredictable". There are two moves that are expected with a sponge bop. The first is to use it to gain height, the other is to clear a larger distance with a jump. Both are based on the fact that, when you press A while un-grabbing a SpongeBop, its current velocity is added to the one of your jump.

Initially, I thought Kirby Kid was mostly criticizing the difficulty to do the first move -- gain height -- because when SpongeBop is  almost idle, the only moment when you can "jump off" is when it moves upwards. But getting that is more a matter of luck than skill: because oscillations of Spongebop across its equilibrium are small and that the "auto-bounce" that happens when you "land" on it can hardly be controlled, the best you can do is to try again and again until it works. You cannot even spam the JUMP button because you'll have to hold it down once successfully bouncing off if you don't want to cancel your jump.


Voyons un peu les interactions que permettent Spongebop:

• SB peut pousser Bilou bas d'une plate-forme ou l'interrompre dans son saut si le contact est latéral. Incohérence: c'est un rectangle qui nous repousse alors que SB est un patatoïde protubérant.
• Bilou peut rebondir sur SB s'il tombe dessus et rebondir plus haut s'il appuie sur (A) avec justesse. Incohérence: il est difficile de déterminer la hauteur qu'aura le saut effectué dans la plupart des cas.
• Bilou peut s'accrocher à SB pour franchir plus facilement un trou. Incohérence: il n'est possible de s'accrocher que lorsqu'on tombe, et pas juste après un rebond malencontreux.
• Bilou peut faire un long saut en avant en appuyant sur (A) au moment précis où l'on lache l'éponge. Incohérence: rien n'indique pour celui qui n'a pas encore suivi de cours de balistique (ou fait trop peu de balançoire) que la fin du mouvement est un mauvais moment pour cette manoeuvre-là.

 I've been more surprised to see Pierrick failing to clear a large jump by using SpongeBop's swinging speed. He was persistantly trying to jump *at the end* of the swing, but physically speaking, bop's momentum is nul at this time. So indeed, it doesn't transfer to your character.

The way Spongebop behaviour lacks consistency can be summarized as such: when you jump off a Spongebop, the velocity you have will depend on Spongebop's instant velocity. Due to its physics, Spongebop velocity is constantly changing in 2 dimension, meaning that it takes some careful study (or prior knowledge) to pick the moment where you'll get the desired behaviour.

encre ? yeah !

Je ne veux pas me contenter de flaques d'encres immobiles pour la School Zone de Bilou. Je veux pouvoir en profiter pour construire des puzzle autour du principe des vases communiquants. Je veux aussi pouvoir utiliser un seul niveau qui monte pour tout le niveau, histoire de proposer des niveaux à terminer dans un temps limité.

So far the ink is static. Puddles where you shouldn't fall in or some bottom-of-level deathly trap. I want to go beyond that. One of my favourite puzzle elements in Fury of the Furries was involving sand or water level that you raise or lower to transform the level. It re-appears in two of the levels I had envisioned for the School Zone, and it would be the base for both deep-ink-pit and rush-to-completion arcade-games I have in my furnace. Several elements need to be sorted out to get that working, though: rendering, interaction with monsters and implementation of the levels equilibrium mechanics.


Côté implémentation, j'ai écarté l'utilisation d'un plan dédié (je n'en ai plus). Combiner une ligne de sprites pour l'animation de la surface avec un remplissage de l'arrière-plan par des pavés tout noirs pourrait faire l'affaire quand l'encre va toujours vers le haut, mais pour des vases communiquants, qui pourrait "réparer" la map quand l'encre descend ? ... A moins que la map complète en mémoire ne soit jamais dégradée, et que seule sa copie à l'écran ait des pavés noirs. Mais Infinimap n'est pas conçu dans ce sens-là. Des gros sprites partout, ça ne marchera pas bien. Le plus souple, ce serait sans doute de règler ça à coup de polygones.

Rendering still has a few options possible on the DS, but in my current setup, the constraints start to pile up. I cannot have a dedicated BG layer. I don't have any left since I introduced 3D objects, which need their own layer. I might be using 3D polygons when the ink sits "between" the two layers of the playground -- that's for Deep-Ink-Pit and Bilou's Adventure. When the ink rise up through the whole level as in Rush-to-Completion, I'd better use the "window" feature (or possibly a raster interrupt to affect background priorities on the fly). For the animated surface of the ink, sprites are the best I can think of.

Ensuite, il y a les personnages. En remplaçant les codes du bloc d'encre sur la map du niveau d'*deline, j'ai pu faire en sorte qu'un taille-crayon lancé dans l'encre fasse des gouttes. C'est aussi un premier pas pour faire en sorte qu'une éponge qui tombe sur l'encre flotte (enfin, à moins que Bilou ne se tienne dessus assez longtemps).

Spongebops and other monsters might have to interact with the ink. I made a first step with Dumblador getting "killed" when touching the ink and generating droplets. That required to change the tile properties so that monsters can also interact with the ink. Initially, I thought making spongebop floating on contact would require some intermediate "liquid" tile before the interactive "kill-Bilou" blocks, but it turns out that the same interactive block can also trigger state transitions such as fall/float for spongebop. neat.
That's actually very good news. It means I don't *need* the ink to be tiles in order to trigger the floating. A GOB with the appropriate collision mask will transparently produce the very same kind of state transition.

Je pensais au départ ajouter une couche de tiles "flotteurs" par-dessus les tiles qui blessent Bilou, mais le même code "F_INK" peut à la fois se traduire en une transition tombe/coule pour Bilou et tombe/flotte pour l'éponge. En en faisant une collision ordinaire (et pas un type de tile spécifique, ce que je garderais pour l'eau), ça veut dire aussi qu'un GOB qui possède la bonne zone de collision F_INK peut interagir avec les éponges, y compris pour l'encre qui monte et qui descend.

A partir de ce moment-là, je peux commencer à concevoir les réactions "vases communicants". Un objet-déclencheur peut forcer les deux GOB-surface à se mettre en mouvement. On peut aussi les lier l'une à l'autre pour leur permettre de s'équilibrer, avec une variante du contrôleur qui ajuste la distance entre Spongebop et son pivot. Reste un élément délicat: comment faire en sorte que les niveaux d'encre se mettent en mouvement simultanément ? Un coup de sonde à l'aide d'une zone de collision bien calibrée pourrait faire l'affaire (de la taille du bouquin central, par exemple), sauf que les zones de collision sont normalement définies pour un état donné, pas pour un objet donné.

If the part of the ink that's animated is allowed to be a GOB, the use case of ink-level-equilibrium turns closer to something GobScript can readily handle: it mostly comes down to two ink-surface objects that adapt to each other so that they reach the same level, possibly assigning them top speed that depends on the width of the pit they're in. Then, I have to figure out a way to kick them so that they start moving simulatenously (e.g. after Bilou opened some path between the two pits). I could build something inspired from Badman II boss rooms in RSD Game-Maker, with a lock-type block that shoots invisible trigger-sparks moving along the same kind of directional block as those controlling inkjets.

J'ai donc commencé à construire quelque-chose qui fait fort penser aux boss de Badman II: faire en sorte que la serrure génère des "étincelles déclencheuses" (invisibles) vers la gauche et la droite et placer le même genre de blocs-directionnels que ceux qui contrôlent les déplacement des encriers pour faire en sorte que les GOB-étincelles atteignent simultanément les deux surfaces pour les mettre en mouvement.

If that's funny to demonstrate that the a-priori simple engine can handle elaborated things, it would quickly turn into a nightmare for any sophisticated situation, like the twin-corks in Remi's level (where each cork might trigger raising ink from the other's position). You'd end-up crafting chuchu-rocket puzzles on your map and hope the timing you computed in your mind is correct when launching the level. As a second thought, I'd rather have the surface GOBs both attached to the "lock" and start raising when this link is lost. Yet, it would be nice to have test-zones that can be defined through GOB variables so that the level editor can precisely define a trigger region for each of them (but it's unclear I have true *need* for that in any of the level I designed so far).

C'est rigolo un instant, et ça fait plaisir de constater que les abstractions construites jusqu'ici sont suffisament Turing-esque (comprenez, expressives) pour ce genre de déviance. Mais soyons clair: si on veut passer à un niveau un tout petit peu plus élevé -- les bouchons jumeaux du niveau de Rémi, par exemple -- on peut rapidement se retrouver à construire un puzzle à la chu-chu-rocket qui va promettre de sérieuses migraines au moment de la mise au point.

Il y a bien une autre possibilité: quand un Gob (ici, la surface d'encre) est attachée à un autre (la serrure), il reçoit un évènement si le Gob de référence disparaît. On peut alors faire monter le niveau d'encre suite à la disparition du bloc-serrure -- ou du bloc invisible qui s'est fait détruire par le bouchon-qui-s'enfonce. La bonne nouvelle, c'est que l'éditeur de niveau supporte déjà ce genre d'approche. La moins bonne, c'est qu'un Gob ne peut être attaché qu'à un seul autre. On saura donc faire des niveaux avec 2 bouchons, mais pas avec trois. Cela dit, ça mériterait vérification, mais je pense bien que je dois pouvoir m'en sortir avec juste "2 bouchons" dans tous les niveaux dessinés jusqu'ici.

3D: X Why Z ?

On me demande sans doute à raison pourquoi m'attaquer à la 3D maintenant (alors que j'ai un premier niveau qui est entre alpha et beta) ... "des effets d'éclairage?" ajoute mon frère ... Plus que ça, en fait.

Wihin 8 hours after publishing my last post, I've got two person wondering why I need 3D now and how I'd use it. Well, there's much more than "lightning effects", as far as I'm concerned:

SpongeBop's thread: a single 3D polygon, extremely thin and flat, can be used to display SpongeBop's link with its pin, helping the user to visualize the sponge's trajectory.
Mon premier test, c'est le "fil" de Bop L'éponge, histoire qu'on visualise mieux sa trajectoire et qu'on cesse de la prendre pour "un nuage jaune". Il est construit tout simplement avec deux polygônes plats et non-texturés, mis "en sablier". Je n'ai pas résisté à la tentation de l'implémenter avant de finir de traduire ce post. Ça n'est pas encore propre (un avocat des model-view-controller s'étranglerait en voyant le code) mais ça prouve le concept.

Large smashing books come later in the level for which I have design on papers. I also have "large books" that can be pushed and dropped to create platforms. This involve a level of rotations and deformation that stem for 3D objects. Without them, their respective levels are as meaningless as a Badman episode.
J'ai dans mes carton un niveau qui repose essentiellement sur des livres-écrabouilleurs qu'il va falloir éviter comme des thwomp. En fait, j'avais construit pas mal de scénarios autour des livres pendant la phase où je réfléchissais à un niveau complètement 3D sur PC en 2004. Ils sont sans doute réalisables sans utiliser le hardware 3D, mais ce serait se chatouiller pour se faire rire.

In both the Bilou's Book and design documents, pendats feature a rich set of poses. Right now, they merely step forward, and the animation when they turn back is essentially cheating. I want them charging Bilou, laying on the ground when stunned and pausing to check left and right locations. Not only that involves rotations, but also twisting that affine sprites cannot offer.
Plus déterminant encore: les crayons-soldats. Je ne saurais pas faire beaucoup mieux avec l'approche actuelle intégralement par sprites dessinés à moins de changer fondamentalement le moteur d'animation des sprites pour passer à quelque-chose qui ressemble davantage à Donkey Kong Country. En 3D, je n'ai plus qu'à prendre 6 polygônes non-texturés et laisser la console gérer les rotations et les effets d'éclairage, le reste étant gardé sous forme de sprites affichés par-dessus les polygônes.

Rotating Rulers  -- acting as stretch-and-squish platforms for more challenging climbing action. That level element is possibly what best defines the design for future Bilou's Adventure game, so I really want to have them done. Granted, I could emulate them with flat, smaller platforms that move back and forth synchronously.
Un autre niveau que j'aimerais beaucoup réaliser et dont j'ai déjà parlé fait intervenir des "règles qui tournent" et qu'il faut escalader bien qu'elles s'escamotent dans les recoins du niveau. Ici, on pourrait imaginer un hack à base de sprites qui bougent en coordination, mais ça rendrait nettement moins bien pour 4 polygones (texturés sans doute, cette fois).

Bookmarks that move like vines in Pharaoh's Return. It's not clear that such giggles would bring significant gameplay enhancement, but they would make the School Zone more credible than if cloth-made bookmark where simply standing stiff while you grab them.
Il y a aussi les signets des livres, que je souhaite transformer en corde. Après avoir vu le prototype de Lazycow, mon frère était d'accord avec moi: ça en jette et ce serait quand même largement un plus d'avoir ça dans Bilou, même si au niveau "fonctionnalité du niveau", ça ne change pas fondamentalement la donne.

BangBash's swinging move involves rotation around the Y axis. This will probably be the most demanding item, asking for a complete update of AnimEDS to look more like that old "sketchup compo entry".
Enfin, il y a BangBash, le personnage qui frappait les trois coups pour l'ouverture de ce blog. ll a normalement deux attaques prévues, l'une frontale qui pourrait être réalisée (pas joliment du tout) avec des rotations de sprites et l'autre, tournoyante et latérale (un petit côté double-balayage de Guile) qui impose la 3D d'une façon ou d'une autre.

Voilà. Ça m'aura couté quelques heures de sommeil, mais c'est (fait) et dit.

Toujours plus haut!

S'il y a une chose à quoi les éponges de la School Zone ne sont pas encore prêtes, c'est bien à servir d'ascenceur dans "Deep Ink Pit". Plate-forme mobile par-dessus l'encre, ça oui. Avec un bon timing pour s'y accrocher puis sauter, on peut prendre pas mal de vitesse horizontale -- et c'est assez fun. Mais monter, ça ... c'est une autre histoire. Au point qu'aux endroits où il fallait passer d'une éponge à quelque-chose d'autre, j'ai fini par amener la trajectoire presqu'au-dessus de l'objectif, qu'on ait plus qu'à se laisser tomber.

With the anniversary level, Spongebop no longer directly hurts. There binding to a pin can be modified by the player too, to the point I wonder whether I should allow Bilou to carry them along. There's one thing they're still terrible at: allowing you to climb up! Too bad: that's what they should provide in Deep Ink Pit. With training, one can get significant horizontal speed when letting the sponge loose, but if you manage to find an idle sponge in the level, you may have hard time gathering the bonuses that float over it. 

While investigating the reasons, I figured out that the rule that makes SpongeBop "slightly bounce when you land on it" interferes with Bilou's attempt to use bop'd ennemy's vertical speed as an extra bounce impulse: first, the sponge gets a push downwards due to its collision with Bilou and then Bilou's jump strength is defined as default_impulse + other.yspeed. I cannot change that ordering: it is defined by who's active (Bilou) and who's passive in the collision. What can do, however, is to arrange a variable where the vertical speed of the monster is preserved (or an impulse bonus of some sort) and ensure that vertical speed is only used as a booster, never to reduce the impulse.

En fait, j'ai presque tué toute possibilité de rebondir au moment où j'ai ajouté la règle "l'éponge reçoit un choc vers le bas en cas de contact" pour donner un effet plus "élastique". Bilou ne peut du coup plus bénéficier de la vitesse montante de l'éponge pour sauter plus haut puisqu'il vient de lui forcer une vitesse descendante! J'imagine que c'est le genre de couac qui a poussé les auteurs de Frogatto & Friends à construire leurs scripts à grand coups d'expressions-qui-renvoient-des-affectations. Ici, il ne me restera qu'à sauver l'ancienne valeur dans une autre variable de Spongebop pour que Bilou puisse y accéder.

2 days late

Making sure Blador can be used as a weapon, cleaning level ... that shall be done. Quite amusingly, the fact that a testpoint is still needed for monsters because they will FAIL to walk on ground only when they've advanced *past* the last pixel of the structure they're walking on also means that I can set a second test point *deeper* in the ground and force the monster to turn back before encountering "fragile" ground that is only 1 solid-tile-high ... or as in the case of the introductory pendat, artificially introduce "fragile ground" here and there to confine him.

I located and fixed the root cause of "disappearing monsters due to excessive load on the GPU", which was actually only present in runME, and not in the game engine or the game data ^^".

J+2. On peut utiliser les tailles comme arme, et le niveau a été "nettoyé". Ce qu'il y a d'intéressant avec le système des "test points pour les monstres", c'est que si je met un 2eme point-test plus "profondément" dans le sol (disons dans le 2eme tile du sol), je peux alors créer des zones-tampon à l'aide d'un 'creux' sous la première ligne de tiles solides.

J'ai réglé le problème des sprites hardware insuffisants (mais comme vous lisez la version française, vous le savez déjà ;). Si j'ai l'occasion j'ajouterai ce soir les collisions pendat/taille lancé et gomme/taille. Petit sondage: est-ce que les éponges devraient blesser Bilou ou juste le repousser ? (résultat: juste repousser. 100%)

If I manage to find some time tonight, I shall code the reaction of pendats and rectoverso to thrown bladors. Is Cyril right thinking that a Spongebop shouldn't hurt Bilou ? Give me your feeling on the poll before the demo is out!

Poll Outcome: 100% (4 person) voted for SpongeBop that doesn't hurt, but merely bops you away.

5 days left

I have some pixels for the "cork platform", I have tunable spongebops. Eraser jumps will not work very well with "invisible walls" as those would act as wall that make no physical sense for the player (unlike Rayman's airborn anti-toons and platforms trapped in cages). Instead, I could have the "prepare" state of verso testing the ground where the next jump should end, and turn back if that location isn't safe.

Would such a remote testpoint work ?

Plus que 5 jours avant la fin du mois de septembre, celui qui est 20 ans après la 'naissance' de Bilou. J'ai dessiné une 'plate-forme en liège', j'ai des éponges au mouvement ajustables. Les gommes-sauteuses ne marchent pas terriblement bien avec les 'murs invisibles' , donc je rajoute un état où elle se prépare à sauter et où elle 'sonde' le sol pour décider de faire ou non demi-tour. Si ça marche, ce sera un record battu pour les testpoints.

7 days left.

I got LEDS working almost fine on the green DS with the expanded and reordered animation sheets. I went through trivial fixes such as "animation X shouldn't loop since we depend on it to be done before switching to another state", etc. In-editor GOB linking did worked, although producing curious effects: a Spongebop was found moving through the level backwards because the nail it's pinned on was cloned from an inkjet and therefore had an initial horizontal speed :P

Cette fois, c'est reparti. L'éditeur de niveaux et le moteur de jeu intégré à "runME" sont capables de gérer les nouvelles pages d'animations correctement. Je peux ajouter les petits raffinements du style "faire faire demi-tour à la gomme" ou "se relever après s'être ramassé un coup", etc. Il me reste 7 soirées pour compléter le comportement de la gomme, de l'encrier et du crayon et dessiner le "bas" du niveau anniversaire.

At some point, it will save time to be able to see the initialization expression of one GOB, clear it if needed (and later, to write it from scratch, of course). A way to have self-initializing spongebop would also help: currently, they do not preserve the "energy" they're given initially, and so their speed is "reset" to a given swing value when they're crossing the vertical line. Unless this is fixed, sponges with a too-short thread will break loose and sponges with a too-long thread won't swing as far as the level design states.

I still wish Bilou could get more height when leaving a grabbed sponge, too. And then, there's pendat.cmd virtually inexistant, verso.cmd hoping for more freedom, inkjet.cmd needing to settle down and some cork-platform to be drawn.