Signets et attach

J'ai pour la SchoolZone l'intention d'introduire des signets/marque-pages qui pendouillent... on pourrait s'y accrocher (indispensable), grimper, descendre (sympa) et ils réagiraient comme des cordes plutôt que comme des barres.

J'ai appris dernièrement qu'il fallait que je prototype ce genre de choses dans l'environnement des "three rooms" sous peine d'être démoralisé par le côté "nu et inintéressant" d'un niveau à peine commencé. Et coup de bol, il y a un coin de la salle "école" qui conviendrait bien : le haut. On pourrait atteindre les signets en utilisant la gomme et s'en servir pour rejoindre l'éponge, un peu compliquée à utiliser pour l'instant.

Hanging to a rope-like bookmark, using it to swing around and hop to the next ... that's clearly something I'd like to bring into the school zone and I may have just found the right way to introduce it first in the "three rooms" demo. Yes, I could use one of the levels in which they are featured, but recent development on the green zone shown that a rushed large level doesn't motivate me as much as a small polished screen can. They would be there, in the top corner and providing an alternate way to reach the swinging Spongebop.

Avant de permettre de s'y accrocher et de se balancer, je voulais voir comment m'y prendre pour une interaction plus simple: juste laisser Bilou bousculer le signet et qu'il ondule un peu en reprenant sa place. J'ai le comportement "circular" qui pourrait être pas mal pour ça.

Before I'll let Bilou grab them and swing, I'll have to start with something easier, like just having Bilou disturb them and make them swing stronger when passing nearby. It should be a mere matter of attaching segments to one another with the "circular" controller... except that once Bilou pushes the bottom part of the "rope", segments now need to lookup two objects instead of just one. And that's a bit more tricky to handle for my engine that only allow one object pointer per object.  

Sauf que on tombe dans le cas de figure compliqué où les mouvements d'un segment dépendent à la fois de la position du segment au-dessus et en-dessous de lui, ce qui pose trois questions:

