'faut pas pousser!

Vous êtes devant une porte verrouillée au fond d'un tunnel. Il y a un trou rempli d'eau sur le chemin menant à la porte, alimentée par une chute venant de la galerie supérieure. Votre sens de l'exploration vous sussure que la clé pour la porte doit se trouver dans une des galleries supérieures que vous avez aperçues durant votre chute. Vous pouvez sauter avec (A) et ramasser des objets moins lourds que vous avec (B), mais la galerie supérieure est trop haute pour que vous puissiez l'atteindre en sautant.

Bon, vous l'aurez compris, je suis à la recherche d'une alternative pour le niveau 1-1 de Bilou qui ne dépende pas d'une action a priori peu maîtrisée à ce stade comme "pousser un bloc". Mais j'ai quand-même envie que le joueur ait la sensation de s'être tiré d'affaire, pas juste d'avoir fait demi-tour.

Ayant tout juste rejoué à DK Tropical Freeze, ma première idée était de mettre un gros bouchon au sol et de le retirer avec (B). Si il faut, on pourrait même faire en sorte que le bouchon dépasse un peu et qu'il laisse passer une goutte de temps en temps, pour attirer l'attention du joueur. Sauf que ... dessiner un geyser, c'est plus facile au bic qu'en 256 couleurs ... l'animer, c'est plus facile dans la tête du lecteur qu'à l'écran... Et ce n'est pas l'époque 16-bit qui va m'aider, cette fois-ci. >_<

How do you get yourself out of a hole when all you can do is JUMP and GRAB but you cannot jump high enough ?Maybe you're lucky and there's a plug-like think holding water that was just waiting for you to spring out. That would save me the trouble of needing to code raising water level and making the player confident that they won't drown if they fill the room with water ... But I have no idea how I could make a convincing geyser and '90s pixel art really does not help this time.

A supposer même que je trouve des graphismes concluants, et si le geyser a l'avantage de ne pas demander de jouer dès le niveau 1 avec de l'eau qui change de niveau, il reste un problème physique: il faudra que je trouve un layout qui explique que l'eau du geyser monte alors que l'eau du "puits" non.

Est-ce qu'on pourrait s'en sortir avec le bouton de saut ? C'est quand-même la mécanique de jeu n°1 ... On pourrait donner un coup de tête dans un truc ou tomber sur un machin qui ferait apparaître des plate-formes (disons des feuilles depuis des lianes, pour rester dans le thème de la forêt) puis sauter de feuille en feuille pour se tirer d'affaire.

Mais j'ai le même soucis qu'avec les Ethers en 200x: c'est un comportement de sale garnement et je voudrais que Bilou reste un personnage exemplaire (malgré son caractère ronchon). (De nouveau, le lecteur attentif sentira l'influence de DKTF et de ses plate-formes rangées contre le mur qu'il faut faire basculer à l'horizontale ... mais dans l'autre sens)

Could there be anything that would trigger a useful event if jumped on ? Like making buds bloom into leaves large and strong enouh to be used as a platform. But unfortunately the only such trigger I could think of imply that Bilou is hurting the target and that pain is the thing that forces blooming. I'd rather not have Bilou do such things if I can avoid it.

Par contre, l'avantage de cette idée, c'est que comme j'ai l'intention de permettre à Bilou de s'accrocher en appuyant sur (B) en l'air, on peut remonter soit en combinant attraper/sauter, ou en utilisant le "mécanisme" pour faire apparaître les feuilles. (détail sans importance puisque le joueur un poil rôdé au jeu n'aura pas oublié d'aller chercher la clé en premier)

Mais sinon, il y a une alternative plus sympa, inspirée du "dragronce":

