Blador vs. Spike

While I was checking collisions/interactions were still working fine after introducing the G_FIGHT group, I noted something not so right about the dumblador. Something I don't think I've ever blogged although it was available since the anniversary level: throw a dumblador into pencil spikes and it will snap to the spike it lands on, turning itself into an additional safe platform.

But with the current engine, you may end up with the blador "waking up" and start walking within spikes. You may also see it stopping completely misaligned and almost everytime, it would be too low compared to where it used to stop.

I first tried to tune collision areas, but that did not seem to help. I checked some values in the DDD debugger, but it's a bit of a lottery: you can't really tell in advance whether you'll find yourself in an interesting case. Note to future self: there are save states in desmume! (In such a case, I should have saved the emulator state before throwing the blador, save again when the breakpoint triggers, fast-forward to see whether the condition will happen and only then go back in time to either review the step-by-step behaviour or change a little bit the initial conditions and try another throw).

But I had not came back from the future to leave myself a note yet, so instead, I started adding coordinates of colliding entities in the "gobscript expression debugger" so I could have something that is stepping faster than DDD, and present precisely the information I needed (although I could have used it in base 10 :P).

And there I realised that when the blador ended up misaligned, it was colliding with a spike whose position was a mere multiple of 8 rather than a multiple of 16 ...

Back in SchoolRush times, it was mandatory to be a 16x16 pixels block if you wanted to have special behaviour such as hurting the player. But it changed with the tiled engine revision where each individual 8x8 tile can be of any 64 special type (or any of the other 192 "normal" types).

Larger blocks are still possible thanks to "refer too" special tiles that point towards the top-left corner tile of the block. When loading an older map, the conversion is automatic, but when I created the "school teleporter" room for the 3-rooms-demo, I just added 1-tile spikes instead. With a small change to the Level Editor, you can now press A to reveal the redirecting arrows (default behaviour is to mirror the pink tile instead). That should make such errors easier to spot in the future, if I ever make them again.

So the script for the dumblador now looks like

$THROWN :anim3 {
  using gravity(24,1536)
  testpoint off (8,18)
  test 0 (0,0)-(8,12) ${F_BAD|G_FIGHT|F_WEAPON} //# weapon against other monsters.
  test 1 (0,15)-(16,16) ${F_BAD|F_PLATFORM};
  area 0 (0,0)-(16,12) ${F_ISINK} //# deleted-by-ink
  area 1 (0,0)-(16,8) ${G_FIGHT|F_HURT} // # stand-on-spike
}

$THROWN->$STUNSTAND on hit1 (0 :1 0 :0 Lc $vPlatform(2));
$STUNFALL->$STUNSTAND on hit1 (0 :1 0 :0 Lc $vPlatform(2));

and the script for the pencil spike looks like

 block 21 {
   is spike "0101030307070f0f"
   area (7,0)-(8,16) 10010010 # hurts
   on hit [0] (t)
 }

 Together, they allow to get a functional blador-align-on-spike (aligning is performed by the Lc opcode), but there's still one thing to fix if I don't want to see dumblador waking up and start walking on pencils: duplicate the $STUNSTAND state into something like $SPIKED, while removing the "get feet" area. But well, a remaining glitch makes some more fun for ScreenshotSaturday ;-)

 

bug on blador

J'ai tout les morceaux pour qu'on puisse à nouveau utiliser la map "anniversaire" de la school zone dans l'exécutable de "Three Rooms Demo" ... mais quand je veux le faire tourner, on ne peut pas vraiment dire que les choses se passent merveilleusement bien. J'ai cru au départ que c'était des choses que j'avais "cassées" en développant le "soft landing" des furblocks (la motivation n° 1 à faire revenir ce niveau *maintenant*, c'était précisément de vérifier l'absence de régressions). Et des choses qui vont de travers, il y en a quelques unes ^^°.

I wasn't 100% confident with the changes I made to special flags used to implement the furblock... So as I'm entering one week off, it seemed appropriate to ensure I have all the required material to revive a School Zone level where all the "monsters" are featured and ensure there aren't regression. So here's the "anniversary" level again.

Mais pour certains bugs, un petit voyage dans le temps avec Mercurial ne laisse aucun doute: ils étaient déjà là avant. C'est notamment le cas avec dumblador, et Bilou qui tout d'un coup se retrouve bloqué et immobile s'il lui atterrit dessus au moment où il devrait pouvoir servir de plate-forme...

Cette fois encore, c'est dans ddd que la réponse est apparue. Si le n° d'état renseigné par InspectorWidget (bi28) est pour "RIDLE", l'affichage de Bilou en train de tomber n'est pas un glitch: on a jamais su rester sur le taille-crayon parce que le contrôleur "onpath" estime qu'il n'y a plus de plate-forme... la faute à une modification pour crocform qui ne s'est pas re-propagée jusqu'à dumblador: le choix du bit d'état qui indique si on est bien sur une plate-forme ou non ...

And well, we do have some regressions, and some of them are quite older than the furblock modification. Today I repaired the ability to stand on a stunned blador, which should have been updated after I implemented the pyramid "collapsing" platform: it reuses bit-testing that allowed stacking dumbladors, but for obscure internal reasons, it did not use the same bit to declare that the platform is indeed valid. Tricky to find, but easy to fix.

