back then ... geometry first.

Dumblador revisit post from October 2011 featured not-so-great book covers and "colour balance" post 20 days later featured them almost identical. Then 10 more days and they suddenly look like in School Rush. What happened in between ? pixel art Comment and Critique. "I think you're focusing way too much on using techniques right rather than the objects itself" said Elk, but I couldn't figure out what that meant. "The biggest problem with your art is bad texturing, at this point, I'll return with specific edit and critique." So Helm Returns is what happened. 

En triant un peu, je suis retombé sur un post du forum pixelation qui répond à une question que personne ne se posait. C'est qu'entre le relookage de Dumblador (Oct. 2011) et la recherche des couleurs idéales pour la School Zone (Nov. 2011), on est passé d'un livre pas très convaincant au design actuel utilisé dans School Rush (et qui restera certainement inchangé pour Dreamland). Dans ce post, Helm me donnait une série de conseils en retouchant lui-même le livre que j'avais dessiné.

1. is your book.
2. is the form broken down to its block shape.
3. is geometry, lit from above more or less. If a thing doesn't look good and identifiable on this stage, it won't look much better if you overrender it.
4. here I apply more detailed geometry, I still don't need more colors or fancy tricks, I don't need to fake texture, it's just stuff that the book can support. I also looked at reference here which you should always do, no matter how cartoony what you're trying to draw is. You can spot many differences from 3 to 4 that are related to the reference.
5.After the shapes are good, identifiable and the object has volume, you can go nuts with your new school colors and tints and whatever else, it's all embellishment from here and on.

Le jeu, dans ce cas-là, c'est d'essayer de réappliquer soi-même les conseils qu'on a reçu. A savoir ici "commence par la forme brute, puis fais en sorte que la géométrie soit compréhensible". Ne pas aller au-delà de l'étape 3 si quelque-chose va de travers. Ensuite, rafiner la géométrie mais ne pas texturer, ne pas partir dans des grands effets de couleur. Une excellente leçon, et je vais en avoir bien besoin pour m'attaquer au gros poing pour la pyramide ...

So I went on and try to apply the master's suggestions to get closer to what I wanted:

My attempt at having the right geometry with flat shading and minimal details, my step of putting more detailed geometry and shading before adding any texture, and the final take. The page lines have become too horizontal and dull, retrospectively, but the binding has been used almost as-is in the game.

It was a pleasure to read the master's comment:

Much, much better. Wouldn't surprise me to see this piece in any professional good looking mega drive game of the era.

Approach all real-life related items you render in a similar way, avoid 'noisy textures' for their own sakes and you will level up in your craft."

A lesson to remember as I'll have to work on more pixels for the upcoming game...

PicoDriller fait des vagues.

A côté de ses productions principales (lunark, castaway), Johan Vinet nous a aussi proposé un petit fangame sur pico8 d'un jeu où il faut creuser plus vite que son ombre, sorte de croisement entre Tetris et Boulder Dash.

Je dit "petit", mais la qualité du gameplay et de l'habillage est tout à fait remarquable. C'eut été un homebrew sur NintendoDS, vous pouvez être certains que je serais resté scotché dessus!

Mais ce qui m'a frappé au point de le reprendre dans ma récapitulation de 2023, c'est la vague géante de l'écran titre. Monochrome, avec au plus un creux à l'écran, elle est tout à fait dans les contraintes techniques de la SNES: on coderait alors les vagues en reprogrammant les "window" à grand coup de HDMA, et ça débloquerait le principal frein à une adaptation de SchoolRush sur la reine des 16 bit ... 

PicoDriller is a fun little Pico8 game, somehow a crossing over Tetris and Boulder Dash, and it would definitely deserve a complete review of its art and gameplay mechanics. And unfortunately, I'm not going to do that today. Sorry Johan (he's one of the Pico Driller author, and I've been playing some of his other games). No, today, I'll just discuss the title screen of PicoDriller and its very convincing big waves.  

Alors autant vous dire qu'à plusieurs reprises au cours de 2024, je me suis posé la question "mais comment savoir quelles valeurs donner, ligne par ligne, à Wstart et Wend pour qu'ils définissent la zone sous une sinusoïde ? et comment coder ça efficacement ? Et est-ce que ça tiendrait dans le budget CPU d'une frame SNES ?"

Et pour bien commencer 2025, je me suis dit "eh, mais si on partait du sommet de la vague et qu'on suivait la pente pour élargir la zone noire masquant l'image ?  Après tout, la dérivée de sinus, c'est le cosinus et le cosinus, c'est le sinus déphasé d'un quart de tour !

The core reason is School Rush, of course, and how the Super NES couldn't render enough sprites on a single scanline to depict the raising ink in the game. But if you use demomaker tricks with the 'window' feature of the 16-bit queen (using it as 2 horizontal lines whose position and size can be updated on every scanline), you might get a wave moving as smoothly as that in PicoDriller intro, and that might be stunning enough to excuse the lack of additional colors. 

The idea isn't new: it has been teasing me for the whole 2024 year. So with the winter holidays coming again I noted that "well, I could just start with the top-of-sine, at a given position, and widen it according to the slope of the sine at that point, right ?" and then taking my noteboox and starting to scribble trigonometric functions, taking into account that slope of sine is cos, that cos at some point is sine later on the curve and things alike until I thought I had enough to write down a little loop that *should* give all the items needed to render the sine with "just" a pre-computed look up table for cos values.

I had the surprise to see game developer Jayenkai (Blockman and countless other titles) objecting that it might still be too much maths for the SNES hardware, and pointing me towards an online BASIC interpreter with fair documentation of their graphics commands ... He proposed an alternative where quadratic curves are used to emulate sine, and to be honest, the difference isn't that strong unless you're interested by the slope of your sine when it crosses the "horizon line".

