GuieA_7 a écrit 689 commentaires

on va créer des packs d'assets qui seront eux aussi sous licence libre

Ça c'est super !

on aimerait proposer des jeux-tutoriels

Et ils seraient libres du coup ?
Par exemple je n'ai pas trouvé les sources (code/assets) de Hunt The Yeti. Est-ce que vous n'avez pas jugé utile de les fournir sachant que Superpowers n'est lui-même pas encore libre (et que du coup elles le soient à l'avenir), ou bien est-ce une volonté délibérée de le laisser fermé ?

Personnellement, je ne suis pas convaincu qu'on trouverait assez de monde intéressé à payer pour ouvrir le code d'un jeu vidéo commercial

La question est intéressante, et je me la pose aussi.

• La situation était assez différente certes, mais il y a plus de 10 ans quand la communauté a du réunir 100K $ pour libérer Blender, cela s'est fait rapidement.
• Plus proche de nous, The Open Bundle n'a pas eu de difficulté à atteindre son objectifs financier pour libérer principalement des assets, de qualité.

À côté de ça, des exemple de libération d'un jeu contre rémunération je n'en vois pas, du coup difficile de savoir. Warzone 2100 a été libéré sans contrepartie et a réunit une petite communauté qui l'a bien amélioré ; c'était vraiment cool de la part de l'éditeur et du studio de dev, mais on ne sait pas quelle somme d'argent la communauté aurait réuni si la libération avait été payante.

Une première étape serait de libérer (si un montant est atteint) un petit jeu qui aurait déjà été amorti par ses ventes (donc on sait que c'est un jeu attirant) quand il commence à moins bien se vendre par exemple. Il n'y aurait pas grand chose à perdre, puisque ce sont les créateurs qui fixent la barre à atteindre. Évidemment c'est quand même complexe, puisque j'imagine qu'un montant abusif pourrait décourager des gens ("ils sont trop gourmands, la campagne va droit dans le mur") qui aurait donné sans ça ; ce qui rendrait un échec de la campagne difficile à analyser ; mais encore une fois il n'y aurait rien à perdre.

Je suis allé tester les deux jeux faits lors de game jam et j'ai vraiment bien aimé ; en particulier j'aime beaucoup le travail graphique sur vos jeux (ces 2 là ainsi que les autres qu'ont voit sur votre blog).

Quand on voit le succès de Unity et de GameMaker, qui font tourner pas mal des très bons jeux indépendants des dernières années, une initiative comme la vôtre (à savoir de faire une plateforme libre) est vraiment réjouissante. Donc félicitation pour le travail accompli, et bon courage pour la suite !

En revanche, j'ai une question qui me taraude. Autant avoir une plateforme libre c'est super, autant avoir en plus des jeux libres, ben ça serait encore mieux. Visiblement vous avez le talent pour faire des jeux, donc ma question est : avez-vous aussi l'envie de faire des jeux libres (code + assets), ou bien vos intentions sont de ne libérer que SuperPowers même dans un avenir lointain ??

Attention, je ne suis pas en train de réclamer des jeux gratuits : je serai vraiment ravi de payer pour avoir des jeux libres, sachant que cela pourrait dans les faits se faire de diverses manières :

• payer pour libérer un jeu proprio fini.
• payer pour libérer les assets proprios d'un jeu avec un code libre.
• financer (via financement participatif) le développement d'un jeu libre (avec évidemment les réserves classiques de faisabilité et cie bien sûr).
• libération d'un jeu lorsque sa période de commercialisation est finie.
• …

Le programme en langage assembleur est transformé en programme équivalent en langage machine : c'est bien une compilation. Une compilation triviale certes, une compilation qui laisse peu de place à l'imagination certes, mais une compilation quand même.

L'avantage des langages compilés (comme C, Ada ou Fortran) est qu'ils ont une sorte de parfum d'éternité.

Oui je comprends ; maintenant cette "éternité" n'est atteignable que pour les logiciels n'interagissant que peu avec le système (comme ici, lire et écrire des fichiers principalement). Ça représente certes bon nombre de nos logiciels d'unixien, mais heureusement qu'on ne se contente de cette classe de logiciel. Et à partir du moment on va se se lier à GTK, Qt, libXML, openSSL, openGL… on peut être certain que 15 ans après notre binaire laissé sur une disquette au fond d'un tiroir ne va plus tourner. C'est frustrant je le concède mais l'idée de logiciels évoluant sans cesse tels des formes de vie me parait tout aussi intéressante que des logiciel figés dans le marbre (ce qui ne m'empêche pas de comprendre votre motivation de ne pas vouloir corriger votre logiciel tous les 2 mois hein).

En revanche pour NB, autant il ne me viendrait pas à l'idée de coder un logiciel en Bash (déjà qu'un script de 3 lignes…), autant je m'interroge : vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?

