Devant ou au-dessus ?

 Pas mon masque, hein. La carapace de scorpion quand Bilou la transporte. Celle qui doit me permettre de faire quelques petits moments-koopa dans la pyramide. La logique voudrait qu'on la transporte au-dessus de la tête de Bilou, comme les Dumbladors et les éponges dans School Rush.

Mais voilà, je me souviens bien qu'un des trucs que je trouvais dommage dans Super Princess Peach, c'est la manière dont elle ramassait les carapaces pour les tenir par-dessus sa tête avec son ombrelle, la laissant du coup vulnérable à une attaque frontale du plus élémentaire goomba. Je préfère de loin la technique de Mario qui peut se protéger (voire foncer dans un ennemi sans hésitation) dès qu'il a ramassé une carapace.

Should Bilou carry throwable scorpion shells in front of him, like Mario and Diddy or should he carry them over is head like Donkey and Princess Peach ? Both Twitter and my bro agree: over-the-head is better. It sure looks better: the shell is too large to be handled any other way. Plus, other carry-me items in the game already gets carried I can't forget however that I preferred the experience of in-front in all the games I played so far. It shields you against incoming foes, let you find hidden areas without taking any risks and avoids functional blind spots when you're throwing them.

Idem dans la série DKC: une des choses qui fait que j'ai toujours préféré jouer Diddy plutôt que Donkey, c'est que Donkey porte ses tonneaux au-dessus de lui. ça les rend à la fois moins utile comme bouclier et comme détecteur de passages secret: Diddy peut se contenter de s'approcher du mur alors qu'avec DK, il faudra s'approcher pas trop et lancer le tonneau (ou alors, on se baisse et on dépose le tonneau, quitte à le reprendre si on a fait chou blanc)

Du coup, j'ai fait un p'tit poll sur twitter pour voir un peu vos avis ... Majoritairement en faveur du 'par dessus la tête', visiblement. ça paraît raisonnable. J'imagine qu'on devrait pouvoir garder un côté "bouclier" en s'abaissant pendant qu'on porte la carapace, façon Blues Brothers / Tic & Tac. Il faudra par contre que je sois attentif à ne pas laisser trop de "zone morte" au moment du lancer pour éviter le défaut de DK, en particulier si je veux être efficace contre des ennemis à peine plus hauts que Bilou.

I think I can fix the shielding issue with some duck-while-holding that would reduce Bilou's hitbox and increases the odds that the shell takes the hit instead.

I'll need to take care of the functional blind spot. The shell should leave at a speed high enough that it feels 'fast' to the player (might be the other issue with Super Princess Peach's throw move). I sure can't afford the blind spot to be as large as in DKC (anything between Kong and banana on the picture above is out of the barrel's reach)

edit: Maybe my memories of Super Princess Peach are skewed. Re-playing it a few minutes didn't give me that feeling that koopa shells were broken, and one reason for that is that Peach also gives a (short-range) umbrella attack while throwing. 

Possibly the real issue is with button mapping: you use PICK UP to take the shell, but if you use the same button again, you'll drop an harmless shell rather than throwing it as a long-range attack. And if you press the ATTACK button instead of PICK UP when you don't have the shell with you, you risk of destroying the shell instead of getting a weapon. None of this should occur with Bilou, hopefully. And when you see that the shell in Princess Peach has lowered by more than 1 block within the first 4 frames of animation. Low enough to hit any possible monster with almost no build-up time.

spongebop virtual walls.

One evening after the other, my "visual todo list" for School Rush is painting in green. Just like dumblador, Spongebop now has limits, including a virtual floor that will prevent Bilou from falling further when the Spongebop gets jammed. All you can do then is throwing it away to get loose.
L'avantage de cette carte des "todo", c'est que j'ai plus facile de faire une petite avancée chaque soir. Ce soir, c'est essentiellement la "cage invisible" qui empèche Bilou de s'écarter arbitrairement de l'éponge qu'il transporte.
Allez, je suis presque prêt à attaquer les power-ups.

edit: ... check, prêt pour les power-ups ^_^

Amélioration Spongebop ...

Je me suis amusé l'autre jour à imaginer comment les SpongeBops pourraient être plus interactives dans le jeu. Les faire flotter sur l'encre, bien sûr, mais aussi les transporter comme les dumbladors. Et pourquoi pas s'en servir également comme d'un "parapluie" contre les jets d'encre ?

So far, we can grab spongebops while they're swinging, and use them to reach higher places ... but that requires significant learning of the game mechanics. Dumbladors can be used to detach them but so far, it doesn't bring much difference. I wanted to add "carrying" and floating, which is now ongoing. I'd also love to make carried sponge a protection against falling ink droplets...

• [done] pick up and throw spongebop
• [done] spongebop floats on ink
• [done] ink droplets stops on spongebop
• [done] pendat turns back when walking into a spongebop.
• [todo] floating makes spongebop move up and down
• [done] stands on floating spongebop. Don't bounce.
• [done] better physics when thrown
• [done] Bilou stays hung when Spongebop is jammed.
• [done] blador-like virtual walls to avoid Bilou holding the spongebop from far away.

