J'aimerais donc connaitre votre avis sur les derniers jeux que vous avez installés, testés, les projets à suivre/encourager, ainsi que l'avenir, la forme des jeux sous Linux.
Je mets quelques petits jeux en liens bien sympathiques.
Aller plus loin
- Mures - un clone de Chu Chu Rocket (multi-joueurs) (24 clics)
- Foobillard - le jeu de billard OpenGl (18 clics)
- Frozen-bubble (19 clics)
- Lbreakout2 - l'incontournable casse brique (22 clics)
- Happypenguin - l'annuaire des jeux sous Linux (60 clics)
# 1st post
Posté par kalahann . Évalué à 10.
Sinon, il existe de nombreux jeux libres sous linux, mais le gros problème c'est pas le manque de programmeurs, c'est le manque de graphistes, musiciens, scénaristes... à cause de ça, les jeux linux aussi bien faits soient-ils, n'auront jamais la profondeur des jeux commerciaux.
[^] # Re: 1st post
Posté par champi . Évalué à 10.
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 (site web personnel) . Évalué à 3.
[^] # Re: 1st post
Posté par Stephane Marchesin (site web personnel) . Évalué à 10.
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 . Évalué à 10.
[^] # Re: 1st post
Posté par Ontologia . Évalué à 7.
[^] # Re: 1st post
Posté par Stephane Marchesin (site web personnel) . Évalué à 6.
[^] # Re: 1st post
Posté par Stéphane V. . Évalué à 10.
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 Anonyme . Évalué à 7.
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 dinomasque . Évalué à -5.
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 20 ans !
# Développement sous Linux: les jeux
Posté par _seb_ . Évalué à 10.
C'est trés curieux d'ailleur parce qu'il existe des tas et des tas de moteurs de jeu (3D, 2D, RPG) sous linux. Pour en citer 2:
Basé sur SDL, moteur de sprites excellent
http://www.grinninglizard.com/kyra/(...)
Moteur 3D avec pour une fois une bonne documentation
http://ogre.sourceforge.net/(...)
Et il y en a beaucoup d'autre dans quaziment tous les langages. Le problème des jeux n'est pas technique, mais plutôt graphique. Même si un jeu est bien fait techniquement (programmation aux p'tits oignons), il n'est pas sûr de plaire si le graphisme est merdique.
Je crois que c'est l'une des raisons au fait qu'il n'y est pas beaucoup de jeux sous Linux. On manque de graphistes.
[^] # Re: Développement sous Linux: les jeux
Posté par Eric Boulat . Évalué à 10.
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 . Évalué à 10.
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_ . Évalué à 10.
<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 . Évalué à 10.
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 . Évalué à 5.
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 . Évalué à 10.
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 . Évalué à -4.
(-1 parceque j'aurais du me renseigner avant de poster)
[^] # Re: Développement sous Linux: les jeux
Posté par ufoot (site web personnel) . Évalué à 10.
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 . Évalué à 10.
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 (site web personnel) . Évalué à 10.
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 . Évalué à 10.
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 . Évalué à 10.
[^] # Re: Anecdote personnelle
Posté par Philippe F (site web personnel) . Évalué à 3.
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.
[^] # Re: Anecdote personnelle
Posté par Thomas RIBO . Évalué à 8.
[^] # Re: Anecdote personnelle
Posté par aem_ . Évalué à -1.
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
Posté par Tab Tab . Évalué à 10.
l'exemple de la demo de UT2003 qui est sortie en meme temps sous windows et sous linux, c'est a mon sens un grand pas en avant.
il faut maintenant que ca se generalise.
[^] # Re: En hausse
Posté par jojolapin . Évalué à 7.
[^] # oui mais ...
Posté par snurpsss . Évalué à -7.
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 (site web personnel) . Évalué à 4.
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?
[^] # Re: oui mais ...
Posté par Stephane Marchesin (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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
Posté par matiasf . Évalué à 3.
Hors j'aimes pas me prendre la tête avec une installation compliquée, etc. pour un jeux.
Ma solution :
J'ai acheté une PS2 que je banche sur la carte TV de mon PC qui tourne sous Linux. C'est finalement pas cher car j'économise sur le lecteur dvd.
Bref, je ne suis pas les développements des jeux des sous Linux. Par contre, je suis le développement de Linux sur les console de jeux. Car quand je joue pas ou regarde un dvd, ma console elle fout rien (je sais, y a un kit Linux PS2 mais c'est cher et pas très standard (disque dur, etc...)).
# parsec & reaper & PlanetShift
Posté par franck villaume (site web personnel) . Évalué à 10.
parsec (pas gpl) : http://www.parsec.org(...)
un simulateur de combat spacial en 3d. Avec une musique de fond sublime.
reaper (gpl) : http://reaper3d.sourceforge.net(...)
un autre simulateur de combat spacial aussi en 3d.
planetshift (en parti gpl) : http://www.planeshift.it(...)
un RPG.
voila pour mes bonnes adresses.
--
C01N C01N !!!
[^] # Re: parsec & reaper & PlanetShift
Posté par Philippe F (site web personnel) . Évalué à 1.
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!
[^] # On continue avec les bonnes adresses
Posté par Guillaume Rousse (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 3.
[^] # Re: parsec & reaper & PlanetShift
Posté par Sylvain Rampacek (site web personnel) . Évalué à 4.
[^] # Re: parsec & reaper & PlanetShift
Posté par Richard Hébert (site web personnel) . Évalué à 4.
# L'émulation...
Posté par David Olivari . Évalué à 10.
D'autres part, ce qui fait souvent défaut avec les jeux sous linux, c'est leur aspect très austère.
On trouve plus de développeur C prèt à passer des nuits à programmer pour le fun que de graphistes/designer suspectibles de céder les droits sur leur création. Or un jeu attractif et populaire, on le doit pour 50% à son design et 30% aux tests, les 20 % de programmation allant de soi.
Le résultat est que nous avons de superbes librairies et outils pour faire des jeux mais pas de contenus :-(
Pour ma part, j'utilise l'émulateur ePsxe qui permet d'avoir accès à une ludothèque immense de jeux variés et de très bonne qualités.
[^] # Re: L'émulation...
Posté par Matho (site web personnel) . Évalué à 10.
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 . Évalué à 2.
# de toute facon...
Posté par Marc (site web personnel) . Évalué à 4.
# Tribes II / Neverwinternights / crossfire
Posté par Brunus . Évalué à 10.
FPS en intérieur/extérieur, jusqu'à plus de 80 joueur sur un serveur (c'est rare...un 32/32 déjà c'est beau !), dans un univers futuriste.
Le gameplay se rapproche d'un FPS comme Counter Strike en mode "get the flag", tout en étant bien moins bourrin et bien plus attrayant puisqu'on peut utiliser des véhicules (terrestres et avians), poser et gérer de l'artillerie de défense, que l'on doit gérer l'état de la base de l'équipe etc...
L'action d'équipe est primordiale. Les équipiers peuvent avoir des rôles très divers entre attaque, renseignement, sabotage, défense, pilotage, sniping et même commandement puisqu'il existe un module de commandement très complet pour les leaders et les équipiers (avec carte, points de navigations, activité radar etc...)
Lorsque vous partez à l'assaut d'une base, en armure lourde, sur un transporteur de troupe, que vous voyez vos équipiers à coté de vous, et que chacun se motive par de bon gros cris de guerre...c'est le frisson assurré lorsque vous arrivez sur la base et que les lance roquette commence à cracher !
Bon...j'ai jamais compris que les linuxiens ne supportent pas ce jeu et continuent à jouer à Counter Strike...qui n'est pas un jeu natif pour Linux...il y à ue un serveur counter strike sur linuxFR pendant un temps...mais jamais de serveur Tribes II.
Tribes II c'était un portage Lokigames...ça les aurait aidé chez Lokigames qu'on supporte ce jeu génial...
http://www.lokigames.com/products/tribes2/(...)
Il doit rester des boites chez certains revendeurs comme http://www.mcd2-diff.fr/(...)
Les patchs et upgrades sont réalisés par un ex Lokigames qui bosse maintenant chez Blizzard (tient tient!), et sont downloadables sur ftp.lokigames.com
- Neverwinter nights :
Une page de download est apparue sur le site Bioware fin Juillet...on l'avait annoncé sur http://www.ggu-squad.org(...)
Au dernières nouvelles...ça avance bien
http://nwn.bioware.com/downloads/linuxclient.html(...)
- Crossfire
C'est un RPG qui intègres des règles à la Donjons et Dragons.
Bin il est pas beau mais le l'aime bien avec son graphisme style bon vieu jeu des années 80
http://crossfire.real-time.com/(...)
Merci de pas me déscorer à cause des fautes d'orthographe...j'essaye de faire des efforts, mais là j'ai pas le temps de me relire.
good games all ;-)
[^] # Re: Tribes II / Neverwinternights / crossfire
Posté par pirme . Évalué à 4.
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
Posté par Nicolas P . Évalué à 6.
# packages "incomplets", c'est un problème aussi ! :-(
Posté par Space_e_man (site web personnel) . Évalué à 4.
(Je commence reconversion de MSFT/Windows vers GNU/Linux.)
Jusqu'à il y a quelques jours, j'avais Mandrake8.2(3CD) d'installé en plus de w2k et le seul truc que j'étais capable de faire étais jouer justement. Et il m'arrivait régulièrement de redémarrer sous linux pour jouer.
Un jour, j'ai cherché à ajouter des jeux à mon linux et depuis mon boulot, j'ai téléchargé quelques rpm estampillés Mandrake8.2. Le problème est qu'une fois de retour chez moi et lancé l'installation de l'un ou l'autre rpm, un message m'apprenait systématiquement (sauf pour 1 ou 2 jeux "nuls" sur la dizaine de rpm téléchargé) qu'il était dépendant de quelques package que je n'avait pas. J'ai laissé tomber. Ben ouai, imaginez, j'aurrais du prendre note des différents packages à télécharger depuis mon boulot etc. : pas l'temps "bordel"(s'cusez moi) !!!
Bon, alors voila, je suis p'être un neuneu ou tout c'qu'on veut mais bon ... quand j'revien de la Fnac avec un jeux pou win, j'ai tout c'qui faut pour jouer et j'doit pas me connecter à internet ou retourner à la Fnac pour installer tel ou tel truc.
Depuis une semaine, j'ai "plus rien". J'ai voulu installer Debian3.0(woody7CD) et il s'avère que j'suis trop neuneu justement 8d.. Alors je vai réinstaller Mandrake8.2 en attendant d'avoir passer "mon doctorat Debian" ;)
Mais là, l'urgence, c'est pour ce soir. J'ai "poussé" un de mes amis à acheter sa licence pour le WinXP qu'il me demande d'installer chez lui. Ce qui à pour effet de lui enseigner le coût réel des produits MSFT... J'ai ainsi pu introduire l'idée d'installer également GNU/Linux pour lui montrer ce qu'il en étais aujourd'hui. Et voila, j'aimerais bien pouvoir lui installer quelques jeux et programmes récents... Mais vu mon expérience, je ne sais pas quoi télécharger etc.
Existe-t-il sur Internet des fichiers uniques à télécharger qui peuvent permettre d'installer des jeux sur une Mandrake8.2 fraîchement installée et non connecté à internet ?
Merci d'avance... :-)
[^] # Re: packages "incomplets", c'est un problème aussi ! :-(
Posté par Banux (site web personnel) . Évalué à 7.
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 . Évalué à 7.
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 (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 6.
[^] # Re: packages "incomplets", c'est un problème aussi ! :-(
Posté par vieuxshell (site web personnel) . Évalué à -1.
# Nekeme prod.
Posté par Nicolas Merigot . Évalué à 10.
Akhart, le seul jeu qui utilise Ark pour l'instant, prend place dans un univers totalement orignal. En effet, le jeu cherche à éviter les lieux communs des JDR inspirés de Tolkien, pas d'orc, pas de magie, ni de conflit entre elfe et nain, mais un mélange subtil entre Heroic Fantasy et Space Opera (oh ! c'est beau, ca sonne comme une press release ;). Tout ceci décris sur une cinquantaine de page, elles aussi libres également.
Le site d'arkhart : http://arkhart.nekeme.net(...)
Nekeme, l'association qui développe Ark et Arkhart, a pour but de créer une communauté de développeurs de jeu libre. Le partage des ressources des jeux (graphismes, code, sons, specs, etc..) étant à la base de celle-ci. Nekeme regroupe déja 3 jeux : Arkhart, bien sur, Expatri et Gobelins. Bien sur, Nekeme est ouvert à tout nouveaux jeux, et recherche constament de nouveaux développeurs pour les jeux déja existant.
Le site de nekeme : http://www.nekeme.net(...)
# Ularn et Moria
Posté par Gniarf . Évalué à 1.
des vieux jeux mais qui me plaisent toujours autant après 10 ans...
http://62.212.109.174/Ularn.gif(...) http://62.212.109.174/Angband.gif(...)
[^] # Re: Ularn et Moria
Posté par Gniarf . Évalué à 1.
voir surtout :
http://test.vaboofer.com/index.php/Angband(...)
et
http://test.vaboofer.com/index.php/Ularn(...)
# un site...
Posté par longhairedguru . Évalué à 4.
[^] # Re: un site...
Posté par phneutre . Évalué à 4.
http://icculus.org/lgfaq/(...)
et une liste des jeux commerciaux et opensource sous linux :
http://icculus.org/lgfaq/gamelist.php(...)
# Ca me redonne envie.
Posté par Serge2 . Évalué à 5.
# Tokyo Game Show
Posté par Erwan . Évalué à 4.
Ben Linux rien, nada, zero cacahuetes. Probablement parce que les japonais aiment en particulier les jeux de roles genre Final Fantasy ou les simulations de vie quotidienne (j'ai meme vu un simulateur "gere ton epicierie") et ca sous Linux y'a pas.
C'est bien dommage... L'année prochaine peut-être !
# Un projet que jai en tete
Posté par Pierre Bonneau . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.