cleaning up a git repository ...

That's just some misluck: your git push is taking ages to complete. By checking it out later on, you realise you have pushed videos that do not belong there. git rm Videos/* is merely placing a curtain over a broken window: videos are still in the repository, they still make any clone über-huge.
Take your TARDIS and go erase any evidence of your mistake before someone else clone your repository! But before doing that, a git pull is required so that you're sure you're operating on a fresh space-time.

gitk

with this tool, find the revision where your Videos come from. Then grab the commit-id (sha1 hash) of the commit just before. Let's say you messed up on commit deadbeef and that cafebabe was your commit just before.

the command we want to execute on every commit between cafebabe and now is

git rm --ignore-unmatch -f Videos/*

The way to travel through time on cafebabe..HEAD to enforce that is

git filter-branch --tree-filter "git rm --ignore-unmatch -f Videos/*" cafebabe..HEAD

I bet you want to update gitk's view and explore commits to check all signs of your videos are indeed gone. Good.

Now, let's really cover our tracks:

mv .git/refs/original /tmp/refs-original-git
git reflog expire --expire=now --all
git gc --prune=nowgit gc --prune=now --aggressive

If you were lucky and realised your mistake before the push, you're now done. If you had it pushed to the master repository, you still need to push these fixes ahead:

git push -f

And if you have a second clone of the master (at home?) where the videos still exist and that you want it as clean as the master,

git pull --rebase --verbose

(ooh, I wish so hard it had a "--dry-run" mode. Maybe you're better to clone your @home repository, and give the command a shot on the clone first so that you can check it has no undesired side-effects. The man pages claim that pull --rebase is potentially dangerous as it may affect your history. This is precisely what I want, but if for some reason your control on the master repository is weaker (i.e. someone else could alter its state between push -f and pull --rebase), you may want to follow the manpage advice and read git-rebase manpage first.)

Quelle taille de crayon ?

Once again, I'm stopped at a development cross-roads. Mostly due to IRL, admittedly, but stopped anyway. I decided to move back SEDS update to "not-a-priority" level as soon as I realised that I had no gameplay idea relying on slope angles variations in the school zone.
I have a "thread" of activity that insist on bringing life to the inkjet. Pixel art is ready, fundamental parts of the behaviour "should work", but it's not operational yet.

Par où continuer ? Les pentes supplémentaires, ce n'est pas franchement une priorité. J'ai bien progressé sur inkjet, j'ai du pixel art qui est prêt, mais ça chipotte un peu au niveau du GobScript. J'ai regardé de plus près le coup de la "corde qui pendouille" et couvert 2 ou 3 pages de formules et de schémas UML, mais pour le rendu, j'aurai certainement besoin du support 3D.

I invested some time into sorting out that "animated rope" thing, and I now have about 3 pages covered with UML diagrams, mathematicae formulae, code snippets and occasionally a gag featuring Bilou and Bouli. So the model and controller aspects are mostly solved. Yet, I haven't figured an obvious way to view the bookmarks that Bilou will hang on, so it starts depending on 3D layer as well, which in turn asks for pendats to come to live.

Alors, quitte à se taper la partie "3D", autant en profiter pour enfin amener le crayon-soldat sur le terrain, non ? Le hic c'est que mes dernières tentatives pour animer côte à côte Bilou et un de ces crayons n'ont pas franchement été convaincantes. Au point que j'hésite même sur la taille à donner au crayon. 40 pixels de haut, Bilou pourra sans trop de problèmes passer par-dessus. 48, c'est peut-être mieux, mais aussi peut-être trop haut pour les capacités actuelles de Bilou

So I converted gbatek into an epub and started studying the options offered by NDS 3D rendering yesterday evening. That opens the door to some pendats, the long-awaited monsters that took over the Owl School. Meanwhile, I did some 2D attempts to animate a pendat, both in AnimEDS and later in flipnote studio, and I realised that I had no clear idea of the size pendat should have compared to Bilou. So far, Bilou should be able to clear a 40-pixels-high ennemy with a regular jump, and I don't know about a 48-px one, especially one like the pendat who cannot be jumped on.

There are only few scenes in Bilou's Book where Bilou faces a pendat directly. And none (iirc) with the desired proportions, neither for Bilou nor for the pendat. Yet, sketches suggest that Pendat.height > 2 Bilou.height
Curieusement, je n'ai pas énormément de croquis de références. Dans tous, un pendat fait entre 2 et 3 Bilous de haut. Par contre, s'il est possible de passer par-dessus un pendat qui charge, mais de justesse, ce qui demande un timing quasi-parfait. L'idée étant évidemment d'encourager le joueur à se servir des dumbladors pour assommer les crayons ou de profiter d'un obstacle plus haut en bout de chemin de ronde.

Bref, le mieux, ce sera encore de faire le test: combien de fois parvenez vous à passer par-dessus le crayon, à gauche de la map avant de mourir (SchoolTest.nds)

In my design documents, I clearly want that it is possible to clear a jump over a charging pendat, but also that it is tricky to do, requiring near-perfect timing when on flat ground.

So let's try it out. Can we clear a jump over a 3-tile-high static pencil ? Is it interesting to have Bilou jumping slightly higher when he walks(/runs?) like in Super Mario Bros ? If so, is it interesting to have Bilou unable to jump over a pendat unless he walk-jump it ?

Swinging Ropes in Pharaohs Return

I love those "dark" places of the Web where you can hear about other people's pet project and see them progressing. I developed a particular sympathy towards Lazycow's "Pharaohs' Return" project, a revival of Pharaohs Curse with state-of-the-art C64 programming.

Il paraît que les forums, c'est la "matière noire" d'Internet. Obscure, insaisissable, insondable. L'antimatière d'un blog/wiki, en somme. Et pourtant, j'adore la façon dont on peut y rencontrer des gens qui ont des intérêts proches des miens. Par exemple, Lazycow nous prépare depuis fin Mai l'exhumation ultime pour "Pharaohs Curse". De nombreuses salles, des couleurs et des décors réalistes, une pléthore d'actions, d'items et des animations à couper le souffle.
Pour sûr, son projet n'a pas à rougir des dernières sorties homebrew sur cette machine telles que Get'em, Mayhem in Monsterland ou Soulless. Superpositions de sprites, reprogrammation à la volée pour doubler le nombre de sprites visibles à l'écran, mélange entre caractères monochrome et multicolores ... tout y est! Même les boss démesurés.

Mixing multicol and monochrome tiles, swapping the color registers on horizontal bands for larger color sets, doing the same with sprites to go way beyond the 8 sprites/screen original limit...  I like it. But what really baffled me was his animation for rope action.

Mais ce qui m'a le plus épaté, c'est cette animation que Lazycow a postée où son explorateur attrape une corde au vol. J'avais toujours classé ce genre de détails dans la catégorie "sympa, mais clairement pas prioritaire". Mais s'il le fait sur C64, je me dois de ne pas être en reste sur la DS, pas vrai ? Grimper aux signets des livres fait partie des éléments de level design que j'avais explorés au moment de reprendre le travail sur Bilou ... Difficile maintenant de me contenter d'un signet rigide même si celà faciliterait le développement.

Climbing on ropes wasn't that easy in the original game, and we used to make fun of friends as they were trying to do it with the joystick. Although functionally, the moving rope doesn't bring that much in terms of gameplay (given the limited angle it allows), it's one of those little details that makes a revamp look worth of it and show the love and care that the developer put in it.

When I asked Lazycow whether he had a tutorial on that, he keenly handed me the snippet of his source code that handles the rope action. I noted so far two sub-behaviours: the rope "above" the hanging character simply follows the shortest straight line between the hook and the hero.

for i=1 to heroheight:
    s[i]=i*herodelta/heroheight

The segments below try to align over the preceding segment with delta=s[i-1]-s[i], increasing the segment's speed so that it moves back towards the previous segment, then enforcing "integrity" of the rope by avoiding exagerated offset between segments.

Note that there's a small simplification here, as the rope doesn't shorten as it moves left or right. An alternative would be to assume that sin(x)=x and thus that it shortens by the amount it deviates from the straight vertical line (a fair estimate until you approach x=30°)

Gare aux taches d'encre ...

Au-delà des pentes plus ou moins pentues et des personnages en 3D, il y a un "monstre" supplémentaire qui attend de rejoindre la school zone et qui n'en est plus qu'à quelques pas: "inkjet", l'encrier tacheur.

Petit tour d'horizon sur la façon de le réaliser, à l'ancienne sur une feuille quadrillée avant d'aller dormir... Chose amusante, je me rends compte qu'en réalité les 2 formes d'encrier ("volant" ou "poussable") présentés ici pourraient très bien être 2 GOBs aux machines d'état totalement distinctes.

As the real life gets a bit more quiet, I managed to find half an hour with pencils and paper ... just enough to make a quick list of what should be done in order to bring inkjets to life. A first one would be "turn back" special blocks that floating inkjets use to change (progressively) their direction (as opposed to an "invisible wall" that would immediately stop the inkjet).

Parmi les "petits défis techniques" posés par Inkjet, j'ai recensé le "demi-tour de plate-forme mobile", nécessitant un contrôleur adapté.
Rien de particulier pour que Bilou puisse être transporté par un inkjet, en revanche: ce sera entièrement dans le code de Bilou que ça se passera.

As far as "carrying" is concerned, nothing special should be needed in inkjet.cmd file -- except a special flag assigned to some hitbox. Bilou's state machine is fully responsible of the additional "carried" state. What we might want is a "throw up" state that allows a hitbox to cancel the droplets generation, so that droplets are created *only* if no character was carried (and thrown up).

Envoyer Bilou en l'air s'il est présent et lancer des gouttes d'encre dans le cas contraire ? C'est possible. Il suffit d'une zone de collision associée à l'animation "projeter". Si elle rencontre un personnage compatible (transition "found"), elle interrompt l'animation (et le projette). Les gouttes d'encre ne seront générée que si l'animation prend fin naturellement (transition "done" dans ma machine d'état).

Interestingly enough, all this is independent to what would happen to the "standing" inkjet (on the ground) and the transitions used to allow it to be pushed by Bilou.

Pour l'encrier au sol, je devrai procéder en 2 temps. Tout d'abord, m'assurer qu'il est effectivement "solide" pour les marcheurs, qui fasse faire demi-tour aux dumbladors et force Bilou à passer en mode "pousser".

Ensuite seulement, une 2eme collision dans le sens inverse force l'encrier à se déplacer.

Bon, là-dessus, je vais m'installer pépère dans un fauteuil et faire quelques petites animations supplémentaires dans SEDS...

Checklist:

• [check] special block digits are read horizontally first, then vertically
• [oops!] 1xxx is for "interacts with monsters" "interacts also with monsters", 2xxx is for "doesn't trash graphics while removing properties" "doesn't disappear when touched", but we could use "on hit [0] ()" in block description to prevent it.
• [oops!] "block 1002 {" effectively encode properties of block using digits 1,0,0,2 on the level editor and not some other funny 0x1002 value that wouldn't make sense. (block 82 is required.)
• [ok] states doesn't prevent collisions to be detected.
• [fixed] decrease controller can cannot be used as expected.
• [bugfix] GameScript::content() should allow \t tabulations in cmd files.

Rope it up!

Paul's tutorial on ladders was on my "readme" list for the Cybook last night. I liked how he motivated them as a way to introduce discontinuity in control mechanics and physics response. It sounded "Eureka" in my mind and I wanted to go further, so I asked Bilou and Bouli to illustrate the other concepts of the article.

In my game engine, such discontinuity can be handled naturally as I can attach different control chains to the different player states.
(Note that I will consider that ropes are just an visual alternative to ladders, that do not bring significant gameplay difference -- i.e. you can't swing ropes yet).

J'aime beaucoup la façon dont Paul Firth introduit les échelles dans son tutoriel. "Rompre la continuité du gameplay". Forcer le joueur à utiliser temporairement d'autres règles de déplacement que celles du platformer, et donc l'obliger à se défaire d'une part de son "confort" de marcheur. Rien à voir, donc, avec le grillage ou Mario se déplace librement dans le château d'Iggy.
La bonne nouvelle, c'est que ce genre de dualité est parfaitement prévue dans mon modèle de "machine d'états" pour la gestion des personnages. Pas besoin, donc, de rajouter des booléens dans tous les sens et des tests tous côtés.

En outre, dans un niveau largement fourni en "plateformes à sens unique" (p.ex. un empilement de livres ;), les cordes et échelles peuvent aussi être un moyen d'offrir localement au joueur la possibilité d'aller "à contre courant". Une seconde bonne raison de ne pas se contenter du moteur de jeu actuel, donc.

Another think that ladders/ropes bring is that they introduce platforms that can be "climbed down". Platforms that let you jump through but not fall through is pretty common in platformers, and they let you build levels where the player is denied to move backwards. A rope is an escape path in that way.

Now let's move to the technical part. The walk/climb transition is not so obvious to set. In Paul's approach, it involved the introduction of several sub-states and sub-tiles type to be processed properly. This is typically the kind of thing that I've learned to be bug-prone and that rather quickly limits the addition of new mechanics to your character.

Ideally, it must be possible to let the game engine align the character to the rope/ladder so that climbing animation works. As mentioned in a former post, this require the combination of the cando(F_LADDER) property on the tiles occupied by the character and dpad&KEY_UP guardian expression.

Il me faut donc un "micro-contrôleur" de personnage capable de s'aligner sur une échelle (align_flag), un capable de créer un évènement lorsque le personnage passe à un endroit où un nouveau mouvement est possible (detect_flag), et évidemment, un comportement pour monter/descendre à l'échelle. Le reste n'est plus qu'affaire de mettre le bon contrôleur au bon endroit, et à filtrer les évènement générés par detect_flag en fonction de la direction prise par le joueur.

It may also happen that you insist on your player to release DPAD left/right before he can climb. This is more likely to be the case to climb down: pressing DOWN will first force Bilou to duck. Only in that "duck" state, we check for ladders. The "align-to-[F_LADDER]" behaviour controller can then be affected to the "getting down" non-cancellable animation.

More slopes

J'ai envie d'avoir plus de souplesse dans les pentes que juste "45° dans quel sens?". Si ça n'apporte pas grand-chose au niveau du gameplay en tant que tel (un ennemi-marcheur en haut d'une pente garde un avantage stratégique même pour d'autres formes de pentes), ça permet de construire des niveaux plus "organiques", ce qui n'est déjà pas si mal.

I deliberately picked a side item that should somewhat be less braintensive to work on as Lil'son is now released. In clear, something that can take place in a FridayAfternoon branch. So let's see how we could introduce more slope angles (and shapes) in my game engine. I assume that most of these "extra slopes" will be designed in larger chunks of 64 pixel wide, like a staircase, a curved hill top or a pair of 22.5° slopes. 

En revanche, j'ai déjà saturé le nombre de "type de blocs" dont je dispose vu ma technique d'encodage. L'idée cette fois serait de combiner le "type" (encodé par élément 8x8) avec la position du tile au sein d'un bloc de 64x16. Si ça reste jouable au niveau du moteur de jeu, ça demande un support spécifique dans l'éditeur de sprite pour "préparer" ces blocs de 64x16 contenant 16 tiles alloués de manière contigüe dans la SpriteRam (alors qu'ils sont normalement alloués par bloc de 4) puis de les disposer conformément à ce qui est prévu pour un des type d'obstacles souhaités.
You may remember that I have 16 major tiles types, which can be freely assigned to any tile. This "chunking" is thus actually required so that we can use the offset of tiles within a chunk as an additional clue of "which sub-type of slope" we're walking on (and eventually convert that into the appropriate height array in the engine's data. No real difficulty is expected from the game engine code, but it requires that we can alter tiles arrangement in the sprite editors so that the "curved hill" uses appropriate tile numbers. Some UML/C++ joy expected ahead. One that really insists on implementing a SMW clone could rather use "gradual" (11.25) slopes rather than those curves.

En comparaison, le moteur de SMW (selon Lunar Magic) offre 3 angles de pente: 'normal' (22.5), 'gradual' (11.) et 'steep' (45). Au niveau du gameplay, les pentes 'steep' étaient les seules à pousser d'office le joueur vers le bas (si ma mémoire est bonne).

Bon, je sais, ce n'est sans doute pas ultra-prioritaire pour faire avancer Bilou, mais mon petit J.l.n est né vendredi dernier, ce qui réduit un peu ma liberté d'action. Un peu de bidouille dans les éditeurs devrait donc être plus aisé que d'aller créer du code pour de nouvelles interactions avec Inkjet.

Setting the bar

It's a secret to everybody: I follow the blog of Frogatto & Friends. I think the project has a high potential and is technically well-done. Their editors are truly impressive, for instance. Yet, I'd love to drive my own theses on game engine design to their conclusion, so I keep working on my own approach.

When I stumbled upon a post entitled "Platformer Enemy Design" in the newsfeed, right after I had crafted the "monster design book" out of this blog, I felt like a kid getting his Christmas present. Yet, the content was pretty far away from what I expected! The post is actually more like a call for rationale development applied to people who code monsters behaviour for games.

Juste comme je finissais le post sur les versions papier de "level design" et "monster design", je tombe sur un article d'un des auteurs de "frogatto & friends" (excellent petit jeu indie et open-source) intitulé "design des ennemis dans un jeu de plate-forme"... qui s'avère être très différent de ce à quoi je m'attendais, mais très intéressant malgré tout. Jetrel y présente une série de "pièges" dans lesquels un développeur de jeu peut tomber (liés à la conception des ennemis)  et qui pourrait retarder indéfiniment sa "sortie".

Consider making a flying enemy with basic behavior that makes it fly from one X position, to another X position. In a generous, open space with no terrain in the way, writing this is trivial; [...] It seems reasonable, from a level-designer’s standpoint, that it should always work regardless of the layout; [...] So if you put it in a twisting corridor, it’ll naturally duck under the outcrops, and rise over ridges to find a path back and forth. Except actually it won’t, because [...] there is no pathfinding. There’s no AI; there’s just one, single line of code with two conditionals in it.

What Jetrel calls for, is for people like me to admit that there's little value for a "magical monster that will always behave as a (hypothetical) third-party level designer could want it to behave". Instead, if you have a monster that works well in some type of terrain/environment - which is *the* type of terrain you intend for the level you want to place the monster in, it's perfectly fine. Noone would expect a paratroopa to work correctly in an underwater level, anyway.

Le premier conseil est une variation sur le thème (célèbre) "Keep it Simplest, but not Simpler": faire le plus simple possible, mais pas plus simple que ça. En particulier, s'évertuer à créer des monstres qui se comportent *toujours* correctement, quelque soit l'environnement, est inutile. Ce qui est important, c'est qu'il se comporte correctement *dans le type de niveau pour lequel il a été conçu*. Si la BerryBat est prévu pour poursuivre Bilou dans des cavernes, il se peut très bien qu'il ne fonctionne pas à l'intérieur de la pyramide (plus labyrinthique) parce qu'elle se cogne systématiquement au murs. Inutile aussi de prévoir que Funky Funghi doive "mourir" s'il tombe dans l'encre de la SchoolZone: il n'y a pas d'encre dans son environnement. Dans le même ordre d'idées, les Applemen qui se croisent ne posent pas de problèmes dans un niveau "à la Mario", même s'ils provoquent des problèmes de clarté dans Apple Assault.

When I was implementing Dumblador's wandering lone feet, last month, I encountered that very kind of situation. Making the feet move back *to the blador* in all circumstances quickly proved totally un-obvious. It would have required them to move at ludicrous speeds here, making jumps that even Bilou can't deal there, etc. But in practice, I don't necessarily want bladors to recover *at all costs*. What I do want, is that blador recovers with variable time depending on the terrain style ("hill"-like or "hole"-like) when the player takes too much time to grab it. It's fun if it recover even though you thrown it to the next book, but it's in no way mandatory.

There is however one key element that I want to bring into Bilou's gameplay, which is the suspension created by allowing monsters to be thrown away from their original location or have their path blocked by some other items (i.e. drop an inkjet on a pendat's pathway). That both rules out the simple "follow design path" approach used in RSD game-maker and the "level encodes where the path ends" used for some Keen monsters and in "The Game Factory" engine. That doesn't mean I need super-smart monsters that can climb up locations and track Bilou, but they definitely need some sort of state machine and level features detection so that they can have sufficient amount of autonomy.

Ce qui est amusant, c'est que les pieds baladeurs de Dumblador ont justement posé des questions de ce genre il y a un mois. Je les avais codé initialement pour qu'il puissent franchir *n'importe quel* obstacle (quelque soit sa hauteur) en les faisant sauter de plus en plus haut. Au final, ils étaient tout simplement incontrôlables et finissaient par sauter tellement haut qu'ils ne parvenaient de toutes façons pas à franchir l'obstacle en question. Dans la démo de nouvel an, les pieds *escaladent* les obstacles plutôt que de chercher à sauter par-dessus. Ça me convient. Il y aura des situations dans lesquels un Dumblador assomé ne pourra pas récupérer ses pieds (en particulier si Bilou l'emporte avec lui), mais il existera aussi des dispositions de niveau dans lesquelles j'obtiens l'effet désiré: un ennemi qui prend plus ou moins de temps à récupérer selon la situation dans le niveau (autorisant des stratégies du genre "j'attends qu'il soit au bord pour l'assomer) tout en offrant un retour visuel sur le temps qu'il reste pour s'en saisir.

J'admets qu'il faudra que je garde le conseil à l'esprit et que j'en fasse une ligne de conduite, parce que j'ai une tendance naturelle à résoudre des problèmes larges. La façon dont les ennemis "marcheurs" de Bilou décident de faire ou non demi-tour en est un exemple, mais je ne saurais me résoudre à une approche "dessinée" du trajet suivi par les monstres (cf. RSD Game-Maker), car j'ai déjà pu me rendre compte à l'époque que les types d'interactions que je souhaite apparaître au coeur du gameplay (interrompre le chemin de ronde d'un pendat en faisant tomber un inkjet, par exemple)

If you do a boatload of work on an enemy to make it work in different situations, but the basic decisions the player faces are still the same, you’ve wasted your time. The basic gameplay is still the same; you’re just jumping through hoops to provide it.

Which I translate in "no matter how smart that inkjet is when it shoots at you: if you can dodge its balls just by jumping anyway, you have changed nothing". I think this is deeply connected to interplay. I'll have to push more thought into that part.

Il y a d'autres choses intéressantes dans cet article, mais là, ça fait 3 fois que ma fée me demande l'heure en 30 minutes, donc je vais lacher un peu mon clavier ...