#20games

Bon, il y a 20 jours, j'ai décidé de suivre l'exemple de Sverx et d'essayer de poster chaque jour "un jeu qui m'a marqué". Je l'ai compris au départ comme "qui est une de mes sources d'influences dans les jeux que je conçois et réalise ... on y trouvera donc pas Link to the Past, même si c'est à son donjon des glaces que je repense chaque fois que je dois trouver la détermination d'envoyer un recommandé ou de renvoyer des couriers administratifs d'un bureau à l'autre du même bâtiment en passant par ma boîte aux lettres ^^".

J'avais dans le passé déjà voulu participer à un autre challenge du genre puisqu'il y avait jusqu'à hier un tag "10 games" avec 3 posts ...  Croyez-moi si vous voulez, le plus difficile aura été d'attendre chaque fois 24 heures avant de parler du jeu suivant ^^".

I've followed Sverx's example and try to identify 20 games that have been most influential to me as a gamedev. Having to wait for the next day before picking the next game turned out to be one of the trickiest part of the challenge to me ^^". The challenge also said "no explanation, no particular order", but it turns out the first four I picked were among games that I go back for reference very often.

Le challenge disait "pas d'ordre particulier" (avoir Goodbye Galaxy en #1 ne veut donc pas dire qu'il s'agit du meilleur jeu ou du plus important), et surtout "pas de commentaire". Mais sans grande surprise, j'aimerais maintenant revenir sur chaque choix et contextualiser.

"Commander Keen in Goodbye Galaxy", donc, qui a été _le_ jeu utilisé par mon frère pendant qu'il dessinait les premiers niveaux de Bilou. Sans oublier les imports aux monstres de "Secret of the Oracle" pour les ennemis de la Green Zone. Il est probablement aussi parmi les jeux dont j'aimerais le plus mettre la main sur le code source. Même s'il y a les sources de "Keen Dreams", le moteur de GG est plus abouti, ça se sent manette en main...

Some of the games I mention on this blog are so influential they even get their own tag in the cloud! That's the case for Commander Keen, the game that formatted my brother's level design and monster rooster, but also for Fury of the Furries, where *I* draw inspiration during so many levels revival and where I've truly learnt pixelart. 

"Fury of the Furries", que ce soit les graphismes, les musiques, le thème, le level design, ce jeu revient tout le temps dans mon esprit dès que je travaille sur mes propres jeux, donc bin ... évidemment, c'était le n° 2. Lui aussi, j'aimerais sacrément tomber sur son code source... la physique de l'eau, du sable, la corde ... vraiment curieux de voir comment les gars s'y étaient pris. (note au passage: il y a toujours le projet FuryStudio à étudier et les infos sur shikadi.net ). C'est aussi le premier jeu que j'ai pu utiliser comme référence pour le pixel art vu que tous ces graphismes étaient des .LBM.

Vient ensuite Prehistorik 2, qui reste une référence pour moi en matière de bonus, de cachette ... et de comment faire une démo d'un niveau capable de captiver une bande de gamins/jeunes pendant tout un après-midi. Comment Bilou.BAS faisait tomber les pommes pour le décompte du score à la fin du niveau ? Prehistorik 2. Comment le niveau-anniversaire essaie de vous pousser à faire un 100% sur un unique niveau un peu corsé quand-même ? Prehistorik 2. La révision des éponges pour les pendre au bout d'un fil ? Encore prehistorik 2. Lui ... trouver son code ... je ne sais pas trop. Ce serait peut-être un sacré travail de l'étudier si jamais il faisait surface, vu les stratégies "tout assembleur" si chères à M. Zmiro ... Mais on a toujours le site mine.nu et sa page sur le format des niveaux. (Il y a une réécriture SDL2 en C, cela dit ... )

The next two may not have their own tag, but their impact on game mechanics and how to make a compact game interesting over the long run are still fundamental. They are also two of the games for which I'd definitely like to see the source code, and figure out what design choice the developers have taken.

Et Pharaoh's curse. Il a beau être simpliste au regard des précédents, c'est peut être le meilleur exemple pour moi de rapport qualité de gameplay / quantité de contenu. Ceux qui lisent ce blog depuis assez longtemps n'auront pas manquer de noter que je finis régulièrement par revenir à des mécaniques tirées de ce jeu C64 ... et j'espère toujours voir débarquer la version remasterisée de notre ami Lazycow ... Notez que pour ce jeu-là, le code source, c'est de l'assembleur, donc plus facile à reverse-engineerer. Et quelqu'un s'y est déjà attelé.

Cachette Secrètes ...

Il y avait quelque-chose de bien fun dans Prehistorik 2: de nombreuses cachettes dans lesquelles on trouvait plein de bonus plus farfelus les uns que les autres. Pas trop à se tracasser, celà dit: ça fait juste monter votre score. Mais ça fait aussi quelques clins d'oeil rigolos. Quand on tombe sur un pacman ou une cocotte en papier, par exemple.

J'avais eu dans l'idée d'ajouter des objets étranges à collecter dans Infinite Pyramid, qui serviraient de témoignages des années qui ont vu naître Bilou. Une K7 audio qui déclenche un jingle de l'inspecteur Gadget, par exemple. Ou un pixel art de Fury of the Furries. Ce genre de chose. Repenser aux parties de PRE2.EXE et à sa casserole géante (élément sympa qui nous rappelle le niveau qui vient de s'écouler) me donne l'impression que des objets hétéroclites sont plus fun qu'un gros tas de bananes, aussi Rare soient-elles.

 

Don't trust what's being said in French: it all happened because I was playing Eagle Island, and couldn't help but trying to smash the owl into walls just in case there'd be hidden things. Only then I recall that I grew this habbit while clubbing around in Titus' Prehistorik 2.

But granted, the thing about K-7-shaped bonuses in the pyraputer that would play Inspector Gadget jingle is a true trivia that has been suggested to Cyborg Jeff for approval. And indeed, bringing that together with the "nostalgia" for clubbing into walls made me realize that collect-a-thon are more fun if you don't know in advance what you'll collect and when designers break your expectation about what may comes during the hunt. It's another way to "make gaming moments memorable" when your game doesn't really fits an epic scenery.

Par contre, je n'avais toujours pas de bonne solution pour faire la chasse au bonus. L'effet préhistorik est drôle parce qu'on peut prendre les attentes du joueur à contre-pied. ça marchera moins (imho) si il a vu les bonus approcher depuis le bord de l'écran. Alors, bien sûr, je peux donner des coups de tête dans les branches pour faire apparaître des trucs. ça se transpose moins bien en dehors de la Green Zone. Je peux lancer des taille-crayons dans les murs, mais ça limite les endroits où chercher.

Je peux aussi essayer de faire une animation de Bilou à 4 pattes, qui permette de rendre la recherche des cachettes dans les murs un peu plus excitantes, mais entrer dans la cachette n'est que le début. ça ne nous donne pas l'effet "bonus surprise" de PRE2.

Puis en gribouillant, je suis tombé sur une idée mélangeant PRE2 et SMB3. Pourquoi ne pas permettre à Bilou de passer à certains moments derrière le décor. Là, il peut utiliser le bouton "GRAB" pour essayer de fouiller et faire sortir tous les bonus cachés ^_^

it brought my attention to the fact that I still don't have a good candidate for PRE2.EXE's club (or DK ground-pound attacks) to investigate things when you haven't been provided a blador/koopa/DK barrel to hint you that there is a secret nearby. I've been scribbling some options, starting with the obvious "jump and hit things repeatedly", continuing with "crawl under a lower (secret) passage into the wall. Nothing really convincing.

Taking a step back, why does clubbing-for-secrets work in PRE2 ? Partly because you'll clubbing all over the time. That's why blowing on things in DK:R doesn't work as well as rolling into the grass in DK:TF. What could Bilou do ? So far, his bare abilities are JUMP and GRAB...

We all know how JUMP can be used to reveal hidden goodies, right ? How about GRAB ? You sure could do it the SMB2 way. Not only you lift up defeated baddies, but you can strip goodies out of the ground after you found a suspicious thing protruding from the ground. You could also do it the DK:TF way, grabbing a root, holding 'GRAB' for a bit longer and finally you reveal the hidden stuffs. But both are for obvious secrets. Mechanically, they're not that different from the hit-me-plants of Rayman Origins (or DK:TF, by the way)

But I could turn them into PRE2-hit-the-unexpected-spot if I combine that with a mechanics from SMB3: hold up/down to switch to the background layer. Only then, you'd start digging for secrets by using GRAB again and again. There won't be the "smash-smash-smash" sound, but it could be made equally funny, I think.

Je sens que ça va être rigolo. On peut aussi le faire dans la pyramide là où il y a du sable, ou en passant derrière un pillier / une statue plutôt que par devant.

La guerre des Mascottes

Ça y est : j'ai enfin reçu mon tome 2 de l'Histoire de Mario. Chiffre de ventes à l'appui, William Audureau et Oscar Lemaire passent au tamis les années sabbatiques du plombier, à savoir la période de 1990 (lancement de Super Mario World) à Juin 1996 (fin du développement de Mario 64). Je dis "années sabbatiques" puisqu'entre les deux, les amateurs de fleurs de feu n'auront que Mario Land II à se mettre sous la dent.

C'est pourtant l'époque où tous vont tenter l'aventure de la plate-forme dans le sillage de celui qui tente de faire vaciller l'idole, à savoir Sonic (1991). Bien sûr, il y aura eu d'autres jeux de plate-forme avant et il y en aura d'autre après, mais durant cette période, ils représenteront le gros des ventes de jeu sur console.

Chose peu surprenante, c'est avec la sortie de Sonic que coïncidera l'envie de faire mon propre jeu de plate-forme avec d'abord Calimero de '91 à '93 puis avec Bilou sous Basic entre '94 et '96.

Pendant ce temps, à peu près tous les détenteurs de personnages enfantin forts vont cesser d'"ignorer" le jeu vidéo et attaquer le dangereux Mario sur son terrain : celui du jeu de plate-forme. Ce sera "castle of illusion" avec Mickey, "duck tales" puis les jeux Infogrames qui ratissent autant de personnages de bande-dessinée francophone que possible mais aussi le bestiaire de la bande à Bugs Bunny -- avec plus ou moins de succès. En réaction, les acteurs du jeu vidéo vont aussi miser gros sur les personnages d'animaux antropomorphiques ayant le potentiel de devenir des mascottes, comme le Mr. Nutz de Philippe Dessoly chez Ocean, la chauve-souris acrobatique chez Sun Soft et le controversé Bubsy chez Accolade (que je ne connaissais jusque là que sur PC pour ses simulateurs de course)... et bien d'autres encore qui n'auront atteint ni l'émission Luna Park ni les planches de Midam. Même les robots de combats spatiaux prennent des allures de braves mascottes et tentent de se faire passer pour des abeilles avec des noms comme "twinnbee".

Oh, well. There's been another book by William Audureau, joint by Oscar Lemaire, about years '91-'95 where platformer was the king of video games, and where it looked like everyone could come with a mascot-like hero that would be the next Sonic since Mario was Missing... So I've been reading and reading. And no code has progressed. More luck next week ?

De notre côtés de jeunes ados, on fait la chasse aux magazines, on rève à ce que peut bien être tel ou tel jeu avec un personnage plus ou moins probable. Il semble qu'il y ait un nouveau venu tous les trimestres. Dans quelques rares cas, on aura l'occasion de s'y essayer mais le monde du PC est tristement dépourvu de ce genre d'exotisme. Au mieux, ce sera James Pond II sur Amiga à la maxithèque, ou la surprise de découvrir Moktar reconverti en Titus the Fox. Ils ne sont pas tous des sonic-like tels que Zool, mais ils cherchent clairement à plaire au même public. Et il semble bien que le succès de Sonic décomplexe tous ceux qui hésitaient jusque là à faire des chat-tout-mignons comme personnages de jeu: il suffit de leur coller un élément vestimentaire de jeune, une attitude cool-et-frondeuse, et en avant. Sur micro, on le prendra avec une dose de dérision, et j'ajouterais bien "Super Frog" (PC, Amiga) à Jazz Jackrabbit & James Pond ... mais le plus souvent, on avait droit à un gros raté du genre "Skunny the Wild West".

Le tandem William-Oscar gratte donc derrière les couvertures de magazines et effectue un impressionnant travail pour rassembler les interviews, les mettre en contexte ... Car si l'un va titrer "la nouvelle mascotte de XXX", ce n'est pas nécessairement l'avis de la société qui l'aura publié, ni du studio qui l'aura créé. Et si les personnages humains (Commander Keen ? Duke Nukem ?) sont assez peu présent dans l'analyse, les "héros/mascottes" improbables tels que Plok ou Cool Spot eux, ne sont pas oubliés.

Il met aussi en perspective les travaux de l'équipe de Miyamoto -- qui n'est évidemment pas restée les bras croisés pendant 5 ans -- qui sans parvenir à donner un deuxième jeu où l'on saute vers des blocs-questions à la SuperNES va se frotter à toutes les technologies de pré-3D afin d'avoir le meilleur Mario 64 possible quand sera enfin prête la console 3D de nintendo.

Il y aura finalement peu de suites parmi les "héros fabriqués spécialement pour l'occasion" ... et aucun ne parviendra à survivre à l'environnement des 16-bits où il a vu le jour, que ce soit pour des raisons de fusion/acquisition/license, par incompatibilité technique entre la vue 3D et les mouvements du jeu de plate-forme, ou simplement parce que les artistes d'animations qui donnaient vie aux personnages se retrouvent privés de tout repère devant les logiciels de modélisations polygonales.

Vous l'aurez compris, même s'il y avait beaucoup moins de matière pour le game-designer-amateur que je suis, le livre m'a malgré tout tenu en haleine. Bon, évidemment, avec tout ça, le travail sur l'amélioration de SEDS et LEDS, mes éditeurs de jeu sous DS, n'ont pas beaucoup avancé ^^".

Tout vient d'la cache

Quand Eric parlait de faire des mises à jour à la volée de la mémoire au fil de l'animation des sprites, je pensais spontanément à un système semblable à celui de Donkey Kong Country: chaque personnage se voit attribué un emplacement en VRAM et les mises à jours pour ce personnage-là viennent systématiquement à l'emplacement alloué à l'apparition du personnage. Du coup, s'il y a deux "kritters" en même temps à l'écran, il n'y aura aucun partage entre eux: le nombre d'objets à l'écran devient fortement contraint, même s'il y a peu d'images indépendantes, comme dans le cas d'Apple Assault.

In my first attempt to understand Eric Zmiro's animation engine I thought the video memory would be managed somehow similarly to what happens in DKC on SNES: every new object on screen would receive a chunk of video memory large enough for the most complex frame it has to render and it would update its content during the vertical synchronization timeslice (or at some other time slice when the GPU isn't busy looking up those pixels). To some extent, the DKC engine would be an auwfully bad choice to implement a game such as Apple Assault, where there are a large number of similar ennemies on screen and high probability that a single block of VRAM is in use by multiple ennemies at the same time. That was failing to include the key ingredient in Zmiro's engine.

J'avais oublié un élément essentiel des moteurs de jeu à la sauce Zmiro:

Chez moi, tout est en cache : Fichier, sprites, palettes, bloc... tu n'allais tout de même pas dupliquer les blocs autant de fois qu'il y a d'instance ? si ? [...] avec ce systeme (développé sur GBA en 2000), on fait actuellement l'affichage de fonte (du texte!) avec caractères proportionnel sur XBOX one et PS4, codé en utf-8 et disposant de toutes les langues y compris chinoix, japonais et coréen ! Tu vois, c'est souple.

Like for tileset used by a gigantic and varied map, Eric introduced cache management algorithm deep into the animation rendering. Animation data refer to logical blocks and the mapping to VRAM location happens dynamically, reusing blocks when possible, importing new ones only when they are not yet in VRAM somewhere else and dropping unused one only when room is needed, keeping them available for the next animation cycle when you have few sprites on screen.

With this approach, no need for pre-defined locations, no need to do spritesheet optimizations such as "let's keep only one VRAM slot for the stunned dumblador and update it from main RAM to get the desired animation on screen". For every block in the SpriteSet, all we need is an additional short integer indicating whether the block is currently missing in VRAM or stored at some location between 0 and 1023. Everytime an OAM need to be patched to reference one logical sprite block (like "page 4, block 21), you can check the corresponding VRAM slot in the spriteset and copy to a free VRAM slot if none is currently assigned.

Fini donc les emplacements pré-établis. Finies les acrobaties du genre "je vais garder une seule image pour 'dumblador assomé' sur la spritesheet et j'aurai un SprAnim qui change son contenu depuis la banque d'image restée en RAM (je fais pareil avec les vagues d'encre actuellement): pour chaque bloc de données contenues dans le spriteset, il nous faut un nombre supplémentaire, entre -1 (absent) et 1023 qui indique l'endroit en VRAM où on peut trouver cette image-là.

A chaque fois que l'on veut reprogrammer un OAM pour qu'il fasse référence au bloc "page 4, image 21", on regarde l'emplacement VRAM associé, et on en alloue un en réutilisant un emplacement libre si le bloc correspondant n'est pas encore en VRAM. Avec 1024 blocs de 16x16, on peut avoir assez de pixels différents dans les sprites pour couvrir 5 fois l'écran de la DS. Le risque d'un objet invisible par faute de mémoire vidéo est virtuellement nul. Dans mon organisation actuelle, j'ai 128Ko pour les sprites, soit moitié moins, mais ça reste tout à fait viable.

Le côté génial du truc, c'est que tant qu'on alloue sur des blocs qui ne sont pas actuellement présents à l'écran (marqués comme libres), on peut faire la mise à jour de la mémoire vidéo pendant la phase longue où le GPU retrace les pixels à l'écran. Seules les substitutions où on est obligé d'éjecter un bloc utilisé lors de l'image actuellement dessinée devront se faire pendant la phase courte émulant un "retour de balayage".

Now, how would that work with Bilou's spritesheet ? I'm currently using about 1/4th of the video memory for Bilou's heads while only one is shown at every single frame. Streaming Bilou's head into a double-buffer as the animation needs it was one of my top improvements for AnimEDS. With a Zmiro-cache, I no longer need to allocate VRAM slots to GOBs. I no longer need AnimEDS updates. And potentially, I could have the whole set of heads used by the current animation in video memory, having only gradual updates of the VRAM as I switch between actions.

Alors, est-ce que ça marcherait avec Bilou ? Un bon quart de la VRAM est utilisé actuellement pour toutes ses "têtes" et une seule est affichée à la fois. J'avais bien l'intention de faire une sorte de "streaming par double-buffer de la RAM vers la VRAM" dans une révision de AnimEDS. Le Zmiro-cache permet de passer souplement d'un double-buffer à "seules les têtes utilisées dans l'action en cours restent en mémoire vidéo". Je gagne de la place et je peux (enfin) me permettre d'autres petites animations avec des grimaces, etc.

Les mains et pieds partagés par les crayons, les taille-crayons et Bilou ? Ils n'occupent pas beaucoup de place et ont de bonnes chances de rester présents en permanence.

Shared hands and feet (used by Bilou, pendats and dumbladors) only use a small area of the whole spritesheet. It's likely a 'least-recently-used' policy would keep them permanently in video memory. Bonuses, ink drops, dust clouds would likely come and go as needed, giving more room for ennemies frames.

How many ennemies could we host ? Well the critical point is more "how much VRAM slots will be off-screen at every frame?". If you have a free (off-screen) slot for every block you need to bring in for the next frame, then you don't need time-critical copies during the blanking interval. You have 128KB of sprites memory, which means 512 different 16x16 blocks. enough to cover 2.5 times the 256x192 screen of the NDS. The gameplay will become cluttered well before you hit the cache limits. 

Les bonus, gouttes d'encre et autres nuages-de-poussière-encore-à-dessiner ferait probablement des apparitions éphémères, forçant des objets dont l'animation tient plus déjà du "streaming" (p.ex. inkjet) à faire revenir une image de la mémoire centrale vers la VRAM.

Bref, vu le nombre de fois où je me suis "cogné la tête au plafond" de la quantité de VRAM disponible juste sur le projet "School Rush", introduire cette technique de cache pour gérer la mémoire vidéo serait sans doute la bienvenue avant d'envisager un jeu plus ambitieux ... disons de la taille d'un Commander Keen ?

Si j'étais graphiste ...

Si j'étais graphiste, mes sprites auraient plutôt cette trogne-là. Je saurais qu'une bonne animation, c'est une animation où on a pas peur de casser les cadres et j'arriverais à l'appliquer. Du coup, le meilleur environnement pour faire du bon travail, ce serait quelque-chose qui soit le plus souple possible. avoir suffisamment d'images disponibles simultanément pour les copier-coller et les comparaison. Bref, un outil comme SEDS ne me semblerait probablement jamais franchement pratique.

Let's be honest: I'm far from getting any close to what a real pixel artist produces. If I was, my spritesheets would look like those featured in Titus's Prehistorik II: I would not let canvas restrict myself and I would apply squash/stretch so that animations work fine. There would be significant pixels variation between frames, too. In a word, the SEDS+AnimEDS would be very unlikely to suit me. I'd need something more flexible, and in return, my game engine would need something to easily convert such flat sheets into usable assets.

Mais pour mettre des graphismes dans un jeu, faire des graphismes ne suffit pas: il faut aussi qu'ils puissent être intégré au jeu. Il faut que l'artiste puisse le plus librement possible retoucher son animation, y compris faire grandir ou rétrécir certaines images.

L'idéal pour ça, comme l'expliquait hier Eric Zmiro -- concepteur avec plus de 20 ans de métier -- c'est d'avoir le système le plus automatisé possible. Voici donc ce que j'ai compris du système qu'il décrit.

 I had the opportunity to compare the tools used in my own "School Rush" with the kind of tools and techniques that Eric Zmiro (now at Magic Pocket, and formerly developer of Prehistorik II at Titus). The core idea is to make the spritesheet-to-game data conversion as automated as possible. There cannot be any "great hotspot positioning tool" because there shouldn't be any human doing such task in first place.

From his explanations, I started to think about such automated framing tool, which is mostly a matter of separating lines that contain pixels from lines that contain none -- and having some conventions such as "an animation is bottom-aligned horizontally". Of course, there is still need to identify a reference position for each frame, so that e.g. the character's nose stays at the same position on screen while scrolling at constant speed, but a mere line of lone pixels could do the trick.

Sur base de la première planche de sprites, le premier algorithme à faire tourner est un système qui identifie les zones dans lesquelles il y a des images des zones vides. Une ou plusieurs lignes horizontale ne contenant aucun pixel (gris foncé): c'est une nouvelle animation. Une ou plusieurs lignes verticales ne contenant aucun pixels (gris clair) à l'intérieur d'une tranche d'animation: c'est une séparation entre deux étapes d'animation. On peut ensuite raffiner pour rétrécir verticalement la zone active d'un sprite.

1) on découpe les animations par planche (1 planche = 1 animation)
2) on a un outil qui capture les sprites, les convertie en bloc
3) quand un bloc existe déjà dans la banque des bloc, il ne le rajoute pas.
4) pour chaque sprite indique : [x, y, flipXY, color_index, bloc_number, size] (j'espère n'avoir rien oublié)

