README: The Sprite Decade

Présenter l'architecture des consoles, du gameboy à la XBOX ... rien de moins que ça. Voilà le contenu qui vous attend depuis 2020 si vous cliquez sur le lien "Copetti" dans la liste "blogs I watch" de cette page. Et oui, la Nintendo DS s'y retrouve ;)

C'est déjà quelque-chose, mais Rodrigo Copetti -- l'auteur du site -- n'en est pas resté là: il a commencé à rassembler ses articles pour nous proposer des version imprimées des bouquins... et j'ai donc craqué pour "The Sprite Decade" qui reprend les machines 8 et 16-bit de Nintendo et Sega auxquelles s'ajoutent la TurboGrafX (aka PC Engine) et la Neo Geo.

Bon, c'est vrai que pour la NES, j'ai déjà le bouquin de Nathan Altice: I AM ERROR, et la SuperNintendo est largement couverte par les vidéos de Retro Game Mechanics Explained. Mais les avoir un peu toutes sous la main, pouvoir retourner voir la vue d'ensemble sur les propriétés de l'une et l'autre ... c'est un bouquin bien pour moi. Bon, j'avoue, j'aurais probablement ajouté encore d'autres détails techniques parce que bah ... on ne se refait pas, mais c'est une bonne base. Une sorte de syllabus de cours sur lequel j'ai déjà commencé à prendre des notes pour me faire ma référence des consoles rétro.

Puis je dois bien l'avouer, il y a une autre raison qui m'a poussé à acheter ce livre: je voulais voir comment il rendait. Parce que je n'ai pas encore abandonné le rêve de convertir un jour tout ce texte en une version linéaire sur papier. Et bien, ça rend rudement bien. La prise en main est bonne, la qualité du papier nickel, un rien velours... Et Rodrigo a travaillé sans maison d'édition, un peu comme Jill Bearup (qui a du 18:6 entre le prix de vente de sa version Amazon paperback et ce qu'elle en retire)... ce qui pourrait peut-être intéresser M. Jared qui cherchait un éditeur/imprimeur pour son bouquin sur le homebrew sur Nintendo DS (justement). 

Un bémol, toutefois: pour offrir une taille maximale à certaines images, Rodrigo a décidé de les imprimer en format paysage ... sur un livre version portrait. Si ça permet effectivement d'avoir plus de détail sur les photos des circuits imprimés de chaque console, ça me semble discutable pour la photo de la NES dans sa boîte en plastique, et c'est franchement dommage pour les différents schémas d'interconnection entre les composants. Le texte est disponible aussi sous github, mais pas les images...

Bon, et non, je ne suis pas devenu fan d'Amazon pour autant. A vrai dire, j'ai même failli passer mon tour quand j'ai vu que le site me réclamait pas loin de 20€ de frais de port et douane pour un bouquin à moins de 30€ ... Puis vérification faites, Rodrigo Copetti nous écrit ça d'Ecosse ... donc en passant par Amazon.fr, mon édition est finalement imprimée en France et mes frais de port me sont offerts. Donc, force et courage aux camarades qui luttent pour des conditions de travail honnêtes dans les entrepôts. Des que je trouve un moyen de soutenir les chercheurs/rédacteurs sans contribuer à votre oppression, je pousse sans hésiter sur le bouton, m'sieurs dames. 

Hydrocity pixel waterjets

Bin ça! Il y avait un parfait exemple de jet d'eau dans un jeu 16-bit dans la série Sonic, et j'étais complètement passé à côté! Heureusement qu'il y avait Tim pour poster une photo de son Anbernic Arc-S pour me remettre sur le droit chemin!

L'effet est plutôt convainquant, plutôt utilisé comme script de transition/narration entre 2 phases que véritablement comme un élément de gameplay interactif, mais ça reste pertinent. Il reste un peu moins de 2 secondes à l'écran avant que Sonic ne soit propulsé plus haut tandis que le jet redescend et sort du cadre.

Last year, I was looking for 16-bit references of a water jet and I couldn't find anything satisfying, but it seems like I completely missed those location-transition-events in Hydrocity Zone act 1 of Sonic 3. I hope you'll excuse me: my memories of Hydrocity essentially resume to "this place hates me". Trying to keep enough air in Labyrinth Zone wasn't easy, but it felt possible and a sort of appropriate final challenge in the game. You'll completely miss the water jets if you're watching a speedrun or any competent player as well: they're sole purpose is to bring back upwards player who failed to stay on the high dry path.

ça se passe dans Hydrocity, la deuxième et parfaitement imbuvable zone de Sonic 3. Il se trouve que j'ai le jeu sur une cartouche combo Sonic Genesis 2D pour NDS et j'ai donc fait l'effort de retourner jusque dans Hydrocity, mais sans encore arriver jusqu'au jet vertical pour me rendre compte par moi-même.

Il faudra pour ça, une fois le jet horizontal passé, que je m'aventure dans les profondeurs jusqu'au couloir avec les hélices qui nous poussent vers la droite. ça malgré les pics, les poissons mal foutu et les tapis qui nous ramènent en arrière juste quand on est sur le point de pouvoir reprendre de l'air ... C'est beau le rétro, mais là, c'est quand même pas loin de l'abus vu qu'on est encore qu'au 3eme stage du jeu ... 

For the era, they seem to work surprisingly well. They only need 4-colors palette cycling, and are even somewhat light on tiles consumption, with a 32x32 pixels pattern (plus mirroring) for the trunk and 32x48 for the top (and even one 16x16 block of the top being shared with the trunk). You've got one big arc per pattern, which clearly works better than the repeated pattern of Mc Donald's Treasure Land Adventure. (although, this is not the worst water animation in that game ...). Note too how the top part uses the raster in opposite direction so that it feels that water is falling down there. (yeah, obvious, I know)

Bon, mais trève de rouspétances, regardons ces pixels. l'artiste s'est concentré sur un motif d'arc répété avec un dégradé plein de tramage (plutôt une bonne idée sur la technologie CRT de l'époque) pour finir par un arc de cercle plus arrondi où le dégradé est mis à contre-sens.

Le tout est évidemment animé par palette cycling ... ça vaut mieux vu la surface à prendre en compte. A noter aussi la grandeur du motif. On a pas essayé ici de faire de petites vagues répétées: la partie "champignon" est constituée d'un seul dégradé ! Du coup, c'est bien l'effet "mouvement" qui prévaut sur l'effet "clignottement".

The pattern is rather noisy, but that shouldn't be a big issue for the CRT screens it is designed to. Given the size of each area, the motion illusion prevails over the flashiness. At least when played at 75% of the intended 60fps. Maybe it also worked at 60fps on CRT screens (we had 50Hz here, so who knows ...). 

All I can tell you is that it took me dedication to bring Sonic in the proper spot(s) of Hydrocity on my Sega collection for Nintendo DS cartridge and on the 3DS LCD screen the result was ... meh ... mostly getting a averaged blue tint all over the jet, the pixels staying in place for most of the 2 seconds where we see the jet, with my brain saying "ah! I spot the pattern!" rather than "wah! That's blasting fast!".

