La forêt de Castle of Illusion ?

C'est l'histoire d'un screenshot qui arrive juste pendant que je réfléchis à décorer un peu mieux ma "green zone". Il aurait mérité d'être avec d'autres dans la section "études pour dessiner des arbres dans mon jeu" ... ou pas. C'est un screenshot de Castle of Illusion sur MegaDrive, mais pas ce niveau qu'on a tous vu, non le suivant. Celui qu'on coupe au montage. Celui où il va falloir éviter de tomber dans le vide et éviter de se manger les araignées ... 

C'est Régis Monterrin qui avait attiré mon attention dessus avant que je ne note des bizarreries dans les tiles, un peu comme si l'artiste avait fait un chouette truc puis que l'outil pour exporter son travail avait buggé et que personne ne s'en était rendu compte.

Parce que bon, on a tellement de carrés répétés indépendamment de la texture, de transition brutale entre palettes de couleurs aux frontière de la grille-de-tiles que ça en devient presqu'un contre-exemple de pixel-art, où les spécialiste vous donneraient des astuces pour éviter qu'on ne remarque que tout n'est que carrelage aligné sur une grille.

En fait, au fil de l'évolution de ma "green zone", je suis passé par un état un peu de ce genre et j'ai noté que ça me faisait inévitablement penser à ce jeu C64: Forbidden Forest. (et sa suite, sur le screenshot)

Forbidden Forest, c'est le jeu qu'il vaut mieux ne pas regarder de trop près. Alors ok, pour un jeu de l'époque 8 bits, avec un maximum de 256 caractères à l'écran alors qu'il y a place pour plus de 1000 d'entre eux, c'est le truc le plus organique et le plus varié que vous puissiez faire. Là où l'état de l'art, ce sont les écrans interchangeables de "Pitfall" ou la répétitivité de Wonder Boy, ici, on est sur un scrolling continu d'arbres tous différents les uns des autres ... mais aussi sur une omni-présence de l'angle droit.

C'est là qu'est intervenu Aurélien Simon:

Tout ça disparaissait sur un bon vieil écran CRT évidemment. Juger du graphisme de cette époque sur un LCD n'a pas de sens, puisqu'ils étaient créés sur et pour le CRT 

J'avoue que j'avais un peu de mal à y croire. Que le côté "patterns bizarre" du tramage ne pose pas de soucis, oui. Mais ces gros pavés ? ces lignes horizontales et verticales quasi-continues se feraient adoucir rien que par le balayage ?

J'ai cherché un peu sur youtube, des fois que quelqu'un aurait effectivement joué à ce jeu sur tube cathodique ... c'est un des niveaux qu'on avait fait avec J.L.N lors d'un "ludifestival", mais à l'époque, manette en main, on faisait bien sûr beaucoup plus attention aux feuilles-plateformes-géantes qu'au décor. Pas de chance, la seule vidéo que j'aie trouvé, c'est celle ou le joueur a coupé cette séquence au montage.

Mais pendant ce temps-là, Aurélien, lui, avait ressorti son bon vieux Phillips et sa méga-drive et re-joué à Castle of Illusion jusqu'à ce niveau-là pour refaire un screenshot (non?) réaffiché l'image de Régis pour la prendre en photo.

Et là, il faut bien reconnaître qu'à part la ligne horrizontale à hauteur du pied de Mickey, sur la gauche, ça donne plutôt propre. Ni les joueurs ni les testeurs de l'époque n'ont dû y trouver à redire.

Bon, fondamentalement, ça ne change pas grand-chose en ce qui me concerne: puisque mes pixels à moi vont être sur la NintendoDS, je n'aurai pas de flou gaussien pour venir à ma rescousse :P 

What's wrong with Gimp ?

 J'avais jusque là la 3.0.6 sur la machine windows du bureau ... qui m'a déplu sur plusieurs aspects. Petit tour d'horizon avant de passer à 3.2.4

• sauf que tout à coup, c'est la 3.2.2 qui s'ouvre !?
• les niveaux de zoom sont devenus beaucoup plus étalés, notamment quand on zoome avec CTRL+roulette ... au point que avoir un 200% ou un 300% "propre" pour une capture d'écran de pixelstudy devenait impossible sans aller entrer la valeur à la main. 3.2.2 corrige ça en permettant de monter à 33, 50, 66.6, 100, 150, 200 avec les raccourci clavier "+" et "-"
• changer de couche avec PG up et PG down ne permettait que de sélectionner la couche, pas de l'activer pour les opérations de dessin et de copier/coller. c'est corrigé avec 3.2.2 

Est-ce que je deviens chèvre ? Non. C'est le nouvel outil de sécurité du boulot qui fait les mises à jour dans notre dos. Sans avertissement, sans résumé d'opérations. Rien.  

Restait le panneau d'impression qui indique maintenant "pas de prévisualisation possible". Un comble pour un programme de dessin ! Un petit tour dans la base des registres pour ajouter PreferLegacyPrintDialog=(DWORD)1 sous Computer\HKEY_CURRENT_USER\Software\Microsoft\Print\UnifiedPrintDialog et on revient à quelque-chose de moche, mais utilisable.

UDHCPD enfin automatisé

