Après une longue attente la version 0.55 du jeu Unvanquished a été publiée le 20 octobre 2024. Deux mises à jour mineures se sont succédées le 3 novembre et le 15 décembre pour peaufiner cette version, juste à temps pour être déposée sous le sapin de Noël !

Unvanquished est un jeu vidéo libre et gratuit mêlant stratégie en temps réel et actions à la première personne dans un univers futuristique où deux factions (humains, aliens) combattent pour leur survie.

S’inscrivant dans la continuité de Tremulous (révélé en 2006) et basé sur ce dernier, Unvanquished développe cette expérience de jeu nerveuse et exigeante depuis 2013, en améliorant continuellement le moteur et explorant des variantes et ajustements de jouabilité.

Laisse-moi goûter à cette version !

Sommaire

• Gameplay
• Bots
• Interface utilisateur
• Traductions
• Nouveaux visuels
• Fichier d’entité
• Le futur est lumineux
• Corrections du moteur de rendu
• Performance améliorées
• Bien entendu que ça fait tourner Unvanquished !
• Nouveaux joujoux
• À venir
• Il est temps de jouer !

Cette version avait été promise dans le dernier article Des nouvelles de Unvanquished, et 10 mois après la version 0.54, voici la version 0.55.

Pendant cette année 2024, le jeu a fait l’objet d’un développement soutenu et vu l’arrivée de nouveaux contributeurs.

Gameplay

• La portée du « rocket pod » a été réduite: 2000qu → 1300qu (62m → 40m).
• Il n’est plus possible de désévoluer vers la même classe, ce qui permettait de recharger ses projectiles sans attendre.

Bots

• Les bots aliens savent désormais éteindre les bases en feu.
• Ils peuvent aussi utiliser le granger avancé pour atteindre des plate-formes élevées et y construire.
• Les classes sachant marcher sur les murs le font de manière plus fiable, et le saut de mur du maraudeur est plus précis lorsqu’il escalade des murs.

D’autres améliorations sont plus subtiles, les bots peuvent naviguer dans les cartes de façon plus efficace depuis que la taille des tuiles du maillage de navigation est configurable. Les mappers (ceux qui créent ou modifient des cartes) peuvent aussi configurer d’autres aspects de la navigation.

Un déséquilibre qui rendait les bots aliens moins bons que les bots humains a été retravaillé.

La navigation dans la carte perseus a été améliorée. C’est un des patchs de la mise à jour mineure 0.55.1, c’était déjà prêt pour la 0.55 mais avait été oublié (oups !).

La 0.55.2 a donné aux bots la capacité de voler et la capacité de danser autour des ravins sans tomber.

Interface utilisateur

Il est désormais possible de se déplacer et d’utiliser certaines touches d’action alors que certains menus circulaires sont ouverts : évolution, construction, balises (beacons). Cela permet d’ouvrir le menu de construction en tant que granger avancé sans tomber. On peut aussi évoluer tout en courant ou en sautant, etc.

Les nouveaux menus avec les options de réticules.

Traductions

La version 0.55 est la première version majeure d’Unvanquished à distribuer de nouveau des traductions ! Nous avions déjà distribué quelques traductions avec la version de correction 0.54.1, elles étaient en quelques sorte en prévisualisation. Cette version apporte les traductions pour le Français, l’Allemand, l’Italien, l’Espagnol, le Finlandais, deux variantes de Portugais, et trois variantes de Chinois.

Dans les premiers jours d’Unvanquished nous avions des traductions, mais il y a longtemps nous avons changé la technologie utilisée pour implémenter l’interface utilisateur et la prise en charge des traductions a dû être réimplémentée. Les voici de retour et nous sommes heureux de vous les distribuer de nouveau. Pour contribuer plus de traductions et les affiner, le mieux est de le faire sur Weblate.

Nouveaux visuels

De nouveaux modèles sont là : la « painsaw » d’Alex Tikkoiev et le Chaingun d’extreazz. Ils ont été intégrés au jeu par Ishq. Cela semble simple à faire mais nous n’avons pas de modeleur ni d’animateur actif et cela nous freine beaucoup, vous pouvez nous rejoindre.

Le nouveau chaingun d’extreazz.

La painsaw produit désormais des étincelles quand elle impacte des surfaces dures, agissant comme le Grand Communicateur de vos désirs de disperser des tripes extra-terrestres.

La nouvelle painsaw d’Alex Tikkoiev.

Il y a dix ans nous avons reçu une fonctionnalité bien sympathique appelée particules douces (soft particles). Cela empêche certains effets comme le brouillard ou les nuages d’acides d’être affichés de manière disgracieuse lorsqu’ils touchent des murs. Initialement l’effet n’était configuré que pour une poignée de shaders. Rapidement des programmeurs paresseux se sont dits : « configurer les shaders est ennuyeux, et si nous activions la fonctionnalité pour toutes les particules ? ». Malheureusement, cela rend certaines particules invisibles, spécialement les effets d’impacts qui sont très proches de murs ou de sols. Apparemment personne n’a remarqué ça pendant 9 ans, jusqu’à ce que nous retournions à la configuration manuelle de shaders à cause de changements architecturaux liés à autosprite2. Après une revue méticuleuse de tous les systèmes de particules du jeu, nous avons corrigé, retiré ou amélioré certains effets graphiques. Par exemple le souffle du canon lucifer produit désormais une onde de choc, causant une distorsion visuelle. Un tel effet était déjà présent dans les données, mais il ne fonctionnait pas à cause d’un problème de tri des shaders. Le tir secondaire produit aussi un flash violacé à l’impact, effet qui était souvent invisible à cause des particules douces automatiques.

