1st post

• [^]Re: 1st post

  Posté par champi (page perso, ) le 20/09/2002 à 10:28. (lien). Évalué à 53.

  Exactement, on peut le voir sur des jeux comme egoboo (egoboo.sourceforge.net) ou le très prometteur planeshift (www.planeshift.it), vegastrike... Les programmeurs n'ont aucun mal à exploiter des technologies comme l'accélération 3D, une gestion correcte du son, des périphérique de jeu... Mais bon, on ne peut pas exceller partout, et le manque de graphiste et de scénaristes est réellement flagrant.
  
  De plus les jeux commerciaux comme UT2003 montrent bien que linux est capable de performances au moins aussi bonne que d'autre plates forme en terme de jeu.
  
  Motivons-nous :)

  • [^]Re: 1st post

    Posté par Matthieu Moy (page perso, ) le 20/09/2002 à 12:40. (lien). Évalué à 3.

    Ce qui s'rait bien, c'est que les développeurs s'associent avec des boites commerciales pour qu'elles leur fassent des bô graphismes ... Payants.

    • [^]Re: 1st post

      Posté par Stephane Marchesin (page perso, ) le 20/09/2002 à 17:03. (lien). Évalué à 26.

      Figure toi que j'y ai réfléchi quand j'ai eu la proposition d'une personne qui voulait faire ça avec un jeu dont je développe (en partie) le code. Ce qu'il proposait était en gros qu'il allait s'occuper des modèles 3d, des textures et tout ça, moi je pouvais garder le moteur en gpl et on allait vendre le tout.
      
      J'y ai réfléchi d'autant plus que je n'ai pas encore réussi à trouver de graphiste 3d motivé par le projet.
      
      Mais en y regardant à deux fois, l'open source n'a pas besoin d'un moteur sans données (textures, modèles, graphs) de plus. Ca ne fait pas un jeu du tout, et des moteurs de jeu il y en a suffisament comme ça, et bien plus polyvalents que le mien, comme ogre, crystal space...
      Je pense même que la valeur des jeux est maintenant de plus en plus dans les données elles-mêmes, j'en veux pour preuve qu'urban terror ou counterstrike ne sont que des packs de donées rajoutés sur des moteurs 3d (q3 ou halflife), et pourtant on parle d'eux comme des jeux à part entière.
      
      En plus, une des deux parties risque d'être lesée par un tel accord, qui allie deux interêts totalement opposés (commercial vs open source).
      
      Du coup, j'ai décliné une telle proposition. Je me suis dit que comme j'avais développé ça sans artistes pendant plus d'un an, je pouvais continuer comme ça encore un peu, plutôt que de faire du commercial.
      
      A mon avis, ce qu'il manque surtout aux jeux open source c'est un endroit où les graphistes, les programmeurs et les musiciens peuvent se rencontrer pour créer des projets (ouverts !). Et même sur sourceforge, savannah, flipcode et autres gamedev les chances de trouver des artistes sont infimes, car n'y vont que les développeurs.
      
      Si vous connaissez un site qui fait ça, postez !
      
      Sinon, si quelqu'un veut participer, ou veut voir le jeu (jeu de course 3d) c'est là (qui sait, peut-être que grâce à linuxfr...):
      http://www.nongnu.org/daredevils/(...)

      • [^]Nekeme

        Posté par Thomas RIBO (page perso, ) le 22/09/2002 à 10:09. (lien). Évalué à 11.

        Chez Nekeme prod., l'association ayant pour but de promouvoir le libre ludique, autrement dit les jeux vidéos libres, c'est un peu ce que nous proposons. Nous regroupons divers projets de jeux et développons des outils permettant aux gens motivés de développer leur propre jeu sans que des connaissances de programmations soient requises (ou alors minimes, c'est-à-dire savoir faire une liste ordonnée d'actions). Si suffisamment de personnes nous rejoignent, il y a moyen de développer un bon gros pôle de développement de jeux libres. En fait, la seule chose qui nous manque, c'est de sortir un bon jeu qui nous fasse plus de publicité. Mais je vous rassure, c'est en cours ;-)

      • [^]Re: 1st post

        Posté par Ontologia () le 22/09/2002 à 20:52. (lien). Évalué à 7.

        Faisons quelques chose ! L'idéal serait un site où programmeur, designer, graphiste et scénariste se rencontreraient. Effectivement comme le consensus le reconnait ici, de très bon programmeurs existent, les moteurs sont là, etc... Ils font de très bon jeu, beau, mais plats. Je viens de jouer à Vegastrike... C'est très joli, mais ou est le jeu ? Que faut-il faire, tourner dans tous les sens ? Je serai ravi d'écrire des scénario et je connais d'excellents graphistes, motivables, à condition de les assurer qu'ils aient un scénar interressant et un bon codeur... Pour revenir à l"idée du site, il faudra veiller à la confiance à établir, car un scénario, cela se vole et il ne faut pas le donner à n'importe qui. Un scénar sous licence GPL, ça donnerait quoi ? ;o)) Ce site ressenserait les codeurs, les moteurs disponibles, les outils de dvp graphiques pour chacun des ces moteurs, etc... Ensuite on passe à SourceForge...

        • [^]Re: 1st post

          Posté par Stephane Marchesin (page perso, ) le 22/09/2002 à 22:33. (lien). Évalué à 6.

          Je suis tout à fait d'accord sur la nécéssité de créer un site où peuvent se retrouver les développeurs/artistes/contributeurs de tout poil de jeux libres. Malheureusement je n'ai pas de talent artistique à fournir pour le design d'un tel site :( mais je suis prêt à y participer, mon mail vous est ouvert. Un tel site pourrait recenser les projets et les personnes par catégories, et faire coller les bonnes personnes avec les bons projets. En plus, ça pourrait avoir l'avantage de fédérer plus facilement plusieurs projets open source qui veulent faire le même type de jeu. Ou permettre d'aider les gens qui veulent contribuer à un jeu open source mais qui ne trouvent pas leur bonheur. J'ai par ailleurs l'impression que sous windows il y a plus d'artistes en tout genre (qui sont sans trop de compétences en informatique, donc sous windows) qui seraient motivés pour créer des jeux mais qu'il y a moins de développeurs (sous windows, les développeurs m'ont l'air d'avoir plutôt tendance à faire des projets commerciaux). Cela pourrait amener des gens dans le monde libre. Après tout, l'open source a réussi à séduire les programmeurs, pourquoi pas ensuite les artistes ? Sinon, un article très intéressant sur la création de jeux open source écrit par Shawn Hargreaves, l'auteur d'allegro, est là : http://www.talula.demon.co.uk/games.html Comme il le dit lui-même c'est inspiré par ESR.

  • [^]Re: 1st post

    Posté par Stéphane VANPOPERYNGHE (page perso, ) le 20/09/2002 à 14:56. (lien). Évalué à 17.

    Pour ce qui est des graphismes, je pense que l'idéal serait que les développeurs s'associent avec des graphistes "spécialisés" comme on peut en voir sur LinuxGraphics (http://www.linuxgraphic.org/(...)). De temps en temps, ils participent au design de sites comme TuxFamily.org (http://www.tuxfamily.org/(...)).
    
    Ensuite, pour la musique, ce serait bien dommage qu'il n'y ait pas quelques volontaires parmi des musiciens de demos (un MadMax like pour les connaisseurs). Il y en a beaucoup d'ailleurs qui se sont tournés vers le jeu par la suite.

  • [^]Re: 1st post - La motivation ne suffit pas !

    Posté par Joseph Maillardet (page perso, ) le 21/09/2002 à 12:51. (lien). Évalué à 7.

    Je suis d'accord sur ce constat : Sur une vue global des différents projets, il y a un manque énorme de créativité graphique et sonor dans les jeux open-source. Mais j'attacherai plus d'importance aux causes de ce manque.
    
    Ma perception des choses est que la plupart des artistes numériques ne sont pas doués en informatique, du fait que leurs recherche artistique est déjà un travail à temps plein. Il recherche donc pour la plupart des stations de travail simple d'approche sans aucune difficulté d'installation et de configuration et surtout des stations qui s'adresse à eux, avec leurs vocabulaire et leurs "empirismes pratique" tout comme par exemple : les "masques de fusions" dont le nom rappelent directement la technique utilisé en photographie et permet donc au connaisseur d'appréhender - sans lire de doc - l'utilité de la chose.
    
    Fort de ce deuxième constat, je pense qu'il est avant tout nécessaire de développer fortement les outils mis à disposition des graphiste et autre animateur, scénariste etc... Avant de vouloir mettre en pratique leurs folie créative sous linux. Aujourd'hui je suis heureux de voir que blender à été racheté pour être mis sous licence GPL et j'espère plus que jamais que ce projet gagnera ces lettres de nobles dans l'univers 3D tout comme theGimp les à gagner et les entretiens dans la 2D. Parceque si je veut voir de la "belle" 3D dans les jeux free, il faut commencer par avoir un bon soft 3D free...
    
    Amicalement, Jok'x

• [+] [^]Re: 1st post

  Posté par Aurélien Girard () le 20/09/2002 à 15:07. (lien). Évalué à -5.

  Ca serait assez malvenu de dire du mal de Frozen Bubble, mais pourtant c'est ce que je pense.
  
  Je suis un fan de Puzzle Bobble (j'ai même acheté une NeoGeo Pocket Color rien que pour ce jeu), et j'ai été très déçu du gameplay : Frozen Bobble est très nettement moins bon que PuzzleBobble ou PuzzleBobble2 (le meilleur).
  
  La jouabilité est encore plus mauvaise que dans Super Puzzle Bobble, mais sans tous les gadgets (combos, poulies, terrains non rectangulaires, ...).
  
  Heureusement, Frozen Bubble est un LL, il finira bien par s'améliorer, et en attendant, il y a toujours les versions Playstation/Saturn et NeoGeo (hop un p'tit coup de MAME) de Puzzle Bobble 2 pour passer le temps.

  --
  BeOS le faisait il y a 10 ans.

Développement sous Linux: les jeux

• [^]Re: Développement sous Linux: les jeux

  Posté par Eric Boulat () le 20/09/2002 à 11:28. (lien). Évalué à 27.

  C'est normal qu'il y ait moins de jeux sous linux, puisque le succés d'un logiciel commercial sous linux est loin d'être assuré (culture du logiciel libre, plateforme non uniforme).
  Or sur un jeu, ce qui coûte cher, c'est pas le moteur (le même sert sur des dizaines de jeux et les algos de base existent depuis 10 ans déjà). Ce qui coute cher c'est le contenu, les graphismes, le son, le scénar. Tout ceci est le rôle de non-développeurs, qui n'ont pas forcément le même intérêt que les développeurs open source à travailler pour pas un rond.
  Je me souviens du projet ALE (un warcraft like) qui avait résolu le problème en fournissant un utilitaire pour extraire les graphismes et les sons de Warcraft II. Ca leur avait permis de toucher un plus large public et du coup, certains graphistes amateurs leur avait fournis généreusement d'autres graphismes.
  C'est une piste à explorer pour les autres projets, mais tout les jeux ne sont pas aussi ouverts que Warcraft II !

• [^]Re: Développement sous Linux: les jeux

  Posté par daggett () le 20/09/2002 à 11:45. (lien). Évalué à 49.

  C'est trés curieux d'ailleur parce qu'il existe des tas et des tas de moteurs de jeu
  
  Tellement des tas que je trouve qu'il y en a trop... Comme tout le monde j'ai essayé de développer un jeu (que, comme tout le monde, j'ai laissé à l'abandon depuis 2 mois), alors je suis allé voir sur Sourceforge, section game, les projets similaires. Dans la section "RTS" qui m'interessait en l'occurence, il y avait... 391 projets. Maintenant il y en a 413.
  
  Dans le tas il y a peut-être 5 jeux "corrects" et 5 moteurs bien finis, tout le reste est plus ou moins à l'abandon, ou pire, même pas commencé (le fameux "Development Status: 1 - Planning"). (Le plus marrant étant les sommaires pompeux et irréalistes que mettent les auteurs. Un projet etait seulement au stade "Planning" mais l'auteur savait deja combien de missions et de créatures différentes il y aurait...)
  
  Bon j'ai un peu dévié de ce que je voulais dire au début: est-ce que beaucoup de moteurs ça aide vraiment à produire des jeux ? Le problème d'un moteur "générique" de jeu de rôle ou de stratégie, voire de sprites, c'est que leur auteur a une idée en tête, il croit que c'est générique, mais en fait il donne des contraintes.
  Avant de me lancer dans le code de mon projet mort-né, j'ai regardé les moteurs qui existaient déja, mais ils ne convenaient tout simplement pas aux specs que je m'étais donné (aussi bien les moteurs de jeu haut-niveau que les moteurs de sprites).
  
  Ca doit être un syndrôme assez généralisé d'ailleur, dans le domaine des jeux opensource: on a envie de coder son truc à soi et tout maîtriser. Peut-être ceux qui s'essaient aux jeux maintenant sont ceux qui tentaient de faire des démos il y a quelques années; dans ce cas, comme pour moi, pas question de prendre une librairie de sprite ultra-généraliste avec des fonctionnalités inutiles alors qu'on peut écrire ses routines optimisées en fonction du cadre qu'on s'est donné.
  
  J'aimerais mieux que ceux qui écrivent leurs moteurs en fasse un jeu complet finalisé (ne serait-ce que pour prouver aux autres qu'on peut effectivement s'en servir: Le moteur de Quake a une démo convaincante, qui est le jeu quake lui-meme; En revanche un moteur trouvé sur Sourceforge... il faut qu'il fasse ses preuves.)
  
  Enfin je voudrais lancer une supplique à tous ceux qui sont tentés par mettre leur projet de jeu sur sourceforge: FAITES LE D'ABORD CHEZ VOUS !! Si vous êtes capable de tenir la motivation à développer votre truc jusqu'à arriver au moins au stade "Development Status: 3 - Alpha" à l'aide de gens motivés recrutés par les forums ou irc, alors vous aurez peut-être la chance de continuer jusqu'à un vrai produit, et l'enregistrer sur sourceforge sera alors profitable. Si, comme moi, vous laissez tomber au bout d'un mois, c'est que de toute facon ca ne valait pas le coup.
  
  
  Enfin, oui, je suis d'accord sur le gros gros GROS manque de graphistes [doués], de désigners, de "sound-effect-er" (on n'y pense pas assez, à ça. Ca me rappelle, dans Freecraft, quand un batiment brûle, le fichier son utilisé c'est la voix d'un gars qui dit "burning" !). D'ailleur si vous êtes interessés pour faire les graphismes d'un starcraft-like, je suis preneur, dès que je serai remotivé ;)

  • [^]Re: Développement sous Linux: les jeux

    Posté par _seb_ () le 20/09/2002 à 12:41. (lien). Évalué à 15.

    Effectivement l'aboutissement d'un jeu complet et fonctionnel est trés difficile, surtout lorsqu'on est seul et que le résultat final n'est pas celui escompté (notament en terme de graphisme, son etc.). Ca devient presque plus facile de faire un moteur de sprite ou même 3D uniquement :-)
    
    <AVOCAT DU DIABLE>
    Il existe pas mal d'utilitaires (cvs, doxygen, etc.) sous linux pour permettre le developpement d'applications (jeux compris). Je vais me faire étripper en disant cela mais il n'y a presque pas de logiciels spécialisés pour le developpement d'un jeu et de manière générale d'une application multimédia. Par exemple, il n'y a pas d'équivalence pour Poser (logiciel de création de personnage 3D), pour Director (environnement de développement d'applications interactives), peu de logiciels 2D/3D et je ne parle même pas des logiciels de son.
    </AVOCAT DU DIABLE>
    
    Si l'on veut qu'un jour des graphistes, des musiciens, des scénaristes participent au developpement de jeux sous linux (par forcement sous licence GPL), il faut leur en donner les moyens. Surtout que des projets dans cette optique existent:
    http://www.linuxgraphic.org/(...)
    
    Ensuite la commercialisation d'un jeu sous Linux ne devrait (AMHA) pas coûter beaucoup plus chèr en terme de temps passé sur le developpement du jeu. Le portage d'un jeu d'une plateforme à une autre (windows, PS2, Dreamcast) est déjà pris en compte lors de la création du jeu.

    • [^]Re: Développement sous Linux: les jeux

      Posté par Brunus () le 20/09/2002 à 13:57. (lien). Évalué à 36.

      Je suis infographiste/developpeur...je peux vous dire que pour les artistes, les solutions sous Linux sont très suffisantes. Blender + Gimp + sketch ça suffit au niveau graphisme...même pas besoin de se payer une license cher comme celle de Maya.
      
      Je rappel qu'on faisant des jeux sur Amiga 2000 avec Deluxe paint et des logiciels de 3D...qui ne savaient pas vraiment faire autre chose que des sphères...( j'abuse )
      SoundTracker pour la bande son et on pondait un Elite, Dungeon Master, ou R-Type...que dire de très belles réalisations comme Shadow Beast !
      32 couleurs c'était déjà du luxe...et le scrolling différentiel horizontal l'arme absolue !
      
      Cryo s'est perdu en superproduction Pharaonesques...beau, très beau jeux mais ininteressants ou injouables.
      
      Warcraft II c'est le meilleur produits de ces dernières années...et les outils utilisés par les infographistes tournaient(3DS4 et Smacker de RAD)pas sur silicone-graphics !

  • [^]Re: Développement sous Linux: les jeux

    Posté par BMenez (page perso, ) le 20/09/2002 à 12:50. (lien). Évalué à 5.

    J'aimerais mieux que ceux qui écrivent leurs moteurs en fasse un jeu complet finalisé (ne serait-ce que pour prouver aux autres qu'on peut effectivement s'en servir: Le moteur de Quake a une démo convaincante, qui est le jeu quake lui-meme; En revanche un moteur trouvé sur Sourceforge... il faut qu'il fasse ses preuves.)

    
    
    C'est vrai que ce serait beaucoup plus facile pour voir les possibilités du moteur. (d'ailleurs +1)
    
    Autre chose : je trouve qu'il manque quelque chose dans le style DirectX sous Linux. Avec DirectX, on a affaire à une seule librairie permetant de programmer le graphisme (2D/3D/vidéos), l'audio (sons/musiques), le réseau... Tout cela avec un squelette commun. Sous Linux, il faut un moteur (on recherche sur le net celui qui nous parait le mieux), une lib audio (à chercher aussi), programmer le réseau à la main ou avec une lib (faut chercher encore). Bref, il faudrait un SDK permettant de "démarrer du bon pied" sans avoir à se soucier d'autre chose que le design du jeu. J'ai un peu d'expérience avec DXSDK et je peux dire que l'on s'y habitue très vite

    • [^]Re: Développement sous Linux: les jeux

      Posté par daggett () le 20/09/2002 à 13:01. (lien). Évalué à 19.

      Pour le SDK, je vais pas être original, mais SDL fait à la fois gestion de l'affichage, des évenement clavier/souris, du son, du réseau, et supporte l'openGL. Cela dit je n'ai pour l'instant utilisé que ces 2 premières fonctionnalités, et j'ai pu très rapidement obtenir quelquechose de concret en très peu de temps (je parle aussi bien en terme d'apprentissage que de vitesse de codage).
      
      Mais, sans connaitre DirectX, je suppose quand même que SDL en est loin. (Pour certaines fonctionnalités un peu avancées, oui il faut sans doute chercher des librairies qui s'utilisent par dessus SDL.) M'enfin Loki (Paix à son âme...) s'en est bien servi pour tous ses jeux, ça doit donc être solide.

      • [+] [^]Re: Développement sous Linux: les jeux

        Posté par BMenez (page perso, ) le 20/09/2002 à 13:15. (lien). Évalué à -4.

        Merci pour cette précision. Je pensais que SDL ne faisait que l'affichage et la gestion du clavier.
        
        (-1 parceque j'aurais du me renseigner avant de poster)

    • [^]Re: Développement sous Linux: les jeux

      Posté par ufoot (page perso, ) le 20/09/2002 à 14:35. (lien). Évalué à 19.

      > dans le style DirectX sous Linux.
      Ahem, ouais, bof... DirectX a un gros defaut, que Microsoft oublie de mentionner -> l'API change a chaque release. Donc si tu as appris a programmer avec DX3, pour passer a DX5 ou DX8, paye ton re-apprentissage.
      
      Alors, evidemment, tu re-apprends pas tout depuis zero car tu as deja des acquis. Mais c'est valable pour toute migration. Concretement, j'ai utilise la bibliotheque Allegro puis ClanLib, les 2 APIs sont tres differentes mais on s'adapte tres vite.
      
      Le probleme, c'est que pour migrer un code existant d'une API vers l'autre -> t'es mort...
      
      Alors bien sur, ton vieux code DX3 pourra se recompiler dans un environnement DX8. Mieux, un vieux binaire compile il y a 5 ans avec DX3 marchera sur une machine ou il y a DX8. Le seul probleme, c'est que la doc de DX3 n'est plus vraiment disponible. Pas tres pratique pour coder... Donc evidemment tu peux juste ajouter un peu de DX8 par-ci par-la dans une appli qui utilisait DX3. Le seul defaut c'est qu'a force d'utiliser ce genre de methode le code est tout caca.
      
      Je prefere de loin l'approche OpenGL ou l'API est *beaucoup* plus stable, quitte a ne pas etre parfaite ni adaptee au matos dernier cri...

  • [^]Anecdote personnelle

    Posté par Antoine () le 20/09/2002 à 12:55. (lien). Évalué à 45.

    J'ai bossé chez Cryo y a quelques années. Effectivement beaucoup de programmeurs viennent (venaient ?) du monde de la démo et de la bidouille autodidacte. Ca pose beaucoup de problèmes pour faire adopter des stratégies de développement saines et viables. Par exemple, il y a des coders qui refusent absolument de toucher à du C++ ; c'est pas qu'ils comprennent pas, non, c'est que c'est le Mal incarné par rapport au C qu'ils sont habitués à coder (et c'est du C plutôt bas niveau, genre j'optimise la moindre multiplication en la transformant en décalage à gauche, même si ce n'est pas dans un chemin d'exécution critique). Il y a en aussi qui ne veulent pas travailler avec des outils génériques, parce que ce ne sont pas eux qui les ont faits, et ils vont faire perdre des mois au projet en recodant un moteur customisé, qui finalement est moins bien foutu que le générique car le gars s'est concentré sur l'optimisation bas niveau au lieu de réfléchir à une conception intelligente et à des algorithmes efficaces.
    
    Dans le jeu sur lequel je bossais, on utilisait le moteur 3D de la boîte (entièrement en C++, massivement templatisé, vraiment belle conception et performances honorables) et la STL faisait partie des outils recommandés ; néanmoins sur les cinq programmeurs il y en avait deux qui n'utilisaient pas la STL mais leurs propres fonctions (pourries) de gestion de listes, et qui n'utilisaient pas les types intégrés au moteur 3D mais leurs propres types pour les objets géométriques (bonjour les conversions). Les deux programmeurs étaient, je te le donne en mille, des demomakers. Pour la petite histoire, le jeu n'est jamais sorti, en grande partie à cause du management exécrable de Cryo, mais aussi des problèmes de délais.
    
    Tout ça fait qu'à mon avis, en milieu hobbyiste où il y a peu de leadership, le développement d'un jeu peut se transformer en désastre en termes de perte de temps et de conception ratée. Bien sûr, ce n'est pas une généralité.

    • [^]Re: Anecdote personnelle

      Posté par Richard Hébert (page perso, ) le 20/09/2002 à 16:32. (lien). Évalué à 12.

      Interressant comme experience. D'aprés toi, quel serait le nombre minimal de participants pour un bon jeu type Warcraft III par ex. ( ou l'on ajouterait un peu plus de gestion fine des ressources...je trouve que ça manque dans ces jeux ) ?
      Quel serait le bon ratio codeur/designer (son+graphique)/scénariste... ?
      Ce que toi tu aurais fait en tant que responsable de developpement, quoi.
      Je pense pas être le seul que ça interresse !

      • [^]Re: Anecdote personnelle

        Posté par Antoine () le 20/09/2002 à 18:00. (lien). Évalué à 24.

        Je ne pense pas que l'effectif de l'équipe soit le problème principal. C'est plutôt le mode de développement. Un jeu video, ça touche à la création artistique (au sens large), la façon qu'on a de juger un jeu n'est donc pas du tout la même que pour un serveur Web par exemple. Un jeu et son gameplay forment un tout, un élément mal conçu rejaillit négativement sur l'ensemble du jeu (par comparaison, une fonctionnalité mal codée dans un utilitaire n'obère pas le reste des qualités du soft : il suffit de ne pas utiliser la fonctionnalité mal codée).
        
        D'autre part, un jeu a besoin d'une ligne directrice et d'une cohérence forte. Il faut avant tout qu'il y ait deux ou trois personnes ayant une vision d'ensemble précise de ce qu'ils veulent faire (gameplay, graphisme, programmation), et aussi que le reste de l'équipe soit prête à suivre les exigences de ces personnes-là. Pour prendre une analogie peut-être douteuse, tu ne remplaces pas un romancier de talent par une dizaine de journalistes travailleurs (par contre ils peuvent faire un très bon journal). Et on commence à toucher les limites du développement type bazar : en général les gens y rechignent à accepter un leadership, surtout s'il se base sur des critères extra-techniques qui peuvent sembler arbitraires. On n'aime pas être commandé dans un travail bénévole.
        
        
        Le mode de développement dans les boîtes de jeu s'apparente de plus en plus à celui de l'industrie du cinéma. Tout part d'un premier jet lancé sous la forme d'idées graphiques et scénaristiques (synopsis, dessins au trait et au crayon...). On recense les différentes caractéristiques du jeu, que ce soit au niveau du gameplay, de l'ambiance, des besoins techniques. Une charte graphique et une charte technique sont constituées, et des exemples peuvent être réalisés rapidement comme "proof-of-concept". Ensuite on affine progressivement en commençant réellement à implémenter certaines choses, certains éléments graphiques par exemple (meshes, textures, sprites...), et les briques de base au niveau technique. La suite est plus classique, une fois que les besoins sont clairement définis. Mais le but est toujours d'avoir des résultats évaluables le plus tôt possible (même s'ils sont très parcellaires), afin de juger de la validité du concept. Par exemple, avoir un premier niveau qui tourne est très important.
        
        
        Bon, pour répondre quand même à la question, côté effectif, un jeu "moyen" (en termes de budget) tourne à une dizaine de personnes pendant un an. Disons quatre programmeurs, quatre graphistes, deux game-designers. Ca dépend bien sûr du type de jeu, de la quantité de briques de base existantes et réutilisables, du temps que tu te donnes. Warcraft 3, si tu regardes le générique de fin, c'est autre chose : ils ont vraiment mis le paquet ! Mais c'est à cause de l'extrême finition graphique, scénaristique et sonore. Comme le suggère quelqu'un d'autre, un jeu comme Warcraft 2 doit être assez abordable pour une équipe bénévole. Note, il faut faire bien attention que les phases de réglage, débuggage, mise au point risquent d'être longues (même problématique que pour un environnement graphique : on veut un résultat très fignolé, très cohérent ; pas question d'accepter une juxtaposition de bidouilles disparates).
        
        (petit aparté à propos de Warcraft 3 : ils ont eu l'excellente idée de réaliser la plupart des séquences non-interactives en 3D temps réel, et en utilisant les mêmes modèles que pour le jeu lui-même. Du coup, même si c'est moins léché que les vidéos précalculées, ça a dû leur épargner un paquet de travail graphique et cinématique. Une voie à suivre à mon avis, surtout que ça épargne également les ressources soft et hard nécessaires à de telles cinématiques).
        
        
        Pour terminer, je dirais qu'un exemple de projet qui me semble avoir un mode de développement adapté à un jeu vidéo est... F-CPU. Il y a une ligne directrice claire (même si apparemment elle a pris du temps à se dégager ;-)), une personne - YG - a une vision d'ensemble complète, très précise voire autoritaire, et quelques contributeurs talentueux sont prêts à suivre cette vision même si c'est parfois au détriment de leurs propres opinions spécifiques. Et, bien qu'ils soient une petite équipe au regard de la tâche entreprise, ils avancent progressivement.
        
        
        PS : - Je précise que je n'ai jamais eu aucune responsabilité dans la supervision d'un jeu ;-))
        
        - Pour le son on peut sûrement se contenter de la contribution relativement ponctuelle d'une personne spécialisée dans le domaine.

        • [^]Re: Anecdote personnelle

          Posté par Antoine () le 20/09/2002 à 18:10. (lien). Évalué à 13.

          J'oubliais qu'il faut des gens pour tester le jeu. Non pas simplement des gens qui jouent (ça c'est facile à trouver ;-)), mais qui soient capables de déceler, d'expliciter et de recenser exhaustivement les problèmes liés au gameplay, à la facilité d'utilisation, les bugs, tout cela avec la vision du joueur moyen (encore une fois, même problématique que pour les environnements graphiques : savoir se mettre à la place de l'utilisateur final). Testeur est un métier à part entière dans l'industrie du jeu (et c'est moins amusant qu'on ne le croit...).

        • [^]Re: Anecdote personnelle

          Posté par Philippe Fremy (page perso, ) le 20/09/2002 à 19:02. (lien). Évalué à 3.

          Ce que tu dis confirme ce que je savais: il faut bien plus que quelques programmeurs pour faire un jeu.
          
          On voit que dans la description que tu donnes, les programmeurs sont en minorite, et la phase de programmation intervient apres l'idee et non pas avant (donc exit les "je vais faire un moteur et puis on verra").
          
          Et surtout, on voit qu'il faut preter beaucoup d'attention aux details, passer beaucoup de temps a ameliorer et accepter la critique sur des elements absolument pas techniques.
          
          Quand je vois la plupart des logiciels libres, je vois des programmeurs qui ne comprennent pas ces regles. Ils font des logiciels qui leur suffisent et ne voient pas tous les defauts. Car la demarche pour faire un bon jeu est la meme que pour faire un bon logiciel. Mais on est loin du compte.

          --
          phil.freehackers.org

        • [^]Re: Anecdote personnelle

          Posté par Thomas RIBO (page perso, ) le 22/09/2002 à 10:28. (lien). Évalué à 8.

          Pour le son on peut sûrement se contenter de la contribution relativement ponctuelle d'une personne spécialisée dans le domaine. Heu, je suis pas d'accord. Le son et la musique doivent être intégrés dès le début justement. C'est parce qu'ils sont justement relégués sur le côté en permanence, ou presque, que dans la plupart des jeux on coupe la musique pour pouvoir jouer en paix. La bande son participe énormément au plaisir de jouer et à l'ambiance qu'on veut donner. Si le musicien est intégré à la fin du projet, il ne peut pas sentir ce qui lui est demandé, connaitre l'importance d'un niveau sur un autre, etc. Pour faire un truc vraiment énorme, il faut réussir à avoir les leads de chaque morceau du jeu d'accords dès le début. Pour le reste, bonne analyse. Et les jeux commerciaux souffrent du même problème : avoir un chef de projet suffisamment bon humainement et techniquement et en terme d'expérience pour mener le projet au bout de manière correcte. Les jeux commerciaux (en France du moins) sont un peu trop faits pas des stagiaires qui ne peuvent avoir une vision globale de pérennité de leur code au sein de l'entreprise, de marche globale à suivre. Ils ne peuvent pas non plus ne pas tomber dans les pièges classiques dans lesquels les développeurs (au sens large, développeurs de JV) expérimentés sont tombés suffisamment de fois pour les éviter. C'est d'autant plus difficile dans le domaine des jeux amateurs (je ne parle même pas des jeux libres) car les gens sont là de leur plein gré, parce qu'au moment où ils rejoignent le projet, ils sont pleins de bonne volonté et de temps. Malheureusement, il faut du temps pour faire un jeu et le statut de ces personnes change au cours du temps, leur motivation aussi. Difficile donc de capitaliser de l'expérience dans une équipe disparate.

    • [+] [^]Re: Anecdote personnelle

      Posté par aem_ () le 27/09/2002 à 14:36. (lien). Évalué à -1.

      c'est dommage que ton experience avec ces individus soit si negative. dans d'autres boites, apparemment, on a su mieux les manager :
      rayman 2 a ete fait avec des demomakers.
      
      comme je l'ai moi meme ete pendant quelques temps, l'experience que ca m'a apporte dans un groupe, sur atari et amiga, le sens du design, de l'organisation, je m'en sers a present que j'ai cree ma propre entreprise de developpement ( pas en jeux ;-) ), et depuis 2 ans ca reussit pas trop mal apparemment :-)
      
      c'est sur que comme partout tu as des extremistes, mais je ne pense pas que cela soit la majorite, pour continuer a en cotoyer regulierement.
      
      l'humain est bien plus versatile qu'une machine, et heureusement :-)
      
      je peux aussi te citer des collegues sortant d'iut, ou de dess qui ont un niveau inferieur a celui de copains autodidactes, qui eux sont directement employables.
      y'a la theorie d'un cote, et la pratique de l'autre si tu preferes. apres, c'est a chacun de savoir faire des concessions.
      le travail d'equipe, ca je connaissais, mais j'ai eu a apprendre les methodologies, et a les appliquer...
      
      apres, si on refuse de les apprendre & appliquer, c'est clair qu'on fonce droit sur le mur mais c'est humain de se tromper aussi...
      
      par exemple, un collegue ayant une boite de sites web, embauche de preference des demomakers qui etaient sur amiga, a cause de leur sens du design et du travail en equipe. et je dois admettre qu'ils font un travail d'une qualite que je ne vois pas beaucoup dans la region (montpellier)...
      
      mais tout comme toi je suis d'accord sur un point : y'a un moment ou on doit lacher le hobby et savoir se comporter en professionnel, et rebondir sur ce qu'on a appris par passion, et pas seulement l'inverse.
      
      un qui l'a bien compris, c'est le codeur du moteur 3d & de l'i.a. de black & white (aussi un demomaker), ou encore le concepteur d'origine de tomb raider ( devine ! ;-) ) (entre autres)
      
      c'est egalement le role des chefs de projet d'entourer correctement et de remettre dans le droit chemin leurs troupes... ils n'en ont pas ete capables sur le moment ?
      
      peu de leadership ca peut aussi arriver dans le cas inverse... ici il s'agit essentiellement de l'humain, et que ce soit chez des autodidactes ou des "diplomés" on peut trouver de tout et son contraire :-)
      
      la motivation a travailler en equipe fait partie du succes a rendre un projet !

