Tuesday, October 16, 2018

Final Scene

Immense pardon d'avance à tous les développeurs de jeux que j'ai terminés (pas si nombreux que ça, donc) et dont la séquence de fin m'a déçu. J'en suis à l'étape de faire la séquence de fin et je dois reconnaître que c'est extrêmement difficile de contourner les limites techniques pour parvenir à faire passer quelque-chose qui ressemble à l'idée que je m'étais faite de la séquence de fin qui soit fun pour le joueur sans devenir un casse-tête complet.

Et évidemment, le blog n'aide plus vraiment à rester motivé pour terminer ça parce que 1) on est plus en 2006 et mes lecteurs sont nettements moins assidûs et 2) j'aimerais que ça reste une surprise, donc je ne peux pas vraiment faire du teasing avec les images.

13/10: une p'tite idée gribouillée sur papier pour l'écran "game over": un pendat arrive par le côté et pousse Bilou assomé dans un trou. Les lettres "G" et "O" de gameover se décrochent et viennent se placer pour faire le "GO" de l'écran titre. Retour à l'écran-titre.
14/10: bonne idée pour intégrer les derniers crédits et l'enregistrement des scores
15/10: mise au point d'un des derniers éléments interactifs qui sera quand-même dans la séquence de fin
16/10: nouvelle tentative pour la map correspondante (2x1 écrans). Peut-être un peu trop dense, par contre. La présentation de "Verso" y est simplifiée à l'extrême par rapport à l'idée de départ.
17/10: ajustements des compteur
18/10: soirée chargée IRL, mais j'ai quand-même trouvé 1/2h pour corriger les compteurs 

Et il est temps de conclure, parce que

http://sylvainhb.blogspot.com/2015/03/il-faut-que-je-finisse-school-rush.html
http://sylvainhb.blogspot.com/2017/10/finishing-steps-for-school-rush.html
...

Et please, dites-moi que j'ai corrigé l'écran bleu dans la branche "démo", parce que sortir ddd et faire des backtrace juste pour connaître la ligne de script fautive ... bof.

Monday, October 15, 2018

Bug Punch

I have one last bug (hopefully) to fix in School Rush: with the latest builds, there is an unexpected additional Bilou head showing in addition to the big punch, and stays until the “shot sprite” takes over the regular animation..

Doing some more testing, it appears that the latest unaffected build is last year’s “xmas” release. It could be something that went wrong with the refactoring, or it could be an accidental modification of the site sheet itself.

A look at the source shows that I implemented an “invisible” sprite by not picking any sprite until the 6th frame. This isn’t clean and chances are that I was exploiting some undefined behaviour. I should definitely have a dedicated command that hides the sprite through the animation that works whatever the contents of the sprite page.

Well at last, in the refactored code, there is a clean INVALID_BLOCKNO value that is set to the frame number as the GOB is created. All I need now is to make sure the sprite remains hidden until we give it another value.

Thursday, October 11, 2018

Amy Zing

It only took Ant a few days to include my little "Amy Zing" sprites into his neat labyrinth crawler homebrew, actually. For some reason, I completely missed it by then (March '18) and only realised that the game was released thanks to some anonymous internet folk who followed a link from simian zombie web site to mine, leaving a mark into the logging system which I tracked backwards to hit the page with the release.

So I grabbed the game, enjoyed it, enjoyed again, tried the various resolutions (normal is my favourite one) and smiled: that was my first ever homebrew collab as a spriter ^_^. And then started to wonder... Could such simple labyrinths work for Bilou, under gravity ?

I traced some of them in a notebook and started to check where I would put collectibles or hazards and why. In a platformer, you shouldn't (imho) try to make your labyrinth with individual blocks, because the player will need some room to manoeuver. If I pick 4x3 Bilou-sized blocks as a "maze cell" (3 blocks being a standard jump height), the maze now scrolls over 4x3 screens. You can no longer plan your move easily with that limited visibility, so you'll end up more often in dead ends and will have to back-track. Hence the rewards and hazards.

And well, Imho, with properly tuned jump distances and some wall-kick mechanics, you might not even need fancy ladders or similar tricks to support those labyrinths.

That's not quite "infinite pyramid", but it could be a nice step towards it.

edit: good news: my 5-year-old J.L.N wasn't afraid of the half-dead monkey and accepted the maze game as something to do when he's bored.

Monday, October 08, 2018

Trotôptimiser

Je voulais faire une pyramides de taille-crayons. Quelque-chose de fun, original et un peu inattendu pour récompenser les joueurs persévérant. Mais voilà. ça veut dire beaucoup de sprites ... beaucoup de collisions ... alors est-ce que le moteur de jeu va le supporter. J'ai passé déjà quelques après-midi et cogiter la chose.

Basculer entre tiles et sprites, peut-être ? ou simplement entre une version mono-sprite du taille-crayon assomé et une version trois-sprites comme celle utilisée dans le reste du jeu ? Oui, parce que les pieds de taille-crayon sont animés avec des sprites séparés histoire de pouvoir faire plus d'étape d'animations avec le même nombre de pixels, mais le moteur de jeu ne supporte pas qu'un objet existant doive acquérir ou libérer des sprites hardware au fil de son existence. Quand le taille-crayon est assommé, ses pieds sont cachés par-derrière lui alors que deux nouveaux objets d'un seul sprite sont créés pour les pieds projetés au loin.

J'aurais donc pu faire ma pyramide avec des tailles-crayons-d'un-seul-sprite. ça m'aurait permis d'en faire tenir jusqu'à trois fois plus à l'écran. Sauf que quand Bilou transporte un taille crayon, les pieds-cachés deviennent les mains de Bilou tandis que les sprites hardware de Bilou sont temporairement désactivés. Ce n'est donc pas quand le taille-crayon reprend ses pieds qu'il faudrait passer (en détruisant un objet pour en reconstruire un autre) à 3 sprites hardware, mais bien quand on ramasse le taille-crayon pour la première fois.

Oui mais et si le joueur réempile les taille-crayons ailleurs, alors ? on va se retrouver avec le même nombre d'objets mais cette fois à 3 sprites ? ça va mal finir ça.

Heureusement, un premier test montre qu'on tient toujours les 60 images secondes avec une trentaine de taille-crayons à l'écran rien qu'avec l'objet de base, tel qu'il intervient dans le jeu. Même les empilements ne posent pas de soucis, sans doute parce qu'en réalités, ils ne sont pas gérés comme des collisions.

A la place, c'est le mécanisme de plate-forme mobile qui entre en jeu, dans lequel on se contente de vérifier la relation avec l'objet auquel on s'était attaché précédemment. Les collisions proprement dites (nécessitant de comparer chacun des taille-crayons avec chacun des ennemis) n'aura lieu que depuis les tailles crayons qui tombent.

Je m'inquiétais donc pour rien. Par contre en en profitant pour mettre un générateur de pieds-baladeurs dans le niveau, J'ai compté jusqu'à 28 pieds générés sans que l'émulateur ne tombe sous les 55fps (la DS serait donc probablement toujours à 60), mais par contre après ça, il y a trop d'objets à gérer et certains d'entre eux ne sont tout simplement plus affichés (un bug bien connu du moteur de jeu actuel, contre lequel il n'y a pas grand chose à faire à part éviter d'en arriver là par le level design). Bon à savoir je calibrerai mes générateurs de pieds en conséquence, un peu comme j'avais fait avec les générateurs d'applemen dans Apple Assault.