Si deux sprites sont identiques, ils seront partagés. Mieux, certains blocs peuvent être partagé même si ils appartiennent a des sprites différents
Encore mieux, des blocs peuvent être identique apres flip, ou être identique a une transposition de palette prêt..

Si elle me semble contre-productive, la décision "une animation par fichier" trouve tout son sens dans une équipe soumise à une date de sortie: sur une planche "prehistorik-man.png", on peut effectivement laisser le logiciel découper les bandes d'animations et faire référence à prun = pman[0][*]; pcrawl = pman[1][*]; pswim = pman[2][*]; pjump=pman[3][*]; etc. Mais imaginons qu'au terme de la production on décide finalement de laisser tomber le niveau aquatique. L'animation de nage tombe aussi et pjump devient maintenant pman[2][*]. Tous les autres animations doivent également être re-numérotée. On s'en passerait bien vu qu'il faut livrer la ROM fin de semaine pour que le jeu soit prêt début décembre...

But my understanding was yet one productivity-step below the Zmiro approach: by enforcing only one animation per sprites file, we now have a strong filename-to-game asset relationship. If the file is named pcrawl.png, then we can gather all the corresponding sprites as pcrawl[*]. When instead the 'crawl' animation is simply refered as the 5th one on pman.png, then we become vulnerable to the removal of e.g. 4th or 3rd animation, for instance because "well, the water level doesn't work, we drop the swim animation".