Trotôptimiser

Je voulais faire une pyramides de taille-crayons. Quelque-chose de fun, original et un peu inattendu pour récompenser les joueurs persévérant. Mais voilà. ça veut dire beaucoup de sprites ... beaucoup de collisions ... alors est-ce que le moteur de jeu va le supporter. J'ai passé déjà quelques après-midi et cogiter la chose.

Basculer entre tiles et sprites, peut-être ? ou simplement entre une version mono-sprite du taille-crayon assomé et une version trois-sprites comme celle utilisée dans le reste du jeu ? Oui, parce que les pieds de taille-crayon sont animés avec des sprites séparés histoire de pouvoir faire plus d'étape d'animations avec le même nombre de pixels, mais le moteur de jeu ne supporte pas qu'un objet existant doive acquérir ou libérer des sprites hardware au fil de son existence. Quand le taille-crayon est assommé, ses pieds sont cachés par-derrière lui alors que deux nouveaux objets d'un seul sprite sont créés pour les pieds projetés au loin.

J'aurais donc pu faire ma pyramide avec des tailles-crayons-d'un-seul-sprite. ça m'aurait permis d'en faire tenir jusqu'à trois fois plus à l'écran. Sauf que quand Bilou transporte un taille crayon, les pieds-cachés deviennent les mains de Bilou tandis que les sprites hardware de Bilou sont temporairement désactivés. Ce n'est donc pas quand le taille-crayon reprend ses pieds qu'il faudrait passer (en détruisant un objet pour en reconstruire un autre) à 3 sprites hardware, mais bien quand on ramasse le taille-crayon pour la première fois.

Oui mais et si le joueur réempile les taille-crayons ailleurs, alors ? on va se retrouver avec le même nombre d'objets mais cette fois à 3 sprites ? ça va mal finir ça.

Heureusement, un premier test montre qu'on tient toujours les 60 images secondes avec une trentaine de taille-crayons à l'écran rien qu'avec l'objet de base, tel qu'il intervient dans le jeu. Même les empilements ne posent pas de soucis, sans doute parce qu'en réalités, ils ne sont pas gérés comme des collisions.

A la place, c'est le mécanisme de plate-forme mobile qui entre en jeu, dans lequel on se contente de vérifier la relation avec l'objet auquel on s'était attaché précédemment. Les collisions proprement dites (nécessitant de comparer chacun des taille-crayons avec chacun des ennemis) n'aura lieu que depuis les tailles crayons qui tombent.

Je m'inquiétais donc pour rien. Par contre en en profitant pour mettre un générateur de pieds-baladeurs dans le niveau, J'ai compté jusqu'à 28 pieds générés sans que l'émulateur ne tombe sous les 55fps (la DS serait donc probablement toujours à 60), mais par contre après ça, il y a trop d'objets à gérer et certains d'entre eux ne sont tout simplement plus affichés (un bug bien connu du moteur de jeu actuel, contre lequel il n'y a pas grand chose à faire à part éviter d'en arriver là par le level design). Bon à savoir je calibrerai mes générateurs de pieds en conséquence, un peu comme j'avais fait avec les générateurs d'applemen dans Apple Assault.

edit: une jolie pile d'une 30aine de taille-crayons, un personnage de chaque autre type et quelques pieds baladeurs ... ça tient toujours.

A dos de blador.

Mes taille-crayons, une fois en mouvement, font d'assez mauvaises plates-formes, en vérité. Celà vient de leur animation. D'abord (comme la plupart des animations de marche), elle va retarder certains mouvements pour consommer d'un coup 2 pixels de déplacement après être restée immobile pendant 4 images si la vitesse de consigne est d'1/2 pixel-par-60eme de seconde. Ensuite, parce que contrairement à Bilou, le déplacement de dumblador s'interrompt pour une courte pause avant de reprendre: non seulement ce taille est trop "dumb" pour mettre un pied devant l'autre, mais en plus, il lui faut un moment pour se souvenir de ce qu'il convient de faire pour finir le mouvement qu'il a entammé. Autant dire qu'il vaudrait sans doute mieux pour une "pile de dumbladors" de tomber d'un étage quand un des tailles-crayon se remet en mouvement plutôt que de jouer à rajouter des "selles invisibles" pour offrir quelque-chose de plus souple.

Non. Je préfère tenter maintenant de faire tenir Bilou sur un taille-crayon à l'arrêt. Et là aussi, j'ai du travail: il faudra veiller à

• forcer une mise à l'arrêt complet au contact, puisque le contrôleur "stopper" sera court-circuité,
• "détacher" Bilou de son support lorsqu'il saute,
• compléter le contrôleur "onpath" pour qu'il provoque le détachement lorsque Bilou n'est plus par-dessus le chemin.

This has been a "known issue" since April 2014, and it still wouldn't be easy to fix it today: you can walk on a Dumblador (after stunning it) as if it was a platform, but as it wakes up, weird things occur that make Bilou slightly slip forward and eventually fall of the blador. Initially, it was also affecting stacked dumbladors, so I added a rule to "break" the stack as a blador wakes up.

