Ludum Dare 47 post-codem

Comme annoncé dans mon précédent article, j’ai participé au Ludum Dare. Vous pouvez jouer à ma contribution directement par ici.

La tradition dans les game jams est d’écrire un « post-mortem », c’est un petit (grand) texte que l’on écrit à tête reposée après avoir bossé comme un oufzor pendant tout un week-end à créer un jeu.

Je trouve l’expression « post-mortem » étrange. Je ne suis pas mort, même si ça a été assez intense et que j’en suis sorti fatigué. Donc : « post-codem ».

Fonctionnement du jeu

Les premiers retours m’indiquent que c’est difficile à prendre en main au départ. J’ai donc fait une petite vidéo de démo explicatoire. J’y parle anglais, c’est une catastrophe. Vous avez le droit de mettre en mute.

L’aire de jeu est une piscine qui se recouvre entièrement de boue et de lierre (les petits traits verts). Vous sélectionnez une première case, en appuyant sur le bouton « 1 », puis vous en sélectionnez une deuxième, et elles s’échangent. Le but est de construire, par échanges successifs, des boucles fermées de lierre, ce qui déclenche la suppression de la boue qui est à l’intérieur.

Il faut commencer par créer une boucle à côté de la fontaine d’eau en haut à gauche. L’eau avance lorsqu’elle est en contact avec une zone sans boue. Vous devez la propager petit à petit jusqu’à l’arrivée en bas à droite.

Vous ne pouvez pas échanger une case si elle n’est pas unie, c’est à dire ayant un mix de boue et d’eau. C’est gênant lorsque vous avez deux boucles proches : vous ne pouvez pas créer de mini-boucle entre les deux pour les fusionner. J’ai donc ajouté un pouvoir spécial, lorsque vous activez le bouton « 2 » sur une case comportant de la boue, un trait vert se rajoute, qui peut vous permettre de finaliser une boucle.

Par le pouvoir du lierre !!

Post-codem au sujet du jeu

Le thème était : « Stuck in a Loop », c’est à dire : « Coincé dans une boucle ».

Il y a deux modes de participation au Ludum Dare :

  • Jam : vous avez 3 jours pour créer un jeu vidéo, en équipe ou en solo. Vous pouvez réutiliser des images, des sons et des codes existants (en respectant les licences et autres fucking copyright, évidemment).
  • Compo : c’est le « hard mode ». Vous n’avez que 2 jours, en solo. Tous les éléments de votre jeu doivent être originaux et doivent avoir été créés durant ces 2 jours. Obligation de partager le code source. Mais vous pouvez utiliser des outils de création privatifs (Unreal Engine, par exemple).

J’ai choisi compo. C’est pas que je veuille me la péter en démarrant directement en hard mode. C’est juste que j’avais mon week-end de dispo, mais pas le lundi après. Et les autres contraintes de la compo me convenaient.

Bien entendu, je n’ai pas eu le temps de réaliser toutes les idées que j’avais. Ça arrive à chaque projet (artistique ou non). Comme c’est systématique, on sait à l’avance qu’on ne pourra pas tout faire, on peut donc diminuer ses prétentions dès le départ. Mais même ainsi, les prétentions restent trop grandes, et on finit toujours par finir à l’arrache.

Ouais, à la

Comme dirait Helmut : voilà un jeu de mot franco-allemand qui Kohl très bien à l’article.

Échec de la continuous delivery

J’ai tellement galéré à coder (j’explique pourquoi dans le dernier chapitre de cet article), que ce n’est que le dimanche à 12h que j’ai eu une version pre-pre-alpha, comportant uniquement la fonction d’échange et la détection des boucles.

Note pour les prochains Ludum Dare : se réserver des petites plages de temps pour tester et faire tester son jeu par des gens quelconques. Ça permet d’ajuster la difficulté et éventuellement de glaner de nouvelles idées.

Ce que j’avais imaginé au début : coder un petit bout de truc, le montrer aux gens qui vivent avec moi, même si ça ne constitue pas un vrai jeu, montrer le bout de truc suivant, et ainsi de suite. On aurait avancé tous ensemble durant le week-end, ces mini-démonstrations régulières auraient permis de me faire pardonner le fait que je me serait comporté en geek pendant 48 heures.

Au lieu de ça, j’ai passé les trois premiers quarts du week-end à grogner devant mon ordinateur. Lorsque quelqu’un venait me voir, je lui grognais que rien ne marchait. Pas très interactif.

Groumpf ! A marche pô !

Échec de l’explication du mécanisme du jeu

J’avais prévu de faire un petit tutoriel, qui s’est terminé en un pseudo-manuel écrit en 20 minutes, sous forme de docstring au début du code python. J’ai ensuite pseudo-copié-collé ce manuel pour le mettre dans la description Ludum Darienne.

Ça n’aide pas trop à comprendre le fonctionnement du jeu quand on le découvre. D’où la petite vidéo que j’ai faite après. Qui est elle-même créé à l’arrache, mais ça c’est parce que j’ai très peu d’expérience dans ce domaine. Je cause très mal anglais alors que d’habitude en vrai conversation je m’en sors potablement. De plus, on m’entend prendre de grandes inspirations avant chaque phrase. C’est malaisant.

