Journal Sortie de Freedoom 0.11

Sommaire

• • Nouveautés
  • Quelques mots sur le développement
  • Futur du projet
  • Fin

Freedoom¹ est un projet visant à créer un set de données libres pour les "source ports", c'est-à-dire les moteurs basés sur le moteur idTech 1, moteur de FPS en 3D publié sous licence GPL par id Software en 1999 (apparemment il a aussi été publié sous licence MIT plus tard mais j'arrive pas à savoir quand). Freedoom désigne aussi, suivant le contexte, le set de données publié par le projet Freedoom, ou tout jeu complet composé d'un source port + des données de Freedoom.

Le projet se décompose en trois sous-projets. Freedoom: Phase 1 ou "freedoom1" est un FPS linéaire découpé en quatre chapitres de huit ou neuf niveaux chacun (35 niveaux au total dans Freedoom 0.11) dans lesquels le joueur est confronté à 10 sortes de monstres différents, avec 7 armes mécaniques à sa disposition. Freedoom: Phase 2 ou "freedoom2" est un FPS linéaire d'une trentaine de niveaux (32 dans Freedoom 0.11), où le joueur retrouve les monstres et les armes de la phase 1, ainsi que sept nouveaux monstres et une arme supplémentaire. FreeDM ou "freedm" est un FPS d'arène contenant une trentaine de maps (32 dans Freedoom 0.11) sans monstres. FreeDM est pensé pour être joué en multijoueur, notamment en DM/duel, mais il faut noter que les maps de freedoom1 et freedoom2 ont aussi été conçues pour être jouables en DM/duel, en plus du mode linéaire.

Freedoom est sous licence BSD-new. Notons que Freedoom: Phase 1 et Freedoom: Phase 2, comme beaucoup de jeux libres, sont des clones de jeux non-libres, visant à être compatibles avec ceux-ci.

Nouveautés

Freedoom 0.11 est sortie le 16 février 2017. Par rapport aux versions précédentes 0.10 et 0.10.1, sorties en décembre 2015, elle apporte les changements suivants :

• De nouvelles maps sur freedoom1 et freedoom2, bien souvent en remplacement d'anciennes;

• Des mises à jour de maps sur freedoom1 et freedoom2, visant à améliorer le gameplay, améliorer les performances, résoudre des bugs, notamment :

• La suppression des "Boomismes" : des fonctionnalités avancées de certaines maps spécifiques aux moteurs basés sur Boom, et qui ne fonctionnaient pas avec les autres moteurs. Par conséquent, Freedoom 0.11 devrait rendre freedoom1 et freedoom2 compatibles avec la plupart des moteurs existants (notamment Doomsday, chocolate-doom, et GZDoom-GPL sans son mode de compatibilité Boom). Le but, à terme, est de rendre freedoom1 et freedoom2 vanilla-compatibles, c'est à dire compatibles avec tous les moteurs y compris le moteur d'origine publié par id Software. Notez que FreeDM a toujours été vanilla-compatible, donc rien de nouveau de ce côté-là.

• De nouvelles textures de maps;

• De nouveaux sprites pour le Handgun, le pack de stéroïdes, les bonus d'armure et de santé, les packs de santé, et pratiquement toutes les recharges de munition;

• Beaucoup de nouvelles musiques;

• De nouveaux noms pour les monstres, notamment :

  • Le Serpent est maintenant le Serpentipede
  • Le Worm et l'Invisible Worm sont désormais nommés Flesh Worm et Stealth Worm
  • L'Orb monster s'appelle maintenant le Trilobite
  • La Deadflare Ball s'appelle maintenant le Summoner

• De nouvelles textures d'entracte et un nouveau logo :

• Plein de corrections de bugs

• Et évidemment, plein de nouveaux bugs pour compenser. Une version 0.11.1 devrait voir le jour bientôt.

Notons que seuls freedoom1 et freedoom2 ont eu des changements significatifs lors de cette release. FreeDM voit simplement son numéro de version poussé à 0.11 (il hérite cependant des nouvelles sprites communes à tous les sous-projets, bien évidemment).

Quelques mots sur le développement