The core of the problem comes from the fact that a carried GOB will adapt to the "moving platform"'s speed in order to give the illusion of friction, but when it comes to dumbladors, the speed and the effective motion quite disagree. First because - as with any WALKing GOB - the horizontal speed isn't constant, and second because I introduced a small pause between two steps for the blador, to reinforce the feeling of "dumbness". As a reminder, the GPath abstraction is as follow:

• GameObjects have an 'onpath' pointer, which complements the 'attach' pointer (to a gob).
• GobArea now implements the (horizontal) GPath API, returning always the same y coordinate, and checking that you're in the desired xrange.
• 'Ap' in a gobexpression will attach the object to a "path" rather than to an object, the area that triggered the collision will be used to define the new path.

I gave path-capable engine a try back in february 2013, but that was nothing I could test. The idea was to support both NSMB-like angled mushrooms and (softly) swinging ropes. The current code with dynamic GPath comes from June 2013 and has still to be complemented with a controller that uses it.

It's all described and motivated in Walking on Platforms

drop your weapons

One of the most vexing gameplay bug I can think of in School Rush is that you can't enter inkjets when carrying a dumblador. That can easily lead to moments of panic for most reactive players and frustrating death for others.

I now have it fixed, by dropping the requirement of NO_WEAPON when entering inkjets, adding a "THROW" test area when being in the inkjet and ensuring that we DROP_WEAPON if this area ever gets triggered.

C'est probablement un des bugs les plus agaçants de School Rush: impossible d'entrer dans un encrier avec un taille crayon dans les mains (ouais, essayez donc vous-même, vous verrez). En phase de playtesting, ça donne lieu à des moments de panique frustrants pour les joueurs. Je corrige donc en retirant une contrainte sur une transition et en ajoutant un nouvel effet de bord.

What took me a bit too much time to figure out is that the impulse to drop an inkjet must be define as you enter the state with a F_THROW test area, and not on the found-matching-object transition expression (likely because the blador-side of the expression evaluation happens before the bilou-side expression).

Le bon tempo

J'essaie de rendre les manipulations de taille-crayons plus dynamiques. Quelque-chose qui soit plus adapté au gameplay du "school rush" ...

Compared to "Anniversary Level", the tempo of the game has quite evolved. Current animation of Bilou grabbing something on the ground with his eyes going "whoo! Look what we've got here" doesn't fit the action anymore. With the ink rising and pushing pressure, having to stop on a blador to GRAB it is a pain. It would be neat if we had the opportunity to grab it on the fly, just after we stunned it. That the best I can think of to "make things snappy".

J'utilise la nouvelle fonction "édition des zones de contact dans AnimEditor", mais ça n'a pas encore l'air très au point ... entre les dumbladors qui s'envolent quand je tente de les ramasser, les animations qui s'interrompent prématurément et les éponges qui glissent des mains de Bilou. Ce serait sans doute une bonne idée de prévoir une amélioration de l'InspectorWidget pour permettre de visualiser ces changements de zones de contact.

Yet, things are not quite working as expected

• [done] Bilou may stomp-and-grab a dumblador in one jump
• [done] why is left-grab not playing ?
• [wish!] how could I end up with an editor that damages animation when opening them ? I need unit testing here.
• [done] bladors should skyrocket when I try to grab them.
• [todo] why do I have anims with over 10 'control: done' statements ?
• [done] make sure InspectorWidget can report areas masking.
• [done] do not flash colors when holding L in InspectorWidget, please.
• [think] export over WiFi has become too complicated. Plan a multi-connection approach

Unrelated (except for timing) todo items:

• [done] allow meta-information about tiles (rules.gam) to sit in a separate file, included by level scripts.
• [todo] allow spawn point (and possibly spawned GOBs) to be modulated by some global game variable (checkpoints, difficulty settings, etc.)
• [think] a simple map editor for PC would be better suited to those "surgical edits" required in current development cycle. That or easier-to-upgrade runME with the cycle moving back to DS device.
• [done] print and deep-review todo items to establish battle plan for 2015.

Et zou.

Cette fois, je pense que j'y suis. Il m'aura finalement fallu sortir l'ensemble de mes techniques pour que cette histoire de lancer de taille-crayons empilés fonctionne correctement. Pas de demie-mesure:

• un nouveau contrôleur, "gobbit" capable de produire un évènement pour signaler le changement de valeur d'une variable -- désolidarisé donc du copycoords dans le plus pur esprit "micro-contrôleurs enchainés"
• un modificateur, F_ATTached, pour que seuls les GOBs attachés au déclencheur de la collision puisse la recevoir. 
• Les collisions sont toujours utilisées pour provoquer le jet de dumblador: c'est la seule façon de permettre de "passer" des arguments d'un GOB à l'autre. Les évènements "gobbit" ne sont là que pour forcer les deux -- lanceur et lancé -- à rester synchronisés quoi qu'il arrive. Bilou ne peut plus se retrouver "mains en l'air" alors que son taille-crayon s'est fait la malle, et ses "impulsions de jet" ou de ramassage ne risquent plus d'être mal interprétées comme des pieds baladeurs.

