pixel art waterfall

I will need something that shows where all that ink comes from, and build a story about getting the School Zone a dry place again. It is not so easy to come with pixel art liquid flow, but I know from a while that iSohei did a great job drawing some. In my case, the narrow and straight flow is possibly the best choice.

The flow is rendered here by a highlight area in curvy and noisy v-shape that twists left to right as it moves down. The picture here shows the individual frames of the animation when vertical movement is canceled.

I could have that with a sprite shot from the top of the waterfall over some otherwise static ink area. I could shoot _two_ of them simultaneously, but that moves down at slightly different speed so that you get the illusion of a wave that widens as it falls down, too.
well ... now it's analyzed. Let's make it so.

Bon, j'ai fait une première tentative désastreuse pour animer une chute d'encre (indispensable pour le dernier niveau de School Rush). Puis une deuxième encore pire... alors je retourne chercher une référence de "Pixel art waterfall" pour voir ce que je peux faire. Le mieux, ce serait sans doute d'appliquer la même technique que iSohei pour sa troisième cascade: un sprite en forme de v qui se tortille en descendant. L'avantage c'est que je pourrai alors utiliser un vrai sprite et avoir une animation d'autant plus fluide.

Edit: coding attempt: having the falling wavelet 'rewind' to the top of the fall/pipe when reaching the ink is nice, but is not sufficient because 'the ink' is actually there only when the 'inkfall' is on-screen. Remember ? ink waves GOBs follow the camera.

Confirmation pour Double-B(ig-punch)

Petite soirée chez les parents de JB, console en poche. J'y retrouve N, A et L de la S-team, mon équipe de beta-testeurs attitrés. La nouvelle technique de "planer en gardant le bouton enfoncé" est adoptée par tous. Les nouvelles trajectoires pour le lancer n'ont perturbé personne et ont permis aux nouveaux-venus de récupérer pas mal de power-ups alors que jusque là, les P-UPs laissaient plutôt les joueurs indifférents.

Presque tous les plus jeunes, à l'instar de Zim, essaient de continuer à ramasser des taille-crayons même après avoir gagné "Big Punch". Ils se placent juste sur le blador et appuient sur B encore et encore, ajustant leur position. Mais sans se rendre compte que Bilou ne ramasse plus rien dans ce cas-là. Inévitablement, les pieds du blador se rapprochent, il se réveille et blesse Bilou, souvent plusieurs fois d'affilée le temps que le joueur comprenne ce qui lui arrive.

Je peux soit faire en sorte que un coup de poing nécessite un double-B ou veiller à ce que donner un coup de poing dans un blador assomé le ramasse ... mais il faut que je fasse quelque-chose.

S'accrocher aux éponges est passé pas trop mal chez le nouveau joueur après que je lui ait dit que

• oui, on peut grimper dessus
• tu tiendrais mieux dessus si tu t'accroches
• j'ai dis "tenir dessus". Là, tu essaies de l'attraper par en bas. 

Il y a un petit coin du niveau 1 ou j'ai placé quelques lettres qui mênent du balancer d'une éponge à une plate-forme en hauteur, c'est un bon moyen pour aider un joueur inexpérimenté à réussir cette action pourtant fort délicate.

This week-end featured some social beta-testing session with kids between 7 and 15, including the S-team. Compared to earlier release of the game, the power-ups were much more used and seeked by the players. The "straight-throw" mechanism was set as default throw and it pleased the players. Only the eldest player asked me how the former "ballistic-throw" could be achieved and used it in a few place when short distance was preferred.

I take note that young players will tend to stick on "pick up bladors" even though they gathered a BigPunch power-up. With the current mechanics, however, they will stun the blador again and again with no effect, wondering why they can't pick up that blador now, getting closer, and completely missing the facts that blador's feet are getting dangerously near. When the blador finally wakes up, odds are high that Bilou will be recovering a BigPunch blow and that he'll get hit by the blador's move, no matter how fast they spam the B button. I think this stems for BigPunch invoked by a Double-B mechanic while single-B remains "pick up" through the whole game.

