Unvanquished Zone 51

Le jeu Unvanquished est sorti ce dimanche 9 décembre en version alpha 0.51, après plus de deux ans de développement. Voici donc une note de version détaillée de cette fournée !

Note : Ceci est une traduction de la note de version officielle que j’ai écrite pour le projet Unvanquished, un jeu vidéo de stratégie en temps réel à la première personne opposant dans un futur intersidéral une espèce extra‐terrestre et l’humanité.

Sommaire

• Metteur à jour, lanceur de jeu !
• Changements dans la mécanique de jeu
  • Minage de ressource et contrôle de territoire
  • Dretch + Tourelle = 💜
  • Mouvements des joueurs
  • Indicateur de dommages
  • Amélioration du « spiker »
• Gros travail sur les données de jeu
  • Nettoyage
  • Modèles
  • Les sons
  • Les cartes
  • Du côté communautaire
  • Amorçage
• Polissage du code du jeu
  • De meilleurs « bots »
  • Animation de modèle, interface utilisateur, lecture audio
  • Réseau, initialisation, système de composant
  • Options de développeur
• Amélioration du moteur
  • Le grand débarras des vieilleries
  • Aller de l’avant
  • Traiter avec des pilotes défectueux et corriger nos propres erreurs
  • Rendre le moteur plus accueillant
  • Meilleur code
  • Encore plus
  • Remerciements
  • Contribuer

Cette traduction est sous licence CC0 1.0.

Nous l’avons donc fait ! Voici notre dernière, tant attendue publication, la version 0.51 ! Se servir tant que c’est chaud !

Il y a eu énormément de changements dans cette version depuis que la précédente a été publiée il y a deux ans et huit mois et, le développement ne sommeillant pas, il sera difficile de tout raconter.

Cependant, le code du jeu lui‐même est vraiment très stable, vu que nous avons été capables de rétro‐porter presque tout sur la précédente version à travers les années. Je dis « presque tout » parce qu’un bogue (désormais corrigé) du système de fichiers nous a empêché de surcharger indéfiniment nos paquets avec des nouveaux, ce qui nous a empêché de faire étalage de certains de nos modèles. Mais le gameplay fut entièrement rétro‐porté et les joueurs étaient en mesure d’y jouer depuis plus d’un an avec leur client 0.50 non modifié, rien qu’en rejoignant des serveurs. C’est un très bon point pour nous, et cela démontre la robustesse de l’architecture et prouve que le moteur Dæmon est une solide plate‐forme de modification.

Vous savez déjà que kharnov a quitté le projet et, puisque c’est notre première version sans lui, nous lui dédions cette alpha 51. Nous savons combien il a intensément attendu cette version et espérait tant voir celle‐ci devenir la première bêta. Ne t’inquiète pas kharnov, la bêta est toute proche. Pour le rappeler à nos lecteurs, nous catégorisons nos versions alpha et bêta non à cause de leur stabilité mais en fonction de la complétude de nos objectifs. Celle version est signalée comme une version alpha, même si nous aurions voulu mettre dessus l’étiquette bêta. Mais, jouons la prudence : nous préférons appeler bêta quelque chose que les joueurs ont eu en main. 🙂

Vous remarquerez probablement que le jeu possède des chaînes de version 0.51.1 à certains endroits, nous avons sournoisement étiqueté une version 0.51.0 quelques semaines plus tôt qui agît un peu comme une candidate à la publication. Après quelques corrections de dernière minute, nous sommes prêts pour distribuer publiquement le jeu à nouveau ! Joie !

Metteur à jour, lanceur de jeu !

  Le metteur à jour d’Unvanquished

Nous accueillons donc notre nouveau metteur à jour ! Nous le distribuons désormais officiellement et c’est maintenant le moyen officiel de télécharger et mettre à jour Unvanquished. Au fond, c’est un lanceur d’Unvanquished. Vous téléchargez simplement un binaire, vous le lancez, et il récupère ce qui manque avant de lancer le jeu. La prochaine fois que vous le lancerez, le jeu sera mis à jour avant d’être démarré si une nouvelle version est disponible.

