Testing & Refactoring

Astrocruiser needs some refactoring

Pas beaucoup de nouvelles côté développement du jeu. Parce que je veux mettre en place un système capable de tester de manière systématique les éditeurs en plus du moteur de jeu. Les makefiles pour la recompilation mieux organisées, c'est fait, je m'attaque maintenant à la structure même des programmes, sortir ce qu'il reste de logique de la partie du code qui dépend directement des interactions avec les boutons... l'idée d'un "sprdo" où on pourrait indiquer une série d'opération élémentaires représentant un scénario d'édition du genre "load spritea.spr, page 3, block 8, store.block 9, save spritea-edit.spr"

I guess Bilou doesn't find it so funny that the engine and the tools need to be deep-checked. I started with revision of the build system -- and that's almost handled. Now I've started to migrate whatever is not GUI-handling out of the *Window class (into corresponding *Model classes, if you ask) so that I can more easily emulate some use cases...

Le journal de Link: Cocorico: Sheik. Et après

 Cher  Journal,

Bon, je veux bien : j'ai passé 7 années en-dehors du temps après avoir fait la plus grosse boulette de ma vie, à savoir laisser entrer ganon dans le temple du temps. J'ai une super-épée donc je vais pouvoir arranger ça. Y'a une fille (?) bizarre qui me tuyaute avant même que j'aie pu faire un pas dehors "va au village cocorico, sans ça, tu ne pourras même pas entrer dans le premier temple". On y va: 'faut être gentil avec les filles.

Pour trouver quoi ? Des gens qui vivotent, qui se fichent pas mal de ce qui se passe dehors et qui n'ont pas l'air d'avoir la moindre idée de ce qu'on m'a envoyé chercher ici. Je reçois un oeuf-cocote ... je réveille un type qui sombre dans la dépression qui me fait un appel gros comme l'arbre Mojo d'aller voir comment va sa fille dans son ancien ranch. Pas l'ombre d'un autre indice... Enfin, à part le vieux Merlin qui délire à propos d'un gars qui savait voir la Vérité et qu'on a construit le puits là où il y avait sa maison et le type du moulin qui insiste sur le fait que là, maintenant, c'est bon: son moulin a bien asséché le puits. Sauf qu'on fond du puits, il n'y a rien qu'un éboulement de rochers si serrés que même une bombe n'en vient pas à bout.

Bon ...

Allons au ranch, alors. C'est qu'il n'y avait rien d'autre à faire, j'imagine. Sauf qu'au ranch, la fille s'isole dans un monologue répétitif. J'ai même pas pu lui placer que j'ai vu son père et quand je lui joue la mélodie des chevaux qu'elle prétend avoir oublié, elle m'ignore superbement.

On peut monter les chevaux, aussi. Ça c'est nouveau. Par contre, invariablement le mec m'interrompt et me flanque dehors au bout d'une minute.

Et ça ne fait pas d'avantage d'effet au vieux père déprimé d'aller lui parler de sa fille, non plus.

Tant pis, essayons le fameux temple de la forêt. Il est au bout des bois perdus, d'accord. Et il suffit de suivre la musique de Saria pour le trouver. Enfin, ça devrait, mais ça ne marche pas vu que Saria, elle ne joue plus. Je dois y aller à l'aveuglette... j'aurais du prendre un cahier à spirale avec moi pour me faire une carte, tiens: c'est pas Navi qui va m'aider: elle fait une fixette sur le village de cocorico. Même quand j'y suis, elle me dit qu'on doit y aller.

Bref, je peux aller où je veux, j'ai zéro équipement juste mon sac de bombes et mon épée qui ne sert pas à grand chose vu qu'il n'y pas de monstres dans la plaine d'Hyrule ... Mais me filer un tuyau sur ce que voulait cette tarée de Sheika. ça. bernique.

J'ai poussé une tête jusque chez les Gorons pour m'acheter une jolie tunique rouge qu'ils ne voulaient pas me vendre quand j'avais 12 ans sous prétexte que j'étais trop petit, mais il n'y a plus personne là-bas non plus.

I'm a bit disappointed by Zelda: Occarina of Time's shift from childhood to late-teenage at the temple of time. I should feel like I can explore much more, but I actually feel lost in a world where I miss my reference points and where all the friends who could explain me what to do next have been relocated somewhere else on the map, and none of the actions I could think of to progress is possible. 