Fixme list

"Don't Repeat Yourself" supported.

The few feedback I got for the "upgraded" school zone level provide some fairly interesting hint: some gameplay features will not be properly managed by players unless they're sufficiently pure. Give any reason for the player to believe that holding B could let him run and he'll fail to discover that he's got to hold R for that to work. So to get pure gameplay in Bilou, I still need:

• [blador:ok] Introduce monsters/ink interaction
• [MEDS] Dedicated animation when Bilou picks up something
• [done] Never "randomly start running", no longer run-on-turn-back, only run-on-land when one had running speed in the air.
• [done] no invisible ceiling to kill your jumps.
• [done] visual clue to tell whether you'll bounce or not.
• [done] visual clue that chalk may break when sufficiently stressed.
• [wish, D.I.P] bouncy-idle-sponge vs. low-bounce-swinging-bops.
• [patch] HUD with life meter. (and speed meter ?)
• [wish, adventure] visual hint for dead ends (?)

Il y a une leçon qui réapparaît à travers les divers retours que j'ai reçu de ma démo de la school zone: les éléments de gameplay ne sont correctement maîtrisés par les joueurs que s'ils sont suffisamment purs (les éléments, pas les joueurs). Par 'pur', j'entends 'le mécanisme se déclenche sur base des inputs, à chaque fois et uniquement dans ce cas-là'. Qu'il y ait la moindre raison que le joueur puisse se mettre à courir en appuyant sur B et celui qui en arrive là lors de sa première partie n'essaiera pas de maintenir R enfoncé pour courir. Par contre, il nous indiquera que 'ouais, courir, des fois ça va, des fois ça va pas'.

Le même genre de leçon peut être tirée pour les animations: une action différente du personnage sur son environnement réclame une animation différente. Le joueur doit pouvoir "voir" que son personnage fait quelque-chose de particulier. Pas d'animation "essaie de ramasser" quand il n'y a rien à ramasser, et il n'y a pas de raison que le joueur essaie de ramasser un truc quand enfin il s'en présente un.

(old) non-symbolic gobscript

All this (and further introduction of power-up with more conditional state transitions) will require more work on the state machine for Bilou which is already fairly complex (32 states, 170 transitions 0_0). 

I don't want to make the parser smarter on the DS side (e.g. I still don't want symbol tables or function definitions) but it's truly time I adapt the Makefiles so that e.g. GCC's pre-processor can be used to produce the "compiled" state machine out of more symbolic description.

(new) symbolic gobscript

Mais pour pouvoir modifier tout ça, il va falloir que j'aille replonger dans la machine d'états de Bilou, qui est déjà pas mal complexe (32 états, 170 transitions).

Je n'ai pas trop envie de devoir augmenter aussi la complexité du parseur qui tourne sur la DS (pas de table de symboles ou de définitions de fonctions, par exemple). mais je pourrais arranger quelque-chose pour utiliser le pré-processeur C pour me convertir une description plus 'symbolique' vers le texte brut compris par le code DS...

Hands'up !

Once we know blador would stick to a wall while Bilou can slightly move below it, our options to show Bilou's hands while carrying something narrow down to only one option: hands are actually part of the "blador" sprite while Bilou's real hands will remain hidden. That perfectly fits the fact that Blador lost its feet, by the way.
Hiding Bilou's hand is somewhat similar to the flickering mechanism introduced for inkjets, in the sense that there's a set of limbs which we'd like to selectively hide while the rest of the character remains displayed.

Je m'attaque enfin à la position des mains, ce qui fera plaisir à Pierrick. Finalement, pour être cohérent avec la façon dont dumblador est transporté, le truc consistera à faire en sorte que les mains de Bilou soient directement visibles sur le sprite de Dumblador. Je reporte à plus tard des mécanismes de "costumes" qui remplaceraient les images en VRAM pour que Bilou porte des lunettes de soleil, par exemple: ça ne m'aiderait pas pour ce problème-ci. Il me reste du coup à cacher les "vraies mains" de Bilou, ce qui ressemble fortement au problème de transparence partielle qu'Inkjet avait introduit, sauf qu'ici les sprites désignés comme transparents doivent en réalité être invisibles.

wrong ...

The first difference with inkjets is that here, hands are *permanently* hidden, bypassing the "counter" used for flickering. The other difference is that many states are involved (actually, most of Bilou's state machine) and that the set of limbs may be different depending on the animation (hands aren't always on the same "layer"), which stems for a more automatic approach (inkjet had sets defined directly within GobExpressions).

Ideally, those "sets" would be defined graphically in AnimEDS. The second best thing I can do is to define them only once, when the animation is imported in the GobScript. That's manageable for a prototype. As a last refinement, I had to alter CopyCoords controller so that it produces an event whenever horizontal direction changes, so that the animation can be changed to avoid odd displays where Bilou seems to have "crossed his arms" while turning back (see the 'wrong' picture).

