Gob3D

There are some items in the school zone that would better be done with 3D objects. This is not quite new, but if I intend to have them in Dreamlands, likely it is time to consider them more seriously. At least, to identify the questions to be addressed.

• How do we define hitboxes for a rotating 3D object ?
• How do we define events that trigger when a given angle is reached ? (e.g. for state machine transition)

Je me suis laissé quelques petites notes pour quand il sera temps d'essayer de faire des objets 3D un peu plus ambitieux que les élastiques de SpongeBop pour Dreamland. Notamment des livres qui tombent et des lattes qui tournent ... Chacun d'eux ouvrant la porte à au moins tout un niveau dans mon carnet bleu.

Il faudra que je trouve le bon moyen de lier des zones de collisions aux objets 3D, pour commencer. Puis il faudra que je vérifie que j'ai bien compris comment marchaient les "display lists" pour la NDS ... Et accessoirement, faire une petite estimation du nombre "d'écrans" que compterait la school zone de DreamLands avec et sans les objets 3D, vu que pour la green zone, je suis déjà bon avec 2 niveaux ancestraux :-P

For the objects being considered here, it might be enough if rotations always happen around the origin of the model. A smashing book always rotates around its bottom line (X position irrelevant). A bridge book, around the middle of its bottom line (Z position irrelevant). A ruler bridge around its center of mass (Y position of the origin irrelevant). Sure, this does not capture all the possible things you might want to do with a 3D object in a 2D game, but it seems to be a sufficient start to me.

Now, last time I toyed with the idea of doing more than ropes in 3D, I ended up with the issue that anything that isn't hard-coded would have to use "glCallList", but I couldn't figure out how that would work. At last, I studied the registers used to control the 3D geometry engine (which turn out to match the gl* function almost 1:1) and noted that there are "command identifiers" associated with every 3D register. A call list is essentially a set of values to be written to GFX_FIFO. Writing to GFX_BEGIN (in order to implement glBegin) would be replaced by writing the command identifier for "begin vertex list", etc.

I could use a tool to craft these and adjust their parameters so that things look properly shaped.

