Unity Pixels

Cyangmou posted again a picture that reminds me of why I wasn't appealed by Unity development (before Unity started acting crazy with its Terms of Use): how to set up unity camera for pixel art

- pick orthographic lens size

- compute lens size = desired pixel resolution height / (2* pixels per unit)

- there are by default 100 PPU, but you can tweak that to another value to support 32x32 or 16x16 blocks rather than blocks of 100x100 pixels.

Oh. Of course that was before Unity lost everyone's confidence in the indie game scene by announcing developers would have to pay a fee per deployment of their game while many indie developers built their business model on the fact that unity license was free and thus game themselves could be cheap enough so that people would actually try them. There's not a chance I get into Unity today, not even when I know that some studios would have an easier time publishing my game on the Switch if it was made with Unity.

Neocities

Pendant des années, j'ai eu un site présentant mon projet d'OS et mon activité sur la démoscène... et quelques-uns des jeux qu'on avait réalisés avec des amis. Le point commun entre eux, c'était le nom de l'équipe: "PPP Team (Software)". Il a migré de mon compte étudiant à mon compte de chercheur, puis il a fini par disparaître corps <body> z'et bien quand j'ai quitté l'unif.

Dommage parce qu'il n'y a plus rien pour parler de notre passage sur la Inscene ou des concepts originels du Clicker32 sans lui.

Mais entre deux tweet, j'entends parler d'un nouveau service d'hébergement orienté "bon vieil HTML", sans lourderie en php: neocities. Vu que mon premier hébergeur était geocities, ça fait mouche, bien sûr.

Je transfère donc mes derniers backups sur  https://pppteam.neocities.org/ pour voir ce que ça donne ...

Somebody on twitter mentioned neocities ... Since I have old (pre-php) web contents that has turned unavailable lately, I decided to re-upload it on brand new https://pppteam.neocities.org/ ... So you can visit my old demoscene archives and operating system development manifesto and I don't have to wonder how I could convert that into wordpress

bin ça donne plutôt sympa ^_^

Qui est volontaire ?

Je voudrais pouvoir faire une série "tutorielle" pour introduire progressivement les concepts de mon moteur de jeu et fournir une base de travail à d'éventuels game-makers amateurs qui voudraient s'essayer sur DS. Je voudrais aussi qu'ils puissent avoir quelques graphismes de référence, y compris les personnages.

ç'aurait pu être la bestiole de Pipemare (RSD), mais j'ai du mal à me l'approprier. ça ne peut pas être Jack Boost, Badman, Spector, parce qu'ils ne m'appartiennent pas en tant que personnage. Je n'ai pas envie que ce soit Bouli ou Biokid parce que j'y suis trop attaché, alors qui ?

For ten years now, I've been developing a game engine for the Nintendo DS. It isn't perfect but it already allows to do interesting things. And while most of the homebrew we've seen in the golden era of NDS development were using static screen, with GEDS, we have the full power of large maps and parallax scrolling.

Yet so far, I have failed to offer a workable starter kit for the libgeds and dsgametools. Apple Assault source code is mostly obsolete. Discovery packs for LEDS and AnimEDS weren't really helping to kick into game development. And my tilesets are too complicated for a 8-years-old to start sketching levels.

I'd like to take some time to craft something better. A small tileset inspired by Kenneth Fejer mockups. A generic-enough-but-yet-inspiring character that could be sent onto a Commander Keen / Nicky Boom-like adventure.

J'ai envisagé de commencer par un exemple basé sur Out'm'Up, SeaFox ou Crazy Brix, mais aucun n'est vraiment pratique pour montrer ce dont le moteur GEDS est capable (scrolling multi-niveaux, animation modulaire, etc). Non, il me faut une aventure à la Nicky Boom ou Commander Keen.

Reste les personnages secondaires que j'ai développés. Nono le gamin malchanceux (une version anonymisée de Badman, en sorte), Mo le sorcier maladroit, Mol la taupe punk ou Mike Boost, le talentueux mais ténébreux. Ou alors affubler spector d'une tête de souris ?

Rien de complètement convaincant. Reste la possibilité de faire des pixels sur mesure. Voici donc "power kid", qui a l'avantage d'être un perso rigolo.

Of course, given the amount of games I have contributed to together with other PPP Team members, it may sound weird that I'm on a quest for a character to drop to the public domain. The thing is, most of them were designed by other members (Badman, Jack Boost, Biokid) or collectively... or were pastiche of copyrighted characters (Calimero, Xeen, Frogger). My best candidate would be the punk mole I inserted in Badman II and who was playable in my brother's "4 to save Toon Land", althoug -- as you can see from the sketches -- it is definitely not the only option.

Round 2 (P.Y. vs. PypeBros)

Allez, je prends une petite demie-heure pour répertorier les questions et les posts qui me viennent en tête quand j'écoute la deuxième partie de l'interview avec P-Y.

01% - faire le jeu auquel on rêve de jouer ? 00:20 - another world - prince of persia - titus - rayman
15% - priorité au plaisir de créer ? 03:13
        - rpg essentialiste
30% - l'évolution dans le rpg ? 06:20 - (mario rpg) (modding/remake de keen)
40% - juste un niveau ? construct 2 ? 08:20 - (badman2/3) - quel je choisir ?
50% - les jeux homebrew (portage/demo/jeu simple-mais-complet) 10:45 - un seul niveau (bilou basic) - l'anniversaire - façon pacman : apple assault
80% - le curseur de difficulté 16:43 - rien que normal - easy-normal-hard dans keen

Somethen, I met a phd student who's interested in understanding why people make video games on their spare time. This is part 2 of 3 of an interview, in French, addressing mostly "are you making for making or making for players" and "how about people that are fine with one-level demos ?".

Et pourquoi pas Construct 2 ?

C'est un aspect qui surprend: non content de faire mon jeu, je fais aussi les outils pour mon jeu, plutôt que d'utiliser un de ces nombreux game-makers disponibles aujourd'hui. Disons par exemple Construct 2.
Je me suis donc un peu documenté et l'outil à l'air de permettre des choses un peu sophistiquées telles que le koopa-troopa, à la fois ennemi et arme contre les ennemis.

