Ressortir la supercard ?

Rédiger ce post à propos de Kirby and the Amazing Mirror, ça m'a de nouveau donné envie d'y rejouer évidemment. Et pourquoi pas sur SuperCard, au fait ? après tout, ça a plutôt bien marché pour Goodboy Galaxy et le jeu "Professor Sinister" de Simian Zombie il y a quelques années ? Et pour pas mal de titres dont Prehistorik Man avant que je ne me lance dans le développement NDS (et que je n'achète mes premiers jeux NintendoDS) ...

I'd like to play Kirby and the Amazing Mirror again. I've been looking for it in 2nd hand stores for over 10 years (nearly 20?) without being able to find it. So maybe I should dust off my GBA SuperCard and give it a try ? It did a fair job on the last few homebrew I tried, despite the memory card being a bit small ...

Mais à l'époque, j'avais un vieux Windows en plus de mon système Linux, et je pouvais y faire tourner le patcheur de ROM du constructeur (Supercard, donc). Pendant des années, plus moyen de convertir des ROMs et donc plus moyen de jouer à des jeux officiels à travers mon linker GBA. Mais en creusant hier, je note qu'il y a finalement une version open-source tournant sous systèmes UNIX du patcheur en question!

But the drawback with the supercard is that you couldn't play "plain" dumps of your games. Instead, you'd have to make the go through a converter software, which was Windows-only, lost in the last Windows Crash I've had and of course, no longer shows up on the manufacturer's web site. But hey hey! Somebody uploaded a github variant of the tool, so finally I could try my favourite Kirby title on real hardware ... and ...

Voilà près de 20 ans que j'essaie de le trouver en boutique de seconde main et qu'on me répond "ah, très bon jeu, mais on ne le voit presque jamais ici" ... donc je tente...

Une fois patchée, la ROM tourne bel et bien ... j'ai omis d'ajouter le patch permettant de relayer les sauvegardes, donc si la cartouche est laissée hors-tension un peu trop longtemps, elle perd la partie en cours. Plutôt gênant pour ce jeu précis. Plus problématique encore, le jeu souffre de ralentissement. Je suis tombé sur un article qui explique assez bien le problème: dans la supercard il y a une RAM à la place de la ROM des cartouches classique, qui fait le "tampon" entre la console et la flash (il faut compter pas loin d'une minute pour charger le jeu depuis la flash) mais elle n'est pas aussi rapide que les meilleures ROM gba. Pour compenser, le patcheur va forcer le CPU à attendre le nombre maximum de cycles d'horloge à chaque lecture sur la cartouche. Et ça, avec Kirby, ça se traduit par des chutes à 30 fps trop souvent. Le jeu n'a évidemment pas été conçu pour ça et l'action est donc ralentie plutôt que saccadée.

... well, it's been disappointing. A bit more research taught me that the RAM used on the supercard is actually slower than the ROM used in high-end GBA game packs. What the patcher software does is changing the initial configuration to enforce enough wait states on the ROM bus so that the RAM has the time to answer. As you can guess, in some time-critical sections, it makes the frames per second drop, and the game wasn't written to compensate that. It was written to have a fast ROM where such conditions never happen. Playing the game isn't impossible, but it sure isn't as fun as I remember

On se dirait bien que "bah, ça laise quand-même la possibilité de faire du pixelstudy" ... sur DS peut-être. Sur l'écran de la Gameboy Advance SP que j'ai utilisé, franchement, ... c'est trop petit ^^"

#20games part 3

Rick Dangerous has its own tag on this blog. This is a clear indication of a influential game. It's not so strong on Bilou's adventure (apart for a spikes at the bottom of pits), but it was Rick that pushed us into making our own platformers, even before Sonic and way before Mario. Its influence was still strong in Calimero, although the impact of Sonic was equally strong on that one. But I never end up telling myself "oh I know, I'll make a Sonic-like" when I need to do something with a "new" character. And I never tell myself "oh, I know: I'll bring Sonic as a cameo playable character". That's for Rick only.

Il reste quelques jeux parmi ceux-qui-m'ont-influencés qui datent d'avant le premier jeu Bilou-en-plate-forme, je pense que ça vaut la peine de les rassembler, même si à ce stade-là du challenge des 20 jeux, ils se retrouvent éparpillés sur les 12 jours restants. Commençons par Rick Dangerous, le jeu qui aura détrôné Sonic (Master System) de cette collection. Parce que si Calimero est construit sur un mélange des deux jeux, très rapidement (sic), c'est le côté Dangerous qui l'emporte dans le gameplay. Et quand je commence à avoir quelques petits sprites prêts sur NDS, à quoi je pense comme moule-de-jeu ? Rick Dangerous. Et quand mon frangin ressort l'idée d'utiliser son personnage "Spector" pour participer au C64 challenge, qu'est-ce qu'on propose ? Rick Dangerous. Et qui mettrait-on bien comme personnage "un peu plus stylé" dans un remake NDS de pharaoh's curse ? Encore Rick Dangerous. Même "Nono in the Maya Zone", n'est qu'un Rick Dangerous déguisé sans Rick.

Passons. Bubsy, c'est un de ces jeux dont on a pas raté la sortie. '94, on était au taquet, de retour devant la télé tous les samedis pour écouter Maniac et Sam Touzami nous parler des dernières nouveautés et nous présenter des trucs et astuces sur les jeux qui avaient déjà quelques mois. Bubsy en a fait partie, et même si on y aura pas joué dès le départ, le côté cartoon/potache de son animation se retrouvera intégrée dans la proposition de Bilou pour le concours de jeu... et qui deviendra un de ses traits de caractère jusque dans les "on the road" de la BD. C'est aussi un des jeux dont la musique ne me quitte pas, ce qui est un autre signe distinctif de jeu qui a eu de l'impact.

Comparatively, it may be surprising to see Bubsy in the list, but it came out precisely when we were brainstorming what the exact formula of Bilou's Adventure should be. New zones ... new super-powers ... new mechanics ... Unlike me, my brother wanted something combining the most original ideas of the era (like Rolo the Rescue map pieces), and Bubsy's animations were certainly novel by the time. More personnally, I keep getting a smile when some Bubsy tune pops up in my playlist. I cannot say the same for Sonic ^^".

Think about it that way: before Bubsy, Bilou was a mere next-game character. After Bubsy, I started practicing little cartoony animations where Bilou would end up stunned/splatted/electroshocked ... 

Donkey Kong Country, j'étais sur le point de commencer l'aventure RSD Game-Maker quand il est sorti ... C'est sans aucun doute une de mes référence en gameplay (et qui a son tag), même si je n'ai jamais envisagé la possibilité de faire un jeu qui y ressemble. Quelque soit l'élément considéré (type de graphisme, d'animation, dimension des niveau ou leur organisation), ce n'est pas quelque chose que je peux tenter en solo. Pensez ... 4 types de "Yoshi" différents ? C'est tout simplement hors d'atteinte. Pourtant ... pourtant quand viendra le moment de reprendre le design en main pour la DS, il reviendra régulièrement à l'avant de mes pensées parce que trouver des secrets dans ce premier DK, c'est à peu près aussi chouette que dans Prehistorik ...

Le plus délicat,ça aura été de choisir entre DKC et DKC2 ... mais malgré ses perles musicales et le monde caché qui manquait cruellement à DKC, il y a trop d'endroits de DKC2 que je n'ai pas envie de visiter, en particulier en début de partie, si bien que je me retrouve rarement à me dire "oh tiens, je me ferais bien un DKC2"

Donkey Kong Country was one of the key games in my life, but it is also the first key game I knew I couldn't ever mimmic. It's super-ambitious to believe I could craft something comparable to Super Mario World or Bubsy, even as a life-lasting project. But DKC is just out of reach as a solo developer. I don't think I've ever envisioned doing it. I'll only make a few observation regarding gameplay, and try to identify what is fun when hunting for secrets in the DKC series ... but that's it.

Surprisingly, though, Rayman became the ultimate game model for Bilou. With epic boss fights, gathering powers as you progress in the adventure, revisiting levels with powers you've just earned to unlock more secrets. It was also the proof that my idea for animating limbless characters could actually work although it was still very crudely done in the prototype I had when Rayman appeared on the shelves. Many people will compare Bilou to Rayman even nowadays (especially when seeing the School Zone), yet Rayman pushed me to avoid or even remove things more than include them, to ensure that Bilou would remain sufficiently distinct. In August '95, Bilou.bas could let you throw your fist if you had the "turtle power" (iirc). It would never be reused again...

Et pour clôturer, il y a Rayman ... le jeu auquel les aventures de Bilou sont le plus souvent comparées. ça me fait plaisir, puisque c'est un de mes jeux préférés, et en même temps, je ne découvre le jeu que 2 ans après le début du travail sur Bilou, quand à peu près toute la phase de "pré-production" de mon frangin a eu lieu et qu'il n'y a plus "qu'à pixeliser et coder tout ça". Rayman, c'est le jeu qui va définir ce que Bilou ne doit pas (ou plus) faire. Ne pas aller dans une zone des instruments ... ne pas faire des champignons qui marchent ... ne pas lancer son poing (pourtant c'était déjà codé). Ce sera le prix à payer pour garder une identité propre.

#20games

Bon, il y a 20 jours, j'ai décidé de suivre l'exemple de Sverx et d'essayer de poster chaque jour "un jeu qui m'a marqué". Je l'ai compris au départ comme "qui est une de mes sources d'influences dans les jeux que je conçois et réalise ... on y trouvera donc pas Link to the Past, même si c'est à son donjon des glaces que je repense chaque fois que je dois trouver la détermination d'envoyer un recommandé ou de renvoyer des couriers administratifs d'un bureau à l'autre du même bâtiment en passant par ma boîte aux lettres ^^".

J'avais dans le passé déjà voulu participer à un autre challenge du genre puisqu'il y avait jusqu'à hier un tag "10 games" avec 3 posts ...  Croyez-moi si vous voulez, le plus difficile aura été d'attendre chaque fois 24 heures avant de parler du jeu suivant ^^".

I've followed Sverx's example and try to identify 20 games that have been most influential to me as a gamedev. Having to wait for the next day before picking the next game turned out to be one of the trickiest part of the challenge to me ^^". The challenge also said "no explanation, no particular order", but it turns out the first four I picked were among games that I go back for reference very often.

Le challenge disait "pas d'ordre particulier" (avoir Goodbye Galaxy en #1 ne veut donc pas dire qu'il s'agit du meilleur jeu ou du plus important), et surtout "pas de commentaire". Mais sans grande surprise, j'aimerais maintenant revenir sur chaque choix et contextualiser.

"Commander Keen in Goodbye Galaxy", donc, qui a été _le_ jeu utilisé par mon frère pendant qu'il dessinait les premiers niveaux de Bilou. Sans oublier les imports aux monstres de "Secret of the Oracle" pour les ennemis de la Green Zone. Il est probablement aussi parmi les jeux dont j'aimerais le plus mettre la main sur le code source. Même s'il y a les sources de "Keen Dreams", le moteur de GG est plus abouti, ça se sent manette en main...

Some of the games I mention on this blog are so influential they even get their own tag in the cloud! That's the case for Commander Keen, the game that formatted my brother's level design and monster rooster, but also for Fury of the Furries, where *I* draw inspiration during so many levels revival and where I've truly learnt pixelart. 

"Fury of the Furries", que ce soit les graphismes, les musiques, le thème, le level design, ce jeu revient tout le temps dans mon esprit dès que je travaille sur mes propres jeux, donc bin ... évidemment, c'était le n° 2. Lui aussi, j'aimerais sacrément tomber sur son code source... la physique de l'eau, du sable, la corde ... vraiment curieux de voir comment les gars s'y étaient pris. (note au passage: il y a toujours le projet FuryStudio à étudier et les infos sur shikadi.net ). C'est aussi le premier jeu que j'ai pu utiliser comme référence pour le pixel art vu que tous ces graphismes étaient des .LBM.

Vient ensuite Prehistorik 2, qui reste une référence pour moi en matière de bonus, de cachette ... et de comment faire une démo d'un niveau capable de captiver une bande de gamins/jeunes pendant tout un après-midi. Comment Bilou.BAS faisait tomber les pommes pour le décompte du score à la fin du niveau ? Prehistorik 2. Comment le niveau-anniversaire essaie de vous pousser à faire un 100% sur un unique niveau un peu corsé quand-même ? Prehistorik 2. La révision des éponges pour les pendre au bout d'un fil ? Encore prehistorik 2. Lui ... trouver son code ... je ne sais pas trop. Ce serait peut-être un sacré travail de l'étudier si jamais il faisait surface, vu les stratégies "tout assembleur" si chères à M. Zmiro ... Mais on a toujours le site mine.nu et sa page sur le format des niveaux. (Il y a une réécriture SDL2 en C, cela dit ... )

The next two may not have their own tag, but their impact on game mechanics and how to make a compact game interesting over the long run are still fundamental. They are also two of the games for which I'd definitely like to see the source code, and figure out what design choice the developers have taken.

Et Pharaoh's curse. Il a beau être simpliste au regard des précédents, c'est peut être le meilleur exemple pour moi de rapport qualité de gameplay / quantité de contenu. Ceux qui lisent ce blog depuis assez longtemps n'auront pas manquer de noter que je finis régulièrement par revenir à des mécaniques tirées de ce jeu C64 ... et j'espère toujours voir débarquer la version remasterisée de notre ami Lazycow ... Notez que pour ce jeu-là, le code source, c'est de l'assembleur, donc plus facile à reverse-engineerer. Et quelqu'un s'y est déjà attelé.

Cachette Secrètes ...

Il y avait quelque-chose de bien fun dans Prehistorik 2: de nombreuses cachettes dans lesquelles on trouvait plein de bonus plus farfelus les uns que les autres. Pas trop à se tracasser, celà dit: ça fait juste monter votre score. Mais ça fait aussi quelques clins d'oeil rigolos. Quand on tombe sur un pacman ou une cocotte en papier, par exemple.

J'avais eu dans l'idée d'ajouter des objets étranges à collecter dans Infinite Pyramid, qui serviraient de témoignages des années qui ont vu naître Bilou. Une K7 audio qui déclenche un jingle de l'inspecteur Gadget, par exemple. Ou un pixel art de Fury of the Furries. Ce genre de chose. Repenser aux parties de PRE2.EXE et à sa casserole géante (élément sympa qui nous rappelle le niveau qui vient de s'écouler) me donne l'impression que des objets hétéroclites sont plus fun qu'un gros tas de bananes, aussi Rare soient-elles.

 

Don't trust what's being said in French: it all happened because I was playing Eagle Island, and couldn't help but trying to smash the owl into walls just in case there'd be hidden things. Only then I recall that I grew this habbit while clubbing around in Titus' Prehistorik 2.

But granted, the thing about K-7-shaped bonuses in the pyraputer that would play Inspector Gadget jingle is a true trivia that has been suggested to Cyborg Jeff for approval. And indeed, bringing that together with the "nostalgia" for clubbing into walls made me realize that collect-a-thon are more fun if you don't know in advance what you'll collect and when designers break your expectation about what may comes during the hunt. It's another way to "make gaming moments memorable" when your game doesn't really fits an epic scenery.

Par contre, je n'avais toujours pas de bonne solution pour faire la chasse au bonus. L'effet préhistorik est drôle parce qu'on peut prendre les attentes du joueur à contre-pied. ça marchera moins (imho) si il a vu les bonus approcher depuis le bord de l'écran. Alors, bien sûr, je peux donner des coups de tête dans les branches pour faire apparaître des trucs. ça se transpose moins bien en dehors de la Green Zone. Je peux lancer des taille-crayons dans les murs, mais ça limite les endroits où chercher.

Je peux aussi essayer de faire une animation de Bilou à 4 pattes, qui permette de rendre la recherche des cachettes dans les murs un peu plus excitantes, mais entrer dans la cachette n'est que le début. ça ne nous donne pas l'effet "bonus surprise" de PRE2.

Puis en gribouillant, je suis tombé sur une idée mélangeant PRE2 et SMB3. Pourquoi ne pas permettre à Bilou de passer à certains moments derrière le décor. Là, il peut utiliser le bouton "GRAB" pour essayer de fouiller et faire sortir tous les bonus cachés ^_^

it brought my attention to the fact that I still don't have a good candidate for PRE2.EXE's club (or DK ground-pound attacks) to investigate things when you haven't been provided a blador/koopa/DK barrel to hint you that there is a secret nearby. I've been scribbling some options, starting with the obvious "jump and hit things repeatedly", continuing with "crawl under a lower (secret) passage into the wall. Nothing really convincing.

Taking a step back, why does clubbing-for-secrets work in PRE2 ? Partly because you'll clubbing all over the time. That's why blowing on things in DK:R doesn't work as well as rolling into the grass in DK:TF. What could Bilou do ? So far, his bare abilities are JUMP and GRAB...

We all know how JUMP can be used to reveal hidden goodies, right ? How about GRAB ? You sure could do it the SMB2 way. Not only you lift up defeated baddies, but you can strip goodies out of the ground after you found a suspicious thing protruding from the ground. You could also do it the DK:TF way, grabbing a root, holding 'GRAB' for a bit longer and finally you reveal the hidden stuffs. But both are for obvious secrets. Mechanically, they're not that different from the hit-me-plants of Rayman Origins (or DK:TF, by the way)

But I could turn them into PRE2-hit-the-unexpected-spot if I combine that with a mechanics from SMB3: hold up/down to switch to the background layer. Only then, you'd start digging for secrets by using GRAB again and again. There won't be the "smash-smash-smash" sound, but it could be made equally funny, I think.

Je sens que ça va être rigolo. On peut aussi le faire dans la pyramide là où il y a du sable, ou en passant derrière un pillier / une statue plutôt que par devant.

Aladdin Sources Analysis

They made a wonderful job at gamehistory.org, based on an in-depth analysis of the sources of the Mega-drive game "Aladdin". The game was made by David Perry's team who also brought us Cool Spot. At the core of their work is a technique and a toolset to allow more flexibility in animating graphics on 16-bits system that had read/write video memory on-board (as opposed to NES with read-only video memory alone, on the cartridge) and fixed-size sprites (e.g. 16x16, 16x32, 32x32).

Everything else will seem silly to you if you do not accept that, by then, getting more KB of memory for your game was very - very - hard. The size of your game was decided by non-technical people based on how much the console vendor would charge for a 2Mbit chip, when the game should came out and how much kids would be allowed to spend given which license you'd be using. So they have early planning deciding how much to dedicate to sprites, levels, code, maps, etc. Based on that, they'll decide how much levels there will be in the game, etc.

Of course, game characters animation all started by having characters whose size fit the hardware requirements (mario nicely stands within a 16x16 box and a 16x16 mushroom makes him 16x32), flipping from one sprite to another within an all-in-VRAM bank. Then some special characters (the hero) would get a special status and only get one or two VRAM slots dynamically updated. To crunch more animation frames, one could use run-length-encoding compression that does wonders on row of pixels of identical color. Others have used 2/3-bit-to-4-bit decompression once realizing that Link sprite (and all others) only need 8 colors per palette, not 16. But all this requires CPU, and the CPU resources too, were limited (Not even 8MHz. Less than my good old 80386).


If we could instead keep the same binary format between the ROM and the RAM, having the right picture in video memory at the right time is all a matter of "blasting" them through the Direct Memory Access chip. See that big line on my notes ? that's the DMA doing its job, while the CPU can focus on crunching numbers to make the game physics stunning and fun...

To make that possible with fun stretch-and-squash, cartoon-like animation, they ultimately relied on their chopper tool that cuts pictures into hardware-sized sprites. Just like the one I imagined for Titus's Prehistorik II sprites.

Ok, granted, it doesn't look completely automated. But the idea is clearly there. And ultimately, it would run on a system that has 1/4 of the power of my Nintendo DS.

So, am I allowed to dream of porting some libgeds game on 16-bit engines ? Well, with the engine refactoring that splits script parsing, it is pretty tempting to see what we could do about it.


Let's start with the animations, thus. What is weird with the animations is that their code has to interrupt every here and there when there is some delay. In high-level language, we'd likely use a switch construct branching you to frame T or frame T+1 code depending on some argument we'd pass to the function. But if we're generating machine code instead, we can do much better. We can then have the actual next animation instruction remembered, rather than an index into an array of virtual instructions. No more conditionals and branch delays on that non-speculating old CPU. Just one jump.

Implementing "keep that state for N screen refreshes" is then looking a lot like software multi-threading: you have a call to some yield_animation micro-routine (and saving your current position into the generated animation code on the stack), which will pop that resume position into some CPU register (an internal scratch variable, in case you didn't know yet), and then return to the code that called animate_aladdin, letting it save the next animation position where it sees fit. Looping animation ? super-easy ! Have you seen how much boilerplate the current virtual-RISC-processor-for-animations of libgeds and AnimEDS must deal with instead ?

What else ? State machine of course. State machines are built with simple expressions used either to guard transition (only let them used when some condition is met) or to define what to do when the transition occur (besides changing states, that is, like playing a sound, changing speed, etc).

The collision system currently will follow a list of GobExpressions calling eval(guard_predicate) until one returns true, then proceeding with eval(action) and changing state. Instead, with generated machine code, that would all be packed into a sequence of predicate code that branch to the appropriate action code or keep testing until we hit the "okay, then nothing happens" terminator that returns to the collision system itself.

One day ... maybe. That would be much more interesting on 16-bit than it would be on DS or native x86_64 code, anyway.

edit: for more background information about how things actually came into existence, seeing tools and teams in action, don't miss the excellent "Splash Wave" episode on the game.
 

L'avis d'Eric

C'est la dernière journée de 2016. Une année qui aura commencé (en ce qui concerne ce projet) par du débugging intense de mon moteur de jeu et qui termine ... par du débugging intense de l'outil "runME" histoire de pouvoir reprendre le dévelopement de nouveaux niveaux.

Mais entre les deux, j'ai l'immense honneur d'avoir reçu un feedback direct pour la grande release de SchoolRush par Eric Zmiro, développeur professionnel à temps plein dans le jeu vidéo, qui a travaillé aussi sur DS et qui a fait du game design aussi bien que du level design et de la programmation système.

Here ends 2016. A year mostly of system debugging and tools polishing, but also the year where I finally could make the first fully playable and polished release of School Rush, the Bilou-based game I've been working on since ... 2013. My goal was to have something I could proudly show to video game professionals, and I got the honour to receive feedback from Eric Zmiro, who developed most of the platformers I played on PC when Bilou was first created. 

L'univers est vraiment bien trouvé avec des attributs cohérents (l'encre, les gommes qui rebondissent, les crayons qui piquent, etc.). C'est super dur (et au clavier surement encore plus) j'ai bien avancé le second niveau, mais pas pu le finir !

A mon avis, sorti plus tôt, vous le vendiez !

It's extremely rewarding to hear "it could sell" from someone who's been experiencing the odds of creating games for a living, even when that's modulated with time traveling conditions. Eric described the game as fun (good thing too: I always loved the humour in Prehistorik series) and really hard (which makes me smile, given how many lives I wasted in spikes and fire of his own games ;)

Venant de l'homme qui a conçu les niveaux de "Titus, the Fox", et (iirc) de Prehistorik 2, je prends le "super dur" avec un immense sourire. Et quand je lui demande pourquoi "sorti plus tôt",

C'est surtout la plateforme qu'est en retard en fait. Sur DS tout projet est mort. Autrement, concernant le jeu lui même (qu'est vraiment dur, p''ain, ou alors ce sont les sauts qui sont mal calibrés, mais je n'arrète pas de me gauffrer) c'est plutôt rigolo. Je ne sais pas comment est la suite, mais si on note une progression dans les niveaux, ça peut être pas mal !

Et parmi les bugs/améliorations nécessaires relevés (programmeur système, hein, n'oubliez pas ;) 

• pourquoi quand on monte sur le truc a patte (taille crayon ?) et qu'il avance, on avance 2x plus vite ?
• Pourquoi le chargement des niveaux est aussi chaotique ??

Dans un cas comme dans l'autre, ces bugs sont liés à des insuffisance du moteur de jeu. Ce ne sera pas simple de les corriger, mais si ça saute aux yeux des professionnels, je ne peux pas le laisser tel quel.

Si j'étais graphiste ...

Si j'étais graphiste, mes sprites auraient plutôt cette trogne-là. Je saurais qu'une bonne animation, c'est une animation où on a pas peur de casser les cadres et j'arriverais à l'appliquer. Du coup, le meilleur environnement pour faire du bon travail, ce serait quelque-chose qui soit le plus souple possible. avoir suffisamment d'images disponibles simultanément pour les copier-coller et les comparaison. Bref, un outil comme SEDS ne me semblerait probablement jamais franchement pratique.

Let's be honest: I'm far from getting any close to what a real pixel artist produces. If I was, my spritesheets would look like those featured in Titus's Prehistorik II: I would not let canvas restrict myself and I would apply squash/stretch so that animations work fine. There would be significant pixels variation between frames, too. In a word, the SEDS+AnimEDS would be very unlikely to suit me. I'd need something more flexible, and in return, my game engine would need something to easily convert such flat sheets into usable assets.

Mais pour mettre des graphismes dans un jeu, faire des graphismes ne suffit pas: il faut aussi qu'ils puissent être intégré au jeu. Il faut que l'artiste puisse le plus librement possible retoucher son animation, y compris faire grandir ou rétrécir certaines images.

L'idéal pour ça, comme l'expliquait hier Eric Zmiro -- concepteur avec plus de 20 ans de métier -- c'est d'avoir le système le plus automatisé possible. Voici donc ce que j'ai compris du système qu'il décrit.

 I had the opportunity to compare the tools used in my own "School Rush" with the kind of tools and techniques that Eric Zmiro (now at Magic Pocket, and formerly developer of Prehistorik II at Titus). The core idea is to make the spritesheet-to-game data conversion as automated as possible. There cannot be any "great hotspot positioning tool" because there shouldn't be any human doing such task in first place.

From his explanations, I started to think about such automated framing tool, which is mostly a matter of separating lines that contain pixels from lines that contain none -- and having some conventions such as "an animation is bottom-aligned horizontally". Of course, there is still need to identify a reference position for each frame, so that e.g. the character's nose stays at the same position on screen while scrolling at constant speed, but a mere line of lone pixels could do the trick.

Sur base de la première planche de sprites, le premier algorithme à faire tourner est un système qui identifie les zones dans lesquelles il y a des images des zones vides. Une ou plusieurs lignes horizontale ne contenant aucun pixel (gris foncé): c'est une nouvelle animation. Une ou plusieurs lignes verticales ne contenant aucun pixels (gris clair) à l'intérieur d'une tranche d'animation: c'est une séparation entre deux étapes d'animation. On peut ensuite raffiner pour rétrécir verticalement la zone active d'un sprite.

1) on découpe les animations par planche (1 planche = 1 animation)
2) on a un outil qui capture les sprites, les convertie en bloc
3) quand un bloc existe déjà dans la banque des bloc, il ne le rajoute pas.
4) pour chaque sprite indique : [x, y, flipXY, color_index, bloc_number, size] (j'espère n'avoir rien oublié)