En hausse

• [^]Re: En hausse

  Posté par jojolapin (page perso, ) le 20/09/2002 à 11:37. (lien). Évalué à 7.

  Il devrait y avoir neverwinter nights aussi (même si ça commence à se faire attendre), et Doom III.

• [+] [^]oui mais ...

  Posté par snurpsss () le 20/09/2002 à 14:02. (lien). Évalué à -7.

  j ai acheté tribes 2 sous windows a ca sortie . A l époque j avais un dual boot win/linux . Le jeux tournais tres bien sur mon bi P2 400Mhz sous WIndows . J ai acheté une boite de tribes 2 sous linux et ma deception fut grande . Le jeu lag a mort . Et ca meme si on ne lance que X et le jeu . ( J ai pourtant une G400 qui est optimisé sous linux ) .
  
  Oui de nombreux jeux sortent et vont sortir sous linux ( Vivement civ3 ... =) ) , mais il reste le probleme de la config
  
  Sous windows et sous linux , la config de base pour un meme jeu , j entend pour le faire tourner , pas les pseudos conseils marqués sur la boite , varie de 500 Mhz facile entre Windows et Linux .
  
  Je pense que ca viens justement des lib utilisés , c est bete a dire , je suis pas dev , mais elles sont "trops ouvertes" (patapé) . Je ne vois pas de quoi ca peut venir sinon . Le moteur du jeu (en l occurence tribes 2) est pas mauvais , et sous un Athlon 1,8Ghz , ca tourne tres bien , mais ca demande , pour le faire tourner a meme vitesse bcq plus de puissance sous nux que sous win .

  • [^]Re: oui mais ...

    Posté par Rin Jin (page perso, ) le 20/09/2002 à 19:57. (lien). Évalué à 4.

    Je suis pas certains que les libs soient les seules choses expliquant une telles différences de vitesse (si elles l'expliquent). Peut-être faut-il aussi voir comment sont programmé de tels jeux: sur mon micro, certains sont plus rapide sous Linux que sous windows (RTWC par exemple), d'autres aussi rapide et les seuls jeux véritablement lents sont ceux que j'utilise avec wine (et encore, pour certains la différence est assez minimes).
    Mais pour la différence de 500MHz entre une version Linux et une version windows, je crois que tu t'avances un peu trop (ou alors, peut-être sur certains jeux mais certainement pas sur tous).
    Une question: qui peut m'expliquer pourquoi Doom (version sans accélération graphique, sinon, ça pulse) est plus lent que RTWC sur ma linuxette?

    --
    "On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone

    • [^]Re: oui mais ...

      Posté par Stephane Marchesin (page perso, ) le 20/09/2002 à 22:14. (lien). Évalué à 6.

      Tu donnes toi-même la réponse à ta question sur la vitesse de doom : doom est lent si on n'utilise pas l'accéleration 3d.
      
      Cela parce que la version linux de doom n'a pas les routines de texturage en assembleur (pour des raisons de portabilité), et tourne dans des résolutions bien plus hautes. Il ne faut pas perdre de vue que passer de 320x240 (résolution originale de doom) à 1280x1024 (résolution à laquelle le linuxien geek moyen tourne doom) multiplie le nombre de pixels à dessiner par 17 !
      Et 17 fois plus puissant qu'un vieux pentium 60 (machine minimale pour doom à 60 fps) c'est quand même un gros cpu ! Surtout que ça veut dire aussi mémoire 17 fois plus rapide, bus vidéo 17 fois plus rapide... Le cpu aura toujours du mal à faire autant de travail qu'un processeur graphique spécialisé.
      
      Moralité : charge prdoom (http://prboom.sourceforge.net/(...)) et sers toi de ta carte 3d !
      
      Sinon pour la différence de 500 Mhz, je ne suis pas d'accord, ça dépend effectivement de la qualité des drivers de ta carte vidéo et des drivers AGP. Les possesseurs de cartes nvidia sont les mieux lotis de ce côté-là (cf http://www6.tomshardware.com/graphic/00q4/001002/linux_nvidia-05.ht(...)).
      
      Par contre, les drivers de G400 ne sont pas les plus rapides en 3d. Il faudrait faire pression pour que les constructeurs de carte vidéo ne se contentent pas de donner les specs de leurs cartes mais expliquent aussi aux développeurs des drivers linux comment les optimiser pour la carte (une spec ne contient pas forcément les "trucs" qui rendent l'uilisation de la carte optimale, elle ne décrit que le fonctionnement vu de l'extérieur). D'ailleurs ça s'applique aussi aux drivers radeon qui souffrent du même problème.

      • [^]Re: oui mais ...

        Posté par ufoot (page perso, ) le 23/09/2002 à 11:30. (lien). Évalué à 3.

        > la version linux de doom n'a pas les routines de texturage en assembleur (pour des raisons de portabilité)
        Je suis pas sur que ce soit exactement ca le pb. A priori de l'assembleur pour i386 DOS ou i386 Linux, c'est pareil 8-)
        
        Ceci DOOM 1&2 etaient "optimises" pour le fameux mode-X - ie 320x200 en 256 couleurs avec 4 buffers "independants", tres pratique pour le page flipping - et ce mode-X avait la particularite de fonctionner de maniere tres, hum... particuliere, ce qui fait que les jeux optimises pour ce mode rament des qu'on utilise un mode plus "standard".
        
        Donc il y a encore plus que le rapport "17" que tu donnes, car entre:
        - doom en 320x200 en mode console (mode-X)
        - et doom en 320x200 sous X en 32-bits
        il doit y avoir une sacre difference deja...

        • [^]Re: oui mais ...

          Posté par Stephane Marchesin (page perso, ) le 23/09/2002 à 14:32. (lien). Évalué à 2.

          Je suis pas sur que ce soit exactement ca le pb. A priori de l'assembleur pour i386 DOS ou i386 Linux, c'est pareil 8-)
          
          i386 ? Attention, ceux qui ont linux sur sparc/alpha/mac/sgi/... vont encôre râler :)
          
          Et non, l'asm est pas pareil, sous X11 on ne peut pas écrire directement en #A000 (segment video où se trouvaient les 3 buffers qu'utilisait doom, et non 4) ce que doom faisait (puisque les 3 pages en question étaient en ram vidéo). Eh oui, la routine de texturage asm de doom dessine par segments verticaux ce qui colle très bien avec le mode-X.
          
          Effectivement, je n'ai pas compté le passage assembleur->C dans le *17, ni la copie vers la mémoire vidéo qu'il faut rajouter puisqu'on ne peut pas y écrire directement ni page flipper, plus la conversion 8bits->X11, plus l'overhead ajouté par X11, parce que je ne sais pas le facteur que ça fait, mais ça commence à faire beaucoup ;)
          
          PS : je viens de voir que tu es l'auteur de babal, il faut que je te remercie pour avoir occupé mes cours de philo :)

