Au centre de Bowser ?

Super Mario RPG pour SNES n'a à ma connaissance jamais été commercialisé en Europe, et c'est bien dommage. C'est donc sur émulateur que j'ai découvert ce petit bijou signé Square(soft) qui m'aura servi d'introduction au RPG tour-par-tour (je m'étais jusque là concentré sur les Zeldas et autres Secret of Mana, boudant les Final Fantasy et Eye of the Beholder précisément à cause du côté pénible de 'j'attaque / je me ramasse une mandale / je me soigne ://{ad lib}').

Mais je constate assez rapidement que les "mario RPG" ont un petit côté qui les rend radicalement différents: chaque attaque de l'adversaire peut -- moyennant timing adéquat -- être évitée, voire contrée. On retrouve un gameplay beaucoup plus proche de mes Zeldas où une attaque d'un adversaire n'est pas nécessairement une fatalité. Mieux: il est faudra pour porter des coups puissants interagir à des moments précis. Le joueur est plus impliqué dans l'action, même si le côté stratégique (utiliser le bon type d'attaque au bon moment, gérer sa barre d'énergie, etc.) reste plus important que dans un Zelda.

Avec la série "Mario&Luigi", les attaques magiques sont remplacées par des "attaques combo en série". Exit donc la princesse aux sortilèges de confusion, et bienvenue aux attaques tournoyantes à dos de carapace de tortue, au pilonage des Hammer Bros. et au marathon de chow-chow. Il va falloir (dans M&L:SS) reproduire des combinaisons complexes ou (dans M&L:PiT) reconnaître de plus en plus rapidement un des personnages (mario, luigi, bébé mario ou bébé luigi) pour appuyer sur le bouton correspondant. Les "Bros. attacks" continuent à "consommer des ressources", mais avec PiT, des badges spéciaux permettent d'évoluer vers des attaques magiques à volonté. Au point malheureusement de rendre le château final presque lassant.

"Voyage au Centre de Bowser" reprend la recette et la pimente de stylet. Je ne parviens malheureusement pas à être convaincu. Cela dit, je n'arrive pas non plus à lacher le jeu malgré une intrigue qui reste "juste bon enfant". Les 2 attaques principales de Bowser (coup de poing et torche) demande juste d'appuyer sur un bouton au bon moment. J'ai tendance à éviter de lancer des attaques spéciales à coup de bob-omb ou de shy-guys pour épargner mon écran tactile qui doit aussi servir à dessiner des Bilous, du coup, c'est vite lassant.

Autre souci, les différentes zones ont été prévues pour être traversées avec les frères Mario en plus du passage de bowser. Récup? certainement. Mais surtout, une bonne portion des ennemis servent juste de figurants face à Bowser (qui peut les éliminer sans combattre). Du coup, le nombre de "combinaison d'ennemis dans un combat" est sensiblement réduit, et tous les combats d'une même zone se ressemblent. Triple bof. Ca va un peu mieux avec les robob-omb-ocop et autres thwomp enrhumés, mais à peine. Et il aura fallu attendre!

Côté "Mario&Luigi", les attaques deviennent plus variées vers la moitié du jeu: balle magique, tuyau tournant, etc. Le mode "entrainement" est bien pensé, mais il n'arrive pas à la cheville du "badge d'entrainement" qui permettait de se faire la main tout en progressant dans le jeu. Bref, bon emprunt, mais je n'en ferai pas un investissement.

Sinon, le nouveau lave-vaisselle va bien, merci ^_^

Higher and Higher ...

Houlààaa. Il est temps que je réagisse, moi! ça va faire quoi ... 1 mois que le code sur DS est au point mort ? Allez, on descend un peu grizzly le laptop à un endroit où on s'en sert plus de 2 minutes par jour ... on ferme les articles en version draft qui sont ouverts depuis 2 semaines de mode veille, les pages wikipedia sur la distribution de Pareto, et autres tentatives foireuses de changer mon fond d'écran.

