using between

 

Bon, imaginer un gameplay sympa avec des ponts, c'est une chose. Mais comment programmer le comportement de ce genre de ponts au fait ? hein ? La bonne nouvelle, c'est qu'on a re-fait un passage dans une autre pleine de jeu avec encore plus de ponts, de cordes, et j'en passerelles et des meilleures. Une image comme ci-dessus, par exemple, suggère que Bilou est nettement plus massif que le reste des rondins, sans quoi il ne perturberait pas autant la répartition des charges sur la corde.

So, I now have fun ideas of how to use bridges in Bilou: Dreamland. Sounds like it could be a good idea to also figure out how I'm going to implement such things with my game engine... One thing is almost obvious: the bridge will be made of a set of independent-but-interacting game objects. I'm not going to try and make it one big animated object. If I did, I'd have to manually adjust collision boxes for segments for every frame. That's not what it is for. Same observation applied to the Green Zone boss: Big Caterpillar. And much like the bridge, Big Caterpillar is made of segments that must be able to interact to give the illusion of a single object.

Mais revenons un cran en arrière, voulez-vous ? Alors que J.L.N était face à son premier mini-boss dans Minish Cap, je me suis mis à prendre quelques notes sur le type de contrôleurs qu'il faudrait ajouter à mon moteur de jeu pour pouvoir faire quelque-chose de ce genre. Puis, sur la lancée, à ce que je pouvais en tirer comme conclusions pour la réalisation de Big Caterpillar, le boss de la Green Zone.

Il y a déjà une chose que le moteur de jeu de School Rush peut faire: c'est attacher un Gob (objet mobile fait de sprite(s)) à un autre, et utiliser sa position dans certains contrôleurs. C'est ainsi p.ex. que la chauve-souris-baie se dirige vers Bilou. ou que SpongeBop sait se balancer au bout d'un clou. C'est encore comme ça qu'on peut transporter un dumblador et que ses pieds le suivent à la trace. Mais dans tous ces exemples, on a un seul objet de référence et un objet référent. Quand il y a plusieurs référents (3 BerryBats) pour un même objet de référence (Bilou), ils s'ignorent les uns les autres. Or, pour permettre de positionner les segments internes de Big Caterpillar entre sa tête et sa queue, il faut les coordonnées des deux autres. C'est forcé :P

So since I've just been studying a bit how BC could be implemented, let's see what it can teach us. The game engine can attach one Gob to another one. That's how SpongeBop swings and how BerryBat aim at their target. It is quite clear that those "attach" links will play a role in animating BC, but the question is "who should be attach with whom, and why". When BC will be crawling, for instance, it is easy to make his head move forward during the "expanse" phase and then make the tail move forward (while the head is stopped) in the "contract" phase. As the distance between head and tail shrinks or grows, the location of other segments should adjust.

It is quite easy to find math expression for those locations based on head and tail coordinates. Unfortunately, that'd require *two* attach links per segment, and the game engine only handle one (including in expression opcodes to attach and detach things when collisions occur). I either have to revise the whole engine and break the assumption that One Attach Link Shall Be Enough For Everybody, or I have to come up with some clever way out. That way out could be how a between(...) controller could use not only the attached gob as a reference, but also *the one to which that is attached*. I.e. segments are all attached to the tail, tail is attached to the head and when segment is processed, it reads segment.attach == tail and tail.attach == head to get the data it needs.

