Let's get Z !

How about going crazy and sampling the support of 3D in my current game engine? I don't mean adding a 3D world nor even so-called 2.5D (2D motion in 3D display as in Relminator's last submissions), but simply the use of 3D hardware to render things such as pendats body, swinging ropes or falling books (much like in NSMB, actually).

After checking my version of desmume (0.9.6, custom build) had support for 3D, I'm merging some NEHE tutorial with my core loop to start some video resource management here and there... and it looks like I'll have somewhat work to make them integrate seamlessly, as I lost all my extended palettes (hence the all-black sprites) and likely the "owl background" in the process.

Quel est donc ce trio de triangles qui semblent avoir volé toutes les couleurs du monde de Bilou ?? Eh bien ce sont les 3D qui ne s'interfacent pas encore très bien (hum ... euphémisme ? ^^") avec le reste du moteur de jeu. Comme le mode 3D a ses propres interfaces, il me faudra quelques soirées en plus avant de commencer à avoir quelque-chose d'exploitable, sans doute.

WYSIWYG level

I had a bullet point in my "todo-before-release" list saying that the level shall be WYSIWYG -- the accronym for "What You See Is What You Get", which is just a coder jargon for form-fits-function. You see a solid structure, there is a solid structure. You don't see any, that's because there isn't any. No invisible wall, no subtle tunnels.

Unfortunately, I did have such a tunnel in my map. Tracking them right now means I have to scan the whole level in "meta-tile" mode. That's not quite comfortable and it proved unsufficient as I regularly break further the map when trying e.g. to adjust colors or fix some buggy pixels. Look at what I found yesterday on my on-going map: a hole dug into a wooden block that would make you walk into the should-be-solid area! How could that happen ? Simply because I tried to fix some un-esthetical combination of tiles.

Veiller à ce que le niveau ait effectivement des murs partout où des murs sont dessinés n'aura pas été une mince affaire pour ce niveau-anniversaire. En fait, je manque cruellement d'un outil capable de m'assister dans ce genre de tâche et il faut passer en revue le niveau en mode "propriétés" après chaque modification. Même un correctif purement cosmétique peut affecter la structure du niveau parce qu'un nouveau graphisme sur l'avant-plan va détruire les propriétés construites précédemment.

Il y a donc une sorte de "méga-raccourci" dans la version g88 qui fait très étrange (on se promène à moitié noyé dans le bois :P) et en voulant corriger une incohérence graphique (image ci-dessous), je me suis retrouver à introduire un nouveau "bug dans la matrice" (image ci-dessus). Bref, il est temps que j'équipe LEDS d'une sorte de radar permanent qui me permettrait d'avoir une vue un peu plus large des propriétés du niveau en cours d'édition qui se combinerait avec une map plus complète sur l'écran d'accueil, de sorte qu'il soit possible de positionner la fenêtre d'édition au stylet, visualiser l'emplacement des différents monstres, etc.

What's especially tricky with this map-bug is that it won't reveal easily when play-testing: Bilou slightly leaps when leaving the edge of a structure, and although it's technically small, that leap is large enough to clear one block. So you won't fall in a 16-pixels hole unles you hardly try and jump to align Bilou on the hole.

So it's now time I implement the "mini-radar" feature, at least able to show 64x64 tiles centered on the current editing screen, with 1 pixels for 1 tile.

• WelcomeWindow : down screen, prompt file names, etc.
• TileWindow : down screen (swapped up during edition), with TileTables for showing tileset content. [done] here be a mini-map of what we're editing.
• [todo] cleaner integration, widget laying on TileWindow although fed from MapWindow
• MonsterWindow, MapeditWindow both on the "up screen", with sprite memory already heavily loaded and the whole tileset present to show the content.

