Hello (androïd) World

Excellent! Les smartphones sont maintenant devenus suffisamment puissants pour faire tourner un émulateur DS. Ils sont nombreux les anciens homebrewers qui se sont fait la malle dans le monde du mobile depuis l'arrivée de l'Androïd et de son SDK accessible.

Je sais, j'aurais pu me mettre au développement Androïd, mais je préfère continuer à travailler sur le coeur du jeu et utiliser le super hardware de la DS comme "game engine" que de perdre du temps à chercher quel framework marcherait bien pour un jeu qui de toutes façons ne colle pas bien avec le hardware d'un smartphone.

That's the best news of the week! My brother managed to get a version of Bilou : School Rush running on an Androïd phone thanks to DraStic emulator. That's great news because it means that -- as I hoped -- I can keep working on the game on a platform I love rather than spending efforts at emulating that platform on a poorly-picked system that will eventually be deprecated by its maintainer. You see, nintendo console cannot turn deprecated. They can become obsolete, they can take dust, they can be forgotten or sold for gold, but they cannot turn deprecate because they were hardware. Therefore, an emulator for such a platform is something that is (until now) more age-traversing and cross-platform than any DirectX or OpenGL release.

edit: I tried the game on my brother's device. It indeed look, sound and moves fine, but there something going wrong with loading new levels. Hard to tell if there's something wrong with my code or if their emulator still needs improvement. 

