L'encre de Rayman ... et de Bilou

L'encre, c'est noir. Facile. Des vagues pointues plutôt que sinusoïdales. C'est noté. Les "highlights" sont localisés à la surface (logique) et fort étroits. Dernière note: presque pas de teinte dans le highlight. C'est essentiellement du gris, avec une très légère teinte brune (saturation maximale 10%)

Make it black, and make it spiky rather than wavy. Keep the highlight thin, focused at the top, and use almost 'pure' greys for the shading. That's what we can learn from analysing Rayman's ink sea in Picture City. So here's (below) what it produces when I follow those advices. It animates nicely, but maybe a 16 pixels-wide tile was a bit too small 0_o.

Bon, celà dit, je ne dois pas me fier aveuglément au graphisme de Rayman. Quand on lit l'article de Pix'n'Love, on se rend compte que les graphismes étaient essentiellement réalisés avec des techniques classiques de dessin animé, puis "retravaillés" pour le jeu vidéo. Moi, je la joue directement "pixel art" avec moins de couleurs etc. (entre autres parce que je n'ai pas une équipe de 60 personnes avec moi :P)

blocking GOBs

Vous vous souvenez peut-être d'un commentaire de mon frère CJ comme quoi "il faudrait quand-même à un moment donné qu'on puisse avoir des ennemis à travers lesquels on ne passe pas même si Bilou est invincible... une chose que je n'avais pas vraiment prévu de rendre possible dans le moteur de jeu de "Apple Assault": Bilou ne sait pas traverser Funky Funghi simplement parce que dès qu'il le touche, il est blessé et repoussé en arrière. Mais pour les encriers et les plate-formes mobiles, ça risque de causer bien d'autres soucis.

It may look like Bilou can't walk through Funky Funghi in the released demos so far, but I'm actually cheating. What happens is that every time Bilou touches Funky, he's hurt and slightly bounce backwards. It wouldn't be possible that have an harmless, blocking sprite with the Apple Assault engine ... fairly annoying to implement inkjets in the schoolzone, isn't it ? I't's been a background question for a while now, and many solutions have been dismissed already, but I quite like the latest one: have object-to-object alignment primitives in GobExpressions so that you can say "hero is moved out of inker's area" between "play a 'ding' sound" and "shoot a sparkle"

Du coup, pourquoi ne pas simplement prévoir quelques actions "de base" d'alignement au niveau des expressions gobScript ? Plus besoin de définir des flags "sprite solide" ou "non-solide", "solide uniquement de haut en bas", pas besoin de venir bricoler les contrôleurs de comportement: on prévoit simplement qu'un des personnages impliqués dans une collision puisse donner l'instruction "repousse l'autre hors de ma zone de collision verticalement" ou "centre l'autre sur ma zone de collision horizontalement". Même la création d'un lien "transporteur/transporté" peut s'y retrouver. Chouettos.

Personnally, I like how "clean" this approach is. No need to hack something about the collision classes, no need to hard-code some directions of collision, no need to expose more things like absolute location or area properties to the gobScript. Just "block-x, center-x, attach" instructions that will be interpreted in a context where both areas are known by the engine. Just one little detail shows up when reading back the code of the collision engine: only "passive objects" will be capable of using those new operations, because state transitions for the "active object" in a collision are taken after collision tests for that object. Who had collided is no longer known. on found [...] (...) is thus not allowed to use any of the 'extra context' information.

Par contre, en relisant le code, je me rends compte que seul l'objet "passif" dans une collision aura la possibilité d'ajuster sa position ou celle de l'autre objet. Toutes les notes on found sont donc en réalité impossibles à moins de changer aussi le coeur du système de gestion des collisions: il faut les ramener à on hit[]. On garde les plate-formes passives même si c'est elles qui contiennent le code qui aligne les objets.

Conséquence: si je veux qu'à la fois l(a plupart d)es ennemis et les personnages puissent déclencher une réaction avec des plate-formes "passives", il me faudra une classe "Solid Moving OBject" en plus de "HERO" et "EVIL".