Même la longueur de la vidéo est une erreur. J’explique tous les mécanismes du jeu durant les 4 premières minutes, puis je passe 6 minutes à terminer ma partie. Lorsque les ordispectateurtrices-joueureuses arrivent sur ma page Ludum Darienne, ces personnes voient une vidéo ayant une durée de 10 minutes. Elles ne la regardent pas forcément, parce que c’est trop long. Si la durée affichée avaient été plus courte, il y aurait eu plus de chances qu’elles cliquassent sur « play », parce que gâcher 4 minutes de sa vie dans notre monde actuel est quelque chose d’encore à peu près acceptable. Ce serait d’ailleurs intéressant de connaître la probabilité de clic sur un bouton « play » en fonction de la durée d’une vidéo, mais ce n’est pas le sujet.

Les graphismes sont manifestement beurkys. Les explications du jeu utilisent le terme « vines » (du lierre), il faut comprendre que ça correspond aux traits verts. Ces traits sont une représentation métaphysique aristotélicienne du lierre quand on n’a pas eu le temps de le dessiner correctement.

Possible échec de la promotion de Squarity

Cette participation au Ludum Dare, et les futures participations à d’autres game jams, n’ont pas pour but de créer un jeu génial qui sera premier au classement et restera dans la mémoire de l’humanité (même si ça me plairait bien). Le but est de promouvoir Squarity.fr, ma plate-forme de création et partage de jeux.

Je veux provoquer chez les Ludum Daristes une réaction de type :

« Voyons voir ce jeu… Moui bof. Pas génial.

Oh, mais quelle est donc ce site web étrange… Squarity ? Mais que vois-je dans la partie droite ? Une fenêtre de texte avec du code python dedans, et d’autres informations qui semblent définir le jeu auquel je suis en train de jouer !

Que va-t-il se passer si je change des trucs et que je clique sur le bouton de validation en-dessous ? Oh bon sang ! Le jeu se modifie instantanément ! Ce site est génial ! Je vais de ce pas m’en servir pour créer tous mes prochains jeux. Je participe au Ludum Dare, c’est bien que je veux créer des jeux pour le restant de ma vie !

Mon avenir sera squaritien ou ne sera pas ! »

Pour provoquer une telle réaction, il faut bien entendu que Squarity soit amélioré (ce qui se fera progressivement), mais la moindre des choses aurait été que je commente mon code python, afin d’aider le monde à comprendre son fonctionnement, et par là même le fonctionnement de Squarity.

J’ai échoué sur ce point, mon code est cradingue et très peu documenté. J’essayerais d’arranger ça dans les jours à venir. Et puis je voulais aussi créer un mini-jeu tutoriel de Squarity. Tant de choses à faire, comme d’habitude…

Les carrés sont l'avenir du monde

Succès de la fontaine !

J’avais prévu d’afficher la quantité de mana sous forme d’une jauge dans un coin de l’aire de jeu. Mais en me levant le dimanche matin, j’ai eu une idée géniale : Squarity ne permet que d’afficher des images, mais la transparence est gérée. Lorsque le mana est bas, je peux noircir la fontaine en superposant plus ou moins de pixels noirs transparent dessus !

Pas besoin de perdre de temps à dessiner une jauge de mana et à coder des choses compliquées pour l’afficher. Avec 4 lignes de code dégueux et un seul sprite supplémentaire (créé rapidement à partir du sprite de la fontaine, en mettant tous ses pixels en noirs-transparents), j’avais un indicateur de mana bien mieux intégré dans le jeu.

Pour fignoler le tout, j’ajoutais un petit log indiquant la quantité exacte de mana lorsqu’on sélectionne la fontaine.

À droite de la fontaine se trouve l’image correspondant à son « ombre ».
if self.pool_mana < 100:
    nb_fountain_darking = (100 - self.pool_mana) // 5
    for _ in range(nb_fountain_darking):
        gamobjs.append("darkfountain")

Je vois aussi cette fontaine comme un très très lointain clin d’œil à l’un de mes jeux préférés intemporels et intraspatial : Might and Magic – World of Xeen.

Alamar, you misguided mechanism ! You’ll destroy us all !

N’ayant pas peur de faire de la surenchère, je rajoutais un autre lointain clin d’œil à World of Xeen : dans le pseudo-scénario de mon jeu, le personnage de la « Countess du Swagging » est une référence au mot de passe secret « Count Du Money ».

Cette fontaine est un auto-clin d’œil, puisque c’est le logo de New World Computing

Si jamais je continuais le dev de ce jeu

Je note ici toutes les idées que je pourrais rajouter dans une hypothétique version post-ludum.

Faciliter le début en pré-plaçant du lierre

Si on n’a pas de bol, on commence comme ça :

