30 réponses à ce sujet

[C_Wizard]

Si le monde du jeu vidéo dispose de quelques icônes reconnues pour leur gameplay (comme le héros favori de Yavin, Peter Molyneux), rares sont ceux qui sont reconnus pour leur mérite technique. En fait, quand on y réflechit, il n'y a bien que John Carmack qui mérite la reconnaissance du monde entier pour ses multiples innovations dans le monde de la 3D.

Beaucoup s'accordent pour dire que sa plus belle création se trouve dans le moteur 3D utilisé pour un petit jeu qui aurait eu un brin de succès, le fantastique Quake 3 : Arena. Il apportait à l'époque des graphismes ravageurs avec quelques techniques de programmation bien senties et légèrement innovatrices. Un moteur que la firme id software a vendu maintes et maintes fois pour servir de base à d'autres jeux (Elite Force, Enemy Territory, etc...). L'excellente nouvelle que l'on attendait tous vient enfin de tomber lors de la conférence de John Carmack lors du QuakeCon (la fête annuelle qui rassemble les fans d'id software dans une Lan Party géante dans un coin perdu du Texas) : le code source de Quake III va bientôt passer en open source.


Ca ne vous donne pas envie d'y rejouer ?

Véritable tradition pour id, l'ouverture du code source de ses jeux permet de voir arriver des initiatives tierces intéressantes comme QuakeForge et bien d'autres, le code de Quake 3 devrait lui aussi déchaîner les passions. C'est surtout pour beaucoup un moyen d'apprendre les techniques de programmation avancées créant ce mythe qui restera dans les esprits de tous pour la qualité de son gameplay multijoueurs.

