Les limites du GobScript

Ramasser des éponges alors qu'on pouvait déjà ramasser des tailles-crayons ... ça n'aurait pas dû être aussi difficile que celà n'a été. Le fait que les objets soient numérotés plutôt que nommés empèchait toute possibilité de détecter les erreurs. L'autre, c'est que le copié-collé est le seul moyen de réutiliser une région substantielle de code.

Current GobScript is meant to be human-readable bytecode for the state machine. Yes, truly. The most obvious way to realise that is how everything is *indexed* rather than *named*. The upgrade introducing C pre-processor in the make process to avoid code duplication in the behaviour script has been generalized to all monsters of the School Zone.

Yet the recent modification of these behaviour show that it becomes quite tricky to maintain coherency when adding new features. For instance,

• [done] picking up spongebops was missing triggers and repeated bugs about stuck carried GOB when hit.
• [done] Pendat rushing don't hurt Bilou when stomping him because I haven't copied hitboxes when creating the new state
• [done] Stomp-and-grab blador in one move kills Bilou's horizontal speed and creates bogus camera conditions.
• [done] We may enter walls when trying to pick something on the ground, because of a missing 'stopper' micro-controller
• [done] stomping a blador while doing a air-grab allowed to move through because of a missing hitbox.

All this claims that I should now work on a higher-level language for editing, where I could express that "SpongeBop allows carry_me" and "blador allows carry_me" and that would imply some new states added to state machines, specific hitboxes in other states, transitions and such. Don't be surprised if I take that excuse to practice some Haskell, as there is currenty a professional incentive to master that language.

Je me vois mal utiliser les macros du pré-processeur C pour reproduire un motif du genre "une zone de collision dans l'état X permet de passer dans un état $CARRIED puis dans un état $THROWN jusqu'à ce qu'on heurte le sol, ce qui nous ramène dans l'état Y." par la seule ligne "using CARRY_ME(X,Y)" ou quelque-chose de ce genre. Dans le meilleur des cas, celà reviendrait à définir CARRY_IN=X et CARRY_OUT=Y avant un #include "carry_me.cmd.h" ... pas franchement le plus élégant, mais sans doute préférable à une duplication du code...

Ne vous étonnez donc pas si je prends le prétexte d'un convertisseur d'une version "maintenable" du GobScript vers sa version "machine" pour mettre un peu d'Haskell en pratique dans les prochains mois, hein ;)

Kirby Kid's Advice: Inkjet interplay

Here's another one stripped out from Kirby Kid's precious feedback:

the double ink jar obstacle could be tuned better so that the player waits less. the rhythm/timing challenge here is pretty complex (two objects moving and attacking at different rate). Also when the ink rises jumping into these jars is difficult when they go under the ink.

Pas évident, hein, les doubles encriers ? Selon Kirby Kid, ça vaudrait la peine d'en ajuster le rythme pour que le joueur ait moins besoin d'attendre. Effectivement, si on essaie de passer en force ou en vitesse ce genre d'obstacle, ça se finit généralement dans une mare d'encre. Même pour moi. Dommage pour un jeu de course ?

Yeah, that's quite true, I have to admit. Whenever I fail myself at *deline's level, that's in the only part she has not been involved in: the double inkjets. Same for the later level. I hadn't bother this far because I'm not that good at video game, so it sounds natural to me when there's some place where I often fail.

Now, there's one easy way I could increase the chance the player goes through such challenge: allow him to undermine it. If only Bilou had the opportunity to stun inkjets by throwing him a dumblador, that would ease moving through. You wouldn't need to time your jumps because inkjet would stay in-place.

Mais je coince un peu: je ne vois pas bien à quels ajustements procéder. Permettre de simplifier le challenge, ça oui. Il me suffit de permettre au joueur d'assomer les encriers qui resteraient alors gentiment sur place, sans plus jeter d'encre. On redescend à un mode plus simple avec un encrier immobile et un mobile, une seule source de goutelettes. Mais est-ce bien à ce genre de solution que Kirby Kid pensait ?



You wouldn't have to fear droplets either. Of course, when there's two of them, only one would be disabled that way, but that would still be better than trying to hop here and there to dodge droplets.

