CompoundGob::RefreshPage

I guess you can hardly tell what's going on on the picture below, and I can't blame you for that. It's supposed to be a stomped scorpeye shell, but since I've added crawling animation for the scorpeye, we see that glitchy mess of sprite parts instead.

Ah oui, je m'étais fait un joli scorpion qui marche, mais si vous parvenez à l'assommer, tout à coup, il ne ressemble plus qu'à un tas de pixels complètement glitché. Comme j'envisage de passer refaire un coucou au "gaming club" de vendredi, ça ne serait pas mal de corriger un peu ça.

La cause du problème, je la connais: l'animation de la marche est construite avec 5 sprites hardware: un "large" pour la carapace du scorpeye et un carré pour chaque "patte". En revanche, les animations "carapace seule" et "carapace qui tourne parce qu'on l'a lancée" sont toujours inchangées et n'utilisent que 3 sprites hardware. Et le couac, c'est qu'en plus, le sprite large n'est pas sur le même d'une animation à l'autre. Il était donc temps que je me gratte un peu la tête et que je retrouve les fonctions-clé pour gérer ça, en particulier loadAnim() dans CompoundGob et setupOAM() qui peut redéfinir les tailles et aspects des sprites.

What happens is that you have dedicated bits in the hardware sprite entries to indicate whether you want a square, tall or wide sprite and of what size. So far, in my engine, those properties are defined once when you allocate hardware sprites for an object and then preserved as we just update coordinates, VRAM location and optionally palette slot of each sprite as we animate them. But by mixing the new crawl and the old spinning animations, I'm breaking an old habit of sharing the same structure for all animations of a given game object. So I need to extend the game engine with the following function:

  void refreshPages(const GobAnim *ani) {
    unsigned nlimbs = ani->getnlimbs();
    unsigned i;
    pages = ani->getpages();
    for (i = 0; i < nlimbs; i++) {
      if (oam[i]==NO_OAM) continue;
      pages[i]->setupOAM(sprites + oam[i], 0 /*?*/);
    }
    for (; i < nboam; i++) {
      if (oam[i]==NO_OAM) continue;
      sprites[oam[i]].attribute[0] = ATTR0_DISABLED;
    }
    nboam = nlimbs;
  } 

Je dois dire qu'au départ, je m'attendais à plus compliqué, mais la petite fonction ci-dessus et une brave ligne de plus, les animations se sont réparées presque d'elles-même. à utiliser avec prudence tout de même: le système ne se déclenche que si les deux animations ont un nombre différent de sprites.

To be honest, I was expecting it to be harder to code. It was a bit tedious to locate where to act in the code (state transition? animation loading ?) and I spent a significant part of a holiday afternoon in ddd setting conditional breakpoints to figure it out. Then I got puzzled by the update/setup/allocate functions manipulating hardware sprites through the "SpritePage" class: the one that is used at every frame to update what we see on screen keeps aspect ratio and size of the sprite unchanged... but after all, it was just a matter of a small function called when we detect that the current number of OAMs (aka hardware sprites) is different from the number of limbs the animation uses. Pretty and straightforward.

Crawling Scorpeye

Sur bsky, MagicalScope nous poste d'impressionnants designs d'objets magiques qui sont ensuite vendus à des internautes. Parmi eux, je suis tombé sur une potion-qui-marche particulièrement inspirante. J'ai d'abord eu le réflexe de voir comment je pourrais l'intégrer comme nouveau perso dans la pyramide jusqu' ce que je réalise que mon brave scorpeye pourrait simplement profiter du type de déplacement que suggère cette potion tout en restant lui-même. 

Après des mois où on voyait un scorpeye tout immobile dans un coin de la salle pyramidique, voici enfin une petite animation (encore un brin brouillonne) du scorpeye patrouillant autour de son trésor. J'aurai probablement un peu de travail à faire sur le moteur de jeu: l'animation de la carapace lancée supposait 3 sprites hardware alors que la marche en crabe en utilise 5 ... le résultat est assez bizarre à voir quand on assomme et ramasse notre scorpeye.

