Sunday, August 08, 2010

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.

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"). 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).

3 comments:

PypeBros said...

Pour ce qui est du "saut maudit" il semblerait que le problème provienne directement du GravityController:
if (gob[1]*(gob[1]-16)<=0) doit être remplacé par
if (gob[1]*ys<=0)
ys capture la valeur de gob[1] au début de la méthode think().

cyborgjeff said...

Hé clairement "Apple Assault" offre clairement plus d'intérêt ludique, que le premier objectif de promenade du premier projet ;)

PypeBros said...

@cj: oui, c'était l'idée: faire de la prochaine release un jeu et pas juste un autre gedsdemo.nds