L'autre explication possible, c'est qu'avec leur façon de monter et descendre depuis le début du niveau, mes encriers se trouvent dans un état trop imprévisible au moment où le joueur les rejoints. Le moindre petit retard accumulé et il n'y a plus moyen de se fier à sa mémoire: il faut obligatoirement observer les encriers, repérer le rythme de leurs tirs (qui dépend de la distance qu'ils parcourent) et se faufiler entre les gouttes.

 

Now, the point I cannot solve is whether that would be solving the "tuning" issue mentioned by Richard. But what could I tune better ? Inkjet's speed doesn't seem too fast, they typically throw once moving up and once moving down. The moment when they'll prepare their blow is constant related to the moment where they turn back, so you *can* learn it from observing, but it will be harder to use this knowledge from one inkjet to the next, since the position of your platform compared to their turn-back position is variable.

Comparativement, tous les Marios sur 8 et 16 bits n'auraient activé le comportement des encriers qu'après que Bilou s'en soit suffisamment approché. En dosant la vitesse à laquelle il avance, le joueur peut alors "manipuler" leur comportement et les forcer à adopter un schéma qui est plus à son avantage. J'avoue, c'est surtout une technique de speedrunner, et j'aurais tendance à la trouver plus perturbante qu'amicale, mais au moins ça donne une possibilté de contrôle bienvenue dans ce genre de situation.

One thing that differs from typical Mario games, is that inkjets are active as soon as the level starts. In comparison, all 2D Mario games built before 1995 were technically limited to a dozen of active sprites. Anything that was moved offscreen from a sufficient distance was "deactivated" and monsters -- but also moving platforms -- start activating when the screen approach them. Here, the player will see them at a random initial position because their position depends on the number of frames spent to get there. Comparatively, in Mario, you'd see them at a position that only depend on how fast you were moving when approaching them. Is this what I'm missing ? 

The ink is interesting to avoid in the air. Once it hits the ground, the player has successfully dodged. If the ink hurts on the ground, the player just waits around for the coast to clear.

This has been easily fixed. Now the ink only hurts in the air, no longer on the ground. For the "rush" type of game, this is definitely not deconstructing any of the challenge.

Et zou.

Cette fois, je pense que j'y suis. Il m'aura finalement fallu sortir l'ensemble de mes techniques pour que cette histoire de lancer de taille-crayons empilés fonctionne correctement. Pas de demie-mesure:

• un nouveau contrôleur, "gobbit" capable de produire un évènement pour signaler le changement de valeur d'une variable -- désolidarisé donc du copycoords dans le plus pur esprit "micro-contrôleurs enchainés"
• un modificateur, F_ATTached, pour que seuls les GOBs attachés au déclencheur de la collision puisse la recevoir. 
• Les collisions sont toujours utilisées pour provoquer le jet de dumblador: c'est la seule façon de permettre de "passer" des arguments d'un GOB à l'autre. Les évènements "gobbit" ne sont là que pour forcer les deux -- lanceur et lancé -- à rester synchronisés quoi qu'il arrive. Bilou ne peut plus se retrouver "mains en l'air" alors que son taille-crayon s'est fait la malle, et ses "impulsions de jet" ou de ramassage ne risquent plus d'être mal interprétées comme des pieds baladeurs.

It's been a hard day's night. And I've been coding like a dog ... At last, I can safely pick up and throw bladors even though they're stacked up. I initially thought a few alterations to the copycoords controller would do it and I end up with a combination of an all-new test-a-bit-in-your-attach-target controller and a filter that makes areas only collide when Gobs are attached to each other. But at least, that allows me to keep both states synchronized and got me rid of those "not quite thrown, sorry, but you'll have to get hurt before you can use your hands again" glitches.

PS: J'imagine que ça va encore sembler "beaucoup de complications pour quelque-chose de simple", mais la richesse du gameplay que j'envisage repose beaucoup sur le nombre d'interactions possibles entre les éléments du jeu. De même que le fait de passer de dangereux (en marche) à inoffensif (dans sa carapace) puis à utile (lancée), puis de nouveau à dangereux (demi-tour) rend le Koopa-Troopa génial, c'est la richesse des états que peut prendre "dumblador" sur laquelle je parie pour faire de la school zone un niveau intéressant dans Bilou's adventure.

If that feels like much work for a small modification of the behaviour, I invite you to read the "interplay" posts of R. Terrel on the critical gaming blog. I expect higher interplay with monsters in the school zone to highly increase the interest of my game under progress.

On se lance ?

Quelques commentaires constructifs sur WoTP (et grâce au croquis animé d'Ymedron que je reprends pour être complet, nd2024), une petite scéance dans AnimEDS et quelques lignes de GobScript en plus ... Voilà des encriers qui ont des yeux, qui font "demi-tour" de manière souple, et -- comble du raffinement -- qui poussent aussi les tailles-crayons (et plus uniquement Bilou).

Now it gots eyes! and thanks to Ymedron, it also gots a more powerful shooting time! Moreover, both Bilou and dumbladors may now get pushed by the hovering inkjet. I also managed to make the blador's top "solid" so that Bilou can move through a stunned blador horizontally, but not fall through it. I think everything should now be ready for moving platforms.

After countless iteration on the animations, on the script files and a few bugfixes on the game engine and a good deal of WiFi DS-to-PC transfers, I finally have inkjets that throw decent ink droplets. Here's the byzanz-record. I think that will be it for this week-end: I've got some frying pans waiting in the queue.

XMAS School Demo.

Here's the new demo. I hope I'll be able to add some screenshots and stuff, but my Internet access is currently down. I've managed to fix the memory corruption problems that prevented to reload the level when Bilou "dies", so here you go.

Voilà enfin la démo promise. Bilou se promène dans les nouveaux graphismes de l'école, il saute (A), assomme les dumbladors, puis les ramasse, les transporte et les lance plus loin (bas). Une erreur de gestion de mémoire m'a obligé à rallonger la phase de debugging. Pour ne rien arranger, je me suis retrouvé sans connexion Internet pendant presque toute ma semaine de congés, du coup, c'est une release "en aveugle", goupillée à partir d'un .nds sur clé USB lors d'un passage-éclair pour reprendre du jus de fruits au bureau ^^".

Since it's a "blind release", I had no access to my todo list, so I couldn't remember I still had a bug with Dumblador recovering just on the left of walls. If you do that, it will remain stuck. (Fixed in SchoolTest-GoT.zip)

Press A to jump and stun bladors, then press "DOWN" to grab them and "DOWN" again to throw them in the direction you're facing.
START enters the pause/debug mode, which you leave by pressing L+START.

Games of Thrown

1MB. throwing in action ...

mises à jour du moteur de jeu terminées: on peut ramasser et lancer des Dumbladors ... puis les re-ramasser et les lancer de nouveau. Enfin, toujours dans la même direction, je le crains, mais lancer quand-même.
Je vais pouvoir passer à l'implémentation des inkjets, du coup ^_^b

PS: attendez-vous à un ralentissement brutal et imprévu du rythme des messages de ce blog dans le courant du mois: *deline attend son petit frère j.l.n mi-janvier.

The game engine now supports throwing of bladors. Pick it up, throw it, repeat. Many things could still be refined including

• [done] having feet really hidden during the stunned animation.
• [drawn] having the bouncing feet looking like feet
• [done]allow the engine to shoot compound gobs too (new feet anim)
• [done] allow runMe to launch the level as well.
• [done] avoid one-way platform to corrupt behaviour of bouncing feet
• [done] throw in both direction, and just drop if you feel so.
• [wish] blador can stun baddies (and Bilou ?) while falling
• [done] fix the map
• [done] use dynamic palette assignment and get rid of those "crosses" marking Bilou feets in jump animations
• [done] areas that can trigger only one other GOB (or a single foot can be consumed by 2 dumbladors simultaneously)
• [wish] climb on stunned bladors, but still walk through them. 
• [done] multi-color that works in runMe too.
• [done] make sure we restart the level if killed, with colours.
• [done] allow bladors to recover next to walls.
• [done] Blador recovers when 2 feet have touched it.

I'll do my best to get all that sorted out quickly so that I could offer the world a new playable demo for Christmas. Earlier arrival of lil'sson could force me to tolerate some imperfections in that release, though.

The Power of Mario

Voilà, c'est mon tour d'avoir fini "l'Histoire de Mario" de William Audureau. Bien intéressant, même si j'avoue que le côté "pourquoi lui ?" mis en avant par l'auteur ne correspond pas à ce qui m'intéresse le plus. Ce qui me tente, moi, c'est de comprendre comment sont apparu les mécanismes qui en font à ce point un jeu hors pair. Au risque de décevoir, je dirais que graphiquement, Super Mario Bros était dépassé techniquement avant même sa sortie. J'en veux pour exemple Pac-Land en arcade en 1984. Non, ce qui est extraordinaire dans ce "premier" Mario, c'est les mécanismes de level design.

Un des grands absents de ce point de vue, dans le livre d'Audureau est sans doute le bloc-question. Miyamoto avait pour règle de travail "la fonction précède la forme": trouvez d'abord quelque-chose d'intéressant au niveau game-play, puis "habillez" là avec quelque-chose de cohérent dans l'univers du jeu. C'est ainsi par exemple que sont apparus dans Mario Bros (vs game) les tuyaux de téléportation, répondant au besoin "d'habiller" le point auquel les tortues quittaient le bas de l'écran pour attaquer une 2eme fois les frères Mario.

I'm pretty lucky we have Pix'n'Love editions around, to provide us great retro-gaming material. I've been reading what you could name "Mario, why *him* -- the story" last month. More than the retrospective aspect, of course, what interrest me most is to dive into the creative process that brought innovative games such as Donkey Kong, Mario Bros. and Super Mario Bros. And for most, I haven't been disappointed. Why barrels, why turtles, why a linear adventure ... so many items are indeed discussed beyond the simple question of "why Mario wears overalls".

La fonction du bloc-question est claire et géniale en même temps: indiquer clairement au joueur l'emplacement des bonus tout lui cachant le nature de ce bonus -- et ça tout en utilisant le mécanisme premier du jeu: sauter. Dans zelda, les "bloc-questions" seront des jarres à casser, vu que le mécanisme premier est le coup d'épée.

Mais alors, que s'est-il passé avec la forme ? Pourquoi cette absence d'habillage complet ? Le mystère n'est même pas évoqué par William. Ce qui est certain, c'est qu'à de nombreux recoins du jeu, l'équipe de Nintendo va utiliser ce côté "magnétique" qu'exerce un bloc isolé et difficile d'accès -- qui pourrait potentiellement contenir jusqu'à un 1UP ou un Power-UP plus rare ... mais aussi une simple pièce d'or ... ou encore une plante grimpante vers une salle bonus!)

But the genious part of the level design imho lays somewhere else -- and is unfortunately un-covered by the book. Questions blocks and Koopa shells. These are the two gameplay elements that make the Mario platformers unique, challenging and interesting. The ?-block is the platforming perfect equivalent of Zelda's bushes, that you hit with your primary mechanics (jump), whose position is obvious, but its content is unknown. So when shown a standalone block in a hard-to-reach area, will you expose yourself, hoping for high reward or not ? Like with poker, you won't know what you missed unless you try it out.

The koopa-shell is bringing the "spinash"-power up to a new level. Flip the power balance: that's the very nature of Pacman's power-up, and to some extent, power-ups in Mario, starting from the hammer in Donkey Kong. The koopa shell does that. From an ennemy, you make a weapon, and a pretty effective one. Only the starman would allow you to defeat a batch of ennemies more easily in SMB than a properly kicked koopa-shell... But a single block on the ground can flip the situation again, because you're not immune to that lethal weapon. And since the shell is quick, you need to speed up to benefit from its action -- but you then expose you again, by reducing your reaction time.
I'm still looking for something as interesting to inject into Bilou's world. I hoped that I'd be taught through the book what is the "design question" that turned "what bounces on walls, moves quickly and hurts when it hits you ? " into "a turtle's shell" ... but obviously, Miyamoto's team has not commented on that.

Autre grand absente: la carapace de Koopa. L'introduction des tortues est elle très bien détaillée ... Mario Bros étant basé essentiellement sur le saut (là où Donkey Kong ne l'avait introduit que comme échapatoire), la première idée de l'équipe est de permettre de "taper par en-dessous". La question de la fonction devient alors "qu'est-ce qui se retrouve immobile lorsqu'on le retourne", et la réponse (l'habillage) : "une tortue".