Mon expérience des jeux sous Linux

parsec & reaper & PlanetShift

• [^]Re: parsec & reaper & PlanetShift

  Posté par Philippe Fremy (page perso, ) le 20/09/2002 à 12:54. (lien). Évalué à 1.

  Il y a un certain nombre de jeu sous Linux mais rare sont ceux qui arrivent a la cheville des jeux commerciaux sous Windows, que ce soit au niveau performance, graphisme ou scenario.
  
  En vrac:
  boson (http://boson.eu.org(...)) tres prometteur
  freeciv (http://www.freeciv.org(...))
  pysol (plus l'addresse en tete)
  kshisen
  klotski (http://phil.freehackers.org/klotski/(...))
  Attal
  
  Le probleme, c'est que pour faire un bon jeu, il faut une bonne idee, un bon scenario, des bons graphismes, et de bonnes performances. En general, c'est autrement plus baleze que ecrir un editeur. On a du mal rien que pour trouver les developpeurs competents, alors vous imaginez le challenge pour trouver les graphistes et scenaristes!

  --
  phil.freehackers.org

  • [^]On continue avec les bonnes adresses

    Posté par Guillaume Rousse (page perso, ) le 20/09/2002 à 16:40. (lien). Évalué à 3.

    D'abord il y a le groupe Wolfpack (http://wolfpack.twu.net(...) ), qui a quand même à son palmarès XShipwars (http://wolfpack.twu.net/ShipWars/XShipWars(...) ) et Search and Rescue (http://wolfpack.twu.net/SearchAndRescue(...)), ainsi que Vertex (http://wolfpack.twu.net/Vertex(...) ), un modeleur 3D. En passant, ils sont train de planifier la prochaine version de XShipwars en 3D, si vous avez envie de vous investir dans un projet prometteur.
    Ensuite il y a aussi Civil (http://civil.sourceforge.net(...) ), un wargame sur la guerre de sécession, que je trouve très impressionant justement par sa richesse graphique et sonore. Bon, l'AI par contre... :-)

• [^]Re: parsec & reaper & PlanetShift

  Posté par Richard Hébert (page perso, ) le 20/09/2002 à 17:42. (lien). Évalué à 1.

  Ca faisait plusieurs fois que j'en entendais parler.
  J'ai donc récupéré les RPMS. Là problème il cherche la libpng.so.2 (j'ai la libpng.so.3...) Ok, va pour une petite compil. Retour sur le site. Cliquouille sur "Source" et que vois-je: SORRY, THIS PAGE IS UNDER CONSTRUCTION...
  
  -> Poubelle.

  • [^]Re: parsec & reaper & PlanetShift

    Posté par Julien Portalier (page perso, ) le 21/09/2002 à 16:39. (lien). Évalué à 3.

    le problème aussi de Planeshift, c'est qu'il n'existe que les rpms pour linux... par de tarball ni rien... alors bon, alien ça marche, mais c pas la panacée n,on plus quoi. Et puis pourquoi 4 paquets linux et 1 seul pour win32 ? Bref, pour moi c'est pas encore poubelle, mais bon.

  • [^]Re: parsec & reaper & PlanetShift

    Posté par Sylvain Rampacek (Jabber id, page perso, ) le 21/09/2002 à 19:04. (lien). Évalué à 4.

    Heu, ne le met pas à la poubelle tout de suite... J'ai déjà eu ce genre de problème avec un soft et j'ai forcé l'installation par rpm... Ensuite, j'ai juste fait un lien du fichier libpng.so.2 vers le fichier libpng.so.3 et ça à marché... Donc peut-être que pour toi ça marchera aussi !

    • [^]Re: parsec & reaper & PlanetShift

      Posté par Richard Hébert (page perso, ) le 22/09/2002 à 12:55. (lien). Évalué à 4.

      Arf c'est le premier reflexe que j'ai eu :) Je ne vais pas rentrer dans les détails ( et je ne suis pas suffisament calé de toutes façons...) mais lors du passage de la libpng 2 à la libpng 3, "on" a remanié le code en profondeur, de telle sorte que même en installant en parallèle les deux libs, on a une chance sur deux de faire planter l'appli qui fera appel à elles...( pour ceux que ça interpelle c'est ici > http://mandrakeforum.com/article.php?sid=1975&lang=en ) Pas de chance, c'est l'un des rares cas d' "incompatibilité binaire" :(

L'émulation...

• [^]Re: L'émulation...

  Posté par Matho (page perso, ) le 20/09/2002 à 14:10. (lien). Évalué à 12.

  Et toutes façons avec mes 3 Go de ROM sous Mame, j'ai meme pas fini le premier de mes centaines de jeux.
  
  Alors jouer sous linux...
  
  Plus sérieusement, on n'a jamais fait mieux qu'une console pour jouer et si vous avez le (pas de) bol d'etre marié avec une fanatique de jeux video comme ma femme, vous n'aurez vite plus de place autour de la tv pour toutes les consoles (N64,DC,PS1,PS2,Game cube) et des dizaines de jeux originaux achetés en occase donc pas cher.
  
  Allez, hop, un coup de wine et un solitaire.

  • [^]Re: L'émulation...

    Posté par Thomas RIBO (page perso, ) le 22/09/2002 à 10:30. (lien). Évalué à 2.

    Tu me prête ta femme pour une dizaine d'années ? ;-)

de toute facon...

Tribes II / Neverwinternights / crossfire

• [^]Re: Tribes II / Neverwinternights / crossfire

  Posté par pirme () le 21/09/2002 à 02:14. (lien). Évalué à 4.

  Il est interressant de noter que la version linux de tribes2 fonctionne mieux que la version win32, si l'on excepte quelques problemes liés au gestionnaire de sons. C'est un jeu où la fluidité d'affichage est capitale, et sur la même configuration matérielle, le gain en fps est de l'ordre de 25 à 80% suivant les scenes.
  Sierra et Loki avaient fait un effort énorme pour sortir une version linux de qualité, mais malheureusement ils ont fait quelques erreures majeures: premierement en complexifiant inutilement l'aspect graphique (splash, boum, wizz), puis en essayant d'en faire un jeu "trop" massivement multiplayer, et finalement en sacrifiant le "fast pace" et les sensations qui avaient fait le succes de tribes1 et quake1.
  Ce qui fait qu'au final, quand le jeu est sorti, la majorité des ordinateurs n'étaient pas vraiement capables de faire tourner le jeu de façon confortable ... ce qui n'est plus le cas un an plus tard.
  Il semblerait cependant que des mods recents s'attelent à résoudre ces problemes de jeunesse.

ClanBomber

packages "incomplets", c'est un problème aussi ! :-(

• [^]Re: packages "incomplets", c'est un problème aussi ! :-(

  Posté par Banux (page perso, ) le 20/09/2002 à 14:19. (lien). Évalué à 7.

  si tu regarde du cote des jeux commerciaux de feux loki, tu avait un installer graphique:
  tu mettait ton cd, lancait install.sh
  ca installer dans le repertoire de ton choix
  ca faisait des liens et des icones dans kde/gnome si tu le demandais, tu n'avait plus qu'a cliquer
  
  en gros pas plus dur qu'un installer sous windows
  par contre au niveau des dependances pour les jeux gpl c'est le meme problemes que pour beaucoup de programmes qui en demande

• [^]Re: packages "incomplets", c'est un problème aussi ! :-(

  Posté par Adrien BEAUCREUX () le 20/09/2002 à 14:47. (lien). Évalué à 7.

  Ton CD, que tu achetes, c'est tout betement que le vendeur a tout mis sur une seule galette, tous les "paquetages".Souvent, tu te retrouves, sous win, aec des boites de dialogue du style "Vous n'avez pas DirectX 25.3b4, voulez-vous l'installer ?" et tu cliques OK. Il y a simplement une "verification des dependances" et tout à portée de main.
  
  Maintenant, les jeux GPL tu les telecharges, mais personne ne s'amuse à te faire une belle image iso avec toutes les dependances, une belle boite, etc.
  D'autant que le plus souvent, il y a une page qui te dit: "Tu vas avoir besoin de SDL, que tu peux trouver sur..." avec un lien. RTFM.
  
  Comme tu l'a toi même indiqué, c'est très lourd de gerer les dependances a la main (surtout avec les dependances des dependances, etc.), c'est pour ca qu'il existe des systemes comme les .rpm ou .deb avec gestion de dependances. Mais c'est prevu pour des machines avec connection. La seule solution, c'est de bien faire gaffe aux dependances.
  
  Et un fichier unique, la seule solution que je voie, c'est de telecharger des binaires compiles statiquement (=> pas de dependances).
  
  Au final, deux sites :
  http://www.ufoot.org/(...) avec l'excellent Liquid War
  http://www.artsoft.org/mirrormagic/(...) : deflektor, pour les amateurs.

  • [^]Re: packages "incomplets", c'est un problème aussi ! :-(

    Posté par ufoot (page perso, ) le 20/09/2002 à 15:01. (lien). Évalué à 6.

    > Et un fichier unique, la seule solution que je voie, c'est de telecharger des binaires compiles statiquement
    Effectivement, le binaire statique ca resoud assez efficacement les problemes d'installation et/ou de dependances. En plus c'est pas mal adapte pour un jeux ou tres souvent tu as *un* binaire et puis plein de fichiers de donnees a cote, mais grosso-modo on evite le syndrome "mon tarball contient 8 copies de la glibc".
    
    Cela dit c'est une bonne solution pour les jeux libres, mais pour les jeux proprietaires, linker tout statiquement c'est pas toujours tres evident d'un point de vue legal 8-) Cet etat de fait ne me choque pas vraiment, il est AMHA logique qu'un binaire proprietaire utilise des liens dynamiques, mais ca ne simplifie pas les choses pour l'utilisateur final.
    
    > avec l'excellent Liquid War
    8-)

• [^]Re: packages "incomplets", c'est un problème aussi ! :-(

  Posté par Pablo Saratxaga (page perso, ) le 21/09/2002 à 11:39. (lien). Évalué à 6.

  Sur une Mandrake il ne faut pas installer un rpm par "rpm -U machin.mp3" mais par "urpmi machin.mp3"
  comme cela, les dependendeces seront explorées et les paquetages supplementaires necessaires seront automatiquemment telechargés ou bien il te demandera d'inserer tel ou tel CD pour les installer.
  
  (Cela pour les biblothèques et paquetages venant avec la distrib standard, il se peut que certains jeux aient des besoins specifiques, mais c'est rare, et ça ne te ferait qu'une petite poignée de paquetages specifiques à recuperer, le gros du travail de resolution des dependences serait fait).
  
  Avec rpm seul, il ne fait que verifier les dependences et te dire toutes celles non verifiées; il ne fait rien d'autre, tu dois à la main installer ce qu'il faut.
  urpmi c'est un niveau au dessus, puisqu'il esseyera d'installer les paquetages necessaires pour resoudre les dependences.
  C'est l'équivalent de apt-get sur Debian.
  
  Beaucoup des "problème de dependences" rencontrés par les utilisateurs de Mandrake sont en fait dûs non pas à de réels problèmes de depndences, mais au fait qu'ils utilisent le mauvais outil; au lieu d'utiliser rpmdrake (en mode graphique) ou urpmi (en ligne de commande) ils utilisent rpm brut.
  C'est un peu comme si, sous Debian, quelqu'un installait les *.deb avec "gunzip" et "ar" plutôt qu'avec les outils adequats; puis venait se plaindre qu'il a des problèmes à la pelle.
  
  Donc, à moins de connaître la page de man de rpm par coeur, il ne faut pas utiliser rpm; mais bien urpmi (ou rpmdrake), sur une distribution Mandrake.

  • [^]Re: packages "incomplets", c'est un problème aussi ! :-(

    Posté par Benoît Sibaud (Jabber id, page perso, ) le 21/09/2002 à 16:07. (lien). Évalué à 6.

    > Sur une Mandrake il ne faut pas installer un rpm par "rpm -U machin.mp3" mais par "urpmi machin.mp3" rpm est plus à l'aise avec les .rpm qu'avec les .mp3 a priori, mais le lapsus est intéressant (<subliminal>ogg vorbis c'est plus libre que mp3</subliminal>) :)

  • [+] [^]Re: packages "incomplets", c'est un problème aussi ! :-(

    Posté par vieuxshell () le 22/09/2002 à 16:50. (lien). Évalué à -1.

    je pense plutot que l'équivalence serrait : rpm <-> dpkg urpmi <-> apt-get car dpkg seul ne vas pas te telecharger les dependances.

Nekeme prod.

Ularn et Moria

• [^]Re: Ularn et Moria

  Posté par Gniarf () le 25/11/2003 à 17:38. (lien). Évalué à 1.

  http://gniarf.nerim.net/vaboofer/Ularn.gif(...) et http://gniarf.nerim.net/vaboofer/Angband.gif(...) maintenant.
  
  voir surtout :
  
  http://test.vaboofer.com/index.php/Angband(...)
  
  et
  
  http://test.vaboofer.com/index.php/Ularn(...)

  --
  The greatest trick the Google Devil ever pulled was convincing the world he did no evil.

un site...

• [^]Re: un site...

  Posté par phneutre () le 21/09/2002 à 10:29. (lien). Évalué à 4.

  et tant qu'on y est, un lien vers la Linux Gamer's FAQ, ca répondra surement à quelques questions :
  http://icculus.org/lgfaq/(...)
  
  et une liste des jeux commerciaux et opensource sous linux :
  http://icculus.org/lgfaq/gamelist.php(...)

Ca me redonne envie.

Tokyo Game Show

Un projet que jai en tete