Dans un recoin obscur, vous remarquez une sorte de tête, mi-crocodile, mi-végétale inconsciente et a l'aspect desseché. Vous faites immédiatement le rapprochement entre la texture de son "cou" et celle des lianes qui sortent ça et là de la paroi

 But maybe there could be something that can be grabbed and carried around to produce the same effect. Like the head of a thirsty dragonthorn, since there's water just nextdoor. That would be nice from Bilou to bring them into water. Might be a bit tricky to draw too ... even with pencils, I'm not convinced by those sketches... and it's a bit ... convoluted.

On peut ramasser sa tête comme les autres objets... on peut l'amener jusqu'au point d'eau pour qu'il reprenne des force et que ses feuilles se changent en plate-formes. La bonne nouvelle c'est que ça fonctionne même si le joueur n'a pas encore compris que B=ramasser et pas B=frapper.

Et avec le saut comme mécanique, est-ce qu'il n'y a pas moyen de faire quelque-chose qui soit sympatique ? Disons qu'il y ait une grosse racine qui soit juste un poil trop haut pour profiter de toute cette eau pour grandir, hein ? il suffirait de lui tomber dessus pour l'enfoncer un peu, elle se réveille, elle boit, les feuilles repoussent. C'est simple, c'est visuel, c'est le bon plan. Non ? 

'bin pas forcément si j'en crois mon frangin... lui, en tous cas, il n'a pas franchement accroché à cette approche.

Or maybe there could be something that wouldn't mind being jumped on and yet make the leaves bloom? Like a big fat root just about to reach water? It would actually be friendly and helpful to push it into the water just enough so that it could come back to life, bloom, etc. Well, I thought I had the perfect solution here until my brother seemed unconvinced.

Bon, qu'est-ce qu'il me reste ? En fait, dans le design d'origine, il n'y a même pas ce genre d'ascenseur interactif à mettre en marche. Le frangin, il avait dessiné un tuyau, une chute d'eau alors qu'on est déjà un demi-écran en dessous de la galerie supérieure, une pente-qui-pousse avec l'eau qui dévale et qui nous entraine jusqu'au bassin Est.

Celui qui n'a pas la clé n'avait qu'à penser à aller dans l'eau et prendre le téléporteur si tant est qu'on ait de l'air jusque là ... ou mourir et recommencer.

That brought me back to the original level design from my brother, only to realise that there was just nothing to help you climb back and get the key you need. Actually, he did even put one-way-watery-slope (inspired by Sonic's Labyrinth zone ?) to push the player into dive-or-door decision. If you dive, you'd have had limited time to locate the teleporting device that brings you back overworld where you could try a better route and find that key.

I don't think it could be used as-is in a modern game (and I want Bilou's Dreamland to feel modern) but since I now have waterflow tiles, I could definitely have some spot reachable from the water surface (Bilou can't dive freely in this game) where you're swallowed by a stream bringing you back where the teleporter would have dropped you. I think I'll have that anyway. But not just that. 

Pendant tout un temps, pour la reprise du niveau, c'était hors de question parce que mourir, c'est has been et que l'eau nous fait flotter, pas couler, donc pas question d'aller explorer le fond des choses avant d'avoir débloquer le bon pouvoir (metroïdvania avant l'heure).

Mais là, maitenant, j'ai des blocs qui permettent d'envoyer le joueur à travers un courant forcé ... je peux donc prévoir qu'une petite partie de ce bassin serve de départ pour une trajectoire "remontante" vers l'emplacement prévu pour la sortie du téléporteur "ah ouais. Comme dans Bubsy" ajoute mon frère.. visiblement, cette stratégie-là, ça lui parle. Je tâcherai donc de la mettre dedans, mais j'aimerais quand-même avoir une alternative plus directe pour le joueur qui a envie de trouver la "solution" plutôt que de contourner le problème.

L'avis de Zim: définir l'animation

Deuxième point du feedback de Zim:

