Puddlehead splash

There's one thing I still miss in my water implementation, and that is splashes. The most beautiful waterfall will fall flat if the water pool doesn't acknowledge you've changed physics by a nice splash of pixels.

I've gathered a few references in my pixelstudies, and this one comes from

puddlehead-creations.itch.io

The video was initially intended to demonstrate how surfaces in GameMaker can be used for palette-lighting  in CinderHoodGame, but what caught my attention was those simple an efficient splashes, which I wanted to pixelstudy.

Un beau splash! Voilà ce qu'il manque à mon petit coin aquatique... Et des beaux splash, vous pensez bien que j'en ai croisé 2 ou 3 depuis que j'ai dessiné la cascade. Celui que vous voyez ici apparaît avec l'autorisation de Puddlehead Creationset a été patiemment extrait à l'aide de VLC d'une vidéo présentant un nouveau shader pour leur jeu CinderHoodGame

As often, such material is posted as a video, so I had to frame skip to get the different steps studyable. May I  call this family of splashes "noisy gaussians" ?

There are two separate animations, depending on whether you splash into the water pool or out of it. 

In both case, I'd first animate the big white part and only then add those noisy spikes and make them turn into "independent droplets" as the splash collapses.

Ne pas hésiter à faire deux animations, une pour "plouf dans l'eau" et une pour "sphlash hors de l'eau" ... partir d'une courbe en cloche d'écume blanche, ajouter des déviations pour le haut ... attendre le moment où l'eau retombe pour ajouter des goutelettes qui suivent leur chemin ... voilà ... à tester.

En comparaison, l'eau de Super Mario World fait un peu pitié ... une couleur unie, une surface statique, un splash qui recycle le nuage de poussière, selon moi ... Par contre, je note l'idée intéressante de faire apparaître au moment du splash des petites bulles qui remonteront à la surface ;)

In comparison, SMW's water is very cheap, with static line, solid blue, unconvincing splash recycling dust sprite ... but it had the good idea of spawning bubbles under you. Rayman's sprite is beautiful, but low framerate and oversized for Bilou's weight. Fury of the furries reused their particles engine but imho could use some fine-tuning... And Hydrocity used something too blast-ish.

edit: One more splashy video posted by Puddlehead creations, just in time to replace the one I used for the snapshots ^_^

"Why am I doing this?"

It's not unusual to ask yourself the question among indiedev. What struck me is that the question was raised this time by someone who's been interviewed by Pix'n'Love and makes games with his son: Dale Coop.

There are moments when I wonder, “Why am I doing all this?” It takes so much time, few people care, and it brings nothing in return. The majority of people don’t even know it exists. Should I just move on to something that makes more sense for my life and family? That’s where I am today 😔 -- Dale Coop

I know that feeling. I relate it to those time where you feel the urge to eat, but nothing you eat seems to quiet it. Because actually, I need to eat something different (sometimes more fruity, sometimes more crunchy, ...) Sometimes gamedev is satisfying, sometimes we need something else.

What tend to make me wonder "why am I ..." is the overall dsgametools approach. 20 years past the introduction of the NintendoDS, and despite my first game on the system is now about 15 years old, none of my relatives have really picked up the tools and start making their own PPP games with them. It is heartwarming to read veteran artist say "your tools are perfect and tailored to your needs", yet

• basic *EDS tools apparently feel repulsive to friends and nephew and will be lacking to professionals
• conversion tools are so tricky to use, you'd better consider them inexistant
• I've got nice IRL chat sessions with my son about the game design overall, but pencil drawing is none of his hobbies so I'm left with all the job anyway
• mixing script and C++ code in the engine doesn't feel that useful when I'm the only developer anyway. It makes many debugging sessions more complicated that they should because you can't really single-step the GobExpressions

I've got something running, but it is far from perfect and it gives me the feeling that I've made my own life overcomplicated. Nobody would use scripted state machines in a platformer. Or if you really want editable behaviour, you'd go for something like Fury of the Furries. 

Nobody ?

Well, I've encountered some github project to decompile the original Rayman title on PSX. I was looking for the code of that tricky-to-beat bandlands bug, and I got intrigued by some of the GO_SPEED, GO_LEFT, etc. you could find in the "top" function DO_MIT_COMMAND. No reference to that anywhere else in the codebase. I was also puzzled by the "skipToLabel();" calls. Digging through references, I end up with just one big "load" function filling all the commands together with other loads for the level... So they're not just some data part of the game engine.