So well, it was a nice reference at the time. I mostly works because you're taken off-screen once the jet should retract and because it's a one-time event rather than what I need (a trigger-on-demand event) or what Mc Donalds and Bubsy games needed: an platform going up and down continuously.

J'affronte donc une deuxième fois le niveau, fort de la carte mémorisée ... il y a surtout des zig-zag imposés à toute allure entre les deux jets d'eau du niveau 1 (aucun dans le niveau 2, qui a besoin de ces tiles-là pour nous mettre plus de toboggans). Je peste contre les poissons-pirhaña qui m'empêchent de sauter pendant plusieurs secondes alors que les bulles d'air ne sont suffisamment grande pour respirer qu'à partir d'un sonic du sol ... je choppe un bouclier-bulle ... je le perd ... je suis propulsé une 2eme fois.

Eh bin, les gars, l'effet "mouvement", à 60fps sur un écran LCD, il est un peu perdu dans la bagarre ... on voit juste une trombe bleue d'une couleur plus ou moins uniforme tellement ça va vite. Un peu déçu, je vous l'avoue.

Cosmic Boll by Yoritoshi

There was a twitter account I held for later while leaving the network: it had a yellow ball avatar, and I remembered a few nice exchanges with somebody doing a platformer featuring a yellow ball, but I couldn't find any track of those exchanges. I ran out of keywords idea to grep my tweet.js and blog.xml ... I asked my contacts for help, but I still wouldn't find it.

But eventually, in the "more tweets" online document I've been crafting, I found back the picture I wanted, where cosmicboll (and not bowl or ball) encounters a waterfall and the water pushes it (him?) down, increasing gravity. Something I don't have yet for my own waterfall and that definitely looks and feel fun.

The game is not from that person with the yellow ball avatar but from the Spanish-speaking developer Yoritoshi, who has been working on the game since at least 2018.

The small snippet I have here may give you the feeling that there is some Sonic legacy in that title, and likely Yoritoshi's videos will convince you even further, since some of the sound effects featured are raw samples from the megadrive titles.

Petit résumé pour mes lecteurs francophones: La balle jaune dans le gif animé ci-dessus est le personnage principal du jeu "cosmic boll" de Yoritoshi, dont j'ai suivi de loin le développement au fil des tweets. On aurait presque pu appeler le jeu cosmic Brawl, vu l'importance que les combos et la variété des attaques dans ce qui aurait pu aussi non passer pour un Sonic-like. Le jeu est téléchargeable en version Windows sur le site itch.io du dévelopeur et je n'y ai pas encore joué.

Avant les premiers tweets présentant ce jeu-là, l'auteur travaillait sur des fangames Sonic, bien intégré dans la communauté, étendant le travail d'un certain "LakeFeperd" et participant à la convention SAGE régulièrement.

It is even stronger when you get a look at the level editor screenshots that Yoritoshi published: there are ramps, there are loops and all ... There are some explanation in the earliest tweet using the #cosmicboll tag:

Began to add enemy characters of my own to replace the dummy from LakeFeperd's engine with, but I hope CF2.5 doesn't pull any nonsense on me when I add hitboxes to their attacks. (Jan 20, 2018)

LakeFeperd's own video often mentions SAGE event, and if we dig deeper than the video about "Spark the Jester", we see that they are about Sonic fan games... So yeah, people gather to show each other their Sonic fan games (and likely fanart and play sonic games and plenty of blue things), there are Sonic-targetted game engines for many different game construction kits, and Yoritoshi was already doing that in 2012.

But Cosmic Boll is not just a Sonic clone. Actually, the gameplay does not feel that much like Sonic. The amount of attacks you have at your disposal to dispatch foes is just impressive. If you believed "Kirby Fighter mode" has a large range of attack, Cosmic likely features 2 or 3 times as much moves. The amount of enemies per wave and the hitpoints per enemy is clearly designed to make the fights a key moment of the game and feel overpowered. And then there are "orbs" you can collect which will e.g let you turn into a fireball when you dash or shoot firewaves when you punch.

And there apparently also are special gadgets that allows you to make surprizing things like sizing down ennemies, althought I have to admit I haven't understood everything about that.

Land on Slope

There are many things that got fixed over my holidays, and many things that remain to be done before I can claim the 3 rooms "done". I had to pick one for the last week-end ... it seemed wise to pick something that I'd likely not have enough focus to work on during the evenings of a regular week. "Land on slopes" seemed the right one to pick.

Il y a pas mal de choses qui restent à arranger avant de pouvoir cocher la case "démo avec les trois salles de test", et ça malgré toutes les choses qui ont pu être corrigées pendant les vacances. Alors pour ce week-end, pourquoi pas s'attaquer à l'atterrissage sur des pentes ?  

So far, only the "walk" (behaviour) controller is aware of slopes. For the rest of the code, the world is all made of square tiles, and the properties of a tiles are homogeneous over that square. The result is that if you try to land from a jump on sloped ground, you're very likely to end up floating over the ground until you start walking.

Jusque là, le seul bout de code qui s'intéresse au pentes, c'est celui qui contrôle le comportement "marcher". Pour le reste du moteur, une pente, ce sont des pavés carrés comme tout le reste. Du coup, si vous faites un p'tit saut pendant que vous étiez sur une pente, il y a de fortes chances que vous finissiez en flottant au-dessus du sol ^^". 

J'ai passé la journée d'hier à faire des va-et-viens entre le débuggueur et le compilateur pour essayer de comprendre ce qui se passait, mais c'est sans espoir tant qu'on ne saura pas tomber à travers les tiles qui constituent les pentes... A cogiter.

I gave it a first try yesterday, opening the debugger, seeing what happens when I'm entering such a tile, designing a patch, compiling it, trying it, discover that it wouldn't work, refine it, and repeating the cycle. Over and over.

It wouldn't work. First because the slope tiles couldn't be fallen through. There's no need to try working around it: they *must* be made fall-through. Second because slopes are currently complemented by walk-through-but-don't-fall-through blocks that ensure smooth walk, but interfere with falling. I had that discussed with the Undisbeliever in the past, as it was a difference between our implementations, and the solution will be to replace them with a 'sloped' ground that actually is square.

But the ultimate reason of my failure is that I was trying to provide a solution for 'fall on the sloped ground' as if we'd have the last row of tiles all made of F_SLOPE tiles. The reality is much more diverse: there are so many 'corner' cases that we can hardly call them 'corners' at all.

Mais même avec cette nouvelle propriété et même avec des blocs carrés qui disent que "oui, en vrai, on est des pentes, mais des pentes plates. haha", ça ne marche pas encore. La solution que j'avais prévue suppose que le sol sur lequel on veut atterrir est constitué d'une brave rangée de tiles de type "pente". Mais comme vous pouvez le voir sur mon petit croquis, il y a pas mal d'autres combinaisons qu'il faudra aussi prendre en compte. 