I'd like to get the feedback of those who remember having played OOT for the first time. How did you figured out what to do when getting out of the Temple of Time as a grown up and realised that noone Kakariko village seemed to know anything about why Sheik of the Sheika sent you there ?

La guerre des Mascottes

Ça y est : j'ai enfin reçu mon tome 2 de l'Histoire de Mario. Chiffre de ventes à l'appui, William Audureau et Oscar Lemaire passent au tamis les années sabbatiques du plombier, à savoir la période de 1990 (lancement de Super Mario World) à Juin 1996 (fin du développement de Mario 64). Je dis "années sabbatiques" puisqu'entre les deux, les amateurs de fleurs de feu n'auront que Mario Land II à se mettre sous la dent.

C'est pourtant l'époque où tous vont tenter l'aventure de la plate-forme dans le sillage de celui qui tente de faire vaciller l'idole, à savoir Sonic (1991). Bien sûr, il y aura eu d'autres jeux de plate-forme avant et il y en aura d'autre après, mais durant cette période, ils représenteront le gros des ventes de jeu sur console.

Chose peu surprenante, c'est avec la sortie de Sonic que coïncidera l'envie de faire mon propre jeu de plate-forme avec d'abord Calimero de '91 à '93 puis avec Bilou sous Basic entre '94 et '96.

Pendant ce temps, à peu près tous les détenteurs de personnages enfantin forts vont cesser d'"ignorer" le jeu vidéo et attaquer le dangereux Mario sur son terrain : celui du jeu de plate-forme. Ce sera "castle of illusion" avec Mickey, "duck tales" puis les jeux Infogrames qui ratissent autant de personnages de bande-dessinée francophone que possible mais aussi le bestiaire de la bande à Bugs Bunny -- avec plus ou moins de succès. En réaction, les acteurs du jeu vidéo vont aussi miser gros sur les personnages d'animaux antropomorphiques ayant le potentiel de devenir des mascottes, comme le Mr. Nutz de Philippe Dessoly chez Ocean, la chauve-souris acrobatique chez Sun Soft et le controversé Bubsy chez Accolade (que je ne connaissais jusque là que sur PC pour ses simulateurs de course)... et bien d'autres encore qui n'auront atteint ni l'émission Luna Park ni les planches de Midam. Même les robots de combats spatiaux prennent des allures de braves mascottes et tentent de se faire passer pour des abeilles avec des noms comme "twinnbee".

Oh, well. There's been another book by William Audureau, joint by Oscar Lemaire, about years '91-'95 where platformer was the king of video games, and where it looked like everyone could come with a mascot-like hero that would be the next Sonic since Mario was Missing... So I've been reading and reading. And no code has progressed. More luck next week ?

De notre côtés de jeunes ados, on fait la chasse aux magazines, on rève à ce que peut bien être tel ou tel jeu avec un personnage plus ou moins probable. Il semble qu'il y ait un nouveau venu tous les trimestres. Dans quelques rares cas, on aura l'occasion de s'y essayer mais le monde du PC est tristement dépourvu de ce genre d'exotisme. Au mieux, ce sera James Pond II sur Amiga à la maxithèque, ou la surprise de découvrir Moktar reconverti en Titus the Fox. Ils ne sont pas tous des sonic-like tels que Zool, mais ils cherchent clairement à plaire au même public. Et il semble bien que le succès de Sonic décomplexe tous ceux qui hésitaient jusque là à faire des chat-tout-mignons comme personnages de jeu: il suffit de leur coller un élément vestimentaire de jeune, une attitude cool-et-frondeuse, et en avant. Sur micro, on le prendra avec une dose de dérision, et j'ajouterais bien "Super Frog" (PC, Amiga) à Jazz Jackrabbit & James Pond ... mais le plus souvent, on avait droit à un gros raté du genre "Skunny the Wild West".

Le tandem William-Oscar gratte donc derrière les couvertures de magazines et effectue un impressionnant travail pour rassembler les interviews, les mettre en contexte ... Car si l'un va titrer "la nouvelle mascotte de XXX", ce n'est pas nécessairement l'avis de la société qui l'aura publié, ni du studio qui l'aura créé. Et si les personnages humains (Commander Keen ? Duke Nukem ?) sont assez peu présent dans l'analyse, les "héros/mascottes" improbables tels que Plok ou Cool Spot eux, ne sont pas oubliés.