Je trouve par contre désagréable que le jeu soit obligatoirement décrit par la succession d'éditions qui ont conduit à sa construction. C'est le problème général des makers type "click-and-play", où il n'y a au final pas moyen d'organiser, réutiliser, décomposer et recomposer un nouveau jeu à partir d'anciens éléments. Il y a bien une représentation texte (xml) de la logique du jeu, mais on reste "verrouillé" par le fabricant de construct, dépositaire des composants de base. Me colletiner un gros composant "Platform" qui fait 'tout ce que le vendeur a jugé bien pour un personnage de jeu de plate-forme' et devoir ruser à partir de là ? bof ... Que le moteur de jeu soit open-source et extensible est donc évidemment une priorité pour moi. Hors de question de retomber dans le travers du Game-Maker RSD dont les jeux se retrouvent interdit de diffusion à plus de 10 exemplaires, ou incapables d'utiliser des musiques originales.

Happy Birthday, SEDS!

2006: first ever SEDS build

C'était il y a 10 ans, déjà. Mes p'tits n'veux étaient plus petits que moi, et pas des grands costauds apprenti-DJs qui râlent parce que "le théorème de Pythagore, ça sert à rien" (faux!). J'en étais aux toutes premières versions de SEDS, mon éditeur de sprites pour la (relativement) nouvelle console de Nintendo: la DS.

J'avoue que j'espérais rassembler une communauté d'enthousiastes utilisateurs autour de ce qui ne sera finalement que "mon éditeur à moi, par moi, que j'utilise, mais vous pouvez vous en servir, hein, si vous voulez". Je ne peux en blâmer personne: en 200x, soit les gens ont appris à se servir des "vrais" programmes de dessins sans avoir besoin d'une petite grille sur écran tactile, soit ils savent où trouver des graphismes "Creative Common" et ça leur va ... soit ils ne s'intéressent pas à tout ça.

Tenez, même le gamin d'en face au barbecue de l'école qui fait aussi des p'tits jeux sur DS va à la chasse au pixel sur Internet plutôt que de s'entrainer au pixel art (il a au max 8 ans) et retouche éventuellement un peu ce qu'il a trouvé avant de l'intégrer dans DsGameMaker.

I started my collection of game tools for DS 10 years ago with some 16x16 grid and a simple "page" system to save/restore/update content. I had dream by then than giving the Internet some tools to intuitively draw pixel art on a handheld system would make the homebrewer community produce more original and nice pixels for their games. By then, they were shamelessly embedding ripped, copyrighted characters even for the most creative one.

It never really took off, and I can't really blame anyone for that: kids doing game making will more easily find creative common art that they can integrate even when targetting the NintendoDS. Pixel artists will likely have grown skills and workflow on their preferred tool that doesn't exist in SEDS. With paypal-powered (?) platforms to sell your pixel art as "assets pack" and guys agreeing to have somewhat generic graphics in their game, the once-mandatory coder + gfx duet of the eighties is no longer a must to make a game.

2016. dsgametools cover almost everything but scripts.

J'espérais que tous mes potes autour de moi (p'tits n'veux, frangin,  vieux'd'la vieille et collègues) sauteraient sur l'occasion pour faire des niveaux comme au bon vieux temps des mercredi après-midi sur RSD Game-Maker. Ça non plus, ça n'aura pas marché. Mon éditeur de niveau reste trop rigide pour le non-initié et les graphismes que j'ai créés demandent des ajustements que les gamins ne prendront pas la peine de faire.

I also had hope that creating a level editor for DS would encourage my relatives (nephews, brother, old-time-friends and co-worker), all enthusiasts about game development in general, to make their own level and I would simply need to integrate what they crafted. It didn't worked either. The map editor never became user-friendly to the point it felt attractive to anybody, I'm afraid.

Et puis il y a le scripting lui-même. Les "machines d'état", cette partie du développement qui -- encore 10 ans après le lancement des "dsgametools" se passe toujours sur le PC. Celle-là est de loin la plus rébarbative. Même si le langage colle assez bien à ce qu'on veut faire, avec ses concepts de zones de collision, d'états, de transitions, d'effets spéciaux, de contrôleurs etc. il est terriblement difficile à apprendre.

but there is *so much* I miss to make it a comfortable development environment for hobbyist gamedev'ers

Je suis sous le charme de l'idée de "Learnable Programming" et de cet environnement de développement idyllique où l'on pourrait voyager dans le temps et dans l'espace d'état d'un bloc de code pour comprendre ce qui se passe, où, pourquoi et comment. J'ai mon "Inspector Widget" qui me permet de suivre d'un peu plus près ce qui se passe du point de vue des "objets/personnages" mobiles du jeu. C'est loin d'être suffisant.

There is one thing left I haven't tackled within those 10 years. The state machines, describing how characters and monsters behave, still require text editing on PC. This is a bit of a pity because a text editor is far from being the most learnable-friendly environment for the task. Collision areas are obfuscated behind numbers, compilation cycles are mandatory to check whether a new move is working or not.

I'd love to have it on the DS too. You would see what the actual objects you manipulate are. You'd be able to track state changes and variable effects with much better integration than with Inspector Widget.

CC tileset by Arachne. (*so* talented girl!)

