BBL to .png converter

J'avais pris l'habitude de faire un p'tit cadeau sur Internet pour mon anniversaire, et là, pour mes 30 ans, schnol. Avec les travaux dans la maison et le retour de Suisse, je n'avais rien à montrer. Quelle idée saugrenue m'a pris ce midi? Aucune idée. Mais je vous offre un petit script de conversion des fichiers graphiques du Recreational Game Maker (.BBL, .CBL et .MBL) vers des .png, plus pratiques à manipuler. download bbl2png.pl exemple d'utilisation :

perl ~/DS/SEDS/runme/bbl2png.pl /tmp/TOYZONE2.PAL /tmp/%.MBL m%.png --sprites

Here comes some pixels dump of sprites i've been working on in '97, at the peak of my RSD Game-Maker years. Each level had its very own tileset and spriteset (though there might be much shared things between two levels in the same "zone"). Behold Badman III, most likely the more complex (and unfinished) project with the RSD-GM ever. I finally managed to write a small ".BBL->.png" conversion script, meaning that i can retrieve *all* the graphics from all our previous games. 

Ca veut donc dire que je peux récupérer tous les graphismes de Badman et autres pour vous les montrer... Je doute qu'il y ait grand-chose à en tirer à part de la nostalgie ... j'ai tant appris en matière de pixel art, que même mes "plus jolis" boss sont tartes "by today's standards" :P En vrac, donc voici quelques sprites tels qu'ils sont présents dans la démo jouable Badman 3 (Badboyz are Back!). On y découvre "Ratman", d'après un T-shirt de T-Bob, qui ne sera finalement pas repris comme boss de la Cheese Zone. Juste après, Burner "relooké" qui laisse derrière lui une trainée de feu quand il court, avec un shading un peu douteux. Enfin, le gris aux oreilles rondes, c'est le "ratman" tel que vous pouvez l'affronter, avec son astro-flasheur "kirsch" et ces attaques de roues de gruyère.  

In "Badman III: Badboyz are Back", you can play either with Badman or Rubishbin (who you saved in "Badman II: Out of This World") in three insane environments: the Cheese zone, the Toy zone and the Ice zone. Each character had unique abilities giving them access to hidden areas. Rubishbinn, for instance, can do a spin-jump that destroy some blocks below him while Badman can dash under low roofs. I also reused the technique developed in Badman II for creating shooting bosses. The result was near to an unmanageable nightmare that turned short as I entered university: with only 5 playable levels, Badman III games already lists 44 'levels' in the game editor. 

Ce serait à refaire, je prendrais le "ratman" initial comme PNJ genre "Je suis le seul maître légitime de la Lune Fromagère, et je délivrerai mon monde de la tyrannie des BadBoyz ... Enfin, si tu veux m'acheter des grenades Petit-Suisses ou des Camemberts lacrymogène, ... " Et oui, le volet 3 de Badman était franchement inspiré de la mécanique de jeu de Megaman ... Suit l'Ice Zone, dont les monstres sont pas mal inspirés du niveau des glaces de Prehistorik II (auquel je rejouais cet été-là -- juillet '97 selon le .zip -- en version complète). 

On y retrouve donc un le fameux pingouin et un eskimo dont je n'étais pas peu fier à l'époque et un "lemmings xmas" qui était là juste pour le fun. Ce genre d'apparition était d'ailleurs assez habituel dans la série des Badman : le bonhomme-promo de Belgacom, Moktar sur son tapis volant, une bestiole rampante "façon Commander Keen", des p'tits robots tout ronds "façon twinbee land", une souris bleue mécanique "à la sauce Alfred Chicken", etc. Vous remarquerez aussi "Rex", le chat (private joke) utilisé dans des "cut-scenes" façon "Kirby's dreamland". Le mamhout vous paraît bizarre ? logique. 

Le game maker de Recreational Software ne supporte qu'une seule taille pour les monstres: 20x20. Un monstre plus gros est indestructible par nature et construit à l'aide de plusieurs monstres que vous tentez de déplacer de manière synchronisée ... ce qui se traduisait généralement par un désastre complet. Allez, je vous mets aussi Badman "himself" et son compagnon d'aventures "Rubish bin" ... On est plus très loin d'un extracteur de niveaux complets, avec les autres infos dont je dispose déjà 

PS : mon frère possède aussi une mine de petits "trivias" sur le développement des épisodes de Badman, qu'il reconstitue a partir des commentaires de ses .S3M ... Si vous êtes fan, bonne lecture.

ça descentote ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guest Book -- Livre d'Or

Lecteur d'un jour, lecteur assidu, Internaute occasionnel perdu