• Est-ce qu'il faut que j'ajoute une zone "solide" à Bilou ?
• Quels flags (pour les collisions) sont disponibles pour ajuster les comportements (j'ai oublié ^^") ?
• de quelles infos est-ce que je dispose après une collision entre deux segments ? Est-ce suffisant ? 

J'avais pensé relire le tag "attach" pour me rafraîchir la mémoire, et j'ai eu la désagréable surprise de le trouver confus, avec quelque malheureuses infos pratiques perdues au milieu du "gamedev story". Il est devenu mon "tag de la semaine", mais j'ai dû reconnaître que ça ne suffisait pas. Je me suis retrouvé à essayer de l'extraire avec les outils "blogpress" et lui appliquer une feuille de style avant de l'utiliser pour tester les "pages web codeberg".

So, that was the idea back on 11/11 when I sat down with my notebook and collected the questions that needed answers before I could get to the coding stage. I thought unrolling the "attach" tag of the thread would give me answers, but it turned out the useful information was somehow lost into trivias, screenshots and other progress reports. And the code documentation wasn't much better, so I ended up restoring a setup for blogpress and tutogit at the same time, uploading them all on codeberg and see whether I could apply simple.css etc.

ça m'a donné le déclic pour reprendre le travail sur le repository "tutogit", en plan depuis 7 ans, vu que maintenant le nouveau système de gestion des propriétés du niveau est arrivé à maturité. Je pense que ce serait là le bon emplacement pour des pages thématiques présentant chaque élément du moteur de jeu ... qui puisse au final s'intégrer à la documentation doxygen. Voilà déjà celle pour attach.

climbing ... manuscript notes.

Quelques notes qui datent de février 2013 et qui refont surface pendant les habituelles chasses de paperasse de début juillet: comment s'y prendre pour que Bilou puisse se balancer aux signets de la school zone.

J'y note la recommandation que les morceaux de signets soient passifs dans la collision et un peu de math pour déterminer si une zone de collision classique croise ou non une "ligne" de collision, qui conviendrait mieux pour les cordes qui pendouillent.

Par contre, je ne sais pas trop dire si j'avais prévu que le signet soit fait d'un seul Gob avec une zone de collision pour chaque élément ou de plusieurs gobs ... la pages avec les lapins vont plutôt dans le sens "un seul gob", chose que le moteur "Dreamland" ne saura pas encore gérer, je dirais.

On y trouve un

state% : 3D.% {
  using RopeController;
  segment [*] F_ROPE;
}

pour un nouveau type d'objet basé uniquement sur du rendu 3D. Le fait qu'on indique des collision pour chaque segment renforce l'hypothèse d'un seul GOB composite d'un nouveau genre. On lit d'ailleurs, sur la première page

foreach (@segments):
   if (b.ymin > s.ymax || b.ymax < s.ymin) continue;
   if (s.dx * s.dy >= 0) {
     // depending on the rope's direction, there's 2 corners of the bbox to check
   } else {
     // test the other two, I presume :P
   }
   

Et une observation que "bah, peut-être qu'une verticale plutôt qu'une ligne oblique, ça ne gènerait pas tant que ça dans la plupart des cas. 

Bref: c'est confus, même pour moi, mais je veux l'avoir sous la main dans le même tag que les autres

Hi English readers. These are manuscript notes from about 12 years ago, when I first tried to figure how to deal with swinging bookmarks that you could catch and climb to. They're a bit confused and I'm unsure even I understand what's being said there. But I've got bookmarks and climbing goal revived for Bilou's Dreamland, so I'd rather have these notes around when I'll think about it. The code snippets I typed above suggests that bookmarks were intended to be a new type of segmented 3D object, which has been dismissed for the Dreamland engine

Swinging animations

Plus le design de Bilou: Dreamland avance, plus la possibilité de s'accrocher et se balancer prend de l'importance dans le gameplay envisagé. Et c'est tant mieux sauf pour une chose: mon moteur d'animations est actuellement très mal adapté pour ce genre de chose. Comprenez, on risquerait plus de se retrouver avec quelque-chose de raide comme Mickey Magical Quest plutôt que les mouvements souples de Fury of the Furries. Ce serait d'autant plus dommage que Spongebop ne souffre pas de ce genre de limitation et que ça rend furieusement bien. Mais voilà, l'image de Spongebop est indépendante de l'angle de sa corde.

The more I sketch some design ideas for Bilou: Dreamland, the more swinging with a rope-like object occurs. I won't claim it will be a primary game mechanic, but it will certainly be an important one. There's just one drawback : so far my game engine offers no support for that kind of animation. Oh, sure, I could go the Mickey Magical Quest way of hard-coding a few frames and the positions Bilou should take to swing, but given that I have a freely-swinging Spongebop in the previous game, I'd prefer go for something like what I've enjoyed in Fury of the Furries: game physics that allows 360° swinging, with free positioning anywhere on the circle defined by the current rope length and almost free extension / reduction of the rope length (Mickey can only climb).

Pour Fury on a pas moins de 36 images différentes et la possibilité de faire un tour complet de son point d'accroche si la physique le permet, soit 10° entre chaque image. Mickey n'offre que 7 images différentes pour un angle de balancier de 90°, soit 15° entre chaque image. La différence devrait être légère (on passe quand-même de 60 fps à 40 fps avec un rapport pareil), mais là où ça change tout, c'est que les angles de la corde elle-même sont discrets à 15° près avec Mickey, dû au fait du hardware 'par tiles' de la super NES. Du coup, les positions de Mickey deviennent elle-même discrètes (bien qu'il puisse remonter sa corde). 

Je me suis donc repenché là-dessus pendant mes p'tites vacances, à l'abri dans mon épave de bateau pirate et j'ai peut-être bien une solution. L'idée serait de compléter les deux modes d'animation actuels (l'un qui suit une ligne du temps, l'autre qui colle à une série de déplacements) pour faire un système dans lequel on va choisir d'avancer ou non dans l'animation selon le vecteur-déplacement actuel. En gros, je fais une animation dans laquelle Bilou se balance autour de sa main et le moteur passera à l'image suivante quand Bilou va dans la même direction que celle suivie par cette image dans l'animation.

