Thursday, September 21, 2017

NExt (last?) steps on School Rush

No real "todo item" identified from last week-end' playtesting session, except one funny idea of using a special feature of the NDS' sprite hardware so that we can see Bilou while he's swimming up the ink.

I've got a few other things to do, though. Some editing on the map, some debugging on the inkjets, but mostly, a way to animate what the pipes when Bilou disable them.


Je me suis retrouvé un peu "tout bête" à ne pas avoir de véritable chose à corriger après la petite scéance de playtesting de du week-end dernier. Qu'à celà ne tienne: il y a quelques détails qui restent encore à améliorer sur le dernier niveau, et en particulier faire en sorte de pouvoir animer l'arrêt du flux d'encre quand on rebouche un bouchon. Je pense bien utiliser les polygones: ça fait parfaitement l'affaire. tout ce qu'il me manqu(ait), c'est un bout de code qui dessine un rectangle noir entre deux objets du jeu, et un peu de script pour lier le tout.

So let's go for a new "GobController" that renders some polygons between two objects and don't do anything else. Ideally, the "circular" controller used to swing spongebops could be cleaned of OpenGL instructions and once I'll have a 3D object editor, I'd be able to name which 3D object should be used as the link between any two attached objects. But we're not there yet.

Ce n'est pas franchement le genre de programmation qui fait plaisir: assez bien de copier-coller, pas franchement le bon rôle (c'est un contrôleur, et on fait de l'affichage >_<), etc. Je reviendrai là-dessus quand j'aurai bouclé le jeu et que j'aurai un peu avancé sur mon projet d'éditeur d'objets 3D sur la DS.

Ah oui. Il y a un autre élément qui serait sympa: faire en sorte qu'on puisse voir Bilou nager hors de l'encre. Point de vue technique, j'ai ma petite idée, mais ce n'est franchement pas prioritaire.

Tuesday, September 19, 2017

Ink pit : play-tested

J'ai eu l'occasion de faire tester le niveau vertical de "school rush" à L., 11 ans maintenant et qui essaie maintenant occasionnellement les niveaux de Bilou depuis 2009 2013. La fonctionnalité-clé est validée: "j'aime bien qu'on puisse nager pour ressortir de l'encre", affirme-t'elle, alors qu'en pratique, elle n'aura réussi que quelques fois à se tirer du mauvais pas, et généralement si affaiblie (enfin, Bilou, hein. Pas ma testeuse) qu'elle n'ira guère qu'un ou deux écrans plus loin.

Mais l'effet psychologique prend. Elle s'accroche et s'améliore peu à peu, jusqu'à atteindre régulièrement 1/4 du niveau et occasionnellement 1/3. Au-delà, les choses se corsent et il faut régulièrement courir pour franchir les sauts, ce que L. ne maîtrise pas encore véritablement.

