Thursday, July 13, 2017

cyblog de retour.

Voilà ... quelques retouches à mon projet "blogpress" puisque je m'étais fait exiler sur le vieux PC bruyant où je l'avais développé. Et j'en extrait un livre de 600 mini-pages avec les posts sur le thème "quel jeu ?"

Bien sympa. En Français exclusivement (puisque je filtre le contenu des balises "<en>" au moment de l'export pour le format .epub), et perfectible:
  • j'approche les 50Mo pour un thème (une dizaine de tags sur le blog)
  • trop d'images dupliquées. Il faudra les identifier (fdupes) et n'en garder qu'une de chaque
  • la construction d'un chapitre par tag est plus intéressante parce qu'elle permet de cibler la lecture (en tout cas pour moi)
  • Tous les liens page-à-page sont pour l'instant perdus (si on clique dessus, la liseuse essaiera d'aller se connecter sur le blog)
Enfin, je serai prêt à affronter les plages et les plaines de jeu ^_^

Saturday, July 08, 2017

Loading Chaos

Il y a environ 2 ans, quand j'ai reçu le commentaire d'Eric sur School Rush, j'étais en pleine tentative de changer radicalement la manière dont fonctionne le chargement des niveaux dans GEDS. Malheureusement, rien ne se déroulait comme je voulais. Du coup, sa remarque

Pourquoi le chargement des niveaux est aussi chaotique ??
est un peu restée en suspens. Je ne savais pas vraiment en faire grand-chose.

Remember Eric's comment that level loading felt like chaos? I haven't addressed it so far, partly because when he mentioned it, I was struggling to improve the way levels are loaded with libgeds. Meanwhile, the reason for which I wanted improved levels loading (a power-up shop) vanished and the chaos got hidden by "black curtains" (actually, the "window" feature of the NDS hardware). But loading time was still excessive and nothing happens while loading.

Entre-temps, le projet de "marché au bonus pendant les temps de chargement" est passé à la trappe en faveur d'un niveau-à-vies/power-ups. Le chaos du changement de niveau (en partie dû au fait que j'aime bien savoir si les étapes se passent correctement en phase de développement, j'avoue) est masqué par un "rideau noir", mais le temps de chargement, lui, est toujours aussi long.

En relisant son commentaire cette semaine, juste après avoir ajouté une "page-de-livre magique" supplémentaire, je me rends compte que l'écran du bas (le livre, donc) ne subit presque aucun changement pendant tout le chargement.

I reached that comment again this week, right after I took some time to have a custom "bottom screen picture" for the "credits level" and then realised that the bottom screen remains mostly unchanged (although completely hidden) while we're doing a lot of chaotic stuff on the top screen as result of the level loading. So If I want the player to get some info about the story, or tease/teach him, the bottom screen could do the job.

En haut, tous les graphismes sont re-chargés, puis la nouvelle map est mise à l'écran, puis -- seulement quand tous les scripts ont étés traduits en machines d'états et tous les personnages positionnés -- on peut positionner la caméra dans le niveau à l'endroit où doit commencer l'action.

Mais en bas, rien ne se produit jusqu'à ce que le niveau soit déclaré "prêt". Je peux donc repêcher une des illustrations qui servaient à présenter les niveau de difficulté et les donner en pâture au joueur -- peut-être avec un message adapté à sa performance (première arrivée dans le niveau, première raté dans le niveau, dernière chance). 

So I crafted a small prototype, that shows one of the 'difficulty selection' pictures and hides it just before we're about to show the "let's play" pages of the HUD book again to resume playing. Now that this is satisfying, I'll have to think about a few more pictures (one per level) and some messages.

J'ai un premier prototype pour ce genre de chose. Afficher l'image au moment où on commence le chargement, c'est facile. Je dois maintenant retrouver dans la séquence "démarrage du niveau" le moment où le niveau va démarrer de sorte qu'on puisse éviter un "glitch" du genre "la page de chargement était affichée, la page de jeu s'affiche un instant, puis l'écran devient brusquement noir avant de se rouvrir sue la page de jeu". N'est-ce pas, Eric ?
  • [done] glitchless showScreen() while loading.
  • [unplanned but done] refactor so that "hud.mode" is defined through script
  • [unplanned todo] refactor so that showScreen is called from "hud.load/show"
  • [todo] adapt the picture to show to the level we're in
  • [todo] adapt the position to show to the lives we have (for specific messages)
  • [todo] make it tell the story of the game

Thursday, July 06, 2017

Nieborg's Colors

Henk Nieborg, maître incontesté du Pixel art qui s'inscrit sur Patreon, c'était plutôt inattendu. Mais un artiste d'un niveau pareil qui propose des tutoriels, c'est le bienvenu.

Unexpected, but very welcome. Henk Nieborg, the Pixel Art Guru, is looking for Patreons! And to get some more, he's releasing a few very interesting tutorials. A good occasion for me to try to figure out how he picks his colors for a "green zone" setting. (So as you have guessed, the picture here is not exactly Henk's tutorial, but my #pixelstudy of it ;)

L'image ci-contre n'est pas directement un des tutoriels du maître, mais le résultat de ma session de "pixel study" pour voir un peu comment il choisit ses couleurs. Résultat ? Eh bien, si le buisson d'arrière plan correspond assez bien à ce qui est recommandé d'ordinaire (décalage chromatique entre les ton obscurs et les tons clairs), j'ai été assez surpris de voir la palette pour la terre rester pratiquement sur la même tonalité (avec uniquement un changement de luminosité) et de voir que toutes les couleurs utilisées pour les "herbes" sont complètement saturées...

PS: c'est moi ou les herbes font penser à des cheveux en bataille ? Y'a quelque-chose à creuser pour Bilou, là ^_^


Wednesday, July 05, 2017

Bonus tuto

Un stage bonus pour refaire le plein de power-up quand on est malencontreusement tombé dans l'encre, je trouve ça une bonne idée. Recycler pour ce faire le tout premier niveau de mon frangin (Calimero) ? J'aime beaucoup (et lui aussi ^_^).

Par contre, démarrer du début "historique" de ce niveau-là et laisser le joueur galérer pour trouver les power-up et rester en vie jusqu'à la sortie ... peut faire mieux. Et ce serait d'autant plus intéressant de faire mieux que ce niveau bonus pourrait aussi être l'endroit idéal pour se familiariser avec les power-ups en question, sans subir le stress de l'encre qui monte.

D'où l'idée de faire débarquer le joueur à des points différents du niveau, selon le nombre de fois où il y retourne. Devant un des power-ups d'abord, puis devant celui qui permet de débloquer l'autre, puis enfin au "début historique".

Du coup, ça demandera d'avoir des portions de script qui sont lue ou non selon un des compteur du jeu. (qui est aussi un préambule aux check-points).

Sunday, July 02, 2017

The secret exit

Le niveau-tour ? je n'y ai pas vraiment touché ces derniers jours. Par contre, j'ai enfin "débloqué" la manière d'y accéder. Ou mettre les indices pour l'énigme, quelle sera cette énigme, et aussi mettre ça en place.

I think I found the way to do it now. I have an enigma on the last level, a clue on the credits if you take the "easy" exit about what you could do to break that "reincarnations circle", and the code to make it work. It could be better, especially in that it is not because we manage to be fast that we unlock the final level in a name dubbed "School Rush". There is a tussle in my mind on whether I should post a few pixels about it or to keep it truly secret as a rewards for those who will finish the game. So far the "keep it secret" side is winning.

Wednesday, June 28, 2017

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)

Sunday, June 25, 2017

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.