UML_LOOK = YES ?

Voilà un des schémas que Doxygen peut produire si je le mets en mode UML (ce qui est sympa, parce que du coup, je peux comprendre les flèches) pour une des classes de mon éditeur de niveaux. Je peux limiter le nombre de "champs" pour chaque catégorie (histoire de garder la taille des boîtes sous contrôle), mais malheureusement pas la profondeur d'exploration. Résultat, le graphe devient vite immense, inutilisable.

When I come back to some code I've been writing long time ago (hey, the project is 10+ years old, now, remember?), I usually take some time with my cybook to study the code through doxyge-rendered documents and sketch in UML what is meaningful for the feature I want to add/change. So it would make sense to have doxygen do some UML for me, wouldn't it ?

Well, doxygen indeed has an UML_LOOK setting that turns available as soon as you declare to have the "dot" graph tool from graphviz package on your (linux) system. Neat. It also has -- took me some time to find them -- settings to reduce the amount of classes that are explored, and the amount of items that are reported for each class.

This is all quite nice, but I'm afraid it will not work nicely with cybook viewing. Whatever I do, the collaboration graph remains very large, both in pixels (and I'm unsure the cybook could pan in a bigger image) and in bytes (10x bigger than doxygen's defaults -- which had only inheritance graph, I admit).

Non configurable ? vraiment ? Voyons, et DOT_GRAPH_MAX_NODES, alors ? et DOT_GRAPH_MAX_DEPTH ?

Eh bien ils font plutôt du bon travail, mais je reste avec près de 3Mo de fichiers .svg pour LEDS, contre 500Ko de .png quand je reste aux graphes de base. Pour la lecture sur tablette, je crois que je préfère ne pas prendre le risque.

What would the perfect feature set be ?
- having the inspected class at the center of the diagram
- be able to specify a canvas size, instead of a maximum amount of nodes
- don't say "and ## more items" when you drop some items
- have a separate "depth" setting for inheritance and for structure/composition
- only show "meaningful" methods/fields of surrounding classes
- still show when a class has relationships with multiple classes of the graph
- don't show "obvious" common ancestors (e.g. the Widget class for all the widgets)
- don't show "obvious" type of data that everyone uses (e.g. std::vector) as a compound.

But let's be pragmatic: this is not the job of a heuristic filter: this is the job of an interactive exploring program. Sure I wish such an interactive tool could be running on my e-ink device, but this is not part of Cybook's business plans, unfortunately. And it is unclear that this could be achieved solely through e-pub documents structure. (would more require an HTML5 canvas or dynamic SVG + JavaScript)

rules.gam

Plus proche de nous, mais en partie lié avec ce nouveau projet "behaviour editor",il y a le besoin de pouvoir utiliser un seul même fichier pour définir certains morceaux des scripts qui décrivent les niveaux. Ce n'était pas trop un soucis avec Apple Assault, un jeu dont les "règles" était assez simples, mais qui devient plus pénible à gérer avec School Rush.

Un niveau de School Rush décrit plusieurs types de choses: des resources (map, planches de sprites), des personnages (à travers les fichiers .cmd de comportement à charger), les positions et paramètres des personnages (définis par l'éditeur de niveau) et ce que j'appelle "les règles du jeu": réactions quand un compteur arrive à zéro, valeur initiale des compteurs (p.ex. le nombre de point de vie restant pour le joueur) et les propriétés des blocs spéciaux.

Pour l'instant, ces règles sont répétées à chaque niveau, et plus le projet avance, plus le risque augmente d'avoir un niveau ou p.ex. il est impossible de reprendre de la vie parce qu'il y a un bug dans les règles dans ce niveau-là.

Et le nombre d'animations pour les bonus augmente encore la pression sur ce point chatouilleux.

Extraire tout ça en un fichier qui serait "importé" par chaque niveau devrait être possible sans trop de difficultés, de la même façon que les machines d'états ne sont décrites qu'une seule fois et importées dans les niveaux où on a besoin d'elles. Par contre, pour pouvoir continuer à utiliser les indices graphiques dans l'éditeur de fichier, il faut qu'il sache qu'il doit y chercher les descriptions des blocs spéciaux.

Cela dit, en refaisant un peu d'exploration dans les sources de LEDS, j'ai noté que c'est simplement sur base de l'extension de fichier (.spr, .map, .cmd) que le code destiné à charger le niveau décide de ce qu'il va faire de chaque "fichier supplémentaire renseigné par le script du niveau). On devrait donc pouvoir utiliser un autre type d'extension (.gam ?) pour que l'éditeur de niveau s'y retrouve. Tout simplement.

Behaviour Edition ... brainstorm

Prochain outil pour le projet "dsgametoosl" ? Je ne sais pas encore. Mais j'aimerais beaucoup construire quelque-chose qui permette de manipuler les machine d'état définissant le comportement des personnages dans les jeux qui tournent sur mon moteur "geds".

Quelque-chose à moitié graphique (je clique sur un bilou en train de sauter, on me montre tous les états qui sont accessibles depuis celui-là. J'en choisis un, je vois les conditions et les actions annexes pour la transition correspondante si elle existe), et à moitié texte (je peux en éditer une ou en créer une nouvelle, sans s'embêter, rien qu'en écrivant les expressions que je veux).

Quelque-chose de pratique (je clique sur une variable, je vois tous les états où elle est manipulée).

Pour permettre la réalisation de "School Rush", j'ai introduit pas mal de fonctions à coup de macros qui permettaient de "nommer" des tests du genre "est-ce que la direction choisie sur le DPAD va vers la droite ?" Pour que l'éditeur soit pratique, il faudrait qu'il permette de conserver ce genre de simplifications, et ne pas imposer à l'utilisateur de mettre dans chaque test "est-ce que le bit 5 de la variable numéro 3 est à 1?"

Du coup, l'éditeur doit à la fois savoir que l'expression utilise la variable 3 (l'état du dpad) pour qu'elle soit listée dans "toutes les expressions qui dépendent du DPAD), mais aussi qu'elle s'affiche avec un "DRIGHT". et pouvoir indiquer à l'utilisateur ce que fait DRIGHT au cas où ce ne serait pas suffisamment explicite.

ça demande d'une part de faire avec assez de précision le tour de tous les éléments de scripting qui ont besoin de pouvoir servir de "critère de tri", mais aussi de faire en sorte que le logiciel tournant sur DS puisse comprendre la version "évoluée" du script et puisse en tirer la version "interprétable par le moteur de jeu" pour essayer les modifications dans runME.

Un défi qui n'est pas à prendre à la légère, en fait. J'avais envisagé pendant mes congés de l'an dernier de refaire l'équivalent du préprocesseur de gcc, mais je me rends compte aujourd'hui que je suis parfaitement libre d'utiliser autre-chose que des macros C pourvu que je sois en mesure de produire le fichier voulu. Par exemple en produisant un fichier .h à partir de ce que le nouvel éditeur utilise pour connaître les variables, les compteurs, les types de collisions, etc.

Ce sous-projet m'intéresse pas mal, et commence à consommer de plus en plus de feuilles quadrillées dans mes petits carnets, même si je traîne un peu à blogger tout ça ces derniers temps. J'ai ma petite idée sur la saisie de texte (à mi-chemin entre pixel-art et reconnaissance d'écriture manuscripte), par exemple, ou  la possibilité de représenter sous une forme d'arbre les expressions mathématiques du style "v6 := min(v6 - 32 , -400)" qui s'écrit en GobScript "v6 32 - 400 ~ m :6" pour être plus facile à traiter par l'interpréteur.

runme + assault = todo

I'd love to have the time to provide a real tutorial for people to start working with libgeds. So far, the best I have is a package with 8-bitifed graphics for AppleAssault and the corresponding game/character scripts... which -- thanks to some work I did a few weeks ago -- now also comes with a copy of RunMe that can run all of that. Maybe that will at some point make it more interesting to start working with the Game Engine for DS.

Of course, because runME is a tool primarily designed to transfer files, it will not exactly be easy to start a game there.

Bon, j'avoue, j'adorerais avoir le temps de travailler sur un vrai tutoriel pour le système lib geds, mais jusqu'ici, la seule chose qui s'en rapproche un petit peu, c'est une sorte de kit avec les graphismes de Apple Assault en version 8-bit et les script correspondant pour les personnages et pour le jeu. Et grâce au travail de ces dernières semaines,  tout ça i tourne maintenant avec une version récente de runme. youpi. Peut-être que ça rendra les choses plus faciles pour ceux qui veulent commencer à travailler avec le game engine for ds on peut toujours rêver...

click 'offline', then 'cmd'	click 'A' to pick one of ASSAULT*.CMD, and then click the name you want to run	press now L+A to load the script into the memory	and now press L+Y to process that script to the end.

Évidemment, le programme 'runMe' est avant tout un outil de téléchargement. Donc il faut un peu chipoter pour pouvoir démarrer son programme:  passer la détection réseau , par exemple, puis choisir le fichier qu'on veut démarrer, et des commandes un peu barbare du genre La+À ou L+y pour démarrer la lecture du script ou pour l'interpréter sur la DS.

When I want to run this, I do it with desmume-cli, using --cflash-path=AA-efsroot (which is in the 'runMe.zip' archive) and --load-type=1. But that only works in Linux. For windows user, you'll have to go into config->slot2 and setup the directory manually (I just hope for Windows users that they can somehow save that configuration)

Il faudra aussi s'assurer que l'émulateur a accès au fichier du jeu qu'on veut essayer. Moi, je fais ça à la ligne de commande dans Linux, mais évidemment, les gens qui travaillent sous Windows devront passer par les menus de configuration de desmume pour avoir la même fonctionnalité ( voir l'image).

Voilà, avec tout ça vous avez la possibilité de tester le jeu que vous avez vous êtes en train de développer, mais malheureusement, s'il y a des erreurs dans le script, c'est encore très laborieux de les trouver et de les corriger. On peut faire mieux avec l'outil de test automatique que j'ai développé pour mettre School rush au point, mais c'est un truc qui doit être compilé à part. Et pour l'instant, il faut même le compiler à chaque fois qu'on veut essayer de traiter de nouveaux script pour un nouveau jeu, donc il faudrait que je fasse appel à l'équipe pour avoir une variante qui tourne sous Windows histoire que les jeunes puissent essayer de faire le même. Mais voilà, l'équipe, pour l'instant c'est juste bibi. alors soit vous vous enrolez, soit de vous patientez. Ciao.

All this makes you able to try the game you're developing, but when there are errors in the script, you just have a stop with the content of the offending line dumped.
Hopefully, It can now also be checked with 'testme', the unit-testing tool for current School Rush game. (which unfortunately still requires a rebuild for Windows everytime you change the scripts you want to check).

I could really use a helping hand to get that going somewhere. Someone who's used to do builds of Linux native projects in a Windows environment. Even then, it's unclear whether I can compete with a tool such as DSGameMaker, but I still think people should have the choice ^_^

Oh, et si vous allez jusque là, la présence du "log" deviendra vite gênante dès le niveau chargé avec succès. Rassurez-vous: il est tout à fait possible de le faire disparaître: il suffit pour ça de toucher le bouton 'log' sur l'écran du bas. Et si vous voulez retourner charger un autre niveau, le bouton "beam out" vous ramènera sur l'écran avec la liste de fichier et le "clavier virtuel" (qui fait les "lettres paires" quand on garde L enfoncé, soit dit en passant).

Et pendant que vous lisiez tout ça, j'ai ajusté la position des vagues d'encre pour le "niveau retour" de School Rush...

Updating Doxyfile

Depuis 2014, je n'utilise apparemment plus que d'anciennes versions de mon code sur ma liseuse Cybook. Du coup, l'utilité s'en trouve assez bien réduite. En cause ? le comportement du nouveau doxygen (1.8.11 contre le 1.7.6 qui avait donné des résultats plus satisfaisants à force de bricole).

Pendant un moment, je me suis dit que je ferais mieux de passer par DocBook (dont je ne sais pas grand-chose excepté le fait qu'il s'agit d'xml). En fait, ce ne serait pas la bonne approche:

1. le générateur de documentation DocBook de doxygen ne fournit pas les "fragments de code" qui sont essentiels pour mon utilisation
2. s'il existe des epub-tools pour faire la conversion docbook->epub, le contenu même du format e-pub c'est ... de l'HTML.

It looks like the last time I updated code shown on my cybook e-ink reader was in 2014. The reason is the newer doxygen that came with with ubuntu since then produces HTML code that makes much less usable epubs.

I realize that CSS support on cybook is picky on what works and what doesn't. Plus there are now 'tooltip' additional information that calibre unrolls between each function. And line numbers, which I don't need in this context either and impede readability.

J'ai donc repris point par point les choses qui posent problème dans la sortie de doxygen 1.8.11

• les modifications pour que le code ressemble à du code et ne soit pas trop grand ne marchent plus. La faute à un nouveau jeu de règles CSS. Mais en réalité, les modifications que j'avais apportées à ces règles sont assez peu nombreuses, et je devrais donc pouvoir faire l'équivalent sur le nouvea fichier CSS.
• les blocs indésirables en fin de fragment de code sont en réalité les tooltips, rendus visibles soit par calibre (le logiciel que j'utilise pour la conversion HTML->epub), soit par mon remplacement sauvage du .css de doxygen 1.8 par un .css modifé venant de doxygen 1.7 ... quoi qu'il en soit, définir SOURCE_TOOLTIPS=NO permet de les évincer du code HTML sans devoir y aller à coup d'expressions régulières. Et si rien ne m'indiquait que c'était possible dans mon DoxyFile, c'est tout simplement que je travaillais dans un fichier 1.7 où la fonction était indisponible ^^"
• les indentations déviantes s'expliquent par une largeur de tabulations de 3 dans les règlages de Doxygen alors qu'elles sont définies à 8 caractères dans mon éditeur. Et que malheureusement il y a toujours dans le code un mélange d'espaces et de tabulations pour indenter le code >_<
• Enfin, pour les numéros de lignes, je n'ai rien trouvé pouvant les supprimer, mais ils ont heureusement une structure très prévisible dans le code HTML. Un sed -ie "s:[ 0-9]*::g" *.html, et on en sera quitte.

Et je préparais un commentaire désobligeant sur la lenteur de conversion à laquelle calibre m'avait habitué, mais il semble que la version présente sur Ubuntu 16.04 a réglé ça. Voyons donc ...

Verdict : il y a encore du travail. Lors de la conversion, je me farcis un retour à la ligne chaque fois qu'on passe à un autre type d'élément syntaxique connue (un mot-clé, un type de donnée, une variable reconnue, une chaîne littérale, etc.)

aniballs

déterrage: une série d'images faites dans SEDS pour un clone de "chuzzle" sur DS qui n'a jamais démarré faute d'avoir pu faire un lapin-tout-rond suffisamment convainquant.

Closing level

En plus du niveau "vertical" pour mettre un dernier coup au joueur exigeant, j'ai attaqué un "niveau de retour" avec les crédits du jeu.
- il faudra ajouter un état "arrivé dans l'encre" qui permette à Spongebop de s'enfoncer un peu avant de se mettre à flotter
- il faudra utiliser un "momentum(y) pour que SpongeBop donne un peu plus l'impression de flotter
[done] il faudra que la "mort" provoque le retour immédiat au niveau suivant
[done] ce serait sympa que les bonus récoltés sur ce niveau donne l'indice pour pouvoir accéder à la "vraie fin" (p.ex. en dévoilant progressivement le texte sur le livre)

I've started one more map that will be a playable credits sequence. I've got a few idea of how to make it interesting and fun... let's see if they work in the upcoming weeks (days?)


Côté musique, CJ est sur le coup, évidemment. Ce ne sera pas When Bilou Wins, en tout cas.

School Rush update

At last, here comes an update on School Rush. Still featuring the 4 levels from last year, but with improved gameplay (especially through slightly increased gravity), improved game feel and a starting level that is more fair. I dub it "splashed" release because most of these changes were suggested by the author of Splashers ;-)

Voici enfin une mise à jour pour School Rush. Toujours les même 4 niveaux que la fois dernière, mais avec un gameplay amélioré, plus de petites animations sur les objets interactifs (gommes et bonus) et un premier niveau plus accessible même en mode normal. Et vu que la grande majorité de tout ça m'a été recommandé par l'auteur de Splashers, je baptise cette release "splashed" ^_^

(gameplay and story migrated to latest release

How to play

Get the NDS image and play it on your homebrew-ready console or in an emulator, such as DeSmuME. See this page if you need extra explanation/instructions for running homebrews.