Le nouvel effet de soin de la médistation.

Reaper a repensé l’effet de soin de la medistation et l’a rendue plus transparente, pour que les joueurs en cours de soin puissent voir à travers.

Sweet a ajouté un nouvel effet visuel au champ de force de la carte plat23. Cela utilise l’effet de mirage de chaleur (heat haze) qui était initialement conçu pour les armes et les effets de feu, mais il se trouve que ça peut également produire des effets très sympathiques dans les cartes. Nous remercions Masmblr pour la manière dont il nous fait avancer en démontrant dans ses propres cartes communautaires comment il est possible d’exploiter de façon créative et nouvelle des fonctionnalités que nous proposons déjà !

Fichier d’entité

Le moteur prend désormais en charge les fichiers d’entité. Cela est particulièrement utile pour les cartes (niveaux de jeu) sans source (il y en a des centaines !). Un fichier d’entité permet certaines personnalisations de comment certaines entités fonctionnent (portes, ascenseurs, téléporteurs…). Il est possible d’extraire une description d’entités avec q3map2 et le fichier extrait peut être édité avec un éditeur de texte et lu par le moteur lorsqu’il charge une carte. Le fichier d’entité peut aussi être utilisé pour modifier comment la lumière d’une carte sera appliquée (il est possible d’y renseigner des variables qui configurent le moteur de rendu pour cette carte).

Le futur est lumineux

Une vidéo démontrant la compatibilité des lumières de diverses cartes historiques (voir la vidéo complète).

Un effort aux long cours est fait pour que le moteur affiche de meilleures lumières en jeu. Les investigations ont commencé à livrer des résultats significatifs en 2020 avec l’affinage du procédé de compilation des lumières. Cet effort est multi-facettes et touche à de multiples aspects de la chaîne de production et de rendu. Ces dernières années, Illwieckz s’est assuré que différents types d’éclairage soient pris en charge. L’éclairage par vertex (vertex lighting) a été ajouté en plus de l’éclairage par grille (grid lighting) et de l’éclairage par texture (lightmap). Ainsi les cartes qui mélangent éclairage par vertex et éclairage par texture sont désormais correctement affichées. Illwieckz a aussi débuggué les styles de lumières, une sorte de lumière dynamique pré-calculée qui fusionne plusieurs textures de lumière (lightmap) au moment du rendu.

Comparaison entre l'ancien suréclairage (à gauche) et le nouveau suréclairage (à droite). Comparer avec un curseur.

Après cela Illwieckz a réimplémenté le mécanisme de suréclairage (overbright) pour éviter la troncature des lumières (light clamping). Il se trouve que le moteur de rendu de Quake 3 souffrait d’une limitation qui atténuait les lumières autant qu’il les éclaircissait… Le nouveau code non-buggé est désormais activé par défaut. Cela a suscité des débats puisque comme le moteur id Tech 3 avait un suréclairage buggé depuis plus de 20 ans, utiliser un moteur de rendu non-buggé peut révéler des bugs que les créateurs de niveaux n’ont jamais vu avant, et il était même possible d’introduire des bugs dans certains logiciels de production sans que les gens ne s’en rendent compte ! Certaines personnes peuvent argumenter que l’affichage buggé est la façon dont le créateur du niveau s’attend à ce que son niveau soit vu… Cette histoire va si loin que cela mériterait un article dédié !

La prochaine étape sur ce chemin vers un meilleur éclairage sera de faire de la colorimétrie correctement et de faire de la fusion linéaire de lumière (quelque chose qu’id Tech 3 n’a jamais fait), mais cette tâche est pour le futur.

Corrections du moteur de rendu

Une vidéo montrant la récursion de miroirs et de portails et leur fusion (voir la vidéo complète).

• Sprites : Les surfaces utilisant le mot clé de shader autosprite2 sont correctement affichées, c’est parfois utilisé pour afficher des effets de symétrie axiale, par exemple pour une flamme de bougie. Ce travail a été réalisé par Slipher.
• Portails et miroirs : Reaper a terminé l’implémentation de la récursion de portail et de miroir, a implémenté la fusion de portails et la fusion alphaGen (une technique qui permet d’obscurcir un portail selon la distance à celui-ci), et a rendu possible d’avoir des portails mobiles. Il a corrigé la rotation de portail ainsi que des bugs de portails liés aux lumières, et s’est assuré que du creep extra-terrestre de taille 10 millions de fois la taille de l’univers observable n’apparaissent pas dans les portails…
• Vidéo : Nous pouvons à nouveau jouer des vidéos sur les surfaces. Avec le temps le code s’était gâté (rotten code), était devenu cassé et avait même été enlevé tandis qu’il était cassé. Il fut ressuscité et a fait l’objet d’une profonde réécriture par Slipher, et la fonctionnalité fonctionne de nouveau — et même mieux qu’avant (avec moins de limites arbitraires) ! Cette nouvelle implémentation était déjà visible dans la version 0.54.1, la voici désormais dans une version majeure. Le seul format pris en charge est l’antique format RoQ utilisé par Quake 3 qui, par mesure de compatibilité avec les données de jeu existantes, est le codec que nous devons prendre en charge avant tout autre codec. Nous ne fermons pas la porte au fait de prendre en charge d’autres codecs, mais pour cela il faudrait que la fonctionnalité soit utilisée plus souvent pour justifier cet effort supplémentaire.
• Brouillard : Reaper a corrigé l’effet de brouillard, qui était cassé dans la version 0.45. Oups !
• Lumières : Les lumières dynamiques sont désormais moins pixelisées, quand bien même ce problème n’est pas encore complètement corrigé.
• PBR : La prise en charge de textures prétendues « basées sur la physique » est désormais dans un état viable grâce à Ishq (plus d’artefacts noirs). C’est déjà utilisé avec un nouveau modèle de chaingun. Pour le rendre bon, nous avons besoin de le faire fonctionner avec les réflexions spéculaires (réflexions statiques).