Mais gérer deux pointeurs (un "avant" et un "arrière"), ça compliquerait méchamment les choses. Entre autres, ça rendrait difficile le choix de 'qui doit bouger le premier", et ça demanderait une série de bytecodes supplémentaires pour les opérations "attache, détache" des expressions de la machine d'état (que j'aurais cru plus nombreuses. [ ] à vérifier).

Let's see whether that can be enough. I also long for the opportunity to have swinging vines in some Bilou game. They could also be made of chained Gob through attach links. At least when they're hanging free. But as soon as Bilou is using them, I'd like the rules to change. Now Bilou's position dictates how one part of the vine behaves because of tension. If we can use collision to re-write attachments when that happens, that turns into a job for between(...) again.

Retournons vers le pont en faisant une halte à une autre mécanique que je tiens à faire apparaître dans Dreamlands: pouvoir s'accrocher à des trucs qui pendent. J'aimerais depuis longtemps que ce genre d'objet dans Bilou soit au moins aussi bien animé que dans le remake de Pharao's Curse par Lazycow. ce qui suppose

• un mouvement ondulant lorsque la liane est livrée à elle-même (pas de balancé excessif à la DKC)
• une certaine raideur quand Bilou s'y accroche (pas question de passer en mode 'corde ninja')
• Si Bilou n'est pas au bout de la corde, l'extrémité libre continue d'agir librement alors que la moitié tendue est entièrement contrainte par la position de Bilou et celle du point d'attache.

Si j'essaie de dessiner des petites flèches rouges sur ce schéma pour représenter "qui a besoin de connaître la position de qui", on voit que la corde devra réorganiser ces liens quand elle passe d'un "état" à l'autre. Normalement, c'est jouable avec des collision. Et ça confirme mon intuition construite avec Big Caterpillar: le jeu, c'est d'avoir les deux points de référence (début et fin) qui sont directement liés l'un à l'autre (fin->attach == debut) et un contrôleur between() qui suit segment->attach pour trouver fin puis fin->attach pour avoir début et détermine la position-cible à partir des positions de fin et début.

Et pour le pont ? Va-t-il forcément falloir deux liens par bûche ? Je crois que non, mais ça supposera de faire apparaître à la volée deux objets "coincés" par collision sous la bûche qui a reçu un poids, chacun étant la fin d'une chaîne qui remonte jusqu'à un des points d'attache du pont. Et donc que la largeur maximale pour les zones de collision déterminera la largeur maximale du pont.

In Theory, it should be possible to do something similar with the bridge, at least to get a nice alignment of the logs when the force applied is so strong that logs' weights becomes neglectible in comparison. Yet, it's obvious there will be two chains here, both using the same "origin" location (the log on which the force is applied). I thought it could be fixed by creating temporarily two GOBs (red dashes) that are pushed by a collision box of the weighted log (red hatching), each being attached to either side of the bridge (red circles). "slave" logs that must just align would then attach to the dashed-GOB that's on their side (green arrows). But maybe we could even do it without the dashed-GOBs if sides attached to the weighted log and not the other way round.

3D: X Why Z ?

On me demande sans doute à raison pourquoi m'attaquer à la 3D maintenant (alors que j'ai un premier niveau qui est entre alpha et beta) ... "des effets d'éclairage?" ajoute mon frère ... Plus que ça, en fait.

Wihin 8 hours after publishing my last post, I've got two person wondering why I need 3D now and how I'd use it. Well, there's much more than "lightning effects", as far as I'm concerned:

SpongeBop's thread: a single 3D polygon, extremely thin and flat, can be used to display SpongeBop's link with its pin, helping the user to visualize the sponge's trajectory.
Mon premier test, c'est le "fil" de Bop L'éponge, histoire qu'on visualise mieux sa trajectoire et qu'on cesse de la prendre pour "un nuage jaune". Il est construit tout simplement avec deux polygônes plats et non-texturés, mis "en sablier". Je n'ai pas résisté à la tentation de l'implémenter avant de finir de traduire ce post. Ça n'est pas encore propre (un avocat des model-view-controller s'étranglerait en voyant le code) mais ça prouve le concept.

Large smashing books come later in the level for which I have design on papers. I also have "large books" that can be pushed and dropped to create platforms. This involve a level of rotations and deformation that stem for 3D objects. Without them, their respective levels are as meaningless as a Badman episode.
J'ai dans mes carton un niveau qui repose essentiellement sur des livres-écrabouilleurs qu'il va falloir éviter comme des thwomp. En fait, j'avais construit pas mal de scénarios autour des livres pendant la phase où je réfléchissais à un niveau complètement 3D sur PC en 2004. Ils sont sans doute réalisables sans utiliser le hardware 3D, mais ce serait se chatouiller pour se faire rire.

In both the Bilou's Book and design documents, pendats feature a rich set of poses. Right now, they merely step forward, and the animation when they turn back is essentially cheating. I want them charging Bilou, laying on the ground when stunned and pausing to check left and right locations. Not only that involves rotations, but also twisting that affine sprites cannot offer.
Plus déterminant encore: les crayons-soldats. Je ne saurais pas faire beaucoup mieux avec l'approche actuelle intégralement par sprites dessinés à moins de changer fondamentalement le moteur d'animation des sprites pour passer à quelque-chose qui ressemble davantage à Donkey Kong Country. En 3D, je n'ai plus qu'à prendre 6 polygônes non-texturés et laisser la console gérer les rotations et les effets d'éclairage, le reste étant gardé sous forme de sprites affichés par-dessus les polygônes.

