Courir ?

En testant la démo "Back to School", Facet regrettait l'absence d'un bouton "RUN" dans le comportement actuel de Bilou. D'un côté, un mini-jeu comme "nuts'n'bolts" ne devrait pas avoir besoin d'un tel bouton (pas de grand trou à franchir, et un gameplay plus basé sur le timing que sur les réflexes). D'autre part, je ne suis pas encore décidé sur le mode de fonctionnement de la course.

Il faut un bouton pour courir, ça c'est assez évident. Mais sur le DPAD ou comme bouton d'action ? Est-il vraiment indispensable de le garder enfoncé tant qu'on veut courir ? A la fin d'une partie de Mario, on finit par attraper des crampes... Pourtant j'aime bien la phase "gagner de la vitesse" que ce genre d'approche permet, par rapport au mode "un coup de bouton X et ça y est, on court à pleine vitesse" dans Rayman. Au point que Peach et Shantae ont carrément un bouton "ne pas courir".

Have you felt the lack of a RUN mechanics in the latest Bilou demo too ? Facet surely did.

I was really missing a run button and the little pauses and lack of inertia take away from the fluidity. I'd like to bounce and slide more.

After I spent some time thinking about it, it becomes clear that "Bilou's adventure" will have such a RUN mechanics, where speed progressively increases, but that this would be absent of "Nuts and Bolts" (and possibly other in-between arcade games featuring Bilou).

I would like, however, to be able to release the button, and not force the power-player to keep RUN button pressed for 30 minutes if he wants to speed-run the game. Fundamentally, what I'd love to try is a sort of "cruise control" behaviour, where you press a button only when you want the DPAD to make you "accelerate". Once you release that button, you keep moving at the reached speed until you release the DPAD as well.

Mon impression, c'est que le fait d'accélérer progressivement ou non peut être découplé du mécanisme de "lecture" du gamepad. En d'autre termes, on pourrait avoir un bouton qui n'est pas "courir", mais "accélerer". Si le joueur mêne Bilou dans une direction sans enfoncer ce bouton, Bilou ne change pas d'allure. Par contre, dès que le bouton "accélerer" est enfoncé, la vitesse de Bilou augmente (plus ou moins) progressivement jusqu'à la vitesse maximale. Que celle-ci ait été atteinte ou non, Bilou conservera la vitesse acquise si on relâche le bouton d'accélération.

The poll is now open: which sort of RUN do you actually prefer ?
Mario: 62%
Rayman (PSX): 12%
Shantae: 0%
Kirby: 0%
Bilou (new): 25%

Synopsis

Possibly the very first Bilou level drawn by my brother

Quand Bilou était dans son jeune age et prévu sous Amiga/CPC, mes niveaux "tombaient du ciel", dessinés par mon frère. Je n'avais plus qu'à les "pixeliser". Mais maintenant que la "computer zone", la "turtle zone" et la "pyramid zone" ne sont plus d'actualité, que la "water zone", la "pipe zone" et la "fire zone" ont besoin de sérieux relooking, comment envisager la structure globale du jeu ? pas avec mes mini-démos, qui serviront au mieux à introduire quelques personnages ou tester un principe de jeu.

Je pensais donc essayer de placer sur une carte unique l'ensemble des "lieux clés" (puits de la clairière, temple de l'encre, la boule de neige dans l'usine chimique du Groenland, etc.), chacun occupant un ou deux écrans DS (allez, disons 512x512 pixels au max), ce qui devrait permettre de me concentrer sur les "interactions majeures" (genre 'au sommet de la montagne infernale, tu trouveras la vanne qui contrôle le niveau du Lac Those), et donner les grandes lignes de chacun des lieux. Restera ensuite à migrer "Synopsis" vers le jeu complet, en y ajoutant les phases d'actions.

... and a second take when it become "level B", a couple of year later

Back then, in the earliest days of the Bilou project, I hadn't to worry about game or level design. My brother had some Great Plans in mind and provided me hand-drawn maps that I could simply "pixelate" and code. Unfortunately, he never drawn anything past the green and school zones, and most of the other "zones" he named are questioned today (turtle zone and computer zones needs a replacement, fire and water zone clearly need more character).