edidit: J'ai fait un essai hier sur le smartphone de mon frère, j'admets qu'en dehors de l'aspect "gif animé interactif", l'émulateur sur Androïd ne permet pas vraiment de jouer au jeu. J'ai eu aussi cet espèce de bug lors des changements de niveau (l'émulateur refuse de nous relancer le jeu si on meurt, par exemple). Le mieux que je puisse dire, c'est qu'il est probable que l'émulateur ne soit pas encore suffisamment fidèle au vrai hardware. A réserver pour les curieux, mais pas vraiment une alternative crédible à DeSmuME sur PC ou au jeu sur une vraie DS.

Beyond the blogosphere.

Yes, I am nostalgic of the time I had plenty of things to discover on my Google Reader, and I have a feeling that the blogosphere has disappeared -- at least the one I was part of. I'm trying to re-construct a similar network, and I came to the conclusion that twitter alone won't suffice my needs.

Ce n'est pas vraiment comme du temps de Google Reader, mais j'ai trouvé un ou deux presque-blogs intéressants. Pour ce soir, on va plutôt parler des mini-vidéos de Keith Burgun. Pour aller plus loin que les questions-réponses de Mario et Socrates, il nous propose quelques étapes qui jalonnent le chemin jusqu'à un jeu (un vrai ?)

There are a few interesting things that happen on Youtube. The good thing is that they are easy to watch while I'm preparing the dinner or cleaning the kitchen mess. The bad thing is that they are hard to find back, when you want to reference them to someone. Yesterday's pick was a tube from Keithburgun about the layers that turns an interactive item into a game. Something I bet Kirby Kid would have enjoyed although he might use a different terminology.

Pick something that people can interact with, but don't give any rule, any objective, just freedom to explore what is possible and what isn't with that item: you have a toy. Some "video-games" are actually toy, although they're more often coined as "sandbox games". My early "demo levels" are typically toys. Playing "School Rush" in easy mode almost turns it into a toy as well.

Au commencement, il y a le jouet. Le jouet, c'est juste un truc avec lequel on peut intéragir, c'est tout. Pas de règle, pas d'objectif venant de l'extérieur. Juste l'objet et la possibilité de découvrir ce qui est possible de faire avec .. et ce qui ne l'est pas. Certains jeux vidéos sont volontairement de tels "bac à sable", mais parfois on essaie juste de faire un jeu et on termine sur un jouet. C'est sans doute ce qui guette de nombreux projets de jeu de plate-forme : sans un objectif défini, on sait juste explorer les possibilités du moteur de jeu. Autre élément intéressant: en mode "easy", rien n'empèche un joueur (plus jeune) de se servir de School Rush comme d'un simple jouet.

Put a goal to a toy (some condition to which you can say "congrats!") and you get a puzzle -- or at least something that is functionally equivalent to a puzzle. It can be as simple as "collect all the blinking items on screen", but it will only be truly a puzzle if you have unlimited attempts and significant freedom to reach the goal. If I remove bonus-counting from the 'anniversary level', it is likely to turn closer to a puzzle: you can retry as much as you want without loss (further than your actual position), and each challenge is essentially to find out how to proceed through.

Pour passer au "puzzle", il faut ajouter un objectif. Quelque-chose qui décide qu'un état du jeu est "gagné" ou "résolu". Ramasser tous les . Détruire tous les . Avec plus ou moins d'effort de réflexion selon les gens que l'on cherche à intéresser, en fait. Si on élimine les contraintes du type temps-réel pour les présenter comme un RPG de table, la plupart des jeux de plate-forme où il faut atteindre la fin du niveau se transforment en puzzle: 

• P: alors je saute par-dessus le picot sur la plate-forme
• MDJ: la plate-forme s'écroule
• P: je re-saute plus vite et j'active mon hélicoptère

Pour que ce soit un vrai puzzle, j'imagine qu'il faudrait aussi pouvoir revenir un pas en arrière presqu'aussi souvent qu'on veut. Dans une certaine mesure, avant que je n'ajoute le système "plus on a ramassé des bonus et plus on a une image intéressante à la fin du niveau", le niveau-anniversaire de Bilou dans l'école était très proche d'un puzzle.

Add session limitation (e.g. time constraint) to such a interactive+goal and you get a "contest". A contest is something where you measure some skill of yours, and compare that measurement with what others achieved. I bet C64 ski was essentially a contest: turn left or right, avoid obstacles, hit the gates. The score will tell how well you performed. Unlike a puzzle, a contest cannot be "solved" -- i.e. put in a state when there is nothing more you can do about it. As soon as you reward players of your labyrinth depending on how fast the found the solution, you're turning the puzzle into a contest, because they could try and improve their score.

Ajoutez des limites sur le fonctionnement du puzzle et on arrive à une forme de concours. Ce n'est plus seulement "trouve la sortie du labyrinthe" mais "sors du labyrinthe le plus vite possible". Il n'y a plus uniquement une décision "gagné/perdu", mais une mesure de la performance. Pour un véritable concours, l'idéal, c'est qu'il n'y ait pas de minimum absolu imposé à la performance (sinon, en fait, on passe dans une version plus sophistiquée du puzzle, tout simplement).

Le dernier pas à franchir pour obtenir un jeu c'est que le joueur n'a pas l'entièreté de l'information qu'il faudrait avoir pour s'y attaquer comme à un puzzle. Que ce soit parce qu'il affronte un autre joueur dont la stratégie ou la main lui est inconnue, ou parce que le jeu ne lui dévoile qu'une petite partie (la vidéo) de l'état du jeu (vecteur vitesse, compteurs internes, taille et emplacement des zones de collisions, etc.) Si le joueur pouvait voir à tout moment les trajectoires futures des ennemis et de ses projectiles avant de décider de tirer, on fait un pas en arrière pour se rapprocher d'un puzzle et s'écarter d'un jeu.

Chose intéressante, si on suppose que SMB est effectivement un jeu à cause de l'ensemble de détails qui sont inconnus du joueur lors de sa première approche, un entrainement et un apprentissage suffisants permettent au joueurs de l'aborder comme un pur concours (le speedrun).

To some extent, I am tempted to consider Apple Assault as such a contest. There is a goal (punch all the apples), but there is limitation both at large-scale (berry-bats will get you if you don't progress) and at small scale (press the buttons in time or you will be hit by the approaching applemen).

What Keithburgun calls "a game" is a contest where the gamestate is obfuscated. You're forced to make decision based on incomplete knowledge of what happens. That's clearly the case when you play against an opponent and don't know what she planed to play next. Or where her units are. That's the case when you play "Apple Assault" and don't quite know what the hitboxes or the behaviour of applemen are. Technically speaking, the game is solvable (? doesn't that kill its "contest" component ?), just like a puzzle, but in practice, you have to rely on heuristic strategy to overcome your own human limitations.

I would be tempted to add that some video games that are primarily skill-based can turn into pure contests once player have fully understood the rules of the game and become capable of anticipating -- through memorization, trial-and-error or modelling of the software threads -- any progress of the game state. That is, imho, what happens when players starts speed-running a game like Super Mario Bros. There's nothing more they have to understand about the game. It just became a super-evolved instance of a virtual parkour and they're in a contest to see how fast they can manoeuvre within it.

Another interesting idea from Keith is to define a mechanics as the combination of an action and a purpose. In Ishisoft's "chardonnay in Bomb Kingdom", for instance, we have "fire a bomb to jump" and "fire a bomb to blast a wall" as two separate mechanics. Yet it makes it difficult with that definition to describe "core mechanics"

Costumes, folks.

Je vais appeler "costume" un ensemble alternatif d'animations pour un personnage qui ne change pas fondamentalement le comportement du personnage. Ce sera le cas par exemple de Mario quand il grandit. Bien sûr, mario-grand est capable de faire des choses que petit-mario ne sait pas faire, mais les animations modifiées vont bien au-delà des nouveaux mouvements. Devenir Mario-tanooki, c'est enfiler un costume. Devenir Mario-feu ou Mario-Marteaux aussi. Devenir Mario-Grenouille (SMB3) change fondamentalement l'ensemble des mouvements du personnage, la physique des déplacements et ne peut clairement pas être assimilé à un costume comme défini plus haut.

Some heroes use costumes. When they have some specific powers, their apparence is changed. Their set of moves doesn't fundamentally change -- it's a costume, not a mutation, but they gained an important additional move that may change strategic choices at some points. Yes, exactly like the fact that Mario is currently able to shoot fireballs, just in case the last platforming section made you forget about it. Grabbing the tanooki suit is a costume. Same for the Hammer Bros. suit. The Frog suit in SMB3, however, is more like a mutation. Many basic moves of Mario like running and jumping are no longer available when you're a frog, and replaced by another set of moves. This is truly a distinct part of Super Mario's state machine, while the Fire Flower merely grant you to access one conditional state (throwing fireballs). I need to find something similar for Bilou's BigPunch power-up.

La question qui se pose pour le développement de Bilou est de choisir le bon moyen de réaliser ce changement d'apparence. Vu la complexité de la machine d'état, plus franchement question de doubler l'entièreté des états pour tenir compte de la disponibilité ou non d'un power-up.

Dans certains cas, un simple changement de contenu de RAM grahique suffit. C'est plus ou moins le cas de SMB3: en utilisant son "mapper" pour remplacer la page de ROM présente, les dessins de Mario petit disparaissent et ceux de Mario grand prennent leur place. A part modifier le visage de Bilou, cette technique ne me permet pas vraiment de changer d'animation parce que moi, je fais de l'animation modulaire: la mémoire vidéo ne contient donc pas d'étapes d'animations mais uniquement des fragments d'image génériques.

I've seen some costume as simple as a palette swap. Megaman uses it quite efficiently. I don't feel to use it for Bilou: its colors are deeply linked to his identity, as far as I'm concerned. I've seen other costumes implemented as a video memory update: some new pictures are loaded and used, while the rest of the code -- including the one that decide which portion of the video memory to use at what time -- remains unchanged. Super Mario Bros 3 obviously works that way, at least for Big / Racoon / Tanooki / Hammer Mario. Same moves at the same place within the different pages. A simple re-mapping of the video ROM and the costumes are swapped.

As much as I like that behaviour, it's useless for me. Bilou's hands and feet cannot be easily replaced because they're shared with bladors and pendats. Only the head could be updated. It wouldn't make the animations -- especially the idle animation -- fundamentally different because I'm doing modular animation: the video memory doesn't contain frames but merely fragments.

A more practical alternative would be to reuse Sonic's shields idea, because those shields are animated and rendered independently from Sonic himself. I don't quite know how I could convey the idea "you have punch power" with such a shield around Bilou, though.

La version plus facile, héritée de la NES et de ses palettes séparées, c'est de changer le jeu de couleurs du personnage (demandez donc à Mega-Man, il en sait quelque-chose). Une approche que je mets de côté pour Bilou: ses couleurs font bien trop partie de son identité.

Autre alternative possible, on se la joue Sonic et son espèce de bouclier transparent. Ici, le sprite de base et toutes ses animations restent inchangées: il suffit de faire suivre Sonic par un sprite supplémentaire suffisamment creux pour qu'on voie encore le personnage par-dessous. Jouable pour Bilou aussi, j'imagine.

Je choisis un système moins rétro mais mieux adapté à mon moteur de jeu: j'introduis des sections conditionnelles dans les animations elles-même. L'idée est d'éviter de devoir modifier les infos liés à l'état -- il continue à ne connaître qu'une seule animation -- mais de profiter du fait que j'ai déjà des instructions type RISC pour les animations (déplacer tel OAM, changer l'image utilisée par tel autre, etc.). Du coup, il est assez facile d'ajouter une "instruction d'animation" qui est en réalité un saut conditionnel dans la séquence, sur base d'un des compteurs de bonus ou d'une des variables internes du personnage. Reste à construire la séquence correctement. Ça, ce sera le rôle du lecteur de scripts. Les animations elles -- et leur éditeur --
restent totalement inchangés. On se contente au moment du parsing de construire quelque-chose de plus complexe comme "if [compteur%] animA else animB".  C'est encore insuffisant pour émuler SMB3 (au niveau script, je veux dire), mais ça devrait faire l'affaire pour Bilou.

So there's one option left if I want to swap animations without modifying the states (and e.g. start having multiple animations per state): the animations themselves. They are build as a sequence of a RISC-styled instructions, each instruction changing one specific parameter of the rendering. My idea is to have one additional instruction that behave as a conditional branch, and allow merging of two animations (or more) in a single one.

It's not quite perfect: it requires the two animations to use the same pages with the same structure because at the moment, only one of the structure will be kept for the merged - conditional - animation. The script-parser that performs the binding is still a bit crude too. Likely too much problem-specific while those instructions could do much more. But it will do the trick for Bilou: School Rush and that's my current interest.

Enfin ... le ROM mapping de SMB3 est peut-être un peu plus compliqué que ça. On voit sur la vidéo de Bisqwit qu'une seule "page" de 256x16 pixels est utilisée à la fois pour Mario, or il y en a 4 différentes par "costume" de Mario. Selon l'action en cours (marcher: +0, courir et tenir une carapace +2, voler +3), la page choisie est différente.

And while we're at it, the costume management for SMB3 could be a bit more sophisticated than I originally thought. Only 1 row is accessible to the NES' GPU at any time, and one "costume" offers at least 3 such rows (dubbed 'pages' on bisqwit's original picture) plus one that is used for star-powered sommersaults. I also spot a "page" that is useful only when Mario is carrying a koopa, or turning back. But excepted for little Mario and Frog Mario, all the rest replicate the same layout for common movements.

Nathan Am Error

I'm reading a book about the NES: "I AM ERROR" by Nathan Altice. I guess you're not surprised. After all, I've been reading Pix'n'Love take on Donkey Kong, "L'Histoire de Mario" and "the Playstation Revolution". But this book is published at MIT press, and written by someone who has a thesis in arts, not an engineer or a game reviewer.

Yet, he got deep into nitty-gritty details about how tiles are used to build the images produced by the PPU, and how game developers and Nintendo themselves tried and extended the features of the NES as competing micro-computers were trying to bridge the technological gap.

Quelque-part entre les chroniques de la saga Zelda et "la révolution playstation", je vais bientôt ranger un outsider: "I AM ERROR" par Nathan Altice. Outsider parce que ce livre-ci a été pensé comme un ouvrage de référence universitaire par un expert d'une faculté "arts & culture" qui va étudier en détail en quoi les limites de la NES ont influencé les gens qui ont créé dessus, leurs oeuvres et les gens qui ont découverts leurs oeuvres, un peu comme on pourrait écrire un livre sur la technique des pigments dans les peintures de la renaissance et l'impact que le changement de matériel pour les pinceaux a eu sur l'oeuvre de Léonard de Vinci. Ici, bien sûr, il sera plutôt question du nombre de couleurs et de tiles, des possibilités de scrolling puis des puces et astuces que les développeurs de jeu et de chez Nintendo ont utilisé pour faire des histoires toujours plus grandes, dans des environnements toujours plus vastes .

I found it pretty surprising that the first generation of NES game had to be soldered for either horizontal and vertical scrolling. Then, cartridge started to include chips that would allow to switch between the two, like with the custom "UNROM" in Mega Man and the official "MMC1" in subsequent Mega Man games. Of course, I already knew that some cartridges featured more than mere ROMs, be it only for the SuperFX in StarFox. But the NES mappers had more arcane things to do and were not that much advertised. And they came as a second choice, as the initial extension roadmap was the disk system and its video RAM where the PPU expected to find tiles and sprites ROM.

En découvrant les maps des jeux Capcom sur NES, j'avais déjà supposé que la console imposait le choix du sens de scrolling: horizontal ou vertical. J'étais loin d'imaginer que pour faire un jeu tel que Megaman qui alterne phase horizontale sur phase verticale, il aura fallu bricoler les cartouches et leur rajouter une puce de contrôle, parce que Super Mario Bros, par exemple, a soudé le choix d'un scrolling horizontal. Toutes ces puces -- les "mappers" -- sont bien plus fréquentes que le SuperFX de la superNES, mais pourtant il n'en a presque jamais fait mention. C'est un détail pour le joueur, presqu'un secret de fabrication. Un secret peu avouable pour les développeurs qui avaient au départ misé sur le "famicom disk system" qui remplaçait la ROM graphique de la cartouche par une RAM remplie à partir du contenu d'une diskette. Pourtant, c'est bien en ajoutant une puce de RAM que Super Mario 3 est capable de retenir quels blocs ont été cassés (la NES n'ayant que 2KB!, à peine de quoi retenir le contenu de 8 écrans).

Still, if you think about it, Super Mario Bros. was already using the full range of pixels that the PPU could use. Embedding more graphics in the game is useless without a technique that could change which 16KiB slice was used. I suspected such techniques existed by 1998 when I first saw nesticle's video "pattern table" window contents updating as SMB3 played out. Those techniques are reminiscent of memory-paging techniques already in use on mainframes by then, but I was far from imagining the level of sophistications those chips could have, having different page sizes depending on the game's need regarding animation or environment diversity, ultimately embedding even additional sound chips and ways to offer real free, 4-direction scrolling.

Ce n'est qu'à travers ce genre de ruse -- pagination pour passer de l'overworld de Zelda à un des donjons, copie à la volée de sprites présents dans la ROM-programme vers la nouvelle RAM auquel le processeur graphique (PPU) a accès -- que les développeurs NES vont pouvoir faire mieux et plus riche que Super Mario Bros, qui saturait déjà les 16KB de mémoire que le PPU sait utiliser. Ici aussi, j'avais soupçonné ce genre de technique en voyant tourner SMB3 dans Nesticle, mais j'étais loin de me douter de la diversité des approches, des subtilités ajoutant des nouveaux systèmes d'interruptions sur une ligne précise de l'écran (devenue partie intégrante des designs de Nintendo depuis la SNES) ou l'intégration d'une puce sonore additionnelle que la NES utilisera comme elle aurait utilisé "l'entrée micro" du 2eme contrôleur de la Famicom.

En revanche, "comment on fait tenir un niveau sur 100 bytes" restera une curiosité dans ce livre. Dommage pour moi. Heureusement - j'imagine - pour la majorité des étudiants qui commandent le livre sur MIT Press...

I'm just slightly disappointed that "how SMB level were packed to a mere hundred of bytes" is the sole sequence that reveal how NES games were created with such a level of detail. I might have to dig for Megaman disassemblies ...

Fixing the level ...

Si l'actuel niveau 2 avait été construit pour servir de préparation à l'ancien niveau 2 (lui-même construit comme un palier de difficulté intermédiaire entre le niveau 1 et le niveau 2 d'origine), ce n'est pas pour autant que tous les éléments avaient atteint un stade définitf.

En particulier, ce tronçon aux trois encriers s'est révélé anormalement dur vu son emplacement vers le milieu du niveau, ce qui m'a amené à le re-dessiner pour en analyser un peu les défauts.

I owed you a detail on how that level 2 difficulty had been fixed. While watching my beta-testing nephew of the S-Team, I had sketchpad and kept noting which parts they had hardest time with. Especially, the 3-inkers obstacle was an issue as soon as ink raising was involved. I can emulate with a slope on the drawn level map how the ink raise as you walk through the level. And here comes the issue. Assuming that you approach the obstacle when the "baldor pit" on the left is barely dry, the two folders that should help you moving through (colored in blue and identified with arrows) will be below the ink level. The only way to meet the obstacle in a more expected state is to really rush through the whole first half of the level.

On est dans un jeu où le level design doit tenir compte de la montée de l'encre, matérialisée ici par la ligne en pointillés: si le joueur n'avance pas assez vite, les plate-formes sont immergées. Le premier point qui fâche dans ce niveau, ce sont les deux plate-formes coloriées en blue et marquées d'une flèche. Elles se trouvent ** plus bas ** que les plate-formes avoisinantes. En d'autres termes, il existe un niveau d'encre pour lequel on voit bien la plate-forme sous le "A" et la dernière plate-forme de l'obstacle, mais où on est incapable d'aller de l'un à l'autre puisque le ssol intermédiaire à disparu.

There is an escape route planned, depicted as "EASY" on the level sketch. The issue is that this route, unlike those in other levels, is extremely hard to follow. Almost harder than going through the default path. Have a look at the animated sequence below. Imagine that you have to 1) get a floating power-up early in the level and keep it; 2) chain from first to the second (long-swinging) sponge despite their lack of synchronism. Then, you'll need 3) to do a nearly-perfect jump off the sponge continue with floating, releasing to land precisely on the block-wide pencil bumper and make it to the "EASY" labeled platform. No 3rd sponge, by the way. 

If you do a single mistake, you're off the "easy path" for good. You'd have to back-track more than 4 screen to the left, which is already tough if you want to still be dry when you're back, but the major issue is that that back-track is only possible through a low path that will very likely be soaked in ink.

L'obstacle permet bien une voie de contournement par le haut, mais son accès était particulièrement délicat. On l'entrevoit dans l'animation ci-contre:
passer par l'éponge au long balancé, faire un saut-plané jusqu'à la gomme en haut du crayon et re-planer jusqu'à la plate-forme comprenant le chemin "facile". Sauf qu'avant la correction du niveau (présente dans la version "fish16"), ni la petite gomme près de la plate-forme "BAY" ni l'éponge entre le haut crayon et la plate-forme finale n'était présents. Le seul moyen d'atteindre ce "raccourci" était donc

• de récupérer le power-up du vol-plané contre le premier crayon du niveau
• de choisir la voie du haut à l'embranchement précédent et d'enchaîner un saut d'une éponge à l'autre malgré leur absence de synchronisation
• faire un grand saut impeccable en quittant l'éponge pour parvenir à atteindre la gomme du crayon haut (qui n'avait pas encore été rapprochée) et rebondir sans perdre sa vitesse -- sans quoi, même avec un vol plané, on aurait de toutes façon pas la possibilité d'atteindre la plate-forme envisagée.