Mon conseil serait de mieux faire comprendre par l'animation du perso sa panoplie de mouvement, développer les actions d'attraper et sauter, supprimer celle de frapper (peut-être courir), et de faire en sorte que tout cela soit impeccable (actions qui sortent de manière fiable, pas de bugs de collision, etc.). Un jeu de plateforme est excellent lorsque c'est un plaisir intuitif et immédiat de manier son personnage, il faut vraiment insister dans ce sens.
- attraper en l'air est possible vers le bas (je l'avais compris avec les nuages), mais pas vers l'avant, même si on n'a pas encore ramassé le power-up
- attraper pourrait être boosté en l'action rendant multi-directionnelle (si vers le bas et les côtés, pourquoi pas vers le haut) et également peut-être en augmentant sa portée au moins un peu

Avec ces mains-en-plasticine, c'est vrai que Bilou ne montre pas particulièrement fort ce qui se passe lorsqu'on essaie d'attraper quelque-chose. En relisant les propositions de Zim, je me rends compte aussi qu'il peut y avoir confusion entre ramasser et s'aggripper, qui sont en réalité deux actions distinctes mais proches au niveau du gameplay. Un "air grab" permet de faire l'un ou l'autre selon l'objet considéré. Un "ground grab" ne fait

	Ramasser, premier essai. Trop lent.
	Ramasser, version actuelle. colle bien au hit-boxes de l'action.
	Attraper en l'air, qui se concentre sur la direction "vers le bas"

Pour le "gros poing", la main de Bilou enfle et ne laisse aucun doute sur l'interprétation du mouvement, mais ici, la main utilisée pour "attraper / ramasser" pourrait aussi bien mettre un uppercut. Ma première réaction est "oui, mais le gros poing est un pouvoir spécial. Il faut que Bilou sans ses pouvoir ait l'air de ne pouvoir compter que sur son astuce et son courage".

What if Zim@alexzone and I do not have the same understanding of a "multi-directional" action. I thought so far that 'AIRGRAB' is multi-directional in School Rush, because when you press B mid-air, there are 3 directions checked for something to grab: in front of you, below you, and behind you. Those three areas are supported by the places where Bilou's hand move during the attempt to grab things. But multi-directional could also mean "you pick which direction the action takes place using your d-pad".

This is clearly not the case for air-grab. It would make sense for a wider-range grab, which Zim is advocating for: the animation could take place in a limited area (good for reading), and still reaching further pixels. You could need to do "UP/RIGHT + B" to reach some sponge bop and "DOWN + B" for some others, though.. and time your button press accurately to grab something. In comparison, current GRAB is a proximity action: move your player next to the item to grab and hit when you're close. That's all I require.

Enforcing the direction with the keypad also allows to draw a larger hand, that better conveys the idea that we're grabbing things. Ideally, we could understand what the move does by watching it in the void. Like you check kick and punch buttons on a beat-em-all before you follow the "GO->" arrow for some action. 

A mieux y réfléchir rien n'interdit que Bilou ait déjà le pouvoir de soulever des choses plus lourdes dans ce jeu-ci, qu'il le conserve de façon permanente et que ça se traduise par une main qui devient plus grande quand il veut attraper les choses. Des doigts visibles, légèrement écartés, pour maximiser les chances d'avoir ce qu'on veut... c'est sans doute ça qui exprime le mieux l'action, comme on l'aurait fait dans une BD.

Voyons le côté "multi-directionnel", maintenant. J'ai tendance à penser que le "grab" est multi-directionnel parce que quand je presse sur B, Bilou attrape ce qui est devant lui, sous lui ou au même endroit que lui. Mais ça fait une animation où il est difficile de voir la main. Multi-directionnel pourrait aussi vouloir dire "dans n'importe laquelle des directions choisie" (avec le D-PAD).

Ça représente malgré tout une modification assez importante. Je pense que je vais dans un premier temps essayer que Bilou puisse s'accrocher par-dessous une éponge (y compris lorsqu'il la touche par le côté) avant de commencer à faire ce genre de changement.

Air Grab