C'était une étape casse-pied du dévelopement DS ici: à chaque fois que je voulais échanger des fichiers par WiFi, il ne me suffisait pas de brancher mon stick wifi, je devais aussi redémarrer le service DHCP sur mon cube. sudo service udpchd restart ... j'ai tapé (ou cherché dans l'historique) un nombre incalculabe de fois. Sans ça, la DS ne recevra pas d'adresse IP.

J'avais essayé d'ajuster les scripts de NetworkManager/dispatch mais sans grand succès. Guère plus du côté du service systemd.

Au final, c'est dans /etc/network/if-up.d que j'ai ajouté un lien qui a fini par fonctionner. 

 

#!/bin/bash

interface=$IFACE
event=up

log() {
        echo $* | systemd-cat -p info -t if-up
}

log "$0 (interface=$interface, event=$event)"
if [[ "$interface" == "enx000272436672" ]] ; then
        log "this is your USB WiFi stick ..."
        if [[ "$event" == "up" ]] ; then
                service udhcpd restart
        fi
fi

Ok, ce n'est pas terriblement convaincant pour les transferts via runME, puisque là je dois toujours déterminer quel fichier envoyer/recevoir dans la ligne de commande, mais au moins ça me permet de faire les mise à jour des outils sans avoir besoin d'ouvrir le laptop... dans le cas où le fix avait déjà été mis sur le cube la veille :P

La surprenante histoire de Xevious

Entre deux chapitre du gros volume sur les jeux Harry Potter, j'ai aussi réemprunté à mon frère les premiers Pix'n'Love, avec l'intention de repérer les titres qui pourraient intéresser Mlle L de la S-Team qui nous fait un cursus lié au jeu vidéo.

Dans ma liste de "pix'n'gems", le 4eme mook était renseigné pour Lode Runner, mais avant d'en arriver la je me suis retrouvé scotché par la présentation du développement du shoot'm'up Xevious. Un titre dont je n'avais jamais entendu parler avant la sortie du magazine et qui n'est pas franchement attrayant à mes yeux de padawan de pixelation.

Mais voilà. S'il n'y a pas des masses d'éléments visuels pour nous raconter la genèse de Xevious dans le dossier, c'est parce que le développement s'est fait à contre-courant d'à peu près tout ce qu'on a eu l'habitude de présenter, avec un gars qui bosse en solo mais dans une grande boîte, qui fait tout "au feeling" directement dans le code au point qu'il faudra une équipe de reverse-designers pour faire les documents que le management voudra signer avant que la borne ne soit lancée. Et qui écrit un roman pour raconter l'histoire de l'univers de son jeu là où "pas besoin d'une histoire quand on a un bon gameplay" règne en maître.

Est-ce qu'il y a des enseignements à en tirer pour développer des jeux au XXIeme siècle ? .... j'hésite. Est-ce que c'est intéressant de découvrir le travail du futur développeur de Tower of Druaga, ce titre étrange et iconique des salles d'arcades japonaises des années '80. Absolument!

20 ans de Nintendo DS

Il y a 20 ans, j'ai reçu plus qu'un nouveau gadget. Une nintendo DS .. avec aucun jeux, en fait. On nous avait annoncé un nouveau Super Mario, un nouveau Zelda et un nouveau Yoshi Island. Bien plus intéressant que les projet rub et zoo keeper qui avaient accompagné la sortie.

Comme j'avais envie de revenir un peu sur tout ça, j'ai fait un petit récapitulatif de la première année de développement et blogging sur bsky ... et d'une façon assez surprenante, ça a explosé les réactions.

Et ils n'ont pas encore vu cette ligne du temps tortueuse qui reprend les milestones, les releases et les interventions et commentaires de "guest stars" 

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.

Petit à petit, le niveau se construit...

Bon, j'ai passé un peu de temps dans mes éditeurs sur DS ces derniers jours pour habiller un peu plus le premier niveau et je viens de construire une map avec le 2eme (après un moment de frayeur de "est-ce que je ne viens pas d'écraser mon gac.map en essayant de créer gpc.map ?_?"), tout ça pendant que je faisais la mise au point des portes du côté PC.

• un arbre tout à gauche pour marquer le bord du niveau
• (pour une raison inconnue, sortir de la map par la gauche conduit à un plantage de runme ... à investiguer)
• une petite pente avant le premier arbre pour rendre le niveau moins plat, valider le graphisme des pentes et faire de la place pour des plate-formes avec les petits vers dessus (côté notuto)
• il faut encore une palette alternative pour la terre dure et des images de bord pour la terre d'arrière-plan
  

I've spent some times on PC to get doors working, but also some time on the NintendoDS itself, putting more tiles around the edges of crude level I had last week. I even tried to start importing the second green zone historical map, but a blue screen in LEDS put that to an end. (possibly linked to bad handling of color palette selection in "paint" mode). It highlighted I'm lacking some darker tones for some parts of the color palette (mostly dirt) and some edge tiles for the "far away dirt"

So here's a couple of screenshots that were part of the last "Screenshot Saturday". One of them illustrating an attempt to implement the "sliding stream from waterfall" which doesn't quite work the way it should: it's too easy to force your way by quickly jumping away again and again. plus, it doesn't kick out into the water once you're at the bottom of the slope. To be investigated

• première tentative pour la cascade-glissante
• quelque-chose empèche le système actuel de nous jeter hors d'une pente avec les tiles "tapis-roulant" ... à creuser.
• correction des hitbox de Bilou qui nage pour qu'il arrête de se manger les murs à tout bout de champ
• habillage de la "cachette sous l'arbre" ... je la trouve un peu petite dans son état actuel ...

Par contre, avant la prochaine release, il faudra vraiment que je prenne le temps de dessiner une deuxième moitié au décor de fond qui convienne pour "au plus profond des cavernes sous la forêt" ...

README: The Sprite Decade

Présenter l'architecture des consoles, du gameboy à la XBOX ... rien de moins que ça. Voilà le contenu qui vous attend depuis 2020 si vous cliquez sur le lien "Copetti" dans la liste "blogs I watch" de cette page. Et oui, la Nintendo DS s'y retrouve ;)

C'est déjà quelque-chose, mais Rodrigo Copetti -- l'auteur du site -- n'en est pas resté là: il a commencé à rassembler ses articles pour nous proposer des version imprimées des bouquins... et j'ai donc craqué pour "The Sprite Decade" qui reprend les machines 8 et 16-bit de Nintendo et Sega auxquelles s'ajoutent la TurboGrafX (aka PC Engine) et la Neo Geo.

Bon, c'est vrai que pour la NES, j'ai déjà le bouquin de Nathan Altice: I AM ERROR, et la SuperNintendo est largement couverte par les vidéos de Retro Game Mechanics Explained. Mais les avoir un peu toutes sous la main, pouvoir retourner voir la vue d'ensemble sur les propriétés de l'une et l'autre ... c'est un bouquin bien pour moi. Bon, j'avoue, j'aurais probablement ajouté encore d'autres détails techniques parce que bah ... on ne se refait pas, mais c'est une bonne base. Une sorte de syllabus de cours sur lequel j'ai déjà commencé à prendre des notes pour me faire ma référence des consoles rétro.

