Tout comme les contrôleurs, les “générateurs-d’objets-en-cours-de-jeu” (baptisés iGun, pour faire simple) sont des classes C++ paramétrées par le script et associées à certains états ou transitions pour ajuster le comportement du jeu.
Pour les contrôleurs, je les avais associé à l’état courant. Facile (presque trop). Pour les “guns”, j’hésite. Le script ? une transition ? un objet graphique ? Qui aura accès directement à la classe, et qui n’y accède qu’à travers les méthodes d’un autre ? C’est le genre d’indécision que je déteste en POO, typiquement parce qu’en programmation impérative, le problème ne se pose pas.
- C’est au niveau des transitions que les guns sont utilisés. Je peux éventuellement capturer ce qui m’intéresse lors du parsing.
- Je n’ai droit qu’à 16 guns dans une ‘palette’ d’effets
- Je veux éviter de devoir ré-instancier des guns identiques (contrairement à ce qui se passe pour l’instant avec les contrôleurs où je dois avoir autant de GravityController que d’états affectés par la gravité).
Not quite “analysis paralysis”, but still not enough time after lunch to figure out the best way to add iGun into the object-oriented game engine. It is used by Expressions (after all, guns are used to shoot new GOBs into the playground), but it’s only one of the 16 guns an expression has, and it is likely to be shared by many states. What scope should it have ? which object will ‘host’ it, etc.
I’m undecided. I’ll have to leave it for further code refactoring.
Bref. Je devrai revoir cette partie-là un autre jour: mon temps de midi touche à sa fin…
Bouli's Homebrew Blog 
PS: en fait, dans un premier temps, je veux attacher ces “actions” aux compteurs. Dans ce cas-là, pas besoin de faire des chichis: le scope est le GameCounter (un objet qui n'existe pas encore) et j'aurai qqch comme
set hitpoints 3 on zero level(green1.cmd)
set lives 3 on zero gameover()
LikeLike
PS: en fait, dans un premier temps, je veux attacher ces \”actions\” aux compteurs. Dans ce cas-là, pas besoin de faire des chichis: le scope est le GameCounter (un objet qui n'existe pas encore) et j'aurai qqch commeset hitpoints 3 on zero level(green1.cmd)set lives 3 on zero gameover()
LikeLike
# une approche possible.
actions[0] = sound(aouch)
actions[1] = sound(patam)
actions[2] = shake(0,-3)
actions[3] = sound(pof)
bfall->bland on fail [v1 512 >] (x1x2)
bfall->bland on fail [t] (x3)
# if you fall too fast, you've got a big
# noise and the camera will shake horizontally
# otherwise, you just hear a little 'pof'
bfall->bhit on hit [wc 1 ?] (x0)
# shout if hit.
actions.keep(0001)
# new actions palette, but keep the 'aouch' sound.
… # more code
actions.clear
# completely fresh actions palette.
LikeLike
# une approche possible.actions[0] = sound(aouch)actions[1] = sound(patam)actions[2] = shake(0,-3)actions[3] = sound(pof)bfall->bland on fail [v1 512 >] (x1x2)bfall->bland on fail [t] (x3)# if you fall too fast, you've got a big# noise and the camera will shake horizontally# otherwise, you just hear a little 'pof'bfall->bhit on hit [wc 1 ?] (x0)# shout if hit.actions.keep(0001)# new actions palette, but keep the 'aouch' sound…. # more codeactions.clear# completely fresh actions palette.
LikeLike
bon. Pour l'instant, je ne pense pas avoir besoin de + de 16 actions en tout, donc je vais me débrouiller avec un seul tableau pour l'ensemble.
LikeLike
bon. Pour l'instant, je ne pense pas avoir besoin de + de 16 actions en tout, donc je vais me débrouiller avec un seul tableau pour l'ensemble.
LikeLike