On s'approche, on s'accroche ... Les travaux sur les zones de collisions contrôlées depuis l'éditeur d'animations portent enfin leur fruits. Il y a maintenant un état dédié dans le comportement de Bilou pour "je pirouette en l'air pour attraper quelque-chose".

At last, the track for controlling hitbox activation through animation is paying off. I have been able to give Bilou a dedicated state where he's checking three directions for something to pick or ride on. I intend to use that both to ease swinging on spongebops and allowing high-paced dumblador grabbing. In the "anniversary level", using spongebop to move along was planned as the hard path. The way that the skilled player would prefer because it leads to faster results as opposed to wandering on the ground. They still had that role when I added "*deline's level" as preliminary experience to the "true level" of the school zone, but the levels are definitely more fun to play when you mastered spongebop riding (left alone the 'sponge jump'). So I want to make more players try to use them.

• Dedicated "grab-mid-air" animation and gameplay state makes it obvious to the player that something happen, and how it spans in space-time.
• The animation itself is fun. J.l.n, my 2-year-old boy goes laughing when he realize he can press A/B buttons to make Bilou roll mid-air in a flash. And fun is important in a video game: that's our primary reward.
• Moving from demanding hitbox (purple one on picture below) to welcoming hitbox (light-blue one) will make it more open to learning.
• You'll still have to learn how your speed evolves with the swing if you want to reach high places or gain stupendous momentum. The potential for power-play is not lost.

Au-delà de la performance technique, l'idée est d'agrandir la marge de manoeuvre des joueurs qui veulent s'accrocher à une éponge. J'ai tenté de reporter sur l'image ci-contre la marge de manoeuvre avant (en mauve) et après (en bleu clair). En rendant le fait d'attraper l'éponge moins élitiste, j'espère -- selon les conseils de KirbyKid -- les rendre aussi plus amusantes.

Une chose, par contre, n'a pas changé: Bilou est toujours centré au-dessus de l'éponge quand il s'y accroche. Du coup, agripper une éponge alors qu'on arrive à côté d'elle produisait un décalage brusque de Bilou. Je tente donc un élément inédit dans le gameplay: une transition pendant laquelle Bilou, roulé en boule pirouette pour revenir par-dessus l'éponge mais dans une forme de pilotage automatique. Il est déjà lié à l'éponge et se dirige automatiquement vers elle, même si elle fait demi-tour et s'y accroche dès qu'il entre en contact avec elle.

I had one concern, though, about the immediate coordinates update that makes Bilou appear centered on top of the spongebop immediately after you hit its side with your hand. Piet and Pierrick, both co-author of the very first Bilou game, suggested that I should "cheat a bit with physics so that the game gets easier for the player", but I'm not confident with such approaches. Yet, it wouldn't be fun to get merely a bounce if you hit the spongebop from the side when trying to grab, so I give a try something new in Bilou's behaviour: temporary automatic control. When you'd expect Bilou to grab and climb the spongebop, he'll actually do it by a rolling bounce in the air where he'll mag(net)ically align to Spongebop position and start riding when reaching the proper position. Accelerations faster than what you could reach manually are tolerated in this state, and all you have to do is hold the (B) button down and hope for hitting no ceiling.

I'll submit that to the S-testing team tomorrow. That may be the biggest improvement since the release of "School Rush" game. Stay tuned.

Les limites du GobScript

Ramasser des éponges alors qu'on pouvait déjà ramasser des tailles-crayons ... ça n'aurait pas dû être aussi difficile que celà n'a été. Le fait que les objets soient numérotés plutôt que nommés empèchait toute possibilité de détecter les erreurs. L'autre, c'est que le copié-collé est le seul moyen de réutiliser une région substantielle de code.

Current GobScript is meant to be human-readable bytecode for the state machine. Yes, truly. The most obvious way to realise that is how everything is *indexed* rather than *named*. The upgrade introducing C pre-processor in the make process to avoid code duplication in the behaviour script has been generalized to all monsters of the School Zone.

