Les limites du GobScript

Ramasser des éponges alors qu'on pouvait déjà ramasser des tailles-crayons ... ça n'aurait pas dû être aussi difficile que celà n'a été. Le fait que les objets soient numérotés plutôt que nommés empèchait toute possibilité de détecter les erreurs. L'autre, c'est que le copié-collé est le seul moyen de réutiliser une région substantielle de code.

Current GobScript is meant to be human-readable bytecode for the state machine. Yes, truly. The most obvious way to realise that is how everything is *indexed* rather than *named*. The upgrade introducing C pre-processor in the make process to avoid code duplication in the behaviour script has been generalized to all monsters of the School Zone.

Yet the recent modification of these behaviour show that it becomes quite tricky to maintain coherency when adding new features. For instance,

• [done] picking up spongebops was missing triggers and repeated bugs about stuck carried GOB when hit.
• [done] Pendat rushing don't hurt Bilou when stomping him because I haven't copied hitboxes when creating the new state
• [done] Stomp-and-grab blador in one move kills Bilou's horizontal speed and creates bogus camera conditions.
• [done] We may enter walls when trying to pick something on the ground, because of a missing 'stopper' micro-controller
• [done] stomping a blador while doing a air-grab allowed to move through because of a missing hitbox.

All this claims that I should now work on a higher-level language for editing, where I could express that "SpongeBop allows carry_me" and "blador allows carry_me" and that would imply some new states added to state machines, specific hitboxes in other states, transitions and such. Don't be surprised if I take that excuse to practice some Haskell, as there is currenty a professional incentive to master that language.

Je me vois mal utiliser les macros du pré-processeur C pour reproduire un motif du genre "une zone de collision dans l'état X permet de passer dans un état $CARRIED puis dans un état $THROWN jusqu'à ce qu'on heurte le sol, ce qui nous ramène dans l'état Y." par la seule ligne "using CARRY_ME(X,Y)" ou quelque-chose de ce genre. Dans le meilleur des cas, celà reviendrait à définir CARRY_IN=X et CARRY_OUT=Y avant un #include "carry_me.cmd.h" ... pas franchement le plus élégant, mais sans doute préférable à une duplication du code...

Ne vous étonnez donc pas si je prends le prétexte d'un convertisseur d'une version "maintenable" du GobScript vers sa version "machine" pour mettre un peu d'Haskell en pratique dans les prochains mois, hein ;)