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.

Somehow, I ended up discovering Dr. Ludos's web page where the development of his SuperNES homebrew title was revealed. The game is an arcade-inspired clean-them-all title that may remind you of my own Apple Assault attempt.

The unexpected twist in the gameplay design is to make a shooter game where you have only one bullet, so you have to wait to get it back before you can shoot again. 

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:

• The PVSNESLib wiki, that will guide you on how to set up the tools and how to make simple SNES programs: https://github.com/alekmaul/pvsneslib/wiki
• The NoCash SNES specs (technical, but thorough) https://problemkaputt.de/fullsnes.htm
• The SNESdev section of the NESdev forum: https://forums.nesdev.com/viewforum.php?f=12
  The community is very helpful and skilled. They saved my life more than once when I was making Yo-Yo Shuriken!

Pour ma part, je n'ai pas encore commencé 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.

I could be tempted to compare the game to the Berzerk! title of the vectrex era, but instead of adding walls and a labyrinth, Dr. went for more ennemy types and boss fights.

What's quite interesting is that Dr. Ludos also explain how, with 2020 tools, he developped a new SNES homebrew title, using libraries developped by former users of the dev-fr forum. I haven't started SNES development myself, but that's something I'd love to think possible, maybe with my next title, although it won't be easy.

 

Dr. Ludos started with 80 baddies on screen (out of 128 allowed hardware sprites per frame), but he had to get down to 40 as soon as collision tests were added, then down to 24 when adding a second player, and music, for a grand total of 38 sprites on-screen including shurikens and blasts. And yet, this was only made possible by moving baddies only every other frame, running collision checks on the odd frames.

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 ...

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. Yes, we can.

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 GreatGianaSisters.

Un contrat. Quand on y réfléchit bien, c'est bien un contrat que l'on établit entre celui qui dessine le niveau et le joueur. C'est loin d'être uniformément adopté, et ça ne l'a sans doute pas toujours été. Il serait constitué des articles suivants:

1. Je ne tente pas le joueur avec des bonus impossibles à atteindre
2. Si le joueur meurt, il sait que c'est de sa faute
3. Je ne crée pas des situations où le seul moyen de continuer à jouer est de décider de perdre une vie.
   

Si on respecte l'article 1, un bonus placé apparemment hors d'atteinte peut indiquer au joueur qu'il n'a pas encore compris une nuance du gameplay. C'était mon cas pendant longtemps dans Donkey Kong Country, jusqu'à ce que je découvre le ROLL-JUMP dans un niveau secret de DKC2 qui le rendait obligatoire. C'est visiblement aussi le cas avec Great Giana Sisters (ci-dessus) où j'ai cru jusqu'en 2020 que certains diamants étaient véritablement impossibles à obtenir.

Dans commander Keen, l'article 1 est totalement bafoué avec ce niveau "Lifewater Oasis". Du coup, si ailleurs je vois des bonus trop hauts, ou au milieu de pics, comment ne pas croire que c'est de nouveau un piège ?

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.

J'ai eu la même farce il y a quelques années en jouant à "GS: twisted dreams". On y contrôle soit giana-punk-qui-dashe, soit giana-cute-qui-plane. Il est cependant possible de changer de personnage pendant une descente planée, et de se retrouver du coup dans le monde "bisounours" de la punk tout en utilisant un mouvement normalement associé au monde-halloween de la cute.

Je n'ai pas vu de panneau-tuto pour ça, et pendant tout un temps, j'avais cru que le seul moyen pour changer de personnage, c'était d'utiliser le bouton d'action correspondant (DASHer ou planer). Cette fois, il aura fallu un 'let's play' pour que je m'en rende compte: j'avais fini par lacher le jeu.

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.

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!

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...