Je conserve donc le concept de sélection de sprites attachés à un personnage (flickermask), des animations elles-même de sorte que si je réutilise la même animation dans plusieurs états, elle définit en même temps le masque à utiliser. Ce serait encore mieux si je pouvais définir cette sélection directement dans AnimEDS, mais je n'y suis pas encore. D'ailleurs, c'est la raison d'être principale du "GobScript": pouvoir expérimenter les techniques du game engine avant d'en automatiser la gestion par les éditeurs graphiques.
mais les expressions de la machine d'état ne seront plus le seul moyen d'y accéder. Je le complète avec une annotation au niveau de l'animation elle-même.

right!

Je suis obligé, par contre, de passer à 2 états distincts pour le transport de dumblador (un vers la gauche, l'autre vers la droite) de façon à utiliser la bonne animation au bon moment. Il faut du coup que j'ajoute au contrôleur copycoords la possibilité de provoquer un changement d'état quand le personnage transporté subit un changement de direction (ça sera intéressant aussi pour Bilou-sur-l'éponge, tiens).

One drawback with this approach, though: Blador follows the move, but he stays at constant height while Bilou walks/run despite the fact that Bilou's body moves up and down.

The art of Blading

For g88 release, carrying bladors was functionally correct, but still a bit cheap, as the carried blador could move through walls, ceilings and such. It would be an acceptable simplification of physic rules in-game if that did not meant you could "throw" it while it overlap solid structures, which would let it "stuck" there as soon as regular physics takes over to let it be thrown away. I want the game to feel professional, and demonstrate that a simple scripting approach does not imply half-baked behaviours. It's thus time to prove it.

Un taille-crayon qui passe à travers tout pour qu'on puisse le lancer n'importe où, ce n'est pas très réaliste, mais c'est acceptable dans un jeu vidéo. Un taille-crayon qui reste bloqué dans un mur quand on le lance, ça, ça fait tache. Surtout quand le joueur aurait théoriquement dû pouvoir le ramasser et l'emporter plus loin. Premier pas pour corriger ça, interdire à mon taille-crayon de passer à travers les murs (ce qui demandait un réglage spécifique du contrôleur freemove). Résultat: Blador suit maintenant Bilou "de son mieux", ce qui amène parfois des résultats curieux comme un saut quantique à travers un mur contre lequel il est resté scotché pendant 15 secondes lorsque Bilou émerge enfin d'un passage secret.

The first step is to make blador using freemove(1) instead of using freemove(0) when carried. Freemove is the controller that allows free movement typical from airborne ennemies such as the berrybat. The only thing it does before validating the desired movement is checking that you cando(m) where m describe some properties of the environment - like being something you can MOVETHRU. 0 is considered as a special case where you can always do what you want -- perfect for ghosts or sparkles that will fall of the screen. So now, blador can't get into walls, but curious things occur when Bilou gets into narrow passages where Blador cannot follow: Blador just sits where it is, and if at some point Bilou reaches a new position where Blador could fit above its head, Blador gets quantumagically teleported to that new location (yes, again).

Pour corriger ça, il faut que Bilou puisse être informé de la situation du Dumblador qu'il transporte. En '97 j'avais donc pensé augmenter mon "ulitmate game maker" d'un système de messagerie entre les personnages. En fait, ici, on va faire beaucoup plus simple: tout comme l'encrier possède une zone-test (hitbox) qui repousse Bilou lorsque celui-ci l'approche, le Dumblador transporté va disposer de murs invisibles qui empècheront Bilou de s'en éloigner de trop tant qu'il le transporte. Eh oui: c'est aussi simple que ça.

Enfin, presque. Il y a quand-même une subtilité dans le cas du saut. Si je me contente de forcer Bilou à faire du sur-place au milieu d'un saut juste parce qu'un taille crayon a la tête dans le plafond, ça fout en l'air la crédibilité de la physique du jeu pour donner un effet Badman/RSD Game-Maker carrément pathétique. Il faudra donc que je traite cette collision aussi du côté de Bilou en forçant une remise à zéro de la vitesse, exactement comme le contrôleur "gravity" l'aurait fait si on s'était vraiment retrouvé directement dans un mur.

I like how Bilou/Blador distance is stretched or squished when colliding the environment, but I need more control over it. And that's just a perfect fit for the "repel" action introduced with solid inkjets. To avoid having Bilou going too far away from the carried Blador in a narrow tunnel, I just need some repelling-areas acting as virtual walls at appropriate distance from its position.
The same approach allows Blador to take some room between Bilou and the ceiling, but here I need some additional action. "Repelling" simply adjusts coordinates and does not affect speed. The result was that Bilou would keep floating along the ceiling as if he virtually kept jumping. Even weirder: he might have resumed moving up as soon as he'd have moved away from what was blocking Blador (just as in Badman II, actually).
To avoid this, Bilou needs to react on the collision and clear vertical speed. Additional tests are needed to ensure the blocking object (active GOB) is indeed over Bilou's head and that he's still moving upwards. The center-to-center distance (dy) is available through GobScript wf variable read and is positive when the active object is above the passive object (and yes, the sign of dx and dy is related to passive/active roles as the distance is defined only once, and then reused in both passive and active objects transitions).

