Saturday, May 30, 2020

Yo Yo Shuriken par Dr. Ludos

Un p'tit coin de web bien sympa, où Dr. Ludos nous raconte l'aventure de son homebrew SuperNES: "Yo-yo Shuriken". On est dans un jeu de type 'arcade / clean-them-all' qui n'est pas sans rappeler les ambitions simples d'Apple Assault.

Le jeu est orienté autour d'un mécanisme qui titillait Dr. Ludos depuis un bon moment: un jeu de tir où on a droit qu'à un seul projectile. Après quelques essais où il faut aller récupérer son shuriken en bordure d'écran, Dr. lui ajoute un mode boomerang et le sort du cyber-ninja est scellé: il se fait voler la vedette par son shuriken. Le voilà condamné à une éternité d'anonymat.

En plus de nous raconter la genèse et le développement de son jeu, Dr. Ludos nous parle aussi du développement pour SNES version 2020.
I used [PVSNESlib] to make Yo-Yo Shuriken, so I could code it in C language. For graphics, I drew BMP images that were converted to the SNES graphics format. For audio the framework accepted wav files for sound effects and .it files (Impulse Tacker format) for music. It was still quite a challenge to make a game running on the SNES, but PVSNESlib made it a "hard but fun challenge"!
PVSNESlib, c'est le travail de papy Alekmaul, un ancien de dev-fr qui a embrayé sur les consoles 16 bits une fois que la fièvre des DS est retombée. On lui doit des portages de jeux Amiga, un assez sympathique jeu de puzzle (qui avait fait parler de lui à une compo, si ma mémoire est bonne) et la partie technique de Sidney Hunter, un homebrew original dans la veine de Rick Dangerous.

In the end, even if you use a tool like PVSNESLib, you'll need to be familiar with how the SNES works in order to make actual games for it. Hopefully the wonderful homebrew community have consolidated some very extensive documentation. I'll recommend:

Pour ma part, je n'ai pas encore commencer le développement sur SNES, mais j'aimerais que mon prochain jeu ("Bilou's Dreamland") puisse envisager un portage sur la reine des 16-bits. Je vais donc garder bien au chaud les recommandations de Dr. Ludos. Mais ce ne sera pas simple partant avec 80 ennemis à l'écran (hors des 128 possibles pour le hardware) pour ses premiers tests, Dr. Ludos doit redescendre à 40 une fois les tests de collisions ajoutés (pour tenir les 60fps), puis de nouveau à 24 pour prendre en charge un deuxième joueur et la gestion de la musique. Soit un total de 38 sprites si on compte aussi les joueurs, leurs shurikens et les explosions.

Il va devoir malgré tout ruser un peu, comme convenu avec ce genre de machines: contrairement au joueur, les ennemis ne seront déplacés qu'une frame sur 2, ce qui permet d'étaler les tests de collisions sur 2 frames. (Curieux de voir ce que PVSnesLib a dans le ventre pour gérer ça, tiens ...) Il va falloir équilibrer ça avec le temps de mise à jour disponible pendant la période de VBlank, aussi -- seul moment où on peut faire une mise à jour de la mémoire graphique sur la SNES -- faute de quoi certains éléments graphiques seront tout simplement manquants à l'écran.

Mais Dr. Ludos ne s'est pas arrêté à faire une ROM de son jeu. Il nous fait la totale, avec une boîte, un manuel et une cartouche physique soudée à la main! Amis amateurs de tubes cathodiques, vous voilà avertis ...



Thursday, May 28, 2020

Twisted Dreams and the level designer contract.

As I'm going deeper into level design analysis, I realize that there should be a sort of "contract" between the level designer (hereafter denoted "I") and the player (hereafter denoted "you"). Something that will at least feature the following items:

  • Art. 1°: I will not tease you with collectibles that are impossible to collect.
  • Art. 2°: Whenever you will die, you will know that it was your fault.
  • Art. 3°: I will not put you in a situation where the only way to keep on playing is to die.