I'm reaching a point where I'd like to have a better understanding myself of what happens on the curious planet where Bilou and Bouli crashed. The small one-feature demos that I planned as milestone won't help me with that. Sketching a few idea for my Bro's next CD, I ended up thinking that I could equally sketch the game's synopsis as a collection of "small rooms" (one per "encounter", max 512x512 pixels in size) that would represent the core goal of individual levels in a more "willy-inspired" game where the exploration dimension would be enhanced, and action dimension reduced to a minimum.

Oh, and btw, I haven't dropped the "Apple Assault" milestone, before you ask. I'm just waay too busy with painting and building up my new kitchen to make any noticeable progress there right now.

Au fait, avant que les questions ne fusent: non, je ne laisse pas tomber "Apple Assault" à 90% de l'objectif: je suis juste légèrement accaparé par le montage de ma nouvelle cuisine :P

B_CRUMBLINGFLOOR

Somehow, I stumbled upon this re-implementation of the Manic Miner / Jet Set Willy engine in Visual Basic. I'm unsure on how I should implement crumbling ground in Bilou (or any block animation in response to character's presence). Let's see how a +20 year old game handled it...

Bon, je l'avoue, je suis intrigué par la quantité d'"éléments spéciaux" présents dans un jeu aussi vieux que "Manic Miner" contient, et la difficulté que j'ai à trouver une manière convaincante de réaliser la même chose dans mon moteur de jeu actuel. Du coup, j'ai mis la main sur une ré-implémentation du jeu en Visual Basic. Voyons donc comment les blocs-qui-disparaissent-quand-on-reste-dessus ont été gérés ...

' block type constants
Private Const B_CRUMBLINGFLOOR      As Byte = 2

Block types are encoded in a separate array, with one byte per 8x8 tile. One such type is "crumbling floor". Other block types include B_AIR, B_FLOOR, B_WALL, B_CONVEYOR and B_NASTY (two of them) and B_SPARE (for switches). Jet Set Willy only has one B_NASTY type, and the other one is converted into B_SLOPE. This is consistent with my own engine.

Carles a construit son moteur de Willy de manière à réutiliser les données du jeu telles quelles -- sans être le code original sous Z80, ça donne malgré tout une bonne idée de ce qui aurait pu être fait. En l'occurence, par exemple, la structure de chaque niveau est donnée par un tableau de la taille de l'écran, indiquant quels graphismes utiliser, mais aussi le type de chaque bloc entre 0 et 7.

B_CRUMBLINGFLOOR est celui qui nous intéresse. En cherchant "crumbling" plus loin dans le code, je tombe donc sur la fonction DoWilly (extrait ci-dessous) qui gère toutes les interactions entre Willy et le monde qui l'entoure. DoConveyors ne fait qu'animer des blocs, de même que DoGuardians se contente de déplacer les monstres. Ce sont les sous-fonctions de DoWilly qui détectent les collisions et altèrent le déplacement du personnage. Exactement le genre d'approche que j'utilisais dans Calimero et Bilou en QuickBasic.

What's interesting (for me :-) in Carles' approach of redoing Willy's world is that he operates directly from the tape file of the spectrum, so not only it has the "readability" of modern BASIC (i'm not that much into Z80 assembly ^^") but it still explains the logic of the original game (how switches, witches and stuff are encoded).

If (.mode = [eWalk]) Then
  If Not (WillyCheckFeet()) Then
    ' code for falling stripped out ...
  End If
  Call WillyCheckConveyor(keys)
  Call WillyCheckCrumblingFloor
End If

The DoWilly() sub shown above proceed step by step, handling interaction of Willy with every item "present" in the game. That is, we have DoConveyors or DoGuardians as well, for sure, but they merely perform animation and movement job. WillyCheckConveyor makes sure conveyor pushes Willy. That's the real job.
Let's thus have a look at WillyCheckCrumblingFloor just below ...

Voyons donc WillyCheckCrumblingFloor dont le code est ci-dessous. Après s'être assurée qu'il y a bien un bloc friable sous les pieds de Willy, elle va utiliser FXCrumblingBlock pour procéder à l'animation (décalage du tile d'un pixel vers le bas) et transforme les propriétés du bloc donné en "B_AIR" si FXCrumblingBlock lui dit de le faire à travers la variable f.