The summer idea about it was to handle that with a new way of playing back an animation: rather than enforcing a delay between two frames or a specific motion, we would compare the in-game speed vector (xg, yg) against inter-frame motion vectors (xa, ya). You'd then step to the next frame in the animation only if (xg, yg) is "beyond" the expected motion to the next frame. A bit of maths done in a sandbox (literally) shown that we can tell that just by two integer multiplications per frame. It will need separate animation for swing-to-the-left and swing-to-the-right, but I'm perfectly fine with that.

Mais comment savoir si un vecteur effectif (xg, yg) est plus proche de l'ancien vecteur de l'animation (xa, ya) ou de celui de l'étape suivante (xa', ya') ? Je suis parti de mon vieux cours d'analyse math avec "l'extrémité du nouveau vecteur (xg, yg) doit être au-dessus de la droite définie par k*xa' = k*ya' (que l'on peut réécrire y = (ya' / xa') * x). Mathématiquement parlant, on sera au-dessus si yg > ya' / xa' * xg. Programmatiquement parlant, c'est moins drôle, à cause des divisions par zéro dans les verticales et du manque de précision des divisions / multiplications quand on se contente de travailler avec des nombres entiers. J'ai donc voulu ruser et faire un peu d'algèbre pour passer à yg * xa' > ya' * xg, qui ne fait que des nombres plus grands que 1. En fait, je venais de retomber sur l'expression de l'aire signée d'un triangle, bon vieux truc du cours d'algo II à l'unif (merci, feu PAdM). ça tombe bien: elle sert justement à calculer si un point est à gauche ou à droite d'un vecteur donné.

Il faudra vérifier expérimentalement si je dois modifier le sens de l'inégalité pour le balancier-retour, trouver un moyen d'intégrer ça au scripts (probablement avec un 'speedmove' comme on a déjà un 'selfmove'). La bonne nouvelle, c'est que le même système pourrait probablement marcher aussi pour une voiture vue du haut, des segments de lianes qui se balancent et segments de ponts qui s'inclinent :-P

extra bonus with the anim.x * gob.y > anim.y * gob.x expression, is that a faster motion (e.g. longer rope) or a slower motion (e.g. shorter rope) will not affect things, because it would affect both gob.x and gob.y by an identical factor k and thus their effects will compensate in the comparison.

Les Capris et tutti quanti.

Avec les enfants qui veulent aussi jouer, les niveaux plus longs et une fonction "prendre une vidéo en jouant", je suis moins tenté sur Switch de mettre mon jeu en pause et de commencer à parler/redessiner quelque-chose. Quand je le fais quand-même, c'est souvent pendant que les enfants jouent, et donc des petits schémas techniques griffonnés plutôt que des croquis.

Mais l'an dernier, j'avais quand-même pris le temps de passer en revue mes vidéos de Donkey Kong Tropical Freeze pour voir un peu ce qu'il y avait de particulier comme type de plate-formes mobiles (avec évidemment la Peaks Zone en tête).

C'est aussi vers DKTF que je me suis orienté il y a quelques jours pour essayer de trouver des idées de 'niveau aérien' et c'est en voyant la tempête du niveau 3-3 emporter tout et n'importe quoi que j'ai réalisé que "bah, en fait, j'ai pas besoin de me creuser la tête pour trouver des animaux succeptibles de faire plate-forme volante: il suffit que je dise qu'il y a des courants d'airs et que je trouve des choses assez légères pour se faire emporter. C'était le premier "débloqueur".

Puis en bas de la feuille j'ai commencé à dessiner ces arbres tout tordus et leur branche m'ont donné envie de tendre des cordes entre les deux pour que Bilou puisse passer dessus. C'était l'élément de level design qui m'avait manqué jusque là.

It's been 2 years since I decided to have a 'mountains peaks zone' for Bilou's Dreamland, and even before that, I had ideas to use sheep/goat-like monsters to populate it (plus birds). But none of this led to any monster design or level design post. I just couldn't come up with anything to draw. Hopefully, it changed lately. It all started with a funny tree I draw on a sketch while collecting gameplay ideas from Donkey Kong: Tropical Freeze videos (and other possible videos about 'air world', btw). It had hook-like branches, with no leaves on it. It was appealing for a string bridging from one to another. It felt natural that Bilou would use that string to move from one place to another when there's nothing 'floating' inbetween...