Il me reste donc "simplement" à corriger l'ordre d'affichage de Bilou et du dumblador (tant qu'à faire, prenons-le en mode "hotte de père Noël" plutôt que "Sac de courses devant le nez") et à m'assurer que les mains de Bilou apparaissent sur le taille-crayon pendant qu'on transporte le crayon.

It leaves me with one last aspect to fix: having Bilou's hand properly shown as grabbing the blador while it is carried, knowing that hands will have to be aligned with blador rather than with Bilou if we want to keep stretch/squish.

2 days left

Inkjet throwing Bilou up finally works fine with corrected animations. I wish Bilou would lower by 3 or 4 pixels when the inkjet prepares the blast.
Tonight, I shall upgrade runME and the .cmd files on the DS so that I can try all those new objects in their real target environment. I also added some turn-back transition for pendats ... they should be able to join the game soon.
I still need some blocks for the "end-of-rail" tile and some horizontal
I need to make RectoVerso vulnerable to thrown bladors
I have to check inkjet-on-rail do work
I need to make sure the engine in RunME allows me to keep grabbing sponges.

Bien. Les animations pour projeter Bilou fonctionnent. Ce serait pas mal que Bilou s'abaisse de 3-4 pixels pendant que l'encrier se prépare. Reste à mettre à jour runME et transférer les .cmd sur la DS pour faire quelques tests en situation réelle. J'ai aussi rajouter une animation de demi-tour pour les pendats. On devrait pouvoir les intégrer prochainement.

Manquent encore des blocs pour la "fin du rail", les rails horizontaux, rendre les gommes vulnérables au lancer de taille-crayon, vérifier que les encriers-sur-rail fonctionnent correctement et que le moteur de jeu permet d'attraper les éponges dans runME.

Gare aux taches d'encre ...

Au-delà des pentes plus ou moins pentues et des personnages en 3D, il y a un "monstre" supplémentaire qui attend de rejoindre la school zone et qui n'en est plus qu'à quelques pas: "inkjet", l'encrier tacheur.

Petit tour d'horizon sur la façon de le réaliser, à l'ancienne sur une feuille quadrillée avant d'aller dormir... Chose amusante, je me rends compte qu'en réalité les 2 formes d'encrier ("volant" ou "poussable") présentés ici pourraient très bien être 2 GOBs aux machines d'état totalement distinctes.

As the real life gets a bit more quiet, I managed to find half an hour with pencils and paper ... just enough to make a quick list of what should be done in order to bring inkjets to life. A first one would be "turn back" special blocks that floating inkjets use to change (progressively) their direction (as opposed to an "invisible wall" that would immediately stop the inkjet).

Parmi les "petits défis techniques" posés par Inkjet, j'ai recensé le "demi-tour de plate-forme mobile", nécessitant un contrôleur adapté.
Rien de particulier pour que Bilou puisse être transporté par un inkjet, en revanche: ce sera entièrement dans le code de Bilou que ça se passera.

As far as "carrying" is concerned, nothing special should be needed in inkjet.cmd file -- except a special flag assigned to some hitbox. Bilou's state machine is fully responsible of the additional "carried" state. What we might want is a "throw up" state that allows a hitbox to cancel the droplets generation, so that droplets are created *only* if no character was carried (and thrown up).

Envoyer Bilou en l'air s'il est présent et lancer des gouttes d'encre dans le cas contraire ? C'est possible. Il suffit d'une zone de collision associée à l'animation "projeter". Si elle rencontre un personnage compatible (transition "found"), elle interrompt l'animation (et le projette). Les gouttes d'encre ne seront générée que si l'animation prend fin naturellement (transition "done" dans ma machine d'état).

Interestingly enough, all this is independent to what would happen to the "standing" inkjet (on the ground) and the transitions used to allow it to be pushed by Bilou.

Pour l'encrier au sol, je devrai procéder en 2 temps. Tout d'abord, m'assurer qu'il est effectivement "solide" pour les marcheurs, qui fasse faire demi-tour aux dumbladors et force Bilou à passer en mode "pousser".

Ensuite seulement, une 2eme collision dans le sens inverse force l'encrier à se déplacer.

Bon, là-dessus, je vais m'installer pépère dans un fauteuil et faire quelques petites animations supplémentaires dans SEDS...

Checklist:

• [check] special block digits are read horizontally first, then vertically
• [oops!] 1xxx is for "interacts with monsters" "interacts also with monsters", 2xxx is for "doesn't trash graphics while removing properties" "doesn't disappear when touched", but we could use "on hit [0] ()" in block description to prevent it.
• [oops!] "block 1002 {" effectively encode properties of block using digits 1,0,0,2 on the level editor and not some other funny 0x1002 value that wouldn't make sense. (block 82 is required.)
• [ok] states doesn't prevent collisions to be detected.
• [fixed] decrease controller can cannot be used as expected.
• [bugfix] GameScript::content() should allow \t tabulations in cmd files.