Yet the recent modification of these behaviour show that it becomes quite tricky to maintain coherency when adding new features. For instance,

• [done] picking up spongebops was missing triggers and repeated bugs about stuck carried GOB when hit.
• [done] Pendat rushing don't hurt Bilou when stomping him because I haven't copied hitboxes when creating the new state
• [done] Stomp-and-grab blador in one move kills Bilou's horizontal speed and creates bogus camera conditions.
• [done] We may enter walls when trying to pick something on the ground, because of a missing 'stopper' micro-controller
• [done] stomping a blador while doing a air-grab allowed to move through because of a missing hitbox.

All this claims that I should now work on a higher-level language for editing, where I could express that "SpongeBop allows carry_me" and "blador allows carry_me" and that would imply some new states added to state machines, specific hitboxes in other states, transitions and such. Don't be surprised if I take that excuse to practice some Haskell, as there is currenty a professional incentive to master that language.

Je me vois mal utiliser les macros du pré-processeur C pour reproduire un motif du genre "une zone de collision dans l'état X permet de passer dans un état $CARRIED puis dans un état $THROWN jusqu'à ce qu'on heurte le sol, ce qui nous ramène dans l'état Y." par la seule ligne "using CARRY_ME(X,Y)" ou quelque-chose de ce genre. Dans le meilleur des cas, celà reviendrait à définir CARRY_IN=X et CARRY_OUT=Y avant un #include "carry_me.cmd.h" ... pas franchement le plus élégant, mais sans doute préférable à une duplication du code...

Ne vous étonnez donc pas si je prends le prétexte d'un convertisseur d'une version "maintenable" du GobScript vers sa version "machine" pour mettre un peu d'Haskell en pratique dans les prochains mois, hein ;)

Le bon tempo

J'essaie de rendre les manipulations de taille-crayons plus dynamiques. Quelque-chose qui soit plus adapté au gameplay du "school rush" ...

Compared to "Anniversary Level", the tempo of the game has quite evolved. Current animation of Bilou grabbing something on the ground with his eyes going "whoo! Look what we've got here" doesn't fit the action anymore. With the ink rising and pushing pressure, having to stop on a blador to GRAB it is a pain. It would be neat if we had the opportunity to grab it on the fly, just after we stunned it. That the best I can think of to "make things snappy".

J'utilise la nouvelle fonction "édition des zones de contact dans AnimEditor", mais ça n'a pas encore l'air très au point ... entre les dumbladors qui s'envolent quand je tente de les ramasser, les animations qui s'interrompent prématurément et les éponges qui glissent des mains de Bilou. Ce serait sans doute une bonne idée de prévoir une amélioration de l'InspectorWidget pour permettre de visualiser ces changements de zones de contact.

Yet, things are not quite working as expected

• [done] Bilou may stomp-and-grab a dumblador in one jump
• [done] why is left-grab not playing ?
• [wish!] how could I end up with an editor that damages animation when opening them ? I need unit testing here.
• [done] bladors should skyrocket when I try to grab them.
• [todo] why do I have anims with over 10 'control: done' statements ?
• [done] make sure InspectorWidget can report areas masking.
• [done] do not flash colors when holding L in InspectorWidget, please.
• [think] export over WiFi has become too complicated. Plan a multi-connection approach

Unrelated (except for timing) todo items:

• [done] allow meta-information about tiles (rules.gam) to sit in a separate file, included by level scripts.
• [todo] allow spawn point (and possibly spawned GOBs) to be modulated by some global game variable (checkpoints, difficulty settings, etc.)
• [think] a simple map editor for PC would be better suited to those "surgical edits" required in current development cycle. That or easier-to-upgrade runME with the cycle moving back to DS device.
• [done] print and deep-review todo items to establish battle plan for 2015.

GobAnim::isJedi()

jump, twist and roll!

