FLITS again

Okay, let's keep tools-fusion for later on and focus on the impending walk of Dumbladors. I had them stepping blindly yesterday, and now, I'm trying to use the "walker" controllers (the one that can follow slopes and so on) to control them, so that they can be placed like Applemen rather than suffering woodworm-like bugs.

I had some more "FLITS" bugs, with dumbladors disappearing into the void of the toroïdal space (?) as soon as they hit a wall 0_o

The good news is that InspectorWidget was already much more capable than I thought, despite its cryptic user interface:

1. (1) touch here to set a "breakpoint on bounding-box intersection
2. (2) once a monster appears, click its "name" (2 first letters of BLador.cmd plus current state number) to give it the inspector focus.
3. (3) click the coordinates of one monster to "disable" it from execution (or resume its execution).
4. (4) click the focused gob's "name" bar to switch between iGobControllers display or cdata (GOB's private variable used in GobScript) display.
5. (5) touch "p*" or "a*" to enable the rendering of collision areas.
6. press L to step to the next frame (slow-motion) or L+START to resume normal play (with breakpoints active).
   

After fixing the "silly sunday bug" (giving a positive v0 speed for a state that moves to the left :P), I think I identified the reason why blador disappears: the "deficit" for step-based walk increases by v0 at every frame, but I also have "delay xxx" instructions in my animation, which makes the GOB to accumulate deficit move over time. When it comes to turn around, it is first "wrapped" to the place it's supposed to be (not very ideal)... and that happened to be off-screen this time ^^"

Fuuuuuusiooooooon

The more I use AnimEDS for the Bilou project, the more it becomes obvious: I will have to merge SEDS and AnimEDS into a single program, so that one can easily touch up or re-center sprites used in animations, or easily preview the new sprites on the defined animation. Easing the switching between the two tools will not do it. Integration is really what's needed.

This post will collect thoughts and battle plan for this huge refactoring attempt ... I won't get into it before I have a first school zone demo running.

SEDS	AnimEDS
* drop the dumb 'animation editor' * leftTable could be dropped between two "restore()" of the fileWindow	* make onion skin possible, but keep OAMs for the rightTable * solve the memory management bug.

Jusqu'ici, avoir AnimEDS et Sprite Editor dans 2 exécutables séparés était plutôt bénéfique. Je pouvais complètement foirer une "release" AnimEDS sans pour autant perdre la possibilité d'éditer des p'tits sprites sur ma DS (ou pire, de corrompre les fichiers .spr). Mais à l'usage, il est clair que devoir basculer d'un programme à l'autre est fréquent pour avoir une animation correcte. Rien que sur Dumblador (pourtant élémentarissime), j'ai du faire des va-et-vients pour re-centrer les pieds, histoire que l'animation passe sans heurts. Alors commencer une animation avec des boules en guise de pieds et mains puis "affiner" en redessinant quelque-chose de plus rayman-esque ... je n'ose même pas imaginer 0_o

Je vais donc devoir fusionner les deux ensembles de "fenêtres" dans un seul et même programme, ce qui va nécessiter un fameux effort de mise à plat du code (UML? ô UML, pourquoi es-tu UML?) histoire de garder un état cohérent entre les "feuilles de travail" pour les sprites.

Je pense que ce sera pour les grandes vacances, dès que j'ai une démo du niveau "school zone" qui est partie sur dev-fr.org.

(PS: ce post est en "brouillon" sur le blog depuis septembre 2011 ...)

2024 #choice reality check: did not happen. Will likely never happen. I'll keep on swapping from one tool to the next and hope for the best.

Yeah! Blading time!

Wow. I had no idea it would go so fast! Less than 24 hours after the proper alignment of dumblador on screen, I can now have it walking around in a level. Many things remain, such as making it detect edges and turn around, just like applemen and woodworms. That will be a next level. Here's the updated AnimEDS for download, although I'm pretty sure it needs more feedback hints before it becomes user-friendly.