Si vous souhaitez laisser un petit message genre "courrier des lecteurs" qui ne se rapporte pas à un post particulier, cet espace est à vous.

Casual reader or #1 fan,
and you too, lost on the Internet

If you'd like to give a feedback on your reading experience of this blog's content, but don't want to comment on a specific post, this space is yours.

This page is also my treasure box, where i'll come and seek for motivation if i ever need some. More than money, you can donate motivation by just posting your comment here !

Cette page est en quelques sortes ma "boîte au trésor", où je puiserai un peu de motivation les jours de blues. Je n'ai pas encore de système de "donation d'argent pour le projet Bilou", ni d'utilité pour un tel système, mais vous pouvez donner de la motivation en laissant votre commentaire ici ;)

 edit: pour les 10 ans de mon premier jeu homebrew, et vu l'évolution de l'accès à Internet (sans clavier. Pauvres de vous), j'avais mis en marche un petit poll. 

 

Qwak!

C'est l'histoire d'un drôle de petit canard qui me fait de l'oeil depuis un moment ... Qwak! Un jeu d'arcade un peu genre "bubble bobble" qui a une histoire pas vraiment ordinaire.

Un vieux vieux jeu, en fait, développé sur un micro 8 bit en 1989 -- eh non. Pas sur C64 mais sur BBC micro, Angleterre oblige ^_^. Au fil du temps, le canard s'est fait relifter avec notamment une version Amiga à laquelle on doit les graphismes actuels (qui me rappellent franchement le look de James Pond). Avec le soutient de Team'17, quand-même!

This is the story of an unexpected duck. Qwak feels like an arcade game in the veins of Bubble Bobble, but it did not start in Japan. Instead, it kickstarted in 1989 on BBC 8-bit computer (logical consequence of being by someone in the UK).

What is notable, is that Jamie kept the little game alive, doing an Amiga reboot produced by Team17 (and visuals that were on par with James Pond titles at least), and even more surprising, a GBA homebrew port. Quite surprisingly, he also managed to get a chinese factory producing 300 cartridges with his own title, and selling them on his website. I'm not that much into international shipping, but I had to check. Maybe one day, Bilou might follow the same track.