Si deux sprites sont identiques, ils seront partagés. Mieux, certains blocs peuvent être partagé même si ils appartiennent a des sprites différents
Encore mieux, des blocs peuvent être identique apres flip, ou être identique a une transposition de palette prêt..

Si elle me semble contre-productive, la décision "une animation par fichier" trouve tout son sens dans une équipe soumise à une date de sortie: sur une planche "prehistorik-man.png", on peut effectivement laisser le logiciel découper les bandes d'animations et faire référence à prun = pman[0][*]; pcrawl = pman[1][*]; pswim = pman[2][*]; pjump=pman[3][*]; etc. Mais imaginons qu'au terme de la production on décide finalement de laisser tomber le niveau aquatique. L'animation de nage tombe aussi et pjump devient maintenant pman[2][*]. Tous les autres animations doivent également être re-numérotée. On s'en passerait bien vu qu'il faut livrer la ROM fin de semaine pour que le jeu soit prêt début décembre...

But my understanding was yet one productivity-step below the Zmiro approach: by enforcing only one animation per sprites file, we now have a strong filename-to-game asset relationship. If the file is named pcrawl.png, then we can gather all the corresponding sprites as pcrawl[*]. When instead the 'crawl' animation is simply refered as the 5th one on pman.png, then we become vulnerable to the removal of e.g. 4th or 3rd animation, for instance because "well, the water level doesn't work, we drop the swim animation".

