Pygame/Guide du dbutant

Un livre de Wikibooks. < Pygame Aller : Navigation, rechercher ou Les choses que j'ai apprises force d'essais et d'erreurs, et que vous n'aurez pas reproduire ou Comment j'ai appris arrter de paniquer et aimer le blit

Introduction Pygame Importation et initialisation Dplacer une image Chimp - Ligne par ligne Introduction au module Sprite Introduction au module Surfarray Guide du dbutant Concevoir des jeux avec Pygame o Code final de Tom's Pong

Traduit de l'anglais, original par David Clark : http://www.pygame.org/docs/tut/newbieguide.html [archive] Pygame est une enveloppe de la SDL [archive] (Simply DirectMedia Layer) pour le langage Python, crite par Pete Shinners. Ce qui signifie que, en utilisant Pygame, vous pouvez crire des jeux ou d'autres applications multimdia en Python qui fonctionneront de manire identique sur toutes les plateformes supportant la SDL (Windows, Unix, Mac, beOS et autres). Pygame peut tre facile apprendre, mais le monde de la programmation graphique peut sembler droutant pour un nouveau venu. J'ai crit ceci pour essayer de rassembler les connaissances pratiques que j'ai acquises tout au long de l'anne passe en travaillant sur Pygame, et son prdecesseur pySDL. J'ai essay de classer ces suggestions par ordre d'importance, mais la pertinence de tel ou tel conseil dpendra de votre exprience personnelle et des dtails de votre projet.

Sections

[masquer]

1 Rgle 1 : Soyez l'aise dans votre utilisation de Python 2 Rgle 2 : Identifiez les parties de Pygame dont vous aurez rellement besoin 3 Rgle 3 : Comprenez ce qu'est une Surface 4 Rgle 4 : Utilisez surface.convert() 5 Rgle 5 : L'animation par dirty_rect 6 Rgle 6 : Il n'y a PAS de rgle 6 7 Rgle 7 : Les surfaces matrielles engendrent plus de problmes que d'avantages 8 Rgle 8 : Ne soyez pas distrait par des questions secondaires 9 Rgle 9 : Les Rects sont vos amis 10 Rgle 10 : Ne vous tracassez pas avec une dtection de collision au pixel prs 11 Rgle 11 : Gestion du sous-systme d'vnement 12 Rgle 12 : Couleur Cl contre Transparence Alpha 13 Rgle 13 : Faites les choses de manire Pythonique

[modifier] Rgle 1 : Soyez l'aise dans votre utilisation de Python

La chose la plus importante est d'tre l'aise avec l'utilisation de Python. Apprendre quelque chose est potentiellement compliqu, et la programmation graphique sera une vraie corve si de plus, vous n'tes pas familier avec le language que vous utilisez.

crivez quelques programmes non-graphiques en python : o un parser de fichiers textes, o un jeu invite de texte, o un programme entre journalire ou d'autres choses de ce style. Soyez l'aise avec la manipulation de chanes de caractres et de listes : sachez comment les dcouper, les slicer et combiner les listes et les chanes. Apprenez comment rutiliser le travail : essayez d'crire un programme qui utilise plusieurs fichiers sources runis. crivez vos propres fonctions, et entranez-vous la manipulation des nombres et des caractres, apprenez comment convertir les nombres en chane et inversement. Venez-en au point o la syntaxe d'utilisation des listes et des dictionnaires est une seconde nature : vous ne devez pas avoir besoin de lire la documentation chaque fois que vous avez besoin de dcouper une liste ou de trier une srie de cls de dictionnaire. Rsistez la tentation d'utiliser une mailing liste, comp.lang.python, irc ou un forum de discussion lorsque vous rencontrerez des problmes. Au lieu de a, saignez votre interprteur et jouez avec le problme quelques heures. Imprimez le guide de rfrence rapide [archive] de Python et gardez le prs de votre ordinateur.

Cela peut vous paratre incroyablement ennuyeux, mais l'assurance que vous aurez gagn en vous familiarisant avec Python, fonctionnera merveille lorsque viendra le moment d'crire votre jeu. Le temps que vous passerez faire de Python votre seconde nature, ne sera rien compar au temps que vous gagnerez lorsque serez entrain d'crire du vrai code.

