Friday, August 29, 2014

Rush to Completion -- 2 levels

Cette fois ça y est: vous pouvez prendre le contrôle de Bilou dans une course effreinée à travers deux niveaux de la School Zone: voici "Rush to Completion". Et quand il n'y en a plus, il y en a encore: tout comme Apple Assault vous faisait affronter de plus en plus de pommes, ici l'encre ira de plus en plus vite ! Pourrez-vous trouver les astuces et maîtriser les rebonds pour continuer à aller de l'avant ?

Finally, it's here! Bilou: Rush to Completion with two levels (you're allowed to expect at least 2 more by the end of October). But don't let yourself fooled: every time you'll beat those levels, the pace will speed up and the ink will raise faster, forcing you to find new path through the level and to improve your skills if you don't want to drown.

Oh, don't let the interactive menu trouble you. Default way to start the game is jumping into the inkjet on the left to grab the "GO" letters. Catch the blue ball on the left if you want "kids mode" and explore the levels with idle ink. If you manage to grab one of the "ARGH" letters without touching the blue ball, you'll enter "hard" mode, with ink raising faster straight from the start. 

Oh ... and you can "keep running" by holding the R shoulder button.

Known bug: 
  • pressing START in-game will likely crash 
  • hint for running on the welcome screen are obsolete.
  • wrong colors in the "heal" bonus.