Ce metteur à jour donne aussi un aperçu du dernier billet de blog. Donc, pendant que vous attendez pour la mise à jour, vous verrez qu’il y a des nouvelles et vous cliquerez juste dessus pour lire l’article comple  !

Même s’il n’était pas annoncé, certaines personnes utilisaient déjà la précédente itération de ce metteur à jour, nous avons donc été en mesure d’écouter les besoins et idées pour le rendre meilleur. Non seulement le comportement fut amélioré pour répondre aux besoins des joueurs, mais le metteur à jour fut entièrement refait en utilisant QML et présente mieux ! Ce metteur à jour est le fruit du travail d’Ishq, sur la base d’une maquette de Gireen.

Changements dans la mécanique de jeu

Parlons à présent du changement de gameplay, puisque c’est ce qui fait sens dans le développement d’un jeu !

Minage de ressource et contrôle de territoire

Cette version introduit un important changement dans la manière dont les points de constructions sont gérés. Vous connaissez peut‐être le drill (foreuse) et le leech (sangsue) si vous avez déjà joué au jeu avant. La foreuse est une machine humaine qui mine des points de construction et la sangsue est l’alter ego extra‐terrestre, un être vivant, étant donnée la nature de cette espèce.

Chaque foreuse ou sangsue construite contribue une certaine quantité de points de construction et de puissance au fond commun de l’équipe, qui est désormais global et non rattaché aux lieux. Les autres constructions comme les tourelles, les armureries, tubes d’acides et les œufs consomment les points de construction et la puissance fournie par les foreuses et sangsues. Cela signifie que ces foreuses et sangsues doivent être défendues puisque leur destruction laisse non alimentées les constructions dépendantes. De plus, lorsqu’une construction est détruite, cela prend du temps pour les points de construction utilisés d’être réintroduits dans le fond commun.

Pour être efficaces, les foreuses et sangsues doivent maintenir une certaine distance entre elles. Ce changement de gameplay encourage les guerres de territoire dans la façon dont les équipes ont besoin de contrôler des territoires extérieurs pour construire des foreuses ou sangsues éloignées, comme le requiert la construction de leurs base. Puisque le mécanisme rend les constructions dépendantes des appareils de minage, cela apporte une alternative à l’ancienne mort subite de Tremulous : plus le jeu dure longtemps, plus cela prend du temps de recouvrir les points de construction après la destruction d’une structure, affaiblissant la base la moins bien gérée et accélérant conséquemment sa destruction.

    La foreuse

Le répéteur est désormais enlevé. Le répéteur était la structure humaine construite pour alimenter les autres constructions dans les bases avancées. Maintenant, la foreuse fait aussi le travail du répéteur : minant les ressources, les stockant et alimentant le tout, y compris les bases avancées. Puisque le répéteur avait un modèle plus beau que celui de la foreuse, la foreuse réutilise le modèle du répéteur et le modèle de la foreuse est désormais retirée. Fondamentalement, ce modèle ressemble à un petit « réacteur », ce qui fait beaucoup sens : le réacteur est le générateur principal de puissance et le centre nerveux.

Dretch + Tourelle = 💜

Les dretchs sont à nouveau capables d’attaquer les tourelles et les rocket pods ! Les dretchs sont l’une des deux formes extra‐terrestres qu’un joueur peut choisir pour (ré)apparaître en jeu, l’autre étant la forme de constructeur granger. Le dretch est une petite et faible forme d’attaque que le joueur extra‐terrestre utilise avant de se transformer en de plus fortes et meurtrières formes. Le jeu Tremulous original permettait à ces dretchs d’attaquer les structures défensives comme les tourelles, mais cette fonctionnalité avait été désactivée dans la gameplay preview (GPP) de la version 1.2 qui ne fut jamais distribuée. Les joueurs demandaient le retour de cette fonctionnalité et ça faisait beaucoup sens parce que cela semblait assez incohérent qu’un extraterrestre seul ne puisse pas être en mesure de détruire une base humaine quand un joueur humain sans protection et seul pouvait détruire une base extra‐terrestre.

Mouvements des joueurs

Quelques changements ont été implémentés dans la façon dont les joueurs se déplacent, tel que demandés par certains joueurs, en les écoutant et prenant soin des problèmes qu’ils rapportent. Il est désormais possible de sauter sur les murs pour atteindre certaines plates‐formes plus facilement. Le glissement humain a été un peu modifié et l’esquive humaine a été désactivée.