[modifier] Rgle 2 : Identifiez les parties de Pygame dont vous aurez rellement besoin
tudier le fatras des classes indiques dans l'index de la documentation de Pygame peut tre vraiment droutant. La chose importante est de se rendre compte que l'on peut faire beaucoup avec un petit sous-ensemble de fonctions. Une grande partie des classes disponibles ne seront pas utilises dans un premier temps : en un an, je n'ai pas touch aux modules Channel, Joystick, Cursors, Userrect, Surfarray et leurs diffrentes fonctions.

[modifier] Rgle 3 : Comprenez ce qu'est une Surface

La partie la plus importante de Pygame concerne la manipulation de surfaces. Imaginez-vous qu'une surface n'est qu'un morceau de papier blanc : vous pouvez dessiner des lignes dessus, remplir certaines parties avec de la couleur, et y copier ou en extraire chaque valeurs des pixels qui la constitue. Une surface peut tre de n'importe quelle taille (dans la limite du raisonnable) et vous pouvez en manipuler autant que vous voulez (toujours dans la limite du raisonnable). Une seule surface est particulire : celle que vous crez avec la fonction pygame.display.set_mode(). Cette surface d'affichage reprsente l'cran : ce que vous y faites apparatra sur l'cran de l'utilisateur. Vous ne pouvez en avoir qu'une seule la fois : c'est une limitation de la SDL, pas de Pygame. Donc comment crer des surfaces ? Comme mentionn ci-dessus, vous crez la surface spciale surface d'affichage avec pygame.display.set_mode(). Vous pouvez crer une surface qui contient une image en utilisant image.load(), ou vous pouvez crer une surface qui contient du texte avec font.render(). Vous pouvez galement crer une surface qui ne contient rien du tout avec Surface(). La plupart des fonctions de manipulation de surface ne sont pas d'une utilit critique. Apprenez seulement blit(), fill(), set_at() et get_at() et tout ira bien.

[modifier] Rgle 4 : Utilisez surface.convert()

Quand j'ai commenc lire la documentation de surface.convert(), je pensais ne pas en avoir besoin, car j'utilisais exclusivement le format PNG pour ne pas avoir de problme de format d'image, et donc que je n'avais pas besoin de convert(). J'ai ralis que j'avais vraiment, vraiment tort. Le format auquel convert() fait rfrence n'est pas un format de fichier (comme PNG, JPEG, GIF), c'est ce qui s'appelle l'espace colorimtrique (RGB/HSV/YUV/...). a se rfre la faon particulire qu'a une surface, d'enregistrer les diffrentes couleurs dans un pixel spcifique. Si le format de la surface n'est pas le mme que le format d'affichage, SDL devra convertir la vole chaque blit, ce qui est trs coteux en temps de calcul. Ne vous souciez

pas plus que a des explications : souvenez-vous seulement que convert() est ncessaire si vous ne voulez pas que votre affichage soit ralenti inutilement. Comment devez vous utiliser convert() ? Appelez-la aprs avoir cr une surface avec la fonction image.load(). Au lieu de faire :
surface = pygame.image.load('foo.png')

Privilgiez :
surface = pygame.image.load('foo.png').convert()

C'est simple, vous avez besoin de ne l'appeler qu'une seule fois par surface, lorsque vous chargez votre image depuis le disque et vous serez enchant des rsultats. J'ai remarqu un gain de performance sur les blits de l'ordre de 6x en utilisant la fonction convert(). Les seules fois o vous ne voudrez pas utiliser la fonction convert(), est lorsque vous avez absolument besoin de garder un contrle absolu sur le format interne de l'image - comme par exemple lorsque vous crivez un logiciel de conversion d'image ou s'en approchant, et que vous devez vous assurer que le fichier de sortie possde le mme espace colorimtrique que le fichier d'entre. Si vous crivez un jeu, vous avez besoin de vitesse, donc utilisez la fonction convert().

[modifier] Rgle 5 : L'animation par dirty_rect