Peu de lierre partent de la zone d’eau. Pour y coller des boucles, on risque d’être obligé d’utiliser le pouvoir d’ajout de lierre. Or c’est un pouvoir qui coûte assez cher en mana, car on ne devrait normalement l’utiliser qu’en dernier recours.

J’aurais dû ajouter automatiquement quelques connexions partant de la zone d’eau. Quelque chose comme ça :

C’est beaucoup plus facile de tracer un chemin depuis le trait vertical qui est sous la zone jusqu’au trait diagonal, ou bien depuis le trait horizontal à droite jusqu’au trait diagonal, et ainsi créer une première boucle sans s’arracher les cheveux.

Une « learning curve » moins violente

Il faudrait ajouter des niveaux. Les premiers seraient rendus plus facile par :

  • un tutoriel,
  • des maps plus petites,
  • des délimitation de cases plus marquées,
  • l’absence de traits diagonales.

J’ai eu beaucoup de remarques au sujet des délimitation de cases. Les gens analysent la map, repèrent une case qui leur convient, et s’aperçoivent ensuite que ce n’en est pas une mais que c’est 4 coins de 4 cases différentes. J’avais fait exprès de brouiller les limites entre les cases parce que je trouvais ça cool et j’aime créer des choses difficiles pour ensuite prendre un air condescendant auprès des gens qui n’y arrivent pas. Mais peut-être que j’ai overkillé.

Alors que les grands comédiens gomment les coupures entre vers lorsqu’ils déclament des alexandrins, je gomme les coupures entre cases lorsque je crée des jeux grid-2D.

J’embroche vos rimes, mon épée vous tru-Cid.

Un monde ouvert

Il y aurait une aire de jeu plus grande que ce que peut afficher l’écran. On ne pourrait pas scroller partout. On aurait un personnage et le scroll serait limité autour de lui. On pourrait déplacer ce personnage uniquement vers une case recouverte d’eau. Pour progresser dans le monde, il faudrait donc faire des boucles et propager l’eau petit à petit.

Par contre, ça gâcherait un peu si on permet de faire des boucles géantes, et surtout il y aurait le risque que le temps de calcul de vérifs des boucles soit trop long. Donc il faudrait limiter les tailles de boucle. Ce qui pourrait être sujet à des bonus : au début on ne peut faire que des boucles ayant une longueur de 5, puis 6, puis 7, etc.

Bien entendu, ce grand monde ouvert serait truffé de bonus, de mana, de sorts et de pouvoirs à gagner. Pour récupérer quelque chose, il faudrait amener son personnage dessus, donc l’entourer avec une boucle.

Et puis des passages secrets et des zones super compliquées à atteindre. Par exemple un grand couloir de 3 cases de large avec un super bonus au bout.

Je voulais aussi faire une super blague, avec un genre de quête annexe. Une map où l’objectif serait à côté du point de départ, mais il y aurait un grand mur entre les deux. Il faudrait faire tout un détour pour l’atteindre. À la fin, le personnage aurait dit : « j’ai du créer toutes ces boucles de lierre juste pour parcourir une grande boucle qui me ramène à mon point de départ ! WTF ? ». Haha, lolilol potentiel.

D’autres idées en vrac

L’échange entre une case de boue et une case d’eau ne coûterait pas de mana, mais ne ferait que déplacer les lierres de l’eau sur la case de boue. On perdrait les lierres de boue. Ça nettoie la piscine et ça encourage à étendre l’eau le plus possible, pour conquérir des lierres qu’on pourra ensuite placer gratuitement.

Des statistiques :

  • longueur & surface de la plus grande boucle réalisée,
  • nombre de boucle créées en une seule action,
  • maximum de mana atteint,
  • rentabilité (mana gagné / mana dépensé),
  • nombre de case d’eau créées,
  • etc.

Et bien sûr, des achievements et des bonus liés à ces stats.

Des robots

Quand on fait une boucle, ça ne supprime pas immédiatement la boue. Il faut poser des petits robots nettoyeurs qui enlèvent la boue autour d’eux. Ils fonctionnent pendant un temps limité. Donc si on les pose sur une boucle trop grande, ils ne nettoieront pas tout et la boue se repropagera dans la boucle. Si on les pose sur une boucle plus petite, ils nettoient tout, la boue ne se propage pas car elle ne peut pas traverser les lierres. On peut alors déclencher la propagation de l’eau vers la boucle nettoyée.

C’est une idée qui reste à finaliser. Parce qu’actuellement, l’eau peut passer à travers le lierre. Donc si on commence à nettoyer une boucle avec des robots, l’eau peut alors se propager tout de suite dans une boucle dont le nettoyage n’a pas été terminé, et ça peut donner n’importe quoi.

Ou alors on dit que l’eau ne passe pas le lierre. Et on doit enlever manuellement le lierre qui sépare l’eau de la boucle nettoyée. À réfléchir si on a envie.

Je laisse cette idée là où elle est, j’ai peur d’avoir embrouillé tout le monde en la décrivant.

Robot nettoyant la boue (à moins que ce soit l’inverse)

Post-codem concernant Squarity