Je n'ai peut-être pas réalisé à quel point la présence d'Internet a transformé le développement de jeux amateurs, non plus. En 1986, si tu voulais faire un jeu vidéo, il fallait soit que tu sois bon en graphisme et en programmation, soit que tu connaisses un bon graphiste et un bon programmeur (après, il reste à inventer un bon jeu, avec de bonnes idées et à bien doser la difficulté, mais ça, ça n'a pas franchement changé).
En '96, c'était presque la même chose sauf qu'on a pu commencer à remplacer "un bon programmeur" par "quelqu'un qui comprend comment se servir de RSD Game-Maker", à condition de ne pas être trop difficile sur le gameplay espéré.

Maintenant, celui qui aime faire des graphismes "comme dans les jeux" peut juste faire ça et mettre ses graphismes comme des "assets pack" sur un forum. Ou alors, il passe une semaine à apprendre un outil intégré à un moteur de jeu. Celui qui a envie de montrer qu'il programme tellement bien qu'il peut s'attaquer a des jeux n'a pas besoin de connaître quelqu'un qui fait des graphismes, pourvu qu'il connaisse un endroit où le premier a mis ses graphismes.

Rayman Designer

Quelque-part en 1997, Ubisoft sort "Rayman Gold", avec un éditeur de niveau. Curieusement, je passe mon tour. Pas trop envie d'acheter une 2eme fois le jeu que j'ai toujours pour pouvoir avoir l'éditeur de niveau ? Pas trop envie de me contenter de faire des maps dans un univers qui n'est pas le mien et d'en être réduit aux seuls ennemis déjà existant dans le jeu ? J'avoue que je ne saurais plus trop dire.

Years before Mario Maker was Rayman Designer. I never owned it, and it never quite appealed me to play custom maps, although I loved very much the original game. It's a bit hard to say why, but I think it could be reduced to two things.

First, the core gameplay is different, and the player is asked to collect every ting (read "golden coin" if it was a Mario game) to reveal the exit of the level. Okay, I love it when you have something more to do than reaching the exit, but being forced to grab every whatever to complete the level always felt annoying. I already found it lame near 2001 when I played Rayman II and discovered that without collecting all the tings of the games I couldn't access the last levels. But here you have to collect them all *level per level*. Oh, okay, you can select levels freely, but still. And the "colored tings that open gates" felt artificial, even more abstract than typical "keys and locks" and much less integrated than Commander Keen's coloured keys.

Pas de cages dans cet épisode, mais des "tings" de différentes couleurs, pouvant ouvrir des barrières quand on a récolté tous les tings d'une couleur donnée. Du coup, le level design ressemble assez fort à un mélange entre pacman et rayman. Un aspect qui m'a assez refroidi du côté de 2007 quand j'ai découvert tout ça sur wiki.

The second thing .. what would player's level look like. I did some game making myself between 1995 and 1997, and I know people who got granted the super-powers of creating levels tends to build impossible missions that they only can beat (sometimes cheating like being the only ones to know that lava is not quite lava in the 3rd pool and that the player needs to dive there to get access to the end of the level). Checking youtube videos of "Rayman by his fans" proved that this was mostly not the case, but instead aspiring level designers forgot to hint on where the tings are to be found, leaving the player to explore the map again and again everytime some magic happened to make things appear or disappear, and ultimately rely on some flying potion to collect the last tings somewhere in the top of the map where regular platforming just can't let you get them.

Mais j'étais curieux l'autre jour de voir un peu à quoi pouvait ressembler les niveaux intégrés dans l'édition "Rayman Forever" -- niveaux de fans repris sur galette. Sont-ils du même tonneau que les missions impossibles de Mario Maker ?


Pas exactement. Pas ceux que j'ai vu, en tout cas. Par contre, il y a usage abusif de la "potion magique qui te donne des aileuus", présente presque systématiquement, et contrairement aux designers de Ubisoft, qui prenaient soin de guider le joueur vers la suite du niveau une fois qu'on a ramassé le "ting-qui-fait-apparaître-un-pont-quelque-part", on risque ici de devoir ré-explorer tout le niveau chaque fois qu'on entend la petite fanfare qui annonce que quelque-chose a changé. Bof pour moi, donc.

2015, L'année Badman ?

Il y a 20 ans, en Mai 1995, naissait Badman. Un antihéros bien rondouillard masqué parti sauver la coupe du monde contre une intrigue louche. Il y a 5 ans, j'envisageais une version-anniversaire reprenant les 4 niveaux-clés du premier jeu (il y aura en tout deux jeux et une démo de 2 mondes du 3eme opus): les toits de Gettham City, Le manoir hanté, la prison et les cascades japonaises.

20 Years ago, in May '95 was born Badman, a masked, plumpy anti-hero who's the last line of defence to avoid soccer world cup to turn into a mass destruction weapon, although the actual nature of the threat was never very clear. 5 years ago, I was exploring tracks for an anniversary version reusing 4 key levels of the first game (Badman will eventually appear in 2 and a half games): Gettham city rooftops, a haunted mansion, a nazi (?) jail and Japanese waterfalls.

It's clear the former PPP Team would love to play the character again -- and he's likely one of the most popular character PPP Team ever animated -- but what should the game look like ? Ennemies in the first game are fairly limited, partly because we were still discovering the features of RSD Game-Maker. At best, they'll move a few step forward, and then some step backward. Badman's moves are fairly chaotic, and button mashing will often be required to clear some jumps. You can somehow climb along edges, although the engine is unable to let you "grab" them. Trying to produce a gameplay that could let you move along in original maps would be totally incoherent, I'm afraid.

My best offer would be something along the lines of "The Blues Brothers" by Titus. I could also get inspiration of some 2008 sketches where Badman gets more muscular by picking up batteries for his sauna belt. It could be used to create a sort of arcade shooter, somewhere between Bomb Jack and Super Crate Box.

Ça ferait sans doute plaisir à pas mal d'anciens de PPP Team de retrouver le personnage, mais pour quel jeu ? Les personnages du premier opus sont limités par les connaissances limitées du Game Maker de l'époque. 3 pas en avant, 3 pas en arrière ... et c'est tout. Les déplacements sont parfois un peu désordonnés, et il faut souvent bourriner les boutons de saut pour atteindre les plate-formes. On parvient plus ou moins à s'accrocher aux mur, à zig-zagguer dans l'air. Franchement, tenter de reprendre les maps d'origine pour refaire un jeu et tenter de reproduire quelque-chose qui ressemble au gameplay de base, ce serait galère.

Sans faire d'étude approfondie sur des gameplay intéressants avec les ennemis de d'origine, on pourrait imaginer quelque-chose ressemblant à un vieux Titus -- genre Blues Brothers.

Autre possibilité, qui s'inspire d'une petite série de croquis de 2008 où on voit Badman devenir plus dynamique après avoir ramassé une "super batterie mégaflash à placer dans sa ceinture (sauna)" et faire un simple "survival shooter" un peu entre bombjack et Super Crate Box.

edit: plus que quatre points à régler sur "Bilou: Rush to completion" ... peut-être bien que je pourrai faire un peu de Badman cette année, après tout ...

encre ? yeah !

Je ne veux pas me contenter de flaques d'encres immobiles pour la School Zone de Bilou. Je veux pouvoir en profiter pour construire des puzzle autour du principe des vases communiquants. Je veux aussi pouvoir utiliser un seul niveau qui monte pour tout le niveau, histoire de proposer des niveaux à terminer dans un temps limité.

So far the ink is static. Puddles where you shouldn't fall in or some bottom-of-level deathly trap. I want to go beyond that. One of my favourite puzzle elements in Fury of the Furries was involving sand or water level that you raise or lower to transform the level. It re-appears in two of the levels I had envisioned for the School Zone, and it would be the base for both deep-ink-pit and rush-to-completion arcade-games I have in my furnace. Several elements need to be sorted out to get that working, though: rendering, interaction with monsters and implementation of the levels equilibrium mechanics.


Côté implémentation, j'ai écarté l'utilisation d'un plan dédié (je n'en ai plus). Combiner une ligne de sprites pour l'animation de la surface avec un remplissage de l'arrière-plan par des pavés tout noirs pourrait faire l'affaire quand l'encre va toujours vers le haut, mais pour des vases communiquants, qui pourrait "réparer" la map quand l'encre descend ? ... A moins que la map complète en mémoire ne soit jamais dégradée, et que seule sa copie à l'écran ait des pavés noirs. Mais Infinimap n'est pas conçu dans ce sens-là. Des gros sprites partout, ça ne marchera pas bien. Le plus souple, ce serait sans doute de règler ça à coup de polygones.