Jayenkai (platdude, blockman et tant d'autres) trouvait que ça faisait trop de calculs pour une snes et m'a aiguillé vers un basic-en-ligne pour m'illustrer une approximation quadratique très 6502 ... 

C'était juste ce qu'il me fallait pour tester rapidement le bidule, donc j'ai recodé la génération de la table de lookup (grandement simplifiée par la présence de cos() et arcsin() dans le basic) puis la 'simple' accélération/décélaration de la descente par accumulation, un accès à la lookup table par ligne

Bin je dois dire que ça donne plutôt bien ^_^

But that evaluator (gotojse) was a breath of fresh air, allowing me to toy around and eventually build up a way to render what *I* had in mind as well, proving the concept. Okay, I don't have it animated like in pico driller, but that might come later on ^_^ 

Bon, ce qui fait tout le sel de l'effet de pico driller, c'est avant tout la variation d'amplitude appliquée sur la sinusoïde, qui va jusqu'à en inverser la polarité. Le fait d'avoir doublé l'effet avec une "ombre" est très stylé, mais incompatible avec le hardware SNES que j'envisage de piloter. 

Il me semble aussi que le "niveau 0" monte et descend légèrement au fil du temps suivant une autre sinusoïde. Ce qui serait stylé, ce serait qu'il suive en réalité une sinusoïde de très basse fréquence (moins de 45° par écran), mais ça nécessiterait pas mal de calculs en plus ... pas sûr que je puisse me le permettre ici ...

 

October update

That week off has been pretty B-usy ... The 'three rooms' demo now actually feature 2 additional rooms, including one that is level-sized. There are still quite some things to fix, tileset updates, adjusting to .more loading, and the like... 

• [done] separate exit special block from fall-through-door special block,
• [done] stop flashing school background by applying waterfall palette cycling only in the green zone
• [done] adjust bounding boxes ... many bounding boxes.

Bienvenue dans un post-qui-change... ma petite semaine de congé d'automne aura été bien remplie de p'tits Bilous (entre autres choses), avec en objectif #1 l'ajout de deux "niveaux" dans la démo "Three Rooms", comme proposé en Mars. Evidemment, comme ils datent tout deux d'avant SchoolRush, il y a eu pas mal de mini-couacs à corriger pour éviter de se retrouver avec un niveau au décor psychédélique qui se termine dès qu'on casse une craie

Well, some recent development are incompatible with some old mistakes... especially bounding boxes. I remember being puzzled by what worked and what did not worked when I introduced the 'sand waves', which did require one bbox x y w h command to align the visuals with the slope ... but it really was almost blind guesses.

For some reason, the "box size" bits were ignored, and the "offset" bits were ... well, it will work better with offsets that says "pictures starts 4 pixels on the right in the 16x16 frame. Of course, fixing the size first made most of the offset wrongs until I've got new offsets computed.

Even after one more afternoon of map fixing, there are weird things happening in that school zone level, like 

• [todo, not critical] Bilou not always hidden by front layer (e.g. hidden if you jump, but not if you're idle or walk)
• [todo, not critical] Inkjets not moving up and down following rails

Le plus gros morceau, ça aura été de corriger le code qui permet à un simple sprite 16x16 d'être considéré comme étant plus grand ou plus petit ... une modification essentielle pour passer du furblock à la branche mais qui interférait avec les gouttes d'encres d'inkjet et les vagues de sable ...
Alors, voilà: un joli bouton vert vers une nouvelle démo à essayer chez vous. Bien sûr, ça reste très en chantier et vous trouverez pleins de trucs pas au point, mais au moins, les horreurs ont été éliminées. Rendez-vous en Décembre avec une démo incorporant BangBash ?

Ah, and it's not in the school zone, but [done] that ugly pink background showing up in the green2 level, too... I'd rather have that fixed before uploading a new demo...

edit: There we are: 2 work-in-progress levels can be found if you explore the three rooms properly. There is still much to do, but also much to explore if you've never launched anything earlier than School Rush.

Chalk 2.0

In the first release of Bilou's Adventure solo anniversary level, I had to use a caption on the blog post so that players would know they need to break one "barrier" to keep going.

Later revision replaced it with a chalk, that can break if you fall from high enough. But that wasn't properly explained to player either.

• I have sketches of training rooms to teach players chalk can be broken
• Original level design had key-and-lock there, and one of the design decision for Bilou's Dreamland is "it is okay to rely on keys and locks"
• What if a simple jump was pushing the chalk down by 1 pixel ? (in addition to everything else you can already do with it)

Bon, ça ne devrait pas être une surprise: Bilou's Dreamland reprendra le niveau-anniversaire pour la school zone. Il a l'avantage supplémentaire que pas mal de mécaniques de jeu qu'on y trouve ont déjà passé l'épreuve du playtesting, même si ce n'était clairement pas parfait. Un des éléments qui a le plus causé de soucis aux joueurs, c'est cette craie-qui-casse que Piek jugeait zelda-esque. C'était pourtant une amélioration notable par rapport à ce qu'il y avait dans la première version nds du niveau, où il fallait lire le blog pour savoir que ce crayon-là peut casser, contrairement aux autres...

It might not be bad that you could push down the chalk-gate without ever making a bigger jump, mostly because those eraser monsters will put you under pressure while you're trying to do that. It wouldn't be a big deal either if you could lower it by e.g. 8 pixels with regular jumps, but that it then lift up by 1 pixel every time you jump from it, making the next jumps useless. But at least you've seen it is interactive.

The 'tutorial' option is to introduce the chalk gate first in a setup where the player is guided into thinking that it is a 'jump-through' platform, but reveal that it actually breaks when Bilou knocks it from below.

Alors ces derniers mois, j'ai rajouté quelques croquis dans mon cahier-design que je vous renumérise ici (panne de scanner) qui étaient sous-titrés "où on apprend que la craie, ça casse". Histoire que le joueur ait déjà des informations à propos de ce type de bloc quand il va devoir réfléchir à son sujet. Je sais: j'avais donné comme ligne de conduite pour Dreamland "on s'autorise des portes-qui-téléportent, des clés, des serrures et des interrupteurs", et dans le design d'origine, c'est un simple interrupteur qu'on utilise. Mais on est tellement proche d'un mécanisme intégré dans le monde du jeu que ce serait dommage de ne pas vérifier que c'est jouable...

And once you know they are breakable, it is much easier to create a setup where you learn that they can also be broken if you fall on them with sufficient speed. Especially if I add some screen shaking when you hit plain ground with that speed... and ask my brother to give me a dedicated sound effect for that.

Sinon, une dernière option serait que chaque saut sur la craie la fasse descendre d'un pixel si la vitesse de collision est insuffisante. De quoi confirmer au joueur que oui, c'est pas interactif et que oui, c'est en tombant que ça va marcher, mais là, ce n'est pas encore assez. Elle n'exclut pas les écrans préliminaires, cela dit... Avec un peu d'écran-qui-tremble quand Bilou arrive sur le sol avec une vitesse suffisante pour casser des choses, ça pourrait faire un combo gagnant.

Being so close to actual organic gate mechanics, I feel like it would be a pity to come back with a plain old key opening a plain old lock.

How it is bashing

Mon agenda étant en vadrouille le week-end dernier, je suis retombé sur mon cahier bleu, celui qui se concentre sur le game design de Bilou's Dreamland. De page en page, je reviens en arrière dans le temps ... je fais une pause sur la révision du niveau de Rémi, toujours en attente avec ses nombreux bangbash, puis tout naturellement, je tombe sur la page dédiée à Bangbash. 

Et il se trouve que quelque jours plus tard, ma fée m'a retrouvé du temps, alors j'ai attrapé ma DS et j'ai essayé de reproduire sur une grille de 32x32 les mouvements que j'avais capturé sur mon calepin.

I couldn't find my agenda, last week-end, but I did flip the pages of my blue design notebook ... I stopped on Remi's level thoughts and from there, to that page where I wrote down decisions about how to make BangBash come back. The next day, my fairy gave me some time and my Lime DS was sitting near, with a battery ready. So I opened the school zone file and tried to sketch some of the BangBash poses I had drawn in the notebook.

So here's what I've got so far. one idle animation, one jump split into prime/apex/landing sub-animations and one front smash that is Bangbash's signature move. That one could use one or two extra frames, and I'll have to draw the eyeslids directly over some of the frames to better slant with the move (and have one sprite free for the mouth ?), but I'm pretty satisfied of how it came so far.

Voilà ce que ça donne après le montage de quelques animations dans AnimEDS. Il y a encore un peu de détails à peaufiner, mais je crois qu'on peut dire que l'un dans l'autre, les animations marchent plutôt bien et qu'on peut effectivement s'en tirer sans avoir besoin de 3D. Peut-être même sans rotations. (bon, entre-autres parce que je laisse tomber l'attaque tournoyante du design originel)

Super Bilou 2

 Supposons qu'il soit possible de changer la manière dont SchoolRush affiche son encre qui monte,
histoire de laisser les 3 plans de background disponibles sur Super NES tranquilles.
On pourrait alors s'en sortir avec moins de 1024 tiles pour la constructions du niveau, et un moteur de scrolling plus classique.

Supposons encore qu'il soit possible de convertir le décor-hibou en 4-couleurs-par-tile sans arriver à une qualité décevante. Il resterait alors entre 12 et 20K de 'sprite tiles' 16 couleurs pour se faire un 'Super School Rush'. ça demanderait clairement une gestion dynamique d'une partie de la VRAM pour les sprites, mais ça semble déjà beaucoup plus cool. On pourrait par exemple garder les sprites 8x8 statiques (pieds, mains, gouttes, etc.) et se contenter d'un tableau de bytes pour encoder l'utilisation dynamique des sprites 16x16. ça reste un gros morceau, mais c'est déjà nettement plus 'viable' que demander du streaming de bouts de niveau.

I had a dream of porting Bilou School Rush to the Queen Console: the Super NES. Last study of how that could be done concluded to a bitter 'not a chance unless you've got a team of SNES geniuses along'. The issue is that I can't draw a full line of sprites on the SNES as if it was an additional plane and still hope to see more sprites through. And the inkline in School Rush DS is all made of sprites.

But the idea came back a few days ago with a striking simple observation: what if instead of changing everything to free up a layer for the ink I change the ink itself ?Like replacing the repeated wave spikes with mostly-flat ink and a crossing bigger wave every now and then ?

J'ai deux options pour ça. La première, c'est de trouver une illustration sympa de vague déferlante. Je garde de l'encre principalement plate et statique (construite par du masquage) et je fais passer de temps en temps une déferlante composée d'un gros sprite (32x32) et qui fait le lien avec un niveau d'encre plus haut par-derrière.

La deuxième option, ce serait de modifier la position verticale des sprites utilisés pour la bande d'encre (graphismes gardés à l'identique) de façon à construire un motif en créneau. Après tout, dès que l'encre couvre de toutes façon tout l'écran, peu importe que la limite de 272 pixels/ligne empêche les pieds des bladors d'être dessinés: ils sont cachés dans l'encre, de toutes façons. Il devrait y avoir entre 8 et 9 "créneaux rouges" visibles à l'écran, soit 128 à 144 pixels consommés sur le budget de 272. En fait, pour que ça coince dans ces conditions, il faudrait que les personnages à l'écran couvrent la moitié de la largeur de l'écran (quand on les dé-superpose, évidemment). Je ne pense pas que ça puisse se produire avant le niveau 4.