Ne m'en veuillez pas: j'ai remis le couvert avec mes menus interactifs. Attrapez les lettres "GO" pour commencer le jeu en mode normal (par exemple en sautant dans l'encrier), "ARGH" pour commencer en mode difficile, et attrapez d'abord la balle bleue sur la gauche pour démarrer en mode "facile".
Au fait, on court avec un "double flèche avant", un ado-ken ou en gardant R enfoncé, tout simplement.

Bonne rentrée à tous les étudiants. Vive l'école ;)

Thursday, August 28, 2014

Pas de précipitation.

J'ai une démo du jeu "Bilou : Rush to Completion" sur deux niveaux. L'envie de vous faire une release et d'avoir enfin des avis plus diversifiés sur le fonctionnement me brûle les doigts, mais je dois patienter encore un peu. Il y a dans le jeu un mode "tutoriel" ou "*deline" dans lequel on peut prendre tout son temps pour explorer les actions possibles parce que l'encre ne monte pas. L'ennui, c'est qu'actuellement, ce mode est activé par défaut et qu'il faudra compléter une ou deux fois les niveaux avant qu'un véritable challenge se présente pour les joueurs plus aguerris. Je dois donc ajuster un rien mon écran d'accueil pour qu'il permette de prendre le mode "*deline" seulement volontairement.

I'd love to release my "rush to completion" demo now, but I must not rush it. Right now, it would start too easy on every game, forcing you to go through repeated 3 minutes of "tutorial-difficulty". I don't want to ruin the experience that way.

Friday, August 15, 2014

Rush 2

oh well, it might turn into level 3 ...
At last, I have a second level matching the "rush game" design that accidentally arose from the "non-tutorial" level 1 crafted last december. This one won't be 4-years-old-friendly, I'm afraid, but there are still plenty of safety nets and alternate faster path for trained daddies. This is somehow giving it some Sonic flavour more than Mario spirit, but without making it roller-coaster looking where you can't figure out how you could perform better. Here, the closer you are from the bottom of the screen, the slower you'll progress (and the more likely you're to be in trouble when the ink will rise faster).

Et voilà enfin un second niveau pour le jeu de course contre la montre l'encre avec Bilou proposé par Piek suite à la disposition du niveau de prise en main construit en décembre dernier. Il plaît moins à ma grande de 4 ans, qui le trouve déjà trop effrayant malgré les "sécurités" rajoutées ici et là. Sécurités qui ne sont efficace pour la plupart que si l'encre reste gentiment à son niveau le plus bas, et qui sont disponible uniquement un bref instant pour une montée lente de l'encre. Bien sûr j'ai gardé des passage plus corsés dans le haut du niveau pour les papas pressés (et pour échapper à l'encre une fois qu'elle monte d'avantage). On retrouve un côté "Sonic" avec des chemins plus rapides mais plus techniques et d'autres plus lents mais plus accessibles ... sauf qu'ici on a en plus la convention "en haut = rapide, en bas = sûr (s'il n'y a pas d'encre)".

I still have technical issues, though. A couple of curious movements may still make you stuck into walls, despite the basics of my game engine are to avoid such situations.

I'm also very close to the maximum number of "OAMs" the console can handle. If you stun all the bladors in the level and drop them in places where they cannot recover, the barrier of 128 OAMs will explode and things will start to disappear. The solution is simple and has been post-poned for a while: manage dynamically the monsters of the level, freeze some that are off-screen for too long and start using those that are getting in-range. This is video game programming 101 since the start of scrolling games (only 10 live monsters in a game of Super Mario World while you may have 10 times more monsters on the map) but the superior processing power of the DS allowed me to be "lazy" up to now.

I'd still probably be nowhere if I hadn't quick-injected a screen copy/paste feature in LEDS. Level 3 will definitely be easier to make if I take time to ensure attaching GOBs in LEDS never break the level script (e.g. by making the attachment instruction always appearing after the two involved GOBs are created :P)

Tuesday, August 05, 2014

Corner Case

Oui, voici *encore* Bilou coincé dans un mur. A mon avis, une sombre combinaison d'une animation de transition qui tente de suivre le mouvement avec le passage vers un état qui n'est pas sensé utiliser ce type de suivi. Dans ces conditions, difficile de se rendre compte de l'évolution de la difficulté du niveau au fur et à mesure que la vitesse de montée de l'encre augmente O_o.
Ce qui est curieux, c'est que selon le "contrat" entre personnages et contrôleurs, il ne devrait jamais y avoir un "déficit de mouvement" tel qu'il puisse m'envoyer dans un mur ...

Everytime I end up with a character in a wall is an annoying proof that my tools are still merely hobby things. I wish so much they were cleaner than this. I have a nasty transanim-with-selfmove combination that somehow allows Bilou to enter a wall on walk/idle transition that disappears as soon as those transition animations are removed. So let's have them removed at the moment and have their return as a "todo" item.
A more curious case, now: bouncing from the ground (thus moving up under gravity, but not in "jump" state) allows Bilou to slightly enter the ceiling. If I then turn to another state, I'll end up merged with the level once for all ... And not even David Herdeg could pull him out.


  1. Bilou atterit, il a toujours une vitesse horizontale et l'animation tombe/marche est activée;
  2. le DPAD est relâché mais avec son inertie, Bilou va continuer à accumuler des déplacements-en-retard;
  3. au moment où il passe de "marche" à "arrêt", Bilou fait un pas quantique vers l'intérieur du mur;
  4. une fois bloqué dans le mur, Bilou y reste.
  5. Si je retire l'animation de transition, le problème disparaît. 
Chose plus étonnante, alors que j'essaie de corriger quelque-chose d'équivalent lors du choc avec le plafond: Bilou qui rebondit *ne cherche apparemment même pas* à ne pas rentrer dans le plafond: au moment où la transition "rebond/tomber" se produit, Bilou est *déjà* rentré dans le mur.

edit: En combinant le mode pas-à-pas d'InspectorWidget avec les breakpoints de ddd, j'ai pu pointer que la vitesse est correctement annulée par GravityController: Bilou n'entrera pas dans le mur. Mais au moment d'activer l'animation utilisée pour l'état "idle" (puisque dans le cas "encastré dans le coin", le point-test indiquant une collision avec le plafond est resté inactif), la position de Bilou est remontée de quelques pixels pour qu'il "s'aligne avec le sol dans ce nouvel état où il prend plus de place"... Haha. La bonne blague. La vraie solution, c'est la vitesse d'impact verticale qui est négative alors qu'elle serait positive dans une collision avec le sol. Une correction qui a déjà été utilisée lors de la mise au point de la gomme sauteuse.

Saturday, August 02, 2014

reposé.

Des corrections tous azimuts et nous y voilà: l'encre monte. C'est encore assez imparfait comme vous pouvez le voir: les vagues créées à la volées ne sont pas ajustées les unes contre les autres. J'ai aussi un retard dans l'évaluation de la position de la caméra qui provoque un traît vide quand on fait monter l'écran, mais ça, ça devrait être trivial à corriger. Bref "rush to completion" commence à prendre forme. Dommage qu'il n'y ait apparemment pas de NéoCompo cette année >_<

Fixes here, and there, and here we go: the ink moves up, stops at a desired height in the level, and looks "solid". It's not quite perfect as you can see: there are "seams" between wave sprites. There's also a glitch when tracking vertical movement, but at least "Rush to Completion" is taking shape. Too bad there won't be a Neoflash competition this year ToT

edit: au final, j'ai remplacé le "chenillard de vagues" par un système où les même vagues sont utilisées d'un bout à l'autre du niveau, mais partent s'afficher à l'autre bout une fois qu'elles atteignent la fin de l'écran d'un côté. Plus simple, plus fiable (les vagues restent toujours à une position multiple de leur taille), plus facile à mettre au point (grâce à une extension d'Inspector Widget pour passer en revue la liste des GOBs) ... cette fois, ça marche. Je me serais quand même épargné un beau mal de crâne si mon moteur de jeu avait pu m'indiquer à l'avance les zones de collisions inopérantes parce que trop larges ou les vitesses excessives lorsque les deux objets impliqués dans un "CopyCoordsController" sont trop loins l'un de l'autre.

Fun Fact: given the level structure, this specific level only need to be "rushed" for 1/4th of its length if you mastered SpongeBop moves :P

petite touche ...

Un peu mieux avec les deux morceaux de l'encre, hein ;) couvrir presque l'entièreté de l'écran n'est pas mal non plus. J'ai encore une drôle d'asymétrie provenant du fait que c'est le bord gauche des vagues qui s'aligne avec les "masters" (les bords du 'serpent d'encre'). Mais là, c'est *repos*.

I simply used AnimEDS to craft a sprite with both ends of the wave, and it already looks better. Fixing the CopyCameraCoords code so that the whole screen can be covered also improves the look, for sure. I still have an issue with the left border that creates much more dense waves due to an alignment asymetry at spawning, but that will be sorted out later.