Une vidéo montrant la lecture de vidéo sur les surfaces du jeu (voir la vidéo complète).

En corrigeant le shader autosprite2, la fusion de portails et la lecture de vidéos, nous avons corrigé 3 régressions du moteur original de Quake 3 et qui étaient liées à la prise en charge de format de fichiers anciens et de techniques tout aussi anciennes. Parce que notre moteur de rendu n’est plus celui de Quake 3, corriger certaines de ces régressions requiert parfois d’écrire du code neuf plutôt que de corriger un code existant, et c’est exactement ce qui s’est produit pour les portails.

Performance améliorées

Unvanquished 0.55.2 a été publiée pour Noël !

Le moteur et le jeu sont plus rapides que jamais !

• Simplification du ciel : Reaper a purifié par le feu le code de rendu du ciel qui était archaïque et… étrange. Ce code pouvait générer plus de 1000 triangles par trame rien que pour dessiner le ciel. Une skybox n’a pas besoin d’une géométrie aussi fine, elle est simplement modélisée comme l’intérieur d’un cube. En plus le code faisait des allers-retours mémoire entre la mémoire principale et la mémoire graphique… 🤦‍♂️️ Nous dessinons donc le ciel maintenant avec seulement 12 triangles. Inutile de dire que les performances sont significativement améliorées, et ça aurait toujours dû être comme ça.
• Culling : Il s’agit du procédé qui élague les surfaces non-visibles pour éviter de les dessiner. Illwieckz a optimisé l’implémentation générique pour processeur central (CPU), Slipher a ciselé à la main un code SSE pour les processeurs x86, et Reaper a permis d’utiliser la carte graphique (GPU) quand le pilote et le matériel sont compatibles.
• Réduction des délais IPC par du traitement par lots et de la mise en cache : Ces travaux accélèrent des choses comme les particules, les marques d’impact, et les ombres. Illwieckz a réduit le temps d’attente pour ces communications interprocessus en ajoutant des alternatives à nos interfaces de programmation (API) qui fonctionnent par lot. L’IPC est comme un service postal qui transporte les messages entre le processus du jeu Unvanquished et le moteur Dæmon. Pour un facteur, l’important n’est pas le nombre de pages que vous écrivez mais le nombre d’enveloppes à livrer. Vous pouvez donc alléger sa charge de travail en mettant toutes vos lettres dans une seule grande enveloppe. Pour un cas d’utilisation (déjà livrée dans la version 0.54.1), Slipher a implémenté une mise en cache côté code de jeu. Pour filer la métaphore, il n’est pas nécessaire de ré-envoyer le même courrier si le contenu est déjà connu. Sur du matériel actuel, ces optimisations peuvent augmenter le taux de trame (framerate) de plusieurs centaines de FPS quand il y a de nombreuses particules et autres choses de ce genre à l’écran (spam de grenade incendiaires, par exemple !).
• Code de vertex flottant plus rapide : L’implémentation de vertex plein-flottant écrite par Slipher pour étendre la compatibilité à du matériel plus ancien ou de plus basse gamme qui ne prennent pas en charge les demi-flottants a aussi doublé le taux de rafraïchissement sur du matériel qui fonctionnait déjà ! La réécriture a aussi apporté de menues optimisations dans le code de modèles.
• Placage de relief : Reaper a corrigé un bug dans le code des cartes de relief (relief mapping), ce qui a débloqué quelques centaines de FPS sur des cartes graphiques de génération actuelle.
• Usage mémoire des images : Illwieckz a implémenté le mécanisme fitScreen pour les textures d’interfaces utilisateur : c’est une alternative à l’antique implémentation noPicMip de Quake 3 : noPicMip instruisait le moteur de ne jamais réduire la taille d’une image, fitScreen s’assure qu’elle soit réduite d’une façon qu’elle ne devienne jamais plus large que l’écran. Par exemple une capture d’écran d’une carte (niveau) utilisée dans la liste des cartes et au chargement d’une carte ne sera plus jamais chargée en pleine résolution dans la mémoire graphique si elle doit être affichée sur un écran 640×480 (pour donner un exemple extrême)… Combiné avec le mécanisme r_maxImageDimension que nous avons ajouté en version 0.52 pour les textures qui ne sont pas utilisées pour les interfaces utilisateurs comme alternative à r_picmip, ce nouveau mécanisme donne au jeu une empreinte mémoire en VRAM très très faible quand on utilise un écran avec une résolution toute petite.
• Plus de pré-calcul : De nombreuses décisions étaient préalablement prises à chaque trame en rendant telle ou telle surface, Illwieckz s’est assuré que ces décisions soient désormais prises une fois pour toute lorsque le shader est parsé. Ce que nous appelons « shader » ici est un format de définition de matériaux utilisé par id Tech 3 et ses dérivés, ainsi que de nombreux outils d’édition de cartes. Ne pas confondre avec un « shader GLSL » qui est un programme exécuté sur la carte graphique.
• SSAO : Le shader GLSL SSAO (Screen Space Ambient Occlusion) a été rendu un peu plus rapide par Reaper.

Le moteur et le jeu ont été profilés intensivement par Illwieckz en utilisant Orbit. Cet effort a permis d’identifier des goulots d’étranglement (bottleneck) et du code non-optimal. Au final cela nous a aidé à implémenter de nombreuses optimisations à de nombreux endroits dans le code.