I tried to imagine what could prevent him from doing so. Like a tightrope dancer. I tried to recycle my goat-idea and had fun giving it a Ice-Kirby pose. It seemed to work like magic. It's not an evil opponent, just someone who happens to be dangerous for you, in this case because you happen to have missed that you're on a circus-training area. The idea was working well, so it was time to pick up proper pens, proper paper and start drawing that for real.

Une fois la corde tendue et Bilou accroché dessus se posait la question: qu'est-ce qui pourrait le mettre en danger. J'avais depuis longtemps l'intention de mettre des espèces de bouquetins dans la montagne. Une influence du premier Rayman.

Ça s'est mélangé dans ma tête avec une posture de Kirby-patineur avec son pied en l'air. Ah, ce serait tellement plus facile pour Bilou s'il avait une formation de funambule ...

Mais pour un bouquetin, ça devrait être un jeu d'enfant, non ? Une fois cette idée dessinée, je savais que je tenais le bon bout.

Restait à voir si tout ça est assez "Bilouteux". J'entends par là, est-ce qu'on se sentira sur la planète des chauve-souris-baies et des crayons soldats ? Les rochers troués comme du gruyère sont rigolos, les arbres sont bien quand ils sont nus mais un peu plus classiques avec leur look de palmier quand ils ont encore leurs feuilles.

Probablement que Joke trouverait que tout ça manque de champignon. Alors j'ai repris mon dessin et j'ai gribouillé des chapeaux de champignons par-dessus tous mes feuillages d'arbre. ça marche. c'est même ce que j'ai de plus convainquant pour justifier les "feuilles parasols" servant de plate-formes volantes. Alors allons-y: ce seront des hybrides arbres/champignons dont le chapeau se laisse emporter par le vent pour aller disséminer plus loin une fois qu'il est bien mûr.

So I started drawing all the stuff I had barely sketched so far, leafless trees, ropedancing goats, watching goats, large flying structures brought up by upwards winds ... a bit too big for a single leaf given the trees size. You'll notice that this early sketch also features sorts of 'beaks' within the rock. That's something I had noted to lead to interesting look, but which doesn't seem to work well with the 'cheddar-holes'. And I definitely want to keep cheddar holes :P

Later on, on a walk, I realised that a pal known as 'the BilouMaster' would likely suggest that the scenery needs more mushrooms. So why not claim that those trees have mushroom-like tops instead of leaves ? That would give me free 'floating platforms in upwards winds', free umbrella-like thing to hold while a goat is ropedancing and contribute to the overall 'Bilou, not earth' feeling of the area. I overdrawn my sketch a bit .. it seemed to work. I kept it.

A ce stade, j'ai repris ma liste de plate-formes spéciales dans DKTF. La première, c'était une plate-forme qui se met en mouvement en fonction de la position de DK sur la plateforme: à gauche, elle part à gauche; à droite, elle part à droite.

ça marche impeccablement avec un chapeau de champignon. En fonction de la hauteur des colonnes d'air, de leur intermittence ou non, je peux construire un niveau aussi varié que la traversée en montgolfière de DKC2.

DKTF propose un joyeux nombre de variations sur ce thème, avec de l'électricité ou des plate-formes incomplètes, mais une des plus remarquable, c'est peut-être celle qui la combine avec la mécanique "s'accrocher" introduite dans Donkey Kong Returns.

Ça tombe bien: j'ai justement envie de faire de "Dream Land" le jeu où Bilou peut justement s'accrocher à tout et n'importe quoi. aux branches des arbres, aux racines souterraines, au cous des bestioles qui infestent la pyramide ... Et évidemment aux cordes des ponts de cette nouvelle zone.

Alors du coup, ça nous donne une manière bien plus intéressante d'utiliser la combinaison 'une corde transportée par deux oiseaux: Bilou au centre, les charges sont réparties et la corde s'élève emportée par les deux oiseaux. Si on se décale d'un côté, ça augmente la charge pour l'oiseau correspondant et on dévie de ce côté tout en descendant lentement.

