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.

Tu (d)'chus, il chût

Le scrolling bouge un peu tard quand le personnage tombe, ce qui pourrait être délicat pour les scènes de plateforme avec du scrolling vertical.

Bigre! Il a raison, le bougre! Evidemment, je commence à connaître mes niveaux par coeur, donc je me promène dedans sans me rendre compte que la visibilité est insuffisante, ou que Bilou est presqu'en train de tomber hors de l'écran.

Il faut avouer que je tâtonne pas mal avec le scrolling. Ce serait assez simple de garder Bilou en permanence exactement au milieu de l'écran, mais je ne le souhaite pas. En particulier pas pendant un saut. Mais ça, je vous en avais déjà parlé, vidéos à l'appui. J'avais donc fait en sorte que seule la vitesse horizontale soit immédiatement prise en compte: les contrôleurs indiquent à la caméra la vitesse exacte de Bilou et la caméra s'y adapte. En plus de ça, j'ai toujours un "garde-fou" qui force la caméra à se recentrer sur Bilou si celui-ci est trop loin de l' écran (en gros, comme un BerryBat se rapproche de Bilou).

Morukutsu pointed out that it was pretty hard in my last release to fall down safely. The camera management tends to let Bilou get really close to the bottom of the screen when falling ... it may even let it "out" of the screen from times to times. I was shocked to realise how true he was. I guess I'm so used to my own game that I barely needs to read anything from screen and I can safely reach any area of the game "blindly". So I tried to sort it out.

It wouldn't be much of an issue to simply keep Bilou in the middle of the screen at all time, but that's definitely not what I want. It leads to very disturbing camera moves when you hop from platform to platform. Plus, it means that you loose track of what you're jumping over during the jump -- as I already said previously.

Mais du coup, dans certains cas, Bilou peut atteindre une telle vitesse que lorsque la caméra "réagit" pour tenter de le suivre, il est déjà trop tard et il se retrouve fort au bord de l'écran. Je corrige le tir avec une règle qui force la caméra à suivre la chute de Bilou dès qu'il va descendre plus bas que la hauteur d'où il a sauté.

Il me manque une rime en "eutre" ...

... euh pardon. Interférence. Il me manque encore une règle dans les contrôleurs "walking" et "idle" qui indiquerait à la caméra "recentre-toi sur Bilou verticalement, tant qu'à faire". Parce que pour l'instant, quand Bilou s'arrête dans les branches à la fin d'un saut, il peut parfaitement rester "fort au bord" (haut ou bas) de l'écran malgré tout. En attendant, j'ai modifié le "StopperController" pour qu'il permette au joueur de regarder en haut ou en bas avec le DPAD. C'est toujours ça.

I just missed that, if I don't update camera's position during a jump, it may be too late to track Bilou back to the center of the screen when he falls down. I thus adjusted so that we follow Bilou's speed again -- even when falling -- as soon as the "landing speed" is reached. By landing speed, I mean "the opposite of jump-off speed", and it is reached when you come back at the vertical position you're jumping from. It's not yet fully Commander Keen's Magic Scrolling, but it's getting close. And I added look up/look down in the "idle" state so that the player can force Bilou to get back in the center of the screen.

I said *jump* !