Indicateur de dommages

Enneract a implémenté cet excellent changement ! Les joueurs ont maintenant un retour visuel montrant combien efficace est leur attaque. Cela aidera aussi les joueurs à comprendre naturellement quelle arme ou attaque est meilleure pour chaque situation, et combien leur visée est bien entraînée, ou s’il y a encore de la place pour du perfectionnement !

  Indicateur de dommages

Amélioration du « spiker »

Le spiker a été amélioré pour le rendre plus utile et efficace. Le spiker est une construction extra‐terrestre de défense qui lance des épines mortelles sur les humains insouciants. Désormais, le spiker décoche ses épines seulement si les dommages attendus atteignent un certain seuil, pour ne pas gaspiller son attaque mortelle (elle se recharge lentement), et il essaie désormais d’éviter le tir ami quand d’autres structures extra‐terrestres sont en ligne de mire. Précédemment, son comportement par défaut était de ne pas attaquer en cas de tir ami, mais cela le rendait inutile quand une autre construction n’était pas correctement positionnée. Désormais, le spiker vise la cible plus précisément pour éviter d’endommager les structures de son équipe. Les épines elle‐mêmes ont reçu une compensation de leur gravité.

Gros travail sur les données de jeu

Vous l’avez probablement remarqué si vous avez lu les précédents billets : un gros travail a été fait sur le plan de la gestion des données. Elles ne sont pas seulement désormais hébergées dans des dépôts Git, nous avons reconstruit leur historique passé lorsque c’était possible, en rejouant les précédents paquets sur l’arbre, par exemple.

Nettoyage

Un gros nettoyage a été fait, éliminant les laissés‐pour‐compte et en dédupliquant les choses. Notre système de gestion de paquets nous permettait de surcharger des paquets précédemment publiés, mais cela ne faisait qu’ajouter de nouveaux fichiers à ceux existant, puisque tous les paquets précédemment publiés devaient être distribués dans tous les cas.

Quelques corrections ont été faites sur le set de textures communes, pour renommer ou abandonner des choses obsolètes. Les sets de textures ej01 ont été fusionnés en un seul, le modèle de répéteur a été abandonné comme expliqué, et il y a eu beaucoup de nettoyage dans les shaders. Ici le mot shader est à entendre comme un « shader Quake 3 », un moyen simple de définir des matériaux, pas comme un « shader GLSL ». L’ensemble de la collection de données a subi une grande quantité de renommages pour unifier les choses et standardiser plus encore.

Pour donner quelques nombres, l’alpha 50 pesait 737 Mio avec 6 322 fichiers, quand l’alpha 51 pèse 488 Mio avec 4 178 fichiers. C’est une économie de 34 % !

Modèles

Cette publication introduit aussi le nouveau modèle du dragon et le nouveau modèle de l’exosquelette ! Le dragon est un modèle de Raphaël « RXMT » Moreault‐Truchon​ et l’exosquelette un modèle de Luiz Henrique « lhdc » de Camargo.

  Le dragon et l’exosquelette

L’ancienne main a été repeinte. L’ancienne main est le modèle de main à la première personne qui est utilisée avec les anciennes armes qui ne sont pas encore remplacées. Certaines d’entre elles ne sont pas si mal et, puisque nous sommes en besoin d’animateur et d’implémenteur, il convient de les garder pour un temps. Avec cette main repeinte de manière à ressembler à la nouvelle, il y a beaucoup moins d’incohérences affichées à l’écran !

  De gauche à droite : ancienne main avec le fusil à impulsion, ancienne main repeinte, nouvelle main avec le fusil à pompe

Bien que le moteur soit en mesure de translater, tourner ou redimensionner les modèles à l’exécution en se servant de fichiers de configuration, nous le faisons désormais au moment de construire les données et nous les distribuons déjà translatées, tournées et redimensionnées pour que les outils tierce‐partie comme des éditeurs de niveaux puissent aussi les afficher correctement. Un bogue a été trouvé du côté du moteur concernant le zOffset (translation verticale), donc les modèles ont été corrigés pour être affichés correctement après la correction de ce bogue.

