Bounce ?

That training level made me realise the issue I had with Bilou's bounce on
land. Quite often, I ended up falling in ink pits because I've landed "hardly" near the edge of a platform, bounce, and fall to my doom. I first thought that I had to make sure the bounce only occurs when falling "from high enough" (thus never occuring when you land back at the height you jumped from), but it's more severe than this.

Rebondir quand on atterit, c'est rigolo. Se voir finir dans une mare d'encre parce qu'on a pas pu l'empêcher, par contre, ça l'est beaucoup moins. Et ça ce produit plus souvent qu'à son tour si j'utilise le comportement "anniversaire" de Bilou dans le nouveau "niveau d'*deline". Je vous propose donc 4 variantes du gameplay avec pas (No), peu (Low) ou beaucoup (Big) de rebonds et éventuellement la possibilité de convertir le rebond en un saut complet en ré-appuyant sur (A) pendant que Bilou fait sa pirouette. Quelle version préférez-vous ?

• [Big] I could keep it as is and call it a (gameplay) feature
• [No] I could dismiss bounce altogether, or make it happen only as an "idle" animation (when player is not pushing Bilou forward) 
• [Low] I could dampen the bounce: make it so that you bounce with a vertical impulse of 200 rather than 400 (800 being the impulse for a full jump
• [Jump] I could compensate the lack of control during a bounce by granting the player to reuse the "lost 50%" later (e.g. mid-air) in a sort of "double jump".

Which is the one that works the best for you ? download the test suite and vote in the poll. (the [Jump] option is implemented in SchJumpBounce.nds, etc.). See release notes for the anniversary level for "how to play on DS/ emulator".

NB: in "No" and "Jump" at least, you should be able to keep running while holding the R trigger (à la Mario).  In "Low" and "Big", the R trigger makes you run only if you're already walking.

Prise en main.

Entre courses de Noël et les soins pour son p'tit frère, les nerfs de *deline commençait à devenir sérieusement tendus. Et moi, j'étais trop naze pour pouvoir la distraire dans Epic Mickey fraîchement prété par mon frère ou sur ce "bon vieux" Zelda: Link to the Past ... Heureusement, quand j'ai proposé "et si on faisait un niveau de Bilou spécial que tu pourrais finir toute seule ?" la réponse a été "oh ouiii!"

A much more cozy first encounter...

J'avais ma petite idée au préalable de ce que je voulais obtenir: quelque-chose basé sur un fonctionnement simple (mot-clé "avancer") avec un petit quelque-chose de "Bilou Origins" dans son design simple de plates formes qui se suivent mais ne se ressemblent pas trop. Je voulais aussi que le niveau puisse servir dans un jeu de course contre la montre où on aurait eu de l'encre dont le niveau monte pour forcer à progresser -- ce qui permet au passage d'éviter un effet "tutoriel" en offrant suffisamment de diversité d'action pour qu'un joueur expérimenté puisse traverser le niveau rapidement et avec fun.

Playing "Epic Mickey: Power of Illusion" reinforced (if that was ever needed) the feeling that I want a no-tuto game, where things can be learnt while playing. But right now, the "school zone, level 1" (aka anniversary level) fails to provide an environment for that. So along with my 4-year-old *deline, we crafted a level where each monster and mechanics are introduced one at a time. 

The resulting level layout is very unusual for a Bilou level, being all-flat-go-to-the-right, which is somewhat reminiscent of Pierrick's "Bilou Origins" game mentioned this summer. It's not yet perfect: the very first jump proved fairly difficult to clear for *deline, her younger cousin and for my fairy, but after a few more attempts, all of them -- none being used to Jump/Run games -- managed to go to the middle of the level. Elder kids (including Remi who previously snobbed the anniversary level) managed to reach the GOAL, after which they seem much better prepared to face the anniversary level. I still have some edges to polish before releasing, but I'd say the mission is already a success.

Au final, le niveau se joue assez bien, encore qu'il reste un peu cru et peut-être finalement trop dur sur la fin, avec un effet "interro surprise" qui rebutterait un enfant qui parviendrait à arriver à ce point-là... correction en cours.

Journal de Link : le monde des ténèbres

(C) by Necos

C'est un cauchemar ! J'ai d'abord cru que j'hallucinais, vu que j'étais tout rose avec des oreilles de lapin, puis j'ai été soulagé de constater que je pouvais revenir dans mon monde. J'ai survécu de justesse à un monstre reptilien cracheur de feu en lui éclatant son masque pour le barder de flèches ... Je croyais que les gardiens des médaillons étaient terrifiants, mais ils ont l'air de poulets mignons à côté des créatures qui hantent le monde des ténèbres. Ces monstres borgnes qui semblent ne jamais manquer de bombes ... ces "choses" électriques qui me poursuivent en flottant. Ce ne sont que pics et carapaces qui me foncent dessus avant que j'ai eu le temps de finir d'ouvrir la porte ... même les plantes et les pierres peuvent être redoutables!

Puis il y a ce cristal... j'ai cru que c'était quelqu'un, mais depuis que je l'ai ramassé, il m'a l'air tout à fait ordinaire. J'ai d'abod essayé d'oublier tout ça, de trouver refuge dans la petite clairière où j'allais jouer quand j'étais gamin... Mais chaque fois que je reviens dans notre monde. Chaque fois que je jette cette maudite "épée légendaire", la même fillette de 4 ans reviens me la mettre dans les mains et lève sur moi ses yeux bleus encadrés de boucles d'or et me dis très sérieusement "Charly, tu dois retourner dans le monde des ténèbres! Tu dois sauver la princesse Zelda! Arrète d'embéter les cocottes!"

Pourquoi moi ? Je ne m'appelle même pas Charly, en plus!

Et ce temple de l'eau qui ne veut pas s'ouvrir ! ...

Shrink and Grow!

It's somewhat time to allow my game "objects" to take the "drink me" bottle and to change size as the game goes. Well, they can already do so. Well, they can already change size, but it usually result in characters stuck in walls, since the coordinates doesn't change.

Jusque là, si M. Miyamoto était revenu me voir après sa pause-déjeuné au Palais du Champignon Chinois, j'aurais bien tiré la tête en l'entendant dire "Mario géant, on ne va pas le faire géant dès le départ: il aura une taille comme dans Mario Bros. et il deviendra géant seulement après avoir attrapé un champignon. C'est bien connu: ça pousse vite, les champignons". Si mon éditeur d'animations me permet effectivement de changer la taille de la zone occupée, le fait que la position du personnage (de son coin supérieur gauche, pour être précis) reste identique l'envoie plus souvent qu'à son tour se faire emmurer.

So despite I'm feeling as dizzy as an egg, I managed to update the game engine so that you can now indicate which edge of your character should stay in place when coming from a state where the major hitbox (the one which is used to test collisions against the world) has a different size. At last, that allows Bilou to adjust his position as the inkjet shrinks while preparing a "blow".

Mais cette fois, j'ai enfin intégré une amélioration du moteur de jeu trop souvent retardée: premettre d'indiquer sur quel bord/coin de sa zone le personnage doit s'aligner. Ça me permettra prochainement d'ajouter de sympathiques animations pour l'aterrisage de Bilou (comme Lazycow l'avait suggéré). Plus directement, ça me permet enfin de décaler légèrement Bilou vers le bas quand un encrier se prépare à le propulser en l'air ^_^