Attention je ne remettais pas en question le choix du langage ; même si le choix est des plus singuliers, ce n'était pas l'objet de mon commentaire.

Je vois que vous avez surtout l'humilité de l'autodidacte, car je vous rassure, les professionnels ont aussi beaucoup de lacunes !! Des tas de pros se reposent sur ce qu'ils ont appris quand ils avaient 20 ans sans remettre en cause leurs connaissances, donc je n'ai souci avec quelqu'un qui se remet à coder a 50 ans ! :)

Sincèrement, je ne savais pas que Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel pouvaient être compilés statiquement (et sans runtime ?) sur Linux.

Pour le runtime, Ocaml, Haskell ou Lisp qui utilisent un Garbage Collector ont un runtime ; en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse plutôt que l'absence de runtime (mais j'ai lu en diagonale), et pour le coup je ne saurais pas vous dire ce qu'il en est (mais Ocaml générant du C, j'imagine que cela doit être possible).

Concernant le choix du langage capable de générer un binaire, la liste était très courte: il n’y avait pas de Basic (à l’époque) pour Linux ; restait le langage C, Ada et Fortran.

Ces dernières années, j'ai l'impression qu'il y a un regain d’intérêt pour les langages qui compilent du natif (Rust, Go, D, Nim…), et c'est plutôt excitant de voir ce que ça va donner dans l'écosystème du Web. Mais même en 2009 (et même 2006) il y avait déjà bien d'autres langages capables de générer un binaire: C++, Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel…

Pour Stallman, l'important est l'accès aux sources, afin de garantir à l'utilisateur une certaine sérénité. D'où l'obligation de donner accès aux sources si on le demande.

Non l'important c'est bien la liberté ; c'est pour ça que ça s'appelle "Free software" et pas "Accessible source code software". L'accessibilité n'est qu'une des nombreuses conditions techniques qui permettent les 4 libertés. D'ailleurs le code de UE4 est accessible ; il est très loin d'être libre pour autant.

Avec la licence BSD c'est un peu l'inverse : chacun fait ce qu'il veut.
C'est plus libre, mais personne n'a de garanties.

Comme je l'ai dit, on peut tout à fait penser que la licence BSD est plus libre que la GPL. Ça revient à se poser la question "la liberté d'enlever la liberté est-elle une bonne chose ?". Mais dans tous les cas, quelle que soit la licence entre BSD et GPL qui apporte le plus de liberté (je rappelle que pour la GPL, le but est la liberté des utilisateurs finaux avant tout) ça ne remet pas en cause l'intention de Stallman.

Par exemple, à mon avis, brider le design de GCC afin de mettre des bâtons dans les roues au logiciel propriétaire était stupide, car cela a aussi privé le libre d'un compilateur qui aurait pu être bien meilleur. Comme je le dis souvent, l'enfer est pavé de bonnes intentions.

Et dans bien des cas la LGPL est là pour que tout le monde soit content.

Si seulement :)

Il me semblait que l'open source s'était les avantages techniques de libre mais sans la philosophie

Alors les choses peuvent être résumées, dans un certain sens, de cette manière, mais encore faut-il comprendre ce que ça veut dire derrière.