I'm afraid we can't do that.
Many earlier games infringe those rules, at least partly. Whoever has played Commander Keen IV has at some point wondered how one could collect all those 1-UPs in the deepness of the lifewater Oasis... or that impossible-to-grab diamond at the end of Level 2 in GGS.

When you do observe art. 1° of the contract, however, placing an item somewhere that looks out of reach can be perceived as the signal that the player is missing some nuance in the gameplay mechanics. This happened in Donkey Kong Country, but I wasn't aware of the contract before I forced my way through the lost levels of DKC2 and discovered the roll-jump move.

Yes, you can!

It happened to me when playing Giana: Twisted dreams, too. There are two modes in that game: punk or cute. The punk Giana can DASH (even mid-air) and the cute Giana can HOVER. Let me call "TWIST" the mechanic that switch between punk and cute.

Black Forest did merge both TWIST and DASH mechanic into one convenient action button. If you press that button, you DASH, and if you weren't punk, you TWIST as well. Same for the HOVER button. That makes them more direct than e.g. Mickey Magical Quest approach where you use L+R to select a power, then activate it with X and finally use it with B. What I had not discovered (and almost made me drop the game) when my brother let me try the game, was the trigger that TWIST without performing any action. When you look at this gameplay video, it also becomes clear that you can TWIST while HOVERing without losing the ability to HOVER ... which is pretty un-intuitive. It can however be suggested to the player by an appropriate layout of cute-gems and punk-gems.




Sunday, May 24, 2020

Toujours dans les pentes ...

Eh oui ... on a passé la mi-mai, et je suis toujours occupé à faire tourner ces tests automatiques des pentes et à corriger l'algorithme doslopes et son intégration.

J'avais introduit un mécanisme "maxMove()" pour pouvoir obliger l'algorithme doslopes à ne pas essayer d'aller plus loin que ce que l'animation permettrait. Dans le cas contraire, il y a un désaccord entre le mouvement vertical prévu et le mouvement effectué, ce qui conduit le personnage à finir en l'air ou encastré dans le sol.

S'en est suivi une refonte de selfmove pour qu'il puisse retenir s'il y a eu un maximum appliqué (et forcer le même maximum au moment de la lecture de l'animation). Puis je me suis rendu compte que tout ça ignorait superbement les décisions du type "il ne peut y avoir aucun déplacement là-tout-de-suite", avec à nouveau des déplacement incohérents. J'essaie de le corriger, et du coup tout bloque à la première pause.

Bref, J.L.N me demandait si j'avais déjà commencé à faire des niveaux pour la pyramide, mais j'ai l'impression que ce n'est pas pour tout de suite.

edit: trouvé. Un excès de zèle au moment de lire l'animation...
edit++: les tests passent! il était temps! Je suis dessus depuis la mi-janvier... et à 23 minutes près, j'y était encore en Juin!

Sunday, May 03, 2020

Tortoise Shelve

C'est le frère jumeau de "jigé" qui m'a fait découvrir cette fonctionnalité ultra-pratique qui dépasse de loin ce que j'arrivais à faire avec mercurial en ligne de commande et l'éditeur EMACS: l'opération "shelve" de TortoiseHg.

L'idée est de passer en revue le contenu d'un futur "commit", et de choisir, patch par patch, s'il doit être appliqué ou s'il doit être gardé pour plus tard.

Confinement oblige, c'est surtout ma fée qui utilise son PC portable en soirée, du coup, j'ai un peu perdu le fil des modifications que j'avais tentées (et qui n'ont pas marché), mais il y a quand-même de bonnes choses dedans.

Ici, je peux aller à la pêche aux bons plans (les anglophones appellent ça du "cherry-picking", mais bon, ils ont aussi le piggy-backing, donc...)

Et ... oh, bin puisqu'on est là à parler de mercurial. Je viens de tomber sur un article impressionant de détails à propos des conversions requises suite à l'abandon de mercurial au profit de git par BitBucket...