mardi, avril 21, 2015

Salut, vieux.

T'as pas pu t'en empécher, hein ? Tu es encore revenu dans les archives perdues de ton blog pour essayer de te souvenir comment il est possible qu'il y ait eu un "trou" de plusieurs semaines entre la version 0.8 et 0.9 que tu n'as d'ailleurs jamais pris la peine de numéroter d'un petit jeu baptisé "School Rush". Et tu vas nous pondre un article nostalgique sur le thème du visiteur temporel. Forcément.

Eh bien, je vais te rafraîchir la mémoire.

Tu vois, c'est sympa, le développement pour le fun. On code un p'tit bout par ci, un p'tit bout par là. Mais voilà, à force de construire des étages les uns par-dessus les autres, tu t'es retrouvé avec une sorte de tour de Pise qui a terriblement besoin qu'on revoie ses fondations. Il y a trop de choses que tu as perdu de vues, au point que tu t'es retrouvé avec du code redondant ou incohérent. Tu étais bien décidé à ne pas baisser les bras. Le projet en vaut la peine: c'est juste un contretemps. Mais là où tu mettais un point d'honneur à te montrer à toi-même que tu étais capable de relever ce genre de défi quand tu étais chercheur universitaire, tu es maintenant dans un job où ce genre de défi, c'est aussi ton lot quotidien dans les semaines de release.

Alors, la prochaine fois que tu éprouveras du dédain pour ceux qui construisent un jeu dans un moteur "2 minutes au four", rappelle-toi qu'ils font ça exactement pour la raison qui fait que tu compiles avec GCC : pour avoir une base solide sur laquelle s'appuyer.

Maintenant, éteins ton ordinateur et monte te coucher: la journée de demain pourrait bien être pas mal gratinée. Moi, demain, si j'ai un moment de calme, je vais en profiter pour gribouiller un peu et continuer à chercher ce qui me plaît dans les "déviations" que j'aime bien. Ça me changera les idées.

/Toi-même du passé.

jeudi, avril 09, 2015

iScriptException ...

Something uncomfortably wrong occurs in the game engine. Objects I'm trying to restore have invalid state attached. I believe this is the reason why there has been "guru meditation" screens during last playtests with friends. It seems linked to abnormal use of the memory: while the infringing object seems to have proper structure, it seems linked to a state that is absolutely not looking like a state structure, but rather some animeds content...
That could quite match with some earlier dig into the issue where I had invalid pointers at some delete() operators, leading to red "guru meditation" screens. I unpacked my gdb-remote-analyzers-and-setup-perl scritps. It takes ages to launch the game in that fashion, but I should get a list of stack trace for those locations that shouldn't have been released. I may need to find a proper path to reproduce the issue first.

Meditate on this I will...

3 days later, with 2 runs on the first level, I managed to trigger the exception again in the "demulator", producing 1GB worth(?) of log. I have hopefully a shorter summary of the 11 addresses involved in operations that looked suspicious. I need to program the software eyes that will scrutinize those operations and explain what happened.

2 more days and "PERL's eyes" are ready. I get detailed reports with stack trace of the last allocation, the last sound deletion and the offending "double-free" issue. But what should I think about some memory block that is first allocated in "GobState::addOnDone" (thus should be a transition, somehow, or the vector of transitions), gets deleted as GobState is destroyed, and then destroyed again as a GobAnim ?_?

Finally, one object, shot during some state transition is delete twice, with a time locality pattern that makes it look like a real issue, not some side-effect. Both deletion happens during Engine::animate(), likely at a few frames interval. How has that occured ?

What transition create that object ? What object is it ? Which object created it ? ... At least those questions can be answered with the whole recording of memory allocations. I know from stack trace the address of the transition that created the "faulty" object. From there, running "Perl's eyes" once again, I find it belongs to a "fall->hit" transition of Bilou, and the object generated is a "power-down" object. That might help reproducing the error ... tomorrow.

