Globalement

Maintenant que nous avons une version pleinement fonctionnelle de Shooter

en référence, il devient intéressant de revoir le déroulement du jeu d’une façon

plus globale, car on peut ainsi mieux apprécier le génie de Xna et de la programmation

objet.

La librairie MSDN le confirme, la rubrique Animation est bien une classe à l’intérieur

de Xna, accessible dans un using ...Graphics. Mais voilà, si on demande à voir ses

méthodes, tout ceci est bien intéressant et sans doute utile, mais cela ne guarantit

en rien le déroulement d’une animation.

C’est le coeur du problème: les classes ne remplacent pas l’obligation de programmer.

Notre jeu contient plus d’une animation à faire rouler: le player, les ennemis, les explosions. Si on regarde d’un oeil détaché la page animation à l’intérieur du jeu, on

se rend compte que les dénitions et la méthode update qui y sont créés ne s’appliquent

à aucune animation en particulier mais à toutes. Frame est défini mathématiquement,

en fonction de viewport et image width. (Image width, à son tour vient de la taille

de la texture2D, par le nombre de divisions, au moment du Load dans Game). Il

en revient au développeur de faire son travail. Notre jeu crée du nouveau dans Animation le temps du jeu.

Dans le même ordre d’idée, on se retrouve aussi en voie d’apprécier que certaines

façon de faire qu’on nous impose - pas toujours évidentes - recèlent des ouvertures

pour des procéder de programmation plus poussés. La première commande du Draw, le Begin, peu servir à un programmeur de jeu professionnel à spécifier bien des choses à propos du dessin à entreprendre, car c’est une méthode du SpriteBatch class.