That's quite amazing, how I manage to postpone an upgrade of the game engine for days and then have two of them implemented in a couple of hours simply because I used doxygen-on-cybook to brief myself on what's around and what is the most straightforward path for implementing them. I have now a way to instruct that a specific transition animation has priority over the running one, which is mandatory for your "air-grab" to have any visible effect when you're turning back or reaching the top of your jump -- in a word, for a consistent behaviour. It also allowed me to give "float-land" a first attempt.

Et voilà: j'ai pu indiquer que certaines animations peuvent "forcer" la main à certaines animations de transitions, comme prévu, mais plus facilement grâce à mon cybook-qui-garde-mon-code-sous-la-main. Comme quoi, je ne regrette pas son passage par le service-après-vente ;). Du coup, on peut déclencher l'animation "attraper en l'air" à n'importe quel moment. Je me suis aussi amusé à modifier l'autre "pirouette en l'air" pour lui donner un aspect de "je descend en planant", même si on ne peut pas dire que Bilou soit un très bon planeur jusqu'ici. Il faudra voir ce que ça donne avec une vraie DS en mains, par contre. Au clavier desmume, c'est assez moyen et on commence à bien s'embrouiller entre la course, le saut, le grab et la pirouette/vrille...

Allez, si ce n'est pas encore fait, profitez-en pour voter pour votre power-up préféré ;-)

catch this!

A new animation and a good deal of "sprtools" to merge pixels drawn on "lime" DS and animations built on the DSi ... Unfortunately that will not be enough. There's one "dead" moment where you cannot see the "grab-in-the-air" animation whatever you do: when Bilou reaches the top of his jump. The reason is that there's already a "transition animation" running at this time, and that there is no way so far to cancel such an animation for another. I may have to fix that before I can proceed any further: it will likely be very important for super powers.

Une nouvelle animation, quelques coups de sprtools pour fusionner les pixels dessiner sur l'une des DS et les animations présentes sur la DSi. Eh pas de bol: ça ne suffit pas pour avoir un mouvement 'attraper en l'air' qui rendrait le gameplay de SchoolRush plus fluide. En fait, ça marche presque tout le temps sauf lorsque Bilou est au sommet d'un saut. La faute à l'animation de transition qui s'active à ce moment là: le moteur de jeu n'a pour l'instant aucun moyen 'd'annuler' une animation de ce genre. Je vais aller corriger ça, parce que ça risque d'être critique pour les coups spéciaux.

• [done] "force" flag to override transition animations
• [done] make "grab" a dedicated state
• [done] edit areas directly in AnimEDS
• [done] import AnimEDS areas in GOB states
• [done] selectively activate/deactivate areas in AnimEDS

Kirby Kid's Advice: Inconsistent Spongebop

Inconsistent interactions with yellow things. The yellow swinging enemies are neat looking and they have neat physics to them. But interacting with them is very inconsistent and too complicated. It's hard to stay on top of them. It's hard to get the big jump off of them. And the momentum of their swing doesn't transfer to the player at all.

Let's first see what "inconsistent" means in this context. Kirby Kid validated the two definitions I formulated as below:

A mechanic is consistent with regards to 2 object if

• applying it the same way on the two objects leads to the same result. E.g. slashing something with the sword breaks it into bits in Zelda series. That works on bushes, jars, skulls and even rocks in some games.
• when it leads to different result, the objects shall be sufficiently different so that the player can easily tell what result it will get from passive analysis of the object. E.g. Jumping on an ennemy in SMB always attacks the ennemy unless the ennemy has spikes on his head. Moreover, the ennemy will always be defeated unless it is shelled.

A gameplay element (applying mechanic A on object B) is self-consistent if

• it always produce the same result (e.g. bounce by 3 blocks height)
• when producing different result, the player can relate the cause of this difference to visible difference of state. E.g. a spring that may be loose or compressed will throw you higher if compressed.

