« Pygame/Introduction au module Sprite » : différence entre les versions
Contenu supprimé Contenu ajouté
→Les classes : actuellement != actually |
m Formatage, ajout de code |
||
Ligne 6 :
__TOC__
La version 1.3 de Pygame inclut un nouveau module, <
Le module sprite est censé être très générique. Il est possible de l'utiliser pour pratiquement n'importe quel type de gameplay. Cette grande flexibilité a toutefois un léger défaut, elle nécessite un peu de réflexion/compréhension pour pouvoir l'utiliser correctement. La [http://www.pygame.org/docs/ref/sprite.html documentation de référence] du module Sprite peut vous venir en aide, mais vous aurez probablement besoin d'un peu d'explications supplémentaires pour utiliser <
Plusieurs des exemples d'utilisation de Pygame (comme ''chimp'' et ''aliens'') ont été mis à jour pour utiliser le module sprite. Vous voudrez certainement examiner ceux là d'abord pour observer ce qu'est approximativement le module sprite. Le module chimp possède de toutes façon son propre [[Pygame/Chimp - Ligne par ligne|tutoriel]] en ligne par ligne, qui pourra en plus vous aider à comprendre la programmation avec Python et Pygame.
Ligne 26 :
== La classe Sprite ==
Comme mentionné auparavant, la classe Sprite est conçue pour être une classe de base pour tous les objets de votre jeu. Vous ne pouvez pas vraiment l'utiliser en tant que telle, car elle est constituée seulement de plusieurs méthodes pour faciliter le travail avec les différentes classes de Group. Le sprite garde une trace du groupe auquel il appartient. Le constructeur de classe (la méthode <
Lorsque vous utilisez les classes Sprite, il est préférable de les considérer comme ''valides'' ou ''vivantes'' lorsqu'elles sont contenues dans un ou plusieurs groupes. Lorsque vous supprimez l'instance de tous les groupes, Pygame va supprimer l'objet (sauf si vous possédez votre propre référence de l'objet quelque part). La méthode <
== La classe Group ==
La classe Group est un simple conteneur. Comme sprite, elle possède une méthode <
Le groupe possède d'autres méthodes comme <
L'autre fonction que vous utiliserez fréquemment est la méthode <
Tel un raccourci, la classe Group contient également une méthode <
Enfin, la classe Group a deux autres méthodes qui vous permettent d'utiliser la méthode interne <
== Utilisation couplée des deux classes ==
Ligne 48 :
La première chose importante est que l'on a un moyen rapide et simple de séparer les sprites en catégories. Par exemple, supposons que l'on ait un jeu de type ''pac-man''. Nous pourrions faire des groupes séparés pour les différents types d'objet dans le jeu, par exemple, un pour les fantômes, un pour pac-man et un pour les pilules. Quand pac-man mange une pilule de puissance, nous pouvons changer l'état de tous les fantômes en agissant sur le groupe des fantômes. C'est plus rapide et plus simple que de boucler à travers une liste de tous les objets du jeu et de vérifier si chacun d'entre eux est un fantôme, puis alors de le modifier.
Ajouter et déplacer des groupes et des sprites est une opération très rapide, plus rapide que d'utiliser des listes pour tout stocker. Ainsi, vous pouvez très efficacement changer les membres d'un groupe. Les groupes peuvent être utilisés pour fonctionner comme de simples attributs pour chaque objet du jeu. Au lieu de suivre un attribut comme <
Un autre bénéfice important apporté par l'utilisation des classes ''Sprite'' et ''Group'' est que les groupes permettent la suppression facile des objets du jeu. Dans un jeu où beaucoup d'objets font référence à d'autres objets, parfois, supprimer un objet peut être très difficile, parce que ça nécessite que sa référence ne soit plus contenue nul part. Supposons que nous ayons un objet qui en ''poursuive'' un autre. Le ''poursuivant'' pourra avoir alors défini un simple groupe qui fait référence à l'objet (ou aux objets) qui il est entrain de poursuivre. Si l'objet ''poursuivi'' est détruit, nous n'avons pas besoin de nous soucier de dire au ''poursuivant'' d'arrêter de le ''poursuivre''. Le ''poursuivant'' pourra voir de lui même que son groupe de ''poursuivis'' est maintenant vide, et pourra chercher une nouvelle cible.
Ligne 65 :
;RenderPlain
:C'est un type dérivé du type Group. Il possède une méthode <
;RenderClear
:Ce type est dérivé du type RenderPlain, et ajoute la méthode <
;RenderUpdates
:C'est la cadillac des groupes de rendu. Il hérite de ''RenderClear'', mais change la méthode <
Voici la liste des différents types de groupe disponibles. Nous discuterons plus longuement de ces groupes de rendu dans la prochaine section. Il n'y a rien qui doive vous empêcher de créer votre propre classe héritée de ''Group'' de cette façon. Ces groupes sont seulement du code python, donc vous pouvez hériter d'un des ces types explicités précédemment et ajouter ou modifier n'importe lequel des attributs ou des méthodes. À l'avenir, j'espère que nous pourrons ajouter quelques types de groupe supplémentaires dans cette liste. Par exemple un GroupMulti qui est comme GroupSingle, mais pourra contenir un nombre fixe de sprites (dans une sorte de buffer circulaire ?). Également un super-render group qui pourra effacer la position d'anciens sprites sans avoir besoin d'une image de fond pour le faire (en mémorisant une copie de l'écran avant le blit). Qui sait, mais dans l'avenir de nouvelles classes utiles seront susceptibles d'être ajoutées à cette liste.
Ligne 79 :
Précédemment, nous avons vu qu'il existe trois groupes de rendu différents. Nous pouvons probablement débuter avec le ''RenderUpdates'', mais il intègre des manipulations supplémentaires qui ne sont pas réellement nécessaires pour un jeu en scrolling, par exemple. Nous avons donc ici plusieurs outils : à chaque type de travail correspond son outil.
Pour un jeu à scrolling, où l'arrière-plan change complètement à chaque image, nous n'avons manifestement pas besoin de nous soucier de la mise à jour des rectangles dans l'appel <
Pour les jeux où l'arrière-plan sera plus statique, vous ne voudriez pas que Pygame régénère entièrement l'écran (surtout qu'il n'y en a pas besoin). Ce type de jeu implique l'effacement de l'ancienne position de chaque objet, et son dessin à un nouvel endroit à chaque image. De cette façon, nous ne changeons que ce qui est nécessaire. La plupart du temps, vous utiliserez la classe ''RenderUpdates'' pour ces types de jeu, puisque vous voudrez passer cette liste de changements à la fonction <
La classe ''RenderUpdates'' effectue aussi un joli travail pour minimiser les zones qui se chevauchent dans la liste des rectangles actualisés. Si la position précédente et la position actuelle d'un objet se chevauchent, la classe ''RenderUpdates'' les fusionnera en un rectangle unique. Combinez ceci avec le fait qu'elle gère proprement les objets supprimés, et vous obtiendrez une classe de Groupe très puissante. Si vous avez écrit un jeu qui manipule les rectangles modifiés pour les objets dans un jeu, vous savez que c'est la cause d'une importante quantité de code ''sale'' dans votre jeu. Spécialement lorsque vous vous lancez dans les objets qui peuvent être effacés à chaque instant. Tout ce travail se réduit à une méthode <
Sachez que rien ne vous empêche de mêler et d'associer ces groupes de rendu dans votre jeu. Vous pouvez finalement utiliser plusieurs groupes de rendu si vous voulez associer vos sprites en couches. Ainsi, si l'écran est séparé en plusieurs sections, peut-être que chaque section de l'écran devra utiliser un groupe de rendu approprié ?
Ligne 93 :
=== spritecollide(sprite, group, dokill) -> liste ===
:Celle-ci contrôle les collisions entre un sprite unique et les sprites d'un groupe. Elle requiert un attribut <
<source lang="python">
Ligne 101 :
</source>
:La fonction recherche tous les sprites du group <
=== groupcollide(group1, group2, dokill1, dokill2) -> dictionnaire ===
:Celle-ci est similaire à la fonction <
<source lang="python">
Ligne 116 :
:Ce code vérifie les collisions entre les balles du joueur et tous les aliens qu'elles ont croisés. Dans ce cas nous bouclons simplement par les clés du dictionnaire, mais nous pouvons aussi boucler par les valeurs ou les items si nous voulons faire quelquechose avec les balles entrées en collision avec les aliens. Si nous bouclons par les valeurs, nous voudrions boucler les listes qui contiennent les sprites. Le même sprite peut toutefois apparaître plus d'une fois dans ces différentes boucles, puisque la même balle peut être entrée en collision avec de multiples aliens.
Ce sont les fonctions de collision fournies avec Pygame. Il devrait être simple de créer vos propres fonctions qui pourraient utiliser quelquechose de différent que les attributs <
== Problèmes connus ==
Actuellement, il existe un problème principal soulevé par de nouveaux utilisateurs. Quand vous dérivez votre nouvelle classe de sprite, vous devez appeler la méthode <
== Dériver vos propres classes (Expert) ==
Ligne 128 :
Les classes ''Sprite'' et ''Group'' sont conçues pour être dérivées, n'hésitez pas à créer vos propres classes ''Group'' pour effectuer des actions spécialisées. La meilleure manière de commencer est probablement le code source du module de sprite. L'examen des groupes ''Sprite'' actuels devrait constituer un bon exemple sur la façon de créer les vôtres.
Par exemple, voici le code source pour un groupe de rendu qui appelle une méthode <
<source lang="python">
Ligne 148 :
Following is more information on how you could create your own Sprite and Group objects from scratch.
Les objets Sprite requièrent uniquement deux méthodes : <
C'est presque les mêmes exigences pour la création de votre propre groupe. En fait, si vous examinez le code source, vous verrez que le ''GroupSingle'' n'est pas dérivé de la classe ''Group'', il implémente uniquement les mêmes méthodes, vous ne pouvez donc pas faire réellement la différence. Une fois encore, vous aurez besoin des méthodes <
Vous devriez lire le code source du module sprite. Là où le code est un peu ''customisé'', il y a suffisamment de commentaires pour vous aider à suivre. Il existe également une section ''todo'' dans le code source, si vous voulez contribuer.
|