edit: avec le "niveau de Rémi" et le niveau-anniversaire, je suis déjà à 36 écrans (contre 30 pour le 2eme monde de Kirby's Dreamland). Il y a au mieux 6 écrans à prendre dans le niveau avec tous les livres qui tombent et 2 à 3 fois autant à aller chercher dans les niveaux sans ces livres (mais avec quand-même quelque chose comme des lattes qui tournent et des bookmarks qui pendent). Je dirais que le plus raisonnable, c'est de garder les livres-3D pour un autre jeu.

Over-engineered ?

Maybe I'm starting that "swim made fun" thing by the wrong end. What I really need is to be able to move Bilou through water and to get him out of the water. Sure it is fun to swim in Rayman Origins, it was pleasant in DKC and a nightmare in TNMT on NES. But unlike all these games, I have no "water level" planned in Bilou: Dreamlands. The reason why I started working on dash-in-water is not because travelling through water would feel empty without it. It isn't even because I have level sketches where jumping out of water is a key mechanics. It is solely because in the current demo, you can't reach the green room exit unless you trigger an unintended double-jump with precise button mashing that should be left to speedrunners.

J'avais donc un beau projet pour les mouvements dans l'eau. Je venais de commencer à ajouter "on accélère si on appuie sur JUMP" et J.L.N a pris "la manette" en main. Il a nagé à droite. Il a nagé à gauche, puis il a voulu sortir de l'eau. Et bien sûr, lui n'a pas attendu que Bilou revienne à l'état "je patauge en attendant" avant de presser le bouton de saut: il l'a fait depuis l'état "bilou nage à gauche", là où j'avais prévu un "fonce dans l'eau vers la gauche" en réaction au bouton "pied"... Bilou n'a donc même pas tenté de s'élever d'un pixel. J'avais échoué le test n°1 de Miyamoto: "the JUMP button makes Jumpman jump". Et donc je me suis enfin posé la bonne question: "Est-ce que j'ai vraiment besoin de tout ça, moi?"

Parce que dans mon cahier bleu, avec les croquis de level design que j'ai l'intention d'utiliser pour Bilou's Dreamland, l'eau est bien présente, mais je n'ai jamais un "niveau aquatique" à proprement parler. Ce qui motive cette recherche sur les mouvements dans l'eau, c'est juste le fait que la berge est trop haute dans la démo. Et donc, garder une mécanique simple "JUMP" à la surface = sauter hors de l'eau et sauter hors de l'eau près de la berge = sortir de l'eau serait impeccable si j'éditais un rien l'écran-démo pour que sa berge soit un tile plus bas ^^" (et éventuellement que j'augmente de 15% la hauteur du saut depuis l'eau, actuellement défini au doigt mouillé)  

I wanted to use the opportunity of changing the level map to also fix an issue I had with the interaction of surface-swimming and following the water flow. I presume that the core of the issue is that the *middle* of the character's bounding box is used to determine whether there's a flow to follow. But "stay at the surface" code maintains Bilou above the flowing tiles. As soon as one pixel of the box enters the "full water, flowing downwards" tile, it starts pushing Bilou upwards.

I made a few bad moves, like trying to have full-water-flow-downwards tiles higher (closer to the surface), but that didn't work at all. Instructing the level that "water-flowing-downwards" can be felt through did work pretty well, I think.

Pendant que je testais cette nouvelle map avec sa nouvelle "berge" moins haute, je me suis rendu compte que depuis qu'on sait nager à gauche et à droite, les remous de la cascade ne nous entrainent plus vers le fond. La flottaison est trop efficace et le centre de Bilou n'entre plus dans la zone qui le tire vers le bas. J'ai un peu chipoté, mais heureusement, il suffisait de permettre à Bilou de "tomber" aussi dans cette zone pour que tout rentre dans l'ordre (enfin, je pense)

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 ?

Tout vient d'la cache

Quand Eric parlait de faire des mises à jour à la volée de la mémoire au fil de l'animation des sprites, je pensais spontanément à un système semblable à celui de Donkey Kong Country: chaque personnage se voit attribué un emplacement en VRAM et les mises à jours pour ce personnage-là viennent systématiquement à l'emplacement alloué à l'apparition du personnage. Du coup, s'il y a deux "kritters" en même temps à l'écran, il n'y aura aucun partage entre eux: le nombre d'objets à l'écran devient fortement contraint, même s'il y a peu d'images indépendantes, comme dans le cas d'Apple Assault.

In my first attempt to understand Eric Zmiro's animation engine I thought the video memory would be managed somehow similarly to what happens in DKC on SNES: every new object on screen would receive a chunk of video memory large enough for the most complex frame it has to render and it would update its content during the vertical synchronization timeslice (or at some other time slice when the GPU isn't busy looking up those pixels). To some extent, the DKC engine would be an auwfully bad choice to implement a game such as Apple Assault, where there are a large number of similar ennemies on screen and high probability that a single block of VRAM is in use by multiple ennemies at the same time. That was failing to include the key ingredient in Zmiro's engine.

J'avais oublié un élément essentiel des moteurs de jeu à la sauce Zmiro:

Chez moi, tout est en cache : Fichier, sprites, palettes, bloc... tu n'allais tout de même pas dupliquer les blocs autant de fois qu'il y a d'instance ? si ? [...] avec ce systeme (développé sur GBA en 2000), on fait actuellement l'affichage de fonte (du texte!) avec caractères proportionnel sur XBOX one et PS4, codé en utf-8 et disposant de toutes les langues y compris chinoix, japonais et coréen ! Tu vois, c'est souple.

Like for tileset used by a gigantic and varied map, Eric introduced cache management algorithm deep into the animation rendering. Animation data refer to logical blocks and the mapping to VRAM location happens dynamically, reusing blocks when possible, importing new ones only when they are not yet in VRAM somewhere else and dropping unused one only when room is needed, keeping them available for the next animation cycle when you have few sprites on screen.