Il met aussi en perspective les travaux de l'équipe de Miyamoto -- qui n'est évidemment pas restée les bras croisés pendant 5 ans -- qui sans parvenir à donner un deuxième jeu où l'on saute vers des blocs-questions à la SuperNES va se frotter à toutes les technologies de pré-3D afin d'avoir le meilleur Mario 64 possible quand sera enfin prête la console 3D de nintendo.

Il y aura finalement peu de suites parmi les "héros fabriqués spécialement pour l'occasion" ... et aucun ne parviendra à survivre à l'environnement des 16-bits où il a vu le jour, que ce soit pour des raisons de fusion/acquisition/license, par incompatibilité technique entre la vue 3D et les mouvements du jeu de plate-forme, ou simplement parce que les artistes d'animations qui donnaient vie aux personnages se retrouvent privés de tout repère devant les logiciels de modélisations polygonales.

Vous l'aurez compris, même s'il y avait beaucoup moins de matière pour le game-designer-amateur que je suis, le livre m'a malgré tout tenu en haleine. Bon, évidemment, avec tout ça, le travail sur l'amélioration de SEDS et LEDS, mes éditeurs de jeu sous DS, n'ont pas beaucoup avancé ^^".

Plummet (2)

Et si le fait d'avoir une plume changeait fondamentalement l'humeur des encriers de la School Zone ? Au point qu'il ne leur vienne même plus à l'esprit de lancer des gouttes d'encre.
Et si ces plumes, Bilou pouvait les transporter d'un encrier à l'autre profitant d'un vol plané d'encrier à encrier.

Techniquement, ce ne sera pas pour School Rush, mais j'aime bien l'idée...

The recent chat about techniques that could extend the number of sprites the GEDS engine could support on the DS opened some new paths and led me to funny ideas such as "what if Bilou could use quills to move from one inkjet to the next one ?" and then "how would an inkjet feel (and look) when he's got a quill in ?".

That might not reshape the SchoolRush game, but I love how it turned out

revising build system

Once upon a commit, was runME, a tool to assist game development on NintendoDS by embedding a game engine, WiFi transfer functions and launch buttons to sprite, level and animation editors. Revising a level should have been as simple as click "LEDS", update the area that wasn't suited to the gameplay, "save and play" to return to runME that would allow you to run the game with its new layout. Editing monster's behaviour should have involved at most a similar trip to SEDS and uploading some revised scripts from a laptop PC.