That may have some impact on the way we script those objects. Most of the use cases do not cause strong problem, except the "platform that carries both heroes and foes". There, I'd love to make sure that 1) the platform is passive, so that it holds the collision logic 2) I don't end up with O(#foes²) tests in collision tests. It sounds like I'll need a SOLID class in addition to HERO/EVIL, so far...
Small battle plan:

1. add a "transported" state. (e.g. standing on platform)
2. enforce coordinates alignment.
3. make sure you're free to move when transported
4. handle disappearing platform.

indie monkey in lost temple

I'm not the author of that game nor affiliated in any way. I'm just a fan. I loved the look of the rendered mockups and the "strategy guides" presenting the obstacles. It inpsired me today to craft the "cave level screens" of "nuts'n'bolts" based on different gems or stones. My brother's gonna love that: he used to memorise (in my brain) the geology pages of his atlas when we were kids. Only bad thing: I can't remember of the game project's name, nor find it back on the Internet anywhere.

If you recognize it, just post a link as comment, please. You'll receive a dedicated drawing in return ^_^.
Thanks to Furan for identifying "adventure apes" by "scary potato salad"

Un p'tit singe perdu dans un temple ... un projet de jeu de (puzzle?)-platformer plutôt sympa qui m'a inspiré l'utilisation d'un "thème géologique" pour chaque écran dans les grottes du monde de Bilou. Seul hic: impossible de retrouver le projet d'origine pour faire le lien. Le premier à me retrouver le lien vers le jeu d'origine gagne un dessin dédicacé ;)

Congrats' and thanks to Furan ^_^

deep ink pit mockup tout moche

J'essaie de rendre "deep ink pit" un peu plus concret, mais j'ai du mal avec ce classeur qui ne veut pas sortir de mon stylet >_< Je devrais peut-être essayer de travailler avec une autre couleur que le violet. Les Bop'Eponges donnent pas encore trop mal pour quelque-chose de bricolé en 2 minutes dans Gimp. Par contre, l'encre, clairement, il faudra que je me documente pour avoir quelque-chose de décent. Comme quoi, quand je disais que je n'ai pas encore ce qu'il faut au niveau graphismes, je ne vous racontais pas de bobards.

Well, you may remember that poll where you had to vote for different game designs. Deep ink pit was then first presented. A kind of "tower climbing" game where you'd hop from spongebop to spongebop and try to get high enough to convince the Inkjet Master that you're the hero and that he should help you on your quest. I think that will be my next mini-game, featuring 'BN chocolate' soundtrack from my brother. Unfortunately, I'm not much more advanced related to the graphics that I was initially. At least, since I've made a game with the green zone graphics, I'm now free to craft some more graphics. Let's hope it will improve soon, because this seminal mock-up looks ugly to my eye.

edit: dans la cité des images de Rayman, seuls les contours de l'encre sont colorés. Enfin, quand je dis colorés, c'est plutôt un reflet blanc qu'une coloration.

run, you fools!

Mario, Sonic, Rayman ... chacun d'eux peut courir, mais l'impact sur le gameplay est chaque fois différent. Voilà un petit dessin-du-dimanche pour refaire le point. L'élément intéressant (pour un platformer) n'est pas tant qu'on va plus vite en courant, mais plutôt la manière dont on va exiger plus de maîtrise de la part du joueur quand il doit affronter "un saut plus compliqué".

It's not that much about going faster, but rather about clearing longer holes with a jump. In most platformers, this is achieved through the RUN mechanics ... but not all. Check out my scribbled notes for details ^_^

Dans SuperMario, il faudra gagner en vitesse, donc essentiellement contrôler l'absence d'obstacles. Le "triple saut" des épisodes du nouveau millénaire poussent cette contrainte encore plus à l'extrème.

Rayman, en comparaison a un bouton de course "binaire". Un seul bloc suffit à faire un saut long. Par contre, le jeu est beaucoup plus pointilleux sur le timing du saut (point-test unique contre deux tests pour Sonic, peut-être ?).