Games of Thrown

1MB. throwing in action ...

mises à jour du moteur de jeu terminées: on peut ramasser et lancer des Dumbladors ... puis les re-ramasser et les lancer de nouveau. Enfin, toujours dans la même direction, je le crains, mais lancer quand-même.
Je vais pouvoir passer à l'implémentation des inkjets, du coup ^_^b

PS: attendez-vous à un ralentissement brutal et imprévu du rythme des messages de ce blog dans le courant du mois: *deline attend son petit frère j.l.n mi-janvier.

The game engine now supports throwing of bladors. Pick it up, throw it, repeat. Many things could still be refined including

• [done] having feet really hidden during the stunned animation.
• [drawn] having the bouncing feet looking like feet
• [done]allow the engine to shoot compound gobs too (new feet anim)
• [done] allow runMe to launch the level as well.
• [done] avoid one-way platform to corrupt behaviour of bouncing feet
• [done] throw in both direction, and just drop if you feel so.
• [wish] blador can stun baddies (and Bilou ?) while falling
• [done] fix the map
• [done] use dynamic palette assignment and get rid of those "crosses" marking Bilou feets in jump animations
• [done] areas that can trigger only one other GOB (or a single foot can be consumed by 2 dumbladors simultaneously)
• [wish] climb on stunned bladors, but still walk through them. 
• [done] multi-color that works in runMe too.
• [done] make sure we restart the level if killed, with colours.
• [done] allow bladors to recover next to walls.
• [done] Blador recovers when 2 feet have touched it.

I'll do my best to get all that sorted out quickly so that I could offer the world a new playable demo for Christmas. Earlier arrival of lil'sson could force me to tolerate some imperfections in that release, though.

levez .. abaissez ... levez ... balancez!

Petite réflexion de week-end: comment s'assurer que Bilou ne puisse pas tenter de prendre un 2eme objet en main. Pour l'instant, c'est en tombant une 2eme fois sur Dumblador que celui-ci passe en mode "transporté", ce qui autorise un nombre arbitrairement grand de Dumbladors à suivre Bilou.

Il faudra donc impérativement que les zones de collision déclenchant le ramassage et le lancer soient liées à un état précis ("ramasse" ou "lance") plutôt qu'à une zone générique, vu qu'on a pas de zones conditionnelles. Il suffit alors d'une des variables d'état de Bilou pour se souvenir s'il y a ou pas un objet à lancer lorsque le bouton d'action est enfoncé.

Technically speaking, we can now carry dumbladors. But we're carrying too much of them: every bop on a stunned blador turn it into the "carried" state. I'd rather avoid having 3 bladors following Bilou: grabbing a new one only if none is being carried at the moment would be by far preferable.

Conceptually, there are two "meta-states" (free hands and carrying), and we're only switching from one to the other by picking up or throwing objects. Practically speaking, however, there no such "meta-states" in the state machines, but there are some per-gob variables that can complete those states, so sIdle-> sPickup and sIdle->sThrow transitions would be conditional (and use dedicated collision areas).

Reste le problème de l'apparence proprement dite (les mains en l'air). Au départ, j'avais envisagé un mécanisme de "costumes" (cf. Monkey Island) rudimentaire qui aurait consisté à "geler" la position des mains de Bilou en ignorant toutes les commandes d'animation les concernant. Le hic, c'est que d'une animation à l'autre, les mains ne sont pas forcément liée au même "membre" logique.

Pas évident non-plus de modifier le contenu d'une page de graphisme en guise de "costume" (comme on l'aurait fait pour Kirby), à moins d'effacer complètement les mains du sprite de Bilou et de les intégrer à l'objet transporté (Dumblador, donc). La seule alternative restante serait de donner une deuxième version de *chaque* animation... j'imagine que vous comprenez aisément pourquoi j'aime autant trouver autre chose :P

To ensure proper operation, it is required that some  active collision zone could force state change after the first collision has been triggered. Then, I still have the problem of "animating the pick-up", but I came up with a nice approach for that.
Last but not least, I'll have to ensure that Bilou's hands remain above his head while moving along with a blador ... which may involve an alternative for *every* animation. I'm still thinking about a more practical way to handle that.

En voiture!

Je continue de suivre ma petite carte de développement, une fonction à la fois. Après les panards baladeurs, après la correction des bugs d'animation, voici le transport de dumblador.

First occurence of a transported GOB tonight: stunned dumblador will not simply follow Bilou (as BerryBat): it sticks to a defined position relative to Bilou. A nice "proof of concept" before I try to make it look as professional as possible. [done]