Mais le génie du koopa-troopa n'est pas là: il s'agit de pouvoir transformer un ennemi en arme. En un seul mouvement, le joueur de Super Mario Bros. envoie vers une longue série d'ennemis un seul projectile capable de les éliminer tous ... mais qui peut se révéler un danger mortel si quelque-chose de dur interrompt sa course. La "boîte d'épinards" de Popeye (origine incontestée des Pac-gommes et power-ups de manière générale), mais à double effet. Qu'est-ce qui passer de "qu'est-ce qui peut être lancé loin pour cueillir des champignons" en "une carapace de tortue" ou "qu'est-ce qui peut se retourner contre son lanceur" - "une carapace de tortue" ... aucune idée.

Grab me, shoot me.

Tout ça est parti d'une relecture des "notes de développement" que je prenais il y a maintenant 10 ans (eh oui) en préparant mon "Ultimate Game Maker". Si les approches que je voulais suivre sont complètement obsolètes, en revanche, j'avais bien creusé les "scénarios pièges" qui définissent généralement la limite entre un moteur de jeu "spécifique" et un moteur générique. En l'occurence, ici "Bilou attrape un ennemi assomé et s'en sert comme arme sur d'autres ennemis".

Coding in a hospital is definitely not an easy job, but there was at least one thing i managed to do during that "free" time when sleep didn't want to come : re-reading those design notes on the "Ultimate Game Maker" I wrote down 10 years ago, organising them, pin-pointing good and bad ideas. Despite virtually all the technical details now fall in the "BadIdeas" category, there were a collection of "gameplay scenarios" that i can reuse to ensure my current game engine is generic enough. The specific "use case" I further studied was the ability to grab an ennemy and use it as a weapon against other ennemies.