Keen, lui ne court jamais (ou tout le temps, c'est selon), mais l'activation du pogo permet de faire des sauts plus longs (mais ici aussi, il faut faire d'avantage attention au timing et à l'environnement). Fury est un peu un mélange de Keen et Sonic: on court de plus en plus vite, et on saute d'autant plus haut qu'on enchaine les sauts (il suffit de garder le bouton enfoncé).

Animer Bilou

Petite image d'archive, pour meubler un petit peu pendant que je tripatouille les entrailles de runme. Entre mes notes de philo, je gribouillais déjà en '96 des animations complète de Bilou à réintégrer dans le jeu QuickBasic. A partir de là, je pouvais identifier les positions à dessiner pour le "corps" dans mon Sprite Editor de l'époque, puis définir les coordonnées des 2 mains et des 4 morceaux de pieds à chaque étape. Bien moins agréable qu'avec AnimEDS, hein ?
Côté animation proprement dite, l'influence de Fury of the Furries a été déterminante.

I retrieved last week-end the full set of hand-drawn animations that were used to produce the QBasic version of Bilou platformer game... I'm sure you can feel the "Fury of the Furries" inspiration here. That was later used to plot the various (but restricted) 10x10 sprites for Bilou's body in my custom Sprite Editor, and then to write down the code that set the position of hands and feet ... 6 coordinates pair for every move. Sure it would have been easier if I had the AnimEDS as well by then ^_^

Vu sur Internet ...

J'aime assez bien la "jaquette" que les rédacteurs de scenebeta.com ont mise en place pour mon éditeur de sprite, lors de sa version n° 4. Elle me donne d'ailleurs une idée pour une extension d'enfer: encodez un bitly, et on "charge" l'image correspondante sous forme .spr directement comme spritepage supplémentaire ^_^

Par contre, les échos qui me reviennent parlent régulièrement d'interface perturbante, où on ne sait pas trop qui fait quoi... Comme dit Morukutsu "on sent que c'est fait pour moi, et pas pour un utilisateur". Ce qui n'est pas totalement faux, mais qui doit le devenir :P

Voilà à quoi ressembleraient (imho) les écrans "gestion du fichier" dans SEDS et AnimEDS respectivement, avec cette nouvelle "ouverture au monde extérieur".

The notification of AnimEDS' new release has started propagating from newsboard to newsboard in a totally uncontrollable fashion. Welcome to the world of homebrew :P I just hope that the next wave of newsers will check out this blog rather than blindly quoting gbatemp's news, as 'AnotherWorld' has completely missed what was new in this release : you can create your own character skeletton.

Meanwhile, I also stumbled upon a post about the latest version of SEDS on scenebeta, where the newser made up a funny "cover" for the tool, depicting a megaman sprite re-worked again and again to show various Capcom characters ... yes, that too could be a use of SEDS. I guess all I still lack is a simple way to import some graphics from the Internet for that ... Maybe some online png->spr tool combined with a bitly encoding of the source URL would do it ?

Dans le même temps, un rédacteur de gbatemp a repris la niouze de la sortie de AnimEDS 0.2, mais sans trop se fouler. Notamment, il reprend texto "The application is still in the early stages of development and is hardcoded for a specific layout of the .spr file.", alors que la création de nouvelles structures, c'est justement ça que j'ai apporté entre la 0.2 et la 0.3 >_<

Pourquoi l'éditeur d'animations ? ...

Souvenez-vous: on est en janvier, je viens de faire une release des sources de Apple Assault, je me suis un peu pris la tête avec les responsables de devkitpro et plutôt que d'attaquer un nouveau mini-jeu, je commence le développement d'un éditeur d'"animations à la rayman". Développement qui aura donc duré 9 mois (mais alors, pas intensif pour un sou, hein ;) avant qu'une version un peu utilisable ne voie le jour. "Ma Perché?" me direz-vous.

Eh bien, c'est qu'en janvier, mon frère s'est rendu compte qu'un p'tit bonhomme, ça grandit vite. "Ce serait chouette de refaire mimi pour eux, Pype", dit-il, "et si on veut qu'ils y jouent tant qu'ils trouvent ça rigolo, il va falloir s'y mettre.

Mimi ... "mimi la fourmi", alias "mimi à la campagne" ... un jeu C64 réalisé par 2 québecquois et distribué par Logidisque qui avait fini dans le rayon du GB, puis dans le caddie de mon paternel. Un petit écran bucolique habité par une petite fourmi. A chaque touche enfoncée, une petite musique et une animation ... de quoi apprendre aux charmantes têtes blondes à reconnaître les lettres du clavier en s'amusant. Ma soeur (4-5 ans à l'époque) y a passé un temps certain. Mon frère et moi, on chipait alors le clavier pour enregistrer des "macros" ... une sorte de mini-histoire en enchaînant (N)uit, (R)eve, (J)our, (P)apillon.

"Mimi la fourmi" was a C64 game that defined a part of our family's childhood. Press a key (e.g. 'N' for 'N'ight) and the little ant will do something on screen such as cutting some flowers or bring a cake to a friend, together with some classical theme played through the SID. Between calimero and the discovery of RSD game-maker, there have been projects to port this little jewel to the PC world during my teenage years. Nothing ever got coded, though.