Nothing like that still occur with SchoolRush. The code layout and the build system makes it extremely tedious to maintain identical feature set for the game's own binary and runME. Slight differences between the two means the game will not play as expected and even will even fail to run on runME because some 'plugin' controllers (the C++ toolkit to build game state machines) expect different arguments. RunME is almost exclusively used to beam .spr and .map files out of the DS to be tested in emulator on the integrated game binary and them beam back the .nds into the DS after some preliminary tests were made on emulator. That's likely the slowest development cycle you could think of :(

Un jeu est sorti. Je m'autorise donc à prendre un peu de temps pour faire de la maintenance dans du code qui en a bien besoin. En particulier le système de gestion des compilations. Ce ne sera pas aussi élégant que ce qu'on a construit au boulot avec mes collègues, mais je reprends quand-même quelques idées... J'élimine les VPATH, notamment. Je regroupe ce qui peut l'être dans un 'common.mk' inclus depuis le makefile de chaque projet, etc.

J'espère que ça me permettra de recommencer à faire de l'exécution dans runME quelque-chose de plus fiable, de façon à pouvoir tester un niveau gribouillé sur DS sans devoir le re-passer par le PC.

I'm on a quest to make it better, drawing experience from the buildroot-derivative project we're dealing with at work. I have hope it will also ease the task of writing unit-tests for LEDS and SEDS that will make them more reliable tools: I've got way too many instances of "data recovery" in the last edits of School Rush.

Maybe I'll have to push myself to avoid re-inventing a "dlod" systems for the plugins and accept that a static library and proper re-compiling statements is all I need: a first intermediate build of "plugins.a" allows me to look at all the things that the bunch of controllers need from the environment to do their job. If I was able to offer that via in-runME patching, I could just upload a new "ppplatformer.bin" to the NDS and have runme work with the update functions. Admittedly, beaming a new runme is simpler and does the job.


[edit] J'aurais pu suivre une alternative intéressante: celle des modules Linux. Dans ce cas-là, c'est l'équivalent de mon "common.mk" qui est fourni à make, et l'emplacement du module à compiler est passé en ligne de commande avec un M=. Du coup, les "raccourcis usuels" qui donnent presque l'impression qu'on a affaire à un dialecte de makefile sont encore plus transparents. Un inconvénient pour un projet dont la base d'utilisateur est plus réduite, peut-être ?

make -p et LevelEditor.elf

Bon, moins drôle. En voulant tester une variante de LevelEditor qui ne conserverait que les personnages effectivement sur la map, je me rends compte que LEDS ne compile plus. En fait, SEDS et AnimEDS non plus: j'ai oublié de vérifier que mes modifications du game engine ne "cassait" pas les éditeurs ^^". Heureusement qu'au boulot, j'ai des "buildbots" pour m'éviter ce genre de mésaventures.

Allow me to be much more technical, please. I have some build system issues with the editors. Somehow, I forgot to maintain them as I was upgrading the core library for the game engine library, and some parts of the engine are shared with the editors. Although I don't have build bots setup for this project, I can use some makefile-debugging techniques I developed working on buildroot-based project. The #1 trick being the existence of '-p' flag for GNU make, that let you review every single variable and rule instantiation and understand what goes wrong much faster than by adding echo commands here and there.

Heureusement aussi, j'ai découvert l'année dernière l'existence du flag "-p" pour GNU make, qui nous fait un dump de l'ensemble des variables internes du makefile, avec en prime la ligne de makefile qui a défini cette variable. De quoi retrouver sans trop de difficulté que les options pour générer la "map" au moment du link sont erronées, et de rajouter un "--cref" histoire d'en apprendre un peu plus.

The core issue I'm facing is that LEDS is now trying to include the core part of the game engine, that parses scripts and does game object updates frame by frame. Clearly, it's not required for the editors. And the editors are not ready to include it, because they don't provide details on the kind of game they are. As soon as 'make -p' allowed me to locate where to define additional flags for the linker and what the current flags are, I can enable the creation of a linking map, that will indicate which symbol triggered inclusion of GameScript.o and in which source file of the level editor it was invoked.

Oui, parce que le problème que je rencontre ici, c'est que tout d'un coup l'éditeur de niveau s'est mis à avoir besoin de la quasi-totalité du moteur de jeu. Qui en retour a besoin qu'on lui indique comment marche le jeu.

Reste à découvrir pourquoi "level.o" s'est mis à faire référence à ce AllocContext::active qui a "attiré" le parseur de GameScript à l'intérieur de l'éditeur de niveau ... ça, c'est un job pour GCC avec son flag -E (pour "fais juste le pre-processing et arrête-toi"). Pour ça, j'ai ré-injecter dans ds_rules du "devkitarm" une technique découverte ce matin dans buildroot: plutôt que d'utiliser directement '@' (oui, oui, comme dans les autoexec.bat ;) pour masquer l'appel d'une commande pour ne pas surcharger la console du développeur, on utilise '$Q ' avec 'Q ?= @'. Il suffit alors d'appeler 'make Q= ' pour avoir l'information complète, voire de ne définir la valeur par défaut de Q que si V n'a pas encore de valeur, ce qui permet un 'make V=1' pour '--verbose' bien plus facile à mémoriser. Je peux alors voir la commande exacte de compilation du fichier "level.cpp" et en introduire une variante avec mon fameux flag -E.

The last step is to understand why this "AllocContext" variable (it turned out not to be a function) is used. My best move for that is to capture the exact command that compile level.cpp and replay it with the '-E' flag that only goes through pre-processing and dump the result. I can then see the same thing as the compiler sees, search through it in a single pass. Once it's done and understood, it's merely a matter of moving those static variables into their own compilation unit, so that the linker can pick AllocContextDefault.o to satisfy level.o's needs without pulling the whole game engine along.

Et voici le chaînon manquant: un script est devenu un contexte d'allocation, et la définition du contexte d'allocation se trouve dans GameScript. Un petit déplacement de la variable "active", et ce sera réglé.

LivingStone, I presume

Les ennemis de Rayman, sur PSX étaient assez évolués dans leur comportement. Les "livingstone" par exemple -- existant en deux tailles -- ne se contentent pas de patrouiller sur leur plate-forme: le grand livingstone peut faire des pauses pour ajuster son casque, fuir effrayé ou se faire assommer d'un coup de prune.

Le petit "teigneux" lui, peut se mettre à pourchasser rayman, mains en avant, tenter de l'aggriper à distance et s'abaisser pour se mettre hors de portée de nos coups de poings. Pas encore exactement un personnage de Street Fighter, mais nettement plus sophistiqué qu'un goomba.

Ennemies in Rayman PSX were fairly sophisticated in their behaviour. The Livingstones -- one of the first monster you encouter -- not only patrol on their platform. They pause here and there, they can be frightened or stunned with bouncing fruits. Then you have the smaller living stone, detecting Rayman's presence, chasing him, or attacking with its hands. It is not yet as complex as a Street Fighter encounter, but not quite your average goomba either. 

J'étais donc assez surpris de constater que les "lividstone" de Rayman Origins sont fondamentalement statiques, occupant sans avancer (ni même se retourner ?) une plate-forme unique. Certains ont un bâton en main, d'autre une balle. Mais d'un point de vue "gameplay", ça ne change rien: ils se contentent d'attendre Rayman. Ils sont assez comparable à des blocs à pics sur lesquels ont peut sauter et qu'on peut casser. Enfin presque: une fois touchés, on peut se servir de leur "bulle" pour aller plus haut, encore que je n'ai pas encore vu beaucoup d'endroit dans les niveaux où cet élément est développé.

Comparatively, I was shocked to see Lividstones of Rayman: Origins almost static, standing on their platform wiht no additional move, not trying to hit rayman with their stick when they have one... just waiting to get smacked. They're functionally equivalent to spiky blocks that you could break with a punch. The "why" is pretty clear: make the game easier. What puzzles me is "how does it come it works? Why haven't I got any feeling of core gameplay being lost ?"

Que s'est-il passé, donc ? Pourquoi cette simplification à l'extrême et surtout où est la "compensation" dans le reste du gameplay qui fait que cette simplification n'a pas d'impact négatif sur l'intérêt du jeu ?

Dans "l'histoire de Rayman", on nous présente la méthode Hascoët qui répartit les challenge contenus dans les niveaux en quatre catégories:

• Rapidité: aller plus vite que la lave, grimper plus vite que l'eau, suivre un scrolling imposé, être parti d'un nuage avant qu'il ne disparaisse ... d'une fleur avant qu'elle ne se fanne... Bref, tout ce qui incite le joueur à rester en mouvement. Dans Rayman Origin, ce rôle est essentiellement joué par le "roi des lums" (score doublé temporairement) et par les bonus-en-bulle dont on ne saura profiter que si on arrive assez vite dessus. Mais il y aura aussi des pans entiers de montagne qui s'abaissent et mettent le joueur trop lambin en danger.
• Astuce: tout ce qui demande au joueur de réfléchir un peu pour résoudre un problème, comme le coup de la prune sur la tête du livingstone, ou parvenir à lui mettre un coup malgré ses stratégies d'évasion. Dans "Origins", l'astuce est souvent secondaire, mais les développeurs ont prévu de nombreuses situations où les plantes-interrupteur font apparaître ou disparaître des plate-formes ou des yeux-à-pointe. On peut ainsi à distance précipiter les lividstone vers leur défaite, les prenant à leur propre jeu. Bien rigolo à faire, en tout cas. Faute d'une récompense intégrée au jeu, on est récompensé par un sentiment de supériorité sur ces mécréants pathétiques.

• Précision: sauter/frapper pour atteindre un endroit en hauteur, ce sera l'élément principal dans Rayman PSX. Rayman Origins monte fortement les exigences ici, en particulière avec les défis des "pièces de la mort" qui demande des sauts et des rebonds impeccables. Je suis aussi tenté de penser que les nuances possibles que dans Rayman PSX, ne serait-ce parce qu'il y a plus d'inertie dans la course du personnage. En plus, ça n'aura échappé à personne, Rayman peut maintenant rebondir sur les têtes des ennemis, et on a droit à plusieurs constructions dans les niveaux ou on joue au parakoopa en rebondissant d'ennemi en ennemi pour les éliminer tous.
• Synchronisation: passer au bon moment ou frapper au bon moment. C'est peut-être un des éléments qui est en retrait, en tout cas dans les premiers mondes, encore qu'il reste quelques plate-formes mobiles pour aller récupérer des pièces de la mort, justement.