Spongebop-lifts

Entre les améliorations de mes outils de base pour qu'il redeviennent fiables, le tri de mes listes youtube et la lecture de ce chouette texte sur Mario World, je récolte les idées en vadrouille succeptible de faire un bon dernier-niveau-vertical pour cloturer School Rush.

Not being able to immediately start with the new level gives me the opportunity to let comments from "reverse design" and miscellaneous youtube video percolate in my mind to come up with building blocks for the vertical level of School Rush. For instance, Spongebop "moving platform" doesn't really fit a one-screen-wide level. It would be better to have it as an elevator. Good thing is that I actually have all the core logic ready, and just need at most one extra controller.

Ici, c'est SpongeBop qui s'y colle, reconverti en ascenceur ... la logique qui lui permet de se balancer en arc de cercle offre déjà tout ce qu'il faut pour détecter s'il faut accélérer ou décélérer le mouvement. L'ascenceur aura un mouvement un peu plus élastique qu'une traditionnelle plate-forme d'un Mario, mais ça ne me gène pas vraiment.

1 heure par jour

C'est en gros le temps que je peux encore consacrer au développement homebrew ces temps-ci, avec les déplacements supplémentaires pour les activités des enfants et l'entretien minimum de la maison. Une heure ou je réouvre mon vieux laptop "grizzly" de 2007 qui surchauffe et s'éteint quand on regarde plus de 15 minutes de vidéo youtube en plein écran, qui a besoin d'être sur secteur à chaque cycle d'horloge mais qui offre le confort d'un écran 1680x1050 et d'un clavier avec le bloc "insert/home/pgup/del/end/pgdn" identique à un clavier classique qui s'est révélé plus important qu'un pad numérique.

Une heure par jour pour ajouter une petite brique par-ci par-là. Ou pour constater que ce que j'ai planifié à coup de tablette-à-encre-électronique pendant les creux où j'attends qu'*deline ait fini ses activités ne va pas se combiner avec les autres composants.

One hour a day...this is more or less how much homebrew development I can afford these days with extra trips for kids activities and house maintenance. One hour with my 2007 "grizzly" laptop (the one overheating on youtube videos, but featuring a comfortable 1680x1050 screen and complete keyboard). That just allow me to put a brick here, a line there or check whether what has been planned on e-ink while my daughter is training could work together with what already exists. Even trying to add 30 minutes of blogging is not sustainable for me.

When I was working at the university, I could easily afford 20-30 minutes of lunch time to try a few things, especially thanks to easy SSH connection between home and office. But then I was doing frequent walk or bike as part of my "commute". With kids to pick up or drop, exercise time has lowered to dangerous levels if I'm not at least having a walk over lunch.

Si j'essaie d'ajouter une demie-heure supplémentaire par-derrière pour blogger des micro-succès, je ne tiens pas la distance...

A l'unif, je prenais facilement une demie-heure sur mon temps de midi pour essayer un truc ou l'autre, entre autres grâce à la connexion SSH quasi-automatique entre le PC du bureau et celui à la maison. Mais je faisais régulièrement les trajets en basket+bus, voire à vélo. Avec les loupiots à déposer, je ne marche quasiment plus dehors en semaine à moins de le faire sur le temps de midi. Et moi, si je ne marche pas, je disjoncte. Donc je marche. Tant pis pour les lignes de code homebrew que j'aurais pu mettre (ou les traductions de post) pendant ce moment-là.

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.

nohup NUC

I got a NUC as Christmas gift, and it was more than welcome. I hope to use it as the post-desktop device for plenty of purpose, mostly just by turning it on and interacting with a WiFi-capable gadget...

[done] be the music machine of the living room
It is not too noisy with its fans, gets a jack output and can easily fit next to the HiFi system. I can use the WiFi connection to quickly view which song is being played, skip to the next song and switch between "fairy-lover" or "chiptune-lover" modes, from any device in the house including smartphones and tablets.

I would still need to let it learn which songs are less liked, or migrate some titles to other folders, etc. Preferably in a way that would not take effects immediately, but rather that is approved over ssh after having been collected during play sessions.

[done] make Fairy's laptop devkit-free

Fairy's laptop still has a battery. Mine is now powercord-tied to the ground. Fairy's one has poor resolution but increase mobility, but Fairy's one isn't always there, so it would be better to use it just as a remote terminal to the NUC instead.

[done] let it serve (auto-generated) epub doxygen
That means having it a mercurial hub with improved features. I use to have something like "nohup hg serve --webdir-conf /path/to/hg/hgweb.config -p 5555 &>/dev/null &" at work, where hgweb.config is simply a list of 'printname = full/path/to/repository', where printname may be 'organizational-folder/repository-printname'. It all falls under a [paths] section of an INI file. But I'd like it to try building and generating documentation whenever I push a new set of commits there. The ultimate goal is being able to browse up-to-date code from my boox without having to power up a laptop.

[wish] make it the server for boox-based diagram editing
That will also help integrating all sort of support pictures like screenshots and UML diagrams into the documentation.

[todo] make it download OC Remix updates on a daily/weekly basis

Because having OC remix on the wrong side of the firewall at work is a pain. My "coding music" is an open playlist,

• and html class pl-video-title-link allows  to identify all the links to the mentioned videos.
• and there is the page to the remix (https://ocremix.org/remix/OCR%%%%%) in tags
• and there is a tag in youtube pages!

So I could have a script that automates download of new OC titles running on the cube...

[todo] enable Androïd development
 
That will be for when I got it plugged into a wired network again: I don't know whether this is due to the extra disk enclosed in the device, but the WiFi connectivity is a nightmare. I get a few 100Kbps at best ... barely enough to use a remote terminal. I'd rather not start installing big things that way.

[todo] make it a better youtube-on-TV than what the ISP provides in their box

Partly because there is no support for user accounts or playlist of any sort in the box...

Special!

Youpie! Ma fée m'a retrouvé mon GBA micro avec Super Mario World dedans ^_^. Et à reprendre ce jeu-là, je me rends compte que je m'étais assez fourvoyé sur le compte du monde "Spécial". Je le considérais comme le passage secret ultime, d'une difficulté crasse, qui ne raccourci rien et qui mêne à un objectif bizarre et pas drôle: la transformation de toutes les couleurs du jeu (plus terne) et le remplacement des tortues par des "faux mario"... Wéé ...

A l'époque, j'avais du mal à passer le deuxième monde du jeu, et je n'avais plus aucune chance de terminer un niveau en une vie une fois arrivé dans la forêt illusoire.

At last! for the first time since '96, I can enjoy Super Mario World -- and now use some Super Papa Bros. time to study its design. I made a hidden reference to the "Special" world of SMW in a recent post, where I presented it as a poor type of reward for dedicated exploration of the game's secret: I simply saw it as insanely hard levels that led to a mysterious switch that replace all monster graphics with out-of-topic ones. I realized since then that the reward wasn't that much about the destination of the Special world but rather about the journey through Special world.

Maintenant que j'ai atteint un niveau un peu correct (jusqu'au chateau avant la vallée de Bowser sans game over), les choses m'apparaissent différemment. Quand je jette un oeil au niveau tubular sur Youtube, la réaction c'est "wow! excellent! tout un niveau où on flotte comme un ballon!". Puis deux niveaux plus loin "Haha! ici, ils ne se sont pas privé avec les tortues jaunes et bleues! ça doit être la fête avec son Yoshi!" En fait, le monde spécial ne mène pas à une "récompense": il *est* la récompense pour le joueur suffisament entrainé. Des niveaux où les concepteurs du jeu ont cette fois laissé libre cours à leur fantaisie et construit des niveaux possibles sur base des éléments peu fréquent dans le jeu, sans tenir compte des contraintes habituelles du genre "on vous promet qu'il est possible de terminer le niveau en 1 vie même si vous ne l'aviez jamais vu avant".