Yet, having the art split into multiple bitmaps doesn't mean that the tool importing them all cannot identify shared frames (or blocks) across the whole dataset. The final touch, for every frame the auto-cropper found, will be to isolate solid pixels into a minimum set of hardware-compatible blocks and pack the pixels of those blocks into tiles. The DS video chip, for instance, will only work with 8*W x 8*H blocks with W/H ratios of 0.5, 1 or 2 and a maximum size of 64*64 pixels. Even with a simple greedy algorithm, we can easily shrunk the amount of video memory required for a sprite to 1/3rd of the brute-force 64x64 sprite approach. Each batch of tiles has a companion set of OAM data that can configure hardware sprites' size, ratio position and indexes so that your 7 sprites actually look like a single, seamless cro-magnon protagonist to the player.

Reste à faire manger ça par le hardware d'une console comme la DS, qui ne fonctionne qu'avec des sprites hardware de 8x8, 16x8, 8x16, 16x16, 16x32, 32x16, 32x32, etc. jusqu'à 64x64. Sa mémoire est limitée, aussi donc avec un seul bloc de 64x64, le nombre de sprites affichables simultanément est sérieusement réduit. Ici, p.ex., on a un cro-magnon de 37x49 pixels qui prendrait 64x64. Avec un simpe algorithme de découpe "glouton", on peut le couvrir avec 4 blocs de 16x16 et 3 blocs de 8x16. Soit 6/16 de la mémoire nécessaire pour l'afficher d'un seul bloc.