That escape path is not a secret path. It's not a way to get an additional credit or whatever. So there is no real need to require the player to plan ahead. The fact that you managed to do it as a perfect sequence of swings is (or should be) self-satisfying because it makes you go faster, and flow through the level. But with one additional spongebop in case you missed the bounce on the high pencil, at least it's not everything-or-nothing. With an additional little bouncing pink eraser on the "BAY" platform, you can try the challenge even without planning -- or react to the fact that you don't have time anymore for the default path.

Final touch, the "EASY" platform has been broken in two parts, so that you can use the inkers to switch path any way. Again, I believe the interest of that 'EASY' path is not to punish you for not having selected it in advance, but rather to give the skilled-and-trained player the pleasure to move through fluidly.

Et tout ça pour quoi ? pour avoir une maigre possibilité de survivre en mode "hard" où l'encre rend le passage par le bas impraticable. C'est tout. pas de 1-UP. Rien de ce genre. Et bien sûr, si on se rate, il faut revenir près de 3 écrans en arrière en évitant deux pendats dont un bien planqué entre des crayons pointus. Ah, mais non: l'encre qui monte ne nous laissera pas le loisir de ré-essayer la manip.

Du coup, j'ai rajouté une petite gomme en bout de plate-forme "BAY" pour qu'on puisse monter directement sur l'éponge au grand balancé, la deuxième 3eme éponge pour se rattraper et j'ai percé la plate-forme "EASY" pour permettre de passer d'en-bas à en-haut en milieu d'obstacle. Il n'est donc plus indispensable de jongler avec les éponges pour passer par le haut, mais ça fait toujours très cool d'y parvenir.