Pour Richard Stallman, le créateur du terme "Free software" l'important c'est la liberté (des utilisateurs du logiciel), qui a été formalisée par les 4 libertés fondamentales du logiciel.
Pour les créateurs de l'"Open source", Bruce Perens et Eric S. Raymond, l'important est la saine collaboration afin d'obtenir de bons logiciels (cf le texte "La cathédrale et le bazar"). Cette idée est formalisée par les 10 points qui font qu'un logiciel est Open Source, et qui va donc bien plus loin que pouvoir voir le code source.

Au final, les licences considérées comme libres (par la FSF classiquement, mais Debian a par exemple des critères encore plus stricts), qu'elles soit héréditaires/contaminantes (GPL, LGPL, AGPL, CC-SA…) ou non (BSD, MIT, CC-BY…) sont aussi considérées comme Open Source par l'Open Source Initiative. Il existe certes des licences Open Source mais pas libres, mais c'est de l'ordre de l'exception, en générale cela recouvre les mêmes licences. Du coup, l'UnrealEngine4 qui ne peut pas être considéré comme libre, ne peut pas être Open Source.

Donc un projet peut en pratique être indifféremment être vu comme libre ou open source. Maintenant si ses contributeurs parlent plus de libre ou d'open source, cela peut indiquer en effet leur vision des choses (philosophiques ou pragmatiques), mais il faut bien voir que ce n'est pas blanc ou noir ; un pragmatique peut envoyer un patch à un projet qui se défini comme libre, un libriste peut contribué à un projet qui se défini comme Open source. Et bien des projets ne se positionnent pas spécialement.

genre llvm/clang ou encore les licences BSD

Et pour le coup là ça ne veut donc pas dire grand chose. Parmi les gens qui choisissent une licence BSD, certains le font par pragmatisme (ex: être utilisé par plein de gens et recevoir des patches), d'autres par philosophie (certains pensent que BSD est plus libre que GPL, mais c'est un autre débat) ; les 2 raisons ne sont bien évidemment pas mutuellement exclusives.

Pour LLVM, même si Apple en est un gros contributeur (et que cette entreprise de manière générale ne peut être considérée comme libriste) :

• il n'y a pas que Apple qui contribue.
• un libriste peut tout à fait être embauché par Apple pour bosser uniquement sur ce projet.

Pour le coup, dire que LLVM est plus open source que libre dans l'approche n'a pas vraiment de sens ; des tas de gens avec des desseins différents bossent dessus.

C'est open source.

Non. "Open source" correspond à une définition précise, à savoir les 10 points spécifiés par l'Open Source Initiative, qui en pratique recouvrent à peu prés la même chose que les 4 libertés du logiciel libre.

Là on se rapproche du concept plus nébuleux de "shared source" de Microsoft.

Personnellement je pense le contraire : utiliser un langage multi-paradigmes est une mauvaise idée

Pour le coup OCaml (vers lequel tu semblais attiré, et c'est très bien) est multi-paradigme. En pratique l'approche fonctionnelle est privilégiée, mais le multi-paradigme n'est pas un mal en soit. Au contraire selon les problèmes un paradigme s'en sort mieux qu'un autre.

GCC au moins le fait depuis longtemps, au moins dans les niveaux d'optimisation les plus élevés
(http://stackoverflow.com/questions/490324/how-do-i-check-if-gcc-is-performing-tail-recursion-optimization => apparemment en 03 mais pas en 02). J'imagine que ce n'est pas le seul compilateur à le faire.

Mais bon ça n'en fait évidemment pas un langage fonctionnel.

Que demander de plus ?

Un langage expressif ?

Leur ambition est d'obtenir quelque chose d'assez proche de Rust (au niveau de la gestion mémoire) me semble-t-il :

http://protz.github.io/mezzo/
https://github.com/protz/mezzo

Bon c'est un projet de recherche et je doute que ce soit une bonne idée en production, mais ça me semblait intéressant comme projet.

Sinon si c'est l'immuabilité qui t'intéresse (ce n'est pas le seul avantage du fonctionnel), alors Rust est un candidat intéressant. Si on oublie que la 1.0 n'est pas encore sortie (mais c'est pour bientôt) il a l'avantage par rapport à OCaml de ne pas avoir de GC et d'avoir des threads qui s'exécutent en parallèle ; en revanche le fait de se soucier des références (emprunt, temps de vie) rend le code plus complexe à écrire.