Merry christmas.

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.

Le journal de Link : 3 médaillons.

Me voilà embarqué dans une curieuse aventure. Tout le monde à l'air de croire que les contes de grand-mère sont sur le point de devenir réels! J'ai
aidé la princesse à sortir des cachots du chateau avec l'épée de mon parrain et maintenant me voilà à courir des ruines au désert pour essayer de trouver des médaillons (plutôt chouettes, d'ailleurs) qui devraient me permettre de tirer l'épée légendaire des bois perdus. Seulement, quelqu'un au chateau n'a visiblement rien compris à l'histoire puisque tous les gardes ont l'air d'en avoir après moi (je leur trouve un drôle d'air, d'ailleurs).

Je me sens un peu patraque, par contre. Ça doit être la 4ème fois que je me réveille dans mon lit en étant persuadé que j'étais déjà au désert ... Je devrais sans doute mettre un peu de remède de la sorcière dans mon tout nouveau bocal "magique", mais j'essaie d'économiser pour une paire de palmes.

Ah. Ça y est, j'ai enfin trouvé le dernier symbole dans le livre des anciens: "prière"... donc ... euh ... "la voie s'ouvre au coeur juste en prière" ... Je crois que je préférais quand s'était juste des dessins.

Au fait, un certain "PypeBros" est arrivé à la taverne du village et me dit de vous dire que "faire tout ça avec un clavier dans zsnes c'est loin d'être pratique" ... comprenne qui pourra.

3D: X Why Z ?

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

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

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

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

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

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

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

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

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

2D + 3D = ^_^

After some clean-up and tweaks, I got the 2D+3D setup properly initialised in my test level. Nothing useful rendered so far: just a NeHe tutorial triangle that rotates as you press the DPAD in various direction without interfering with the 2D game. I still have to re-arrange memory banks before I can get textures, though. And I'll have to move around the owl-school background which was currently mapped on the "BG0" layer, the only one capable of 3D.

Quelques règlages ici et là, et j'y suis: un premier polygone (non-texturé) affiché en symbiose avec le moteur de jeu 2D. Tout ça fonctionne évidemment mieux quand on essaie pas d'activer la 3D à 3 emplacements différents dans le code. Je vais devoir à nouveau ré-organiser quel-layer-est-utilisé-pour-quelle-fonction ... ça devient un brin lassant, je vais faire une couche d'abstraction, ce coup-ci.

That starts sounding like I should introduce an abstraction layer so that the following things manipulate a "logical background" rather than physical registers directly:

• setting up map/tile VRAM addresses in GameScript
• scrolling registres in InfiniMap
• setting priority in runme

There was activity about the controling log display this summer ... It should allow me to flip between BG and log quite transparently.

edit: huzzah! it works!

edit: game engine fix is done. Runme adaptation will have to follow (and will likely be a bit more tricky). Real bugger will be the "fade sequence" which used BG1 (now used as "farground") to hide the screen content while re-loading the level ... I'll have to use another technique like window registers.

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.

Let's get Z !

How about going crazy and sampling the support of 3D in my current game engine? I don't mean adding a 3D world nor even so-called 2.5D (2D motion in 3D display as in Relminator's last submissions), but simply the use of 3D hardware to render things such as pendats body, swinging ropes or falling books (much like in NSMB, actually).

After checking my version of desmume (0.9.6, custom build) had support for 3D, I'm merging some NEHE tutorial with my core loop to start some video resource management here and there... and it looks like I'll have somewhat work to make them integrate seamlessly, as I lost all my extended palettes (hence the all-black sprites) and likely the "owl background" in the process.

Quel est donc ce trio de triangles qui semblent avoir volé toutes les couleurs du monde de Bilou ?? Eh bien ce sont les 3D qui ne s'interfacent pas encore très bien (hum ... euphémisme ? ^^") avec le reste du moteur de jeu. Comme le mode 3D a ses propres interfaces, il me faudra quelques soirées en plus avant de commencer à avoir quelque-chose d'exploitable, sans doute.

WYSIWYG level

I had a bullet point in my "todo-before-release" list saying that the level shall be WYSIWYG -- the accronym for "What You See Is What You Get", which is just a coder jargon for form-fits-function. You see a solid structure, there is a solid structure. You don't see any, that's because there isn't any. No invisible wall, no subtle tunnels.

Unfortunately, I did have such a tunnel in my map. Tracking them right now means I have to scan the whole level in "meta-tile" mode. That's not quite comfortable and it proved unsufficient as I regularly break further the map when trying e.g. to adjust colors or fix some buggy pixels. Look at what I found yesterday on my on-going map: a hole dug into a wooden block that would make you walk into the should-be-solid area! How could that happen ? Simply because I tried to fix some un-esthetical combination of tiles.