A new RadarWindow appearing together with WelcomeWindow (and thus on the 'up screen' when it's truly up) would be welcome to check whether we don't have broken structures just before we save/play the level, with a full level.

read more ...

A block too far.

Dix blocs à franchir ... Ce second obstacle continue à rebuter, mais ça devient plus facile à gérer. Dans la version g88, il était indispensable d'arriver avec la bonne vitesse sur une petite gomme. Sauter trop tard (en courant), c'était l'échec assuré. Ne pas courir, c'était arriver à coup sûr trop court.

I guess many have cursed that row of pencils in the g88 "anniversary" level. One thing I wanted to fix is that not only it required a master-level of the RUN and JUMP mechanics, but it did not provided a way for the player to build that mastery. Jump too late, and you'll end in spikes. Fail to run, and you'll realise quite late that you don't have the speed to clear the jump.
I experimented two approaches that make the obstacle easier to clear: the first one is widening the bouncing zone, which in turn reduces the stress on the timing. The second was to move the bumper away from the pit, so that missed attempts can be cancelled by the player.

Pour rendre ce saut plus facile à apprivoiser sans en tuer la difficulté, et maintenant que Bilou peut courir de façon fiable, il y a 2 choses sur lesquelles je peux jouer. D'abord, la largeur de la zone-bumper: un bumper plus large donne plus de souplesse au joueur sur le moment où il va sauter. Ensuite, un "filet de sécurité" entre le bumper et le début des crayons. De cette façon, le joueur qui a mal jugé de la distance de son saut garde une possibilité de revenir en arrière.

These two adjustments to the level make it more learning-friendly, but most of the challenge remain. Either you manage to RUN-JUMP as desired, or you find the alternate, safier route. For the next release, I'd like to grant player with the ability to feel empowered and have a laugh at the challenge, by power-ups, of course. You could either start the level with 5 hitpoints or pick one (random?) power-up before you enter it. That could be done through some form of DASH mechanic, or possibly a way to break more easily through that chalk-barrier, etc. Of course, I wouldn't have a "fix-them-all" item: if you get the ability to undermine _some_ challenges, you'll have to rely solely on your skills on others.


Enfin, avec l'augmentation de la vitesse que Bilou peut atteindre en courant, il est possible de passer par-dessus les pointes des crayons simplement en courant et en sautant, y compris en prenant "par le haut". Celà n'empèche que pour une prochaine release, il serait intéressant de proposer des "power-up" au joueur qui lui donnerait la liberté de bouder l'obstacle, même sans le contourner par le haut.

Entretemps, j'ai pris le contrôle de la course de Bilou, de sorte que je gère la vitesse maximale qu'il peut atteindre (suffisante pour franchir les 10 blocs de justesse sans l'aide de la gomme) et qu'on peut se mettre à courir en faisant un double-dash dans une direction (à la Kirby) ou en donnant une impulsion vers le bas pendant qu'on marche ou donnant un coup de R.

Fine-tuning.

Raw as raw can be: here's a collection of "todo items" related to the "20 years anniversary level" that has staid draft since my first re-contact with the BilouCorp. It's not very sexy, but at some point, gameplay fixing is also those kind of fine-tuning.

• [done] BIGFALL Camera: a maximum vertical speed of 7 for the camera is a minimum as Bilou's maximum vertical speed is near 6 (pixels/frame). It feels better when the camera is controlled by the DPAD (holding down when falling) rather than activated automatically when reaching a specific velocity. With those settings, the player has 0.5 second between the time pencils appear at the bottom of the jump-of-(fai|dea)th and contact with the ground. half that time is required to manoeuvre Bilou away by 16 pixels, that leaves ~0.25 seconds of reaction time to the player.
• [done] Spongebops appearing on the bottom of the screen due to wrapping of the Y coordinate by the DS hardware (?) mislead the player into believing that there's an invisible sponge that will reveal if they jump into endless pits.
• [wish, AskTheTeam] Bonus room with a "hidden exit" should better be replaced with a room that offers a limited time to collect all the items and brings you back to the level when completed (as in DKC). Until the engine can support that, make sure the room's exit is as close as possible from its entry, so that realizing that you can't come back through the path you picked doesn't prevent you from going further with the game.
• [done] Chalk do break, much more easily than pencils. Use some chalk picture for the break-through platform on the desktop.
• [done] Add an 'onscreen' controller that triggers an event when an object gets offscreen, so that 'stunned' animations can be completed and items no longer "magically disappear".
• [done] with a horizontal top speed of 540, running becomes enough to clear the pencil-pit area: no more bouncing-on-bumpers or grabbing-sponges is necessary. with momentum limited at 480, it is still feasible to clear the pencils, but it requires to jump when Bilou's first feet is already out of the safety area, so the bumber is "safier", and it could be made more in the middle of the platform as initially designed, so you don't necessarily fall into the pencils if you miss it.

Croyez-le ou non, mais j'ai réussi à recontacter la "Bilou Corp", et j'ai donc une toute nouvelle toudoulisse pour le niveau-anniversaire. C'est un peu brut, vous m'excuserez peut-être un jour. Plein de petits règlages à faire: les vitesses de caméra quand on tombe, le remplacement du crayon-qui-casse par une craie-qui-casse, etc.

horizontal position.

What if one reason for players failing to clear the large-pencils-pit was that they can't predict what's ahead? With the 'G88' release of the anniversary level, Bilou was tightly centered on the screen (horizontally). So tightly that you could barely see a few pixel of the other side even though you dangerously adventured over the first pencil.

Cette fois, j'en ai, des retours de beta-testeurs. Au point que je ne suis plus la cadence pour le blog lui-même ^^". J'ai passé un certain temps à faire des ajustements sur le système de caméra, notamment pour faire en sorte qu'on ait une meilleure vision sur ce qui nous attend. Cette rangée de crayons, à droite de Bilou, saura-t'on la passer en sautant ? Faut-il courir ? Faut-il chercher un autre chemin ? délicat à décider si on en voit pas la fin, hein?

L'occasion donc de refaire un tour d'horizon et de voir où sont positionnés les héros dans les jeux de plate-forme qui me servent de référence. Commençons par New Super Mario Bros et ses variantes: Mario est (du point de vue horizontal) au centre de l'écran. Dans SMB3, c'est l'arrière de Mario qui est au centre: il tire véritablement la caméra derrière lui, ce qui lui donne l'occasion de faire un demi-tour sans à-coup de caméra qui donnerait la nausée au joueur. Simple, donc mais aussi paradoxal: le joueur voit mieux les obstacles qu'il vient de passer que ceux qui restent à venir.

But what is the behaviour of canon platformers ? It looks like NSMB always center Mario and it feels fine. True, but NSMB can zoom out when you will need more vision of what's going on. Plus, I'd bet you could beat any level without running. Large leaps with the RUN button held down are on alternative paths only. For the record, SMB3 was even weirder: Mario litterally pulled the camera behind his back! Granted, that allow for smooth turn backs, but that somehow kills visibility. Hopefully, the Racoon suit can save you from unforseen pits ^^"

À l'opposé, Rayman PSX se situe presqu'à 1/3 de l'écran, ça donne bien au niveau de la composition d'image (disent les artistes) et ça dégage la vue. En revanche, ça fait un fameux travelling chaque fois que le joueur se retourne. Si ce n'est pas trop délicat dans la majorité des niveaux, en revanche, ça rend les combats contre les boss particulièrement agaçant puisqu'on les perdra de vue presqu'immédiatement après avoir essayé de s'en écarter. Il faudra se retourner à nouveau pour savoir quelle attaque ils préparent (ou retenir l'enchainement par coeur).

Rayman goes a bit extreme when placing the hero almost on the 1/4 boundary of the screen. True, you'll get good preview of what's ahead (and that's very welcome), but if you have to move back and forth, it will quickly annoy you with wavy behaviour. And you'll have to move back and forth *a lot* when fighting bosses. Even worse: your position on screen is not based on your state (staring left or right) but on your (last) speed. When swinging or on mobile platforms, the camera may suddenly shrink your vision of what's ahead by 50% at critical instant. Donkey Kong Country (which also has the character near 1/3 of the screen) solves this my centering your Kong perfectly when he's on a swinging rope.

Autre hic, le système de caméra ignore en réalité dans quelle direction Rayman regarde: il ne connaît que sa vitesse. Du coup, sur une plate-forme mobile qui fait demi-tour, votre visibilité devient tout d'un coup réduite de moitié sans que vous ne puissiez rien y changer >_<.

Un qui m'a surpris, en revanche, c'est Super Mario Bros. sur NES. Bien sûr, le jeu n'autorise pas la marche arrière, et on pourrait donc "fixer" Mario à 1/3 de l'écran pour avoir une bonne visibilité sans souffrir des défauts de caméra de Rayman. Pourtant, à vitesse de marche ou à l'arrêt, Mario se situe au-dessus du 8eme des 16 blocs que l'écran affiche. 1/2 écran entier devant soi, en somme.
En revanche, dès que l'on se met à courir, l'écran se centre différemment et ramène Mario d'un bloc en arrière, libérant un peu plus le champ de vision.

I've been quite surprised, however, to see the behaviour of SMB on the NES. Since the game always moves to the right, I'd have expected Mario to be somewhat near 1/3 of the screen. But it's not. It's almost centered (it pushes the screen center with his nose, rather than pulling it with its back as in SMB3) *unless you run*. As soon as you gained significant speed with the RUN mechanic, you've been moved backward by 1 block.

Bien sûr sur SuperNES, l'habitude était de proposer au joueur de regarder en avant et en arrière avec les boutons L et R, mais j'aimerais garder ces boutons pour faire tourner Bilou dans tous les sens. Le coup de SMB1 m'a donc donné l'idée de laisser continuer la caméra pour qu'elle se centre en avant de Bilou lorsque celui-ci s'arrête. Le joueur n'a donc qu'à marquer une pause s'il veut savoir ce qui l'attend ^_^

Since I want to keep L and R for later purpose, I came up with the following idea: why wouldn't I use the "idle" state to change the ideal camera position ? Do you want to see more of what's ahead ? just relax, wait a little bit and that will be shown to you ^_^. I adapted the camera system so that it become feasible, and tweaked the parameters so that you don't get jerky camera motions when doing funny things like "turn back while jumping before the camera settled on your idle position", but I think it's now working nicely. I hope it will pay off for the future beta-testers. There's something similar in DKC, btw: when entering a barrel, the view is shifted somewhat more towards the blast's direction

L'avis de Joke

Longue session de beta-testing hier avec Joke de la BilouCorp -- une corporation sans lien direct avec mon personnage fétiche mais néanmoins fort sympathique et versé dans la conception de jeu vidéo -- si bien que ce matin, je passais le démarrage du niveau en mode "image par image" pour comprendre d'où venait ces "à-coups" quasi systématique quand on descend de la latte pour aller se mesurer à notre premier crayon.

• il sautille un peu sur la descente de la règle au début
•  … la caméra ça va je trouve
•  ça manque d'effet sonore pour les sauts et rebonds 
• le premier saut qu'on doit faire d'un crayon à l'autre avant le pot d'encre, je remarque qu'on peut pas y arriver si on ne se tourne pas d'abord dans la bonne direction
• La gomme du crayon c'est volontaire la possibilité de passer derrière ? le fait qu'on soit propulsé en sautant quand on est dessus n'a pas l'air de nous aider à passer. il faut prendre de l'élan je pense, ça complique les choses

 Il y a deux ans, j'aurais plus ou moins considéré ça comme du temps perdu: ce sautillement ne gène en rien le gameplay... mais ça fait tache et en plus, c'est la première chose que le joueur va voir du jeu. Donc, je creuse à grands coups de ddd avec la méthode désormais bien rôdée de "je m'arrête avec Inspector Widget dans la situation qui m'intéresse avant de mettre mes breakpoints".
Après une bonne heure d'inspection méticuleuse, j'arrive à la conclusion que le code du moteur de jeu, des contrôleurs etc. est 100% clean: c'est dans l'animation que ça coince. Pour une raison encore inconnue, une des étapes d'animation force le déplacement à être horizontal plutôt que de s'adapter à la pente en cours ... bizarre, bizarre.

Je ressors donc mon "extracteur d'animation en vrac (à perforation en vrille): il y a en effet quelque-chose de louche avec les animations de marche de Bilou. Les étapes d'animations qui se comportent bizarrement ont un bit "déplacement vertical autorisé" qui reste à zéro. Chose intéressante: le pendat (qui était incapable de suivre les pentes) a systématiquement ce bit à zéro. Dumblador, lui a son bit "déplacement vertical autorisé" mis pour chaque étape.

J'aurais été bien incapable de dire en aveugle à ma fée quelle manipulation elle aurait du faire pour changer ce règlage dans AnimEDS, ce qui signifie que c'est un des contrôles-candidats pour un menu déroulant ou quelque-chose de ce genre.
En fait, c'est le petit "!" devant "y" qui doit être retiré pour "déverouiller" l'animation verticalement.

Mais alors ? Si ce sont des règlages au niveau de l'animation (et pas d'une étape isolée), pourquoi cet étrange étape verouillée dans la marche de Bilou qui ne l'est pas pour le reste ? Sans doute parce qu'il s'agit de la liste de commandes générée pour permettre de boucler la boucle, et que son code n'a probablement pas eu droit à sa mise à jour (ouuuuh ^^").

J'édite l'animation en hexadécimal dans Midnight Commander ... Je recompile à cloche pied ... Bilou retient son souffle: c'est l'heure du test fatidique ... attente insupportable de 15 seconde pendant que la caméra re-traverse le niveau à contre sens pour venir se centrer sur Bilou au départ.

Ah oui! Bien mieux! La descente est fluide, la remontée aussi... Il me reste à aller corriger AnimEDS, donc.

read more ...

Fixing Monsters

Walls ? Caves ? Where ?

I mentioned earlier a post on frogatto blog about the danger of setting the bar too high for your monsters adaptiveness. E.g. it would be pointless to develop A* pathfinding so that lakitu can track you in a caves maze. Yet, when I explained Didier that I froze development with a list of fixes before the next release and things that would be allowed to be missing, he raised an eyebrow at his son's game screen and wondered in a laugh whether an eraser stuck on the ceiling, twisting like a fly in a spider's web qualified as "it doesn't stop moving for some coder-could-guess reason".

(/metagolf) Si le sommet d'une gomme touche le plafond d'une plateforme, elle y reste parfois coincée. J'en ai shooté une avec un taille-crayon et elle a reculé de manière statique jusqu'à atteindre un mur. Peut-être revoir la FSM ?

En effet. Et ce n'est pas le seul point sur lequel Armitage, concepteur de MetaGolf, a raison. J'avais suivi le conseil des dévelopeurs de Frogatto et prévu mes monstres pour qu'ils aient le bon comportement (sauter, faire demi-tour, continuer à sauter) dans le bon environnement (sol plat, ciel dégagé, faible brise au NNO ...). Mais que le joueur passe par là et ouvre la route vers le bas du niveau et les gommes peuvent le suivre -- bien qu'en général, elles éviteront puisqu'elles sont programmées pour éviter les trous.


The thing is I crafted RectoVerso's behaviour so that it should stay confined in some area, and ensured no issues could arise in those areas ... i.e. the ceiling is high enough, and discontiunity of the ground -- rather than walls -- define when RectoVerso turns back. But at some point, by opening the path to the lower part of the level, you also allow some RectoVerso to enter a place that wasn't designed for them: ceilings, books stacked onto each other, etc.
Playtesting showed that it happens more often than I'd ever have expected, so I took the time to fix those testpoints.

RARE! Rectoverso went down!

Qu'est ce qui change, donc, entre la version qui marche et la précédente ? L'utilisation de l'enregistrement de la vitesse d'impact en cas de choc (GobGravityController), et remise à zéro de cette valeur après qu'elle ait été utilisée pour que le contrôleur n'hésite pas à la ré-enregistrer au coup suivant.
Avant, toute impossibilité de continuer à avancer pendant un saut était interprété comme "arrivé au sol", maintenant, on se sert de la vitesse d'impact pour détecter l'arrivée dans un mur horizontal (impact_x <> 0) ou dans un plafond (impact_y < 0).  

PS: because blador can sit in wall when carried, it can also be thrown while being in a wall. Can we do something to fix this ? Yes! just update freemove mask makes him stay within the level. If we truly want so, it could also repel Bilou if getting too close (e.g. don't end up with Blador hiding Bilou's body completely when getting into a wall.