Keen: ClipToWalls()

Pour éviter que Keen ne passe à travers les murs ou ne reste bloqué en bas d'une pente, les niveaux attribuent à chaque bloc de 16x16 pixels un ensemble de propriétés. C'est la technique des "tiles" bien connue de la plupart des lecteurs. Ce qui est particulier dans le moteur d'ID software, c'est la possibilité de définir séparément l'animation, la pente de sol, le comportement en tant que bloc spécial (valeur du bonus, couleur de la clé, etc.) et la polarité du mur.
Plus fastidieux à définir que le simple remplissage en tant que bloc solide de mon éditeur de niveau, mais heureusement, dans Keen, il y a presque systématiquement correspondance entre graphisme et propriétés, et l'éditeur de niveau peut automatiser tout ce qui n'est pas passages secrets.

Levels in Commander Keen are build out of tiles -- 16x16 pixels squares combining a graphic content and some in-game properties. In ID's engine, the tile number (*map) is used to index a set of arrays that are present in game definition, and read at game startup into tinf. NORTHWALL, in the snippet above, is the offset to the array holding information about how the tile behave as a floor. Is it sloped ? can we move through if we're sliding down a pole ? tinf[NORTHWALL+*map] tells you that. And only that. If you'd like to know whether there's a bonus of some value, you should definitely check another "slice" of the tinf array.

Interestingly, the behaviour routines won't immediately react to wall/floor/ceiling collision. Oh, well, character will immediately be _clipped_ to that wall. Aligned, if you prefer, so that it doesn't enter a rigid structure. But the alignments that were performed are saved into four boolean variables: hitnorth (floors), hitsouth (ceilings), hiteast and hitwest (walls). Behaviour routines like KeenAirReact use this information to adapt the current state (stop falling when reaching the ground, for instance).


La notion de "polarité des murs" est intéressante. Lorsque le personnage se retrouve partiellement dans un mur, c'est cette polarité qui décide si Keen est repoussé vers la gauche ou vers la droite. On aura donc jamais de situation comparable au "zipping" des jeux NES où Megaman se met à traverser le niveau à vitesse super-sonique lorsqu'il rentre dans un mur simplement parce que les programmeurs se sont contenté de "si on est dans un bloc solide, on repousse Megaman sur le tile suivant". Evidemment, ça suppose que les murs font toujours au moins deux tiles de large.

A Zipping technique in Megaman. Propelled at 1 tile/frame or so.

Another interesting thing is that walls have polarity. They're either left wall or right walls. And they're not plain ground either: you could fall through a wall if there were no floor on its top to prevent you from entering there. And it's actually more resilient against zipping through walls. Unlike Megaman, Keen wouldn't be propelled to the (arbitrary coder decision) right if he ends up into the wall from the left while heading left. A wall on Tuberia knows whether it is an east wall, no matter the direction, speed and age of the Commander. And if it's an East wall, it will push you to the East, back where you're supposed to belong to. That makes ID software's collision handling the perfect opposite to Epic Megagames' cando() function.

C'est intéressant de voir que ID software a choisi ici une technique radicalement opposée à celle d'Epic Megagames. Pour Jill of the Jungle et Xargon, Epic faisait en sorte que le personnage n'entre jamais dans des tiles qu'il ne peut pas traverser (grâce à la fonction "cando"). Pour Keen, think() peut potentiellement faire rentrer un personnage dans un mur, mais le déplacement via ClipToWalls() le repoussera automatiquement dans la bonne direction, sans risquer de se faire piéger par un demi-tour de dernière minute comme dans Mario Bros.

analysis paralysis ?

Près de 3 mois loin de chez moi, maintenant, et toujours pas de petit homebrew à vous mettre sous la dent. Okay, mon laptop est un char à boeufs comparé aux PC que j'ai à la maison. Okay, je n'ai pas de Wifi dans mon k0dek et le laptop n'est pas configuré pour faire base station pour la DS mais il y a autre chose.

Je sais qu'il y aura pas mal de choses à mettre en place pour parvenir à réaliser Bilou sur DS ... je veux dire par là, "le jeu de plate-formes tel qu'il avait été prévu dans les années '90 et prototypé sur BASIC", mais revu et corrigé pour la DS, bien sûr.

Par exemple:

• [just started] la gestion des bordures. Même si je garde au départ un système tile-based, les plate-formes mobiles et autres sables mouvant devront être capable d'altérer le comportement des sprites
• [ongoin] les pentes. Je veux que Bilou puisse se déplacer sur des plate-formes qui ne soient pas uniquement horizontales.
• [done] l'animation modulaire. ou "à la rayman", qui me demande un éditeur d'animations spécifique en plus des ajustements dans le moteur de jeu
• [done] les collisions perso-bloc qui soient plus maniable que juste le "petit bonus" que j'ai pour l'instant. Plate-formes qui disparaissent, échelles, etc.
• [done] des réactions aux collisions perso-monstre. Avec une question pertinente "et comment fait-on perdre une vie, au fait"

J'accumule les idées sympa sans vraiment avancer dans le développement. Je sautille d'un projet de shoot à une reprise de Seafox à un "bubble bobble - like" etc. Et bien sûr, comme j'aime le pixel art, j'ai tendance à explorer les aspects graphiques à tort et à travers avant de me lancer dans un jeu.

