Une histoire de fork

44
22
août
2012
Jeu

Dans un récent journal, il a été fait état du problème des forks dans les jeux libres… Mais, plutôt que de tirer des conclusions sur des suppositions, et si nous étudions un exemple concret ? Alors, voici une histoire de fork !

Je propose une rétrospective historique avec une petite analyse et quelques avis personnels.

NdM : merci à Thomas DEBESSE pour son journal.

Sommaire

Quake Ⅲ Arena, ioQuake3

En décembre 1999 est sorti le Jeu Quake Ⅲ Arena créé par id Software.

Six ans plus tard, en août 2005, le moteur de Quake 3 est libéré. Le code de Quake 3 est repris par l'équipe d'icculus pour donner le moteur ioQuake3. Cette ouverture et publication du moteur ioQuake3 est pour de nombreux mods l'occasion de sortir en version standalone.

Le fork Tremulous

Tremulous utilise un fork du moteur ioQuake3. Tremulous est donc plus qu'un mod collé à ioQuake3, c'est aussi un fork.

Tremulous est un jeu passionnant qui propose deux classes d'ennemis différentes, les humains et les aliens, ce qui permet au jeu de se distinguer de la majorité des quake-like qui permettent seulement de se battre contre son semblable. En plus de cette spécificité, il rajoute à la partie « jeu de tir en équipe  » toute une partie de gestion stratégique avec la capacité de construire, organiser et déplacer la base. Une équipe ne gagne pas parce qu'elle a fait le plus de frags, mais parce qu'elle a détruit la base adverse, empêchant les joueurs de venir combattre.

Tremulous sort donc en version standalone à l'occasion de sa sortie en version 1.1.0, en mars 2006.

Malheureusement, c'est aussi la dernière version sortie. Une version 1.2.0 est attendue et promise depuis 2006 mais n'a encore jamais vu le jour. Puisqu'il n'y a pas eu de sortie officielle après la 1.1.0, les dépôts proposent toujours la 1.1.0.
Si l'on me proposait de remonter le temps, j'en profiterais peut-être pour essayer de convaincre l'équipe des bienfaits du release early, release often.