Since my bros' and I are now parents, the idea popped up to revive the game on the DS. Almost everything is in place, except that there are quite many animations for that game ... too much for classical techniques, but not for modular animations. That's why I've spent the last 9 month on a tool that seems so far away from creating one more Bilou game.


Chouettes souvenirs, donc. A peine avais-je maîtrisé les commandes "draw" et "play" du QBasic que j'envisageais déjà un portage sur PC, qui n'a jamais été vraiment commencé. Mimi la fourmi, une coccinelle qui passe sur l'air de "la cuccaracha", une abeille qui apporte du miel, un -- non, deux -- petits vers ... tout ça pourrait en effet être bien sympathique.

Mais il y a beaucoup d'animations différentes dans le jeu C64. A l'époque 8 bit, ce n'était pas un vrai problème. Une image à l'arrêt, une image assise, une debout ... deux pour la marche dans chaque sens. En monochrome 24x24, les graphismes sont vite règlés. Mais en 256 couleurs sur la DS, à 60 images secondes, je me vois mal faire toutes les images à la base. Or, c'est le genre de petits bonshommes qui passent encore bien en animation modulaire -- qui était prévue pour Bilou depuis le départ, mais pas encore disponible. Alors oui, je me suis mis à créer l'outil nécessaire pour faire tout ça.

Et toi, Piet, t'es prêt avec tes MODs ? T'as téléchargé AnimEDS pour te mettre à l'animation ?

AnimEDS: l'écran "fichier"

Le menu "fichier" a pas mal été révisé avec la version 0.3 d'AnimEDS. Ca vaut peut-être la peine de passer les nouvelles fonctionnalités en revue:
Pour enregistrer une animation et en commencer une autre

• pressez (START) pour passer en mode "fichier"
• utilisez le DPAD pour choisir un slot, puis pressez (Y) pour y sauver votre animation
• choisissez une autre animation et presssez (A) pour la prévisualiser
• pressez à nouveau (START) pour revenir au mode d'édition

N.B.: (A) sauve l'animation en cours d'édition dans son slot d'origine. Pour abandonner les dernières modification et charger une autre animation, pressez (B).

Pressez (R)-(R) en mode 'fichier' pour sauver de façon permanente votre fichier sur la carte-mémoire. Alternativement, (R)-(A), (R)-(B), (R)-(X) et (R)-(Y) permettent d'enregistrer sur un des fichiers de travail précis.

Define your own character
That's a major new feature added with AnimEDS 0.3: you're no longer tied to a pre-coded character structure. You can come with a fresh .spr file you've drawn with SEDS and proceed as follows:

• use '-' and '+' buttons to define how many component your character will have
• use '>>' and '<<' buttons to navigate to the proper sprite sheet, touch the picture you want to use as "thumbnail" for a component, and finally L-touch the limb in the limbs table on the left.
• repeat this process until all the limbs have a picture defined.
• click 'OK' to start a fresh animation with that skeletton, or L-click "OK" to resume edition of the current animation with the updated skeletton.

N.B.: the order in the limbs table also define priority among limb sprites.

modifier la structure du personnage:
L'éditeur prépare un personnage à 2 mains, 2 pieds, 1 corps et 1 tête. Chaque "composant" est associé à une palette de sprites (la "sprite sheet" sur la droite) et ne peut utiliser que des sprites appartenant à cette palette. En revanche, plusieurs composants peuvent utiliser la même palette.

• utilisez les boutons '-' et '+' pour définir le nombre de composants dans votre nouveau personnage.
• pour chaque composant, déplacez-vous vers la bonne palette à l'aide de '<<' et '>>', puis touchez du stylet le sprite qui servira de "représentant" pour ce composant et L-touchez le composant en question dans la table de gauche.
• répétez l'opération avec les composants suivants jusqu'à ce que le personnage soit entièrement défini
• cliquez sur 'OK' pour commencer une nouvelle animation avec cette structure, ou cliquez en maintenant 'L' enfoncé pour retourner à l'animation en cours en appliquant les modifications de structure.

N.B.: l'ordre d'apparition dans la table de gauche défini aussi la priorité relative des composants (p.ex. 1 main et 1 pied par-devant le corps, 1 main et 1 pied par-derrière, et les yeux par-dessus tout).
Truc: une fois la structure définie, positionnez les différents composants pour une image fixe que vous enregistrez immédiatement (START-Y) avant de commencer à animer. Enregistrer votre première animation sur un slot différent de façon à pouvoir facilement commencer une 2eme puis une 3eme animation en repartant d'une structure déjà dégrossie.

