Coucou ! Quatre fois n’est pas coutume, je viens encore vous parler de Squarity.
J’ai réussi à régler le problème de lenteur. J’ai lâché la librairie JS Brython, pour la WebAssembly Pyodide.
Argh, du code binaire !
D’aucuns-et-d’aucunes considèrent que les WebAssembly sont le mal absolu, car, tout comme le code binaire des fichiers exécutables, c’est non lisible par un humain. Ça va à l’encontre de l’un des dogmes du web, qui énonce que tous les composants d’un site doivent être analysables, même si cette analyse peut être compliquée. Le HTML, le javascript, le CSS, le JSON sont écrits avec des mots, et non avec des nombres. C’est en partie en raison de ce dogme que les navigateurs vont définitivement virer la technologie Flash.
J’oblige donc votre navigateur à exécuter du code que vous ne pouvez comprendre aisément, ce qui fait de moi un vilain.
Ce à quoi je répondrai : « Mouiimmpfboapf, ça va bien. Le code source de Pyodide est disponible sur internet. D’autre part, avez-vous tous les codes sources de tous les exécutables que vous lancez sur votre machine ? ». À mon avis, la seule personne qui peut vraiment le prétendre serait Richard Stallman.
(TODO : insérer ici une photo à poil de Richard Stallman, pour équilibrer par rapport à la quantité de photos de femmes rondes à poil qu’il y a dans ce blog)
Heuwargl, le chargement est lent !
L’exécution de code python dans un navigateur est plus rapide par Pyodide que par Brython. J’ai fait quelques benchmarks au doigt mouillé, en particulier avec le jeu Loops in Pool. La propagation de la boue et de l’eau sont maintenant beaucoup plus fluide.
Dans la version précédente de Squarity, j’avais testé avec un délai de 1 milliseconde entre chaque propagation, et c’était quand même lent. Alors j’ai mis 400 millisecondes pour ne pas surcharger la machine. Dans la nouvelle version, j’ai re-essayé 1 milliseconde, l’animation s’est accélérée significativement. Je l’ai laissé ainsi, youpi.
Cependant, l’initialisation de Pyodide est très lente. Il faut télécharger 20 Mo de bazar, alors que Brython tient en moins de 10 Mo (et c’est déjà beaucoup pour du javascript !). Ensuite, le navigateur doit interpréter et démarrer la WebAssembly, ce qui prend encore quelques secondes.
« Dans le monde dans lequel on vit », tout doit aller très vite. Une dizaine de secondes d’attente peut décourager certaines personnes. Ce choix de Pyodide me fera donc perdre une base potentielle de user-client-partner. Mais je préfère décourager définitivement un petit nombre, plutôt que ralentir continuellement tous les futurs fidèles qui utiliseront Squarity.
Je mettrai une barre de progress la plus précise possible. On accepte plus facilement d’attendre lorsqu’on voit un décompte qui avance. Actuellement, le progress n’est qu’une liste de 8 étapes, dont 6 sont pratiquement instantanées et 2 sont très longues. C’est pas du tout suffisant.
Si je pouvais éviter le re-téléchargement des 20 Mo une fois que ça a été fait, ce serait top. Je sais bien que le navigateur a un cache, mais celui-ci a une fâcheuse tendance à se vider. On a le droit de stocker des WebAssembly dans du local storage ?
J’ai également testé sur smartphone. Ça fonctionne (j’en n’étais vraiment pas sûr), par contre l’exécution reste super lente. Les fuckings millenials de la génération Ÿ écoperont des deux inconvénients : lent à l’initialisation ET à l’exécution. Je laisse comme ça pour l’instant, tant pis. De toutes façons, le premier truc à régler concernant l’utilisation sur smartphone serait le responsive design cradingue. Et dans un futur très lointain, on pourrait carrément imaginer une app.
Il suffira juste d’accepter le postulat qu’une app mobile exécutant du code python arbitraire ne constitue pas une faille de sécurité. Ha ha ha. Je ne suis même pas sûr de ce postulat concernant les sites web. Re-ha re-ha re-ha. Bref : y’a du boulot.
En tout cas, Pyodide est beaucoup plus simple à intégrer que Brython. Pour exécuter du python, j’ai une fonction à appeler, avec le code en paramètre. On peut directement lire/écrire les variables javascript, les exceptions python sont automatiquement remontées, avec traceback et message. J’ai tout ce qu’il me faut.
Avec Brython, je devais pré-placer mes variables d’échanges dans un truc à la con, mettre mon code dans une balise script, lancer une fonction sans paramètres, prier pour que la portée des variables ne se vautre pas toute seule, et lire les données de retour dans le truc à la con sus-mentionné. Je ne vous (re)parle même pas de la récupération des erreurs où j’ai eu recours à des astuces tellement tordues que mon cerveau a préféré les oublier !
Vive Pyodide. De plus, je ne désespère pas que dans quelques siècles, si l’humanité n’a pas entièrement crevé pour une raison quelconque, les navigateurs web soient nativement dotés d’un interpréteur python. Que l’on ait enfin une alternative sérieuse à ce javascript de merde.
Qui veut dessiner un beau tileset ?
Mon jeu-phare, les aventures de H2O, mériterait bien un petit coup de polish (dans le sens polissage, pas dans le sens polonais). Mais je ne suis pas un dessinateur assez doué pour ça.
Alors j’ai posté un message chez la communauté PixelJoint, pour leur demander qui serait assez gentil pour me redessiner le tileset de H2O, en mieux.
Si vous élevez des pixels chez vous, n’hésitez pas à vous manifester sur le forum de PixelJoint. Il s’agit d’un concours en mode bisounours, dans lequel tout le monde gagnera. C’est à dire que je ne prendrais pas le meilleur tileset, mais je ferais une version du jeu H2O pour chaque tileset qui sera proposé.
Pour l’instant, je n’ai eu qu’une seule proposition, via message privé. Je peux m’en contenter, le pixel-artiste m’a fait un super boulot. Vous le verrez très bientôt lorsque j’aurais mis à jour le jeu.
Pour le bon plaisir de ce projet Squarity, j’ai dû me créer un compte Twitch, un compte Ludum Dare, un compte GoDaddy, un deuxième compte pythonanywhere et maintenant un compte PixelJoint. Tellement populaire, tellement social.
À propos de social
L’une des prochaines grosses étapes de Squarity sera de créer un lieu d’échange et de contenu. Ça me permettra de recenser les jeux existants, de publier les release notes, d’ajouter des articles et des tutoriels, d’aider les codeureuses en herbe, etc.
Je ne sais pas encore sous quelle forme je ferai ça. Le plus simple serait un serveur Discord, mais j’aimerais éviter d’être trop dépendant d’un réseau social existant, quitte à payer un petit peu. Peut-être que ça se finira avec une instance Mastodon et un CMS à l’arrache.
Mais j’aimerais aussi éviter d’obliger les gens à se créer un enième compte sur un enième site. J’essaierais peut-être d’intégrer des authentifications tierces : les boutons « sign in with Google », « sign in with Github », etc.
Bien évidemment, je ne connais pas grand chose dans ce domaine, ça risque donc de me prendre du temps et d’être un beau bordel. On verra bien. Peut-être que dans trois semaines, j’écrirais un article de blog larmoyant expliquant que c’est trop compliqué, que j’abandonne tout, et que je préfère encore utiliser tout mon temps libre à zapper en continu sur Twitch.
(TODO: insérer ici une image prise sur Twitch de gens pixelisés déguisés en serpent qui font passer des arcs électriques dans de la vapeur d’eau pour voir si ça la disperse et qui ensuite font de la peinture sur corps).
À propos de corps
Petit rattrapage de tous les précédents articles n’ayant pas d’images de femmes rondes.
Voici Nicole Nurko, dont je vous ai précédemment parlé :
Ainsi que Kim Manana :
Et la sublime-bling-bling Gabriella Lascano :
Pro-tip : lorsque vous voulez parcourir un compte Instagram (d’une femme ronde ou pas) et que vous ne voulez pas vous inscrire car, comme dit précédemment, vous en avez marre de vous créer des comptes de partout, vous pouvez remplacez dans l’url « instagram.com » par « imginn.com ». Vous aurez toutes les photos sans les pop-ups lourdingues.
À la chopraine, comme on disait dans les années 1990.
Réchèr : le Grand Tout 