It's been a hard day's night. And I've been coding like a dog ... At last, I can safely pick up and throw bladors even though they're stacked up. I initially thought a few alterations to the copycoords controller would do it and I end up with a combination of an all-new test-a-bit-in-your-attach-target controller and a filter that makes areas only collide when Gobs are attached to each other. But at least, that allows me to keep both states synchronized and got me rid of those "not quite thrown, sorry, but you'll have to get hurt before you can use your hands again" glitches.

PS: J'imagine que ça va encore sembler "beaucoup de complications pour quelque-chose de simple", mais la richesse du gameplay que j'envisage repose beaucoup sur le nombre d'interactions possibles entre les éléments du jeu. De même que le fait de passer de dangereux (en marche) à inoffensif (dans sa carapace) puis à utile (lancée), puis de nouveau à dangereux (demi-tour) rend le Koopa-Troopa génial, c'est la richesse des états que peut prendre "dumblador" sur laquelle je parie pour faire de la school zone un niveau intéressant dans Bilou's adventure.

If that feels like much work for a small modification of the behaviour, I invite you to read the "interplay" posts of R. Terrel on the critical gaming blog. I expect higher interplay with monsters in the school zone to highly increase the interest of my game under progress.

InspectorWidget could be more helpful ...

Ok, je suis toujours dans les ajustements supposés permettre à Bilou de soulever un taille-crayon dans un empilement. DDD, cybook, tout le monde y passe ... j'aurais bien aimé avoir un peu plus progressé sur l'Inspector Widget pour me simplifier la tâche, mais il faut faire avec ...

Après avoir envisagé la possibilité d'envoyer un message "à tous les objets qui me sont attachés", j'opte pour une approche plus pragmatique: une variable de la plate-forme que les objets transportés peuvent tester via leur contrôleur (on écrira donc onpath(when w7.1)) pour demander un avertissement si la 7eme variable de la plate-forme voit son bit 0 retomber à 0.

At last, Bilou can pick up any blador even when they're stacked up. One glitch fixed. I hope the same technique will allow me to have Bilou's carrying/non-carrying state more coherent. What technique ? Well, at first I thought collisions would be suitable to notify that one can no longer stand on a platform. E.g. when the platform fades into the background, I'd have a state with a collision area triggering a $STAND->$FALL (Detach) transition. But that's not working properly, because gobs might get collisions from another object that the one they're attached to. Tweaking areas so that the collision is properly received by all the gobs in all their states also turns into a sort of nightmare. 
Instead, I updated 'onpath' controller so that it optionally polls one of the target's variable and raise an event when this variable states "I'm no longer a solid platform, go away." That was the least resistance path. Plus, the polling is virtually free since we had to check that target for presence, position and speed anyway.

What about inspector widget and the picture ? well, it's an additional todo list to remember everything InspectorWidget should have been able to do to ease the (completed) debugging session.

