SchoolRush NY2018

Happy New Year Everyone. I've got a new build of SchoolRush uploaded. Hope you'll enjoy it. For those of you who mastered the game, you'll discover the credits level and the hint towards the secret, vertical level that I've been working on half this year.

Prêts pour la nouvelle année ? Voici une version de Bilou: School Rush avec un niveau secret terminé, des images de chargement qui racontent l'histoire du jeu, la séquence de crédits ... Et pour ceux qui n'arriveraient pas encore jusque là, deux modifications qui rendent le jeu moins impitoyables: on peut "nager" hors de l'encre (encore faut-il pouvoir trouver une plate-forme où atterrir) et on grimpe automatiquement dans les encriers quand on tombe dessus, même si on tenait un taille-crayon entre les mains.

For everyone, you'll enjoy the "swim up for your live" mechanics that will let you go forward even if you missed a jump and fell into the ink. Well, you cannot recover *every* missed jump that way, but it's already much more forgiving than it used to be.

You'll also enjoy how jumping into an Inkjet now automatically let you in, dropping the Dumb Blador you're carrying, if any.

Story and gameplay migrated to latest release post
how to play
Get the .NDS image and play it on your homebrew-ready console or in an emulator, such as DeSmuME. See latest post if you need extra explanation/instructions for running homebrews.

OBJ-WINDOW: Look through the ink

The DS video is made of multiple layers -- this should be no news for you. One of the video registers define which of these layers should be shown on screen, but that register also enables and disable a more obscure feature of the NDS: the windows -- that is, the ability to define multiple regions on screen and give them different set of layers to be shown. When the ink raise in School Rush, I'm not simply painting black squares over the scenery: I actually reduce the window through which the scenery can be seen (with a setup where nothing at all can be seen out of that window).

Petit tour d'horizon dans le document "gbatek" pour voir comment fonctionnent les sprites/fenêtres, une petite particularité de la console DS qui permet de basculer entre deux réglages de visibilité des différentes couches graphiques du jeu. Jusque là, je l'utilisais d'une manière assez simpliste pour dessiner l'encre ou les "rideaux" qui ferment la scène à la fin d'un niveau.

Un simple rectangle dans ce cas-là, qui permet de voir toutes les couches à l'intérieur de la fenêtre et aucune à l'extérieur.

The use I have so far of the "window" feature is pretty basic, but a recent talk with Adrian (GBA developer) made me realise that it would be just perfect to allow the game to give us a hint on where Bilou is when he's swimming up the ink to safety. The trick is that some sprites can be used to create another kind of window. Rather than being rectangular, it can have any shape ... and will be much easier to use than reprogramming the size of the window as we get horizontal interrupts amiga-style.

Pour que l'on puisse voir Bilou nager dans l'encre, il me faudrait donc une deuxième configuration qui laisse voir une partie du niveau tout en gardant assez de noir. Il devrait suffire pour ça de changer un simple bit dans la configuration.

J'hésite un peu quand à la manière d'implémenter ça ... Plus précisément, sur la manière d'indiquer depuis les scripts du jeu que l'on souhaite passer un certain sprite dans le mode "fenêtre". L'idéal serait probablement que l'information soit retenue dans les animations elles-même, mais sans nécessiter de modification de AnimEDS.

En même temps, l'utilisation d'AnimEDS n'est nécessaire que si j'essaie de micro-optimiser et d'éviter un sprite 32x32.

There are a few implementation details I'd like to sort out before implementing that. I already figured out that it should be under the responsibility of *Gob + GobAnim classes, the *Gob being the only class that can manipulate OAM entries (including the OBJ_WINDOW_MODE bits) and GobAnim being a natural place to setup flags indicating that "this appearance of the sprite should be a window (or alpha-blended, or rotated)". I might give it a try with a single 32x32 sprite and dedicated "flags xxx" script entry before I go for something more integrated that could replace the Flicker command currently in use by e.g. inkjets... 

edit: got it working. (by Oct. 14th) Some pixels to edit, now.

Ink pit : play-tested