Pour corriger mon éponge-qui-se-balance, aussi connue sous le nom de "Spongebop" ou "Bop, l'éponge", je vais avoir un peu plus de mal. Kirby Kid lui a diagnostiqué un problème de manque de cohérence, ce que je peux traduire de la façon suivante: il n'existe pas de manière claire de savoir quel sera le résultat d'un rebond ou d'un balancer qui fait intervenir l'éponge. Kirby Kid mentionnait aussi le fait qu'il est difficile de déterminer si l'éponge va nous repousser vers le côté où si on va pouvoir atterrir dessus. La difficulté principale sera psychologique: dès les premiers coups de crayons, "Bop, l'éponge" est un personnage (et pas une plate-forme) au comportement erratique. Il sera utile, mais il faudra s'en méfier.

From the start I have designed spongebop to be somewhat chaotic, which makes it appear mostly only on the "hard path" of School Rush game. But chaotic must not mean "totally unpredictable". There are two moves that are expected with a sponge bop. The first is to use it to gain height, the other is to clear a larger distance with a jump. Both are based on the fact that, when you press A while un-grabbing a SpongeBop, its current velocity is added to the one of your jump.

Initially, I thought Kirby Kid was mostly criticizing the difficulty to do the first move -- gain height -- because when SpongeBop is  almost idle, the only moment when you can "jump off" is when it moves upwards. But getting that is more a matter of luck than skill: because oscillations of Spongebop across its equilibrium are small and that the "auto-bounce" that happens when you "land" on it can hardly be controlled, the best you can do is to try again and again until it works. You cannot even spam the JUMP button because you'll have to hold it down once successfully bouncing off if you don't want to cancel your jump.


Voyons un peu les interactions que permettent Spongebop:

• SB peut pousser Bilou bas d'une plate-forme ou l'interrompre dans son saut si le contact est latéral. Incohérence: c'est un rectangle qui nous repousse alors que SB est un patatoïde protubérant.
• Bilou peut rebondir sur SB s'il tombe dessus et rebondir plus haut s'il appuie sur (A) avec justesse. Incohérence: il est difficile de déterminer la hauteur qu'aura le saut effectué dans la plupart des cas.
• Bilou peut s'accrocher à SB pour franchir plus facilement un trou. Incohérence: il n'est possible de s'accrocher que lorsqu'on tombe, et pas juste après un rebond malencontreux.
• Bilou peut faire un long saut en avant en appuyant sur (A) au moment précis où l'on lache l'éponge. Incohérence: rien n'indique pour celui qui n'a pas encore suivi de cours de balistique (ou fait trop peu de balançoire) que la fin du mouvement est un mauvais moment pour cette manoeuvre-là.

 I've been more surprised to see Pierrick failing to clear a large jump by using SpongeBop's swinging speed. He was persistantly trying to jump *at the end* of the swing, but physically speaking, bop's momentum is nul at this time. So indeed, it doesn't transfer to your character.

The way Spongebop behaviour lacks consistency can be summarized as such: when you jump off a Spongebop, the velocity you have will depend on Spongebop's instant velocity. Due to its physics, Spongebop velocity is constantly changing in 2 dimension, meaning that it takes some careful study (or prior knowledge) to pick the moment where you'll get the desired behaviour.

Spongebop Rodeo