With this approach, no need for pre-defined locations, no need to do spritesheet optimizations such as "let's keep only one VRAM slot for the stunned dumblador and update it from main RAM to get the desired animation on screen". For every block in the SpriteSet, all we need is an additional short integer indicating whether the block is currently missing in VRAM or stored at some location between 0 and 1023. Everytime an OAM need to be patched to reference one logical sprite block (like "page 4, block 21), you can check the corresponding VRAM slot in the spriteset and copy to a free VRAM slot if none is currently assigned.

Fini donc les emplacements pré-établis. Finies les acrobaties du genre "je vais garder une seule image pour 'dumblador assomé' sur la spritesheet et j'aurai un SprAnim qui change son contenu depuis la banque d'image restée en RAM (je fais pareil avec les vagues d'encre actuellement): pour chaque bloc de données contenues dans le spriteset, il nous faut un nombre supplémentaire, entre -1 (absent) et 1023 qui indique l'endroit en VRAM où on peut trouver cette image-là.

A chaque fois que l'on veut reprogrammer un OAM pour qu'il fasse référence au bloc "page 4, image 21", on regarde l'emplacement VRAM associé, et on en alloue un en réutilisant un emplacement libre si le bloc correspondant n'est pas encore en VRAM. Avec 1024 blocs de 16x16, on peut avoir assez de pixels différents dans les sprites pour couvrir 5 fois l'écran de la DS. Le risque d'un objet invisible par faute de mémoire vidéo est virtuellement nul. Dans mon organisation actuelle, j'ai 128Ko pour les sprites, soit moitié moins, mais ça reste tout à fait viable.

Le côté génial du truc, c'est que tant qu'on alloue sur des blocs qui ne sont pas actuellement présents à l'écran (marqués comme libres), on peut faire la mise à jour de la mémoire vidéo pendant la phase longue où le GPU retrace les pixels à l'écran. Seules les substitutions où on est obligé d'éjecter un bloc utilisé lors de l'image actuellement dessinée devront se faire pendant la phase courte émulant un "retour de balayage".

Now, how would that work with Bilou's spritesheet ? I'm currently using about 1/4th of the video memory for Bilou's heads while only one is shown at every single frame. Streaming Bilou's head into a double-buffer as the animation needs it was one of my top improvements for AnimEDS. With a Zmiro-cache, I no longer need to allocate VRAM slots to GOBs. I no longer need AnimEDS updates. And potentially, I could have the whole set of heads used by the current animation in video memory, having only gradual updates of the VRAM as I switch between actions.

Alors, est-ce que ça marcherait avec Bilou ? Un bon quart de la VRAM est utilisé actuellement pour toutes ses "têtes" et une seule est affichée à la fois. J'avais bien l'intention de faire une sorte de "streaming par double-buffer de la RAM vers la VRAM" dans une révision de AnimEDS. Le Zmiro-cache permet de passer souplement d'un double-buffer à "seules les têtes utilisées dans l'action en cours restent en mémoire vidéo". Je gagne de la place et je peux (enfin) me permettre d'autres petites animations avec des grimaces, etc.

Les mains et pieds partagés par les crayons, les taille-crayons et Bilou ? Ils n'occupent pas beaucoup de place et ont de bonnes chances de rester présents en permanence.

Shared hands and feet (used by Bilou, pendats and dumbladors) only use a small area of the whole spritesheet. It's likely a 'least-recently-used' policy would keep them permanently in video memory. Bonuses, ink drops, dust clouds would likely come and go as needed, giving more room for ennemies frames.

How many ennemies could we host ? Well the critical point is more "how much VRAM slots will be off-screen at every frame?". If you have a free (off-screen) slot for every block you need to bring in for the next frame, then you don't need time-critical copies during the blanking interval. You have 128KB of sprites memory, which means 512 different 16x16 blocks. enough to cover 2.5 times the 256x192 screen of the NDS. The gameplay will become cluttered well before you hit the cache limits. 

Les bonus, gouttes d'encre et autres nuages-de-poussière-encore-à-dessiner ferait probablement des apparitions éphémères, forçant des objets dont l'animation tient plus déjà du "streaming" (p.ex. inkjet) à faire revenir une image de la mémoire centrale vers la VRAM.

Bref, vu le nombre de fois où je me suis "cogné la tête au plafond" de la quantité de VRAM disponible juste sur le projet "School Rush", introduire cette technique de cache pour gérer la mémoire vidéo serait sans doute la bienvenue avant d'envisager un jeu plus ambitieux ... disons de la taille d'un Commander Keen ?

The Ultimate Scrolling Analysis.

Huge thanks to Itay Keren for having written his essay that creates a clear nomenclature of camera techniques in (mostly) platformer games, ranging from Pac-land's position locking to Mario's platform snapping to linear interpolation and beyond.

Grâce au développeurs de Frogatto, j'ai pu découvrir l'existence d'un excellent article sur le scrolling des jeux de plate-forme publié il y a quelques jours sur Gamasutra. Eh oui. C'est ça, l'après Google Reader. Je ne vais pas repasser en revue toutes les techniques qu'il présente, du premier platformer à nos jours -- pour ça, il y a l'article d'origine, mais j'en profite pour mettre à jours mes propres références.

Lerp in action. (C) Itay Keren.

Back then, when I started researching how to move Bilou's camera, my colleague Cyril suggested "an elastic string that would draw back the camera to Bilou's position". One close match is Donkey Kong Country's linear interpolation technique. It still has some "wobbly" effect but much less nausea-inducing than when you lock to the player's position. But this is far from being the only camera mechanic in DK games. Anyone who played the game has noted that some areas of the level are apparently "scripted" with cameras behaviour and that entering some hitbox may suddenly allow the camera to move past some artificial barrier, revealing a hidden area. More subtly, this can also be used to enforce "bottom-locking" in some part of the level, or change the horizontal tracking to the type of gameplay (rush, explore, climb...) of a specific area.

Commençons par une technique que j'avais laissé sur le côté quand elle m'avait été proposée par Cyril -- une "sorte d'élastique qui ramènerait la caméra vers Bilou" -- que j'avais tenté d'implémenter avec le code de poursuite des BerryBats. J'aurais mieux fait de procéder comme dans Donkey Kong Country avec une "interpolation" linéaire qui déplace la caméra d'autant plus vite qu'elle se trouve loin de son point de destination.

When I tried myself to analyze the horizontal scrolling of Super Mario Bros, I thought that there was two 'push-the-screen' positions, depending of the speed at which Mario moves. The reality is a bit different.

two triggers in SMB. (C) Itay Keren.

There is indeed two trigger positions, one -- walking barrier -- that forbids Mario from entering the rightmost part of the screen, and a second that smooths camera movement when Mario starts running. The "early-scroll" trigger doesn't try to keep Mario at its left, though, so he eventually "escapes" to the walking barrier.

Passons ensuite à SMB1, avec son interdiction de revenir en arrière. Ici pas de soucis pour faire demi-tour, mais Miyamoto a quand même pensé à nos jeunes estomacs et a ajouté un démarreur de caméra deux blocs avant la position 'naturelle' de Mario. On y gagne pas pour autant en visibilité pendant la course comme je le pensais au départ, mais on évite un départ trop brusque de la caméra si on revient en courant.

This is what smooth out the movement of the camera by reducing the instan(aus)eous acceleration of the image. I'd be tempted to say screen will move at walking speed until the real barrier is hit. I guess with more CPU cycles and memory, miyamoto's team could have even tried to linearly over time in that region rather than having two-steps, but I doubt most of us would notice the difference, so it's not bad to keep it simple. But no, you don't really have more headroom when running in SMB.

Finally, Itay's model of Super Mario World's camera nicely complement the video document I already found (and not yet re-blogged so far). The camera here clearly has multiple mode, that Shaun categorizes as "platform-snap", "bottom-locked" or "free-moving". I tried and mapped these as an UML state machine, but it lacks one component: the fact that in some levels/parts of the level, some transitions are forbidden -- e.g. in some levels, you will not enter platform-snap and stay bottom-locked.

Les différents mode de suivi vertical de Super Mario World, j'avais déjà étudié par l'entremise de Shaun. Le code est assez sophistiqué pour mériter une machine d'état à lui tout seul. En plus de ça, certaines transitions sont interdites dans certains (morceaux de) niveaux, forçant par exemple la caméra à rester au niveau du sol à moins que Mario ne s'envole dans les niveaux plats. 

What Itay adds to that, is a clear illustration that the camera in SMW has a direction state of its own (moving leftwards or moving rightwards) distinct from Mario's movement. In each direction, there is one barrier that will make you push the screen if you try to go past it, and a trigger that will switch to the other mode if you touch it. When the camera is "heading right", the two yellow lines are active -- Mario is confined within 2 blocks. As soon you hit the dashed line while turning back, the camera switches to "cyan mode", and then you have the screen adapting as quickly as the camera's max speed tolerates because you're about 64 pixels away from the push barrier for that direction (still picture shows a point in time where such catch-back occurs).

L'analyse de Itay est plus précise en ce qui concerne le scrolling horizontale. Il illustre parfaitement le mécanisme des deux "poussoirs horizontaux" décentrés (un pour chaque direction de caméra) et les déclencheurs qui forcent la caméra à changer de direction quand Mario a fait demi-tour de plus de 2 blocs. Il semblerait qu'on ait ici aussi utilisé une "interpolation linéaire" pour adoucir le mouvement de la caméra quand elle atteint à nouveau la position de Mario.

With this scheme, the player always have at least 1/3rd of the screen in the direction he face and half-a-screen-plus-one-block in most of the cases. That works quite well with exploration games like Commander Keen, imho.


If you're doing game design in some way, I strongly recommend you to spend some of your "research points" reading Scroll back : the Theory and Practice of Cameras in Side Scrollers.

Spongebop Rodeo

I now have a (partly-)working prototype where Bilou can grab a Sponge bop and stay hooked while swinging, but I have to hard-code the offset between Bilou and the Sponge as arguments of the copycoords controller. Not so elegant. Plus, if I also allow to grab on Bladors (granted, that's a silly idea, but it helped for debugging :), those offsets are no longer correct and we're rather grabbing some point in the air over Blador's top-right corner >_<

Bien. Bilou peut maintenant s'accrocher aux éponges en balance. Il y a encore des soucis non résolus avec l'animation prévue à cet effet (d'où l'absence de démo jusqu'ici) et un désagrément mineur: il m'a fallu ajuster à la main et préciser dans les paramètres du comportement "accroché à X" la position relative de Bilou et de l'éponge. Au moment d'ajouter le comportement "assis dans un encrier", ça me démange un peu.

I initially had plans for making those "grabs" act on an are, and it would make sense to actually state "copycoords(a.bottom=b.top ; a.center=b.center)", but I've just said that accessing GobAreas within a controller isn't practical.
Expressions handling a collision have access to some extra-context variables (wc-wf) which were just involved in that "repel" behaviour that made inkjet "solid".

• xcontext[0] - wc -- collision flags
• xcontext[1] - wd -- unused (0)
• xcontext[2] - we -- X-axis center-to-center distance
• xcontext[3] - wf -- Y-axis center-to-center distance
• xcontext[4] -- not in GobScript - X-axis area overlap
• xcontext[5] -- not in GobScript - Y-axis area overlap

 The idea would be to use some GobScript to compute/force the desired location, possibly record it in some GOB variables and have the CopyCoords controller simply enforce that offset from the GOB variables.

Il y aurait bien des solutions techniques pour automatiser ces coordonnées relatives en "alignement vertical, centrage horizontal", à la façon des éditeurs de diagramme ... il y aurait même un "chemin de moindre résistance" pour construire ça dans le contexte actuel. Mais soyons honnête: ce n'est *pas* un élément nécessaire pour le programme. J'ai un seul objet auquel Bilou puisse s'accrocher de la sorte (l'éponge) et je dois de toutes façon utiliser une autre animation pour Bilou-dans-l'encrier (donc, autre état et autres paramètres). Ce serait donc de la généralisation intempestive et prématurée! Caramba! Ça le ferait pas!

I could thus extend the "interaction opcodes":

• A[p]: attach [with path] evaluating object to context object (works in hit and found)

D: detach evaluating object (works in any transition)

R[xy]: repels context object away from the evaluating object (works in hit and found) [only along x/y axis]

L[xy]: line up the evaluating object with context object (mirrored repel)

C[xy]: center the evaluating object with context object (wish)

Now, let's be honest. That's a "wish", not a "todo". I only have one grabbable ennemy so far, and only Bilou grabs it. "hard-coded" offset are just fine in that context, and alternative are "premature generalization". I thought about all this because I'll also need a "copycoords" when Bilou sits in an inkjet, but that will be another animation and another state, so other copycoords offset is just fine.

Setting the bar

It's a secret to everybody: I follow the blog of Frogatto & Friends. I think the project has a high potential and is technically well-done. Their editors are truly impressive, for instance. Yet, I'd love to drive my own theses on game engine design to their conclusion, so I keep working on my own approach.

When I stumbled upon a post entitled "Platformer Enemy Design" in the newsfeed, right after I had crafted the "monster design book" out of this blog, I felt like a kid getting his Christmas present. Yet, the content was pretty far away from what I expected! The post is actually more like a call for rationale development applied to people who code monsters behaviour for games.

Juste comme je finissais le post sur les versions papier de "level design" et "monster design", je tombe sur un article d'un des auteurs de "frogatto & friends" (excellent petit jeu indie et open-source) intitulé "design des ennemis dans un jeu de plate-forme"... qui s'avère être très différent de ce à quoi je m'attendais, mais très intéressant malgré tout. Jetrel y présente une série de "pièges" dans lesquels un développeur de jeu peut tomber (liés à la conception des ennemis)  et qui pourrait retarder indéfiniment sa "sortie".

Consider making a flying enemy with basic behavior that makes it fly from one X position, to another X position. In a generous, open space with no terrain in the way, writing this is trivial; [...] It seems reasonable, from a level-designer’s standpoint, that it should always work regardless of the layout; [...] So if you put it in a twisting corridor, it’ll naturally duck under the outcrops, and rise over ridges to find a path back and forth. Except actually it won’t, because [...] there is no pathfinding. There’s no AI; there’s just one, single line of code with two conditionals in it.

What Jetrel calls for, is for people like me to admit that there's little value for a "magical monster that will always behave as a (hypothetical) third-party level designer could want it to behave". Instead, if you have a monster that works well in some type of terrain/environment - which is *the* type of terrain you intend for the level you want to place the monster in, it's perfectly fine. Noone would expect a paratroopa to work correctly in an underwater level, anyway.

Le premier conseil est une variation sur le thème (célèbre) "Keep it Simplest, but not Simpler": faire le plus simple possible, mais pas plus simple que ça. En particulier, s'évertuer à créer des monstres qui se comportent *toujours* correctement, quelque soit l'environnement, est inutile. Ce qui est important, c'est qu'il se comporte correctement *dans le type de niveau pour lequel il a été conçu*. Si la BerryBat est prévu pour poursuivre Bilou dans des cavernes, il se peut très bien qu'il ne fonctionne pas à l'intérieur de la pyramide (plus labyrinthique) parce qu'elle se cogne systématiquement au murs. Inutile aussi de prévoir que Funky Funghi doive "mourir" s'il tombe dans l'encre de la SchoolZone: il n'y a pas d'encre dans son environnement. Dans le même ordre d'idées, les Applemen qui se croisent ne posent pas de problèmes dans un niveau "à la Mario", même s'ils provoquent des problèmes de clarté dans Apple Assault.

When I was implementing Dumblador's wandering lone feet, last month, I encountered that very kind of situation. Making the feet move back *to the blador* in all circumstances quickly proved totally un-obvious. It would have required them to move at ludicrous speeds here, making jumps that even Bilou can't deal there, etc. But in practice, I don't necessarily want bladors to recover *at all costs*. What I do want, is that blador recovers with variable time depending on the terrain style ("hill"-like or "hole"-like) when the player takes too much time to grab it. It's fun if it recover even though you thrown it to the next book, but it's in no way mandatory.

There is however one key element that I want to bring into Bilou's gameplay, which is the suspension created by allowing monsters to be thrown away from their original location or have their path blocked by some other items (i.e. drop an inkjet on a pendat's pathway). That both rules out the simple "follow design path" approach used in RSD game-maker and the "level encodes where the path ends" used for some Keen monsters and in "The Game Factory" engine. That doesn't mean I need super-smart monsters that can climb up locations and track Bilou, but they definitely need some sort of state machine and level features detection so that they can have sufficient amount of autonomy.

Ce qui est amusant, c'est que les pieds baladeurs de Dumblador ont justement posé des questions de ce genre il y a un mois. Je les avais codé initialement pour qu'il puissent franchir *n'importe quel* obstacle (quelque soit sa hauteur) en les faisant sauter de plus en plus haut. Au final, ils étaient tout simplement incontrôlables et finissaient par sauter tellement haut qu'ils ne parvenaient de toutes façons pas à franchir l'obstacle en question. Dans la démo de nouvel an, les pieds *escaladent* les obstacles plutôt que de chercher à sauter par-dessus. Ça me convient. Il y aura des situations dans lesquels un Dumblador assomé ne pourra pas récupérer ses pieds (en particulier si Bilou l'emporte avec lui), mais il existera aussi des dispositions de niveau dans lesquelles j'obtiens l'effet désiré: un ennemi qui prend plus ou moins de temps à récupérer selon la situation dans le niveau (autorisant des stratégies du genre "j'attends qu'il soit au bord pour l'assomer) tout en offrant un retour visuel sur le temps qu'il reste pour s'en saisir.

J'admets qu'il faudra que je garde le conseil à l'esprit et que j'en fasse une ligne de conduite, parce que j'ai une tendance naturelle à résoudre des problèmes larges. La façon dont les ennemis "marcheurs" de Bilou décident de faire ou non demi-tour en est un exemple, mais je ne saurais me résoudre à une approche "dessinée" du trajet suivi par les monstres (cf. RSD Game-Maker), car j'ai déjà pu me rendre compte à l'époque que les types d'interactions que je souhaite apparaître au coeur du gameplay (interrompre le chemin de ronde d'un pendat en faisant tomber un inkjet, par exemple)

If you do a boatload of work on an enemy to make it work in different situations, but the basic decisions the player faces are still the same, you’ve wasted your time. The basic gameplay is still the same; you’re just jumping through hoops to provide it.

Which I translate in "no matter how smart that inkjet is when it shoots at you: if you can dodge its balls just by jumping anyway, you have changed nothing". I think this is deeply connected to interplay. I'll have to push more thought into that part.

Il y a d'autres choses intéressantes dans cet article, mais là, ça fait 3 fois que ma fée me demande l'heure en 30 minutes, donc je vais lacher un peu mon clavier ...

KISS (t.a.g)

Keep It Simply Simple

I have a natural twist towards over-sophisticated designs. I certainly prefer Great Ball Contraptions over the shortest path. I've spent countless hours of my childhood trying to build a mechanical pattern to have a spider-like LEGO robot. I need to monitor my own designs again and again to ensure my software doesn't end up so sophisticated that it becomes impossible to think about it over the time of a tea cup.

There were likely too little words in this section, showing that the road is still long.