Veiller à ce que le niveau ait effectivement des murs partout où des murs sont dessinés n'aura pas été une mince affaire pour ce niveau-anniversaire. En fait, je manque cruellement d'un outil capable de m'assister dans ce genre de tâche et il faut passer en revue le niveau en mode "propriétés" après chaque modification. Même un correctif purement cosmétique peut affecter la structure du niveau parce qu'un nouveau graphisme sur l'avant-plan va détruire les propriétés construites précédemment.

Il y a donc une sorte de "méga-raccourci" dans la version g88 qui fait très étrange (on se promène à moitié noyé dans le bois :P) et en voulant corriger une incohérence graphique (image ci-dessous), je me suis retrouver à introduire un nouveau "bug dans la matrice" (image ci-dessus). Bref, il est temps que j'équipe LEDS d'une sorte de radar permanent qui me permettrait d'avoir une vue un peu plus large des propriétés du niveau en cours d'édition qui se combinerait avec une map plus complète sur l'écran d'accueil, de sorte qu'il soit possible de positionner la fenêtre d'édition au stylet, visualiser l'emplacement des différents monstres, etc.

What's especially tricky with this map-bug is that it won't reveal easily when play-testing: Bilou slightly leaps when leaving the edge of a structure, and although it's technically small, that leap is large enough to clear one block. So you won't fall in a 16-pixels hole unles you hardly try and jump to align Bilou on the hole.

So it's now time I implement the "mini-radar" feature, at least able to show 64x64 tiles centered on the current editing screen, with 1 pixels for 1 tile.

• WelcomeWindow : down screen, prompt file names, etc.
• TileWindow : down screen (swapped up during edition), with TileTables for showing tileset content. [done] here be a mini-map of what we're editing.
• [todo] cleaner integration, widget laying on TileWindow although fed from MapWindow
• MonsterWindow, MapeditWindow both on the "up screen", with sprite memory already heavily loaded and the whole tileset present to show the content.