Rendering still has a few options possible on the DS, but in my current setup, the constraints start to pile up. I cannot have a dedicated BG layer. I don't have any left since I introduced 3D objects, which need their own layer. I might be using 3D polygons when the ink sits "between" the two layers of the playground -- that's for Deep-Ink-Pit and Bilou's Adventure. When the ink rise up through the whole level as in Rush-to-Completion, I'd better use the "window" feature (or possibly a raster interrupt to affect background priorities on the fly). For the animated surface of the ink, sprites are the best I can think of.

Ensuite, il y a les personnages. En remplaçant les codes du bloc d'encre sur la map du niveau d'*deline, j'ai pu faire en sorte qu'un taille-crayon lancé dans l'encre fasse des gouttes. C'est aussi un premier pas pour faire en sorte qu'une éponge qui tombe sur l'encre flotte (enfin, à moins que Bilou ne se tienne dessus assez longtemps).

Spongebops and other monsters might have to interact with the ink. I made a first step with Dumblador getting "killed" when touching the ink and generating droplets. That required to change the tile properties so that monsters can also interact with the ink. Initially, I thought making spongebop floating on contact would require some intermediate "liquid" tile before the interactive "kill-Bilou" blocks, but it turns out that the same interactive block can also trigger state transitions such as fall/float for spongebop. neat.
That's actually very good news. It means I don't *need* the ink to be tiles in order to trigger the floating. A GOB with the appropriate collision mask will transparently produce the very same kind of state transition.

Je pensais au départ ajouter une couche de tiles "flotteurs" par-dessus les tiles qui blessent Bilou, mais le même code "F_INK" peut à la fois se traduire en une transition tombe/coule pour Bilou et tombe/flotte pour l'éponge. En en faisant une collision ordinaire (et pas un type de tile spécifique, ce que je garderais pour l'eau), ça veut dire aussi qu'un GOB qui possède la bonne zone de collision F_INK peut interagir avec les éponges, y compris pour l'encre qui monte et qui descend.

A partir de ce moment-là, je peux commencer à concevoir les réactions "vases communicants". Un objet-déclencheur peut forcer les deux GOB-surface à se mettre en mouvement. On peut aussi les lier l'une à l'autre pour leur permettre de s'équilibrer, avec une variante du contrôleur qui ajuste la distance entre Spongebop et son pivot. Reste un élément délicat: comment faire en sorte que les niveaux d'encre se mettent en mouvement simultanément ? Un coup de sonde à l'aide d'une zone de collision bien calibrée pourrait faire l'affaire (de la taille du bouquin central, par exemple), sauf que les zones de collision sont normalement définies pour un état donné, pas pour un objet donné.

If the part of the ink that's animated is allowed to be a GOB, the use case of ink-level-equilibrium turns closer to something GobScript can readily handle: it mostly comes down to two ink-surface objects that adapt to each other so that they reach the same level, possibly assigning them top speed that depends on the width of the pit they're in. Then, I have to figure out a way to kick them so that they start moving simulatenously (e.g. after Bilou opened some path between the two pits). I could build something inspired from Badman II boss rooms in RSD Game-Maker, with a lock-type block that shoots invisible trigger-sparks moving along the same kind of directional block as those controlling inkjets.

J'ai donc commencé à construire quelque-chose qui fait fort penser aux boss de Badman II: faire en sorte que la serrure génère des "étincelles déclencheuses" (invisibles) vers la gauche et la droite et placer le même genre de blocs-directionnels que ceux qui contrôlent les déplacement des encriers pour faire en sorte que les GOB-étincelles atteignent simultanément les deux surfaces pour les mettre en mouvement.

If that's funny to demonstrate that the a-priori simple engine can handle elaborated things, it would quickly turn into a nightmare for any sophisticated situation, like the twin-corks in Remi's level (where each cork might trigger raising ink from the other's position). You'd end-up crafting chuchu-rocket puzzles on your map and hope the timing you computed in your mind is correct when launching the level. As a second thought, I'd rather have the surface GOBs both attached to the "lock" and start raising when this link is lost. Yet, it would be nice to have test-zones that can be defined through GOB variables so that the level editor can precisely define a trigger region for each of them (but it's unclear I have true *need* for that in any of the level I designed so far).

C'est rigolo un instant, et ça fait plaisir de constater que les abstractions construites jusqu'ici sont suffisament Turing-esque (comprenez, expressives) pour ce genre de déviance. Mais soyons clair: si on veut passer à un niveau un tout petit peu plus élevé -- les bouchons jumeaux du niveau de Rémi, par exemple -- on peut rapidement se retrouver à construire un puzzle à la chu-chu-rocket qui va promettre de sérieuses migraines au moment de la mise au point.