Le chargement de carte a aussi été amélioré de plusieurs façons :

• Le moteur ne calcule plus la somme de contrôle des images CRN au chargement.
• Le moteur ne compile plus certains shaders GLSL qui sont détectés comme inutilisés.
• De la même façon nous avons réduit le nombre de permutations de shader GLSL à compiler.
• Les joueurs qui aiment jouer seul apprécieront notre génération « multithread » de maillage de navigation de bot (bot navigation mesh), grâce à Ishq et Slipher. Cela fait partie de la phase de chargement lorsque vous jouez une carte pour la première fois dans un jeu local. Cette génération n’utilisait avant qu’un seul fil d’exécution (thread), désormais toute la puissante de votre processeur est exploitée en mettant tous les cœurs à contribution. Les hébergeurs de serveurs peuvent également en profiter et peuvent configurer cette fonctionnalité avec la variable g_bot_navgenMaxThreads (utiliser moins de fils utilise moins de mémoire, ce qui peut être préféré sur certains serveurs).

Il y a aussi tout un ensemble de choses qui n’ont pas de lien avec le moteur de rendu qui rendent le jeu plus rapide :

• Le préréglage « le plus bas » (lowest) pour les appareils de très bas de gamme a été optimisé encore plus.
• Nous distribuons des modèles optionnels en faible qualité – pour le moment seulement pour les constructions, avec la seule différence que ces modèles ont moins d’articulations. Cela permet de traiter l’animation de ces modèles sur des GPUs plus bas de gamme (au lieu de basculer sur le code CPUs quand le GPU est trop bas de gamme).
• Il a été découvert que certaines variables de configuration (cvar) étaient utilisées par le code de jeu pour envoyer des informations à l’interface du code du jeu dans le but de les afficher à l’écran. Cela signifie que le jeu s’envoyait une lettre à lui-même à travers le moteur à chaque trame… En fait cela demandait même deux lettres : une pour envoyer la donnée au moteur, une pour la récupérer depuis le moteur, tout ça pour une donnée déjà connue ! Cette horreur a été atomisée avec un préjudice extrême.
• L’accès à une cvar de jeu par son nom depuis le jeu utilise désormais un cache local, réduisant encore le nombre de messages que le jeu et le moteur doivent échanger, accélérant de beaucoup l’interface utilisateur.

Ceux qui aiment faire tourner des benchmarks seront heureux d’apprendre que le taux de trame de la fonctionnalité timedemo n’est plus plafonné à 999 fps.

De plus, l’interface Curses peut désormais afficher les FPS.

Bien entendu que ça fait tourner Unvanquished !

Toujours du côté du moteur de rendu, l’exigence minimale est désormais OpenGL 2.1 sans extension spéciale. Cela signifie que le matériel le plus limité qui puisse faire tourner Unvanquished inclue les ATI R300, les Intel GMA 3 et 4 (sous Linux) et les Nvidia NV40. Parfois même un OpenGL 2.1 incomplet pourrait suffire !

Votre carte graphique est prise en charge. Si cela ne fonctionne pas alors qu’elle est censée prendre en charge OpenGL 2.1 (ou plus), c’est très probablement un bug de pilote.

Par exemple même le VC4 du Raspberry Pi 3B+ peut soutenir 60 fps avec la préconfiguration la plus basse (lowest) et une résolution faible. Cependant le pilote a encore besoin d’être amélioré pour être compatible avec tous les niveaux jouables.

Un Raspberry Pi 3B+ dessinant la carte plat23 à 60 fps avec le préréglage « le plus bas »…

Jouer à Unvanquished sur un RPI3 n’est vraiment pas recommandé (la mémoire vive disponible sera aussi très limitante), mais si un RPI3 arrive à tenir le rang, c’est que le jeu tourne sur vraiment n’importe quoi, y compris sur un topinambour (parce que même une patate ça serait du luxe 🤭️).

Voici quelques optimisations qui ont été faites pour étendre la compatibilité du moteur :

• L’extension GL_ARB_half_float_vertex n’est plus requise. Cela s’ajoute au fait que l’extension GL_ARB_framebuffer_object n’est plus non-plus requise depuis la version 0.54 pour être compatible avec plus de matériel. La réécriture faite par Slipher pour prendre en charge à la fois les vertex demi-flottants ou les vertex plein-flottants a même amélioré les performances du moteur (code plus concis, code plus performant, et qui permet plus de chose… tout ça à la fois) !
• Les textures 3D ne sont plus requises. C’est quelque chose qui est obligatoire en OpenGL 2.1, mais le moteur peut faire sans lorsque l’implémentation est incomplète. De telles implémentations incomplètes peuvent être trouvées avec certaines puces graphiques embarquées conçues pour OpenGL ES, et Mesa se permet de fournir « autant qu’il peut » d’OpenGL pour faire fonctionner les compositeur de bureau. Le moteur Dæmon sait désormais se satisfaire lui-aussi d’une telle implémentation incomplète.
• Une collection de codes de détection a été implémentée pour identifier des pilotes buggés ou lent, ainsi que des matériels lents. Quand c’est possible, un code moins buggé ou plus rapide est activé lors de l’exécution. Par exemple lors de ce cycle de développement nous avons mis le pied dans ce que les développeurs Intel caractérisent comme un défaut matériel de l’architecture Iris (l’actuelle…), et ont suggéré un contournement qui limite les défauts visuels la plupart du temps. Il y a quelques années nous avions identifié que le dernier pilote Nvidia pour toute une génération de carte donnée ment sur la présence d’une extension, et plante si on tente de s’en servir, et ne sera jamais mis à jour… donc depuis un moment déjà on le détecte pour corriger ses prétentions. Il y a aussi une génération de vieilles cartes ATI qui sont plus rapides en flottants qu’en demi-flottant (la prise en charge annoncée par le pilote est très probablement une émulation pour permettre de faire fonctionner d’autres logiciels qui n’ont pas d’implémentation alternative), donc on détecte et on utilise le code le plus adapté à cette architecture. Il y a d’autres types de contournements mais ces trois-là sont représentatifs. Nous avions déjà quelques-uns de ces contournements implémentés (comme celui pour certaines Nvidia), mais désormais nous avons un procédé standardisé pour implémenter de tels contournements et pour pouvoir les désactiver (pour que les fabricants de matériel et/ou développeurs de pilotes puissent reproduire les bugs, par exemple).