La cause principale d'un taux d'images inadquate dans un programme Pygame rsulte d'un malentendu sur la fonction pygame.display.update(). Avec Pygame, le seul trac sur la surface d'affichage n'engendre pas son apparition sur l'cran : vous avez besoin d'appeler la fonction pygame.display.update(). Il existe trois manires d'appeler cette fonction : pygame.display.update() Celle-ci actualise la fentre entire (ou l'cran entier lors d'un affichage en plein cran). pygame.display.flip() Celle-l fait la mme chose, mais devrait tre celle utilise si vous utilisez l'acclration matrielle en double tampon (doublebuffer), que vous n'avez pas, ainsi sur... pygame.display.update(un rectangle ou une liste de rectangles) Cette dernire actualise uniquement les zones rectangulaires de l'cran que vous avez spcifies. La plupart des personnes dbutantes en programmation graphique utilisent la premire : ils mettent jour la totalit de l'cran chaque image. Le problme est que c'est inacceptablement lent pour la plupart des personnes. Appeler update() prends 35 millisecondes sur ma machine, ce qui n'est pas norme, jusqu' ce que vous ralisiez que 1000ms / 35ms = 28 images par secondes maximum. Et ceci sans la logique de jeu, sans blits, sans entres, sans intelligence artificielle, sans rien. Je n'ai simplement fait qu'actualiser l'cran, et 28 images par secondes est mon taux maximal. Hum...

La solution est appele dirty rect animation. Au lieu d'actualiser l'cran entier chaque image, seule la partie qui a chang depuis la dernire image est actualise. J'obtiens ceci en suivant ces rectangles dans une liste, ensuite j'appelle update(the_dirty_rectangles) la fin de l'image. En dtail, pour le dplacement d'un sprite, je : 1. Blit une partie de l'arrire-plan sur l'emplacement actuel du sprite, ce qui l'efface. 2. Ajoute le rectangle de l'emplacement actuel du sprite dans une liste appele dirty_rects[]. 3. Dplace le sprite. 4. Dessine le sprite sur son nouvel emplacement. 5. Ajoute le nouvel emplacement du sprite sur ma liste de dirty_rects. 6. Appelle la fonction display.update(dirty_rects). La diffrence en vitesse est stupfiante. En considrant que Solarwolf [archive] possde des douzaines de sprites en mouvement mis jour de faon fluide, et qu'il lui reste encore assez de temps pour afficher un champ d'toile en parallax en arrire-plan et l'actualiser lui aussi. Il existe deux cas o cette technique ne fonctionne pas. Le premier est lorsque la fentre ou l'cran entier doit tre actualis entirement : pensez un moteur de scrolling fluide comme une vue arienne de jeu de stratgie en temps rel ou un jeu dfilement latral. Alors que faites-vous dans ces cas-l ? Voici la rponse courte : N'crivez pas ce genre de jeu avec Pygame. La rponse longue est de faire dfiler par tapes une grosse quantit de pixels la fois. N'essayez pas d'obtenir un scrolling parfaitement fluide. Vos joueurs apprcierons un jeu qui dfile rapidement et ne vous tiendrons pas trop rigueur sur les sauts de l'arrire-plan. Un dernier mot : tous les jeux ne requiert pas de fort taux de rafraichissement. Un jeu de stratgie, de style wargame, pourrait facilement s'accomoder de quelques images par secondes, dans ce cas, la complexit ajoute par l'animation en dirty_rect ne serait pas ncessaire.

[modifier] Rgle 6 : Il n'y a PAS de rgle 6 [modifier] Rgle 7 : Les surfaces matrielles engendrent plus de problmes que d'avantages
Si vous avez tudi les diffrents drapeaux utilisables dans la fonction pygame.display.set_mode(), vous pouvez vous dire: "Aaah, HWSURFACE ! Cool, c'est ce que j'ai besoin, qui n'utilise pas l'acclration matrielle ? Oooh DOUBLEBUF ! Ca m'a l'air rapide, je pense que je vais l'utiliser aussi !". Ce n'est pas votre faute, nous avons t habitu, par les jeux 3D, croire que l'acclration matrielle est meilleure, et que le rendu logiciel est lent. Malheureusement, l'acclration matrielle engendre une longue liste d'inconvnients :

Elle ne fonctionne que sur certaines plateformes. Les machines Windows peuvent habituellement accder aux surfaces matrielles si vous les demandez. La plupart des autres plateformes ne le peuvent pas. Linux, par exemple, est capable de fournir des surfaces matrielles si Xorg4 est install, si DGA2 fonctionne correctement, et que les