Mettez un commentaire sur un de vos posts dev-fr, en précisant que c'est pas vraiment une release, juste que vous avez la flemme de refaire un gif animé, et bardaf, le monde entier s'en empare. Ceci dit, ça valait la peine puisque Morukutsu (qui planche sur la suite d'Inside the Machine) a pu ainsi me pointer du doigt deux ou trois choses que j'ai encore à arranger.

J'ai vraiment du mal à sauter par dessus (ou passer par dessous) des champignons violets. J'ai du me résoudre utiliser le tremplin pour passer par dessus eux après avoir être mort 5 ou 6 fois.

Y'a un tremplin dans mon jeu ?? où ça ??

En discutant un peu, je me rends compte que c'est toujours le même problème qui fait qu'un champignon rouge censé servir uniquement de plate-forme est interprété comme un tremplin par le joueur: tant que le joueur garde le bouton X enfoncé, Bilou enchaîne saut sur saut...

As long as you hold the 'jump' button pressed in the current demos, Bilou keeps jumping and jumping everytimes he lands. This led some beta-testers to mis-interprete platforms into bumpers recently. I'd prefer to keep this "jump frenzy" as a later power-up and require the player to press the button again at every jump.

C'est assez simple à arranger dans l'absolu, mais je veux en profiter pour revisiter la gestion du DPAD et permettre de tenir compte du timing des entrées. L'idée ultime étant que lorsque Bilou "rebondira" sur la tête d'un monstre, il y ait moyen de doser la hauteur de ce rebond en appuyant sur le bouton le plus proche possible de la collision. Je prépare donc un peu le terrain pour "deep ink pit".

At the root, it is not so complicated, but I want to make it ready for further development. Especially, sooner or later, I would like to use "bouncing on monsters" as a technique to access hidden or alternate areas of a level, in an attempt to have layered level design. To allow this, I plan to have timers associated with each button so that we can estimate how long the button is pressed, and e.g. adjust the bouncing impulse to the elapsed time since button press. If the delay is long enough, it's like you hadn't pressed anything.

Par contre, toutes ces commandes supplémentaires pour effacer certains boutons lors d'une transition vers l'état "Stopper" ne me convainquent pas. Il me faudrait peut-être une variante de "think()" qui permette de "préparer le contrôleur" quand on arrive dans un nouvel état.

Commuting Artists' feedback.

Here comes a small comment from a fry on Pixelation who was looking for "something else that UA paint for pixel art". Here's (anonymized) a snapshot of our conversation that contains relevant information for programmers. 'Embossing' is mine.

I saw from your sig that you pixel on your DS - which is something I often do too. I have a two hour daily commute, so it's great to shave some time off my freelance work. I use a program called UAPaint, which is fine, but picking colours is very long winded and I often get crashes losing work. I'd be very interested to hear what software you use, and your experiences with it. So far the graphics software I've seen has been programmed by programmers (obviously) who don't really need to use the software, and are almost quite 'proof of concept'. A few simple tweaks to UAPaint would make it so much more ideal for the professional pixel pusher so I'm cautiously hoping you have a better solution!

(...)

When working in photoshop I very frequently alt+click to pick colours directly from the artwork, which is a very quick and natural feeling of painting. In UAPaint doing this involves lots of steps: bring up menu, select dropper tool, close menu, pick colour, bring up menu, select brush tool again, close menu. 7 steps! It's my biggest bug-bear. I believe you can't really refine anything properly without having the freedom to push pixels around on a whim.

In SEDS, I tried to address specifically that problem of color management. I've never been convinced by typical paint-program approach where you use left button for FG color and right button for BG color. Gimp and Photoshop's "CTRL+pencil = color peek" is much more interesting, except that you only have it when ... using the pencil, obviously. You don't have anything like "right-click" with a stylus, so I recylced scummVM for DS approach: holding L while touching the screen is a right-click. And L-touch the edition grid is always "peek colour" while "just touching" the grid is "poke colour (paint)".

Now admitedly, SEDS' user interface is far from being optimal. It ignores the golden rule that "users don't remember anything" and that "users don't read" (mostly because I'm egoïstly developing it to fill my own needs, though there is some 'embedded tutorials' in the last release). Xelados already suggested alternate approach, which sounds valid but which I'm unsure how to integrate with the current work. Also, I recommend anyone working on a app targeted at pixel art to have a look at this Video where pixel master Helm does colour reduction, anatomy editing and much more on a 35x75 woman sprite. Even his powerful tool doesn't seem appropriate to the "palette touching" he's doing to locate pixels of a given colour in the colour reduction process.

If SEDS don't fit your needs either, you might be glad to learn that BassAceGold (the author of UAPaint) just revealed the name of his latest painting program project for the DS : Etch... Wait 'n' See.

Oui, désolé pour mes amis francophones : ces derniers posts sont surtout des extensions de commentaires faits sur les blogs d'autres personnes, et le boulot me laisse particulièrement peu de temps ces jours-ci.

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.

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.


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.

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

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

Berrybats!