Du point de vue "mécanique", je joue sur la possibilité de définir des propriétés aux zones de collisions. Un appleman normal possède juste la propriété "stomp" qui permet à Bilou de l'étourdir en sautant dessus, une fois étourdi, il possède aussi "pick". Au moment où le joueur enfonce le bouton "poing", on ajoute une zone de collision à Bilou qui teste la présence de "picks". En réaction à ce genre de collision, l'état de Bilou aussi bien que celui de l'appleman sont modifiés. Le même genre de mécanisme avec une propriété "shot" est utilisée pour provoquer le passage de l'appelman de l'état "transporté" à l'état de projectile. Tout va bien.

First, I need to translate the scenario into states-collisions-properties elements of my current engine model. With the recently introduced per-collision-area properties, it goes quite well. The appleman doesn't receive f_pick collisions unless it is in the 'stunned' state, and Bilou doesn't test for f_pick collisions unless the player triggers a punch. Similarly, the 'carried' appleman can receive f_shot collisions that turn it into a weapon agaisnt other ennemies. This was tricky in the UGM model because the class of a Gob (bonus, character, ennemy, shot, object ...) stricly defined what collisions could occur. The new model is much more tolerant and it's only your mind that decide the appleman is now a ennemy and then a weapon. Of course, the controller used in "carried" state aligns position and speed of the appleman to those of Bilou.