Les sons

Du travail a commencé du côté de la face cachée du son. Obani en a contribué quelques‐uns (le son du jetpack, le son de pré‐construction), et quelques‐uns ont été repris de dépôts de données libres comme opengameart, provenant de divers auteurs, quand ces sons étaient suffisamment proches de ce que nous avions déjà (bruit de tir de la mitrailleuse, les pas de l’exosquelette…). Après une vérification des licences certains sons de Tremulous qui ont été vérifiés comme sûrs ont été réimportés.

Nous distribuons désormais un paquet de ressources nommé res‐legacy pour fournir des choses héritées de Tremulous qui ont à être remplacées ou déplacées vers d’autres dépôts quand elles sont vérifiées comme sûres et libres. Ce paquet distribue des substituts qui ont vocation à être entièrement abandonnés un jour. Donc, s’il vous plaît, ne mettez pas ce paquet dans les dépendances de vos propres paquets.

Les cartes

Un gros chargement de corrections de cartes est apporté par cette version : des lieux où le granger pouvait construire à l’extérieur de la zone de combat dans Antares, Perseus et Spacetracks sont maintenant marqués comme non constructibles. Un endroit où le spectateur pouvait quitter la zone de combat dans Perseus a été scellé.

Dans Thunder, un mobilier extérieur permettait par erreur aux joueurs de s’y cacher, ce modèle est désormais proprement clippé (N. D. L. A. : un clip est une surface spéciale qui découpe l’espace en zones traversables ou non selon la nature de l’objet qui tente de traverser). Dans Spacetracks quelques surfaces avec un « clip complet » ont reçu un « clip d’arme » à la place pour permette aux projectiles de traverses les portes entrouvertes sans laisser les joueurs sortir de la carte.

  Porte entrouverte sur Spacetracks : les projectiles ne sont désormais plus clippés

Sur la carte Chasm du travail fut réalisé pour empêcher le granger de construire des œufs au bord du ciel ou bien à l’intérieur du gouffre, et des systèmes de particules de flocons de neige ont été ajoutés à un endroit où ça manquait. La carte Chasm a aussi reçu des optimisations de hint (N. D. L. A. : un hint est une surface indicative qui permet au compilateur de carte d’optimiser les calculs de visibilité et donc les performances).

  Cela requérait une dextérité vraiment impressionnante, mais c’était possible. Oups !

Les cartes comme Parpax, Station15, Spacetracks et Chasm ont fait l’objet d’un travail de caulk (N. D. L. A. : un _caulk est une surface spéciale qui n’est pas affichée et qui n’a aucun effet en jeu, elle est même généralement supprimée à la compilation ; ces surfaces sont utilisées sur les faces invisibles des polygones à des fins d’optimisation_), réduisant parfois la taille des cartes de lumières (lightmaps) par un quart pour les deux dernières (N. D. L. A. : les cartes de lumière sont des textures décrivant les jeux d’ombres et de lumières pré‐calculées pour toutes les surfaces). Thunder a vu certaines textures manquantes corrigées en même temps qu’un gros effort de déduplication : cette carte est antérieure à la plupart des sets de textures, mais elle repose désormais sur eux.

Quelques changements mineurs ont été faits par Viech sur Parpax, et EmperorJack a mis à jour sa carte Forlorn en bêta 1. Vous avez tout ça dans cette version.

Du côté communautaire

Supertanker a publié une préversion d’une carte urbaine appelée Freeway qui n’est pas encore distribué avec le jeu, parce qu’il y a encore beaucoup de travail à faire, mais vous pouvez déjà l’essayer sur les serveurs !

  La carte Freeway à venir

Du côté communautaire, certains cartographes ont fait de chouette cartes qui vous enjoueront peut‐être sur les serveurs. Bien que non officielles, elles valent le détour et le jeu : Matth a publié une refonte de la bonne vieille carte Tremor sous le nom « USS Tremor », une refonte d’UTCS sous le nom CTCS et aussi une carte dans un univers désertique, appelée Fortification, avec un plan qui rappelle ATCS. Vous remarquerez l’impressionnante carte Hangar28 de tvezet, qui raconte tant d’histoires par elle‐même. Freeslave a porté sa carte Stalkyard pour Unvanquished, et cu-kai fait de même avec sa carte combat-t3. Donc, en même temps que les mises à jour officielles, il y a plein de truc nouveaux à apprécier sur les serveurs.