La suppression des Boomismes et la compatibilité avec la quasi-totalité des source ports constitue un jalon important dans le développement de Freedoom. En effet la compatibilité vanilla a toujours été un des objectifs majeurs du projet.

Pourtant, le 2 janvier 2017, la communauté s'alarme. Après avoir testé la compatibilité vanilla sur chocolate-doom, l'un des principaux développeurs du projet fait remarquer que la plupart, sinon la totalité des maps de Freedoom est soumise à un bug bien connu : le "savegame buffer overrun". Ce bug apparaît lorsque le joueur tente de sauvegarder une partie qui prend plus de place en mémoire que ce qui était prévu par le moteur id Tech d'origine, ce qui cause un crash du jeu. Or, si la plupart des source ports avancé corrigent ce bug énervant, ce n'est pas le cas de moteurs vanilla tels chocolate-doom, qui cherchent à préserver tous les aspects de l'expérience utilisateur d'origine, y compris les bugs ! Il existe bien une option de configuration (buffer protection) pour corriger ce bug, mais celle-ci est désactivée par défaut.

Cela signifierait donc que si le projet Freedoom veut pouvoir continuer, il doit soit abandonner l'un de ses principaux objectifs, soit refaire à partir de zéro toutes les maps problématiques, ce qui équivaudrait à jeter à la poubelle 15 ans de travail ! Cruel dilemme ! Le projet aurait-il atteint une impasse ?

Des membres de la communauté font remarquer plusieurs points :

• Chocolate-doom n'activera jamais la fonctionnalité buffer protection par défaut (cela irait à l'encontre des objectifs du projet);
• Ni chocolate-doom ni aucun des ports vanilla n'est recommandé par le projet Freedoom. Cependant, chocolate-doom est packagé dans beaucoup de distros, et pourrait être installé comme moteur par défaut lorsque l'utilisateur installe freedoom;
• Tester toutes les maps pour être sûr qu'un savegame ne crashe jamais le jeu demanderait des efforts herculéens en matière de tests, que la communauté ne peut pas se permettre;
• D'autres projets se prétendant vanilla-compatibles ont des problèmes de buffer overrun (et apparemment cela concernerait même certaines maps du jeu d'origine);

Finalement, il a été choisi d'ignorer le problème du savegame buffer overrun dans l'objectif de compatibilité vanilla de Freedoom. Pour les distributions permettant d'utilisation de scripts de post-installation dans leurs packages, il a été proposé d'activer l'option de buffer protection dans la configuration de chocolate-doom si freedoom venait à être installé aux côtés de celui-ci.

--> Avis personnel <--
Je pense que c'est une bonne décision. D'une part Freedoom ne peut pas se fixer des objectifs qui risqueraient de tuer le projet. D'autre part les maps immenses, labyrinthiques et pleines de monstres sont une composante importante dans l'identité de Freedoom. Enfin, si des gens ont envie de jouer sur un moteur où un crash est une feature, hé bien…pourquoi les décevoir ? /o\

Futur du projet

Après avoir éliminé les Boomismes, les développeurs vont continuer à travailler sur la compatibilité vanilla. Il reste encore des éléments dans Freedoom qui peuvent générer des bugs mineurs (glitches) sur les moteurs les plus anciens. L'objectif pour la version 0.12 est que toutes les maps soient vanilla-compatibles (buffer overrun mis à part). Pour la version 0.13, l'objectif est d'éliminer tout bug dans le gameplay, et de s'assurer que toutes les maps puissent êtres finies à 100% en -skill 4. Rien n'est encore défini pour la suite, mais on peut imaginer que le projet se concentrera alors sur les améliorations artistiques (meilleures sprites/textures, rédaction d'une histoire, meilleurs sons/musiques, etc.).

Actuellement le projet a besoin de graphistes/pixelartistes pour améliorer les sprites des monstres, notamment le Flame Bringer et le Pain Lord, de musiciens MIDI, et de contributeurs pour éditer et tester les maps.

--> Avis personnel <--

Le projet Freedoom recommande 2 moteurs : PrBoom+, qui est packagé dans Debian, et Odamex, qui ne l'est pas. Les deux sont en développement actif.