AnimEDS travaille par petites éditions successives. Mais AnimEDS suppose que le contenu de la mémoire vidéo est constant. Ici, il n'y a aucun intérêt à garder un morceau de cro-magnon en mémoire si cette image-là n'est pas à l'écran. Du coup, tout ce qu'il faut c'est allouer un bloc de N tiles de sprites -- avec N assez grand pour la plus grosse étape d'animation -- et assez de blocs 'OAM' pour les contrôler. Pendant la synchronisation vidéo, c'est un nouvel ensemble "VRAM+OAM" qui est transféré simultanément pour changer les pixels que la console peut afficher et l'information sur quoi afficher où (les OAMs).

Then you need to have a game engine that can make the best use of these list of OAM datas. A real animator like those who work with Eric will easily saturate the 128K of sprite memory the DS has, so every new frame is likely to see new sprites tiles updated in VRAM together with the OAM updates. More on that in a future post.

Mais je ne suis pas graphiste. Il y aura encore pas mal d'eau coulant sous des ponts avant que je n'accouche d'un personnage pareil ... donc je vais garder SEDS et AnimEDS encore un petit moment. Par contre, si mon moteur de jeu évolue dans le bon sens, on pourrait envisager un outil d'importation des .png en .spr qui ferait ce genre de travail pour faciliter l'importation de graphismes non-SEDS dans un jeu tournant grâce à libgeds.

Titus the Fox dans Pix'n'Love #15

Parmi les excellents dossiers du magazine "Pix'n'Love" que j'aimerais voir réunis en un ouvrage dédié au game design, il y a une interview très intéressante d'Eric Zmiro sur le développement de "Titus the Fox / Moktar". Moktar est un des premiers jeux de plate-formes auquel j'ai pu vraiment m'essayer ... comprenez avec autant de tentative que je ne le voulais parce qu'il n'y avait pas de fin de vacances, de fin de courses au GB ou de fin de pièce de 500 Lires pour m'obliger à passer la manette de manière définitive.