Il y a bien une autre possibilité: quand un Gob (ici, la surface d'encre) est attachée à un autre (la serrure), il reçoit un évènement si le Gob de référence disparaît. On peut alors faire monter le niveau d'encre suite à la disparition du bloc-serrure -- ou du bloc invisible qui s'est fait détruire par le bouchon-qui-s'enfonce. La bonne nouvelle, c'est que l'éditeur de niveau supporte déjà ce genre d'approche. La moins bonne, c'est qu'un Gob ne peut être attaché qu'à un seul autre. On saura donc faire des niveaux avec 2 bouchons, mais pas avec trois. Cela dit, ça mériterait vérification, mais je pense bien que je dois pouvoir m'en sortir avec juste "2 bouchons" dans tous les niveaux dessinés jusqu'ici.

petit computer

Mais, mais ... du neuf sur le DSi Ware ? Heureusement que Digital Tools est là pour me tenir informer. Voilà qui va fameusement plaire à Pierrick : un BASIC sur la DSi: Petit Computer. Avec support des sprites, décors et même de quoi faire des p'tites mélodies. On va même pouvoir s'échanger nos programmes sous la forme de QR-codes (imprimés sur des étiquettes collées sur les floppies des années '80, bien sûr :) Bien vu, SmileBoom ... ça va faire mal ^_^

Voilà qui va faire une sérieuse concurrence à mes p'tits outils homebrew ... mais c'est une joie immense de voir le "homebrew coding" de ma jeunesse enfin compris et approuvé par Big N ... bon, y'a probablement pas de SYS 16384, mais qu'à celà ne tienne ...

Creating and sharing your own BASIC tools and games on the DSi, with only Nintendo-approved software... does that sounds impossible ? check it out for yourself

REALITY CHECK: Amère déception après la mise à jour système: le logiciel n'est pas encore disponible en Europe. Et je suis optimiste sur le "encore"... Il a fallu près d'un an pour que 'Inchworm Animation' traverse l'Atlantique, et on attend toujours Cave Story. La traduction de tous ces textes prend un temps considérable, hein ... M'enfin, quoi, c'est à ce point la fin du monde de faire une catégorie "dans ma langue préférée" ou "dans n'importe quelle langue" en laissant à l'acheteur la possibilité "d'upgrader" dans sa langue une fois le jeu enfin traduit.

Hey, GameBridge and SmileBoom, if you're reading this don't stop after the US: Europe wants Petit Computer! We are the land of the micro-computers! We've been playing on C64 even in the nineties and have dropped our Amigas only when the PlayStation decided the market for micro-computer games should no longer exist. I won't care if translation isn't complete: most of us can understand English anyway, so please, go to your Nintendo representative and ask them how translations could be provided as a downloadable upgrade. Stop reading and go releasing ... just ... please.

Pipemare DS ... in the pipeline.

@Dec 15, 2011 02:24 AM
PypeBros:

Just a thought ... I've released a first version of my Level editor for Nintendo DS. Would you like me to convert some Pipemare tiles & sprite sheets to the expected format so that we can propose Pipemare DS to the grown-up RSD fans ?

G. Andrew Stone:

Yes that would be really cool!

Well, it looks like I had overlooked Andrew's reply. With the level editor crashing on school1.cmd, I need to revise it anyway, so that might be a nice time to provide the sprites/tiles and go through a step-by-step how-to on generation of simple animation / behaviours definition.

"hackers handheld gaming platform"

G. Andrew Stone, author of the RSD Game-Maker has shown up. On his blog, he unveils some nice trivias on Game-Maker development.

Of course, I had to post a comment pointing out my own DS development, since the spirit is very similar to the one of RSD Game-Maker. I had the pleasure to read this reply this morning :

Hi! Great to hear from you and see the RSD Gamemaker helped you find your avocation! I read your posts on the DS and that is a pretty good idea; it would be great to have sort of a hackers handheld gaming platform!

Presque 15 ans plus tard, grâce à Aderack, je peux enfin mettre un nom sur le créateur du Game-Maker qui nous a permis mon frère et moi de laisser parler notre créativité de grands ados: G. Andrew Stone. Sur son blog, Andrew nous donne quelques détails techniques sur la réalisation du logiciel, qui était probablement le premier outil "do it yourself" à offrir tant de flexibilité (le Shoot-em-up Construction Kit de Sensible Software est plus ancien, mais limité à un seul type de jeu et s'apparente du coup d'avantage à un "level editor" avant l'heure).

L'absence de toute technique de protection du contenu (un utilisateur de RSD peut réimporter et modifier les jeux écrits par d'autres) était volontaire et vue comme une sorte de "creative common license" avant l'heure. Le plus étonnant, c'est que cet outil a lui aussi été développé par des jeunes, ne recevant du soutient d'adultes que pour les aspects "distribution, marketting", etc. La version 3.0 est sans doute sortie alors qu'Andrew et son frère étaient en 1ere année de collège (l'équivalent aux States des études supérieures ici).

Pourtant, Andrew n'a pas poussé plus loin le développement de jeu. Il nous parle majoritairement de jobs dans des sociétés en tant qu'informaticien détaché, et bricole des petits projets sur FPGA.

The revenge of ZooL

Pour tous ceux qui n'ont pas eu Windows sur leur premier ordinateur (et qui n'ont pas eu de console SEGA non plus), ZooL est sans doute l'expérience la plus proche d'un Sonic que l'on puisse imaginer... enfin, presque. Et comme mon frère le faisait remarquer, c'est Zool qui a servi de cas d'étude pour un livre qui introduit des concepts tels que les plate-formes tombantes ou mobiles, l'attaque en vrille, en glissade, les monstres smarts ou l'escalade de murs. La plupart de tout celà est présenté dans le chapitre 6 : "Empower strikes back".

Ever thought about fighting in the middle of candies, music instruments or drills ? that's precisely the setup of Zool : Ninja from the Nth dimension. Zool was a stunning, hard and exciting game that kept me busy for weeks when I was a teenager. The closest PC and Amiga guys could get to a Sonic experience. It's coming back to the front of the scene with that Game maker companion book by Jacob et al. I especially dug chapter 6 about attack moves and interaction with moving and crumbling platforms.

Si les éléments présentés m'intéresse, je dois dire que j'ai été un peu déçu par l'approche. Il faudra que je retrouve une copie de Zool pour Amiga pour vérifier ce qui faisait partie des limitations du jeu d'origine et ce qui a été simplifié pour ce livre.

Personnellement, quand je lis que Zool va pouvoir assommer les monstres qui le touchent pendant qu'il tombe, peu importe qu'il les touche du pied ou de la tête ... ou que "celà signifie qu'un ennemi peut être tué lors d'une glissade même s'il touche Zool dans le dos. Mettons ça sur les super-pouvoir d'un ninja trans-dimensionnel", je dois dire que je ne suis pas convaincu.

Of course, unlike the typical target reader for that book, I'm not that interested (sic) in which buttons or dialog boxes I should use in order to activate response to monster collisions, but rather by the backstory, the logic, and some nitty-gritty details that can make things "professionnally right". To that extent, i must admit that I have been disappointed.

The revival of Zool presented in the book apparently solely relies on a pixel-perfect collision detection and trivial boolean flags (attack?=true) to do all the decisions. It is not possible, for instance, to insist on the fact that zool's foot should be in contact with a monster so that the monster can be stomped. If a bee enters Zool's face while he's falling, the bee will be "stomped" as well. Similarly, the author says that the fact that a monster could die on contact of Zool's back while he's sliding could be considered as a "cool ability of a inter-dimensional ninja". That's just a bug, as far as I'm concerned.

Dans mon propre "game engine", ce genre de comportement (la présence de "points faibles" et de "zones qui donnent un coup") était clairement un objectif majeur par rapport à tout ce que j'ai fait ou utilisé précédemment. Ca marche, ça ne coute pas bien lourd (même s'il faudra que je mette à jour l'éditeur de sprite pour que ce soit plus convivial) Après avoir tenté de reconstruire mentalement les interactions en place dans la réalisation des plate-forme à partir des manipulations recommandées, j'ai été aussi un peu déçu.

Et les auteurs ne s'en cachent pas: "il y aura un léger décalage entre le déplacement de Zool et celui des plate-formes. C'est ça ou prendre le risque que les plate-forme mobiles puissent envoyer Zool dans un mur. Donc oui, ils reconstruisent Zool, mais d'une manière qui est entachée par un bon nombre de "limitations d'amateurs" que je croyais avoir disparu depuis une 15aine d'années.

I unfortunately stumbled upon similar "amateurism" when checking the moving / crumbling platforms. Yes, they have something that approaches the desired effect, but either with a _lag_ between Zool and the platform's move, or with a risk that platforms could throw Zool within a wall. Looks like I'll have to hunt for more reference if I want to find an appropriate solution to those platforms problems.

I note, however, that one key technical aspect that supports the examples is that the game maker engine is object-based rather than tile-based. By making a movable platform a subclass of the "obj_ledge", Zool can naturally walk on it, wherever it moves, fall or stay still. That's something that won't be so easy to achieve with my approach.

Small step for me, Giant leap for Badman

I guess this is another instance of "I just can't help", and I can only hope I'm not to blame. As I was working on retrieving more content for Aderack's Wiki, I stumbled upon that previous post where I was listing things that were needed for an anniversary edition of Badman on DS. One of them was "produce .spr files out of extracted BBL files", somehow. Since I was sick last week, I could hardly focus on Apple Assault or any "real" coding, but hacking perl scripts wasn't too hard.

Alors que je tentais d'expliquer à Aderack que "non, je ne cherche pas à porter les jeux Game-Maker sous DS", je me rends compte que le principal obstacle technique à une version anniversaire de Badman -- les tirs -- est maintenant résolu. Alors vu que j'étais trop naze pour réfléchir la semaine dernière, j'en ai profité pour bidouiller du script Perl de-là de-ci histoire de peaufiner la conversion des fichiers .BBL en .SPR. On ne s'emballe pas : ça reste hautement expérimental et artisanal, mais à force d'ajustement, j'ai fini par pouvoir sortir les sprites du jeu dans un setup "un sprite par pavé de 32x32 pixels" mieux adapté à une conversion vers le format SEDS.

The first step was to update bbl2png.pl so that it accepts the --width=32 --height=32 options that are required for inserting padding and --xoffset=6 --yoffset=12 that allow 20x20 sprite positioning within 32x32 frame. Piece of cake.

I had a bit more difficulties with making the resulting image converted into a regular .spr, especially because the tools I used so far were targetted at importing maps, not sprites. A bit more tweaking allowed perl /home/pype/DS/SEDS/runme/imlib2spr.pl badman-cbl.png badman-cbl.spr --blocksize=32 --bgcolor=420042 --nopack --nomap to properly produce the sprite sheets I wished to have, with 10 Game-Maker sprites per sheet ... ready for action :P

Je dis "mieux adapté", mais rien n'était encore joué. Mon bon vieux script "imlib2spr.pl" avait en son temps été conçu pour produire des maps destinées à tester mon scrolling, absolument pas à remplir des pages de sprites avec un nombre réduit de blocs 32x32. Il m'a donc fallu un brin plus de chipotage pour parvenir à refaire un fichier qui soit accepté par l'éditeur, mais ça y est, photo à l'appui !

On verra bien s'il finit par en sortir quelque-chose :P

Aderack" RSD Wiki

Peut-être me connaissiez-vous déjà du temps du Game-Maker et de PPP Team Software. Peut-être m'avez vous maudit après un "Game Over, Man" dans un des Badman. J'ai été contacté il y a quelques semaines par Eric-Jon "Aderack" qui était en quête de renseignements pour remplir son wiki sur les jeux produits sous Game-Maker... Ce qui m'a donné envie de raconter (enfin) ma version de l'aventure RSD -- en Anglais, pour compenser le fait que tous les jeux PPP sont en français.

I have been working on a story page on my Game-Maker years (the RSD Game-Maker, the one on MS-DOS with ugly scrolling and an odd sprite engine, not the Windows one from Yoyo). As you will read through the story, you will encounter a few videos posted by Aderack who is working on a wiki collecting all the RSD games ever produced.

Hope you'll enjoy it.

Bounce & Shoot

Petite tentative de mettre en image les petits essais de ce midi, dans le cadre du mini-jeu "Apple Assault". L'idée est d'avoir une jauge d'attaque que Bilou peut remplir en rebondissant sur des monstres (représenté par les 2 transitions en haut de l'image) et qui lui permet de lancer une étoile (à remplacer par un coup de poing).

Cette jauge n'est toutefois pas permanente: quand Bilou est au sol, elle retombe progressivement à 0, réutilisant le même mécanisme que celui qui fait ralentir les Applemen. Cette "vue synthétique" de toutes les interactions faisant intervenir une variable donnée pourrait bien venir compléter d'autres fenêtres de dialogue plus "classique" (éditer toutes les transitions de / vers un état) dans un éditeur de comportement tournant directement sur la DS ... à venir plus tard.

This week-end has seen virtually no code written for the engine, but massive update and improvement on the "gobscripts" defining Bilou and the Applemen. Bilou now actually 'bounces' when he stuns appelmen, and you can bounce higher by pressing the jump button with the proper timing. In an attempt to get closer to the "apple assault" milestone, I was toying this lunch time with a bounce counter that could be use to enable the "shot of some placeholder" that is meant to become a "finishing move" that would clear the area of stunned (or running) applemen.

Here's a conceptual mockup of how that job would have been done if the "behaviour editor for DS" was already implemented... or at least how you could visually provide hints on what is using that bounce counter by identifying all the predicates and action that use "variable #6". In order to add that behaviour, you'd have to start with the "falling" state, alter "monster found" behaviour, then browse neighbour states and decide what to do with v6 in order to implement the "depleting counter" that only let you "throw a star" shortly after you've hit the ground.

On se refait un Zelda ?

Ils sont nombreux, sur Internet, spriters, game-makers et même programmeurs, fan de tout poils à se lancer dans l'aventure de "mon propre Zelda"... Mystery of Solarus, 3 Shards of Light, Occarina of Time 2D ... La liste est sans doute encore bien plus grande. Et à bien y regarder, hormis le fait que j'utilisais Bilou comme personnage, mon propre projet de RPG était à 90% calqué sur Zelda: Link's Awakening. C'est inévitable: Zelda -quel qu'il soit- est un jeu qui marque et une fois l'aventure terminée, on en veut toujours plus (constat qui s'étend à tous les univers de Fantasy réussis, d'ailleurs). Dommage, d'une certaine manière que toute cette créativité ne soit pas accompagnée de graphismes originaux, mais tout ceux qui se sont essayés à la programmation de jeux savent à quel point il est difficile de trouver une équipe de graphistes qui vous suive dans votre aventure.

Par curiosité, j'ai regardé d'un peu plus prêt le projet "Solarus", dont le moteur "deluxe" est open-source. Codé en C++ avec du Lua pour le scripting -- une approche assez en vogue dernièrement -- il constitue une bonne base de comparaison vis-à-vis de mon propre moteur de jeu. Par exemple

-- Function called when the player wants to talk to a non-playing character.
-- If the NPC is the monkey, then the monkey sound is played and the dialog starts.
function event_npc_dialog(npc_name)

if string.find(npc_name, "monkey") then

if not savegame_get_boolean(24) then
-- monkey first dialog
play_sound("la_monkey")
start_message("outside_world.village.monkey")
else
play_sound("la_monkey")
start_message("outside_world.dungeon_2_entrance.monkey")
end
end
end

trouvé dans map0003.lua, propose une série de fonctions-scripts qui devront être appelées dans des cas précis. event_npc_dialog, par exemple, est d'office appelée par le code C++ lorsque le joueur tente d'interagir (bouton A?) avec une InteractiveEntity de sous-type NON_PLAYING_CHARACTER. Qui l'eut cru, hein ? Il vaut donc mieux que cette fonction soit définie si vous avez quoi que ce soit dans le fichier .map qui soit interactif. Un fichier complémentaire (map0003.dat), généré par un éditeur graphique, fixe les coordonnées des différents NPC en donnant, ici via la chaîne "monkey", le nom du personnage qui sera passé en argument à event_npc_dialog.


Il y a donc toute une série d'action-clé, véritables "point d'ancrage" dans le code C++ pour définir les interactions qui régissent les donjons et les énigmes d'un zelda. event_hero_on_sensor, event_switch_enabled, event_message_sequence_finished, etc. Dans l'autre sens, le script va essentiellement faire des appels à des fonctions C++, auxquelles on aura assigné un "nom Lua". P.ex.

lua_register(context, "play_sound", l_play_sound);

int MapScript::l_play_sound(lua_State *l) {

MapScript *script;
called_by_script(l, 1, &script);
const SoundId &sound_id = lua_tostring(l, 1);

script->game->play_sound(sound_id);

return 0;
}

Les chaînes de texte constituent un élément essentiel de tout ce système, identifiant systématiquement les entités. Pour un Zelda (où le temps de réaction des NPC n'est pas critique pour le jeu) sur PC (avec 1GHz facilement), ce n'est pas un soucis. Sur console portable, l'issue d'une telle approche est incertaine. Au passage, Lua prend en charge lui-même les constructions telles que if-then, les manipulations de chaîne et les expressions numériques. Ouf.

A noter que la "logique" d'une séquence se retrouve forcément éparpillée entre "parler au NPC", "fin de dialogue", , "fin de mouvement du NPC", "item ramassé", etc. Et également mélangées avec les interactions des autres personnages présents sur la même map. On peut s'en sortir, bien sûr, mais de là à dire que le modèle de programmation est transparent, je ne m'y risquerais pas. C'est une tournure d'esprit à prendre, probablement assez proche de la programmation d'interfaces graphiques sous winwin.

-- Function called when the monkey has finished jumping
function event_npc_movement_finished(npc_name)

if monkey_jumps == 1 then
-- first jump finished: wait a little amount of time before jumping again
start_timer(300, "monkey_timer", false)
elseif monkey_jumps == 2 then
-- second jump finished: start the last jump
play_sound("la_monkey")
npc_jump("monkey", 1, 64, false)
monkey_jumps = 3
else
-- last jump finished: remove the monkey from the map and unfreeze the hero
npc_remove("monkey")
unfreeze()
end
end

Si je n'en suis pas encore au stade où je peux proposer une alternative en "GOBscript Bilou" à un comportement de ce genre, je voudrais le contre-balancer avec le système des "gendoors/killdoors" de rayman designer. Une série d'objet dans le jeu peuvent être reliés à un "compteur" (représenté par le magicien) de sorte que lorsqu'un d'eux (ou tous, c'est selon) entrent en contact avec Rayman, une autre série d'objets (ici, un bonus et un clown ennemi) sont créés ou détruit. Un bon nombre de "salles-à-énigme" dans les donjons de Zelda peuvent se réduire à ce genre d'interaction. Un simple lien, créé graphiquement entre les objets, a donc suffi ici, là où plusieurs fonctions interviennent dans l'approche "solarus-dx".

Suite au prochain épisode ... il est temps que j'aille mettre ma fée au lit ;)

(Might be) Back again ?

La prison, "retaillée" pour DS

Ok, mettons que je n'essaie pas de faire un programme qui convertisse un jeu Game Maker en un jeu DS tout fait, mais plutôt que je reprenne les graphismes du premier Badman pour m'amuser un peu à faire une "version anniversaire" sur DS, reprennant les meilleurs niveaux, etc.

Première observation, les graphismes étaient tellement simplistes qu'ils passent pratiquement tous à travers une conversion "20x20 -> 16x16" brutale dans The Gimp. Certains (la porte en bois et les caisses) auront besoin d'un petit relifting dans SEDS, d'autres (la grille de la prison) auront tout intérêt à être réimportés de leur version 20x20 et "recollés" sur le fond.

A few more "mapshots" of RSD game-maker games i did in '95. Here comes Badman, an overweight parody of Batman, in a super-zero style. The tools i've crafted so far don't allow straight conversion of any RSD game, but let's try and see how much work a specific port (for instance an "15th anniversary release" of Badman) would require. Let's go. Just convert 2000x2000 map into 1600x1600 map and see what happens...

Le manoir, "retaillé" également à l'exception de Badman

Deuxio, Badman ne fait pas 16x16 mais seules ses "oreilles" et sa cape dépassent du cadre. Au niveau du gameplay, ça ne devrait donc pas choquer de le voir se faufiler dans des passages un peu trop étroits. Les ennemis seront conservés en 20x20 aussi (et prout pour la surconsommation de VRAM), sinon ça ne donne pas

la version d'origine, sur PC

Tertio, si la version PC était limitée, il y a moyen de s'amuser en variant un peu le comportement des ennemis, cette fois-ci. Faire hanter les cuirasses de chevalier par les fantômes du manoir, par exemple. Ou passer l'horrible grille de la prison en parallaxe, etc.

well, a few background tiles will need to be reworked, of course, though in some cases, like the jail's grid, i can just re-import the pixels because they actually don't have per-block granularity.
Clearly, i should better keep sprites 20x20 anyway (if i dedicate per-OAM vram rather than per-frame vram, it should work for every game, and it really doesn't care for Badman 1 which features some 40 frames for all animated objects throughout the game ;)

Retenus pour l'occasion : gettham city, le manoir, la prison et le japon.

et point de vue code:

• extraire les animations des blocs vers du script "GEDS"
• itou pour la position des monstres sur la map (avec un offset et ajustement des coordonnées quand-même)
• un mbl2spr qui ajuste les sprites 20x20 sur du 32x32 (ou éventuellement 24x24 si vous êtes sages.

vgmaps tool for RDS Game-Maker

bbl2map.pl
Et voilà. L'outil ultime : conversion des fichiers .MAP en allant rechercher les animations des monstres dans les .MON. Je suis encore loin d'avoir tout compris aux .mon (déplacement, etc.), mais au moins, j'ai de quoi me faire un joli musée de niveaux de nos jeux RSD Game-Maker. Pour ce qui est de faire une conversion .gam -> .nds, par contre, ce n'est toujours pas gagné. Si la plupart des maps se "compressent" assez bien sur des tiles de 8x8 (pour Badman II, en tous cas), la gestion des animations serait un vrai cauchemar dans un environnement pareil ...

Good news if you used to design games on RSD Game-Maker: i managed to build a fully-featured RSD .MAP reader that lookups .MON files (at least animations) to render a full map of your levels, with monsters depicted... Oh, it could still use the information from .GAM files to show you entry/exit points as well, i admit.

I guess anyone fluent in PERL could reuse the code to write a RSD->XXX converter given that you already know the map format for XXX. Unfortunately, that doesn't really bring me much closer to the "RSD->NDS" conversion/replay tool due to the silly 20x20 block size in .BBL files. Not much of a concern for handling the map (at least, in Badman II, most of the maps use quite few blocks and a plain conversion to 8x8 tiles does the trick), but animating such 20x20 blocks that are split over different tiles would likely turn into a nightmare. And trying to update a bitmap rendering of the level might be tedious (and boring) to implement, not mentioning the limited bandwidth to the screen's backbuffer , that would hit the framerate quite badly..

BBL metadata.

Voilà. Une fois qu'on dispose de tout un jeu de .BBL avec les tileset correspondant, c'est bien plus simple de reconstituer le rôle des 20 bytes de contrôle ... C'est ce que fait de son mieux ce petit outil "bblmeta.pl" que je vous offre également.

Chaque ligne rappelle le numéro du bloc (en hexa) et sa position dans l'image générée par bbl2png (le premier, par exemple, r02 c12 correspond au premier canon, tourné vers la gauche sur la 3eme ligne de l'image). Suit ensuite les "flags" tels que lus dans le fichier .BBL puis l'interprétation de ces flags par le script bblmeta.pl

J'ai repris la technique des répertoires UNIX: un '-' chaque fois qu'il n'y a rien à signaler, une lettre sinon. Ainsi "B--a-K" serait un bloc solide (B) animé qui interagit avec une clé (probablement une porte). "--g-+-" est un bonus qui rapporte uniquement des points, etc. Pour être exhaustif, je dirais que le programme reconnait:

1. Bloc, Floor, Wall ou ciel (-)
2. Pickme : l'objet peut être ramassé pour l'inventaire
3. g, l ou r : gravité normale, vers la gauche ou la droite. Les autres combinaisons ne sont pas reconnues.
4. a : bloc animé,
5. t: réagit au contact
6. bonus/malus : H=hitpoints, x=kills, + : score
7. L = 1UP, K=clé/porte.

En plus de ces "flags", certaines valeurs sont indiquées dans une liste entre parenthèse, comme la succession des blocs pour une animation, le nombre de hitpoints ou de clés, ou de points modifiés lors d'un contact , le numéro du monstre tiré (pour les blocs qui tirent des monstres), etc.

Here comes a second funny PERL script. It extracts meta-data from .BBL (Background BLocks), .CBL (Character BLocks) and .MBL (Monster BLocks) produced by RSD Game-Maker. If you used to write games with that editor, feel free to use that tool to retrieve all meaningful elements and port your old funware to some new platform. If you do so (or just plan to do so), please share the joy and post a comment.

This tool is a kind of "preliminary" reverse-engineering tool. It can tell you roughly what are the properties of individual blocks but detailed information may need to be looked up in the 40-digits hex string. Each line describes a block. Right to left you'll have the following information :

1c (r01 c13): 400100000000000000ffff1b64001c0400010000  --ga-x-  (a1b,100)(h-1)
^    coords   |--- complete hex dump of meta-data ---|  |flags|  |---details--|
+- block number

On the right side, "flags" tell you roughly what are the properties of your block. here you see an Animated block that has downwards Gravity and that hurts the player (x) on contact. Details tell you that it animates to block 1b after 100 ticks and that hitpoints are reduced by 1 on contact. On the left, you have block number (block #x pixels are located at bytes x*420..x*420+399 in xBL file) and the row/column coordinates on the picture generated by my former bbl2png.pl script.
Bref, ce n'est certainement pas aussi souple que l'éditeur du game-maker (et d'ailleurs, ce n'est pas un éditeur, juste un outil d'inspection), mais ça capturera la plus grande partie des cas que l'on retrouve dans un jeu de plates-forme comme les Badman.

Hope it Helps ^_^
PS: 1st byte is the index of the generated monster (0x40 = no monster generated), thus byte 2 is likely the delay between two such generations.