Eventuellement, on pourrait même imaginer forcer l'encre à rester plus plate autour des personnages qui pataugent dedans histoire de diminuer temporairement le budget-sprites qu'elle nécessite... éventuellement.

Another thing I realized is that only one part of the ink stripe consumes near 100% of the sprite-pixels-per-line budget. On the most interesting part (the spikes), we have nice 16-pixels blank space between two 16-pixels spikes. The NDS graphics absolutely don't take advantage of this, but an SNES port perfectly could. The top-part of the ink (red) then consume about 50% of the sprite-line budget and what happens as soon as the blue part kicks in doesn't matter because there, the ink is obscuring everything anyway. That will make the ink more tricky to animate, with sprites coordinates changing much more often, but that should remain manageable.

Now the next step is to ensure the background owl can still be nice to look at when using only 4 colours per tile.

Dreams/efsroot/*

Premiers pas vers mon objectif des trois "téléporteurs": j'ai une structure capable de produire un .nds qui comporte aussi bien les graphismes de la school zone que ceux de la green zone, avec un bilou.spr partagé entre les deux et la possibilité de passer de l'un à l'autre pendant un chargement de niveau.

Bon, j'ai eu droit à mon compte de p'tits bugs pendant que j'ajustais les pages de sprites à utiliser pour les monstres de la green zone, évidemment.

Et si une grande partie de ces défauts sont maintenant corrigés, il reste quelque-chose de travers avec la gestion des palettes. Pour la school zone, bilou.spr et school.spr contenaient exactement les même palettes, mais green.spr en a une autre. Et essayer d'afficher les applemen avec la palette des pendats donne des résultats pas tout à fait esthétiques.

3 rooms milestone.

My next first milestone for Bilou Dreamland will be to create a .nds where you can use doors to visit the 3 available environments. Ideally, each of the "room" (need not to be single-screen, but should stay simple) would feature the key gameplay mechanics I want to work on / repair before I go for more complete level designs. Sandboxes, in a sense.

On dirait bien que mes éditeurs sont maintenant prêts pour le travail sur Bilou's Dreamland. Support des nouveaux types de collisions et de pentes, support du choix de palette sur les deux plans. Et les spritesheets/tilesheets ont été nettoyées et prêtes à l'emploi aussi.

Il me faut donc un prochain objectif, et ce sera les trois portes salles. Une pour chaque environnement, pas trop grande, mais assez pour qu'on puisse y placer les différents éléments de gameplay critiques pour le jeu comme les cascades, l'eau qui change de niveau, le sable qui glisse, les portes, les plate-forme crocos, les branches qui plient, etc.

(Eh, CJ, ça fait penser à tes niveaux-téléporteurs du jeu d'origine, ça, non?)

Ravin' Rabbids en Perspective.

Bon, j'aimerais bien dire que je suis fan inconditionnel de Rayman, parce que c'est chouette, d'être fan inconditionnel. Mais quand j'ai vu "Ravin' Rabbids" sur GBA, j'ai bien du admettre que non. Je suis juste "fan de la première heure" de Rayman.

Je vais essayer de ne pas m'étendre sur ce qui fait que je n'ai même pas essayer de finir le 2eme monde de ce jeu, et si j'en ressors quelques screenshots aujourd'hui, c'est essentiellement pour étudier les choix de perspective dans ce jeu. Pour faire court, que ce soit le look du perso, la présence des lapins crétins ou la charte graphique des différents niveaux, j'ai l'impression qu'on a délégué la réalisation à une bande de sous-contractant sans vraiment chercher l'harmonie avec les jeux précédents ... et en particulier pas avec l'épisode 2D sur PSX/PC qui m'est si cher.

Si je prends un objet comme le livre sur lequel rayman court, il fait grosso-modo 2 blocs de haut. 50% de cette hauteur correspond à la tranche du livre et 50% servira pour la couverture sur laquelle Rayman marche. Un angle de vue très aplatit, mais qui se n'a pas l'air de coller avec l'angle proche de 45° que fait le "haut" du livre avec sa tranche.

Ignorons un instant la taille ridicule des crayons-pilliers par rapport aux livres, le rapport entre la largeur et la profondeur de leur sommet est de 2:1. Sous cette perspective-là, normalement, un cube aurait une face 'supérieure' aussi grande que sa face 'avant'. On est en pleine contradiction.

Pour les prochains niveaux de Bilou, je m'étais plutôt fixé un rapport de 6:1. Le rapport 50/50 pour la surface 'top' et la surface 'front' est confortable pour le sol de base. Le cahier dans lequel j'ai gribouillé ces notes fait 15mm d'épaisseur. Si je les ramenais à 16 pixels, une couverture de 16 pixels correspondrait à un cahier de 9cm de large. Il est plutôt aux alentours de 15cm, ce qui irait chercher dans les 26 pixels.

Essayons de 'perspectiver' la School Zone de Bilou. (bon, désolé, je repars d'une vieille capture .gif qui me donne des couleurs un peu pourries). J'ai gardé un ratio 50:50 pour le "banc" sur lequel se trouvent Bilou et l'encrier ... ce qui veut dire qu'il a en réalité une forme plus proche d'une grosse latte en bois (je prends 5mm d'épaisseur et 3cm de largeur pour nos lattes traditionnelles d'écoliers) ou de la rainure du tableau que la taille d'une planche d'étagère. Mais soit.

Les mini-livres qui servent ici de plate-forme perchées sont presque cubiques, mais on voit à peine leur couverture. Bref, c'est pas un exemple génial, mais çadonne l'idée générale.

vannes à encre

Il y a bien eu quelques "vannes à fermer" dans School Rush mais la plupart des autres niveaux avec des zones d'encre dont la hauteur est variable, l'idée est plutôt de provoquer un transfert d'une zone vers l'autre, ou de déclencher la montée de l'encre qu'il va falloir prendre de vitesse.
J'aurais bien pris un mécanisme à la Fury of the Furries (un bloc à tirer pour créer un passage), mais il ne s'agit pas d'eau ici, mais d'encre-qui-blesse. Le plus prometteur serait d'utiliser un "accident" provoqué par un pendat qui se serait mis en chasse de Bilou.

Granted, there are a few “ink switches” in schoolRush, but most of the levels sketched which feature areas with variable ink level are designed around the idea of moving ink on-demand from one place to another. Original sketches suggested pull-me-blocks directly inspired from Fury of the Furries, but this is nor water we could swim in, but rather toxic ink. I think it would work better if we instead use pendats …

Le retour de Bangbash ?

 Il y a eu un "grand absent" dans les niveaux de la School Zone jusqu'ici : Bangbash. Pourtant, il avait plus ou moins été le pillier central du redesign de la School Zone jusqu'en 2010.

Mais au contraire des pendats, jusqu'ici j'avais pensé qu'il me faudrait obligatoirement utiliser des modèles 3D pour pouvoir les afficher. Pourtant, pour "dreamland", j'aimerais bien pouvoir en mettre quelques-un dans le "niveau de rémi". Mais est-ce que les polygones sont vraiment indispensable pour son animation ?

Maybe you still remember BangBash ? If you do, I sure owe you something for it's been nearly a decade that it's been collecting dust. Back in 2010, BangBash was more or less the cornerstone of the SchoolZone redesign. Unfortunately, I had planned to use 3D meshes to render it, in a sort of New Super Mario Bros style, but neither the game engine nor the DS game tools have evolved to a point where that would happen. And it's quite a shame, because it means none of the "newer" levels can be used as planned.

idée d'animation de 'recovery' après une attaque.

La motivation principale pour un bangbash en 3D, c'était le mouvement où il attaque par rotation autour de son point. Appelons ça l'attaque latérale. Elle était essentiellement intéressante dans l'optique d'un jeu en 2.5D où elle pouvait applatir Bilou contre un mur ou l'envoyer sur un plan de jeu plus proche ou plus lointain, permettant de prendre volontairement des dommages pour rejoindre une zone secrète.

The signature move of bangbash is the front bash, where it tries to smash directly what is in front of him. The reason why I had planned 3D was that the whole game was supposed to be 3D when Bangbash was first introduced (2006). And because it had a secondary -- spinning -- attack, which would be tricy to render in 2D. But the only "interesting" game mechanics I could think of based on this spin attack was to throw Bilou into a more distant layer.

l'attaque frontale (image d'archive)

Bon, tout d'abord, c'est discutable au niveau du game design -- similaire à des faux-pics ou de la fausse-lave. Je serais tenté de dire, avec le recul, que si le "damage boost" est une technique valide en speedrun, ça ne devrait pas faire partie de l'expérience de jeu "normale" de se faire volontairement toucher par un adversaire.

But by today's gameplay standards, I don't think it would be a good idea to ask the player to take damage in order to progress -- or even to find a secret location full of goodies. That would be no different from fake spikes, which I decide I'd no longer use. So maybe I should just do it in plain pixels. After all, pendats were also supposed to be made of 3D models, and they work quite well with mere sprites. The thing will be to ensure that BangBash is sufficiently interesting while being 'only' 2D.

Ensuite, conditionner la technique du moteur de jeu pour juste une idée de passage secret, c'est franchement douteux comme équilibre effort/retour. Surtout si on projette de faire son propre éditeur de modèles 3D en plus.

Bref, Bangbash devrait pouvoir rester un adversaire intéressant même si il ne peut faire qu'une attaque frontale (ou il frappe droit devant lui, dans le plan de l'écran). Je dois faire des essais d'animation pour trouver le rythme de mouvement qui colle. A partir de là, on verra bien si le support des rotations de sprites est utile ou pas pour l'animation.

Bangbash's movements are sufficiently different from pendats, bladors and recto/verso (bouncing erasers). It moves around by hops. I've been sketching some interactions with bladors -- now the major mechanics for the SchoolZone -- including the possibility that Blador might turn back bladors at you if it see them coming.

Je dois aussi trouver une place correcte dans l'espace des comportements possibles pour BangBash. On sait qu'il peut faire trembler les crayons et certains livres au point d'en faire tomber Bilou. On sait qu'il marque un temps d'arrêt avant de frapper.

Sa vitesse de déplacement n'est pas aussi élevée que celle d'un pendat qui court et la hauteur de ses sauts n'est pas comparable avec celle d'une gomme qui saute.

Unlike other "monsters in the school zone, I also plan to make BangBash a permanent baddie. You may stun it, but I wouldn't let it be dismissed and leaving the level like you can do with pendats. That's its defining trait: BangBash is strong.

Son atout (et son "originalité") tiennent dans sa résistance. Au moment du design de BangBash, il n'était pas encore question lancer de taille-crayon. C'est devenu un des mouvements-clé de la School Zone. Il serait logique qu'on puisse mettre BangBash hors-jeu d'un coup de taille, mais ce serait aussi sympa de réduire le champs des attaques possibles. Par exemple en permettant à BangBash de nous renvoyer un taille-crayon qui serait lancé de face.

Autre élément possible: ne pas permettre l'élimination complète de BangBash, uniquement la possibilité de l'assommer pour quelques temps.

Finally, one thing that I must make sure I implement is BangBash's ability to shake some parts of the level -- up to the point where Bilou could fall from them and becomes exposed to BangBash again. Unlike the 'spinning attack' that was sketched, but never used in any levels I designed (unsurprisingly, since level design happens on paper :-P), there are a couple of places in some levels where BangBash is placed in such a way that it "protects" some lone pencils. Those would stop being interesting gameplay elements if BangBash was to be replaced by e.g. a pendat there.

Super Bilou ?

Because yeah, I can't help: the SuperNES draws me like a magnet. No matter how many times I refrain myself from looking deeper into it, I keep wondering how school rush would feel on the 16-bit queen.

But there is no easy answer. The SNES means only 128 colours for all 3 tiled layers. It means that either the ink or the owl must be patched to work with only 4 colours per tile. And it most likely mean that the twin playground layers of School Rush levels must be merged into a single one, with sprites automatically used where Bilou must enter objects like big binders.

Parce que oui, il n'y a rien à faire: la Super Nintendo exerce un magnétisme sur moi, et quelque soit le nombre de fois que j'aie décidé de ne pas m'attarder dessus, je ne peux pas m'empêcher de recommencer à me demander comment Bilou tournerait dessus. Après tout, le jeu a été conçu à une époque où les 16-bits régnaient en maîtres, et faire tourner le jeu sur une vraie machine 16-bit, ce serait la consécration. Et la Super Nintendo est à mon avis la seule machine grand-public qui serait capable de faire tourner un portage correct du jeu. La Mega-Drive et l'Amiga manquent tous les deux de couleurs ... puis je me vois assez mal demander à mon frangin de travailler sur une bande-son Mega Drive, même si l'assembleur 68000 est définitivement plus sexy que le 6502+ de la SNES.

Mais tourner sur SNES, ça veut dire tenir sur 128 couleurs pour l'ensemble des décors, retravailler l'encre ou le hibou du décor parallaxe pour qu'il ne prenne que 4 couleurs par tile, et autres contraintes de ce genre. Et ça veut dire aussi que je dois fusionner les deux couches de tiles en une seule, parce qu'il n'y aura pas assez de plans sans ça. J'ai bien tenté de faire l'encre avec des sprites ou une tranche de hibou en sprites pendant qu'on bascule un des décors du hibou vers l'encre, mais les ressources de la console en terme de sprites sont trop limitées pour ça. Ce n'est pas pour rien si les vagues des niveaux d'eau dans Sonic montrent un clignotement pair/impair ... mais je ne peux pas faire ça si je veux que l'encre ait l'air opaque.

But even with all those limitations, I feel like it would be the only mass-marketed 16-bit  that could host ports of the game. Both Mega-Drive and Amiga lack colours , and I don't feel like asking my bro to give Sega FM chip a try, even though 68000 assembly has more hex appeal than SNES 6502+ instruction set.

I tried other approaches, like using a row of sprites for the owl statue if the ink approaches enough, since there isn't enough sprite resources to implement ink waves as sprites as on the DS (more on that in a later post). But I had to come to the conclusion that merging the two layers into one is the only practical thing to do. So the next question is: how much overlap between layers is there in the levels of School Rush?

Voyons donc cette histoire de fusion. Ayant un niveau modeste en pixel art et un moteur de jeu basé sur un contenu quasi-statique de la mémoire vidéo, j'avais essayé au maximum d'éviter dans School Rush d'introduire des tiles qui seraient une combinaison de deux objets (un classeur à l'avant-plan et un morceau de bois à l'arrière plan). Au lieu de ça, j'utilisais deux plans verouillés ensembles tout en mettant les graphismes sur l'un ou l'autre plan selon les besoin. Avec le GPU sous stéroïdes de la DS (si, si), il me restait encore de quoi faire tout le reste. Ramener les deux plans sur un seul est possible parce que la SNES permet pour chaque tile dans la map de fixer sa priorité par rapport aux sprites. Reste à trouver des solutions pour afficher les superpositions. Du coup y en a-t-il beaucoup dans School Rush, et où sont-elles ?

I have fairly simple tilesets in School Rush, and used overlap to make object-bridging tiles. Merging means that these tiles now need new slots in the tileset. How many of these are there ? Can they fit the remaining space in the tileset or do I need to use virtual tilesets as I plan to implement in later versions of libgeds.

In most of the game, there is only a few tiles of overlap, in corners, often with green books or binders. These could either be done with overlay sprites or merged tiles. No problemo.

Les plus fréquentes proviennent des livres et des classeurs verts. Je dis 'fréquents', mais il n'y en a pas tant que ça par écran. Ce ne serait probablement pas pratique de construire une palette qui permette de combiner 'verts et mauves', une autre avec 'verts et bruns', etc. donc je m'orienterais probablement vers une implémentation avec des petits sprites 8x8 par-dessus le graphisme de la "couche" la plus distante de la version DS. Pas de soucis en vue ici.

Il y a ensuite une série de structures où la superposition n'est pas fondamentale pour le gameplay, voire parfois carrément accidentelle. C'est le cas avec la zone encadrée en bleu clair sur l'image ci-contre. Là une simple modification de la map suffira.

Viennent aussi les graphismes qui sont réalisés avec une combinaison de deux tiles plus simples pour des raisons de facilité, comme ce tube qui rentre dans le classeur, mais qui en réalité ne se coude pas et passe simplement par-derrière. Là, on pourra probablement se contenter d'un nouveau jeu de tiles parce que les version "simplifiées" ne sont pas utilisées telles qu'elles dans le niveau.

There are other locations where overlap allows to create sophisticated tiles with simpler ones -- like with the purple areas on the screenshot next. But in the level where I find these, the 'simpler' tiles aren't used anywhere else, so I could just have these in the SuperNES vram and that's it. Then there are locations where the level could be simplified to avoid overlap (like with the cyan area) without altering the layout of the play area.

Then there is the annoying areas. Those where we don't see parallax background layer with some wooden walls. They lead to a significant amount of additional tiles, especially given the complexity of that background (16 unique tiles). There isn't much else in these areas, hopefully. And not so many structure. Stacking sprites should work, but that makes more palettes needed. Alternatively, I would have to simplify the background texture locally and have a copy of those tiles with a simple, but opaque background.

Là où les choses se corsent réellement, c'est pour les "cachettes", ces passages du niveau où on est à l'intérieur d'un banc. Ici, n'importe quel objet qui n'est pas simplement rectangulaire introduit des nouveaux tiles. Et pour corser encore les choses, la texture de "fond de bois" prend facilement 16 tiles. On va avoir des combinaisons dans tous les sens si on n'y prend par garde. On risque de manquer de palettes si on essaie d'utiliser des sprites pour tout ça. Par contre, je pourrais essayer de faire une variante de ces tiles sur un fond opaque mais plus simple, et ajouter une variante des tiles de la texture "bois" qui permet la transition vers les objets. A condition que j'aie assez de place dans mon tileset pour caser tout ça.

Likely, the last, vertical level will be impossible to port to the SuperNES, and it is the reason why I started consuming the last 256 tiles of the 1024-tiles set.

So final move. Let's pick the latest tileset. Let's clear out all the tiles that feature only opaque pixels. Then let's clear those that are mirrors of each others (maybe not that wise, but there weren't so many of them). The result is about half the free room that not implementing the vertical level leaves. I can have two alternate (opaque) backgrounds of these. Or at least, I could if the SNES had 96 or 128KiB of video memory. But it only has 64.


Ce ne sera probablement pas le cas avec la version finale de School Rush et son niveau vertical qui introduisait justement plein de nouveaux tiles-de-raccord, mais si je m'en tiens aux 4 niveaux horizontaux d'origine, il me reste un bon quart (256 tiles) de mémoire disponible. Belote.

Maintenant, voyons un peu quelle quantité de mémoire représentent tous ces tiles qui possèdent des pixels transparents. On est dimanche soir, j'ai la flemme de scripter quelque-chose de pratique. J'y vais à la main comme un bourrin. Verdict: on pourrait faire tenir encore 2 à 3 copies de ces tiles-là dans un tileset de 1024 éléments. Rebelote.

Mais la Super Nintendo n'a que 64KiB de mémoire, à partager entre les graphismes des décors, des sprites et les "maps" (comptez 4KiB pour un écran qui scrolle horizontalement, 2KiB pour un arrière plan qui reboucle), et un tileset complet en 16 couleurs pèse 32KiB. Mon décor de hibou (534 tiles et 10 couleurs) est légèrement au-dessus des 16 KiB. Les techniques de "virtual tilesets" seront donc incontournables.

 NOTE: le côté "ouais, mais non, j'ai pas de SNES ni d'écran pour brancher une SNES dessus, de toutes façons, et les cartouches-linker coûtent bonbon" devrait pouvoir s'incliner devant un appareil comme le BittBoy. à cogiter.

16 couleurs.

Bon, c'est un peu inévitable: à présenter Bilou sur un forum de dévelopeurs NES arrive la question des "demakes" sur GBA, SNES et autres MegaDrive. J'avais déjà un peu regardé ce que ça pourrait donner suite à un commentaire de MonsieurL sur UltimateConsole, mais ni la SNES ni la MegaDrive n'est vraiment convaincante. Pourtant, il y a déjà des bibliothèques pour les aspects bas-niveau qui auraient pu être intéressantes.

Pour commencer, la MegaDrive n'a que 4 palettes de 15 couleurs, décors et  sprites inclus. Ici, dans Bilou, j'ai travaillé avec 8 palettes de 256 couleurs. Bon, on est bien d'accord, je n'utilise pas l'entièreté des possiblités, mais j'ai quand même au moins 6 couleurs de pieds (2 pour Bilou, 2 pour les Pendats et 2 pour les Dumbladors), 4 couleurs de mains, plus des livres et des fardes qui font pas mal dans le color swap. Bref, il faudrait presque considérer une réduction à 60 couleurs fixes. Il y a bien quelques palettes sympa dans ces eaux-là, ce n'est quand même pas top-sexy, comme résultat.

La SuperNES, de son côté a quand-même droit à 8 palettes de 15 couleurs pour les sprites et 8 autres pour le décor. On est déjà nettement plus à l'aise. Jusqu'à 1024 tiles par plan de décor et 512 pour les sprites (moitié moins que sur DS. On ne s'en sortira pas sans une technique façon Zmiro ou Perry) pour un total de 64KB de mémoire vidéo ... presque 10 fois moins que sur la DS. Il faudra aussi compter avec un maximum de 34 sprites 8x8 par scanline (or je fais pas mal de recouvrement) mais bon, c'est pas un bullet hell non plus. Lors des tests automatiques, j'ai au plus 70 objets actifs (pas forcément tous visibles) en même temps.

Un autre élément à prendre en compte, c'est que sur la planète PAL, la gravité est 224/192 fois plus forte que sur la planète DS. tout y est donc un peu plus tassé. Ce n'est pas vraiment un problème pour les indigènes, mais Bilou a tendance à se tasser, ce qui nuit à son charisme. J'utiliserais probablement les lignes de pixels transparents (le corps de Bilou fait plutôt 16x13  pixels au sol et 16x14 en chute libre)

Il y a donc 32 lignes inutilisées (en noir sur l'image) que je pourrais exploiter pour insérer un HUD, vu qu'on perd l'écran du bas.

Bref, Piet, si ça t'inspire, il faudrait que la musique tienne en 64K (disons 48K pour les samples, 16 pour les patterns et le player) et n'utilise que 8 pistes au maximum.

Et pour rire, avec une seule palette de 16 couleurs, on arrive à  ... quelque chose de pas complètement moche, mais quand même fort loin de l'original (bon, c'est de la conversion automatique, évidemment).

Par contre, le homebrew sur GBA serait légal dans certains pays où le homebrew NDS est frappé d'interdiction ... ça mérite qu'on y réfléchisse ...

edit : bon, j'ai pas pu m'empêcher de faire un gros montage de plein de screenshots de SchoolRush, de retirer tous les sprites et de faire "conversion en mode indexé" pour voir où on en est (avec les différentes variantes de teintes pour les livres, le sol, etc). Bin ça fait 190 couleurs en tout. Alors que la SuperNES n'en a que 120 à me proposer ... sur GBA, par contre, ça passerait sans soucis.

 edit again: oui, mais une SuperNES, ça sort un signal analogique. Et sur un signal analogique, le dithering passe beaucoup mieux que sur écran LCD. Je peux donc avoir une variante du contenu qui passera pas trop mal (moyennant quelques retouches sur les crayons qui peuvent se passer des petits pixels isolés et prendre une teinte légèrement différente de celle utilisée sur DS ... ce genre de choses).

A suivre, donc, finalement. Mais attention: la SuperNES n'a au mieux que 3 plans et ne pourra pas faire les vagues avec des sprites parce qu'elle n'autorise au mieux que 34 sprites de 8x8 sur une ligne horizontale, l'image en faisant 32 de large.

School Zone: aftermaths

Five year ago, I released a single-level "anniversary" game featuring Bilou in a school zone settings. A bit later, in early November, I had the opportunity to have it play-tested by my nephews, who were 7 to 13 years old by then. From there difficulties to approach the game, I added one "preliminary" level that is now level 1 in school Rush.

Voici 5 ans, je vous faisais un jeu-anniversaire avec Bilou dans la zone de l'école. Quelques semaines plus tard, en septembre, mes p'tits n'veux me faisaient me rendre compte qu'il me fallait quelque-chose d'autre comme niveau pour introduire les mécaniques du jeu. Ce niveau non-tutoriel est depuis devenu le premier niveau de School Rush.

Download SchoolRush - JLN build.

So yeah, the 5 levels I'm releasing today for Bilou's 25th  anniversary took me long time to make. And it doesn't even feature the level that started it all. Because meanwhile, I grew interest in speedruns, and I wanted the game to focus on going as fast as we could and save the books. Things with a focus on wandering, discovering, solving or exploring will happen in another small game.

I'm proud I could get feedback from several professionals with the 2016 release. I hope the game is better now. May there be many of you finding it, may you have a fun time playing it. This is my gift to whoever makes free software, free music, or free videos. Thank you all for making coding possible/enjoyable. 

The engine code is LGPL, the tools 'used to make it (animations and level editors) are GPL, the art and level design remain my copyrights, but they are free to play, and free to share unmodified as part as this School Rush release.

Aujourd'hui, le développement de School Rush prend fin. Ce fut long, parfois fastidieux, mais je voulais l'amener jusqu'au bout. Comme dans tout jeu, il y a des choses qui ont été abandonnées en cours de route. Soit qu'elles ne convenaient pas, soit qu'elles m'écartaient du but premier du jeu... soit qu'elles promettaient de devenir un gouffre de développement rendant irréaliste toute sortie tant que je serais en solo sur le développement. Que ce jeu soit mon cadeau à tous ceux qui ont écrit du code free software que j'utilise tous les jours, les musiques que j'écoute en codant, les vidéos sympa qui m'ont donné envie de continuer. Merci à tous pour votre travail.

I'll just update November post with the link to December contents, if you don't mind. How-to-play etc. is there. If you're looking for a changes list, it's been posted already ;)

Featured on PDRoms.de

History tracked on playeradvance, tigsource, homebrewlegends

Un peu de perspective ?

J'avais trouvé hob (runic games) totalement épatant, mais en faisant des essais pour le ramener à une vue 2D totalement à plat (façon Mario World ou SMB* sur NES), il faut bien reconnaître qu'on perd beaucoup de l'effet étrange, même en essayant de jouer sur des effets de lumière pour reproduire la perspective.

A peu près au même moment, je tombe pour la première fois sur la réinterprétation de Zelda II par Itchabop ... Je suis convaincu. ça donne plus de profondeur aux scènes, une ambiance plus close et à mon avis tout à fait utile pour la zone du chateau ou de la pyramide (et sans doute très bien aussi pour le temple perdu si jamais j'arrive jusque là).

(C) Ichtabop aka pxlitch2017

Hob's environment design works great because of hob's perspective. Itchabop's mockup of Zelda II conveys impressive atmosphere partly because of its perspective that put next to each others things that you can walk on and parts that are out or reach and mysterious.

Can I improve my skills and tools to get something similar in the desert and castle zone of Bilou ?

Du coup, je sors mon bloc à gribouille et je cherche un peu ...

Quelle perspective ?

Il faut qu'on reste dans quelque-chose de propice à du jeu de plate-forme. Je connais le système 1/3 pour une face 2/3 pour l'autre face, régulièrement utilisé pour un jeu façon Zelda "2D", mais même en inversant les proportions habituelle et en mettant 1/3 pour le sol et 2/3 pour les murs, c'est encore trop (cf. le tuyau de mario en bas à gauche de l'image). J'opte donc pour 1/6eme de dessus contre 5/6eme de face en espérant ne pas déchirer le continuum espace-plan.

I think I need something more subtle that the typical RPG perspective, where a cube's top would take 2/3 of the tile's height and the cube's front would be 1/3. Testing with Super Mario pipe makes me think that I should have at most 1/6th for the top and 5/6th for the front part to have a platformer-friendly perspective.

With those values, a 16-wide cube would show 2.66 pixels of "top" area -- okay, let's say 2 pixels of "top" color plus one pixels of shared "highlight" area.

Avec ces valeurs-là, un cube de 16 pixels aura approximativement 2.66 pixels de "surface horizontale" affichée. Allez, disons deux pixels pour le plat et un pixel de highlight partagé, puis 13 pixels "de face".

Et la School Zone ?

Oui, parce que pour avoir des images intéressante dans School Rush (et dans la school zone en général), j'ai déjà cherché à éviter les objets placés complètement face caméra, notamment avec les livres qui sont décalés. Plus question avec une élévation de 15° de choisir arbitrairement la taille de la tranche et la taille de la reliure. Il faudra que ça corresponde à un angle de rotation et une dimension de page qui soit cohérente. Ensuite, il faudra beaucoup plus de graphismes parce que si j'ai bien calculé, une section de 48 pixels de large correspondra à un décalage de 5 pixels et autant de variante d'un tile (mettons la transition bas/côté du livre) qu'on ne souhaite de dimension de livre (16 pixels plus large, il sera 2 pixels plus bas, etc.)

That's all nice for cubes and affordable for pencils, but big books will be more complex to handle. Their ratio will need to be studied more in-depth. The slopes to have will depend on the angle they're doing with the X axis, and they will lead to *much* more tiles just to cope with the vertical offset introduced. That's completely unpractical for the current engine. Another approach of how level map is turned into contents for the video RAM is mandatory to get the effect propagated back into the School Zone, and that won't happen any time soon.

Une horreur pour le game engine actuel

Pas question, donc, de pousser ça dans School Rush. Par contre, avec un game engine qui utiliserait la mémoire vidéo comme un "cache" pour un tileset plus grand, et avec un level editor capable de créer au besoin des versions "déphasées" horizontalement ou verticalement de n'importe quel tile, ça deviendrait envisageable.