lunes sont correctement alignes (NdT : Ce guide doit dater un peu, a fait quelques temps que les pilotes sont devenus potables. Don't feed the troll ;)). Si les surfaces matrielles ne sont pas disponibles, la SDL vous fournira une surface logicielle la place. Elle fonctionne uniquement en plein cran. Elle complique les accs aux pixels. Si vous avez une surface matrielle, vous avez besoin de verrouiller la surface avant d'crire ou de lire la valeur d'un seul pixel de celle-ci. Si vous ne le faites pas, de mauvaises choses arriveront. Alors vous devrez rapidement dverrouiller la surface, avant que l'OS s'embrouille et commence paniquer. La plupart de ces processus sont automatiss par Pygame, mais ce sont des lments prendre en compte. Vous perdez le pointeur de la souris. Si vous spcifiez HWSURFACE (et que vous l'obtenez), votre pointeur va simplement s'vaporer (ou pire, s'accrocher droite ou gauche et commencer scintiller). Vous aurez besoin de crer un sprite pour le pointeur de la souris, et vous aurez besoin de faire attention l'acclration du pointeur et sa sensibilit. Que de complications... Toutefois, ce pourra tre toujours lent. La plupart des pilotes ne sont pas acclrs pour le type de tra que nous faisons, et puisque que tout doit tre blit travers le bus vido ( moins que vous ne puissiez fourrer votre surface source dans la mmoire vido aussi), a pourra finir par tre aussi lent qu'un accs logiciel.

Le rendu matriel garde son utilit. Il fonctionne de manire fiable sous Windows, si vous n'tes pas intress par des performances multi-plateforme, il peut vous fournir une augmentation substantielle de vitesse. Cependant, il a un cot : augmenter les maux de ttes et la complexit. Il est prfrable de conserver les bonnes vieilles SWSURFACES fiables, jusqu' ce que vous soyez certains de ce que vous faites.

[modifier] Rgle 8 : Ne soyez pas distrait par des questions secondaires

Quelque fois, les programmeurs de jeu dbutants passent normment de temps se soucier de questions qui ne sont pas vraiment critiques au succs de leur jeu. Le dsir de satisfaire des objectifs secondaires est comprhensible, mais au dbut du processus de la cration d'un jeu, vous ne pouvez pas savoir quelles sont les questions importantes, sans parler des rponses que vous devrez choisir. Le rsultat peut engendrer de nombreuses tergiversations inutiles. Par exemple, considrons la question : comment organiser les fichiers de vos graphismes. Estce que chaque image devrait avoir son propre fichier ? ou chaque sprite ? Peut-tre que tous les graphismes devraient-tre zipps dans une archive ? Enormment de temps a t perdu sur beaucoup de projet en posant ces questions sur des listes de diffusion, en dbattant des rponses, en peaufinant, etc. Ce ne sont que des questions secondaires, chaque instant pass discuter devrait tre pass coder le jeu. En rsum, il est de loin prfrable d'avoir une assez bonne solution qui soit mise en oeuvre, plutt qu'une solution parfaite que vous ne savez pas comment coder.

[modifier] Rgle 9 : Les Rects sont vos amis

L'enveloppe de Pete Shinner (Pygame) peut fournir de beaux effets de transparence et de bonnes vitesse de blit, mais je dois admettre que ma partie prfre de Pygame est la modeste classe Rect. Un rect est un simple rectangle, dfini par la position de son coin suprieur gauche, sa largeur et sa hauteur. Beaucoup de fonctions de Pygame prennent des rects en arguments, ou des styles de rects, ou des squences qui ont les mmes valeurs qu'un rect. Ainsi, si je veux un rectangle qui dfinit une zone entre 10, 20 et 40, 50, je peux faire une des choses suivantes :
rect rect rect rect rect = = = = = pygame.Rect(10, 20, 30, 30) pygame.Rect((10, 20, 30, 30)) pygame.Rect((10, 20), (30, 30)) (10, 20, 30, 30) ((10, 20, 30, 30))

Si vous utilisez une des trois premires versions, quelle qu'elle soit, vous aurez accs aux fonctions utilitaires des Rects. Elles incluent les fonctions de dplacement, de diminution et d'agrandissement des rects, de recherche de l'union de deux rects, et d'une varit de fonctions de dtection de collision. Par exemple, je suppose que j'aimerais obtenir une liste de tous les sprites qui contiennent le point (x, y), peut-tre que le joueurs a cliqu ici, ou peut-tre est-ce l'emplacement actuel d'une balle. C'est trs simple si chaque sprite possde un attribut rect, je n'ai qu' faire :
sprites_clicked = [sprite for sprite in toute_ma_liste_de_sprites if sprite.rect.collidepoint(x, y)]