crasher en cas de cycle au lieu de lancer le GC

Ça n'a pas de sens ; dans un système par comptage de référence, un cycle entraîne une fuite mémoire. Et il faut justement un GC pour détecter automatiquement ces cycles (si notre cerveau ne l'a pas fait en lisant le code donc). Donc si tu veux un crash il faut lancer quand même le GC, mais crasher plutôt que libérer la mémoire.

En revanche tu peux:

• réactiver le GC lorsque c'est intelligent, genre entre les niveaux.
• activer le GC à la demande quand tu es en debug mode, et voir s'il a collecté des choses (et donc si ton code casse bien les cycles).

Je pense en effet que Rust est assez "élitiste" et la courbe d'apprentissage un peu rude ; j'ai d'ailleurs un peu peur qu'à cause de ça Rust reste assez marginal à l'instar de OCaml ou Haskell.

Un article assez intéressant qui résume assez bien la situation :
http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust
Bon en l’occurrence il est très probable que Nim reste lui aussi marginal, mais peu importe : Rust est sûrement le langage dans lequel on aimerait avoir codé un gros projet quand sa taille devient un problème, mais ne sera pas peut-être pas être assez "fun" pour débuter ledit projet, quand on ne sait pas encore qu'il va être gros :)

Bon après j'espère me tromper, et l'arrivée de bons outils (aide au refactoring automatisé, autocomplétion, voire même IDE) pourrait bien changer un peu la donne.

Je pense que tu as lu un peu vite, ou que je n'ai pas été assez clair.

Il se trouve que dans le cas particulier qui nous importe, l'interface Evaluable existe déjà à mon sens dans le langage, et c'est ce que j'appelle un callable (appelable comme une fonction donc). Je lui conseille donc de ne pas traduire le code Java trop bêtement en évitant de définir une nouvelle interface.

Mais comme je l'indique dans ma dernière phrase, il peut remplacer __call__ par eval (dans ce cas il faudra faire f.eval(1) et plus f(1) évidemment), et de même il pourrait rajouter des méthodes eval2 ou zigouigoui si il veut.

Ainsi que François l'explique au dessus, en général tu vas définir une classe AbstractMachin ou BaseBidulos, dans laquelle tu vas mettre des fonctions :

• qui soulèvent une exception NotImplementedError
• qui fournissent une implémentation de base (comme les Adapter de la lib standard Java si je me souviens bien).

un peu comme tu peux le faire en C++ et ses classes abstraites.

Il n'y a pas (à ma connaissance) de classe maitresse de toutes les autres

o = object()

Bon après rajouter des méthodes à un objet/classe ça arrive et parfois ça "sauve la vie", mais on le fait assez rarement.

S'il n'y a pas d'interface formelle[*] en Python c'est parce qu'on raisonne en terme de duck-typing, ce n'est pas à cause de la dérivation multiple.

