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.

jeudi, janvier 26, 2017

What happens ?

  • Something goes wrong with runMe ... switching between game play testing and file management needs to be revised. 
  • At the moment, some event make the UI buttons unresponsive. I can't get the display restored properly, which makes investigating why point 1 occurs ... 
No escape, I think. I'll have to do some code mapping using carbonic support to refresh my mind.

samedi, janvier 07, 2017

runMe is coming back

I got the most annoying bugs fixed, and in the "restructuring" branch, I'll also be able to use the same controllers/shooters state machine plug-ins for both runMe (the interactive playtest tool) and the final SchoolTest ROM.

I can choose between regular background and debug console output too. InspectorWidget, on the other hand, is messed up with some text. I'll be able to resume level design...

Avoir mon programme de chargement à nouveau opérationnel, c'est plutôt une bonne chose. Il est peu utile de faire progresser l'éditeur de niveaux -- ou de dessiner un nouveau niveau à la verticale -- si je dois à chaque fois transférer le niveau hors de la DS, recompiler tout et récupérer à nouveau le .nds sur la console pour faire le test... et c'est bien à ça que runMe me sert le plus: tenter un morceau de niveau avant de retourner dans l'éditeur, faute d'un mode "modification de la map en cours de jeu" qui serait indispensable pour un projet plus sérieux.

well as soon as I figure out why the level editor is stripping out all the dynamic objects. (not that it's so surprising, as the last thing I tried was to remove dynamic objects that were out of the level's boundaries).

There are other oddities linked to incomplete port to the latest devkitpro/devkitarm/libnds, imho, such as

  • [fixme] no sound playing in new builds of runMe
  • [fixed] no EFS found for SchoolTest
  • [workaround] everytime a level is loaded, 3D effect is zoomed out a bit more
  • [fixme] dying on the title screen leads to the game to stall on a blue screen.
  • [fixme] none of the runME control widget seems to be working once the game is running...

mercredi, janvier 04, 2017


La pseudo-console PICO8 est sans doute le gadget le plus sympa que j'aie découvert au cours de l'an dernier. Un système tout-en-un, avec une programmation style BASIC (mais pas tout à fait) et un petit éditeur de graphisme et de son intégré, tout à fait dans l'esprit "game development for all", mais sur un support imaginaire, accessible via un browser et sur un assez grand nombre de systèmes. Des petits jeux qui rappellent l'âge de la programmation de garage sur commodore.

I'm enthusiast. PICO8 virtual console and the PocketC.H.I.P computer are likely the gadget-computers I love the most among those "thing-a-teach-kids-coding" I've met so far. BASIC-style, embedded editors. Easy to take along. I played a few platformer projects last week-end and enjoyed quite a lot of them. They remind me of fresh little projects that could be found in the garage-afternoon-devin' times of the C64 era. It's unclear to me whether that could support logic as complex as the one found in School Rush, though.

Si je n'en parle que maintenant, c'est que jusque là, je n'avais pas eu l'occasion de voir de plus près à quoi la programmation peut effectivement ressembler (mis à part quelques démos officielles). Mais je suis tombé cet après-midi sur un tuto "comment faire son premier shoot-em-up" en quelques gifs animés.

Et à mon avis un des hardwares les plus sympas pour faire tourner cet émulateur 8-bit, c'est le PocketCHIP... un ordinateur de la taille d'une calculette des années '80

samedi, décembre 31, 2016

L'avis d'Eric

C'est la dernière journée de 2016. Une année qui aura commencé (en ce qui concerne ce projet) par du débugging intense de mon moteur de jeu et qui termine ... par du débugging intense de l'outil "runME" histoire de pouvoir reprendre le dévelopement de nouveaux niveaux.

Mais entre les deux, j'ai l'immense honneur d'avoir reçu un feedback direct pour la grande release de SchoolRush par Eric Zmiro, développeur professionnel à temps plein dans le jeu vidéo, qui a travaillé aussi sur DS et qui a fait du game design aussi bien que du level design et de la programmation système.

Here ends 2016. A year mostly of system debugging and tools polishing, but also the year where I finally could make the first fully playable and polished release of School Rush, the Bilou-based game I've been working on since ... 2013. My goal was to have something I could proudly show to video game professionals, and I got the honour to receive feedback from Eric Zmiro, who developed most of the platformers I played on PC when Bilou was first created. 

L'univers est vraiment bien trouvé avec des attributs cohérents (l'encre, les gommes qui rebondissent, les crayons qui piquent, etc.). C'est super dur (et au clavier surement encore plus) j'ai bien avancé le second niveau, mais pas pu le finir !

A mon avis, sorti plus tôt, vous le vendiez !

It's extremely rewarding to hear "it could sell" from someone who's been experiencing the odds of creating games for a living, even when that's modulated with time traveling conditions. Eric described the game as fun (good thing too: I always loved the humour in Prehistorik series) and really hard (which makes me smile, given how many lives I wasted in spikes and fire of his own games ;)

Venant de l'homme qui a conçu les niveaux de "Titus, the Fox", et (iirc) de Prehistorik 2, je prends le "super dur" avec un immense sourire. Et quand je lui demande pourquoi "sorti plus tôt",
C'est surtout la plateforme qu'est en retard en fait. Sur DS tout projet est mort. Autrement, concernant le jeu lui même (qu'est vraiment dur, p''ain, ou alors ce sont les sauts qui sont mal calibrés, mais je n'arrète pas de me gauffrer) c'est plutôt rigolo. Je ne sais pas comment est la suite, mais si on note une progression dans les niveaux, ça peut être pas mal !
Et parmi les bugs/améliorations nécessaires relevés (programmeur système, hein, n'oubliez pas ;) 
  • pourquoi quand on monte sur le truc a patte (taille crayon ?) et qu'il avance, on avance 2x plus vite ?
  • Pourquoi le chargement des niveaux est aussi chaotique ??

Dans un cas comme dans l'autre, ces bugs sont liés à des insuffisance du moteur de jeu. Ce ne sera pas simple de les corriger, mais si ça saute aux yeux des professionnels, je ne peux pas le laisser tel quel.

mardi, décembre 20, 2016

The latest devkitpro

  • [solved] latest runme crash with stack=0 when loading the title screen
  • runme triggers a crash of desmume-cli, version 0.9.11 when --cflash-path is used to grant access to data items
  • same runme can be launched when no --cflash-path is provided
  • same runme works fine when emulated on old desmume (0.9.6, 32-bit, running on old laptop), even with --cflash-path
  • same runme crashes when emulated on old desmume (0.9.6) rebuilt on 64-bit system, with --cflash-path
  • SchoolTest can read the title screen, but suffers the same "stuck-on-the-title-screen" bug as observed on the Androïd emulator
  • desmume 0.9.11 apparently doesn't emulate bad address / invalid instruction. That's not going to help.
Sounds like there will be some guru meditation in the upcoming weeks...

Si les tests automatiques avaient plutôt bien supporté le passage d'un vieux devkitpro à un plus récent, les outils du type "runMe" et le test du jeu s'en sortent moins bien. Il n'y aura probablement pas de "release Noël" de School Rush ...

First step to sort that out would be to make sure I can see last command the parser tried to parse. That should already be mentioned in the "die()" function, but with such a stackless-crash, it is unclear it would be possible to call a function at all.

Second priority will be to figure out whether the "latest devkitpro/libnds-1.5.12"  team still properly support the "register exception handler" feature.

Finally, I'll have to try freshly compiled SchoolTest against my old desmume, just to check where the regression is.