Il y avait beaucoup de bonnes choses dans ce jeu -- notamment la possibilité d'emporter plein d'objet et de construire le gameplay sur leur manipulation -- et c'est toujours un peu triste pour moi d'entendre les joueurs console cracher sur la société qui a produit les premiers jeux sympas pour PC que j'aie rencontrés. Il y a aussi beaucoup de choses discutables que l'article me permet de comprendre mieux. Le scrolling, par exemple, fonctionnant par à-coup, qui se révèle être un hybride entre le scrolling continu d'un Mario/Keen et le screen-flipping qu'on trouvait déjà dans le premier opus de Prehistorik. Bien sûr, il était techniquement possible en 1991 de faire mieux, mais pour un éditeur qui n'agit qu'en France, il est important que les titres PC tournent sur tous les PC. Pas seulement sur le 286 équippé d'une carte VGA de mon voisin Alain, mais aussi sur un 8086 CGA.

L'écart de fluidité entre les version Amiga et PC, le choix de jeux à licence laissait imaginer une équipe encleinte à la facilité. L'interview révèle une équipe extrêmement réduite (un graphiste et un programmeur pour le jeu "Moktar") qui n'hésite pas à reprendre la partie la plus technique du moteur de jeu pour pouvoir supporter des sprites plus gros et des niveaux plus vastes quand la direction déclare juste "on va faire un jeu avec Lagaf'. Changez juste le personnage de Blues Brothers et ça ira comme ça" (citation officielle). Et la description de l'environnement de création habituel, très "bride sur le coup", de Titus Interactive donne aussi un autre éclairage sur cette déclaration. "On a un contrat pour un jeu, les gars. Et cette fois on a une date limite. Alors pas question de démo techniques qui n'aboutissent à rien cette fois-ci." (interprétation personnelle, ce qui n'a de toutes façon pas beaucoup d'importance puisque de toutes façons, pendant les mois passés à attendre les graphismes, Eric Zmiro a eu l'occasion de faire un tout nouveau moteur de jeu). Quand aux versions Amiga, elles ne sont pas développées en interne, mais confiées à des spécialistes free-lance de cette machine, sans doute une fois que le jeu a fait ses preuves et que les rentrées permettent d'envisager des frais supplémentaires.

Merci à Eric pour cette interview officielle, mais aussi aux longues discussion en privé depuis son premier commentaire sur ce blog en 2007.

Missing monster ?

Pendats dropping Power-ups, bladors stunning inkjets, all this had the objective to address Kirby Kid's most critical statement:

Most enemies are just things to avoid (lacking interplay). When I see enemies I don't get exciting to avoid them or take them out.

Most enemies were built around the idea that they are not aggressive, but still dangerous. This is built deep within the genome of Bilou's world: there is no invasion army we fight against, rather wild beast not appreciating that you disturb their business. Yet, it turns out that for a time attack side-scroller, we're missing something that would have wider range and somewhat chase Bilou (60px/sec when walking). I needed something that's mostly on the ground and dismissed with primary mechanic, but that moves faster than pendat (16px/sec) or dumblador (8px/sec).

Making Pendats Run?
That would be the easy way out. or should be. Design documents from 2004-2005 show pendats that charge Bilou with their spears. Even earlier, the comic show them knocking down stacks of books. Yet, this is hard to achieve -- if ever possible -- with today's pixel art pendat. To reach that, I will need the hybrid vector/bitmap animation editor I intended to use for BangBash.

Bangbash wouldn't help.
He's more than just dangerous. He's dangerous and quick to anger. Maybe that's not yet what makes you excited about facing an opponent, but at least, that should build up some tension.

Something a la Blues Brothers ...
That game from Titus is one where I could feel engaged in dispatching enemies. They weren't very developed, either shooting, wandering or wandering-and-shooting-if-spotting-you, but they were moving about as fast as yourself. If they weren't as smart as the pendat described above, they'd usually have a "knock you down" animation when they hurt you. They're also quite fast. If you find yourself out of crate, think twice before you revert direction because every pixel between you and the bad guy count. You won't outrun them as easily as a goomba.

So if you haven't guessed from the size-test picture, I'm opting for a staple remover. These things look hazardous enough in real-life, it's not a wonder why you can find some customized into T-Rex heads. I've endured countless buzzing of Nintendo's "Donkey Kong Jr." game-over as I got my feet chunked into bits by those living wolf traps and their klap trap derivative. It doesn't turn very easy to pixel, however.

Funky Inside