Amorçage

Le dossier main/ du dépôt Unvanquished est désormais extrait comme un dépôt à part entière nommé « unvanquished_src.dpkdir » et réimporté comme sous‐module dans le dossier pkg/ du dépôt Unvanquished. Ce dépôt de paquets ne contient pas suffisamment de choses pour jouer au jeu mais en a suffisamment pour démarrer le jeu, rejoindre un serveur et récupérer tout le reste à partir de là.

Polissage du code du jeu

Bon, il va être difficile de rapporter toutes les corrections, mais essayons tout de même. Pour commencer, les données ne sont pas les seules à avoir subi un grand nettoyage, le code aussi et du code résiduel a été supprimé.

De meilleurs « bots »

Les bots peuvent désormais se débloquer eux‐mêmes et le remplissage de bot a été implémenté (commande bot fill) : c’est la méthode de gestion des bots communément implémentée sur les jeux en ligne où une réserve de bots est introduite sur les serveurs vides puis automatiquement retirée au fur et à mesure que de vrais joueurs rejoignent la partie. Ces deux fonctionnalités étaient attendues depuis longtemps.

Toujours du côté des bots, le code de jeu retire désormais les bots à la fin du jeu quand une carte est redémarrée, et une division par zéro se produisant quand l’habileté d’un bot était de 10 est désormais corrigée.

Animation de modèle, interface utilisateur, lecture audio

Quelques interpolations défectueuses d’animation affectant la fluidité des modèles sont corrigées, l’animation par squelette a été refactorisée, les attaques du spiker et de l’overmind ne sont plus interrompues par les animations de douleur. Les joueurs ne s’inclinent plus deux fois dans le sens de leur marche. Comme dit précédemment, l’interprétation des dimensions des modèles a été corrigée et les modèles redimensionnés en conséquence.

Au sujet de l’interface utilisateur, le filtrage listmap et son affichage ont été corrigés (c’est une fonctionnalité de console), plus de choses sont relancées au redémarrage des cartes pour retirer le tableau des scores de l’écran dans ce genre de situation par exemple, et les longues chaînes de caractères ne déplacent plus les éléments dans les tableaux : avant ça, les longs noms d’utilisateur mettaient la pagaille dans le tableau des scores, de même avec les longs noms de serveurs dans la liste des serveurs : c’est désormais corrigé.

  Les longs noms ne déplacent plus les autres éléments

Les chemins d’accès des fichiers de son sont désormais indépendants de leur extension. Ceci nous permet de distribuer de nouveaux sons en utilisant un nouveau format sans avoir à se soucier de ce que l’ancien format soit toujours là dans les anciens paquets. Avant ça, si un effet sonore obsolète était appelé son.wav et son remplacement utilisait un format plus récent et était nommé son.opus, l’ancien aurait été chargé dans tous les cas. À présent, le fichier le plus récent est prioritaire, quel que soit le format.

Réseau, initialisation, système de composant

Un vilain bogue a été corrigé dans le paquet inforesponse. C’est utilisé par les outils d’interrogation et l’explorateur de serveur tierce partie comme qstat ou XQF (dont on a déjà parlé dans ces colonnes) et le bogue affichait simplement une quantité erronée de joueurs quand on interrogeait les serveurs.

Quand le jeu était démarré pour la toute première fois quelques options d’initialisation n’étaient pas faites, menant à un menu de configuration erroné. C’est corrigé. Un plantage se produisant lors des redémarrages avec switchteam est également corrigé.

Le système de composants a été profondément remanié, particulièrement du côté des constructions, et les composants de pensée ont été optimisés.

Options de développeur

Une nouvelle triche give bp a été ajoutée pour se donner à soi‐même une quantité arbitraire de points de construction en vue de tests, et une nouvelle option de développeur appelée g_neverEnd a été ajoutée pour ne pas terminer le jeu même s’il n’y a plus du tout de points de réapparition. Ceci est utile pour les cartographes qui ont besoin de tester leur travail en cours ou pour les développeurs qui doivent ouvrir des cartes dans Unvanquished provenant d’autres jeux, alors qu’ils travaillent sur un portage et que leur jeu n’est pas encore complet. Ils ont simplement à activer cette option et à charger cette carte avec devmap.