Basta, les 4 fenêtres Emacs gelées sur le buffer *scratch* ou sur du contenu Latex probablement périmé depuis ... Même la partition du thème "Flower Garden" pour Guitar Pro 5 envoyée par leemuar (4/2!) et l'article co-écrit avec Manolis (31/1) re-soumis à une conf' en kamikaze :P ('faudra quand même que je trouve un moment pour le lire, note).

Hey there. How about resuming the coding on the animation editor, for some change. As you can see, but probably can't understand, I've been fairly busy on plenty of other matters, including experimenting with a new post-processing technique (based on Inkscape's "trace bitmap" tool) for enhancing the quality of my sketches. Believe it or not, but the one you see on your right actually originates from a picture shot from a whiteboard, and it merely took 5 minutes to enhance and upload (against 20 minutes of PGP setting up to transfer it from a physical desktop to the virtual one). Hope you don't mind if I don't say much more and resume meditation about g++ error messages ? Thanks. You're truly friends. Silent, but friends nonetheless.

Non, parce que, vous avez l'air de dire que je ne fous rien, moi, ici, hein. Mais ce qui va peut-être bien vous plaire, c'est de savoir qu'au milieu de tout ça, j'ai trouvé le moyen de booster la qualité de mes p'tits gribouillages. Vous voyez cette petite idée de gameplay pour la school zone, là, sur la droite ? Vous me croyez si je vous dis que je l'ai dessiné sur le tableau blanc de Cyril qui l'a ensuite photographié pour me l'envoyer par mail ? ... Non ? Bin, pourtant, c'est la vérité. Et avec son téléphone, encore bien (note, ça ne veut plus dire grand-chose, de nos jours).

Mon arme secrète ? La conversion en traîts vectoriels dans Inkscape ^_^. Alors, vous comprenez, avec tous ces dessins qui attendent sur Tux64 le post-processing qui leur permettra de passer sur le Net et la numérisation toute récente de la "deuxième moitié" du "Bilou's Book" ...

Allez, tentons une petite compilation de AnimWindow.cpp, histoire de voire où j'en étais arrivé quand Sourceforge s'est pris sa kernel-panique ...

/home/pype/DS/dsgametools/AnimEditor/source/timeline.cxx:44:31: error: no matching function for call to 'WidgCoords::getcoords(unsigned int*, unsigned int*)'
/home/pype/DS/dsgametools/AnimEditor/../include/GuiEngine.h:128:8: note: candidate is: void WidgCoords::getcoords(u16*, u16*)

D'accord d'accord ...

PS: Oh. Oui, j'ai aussi emprunté "Mario&Luigi : Voyage au centre de Bowser" et enfin trouvé "La trilogie des Périls" ... Personne n'est parfait, non ?

PPS: ouaiche. Ca fait visiblement encore plus longtemps que je n'ai plus codé sur le temps de midi. Même runme pour devkit-32 ne compile pas comme prévu >_<. J'ai du être un poil trop limité sur mon "svn commit" hier soir ...

PPPS: rhaa! une coding session de perdue parce que j'ai dit --cflash-path=dataset au lieu de --cflash-path=datatest et que desmume n'a pas bronché >_<

Life-changing books (1/3)

I guess my life would simply not be the same if I haven't had that book in my dad's shelf when I was young. Granted, I had a couple of books about programming, but the "Commodore 64 user's guide" was really a goldmine. Every single aspect of the C64 was covered: multi-track music, video screen layout, memory map and sprites. There were a couple of high-level techniques that I learnt later on (such as bitmap mode or reprogramming characters) in other books, but this one really set the basis on which e.g. Calimero and Space Mission were dreamt.
Sans ce bouquin sur l'étagère de mon père, il y a des chances que ma vie n'aurait pas vraiment été la même. Oh, j'avais bien 2 ou trois autres bouquins de programmation mieux adaptés à mes 8 ans, mais le "guide de l'utilisateur" était purement et simplement une mine d'or. Musique multi-piste sur le SID, fonctionnement de l'écran et des sprites: tout y étais (enfin, me semblait-il), même si j'ai découvert par la suite d'autres techniques telles que la reprogrammation des caractères ... C'est armé de cette brique à reliure à anneaux que je me suis attaqué notamment à Calimero et à Space Mission.

As a result, many of my spare time since then consisted of filling 24x21 grids or trying to depict level using the PETSCII codes (which I used to copy in a small notebook so that I could use it anywhere), which I'd then convert into lines of DATA for POKE calls.
Une bonne partie de mes temps libres (en dehors de la guitare et des LEGOs) aura donc consisté à remplir des grilles de 24x21 carrés ou à construire des niveaux à l'aide d'une copie manuscripte du jeu de caractères PETSCII que je pouvais par la suite convertir en lignes de nombres traîtées par des POKE (écriture directe dans la mémoire de l'ordi depuis le programme BASIC).

When I received my first PC, my uncle gave me an official copy of the "EP basic" (similar although not 100% identical to GWbasic), which I used for many years. It was pretty confusing to me to move to a platform where there wasn't any memory-mapped registers anywhere. The PC memory map didn't contained anything interesting, and everything had to be done with dedicated statements such as DRAW, PLAY, SOUND, etc.

Autant dire que mon premier pas dans le monde du PC m'a complètement perturbé. Exit les memory maps ... pas de registre de coordonnées pour les sprites, mais des commandes PUT et GET ... Pas de registre de timbre ou d'attaque, mais une commande PLAY capable de "jouer" à travers le PC speaker le genre de ligne mélodique de votre tout premier GSM... et écran monochrome. Pas franchement le grand amour. Mais voilà: le PC est présent en permanence alors que le C64 n'est monté que pendant les vacances.

Organisation globale d'AnimeDS

Pas d'excitation excessive, hein: c'est encore entièrement à coder. Mais puisque je range un peu (en particulier, je cherche mon appareil photo :-/), j'en profite pour scanner ce petit "cas d'utilisation de haut niveau" allant des choix de fichiers jusqu'à l'édition des étapes de l'animation.

Where's my camera ? I'm pretty sure it was there. Behind the sofa ? No. Maybe under this pile of paper ? Nope. ... Hey, but I might have used of that "user-interface sketch" for further coding of AnimeDS, right. Let's boot the scanner ...

</busy>

Bion, c'est le boulot qui veut ça ... J'ai de temps en temps des "deadlines" où on doit mettre tout le reste en berne et courir pendant une semaine pour que les choses soient prêtes à temps. Là, c'est passé, donc je devrais pouvoir recommencer à trouver un peu de temps pour mes bricoles sur DS ... dès que mon organisme aura "EV/EM restaurées" ...

phew. Deadline rush has been succesfully completed, thanks to my new colleagues. I can now resume to a more sustainable rate, and hopefully restart doing some homebrew stuff as soon as I'll have recovered enough sleep.

Still alive.

<busy>

¿ Che Passa ?

Une semaine après un e-mail curieux de SourceForge annonçant une tentative d'infiltration dans leur systèmes qui les auraient obligés à bloquer tous les comptes jusqu'à ce que leurs mots de passes soient changés, voilà une drôle de bourde de configuration qui m'indique que je suis le seul à pouvoir dire à mon ordinateur de faire confiance au serveur SVN sur lequel se trouvent les sources de mes outils. Là, je regrette, mais je vais faire une pause "no sf.net" le temps que les choses soient corrigées...

Slightly more than one week ago, SF.NET announced a hacking attempt. Today, I cannot update my svn working directory because of some certificate issues. That shouldn't impact my hobby too severely, but I'm afraid that means you might see a larger amount of technical self-comments

platforms (at last ?)

1. The platform must be passive
This is due to the fact the platform could be carrying several objects and must remain "unaware" of this.

2. Having a "reference GOB" is fundamental
Not only walking on a platform involves Bilou (or other "character" GOBs) to have controllers that look at the behaviour of other GOBs. It also happens with any other kind of vehicles, with homing shots that have per-instance (as opposed to class-wide) target, or to carrying of objects/monsters. Moreover, it is linked to a collision area of the GOB rather than to the GOB itself.

Bion. Refaisons d'abord le point sur les faits:

1. les plate-formes doivent être passives;
2. un GOB peut toujours avoir un GOB de référence
3. le script ne doit être nécessaire que pour les changements d'état.
4. l'état propre aux contrôleurs est partagé par tous les personnages qui utilisent ce contrôleur.

3. Collisions are only needed when we start/stop being transported.
We simply need to exit the "falling" state when a platform is hit and to leave the "walking/idle" state when the platform stops being solid. To "keep walking" on an established platform, no "event" is required, and no "scriptable action" must take place.

4. It is preferable not to mess with controllers chain
Although it was my initial idea to have collision with platforms to prepend a "walk-on-platform" micro-controller on Bilou, it only make things harder to work with. For a start, controllers are essentially class-wide resources (as the whole state machine), meaning that it would be hard to have e.g. applemen properly walking on platforms this way. Second, it requires that we identify the location in the controllers chain where the new controller should be added, which we currently have no support for. Finally, it would be impossible to insert controller-specific event for "on-platforms" micro-controller, because it is unknown at the "script compilation" time.

Pour pouvoir implémenter proprement les plate-formes mobiles, il faut d'abord:

• que les plate-formes se soient toutes déplacées avant que l'on ne commence les calculs de mouvement des personnages succeptibles de marcher dessus.
• que les flags de collisions permettent d'indiquer "conserver ma référence après la collision" et "accepter une référence suite à la collision"

Si tout ce passe bien, une fois ces éléments en place, il sera non seulement possible de créer des plate-formes mais aussi tout autre type de "déplacement aligné" simplement par ajustement du script (quelles collisions, à quel moment, par rapport à quelle zone, avec quel effet sur les contrôleurs, etc.)

The only modifications required on the engine should thus be 1) that GOBs acting as mobile platforms are "animated" prior to GOBs that walk on them (to avoid zool-lags) and 2) allow collision flags to indicate whether a reference to the passive object should be kept and whether the active object is willing to change its current reference.

It is still unclear, however, to what extent platforms require their own collision cast (that is, beyond HERO and EVIL).

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.