o = .x + (.y \ 8 + 2) * 32
For c = 0 To 1
  If (m_RoomBlock(o + c) = B_CRUMBLINGFLOOR) Then
    Call FXCrumblingBlock(m_DIBBack, 8 * (.x + c), .y + 16,
                          CAPaper(m_RoomData(o + c)), f)
    Call FXCrumblingBlock(m_DIBMask, 8 * (.x + c), .y + 16,
                          I_BLACK, False)
    If (f) Then
      m_RoomBlock(o + c) = B_AIR
      Call FXRect(m_DIBBack, 8 * (.x + c), .y + 16, 8, 8,
                  CAPaper(m_BlockCA(0)))
    End If
  End If
Next

FXCrumblingBlock will not be shown here, because it's a pretty dirty function that mixes up game logic, tile animation and rendering engine commands. What I can tell you is that everytime it is invoked, it scroll downs the data of that specific tile, and insert a "blank" line at the top. Once this is done, it scans the whole tile again and sets the "cleared" flag (variable f) to false if it found any non-blank pixel. That's precisely what triggers transformation of B_CRUMBLINGFLOOR into B_AIR.

As the tile "crumbles" exactly one pixel per frame and Willy walks one pixel per frame, it means if you simply walk on crumbling floor, it will be completely crumbled when you're done walking.

Pour moi, c'est là que le bât blesse: FXCrumbblingBlock mélange allègrement rendu vidéo, manipulation des animations et logique du jeu. Je ne la reprend donc pas ici, sachez juste qu'elle décide si oui ou non l'animation est finie en parcourant les pixels qui viennent d'être édités. Si tous les pixels sont "transparents", c'est qu'il n'y a plus du tout de sol et on peut remplacer B_CRUMBLINGBLOCK par B_AIR.

Là-dessus, je vous laisse bras-dessous: il est temps que je prépare ma pitchounette à aller rechercher ma fée à Belle Ile. Ciao.

Foiré.

En dessinant les boulons et les écrous à ramasser dans le prochain jeu, j'ai bousillé un "tile" plus critique que je ne le pensais : l'ombre portée par les blocs sur la terre. Voilà qu'il contient des morceaux d'écrou sur fond transparent >_<

Bon, ce n'est pas la fin du monde: j'ai bien évidemment ce tile-là en backup dans un autre fichier, mais je n'ai par contre encore aucun outil permettant le transfer de tiles d'un fichier à l'autre ... du moins pas sans prendre le risque de voir les anciens tiles déplacés au point que les maps des deux niveaux existants ne pourraient plus être utilisées comme terrain d'entraînement. Bref, attendez-vous à un peu de bricolage sur SEDS la semaine prochaine.


Aouch. I was happily drawing nuts and bolts for the next little game, and I smashed a tile that seems to have much more importance that I initially thought. The shadow around ground blocks is gone, replaced by a piece of bolt.

I still have it in former backups of my tileset, of course, but I have no tool that could easily bring back the two of them without potentially damaging the mapping of the tileset to a point that the two levels I already have would become useless... I might be messing with SEDS to fix that in the next few days.

PS: we now have a "scrolling" tag with updated translations.

Todo ... later

Time to compile a list of "pending issues" that I'd like to see resolved to progress in my projects. Only then I can actually start adding support for vines, moving platforms, conveyers or whatever else fancy stuff "Bilou Mining" could use.