Un nouveau "contrôleur" qui utilise directement les coordonnées de Bilou (après attachement) pour aligner le dumblador. Ça n'est pas encore aussi impeccable que je le souhaite, et on peut observer un léger décalage qui dépend de la vitesse de Bilou, comme avec les plate-formes de Zool. Il faut donc que j'aille jeter un oeil aux listes d'animation pour ajouter le support de ces bits "pending" pour arranger ça.

Puis j'irai chercher une technique de "costumes" à la Monkey Island pour que les mains de Bilou reste sous le Dumblador.

The Power of Mario

Voilà, c'est mon tour d'avoir fini "l'Histoire de Mario" de William Audureau. Bien intéressant, même si j'avoue que le côté "pourquoi lui ?" mis en avant par l'auteur ne correspond pas à ce qui m'intéresse le plus. Ce qui me tente, moi, c'est de comprendre comment sont apparu les mécanismes qui en font à ce point un jeu hors pair. Au risque de décevoir, je dirais que graphiquement, Super Mario Bros était dépassé techniquement avant même sa sortie. J'en veux pour exemple Pac-Land en arcade en 1984. Non, ce qui est extraordinaire dans ce "premier" Mario, c'est les mécanismes de level design.

Un des grands absents de ce point de vue, dans le livre d'Audureau est sans doute le bloc-question. Miyamoto avait pour règle de travail "la fonction précède la forme": trouvez d'abord quelque-chose d'intéressant au niveau game-play, puis "habillez" là avec quelque-chose de cohérent dans l'univers du jeu. C'est ainsi par exemple que sont apparus dans Mario Bros (vs game) les tuyaux de téléportation, répondant au besoin "d'habiller" le point auquel les tortues quittaient le bas de l'écran pour attaquer une 2eme fois les frères Mario.

I'm pretty lucky we have Pix'n'Love editions around, to provide us great retro-gaming material. I've been reading what you could name "Mario, why *him* -- the story" last month. More than the retrospective aspect, of course, what interrest me most is to dive into the creative process that brought innovative games such as Donkey Kong, Mario Bros. and Super Mario Bros. And for most, I haven't been disappointed. Why barrels, why turtles, why a linear adventure ... so many items are indeed discussed beyond the simple question of "why Mario wears overalls".

La fonction du bloc-question est claire et géniale en même temps: indiquer clairement au joueur l'emplacement des bonus tout lui cachant le nature de ce bonus -- et ça tout en utilisant le mécanisme premier du jeu: sauter. Dans zelda, les "bloc-questions" seront des jarres à casser, vu que le mécanisme premier est le coup d'épée.

Mais alors, que s'est-il passé avec la forme ? Pourquoi cette absence d'habillage complet ? Le mystère n'est même pas évoqué par William. Ce qui est certain, c'est qu'à de nombreux recoins du jeu, l'équipe de Nintendo va utiliser ce côté "magnétique" qu'exerce un bloc isolé et difficile d'accès -- qui pourrait potentiellement contenir jusqu'à un 1UP ou un Power-UP plus rare ... mais aussi une simple pièce d'or ... ou encore une plante grimpante vers une salle bonus!)

But the genious part of the level design imho lays somewhere else -- and is unfortunately un-covered by the book. Questions blocks and Koopa shells. These are the two gameplay elements that make the Mario platformers unique, challenging and interesting. The ?-block is the platforming perfect equivalent of Zelda's bushes, that you hit with your primary mechanics (jump), whose position is obvious, but its content is unknown. So when shown a standalone block in a hard-to-reach area, will you expose yourself, hoping for high reward or not ? Like with poker, you won't know what you missed unless you try it out.

The koopa-shell is bringing the "spinash"-power up to a new level. Flip the power balance: that's the very nature of Pacman's power-up, and to some extent, power-ups in Mario, starting from the hammer in Donkey Kong. The koopa shell does that. From an ennemy, you make a weapon, and a pretty effective one. Only the starman would allow you to defeat a batch of ennemies more easily in SMB than a properly kicked koopa-shell... But a single block on the ground can flip the situation again, because you're not immune to that lethal weapon. And since the shell is quick, you need to speed up to benefit from its action -- but you then expose you again, by reducing your reaction time.
I'm still looking for something as interesting to inject into Bilou's world. I hoped that I'd be taught through the book what is the "design question" that turned "what bounces on walls, moves quickly and hurts when it hits you ? " into "a turtle's shell" ... but obviously, Miyamoto's team has not commented on that.

Autre grand absente: la carapace de Koopa. L'introduction des tortues est elle très bien détaillée ... Mario Bros étant basé essentiellement sur le saut (là où Donkey Kong ne l'avait introduit que comme échapatoire), la première idée de l'équipe est de permettre de "taper par en-dessous". La question de la fonction devient alors "qu'est-ce qui se retrouve immobile lorsqu'on le retourne", et la réponse (l'habillage) : "une tortue".