At last! After months (years ?!) of design blockage on how-the-heck-am-I-going-to-make-scorpeye-walk, I can propose you a prototype animation for the crawling scorpeye ! Maybe not as "crawling" as I had imagined after seeing MagicalScope's mimmic potion, but that shall be a start.

Key idea for the redesign is to embrace the "limbless" nature of Bilou's world and grant the scorpeyes 4 versatile spike sattelites. It can use them to crawl, pinch or sting depending on the situation's need. It will make it clear whether it's currently safe to stomp on its shell to stun it.

"Mais où sont passées ses pinces ?" me demanderez-vous ? Eh bien c'est justement là tout le sel du redesign: les même membre lui serviront soit de pattes, soit de pinces, soit de morceau de queue de scorpion. Je décide que ce sera plus fun et plus lisible qu'un vrai arachnide avec tous ses chéli-chose (J.L.N ? c'est quoi le bon nom, encore ?) 

As a bonus, an intermediate step where I was studying the design of the magic potion and considering "well, why not. It would be an extended version of Inkjet that can move along... quite fits the universe. You lose some part of the crab-like suggestion by not having limbs between the pinching part and the body, but that's how I came up with the idea of keeping scorpeye and having it walk on its pincher, so I'm okay with it.

 

Scorpeye... Enfin!

 Oui, je l'avoue, j'ai été lent. J'ai été distrait (au sens attention détournée). J'ai été démoralisé par cette "carapace" qui ne voulait pas faire demi-tour à chaque fois ou qui faisait des demi-tours intempestifs. J'ai douté, de cet empilement de couches qui devait me permettre de laisser des personnes non éduquées au C++ de bricoler aussi leur propres personnages. Sauf que tout ça, c'est bien joli mais que quand vous avez un dysfonctionnement quelque-part, le débugger vous balance des instructions machines alors que le problème est dans le bytecode qu'elles interprètent. Et mon "inspector widget" (pas encore fonctionnel dans le projet 3 rooms) est loin de valoir ddd.

It's been a long time, I have to admit. I've been slow to get things running; I've had lost the hope that I could get that scorpio-shell turning back when it hits a wall... and only when it hits a wall. It felt like I had built a Jenga stack of complexity in order to have a 'simple' interpreter for state machines. But a language is never less complex than the tools you provide to debug it. And Inspector Widget fell short when trying to explain the issue (partly because it is surprisingly not yet working on Dreams.nds)

Une intuition pendant mes vacances ... j'ai retracé la machine d'état de mon scorpion-cyclope. J'ai bien identifié deux ou trois incohérences, mais rien qui ne conduise au bon comportement une fois corrigé.

Oui, je sais aussi, par rapport à ce que je bricolais sur le côté pendant mes semaines de vacances, c'est maigre. C'était des vacances un peu ... particulières.

Puis hier, j'ai repris la machine d'état de pendat. Lui aussi, il réagit quand il fait demi-tour en se prenant un mur. Et il n'est peut-être pas parfait, mais il marche en général bien mieux que cette satanée carapace.

Alors que scorpeye tentait de reconnaître l'absence de sol à l'aide d'un testpoint, pendat se contentait de "dire" "ah bin si la vitesse horizontale est tombée à zéro, c'est qu'on s'est pris un mur. Sinon, c'est qu'on a plus de sol. C'est forcé."

I found only a small evening of ndsdev during my summer holiday this year, and I used it to map the state machine of Scorpeye. It helped me finding a few weird stuff, but it would not make things run properly enough, unfortunately. Then I realised past Inktober that I already had a 'working' monster that bounced off walls. That was the running pendat. And I started mapping its state machine too (granted, after all these years of dsgametools, I should have given myself a tool to make that automatically). To my surprise, it almost never used the same tricks to perform the same task.

For instance, I used a TestPoint below scorpeye to tell me whether there was ground underneath when it claims it failed to slide on the ground. But this is unreliable because it checks only one point to decide for ground while the WalkController checks the whole surface. Instead, the pendat would test whether it came to a halt horizontally. If it did, that means there has been a wall. Otherwise, it bets there's no ground left.

Same with fall/slide transition: the scorpeye tried to use a testpoint to know whether it FAILed because of a ground. Pendat code author (past self) knew the only thing that can make GobGravityController FAIL was a ground. Being stopped by a wall triggers an event. That means no testpoint validation is required.

Finally, I gave myself an extra variable (there are still plenty available for scorpeye) to remember the sliding speed so that we can bounce walls without having to rely on an ImpactController to save the last speed, because so far I don't think GobWalkerController is an ImpactController. It requires to double some states (like left-thrown vs. right-thrown), but that should not be a big deal.

Still, there's one thing that I'll need to fix with unit testing: from times to times, being stopped by a wall while 'walking' doesn't make the move FAIL, but it does clears the speed. Pendat doesn't suffer for that because it has an "increase horizontal speed" statement in its running states that prevents the speed to stay null. I had to add the same statement to the shell, but it shouldn't be required. that's a todo item for XMAS, I guess.

Il me fallait un double-état pour la carapace lancée, une variable supplémentaire pour retenir la vitesse à la place de la 'variable d'impact'... ce genre de choses. Mais il y a un élément suspect. Pour qu'il n'y ait aucun soucis, je suis obligé de mettre une instruction forçant la carapace à accélérer. Sans ça, il reste des situations dans lesquelles je retrouve ma carapace toujours dans l'état "on glisse vers la droite" mais avec une vitesse nulle est un mur juste à ça droite.

Comme si GobWalkerController avait un bug qui l'empèchait parfois de signaler l'échec (FAIL) même si la vitesse tombe à zéro. ça, ce sera une tâche pour un test unitaire.

scanf %ms ou scanf %n?

 it should have been quickly done. Almost trivial. Edit "DHud.cpp", revive calls to the MuadDebug class, change the GOB number so that it tracks the scorpeye rather than Bilou, and make it rewind time

• when the shell's horizontal speed turns to zero
• after it has been thrown (there's a flag telling us that)
• after it has been picked up (need a new flag for that).

Except that however I tried to do it, and regardless of the amount of instruction-by-instruction stepping I made, I couldn't get the second condition to trigger. The optimizer did a great job at packing the expression evaluation code -- I mean there, that you can't tell anymore where you're in the source while doing it, and thus mostly can't set a breakpoint on a specific instruction.

Hopefully, there's the B opcode (not D, which is for Detach) to break at the script expression level. That one at least allowed me to realise that the expression for that second condition was indeed evaluated. But for some reason, the part I was interested in, with flag-setting, never got executed. A 'all done, bye' opcode always showed first. Mysterious...

Faire des essais dans le jeu pour essayer de reproduire un 'trick' pas fréquent, et avoir programmé un critère d'arrêt qui nous permet de passer en débugging pas-à-pas mais en revenant une image en arrière dans le temps, donc en revivant exactement l'évènement qui fait que tout est parti de travers en bullet-time pour pouvoir le comprendre et savoir ce qui doit être corrigé. J'appelle ça le muad-debugging, et c'est vachement pratique.

Enfin, surtout quand ça marche.

It turned out the reason was the expression got truncated even before it was turned into bytecode. Such a thing is not viable to extend the game to "Bilou Dreamland" level.

The code to parse an expression basically looks like

siscanf(base+cont,"[%64[^]]] (%64[^)])",predicate, axion)

And both 'predicate' and 'axion' arrays are static-sized. I know there's another way you could do the 'same' thing, but with any-sized arrays. That'd be something like

siscanf(base+cont,"[%m[^]]] (%m[^)])",predicate, axion)

in which case the siscanf function will allocate some memory by itself and you'll have to invoke free(predicate) when you're done with it. It is sure the way to go in most of your production code, but to be honest, I do not want this within GEDS script parsing code. Parsing a level already takes too much time. Adding dynamic memory for strings processing will only make things worse. Not to mention that it will fragment memory with temporary strings requested while we're making big blocks for the 'tank'.

But there's another trick I could (and likely will) use:

%n Nothing is expected; instead, the number of characters consumed thus far from the input is stored through the next pointer, which must be a pointer to int. This is not a conversion and does not increase the count returned by the function

Combined with the fact that %*s scans a 'string', but does not store it, I should be able to write

siscanf(base+cont, "[%n%*[^]]%n] (%n%*[^)]%n)", &predistart, &prediend, &axstart, &axend);

Now, I'd have start and end pointers for both expressions (if they're actually there), plus that would be copy-less and I would directly perform ascii-to-bytecode conversion. The conversion code would have to be adjusted, of course, so that it takes two pointers instead of one and that it does not expect a terminating \0 character at the end of the expression. So that will be a new "todo" item for when ongoing things are cleared and time is right to start something more experimental.

Oh, yes. And I could just grow the static arrays, of course. That's what I did in the past when they were 32-character long each, and I thought "well, 64-bytes predicates ought to be enough for everybody, right ? ". In another context, I could pick ridiculously large arrays (like 2048 bytes each) and forget about the issues for decades until it strikes back with some auto-generated script. But that would be a bad idea on the Nintendo DS with its fairly small stack. And nah, I won't make the arrays global either. That would sure break so many things in the ability to run that code out of its current context that it has even been considered as an evil thing to do by the former generation of developers.

Oh!? A post! A shell !? Progress ?

I know it's been a long time. Would you like an explanation ? It's a nice one, with Persian princes and oversea travels and unicorns. Maybe even a dragon!

Anyway, I finally got some code refactory completed so that more 'controllers' can record impact speed into script-friendly variables. That at last allow me to code whether a scorpeye shell should bounce or not when it can no longer keep moving the way it was.

Salut! Vous êtes toujours là ? Bien! Merci ^_^ Allons-y, alors. J'ai enfin repris mon projet NDS, finalisé cette classe GobImpactController dont dérive maintenant GobGravityController, mais aussi GobFreemoveController, ce qui devrait (enfin) permettre à cette satanée carapace de scorpion de faire demi-tour quand elle se prend un mur.

Enfin, ça aurait suffi sur un sol lisse et infini. Mais j'avais justement un trou dans mon miniveau de test, j'ai donc pu chipoter un peu plus avec les testpoints, pester sur le fait que le contrôleur de chutes signale un event quand on se prend un mur (plutôt que d'annoncer l'échec du mouvement, vu qu'on peut toujours continuer à tomber ... dans un sens, c'est logique).

Je vous aurais bien mis une vidéo de tout ça, mais à 1Mo la vidéo de 10 secondes ... les plus irréductibles sont invités à la regarder sur twitter.

Oh, granted, there's been pitfalls. The fact that moving along the ground fails when you hit a wall while falling down and hitting a wall just creates an event, wasn't exactly welcome-back-to-coding-friendly.

But well, there it is. There it bounces. Unless you throw it straight into a floor+wall corner or on some odd location on the sand. I'll need more runME+InspectorWidget to find out what is going on there. Or maybe some more muad'dibugging ?

freemove ou pas

Bon, le week-end était bien chargé et la semaine qui commence risque d'être du même accabit, mais j'avais quand même trouvé le temps de modifier la configuration de runMe pour corriger l'affichage des sprites 32x16 et du même coup pouvoir utiliser InspectorWidget convenablement. Il est temps que je trouve pourquoi les carapaces de Scorpeye ne font pas demi-tour quand elles rencontrent un mur.

Et on dirait bien qu'une des raisons, c'est que j'ai utilisé pour cet état-là le contrôleur "freemove". (oui. encore;) Et freemove n'a pas le code C++ qu'il faut pour 'rapporter' la vitesse à laquelle on se déplaçait au moment où une collision avec le terrain a empéché un déplacement d'avoir lieu. Or c'est cette valeur qu'il faut utiliser pour faire le demi-tour.

Despite a week-end with a good deal of events, I managed to fix runME so that it could too display 32x16 pixels sprites properly. That unlocked the use of InspectorWidget to find out why scorpeye shells won't bounce when they hit a wall.

Apparently, the core reason for that is that the GobFreemoveController I use for sliding shells is unable to tell at what speed it was moving when there had been an impact with the wall. As a consequence, the script handling state transitions cannot properly program the new speed. And yes, that is very similar to an issue I've had with 'swimming' state for Bilou not so long ago. That sounds like I should refactor something so more state controllers can report impact speed...

Bref, soit un contrôleur comme 'walker' ferait l'affaire, soit il faut que je prévoie quelque-chose d'autre. peut-être que 'sauver la vitesse actuelle si le déplacement en cours n'est plus possible' devrait en soi être un contrôleur autonome dans la chaîne ?

Ou je met une vitesse 'hard-codée' pour l'instant ?
 

des sprites 32x16 ?

Le support des sprites rectangulaires, c'est pas encore une grande réussite dans GEDS. En chipotant un peu, on parvient à avoir une planche de sprites verticaux ou horizontaux dans SEDS. Ils sont quand-même édités sur une grille carrée, mais soit.

Les choses sont déjà un peu plus louches dans AnimEDS, où de curieux résidus viennent se placer par-dessous un sprite 32x16. ça gâche un peu l'effet, mais disons qu'on s'en serait accommodé le temps de d'un ennemi ou deux.

There is somehow way to introduce non-square sprites in my SpriteEditor (with those 'new W(ide)' and 'new H(igh)' buttons), and the NDS hardware definitely has support for them, but let's face it: none of the game engine or Animation Editor was half ready for a 32x16 scorpeye 'shell'

Mais le moteur de jeu a l'air de perdre complètement les pédales, lui.

Une petite réactivation de l'afficheur-de-sprites finit par me pointer le problème: je suis déjà au bout des 1024 sprites possibles dans ce nouvel environnement... enfin, pas exactement. Je n'ai pas encore saturé les 128K de mémoire disponibles pour les sprites, mais seulement les identifiants disponibles.

J'ai déjà joué avec ça pour l'éditeur de sprites, mais le moteur de jeu, visiblement, n'était pas prêt non-plus pour ça ... ça va faire un gros commit ...

You see: it really doesn't make sense. We get parts of Bilou heads instead of getting our expected shell, and the shape isn't even rectangular. Part of it is because the engine cannot change the shape of a 'limb' for a compound character while playing (changing states doesn't let you break that rule). If you're rectangular on your frame one, you're rectangular all your life long. Another part of it is because I'm hitting the tile number limit. I thought SchoolRush was already using 128K of VRAM for sprites, but it seems I was wrong and everything used to fit the default 64K. Only the background tiles had been increased. Anyway, the Makefiles didn't like it, but it is now expanded to 128K. Anything else ? Yep. size = 16 + mode = wide gives you 32x8 sprites. Not 32x16. That explains the lone stripe I had in the final attempts.

Un autre soucis visible sur l'animation: les tailles de gobs pour une page donnée ne peuvent pas être changées en passant d'une animation à l'autre. Et j'avais gardé la première version 32x32 pour l'animation "immobile". Du coup, les autres animations tentaient aussi d'utiliser du 32x32 même quand les images à charger étaient en 32x16.

Ah, et j'ai probablement sous-estimé l'existence des sprites 32x8, ce qui fait qu'encore après tous ces patches, il me manque la moitié de ma carapace ...

Codons du scorpion

J'ai fini par avoir un petit temps creux avec le cube allumé. J'en ai profité pour faire deux animations-bidon du scorpion dans AnimEDS et les transférer par wifi hors de la Nintendo DS. Du coup, en reprenant le comportement de base de dumblador (seul autre ennemi que l'on puisse ramasser pour le moment), je peux *enfin* voir ce que donne le fait de ramasser une carapace de scorpeye pour se promener avec.

Eh oui, vous aviez reconnu les pieds de bladors qui s'échappent, hein. On ne vous la fait pas. A terme, ils seront remplacés par les pinces du scorpion, évidemment. Avec à la clé une question de game design: est-ce qu'elles devront pincer Bilou ou non?

I've been creating dummy animations for the Scorpeye with existing pixels and beamed them out of my DS so I could start toying with the ennemy in the playground level. The dumblador state machine provided a neat template to start with, and despite there are still many rough edges, I could get a proof-of-concept within a couple of hours.

Mais bon, un dumblador, ça s'arrête net quand ça arrive sur le sol. Moi, je veux un comportement de carapace de koopa. quelques petites modifications dans le script permettront ça en moins d'une heure: deux nouveaux états $LSLIDE et $RSLIDE au lieu de $STUNSTAND

Les transitions du style 

$STUNFALL->$STUNSTAND on fail [t] ($8000 F $vPlatform(1));

sont maintenant remplacées par une paire de transitions

$THROWN->$LSLIDE on fail [v2 1 & v0 0 <= &] ($8000 F $vPlatform(1));
$THROWN->$RSLIDE on fail [v2 1 & v0 0 > &] ($8000 F $vPlatform(1));

Un petit rappel de la syntaxe ? l'expression entre crochets [] est la condition à vérifier pour que la transition puisse avoir lieu et l'expression entre parenthèses, l'effet de bord à appliquer en plus de la transition. (ici, j'ai du nettoyage à faire, puisqu'une carapace ne devient pas une plate-forme quand elle touche le sol. $vPlatform() ne sert donc à rien)

Les expressions utilise la notation polonaise inverse, donc soit vous ajoutez des valeurs sur une pile (v2 qui empile le résultat des test-points, v0 qui empile la vitesse horizontale, les nombres qui s'empilent eux-même), soit vous retirez des valeurs pour faire une opération (comparer deux valeurs et les remplacer par vrai/faux avec <= ou >, faire un ET logique avec &).

I'd like to tell you that I've got more animations done on the DS and that they are going to be integrated soon. The reality is somewhat different. I've lost several improvements attempts while animating yesterday and I'm not 100% sure of what got saved and what didn't. Apparently, there are still many combination of altering the 'animation structure' and returning to edition that need to be unit-tested and fixed. But that's not done yet. I'd like to be able to give you a 'meet you on saturday afternoon for a updated demo', but IRL struck again, and fairies only know where I'll be by then.

Devant ou au-dessus ?

 Pas mon masque, hein. La carapace de scorpion quand Bilou la transporte. Celle qui doit me permettre de faire quelques petits moments-koopa dans la pyramide. La logique voudrait qu'on la transporte au-dessus de la tête de Bilou, comme les Dumbladors et les éponges dans School Rush.

Mais voilà, je me souviens bien qu'un des trucs que je trouvais dommage dans Super Princess Peach, c'est la manière dont elle ramassait les carapaces pour les tenir par-dessus sa tête avec son ombrelle, la laissant du coup vulnérable à une attaque frontale du plus élémentaire goomba. Je préfère de loin la technique de Mario qui peut se protéger (voire foncer dans un ennemi sans hésitation) dès qu'il a ramassé une carapace.

Should Bilou carry throwable scorpion shells in front of him, like Mario and Diddy or should he carry them over is head like Donkey and Princess Peach ? Both Twitter and my bro agree: over-the-head is better. It sure looks better: the shell is too large to be handled any other way. Plus, other carry-me items in the game already gets carried I can't forget however that I preferred the experience of in-front in all the games I played so far. It shields you against incoming foes, let you find hidden areas without taking any risks and avoids functional blind spots when you're throwing them.

Idem dans la série DKC: une des choses qui fait que j'ai toujours préféré jouer Diddy plutôt que Donkey, c'est que Donkey porte ses tonneaux au-dessus de lui. ça les rend à la fois moins utile comme bouclier et comme détecteur de passages secret: Diddy peut se contenter de s'approcher du mur alors qu'avec DK, il faudra s'approcher pas trop et lancer le tonneau (ou alors, on se baisse et on dépose le tonneau, quitte à le reprendre si on a fait chou blanc)

Du coup, j'ai fait un p'tit poll sur twitter pour voir un peu vos avis ... Majoritairement en faveur du 'par dessus la tête', visiblement. ça paraît raisonnable. J'imagine qu'on devrait pouvoir garder un côté "bouclier" en s'abaissant pendant qu'on porte la carapace, façon Blues Brothers / Tic & Tac. Il faudra par contre que je sois attentif à ne pas laisser trop de "zone morte" au moment du lancer pour éviter le défaut de DK, en particulier si je veux être efficace contre des ennemis à peine plus hauts que Bilou.

I think I can fix the shielding issue with some duck-while-holding that would reduce Bilou's hitbox and increases the odds that the shell takes the hit instead.

I'll need to take care of the functional blind spot. The shell should leave at a speed high enough that it feels 'fast' to the player (might be the other issue with Super Princess Peach's throw move). I sure can't afford the blind spot to be as large as in DKC (anything between Kong and banana on the picture above is out of the barrel's reach)

edit: Maybe my memories of Super Princess Peach are skewed. Re-playing it a few minutes didn't give me that feeling that koopa shells were broken, and one reason for that is that Peach also gives a (short-range) umbrella attack while throwing. 

Possibly the real issue is with button mapping: you use PICK UP to take the shell, but if you use the same button again, you'll drop an harmless shell rather than throwing it as a long-range attack. And if you press the ATTACK button instead of PICK UP when you don't have the shell with you, you risk of destroying the shell instead of getting a weapon. None of this should occur with Bilou, hopefully. And when you see that the shell in Princess Peach has lowered by more than 1 block within the first 4 frames of animation. Low enough to hit any possible monster with almost no build-up time.

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.

 

Pyramid mechanics

Jusque là, j'avais prévu de me servir des "blocs poilus" pour servir de blocs destructibles dans la pyramide, mais je crois bien que j'ai trouvé mieux. Et tout simple, avec ça: des pots. Eh oui. Ils peuvent être brisés, ils peuvent libérer des trucs, ils peuvent bloquer le chemin de Bilou.

Bilou peut naturellement ramasser des trucs. Les pots aussi, mais on peut faciement dire que seuls ceux qui n'ont rien par-dessus. On peut construire plein de scènes sur cette base-là, où un 'mur' de pots bloque un accès, qu'on ne saura libérer qu'avec une carapace de scorpion.

What can play the role of breakable blocks in the pyramid ? I once thought it could be furry blocks, and possibly I'll keep them in some places ... but building walls with them ? or large structures like SMB3 "pyramidal stack" ? I finally found something that could work better. Okay, lifting up jars and throwing them against walls to get goodies isn't exactly an original mechanics, but it would work fine with the pyramid setup as well as with a shell from a scorpio.

On peut en imaginer des 'intacts' qui font faire demi-tour à la carapace et d'autres déjà fendus qui laissent passer d'un coup.

Enfin, on peut ranger des pots sur une étagères, on peut les faire tomber en cognant l'étagère ... bref, ils peuvent servir de 'briques en l'air' qu'on casse en tapant dedans par le bas.

L'autre truc qui ne me branchait pas, c'est les lanceurs de flèches. J'avais une note proposant 'des statues de chat pour les boules de feu, des statues d'aigle pour propulser vers le haut'. Mais des piafs embusqués qui tentent de becquer Bilou et dont on peut utiliser le cou comme tremplin-à-la-Ori, ça serait sans doute nettement mieux.

One other thing needed more thoughts: wall hasards. Like arrow throwers or spears pointing out and coming back. I loved the idea of them being helpful to climb up with the right timing, but we've been served the cliché of climbing up spears stuck into walls after you dodged them so many times ... It wasn't too clear what would throw them either.

But given how birds are expected to play a major role in the last world of "Bilou Dreamland", I thought "why not long-neck beaked baddies trying to snap Bilou and then getting stuck into the wall facing them, so we can use their neck to climb up ?

Scorpion or not scorpion

I'm still on my quest to find creatures to fill the gameplay of the "infinite pyramid", looking for things that will remind the player of Earth Egypt / deserts while keeping the exotism of Bilou-like characters. And my fresh quest on "why some Ori monsters didn't work on me" pushed me to find the real best candidate so that my own fiction keeps an homogeneous world. It's kinda tricky, and it is possibly the first time I'll have a full area with monsters of my own from the first stroke to the last pixel in the game.

J'essaie de trouver des personnages pour peupler cette fameuse pyramide. J'ai déjà quelques possibilités pour des figurants, mais rien de suffisamment interactif pour motiver sérieusement la scribouille de petits scénario comme j'ai pu le faire avec le Bilou's Book au début des années 2000.

J'avais une idée de "rampant", dont le design était inspiré de Toki Tori 2 et des torches de Link's Awakening (le vieux).

I already had a fun crawling crab sketch. I got it by blending the look of some Link's Awakening torch with the gameplay of Toki Tori 2. It introduced the idea that "monsters are the treasure, and the treasure is the monsters" that would fit nicely with the design of the School Zone and the green zone, but I'm afraid those little crawling legs will make it too slow to be truly interesting. Plus it only fits the theme if it is impossible to stomp on. I had the idea to try something with a glowing, gem-like back, inspired from some HoB crawling sentries. There came the blades (instead of pinches), and legs might be made of that metal helping gems to fit rings. But the outcome isn't working as I expected.

J'ai aussi essayé quelque-chose qui restait dans le thème "les monstres, c'est le trésor, le trésor, c'est les monstres" pour prolonger l'idée d'objets animés que l'on peut voir dans la forêt (berrybats) et l'école (pendats, inkjets). J'ai tenté de m'inspirer des robots-sentinelles de HoB, avec leur derrière qui brille comme une gemme ... Les pinces étaient du coup des lames de sabre (ou des fermoirs de collier), les pattes des griffes-à-brillant pour une bague.  Mais le résultat ne m'emballe pas.

If I was to focus on the gameplay first, I'd love one of the monsters in the pyramid to provide a shell that can be kicked as a koopa shell. I confess: this is a game mechanics I love in Mario games and I'd really love to be able to use things like that in my own levels as well.

Puis je me suis remis à avoir envie de carapaces-de-koopa à lancer contre des murs et j'ai remis le couvert en essayant de faire en sorte que les "nasty bugs" puissent être utilisés comme des koopa une fois assommés. Il aurait avancé plus vite sur 4 pieds pendant sa "patrouille" que redressé sur 2 pieds en utilisant 4 pinces pour essayer de saisir Bilou. C'était sympa. Il resterait à lui coller une coiffe égyptienne ... sauf que les dernières tentatives lui prévoyait une taille presque plus haute que celle des pendats. J'ai essayé d'en refaire une version "couchée", mais le look ne convenait pas. Les pattes alignées les unes à côté des autres à la façon des araignées de Badman II étaient bof et ne laissaient que trop peu de place pour les yeux.


Puis j'ai un un flash en voyant les "tektites" du nouveau Link's Awakening pendant que J.L.N explorait la rivière Tal Tal: si je lui donne une démarche de crabe, sur le côté, mon scorpion devient plus expressif tout en restant mobile et tout en pouvant se transformer en une carapace-à-lancer en cas de besoin ^_^
Il me reste à décider si je lui donne une carapace qui est un gros joyau ou si je reviens vers quelque-chose de lisse, noir et luisant comme sur mon premier essai.

The final touch might come from (new) Link's Awakening tektites. With their front view and side moves, they provide interesting and easily recognisable shapes.

Ce qui est à peu près sûr, par contre, c'est que je lui mettrai une sonette-de-serpent au bout de sa queue de scorpion histoire de ne pas condamner l'unique angle d'attaque de Bilou.