Friday, August 18, 2017

Habillage ...

Il est temps de passer du 'test fonctionnel' à quelque chose de plus "habillé" pour le dernier niveau vertical. Jusqu'ici, je m'étais contenté d'un minimum de graphisme (les blocs-sol) pour vérifier si les sauts étaient possibles. Il est temps de dessiner le reste des objets.

Ouais, sauf que pour avoir des dessus-de-fardes-sur-lesquels-on-marche un peu partout dans le niveau, c'est pas forcément simple. J'avais pensé à des "couches" suggérées par différentes couleurs (il y a déjà une convention dans l'ensemble du jeu du genre farde verte = mur, farde brune/mauve/vert-foncée = plate-forme semi-solide), et faire des structures un peu imbriquées comme avec mes bons-vieux-buissons.

Since April, I've been extending the "vertical, last level" of School Rush with some more platforming challenges. I intentionally kept the look of the level ultra-minimalist for monthes, as it is much easier to tweak the location of the platforms and adjust difficulty that way. I haven't touched the layout of the level in weeks, so I guess it is ready to receive more complete look.

I had plans to fake depth between level elements such as books or binders to justify the presence of so many platforms without having significantly more "ground", although there is some from time to time. And I was also planning to reuse the color conventions present in earlier levels of School Rush, such as "green book = wall, purple book = jump-through platform".

But that was missing the annoying fact that I can change the colors only on the background layer of tiles, while I typically need both background and foreground together to combine small objects into larger structures as I did with the green zone's bushes.


Sauf que pour faire facilement ce genre de choses avec un tileset réduit, je jouais sur les deux plans de tiles, toujours le même pour ce qui est par-devant, l'autre pour tout le reste. Mais mon moteur de jeu ne permet pour l'instant de changer la palette de couleurs que pour les tiles d'arrière plan: les tiles d'avant-plan sont systématiquement "verouillés" sur la palette #0 et les bits correspondants sont utilisés pour encoder le type de bloc.

This is thus one more motivation to change things in the game engine and take the "tiles properties" array out of foreground palette information, but hopefully, I have enough room (~20% left) in my blocks tileset to accommodate for some "combined" tiles, be it at the cost of manual palette retro-fitting.

But I know this cannot be labeled as "the solution" for this problem: It killed the Badman III effort by making the art impossible to manage. Later on, I'll have to address the issue for real.

Bref, pour cette fois-ci, je vais me débrouiller en créant "à la main" des tiles supplémentaires qui "combinent" les deux couches, avec des imports de palette, mais ce ne sera pas beau à regarder dans l'éditeur (parce que le joueur ne devrait pas voir la différence, lui). Décidément, tout cet été pousse vers un déplacement des propriétés du niveau hors des couches de "rendu".

Wednesday, August 02, 2017

On reprend les crayons

(enfin, le porte-mine, plutôt). Les aspects techniques pour avoir une petite image originale au chargement de chaque niveau sont réglés. Je gribouille un peu pour avoir les 4 images qui me plaisent pour raconter l'histoire de School Rush (invasion des crayons-soldats, résistance, déroute et vengeance des soldats en question).

Let's pick up pencils again and draw some 'cutscenes' for SchoolRush to be shown while the level loader is parsing the characters behaviour descriptions again. I had initially planned to recycle those choose-your-difficulty pictures, but the story they're telling shows the pendats defeating the inkjets (comic book's scenario) while I actually need the opposite...

Ce qui s'avère être plus ou moins l'opposé de ce que j'avais prévu de faire raconter au cancrier dans la BD, en fait ... donc il va me falloir encore au moins une dernière image.

Tuesday, July 25, 2017

simplifions le HUD

J'ai attaqué une révision du code de contrôle entre le moteur de jeu et l'affichage de l'écran du livre-magique. J'ai déjà remplacé les tests douteux sur des variables obscures supposés indiquer si on est sur le menu ou dans le jeu par une commande explicite "hud.mode=%c"

The code controlling the HUD logic deseperately needed some refactoring. It smells it has been written with a "oh, come on: this is just testing X and doing Y". As the rules for the game status display became more complex (different pictures for the menu, then custom behaviour for power-ups, then a complete different behaviour for the credits level ...

Je continue avec une simplification des relations entre "GameScript", "GameWindow" (qui s'appelle toujours CmdWindow parce qu'elle s'occupe des fichiers .cmd) et "Hud". Le Script et le HUD sont maintenant créés avant le chargement du niveau, le "setup" qui permet au HUD de savoir quel objet est le héro, où sont les compteurs, le score, etc. se produit explicitement lors du dernier "end"

So I started with making the behaviour of the HUD explicit through hud.mode=xxx in the scripts -- since both menu, credits and game levels are separate scripts. Then I refactored the way the HUD is constructed and linked to the GameScript so that parsing hud.show "xxx.spr" can lead to some Hud::showScreen() although the HUD isn't ready to run its play() function yet (i.e. because it doesn't know the pointer to Bilou's state and to game stats, which will be taught by the GameScript through the Hud::setup() call).

Once again, all this was made possible thanks to doxygen-on-cybook where I could annotate code with refactoring thoughts until I was ready to sketch the desired behaviour as UML. Once this is done, I'm ready to code it in small chunks, one evening at a time.


Enfin, je suis prêt pour un 'hud.show "somefile.spr"' qui me permettra de raconter une petite histoire sur l'écran du bas avec une image différente pour chaque niveau.

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.

I acknowledge Romain's advice that the game should give the player some room to try mechanics even when not entering in 'easy' mode. That's now done for all the basic mechanics, but we still lack a sandbox to try the power-ups. At first, I had hopes that the 'bonus-level-where-you-can-get-some-power-ups-back' could fulfill this need, but it won't. Not in its "historical" shape where you need to collect the 'break-things' power-up, then you can get the 'fly/float' power-up, and eventually you can get out.

But I could get something better if the starting point of Bilou in that level is picked based on how much we've visited it in the past. First, you'd be dropped next to the 'float' power up. Then you'll be dropped next to the 'punch' power-up and finally next to the 'historical starting point'.


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.



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.



Sunday, June 18, 2017

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 runpress now L+A to load the script into the memoryand 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...

Saturday, June 17, 2017

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.
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.)

    Monday, June 05, 2017

    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
    - il faudra que la "mort" provoque le retour immédiat au niveau suivant
    - 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.

    Saturday, June 03, 2017

    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

    You're controlling Bilou, a blue, ball-shaped explorer. You make him JUMP with the (A) button and grab things (or throw them) with (B). Your goal is to reach the right of each level before you're caught by the ever-raising ink.
    You'll need to be quick, too. Use (R) or double-tap in left/right directions as if you were a pink, living vacuum cleaner.

    You can stomp some monsters, you can throw sharpeners at others. Remember: the pencil soldats are the only real threat here, and they must be stopped from pouring even more ink for their autoritarist plans. Everything else that looks dangerous is mostly acting on fear and may prove very useful if you keep your head cold. Think about how useful a bobbing sponge could be if you could ride it (B). or how high an inkwell could shoot you ...

    There are rumours of magical artifacts that could help you. The Fist of Justice, that noone can stand against (double-B) and the Floating Twister (hold A), that let you reach far away places. It's unlikely the pendats will let you recover them without a fight, though.

    Story

    At the far east of this school-like country, there is a gauge that will stop the ink. Rush for it! The books city is close to be destroyed once for all, and the elders' knowledge will be lost. This must be another plot from Square Root, who decided that mathematics are the only thing worth of being written down.
    Everyone here seems to believe that Bilou is a sort of legendary hero...

    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.

    Tuesday, May 30, 2017

    Encre ou pas ?

    J'avais voulu pour la prochaine release couvrir un des autres aspects des commentaires de Romain:

    Côté [level design], est ce que c'est censé faire partie du jeu normal que l'encre monte tout le temps ? En tout cas, mode facile ou pas, il faut que les joueurs puissent apprendre votre jeu.
    Faites vos 2 - 3 premiers niveaux très gentils, avec pourquoi pas des endroits où ça monte mais pas partout et surtout pas au tout début, avec du challenge mais avec pour objectif que je joueur se familiarise le plus possible, s'amuse, dompte, avec le moins de punition possible (c'est chiant, et surtout c'est pas le but). Vous aurez tout le loisir de faire des choses progressivement très hardcore dans les niveaux d'après (3, 4, 5 etc.)

    Romain, developer of Splasher, also questioned the way ink is always (~) raising in SchoolRush. "Whatever the difficulty level, the player must be able to learn the game", he argues. "Let your first few level be very soft, maybe with some areas where the ink may raise, but definitely not right at the start. You may put some challenge in, but the goal must be that the player gets confident about the gameplay, has fun and is allowed to master [basic controls] without getting penalties for every bad move. You'll have plenty of levels to get slowly to a hardcore difficulty level"

    I must confess this is one of the tip he gave I had the hardest time to integrate into the gameplay. Because I only plan to have 4 + 1 levels in School Rush. The game is intended to be short, focused on simple gameplay of running forward under ink raise pressure. I have been tempted to select a trigger in every level where the ink would start raising while keeping the first two screens for some gameplay sandboxes. I think this can work provided that the player may "see" that something got triggered and the ink starts raising. I even made some sketches with gargoyles-like items in the background, but I couldn't get it to fit the desired storyline of the game -- that is, pendats have decided to flood the area to punish books for not following their leader, and Bilou tries to get to the ink source to turn it off before it is too late.


    En ayant pour objectif de faire uniquement 4+1 niveaux pour SchoolRush, je devais adapter le commentaire, évidemment. J'ai pensé par exemple à garder les quelques premiers écrans avec l'encre à l'arrêt avant de déclencher la montée. Pour que ça marche, il faut que le joueur puisse "voir" que l'encre se met en route ou s'arrête. J'ai fait quelques esquisses de têtes de crapauds qui laisseraient l'encre s'écouler hors de leur bouche, par exemple. Mais je n'arrive pas à relier ça avec l'histoire (les pendats cherchent à noyer le niveau)

    Puis j'ai réalisé que -- dans les 2 premiers tiers du niveau "School Rush", la montée de l'entre n'est pas vraiment importante (en mode normal), parce que si elle retire certaines structures destinées à servir de filet de sécurité aux novices, en revanche elle ne monte jamais assez haut pour mettre en danger le joueur qui reste au niveau du "sol officiel". Pourtant, ça ne se voit pas parce que au niveau des pixels, l'entièreté du sol est couvert.

    avant
    après
    Then I realised that in the first 2/3rd of the level 1 of School Rush, having the ink raising is irrelevant in "normal" mode, because it never gets its hitbox reaching Bilou as long as Bilou is on the level's main structures. The only thing that effectively becomes unusable are the safety nets meant for the "easy" difficulty level. But this is not what the player feels, because the ink effectively hides the main structures. I mean completely. I have to remember precisely the position and size of the holes to clear if I don't want to lose a life there.

    So all I need to do if I want to get a newbie-friendly 'normal' mode is to let the sprites depicting the ink shifted down by a few pixels so that I can get both the initial intent (let the player know, right from the start, that she's rushing against ink) and the new objective (once it turns obvious that the rise has come to an end, be able to freely explore game controls and mechanics).


    Il me 'suffit' donc de descendre un rien le niveau des images représentant l'encre animée pour rencontrer à la fois mon objectif initial (que le joueur sache dès le départ que, dans ce jeu, on court parce que l'encre monte) et le nouvel objectif (que le joueur ait un terrain d'entrainement pour se familiariser avec les contrôles et les règles du jeu).

    Il me manquera une possibilité d'avoir un terrain d'entrainement pour les power-ups, qui ne sont pas évidents à obtenir dans le premier niveau. Je crois qu'en retravaillant les modalités du niveau bonus, on doit pouvoir y remédier.

    I still lack a sandbox for trying the power-ups, as they aren't obvious to get in the first level. I hope to get that fixed through the bonus level you'll be able to unlock with the collectible letters.

    Friday, May 26, 2017

    SaturdayScreenshot

    Et voilà. J'ai un petit effet sympa pour attirer l'attention sur les boules bleues redonnant de l'énergie au joueur. Ça aura été un peu de chipotage pour intégrer les nouvelles animations dans les 4 niveaux existants, par contre. Pour la suite, il va vraiment falloir que je veille à ce qu'on puisse inclure les déclarations de bloc spécial de la même façon qu'on inclut les machines d'état pour les personnages.

    Demain, je pourrai mettre ça sur Twitter et participer au micro-évènement "postez un screenshot de votre jeu en cours de développement".

    Don't you love that blinking effect on the healing bonus ? Not as hypnotic as bouncing on a pink eraser, but i'm quite satisfied with the result. I'll have some work to do to allow such things be used in multiple levels without having to rely on manual copy-and-pasting across multiple script files.

    Wednesday, May 24, 2017

    Quelques détails

    à régler avant de refaire une release:

    • récupérer le dernier .spr avec les petites étoiles en jaune pour les lettres
    • ajouter un effet quand on récupère un point de vie
    • corriger la fin du niveau 1 et les pilliers du niveau 4 pour qu'il n'y ait pas des bouts de gommes au lieu des graphismes.
    • veiller à repasser en mode "jeu complet sans Inspector Widget"
    Mais au moins l'ensemble des niveaux reste jouable avec les niveaux d'encre ajustés.

    Sunday, May 21, 2017

    shell to cybook

    I got the z-list issue fixed. The error was what I suspected, but what is more interesting is that I have been able to write a test case that reproduced the bug systematically, and thus that demonstrate that the problem is gone with the fix.

    I had to change my approach for investigating that because I've been doing so much on-line activities these last days that my eyes started to "panic". So rather than staring at my laptop top understand the outcome of a test, I pushed it into a .html file that I could browse with my e-ink cybook.

    
    python -m SimpleHTTPServer 8000 &
    
    (echo "<html><body><pre>" ; 
      ./testme ; 
      echo "</pre></body></html>") > /tmp/html/out.html
    
    (echo "<html><body><pre>" ; 
      grep -h -C14 prepare libgeds/source/* 
        | sed -e 's:&:&amp;:g;' 
        | sed -e "s:<:\&lt;:g;" 
        | sed -e 's:>:\&gt;:g;' ; 
      echo "</pre></body></html>") > /tmp/html/code.html
    

    Bon, ça n'a pas été une semaine simple, mais j'ai réussi à pouvoir prouver que le bug d'affichage de Bilou est corrigé tout en reposant suffisamment mes yeux qui criaient "au secours" la semaine d'avant. J'ai notamment utilisé assez abondamment ma liseuse pour passer en revue les résultats des tests (puisque oui, j'ai choisi l'approche "test automatique plutôt que l'approche "debugging interactif raffiné", la faute aux yeux précédemment cités). Celà dit, je vais rester prudent et laisser les détails techniques uniquement en Anglais pour cette fois-ci. Dès que j'aurai compris pourquoi l'encre refuse de s'arrêter à la hauteur demandée, je pourrai faire une release améliorée de School Rush.

    The test itself is actually fairly simple conceptually: I just drag Bilou around in the level, back and forth, emulating the camera and the game logic after each displacement. As the camera moves through the level, some game objects freeze and unfreeze, recycling the hardware sprites, and inkjets use the top-layer sprites so that ink drops look to come from within it.

    On the first round, the bug did not happen, but I had programmed a "trap" to report what I thought to be the precondition to reproduce the bug (having the inkjet frozen while it had one hardware sprite at top priority). The test then showed me that this happened, but less often that I thought. Actually, it only happened with one inkjet near the end of the level.

    Then, I extended the test so that I would make an increased number of scrolls through the level. There I got the bug appearing systematically on one of the levels. I had to filter out some of the events reported during the scroll (I reported every change in the zlist's size as well as any arrival/departure of hardware sprites): inkjets throwing ink corresponding for instance to 4 correlated events. Making sure that the camera coordinates are reported (instead of Bilou's coordinate) helped as well.

    Monday, May 08, 2017

    Another Inspector Widget ?

    I have another instance of sprites disappearing and re-appearing in School Rush. It is likely something with the "pull part on top of every other sprite (aka. zlist[0]). I believe the issue happens when a modular sprite gets frozen while it had one of its component pulled to zlist[0], and then comes back to activity.

    It would be great to investigate those situations to have an alternate widget for the Inspector Window Something that would show the on-screen area, the "GPU-active area" around it (where hardware sprites are are still programmed to be shown), and the area where the objects are still active although their OAMs are all disabled to avoid display glitches.


    Bon, je tape un peu en vrac mes cogitations du week-end. Si je n'ai pas encore refait une release avec les améliorations de School Rush du mois dernier, c'est que je suis confronté à un retour des sprites-fantômes. Au départ, c'était juste dans la tour encrièrnale, mais ça se généralise à tout le jeu School Rush... J'ai ma petite idée sur la cause, mais j'aurais bien aimé en avoir la preuve avant de tenter une correction du code. Histoire d'être en mesure de montrer que c'est bien corrigé.

    L'ennui c'est que j'estime le rapport entre corriger et démontrer que c'est corrigé de 1 à 10 au minimum. Voire de 1 à 100. L'autre ennui, c'est que ni l'amélioration d'Inspector Widget (qui aurait de la gueule) ni l'écriture de cas de tests (qui serait en aveugle) ne me paraît préférable

    Ideally, it should be able to show "regular" and "pulled" sprites differently so that we can spot what state they are in and when. It should of course allow pausing and step-by-step processing to maximize our chances to reproduce the believed cause of the crash. Would that be enough ? should I rather try to have that investigated through "unit" testing ? I don't know yet.


    Monday, May 01, 2017

    MapAnim : done

    Once again, properly mapping the codebase before starting to program got a loong-delayed-feature added to the engine within an afternoon. The code was actually written bottom up, starting with the revision of the "clearblock" function up to the script parsing code. 

    I love so much the new little bounces and stars, I couldn't play the game without them anymore :P

    Et donc les voilà, ces petites étoiles qui accompagnent la disparition des bonus et cette gomme rebondissante que l'on me recommandait. Je vais bien vite me refaire une version de School Rush qui intègre tout ça, parce qu'on y prend terriblement vite goût ^_^

    Le nouveau système me permet aussi d'affiner un peu le comportement de la gomme rebondissante: elle ne projette plus Bilou immédiatement en l'air: au départ, elle n'est qu'un détecteur et devient un rebondisseur uniquement avec la première étape d'animation. Du coup, ça permet au joueur de mieux ajuster ses mouvement avec ce qui se passe dans le jeu (enfin, je trouve).

    Saturday, April 29, 2017

    Adding the MapAnim

     Allons-y donc pour l'ajout d'un nouveau type d'animations dans mon moteur de jeu: la modification du contenu de la map elle-même dans le temps. Jusqu'ici, c'était limité à "faire disparaître le bloc en (x,y)" ou "retire-lui ses propriétés, mais laisse-le visible" (pour les bonus cachés). ça peut marcher pour certaines choses, mais ça suppose que les éventuels effets liés à la disparition soient entièrement pris en charge par un sprite supplémentaire. Idéal si l'image doit quitter son emplacement (un morceau de pont qui tombe, un décompte des points qui monte, etc), celà dit.

    Let's have one more way of animating things in my game engine. One that would be suited to special blocks, and that update the map content at a specific location over time. The only thing I could do so far would be to shoot a sprite-manipulating game object and make the block disappear. That's mostly appealing if you want a picture to move away, like broken bricks, falling logs and the like. 
    The "BlockAnim", used to animate the ink, is not interactive and apply simultaneously to all the instances on screen. It can make SMW coins spin, but it cannot leave a trail of sprinkling sparkles behind.

    Now, let's resume the coding, I'll keep you updated on the outcome. I already love the animation I designed last night for the bouncing erasers ^_^.

    Il y avait aussi les "blockanims", qui permettraient par exemple de faire tourner les pièces de Super Mario World sur elles-même. On procède alors par une mise à jour de la mémoire "tiles" et toutes les instances de l'objet sont mises à jour simultanément sur l'image à l'écran.

    Le nouveau "MapAnim", lui, correspond plutôt aux besoins pour faire bouger un buisson devant lequel on passe, mettre des petites étoiles là où il y avait un bonus, etc. Comme vous pouvez le constater sur les diagrames, le mécanisme qui permet de mettre à jour le niveau (les données gérées par la classe InfiniMap) n'est pas particulièrement simple. Il met en jeu une description de chaque type de bloc spécial (les BlockInfos) et un objet temporaire capturant "tel bloc à tel endroit" (le BlockArea) qui permet d'interagir avec le personnage (GameObject) qui vient de passer par là. C'est finalement InfiniMap lui-même qui procède à l'effacement sur base du résultat du test de collision. La seule bonne nouvelle, c'est que c'est assez souple pour permettre des (petites) portes, des bonus, des bumpers et même les guides invisibles qui font faire demi-tour aux encriers.


    Koopa 3D

    Houlalaa... je retombe sur une vieille image de synthèse que j'avais réalisée dans moray/povray et présentée à la Inscene '99 ...

    Quand je vous dis que la 3D, ce n'est pas pour moi, c'est pas une blague, hein.

    Thursday, April 27, 2017

    pauvre Game Feel

    Je n'ai pas de définition de "Game Feel" à proposer. C'est juste un mot pour parler de ce qui fait que le jeu semble attrayant, divertissant. Les petits nuages de fumée de Rayman, les bananes qui s'envolent vers le compteur de DKC, la pièce d'or qui bondit hors des blocs-question dès Super Mario Bros sur NES...

    Toutes des choses dont mon School Rush est actuellement dépourvu, comme le faisait remarquer Romain Claude:

    Après le feeling avec le jeu c'est une tonne de choses à soigner : les réglages des paramètres physiques, les animations, tous les petits détails de feedback à droite à gauche qui rendent le tout "rewardant" et jouissif. Pour le moment le jeu est assez dépourvu de tout ça. Les gommes rebondissantes par exemple, si elles étaient animées cela rendrait le rebond plus satisfaisant et plus clair sur le fait que cet objet réagit.
    Et qui est repris également sur le forum "e-magination", même rien qu'en regardant les images d'accroche:
    Ce serait chouette que les bonus affichent un petit effet quand on les récupère, selon moi, ce serait moins "tristoune"
     J'y ajouterais bien un peu de secousse de caméra quand on donne un coup de poing au sol, si jeu peux.

    It seems like people have dedicated the words "game feel" for all those little details that make a videogame feel more alive and reacting to player's actions. Dust clouds, sparkles, bananas flying towards their counter and things alike. It is becoming a recurring comment on current School Rush that I lack such little animations that should provide important feedback and make the player smile. 

    Unfortunately, I have considered them as unimportant for most of the development and I'm now near the limits of the current game engine, especially when it comes to new graphics for the sprites. Both eraser-bumpers and disappearing bonuses will thus have to be implemented that patching the tilemap according to some animation commands ... something for which I haven't got code for. So far, the closest I had was pushing new graphics into the sprite/tilesets, which animates all the instances simultaneously.

    Pour les bonus et les gommes animées, par contre, ça demande d'ajouter au map elle-même (et pas le remplacement des images du tileset comme c'est le cas pour les animations non-interactives : l'encre, les pommes qui se balancent dans la Green Zone, etc). J'avais pensé un temps m'en sortir avec un sprite temporaire, mais ma planche de sprite est trop remplie pour que ça puisse passer.
    Je vais donc devoir rajouter au moteur de jeu un composant que j'ai retardé depuis probablement trop longtemps: l'animation d'un objet par manipulation du contenu de la map elle-même.

    Tuesday, April 25, 2017

    Rushed difficulty selector ?

    It took me about one year to realise that my difficulty selection interface on the main menu of School Rush had a flaw. It perfectly moves the cursor up and down with the DPAD, but it will only register the difficulty selection and apply it in-game if you used the stylus to perform your selection. Pretty annoying. Now I understand better why people considered the game a bit too hard ^^"

    Aargh! Quelle horreur. Je me retrouve avec une interface incohérente pour le choix de la difficulté de School Rush! et depuis près d'un an sans m'en être rendu compte jusque là !? Tout fonctionne si on choisit son niveau de difficulté au stylet (chose plutôt rare, convenez-en) mais si on utilise les direction "haut" ou "bas" du DPAD, on reste en fait bloqué en mode "normal" ...

    Vive les revues de code >_<

    Monday, April 24, 2017

    Round 2 (P.Y. vs. PypeBros)

    Allez, je prends une petite demie-heure pour répertorier les questions et les posts qui me viennent en tête quand j'écoute la deuxième partie de l'interview avec P-Y.

    01% - faire le jeu auquel on rêve de jouer ? 00:20 - another world - prince of persia - titus - rayman
    15% - priorité au plaisir de créer ? 03:13
            - rpg essentialiste
    30% - l'évolution dans le rpg ? 06:20 - (mario rpg) (modding/remake de keen)
    40% - juste un niveau ? construct 2 ? 08:20 - (badman2/3) - quel je choisir ?
    50% - les jeux homebrew (portage/demo/jeu simple-mais-complet) 10:45 - un seul niveau (bilou basic) - l'anniversaire - façon pacman : apple assault
    80% - le curseur de difficulté 16:43 - rien que normal - easy-normal-hard dans keen

    Somethen, I met a phd student who's interested in understanding why people make video games on their spare time. This is part 2 of 3 of an interview, in French, addressing mostly "are you making for making or making for players" and "how about people that are fine with one-level demos ?".

    Wednesday, April 19, 2017

    Augmentons la Gravité ?

    J'ai eu l'honneur (et un peu la chance, il faut l'avouer) d'avoir un retour de Romain Claude -- dévelopeur principal de Splashers sur mon School Rush. Un feedback assez technique et qui ne sera pas facile à prendre en compte, parce qu'on s'attaque ici au coeur du gameplay.

    Mon principal retour pour le moment concerne la prise en main, que je trouve assez raide. De plus, le fait que le jeu soit assez mou rend le tout assez hardcore, même en facile ... Côté contrôles vous devriez avoir un air control progressif (de moins souple à beaucoup plus souple), et ceci marié à une gravité plus forte rendra la prise en main plus réactive et agréable. Par contre pour retrouver la même hauteur de saut il faudra augmenter la valeur de l'impulsion.

    I'm honoured and proud that Romain, main designer of the platformer "Splasher" took the time to try and give detailed and technical comment on my own "School Rush". In the upcoming weeks, I'll likely be busy understanding the implications of his proposals and doing attempts to adjust the gameplay of SchoolRush accordingly.

    The first suggestion is to increase the gravity to get more a reactive experience -- which echoes a comment from Kirby Kid in a previous iteration. That's not something to be taken lightly, though. Many things in the game depends on the gravity. Changing it by a ration g'/g means that you have to modify the jump impulse v1 so that the maximum height of the jump -- v1²/2g -- remains constant. But even so, the amount of time you stay in the air is reduced due to the increased gravity, meaning that the distance you can clear with a jump is shortened.

    Mais changer la gravité, c'est changer beaucoup de chose. En plus d'ajuster la puissance de l'impulsion, je dois aussi ajuster la vitesse de déplacement de Bilou puisque le temps qu'il passe en l'air, lui a été réduit. Sans celà, il faudrait revoir tous les obstacles du jeu.

    En fait, une fois tous les paramètres dépendants de la gravité réajustés, on a le même jeu mais avec le temps accéléré. Ce n'est pas déplaisant, mais ça va demander aux joueurs d'être plus alerte, parce que du coup, je vais devoir aussi augmenter la vitesse de l'encre sans ça elle est complètement à la traine. Peut-être devrai-je aussi accélérer les pendats...

    By increasing the walking and the jumping speed of Bilou with the appropriate factor, I can keep the levels unchanged and enjoy a more engaging gameplay. I'll have to speed up the rise of the ink: at the moment, the game has turned too easy and I might also have to speed up pendats, so that Bilou don't outrun them too easily, which will shrink the response time allowed to the player (to 86% of the current value for g'/g=4/3) ... but it still leaves 500ms+ to react, so that should work.

    http://critical-gaming.squarespace.com/blog/2011/1/5/super-meat-boy-pt1.html
    J'essaierai celà dit d'éviter "l'effet Meat Boy" si je le peux, à savoir d'avoir le contrôle en l'air tellement élevé que l'on finit par "glisser" dans l'air et se déplacer plus vite horizontalement que verticalement. Mais en ajustant la vitesse horizontale maximale, il devrait y avoir moyen d'éviter ça.

    Directly linked to the change of gravity, Romain suggests progressive air control. The current code controlling Bilou has some momentum while mid-air with an acceleration that is 1/2 of the one you have on the ground.

    In his interview about Splasher, Romain says:
    Air control is a touchy subject: you need sufficient control so that player can compensate for an imperfect impulse (imperfect timing or speed) while still having an interesting skill floor, but not give too strong air control, else the player will [go wild at uncontrolled speed] at the slightest move of the joystick.
    To balance things in Splashers, Romain used delays, so that the air control just after the impulse is not as strong as it is some frames later.
    This happens in Super Meat Boy too, with a character that initially struggles to work against its original impulse, but that gets increasing amplitude as you maintain the joystick pushed into one direction. To be honest, Super Meat Boy isn't one of my reference in terms of gameplay. I would even consider it as a counter-example of convincing physics

    Dans le "School Rush" actuel, j'ai un système qui encourage le joueur à prendre le temps de courir avant de sauter: une fois en l'air, on peut ralentir et faire demi-tour (Bilou reste tout de même un explorateur de l'espace, ça offre quelques mouvements inaccessibles aux simples humains), mais on ne pourra jamais atteindre à nouveau la vitesse maximale avant d'avoir touché le sol pour courir à nouveau.

    Ma première tentative pour m'approcher du "contrôle de plus en plus souple" (que je traduis par "augmentation linéaire de l'accélération horizontale avec le temps passé en l'air") consistait simplement à autoriser une vitesse horizontale plus grande en phase descendante par rapport à la phase ascendante. Mais ça, ça n'a pas été un succès.