• [testing ...] stand and land on slopes
• [done] fix vertical scrolling issues (cf. Morukutsu comment)
• [done] a "pause" action that dumps GOB state and stops the game engine so that I can proceed with collision debugging.
• [done] properly stomp applemen (woodworms seems ok in gedsdemo)
• [thinking ...] load any background music from the gamescript
• [done] require a press on a button to trigger a jump.
• improve berrybat's behaviour
• [wish] animXX mirror animYY to ease coding of .cmd files.
• [done] explicitly export states from monsterxxx.cmd into levelxxx.cmd
• [done] (refactory) give monsterxxx.cmd its own namespace for animations.
• [done](refactory) 'on event ...' transitions bound to micro-controllers and 'on fail' transitions to testpoints, the same way 'on hit/found' are bound to test/area statements.
• [done] (refactory) stateXX..YY->stateZZ on event [...] (...) to allow a transition from multiple input states.
• (wish) a "media manager" to avoid redundant loading of maps, spritesheets, modules, ...
• [done] (bugfix) make sure all OAMs are disabled when a new level starts.
• [done, afaik] (leds, bugfix) newly cloned monsters should be playable too.
• [done] (gfx) draw collectible nuts&bolts
• [done] (gfx) a separate frame when Bilou gets hit.
• [done] (leds) "play" button that saves the current .cmd file as "autoexec.cmd"
• [done] (blog) widen the view, update heading banner
• [thinking ...] blocks that fall/disappear after Bilou walked them (incl. gfx).
• (leds, bugfix) You might have several times the same gobno allocated ??
• (leds, bugfix) Cursor for block-picking doesn't work properly ??
• (seds) more "storage areas" : tileset, sprites, anims, sketches
• get the garbage out of the kitchen tonight

Bon, bin y'a du boulot! Entre les bugs dans les la maturation des fonctions expérimentales de LEDS, les graphismes à rajouter, les commentaires de Morukutsu sur la jouabilité, les difficultés pour le debugging des collisions Bilou-Appleman (les applemen étant invulnérables de temps en temps sans que ça ne soit prévu) et le "refactoring" nécessaire pour pouvoir continuer à gérer plus de monstres correctement ... Alors seulement on pourra commencer à penser à des plate-formes mobiles ou des tapis roulants.

Do you sass' ZX Willy ?

"Connaissez-vous Manic Miner et le ZX Spectrum ?" me demandait assez logiquement nicolas.guigoz dans un commentaire récent. Je n'ai pas eu de spectrum, et j'aurais répondu IRL "c'était pas le micro avec les touches molles ?". Je sais via "pixelation" que c'est ce micro-ordinateur bizarre (probablement à base de Z80) qui, bien qu'ayant un affichage 16 couleurs, ne pouvait utiliser qu'une couleur par caractère de 8x8 et n'avait pas de sprites. Si bien que quelque soit le jeu, ça ressemblait assez invariablement à un livre d'image colorié par un gamin qui ne sait pas éviter de déborder des contours. Maintenant, j'imagine que pour celui qui en a possédé un gamin, c'est une merveille de nostalgie au même titre que le c64 l'est pour moi et l'amstrad CPC pour Pierrick H.

All I could have told about the ZX spectrum before starting this post was that it had soft keys and tend to spread colors all over the place on polychromatic screens. I couldn't have said anything about Manic Miner unless you would have asked about the Jet Set Willy sequel which my brother had tried a bit on C64.

Willy, revisited by Arne

Pour ce qui est de Willy (Jet Set Willy, Manic Miner), je ne connais que depuis la sortie des "Lost Levels" sous DS. D'ailleurs, c'est bien simple, quand en juin 2007 Arne nous poste ce joli mock'up sur Pixelation, je me dis juste "que c'est bien fait pour du 16 couleurs. Mais où va-t-il chercher tout ça ?". Le parallèle était pourtant frappant.

It needed a Lost Levels homebrew, released on DS in June 2007, to make me realise that the mock up screen titled "Macaroni Ted" is a reinterpretation of an old game, not just some awesome flip-screen for a yet-to-code game. And I have to admit that I'm baffled by the creativity it took to fill so many screens of challenges involving so many weird characters, even on the 8-colors original game.

Mais indépendamment des qualités du jeu, de l'"ingéniosité" des niveaux et tout ça, je n'accroche pas. Ni aux "lost levels" flambant neufs, ni à l'idée de me le refaire sur un émulateur.

Lost Levels par Headsoft

La maniabilité de Willy redore le blazon de l'explorateur de Pharaoh's Curse et de Thing on a Spring. Et pourtant, j'ai passé plus de 900 vies à finir "vvvvvv" ... Alors quoi ?