A new RadarWindow appearing together with WelcomeWindow (and thus on the 'up screen' when it's truly up) would be welcome to check whether we don't have broken structures just before we save/play the level, with a full level.

A block too far.

Dix blocs à franchir ... Ce second obstacle continue à rebuter, mais ça devient plus facile à gérer. Dans la version g88, il était indispensable d'arriver avec la bonne vitesse sur une petite gomme. Sauter trop tard (en courant), c'était l'échec assuré. Ne pas courir, c'était arriver à coup sûr trop court.

I guess many have cursed that row of pencils in the g88 "anniversary" level. One thing I wanted to fix is that not only it required a master-level of the RUN and JUMP mechanics, but it did not provided a way for the player to build that mastery. Jump too late, and you'll end in spikes. Fail to run, and you'll realise quite late that you don't have the speed to clear the jump.
I experimented two approaches that make the obstacle easier to clear: the first one is widening the bouncing zone, which in turn reduces the stress on the timing. The second was to move the bumper away from the pit, so that missed attempts can be cancelled by the player.

Pour rendre ce saut plus facile à apprivoiser sans en tuer la difficulté, et maintenant que Bilou peut courir de façon fiable, il y a 2 choses sur lesquelles je peux jouer. D'abord, la largeur de la zone-bumper: un bumper plus large donne plus de souplesse au joueur sur le moment où il va sauter. Ensuite, un "filet de sécurité" entre le bumper et le début des crayons. De cette façon, le joueur qui a mal jugé de la distance de son saut garde une possibilité de revenir en arrière.

These two adjustments to the level make it more learning-friendly, but most of the challenge remain. Either you manage to RUN-JUMP as desired, or you find the alternate, safier route. For the next release, I'd like to grant player with the ability to feel empowered and have a laugh at the challenge, by power-ups, of course. You could either start the level with 5 hitpoints or pick one (random?) power-up before you enter it. That could be done through some form of DASH mechanic, or possibly a way to break more easily through that chalk-barrier, etc. Of course, I wouldn't have a "fix-them-all" item: if you get the ability to undermine _some_ challenges, you'll have to rely solely on your skills on others.


Enfin, avec l'augmentation de la vitesse que Bilou peut atteindre en courant, il est possible de passer par-dessus les pointes des crayons simplement en courant et en sautant, y compris en prenant "par le haut". Celà n'empèche que pour une prochaine release, il serait intéressant de proposer des "power-up" au joueur qui lui donnerait la liberté de bouder l'obstacle, même sans le contourner par le haut.

Entretemps, j'ai pris le contrôle de la course de Bilou, de sorte que je gère la vitesse maximale qu'il peut atteindre (suffisante pour franchir les 10 blocs de justesse sans l'aide de la gomme) et qu'on peut se mettre à courir en faisant un double-dash dans une direction (à la Kirby) ou en donnant une impulsion vers le bas pendant qu'on marche ou donnant un coup de R.

Fine-tuning.

Raw as raw can be: here's a collection of "todo items" related to the "20 years anniversary level" that has staid draft since my first re-contact with the BilouCorp. It's not very sexy, but at some point, gameplay fixing is also those kind of fine-tuning.

• [done] BIGFALL Camera: a maximum vertical speed of 7 for the camera is a minimum as Bilou's maximum vertical speed is near 6 (pixels/frame). It feels better when the camera is controlled by the DPAD (holding down when falling) rather than activated automatically when reaching a specific velocity. With those settings, the player has 0.5 second between the time pencils appear at the bottom of the jump-of-(fai|dea)th and contact with the ground. half that time is required to manoeuvre Bilou away by 16 pixels, that leaves ~0.25 seconds of reaction time to the player.
• [done] Spongebops appearing on the bottom of the screen due to wrapping of the Y coordinate by the DS hardware (?) mislead the player into believing that there's an invisible sponge that will reveal if they jump into endless pits.
• [wish, AskTheTeam] Bonus room with a "hidden exit" should better be replaced with a room that offers a limited time to collect all the items and brings you back to the level when completed (as in DKC). Until the engine can support that, make sure the room's exit is as close as possible from its entry, so that realizing that you can't come back through the path you picked doesn't prevent you from going further with the game.
• [done] Chalk do break, much more easily than pencils. Use some chalk picture for the break-through platform on the desktop.
• [done] Add an 'onscreen' controller that triggers an event when an object gets offscreen, so that 'stunned' animations can be completed and items no longer "magically disappear".
• [done] with a horizontal top speed of 540, running becomes enough to clear the pencil-pit area: no more bouncing-on-bumpers or grabbing-sponges is necessary. with momentum limited at 480, it is still feasible to clear the pencils, but it requires to jump when Bilou's first feet is already out of the safety area, so the bumber is "safier", and it could be made more in the middle of the platform as initially designed, so you don't necessarily fall into the pencils if you miss it.

Croyez-le ou non, mais j'ai réussi à recontacter la "Bilou Corp", et j'ai donc une toute nouvelle toudoulisse pour le niveau-anniversaire. C'est un peu brut, vous m'excuserez peut-être un jour. Plein de petits règlages à faire: les vitesses de caméra quand on tombe, le remplacement du crayon-qui-casse par une craie-qui-casse, etc.

horizontal position.

What if one reason for players failing to clear the large-pencils-pit was that they can't predict what's ahead? With the 'G88' release of the anniversary level, Bilou was tightly centered on the screen (horizontally). So tightly that you could barely see a few pixel of the other side even though you dangerously adventured over the first pencil.

Cette fois, j'en ai, des retours de beta-testeurs. Au point que je ne suis plus la cadence pour le blog lui-même ^^". J'ai passé un certain temps à faire des ajustements sur le système de caméra, notamment pour faire en sorte qu'on ait une meilleure vision sur ce qui nous attend. Cette rangée de crayons, à droite de Bilou, saura-t'on la passer en sautant ? Faut-il courir ? Faut-il chercher un autre chemin ? délicat à décider si on en voit pas la fin, hein?

L'occasion donc de refaire un tour d'horizon et de voir où sont positionnés les héros dans les jeux de plate-forme qui me servent de référence. Commençons par New Super Mario Bros et ses variantes: Mario est (du point de vue horizontal) au centre de l'écran. Dans SMB3, c'est l'arrière de Mario qui est au centre: il tire véritablement la caméra derrière lui, ce qui lui donne l'occasion de faire un demi-tour sans à-coup de caméra qui donnerait la nausée au joueur. Simple, donc mais aussi paradoxal: le joueur voit mieux les obstacles qu'il vient de passer que ceux qui restent à venir.

But what is the behaviour of canon platformers ? It looks like NSMB always center Mario and it feels fine. True, but NSMB can zoom out when you will need more vision of what's going on. Plus, I'd bet you could beat any level without running. Large leaps with the RUN button held down are on alternative paths only. For the record, SMB3 was even weirder: Mario litterally pulled the camera behind his back! Granted, that allow for smooth turn backs, but that somehow kills visibility. Hopefully, the Racoon suit can save you from unforseen pits ^^"

À l'opposé, Rayman PSX se situe presqu'à 1/3 de l'écran, ça donne bien au niveau de la composition d'image (disent les artistes) et ça dégage la vue. En revanche, ça fait un fameux travelling chaque fois que le joueur se retourne. Si ce n'est pas trop délicat dans la majorité des niveaux, en revanche, ça rend les combats contre les boss particulièrement agaçant puisqu'on les perdra de vue presqu'immédiatement après avoir essayé de s'en écarter. Il faudra se retourner à nouveau pour savoir quelle attaque ils préparent (ou retenir l'enchainement par coeur).

Rayman goes a bit extreme when placing the hero almost on the 1/4 boundary of the screen. True, you'll get good preview of what's ahead (and that's very welcome), but if you have to move back and forth, it will quickly annoy you with wavy behaviour. And you'll have to move back and forth *a lot* when fighting bosses. Even worse: your position on screen is not based on your state (staring left or right) but on your (last) speed. When swinging or on mobile platforms, the camera may suddenly shrink your vision of what's ahead by 50% at critical instant. Donkey Kong Country (which also has the character near 1/3 of the screen) solves this my centering your Kong perfectly when he's on a swinging rope.

Autre hic, le système de caméra ignore en réalité dans quelle direction Rayman regarde: il ne connaît que sa vitesse. Du coup, sur une plate-forme mobile qui fait demi-tour, votre visibilité devient tout d'un coup réduite de moitié sans que vous ne puissiez rien y changer >_<.

Un qui m'a surpris, en revanche, c'est Super Mario Bros. sur NES. Bien sûr, le jeu n'autorise pas la marche arrière, et on pourrait donc "fixer" Mario à 1/3 de l'écran pour avoir une bonne visibilité sans souffrir des défauts de caméra de Rayman. Pourtant, à vitesse de marche ou à l'arrêt, Mario se situe au-dessus du 8eme des 16 blocs que l'écran affiche. 1/2 écran entier devant soi, en somme.
En revanche, dès que l'on se met à courir, l'écran se centre différemment et ramène Mario d'un bloc en arrière, libérant un peu plus le champ de vision.

I've been quite surprised, however, to see the behaviour of SMB on the NES. Since the game always moves to the right, I'd have expected Mario to be somewhat near 1/3 of the screen. But it's not. It's almost centered (it pushes the screen center with his nose, rather than pulling it with its back as in SMB3) *unless you run*. As soon as you gained significant speed with the RUN mechanic, you've been moved backward by 1 block.

Bien sûr sur SuperNES, l'habitude était de proposer au joueur de regarder en avant et en arrière avec les boutons L et R, mais j'aimerais garder ces boutons pour faire tourner Bilou dans tous les sens. Le coup de SMB1 m'a donc donné l'idée de laisser continuer la caméra pour qu'elle se centre en avant de Bilou lorsque celui-ci s'arrête. Le joueur n'a donc qu'à marquer une pause s'il veut savoir ce qui l'attend ^_^

Since I want to keep L and R for later purpose, I came up with the following idea: why wouldn't I use the "idle" state to change the ideal camera position ? Do you want to see more of what's ahead ? just relax, wait a little bit and that will be shown to you ^_^. I adapted the camera system so that it become feasible, and tweaked the parameters so that you don't get jerky camera motions when doing funny things like "turn back while jumping before the camera settled on your idle position", but I think it's now working nicely. I hope it will pay off for the future beta-testers. There's something similar in DKC, btw: when entering a barrel, the view is shifted somewhat more towards the blast's direction

L'avis de Joke

Longue session de beta-testing hier avec Joke de la BilouCorp -- une corporation sans lien direct avec mon personnage fétiche mais néanmoins fort sympathique et versé dans la conception de jeu vidéo -- si bien que ce matin, je passais le démarrage du niveau en mode "image par image" pour comprendre d'où venait ces "à-coups" quasi systématique quand on descend de la latte pour aller se mesurer à notre premier crayon.

• il sautille un peu sur la descente de la règle au début
•  … la caméra ça va je trouve
•  ça manque d'effet sonore pour les sauts et rebonds 
• le premier saut qu'on doit faire d'un crayon à l'autre avant le pot d'encre, je remarque qu'on peut pas y arriver si on ne se tourne pas d'abord dans la bonne direction
• La gomme du crayon c'est volontaire la possibilité de passer derrière ? le fait qu'on soit propulsé en sautant quand on est dessus n'a pas l'air de nous aider à passer. il faut prendre de l'élan je pense, ça complique les choses

 Il y a deux ans, j'aurais plus ou moins considéré ça comme du temps perdu: ce sautillement ne gène en rien le gameplay... mais ça fait tache et en plus, c'est la première chose que le joueur va voir du jeu. Donc, je creuse à grands coups de ddd avec la méthode désormais bien rôdée de "je m'arrête avec Inspector Widget dans la situation qui m'intéresse avant de mettre mes breakpoints".
Après une bonne heure d'inspection méticuleuse, j'arrive à la conclusion que le code du moteur de jeu, des contrôleurs etc. est 100% clean: c'est dans l'animation que ça coince. Pour une raison encore inconnue, une des étapes d'animation force le déplacement à être horizontal plutôt que de s'adapter à la pente en cours ... bizarre, bizarre.

Je ressors donc mon "extracteur d'animation en vrac (à perforation en vrille): il y a en effet quelque-chose de louche avec les animations de marche de Bilou. Les étapes d'animations qui se comportent bizarrement ont un bit "déplacement vertical autorisé" qui reste à zéro. Chose intéressante: le pendat (qui était incapable de suivre les pentes) a systématiquement ce bit à zéro. Dumblador, lui a son bit "déplacement vertical autorisé" mis pour chaque étape.

J'aurais été bien incapable de dire en aveugle à ma fée quelle manipulation elle aurait du faire pour changer ce règlage dans AnimEDS, ce qui signifie que c'est un des contrôles-candidats pour un menu déroulant ou quelque-chose de ce genre.
En fait, c'est le petit "!" devant "y" qui doit être retiré pour "déverouiller" l'animation verticalement.

Mais alors ? Si ce sont des règlages au niveau de l'animation (et pas d'une étape isolée), pourquoi cet étrange étape verouillée dans la marche de Bilou qui ne l'est pas pour le reste ? Sans doute parce qu'il s'agit de la liste de commandes générée pour permettre de boucler la boucle, et que son code n'a probablement pas eu droit à sa mise à jour (ouuuuh ^^").

J'édite l'animation en hexadécimal dans Midnight Commander ... Je recompile à cloche pied ... Bilou retient son souffle: c'est l'heure du test fatidique ... attente insupportable de 15 seconde pendant que la caméra re-traverse le niveau à contre sens pour venir se centrer sur Bilou au départ.

Ah oui! Bien mieux! La descente est fluide, la remontée aussi... Il me reste à aller corriger AnimEDS, donc.

Fixing Monsters

Walls ? Caves ? Where ?

I mentioned earlier a post on frogatto blog about the danger of setting the bar too high for your monsters adaptiveness. E.g. it would be pointless to develop A* pathfinding so that lakitu can track you in a caves maze. Yet, when I explained Didier that I froze development with a list of fixes before the next release and things that would be allowed to be missing, he raised an eyebrow at his son's game screen and wondered in a laugh whether an eraser stuck on the ceiling, twisting like a fly in a spider's web qualified as "it doesn't stop moving for some coder-could-guess reason".

(/metagolf) Si le sommet d'une gomme touche le plafond d'une plateforme, elle y reste parfois coincée. J'en ai shooté une avec un taille-crayon et elle a reculé de manière statique jusqu'à atteindre un mur. Peut-être revoir la FSM ?

En effet. Et ce n'est pas le seul point sur lequel Armitage, concepteur de MetaGolf, a raison. J'avais suivi le conseil des dévelopeurs de Frogatto et prévu mes monstres pour qu'ils aient le bon comportement (sauter, faire demi-tour, continuer à sauter) dans le bon environnement (sol plat, ciel dégagé, faible brise au NNO ...). Mais que le joueur passe par là et ouvre la route vers le bas du niveau et les gommes peuvent le suivre -- bien qu'en général, elles éviteront puisqu'elles sont programmées pour éviter les trous.


The thing is I crafted RectoVerso's behaviour so that it should stay confined in some area, and ensured no issues could arise in those areas ... i.e. the ceiling is high enough, and discontiunity of the ground -- rather than walls -- define when RectoVerso turns back. But at some point, by opening the path to the lower part of the level, you also allow some RectoVerso to enter a place that wasn't designed for them: ceilings, books stacked onto each other, etc.
Playtesting showed that it happens more often than I'd ever have expected, so I took the time to fix those testpoints.

RARE! Rectoverso went down!

Qu'est ce qui change, donc, entre la version qui marche et la précédente ? L'utilisation de l'enregistrement de la vitesse d'impact en cas de choc (GobGravityController), et remise à zéro de cette valeur après qu'elle ait été utilisée pour que le contrôleur n'hésite pas à la ré-enregistrer au coup suivant.
Avant, toute impossibilité de continuer à avancer pendant un saut était interprété comme "arrivé au sol", maintenant, on se sert de la vitesse d'impact pour détecter l'arrivée dans un mur horizontal (impact_x <> 0) ou dans un plafond (impact_y < 0).  

PS: because blador can sit in wall when carried, it can also be thrown while being in a wall. Can we do something to fix this ? Yes! just update freemove mask makes him stay within the level. If we truly want so, it could also repel Bilou if getting too close (e.g. don't end up with Blador hiding Bilou's body completely when getting into a wall.

Die and Retry ?

J'ai pu rassembler quelques feedbacks sur le niveau-anniversaire cette semaine, dont celui très attendu de Pierrick... et ce premier Novembre aura aussi été l'occasion de voir le mode "essaie de battre mon record" à l'oeuvre avec les cousin(e)s d'*deline. Je pense que la citation de Pierrick reprend bien la première réaction de la plupart des joueurs:

C'est du pur "die and retry" (c'est pas évident)

Die and retry ... le jeu impitoyable façon Rick Dangerous ou "Les Schtroumpfs d'Infogramme". C'est loin d'être mon modèle, mais c'était clairement celui de mon frère 2 ans avant le niveau de la School Zone quand il dessinait les niveaux de Calimero.

Où sont donc les "coins infogrammes" dans mon jeu ? La chute en aveugle un rien avant la fin du niveau peut clairement en faire partie. J'ai bien essayer de montrer la trajectoire idéale avec des bonus, de sorte qu'il faille prendre le risque de s'écarter de la trajectoire sûre pour faire de gros points mais qu'on soit quand-même guidé vers la zone d'atterissage (presque) sûre...

Really ? is the 20-year anniversary level "die and retry" in the sense of Infogramme's Smurfs, where you have no chance to identify something as being a hazard before you die because of it ? There's cleary a jump-of-faith near the end of the level, where you have to blindly jump and even good reflexes will not give you much chance to evade death if you happen to be on the "wrong side" of the fall. Well, actually, with good reflexes and knowledge of the evasive move that replace invulnerability in my engine, you still can get out provided that you have enough energy remaining.

En revanche, à regarder les enfants de mon beau-frère (6, 10 et 12+ ans) s'essayer à tour de rôle, je constate que dès le début du niveau (et donc du jeu), il est indispensable d'avoir la maîtrise des actions pour ne pas finir empaler sur les pointes de crayons. Les consignes du style "ah, ici, il va falloir courir, sauter au bon moment et ré-appuyer sur A quand tu touches la gomme et garder A enfoncé pour faire un saut assez haut... oui, avec les gouttes d'encre, c'est pas facile, il va falloir partir au bon moment. Aïe. Non. Trop court. Saute pour sortir de là .. encore .. non. trop tard. Tu ferais mieux d'essayer par l'encrier la prochaine fois. Allez, à ta soeur, maintenant."

Mais ils persistent. Ils s'entrainent... il faut dire qu'il n'y a pas grand chose d'autre à faire à part regarder maman finir son cacao chaud. À la fin de l'après-midi, seule la plus jeune continuera à éviter ce "saut de la mort". Ma prochaine mission sera donc de faire un "niveau préparatoire" que même *deline, du haut de ses 4 ans, puisse essayer de finir.

Real-life testing with 3 of my nephew yesterday still turned out to be successful. Having only a few hitpoints before they had to hand the game to their sibling pushed them to improve, and while their initial steps were hazardous and punished by frequent death on the second or third screen, they managed to master the not-so-easy controls (press B timely to grab the sponge, hold it, then quickly release B and press A to clear the first jump). Somehow, the level is missing a sort of preliminary sandbox if I wanted it to be newbies-friendly, but it worked as a good playground for siblings arcade-like competition. Excessive sandbox place would have likely led the youngest to stick in the sandbox and avoid going where the challenge stands, killing the fun for the older kids.

Par contre, un testeur seul de 14 ans, le verdict est assez sévère: après avoir manqué le saut de la mort et le passage des éponges, j'ai droit à "t'as plus le jeu avec yoshi?"

edit: lors d'une discussion approfondie avec Pierrick,

 Bien Rick Dangerous... Tu ne peux pas savoir combien de fois je me suis pris la première rangée de crayons pointus avant de comprendre qu'il fallait se servir de l'encrier pour contourner le problème.

Visiblement, quand un joueur (même drilé au mégaman et autre mario) arrive à ce premier trou, la solution ne vient pas d'elle-même. Courir n'est absolument pas devenu un réflexe à ce stade du jeu. Il faudra que j'en tienne compte dans mes prochaines release.

Comparé au non-tutoriel de Super Mario Bros (les 2 premiers écrans), mon niveau contient au moins deux erreurs criantes.

Le premier crayon ne se contente pas d'être un ennemi à vaincre en sautant par-dessus: il faut une bonne maîtrise du saut pour contourner ce personnage relativement haut et sur lequel on ne peut pas atterrir sans se blesser. En plus, contrairement au goomba, il peut faire demi-tour et devient alors d'autant plus délicat à dépasser. Seule consolation: en le faisant s'approcher un peu plus de la pente initiale, il devient possible de réduire la hauteur du saut nécessaire. (Dans la version g88, le crayon reste un rien trop loin de la latte et on retombera le plus souvent sur sa pointe plutôt que de parvenir à l'enjamber sans heurts).

Compared to SMB level 1-1, I noted the following design mistakes. The first pendat you encounter is not simply a monster you can defeat by stomping it. Actually, you cannot defeat it. You must avoid it, and this is not quite as easy as avoiding a goomba, because it is only a few pixels lower than your maximum jump. Moreover, unlike a goomba, the pendat may turn back just as you jump over it. You don't simply have to estimate the proper jump time given speeds, but also given positions and memorize where the turn-back occurs. I had hoped that the slanted ruler at the start of the level would give Bilou some advantage to make a good jump, but it ends up being a bit too far, and the player is more likely to fall straight on the pendat's spike than clearing the jump when trying to jump off the ruler.

Then comes the first jump-over-the-pit challenge, which is again abnormally complex. You must both run (still an emergent behaviour at that prototype state), jump, and bounce to the maximum height to clear it. Your first attempt is for real. There's no such thing as a "practice area" where the spikes would be replaced by a mere staircase. And if you'd change your mind and decide to look for an alternate path, it is too late: the alternate path is only available *before* you can see the challenge arriving.

Ensuite, le premier saut à effectuer (par dessus les pointes de crayons) est complexe puisqu'il implique à la fois de courir, sauter, rebondir et faire un long saut. Et pour de vrai! ici, pas de "trou pour rire" façon monde 1-1 pour se rendre compte qu'il convient d'être prudent.
Pire encore, le "chemin alternatif" devient hors d'atteinte quand le joueur se rend compte qu'il ne parviendra pas à passer par-dessus les pointes de crayon! (Forcément: c'était un passage secret).

Enfin, si un adulte pratiquant couramment l'Anglais et rompu au jeux vidéos depuis 10 ans n'a pas sais que l'on pouvait courir et avec quelle manip', c'est que ma manip' est contre-intuitive et doit être renseignée plus clairement. Je dois prolonger l'effort sur la gestion de la course de Bilou.

Fly, you fools!

Fly, you fools!

The way Bilou runs in the anniversary level was emergent behaviour for the given set of rules: it wasn't designed to happen: Bilou has just started to run on its own because no line of code was there to prevent him to go beyond the momentum's maximum speed.

Parmi les retours que je commence à recevoir du niveau-anniversaire, le côté peu pratique du démarrage de la course revient assez souvent. Moi j'avais bien aimé la façon dont il "suffisait" de faire "gauche->droite" dès que je me suis mis en tête "il suffit d'aller plus fort vers la droite" pour parvenir à courir, mais en fait, c'était loin d'être un choix de ma part. En fait, on pourrait presque dire que Bilou a appris à courir tout seul: c'est un un comportement résultant des règles définies que j'ai décidé de ne pas corriger plutôt qu'une fonction explicitement ajoutée dans le système.

Mais pour pouvoir donner une animation dédiée à la course (indispensable pour que l'utilisateur ait un feedback clair avant de faire un saut dangereux) et une façon fiable d'atteindre une vitesse donnée, je dois reprendre le contrôle. Mais comme vous pouvez le constater sur cette mini-vidéo, ça va me prendre un temps de midi de plus que prévu ...

But as I try to make him truly run, with a dedicated animation and such, it looks like he took Gandalf's quote "Fly, you fools" a bit too litterally ...

edit: with InspectorWidget's help, it's now fixed. And with Cyril doing more testing on a built where both "<->" and ">->" making you dash to the right, it revealed that at some point, people will start running when they intend to slightly turn back to avoid collision. That's not only un-intuitive, but dangerously counter-intuitive. I need to get it removed.

G88 and the sound is gone!

For some reason, slide effect Gxx in music track wasn't played properly. Let me investigate ...

• ::playRow() checks EFFECT_PORTA_NOTE. It will complain about instruments that change, then, capture the cell's note as "target note" and record the slidetune_speed from parameters. The playing note in the channel remains unchanged, although the "pattern cell" has the new one.
• ::handleEffects() is for per-row effects. It also process some "volume column effects", but PORTA_NOTE is a "per-tick" effect.
•  but I have checked that the PORTA_NOTE (effect #3) happens always on the 'regular' column.
• xmtell.pl confirms there is a note on the cell that has PORTA_NOTE. Yet, when processing the row to setup channel state (including target note and slide speed), the cell mentions having EMPTY_NOTE ^^".

Reason ? The musical cells in an XM pattern may either be stored as is, or packed using a "magic bytes" that indicate which fields (effect, volume ...) are present and which are missing. For some reason, libntxm code was resetting the note to "EMPTY_NOTE" when the cell was stored in plain mode. I'd say there was no chance 0xt0b could debug that properly since he had no effects support -- thus likely only tested modules with no effects (where no cell can ever be "complete", obviously.

Pour éviter des bruits désagréables entre deux notes de la mélodie, mon frère a utilisé assez abondamment les effets de glissé pour enchaîner deux notes sans relancer le sample depuis le début. Mais dans la release d'origine, ces notes étaient curieusement silencieuses. Après pas mal de bourlinguage dans le code de la libNTXM d'0xtob, j'ai fini par me rendre compte que c'était lié avec la présence de "cellules pleines" (avec une note, un volume, un effet et ses paramètres). C'est maintenant réglé, ce qui veut dire que vous avez bien mérité une version révisée du niveau anniversaire.

Now, I have another issue with G00... parameter value 00 for an effect means "same value as the last effect" I used to do that on demand when processing per-tick effect, but for porta-to-note, I need to apply it earlier, when the finetune speed is defined.

So, enjoy g88 revision of the anniversary level.

• camera control with UP and DOWN dpad directions;
• improved spongebop bounces;
• fixed music;
• fixed crash/stall upon level reload.

Some bugfixes in progress

After a couple of days checking the stats, I opened the editors again. I wanted to experiment alternative collisions for Spongebop and improve the readability when falling down. I updated camera control so that UP/DOWN DPAD directions can be used to adapt camera (that was quite simple)

I think I tracked down an unpredictible crash on level loading. The crash only occured when reseting the level just after some droplets (the only object that turns into nil) gets deleted. Engine::delanim() should remove the object from the deleteme list in that case, not from the todo list. I also fixed another potential source of silent random crash linked to the lack of dedicated "you're dead / level clear" tracks :P .

Allez, quelques petites modif's avant d'aller au lit. Le nouveau comportement des collisions avec l'éponge, pour commencer, suivi d'une meilleure gestion de la caméra pendant les chutes (Morukutsu appréciera ;) puis la possibilité de regarder en haut et en bas quand on est à l'arrêt ... c'est toujours sympa, dans un jeu d'exploration.

J'ai du débugging sur la planche, aussi. Certains effets de glissés de la musique ne passent pas, les notes en questions restant du coup silencieuses et une sorte de condition de course logicielle pouvait planter la console si on avait le malheur de changer de niveau juste après qu'une goutte d'encre n'ait été retirée (à quoi ça tient, quand-même!)

I could also point out that the inconsistences in the music comes from module effects to be ignored. They should explicitly be supported! that's a task for ddd and --arm7gdb=7777 ... As soon as I got that sorted out and get the confirmation by early downloaders that the game can be launched, I'll post a fix.

All this reminds me, of course, of the "last minute panic" I got when I tried to enable throw-bladors-anytime (3 days before the release) and observed  curious effects: parsing the second level would then corrupt memory (most likely) and make the level loading impossible. On one of my machine, that made the std::map that holds BlockInfo to have an invalid pointer.
Hopefully, once that bug turned "stable", identifying the root cause was a mere "sherlock holmes game": list all the possible causes for one more state transition to corrupt memory, rule out those that are incompatible with the observed behaviour and you get pointed at a "owned" bitfield that has incoherent value (and still rules which transitions are deleted when).

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.

School level delivered!

Enfin nous y voilà. 3 ans après 'Apple Assault', un nouveau jeu Bilou est sorti. Enfin, "jeu" est excessif: c'est une démo jouable comme vous auriez pu en trouver avec votre magazine PC-Fun préféré dans le milieu des années nonantes. Avec un seul niveau, il n'y a par exemple aucun moyen de reprendre de la vie ni de regagner des vies. J'ai pourtant d'excellents souvenirs de la démo de Prehistorik 2 avec son compteur de pourcentage d'exploration. Nous nous étions donc mis en chasse des dernières plate-formes invisibles et bonus cachés jusqu'à parvenir à un 100%. C'est ce genre d'ambiance que j'ai tenté de reproduire dans le niveau-anniversaire mis en ligne hier.

Looking back at the former releases and the completed todo lists initially left me with some bitter taste: since March, it looks like nothing significant has been achieved and that almost all the features were present in the "usability test demos". Reality is somewhat different. Even the month spent exploring SMW and incentives for "alternate path" was the key to level re-design. There *was* some significant progress on the reliability of my SEDS/LEDS/AnimEDS tools. when monsters are randomly altered after every save, when you have some animation that may disappear under some circumnstances, when the map may be erased by a misplaced click, the odds that you manage to craft a level featuring 20 monsters are weak. Shaping up to 54 unique animations is only possible with some convenient numbering scheme.

Hopefully, those 6 monthes made the tools reliable and the additional month made the level appear. Let's celebrate ^_^.

Et dire que depuis Mars dernier, il me semblait de n'être nulle part, puisque presque toutes les modifications apportées au moteur de jeu dataient de 2012. Et pourtant, du changement il y en a eu: tout ce "rush" sur le niveau-anniversaire n'aurait jamais été possible avec des outils aussi peu fiables que ceux dont je disposaient en début d'année, succeptibles de perdre ou d'écraser le travail accompli à la moindre fausse manoeuvre.

I was concerned about the lack of variety in my tileset. One book here, one binder there ... wooden structure, metallic items, spiky pencils. At the end of the level, I started feeling repeating myself. If a level 2 was required, I'd need more variety, shadows, and such similar things. That's especially blatant in those confined areas where the scrolling background is not visible. Hopefully, I'm not near 80% of tile space as I initially thought. I merely used 50% of the space, because many object got dismissed as "drafts" as I progressed (greyed/translucent areas).

Le niveau dans lequel on se promène tente de respecter le plus fidèlement possible le design d'origine (1994) créé par mon frère, mais remplace régulièrement les "clés" et les "interrupteurs" abstraits par des interactions entre personnages. Par contre, au niveau graphismes, je dois admettre que sur la fin du niveau, je tournais un peu en rond. Pour continuer à construire la School Zone, il me faudra d'autres objets. Et là, soulagement de dernière minute; je ne suis en fait qu'à ~50% de l'espace disponible. Du côté des sprites je devrais pouvoir compter sur le doublement de l'espace disponible (j'utilise 64K sur 128), mais il faudra "expliquer" ça à l'éditeur de niveau.

I will have to do similar cleanup in the "sprites" memory or upgrade to full 128K of sprites (the hardware allows it, LEDS won't like it :P) if I want to have the full set of animations of pendats with pixel art (initially, 3D was planned) or if I want to have spinning sponges once on the ground.

Quite amusingly, many aspects of the monsters behaviour where "hacked" during the release-rush through creative use of the current game engine and level editor -- such as undermining some platforms so that monsters see them as holes while Bilou can indeed walk them -- where I'd have in normal hobby development extended the game engine with dedicated features to support the desired behaviour (such as a monsters-wall that Bilou can move through).

Si je suis parvenu à boucler ce "niveau jouable" en 2 mois alors que je travaille sur la school zone depuis Septembre 2011, c'est entre-autres que je suis passé sur une autre approche: chaque fois que c'était possible, j'ai rusé (par exemple en trouant le sol sous les pieds des Pendats pour leur faire faire demi-tour à l'emplacement souhaité) plutôt que de chercher à étendre le moteur de jeu (p.ex. avec un mur invisible pour les monstres). à retenir.

Et maintenant ? Quand tous les confettis de l'anniversaire auront été balayés? Bien sûr il y aura un peu d'emballage nécessaire pour permettre à mes p'tits n'veux de faire leur propres niveaux: manuel d'utilisation, blocs supplémentaires pour les vies et les soins, par exemple. Sur une autre branche, proposer une réalisation de "Deep ink pit" malgré tout pourrait s'avérer sympa, encore que le concept du jeu n'était pas aussi riche que celui d'Apple Assault. Enfin, il serait temps de s'attaquer à la 3D, histoire de permettre aux crayons de poursuivre Bilou et d'introduire le fameux Bang Bash qui, en février 2006, introduisait le jeu vidéo Bilou dans la blogosphère...

Oh ... et il me faudra un écran "sound test" pour comprendre les effets curieux qui se produisent sur les musiques ces temps-ci.