I now have a (partly-)working prototype where Bilou can grab a Sponge bop and stay hooked while swinging, but I have to hard-code the offset between Bilou and the Sponge as arguments of the copycoords controller. Not so elegant. Plus, if I also allow to grab on Bladors (granted, that's a silly idea, but it helped for debugging :), those offsets are no longer correct and we're rather grabbing some point in the air over Blador's top-right corner >_<

Bien. Bilou peut maintenant s'accrocher aux éponges en balance. Il y a encore des soucis non résolus avec l'animation prévue à cet effet (d'où l'absence de démo jusqu'ici) et un désagrément mineur: il m'a fallu ajuster à la main et préciser dans les paramètres du comportement "accroché à X" la position relative de Bilou et de l'éponge. Au moment d'ajouter le comportement "assis dans un encrier", ça me démange un peu.

I initially had plans for making those "grabs" act on an are, and it would make sense to actually state "copycoords(a.bottom=b.top ; a.center=b.center)", but I've just said that accessing GobAreas within a controller isn't practical.
Expressions handling a collision have access to some extra-context variables (wc-wf) which were just involved in that "repel" behaviour that made inkjet "solid".

• xcontext[0] - wc -- collision flags
• xcontext[1] - wd -- unused (0)
• xcontext[2] - we -- X-axis center-to-center distance
• xcontext[3] - wf -- Y-axis center-to-center distance
• xcontext[4] -- not in GobScript - X-axis area overlap
• xcontext[5] -- not in GobScript - Y-axis area overlap

 The idea would be to use some GobScript to compute/force the desired location, possibly record it in some GOB variables and have the CopyCoords controller simply enforce that offset from the GOB variables.

Il y aurait bien des solutions techniques pour automatiser ces coordonnées relatives en "alignement vertical, centrage horizontal", à la façon des éditeurs de diagramme ... il y aurait même un "chemin de moindre résistance" pour construire ça dans le contexte actuel. Mais soyons honnête: ce n'est *pas* un élément nécessaire pour le programme. J'ai un seul objet auquel Bilou puisse s'accrocher de la sorte (l'éponge) et je dois de toutes façon utiliser une autre animation pour Bilou-dans-l'encrier (donc, autre état et autres paramètres). Ce serait donc de la généralisation intempestive et prématurée! Caramba! Ça le ferait pas!

I could thus extend the "interaction opcodes":

• A[p]: attach [with path] evaluating object to context object (works in hit and found)

D: detach evaluating object (works in any transition)

R[xy]: repels context object away from the evaluating object (works in hit and found) [only along x/y axis]

L[xy]: line up the evaluating object with context object (mirrored repel)

C[xy]: center the evaluating object with context object (wish)

Now, let's be honest. That's a "wish", not a "todo". I only have one grabbable ennemy so far, and only Bilou grabs it. "hard-coded" offset are just fine in that context, and alternative are "premature generalization". I thought about all this because I'll also need a "copycoords" when Bilou sits in an inkjet, but that will be another animation and another state, so other copycoords offset is just fine.

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.

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.

Mechanics (t.a.g.)

This is a term I borrow from Kirby Kid -- aka Richard Terrel.

Mechanics are the player initiated actions from controller inputs as designated by the game designers. These actions have effects on the gamestate in terms of the variables and dynamics of the gameplay system

.

In fact, if we consider that gameplay is the part that defines and rules interactions between game elements based on user inputs, mechanics are actually atomical element of the gameplay.

Une mécanique de jeu, ça va être un élément atomique de gameplay. Et le gameplay, c'est l'ensemble des règles déterminant les interactions entre les éléments du jeu sur base des actions de l'utilisateur. Oui, je comprends: ça paraît très formel, mais c'est justement l'idée derrière l'emprunt de ces termes à Richard Terrel: permettre de formaliser le discours sur un jeu. Dans mon cas, je fais principalement des jeux de plate-formes, donc mes mécaniques principales seront 'sauter' et 'courir'. je leur donne des tags dédiés. Je les note en Anglais et en majuscules (JUMP) quand je veux vraiment dire 'la mécanique du saut // le fait que le joueur pousse sur le bouton de saut pour faire sauter le personnage'.

I'm mostly building platformers here, so my primary mechanics are JUMP and RUN. I can modulate them with FLOAT. I don't quite have a shooting or fighting character, but it instead GRAB and THROW things.

As you have noted, I use all-caps when I want to obviously refer to gameplay actions (mechanics) within the text. I promise I won't shout too much.

Readme: KK: Mechanics & Abstractions (p.2)