I got the enlightenment while watching some Special speedruns on Youtube while my GBA had actually disappeared in the sub(sofa)-space, just after (barely) beating Gnarly level. I had always remembered Tubular as complete madness, where you have no place to land and things got thrown at you all over the place. That was missing the fact that Tubular is actually about turning Super Mario into a kind of shoot-m-up level where you're ballooning and have to locate the next hidden balloon among the [?] blocks on tight timing. In the rest of the game, taking a balloon is optional, and when deadly, you get a free 1-UP ahead of the danger.

Donc oui, c'est dur (parce qu'on pousse en avant les nuances du gameplay et les

techniques avancées), et il faudra de la mémorisation pour venir à bout de certains niveaux. Mais on est en réalité bien plus proche des "mondes cachés" de Donkey Kong Country que je ne l'aurais cru...Mondes cachés qui étaient également basés sur le détournement des règles établies dans le jeu avec "ici, jungle des pneus qui tuent" ou "le niveau où tu vas jouer avec tous les copains-animaux".

Just like Lost World of DKC2 -- which I loved a lot and made me start DKC3 with only one question: how do I get to the Lost World this time -- Special World is about doing the forbidden, breaking the rules and going wild. It's about making the rare Blue and Yellow Koopa common for a couple of levels so that having Yoshi around turns into a sort of fancy fair in Awesome. It's about doing mad spin-jump on a platform maze in Way Cool. 

Et les koopa-mask, alors ? Pourquoi cette ridicule transformation de tous les monstres ? Apporte-t'elle quelque-chose au gameplay ?
Peut-être bien. Pour arriver à la fin du monde Special, il faut un fameux nombre d'heure de jeu sur un mario. A ce nombre d'heures, on lit inconsciemment un écran. En vision périphérique, on sait déjà qu'un personnage est un koopa, un parakoopa ou une plante pirhana. Plus besoin d'y réfléchir: ça vient d'instinct, comme de porter la main à son sabre laser si on croise Darth Vador. Et tout d'un coup, on va dire au joueur "eh, Julien, tu crois que tu y arriverais si tu ne pouvais pas compter sur tes années d'entrainement à jouer à Mario ? Eh bien c'est ce qu'on va voir. On mélange les cartes! Pire, ils vont tous te ressembler au point que tu devras te concentrer ne serait-ce que pour savoir où tu es vraiment!".

But then, why offering those curious "koopa mask" to the Super-Player that beats the Special World ? What does it bring ? It's not even truly fun (imho). After reading Kirby Kid's definition of "a mix up", it becomes clearer in my mind. Having picked Mario's head shape is not accidental: it's deliberate. Mario's head has been progressively hard-wired into the player's mind as "me". And now Nintendo's designers change the rule and "me" becomes your worst ennemy! Rather than reading "pick me up!", the empty koopa[mask] shell reads "me". Instead of reading "Jump! I'm gonna kill you", the shell that bounced and comes back reads "me" again. Picking the Koopa for that purpose isn't an accident either: it's the monster that has the most interplay with Mario. So that 'season switch' isn't merely about "replacing the graphics": it's truly a "hard mode" hidden within the game, that resets your habits and puts you in a somewhat parallel world where you cannot trust your eyes.

Oui, c'est bel et bien un "mode hard" caché au sein du jeu.

The true Mario Jump

J'ai un vieux post, le premier qui raconte comment on peut faire sauter un personnage dans un jeu vidéo. Dedans, il y a une image où j'explique que la physique de SMB3 est un peu 'truquée' du côté des sauts. Mais bon, j'avais fait ça à la grosse loupe sur une vidéo youtube, alors que l'ami Upsilandre, lui, a du lourd sur le sujet: il a analysé en détail les mouvements de Mario et ceux de TinyToons Adventure pour voir s'il y avait eu des fuites de code source entre les deux jeux.

When I was writing one of my first post about having a character jump in a tile-based game, I had the surprise to see that Super Mario bros. 3 doesn't seem to use Newtonian gravity. Instead of having a smooth parabolic curve, there seems to be linear rise, parabolic climax and linear fall in a Mario jump. But I did that just by checking a let-s-play video on youtube. On his French blog, Upsilandre did a detailed comparison of SMB3 and Tiny Toons Adventure where he gathered all the impulse and gravity constants, so why not pay him a visit ?

Il pointe notamment une correspondance exacte pour les impulsions de saut. au centième de pixel par frame près. Troublant ? Eh bin, rappelons-nous: quelques paragraphes plus haut, il relevait aussi que les deux jeux utilisent le même format de nombre pour les vitesses: 4,4 bit

La vitesse dans Tiny Toon est encodée exactement dans le même format à virgule fixe 4b.4b que je n'ai vu que dans SMB3 (même pas dans SMB1), en général c’est plutôt du 8b.8b (voir du 3b.5b). [...] La même force de gravité faible de 0.06 tant qu’on maintient le bouton saut (comme si on était sur la Lune) et une force de gravité forte de 0.31 (retour sur Terre) quand on lâche le bouton ou que la vitesse verticale passe en dessous des 2 pixels par frame (donc quand on approche du sommet du saut). [...] [on va retrouver] strictement les mêmes 5 valeurs d’impulsion à la décimal prêt (respectivement 3.44, 3.56, 3.69, 3.94 et 4.00 ppf). La seule chose qui diffère c’est la valeur qui sert à caper la vitesse max de chute qui, comme pour la glissade en pente, est plus basse dans TTA.

Petite précision: cette histiore de 4,4 (ou 4b.4b selon la formulation d'Upsilandre) signifie que toute vitesse est exprimée en un nombre entier de 16 de pixel/frame. et on peut aller de -16 à +16 pixels par frame (mais personne n'ira jusque là). Du coup, 0.44 c'est 7/16, 0.56=9/16, 0.69=11/16 et 0.94=15/16. Déjà beaucoup moins surprenant. Notons au passage que la gravité lunaire de 0.06 pixels/frame² correspond à une simple décrémentation de la vitesse en 4,4bit. C'est 1/16eme. Tout simplement. Sur un processeur tel que le 6502, si on peut décrémenter plutôt que de soustraire 2, c'est toujours ça de pris.

The most interesting part is that the game uses two different gravity values. the 'ramp up' part of the jump uses the lowest possible gravity the game can deal with, of 1/16th pixel per frame². The switch to another gravity happens when we reach a vertical speed of 2 pixels/frame (or if the button is released), and we then go for 5ppf².

The impulse value may seem surprising, especially when expressed as decimal values like 3.69ppf. In fact, they integrate to nicely integer jump height expressed in Super Mario Blocks. What it means is that any game that wants to use the same gravity as SMB3 and a map made of 16-pixels blocks is likely to need the same impulse values as well.

