à l'eau ?

J'imagine que ça devait être la prochaine chose à faire: s'assurer que Bilou sache rentrer dans l'eau et que les mouvements quand il s'y trouve soient différents de ceux dans l'air. C'est encore assez primitif, mais ça commence à marcher.

Let's dive in: the last demo was nice, but it sure felt awkward to have the water behave as a solid platform. I suppose it's a mandatory to-do item before I release something new: make sure the water feels more like water. It will be perfectible, of course. I don't intend to make it look more like water at this iteration, but at least ensure that I can detect when Bilou is entering water and make him act differently. And that is slowly getting in shape... 

J'ai finalement pris l'approche envisagée dans mes notes de l'an dernier (ou 2 ans ?): une bande de tiles haute comme Bilou qui autorise à la fois de tomber et de nager. La surface est dessinée à peu près à mi-hauteur de cette bande.

Du coup, quand Bilou rencontre enfin de "l'eau profonde" dans laquelle il n'est plus possible de tomber, il est déjà capable de nager là où il se trouve.

ça ne fonctionnerait pas aussi facilement avec un personnage plus gros comme ce poisson, mais on y est pas encore, au gros poisson (je n'en ai même pas dans mes cartons pour 'Dreamland', alors ...)

trivia: the animated gif above is about 100KB. The one I initially captured was over 1.5MB due to scrolling. I had to create a 'dontmove.cmd' object and give it the focus so I could capture the proper sequence. If you look carefully above the water surface, you can spot it.

There's one thing I'd like to get fixed soon: when you reach back the surface, you're stopped straight. That should not happen, but I do not seem to be able to fix it with a transition. This is a job for a revived "muad-debugging" session: it would let me see step by step why no transition is taken by re-playing the think() function after I detected yspeed == 0.

edit: I'll have to write a dedicated 'in-water' controller: hacking with 'increase' and 'freemove' doesn't produce anything convincing even after freemove is fixed so that it fails at the surface.

Flexible!

I remember how adding bounciness to the erasers bumpers felt and how I immediately wanted to have some erasers all over the games to be bouncing as much as I could. So wouldn't it be a shame if the branches of the Green Zone were all static platforms while they could be slightly bouncing you higher instead?

Les gommes qui rebondissent, c'était bien gai. Surtout quand elles se sont mises à bouger en réagissant à notre présence, au point que j'avais envie d'en rajouter partout dans le jeu. Du coup, en repassant sur le level design de la green zone, je me suis dit que ce serait dommage que les branches des arbres restent raides comme des piquets alors qu'elles aussi pourraient nous propulser dans les hauteurs. Oh je ne parle pas d'un bumper à la Sonic, mais si ça pouvait nous faire monter déjà de 1.5 blocs de plus que le saut standard (3.5 blocs), ce serait chouettos.

 Note that I don't meant to change them into Sonic-like bumpers. I said "slightly higher", like your jump would be 5 blocks high rather than 3.5, but still high enough to make the trip fun, and the top of the trees higher to reach without cluttering the screen with leaves.

I don't know yet whether I can do that with animated tiles alone or whether I need to switch to sprites while animating, and then back to tiles à la Super Mario brick blocks.

And before I'll dig deeper into such technical thoughts, I wanted to check what it'd look like. Apparently, just lifting tiles up and down by 1 pixels would produce a decent effect. That was quite some month ago. (you can't notice it, but there are two frames (one full-low and one full-high) merged into that picture).

Après un petit essai en torturant une ancienne capture d'écran, la première question sur laquelle je me penche c'est "tiles ou sprites". En clair, la branche va-t'elle se comporter comme un 'monstre' fort peu mobile ou une pente un peu bizarre. Avec un effet correct rien qu'en décalant d'un pixel de plus à chaque prochain tile, que je n'ai malheureusement pas 'filmé'.

Depuis, j'ai eu l'occasion de faire un test avec AnimEDS -- beaucoup moins concluant -- et de recompter le nombre de fois qu'une telle "branche" est présente dans les différents niveaux déjà réalisés pour la Green Zone. A savoir un maximum de 4. A ce stade-là, je peux franchement tolérer une approche "100% sprites". Même pas besoin de passer d'une image "décor" à une image "sprites" à la demande comme pour les bloc-question de Super Mario quand on les bouscule. En tous cas, pour Bilou's Dreamland, je vais prendre le risque de supposer que je n'ai pas besoin de faire des optimisations là-dessus.

Last week, I did some more tests with AnimEDS but I couldn't come with a convincing animation for the branch (modeled as some set of green balls). Also, I counted how many such 'branches' I have in existing Green Zone levels, and there is at most 4 of them per level. So there is no real pressure to do this 'made of tiles' rather than 'made of sprites', so the upcoming Bilou's Dreamland game will be a test of whether doing such level elements with sprites is a working strategy.

Et du coup, si c'est du "tout Sprite", pourquoi ne pas se faire plaisir et coder quelque-chose à base d'une animation d'un 'squelette' qui indiquerait où placer les sprites plutôt que d'animer à la main ? Avec un angle égal entre chaque segment, on a un rendu assez fidèle de 'branche qui plie'. En variant la valeur de l'angle, on peut redresser la branche, etc. tout ça fait des schémas assez sympa à dessiner...

I think I'd also check whether such things can be animated based on a coded skeletton rather than with pre-built pixels. Or at least I could be tempted to do that, but it could turn out to be a bad move, despite it having some definitive appeal. Dedicated pixels could provide better motion that code-driven shifts of still pictures.

I mean, look at those neat diagrams where adding a constant alpha angle at each segment produces a nicely curved branch, and how applying a weight at the middle of the branch only curves one half, and let the other half unchanged. And how having a maximum-alpha threshold will affect how easily the branch bends with weight.

But ultimately, the object isn't that big. It might turn out that weight-at-the-edge only differs from weight-in-the-midle by a few pixels. And similarly, a 'big bounce' and a 'small bounce' might differ only by not using extreme frames.

Mais ce n'est pas forcément l'approche qui donnera l'animation la plus sympa. En particulier compte tenu du fait que la branche à animer n'est pas bien longue.

Cogitons un peu. Si je donne une pente d'1 pixel de dénivelé au bout de 8 pixels en avant pour le premier segment, le 2eme segment, devrait avoir un dénivelé de 2:8, puis on sera à 3:8, et ainsi de suite. Avec cette valeur de alpha, une branche de 6 segments de 8 pixels peut déjà s'approcher d'une pente à 45°.

Mais surtout, ça me donne une manière facile de tracer ce genre de courbe dans SEDS et de tester des animations de baguettes diverses (raides comme une latte ou souples comme une branche de sapin) à partir de 4 valeurs de courbure et une inclinaison maximum à 4:8 (valeur à partir de laquelle il faudra 'raccourcir' le traît de 10% pour tenir compte de sa diagonale).

Augmentons la Gravité ?

J'ai eu l'honneur (et un peu la chance, il faut l'avouer) d'avoir un retour de Romain Claude -- dévelopeur principal de Splashers sur mon School Rush. Un feedback assez technique et qui ne sera pas facile à prendre en compte, parce qu'on s'attaque ici au coeur du gameplay.

Mon principal retour pour le moment concerne la prise en main, que je trouve assez raide. De plus, le fait que le jeu soit assez mou rend le tout assez hardcore, même en facile ... Côté contrôles vous devriez avoir un air control progressif (de moins souple à beaucoup plus souple), et ceci marié à une gravité plus forte rendra la prise en main plus réactive et agréable. Par contre pour retrouver la même hauteur de saut il faudra augmenter la valeur de l'impulsion.

I'm honoured and proud that Romain, main designer of the platformer "Splasher" took the time to try and give detailed and technical comment on my own "School Rush". In the upcoming weeks, I'll likely be busy understanding the implications of his proposals and doing attempts to adjust the gameplay of SchoolRush accordingly.

The first suggestion is to increase the gravity to get more a reactive experience -- which echoes a comment from Kirby Kid in a previous iteration. That's not something to be taken lightly, though. Many things in the game depends on the gravity. Changing it by a ration g'/g means that you have to modify the jump impulse v1 so that the maximum height of the jump -- v1²/2g -- remains constant. But even so, the amount of time you stay in the air is reduced due to the increased gravity, meaning that the distance you can clear with a jump is shortened.

Mais changer la gravité, c'est changer beaucoup de chose. En plus d'ajuster la puissance de l'impulsion, je dois aussi ajuster la vitesse de déplacement de Bilou puisque le temps qu'il passe en l'air, lui a été réduit. Sans celà, il faudrait revoir tous les obstacles du jeu.

En fait, une fois tous les paramètres dépendants de la gravité réajustés, on a le même jeu mais avec le temps accéléré. Ce n'est pas déplaisant, mais ça va demander aux joueurs d'être plus alerte, parce que du coup, je vais devoir aussi augmenter la vitesse de l'encre sans ça elle est complètement à la traine. Peut-être devrai-je aussi accélérer les pendats...

By increasing the walking and the jumping speed of Bilou with the appropriate factor, I can keep the levels unchanged and enjoy a more engaging gameplay. I'll have to speed up the rise of the ink: at the moment, the game has turned too easy and I might also have to speed up pendats, so that Bilou don't outrun them too easily, which will shrink the response time allowed to the player (to 86% of the current value for g'/g=4/3) ... but it still leaves 500ms+ to react, so that should work.

J'essaierai celà dit d'éviter "l'effet Meat Boy" si je le peux, à savoir d'avoir le contrôle en l'air tellement élevé que l'on finit par "glisser" dans l'air et se déplacer plus vite horizontalement que verticalement. Mais en ajustant la vitesse horizontale maximale, il devrait y avoir moyen d'éviter ça.

Directly linked to the change of gravity, Romain suggests progressive air control. The current code controlling Bilou has some momentum while mid-air with an acceleration that is 1/2 of the one you have on the ground.

In his interview about Splasher, Romain says:

Air control is a touchy subject: you need sufficient control so that player can compensate for an imperfect impulse (imperfect timing or speed) while still having an interesting skill floor, but not give too strong air control, else the player will [go wild at uncontrolled speed] at the slightest move of the joystick.

To balance things in Splashers, Romain used delays, so that the air control just after the impulse is not as strong as it is some frames later.

This happens in Super Meat Boy too, with a character that initially struggles to work against its original impulse, but that gets increasing amplitude as you maintain the joystick pushed into one direction. To be honest, Super Meat Boy isn't one of my reference in terms of gameplay. I would even consider it as a counter-example of convincing physics

Dans le "School Rush" actuel, j'ai un système qui encourage le joueur à prendre le temps de courir avant de sauter: une fois en l'air, on peut ralentir et faire demi-tour (Bilou reste tout de même un explorateur de l'espace, ça offre quelques mouvements inaccessibles aux simples humains), mais on ne pourra jamais atteindre à nouveau la vitesse maximale avant d'avoir touché le sol pour courir à nouveau.

Ma première tentative pour m'approcher du "contrôle de plus en plus souple" (que je traduis par "augmentation linéaire de l'accélération horizontale avec le temps passé en l'air") consistait simplement à autoriser une vitesse horizontale plus grande en phase descendante par rapport à la phase ascendante. Mais ça, ça n'a pas été un succès.

speed-up letters ?

One of the last things I need to add in Bilou: School Rush is meaning for the collectible letters. I have plan to let the player use them in a sort of shop, but I also acknowledge Kirby Kid when he says it is a shame they aren't encouraging the player to play well, but rather to slow down, grab them, and then keep moving.

It's been a few month I'm growing the idea to use a special type of letter for speed runners (e.g. ok, you won't be able to get all the bonuses in normal or hard mode, but can you get at least all the Rs ?). That would keep the game challenging for people who play it for the challenge and nice and friendly for kids toying around in easy mode.

Then I came with a nice function those letters could have. What if every time you hit an R, it would boost your speed by e.g. 10% ?

afterthought: School Rush got 'terminated' without actually trying that. I eventually just allowed letters to provide 1-UPs. It still does't goes "can you play well enough to collect these ?" but instead "have you played well enough to afford collecting these ?" or "will you play well enough to afford leaving these behind and rushing for the ultimate challenge".

necroedit: I've actually played a game, back then, that features that kind of speed-boost-power-ups, and that game is SuperFrog. And I remember it was annoying to be sent back to 'normal' speed once you're killed. If I was to feature something like that in a game, I'd at least have to do something like Shovel Knight floating treasures so you *could* recover most (if not full) speed boost without having to travel to tons of levels again.

It might work better if each speed boosts would bring you significant speed up (by 50% or maybe even doubling max speed) that would work only temporarily ... ehm ... wait ... That's Sonic's shoes.

Deuxième essai pour StraightThrow.

Je n'ai pas grand-chose de solide à opposer au commentaire de Zim comme quoi le lancer de School Rush manque de punch. En fait, en voulant faire les petits dessins-tutoriels pour l'action "lancer un taille-crayon", je me rends compte que la seule façon de le montrer, c'est avec un taille-crayon qui part en ligne droite vers sa cible. Un "Straight Throw", en somme.

Je fais donc un essai de gameplay: B fait un Straight-Throw, UP+B fait un Classic-Throw. Ainsi, je fais du cas de figure le plus important l'action par défaut tout en donnant de la marge pour planter un blador sur un crayon ou placer une SpongeBop pas trop loin dans l'encre.

• [done] rebondir sur un ennemi pourrait faire sauter plus haut
• [done] lancer manque de punch (ça ne va pas très loin), si l'on pouvait contrôler la distance et la direction rendrait le maniement plus jouissif (l'impression de faire ce qu'on veut)
• [done] lancer en pleine course pourrait augmenter la portée du "projectile" (il me semble que c'était pas possible)

Lancer plus fort en pleine course ne donnait rien avec le Classic-Throw, parce qu'il devenait impossible de juger de la trajectoire. Avec Straight-Throw, ça ne devrait plus être autant un soucis, et ça encourage le joueur à prendre de la vitesse, ce qui est le point central de School Rush.

Remember I said "straight throw" as a power-up didn't convince me ? Yet when it is time for me to illustrate "you can stun pendats with a blador", what naturally comes out is a straight throw. So it seems Zim wisely pointed out the lack of power in the current (classical) THROW. I changed the way impulse from Bilou is conveyed to thrown items so I can have "straight-throw" by default and "classical throw" on-demand with UP+B. That feels much more natural in this game, altough less original and possibly less suited to the Big Adventure that is yet to come.


Edit: I'm not sure players will feel that the blador is thrown further as they move faster, but at least they will not get the feeling that they're reaching it back.  Another mechanic to change in a similar way would be to require double-B to use Big Punch.

Note to future self: remember how you spent displeasant hour trying to figure out the reason for a Guru Meditation after you compiled this TryThrow.nds from the mercurial sources in Trusty Tahr. Remember how you promised yourself to spend at least equivalent amount of time on a "build.sh" script that would make the start-of-work from a fresh hg clone reliable.

• [done] update spons.cmd.c so that it also obeys two-dimensional impulse as the bladors do.
• [done] merge in "hang-on-spons" when Bilou miss an AIRHOP auto-move.

J'ai tenté le "straight throw"

Une impulsion de départ un rien différente, et je me rapproche du "lancer horizontal", dernier élément style "power-up" auquel je pensais pour School Rush. Mais ça ne marche pas. Vérifiez vous-même. Ok, on a fortement élargi la portée du dumblador lancé (la zone où sa courbe croise la hitbox des ennemis), mais le même lancé pour SpongeBop donne quelque-chose de complétement inutilisable.

I tried giving thrown bladors more range ... something towards "straight throw", but it is quite a failure. it works fine when used as weapon, but all the other throw-related actions (floating spongebops, bladors turned into platforms) become impossible to use due to the difficulty to guess where things will land -- and whether you'll be able to reach the "platform" you created.

C'est qu'il ne suffit pas de lancer Spongebop pour flotter sur l'encre: encore faut-il être capable de sauter jusque là. Et assez rapidement, ça cesse d'être possible à moins de faire un saut couru parfait. J'ai tenté de donner aux deux une trajectoire distincte, mais le résultat n'est vraiment pas convaincant.

I had plans to have Straight Throw available as soon as you collect a BigPunch power-up. Your punch power has increased, so you throw faster. But that makes the elementary "regular throw" harder to master because you'll have to learn two curves rather than just one. The solution for making them both available when BigPunch is collected is quite obvious: have Straight Throw activated by charging your throw. But I precisely noted that I didn't want to introduce another mechanic in School Rush. Maybe holding the button down to charge would work correctly in this game ?

Air Grab

On s'approche, on s'accroche ... Les travaux sur les zones de collisions contrôlées depuis l'éditeur d'animations portent enfin leur fruits. Il y a maintenant un état dédié dans le comportement de Bilou pour "je pirouette en l'air pour attraper quelque-chose".

At last, the track for controlling hitbox activation through animation is paying off. I have been able to give Bilou a dedicated state where he's checking three directions for something to pick or ride on. I intend to use that both to ease swinging on spongebops and allowing high-paced dumblador grabbing. In the "anniversary level", using spongebop to move along was planned as the hard path. The way that the skilled player would prefer because it leads to faster results as opposed to wandering on the ground. They still had that role when I added "*deline's level" as preliminary experience to the "true level" of the school zone, but the levels are definitely more fun to play when you mastered spongebop riding (left alone the 'sponge jump'). So I want to make more players try to use them.

• Dedicated "grab-mid-air" animation and gameplay state makes it obvious to the player that something happen, and how it spans in space-time.
• The animation itself is fun. J.l.n, my 2-year-old boy goes laughing when he realize he can press A/B buttons to make Bilou roll mid-air in a flash. And fun is important in a video game: that's our primary reward.
• Moving from demanding hitbox (purple one on picture below) to welcoming hitbox (light-blue one) will make it more open to learning.
• You'll still have to learn how your speed evolves with the swing if you want to reach high places or gain stupendous momentum. The potential for power-play is not lost.

Au-delà de la performance technique, l'idée est d'agrandir la marge de manoeuvre des joueurs qui veulent s'accrocher à une éponge. J'ai tenté de reporter sur l'image ci-contre la marge de manoeuvre avant (en mauve) et après (en bleu clair). En rendant le fait d'attraper l'éponge moins élitiste, j'espère -- selon les conseils de KirbyKid -- les rendre aussi plus amusantes.

Une chose, par contre, n'a pas changé: Bilou est toujours centré au-dessus de l'éponge quand il s'y accroche. Du coup, agripper une éponge alors qu'on arrive à côté d'elle produisait un décalage brusque de Bilou. Je tente donc un élément inédit dans le gameplay: une transition pendant laquelle Bilou, roulé en boule pirouette pour revenir par-dessus l'éponge mais dans une forme de pilotage automatique. Il est déjà lié à l'éponge et se dirige automatiquement vers elle, même si elle fait demi-tour et s'y accroche dès qu'il entre en contact avec elle.

I had one concern, though, about the immediate coordinates update that makes Bilou appear centered on top of the spongebop immediately after you hit its side with your hand. Piet and Pierrick, both co-author of the very first Bilou game, suggested that I should "cheat a bit with physics so that the game gets easier for the player", but I'm not confident with such approaches. Yet, it wouldn't be fun to get merely a bounce if you hit the spongebop from the side when trying to grab, so I give a try something new in Bilou's behaviour: temporary automatic control. When you'd expect Bilou to grab and climb the spongebop, he'll actually do it by a rolling bounce in the air where he'll mag(net)ically align to Spongebop position and start riding when reaching the proper position. Accelerations faster than what you could reach manually are tolerated in this state, and all you have to do is hold the (B) button down and hope for hitting no ceiling.

I'll submit that to the S-testing team tomorrow. That may be the biggest improvement since the release of "School Rush" game. Stay tuned.

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.

Premier encrier.

Enfin! le premier encrier qui se promène dans le jeu de Bilou. Je n'étais jamais arrivé jusque là dans la version "BASIC". Voyez vous-même (.nds homebrew).
Maintenant, on va *vraiment* pouvoir commencer. L'encrier doit pousser Bilou, le repousser en cas de collision en l'air, mais aussi emporter Bilou.
Inkjet floats around, special blocks (not yet invisible, for debugging reasons) guide the path followed... I'm ready to start with the "new collision" mechanisms. And I'm curious to know how many times you manage to jump over the 48-pixel pencil in a row.

(Et si vous allez vous promener à la gauche de la map, vous pouvez essayer de sauter par-dessus le crayon de 48 pixels pour remplir le Quizz de la semaine.)

edit: bon, bin c'était pas franchement le poll qui ait attiré le plus de participation, mais avec la puissance du saut de Bilou revu légèrement à la hausse, les obstacles de 48 pixels de haut devraient maintenant offrir juste le bon dosage de difficulté.

Quelle taille de crayon ?

Once again, I'm stopped at a development cross-roads. Mostly due to IRL, admittedly, but stopped anyway. I decided to move back SEDS update to "not-a-priority" level as soon as I realised that I had no gameplay idea relying on slope angles variations in the school zone.
I have a "thread" of activity that insist on bringing life to the inkjet. Pixel art is ready, fundamental parts of the behaviour "should work", but it's not operational yet.

Par où continuer ? Les pentes supplémentaires, ce n'est pas franchement une priorité. J'ai bien progressé sur inkjet, j'ai du pixel art qui est prêt, mais ça chipotte un peu au niveau du GobScript. J'ai regardé de plus près le coup de la "corde qui pendouille" et couvert 2 ou 3 pages de formules et de schémas UML, mais pour le rendu, j'aurai certainement besoin du support 3D.

I invested some time into sorting out that "animated rope" thing, and I now have about 3 pages covered with UML diagrams, mathematicae formulae, code snippets and occasionally a gag featuring Bilou and Bouli. So the model and controller aspects are mostly solved. Yet, I haven't figured an obvious way to view the bookmarks that Bilou will hang on, so it starts depending on 3D layer as well, which in turn asks for pendats to come to live.

Alors, quitte à se taper la partie "3D", autant en profiter pour enfin amener le crayon-soldat sur le terrain, non ? Le hic c'est que mes dernières tentatives pour animer côte à côte Bilou et un de ces crayons n'ont pas franchement été convaincantes. Au point que j'hésite même sur la taille à donner au crayon. 40 pixels de haut, Bilou pourra sans trop de problèmes passer par-dessus. 48, c'est peut-être mieux, mais aussi peut-être trop haut pour les capacités actuelles de Bilou

So I converted gbatek into an epub and started studying the options offered by NDS 3D rendering yesterday evening. That opens the door to some pendats, the long-awaited monsters that took over the Owl School. Meanwhile, I did some 2D attempts to animate a pendat, both in AnimEDS and later in flipnote studio, and I realised that I had no clear idea of the size pendat should have compared to Bilou. So far, Bilou should be able to clear a 40-pixels-high ennemy with a regular jump, and I don't know about a 48-px one, especially one like the pendat who cannot be jumped on.

There are only few scenes in Bilou's Book where Bilou faces a pendat directly. And none (iirc) with the desired proportions, neither for Bilou nor for the pendat. Yet, sketches suggest that Pendat.height > 2 Bilou.height
Curieusement, je n'ai pas énormément de croquis de références. Dans tous, un pendat fait entre 2 et 3 Bilous de haut. Par contre, s'il est possible de passer par-dessus un pendat qui charge, mais de justesse, ce qui demande un timing quasi-parfait. L'idée étant évidemment d'encourager le joueur à se servir des dumbladors pour assommer les crayons ou de profiter d'un obstacle plus haut en bout de chemin de ronde.

Bref, le mieux, ce sera encore de faire le test: combien de fois parvenez vous à passer par-dessus le crayon, à gauche de la map avant de mourir (SchoolTest.nds)

In my design documents, I clearly want that it is possible to clear a jump over a charging pendat, but also that it is tricky to do, requiring near-perfect timing when on flat ground.

So let's try it out. Can we clear a jump over a 3-tile-high static pencil ? Is it interesting to have Bilou jumping slightly higher when he walks(/runs?) like in Super Mario Bros ? If so, is it interesting to have Bilou unable to jump over a pendat unless he walk-jump it ?

Courir ?

En testant la démo "Back to School", Facet regrettait l'absence d'un bouton "RUN" dans le comportement actuel de Bilou. D'un côté, un mini-jeu comme "nuts'n'bolts" ne devrait pas avoir besoin d'un tel bouton (pas de grand trou à franchir, et un gameplay plus basé sur le timing que sur les réflexes). D'autre part, je ne suis pas encore décidé sur le mode de fonctionnement de la course.

Il faut un bouton pour courir, ça c'est assez évident. Mais sur le DPAD ou comme bouton d'action ? Est-il vraiment indispensable de le garder enfoncé tant qu'on veut courir ? A la fin d'une partie de Mario, on finit par attraper des crampes... Pourtant j'aime bien la phase "gagner de la vitesse" que ce genre d'approche permet, par rapport au mode "un coup de bouton X et ça y est, on court à pleine vitesse" dans Rayman. Au point que Peach et Shantae ont carrément un bouton "ne pas courir".

Have you felt the lack of a RUN mechanics in the latest Bilou demo too ? Facet surely did.

I was really missing a run button and the little pauses and lack of inertia take away from the fluidity. I'd like to bounce and slide more.

After I spent some time thinking about it, it becomes clear that "Bilou's adventure" will have such a RUN mechanics, where speed progressively increases, but that this would be absent of "Nuts and Bolts" (and possibly other in-between arcade games featuring Bilou).

I would like, however, to be able to release the button, and not force the power-player to keep RUN button pressed for 30 minutes if he wants to speed-run the game. Fundamentally, what I'd love to try is a sort of "cruise control" behaviour, where you press a button only when you want the DPAD to make you "accelerate". Once you release that button, you keep moving at the reached speed until you release the DPAD as well.

Mon impression, c'est que le fait d'accélérer progressivement ou non peut être découplé du mécanisme de "lecture" du gamepad. En d'autre termes, on pourrait avoir un bouton qui n'est pas "courir", mais "accélerer". Si le joueur mêne Bilou dans une direction sans enfoncer ce bouton, Bilou ne change pas d'allure. Par contre, dès que le bouton "accélerer" est enfoncé, la vitesse de Bilou augmente (plus ou moins) progressivement jusqu'à la vitesse maximale. Que celle-ci ait été atteinte ou non, Bilou conservera la vitesse acquise si on relâche le bouton d'accélération.

The poll is now open: which sort of RUN do you actually prefer ?
Mario: 62%
Rayman (PSX): 12%
Shantae: 0%
Kirby: 0%
Bilou (new): 25%

OAM priority issues

I'm about to introduce significant complexity in the game engine for the purpose of displaying some compound animations properly. I've took the time to think about it (while drilling staircase for a kid-safety-barrier, if you ask :P) and figured out how to sort all the needed details. I just missed one point: this is absolutely not the only place where I need OAM depth-sorting.

Remember of Apple Assault's frenzy, and how you could end up not seeing that appleman that runs towards you because it's actually sneaking behind a row of stunned applemen ? That's never been fixed to date because I had no way to instruct the game engine that "those stunned applemen should be moved to the background".

Then I remembered of that "talk" by Rafael Baptista about resource management on the GBA. Before he entered the core meat of his talk, he suggested that copying OAM entries (you can think of them as sprite descriptors) could be the right time to follow a Z-order linked list and keep the "hardware" OAM entries and their "shadow" counterpart. Nice move, although I still wonder how he manages the scaling/rotation matrices along the way...

I used to have a large, one-chunk DMA transfer of all the sprites & rotation information. I would have to split that in 3-u16 slices. That sounds like I'll have to pay sverx's report on memory copies performance benchmark a second - and more careful - read... and possibly opt for an intermediate - sorted, but in-cache - version out of the vblank period and then DMA that into VRAM when the vblank is hit.

A final consideration: there is little chance that I need a fine-grained Z-sorting. low/normal/high priority should be enough in 99% of the cases, and the remaining case could likely be "sorted" out at GOB instanciation by internally sorting the OAMs the GOB received.

edit: I asked myself the right question: 'is that move out of DMA sync'ing gonna cost me framerate or not ?'. From that point on, I hacked a modified version of my game engine, that uses CPU-driven copy with merging of OAM and rotations into one single table (as the DS hardware expects) and started Apple Assault with aggressivity setting turned at max (so many apples that you'll experience "ghost" berry bats and shots). Good news: it still works flawlessly (that is, I can't observe any slowdown). Next: the depth-re-ordering...

edit++: just applied silly reverse-priority and order-enforcement-at-sync() in an AppleAssault check: it proves the concept: now Bilou can sneak behind stunned applemen. Useless, but you can't deny it's no longer the default z-order that is applied.

edit+++: checked that a (Simple)Gob set on zlist[0] appears in front of (Compound)Gobs set on zlist[1]... now I've got to figure out how to use that best to implement the pullmask for my "roll jump" animation ...

Piek's counter

Rencontre-surprise avec Piek, concepteur initial de ce qui a fini par devenir le Bilou que vous connaissez. Et double-combo-bonus: il venait juste de tester de manière plus approfondie Apple Assault (avec contre-expertise de son gamin que je situerais pas loin des 10 ans).

J'ai pensé à quelque chose qui pourrait discipliner un peu parfois un certain chaos... Je m'explique...

L'introduction dans ton code d'une simple variable qui en fait varierai selon la difficulté... Le nombre de pommes maximales en jeu en même temps...

D'une toute petite variable ajoutée, voici les avantages que tu pourrais en retirer...

• Cela permettrait que l'on évite de se planquer dans un coin sûr de la map et les attendre. On serait alors obligé d'aller chercher les pommes au contact et de sortir de sa zone de confort...
• Cela permettrait également d'éviter qu'elles ne sortent toutes à la fois de façon continue et de fait, d'éviter que l'on se retrouve avec 50 pommes groupées en bas de la map où il est très difficile de les battre...
• Cela t'apporterais un "curseur" de difficulté supplémentaire qui te permettrai de réutiliser tes maps mais en augmentant de fait leurs niveau de difficulté... (il est plus facile de se battre contre 5 pommes en même temps que 10 sur la même map)

An old-time fellow pops up while I'm on a walk ... Piek, inventor of the school zone, and initiator of Bilou's early look. He just gave Apple Assault a try with his 10-year-old boy and was eager to report his proposal: an on-screen appleman counter, separated from the 'to-be-defeated' counter. He's got coding background as well, so he came with a code proposal rather than a mere fuzzy feeling, but most importantly, he's a much better retro-gamer than I am, and supported his proposal with a quite complete set of weaknesses in gameplay that his proposal would (likely) fix.

I'll thus likely come back with an Apple Assault 'piek' 1.6 integrating that new counter with other revisions, such as "punch-button-always-has-an-effect-on-baddies", even if the effect is weak, and insufficient to beat them.

La plupart de ces soucis, je les avais déjà identifiés, mais pas vraiment traité avec succès. Mon meilleur coup reste BerryBat qui vient "punir" le joueur qui campe sans affronter les pommes. Mieux doser la quantité de pommes présentes sur la carte ne ferait pas de mal non plus, mais là, toutes mes tentatives ont été des échecs complets. Mais je persévère: ça ne devrait pas me coûter trop cher de faire le test.

Mon inquiétude se situe plutôt sur la manière de "doser" ce paramètre pour que le jeu reste intéressant. Je sais que pour le joueur déterminé, Apple Assault 1.4 + Berry Bat offre un challenge digne de ce nom et pourrait ce content de max_apples_on_screen=128. Pour le gamin de la voisine, qui n'a pas encore maîtrisé le coup de "rebondir puis puncher", 5 pommes au niveau 1, c'est déjà chaud. Probable donc qu'Apple Assault 1.6 introduira un 'bonus/malus' qui permet de récupérer toute sa barre de vie, mais au prix d'une augmentation sensible du nombre maximum de pommes à l'écran. Le baroudeur intrépide verra là une occasion d'aller droit au challenge en faisant des gros points.
Il y a un dernier point que j'aimerais revisiter dans cet Apple Assault 1.6: faire en sorte que le bouton de punch fasse toujours quelque-chose même quand la barre de punch de Bilou est à zéro. Sans doute une sorte de pitchenette à la Worms qui fait juste faire un bond en arrière aux applemen.

Funny enough, it sounded like Piek doesn't remember he's the one who settled the ground for Apple Assault gameplay in first place. I, for sure, haven't forgot ;)

Apple Assault 1.5 : tops & flops

Hey there! Still reading ? great.
Deadlines at work somehow kept me away from my blog these last days, but I've got the time to play myself a little more with my 1.5 release, and I'm not so satisfied I actually released it anymore. If I was doing flash games rather than homebrew on a disintegrating scene, it might have cost me my fans and reputation.

• Berry bat is effective. It forces the player to focus with an acceptable level of frustration.
• Un-clumping makes level 3 less interesting, with most Applemen coming to you even if you don't explore what the level looks like (at least at very high incoming rates)
• With over 60 applemen on screen, there is a number of situation where un-clumping no longer work. Applemen remain stuck in a short place where they constantly collide against each other, and don't seem to "walk" anymore. This in turn slows down the game severely due to the abnormally high amount of events that are generated.
• I failed to solve the cluttering applemen problem. Especially, it remains hard to identify walking applemen that still manoeuvre through a bunch of stunned applemen.

I may return to it later on, for the sake of figuring out what makes the gameplay correct... but right now, the priority will be shifted (back) to make compound anims work and bring the school zone to life. If you've tried A.A-1.5 so far, feel free to fill the poll.

Semaines de dingue au boulot ... et donc pas trop la possibilité d'approcher mon blog à moins de 2 Mbit. Ça m'a par contre donné l'occasion de prendre du recul sur Apple Assault 1.5 ... si la chauve-souris-baie est plutôt réussie, la tentative d'éviter que les pommes ne s'agglutinent sur le haut de l'écran, en revanche, fait plutôt un four. Tout d'abord, les pommes viennent à toi, même si tu ne viens pas aux pommes -- en tout cas dans les niveaux 1 et 3. Ensuite, à partir d'une certaines densité de pommes (au 2eme passage en mode hard, notamment), les pommes commencent à se bloquer l'une-l'autre, à s'agglutiner encore plus sans même plus prendre la peine de se ballader à la recherche de Bilou. Le nombre de collisions pommes-pommes monte en flèche alors qu'il était supposé rester rare parce que provoquant O(N²) tests.

Berry Bat Things

Hey, there! Cleaning up and tuning in are done. If you enjoyed once AppleAssault, but then stopped playing it because you didn't feel the challenge anymore, here's an update that you might love: AppleAssault -- BerryBat Things. The idea is simple: you've got limited time to clear up a level. As long as you punch applemen out of the arena, nothing bad will happen... But if you get lazy and that the applemen count remains the same for too long, a berry bat will come and tease you. You could manage to get rid of it, of course, but then another one will come soon, and then again another and another, again and again until you surrender (or focus on punching Applemen, after all).

So how comes you're still reading this ? Go and download it! -- oh, wait. Better pick the final release

Bilou! Le revoilou! Ok, je suis supposé bosser sur la School zone, mais j'ai une très bonne excuse pour recycler AppleAssault en ce début d'année 2012. J'ai enfin intégré les "berrybats" dans le jeu. Si vous aviez fini par faire le tour du jeu de 2010, autant vous prévenir tout de suite: vous allez faire une rechute!

A priori, le principe est toujours le même: assommez les pommes en leur sautant dessus, puis expédiez-les hors de l'arène d'un bon coup de poing. Ouaip. Sauf que maintenant, si vous passez trop de temps sans dégommer de pomme, une chauve-berrie (berrybat) viendra vous tirer les oreilles. Oh, bien sûr, vous parviendrez sans doute à vous en défaire, mais il en viendra alors encore et encore, de plus en plus vite. Jusqu'à ce que vous vous décidiez à vous concentrer sur la mission première: virer les pommes.

Prêts ? Moteur ... et .... Action!

Oh, and btw, make sure you're voting for the "success" of the new features in the side panel if you've played to v1.4 as well ;)

Unclump'm

Well, I've been using AppleAssault as a regression test when developing the new collision engine ... really just to make sure I'm not broking everything up, as there's nothing in AppleAssault that could benefit from the new engine, anyway. No pushable/carriable ennemies, no platforms. Nothing.

But of course, being in that source tree again (^_^), I wanted to give some ideas a try. The first one was to integrate berrybats in the game, as a way to force the player to focus on defeating applemen, and not just hop around. It now acts like a sort of indirect timer, appearing when you've been unfocused for too long... and appearing again and again until the lesson has been learnt :)
I'll need to work on the timing, though, so that the game doesn't become completely unfair :P

Un nouveau moteur de collision, c'est pas rien. Alors j'utilise AppleAssault pour m'assurer que tout fonctionne toujours bien au fil des modifications, même si la plupart des améliorations (pousser, ramasser, etc) ne sont pas à l'ordre du jour pour ce jeu précis. Mais, vous me connaissez: à trainer dans le code, j'en viens à me dire qu'on pourrait utiliser les chauve-souris pour forcer le joueur à s'attaquer au pommes ...

Un autre point, plus délicat, c'est de faire en sorte que les pommes cessent de se coller les unes aux autres. KirbyKid a raison là-dessus: ça pousse le non-réalisme vraiment trop loin. Je ne veux pas non plus en venir à un comportement de type goomba: il est prévu que les Applemen puissent se croiser s'ils arrivent en face l'un de l'autre, mais on ne devrait pas pouvoir en avoir 10 sur 2 pixels. Il me faut donc un test de collision entre-applemen, mais je vais devoir être prudent si je ne veux pas me retrouver avec des centaines de tests inutiles et vider la batterie de la DS en un rien de temps.

The second thing is linked to Kirby Kid's comments: Applemen tend to stick to each others, overcrowding on platforms, which isn't very realistic. I don't want to go for goombas-like behaviour: Applemen are design to be able to cross each other. Still, there shouldn't be 10 of them on 2 pixels. So I need to have a sort of applemen/applemen collision detection, but that should be handled with care, otherwise I could easily overload the collision engine with hundreds of (unnecessary) checks and dry the DS batteries in no time.

The approach I picked is to take advantage of a small transient state where the Applemen halts in front of a cliff, checking whether it will jump -- which you'd barely notice when playing the game. Only during these 2 frames, it actively checks for other Applemen in its immediate neighbourhood, and get "knocked out" of the platform if there was. Expect a revised .nds file to download in early February, as now, I still need to remove a *lot* of debugging printf ... and have a shower...
Oh, and some coffee would be nice as well... And a commit :) Cheers :)

Mais il y a dans la machine d'état de l'appleman un petit délai où il fait une pause en bout de plate-forme pour décider s'il va sauter ou non. ça pourrait être le bon moment pour tester s'il y a un autre appleman dans les alentours et se faire "éjecter" de la plate-forme si c'est le cas. On va tenter de vous permettre de télécharger ça début février, mais avant ça, j'ai une tonne de printf à retirer ^^"

External Actions

using sound(16,56) as 0	Bilou shoot
using sound(0,60) as 1	Bilou hit
using shgob(state28:= 0 :1 1 :0) as 2	Bilou, right punch
using shgob(state29:= 0 :1 1 ~ :0) as 3	Bilou, left punch
using shgob(state19:=$100 :0 $100 ~ :1) as 4	Bilou, stomped star
using shgob(state19:=$100 ~ :0 $100 ~ :1) as 5	Bilou, other stomped star
using shgob(state0:=D) as 6	throw a fake appleman (?)
using sound(17,64) as 7	Bilou bop
using shgob(state18:= 0 :1 v6 :0) as 8	Bilou, shuriken
using shgob(state0 is e:=D) as 9	throw an appleman

ça fait un peu peur, hein ? C'est ainsi que je définis en "gobscript" les différentes classes C++ qui peuvent être appelées et quels paramètres leur donner. Il ne me restera plus qu'à dire "x4x5x1" lors d'une transition pour qu'on voit deux petites étoiles jaillir de bilou avec un son "ouch". Et si je vous mets ça en ligne, c'est parce que je vous concocte un "mégapunch" à placer entre le "coup de poing de base" et le shuriken dans apple assault ... wait'n'see.

Did I scared you ? This is how you bind external C++ code to transitions in gobscript ... well, you'd still have to specify "x4x5x1" to have small stars shots while you hear an "aouch" sound. Why do I put *that* online, will you ask ? because I needed to have a better overview of those actions so that I pick the proper numbers for the "big punch" action I'm testing right now. Yeah. Big punch. Larger collision box, more apples dispatched, more fun. Wait"n"see :)

edit: Oh Yeah! The "Big Punch" definitely roxx! I still have to fine-tune it, so that e.g. the master player can use it mid-air to knock-out applemen below him; but ... Man! It let me score 10005000 at the hardest difficulty level, and it makes me play less cowardly! I can't wait to have those additional tunes and share a next apple assault release with you!

todo: add a "state%%->self on ... [condition] (action)" mechanism so that we can easily encode the rules for punching while walking, idle, jumping and falling ... and a prio % command in animtions to select the plane on which things are.

Manoeuvre d'évasion β-1 !

Autre petite expérience en cours: les manoeuvres d'évasions. Afin d'éviter les chocs enchaînés, Bilou dispose à présent d'un court laps de temps au moment où il touche le sol pour mettre à profit l'entraînement physique draconien des pilotes de la Stellar Assembly et se mettre hors de portée des coups suivant.

Une variante à l'invulnérabilité temporaire, inspirée des commentaires de KirbyKid (eh oui, encore) qui met l'accent sur les réflexe et le timing du joueur pour échapper à son destin.

Following KirbyKid's advice, I'm also giving a try to an alternative to the typical "temporary invulnerability" of platformers game that -- I think -- would negatively impact challenges I intend to put into Bilou's Adventure. Welcome evasive moves: by pressing A or B with the proper timing when Bilou hit the ground after being hurt, you can dodge the next hit by doing a sommersault that brings you to a safer place. Of course you won't be hurt again while dodging.

It isn't clear, however, that such things do not suffer the very same defects as "regular invulnerability": you could use an evasive-B-move to quickly hop through a funky funghi after being hit by an appleman, for instance.

L'ennui, c'est que même comme ça, un contact volontaire avec un "petit" ennemi (p.ex. un appleman) permet d'utiliser une manoeuvre d'évasion (horizontale) pour passer à travers un ennemi-obstacle (p.ex. Funky Funghi), puisqu'aucune zone de collision n'est définie pendant l'évasion >_<

todo: ajouter une sélection du niveau de difficulté (easy/normal) dans le "niveau 0" ...

They do clump a lot

I've been an attentive reader of KirbyKid's writings on level design for a couple of years, now, so I sent him a copy of Apple Assault v1.1, asking for advices on a few points where my "regular consultants" and I tend to disagree. I was happy and honoured to find his in-depth reply in my mailbox this morning. I'll sure have things to think about and experiments to run in the next weeks.

A force que la plupart de mes "consultants réguliers" (comprenez, CJ, Cyril et Gédéon) me contredisent sur certains choix de design pendant les préparatifs d'AppleAssault, et vu les commentaires peu instructifs récoltés sur dev-fr, j'ai fini par profiter que j'avais un binaire prêt-à-l'emploi pour demander l'avis d'un quasi-pro du level design, j'ai nommé Krazy Kirby Kid. Après quelques échanges de commentaires et d'e-mails, j'ai reçu ce matin sa réponse détaillée dans ma boîte aux lettre, que j'ai ouverte avec une excitation assez proche d'une réponse-du-Père-Noël. Il faut dire que je suis le blog de KirbyKid depuis près de 2 ans et que ses essais sur les "blind-boxes", les "core mechanics" et autre DKART. Un des aspects qui me turlupinait, c'est cette tendance qu'ont les applemen à "s'agglutiner" pour former des chenilles

I had issues with the "wiggler/lemmings" aspect of applemen behaviour, and my initial idea was to make "fall of cliff" somehow probabilistic. KirbyKid pointed out that

I like working with simple predictable enemies. They [Applemen] do clump up a lot though. The issue I have with this is that they can clutter the game (...) [and it] makes it easier for an appleman to sneak behind a stunned appleman and hit you.

La bonne nouvelle, c'est que l'avis extérieur de KirbyKid me motive à faire des expérimentations alors que j'ai plutôt tendance à justifier ma position vis-à-vis de mes "voisins de VTJ". Ou alors il a juste réussi à trouver les arguments vraiment convaincants. Bref, voyons ce qu'on peut faire pour éviter les "grappes" d'applemen, en particulier compte tenu du fait qu'un tel attroupement rend plus difficile l'identification des applemen encore "en course".

Let's experiment another strategy, then ... something more bio-inspired, such as generators that "sense" how many applemen exists in their surrounding and self-inhibit the generation of applemen if a certain density is reached.

state1->state2 on done
state2->state1 on found0
state2->state1 on done [c#applemen# 0 >] (x#throw_appleman# d#applemen#)

Petite idée "bio-inspirée" pour éviter ça: rendre le générateur d'applemen plus sensible à son environnement ... par exemple l'empêcher de générer un nouvel appleman s'il en a vu un récemment. J'ai déjà des zones-de-détections (cf la boîte bleue sur le schéma) que l'appleman utilise pour "voir" Bilou et l'attaquer, c'est le même principe. Sauf qu'ici, celà provoquera le retour anticipé de l'état "sonder l'environnement" (state2) vers l'état "attendre" (state1) alors que la génération d'un nouvel appleman se fait normalement à la fin de l'animation de state2 (à condition qu'il y ait encore des applemen à générer, bien-sûr).

It is actually surprisingly easy to tweak: an additional state (state2) is added to the FSM ruling the generator, which has an "active test area" (depicted in blue) and it will remain in this state only for a few frame, while state1 covers the majority of the inter-applemen delay. We can leave state2 either because an appleman has entered the "sensitive area" of the generator (in which case nothing happens) or because the delay for state2 has expired, and only then we throw a new appleman and decrement the number of applemen still to be generated.

Pour peaufiner, je peux faire en sorte que l'appleman soit à son tour "sensible" à l'annulation d'une génération et du coup "quitte le nid". Ca marche assez bien sur le niveau 1, en tout cas.

An additional tweak allowed the applemen to "sense back" such detection and, when this happens when they're on a cliff, make them jump off. In this way, applemen no longer "stick in their trunk hideout forever" on map #1: after a short time, they will leave the safety of the hollow trees and explore the surroundings. That should make them clump much less, although it's not yet a full-proof solution.

edit: I only gave these new game rules a few tries, but it looks like it doesn't make difficulty increasing with levels. At least, it doesn't make me feel that the game is getting harder, just that the levels are longer and longer to play, and I've been tempted to stop playing when I reached the map #1 with >60 applemen to attract out of there trees. I may need to find something else so that running applemen cannot ambush behind stunned applemen. The fact that the priority of two applemen solely depend on the OAM registers they use doesn't help 0_o


Au final, l'approche n'est pas vraiment concluante. Le niveau 1 est rasoir (sauter pour attirer 60 applemen ou les voir approcher au compte-goutte ... bof. Le niveau 2 déséquilibré (certains "trous" n'auront généré que 2 applemen, et un bug fait que certains restent "cachés" dans leur arbre. Les niveaux 3 et 4 ont leurs générateurs trop loin des applemen et ne sont donc de toutes façons pas affectés. Bref un "compteur global du nombre d'applemen présent à l'écran" aurait été tout aussi (sinon plus) efficace. Je devrais avoir moyen d'arranger les niveaux 1 et 2 avec un "nombre de saut autorisés" défini pour chaque générateur, par contre.

monster_speed = level ;

Ce week-end, petit passage chez Piek -- le "père biologique" de Bilou -- pour découvrir son nouveau "studio" et faire des risettes à sa nouvelle petite puce. L'occasion aussi de lui présenter le gameplay de mon "Apple Assault en gestation".

"Whaa! C'est mortel, comme jeu" me lache son bonhomme de 5 ans, pourtant déjà bien entraîné sur les manettes. Piek explique donc patiemment que c'est normal, que c'est un développement en cours. Au début, un jeu vidéo, on tâtonne, on bricole, jusqu'à ce qu'on ait trouvé les bon règlages. J'oppine du chef et je plussoie. J'explique que là, ce serait plutôt le 3ème ou le 4ème niveau. 42 pommes à dégommer avec 5 points d'énergie, c'est un peu hard quand-même.

I went to visit my friend Piek last week-end, who's the initial author of Bilou character and showed him the in-progress version of Apple Assault. His 5-year-old boy immediately wanted to give it a try, but frowned at the difficulty of clearing those 42 applemen without bumping into deathly Funky Funghies. As I was explaining that I still have to tune the game's difficulty, Piek suggested a more arcade approach: every level you beat increase how many applemen you'll face at the next one and decrease the delay between the appearance of two applemens. I'm now trying to map that on my GOBlang script, but it definitely sounds more appealing that a lame 5-levels minigame.

C'est alors que Piek me propose une idée séduisante: laisser la difficulté augmenter avec le nombre de niveau passés. C'est à dire, ne pas simplement définir 5 niveaux avec une difficulté qui augmente progressivement, mais plutôt

• map = levelmaps[level%nbmaps]
• apples_nb = level * A
• inter_apple_delay = B - level * C

etc. "Comme ça, tu peux voir jusqu'où tu sais aller. Même les tests sont fun. Tu peux passer la console à un pote en disant: 'Je fais 5300 points. Essaie de battre mon record'", ajoute-t'il. Il faudra que j'essaie, en effet. Ca a un côté "pacman-esque" sympa, plus que "j'ai réussi à expédier 10 pommes avant d'être Game Over".

Suivant l'esprit "Another World", ce genre de mécanisme collerait assez bien aux "compteurs" qui me servent à gérer l'énergie de Bilou, les pommes d'un niveau, etc. Du moins, à condition que je puisse définir leur valeur avec une expression, et pas uniquement avec une constante. Heureusement, la lecture des scripts est maintenant suffisamment avancée pour que ce genre de modification puisse avoir lieu sans trop d'arrachage de cheveux.