Rompant avec les niveaux prévus par mon frère, je décide en 2001 de placer la confrontation entre Bilou et Big Caterpillar au sommet d'un arbre creux monstrueusement grand... et je fais totalement l'impasse sur ce qui se passe à l'intérieur de l'arbre. Puis, en pleine phase Cave-Story, je décide que la "clé du boss" ne sera pas une bête clé mais plutôt une interaction avec des NPC, notamment les Funky Funghi fraîchement relookés. L'occasion aussi d'un niveau tout en hauteur où je peux caser des bascules/tremplins et autres effets catapultants bien marrants (enfin, j'espère).

In Bilou's Adventure as my Brother invented it, there was no such thing as a hollow tree level. Still, when I converted the yet-to-be-written game into a (web)comic in 2001, I figured out that a huge, hollow tree would be a nice place for Big Caterpillar to have his lair.

Later on, as I started to feel the interest that an organic (or even story-based) key may have and decided that 'plain keys' had no real place in the green zone, that hollow tree seemed to be a nice place to have a crowd of Funky Funghi that would make the boss a bit harder to reach...

I had no real luck on my hunt for reference material until that Rayman Origins screenshot me in the head with the naked truth: nobody said that your hollow tree had to be made of brown wood only. Actually, it quite makes sense that it would be invaded by moss, vines and other greeny stuff, especially if it's the resting place of the funghi ;)

Je m'étais mis en chasse de quelques souvenirs de jeux vidéos avec des arbres creux ... Mickey Magical Quest sur SNES ... Prehistorik 2 et ... ah bin non. Pas les rangers dur risque, finalement. Tout ça sans véritable coup de coeur: rien de vraiment utile. Par contre, j'avais passé déjà un certain temps à décortiquer le graphisme de l'arbre ronfleur de Rayman Origins (eh oui, encore lui ;) qui donne des pistes assez intéressantes. L'une d'entre elles ? Eh, qui a dit qu'un arbre creux ne pouvait pas être plein de mousse (et donc vert-sombre plutôt que tout brun) ? ... réponse : personne.

Primary Mechanics

Sauter n'est pas seulement un bouton d'action dans Super Mario, c'est ce que Kirby Kid appelle la "fonction première" (primary mechanic): c'est ainsi qu'il se débarrasse des ennemis, mais aussi qu'il obtient des bonus (bloc-question), transforme son environnement pour aller plus loin et découvre des salles-bonus. Bref, tout dans Mario est axé autour du saut, si bien que même lorsqu'il se prend une boule de feu dans les moustaches, ça reste quand-même la gravité qui l'achève.

When Kirby Kid names Mario's jump the "primary mechanic", it quite makes sense. Think a little bit at Super Mario Bros. gameplay and you'll be amazed at how many thing you do by jumping: stomping ennemies, grab bonuses and power-up, open path (by brick-smashing or vines-reveal ?-blocks). In later releases, even more sophisticated switches (P-switches, for instance) require a jump.

D'une manière surprenante, c'est loin d'être le cas dans tous les jeux de plate-formes. Oui, Rayman saute, et doit dans pas mal de situations sauter judicieusement pour éviter les obstacles. Mais la fonction première, ici, c'est le coup de poing téléscopique. C'est lui qui élimine les ennemis, ouvre l'accès en pulvérisant les rochers ou en mettant en mouvement les boules à pic.

What's more surprising is to realise that not all platformers use JUMP as the primary mechanic. That wouldn't be surprising for a run-and-gun game, but that's not even the case for games that would have filed under the generic platformer category as Rayman 1 or Shantae. There isn't that much you can do by jumping in Rayman. Throwing your punch away, on the other hand (^_^), keeps the baddies away, unlock path and set spiky balls to move. Of course, freeing the electoons involve punching the cage, not just touching it or pressing 'UP' on the D-PAD. And the most interactive element (the bouncing plum) in the game is completely punch-controlled.

Une prise à rebrancher dans les caves de Skops ? c'est encore d'un coup de poing bien placé que Rayman arrange ça. Clairement, il serait peu judicieux pour moi de reprendre un coup de poing téléscopique comme super-pouvoir pour Bilou, même si c'était le cas dans la version de 1996: c'est le "signature move" de Rayman, et celà ôterait à Bilou toute possibilité d'identité propre auprès des joueurs qui connaissent déjà le héros d'Ubisoft.

Et c'est loin d'être un cas isolé: Shantae, elle aussi, a un comportement "guerrier-platforme" où le bouton "frapper" est celui qui a la priorité, et ce de manière peut-être encore plus flagrante.
Que ce soit pour ouvrir les coffres, briser les jarres, déclencher les mécanismes et résoudres les énigmes, rien ne sert de bondir, il faut fouetter à point.

Assez curieusement, il semble même que certains jeux n'ont tout simplement pas de "primary mechanic". J'aurais bien du mal à en proposer un pour Commander Keen, par exemple. Les ennemis y sont généralement éliminés à coup de pistolaser, mais les interrupteurs utilisent une commande dédiée. La transformation du niveau passe presqu'intégralement par ces interrupteurs: Keen ne casse (presque) rien avec son pogo ni avec ses lasers, au point que quand les développeurs décident d'inverser la tendance, le joueur peut fort bien y perdre son latin (oui, oui, je parle des 4 fusibles à exploser dans l'épisode 5).

Now, it looks like some platformers I've played through my childhood did not even bother to have a 'primary' mechanic. Commander keen may shoot, jump and use his pogo stick, but none of this affects the game further than clearing jumps or disabling baddies. To progress, you need keys, and to activate switches, you use a dedicated look-up direction arrow. That's the only way you alter your environment to solve "puzzles". Stomping on things just don't help in any way. Neither do shooting on them (wise, since amno are limited). That's true to the point that when level designers decide to break the rule and *do* use one of the player's direct action to alter the level, the player is puzzled at best, and may need a FAQ lookup.


Titus the Fox is a bit harder to consider. Is the game's primary mechanic "carry", or doesn't it have any ? Granted, you carry things to use them as amno against foes. Granted, by not throwing things, you may use them and climb later on to access hidden areas. To fly through the sky, the Fox needs to grab and throw the magic carpet, but there's no such thing as a "throw target" that would release bonuses, nor objects whose state is changed from obstacle to platform by throwing anything on them. We can clearly say "it looks like Mario can't do anything without jumping". Can we say the same about Titus ? I don't think so, although I might be wrong.

Et dans Titus the Fox, la situation est encore un peu plus étrange. Le jeu possède bien un mot-clé: transporter, et à l'instar des Rangers du Risque, c'est en lançant des objets que le joueur se sort des situations à risque -- un élément que Titus met à profit en ne distribuant les munitions avec une extrème parcimonie ... et en forçant le joueur à prendre des risques dans le transport de certains objets pour grimper ou sauter, lui interdisant alors de lancer quoi que ce soit. Pourtant, je n'y vois pas cette richesse d'interaction avec l'univers du jeu qui me fait dire que le coup de poing de Rayman est "mécanique première" par rapport au saut ... sauf que ... allez, oui: c'est en s'abaissant pour prendre des objets que Titus/Moktar peut aussi se faufiler dans les passages secrets. Ca reste faible comparé aux blocs-questions, briques et autres carapaces de koopas, si vous voulez mon avis.

Blues Brothers -- Trivia

Le saviez-vous ? Bien avant la SNES, les Blues Brothers de Titus Interactive avaient été adaptés sur NES. Mais j'ai bien l'impression que les exigences de "politiquement correct" de Nintendo ont eu un effet néfaste sur le concept du jeu. Point de caisse à jeter à l'horizon. Exit les personnages loufoques tels que Mamie-Caddie ou la serveuse-championne-olympique ... Pas même de disques à collectionner. Bien pauvre. Ca n'a pas dû aider le succès du jeu.

Blue Brothers was one of the game I was most hyped about when neighbours started to get VGA screens and AdLib soundcards. Little did I know that the game had a NES release, but it seems like the fun of the game has been completely lost in the process. Its spirit did, at least, imho. Is that Nintendo 'politically correct' policy ? is it self-censor to reach more than the peculiar French video game market ? Is it just lack of space on a cheapest-possible cartridge ? I cannot tell

Dans ce speedrun, le jeu est terminé en 4 minutes chrono. Pas de gamin armé de lance-acide dans l'usine ... pas de Docteur-Maboule armé d'un lance-seringue dans la prison ... Que diable s'est-il passé? Il ne reste qu'à traverser des maps vides. Le monde impitoyable du jeu grand public ne cessera de m'attrister.

Le rétro-gameur averti boudera donc la cartouche pour se concentrer sur la version amiga qui ne souffre pas des habituels problèmes de scrolling rencontrés dans les portages PC des jeux Titus -- même si les bande-son Adlib me manqueront.

So if you want to retro-play the game, your best option is likely to hunt for an Amiga copy of it. You won't get the sweet adlib sound but your head won't explode with 8086-compatible push-on-demand scrolling. And you'll experience the full chemical kids, caddie-nanies and furious damsels high on heels fun of the original.

(Bilou progress report: une 3eme map scribouillée pour Apple Assault, polish des 2 premières maps ... tout ça malgré un Level Editor qui aurait encore bien besoin d'être débuggué...)

easy - *normal* - hard

Sur pas mal de points, je me retrouve dans la "philosophie du jeu de Locomalito". "Fun for a while, not entertainment for a long time" (chaque minute de jeu doit nous impliquer totalement), "Ingame secrets and optional stuff", "Free indie developers makes games for love" (un peu comme les dessinateurs du Gang Mazda), voire même "Difficulty and glory !". Mais il y a quand-même un point sur lequel je bute:

I think every game should have a single level of difficulty, according to the situations in it. For example, the end of an adventure game should be reserved for adventurers, the end of a war game for warriors... so a player can feel he has beaten a game thanks to his own skills and likes.

Celà suppose que tous les joueurs ont déjà acquis la maîtrise de leur pad et cherchent juste à s'essayer à de nouveaux challenges. Je me souviens du message de Prehistorik II "désolé, l'accès au chateau (et donc au boss final) est réservé aux joueurs confirmés. Revenez en mode "normal" (ou "hard" ?) et on en reparle. J'ai donc refait le jeu à nouveau, bénéficiant de la connaissance que j'avais des niveaux ... Si j'avais dû attaquer directement le mode "normal", c'était sans espoir!

Prenons Super Princess Peach. Jeu sympathique, mais au challenge limité. Peu probable que je le reprenne avant des années. Giana Sisters (version C64) me demande une maîtrise, et par son mécanisme de bonus, donne du sens au parcours répété des premiers niveaux: il faudra faire un "sans-faute" sur les 10 premiers pour bénéficier d'un atout pour court-circuiter la difficulté du no 11.

I agree with most of Locomalito's indie philosophy of games. There's just one thing ... Locomalito seems to assume that we're skilled and trained already. I can name games that have only one level of difficulty and that made it wrong -- Super Princess Peach, because that level is "I haven't played a lot of platformers so far" and Megaman for Wii (or Toki arcade) because its difficulty is so insanely high that you wouldn't make it to the first half-boss unless you've already cleared one game of the Megaman series. And I certainly needn't to name game that have multiple difficulty levels and that made it wrong, for instance because you need to beat the game in easy mode first to unlock hard mode (if easy mode is boring for you ...). Kirby's Dreamland (GB) imho did it the wise way by showing the player the cheat code to access hard mode once he beat the easy game. Will you get your hand on a lost cartridge 20 years later, you can try the challenge again.

Now he also said "the war game is for the warrior to complete, not for the ranger". Basically, that echoes Prehistorik II setup (for PC) where you'd be denied access to the last castle unless you're in hard mode. You just have a "happy ending", but you know you missed something. The thougher part of the game design then is to avoid blatant repetition of the experience of levels 1-N so that you can at last reach boss level N+1. Both Rayman for PSX suffers this design flaw, where you'll face a door requiring you to crawl some basic levels again and hunt for the last electoons. Same for Princess Peach and her toads. I don't remind of anything in the game experience warning me about this. At least level design of princess peach ensures you can focus on the missing toads when replaying the levels.

His claim also doesn't match games such as 'Maestro: Jump in Music' or "Soul Bubbles" where we're all newbies because of the innovating game mechanics.

Le petit Kirby's Dreamland (GameBoy), premier jeu de plate-forme que j'ai terminé, a une difficulté pour débutants: un joueur confirmé pourra atteindre le boss final en moins d'une heure. Après avoir mis une raclée à DeeDeeDee, un petit "v+select+A" me permet de choisir le mode "hard" ... où je n'ai toujours pas réussi à dépasser le 3eme monde, si ma mémoire est bonne. Résultat: à chaque occasion, j'y retourne. Même constat avec l'excellentissime "Maestro: Jump in Music" dont le niveau "easy" m'aurait laissé sur ma faim ... A ceci prêt que dans le cas de Maestro, les niveaux sont à peine reconnaissables d'un mode à l'autre. Mettre uniquement le niveau "normal" (ou hard) dans Maestro aurait provoqué un bide: dans ce style de jeu, nous sommes tous des débutants. Ils sont loins, les temps où on s'acharnait sur un Toki trop dur simplement parce que c'était le seul jeu à la ronde: le jeu doit à la fois offrir un défi consistant, mais aussi permettre au joueur de se faire la main. Mettre les deux dans une seule trame (et donc obliger le joueur confirmé à traverser 10 niveaux de tutoriel avant de commencer à être mis au défi) n'est certainement pas la bonne manière de faire...

PS: As you can see, *my* philosophy of game design isn't settled yet. I'm not sure I've been consistent in my rambling

Let's >> scroll >> baby ...

edit: screentoaster, video.google.com ... all these are no longer operating and not covered by the wayback machine. Link replacement in progress

Hop. Un p'tit temps de midi et je rattaque le scrolling, maintenant capable de "suivre" véritablement Bilou (plutôt que de se contenter de mimer ces déplacements au risque de finir par le faire sortir de l'écran :P) Le plus délicat, c'est d'éviter un scrolling "par à-coups" comme on avait tendance à le voir dans les jeux Titus, ou (pire) dans le Game Maker de mon enfance :P

It's about time I focus on scrolling again, so that we can actually "track" Bilou's position. So far all it did was mimmic'ing Bilou's moves but as you hit ceilings and floors, it slowly gets off. I realise when playing games of my childhood that a smooth and smart scrolling is the key to a great platformer experience. 

I want to avoid "quantum leaps" that was typicall from Titus games and that sloppy "I'm following you at my speed don't move soo fast" scrolling coded in the Recreative Game Maker my Brother and I used for Badman series.

J'ai eu droit à quelques effets marrant en débuggant (ou déboguant?), comme l'écran qui fait le point-fixe autour d'un moustique invisible tournant autour de Bilou (ça, ça fait mal aux yeux), d'où les dernières lignes) ... ou alors le scrolling qui fait des sauts de puces en arrière après avoir fait un pas de géant en avant ... Bref. Le dernier truc qui reste douteux, c'est le fait que l'écran scrolle presqu'immédiatement vers le haut dès que Bilou saute ... je suis pas fan (ça donne un peu le mal de mer), mais je ne vois pas trop comment l'éviter proprement.

As usual, there has been some odd-and-funny bugs while working on it, such as the camera suddenly tracking "a bee that fly around Bilou" rather than tracking Bilou himself. The last 4 rows of code shown above are designed to avoid that : they prevent counter-centering moves from happening. Yet, it turns out that perfectly keeping Bilou in the center of the screen isn't so sexy. You quickly get sick when you jump often ...

I dug for Commander Keen videos, where you can observe a surprising but efficient approach. The camera only keeps Keen in the center of the screen (vertically) when he's on the ground (not quite at the center, but almost. I'd say some 32 pixels lower than the centre). However, when Keen jumps, the camera remains at its current height, giving a better view of where you're going to land. The only exception is when Keen gets really close to the edges of the screen (some 8 pixels close from the top or 32 pixels close from the bottom). Only when Keen *lands* does the camera quickly bring him back at the center of the screen.