Mais pourquoi ces valeurs-là ?
C'est le moment de ressortir un autre vieux post où on reverse-designait Super Mario World. Le game design forum y pointait que tout se mesure en bloc, dans le monde de Mario. Y compris la hauteur et la longueur des sauts. je ne serais pas surpris de découvrir que les impulsions correspondent aux vitesses qui permettent de franchir un obstacle de 3, 4, 5 ou 6 blocs le plus justement possible. Mais on a les valeurs, donc vérifions!

Voilà donc: selon l'impulsion initiale (v0), la hauteur atteinte (y2) au moment où la vitesse vaut 2 (et où on applique une gravité "normale" proche de 5/16 ou 6/16 ppf²). Avec en prime le temps mis pour y parvenir. Les valeurs 'magiques' correspondent à un obstacle de 4, 4.5, 5 et 6 blocs respectivement.

During the fall down, the game physics makes the terminal velocity kicks in very soon. As soon as 2 blocks high, actually. It may be an important part of consistent air control, giving you equal chance to hit RIGHT and reach a platform regardless of how long you've been falling down. The quasi-linear ramp up with super-small gravity does its best to mimic that for gameplay symmetry and ensures that we don't need speeds near 1 tile/frame if we want to jump up to 6 blocks high, as 1 tile/frame is almost warp speed for a 8-bit game engine.

ça, c'est pour la montée en gravité lunaire. Avec une gravité de 5/16, il faudra 22 frames pour tomber de 65 pixels de haut, mais 2 frames plus tard, on aurait déjà franchi 80 pixels. Enfin, ce serait en supposant que les programmeurs de SMB3 n'aient pas mis une 'terminal velocity' pour la chute libre en-dessous de 6ppf². En réalité, comme le fait remarquer Upsilandre, la vitesse de chute est limitée à 4+5/16 ppf par la "friction dans l'air". La mini-gravité en début de saut est essentiellement là parce que le gameplay veut une hauteur qui ne devrait pouvoir être atteinte qu'avec une vitesse de chute supérieure à cette vitesse terminale. Sans ça, il faudrait une impulsion de plus de 7+8/16 ppf pour dépasser 6 blocs de hauteur. On s'approche dangereusement de la limite de 1 tile / frame à partir duquel le code de détection de collision avec le niveau doit être radicalement modifié.

Au final, 

• la descente de Mario est principalement linéaire. Il n'y a accélération que pendant les 2 premiers blocs (1 mario) de hauteur.
• la montée de Mario n'est pas strictement linéaire, mais la gravité est si faible que la différence est à peine perceptible. Elle va surtout agir comme un compteur intégré de frames de montée forte avant de passer à la phase 'sommet du saut'
• le changement de gravité au moment de relâcher le bouton offre une alternative sympa à ma solution de "forcer la vitesse de saut à -2 si on relâche le bouton [et que...]" 

edit: j'en profite pour sortir d'un vieux draft un autre schéma 8-bit d'upsilandre: la comparaison des courbes d'accélération de différents personnages.

edit+: en comparaison, Gomez ne sait sauter que par-dessus un obstacle de 2 blocs de haut mais peut s'accrocher à un rebord à 3 blocs de hauteur. Plus approprié pour un jeu de puzzle comme FEZ.

Nitrome, Ni trop peu

Il y a 25 ans, avant de commencer le projet Caliméro et devant le refus de mon frère de me dessiner d'autres niveaux pour Logic Labyrinth, j'avais imaginé utiliser RND() pour me construire des variations de la "Bridge Zone" de Sonic 1 (SMS) sous le nom de code "Sonic Labyrinth".
Le projet n'aura débuté, mais vous comprendrez que quand j'ai vu "Platform Panic/Infinite Platformer" sur twitter, ma curiosité était immédiatement piquée.

Thanks to birslip, I discover "Platform Panic" by Nitrome studios. I said earlier I wasn't interested in procedural generation for platformer levels, but I once had ideas like that, so cute pixel + implementation of some old fantasy of mine = curiosity leveled up.

May the Seed be with you
After watching some trailers and playing the game with my brother, I don't believe we have procedural generation here. It rather looks like a flip-screen game where the screens were turned into decks of cards and each deck was shuffled. When starting a new game, the system draws a few screens from each deck (and each deck correspond to a difficulty level). The combinations are numerous, and you will never face the same game, leading to some level of permadeath. Still, you will recognize rooms you have met before, and each room gives a feeling of being designed with care.

Il ne s'agit pas véritablement ici de créer des niveaux aléatoires au sens d'un roguelike et de son générateur de map. Je pencherais plutôt pour une base de données de salles parmi lesquelles on tire une séquence de salles pour la partie donnée, comme dans Qwak, mais généralisé. Tout comme Spelunky, on est ici dans un jeu à "permadeath" -- comprenez que votre mémoire ne vous sera que moyennement utile si vous échouez parce que la partie suivante pourrait très bien ne pas faire ressortir la salle qui vous a donné du fil à retordre. Et c'est du "one-shot", aussi ... à la Fury!


Building Blocks

I tend to believe that playing a video game is learning. The most obvious is to learn the topology of the playfield, but with the shuffling, this is not as useful here as in Donkey Kong Country. But you still learn. How far a jump goes. How close you can approach from hazard while still being safe. And most of all, what is hazardous and what to expect from it. Platform Panic feature most of what you could expect from split-screen platformer if you ever played any Spectrum-era willy-esque game. Crumbling floor, revealing spikes, springs that throw you up at first contact ... to get you reach the spikes on the ceiling, plus your usual falling hazard and shooting walls.

Bloc escamotable, pointes qui chutent ou qui sortent après votre passage, ressorts qui propulsent sans crier gare ... sans oublier les plate-formes mobiles, bien sûr. Les ingrédients du level design de Platform Panic sont de vieilles connaissances qui ont fait leur preuves -- si vous êtes du millénaire dernier. Par contre, les contrôles résoluments iThing, ce qui rafraîchit la donne. Avec un mouvement "demi-tour" et un mouvement "saute", le petit perso n'est qu'à moitié sous votre contrôle ... à peine plus qu'un lemming, en fait. Ce n'est pas sans rappeler "Rayman Jungle Rush" de Pasta Games / UbiSoft, mais ici en "flip screen".

While all this might feel réchauffé, it is served with your favourite touchscreen indie sauce on controls. One move to make you turn back, and one move to jump. No sophisticated buttons to press this time, but no time to rest either. Your character is always moving, and most of the time, it is moving towards instant death. You'll have to learn to identify those hazards quickly and plan ahead if you don't want to trap yourself.

Pixel Perfect
Côté graphisme, Helm nous a concocté un environnement agréable, rétro ni trop peu, facile à "lire" (bleu=inerte, pas bleu = méfie toi), mais pas surchargé non plus, et des petits personnages de toute beauté. J'ai bien peur que mes capture de trailer youtube n'en donne qu'une idée très déformée... Et c'est tant mieux, parce qu'il y en a, des pièges retors, et qu'avec un perso qui avance en permanence, on a qu'un rapide coup d'oeil pour analyser la situation et voir que "si je me laisse tomber ici, les pics vont me suivre et me prendre au piège".