I couldn't find anything like "Rayman Level Format" as I hoped, but I found Ray1Map ... the website that pretends to be a Rayman 1 level editor, and that's nearly as good as far as I'm concerned.

And there, we can view the commands for each individual enemy in the game. Some of them will be delivered to per-enemy handler (like LEFT % and RIGHT %), many will affect variables that those handlers can check and manipulate (especially enemy state), but there's also a whole set of flow control instructions for loops, branches, and even subroutine calls. And as you can see, the programs are already quite sophisticated. But that was used, and not only by that game (and its numerous ports), not only for other Rayman games (like the designer kit or the Junior series), but for dozens of unrelated platformers until the GBA era... or so does the Readme.md file suggests.

So well ... let's say that for 32-bit consoles, that approach makes sense, and recreating a game engine that deals with such abstract code at runtime isn't a bad idea. I just need to give myself better tools to address the debugging aspects... like presenting the whole thing as the debugger for a virtual machine that does not exists ?

appleman 2.0.1

A little bit of work on the Appleman last week-end (at last, you could add and I wouldn't blame you). I've got the "shocked" animation revised, added "carried" animations and gathered infos about where these are in green.spr.

I'll still need to see why there is no "bounce" when it is shocked (reason: it's just using stopper and the animation is supposed to do the job) and patch the greent.cmd level script on the SD card of DarkneSs, because it still show the appleman with big purple punches instead of feet. (appleman.cmd must be correct, since level 2 doesn't seem to have any similar issue).

Voilà donc enfin le moment que je prends pour compléter les animations et le comportement de l'Appleman pour le projet Dreamland. J'ai corrigé l'animation "étonné", j'ai ajouté les animations "transporté", tout ça attend dans un petit fichier green.spr le prochain passage du WiFi. Je note au passage que le fichier "greent.cmd" qui décrit le premier niveau des "3 salles" a besoin d'un petit rectificatif pour ne plus me montrer un appleman aux poings mauves ^^".

La prochaine étape sera d'ajouter les animations des "pieds perdus". J'ai aussi retiré la commande de boucle pour l'animation "assommé", mais j'arrive trop tard: c'était bon pour compléter le comportement "Apple Assault" où les applemen se réveillent seuls, mais c'est inutile pour le comportement construit à partir du fichier "blador.cmd". Car oui, le nouvel appleman est plus ou moins la fusion des deux.

So let's add tonight "undead feet" animations, check a "do not loop stunned animation" that must be over 1 year old in my notebook. I've got another notebook where I've written down blador's behaviour ... let's merge that into appleman's script and we'll cleanup the resulting code mess once the home mess is tidied up.

edit: adding the wandering feet turned out extremely annoying. They're one-sprite objects, unlike most of the things I animate with AnimEDS, and it seems the software still handle that in a very different manner: touching an sprite in the side panel adds a frame with that item, rather than changing the current frame. It also breaks relationship between timeline, frame editor and buttons in general. I'll have to get that fixed: it really breaks the user experience...

edit': pick up works, stun works, wandering feet work. Apple/water interaction is a catastrophy, throwing only work from times to times, and there's something odd when you stomp on a stunned apple (blador acted as a platform there, appleman won't). That feels like it should roll instead ... A good thing animation 2.0 freed some frames ;)
 

I want to try your editors so much!

How could I resist to such a quote ?

Adeline Venture (hehe) in Shadow Of The Temple The puzzle platformer I really, really want to make some day.

I want to try your editors so much! But in order to finish, I will have to do it in an engine I already know well. Probably construct3 -- CastPixel

It made me want to pack a set of my dsgametools with contents of Castpixel's mockup pre-digested into a .spr file so that she could directly toy with the level editor ... perhaps also convert the tutogit scripts so that she'd get something playable!

So first thing to know is that SEDS works with 16x16 blocks. There is a perl script that can convert the mock-up into tiles but if used directly, it will be a complete mess as game assets.

1. 
   ensure things are aligned on the 16x16 grid as much as possible. That means the ladder half-way over pillar must be shifted. A few other things needs similar shifting on the mockup.
2. SEDS shows you 64-pixels slices at once. The scripts *can* handle wider pictures, but at the moment, they'll scan e.g. first row of 256x16 pixels and output 4 64x16 rows in the first page, then another 4x64x16 chunk etc. The result is barely usable, again, because many objects bigger than 16x16 will be de-aligned and will need to be re-aligned in the DS editor.
   
3. So instead, you may want to turn the mockup into a 64x* image where things are where you want. Todo: imlib2spr.pl should be able to scan the image in 64px-wide columns itself, so that this step becomes useless and the mockup remains readable.
   
4. The script may remove the background color, but when it does so, it also deletes fully background blocks from the output file. This is nice to avoid redundant data, but again, it screws up alignment on such a mockup. You can scribble something on those blocks or you may turn off the background color by giving another one with --bgcolor=ff00ff. Todo: have the imlib2spr.pl tool inject empty slots on the sprite page when it encounters such full-background blocks, to preserve alignment
5. B u t if I use --bgcolor=some-color, the tool will inject a fully-transparent block as block 0. This is required for proper operation of the game engine and the level editor, but this is useless on the sprite pages. And worse, having block 0 editable led to corrupted files in the past. todo: patch the tool so that the empty block is never used by the generated pages (and never allocated by the editor :P)

With all that taken into account, with a 64x* png file with the content of the mockup aligned on a 16x16 grid as often as possible, conversion is performed with 

SpriteEditor/bin/imlib2spr.pl cast-a-venture2.png venture.spr --nomap --nopack --blocksize=16

And the reverse operation to see how things went is

SpriteEditor/bin/spr2png.pl venture.spr /tmp/venture.png && display /tmp/venture.png

Once that looks fine, copy the venture.spr file on your SD card in the /moving/ directory, make sure you have SpriteEditor for DS at the root of your SD card and launch it.

• once launched, press START to enter the FILE screen
• click the |/_/ browse button to show the contents of /moving/
  
• if venture.spr doesn't show up, hold L trigger and touch the "UV" button on the alphapad to filter the list of files. (holding L lets you enter the second letter of each "button").
• touch the "venture.spr" name to load the file, then press START again to return to the edition grid.

 

climbing ... manuscript notes.

Quelques notes qui datent de février 2013 et qui refont surface pendant les habituelles chasses de paperasse de début juillet: comment s'y prendre pour que Bilou puisse se balancer aux signets de la school zone.

J'y note la recommandation que les morceaux de signets soient passifs dans la collision et un peu de math pour déterminer si une zone de collision classique croise ou non une "ligne" de collision, qui conviendrait mieux pour les cordes qui pendouillent.

Par contre, je ne sais pas trop dire si j'avais prévu que le signet soit fait d'un seul Gob avec une zone de collision pour chaque élément ou de plusieurs gobs ... la pages avec les lapins vont plutôt dans le sens "un seul gob", chose que le moteur "Dreamland" ne saura pas encore gérer, je dirais.

On y trouve un

state% : 3D.% {
  using RopeController;
  segment [*] F_ROPE;
}

pour un nouveau type d'objet basé uniquement sur du rendu 3D. Le fait qu'on indique des collision pour chaque segment renforce l'hypothèse d'un seul GOB composite d'un nouveau genre. On lit d'ailleurs, sur la première page

foreach (@segments):
   if (b.ymin > s.ymax || b.ymax < s.ymin) continue;
   if (s.dx * s.dy >= 0) {
     // depending on the rope's direction, there's 2 corners of the bbox to check
   } else {
     // test the other two, I presume :P
   }
   

Et une observation que "bah, peut-être qu'une verticale plutôt qu'une ligne oblique, ça ne gènerait pas tant que ça dans la plupart des cas. 

Bref: c'est confus, même pour moi, mais je veux l'avoir sous la main dans le même tag que les autres

Hi English readers. These are manuscript notes from about 12 years ago, when I first tried to figure how to deal with swinging bookmarks that you could catch and climb to. They're a bit confused and I'm unsure even I understand what's being said there. But I've got bookmarks and climbing goal revived for Bilou's Dreamland, so I'd rather have these notes around when I'll think about it. The code snippets I typed above suggests that bookmarks were intended to be a new type of segmented 3D object, which has been dismissed for the Dreamland engine

gravity.flow ?

Je voulais faire tout autre chose, mais au moment de prendre le code en main, je me rends compte que j'ai une série de modifications qui n'ont pas encore eu droit à leur commit ... et que je ne sais plus trop à quoi elles correspondent.

Il s'agissait en réalité de deux modifications liées à l'eau: animer la surface (nager si bien avec un miroir en guise de surface, c'est un peu dommage ...) et faire en sorte qu'on puisse placer un jet d'eau dans une grotte. Parce que vous ne ça n'aura pas manqué de vous faire tiquer: il y a une sorte de rectangle moche au pied du geyser sur l'image ci-contre/dessus. C'est lié au fait que le geyser (tout comme la cascade) est obtenu en par une combinaison des deux couches de décor: l'une avec une animation de type "palette cycling" et l'autre avec une animation conventionnelle. Et donc pour mettre le geyser dans une grotte, il me faut deux nouveaux blocs "décor de geyser fusionné avec le décor de grotte".

After a fairly busy week and significantly busy Saturday, I wanted to try updating the Appleman behaviour, but I found my homebrew directory with different files uncommitted and changes involving binary files like maps. So I started by running the current code first on the emulator, and visit those maps to see whether there were any changes. And oh, of course. First change was animating the water line (see the mastodon video below). Second was an extra water jet in the second green map.

Quand je dis "je ne sais plus à quoi elles correspondent" (y compris une modification du code qui assure le palette cycling), comprenez "il a fallu que je fasse tourner le .nds pour m'en souvenir". Ce qui m'a donné envie d'en faire des petites captures (un jour après le ScreenshotSaturday ... pas de chance ^^"), et sur une de ces captures, on remarquait quand-même fort que le haut du geyser reste en permanence au même emplacement. Moi, j'aimerais qu'il monte et qu'il descende, pour ajouter un peu de dynamisme à la scène, et appeler à l'interaction.

See on that level editor, waterfalls and geysers are made of two layers of tiles combined. But that means you can't put a geyser over a dirt wall unless you've got tiles showing that in first place. Plus I'm using another palette slot for the dirt wall than the default one, meaning the cycling code had to be updated. That was ready for some screen-shotting. 

J'aurais peut-être pu utiliser le contrôleur "grid" de furblock, mais tôt ou tard, il faudra aussi que Bilou soit propulsé vers le haut par le geyser. Plan B: utiliser le même mécanisme de "flow" dans le contrôleur gravity que celui codé pour swim. Je profite donc que tout le setup wifi est là pour modifier le niveau et je définis un nouveau type de tile (les ^ mauves). ça donne des résultats rigolos avec Bilou, mais en réalité, ça ne marche pas: Bilou est bien ralenti quand il arrive dans le haut du geyser, il peut même remonter légèrement, mais au final, la gravité lui donne une vitesse suffisamment élevée (on peut aller jusqu'à 6px/frame) pour qu'il redescende, puisque le geyser le fait monter à une vitesse constante de 2px/frame. Bref, c'est bien pour des tapis roulants mais pas pour des geysers.

But then, the top of the geyser was very static ... I want it to wave up and down a bit. There are different ways I could do that in my engine, but only a few where not only the geyser top but also Bilou is lifted up when in contact with the stream. That implies a mechanism similar to the water flow designed last year, except this new special physics tile will define a property for the gravity controller instead. It will still be an "AIR" tile, though: we can fall through geyser, not swim them. (I hope to avoid nasty corner cases that way).

Unfortunately it didn't work the way I wanted. Lifting Bilou by 2 pixels (cyan lines on the diff) is fine as long as the vertical speed is lower than 2 pixels/frame downwards. It gives a nice boost when jumping and catches you when you're "stomping" the geyser, but while you're being stopped, your intended velocity keeps increasing, and at some point, you'll be fast enough to reach the ground again. Exactly as you start sprinting backwards on a conveyor belt.

So I ended up using the yellow code instead: directly change the polarity of the gravity based on the sign of the terminal velocity stored as a per-tile-type property. Not perfect, but close enough for now.

Mais en fait, il n'y a pas tant à changer que ça: plutôt que de déplacer Bilou, on va utiliser l'information stockée pour contraindre la vitesse maximale ... et tant qu'à faire, inverser la poussée si la vitesse maximale est négative. J'ai pris des vitesse identiques pour la gravité et le jet d'eau pour le "petit nuage" en haut du geyser, ce qui lui donne un mouvement symétrique alors que pour Bilou, la gravité lui permet d'acquérir une vitesse jusqu'à 3 fois plus grande, et il a donc tendance à s'enfoncer plus dans le jet d'eau. ça suffira pour le premier jet ;-)

edit: valeur maximale -2px/frame validée: il suffit de garder le bouton de saut enfoncé pour décoller bien au-dessus du geyser. Et si on tombe du sommet, on ne redescend pas trop bas.
 

Post by @PypeBros@mastodon.social

View on Mastodon

Gamebrew / platformers

Somebody on gbatemp surprised me back in 2016 claiming (about School Rush)

HOLY CRAP! I'm surprised to see an actual game here, because usually most DS Homebrew is just shitty abandoned tech demos. Nice job on this! I'll check it out soon.

I dug that one again not so lately after School Rush finally got its Gamebrew Wiki entry and it felt hard to believe given the 1394 other entries the wiki has just for NDS games. There had been some unfinished titles for sure that had just enough contents to rank fairly in seasonly "coding" competitions, but there had also been brilliant titles. It was just after I ran into some "7 best DS games" that would only mention a few FPS and then non-game homebrews... I can't review all 1394 games, but I sure could give the "platformers" category a spin

"Sonic, the game" defines quite well the first category: graphics ripped from various 2D titles in Mario and Sonic series, unfinished physics and uninspired level design and no sound whatsoever. At least it demonstrates scrolling in large levels with parallax effect for the background layer.

Monky. One-screen collect-and-progress game. You'll have to backtrack if you missed some letters on the way. You'll lose all the collected bananas if you get hit. 1 monster type, 4 levels (as far as I can tell). (Unrelated) background music featuring a mod player and a few sound effects.
A nice tech demo using PaLib and graphics ripped from DK Jungle climb GBA game, but not very inspired as far as game and level design goes.

I did not pass level 1 on first play. I missed a key gamedesign element: as you keep moving forward, you'll enter a sort of "run state" where you jump higher. There seems to be 4 worlds of 5 levels each ... that would be worth playing more before rating the quality of level design. You've got sound and music, but if you've played some pinball titles on the Amiga, you'll immediately recognize the style and honestly, it doesn't quite fit the coconut plains of the first levels. 

Temple Topple could have been featured in our "Biloutris" project, I guess. Block falls, they disappear if they line up, but you can't move them (at least, I don't think so). You do have to avoid getting crushed, though. Don't expect much variety as you play. None of the little things that can make such a "climbing" game really funny.

Starting a game has a significant chance of being unfair. Once you're one or 2 screens away from the bottom, there's little chance of getting crushed, and in between, there's a good chance you'll have to wait for the next jump option to show up. I gave up around 1300 pixels high, out of boredom. I would bet on looped WAV/MP3 sample for the background music. It might have been the author's hands-on title for DS Game Maker...

I tried Epic Caveman, too, and understood why the wiki entry only lists the title screen. The title is an endless runner, somehow akin to the "running zilla" game offered when a chrome browser cannot connect to the internet. But here obstacle are quite large, right form the start, requiring very precise timing to clear the jump over them. You can't jump "on" them either, which doesn't seem to make sense in this context. An there will be sudden speed up, requiring you to adjust the tediously learnt timing on the fly. Not even between series of blocks but *within* a series.

There's some sound but nothing really impressive. I'd put it in the category "mini-game of an afternoon, to check you've understood how to use assert import and can structure your project with different screens around the main game screen. Good for a programming tutorial if you had the source, but hardly interesting as a game, although - unlike "sonic the game" - there is coherency and care to detail here.

edit: okay, this is what "sonic the game looks like. and you don't see the fact that if you nearly land on a "platform", it will push you backwards so you can safely fall down instead of remaining balancing on a few pixels. That reminds me why the real sonic has *two* vertical sensors, and not just one. 

(yeah, I hesitated to dedicate 280KiB of blog storage to show that, and I certainly didn't want it to become the post's thumb picture)