Une petite bidouille a été introduite pour empêcher le clip de l’arme de l’exosquelette. Du code mort a été retiré, merci à Slipher d’en avoir pris soin. Oh, et le jeu peut désormais être construit contre un dossier du moteur Dæmon stocké à l’extérieur de l’arbre des sources d’Unvanquished.

De nombreux correctifs ont été apportés grâce à de l’analyse statique. C’est vrai aussi pour le code du moteur.

Amélioration du moteur

Cette version casse la compatibilité avec les précédentes versions sous plusieurs aspects : gestion de paquets, stockage des données des utilisateurs, entrée… Puisque la compatibilité allait être cassée dans tous les cas, c’était le meilleur moment pour implémenter tous les autres changements qui cassent la compatibilité et qui attendaient depuis longtemps. C’était le moment de se défaire des vieilleries.

Le grand débarras des vieilleries

Nous avons donc basculé vers le format de paquet DPK, comme expliqué dans un article précédent.

C’est le moment d’annoncer une importante amélioration sur le plan de l’utilisabilité : il faut remercier le travail de Slipher, qui permet aux utilisateurs d’associer des caractères non‐ASCII, et il y a plusieurs manières d’associer une touche, l’une d’entre elle utilisant des identifiants matériels qui sont indépendants de l’agencement du clavier. Cela signifie que nous pouvons dès maintenant distribuer une carte de touches qui fonctionne quel que soit l’agencement du clavier et la langue, tout en permettant aux personnes de la personnaliser en utilisant les noms des touches dans leur propre langue. Il faut noter que les anciennes associations de touches sont automatiquement converties depuis les précédents paramètres pour être utilisées dans le nouveau moteur, mais elles ne seront pas utilisables par des moteurs plus anciens après ça. EACFreddy a aussi travaillé à une meilleure prise en charge des manettes de jeu.

Le stockage des données utilisateur suit maintenant les recommandations XDG sous GNU/Linux. Donc, à moins que vous ayez des variables d’environnement personnalisées, le moteur utilise désormais le chemin ~/.local/share/unvanquished sous GNU/Linux, déplaçant automatiquement l’ancien dossier caché ~/.unvanquished.

Aller de l’avant

Nous avons aussi mis à jour le code de Crunch en le rebasant sur l’amont d’Unity… Crunch est un outil de compression et un format d’image à destination des cartes graphiques : les textures peuvent être distribuées dans un format compressé qui peut être déchargé directement vers la carte graphique, économisant de l’espace disque, de la mémoire vive principale, du calcul processeur et de la bande passante, et donc du temps de chargement. Crunch est un outil et un format initialement développé par BinomialLLC, mais, plus tard, Unity a mis ses mains dans le code et l’a beaucoup amélioré. Par beaucoup, je veux dire beaucoup.

Les gens d’Unity disent que leur outil crunch modifié « peux compresser jusqu’à 2,5 fois plus rapidement, tout en produisant un meilleur taux de compression de 10 % ». Nous avons donc mené un test sur notre propre dépôt de données, « re‐crunchant » tous les paquets de ressources et de textures. Le corpus donné au moment où nous fîmes les tests produisirent 1 797 fichiers .crn. Nous avons comparé notre ancien outil crunch basé sur le code de BinomialLLC et le nouveau d’Unity avec nos modifications apportées. Nous avons recompilé l’exécutable, il n’y a donc pas de biais sur ce plan‐là. Et voici les résultats :

Le crunch de BinomialLLC :

• temps de compression : 115 minutes et 8 secondes ;
• taille des fichiers produits : 269 mégaoctets.

Le crunch d’Unity :

• temps de compression : 26 minutes et 43 secondes ;
• taille des fichiers produits : 239 mégaoctets.

Donc, l’outil crunch d’Unity réduit le temps de compression par 4,31 et réduit la taille par 11,15 %. Ils disaient « jusqu’à 2,5 fois plus rapide », mais nous avons vu certaines textures être compressées six fois plus rapidement, et la moyenne de l’ensemble est 4,3 fois plus rapide. Et oui, l’outil compresse mieux que 10 %, plus intensément. Les résultats sont impressionnants et sont beaux à voir.