En 2006, Jamie nous propose sur www.qwak.co.uk une version GBA. Décision peu courante, il s'est arrangé avec une fabrique chinoise pour recevoir 300 cartouches de son jeu (ben oui. On faisait bien des Supercards ... pourquoi pas mettre son petit jeu à soi sur ce support, du coup ?). J'ai donc décidé de risquer 15£ pour un achat par correspondance, un prix que je trouve tout à fait honnête pour un p'tit jeu sympa de ce genre, et une initiative qui m'ouvre des horizons pour Bilou (si j'arrive à une version vendable un jour).

Voilà, donc. Après quelques petits mails perdus, Qwak, lui, est bien arrivé dans ma boîte aux lettres, mais j'ai à peine pu vérifier qu'il fonctionnait bien que ma fée me l'a confisqué ... cadeau d'anniversaire. Je vous dirais mes impressions plus tard, donc.

Chenillard

En faisant des fouilles dans les archives de la green zone (que je vous présenterais bientôt), je me rends compte qu'un des monstres qui revient le plus souvent est en réalité le seul monstre qui n'a jamais été retenu : le chenilleur. Je lui préféré, dans la version BASIC, le "petit ver jaune", maintenant connu sous le nom de "woodworm".

En allant chercher mon sandwich hier midi, j'ai essayé d'imagine ce que pourrait bien donner le "chenilleur" en 2009, sans faire un repompage trop ostensible sur wiggler de super Mario World (qui pourtant doit être à l'origine du personnage).

Mais évidemment, ça ne m'intéresse pas vraiment de juste rajouter un monstre dont le comportement ne serait pas différent des petits vers. La seule doc que j'ai dit "chenilleur : vulnérable ; petit ver : comme chenilleur, mais invincible au default power". En clair, si vous essayiez de sauter sur le petit ver de terre jaune, le monstre apparamment le plus innofensif du jeu, bardaf, vous perdiez un point de vie 0_o". Une référence de plus au Commander Keen, mais que je trouve franchement gênante au niveau du gameplay.

Tentative de changer la donne, donc. Je voudrais faire du chenilleur une chose qu'il vaut mieux éviter et pour laquelle il faudra ruser pour en venir à bout.

Tout d'abord (coup classique), seul un des éléments sera sensible à vos attaques. Mettons la queue. Si on saute sur sa tête, je reprend le coup de SMW: il se fâche, devient tout rouge et vous avez intérêt à prendre le large. De plus, ses ornements dorsaux devraient vous décourager de tenter un rodéo pour aller jusqu'à son point faible.

Facile, me direz-vous ? "Il suffit d'attendre qu'il ait fait demi-tour". Bin pas vraiment, parce qu'à l'instar de Robo Red (Commander Keen 5), j'ai l'intention de lui permettre "d'entendre" Bilou: si vous atterissez alors qu'il vous tourne le dos, le chenilleur se redresse pour vous faire face: c'est loupé.

World Collisions

Left alone, testpoinst are not really a satisfactory way to handle collisions between objects of a game and the world.
First they don't cover enough and cannot catch all the odd situations. Testpoints are points and they cannot detect the case where you're jumping through a corner unless you have many of them (up to one per tile your character covers).

Je ne suis plus trop emballé par les tests-points tels que je les avait décrit précédemment. En premier, ils ne capturent suffisamment toutes les collisions. A moins de les multiplier, on risque toujours d'avoir une partie du personnage qui rentre dans un coin de mur lors d'un mouvement, et en donnant à chaque état sa propre liste de testpoints, on ne fait qu'augmenter les possibilités de bugs.

Second, they are only boolean. They don't let you express that a fish can only move into water, that a bird can only move in air, and that a frog can move through both, but that only the ghost can also move through walls (and i'm sure we can come up with a negative space creature that can only walk through/over walls). This is a situation much more common that one could think. As soon as you add ladders to your levels, you want to express that climbing the ladder "is only possible over ladders tiles". That was a quite strong restriction of Recreational Game Maker where the only way you could create a ladder for a platformer game was to set gravity=0 on ladder tiles ... As a result, your character zooms through ladders if you press the 'jump' key and miserably 'fail to climb up the air' if you press the 'upwards' when he's not over a ladder.

Le deuxième souci avec les test-points, c'est qu'ils sont simplement binaires. Alumés ou éteints. Point barre. Pas moyen de préciser qu'un poisson ne peut se déplacer que dans l'eau ou qu'un oiseau ne peut aller que dans l'air, mais que la grenouille peut évoluer dans les deux milieux. Si on y réfléchit bien, ce genre de situation apparaît bien plus souvent qu'on ne pourrait le penser. Le simple ajout d'échelles dans nos niveau oblige de définir que "escalader une échelle" ne peut s'envisager que s'il y a une échelle à escalader. Le Recreational Game Maker sur lequel j'ai développé (entre-autres) la série des badman ne permettait pas ce genre de subtilité: une échelle était tout simplement un bloc sans gravité, de sorte que l'on pouvait y monter en sautant -- à une vitesse franchement irréaliste -- et on aurait vu le personnage ridiculement patauger dans l'air en faisant de petits bonds si on avait appuyé sur la touche "monter à l'échelle" alors qu'il n'y avait aucune échelle.

The approach of "the nature of a tile" is thus interesting: it can express (through flags) who can do what over that tile. This is a concept used both in Xargon and (afaik) in the side-scrolling Rayman game, where you have "monster-walls" that monsters can't cross (though Rayman don't feel them). This is imho an elegant solution to many level design problems. Let's take the walking block of "Inside the Machine", who wanders around its initial location, "guarding" a virtual spot even if it could theoretically walk further. Morukutsu relied on a "distance" counter that is increased/decreased through the animation code, which won't let you alter the 'coverage area' of the ennemy through level design, but only through implementation ... not so fun.