Voici maintenant mes retours en tant que simple utilisateur/créateur de cette plate-forme de jeu.

Les messages d’erreur, rogntudjuu !

Comme l’a si bien dit 10kbis en commentaire de mon précédent article, il faut les messages d’erreur et les tracebacks !

Quand le code du jeu plante à l’initialisation, le message s’affiche comme il faut dans la console du navigateur. Mais quand ça plante pendant l’exécution d’une callback, on a que d’alle. On ne sait pas où ça a planté, ni pourquoi. Je n’ai pas encore pris le temps de régler ce problème.

Je pensais être capable de coder du python sans visibilité sur les messages d’erreur. Je m’étais dit : « je suis super fort, et au pire, je pourrais toujours débuguer à coups de print ».

Débuguer à l’aveugle, c’est ce que j’ai fait pendant tout le week-end. C’est la raison pour laquelle je n’ai eu une version pre-pre-alpha que très tard. Ça m’a aussi mis de sérieux doutes sur ma capacité à sortir quelque chose de jouable avant la fin.

J’avais prévu, après le Ludum Dare, de me poser un peu concernant le dev, faire un semblant de road-map, nettoyer et documenter un peu mon code. Mais là, nope. Avant de faire tout ça, il faut que je règle cette non-gestion des erreurs.

Bien. Il me reste 12h pour faire tout le reste et j’ai pas encore mangé.

Ajouter les événements de clics de souris

Je m’étais promis que pendant le Ludum Dare, je m’occuperais uniquement du jeu, sans mettre à jour le site Squarity. Je voulais prouver que la présente version est suffisamment aboutie pour créer un jeu, même très simple, même avec beaucoup de galère.

Puis j’ai réalisé que Loops in Pool serait beaucoup plus pratique si on pouvait directement cliquer sur les cases. Alors j’ai décidé que je ferais une entorse à ma promesse et que je rajouterais à la va-vite la gestion des clics dans Squarity.

Finalement, je n’ai pas du tout eu le temps de faire ça. Je suis donc parvenu à être suffisamment à l’arrache pour tenir ma promesse. Youpi !

Ayez l’amabilité de bien vouloir gérer ce mulot, mon brave.

Ça peut être très lent

Exécuter du python dans un navigateur web, c’est lent. Je m’en doutais un peu, mais je ne pensais pas que ça se révélerait dès maintenant.

Lorsqu’on échange deux tiles, il faut attendre une ou deux secondes avant de pouvoir faire autre chose. C’est le temps pour vérifier si l’échange a créé une boucle ou pas. On exécute pour cela un algo pourri de Dijkstra sur 2240 pauvres petits nodes. Ça devrait se faire instantanément, or ce n’est pas le cas.

C’est pour ça que la boue se remplit progressivement au début. Si je calculais toute la propagation dès le départ, ça prendrait vachement de temps et on pourrait croire que le jeu ne marche pas.

Heureusement, quand on fait des jeux simples nécessitant peu de traitement, il n’y a aucun problème, le jeu du magicien et H2O en sont des preuves. Mais il ne faut pas trop abuser.

Je n’ai pas de solution miracle pour ce problème, juste des pistes :

  • Faire des tests de performances, en déduire des manières de coder plus rapide que d’autres et les documenter dans des bonnes pratiques. Je suppose que le python dans un navigateur se code et s’optimise différemment par rapport au python normal.
  • Essayer de faire des traitements parallèles ou asynchrones. Je ne sais même pas si on peut faire ça proprement dans un navigateur web, que ce soit en javascript ou en python.
  • Mesurer en live les performances du code, pour repérer les parties de code les plus ralentisseuses.
  • Optimiser l’affichage. Au lieu de redessiner toutes les tiles à chaque fois, on en marque certaines comme « dirty ». Seules celles-là seront redessinées. Mais, je ne suis pas sûr que ça améliore grandement la vitesse.

D’autre part, j’ai fait une modif qui me semble cool : j’ai redirigé les print. Normalement, ils vont dans la console du navigateur. Moi je les affiche dans la zone de texte en bas à gauche. Figurez-vous que ça aussi, ça ralentit tout. Faites une dizaine de print à chaque appui de bouton : ça devient horrible, même dans un jeu simple.

Je ne sais pas pourquoi. Est-ce que le navigateur doit recalculer tout le DOM à chaque fois qu’on écrit dans un élément <textarea> ? Ce serait embarrassant. En attendant, l’effet de bord est très amusant : le seul moyen actuel de débuguer est de faire des prints, mais les prints ralentissent tout. Bon courage !!!

Je ne parviendrais peut-être pas à régler ce gros défaut de lenteur, ce qui risque de bloquer des créateurtrices potentieleulleux dans la réalisation de leurs jeux.

Ça ne me fera pas abandonner ce projet, ni déroger de mon idée principale : créer et partager des jeux 2D en python dans un navigateur web. C’est ce que je veux faire, et plus que ça, c’est aussi ce que j’ai envie d’avoir. Je veux utiliser mon propre outil pour créer une foisonnance de jeux bizarres/amusants/pulpesque/dérangeants/moches/etc. Bref, des jeux que je veux voir exister.