Question: while there has been only one "constructor" call, could there be two "reganim", making the object linked twice in the objects list ?
Question: if there's a single "reganim" for two "delanim", what is the cause ? Who messed up with the list's invariant ?

dimanche, mars 29, 2015

BigPunch, 3rd try.

Second try was based on track(Bilou), but it was ridiculously non-working. Picture big punches flying around, chasing Bilou like berry bats... No. Really not. I dropped the code-driven approaches, made an animation of Bilou punching the ground, then erased the punch for the last frames and synchronized the apparation of a punch object when it disappears from the animation. That way, the punch can pound to the ground even when the ground is lower than Bilou's feet level.

La troisième est la bonne. Voilà un coup de poing qui passe plutôt bien. Pas comme la tentative pathétique d'adapter le comportement des berry bats pour que ça tourne comme un coup de poing autour de Bilou.

edit: 30/3: fixed flickering glitch

samedi, mars 28, 2015

Nitrome, Ni trop peu

Il y a 25 ans, avant de commencer le projet Caliméro et devant le refus de mon frère de me dessiner d'autres niveaux pour Logic Labyrinth, j'avais imaginé utiliser RND() pour me construire des variations de la "Bridge Zone" de Sonic 1 (SMS) sous le nom de code "Sonic Labyrinth".
Le projet n'aura débuté, mais vous comprendrez que quand j'ai vu "Platform Panic/Infinite Platformer" sur twitter, ma curiosité était immédiatement piquée.

Thanks to birslip, I discover "Platform Panic" by Nitrome studios. I said earlier I wasn't interested in procedural generation for platformer levels, but I once had ideas like that, so cute pixel + implementation of some old fantasy of mine = curiosity leveled up.

May the Seed be with you
After watching some trailers and playing the game with my brother, I don't believe we have procedural generation here. It rather looks like a flip-screen game where the screens were turned into decks of cards and each deck was shuffled. When starting a new game, the system draws a few screens from each deck (and each deck correspond to a difficulty level). The combinations are numerous, and you will never face the same game, leading to some level of permadeath. Still, you will recognize rooms you have met before, and each room gives a feeling of being designed with care.

Il ne s'agit pas véritablement ici de créer des niveaux aléatoires au sens d'un roguelike et de son générateur de map. Je pencherais plutôt pour une base de données de salles parmi lesquelles on tire une séquence de salles pour la partie donnée, comme dans Qwak, mais généralisé. Tout comme Spelunky, on est ici dans un jeu à "permadeath" -- comprenez que votre mémoire ne vous sera que moyennement utile si vous échouez parce que la partie suivante pourrait très bien ne pas faire ressortir la salle qui vous a donné du fil à retordre. Et c'est du "one-shot", aussi ... à la Fury!


Building Blocks

I tend to believe that playing a video game is learning. The most obvious is to learn the topology of the playfield, but with the shuffling, this is not as useful here as in Donkey Kong Country. But you still learn. How far a jump goes. How close you can approach from hazard while still being safe. And most of all, what is hazardous and what to expect from it. Platform Panic feature most of what you could expect from split-screen platformer if you ever played any Spectrum-era willy-esque game. Crumbling floor, revealing spikes, springs that throw you up at first contact ... to get you reach the spikes on the ceiling, plus your usual falling hazard and shooting walls.

Bloc escamotable, pointes qui chutent ou qui sortent après votre passage, ressorts qui propulsent sans crier gare ... sans oublier les plate-formes mobiles, bien sûr. Les ingrédients du level design de Platform Panic sont de vieilles connaissances qui ont fait leur preuves -- si vous êtes du millénaire dernier. Par contre, les contrôles résoluments iThing, ce qui rafraîchit la donne. Avec un mouvement "demi-tour" et un mouvement "saute", le petit perso n'est qu'à moitié sous votre contrôle ... à peine plus qu'un lemming, en fait. Ce n'est pas sans rappeler "Rayman Jungle Rush" de Pasta Games / UbiSoft, mais ici en "flip screen".