Ton interface dans l'absolu c'est juste un callable (un truc qui s'appelle comme une fonction). Tu peux faire un truc comme ça:

class Courbe(object):
    def __init__(self, f):
        self.f = f

def main():
    [...]
    c = Courbe(lambda u: u * u)
    [...]

Ou bien avec une "vraie" fonction (que je définis bien ici depuis l'intérieur d'une autre fonction, comme toi):

def main():
    [...]

    def foobar(u):
        return u * u

    c = Courbe(foobar)
    [...]

Voire même avec une classe qui définit la méthode __call__ et peut donc être appelée comme une fonction:

def main():
    [...]
    class Foobar(object):
        def __call__(self, u):
            return u * u

    c = Courbe(Foobar())
    [...]

(évidemment si tu tiens vraiment à ta méthode 'eval' tu peux modifier mon dernier exemple, mais je trouve ça moins pythonique).

[*] Ce qui n'est plus tout à fait vrai: https://docs.python.org/release/2.7/library/abc.html#module-abc

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.

le libre ne se construit pas à grand coup de développements intensifs

Hum, c'est une vision un peu idéalisée des choses je pense. Un certain nombre de logiciels star du libre en sont le contre-exemple :

• Linux et ses milliers de contributeurs ; oui il implémente le standard POSIX, mais on ne peut pas dire qu'il ait vraiment pu utiliser des briques standards pour se faciliter le boulot.
• Blender a été développé intensivement durant sa période propriétaire (200 ingénieurs à un moment si je me souviens bien), et il ne serait pas le logiciel libre qu'il est sans ça (il n'y a qu'à regarder la concurrence libre). Évidemment il utilise des libs existantes, certaines avec des standards (ex: jpg, mpeg, png…) et d'autres non (ex: bullet), mais il est très loin d'être un assemblage de petites briques qui géreraient les maillages 3D pour une, les squelettes pour une autre, la texturisation encore à côté etc… (à mon avis une telle approche serait vouée à l'échec).
• Open/LibreOffice : là aussi développé à la base intensivement chez Sun. Les dépêches sur LinuxFr nous ont permis de voir qu'en pratique ils ont développé pas mal d'outils spécifiques (qui n'existaient pas en standalone) et se retrouve aujourd'hui à supprimer ces outils en faveur d'outils 'standards'. J'ajouterai que ODT a été standardisé longtemps après la création du logiciel, mais c'est sûrement une bonne chose, afin d'avoir une bonne idée des besoins et des problèmes rencontrés.
• Firefox

À côté de ça, les logiciels libres qui justement nécessiteraient peut-être d'un développement intensif (parce que les petites briques ne sont pas toujours une solution) mais qui n'en bénéficient malheureusement pas, sont en général à la traîne ("hey je suis un noob sous Linux et je cherche un équivalent gratuit à Photoshop/AfterEffects/Illustrator/SolidWorks…"). Pour le coup je pense que le financement participatif fait sûrement partie de la solution, puisque c'est naturel dans le libre de financer le développement avant plutôt qu'après, à coup de licences payantes.

une solution, c'est de faire des propositions, mais c'est aussi le risque de tomber dans le syndrome xkcd.

À mon sens, faire des propositions de standards n'est justement pas la chose à faire tout de suite ; ce qu'il faut faire c'est des bons jeux, avec des besoins variés, quitte à ce qu'il fasse des hacks chacun dans leur coin. Et ensuite on essaiera de rationaliser les besoins des uns et des autres afin de ne pas faire de standard bancal qui serait un boulet plus qu'autre chose.

Les fichiers standardisés c'est fondamental pour sauver les données créées par les utilisateurs et garantir l'interopérabilité. Dans le cas des jeux, cela n'a pas vraiment de sens si on parle des utilisateurs finaux : tu ne vas pas importer ta sauvegarde de FrozenBobble dans Hedgewars. Et si on parle des développeurs, le problème se pose rarement ; parce que très peu de jeux, donc peu de chance qu'il y ait un projet suffisamment proche pour que lui prendre des assets.

Je pense vraiment que akagoria est trop ambitieux pour quelqu'un qui ne peut évidemment pas bosser dessus à plein temps (mais la série d'articles n'en est pas moins excellente) [*] ; le fait de n'avoir pas à ce stade un prototype pour tester si les mécaniques fonctionne ou pas est bien plus inquiétant que d'avoir 3 parsers plutôt qu'un.

PS: j'ai hâte de voir une rétrospective des jeux qu'auront pu faire tes étudiants.

[*] j'ai du moi-même abaisser grandement les ambitions de mes jeux au cours des années, et je n'ai pourtant encore rien à montrer doit je puisse être fier…

Il y a déjà un beau moteur graphique

Ce n'est pas un moteur graphique, mais un moteur de jeu spécialisé dans les RTS.

Et oui Spring fait parti des moteurs libres les plus aboutis ; mais pour appuyer mon 1er commentaire, au final la moitié des jeux l'utilisant (http://springrts.com/wiki/Games) ne sont pas libres (contraintes NC et/ou ND).

Il ne permet donc pas de faire n'importe quel type de jeu, mais j'imagine qu'on doit pouvoir écrire son propre RTS sans toucher au code (ce qui est bien).

C'est dommage qu'on ne parle jamais de ce projet sur linuxfr.

Tu en sais sûrement plus que la plupart des linuxfriens sur ce projet, c'est donc peut-être à toi de faire le premier pas et d'écrire un journal ou une dépêche dessus ! :)