Un jeu « pulpe-zinesque » créé par Anna Anthropy, dont je vous parlerai à l’occasion

Autres trucs-en-vrac

Il faut des sons et de la musique. C’est prévu, mais les conseils que j’ai pu récolter à l’occasion du Ludum Dare me confirment que c’est très important pour se démarquer. Si j’avais pas un tas de choses déjà prioritaires, je prioriserai les sons.

Les images des objets ne peuvent pas déborder de leur tile. On peut faire sans, mais pour dessiner un trait qui rejoint deux tiles en diagonale, il faudrait pouvoir placer quelques pixels sur les tiles diago-adjacentes. Ça mériterait un petit dessin pour vous expliquer, mais là, pfouf, cet article est déjà bien assez long.

L’image de tileset devrait pouvoir être uploadée depuis le disque en local, dans le navigateur (en local aussi, du coup). Actuellement, il faut publier l’image sur un site d’hébergement, et ce à chaque changement. Même si on ne souhaite pas publier son jeu. C’est relou. En ce qui me concerne, je met l’image dans un repo github. Mais les push d’images dans github ne sont pas instantanément mis à jour dans leur site web.

Tôt ou tard, il me faudra un lieu d’échange et de création de contenus autour de Squarity (articles, documentation, tilesets, jeux, …). Je me permettrais de commencer par un tout petit truc. Mais il me le faut vraiment ce petit truc, car actuellement j’ai rien du tout, à part des comptes sur des rézosociaux « annexes », comme ce blog. Or, ces comptes n’ont pas pour utilité principale de décrire Squarity. Il va falloir que je me lance dans un mini-CMS Django, et/ou une instance Mastodon, ou autre chose de mieux si vous avez une idée.

Rappelons que l’utilité principale de ce blog est de vous faire découvrir des images de femmes rondes. Ceci ne va pas changer de sitôt. À ce sujet je vous présente llindaa23

À la prochaine, je me remet sur mon code et mes gestion d’erreurs.

Découvrir le python – chapitre 3 – list’oire de la vie

Le titre de l’article est une blague par rapport à la chanson naze et bien-pensante du Roi Lion : « C’est l’histoâââââre de la viiiiiiiie ». Ce troisième article de découverte du python a pour sujet principal : les listes.

Je tenais à expliquer cette blague, car quand on explique une blague, elle n’est plus drôle. Mais quand une blague est pas drôle dès le départ et qu’on l’explique, ça devient drôle.

Avant tout, pif paf la solution au devoir du précédent article. C’était plus un travail de géométrie que de programmation. Des fois, on croit qu’on fait un truc et on en fait un autre. C’est comme ça la vie, jeune lecteurtrice. L’histoâââre de la viiiiieeeuuuuu.

De la couleur

Remet-toi sur le site Trinket, ajoute les deux instructions habituelles du début : « import turtle », « turtle.speed(0) ».

Ensuite, tu copie-colles la fonction « dessiner_diams » créée dans l’article précédent (tu peux la récupérer dans la correction du devoir).

Pour finir, ajoute une seule ligne après la fonction, dans le programme principal : « dessiner_diams(0, 0, 50) ». On est devenu des prolos et on fait des petits diamants.

On est des prolos, mais on n’est pas forcément des communistes. On voudrait pouvoir faire des diamants ayant une autre couleur que ce rouge pétaradant.

Tu as certainement déjà repéré la ligne de code de la fonction spécifiant que le diamant est rouge. Pour les anglophonophobes, je rappelle que « red » signifie « rouge ». Indique une autre couleur à la place : « green », « blue », …

C’est top-de-la-housse, mais ça ne permet pas de dessiner des diamants de couleurs différentes.

Alors tu vas appliquer la même méthode que dans l’article précédent, lorsqu’on avait ajouté le paramètre « taille » :

  • Ajoute un paramètre supplémentaire dans la fonction « dessiner_diams ». On va l’appeler « couleur ».
  • Utilise ce paramètre dans le corps de la fonction. À toi de trouver où il faut le mettre et à la place de quoi.
  • Ajoute ce paramètre lorsque tu appelles la fonction, dans ton programme principal.

On va profiter de cette souplesse supplémentaire que tu viens de conférer à ta fonction (lecteurtrice, tu te rends compte que tu con-faire ? Tellement génial). Remplace la ligne du programme principal par ces deux lignes :

dessiner_diams(0, 0, 50, "green")
dessiner_diams(25, 25, 50, "blue")

Et voilà !

Lien vers la solution si t’as perdu tes couleurs.

De la couleur RVB

Les couleurs c’est fun et bigarré, mais c’est chiant de devoir les identifier par des noms, surtout en anglais. C’est un coup à ce que ça parte en bastonnade entre d’éminents chromatologues qui se crêperont l’arc-en-ciel sur la différence entre le cyan et le turquoise. Encore heureux que turtle ne reconnaît pas le fuschia, sinon je vous dis pas le bordel ! Personne ne connaît vraiment ce mot.

