Sorties de Freedoom 0.11 et 0.11.1

Freedoom 0.11 est sorti le 16 février 2017. Freedoom est un projet visant à créer un ensemble de données libres pour les source ports du moteur de jeu FPS 3D Id Tech 1 publié par id Software en 1999 sous licence GPL (disponible aussi sous licence MIT sur GitHub) — autrement dit, le moteur d’un célèbre jeu des années 90.

Freedoom désigne aussi, suivant le contexte, l’ensemble des données publiées par le projet Freedoom, ou tout jeu complet composé d’un source port ainsi que des données de Freedoom.

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

Sommaire

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

Introduction

Le projet se décompose en trois sous-projets :

Freedoom: Phase 1 (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.1) dans lesquels le joueur est confronté à dix sortes de monstres différents, avec sept armes mécaniques à sa disposition ;
Freedoom: Phase 2 (freedoom2) est un jeu de tir en vue subjective (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 (freedm) est un FPS d’arène contenant une trentaine de maps sans monstres (32 maps dans Freedoom 0.11.1). FreeDM est pensé pour le multijoueur, notamment en DM/duel. Notez que les maps de freedoom1 et freedoom2 ont été conçues pour être jouables aussi en DM/duel en plus du mode linéaire.

Nouveautés

Le projet Freedoom inaugure un nouveau logo pour cette version :

Un effort particulier a été fait pour supprimer les « boomismes » dans les maps. Les boomismes sont des fonctionnalités avancées introduites par le moteur Boom, qui ne fonctionnent 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à.

Par rapport aux versions précédentes 0.10 et 0.10.1, sorties en décembre 2015, la version 0.11 apporte les changements suivants :

• de nouvelles maps sur freedoom1 et freedoom2, bien souvent en remplacement d’anciennes, et de nombreuses autres maps reçoivent des mises à jour, visant à améliorer le gameplay, améliorer les performances, résoudre des bogues, notamment la suppression des boomismes ;
• 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 munitions ;
• beaucoup de nouvelles musiques ;
• de nouveaux noms pour les monstres : 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 et la Deadflare Ball s’appelle maintenant le Summoner ;
• de nouvelles textures d’entracte et le nouveau logo ;
• plein de corrections de bogues ;
• et, évidemment, plein de nouveaux bogues ; pour compenser, une version 0.11.1 est sortie six jours après.

Freedoom 0.11.1 est sortie le 22 février 2017. Par rapport à la version 0.11, elle apporte les changements suivants :

• changement de la couleur des bonus de 1 % d’armure de rouge à vert, pour des raisons de cohérence ;
• changements supplémentaires sur les maps : correction de bogues graphiques, correction de bogues de gameplay, suppression de Boomismes résiduels ;
• nouvelle map c3m1 ;
• nouvelles musiques ;
• quelques nouvelles textures ;
• nouveaux sprites pour le Pain Bringer et le Pain Lord.

Avec ces nouveaux sprites l’apparence du Pain Bringer et celle du Pain Lord changent profondément : des sortes de mutants cyborgs géants à tête d’oiseau, avec ce qui semble être la tête d’un lézard géant cracheur de boules d’énergie greffée à la place du bras, totalement animés, viennent remplacer les golems argileux statiques utilisés jusqu’alors. Les deux créatures sont vêtues d’une armure à dominance blanche, avec des éléments de couleur rouge pour le Pain Bringer et de couleur verte pour le Pain Lord. Pour le Pain Bringer, la tête du lézard est verte et greffée sur son bras droit, et pour le Pain Lord, la tête de lézard est rouge et greffée sur son bras gauche.

Un nouveau moteur est apparu sur le site du projet dans la liste des moteurs recommandés. Il s’agit de Crispy Doom, un moteur basé sur Chocolate Doom et compatible en matière de fichiers et de protocoles réseau avec celui‐ci, tout en étant un peu plus avancé. Cela fait donc maintenant trois moteurs recommandés par le projet Freedoom, avec Odamex et PrBoom+.

Notons que seuls freedoom1 et freedoom2 ont eu des changements significatifs lors de ces publicatons. FreeDM voit simplement son numéro de version poussé à 0.11.1 (il hérite cependant des nouveaux sprites communs à tous les sous‐projets, bien évidemment).

Voici un petit montage présentant les créatures avec leurs nouveaux noms. Sur fond brique, les monstres spécifiques à Freedoom: Phase 2 :

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 bogue bien connu : le « savegame buffer overrun ». Ce bogue 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és corrigent ce bogue é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 bogues ! Il existe bien une option de configuration (buffer protection) pour corriger ce bogue, 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 quinze 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 empaqueté dans beaucoup de distributions 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 paquets, 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.

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 bogues 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 bogue 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 (meilleurs sprites et textures, rédaction d’une histoire, meilleurs sons et musiques, etc.).

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

Aller plus loin

• Site officiel (510 clics)
• Description officielle (104 clics)
• Copies d’écran (279 clics)
• Comment aider le projet (89 clics)
• Wikipédia : id Tech 1 (132 clics)
• Wikipedia (EN) : Doom Engine (un autre nom d’id Tech 1) (98 clics)