J'ai eu l'occasion de faire tester le niveau vertical de "school rush" à L., 11 ans maintenant et qui essaie maintenant occasionnellement les niveaux de Bilou depuis 2009 2013. La fonctionnalité-clé est validée: "j'aime bien qu'on puisse nager pour ressortir de l'encre", affirme-t'elle, alors qu'en pratique, elle n'aura réussi que quelques fois à se tirer du mauvais pas, et généralement si affaiblie (enfin, Bilou, hein. Pas ma testeuse) qu'elle n'ira guère qu'un ou deux écrans plus loin.

L./S-team is 11 years old now. She's been play-testing School Rush since 2013 and she just validated a new mechanics I added to the game: "I like it that I can swim out of the ink, now". In practice, it only saved "her" (well, actually Bilou) a couple of time, and usually so weak that she can barely go a few screen further before re-starting. But the psychological effect is there: she keeps playing that vertical level, keeps improving so that she frequently reaches 1/4th of the level and 1/3rd from times to times. Quite an achievement for me too, given that she initially played in "easy mode" only, and did not really bother to reach any goal but the one she set for herself.

Mais l'effet psychologique prend. Elle s'accroche et s'améliore peu à peu, jusqu'à atteindre régulièrement 1/4 du niveau et occasionnellement 1/3. Au-delà, les choses se corsent et il faut régulièrement courir pour franchir les sauts, ce que L. ne maîtrise pas encore véritablement.