On dirait bien que le problème est maintenant résolu. Glitch suivant: les mains de Bilou qui disparaissent dans certaines conditions (lancer un taille-crayon près d'un taille-crayon isolé, p.ex).

Walking on Bladors

It's far from being done, but at least now I can give it a try: I can start walking when standing on a blador. Issues remain:

• [done] once moving on a blador, I cannot stop: I slide. That's because "onpath" so far short-circuits "stopper" who was in charge of both bringing Bilou (with some inertia) to stop and check whether he'll fall. These two will have to be split for "onpath" to work properly.
• [done] I am not detached when I leave the blador, making me slide even when I walking *past* the blador. 
• [done] if bladors are stacked onto each other, make the upper one fall when the lower recovers.
• [done] same if the lower got picked up.
• [check] I may still end up not on the platform, but still forbidden to fall. Repelled and not attached am I ?
• [todo] Why is there a slight bounce when I'm done picking a blador ?
• [todo] horizontal speed killed when landing on a blador. But at least we can nicely move *out* of a blador.
• [done] Why am I able to "restore" a blador when I pick up the one he's standing on with random chance ?
• [todo] whatever went wrong with Bilou vs Inkjets ... fix it.

Game scripts todo list

Beside the current "moving ink" target, there are a number of things that don't (or no longer) satisfy me in the current School Zone prototype:

• [now] One can land on a stunned blador, but can't walk on him.
• [todo] 1/3-2/3 for the hero position on screen gives more room to anticipate, which is great when running, but a center position is nice when you have monsters all around you. Using the (R) shoulder to "look ahead" (direction-dependent) should be investigated.
• [todo] the "chalk" gob is crying for being polished, both art and behaviour. Having the chalk-gob being the only thing able to break the chalk-tiles would likely be the best approach to avoid curious behaviour.
• [done] when thrown in pencils, dumblador should stop slightly above "the ground".
• [done] update maps make pencils spikes reacting to ennemies too.
• [check] granted, we cannot attach or repell them, but can we allow line-up operations against BLOCKs ?
  

Ça comme à faire un peu trop de choses qui ont été testées mais qui n'ont pas vu leur potentiel pleinement réalisé et qui réduisent la qualité du prototype de la SchoolZone au lieu de l'augmenter. On voit que je ne fais plus assez souvent de démos auprès de mes collègues ^^".

Stack'm'up!

totally totem !

Commencer par les choses simples. C'est ce qui m'a permis de progresser en fin un peu sur le systèmes des plate-formes dans mon moteur de jeu, malgré des semaines bien remplies. L'objectif: permettre d'empiler des dumbladors l'un sur l'autre pour que plus tard, Bilou puisse lui aussi grimper sur un dumblador puis sur des objets qui bougent.

C'est un bon premier pas, même si dans l'immédiat, le taille-crayon du dessus ne se rend pas compte du "démarrage" de celui d'en-dessous, ce qui m'a permis de l'envoyer à son tour par-dessus le premier.

that was too much for one chunk.

At last, I've got one more step performed on the game engine. Too many times, I picked up my laptop after the kids when to bed to end up watching things on youtube or hunting for a new car. Somehow, getting at once into "Bilou riding some platform" was intimidating and I couldn't get things in place. When picking up my notes again this morning, I wanted to come back to small steps that can be chunked with a single tea cup. How about having Bilou able to stand on a stunned blador and call it a milestone ? As I started converting blador.cmd into the new cpp-assisted format, it turned out that I could get something even simpler to check the bare mechanisms: having stunned blador stacked onto each others. Well, tonight it's done.

Oh, and I'm afraid you'll have to wait somewhat for my "Critical Link" series comparing the gameplay of 2D Zelda games: my scanner has apparently entered the dark world of non-functioning appliances.
PS: it's easy to explain the fact that the "stacked" blador stays in place: I was missing the "attach to path" statement. More annoying: the new GameObject::ride() method was built under the assumption that Gob's movement in (dx,dy) would be consumed, which is not the case with dumblador's stepped movement.

Hands'up !

Once we know blador would stick to a wall while Bilou can slightly move below it, our options to show Bilou's hands while carrying something narrow down to only one option: hands are actually part of the "blador" sprite while Bilou's real hands will remain hidden. That perfectly fits the fact that Blador lost its feet, by the way.
Hiding Bilou's hand is somewhat similar to the flickering mechanism introduced for inkjets, in the sense that there's a set of limbs which we'd like to selectively hide while the rest of the character remains displayed.

Je m'attaque enfin à la position des mains, ce qui fera plaisir à Pierrick. Finalement, pour être cohérent avec la façon dont dumblador est transporté, le truc consistera à faire en sorte que les mains de Bilou soient directement visibles sur le sprite de Dumblador. Je reporte à plus tard des mécanismes de "costumes" qui remplaceraient les images en VRAM pour que Bilou porte des lunettes de soleil, par exemple: ça ne m'aiderait pas pour ce problème-ci. Il me reste du coup à cacher les "vraies mains" de Bilou, ce qui ressemble fortement au problème de transparence partielle qu'Inkjet avait introduit, sauf qu'ici les sprites désignés comme transparents doivent en réalité être invisibles.

wrong ...

The first difference with inkjets is that here, hands are *permanently* hidden, bypassing the "counter" used for flickering. The other difference is that many states are involved (actually, most of Bilou's state machine) and that the set of limbs may be different depending on the animation (hands aren't always on the same "layer"), which stems for a more automatic approach (inkjet had sets defined directly within GobExpressions).

Ideally, those "sets" would be defined graphically in AnimEDS. The second best thing I can do is to define them only once, when the animation is imported in the GobScript. That's manageable for a prototype. As a last refinement, I had to alter CopyCoords controller so that it produces an event whenever horizontal direction changes, so that the animation can be changed to avoid odd displays where Bilou seems to have "crossed his arms" while turning back (see the 'wrong' picture).

Je conserve donc le concept de sélection de sprites attachés à un personnage (flickermask), des animations elles-même de sorte que si je réutilise la même animation dans plusieurs états, elle définit en même temps le masque à utiliser. Ce serait encore mieux si je pouvais définir cette sélection directement dans AnimEDS, mais je n'y suis pas encore. D'ailleurs, c'est la raison d'être principale du "GobScript": pouvoir expérimenter les techniques du game engine avant d'en automatiser la gestion par les éditeurs graphiques.
mais les expressions de la machine d'état ne seront plus le seul moyen d'y accéder. Je le complète avec une annotation au niveau de l'animation elle-même.

right!

Je suis obligé, par contre, de passer à 2 états distincts pour le transport de dumblador (un vers la gauche, l'autre vers la droite) de façon à utiliser la bonne animation au bon moment. Il faut du coup que j'ajoute au contrôleur copycoords la possibilité de provoquer un changement d'état quand le personnage transporté subit un changement de direction (ça sera intéressant aussi pour Bilou-sur-l'éponge, tiens).

One drawback with this approach, though: Blador follows the move, but he stays at constant height while Bilou walks/run despite the fact that Bilou's body moves up and down.

The art of Blading

For g88 release, carrying bladors was functionally correct, but still a bit cheap, as the carried blador could move through walls, ceilings and such. It would be an acceptable simplification of physic rules in-game if that did not meant you could "throw" it while it overlap solid structures, which would let it "stuck" there as soon as regular physics takes over to let it be thrown away. I want the game to feel professional, and demonstrate that a simple scripting approach does not imply half-baked behaviours. It's thus time to prove it.

Un taille-crayon qui passe à travers tout pour qu'on puisse le lancer n'importe où, ce n'est pas très réaliste, mais c'est acceptable dans un jeu vidéo. Un taille-crayon qui reste bloqué dans un mur quand on le lance, ça, ça fait tache. Surtout quand le joueur aurait théoriquement dû pouvoir le ramasser et l'emporter plus loin. Premier pas pour corriger ça, interdire à mon taille-crayon de passer à travers les murs (ce qui demandait un réglage spécifique du contrôleur freemove). Résultat: Blador suit maintenant Bilou "de son mieux", ce qui amène parfois des résultats curieux comme un saut quantique à travers un mur contre lequel il est resté scotché pendant 15 secondes lorsque Bilou émerge enfin d'un passage secret.

The first step is to make blador using freemove(1) instead of using freemove(0) when carried. Freemove is the controller that allows free movement typical from airborne ennemies such as the berrybat. The only thing it does before validating the desired movement is checking that you cando(m) where m describe some properties of the environment - like being something you can MOVETHRU. 0 is considered as a special case where you can always do what you want -- perfect for ghosts or sparkles that will fall of the screen. So now, blador can't get into walls, but curious things occur when Bilou gets into narrow passages where Blador cannot follow: Blador just sits where it is, and if at some point Bilou reaches a new position where Blador could fit above its head, Blador gets quantumagically teleported to that new location (yes, again).

Pour corriger ça, il faut que Bilou puisse être informé de la situation du Dumblador qu'il transporte. En '97 j'avais donc pensé augmenter mon "ulitmate game maker" d'un système de messagerie entre les personnages. En fait, ici, on va faire beaucoup plus simple: tout comme l'encrier possède une zone-test (hitbox) qui repousse Bilou lorsque celui-ci l'approche, le Dumblador transporté va disposer de murs invisibles qui empècheront Bilou de s'en éloigner de trop tant qu'il le transporte. Eh oui: c'est aussi simple que ça.

Enfin, presque. Il y a quand-même une subtilité dans le cas du saut. Si je me contente de forcer Bilou à faire du sur-place au milieu d'un saut juste parce qu'un taille crayon a la tête dans le plafond, ça fout en l'air la crédibilité de la physique du jeu pour donner un effet Badman/RSD Game-Maker carrément pathétique. Il faudra donc que je traite cette collision aussi du côté de Bilou en forçant une remise à zéro de la vitesse, exactement comme le contrôleur "gravity" l'aurait fait si on s'était vraiment retrouvé directement dans un mur.

I like how Bilou/Blador distance is stretched or squished when colliding the environment, but I need more control over it. And that's just a perfect fit for the "repel" action introduced with solid inkjets. To avoid having Bilou going too far away from the carried Blador in a narrow tunnel, I just need some repelling-areas acting as virtual walls at appropriate distance from its position.
The same approach allows Blador to take some room between Bilou and the ceiling, but here I need some additional action. "Repelling" simply adjusts coordinates and does not affect speed. The result was that Bilou would keep floating along the ceiling as if he virtually kept jumping. Even weirder: he might have resumed moving up as soon as he'd have moved away from what was blocking Blador (just as in Badman II, actually).
To avoid this, Bilou needs to react on the collision and clear vertical speed. Additional tests are needed to ensure the blocking object (active GOB) is indeed over Bilou's head and that he's still moving upwards. The center-to-center distance (dy) is available through GobScript wf variable read and is positive when the active object is above the passive object (and yes, the sign of dx and dy is related to passive/active roles as the distance is defined only once, and then reused in both passive and active objects transitions).

Il me reste donc "simplement" à corriger l'ordre d'affichage de Bilou et du dumblador (tant qu'à faire, prenons-le en mode "hotte de père Noël" plutôt que "Sac de courses devant le nez") et à m'assurer que les mains de Bilou apparaissent sur le taille-crayon pendant qu'on transporte le crayon.

It leaves me with one last aspect to fix: having Bilou's hand properly shown as grabbing the blador while it is carried, knowing that hands will have to be aligned with blador rather than with Bilou if we want to keep stretch/squish.

8 days late

Took yesterday evening preparing material for the "achievements" (or so). Blador is now bound to button B and HOLDing one prevent you from RIDing inkjets or spongebops, just like grabbing one's legs to DUCK prevents Fire Mario from SHOOTing fireballs.

If I find some time tonight, I really should spend it on making that hole in the desktop break-able only when Bilou has sufficient vertical speed.

Après une petite soirée passée à vous concocter de petites récompenses pour les plus assidûs d'entre vous dans la chasse aux bonus, je revois suite aux commentaires de Cyril la manipulation des dumbladors. Pour ce soir, ce sera (enfin?) le bouchon-à-casser pour passer d'une moitié à l'autre du niveau.

PS: si ces minis-posts permettent mieux de maintenir la tension avant le lancement du niveau, ils sont par contre nettement moins efficaces pour progresser sur le projet. Pour les outils et les modifications dans la libgeds, je garderai des posts-todo aux ré-éditions multiples faisant le lien vers les diff du svn ...

XMAS School Demo.

Here's the new demo. I hope I'll be able to add some screenshots and stuff, but my Internet access is currently down. I've managed to fix the memory corruption problems that prevented to reload the level when Bilou "dies", so here you go.

Voilà enfin la démo promise. Bilou se promène dans les nouveaux graphismes de l'école, il saute (A), assomme les dumbladors, puis les ramasse, les transporte et les lance plus loin (bas). Une erreur de gestion de mémoire m'a obligé à rallonger la phase de debugging. Pour ne rien arranger, je me suis retrouvé sans connexion Internet pendant presque toute ma semaine de congés, du coup, c'est une release "en aveugle", goupillée à partir d'un .nds sur clé USB lors d'un passage-éclair pour reprendre du jus de fruits au bureau ^^".

Since it's a "blind release", I had no access to my todo list, so I couldn't remember I still had a bug with Dumblador recovering just on the left of walls. If you do that, it will remain stuck. (Fixed in SchoolTest-GoT.zip)

Press A to jump and stun bladors, then press "DOWN" to grab them and "DOWN" again to throw them in the direction you're facing.
START enters the pause/debug mode, which you leave by pressing L+START.

Games of Thrown

1MB. throwing in action ...

mises à jour du moteur de jeu terminées: on peut ramasser et lancer des Dumbladors ... puis les re-ramasser et les lancer de nouveau. Enfin, toujours dans la même direction, je le crains, mais lancer quand-même.
Je vais pouvoir passer à l'implémentation des inkjets, du coup ^_^b

PS: attendez-vous à un ralentissement brutal et imprévu du rythme des messages de ce blog dans le courant du mois: *deline attend son petit frère j.l.n mi-janvier.

The game engine now supports throwing of bladors. Pick it up, throw it, repeat. Many things could still be refined including

• [done] having feet really hidden during the stunned animation.
• [drawn] having the bouncing feet looking like feet
• [done]allow the engine to shoot compound gobs too (new feet anim)
• [done] allow runMe to launch the level as well.
• [done] avoid one-way platform to corrupt behaviour of bouncing feet
• [done] throw in both direction, and just drop if you feel so.
• [wish] blador can stun baddies (and Bilou ?) while falling
• [done] fix the map
• [done] use dynamic palette assignment and get rid of those "crosses" marking Bilou feets in jump animations
• [done] areas that can trigger only one other GOB (or a single foot can be consumed by 2 dumbladors simultaneously)
• [wish] climb on stunned bladors, but still walk through them. 
• [done] multi-color that works in runMe too.
• [done] make sure we restart the level if killed, with colours.
• [done] allow bladors to recover next to walls.
• [done] Blador recovers when 2 feet have touched it.

I'll do my best to get all that sorted out quickly so that I could offer the world a new playable demo for Christmas. Earlier arrival of lil'sson could force me to tolerate some imperfections in that release, though.

levez .. abaissez ... levez ... balancez!

Petite réflexion de week-end: comment s'assurer que Bilou ne puisse pas tenter de prendre un 2eme objet en main. Pour l'instant, c'est en tombant une 2eme fois sur Dumblador que celui-ci passe en mode "transporté", ce qui autorise un nombre arbitrairement grand de Dumbladors à suivre Bilou.

Il faudra donc impérativement que les zones de collision déclenchant le ramassage et le lancer soient liées à un état précis ("ramasse" ou "lance") plutôt qu'à une zone générique, vu qu'on a pas de zones conditionnelles. Il suffit alors d'une des variables d'état de Bilou pour se souvenir s'il y a ou pas un objet à lancer lorsque le bouton d'action est enfoncé.

Technically speaking, we can now carry dumbladors. But we're carrying too much of them: every bop on a stunned blador turn it into the "carried" state. I'd rather avoid having 3 bladors following Bilou: grabbing a new one only if none is being carried at the moment would be by far preferable.

Conceptually, there are two "meta-states" (free hands and carrying), and we're only switching from one to the other by picking up or throwing objects. Practically speaking, however, there no such "meta-states" in the state machines, but there are some per-gob variables that can complete those states, so sIdle-> sPickup and sIdle->sThrow transitions would be conditional (and use dedicated collision areas).

Reste le problème de l'apparence proprement dite (les mains en l'air). Au départ, j'avais envisagé un mécanisme de "costumes" (cf. Monkey Island) rudimentaire qui aurait consisté à "geler" la position des mains de Bilou en ignorant toutes les commandes d'animation les concernant. Le hic, c'est que d'une animation à l'autre, les mains ne sont pas forcément liée au même "membre" logique.

Pas évident non-plus de modifier le contenu d'une page de graphisme en guise de "costume" (comme on l'aurait fait pour Kirby), à moins d'effacer complètement les mains du sprite de Bilou et de les intégrer à l'objet transporté (Dumblador, donc). La seule alternative restante serait de donner une deuxième version de *chaque* animation... j'imagine que vous comprenez aisément pourquoi j'aime autant trouver autre chose :P