Yet, having the art split into multiple bitmaps doesn't mean that the tool importing them all cannot identify shared frames (or blocks) across the whole dataset. The final touch, for every frame the auto-cropper found, will be to isolate solid pixels into a minimum set of hardware-compatible blocks and pack the pixels of those blocks into tiles. The DS video chip, for instance, will only work with 8*W x 8*H blocks with W/H ratios of 0.5, 1 or 2 and a maximum size of 64*64 pixels. Even with a simple greedy algorithm, we can easily shrunk the amount of video memory required for a sprite to 1/3rd of the brute-force 64x64 sprite approach. Each batch of tiles has a companion set of OAM data that can configure hardware sprites' size, ratio position and indexes so that your 7 sprites actually look like a single, seamless cro-magnon protagonist to the player.

Reste à faire manger ça par le hardware d'une console comme la DS, qui ne fonctionne qu'avec des sprites hardware de 8x8, 16x8, 8x16, 16x16, 16x32, 32x16, 32x32, etc. jusqu'à 64x64. Sa mémoire est limitée, aussi donc avec un seul bloc de 64x64, le nombre de sprites affichables simultanément est sérieusement réduit. Ici, p.ex., on a un cro-magnon de 37x49 pixels qui prendrait 64x64. Avec un simpe algorithme de découpe "glouton", on peut le couvrir avec 4 blocs de 16x16 et 3 blocs de 8x16. Soit 6/16 de la mémoire nécessaire pour l'afficher d'un seul bloc.

