> > Le code n'est pas une forme d'expression, à la base c'est de l'ingenierie.
Tout à fait d'accord.
> que fais-tu du démomaking?
En général, le code des démos n'a aucun intérêt sauf d'un point de vue technique, le but est d'obtenir le maximum de performance quel qu'en soit le prix, pas d'écrire du joli code. Ni du code qui suscite des émotions en le lisant d'ailleurs (ou de frayeur peut-être :). Et puis souvent c'est écrit en assembleur (enfin, ça l'était à une époque) et c'est donc beaucoup plus proche de la machine que de l'humain.
> de la Perl Poetry? de l'Obfuscated C Contest? j'en oublie très
> certainement, mais ce sont-là des formes de programmation qui
> n'ont rien à voir avec l'ingéniérie, car, que je sâche elles ne
> construisent rien à proprement parler!
Peut-être aussi que ces codes n'ont aucun intérêt en tant que code, mais seulement en tant qu'"oeuvre". Et dans ce cas, ce n'est pas vraiment du code étant donné que ça ne sert à rien, sauf à être "beau". Je pense que ton but est plutôt d'expliquer en quoi le code "courant" est une forme d'expression, pas d'expliquer qu'il peut l'être dans certains cas très spécifiques, sinon ça ne sert pas à grand chose. Et je vois difficilement comment tu pourrais justifier ça.
> j'aimerais prouver qu'il est facile, sinon nécessaire, de le faire pour
> le code informatique, afin de préserver la créativité de ceux qui le
> conçoivent et l'utilisent comme tel, et de ne pas favoriser les interêts
> commerciaux qui souhaiteraient le voir "marchandisé" comme tout le
> reste...
Le code peut être "marchandisé" quand il fait partie d'un processus industriel, je ne vois pas le problème. Si c'est au niveau des brevets logiciels que tu t'inquiètes, je pense qu'il vaut mieux rechercher des parallèles entre langage informatique et langage mathématique. Ou entre algorithme et théorème. Il y en aura sans doute plus qu'avec le langage tout court.
En gros tu places le code au même niveau que les données ? Moi je considère qu'un jeu est un logiciel, si le code source du jeu est libre, alors il est libre, que les données soient sous licence libre ou pas. Et je disais que dans la définition de logiciel libre donnée par la fsf, il n'est pas fait mention des données ni de leur licence. Si tu trouves des infos à ce sujet, je suis preneur.
Tu parles de Crystal Space, c'est un moteur de jeu 3D qui ne peut pas fonctionner sans données, tout comme un jeu. Selon ta définition, c'est un moteur libre ou pas ? Oui s'il est fourni avec des données libres, non s'il n'est pas fourni avec des données libres ? Et s'il est fourni sans données ? Ce raisonnement est d'ailleurs valable pour tout type d'application qui a besoin de données externes pour fonctionner.
La différence entre nos deux points de vue c'est que tu considères un jeu comme un ensemble code source+données. Moi je considère qu'un jeu est un logiciel. Si son code source est libre, alors il est libre. Si tu me montres un lien vers une définition de ce qu'est un jeu libre, je suis preneur.
> Si j'ai la moitié d'un programme qui est non-libre, il ne l'est pas globalement.
Si le code source est libre, le programme est libre, c'est la définition d'un logiciel libre. Si une partie du code source n'est pas libre, le logiciel n'est pas libre. Je ne vois pas de problème.
> Si le fichier de données n'est pas libre, alors on n'a pas accès aux libertés
Si, on a la liberté d'utiliser le programme avec d'autres données. Et on a toutes les libertés que donne la licence du code source.
> Si le jeu est libre, ça veut dire que ses données sont libres, par définition.
Tu peux me donner un lien sur cette définition ?
> Si tu es en train de dire qu'il suffit que le code soit libre pour en
> faire un logiciel libre, sous prétexte qu'on peut créer des données
> soi-même, ça n'a aucun sens : on pourrait tenir le même argument
> avec du code pour prétendre que du code propriétaire est fermé
> (ben oui, tu n'as qu'à recoder ce qui n'est pas libre !)
Non, justement parce que je fais une différence entre code et données. Et s'il te plait, évite les petites phrases péremptoires du genre "ça n'a aucun sens", ça n'ajoute rien à l'argumentation au niveau du fond et ça n'a pour but que de décrédibiliser un contradicteur en utilisant la forme. Bref, c'est de la réthorique.
> Tous les jeux qui utilisent des données non-libres ne sont pas des logiciels libres.
Relis la définition de logiciel libre donnée par la fsf, il n'est fait nulle part mention de la licence des données des logiciels. Ca ne concerne que le code source.
> Et puis les données n'ont pas besoin de licences différentes du code
Alors pourquoi des types de licence supplémentaires ont-ils été créés pour les données ?
> Tout comme un projet utilisant 90% de LGPL et 10% de propriétaire
> possédera beaucoup de code libre, mais ne sera pas libre pour
> autant.
C'est évident et je n'ai jamais dit le contraire. Quand tout le code n'est pas libre, le logiciel n'est pas libre.
> Tu parles donc d'un ensemble de logiciels qui ne contient pas que des logiciels libres.
Je me repète, mais un logiciel libre n'envisage que la licence du CODE SOURCE. Voir la définition de la fsf. Les données ne sont pas du logiciel.
> Si tu ne vois rien concernant les données dans les jeux libres, c'est
> parce que tu n'as pas regardé : si la licence du jeu complet est
> libre, alors tout est sous cette licence et le jeu et libre.
Fais une recherche sur happypenguin.org et dis-moi combien de projets spécifient la licence de leurs données. Je te mets au défi d'en trouver une proportion importante. Pour prendre un exemple simple, télécharge les données et les sources de TuxRacer et dis-moi si tu y trouves quoi que ce soit en rapport avec la licence des données.
> Va regarder par exemple le répertoire des jeux présents dans
> Debian. Ceux qui ont du code libre et des données non-libres
> seront séparés entre main/contrib et non-free.
La Debian n'a pas le monopole de la définition de logiciel libre, et d'ailleurs je serais curieux de savoir sur quelle définition ils se basent. C'est le boulot de la fsf de définir ce qu'est un logiciel libre et sur leur site, rien n'indique qu'un logiciel libre concerne autre chose que le code source. D'ailleurs, les données de TuxRacer ne sont pas dans la section non-free alors que la licence des données n'est spécifiée nulle part, ni par Debian, ni sur le site de TuxRacer, ni dans leurs tar.gz.
> Dire que pour utiliser linux, il ne faut pas toucher au shell : c'est faux
> ou il faut être d'une mauvaise foi redoutable.
Je ne suis pas d'accord, tout dépend de l'utilisation qu'on fait de son système. Il n'y a pas besoin de toucher au shell quand on fait de la bureautique, qu'on navigue sur Internet ou qu'on lit/écrit des e-mails, ce qui doit correspondre à l'utilisation la plus courante des gens sous Windows je pense.
> Dire que les packages binaires sous linux, c'est géré à 100% et
> qu'il ne faudra pas à un moment ou un autre se plonger dans les
> sources, dans les fichiers de config, ou même dans le shell c'est
> également faux.
Pas d'accord non plus, pour une utilisation courante.
> Ca me paraissait logique que ces problèmes mineurs soient résolus
> depuis longtemps au moins pour une configuration standard
> automatique ! Quelle déception !
Là je suis d'accord, je trouve que les efforts faits par les différents éditeurs de distributions ne sont pas forcément placés là où ils devraient l'être. D'ailleurs j'aime bien cette idée de "minimum vital", il faudrait qu'elle fasse des émules...
> Pire encore, aucune distribution n'est capable de proposer le
> minimum vital
D'accord aussi, j'ai l'impression qu'une distribution comme Knoppix est en train de se focaliser sur ces objectifs, ils font du bon boulot même s'il y a encore des points noirs. Ce serait bien que tous les éditeurs de distributions s'en inspirent...
Pour la configuration de l'écran, la limite est X Window, les distributions n'y sont pour rien. C'est pas encore ça niveau paramétrage mais ça continue à évoluer dans le bon sens. C'est vrai que j'ai trouvé moyennement drôle de ma taper des calculs de Modelines à la main pour avoir les fréquences optimales et un mode supplémentaire (1152x864) pour mon écran exotique. Mais j'avais eu le même problème sous Windows.
Le problème c'est que c'est quand même plus simple de choisir un programme dans une liste que de taper le nom d'un exécutable en ligne de commande. On ne peut pas demander à un débutant de retenir les noms des exécutables de tous les programmes qu'il veut lancer. Par exemple, ça ne demande aucun effort de mémoire de cliquer sur OpenOffice Writer dans un menu, par contre c'est autre chose quand il faut se souvenir qu'il faut taper swriter en ligne de commande pour faire la même chose. Quand le nombre d'applications à lancer dépasse la dizaine, ça devient tout de suite moins facile, surtout quand les noms des exécutables ont un rapport lointain avec le nom du programme (swriter par exemple).
D'ailleurs, la différence essentielle est que dans ton cas, la petite fille dont tu parles a sans doute été guidée par un adulte, je doute qu'elle soit arrivée à ce niveau d'utilisation du système en lisant de la doc et des how-to. Si chaque nouvel utilisateur de Linux était guidé par quelqu'un qui connait le système, ce serait sans doute plus simple, mais c'est loin d'être immédiat pour quelqu'un qui débute seul, surtout s'il ne sait pas comment demander de l'aide sur Internet. Et s'ils n'ont pas besoin d'aide pour apprendre à utiliser Windows, je trouve légitime qu'ils soient déçus de ne pas pouvoir utiliser Linux sans aide extérieure.
J'ai tendance à préférer la ligne de commande en général, mais c'est parce que je connais le nom des exécutables que j'utilise. On ne peut pas demander à un débutant de faire la même chose, je trouve normal qu'il considère ça comme une régression, c'est la machine qui est censée être à son service, pas l'inverse. Et puis rien ne l'empêchera d'utiliser la ligne de commande quand il sera un peu plus aguerri.
> Il n'existe aucun gros jeu libre puisque les jeux ont une durée de vie
> relativement courte et que les logiciels libres ont un temps d'arrivée
> à maturité globalement long
Je ne sais pas si c'est la principale raison, il existe pas mal de types de jeux propriétaires qui évoluent assez lentement et de manière incrémentale, un peu comme les logiciels libres.
Les jeux de sports sont un bon exemple, je me rappelle avoir joué à FIFA 95 il y a quelques années et on en est maintenant à FIFA 2003. C'est valable aussi pour les jeux de tennis (Rolland Garros 96 à 2003), les jeux de rallye (Colin Mc Rae 1 à 3) ou de skateboard (Tony Hawks 1 à 4).
C'est valable pour toutes sortes de jeux d'ailleurs : Final Fantasy (I à XII), Warcraft (1 à 3) sans compter les add-ons et les "spins-offs" (Starcraft), Grand Theft Auto (1 à 3 + add-ons + vice city), etc.
Le problème est peut-être que les gens qui écrivent des jeux libres ont la même démarche que ceux qui écrivent des jeux propriétaires. Ils écrivent leur jeu pour répondre à un besoin immédiat mais n'envisagent pas le futur. Ce qui fait qu'ils essayent d'en faire quelque chose de très ambitieux dès le départ en pensant que ça pourra se faire rapidement, mais comme ils n'ont pas les mêmes moyens que des professionnels ou que l'envie s'amenuise au fur et à mesure, le jeu n'aboutit jamais.
Mais je dois dire que je suis assez confiant dans l'avenir des jeux libres vu le succès du mode de développement très incrémental des jeux propriétaires.
> Si le son ou les graphismes ne sont pas libres, le jeu n'est pas libre
Je joue peut-être sur les mots, mais pour moi un jeu est un logiciel. Si les sources d'un jeu sont sous une licence libre, c'est un logiciel libre et donc un jeu libre. D'ailleurs je n'ai rien vu à propos de la licence des données dans les définitions du logiciel libre données par la fsf, il me semble que ça ne concerne que les sources.
D'ailleurs, si le jeu est libre, rien n'empêche de créer du contenu pour le faire fonctionner en choisissant n'importe quelle licence pour les données. Je ne suis d'ailleurs pas sûr que tous les jeux libres utilisent des données libres, généralement les auteurs de jeux libres ne parlent pas de la licence des données.
De Kraftwerk à Rammstein
Trente ans de musique populaire outre-Rhin
Non, l'Allemagne ne se limite point à Beethoven et Scorpions ! Chaque nouveau mouvement musical international trouve sa version
teutonne (avec plus ou moins de réussite...). Metal, rock progressif, punk, new wave, krautrock, les Allemands essaient, expérimentent et se lancent dans tous les courants. Et c'est ainsi que ces dernières années, la scène électronique d'outre-Rhin s'avère être l'une des plus intéressantes d'Europe. Voici donc une sélection éclectique d'albums à découvrir pour apprécier la musique germanique de ces trente dernières années.
> le basic MSX est un poil plus rapide que celui de l'amstrad bien
> qu'on puisse s'attendre a des difference de prefs plus importante
Ben c'est le même processeur à la base, donc en performance brute y a pas de raison que ça aille plus vite sauf si l'un des deux interpréteurs est vraiment plus mal écrit. Sauf quand on utilise les spécificités du hard, comme le scrolling hard et les sprites hard sur MSX.
> Et en effet Salamander et autre sont plus beau que sur les autres
> machines mais ce sont des cartouches Konami
Oui mais c'est aussi valable pour d'autres jeux comme Sorcery. De toute façon, d'un point de vue visuel la supériorité était clairement du côté du MSX. 256x192 en 16 couleurs contres 160x200, y a pas photo... Sans compter que le MSX utilisait moins de mémoire vidéo grâce à sa subtile (et parfois très chiante) utilisation d'un seul octet pour coder 8 pixels. Et puis les japonais ont toujours été meilleurs que les occidentaux pour produire des jeux bien léchés. C'est pas étonnant que Konami soit toujours là d'ailleurs...
> apres pour sortir quelque chose de la béte faut le faire en ASM et
> c'est trés chiant plus que sur l'Amstrad.
Ca dépend des outils fournis. Avec Devpac à l'époque, ça changeait pas grand chose le type de plate-forme, surtout quand c'était le même processeur. Et puis intégrer de l'assembleur dans un programme BASIC, c'était pas si compliqué sur MSX. Et puis au moins, on avait un vrai éditeur plein écran, pas un pauvre truc ligne à ligne :) Un peu comme la différence entre vi et ed :)
> donc méme si c'était une machine de merde j'en garde un bon souvenir
Je dis pas que c'était une machine de merde, loin de là. Un peu moins performante niveau technique, mais très bien intégrée (moniteur intégré, lecteur K7 ou disquette intégré, design sympa), très bon marketing en France et support utilisateur très bon. C'était l'une des rares machines pour laquelle on pouvait trouver des revues en kiosques longtemps après sa mort (un peu comme l'Amiga :).
> Tien toi aussi ta le Canon V20, merde il est pas si rare que ca au final
ben non en fait :) Faut dire que la plupart des pubs magazines pour les premiers MSX mettaient en avant le Canon. Les Sony et Phillips n'ont été mis en avant qu'avec la vague des MSX 2.
Oui, enfin ils étaient pas tous seuls non plus. C'était avant tout un standard japonais (Sony, Canon, Yamaha, Casio, etc.) puis européen (Phillips). Et Microsoft a surtout fourgué son BASIC.
> Puis le MSX a par les rares jeux cartouches Konami, il était pas
> aussi fun que l'Amstrad
T'as jamais eu de MSX toi, les jeux étaient largement meilleurs que sur Amstrad (Nemesis, Knightmare, Lode Runner, Hole in one, etc.), surtout dans le cas où ils existaient sur les deux systèmes (Salamander, Sorcery, etc.). D'un point de vue graphique et sonore ça enterrait l'Amstrad, et de loin. Et niveau fun, pareil. Les jeux exploitaient vachement bien la machine et tu n'avais pas ce sentiment de manque de finition qu'on ressentait sur l'Amstrad.
> la programation du MSX était plus galére, certe un peut plus perfomante,
C'est une blague ??? Le basic MSX était un des meilleurs de l'époque, super puissant et simple à utiliser, tu avais tout ce qu'il fallait pour programmer des jeux et le BIOS était très bien documenté. A part les consoles, à l'époque je ne connaissais aucune machine qui supportait les sprites en hard.
> mais surtout l'absence du lecteur de casette en standar du CPC a
> beaucoup jouer en sa defaveur,
Ca c'est clair. Et le fait qu'il n'y ait pas eu de moniteur avec aussi, c'était l'argument de vente de l'Amstrad : libérez la télé...
> surtout que les cartouches Konami en Europe on pouvait se brosser.
Ben y en avait quand même une bonne collection et à l'époque j'ai jamais eu de souci pour en trouver. Il doit m'en rester une dizaine, sans compter tous les jeux rippés sur K7.
> Mais bon la machine de reference pour la prog reste le C64, qui me
> manque encore et toujour dans ma collection.
Tout à fait d'accord. Et puis pareil, ça ferait bien dans mon musée à côté de mon Apple IIc, MSX Canon V20, Amiga 500 et Atari Portfolio... :)
Ah, je croyais qu'un kit de développement Linux/OpenGL était dispo pour la Playstation 2. Et il me semblait aussi que SDL tournait dessus. Sinon, pour la XBOX, c'est DirectX, comme sous Windows, non ? Pour la Gamecube, j'en sais rien par contre...
> Bas si il veulent developper et distribuer sur un autre plateforme de
> jeu que le PC ( genre n'importe qu'elle console ), ils n'ont pas
> vraiment le choix non plus, les boites derriére les consoles ne files
> pas de licence de dev a n'importe qui,
Ca m'étonnerait qu'ils visent le marché des consoles étant donné qu'ils ne financent pas le développement.
> et surtout les devkit et leurs code n'est pas ouvert et ne risque pas de l'étre.
Rien n'empêche les développeurs retenus de choisir des librairies Open Source (sous LGPL par exemple). C'est déjà ce que faisait Loki avec SDL, SMPEG et OpenAL pour ses portages de jeux Windows.
C'est vrai que le niveau des commentaires n'est pas particulièrement brillant. Comme site d'information concernant les jeux sous Linux, il y a The Linux Game Tome qui vole un peu plus haut (c'est pas difficile non plus :)
La news a aussi été relayée par un autre site dédié aux jeux vidéo sous Linux : The Linux Game Tome (http://happypenguin.org/newsitem?id=3459(...) ). D'ailleurs ce site organise le 2 mars prochain une interview sur son canal IRC avec Michael Simms (http://happypenguin.org/newsitem?id=3449(...) ), la personne qui est justement derrière cette initiative (et qui dirige Linux Game Publishing et http://www.tuxgames.com(...)). Ce sera sans doute l'occasion d'avoir plus d'information sur le sujet et sur les jeux en cours de portage chez LGP : Majesty, Disciples 2, Ballistics (un jeu de voiture futuriste) et Bandits.
> Le site LinuxGames.com annonce la mise en place d'un projet de mécénat concernant un jeu.
Juste histoire de préciser, le mécénat en question ne couvre que les frais de production, de marketing et de distribution du produit final, les développeurs ne seront pas rémunérés et ils travailleront chez eux. Ils se partageront 70% des bénéfices si le jeu se vend correctement, mais financièrement, toute la charge du développement sera sur eux :
"Firstly, this is NOT a job. This is a future self-employment opportunity. We will not be paying a salary for this."
"70% of sales revenue will go to the development company, to be divided up as the team sees fit."
> Note: il n'est pas fait mention dans l'annonce de la future licence prévue pour le jeu.
Michael Simms a donné quelques précisions à ce sujet sur le forum de happypenguin.org, et ce sera clairement propriétaire :
"It will be closed source and then it will be up to the developers when they open it - within certain guidelines"
"Im glad to see people liking the way we do things, we're trying to make sure that, sure, we're closed source, but that doesnt mean the community cant get involved!"
Et sinon, je ne vois pas non plus le rapport avec Nekeme...
> > > bagnoles ya torcs et racer, mais l'un est moche et l'autre demande
> > > obligatoirement un joystick :(
> > Lequel des deux tu trouves moche, TORCS ?
> rate, ct l'autre... c'est torcs qui demande le joystick obligatoirement :(
Ca veut dire que tu trouves que Racer est moche ? On doit pas avoir la même définition du terme "moche" alors...
Oups, désolé, je croyais qu'ils avaient corrigé ce problème. Ca fait longtemps que je l'ai pas essayé vu qu'il ne fonctionne pas avec la version de Plib fournie dans la Debian. Cela dit, c'est pas possible d'émuler le clavier avec un driver pour joystick ?
Félicitations au fait, ta 1ère place était vraiment méritée, c'est vraiment un des jeux les plus originaux auxquels j'ai eu l'occasion de jouer. D'ailleurs, j'avais voté pour toi :)
Ca existe depuis belle lurette (1994 - presque dix ans) et c'est sorti sur consoles (Super Nintendo, Playstation, Nintendo 64, etc.) et en arcade. Il y a plusieurs noms, dont Puzzle Bobble (qui est une référence au mythique Bubble Bobble des années 80) et Bust-A-Move.
Il existe une palanquée de versions différentes, Bust-A-Move 1 à 4, puis Super Puzzle Bobble jusqu'à Super Puzzle Bobble 2 qui est sorti l'an dernier sur Playstation 2 et Super Puzzle Bobble All-Stars qui va sortir prochainement sur Gamecube.
Sans dire que Frozen Bubble est "pitoyable" par rapport à Puzzle Bobble, on peut quand même dire qu'il est loin de lui arriver à la cheville. Mais ça reste quand même un très bon jeu et l'effort est très louable. D'autant plus qu'il me semble qu'il a été écrit en peu de temps et que je pense que c'est un des meilleurs clônes toutes plates-formes confondues.
Si tu veux essayer les versions "officielles", je te conseille de récupérer l'émulateur Mame qui les gère très bien (après il faut trouver les ROMS). Tu verras vraiment la différence.
Tout à fait d'accord. D'ailleurs à ce propos je ne pense pas que la mode du "Release early, release often" soit très adaptée à la création de jeux vidéos. Il y a tellement de jeux à peine commencé qui traînent sur le web que ça ne motive ni les joueurs ni les éventuels contributeurs. Et en plus beaucoup se la pètent en promettant monts et merveilles tout ça pour voir le projet mourir de sa belle mort avant même qu'il ne soit arrivé à une version jouable.
Moi j'aurais tendance à penser que quand on développe un jeu, il vaut mieux n'en parler qu'à partir du moment où il est suffisament abouti pour être jouable et prêt à être étendu (niveau code ou contenu). Et si les graphismes de base ne sont pas très attrayant, c'est pas très grave, ce qui compte c'est d'avoir une base solide pour en ajouter.
C'est clair que trouver des graphistes pour un jeu qui démarre et qui n'est pas encore jouable, ça doit pas être facile. Mais quand on regarde le nombre de maps, modèles, mods et conversions disponibles pour différents jeux commerciaux comme Quake, Half-Life, NWN, Les Sims, etc. on se dit vraiment que c'est pas les bons graphistes qui manquent. Et en plus ils font ça gratuitement et sans que personne ne leur demande...
C'est clair que pour les jeux libres, il y a moins de participation, mais c'est à mon avis du essentiellement au faible avancement des différents jeux disponibles. Mais il y a quand même quelques jeux qui reçoivent des contributions extérieures, comme Cube (maps), TuxRacer (courses), Torcs (modèles) ou FlightGear (modèles) et sans doute beaucoup d'autres.
Moi je pense que si un jeu libre est suffisamment jouable et avancé pour être intéressant, trouver des graphistes ne doit vraiment pas être un problème. Ils viendront d'eux-même si le jeu en vaut la chandelle. Par contre, je comprends très bien que des graphistes n'aient pas envie de s'investir dans la création de contenu pour un jeu très peu avancé et non jouable dont ils ne savent pas s'il aboutira ou s'il sera intéressant à jouer.
Par contre, dans un premier temps, ça peut être pas mal d'essayer de profiter des modèles créés pour d'autres jeux. Quand on voit le nombre de modèles hébergés sur Polycount ou Simsresource par exemple, on se dit qu'il doit y avoir de quoi puiser dedans. Après il suffit juste de demander aux auteurs s'ils sont d'accord pour que leur contenu soit intégré.
Cela dit, s'il y avait plus d'outils utilisables pour créer du contenu sous Linux, ça aiderait carrément. Tant qu'il n'y aura pas d'équivalents à des outils comme Milkshape, Gmax, 3DS ou Lighwave, ça risque d'être difficile. Et, non, je ne pense pas que Blender soit un équivalent acceptable. D'ailleurs, à part AC3D et GTKradiant, je ne connais pas beaucoup d'outils qui sont utilisés pour créer des modèles sous Linux.
> En gros, tous le monde peut participer quelque soit sa nationnalité
> s'il est capable de parler l'une des 12 langues européennes
> (français, anglais, espagnol etc.). On ratisse très large, mais cela ne
> me dérange pas plus que cela.
Ca ne me dérange pas non plus, seulement il y a contradiction entre ce que dit le règlement et ce que dit la FAQ sur ce sujet. Il fallait prendre ma boutade à propos de l'auteur de Plib au second degré :) D'ailleurs, l'autre problème de cette clause est que l'Amérique, l'Europe et l'Australie sont plutôt favorisés par rapport à l'Afrique et à l'Asie, comme d'hab. Il suffit de regarder une carte des langues par pays...
> Ce qui veut dire que les employés de société de jeux vidéo
> (même sous linux) ne peuvent participer.
C'est clair, mais là aussi il y a un problème de cohérence. C'est eux qui ont choisi de restreindre la participation à ceux qui ne travaillent pas dans le domaine, mais le domaine est plus vaste que ce qu'ils pensent. Après, savoir s'il faut effectivement restreindre l'accès au concours en fonction de la profession, c'est autre chose.
> Vu les lots, il y a peu de risque que cela interresse ce genre de société.
Si des employés de sociétés de jeux avaient eu l'intention de participer au concours, ça n'aurait sans doute pas été pour l'argent. En général, on fait ce métier parce qu'on adore ça, pas parce qu'on veut gagner des sous. Et puis, pour l'esprit de compétition aussi...
> C'est une "première" pour le ministère de la recherche et des
> nouvelles technologies, ne soyons pas trop méchant.
Mon but n'est pas d'être "maichant" mais de montrer que certains points prêtent à confusion. Je trouve l'initiative géniale, il n'y a aucun problème là-dessus.
> Au contraire, contribuons d'une manière ou d'une autre à
> developper cette initiative.
Je vais aussi essayer d'y contribuer en écrivant un programme, mais je pense que leur montrer certaines incohérences dans le règlement est aussi une façon d'y participer. Moi ce que je veux, c'est que ça se passe bien.
Je vais leur écrire en leur faisant part de mes remarques, on verra bien ce qu'ils en pensent. C'est pas que ce soit très important, mais j'aime bien quand les choses sont claires. Je suis peut-être un peu trop psycho-rigide :)
[^] # Re: Critères de personnalité d'un code
Posté par Frédéric Lopez . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 2.
Tout à fait d'accord.
> que fais-tu du démomaking?
En général, le code des démos n'a aucun intérêt sauf d'un point de vue technique, le but est d'obtenir le maximum de performance quel qu'en soit le prix, pas d'écrire du joli code. Ni du code qui suscite des émotions en le lisant d'ailleurs (ou de frayeur peut-être :). Et puis souvent c'est écrit en assembleur (enfin, ça l'était à une époque) et c'est donc beaucoup plus proche de la machine que de l'humain.
> de la Perl Poetry? de l'Obfuscated C Contest? j'en oublie très
> certainement, mais ce sont-là des formes de programmation qui
> n'ont rien à voir avec l'ingéniérie, car, que je sâche elles ne
> construisent rien à proprement parler!
Peut-être aussi que ces codes n'ont aucun intérêt en tant que code, mais seulement en tant qu'"oeuvre". Et dans ce cas, ce n'est pas vraiment du code étant donné que ça ne sert à rien, sauf à être "beau". Je pense que ton but est plutôt d'expliquer en quoi le code "courant" est une forme d'expression, pas d'expliquer qu'il peut l'être dans certains cas très spécifiques, sinon ça ne sert pas à grand chose. Et je vois difficilement comment tu pourrais justifier ça.
> j'aimerais prouver qu'il est facile, sinon nécessaire, de le faire pour
> le code informatique, afin de préserver la créativité de ceux qui le
> conçoivent et l'utilisent comme tel, et de ne pas favoriser les interêts
> commerciaux qui souhaiteraient le voir "marchandisé" comme tout le
> reste...
Le code peut être "marchandisé" quand il fait partie d'un processus industriel, je ne vois pas le problème. Si c'est au niveau des brevets logiciels que tu t'inquiètes, je pense qu'il vaut mieux rechercher des parallèles entre langage informatique et langage mathématique. Ou entre algorithme et théorème. Il y en aura sans doute plus qu'avec le langage tout court.
[^] # Re: une position unique ?
Posté par Frédéric Lopez . En réponse à la dépêche Interview de Michael Simms sur Happy Penguin. Évalué à 1.
Tu parles de Crystal Space, c'est un moteur de jeu 3D qui ne peut pas fonctionner sans données, tout comme un jeu. Selon ta définition, c'est un moteur libre ou pas ? Oui s'il est fourni avec des données libres, non s'il n'est pas fourni avec des données libres ? Et s'il est fourni sans données ? Ce raisonnement est d'ailleurs valable pour tout type d'application qui a besoin de données externes pour fonctionner.
La différence entre nos deux points de vue c'est que tu considères un jeu comme un ensemble code source+données. Moi je considère qu'un jeu est un logiciel. Si son code source est libre, alors il est libre. Si tu me montres un lien vers une définition de ce qu'est un jeu libre, je suis preneur.
> Si j'ai la moitié d'un programme qui est non-libre, il ne l'est pas globalement.
Si le code source est libre, le programme est libre, c'est la définition d'un logiciel libre. Si une partie du code source n'est pas libre, le logiciel n'est pas libre. Je ne vois pas de problème.
> Si le fichier de données n'est pas libre, alors on n'a pas accès aux libertés
Si, on a la liberté d'utiliser le programme avec d'autres données. Et on a toutes les libertés que donne la licence du code source.
> Si le jeu est libre, ça veut dire que ses données sont libres, par définition.
Tu peux me donner un lien sur cette définition ?
> Si tu es en train de dire qu'il suffit que le code soit libre pour en
> faire un logiciel libre, sous prétexte qu'on peut créer des données
> soi-même, ça n'a aucun sens : on pourrait tenir le même argument
> avec du code pour prétendre que du code propriétaire est fermé
> (ben oui, tu n'as qu'à recoder ce qui n'est pas libre !)
Non, justement parce que je fais une différence entre code et données. Et s'il te plait, évite les petites phrases péremptoires du genre "ça n'a aucun sens", ça n'ajoute rien à l'argumentation au niveau du fond et ça n'a pour but que de décrédibiliser un contradicteur en utilisant la forme. Bref, c'est de la réthorique.
> Tous les jeux qui utilisent des données non-libres ne sont pas des logiciels libres.
Relis la définition de logiciel libre donnée par la fsf, il n'est fait nulle part mention de la licence des données des logiciels. Ca ne concerne que le code source.
> Et puis les données n'ont pas besoin de licences différentes du code
Alors pourquoi des types de licence supplémentaires ont-ils été créés pour les données ?
> Tout comme un projet utilisant 90% de LGPL et 10% de propriétaire
> possédera beaucoup de code libre, mais ne sera pas libre pour
> autant.
C'est évident et je n'ai jamais dit le contraire. Quand tout le code n'est pas libre, le logiciel n'est pas libre.
> Tu parles donc d'un ensemble de logiciels qui ne contient pas que des logiciels libres.
Je me repète, mais un logiciel libre n'envisage que la licence du CODE SOURCE. Voir la définition de la fsf. Les données ne sont pas du logiciel.
> Si tu ne vois rien concernant les données dans les jeux libres, c'est
> parce que tu n'as pas regardé : si la licence du jeu complet est
> libre, alors tout est sous cette licence et le jeu et libre.
Fais une recherche sur happypenguin.org et dis-moi combien de projets spécifient la licence de leurs données. Je te mets au défi d'en trouver une proportion importante. Pour prendre un exemple simple, télécharge les données et les sources de TuxRacer et dis-moi si tu y trouves quoi que ce soit en rapport avec la licence des données.
> Va regarder par exemple le répertoire des jeux présents dans
> Debian. Ceux qui ont du code libre et des données non-libres
> seront séparés entre main/contrib et non-free.
La Debian n'a pas le monopole de la définition de logiciel libre, et d'ailleurs je serais curieux de savoir sur quelle définition ils se basent. C'est le boulot de la fsf de définir ce qu'est un logiciel libre et sur leur site, rien n'indique qu'un logiciel libre concerne autre chose que le code source. D'ailleurs, les données de TuxRacer ne sont pas dans la section non-free alors que la licence des données n'est spécifiée nulle part, ni par Debian, ni sur le site de TuxRacer, ni dans leurs tar.gz.
[^] # Re: Un article et un livre sur Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un article et un livre sur Linux. Évalué à 7.
> ou il faut être d'une mauvaise foi redoutable.
Je ne suis pas d'accord, tout dépend de l'utilisation qu'on fait de son système. Il n'y a pas besoin de toucher au shell quand on fait de la bureautique, qu'on navigue sur Internet ou qu'on lit/écrit des e-mails, ce qui doit correspondre à l'utilisation la plus courante des gens sous Windows je pense.
> Dire que les packages binaires sous linux, c'est géré à 100% et
> qu'il ne faudra pas à un moment ou un autre se plonger dans les
> sources, dans les fichiers de config, ou même dans le shell c'est
> également faux.
Pas d'accord non plus, pour une utilisation courante.
> Ca me paraissait logique que ces problèmes mineurs soient résolus
> depuis longtemps au moins pour une configuration standard
> automatique ! Quelle déception !
Là je suis d'accord, je trouve que les efforts faits par les différents éditeurs de distributions ne sont pas forcément placés là où ils devraient l'être. D'ailleurs j'aime bien cette idée de "minimum vital", il faudrait qu'elle fasse des émules...
> Pire encore, aucune distribution n'est capable de proposer le
> minimum vital
D'accord aussi, j'ai l'impression qu'une distribution comme Knoppix est en train de se focaliser sur ces objectifs, ils font du bon boulot même s'il y a encore des points noirs. Ce serait bien que tous les éditeurs de distributions s'en inspirent...
Pour la configuration de l'écran, la limite est X Window, les distributions n'y sont pour rien. C'est pas encore ça niveau paramétrage mais ça continue à évoluer dans le bon sens. C'est vrai que j'ai trouvé moyennement drôle de ma taper des calculs de Modelines à la main pour avoir les fréquences optimales et un mode supplémentaire (1152x864) pour mon écran exotique. Mais j'avais eu le même problème sous Windows.
[^] # Re: shell advocacy
Posté par Frédéric Lopez . En réponse à la dépêche Un article et un livre sur Linux. Évalué à 5.
D'ailleurs, la différence essentielle est que dans ton cas, la petite fille dont tu parles a sans doute été guidée par un adulte, je doute qu'elle soit arrivée à ce niveau d'utilisation du système en lisant de la doc et des how-to. Si chaque nouvel utilisateur de Linux était guidé par quelqu'un qui connait le système, ce serait sans doute plus simple, mais c'est loin d'être immédiat pour quelqu'un qui débute seul, surtout s'il ne sait pas comment demander de l'aide sur Internet. Et s'ils n'ont pas besoin d'aide pour apprendre à utiliser Windows, je trouve légitime qu'ils soient déçus de ne pas pouvoir utiliser Linux sans aide extérieure.
J'ai tendance à préférer la ligne de commande en général, mais c'est parce que je connais le nom des exécutables que j'utilise. On ne peut pas demander à un débutant de faire la même chose, je trouve normal qu'il considère ça comme une régression, c'est la machine qui est censée être à son service, pas l'inverse. Et puis rien ne l'empêchera d'utiliser la ligne de commande quand il sera un peu plus aguerri.
[^] # Re: une position unique ?
Posté par Frédéric Lopez . En réponse à la dépêche Interview de Michael Simms sur Happy Penguin. Évalué à 3.
> relativement courte et que les logiciels libres ont un temps d'arrivée
> à maturité globalement long
Je ne sais pas si c'est la principale raison, il existe pas mal de types de jeux propriétaires qui évoluent assez lentement et de manière incrémentale, un peu comme les logiciels libres.
Les jeux de sports sont un bon exemple, je me rappelle avoir joué à FIFA 95 il y a quelques années et on en est maintenant à FIFA 2003. C'est valable aussi pour les jeux de tennis (Rolland Garros 96 à 2003), les jeux de rallye (Colin Mc Rae 1 à 3) ou de skateboard (Tony Hawks 1 à 4).
C'est valable pour toutes sortes de jeux d'ailleurs : Final Fantasy (I à XII), Warcraft (1 à 3) sans compter les add-ons et les "spins-offs" (Starcraft), Grand Theft Auto (1 à 3 + add-ons + vice city), etc.
Le problème est peut-être que les gens qui écrivent des jeux libres ont la même démarche que ceux qui écrivent des jeux propriétaires. Ils écrivent leur jeu pour répondre à un besoin immédiat mais n'envisagent pas le futur. Ce qui fait qu'ils essayent d'en faire quelque chose de très ambitieux dès le départ en pensant que ça pourra se faire rapidement, mais comme ils n'ont pas les mêmes moyens que des professionnels ou que l'envie s'amenuise au fur et à mesure, le jeu n'aboutit jamais.
Mais je dois dire que je suis assez confiant dans l'avenir des jeux libres vu le succès du mode de développement très incrémental des jeux propriétaires.
[^] # Re: une position unique ?
Posté par Frédéric Lopez . En réponse à la dépêche Interview de Michael Simms sur Happy Penguin. Évalué à 1.
Je joue peut-être sur les mots, mais pour moi un jeu est un logiciel. Si les sources d'un jeu sont sous une licence libre, c'est un logiciel libre et donc un jeu libre. D'ailleurs je n'ai rien vu à propos de la licence des données dans les définitions du logiciel libre données par la fsf, il me semble que ça ne concerne que les sources.
D'ailleurs, si le jeu est libre, rien n'empêche de créer du contenu pour le faire fonctionner en choisissant n'importe quelle licence pour les données. Je ne suis d'ailleurs pas sûr que tous les jeux libres utilisent des données libres, généralement les auteurs de jeux libres ne parlent pas de la licence des données.
[^] # Re: LRs GNU Linux
Posté par Frédéric Lopez . En réponse à la dépêche LRs GNU Linux. Évalué à 10.
http://www.amazon.fr/exec/obidos/tg/feature/-/150957/ref=ed_cp_13_2(...)
De Kraftwerk à Rammstein
Trente ans de musique populaire outre-Rhin
Non, l'Allemagne ne se limite point à Beethoven et Scorpions ! Chaque nouveau mouvement musical international trouve sa version
teutonne (avec plus ou moins de réussite...). Metal, rock progressif, punk, new wave, krautrock, les Allemands essaient, expérimentent et se lancent dans tous les courants. Et c'est ainsi que ces dernières années, la scène électronique d'outre-Rhin s'avère être l'une des plus intéressantes d'Europe. Voici donc une sélection éclectique d'albums à découvrir pour apprécier la musique germanique de ces trente dernières années.
[^] # Re: L'amigaïste, une espece morte mais qui trolle toujours
Posté par Frédéric Lopez . En réponse à la dépêche TrackBalls 0.7.1 est disponible. Évalué à 1.
> qu'on puisse s'attendre a des difference de prefs plus importante
Ben c'est le même processeur à la base, donc en performance brute y a pas de raison que ça aille plus vite sauf si l'un des deux interpréteurs est vraiment plus mal écrit. Sauf quand on utilise les spécificités du hard, comme le scrolling hard et les sprites hard sur MSX.
> Et en effet Salamander et autre sont plus beau que sur les autres
> machines mais ce sont des cartouches Konami
Oui mais c'est aussi valable pour d'autres jeux comme Sorcery. De toute façon, d'un point de vue visuel la supériorité était clairement du côté du MSX. 256x192 en 16 couleurs contres 160x200, y a pas photo... Sans compter que le MSX utilisait moins de mémoire vidéo grâce à sa subtile (et parfois très chiante) utilisation d'un seul octet pour coder 8 pixels. Et puis les japonais ont toujours été meilleurs que les occidentaux pour produire des jeux bien léchés. C'est pas étonnant que Konami soit toujours là d'ailleurs...
> apres pour sortir quelque chose de la béte faut le faire en ASM et
> c'est trés chiant plus que sur l'Amstrad.
Ca dépend des outils fournis. Avec Devpac à l'époque, ça changeait pas grand chose le type de plate-forme, surtout quand c'était le même processeur. Et puis intégrer de l'assembleur dans un programme BASIC, c'était pas si compliqué sur MSX. Et puis au moins, on avait un vrai éditeur plein écran, pas un pauvre truc ligne à ligne :) Un peu comme la différence entre vi et ed :)
> donc méme si c'était une machine de merde j'en garde un bon souvenir
Je dis pas que c'était une machine de merde, loin de là. Un peu moins performante niveau technique, mais très bien intégrée (moniteur intégré, lecteur K7 ou disquette intégré, design sympa), très bon marketing en France et support utilisateur très bon. C'était l'une des rares machines pour laquelle on pouvait trouver des revues en kiosques longtemps après sa mort (un peu comme l'Amiga :).
> Tien toi aussi ta le Canon V20, merde il est pas si rare que ca au final
ben non en fait :) Faut dire que la plupart des pubs magazines pour les premiers MSX mettaient en avant le Canon. Les Sony et Phillips n'ont été mis en avant qu'avec la vague des MSX 2.
[^] # Re: en parlant de MSX
Posté par Frédéric Lopez . En réponse à la dépêche TrackBalls 0.7.1 est disponible. Évalué à 1.
[^] # Re: L'amigaïste, une espece morte mais qui trolle toujours
Posté par Frédéric Lopez . En réponse à la dépêche TrackBalls 0.7.1 est disponible. Évalué à 2.
Oui, enfin ils étaient pas tous seuls non plus. C'était avant tout un standard japonais (Sony, Canon, Yamaha, Casio, etc.) puis européen (Phillips). Et Microsoft a surtout fourgué son BASIC.
> Puis le MSX a par les rares jeux cartouches Konami, il était pas
> aussi fun que l'Amstrad
T'as jamais eu de MSX toi, les jeux étaient largement meilleurs que sur Amstrad (Nemesis, Knightmare, Lode Runner, Hole in one, etc.), surtout dans le cas où ils existaient sur les deux systèmes (Salamander, Sorcery, etc.). D'un point de vue graphique et sonore ça enterrait l'Amstrad, et de loin. Et niveau fun, pareil. Les jeux exploitaient vachement bien la machine et tu n'avais pas ce sentiment de manque de finition qu'on ressentait sur l'Amstrad.
> la programation du MSX était plus galére, certe un peut plus perfomante,
C'est une blague ??? Le basic MSX était un des meilleurs de l'époque, super puissant et simple à utiliser, tu avais tout ce qu'il fallait pour programmer des jeux et le BIOS était très bien documenté. A part les consoles, à l'époque je ne connaissais aucune machine qui supportait les sprites en hard.
> mais surtout l'absence du lecteur de casette en standar du CPC a
> beaucoup jouer en sa defaveur,
Ca c'est clair. Et le fait qu'il n'y ait pas eu de moniteur avec aussi, c'était l'argument de vente de l'Amstrad : libérez la télé...
> surtout que les cartouches Konami en Europe on pouvait se brosser.
Ben y en avait quand même une bonne collection et à l'époque j'ai jamais eu de souci pour en trouver. Il doit m'en rester une dizaine, sans compter tous les jeux rippés sur K7.
> Mais bon la machine de reference pour la prog reste le C64, qui me
> manque encore et toujour dans ma collection.
Tout à fait d'accord. Et puis pareil, ça ferait bien dans mon musée à côté de mon Apple IIc, MSX Canon V20, Amiga 500 et Atari Portfolio... :)
[^] # Re: Autres idées de portage
Posté par Frédéric Lopez . En réponse à la dépêche TrackBalls 0.7.1 est disponible. Évalué à 6.
http://stuntcarracer.sourceforge.net/(...)
[^] # Re: Correction et précisions
Posté par Frédéric Lopez . En réponse à la dépêche Recherche développeurs de jeux. Évalué à 1.
[^] # Re: Correction et précisions
Posté par Frédéric Lopez . En réponse à la dépêche Recherche développeurs de jeux. Évalué à 2.
> jeu que le PC ( genre n'importe qu'elle console ), ils n'ont pas
> vraiment le choix non plus, les boites derriére les consoles ne files
> pas de licence de dev a n'importe qui,
Ca m'étonnerait qu'ils visent le marché des consoles étant donné qu'ils ne financent pas le développement.
> et surtout les devkit et leurs code n'est pas ouvert et ne risque pas de l'étre.
Rien n'empêche les développeurs retenus de choisir des librairies Open Source (sous LGPL par exemple). C'est déjà ce que faisait Loki avec SDL, SMPEG et OpenAL pour ses portages de jeux Windows.
[^] # Re: Correction et précisions
Posté par Frédéric Lopez . En réponse à la dépêche Recherche développeurs de jeux. Évalué à 2.
http://happypenguin.org/newsitem?id=3459(...)
Il faut regarder les lignes comportant "posted by msimms".
[^] # Re: Correction et précisions
Posté par Frédéric Lopez . En réponse à la dépêche Recherche développeurs de jeux. Évalué à 2.
[^] # Re: Correction et précisions
Posté par Frédéric Lopez . En réponse à la dépêche Recherche développeurs de jeux. Évalué à 3.
> Le site LinuxGames.com annonce la mise en place d'un projet de mécénat concernant un jeu.
Juste histoire de préciser, le mécénat en question ne couvre que les frais de production, de marketing et de distribution du produit final, les développeurs ne seront pas rémunérés et ils travailleront chez eux. Ils se partageront 70% des bénéfices si le jeu se vend correctement, mais financièrement, toute la charge du développement sera sur eux :
"Firstly, this is NOT a job. This is a future self-employment opportunity. We will not be paying a salary for this."
"70% of sales revenue will go to the development company, to be divided up as the team sees fit."
> Note: il n'est pas fait mention dans l'annonce de la future licence prévue pour le jeu.
Michael Simms a donné quelques précisions à ce sujet sur le forum de happypenguin.org, et ce sera clairement propriétaire :
"It will be closed source and then it will be up to the developers when they open it - within certain guidelines"
"Im glad to see people liking the way we do things, we're trying to make sure that, sure, we're closed source, but that doesnt mean the community cant get involved!"
Et sinon, je ne vois pas non plus le rapport avec Nekeme...
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 2.
> > > obligatoirement un joystick :(
> > Lequel des deux tu trouves moche, TORCS ?
> rate, ct l'autre... c'est torcs qui demande le joystick obligatoirement :(
Ca veut dire que tu trouves que Racer est moche ? On doit pas avoir la même définition du terme "moche" alors...
Jette un oeil aux copies d'écrans, ça calme :
http://www.racer.nl/images/modern_350z_lg.jpg(...)
http://www.racer.nl/images/gt500_lg.jpg(...)
http://www.racer.nl/images/country_lg.jpg(...)
http://www.racer.nl/images/roundabout_lg.jpg(...)
Y en a d'autres ici :
http://www.racer.nl/gallery.htm(...)
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 1.
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 1.
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 1.
Il existe une palanquée de versions différentes, Bust-A-Move 1 à 4, puis Super Puzzle Bobble jusqu'à Super Puzzle Bobble 2 qui est sorti l'an dernier sur Playstation 2 et Super Puzzle Bobble All-Stars qui va sortir prochainement sur Gamecube.
Sans dire que Frozen Bubble est "pitoyable" par rapport à Puzzle Bobble, on peut quand même dire qu'il est loin de lui arriver à la cheville. Mais ça reste quand même un très bon jeu et l'effort est très louable. D'autant plus qu'il me semble qu'il a été écrit en peu de temps et que je pense que c'est un des meilleurs clônes toutes plates-formes confondues.
Si tu veux essayer les versions "officielles", je te conseille de récupérer l'émulateur Mame qui les gère très bien (après il faut trouver les ROMS). Tu verras vraiment la différence.
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 2.
Moi j'aurais tendance à penser que quand on développe un jeu, il vaut mieux n'en parler qu'à partir du moment où il est suffisament abouti pour être jouable et prêt à être étendu (niveau code ou contenu). Et si les graphismes de base ne sont pas très attrayant, c'est pas très grave, ce qui compte c'est d'avoir une base solide pour en ajouter.
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 0.
C'est clair que pour les jeux libres, il y a moins de participation, mais c'est à mon avis du essentiellement au faible avancement des différents jeux disponibles. Mais il y a quand même quelques jeux qui reçoivent des contributions extérieures, comme Cube (maps), TuxRacer (courses), Torcs (modèles) ou FlightGear (modèles) et sans doute beaucoup d'autres.
Moi je pense que si un jeu libre est suffisamment jouable et avancé pour être intéressant, trouver des graphistes ne doit vraiment pas être un problème. Ils viendront d'eux-même si le jeu en vaut la chandelle. Par contre, je comprends très bien que des graphistes n'aient pas envie de s'investir dans la création de contenu pour un jeu très peu avancé et non jouable dont ils ne savent pas s'il aboutira ou s'il sera intéressant à jouer.
Par contre, dans un premier temps, ça peut être pas mal d'essayer de profiter des modèles créés pour d'autres jeux. Quand on voit le nombre de modèles hébergés sur Polycount ou Simsresource par exemple, on se dit qu'il doit y avoir de quoi puiser dedans. Après il suffit juste de demander aux auteurs s'ils sont d'accord pour que leur contenu soit intégré.
Cela dit, s'il y avait plus d'outils utilisables pour créer du contenu sous Linux, ça aiderait carrément. Tant qu'il n'y aura pas d'équivalents à des outils comme Milkshape, Gmax, 3DS ou Lighwave, ça risque d'être difficile. Et, non, je ne pense pas que Blender soit un équivalent acceptable. D'ailleurs, à part AC3D et GTKradiant, je ne connais pas beaucoup d'outils qui sont utilisés pour créer des modèles sous Linux.
[^] # Re: The Happypenguin Awards
Posté par Frédéric Lopez . En réponse à la dépêche The Happypenguin Awards. Évalué à 1.
> obligatoirement un joystick :(
Lequel des deux tu trouves moche, TORCS ?
Regarde la vidéo sur leur site (http://torcs.sourceforge.net/video/torcs1.avi(...) ), moi je trouve que c'est loin d'être moche.
[^] # Re: Réglement du concours de jeu de programmation libre
Posté par Frédéric Lopez . En réponse à la dépêche Réglement du concours de jeu de programmation libre. Évalué à 1.
[^] # Re: Réglement du concours de jeu de programmation libre
Posté par Frédéric Lopez . En réponse à la dépêche Réglement du concours de jeu de programmation libre. Évalué à 1.