Les Rects n'ont aucune relation avec les surfaces ou les fonctions graphiques, autre que le fait qu'ils les utilisent comme arguments. Vous pouvez les utiliser des endroits qui n'ont rien voir avec le graphisme, mais que vous avez besoin de dfinir comme des rectangles. A chaque projet, je dcouvre de nouvelles faons d'utiliser des rects, l o je n'avais jamais pens en avoir besoin.

[modifier] Rgle 10 : Ne vous tracassez pas avec une dtection de collision au pixel prs
Vous avez donc vos sprites qui se dplacent, et vous avez besoin de savoir s'ils entrent en collison ou non. On peut tenter d'crire quelque chose comme ceci : 1. Vrifier si les rects entrent en collision. Sinon, les ignorer. 2. Pour chaque pixels qui se chevauchent, voir si les pixels correspondant des deux sprites sont opaques. Si oui, il y a collision. Il existe d'autres solutions, en ajoutant des masques de sprites, mais comme vous devez le faire dans Pygame, ce sera probablement trop lent. Pour la plupart des jeux, il sera prfrable de tester une collision de sous-rect : en crant un rect pour chaque sprite qui sera un peu plus petit que l'image actuelle, et l'utiliser pour les collisions. Ce sera bien plus rapide, et dans la plupart des cas, le joueur ne vous tiendra pas rigueur de l'imprcision.

[modifier] Rgle 11 : Gestion du sous-systme d'vnement

Le systme d'vnement de Pygame est quelque peu complexe. Il existe en fait deux manires diffrentes de savoir ce que fait un priphrique d'entre (clavier, souris, joystick). Le premier est de contrler directement l'tat du priphrique. Vous ralisez ceci en appelant pygame.mouse.get_pos() ou pygame.key.get_pressed(). Ceci vous donnera l'tat du priphrique au moment de l'appel de la fonction. La seconde mthode utilise la file d'vnement de la SDL. Cette file est une liste d'vnement : les vnements sont ajouts la suite de la file lorsqu'ils sont dtects, et ils sont effacs de la file lorsqu'ils ont t consults. Il y a des avantages et des inconvnients pour chaque systme. Le contrle d'tat (systme 1) vous donne la prcision : vous savez exactement quelle entre a t effectue, si mouse.get_pressed([0]) est vrai, a signifie que le bouton gauche de la souris est actuellement enfonc. La file d'vnements, elle, ne fait que rapporter que le bouton de la souris a t enfonc un certain moment dans le pass. Si vous vrifiez la file relativement souvent, a fonctionnera, mais si vous tardez la consulter, la latence peut s'agrandir. Un autre avantage du systme de contrle d'tat est qu'il dtecte facilement les accords de touches : qui sont plusieurs tats au mme moment. Si vous voulez savoir si les touches T et F sont press en mme temps, il suffit de vrifier :
if (key.get_pressed[K_t] and key.get_pressed[K_f]): print "Yup!"

Toutefois, dans le systme de file, chaque pression de touche entre dans la file comme un vnement compltement spar, ainsi, vous devez vous rappeler que la touche T est enfonce et n'a pas encore t relache lorsque vous contrlez l'tat de la touche F. Un peu plus complexe. Le systme d'tat possde toutefois une grande faiblesse. Il rapporte seulement quel est l'tat d'un priphrique au moment o il est appel. Si l'utilisateur enfonce le bouton de la souris et qu'il le relache juste avant que l'appel mouse.get_pressed() soit fait, le bouton de la souris retournera 0. La fonction get_pressed() rate compltement la pression du bouton de la souris. les deux vnements, MOUSEBUTTONDOWN et MOUSEBUTTONUP seront toutefois, toujours dans la file d'vnements, attendant d'tre retrouvs et mis en application. La leon retenir est : choisissez le systme qui convienne vos besoins. Si vous n'avez pas beaucoup de continuit dans votre boucle, c'est--dire que vous attendez une entre, dans une boucle while 1:, utilisez la fonction get_pressed() ou une autre fonction d'tat, la latence sera rduite. D'un autre cot, si toutes les touches enfonces sont cruciales, mais que la latence n'est pas importante, comme par exemple si l'utilisateur est entrain d'crire quelquechose dans une boite d'dition, utilisez la file d'vnement. Certaines pressions de touches pourront tre un peu en retard, mais au final, vous les aurez toutes. Un mot propos de la diffrence entre les fonctions event.poll() et event.wait() :

