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.