Encre ou pas ?

J'avais voulu pour la prochaine release couvrir un des autres aspects des commentaires de Romain:

Côté [level design], est ce que c'est censé faire partie du jeu normal que l'encre monte tout le temps ? En tout cas, mode facile ou pas, il faut que les joueurs puissent apprendre votre jeu.

Faites vos 2 - 3 premiers niveaux très gentils, avec pourquoi pas des endroits où ça monte mais pas partout et surtout pas au tout début, avec du challenge mais avec pour objectif que je joueur se familiarise le plus possible, s'amuse, dompte, avec le moins de punition possible (c'est chiant, et surtout c'est pas le but). Vous aurez tout le loisir de faire des choses progressivement très hardcore dans les niveaux d'après (3, 4, 5 etc.)

Romain, developer of Splasher, also questioned the way ink is always (~) raising in SchoolRush. "Whatever the difficulty level, the player must be able to learn the game", he argues. "Let your first few level be very soft, maybe with some areas where the ink may raise, but definitely not right at the start. You may put some challenge in, but the goal must be that the player gets confident about the gameplay, has fun and is allowed to master [basic controls] without getting penalties for every bad move. You'll have plenty of levels to get slowly to a hardcore difficulty level"

I must confess this is one of the tip he gave I had the hardest time to integrate into the gameplay. Because I only plan to have 4 + 1 levels in School Rush. The game is intended to be short, focused on simple gameplay of running forward under ink raise pressure. I have been tempted to select a trigger in every level where the ink would start raising while keeping the first two screens for some gameplay sandboxes. I think this can work provided that the player may "see" that something got triggered and the ink starts raising. I even made some sketches with gargoyles-like items in the background, but I couldn't get it to fit the desired storyline of the game -- that is, pendats have decided to flood the area to punish books for not following their leader, and Bilou tries to get to the ink source to turn it off before it is too late.

En ayant pour objectif de faire uniquement 4+1 niveaux pour SchoolRush, je devais adapter le commentaire, évidemment. J'ai pensé par exemple à garder les quelques premiers écrans avec l'encre à l'arrêt avant de déclencher la montée. Pour que ça marche, il faut que le joueur puisse "voir" que l'encre se met en route ou s'arrête. J'ai fait quelques esquisses de têtes de crapauds qui laisseraient l'encre s'écouler hors de leur bouche, par exemple. Mais je n'arrive pas à relier ça avec l'histoire (les pendats cherchent à noyer le niveau)

Puis j'ai réalisé que -- dans les 2 premiers tiers du niveau "School Rush", la montée de l'entre n'est pas vraiment importante (en mode normal), parce que si elle retire certaines structures destinées à servir de filet de sécurité aux novices, en revanche elle ne monte jamais assez haut pour mettre en danger le joueur qui reste au niveau du "sol officiel". Pourtant, ça ne se voit pas parce que au niveau des pixels, l'entièreté du sol est couvert.

avant	après

Then I realised that in the first 2/3rd of the level 1 of School Rush, having the ink raising is irrelevant in "normal" mode, because it never gets its hitbox reaching Bilou as long as Bilou is on the level's main structures. The only thing that effectively becomes unusable are the safety nets meant for the "easy" difficulty level. But this is not what the player feels, because the ink effectively hides the main structures. I mean completely. I have to remember precisely the position and size of the holes to clear if I don't want to lose a life there.