Le point noir, c’est que ce nouvel outil crunch casse la compatibilité du format pour pouvoir réaliser ces améliorations (en lire plus dans nos forums), cependant le code de BinomialLLC est en dormance, tandis que celui d’Unity est non seulement actif mais aussi implémenté dans Unity (c’est une large base d’utilisateur). Et même l’auteur original de chez BinomialLLC semble avoir lui‐même embranché l’arbre d’Unity ; donc, nous avons sauté le pas.

L’amont d’Unity semble ne pas fusionner les demandes de fusion, donc si vous êtes un développeur de jeu intéressé par Crunch, jetez un œil à notre divergence du code source qui maintient des corrections de compilation pour GNU/Linux et macOS, un Makefile corrigé, une intégration avec l’outil CMake (il semble que les gens d’Unity se focalisent uniquement sur Windows et Visual Studio), la personnalisation d’assertion et une normalisation optionnelle de carte normale, tout en restant synchronisé avec l’amont d’Unity.

Traiter avec des pilotes défectueux et corriger nos propres erreurs

Un plantage se produisant avec du matériel et du logiciel NVIDIA spécifique est désormais corrigé. Ce bogue était ennuyeux et même la quantité massive de fichiers journaux partagés par les joueurs dans les rapports de bogue n’était pas suffisante pour circonscrire correctement le problème. Heureusement, quelqu’un dans l’équipe de développement réussit à mettre la main sur ce bout de rebut défectueux, nous permettant de reproduire et contourner le problème puisque nous savons que le pilote ne sera plus jamais mis à jour.

Nous avons corrigé une erreur GLSL qui plantait le jeu sur des pilotes correctes parce que, eh, pas seulement les autres font des erreurs, mais au moins, nous, nous corrigeons les nôtres. Un bogue en rapport avec le light culling est désormais corrigé. Le shader SSAO est désormais corrigé sous OpenGL 2.1, et quelques incompatibilités avec OpenGL 2.x sont corrigées.

Un méchant bogue menant à un crash quand de trop nombreux avertissements étaient affichés dans le terminal de l’utilisateur est désormais corrigé. Toujours du côté du terminal, une mauvaise initialisation causant un problème d’affichage de la console ncurses est désormais une chose du passé.

Nous avons découvert un problème lié à la gestion des canaux privés (la quantité de personnes connectées était fausse dans certains cas), désormais corrigé.

Rendre le moteur plus accueillant

  Ce granger est très accueillant

Pour améliorer la compatibilité avec d’autres jeux essayant de se porter vers le moteur Dæmon, la prise en charge de DXT3 et BC2 a été ajoutée, c’est utilisé dans certains formats d’image comme le DDS (DirectDraw Surfaces). Le moteur prend maintenant en charge le préfixe dds/ que des moteurs de jeu comme celui de Doom 3 ou encore Darkplaces attendent. L’interprétation des shaders n’avorte plus en cas d’avertissement (nous parlons toujours de matériau Quake 3). C’était une erreur, puisque les avertissements sont pensés pour avertir, pas pour avorter. Et ce correctif aide aussi les données de tierces parties à être chargées même si elles sont incomplètes ou essaient d’utiliser des fonctionnalités non prises en charge.

Le moteur ne recompresse plus salement les skyboxes (N. D. L. A. : une _skybox est une texture spéciale en forme de cube vu de l’intérieur qui représente l’environnement lointain tout autour d’une carte, généralement le ciel_). Cela utilisait avant la très inefficace compression OpenGL, et nous ne faisons plus ce genre de chose puisque la compression de texture est désormais prise en charge au moment de construire les données, sélectionnant le meilleur format pour un bon affichage, un chargement court, et de hauts résultats de compression. Cette recompression inefficace produisait de très laides skyboxes. Et c’était très problématique, puisqu’une skybox dessine une image statique devant les yeux du joueur par conception, remplissant parfois l’écran entier. Ainsi, un artefact serait très visible et ennuyeux, et ce n’est pas acceptable.