Bien entendu ce moteur date quelque peu (5 ans, c'est très long dans le monde de la 3D), mais de l'avis de ceux qui ont vu le code source (suivez un peu, id software l'a déjà vendu à pleins de gens), il est beaucoup plus clair et simple à comprendre que ses prédecesseurs, plutôt bien hiérarchisé et il sera possible de le faire évoluer assez simplement pour lui ajouter les petites nouveautés auxquelles vous êtes tous accros (physique plus évoluée, pixels shaders en pagaille et éclairages un brin plus réalistes).

Des lignes de code qui se liront comme de saintes paroles.

Merci John.

Pour plus de détails sur la Keynote :
http://www.filerush.com/download.php?targe...mackKeynote.zip

[Drealmer]

Ca c'est une excellente nouvelle ! Il se sera fait désirer celui-là... Et en plus de ça il est bien mature, Id n'est pas du genre à laisser tomber un code avant de l'avoir patché jusqu'au moindre petit bug, un peu comme Epic.

Je vais enfin pouvoir lire le vrai code derrière les MD4, miam.

[Donjohn]

C'est une bonne nouvelle pour le mode des moddeurs aussi. Ils vont pouvoir faire leurs jeux non commerciaux (je pense que le contrat doit specifier une telle chose) en ayant le moteur complet.

Et pour ce qui est de l'evolutivité on a déjà vu beacoup d'exemples (merde... comment s'appelle ce jeu lara croft like mais à l'epée et style platforme ? tiré d'un comic américain ?? rien à gagner sauf me faire plaisir )

PS : non c'est pas American Mc Gey (Gea/Gei/Geai ?) qui avait aussi montré qu'on pouvait utiliser le moteur de Q3 pour de grands décors.


PS2 : faut que je m'y remette, j'ai chauffé Teckos et Vince sur Q3

Modifié par Donjohn, 13 August 2005 - 20:57.

[PetitPrince]

Donjohn, le 13 Aug 2005, 21:53, dit :

PS : non c'est pas American Mc Gey (Gea/Gei/Geai ?) qui avait aussi montré qu'on pouvait utiliser le moteur de Q3 pour de grands décors.

<{POST_SNAPBACK}>

American McGee's Alice ?

[Drealmer]

Donjohn, le 13 Aug 2005, 20:53, dit :

Et pour ce qui est de l'evolutivité on a déjà vu beacoup d'exemples (merde... comment s'appelle ce jeu lara croft like mais à l'epée et style platforme ? tiré d'un comic américain ?? rien à gagner sauf me faire plaisir )

PS : non c'est pas American Mc Gey (Gea/Gei/Geai ?) qui avait aussi montré qu'on pouvait utiliser le moteur de Q3 pour de grands décors.

<{POST_SNAPBACK}>

Heavy Metal FAKK 2 ?

Et sinon c'est Mac Gee je pense

[C_Wizard]

Pour ceux qui auraient la flème de mater la conf de Carmack, quelques remarques supplémentaires du grand John :

- Malgré le hype, il estime que les consoles next gen sont a peu près au niveau d'un pc haut de gamme actuel.
- John dit du bien de Microsoft et des efforts qu'ils ont fait sur les kits de développement.
- Ces consoles sont multi threadées de tout les cotés, et il va y'avoir pas mal de boulot pour en tirer le meilleur. Si l'on compile du code "actuel" sur ces consoles, on obtient la moitié des perfs de ce qu'on à sur un PC.
- Utiliser les 3 procs de la Xbox360 en simultané est très chaud, et beaucoup de développeurs vont se contenter de faire le rendu dans un autre thread (comme le permetait le mode SMP de Q3).
- Pour lui, l'arrivée du multi processeur à tous les niveaux est peut être un brin précipité vu les problèmes engendrés par les problèmes de parrallélisation. Beaucoup de recherches ont été faites sur le sujet et ce n'est pas top.
- A propos du Cell, Carmack estime qu'il n'est pas forcément fait pour juste la physique ou l'AI, et que le surplus de cycles qu'on offre à ces champs ne sera pas forcément totalement utilisé corecteemnt. Il estime que l'AI ne profitera pas énormément des cycles supplémentaires et que malgré une complexité plus grande, l'impression finale pour le gamer sera quasi similaire. Pour la physique, elle n'est pas scalable et c'est un gros problème.
- Beaucoup de démos de physique sur PS3 ou sur Ageia sont faites de manière non interactives, restent intéressantes mais ne vont pas rendre le gameplay plus interessant. Dès que l'on veut faire des choses interactives, cela demandera beaucoup plus de puissance. Il conclut sur le sujet en disant que le sujet est très complexe à résoudre, et que le temps passé dessus n'apportera pas grand chose au final.
- Il aime le coté ouvert de Sony pour ses plateformes de développement par rapport à MS (faut qu'on lui parle de la PSP ). Il compare la PS3 à une sorte de nouvel Amiga. Stupeur. Sony pourrait l'ouvrir et en faire une machine similaire...
- Le HD : la restriction de rendre les jeux en 720p mini chez MS est purement marketing parce qu'on pourrait faire peut être aussi bien avec moins de resolution et plus d'anti-aliasing (un grand débat sur PC).
- Il se plaint qu'il aimerait essayer de nouveaux genres de jeux que les FPS (Il le fait a tout les Quakecon mais Todd son boss n'est pas très réceptif )
- Il s'amuse beaucoup a essayer des choses sur téléphones portables car ca ne coute pas cher et qu'ils peuvent se permettre d'essayer beaucoup de choses sans que ca coute grand chose ou remette en cause le projet.
- Il trouve que ce sont de belles plateformes pour apprendre à programmer car sur PC les technologies sont parfois complexes et surtout couteuses.
- Tous les titres de la famille Quake ont rapporté un milliard de $ à id. Il pense que sortir le code source peut inspirer les gens.
- Parmis ses fantasmes il aimerait que quelqu'un sorte un jeu de manière commerciale avec le code source sur le CD. Il est prêt à relicenser le code pour ceux qui a partir du code GPL voudrait refaire une appli commerciale closed source.
- Trop de développeurs portent une trop grande valeur à leur code source et devraient l'ouvrir.
- Il aimerait sortir un jeu "différent" sur téléphones portables puis utiliser ca pour négocier la possibilité de faire un jeu PC basé sur le même concept. Bon courage John.
- Son dernier fantasme graphique serait d'avoir une virtualisation totale sur les GPU.
- Il préfère les données précalculées aux algorithmes de génération, trop limités.
- Les textures actuelles (répétition type tiling) sont un des freins au réalisme et il milite pour des textures "uniques". Cela aurait un impact surement plus important sur les joueurs que la plupart des technologies actuelles qui consomment des cycles 3D (il parle du subsurface scattering par exemple). Il veut des virtual page tables sur les GPU pour acceder aux textures
- Les drivers et les API apportent un niveau d'abstraction intéressant, mais trop souvent ils prennent de mauvaises décisions et limitent la créativité du code.
- Les platesformes sont stables, les CPU et les GPU sont a un bon niveau dans toutes les marques

Dans les Q&A :
- Développement sur de multiples plateformes : les différences sont de plus en plus limitées et les consoles de prochianes générations (avec les pc haut de gamme) ont quasiment les mêmes perfs finales. Les devs feront plutot de multiples petites threads qui tourneront bien sur les 2 consoles, qu'une gestion en peer thread qui ne marcherait pas bien sur le Cell (alors que ca tournerait mieux sur 360). Programmer avec le PC comme plateforme principale posera des soucis lors du portage sur console.
- PSP : Il aime le côté cool de la console et son architecture. Développement "painful" dessus
- Cartes standalone physiques : il n'est pas content de s'etre fait quoter par AGEIA sur le sujet de la physique, ils vont payer des devs pour ajouter de l'herbe qui bouge et de la fumée intelligente, mais cela risque de s'arreter la. Le problème de la physique est qu'il n'y a pas de fallback, les effets physiques ne peuvent pas etre intégrés au gameplay si ils necessitent une carte optionnelle.
- Sur les MMO : il aurait aimer travailler sur un de ces titres. L'augmentation de la bande passante pourrait éliminer les cheats. Il redit du bien de Xbox Live (décidément on ne l'a jamais entendu dire autant de bien de MS).
- D'ici une semaine le code de Q3 devrait être disponible.
- Il a revendu ses ferraris et conduit un X5, sa femme un Z8. Très BMW les Carmacks décidément.

[Drealmer]

Merci C_Wizard pour cet excellent compte-rendu !

C_Wizard, le 13 Aug 2005, 22:06, dit :

- Les textures actuelles (répétition type tiling) sont un des freins au réalisme et il milite pour des textures "uniques". Cela aurait un impact surement plus important sur les joueurs que la plupart des technologies actuelles qui consomment des cycles 3D (il parle du subsurface scattering par exemple).

<{POST_SNAPBACK}>

Oui mais euh... Des textures uniques d'accord, il a déjà fait un pas dans ce sens avec la fameuse techno megatexture de quake wars, mais il faut encore des artistes pour les créer ces textures. Et puis les outils qui vont avec.

Et pour le subsurface scattering, je trouve que ça ajoute quand même pas mal à la qualité du rendu, et y'a de toutes façons pas moyen d'arriver à un résultat équivalent avec de simples textures.

[Clad]

En plus ça montre qu'ils ont vraiment confiance dans le moteur de D3 pour considérer déjà le code de quake 3 obsolete. Et puis d'accord, le moteur a 5 ans, mais même encore aujourd'hui (enfin jusqu'à l'année derniere au moins) on voit apparaitre des jeux recents utilisant ce moteur, et ils ne sont pas plus moche que d'autres.

Par contre "la PS3 un nouvel amiga" euh... certes.... il a inhallé la "fumée intelligente" de chez AGEIA ?

[yavin]

Clad, le 13 Aug 2005, 22:23, dit :

En plus ça montre qu'ils ont vraiment confiance dans le moteur de D3 pour considérer déjà le code de quake 3 obsolete.

<{POST_SNAPBACK}>

Quand tu vois le trailer de Quake Wars, t'as pas trop de doute sur la viabilité du Doom 3 engine.

[Ghanja]

Merki mon cher C_Wiz !

Quelques remarques:

-Pareil que drealmer, c'est bien de vouloir des textures uniques, encore faut-il avoir l'armée de graphistes nécessaire. Ou alors j'ai compris de travers.

-Les consoles next-gen au niveau d'un pc haut de gamme actuel?? My god elles sont vraiment pas si puissantes que ça alors... Tout ce foin pour rien?

-720p mini... euh vraiment mini?

-putain revendre ses ferraris... et pour un X5 en plus. Il baisse dans mon estime ce john.

[yavin]

Ghanja, le 13 Aug 2005, 23:33, dit :

-720p mini... euh vraiment mini?

<{POST_SNAPBACK}>

Non pas "mini" dans le sens où le jeu ne proposera aucune autre résolution, Microsoft est fou mais pas cinglé. Ils veulent imposer aux développeurs le 720p dans tous les jeux histoire que ça fasse bien sur les bornes Fnac pour que ça tape et créer un fossé générationnel entre les machines. C'est dans ce sens là qu'il faut le comprendre, et ça fait débat en ce moment, cette obligation.

[tuo]

yavin, le 14 Aug 2005, 01:17, dit :

Non pas "mini" dans le sens où le jeu ne proposera aucune autre résolution, Microsoft est fou mais pas cinglé. Ils veulent imposer aux développeurs le 720p dans tous les jeux histoire que ça fasse bien sur les bornes Fnac pour que ça tape et créer un fossé générationnel entre les machines. C'est dans ce sens là qu'il faut le comprendre, et ça fait débat en ce moment, cette obligation.

<{POST_SNAPBACK}>

Microsoft considére que dans les 4 ou 5 ans de durée de vie de la console, le HDTV va décoller (ça a déjà commencé aux US et au Japon, en Europe on est craintif mais ça viendra bien un jour ou l'autre). Du coup, ils préférent s'assurer que meme les premiers jeux fonctionnent en HDTV, pour éviter d'avoir des gouffres entre les premiers jeux non-HDTV et les jeux suivants en HDTV niveau performance : le fillrate requis pour remplir tout ça n'est pas le même.

Donc certes, ils "brident" artificiellement les performances de leur machine, mais ils assument, et font ça pour que les gens, plus tard, puissent exploiter leurs télés HDTV. Si un constructeur avait fait ça a l'époque du 16/9, il serait bien plus largement supporté qu'actuellement.

[silicium]

merci C_wizard pour ce compte rendu. pour ce que j'en touche, je trouve Carmack très crédible, pour les sujets que je connais pas, je veux bien le croire, hormis le coup de l'amiga

et merci john, t'es le meilleur, id software remonte dans mon estime après un doom3 lassant et répétifif au possible. bon c quand que le code s'ouvre ? j'imagine qu'on pourra le downloader sur de beaux FTP bientôt non ?

[Drealmer]

silicium, le 14 Aug 2005, 01:47, dit :

et merci john, t'es le meilleur, id software remonte dans mon estime après un doom3 lassant et répétifif au possible. bon c quand que le code s'ouvre ? j'imagine qu'on pourra le downloader sur de beaux FTP bientôt non ?

<{POST_SNAPBACK}>

Ouh le vilain petit Silicium, qui n'a pas lu tout le post de C_Wizard:

Citation

- D'ici une semaine le code de Q3 devrait être disponible.

[silicium]

Drealmer, le 14 Aug 2005, 10:40, dit :

Ouh le vilain petit Silicium, qui n'a pas lu tout le post de C_Wizard:

<{POST_SNAPBACK}>

je plaide coupable, mais pour circonstances atténuantes, j'ai posté à 2h40 du matin

[Glup]

Drealmer, le 13 Aug 2005, 23:22, dit :

Merci C_Wizard pour cet excellent compte-rendu !
Oui mais euh... Des textures uniques d'accord, il a déjà fait un pas dans ce sens avec la fameuse techno megatexture de quake wars, mais il faut encore des artistes pour les créer ces textures. Et puis les outils qui vont avec.

Et pour le subsurface scattering, je trouve que ça ajoute quand même pas mal à la qualité du rendu, et y'a de toutes façons pas moyen d'arriver à un résultat équivalent avec de simples textures.

<{POST_SNAPBACK}>

Euh... Et ça prendrais pas des Go par dizaines ce plan textures uniques pour un bon fps ? Blu-ray ? CG 1Go ? :x

Modifié par GluP, 15 August 2005 - 17:03.

[Bassah0lic]

C_Wizard, le 13 Aug 2005, 22:06, dit :

- Trop de développeurs portent une trop grande valeur à leur code source et devraient l'ouvrir.

<{POST_SNAPBACK}>

5 ans après si ils veulent le X5 "

[Drealmer]

Au sujet du code source que les développeurs devraient tous diffuser, c'est pas si simple (voici trois raisons, par ordre croissant d'importance) :

1. Le code source n'est pas toujours très propre. Quand on fait un moteur, comme c'est le cas pour Quake, les exigences ne sont pas les mêmes, et on obtient à la fin un code qui est concu pour être transféré à d'autres personnes. Diffuser un code source brouillon peut nuire, niveau notoriété.

2. Quand on a le code source, on peut facilement compiler en enlevant tous les systèmes de protection contre la copie. Et même si le jeu est considéré comme commercialement mort par le développeur, il peut ne pas en être de même pour les éditeurs. Et mieux vaut ne pas se mettre les éditeurs à dos, à moins de s'appeler Valve ou id software, càd d'en avoir les moyens.

3. Un jeu qui compile sans aucun SDK externe, ça devient rare. Y'a pas beaucoup de monde qui fait encore des jeux en créant son propre système audio, son propre moteur 3D, son propre moteur physique, son propre moteur réseau, etc. Et la plupart du temps ces SDK ont une licence qui empêche de les distribuer... tout le monde ne s'appelle pas FMOD

[C_Wizard]

Drealmer, le 15 Aug 2005, 21:19, dit :

1. Le code source n'est pas toujours très propre. Quand on fait un moteur, comme c'est le cas pour Quake, les exigences ne sont pas les mêmes, et on obtient à la fin un code qui est concu pour être transféré à d'autres personnes. Diffuser un code source brouillon peut nuire, niveau notoriété.

<{POST_SNAPBACK}>

Ha putain. Pourtant tout le monde sait que je conchie RMS, emacs et le kernel 2.4 mais je vais quand même prendre la défense de l'open source.

L'excuse qui revient sans cesse de "mon code il est pas propre, il est pas optimisé, y'a des trucs pas bien dedans", ça me les brise menues. Si c'est pas propre, on rend propre, si c'est pas optimisé, on optimise, et si y'a des choses moches on les vire. Quoi ? Pas le temps ? Bah voilà, soit on code pour l'amour de l'art ou soit on fait ça de manière alimentaire. C'est une question de philosophie de vie.

J'en entends déjà qui vont me dire "ouiiiiiiiiiiiiiiii mais tu comprends, les pressions de l'éditeur tout ça". Carmack n'a pas toujours été une star, et il ne faisait pas de concessions avant. C'est peut être pour ça qu'il est différent.

Drealmer, le 15 Aug 2005, 21:19, dit :

2. Quand on a le code source, on peut facilement compiler en enlevant tous les systèmes de protection contre la copie. Et même si le jeu est considéré comme commercialement mort par le développeur, il peut ne pas en être de même pour les éditeurs. Et mieux vaut ne pas se mettre les éditeurs à dos, à moins de s'appeler Valve ou id software, càd d'en avoir les moyens.

<{POST_SNAPBACK}>

Pipo. Tous les checks de clefs modernes sont server side et la version solo aura été craquée 4 jours avant la sortie du jeu. Donc même avec le code source de la protection, ca ne changera strictement rien.

Drealmer, le 15 Aug 2005, 21:19, dit :

3. Un jeu qui compile sans aucun SDK externe, ça devient rare. Y'a pas beaucoup de monde qui fait encore des jeux en créant son propre système audio, son propre moteur 3D, son propre moteur physique, son propre moteur réseau, etc. Et la plupart du temps ces SDK ont une licence qui empêche de les distribuer... tout le monde ne s'appelle pas FMOD

<{POST_SNAPBACK}>

Des problèmes de licence il y'en a toujours, si tu bases ton jeu entièrement sur un SDK tiers, l'intérêt est moindre. D'un autre côté, je ne pense pas que les développeurs de jeux basés sur Q3 vont se presser pour ouvrir leur code maintenant que celui de leur SDK est dispo ? Mauvaise excuse donc.

Et personne ne les oblige à partager le code complet, ils pourraient très bien en partager de petites portions, même si elles ne compilent pas. Pour que les autres apprennent.

[GloP]

C_Wizard, le 17 Aug 2005, 09:08, dit :

L'excuse qui revient sans cesse de "mon code il est pas propre, il est pas optimisé, y'a des trucs pas bien dedans", ça me les brise menues. Si c'est pas propre, on rend propre, si c'est pas optimisé, on optimise, et si y'a des choses moches on les vire. Quoi ? Pas le temps ? Bah voilà, soit on code pour l'amour de l'art ou soit on fait ça de manière alimentaire. C'est une question de philosophie de vie.

<{POST_SNAPBACK}>

Ouai enfin juste une petite observation meme si sur le fond je suis d'accord mais dans un projet de cette taille c'est quand meme super plus compliqué que ca et vachement moins tout noir/tout blanc. Carmack meme si il vit dans un monde a part et tout je suis d'accord, il est pas tout seul a coder, de mega loin. On peut pas rendre open source un truc juste en faisant un zip et basta et c'est pas forcement de l'art ou du code alimentaire (je sais que ca vanne tuo la coucou tuo). On considere toujours de le faire pour tout le code de System.Windows.Forms et y a rien dans le code dont j'ai honte et pourtant c'est super loin d'etre aussi trivial et ca prend des ressources significatives. Il faut qu'il y ait une vrai motivation derriere, pas juste "parceque ca serait rigolo". Maintenant clair, y a de la philosophie dans la maniere de coder et si c'est fait a la "alimentaire/je m'en foutiste" t'as beaucoup plus de problemes bien bien avant que des gens qui regardent ton code ait des commentaires "artistiques" a faire

[titibgosse]

un gros merci à c_wiz pour son compte rendu !

[C_Wizard]

GloP, le 17 Aug 2005, 19:46, dit :

Il faut qu'il y ait une vrai motivation derriere, pas juste "parceque ca serait rigolo". Maintenant clair, y a de la philosophie dans la maniere de coder et si c'est fait a la "alimentaire/je m'en foutiste" t'as beaucoup plus de problemes bien bien avant que des gens qui regardent ton code ait des commentaires "artistiques" a faire

<{POST_SNAPBACK}>

Oui mais si j'insiste la dessus, c'est que de tous les champs de développement logiciels modernes, le jeu est parmi les moins bien représentés en code source disponible (open source ou licence quelconque, on s'en tape). Je parle ici des jeux qui vont stresser (ou ont stressé) la carte 3D (on peut être pour/contre, trollez ailleurs), le jeune de 13 ans qui voudrait se mettre a la prog de jeu video, il pleure parce qu'il ne trouve pas grand chose pour se faire les dents.

Et pas de dérives sur les SDK please (c'est à toi que je parle Gloppy)

[GloP]

Le jeune de 13 ans si tu veux le degouter a vie de la programmation de jeux videos tu lui balance le code source d'un jeu moderne complet cela dit je comprend l'argument, le code pour programmer de jeux et s'y mettre est clairement aps super dispo.

[Drealmer]

C_Wizard, le 17 Aug 2005, 18:08, dit :

L'excuse qui revient sans cesse de "mon code il est pas propre, il est pas optimisé, y'a des trucs pas bien dedans", ça me les brise menues. Si c'est pas propre, on rend propre, si c'est pas optimisé, on optimise, et si y'a des choses moches on les vire. Quoi ? Pas le temps ? Bah voilà, soit on code pour l'amour de l'art ou soit on fait ça de manière alimentaire. C'est une question de philosophie de vie.

J'en entends déjà qui vont me dire "ouiiiiiiiiiiiiiiii mais tu comprends, les pressions de l'éditeur tout ça". Carmack n'a pas toujours été une star, et il ne faisait pas de concessions avant. C'est peut être pour ça qu'il est différent.

<{POST_SNAPBACK}>

Des trois arguments, j'ai bien dit que celui-ci était le moins solide, et effectivement il est pas évident à défendre. Cependant, même si on encense Carmack, faut bien se dire que c'est lorsque id software a été créé (ou "ideas from the deep" pour le nom d'origine) qu'il a commencé à diffuser ses codes sources. Lorsqu'il travaillait pour SoftDisk, il a écrit pas mal de trucs aussi, mais à ma connaissance y'a jamais eu un bout de code source diffusé. C'était juste pas lui qui avait les droits sur le code. Diffuser un code source c'est pas l'affaire des programmeurs, c'est l'affaire des gens qui embauchent les programmeurs. Et ceux-là n'ont pas toujours une vocation de bienfaiteur de l'humanité. D'ailleurs le code source de Doom version PC n'a jamais été publié non plus. Ok je dévie de l'argument inital pas propre blabla.

C_Wizard, le 17 Aug 2005, 18:08, dit :

Pipo. Tous les checks de clefs modernes sont server side et la version solo aura été craquée 4 jours avant la sortie du jeu. Donc même avec le code source de la protection, ca ne changera strictement rien.

<{POST_SNAPBACK}>

Tout d'abord non, ça saute pas en 4 jours, voir le thread sur splinter cell qui a été locké y'a pas longtemps. Ensuite, après la vie en magasin d'un jeu, y'a plein d'autres façons de l'utiliser pour encore en tirer un peu de sous. Encore une fois, voir le thread en question pour plus amples explications. Et même si y'a à peine moyen d'en tirer de quoi acheter un paquet de cacahuètes, demande à un éditeur ce qu'il pense de balancer le code source et vois la réponse.

C_Wizard, le 17 Aug 2005, 18:08, dit :

Des problèmes de licence il y'en a toujours, si tu bases ton jeu entièrement sur un SDK tiers, l'intérêt est moindre. D'un autre côté, je ne pense pas que les développeurs de jeux basés sur Q3 vont se presser pour ouvrir leur code maintenant que celui de leur SDK est dispo ? Mauvaise excuse donc.

Et personne ne les oblige à partager le code complet, ils pourraient très bien en partager de petites portions, même si elles ne compilent pas. Pour que les autres apprennent.

<{POST_SNAPBACK}>

Tout d'abord je parle du problème inverse, pas un jeu qui utilise un SDK open source, mais un jeu open source qui utiliserait plein de SDK propriétaires. Tout d'abord, si tu diffuses le code source sans les SDK, non seulement ça compile pas, mais tu diffuses aussi la façon d'utiliser le SDK, car tous les appels de fonctions sont toujours là. Suffit d'avoir un éditeur de SDK qui veut chercher la petite bête et y'a de quoi se faire taper sur les doigts.

Donc au final le code source est forcément incomplet et inutilisable. Permettre d'apprendre ? Clairement : non. Le code source complet d'un jeu actuel, c'est énorme, pas forcément très propre, et très complexe. Sans parler du fait que c'est généralement peu et mal documenté, car pour un code conçu par une petite équipe et qui a évolué beaucoup et très vite, y'a pas mal de connaissances transmises par voie orale qui prendraient beaucoup de temps à être rédigées. Donc ça va juste servir à faire peur et à paumer le débutant qui y jetterait un oeil. Y'a de meilleures sources de référence pour apprendre que ça.

Alors il reste ceux qui ont déjà les connaissances nécessaires pour se débrouiller avec ce genre de trucs, et qui aimeraient bien avoir accès à ce genre de code pour voir si y'a des idées intéressantes. Et là, c'est la pénurie, d'accord. Et c'est dommage.

L'idéal serait d'avoir plein de codes sources qui circulent. C'est un énorme débat, bien plus philosophique que technique. Mais faut bien se dire que diffuser un code source, c'est pas juste comme le dit glop "on zip, et hop". Et puis pour finir sur une constation étayant mon premier argument, moi je trouve que la plaie de l'open source, c'est que pour 1 projet développé activement, y'a 50 projets morts qui polluent (n'ayons pas peur des mots) sourceforge et consorts. Alors partager du code source d'accord, mais privilégions le code source de qualité. Et oui, vive Carmack, car il fait les deux.

[C_Wizard]

Je la fais courte :

Drealmer, le 17 Aug 2005, 22:39, dit :

Des trois arguments, j'ai bien dit que celui-ci était le moins solide

<{POST_SNAPBACK}>

Alors pourquoi argumenter ? Ou déplacer le débat en disant que peut importe si c'est mal codé, de toute façon c'est l'éditeur qui décide ! So what, il n'y a pas de bonnes raisons pour mal coder, et dire qu'on ne veut pas ouvrir son code parce qu'on a honte de ce qu'on a écrit, ca me met hors de moi. Autant dire qu'on ne veut pas l'ouvrir et basta, je respecte. Faut arreter les arguments vaseux.

Sinon, pour la version DOS (et pas PC, SERIEUX) de Doom, c'est a cause d'un driver son tiers. Ils se sont contentés quand même de releaser le code de la version Linux, pas mal non ? Ha le fud c'est facile a propager...

Drealmer, le 17 Aug 2005, 22:39, dit :

Tout d'abord je parle du problème inverse, pas un jeu qui utilise un SDK open source, mais un jeu open source qui utiliserait plein de SDK propriétaires. Tout d'abord, si tu diffuses le code source sans les SDK, non seulement ça compile pas, mais tu diffuses aussi la façon d'utiliser le SDK, car tous les appels de fonctions sont toujours là. Suffit d'avoir un éditeur de SDK qui veut chercher la petite bête et y'a de quoi se faire taper sur les doigts.

<{POST_SNAPBACK}>

Non je ne parle pas d'un problème inverse. Les gens qui ont acheté le moteur de Q3 sous licence commerciale (il n'était pas open source a l'époque) ne vont pas ouvrir leur code aujourd'hui, alors qu'ils le pourraient.

Des gens utilisent des libs tierces ? Oui c'est un problème, en attendant y'a beaucoup d'autres gens qui ouvrent leur code ? Non, j'ai que 2 autres exemples en tête hors id.

Drealmer, le 17 Aug 2005, 22:39, dit :

Donc au final le code source est forcément incomplet et inutilisable. Permettre d'apprendre ? Clairement : non. Le code source complet d'un jeu actuel, c'est énorme, pas forcément très propre, et très complexe. Sans parler du fait que c'est généralement peu et mal documenté, car pour un code conçu par une petite équipe et qui a évolué beaucoup et très vite, y'a pas mal de connaissances transmises par voie orale qui prendraient beaucoup de temps à être rédigées. Donc ça va juste servir à faire peur et à paumer le débutant qui y jetterait un oeil. Y'a de meilleures sources de référence pour apprendre que ça.

<{POST_SNAPBACK}>

Et le mec de niveau intermédiaire qui s'est fait tout les tutoriels DirectX qui trainaient, puis tous les OpenGL parce qu'il était a court, et qui ne sait toujours pas trop comment s'y prendre, il ne bénéficierait pas du code d'un jeu complet ? Ou d'une portion qui pourrait être illustrée par un tutorial écrit par un programmeur, va savoir. On l'obligerait même pas a mettre des morceaux entiers de code dedans. Ce genre d'initiatives y'en a pas des masses dans le jeu vidéo, clairement moins qu'ailleurs, et ca c'est dommage. Tout le reste c'est du blabla.

On la refait : personne ne va bénéficier du code de Carmack ? Ha oui mais tu va me sortir que c'est différent parce que lui, il code bien.

Drealmer, le 17 Aug 2005, 22:39, dit :

Alors partager du code source d'accord, mais privilégions le code source de qualité. Et oui, vive Carmack, car il fait les deux.

<{POST_SNAPBACK}>

Je coupe encore le blabla inutile sur les forks qui n'a rien a faire ici. Donc l'argument final c'est quoi que je résume ? Il n'y a que Carmack qui fait bien son boulot donc laissons le ouvrir seul ? Super... Franchement on a bien avancé !

[Drealmer]

C_Wizard, le 17 Aug 2005, 23:20, dit :

Je la fais courte :
Alors pourquoi argumenter ? Ou déplacer le débat en disant que peut importe si c'est mal codé, de toute façon c'est l'éditeur qui décide ! So what, il n'y a pas de bonnes raisons pour mal coder, et dire qu'on ne veut pas ouvrir son code parce qu'on a honte de ce qu'on a écrit, ca me met hors de moi. Autant dire qu'on ne veut pas l'ouvrir et basta, je respecte. Faut arreter les arguments vaseux.

<{POST_SNAPBACK}>

Ben donc on n'a pas le même avis, ce n'est pas une raison pour traiter mes arguments de vaseux. Quand je programme j'apprends de nouvelles choses tous les jours, et mon style évolue de façon constante. Au final, quand je regarde un an derrière moi, et que je vois ce que j'ai écrit, j'ai envie de tout balancer à la poubelle. Tu veux le code source d'un logiciel de gestion en production qui fonctionne en réseau parce que sa base de données est sur un disque partagé et que j'ai hacké un méchanisme de lock pour que chaque client s'y connecte à son tour ? Tu veux un autre logiciel de gestion dans lequel tous les éléments d'interface sont définis par des coordonnées hardcodées ? Et des trucs où près de 50% du code contient un assert(!"dead code"); pour éviter de virer les dépendances, parce que c'était juste un test qui a finalement dégénéré en "code de prod" ? Ah oui, et du code où y'a un #ifdef TEST_XYZ toutes les cinq linges ? Faut pas croire, mais ce qu'on voit sur thedailywtf ça existe vraiment. Alors bien entendu, je ne reprends que les pires exemples. De tout ce que j'ai produit jusqu'à présent, y'a quasiment rien que je récrirais de la même manière, mais y'a pas non plus que des monstruosités. L'ennui c'est que plutôt que de choisir de nettoyer un vieux truc, je préfère investir mon temps à aller de l'avant en écrivant quelque chose de neuf et en prenant note des erreurs qui m'ont conduit à être insatisfait du précédent code.

C_Wizard, le 17 Aug 2005, 23:20, dit :

Sinon, pour la version DOS (et pas PC, SERIEUX) de Doom, c'est a cause d'un driver son tiers. Ils se sont contentés quand même de releaser le code de la version Linux, pas mal non ? Ha le fud c'est facile a propager...

<{POST_SNAPBACK}>

Oui, la version DOS, pas la version PC. Je me suis relu un peu vite, et non je ne fais pas de fud, arrête les procès d'intentions.

C_Wizard, le 17 Aug 2005, 23:20, dit :

Non je ne parle pas d'un problème inverse. Les gens qui ont acheté le moteur de Q3 sous licence commerciale (il n'était pas open source a l'époque) ne vont pas ouvrir leur code aujourd'hui, alors qu'ils le pourraient.

<{POST_SNAPBACK}>

C'est clair, et c'est bien dommage. Mais entre les gens qui veulent et les gens qui peuvent... enfin, ça a déjà été dit.

C_Wizard, le 17 Aug 2005, 23:20, dit :

Des gens utilisent des libs tierces ? Oui c'est un problème, en attendant y'a beaucoup d'autres gens qui ouvrent leur code ? Non, j'ai que 2 autres exemples en tête hors id.
Et le mec de niveau intermédiaire qui s'est fait tout les tutoriels DirectX qui trainaient, puis tous les OpenGL parce qu'il était a court, et qui ne sait toujours pas trop comment s'y prendre, il ne bénéficierait pas du code d'un jeu complet ? Ou d'une portion qui pourrait être illustrée par un tutorial écrit par un programmeur, va savoir. On l'obligerait même pas a mettre des morceaux entiers de code dedans. Ce genre d'initiatives y'en a pas des masses dans le jeu vidéo, clairement moins qu'ailleurs, et ca c'est dommage. Tout le reste c'est du blabla.

<{POST_SNAPBACK}>

Faire des tutoriaux et expliquer ce qu'on a fait dans le code ? Juste en expliquer une partie car l'intégralité serait une trop grosse somme de travail ? Expliquer les leçons qu'on a tirées d'un projet ? Ben regarde les articles de gamasutra, les présentations de la GDC, les articles de game developer magazine, ça pullule. Tout ça sans parler des recueils genre game gems ou gpu gems. C'est clairement pas le matériel qui manque. Ce sont tous des articles et extraits de code de qualité réalisés par des professionnels expérimentés, qui partagent leur savoir sur des sujets intéressants. Tu préfères lire un gros code source où seul 5% du code noyé dans le reste a un intérêt au lieu de trouver directement de la documentation sur le sujet qui t'intéresse ? Bah chacun son truc. Et alors le coup de celui qui a lu et compris tout ça et qui veut encore apprendre... Ben si le gars il a pas déjà un poste de senior developer c'est qu'il a raté une marche, ce serait plutôt à lui d'écrire des articles.

C_Wizard, le 17 Aug 2005, 23:20, dit :

On la refait : personne ne va bénéficier du code de Carmack ? Ha oui mais tu va me sortir que c'est différent parce que lui, il code bien.

<{POST_SNAPBACK}>

J'ai dit qu'il était expérimenté, et qu'il vendait ses moteurs, et que donc la documentation et le nettoyage du code à destination d'autre personnes faisaient partie de ses attributions. Ai-je dit que personne ne bénéficierait de son code ? Non

C_Wizard, le 17 Aug 2005, 23:20, dit :

Je coupe encore le blabla inutile sur les forks qui n'a rien a faire ici. Donc l'argument final c'est quoi que je résume ? Il n'y a que Carmack qui fait bien son boulot donc laissons le ouvrir seul ? Super... Franchement on a bien avancé !

<{POST_SNAPBACK}>

Des forks ? J'ai parlé de forks ? Non j'ai parlé de projets open source en général. Combien y a-t-il de projets à l'état de alpha depuis trois ans sur sourceforge ? Combien de projets qui n'ont jamais dépassé la version 0.1 ? Combien de projets ne souffrent pas du syndrôme "j'ai codé 500 lignes, c'est vraiment trop génial, faut que je le partage avec tout le monde, et ça va attirer les foules" et après on se rend compte soi même d'à quel point c'était nul et on laisse tomber.

Comprenons-nous bien : je suis totalement POUR le partage du code source, seulement, y'a deux éléments importants :

1. la qualité vaut mieux que la quantité, je préfère un extrait de code intéressant avec un article qu'un code source complet sans explications
2. pour des gros projets, c'est pas facile d'avoir les autorisations nécessaires

Et pour finir, restons courtois, please...

[C_Wizard]

Drealmer, le 18 Aug 2005, 10:19, dit :

1. la qualité vaut mieux que la quantité, je préfère un extrait de code intéressant avec un article qu'un code source complet sans explications
2. pour des gros projets, c'est pas facile d'avoir les autorisations nécessaires

<{POST_SNAPBACK}>

Soit exactement ce que je suggère depuis le début, je n'ai pas demandé que tout le monde ouvre son code mais que plus de gens le fassent dans un milieu ou le code dispo est plus réduit qu'ailleurs. Tout n'est pas bon a ouvrir mais il y'a surement d'autres projets sympathiques qui auraient pu être ouverts.

Modifié par C_Wizard, 18 August 2005 - 18:38.

[lordabdul]

Y'a aussi l'aspect "réputation de la boite"... Je sais pas, si une boite sort le code source d'un jeu vieux de 3 ans, et mon dieu, 3 gars sur internet ont le malheur de trouver que le code est crade et postent sur leur blog, c'est répercuté partout, ça prend des proportions énormes, et avant que les commerciaux aient le temps de finir leur dernière présentation PowerPoint, tout internet surnomme la boite "MonkeyCoding".
(ou alors c'est moi qui suis parano)

[GloP]

lordabdul, le 18 Aug 2005, 10:08, dit :

(ou alors c'est moi qui suis parano)

<{POST_SNAPBACK}>

Oooooh non. Malheureusement pas.

[Staz]

Désolé de vous déranger dans vos délires libristes. c'est juste pour vous prévenir que le code source est dorénaveant disponible.

source + mirroir

Modifié par Staz, 21 August 2005 - 22:04.