De nouveaux jeux libres à découvrir

Posté par  (site web personnel) . Édité par Davy Defaud, baud123, NeoX et Benoît Sibaud. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
18
5
nov.
2012
Jeu

Et de 4 ! Voici la quatrième compilation de l’association LanPower produite en 2012. C’est avec un plaisir non dissimulé que l’association dévoile son dernier CD de l’année : le CD tout public Série 1.

Avec cette compilation, nous débutons une nouvelle série de 2 CD qui porte le numéro 1. Pourquoi cette numérotation, bien que ça soit la cinquième série ? Suite à un trou historique, la série 1 avait disparu (pour devenir la série 2).

Lors de la réalisation des premières compilations, il y a plus de 5 ans, nous ne pensions pas faire autant de CD de jeux libres originaux et sympathiques.

Cette nouvelle série en est pourtant un exemple avec de très belles réalisations, telles que Plee The Bear, Pink Pony ou Tower Toppler, accompagnés des jeux phares YoFrankie et Hedgewars.

Comme l’on peut s’en douter, les créateurs sont internationaux, et parmi les développeurs principaux ou à l’initiative du projet, on peut remarquer quelques français — Plee the Bear, Kitsune et 2H4U —, japonais — Area2048, Gunroar —, américains — Cultivation —, espagnols — Pixbros, Holotz Castle — et allemands — Blobby Volley.

L’association LanPower n’a pas ménagé ses efforts pour les mettre en forme ou les améliorer : correction de la traduction de Cultivation, traduction des manuels de Area2048, Gunroar, Cultivation, réalisation d’icônes et d’installateurs.

Comme d’habitude, les jeux sont en version Windows, mais existent tous sous GNU/Linux. En outre, l’interface étant compatible GNU/Linux grâce à Wine, ils peuvent être testés pour certains sur ce système d’exploitation à partir du CD (voir les notes de compatibilité).

Les autres compilations produites en 2012 sont :

