Funnier Apples

Depuis le début de mon carnet en cours, j'ai un objectif "rendre les pommes plus fun". ça passera par des interactions révisées mais aussi par des compléments d'animation. Entre autre, quand on lance un appleman et qu'il arrive par terre. Le comportement actuel est tiré de dumblador, qui glisse légèrement sur les surfaces planes de l'école avant de s'immobiliser assez rapidement.

Finally! that little sketch of an appleman rolling away when hitting the ground has been teasing me for month at the start of my notebook, but now I've finally sketched something in AnimEDS. Hopefully I could try to integrate it in the prototype this week-end.

It should trigger when you've thrown an appleman and its hitting the ground. The current way it slide for a few pixels before settling feels incompatible with the spheroidal nature of an apple but I still have to decide whether it will bounce-roll or just roll. Likely "just roll" will work better with slowing it down. Or maybe it should just keep rolling until off-screen or stopped by a wall ? 

Mais soyons clair: ça ne donne rien de convaincant avec une pomme sur le sol de la forêt. D'où l'idée que la pomme roule un peu en atterrissant ce qui 1) est fun et 2) lui donne un peu plus de portée qu'un projectile classique, ce qui est toujours le bienvenu dans un monde 1.

Pix'n'Gem: La naissance de space invaders

Prenez un Japonais qui maîtrise suffisamment les chips TTL pour avoir réalisé "Speed Race" (mais si! ce jeu d'arcade qui a servi de base au jouet où le volant déplaçait une petite voiture sur une route avançant toujours plus vite ... et à Donkey.bas, au passage :P), qui vit dans une époque où les clones de Pong saturent les machines d'arcade et qui rêve de jeux où les graphismes nous feraient plus voyager que des rectangles et des carrés...

Maintenant, faites-lui se prendre une grande claque en lui présentant le tout nouveau breakout d'Atari. C'est toujours des rectangles et des carrés, mais c'est aussi un jeu complètement neuf! En plus, il vient d'obtenir un processeur 8080 (l'ancêtre du Z80), ce qui va lui permettre d'envisager quelque-chose de beaucoup plus sophistiqué que ces petites voitures (qui étaient déjà franchement pas mal :)

Il ne le sait pas encore, mais il est sur le point d'entamer le développement de Space Invaders, et ce n'est pas un hasard si Pix'n'Love y consacre un article de 10 pages dans son premier mook! L'histoire de Tomohiro Nishikado mérite amplement de figurer dans les référence d'un cours de game design (n'est-ce pas, Mlle L. ;). Partant de Breakout, il modifie le concept, prototype après prototype jusqu'à finalement arriver avec l'idée d'aliens tombant du ciel. On est en plein dans la philosophie de "l'habillage de dernière minute".

• d'abord, des briques, un tireur et des tirs qui montent à la verticale plutôt qu'une balle qui pongue
• les "briques" (en fait des cibles) pourraient bouger: ça donnerait plus de challenge
• il faudrait limiter le temps, comme dans les jeux de tir mécaniques 
• OMG ! en fait ils pourraient faire ce que les cow-boys en alu des salles d'arcades n'ont jamais pu faire: ils pourraient nous tirer dessus si on ne tire pas les premiers! (eh oui, à l'époque, c'était une idée novatrice, voire audacieuse)
• et on aurait pas besoin de limite de temps si les cibles-qui-tirent avancent vers nous. 
• S'ensuit enfin la recherche du bon habillage ... et c'est finalement la folie Star Wars qui donne l'idée

Le dossier ne se limite pas à interviewer sur le développement, cela dit. On a aussi des détails intéressants sur les playtests avec les clients potentiels, le lancement, etc. Mais surtout (pour moi) une note qui retient mon attention: le devkit 8080 coûtant trop cher, l'équipe doit se fabriquer le sien, ce qui lui prend 6 mois hors des 10 consacrés à la réalisation du jeu. Ahurissant du point de vue d'un programmeur de machines tournant à 66MHz, mais le gars a l'habitude de réaliser des circuits, pas juste des programmes. Et son écran n'aura besoin que de 480kHz pour tracer les 256x224 pixels du jeu... ce qui devrait rendre possible le prototypage sur breadboard avant la mise en production d'un PCB.

Bref, la suite du Pix'n Love  #1 devra attendre parce que me voilà parti à fouiller les schémas de la borne pour essayer de reconnaître la partie "générateur d'image" après avoir découvert qu'il utilisait une VRAM en mode "gros bitmap" en creusant dans le code désassemblé (?) qui tourne sur le CPU. Un bitmap, ça veut dire que 8 pixels contigüs sont rassemblés sur un même accès mémoire ... c'est souvent désagréable à gérer surtout quand on a un défilement horizontal: nos données devront être décalées et appliquées sur deux zones mémoire. Mais dans le cas de space invaders, l'écran est placé à la verticale (assez fréquent dans les machines d'arcade), si bien que nos aliens -- qui font justement 8 pixels de haut -- n'ont jamais besoin de décalages. Et pour les tirs, le 8080 est secondé par un registre à décalage manipulé avec les instructions IN et OUT comme s'il était un coprocesseur.

edit: on a aussi un sympathique article de quelques pages sur Toki dans ce numéro (mais qui fait plus figure de test/présentation dans un magazine style PCFun) et un dossier sur la création de Metroïd mais qui reste plus en retrait: quelques trivias sympa, une remise dans le contexte historique, mais c'est tout.

Enfin !

Il fait partie de mon top 20 des jeux vidéos, et ça fait pas loin de 20 ans que j'essaie d'y jouer, des mois que je résiste à la tentation de prendre un abonnement sur ma Nintendo Switch pour y jouer. Le linker GBA s'est avéré décevant, j'en arrivait à envisager de demander à quelqu'un de remplacer une ROM sur une cartouche lambda étant donné à quel point il était introuvable en magasin.

Mais ça y est: j'ai enfin une cartouche de Kirby & the Amazing Mirror(s) pour GBA! (à laquelle je jouerai sur NDS lite, ne vous déplaise ... les gâchettes de Lime fonctionnent encore assez pour appeler à la rescousse:). Je n'irais pas jusqu'à appeler ça une occasion en or, mais je vais pouvoir me replonger dans quelque chose d'inspirant au niveau game design et ça me fera du bien ^_^
 

Signets et attach

J'ai pour la SchoolZone l'intention d'introduire des signets/marque-pages qui pendouillent... on pourrait s'y accrocher (indispensable), grimper, descendre (sympa) et ils réagiraient comme des cordes plutôt que comme des barres.

J'ai appris dernièrement qu'il fallait que je prototype ce genre de choses dans l'environnement des "three rooms" sous peine d'être démoralisé par le côté "nu et inintéressant" d'un niveau à peine commencé. Et coup de bol, il y a un coin de la salle "école" qui conviendrait bien : le haut. On pourrait atteindre les signets en utilisant la gomme et s'en servir pour rejoindre l'éponge, un peu compliquée à utiliser pour l'instant.

Hanging to a rope-like bookmark, using it to swing around and hop to the next ... that's clearly something I'd like to bring into the school zone and I may have just found the right way to introduce it first in the "three rooms" demo. Yes, I could use one of the levels in which they are featured, but recent development on the green zone shown that a rushed large level doesn't motivate me as much as a small polished screen can. They would be there, in the top corner and providing an alternate way to reach the swinging Spongebop.

Avant de permettre de s'y accrocher et de se balancer, je voulais voir comment m'y prendre pour une interaction plus simple: juste laisser Bilou bousculer le signet et qu'il ondule un peu en reprenant sa place. J'ai le comportement "circular" qui pourrait être pas mal pour ça.

Before I'll let Bilou grab them and swing, I'll have to start with something easier, like just having Bilou disturb them and make them swing stronger when passing nearby. It should be a mere matter of attaching segments to one another with the "circular" controller... except that once Bilou pushes the bottom part of the "rope", segments now need to lookup two objects instead of just one. And that's a bit more tricky to handle for my engine that only allow one object pointer per object.  

Sauf que on tombe dans le cas de figure compliqué où les mouvements d'un segment dépendent à la fois de la position du segment au-dessus et en-dessous de lui, ce qui pose trois questions:

• Est-ce qu'il faut que j'ajoute une zone "solide" à Bilou ?
• Quels flags (pour les collisions) sont disponibles pour ajuster les comportements (j'ai oublié ^^") ?
• de quelles infos est-ce que je dispose après une collision entre deux segments ? Est-ce suffisant ? 

J'avais pensé relire le tag "attach" pour me rafraîchir la mémoire, et j'ai eu la désagréable surprise de le trouver confus, avec quelque malheureuses infos pratiques perdues au milieu du "gamedev story". Il est devenu mon "tag de la semaine", mais j'ai dû reconnaître que ça ne suffisait pas. Je me suis retrouvé à essayer de l'extraire avec les outils "blogpress" et lui appliquer une feuille de style avant de l'utiliser pour tester les "pages web codeberg".

So, that was the idea back on 11/11 when I sat down with my notebook and collected the questions that needed answers before I could get to the coding stage. I thought unrolling the "attach" tag of the thread would give me answers, but it turned out the useful information was somehow lost into trivias, screenshots and other progress reports. And the code documentation wasn't much better, so I ended up restoring a setup for blogpress and tutogit at the same time, uploading them all on codeberg and see whether I could apply simple.css etc.

ça m'a donné le déclic pour reprendre le travail sur le repository "tutogit", en plan depuis 7 ans, vu que maintenant le nouveau système de gestion des propriétés du niveau est arrivé à maturité. Je pense que ce serait là le bon emplacement pour des pages thématiques présentant chaque élément du moteur de jeu ... qui puisse au final s'intégrer à la documentation doxygen. Voilà déjà celle pour attach.

simple.css

That's the stylesheet colleagues use when they make some internal website. This is what my HiFi remote control over HTTP is lacking... https://simplecss.org/

Although, I may like it better with a few CSS transitions, especially for the navigation header:

header > nav a,
header > nav a:visited {
  margin: 0 0.5rem 1rem 0.5rem;
  border: 1px solid var(--border);
  border-radius: var(--standard-border-radius);
  color: var(--text);
  display: inline-block;
  padding: 0.1rem 1rem;
  text-decoration: none;
  transition-duration: 0.2s; // added
  
}

header > nav a.current,
header > nav a[aria-current="page"],
header > nav a[aria-current="true"] {
  border-color: var(--accent);
  color: var(--accent);
  cursor: pointer;
}

header > nav a:hover { // forked out of block above
  border-color: var(--accent);
  color: var(--accent);
  cursor: pointer;
  transform: scale(1.1); // added
  transition-duration: 0s; // added
}

It acts on <a> tags that sit withing the <nav> in <header> section, making them more ... playful and engaging ? It's been sitting here for a while, but now that I'm toying a bit with codeberg pages, It's time to publish my original (Nov '24) notes as well ^^"

The basis of  simple.css is to create a grid at page level, and to indicate on which cells of the grid each item should fit. Lines are created automatically by titles, paragraphs and things alike, while columns are templated once for all.

The core layout of the document is defined by grid-template-columns: 1fr min(45rem, 90%) 1fr;, which is where the 3 columns come from.

• column 2 is 720px (45*16) if that fits, 90% of the page width otherwise.
• columns 1 and 3 are as large as allowed, the fr unit being "how much space is left". Apparently, balancing available space between the two is automatic although you could have used .5fr 45rem 1.5fr to get one margin bigger than the other.

45em is more or less the size you need for a 60-75 characters amount in English (the target of most LaTeX documents). There will be another rule stating grid-column: 2; within body > *, meaning that anything within any tag within <body> goes into column 2. That's why my blogger-to-simple script ends up with some text weirdly on column 3 when it isn't in any tag, but just sitting directly within <body>

Survivre à Octobre

Bon, c'est sans doute excessif comme formulation, donc pardon pour le drama. Mais le mois d'octobre n'a pas été de tout repos. Entre les travaux sur la maison qui sont sur le point de démarrer (mais qui s'accompagnent de mauvaises surprises), les efforts pour la désencombrer et les déboires accompagnant les remplacements de PC au bureau, j'ai rarement eu assez de tonus pour envisager du gamedev en fin de journée ... encore moins pendant les week-ends. 

Ce qui aura le plus fait progresser "dreamland", ç'aura été les efforts sur les "pentes glissantes" qui interviennent ça et là dans les niveaux dessinés par mon frangin pour la "green zone" il y a tant d'années. Ah, et je vous rassure tout de suite: elle n'auront pas cette dégaine d'ovni digitalisé : ça c'est juste un montage pour essayer de me rendre compte des couleurs à utiliser, des ombrages qui marchent ou non, etc. 

Non, le graphisme actuellement utilisé pour la démo est beaucoup plus sommaire que ça, pas franchement mieux intégré.

Le comportement de base est codé, mais il reste insatisfaisant, en particulier parce qu'il permet de sauter à pleine vitesse vers l'avant même si l'eau nous faisait presque reculer. Le mécanisme de "tapis roulant" ne suffit pas ici. 

J'avais aussi envisagé au début du mois de commencer à dessiner quelques sprites pour le personnage de "Napin", ou au moins d'étudier les oreilles des Tiny Toons, mais ça non plus, ça n'a pas réellement eu lieu. 

Out of Memory

There's something going disturbingly wrong with my debian setup ... I thought it was mainly an issue with firefox, where the whole system froze and became completely unresponsive when youtube's scripts push the browser out of memory bounds. But it just happened as I tried to convert a too complex picture into a stack of svg path with inkscape while still having gimp opened with the bitmap edits and consuming about 3G of RAM to host them.

Usually, I can then access a text terminal and launch the top tool to kill the process that went crazy, but with that debian 12, it seems like it couldn't even keep that in memory ... too often, I end up having no other option but forcing the system to shut down, losing whatever state I had on the machine.

A message on stack exchange describes quite accurately what is possibly going wrong: the system has been assigning so much memory to data that it started stealing pages of executable code from processes ... and unfortunately, those processes call these pages back, forcing the swapper to find something else to kill, again and again. the "Out Of Memory" behaviour of the system does not kick in, or not before things have been running wild for over 10 or 20 minutes.

I've found some blog page presenting "Early OOM", an alternative that would kill memory-hoggers process in advance. Got it installed ... Got to check whether it helps ... Still have to write a wrapper to firefox launcher that would ulimit its consumption of virtual memory (did check it is effective).

(Maybe having a look at https://fedoraproject.org/wiki/Changes/EnableSystemdOomd could be useful, although it is for fedora installs) 

Spotting systemd_oomd running on my ubuntu (virtual) machine ...