Friday, December 31, 2021

Les jeux de l'année 2021

Allez, on va imiter le frangin et faire un topo sur les jeux de l'année dernière, même si le #1 incontesté du temps d'écran sera celui sur lequel il y a le moins à prendre dans Bilou: j'ai nommé Ring Fit Adventure. Eh oui. Le jeu qui détrôna BotW de mon slot carte switch.


Toki

Je ne pouvais pas ne pas l'essayer dans la mesure où Philippe Dessoly avait essayé d'essayer Bilou. Mais le jeu n'est toujours pas plus facile. C'est même un exemple de vicelarditude de level design des années '90. Mais bon, de temps en temps j'ai vraiment la hargne sur le VPN en fin de journée et dans ce cas-là, Toki est juste le genre de défouloir qu'il faut.

Cybershadow

Un autre qui marche encore bien comme défouloir, mais qui tout en étant hardcore-dur, est rempli d'excellentes idées de game design. Je suis bien content par contre d'avoir suivi son développement parce que j'avance tellement un p'tit coup à la fois que je n'en découvre pas grand-chose par mois. (Et régulièrement, je découvre après coup que j'aurais pu me simplifier la vie en comprenant un truc comme exploser les lasers)

Gris

Indubitablement le jeu-claque de l'année. Mais ça je l'ai déjà dit.

AER

Une sorte de 'wind waker' où on a pas besoin de bateau parce qu'on peut se changer en aigle. Il y a un potentiel énorme, mais malheureusement une gestion de caméra très Nintendo64 qui rend les phases au sol un peu pénibles. Il avait bien tapé dans l'oeil des enfants, cela dit ... enfin jusqu'à ce qu'un certain Link se réveille. Très sensible au joycon drift, ce qui n'aide pas des masses.

Fe

L'environnement à explorer numéro 2. Aussi nominé pour les visuels les plus déconcertants. Plus zen et plus dense en action que BotW qui avait un peu tendance à tourner au "oui, je mets le jeu sur la table, le temps que la météo change un peu". Mais Fe aussi, j'en ai déjà parlé. Deux fois, même.

Celeste

C'est un classique et j'adore sa bande son (enfin, la face A, en tout cas). Terriblement exigeant, par contre. Trop exigeant pour mes mains. Le temps d'être sur le point de passer un écran (vu l'endroit atteint), je frise la tendinite.

 

Whipseey

Au départ je me sentais mal d'avoir ce titre pour seulement quelques Euros. C'est aussi un titre dont j'ai suivi le développement sur Twitter.

C'était avant que je ne l'aie en main. Il faudrait un entrainement pour Megaman pour parvenir à jouer à celui-là. J'arrive à avoir quelques vies en stock au 2eme boss quand je repars du début du jeu, mais ça ne change rien: je me fais applatir.

Hoa

Un autre poême vidéoludique qui fait de son mieux pour donner la réplique à Gris. Bien plus coloré, tout aussi captivant, mais avec un gameplay qui manque de dégrossissage. Trop souvent, ça chipote pour une action aussi simple que sauter sur un bloc qu'on a devant soi. Je suis allé sans grand soucis jusqu'à la fin, mais les enfants on fini par s'en désintéresser avant d'en avoir passé la moitié.

J'adore la manière dont le jeu revisite les canons du jeu de plate-formes comme les plate-formes temporaires, les mobiles, etc. Avec une direction artistique aussi remarquable, j'aurais apprécié des personnages plus grands à l'écran.

Mon seul avertissement à ceux qui sont séduit par les graphismes du jeu ? Il est court. Même Gris est potentiellement plus grand.

Eagle Island: Twisted Mode

Je vous avais déjà présenté Eagle Island. Le "twisted Mode" n'est rien d'autre qu'un nouveau jeu construit (surtout) à partir des mêmes graphismes. Par contre, l'approche a complètement changé. On est pas du tout dans le trip "Super Mario : The Lost Levels". On est plutôt dans ce que ça aurait donné si toutes les idées "ah non, ça c'est pour Zelda" avait quand-même été reprises dans un Mario.
Plus précisément, le jeu de base construit ses niveaux au hasard et attribue des récompenses au hasard. Et il faut reconnaître que Pixelnicks avait été plutôt inspiré sur les variations possible autour de "je lance mon animal de compagnie pour attaquer les monstres". Dans "Twisted Mode", on retrouve certains de ces power-ups les plus originaux combinés à des niveaux construits sur mesure pour maximiser le fun. Exit la récupération progressive des pouvoirs, mais en contrepartie, certains pouvoirs se retrouvent "verrouillés" dans certains niveaux. Le complément parfait à l'aventure originale, quoi.

The Last Campfire

