Revoir le mode "debugging".

Je continue mon petit "tour de piste" de la todo list de l'autre jour ... Les collisions entre Bilou et les monstres ne sont pas tout à fait fiables. Si vous essayez d'assomer un appleman ou un woodworm en lui sautant dessus, vous avez un risque non négligeable de le "louper" et de vous faire blesser.
J'ai tenté à plusieurs reprises de "debugger" ça à l'aide de mes petits messages affichés sur le 2eme écran, mais sans grand succès. Et contrairement aux soucis rencontrés dans la gestion du sol, gdb n'est pas très utile non plus.

I need something to help me debugging collisions. Trial-and-errors allowed me to have woodworms stomped with sufficiently high probability, but stunning an appleman is still a pretty risky task. It's not that I haven't cared it, it's just that I miss the proper tools to investigates what happens. Dumping state changes on the console doesn't help because too many things occurs. I've got "step-by-step" system, but doesn't help either because it freezes monsters and only moves Bilou step by step. Finally, proceeding with gdb and ddd for a regular debugging session is helpless: problems are located in state transitions and collision area definitions, not in C++ code as with slopes and controllers.

D'où l'idée d'un écran spécifiquement prévu pour la mise au point du jeu, qui présenterait l'état actuel de Bilou, les différents contrôleurs, testpoints et zones de collision ... et les transition d'état qui y sont associées (event, fail, hit et found), les GOBs qui entrent dans la zone d'intersection, leur propres zones de collisions, etc. Chaque transition pourrait être "cochée" de sorte que le jeu soit mis en pause dès qu'on essaie de l'emprunter.

Je sens qu'il va être temps que je regarde comment fonctionne la commande "friend" en C++ ...

So I've been thinking about a specific game debugging screen that would show current hero state, active controllers and their "internal state", testpoints, collision areas. State transitions would have a special importance: each "item" that could trigger a state transition would list (a few) possible output states and the user (me ^_^) could then click them to force the game engine to enter debugging mode if that transition is attempted

Vous remarquerez peut-être que j'associe les transitions systématiquement à des éléments (contrôleur, test-point, zone de collision) ... c'est une des prochaines "refontes de code" à laquelle je dois m'attaquer ... la clé de voûte de la prochaine release. Aussi bien l'éditeur de niveau que le debugging et l'augmentation du nombre de monstres (et de types de monstres) en dépendent d'une manière ou d'une autre.

edit: j'étais ennuyé par l'entrelacement entre cette nouvelle fonctionnalité et tout le "refactoring" que je souhaite faire par rapport à la manipulation de la machine d'états. En fait, pour mettre au point les collisions, c'est essentiellement les zones de collisions qui m'intéressent, évidemment. Et pour elles, la liaison zone/transition est déjà une réalité. Je peux donc commencer par ça et ajouter le reste par la suite.

I've been concerned by the interleaving between this new debugging screen and the under-planning refactory of linking between controllers and transitions. But actually, it's something that can happen smoothly. The debugging screen can focus on "areas" first, and transitions due to "controller-generated events" can be added to the InspectorWidget after the refactory took place.
Oh, it will be my first time with C++ friend classes, too.