Bion, ça ne va pas être un post extraordinaire parce que j'ai la crève. Et ce n'est pas une évolution extraordinaire non plus, en fait. C'est juste qu'à additionner 2 et 2, on finit par avoir 4. Et en l'occurence, ici, 4, c'est une baie sauvage volante non-identifiée qui colle Bilou au train dans les bois. Voyez plutôt. Ou jetez un coup d'oeil aux sources de la démo, c'est selon. Bien qu'ayant changé de nom à plusieurs reprises, les BerryBats restent l'ennemi le plus ancien de Bilou (bon, okay, il ne fallait pas trop se forcer pour y penser au départ). J'avais prévu un long post de rétrospective mais je vais plutôt finir de boire mon ciment et retourner me coucher. Je vous invite à retourner voir l'ensemble des posts marqués "berrybat" pour vous faire une idée de ce que j'aurais causé. I'm sick. So don't expect some very fancy stuff around. I just put the last bits together that were needed to have a berry bat flying around and tracking Bilou in the woods. It's mostly harmless at the moment. It's not even "turning back" nor does it sits sleeping until Bilou gets close. But it is the eldest of Bilou's ennemies and I had kept its pixels secret for too long. Enjoy. I'm gonna have my medecine and get some sleep. Enjoy the previous posts tagged "berrybats", that should tell it all. Oh, au passage, faites donc un tour sur Pixelation, j'y avais fortement fait évoluer le "look" des chauves-souris entre leur version "pomme" et leur version "baie".

{ using decrease(v0 by 4 to 100) ...

Quand j'ai commencé à réimplémenter le comportement de l'appleman pour la version DS de Bilou, j'avais dans l'idée de lui permettre un "boost de vitesse" pour prendre Bilou en chasse tout en gardant son côté lourdaud, ç.à.d. en limitant le temps pendant lequel la chasse en question pouvait durer. Jusqu'ici, seul le premier aspect était programmé, et je viens assez facilement d'ajouter le deuxième. Au niveau du gamescript, ça se limite à la ligne qui figure dans le titre (dans la description d'un état) et une transition supplémentaire "courir->marcher on event".

The appleman 'revived' on the NintendoDS through a small animation that showed him "walking, shocked, running, slowing down, walking again". So far, it was mostly running ahead until it encountered a wall or a cliff -- not very compatible with its clumpsy nature. A small additional line in the gamescript and a supporting "controller" class in the C++ code base did the trick in half the time I need to relate it, so let us check the code which speak for itself:

Au niveau du game engine, celà passe par la définition d'un contrôleur supplémentaire qui diminue une des variables (ici v0, la vitesse horizontale) jusqu'à atteindre un seuil donné (100, la vitesse de marche de l'appleman au repos). A ce moment un "évènement" est généré et le moteur de jeu parcours les transitions associées avec l'état actuel.

iThought DecreaseController::think(s16 gob[8], GameObject *g) {
  iThought me = NONE;
  if (gob[varno]<0) {
    gob[varno]+=step;
    if (gob[varno]>-threshold) {
gob[varno]=-threshold; me=EVENT;
    }
  } else {
    gob[varno]-=step;
    if (gob[varno]<threshold) {
gob[varno]=threshold; me=EVENT;
    }
  }

  return combine(me, gob, g);
}

auquel se rajoute un petit code de parsing :

iGobController* GobDecreaseFactory::create(char* args) {
  int v=0, s=1, t=1;
  siscanf(args,"v%u by %i to %i",&v, &s, &t);
  return new DecreaseController(v,s,t);
}

Rien de bien extraordinaire: un code relativement simple pour une fonction relativement simple. D'où le choix de cet exemple pour vous montrer un peu plus comment je m'y prends. C'est ce que j'aime dans l'approche "micro-contrôleurs enchaînés" où je n'ai plus besoin de surcharger la signification du code C++ pour traiter tel ou tel cas un peu particulier comme je le faisais au début du projet. J'aime assez bien le côté "auto-explicite" et très "BASIC" de la liste d'arguments "v0 by 4 to 100" plutôt que (0,4,100) comme je l'utilisais jusqu'ici. Attendez-vous à voir ça se généraliser dans les gamescripts

That's all the beauty of chained micro-controllers approach I implemented this summer: no need to clutter a generic "walking" behaviour with something like "oh, btw, some guys would need to slow down" or with "btw, v4 is a speed decrementor and v5 a speed target for the walking behaviour". Opting for a BASIC-like encoding of arguments (instead of the typical 0,4,100) is the final stylish touch ... Now I'm one step closer from having berrybats chasing you if you approach the vines carelessly. I just wish I'd be able to provide these "supplemental C++ classes" through plug-ins I could upload by WiFi to the game engine. Maybe I'm wishing too much ^^".

Voilà, voilà. Pas vraiment lié aux problèmes d'escalade mentionnés ce week-end, si ce n'est que decrease(...) pourrait aussi être utile pour les berrybats qui poussent sur ces lianes envahissantes.

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"