Il existe une manière plus standard de définir les couleurs en informatique. On indique trois nombres, correspondant aux quantités des trois couleurs primaires : rouge, vert et bleu.

Je t’entends protester d’ici, lecteurtrice : « han mais n’importe quoi, mon prof de dessin il m’a dit que les couleurs primaires c’est rouge, bleu et jaune ! ». Alors je te répondrai d’écouter ton prof mieux que ça, car il a plutôt dit que les couleurs primaires sont magenta, cyan et jaune. Finalement, je te répondrais que ça dépend si on est en synthèse additive ou en synthèse soustractive. Écris ces termes dans un moteur de recherche si tu veux en savoir plus.

Si tu as joué avec des logiciels de dessins, tu connais déjà les sélecteurs de couleurs. En voici un disponible en ligne : https://lehollandaisvolant.net/tout/tools/color/ .

Choisis la couleur que vu veux et retiens les trois nombres de la ligne « RGB » (Red Green Blue).

Dans ton code python, tu peux écrire ces trois nombres à la place du nom de la couleur. Mais attention, il faut mettre des parenthèses pour les délimiter. Par exemple :

dessiner_diams(0, 0, 50, (42, 234, 69))

« dessiner_diams(0, 0, 50, 42, 234, 69) », ça ne marcherait pas.

Miss Diamond Doll, puisqu’on reste sur les diamants

Tuple et zante ?

Pourquoi il faut des parenthèses en plus ?

La couleur ne doit constituer qu’un seul paramètre. Mais celui-ci peut être de type simple (un texte entre guillemet), ou de type composé.

Ces trois nombres entre parenthèses définissent une valeur de type tuple. « Tuple » est le mot générique pour dire un couple / un triplet / un quadruplet / un n-uplet.

Pour toutes les fonctions de la librairie turtle nécessitant des couleurs dans leurs paramètres, on peut indiquer un texte correspondant à un nom de couleur valide, ou bien un tuple de 3 entiers. Une conversion est effectuée en interne dans turtle.

Les tuples sont des types de valeurs comme les autres, tu peux donc les mettre dans des variables :

ma_couleur = (42, 234, 69)
dessiner_diams(0, 0, 50, ma_couleur)

Et aussi utiliser des variables numériques comme composantes d’un tuple:

le_rouge = 42
le_bleu = 69
# J'ai la flemme de créer la variable pour le vert.
dessiner_diams(0, 0, 50, (le_rouge, 234, le_bleu))

Plus d’infos sur les tuples dans cette chouette documentation : https://courspython.com/tuple.html

Profitons de cette nouvelle connaissance et réalisons un joli dégradé de couleur.

Tu me fais une boucle qui dessine 100 diamants :

  • La coordonnée X varie de 5 en 5, en partant de -200 : -200, -195, …
  • La coordonnée Y reste à 0.
  • La taille reste à 50.
  • La couleur rouge reste au maximum, c’est à dire 255.
  • La couleur verte reste à 0.
  • La couleur bleue varie de 2 en 2, en partant de 50 : 50, 52, 54, …., 246, 248.

Ça donnera un magnifique dégradé :

Lien vers la réponse, si ton cerveau s’est dégradé.

Vous êtes l’éliste de la nation

Tu vas mettre en commentaire ta belle boucle du chapitre précédent, car on va partir sur autre chose. Nous arrivons enfin au sujet majeur de cet article : les listes.

Dans le programme principal, juste après la définition de la fonction dessiner_diams, tu vas créer une liste contenant quelques nombres :

ma_liste = [-70, 38, 45, -20, 113]

Tu peux parcourir cette liste à l’aide d’une boucle. En voici une toute simple, je te laisse deviner ce que ça fait :

for elem in ma_liste:
    print(elem)

On retrouve la même syntaxe que pour les autres boucles : for {bidule} in {truc}:

Sauf que cette fois-ci, le {truc} que tu parcoures n’est pas une fonction « range » qui ne fait que compter. C’est une liste, avec tout et n’importe quoi dedans.

Lecteurtrice, je vois bien, à ton œil mouillé et ton air rébarbatoire, que tu as envie de me poser une question qui dérange :

« Wesh, auteurtrice, c’est quoi l’intérêt d’avoir inventé deux types : les listes et les tuples ? Ils font la même chose : stocker une suite d’éléments. »

Eh bien voilà : les tuples ne peuvent pas changer de contenu. Les listes, si. On peut y ajouter ou enlever des éléments, en remplacer un par un autre, etc.

Re-lecteurtrice, je te revois bien me redemander :

« Re-wesh, à quoi ça sert d’avoir inventé des tuples qu’on ne peut pas changer, si on a déjà les listes, qui font la même chose et qu’en plus on peut changer ? »

C’est pour les performances. Les tuples prennent très peu de place en mémoire et sont très rapides d’accès. Quand on a besoin d’une suite de trucs et qu’on sait qu’on ne la changera pas, on prend un tuple.