The alternative would be to ensure that punching a stunned blador means you pick it up. It sounds both more perplexing (you lose the mechanic's individuality, which is an important factor of cleanness)

Deuxième essai pour StraightThrow.

Je n'ai pas grand-chose de solide à opposer au commentaire de Zim comme quoi le lancer de School Rush manque de punch. En fait, en voulant faire les petits dessins-tutoriels pour l'action "lancer un taille-crayon", je me rends compte que la seule façon de le montrer, c'est avec un taille-crayon qui part en ligne droite vers sa cible. Un "Straight Throw", en somme.

Je fais donc un essai de gameplay: B fait un Straight-Throw, UP+B fait un Classic-Throw. Ainsi, je fais du cas de figure le plus important l'action par défaut tout en donnant de la marge pour planter un blador sur un crayon ou placer une SpongeBop pas trop loin dans l'encre.

• [done] rebondir sur un ennemi pourrait faire sauter plus haut
• [done] lancer manque de punch (ça ne va pas très loin), si l'on pouvait contrôler la distance et la direction rendrait le maniement plus jouissif (l'impression de faire ce qu'on veut)
• [done] lancer en pleine course pourrait augmenter la portée du "projectile" (il me semble que c'était pas possible)

Lancer plus fort en pleine course ne donnait rien avec le Classic-Throw, parce qu'il devenait impossible de juger de la trajectoire. Avec Straight-Throw, ça ne devrait plus être autant un soucis, et ça encourage le joueur à prendre de la vitesse, ce qui est le point central de School Rush.

Remember I said "straight throw" as a power-up didn't convince me ? Yet when it is time for me to illustrate "you can stun pendats with a blador", what naturally comes out is a straight throw. So it seems Zim wisely pointed out the lack of power in the current (classical) THROW. I changed the way impulse from Bilou is conveyed to thrown items so I can have "straight-throw" by default and "classical throw" on-demand with UP+B. That feels much more natural in this game, altough less original and possibly less suited to the Big Adventure that is yet to come.


Edit: I'm not sure players will feel that the blador is thrown further as they move faster, but at least they will not get the feeling that they're reaching it back.  Another mechanic to change in a similar way would be to require double-B to use Big Punch.

Note to future self: remember how you spent displeasant hour trying to figure out the reason for a Guru Meditation after you compiled this TryThrow.nds from the mercurial sources in Trusty Tahr. Remember how you promised yourself to spend at least equivalent amount of time on a "build.sh" script that would make the start-of-work from a fresh hg clone reliable.

• [done] update spons.cmd.c so that it also obeys two-dimensional impulse as the bladors do.
• [done] merge in "hang-on-spons" when Bilou miss an AIRHOP auto-move.

1st Mercurial Commit

Oh, the first one for this hobby project, I mean. I'm using mercurial happily for about 18 months at work. It is smoother to use than git, to my taste.

And it brings a first step for the "quick navigation" widget, that is the rendering of the map. It just need to be turned into a widget and migrated to the right window.

Bon, bri-coder un outil supplémentaire pour mon éditeur de niveau assis dans les escaliers parce que c'est le seul bon endroit de la maison pour le faire, ça faisait longtemps ... Mais les enfants voulaient jouer dans leur chambre, et rentrer trop dans la chambre, c'était devoir refuser "la vie la vie" sur youtube toutes les 2 minutes.

Par contre, cette fois encore, il manque criamment un mécanisme permettant à plusieurs contextes (les 'windows') de collaborer à travers une structure de données ou un widget commun. 

Oui, j'abandonne SVN au profit de Mercurial, avec lequel je me sens désormais bien plus à l'aise. Et puisqu'il me faut lâcher ma LTS de 2010 pour me risquer en Trusty Tahr, j'en profiterais pour basculer en bash et définir EDITOR=vim dans mon profil, au risque de choquer ceux qui ont fait de l'admin système avec Sheriff... 

PS: on ne laisse pas vim pourrir ses fichiers en jouant au sauvage avec les tabulations

PPS on n'oublie pas :set paste pour éviter les mauvaises surprises en collant du code venant d'ailleurs

Magic Feet ?

Je cherche un moyen pour que le joueur de School Rush voie immédiatement s'il a un power-up ou non. Il y a bien sûr l'idée géniale de mon frangin d'utiliser l'écran du bas pour montrer les possibilités que Bilou gagne au fil du jeu. Quelque-chose, si on utilise l'habillage d'un "livre d'histoire", qui se marie assez bien avec les bonus-tutoriels que je cherche aussi à ajouter.

The next Big Thing I truly need to bring into School Rush is a way to view which powers Bilou can currently use. That's something Zim pointed out. That's something latent (you remember how the S-Team wasn't using power ups at all) since I introduced the power ups. I keep thinking that my brother's idea of using the bottom screen is a great way to avoid tutorial texts/screens. But I'll need something more.

Mais ça me semble incomplet. Il manque quelque-chose de visuel. Mais pas des petites ailes dans le dos, ni un chapeau à la Kirby. Pas non plus une sorte de bouclier élémental à la Sonic 3 ... Pas de changement de couleur à la Megaman. Rien de tout celà ne serait compatible avec le personnage que j'ai en tête. L'ennui, évidemment, c'est qu'en fait rien de ce genre n'a été envisagé dans le design d'origine, sauf peut-être les lunettes noires qui accompagnent l'astro-flasheur. Ce n'est pas vraiment une surprise: les pouvoirs de Bilou n'étaient pas prévus alors pour être temporaires (plus similaires aux missiles de Samus que de la fleur de feu de Super Mario, donc).

I know I don't want color swaps like in Megaman, nor little wings (Kirby-like) or a sort of colored shield (Sonic-like). That doens't fit my own perception of Bilou's character. I could accept, however, blinking magic feet or blinking magic hands, with trailing sparkles. It doesn't look too bad on this mock-up. I'll dig further how to properly implement that knowing that the multi-palette technology makes it a bit harder (requires memory un/re-mapping synchronized with screen updates).

Je fais donc un petit essai. Des pieds légèrement brillants et qui laisseront derrière Bilou de petites étincelles vertes pour le pouvoir 'FLOAT' alors que 'BigPunch' fera pareil avec les mains et de petites étincelles bleues. Il faudra sans doute quelque-chose d'un peu plus calme mais je crois que ça pourrait marcher.

• [cancelled] given the GameEngine structure, I'll have to register a post-vbl callback
• rather opted for custom idle animations

L'avis de Zim: définir l'animation

Deuxième point du feedback de Zim:

Mon conseil serait de mieux faire comprendre par l'animation du perso sa panoplie de mouvement, développer les actions d'attraper et sauter, supprimer celle de frapper (peut-être courir), et de faire en sorte que tout cela soit impeccable (actions qui sortent de manière fiable, pas de bugs de collision, etc.). Un jeu de plateforme est excellent lorsque c'est un plaisir intuitif et immédiat de manier son personnage, il faut vraiment insister dans ce sens.
- attraper en l'air est possible vers le bas (je l'avais compris avec les nuages), mais pas vers l'avant, même si on n'a pas encore ramassé le power-up
- attraper pourrait être boosté en l'action rendant multi-directionnelle (si vers le bas et les côtés, pourquoi pas vers le haut) et également peut-être en augmentant sa portée au moins un peu

Avec ces mains-en-plasticine, c'est vrai que Bilou ne montre pas particulièrement fort ce qui se passe lorsqu'on essaie d'attraper quelque-chose. En relisant les propositions de Zim, je me rends compte aussi qu'il peut y avoir confusion entre ramasser et s'aggripper, qui sont en réalité deux actions distinctes mais proches au niveau du gameplay. Un "air grab" permet de faire l'un ou l'autre selon l'objet considéré. Un "ground grab" ne fait

	Ramasser, premier essai. Trop lent.
	Ramasser, version actuelle. colle bien au hit-boxes de l'action.
	Attraper en l'air, qui se concentre sur la direction "vers le bas"

Pour le "gros poing", la main de Bilou enfle et ne laisse aucun doute sur l'interprétation du mouvement, mais ici, la main utilisée pour "attraper / ramasser" pourrait aussi bien mettre un uppercut. Ma première réaction est "oui, mais le gros poing est un pouvoir spécial. Il faut que Bilou sans ses pouvoir ait l'air de ne pouvoir compter que sur son astuce et son courage".

What if Zim@alexzone and I do not have the same understanding of a "multi-directional" action. I thought so far that 'AIRGRAB' is multi-directional in School Rush, because when you press B mid-air, there are 3 directions checked for something to grab: in front of you, below you, and behind you. Those three areas are supported by the places where Bilou's hand move during the attempt to grab things. But multi-directional could also mean "you pick which direction the action takes place using your d-pad".

This is clearly not the case for air-grab. It would make sense for a wider-range grab, which Zim is advocating for: the animation could take place in a limited area (good for reading), and still reaching further pixels. You could need to do "UP/RIGHT + B" to reach some sponge bop and "DOWN + B" for some others, though.. and time your button press accurately to grab something. In comparison, current GRAB is a proximity action: move your player next to the item to grab and hit when you're close. That's all I require.

Enforcing the direction with the keypad also allows to draw a larger hand, that better conveys the idea that we're grabbing things. Ideally, we could understand what the move does by watching it in the void. Like you check kick and punch buttons on a beat-em-all before you follow the "GO->" arrow for some action. 

A mieux y réfléchir rien n'interdit que Bilou ait déjà le pouvoir de soulever des choses plus lourdes dans ce jeu-ci, qu'il le conserve de façon permanente et que ça se traduise par une main qui devient plus grande quand il veut attraper les choses. Des doigts visibles, légèrement écartés, pour maximiser les chances d'avoir ce qu'on veut... c'est sans doute ça qui exprime le mieux l'action, comme on l'aurait fait dans une BD.

Voyons le côté "multi-directionnel", maintenant. J'ai tendance à penser que le "grab" est multi-directionnel parce que quand je presse sur B, Bilou attrape ce qui est devant lui, sous lui ou au même endroit que lui. Mais ça fait une animation où il est difficile de voir la main. Multi-directionnel pourrait aussi vouloir dire "dans n'importe laquelle des directions choisie" (avec le D-PAD).

Ça représente malgré tout une modification assez importante. Je pense que je vais dans un premier temps essayer que Bilou puisse s'accrocher par-dessous une éponge (y compris lorsqu'il la touche par le côté) avant de commencer à faire ce genre de changement.

I need the Rainbow Road

I started working on a last level for School Rush, where you'd have to climb up for safety. It was tedious, because navigating in the level in LEDS can only be done with L+DPAD at the moment, in 64-pixel increments. Yet this time, I had to move through 1024x8 pixels of emptyness before I reach the "bottom" of the level everytime I want to migrate something from the title screen.

And then, i tried to copy the current game on my brother's DS using my not-so-smartphone, so I lost that map. Sigh. I'm not re-doing it that way. I will first bring on a new tool in the Level Editor. Something like a "Quick Navigate" option. I thought a "Rainbow Road" would work okay. level structure is depicted by two rasters (one horizontal, the other one vertical), and auto-zooming so that you a square area covered with stripes, and touching one pixel of that square brings you immediately to the corresponding area of the level.

Bon, perdre un niveau qu'on édite, ce n'est pas drôle. Devoir recommencer en faisant des centaines de fois L+bas pour retourner au fond du niveau, ça l'est encore moins. J'ai pris un peu de temps cette semaine pour réfléchir à un moyen de se déplacer rapidement d'un point à l'autre de la map pendant l'édition, en tenant compte des ressources vidéo déjà largement sollicitées sur l'écran d'édition. Je propose la RainbowRoad: un carré sur lequel sera représenté le niveau en utilisant un dégradé bleu-rouge pour l'axe horizontal et un dégradé foncé-clair pour l'axe vertical.

As far as software engineering is concerned, I face once again the need for a given event (update of level coordinates) to be produced by any of M sources and consumed by N receivers. M and N are small, and constant once the program is built. A bus pattern could work, or possibly something like an object that sends notifications when updated.

Color selection in SEDS could also benefit from this pattern.
Post-Scriptum thoughts:

• [dont] Having QuickGo out of MapEditWindow allows to keep level edition full-screen. I have very limited options to introduce yet another window over MapEdit.
• The drawback is that currently MapEditWindow doesn't show when you toggle to TilesetWindow.
• [done] The transient "layer selection" overlay (available when map edition in "copy" mode) could host it as well.
• Maybe replacing one of the rasters with a overview of how "dense" the area represented by one pixel is (with transparent-to-white) would give a good feeling of where we will go ...