To ensure proper operation, it is required that some  active collision zone could force state change after the first collision has been triggered. Then, I still have the problem of "animating the pick-up", but I came up with a nice approach for that.
Last but not least, I'll have to ensure that Bilou's hands remain above his head while moving along with a blador ... which may involve an alternative for *every* animation. I'm still thinking about a more practical way to handle that.

En voiture!

Je continue de suivre ma petite carte de développement, une fonction à la fois. Après les panards baladeurs, après la correction des bugs d'animation, voici le transport de dumblador.

First occurence of a transported GOB tonight: stunned dumblador will not simply follow Bilou (as BerryBat): it sticks to a defined position relative to Bilou. A nice "proof of concept" before I try to make it look as professional as possible. [done]

Un nouveau "contrôleur" qui utilise directement les coordonnées de Bilou (après attachement) pour aligner le dumblador. Ça n'est pas encore aussi impeccable que je le souhaite, et on peut observer un léger décalage qui dépend de la vitesse de Bilou, comme avec les plate-formes de Zool. Il faut donc que j'aille jeter un oeil aux listes d'animation pour ajouter le support de ces bits "pending" pour arranger ça.

Puis j'irai chercher une technique de "costumes" à la Monkey Island pour que les mains de Bilou reste sous le Dumblador.