It felt like it was the right time to pick up my never-blogged list of original kind of platforms in Donkey Kong: Tropical Freeze, and see whether I could match them with things that would work in the newly defined Peaks Zone.

A platform that starts moving left or right as you move to its left or right, for instance. That could be a floating mushroom top. Another one where you're hanging instead of landed ? Well, since "I don't see why Bilou wouldn't use the ropes" would work well here too. When there are just 2 birds and one rope, they're just strong enough to lift him if Bilou's weight is equally distributed. Otherwise, you'd dift in one direction (and slightly slide down).

Mais revenons à nos bouquetins. Un autre petit schémas de plate-forme que j'avais dans mon cahier montrait une bascule avec un obstacle à pic passant d'un côté à l'autre.

Alors bon, on ne va pas vraiment commencer à rajouter des boules à picots ici (je n'ai pas les fruits géants de DK pour le justifier), mais dans la catégorie 'obstacle à roulette', je peux profiter de l'idée "font leur cirque pour introduire un autre type d'acrobate.

et le voilà. Irrésistible. Adorable mais redoutable.

Can the new goats also be used in some DK-like platform mechanics ? Sure! There was one about a platform that tilts back and forth and makes a spiky hazard roll left and right along with its movement. We can sure find something that rolls in a circus setting, right ? Just add a happy goat/sheep thing on top of it and voilà.

And while I was telling all that to my brother, I've got a flash-vision of happy goats appearing from the bottom of the screen as if there was a hidden trampoline and you could make your way by carefully bouncing from one goat-back to the next. 

Puis en racontant tout ça à mon frangin hier me vient l'idée d'un passage où on voit tout simplement des bouquetins surgir du fond de l'écran, faire leur petite pose et retomber. On doit passer à dos de 'mouton' pendant ce temps-là.

au moment de le dessiner, vu que je n'ai pas de "fond d'écran" pour masquer ce qui se passe, j'ajoute à nouveau une corde. il rebondissent dessus comme sur un trampoline. Un clin d'oeil à Sleepwalker.

Autant dire que ça aussi, il vaudra mieux que ça n'arrive pas pendant que Bilou est suspendu à la corde.

Of course 'a hidden trampoline' isn't something easy to draw, so I replaced it by a string. A string you should better not try to use because you can't hold to a strumming string. There were more platforms styles in DKTF, of course, like that giant flower that starts bending when you lose its center, but there's already a good deal of things to implement here, isn't it ?

Il en reste, évidemment. Je n'ai pas essayé de convertir les fleurs géantes qui basculent, celles qu'on déplie en se suspendant à un truc qui pendouille ni les tours de plate-formes qui s'enfoncent (et donc se déroulent) quand on marche sur l'une d'elles. Mais bon, je crois qu'on peut dire qu'il y a déjà de quoi voir venir, non ?

whipseey

A lovely setting, charming character, platforming action in pixel art, and above all, a "whip/ninja rope" mechanics I'm in love with since Fury of the Furries and Mickey Magical Quest. You bet I'm following @whipseey in his quest recovering the Lost Atlas ^_^. And the fact it is drawing inspiration from the legendary Mr. Gimmick is just the perfect spice to complete the gift.

Yet, while watching I realised that one of the sceneries had an issue that also existed in Bilou School Rush and that was pointed out by Kirby Kid when he gave feedback on the early version of the game: one-block-wide pillars.

You have a lot of "one block wide" or "character width wide" platforms. I find this irritating. They put a lot of stress on the mechanics and they also slow down the gameplay a lot. Open the platform spaces up some more.

 For the untrained player, these will put strong stress on the player's knowledge of the game engine's intimacy, like how much exactly gravity and momentum there is, so that one can land her favourite pink avatar on such a tiny spot.

One think I like to do on Twitter is to dream how I'd approach those short video  sequences myself. Preferably in the original character's abilities set, a bit like how Myamoto and his team decided to make Popeye be able to jump over barrels in the early prototypes of Donkey Kong as it was the most natural thing to do if it wasn't a videogame.

And what would be the most natural thing to do if you barely missed a jump to a pillar while carrying a magical yoyo/whip/rope thing ? Well I bet I'd try to wrap the rope around the pillar to be safe again.

That in turn raised the question of "how would I do such a thing for Bilou in my own engine?"  Should the 'whip' be an extension of the player's gob (that is, the internal software element ruling the sprite's behaviour) or be a gob of its own ? Should the pillar be made of special tiles or would the whip-end object (if any) be able to detect a pattern of solid-but-small-enough area ? Both approaches would be valid in each question, but as you may have guessed from the way I ask (or read in the sketches), I'd rather opt for the second answers if I was immediately ready to introduce that ;-)