L'approche "nature du tile", telle qu'elle est utilisée dans Xargon est intéressante à plus d'un titre, et je soupçonne les concepteurs de Rayman (la version 2D) d'avoir suivi une approche similaire. En particulier, elle permet l'introduction de "grillage à monstres", des blocs invisibles et non-bloquant pour le personnage et les projectiles, mais qui sont assimilés à un mur par certaines plates-formes mobiles et par certains monstres. Comme je l'avais déjà précisé lors de l'analyse des maps de Commander Keen 5, je trouve que c'est une technique élégante pour construire les niveaux. Si je compare à "Inside the Machine" (l'autre jeu dont j'ai étudié les sources pendant mes longues soirées d'hiver en Suisse), l'alternative consiste à programmer les monstres de sorte qu'ils ne s'éloignent jamais de plus de n pixels de leur position initiale, en maintenant une variable supplémentaire "distance" qui les force à faire demi-tour. C'est exactement le genre de "pré-câblage de code" que je cherche à éviter. Décider jusqu'où un monstre va, c'est une question de level design, pas de programmation du comportement des monstres.

The final argument is that some testpoints are typically more important than others, and there is a strong relationship between which testpoint is triggered and which movements you can do. A problem i have with the current implementation of collisions in Bilou is that as soon as one of the testpoint checks fails, the whole move is cancelled. If you fall along a wall, you don't expect your character to "stick" on the wall because you keep pressing the D-pad in the wall's direction. Yet, that's exactly what Bilou does right now.
Instead, we'd like something like

if cando(dx,dy) then (x,y) := (x+dx,y+dy)
elsif cando(0,dy) then (x,y) := (x,y+dy)
else { 
  (x,y) := (x,align_on_tile(y+dy)); 
  trigger_testfail_event 
}

where cando(deltax, deltay) checks the whole area covered by the character at a new temptative location. But still, you don't want such behaviour for all your monsters, and it's certainly something that is specific to jumping. You wouldn't see this ever in a Zelda game : instead you'd have the character "walk around" a block if he's sufficiently near to the edge of that block. So this logic is really controller-related rather than being something that belongs to the game engine itself.

So, do we still need any testpoint ? after all, Xargon's cando() used in controller-specific code seems to be fine. Actually, there's something that cando() cannot catch: mixed situations. The controller will be able to tell the game engine that it's no longer possible to fall, but it can't tell whether we are now landing, diving, or bouncing against a corner. This is where we *really* need test-points, and you'll notice that testpoints are only used for state transitions.

I still have to figure out the best way to convert my codebase to this new approach -- the fact that i'm busy working on the real-world house not really helping -- but i think it might be what i've been looking for since the start of the project.

Enfin, certains testpoints sont clairement plus important que d'autres, et le déplacement indiqué par le contrôleur doit être ajusté en fonction de la situation. J'ai le problème dans le saut de Bilou, actuellement: quelque soit le testpoint qui détecte une collision, le mouvement complet est annulé. Résultat, si Bilou rentre dans un mur lors d'un saut, il va rester "collé" au mur jusqu'à ce que je relâche la touche de direction. Celà n'arriverait pas si je pouvais donner une priorité, ou une description plus complète du rôle des différents testpoints (p.ex. puisque c'est un test-point "mur", il n'annulerait que le déplacement horizontal, etc.)
Mais en fait, ce genre de logique est commune à tous les déplacements guidés par la gravité dans un jeu de plate-forme. Ce n'est pas quelque-chose de spécifique au comportement de Bilou, et celà pourrait sans difficultés être introduit dans le contrôleur du sprite. En tout cas, ce n'est clairement pas à introduire dans la classe GameObject elle-même, puisque si on veut faire un r-type, un boulder-dash ou un zelda, on en aura pas besoin.

Mais alors, à quoi servent encore nos test-points ? eh bien, à décider de quel sera le prochain état lorsque le contrôleur signale qu'il n'est pas possible de continuer. Ca veut dire aussi que le contrôleur devra évidemment ajuster la position du sprite de manière à respecter les "cando()" mais pour que les testpoints puissent détecter quelque-chose quand-même :P

• [done] extract persistent state (found in map and accessible by other classes)
• [done] iGobPubstate::cando(x,y,flags)
• [done] manipulate tile_flags array (that translate tile type into tile flags) from the script
• [done] controllers report "fail" when no "cando()" can be applied
• [done] who updates coordinates ?
• [done] update GameObject::play() and trymove()
  

2024 #choice reality check: cando is still there. it has allowed slopes, jump-throughs and more. And I finally have proof that it also works with levels featuring water. Pfew!

Revamping the green zone

moui ... voilà donc un aperçu de cette fameuse "nouvelle map" que je bricole pour l'instant histoire de tester mes nouveaux graphismes de forêt (encore loin d'être parfaits, hein), avec, marqué en rouge, les endroits où il me manque des blocs de transition pour les coins, etc.

Notez aussi qu'il va falloir que j'aille un peu corriger mon éditeur de niveau qui m'a laissé éditer une cave profonde alors que je sortais en réalité des limites de la map, d'où ces étranges blocs flottants dans l'arbre de droite.

Il me manque des branches, un décor de feuillage "valable" par-dessus lequel je pourrais venir rajouter mes plates-formes feuillues, etc.

A quick sample of the current tileset for the green zone, which is used for testing new collision/behaviours atm. i'm still missing many transition tiles (hunt for red circles) and

TODO:

• [leds-done] ignore extra sheets in the level editor (rather than just showing empty sheets)
• [leds-done] a 'swap layer' tool that moves existing tiles to the other (bg/fg) layer
• [seds-done] RGB shown as 00..FF rather than 00..31
• [seds-done] S and V shown as 0..100 and not 0..255
• [seds-done] capture all the colors used on a page and clone them (to allow palette manipulations), updating tiles of that page to the new colors.
• [leds-wish] copy/paste/clear whole areas
• [leds-done] don't let me edit out of the valid map area