AnimEDS travaille par petites éditions successives. Mais AnimEDS suppose que le contenu de la mémoire vidéo est constant. Ici, il n'y a aucun intérêt à garder un morceau de cro-magnon en mémoire si cette image-là n'est pas à l'écran. Du coup, tout ce qu'il faut c'est allouer un bloc de N tiles de sprites -- avec N assez grand pour la plus grosse étape d'animation -- et assez de blocs 'OAM' pour les contrôler. Pendant la synchronisation vidéo, c'est un nouvel ensemble "VRAM+OAM" qui est transféré simultanément pour changer les pixels que la console peut afficher et l'information sur quoi afficher où (les OAMs).

Then you need to have a game engine that can make the best use of these list of OAM datas. A real animator like those who work with Eric will easily saturate the 128K of sprite memory the DS has, so every new frame is likely to see new sprites tiles updated in VRAM together with the OAM updates. More on that in a future post.

Mais je ne suis pas graphiste. Il y aura encore pas mal d'eau coulant sous des ponts avant que je n'accouche d'un personnage pareil ... donc je vais garder SEDS et AnimEDS encore un petit moment. Par contre, si mon moteur de jeu évolue dans le bon sens, on pourrait envisager un outil d'importation des .png en .spr qui ferait ce genre de travail pour faciliter l'importation de graphismes non-SEDS dans un jeu tournant grâce à libgeds.

Pourquoi des bonus ?

They are good-looking, they balance the colours of the level while giving the golds some good reason to attract player's eyes. They are the bonuses. They make friendly sound when you collect them, but as of writing, that's pretty much it. In the previous "anniversary level" game, bonuses had a puprose: they measured how well the player explored the game and rewarded her with a deving history treasure.

There are too many of them in School Rush to keep that "completion gameplay" idea. The game is too large, too. The "completion goal" was inspired by Prehistorik 2 one-level demo and how having hidden bonuses and a completion percentage at the end of the level kept us playing the same 5-minute level for days and days.

Ils sont bien brillants, d'un joli jaune qui attire l'oeil et complète le spectre des couleurs du jeu School Rush, et sont plutôt plaisants à ramasser. Il s'agit bien sûr des lettres-bonus. Pourtant, à l'heure actuelle, ça s'arrête plus ou moins là. Si dans le niveau anniversaire ils permettaient au joueur de découvrir une image plus ou moins vieille selon le niveau d'exploration et d'exécution atteint (un rôle inspiré de la démo de Prehistorik 2), je ne sais plus rien mettre de tel ici: les bonus et les vies sont trop nombreux(es) pour que ça puisse avoir un sens. Le jeu est trop long, aussi. Alors bien sûr, le jeu étant exempt de 1-UP secret, je peux proposer le classique "100 lettres contre une vie", mais j'ai envie d'aller un peu plus loin que ça quand-même. 

With only 3 lives at the start of the game and no 1-UP hidden, they could receive the obvious purpose of granting one-ups if you collect enough of them, but I wanted to offer a little bit more than this. Chatting a bit with my brother -- who suggested that they could slow down ink rise, and possibly even inverse its flow -- lead me to thinking that they would indeed turn 'cool' if they allow to counter something that the player could think "unfair" from the game.