Bien sûr toutes les améliorations de la vitesse d’exécution ont étendu la compatibilité en transformant des équipements « capable de faire le rendu » en « quelque chose avec lequel on peut jouer ».

Nous avons aussi ajouté la possibilité de compiler et exécuter un moteur Dæmon natif sur FreeBSD. Les binaires NaCl exécutés dans le bac à sable tournent toujours dans le mode de compatibilité Linux, mais le moteur peut désormais être natif FreeBSD. Une telle astuce doit probablement être utilisable sur d’autres systèmes qui ont une compatibilité Linux intégrée (NetBSD par exemple, mais nous n’avons pas testé), en utilisant un binaire natif pour le moteur et la compatibilité Linux pour la machine virtuelle du code du jeu.

Un point que nous aimerions améliorer dans le futur au niveau du moteur est l’utilisation mémoire.

Nouveaux joujoux

Remarquez les reflets sur les tuyaux !

Placage de reflet (très expérimental) : Tandis que notre moteur de rendu progresse, les reflets statiques qui étaient complètement cassés sont désormais en meilleur état. Une fois activés, vous pourrez apercevoir votre environnement dans les matériaux réfléchissants, comme des tuyaux métalliques, des plastiques brillants, et des surfaces excessivement polies… Puisque cela est statique, seule la géométrie stationnaire de la carte est pour le moment reflétée, bien que cela soit suffisamment subtil pour que les différences ne soient pas trop évidentes, surtout au beau milieu de l’action. En outre, les données de reflets sont enregistrées et chargées depuis le disque quand vous activez la mise en cache dans les options. Le code du moteur en charge de sélectionner les reflets pour chaque surface a aussi été amélioré, apportant des reflets plus corrects et de grandes améliorations de performance.

Système de matériaux (très expérimental) : Une autre étape vers la modernisation du moteur est l’ajout d’un système de matériaux. Lorsque le matériel et les pilotes sont compatibles, cela déplace de nombreuses tâches de rendu depuis le CPU vers le GPU, produisant ainsi un flux de travail centré sur le GPU. Bien que cela ajoute un peu plus de travail au GPU, cela élimine une forte pression mise sur le CPU, ainsi que de nombreux aller-retours entre le moteur et le pilote et entre le CPU et le GPU. Sur les cartes les plus exigeantes pour le CPU (en particulier celles avec un “vis” mauvais, le vis est une représentation de la carte générée par le compilateur de carte qui détermine quelle partie devrait être visible selon le point de vue) cela peut doubler le taux de trame comparé au moteur de base. Ce système est encore incomplet et de nombreuses améliorations sont à venir.

Reaper est celui qui se cache derrière la réalisation de ces chantiers impressionnants.

Pour pouvoir en profiter il vous sera nécessaire d’avoir OpenGL 4.6 et (en plus) l’extension GL_ARB_bindless_texture. Il reste cependant des problèmes avec certains matériels et pilotes : tout devrait fonctionner avec Nvidia, le système de matériaux et le « frustum culling » devraient fonctionner avec Mesa (radeonsi pour AMD, etc.) quand la dernière version de Mesa est utilisée (l’ « occlusion culling » ne fonctionne pas encore et pourrait planter avec un Mesa qui ne vient pas de la branche de développement main…). Cela ne fonctionne pas avec le pilote propriétaire AMD à cause de bugs. Des contournements pour ces problèmes sont planifiés, mais tous n’ont pas été implémentés à temps pour la sortie de cette version.

À venir

Parmis les développements qui sont déjà testables sur certains serveurs et qui seront disponibles dans la prochaine version, il y a le mode « vampire », qui est un mode alternatif de gestion des ressources : plutôt que de miner du point de construction, chaque équipe se voit dotée d’un lot déterminé de points en début de partie et lorsqu’une équipe détruit une construction adverse elle s’approprie les points de construction associées. Ce mode « vampire » est évalué comme une solution potentielle au problème de certaines parties qui sont trop longues ou semblent bloquées avec des équipes trop bien fortifiées de chaque côté. Ce mode de jeu peut être testé en avant-première sur des serveurs comme Map&Bot Testing, Der Bunker, ou Bug Squash Central.

Il est temps de jouer !

Le jeu Unvanquished se télécharge ici et les parties en cours sont listées ici !

Tuxemon Tower 0 est un petit jeu vidéo très sobre. Il est inspiré des jeux Pokémon classiques et consorts, mais il est 100% libre et ne cherche aucunement à être un clone.

Sommaire

• En bref
  • Qu'est-ce que Tuxemon Tower 0 ?
  • Télécharger Tuxemon Tower 0
    • Quelques clients BitTorrent libres
  • Images du jeu
    • Images de cartes
    • Images de combats
    • Images de menus
  • Comment contribuer ?
  • Le droit d'auteur
    • Les licences utilisées
    • Les conséquences
  • Remerciements