J'ai une idée pour remplacer ça ... il faudra que je la teste. Elle n'est pas sans me rappeler (ce que j'ai compris) du moteur de Sonic, d'ailleurs: considérer toute la colonne de tiles par-dessus la nouvelle position souhaitée pour le "hot spot" et calculer la "hauteur du sol" dans cette colonne.  

I have a replacement design sketched, which I'll give a try in the afternoon. Amusingly, it looks a lot like what (I've understood) happens in Sonic the Hedgehog engine: consider the whole column of tiles on top of the desired 'new hot spot position' and figure out the 'ground height' in that column. Then make sure the move planned so far doesn't work past the ground.

Do that every time. If done right, it doesn't matter how many sloped tiles were encountered when checking that we cando() the move.

Well, that was the plan, but for some reason, it is not yet quite working. And for some (possibly other) reason, it managed to break walk-on-slopes despite my care to avoid so.

edit: fixed

Smashing pixels

I did a few tries to render the heavy punch smashers for the pyramid in SEDS, and most of them were deceiving. My best render So far was crafted with the Gimp using the style and palette of an inspiring Sonie-like indie game dubbed "Kyle and Lucy".

Since I had a day off yesterday, I brought them back on top of my Pyramid level mockup. After all, the pixels for the Smashers were all mine. They just needed to be moved out that Kyle-and-lucy environment.

I also took the opportunity to try another approach: some structures in the School Zone are made of wooden, gianthands. What if I turn then upside down? Can I get something Convincing by Shading them with blues and pretend they're now metallic?

 

Bon, ceux-ci ne sont pas les premiers gros-poing-écrabouilleurs que je tente, mais les précédents ne ce sont pas vraiment révélés concluant (#euphémisme. Voir ci-dessous). Mais là, je retombais sur un screenshot de Kyle & Lucy sur lequel j'avais profité de la palette pour redessiner un gros poing d'un autre genre alors que j'avais toujours mon mockup "desertcolor.xcf" ouvert. J'ai fait un test. 

Et tant qu'à faire, j'ai essayé un autre truc que j'avais en tête: retourner le poing-pillier de la SchoolZone et lui donner une teinte blue-métallique, histoire que ça ne fasse pas trop bois. Les avis sur twitter sont assez unanimes: c'est le gros poing du bas qui gagne. Par contre, un truc de cette taille en métal, ça ne fait pas fort égyptien. L'histoire a beau ne pas se dérouler sur Terre, je prends note: je m'en tiendrai à un gros-poing en pierre.

I haven't been running any twitter poll this time, but I still managed to gather interesting comments. Generally, the bottom puncher are perceived superior to the recycled school-zone structures flipped and recolorized. Of course, I should have X-flipped them for coherent lightning with the rest of the scene.

Among others, Joke@bilouCorp pointed out that Egyptians did not have the technology to produce large metallic structures. That's both quite irrelevant (since Bilou's pyramid is nowhere near the Nile and not even on our planet) and super-important, because I want people to feel like if they were in an Egyptian pyramid while at the same time feel like it is something else. If I come up with hammers looking like they're from the Misty Mountains or from Vinea, they won't "buy" it. Similarly, although I won't use the Egyptian hieroglyphs, I'll use glyph-like writings anyway and not neon ads.

Et je ne résiste pas à l'envie d'en profiter pour vous présenter le projet Kyle & Lucy de Cellar Chateau. Un jeu bien dans la veine de Sonic 2, avec ses sols qui font des crolles, ses boucles et ses tremplins. Je trouve très bien trouvé l'introduction des rollers aux pieds des héros félins (déclenchés dès que la vitesse est suffisante), ce qui permet de garder une animation lisible tout en ayant une vitesse de déplacement digne de Sonic.

On est ici dans une "zone de la musique" qui n'a pas à rougir devant celle de Rayman ou de Zool. Chapeau. Il faut dire que le talentueux Lapper (qui nous présente les avancées de son projet "Sonic Studio" sur sa chaîne Youtube) prête main forte au niveau du graphisme.

Maybe you had never heard of Kyle and Lucy before. It's another game project I'm following on twitter, with Sonic-inspired gameplay and surrealistic aesthetics. The music zone is clearly one of my favourite. Everything looks so readable there. Note how the designer has given Kyle retractable rollerblades so he could zoom through the level without having to move his legs at ludicrous speed!

Sonic Mania

Il faut le reconnaître: Sonic Mania est une réussite. Ces nouvelles couleurs sont tout simplement fantastiques. Le mélange entre ancien et nouveau est particulièrement réussi. Je trouve le design franchement bien pensé, avec un premier niveau par zone qui est un hommage au niveaux originaux alors que la 2eme zone se lache pour étendre la formule. On retrouve ainsi un lac souterrain et des totems géants en deuxième volet de la "Green Hill Zone" (et si je ne me trompe pas, on peut déjà en avoir un aperçu dans certains itinéraires de la première zone).

Le changement est encore plus marquant dans la Chemical Zone, qui offre un revisitage de mécanique de jeu qui n'est pas sans rappeler la main-du-maître revisitée dans Link Between Worlds.Je m'explique.