Rotating Rulers  -- acting as stretch-and-squish platforms for more challenging climbing action. That level element is possibly what best defines the design for future Bilou's Adventure game, so I really want to have them done. Granted, I could emulate them with flat, smaller platforms that move back and forth synchronously.
Un autre niveau que j'aimerais beaucoup réaliser et dont j'ai déjà parlé fait intervenir des "règles qui tournent" et qu'il faut escalader bien qu'elles s'escamotent dans les recoins du niveau. Ici, on pourrait imaginer un hack à base de sprites qui bougent en coordination, mais ça rendrait nettement moins bien pour 4 polygones (texturés sans doute, cette fois).

Bookmarks that move like vines in Pharaoh's Return. It's not clear that such giggles would bring significant gameplay enhancement, but they would make the School Zone more credible than if cloth-made bookmark where simply standing stiff while you grab them.
Il y a aussi les signets des livres, que je souhaite transformer en corde. Après avoir vu le prototype de Lazycow, mon frère était d'accord avec moi: ça en jette et ce serait quand même largement un plus d'avoir ça dans Bilou, même si au niveau "fonctionnalité du niveau", ça ne change pas fondamentalement la donne.

BangBash's swinging move involves rotation around the Y axis. This will probably be the most demanding item, asking for a complete update of AnimEDS to look more like that old "sketchup compo entry".
Enfin, il y a BangBash, le personnage qui frappait les trois coups pour l'ouverture de ce blog. ll a normalement deux attaques prévues, l'une frontale qui pourrait être réalisée (pas joliment du tout) avec des rotations de sprites et l'autre, tournoyante et latérale (un petit côté double-balayage de Guile) qui impose la 3D d'une façon ou d'une autre.

Voilà. Ça m'aura couté quelques heures de sommeil, mais c'est (fait) et dit.

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°)

Dans le temple perdu

Un temple, quasi-inaccessible, témoin d'une civilisation disparue ... un endroit imprégné de mystères et de questions sans réponses. Depuis que mon frère a composé le thème "Maya Zone" pour "Logic Labyrinth II", je brûle d'en faire un niveau de jeu vidéo. Du coup, je le remets sur la carte en reprenant le synopsys de Bilou en main.

Oui, mais le temple de quoi ? et qu'y affronte-t'on. Le premier point détermine le look à donner au niveau ... le 2eme conditionne le gameplay et l'esprit du niveau.

Le déclic, ça a été d'y implanter les lianes de la forêt. Des berrybats dans le temple perdu ...

I think I at last managed to turn the two words "lost temple" into some interesting and original design idea for both monsters and area look. I have studied art of Rayman and Shantae closer, sketching some original derivative here and there, keeping them secret until I'd have something coherent -- although it isn't pixel art and certainly not a playable demo yet. But let's face it: how would a playable demo "protect" my idea better than a sketch ? It's not like I was trying to win a race with a competitor here, not willing to let X know what I'm doing. Sure, I don't want the idea to be ripped, but I can't prevent someone else to do the same. So I bet my best defence is to do it publicly.

But anyway, just look at that "golem" thingy, animated by the berrybats vines (with berries too young to turn bats :) -- *that* will put you into trouble when you'll play the level ... well, if you manage to find the level in the final game, because it's not called "lost" temple in vain. Trust me: I won't reveal you the slightest bit of information on how you'll get there.
Allez, encore un petit effort. Des berrybats, oui, mais pas tout seul. Et si ... et si les lianes vivantes s'emparaient (au sens propre) des ruines du temple pour construire un golem géant ...

Là, je tiens mon idée de design. Le truc inédit, qui donne une identité propre par rapport à Lost Vickings, Rick Dangerous, Sonic et même Rayman. Alors je le poste, pour marquer l'antériorité. Voilà. C'est mon idée, j'en suis fier. Elle s'appuie sur 3 ans de marquage de favoris dans DeviantArt sans pour autant copier un design de quelqu'un d'autre, je pense. L'imagination est notre ultime frontière. Voici pour vous une planète supplémentaire, aux portes de l'inconnu pour vous lancer à votre tour dans les confins inexplorés de l'imaginaire vierge. Have fun.