And at the time, the most unfair thing I can think of is the fact that falling in the ink make you lose all the power-ups you had collected, so because the coins are preserved from level to levels and even through failure (Kirby Kid call that suspension), they can be used in a sort of shop where the player can re-fill her stock of power-ups.

When can we enter that "shop" ? When can the player use what she "purchased". This will have an important result on how valuable the 'shop' feature (and thus, the letters themselves) are to the player.

Mon frère m'avait suggérer de ralentir l'encre en fonction du nombre de bonus récupéré. Je n'ai accroché qu'à moitié, mais il y a là-dedans un point essentiel: faire en sorte que les bonus donne au joueur la sensation que le jeu est moins injuste quand il en ramasse que quand il les ignore. Et quoi de plus injuste dans le "School Rush" actuel que de perdre tous les power-ups durement  gagnés parce qu'on est tombé dans l'encre. Le nombre de lettres ramassées, lui, est préservé à travers les niveaux et les échecs, au même titre que les pièces d'or de Super Mario. Pourquoi donc ne pas en faire une monnaie d'échange pour que le joueur puisse récupérer certains power-ups entre deux essais ? Reste à déterminer quand et comment.

• I want something that allows me to definitely remove the "auto-granted power-ups" from the title screen, as they proved perplexing for the players.
• I opt for some inter-mission shop. Trading level-collected bonuses against level-useful power-ups takes place between play sessions, as a way for the player to take a break.
• I opt for something that is not automatic: the player can chose not to receive a 1-UP and save her letters for more power-ups for the later levels as she thinks it would be a better strategy.
• I opt for something where the player doesn't need to _beat_ the level to enter the shop. It's there between play sessions, not between levels. I feel it essential so that the player gets the indemnity feeling after a mistake.

Je sais que je veux permettre au joueur de choisir sa stratégie. Pas de vie supplémentaire automatique: on doit pouvoir garder ses 100 lettres pour s'offrir plus de power-up dans le dernier niveau si c'est de ça dont on a besoin pour finir le jeu. Je veux aussi que l'on ne fasse l'échange qu'en dehors des niveaux, mais qu'il soit possible de "racheter" des power-up même quand on a raté le niveau, pas uniquement quand on en change.

L'habillage de ce "magasin à power-up" est venu par après. J'ai bien ri en moi-même comme j'imaginais Bilou pendu à un marque-ta-page, nourrissant le livre de lettres pour atteindre l'élément convoité. Il ne restait plus qu'à trouver une disposition livre/marque-ta-page/bonus/Bilou qui soit telle que le joueur comprenne immédiatement qu'il ne peut y avoir qu'un seul achat par choix.

Voilà pour l'idée. Maintenant je dois coder tout ça.

I started considering what the 'shop' should look like in a big laugh, as I visualized in a flash Bilou hanging at a bookmark, feeding the book with collected letters to make the bookmark move and reach the selected item. While peeling vegetables, if you ask. If you're serious about game design, make sure you have vegetables to peel. A lot of them.

This had to be refined. For the player to accept this idea, it must be obvious that only "paying back" the book is the only way to reach the bonus. It must be obvious that there's a choice to do, and that no smart movement should allow to grab several items at once it physically impossible, not an arbitrary restriction. Having the bookmark dragging Bilou upwards, for instance, doesn't work well, because Bilou has the Jump Power and reaching items hidden high is something he's got many options to do.

Now I have to address the technical aspect of it:

• [todo] the action must take place while the next level is being re-loaded. 
• [todo] Animation is involved
• [todo] player clicks what she wants
• [wish] letters flowing to the book are the ones you collected in the level

Titus the Fox dans Pix'n'Love #15

Parmi les excellents dossiers du magazine "Pix'n'Love" que j'aimerais voir réunis en un ouvrage dédié au game design, il y a une interview très intéressante d'Eric Zmiro sur le développement de "Titus the Fox / Moktar". Moktar est un des premiers jeux de plate-formes auquel j'ai pu vraiment m'essayer ... comprenez avec autant de tentative que je ne le voulais parce qu'il n'y avait pas de fin de vacances, de fin de courses au GB ou de fin de pièce de 500 Lires pour m'obliger à passer la manette de manière définitive.

Il y avait beaucoup de bonnes choses dans ce jeu -- notamment la possibilité d'emporter plein d'objet et de construire le gameplay sur leur manipulation -- et c'est toujours un peu triste pour moi d'entendre les joueurs console cracher sur la société qui a produit les premiers jeux sympas pour PC que j'aie rencontrés. Il y a aussi beaucoup de choses discutables que l'article me permet de comprendre mieux. Le scrolling, par exemple, fonctionnant par à-coup, qui se révèle être un hybride entre le scrolling continu d'un Mario/Keen et le screen-flipping qu'on trouvait déjà dans le premier opus de Prehistorik. Bien sûr, il était techniquement possible en 1991 de faire mieux, mais pour un éditeur qui n'agit qu'en France, il est important que les titres PC tournent sur tous les PC. Pas seulement sur le 286 équippé d'une carte VGA de mon voisin Alain, mais aussi sur un 8086 CGA.

L'écart de fluidité entre les version Amiga et PC, le choix de jeux à licence laissait imaginer une équipe encleinte à la facilité. L'interview révèle une équipe extrêmement réduite (un graphiste et un programmeur pour le jeu "Moktar") qui n'hésite pas à reprendre la partie la plus technique du moteur de jeu pour pouvoir supporter des sprites plus gros et des niveaux plus vastes quand la direction déclare juste "on va faire un jeu avec Lagaf'. Changez juste le personnage de Blues Brothers et ça ira comme ça" (citation officielle). Et la description de l'environnement de création habituel, très "bride sur le coup", de Titus Interactive donne aussi un autre éclairage sur cette déclaration. "On a un contrat pour un jeu, les gars. Et cette fois on a une date limite. Alors pas question de démo techniques qui n'aboutissent à rien cette fois-ci." (interprétation personnelle, ce qui n'a de toutes façon pas beaucoup d'importance puisque de toutes façons, pendant les mois passés à attendre les graphismes, Eric Zmiro a eu l'occasion de faire un tout nouveau moteur de jeu). Quand aux versions Amiga, elles ne sont pas développées en interne, mais confiées à des spécialistes free-lance de cette machine, sans doute une fois que le jeu a fait ses preuves et que les rentrées permettent d'envisager des frais supplémentaires.

Merci à Eric pour cette interview officielle, mais aussi aux longues discussion en privé depuis son premier commentaire sur ce blog en 2007.

School level delivered!

Enfin nous y voilà. 3 ans après 'Apple Assault', un nouveau jeu Bilou est sorti. Enfin, "jeu" est excessif: c'est une démo jouable comme vous auriez pu en trouver avec votre magazine PC-Fun préféré dans le milieu des années nonantes. Avec un seul niveau, il n'y a par exemple aucun moyen de reprendre de la vie ni de regagner des vies. J'ai pourtant d'excellents souvenirs de la démo de Prehistorik 2 avec son compteur de pourcentage d'exploration. Nous nous étions donc mis en chasse des dernières plate-formes invisibles et bonus cachés jusqu'à parvenir à un 100%. C'est ce genre d'ambiance que j'ai tenté de reproduire dans le niveau-anniversaire mis en ligne hier.

Looking back at the former releases and the completed todo lists initially left me with some bitter taste: since March, it looks like nothing significant has been achieved and that almost all the features were present in the "usability test demos". Reality is somewhat different. Even the month spent exploring SMW and incentives for "alternate path" was the key to level re-design. There *was* some significant progress on the reliability of my SEDS/LEDS/AnimEDS tools. when monsters are randomly altered after every save, when you have some animation that may disappear under some circumnstances, when the map may be erased by a misplaced click, the odds that you manage to craft a level featuring 20 monsters are weak. Shaping up to 54 unique animations is only possible with some convenient numbering scheme.

Hopefully, those 6 monthes made the tools reliable and the additional month made the level appear. Let's celebrate ^_^.

Et dire que depuis Mars dernier, il me semblait de n'être nulle part, puisque presque toutes les modifications apportées au moteur de jeu dataient de 2012. Et pourtant, du changement il y en a eu: tout ce "rush" sur le niveau-anniversaire n'aurait jamais été possible avec des outils aussi peu fiables que ceux dont je disposaient en début d'année, succeptibles de perdre ou d'écraser le travail accompli à la moindre fausse manoeuvre.