Si on compare, la politique dans Commander Keen est assez particulière. Tant que Keen est au sol, il est maintenu dans une zone proche du centre (pas exactement au centre, mais presque; je dirais à 32 pixels du centre au maximum), mais lorsqu'il saute, on ne scrollera verticalement que si Keen approche le bord haut (ou bas) de l'écran (je dirais de 8 pixels au moins, probablement plutôt 32 pour le bas), et ce n'est qu'au moment ou Keen "atterit" sur une plateforme que le scrolling vertical se recentre. Je trouve que c'est un assez bon choix en somme : celà permet de conserver le point de vue que le joueur avait au moment de prendre la décision de faire un saut, et donc de mieux gérer l'endroit où le personnage retombe, tout en ayant un bonne vue d'ensemble du niveau pendant que le personnage "marche", tout simplement.

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.

Tiens, tiens ...

J'ai envie d'en rajouter une couche sur Prehistorik 2... Un jeu assez intriguant sur bien des rapports, et que j'ai envie de qualifier de "démo la plus impressionnante pour un jeu de plateforme sous DOS". Car il faut bien l'avouer, avec ses 15 niveaux tout mouillé, Prehistorik 2 est loin d'un rayman du point de vue de la longueur du jeu ... Et pourtant, les niveaux sont souvent d'une densité et d'une originalité qui fait défaut à bon nombre de jeux console.