Eh bin !? ça n'aura pas trainé. Je sentais bien que je n'étais pas loin de "dumblador qui avance", mais de là à deviner qu'en une soirée, ce serait réglé dans AnimEDS et qu'avec juste 2 heures de plus dessus ce matin (dont un peu d'ajustement de sprites), je pourrai le faire avancer aussi dans le moteur de jeu ... C'est pourtant le cas. Chouette. Je vais pouvoir commencer à ajouter la définition des zones de collisions entre sprites ... ou alors je garde ça pour un programme annexe encore un moment ?

Where You See is Where It Is

Bon, on récapète.

• 3 mars: fusion du code expérimental pour les nouveaux sprites composites dans le moteur de jeu. Il faudra quand-même pas mal chipoter pour pouvoir éditer la school zone dans LEDS
• 18 mars, le fichier de commande pour dumblador est écrit. C'est lui qui servira de démonstration des nouvelles capacités du moteur de jeu, mais rien à l'écran ne trahit encore la présence de dumblador :P
• 24 mars, release source du moteur de jeu et de ses outils.
• 26 mars, "reality check": pour pouvoir positionner Dumblador dans un niveau, he dois faire une révision d'AnimEDS pour qu'il enregistre la miniature à afficher;
• 25 avril, je peux ajouter des dumbladors qui font quelques pas (sur-place) mais il me manque des outils pour définir quelle portion de l'espace ils occupent dans le jeu.
• 7 mai, comme d'habitude, j'ai zappé la case 'feedback à l'utilisateur' et mes outils sont à la limite de l'utilisable.


• 15 mai; ok. Je peux enfin positionner de manière fiable un dumblador dans mon niveau

Là, j'ai AnimEDS, LEDS et le moteur de jeu qui sont d'accord sur la manière d'interpréter la position d'un personnage composite dans un niveau. Ça n'aura pas été sans mal.

Well, it's a milestone: I can precisely place compound GOBs in a level. Neat. Now, if you don't mind, I won't translate all the tracking and focus on the impeding future: defining moves of the compound GOB in AnimEDS as well ... and then have them walking :)

A few weird things occured with this dumblador development, which should sound "normal" to any game developer: a monster that cannot be seen but hurts you nonetheless, or that can be seen at position A while it hurts and can be bop'ed on at position B ... and also a monster that "walks" without leaving position A and suddenly appears at position C when his "step" movement is done (distance between A and C being totally impossible to predict from the observation of the movement).

No need to say that in some parallel universe, dumbladors seems to have super-natural powers that make Bilou's job quite more complex. According to Bouli, that'd be because they're following elliptic curves, but on a toroïdal and discrete space...

J'ai même le début de la définition des déplacement, quoi que ce soit encore très "courbes elliptiques en espace discret toroïdal", si vous voyez ce que Bouli veut dire ... non ? bon, bin Dumblador reste sur place pendant presque toute l'animation, puis arrive d'un coup à une position improbable qui n'a pas grand-chose en commun avec le déplacement qui était prévu, donc:

1. faire en sorte d'avoir en mode émulateur (sur toutes mes machines) une animation de déplacement, histoire d'éviter de re-faire l'animation à chaque test;
2. éliminer les effets du type "la position de la tête n'est remise à jour que si la tête est déplacée (relativement) dans l'animation.
3. garantir que l'info du type "verouillé sur le membre #3" est maintenue à jour quand on se déplace le long de la timeline.
4. trouver le bug.
5. Faire en sorte que les repères de positions dans LEDS restent corrects quand on se déplace dans le niveau ^^"

Voo have a problem

Okay, there was enough to do over the week-end to support an Internet service downtime, but it was still a pain to see that brand new Voo modem rebooting for 48h, completely out of my control, with only a few 5-minute window where I could commit some code to my svn.

Hopefully enough, one of my systems at home had a pretty freshly updated code base to work with, so I could fix those solid-box-definition issues and bring AnimEDS to a point where I can start toying with embedded movements... at last. Let's see if I can make dumblador actually *move* by the end of the week (and get that modem fixed, btw).

devil in the details

Mouais. J'aimerais dire "#çac'estfait", mais en fait non. J'ai bien la possibilité de définir une première zone de collision dans AnimEDS, la possibilité d'aligner le bord inférieur sur la map dans LEDS et le game engine qui regarde tout ça sans broncher, je garde un désagréable goût de bicarbonate en bouche.
Il m'aura fallu plusieurs aller-retours dans LEDS pour pouvoir faire l'ajustement, les monstres se désactivant à plusieurs reprises. De plus, le minuscule dumblador affiché sur la map ne permet pas de se rendre compte si le positionnement est correct, ni de le sélectionner avec précision. Affaire à suivre.

I'd love to call it done, but let's be honest: it's not. It's merely a hack that allowed me to have *one* dumblador properly aligned after countless "there-and-back" games in the level editor. I'll have to do some polish before it could be of any real use. Much polish. "devil is in the details".

• [done] now that I can select dumbladors with their real sizes, I can't select Bilou anymore, who looks to have (0,0) dimensions -- fixed.
  
• [fix] DPAD-positioning is somehow fixed ...
  
• [workaround] but I still need to visualise the solid box of the monsters, not only their thumbnail.
• [done] monsters are rendered where they have been designed to stand.
• [done] BoxWidget becomes immediately responding to DPAD commands after the 'bx' button has been clicked.
  

BoxWidget ... beyond the code.

I missed a "svn commit" this morning, so all I can do is some mock-up to think about how the "BoxWidget" will be used to define hitboxes in AnimEDS... It seems like I'd rather not jump into implementation immediately and think a little bit about the options: boxes are defined on a per-animation basis, not a per-frame basis, so maybe they could be edited on the FileWindow rather than on the AnimWindow.


Bon, bin quand on a pas synchronisé son code à la fin du week-end, on peut toujours se faire un p'tit mockup pour voir comment le nouveau widget "définir une zone rectangulaire" va pouvoir aider à la définition des zones de collision. Mock-up pas totalement convaincant, d'ailleurs. Fort confus, même si je ne vois pas bien comment faire mieux. Ça me paraissait une bonne idée, au départ, de juste "suggérer" la zone de collision en marquant ses coins, mais la plupart des problèmes de collisions rencontrés jusqu'ici provenait d'un recouvrement entre zones. Du coup, pouvoir en visualiser plusieurs d'un coup ne serait sans doute pas plus mal...

It could also be interesting to be able to visualize more than one box at a time, similarly to what happens with InspectorWidget: many "collision bugs" were due to improperly overlapping windows. That could require another form of display