gob->attach(that)

J'ai trouvé un cas de figure pour tester la fonction "attacher un GOB à un autre" qui doit me servir entre-autres pour transporter Dumblador ou pour faire de SpongeBob une plate-forme mobile.
Je veux dire, "un cas de figure qui ne dépende *que* de cette nouvelle fonction".

Starting to work on a set of new features such varied as "grab bladors and throw them onto other ennemies" usually raise the problem of "where do we start". Among all the features (aligning Gobs onto each other, tracking them, etc.), I need a first one that is simple enough and demonstrate the bare bones needed in the code logic: attaching objects at run-time. It seemed that bladors feet could be a candidate. When I draw Bilou bopping a dumblador, blador's feet are stretched away from its body. And when Bilou throws bladors at pendats, the feet are gone, leaving just a large chunk of steel ... a living weapon.

It would be easy to have feet "thrown away" when blador gets bopped on, but then, what should we do when the blador recovers? It magically rebuilds up wherever its feet are gone, like New Super Mario Bros' drybones ? I'd rather not.

Actually, I'd rather have feet attached to their blador although they have been thrown, and guided by a controller that pulls them back in place. The blador's body (the initial GOB) would then stay stunned until both feet have returned. Not only that sounds funny to do and play with, but it also means that the terrain surrounding the dumblador will affect how long it will stay stunned if you stomp it, and thus how tricky it is to grab it before it recovers. A nice interplay approach, imho.