While all this might feel réchauffé, it is served with your favourite touchscreen indie sauce on controls. One move to make you turn back, and one move to jump. No sophisticated buttons to press this time, but no time to rest either. Your character is always moving, and most of the time, it is moving towards instant death. You'll have to learn to identify those hazards quickly and plan ahead if you don't want to trap yourself.

Pixel Perfect
Côté graphisme, Helm nous a concocté un environnement agréable, rétro ni trop peu, facile à "lire" (bleu=inerte, pas bleu = méfie toi), mais pas surchargé non plus, et des petits personnages de toute beauté. J'ai bien peur que mes capture de trailer youtube n'en donne qu'une idée très déformée... Et c'est tant mieux, parce qu'il y en a, des pièges retors, et qu'avec un perso qui avance en permanence, on a qu'un rapide coup d'oeil pour analyser la situation et voir que "si je me laisse tomber ici, les pics vont me suivre et me prendre au piège".

Hopefully, Helm did a wonderful job on the pixel art. It is charming, varied while remaining easy to read. I'm afraid the screenshots from youtube videos won't do it justice and you'll need an alternate source to get a clear idea of their quality. The design of the characters is lovely as well,


Je suis assez bien fan du design des robots de cette usine (?), qui se déclinent jusqu'ici en "sauteurs", "marcheurs" et "volants". Il y a aussi les mines, bien sûr.

No Tuto
A l'exception des glissements de doigts suggérés sur l'écran d'accueil (la salle 0), il n'y a pas de réel tutoriel. On apprend de ses erreurs. Heureusement, elles se produisent surtout en début de partie quand on a pas encore appris ce que font les différents blocs interactifs. Je suis tenté de penser que les niveaux sont regroupés en "phases" et que le jeu progresse d'une phase à la suivante avec une difficulté qui augmente par palier. Niveau 1, une seul obstacle par salle. Niveau 2, on commence à combiner (p.ex. blocs à pointe et tir de missiles). Niveau 3, il faudra enchaîner les contrôle comme faire demi-tour en cours de saut.

I love how the Nitrome team dared to go to the essence of the game and not clobber it with tutorial on each hazard. You learn from you mistake. You fail a lot when you start, but your failure is just another way of exploring. Because you're not repeating the very same steps every time you retry, dying is not so frustrating. It gets more frustrating when you reached some depth in your path and now have to start again at room #1. But that's more the kind of irritation that make you want to beat your own score rather than some frustration that makes you wish you weren't playing.

Coin Layers
You will then realise that those coins that look randomly dispensed in the level have more value than you thought. They can be used to purchase continues (try again the room you fail) and other power-up that will change how you experience the game (I guess, although you might have to farm a lot for that). But mainly, placing the coin at this or that part of the screen allows for slightly more variations and bring closer to "infinity"... 
All to say, I love the game's design. It's an effective way to build fun time from old-school gameplay elements. I might reuse the idea when time will come to make a mini-game in Bilou's pyramid or castle zone.


Que faire à part s'éclater dans ce jeu ? Eh bien collecter des piécettes. D'abord parce que c'est brillant et tournoyant alors qu'il y a de la gravité, mais surtout parce qu'à un certain niveau dans le jeu, elles vous permettront de vous acheter des continue plus que bienvenus (15 pour le premier, 30 pour le second, etc.). Elles permettent aussi de débloquer des persos supplémentaires (l'armure double-saut, p.ex.) ou des nouvelles compétences (rebondir sur les ennemis ?). Placées adroitement, elles permettent tout comme dans un bon Mario de pousser le joueur un peu plus dans les cordes. Elles ajoutent aussi une couche d'"infini" puisqu'elles ne sont visiblement pas toujours au même endroit lorsque le jeu vous ressert la même salle.

Voilà. J'aime beaucoup la recette, et j'ai très envie de la resservir dans un des "mini-jeux" qui servent de jalon le long de la route qui mène à Bilou's Adventure ... Ça marcherait assez bien avec la Desert Zone, voire avec la Castle Zone.

jeudi, mars 26, 2015