Swinging Ropes in Pharaohs Return

I love those "dark" places of the Web where you can hear about other people's pet project and see them progressing. I developed a particular sympathy towards Lazycow's "Pharaohs' Return" project, a revival of Pharaohs Curse with state-of-the-art C64 programming.

Il paraît que les forums, c'est la "matière noire" d'Internet. Obscure, insaisissable, insondable. L'antimatière d'un blog/wiki, en somme. Et pourtant, j'adore la façon dont on peut y rencontrer des gens qui ont des intérêts proches des miens. Par exemple, Lazycow nous prépare depuis fin Mai l'exhumation ultime pour "Pharaohs Curse". De nombreuses salles, des couleurs et des décors réalistes, une pléthore d'actions, d'items et des animations à couper le souffle.
Pour sûr, son projet n'a pas à rougir des dernières sorties homebrew sur cette machine telles que Get'em, Mayhem in Monsterland ou Soulless. Superpositions de sprites, reprogrammation à la volée pour doubler le nombre de sprites visibles à l'écran, mélange entre caractères monochrome et multicolores ... tout y est! Même les boss démesurés.

Mixing multicol and monochrome tiles, swapping the color registers on horizontal bands for larger color sets, doing the same with sprites to go way beyond the 8 sprites/screen original limit...  I like it. But what really baffled me was his animation for rope action.

Mais ce qui m'a le plus épaté, c'est cette animation que Lazycow a postée où son explorateur attrape une corde au vol. J'avais toujours classé ce genre de détails dans la catégorie "sympa, mais clairement pas prioritaire". Mais s'il le fait sur C64, je me dois de ne pas être en reste sur la DS, pas vrai ? Grimper aux signets des livres fait partie des éléments de level design que j'avais explorés au moment de reprendre le travail sur Bilou ... Difficile maintenant de me contenter d'un signet rigide même si celà faciliterait le développement.

Climbing on ropes wasn't that easy in the original game, and we used to make fun of friends as they were trying to do it with the joystick. Although functionally, the moving rope doesn't bring that much in terms of gameplay (given the limited angle it allows), it's one of those little details that makes a revamp look worth of it and show the love and care that the developer put in it.

When I asked Lazycow whether he had a tutorial on that, he keenly handed me the snippet of his source code that handles the rope action. I noted so far two sub-behaviours: the rope "above" the hanging character simply follows the shortest straight line between the hook and the hero.

for i=1 to heroheight:
    s[i]=i*herodelta/heroheight

The segments below try to align over the preceding segment with delta=s[i-1]-s[i], increasing the segment's speed so that it moves back towards the previous segment, then enforcing "integrity" of the rope by avoiding exagerated offset between segments.

Note that there's a small simplification here, as the rope doesn't shorten as it moves left or right. An alternative would be to assume that sin(x)=x and thus that it shortens by the amount it deviates from the straight vertical line (a fair estimate until you approach x=30°)

Climbing [t.a.g.]

Let's try to clarify all those related tags...

	HANG: a mechanics where you can wait at some places that look mid-air		HOOK, a mechanics that allows you to remotely attach to place from where you can HANG or swing
	climbing, a mechanics to reach higher places continuously without jumping		ROPE, an interactive element that may be used in many mechanics, and involves specific computations
	VINES: plants, you see. They grow, they're climbing, they're falling down. A visual that can be the form fitting many functions.