Le petit dernier qui me faisait de l'oeil dans le Switch Store. Un jeu d'exploration avec une petite dimension "ramasser les objets pour les utiliser plus tard" (mais on est loin d'un point-n-click, hein). ça, c'est pour l'ambiance. C'est "l'overworld". Pour réveiller les PNJ inanimés, on aura droit à un niveau-puzzle à faire pâlir Sokoban et Boulder Dash eux-même. Le tout avec des graphismes très soignés.

World of Goo

Lui aussi, je ne l'ai pris que tout dernièrement (un jour sombre ?) quand j'ai finalement découvert que ah bin oui, il est sur switch. Le premier monde s'est avéré aussi amusant que prévu. Je devrais même pouvoir y jouer sur mon vélo d'appartement, tiens.

Unbound (worlds apart)

Un autre dont j'avais suivi (avec un peu plus de distance) le développement et dont j'ai pu essayer la démo. Mais qui ne m'avait pas plus convaincu que ça. Quelque chose dans les contrôles que j'ai trouvés trop raides et les challenges qui demandent trop vite d'enchainer des actions comme un malade fan de super Meat Boy.

De leur côté, les enfants se sont essayés à FeZ, ont repris un peu de Rayman Legends et fini Yono. Kirby: Stars Allied reste une valeur sûre tandis que (comme prévu), Just Dance est tombé dans les limbes de l'oubli...



Dreamland: on fait le point

 La deuxième année de développement de "Bilou Dream Land" tire à sa fin. Il n'y a pas encore de nouvelle maps, mais je pense que les outils sont maintenant prêts à l'emploi.

Ce qui n'était qu'un brouillon avec quelques notes est maintenant une démo exécutable sur DS. Bugguée, certes. Incomplète, tout à fait, mais une démo tout de même. Je me donne l'année 2022 pour continuer d'ajouter des mécaniques de jeu dans ces trois pièces (branches rebondissantes, de l'eau où on nage, des plate-formes mobiles et des écrabouilleurs pour la pyramide, etc). Après 2022, il commencera à être temps de construire les niveaux eux-même avec tout ça, et de réfléchir à la technique pour faire les boss.

Au niveau du contenu du jeu, j'ai un premier projet de niveau dans la pyramide (depuis Aout) -- gardé au secret, évidemment -- et la zone-montagne commence à se dessiner peu à peu. Le "goomba-like" et les "bricks-like" sont venus compléter le bestiaire de la pyramide: je ne devrais plus avoir besoin de rien de ce côté-là. Ce qu'il me faut maintenant, c'est convertir tout ce petit monde en pixels.

Well, why not swapping the years with a flash back on what has been achieved. I almost did it last year. With 2021 closing, it's been 2 full years working on my "Bilou Dreamland" objective. The cornerstone of the year was introducing the "3 rooms" milestone. I'm proud to announce that as of today, that milestone sketched in March is now a demo, of 3 interactive environment packed into one (huge -- 2.7MB) .nds with swapping songs and shared contents for Bilou.

Beyond those got-them-working steps done, I've got most of the monster design for the Pyramid zone covered ... and starting to get idea for the final "Peaks zone". So stay tuned: 2022 will be the year for implementing all those fancy mechanics within the 3 rooms before I start doing full-fledged levels. Maybe I'll even be able to prototype the NPCs.

Il y aura encore eu quelques gros bug-de-murs pendant l'année, mais tout semble indiquer que Bilou supporte convenablement son nouvel environnement, maintenant. En tout cas, on peut essayer les maps de J.L.N sans devoir redémarrer à tout les coins de couloirs.

Euh ... donc en fait ... mise à jour de la Démo.

Edit: J.L.N me rappelle qu'il y aura des boss en plus des 4 mondes. J'imagine que mon prochain milestone (en plus de remplir ces salles de tests), ce sera de faire un proof-of-concept avec au moins un boss. N'importe lequel.


Thursday, December 30, 2021

Color Cycling.

Being able to animate things just by changing entries in the color palette is one of the reasons why I'm loving old school programming that much. The amount of pixels you can affect with this technique with just a few memory writes has so much hex appeal! Yet, you wouldn't find anything animated that way in Apple Assault or in School Rush. Flowing ink could have used some, though.

Technically speaking, one key thing to fix to get it working with my setup is to ensure that the palette writes happen in a Vertical blank handler, and the other is that we bring the video memory holding the colors as freely-accessible video memory ( aka LCD for the Nintendo DS) while updating it, and then return it as extended palette bank.

So with all that coded, I could replace the lengthy 16-frames animation of the waterfall with just one static frame. And I have a comfortable homework to create as many tiles of flowing-wafer-slopes as I could need. I used a sort of "rainbow raster" to be able to draw those animations properly, which makes them look a bit strange in the level editor and in runMe, but I should be able to fix that by having the raster be on a secondary palette shot and a "static preview" on the main (and animated) slot.

Yeah, that's the major drawback: I don't see how to get it customizable from the level scripts by now, so I prefer keep it as some custom code running in Dreams.nds and leave runMe alone for now.

Là, je m'attaque à un morceau iconique du développement 16-bit: l'animation des palettes. Un truc que je connais depuis le BASIC mais que je n'ai encore jamais eu l'occasion de pratiquer sur DS (c'est dire si les petites animations sont à la traîne dans mes jeux DS :-P. Le principe ? les graphismes en mémoire vidéo ne contiennent pas directement des couleurs, mais des références à ces couleurs. Les pieds de Bilou seront faits avec la couleur n° 24 alors que sa main aura la couleur n° 79 et le blanc de ses yeux la couleur n°3, etc. Une partie de la mémoire vidéo est dédiée à retenir la correspondance entre ces numéros et les couleurs RGB à utiliser: c'est ce qu'on appelle la palette. Du coup, si vous changez une de ces valeurs, vous avez la possibilité de modifier simultanément une grande quantité de pixels à l'écran.

Une sous-catégorie de ces animations concernent les boucles de palettes. Vous n'ajoutez aucune nouvelle couleur, vous n'en retirez aucune non plus, vous vous contentez de les changer de place. du coup, un dégradé bien construit peut devenir un tapis roulant, une chandelle vacillante, une mare de lave ou une jolie cascade. (Mark Ferarri étant le champion de la discipline, cf. ci-contre).
 
If you look closely at the blue ramp between the two rightmost waterfalls on the gif above, you'll note that palette cycling is working there (backwards, but working). The waterfalls are still 'frozen' because I haven't applied my palette effect on the background layer yet. Oh, and if you wonder why half of the background is pink on those green zone captures, greenbg.spr is 32x32 and CommonMap expects a 64x32 map instead ... so half of it is 'blank'.

Mais pour que le chip graphique puisse pomper les valeurs de la palette assez vite pour tenir le rythme de l'écran, on doit régulièrement caser la palette dans une mémoire dédiée, avec un protocole d'accès un peu plus compliqué que BG_PALETTE[index] = rgbValue; C'était le cas avec le VGA, c'était le cas avec la SNES, c'est toujours le cas avec la Nintendo DS (plus simple à coder, mais pas forcément à expliquer).

Bref, ça marche, mais vu que ça ne peut se produire que pendant le 'temps mort' entre deux rafraîchissements d'écran, et vu qu'il y a cette histoire de va-et-vient entre la configuration où on sait écrire dans la palette (mode LCD) et celle où on sait l'utiliser pour afficher les couleurs (mode EXTENDED_PALETTE), je vais juste garder ça comme un 'petit extra' de Dreams.nds et vous aurez le fond des cascades statiques quand je ferai une démo IRL avec runMe. Vendu ?

Tuesday, December 28, 2021

Libérer l'eau

Dans le niveau dessiné par mon frère il y a longtemps, on a une clé "à attraper au premier passage" et une porte verrouillée dans untrou. Dernièrement, j'ai décidé de laisser tomber mes idées de faire pousser un haricot magique pour quelque-chose de plus direct.

Comme j'envisage déjà d'avoir un niveau d'eau qui monte ou qui descend dans un autre niveau de la green zone, j'aimerais bien pouvoir résoudre le problème en faisant monter l'eau assez pour que la clé devienne accessible.

I have some design to fix if I want to reuse my brother's Green Zone Level 1 in DreamLand. Whatever the revision, the map can get you locked in a pit with a door that needs a key that is higher than the pit. Originally, we were meant to dive in and find a sunken door that brings back at the surface where we can try to catch the key on a second fall.

That would have worked because Bilou was supposed to swim freely in that game, but only for some limited time (the Blue Power would then allow to extend that with magic collectibles). But in Dreamland, we should instead expect water to push the player up, forcing them to float rather than to swim anywhere.

Evidemment, il faudra que le niveau redescende automatiquement après, parce que tout comme dans Fury of the Furries, j'envisage que Bilou ne puisse pas plonger librement dans l'eau pour ce jeu-ci, mais flotte obligatoirement.

Il restait à trouver un moyen de faire venir l'eau d'une manière qui colle à la fois aux mécanismes de Bilou et à l'environnement 'green zone'; un peu comme l'histoire de la vanne à encre déjà discutée l'an dernier.

In an earlier revision, I had thought of introducing a sort of 'fast-growing vine' that the player could trigger, but I'm not that fan of using such an indirect mechanics like 'water-the-bean' or 'make sure the bean is no longer drowning'. If I'm to play with water, I'd rather let the water rise high enough so we could reach the missed key. Sounds like a nice, more direct, way to do things. All I was still needing was a way to trigger that water rise that would integrate nicely with Bilou's world. I may have found something working based on push-me blocks. phew.

Prince of Persia

J'avoue que quand j'ai vu "le making of de Prince of Persia" chez Third Editions juste avant Noël (dernier), je me suis dit que je n'avais pas besoin de chercher plus loin un cadeau pour mon frangin. Il m'avait avoué avoir aussi commandé quelque-chose pour moi chez eux, donc j'étais convaincu qu'on allait s'échanger le même bouquin au pied du sapin. Tellement convaincu que j'ai laissé le sien bien au chaud dans son emballage, histoire de ne pas gâcher le plaisir de la lecture *du mien*.

Sauf que non. J'ai eu quelque-chose d'autre. Et la lecture du making of aura attendu encore et encore, le livre continuant d'être sur la table de chevet de mon frère. Jusqu'à ce Noël ou j'ai réussi à le convaincre (nouvelles  BD à l'appui), qu'il parviendrait bien à s'en passer une semaine ou deux.

- - - -

Deux ans après avoir numérisé les premières séquences vidéo où son frère court et saute, Jordan Merchner prend conscience qu'il manque quelque chose de fondamental dans son prototype de Prince of Persia: des objectifs.

La princesse à la fin du jeu n'est qu'un trophée. Il faut des récompenses dans le jeu comme battre un garde dans Karateka, attrapper une pac-gomme dans Pac Man ou compléter un niveau dans Lode Runner.

A ce moment-là, son jeu autorise l'exploration libre de grands niveaux (plus d'une 20aine d'écrans). Il n'y a pas encore de combats. Il n'y a pas moyen d'anticiper à quelle distance on est encore de la sortie du prochain niveau. Si on tombe dessus, on se dit "ah ok ? c'est la sortie, alors". Pour qu'il puisse y avoir sentiment de récompense, il faut que le joueur ait pu anticiper qu'il avait quelque-chose à réussir.

On peut se retenir pour la tâche suivante, attendre le bon moment avant de se dire "Ok. Maintenant!" et se plonger dans une période de tension plus forte, avec une grande chance d'avoir un contretemps ou un succès. Prince of Persia n'a rien de tout celà pour le moment (12/11/1988). Si le sous-objectif est de finir le niveau, il faut un indicateur visuel de où on en est.

Il faudra que je sois attentif à ce genre de chose dans Bilou. La bonne nouvelle, c'est que les bonus-à-ramasser donnent facilement des petits objectifs intermédiaires. Il se pourrait que ce qui ne m'a pas plus dans les collect-a-thons, c'est justement cet absence d'objectif (ou alors un objectif caché, du style "bon, il reste 8 Lums dans ce niveau. génial. Où est-ce qu'on achète une boussole à Lums ?)

edit: okay. Bouquin fini. Bonne histoire, bonne lecture, mais il faut reconnaître un truc: Jordan ne s'est pas particulièrement étendu sur les aspects techniques du développement. Pas beaucoup plus sur les niveaux eux-même. Ce n'est pas si étonnant. Quand il bosse, il bosse. Il ne prend pas des notes sur "pourquoi on met une potion l et pas ici". Il prend des notes quand il rumine. Et pour tout ce qui est 'bon comment on va faire ça sur 8-bit', voyez plutôt le portage C64. (par contre, le code source est publiée sur github)

On y retrouve les schémas expliquant comment les graphismes sont découpés dans le bouquin, et deux ou trois autres trucs du genre, mais on ne s'y attarde pas. Pas de regrets, donc: c'est un bouquin taillé pour CJ et PYH plus que pour moi.

Bon, Jordan, si tu me lis un jour, je n'ai jamais vu PoP en magasin. J'y ai un peu joué en version MS-DOS, mais je n'ai jamais réussi à passer le 3eme ou le 4eme niveau. Mais t'as fait un super travail quand-même. Ton jeu reste un mètre étalon de la discipline. Et merci d'avoir publié tes carnets.

Saturday, December 25, 2021

xmas21.zip

I finally posted something more on my sourceforge project: the set of editors (plus runme) as I've got them by this Christmas, invoking oven-hot slopes support.

I wish I could provide you with a meaningful 'change log' for this 'release' of my tools, but let's be

honest: there are over 20000 lines changed between then and now (assuming that you're only interested in what changed since last AnimEDS release in 2020). It won't be exhaustive, but I'll try to give you an idea of what's in anyway.

Sprite Editor

  • allows you to work on any file you've got on your memory card (including automatic backups put in /DATA/SEDS/*)
  • better 'colors zapping' implementation.
  • 'where is that color used?' now cleanly implemented in the PaletteWindow
  • (improved host tools sprdo and sprck are missing from this pack)

Animation Editor

  • allows you to work on any file you've got on your memory card. 

Level Editor

  • uses new map layout with dedicated PHYS layer (accidentally named 'SYHP' in the file >_>)
  • show the 8 color palettes when selecting a block in DRAW mode (A). Color paint mode now available on both foreground and background layers (trigger with L+A on the desired layer)
  • supports new any-sized special blocks with 'lookup arrows', features revised 'meta buttons' widget to select tile properties.
  • reads new 'slopes %d = "%x"' hint in .cmd or .gam files and populates the slope tiles graphics accordingly. Different maps can use different slopes or share them by importing the same .gam file.
  • supports spritesets and tilesets overlay commands

runMe (gameplay preview & WiFi transport)

  • Allows live-skipping of buggy script lines
  • allows auto-repair of the /moving/ directory
  • features new level map engine
  • supports script-driven song swapping with zik.file = "%s"
  • Improved modplayer playback speed stability
  • supports spriteset overlays (spr.more "%s" ...) and tileset overlays (bg0.more "%s" ...)

All these .nds files will work from anywhere in your flash card, but if you install them with their original *dlta.nds filenames at the root, you'll be allowed to hope from one tool to another with the embedded buttons (quit, LEDS, SEDS, MEDS) in the application welcome windows.

Saturday, December 18, 2021

Ludricous Speed

 There's another bug with my modified version of libntxm. It has been around since at least early School Rush prototypes and possibly even Apple Assault. If you let the player spin for too long, it suddenly starts to play things at ridiculous speed that makes the song barely recognizable.

I had the Dreams demo running with ARM7 debugger plugged in for another reason (undefined instruction) and it started speeding the song up so I dropped all my kitchen stuff and jumped on the CTRL+C to be able to dig that later. And later is now.

One symptom of the issue seems to be that the tick_ms variable is now way larger than the MsPerTick() property of the Song.

Every time the playTimeHandler() is invoked, it recomputes how many milliseconds elapsed since last call, and here I get the value of 1. It won't get out of the issue because there's nowhere we could read tick_ms = 0. Instead, the amount of time expected is substracted from the time elapsed so far, so that 'extra milliseconds' are deduced from the next 'tick'.But watching that tick_ms evolve, it is properly decreasing. It has not just been gone wild. It got corrupted from something else.

It doesn't tell me what goes wrong in the soft, unfortunately, but at least, it gives me a way to make sure players won't experience it. If I cap the tick_ms to 2*MsPerTick(), I shouldn't have issues.

Note how buggy tick_ms is close to last_ms ...

Note how unlikely it is that the player has been running for 43509 seconds. I wasn't even running it for one hour! And when it eventually occured again, lastms was 43494543, or something alike (decimal, not hexa).

Seeing some more code featuring 'compute over 100' now makes much more sense. 100 times higher than 43 million, we're quite at MAXINT for an unsigned. Plus, if you've got an unsigned, comparing -t to something might very well produce something that is compiler-dependent. Likely, there might be a switch to produce a warning for that.

Il y a un truc qui me chagrinait, avec School Rush: au bout d'un certain temps la musique partait en vrille. Le problème se posait uniquement au bout d'un temps assez long, du coup, je n'avais jamais eu l'occasion de prendre le temps de chercher le problème. Mais hier, j'avais un débuggeur ARM7 prêt à fonctionner, un émulateur branché dessus avec le code qui 'là-normalement-ça-devrait-marcher' pour un autre soucis et j'étais en cuisine ... donc ils ont tourné pendant longtemps sans intervention ... assez longtemps pour que le problème de School Rush se produise. J'ai bondi sur mon ordi pour interrompre tout ça et débugguer enfin cette histoire.

Au premier tour, tout ce que j'ai pu dire c'est que "bin c'est parce que tout d'un coup, on découvre qu'on est en retard de plus de 40 millions de microsecondes pour passer au 'tic' de musique suivant". J'avais espéré qu'il s'agissait d'une déviation ou quelque-chose de ce genre, j'avais mis quelques 'break if...' dans ddd mais quand le problème s'était finalement re-reproduit (bonne journée, ça), on était passé de quelques millisecondes de retard à plus de 43 millions, comme ça, sans-transition-à-vous-les-studios. J'en venais à me dire que 'tant pis, je vais juste mettre un patch qui limite artificiellement ce délai' puis je tombe sur l'implémentation de la lecture du temps à partir du hardware qui cache une division par 100 ... et 100 * 43 million, on approche du plus grand entier 32 bits. Là, ça pue le bug de conversions arithmétique dû à une soustraction mal calibrée... ça je pourrai corriger pour de bon.

Thursday, December 16, 2021

Peaks'n'Beaks

Pour l'instant, je reste sur l'idée que la zone "des cimes" (montagnardes) ferait une bonne zone finale pour "Bilou Dreamland". Mais c'est pas tout d'avoir une idée de zone: il faut encore la peupler. Attendez-vous à avoir quelques bestioles inspirées de boucs, mais aussi de piafs plus ou moins agressifs.

Il faut encore que je trouve le moyen de le dessiner en train de voler, par contre.

Pour ce qui est du look des niveaux, j'ai été un moment tenté de m'inspirer du niveau de Meta Knight dans Kirby Stars Allied, mais à la réflexion, je le trouve trop cahotique.

Enfin, est-ce que je peux faire un niveau des montagnes sans jouer la carte de la caverne-dans-la-montagne ? On est pas franchement dans le thème du 'à-fond-platforming' pressenti, c'est vrai. Mais à force de visiter des grottes, ça devient de plus en plus tentant. D'autant qu'il suffit de couper un chou pour avoir un level design de grotte ^_^

Tuesday, December 14, 2021

PlaySFX vs. PlayInst

 

Je refais un peu d'explication-BD parce que là, c'est un brin compliqué. Le mécanisme que j'avais ajouté pour faire des effets-par-pattern, je l'ai poussé un peu trop loin.

Au départ, c'était bien vu: un ensemble de flags permettant de dire si on doit suivre la "partition" normale du module ou continuer à avancer dans la piste en cours jusqu'à trouver un effet 'pattern break'. Mais il y a un cas que je n'avais pas en tête à ce moment-là: les effets 'normaux' fait d'un p'tit sample tout seul. Eh oui.

Dans ce cas-là, la piste sur laquelle on met le sample n'a normalement pas de contenu. Depuis le nouveau code, elle est ignorée puisqu'au-dessus du nombre de pistes définies dans le fichier .xm. La seule exception à cette règle, c'est pour les pistes qu'on a attachées à un morceau de piste d'effet.

Disclaimer first: many of the things I'm now doing with libntxm are far beyond what it was designed to do, that is running a soundtracker on the NDS. When thigns go wild because I stop a song and replace it with another before the Player class on the ARM7 get any chance to run its every-millisecond handler routine, I'm worse than a TAS-speedrunner producing superhuman inputs on the software. Right ? Same when I feed the Player with two patterns simultaneously and going 'yeah, play pattern 9 on channels 1-12 while at the same time playing pattern 27 on channels 14-16, will you ?'. None of this was part of the original plan, and that's perfectly natural. It's up to me to make it work if I want it to work.

Ça, ça marche bien pour le moment 'lecture de la nouvelle cellule (note) dans la ligne'. Mais si on veut qu'un p'tit son puisse être joué, il faut qu'on continue à faire des calculs d'enveloppe, la gestion des registres de volume. C'était déjà un peu à ça que servait le flag channel_active. Il reprend du service.

Bon, là je me suis limité à un p'tit test tout bas, parce que ma fée est pas ultra-fan de StrTrk et que c'est l'heure de la p'tite série qu'elle aime bien à la télé.

So a few weeks ago, I fixed a crash in the ARM7 code with 'oh, I know: I'll give NTXM player a NULL song first, and then delete-and-create another one'. Not a bad idea in itself, but I missed a few things that the player has to do even when I change the song, like progressively muting the channels when there are no more notes to do. Obviously, I shouldn't prevent it from doing so even though we activated the NULL song.

I also finally implemented an if-block for the GobScript (it turned out quite simple thing to do) and tried to use that so that we'd use pattern-effects only when playing a tune with such patterns, and play plain-samples-effects otherwise. Nice try, but it turned out that no sample was playing at all. That was because of my previous changes again: when playing such lone samples, we're perfectly right to do so on channels that are not present in the song. (Actually, we should better do so). But the code from SchoolRush would only start playing a sample if there was a pattern Cell to back it up. Either a regular one, or one from a pattern-effect. I had to identify the tasks where that test was mandatory (e.g. when processing effects or advancing to the next row) and tasks where it shouldn't be used (process volume envelopes, start the sample, turn down the volume when done playing the sample, etc.)

Reste à espérer qu'avec les corrections de 'quelle musique jouer quand' et 'okay, on a plus de partitions, mais continue quand-même à baisser le volume', ça suffise pour que les musiques de la prochaine démo soit un peu plus sous contrôle.

Ah oui. Et au cas où, ces choses en forme de tentacules (Bob) sont des statues-registres.

And after all ... here's my waterfall

After almost 3 weeks of quarantine, I knew I was going to see my brother again. He stated the new 'release' looked fine, and I wanted him to see the animated version I had in mind. So I did my best to get that done by the end of the week, although this is hardly of any emergency in the not-yet-written list of things to fix in that build. I mean, yeah, the water is more convincing if the falls flow, but we can walk on it anyway, so ...

Premier changement par rapport à la démo téléchargeable: animer la cascade. Ouais, je sais c'est clairement pas le truc le plus prioritaire, mais c'est un projet-hobby, donc la priorité, ça doit rester de se faire plaisir. En plus, je tenais un créneau pour montrer ça à mon frangin, alors autant lui en mettre carrément plein la vue, non ?

I wanted the waterfall not to look like a simple scrolled tile, so instead I scrolled two layers independently, at different speeds. Yeah, I know this is quite cheap. Well, I also gave 'noise' variations in the frames of the fore layer and I intend to add 'wavy' animation to the back layer. That produced something I'm proud of, even though it's far from being perfect. It also has the bonus advantage that I can make characters looks 'in the water' by being between the two layers ^_^.

Comment éviter que la cascade n'ait l'air d'un tapis roulant bleu ? Ma p'tite idée était de jouer sur deux plan, avec deux vitesses de scrolling différentes et deux niveaux de détails différents. à l'avant, c'est "haute fréquence" et vitesse de chute élevée. A l'arrière, "basse fréquence" de détails et vitesse faible. Mais un cycle de 16 pixels pour la face avant, c'était trop court par rapport à l'effet désiré.Qu'à celà ne tienne: il me faut de toutes façons aussi un "pied de chute" où l'eau mousse. Si je garde la mousse sur le demi-bloc du bas, je peux utiliser le demi-bloc du haut pour avoir un cycle de 24 pixels de haut et un pied de 8 sans que le moteur d'animation par blocs de 16x16 n'y trouve à redire.

Les bords, eux, n'existent que dans la face arrière, y compris le dessus de la cascade. ça me fait 45 kB/s à streamer entre la RAM et la VRAM, et la NDS donne l'impression de parfaitement tenir le coup. Pourtant, il se pourrait que j'introduise malgré tout du palette cycling pour la "couche de fond". Bin oui, la je n'ai que de l'eau qui tombe, mais je veux aussi de l'eau qui coule au sol et qui entraîne Bilou avec elle. Et pour la faire couler malgré un dénivelé doux, je vais soit devoir sortir des sprites, soit multiplier le nombre de blocs animés au-delà du raisonnable.

There's a catch remaining though. I have plans for flowing water *on the ground* too, including on sloped ground. With the current setup, I have used 6 animated tiles with 12 to 16 frames each. If I ever try to expand that to ground tiles, I'll quickly blow up my DS resources before I'm half-done with the game I intend to make. I might have to animate all but the foreground layer using palette cycling instead.

Wednesday, December 08, 2021

3 Rooms - Release Early

 

There we are. The first demo featuring the first 3 environments of Bilou's Dreamland cycling to one another, changing music and graphics. It's super work-in-progresss, and there are so many things to be fixed that I won't try list them now. But you know what they say: "release early, release often", and a fellow gamedever asked me earlier this week about being allowed to test and so on. So if you think he's right, enjoy this St-Nicolas gift.

Download: Dreams.nds updated Dreams.nds for new year

Voici donc (enfin ?) quelque-chose de téléchargeable avec les environnements que j'ai l'intention de faire évoluer pour y amener toutes les nouveautés de gameplay de Bilou's Dreamland. Alors, soyez avertis quand-même: c'est vraiment une version 0.0.0.1 là. Pas même une ébauche, tout juste un canevas. Y'a des retouches à faire par-tout. Y'en a tellement que je n'aurais même pas le temps d'en dresser la liste avant d'aller me coucher. Mais qui sait, ça vous amusera peut-être.

/Fe

Voilà, malgré une caméra capricieuse et un joycon rouge qui garde une légère tendance au drift malgré l'entretien à l'alcool, j'ai fini le jeu de Zoinks: Fe. Après un enchaînement de challenge assez satisfaisant en matière de puzzle final, entrecoupé de révélations inattendue et dans un décor impressionnant. On ne pouvait pas vraiment s'attendre à un boss final qui tire de partout, évidemment. Ça aurait complètement cassé l'atmosphère du jeu.

Cette atmosphère (et le rythme qui va avec), c'était pile ce qu'il me fallait pour me délasser. Il est fairy-friendly, en plus, avec ses visuels zen et sa musique aux antipodes du chiptune. Bref quand ma fée est plongée dans ses lectures, c'est un bon choix pour la soirée.

Pendant tout le jeu, on est invité à essayer de comprendre ce qui s'est passé, que ce soit en visionnant les mémoires des adversaires mécaniques ou en réveillant des dessins témoins du passé. Les différentes races intervenant dans le jeu y sont représentées schématiquement, ce qui marche plutôt bien sur le début. Mais j'avoue que ça n'a pas suffit pour que je comprenne l'histoire que ces stelles essaient de raconter. ça reste plus intéressant comme manière de procéder que les textes effacés de zelda: breath of the wild.

Et maintenant ? A quoi on joue ? Ah bin il y a une promo sur 'World of Goo' qui était sur ma wishlist depuis 11 ans une éteeeeernité. Allons-y.


Monday, December 06, 2021

greent.map

Se pourrait-il que j'arrive malgré tout à avoir une démo "3 rooms" pour la fin de l'année. Enfin un premier jet. Le hic n° 1, jusque là, c'était la quasi-impossibilité de faire une nouvelle map propre. Depuis l'introduction de la branche newmap, l'éditeur de niveau ne savait plus le faire, mais j'ai fini par trouver ce qui n'allait pas

Maybe I'll have a 3-rooms demo by the end of the year ? Not with all the features working, of course. Expect static waterfalls and incomplete water physics, but at least a .nds where you could travel freely between the 3 environments I have so far. Until yesterday, that was hindered by a bug in the level editor that prevented me from creating new maps: I could only update existing ones. But that bug is now solved, so I started tiling 'greent.map' and 'schoolt.map' as I intended them to look like in my notepad.

Du coup j'en ai profité pour redessiner en 512x256 les niveaux-démos prévus, rajouter les palettes de couleurs que j'avais essayées pour les cascades. Il n'y a pas encore d'animations ni de physique de l'eau ... ce qui donne un résultat un peu perturbant (mais pratique pour aller voir ce qu'il y a d'autre sur le 2eme écran). Ouaip. c'est l'avantage de la Saint-Nicolas en quarantaine quand les enfants ont assez grandi. J'ai eu l'occasion de m'asseoir avec ma DS à côté d'un Gimp.

Then I went ahead, taking advantage of the 'woot-we-have-new-toys' while we're all locked-home by quarantine to open my earlier waterfall mock up and redraw that into SEDS.

I hope I'll be able to do the same with pyrat.map soon.

Thursday, December 02, 2021

The true Mario Jump

J'ai un vieux post, le premier qui raconte comment on peut faire sauter un personnage dans un jeu vidéo. Dedans, il y a une image où j'explique que la physique de SMB3 est un peu 'truquée' du côté des sauts. Mais bon, j'avais fait ça à la grosse loupe sur une vidéo youtube, alors que l'ami Upsilandre, lui, a du lourd sur le sujet: il a analysé en détail les mouvements de Mario et ceux de TinyToons Adventure pour voir s'il y avait eu des fuites de code source entre les deux jeux.

When I was writing one of my first post about having a character jump in a tile-based game, I had the surprise to see that Super Mario bros. 3 doesn't seem to use Newtonian gravity. Instead of having a smooth parabolic curve, there seems to be linear rise, parabolic climax and linear fall in a Mario jump. But I did that just by checking a let-s-play video on youtube. On his French blog, Upsilandre did a detailed comparison of SMB3 and Tiny Toons Adventure where he gathered all the impulse and gravity constants, so why not pay him a visit ?

Il pointe notamment une correspondance exacte pour les impulsions de saut. au centième de pixel par frame près. Troublant ? Eh bin, rappelons-nous: quelques paragraphes plus haut, il relevait aussi que les deux jeux utilisent le même format de nombre pour les vitesses: 4,4 bit

La vitesse dans Tiny Toon est encodée exactement dans le même format à virgule fixe 4b.4b que je n'ai vu que dans SMB3 (même pas dans SMB1), en général c’est plutôt du 8b.8b (voir du 3b.5b). [...] La même force de gravité faible de 0.06 tant qu’on maintient le bouton saut (comme si on était sur la Lune) et une force de gravité forte de 0.31 (retour sur Terre) quand on lâche le bouton ou que la vitesse verticale passe en dessous des 2 pixels par frame (donc quand on approche du sommet du saut). [...] [on va retrouver] strictement les mêmes 5 valeurs d’impulsion à la décimal prêt (respectivement 3.44, 3.56, 3.69, 3.94 et 4.00 ppf). La seule chose qui diffère c’est la valeur qui sert à caper la vitesse max de chute qui, comme pour la glissade en pente, est plus basse dans TTA.

Petite précision: cette histiore de 4,4 (ou 4b.4b selon la formulation d'Upsilandre) signifie que toute vitesse est exprimée en un nombre entier de 16 de pixel/frame. et on peut aller de -16 à +16 pixels par frame (mais personne n'ira jusque là). Du coup, 0.44 c'est 7/16, 0.56=9/16, 0.69=11/16 et 0.94=15/16. Déjà beaucoup moins surprenant. Notons au passage que la gravité lunaire de 0.06 pixels/frame² correspond à une simple décrémentation de la vitesse en 4,4bit. C'est 1/16eme. Tout simplement. Sur un processeur tel que le 6502, si on peut décrémenter plutôt que de soustraire 2, c'est toujours ça de pris.

The most interesting part is that the game uses two different gravity values. the 'ramp up' part of the jump uses the lowest possible gravity the game can deal with, of 1/16th pixel per frame². The switch to another gravity happens when we reach a vertical speed of 2 pixels/frame (or if the button is released), and we then go for 5ppf².

The impulse value may seem surprising, especially when expressed as decimal values like 3.69ppf. In fact, they integrate to nicely integer jump height expressed in Super Mario Blocks. What it means is that any game that wants to use the same gravity as SMB3 and a map made of 16-pixels blocks is likely to need the same impulse values as well.

Mais pourquoi ces valeurs-là ?
C'est le moment de ressortir un autre vieux post où on reverse-designait Super Mario World. Le game design forum y pointait que tout se mesure en bloc, dans le monde de Mario. Y compris la hauteur et la longueur des sauts. je ne serais pas surpris de découvrir que les impulsions correspondent aux vitesses qui permettent de franchir un obstacle de 3, 4, 5 ou 6 blocs le plus justement possible. Mais on a les valeurs, donc vérifions!

Voilà donc: selon l'impulsion initiale (v0), la hauteur atteinte (y2) au moment où la vitesse vaut 2 (et où on applique une gravité "normale" proche de 5/16 ou 6/16 ppf²). Avec en prime le temps mis pour y parvenir. Les valeurs 'magiques' correspondent à un obstacle de 4, 4.5, 5 et 6 blocs respectivement.

During the fall down, the game physics makes the terminal velocity kicks in very soon. As soon as 2 blocks high, actually. It may be an important part of consistent air control, giving you equal chance to hit RIGHT and reach a platform regardless of how long you've been falling down. The quasi-linear ramp up with super-small gravity does its best to mimic that for gameplay symmetry and ensures that we don't need speeds near 1 tile/frame if we want to jump up to 6 blocks high, as 1 tile/frame is almost warp speed for a 8-bit game engine.

ça, c'est pour la montée en gravité lunaire. Avec une gravité de 5/16, il faudra 22 frames pour tomber de 65 pixels de haut, mais 2 frames plus tard, on aurait déjà franchi 80 pixels. Enfin, ce serait en supposant que les programmeurs de SMB3 n'aient pas mis une 'terminal velocity' pour la chute libre en-dessous de 6ppf². En réalité, comme le fait remarquer Upsilandre, la vitesse de chute est limitée à 4+5/16 ppf par la "friction dans l'air". La mini-gravité en début de saut est essentiellement là parce que le gameplay veut une hauteur qui ne devrait pouvoir être atteinte qu'avec une vitesse de chute supérieure à cette vitesse terminale. Sans ça, il faudrait une impulsion de plus de 7+8/16 ppf pour dépasser 6 blocs de hauteur. On s'approche dangereusement de la limite de 1 tile / frame à partir duquel le code de détection de collision avec le niveau doit être radicalement modifié.

Au final, 

  • la descente de Mario est principalement linéaire. Il n'y a accélération que pendant les 2 premiers blocs (1 mario) de hauteur.
  • la montée de Mario n'est pas strictement linéaire, mais la gravité est si faible que la différence est à peine perceptible. Elle va surtout agir comme un compteur intégré de frames de montée forte avant de passer à la phase 'sommet du saut'
  • le changement de gravité au moment de relâcher le bouton offre une alternative sympa à ma solution de "forcer la vitesse de saut à -2 si on relâche le bouton [et que...]" 

edit: j'en profite pour sortir d'un vieux draft un autre schéma 8-bit d'upsilandre: la comparaison des courbes d'accélération de différents personnages.

edit+: en comparaison, Gomez ne sait sauter que par-dessus un obstacle de 2 blocs de haut mais peut s'accrocher à un rebord à 3 blocs de hauteur. Plus approprié pour un jeu de puzzle comme FEZ.

Tuesday, November 30, 2021

bg0.more vs. spr.more

 Bin ç'a été un drôle de week-end. Avec la p'tite famille en attente de résultats des tests covid et moi qui savais déjà que j'étais négatif ... enfin, le point positif dans tout ça, c'est que j'ai pu (dû?) me poser et clarifier sur papier ce qui n'allait pas avec ma gestion des 'overlays de spriteset' (si, vous savez bien: la superposition de deux fichier dans la mémoire vidéo de la console).


Reprenons. J'avais remarqué que mes écrans bleus étaient liés à des pages incohérentes, et ça m'avait conduit à constater que ni l'indexage page-dans-le-fichier ni bloc-dans-une-page ne contrôlait que je restais dans des objets définis. En clair, si je prends la 12eme page sur un fichier qui en fait 10, bin il y a des chances que ça se termine mal.

J'ai donc rajouté du code pour détecter et rapporter les erreurs (ces petits yeux gluants sur mon dessin de l'autre jour) si bien que le niveau de l'école ne chargeait plus. En cause, l'animation de ce smiley bleu qui sert de renfort d'énergie à Bilou et qui est un peu un extraterrestre dans le jeu. Tout comme les livres, les fardes et les lettres-bonus, il s'agit d'un élément de la map du niveau. Un simple bloc animé. En revanche, son animation fait partie du fichier bilou.spr, histoire que je puisse le réutiliser dans les autres zones à l'identique.

Sauf que jusque là, si je chargeais bien un 2eme fichier .spr par-dessus bilou.spr dans la mémoire des sprites (malgré les complications pour l'animation), du côté des blocs, c'était school.spr et rien que school.spr. Et le code qui demandait de créer un BlockAnim à partir de la page spr:6 ne pouvait pas fonctionner, vu que quand on charge un .spr en tant que "sprites", tous les autres types de pages (blocs et anims) sont ignorés. Une ruse pour éviter de charger deux fois les animations en mémoire.

Bien. On va charger les blocs de bilou.spr dans la mémoire des blocs. Mais on les mets où ? Si je les rajoute par-derrière school.spr (ou green.spr, ou desert.spr), les nouvelles pages d'animations auront un numéro différent dans chaque zone (galère pour écrire les scripts). Si je les mets par-devant, toutes mes maps sont bonnes à jeter. Et si je les corrige, je pourrai recommencer chaque fois que j'ajouterai ou retirerai un bloc de bilou.spr >_<

Alors me voici occupé à ajouter le support pour 'bg0:-1' qu'il faudra comprendre comme 'la dernière page du SpriteSet des blocs'.


Friday, November 26, 2021

Three tunes

Having three different visual environment for Bilou's Dreamland's first demo is one thing. I'd like to given them distinct musical background, too. That was last week-end's target, but unfortunately, it hasn't been very satisfying.

Sure, I could get 'school rush' theme played while being in the school room, and 'Apple Assault' theme while being in the green room (sic), but the loading time between them became quite excessive. Even if I expect this to happen only at 3 different time in the game, being completely silent and blank then is a no-go.

The second issue is with sound effects. Apple Assault used simple samples to play sound effects for e.g. jumps, stuns and the like. School Rush instead had mini-patterns with 3-4 tracks to produce the desired arpeggios and effects from ultra-basic sound palette. Of course the green zone tune did not featured any of this.


 The third and final(?) issue is an endless loop within the memory manager. Most likely, something's wrong within libNTXM memory management (or in my messed' up clone of it) which never showed up since I was playing the same module over the whole game's lifetime in previous installments.

Eh bin ... ça en a fait, des choses à fixer pour pouvoir passer d'une musique à l'autre au sein d'un même programme basé sur GEDS. Entre les makefiles, la bibliothèque NTXM elle-même, les p'tits soucis de parser et les modifications à apporter aux scripts, heureusement que TortoiseHg était là pour déméler tout ça au moment de faire enfin des commits.

C'est encore hautement perfectible, notamment au niveau des temps de chargements, mais si je veux avoir une première version jouable de Dreamland d'ici la fin des primaires de J.L.N., il va falloir que je me concentre d'abord sur le reste.

So I've been trying to see where I could have poorly managed memory ... something that would explain how the loop appeared, but given how shielded the memory management code already was in libntxm, I started doubting of my own deductions.

Then the emulator suddenly decided to give me addresses and register dumps! Huzzah!... but they were all for the ARM7 core.

It turned out that, no matter whether you invoked NTXM9->stop(), the timer interrupt keeps running and it keeps checking for the NTXM7->song pointer and dereference it. Simply, all channels are turned to mute, or something alike when you've stopped the playback on the ARM7. Note that background color for the top screen turns to weird orange when this occurs.

And of course, the ARM9 code would delete() that song before it sends the 'set song' command to the ARM7, meaning that the ARM7 core would start using recycled content to guide how it should work (including objects and VPTRs!) ... Pretty weird to see shared virtual tables between the two co-processor of a console, btw. Don't try to do that with the M68000/Z80 duo of Megadrive development.

  • step one: fix the .cmd so they use SFX that suit with the loaded level
  • step two: find a way to share revamped SFX through levels
  • step three: find a way to hide music loading latencies.

Don't start addressing step three before you get the 'three rooms' demo running and you're ready to encode levels.

Tuesday, November 23, 2021

Super Bilou 2

 Supposons qu'il soit possible de changer la manière dont SchoolRush affiche son encre qui monte,
histoire de laisser les 3 plans de background disponibles sur Super NES tranquilles.
On pourrait alors s'en sortir avec moins de 1024 tiles pour la constructions du niveau, et un moteur de scrolling plus classique.

Supposons encore qu'il soit possible de convertir le décor-hibou en 4-couleurs-par-tile sans arriver à une qualité décevante. Il resterait alors entre 12 et 20K de 'sprite tiles' 16 couleurs pour se faire un 'Super School Rush'. ça demanderait clairement une gestion dynamique d'une partie de la VRAM pour les sprites, mais ça semble déjà beaucoup plus cool. On pourrait par exemple garder les sprites 8x8 statiques (pieds, mains, gouttes, etc.) et se contenter d'un tableau de bytes pour encoder l'utilisation dynamique des sprites 16x16. ça reste un gros morceau, mais c'est déjà nettement plus 'viable' que demander du streaming de bouts de niveau.

I had a dream of porting Bilou School Rush to the Queen Console: the Super NES. Last study of how that could be done concluded to a bitter 'not a chance unless you've got a team of SNES geniuses along'. The issue is that I can't draw a full line of sprites on the SNES as if it was an additional plane and still hope to see more sprites through. And the inkline in School Rush DS is all made of sprites.

But the idea came back a few days ago with a striking simple observation: what if instead of changing everything to free up a layer for the ink I change the ink itself ?Like replacing the repeated wave spikes with mostly-flat ink and a crossing bigger wave every now and then ?

J'ai deux options pour ça. La première, c'est de trouver une illustration sympa de vague déferlante. Je garde de l'encre principalement plate et statique (construite par du masquage) et je fais passer de temps en temps une déferlante composée d'un gros sprite (32x32) et qui fait le lien avec un niveau d'encre plus haut par-derrière.

La deuxième option, ce serait de modifier la position verticale des sprites utilisés pour la bande d'encre (graphismes gardés à l'identique) de façon à construire un motif en créneau. Après tout, dès que l'encre couvre de toutes façon tout l'écran, peu importe que la limite de 272 pixels/ligne empêche les pieds des bladors d'être dessinés: ils sont cachés dans l'encre, de toutes façons. Il devrait y avoir entre 8 et 9 "créneaux rouges" visibles à l'écran, soit 128 à 144 pixels consommés sur le budget de 272. En fait, pour que ça coince dans ces conditions, il faudrait que les personnages à l'écran couvrent la moitié de la largeur de l'écran (quand on les dé-superpose, évidemment). Je ne pense pas que ça puisse se produire avant le niveau 4.

Eventuellement, on pourrait même imaginer forcer l'encre à rester plus plate autour des personnages qui pataugent dedans histoire de diminuer temporairement le budget-sprites qu'elle nécessite... éventuellement.

Another thing I realized is that only one part of the ink stripe consumes near 100% of the sprite-pixels-per-line budget. On the most interesting part (the spikes), we have nice 16-pixels blank space between two 16-pixels spikes. The NDS graphics absolutely don't take advantage of this, but an SNES port perfectly could. The top-part of the ink (red) then consume about 50% of the sprite-line budget and what happens as soon as the blue part kicks in doesn't matter because there, the ink is obscuring everything anyway. That will make the ink more tricky to animate, with sprites coordinates changing much more often, but that should remain manageable.

Now the next step is to ensure the background owl can still be nice to look at when using only 4 colours per tile.

Saturday, November 20, 2021

Smashing pixels

I did a few tries to render the heavy punch smashers for the pyramid in SEDS, and most of them were deceiving. My best render So far was crafted with the Gimp using the style and palette of an inspiring Sonie-like indie game dubbed "Kyle and Lucy".
Since I had a day off yesterday, I brought them back on top of my Pyramid level mockup. After all, the pixels for the Smashers were all mine. They just needed to be moved out that Kyle-and-lucy environment.

I also took the opportunity to try another approach: some structures in the School Zone are made of wooden, gianthands. What if I turn then upside down? Can I get something Convincing by Shading them with blues and pretend they're now metallic?
 

Bon, ceux-ci ne sont pas les premiers gros-poing-écrabouilleurs que je tente, mais les précédents ne ce sont pas vraiment révélés concluant (#euphémisme. Voir ci-dessous). Mais là, je retombais sur un screenshot de Kyle & Lucy sur lequel j'avais profité de la palette pour redessiner un gros poing d'un autre genre alors que j'avais toujours mon mockup "desertcolor.xcf" ouvert. J'ai fait un test. 

Et tant qu'à faire, j'ai essayé un autre truc que j'avais en tête: retourner le poing-pillier de la SchoolZone et lui donner une teinte blue-métallique, histoire que ça ne fasse pas trop bois. Les avis sur twitter sont assez unanimes: c'est le gros poing du bas qui gagne. Par contre, un truc de cette taille en métal, ça ne fait pas fort égyptien. L'histoire a beau ne pas se dérouler sur Terre, je prends note: je m'en tiendrai à un gros-poing en pierre.

I haven't been running any twitter poll this time, but I still managed to gather interesting comments. Generally, the bottom puncher are perceived superior to the recycled school-zone structures flipped and recolorized. Of course, I should have X-flipped them for coherent lightning with the rest of the scene.
Among others, Joke@bilouCorp pointed out that Egyptians did not have the technology to produce large metallic structures. That's both quite irrelevant (since Bilou's pyramid is nowhere near the Nile and not even on our planet) and super-important, because I want people to feel like if they were in an Egyptian pyramid while at the same time feel like it is something else. If I come up with hammers looking like they're from the Misty Mountains or from Vinea, they won't "buy" it. Similarly, although I won't use the Egyptian hieroglyphs, I'll use glyph-like writings anyway and not neon ads.

Et je ne résiste pas à l'envie d'en profiter pour vous présenter le projet Kyle & Lucy de Cellar Chateau. Un jeu bien dans la veine de Sonic 2, avec ses sols qui font des crolles, ses boucles et ses tremplins. Je trouve très bien trouvé l'introduction des rollers aux pieds des héros félins (déclenchés dès que la vitesse est suffisante), ce qui permet de garder une animation lisible tout en ayant une vitesse de déplacement digne de Sonic.
On est ici dans une "zone de la musique" qui n'a pas à rougir devant celle de Rayman ou de Zool. Chapeau. Il faut dire que le talentueux Lapper (qui nous présente les avancées de son projet "Sonic Studio" sur sa chaîne Youtube) prête main forte au niveau du graphisme.

Maybe you had never heard of Kyle and Lucy before. It's another game project I'm following on twitter, with Sonic-inspired gameplay and surrealistic aesthetics. The music zone is clearly one of my favourite. Everything looks so readable there. Note how the designer has given Kyle retractable rollerblades so he could zoom through the level without having to move his legs at ludicrous speed!


Tuesday, November 09, 2021

Premiers pixels pour le désert...

Oui, enfin, premiers pixels pour scorpeye et undead-cell récupérés depuis ma DS hier soir, parce que bien sûr, les blocs de construction, eux, vous les aviez déjà vu.

L'occasion de prendre un peu la température et d'essayer quelques variantes avant d'avoir fait de longues animations, comme je l'avais fait pour inkjet et les pendats.

J'ai déjà un poll twitter en route qui donne un léger avantage à la taille intermédiaire de 27 pixels (petit snapshot parce que je vous fiche mon billet qu'on aura de nouveau un 50/50 une fois la deadline atteinte). J'en ajoute un autre pour la couleur de momie la plus à la mode

Et il faudra que j'en ajoute un dernier pour la taille des pots-à-briser (oui, pour les besoins du mock-up, ce sont juste des encriers colorisés dans Gimp.


Merci au passage pour l'avis de l'onc'Ronald pour le tuning de palette de momie. 'faut dire qu'avec son p'tit bonhomme, il voit passer tout son content de momies ;) Vous l'aurez compris, c'est de nouveau la mobilité de la DS qui a débloqué la situation en me permettant d'aller montrer et discuter des différentes options autour de moi. Même si je reconnais qu'en contrepartie, les écrans bleus dans les *EDS en développement m'auront pas mal ralenti ^^'

edit: ah bah au final, la momie tunée n'aura pas convaincu. C'est celle de droite, plus sombre, qui a eu la préférence jusqu'à ce que mon frangin ramène les choix à un 50/50 entre la bleutée (inspirée des Losts Vikings) et la sombre... comme quoi.