• En plus long ?
• Données du jeu
  • Consultation en jeu
  • Documentation HTML
  • Images
    • Liste des créatures
    • Liste des dresseurs et dresseuses
• Annexe : temps et motivation
  • Approximation de l'évolution de la motivation
    • Statistiques de commits par nous pour ce nouveau jeu
    • Statistiques de commits par nous pour Greycess Knight RPG

En bref

Qu'est-ce que Tuxemon Tower 0 ?

Tuxemon Tower 0 est un jeu vidéo de combats en tour par tour. Les combattants peuvent avoir un ou des types, ont des statistiques, et une ou plusieurs capacités. En gagnant assez d'expérience, ils montent de niveau et ainsi deviennent plus forts. Un genre simple et classique, mais efficace.

Et dans le cas de Tuxemon Tower 0, la réalisation est très basique. Cela est vrai autant du point de vue graphique que de celui du moteur. De plus, on accorde qu'on peut parfois juger que l'expérience des joueurs est médiocre (notamment car, hormis être meilleur que nous, vous allez devoir vous fader des combats juste pour avoir un niveau suffisant et on reconnaît qu'il n'y a pas trop d'intérêt ludique à regagner le même combat contre une dresseuse ou commettre un crime contre la biodiversité en enchaînant à gogo les créatures sauvages de la même zone, mais augmenter la vitesse de défilement du texte et garder enfoncé sur le bouton A permet d'écourter le temps de mise à niveau). Mais le jeu est court, donc il est escompté que la découverte et la curiosité qui l'accompagne permettent d'avoir une expérience agréable de ce mini-jeu.

Télécharger Tuxemon Tower 0

Le téléchargement des sources (code, images, etc.), de la documentation générée et des constructions pour certaines plateformes (distributions GNU/Linux et Windows) se fait via BitTorrent à travers un lien magnet. On promeut en effet la décentralisation et le fédéralisme, mais aussi la non-disponibilité permanente. De plus, ça oblige tout le monde à partager le coût (hormis les trackers, certes) et à avoir une copie des sources, tout en étant résilient.

Ce serait sympa de partager pendant l'obtention et aussi après que ce soit fait. Et on prévient : on n'est que rarement à la fois connecté à Internet (on n'a volontairement pas d'accès chez nous) et en mesure de partager via BitTorrent (on ne veut pas faire ça au boulot et il faut que ce soit permis par le réseau), donc ayez de la patience (ou ne vous plaignez pas inutilement). C'est également pour ça qu'on encourage fortement que vous continuez de partager le torrent après l'avoir entièrement obtenu et de préférence sans ratio (puisqu'il n'est pas bien lourd à la vue de la normalité actuelle, et est tout à fait légal, ça ne devrait pas vous être bien problématique).

Quelques clients BitTorrent libres

Au cas où vous n'auriez pas de client BitTorrent (ou un qui soit propriétaire), en voici quelques-uns qui sont libres :

• GNU/Linux, *BSD, Windows et/ou macOS
  • Transmission
  • Deluge
  • KTorrent
  • qBittorrent
• Android
  • LibreTorrent
  • BiglyBT

Images du jeu

Images de cartes

Images de combats

Images de menus

Comment contribuer ?

Avant d'éventuellement contribuer, n'oubliez pas plutôt en priorité de faire des choses plus importantes. En effet selon nous, mieux vaut s'activer pour l'émancipation sociale universelle et tendre vers une société écologique que de contribuer à un jeu.

