L'avis des alpha-testeurs

Petit passage chez mes n'veux hier, avec l'inévitable (et attendue :) scéance de test du Bilou en cours ... sans même m'avoir laissé le temps de faire une démo à mon beau-frère, cette fois-ci, soit dit en passant. Le côté le plus positif, c'est sans doute qu'Apple Assault a facilement tenu les gamins 2 heures avant qu'ils ne me réclament un autre jeu.

J'avais voulu ajouter rapidos la gestion du "game over" (le jeu fonctionnant pour l'instant avec des vies infinies). Ca n'aurait pas dû être plus compliqué que de transformer

let c2 = 5  # hitpoints
c2.action = level(green2.cmd)

en

let c2 = 5  # hitpoints
# let c3 = 3 # lives, only in green0
c2.action = level(green1.cmd,d3) # try again
c3.action = level(green0.cmd)    # game over

l'idée étant que l'action associée à un compteur est exécutée lorsque celui-ci atteint 0. Le code de bilou.cmd est déjà rempli de d2 pour décrémenter le nombre de hitpoints chaque fois que Bilou se prend une mandale, il restait à ajouter le retrait d'une vie chaque fois qu'on recharge le niveau avec d3, qui aurait à son tour provoqué le chargement de l'écran-menu (green0.cmd) lorsque toutes les vies ont été consommées.

I'm happy to see my nephews (eagerly) expecting to try my latest Bilou demo. They did not even let me show it to my step-brother first this time. And the good news is that Apple Assault easily held for 2 hours before the kids asked me for something else!

I tried to add a "game over" feature to the game: reseting to the title screen when you exhausted your 3 attempts. That usually helps kids turning the DS around, and it is more fair to everyone if they don't have to try a harder level just because that's where their elder sibling failed. It should have been a matter of adding one action to the counter #3 like above, and decreasing it as we reload the level ... But it did not work.

Sauf que ça ne marche pas.

C'est à dire: les vies diminuent bien, mais on reste malgré tout sur le niveau en cours sans jamais faire le retour vers le menu. Je subodore quelque chose du genre

eval_expression(d3)
 decrement_counter(c3)
  execute_action(level(green0))
   setNextLevel("green0.cmd")
   switchToLoaderWindowAsap()
  action_performed
 expression_performed
execute_action(level(green1))
 setNextLevel("green1.cmd")
 switchToLoaderWindowAsap()
action_performed

ce qui écraserait la demande de passer au "niveau 0" lors de setNextLevel("green1.cmd").

I think the core is that loading a level does not have an immediate effect: it just saves the name of the level to load, and loading will happen afterwards. And the two actions are nested, so the second half of "when you're out of health, reload" erases what "when you're out of tries, game over" had done.

And unforutnately, I cannot try to fix it because the current code is only on a hard drive in the lab, powered off because we're about to replace the floor at the office.

Je ne peux malheureusement pas le vérifier avant lundi: le CVS n'est pas à jour et mon PC du bureau est actuellement débranché dans le labo vu qu'on change la moquette la semaine prochaine.

Plus gênant, on dirait bien que le problème du saut-qui-ne-devient-pas-une-chute (et donc qui n'écrase pas les pommes) a réapparu. Difficile pour moi de le traquer: il semble lié à la manière dont on se sert des boutons (durée de la pression, etc). Et clairement, je dois revoir les contrôles: X = sauter, B = frapper, rien à faire, les gamins s'y perdent. Autre option pour rendre le jeu un peu plus intéressant: permutter aléatoirement les niveaux 2 et 3 à chaque partie (à la Qwak).

There's another issue to solve: sometimes jumping does not chain to falling, and that means we cannot stomp apples. It might be linked to how long kids press the buttons, which is tricky for me to replicate. And obviously, X=Jump, B=Punch isn't intuitive for the kids.

Oh, and maybe I could randomly swap levels 2 and 3 during each play, like Qwak does. That might increase replayability...