Dans les faits, depuis très longtemps, plus aucun serveur ne tourne en version 1.1.0. Se connecter avec un client 1.1.0 provoque un avertissement. Tous les administrateurs de serveurs ont installé des compilations de la branche de développement, rendue facilitée par la publication de quelques binaires précompilés sur des serveurs plus ou moins officiels. Si vous vous connectez sur des serveurs actuels avec un Tremulous 1.1.0, certains vous indiqueront un lien pour télécharger une mise à jour, chaque fois différente (par exemple l'un m'a indiqué celui-ci)… Parfois en allant à ces liens (par exemple un autre serveur m'a indiqué ce lien, qui propose tout simplement TremFusion).

Donc voilà l'état de Tremulous aujourd'hui : la seule version publiée est la 1.1.0, il y a six ans. Plus personne ne joue avec et tous les serveurs râlent si vous vous connectez avec. Si vous êtes un joueur débutant, vous commencez la partie par un message d'erreur peu accueillant.

Un exemple de bug dans Tremulous qui n'a toujours pas été corrigé en six ans : le menu de configuration n'est accessible que depuis une partie ! Il faut donc rejoindre un serveur ou lancer une partie en local pour changer son pseudo, sa résolution d'écran…

Il ne fait pas bon être débutant sous Tremulous, il faut franchir une marche assez élevée, ce qui fait que petit à petit les joueurs se sont mis à jouer entre eux en cercle fermé. D'autres problèmes internes à la communauté de joueurs ont provoqué la migration de certains joueurs vers d'autres jeu, comme UrbanTerror proposant pourtant un GamePlay plus classique.

Une bêta de la 1.2 « Gameplay Preview » est sortie en 2009, mais cela n'a pas freiné le départ des joueurs.
Cela fait désormais 6 ans que Tremulous 1.1.0 est sorti et qu'on attend une sortie officielle. 6 ans, c'est le temps qu'à attendu id Software pour considérer leur moteur de jeu comme non rentable et dépassé, pour pouvoir le libérer.

Les mods de Tremulous

Tremulous, comme beaucoup de jeux, a été modé. Mais il faut voir que beaucoup de ces mods n'étaient là que pour corriger des défauts de Tremulous, ou pour apporter des améliorations qu'on aurait bien aimé voir dans une version 1.2.
Déjà, l'existence de ces mods traduisaient un besoin non satisfait : que l'équipe de Tremulous publie une mise à jour.

On peut par exemple citer le mod TremX, et son annonce sur les forums tremulous donne une petite idée de l'ambiance, les premiers mots sont « some minor(!) fixes », le point d'exclamation étant assez explicite. Le reste de l'annonce parle du dépôt svn du moteur et sentait déjà le fork, TremX est sorti pour la première fois en août 2006.

Un autre mod populaire était le mode KoRx, dérivé de TremX, KoRx pour tremx-kor, kor pour le nom de l'équipe Knights of reason.

Dans le genre « mod qui corrige les bugs », Ergo+ ne changeait rien au jeu, mais apportait quelques corrections pratiques comme placer le menu d'option sur la page principale.

Le fork TremFusion

TremFusion est à l'origine une fusion de plusieurs mods de Tremulous.
C'est devenu un fork, et je pense que pour beaucoup de joueurs, il correspond à la version 1.2 tant attendue et jamais sortie.

Tremfusion 0.9 est sorti en décembre 2008, la dernière version, Tremfusion 0.99r3, est sortie en 2009. Il n'y a pas eu de mise à jour depuis, peut-être parce que ce n'est pas vraiment nécessaire, et en attendant d'autres projets plus ambitieux (voir ci-après), il faisait au moins ce qu'on attendait de lui : corriger les bugs du moteur et apporter les améliorations de gameplay que l'usage demandait.

TremFusion ne remplace que le moteur de Tremulous, par exemple le dépôt PlayDeb vous installera le paquet Tremfusion et Tremulous-data, et vous verrez les mêmes serveurs que Tremulous. Si vous n'avez pas de dépôt qui propose TremFusion pour votre distribution, il faudra installer Tremulous avant TremFusion.

Tremfusion et XreaL

L'équipe de Tremfusion avait essayé de le porter sur XreaL, il existait une branche TF-XreaL.
Aujourd'hui Tremfusion ne tourne pas sur XreaL, il semble plutôt que le code de Tremfusion est toujours le code de Tremulous, plus des correctifs, plus quelques fonctionnalités rapportées d'XreaL.

Le moteur XreaL

XreaL est un fork du moteur ioQuake3, et était le moteur libre le plus avancé avant la libération du moteur de Doom3. En fait, je ne saurais pas comparer le moteur de Doom3 et XreaL et dire en quoi l'un est meilleur que l'autre. Ce qui est certain, c'est qu'XreaL est un moteur très avancé, et propose des améliorations graphiques modernes, et la prise en charge de formats plus récents que ceux de Quake3 (notamment les formats de Doom3 et une partie des formats d'Unreal Engine).

XreaL avait son site dédié, xreal-project.net (un site parking, PAKLIKAI !) mais le site a fermé quand Wolfenstein : Enemy Territory a commencé à migrer sur XreaL, peu après la libération du code d'Enemy Territory, tandis qu'XreaL intégrait des parties d'iowolfet.

Avant l'aventure ET:XreaL, XreaL était plus qu'un moteur de jeu, c'était aussi un projet de jeu libre, mais pas grand chose de plus qu'un classique QuakeLike sans grand intérêt.

Aujourd'hui, la page officielle semble être sur ModDB. Le dépôt se trouve sur Sourceforge, et la lecture du Readme semble montrer que désormais XreaL est avant tout le moteur d'ET:XreaL.

XreaL et Tremulous

Dès que XreaL a commencé à être connu, certains ont imaginé et essayé de porter Tremulous dessus. Il est en effet beaucoup plus simple de porter un jeu depuis ioQuake3 vers XReaL que de porter vers ioDoom3 ou ses forks.

Avant que XreaL ne devienne le moteur d'ET:XreaL, on pouvait compiler XreaL pour Tremulous avec un simple argument à make (je n'ai pas vérifié depuis).

TremZ et OpenWolf

TremZ est à l'origine un mod de tremulous qui a très vite viré au fork, lui aussi. Le projet TremZ a forké le moteur XreaL pour en faire le moteur OpenWolf.

Le projet OpenWolf était très ambitieux : devenir le moteur libre qui remplacerait ioQuake3 dans les projets utilisant ioQuake3 actuellement, et le développeur publiait régulièrement des copies d'écran d'OpenWolf faisant tourner Tremulous, Urban Terror et Enemy Territory. Le but premier n'étant pas seulement d'être le moteur de TremZ, mais également de pouvoir faire tourner les autres jeux sans modification. On pouvait lire sur le forum :

Project goal is to provide perfect combination between current IDTech3 engines (Urban Terror, Quake3, Return To Castle Wolfenstein, Enemy Territory and Tremulous).

On pouvait lire aussi :

One of the major goals is to be able use assets from any Quake 2 or 3 mod game. So, being able to play regular Tremulous 1.1 on OpenWolf would be a proof of this capability.

Le moteur était très prometteur, cette vidéo montrant les effets d'eau m'avait beaucoup impressionné, et on peut lire une ancienne description du moteur assez intéressante (mais semble mélanger fonctionnalités effectives et souhaitées).

Cependant, il y eut des dissensions assez vite.

Le développement est devenu fermé, ce n'est pas incompatible avec le libre, ils ne sont pas obligés de développer collaborativement, ils ont seulement obligation de publier les sources des binaires qu'ils publient, et pour le moment aucune alpha n'a été publiée. Il y avait le dépôt github.com/TremZ, mais il n'existe plus.

On peut lire les motivations sur le forum de TremZ. Il en ressort des arguments similaires à ce qu'on a pu lire pour Warsow.

Cependant, à l'inverse de Warsow, et comme Tremulous, les données devraient être publiées sous une licence Creative Commons (mais je ne crois pas avoir lu laquelle), le but est toujours de faire un jeu libre.

Le but du projet TremZ est de sortir un jeu bon du premier coup.

TremZ a donc pris résolument la direction d'un développement en mode cathédrale, allant dans la même direction que l'équipe de Tremulous et en prenant donc les mêmes risques. Il était prévu une première diffusion en décembre en disant « vous avez attendu 6 ans que Tremulous 1.2 sorte, voici TremZ », mais rien n'est sorti, et on attend TremZ comme on a attendu Tremulous 1.2. Et à part un poisson d'avril, il n'y a plus de nouvelles sur le blog officiel. Sur les forums, il y a encore quelques discussions, mais pas grand chose de plus que des copies d'écran et des comparaisons entre TremZ et Unvanquished.

Unvanquished et Daemon

En fait, TremZ a été forké par ceux qui n'étaient pas d'accord avec cette politique de développement fermé, la majorité des participants est partie d'elle-même, certains se sont faits bannir du projet TremZ.

Unvanquished était un des noms pressentis pour TremZ, en fait le dépôt TremZ de github cité plus haut est devenu le dépôt d'Unvanquished, et a gardé ce nom après le fork jusqu'à ce qu'une première sortie alpha soit faite (et donc que le nom soit fixé). Le code d'Unvanquished ainsi que de nombreux travaux complémentaires est disponible sur github.com/Unvanquished. Dans le projet Unvanquished fork de TremZ (jeu complet), Daemon est le fork d'OpenWolf (moteur de jeu).

Du côté de TremZ, je n'ai lu aucune remise en question, si ce n'est de reporter la faute sur le principe même du modèle Open Source :

Yes, also welcome to opensource development things like this happen all the time. It isn't as a big of a deal as you think, don't over think it.

La pre-release annoncée par le projet TremZ a en fait été sortie par le projet Unvanquished. Depuis décembre, ils ont déjà sorti 6 versions alpha, la dernière est sortie le 3 août dernier.

De son coté, le projet TremZ reconnaît intégrer les corrections de Daemon à OpenWolf, mais ne permet pas encore (tant qu'ils ne publient rien) l'inverse. Ils en ont le droit.

Le projet Unvanquished prend donc la direction d'un projet, non seulement libre, mais ouvert et communautaire, et fait le choix d'avancer par petites incrémentations.

Analyse

À propos du fork de jeu libre

Dans l'argumentaire de TremZ, il est dit que pour un jeu vidéo, c'est dangereux de publier trop tôt des versions non finies, car le public du jeu vidéo peut rester définitivement déçu par l'expérience d'une simple version alpha. C'est quelque chose de vrai.

Pourtant, pour une fois, l'argument ne tient pas. En effet, TremZ/Unvanquished sont des forks de Tremulous, ils s'adressent donc à une base de joueur déjà convaincue ! Il suffit seulement de ne pas faire pire que Tremulous pour ne pas perdre de joueurs, et d'apporter plus que Tremulous pour les récupérer. C'est ce qu'a fait TremFusion, les joueurs de Tremulous ont peu à peu migré vers TremFusion, ils migreront peu à peu vers Unvanquished.

Dans le débat sur les licences de Warsow, et dans les discussions du forum TremZ, il a été avancé que le développement libre nuisait aux projets de jeux libres en dispersant la communauté de joueurs. À première vue, l'exemple de Tremulous semble aller complètement dans ce sens. En creusant un peu plus, on se rend compte que le problème est ailleurs, le fork étant seulement ce qui révèle un problème.

Et si nous regardions vite fait les autres projets libres similaire ?

  • Nexuiz a forké une fois, mais c'est un cas particulier : il a été vendu à Illfonic et est devenu propriétaire. Le Nexuiz libre est devenu Xonotic, pour les joueurs, cela n'a rien changé, si ce n'est le nom. La base de joueur n'a pas été dispersée, ni la base des développeurs.
  • Personne n'a forké Smokin'Guns ou AlienArena (ou alors c'est vraiment confidentiel). Pour Smokin'Guns, ils sont revenus d'un fork de Quake3 vers la version ioQuake3.
  • OpenArena a vu quelques forks qui n'ont pas fait long feu, qu'on ne peut pas accuser de diviser la communauté et qui ont surtout été des explorations de concept qu'autre chose (comme IHTG qui visait à proposer une version du jeu pour systèmes peu puissants).

Il n'y a vraiment que le jeu Tremulous pour avoir vu autant de forks dans son histoire, alors on ne peut pas dire que ce n'est pas la liberté qui est cause de ces forks, mais un problème inhérent à la communauté de Tremulous.

Le fork est un marqueur, la plupart du temps, il y a fork quand quelque chose ne va pas. Pour Tremulous, ce fut de ne pas savoir publier des corrections et de laisser les joueurs dans l'illusion. Parce que c'était libre, alors Tremulous a été forké, Tremulous est encore en vie grâce à ses forks. Alors oui la communauté des joueurs est divisée, mais elle existe encore. Si Tremulous n'avait pas été libre, il n'y aurait déjà plus de joueurs, et le jeu serait complètement mort. Les forks permettent cette survie, et ce n'est pas un inconvénient !

En fait, les jeux libres forkent pour survivre. Ils ne forkent pas juste pour diviser. Quand un jeu libre forke, c'est qu'il est déjà pourri.

Il y a deux types de forks dans les jeux libres :

  • le fork pour survivre
  • le fork pour explorer une nouvelle idée

Aucun des deux n'est mauvais : le premier est une chance, le second ne porte pas préjudice : il commence souvent comme un mod (et alors ne divise pas la communauté des joueurs), et s'il n'est pas intéressant, il meurt très vite. Si le mod/fork survit, c'est qu'il était pertinent, et c'est encore une chance d'avoir un nouveau jeu. On ne joue pas toute sa vie aux mêmes jeux, et certaines variations sont très appréciées jusqu'à supplanter le jeu original, au grand plaisir des joueurs, et puis les développeurs du jeu original peuvent toujours rejoindre le nouveau jeu à la mode, c'est ça aussi le libre.

À propos du fork de moteur de jeu libre

Alors là, c'est un vrai problème. J'ai pour avis que beaucoup de ces jeux prennent trop souvent le risque du fork. Tremulous est un fork, Smokin'Guns fut un fork… TremZ puis Unvanquished ont forké XreaL…

Dans le milieu du jeu vidéo, il semble inhabituel de proposer ses modifications à un projet plus général. Quand on installe UrbanTerror, OpenArena, WorldOfPadman, Smokin'guns, Tremulous etc. on installe autant de fois ioQuake3 ou l'un de ses forks. Jamais personne n'a transformé ioQuake3 en une libioquake3.

Alors, je vais tenter un avis et prendre beaucoup de risque… mais ça semble venir du fait que la majorité des développeurs sont sous Windows et ne connaissent pas la joie d'un dépôt. Un développeur sous Windows, il fournit toujours toutes ses dépendances, et d'une certaine manière c'est comme s'il forkait à chaque fois. Sous Windows quand vous installez Gimp, Pidgin et Gsmartcontrol, vous installez trois versions de GTK, et chacun de ces projets vous fournit sa version de GTK. On comprend qu'il soit normal pour un développeur sous Windows de fournir une version supplémentaire d'ioQuake3, et qu'il devient alors très tentant de forker quand il n'est pas naturel de remonter upstream ses modifications et de fournir un paquet dépendant d'un autre paquet développé par une autre équipe.

Aussi, le développeur propriétaire, très courant sous Windows, fournit tout d'un bloc parce que l'utilisateur ne peut pas se procurer les dépendances. Bref, j'ai l'impression que tous ces forks sont plus ou moins la conséquences des habitudes de développement propre au monde propriétaire et/ou à la plate forme Windows.

On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla : ils ne sont pas vraiment conçus dans l'idée que XulRunner puisse être livré séparément, et les projets comme Debian ont du mal avec ces projets, la manière de faire n'est pas du tout celle de procéder habituellement dans le libre, ça convient tout à fait à un programme Windows (et l'on ne peut pas faire le reproche d'avoir comme base principale d'utilisateur des utilisateurs de Windows), mais ça entraîne quelques complications. Par exemple, un projet basé sur XulRunner, BlueGriffon, vient encore avec sa propre version de XulRunner… Sous Windows, ça ne choque pas ; pour beaucoup de distributions Linux, c'est une mauvaise manière de faire.

On pourrait avancer (ouhouh, je prends des risques) que l'absence de gestionnaire de paquet sous Windows conditionne la méthode de travail du développeur, ce qui conditionnera au final la cohérence du produit. D'une certaine manière, l'absence de gestionnaire de paquet ne nuit pas directement à l'utilisateur, elle nuit indirectement, parce que le développeur n'en a pas.

Mais pour revenir à nos forks de moteurs de jeu, on peut reconnaître que beaucoup de temps et de ressources sont probablement gaspillés, mais là encore, l'argument du fork n'est pas recevable : les moteurs de jeu ne sont forkés que lorsque le jeu est déjà forké.

Ce n'est donc pas la possibilité du fork qui provoque le fork. La possibilité du fork n'est donc pas un désavantage. Il y a certainement plein de choses regrettables dans tous ces forks de forks de forks de moteurs de jeu, mais puisque ces forks ne surviennent qu'après coup, ils ne sont pas directement un risque pour le jeu. Ils sont un risque pour le moteur de jeu. C'est pas le fork qui est mauvais ici, c'est la manière de forker qui l'est.

Faire un jeu forkable ne signifie pas que le fork soit un jour effectif. Un jeu qui ne forke pas est un jeu dont l'équipe de développement a une ligne directrice claire et établie, et qui a un développement vivant. L'expérience montre que les jeux libres et sérieux ne forkent pas, les jeux libres qui forkent ne forkent pas parce qu'ils sont libres, mais parce qu'ils prennent l'eau.

Ce ne sont pas les forks qui ont tué Tremulous, mais c'est parce que Tremulous est mort que Tremulous a été forké.

Remarque générale sur ces forks

Les données ne sont quasiment jamais forkées, parce que justement elles constituent l'identité du jeu beaucoup plus que le moteur, c'est donc beaucoup plus risqué. Ce sont les moteurs qui forkent.

L'argument du fork est valable pour le moteur, pas pour les données.

L'avenir de Tremulous.

Je souhaite que le projet Unvanquished arrive à ressusciter ce merveilleux jeu que fut Tremulous, et c'est facile d'avoir de l'espoir parce que le développement est actif et l'équipe communique bien !

Il est très probable que le projet TremZ devienne comme la version 1.2 de Tremulous : une illusion. En plus de ne pas se rendre compte que, dans leur cas, ils pouvaient se permettre le release early, release often, et qu'ils n'ont pas saisi cette chance, en plus de ne pas savoir se remettre en cause (reporter la cause du fork sur sa simple possibilité, c'est petit), ils n'ont pas non-plus remarqué que pour un jeu indépendant qui a peu de ressource pour sa communication, c'est dangereux de jouer à la boîte noire.

Ils disparaissent peu à peu des discussions, il leur sera de plus en plus difficile de recruter des artistes et des développeurs, et les joueurs se désintéressent.

Avec tout ça, ils ne font pas que porter le jeu, ils commencent à remettre en cause certains points du gameplay, voulant remplacer les aliens insectoïdes par des quadrupèdes… Ça rappellera à certains un récent journal qui traitait du risque et de la tentation de la réécriture… Plus le temps passe et plus ils se donnent du travail…

Il y a toujours quelques joueurs qui jouent au Tremulous original, enfin, le Tremulous original avec patchs téléchargés sur un obscur serveur, si vous installez Tremulous depuis votre dépôt les serveurs râleront.

Unvanquished remplace peu à peu les modèles par des plus détaillés, voir par exemple cette galerie, certains modèles présentés sur cette page ont déjà été intégrés.

Certains serveurs proposent des bots. Surtout, il faudra faire des cartes tirant parti des possibilités graphiques du moteur, surtout que les nouveaux modèles détaillés d'Unvanquished font un peu tache dans les cartes de Tremulous…

Les sons devront être refaits, c'est un problème qu'essaie de résoudre le projet Tremulous original, car il est apparu que les droits sur les sons étaient incertains, voire complètement douteux.

Jouer ?

Donc, si vous souhaitez jouer, vous pouvez essayer TremFusion, il y a toujours une base de joueur active. Une archive pour Linux est proposée sur la page de téléchargement, et pour ceux qui sont sur Ubuntu, le dépôt Playdeb le propose.

Pour ceux qui voudraient essayer Unvanquished, un installeur pour Linux est disponible sur leur page SourceForge, et un paquet Ubuntu est disponible sur PlayDeb.

Ces jeux n'ont pas vraiment de sens sans une base de joueurs active !

Pièce 9 du concours Plee the Bear

Aller plus loin

  • # Tremulous, un bon souvenir

    Posté par  . Évalué à 4.

    Le fait de pouvoir choisir entre un alien ou un humain, et entre un combattant et un "constucteur", et puis ce savant mélange de FPS et de RTS, pouvoir marcher sur les murs et au plafond avec le petit alien et la possibilité d'évoluer au fur et à mesure du jeu… Le seul point noir à mon avis, c'est que le jeu est assez moche, j'aimerais voir ce que ça donne avec Unvanquished…

    Un jeu original qui mérite de vivre à mon avis.

    Le fork est un marqueur, la plupart du temps, il y a fork quand quelque chose ne va pas.

    GNOME 3 ? (Ceci n'est pas un troll). Parce que ça ressemble un peu à la même chose : dispersion de la communauté et des développeurs, surtout entre GNOME-Shell et Unity qui sont assez proches dans l'idée et dans la conception. Sauf que là, les forks ne sont pas près de mourir, mais la séparation n'est bénéfique pour personne à mon avis.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Tremulous, un bon souvenir

      Posté par  . Évalué à 2.

      GNOME 3 ? (Ceci n'est pas un troll). Parce que ça ressemble un peu à la même chose : dispersion de la communauté et des développeurs, surtout entre GNOME-Shell et Unity qui sont assez proches dans l'idée et dans la conception. Sauf que là, les forks ne sont pas près de mourir, mais la séparation n'est bénéfique pour personne à mon avis.

      Pourtant KDE a eu son fork, mais on ne peut pas dire que ce n'est pas une réussite (au moins technique).

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Tremulous, un bon souvenir

        Posté par  . Évalué à 3.

        Il a du succès, le fork de KDE ?
        N'importe qui peut forker, surtout avec github et compagnie, le critère est plutôt la popularité des forks.

  • # Ah merci pour la transformation !

    Posté par  (site web personnel) . Évalué à 3.

    Puisque c'est à l'origine un journal, je rappelle que les journaux sont des espaces personnels mutualisés d'expression libre et qu'ils appartiennent à ceux qui les ont postés, que les avis n'engagent que leurs auteurs et que LinuxFR ne saurait être rendue responsable de la présence dans cette dépêche de quelconque avis personnel, opinion, supposition, parti-pris, lancé de troll, humeur, ou allusion d'initié ! :)

    ce commentaire est sous licence cc by 4 et précédentes

  • # Avis personnel

    Posté par  . Évalué à 5.

    Autant le libre pour poste de travail/ serveur a un réel avenir à mon sens, autant dans le domaine du jeu vidéo je suis dubitatif. Etant amateur de FPS et de stratégie, j'ai essayé Tremolus, OpenArena. Je n'ai fait qu'essayer. Les jeux sont nettement moins beaux graphiquement, nettement moins immersifs, et je n'ai trouvé aucun réel apport dans le gameplay. J'aime également la stratégie, mais là encore, le proprio surclasse largement le libre (X3, Homeworld, …).

    Je pense que le problème est inhérent à la complexité du jeu vidéo : il faudrait fédérer une énorme communauté aux compétences extrêmement variées pour lutter contre les grands du domaine : en allant du moteur jusqu'à la réalisation d'images et de sons.

    Le système de forks évoqué ici rend la tache encore plus ardue : un développeur de moins dans une équipe de taille réduite oblige à faire des coupes franches, ce qui provoque ensuite une hémorragie (découragement, mauvaise ambiance). Même s'il n'est qu'une conséquence de problème antérieurs, il aggrave les conséquences.

    Concernant les aberrations de gestion des librairies, là il y a une bonne habitude à prendre dès le début. Le problème n'est pas que le fork utilise une librairie donnée, mais plutôt que le jeu originel ne se base pas sur une librairie standard. Attribuer cette habitude au monde propriétaire/ Windows est ici probablement de mauvaise foi : quand on développe avec le framework .NET, on évolue en même temps que celui-ci, on n'oblige pas le client à avoir une version spécifique de la librairie, et ce depuis au moins 5-6 bonnes années maintenant. De plus, la nécessité de permettre le jeu sous plusieurs plateformes logicielles(car la plupart des joueurs sont sous Windows) rends très complexe un certain nombre d'optimisations. Les maintenir au fur et à mesure de l'évolution des librairies sous différents système est un casse-tête qui explique probablement à lui seul la non-évolution des dépendances liées à un jeu.

    Pour ma part, si je garde encore un Windows, c'est essentiellement pour pouvoir continuer à jouer à des jeux récents, immersifs. Si une véritable alternative libre apparaissait (et à mon avis il y a des créneaux, notamment dans le MMO ou la STR, ou les graphismes sont moins importants que le gameplay), je switcherai volontiers sous Linux en totalité. Mais pour l'instant, force est de constater que les alternatives libres sont soit un gros cran en dessous des propriétaires (FPS) soit sont quasiment inexistante (stratégie spatiale par exemple…). Donc en l'état actuel, parler de "jeu libre" en alternative aux blockbusters ne me semble pas être très pertinent. Les placer à côté en disant "il existe cela" est déjà très optimiste.

    • [^] # Re: Avis personnel

      Posté par  (site web personnel) . Évalué à 8.

      Le problème ce n'est pas la licence, le mode de développement ou les forks.

      Faire un jeu AAA demande plusieurs millions d'euros.

      Les jeux libres actuels ont en moyenne un budget de 0€.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Avis personnel

        Posté par  . Évalué à 6.

        Les millions d'euros couvrent 2 choses : le marketting et le travail des devs. Dans le libre, le marketting n'est pas indispensable. Il ne reste que le temps passé en développement, qui lui est dépensé de toute manière. Mais quand Activision met pendant 2 ans 150 devs sur un projet, le temps passé n'est pas faisable pour une communauté libre , même avec 150 contributeurs réguliers (ce qui est déjà relativement rare). Donc étant donné que dans un projet libre de jeu les devs sont rarement rémunérés…

        De plus le fait qu'il s'agisse d'un jeu (donc, aucune contribution dans le cadre d'une entreprise), limite encore davantage le temps que peut y consacrer un dev.

        C'est pour moi l'une des limites du libre : sur de gros projets non professionnels, le temps de développement nécessaire pour lutter contre les alternatives propriétaires exclut quasiment cette possibilité. Le jeu est peut-être l'une des illustrations de cette limitation.

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 2.

          Il y a des tas de bons jeux indépendants (donc faits avec un petit budget, voire bénévolement pour certains). Le truc, c'est que quasi aucun de ces jeux n'est libre à part ceux de Jason Rohrer.

          Évidemment, ces jeux ne doivent pas être appréciés avec les mêmes critères que les jeux hollywoodiens : pas la peine d'espérer un environnement « immersif » avec des millions de polygones et des textures ultra-chiadées.

    • [^] # Re: Avis personnel

      Posté par  . Évalué à 7.

      Le problème des jeux libres est que ce sont majoritairement des clones de jeux propriétaires, en moins bien, en moins beau, et surtout en version 0.1. Et on se fait moissonner/huer quand on dit ça.

      Je pense que le seul moyen de faire un jeu libre qui marche serait d'inventer/réinventer un concept simple, du genre un truc en 2D, et de faire un gros buzz dessus.

      • [^] # Re: Avis personnel

        Posté par  (site web personnel) . Évalué à 3.

        Le fait que ça soit des reprises ne me semble pas un problème : je m'explique et cite pour cela Nina Paley par exemple, qui explique dans une video que toute oeuvre est inspirée par une précédente oeuvre. Et c'est le cas pour les jeux video aussi.

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 5.

          Une reprise ou une inspiration n'est pas pareil qu'un clone. L'objectif de beaucoup de jeux libres est de cloner un jeu propriétaire afin d'y jouer gratuitement et sous linux. Il est évident qu'il n'existe pas vraiment de plus-value associée à ce type de projet…

    • [^] # Re: Avis personnel

      Posté par  . Évalué à 5.

      Je pense que le problème est inhérent à la complexité du jeu vidéo : il faudrait fédérer une énorme communauté aux compétences extrêmement variées pour lutter contre les grands du domaine : en allant du moteur jusqu'à la réalisation d'images et de sons.
      
      

      Je ne pense pas que ce soit le problème, ou du moins, pas le seul, vu qu'il y a plein de petits studios indés qui font des jeux merveilleux. Hors ces studios comportent fréquemment moins de développeurs et d'artistes qu'un projet open source typique.

      Personnellement, j'avancerai trois hypothèses sur ce qui fait obstacle à l'abondance de jeux libres "réussis" (ayant le degré de finition des jeux propriétaires):

      • Dans un projet ouvert, il n'est pas facile de maintenir une cohérence de style entre plusieurs artistes (que ce soit pour les graphismes, les sons, le level design…). À l'inverse du code où il suffit de quelques règles simples, et où de petites variations de style ne seront pas perceptibles par le joueur.
      • Il est difficile de créer un gameplay à plusieurs, dans une discussion ouverte. Paradoxalement, on peut constater cette même difficulté dans les grands studios, dont les titres AAA sont quasiment tous des déclinaisons de gameplay bien établis. Seul les petits studios semblent capables d'innover (il y a bien sûr quelques exceptions).
      • Il faut souvent sacrifier du code / des assets pour améliorer le gameplay, et je pense qu'un projet libre hésitera avant de jeter une partie du travail de ses contributeurs.
      • [^] # Re: Avis personnel

        Posté par  . Évalué à 4.

        Hors ces studios comportent fréquemment moins de développeurs et d'artistes qu'un projet open source typique.

        Même si tu compare en temps disponible pour le projet ?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 2.

          D'une part, certains studios indés débutent en ayant un autre job à côté (parfois dans une grosse boite de jeux). La situation est alors similaire.

          Il y a aussi pas mal de "studios" comportant seulement une ou deux personnes; la plupart des jeux libres dont j'ai pu observer le développement ont souvent bien plus de contributeurs, et peuvent donc cumuler un temps disponible équivalent.

          Donc oui, je pense qu'un projet open source peut aisément rivaliser en terme de "puissance brute". Pour moi c'est beaucoup plus un problème de direction que de nombre.

          • [^] # Re: Avis personnel

            Posté par  . Évalué à 3.

            et peuvent donc cumuler un temps disponible équivalent.

            Sauf que 100h de disponibilité par la même personne ou 100 x 1h par personne ne s'est pas vraiment comparable.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Avis personnel

              Posté par  . Évalué à 2.

              C'est précisément ce que j'entends par "problème de direction". Il amha est plus difficile d'obtenir certaines formes de cohérence dans un projet ouvert.

              À ma connaissance, les jeux libres les plus "finis" (je pense à Battle for Wesnoth, Neverball) ont été initialement l'œuvre d'une seule personne.

      • [^] # Re: Avis personnel

        Posté par  (site web personnel) . Évalué à 3.

        Je pense que les devs indépendants savent qu'ils vont gagner de l'argent avec leur jeu. C'est une motivation financière. Il ponde le jeu de leur rêve, un jeu fait pour les joueurs. L'OpenSource ils s'en tamponne (sinon la plupart libérerait leur jeu une fois qu'il ne se vend pas, ce qui n'est jamais le cas)…

        Ils sont souvent une petite équipe, n'ont a justifier leurs choix qu'a eux même, l’envie de réussir son jeu, qu'il plaise et qu'il se vende correctement.

        L’aspect communautaire dans le jeu vidéo fait vraiment peur. Pour ceux qui ont un peu suivi le développement de Teeworld, on avais parfois l'impression que la communauté faisait tout pour que les devs lâche définitivement le projet (ce qu'ils ont plus ou moins fini par faire).

        Un dev indépendant, il se préoccupe de ces ventes et est rarement présent sur les forums (même si il peut les lires).

        Bref, je pense que c'est une approche très différente. Si tu est libriste et que tu veut faire un jeu video, tu le fait, tu le fini, tu le rend le plus disponible possible (repos debian/ubuntu) et ensuite seulement tu commence le travail collaboratif.

        Et puis les rares jeux inde qui ont été libérés n'encourage en rien a faire ce choix. Aquaria par exemple (qui est un jeu magnifique comme on en voit trop rarement dans le libre), a ma connaissance, seul icculus a bosse dessus depuis sa libération…

        Pourtant tout est la:

        http://hg.icculus.org/icculus/aquaria/

        Tout le travail de compatibilité, compilation a été fait et il n'a jamais été ajouter a un repo, genre Ubuntu ou Debian.

        Il y a surement une raison mais je ne comprend pas.

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 4.

          Et puis les rares jeux inde qui ont été libérés n'encourage en rien a faire ce choix. Aquaria par exemple (qui est un jeu magnifique comme on en voit trop rarement dans le libre), a ma connaissance, seul icculus a bosse dessus depuis sa libération…

          Pourtant tout est la:

          http://hg.icculus.org/icculus/aquaria/

          Tout le travail de compatibilité, compilation a été fait et il n'a jamais été ajouter a un repo, genre Ubuntu ou Debian.

          Attention, Aquaria n’est pas libre, son code à été libéré mais c’est tout. Il faut toujours payer pour avoir les assets du jeu. Ça explique sûrement son absence des dépôts.

          Sinon quelqu’un continue de faire des mises à jour du code d’Aquaria (son dépôt est sur github) et il fournit des liens vers ses binaires sur le forum officiel d’Aquaria.

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 2.

          Je pense que les devs indépendants savent qu'ils vont gagner de l'argent avec leur jeu.

          Seul 10% des jeux sortis (indés et non indés confondus) sont rentables. Mes sources : des discussions avec des devs du milieu.

          • [^] # Re: Avis personnel

            Posté par  . Évalué à 5.

            Seul 10% des jeux sortis (indés et non indés confondus) sont rentables

            Il y a quand meme une difference entre ne pas faire assez de ventes pour rembourser l'argent investi dans le jeu et savoir a l'avance que presque personne payera pour le jeu et que tu n'as aucune chance d'en faire un boulot a plein temps.

            L'argument pour dire qu'on peut vivre du libre, c'est en general:

            • soit que les gens ne payent rien pour le logiciel en lui-meme mais grace aux contrats de support avec quelques utilisateurs importants tu peux gagner ta vie (sachant que la majorite des utilisateurs ne deboursera jamais le moindre centime si c'est dispo gratuitement par ailleurs)
            • soit que c'est sous forme de development specifique pour un client pour usage interne (cas typique pour les petites structures)

            On a des exemples de gens qui reussissent (parfois tres tres bien) en faisant ce genre de chose, mais j'attends encore de voir comment appliquer ca de facon reproductible a un jeu libre (code + donnees).

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 2.

          Pour Teeworlds c'est différent :

          Le jeu est composé de couleur très vives et des graphismes de type 'cartoon', le gameplay est assez simple mais bien pensé car il y a une réel différence de niveau entre les joueurs expérimenté et les débutant.
          Tout ceci fait qu'il attire un public plutôt jeune. C'est à dire, majoritairement entre 10 et 18 ans.

          Les joueurs régulier un peu plus mature sont souvent des anciens, très ancien pour certain. Ils forment un groupe détaché de la communauté.

          Du coup pour le développement de Teeworlds, la discutions est peu active entre les devs et les joueurs et le processus est assez fermé.

          En se moment, la version 0.7 est en préparation, et le dépot est redevenu actif. Redevenu car je trouve que le mode de fonctionnement est très atypique :
          Tout le monde fait ces modifs dans son coin pendant un bon bout de temps (entre la 0.6.1 et les premières modif de la 0.7, il c'est écoulé au moins 6 mois) et d'un coup de très grosse modif sont mergées, des propositions sont faites à la communauté. Depuis la reprise d'activité du dépot, il y a eu les nouveautés suivantes :

          • Deux nouveaux mode: SUR et LSM, respectivement Survival et Team Survival,
          • Amélioration graphique sur le rendu, les maps (encore en attente), les tileset,
          • Nouveau système de skin beaucoup plus puissant,
          • Peut-être un troisième mode: le mode Race,
          • Le menu principal à été totalement refait,
          • Des correction de bugs à la pelle et des améliorations de fond.

          Et il y en aura surement d'autres car pour l'instant, seul le travail de Choupom et Landil (les skins), Oy (dev principal), SushiTee (dev très actif) ont été intégré. Et encore, je ne consulte pas assez le chan IRC pour connaître ce qui est en préparation, par exemple il y a un appel à idées sur le forum pour le rajout d'une nouvelle arme…

          Donc comme tu peux le voir, les devs n'ont rien lâché du tout. Même le créateur de Teeworlds à repris de l'activité !

      • [^] # Re: Avis personnel

        Posté par  (site web personnel) . Évalué à 3.

        Il faut souvent sacrifier du code / des assets pour améliorer le gameplay, et je pense qu'un projet libre hésitera avant de jeter une partie du travail de ses contributeurs.

        Ça c'est un vrai problème, et c'est vrai qu'humainement c'est très difficile de savoir jeter !
        J'ai lu récemment un article, déjà ancien pourtant, sur le fait que Splash Damage avait jeté une dizaine de map pour Enemy Territory et Quake Wars… Ça doit pas être facile comme décision, et pourtant ça peut être nécessaire pour la qualité globale du projet !

        Je sais que le projet Nexuiz/Xonotic a fait plusieurs fois le ménage des ses maps, par souci de qualité.

        D'ailleurs, certaines de ces maps ont parfois été récupérées par OpenArena qui semble moins strict sur la cohérence et la qualité globale…

        ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Avis personnel

        Posté par  (site web personnel) . Évalué à 4.

        Hors ces studios comportent fréquemment moins de développeurs et d'artistes qu'un projet open source typique.

        Tu compares deux choses différentes:

        • un projet libre en général.
        • un projet de jeu.

        La première motivation dans un projet libre qui attire beaucoup de contributeurs, c'est de pouvoir utiliser le projet. Dans les jeux, c'est très différent: on développe les jeux pour que d'autres y jouent et ça change tout!

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Avis personnel

          Posté par  . Évalué à 4. Dernière modification le 22 août 2012 à 21:30.

          Non, je pensais aux différents projets de jeux libres que j'ai pu observer d'un peu près (je n'ai participé un peu qu'à Neverball). Il y a souvent une poignée de codeurs, et plusieurs artistes qui se relaient.

          Bien sûr il y a aussi des équipes plus restreintes… :)

          Je disais juste que ça existait, assez fréquemment. Et donc que "le problème" des jeux libres ne réside pas dans la quantité de travail fourni.

  • # To fork or not to fork

    Posté par  . Évalué à 8. Dernière modification le 23 août 2012 à 14:18.

    Comme forks d'OpenArena, il y a eu Q3min (mort), et Aftershock est un mod aux airs de fork dont le développement est au ralenti depuis quelques mois mais qui est encore utilisé sur quelques serveurs qui cherchaient à donner un côté plus "compétitif" au jeu. IHTG n'a jamais été significatif, il s'agit plus d'une page perdue dans le wiki. Et je crois en oublier un autre.
    Je vais pas raconter toute l'histoire de ces projets car comme pour ton journal ça prendrait du temps.

    Alors je vais plutôt parler de l'état actuel d'OpenArena,
    OA a lutté pendant un peu plus d'une année pour sortir une version 0.8.8. Et franchement, l'attente n'en valait pas la peine, car au bout du compte l'intention du chef de projet était d'en faire une mise à jour mineure (comme s'il cherchait à s'en tenir à la logique de numérotation mineure de version, alors que tout le reste du développement ne suit aucune logique). De même que pour la version 0.8.5, qui avait aussi mis une bonne année à sortir. Pourtant, durant ces longues periodes, des gens étaient tout chauds bouillants de faire des développements, pas mal de maps ont été produites, mais n'ont pas été intégrées. Entre temps également, les joueurs ont exprimé pas mal de besoins, mais ça semble tellement peu envisageable de pouvoir y remédier que personne n'a cherché à y répondre. (On attend encore le "hotfix" de la 0.8.8, on croyait pourtant que la 0.8.8 était déjà une mise à jour mineure ! En attendant on se tape des bugs graphiques sur une map populaire, et 2 nouveaux moyens de faire crasher les serveurs.).

    Une chose qui est difficile à constater, c'est l'évincement progressif des contributeurs et des efforts au sein du projet. Pas mal de contributeurs "pas nés de la dernière pluie" (du monde Q3) se sont détournés du projet, et parmi ceux qui se sont tout de même intégrés, ça n'est pas la fête de l'activité non plus (en terme de technique, ça remue plus en une journée sur le salon IRC de xonotic qu'en 6 mois sur le forum OA). Les causes principales: une politique bornée mêlée de froideur à l'égard de "ce qui n'entre pas dans le protocole", un manque d'accès aux infrastructures de développement, et sûrement d'autres choses comme l'exercice d'une autorité qui rompt avec les tentatives de dialogue. Au final il ne reste sur le forum:
    - que les cons, une minorité, à l'origine de la désertion et qui adhèrent à cette manière de gérer le projet
    - les naïfs, qui arrivent dans le projet en pensant qu'il est possible d'y contribuer
    - et quelques "techniciens", qui trouvent un intérêt à y participer ponctuellement (c'est quand même intéressant de toucher à ioquake3 dans un projet qui lui donne vie par la communauté de joueurs qui l'utilise)
    Le point commun de tous ces gens: la politique de gestion du projet ne les dérange pas suffisamment. J'ai rien contre les 2 dernières catégories, j'ai d'ailleurs moi-même "fait avec" pendant longtemps.

    Je n'ai pas assisté à l'accouchement de la 0.8.8 car j'ai été banni du projet plusieurs mois auparavant. Très peu de gens ont réagit suite à cette sortie, et l'activité des développeurs s'est soudainement tassée, là où pourtant on pourrait s'attendre à une certaine excitation, comme pour les projets où une nouvelle version s'est fait attendre pendant longtemps.

    Et pourtant, et pourtant … ça ne fork pas. Faute de manque de gens motivés, et du trop d'énergie gaspillée. Un espoir résidait dans Aftershock, car les développeurs qui en sont à l'origine font davantage preuve d'ouverture, mais hélas également moins habitués à gérer des projets opensource.

    Et pour parler brièvement de Warsow, TremZ, ou des projets qui semblent brinquebalants que tu cites, je soupçonne que leur soucis, c'est que les personnes qui sont à leur tête ne croient à l'origine pas plus que ça au logiciel libre et aux licences libres, ou alors, ils n'en ont pas mesuré toute la portée (et il faut avouer que ça n'est pas simple d'en mesurer la portée).
    Puisque un peu plus haut ça discute de l'échec des initiatives liées aux jeux libres, il faudra bien leur apprendre qu'on peut leur clouer le bec à ces jeux (semi)-propriétaires :P

    • [^] # Re: To fork or not to fork

      Posté par  (site web personnel) . Évalué à 3.

      Ah merci pour ce commentaire qui complète bien mon journal !
      En fait je n'ai pas cité Q3Min parce que je n'ai trouvé plus trouvé de lien pertinent. Donc entre deux projets morts, j'ai cité celui qui avait une description sur le wikia d'OpenArena… Ça ne change pas l'idée que les rares forks n'ont pas fait long feu. :)

      Merci des détails concernant OpenArena (projet que je connais moins). Tu décrit une impression que je ressentais plus ou moins, j'avais déjà entendu parlé de ces difficultés de dialogues, mais pas aussi bien décrites.
      Pour les trois catégories de ceux qui restent, cela ressemble un peu à Tremulous, sauf que pour Tremulous il y a une 4ième catégorie, ceux qui restent uniquement pour décourager et dire « mais ça sert à rien ce que tu fais, Tremulous est mort, c'est trop tard », dès que quelqu'un arrive la bouche en cœur avec un peu d'espoir pour donner un nouveau souffle dans un quelconque domaine.

      je soupçonne que leur soucis, c'est que les personnes qui sont à leur tête ne croient à l'origine pas plus que ça au logiciel libre et aux licences libres, ou alors, ils n'en ont pas mesuré toute la portée (et il faut avouer que ça n'est pas simple d'en mesurer la portée).

      Oui, c'est un sentiment que j'ai, et que je traduis certainement mal quand j'essaie de faire le lien avec des méthodes qui me semblent plus habituelles au monde propriétaire. Les arguments que j'ai donné ne sont peut-être pas les bons, mais ils essaient de comprendre pourquoi, souvent, le libre n'est qu'un détail pratique (ce qui est déjà pas mal).

      Ce n'est peut-être pas vrai pour tous les concepts de jeu vidéo, mais pour la catégorie de jeu multijoueur en ligne (et pas nécessairement FPS) qui permet de faire évoluer progressivement l'univers, une communauté libre devrait pouvoir (avec le temps) fournir des jeux d'excellente qualité. En fait les licences CC n'obligent pas nécessairement les sources, ça se comprend pour un enregistrement audio, où l'on ne peut sourcer ni l'interprète ni l'instrument etc. mais cela fait que beaucoup de ressources sous licence CC considérées libres (CC-By-Sa par exemple) ne viennent pas sans sources. Par exemple la plupart des maps de Tremulous viennent sans les sources. Si elles étaient fournies avec les sources, on aurait pu les améliorer de manière incrémentale (rajouter des détails, changer les textures, corriger des problème d'équilibrage entre les deux classes de combattants…). Beaucoup trop de choses sont à remplacer plutôt qu'à faire évoluer, et ça bouffe des ressources inutiles.

      ce commentaire est sous licence cc by 4 et précédentes

  • # Commentaire supprimé

    Posté par  . Évalué à -4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Connaisse pas la joie des depots

      Posté par  (site web personnel) . Évalué à 3.

      Un jeu c'est un produit 'fini'

      Rien n'est moins sûr !

      C'est vrai sur le marché de la console de jeu, mais ce n'est qu'une manière de concevoir le développement d'un jeu, même si cette idée est majoritaire.
      Ce n'est pas parce que le plus gros marché du jeu vidéo fonctionne sur ce principe que tout développement de jeu vidéo doit se faire selon ces mêmes rêgles.

      Avec le même raisonnement on pourrait dire :

      Un programme c'est un produit 'fini'.
      Donc quand ça marche on n'y touche pas, on n'a pas besoin des sources non plus, et c'est très bien ainsi !

      Et puis les depots c'est bien gentil, mais c'est au bon vouloir des mainteneurs. Bref encore des gens exterieur au projet a gerer.

      Rien n'empêche un mainteneur (par exemple celui de PlayDeb) d'être considéré justement comme le mainteneur du jeu NNNN et pour ce rôle, membre de l'équipe de développement de NNNN. Les ensembles 'développeurs' et 'mainteneurs' ne sont pas fondamentalement disjoints, il peut y avoir jonction. Le travail du mainteneur peut être complètement intégré au projet.

      Soit le projet peut demander à son membre qui fait habituellement les packages de rejoindre l'équipe d'un dépôt, soit au contraire, le projet qui est habituellement empaqueté par un dépôt peut proposer au mainteneur de ce dépôt de rejoindre l'équipe pour ce rôle, créer un lien social, avoir en lui un interlocuteur privilégié, lui donner un droit de regard et la possibilité de poser des rapports de bugs visant à améliorer son travail d'empaquetage, et in fine une meilleure expérience utilisateur.

      L'inverse de « je fais un setup parce que ça n'attend pas » n'est pas, « je publie l'url d'un dépôt et j'attends qu'un inconnu surgisse de nulle part poussé par la main invisible et empaquette tant bien que mal le jeu sans jamais me demander de l'aide ».

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -3. Dernière modification le 26 août 2012 à 19:31.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Connaisse pas la joie des depots

          Posté par  (site web personnel) . Évalué à 3.

          Bref un jeu est une 'oeuvre', que tu fasses evoluer ton marteau si tu veux, mais touche pas a l'art.

          C'est pour ça que Mike Oldfield a sorti 3 « Tubular Bells »…

          Tu sais qu'en musique (art interprété, vivant) il existe plusieurs versions de partoches ou d'harmonisation pour certains morceaux ? Qu'un musicien interprète ne reproduit jamais une œuvre, il ne fait que produire de nouvelles œuvres dérivées et éphémères à chaque fois qu'il interprète ?

          Bref, tu prends un cas particulier (valable pour une statue ou une peinture, quoiqu'elle puisse faire l'objet d'un travail de restauration, et tu l'étends à tout l'art) mais c'est pas pertinent du tout ! Et le théatre ? Et la danse ? Tout ça se rapproche beaucoup du jeu ! Et pourquoi un programme ne serait pas une œuvre d'art, et dans ce cas là, sous prétexte de l'intouchabilité d'une statue ou d'un bâtiment classé, l'on ne pourrait y toucher ?

          Pour le reste du débat dépôt vs setup, je vais pas trop perséverer parce qu'on sait que ça ne mène à rien. Je vais me limiter à cela :
          En effet, si ton but est de faire un jeu 'figé', alors oui tu peux faire un setup ala windows, il y a des très très vieux binaires de jeux proprio sous linux qui marchent encore (mais aussi rares que sont tout simplement rares les jeux sous linux) ce qui prouve que c'est possible.

          Pour un jeu comme Unvanquished, le jeu évolue, des maps sont régulièrement créées, ce qui fait de l'univers d'Unvanquished un univers en expansion. Et puis les développeurs ont le droit de ne pas faire un jeu "définitif", même si d'autres le font, et s'il ne le font pas, un dépôt est une excellente idée.

          Si tu veux faire un jeu définitif, oui tu peux te restreindre à une archi (ou mieux, une vm), mes jeux megadrive marchent toujours parce qu'on sait comment émuler une megadrive, il y a pas 300 modèles, mais Unvanquished n'est pas un jeu console prévu pour sortir sur cartouche ou galette de plastique en lecture seule !
          Unvanquished est en release early, release often, il y a des corrections de bug, des améliorations, des optimisations, de nouvelles peut-être y aura-t-il de nouvelles fonctionnalité… Ils pourraient faire un setup, mais travailler avec le gars qui gère le dépôt ça prend pas nécessairement plus de temps, et pour les raisons sus-citée, le dépôt est une meilleure idée pour ce type de jeu.

          Surtout, le débat dépot vs setup est biaisé parce qu'en fait c'est un débat setup sur une seule distribution avec seulement des différences de version et quelques saveurs vs 5000 dépôt pour 5000 distribution. Le débat des 5000 distributions est un autre débat, mais il empêche de débattre sereinement de la pertinence d'un dépôt : ce n'est pas un défaut du modèle "dépôt" qu'il y ai 5000 distribs, et c'est uniquement le fait qu'il y ai 5000 distribs qui fait que le modèle "dépôt" ne marche pas complètement, mais ce n'est pas un défaut du modèle "dépôt".

          Et Steam sous linux, faut pas rever ca sera pas toutes les distribs, deja si il y en a deux ca sera un miracle. (et tant mieux, si ca peut consolider le desktop ca sera pas un mal).

          Un dépôt comme PlayDeb fait un peu le rôle de steam pour les jeux libres ou semi-libres/portables. Alors oui ce n'est que pour Ubuntu, mais là encore c'est un autre débat que le "figé" vs "maintenu" ou "setup" vs "dépôt", autre débat qui nuit beaucoup, mais autre débat.

          Et puis je vais troller méchamment, mais je préfère que la plate forme linux de référence pour jouer sois une imaginaire PlayPlayLinux ou Ubuntu Linux ou une autre mais qu'elle existe ! Et peu importe les déçus qui auraient préféré leur préférée, et peu importe comment cette référence s'établit. Si (par exemple), demain à cause de PlayDeb et Steam, 99% des jeux tournent sans souci sous Ubuntu (et on s'en fout que ce soit celle-ci ou une autre), on aura déjà fait un GRAND pas en avant ! Des centaines de joueurs gardent un dual boot sous Windows pour pouvoir jouer, il préfèreront avoir dans un coin de leur distrib préférée un chroot Ubuntu pour jouer, utilisable sans rebooter, et complètement intégrable à leur environnement. Hop, plus de reboot, plus de dual boot, seulement un chroot libre, quel grand progrès ce serait !

          ce commentaire est sous licence cc by 4 et précédentes

  • # fork d'outil libre

    Posté par  (site web personnel) . Évalué à 2.

    Je suis confronté au problème avec Tiled…

    https://linuxfr.org/users/devnewton/journaux/newton-adventure-la-soluce-2-6-terminer-le-vatican-sans-papoter

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Une retrospective d'Unvanquished !

    Posté par  (site web personnel) . Évalué à 2.

    En langue anglaise, on trouve sur le blog du projet une rétrospective très détaillée, en plusieurs parties.
    Pour le moment deux « tomes » sont sortis, un troisième devrait paraître, ainsi qu'une nouvelle alpha d'Unvanquished !

    Unvanquished: A Retrospect (Part I)
    Unvanquished: A Retrospect (Part II)

    La rétrospective remonte très loin, à Quake 2 et son mod Gloom !

    De mon coté, je suis tombé par hasard sur une vieille page abandonnée d'Xtr3m, une n-ième tentative de port de tremulous sur XreaL, abandonnée après avoir décidé de réécrire le moteur from scratch (!) en laissant un lien vers encore un autre projet mort : Dretchstorm (http://dretchstorm.com/). J'ai trouvé ces cadavres en cherchant des infos sur un vaporeux port de Tremulous sur le CryEngine 3 dont on m'a parlé pendant une partie, infos que je n'ai pas trouvé tellement c'est fumeux (le gars qui disait avoir rejoint l'équipe a ensuite répondu à quelqu'un d'autre jouer à Unvanquished depuis seulement deux jours, y a vraiment de drôles de fantasmes de fork autour de Tremulous) !

    ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.