Manage your animations
Once in the "file" area, you can move the cursor on the top screen with your DPAD to select an animation slot. In v0.3, you're given 48 slots where you can record animations. By default, your "ongoing" work is nowhere yet in those slots, but the program remembers where it came from. So,

• (A) will save current work where it came from, and load the selected slot
• (B) will drop current work, and load the selected slot
• (Y) will overwrite the selected slot with your current work.
• (X) should clear the selected slot, and keep your current work untouched (experimental feature).

When saving your work to a file (with START-R-[ABYX]), the program will automatically write back your current work into the slot it came from.

AnimEDS version 0.3

timeline management reviewed, bug fixed, next/previous location of the selected component are depicted on screen ... well, I think we've got everything we could like for a 0.3 release of my animation editor. Enjoy... start: toggle file/edition screens in file mode:

• DPAD selects the animation slot to use
• A : write back current work and load select slot
• B : drop current work and load selected slot
• X : (delete selected slot ?)
• Y : overwrite selected slot with current work
• L : load file
• R: save to file

edition, with a selected limb: DPAD = move limb precisely, L=deselect edition, no limb selected:

• left = move frame earlier in time, right = move frame later in time
• up = edit previous frame, down = edit next frame
• Y = copy the current frame
• X = delete the current frame

To get started: unpack the zip file, place AnimEditor.nds wherever you want, place the shipped "spritey.spr" at the root of your media card -- if there was any other file there, backup it first. Then boot your DS, launch the editor and press [START]-L-Y to load the file, then [START] again and use DPAD+A to preview animations. Bien. Bugs résolus, manipulation du temps parachevée, visualisation trans-temporelle des composants d'un personnage ... Je pense que tout y est. On peut faire la release 0.3 de AnimEDS. Amusez-vous bien. Les instructions sont traduites en français sur dev-fr. See this post for additional user instructions

OAM Alpha

Résumons un peu:
- si je veux un niveau de transparence variable pour un sprite, le seul moyen est d'utiliser un sprite en mode bitmap/direct color ((Attr 0, Bit10-11) to a value of 3) et d'utiliser le champ prévu pour le no de palette pour "personnaliser" le niveau de transparence.
- pour les sprites à palette, ce sont les mêmes registres "BLDCNT" et "BLDALPHA" qui régulent la transparence des sprites depuis le GBA.

REG_BLDCNT_SUB = BLEND_DST_BG0|BLEND_DST_BG3|    BLEND_SRC_BG2|BLEND_SRC_SPRITE|BLEND_ALPHA; permet donc d'afficher des sprites et le calque 2 transparents par-dessus BG0 et BG3 (pour autant que ces deux calques soient effectivement derrière eux, sans autre chose pour faire obstruction).

Mais comment faire pour que seuls certains sprites soient transparents?

OBJs that are defined as 'Semi-Transparent' in OAM memory are always selected as 1st Target (regardless of BLDCNT Bit 4), and are always using Alpha Blending mode (regardless of BLDCNT Bit 6-7).

nous apprend-on sur gbatek.

C'est donc le rôle de ATTR0_TYPE_BLENDED (à utiliser à la place de ATTR0_TYPE_NORMAL) qui sélectionne le sprite en question comme "source d'alpha-blending" indépendamment de la valeur de BLEND_SRC_SPRITE dans le registre BLDCNT.

Cool. Je suis prêt à attaquer l'implémentation de "l'onion skin" dans AnimEDS ^_^

I need 'onion skin' preview of the previous/next frame in AnimEDS, which suppose some sort of alpha-blending on the frame editor, which is made of sprites. I've got a DS alpha-blending tutorial around for some years now, but my last attempt to have that working in the level editor was rather disappointing. So here's a recap:

• You can make all the sprites have some alpha-blending by turning on BLEND_SRC_SPRITE in REG_BLDCNT_SUB ... not that useful. You're more likely to want a BG translucent that let sprites show through as well. That's with REG_BLDCNT_SUB|=BLEND_DST_SPRITE
• You can selectively turn on blending of some sprites by using ATTR0_TYPE_BLENDED. That's what I need in my editors, but the blending level will be the same for all sprites (and layers).c
• bitmap-type sprites use direct colors (bypassing the palettes), so the ATTR2_PALETTE() field of GBA sprites is useless and has been recycled into ATTR2_ALPHA. I guess you still depend on REG_BLDCNT to tell *what* you're transparent against... Oh, and don't forget to set REG_BLDALPHA to some value, of course.