Hopefully, Helm did a wonderful job on the pixel art. It is charming, varied while remaining easy to read. I'm afraid the screenshots from youtube videos won't do it justice and you'll need an alternate source to get a clear idea of their quality. The design of the characters is lovely as well,


Je suis assez bien fan du design des robots de cette usine (?), qui se déclinent jusqu'ici en "sauteurs", "marcheurs" et "volants". Il y a aussi les mines, bien sûr.

No Tuto
A l'exception des glissements de doigts suggérés sur l'écran d'accueil (la salle 0), il n'y a pas de réel tutoriel. On apprend de ses erreurs. Heureusement, elles se produisent surtout en début de partie quand on a pas encore appris ce que font les différents blocs interactifs. Je suis tenté de penser que les niveaux sont regroupés en "phases" et que le jeu progresse d'une phase à la suivante avec une difficulté qui augmente par palier. Niveau 1, une seul obstacle par salle. Niveau 2, on commence à combiner (p.ex. blocs à pointe et tir de missiles). Niveau 3, il faudra enchaîner les contrôle comme faire demi-tour en cours de saut.

I love how the Nitrome team dared to go to the essence of the game and not clobber it with tutorial on each hazard. You learn from you mistake. You fail a lot when you start, but your failure is just another way of exploring. Because you're not repeating the very same steps every time you retry, dying is not so frustrating. It gets more frustrating when you reached some depth in your path and now have to start again at room #1. But that's more the kind of irritation that make you want to beat your own score rather than some frustration that makes you wish you weren't playing.

Coin Layers
You will then realise that those coins that look randomly dispensed in the level have more value than you thought. They can be used to purchase continues (try again the room you fail) and other power-up that will change how you experience the game (I guess, although you might have to farm a lot for that). But mainly, placing the coin at this or that part of the screen allows for slightly more variations and bring closer to "infinity"... 
All to say, I love the game's design. It's an effective way to build fun time from old-school gameplay elements. I might reuse the idea when time will come to make a mini-game in Bilou's pyramid or castle zone.

Que faire à part s'éclater dans ce jeu ? Eh bien collecter des piécettes. D'abord parce que c'est brillant et tournoyant alors qu'il y a de la gravité, mais surtout parce qu'à un certain niveau dans le jeu, elles vous permettront de vous acheter des continue plus que bienvenus (15 pour le premier, 30 pour le second, etc.). Elles permettent aussi de débloquer des persos supplémentaires (l'armure double-saut, p.ex.) ou des nouvelles compétences (rebondir sur les ennemis ?). Placées adroitement, elles permettent tout comme dans un bon Mario de pousser le joueur un peu plus dans les cordes. Elles ajoutent aussi une couche d'"infini" puisqu'elles ne sont visiblement pas toujours au même endroit lorsque le jeu vous ressert la même salle.

Voilà. J'aime beaucoup la recette, et j'ai très envie de la resservir dans un des "mini-jeux" qui servent de jalon le long de la route qui mène à Bilou's Adventure ... Ça marcherait assez bien avec la Desert Zone, voire avec la Castle Zone.

Les démos

 Après la bafouille sur "Titanic Death by a Worm", vous avez peut-être l'impression que la démoscène, c'est une page que j'ai tournée depuis longtemps. Dans un sens, vous n'avez pas tort, mais n'allez pas croire que j'aie coupé tous les ponts pour autant.

Bon, d'accord, depuis 2005, je n'ai clairement plus un PC capable de faire tourner des productions récentes, et depuis que youtube a débarqué dans l'équation, j'avoue me contenter de regarder des vidéos des démos plutôt que les démos elles-même. Le fait que j'utilise mon PC aussi pour les paiements en ligne et qu'il tourne Linux n'y est pas complètement étranger.

J'essaie aussi de me tenir à la page, et de ne pas sombrer dans le nostalgisme à ne regarder que Heaven Seven ou Second Reality. Non, chaque année je creuse comme je peux pour essayer de trouver les pépites publiées dans l'année. Pour 2020, selon moi, c'était Apex par Bitbendaz

Je salue bien sûr tous les afficionados de l'Amiga et du Commodore 64 qui continuent à donner de leur temps pour que leur idole survive. Mais je dois reconnaître que ce n'est pas l'esthétique qui m'interpelle. En 2018, ma démo-fétiche, c'était par exemple "Reboot" d'Umlaüt Design.

Et la découverte de 2019, c'était "ninjadev" avec des titres plus exotiques les uns que les autres comme Construct (bravo les Légos), Flat shade society (bravo le jeu de mots) ou What are you syncing about (bravo la bande son)

Mario in Godot

Refaire Super Mario World dans le game-maker "Godot" ... j'ai envie de dire à la fois "tout ça" et "rien que ça". Pourtant, l'idée de Wye n'est ni de proposer un Mario World Studio ni son Mario World 3. L'idée, c'est de comprendre le fonctionnement du jeu d'origine en le reconstruisant dans un nouvel outil tout en apprenant l'outil lui-même. Et ça, ça me parle. C'est le genre de bouquin que je dévorerais mais ici, ce sont des vidéos youtube.

"In Super Mario World, Mario was considered fully underwater if both his head and body interaction points are touching water tiles. [...]

That's the kind of things you can learn by watching Wye's series on re-making Super Mario World in Godot, and learn how to use Godot in the process

I've been following the videos roughly since episode 1 or 2, but as Wye now address the water physics, I cannot just remain a silent watcher. I've spent too much time working on water physics myself, and I need to compare the approaches. Of course, Mario isn't using the "cando"  function. Instead, interaction with the world are guided by "interaction points" which remember the type of tile they're on. So for instance, 

"When Mario body is in the water but not his head, that means he is near the surface."

Du point de vue des collisions avec le niveau, Mario n'est pas une boîte. Il est ... une sorte de constellation de points qui ont chacun leur préférence sur le type de terrain 8 en tout, mais dont certains ne seront évalués que dans certaines conditions. Pour déterminer s'il faut nager ou non, ce sont par exemple ce sont les tests du milieu et de la tête qui entrent en ligne de compte. Et pour déterminer si on peut sauter hors de l'eau ? Bin il faut que le corps de Mario soit dans l'eau mais sa tête hors de l'eau. On évite en fait les complications du type "la surface est à la fois de l'air et de l'eau" dans lesquelles je me suis embarqué.

And only when Mario is near the surface is it possible to jump out of water ... and only if pressing UP in addition to pressing the JUMP button ...

The concept of interaction points comes from the disassembly of SMW itself and was discussed in an earlier video. They replace hitboxes when it comes to interacting with the world and there are 8 of them for Mario. But as usual with 16-bit games, not all points are tested on every frame. What is interesting is that rather than testing e.g. "left side" when moving left, the game tests "left side" only if the left side is "smaller" than the right side, as a way to detect "new" things, assuming that what covers most of Mario's box has been tested in the past. "When Mario is on the right side of a tile, the two points on the left are ignored" is possibly a better way to describe what happens, indeed ^^".

I'd be curious to find out to what extent that keeps working where your level grid isn't exactly one hero wide ...

edit: while you need to *press* the jump button to make Mario jump when he hits the ground from a fall, you just need to be *holding the button down* when reaching the water surface to trigger "jump out of water".  (from the "extra bits")

