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.

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

• [fixed] 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
• [fixed] dying on the title screen leads to the game to stall on a blue screen.
• [fixed] none of the runME control widget seems to be working once the game is running...

Pico8

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

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.

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.

class *Model

It's a bit more complicated to make my level editor test-friendly than it was with the sprite editor... so allow me to recap how I proceeded with SEDS:

hmm ... je pensais que ce serait plus simple que ça d'adapter le code de LEDS pour qu'il permette le même genre de tests que celui de SEDS. En fait non. Sans doute parce que j'ai déjà essayé d'avoir une couche "modèle" pour LEDS mais qu'elle ne correspond pas assez bien à ce dont j'ai besoin.

Guidelines

• the model captures all the information about internal state of the edited object.
• the UI code makes no access to the components of the model (i.e. a palette, a spritesheet, ...) without going through one of the model's function
• code within the model is free from any UI interaction
• each UI component (aka *Window) has its corresponding model capturing the information it needs. When a component is used by multiple UIs, we'll use a common ancestor (e.g. ModelWithSheet) to capture the shared component.
• editor-specific extensions to the library component (e.g. EditorSpriteSheet extends SpriteSheet) is declared at the *Model.h level.

Outcome

• Every operation performed on edited objects can be reproduced out of native UI environment for testing
• Dependent objects are created together as a *Model, making it simple to ensure they're working correctly with each other.
• main code no longer needs to maintain and dispatch pointers to shared component all over the place, while components themselves still blissfully ignore where the peer components they're working with are managed.

Juju & Peyo

C'est un chouette nouveau (2014) jeu que je (re-)trouve là: Juju and Peyo, que je classerai dans le filon "donkey kong returns" mais plutôt ciblé sur les joueurs moins aguerris, en particulier étant donné la vitesse de marche assez poussive du personnage. Par contre, attaque par boost, éléments à retrouver, petits éléments du décor qui libèrent des bonus à ratrapper (et qui volent, éventuellement en suivant un pattern pré-défini). Ambiance colorée, mais globalement plus lisible qu'un Giana Sisters Twisted Dreams, voire même qu'un DKC returns lui-même. 'faudra que je demande à mon frère s'il trouve ça sur sa PS3...

En plus des mouvements de base déjà mentionnés, notre petit ourson rose peut faire un "mouvement de danse magique". Il assomme les ennemis, déclenche des mécanismes, ouvre des coffres au trésor, etc.
Un élément qui complète le gameplay de manière plus sympathique que des interrupteurs ou des clés, à mon avis, et qui manque dans bon nombre de jeux d'exploration.

Les joueurs rodés pourront utiliser la charge pour progresser un peu plus rapidement dans les niveaux, à défaut d'un bouton de course à la Mario (pour autant que je puisse en juger à travers les 'Let's Play'). Ouf. Par contre, on reste sur des ennemis au comportement assez simple, j'en prends pour exemple les crabes qui sont vulnérables à toutes les attaques là où ceux de DKCR demandent soit une roulade ou un saut selon qu'ils ont les pinces en l'air ou à l'horizontale (et peuvent demander plusieurs hits, en changeant de position entre les hits).

Côté design, j'aime beaucoup les espèces de golems musicaux, spectateurs, partiellement acteurs mais incapable de vraiment interagir avec l'avatar du joueur.

Ils pourraient presque faire partie d'un Rayman Origins. Il y a plein de très chouettes éléments de décors, mais aussi un grand nombre de blocs qui font juste "asset" quasi-générique... je n'ai pas encore mis le doigt sur ce qui a un goût de loupé, de ce côté-là.