So all I need to do if I want to get a newbie-friendly 'normal' mode is to let the sprites depicting the ink shifted down by a few pixels so that I can get both the initial intent (let the player know, right from the start, that she's rushing against ink) and the new objective (once it turns obvious that the rise has come to an end, be able to freely explore game controls and mechanics).

Il me 'suffit' donc de descendre un rien le niveau des images représentant l'encre animée pour rencontrer à la fois mon objectif initial (que le joueur sache dès le départ que, dans ce jeu, on court parce que l'encre monte) et le nouvel objectif (que le joueur ait un terrain d'entrainement pour se familiariser avec les contrôles et les règles du jeu).

Il me manquera une possibilité d'avoir un terrain d'entrainement pour les power-ups, qui ne sont pas évidents à obtenir dans le premier niveau. Je crois qu'en retravaillant les modalités du niveau bonus, on doit pouvoir y remédier.

I still lack a sandbox for trying the power-ups, as they aren't obvious to get in the first level. I hope to get that fixed through the bonus level you'll be able to unlock with the collectible letters.

SaturdayScreenshot

Et voilà. J'ai un petit effet sympa pour attirer l'attention sur les boules bleues redonnant de l'énergie au joueur. Ça aura été un peu de chipotage pour intégrer les nouvelles animations dans les 4 niveaux existants, par contre. Pour la suite, il va vraiment falloir que je veille à ce qu'on puisse inclure les déclarations de bloc spécial de la même façon qu'on inclut les machines d'état pour les personnages.

Demain, je pourrai mettre ça sur Twitter et participer au micro-évènement "postez un screenshot de votre jeu en cours de développement".

Don't you love that blinking effect on the healing bonus ? Not as hypnotic as bouncing on a pink eraser, but i'm quite satisfied with the result. I'll have some work to do to allow such things be used in multiple levels without having to rely on manual copy-and-pasting across multiple script files.

Quelques détails

à régler avant de refaire une release:

• récupérer le dernier .spr avec les petites étoiles en jaune pour les lettres
• ajouter un effet quand on récupère un point de vie
• corriger la fin du niveau 1 et les pilliers du niveau 4 pour qu'il n'y ait pas des bouts de gommes au lieu des graphismes.
• veiller à repasser en mode "jeu complet sans Inspector Widget"

Mais au moins l'ensemble des niveaux reste jouable avec les niveaux d'encre ajustés.

shell to cybook

I got the z-list issue fixed. The error was what I suspected, but what is more interesting is that I have been able to write a test case that reproduced the bug systematically, and thus that demonstrate that the problem is gone with the fix.

I had to change my approach for investigating that because I've been doing so much on-line activities these last days that my eyes started to "panic". So rather than staring at my laptop top understand the outcome of a test, I pushed it into a .html file that I could browse with my e-ink cybook.

python -m SimpleHTTPServer 8000 & # http.server if you're on python3

(echo "<html><body><pre>" ; 
  ./testme ; 
  echo "</pre></body></html>") > /tmp/html/out.html

(echo "<html><body><pre>" ; 
  grep -h -C14 prepare libgeds/source/* 
    | sed -e 's:&:&amp;:g;' 
    | sed -e "s:<:\&lt;:g;" 
    | sed -e 's:>:\&gt;:g;' ; 
  echo "</pre></body></html>") > /tmp/html/code.html

Bon, ça n'a pas été une semaine simple, mais j'ai réussi à pouvoir prouver que le bug d'affichage de Bilou est corrigé tout en reposant suffisamment mes yeux qui criaient "au secours" la semaine d'avant. J'ai notamment utilisé assez abondamment ma liseuse pour passer en revue les résultats des tests (puisque oui, j'ai choisi l'approche "test automatique plutôt que l'approche "debugging interactif raffiné", la faute aux yeux précédemment cités). Celà dit, je vais rester prudent et laisser les détails techniques uniquement en Anglais pour cette fois-ci. Dès que j'aurai compris pourquoi l'encre refuse de s'arrêter à la hauteur demandée, je pourrai faire une release améliorée de School Rush.

The test itself is actually fairly simple conceptually: I just drag Bilou around in the level, back and forth, emulating the camera and the game logic after each displacement. As the camera moves through the level, some game objects freeze and unfreeze, recycling the hardware sprites, and inkjets use the top-layer sprites so that ink drops look to come from within it.

On the first round, the bug did not happen, but I had programmed a "trap" to report what I thought to be the precondition to reproduce the bug (having the inkjet frozen while it had one hardware sprite at top priority). The test then showed me that this happened, but less often that I thought. Actually, it only happened with one inkjet near the end of the level.

Then, I extended the test so that I would make an increased number of scrolls through the level. There I got the bug appearing systematically on one of the levels. I had to filter out some of the events reported during the scroll (I reported every change in the zlist's size as well as any arrival/departure of hardware sprites): inkjets throwing ink corresponding for instance to 4 correlated events. Making sure that the camera coordinates are reported (instead of Bilou's coordinate) helped as well.

Another Inspector Widget ?

I have another instance of sprites disappearing and re-appearing in School Rush. It is likely something with the "pull part on top of every other sprite (aka. zlist[0]). I believe the issue happens when a modular sprite gets frozen while it had one of its component pulled to zlist[0], and then comes back to activity.

It would be great to investigate those situations to have an alternate widget for the Inspector Window Something that would show the on-screen area, the "GPU-active area" around it (where hardware sprites are are still programmed to be shown), and the area where the objects are still active although their OAMs are all disabled to avoid display glitches.

Bon, je tape un peu en vrac mes cogitations du week-end. Si je n'ai pas encore refait une release avec les améliorations de School Rush du mois dernier, c'est que je suis confronté à un retour des sprites-fantômes. Au départ, c'était juste dans la tour encrièrnale, mais ça se généralise à tout le jeu School Rush... J'ai ma petite idée sur la cause, mais j'aurais bien aimé en avoir la preuve avant de tenter une correction du code. Histoire d'être en mesure de montrer que c'est bien corrigé.

L'ennui c'est que j'estime le rapport entre corriger et démontrer que c'est corrigé de 1 à 10 au minimum. Voire de 1 à 100. L'autre ennui, c'est que ni l'amélioration d'Inspector Widget (qui aurait de la gueule) ni l'écriture de cas de tests (qui serait en aveugle) ne me paraît préférable

Ideally, it should be able to show "regular" and "pulled" sprites differently so that we can spot what state they are in and when. It should of course allow pausing and step-by-step processing to maximize our chances to reproduce the believed cause of the crash. Would that be enough ? should I rather try to have that investigated through "unit" testing ? I don't know yet.

MapAnim : done

Once again, properly mapping the codebase before starting to program got a loong-delayed-feature added to the engine within an afternoon. The code was actually written bottom up, starting with the revision of the "clearblock" function up to the script parsing code. 

I love so much the new little bounces and stars, I couldn't play the game without them anymore :P

Et donc les voilà, ces petites étoiles qui accompagnent la disparition des bonus et cette gomme rebondissante que l'on me recommandait. Je vais bien vite me refaire une version de School Rush qui intègre tout ça, parce qu'on y prend terriblement vite goût ^_^

Le nouveau système me permet aussi d'affiner un peu le comportement de la gomme rebondissante: elle ne projette plus Bilou immédiatement en l'air: au départ, elle n'est qu'un détecteur et devient un rebondisseur uniquement avec la première étape d'animation. Du coup, ça permet au joueur de mieux ajuster ses mouvement avec ce qui se passe dans le jeu (enfin, je trouve).