Voilà un autre lien avec plein de détails sur les listes : https://openclassrooms.com/fr/courses/235344-apprenez-a-programmer-en-python/232026-creez-des-listes-et-des-tuples-1-2

Si tu ne veux pas tout lire, je te montre très rapidement ce dont tu auras besoin pour la suite :

ma_liste = [-70, 38, 45, -20, 113]
# Accès à un élément
print(ma_liste[2])
# Ajout d'un élément à la fin
ma_liste.append(99)
# Écriture de toute la liste.
print(ma_liste)

Mets ça dans un programme et regarde ce que ça fait. C’est d’une comprenabilité qui ne me semble pas pharaonique.

On peut boucler sur les listes, comme sur les tuples. De manière générale, il y a des tas de choses en commun entre les listes et les tuples, qui se font exactement de la même manière. C’est possible grâce à un concept de programmation appelé le duck typing.

Ça disgresserait trop d’expliquer ce concept dans cet article. Pour ne rien te cacher, je l’ai mentionné juste pour avoir l’occasion de placer cette superbe image :

Si ça fait coin-coin comme un canard, c’est un canard.

List-ception

En informatique, on aime mettre des trucs dans les mêmes trucs : un sous-bloc de code dans un bloc de code, un sous-répertoire dans un répertoire, …

J’ai le plaisir de t’annoncer qu’on peut mettre des listes dans des listes, des tuples dans des tuples, des tuples dans des listes dans des tuples dans des tuples, etc.

Voici une liste avec des tuples dedans :

des_coords = [ 
    (-100, -40), (100, -40), (-80, -70), 
    (80, -70), (-60, -90), (60, -90),
    (-40, -100), (40, -100), (-20, -110), 
    (20, -110), (0, -115),
    (-70, 120), (70, 120),
]

Tu remarqueras qu’on peut l’écrire sur plusieurs lignes, à condition de ne pas oublier le crochet ouvrant au début ni le crochet fermant à la fin, et de respecter l’indentation.

Ajoute cette liste de tuples dans ton programme et fais une boucle dessus.

  • À la première itération, tu récupéreras le tuple (-100, -40), et tu me dessineras un diamant aux coordonnées X=-100 ; Y=-40.
  • À la deuxième itération, tu dessineras au autre diamant en X=100 ; Y=-40.
  • Puis en X=-80 ; Y=-70.
  • etc.

Pour la couleur des diamants, met ce que tu veux. Personnellement, j’ai choisi un espèce de jaune-orangé : (250, 150, 0).

Tu obtiendras un joli sourire de joker !

Why so serious ?

Lien vers la réponse, si t’as plus de cartes joker.

Je return à ma maison

OK lecteurtrice, si tu en es là dans l’article, et que tu as codé tous les exercices avec les doigts nus de tes mains nues, sans trop regarder les réponses, tu as de la motivation et de la comprenitude. J’ai confiance en toi, je sens que tu ne vas pas t’évanouir si je t’apprends DEUX choses différentes dans un même chapitre.

Mets-toi face à moi pour bien recevoir toute ma décharge cognitive.

1)

Une fonction peut renvoyer quelque chose (un nombre, une liste, …). Le code ayant appelé la fonction peut récupérer ce qui a été renvoyé.

Voilà un exemple :

def renvoyer_une_liste():
    print("coucou")
    return [4, 6, 15, 9]
    print("On ne voit pas ce texte.")
    print("Car une fonction s'arrête après un return.")

liste_que_je_recupere = renvoyer_une_liste()
print(liste_que_je_recupere)

Si tu exécute ce bout de code, ça écriras : « coucou », puis « [4, 6, 15, 9] ».

On a le droit d’écrire plusieurs « return » dans une même fonction. Mais dès que l’exécution arrive sur l’un d’eux, la fonction s’arrête, et renvoie ce qui est indiqué.

2)

La fonction turtle.pos() renvoie un tuple de deux éléments, contenant les coordonnées de la position actuelle de la tortue. Tu peux tester comme ceci :

ma_position = turtle.pos()
print(ma_position)

Et maintenant tu vas mettre tout ça en pratique.

  • Au début de la fonction dessiner_diams, tu crées une liste vide. On va l’appeler « coord_des_pointes ».
  • Dans la boucle de la fonction, juste après l’instruction turtle.circle, tu récupères la position actuelle de la tortue.
  • Tu ajoutes cette position dans coord_des_pointes. Celle liste contiendra donc des tuples.
  • À la fin de la fonction, tu « return » coord_des_pointes.
  • Dans le programme principal, tu exécutes une seule fois la fonction dessiner_diams,
    • coordonnées X=0 ; Y=0, taille = 50, couleur = ce que tu veux.
  • Tu récupère la valeur renvoyée par la fonction, et tu la printes.

Ça devrait t’afficher ça dans la sortie standard :

[(0.0, 50.0), (50.0, 0.0), (0.0, -50.0), (-50.0, 0.0)]

Lien vers la solution, en cas de surcharge cognitive.

Je vous emmerde et je return à ma maison

Des diamants dans des diamants