Mais le génie du koopa-troopa n'est pas là: il s'agit de pouvoir transformer un ennemi en arme. En un seul mouvement, le joueur de Super Mario Bros. envoie vers une longue série d'ennemis un seul projectile capable de les éliminer tous ... mais qui peut se révéler un danger mortel si quelque-chose de dur interrompt sa course. La "boîte d'épinards" de Popeye (origine incontestée des Pac-gommes et power-ups de manière générale), mais à double effet. Qu'est-ce qui passer de "qu'est-ce qui peut être lancé loin pour cueillir des champignons" en "une carapace de tortue" ou "qu'est-ce qui peut se retourner contre son lanceur" - "une carapace de tortue" ... aucune idée.

Grab me, shoot me.

Tout ça est parti d'une relecture des "notes de développement" que je prenais il y a maintenant 10 ans (eh oui) en préparant mon "Ultimate Game Maker". Si les approches que je voulais suivre sont complètement obsolètes, en revanche, j'avais bien creusé les "scénarios pièges" qui définissent généralement la limite entre un moteur de jeu "spécifique" et un moteur générique. En l'occurence, ici "Bilou attrape un ennemi assomé et s'en sert comme arme sur d'autres ennemis".

Coding in a hospital is definitely not an easy job, but there was at least one thing i managed to do during that "free" time when sleep didn't want to come : re-reading those design notes on the "Ultimate Game Maker" I wrote down 10 years ago, organising them, pin-pointing good and bad ideas. Despite virtually all the technical details now fall in the "BadIdeas" category, there were a collection of "gameplay scenarios" that i can reuse to ensure my current game engine is generic enough. The specific "use case" I further studied was the ability to grab an ennemy and use it as a weapon against other ennemies.

Du point de vue "mécanique", je joue sur la possibilité de définir des propriétés aux zones de collisions. Un appleman normal possède juste la propriété "stomp" qui permet à Bilou de l'étourdir en sautant dessus, une fois étourdi, il possède aussi "pick". Au moment où le joueur enfonce le bouton "poing", on ajoute une zone de collision à Bilou qui teste la présence de "picks". En réaction à ce genre de collision, l'état de Bilou aussi bien que celui de l'appleman sont modifiés. Le même genre de mécanisme avec une propriété "shot" est utilisée pour provoquer le passage de l'appelman de l'état "transporté" à l'état de projectile. Tout va bien.

First, I need to translate the scenario into states-collisions-properties elements of my current engine model. With the recently introduced per-collision-area properties, it goes quite well. The appleman doesn't receive f_pick collisions unless it is in the 'stunned' state, and Bilou doesn't test for f_pick collisions unless the player triggers a punch. Similarly, the 'carried' appleman can receive f_shot collisions that turn it into a weapon agaisnt other ennemies. This was tricky in the UGM model because the class of a Gob (bonus, character, ennemy, shot, object ...) stricly defined what collisions could occur. The new model is much more tolerant and it's only your mind that decide the appleman is now a ennemy and then a weapon. Of course, the controller used in "carried" state aligns position and speed of the appleman to those of Bilou.

Sauf que ... comment au juste vais-je "ramasser" l'appleman ? Je veux dire, le mouvement des mains de Bilou et celui de l'appleman doivent être synchronisés pour que ça marche. C'est le genre de problème qui n'apparaît pas dans Blues Brothers avec une seule étape d'animation et un seul objet à ramasser (la caisse), mais je veux profiter de l'absence de bras & jambes de Bilou pour améliorer les animations, même si j'ai 15 ans de retard sur Rayman pour l'implémentation ^^"

