samedi, février 18, 2017

Si on relookait la "green zone"

Bon, vous vous demandez peut-être pourquoi avec un moteur de  jeu fonctionnel et des pixels tout prêts il n'y a toujours pas moyen de s'essayer aux niveaux dessinés par Piet dans les années '90...
Il y a la raison du jeu: sans les 6 mondes qui suivent, la green zone n'offre pas, à mon avis, un challenge intéressant. On pourrait se promener dedans,oui. On pourrait y assommer des pommes et y chercher des vies, mais quel intérêt si il y a de toutes façons suffisamment de vies pour terminer les niveaux sans ça ?
Ensuite, il y a la raison du relooking.

I suppose I could be spending my time crafting levels that mimmic the BASIC version of Bilou's Adventure, since I have pixels for the Green Zone and a working game engine. But I question the fun of such a package. The Green Zone doesn't feature sufficient diversity (imho) and is mostly hunting for secret 1-UPs here and there. But what's the point of 1-UPs when you have only 4 levels to explore ?
Je n'ai pas forcément envie que la nouvelle green zone ressemble exactement à la version Basic. Des clés, des portes, des tuyaux et des bumpers ? Bilou ressemblerait alors à un mélange entre sonic, Mario et keen. Je voudrais qu'il ait plus son identité propre. Un napin qui aide à sauter, un mécanisme pour ouvrir le passage... Le genre de chose que Piet aurait mis en place si je n'avais pas dû simplifier pour que ça passe en Basic.

The second reason I'm not jumping into that is that I still would like some revamp of the mechanics used in those levels. If I stick to floating platforms, bumpers, colored keys and locked doors, Bilou's Green Zone would just look like Sonic * Mario * Commander Keen cross over, which imho wouldn't be interesting. I'd like to have crabit featured as moving bumper, for instance.

I must not put it on hold for too long, though. J.l.n just turned 4 years old and he starting to have the basic skills to jump over pipes and stomp goombas...

dimanche, février 05, 2017

class LayersConfig

All my DS tools share the same "GUI engine", but all somehow have custom requirement on what the hardware compositing engine -- the "layers" system -- should do.

Yet, so far, they do that by peek/poke-like custom lines of code hacking into the video registers of the Nintendo DS. Because the hardware is so elegant, I had no real appeal to hide it between an abstraction layer, but now I run into issues where console can't be read anymore.

So let's try to make it more structured. Capturing all code that access the layers control register into one class would be nice. I think that class -- let it be "LayersConfig" -- could be associated with *Windows classes that define the different "modes" of the application. Switching between the drawing-on-grid and the Palette-edition of the Sprite Editor implies changing the active window. Same for swapping between files picking and map editing of LEDS or swapping between downloads and playtesting in RunME.

I think I should stop trying to optimize which character is updated on such window switches and consider that there should be a clearscreen followed by a full repaint, if that's not yet the case. That could make Window::clearscreen an interesting place to do tricks like letting only some part of the console show through, for instance.