Coté musique, rien à redire. Des mods multi-voix rendus en temps-réel, c'est à peu près ce que l'on pouvait faire de mieux à l'époque. Elles collent bien au jeu sans être trop gourmandes en ressources. Côté graphisme, je voulais vous mettre Prehistorik 1 (à droite) et 2 (à gauche) côte à côte. J'ai joué au deux des semaines entières, et je n'avais jamais remarqué que le décor du premier niveau avait tout simplement été repris de l'un à l'autre! C'est dire si l'animation des monstres en tout genres faisait la différence! Et pourtant, en jetant un oeil à la planche de sprites, on ne peut être qu'étonné par le faible nombre d'images qui ont été utilisées pour obtenir ce résultat. C'est bien simple: alors que pas un bonus ne reste fixe, la plupart ne dispose que d'une seule frame, que l'on a simplement fait rebondir.

Si je dis que le jeu fait figure de démo, c'est parce que depuis, j'ai eu l'occasion de tester la version SNES/GBA (cf image à gauche). Beaucoup plus colorée, avec des personnages qui tiennent plus du dessin animé que du sprite de jeu vidéo (ce que beaucoup prendront pour un avantage, j'en conviens) et plus rallongée. L'ensemble a subi une sorte de refonte scénaristique typique de chez nintendo, et on voit débarquer l'ancien du village (et sa fille), le forgeron-qui-fait-des-armes, l'inventeur-génial qui vous trouve de nouveaux moyens de déplacements tous plus farfelus les uns que les autres (pas loin de 4 en tout, si j'ai bonne mémoire, du pogo-stick au monocycle en pierre digne des pierrafeux) mais quelque-part, ça sent le prémaché ... Le "mass consumption" où il n'y a plus aucun clin-d'oeil au monde des jeux vidéo et où l'originalité du premier jeux (les passages secrets et téléporteurs) ont presque complètement disparus au profits de niveaux plus longs, mais aussi un peu insipides.

En revanche, on a droit à l'habituelle débauche d'effets (feu, lave, flotte, etc) que permet le hardware des console. C'est un peu curieux comme résultat. Comme si les joueurs de consoles étaient obligatoirement des gens avec lesquels on ne peut pas se permettre le moindre écart dans le gameplay traditionnel. Un autre exemple? Dans PH2-PC, chaque niveau comportait trois élément principaux: la sortie (un gros feu-rouge), un briquet géant qui permet d'allumer la marmite dans laquelle vous allez faire une méga-soupe avec toute la bouffe récoltée (indispensable pour que la sortie soit activée) et le code qui permet de reprendre le jeu depuis ce niveau.

Bin côté console, il n'en reste pas grand-chose. Exit les feux-rouges et une bestiole bizarre les remplace comme point de sauvegarde. Un peu comme si tout anachronisme aurait nuit au jeu alors que ça faisait son charme. On vous explique bien par-ci par-là que "groumpf! pour faire ton delta-plane, il me faut absolument de la peau de lion tacheté" et que "groarf. Je t'ai fait une nouvelle hache tu en auras besoin pour les bêtes plus coriaces".

A la place le joueur PC voyait juste la hache (ou le super-marteau) en question se balancer dans les airs. Ne vous tracassez pas que l'on comprenait aussi bien et que le fun était quand-même au rendez-vous quand tout le sol tremblait au son du "Breum!" gigantesque de ce marteau démesuré...

(images de www.abandonia.com/games/en/4/Prehistorik2.htm et prehistorik.milichovsky.com/zmeny.htm)

Les Secrets de Titus

Je suis tombé sur deux mines d'or: http://ttf.mine.nu/ (le fan club de Titus the Fox) et http://pre2.mine.nu/ (le fan club de Prehistorik 2)

"Titus Interactive was a long-running French software publisher that produced games for various formats over its lifetime." Voilà ce que Wikipedia nous apprend sur Titus, la société qui a écrit et produit Prehistorik, Titus the Fox (aka Moktar), et bien d'autres. Pour moi, Titus Interactive, c'est tout une époque... Les jeux DOS à la limite de l'impossible, bourré de bonus cachés, de monstres vicieux à côté desquels les Blôrks affrontés par le barbare de Kid Paddle font figure d'enfants de choeur en barboteuse rose à fleurs!


Titus interactive, ce sont des heures et des heures passées chez Alain Gillon ou Vivien Vanoirbeek à chercher après la caisse qu'on allait bien pouvoir balancer sur ce pocheron-lanceur-de-fléchette qui nous barrait la route tout en évitant les bouledogues survitaminés et les poubelles farceuses.


Titus Interactive, ce sont encore plus d'heures à fouiller le niveau à la recherche de cette porte cachée (comprenez: un emplacement quelconque dans le jeu où vous allez être téléporté vers un nouvel endroit à condition de rester "accroupi" 3 secondes), et de stress intense quand enfin apparaît la lampe magique (si, si) ou l'item généralement quelconque révélateur du code hexa qui permettra de reprendre depuis le niveau en question, dans un univers où les sauvegarde dans les jeux vidéo n'existaient que pour les aventures "pointer/cliquer".

Titus Interactive, enfin, c'est la migraine garantie quand on rentrait chez soi les doigts en feu, surexcité, et ayant passé toutes les heures sus-mentionnées à subir un scrolling brutal (genre "page down" dans firefox) chaque fois que le personnage s'approchait un peu trop du bord de l'écran... et quelques claviers dont la barre d'espace a été rendue complètement inutilisable.

Grand merci, donc, à Jesses pour ses deux sites en or... Et à tous les employés de Titus Interactive qui ont participé à nos rêves de gosses au dépend de leur salaire (j'espère qu'ils s'en sont sorti plus tard, et s'ils veulent un taré pour porter tout ça sur DS, je signe dès l'année prochaine -- peut-être)

I am somehow nostalgic towards that era where "gameplay" and "level design" were words you never needed when talking about a video game. It was the era of DOS games, when designers knew the game's lifetime is inversly proportionnal to the character's lifetime -- the era of Titus Interactive.

Relaying on our neighbours' keyboard, we were trying to duck foes' shots, hunting for hours the throwable crate that we could use to dispatch the next grumpy and vicious monster that was blocking us on the path to the HEX code that we could use to restart our quest at the same level. Then other hours were wasted searching for "hidden doors" that would give us the additional lifepoint we were missing to reach the end of the level ... once we found it :P

We then came back at home for dinner, with our mum asking what we did to get such headaches (if only she knew how basic scrolling was!) and how on earth we could be that excited ... Thanks Jesses for your goldmine websites ... and thank you, all dev'ers at Titus Interactive who built our dreams at the expense of your salary.