Je m'étais amusé à imaginer Dumblador perdant ses pieds au moment où Bilou lui saute sur la tête ... eh bien, c'est exactement ce dont j'ai besoin. Les pieds deviennent des GOBs autonomes, mais restent "attachés" à leur Dumblador d'origine, ce qui permet de définir des contrôleurs qui les ramènent vers celui-ci. On verra par la suite si celà crée un gameplay intéressant, mais pour l'instant, ça semble un test prometteur.

• Le mécanisme "pending" qui garanti que l'objet auquel on fait référence a déjà été traité n'est pas encore complètement opérationnel.
• Lors de la génération des "tirs", ceux-ci sont assimilés aux objets passifs d'une collision alors que le "tireur" est l'objet actif.

throwing bladors

I can be glad I'm done with the "bottom things" of my summer todo list. Now the winter is starting, and what is left is what is more linked to the game logic and the revised collision engine which is waiting to prove its superior capabilities with some dumblador stunning and throwing.
De temps en temps, ça fait du bien de retourner à une "liste de choses à faire" pour s'assurer que le projet avance effectivment. Bon, des "todo lists", vous devez tout doucement commencer à en avoir une indigestion, mais je parle ici de quelque-chose qui s'approche plus d'un "planning" que des micros-tâches à effectuer sur un temps de midi. Mon dernier planning datait de mi-juin ... voyons où on en est... tous les éléments "du bas" ont été satisfaits, à grand renfort de mises à jour de SEDS et AnimEDS. Je vais donc pouvoir cet hiver attaquer sérieusement les nouveaux types d'interactions entre personnages: assomer, attraper, balancer.

On dirait que les mois à venir vont être durs, chez les Dumbladors.

At those "milestones", I can close many former todo lists, by collecting in a new one the items that remains pending but that weren't really linked to the then-going activities. And yes, this is truly a milestone, since I now have fully operational CompoundGobs, including the definition of palettes for individual limbs (altering the palette while playing the animation will be for a next milestone :P)

• [done] looping move should only be generated for looping animations
• [done] initial Mx,y statement should be ignored by the game engine (actually, everything that delays the rendering of the first frame of the animation should be skipped). That will partly solve the "landing bug".
• [todo] most of blador's debugging could have been avoided if we had the state-initialisation expression feature implemented.
• [done] not detaching an attached GOB when "throwing" it may have weird effects, but I would have liked the display list to be re-ordered so that such side-effects wouldn't have systematically occured.