Premier hic, la lenteur. Eeeh oui. Si Willy nous change de l'animation en deux temps de Rick Dangerous, en revanche, il est trop lent à se déplacer, bien plus lent que votre "projection mentale dans le jeu", ce qui pour un jeu de "timing" est particulièrement désagréable.
Autre hic -- de taille -- la lisibilité. Se faire tuer par quelques pixels qui trainaient par là et qui ressemblent autant à un buisson qu'à une clé, ça n'a rien d'amusant. La version GBA est un peu plus lisible (sans aller jusqu'à dire qu'elle est meilleure pour autant). La version ancienne (ZX) est assez bien lisible (si ce n'est pas noir ni du sol, touche-le pas) et d'une difficulté sans doute plus progressive. La preuve c'est que j'ai réussi à aller au niveau 2.

Unfortunately, once I have the game in hand, I absolutely don't want to play it. Controlling the explorer in Pharaoh's Curse or even the thing on a spring is fun compared to Willy. I think this is linked to how slow the walking animation is. I cannot make my mind match that and I'm never quite accurate on where I expect the character to be when it will be time to ask it to jump or to stop.

The second big issue with Manic Miner Lost Levels is the readability. In the original game everything is either black, flat, blinking or dangerous. small patch of pixels actually depict a deathly trap on the floor and you should jump above it.

Je vais donc éviter de jeter un blâme et je ne me lancerai pas dans des calculs savant de temps-pour-traverser-l'écran divisé par temps-de-réaction-pour-contrer-un-monstre. Il est clair que si j'ajuste le gameplay de Bilou, ce sera légèrement, de sorte qu'un monstre isolé représente déjà une difficulté (là, s'ils ne sont pas au moins deux dans un environnement exigu, le jeu est plutôt de voir combien de fois vous pourrez vous gausser grassement d'eux avant qu'ils ne vous touchent). Mais je n'irai pas cloner le gameplay de Manic Miner... Ooh non, alors!

Il est clair aussi que ce qui fait le "charme" des aventures de Willy, c'est ce côté "hors-contexte" des monstres et des salles, renforcé par le fait qu'il "suffisait" de 8 chiffres pour "programmer" une dalle et d'une douzaine de dalles pour un niveau. J'ai beau me débrouiller en pixel art, je ne suis pas graphiste. Il faudra donc que je trouve quelque-chose d'autre pour rendre le "petit puzzle-platformer avec Bilou" suffisament attractif. Je laisse donc tomber le "mining" du titre, la prochaine "milestone" sera tout simplement

Bilou : Nuts & Bolts

Yes, I'd love to have something that looks a bit like a Manic Miner game featuring Bilou. Flip screens, a few baddies per screen, things to collect (nuts and bolts from the crashed ship). But it wouldn't feel like a manic miner game. I'd adjust some physics constant so that individual ennemies requires precision, but not the kind of pixel-perfect precision manic miner implies.

PS: ça veut dire "des boulons et des écrous", et je trouve que ça colle bien au fait de devoir retrouver les pièces de l'astro-cruiser tout éparpillées ...
PPS: une vitesse verticale de 600 pour commencer un saut paraît bien pour ça. Ca rend déjà le champignon dans le premier arbre inaccessible, par contre :P
PPPS: je n'oublie évidemment pas les choses que j'avais trouvées sympa dans Johnny Biscuit (rotation des thèmes graphiques plutôt que 4 niveau halloween, puis 4 niveau en égypte, puis ...) et dans Qwak (parcours semi-aléatoire d'une partie à l'autre).

Voir aussi :