I was concerned about the lack of variety in my tileset. One book here, one binder there ... wooden structure, metallic items, spiky pencils. At the end of the level, I started feeling repeating myself. If a level 2 was required, I'd need more variety, shadows, and such similar things. That's especially blatant in those confined areas where the scrolling background is not visible. Hopefully, I'm not near 80% of tile space as I initially thought. I merely used 50% of the space, because many object got dismissed as "drafts" as I progressed (greyed/translucent areas).

Le niveau dans lequel on se promène tente de respecter le plus fidèlement possible le design d'origine (1994) créé par mon frère, mais remplace régulièrement les "clés" et les "interrupteurs" abstraits par des interactions entre personnages. Par contre, au niveau graphismes, je dois admettre que sur la fin du niveau, je tournais un peu en rond. Pour continuer à construire la School Zone, il me faudra d'autres objets. Et là, soulagement de dernière minute; je ne suis en fait qu'à ~50% de l'espace disponible. Du côté des sprites je devrais pouvoir compter sur le doublement de l'espace disponible (j'utilise 64K sur 128), mais il faudra "expliquer" ça à l'éditeur de niveau.

I will have to do similar cleanup in the "sprites" memory or upgrade to full 128K of sprites (the hardware allows it, LEDS won't like it :P) if I want to have the full set of animations of pendats with pixel art (initially, 3D was planned) or if I want to have spinning sponges once on the ground.

Quite amusingly, many aspects of the monsters behaviour where "hacked" during the release-rush through creative use of the current game engine and level editor -- such as undermining some platforms so that monsters see them as holes while Bilou can indeed walk them -- where I'd have in normal hobby development extended the game engine with dedicated features to support the desired behaviour (such as a monsters-wall that Bilou can move through).

Si je suis parvenu à boucler ce "niveau jouable" en 2 mois alors que je travaille sur la school zone depuis Septembre 2011, c'est entre-autres que je suis passé sur une autre approche: chaque fois que c'était possible, j'ai rusé (par exemple en trouant le sol sous les pieds des Pendats pour leur faire faire demi-tour à l'emplacement souhaité) plutôt que de chercher à étendre le moteur de jeu (p.ex. avec un mur invisible pour les monstres). à retenir.

Et maintenant ? Quand tous les confettis de l'anniversaire auront été balayés? Bien sûr il y aura un peu d'emballage nécessaire pour permettre à mes p'tits n'veux de faire leur propres niveaux: manuel d'utilisation, blocs supplémentaires pour les vies et les soins, par exemple. Sur une autre branche, proposer une réalisation de "Deep ink pit" malgré tout pourrait s'avérer sympa, encore que le concept du jeu n'était pas aussi riche que celui d'Apple Assault. Enfin, il serait temps de s'attaquer à la 3D, histoire de permettre aux crayons de poursuivre Bilou et d'introduire le fameux Bang Bash qui, en février 2006, introduisait le jeu vidéo Bilou dans la blogosphère...

Oh ... et il me faudra un écran "sound test" pour comprendre les effets curieux qui se produisent sur les musiques ces temps-ci.

Circularity

Spongebop monster design was a way to convert the (imho) funny and interesting spider monsters of prehistorik 2 into Bilou's world. As such, they won't simply move up or down, or track Bilou while sliding (as suggested in the 20-year-old proposal), but also rock and roll, hanging by a thread. Another conversion of dangerous-but-useful NPC rather than an evil ennemy.

Une éponge qui se balance au bout de sa corde ... une idée de monstre sympa et qui ouvrait pas mal de perspectives dans la "School Zone", mais techniquement plus délicate à réaliser qu'un "simple" monstre sauteur ou marcheur, en particulier avec les contraintes techniques de la DS. Depuis l'automne dernier je dois bien avoir gribouillé 3 ou 4 techniques succeptibles de rendre la chose possible sans jamais être allé jusqu'au stade de l'expérimentation. Mais maintenant que je peux attacher un objet à un autre au niveau du script, il est temps de monter un prototype.

Now, it's time to turn this "nice idea" into some real code. Physically speaking, spongebop will act as a pendulum bob, oscillating as the result of gravity and counter-force originating from thread tension. We're taught that when 17 at school. There's just two major drawback to a "straight coursebook implementation":

• it's full of angles, sin(x) and cos(x), which are pretty heavy for our 66MHz processor
• It assumes a rigid, fixed-length rod between bob and pivot.

Conservation de l'énergie, mouvement circulaire ... ce ne sont pas les approches qui manquent, mais chacune a aussi ses hypothèses de travail (notamment la présence d'un axe fixe que je ne désire pas). J'étais au départ prêt à utiliser une variante des algorithmes à la bresenham pour les cercles, mais la multiplication n'est en fait pas si coûteuse en terme de temps de calcul que je ne l'aurais cru. Je peux donc exploiter assez librement l'équation x²+y²<=r qui décrit tous les points à l'intérieur d'un disque. Dès que les la distance entre SpongeBop et son point d'attache ne valide plus cette contrainte, c'est qu'il tire trop sur la corde.

 Bilou would pretty much love that sort of predictable and massive pendulum platform, but spongebop's thread is instead fairly elastic and landing with excessive velocity triggers a rodeo session, says the comic concept art.
In other term, I would like something more flexible, that can constraint Spongebop to stay within a certain circular area, but still allow Lissajous-like patterns when drawn away from its equilibrium path, as I explained this lunch-time to Cyril. So fundamentally, Spongebop's behaviour is defined by two controllers:

• gravity, that takes care of the "free riding" when x²+y²<r²
• radius detects situations where x²+y²>r². As soon as that occurs, we use a 'unit' vector that points towards the pivot position and iteratively move spongebop back into the allowed area.

Ce qui est assez amusant, c'est que si je parviens à faire en sorte que SpongeBop ne puisse allonger exagérément sa corde, j'aurai le mouvement de balancier par simple application du même contrôleur gravity que celui qui sert pour les sauts de Bilou. Je rejoins alors le "scénario BD" qui prévoit un comportement plus cahotique lorsqu'on atterit trop violemment sur le dos d'une éponge. J'utilise donc le vecteur "attache-éponge" pour définir une "direction de rappel" et ajouter un déplacement vers le centre tant que Bop est hors de son cercle de repos.

Ideally, energy preservation should keep the sponge oscillating as long as the level runs, but there's something that looks very much like friction in the digital world: precision loss. Since we're working with fixed-point arithmetic here, we're losing some speed in rounding coordinates and angles, so that after about 3 cycles, there isn't much movement left. It's compensated by a refreshing impulsion generated everytime Spongebop arrives just below the pivot point, as if it had some muscles that helps it control its movement. That part is handled by some gobscript and the controller merely report "you're at (0,ymax)" through an event.

it's a sponge bob ^_^

MUL instruction on ARM9 merely takes 2 cycles. As a result, I ended up dropping my initial idea of using (x+1)²=x²+2x+1 and simply re-compute (x+a)*(x+a) whenever needed.
I have at most one division per frame (per instance), to define the centripedic 'unit' (1/16th of pixel) vector. Yet, division isn't handled by the CPU, but by some extra software (the support library coming along with devkitpro's flavour of GCC). I think I'll live with it unless it turns out that I'm over my cycles-per-frame budget.

Le résultat est plutôt satisfaisant. Ce n'est pas un arc de cercle parfait et je dois "relancer" le mouvement régulièrement, les erreurs d'arrondi en virgule fixe ayant tendance à l'amortir trop rapidement. Je m'en sors donc avec une division (software) par éponge et par frame au prix d'une progression itérative pour recentrer Bop lors de ses déviations. C'est plus erratique que le pendule du cours de physique, mais ça colle plutôt bien au personnage. Reste à maîtriser la 3D pour tracer l'élastique et le co-processeur mathématique de la DS pour avoir accès aux divisions et aux racines carrées la prochaine fois.

Agreed, the trajectory followed by SpongeBop on the animation above is not quite a circular arc, but for some dizzy sponge on an elastic string, I think it does the trick. Now it's time I allow Bilou to "land" on SpongeBop, because solely bopping over is pretty tricky.