Enfin, des pentes qui marchent !

C'est encore un peu mystérieux, mais ça commence à fonctionner! Petite démo téléchargeable (non-jouable, par contre) de mon "cas d'étude pour le débugging". Je vais tagguer le CVS pour qu'on puisse retrouver les sources correspondantes.
Je dis "mystérieux", parce qu'au départ, l'appleman semble "hésiter" à prendre les pentes, chose qui n'a pourtant pas été programmée comme telle. Je soupçonne un effet de bord des vitesses inférieures à 1pixel/frame, sans avoir pu creuser complètement.

Howdy! It starts working (though still subtly mysterious). Rather than trying to shoot you a full-blown Youtube Video, i used byzanz-record and some javascript to provide you a nice "video" teaser (hover the picture, you'll see ;). On the other hand, you're welcome to grab the running .nds and try it on your favourite emulator or linker.

owlboy: monkey feedbacks

J'étais arrive au continent volant, convaincu qu'avoir pris conscience que je jouais à un shoot-em-up allait enfin rendre le jeu plus facile à aborder. Malheureusement, ça n'a pas suffi. Je me débats avec le tir explosif du personnage secondaire, je peine contre des mouches carnivores invisibles pendant des heures pour finalement découvrir dans un let's play (après avoir laborieusement passé la zone) qu'en réalité elles sont juste déclenchées par un timer quand on reste trop dans le noir, et qu'il faut trouver d'autres torches pour les tenir à l'écart, et non essayer de les vaincre.

Je ne peux pas m'empêcher de penser que quelque-chose lié au temps devrait clairement indiqué comme tel au joueur. Ok, l'idée des mouches carnivores est merveilleusement intégré à l'histoire, mais rien ne les lie au temps, au fait d'être dans l'ombre, ni même ne nous renseigne sur ce qu'elles sont réellement.

d'autant que juste après ce dialogue sur la peur des mouches, on tombe sur un buisson avec des insectes qui tournent autour et qui se mettent à nous tourner autour. On ne sait pas les toucher, mais si on brûle certaines lianes (le personnage au "briquet" vient de nous dire qu'il ferait de son mieux pour les tenir à l'écart, c'était assez gros comme tutoriel déguisé), elles quittent les lianes pour se réfugier dans le buisson voisin.

Mais non. Ce n'était pas ça.

Le mouches en question sont noires, et invisibles dans le noir. Et je ne suis pas le seul à m'être tout d'un coup dit "eh ? que se passe-t'il ? pourquoi je perds ma vie, tout à coup ?". On aurait pu être dans une impasse, et être forcé d'apprendre. Les mouches auraient pu être visibles si on est mis game-over. Mais en réalité, si on va suffisamment vite, et qu'on va de l'avant, on reste assez proche des lucioles innoffensive jusqu'à ce qu'on atteigne un 'fruit-lumière'. On a donc pu passer et les mouches vont passer au second plan. Le problème se reproduira plus tard dans le niveau, quand les fruits-lumière se feront plus rares. C'est là que j'ai dû faire appel à un wiki pour comprendre de quoi il retournait, à quoi ressemblaient ces "mouches", etc. personnellement.

Je suis tenté de raccrocher ça au fait qu'on est en face d'un jeu indé, avec une équipe trop restreinte pour qu'à un moment quelqu'un de suffisamment influent et avec assez de recul sur le développement ait dit "non, ça ne va pas. Les joueurs ne comprendront pas". Peut-être bien l'origine de ce que Kirby Kid appelait "that indie feel" ...

Tout ça me donne l'impression que la communication des objectifs et des avertissements n'est pas aussi claire qu'elle le pourrait. Et le deuxième boss dans la lave a tendance à me renforcer dans cette idée. Ici, on se fait régulièrement attraper par un des singes et plonger dans la lave, ce qui met fin au combat. 30 à 40 minutes de jeu plus tard, ça n'avait toujours pas changé. Je ne m'attend plus à passer un boss du premier coup dans le jeu: je sais qu'il faudra que je sacrifie d'abord quelques vies pour comprendre ce qu'on me veut.

Ici, il aura fallu une vidéo youtube pour que je réalise qu'il était possible de se libérer de ce genre de prise. Et non, je n'aurais jamais pensé utiliser le bouton "Saut" pour ça! Ni qu'un tel mécanisme puisse être introduit si tard dans le jeu sans un indice sur l'action attendue. D'autres évènements en cours de combat (comme le fait d'être enflammer) sont annotés avec l'action à faire pour se "soigner". Pourquoi pas ici ?

Iconoclasts perdait peut-être parfois un peu en immersion avec ses icônes, mais au moins les intentions des développeurs étaient claires. Ici, on dirait qu'il manque le message "RELOAD" d'un rail shooter.

Et ce genre de problème de communication va se généraliser jusqu'à ce que l'on trouve le troisième personnage et que le jeu s'écarte un peu du fait de tirer sur des cibles. Mais Alphonse et son arme dont on ne voit ni la portée ni la direction de tir va nous faire passer un désagréable milieu de partie...

https://www.spriters-resource.com/fullview/78065/ {alphonse}
https://www.spriters-resource.com/pc_computer/owlboy/sheet/84737/ {monkey}

De plus en plus long ?

Ai-je raison de penser que les niveaux de jeux de plate-formes sont de plus en plus long, et donc infaisables sans avoir une demi-douzaine de checkpoints au minimum et des vies infinies ? 