Celà dit, comparé au jeune premier, L. a immédiatement senti l'urgence de l'encre qui monte, remarqué qu'il fallait se méfier des encriers endormis et qu'en sautant un petit coup supplémentaire une fois arrivé dedans on les réveillait (oui, c'est un vrai bug que je dois corriger, pas un choix de gameplay douteux), repéré les horizontales dans les les livres et les utiliser comme plate-formes, etc.

A younger cousin of L. did try the game as well, but unlike her, he didn't seem to get any feeling of emergency from the raising ink. L. also noted how a small jump can prevent an inkjet from keeping asleep (a true bug I still have to fix) and she is now super-fast at spotting those horizontal "decoration" on books that can actually be used as platforms.

Come back from the ink ?

Bon, entre les programmes d'activité des loupiots qui grandissent, les centrales vapeur qui tombent en panne et les interventions de réparation dans la maison, je me prends une petite paire d'heure pour essayer de corriger un couac avec le passage à un niveau vertical dans "School Rush": s'assurer que le jeu relance bien le niveau si l'encre nous rattrape.

Je dois  notamment éviter que Bilou ne puisse rester indéfiniment dans un encrier sous l'encre. Etre invulnérable dans l'encrier, ok, mais pas retomber immédiatement dedans quand il nous projette jusqu'à la fin de la batterie.

It is time to check what the vertical level looks like when we add rising ink in the mix. And the first tests show that there's quite some tuning required. The first mis-steps that my last playtester did led Bilou to be stuck in the ink, invulnerable, but also unable to keep on playing. One of them involved cycling between in-inkjet and hit.

I'm trying to make the state machine detect that we're in the ink and switch to a "swim up" state that would give the player a chance to get out. This is possible because ink has an additional flag that makes it possibly different from a regular hazard. All the engine requires is that the test on "hurts and is ink" precedes the test on just "hurts".

Se faire projeter par l'encrier, c'est "$HJUMP". L'encre, c'est à la fois F_HIT (blesse Bilou) et F_ISINK (fait flotter les éponges). Une réaction "normale" pour le personnage qui tombe dans l'encre serait d'essayer de nager pour en sortir. En particulier s'il atteint quelque-chose qui peut le propulser hors de l'encre. Ce sera "$SWIM", dans lequel on est insensible à l'encre mais qui repasse faire un test périodiquement et continue donc à consommer des points de vie tant qu'on est dans l'encre.

Il faudra aussi que je complète ce "swim" lorsque Bilou arrive hors de l'encre.

mayfreeze = false

Voilà: le niveau vertical est pour ainsi dire fini. Du moins pour ce qui est des décors. Maintenant, je vais devoir passer un peu de temps à faire les réglages pour l'encre-qui-monte. La bonne nouvelle, c'est que la technique qui évite que l'encre s'arrête de monter quand elle sort de l'écran est déjà opérationnelle depuis Juillet.

It's now time to make sure the vertical level get rising ink, too. And this time, I need to take extra care that the objects that control the ink level will never got "frozen" when going too far away from the camera. That was hopefully available since early July.

Un peu plus délicat: s'assurer que Bilou se "noie" toujours dans l'encre malgré le fait qu'il puisse parfois tomber de plusieurs écrans avant d'être arrêté (et la zone de collision de l'encre ne va pas jusque là).

Another thing that I'll have to take care of, is that Bilou don't go too deep into the ink. Without it, we can quite easily have Bilou fall down so low that he'll go out of the "hit player" box ... and player will have to find some other way to hurt himself (while seeing nothing but a black screen) to be granted another attempt.

Je vais devoir ajuster un peu les encriers -- et en particulier éviter que Bilou ne soit totalement à l'abri à l'intérieur d'un encrier -- faute de quoi il pourrait très bien y rester bloqué indéfiniment. Et enfin, il faudra trouver la bonne vitesse pour la montée de l'encre, parce que là, j'arrive en haut du niveau avec 6 bonnes minutes d'avance. De préférence sans trop "tricher".

One last thing: I cannot keep the rule that "being within an inkjet = being immune to ink" as with the 4 previous levels, because then you'll be stuck in your inkjet forever.

And then, I'll need some tuning on the ink speed itself. Right now (60*32/256px/sec), I can climb up the level and I'd have to wait for over 6 minutes before the ink can catch me back.

If I let the ink almost reach me when I'm about to go through the last "room", though, I'm only some 40 seconds ahead at the top -- which is still quite a lot.

Palettes fix

With this fix to GameScript's graphic chip initialization, SchoolZone's colours are back to normal despite the new ink pipes tiles that use the same colour numbers as the browns used for "owl background". I thought at first that I was using a too small memory bank for extended palettes, but no. VRAM_E_LCD is 64K and only 32K are used when mapping as VRAM_E_EXT_PALETTES. But I wrongly set "BG_WRAP" while tile planes are always wrapping (unlike bitmap planes), and for the plane used for the owl background, it forces sharing of the palettes of the playground plane.

Voilà. Une vieille erreur dans l'initialisation des plans de décor de corrigée, et mes couleurs sont enfin comme elles le doivent sans "couleur interdite" pour l'avant plan. Je vais pouvoir passer à la programmation des bouchons et des vaguelettes.

Et au passage, je retombe sur un outil en ligne de planification pour la mémoire vidéo de la NintendoDS assez pratique. Voir dans les commentaires pour ce qui me semble le plus intéressant pour la suite du programme.

School Rush Story

Bon, mon jeu n'a pas la reconnaissance de Rick Dangerous, mais il y a une ressemblance amusante avec les croquis de Simon Phipps.

The idea of "turning off the ink" starts to get real. With some details on the level design, I hope to be able to explain "why is there so many ink here", and "what happened to turn something normal into something dangerous. Time for some more Pixel art ...

edit: Got fair art drawn, but unfortunately, I'm using the few 16 colors (same as the inkjets), which happen to be trashed by the background art in the current code. There is no good reason for this to happen, given that we have now extended palettes (16*256 colors for every individual plane). I'll have some code-digging and potenially refactory time ahead.

Edit: ok. Cork switch closes the level. It doesn't let you see ink draining away from the pipe, though.

pixel art waterfall

I will need something that shows where all that ink comes from, and build a story about getting the School Zone a dry place again. It is not so easy to come with pixel art liquid flow, but I know from a while that iSohei did a great job drawing some. In my case, the narrow and straight flow is possibly the best choice.

The flow is rendered here by a highlight area in curvy and noisy v-shape that twists left to right as it moves down. The picture here shows the individual frames of the animation when vertical movement is canceled.

I could have that with a sprite shot from the top of the waterfall over some otherwise static ink area. I could shoot _two_ of them simultaneously, but that moves down at slightly different speed so that you get the illusion of a wave that widens as it falls down, too.
well ... now it's analyzed. Let's make it so.

Bon, j'ai fait une première tentative désastreuse pour animer une chute d'encre (indispensable pour le dernier niveau de School Rush). Puis une deuxième encore pire... alors je retourne chercher une référence de "Pixel art waterfall" pour voir ce que je peux faire. Le mieux, ce serait sans doute d'appliquer la même technique que iSohei pour sa troisième cascade: un sprite en forme de v qui se tortille en descendant. L'avantage c'est que je pourrai alors utiliser un vrai sprite et avoir une animation d'autant plus fluide.

Edit: coding attempt: having the falling wavelet 'rewind' to the top of the fall/pipe when reaching the ink is nice, but is not sufficient because 'the ink' is actually there only when the 'inkfall' is on-screen. Remember ? ink waves GOBs follow the camera.

book stack ...

A few days after releasing the playable version of Bilou : School Rush, I started encountering ideas for one ultimate level, one where you climb up to the top, rather than running horizontally. Something much more along the lines of the "original" deep-ink-pit although not expecting any specific game physics.
What was nice with that was that it turned the otherwise purpose-less "school rush" into something backed by a story (simple, I admit, but a story nonetheless). It opened nice opportunities to have hand-drawn pictures as support for a "game ending / credit" moment, too... and last but not least I found a nice way to ensure that this last level is available only in "amiga" or "arcade" mode, but not in "casual" (which is meant for training and teasing, as you remember).

A sketching pause was more than welcome, and now I have some concept art and some tiki-books for the background to change the atmosphere of the ultimate level. I'm under the process of converting that to pixel art. With a size of over 800 individual tiles, it is clearly the biggest piece i've addressed with my sprite editor. I had to chunk it into 64-pixels slices, resisting the temptation to redesign the UI of the editor, but I'll allow myself to add a "live mockup construction mode" before I'm done.
I first opted for 32-indexed colours in Gimp, thinking that I'd paint over the lines, but the shapes are too far from pixel-friendly angles, and "cleaning up", adding highlihgts could turn out to be my best approach. Yet, I'm already raging against my own self:

• clicking '+' on the quick palette widget insert the selected colors, shifting existing colors to make some room, collapsing places they come from ... but I couldn't find that documented anywhere;
• '!' (replace current color by its closest match) acting only on the grid is too restrictive for such pieces
• '!' and '?' (search for color closest match and occurence of the color in the tileset) are disabled after we load something on the grid. I have to shift the pixels around before the buttons work again.
• losing the content of the 32x32 grid when entering palette screen or touching one 16x16 block on the tilesheet should never occur again.

PS: please excuse french/english hopping again: it's another i'm-sick-and-blogging week.

Il faut que je finisse "School Rush".

Voilà quelques jours que je ne parviens pas à me mettre à la programmation des derniers éléments de School Rush. J'ai l'impression qu'il est temps que ce volet se clôture. Il y a 3 ans, je mettais en ligne -- vidéo à l'appui -- la première démo du moteur de jeu supportant les animations créées dans AnimEDS. Le premier écran reconsitué de la School Zone, lui, a encore 6 mois de plus, et comptait mettre en oeuvre un jeu type "arcade sans monnaieur" -- deep ink pit.

Là, je commence à avoir envie de changer le décor de fond du jeu, à déguiser l'encrier de l'écran de menu en vieux moustachu, mais le thread sur wayofthepixel fait déjà plus de 160 messages, et je ne parviens plus vraiment à attirer l'attention. J'ai envie de coder ces lattes-qui-tournent et les signets auxquels on s'accroche. Les power-ups m'écartent du gameplay prévu. Je ne suis pas sûr d'intégrer le "wall kick". "Big Punch", ça, clairement.

Et puis il me faut du son. CJ? T'en es où, avec ton son ? J'ai fait quelques essais, un petit roulement de percussions fait un bruit décent pour un crayon qui fait demi-tour. Jouer le même son avec "pitch bend" vers le bas pourrait aussi faire le bruit du crayon dégommé. Je dois introduire des "GunPalettes" dans le moteur de jeu pour pouvoir ajouter assez d'effets sonores ... Ou alors j'associe directement les sons aux animations.

Il me manque un palier de difficulté entre les niveaux 1 et 2, mais le bouton L de la DaiSi me fait à nouveau faux bond. Migration de mon iPlayer vers "lime" retrouvée il y a un bail dont je viens du coup de vider la batterie.

Là, il est temps que je release et que je passe à la suite, je crois, sinon je vais sombrer dans le traçage d'historique de développement ...

C'est quand, la prochaine vidéo du JDG ?

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.

Ink Swamp Worm

The ink swamp worm

Now *this* is looking better. It tooks two "masters" (one to the left, the other to the right) to ensure that I have a chain of wavelets GOB looking still, and looking to occupy the whole level. I will definitely need a wider GOB for the wavelet so that the spawn rate is enough to cover the screen even when the camera accelerates, and I'll need to investigate the camera offsets (currently, some values curiously refuse to work). But at least I get spawning and termination of wavelets as expected.

Hmm. J'aime mieux ça ^_^ Un "maître" de chaque côté, qui s'assure qu'il n'y ait plus de vagues à une extrémité et qui en génère une nouvelle s'il n'y en a pas au-dessus de lui. Il me restera des règlages avant que ça n'ait une belle tête de mer d'encre, mais on s'approche de l'objectif.
Il faudra aussi que je trouve un moyen d'arrêter la montée implacable de cette encre, au fait ^^"

Une histoire d'encre...

La première implémentation de l'encre qui monte n'est pas franchement un succès. J'avais oublié que les zones sensibles d'un GOB (hitbox) ne peuvent pas se trouver en-dehors de son rectangle vital (bounding box). J'avais aussi oublié qu'un nouvel objet généré par un GOB apparaît systématiquement à l'emplacement de son "père". Les alignements de coordonnées partiels et impliquant la caméra, par contre, donnent pleinement satisfaction.

Pour ce qui est de l'affichage de la "grosse zone noire" par-dessous les vagues (l'encre proprement dite), j'ai décidé de laisser ça sous la responsabilité du code spécifique au jeu qui gère aussi l'affichage du score

Un petit pas de plus

Rien de bien impressionnant à montrer, mais le système d'animation des blocs de l'encre (entre autres) vient d'être revu pour éviter une copie supplémentaire de la "page" de graphisme sur laquelle l'animation se trouve. Pas grand-chose mais c'était un point de passage obligé pour pouvoir faire pareil vers un élémént situé dans la mémoire utilisée par les sprites.

No fancy screenshot yet, but I've got rid of an extra copy of animations in the the block-animation engine. Something I wanted to cleanup long ago but that now becomes mandatory to apply the same kind of animation to sprites ... which will ultimately allow ink moving up and down. Once again, my cybook proved very useful to dig in that dusty part of the game engine.

La p'tite encre qui monte, qui monte ...

Quelques notes sur l'encre-qui-monte que je numérise avant de passer à l'implémentation. L'idée étant d'utiliser soit un polygone soit la fonction "fenêtre/cadre de vue" pour la partie noire ("Master Ink" dans mes notes") et des sprites pour la partie animée (les "wavelets").
Si je veux avoir quelque-chose à proposer pour la NeoCompo de l'été, il est temps que je m'y remette, n'en déplaise à Gomez et son fez. Donc:

• [done] permettre au contenu de la mémoire vidéo des sprites de recevoir des étapes d'animations successives à un seul emplacement (par copie à chaque étape) pour une synchronisation parfaite des ondelettes;
• [done] ajuster CopyCoords pour que MasterInk ne suive la caméra qu'horizontalement et que les wavelets ne suive MasterInk que verticalement.
• Mettre en place la machine d'état avec ces éléments-là
• Faut-il une "caste" spécifique pour les vaguelettes (pour réduire le coût des collisions) ? 

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.

Fixme list

"Don't Repeat Yourself" supported.

The few feedback I got for the "upgraded" school zone level provide some fairly interesting hint: some gameplay features will not be properly managed by players unless they're sufficiently pure. Give any reason for the player to believe that holding B could let him run and he'll fail to discover that he's got to hold R for that to work. So to get pure gameplay in Bilou, I still need:

• [blador:ok] Introduce monsters/ink interaction
• [MEDS] Dedicated animation when Bilou picks up something
• [done] Never "randomly start running", no longer run-on-turn-back, only run-on-land when one had running speed in the air.
• [done] no invisible ceiling to kill your jumps.
• [done] visual clue to tell whether you'll bounce or not.
• [done] visual clue that chalk may break when sufficiently stressed.
• [wish, D.I.P] bouncy-idle-sponge vs. low-bounce-swinging-bops.
• [patch] HUD with life meter. (and speed meter ?)
• [wish, adventure] visual hint for dead ends (?)

Il y a une leçon qui réapparaît à travers les divers retours que j'ai reçu de ma démo de la school zone: les éléments de gameplay ne sont correctement maîtrisés par les joueurs que s'ils sont suffisamment purs (les éléments, pas les joueurs). Par 'pur', j'entends 'le mécanisme se déclenche sur base des inputs, à chaque fois et uniquement dans ce cas-là'. Qu'il y ait la moindre raison que le joueur puisse se mettre à courir en appuyant sur B et celui qui en arrive là lors de sa première partie n'essaiera pas de maintenir R enfoncé pour courir. Par contre, il nous indiquera que 'ouais, courir, des fois ça va, des fois ça va pas'.

Le même genre de leçon peut être tirée pour les animations: une action différente du personnage sur son environnement réclame une animation différente. Le joueur doit pouvoir "voir" que son personnage fait quelque-chose de particulier. Pas d'animation "essaie de ramasser" quand il n'y a rien à ramasser, et il n'y a pas de raison que le joueur essaie de ramasser un truc quand enfin il s'en présente un.

(old) non-symbolic gobscript

All this (and further introduction of power-up with more conditional state transitions) will require more work on the state machine for Bilou which is already fairly complex (32 states, 170 transitions 0_0). 

I don't want to make the parser smarter on the DS side (e.g. I still don't want symbol tables or function definitions) but it's truly time I adapt the Makefiles so that e.g. GCC's pre-processor can be used to produce the "compiled" state machine out of more symbolic description.

(new) symbolic gobscript

Mais pour pouvoir modifier tout ça, il va falloir que j'aille replonger dans la machine d'états de Bilou, qui est déjà pas mal complexe (32 états, 170 transitions).

Je n'ai pas trop envie de devoir augmenter aussi la complexité du parseur qui tourne sur la DS (pas de table de symboles ou de définitions de fonctions, par exemple). mais je pourrais arranger quelque-chose pour utiliser le pré-processeur C pour me convertir une description plus 'symbolique' vers le texte brut compris par le code DS...

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.

Yearling

Last year's "holiday todo list" is thus finally completed. The last touches to SpongeBop's behaviour were introduced mid-June, multi-palette support was released in March, ink hurts (when configured in that way) and (of course), we do have compound-animation for Bilou since September 1st, 2012, and I fixed much more than just the "landing bug".

What's up for this year's holiday ? I've got pendats animation (well, not the full set of actions, just the simple walk) and a first draft of verso-the-eraser. I just have used the last 70$ of NeoCompo prize to order a replacement part for my fridge (15°C cooling is not funny), and I still have much drilling and sawing to do outdoor to make the garden kids-friendly.

Si sur le devant de la scène je prend enfin le temps de mettre en ligne toutes ces réflexions sur le gameplay de Mario World, en coulisses, la révision de l'éditeur de niveau atteint le stade "tests intensifs". L'objectif ? Pouvoir enfin ajouter de manière fiable des monstres, encore des monstres, et pouvoir les lier les uns aux autres (indispensable pour SpongeBop) sans devoir passer par le PC et son éditeur de texte ... Mais le reste (clonage de niveau, wizards, etc) devra attendre: la Neo Compo 2013 approche à grands pas et j'aimerais pouvoir y présenter une première version de Deep Ink Pit ... si libntxm veut bien ... et la VTJ aussi.

The critical item to get started on a "deep ink pit" map right now is the level editor, which must be capable of cloning monsters that are attached to other monsters without messing up the level commands. It's still in "testing and fixing" stage, though. Then, I'll need something that makes the ink moving up ... that will involve a custom effect of some sort, as that's not something the state machines will easily handle.

I hadn't got much luck with musics so far: Both Piek's and Piet's tune play weirdly on the Nintendo DS... Deep ink pit will feature yet another song and if that one doesn't work properly either, fixes/level-up will be required on libntxm.

Will this be completed for NeoCompo 2013's deadline ?

Oh, btw, translation of Saturday's post is at last completed. 

Deep Ink Pit gameplay

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

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

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

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


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

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

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

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

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