The tricky questions surprisingly came from rendering the actions. How do I define the intermediate frames of Bilou grabbing and shooting the appleman ? It wasn't much of an issue in 8-bit (chip'n'dale) or 16-bit (Blues Brothers) paltformers, because you had at most one frame and one object to carry (the crates). But I'd like to take advantage of the 'limbless' nature of Bilou to improve animation (despite I'm 15 years late compared to Rayman :P)

Plusieurs lignes de conduites sont apparues par rapport à cette réflexion:

• les sprites d'un Gob composé doivent permettre de définir l'emplacement des zones de collisions, ainsi f_pick est toujours associé à la main droite de Bilou (tout au long de son déplacement) et f_shot à son pied droit.
• l'ancrage d'un Gob (appleman) à un autre (Bilou) doit aussi pouvoir être défini par rapport à un sprite précis. Ainsi, quand Bilou abaisse sa main pour shooter dans l'appleman, l'appleman suit le mouvement
• deux "commandes" permettront de définir des animations plus fluides : "goto" et "auto", qui permettent à un sprite d'utiliser une paire des variables du Gob comme vitesse pour atteindre un point de référence donné.
  

It resulted that in such 'composite GOBs', the individual sprites (hands, feets, body) should be allowed to govern the position of (some) test areas, and serve as anchor points to other 'carried' GOBs. Moreover, we'll love to have "automated" animation statements such as "go to (x,y) using GOB variables v4 and v5 as horizontal and vertical speeds", rather than giving explicit position for every sprite at every frame.

I could have alternatively opted for multi-gobs (that is, Bilou *shoots* a hand that come back at him), but that would have terribly complicated further interactions.

ps: i gave the official google "readmore" feature a second try on this post and i'll drop it: the RSS still provide the full post, making "read more" not that useful. Plus it will doom my backup strategy. Only "ranting" posts will have "read more" stuff.
pps : yeah, that means i'll really have to work on that "modular animation" add-on for SEDS.

Encore Titus

De temps en temps, je passe faire un tour sur vgmaps.com, un chouette site qui répertorie les niveaux de jeux vidéos comme un "atlas". C'est du boulot, évidemment. Ayant récupéré "the Blues Brothers" sur abandonia, je me suis amusé à photographier le jeu au fur et à mesure.

the Blues Brothers, c'est le jeu où Titus Interactive prépare les ingrédients de ses futurs jeux. Des munitions (caisses à lancer sur les ennemis), pas encore tant de passages secrets, mais une série de "salles secrètes", comme les cavernes de Prehistorik (premier du nom) qu'il faudra explorer pour rassembler les objets nécessaires au concert de Jack et Elwood, mais qui peuvent aussi bien contenir des "bêtes" bonus ou un loubard.

Many games feature a way to carry items between different places, but Titus Interactive, in their nineties, brought that as the number-one mechanic of the game. The amno, for instance, are things you carry along, like crates. You can only carry one at a time, and if you get hit, you lose what you're carrying. The result is a platformer where careful progress is required, but where you also face a puzzle dimension, in the sense that you will need to pick your route to save amnos.

The whole is spiced up with some exploration, as you will need to find a special item in each level to get the "good ending" of the game. By then, I found that mix much more interesting than the usual straightforward, infinite amno, gun-oriented platformer.

Autre détail qui a son importance, si vous êtes touchés alors que vous transportez une caisse, vous la perdez, ce qui veut dire que plus loin dans le jeu, vous serez désarmé face à un autre danger. Bref, le moindre faux-pas est lourd en conséquence. Autre exemple, les designers se sont amusés à s'assurer qu'à deux ou trois endroits, vous risquiez de retomber plus en arrière dans le jeu (de préférence là où vous n'aviez pas la possibilité d'éliminer tous les ennemis).

• niveau 1 : le magasin (guitare dans une des échoppes). On affronte des loubards, des mémés en caddie, des policiers, des serveuses furieuses et des jardiniers toqués. Une fois dans les nuage, c'est le piaf pond-vite qui nous mêne la vie dure
  
• niveau 2: en construction (lunettes et chapeau que je ne parviens pas à atteindre. Peut-être faut-il un parapluie ...) Sale gosses armés de pulvérisateur d'acide et gros bras maniaques de la clé à molettes, mais gare aux mares d'acides et aux broyeurs.
  

Autre petit élément sympathique, des objets tels que les parapluies ou les balons du premier niveau, offrent un gameplay plus varié.

Bref, du bon jeu de plateau comme on aimerait en voir à nouveau. Dommage que l'opus "II" (juke box adventure) n'ait pas été une réussite... Bien sûr, les graphismes sont nettement plus beaux, mais ils ont complètement perdu le fil de l'histoire. Tout d'abord, le principe même du jeu n'a plus rien avoir. On le catégorise sur abandonia de "no-brain fun", et en effet, plus la moindre recherche. La progression dans le niveau est devenue ultra-linéaire. Finies les caisses, ici on lance des disques, et il faudra souvent en balancer plusieurs pour venir à bout d'un monstre apparemment inoffensif.

Là aussi, le bât blesse: alors que Blues 1 nous avait fait affronter des personnages parfois déjantés, mais toujours réalistes, on se retrouve ici face à des pièges à loup vivants et géants, et .. euh une sorte de tondeuse à gazon croisée avec une pelleteuse mécanique qui à visiblement des instincts de pit-bull.

Bref, les deux premiers niveaux sont beaux, mais franchement insipide une fois leur côté démo/tutoriel passé, et dès le niveau 2, les monstres sont tout simplement pénibles (mouvements trop rapides, impossibilité de les dégommer quand ils sont "au repos", bref, pas impassables, mais pénibles)

Et pour le coup de grâce, je vous laisse contempler, hébétés, nos fameux blueseurs transformés en sur-hommes après avoir mangé une part de gâteau, ce qui semblerait leur permettre de faire des sauts plus longs, et peut-être renforcerait la puissance de leur lancer de disque.

Ridicule et pas convaincant pour un sous. Bref, autant Titus Interactive nous a fait de bons jeux dans ses jeunes années, autant il semblerait qu'ils aient été contaminés par la transformation du monde du jeu vidéo en un "marché" et progressivement perdu toute notion du gameplay et de la conception des bons niveaux. Je n'oserais même pas dire qu'ils ont transformé BB en un clône de Megaman: la seule ressemblance viendrait du fait que l'on tire sur des ennemis dans un sidescroller.

Bref, concentrez-vous sur le premier volet à moins d'être un graphiste en manque d'inspiration.