Aller plus loin

  • # schtroumpf grognon

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

    Pourquoi consacrer vos efforts à du packaging pour Windows alors qu'il y a tant à faire pour les systèmes libres?

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

    • [^] # Re: schtroumpf grognon

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

      -Parce qu'on n'a pas encore l'interface pour faire de telles compilations, mais on y travaille : ça pourrait débuter ici : MultiinstallEdit pour Linux. "Il y a rien" bien oui, rien n'est encore commencé.
      -les gamers à faire passer au libre sont très majoritairement sous Windows.

      • [^] # Re: schtroumpf grognon

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

        Je n'ai pas trop compris ce qu'était MultiinstallEdit, mais n'est-il pas plus efficace de faire des paquets debian (par exemple)?

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

        • [^] # Re: schtroumpf grognon

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

          Je vais peut être dire une bêtise mais je ne vois pas Newton adventure dans les dépots Debian.
          C'est d'ailleurs sûrement la seule raison pour laquelle je ne l'ai pas encore essayé ;-).
          Il semble me souvenir que ce jeu est écrit en java mais n'y a t il pas une manière de le pakager ?

          Au passage merci et toutes mes félicitations à LanPower (même si je rejoint devnewton sur son commentaire au sujet du pakaging) et merci à tous les créateurs de jeux libres !!

          kentoc'h mervel eget bezan saotred

          • [^] # Re: schtroumpf grognon

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

            Il semble me souvenir que ce jeu est écrit en java mais n'y a t il pas une manière de le packager ?

            suivre http://wiki.debian.org/Java/Packaging

            il y a même des recommandations agrémentées de quelques exemples :

            bon bien-sûr, ouvrir une ITP ou au minimum une RFP peut aider (si vous ne savez pas ce que c'est, demandez à quelqu'un pouvant expliquer, un DD éventuellement :D sinon, bien-sûr il y a aussi de la doc' mise en évidence sur http://www.debian.org/doc/).

            • [^] # Re: schtroumpf grognon

              Posté par  . Évalué à 4.

              J'avais essayé de packager devnewton pour Debian mais il nécessite des libs qui ne sont pas packager dans Debian. Il faut donc commencer par packager ces libs. Et là, ça devient pénible.

              « 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: schtroumpf grognon

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

                J'ai fait un paquet hier soir pour tester. J'ai fini par mettre le jeu et toutes ses dépendances dans /opt/newton_adventure, mais ce n'est pas génial, mais est-ce acceptable?

                Je pourrais aussi générer un gros jar avec toutes les libs java et me contenter de la seule dépendance native: lwjgl.

                Malheureusement, la version packagée par debian est vieille de plus d'un an et il lui manque une fonctionnalité importante: la gestion des fenêtres redimmensionnables.

                Je peux peut être faire une branche spéciale debian qui ne gère pas ça?

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

                • [^] # Re: schtroumpf grognon

                  Posté par  . Évalué à 4.

                  Je ne pense que ce soit acceptable par Debian. Mais bientôt, la nouvelle version va sortir, du coup, il sera possible d'avoir une version de la lib à jour dans les backports.

                  « 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: schtroumpf grognon

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

                    Ce qui me freine, c'est combien de temps va-t-il falloir pour avoir les libs dont je dépends dans debian pas backport?

                    Si ça se compte en années, autant que je fasse un PPA…

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

                    • [^] # Re: schtroumpf grognon

                      Posté par  . Évalué à 4.

                      Je pense que si tu veux un paquet rapidemment. Il vaut mieux que tu fasse toi même un paquet qui englobe tout.

                      « 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: schtroumpf grognon

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

                        J'ai regardé un peu plus comment faire et soumettre un paquet debian: c'est la misère, j'aurais le temps de développer 3 jeux le temps que j'en comprenne les subtilités :-(

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

                    • [^] # Re: schtroumpf grognon

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

                      L'avantage d'un PPA c'est qu'effectivement, cela peut te donner un paquet potentiellement installable (mais pas forcément intégrable à debian). Cela revient un peu à faire le travail en double : tu risques de faire des choix (embarquer les libs notamment) qui vont à l'encontre des bonnes pratiques de création de paquet (libification + ajouts de docs/man + vérification des licences… + chaîne de génération conforme pour plusieurs cibles : Squeeze, Wheezy, sid…).

                      Au moins ça te donnera le temps d'avoir des remarques sur la constitution de ton paquet, voire des patchs, voire trouver un mainteneur motivé :-) Et une fois fait le travail pour constituer un paquet acceptable pour une distribution, cela simplifiera le travail pour d'autres distributions.

                      • [^] # Re: schtroumpf grognon

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

                        Au lieu d'un gros deb, je pourrais peut être pondre n petits deb, un par dépendance, comme ça si un packageur debian passe dans le coin< il n'aura qu'à piocher.

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

                        • [^] # Re: schtroumpf grognon

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

                          oui ;-)
                          Bon après, il te recommandera peut-être de regrouper certaines choses ;-)

                          Déjà, si tu as une liste des dépendances (sur un wiki par exemple), tu peux noter :

                          • celles déjà disponibles (un paquet existe),
                          • celles dont une version supérieure serait nécessaire (si le paquet existe déjà, tu peux contacter le mainteneur et voir avec lui la difficulté qu'il y a à passer à la version qui te serait nécessaire)
                          • celles non empaquetées qui sont nécessaires (tu as dû les lister dans ta conf' maven…) pour le build
                          • et celles non empaquetées nécessaires pour le fonctionnement de l'appli (avec des versions minimales réalistes ou celles que tu as utilisées)

                          Il y a bien la page BuildHowTo ;-) mais pas vraiment une liste effective des dépendances, hormis sur jeux_libres_linuxfr mais qui est peu détaillée :/

        • [^] # Re: schtroumpf grognon

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

          J'ai envi de rajouter : notre temps de bénévolat étant limité, on se concentre sur une facette du problème. Pour notre part, on produit des CDs pour promouvoir les jeux libres auprès des gamers Windowsiens, et on laisse le reste du boulot à faire aux autres (et il y a plein de chose à faire mais l'énergie de bénévolat a ses limites). Si les ventes de CDs ou autres activités connexes aux jeux libres, marchaient bien, on pourrait envisager le problème autrement.

    • [^] # Re: schtroumpf grognon

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

      C'est une bonne remarque, lanpower pourrait faire beaucoup pour le jeu libre en s'occupant de packager les jeux pour les différentes distributions. (Voir de maintenir des dépôts s'il y a besoin, pour Ubuntu il y a playdeb, mais pour certaines distributions il n'y a pas d'équivalent)

      Ce serait un recentrage intéressant pour l'association à mon avis, mais c'est bien sûr à vous de voir. Ce serait l'occasion d'écrire de la doc sur comment packager un jeu, faire un .desktop, les bonnes pratiques pour faciliter le packaging, etc…, et de faire remonter patch ou remarques upstream pour aider les devs à faire du bon boulot.

      Le jeu libre manque de structures qui s'occupent de ce qu'il y a autour des jeux, qui cherche à faciliter l'accès à ceux ci, à uniformiser les usages, etc…
      Ça peut vouloir dire développer des outils comme un menu pour lancer facilement les jeux avec une manette, packager et catégoriser les jeux correctement (pitié, les catégories de jeux dans le menu Gnome2, c'est atroce, les FPS sont tantôt dans action tantôt dans arcade, ya aucune logique), pousser les devs à aller dans le bon sens : respecter les standards comme XDG, supporter les manettes de jeu, les différentes résolutions, avoir des contrôles configurables et non qwerty-centrés, …

      • [^] # Re: schtroumpf grognon

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

        les FPS sont tantôt dans action tantôt dans arcade, ya aucune logique

        On voit souvent Arcade et Action dans les annuaires de jeux, mais ça correspond à quoi exactement???

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

        • [^] # Re: schtroumpf grognon

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

          À rien, ce sont des catégories trop floues pour être intéressantes.

          Action concerne tout ce qui est temps-réel, en général un poil violent. ça va du beat-them-all au FPS.
          Arcade tout ce qui se rapproche de ce qui se jouait sur borne d'arcade, qui est orienté fun et pas simulation réaliste. J'y mettrai tout ce qui est shoot-them-up, voir les puzzle-game.

      • [^] # Re: schtroumpf grognon

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

        Je plussoie tout le commentaire. N'ayant pratiquement pas touché aux jeux vidéos pendant pas mal d'années, j'ai décidé récemment de remettre le nez dedans, afin de découvrir l'univers du jeu libre (dont ma connaissance se limitait jusqu'alors à Tuxracer et Metal Blob Solid…). Hé bien pour résumer, actuellement, c'est un peu le foutoir. La communauté du libre a un super potentiel, on le voit bien sur les logiciels utilitaires, mais sur les jeux ce potentiel est trop peu exploité. Et c'est dommage, parce que la base des jeux libres est loin d'être pauvre, et contient beaucoup de bons trucs, il ne reste plus grand chose à faire pour que le péquin moyen puisse "jouer sous linux" out-of-the-box sans se prendre la tête.

        Voir de maintenir des dépôts s'il y a besoin, pour Ubuntu il y a playdeb, mais pour certaines distributions il n'y a pas d'équivalent.

        Alors si on commence par Ubuntu, il y a beaucoup à dire. Quand j'ai voulu tester l'offre existante en jeux vidéos libres, j'ai commencé par installer une Ubuntu vierge sur une machine (relativement) puissante. Pourquoi ? Parce que Ubuntu est excellente pour jouer. On dira ce qu'on voudra, Ubuntu est bugguée, instable, prend l'utilisateur pour un imbécile, change d'interface toutes les 4 releases, les dépôts sont en bordel, etc…mais elle n'a pas d'équivalent pour les jeux. D'abord les dépôts de base sont bien fournis en jeux. Ensuite, il y a ce gestionnaire d'applications, que je déteste utiliser, mais dont je reconnais l'utilité pour qui veut découvrir l'univers des jeux libres : quand on ne connaît aucun des jeux disponibles, on n'a pas que ça à faire d'ouvrir un browser pour chercher une présentation de chacun des jeux sur le web, et une description texte est loin d'être suffisante. Alors qu'un logiciel qui présente une liste des programmes, avec une icône donnant déjà une idée du style graphique (et de l'époque), et un ou plusieurs screenshots si on clique dessus, ça donne déjà plus envie ! On notera également le fait que quand on se rend sur le site d'un projet récent, on a généralement un .deb pré-packagé pour les gens qui utilisent la dernière LTS, les autres distros…configure-make-make-install.
        Enfin il y a les PPA. Le dépôt playdeb, c'est génial. Le site en lui-même est organisé comme un gestionnaire d'applications, on a les jeux , leur description, un screenshot, leur popularité, leur note, leur licence, etc. Parfois certains projets ont leur propre PPA, mais c'est assez rare. Un gros reproche à faire à playdeb, par contre : c'est encore plus le bordel que dans les dépôts officiels. On y mélange des jeux libres, des jeux au code libre et aux données non-libres, des jeux sous licence libre mais aux sources incomplètes, des jeux libres selon la FSF, mais pas selon les DFSG, etc. Bref, on dirait que la philosophie de playdeb, c'est « on fout tout dans main, allez sur le site pour avoir les détails » (et encore, même sur le site il y a plein d'erreurs). (Note: ce que je dis ici reste valable pour les boutiques de jeux style djl : c'est le foutoir dans les licences.)
        J'allais oublier un autre super avantage d'Ubuntu : la reconnaissance du matériel (périphériques exotiques) souvent un peu plus soignée que sur les autres distros, et surtout les drivers graphiques bleeding-edge, pour avoir les meilleures performances possibles avec des drivers libres (je pense notamment au PPA d'Oibaf). Parce que mine de rien, avec des jeux comme Unvanquished ou 0AD on est sur le point de mettre un terme à la loi qui veut que n'importe quel PC bas de gamme (ou haut de gamme blob-free) est suffisant si on ne veut jouer qu'à des jeux libres.

        Bref, tout ça pour dire que c'est un peu déprimant, pour un geek fier de défenestrer une bonne fois pour toute son PC, parce qu'il vient de constater que l'offre de jeux libres était amplement satisfaisante, de devoir garder un Ubuntu en dual-boot à côté de sa Debian/Arch/Fedora/PC-BSD/[insérer le nom d'une distro agréable à utiliser], juste pour jouer aux jeux. Quelle ironie ! On ne le dira jamais assez : Ubuntu est bel et bien devenu le « Windows du linuxien ».
        (En passant, est-ce que quelqu'un a déjà réussi à faire fonctionner Those Funny Funguloids en natif ? dépôts, binaire officiel, compilation…rien à faire : seul le binaire Windows lancé dans Wine m'a permis d'en profiter.)
        (En passant bis, est-ce que quelqu'un a déjà réussi à installer un jeu Spring sous GNU/Linux, et à y jouer sans problème ? Il faut installer un moteur de jeu, télécharger des mods, télécharger des maps, les extraire dans tel ou tel dossier, ça change selon les versions, le site officiel est bordélique au possible, c'est une galère pour savoir ce qu'on télécharge et sa licence, y'a un lanceur, on peut lancer certaines maps mais pas d'autres…Hé ho ! Sans vouloir me faire l'echo d'un geek bien connu, « z'auriez pas un .deb ? » (ou juste un tutoriel pour sots et malcomprenants, au moins…))

        Pour revenir aux dépôts, ne serait-il pas pertinent de mettre les données des jeux dans un dépôt "backports" ou "volatile", pour les distros vieilles et stables ? Les données des jeux libres sont souvent en permanente évolution, et elles ne posent pas vraiment de risques de sécurité/instabilité…

        pousser les devs à aller dans le bon sens : respecter les standards comme XDG, supporter les manettes de jeu, les différentes résolutions, avoir des contrôles configurables et non qwerty-centrés, …

        J'ai été surpris par le manque de finitions de jeux pourtant aboutis depuis pas mal de temps. Il y a encore des jeux sous GNU/Linux qui changent la résolution de tout l'écran quand on change la résolution dans le jeu, même en mode fenêtré ! O_o
        Quant aux claviers qwerty centrés…c'est si dur que ça de mettre dans chacun des jeux une petite brique de code générique qui change AWSD en QZSD en se basant sur la keymap ? C'est vraiment impossible de prendre en compte la touche MAJ ou le numpad par défaut pour accéder aux touches numériques ? Les joueurs français, belges ou tchèques sont-ils condamnés à remapper les touches de tous les jeux qu'ils installent ?

        Ah, oui, un dernier truc : le peu d'accent mis par les devs sur l'aide. Pas la doc, mais l'aide dans le jeu, les tutoriels, les didacticiels, tout ça. Beaucoup de jeux libres sont des clones de jeux propriétaires, on suppose donc que le joueur les connaît déjà, sait déjà comment y jouer. Pourquoi donc ? Pourquoi notre premier contact avec un jeu de simulation économique, par exemple, ne serait-il pas un jeu libre ?
        J'ai notamment été surpris de voir que Nexuiz disposait d'un didacticiel (simple, mais bien fait), alors que son descendant direct Xonotic, non. C'est d'autant plus étonnant que Xonotic est supposé donner une seconde via à Nexuiz, dont le nom a malheureusement été entaché par la puissance marketing d'un concurrent privateur

        • [^] # Chez moi ça marche

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

          j'ai pu installer spring sans problème sur gentoo, il y quelques années déjà (je crois que c'est même ça qui m'a fait passer à gentoo) puis sur arch et ubuntu .
          dans tout les cas, j'ai utilisé springlobby qui permet de récuperer les carte et les mods (en p2p avec les autre joueurs) et qui les mets dans le bon dossier. (en gros c'est un wrapper de spring)

          sinon je plussoie a peu près tout (si ce n'est qu'un remappage possible c'est déja bien, (je me souviens d'un jeu sympa avec des lapin qui se saute dessus qu'on doit recompiler pour changer de keymap (édition des #define toussa )

          d'un côté le gars il fait un jeux pour se faire plaisir, il fait comme il veut au final.

          sinon félicitation pour votre initiative de bundle libre, mais c'est vrai que sur linuxfr, on est plus intéressés par les jeux libre qui fonctionnent sur linux.

          • [^] # Re: Chez moi ça marche

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

            je me souviens d'un jeu sympa avec des lapin qui se saute dessus qu'on doit recompiler pour changer de keymap

            Ca doit être Jump'n Bump !

        • [^] # Re: schtroumpf grognon

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

          En passant, est-ce que quelqu'un a déjà réussi à faire fonctionner Those Funny Funguloids en natif ?

          Non, j'ai jamais réussi il me semble. J'avais croisé un paquet deb à l'époque où j'étais sous Ubuntu mais le jeu plantait.

          En passant bis, est-ce que quelqu'un a déjà réussi à installer un jeu Spring sous GNU/Linux, et à y jouer sans problème ?

          Jamais… On m'a toujours dit que spring était des meilleurs jeux libres, que c'était trop bien, qu'il fallait y jouer, mais j'ai jamais réussi à lancer une partie (j'ai réussi une fois je crois et le jeu avait planté ou bien j'avais un problème d'affichage, bref ça n'allait pas)

          Ah, oui, un dernier truc : le peu d'accent mis par les devs sur l'aide. Pas la doc, mais l'aide dans le jeu, les tutoriels, les didacticiels, tout ça.

          C'est incroyable le temps et l'effort que demande le développement d'un tutoriel par rapport au temps passé sur le dev du jeu. Développer un tutoriel oblige à ajouter des fonctionnalités à son jeu pour pouvoir mettre le jeu en pause, afficher des indications à l'écran, réagir aux actions du joueur, avoir des sous-objectifs, …
          Et souvent c'est difficile à concilier avec l'architecture du code. (Du coup certains craquent et font n'importe quoi, je vous invite à aller voir le code du jeu Lugaru, ya des «if (levelname=="tutoriel")» dans à peu près chaque fonction)
          C'était normalement la prochaine chose qu'on devait ajouter à Genetic Invasion, le tutoriel, mais le développement du jeu s'est brutalement arrêté ^
          (Pour ce qui est de Slime Volley dont j'ai repris le développement il y a quelques jours, on devrait ajouter un niveau avec ce fond là en guise de tutoriel : http://mcmic.haxx.es/fotoo/i/cb/6uCZ7cShD.slimevolley-tuto2.png )

          • [^] # Re: schtroumpf grognon

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

            Dans Newton Adventure, au lieu d'un tutorial, j'ai juste mis une page d'aide. Pour des jeux simples, quelques écrans d'explication sont suffisants, même si c'est la mode de faire un tutorial de 15min pour apprendre à jouer à un mario like.

            Aide Newton Adventure

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

          • [^] # Re: schtroumpf grognon

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

            C'est incroyable le temps et l'effort que demande le développement d'un tutoriel par rapport au temps passé sur le dev du jeu. Développer un tutoriel oblige à ajouter des fonctionnalités à son jeu pour pouvoir mettre le jeu en pause, afficher des indications à l'écran, réagir aux actions du joueur, avoir des sous-objectifs, …

            J'en suis conscient. Et non seulement ça demande beaucoup de travail, mais en plus c'est loin d'être la partie la plus motivante du développement d'un jeu, généralement. À mes yeux c'est un peu comme écrire la doc pour les programmes-outils : c'est la partie chiante, mais nécessaire, et qu'il faut éviter de repousser, parce que c'est le point de départ de l'agrandissement de la communauté.

            Un bon exemple, pour moi, c'est le jeu Widelands : je n'ai jamais joué à Settlers, et pourtant j'ai pu entrer sans difficulté dans l'univers de Widelands, quand bien même le jeu était loin d'être abouti. Tout simplement parce que les développeurs se sont concentrés assez vite sur les didacticiels (les campagnes d'introduction, pour être plus correct). Résultat, on apprivoise le jeu très vite, on se rend compte qu'après les campagnes d'intro il n'y a plus rien, mais on a déjà envie d'aller farfouiller dans l'éditeur, d'imaginer la suite du scénario, de proposer des trucs, bref, de faire avancer le développement. On ne peut pas en dire autant des autres jeux de simulation économique (les clones de Civilization et de Sim City).

        • [^] # Re: schtroumpf grognon

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

          En passant bis, est-ce que quelqu'un a déjà réussi à installer un
          jeu Spring sous GNU/Linux, et à y jouer sans problème ? Il faut
          installer un moteur de jeu, télécharger des mods, télécharger des
          maps, les extraire dans tel ou tel dossier, ça change selon les
          versions, le site officiel est bordélique au possible, c'est une
          galère pour savoir ce qu'on télécharge et sa licence, y'a un
          lanceur, on peut lancer certaines maps mais pas d'autres…Hé ho !
          Sans vouloir me faire l'echo d'un geek bien connu, « z'auriez pas
          un .deb ? » (ou juste un tutoriel pour sots et malcomprenants, au
          moins…))

          Spring et SpringLobby s'installe et fonctionnent sans aucun problème sous Slackware. Les cartes et autres mods s'installent classiquement dans le répertoire ~/.spring.

          L'idée est de compiler et d'installer le moteur (Attention aux dépendances comme devIL, openAL, et boost, sources téléchargeable ici : http://springrts.com/wiki/Download ), puis les mods et les cartes et les AI si besoin s'en faisait sentir (tout ça est dispo sur springfiles.com).

          De mémoire, il faut malgré tout certaines librairies dans leurs versions pas trop obsolètes ou tout au moins celles en concordances avec la version de Spring que tu veux compiler.

          Optionnellement (mais me semble t-il obligatoire pour jouer en réseau), installer SpringLobby.

          Spring est en effet un excellent jeux de stratégie, très rapide et avec un mod 'kernel panic' fabuleux (il faut aimer les graphismes tron-like).

      • [^] # Re: schtroumpf grognon

        Posté par  . Évalué à 2.

        Hum…
        Personnellement, pour découvrir un jeu avec ma debian, j'utilise aptitude => vue par debtags et je vais dans la catégorie que j'ai envie.
        Après, pour les catégories du menu "démarrer"… Aucune idée, j'en ai pas ^

        Pour ce qui est du coup de gueule sur la packaging, j'ai envie de dire deux choses:
        1) ".configure && make && make install" ça me semble dépassé, les dernières compilations que j'ai vues c'était "mkdir build && cd build && cmake .. && make && make install". Au moins la sortie est lisible et la procédure peut fonctionner sur n'importe quel OS.
        2) avec cmake, il est possible de générer les paquets pour la plupart des distros en se prenant moins la tête. Moins, mais il faut quand même maintenir la liste des dépendances, et je me demande toujours pourquoi diable boost n'a pas de méta-package chez debian, chose qui oblige les dev à préciser le numéro de version dans le nom du paquet…

        Pour le coup, la situation me semble meilleure (ou peut s'améliorer) grâce a cmake (je sais pas si les autres ont un mécanisme idoine aussi simple à gérer), mais il n'empêche que ça reste du boulot de maintenir le cmake pour chaque distro (combien, déjà? 400? de toute façon: trop pour maintenir). Et si le jeu n'utilise pas ce procédé sous prétexte qu'ils utilisent les PPA d'ubuntu, ben… à qui la faute?

        Bien sûr, je parle de cmake, et peut-être existe-t-il d'autres mécanismes aussi chiadés (portable et simple), mais je ne les connais pas, alors je vais pas en parler ;)
        Après, forcément, cmake n'est pas conforme à la philosophie POSIX, puisqu'il est capable de faire plusieurs choses, mais je ne veux pas lancer un débat sur le fait que ".configure" soit obsolète ou pas (bien que, personnellement, je pige pas comment ça marche, je me dis que d'autres ont peut-être le problème inverse)

    • [^] # Re: schtroumpf grognon

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 06 novembre 2012 à 10:16.

      C'est une très bonne façon pour moi de vous poser une question.
      On a souvent tendance à dire que sous windows, on a un système homogène ce qui permet de faire des packs alors que sous linux non. Autant que j'ai pu le comprendre, l'ABI du kernel, de la libc,… ne change pas du jours au lendemain, et ce qui rend les choses difficiles, c'est dingo les dépendances aux bibliothèques extérieures. Et de ce point de vue, les Un*x et Windows ne sont ni meilleurs ni moins bons les uns que les autres.
      Seulement, sous Windows, on fait souvent des packs avec toutes les libs incluses alors que pour les poilus, on préfère gérer les dépendances via des gestionnaires de packages.

      Je peux comprendre ça, moi même j'hésiterais plus à installer une calculette de bureau qui me prendrait 50 Mo sous linux, alors que ca me gène beaucoup moins sous windows, allez savoir pourquoi.

      Oui mais Linux est bientôt prêt pour le desktop, comme tout le monde le sait. Donc il faudrait penser à tous ces galbes du menton qui veulent que ça juste marche.

      Du coup, je me dit qu'il serait assez simple de faire un programme d'installation auquel le 'packager' donne à manger les binaires et la description des dependances (QT>2.3, Xlib==…) et qui créerait un pack décompressable chez l'utilisateur final, avec un script à la volée du genre:

      export PATH=$INSTALL_DIR:$PATH
      export LD_LIBRARY_PATH=$INSTALL_DIR:$LD_LIBRARY_PATH
      cd $INSTALL_DIR
      ./start_program
      
      

      On peut ensuite imaginer des améliorations sur cette base:
      - Le programme peux ne décompresser QUE les libs non déjà présentes ou de version incompatibles, mais ça implique que la désinstallation d'autres softs peut impacter le logiciel (je ne décrit pas ici un nième gestionnaire de dépendances)
      - Voir même, avec une connexion Internet, le programme peux ne télécharger QUE les libs nécessaires

      j'aimerais beaucoup faire ce programme, mais j'ai comme l'impression que ça existe déjà en 12 versions et que je n'ai pas vraiment compris la problématique de fond.

      Alors, un tel soft serait-il utile/pertinent/débile/pas assez geek mon fils ?

      Ceci n'est pas une signature

  • # réponse collective

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

    Je répond à plusieurs messages : effectivement, on pourrait travailler les jeux libres sous Linux, mais le vrai souci actuel et qui nous occupe, ce sont les joueurs qui sont essentiellement sous Windows comme je l'ai déjà dit. De plus , c'est plus difficile de faire un objet CD qui irait avec beaucoup de distrib, alors que sous Windows les outils existent, de plus, ils sont partiellement compatible Linux grâce à Wine : Avec la Gamekey Light série 2 on est aussi compatible Linux, donc on touche un très large public. Pourquoi des CDs et non pas des packages à mettre sur un dépôt ? Parce que d'autre le font déjà. Autre avantage des CDs : on s'affranchit du besoin de liaison internet (ça sert encore notamment dans des salons)

    • [^] # Re: réponse collective

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

      Un point que je trouve important, c'est aussi que c'est un autre moyen de faire connaître et promouvoir le libre, à ceux qui évoluent plutôt dans un univers propriétaire. C'est pour ça que la même chose pour Linux a à mon avis moins d'intérêt… Bref, continuez ;-)

    • [^] # Re: réponse collective

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

      De plus , c'est plus difficile de faire un objet CD qui irait avec beaucoup de distrib

      Mais justement, on ne vous demande absolument pas de faire des CD pour GNU/Linux.
      Le CD en lui même est un support mourant, mais le CD en tant que support pour logiciels n'a jamais eu beaucoup de succès dans le libre, encore moins dans le jeu-libre.
      Par contre effectivement faire une clé USB bootable avec une distrib très orientée jeu est intéressant (pas de login utilisateur, menu plein écran avec les jeux par catégories, jeux sélectionnés pré-installés, …). Je dis ça je dis rien mais ce serait un chouette projet de framakey et ça en ferait peut-être enfin une que j'ai envie d'acheter pour de vrai…

Suivre le flux des commentaires

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