Sauf que ... comment au juste vais-je "ramasser" l'appleman ? Je veux dire, le mouvement des mains de Bilou et celui de l'appleman doivent être synchronisés pour que ça marche. C'est le genre de problème qui n'apparaît pas dans Blues Brothers avec une seule étape d'animation et un seul objet à ramasser (la caisse), mais je veux profiter de l'absence de bras & jambes de Bilou pour améliorer les animations, même si j'ai 15 ans de retard sur Rayman pour l'implémentation ^^"

The tricky questions surprisingly came from rendering the actions. How do I define the intermediate frames of Bilou grabbing and shooting the appleman ? It wasn't much of an issue in 8-bit (chip'n'dale) or 16-bit (Blues Brothers) paltformers, because you had at most one frame and one object to carry (the crates). But I'd like to take advantage of the 'limbless' nature of Bilou to improve animation (despite I'm 15 years late compared to Rayman :P)

Plusieurs lignes de conduites sont apparues par rapport à cette réflexion:

• les sprites d'un Gob composé doivent permettre de définir l'emplacement des zones de collisions, ainsi f_pick est toujours associé à la main droite de Bilou (tout au long de son déplacement) et f_shot à son pied droit.
• l'ancrage d'un Gob (appleman) à un autre (Bilou) doit aussi pouvoir être défini par rapport à un sprite précis. Ainsi, quand Bilou abaisse sa main pour shooter dans l'appleman, l'appleman suit le mouvement
• deux "commandes" permettront de définir des animations plus fluides : "goto" et "auto", qui permettent à un sprite d'utiliser une paire des variables du Gob comme vitesse pour atteindre un point de référence donné.
  

It resulted that in such 'composite GOBs', the individual sprites (hands, feets, body) should be allowed to govern the position of (some) test areas, and serve as anchor points to other 'carried' GOBs. Moreover, we'll love to have "automated" animation statements such as "go to (x,y) using GOB variables v4 and v5 as horizontal and vertical speeds", rather than giving explicit position for every sprite at every frame.

I could have alternatively opted for multi-gobs (that is, Bilou *shoots* a hand that come back at him), but that would have terribly complicated further interactions.

ps: i gave the official google "readmore" feature a second try on this post and i'll drop it: the RSS still provide the full post, making "read more" not that useful. Plus it will doom my backup strategy. Only "ranting" posts will have "read more" stuff.
pps : yeah, that means i'll really have to work on that "modular animation" add-on for SEDS.

Bilou : première mise en page

Quelques images de "la farde Bilou" ... un document estampillé "P.P.P. Software '94", dans lequel pour la première fois le projet du jeu de plate-formes mettant en scène Bilou et Bouli est décrit avec un peu de cohérence. Jusque là, c'étaient essentiellement quelques croquis de Piet qui tenait lieu de scénario.

Dans les grandes lignes, le scénario est simple: Bilou et Bouli se baladent tranquillement dans l'espace quand un incident quelconque (c'est allé du rayon tracteur à la collision d'astéroïde selon les périodes) provoque un crash de leur "astro-cruiser".

A noter aussi qu'au départ, Bilou et Bouli sont supposé être des humains transformés par un rayon émis depuis cette planète (en cause, 7 pierres magiques qu'il va falloir rassembler pendant le jeu). J'ai laissé tomber cette partie du scénario quand je l'ai repris pour ma petite BD en 2000. Plus question "d'alien des plus étranges" donc.