PrBoom+ n'a que deux choses pour lui : 1) il est joli, 2) il peut jouer n'importe quelle démo. En fait, aujourd'hui les gens s'en servent surtout pour jouer des démos, pas vraiment pour jouer.

Si vous tenez à jouer avec, je vous conseille deux trucs : 1) choisissez une résolution supérieure à celle par défaut, style 832x624, puis dans les options de textures, poussez tout au max (trilinear filter, anisotropic filter 16x, etc.), 2) dans les options de sons, choisissez "SDL" comme lecteur MIDI par défaut. Vous pouvez aussi configurer le HUD pour avoir des chiffres colorés, ça aussi c'est une friture bien sympa que je n'ai pas retrouvée dans les autres moteurs. :o

Mettez le freelook par défaut, poussez l'autoaim au minimum, ajoutez des crosshairs pour éviter de trop niquer votre précision et vos réflèxes, configurez les raccourcis claviers pour les armes (là aussi, Pr+ propose une interface bien foutue qu'on ne retrouve dans aucun autre moteur), et choisissez la touche espace comme touche d'action.

Ensuite enjoy.

PrBoom+ a des défauts bien chiants. L'autoaim ne peut pas être désactivé, pourtant comme antifriture on fait pas mieux :o Utiliser le clic droit comme touche d'action est presque impossible, sinon ça oblige à cliquer deux fois à chaque fois qu'on veut ouvrir une porte, c'est très énervant. C'est pour ça que je vous ai conseillé de le mapper sur l'espace (par défaut utilisée pour sauter, mais Freedoom a été pensé comme un jeu vanilla, c'est moins marrant avec le saut). Last but not least, PrBoom+ a un code réseau cauchemardesque, il est recommandé par pratiquement tout le monde (dont les développeurs) de ne pas utiliser PrBoom+ pour jouer en multi.

Ce qui nous amène à Odamex, un Boom-like qui gère bien le réseau. Il n'est pas packagé donc il faudra le compiler. Il n'a pas toutes les fonctionnalités esthétiques de PrBoom+ mais il permet de désactiver l'autoaim via la console ou le fichier de configuration. Par contre le freelook n'est pas total (pour Freedoom ça ne devrait pas poser trop de problèmes), et il ne donne aucune indication sur les secrets trouvés, il faut donc regarder l'automap, c'est chiant. Notons aussi qu'il n'utilise pas toujours les noms d'armes/items/monstres de Freedoom et utilise parfois ceux du jeu non-libre dont il est tiré. Ah oui, et devoir attendre que le jeu joue un son à chaque fois qu'on veut quitter, c'est relou aussi.

Je n'ai pas beaucoup testé Odamex en multijoueur mais il dispose d'un binaire serveur séparé ce qui est un bon point. Impossible de désactiver les armes de DM en mode coop ce qui est vraiment décevant.

Ce qui nous amène à GZDoom-GPL, une tentative de libérer totalement le puissant moteur GZDoom. Je vous conseille de télécharger et compiler la version git. Ce moteur a à peu près toutes les options dont on peut avoir besoin en terme de gameplay. Il est plus joli que Odamex, moins que PrBoom+ (on ne peut pas choisir le mixeur SDL, je vous conseille donc d'installer fluidsynth et d'utiliser ce dernier, qui offre un rendu assez proche, et je ne sais pas si on peut lisser les textures pour obtenir un rendu aussi joli que celui de PrBoom+, mais on peut s'en rapprocher), mais propose cependant des effets graphiques supplémentaires (tâches de sang sur les murs, halos lumineux autour des projectiles de feu et de plasma, semi-transparence sur les Deadflares, effet "infrarouge" avec les Night Vision Goggles). Il n'est pas capable de lire les démos donc votre écran d'accueil aura un fond statique. Comme Odamex, il ne respecte pas totalement les noms des armes/items/monstres. Il ne respecte pas non plus le son de découverte d'un secret (il joue un bruit de scouic-scouic en cahoutchouc à la place o.O ).

Freedoom 0.11 devrait tourner comme une horloge avec GZDoom-GPL, mais si vous utilisez Freedoom 0.10.1 ou une version précédente, n'oubliez pas d'activer le mode de compatibilité Boom dans votre config.

Niveau réseau, il n'est pas en mode client-serveur mais en pair-à-pair, il n'est donc pas possible de le mettre en place sur un serveur headless. Cependant, les armes de DM peuvent être désactivées en mode coop (pas les autres items par contre).

Son développement est très actif et il pourrait bien remplacer complètement le GZDoom "officiel" un jour (et les autres moteurs de la branche ZDoom pourraient remplacer leurs fichiers non-libres par ceux de GZDoom, à terme).

Il existe d'autres moteurs libres pour jouer à Freedoom, que je n'ai pas beaucoup testés. Chocolate-doom, pour les masochistes qui aiment jouer sans clavier, sans freelook, sans alcool, sans gluten, etc. Doomsday, pour un autre type de masochistes qui aiment se prendre la tête avec qmake (perso je n'ai jamais réussi à compiler Doomsday, si quelqu'un y arrive qu'il me fasse signe), Eternity, qui est un jeune moteur assez proche d'Odamex et qui a des petits trucs en plus, comme un petit effet de splash (eingousef !) quand on marche dans de l'eau (j'ai découvert Eternity avant de découvrir GZDoom-GPL, en cherchant un moteur pour jouer à Blasphemer, mais la compatibilité est pas encore top malheureusement). Il y a aussi des gens qui utilisent un truc appelé GLOOME mais j'ai jamais testé.

Donc pour revenir à ma recommandation personnelle, si vous voulez vraiment apprécier le jeu, tant en solo qu'en multi, utilisez GZDoom-GPL. C'est plein de fritures, ça envoie du gros.

Concernant le jeu en lui-même, je dirais qu'il y a des gros progrès dans la version 0.11. Les nouvelles musiques sont bien plus belles que les précédentes. Fini les boites à musiques 8 bit déprimantes, place aux trompettes et aux roulements de percus. De bons progrès ont été faits sur les sprites d'armes depuis la 0.7 (la dernière version à laquelle j'ai joué sérieusement). Les sprites de monstres ne sont pas beaucoup plus beaux en terme de finesse de dessin, mais ils sont plus visibles et moins déprimants. Les nouveaux items sont plus détaillés que les précédents mais je trouve qu'ils manquent de visibilité par rapport à leurs prédécesseurs.

Concernant les maps, la plupart des nouveaux layouts sont très intéressants. Sur la nouvelle c1m1 on peut voir un net progrès dans les textures, bien que j'aime pas trop son architecture. Cette map est sûrement plus intéressante en DM qu'en solo.

Évidemment, à chaque nouvelle release de Freedoom on ressent un peut de nostalgie. Voir disparaître l'ancienne c1m1 avec son zombie qui patrouille à la fenêtre fait un petit pincement au cœur :/ Pareil pour les sons du Flame Bringer. Certes ils étaient bien pourris, mais il faisaient partie du folklore. On ne l'entendra plus délirer avec une voix d'outre-tombe :

PALEKAS KRUES LAMALEKASTA !!! °□°
EÏNOÏKAS !!! \°□°/
*BOUM!*

Et on ne saura jamais ce qu'il a voulu dire :/

Et puis les nouveaux sons du Flame Bringer sont pas vraiment mieux je trouve.

Concernant les bugfixes, certaines conneries de la 0.10 ont été corrigées, ça fait bien plaisir. Comme les monstres qui ne respawnaient plus sur map04. Bon malheureusement il y a maintenant un problème similaire sur c2m2. Celui-ci devrait être corrigé dans la 0.11.1.

Les développeurs ne testent pas complètement Freedoom à chaque release, il se contentent de vérifier si les maps peuvent être finies en 0/0/0, d'où ce type de bugs. Ce n'est que pour la 0.13 qu'ils s'assureront que toutes les maps peuvent se finir en 100/100/100 (et ça demande beaucoup de temps, moi-même je voulais le faire avant la release, mais je n'ai pas réussi à finir à temps).

Fin

Pour finir, et pour vous aider à vous y retrouver avec les noms des monstres, la nimage en cadal P:

Site officiel
Description officielle
T'en veux-tu des skouinechottes ?
Comment aider le projet