Big Punch ...

Quelques petits essais de gros coups de poings comme 2eme power-up... mais je ne suis pas tout à fait satisfait du résultat au niveau animation.
You voted for BigPunch, and indeed, it would be a good power-up as it allows to bypass many challenges. Here's a first attempt, with gravity-based animation. I'm not quite convinced by the result.

dimanche, mars 22, 2015

Au ralenti ...

J'avais noté de fort ralentissement sur émulateur dans le nouveau niveau. Il me restait malheureusement à constater que les ralentissement se produisent aussi sur la console, du moins pendant que les encriers projettent et si j'ai assomé beaucoup de dumbladors sans permettre à leur pieds de les rejoindre.

Slow downs are only fun when you control'm
The new level wasn't playing well on emulator. In fact, it was so slow (about 15 fps rather than 60) that I  could barely test it. I first thought my PC was unable to emulate it -- I had similar issues with e.g. Yoshi's Island DS when trying to get some snapshots. Running it on real hardware seemed to work fine until I started stunning bladors. With their feet as additional GOBs to animate, the system started to show slow downs occasionally (when jumping while inkjets throws drops). In my former level, I was 4 monsters, 16 drops and 14 feet under the threshold of what the 66MHz of the Nintendo DS can sustain.

Il y a 45 intervenants dans le nouveau niveau, dont 8 encriers et 7 dumbladors, soit un potentiel pour générer 30 objets de plus -- près du double. Oui, c'est risible comparé aux systèmes de particules qui peuvent tourner sur les PC moderne. Même pour 66MHz, ça ne devrait pas faire une telle différence. Mais voilà, à permettre aux gouttes d'encre de s'arrêter sur les éponges, à veiller à ce qu'un encrier puisse interrompre la marche d'un pendat ... bref, en ajoutant des interaction entre les ennemis et pas uniquement entre Bilou et ses ennemis, j'augmente les nombre de tests de collision, et il est possible que ce soit ce genre de chose qui fasse grimper la charge de calcul.

Is it the extra processing with of those monsters, with the animation parsing ? I could get up to 100 of them in Apple Assault, unless I try to make them react against each other (that would mean ~10000 collision checks). I do have some of those monster-to-monster tests, especially with ink droplets since I want them stopped by spongebops you carry along.
My plan so far to address this issue was to create sections of the game and to allow for collision testing only between objects belonging to the same section. Putting that into code lines didn't come out fluently, so I opted for the Commander-Keen inspired approach of freezing GOBs that are out of display range (that is, more than one screen away of what's on-screen). You can still try to collide against them when they're frozen, but *they* won't try to do anything. It was enough. It works well with the current game's flow. I'll revise it to something more generic later.


J'ai bien esquissé un système permettant de rassember les ennemis selon des sections, les collisions étant limitées entre personnages appartenant à une même section. Mais au moment de passer à l'implémentation, rien ne se combinait avec le code existant de façon souple. Je suis donc repassé à une technique plus traditionnelle -- le gel complet des personnages qui se retrouvent en-dehors de l'écran, qui était déjà à moitié implémenté (ils n'étaient plus traités par la couche graphique). Les listes à parcourir pour les collisions restent longues, mais c'est tolérable, d'autant qu'il y a moins de personnages qui provoquent des tests de collision. Et vu la constitution du code "GameObject::play", avec ses chaînes de contrôleurs et ses listes de commandes d'animation à interpréter, il n'est pas évident que la centaine de comparaison de coordonnées supplémentaire pèse tellement lourd par rapport à 5 objets supplémentaires à gérer entièrement.

There's an important effect of this mechanism. Yesterday, the position of a moving inkjet when you approach it depended on the time you took to reach it, from the start of the level. Today, it only depends on the speed you approached it for the last 2 screens. It will make learning of patterns easiers, as the level can be broken down into smaller chunks. It also means that the pattern of multiple GOBs (like two-inkjet-close-to-each-other) can now be manipulated by how you approach them... much like in Super Mario World.