School Rush "Fish16"

 

Here we go: the long awaited update on Bilou: School Rush game. Still only 4 levels, polished gameplay, improved menus for easier difficulty selection, and last but not least, improved software stability. I also fixed a couple of issues with level maps, esp. in level 2 that still featured a few excessively difficult things. More about that later on.

• A : use your feet (jump, stomp, float)
• B : use your hands (grab, throw, pick up, punch -- double-B)
• R : run (or kirby-like tap-press the DPAD) 

Don't hesitate to have a look at the instruction in the former release if you need additional help to run the game.

Enfin! Une version stable avec gameplay, niveaux et menu amélioré. Cette fois, tout le monde devrait être capable de sélectionner la difficulté (c.à.d. la vitesse de montée de l'encre) qui lui convient. Alors faites-vous plaisir, et essayez cette nouvelle version de School Rush!

• A pour les pieds (sauter, rebondir, planer)
• B pour les mains (attrapper, ramasser, lancer), double-B pour le coup de poing (si on l'a).
• R pour courir (ou alors, à la Kirby, avec un double-coup de DPAD).

The next BigThing (tm) is to complete HUD (or should I rather stay the status screen ?) and give better feedback to the player about available abilities like floating or punching. I thought about dust clouds, sparkles, palette blinks and many others, but given how tight I am currently with the spritesheet, something simple could be preferred. 

Pour la suite, il faut que je complète l'écran du bas, qu'il donne une idée claire de la vie restante, des power-ups, etc. Ce serait bien aussi que le joueur puisse "sentir" s'il a tel ou tel power-up sans quitter le jeu des yeux. J'ai déjà listé quelques possibilités, mais je crois que c'est à travers l'animation de Bilou que je peux faire passer ça au mieux... d'autant que ma planche de sprites -- en plus d'avoir à nouveau des clusters-croisés -- est méchamment remplie.

C'est vrai quoi: ça ne fait pas très sérieux, Bilou qui reste tout souriant à nous regarder alors que le crayon lui fonce dessus. Quelque-chose d'un peu plus street-fight-esque pourrait faire passer l'idée que oui, on a bien le punch-power là maintenant.

Watching the animations of last month, I figured out that something was missing with the ready-to-punch one: Bilou is waiting for pendat to approach and is ready to punch. Yet, he's looking at us, smiling and stancing rather than "feeling the tension of the imminent release of his super-power". I thought it would work better if the idle stance was adapted to this situation, and it could convey to the player the information that "yeah, you've got the power to punch, right here, right now" much better than any random sparkles could do.

Oh, and before you wonder, that's "Fish" because French-speaking people say "poisson d'avril" instead of "April fool".

Je brûle d'envie de faire essayer ça à Kirby Kid, Philippe Dessoly et Eric Zmiro, mais il manque encore ces quelques petites choses qui produiront une meilleure prise en main. A bientôt.

Entre Pech-Merle et Padirac

Padirac par Revenia

Me voici de retour du Lot, une terre étonnante, creusée de toute part avec des rivières souterraines et des chênes nains torturés. Si Miyamoto regrettait la disparition des terres sauvages de son Japon natal, la France a encore sous la main de fameux terrains pour explorateur en herbe, à ce que j'ai pu voir.

A l'occasion d'un jour de pluie ou toute la smala était en repos au gîte, S-team comprise, j'ai pu faire une session intensive de test de "School Rush", et plus particulièrement du menu de sélection de difficulté. Ce genre de test/développement étant évidemment bien plus efficace que des tests isolés ou une semaine de soirées d'essai en se demandant si les gens comprendront ou non comment ça marche. Ici, la question "comment on fait pour revenir à la première page" est sans équivoque, de même que "j'arrive pas à choisir: je sais juste tourner les pages"

J'y suis presque donc. Encore une petite animation de la "main-pour-choisir", histoire qu'elle attire davantage le regard du joueur, puis je m'attaquerai à l'affichage des power-up et du niveau d'énergie de Bilou pendant le jeu.

Je sais: tout ça paraît beaucoup de chipoterie pour un simple menu. C'est l'inconvénient de travailler sans framework, mais je suis convaincu qu'il est cruxial de rendre cette sélection la plus intuitive et évidente possible, parce qu'aujourd'hui plus que jamais, les premières minutes de contact avec le jeu seront déterminantes. Si le joueur ne se rend pas compte qu'il aurait pu choisir une partie plus facile après un premier "game over" trop direct, il n'ira pas voir plus loin. Si je force le mode "easy", il est possible qu'il abandonne le jeu à la moitié, le jugeant trop facile et indigne de son temps.