jeudi, novembre 28, 2013

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.

mercredi, novembre 20, 2013

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.


mardi, novembre 19, 2013

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.

samedi, novembre 16, 2013

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.

vendredi, novembre 15, 2013

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

dimanche, novembre 10, 2013

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.


jeudi, novembre 07, 2013

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.

samedi, novembre 02, 2013

Die and Retry ?

J'ai pu rassembler quelques feedbacks sur le niveau-anniversaire cette semaine, dont celui très attendu de Pierrick... et ce premier Novembre aura aussi été l'occasion de voir le mode "essaie de battre mon record" à l'oeuvre avec les cousin(e)s d'*deline. Je pense que la citation de Pierrick reprend bien la première réaction de la plupart des joueurs:

C'est du pur "die and retry" (c'est pas évident)
Die and retry ... le jeu impitoyable façon Rick Dangerous ou "Les Schtroumpfs d'Infogramme". C'est loin d'être mon modèle, mais c'était clairement celui de mon frère 2 ans avant le niveau de la School Zone quand il dessinait les niveaux de Calimero.

Où sont donc les "coins infogrammes" dans mon jeu ? La chute en aveugle un rien avant la fin du niveau peut clairement en faire partie. J'ai bien essayer de montrer la trajectoire idéale avec des bonus, de sorte qu'il faille prendre le risque de s'écarter de la trajectoire sûre pour faire de gros points mais qu'on soit quand-même guidé vers la zone d'atterissage (presque) sûre...

Really ? is the 20-year anniversary level "die and retry" in the sense of Infogramme's Smurfs, where you have no chance to identify something as being a hazard before you die because of it ? There's cleary a jump-of-faith near the end of the level, where you have to blindly jump and even good reflexes will not give you much chance to evade death if you happen to be on the "wrong side" of the fall. Well, actually, with good reflexes and knowledge of the evasive move that replace invulnerability in my engine, you still can get out provided that you have enough energy remaining.

En revanche, à regarder les enfants de mon beau-frère (6, 10 et 12+ ans) s'essayer à tour de rôle, je constate que dès le début du niveau (et donc du jeu), il est indispensable d'avoir la maîtrise des actions pour ne pas finir empaler sur les pointes de crayons. Les consignes du style "ah, ici, il va falloir courir, sauter au bon moment et ré-appuyer sur A quand tu touches la gomme et garder A enfoncé pour faire un saut assez haut... oui, avec les gouttes d'encre, c'est pas facile, il va falloir partir au bon moment. Aïe. Non. Trop court. Saute pour sortir de là .. encore .. non. trop tard. Tu ferais mieux d'essayer par l'encrier la prochaine fois. Allez, à ta soeur, maintenant."

Mais ils persistent. Ils s'entrainent... il faut dire qu'il n'y a pas grand chose d'autre à faire à part regarder maman finir son cacao chaud. À la fin de l'après-midi, seule la plus jeune continuera à éviter ce "saut de la mort". Ma prochaine mission sera donc de faire un "niveau préparatoire" que même *deline, du haut de ses 4 ans, puisse essayer de finir.

Real-life testing with 3 of my nephew yesterday still turned out to be successful. Having only a few hitpoints before they had to hand the game to their sibling pushed them to improve, and while their initial steps were hazardous and punished by frequent death on the second or third screen, they managed to master the not-so-easy controls (press B timely to grab the sponge, hold it, then quickly release B and press A to clear the first jump). Somehow, the level is missing a sort of preliminary sandbox if I wanted it to be newbies-friendly, but it worked as a good playground for siblings arcade-like competition. Excessive sandbox place would have likely led the youngest to stick in the sandbox and avoid going where the challenge stands, killing the fun for the older kids.

Par contre, un testeur seul de 14 ans, le verdict est assez sévère: après avoir manqué le saut de la mort et le passage des éponges, j'ai droit à "t'as plus le jeu avec yoshi?"

edit: lors d'une discussion approfondie avec Pierrick,
 Bien Rick Dangerous... Tu ne peux pas savoir combien de fois je me suis pris la première rangée de crayons pointus avant de comprendre qu'il fallait se servir de l'encrier pour contourner le problème.
Visiblement, quand un joueur (même drilé au mégaman et autre mario) arrive à ce premier trou, la solution ne vient pas d'elle-même. Courir n'est absolument pas devenu un réflexe à ce stade du jeu. Il faudra que j'en tienne compte dans mes prochaines release.

Comparé au non-tutoriel de Super Mario Bros (les 2 premiers écrans), mon niveau contient au moins deux erreurs criantes.

Le premier crayon ne se contente pas d'être un ennemi à vaincre en sautant par-dessus: il faut une bonne maîtrise du saut pour contourner ce personnage relativement haut et sur lequel on ne peut pas atterrir sans se blesser. En plus, contrairement au goomba, il peut faire demi-tour et devient alors d'autant plus délicat à dépasser. Seule consolation: en le faisant s'approcher un peu plus de la pente initiale, il devient possible de réduire la hauteur du saut nécessaire. (Dans la version g88, le crayon reste un rien trop loin de la latte et on retombera le plus souvent sur sa pointe plutôt que de parvenir à l'enjamber sans heurts).

Compared to SMB level 1-1, I noted the following design mistakes. The first pendat you encounter is not simply a monster you can defeat by stomping it. Actually, you cannot defeat it. You must avoid it, and this is not quite as easy as avoiding a goomba, because it is only a few pixels lower than your maximum jump. Moreover, unlike a goomba, the pendat may turn back just as you jump over it. You don't simply have to estimate the proper jump time given speeds, but also given positions and memorize where the turn-back occurs. I had hoped that the slanted ruler at the start of the level would give Bilou some advantage to make a good jump, but it ends up being a bit too far, and the player is more likely to fall straight on the pendat's spike than clearing the jump when trying to jump off the ruler.

Then comes the first jump-over-the-pit challenge, which is again abnormally complex. You must both run (still an emergent behaviour at that prototype state), jump, and bounce to the maximum height to clear it. Your first attempt is for real. There's no such thing as a "practice area" where the spikes would be replaced by a mere staircase. And if you'd change your mind and decide to look for an alternate path, it is too late: the alternate path is only available *before* you can see the challenge arriving.


Ensuite, le premier saut à effectuer (par dessus les pointes de crayons) est complexe puisqu'il implique à la fois de courir, sauter, rebondir et faire un long saut. Et pour de vrai! ici, pas de "trou pour rire" façon monde 1-1 pour se rendre compte qu'il convient d'être prudent.
Pire encore, le "chemin alternatif" devient hors d'atteinte quand le joueur se rend compte qu'il ne parviendra pas à passer par-dessus les pointes de crayon! (Forcément: c'était un passage secret).

Enfin, si un adulte pratiquant couramment l'Anglais et rompu au jeux vidéos depuis 10 ans n'a pas sais que l'on pouvait courir et avec quelle manip', c'est que ma manip' est contre-intuitive et doit être renseignée plus clairement. Je dois prolonger l'effort sur la gestion de la course de Bilou.