Tu te rends compte que tes exemples ne font qu'apporter de l'eau à mon moulin ?
Non et je vais ré-expliquer pourquoi.
Linux, comme dit avant moi, n'est pas parti de rien, il s'est appuyé sur des briques déjà existantes à l'époque, notamment le userland GNU, et GCC
Je n'ai pas prétendu que Linux était parti de rien. Évidemment qu'il utilise un langage/compilateur existant ; même si tu utilises C++ et SFML pour ton projet, je considère que tu l'as codé depuis 0, au contraire de si tu avais par exemple forké un jeu existant (après ça reste discutable). Ce que je dis c'est qu'il est issu d'un développement intensif, et pas d'un simple assemblage de briques existantes faisant une chose et une seule (scheduler, gestionnaire de mémoire, VFS...) ; si de telles briques avaient existé chez GNU, ça voudrait dire que Hurd était disponible.
Blender et OpenOffice : beaux exemples de développements intensifs... non-libres
Tout à fait mais que tu le veuilles ou non, ce sont maintenant des projets libres, et sans cette phase de développement non-libres, ils n'existeraient pas. Difficile de savoir si la communauté auraient été capable de faire aussi bien, et c'est pour ça que j'ai parlé des hypothétiques équivalent libres à Photoshop et cie, qui me font dire que non, on aurait pas aussi bien que Blender.
Développer un logiciel proprio et le libérer ce n'est pas ma façon de faire, ni la tienne, mais ça reste une option qui a donné des résultats.
Et tu décris toi-même le processus en cours chez LibreOffice : ils utilisent un maximum des briques libres.
Oui maintenant ils ré-usinent le code (et c'est très bien), mais dans un premier temps il se sont foutu de faire des briques standards (parce que coder de telles briques était déjà suffisamment difficile comme ça), et s'en sont préoccupé largement après que OO est devenu une référence.
Quant à Firefox, il a commencé comme un navigateur basé sur une brique libre (Gecko) plutôt que par un développement from scratch.
Gecko est né des cendres de Netscape (avec donc une histoire un peu similaire a Blender/OpenOffice), et reste donc un logiciel développé de manière intensive par une grosse équipe, et pas un assemblage épars de briques standardisées.
On ne fait pas des bons jeux avec des hacks dans le libre. Le libre a la particularité de ne pas fonctionner avec des logiciels jetables mais avec du durable et du réutilisable.
As-tu lu le code de beaucoup de logiciel libres ? Bon nombre de logiciels libres de référence (OpenSSL :) ) ont un code crade.
hacks ! = jetable. Parfois un hack est nécessaire à un instant T pour que les utilisateurs aient un logiciel qui marche, et on l'enlève quand on peut. Les codeurs de Linux ou de Python par exemple sont les premier à avouer avoir eu recours à des hacks, ce n'est pas sale :)
Attention je ne veux pas avoir l'air de prôner le code dégueulasse, en revanche la vertu numéro 1 d'un soft c'est de fonctionner (il faut juste ne pas s’arrêter à ce stade).
Je me suis peut-être mal exprimé mais il ne s'agit pas de partager des assets mais des formats. Si je reprends l'exemple des dialogues, on peut très bien avoir un format unique mais des dialogues différents pour chaque jeu. L'avantage du format unique est qu'il permet d'avoir des outils commun pour le manipuler.
Je comprends tout à fait l'idée, mais dans la mesure ou il n'y a pas de jeux libres d'aventures du genre d'akagoria, difficile de savoir quels vont être les besoins des autres jeux, qui devront donc être satisfaits pas cet éventuel format. Évidemment des tas de gens ici seront capable de te dire qu'il faut absolument ceci ou cela (moi le premier), mais sans être vraiment confronté au problème dans un vrai jeu, il est probable que tu finisses pas implémenter des fonctionnalités dont personne ne va se servir au final, et oublier les besoins réels des futurs jeux.
Si Ruby on Rails et Django sont si bons, c'est parce qu'ils ont été écrits par des gens ayant écrit par mal de sites/apps web, ce qu'il leur a permis de voir les besoins réels, les patterns récurrents, les abstractions qui seraient utiles. S'il les avaient conçus avant même d'avoir ne serait-ce qu'un seul site à moitié fini, ces frameworks serait sûrement morts et enterrés.
Ils ont du mal, pas tant dans le code que dans l'organisation.
Difficile de leur jeter la pierre, rien de ce que j'ai pu écrire étant étudiant ne vaut quoi que ce soit.
[^] # Re: Le plus gros manque ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E14 : formats de données. Évalué à 3.
Non et je vais ré-expliquer pourquoi.
Je n'ai pas prétendu que Linux était parti de rien. Évidemment qu'il utilise un langage/compilateur existant ; même si tu utilises C++ et SFML pour ton projet, je considère que tu l'as codé depuis 0, au contraire de si tu avais par exemple forké un jeu existant (après ça reste discutable). Ce que je dis c'est qu'il est issu d'un développement intensif, et pas d'un simple assemblage de briques existantes faisant une chose et une seule (scheduler, gestionnaire de mémoire, VFS...) ; si de telles briques avaient existé chez GNU, ça voudrait dire que Hurd était disponible.
Tout à fait mais que tu le veuilles ou non, ce sont maintenant des projets libres, et sans cette phase de développement non-libres, ils n'existeraient pas. Difficile de savoir si la communauté auraient été capable de faire aussi bien, et c'est pour ça que j'ai parlé des hypothétiques équivalent libres à Photoshop et cie, qui me font dire que non, on aurait pas aussi bien que Blender.
Développer un logiciel proprio et le libérer ce n'est pas ma façon de faire, ni la tienne, mais ça reste une option qui a donné des résultats.
Oui maintenant ils ré-usinent le code (et c'est très bien), mais dans un premier temps il se sont foutu de faire des briques standards (parce que coder de telles briques était déjà suffisamment difficile comme ça), et s'en sont préoccupé largement après que OO est devenu une référence.
Gecko est né des cendres de Netscape (avec donc une histoire un peu similaire a Blender/OpenOffice), et reste donc un logiciel développé de manière intensive par une grosse équipe, et pas un assemblage épars de briques standardisées.
Je comprends tout à fait l'idée, mais dans la mesure ou il n'y a pas de jeux libres d'aventures du genre d'akagoria, difficile de savoir quels vont être les besoins des autres jeux, qui devront donc être satisfaits pas cet éventuel format. Évidemment des tas de gens ici seront capable de te dire qu'il faut absolument ceci ou cela (moi le premier), mais sans être vraiment confronté au problème dans un vrai jeu, il est probable que tu finisses pas implémenter des fonctionnalités dont personne ne va se servir au final, et oublier les besoins réels des futurs jeux.
Si Ruby on Rails et Django sont si bons, c'est parce qu'ils ont été écrits par des gens ayant écrit par mal de sites/apps web, ce qu'il leur a permis de voir les besoins réels, les patterns récurrents, les abstractions qui seraient utiles. S'il les avaient conçus avant même d'avoir ne serait-ce qu'un seul site à moitié fini, ces frameworks serait sûrement morts et enterrés.
Difficile de leur jeter la pierre, rien de ce que j'ai pu écrire étant étudiant ne vaut quoi que ce soit.