1. Pour nous, la meilleure manière de contribuer est de mettre à disposition des sprites pour des créatures et des dresseurs. En effet, nous sommes très mauvais pour produire ça et cela ajouterait de la diversité bienvenue (pendant que celle sur Terre s'effondre…). Si ça vous branche, faites-le en respectant le style des actuels, avec une taille adéquate (64×64 et/ou 56×56 et/ou 48×48), et de préférence en faisant l'avant et l'arrière (car avec juste l'avant on ne peut pas jouer la créature ou la personne dresseuse mais juste l'affronter), voire en vous restreignant à 4 couleurs (c'est là la contrainte ultime, mais qui serait utile pour économiser de l'espace et deviendra nécessaire si un jour un port sur GameBoy Color est fait) et alternativement c'est déjà ça si ça ne dépasse pas la barre des 8 (qui va nous servir de transition entre 16 et 4, tout en permettant de réduire l'usage mémoire avec une petite astuce ou de la compression plus poussée que nous ne ferons probablement pas).
2. Nous n'avons pas l'intention de gérer une communauté autour de ce jeu. C'est pourquoi nous n'avons pas mis le code source sur une forge et nous ne comptons pas le faire. Rien ne vous empêche toutefois de faire une version dérivée et de la publier, peut-être que nous irons y piocher des trucs en vous créditant si nous en avons connaissance.
3. Bien sûr, si vous voulez que nous intégrions peut-être un jour une contribution, veillez à la mettre sous une licence compatible quand vous n'y êtes pas de toute façon obligé par le gauche d'auteur. Utilisez donc une licence libre, avec de préférence la GNU AGPLv3+ pour le code source et la Creative Commmons BY-SA v4.0 pour le reste.
4. Mais où mettre ce que vous produisez ? Ça vous regarde. Mais, pour que ce soit visible, le wiki du projet Tuxemon est un bon endroit ou vous pouvez faire un commentaire ci-dessous (pointant par exemple vers votre dépôt sur OpenGameArt).
5. Si vous vous y connaissez en portage ou en packaging pour votre système favori, n'hésitez pas à faire un joli paquet pour le jeu et à tenter honnêtement de le faire officiellement intégrer. Toutefois, cela ne vaut pas pour Apple iOS, Google Play, Microsoft Store, Steam de Valve, Origin d'Electronic Arts, et consorts.
6. Évidemment une autre forme de contribution est tout simplement de faire la promotion du jeu. Parlez-en !
7. Enfin, il existe un moyen rudimentaire : partager le contenu du torrent, pour qu'il soit disponible le plus de temps possible. En effet, nous sommes très loin d'être en permanence avec un accès à Internet et nous n'ouvrons pas systématiquement notre client BitTorrent favori quand nous le sommes.

Le droit d'auteur

Les licences utilisées

• La très vaste majorité du code source est sous la licence GNU AGPL en version 3.0 ou plus. Le faible reste est dans le domaine public (via une version très légèrement augmentée de la licence GNU All-Permissive ou FSFAP dans la nomenclature SPDX).
• Les sprites 16×16 sont dans le domaine public (via la licence Creative Commons 0).
• Les sprites 64×64 ont été faits par de multiples personnes et sont donc sous de multiples licences libres.

Les conséquences

• Pour le code sous GNU AGPL, c'est avec gauche d'auteur contaminant, y compris pour la fourniture par réseau (c'est l'amélioration par rapport à la GNU GPL). Si vous distribuez une version modifiée, vous devez donc en distribuer le code source et ce sous une licence compatible (le plus simple est d'utiliser la même licence et à notre connaissance c'est la seule pour du déjà existant, mais vous pouvez utiliser la GPLv3 pour du nouveau code mis dans un nouveau fichier).
• Vous pouvez faire ce que vous voulez du code sous licence GNU All-Permissive et de tous les sprites 16×16.
• Si vous utilisez un ou des sprites 64×64, vous devez au moins en créditer la ou les personnes autrices et mentionner la licence. Pour certaines, vous devez partager sous les mêmes conditions même si modification(s) (de par le gauche d'auteur de la Creative Commons BY-SA et de la GNU GPL).

Remerciements

• le projet Tuxemon originel, pour le concept et le rassemblement des sprites 64×64 et la création d'un certain nombre
• OpenGameArt et Kenney, pour les sprites 16×16
• le projet GNU, pour notamment sa « philosophie » et ses licences, ainsi que GCC
• GNU make et CMake, pour l'orchestration de la compilation et des tests
• Trisquel GNU/Linux et Debian GNU/Linux, les deux systèmes d'exploitation utilisés
• GDB et Valgrind, pour avoir bien aidé à déboguer et résoudre des problèmes de mémoire
• check, pour des tests automatiques d'exécution
• Clang, pour ses messages complémentaires à GCC
• cppcheck et splint, ainsi que KWStyle, pour des tests statiques complémentaires aux compilateurs
• toutes celles et ceux qu'on a oubliés (moyen facile de demi-esquive !)

En plus long ?

Le comité éditorial de LinuxFr.org a jugé inappropriée la version longue qui était prévue et qui lui a été soumise. De plus, il a suggéré de feuilletonner l'annonce d'origine. Mais cela ne correspond pas à notre vision éditoriale et plus généralement notre vision anthropologique (le brouhaha communicationnel nous apparaît comme néfaste et donc à ne surtout pas alimenter), et nous n'avons de toute façon pas envie d'y passer du temps (il y a pour nous bien plus important que ce petit jeu vidéo, dont la réalisation est plus pour nous un plaisir coupable qu'autre chose, à fortiori dans une phase très nette de fascisation et d'écocide).

Néanmoins l'annonce d'origine, qui contient bien plus d'explications, reste disponible. Dans le torrent, il y a les sources (sources.tar.xz) et dans celle-ci il y a l'annonce prévue à la base (news/fr/version-1-0-0_annonce.md). Et si vous voulez la publier ailleurs (en mentionnant que nous en sommes à l'origine et en différenciant bien toute modification), en entier ou sous forme partielle, elle est sous licences libres (vous pouvez choisir celle qui vous convient le mieux) avec gauche d'auteur : Creative Commons BY-SA 3.0, Creative Commons BY-SA 4.0 et GNU GPL 3.0.

Données du jeu

Consultation en jeu

Dans le menu de lancement, proposant de démarrer une nouvelle partie ou d'en charger une existante, appuyez sur Start (ou plutôt l'un des boutons qui y correspond si vous n'utilisez pas une manette ou qu'elle n'est pas reconnue ou pas bien). Cela vous fera changer de menu. Vous aurez alors une entrée « Explorer les données ». Ce n'est pas parce que ça existe que c'est exhaustif.

Documentation HTML

Dans le torrent, avec les sources et les constructions, il y a de la documentation sous forme de fichiers HTML, que vous pouvez consulter avec un navigateur web. Vous pouvez aussi la regénérer depuis les sources. Comme pour la consultation en jeu, ce n'est pas nécessairement exhaustif, mais c'est déjà ça.

Images

Liste des créatures

Liste des dresseurs et dresseuses

Annexe : temps et motivation

Au début d'un projet personnel, la motivation est souvent grande. Mais tant qu'il n'y a pas quelque chose de finalisée, il est à priori courant que la motivation tende à décroitre. En tout cas, c'est notre cas.

C'est en partie pour cela que le jeu est très simple (système ultra-basique pour les cartes, pas de possibilité d'esclavagir, pas de statut, pas de possibilité de manipulation par le joueur/joueuse d'objets non-visuels, pseudo-aléatoire en guise de non-intelligence artificielle, etc.). L'autre grosse partie de l'explication est la volonté de faire de la basse technologie (d'où entre autres que ce soit graphiquement en niveaux de gris, malgré des sprites avec des couleurs au-delà de ce spectre) et la restante est l'ajout de complexité qui nuise à l'expérience de la mécanique du jeu en ajoutant du « bruit », mais ce n'est là pas le sujet.

Venir reprocher ou se plaindre de la trop grande simplicité du jeu (qu'il aurait fallu qu'il y ait ceci et cela, etc.) peut être en soi une critique pertinente. Néanmoins, ça ferait totalement fi de l'aspect humain en ce qui concerne la production. En effet, si le jeu n'était pas aussi basique, il ne serait probablement jamais sorti de par la baisse de motivation.

C'est pourquoi le jeu est volontairement très simple. Mais c'est une fin en soi et une base. Tout ce qui a été fait pour la version 1.0.0 de ce jeu ne sera plus à faire pour une ou des éventuelles versions améliorées et un ou des éventuels autres jeux exploitant tout ou partie de ce qui a été réalisé pour celui-là.

Approximation de l'évolution de la motivation

Dans le cadre du développement de ce jeu, on utilise git, un logiciel de gestion de version. Tous les changements y sont consignés et datés. À partir des informations qu'il a enregistrées, il est donc possible d'avoir une idée de l'évolution de la motivation.

Toutefois, on ne va pas vous livrer le dépôt git (et on a expliqué pourquoi). Vous n'en aurez donc ci-après qu'une vue fort approximative, dont la génération a été faite par git-bars.

Il fournit une vue par mois du nombre de commits. C'est donc très approximatif. En effet, un commit peut avoir une taille très variable et être pour des changements importants ou mineurs. Néanmoins, ça donne tout de même une image plutôt réaliste de l'évolution de notre motivation.

On peut notamment bien voir que les débuts sont des périodes fastes. Pour début 2023, on peut constater que c'est assez peu garni, ce qui s'explique par la contre-réforme des retraites. Mais ça montre aussi un biais : en mars et en avril 2023, on n'a fait que des petits trucs pas bien importants, mais ça a engendré pas mal de commits.

Statistiques de commits par nous pour ce nouveau jeu

2024-11  61   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-10  52   ▀▀▀▀▀▀▀▀▀▀▀
2024-09  45   ▀▀▀▀▀▀▀▀▀▀
2024-08  77   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-07  19   ▀▀▀▀
2024-06  34   ▀▀▀▀▀▀▀
2024-05  62   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-04  126  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  59   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-02  96   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-01  89   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-12  52   ▀▀▀▀▀▀▀▀▀▀▀
2023-11  78   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-10  117  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-09  224  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-07  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-06  56   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-05  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-04  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  10   ▀▀
2023-01  19   ▀▀▀▀
2022-12  34   ▀▀▀▀▀▀▀
2022-11  80   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-10  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-09  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-08  88   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  138  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-05  50   ▀▀▀▀▀▀▀▀▀▀▀
2022-04  28   ▀▀▀▀▀▀
2022-03  121  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-02  131  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  144  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  133  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀
2021-05  18   ▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀

Statistiques de commits par nous pour Greycess Knight RPG

Greycess Knight RPG est la base de ce nouveau jeu. Il part donc du même dépôt git. Puisque des changements sont valables pour les 2 jeux, on les fait dans Greycess Knight RPG, ce qui occasionne des commits de fusion dans le nouveau jeu. De plus, en soustrayant les nombres de commits par mois de Greycess Knight RPG à ceux du nouveau jeu, on peut avoir le nombre de commits qui touchent aux changements nécessaires au nouveau, ou du moins en partie puisqu'on fait parfois le changement dans le nouveau jeu avant de le mettre aussi dans l'ancien ou le (quasi-)même changement dans les 2 pour faciliter la fusion. C'est pour ça qu'on met ci-après les statistiques pour Greycess Knight RPG.

2024-11  17   ▀▀▀▀▀▀▀
2024-10  9    ▀▀▀▀
2024-09  4    ▀
2024-08  20   ▀▀▀▀▀▀▀▀
2024-07  1    
2024-06  8    ▀▀▀
2024-05  15   ▀▀▀▀▀▀
2024-04  34   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  3    ▀
2024-02  10   ▀▀▀▀
2024-01  12   ▀▀▀▀▀
2023-12  16   ▀▀▀▀▀▀▀
2023-11  15   ▀▀▀▀▀▀
2023-10  13   ▀▀▀▀▀
2023-09  29   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-07  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-06  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-05  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-04  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  4    ▀
2023-01  3    ▀
2022-12  9    ▀▀▀▀
2022-11  22   ▀▀▀▀▀▀▀▀▀
2022-10  15   ▀▀▀▀▀▀
2022-09  14   ▀▀▀▀▀▀
2022-08  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  44   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  14   ▀▀▀▀▀▀
2022-05  16   ▀▀▀▀▀▀▀
2022-04  6    ▀▀
2022-03  22   ▀▀▀▀▀▀▀▀▀
2022-02  33   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  54   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀▀▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀▀
2021-05  18   ▀▀▀▀▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Par ailleurs, comme vous pouvez le voir, ça a bougé du côté de Greycess Knight RPG. Une version 1.0.2 est en cours. Mais du point de vue de l'expérience de jeu, elle n'apporte rien ou presque. Ce sera une mise à jour technique : elle consistera essentiellement en une amélioration du code source (de diverses manières et à divers endroits) et en une réduction par 3 de la taille du binaire sans la bibliothèque SDL2 statiquement liée (ce qui l'amènera à environ 250 ko grâce à la correction d'une erreur stupide).