statI4->statJ6 on event0

Difficile de rester accessible tout en donnant des détails sur l'avancement de la réalisation de mon moteur de jeu. J'ai peur d'avoir perdu la majorité d'entre vous avec le post précédent ... Pour essayer de rectifier le tir, rappelons que le comportement de mes p'tits sprites est découpé en états, chaque état donnant l'animation à exécuter, le comportement (à travers des contrôleurs comme "lecture du DPAD", "gravité", "marche sur le sol" ou "suit le sprite n° X") et les zones de collisions reçues et générées. Le comportement global -- mettons de l'appleman -- se définit alors en donnant les transitions qui vont faire passer un sprite d'un état à un autre dans certaines conditions et avec certains effets. Par exemple:

Not so easy to keep you updated of development stories while remaining accessible. I guess most of you have been lost somewhere in the previous post... Let me try to explain better. Every sprite in the game has a behaviour that is split up in states, every state defining what animation should be displayed, the generic behaviour (through controllers such as "read DPAD", "apply gravity", "track sprite #x", "walk on the ground", etc.) and collision-related properties including hitboxes.

• Falling->Running on FAIL qui fait en sorte que l'appleman cesse de tomber une fois arrivé au sol
• Walking->Surprised on found1 qui fait sursauter l'appelman quand Bilou entre dans sa zone de détection.

Things are then put together with transitions that describe when you will move from one state to the other, and under which condition. "FAIL", for instance, indicates that the controller responsible for movements cannot find any valid move for the current position and speed. "Found" and "Hit" are used when one succesfully hurt or get hurts by someone else, respectively. "Done" indicate the end of an animation and "Event" reports a 'special' condition.

Au moment de programmer la gestion des collisions, j'avais bien senti que l'approche ne serait gérable que si les différentes zones de détection pouvaient être gérées indépendamment, d'où "found1" lorsqu'un appleman 'a vu' Bilou et "found0" qui indique que Bilou a été touché. Puis l'idée est apparue (en codant InspectorWidget ?) d'étendre ce principe à eventi pour identifier quel contrôleur, dans l'enchaînement qui définit un comportement, a signalé une condition spéciale. On pourrait ainsi plus facilement distinguer "nouvelle touche enfoncée" de "passe du saut à la chute" ou "on est devant une liane". J'ai déjà eu des "interférences" malheureuses de ce genre pendant le développement d'Apple Assault, ça ne saurait aller qu'en s'empirant au fur et à mesure que le comportement de Bilou devient plus sophistiqué.

"Special Condition" was initially only used for reporting DPAD changes, but as the behaviours expanded, it started including more diverse things such as "vertical speed reversed" at the top of a jump, "target has changed side" ... Somehow, it became a fairly generic gobscript invokation mechanism as I decided to split the control function into a chain of simpler things. The problem that arose was that it then become hard to tell which of the chained controllers raised the event, testing them in the right order to come to the right conclusion. What I tried this week-end was to delegate the list of transitions-on-event to the controllers themselves, so that you explicitly "name" the controller for which you program an event reaction. So far it works, it hasn't been too complicated to setup (although it's probably a terrible hack from OO design patterns point of view), and thus it enables the door to more techniques ...

Et avec tout ça, évidemment, je n'ai pas fait les 3 dernières modifications qui me permettraient de passer à la version "finalisée" d'Apple Assault ... à savoir ... euh ... j'sais plus.

• [wish?] ne pas effacer la souche au démarrage du jeu
• [done] prendre le contrôle de Bilou dans les animations level clear/you're dead
• [done]activer les nouveaux graphismes pour une meilleure visibilité dans les branches
• [done]garder l'écran de jeu masqué pendant le chargement du niveau
• [done]éviter que [START] ne bousille tout l'affichage (eh oui, encore).