Je vais devoir me fixer une "roadmap" jallonée de petits projets intermédiaires, et attaquer les difficultés techniques une à une, sinon je vais finir par recommencer à programmer sur Clicker :P

Bonne résolution 2009 #1: on garde Bilou. Quelque soit le petit jeu envisagé
Bonne résolution 2009 #2: un nouveau thème graphique si et seulement si un jeu est produit.
Bonne résolution 2009 #3: s'il n'y a pas d'image de fond (ou si l'image est fixe, etc.) ce n'est pas un problème pour l'instant.
Bonne résolution 2009 #4: faire la vaisselle ce soir

edit: côté "base station", j'ai au moins pris la peine de recompiler le module de mon stick WiFi. M'en vais aller manger une soupe et tester ça @home, tiens.
edit++: toujours pas de connexion Internet au k0dek, mais au moins, j'ai su modifier runme pour qu'il puisse démarrer un programme 'runme-compatible' après l'avoir téléchargé.

3 monthes in Switzerland and still no updates. I'm not focused enough and therefore I'm missing the #1 golden rule of game development : *release*. Having no Internet access in my Swiss flat doesn't help, so I modified runme so that it can launch the last compatible .nds it received from a WiFi transfer. Using my laptop as an access point, it allows ad-hoc development.

Allez, je vais essayer de me faire un petit "ramasse toutes les pommes pour passer au niveau suivant". Ce sera déjà un bon début. Après tout, c'est fort le principe de base de Qwak, Bubble Bobble et même Still Alive DS :P

"Je vous présente les bordures!"

Je viens de retomber sur une lettre -- datée du 8 janvier 1900 -- que je n'ai jamais envoyée à son destinataire, Gédéon (qui signe de temps en temps un commentaire du nom de 'Ged' sur ce blog). Il faut dire qu'après la Inscene '99 et la collaboration de CJ à son jeu "insane bugs" (une sorte de remake de micromachines), on avait entamé une correspondance sur des sujets traitant de la réalisation de jeux vidéos, que j'illustrais assez abondamment de mes Bilous, évidemment.

edit 2021: finally translated.

A cette époque, en pleines études, je codais surtout pour les TP de l'université, mais je n'avais pas énormément le temps de mettre en oeuvre tout ce à quoi je réfléchissais pour mon "Ultimate Game Maker"

Voilà ce que celà disait:

Hello, Gédéon.

Je crois bien que j'ai trouvé un truc cool pour modéliser les niveaux dans Bilou! un truc plus smart que ces "tests de couleurs" puants que j'ai utilisé dans la version BASIC du jeu!... Je te présente les bordures.
L'idée est la suivante: tes sprites possèdent un certain nombre de "testpoints" et les déplacements ne sont possibles que pour certaines valeurs de ces test-points (pas question de faire marcher Bilou dans le vide, hein!)

D'autre part, tu plaques un peu partout dans ton niveau des bordures. Ces bordures sont des éléments logiques qui ne correspondent à aucun affichage. Elles sont liées logiquement de telle manière que l'on peut facilement savoir quelle bordure est située à gauche, droite, au-dessus ou en-dessous d'une bordure donnée. Les bordures sont également séparées en 4 classes: plancher, plafond, mur-gauche et mur droit.

Ca va, je ne vais pas trop vite ?

Bon. Voyons comment ça marche. Lorsqu'un sprite crèe ses test-points, il leur fournit à chacun une classe correspondant à la classe de bordure avec laquelle ils réagissent. Du coup, on s'empresse de lier chaque test-point à la bordure de même classe la plus proche (euh, ça ne devrait pas être trop sorcier).
Voilà un aperçu de la chose en cours ... tu peux facilement savoir si tu es "dans le mur" ou pas: il suffit de regarder de quel côté de la ligne le point se trouve. Dès que ton point sort du "champs d'action" de sa bordure, on cherche quelle est la nouvelle bordure et on y relie le testpoint (après quoi on effectue le test habituel).

C'est-y-pas merveilleux, tout ça ?

Allez, une dernière idée qui m'est venue comme ça, en écrivant cette lettre (pour être sûr que tu n'arrives pas à dormir cette nuit ;-)
Au lieu des testpoints, tu pourrais faire des "bordures" pour les sprites aussi (en fait, à partir de la bounding box), mais tu risquerais d'avoir plus de calculs à faire ...)

Enfin, ça m'éviterais d'avoir des bugs à la "Crazy BriX".
Allez,
Bion, depuis, l'eau a coulé sous les ponts. Le coup des "bordures" était bien alléchant, il permettait de passer à la 3D avec moins de prise de tête que si on doit procéder pixel par pixel (c'était le cas dans Bilou en Basic, comme je le mentionnais dans la lettre), mais par contre je n'ai jamais trouvé le véritable "truc pas trop sorcier" pour déterminer quel est la prochaine bordure du même type, en particulier lorsqu'il y a plusieurs plate-formes les unes au-dessus des autres (classique dans un jeu de plate-forme, évidemment).

Pour la version "DS", je me rabats principalement sur des tests "tile par tile" (et prout pour la 3D), et les "bordures" serviront principalement pour des plate-formes mobiles, nuages, et autres joyeusetés ... Une sorte de manière de passer outre les limitations typiques des jeux "game maker".

Voilà. Bonne année à tous.