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 >_<