When ID software is keen to hide ...

There's an interesting thing with this "tunnel" level of Keen Commander V, that reveals the way ID software did conceived secret passages as rewards for exploration to players. Exploration is a key part of Keen games: you're not supposed to zoom through levels, as many keys and doors will require you to take detours. In small corners, you might find hidden by-passes and hidden bonuses (like just above the blue rays on 1st figure). But here, they did a different approach. A huge, black door teases the player. You see there's something there, but how to get in ? is that supposed to be input or output ? It's a miracle you've got the time to think about that just after you avoided being zapped by Robo Red ! But no matter how hard you may try to get in, you're not in the right place yet (level is played right-to-left here).

C'est une idée intéressante qu'ID software a utilisé dans ce niveau de Keen5.exe : au début du niveau apparaît une porte mystérieuse -- une chose assez peu courante, dans les Keen. Apparemment, aucun moyen de l'atteindre. Et tout autour, c'est assez dangereux de traîner, avec Robo Red et tout ces shelleys ...

So good luck. Keep going. If you feel like exploring again when approaching the door from the left somewhat later, beware the smart bomb that will jump off the platform (oh ... just like an Appleman ? ... no: this one means death-on-contact and explodes into deathly bits when it hits the ground). Do you feel like rushing instead ? too bad: you're actually missing the entry to something ... you don't know what yet.

Only when approaching the exit door, you'll be shown what you've missed: a 1-UP. A pretty precious thing in Keen, but no: hollow walls around only give you a few bonuses. Will you head back for the hidden door and search more ? Or will you save the current life and exit ?

Ce n'est qu'à la fin du niveau que le joueur aura le fin mot de l'histoire: une vie, bien visible mais inaccessible. Ding, le franc tombe. Le joueur qui avait jeté l'éponge va sans doute retourner en arrière pour parvenir à atteindre la 1ere porte. Je pense, ceci dit, que Tom Hall aurait pu faire encore mieux. Primo, une seule porte, dans un niveau qui n'en contient aucune c'est louche. D'autant qu'il n'y a rien d'autre que la porte à cet endroit. Quelques gros bonus auraient pu faire croire au joueur que c'est une arrivée, pas un départ. Deuxio, il n'y a finalement pas de grand challenge à repartir en arrière, à ce stade, la plupart des dangers étant situés dans des embranchements latéraux ... ou ont été éliminés lors du 1er passage.

That's where imho the design becomes a bit weak. I'd have personally ensure that there is a significant risk in back-tracking to the access door ... Something like Robo Red, moving spikes, or a combination of shooting lasers and moving platforms (since normal monsters do not respawn in Keen). The only challenge here is a set of shooting lasers, but on solid ground, so you can move through that without too much trouble.

Voilà. Bon anniversaire, Piet ;)

Unclump'm

Well, I've been using AppleAssault as a regression test when developing the new collision engine ... really just to make sure I'm not broking everything up, as there's nothing in AppleAssault that could benefit from the new engine, anyway. No pushable/carriable ennemies, no platforms. Nothing.

But of course, being in that source tree again (^_^), I wanted to give some ideas a try. The first one was to integrate berrybats in the game, as a way to force the player to focus on defeating applemen, and not just hop around. It now acts like a sort of indirect timer, appearing when you've been unfocused for too long... and appearing again and again until the lesson has been learnt :)
I'll need to work on the timing, though, so that the game doesn't become completely unfair :P

Un nouveau moteur de collision, c'est pas rien. Alors j'utilise AppleAssault pour m'assurer que tout fonctionne toujours bien au fil des modifications, même si la plupart des améliorations (pousser, ramasser, etc) ne sont pas à l'ordre du jour pour ce jeu précis. Mais, vous me connaissez: à trainer dans le code, j'en viens à me dire qu'on pourrait utiliser les chauve-souris pour forcer le joueur à s'attaquer au pommes ...

Un autre point, plus délicat, c'est de faire en sorte que les pommes cessent de se coller les unes aux autres. KirbyKid a raison là-dessus: ça pousse le non-réalisme vraiment trop loin. Je ne veux pas non plus en venir à un comportement de type goomba: il est prévu que les Applemen puissent se croiser s'ils arrivent en face l'un de l'autre, mais on ne devrait pas pouvoir en avoir 10 sur 2 pixels. Il me faut donc un test de collision entre-applemen, mais je vais devoir être prudent si je ne veux pas me retrouver avec des centaines de tests inutiles et vider la batterie de la DS en un rien de temps.