Et ce qui manque le plus dans les jeux libres, ce sont ces formats standardisés

J'aurai tendance à dire que non, c'est un problème très secondaire. Le jour où il y aura des tas de jeux libres de qualitay, et qu'on aura à gérer des tas de moteurs maisons avec leurs formats propres, et leurs différentes sous-versions etc…, alors le problème des standards se posera (d'ailleurs l'industrie du jeu y est confrontée — j'avais vu un article sur Gamasutra à propos de Collada y a quelques années par exemple).

Je ne peux pas ouvrir mes fichiers .blend (de Blender donc) dans un autre modeleur 3D ; c'est dommage mais en pratique, je m'en tape parce qu'aucun autre modeleur libre ne lui arrive à la cheville. Je préfère avoir un seul logiciel libre/gratuit/multi-plateforme qui assure, plutôt que plusieurs interopérables mais qui font le tiers de ce que je veux.

À côté de ça, ça plus de 10 ans qu'on peut facilement exporter les modèles 3D de Blender vers Ogre3D. Pourtant tous les jeux utilisant Ogre un tant soit peu aboutis sont propriétaires [*]. Pas parce que les libristes sont mauvais, mais parce que faire un bon jeu ça demande beaucoup de temps, qu'il y a peu de libristes graphistes, etc… De manière générale les créateurs de jeux libristes sont très peu nombreux, la comparaison avec les jeux propriétaires est donc forcément décevante.

Ton jeu utilise 3 formats : et bien tant pis c'est pas grave ! Quand tu auras des milliers de joueurs tu pourras proposer à tes étudiants un projet consistant à régler ce problème (ils seront ravis de toucher à un programme utilisé par des tas de gens).

Les formats standardisés ne vont pas t'apporter de graphiste libriste. A l'inverse un outil de création de jeu accessible à des non codeurs serait un vrai plus ; ces dernières années un certains nombre de très bons jeux indépendants utilisent des logiciels comme GameMaker. Mais :

• qui va écrire un tel soft en libre (c'est sûrement beaucoup de travail aussi) ?
• paradoxalement, un tel soft, gratuit et de qualité, serait sûrement utilisé avant tout pour faire des jeux proprios ! :)

J'espère ne pas avoir l'air trop négatif, je pense juste que le problème est complexe, et la solution pas forcément technique ; l'organisation de Jam et le prosélytisme de la part de tes étudiants est peut-être plus efficace au final !

Ah oui, félicitation pour ta série d'articles !

[*] Je dis ça sans méchanceté aucune, j'ai moi-même pas mal d'embryons de jeux libres dans mes cartons, dont un utilisant Ogre.

Je n'aime pas trop cette construction, ce n'est ni intuitif, ni très connu.

Je n'ai pas l'occasion de m'en servir tous les jours (comme des tas d'autres fonctionnalités au final), mais moi j'aime beaucoup cette construction. C'est à la fois lisible, et plus court et plus performant que par exemple avoir un booléen qu'on testerait en sortie de boucle. En fait j'ai même toujours pensé que ça irait bien d'autres langages genre le C.

Dans ce même registre, j'aurai aimé connaître ton avis sur Rust (en faisant abstraction du fait que la v1.0 ne soit pas sortie) ; il me semble qu'en ayant une bonne part de la puissance (concision/sûreté etc…) de langage comme Haskell/OCaml/Erlang tout en étant un vrai langage système (plus son concept de référence protégeant statiquement des data races par exemple), j'ai l'impression qu'une bonne part des analyses statiques sont déjà parties intégrante du langage (sans rebuter gens qui cherchent les performances brutes).