Hmm ... tracing a GL_LINE between the spongebop and its pivot (not yet visible) would be a nice use case to introduce 3D support in the mix ...

PS: all this was the last idea of a long list of dropped approaches. Maybe I'll discuss alternatives later on.
PPs: of course, although the ARM processor on the DS has no support for division/square roots, the DS itself has extra hardware for such functions.  Since it says "square root takes 13 cycles", it could be worth to use the sqrt(dx²+dy²)/sqrt(R) ratio to properly compute the pullback force rather than relying on iterations here. (that's still an occurence of premature optimisation, imho)

Funky Inside

Rompant avec les niveaux prévus par mon frère, je décide en 2001 de placer la confrontation entre Bilou et Big Caterpillar au sommet d'un arbre creux monstrueusement grand... et je fais totalement l'impasse sur ce qui se passe à l'intérieur de l'arbre. Puis, en pleine phase Cave-Story, je décide que la "clé du boss" ne sera pas une bête clé mais plutôt une interaction avec des NPC, notamment les Funky Funghi fraîchement relookés. L'occasion aussi d'un niveau tout en hauteur où je peux caser des bascules/tremplins et autres effets catapultants bien marrants (enfin, j'espère).

In Bilou's Adventure as my Brother invented it, there was no such thing as a hollow tree level. Still, when I converted the yet-to-be-written game into a (web)comic in 2001, I figured out that a huge, hollow tree would be a nice place for Big Caterpillar to have his lair.

Later on, as I started to feel the interest that an organic (or even story-based) key may have and decided that 'plain keys' had no real place in the green zone, that hollow tree seemed to be a nice place to have a crowd of Funky Funghi that would make the boss a bit harder to reach...

I had no real luck on my hunt for reference material until that Rayman Origins screenshot me in the head with the naked truth: nobody said that your hollow tree had to be made of brown wood only. Actually, it quite makes sense that it would be invaded by moss, vines and other greeny stuff, especially if it's the resting place of the funghi ;)

Je m'étais mis en chasse de quelques souvenirs de jeux vidéos avec des arbres creux ... Mickey Magical Quest sur SNES ... Prehistorik 2 et ... ah bin non. Pas les rangers dur risque, finalement. Tout ça sans véritable coup de coeur: rien de vraiment utile. Par contre, j'avais passé déjà un certain temps à décortiquer le graphisme de l'arbre ronfleur de Rayman Origins (eh oui, encore lui ;) qui donne des pistes assez intéressantes. L'une d'entre elles ? Eh, qui a dit qu'un arbre creux ne pouvait pas être plein de mousse (et donc vert-sombre plutôt que tout brun) ? ... réponse : personne.

easy - *normal* - hard

Sur pas mal de points, je me retrouve dans la "philosophie du jeu de Locomalito". "Fun for a while, not entertainment for a long time" (chaque minute de jeu doit nous impliquer totalement), "Ingame secrets and optional stuff", "Free indie developers makes games for love" (un peu comme les dessinateurs du Gang Mazda), voire même "Difficulty and glory !". Mais il y a quand-même un point sur lequel je bute:

I think every game should have a single level of difficulty, according to the situations in it. For example, the end of an adventure game should be reserved for adventurers, the end of a war game for warriors... so a player can feel he has beaten a game thanks to his own skills and likes.

Celà suppose que tous les joueurs ont déjà acquis la maîtrise de leur pad et cherchent juste à s'essayer à de nouveaux challenges. Je me souviens du message de Prehistorik II "désolé, l'accès au chateau (et donc au boss final) est réservé aux joueurs confirmés. Revenez en mode "normal" (ou "hard" ?) et on en reparle. J'ai donc refait le jeu à nouveau, bénéficiant de la connaissance que j'avais des niveaux ... Si j'avais dû attaquer directement le mode "normal", c'était sans espoir!

Prenons Super Princess Peach. Jeu sympathique, mais au challenge limité. Peu probable que je le reprenne avant des années. Giana Sisters (version C64) me demande une maîtrise, et par son mécanisme de bonus, donne du sens au parcours répété des premiers niveaux: il faudra faire un "sans-faute" sur les 10 premiers pour bénéficier d'un atout pour court-circuiter la difficulté du no 11.

I agree with most of Locomalito's indie philosophy of games. There's just one thing ... Locomalito seems to assume that we're skilled and trained already. I can name games that have only one level of difficulty and that made it wrong -- Super Princess Peach, because that level is "I haven't played a lot of platformers so far" and Megaman for Wii (or Toki arcade) because its difficulty is so insanely high that you wouldn't make it to the first half-boss unless you've already cleared one game of the Megaman series. And I certainly needn't to name game that have multiple difficulty levels and that made it wrong, for instance because you need to beat the game in easy mode first to unlock hard mode (if easy mode is boring for you ...). Kirby's Dreamland (GB) imho did it the wise way by showing the player the cheat code to access hard mode once he beat the easy game. Will you get your hand on a lost cartridge 20 years later, you can try the challenge again.

Now he also said "the war game is for the warrior to complete, not for the ranger". Basically, that echoes Prehistorik II setup (for PC) where you'd be denied access to the last castle unless you're in hard mode. You just have a "happy ending", but you know you missed something. The thougher part of the game design then is to avoid blatant repetition of the experience of levels 1-N so that you can at last reach boss level N+1. Both Rayman for PSX suffers this design flaw, where you'll face a door requiring you to crawl some basic levels again and hunt for the last electoons. Same for Princess Peach and her toads. I don't remind of anything in the game experience warning me about this. At least level design of princess peach ensures you can focus on the missing toads when replaying the levels.

His claim also doesn't match games such as 'Maestro: Jump in Music' or "Soul Bubbles" where we're all newbies because of the innovating game mechanics.

Le petit Kirby's Dreamland (GameBoy), premier jeu de plate-forme que j'ai terminé, a une difficulté pour débutants: un joueur confirmé pourra atteindre le boss final en moins d'une heure. Après avoir mis une raclée à DeeDeeDee, un petit "v+select+A" me permet de choisir le mode "hard" ... où je n'ai toujours pas réussi à dépasser le 3eme monde, si ma mémoire est bonne. Résultat: à chaque occasion, j'y retourne. Même constat avec l'excellentissime "Maestro: Jump in Music" dont le niveau "easy" m'aurait laissé sur ma faim ... A ceci prêt que dans le cas de Maestro, les niveaux sont à peine reconnaissables d'un mode à l'autre. Mettre uniquement le niveau "normal" (ou hard) dans Maestro aurait provoqué un bide: dans ce style de jeu, nous sommes tous des débutants. Ils sont loins, les temps où on s'acharnait sur un Toki trop dur simplement parce que c'était le seul jeu à la ronde: le jeu doit à la fois offrir un défi consistant, mais aussi permettre au joueur de se faire la main. Mettre les deux dans une seule trame (et donc obliger le joueur confirmé à traverser 10 niveaux de tutoriel avant de commencer à être mis au défi) n'est certainement pas la bonne manière de faire...

PS: As you can see, *my* philosophy of game design isn't settled yet. I'm not sure I've been consistent in my rambling

Super Princess Peach

Il faut l'avouer, elle est de toute beauté, la princesse champi, avec son pixel art parfait et son style épuré en ligne droite de la série de RPG "Mario & Luigi". Comme mon frère me re-prète sa cartouche, c'est l'occasion de comparer mes impressions aux siennes.

Clearly, the clean pixelart style of Super Princess Peach was strongly attracting me. It may have an arguable plot and a discouraging early minigame, it has a "Mario & Luigi" look that I just want to play more. My brother let me borrow his cart, so I could play it nearly to completion see whether I agree with his critics.

"Le gros soucis de ce jeu, c’est qu’il y a trop de choses !"

Des pièces pour acheter des nouveaux objets (dans mon cas, des parapluies plus perfectionner pour taper, planer,…) puis il y a des petits coeur à ramasser pour reprendre de la vie, et aussi des crystaux pour utiliser l’une des 4 magies possibles pour la princesse

Et pourtant, ça ne fait que 3 types d'items dans les niveaux. Supposons que Peach soit plutôt Duke, ça fait une barre d'énergie, une barre de munitions et des crédits pour acheter des power-ups. Les boutiques à Power-Up, c'est classique dans un platformer. Mickey Magical Quest comme Adventure Island le proposait. La subtilité de Peach est d'avoir cette boutique ouverte en permanence, accessible hors des niveaux. En plus des parapluies, on y retrouvera aussi les "fragments de coeur" et extensions de la barre de magie qui ne devrait pas dérouter ceux d'entre-vous qui ont joué à Zelda.

He pointed out that the game features quite many items and collectible, to the point where we somewhat got lost: coins for items purchases, life and vibe collectibles. That hasn't been seen in recent games, indeed, but that was quite common in run-and-gun titles like Duke Nukem and not so uncommon in Japanese platformer with an adventure background (Mickey Magical Quest or Adventure Island II), especially since the items you pruchase are mostly equipment and health upgrade. I'm fine with all that.

Trop de mouvements

A coté de cela… La princesse peu tuer les enemis en sautant dessus, en les frappant de son parapluies, en les attrapant et les projetant ou en les donnant à manger à son parapluie (histoire de regagner des pouvoir magique). Elle peut également transporter des trampolings histoires d’aller tenter quelques sauts plus haut à gauche ou à droite ou faire de courer/glisser pour butter les monstres et passer en dessous des blocs…

A l'exception des pouvoirs magiques, tu remarqueras que l'ensemble des mouvements que tu décris correspond à ce que Duck Tales permettait. En donnant un grand nombre de mouvements d'attaque, les concepteurs du jeu ont réduit les "zones de risque" pour Peach.

Le seul véritable danger, c'est que le ciel lui tombe sur la tête, en quelques sortes. De plus, presque tous les ennemis sont vulnérables à toutes les attaques, c'est donc entièrement une question de style de jeu (préfères-tu passer à travers tout en assomant les ennemis d'un coup de saut ou attendre qu'ils arrivent à ta portée pour les dégommer d'un coup de canapluie bien placé). Mon seul véritable reproche s'adresse aux carapaces de Koopa: pour un fidèle à Nintendo, le premier réflexe est de vouloir les transporter pour les lancer à l'occasion sur une série de monstres, mais la manip pour y parvenir vient rarement toute seule.

Second complain from my brother: too many moves. You can attack by stomping, hitting, catch-and-throwing or just let your umbrella "swallow" baddies (and regain vibe/magic). To me, most of those moves are classic. A title like Duck Tales already proposed most of that, with the exception of magic powers. The developers clearly wanted to reduce the blind zones of Peach so she could defeat baddies wherever they come from, except directly from above. As most baddies can be defeated with most moves, you're actually free to stick to one type of gameplay that suits you. The only move I could not really get used to is "carry and throw koopa shells". It's a common move in the Mario universe, but Peach does it really differently and I just couldn't update that in my fingers. And he's completely right about pipes. There's no excuse to see Peach struggle that much to enter a pipe while they've been natural to use since SMB1.

Bref, à tout moment, vous pouvez être en mesure de faire un choix parmi tout cela ! Pour corser un peu le tout, je trouve que les entrées dans les tuyaux sont mal gérées…

J'admet pour les tuyaux. C'est particulièrement désagréable de devoir faire un ajustement de précision pour une chose aussi élémentaire que passer à la suite du niveau. D'autant plus ridicule que les portes, elles, marchent sans problèmes.

Does the gameplay choices seemed overwhelming to you ? It surely was for my brother, but I'd rather consider it a nice thing to have in a game. SMB make you choose between breaking bricks for possible hidden coins or keep moving for certain extra time to complete the level. Prehistorik II make you choose between leaving the tiger-that-hit-you alone (and go for safety) or face it again and possibly recover your lost health. Then comes the choice linked to magic uses. This is clearly what the game wants you to master. It wants you to read the level design and understand that it's telling you to start flying (hint: aligned vertical coins), start crying/rushing (hint: blue object), start burning things, etc. They disguised as emotions what are essentially elemental powers, and we've been super-trained to elemental puzzles. I'd dare say once you realize that, puzzles in SPP become simple compared to Fury of the Furries. Granted, that leads to quite unsinspired Ice zone and Fire zone once again...

Pour ce qui est des choix, un jeu intéressant *doit* offrir des choix. Dans Super Mario, où tu es contraint par le chrono, ce sera "est-ce que j'essaie de démolir cette structure pour trouver des bonus ou est-ce que je continue vers l'avant". Dans Commander Keen (niveau de difficulté normal) ce sera "je ramasse les bonus, ou je préfère ne pas prendre le risque de passer sous le champignon ?". Dans Prehistorik II, "Si j'arrive à dégommer cette saloperie de tigre, il me rendra mes os, mais si je le loupe, il me prendra un 2eme coeur".

J'utilise la magie ou pas ? et laquelle ?

On touche au coeur du problème. Peach n'est pas un jeu d'adresse ou d'endurance comme pourrait l'être un Mario. C'est un jeu d'exploration. Une sorte de puzzle où il faut apprendre à "lire" les indices

• trois pièces d'or alignées verticalement et un cristal magique au bout : 'faut voler, mon gars ...
• des trucs bleus dans le chemin ? une roue à aube ? Pleure un coup: ça ira mieux.

Le génie des concepteurs de SPP, c'est d'avoir en fait utilisé les 3 des 4 éléments (eau, feu, vent) sous le déguisement des émotions. Or c'est quelque-chose avec lequel nous sommes habitué à vivre: le feu brule, le vent souffle, etc. Une fois ce "grand principe" acquis, on ne se demandera plus que faire face à un nouvel élément dans un niveau . A mon avis, bien plus accessible que les quatres pouvoirs des tinies dans Fury of the Furries.

Et comme tous les platformers de Nintendo, ces actions supplémentaires (généralement destinées à sauver des Toads) sont facultative. L'exploration est récompensée, encouragée par le débloquage de chanson, etc. mais pas indispensable, là où Commander Keen ne saura pas finir le niveau à moins d'avoir collecté les clés appropriées et dans le bon ordre s'il vous plait.

Most puzzles are gateways to free toads, which is mostly optional and sometimes unlock titles for the games' jukebox. Most collectibles are open to trading: you can convert magic into health, risked-health into magic, and you can't get out of lives because you're granted infinite lives. Keeping "follow the coins" logic without the "100 coins grant 1UP" naturally led to that umbrella-upgrades-shop. I could have used story-telling collectibles instead of a long not-really-playing introduction.

Tu noteras aussi que tout (ou presque) est interchangeable dans le jeu, puisque tu peux convertir la magie en énergie, et l'énergie en magie (en prenant le risque d'attraper les ennemis pour les faire manger au parapluie). "Peach never dies", à moins que le joueur n'ait mal jugé de sa situation présente (plus assez de coeurs ou manque de magie). Il n'y a même pas de compteur de vies! On comprend mieux du coup le rôle des pièces d'or, puisqu'il n'y a plus de 1UP à obtenir au bout de 100 pièces. Logique, d'une certaine manière, le joueur n'ayant plus à mettre des pièces (de 20Fr) dans la machine pour acheter plus de vies (cf. nos vieilles bornes d'arcade). Mais dans les jeux nintendo, les pièces servent surtout à guider le joueur, l'entrainer vers des chemins plus risqué et le récompenser.

Puis dès le départ, une intro assez longuette, et un mini-jeu range champignon tout à fait inutile... Bref nous voilà arrivé dans un premier stage “tutoriel” peu accrocheur…

Là, je rejoint l'avis de mon frère. D'autant que dans un jeu d'exploration qui proposait déjà des "pièces de puzzle", il aurait été aussi intéressant (imho) de mettre ces ingrédients en "bonus accessibles à la demande". Fragments de journal du Commandant des Koopas Troops, etc.

Une zone du feu où il fait chaud, une zone des glace où ... ça glisse !

Commentaire d'un reviewer du jeu à sa sortie que je ne pourrais plus vous retrouver. J'avoue, SPP ne brille pas par l'originalité des mondes qu'il nous fait traverser. D'un autre côté, glisser pour glisser (quoi qu'on en dise, c'est un canon du jeu de plate-formes), autant que ce soit sur de la glace dans le monde des glaces plutôt que sur de la chantilly dans le monde des jouets ou sur de l'huile dans le monde des robots. Au moins, peach-de-feu peut la faire fondre, la glace, et peach-qui-pleure peut en faire apparaître là où il n'y en avait pas. Ca donne lieu à quelques puzzles sympas. Les moulins à vent et à eau des premiers mondes n'auront donc servi que de "déclencheur" pour ajuster l'esprit des joueurs à celui du jeu, et c'est tant mieux.