Celà dit, comparé au jeune premier, L. a immédiatement senti l'urgence de l'encre qui monte, remarqué qu'il fallait se méfier des encriers endormis et qu'en sautant un petit coup supplémentaire une fois arrivé dedans on les réveillait (oui, c'est un vrai bug que je dois corriger, pas un choix de gameplay douteux), repéré les horizontales dans les les livres et les utiliser comme plate-formes, etc.

Friday, September 15, 2017

Come back from the ink ?

Bon, entre les programmes d'activité des loupiots qui grandissent, les centrales vapeur qui tombent en panne et les interventions de réparation dans la maison, je me prends une petite paire d'heure pour essayer de corriger un couac avec le passage à un niveau vertical dans "School Rush": s'assurer que le jeu relance bien le niveau si l'encre nous rattrape.

Je dois  notamment éviter que Bilou ne puisse rester indéfiniment dans un encrier sous l'encre. Etre invulnérable dans l'encrier, ok, mais pas retomber immédiatement dedans quand il nous projette jusqu'à la fin de la batterie.

It is time to check what the vertical level looks like when we add rising ink in the mix. And the first tests show that there's quite some tuning required. The first mis-steps that my last playtester did led Bilou to be stuck in the ink, invulnerable, but also unable to keep on playing. One of them involved cycling between in-inkjet and hit.

I'm trying to make the state machine detect that we're in the ink and switch to a "swim up" state that would give the player a chance to get out. This is possible because ink has an additional flag that makes it possibly different from a regular hazard. All the engine requires is that the test on "hurts and is ink" precedes the test on just "hurts".


Se faire projeter par l'encrier, c'est "$HJUMP". L'encre, c'est à la fois F_HIT (blesse Bilou) et F_ISINK (fait flotter les éponges). Une réaction "normale" pour le personnage qui tombe dans l'encre serait d'essayer de nager pour en sortir. En particulier s'il atteint quelque-chose qui peut le propulser hors de l'encre. Ce sera "$SWIM", dans lequel on est insensible à l'encre mais qui repasse faire un test périodiquement et continue donc à consommer des points de vie tant qu'on est dans l'encre.

Il faudra aussi que je complète ce "swim" lorsque Bilou arrive hors de l'encre.

Thursday, September 07, 2017

Doxygen on Onyx

I don't exactly know what I have changed, but using the "Neo Reader" application on the Boox today, my doxygen-to-epub-through-calibre file now renders as expected. I thought that could be linked to the disabling of "cache reflow bitmap" cryptic option in the advanced settings (see the small icon pointed by the stylus on the picture), but re-enabling it doesn't change anything (or it only has an effect when restarting the application ?)

Qu'est-ce que j'ai changé ? Je n'en sais plus trop rien. J'ai "torturé" le morceau de code qui apparaissait dans la version e-pub de mon blog pour essayer de trouver ce qui faisait la différence entre un rendu correct (white-space: pre-wrap ? utilisation de
<pre>plutôt que <div>? de <tt> plutôt que <span>?


Rien n'a semblé avoir d'effet. Puis ce midi, en jetant un coup d'oeil à mon code converti par doxygen et calibre, surprise! tout est impecablement rendu.

Plus de numéro de lignes indésirables, changements de polices, traitement correct des espaces ... tout y est.

Est-ce que ça vient du réglage "cache reflow bitmap" que j'avais changé ? difficile à dire. Le désactiver ne semble pas avoir d'effet immédiat, mais ils auraient pu omettre de dire qu'il fallait redémarrer l'application ...

One major drawback, though: Neo Reader application is the only one for which I find no way to hop back to the place I was before following a link in the epub document. And that will make navigation extremely annoying, I'm afraid.
Neo Reader v2.0 had nice backtracking feature, and that one gets interesting behaviour on my test epub document.
  • When using <span> or <div> with the CSS classes associated with working 'code-style' elements, nothing happens
  • When using <pre> or <tt> with the same elements, code is rendered as it should (as printed on dot-matrix ;-)
  • The style applied to "English section" (using <en>) doesn't go italic, while emphasis directly using <i> in the French part goes italic.
  • skipping CSS classes altogether has no impact (given that you're using
    pre/tt tags)
  • embedding the whole stuff in "blockquote" doesn't seem to have much effect
  • trying to use tables with colspan and some cells containing only a few whitespaces failed miserably. I think all cells are just sitting in a vertical list, not laid out on a table at all. 

Wednesday, September 06, 2017

Sketching on Boox

La première prise en main de l'application "prise de notes" de mon nouvel Onyx Boox n'avait pas franchement été convainquante... arrêter son traît au bon endroit, viser un emplacement avec le stylet ... tout ça est plus complexe que ça ne le devrait. La faute à mon avis à l'absence de compensation de l'inclinaison du stylet.

Starting to draw with my "Boox" was a bit disappointing. Whatever I could try with stylus calibration, there was still a significant offset between the contact point of the stylus tip and the actual drawing point. I bet better tilting support in the software (or hardware?) would have avoided that, but that's not something I can improve. Hard to stop at the right place on a rectangle's corner. Harder to make a circle (or whatever else) at a precise spot ... and almost impossible to make an arrow >_<

Du coup, quoi qu'on fasse avec la fonction "calibrage", le point de contact du stylet avec la surface et le point où l'encre change de couleur ne coïncide pas.

Difficile du coup de faire de beaux rectangles ou  (encore plus ennuyeux) des flèches. Difficile aussi de dessiner des p'tits Bilous dans le coin d'une explication. Ou de faire du dessin type "ligne claire".

I usually love to have small Bilou / Bouli talking and illustrating a technical chat... That will be difficult to do here. It usually requires to draw at small scale, a single line, Tintin-style. And that works terribly bad with the imprecisions of the Boox "Notes" application. 
 
But hopefully, lining up multiple lines and writing works naturally well. 

The good news, however, is that if I'm just sketching at a scale of 5-7 cm, striking over again and again to make the lines more defined gives some quite interesting results. Not really suitable for artwork either, but creating quite acceptable sketches.

Par contre, le style "repasser sur les lignes, plus nerveux, plus "esquisse" ne donne pas trop mal.

Friday, September 01, 2017

I got a Boox

J'ai reçu mon nouveau gadget à base d'encre électronique, donc. Même si au prix où il était, j'espère qu'il sera plus proche d'un ordi que d'un gadget, évidemment. Il s'agit d'un Onyx Boox 9.6" combinant un stylet magnétique et un écran capacitif.

I jumped completely out of my comfort zone and ordered online a device I never had in hands before at a price well over that of a Nintendo DS: the Onyx Boox N96, combining magnetic stylus (afaik), capacitive screen and e-ink display for roughly the size of a A5 sketchpad.

Malgré une boîte tout-en-chinois un peu intimidante, l'appareil a des menus en bon Anglais et la prise en main s'est faite assez facilement. Ma grande inquiétude, évidemment, c'était de savoir si je pourrai m'en servir pour mes documents "doxygen" si utile pour faire du développement intermittent.

The device feels right in hand, is quite a hybrid between an androïd tablet (unfortunately only 4.0, making applications for twitter, picasa and blogger unusable >_<), but what was really stressing me was to know whether I could use it for epub+doxygen code browsing I've been usiing sooo much for the last years to progress on my pet projects. And unfortunately, out of the 4 embedded readers, none of them got the layout right. No indentation, useless line numbers, incoherent spacing ... all of the issues I had fixed earlier this summer -- and some I never heard of before -- were back to haunt me.

Ce n'est pas gagné: sur les quatre lecteurs e-pubs embarqué, aucun n'a un système "styles de l'éditeur" comme mon regretté Cybook. Et sur chacun d'eux, le code produit a tous les défauts d'une mauvaise conversion: pas d'indentation, numéro de ligne inutiles, tailles incohérentes, etc.

J'avais compté sur l'installation de FBReader, testé avec succès sur la tablette de ma fée, mais c'était compter sans une dernière roublardise d'androïd: Il y a en réalité une version plus ancienne de FBReader dans le pack d'applications préinstallées, ce qui m'empèche d'installer une version plus récente pour cause d'erreur -104. (j'aurai peut-être plus de chances après une recompilation ?)

My plan was to use the open-source FBReader if such thing occured, but unfortunately, I couldn't install it from Google Play: interference between the pre-installed FBReader (older version) in the firmware makes it fail with error -104.

I was hesitating between sending it back and switching to some pure html-based doxygen crawling when a post in one of my blog-on-epub conversion caught my attention.

Bref, je m'apprétais à devoir me rabattre sur une utilisation de pages webs moins pratiques (pas d'annotations, pas de marqueur 'vous êtes ici' d'une lecture à l'autre, etc.) lorsqu'au détour d'un post de ce blog converti en fichier e-pub, je constate que l'un des lecteurs par défaut (je ne me souviens pas duquel il s'agit :P) que les styles sont tout à fais satisfaisants pour mes besoins:
  • le bloc de code est en police monospace alors que le texte du post est en police classique,
  • les indentations ont fonctionné correctement,
  • (bin y'a pas denuméro de ligne, forcément, vu que je n'en ai pas mis. Haha.)
Le jeu, ça va être maintenant de comprendre la différence entre ce bloc-là et ce que j'avais dans mon document doxygen pour faire des doxygens qui marchent mieux.

See ? It's all there. Indentation, font switching... The CSS reading is there. The rendering works. It's all a matter of making the doxygen stuff damn simple enough so that it couldn't possibly fail. That's something I can handle. The boox may stay here.

Wednesday, August 30, 2017

mayfreeze = false

Voilà: le niveau vertical est pour ainsi dire fini. Du moins pour ce qui est des décors. Maintenant, je vais devoir passer un peu de temps à faire les réglages pour l'encre-qui-monte. La bonne nouvelle, c'est que la technique qui évite que l'encre s'arrête de monter quand elle sort de l'écran est déjà opérationnelle depuis Juillet.

It's now time to make sure the vertical level get rising ink, too. And this time, I need to take extra care that the objects that control the ink level will never got "frozen" when going too far away from the camera. That was hopefully available since early July.

Un peu plus délicat: s'assurer que Bilou se "noie" toujours dans l'encre malgré le fait qu'il puisse parfois tomber de plusieurs écrans avant d'être arrêté (et la zone de collision de l'encre ne va pas jusque là).

Another thing that I'll have to take care of, is that Bilou don't go too deep into the ink. Without it, we can quite easily have Bilou fall down so low that he'll go out of the "hit player" box ... and player will have to find some other way to hurt himself (while seeing nothing but a black screen) to be granted another attempt.

Je vais devoir ajuster un peu les encriers -- et en particulier éviter que Bilou ne soit totalement à l'abri à l'intérieur d'un encrier -- faute de quoi il pourrait très bien y rester bloqué indéfiniment. Et enfin, il faudra trouver la bonne vitesse pour la montée de l'encre, parce que là, j'arrive en haut du niveau avec 6 bonnes minutes d'avance. De préférence sans trop "tricher".

One last thing: I cannot keep the rule that "being within an inkjet = being immune to ink" as with the 4 previous levels, because then you'll be stuck in your inkjet forever.

And then, I'll need some tuning on the ink speed itself. Right now (60*32/256px/sec), I can climb up the level and I'd have to wait for over 6 minutes before the ink can catch me back.

If I let the ink almost reach me when I'm about to go through the last "room", though, I'm only some 40 seconds ahead at the top -- which is still quite a lot.

Saturday, August 26, 2017

School Rush sur Press Start

Difficulté très bien rodée, dit Space-Cowboy de Press-start. La présentation est un peu plus formelle que celle de Pirez, mais tout à fait sympathique.On va un petit peu plus loin dans le jeu, aussi. Mon regret sera que notre cow-boy a fait sa vidéo sur la version de l'an dernier et ne nous montre donc pas les nouvelles animations sur lesquelles j'ai travaillé l'an dernier.

School Rush continue lentement sa progression parmi les internautes. J'espère un jour pouvoir atteindre la rédaction de Pix'n'Love, mais leur forum reste curieusement verouillé...

I'm still hoping to get in touch with some English-speaking youtuber who would love to play-test School Rush. I'll definitely have to try a bit harder with the next release

Monday, August 21, 2017

End of Cybook ?

After about 5 years of helpful operation, my e-ink device "cybook odyssey" seems to be definitely damaged. I cannot do more than a few minutes of reading before getting the system to reset. Sometimes even just clicking a link or trying to change the font size will jam the device. I tried a factory settings restore, but that only help for a few minutes.

And now the "gadget" class of the device really shows up. I have no logs that could point out the flaw, no way to access the critical components (namely the internal flash). The device as a whole will have to be recycled just because one component is weared out.


Mon Cybook me lache à nouveau. Trois ans après son passage en service-après-vente, mais sans espoir d'intervention de garantie, cette fois-ci. Me le réparerait-on de nouveau ? Peut-être. Est-ce que j'ai envie d'injecter encore de l'énergie dans un appareil que je ne peux empêcher de vieillir ? Pas franchement. Est-ce qu'il y a mieux à acheter ? Peut-être si je suis prêt à lâcher 300€ pour un modèle Androïd-à-encre-électronique.

So what ? Shall I replace it with another one, with slightly increased screen resolution, take advantage that I know the beast, including the annoying amount of time it takes to accurately select a phrase to highlight it (and risk having issues with memory again within a few years) ? Shall I pay up to 3 times the price for a device with stylus, android (including the ability to program my own tools on it), bluetooth, but unfortunately not the version of Android required to run the infamous "inkspace" application required for my bamboo spark ?

There is even 13" models, but they seem to be sold near 700$, not the 400$ I spot on alibaba. The same company makes 9" devices too, claimed to be half the price (which gets into the "expensive but affordable" category). Maybe I should wait for a few weeks and see whether that "ReMarkable" thing actually ships this august and at what price ?

None of these could be found in stores so far, but I had a look at a Kobo Aura One this afternoon, and it was quite sexy, with its all-flat front side. No stylus and no android (afaik), though.

Saturday, August 19, 2017

Les autres pentes

Du point de vue du moteur de jeu, un niveau est avant tout une grille dont chaque case reçoit des propriétés: solide, solide uniquement quand on tombe, pente, spécial, etc.

(note to English reader: the handwritten text on the pictures is part of the post's text this time).

... A grid, with tiles telling "solid" or "sloped", or "jump through, but don't fall". And sometimes just "special block".


Les "blocs spéciaux" ne sont pas compris par le moteur de jeu lui-même (d'où leur caractère "spécial") mais décrits dans les scripts qui définissent les règles du jeu.

Ainsi, quand Bilou touche par exemple un Bonus, le moteur de jeu récupère quelques bits d'information pour chaque pavé (8x8) de la grille constituant le bloc (16x16) et reconstruit un numéro de bloc spécial (de 0 à 255) qui permettra de retrouver les instructions à exécuter (faire un son, déclencher une animation, donner des points, etc.)

... each "special block" tile provide two bits that are combined to define the "block number" used to retrieve collision properties, hit box and script expression that makes a bonus play a sound and spikes hurt Bilou. The game engine itself, to some extent, doesn't know anything about the special blocks except how to delegate block/object collisions to the appropriate script sections.

Quand Bilou touche une pente, en revanche, le moteur de jeu sait qu'il doit aller regarder une petite table indiquant la hauteur de chaque pixel de la pente. A priori, la forme de cette pente pourrait être n'importe quoi. Mon éditeur de niveau connaît les pentes à 45° et à 22.5°

The height array tells how high is each pixel in the tile. The game engine knows very well what to do, this time. Some tuning could provide an alternate height array to support a different kind of slope, but I haven't used that so far in the game.


Mais voilà: j'aimerais pouvoir avoir plus de souplesse: des escaliers, des coudes, par exemple. Un petit schéma de rien du tout qui traîne depuis des années (2010?) sur un bloc de brouillon en atteste.
"Le mieux serait d'avoir deux boutons 'pente' [dans l'éditeur de sprites] qui forcent le remplissage d'une ligne de 64x16 pixels avec des pentes suivies (les modèles)"
 ajoute encore le calepin.

That "sprite editor / stripe of sloped tiles" approach hangs around in draft mode for years. Because each tile has a unique address in video memory, I had plan to use that address to extend "advanced slope-to-the-right" into "start-of-slope, 0° to 22°". The issue is that the Sprite Editor has no real control of which blocks goes where in memory. Just filling a row of the tile sheet with slope patterns doesn't guarantee that the corresponding tiles will all receive consecutive (and not even aligned either) numbers in the tile set. The solution was in realising that the Level Editor is the component that should solve the more-slope-types problem.

En effet, la technique que j'envisageais alors consistait à utiliser comme information supplémentaire la position du graphisme au sein d'une ligne de blocs dans l'éditeur de niveau (une "tranche" de 16 pavés de 8x8 successifs). On pourra alors convertir l'information de la grille "pente compliquée vers la droite" en "transition douce de 0° à 22°" parce qu'on est dans le 6eme pavé sur une tranche de 16.

Sur les dernières années, ça n'a jamais été mis en service et mes derniers tours d'horizon dans le code de l'éditeur de Sprites me confirme que travailler "par tranche de 16 pavés" serait un vrai casse-tête (le mode et le moment de l'allocation des pavés dans la mémoire vidéo n'étant absolument pas prévu pour ça).

Et cet été vient une idée qui jette un autre éclairage sur ce problème: "Les pentes douces, c'est un problème pour l'éditeur de niveaux. Ce n'est pas quelque-chose à régler dans l'éditeur graphique.

Et l'éditeur de niveau sait par contre traiter des groupes de chiffres pour montrer qu'un bloc spécial est soit un bonus, soit des pics, etc. En prenant donc un type de pavé qui dit "pente compliquée, regardez les chiffres en-dessous pour en savoir plus", je peux diriger le moteur de jeu vers une autre table de hauteurs qui définit la pente (parmi 16 pentes possibles), mais aussi éventuellement fixer le coefficient de friction (sol dur, glissant, boue-qui-ralentit, etc.)

"Special Slope" type merges the behaviour of "sloped tile" and "special block": it will have less bits available to encode the type of slope (e.g. "only" 16 possible slopes), it will require collaboration of multiple tiles, but instead of creating a BlockArea and trying to match collisions, it will just provide an alternate height arrays.

Il me tarde d'essayer ça ^_^




Friday, August 18, 2017

Habillage ...

Il est temps de passer du 'test fonctionnel' à quelque chose de plus "habillé" pour le dernier niveau vertical. Jusqu'ici, je m'étais contenté d'un minimum de graphisme (les blocs-sol) pour vérifier si les sauts étaient possibles. Il est temps de dessiner le reste des objets.

Ouais, sauf que pour avoir des dessus-de-fardes-sur-lesquels-on-marche un peu partout dans le niveau, c'est pas forcément simple. J'avais pensé à des "couches" suggérées par différentes couleurs (il y a déjà une convention dans l'ensemble du jeu du genre farde verte = mur, farde brune/mauve/vert-foncée = plate-forme semi-solide), et faire des structures un peu imbriquées comme avec mes bons-vieux-buissons.

Since April, I've been extending the "vertical, last level" of School Rush with some more platforming challenges. I intentionally kept the look of the level ultra-minimalist for monthes, as it is much easier to tweak the location of the platforms and adjust difficulty that way. I haven't touched the layout of the level in weeks, so I guess it is ready to receive more complete look.

I had plans to fake depth between level elements such as books or binders to justify the presence of so many platforms without having significantly more "ground", although there is some from time to time. And I was also planning to reuse the color conventions present in earlier levels of School Rush, such as "green book = wall, purple book = jump-through platform".

But that was missing the annoying fact that I can change the colors only on the background layer of tiles, while I typically need both background and foreground together to combine small objects into larger structures as I did with the green zone's bushes.


Sauf que pour faire facilement ce genre de choses avec un tileset réduit, je jouais sur les deux plans de tiles, toujours le même pour ce qui est par-devant, l'autre pour tout le reste. Mais mon moteur de jeu ne permet pour l'instant de changer la palette de couleurs que pour les tiles d'arrière plan: les tiles d'avant-plan sont systématiquement "verouillés" sur la palette #0 et les bits correspondants sont utilisés pour encoder le type de bloc.

This is thus one more motivation to change things in the game engine and take the "tiles properties" array out of foreground palette information, but hopefully, I have enough room (~20% left) in my blocks tileset to accommodate for some "combined" tiles, be it at the cost of manual palette retro-fitting.

But I know this cannot be labeled as "the solution" for this problem: It killed the Badman III effort by making the art impossible to manage. Later on, I'll have to address the issue for real.

Bref, pour cette fois-ci, je vais me débrouiller en créant "à la main" des tiles supplémentaires qui "combinent" les deux couches, avec des imports de palette, mais ce ne sera pas beau à regarder dans l'éditeur (parce que le joueur ne devrait pas voir la différence, lui). Décidément, tout cet été pousse vers un déplacement des propriétés du niveau hors des couches de "rendu".

Wednesday, August 02, 2017

On reprend les crayons

(enfin, le porte-mine, plutôt). Les aspects techniques pour avoir une petite image originale au chargement de chaque niveau sont réglés. Je gribouille un peu pour avoir les 4 images qui me plaisent pour raconter l'histoire de School Rush (invasion des crayons-soldats, résistance, déroute et vengeance des soldats en question).

Let's pick up pencils again and draw some 'cutscenes' for SchoolRush to be shown while the level loader is parsing the characters behaviour descriptions again. I had initially planned to recycle those choose-your-difficulty pictures, but the story they're telling shows the pendats defeating the inkjets (comic book's scenario) while I actually need the opposite...

Ce qui s'avère être plus ou moins l'opposé de ce que j'avais prévu de faire raconter au cancrier dans la BD, en fait ... donc il va me falloir encore au moins une dernière image.

Tuesday, July 25, 2017

simplifions le HUD

J'ai attaqué une révision du code de contrôle entre le moteur de jeu et l'affichage de l'écran du livre-magique. J'ai déjà remplacé les tests douteux sur des variables obscures supposés indiquer si on est sur le menu ou dans le jeu par une commande explicite "hud.mode=%c"

The code controlling the HUD logic deseperately needed some refactoring. It smells it has been written with a "oh, come on: this is just testing X and doing Y". As the rules for the game status display became more complex (different pictures for the menu, then custom behaviour for power-ups, then a complete different behaviour for the credits level ...

Je continue avec une simplification des relations entre "GameScript", "GameWindow" (qui s'appelle toujours CmdWindow parce qu'elle s'occupe des fichiers .cmd) et "Hud". Le Script et le HUD sont maintenant créés avant le chargement du niveau, le "setup" qui permet au HUD de savoir quel objet est le héro, où sont les compteurs, le score, etc. se produit explicitement lors du dernier "end"

So I started with making the behaviour of the HUD explicit through hud.mode=xxx in the scripts -- since both menu, credits and game levels are separate scripts. Then I refactored the way the HUD is constructed and linked to the GameScript so that parsing hud.show "xxx.spr" can lead to some Hud::showScreen() although the HUD isn't ready to run its play() function yet (i.e. because it doesn't know the pointer to Bilou's state and to game stats, which will be taught by the GameScript through the Hud::setup() call).

Once again, all this was made possible thanks to doxygen-on-cybook where I could annotate code with refactoring thoughts until I was ready to sketch the desired behaviour as UML. Once this is done, I'm ready to code it in small chunks, one evening at a time.


Enfin, je suis prêt pour un 'hud.show "somefile.spr"' qui me permettra de raconter une petite histoire sur l'écran du bas avec une image différente pour chaque niveau.

Thursday, July 13, 2017

cyblog de retour.

Voilà ... quelques retouches à mon projet "blogpress" puisque je m'étais fait exiler sur le vieux PC bruyant où je l'avais développé. Et j'en extrait un livre de 600 mini-pages avec les posts sur le thème "quel jeu ?"

Bien sympa. En Français exclusivement (puisque je filtre le contenu des balises "<en>" au moment de l'export pour le format .epub), et perfectible:
  • j'approche les 50Mo pour un thème (une dizaine de tags sur le blog)
  • trop d'images dupliquées. Il faudra les identifier (fdupes) et n'en garder qu'une de chaque
  • la construction d'un chapitre par tag est plus intéressante parce qu'elle permet de cibler la lecture (en tout cas pour moi)
  • Tous les liens page-à-page sont pour l'instant perdus (si on clique dessus, la liseuse essaiera d'aller se connecter sur le blog)
Enfin, je serai prêt à affronter les plages et les plaines de jeu ^_^

Saturday, July 08, 2017

Loading Chaos

Il y a environ 2 ans, quand j'ai reçu le commentaire d'Eric sur School Rush, j'étais en pleine tentative de changer radicalement la manière dont fonctionne le chargement des niveaux dans GEDS. Malheureusement, rien ne se déroulait comme je voulais. Du coup, sa remarque

Pourquoi le chargement des niveaux est aussi chaotique ??
est un peu restée en suspens. Je ne savais pas vraiment en faire grand-chose.

Remember Eric's comment that level loading felt like chaos? I haven't addressed it so far, partly because when he mentioned it, I was struggling to improve the way levels are loaded with libgeds. Meanwhile, the reason for which I wanted improved levels loading (a power-up shop) vanished and the chaos got hidden by "black curtains" (actually, the "window" feature of the NDS hardware). But loading time was still excessive and nothing happens while loading.

Entre-temps, le projet de "marché au bonus pendant les temps de chargement" est passé à la trappe en faveur d'un niveau-à-vies/power-ups. Le chaos du changement de niveau (en partie dû au fait que j'aime bien savoir si les étapes se passent correctement en phase de développement, j'avoue) est masqué par un "rideau noir", mais le temps de chargement, lui, est toujours aussi long.

En relisant son commentaire cette semaine, juste après avoir ajouté une "page-de-livre magique" supplémentaire, je me rends compte que l'écran du bas (le livre, donc) ne subit presque aucun changement pendant tout le chargement.

I reached that comment again this week, right after I took some time to have a custom "bottom screen picture" for the "credits level" and then realised that the bottom screen remains mostly unchanged (although completely hidden) while we're doing a lot of chaotic stuff on the top screen as result of the level loading. So If I want the player to get some info about the story, or tease/teach him, the bottom screen could do the job.

En haut, tous les graphismes sont re-chargés, puis la nouvelle map est mise à l'écran, puis -- seulement quand tous les scripts ont étés traduits en machines d'états et tous les personnages positionnés -- on peut positionner la caméra dans le niveau à l'endroit où doit commencer l'action.

Mais en bas, rien ne se produit jusqu'à ce que le niveau soit déclaré "prêt". Je peux donc repêcher une des illustrations qui servaient à présenter les niveau de difficulté et les donner en pâture au joueur -- peut-être avec un message adapté à sa performance (première arrivée dans le niveau, première raté dans le niveau, dernière chance). 

So I crafted a small prototype, that shows one of the 'difficulty selection' pictures and hides it just before we're about to show the "let's play" pages of the HUD book again to resume playing. Now that this is satisfying, I'll have to think about a few more pictures (one per level) and some messages.

J'ai un premier prototype pour ce genre de chose. Afficher l'image au moment où on commence le chargement, c'est facile. Je dois maintenant retrouver dans la séquence "démarrage du niveau" le moment où le niveau va démarrer de sorte qu'on puisse éviter un "glitch" du genre "la page de chargement était affichée, la page de jeu s'affiche un instant, puis l'écran devient brusquement noir avant de se rouvrir sue la page de jeu". N'est-ce pas, Eric ?
  • [done] glitchless showScreen() while loading.
  • [unplanned but done] refactor so that "hud.mode" is defined through script
  • [unplanned todo] refactor so that showScreen is called from "hud.load/show"
  • [todo] adapt the picture to show to the level we're in
  • [todo] adapt the position to show to the lives we have (for specific messages)
  • [todo] make it tell the story of the game

Thursday, July 06, 2017

Nieborg's Colors

Henk Nieborg, maître incontesté du Pixel art qui s'inscrit sur Patreon, c'était plutôt inattendu. Mais un artiste d'un niveau pareil qui propose des tutoriels, c'est le bienvenu.

Unexpected, but very welcome. Henk Nieborg, the Pixel Art Guru, is looking for Patreons! And to get some more, he's releasing a few very interesting tutorials. A good occasion for me to try to figure out how he picks his colors for a "green zone" setting. (So as you have guessed, the picture here is not exactly Henk's tutorial, but my #pixelstudy of it ;)

L'image ci-contre n'est pas directement un des tutoriels du maître, mais le résultat de ma session de "pixel study" pour voir un peu comment il choisit ses couleurs. Résultat ? Eh bien, si le buisson d'arrière plan correspond assez bien à ce qui est recommandé d'ordinaire (décalage chromatique entre les ton obscurs et les tons clairs), j'ai été assez surpris de voir la palette pour la terre rester pratiquement sur la même tonalité (avec uniquement un changement de luminosité) et de voir que toutes les couleurs utilisées pour les "herbes" sont complètement saturées...

PS: c'est moi ou les herbes font penser à des cheveux en bataille ? Y'a quelque-chose à creuser pour Bilou, là ^_^


Wednesday, July 05, 2017

Bonus tuto

Un stage bonus pour refaire le plein de power-up quand on est malencontreusement tombé dans l'encre, je trouve ça une bonne idée. Recycler pour ce faire le tout premier niveau de mon frangin (Calimero) ? J'aime beaucoup (et lui aussi ^_^).

Par contre, démarrer du début "historique" de ce niveau-là et laisser le joueur galérer pour trouver les power-up et rester en vie jusqu'à la sortie ... peut faire mieux. Et ce serait d'autant plus intéressant de faire mieux que ce niveau bonus pourrait aussi être l'endroit idéal pour se familiariser avec les power-ups en question, sans subir le stress de l'encre qui monte.

I acknowledge Romain's advice that the game should give the player some room to try mechanics even when not entering in 'easy' mode. That's now done for all the basic mechanics, but we still lack a sandbox to try the power-ups. At first, I had hopes that the 'bonus-level-where-you-can-get-some-power-ups-back' could fulfill this need, but it won't. Not in its "historical" shape where you need to collect the 'break-things' power-up, then you can get the 'fly/float' power-up, and eventually you can get out.

But I could get something better if the starting point of Bilou in that level is picked based on how much we've visited it in the past. First, you'd be dropped next to the 'float' power up. Then you'll be dropped next to the 'punch' power-up and finally next to the 'historical starting point'.


D'où l'idée de faire débarquer le joueur à des points différents du niveau, selon le nombre de fois où il y retourne. Devant un des power-ups d'abord, puis devant celui qui permet de débloquer l'autre, puis enfin au "début historique".

Du coup, ça demandera d'avoir des portions de script qui sont lue ou non selon un des compteur du jeu. (qui est aussi un préambule aux check-points).

Sunday, July 02, 2017

The secret exit

Le niveau-tour ? je n'y ai pas vraiment touché ces derniers jours. Par contre, j'ai enfin "débloqué" la manière d'y accéder. Ou mettre les indices pour l'énigme, quelle sera cette énigme, et aussi mettre ça en place.

I think I found the way to do it now. I have an enigma on the last level, a clue on the credits if you take the "easy" exit about what you could do to break that "reincarnations circle", and the code to make it work. It could be better, especially in that it is not because we manage to be fast that we unlock the final level in a name dubbed "School Rush". There is a tussle in my mind on whether I should post a few pixels about it or to keep it truly secret as a rewards for those who will finish the game. So far the "keep it secret" side is winning.

Wednesday, June 28, 2017

UML_LOOK = YES ?

Voilà un des schémas que Doxygen peut produire si je le mets en mode UML (ce qui est sympa, parce que du coup, je peux comprendre les flèches) pour une des classes de mon éditeur de niveaux. Je peux limiter le nombre de "champs" pour chaque catégorie (histoire de garder la taille des boîtes sous contrôle), mais malheureusement pas la profondeur d'exploration. Résultat, le graphe devient vite immense, inutilisable.

When I come back to some code I've been writing long time ago (hey, the project is 10+ years old, now, remember?), I usually take some time with my cybook to study the code through doxyge-rendered documents and sketch in UML what is meaningful for the feature I want to add/change. So it would make sense to have doxygen do some UML for me, wouldn't it ?

Well, doxygen indeed has an UML_LOOK setting that turns available as soon as you declare to have the "dot" graph tool from graphviz package on your (linux) system. Neat. It also has -- took me some time to find them -- settings to reduce the amount of classes that are explored, and the amount of items that are reported for each class.

This is all quite nice, but I'm afraid it will not work nicely with cybook viewing. Whatever I do, the collaboration graph remains very large, both in pixels (and I'm unsure the cybook could pan in a bigger image) and in bytes (10x bigger than doxygen's defaults -- which had only inheritance graph, I admit).


Non configurable ? vraiment ? Voyons, et DOT_GRAPH_MAX_NODES, alors ? et DOT_GRAPH_MAX_DEPTH ?

Eh bien ils font plutôt du bon travail, mais je reste avec près de 3Mo de fichiers .svg pour LEDS, contre 500Ko de .png quand je reste aux graphes de base. Pour la lecture sur tablette, je crois que je préfère ne pas prendre le risque.

What would the perfect feature set be ?
- having the inspected class at the center of the diagram
- be able to specify a canvas size, instead of a maximum amount of nodes
- don't say "and ## more items" when you drop some items
- have a separate "depth" setting for inheritance and for structure/composition
- only show "meaningful" methods/fields of surrounding classes
- still show when a class has relationships with multiple classes of the graph
- don't show "obvious" common ancestors (e.g. the Widget class for all the widgets)
- don't show "obvious" type of data that everyone uses (e.g. std::vector) as a compound.

But let's be pragmatic: this is not the job of a heuristic filter: this is the job of an interactive exploring program. Sure I wish such an interactive tool could be running on my e-ink device, but this is not part of Cybook's business plans, unfortunately. And it is unclear that this could be achieved solely through e-pub documents structure. (would more require an HTML5 canvas or dynamic SVG + JavaScript)

Sunday, June 25, 2017

rules.gam

Plus proche de nous, mais en partie lié avec ce nouveau projet "behaviour editor",il y a le besoin de pouvoir utiliser un seul même fichier pour définir certains morceaux des scripts qui décrivent les niveaux. Ce n'était pas trop un soucis avec Apple Assault, un jeu dont les "règles" était assez simples, mais qui devient plus pénible à gérer avec School Rush.

Un niveau de School Rush décrit plusieurs types de choses: des resources (map, planches de sprites), des personnages (à travers les fichiers .cmd de comportement à charger), les positions et paramètres des personnages (définis par l'éditeur de niveau) et ce que j'appelle "les règles du jeu": réactions quand un compteur arrive à zéro, valeur initiale des compteurs (p.ex. le nombre de point de vie restant pour le joueur) et les propriétés des blocs spéciaux.

Pour l'instant, ces règles sont répétées à chaque niveau, et plus le projet avance, plus le risque augmente d'avoir un niveau ou p.ex. il est impossible de reprendre de la vie parce qu'il y a un bug dans les règles dans ce niveau-là.

Et le nombre d'animations pour les bonus augmente encore la pression sur ce point chatouilleux.

Extraire tout ça en un fichier qui serait "importé" par chaque niveau devrait être possible sans trop de difficultés, de la même façon que les machines d'états ne sont décrites qu'une seule fois et importées dans les niveaux où on a besoin d'elles. Par contre, pour pouvoir continuer à utiliser les indices graphiques dans l'éditeur de fichier, il faut qu'il sache qu'il doit y chercher les descriptions des blocs spéciaux.

Cela dit, en refaisant un peu d'exploration dans les sources de LEDS, j'ai noté que c'est simplement sur base de l'extension de fichier (.spr, .map, .cmd) que le code destiné à charger le niveau décide de ce qu'il va faire de chaque "fichier supplémentaire renseigné par le script du niveau). On devrait donc pouvoir utiliser un autre type d'extension (.gam ?) pour que l'éditeur de niveau s'y retrouve. Tout simplement.



Behaviour Edition ... brainstorm

Prochain outil pour le projet "dsgametoosl" ? Je ne sais pas encore. Mais j'aimerais beaucoup construire quelque-chose qui permette de manipuler les machine d'état définissant le comportement des personnages dans les jeux qui tournent sur mon moteur "geds".

Quelque-chose à moitié graphique (je clique sur un bilou en train de sauter, on me montre tous les états qui sont accessibles depuis celui-là. J'en choisis un, je vois les conditions et les actions annexes pour la transition correspondante si elle existe), et à moitié texte (je peux en éditer une ou en créer une nouvelle, sans s'embêter, rien qu'en écrivant les expressions que je veux).

Quelque-chose de pratique (je clique sur une variable, je vois tous les états où elle est manipulée).

Pour permettre la réalisation de "School Rush", j'ai introduit pas mal de fonctions à coup de macros qui permettaient de "nommer" des tests du genre "est-ce que la direction choisie sur le DPAD va vers la droite ?" Pour que l'éditeur soit pratique, il faudrait qu'il permette de conserver ce genre de simplifications, et ne pas imposer à l'utilisateur de mettre dans chaque test "est-ce que le bit 5 de la variable numéro 3 est à 1?"

Du coup, l'éditeur doit à la fois savoir que l'expression utilise la variable 3 (l'état du dpad) pour qu'elle soit listée dans "toutes les expressions qui dépendent du DPAD), mais aussi qu'elle s'affiche avec un "DRIGHT". et pouvoir indiquer à l'utilisateur ce que fait DRIGHT au cas où ce ne serait pas suffisamment explicite.

ça demande d'une part de faire avec assez de précision le tour de tous les éléments de scripting qui ont besoin de pouvoir servir de "critère de tri", mais aussi de faire en sorte que le logiciel tournant sur DS puisse comprendre la version "évoluée" du script et puisse en tirer la version "interprétable par le moteur de jeu" pour essayer les modifications dans runME.

Un défi qui n'est pas à prendre à la légère, en fait. J'avais envisagé pendant mes congés de l'an dernier de refaire l'équivalent du préprocesseur de gcc, mais je me rends compte aujourd'hui que je suis parfaitement libre d'utiliser autre-chose que des macros C pourvu que je sois en mesure de produire le fichier voulu. Par exemple en produisant un fichier .h à partir de ce que le nouvel éditeur utilise pour connaître les variables, les compteurs, les types de collisions, etc.

Ce sous-projet m'intéresse pas mal, et commence à consommer de plus en plus de feuilles quadrillées dans mes petits carnets, même si je traîne un peu à blogger tout ça ces derniers temps. J'ai ma petite idée sur la saisie de texte (à mi-chemin entre pixel-art et reconnaissance d'écriture manuscripte), par exemple, ou  la possibilité de représenter sous une forme d'arbre les expressions mathématiques du style "v6 := min(v6 - 32 , -400)" qui s'écrit en GobScript "v6 32 - 400 ~ m :6" pour être plus facile à traiter par l'interpréteur.



Sunday, June 18, 2017

runme + assault = todo

I'd love to have the time to provide a real tutorial for people to start working with libgeds. So far, the best I have is a package with 8-bitifed graphics for AppleAssault and the corresponding game/character scripts... which -- thanks to some work I did a few weeks ago -- now also comes with a copy of RunMe that can run all of that. Maybe that will at some point make it more interesting to start working with the Game Engine for DS.

Of course, because runME is a tool primarily designed to transfer files, it will not exactly be easy to start a game there.


Bon, j'avoue, j'adorerais avoir le temps de travailler sur un vrai tutoriel pour le système lib geds, mais jusqu'ici, la seule chose qui s'en rapproche un petit peu, c'est une sorte de kit avec les graphismes de Apple Assault en version 8-bit et les script correspondant pour les personnages et pour le jeu. Et grâce au travail de ces dernières semaines,  tout ça i tourne maintenant avec une version récente de runme. youpi. Peut-être que ça rendra les choses plus faciles pour ceux qui veulent commencer à travailler avec le game engine for ds on peut toujours rêver...




click 'offline', then 'cmd'click 'A' to pick one of ASSAULT*.CMD, and then click the name you want to runpress now L+A to load the script into the memoryand now press L+Y to process that script to the end.

Évidemment, le programme 'runMe' est avant tout un outil de téléchargement. Donc il faut un peu chipoter pour pouvoir démarrer son programme:  passer la détection réseau , par exemple, puis choisir le fichier qu'on veut démarrer, et des commandes un peu barbare du genre La+À ou L+y pour démarrer la lecture du script ou pour l'interpréter sur la DS.

When I want to run this, I do it with desmume-cli, using --cflash-path=AA-efsroot (which is in the 'runMe.zip' archive) and --load-type=1. But that only works in Linux. For windows user, you'll have to go into config->slot2 and setup the directory manually (I just hope for Windows users that they can somehow save that configuration)
Il faudra aussi s'assurer que l'émulateur a accès au fichier du jeu qu'on veut essayer. Moi, je fais ça à la ligne de commande dans Linux, mais évidemment, les gens qui travaillent sous Windows devront passer par les menus de configuration de desmume pour avoir la même fonctionnalité ( voir l'image).

Voilà, avec tout ça vous avez la possibilité de tester le jeu que vous avez vous êtes en train de développer, mais malheureusement, s'il y a des erreurs dans le script, c'est encore très laborieux de les trouver et de les corriger. On peut faire mieux avec l'outil de test automatique que j'ai développé pour mettre School rush au point, mais c'est un truc qui doit être compilé à part. Et pour l'instant, il faut même le compiler à chaque fois qu'on veut essayer de traiter de nouveaux script pour un nouveau jeu, donc il faudrait que je fasse appel à l'équipe pour avoir une variante qui tourne sous Windows histoire que les jeunes puissent essayer de faire le même. Mais voilà, l'équipe, pour l'instant c'est juste bibi. alors soit vous vous enrolez, soit de vous patientez. Ciao.

All this makes you able to try the game you're developing, but when there are errors in the script, you just have a stop with the content of the offending line dumped.
Hopefully, It can now also be checked with 'testme', the unit-testing tool for current School Rush game. (which unfortunately still requires a rebuild for Windows everytime you change the scripts you want to check).

I could really use a helping hand to get that going somewhere. Someone who's used to do builds of Linux native projects in a Windows environment. Even then, it's unclear whether I can compete with a tool such as DSGameMaker, but I still think people should have the choice ^_^


Oh, et si vous allez jusque là, la présence du "log" deviendra vite gênante dès le niveau chargé avec succès. Rassurez-vous: il est tout à fait possible de le faire disparaître: il suffit pour ça de toucher le bouton 'log' sur l'écran du bas. Et si vous voulez retourner charger un autre niveau, le bouton "beam out" vous ramènera sur l'écran avec la liste de fichier et le "clavier virtuel" (qui fait les "lettres paires" quand on garde L enfoncé, soit dit en passant).

Et pendant que vous lisiez tout ça, j'ai ajusté la position des vagues d'encre pour le "niveau retour" de School Rush...