(merci à Cyril et son Sony pour les photos, parce que j'aurais jamais trouvé le temps de scanner ça avant ... houuu ... le surlendemain de la St-Valentin ?)

all rights reserved.

grimpons, grimpons

Bon, c'est pas le tout de dessiner des pixels de lianes/vignes sur lesquelles grimper. Maintenant, il va falloir coder ça, aussi. La base est relativement simple : un nouveau type de tile qui permet l'utilisation du comportement "grimper", au même titre que le sol permet de marcher.

C'est plutôt le passage d'un autre état (à l'arrêt ou en saut) vers l'aggripage de liane qui va demander une attention particulière. Deux éléments entrent en ligne de compte :

1. le joueur appuie-t-il sur la flèche vers le haut ?
2. Y-a-t'il une liane à laquelle s'aggriper ?

La deuxième question revient à un test du type "cando(...)", à ceci près qu'il ne fait pas partie du comportement "normal", mais qu'il risque de devoir être évalué depuis les transitions de la machine d'état.

Of course, just having pixels for the vines is not enough: it's time to start thinking about the code that will let us grab and climb them. I have a few technical problems that need to be solved before code can be written down.

One of them is that you can climb a vine (assuming you're on the ground) only when you're exactly below it. From a gameplay point of view, this is unacceptable, so something will be required to make the vines "magnetic" so that the player is automatically placed at the right position when he attempts to climb while being "sufficiently close to the vine".

Second, to be able to grab the vine while jumping, I need to alter the behaviour of "jumping" and "falling" so that it raises an event, which forces transition towards new states to be evaluated. But I do not want such event to be raised at every frame when the player holds 'UP' dpad while jumping. I am still undecided on how I should make the fact that a vine is present available to the state machine expressions -- and potentially, same kind of info will be required for swimming in water and slippering on ice.

Autre petite difficulté technique en vue : lorsqu'on est au sol, il n'y a a priori qu'une position où il est effectivement possible de monter à une liane : quand on est pile sous celle-ci. Du point de vue du gameplay, ce serait l'horreur d'imposer ça et il faudra donc programmer une sorte de "magnétisme" qui positionne le joueur qui tente de monter à une liane juste sous celle-ci s'il n'en est pas trop éloigné. La solution s'ébauche, mais ce n'est pas encore assez précis à mon goût ...

Bilou Mining, donc.

Am I ready for this ? ...

Vous n'êtes pas du genre contrariant, hein ? je mets sur "papier" une série de petits jeux rigolos que je pourrais réaliser plus ou moins rapidement sur DS avec Bilou compte tenu du code et des graphismes dont je dispose maintenant, j'organise un petit vote, et qu'est-ce qui sort vaincqueur ? Exactement ce que je suis occupé à faire depuis l'an dernier. Autant pour le vent neuf de l'an dix, tiens. Voyons donc ce que donne le mockup d'arachne réchauffé à la sauce Bilou ...

Arachne's seminal mockup

I guess I'm just happy if Arachne don't kill me for this one. I'm quickly doing a mockup of Bilou in a "mining for ... stuff" minigame, using her own mockup as a base. Indeed, despite all the alternative I suggested, according to the poll, you seem to prefer that I keep focusing on the current line of demos. Since I don't see why Bilou should gather all the apples of a level to clear it, I prefer keeping fruits as "optional" bonuses and claim that the goal of "Bilou Mining" will be to recover all the nuts and bolts from the crashed Astro-cruiser.

On va donc continuer dans l'optique "ramasser les items et atteindre la sortie", mais plus des pommes cette fois-ci. Il me faut des "clés" qu'il est indispensable de collecter, les fruits servant uniquement à juger le "style" -- départager le maximum d'entre les maxima, comme disait Popo. Bin ce sera les boulons de l'astro cruiser. voilà.

Shantae, again

Mais un gameplay "à la Manic Miner" a des exigences tout de même un peu différentes d'un SuperMario. Tout d'abord, le timing est la clé du succès, plus que votre adresse à défier la gravité. Il faudra donc que je revoie l'armement de Bilou.

Ensuite, il faut que le joueur puisse avoir une vue d'ensemble du challenge, ce qui colle bien avec la taille de Bilou, un peu moins avec la hauteur de ses sauts. Finalement, il va falloir grimper à des échelles et ne pas trainer sur des plate-formes éphémères. Et là, c'est plus chaud: je n'ai toujours pas réussi à dessiner des lianes convaincantes en couleur. L'idéal, ce serait quelque chose approchant les arbres de Shantae DS (voir les images de référence en bas du post).

ma tentative pathétique de s'en approcher ...

I expect subtle changes to happen on the current gameplay to match that objective, though. At first, jumps should be shorter so that I can put more of one challenge on the screen and have an increased "puzzle" dimension by letting the player observe the level and decide of its strategy rather than reading and reacting promptly as in a SuperMario game. This also suggest that we should have more than stomps to dispatch baddies. Collectible weapons are likely to appear. But most of all, to pack more action per screen, I'll need ropes and ladders ... that is, vines, in this green woods stage. Unfortunately, all my attempts at drawing something (even just slightly) similar to the vines found in Shantae DS is a total wreckage so far.

Je me suis donc fait un petit tour de flickr-vgmaps-f-spot pour essayer de collecter un maximum d'images de référence. Ca a un peu amélioré le résultat mais pas énormément. Je gribouille donc des lianes un peu partout sur des bouts de papier, je m'arrête au milieu d'un niveau dans SPP pour chiper les marqueurs de ma fée et redessiner les haricots magique qui dépassent des nuages dans le monde du ciel. Pour changer, j'ai dessiné d'abord la forme dans un pavé 32x32 et je lui ai donné du volume avant de la "zoomer" en 64x64 pour ajouter les détails et peaufiner le look.

I've collected quite uselessly tons of reference pictures, until I stumbled upon that magical-bean-plant-seen-over-clouds in the Glidy Sky of Super Princess Peach. I loved the simple elegance of that ?-shaped curve that renders all my previous attempts pretty obsolete. And I actually managed to reproduce it by sketching it first on a 32x32 draft (including colors and shading) before I zoomed individual quarters of that draft to a 64x64 canvas that I could further refine. Graphically speaking, I'm quite happy with the result, except that it is completely useless from a gameplay point of view. Still I've used its "curved head" in the mock-up as ladder and as anchor for the "berry-spiders".

EDIT: entretemps, le projet a été renommé "Nuts&Bolts"

Ziggy, il s'appelle Ziggy ...

Unfortunately, I'm not the author of these graphics (2Dhero -- Tom Filhol is), neither am I working on a nintendo DS port of this indie game running on Game Maker for Windows. So why does it appear here ? because I'm studying it as much as I can: character design, graphic style, palette choice, composition. This is truly a platformer gem that we are offered here, reminiscence of Superfrog (with so much better gfx!) 

 Je ne peux pas m'empêcher de comparer Ziggy à Superfrog. C'est un excellent exemple de "jeu d'auteur" où la passion (et le talent, je dois l'admettre) nous apportent un jeu d'une qualité rare en ces temps de crise. Vous l'aurez compris: il ne s'agit pas de graphismes à moi, ni même d'un homebrew pour DS (dommage, d'ailleurs). 2Dhero nous a concocté son jeu "en indépendant", avec le Game Maker pour Windows, comme beaucoup d'artistes du pixel le font ces derniers temps. 

De mon côté, j'étudie tout ça avec beaucoup d'intérêt ... palette de couleur, composition de la scène, style graphique, etc. J'imprime en gros plan, je colle des petits extraits dans mon agenda, etc. Je ne "relookerai" probablement pas complètement Bilou pour suivre le "style ziggy", mais comme je coince sur les lianes et les fleurs ces temps-ci ... A noter au niveau gameplay une "attaque aérienne" qui permet de sauter horizontalement en plus du saut ordinaire, ce qui ouvre presque plus de possibilité que la "glissade", plus classique. Oh, et pour ne rien gâcher, il tourne dans wine...

Edit: it took me a while to do it, but in december, the 'slopes demo' features ziggy-inspired vines. 

Xargon, Jill et Nikita

Okay, pour ceux qui en nourrirait encore vaguement l'espoir, je n'ai pas l'intention de porter Jill ou Xargon sur DS. C'étaient de bons jeux dans leur temps, mais même le fait que les sources soient disponibles (pour Xargon en tout cas) ne me tente pas.

Je m'explique. Un des éléments qui m'intéressait dans l'étude du code de Xargon, c'est que tout comme notre Commander Keen, Jill et Malvineous (eh oui: Xargon, c'est le vilain pas beau et Malvineous le héros tout en muscles) savent grimper aux lianes (chaines et autres). Un des aspects qui me coince un peu dans Bilou. Or donc, grace au flag f_notvine, ces héros grimpotent grace aux éléments suivants:

• le test "y a-t'il une liane" n'est effectué que sur des frontières de tiles (comprenez, quand x est un multiple de 16)
• une fois accroché à une liane, il n'y a plus de déplacement horizontal

Maybe my last post made you believe I was about to port Xargon or Jill of the Jungle to the Nintendo DS. I'm not. They were solid games back in the days, but even with sources available, I'm not tempted. What's interesting me while studying Epic source code is that their heroes (much like Commander Keen) can CLIMB. Vines, chains, pole. Name it, you have it. That's one thing I don't know how to deal with in Bilou so far, but thanks to the F_NOTVINE flag. Things seem to work fine. The 'is there a vine' test is performed only at tile edges (x is a multiple of 16) and no horizontal motion is allowed on a vine. Fine.

But there's one thing missing: where's the code that aligns character to a vine if they aren't yet ? having to pixel-perfectly aligning before climbing is usually not something you leave to your players. And I don't recall it being so hard to hop from vine to vine in Jill of the Jungle. Almost easier than hopping from block to block, actually.

Apparemment tout ce qu'il faut sauf qu'il n'y avait apparemment rien dans le code qui permette de forcer le perso à s'ajuster à l'emplacement de la liane si jamais il n'était pas pile en-dessous ... louche, ça. Vous vous voyez jouer à un jeu où il faut être positionner au pixel près pour monter à l'échelle, vous ?

Pourtant je me souviens que ce n'était pas si difficile de sauter de liane en liane dans Jill (j'ai peu joué à Xargon, en fait). Bien plus facile que de sauter de bloc en bloc, d'ailleurs.

Bin voui. pas étonnant. Figurez-vous que Jill ne se déplace jamais que _de 8 pixels à la fois_ idem pour le scrolling. Oui, vous avez bien lu : 8 pixels. La taille d'un caractère à l'écran. Jill est soit sur le bloc gris, à moitié sur le bloc gris ou à côté du bloc gris. Point barre. Le jeu est un peu plus "souple" pour les déplacements verticaux (2 pixels) mais n'empèche. La version shareware avait beau se gausser de Commander Keen et de Super Mario, le slogan "The Brothers are History", c'est à Giana qu'il revient, certainement pas à Jill. Et toutes ses voix enregistrées et ses cuisses bien rondes n'y changeront rien!

So here's the catch: Jill and Xargon only move by 8 pixels. Same for the scrolling. Yes, 8. A full-sized letter on CGA screen. Either Jill is perfectly centered on a 16x16 grey block, or she's exactly on the edge of that block. Or she's next to it. That's it. Vertical motion is a bit smoother (2 pixels granularity), but barely. There may be a similar 'minimum walking distance' in commander Keen (4 pixels), but motion happens pixel per pixels, much more smoothly. And while Jill's jerky motion could be excused by the run animation on the ground, nothing justifies it while jumping (and it hurts the gameplay a lot).

Dans Commander Keen, cette "distance de déplacement minimale" est de 4 pixels (en tout cas, si je donne le plus court déplacement possible, c'est ce qu'il se passe), mais malgré tout Keen est déplacé pixel par pixel. Bien plus fluide. Et si ce genre de "déplacement brusque" peut se justifier pour l'animation de la course, en revanche, il est complètement ridicule (et pénible au niveau du gameplay) lors d'un saut. Tiens, à creuser par contre ... Et si j'utilisais le freinage du perso pour forcer ce genre de déplacement minimum ?

Bref, le code était instructif, je vais me replonger dans la programmation de mon p'tit Bilou (qui a appris à marcher ce matin ;) et en attendant, si vous êtes en manque d'exploration de mondes curieux à grand renfort de transformations magiques (c'était un des points-forts de Jill, je l'admet), je vous recommande chaudement Nikita, la femme-loup du jeu Inner Worlds. (merci à CJ pour l'URL et sa compil' "nostalgy power" :)

Voilà. Ma sauce bloubloute alors je vais vous laisser. A+.

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.