Les shaders GLSL sont désormais embarqués dans le moteur au moment de la compilation. Quelques efforts ont été faits pour rendre le moteur plus autonome, faisant en sorte que certains fichiers de police de caractère soient optionnels, par exemple. Ce travail n’est pas complet : le moteur a toujours besoin de quelques données pour se charger, mais c’est mieux qu’avant. Autonomiser le moteur rend le portage de jeux plus facile.

Le code de démo a été nettoyé par Melanosuchus (N. D. L. A. : une démo est un enregistrement de tous les événements du jeu qui peuvent être rejoués par le moteur), les cvars ont été proprement renommées et des fonctionnalités cassées ont été retirées (N. D. L. A. : une _cvar est une forme de variable utilisée dans le jeu que le joueur peut configurer depuis la console intégrée_). Melanosuchus était celui qui avait déjà importé les codes de couleur RGB depuis Xonotic à l’époque de la version 0.43. Cette fois‐ci, T4im a apporté des corrections au code de couleur.

Meilleur code

Le machin mathématique des quaternions a été remanié, ne comptez‐pas sur moi pour expliquer ça en détails. Le moteur utilise désormais des appels non bloquants pour générer de l’aléa si possible. Quelques modernisations de C++ ont été dirigées par T4im. Gimhael a corrigé un bogue se produisant avec des cartes n’ayant pas de lightmap, un bogue qui a été découvert par nos amis du projet en chantier UnrealArena.

Un problème lié à breakpad (outil de rapport de crash) a été corrigé et un problème empêchant de construire le moteur depuis un dossier extérieur à l’arbre des sources a reçu une correction. Le problème de système de fichiers nous empêchant de publier des préversions dans certains cas a été corrigé, comme dit précédemment.

Encore plus

Il y a eu beaucoup de travail réalisé sur la chaîne d’édition de carte, l’éditeur de carte NetRadiant et le compilateur de carte q3map2 sont désormais pleinement pris en charge. Il y a tellement à dire qu’un billet dédié est requis. Restez à l’écoute !

Le moteur peut désormais interroger plusieurs serveurs maîtres, et maintenant le jeu le fait : nous avons mis en place un serveur maître secondaire (master2.unvanquished.net), il rend le jeu plus résilient quand de mauvaises choses se produisent.

Nous attendons toujours la permission restante de dsalt pour basculer le Wiki depuis la licence non libre CC By-NC-SA vers la licence libre CC By-SA. Nous sommes toujours sans nouvelle de chris807, ses modèles étant les derniers à ne pas être sous la même licence que les autres.

Comme annoncé dans les précédentes publications, nous avons désormais une page pour suivre l’activité du développement et un salon discord a été ouvert. Les canaux IRC vous accueillent toujours, rejoignez‐nous et prenez part à un gros et excitant projet comme Unvanquished !

Nos amis de Smokin’ Guns ont annoncé une tentative de porter leur jeu vers le moteur Dæmon, espérons que cela sera un succès parce que ce jeu est vraiment amusant et mérite un rafraîchissement !

Remerciements

Il serait difficile de nommer tous ceux qui ont été impliqués dans cette publication, mais nous remercions profondément tous ceux de l’équipe et chacun des contributeurs.

Contribuer

Nous avons besoin d’animateur et d’implémenteur pour pouvoir distribuer certains de nouveaux modèles qui sont déjà modelés. Le jeu a besoin d’un écran de vote de carte, avoir des démos côté serveur comme Xonotic serait appréciable, importer l’effet d’eau et les lightmaps sRGB depuis le moteur Darkplaces serait excellent, expérimenter avec WebAssembly dans l’intention de remplacer Native Client un jour serait une bonne chose pour notre système de bac à sable.

Nous avons toujours besoin de nouveaux sons, quelqu’un a dit qu’il travaillait à refaire la bibliothèque sonore. Donc, si vous désirez contribuer sur cette partie, c’est mieux de le contacter.

Et maintenant la meilleure chose à faire : jouons !

Aller plus loin

• Télécharger Unvanquished (412 clics)
• Histoire d’un arbre (152 clics)
• Unvanquished toujours sur les rails ! (173 clics)
• Unvanquished Area 51 (article original) (119 clics)