La Chemical Zone de Sonic 2 est remplie d'un liquide chimique pénible, avec en plus des gouttes d'un autre liquide chimique. L'un tue rapidement, l'autre lentement (enfin, l'inverse). C'est probablement le premier véritable obstacle du jeu, et on a beau faire, contrairement à de la lave qui nous blesse mais sur laquelle on peut courir pendant nos phases d'invincibilité, dans un produit chimique, Sonic coule.

Mais dans le 2eme niveau de Sonic Mania, on fait apparaître des switches qui permettent de faire réagir ces liquides chimiques pour produire une sorte de slime ultra-élastique et obtenir un trampoline géant. La difficulté transformée en fun par l'intermédiaire des actions du joueur, c'est déjà bien chouette. Quand en plus ça se traduit en trampoline (sans pics par-dessus) dans un jeu de plate-forme, c'est fun-compte-double.

Bien sûr, on saute dans un jeu de plate-forme. Mais régulièrement, on ne saute pas assez haut. Parfois il y a un bumper pour nous propulser plus haut, mais il y a alors le risque de mal retomber, ou de rater sa cible. Une salle-trampoline, c'est de la pure gourmandise: saut jusque tout en haut, on peut tout attraper, on ne prend aucun risque. 

(Bon, ça fait un moment que Sonic Mania est sur ma switch, bien sûr. Les notes qui disent "J.L.N a encore les réflexes un peu lent pour éviter les crabes qui lancent des boules en ouvrant les pinces" doivent dater du mois d'Avril).

Pour l'instant je cale sur le boss de la Flying Battery Zone, mais il y a un dernier élément sur lequel j'aimerais revenir: la boule-rouge-à-ressort de StudioPolis Zone. Une variation sur le thème du trampoline qui vaut la peine qu'on y regarde de plus près.

Ceux-ci ne propulse franchement pas haut, mais on a bien le temps de profiter de leur animation atypique. En plus, ils déclenchent "à la demande" une animation normalement plutôt rare de Sonic (celle utilisée pour le faire marcher dans les pistes-tourbillon de la GHZ).

Leur forme sphérique s'accompagne d'une mécanique où on est propulsé un peu dans n'importe qu'elle direction, les transformant en un mélange entre bumper et tapis-roulant, mais comme ils sont placés en groupes assez généreux et à l'écart des dangers, ils restent fun.

Sandopolis Zone and Mega-tiles.

Ok, au départ je cherchais des références pour les couleurs et le style de la "desert/pyramid zone" de mon prochain jeu. Et je venais de découvrir l'existence de Sandopolis, région d'un jeu Sonic jusqu'à laquelle je ne suis probablement jamais allé.

At first, I was just trying to find colour references for the pyramid/desert level of my next game, and I just had discovered the Sandopolis zone in some Sonic game (where I never managed to have my red shoes around). The tileset was a big .zip where I should have found all the backgrounds, but instead of the expected 'tilesheet', I stumble upon a set of 128x128 pixels pictures.

Un beau gros .zip dans lequel était supposés se trouver tous les décors, mais au lieu d'une "tilesheet" habituelle, je tombe sur une collections d'images de 128x128 pixels. J'étais resté un peu intrigué mais sans plus. Puis en revoyant la vidéo "making of Sonic 2" de splashwave, le doute n'est plus possible: il y a un niveau intermédiaire de map, et ces blocs de 128x128 pixels sont bels et biens des morceaux de puzzle construit à la main pour servir ensuite de de bloc de construction dans un niveau. On va les appeler des "mega-tiles".

I then shifted from "puzzled" to "enlightened" while watching the Sonic 2 making of video by Splashwave. There was no more doubt to have: there is truly an intermediate level of design -- 128x128 pixels areas hand-crafted by the graphics people out of brainstorming proposals, and making best reuse of the 8x8 tiles. Level design people then use them as jigsaw pieces to get the desired chains of jumps, boosts and loops. Note how the in and out ground height is standardised over the mega-tiles, btw. The core idea of this technique is of course to improve space efficiency: levels in Sonic may get as large as 10000x2000 pixels and the machine only has 64K of RAM. A 100:1 compression ratio is more than welcome in this context.

Avec les mega-tiles, on peut atteindre ainsi un taux de compression proche de 100 pour 1. Les niveaux de Sonic avec leur taille surréaliste de 10,000 x 2,000 pixels tiennent en réalité dans moins de 64K de mémoire.
Et si on regarde un niveau construit avec suffisamment de recul, on peut commencer à trouver des correspondances. Commencer seulement, parce que c'est loin d'être complètement évident ... et j'aurai eu recours au mode "soustraction" de Gimp pour les mettre en évidence.

Yet, when you have a look at a sonic map, it isn't obvious that it is made of such mega-tiles. To see them,  I had to use the same trick I used to locate tiles in SuperFrog: duplicate the layer and turn it in "substraction" mode, so that tiled area suddenly turn as all-black squares when they overlay.

Et si on ne s'en rend pas compte en jouant, c'est grâce aux différents éléments qui eux ne font pas partie de ces blocs : les télévisions, les anneaux, les ennemis ... Et parce que contrairement à un jeu "type Mario", la disposition des blocs de taille 16x16 au sein du jeu a nettement moins d'importance. J'entends par là que Mario interagit avec un bloc de brique ou un bloc-question individuellement. Et le fait qu'un saut soit possible ou non se décide à un bloc près.

I see two possible reasons explaining why those mega-tiles remain hidden to the player. First, the level designers have an additional layer of diversity with rings, screenchests, spikes, bumpers and baddies. Second, unlike a Mario-styled game, 16x16 blocks layout within the level makes little practical sense: Mario interacts with individual blocks frequently, and a mere block may define whether you an clear a jump or not. This isn't the case in Sonic: the speed, not the layout, defines whether you make it through -- or whether you find the appropriate bumper to gain extra height/speed. And even when you aren't high enough, you can still make it through a less-impressive backup route.

Pas dans Sonic. Selon qu'on va plus ou moins vite, on passe ou non. Selon qu'on trouve le bon bumper ou non, on va assez haut. Et quand on n'est pas assez haut, il y a de toutes façons une route inférieure à suivre. 

edit: a nice document entitled 'a level map is assembled with 64 parts' shows up in interview. Note that the width of a meta-tile allowed one loop to fit one meta-tile (and that the loop is actually made of one background tile and one foreground tile)

La guerre des Mascottes

Ça y est : j'ai enfin reçu mon tome 2 de l'Histoire de Mario. Chiffre de ventes à l'appui, William Audureau et Oscar Lemaire passent au tamis les années sabbatiques du plombier, à savoir la période de 1990 (lancement de Super Mario World) à Juin 1996 (fin du développement de Mario 64). Je dis "années sabbatiques" puisqu'entre les deux, les amateurs de fleurs de feu n'auront que Mario Land II à se mettre sous la dent.

C'est pourtant l'époque où tous vont tenter l'aventure de la plate-forme dans le sillage de celui qui tente de faire vaciller l'idole, à savoir Sonic (1991). Bien sûr, il y aura eu d'autres jeux de plate-forme avant et il y en aura d'autre après, mais durant cette période, ils représenteront le gros des ventes de jeu sur console.

Chose peu surprenante, c'est avec la sortie de Sonic que coïncidera l'envie de faire mon propre jeu de plate-forme avec d'abord Calimero de '91 à '93 puis avec Bilou sous Basic entre '94 et '96.

Pendant ce temps, à peu près tous les détenteurs de personnages enfantin forts vont cesser d'"ignorer" le jeu vidéo et attaquer le dangereux Mario sur son terrain : celui du jeu de plate-forme. Ce sera "castle of illusion" avec Mickey, "duck tales" puis les jeux Infogrames qui ratissent autant de personnages de bande-dessinée francophone que possible mais aussi le bestiaire de la bande à Bugs Bunny -- avec plus ou moins de succès. En réaction, les acteurs du jeu vidéo vont aussi miser gros sur les personnages d'animaux antropomorphiques ayant le potentiel de devenir des mascottes, comme le Mr. Nutz de Philippe Dessoly chez Ocean, la chauve-souris acrobatique chez Sun Soft et le controversé Bubsy chez Accolade (que je ne connaissais jusque là que sur PC pour ses simulateurs de course)... et bien d'autres encore qui n'auront atteint ni l'émission Luna Park ni les planches de Midam. Même les robots de combats spatiaux prennent des allures de braves mascottes et tentent de se faire passer pour des abeilles avec des noms comme "twinnbee".

Oh, well. There's been another book by William Audureau, joint by Oscar Lemaire, about years '91-'95 where platformer was the king of video games, and where it looked like everyone could come with a mascot-like hero that would be the next Sonic since Mario was Missing... So I've been reading and reading. And no code has progressed. More luck next week ?

De notre côtés de jeunes ados, on fait la chasse aux magazines, on rève à ce que peut bien être tel ou tel jeu avec un personnage plus ou moins probable. Il semble qu'il y ait un nouveau venu tous les trimestres. Dans quelques rares cas, on aura l'occasion de s'y essayer mais le monde du PC est tristement dépourvu de ce genre d'exotisme. Au mieux, ce sera James Pond II sur Amiga à la maxithèque, ou la surprise de découvrir Moktar reconverti en Titus the Fox. Ils ne sont pas tous des sonic-like tels que Zool, mais ils cherchent clairement à plaire au même public. Et il semble bien que le succès de Sonic décomplexe tous ceux qui hésitaient jusque là à faire des chat-tout-mignons comme personnages de jeu: il suffit de leur coller un élément vestimentaire de jeune, une attitude cool-et-frondeuse, et en avant. Sur micro, on le prendra avec une dose de dérision, et j'ajouterais bien "Super Frog" (PC, Amiga) à Jazz Jackrabbit & James Pond ... mais le plus souvent, on avait droit à un gros raté du genre "Skunny the Wild West".

Le tandem William-Oscar gratte donc derrière les couvertures de magazines et effectue un impressionnant travail pour rassembler les interviews, les mettre en contexte ... Car si l'un va titrer "la nouvelle mascotte de XXX", ce n'est pas nécessairement l'avis de la société qui l'aura publié, ni du studio qui l'aura créé. Et si les personnages humains (Commander Keen ? Duke Nukem ?) sont assez peu présent dans l'analyse, les "héros/mascottes" improbables tels que Plok ou Cool Spot eux, ne sont pas oubliés.

Il met aussi en perspective les travaux de l'équipe de Miyamoto -- qui n'est évidemment pas restée les bras croisés pendant 5 ans -- qui sans parvenir à donner un deuxième jeu où l'on saute vers des blocs-questions à la SuperNES va se frotter à toutes les technologies de pré-3D afin d'avoir le meilleur Mario 64 possible quand sera enfin prête la console 3D de nintendo.

Il y aura finalement peu de suites parmi les "héros fabriqués spécialement pour l'occasion" ... et aucun ne parviendra à survivre à l'environnement des 16-bits où il a vu le jour, que ce soit pour des raisons de fusion/acquisition/license, par incompatibilité technique entre la vue 3D et les mouvements du jeu de plate-forme, ou simplement parce que les artistes d'animations qui donnaient vie aux personnages se retrouvent privés de tout repère devant les logiciels de modélisations polygonales.

Vous l'aurez compris, même s'il y avait beaucoup moins de matière pour le game-designer-amateur que je suis, le livre m'a malgré tout tenu en haleine. Bon, évidemment, avec tout ça, le travail sur l'amélioration de SEDS et LEDS, mes éditeurs de jeu sous DS, n'ont pas beaucoup avancé ^^".

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)

Sonic 2 for free ?_?

J'avais eu l'occasion de télécharger Sonic 2 pour Androïd, temporairement gratuit, sur la recommandation de mon frère. Une valeur sûre, de 1992. Emerald Hill et ses ponts spiralés ... La Chemical Zone et ses blocs lambinants qu'il faut escalader après avoir dévalé des pipe-line de liquide bleu-louche.
J'essaierais bien d'aller jusqu'à la Mystic Cave voire Oil Ocean, mais pour tout dire, les contrôles sur tablettes sont une catastrophe! Le bouton de saut ne réagit pas systématiquement, ce qui est un comble pour un jeu de plate-forme où les réflexes sont si importants. Ça fonctionne un peu mieux quand on appuie vers la mi-hauteur, mais ça veut dire que presque tout ce qui se trouve devant Sonic devient masqué par ma main >_<

What good is a free copy of Sonic 2 if you can't play it ? And how could play a reflex-based platformer when your hands are hiding half of the play screen ? How could you have proper timing when you can't have your hero reliably jumping on "button" press ? And if trying to move backwards may be ignored because you suddenly move out of the active detection region ?

does it really deserve the 'sonic' tag ?

Sonic bof

Autant l'histoire de Mario des éditions Pix'n'Love m'avait séduit, autant celle de Sonic m'a semblé insipide, malheureusement. Les images brillantes et omniprésentes semblent avoir détourné les auteurs du contenu texte. Il faut dire que L'histoire de Sonic le hérisson avait déjà largement été collectée par des fans de tous poils avec des wikis reprennant tous les personnages et les jeux dans lesquels ils apparaissent de manière bien plus pratique. On trouve aussi sans trop de peine de nombreux concept arts qui sont repris dans le livre.

Bref, dans une certaine mesure, l'article sur le projet (avorté) "Sonic Mars" paru dans le Mook avait plus retenu mon attention. Au niveau design, pas grand-chose à me mettre sous la dent non-plus. Là où l'histoire de Mario présentait la manière dont un des premiers personnages de jeu a pris vie, on est ici dans un cas de figure où l'ensemble des concepteurs de jeux et artistes d'une société bien installée se sont attelés à proposer des personnages "à la Mickey Mouse" pour "un jeu qui va vite" (parce qu'accompagnant une nouvelle console qui devait écraser la concurrence par ses performances).

On reste donc dans le domaine du "gentil trivia" qui accompagne la gallerie de photo. Un livre qui plaira sans-doute à celui qui est collectionneur dans l'âme et cherchait une pièce maîtresse pour caser entre sa manette Saturn et sa cartouche "Tails & the Music Maker" ... mais personnellement, je n'ai pas été convaincu. Les interview des membres de la Sonic Team auraient pu relever le niveau, mais en réalité, elles sont redondantes par rapport aux informations apportées dans la partie "l'histoire". Bref, une série d'articles bien ficelés dans les "mooks" aurait été préférable en ce qui me concerne.

Sonic Physics Guide

ça faisait un moment que je n'étais plus tombé sur de la lecture chouette comme celle-là. "pentes & blocs à pousser", "collisions", "gestion de la camera", etc. Ca va me faire de la lecture ... Attendez-vous à ce que je vous en dise d'avantage dans les prochains jours.

A neat pick: the Sonic physics Guide starring handling of slopes, curves, camera movement ... knowledge likely generated from years of hacking the good'old Sonic 1 and Sonic 2 roms (for SEGA Genesis). Expect some more detailed posts when I'll be done with my readings. 

TODO: make a small executive summary of it. You may use https://twitter.com/bigevilboss/status/1164309035270754306 as a starting point.

Marble Fire Madness ...

La médiathèque du coin me permet d'emprunter des jeux DS à un coût de 2€ par mois ... alors je ne me fais pas trop prier. En attendant mon vol pour Uppsala, j'ai pu m'essayer un peu aux Sonics auxquels je n'ai jamais vraiment eu l'occasion de jouer étant gamin. La MegaDrive étant squattée par les "grands" à la maxithèque, je me rabattais sur la version "Master System" (où j'arrivais fièrement à passer le boss de la zone de la jungle).

Ce devait donc être la première fois que j'affrontais la "Marble Zone" pour de vrai, et là, le parallèle avec ce que mon frère tentait de faire dans la "fire zone" de Calimero, dont j'ai retrouvé dernièrement le niveau 1 devient évident ... le tout premier niveau dessiné par mon frère qui me le tape sur ma planche à LEGO en disant "tiens, code moi ça sur C64, plutôt"...

Les mouvements de Sonic sont clairement mieux adaptés aux pentes et arrondis de la Green Hill qu'aux escaliers de la Marble Zone, chose que l'on observe pas tant dans les Mario. j'avance avec prudence ... ça aussi, ce n'est pas "naturel" pour Sonic. Je suis aussi impressionné de voir que, si tôt dans la série, Sonic tirait sa force non seulement de sa vitesse, mais aussi du réalisme de son moteur physique. Ecrabouilleurs, des pans entiers du niveau qui s'écroulent ou s'enfoncent ... On est clairement à un niveau différent d'un Super Mario où les "objets" sont généralement d'un seul bloc.

Du point de vue d'un programmeur, Sonic restera un exemple impressionnant. Je serais vraiment curieux de mettre la main sur le code Genesis de ce jeu ... ne serait-ce que pour la gestion des plate-formes mobiles... et des loopings, combinés au sol qui croule et aux blocs destructibles...

PS: avant de conclure que "la marble zone n'est pas vraiment Sonique, mais pourrait se retrouver dans n'importe quel jeu de plate-forme, je vous invite à regarder ce speedrun où la plupart des séquence "sur un bloc flottant sur la lave" sont court-circuitées en prenant de la vitesse et en enchaînant les sauts avec précision... Ou en choisissant de se faire toucher par un écrabouilleur-à-picots pour sauter un peu plus haut.

Sprites à Priorité Dynamique

Voilà typiquement le genre d'environnement qui était pénible à construire avec l'ancienne version de LEDS et qui devient simplissime avec le curseur de copie et autres nouveautés.
Mais c'est aussi le genre d'environnement qui pose problème au moteur de jeu dans sa version ".999" parce que j'utilise les deux plans de tiles comme arrière-plan alors qu'à d'autres endroits dans le jeu (p.ex. quand Bilou est dans un arbre), il se situe en fait _entre_ les deux plans.

Bushes like these were typically the kind of background that was a real nightmare to build with the previous release of LEDS. And with the "copy cursor" and "pull to foreground" modes of the new prototype level editor, it's really easy and funny. On the other hand, it was also the kind of background that challenged the game engine. It is acutally built by "flattening" the two layers in such a way that i never need more than two tiles at a place, and yet simulate much more planes. Unfortunately, as i wish some elements to hide Bilou (such as walls and trees in secret places), Bilou actually stands "between" the two layers i'm using here, while in this specific case, he should be on top.

Le résultat, c'est que souvent, les pieds de Bilou étaient masqués, comme sur l'image ci-contre, soit parce que j'avais oublié de repasser l'herbe en arrière plan, soit parce qu'il y avait déjà un autre élément de décor par-derrière l'herbe.
Quand j'avais lu les spécifications techniques de la console Genesis, j'avais été plutôt étonné de voir qu'il n'y avait que deux plans de tiles. Or, Sonic est parfois devant le décor et parfois derrière (sans compter l'image de fond, bien sûr, qui occupe le 2eme plan). Le truc, c'est que contrairement aux console de Nintendo, la Genesis permettait de définir pour chaque tile si les sprites avait priorité ou pas pour l'affichage.

As a result, it is common to see Bilou's feet hidden by the grass in the latest demo, either because i forgot to move the grass to the bottom layer, or because it has to be on the front layer due to some other object (e.g. vines or bushes) in the background. I'm trying to address this by reproducing in software the technique used in the SEGA Genesis, as illustrated in Sonic II.

Je vais donc tenter de reproduire cette approche en software: puisque je dois tester les "flags" de chaque tile lors du déplacement de Bilou, je peux assez aisément en ajouter un qui force Bilou (et les autres sprites) à "passer par-devant le décor" quand ils sont au moins partiellement en contact avec ce tile-là. Ca risque bien de compliquer un rien l'édition de niveaux, mais ça devrait valoir la peine...


Despite the Genesis had only two "scroll layers" (against 4 for the DS), it dynamically evaluated tile-to-sprite priority: while all the tiles involved in the "tunnel" on the picture above were on scroll layer A, Sonic can be hidden by the "front pillars" and still seen in front of the dark checker tiles. I'm unsure whether this implies that rings in Sonic were sprites, though. I cannot change the DS hardware, but i can mimmic this technique by having some of the tile attributes (F_RAISER) that forces any sprite that hits it to appear above all the "scroll layers" rather than between "F scroll" and "B scroll" for this specific frame. It's still to be tested.

Calimero

Difficile de vous parler de mon expérience de la programmation de jeu sans vous parler de Calimero. Plus qu'un jeu, c'est pratiquement toute une page d'histoire en ce qui me concerne. Celà se passe au début de mes années de secondaires, donc entre 1991 et 1994.

La construction du jeu est clairement inspirée par le jeu Sonic the Hedgehog sur MasterSystem qui cartonnait à l'époque sur les écrans de la maxithèque: bumpers, pics, et bonus / powerup dans des "télévisions". La comparaison s'arrête là : j'avais dans les 13-14 ans, et bien loin du niveau de la Sonic Team ...

"Calimero against the Black Empire" is more than a game: it's almost the complete story of my early game-programming experiments, between 1991 and 1994. I was roughly 14, in a world ruled by floppy disks, my brother and I were impressed by the first episode of "Sonic the Hedgehog" on MasterSystem and so appeared our first levels featuring bonus-in-televisions. While the initial project was to realise this on C64 (see sprites below), it was my first big BASIC project on a PC ... an 8086 XT to be precise with 720x348 Hercules graphic display.

Le projet a commencé alors que je recevais à peine mon premier 8086 XT, et je m'orientais plutôt vers une réalisation sur le C64, comme en témoignent ces premiers essais de sprites millimétrés. De là aussi le look très "géométrique" des décors. Pourtant, avec l'avancée de ma lecture du langage EPbasic, c'est bel et bien sur PC que l'aventure aura lieu. Je passe donc mes grandes vacances à compter les petits carrés et à encoder tout ça en "passe 21 pixels, trace 20 pixels en blanc, à la ligne, passe 20 pixels ...".

Si je ne peux pas vous donner une historique plus exacte, c'est qu'avec un disque dur de tout juste 20 MB, toute l'évolution du projet s'est déroulé sur diskettes 5'1/4 un peu dures à relire aujourd'hui ... Et avec un PC qui ne retient pas la date, ... Quelques versions diskettes seront refilées à mes copains de classe programmeurs Julien Collaer et Cédric Dupont.

My brother drew the level for 4 worlds -- namely fire, water, pyramids and pipes -- that Calimero the black chick will travel to save his sweetheart Priscilla from the clutches of the Evil Black Empire. Okay, admittely, nothing impressive in that scenario by today's standards, but keep in mind that this was the scenario of virtually *any* platformer by then. Calimero's favourite sentence "That's too much unfair" is really the corner stone of my brother's level design: you'll have to jump into that fake lava river to find the level exit. Don't rush to the obvious exit, which is fake and will just make spikes appear all over the place that will kill you. Even with the cutest graphics, with such levels, it would be hopeless to work on Calimero on DS...

La première version qui voit le jour pour PC avec carte monochrome Hercules à la résolution improbable de 720x348 dans le "niveau du feu". Mon frangin (Cyborg Jeff, uniquement connu en tant que "Piet" à ce moment-là) qui était déjà mon scénariste pour la bande dessinée, me fournit un scénario en béton (la belle priscilla enlevée par l'Empire Noir) et des niveaux dans 4 mondes originaux (le feu, l'eau, les pyramides et les tuyaux)... On s'en plaint maintenant dans Super Princess Peach, mais à l'époque, c'était plutôt bien vu.

Non, le vrai problème avec ces niveaux, c'est l'influence de Rick Dangerous. Des "picots invisibles", un faux drapeau (fausse sortie du niveau), et quasi systématiquement la fin se trouve derrière une fausse mare de lave, etc. C'est une des raisons pour lesquelles il n'y aura jamais de portage de Calimero sur DS, même si je faisais quelque-chose d'aussi réussi graphiquement que le mockup de 'New Zealand Story' par Kenneth Fejer.

I don't precisely realise those flaws by that time, and I will spend much of my leisure time to precisely draw every screen on a large sheet of paper, with a 1mm=2px scale, before the level is translated into LINE(xo,yo)-(xd,yd) and PAINT(xc,yc) statements. The coordinates of every bonus and hazard hitbox are scribbled with a coloured microball pencil ... I had only access to the computer three days a week, and only for one hour (parental rules :P), so such preparation were a must. Programming sessions, however, often consist of repeatedly asking the screen to be repainted as being one pixel off could make a PAINt command to overflow and fill the whole screen >_<. A missed "screen exit detection" -- a request to paint a sprite out of the screen -- will interrupt the execution with an infamous error message from the BASIC : more "IF XX < ... THEN GOTO ..." is needed :P

Et pourtant, je persiste. A grand coup de feuilles de listing sur lesquelles je prépare minutieusement les commandes "line" et "paint" du BASIC à l'échelle qui définiront chaque écran, des tests pour chaque bonus et pour chaque zone mortelle. Si ça permet une certaine liberté, c'est long. Terriblement long à mettre au point (un seul pixel de loupé et la commande "paint" recouvre tout l'écran >_<). Je suis toujours dessus en septembre '93 quand mon frère rencontre Pierrick et commence à envisager une version en couleur sur ... Amstrad CPC. Le projet ne commencera jamais, mais jettera les base de Bilou. A Pâques 1994, je migre vers un 386 avec VGA et carte son. Et là, horreur : le mode d'écran "SCREEN 3" que j'utilisais jusque là n'est plus valable. Il faut tout repasser en 640x480, mais je gagne quelques couleurs au change. Je vais même aller jusqu'à programmer enfin le premier boss avec l'aide de Pierrick, reportant méticuleusement le dragon dessiné en Deluxe Paint via des pages entières de feuilles quadrillées (genre 'point-de-croix' pour ceux qui connaissent) des zones importantes, que je réencode en BASIC. Sans services du genre "wotsit", l'utilisation des .pcx est à cette époque réservée à ceux qui ont pu s'offrir "graphic gems" ou un bouquin du genre.

When I purchase a VGA graphic card and a Master Boomer sound card for my 386 in easter '94, I realise in terror that the 720x384 mode is Hercule-specific and no longer supported. The whole game has to be updated -- but by the same time, colours can be added. With some help from Pierrick, Calimero will at least fight against his first boss -- a dragon drawn with Deluxe Paint and hand-transcoded with several 20x20 tiles on A4 draft, squared sheets: there was no WOTSIT service by that time to help me understand how to process PCX or LBM file format, and definitely no function library to do the job for me. In its ultimate shape, Calimero will have a 10sec music sample looping during the boss fight and a "cinematic" conclusion where lava is replaced by water, flowers grow and blue bunnies frolic all over the scene on a speaker-rendered "merry melodies" theme.

J'irai même jusqu'à programmer une petite "cinématique" de fin de monde, réutilisant les lapins servant de NPC dans "Bilou RPG" (que je mêne en parallèle) et la goutte d'eau qui sert de pièce d'or dans Keen IV et faire un happy end sur la musique du final "Merry Melodies" des cartoon de mon enfance.


Alors que Juin '94 arrive, le projet s'essoufle. C'est définitivement trop exigeant pour un gameplay qui lasse. Pour pouvoir jouer la musique de Pierrick pendant le boss (en fait, une interprétation du thème de Terminator sur le synthé de mon frère), j'ai "acquis" le QuickBasic 4.5, étudié attentivement l'aide qui m'ouvre de nouvelles perspectives : le stockage de sprites "en natif", la manipulation de fichiers, et surtout la programmation structurée, enfin libérée de la numérotation des lignes. De nouveau, c'est surtout "Bilou RPG" qui en bénéficiera, Calimero ne servant que d'explorateur hasardeux pour ces techniques.

As I get more comfortable with 256 color screen mode and find ways to go beyond a simple "XOR" display, the project is left aside as I turn towards the Bilou RPG project using recently developped sprite editors. Calimero will remain forgotten until June '95 where my bored brother will use Recreational Software Design Game-Maker to revive the first twp levels. The hope to see the water, pyramid and pipes zone didn't last very long, however, as G-M hardly support most of the gameplay features (secret passages, bumpers, and switch between gravity-affected player and helicopter power-up in the same level).

Ce n'est qu'en juin '95 que mon frère, armé cette fois du GameMaker de Recreational Software Design et des graphismes (très inspiré de Sonic, il faut le dire) de mon "Panzer III", nous gratifiera d'un "calimero 2". Je suis sûr qu'il avait prévu de faire (enfin) une réalisation des niveaux de l'eau, pyramide et du monde des tuyaux, mais même le premier boss passera sous silence. Les passages secrets, les bumpers et l'hélicoptère, ce n'était vraiment pas pour le GameMaker, rien à faire.


Maintenant, éteignez votre ordinateur et allez vous coucher

ça descentote ...

Je me faisais un petit tour de jeux SNES rapidos pendant que ma fée écoute Cedra... En retombant sur Twinbee, je me rends compte d'un élément intéressant: le perso peut rester sur une pente même si un seul pixel s'y trouve.

Autre élément: dans ce jeu, une pente "repousse" automatiquement le joueur vers le bas. Si vous marchez le long de la pente, arrivé au bord formé par un mur celui-ci vous "éjecte" avec une vitesse presqu'exclusivement horizontale.

Un système de contrôle original, qu'il faudra que je compare avec le comportement de SuperMario et autres Rayman the Hedgehog Commander ...

As i was busy converging my data to a new USB backup drive, I gave another try to some of my favourite platformers. Twinbee (rainbow island adventures) caught my attention with its slope management. First, slopes always "push" the character downwards, so you cannot "stand still" on a slope. If you walk down a slope, you'll get "thrown" horizontally when you go past the edge. Interestingly, you can stay "on the edge" of a slope, as shown on the screenshot, hanging in the air (i haven't checked whether it also happens when walking down the slope or only when being "pushed backwards when you stop walking up the hill").

I'll investigate that deeper, comparing the physics of slope-walking in Twinbee, Fury of the Furries, Mario, Keen and Rayman, and possibly some Sonic game if i manage to locate some. My feeling is that gameplay of slopes should prevail on accuracy of physical behaviours to make the game fun. Slopes are not just a way to have your character elevating as he moves: in a platformer, they should be used to tune the difficulty of basic moves (jump or stun ennemies).

Konami's decision to have Twinbee "pushed backwards" when halting on a slope clearly makes anything above a slope harder to reach precisely, yet the fact that you're stopped at the edge of the cliff compensate by not throwing you into hazards. Of course in Twinbee, slopes also play an important deflecting role when you're flying with your boosters, but that's a different story.

New Super Mario Bros. : pratiquement aucune pente en bord de plate-forme dans ce jeu. Les seuls emplacements où j'ai pu le détecter, c'est soit dans le niveau des glaces ou pour des plates-formes spéciales (champignons mobiles, leviers ...), pour lesquels le bord est carrément arrondi et où Mario suit l'arrondi. La friction est parfaite : hormis sur les pentes enneigées, Mario tient en place sur les pentes.
No real slope-edge to report in that game, except for some special objects (moving mushrooms, levers, falling rocks ...).

Commander Keen : dès que le test-point central de commander Keen n'est plus sur le sol, Keen tombe et se fait "repousser" par le mur. A noter que, compte-tenu de la faible largeur de Keen, il y aura ajustement de deux pixels à peine. En saut, il y a moyen de voir Keen "atterir presque" sur le bord d'une pente et se faire soudain repousser. Dans le mouvement, l'ajustement en X donnera aussi l'impression que Keen "saute" vers l'avant en quittant la pente en marchant. Idem: friction parfaite.
As soon as the "hot spot" test-point of Commander Keen leaves the slope, keen falls and is "pushed" by the wall. Given the small width of Keen, this is merely a 2-pixels extra move that you'll barely detect unless you try to land "not quite" on the edge of the slope.

Rayman : les pentes sont toujours terminées par un bord horizontal. La seule exception que j'aie relevé à cette règle, c'est dans le pencil pentathlon où au bout d'une course effreinée, Rayman passe le long de 3 crayons inclinés. Ceci dit, les crayons en question sont terminés par des gommes-bumper, et donc on a pas vraiment la physique d'un "bord incliné" comme les plate-formes de Commander Keen. A noter que, du coups, Rayman sait s'accrocher à tous les bords, alors que les bords inclinés ne permettent pas à Keen de se suspendre dans Goodbye Galaxy. Ils ont bien tenté de lever cette interdiction dans "Alien Ate my Baby-Sitter", mais c'est la source de bugs innombrables dans ce jeu.
Virtually all slopes are terminated by a horizontal edge. The only exception i could spot is the Pencil Pentathlon, but there are bumpers at the edge of those pencils, so it's not exactly what you'd call an edge.

Mario World: 4 angles de pentes différents dans ce jeu. Pas de doute : on cherchait à démontrer la supériorité de la nouvelle SNES ... A noter qu'il y a deux types de "bord de pente" : celui qui donne sur un mur solide, et celui qui n'est qu'un bord de plate-forme. Dans le cas "bords de mur" (comme avec le beetlebug), je ne note que des pentes possédant un rebord horizontal.
Four different slopes! That's what i call "technically amazing" for introducing the new (back then) Super Famicom. Two kind of slopes here: those who are merely platforms (side picture), and those who are the edge of a solid area (bottom picture). In first case, mario will fall as soon as the test point is no longer on the slope (like Keen), and in the second, there is usually a horizontal edge after the slope (like Rayman).

Sur les pentes à moins de 45°, friction parfaite. Les pentes à 45° et plus repoussent Mario vers le bas. En clair, il sera impossible de s'y arrêter et difficile d'y contrôler sa vitesse. Une pente comme celle représentée sur l'image du haut correspond donc à une double difficulté : on tombe plus tôt (des que le test-point a quitté la surface) et on ne sait pas s'arrêter. En revanche, c'est bien un "test de boîte" qui a lieu pour les surface horizontales.
Also note that friction differs from the slope: over 45°, the slope is slippery and you cannot stop, while slope below 45° behaves like plain horizontal ground.

Kirby (squeak squads): c'est le jeu idéal pour ce genre d'observation car l'animation de Kirby est différente selon qu'il est à l'arrêt sur une pente ou sur une surface horizontale. De plus, comme dans Keen, la friction est parfaite quelle que soit la pente (un jeu pour gamins, quoi, mais j'adore). A noter qu'à l'inverse d'un personnage comme Keen, Kirby se prète plutôt mal à un mécanisme de "test-point" unique, puisque sa base au sol est particulièrement large.
Interesting game to study as there are two different idle frames depending on whether Kirby stands on a slope or on a horizontal area. Here we can observe an additional "horizontal" move after the hot spot has left the slope, but while kirby cannot "fall" yet due to the wall (box-cando test).

Phénomène intéressant, dans le cas d'un "bord pentu descendant" comme sur la photo ci-contre, on observe un comportement "horizontale - pente - horizontale - chute". Dès que le "test-point" qui sert à suivre une pente a quitté la pente, Kirby a donc le choix entre deux actions: continuer à avancer à l'horizontale ou tomber. Il ne tombera pas tant qu'une partie de sa base reposera sur le bord du mur (d'où la deuxième phase horizontale). Du point de vue du code, ça pourrait se traduire par:

• test = cando(FALL, x+dx , y+1);
• if (test&FALL) return switch_state(falling);
• if ((test&SLOPE) && testpoint_on_slope(x+dx,y+1)) return align_slope(x+dx, y+1);
• if (cando(WALK, x+dx, y)) return simply_move(x+dx,y);