peut sembler meilleure, puisqu'elle n'interdit pas votre programme de faire autre chose que d'attendre une entre. wait() suspend la programme jusqu' ce qu'un vnement soit reu.
poll()

Toutefois, poll() utilisera 100% de la charge du processeur lors de son fonctionnement, et il remplira la file d'vnements avec des NOEVENTS. Prfrer l'utilisation de la fonction set_blocked() pour slectionner uniquement les types d'vnements qui vous intressent, votre file n'en sera que plus grable.

[modifier] Rgle 12 : Couleur Cl contre Transparence Alpha

Il y existe de nombreuses confusions autour de ces deux techniques, et beaucoup proviennent de la terminologie utilise. Le blit par Couleur Cl implique de dire Pygame que, dans une certaine image, tous les pixels d'une certaine couleur (la Couleur Cl en question) apparatront comme transparents au lieu de s'afficher dans leur vraie couleur. C'est de cette faon que l'on cre un sprite qui n'apparaissent pas dans un rectangle. Il suffit d'appeler la fonction surface.set_colorkey(color), o color est un 3-uplets RGB, comme par exemple (0,0,0). Ceci fera que tous les pixels noirs de l'image source apparatront comme transparents. La Transparence Alpha est diffrente, et implique deux gestions diffrentes. Image Alpha s'applique toute l'image et correspond probablement ce que vous dsirez. Connu aussi sous le nom de translucidit, le canal alpha applique chaque pixel de l'image source une opacit partielle. Par exemple, si vous dfinissez le canal alpha d'une surface 192, et que vous le blitez sur un arrire-plan, 3/4 de la couleur de chaque pixel proviendra de l'image source et 1/4 de l'arrire-plan. Le canal alpha se mesure de 255 0, o 0 est compltement transparent et 255 est compltement opaque. A noter que la Couleur Cl et le blit Transparence Alpha peuvent tre combins : cela produit une image qui est compltement transparente sur certains pixels et semi-transparente sur d'autres. La Transparence Alpha par Pixel est la seconde gestion du canal alpha, et est plus complexe. Concrtement, chaque pixel d'une image source possde sa propre valeur de canal alpha, de 0 255. Chaque pixel peut donc avoir une opacit diffrente lorsqu'ils sont blits sur un arrireplan. Ce type d'alpha ne peut pas se combiner avec une couleur cl et il dsactive l'autre gestion de la Transparence Alpha. La Transparence Alpha par Pixel est rarement utilise dans les jeux, et pour l'utiliser vous devez enregistrer vos images sources l'aide d'un diteur graphique qui gre le canal alpha. C'est compliqu, ne l'utilisez pas pour l'instant.

[modifier] Rgle 13 : Faites les choses de manire Pythonique

Un dernier mot (ce n'est pas le moins important, c'est seulement le dernier). Pygame est une enveloppe plutt lgre de la SDL, qui elle-mme est une enveloppe plutt lgre des appels graphiques de votre OS. Si votre code est encore lent, et que vous avez appliqu les choses que j'ai mentionne plus haut, il y a de fortes chances que le problme vienne de la faon dont vous avez adress vos donnes en Python. En Python, certains idiomes resteront lents, quoi que vous fassiez. Heureusement Python est un langage trs clair - Si une partie du code vous semble maladroite ou difficile manier, il y a de fortes chances qu'elle puisse tre optimise en vitesse. Lisez Python Performance Tips [archive], pour trouver de prcieux conseils sur la faon dont vous pouvez augmenter la vitesse de votre code. Ceci dit, une optimisation

prmature est foncirement mauvaise, si ce n'est pas assez rapide, ne torturez pas le code pour l'acclrer. Certaines choses ne sont pas censes l'tre :) Alors voil, maintenant vous en savez pratiquement autant que moi sur l'utilisation Pygame. Maintenant allez crire votre jeu !

David Clark est un utilisateur avide de Pygame et l'diteur du Pygame Code Repository [archive], une vitrine de codes de jeu Python soumis la communaut. C'est galement l'auteur de Twitch [archive], un jeu d'arcade entirement fait avec Pygame