This was not exactly "the very beginning", but that's the closest we have preserved from that beginning. Somewhere at the end of 1994, there was a video-game design contest where the first prize was to have your game realised by a professional team. It definitely motivated my brother and myself to get some real "design documents" written. This is how the first ever storyline for "Bilou's Adventure" was written. Funny enough, by that time, Bilou and Bouli were initially humans that got lost in space. They're unfortunately approaching a mysterious planet and get hit by a "beam" that both attracts their ship and crash it on the surface, but also turn them into "strange aliens" : a blue ball and a yellow stick.

This is where the 7 "magic stone" initially appeared (influenced by Sonic's chaos emerald ? who knows ?) : they're the key to get back to your old self again, as you probably don't want to stay a blue ball for the rest of your days. I totally droped that part when writing down the comic in 2000. Bilou and Bouli *are* aliens, they don't find themselves "strange" and they are happy to be a ball and a "stick".
Piet était super-motivé par ce fameux concours "décrivez votre jeu vidéo et on le réalise pour vous", puisque non seulement il avait doublé le nombre de niveaux de la Green Zone (apparition du "puit de la clairière", notamment), mais il avait même pris le temps de détailler le "gameplay": "Jumper Mushroom invincible à vos armes" (tiens, ça fait un peu Keen 4, ça, non?), levier pour "dépolluer" le puits avant de tomber dedans, respiration dans l'eau limitée à 5 secondes, avec un pouvoir magique (Blue Stone) pour le prolonger, etc.

De mon côté, il fallait illustrer l'utilisation de tous ces pouvoirs magiques imaginés par Piet qui --jusque là-- se limitaient à un ou deux mots : "invincible", "voler", etc.
Evidemment, au fil du temps, c'est cet ensemble de "pouvoirs" qui a le plus souvent été remis en question. Ainsi, dans la version BASIC, Bilou ne lance pas de gameboy mais a un poing téléscopique et peut s'aggriper au plafond (toute ressemblance avec Rayman est absolument fortuite, puisque celui-ci fait son apparition sous DOS et PSX uniquement l'année après, en 1995).

This has led my brother to start sketching levels for the Green Zone -- and not only sketching them, but also describing them, giving hints on the ennemies movement patterns, gameplay etc. It was full of fun (but impractical for me) ideas such as "stop the pollut-o-matic so that you can enter the river safely", floating, walking and flying bumpers, etc. On my side, i of course had to bring flesh to the bones, and visuals to all of those funny "special powers" that my brother had in mind. "flying", "diving", ... have seen a couple of animations sketched.

Somehow, after the School Zone (which was deeply influenced by Pierrick's sketches), it seemed that my brother had his focus moving away. He just recycled levels of our very first video game "Calimero Against the Black Empire" that i hadn't completed : pyramid zone, water zone, computer/techno zone and the "pipe zone" full of warp pipes and pirhana plants ... hum.
Certains pouvoirs (voler et nager, entre-autres) et la présence d'une "zone des pyramides" n'est pas sans rappeler notre tout premier jeu vidéo "Calimero against the Black Empire", et bien qu'il n'y ait jamais eu de niveau dessinés pour la Fire Zone ou la Water Zone de Bilou, je soupçonne fort mon frère d'avoir penser s'en tirer en repompant les niveaux que je n'avais pas su complètement exploiter dans ce jeu (dont seule la première zone avait été réalisée à grand coups de Gotos ;)

De mon côté, ces illustrations on pratiquement vidé mon microfin de l'époque et ma collection de marqueurs destinés à souligner les titres de mon cours de Français, mais qu'importe. C'était les tout premiers éléments ou je pouvais amener un peu de personnalité à ces deux bonshommes -- Bouli ayant été tout fraichement dessiné (avant ça, il était dessiné comme un "SuperLapin") pour être le dual parfait de Bilou, tant dans les couleurs que dans la version "Laurel & Hardy". Probablement une influence des frères "Jack & Elwood" des Blues Brothers auxquels on jouait tant ... Quoi que j'aie retrouvé en prenant ces photos une première esquisse pour le jeu "Logic Labyrinth", un puzzle-platformer inspiré de Rick Dangerous où mon frère n'avait pas prévu de personnage, et où je pensais bien introduire une balle avec des cheveux punk qui courait très vite et une espèce de saucisse faisant plutôt des sauts en hauteur (un début de Lost Vikings ?). Celui-là n'était pas daté, mais j'aurais tendance à le placer aux alentours de 1990, vu que je me limitais toujours à la palette CGA ;)

It's fun to think that this era is where i initially introduced Bouli in the game. Bilou was there for a long time ago, starring Pierrick's games as "a blue ball named Bubble". I somehow tried to make him look "opposite" to Bilou, unconciously using warm colours where Bilou was all of cold colours, being long and slim (mimmick'ing memorable duos such as Laurel&Hardy or Jack&Elwood) while Bilou was all round. Even his "mood" was different. Bilou started being fast and a bit "impetuous" while Bouli has that kind of "Zen Attitude" that suits the engineer of a revolutional spaceship -- Bilou being instead a talentuous pilot. Think about it: if things had not turned out that way, you might have seen Bouli dubbed "Superabbit" and Bilou might have been blue and magenta with some punk hair...

Voilà. Je vous laisse visionner les archives et je retourne faire mes p'tits trous dans les murs de la cave pour installer des étagères ;)

Encore Titus

De temps en temps, je passe faire un tour sur vgmaps.com, un chouette site qui répertorie les niveaux de jeux vidéos comme un "atlas". C'est du boulot, évidemment. Ayant récupéré "the Blues Brothers" sur abandonia, je me suis amusé à photographier le jeu au fur et à mesure.

the Blues Brothers, c'est le jeu où Titus Interactive prépare les ingrédients de ses futurs jeux. Des munitions (caisses à lancer sur les ennemis), pas encore tant de passages secrets, mais une série de "salles secrètes", comme les cavernes de Prehistorik (premier du nom) qu'il faudra explorer pour rassembler les objets nécessaires au concert de Jack et Elwood, mais qui peuvent aussi bien contenir des "bêtes" bonus ou un loubard.

Many games feature a way to carry items between different places, but Titus Interactive, in their nineties, brought that as the number-one mechanic of the game. The amno, for instance, are things you carry along, like crates. You can only carry one at a time, and if you get hit, you lose what you're carrying. The result is a platformer where careful progress is required, but where you also face a puzzle dimension, in the sense that you will need to pick your route to save amnos.

The whole is spiced up with some exploration, as you will need to find a special item in each level to get the "good ending" of the game. By then, I found that mix much more interesting than the usual straightforward, infinite amno, gun-oriented platformer.

Autre détail qui a son importance, si vous êtes touchés alors que vous transportez une caisse, vous la perdez, ce qui veut dire que plus loin dans le jeu, vous serez désarmé face à un autre danger. Bref, le moindre faux-pas est lourd en conséquence. Autre exemple, les designers se sont amusés à s'assurer qu'à deux ou trois endroits, vous risquiez de retomber plus en arrière dans le jeu (de préférence là où vous n'aviez pas la possibilité d'éliminer tous les ennemis).

• niveau 1 : le magasin (guitare dans une des échoppes). On affronte des loubards, des mémés en caddie, des policiers, des serveuses furieuses et des jardiniers toqués. Une fois dans les nuage, c'est le piaf pond-vite qui nous mêne la vie dure
  
• niveau 2: en construction (lunettes et chapeau que je ne parviens pas à atteindre. Peut-être faut-il un parapluie ...) Sale gosses armés de pulvérisateur d'acide et gros bras maniaques de la clé à molettes, mais gare aux mares d'acides et aux broyeurs.
  

Autre petit élément sympathique, des objets tels que les parapluies ou les balons du premier niveau, offrent un gameplay plus varié.

Bref, du bon jeu de plateau comme on aimerait en voir à nouveau. Dommage que l'opus "II" (juke box adventure) n'ait pas été une réussite... Bien sûr, les graphismes sont nettement plus beaux, mais ils ont complètement perdu le fil de l'histoire. Tout d'abord, le principe même du jeu n'a plus rien avoir. On le catégorise sur abandonia de "no-brain fun", et en effet, plus la moindre recherche. La progression dans le niveau est devenue ultra-linéaire. Finies les caisses, ici on lance des disques, et il faudra souvent en balancer plusieurs pour venir à bout d'un monstre apparemment inoffensif.

Là aussi, le bât blesse: alors que Blues 1 nous avait fait affronter des personnages parfois déjantés, mais toujours réalistes, on se retrouve ici face à des pièges à loup vivants et géants, et .. euh une sorte de tondeuse à gazon croisée avec une pelleteuse mécanique qui à visiblement des instincts de pit-bull.

Bref, les deux premiers niveaux sont beaux, mais franchement insipide une fois leur côté démo/tutoriel passé, et dès le niveau 2, les monstres sont tout simplement pénibles (mouvements trop rapides, impossibilité de les dégommer quand ils sont "au repos", bref, pas impassables, mais pénibles)

Et pour le coup de grâce, je vous laisse contempler, hébétés, nos fameux blueseurs transformés en sur-hommes après avoir mangé une part de gâteau, ce qui semblerait leur permettre de faire des sauts plus longs, et peut-être renforcerait la puissance de leur lancer de disque.

Ridicule et pas convaincant pour un sous. Bref, autant Titus Interactive nous a fait de bons jeux dans ses jeunes années, autant il semblerait qu'ils aient été contaminés par la transformation du monde du jeu vidéo en un "marché" et progressivement perdu toute notion du gameplay et de la conception des bons niveaux. Je n'oserais même pas dire qu'ils ont transformé BB en un clône de Megaman: la seule ressemblance viendrait du fait que l'on tire sur des ennemis dans un sidescroller.

Bref, concentrez-vous sur le premier volet à moins d'être un graphiste en manque d'inspiration.