Puisque tu as récupéré des coordonnées, profites-en pour dessiner des diamants avec ! Mais tu les fais un peu plus petits. Une taille de 25, par exemple.

Ça donnera quelque chose dans ce style (même si c’est pas ces couleurs là) :

Est-ce que tu vois ce qui va venir après, lecteurtrice ? Est-ce que tu réalises qu’on est maintenant très proche de l’image finale que je t’ai promise il y a plus de deux mois ?

À chaque fois que tu traces les 4 petits diamants, la fonction renvoie à nouveau les coordonnées de leurs 4 coins. Tu pourrais toutes les récupérer, (16 coordonnées en tout), et dessiner sur chacune d’elles un autre diamant, encore un peu plus petit que les précédents. Ne serait-ce pas fractalement uber-classe ?

Il te reste à régler un petit détail : tu ne récupères pas les 16 coordonnées en un seul coup.

Dans le programme principal, avant la boucle où tu dessines les diamants de taille 25, tu crées une liste vide. On va l’appeler coord_mini_diamants.

À chaque dessin de diamant, tu récupères 4 coordonnées, que tu ajoutes dans coord_mini_diamants. Sais-tu comment on ajoute une liste à la fin d’une autre liste ?

Eh non lecteurtrice, ce n’est pas la fonction « append ». Celle-ci permet d’ajouter un élément simple au bout d’une liste. Pour ajouter une liste au bout d’une liste, on utilise l’addition, tout simplement.

Tu aura donc ceci dans ta boucle :

coord_mini_diamants = coord_mini_diamants + dessiner_diams(x, y, 25, (255, 0, 0)

Une fois que cette liste est remplie, plus qu’à s’en servir.

Et paf, un niveau de diamant supplémentaire :

Lien vers le code, si les diamants ne sont pas tes meilleurs amis.

diamant(diamant(diamant(diamant())))

Pour finir, tu re-appliques la même démarche, pour un dernier niveau supplémentaire.

Je te récapitule le tout :

  • premier diamant : taille = 50, couleur= (128, 0, 0)
  • 4 diamants autour : taille = 25, couleur= (255, 0, 0)
  • 16 diamants autour : taille = 12.5, couleur= (255, 70, 70)
  • 64 diamants autour : taille = 6, couleur= (255, 120, 120)

Le fait de reproduire plusieurs fois la même forme, à d’autres endroits, et de plus en plus petite, me permettrait de te présenter les notions de fractales et de récursivité. D’ailleurs, on pourrait dessiner tous les diamants en une seule et même boucle. Mais je ne vais pas t’embêter avec ça, cet article est déjà assez cerveauphage.

Tout ça pour dire que nous arrivons enfin à notre image finale ! Yiiipiii !

Lien vers la réponse, si tu t’es fait une fracture de la fractale.

C’est tout pour aujourd’hui

Voici inévitablement des devoirs. Pour cette fois, je t’en donne deux !

Le premier est assez facile, c’est une reprise du devoir précédent. Il faut dessiner cet anus de licorne :

Petit indice : tu vas devoir trouver comment tracer des formes remplies de couleur, mais sans le trait noir de délimitation.

Le deuxième :

Là c’est un peu plus dur. Il faut reprendre ce qu’on a fait avant, en annulant le dessin de certain diamants. Le tout est de savoir lesquels. Un coup c’est celui de droite, un coup celui du haut, …

Tu vas peut-être devoir apprendre par toi-même à utiliser une notion que je n’ai pas du tout présentée : le branchement conditionnel, if-then-else.

 

Et la suite ?

La librairie turtle permet également de créer des animations. Dans Trinket, on peut faire quelque chose comme ça :

Je pourrais donc te pondre un ou deux articles là-dessus, lecteurtrice. Mais je ne sais pas si ça vaut le coup. Je voudrais écrire d’autres trucs et me lancer dans d’autres projets.

J’ai mis cette série d’article de découverte du python sur mon compte Linkedin (vous ne savez pas lequel c’est, mais vous n’en avez pas besoin). Dans l’ensemble, j’ai eu des retours très aléatoires :

  • zéro commentaire dans ce blog, mais ça j’y suis habitué,
  • plein de commentaires et repartages Linkedin pour le premier article,
  • un seul repartage (de mon super-pote) pour le second article.

Je suis un peu perplexe. Je ne sais pas si c’est les gens qui ne me répondent rien parce que je ne les intéresse pas, ou si c’est Linkedin qui ne met pas mes articles dans le fil d’actualité des gens pour une raison obscure (le fait d’avoir placé le mot « fouetter » lorsque j’ai décrit les sévices corporels destinés aux personnes ne faisant pas leur devoirs ?)

Et désolé, il n’y a pas autant de blagues et de jeux de mots débile dans cet article. Un réajustement effectué par mon inconscient ? Je ne sais pas.

Je vais attendre les retours, mais si j’en ai à nouveau aussi peu, je ne me prendrais pas la tête. Le tout dernier article de la série (s’il y en a un) sera du code brut : les corrections des devoirs et l’animation.

Tchôrp.