Puis je dois bien l'avouer, il y a une autre raison qui m'a poussé à acheter ce livre: je voulais voir comment il rendait. Parce que je n'ai pas encore abandonné le rêve de convertir un jour tout ce texte en une version linéaire sur papier. Et bien, ça rend rudement bien. La prise en main est bonne, la qualité du papier nickel, un rien velours... Et Rodrigo a travaillé sans maison d'édition, un peu comme Jill Bearup (qui a du 18:6 entre le prix de vente de sa version Amazon paperback et ce qu'elle en retire)... ce qui pourrait peut-être intéresser M. Jared qui cherchait un éditeur/imprimeur pour son bouquin sur le homebrew sur Nintendo DS (justement). 

Un bémol, toutefois: pour offrir une taille maximale à certaines images, Rodrigo a décidé de les imprimer en format paysage ... sur un livre version portrait. Si ça permet effectivement d'avoir plus de détail sur les photos des circuits imprimés de chaque console, ça me semble discutable pour la photo de la NES dans sa boîte en plastique, et c'est franchement dommage pour les différents schémas d'interconnection entre les composants. Le texte est disponible aussi sous github, mais pas les images...

Bon, et non, je ne suis pas devenu fan d'Amazon pour autant. A vrai dire, j'ai même failli passer mon tour quand j'ai vu que le site me réclamait pas loin de 20€ de frais de port et douane pour un bouquin à moins de 30€ ... Puis vérification faites, Rodrigo Copetti nous écrit ça d'Ecosse ... donc en passant par Amazon.fr, mon édition est finalement imprimée en France et mes frais de port me sont offerts. Donc, force et courage aux camarades qui luttent pour des conditions de travail honnêtes dans les entrepôts. Des que je trouve un moyen de soutenir les chercheurs/rédacteurs sans contribuer à votre oppression, je pousse sans hésiter sur le bouton, m'sieurs dames. 

MechaSkull's ninja

J'ai à peine atteint le boss des catacombes dans The Messenger que la nouvelle tombe: Cyber Shadow, le jeu de ninja de MekaSkull sort la semaine prochaine demain aujourd'hui. Un jeu dont j'ai suivi le développement avec plaisir et assidûité ces dernières années. C'était d'ailleurs un de mes plaisirs sur twitter pendant les années creuses de mon blog: découvrir un nouveau screenshot animé de MekaSkull, et imaginer la raison d'être de ce qu'on voit ou des variantes pour un retour-plus-tard-dans-le-jeu.

Traps activated by powersources. There may be more ways to use them?#indiedev #8bit #pixelart
pic.twitter.com/GVH6sr4gby

— Aarne Hunziker (@MekaSkull) September 27, 2016

Prenons les barrières électriques intermittentes et les "chausse-trappes" à coup de sol qui s'électrifie par moment, par exemple: en introduisant des 'générateurs d'impulsions' (les ronds rouges), MekaSkull permet à la fois de mieux visualiser les timings complexes (façon guitar hero ?), mais aussi nous permet potentiellement de chercher par quel détour on pourrait aller les désactiver et rendre le passage moins hardcore. (s'il ne l'a pas fait dans Cyber Shadow, j'ai bien l'intention de faire ça dans la pyramide de Bilou, d'ailleurs).

Testing room for new enemies. They can now defend themselves with aimed shots... to some extent.#indiedev #8bit #pixelart pic.twitter.com/C9HpIezzH0

— Aarne Hunziker (@MekaSkull) October 10, 2016

Vous aurez probablement compris si vous avez cliqué sur quelques liens pour aller voir les vidéo de gameplay que MekaSkull avait postées qu'on est -- au niveau de l'intrigue -- à la croisée des chemins entre un Ninja Gaiden et un Matrix. Et je dois dire que ça me convient bien.

Il ne manque pas de vidéos sur Internet où les développeurs -- quelle que soit leur expérience -- cherchent à résoudre le problème des 'ennemis stupides' dans un jeu "moi contre le monde". Même la Développeuse du Dimanche y passe [citation requise]. Pourtant, dans ce genre-là, c'est presqu'indispensable d'avoir des ennemis un peu stupides. Pas forcément au point de se jeter d'eux-même dans les trous à la goomba, mais vu leur sur-nombre sur nous, c'est ça où nous rendre tellement blindé d'armure qu'on se demande comment on arrive encore à bouger.

That one enemy didn't seem too tough....#indiedev #8bit #pixelart pic.twitter.com/8QpK23pLAv

— Aarne Hunziker (@MekaSkull) January 23, 2017

Pour moi, le setup 'cyberpunk' avec des robots comme adversaires offre une excellente justification: ce ne sont que des machines. Une tenue de camouflage peut en effet faire en sorte qu'elles soient 'myopes' comme des taupes. L'absence d'instinct de survie peut expliquer qu'elle continuent à faire leur ronde bien qu'on vienne d'éliminer trois de leurs clones, etc. Et on peut matérialiser la borne qui leur envoi un message de 'fin de recherche' si elles n'ont pas trouvé leur proie au bout de 20 secondes (et donc détruire cette borne si on veut).

On peut même justifier leur montée en aggressivité au fur et à mesure qu'on progresse dans le jeu par des mises à jour un peu rushées du genre "dévier l'alimentation vers la coque en cas de choc inexpliqué" (traduction: l'ennemi qu'on utilisait jusque là comme plate-forme va pouvoir maintenant s'électrifier après 1 seconde quand on lui tombe dessus, mais en revanche, ça vide ses batteries pour nous tirer des boulettes dessus).

Some skills can be used in unorthodox ways to avoid traps and travel faster. #indiedev #8bit #pixelart pic.twitter.com/0nwnhaBQRN

— Aarne Hunziker (@MekaSkull) October 3, 2016

Enfin, voilà. Avec le soucis du détail qui a été mis dans ce jeu, j'espère très sincèrement qu'il retiendra l'attention des sélectionneurs de l'Ultime Décathlon!

Sonic Mania

Il faut le reconnaître: Sonic Mania est une réussite. Ces nouvelles couleurs sont tout simplement fantastiques. Le mélange entre ancien et nouveau est particulièrement réussi. Je trouve le design franchement bien pensé, avec un premier niveau par zone qui est un hommage au niveaux originaux alors que la 2eme zone se lache pour étendre la formule. On retrouve ainsi un lac souterrain et des totems géants en deuxième volet de la "Green Hill Zone" (et si je ne me trompe pas, on peut déjà en avoir un aperçu dans certains itinéraires de la première zone).

Le changement est encore plus marquant dans la Chemical Zone, qui offre un revisitage de mécanique de jeu qui n'est pas sans rappeler la main-du-maître revisitée dans Link Between Worlds.Je m'explique.

La Chemical Zone de Sonic 2 est remplie d'un liquide chimique pénible, avec en plus des gouttes d'un autre liquide chimique. L'un tue rapidement, l'autre lentement (enfin, l'inverse). C'est probablement le premier véritable obstacle du jeu, et on a beau faire, contrairement à de la lave qui nous blesse mais sur laquelle on peut courir pendant nos phases d'invincibilité, dans un produit chimique, Sonic coule.

Mais dans le 2eme niveau de Sonic Mania, on fait apparaître des switches qui permettent de faire réagir ces liquides chimiques pour produire une sorte de slime ultra-élastique et obtenir un trampoline géant. La difficulté transformée en fun par l'intermédiaire des actions du joueur, c'est déjà bien chouette. Quand en plus ça se traduit en trampoline (sans pics par-dessus) dans un jeu de plate-forme, c'est fun-compte-double.

Bien sûr, on saute dans un jeu de plate-forme. Mais régulièrement, on ne saute pas assez haut. Parfois il y a un bumper pour nous propulser plus haut, mais il y a alors le risque de mal retomber, ou de rater sa cible. Une salle-trampoline, c'est de la pure gourmandise: saut jusque tout en haut, on peut tout attraper, on ne prend aucun risque. 

(Bon, ça fait un moment que Sonic Mania est sur ma switch, bien sûr. Les notes qui disent "J.L.N a encore les réflexes un peu lent pour éviter les crabes qui lancent des boules en ouvrant les pinces" doivent dater du mois d'Avril).

Pour l'instant je cale sur le boss de la Flying Battery Zone, mais il y a un dernier élément sur lequel j'aimerais revenir: la boule-rouge-à-ressort de StudioPolis Zone. Une variation sur le thème du trampoline qui vaut la peine qu'on y regarde de plus près.

Ceux-ci ne propulse franchement pas haut, mais on a bien le temps de profiter de leur animation atypique. En plus, ils déclenchent "à la demande" une animation normalement plutôt rare de Sonic (celle utilisée pour le faire marcher dans les pistes-tourbillon de la GHZ).

Leur forme sphérique s'accompagne d'une mécanique où on est propulsé un peu dans n'importe qu'elle direction, les transformant en un mélange entre bumper et tapis-roulant, mais comme ils sont placés en groupes assez généreux et à l'écart des dangers, ils restent fun.

Infogrames

Regis Monterrin et Florent Gorges ont obtenu une interview avec un ancien designer de jeu chez Infogrames durant la période SNES à N64: Vannara Ty, interview qui est rediffusée sur la chaîne "les petits secrets de la playhistoire". On y discute entre autres de l'évolution du projet "Schtroumpfs 64" -- un projet ambitieux, mais qui doit faire face à une période où la société ne sait pas encore sur quelle machine 3D miser et où il est donc nécessaire de faire toute la phase de pré-concept sur "ClaireFontaine Engine" parce qu'il n'est pas possible d'acheter une license de 3DStudio Max pour travailler sur un projet qui n'est pas encore validé. Mais la déclaration qui m'a retenu est la suivante:

[Peyo] n'a jamais vraiment eu de feedback négatif sur tout ce qu'on produisait. Déjà, de base, ils n'étaient pas gamer donc ils nous faisaient vraiment confiance.

Bien sûr. On a beau parler de Peyo-fils ici, le gars a la quarantaine quand le projet démarre. Pas loin de l'âge de mon e-Papou, qui ne se sera jamais vraiment à l'aise joystick en main. Alors le chasseur impérial qui sert de contrôleur à la N64 ou même les 6 boutons colorés de la SNES ... ils préfèrent sans doute laisser les spécialistes du testing (ceux qui à la fin du développement finissaient Tintin au Tibet en une vie, donc, avec des défis speedrun) de chez Infogrames leur montrer que tout marche bien que d'essayer le jeu eux même. 

Autre révélation-choc: quand Vannarra fait le design de Tintin au Tibet Le Temple du Soleil - ce titre techniquement impressionnant mais à la jouabilité difficulté monstrueuse (?) - il vient d'être engagé chez Infogrames juste après la fin du développement de Tintin au Tibet : c'est son premier jeu. C'est son stage (période d'essai?).

J'avais règlé les niveaux tellement durs que même les testeurs n'arrivaient pas à les passer. [...] Puis un jour [en revenant de vacances], les réflexes étant moins top, j'ai découvert les atrocités que j'avais faites subir aux testeurs et j'ai revu la difficulté pas mal à la baisse.

 Il nous avoue aussi qu'une fois le jeu fini, après un marathon de 10 mois uniquement là-dessus, il n'a évidemment qu'une seule envie: ne plus y toucher. Ce qui expliquer que ce soit un p'tit jeune qui ait travaillé sur le nouveau jeu, et pas le "chef" de l'équipe de Tintin au Tibet (pour peu qu'il y ait eu des chefs d'équipe à l'époque).

Kirby's Dreamland

Permettez-moi de revenir en 1993. Jeune ado qui vient de commencer à envisager de laisser tomber son projet "Calimero" pour quelque chose de plus ambitieux avec pour personnage une boule bleue: Bilou. Puis mon frangin revient de chez notre jeune voisin avec un ovni pour Gameboy: Kirby's dreamland.

Fan de jeu de plate-forme, je fais d'abord la grimace devant le fait que le personnage peut voler à volonté: ça va tuer complètement l'intérêt du jeu. Puis je vois l'écran-titre, et je suis scotché par l'animation du personnage.

Pourtant le nombre d'images en lui-même n'est pas si énorme. Si on fait abstraction des sprites gonflés, c'est même assez standard pour l'époque. Mais avec un dosage parfait des versions "applaties" sur les murs et les petites étoiles qui soulignent les chocs au sol, cette petite variante ou Kirby (je dois vraiment me concentrer pour ne pas écrire "Bilou") plonge vers le bas quand il tombe depuis trop longtemps ... la magie prend. Et les petites "cutscenes" ajoutent juste ce qu'il faut pour que les temps de chargement deviennent une partie amusante de l'expérience.

Le jeu est court. 4 mondes, 4 boss. Pas de nette séparation de chaque monde en 'niveaux', mais plutôt une séquence de 'salles' entre-coupées par des portes ou des petites animations (faisant généralement intervenir une 'warp star' et un peu d'humour). Vient ensuite une sorte de "boss rush" précédé de salles "remixées" du niveau de chacun de ces boss avant d'affronter enfin sur son ring King Dedede -- qui pour une fois semble responsable des maux dont on l'accuse.

C'est le premier jeu Nintendo qu'on termine (heureusement, vu nos 15 ans?) et nous découvrons alors le mode "extra" que je n'ai toujours pas fini 25 ans plus tard. Si j'ai joué au maximum de 'vrais Kirbys' que j'ai pu rencontrer depuis (dédaignant les épisodes basés sur des pinceaux et des bouts de ficelle -- peut-être à tort), Kirby's dreamland a sans aucun doute gardé une place spéciale dans mon coeur et il est souvent arrivé que je remette la cartouche dans ce qui me tenait lieu de game boy pour me refaire une petite partie.

Si ça n'a pas été facile de faire apprécier le jeu à J.l.n (qui préfère quand Kirby peut attraper des pouvoirs) ou à *deline, les choses ont changé quand il s'est vu mis à l'honneur lors de la compétition de speedrunning francophone l'an dernier: l'ultime décathlon 7 que les enfants suivent maintenant avec avidité.

Voilà. Ca faisait bientôt 10 ans que je voulais prendre le temps de parler de ce petit jeu. C'est chose faite. Et si je m'y mets enfin, c'est qu'en voyant J.l.n aller jusqu'à Lololo/Lalala hier, je me suis dit qu'il y avait quelque-chose d'intéressant dans la formule "Dream Land", et que je devrais peut-être bien m'en inspirer pour faire un Bilou Dream Land, techniquement moins ambitieux que "Infinite Pyramid" et probablement faisable en 2 ans si je m'y prends bien.

J'ai donc repris les maps du jeu entre deux motiliums pour voir un peu dans quelle catégorie on joue.

Green Greens : 26 écrans, avec des zones relativement grandes et des environnements simples et ouverts

Lololo Castle : environ 30 écrans. Nombreuses petites zones inter-connectées. Principalement à l'intérieur avec une tendance à désorienter le joueur.

Floating Islands : 36 écrans plus quelques salles bonus et des cutscenes. Mélange intérieur/extérieur tout en restant dans le thème 'île aux pirates'

Bubbly Clouds : probablement aux alentours de 42 écrans. avec une progression de "pays des nuages" vers "monde des étoiles" en passant par le panthéon grec perché sur les nuages.

Si mes derniers chiffres sur le nombre d'écrans est douteux, c'est que pour les petites salles, les gars des studios HAL ne se sont pas fixés sur des nombres d'écrans entiers. On se retrouve ainsi dans le Lololo castle avec des salles de taille 256x192, 320x192 et 384x128 pas franchement alignée sur l'écran 160x128 du jeu quand il tourne sur game boy.

L'idée pour la version Bilou serait de recycler donner vie à un maximum de niveaux du jeu "Bilou's Adventure" prévu à l'origine sans entrer dans les niveaux "souterrains". Pas encore de temple perdu, de zone des insectes-de-chantier ou d'océan musical donc. Je garde la zone du désert vu les récents travaux sur les monstres en guise de "floating islands", et il me reste à trouver un bon environnement (probablement montagnard ... l'influence de Céleste) pour jouer le rôle de zone finale.

Il faut aussi que je décide ce que je fais pour les Boss. J.l.n voudra des boss à affronter, mais ça va clairement augmenter le temps de développement. Le jeu perdra tout intérêt si les enfants ont passé l'âge limite pour jouer à Fortnite d'ici qu'il soit fini.

FlatWorld.artmap

Bon, bin j'ai finalement réussi à trouver les erreurs que j'avais glissées dans mon code et à les corriger. Je peux donc reprendre une des "maps" de School Rush et la convertir à la volée pour qu'elle tourne avec la nouvelle classe "monde" et ses données de collisions séparées des blocs de VRAM du fichier .map. Par contre, ce faisant, j'ai cassé la possibilité d'animer le contenu de l'écran en réaction à une collision avec un bloc spécial.

Je dois reconnaître que j'y vais à tous petits pas, là. Entre autres à cause de la faible quantité de temps libre qu'il reste après les transports et les opérations de maintenance domestiques ... et encore, je suis loin du compte.

Bref, on va commencer par ré-établir un lien entre la "méta-map" et les map-à-images puis il faudra ajuster les changeblock() et autres clearblock() pour que tout passe. Mais caser ça avant St-Nicolas ? Je dirais qu'on est à un niveau d'improbabilité de 3.14 ou pis.

owlboy: monkey feedbacks

J'étais arrive au continent volant, convaincu qu'avoir pris conscience que je jouais à un shoot-em-up allait enfin rendre le jeu plus facile à aborder. Malheureusement, ça n'a pas suffi. Je me débats avec le tir explosif du personnage secondaire, je peine contre des mouches carnivores invisibles pendant des heures pour finalement découvrir dans un let's play (après avoir laborieusement passé la zone) qu'en réalité elles sont juste déclenchées par un timer quand on reste trop dans le noir, et qu'il faut trouver d'autres torches pour les tenir à l'écart, et non essayer de les vaincre.

Je ne peux pas m'empêcher de penser que quelque-chose lié au temps devrait clairement indiqué comme tel au joueur. Ok, l'idée des mouches carnivores est merveilleusement intégré à l'histoire, mais rien ne les lie au temps, au fait d'être dans l'ombre, ni même ne nous renseigne sur ce qu'elles sont réellement.

d'autant que juste après ce dialogue sur la peur des mouches, on tombe sur un buisson avec des insectes qui tournent autour et qui se mettent à nous tourner autour. On ne sait pas les toucher, mais si on brûle certaines lianes (le personnage au "briquet" vient de nous dire qu'il ferait de son mieux pour les tenir à l'écart, c'était assez gros comme tutoriel déguisé), elles quittent les lianes pour se réfugier dans le buisson voisin.

Mais non. Ce n'était pas ça.

Le mouches en question sont noires, et invisibles dans le noir. Et je ne suis pas le seul à m'être tout d'un coup dit "eh ? que se passe-t'il ? pourquoi je perds ma vie, tout à coup ?". On aurait pu être dans une impasse, et être forcé d'apprendre. Les mouches auraient pu être visibles si on est mis game-over. Mais en réalité, si on va suffisamment vite, et qu'on va de l'avant, on reste assez proche des lucioles innoffensive jusqu'à ce qu'on atteigne un 'fruit-lumière'. On a donc pu passer et les mouches vont passer au second plan. Le problème se reproduira plus tard dans le niveau, quand les fruits-lumière se feront plus rares. C'est là que j'ai dû faire appel à un wiki pour comprendre de quoi il retournait, à quoi ressemblaient ces "mouches", etc. personnellement.

Je suis tenté de raccrocher ça au fait qu'on est en face d'un jeu indé, avec une équipe trop restreinte pour qu'à un moment quelqu'un de suffisamment influent et avec assez de recul sur le développement ait dit "non, ça ne va pas. Les joueurs ne comprendront pas". Peut-être bien l'origine de ce que Kirby Kid appelait "that indie feel" ...

Tout ça me donne l'impression que la communication des objectifs et des avertissements n'est pas aussi claire qu'elle le pourrait. Et le deuxième boss dans la lave a tendance à me renforcer dans cette idée. Ici, on se fait régulièrement attraper par un des singes et plonger dans la lave, ce qui met fin au combat. 30 à 40 minutes de jeu plus tard, ça n'avait toujours pas changé. Je ne m'attend plus à passer un boss du premier coup dans le jeu: je sais qu'il faudra que je sacrifie d'abord quelques vies pour comprendre ce qu'on me veut.

Ici, il aura fallu une vidéo youtube pour que je réalise qu'il était possible de se libérer de ce genre de prise. Et non, je n'aurais jamais pensé utiliser le bouton "Saut" pour ça! Ni qu'un tel mécanisme puisse être introduit si tard dans le jeu sans un indice sur l'action attendue. D'autres évènements en cours de combat (comme le fait d'être enflammer) sont annotés avec l'action à faire pour se "soigner". Pourquoi pas ici ?

Iconoclasts perdait peut-être parfois un peu en immersion avec ses icônes, mais au moins les intentions des développeurs étaient claires. Ici, on dirait qu'il manque le message "RELOAD" d'un rail shooter.

Et ce genre de problème de communication va se généraliser jusqu'à ce que l'on trouve le troisième personnage et que le jeu s'écarte un peu du fait de tirer sur des cibles. Mais Alphonse et son arme dont on ne voit ni la portée ni la direction de tir va nous faire passer un désagréable milieu de partie...

https://www.spriters-resource.com/fullview/78065/ {alphonse}
https://www.spriters-resource.com/pc_computer/owlboy/sheet/84737/ {monkey}

owlboy: drôles de contrôles.

Les graphismes d'Owlboy sont superbes, les musiques plantent une ambiance idéale et j'adore l'histoire. Pourtant, pendant tout le début de l'été, je n'ai pas ressenti cet effet d'appel à jouer que j'ai pu avoir avec hob ni meme flinthook. La progression est laborieuse, j'ai la sensation d'être brouillon et de ne pas bien comprendre ce que le jeu attend de moi.

J'ai commencé par penser qu'il s'agissait d'un problème d'interface: si seulement je pouvais
forcer le jeu à tirer quand je pousse sur Y plutôt que de réclammer un ZR, tout irait beaucoup mieux, non ? Ça me remettrait dans une configuration identique à celle d'Iconoclast et de Flinthook auxquels j'étais aussi en train de jouer. Les choses deviendraient enfin naturelles. D'autant qu'en y regardant de plus près, c'est aussi le mode de fonctionnement que j'ai utilisé sur Super Mario World et Donkey Kong Country.

Puis je me suis rendu compte que ce serait incompatible avec le système de visée du jeu et j'ai commencé à prendre conscience de tous les raccourcis prévus dans les actions du joueur. J'ai alors commencé à reconsidérer le jeu, non plus comme un jeu de plate-fomes où on sait voler, mais comme un shoot-em-up avec des phases au sol, et à laisser le jeu en mode "tir automatique" par moment pour me concentrer sur mes mouvements d'esquive.

Et des "raccourcis", il y en a des fameux. Voyez, en bleu la séquence d'actions que j'effectuais jusqu'à la fin du deuxième "donjon" pour pouvoir tirer: d'abord commencer à voler puis invoquer mon partenaire, et enfin, viser et tirer. Il y avait aussi une autre possibilité consistant à faire apparaître d'abord le partenaire, puis à le 'ramasser'.

Tout celà est rendu encore plus compliqué par le fait que certaines pressions de touches peuvent nous faire revenir en arrière, et que lorsqu'il est au sol, il faut être assez près de son partenaire pour pouvoir le ramasser. En clair, dès que le boss va venir vous mettre la pression, c'est fini. D'autant que la plupart des coups qu'on encaisse projettent notre personnage et son partenaire dans des directions différentes. Mais heureusement, si on se concentre sur le côté "shoot-em-up" du jeu, bin le réflexe quand on s'est fait toucher n'est plus de sauter mais bien de se remettre à tirer. Et là, bonne nouvelle: utiliser le bouton de tir nous "téléporte" instantanément dans l'état "en train de voler avec son partenaire accrocher qui se met à tirer dans la direction indiquée par le 2eme stick. On peut dès lors oublier toute la partie bleue dans les phases d'action et se concentrer sur l'essentiel: un stick pour bouger, un stick pour viser, une gâchette pour changer d'arme et une gâchette pour tirer.

Je pensais plus ou moins jusque là que les noms "plate-forme", "beat-em-all" et "shoot-em-up" n'avaient d'utilité que dans un catalogue ou un magasin, mais après plus de 20 ans de pratique du jeu vidéo, on dirait que ça va plus loin. Le fait de penser "c'est un shoot-em-up" semble activer un autre ensemble de réflexes, y compris un mode de vision plus global pour surveiller les trajectoires de plusieurs projectiles à la fois.

Et pourtant, pendant une bonne partie du jeu (et en particulier presque tout ce deuxième donjon), le fait de tirer est beacoup moins impliqué: on va essentiellement résoudre des énigmes en transportant et lançant des objets (ennemis-bombes, nuages ou cruches d'eau pour éteindre les monstres de feu, etc). De quoi endormir le peu de réflexes qu'on aurait pu se constituer dans les phases d'action du premier donjon.

Bref, Owlboy a fait le pari d'un jeu multi-facette, qui alterne des phases de shoot-em-up, des phases de puzzle "à la zelda" et des phases (rares) de réel platforming ("Attention: ces gnomes ont une ouïe super-fine. Ils t'entendraient battre des ailes à 100 mètres. Quoi qu'il arrive, ne t'envole surtout pas!"). Une richesse indéniable, mais pas toujours claire à appréhender pour le joueur. Et qui va vous demander -- tout comme le personnage doit le faire dans le jeu -- d'abandonner derrière vous vos a priori si vous voulez continuer à aller de l'Avent.

Salut!

Salut. Je m'appelle Bilou et je suis explorateur de l'espace. j'ai eu le malheur de m'approcher un peu trop d'une planète non-répertoriée dans le quadrant 79.03.24 et j'ai été mystérieusement happé sur la planète. Mon astronef est hors d'usage, la planète pour le moins curieuse et mon sort serait lié à 7 pierres mystiques auquelles les autochtones prêtent des pouvoir magiques.

Je n'irais pas jusqu'à dire que je peux compter sur mon coéquipier et ami Bouli pour nous tirer de là : cette planète a l'air de faire ressurgir en lui tout ce qu'il semblait avoir réglé comme problèmes d'adolescent... quand il ne se fait pas tout simplement kidnapper *soupir*

centres d'intérêts: astroconduite, planetologie, haute-technologie, biologie des blobs, physique des plate-formes scrollantes, téléportation par ondes Wi-Fi, spirographe hyper-spatial, tir de précision à l'astro-flasheur à perforation en vrille

(c'était la présentation du personnage fictif "Bilou" sur Facebook, mais l'Ordinateur a décidé de remplacer ça par une "description de page" qui est malheureusement limitée à 255 caractères >_<

HoB: les combats

Les combats dans HoB ne sont pas simples. Pourtant, même après avoir découvert qu'il était possible d'en ajuster la difficulté, je n'en fais rien: chaque fois que je parviens enfin à venir à bout d'un monstre, je sens que c'est parce que j'ai mieux joué que les fois précédentes.

J'apprécie assez l'équilibre entre le système de sauvegarde (respawn rapide, sans temps de chargement) et les effets permanents/temporaires du jeu. Ainsi, quand vous éliminez un monstre, il est éliminé à jamais, mais les points de vie retirés à un monstre plus costaud lui sont rendus si vous mourez. Il m'a fallu du temps pour m'en rendre compte, mais ça devient évident dès qu'on commence à affronter des ennemis en armure.

Inutile contre certains ennemis de rester planqué derrière son bouclier en attendant l'ouverture: leurs attaques sont tellement puissantes qu'il n'a presqu'aucun effet.

La solution n'est pas non plus dans une plus stricte observation d'une boucle "narguer - esquiver - bondir - frapper (un coup) - esquiver" : ce genre de tactique rend le combat trop long et finit par me conduire à la faute ... et comme en début de partie on peut tomber sur des monstres qui vous tuent en un coup, mieux vaut éviter.

La clé, je pense, réside dans la mobilité: parvenir à éliminer d'abord les monstres de moindre importance sans attirer l'agressivité du "boss", utiliser à bon escient la roulade (ou la téléportation quand on l'a débloquée) pour pouvoir battre en retraite un peu plus tard. Pour ça, il est indispensable d'apprendre les distances de sécurité et d'action, et de garder la tête froide, histoire de ne pas se retrouver juste devant un caïd quand on espérait passer derrière. Plus tard, dans le jeu, on pourra aussi se servir du terrain pour empècher ces caïds d'utiliser leurs attaques, ou les faire se frapper les uns les autres pendant qu'on esquive.

Fort heureusement, la caméra nous laisse largement de quoi voir les antagonistes, et évite de nous balancer dans un plan serré et confus comme dans un Wind Waker.

Mais bon, je vous raconte tout ça depuis ma première partie où j'ai tardé à trouver des mises à jour pour mon épée, passé une bonne moitié du jeu avant de me rendre compte que je pouvais défoncer certaines armures et tardé à utiliser le bouton "courir" pendant les combats. Il est fort probable qu'une fois les subtilités du jeu maitrisées, il n'y aura plus autant de challenge (mais là, ma deuxième partie est plutôt en mode 'esquive' pour ne pas voir mon fiston commencer à mettre des coups de chaise à tous ses camarades de classe).

On est pas non plus dans un jeu où le système de combat était le coeur de l'attention des développeurs et où il faut presqu'autant de concentration pour jongler avec les mouvements possibles que dans un Street Fighter. Mais aller dire qu'il a été ajouté "parce qu'il fallait bien" ? non, ça serait pousser trop loin. Ne serait-ce que parce qu'une grande partie des items cachés servent à tenir plus longtemps en cas de combat, et pas vraiment à obtenir des "clés" pour avancer dans l'aventure comme ce serait le cas dans Fez.

16 couleurs.

Bon, c'est un peu inévitable: à présenter Bilou sur un forum de dévelopeurs NES arrive la question des "demakes" sur GBA, SNES et autres MegaDrive. J'avais déjà un peu regardé ce que ça pourrait donner suite à un commentaire de MonsieurL sur UltimateConsole, mais ni la SNES ni la MegaDrive n'est vraiment convaincante. Pourtant, il y a déjà des bibliothèques pour les aspects bas-niveau qui auraient pu être intéressantes.

Pour commencer, la MegaDrive n'a que 4 palettes de 15 couleurs, décors et  sprites inclus. Ici, dans Bilou, j'ai travaillé avec 8 palettes de 256 couleurs. Bon, on est bien d'accord, je n'utilise pas l'entièreté des possiblités, mais j'ai quand même au moins 6 couleurs de pieds (2 pour Bilou, 2 pour les Pendats et 2 pour les Dumbladors), 4 couleurs de mains, plus des livres et des fardes qui font pas mal dans le color swap. Bref, il faudrait presque considérer une réduction à 60 couleurs fixes. Il y a bien quelques palettes sympa dans ces eaux-là, ce n'est quand même pas top-sexy, comme résultat.

La SuperNES, de son côté a quand-même droit à 8 palettes de 15 couleurs pour les sprites et 8 autres pour le décor. On est déjà nettement plus à l'aise. Jusqu'à 1024 tiles par plan de décor et 512 pour les sprites (moitié moins que sur DS. On ne s'en sortira pas sans une technique façon Zmiro ou Perry) pour un total de 64KB de mémoire vidéo ... presque 10 fois moins que sur la DS. Il faudra aussi compter avec un maximum de 34 sprites 8x8 par scanline (or je fais pas mal de recouvrement) mais bon, c'est pas un bullet hell non plus. Lors des tests automatiques, j'ai au plus 70 objets actifs (pas forcément tous visibles) en même temps.

Un autre élément à prendre en compte, c'est que sur la planète PAL, la gravité est 224/192 fois plus forte que sur la planète DS. tout y est donc un peu plus tassé. Ce n'est pas vraiment un problème pour les indigènes, mais Bilou a tendance à se tasser, ce qui nuit à son charisme. J'utiliserais probablement les lignes de pixels transparents (le corps de Bilou fait plutôt 16x13  pixels au sol et 16x14 en chute libre)

Il y a donc 32 lignes inutilisées (en noir sur l'image) que je pourrais exploiter pour insérer un HUD, vu qu'on perd l'écran du bas.

Bref, Piet, si ça t'inspire, il faudrait que la musique tienne en 64K (disons 48K pour les samples, 16 pour les patterns et le player) et n'utilise que 8 pistes au maximum.

Et pour rire, avec une seule palette de 16 couleurs, on arrive à  ... quelque chose de pas complètement moche, mais quand même fort loin de l'original (bon, c'est de la conversion automatique, évidemment).

Par contre, le homebrew sur GBA serait légal dans certains pays où le homebrew NDS est frappé d'interdiction ... ça mérite qu'on y réfléchisse ...

edit : bon, j'ai pas pu m'empêcher de faire un gros montage de plein de screenshots de SchoolRush, de retirer tous les sprites et de faire "conversion en mode indexé" pour voir où on en est (avec les différentes variantes de teintes pour les livres, le sol, etc). Bin ça fait 190 couleurs en tout. Alors que la SuperNES n'en a que 120 à me proposer ... sur GBA, par contre, ça passerait sans soucis.

 edit again: oui, mais une SuperNES, ça sort un signal analogique. Et sur un signal analogique, le dithering passe beaucoup mieux que sur écran LCD. Je peux donc avoir une variante du contenu qui passera pas trop mal (moyennant quelques retouches sur les crayons qui peuvent se passer des petits pixels isolés et prendre une teinte légèrement différente de celle utilisée sur DS ... ce genre de choses).

A suivre, donc, finalement. Mais attention: la SuperNES n'a au mieux que 3 plans et ne pourra pas faire les vagues avec des sprites parce qu'elle n'autorise au mieux que 34 sprites de 8x8 sur une ligne horizontale, l'image en faisant 32 de large.

gource and reDS

C'est un outil super: gource. Transformer les fichiers logs d'un gestionnaire de versions en une animation interactive où les développeurs deviennent des jardiniers taillant, soignant, élagant, greffant...

Et facile à utiliser, en plus! Bon évidemment, ici c'est assez moyennement intéressant puisque je suis tout seul sur le projet depuis le début ...

Mais au moins, ça met bien en valeur les efforts pour restructurer le code et permettre à d'autres (au cas où) de faire des projets à base du moteur de jeu GEDS plus facilement.

Au passage, j'ai franchi un cap avec le code d'AnimEDS. Les "modèles" sont maintenant activés. Je regrette un peu d'avoir quand même dû passer par l'émulateur et une exécution pas à pas pour corriger les bugs introduits lors du refactoring alors que j'avais des programmes de tests pour l'architecture native juste à côté... mais bon, les erreurs étaient dans le setup des objets, pas dans leur logique.

Maintenant, il reste à sortir la gestion des "callback" hors de la classe "Engine" (je les verrais bien en gestion autonome, avec un objet complètement interne qui assure la gestion et qui est caché derrière les méthodes "register" et "unregister" de la classe-maîtresse). edit: c'est fait.

.fr ?

Bon, je ne vais pas y aller par quatre chemins: animer ce blog en bilingue devient trop lourd pour moi. Entre le boulot qui me tient beaucoup plus devant un écran, les trajets en tous ssens pour les activités extra-scolaires des loustics, et -- avouons-le -- un laptop moins convaincant dont l'écran n'a jamais la taille qu'il faudrait, je peine déjà à rédiger ce qui me passe en tête quand je gribouille une page de notes sur ma tablette-liseuse-scanneuse.

Alors le faire en deux langues, ça devient vraiment infernal. C'est aussi au détriment du projet lui-même. En théorie, la France arrive toujours en n°2 dans les statistiques. Ai-je encore des lecteurs francophones ? (ai-je encore des lecteurs tout court ?)

N'hésitez pas à vous faire entendre: le sondage "English /Français" court toujours.