The second thing is linked to Kirby Kid's comments: Applemen tend to stick to each others, overcrowding on platforms, which isn't very realistic. I don't want to go for goombas-like behaviour: Applemen are design to be able to cross each other. Still, there shouldn't be 10 of them on 2 pixels. So I need to have a sort of applemen/applemen collision detection, but that should be handled with care, otherwise I could easily overload the collision engine with hundreds of (unnecessary) checks and dry the DS batteries in no time.

The approach I picked is to take advantage of a small transient state where the Applemen halts in front of a cliff, checking whether it will jump -- which you'd barely notice when playing the game. Only during these 2 frames, it actively checks for other Applemen in its immediate neighbourhood, and get "knocked out" of the platform if there was. Expect a revised .nds file to download in early February, as now, I still need to remove a *lot* of debugging printf ... and have a shower...
Oh, and some coffee would be nice as well... And a commit :) Cheers :)

Mais il y a dans la machine d'état de l'appleman un petit délai où il fait une pause en bout de plate-forme pour décider s'il va sauter ou non. ça pourrait être le bon moment pour tester s'il y a un autre appleman dans les alentours et se faire "éjecter" de la plate-forme si c'est le cas. On va tenter de vous permettre de télécharger ça début février, mais avant ça, j'ai une tonne de printf à retirer ^^"

Dans le temple perdu

Un temple, quasi-inaccessible, témoin d'une civilisation disparue ... un endroit imprégné de mystères et de questions sans réponses. Depuis que mon frère a composé le thème "Maya Zone" pour "Logic Labyrinth II", je brûle d'en faire un niveau de jeu vidéo. Du coup, je le remets sur la carte en reprenant le synopsys de Bilou en main.

Oui, mais le temple de quoi ? et qu'y affronte-t'on. Le premier point détermine le look à donner au niveau ... le 2eme conditionne le gameplay et l'esprit du niveau.

Le déclic, ça a été d'y implanter les lianes de la forêt. Des berrybats dans le temple perdu ...

I think I at last managed to turn the two words "lost temple" into some interesting and original design idea for both monsters and area look. I have studied art of Rayman and Shantae closer, sketching some original derivative here and there, keeping them secret until I'd have something coherent -- although it isn't pixel art and certainly not a playable demo yet. But let's face it: how would a playable demo "protect" my idea better than a sketch ? It's not like I was trying to win a race with a competitor here, not willing to let X know what I'm doing. Sure, I don't want the idea to be ripped, but I can't prevent someone else to do the same. So I bet my best defence is to do it publicly.

But anyway, just look at that "golem" thingy, animated by the berrybats vines (with berries too young to turn bats :) -- *that* will put you into trouble when you'll play the level ... well, if you manage to find the level in the final game, because it's not called "lost" temple in vain. Trust me: I won't reveal you the slightest bit of information on how you'll get there.
Allez, encore un petit effort. Des berrybats, oui, mais pas tout seul. Et si ... et si les lianes vivantes s'emparaient (au sens propre) des ruines du temple pour construire un golem géant ...

Là, je tiens mon idée de design. Le truc inédit, qui donne une identité propre par rapport à Lost Vickings, Rick Dangerous, Sonic et même Rayman. Alors je le poste, pour marquer l'antériorité. Voilà. C'est mon idée, j'en suis fier. Elle s'appuie sur 3 ans de marquage de favoris dans DeviantArt sans pour autant copier un design de quelqu'un d'autre, je pense. L'imagination est notre ultime frontière. Voici pour vous une planète supplémentaire, aux portes de l'inconnu pour vous lancer à votre tour dans les confins inexplorés de l'imaginaire vierge. Have fun.