pirez in Bilou : School Rush (1'30") P

SMB 1-1 à l'aise (1'20") NES
SMB 4-1 à l'aise (1'20") NES
Commander Keen, perilous pit (4'00") SNES
Commander Keen, perilous pit (0'45") -- world record. SNES
DKC, Millstone Mayhem (1'20") SNES
SMW, Donuts 1 (1'15 en prenant son temps) SNES
DKCR -- level 2, 100% (7'30") WII+
DKCTF -- level 2-6, no collectible (2'40) WII+
Rayman Origins, level 2-1, 3 cages (4'30") WII+
Splasher, level 2 (speedrun) (1'30") WII++
Splasher, level 7 (speedrun) (1'50") WII++
Giana Sisters Twisted, level 1-6 (speedrun, no boss) (4'35") WII++

La minute' trente de Pirez pour finir le parcourir le niveau 1 de Bilou: School Rush est donc assez bien dans la moyenne. Ce n'est pas un niveau court, mais ce n'est pas un niveau long non plus. Il y a bien des jeux qui ont des niveaux beaucoup plus longs (la palme revient à Giana Sisters, talonné par les Donkey Return/Tropical freeze si on essaye de récupérer les items).

Sometimes, I got the feeling that levels in platformers are up to 10 times as large as they used to be. That feeling grew up as I played/watched some Tropical Freeze and culminated with the strolling in the amethyst mines of Giana Sisters: Twisted Dreams. But is it accurate ? Above is a list of youtube power plays / speedruns of some of my reference games. I picked the second level most of the times, or the first level orf world 2 ... or some particularily memorable level I want to compare against.

It looks like I'm not completely wrong, but biased by the amount of side-action that exists in latest Rayman and Donkey Kong games. Splasher, on the other side, seems to have a more standard 1:30 average run-through time. Just like Bilou: School Rush :P .

Splasher, par contre, reste dans un timing habituel. C'est uniquement parce qu'il s'agissait d'une "blind race" que j'ai eu l'impression que les niveaux étaient beaucoup plus longs que le "niveau standard"

PS: non, ne cherchez pas Keen 4 sur NES. C'est un jeu PC. Je le mets dans "SNES" en fonction de son époque et de sa technologie (CPU 16 bits, peu de mémoire, son FM). Idem pour les "Wii+" et "Wii++".

Ah oui. J'expliquerai un peu plus tard le lien avec Splasher.

design [t.a.g.]

Level design is the first item I considered when starting to think about video games beyond a pure technical point. I use to think about it as the art of drawing interesting maps. If it looks cool on a sheet of paper, then it's great level design.

I started thinking about game design after I experienced new Super Mario Bros for the first time, and immediately compared it to SMB3. It captures the rules and the decisions that affect the whole game, especially how you manage game-over, save states, character abilities and whether they are progressively revealed, etc. If you can't alter it with e.g. RSD game-maker or an editor in any way, then it's likely game design.

Le premier élément de design auquel je me suis confronté, c'est le design des niveaux. Enfin, quand j'ai commencé à aller au-delà de l'aspect purement technique de la réalisation et à embrasser aussi la conception de jeu. Je définirais le level design comme "l'art de dessiner des cartes intéressantes". Si ça a l'air cool sur papier, c'est un bon level design.

Après, il m'a fallu faire la distinction entre gameplay et monster design. Certains niveaux -- chouettes au départ -- perdent toute leur saveur si on change le comportement des ennemis qu'ils hébergent. ça, c'est du 'monster design'. Mais le gameplay va au-delà des interactions avec les structures, le personnage et les ennemis. Le gameplay prend aussi en compte ce qui se passe entre les mouvements de l'utilisateur et les règles de bases du moteur de jeu. C'est la partie du jeu qui ne sait pas être représentée sur papier et pour laquelle l'expérience est indispensable: la partie que même une capture vidéo ne montre pas et qui mets en jeu notre dextérité, nos réflexes et notre sens du timing.

It took me time to realise the difference between gameplay and monster design. I had noted that some levels may be completely boring if you change the behaviour of the monsters that are in.

But gameplay goes beyond that interplay between static structures of the level, player's avatar and monsters. It really defines what goes between user input and game engine core rules. It's the part of the game that definitely *cannot* be depicted on paper and that *need* to be experienced. The part that Youtube cannot show you and that stress your dexterity, reflexes and timing.

Out of Memory

There's something going disturbingly wrong with my debian setup ... I thought it was mainly an issue with firefox, where the whole system froze and became completely unresponsive when youtube's scripts push the browser out of memory bounds. But it just happened as I tried to convert a too complex picture into a stack of svg path with inkscape while still having gimp opened with the bitmap edits and consuming about 3G of RAM to host them.

Usually, I can then access a text terminal and launch the top tool to kill the process that went crazy, but with that debian 12, it seems like it couldn't even keep that in memory ... too often, I end up having no other option but forcing the system to shut down, losing whatever state I had on the machine.

A message on stack exchange describes quite accurately what is possibly going wrong: the system has been assigning so much memory to data that it started stealing pages of executable code from processes ... and unfortunately, those processes call these pages back, forcing the swapper to find something else to kill, again and again. the "Out Of Memory" behaviour of the system does not kick in, or not before things have been running wild for over 10 or 20 minutes.

I've found some blog page presenting "Early OOM", an alternative that would kill memory-hoggers process in advance. Got it installed ... Got to check whether it helps ... Still have to write a wrapper to firefox launcher that would ulimit its consumption of virtual memory (did check it is effective).

(Maybe having a look at https://fedoraproject.org/wiki/Changes/EnableSystemdOomd could be useful, although it is for fedora installs) 

Spotting systemd_oomd running on my ubuntu (virtual) machine ...  

Je suis un n00b

J'ai découvert la guilde  NOOB de Fabien Fournier via twitter lors de l'appel à participer à leur levée de fonds pour créer un jeu vidéo. En soi un évènement assez banal, sauf que cette fois, les personnages du jeu étaient déjà connus depuis 6 saisons par les spectateurs de la Websérie - un concept qui, lui aussi, m'était inconnu. Intrigué, je lance l'intégrale de la saison 1, je regarde le présentation de Gaea qui crée son perso  avant de me souvenir que j'ai Une intervention prévue en salle des machines.

Quand je remonte, ma fée m'a chipé ma chaise de bureau et est en train de rigoler devant le Jack Céparou. c'est la période où on vient de changer de box, et le nouveau modèle permet de regarder des vidéos Youtube sur la télé. La guilde va donc se faire sa petite place au chaud dans nos soirées entre les Dr. Who et les épisodes de Castle. L'humour, la parodie et le second degré vont permettre de proposer un divertissement très réussi malgré un budget d'amateurs et les personnages bien croustillants, au juste équilibre entre réalisme et caricature nous auront définitivement convaincus.

Soyons clair: le jeu d'acteur de Gaëa, Omega Zell, Arthéon et Sparadrap est excellent. Le truc, c'est qu'ils n'ont pas à être crédible en tant qu'invocatrice ou assassin. Ils sont crédibles en tant que geeks qui incarnent des personnages. Et ça, ils le font superbement bien. Pareil pour les inévitables combats. Quand un JDG nous sort un épisode dans lequel il est supposé être CanardMan mais qu'il se bat plutôt comme léguman ... bin ... c'est mignon puis c'est tout.

Ici, plutôt que d'essayer de faire des combats de dingues à la Seigneur des Anneaux, la série joue sur le fait que c'est un combat dans un jeu vidéo. Oui, les coups sont ridiculement mous par moment et on tape dans le vide à d'autre, ce qui compte ce n'est pas le réalisme avec lequel l'acteur combat mais le petit '-200PV' (ou parfois '-2PV') qui accompagne pour nous envoyer un 'bin oui, on est dans un jeu! t'avais oublié?'

Quand ma fée est revenue de la bibliothèque avec le roman "La pierre des Âges (saison 1.5)", je savais déjà bien qu'il y avaient des 'produits-dérivés' de l'univers de Noob. Mais j'avoue qu'entre le graphisme pas franchement à mon goût de la BD, l'idée euh-ouais? de Néogicia et le fait que je ne suis pas un joueur de mmeuporgs, je ne m'étais pas précipité pour acheter les romans. Bin j'aurais peut-être bien dû. Parce que non, on ne verra pas Sparadrap faire l'andouille ni Omega Zell prendre la pose dans le roman, mais c'est toujours bien la même écriture et les même personnages. Fabien Fournier a réussi à choisir un style équilibré entre la narration classique, les dialogues comme-dans-la-série et les chapitres dans-la-tête-du-perso. Quand je lis les répliques, j'entends les voix de Sparadrap ou d'Arthéon dans ma tête. Je vois les grimaces de Gaëa qui cogite. J'aimerais entendre la voix de Zell, mais n'ayant pas l'acceng, c'est plus difficile.

En plus de ça, le "1.5" un peu troublant au départ prend tout son sens une fois la lecture entamée: chaque saison de la web-série démarre par une introduction en vitesse d'un nouveau contenu dans le jeu-qui-n'existe-pas Horizon. Au risque de voir le spectateur décontenancé par les références au sans-âmes, à la Pierre des âges, un nouveau continent, une nouvelle faction ou que sais-je encore. Les romans, eux, traitent justement du passage entre ces saisons, sur fond de quêtes-d'investigations, de rumeurs de forums et tutti quanti. Bien trouvé. Bref, j'ai accroché et ma fille a laissé de côté ses re-lectures de Harry Potter pour se plonger dedans (le "bin non les louloups, je ne vais pas vous mettre la saison 3 tant que *deline est occupée à lire le tome 2.5" n'y étant peut-être pas tout à fait étranger)
 

Mechanic*s*

Okay, there may be something I misread in KirbyKid's definition of primary mechanics. The plural form. Nothing prevents the existence of a group of mechanics that together are primary -- that is, essential to the game. Clearly, MOVE/WALK is a primary mechanic in almost every game that feature an avatar. It's so common, that it can be thought as granted by default, and arguably, few people will complain if it's ommitted from an analysis.

But some sub-genre feature a set of additional ex-aequo mechanics -- JUMP + SHOOT in Mega Man series, for instance -- where removing any of the component makes almost any part of the game impossible to play. This is likely to be true as well in Rayman ...

below is the full discussion, for archive purpose.


That will take me more thoughts to analyze Commander Keen and The Fox again ...

I'd have posted this on "the post on primary mechanic", but I fail to find it, if any. Playing Rayman 1 and Shantae recently opened my eyes on the fact that not all platformers use "JUMP" as the primary mechanic, and that it's actually quite the signature of a Mario game.

On the two games mentioned above, the attack move seems to be the primary mechanic, but I find it hard to apply it to games such as Commander Keen. It looks like some designers just decided to balance the various mechanics they offer to the player so that there isn't *one* action that is the core of the gameplay. In the case of Keen, if I was to pick one keyword to describe the game, that would be "explore", but that's definitely not a mechanic.

I'm curious to know how you consider this example, if you happen to have played the Commander Keen series.

/Pype
March 13, 2012 | Unregistered CommenterPypeBros

If a game's primary mechanic isn't JUMP or a mechanic that manipulates/fights against gravity, then it probably isn't a platformer. It's probably an action game that uses some platforming mechaincs/challenges/elements.

I think I've played Rayman 1 on GBA and I've played the new Shauntae on DSiware. I know that Shauntae has a lot of combat and some puzzles which puts the whole game into the action-adventure category.

I haven't played commander keen, but the youtube video makes it look like it has plenty of exploring, collecting, maybe some puzzle solving, combat, and some platforming. So it wouldn't be a platformer.

I hope that helps. Genres are tricky.

March 13, 2012 | Registered CommenterRichard Terrell (KirbyKid)

Thanks for your reply, Richard. That's one pretty short way to define "platforming genre" as soon as you have a solid definition of "primary mechanics", I must admit. That wouldn't have been my out-of-the-box definition, but it makes sense (and I'm far from being an authority on the subject :)

Thinking more about shantae, it would indeed be an action game with some platforming sequences (where ennemies may be altogether missing and JUMP becomes the button that *must*not*fail*.

It's pretty hard to do the same with the first Rayman. PUNCH may require JUMP to modulate it (a la megaman) and compensate the blind spots, and there is a mixture of platforming and action elements more than a real alternance. As if mechanics were here like abilities of an RPG characters, where some balance is ultimately required. So JUMP isn't what's put as the character-defining move, few power-up / secondary mechanics modulate the way Rayman jumps, except the FLOAT (?) mechanic, using his haircopter.

If I may refer to this picture on my recent post, would you say that the amount of interactions triggered by one mechanic is irrelevant (or not as relevant as I think) in defining it the primary or secondary mechanic ?

Do you think that makes sense to consider that, in some game, the boundary between primary and secondary mechanic may be fuzzy to the point that we have two ex-aequo primary mechanics (as JUMP/PUNCH would be for rayman) ? Or do you rather think I'm looking things at a sub-optimal angle that blurs *my* vision ?

(I'll dig some posts of you about the megaman series ... That may already provide some answers to all these questions).
March 16, 2012 | Unregistered CommenterPypeBros

You're getting at some of the trickiest parts of talking about video game genre. I was planning to write a post about genre but that's a long way off at this point. So I'll discuss the issue here.

1) A Primary Function is what type of action you do most in the game to win or beat the game. Often enough, the thing you do most in a game is a combination of various actions. This is why the genre of "action" is pretty wide spread. If a game has some platforming, some shooting, and some racing, we generally say that the primary function is action (like an action movie).

2) Primary Mechanics are mechanics that are required to beat the game or beat a level (if you're talking about a specific level or group of levels). Talking about primary mechanics is helpful to focus in on the "skill floor" or the set of mechanics and their required use to simply win.

3) Secondary mechanics are any mechanics that are not primary and therefore optional.

So while some examples are clear like Mario and Shauntae, other's are not as clear like Raymand. The truth is, there is no exact way to categorize a genre. In some ways the amount of interactions using primary mechanics. Sometimes we pick genre based on theme and feel rather than function. Sometimes there's a lot of fuzzy overlap. Genres are categories that are supposed to help us understand what the game is, but some games are simply a bunch of elements.

Looking at the required challenges of a game to determine the genre is a great way to go. But this method doesn't cover everything. Between the skill floor and the skill ceiling could be many different types of gameplay experiences that stress different mechanics.

To sum up, while we can accurately label what is a primary and secondary, mechanic, picking the genre of a game can be much more complicated.

March 16, 2012 | Registered CommenterRichard Terrell (KirbyKid)

Thanks. I'll meditate that.
March 20, 2012 | Unregistered CommenterPypeBros

Meditation output: it sounds like I had so far inferred that the "primary" mechanic was by definition a singleton -- likely not being a native speaker have misled me there.

You clearly have mentioned "primary mechanic*s*", so it means your definition is happy with the fact that a small set of mechanics are equally "core-important", right ?

I suppose you thus consider that both JUMP and SHOOT are primary mechanics of Mega Man (oh, and WALK as well, I guess, although it's so natural that it might belong to something like disappeared mechanics, which the player is barely aware of, as they are ubiquitous)

March 21, 2012 | Unregistered CommenterPypeBros

To answer your question, Yes. But since a primary mechanic is defined as a mechanic that is mandatory for advancements/progression through a game or a particular level/challenge, the primary mechanics can be 100% of a game's mechanics. It's not necessarily a small set.

Yes, in MegaMan JUMP and SHOOT and MOVE are all primary because you must do these things in order to beat any level.

In Ikaruga MOVE and SWITCH (polarity) are primary, but surprisingly SHOOT is secondary. You don't have to shoot a single bullet to beat the game.

Good job meditating.

Early DS homebrew moments.

When I started considering doing homebrew on the Nintendo DS, the hardware used by hackers was pretty unconvenient to bring in a sofa. For years, I've kept those pictures around found on website such as http://natrium42.xyz/ or https://www.darkfader.net/ds/, two websites where people pushing the limits of homebrewing were exchanging information and achievements.

But I must admit, I was merely considering doing GBA homebrew on NDS, by then. I wanted to keep things simple. And to some extent, I still want, which is one of the reason why, in 2020, I still haven't started doing homebrew on any other system, unlike most former NDS homebrewers.

There's a much better coverage of the era in Modern Vintage Gamer's video (2019) (reached from Retro Reversing)

The hack on the first picture shows how to extend GBA device with mass storage through a IDE cable and a (portable, enclosed) hard disk. The first devices allowing to run DS homebrew software (not only GBA homebrew) was only half less chunky. To be able to do so, the PassMe device had to relay requests for signed headers to a genuine NDS cart plugged at the rear of the console while it was itself inserted in the slot 1 of the console. That sort of thing works fine on a 16-bit home console, like a game genie / Sonick & Knuckles like monster, but for a handheld, I'd have been constantly fearing to lose a part or break it.

The remaining alternative wasn't very appealing either, as it required you to flash the firmware of the console with one that would have a menu for browsing homebrews on GBA flash cart (iirc) and bypass copyprotection checks.

That involved bridging two testpoints (solder pads) together with a metallic device and keeping them in contact while you're flashing the ROM with new contents (don't remember how). Would you slip during the process, and you might end up with a bricked device that has incomplete firmware. 

Well, it turned out that I eventually started doing NDS homebrews running in emulators before I started doing GBA homebrews and that by the time I decided to purchase something doing GBA homebrew, 'passcard' were small enough to fit a slot 1.

Oh, and by the way, I just discovered someone made a top 5 best homebrew apps last month. When you see that they are youtube 4 DS, Yahoo messenger for DS, an MP3 player and a text editor disguised as WintenDoS, it shouldn't be a surprise why homebrew consumers turned to smartphones as soon as smartphones became cheap enough.

Happy new year, too.

Souldiers Pyramid

Je l'ai découvert à travers une vidéo "Game of the Year", mais dans la catégorie "jeux les plus décevants". Pourtant, Souldiers est carrément superbe. Et principalement réalisé en pixel art. Et enfin, cerise sur le gateau, il propose généreusement une zone du sable avec une pyramide cachée dedans! L'idéal pour aller à la pêche au pixels, en somme, d'autant que même la perspective du jeu est compatible avec ce que je veux faire dans Bilou's Dreamland.

I happily clicked on a "game of the year" video without realising it was mentioning the "most disappointing GOTY". But given how gorgeous the visuals were, I've been shocked that this was actually referred to as disappointing. Souliders is a piece of magic when it comes to pixel art. Plus it has a desert and a pyramid level, so while people are debating about its difficulty, I'll just increase the zoom level and see what I can learn from it.

Bon, malheureusement, un jeu récent sorti sur une machine haute-résolution (il sort des images 1920x1080 où on distingue clairement des sprites et tiles prévus pour du 640xqqch), je n'ai pas beaucoup de screenshots "propres" à me mettre sous la dent. C'est surtout des vidéos youtube qui vont me servir de base.
Premier élément à réfléchir pour Bilou: des toutes grosses pierres comme décor de fond, ça marche finalement mieux que des briques à la MegaMan & Bass ...

It wasn't that easy as I'd have liked, though: the game is running scaled up to 1920x1080 with only some effects/rotations using the increased resolution while sprites and maps are at 640xSomething. Add some touch of JPEG encoding of people's snapshots and you end up with 9 candidate colors per pixel, and little chance to see the same RGB value twice. So my pixelstudy session will be less precise than some earlier pixelstudies ...

On a un élément 'pente ensablée', juste le look qu'il faut pour du sol qui pousse Bilou dans une direction ou l'autre (ce qui n'a pas l'air d'être le cas dans ce jeu-ci). J'aime bien les motif en croissant de lune qu'on retrouve un peu partout dans le sable, que ce soient les paliers dans la pente ou les dunes au sol (petites ou grandes), ça passe nettement mieux que tout ce que j'ai essayé de dessiner jusque là.

Among the interesting items, I note a sandy slope, just the kind I need to implement 'conveyer belts' in Bilou's own pyramid. Note the moon-crescents patterns in the sands. We have such shapes almost everywhere, in background dunes, on the foreground sands etc. but I especially like how they make 'steps' here.

Another item I'm interested in is the sands-within-pyramid. Souldiers features both patches of sands that do not fully cover the ground and 'pools' of sands. Note how they used layers of sands to suggest depth and end up with a solid color rather than texturing the 'side' view of the sands area.

Et on a des zones ensablées dans la pyramide. Et du sable qui traine au sol sans couvrir l'entièreté du sol. Notez au passage la manière dont ces développeurs-ci ont utilisé une teinte nettement plus sombre pour faire "le sable au sol à l'avant plan" qui sert aussi de 'fond de sable' pour l'intérieur de la pyramide.

Allons-y, donc. Un des éléments qui m'intéresse dans tout ça, c'est la taille choisie par l'artiste (un crayon dédicacé à celui qui me trouve son nom/instagram/twitterID) pour les 'vagues' de sable au sol, selon qu'elles sont à l'avant plan, à l'arrière plan ou sur la trajectoire prévue pour le joueur. Verdict: on est avec un modeste 8 pixels de haut que ce soit sur le chemin ou à l'arrière plan, et seuls les dunettes à l'avant plan vont pouvoir se permettre de monter à 12 ou 16 pixels de haut. Les plus hautes sont principalement devant des structures en rocher, d'ailleurs.

 

Chose remarquable, par contre, un "dune au sol" (ici le modèle 64x16 de l'image ci-dessous) n'utilise au final que 4 teintes en plus du ton de base "sable sombre" utilisé pour le remplissage quand des espaces sans détails. Les pentes avant et arrière de la mini-dune sont linéaires (sauf au sommet) et utilisent le même angle par rapport à l'horizontale (contrairement à ce que mon croquis suggère ^^")

It took me some time before I could actually start and study those sand grounds, but a first item I could directly check on the raw picture: what sizes the artist has picked for those waves. I have noted that Souldier's main character is about 40-48 pixels high (roughly the size of pendats). The biggest dunes are 64x16, but that's only seen out of the character's path, as foreground element, but always put under the ground line so that it doesn't obscure the view. On the ground line, we only see 8-pixel high dunes.

I spot only 4 colours per dune, plus one extra 'darkest' tone that is also used as a filler. Of course dunes on another layer will use a lighter set of 4 colours. Another unexpected thing is that the slopes on each side of the wave is are almost linear (except at the top) and fairly symmetric (unlike what I drawn ^^").

There's so much more I could talk about. Those rock strucures, the bigger dunes in the background, the fallen statues... But there's not a chance I could use so much things in "Bilou's Dreamland" project ... so that will be for much, much later ;-)

Il y aurait largement de quoi étudier ces structures rocheuses, les dunes à l'arrière plan et les monstres, mais bon ... je n'aurai pas le luxe de tenter tout ça pour le jeu en cours: juste l'intérieur de la pyramide, ce sera déjà un bon début. Gardons donc ça sous le coude pour un prochain jeu ?

Niveau couleurs, j'ai fait quelques petits essais de superposition des morceaux de sable de souldiers dans la pyramide de Bilou ... c'est pas la grande joie. Les couleurs de prowler passeront probablement mieux. à vérifier.