• manic miner (lost levels) screenshot sur pdroms
• manic miner (niveaux d'origine, graphismes retouchés) sur DS, par Alekmaul

grimpons, grimpons

Bon, c'est pas le tout de dessiner des pixels de lianes/vignes sur lesquelles grimper. Maintenant, il va falloir coder ça, aussi. La base est relativement simple : un nouveau type de tile qui permet l'utilisation du comportement "grimper", au même titre que le sol permet de marcher.

C'est plutôt le passage d'un autre état (à l'arrêt ou en saut) vers l'aggripage de liane qui va demander une attention particulière. Deux éléments entrent en ligne de compte :

1. le joueur appuie-t-il sur la flèche vers le haut ?
2. Y-a-t'il une liane à laquelle s'aggriper ?

La deuxième question revient à un test du type "cando(...)", à ceci près qu'il ne fait pas partie du comportement "normal", mais qu'il risque de devoir être évalué depuis les transitions de la machine d'état.

Of course, just having pixels for the vines is not enough: it's time to start thinking about the code that will let us grab and climb them. I have a few technical problems that need to be solved before code can be written down.

One of them is that you can climb a vine (assuming you're on the ground) only when you're exactly below it. From a gameplay point of view, this is unacceptable, so something will be required to make the vines "magnetic" so that the player is automatically placed at the right position when he attempts to climb while being "sufficiently close to the vine".

Second, to be able to grab the vine while jumping, I need to alter the behaviour of "jumping" and "falling" so that it raises an event, which forces transition towards new states to be evaluated. But I do not want such event to be raised at every frame when the player holds 'UP' dpad while jumping. I am still undecided on how I should make the fact that a vine is present available to the state machine expressions -- and potentially, same kind of info will be required for swimming in water and slippering on ice.

Autre petite difficulté technique en vue : lorsqu'on est au sol, il n'y a a priori qu'une position où il est effectivement possible de monter à une liane : quand on est pile sous celle-ci. Du point de vue du gameplay, ce serait l'horreur d'imposer ça et il faudra donc programmer une sorte de "magnétisme" qui positionne le joueur qui tente de monter à une liane juste sous celle-ci s'il n'en est pas trop éloigné. La solution s'ébauche, mais ce n'est pas encore assez précis à mon goût ...

Bilou Mining, donc.

Am I ready for this ? ...

Vous n'êtes pas du genre contrariant, hein ? je mets sur "papier" une série de petits jeux rigolos que je pourrais réaliser plus ou moins rapidement sur DS avec Bilou compte tenu du code et des graphismes dont je dispose maintenant, j'organise un petit vote, et qu'est-ce qui sort vaincqueur ? Exactement ce que je suis occupé à faire depuis l'an dernier. Autant pour le vent neuf de l'an dix, tiens. Voyons donc ce que donne le mockup d'arachne réchauffé à la sauce Bilou ...

Arachne's seminal mockup

I guess I'm just happy if Arachne don't kill me for this one. I'm quickly doing a mockup of Bilou in a "mining for ... stuff" minigame, using her own mockup as a base. Indeed, despite all the alternative I suggested, according to the poll, you seem to prefer that I keep focusing on the current line of demos. Since I don't see why Bilou should gather all the apples of a level to clear it, I prefer keeping fruits as "optional" bonuses and claim that the goal of "Bilou Mining" will be to recover all the nuts and bolts from the crashed Astro-cruiser.

On va donc continuer dans l'optique "ramasser les items et atteindre la sortie", mais plus des pommes cette fois-ci. Il me faut des "clés" qu'il est indispensable de collecter, les fruits servant uniquement à juger le "style" -- départager le maximum d'entre les maxima, comme disait Popo. Bin ce sera les boulons de l'astro cruiser. voilà.

Shantae, again

Mais un gameplay "à la Manic Miner" a des exigences tout de même un peu différentes d'un SuperMario. Tout d'abord, le timing est la clé du succès, plus que votre adresse à défier la gravité. Il faudra donc que je revoie l'armement de Bilou.

Ensuite, il faut que le joueur puisse avoir une vue d'ensemble du challenge, ce qui colle bien avec la taille de Bilou, un peu moins avec la hauteur de ses sauts. Finalement, il va falloir grimper à des échelles et ne pas trainer sur des plate-formes éphémères. Et là, c'est plus chaud: je n'ai toujours pas réussi à dessiner des lianes convaincantes en couleur. L'idéal, ce serait quelque chose approchant les arbres de Shantae DS (voir les images de référence en bas du post).

ma tentative pathétique de s'en approcher ...

I expect subtle changes to happen on the current gameplay to match that objective, though. At first, jumps should be shorter so that I can put more of one challenge on the screen and have an increased "puzzle" dimension by letting the player observe the level and decide of its strategy rather than reading and reacting promptly as in a SuperMario game. This also suggest that we should have more than stomps to dispatch baddies. Collectible weapons are likely to appear. But most of all, to pack more action per screen, I'll need ropes and ladders ... that is, vines, in this green woods stage. Unfortunately, all my attempts at drawing something (even just slightly) similar to the vines found in Shantae DS is a total wreckage so far.

Je me suis donc fait un petit tour de flickr-vgmaps-f-spot pour essayer de collecter un maximum d'images de référence. Ca a un peu amélioré le résultat mais pas énormément. Je gribouille donc des lianes un peu partout sur des bouts de papier, je m'arrête au milieu d'un niveau dans SPP pour chiper les marqueurs de ma fée et redessiner les haricots magique qui dépassent des nuages dans le monde du ciel. Pour changer, j'ai dessiné d'abord la forme dans un pavé 32x32 et je lui ai donné du volume avant de la "zoomer" en 64x64 pour ajouter les détails et peaufiner le look.

I've collected quite uselessly tons of reference pictures, until I stumbled upon that magical-bean-plant-seen-over-clouds in the Glidy Sky of Super Princess Peach. I loved the simple elegance of that ?-shaped curve that renders all my previous attempts pretty obsolete. And I actually managed to reproduce it by sketching it first on a 32x32 draft (including colors and shading) before I zoomed individual quarters of that draft to a 64x64 canvas that I could further refine. Graphically speaking, I'm quite happy with the result, except that it is completely useless from a gameplay point of view. Still I've used its "curved head" in the mock-up as ladder and as anchor for the "berry-spiders".

EDIT: entretemps, le projet a été renommé "Nuts&Bolts"

Days left to vote: 4

Avis à ceux qui suivent ce flux uniquement par RSS, vous n'avez probablement pas remarqué le petit "sondage" sur les différents mini-jeux candidats pour la prochaine milestone. Il reste 4 jours pour voter.

Clickez ici pour relire le post et enregistrer votre vote

You may be reading this with a RSS reader, in which case you've likely missed the "poll" that came together with my previous post on the candidate mini-game for the next milestone. You've got 4 days left. Go! Go! Goo!

Bilou Dreams : Clone it !

As I said earlier, while the final "Bilou" project is a story-supported large platformer (yeah, think of Rayman vs Mr. Dark, you've got it) with a supporting game-making toolset, I know from my experience that I must split that down into chewable chunks unless I want to drop the project before anything is realised. The current "milestone" is a "explore, collect, think, collect, finish" game. The equivalent of Manic Miner or similar 8-bit arcade platformer But there are a few other things I think/dream of, while "sticking Bilou" as decided. Figures near each game title are the votes you have casted during the January Poll

Bilou sera un jeu de plate-formes. 8 zones différentes à explorer, des batailles épiques contre des boss à pics. Mais je sais aussi que je dois me mettre des étapes intermédiaires pour éviter que le projet ne tourne à rien, et j'ai la sensation que c'est à travers des mini-jeux permettant de tester les différents aspects sans exiger la cohérence de l'ensemble que j'y arriverai. "gedsdemo-999" en était un exemple. Ca me permettra aussi de m'assurer que les "gedstool" pour le game-making sur DS ne se limitent pas à un éditeur de niveau spécifique à un seul jeu. Voilà donc les quelques idées qui me trottent en tête pour la prochaine release sans que je ne puisse me décider. Mais vous avez voté, comme en témoignent les nombres à côté de chaque "titre de jeu".

Bilooyan (1/8) -- [forget it]

A pooyan clone, that would take place in Bilou's woods, starring Bilou and the applemen, and cameohs of Funky Funghi as the Smart Bomb, Bouli and possibly BerryBats. pros: most of the art is available, I love the soundtrack, especially as interpreted by wolk. cons: soundtrack avl. only in MP3 format, applying the gameplay to the current game engine is challenging, not straightforward.

Biloubulus (2/8) -- [forget it]

A nebulus clone that would take place in Bilou's woods, with all the existing monsters. pros: art available, except for the (central) tree, I love Nebulus but where to find the "maps"? cons: the pseudo-3D layout and important amount of "special platforms".

Un p'tit clone de Nebulus autour d'un arbre géant avec les appleman et autre berrybat en guise d'ennemis ... Ca serait sympa, non ? J'ai toujours adoré Nébulus. Le hic, c'est le côté pseudo-3D et la quantité de "plate-formes spéciales" à gérer ... Je ne sais pas trop comment transposer ça sur le moteur de jeu en cours.

Apple Assault (3/8) -- [released in 2010]

Inspired from this flashpunk video and partly from this tree monster, Bilou would have to survive waves of applemen (and possibly other ennemies) in an arena of angry trees that continuously throw applemen at him. pros: stresses the current engine, sets the ground for testing "shooting monsters". cons: no suitable music right now, no art for the "angry trees" so far, and they weren't mentioned anywhere in the synopsys of the game.

A chaque seconde, de nouveaux applemen sont crachés dans l'arène par des arbres mécontents. Bilou doit survivre le plus longtemps possible. pour: test de performances du moteur de jeu, tester la création dynamique d'ennemis. contre: pas de musique pour cette ambiance-là sous la main (Mais si! String Tracking par Cyborg Jeff!), pas de sprites des "arbres mécontents".

Deep Ink Pit (4/8) -- [work in progress, 2011]

Somewhere in the School Zone, Bilou must prove his valour to a veteran inker and its magic feather. He's thrown in the deepness of the Ink Pit where he must escape ever-rising (deathly) ink in a vertical-only scrolling. Gameplay is closer to GravityHook than it is from Rayman's jungle rain in that all Bilou can use are SpongeBops to bounce over or grab pros: would test how playable multi-bounce over spongebobs is. Sets environment for testing "grab" mechanisms. "BN chocolate" could be used as tune ... maybe. Magic feather is a nice opportunity to experiment with 3D objects. Got nice lineart for surrounding (menus) art mids: some (background) art available as lineart cons: fun only if I have an online leaderboard. Major art effort required (but welcomed later). Many "not yet available" items at once.

Bilou se trouve quelque part dans la School Zone et doit prouver à un Encrier Vétéran et sa Plume Magique qu'il est bien le héro légendaire. Du coup, il se retrouve plongé dans un puits d'encre où le niveau monte en permanence et où sa seule chance de survie est de rebondir le plus haut possible, d'éponge en éponge. pour: tester des comportements plus complexes tels que le "grabbing". tester l'intégration d'objets 3D (la plume). tester la jouabilité du "multi-bounce" pour des puzzle ou des éléments d'adresse dans les niveaux du "vrai" Bilou. contre: il faut un high-score en ligne pour que ce soit chouette. Presqu'aucun graphisme disponible là-tout-de-suite. Peut-être un peu trop tôt pour le moteur de jeu.

Rescue Mission (1/8) -- [forget it]

Inspired by vvvvvv, since Bilou and Bouli are space explorers, and given that game deserves better graphics. pros: provides some backstory. I'd love to tell a story about a space station in distress where things have turned wild since ... Blork Carnage. Simple (seemly) mechanics. Nice puzzles cons: would be fun only if I've got similar maps and if you can discover the plot. Graphics & Sound ?
Bin, finalement, Bilou et Bouli sont des explorateurs de l'espace. Donc un jeu comme
vvvvvv, ça pourrait marcher. pour: ça permettrait de construire un peu les personnages (qui étaient-ils avant de se planter sur la planète étrange ? etc.) Et puis j'ai toujours révé de raconter une hist:oire sur une station spatiale à la dérive. Les mécanismes sont plutôt simple. contre: il faudra des maps, et encore des maps. et une histoire. Et je n'ai rien au niveau graphisme & son.

Bilou "Mining" (6/8) -- [mid-term development]

Some sort of a "manic miner : lost levels" clone, with a more complete collision and physics engine. And "32-bit" pixel art. I'd love to achieve it since i've seen Arachne's mockup (just on your left. Yep, that one). This is straight continuation of the current "gedsdemo" I already provided, where you'd add conveyer platforms, ladders and the like. pros: in progress. cons: Needs work on the level editor to be continued. Needs some "real stuff to collect" (not just apples: I cannot come with a coherent backstory for "collect apples so that you can pass through the trunk"). And golden keys and doors would be completely misplaced in Bilou's woods.
C'est la continuité du "gedsdemo" déjà disponible. Récolter des items pour que la porte s'ouvre et pouvoir passer au niveau suivant. C'est le principe de Qwak, de Manic Miner et de Johnny Biscuit. pour: déjà en cours, contre: pour rester intéressant, il faut régulièrement introduire de nouveaux objets/mécanismes au fil des niveaux. Le jeu demande un éditeur de niveau plus costaud. Je n'ai pas de "clés & portes" adaptées à la forêt de Bilou.