(merci à Cyril et son Sony pour les photos, parce que j'aurais jamais trouvé le temps de scanner ça avant ... houuu ... le surlendemain de la St-Valentin ?)

all rights reserved.

C'est ça, être branché.

Dans le monde de Bilou, le tileset et ses habitants vivent en paix. Le GameEngine maintient l'équilibre et l'harmonie de ce monde. Désolé, les amis. Apparemment, ça ne va pas durer...

Car, un funeste jour, l'horrible Mr. Pype bidouille le GameEngine et neutralise les pouvoirs du Makefile qui cherchait à le recompiler! Les GobStates, qui gravitaient autour de l'Engine perdent soudain leur stabilité naturelle ... et s'éparpillent dans tout l'disque dur! Préoccupant, non ?
Et en plus, ça fait désordre.

Dans ce monde à présent déséquilibré, d'étrange phénomènes se produisent ... des Applemen hostiles apparaissent plus vite que prévu, et quand on essaie de les assomer, ils se téléportent sur la gauche avant de revenir à la charge de plus belle ... non sans s'être momentanément transmuté en BerryBat ou en buisson ...

Remember when everything in Bilou's world was messed up to the point that Bilou turned into a jumping bush wandering around bubble-headed-trees? Well, with the regression test I applied to AppleAssault with the game-engine modification that are supposed to bring in compound animation, it appeared again. Applemen being flooded over the level rather than appearing progressively, they'd also stay stunned for much shorter and show some odd "side-effects", such as temporarily turning into berry bat on wake-up and even sometimes "teleporting" to the left while being pwned.

I had just introduced CommonGob, that captures the GobState management, including the reaction to an event (evaluating expressions, and so on), while the animation itself is still manipulated by SimpleGob (now a class deriving from CommonGob). It took me a couple of fixes to separate them right while still having the animation restarted from scratch when we switch states (and some more tests to handle the state3->state3 case). It would have been a mere lunchtime debugging session not worth mention if GDB hadn't decide to black-hole the SimpleGob class. No line numbers, no breakpoint, no variable or structure interpretation. Nothing but instruction stepping and register values >_<. I still haven't found out why, but I fixed the code nonetheless.

Bref, on aurait bien voulu appeler DDD à la rescousse, mais pas de chance: il ne parvient plus à interpréter une partie des annotations qui accompagnent les quelques classes maîtresses ... plus de visualisation des objets, plus de suivi des instructions ligne-par-ligne ... rien. sauf dans objdump. A en perdre son latin.

Picking a Tile size.

Reading further through the Sonic Physics Guide, I noted that the collision mechanisms used (two "vertical sensing bars" for each feat and one "horizontal sensing bar") calls for a certain ratio between the character's collision box and the tile size. The rule is simple: your character should be able to stand on a single tile, and it should also be able to fall into a hole that's one tile wide only.

Another observation is that Sonic is 2 tiles high, which makes it more convenient to push items, but which also makes the 1-tile-high obstacle more convincing. Let's think about it this way: if there was a boulder that's half your size high (let's say almost up to your belt), would you have to do a special action (e.g. jump) to go over it? How about an obstacle that comes only up to your knees ? And halfway on your tights ?

My feeling is that, visually, an obstacle that's only coming up to your knees can be simply stepped on. Something that comes up to your belt is a real barrier. That's what a tile should be.

And well, unfortunately, Bilou isn't quite following those guidelines so far, but Bilou is quite far away from the Vitruvian Man (despite equally being an alien ;-)

2 tiles de haut contre 1 de large. Pour un personnage bipède, c'est l'idéal, si je tire les conclusions qui s'imposent de la lecture du Sonic Physics Guide. Attention, je parle ici de la zone de collision. À aucun moment celà n'implique que l'on doive caser tous ses dessins dans un rectangle de 20x40 comme dans le RSD game-maker, hein ?

En revanche, il est indispensable que le personnage puisse "tenir debout" sur un élément constitué d'un seul "tile" sans que ça ne paraisse bizarre au joueur. Idéalement, il devrait aussi pouvoir tomber dans un trou qui ne fait qu'un seul tile de large.

Difficile de dire si c'est le cas ou non pour Bilou, par contre. Ok, il est loin d'avoir les proportions de l'homme de Vitruve, et sera plus proche de 16x24 pixels dans la school zone qu'autre chose. Difficile aussi de lui appliquer la règle "un obstacle doit plus ou moins arriver à la ceinture pour avoir l'air un rien costaud"... Mais je garde ça en tête pour la révision de Badman...

(ces 2 croquis Biloupométriques datent de 2005, quand je m'étais mis en tête de faire une version 3D de la school zone en utilisant OGRE ... et que je me suis rendu compte que je ne parvenais plus à dessiner un Bilou correct qu'une fois sur 4 :P)

Countless Great Designs

Petite pépite que je renseigne à l'intention d'armitage, en espérant qu'il trouve souvent ce qu'il cherche quand ses scéances de google le font atterir sur la planète Bilou: le générateur ultime d'entropie ... le test de Rorschack (toute ressemblance avec un nom existant est un pur coup de bol ;) version Pixel art.

Trouvé sur wayofthepixel, bien sûr ... mais où, ça ...

I have to call for your scientific forgiveness, although I find myself unable to \cite{my-sources} correctly this time. It's just a too marvellous tool that was presented on wayofthepixel. I just can't let it rest in the shadow for longer: behold the Rorschak test for pixel artists ... the ultimate inspiration generator that randomly fills a sprite sheet with monocrhomatic (and usually symmetric) pixels. What you see in here will only depend on who you are. I do see countless great design, and also a first step towards space-invaders-meeting-netcraft ^_^

And if you still don't see anything, click the picture and you'll get another sheet for you to play.

branch/companim

Rien de tel qu'un peu d'UML pour commencer la nouvelle branche du SVN "animation composée" (imho). Ah, mais peut-être voulez-vous un mot d'explication sur les "branches"? C'est l'équivalent pour un programmeur de "Dis, on va commencer par dupliquer la maison dans un univers parallèle avant d'attaquer les travaux pour la véranda. Comme ça, si on doit chercher les clés à un moment donné, on a qu'à le faire dans la copie de base. Et puis on peut laisser les enfants dormir dans celle-là, aussi: inutile de les envoyer dans la copie où on a abattu le mur du salon et où l'eau ne va plus jusqu'aux WC, hein ?"

Convaincus ?

I was quite confuse on where to start working on the compound anim support, so I just started by depicting the current situation into an UML blueprint, trying to precise which are the different phases of SimpleGob::play, which member variables where involved when, and where in the class hierarchy they stand. Part of my indecision came from the fact that the abstract class GameObject is designed to capture what controllers use, so I wasn't quite tempted to push up the state management there.

And to my suprise, that alone suffice to show me the right path to take: introduce a CommonGob class that capture what's not-in-GameObject but should be in all the technical variation of the animated objects.

Bon, première tâche dans cette branche, donc, c'est de refaire un peu l'état des lieux. Une animation composée, ça change essentiellement l'animation des GOBs, mais l'état, les contrôleurs, les collisions, tout ça reste identique. Ouais, sauf que jusqu'ici, tout ça est uniquement dans SimpleGob.

Une fois tout à plat sur ce joli "bluescreen" (excusez ma nostalgie d'ex-codeur en QuickBasic), la solution devient évidente: introduire une classe "CommonGob" qui regroupe tout ce dont SimpleGob et CompoundGob auront besoin dans leur fonctions "play" sans toucher au GameObject héréditaire endogène ... ce qui fera sans doute plaisir à BlockArea, accessoirement.

If you don't get a word of UML then ... well ... I guess the sketched-up version of a former, similar reflexion might help you to figure out what is this CompoundGob stuff all about.

Pendant ce temps, dans le code ...

Oh, pas de soucis: je n'oublie pas Bilou, malgré tout cet intérêt renouvelé pour mon perso Ubisoft favori... Mais comme les études de Rayman et de Shantae ont pour objectif de construire le synopsys lointain, comprenez que je garde ça "en réserve" pour plus tard... Il faut quand-même bien que vous ayez le plaisir de la découverte quand je vous proposerai 4 écrans par monde dans nuts'n'bolts, hein :)

Don't worry: I keep working on Bilou, even though it's sort of top-secret sketching of distant scenario ideas for whatever will happen beyond the green & school zones you already know. I'll start working on the integration of animations edited with AnimEDS into the game engine. Please allow me to keep my todo-list in French only and focus back to my soup now :P

Entre-temps, il va falloir que je voie à intégrer les animations complexes générées par AnimEDS dans le moteur de jeu, sinon, c'est moins rigolo :P

• le GameScript pourra se servir des informations de anim[i] pour décider de créer un SimpleGob ou un CompoundGob (j'ai déjà une super-classe, ici)
• pas de bloc "anim%u %x { ... }" pour les animations composée, donc pas d'appel à parse(). Je pourrais soit détourner "state%u :anim%u { ... }" avec "state%u :spr%.anim%", soit pré-déclarer les animations "anim%u = spr%.%" -- l'idée étant d'autoriser des "pages d'animations" et d'avoir de préférence une page par fichier de commande.
• j'ai des commandes générales et des commandes "d'affichage" dans les anims. Est-ce que ça vaut la peine d'essayer de ne conserver qu'une seule copie des commandes générales ?
• Dès que je vais vouloir utiliser des déplacements automatiques, il me faudra de l'état par composant, ce qui rend moins attirant l'inclusion du code qui gère case ANIM_SET_SPR au sein de GobAnim ...
  

Origins band land

"Je suis arrivé au 2eme monde: la musique" me dit mon frère. Il venait de lire mon éloge du premier monde de Rayman Origins, mais il était un peu déçu par ce nouveau monde "c'est tout creux, vide quoi. Un peu mort aussi". Je souris: je viens de refaire le "Band Land" du Rayman d'origine, "Band Land" signifiant à la fois le pays des groupes (de rock/jazz) avec un jeu de mot sur "Bad Lands", les terres arides et rocailleuses ... Mais une fois la manette en main, je dois bien reconnaître qu'il n'a pas tort: les mêmes instruments tordus encore et encore, quelques tambours-tremplins ...

Il faut dire que le 1er monde avait placé la barre assez haut. Retournons voir les images trouvées ça et là sur Internet ...

Non seulement c'est beau et détaillé, mais un plus, c'est particulièrement varié. On passe, l'espace de quelques niveaux, d'une forêt sombre et dense à une caverne moussue, puis une sorte de plage avant de partir à l'assaut des montagnes. Rien de ce genre (ou presque) dans le niveau musical. L'action a beau être variée, le niveau "des angry birds" reste un monologue visuel. Même dans les passages secrets où l'on délivre les électoons, on reste en environnement ouverts (moi, j'aurais bien vu ça à l'intérieur d'un tambour ou d'un saxophone :P).

Mais entre les câbles électriques, le planage le long des mélodies et les niveaux venteux, on ne s'ennuie pas jusqu'au monde des desserts glacés, qui -- je l'espère -- nous remettra une deuxième claque graphique pour enfoncer le clou ;)

Evidemment, dans Rayman version PSX, on a pas du tout cette idée de "désert" pour la zone musicale, vu qu'il était conçu comme "Ciel Chromatique" par une équipe franchement francophone.

The Art of Rayman

So I've got new Copic markers and a freshly downloaded Rayman for DSi. Neat. Just what I need to do some graphics analysis the same way I did for Shantae, although it's clearly non-pixel-art, but rather converted and carefully fixed painting.

Armé de mes Copic et de ma DSi sur laquelle j'ai fraîchement installé le Rayman de mon adolescence, j'entamme le même genre d'analyse du graphisme du jeu que ce que j'ai fait pour Shantae. Bon, évidemment, le graphisme de Rayman est en grande partie de la peinture retouchée, et pas du Pixel Art, donc je ne sais pas en tirer le même genre d'enseignements ... n'empèche...

C'est étonnant de voir qu'il n'y a plus ou moins aucun arbre "normal" dans tout le premier monde. Des troncs-champignon, ça oui. Avec même des "mains" qui vous supportent. Pourtant, les couleurs et la texture sont celles du bois, et donc, on voit du bois.

Étonné, aussi, de voir que certains éléments de décor peuvent être allongés ou raccourci, malgré leur complexité. Chapeau! Les troncs couchés et les "palmiers", notamment. Il est rare d'avoir un même objet de grande taille plus de 2 fois dans un seul niveau, mais par contre, beaucoup moins rare d'avoir un objet repris à moitié découpé sur le bord de l'écran en début ou fin de niveau, où l'impression de "copié-collé" sera moins forte.

Autre grosse différence avec ma "green zone": Pas de terre dans la forêt primordiale de Rayman. Des cailloux, oui. Des entrelacs super-serrés de lianes, aussi. Mais de la terre, schnoll. Nada.

Pour pouvoir construire leurs niveaux, les p'tits gars d'Ubisoft n'ont pas hésité à utiliser un truc courant (mais souvent mal utilisé) chez les pixel artists: le contre-jour. En-dehors des pierres détaillés, certaines zones plus sombres sont tout simplement d'une couleur unie, souvent au bord des zones.

Each level in the Dream Forest features one or two "large background element" that gives it a unique style compared to the generic "green & rocks & water" template that has been seen in so many games. Some of them are interactive (mushroom trees), other are purely decorative. It's rare to see them repeated more than twice in a single level, but it's frequent to see them repeated (but only partially) near the begin or the end of the level.

It's also surprising to see that, despite the "wooden" colours and textures of some components, we never see a real "tree" in the foreground in that forest. Are these vegetal tentacles ? Are these mushrooms-on-branches ? It's just some fantasy. Rayman Origins is much more conventional, to that regards.

Another impressive thing: the way the artists managed to create variations of some relatively complex element. That's especially visible with that sort of "palmtree" seen during the "bzzit fight". Here, they strip a part of the full-size tree. There, they duplicate a part to extend it. Simply thanks to a bumpy detail that makes the seamless connections possible. Well done, dudes.

PS: thanks fly to the maintainers of the raywiki: some of the screenshots they have were quite useful.

Climb up, and start the ro .. nevermind.

Voilà bien le genre de "mini-cave" cachée dans le monde de Shantae qui m'aura fait souffrir ... (et qui renforce mon impression que le jeu tient presqu'autant du "zelda" que d'un jeu de plate-forme classique, au passage). Pourquoi ? parce qu'il va falloir sauter de chaîne en chaîne jusqu'au coffre ... et retour. Et assez curieusement, dans Shantae, s'accrocher à une "corde" verticale en cours de saut est assez délicat.

Grab a "rope", climb up, hop, grab the next rope, climb down a bit, hop, grab, hop, grab, climb ... This is sure nothing new. I think even Pharaoh's curse had a screen that was designed along that rule. And you'll sure face it a couple of time in the armaggedon machine as well. So why is it so tedious to perform it right here ?

Pour s'accrocher, il faudra que le joueur presse le DPAD en direction "haut" pendant qu'il saute (vers l'avant, de préférence). Et on dirait bien que sur la DSi, ce genre de manipulation est assez peu pratique. On passe un tout petit peu trop facilement de la diagonale "haut-droite" à la position "juste vers le haut", auquel cas Shantae s'immobilise presqu'immédiatement et tombe si le joueur n'a pas bien estimé la largeur de la zone de collision de la chaîne.

Well, first, I'm playing Shantae on the DSi, with a DPAD, while I mostly grow my platforming skills with a keyboard, where there's no such thing like a "diagonal" position. And apparently, holding the DPAD in a diagonal position is not so easy. As Shantae quickly loses her horizontal velocity if you release the "right" direction in-air, you're better have a very precise understanding of how wide the collision area for those "ropes" is, or you might end up to instruct the game to "climb" when that cannot be done (not yet), and just start falling where you are. I'll have to keep that in mind when I'll implement vines-climbing in Bilou.

Keen demande lui aussi que l'on presse vers le haut pour s'accrocher aux "barres verticales". Mais ayant majoritairement joué sur clavier, ça ne me posait aucun problème.

edit: Super Princess Peach, de son côté, à une étape d'alignement aux échelles bien visibles et progressive (donc, au départ, on se déplace en diagonale puis verticalement).

symbol 240,60,126,255,254,255,126,60,62

Premier passage de Pierrick chez moi, en 1993. Il attrape une feuille au hasard sur mon bureau pour me montrer comment il réalise des personnages sur son Amstrad CPC, à l'aide de la commande "SYMBOL" qui reprogramme les caractères graphiques. La feuille était en réalité le dos du plan du premier niveau de Calimero ... ce petit croquis a donc voyagé dans le temps jusqu'en 2012 ^_^

Heh. That one survived too, on the back of a level map that my brother had with him at school: the bubble-shaped character that Pierrick used as hero for small flip-screen platformers on his CPC. I've long time wished that reprogramming characters on the C64 basic was as easy as SYMBOL x,... but even for sprites, it was a PEEK/POKE nightmare, so almost all my C64 games attempts were merely using PETSCII.

Celà se passe sans doutelégèrement après que mon frère ait dessiné la page d'introduction de "Bubule Warrior", sans doute parce que Pierrick dessine depuis longtemps des personnages tous ronds autour de ses feuilles de cours.

Happy New Year !

En guise de carte de voeux, une "fractale du temps" de toutes les "releases" de mon projet sur DS depuis 2006. J'espère la compléter dans le courant du mois avec les "choix stratégiques" sur le moteur de jeu, etc.


Maybe a fractal timeline is too geeky for my audience, but at least, it allows me to tile all the downloadable material released on this blog since 2006. Let's pretend it's my new year's wishes card for 2012