Quand les gens faisant du Rust s'appuient naturellement sur les forces du langages, dans le but d'obtenir des programmes élégants et performants, on y gagne en sécurité "gratuitement". Les programmes ne deviennent évidemment pas sécurisés par magie (la sécurité ça n'est pas que supprimer les buffer-overflows et cie), et pour le coup Capsicum ne perd aucun intérêt

Mais évidemment cela nécessite la ré-écriture des programmes, peut-être que c'est pour ça que tu évoques d'autres solutions.

Ceci est absolument faux. Tu confonds pas mal de choses.

Non. Parce que comme dit au dessus tu pointes le droit d'auteur "normal" (celui pour les livres, photos etc…) mais qu'il y a des exceptions spécifiques à l'écriture de code en entreprise.

Maintenant une entreprise peut-elle supprimer le nom d'un de ses salariés (ou sous-traitant) en tant qu'auteur ? Je n'en sais rien je l'avoue. Je n'ai peut-être pas été très clair, mais je parlais plus du fait de rajouter les informations manquantes fournies par la société 'C' en vue de libérer ; auquel cas il faut qu'il y ait au minimum la mention de 'A' en tant que détenteur des droits. Les salariés de 'C' ne seront que les auteurs ; je n'ai pas parlé de supprimer leurs noms, mais plutôt de les rajouter s'il ne l'ont pas fait eux-mêmes (en leur demandant leur avis). Je ne sait pas si 'A' aurait le droit de supprimer leurs noms comme je l'ai dit, mais en même tant ça serait un peu une attitude de merde de toute les façons, et j'étais plus dans l'optique de rendre à César ce qui lui appartient (à savoir un peu de reconnaissance).

J'imagine que les salariés de 'C' ont le droit de refuser, c'est pour ça que je dis de leur demander leur avis. Et le code ayant déjà été livré, je ne vois pas où 'A' s'oppose à ce qu'ils mettent leurs noms dans le code ; éventuellement ça serait la faute de 'C', je propose justement de rétablir la situation.

Mais encore une fois, si je n'ai pas été assez clair : je parlais uniquement d'ajouts.

Attention il faut faire la différence entre auteur et détenteur du doit d'auteur. Lorsque le salarié 'a' de la société 'A' écrit du code dans le cadre de son travail, il est l'auteur du code mais c'est 'A' qui détient les droits d'auteurs (j'admets que 'a' ne travaille pas en régie dans une société 'C'). Si ici 'B' a bien cédé ses droits à 'A' (cela dépend du contrat entre les 2 sociétés), alors c'est bien 'A' le détenteur des droits, quand bien même les auteurs sont des salariés de 'B'.

Seul le détenteur des droits doit figurer dans les sources, mais il est classique et sympa de citer les auteurs, ainsi qu'éventuellement leur rôle dans le code et une adresse e-mail, généralement dans un fichier AUTHORS. Cela ne leur donne aucun droit sur ledit code, mais à moins que le code ne soit honteux, ça fait plaisir un peu de reconnaissance ! Je serai donc d'avis de demander aux auteur chez 'B' s'ils souhaitent y figurer.

Pour la permissivité, attention cela veut dire que le code sous licence permissive peut tout à fait être intégré dans un code sous une autre licence (libre ou proprio) ; en revanche cela ne veut pas dire que la licence originelle du code peut être modifiée. Elle reste la même, tandis que le reste du code a une autre licence, mais ça ne pose pas de problème.

Auriez vous des suggestions de licences pour un mode permissif ou un mode contaminant ?

Restes sur des licences classiques et éprouvées :

• GPL/LGPL/AGPL pour du héréditaire/contaminant.
• BSD/MIT/Apache pour du permissif.

C'est déjà assez compliqué comme ça les licences libres pour ne pas aller en chercher une exotique que personne ne connaît.
Et si celles-ci ne te satisfont, que tu veux des clauses supplémentaires (genre obligation de remonter les modifications à l'upstream, ou avoir la photo de la sœur des contributeurs), tu vas te rendre compte que tu ne cherches pas à faire du libre.