Oui, je parlais évidemment du temps qu'il fallait pour quelqu'un d'expérimenté. Quand un plombier te dit qu'il en a pour deux heures pour remplacer ton radiateur, il ne prend pas en compte son temps de formation sur la pose de radiateur.
Certes. Mais dans cas tu es le plombier et tu dis à des non plombiers qu'ils devraient faire la réparation (eux-mêmes) et que ça prendra 2h ; personnellement je le comprends comme "ça va vous prendre 2h". Mais c'est peut-être moi. Peu importe.
Mouais, en même temps l'amateurisme des équipes qui développent les jeux libres est peut-être le problème majeur […]
Je suis globalement d'accord avec tout ton paragraphe. Mais il n'est pas en contradiction avec ma phrase ; même des pros vont avoir besoin de beaucoup de temps pour faire quelque chose de soigné. Si tu codes (mais c'est vrai pour tout), alors tu sais ce que c'est que faire un sympathique prototype en 3h, mais au final passer 2 semaines sur ton patch pour gérer tous les cas particuliers pénibles etc…
Je suis d'accord avec l'ensemble de ton commentaire. Je reviens sur 2 points en particulier:
Parfois on trouve des paliers très hauts pour l'ouverture du code dans les campagnes de financement participatif de jeux indépendants mais c'est rare et encore plus rarement atteint.
Intéressant. Je me suis déjà amusé à faire le tour des plateformes de financement participatif à la recherche de projets de jeux libres, et je n'avais rien trouvé (sauf un anecdotique jeu genre casse brique pas du tout attrayant). La seule exception semble être la campagne d'amélioration de 0AD.
Du coup l'existence de tels paliers dans des projets de jeux m'intéresse, mais j'y vois 2 bémols:
je ne serais pas étonné que comme d'habitude, il s'agisse de la libération du moteur seulement.
ça me dérange que ça soit un palier, car moi j'aimerai financer uniquement si je sais que ça va être libre. Donc en pratique je dois attendre que ledit palier soit atteint ; difficile de faire passer le message "c'est ce palier que je veux, sinon rien".
Je ne pense pas que ce soit aussi simple que le fait que ça prenne du temps.
J'ai axé ma réponse autour du temps, en rapport au message auquel je répondais ; ce n'est évidemment pas le seul problème.
Mais pour préciser ma réponse, je parlais de petits jeux d'arcade comme celui de cette dépêche. Pour de tels jeux, il n'y a pas de grosse difficulté technique (le côté artistique c'est autre chose) (ex: il ne s'agit pas de faire un modèle d'éclairage dynamique 3D nécessitant des connaissances pointues en optique et en pipeline 3D), je pense pour l'aspect mathématique un niveau 4ème doit suffire (bon allez si on peut envoyer une bombe, faut peut-être savoir ce qu'est une parabole). Du coup même si ce sont des amateurs qui codent, s'ils ont assez de temps, ils vont y arriver (le code ne sera peut-être pas terrible, mais ça marchera à peu prêt). Mais même pour un petit jeu comme ça, il faudra pas mal de temps pour faire tous les petits détails qui font que ça rend bien.
Évidemment pour des jeux plus ambitieux le problème sera tout autre.
Si la seule manière d'évalluer la complexité d'un projet était de le coder, alors ça ne servirait pas à grand chose d'évaluer la complexité d'un projet…
Certes, mais en parlant d'une journée max de boulot, tu montres à mon avis à quel point il est courant dans le milieu de l'informatique de sous-évaluer le temps de développement (mais peut-être es-tu commercial dans une SSI :) ).
Alors oui, il existe des gens capables lors d'une GameJam de 24h de pondre seul des jeux même plus ambitieux que ça (et en faisant les graphismes et le son) (regardez ce que DeepNight arrive à faire par exemple), mais il s'agit de gens rodés à cet exercice depuis de longues années, qui connaissent leur outils de création de jeux sur le bout des doigts ; généralement ce sont des professionnels de la création de jeux vidéos. Donc s'ils sont capable de faire ça en un week-end, il ne faut pas oublier les années de création de jeux qui on permis d'atteindre ce niveau.
De simples amateurs qui se mettent à la création de jeux il leur faudra bien plus. Ça ne sera pas des années de développement évidemment, mais moi rien que pour lire la documentation et faire les tutoriels de GodotEngine, ça m'a largement pris plus d'une journée, pendant mes vacances. Il est tout à fait possible que tu sois bien plus compétent que moi, mais je bosse depuis suffisamment longtemps pour savoir que je suis plus compétent que la moyenne. Après je serai heureux que tu viennes nous présenter les applications libres que tu codes ; parce que si tu es capable de faire ça en quelques heures, j'imagine qu'en quelques jours de travail ça doit vraiment être impressionnant.
PS: 90% du code écrit ne fait rien de bien complexe. Pourtant le diable se cache dans les détails et même faire quelque chose d'assez trivial, quand on veut que ça soit de bonne qualité, ça prend du temps. Sinon nous aurions des tas de jeux libres de qualité. Hélas on sait qu'il ne sont pas très nombreux.
Le jeu est identique à la version DOS à part l’ajout de l’I.A
Visiblement l'idée est d'améliorer le jeu (avec un peu d'imagination, les possibilités sont nombreuses), pas juste de garder quelque chose de figé qu'on va faire tourner sur plein de plateformes. Auquel cas, la façon la plus pragmatique de faire aurait été de faire de l'émulation [*] ; ce n'est pas forcément la plus excitante techniquement évidemment.
Donc un langage de plus haut niveau peut avoir du sens (pour écrire un code réseau plus sereinement par exemple). Après ce n'est pas à moi de décider si le jeu en vaut la chandelle.
[*] la NES mini & la SNES mini par exemple, ce ne sont "que" des émulateurs dans un joli écrin.
À noter qu'il existe un outil, Corrode , capable de convertir du code C vers Rust (en revanche le projet n'a plus l'air très actif).
Évidemment ce n'est pas magique, mais l'outil a quand même réussi à convertir le code de CVS (50K lignes de code).
Dans le cas présent il est clair que si le code n'est déjà pas du joli C (pour des raisons évidentes), passer de l'asm à du Rust idiomatique ne va pas se faire sans travail de la part des codeurs.
Il ne s’agit pas de contributeurs qui sont, en effet, sonores, mais de personnes qui contribuent avec de l’effet sonore.
À titre personnel j'aurais mis "effets sonores". Si on parlait de cinéma libre, j'imagine qu'on dirait "des contributeurs en effets spéciaux" ; même si on peut parler d'un effet spécial au singulier (ex: "tel effet spécial a été réalisé avec Blender"), il me semble qu'on en parle au pluriel en général.
J'imagine que c'est de l'humour, mais vu l'incubateur d'excellence qu'est LinuxFr, je vais quand même répondre. :)
À part des cas très spécifiques, par exemple toutes ces conditions sont vérifiées:
on n'a pas de thread donc pas possible que ça introduise un bug.
on a vérifié que l'optimisation règle effectivement un problème en production très critique.
on doit livrer très rapidement une version qui corrige ledit problème mais sans casser l'API, et derrière on fera une version avec une nouvelle API correcte (celle que je proposait par exemple) (on peut même garder la vieille API en "deprecated").
soit on garde la vielle version (lente mais correcte), soit on fait une version rapide et correcte (ce qui en l'occurrence n'était pas bien long, les lignes en plus n'étant quelques déclarations). Mais conseiller en premier une bidouille infâme ne me semble pas une bonne chose ; le C++ est déjà assez piégeux comme ça.
Perso, vite fait, je me dis autant allouer la memoire dans une variable statique de la fonction, et avoir un moyen de faire un appel pour liberer si necessaire.
Les variables statiques, à l'ère du multi-threading hyper courant, c'est une mauvaise idée, puisque ta fonction ne sera pas ré-entrante. Personnellement je transformerai cette fonction en une classe avec une méthode (au moins) ; l'allocation du buffer irai dans le constructeur (RAII et compagnie, et donc la désallocation dans le destructeur évidemment), et le traitement principal dans ladite méthode. Si la méthode n'est pas protégée pas un mutex (pour être un poil plus rapide), l'objet ne devrait pas être partagé par différents threads (malheureusement C++ ne permet pas de vérifier ce genre de mauvais usage à la compilation), mais au moins chaque thread peut créer/utiliser sa propre instance sans souci.
on peut pratiquement considérer qu'un logiciel non libre puisse avoir un apport au libre plus important qu'une alternative libre…
On s'éloigne encore un peu (mais tant pis c'est amusant), mais oui on peut aller jusque là si on est taquin. Un 2000ème CMS en PHP/MySQL ne sera sûrement pas une contribution majeure au libre (et ce n'est pas grave, ses créateurs font ce qu'ils veulent) ; à côté de ça, l'IHM d'iOS a beaucoup inspiré celle d'Android par exemple (ou bien 0AD est clairement inspiré d'Age of Empires etc…). Évidemment, je ne dirai pas qu'Apple, en ce qui concerne iOS en tout cas, a fait une contribution au libre, ou que c'est cool que iOS soit propriétaire. Juste qu'à leur manière ils ont apporté quelque chose à l'humanité (mais bien sûr ça serait tellllleeement mieux si c'était libre, snif).
Si je prend ton exemple de code libre en flash, peut-être bien que si, il apporte une vraie plus-value au libre, par exemple s'il s'agissait d'un logiciel de conception d'une qualité équivalente à solidworks, katia ou autocad.
Je n'ai jamais dit que le logiciel en Flash n'avait aucune plus-value. Dans mon exemple il y aurait aussi un solidworks-like libre en C++ (équivalent à l'autre en Flash), qui aurait une plus grande plus-value. Pour mesurer cette différence de plus-value libre en fonction des dépendances/technos, c'est important dans mon exemple de ne faire varier qu'un seul paramètre (la techno) ; parce que sinon comparer un solidworks en flash et un tetris en C++, n'a pas vraiment de sens.
La frontière entre le libre et le non libre est claire: un logiciel qui respecte les 4 libertés est libre, point.
Toutafé. Je suis le premier a expliquer aux gens que non, open source c'est pas juste que le code est visible ; ou que non CC-NC/ND c'est pas du tout libre.
Du coup OpenArena n'est pas libre (il se balade avec du code non libre, point), mais la version expurgée de Debian l'est.
Je ne veux surtout pas remettre en question la définition de libre ; déjà rien qu'avec la définition commune tout le monde n'est pas toujours d'accord (ex: libre selon la FSF mais pas Debian). Mais je trouve intéressant de garder à l'esprit que la liberté ce n'est pas absolue (comme tu le dis "ça dépend des sensibilités") ; par exemple, selon qu'on considère la liberté du matériel (ou qu'en fiche, parce que matériel on le change souvent, on veut juste que les spec soit publiques) on va se sentir libre ou pas.
Je trouve qu'à l'échelle d'un logiciel, raisonner la liberté non pas de façon binaire (libre ou pas libre) mais de façon "analogique" peut être pertinent.
soit un jeu écrit par son auteur sous Windows avec VisualC++, avec quelques scripts .bat et une interface de configuration minimale utilisant l'API Windows, le tout placé sous une licence libre. Admettons qu'on peut le porter sous Linux (et autre) en utilisant des scripts shell (à la place des .bat) et du Qt/GTK en une journée.
soit un jeu "équivalent", placé lui aussi sous licence libre, mais écrit en Flash (et impossible à faire tourner avec les implémentations libres). Il va peut-être tourner sous Linux, mais pour les autres plateformes, il faudrait tout réécrire avec d'autres technos.
J'aurai tendance personnellement à trouver que (je rappelle que les 2 sont similaires en tant que jeu et entièrement sous licence libre) l'apport du 2ème au libre est nettement moindre ; juste dire qu'ils sont libres est un peu réducteur.
Annoncer une version stable alors même que les mécaniques de base sont visiblement remises en question (pas très amusant à jouer) ça serait une très mauvaise idée. Faire une version stable, puis faire des versions qui améliorent l'esthétique, ça c'est envisageable ; mais là c'est très différent.
C'est déjà compliqué de savoir combien de temps ça va prendre d'écrire du code quand on sait ce qu'il doit faire. Mais là il va peut être falloire des tas de tests sur le long terme pour savoir si les (futures) nouvelles mécaniques sont "amusantes". Quiconque s'intéresse au développement de jeu sait que ça signifie écrire et jeter beaucoup de code. Les développeurs peuvent bien t'annoncer que la prochaine version sera la stable, ils ne savent absolument quand elle sortira.
En plus, s'ils arrêtent de sortir des versions 'alpha', les joueurs prêts à tester, mais pas au point de vouloir compiler à la main le code du SVN, arrêteront de tester et de faire de retours (qui sont essentiels à la sortie de la version stable—donc c'est un cercle vicieux).
Donc c'est certes frustrant, mais dans la mesure où les créateurs n'ont pas un éditeur qui leur permet de travailler à plein temps et de payer des testeurs, alors lesdits tests sont faits par la communauté ; dans l'industrie classique, ces versions 'alpha' seraient internes (tu n'en entendraient même pas parler) ; en revanche il y auraient sûrement plus tard des versions 'beta' pour faire l'équilibrage final.
Évidemment il faut préciser de quoi on parle, parce qu'entre le mode solo d'un doom (suite de maps avec monstres/portes/armes) et le mode solo d'un Call of Duty (des couloirs séparés par des cinématiques :) ) c'est pas vraiment la même chose. Comme le commentaire initial parle de Half-Life (et que la dépêche est à propos d'un jeu en 3D), je suis parti de ce niveau d'exigence (donc des "cinématiques" en temps-réel assez basiques, genre un scientifique qui se fait bouffer juste quand tu arrives).
Ah oui mais concevoir des levels et concevoir des cinématiques c'est pas le même boulot !
Je ne sais pas si c'était clair mais je parle de cinématiques en temps-réel, donc qui se passent dans le niveau où tu joues, avec des modèles de personnages du jeu. Et donc oui, ça demande sûrement des compétences différentes, mais:
si on a des outils pour le 1er "métier" et pas le 2nd, alors c'est une réponse à la question initiale.
les gens qui arrivent à créer des campagnes solo tout seuls cumulent les 2 compétences, ce n'est pas impossible.
même si c'est 2 personnes différentes qui font le travail, il faudra qu'elle collaborent. Pour bien faire les choses, ce n'est pas un level designer qui va faire une map dans son coin, puis un autre artiste qui va se débrouiller avec ça pour raconter quelque chose.
[…] faut coder des ia qui tiennent la route (pas faibles et pas cheatees)
Suivant le jeu que tu veux faire ce n'est pas nécessaire que les ennemis soient super intelligents ; alors que typiquement, quand les bots en multi sont idiots mais peuvent te mettre des tir à la tête avec un pistolet pourri à 300 mètres c'est énervant. Par exemple si tu combats des zombis, une IA très basique donnera un bon effet je pense.
Mais si tu dois décrire des scènes cinématiques en temps réel (tel personnage parle, tel autre intervient et la caméra va vers lui etc…) uniquement avec des lignes de code (par d'éditeur visuel), j'imagine que c'est clairement un frein.
À propos des gens qui arrive à faire des mods/jeux en étant seuls:
cela n'enlève rien au travail parfois titanesque de ces personnes, mais souvent le principe des mods consiste à réutiliser les assets du jeu solo de base (et donc on revient à mon premier commentaire sur le fait de les créer lesdits assets dans le cas des jeux libres). On a aussi les fan-games qui réutilisent de manières illicites des assets d'un jeu ; ce qui pour un jeu gratuit ne me choque pas plus que ça (quand il s'agit de toute évidence d'un hommage), mais si on veut faire les choses proprement, un jeu libre ne pourrait évidemment pas se le permettre.
Désolé je comprends bien que tu voudrais connaître l'état des outils libres permettant d'écrire des campagnes solo de FPS (par rapport à ce qu'on trouve du côté proprio) ; la question est intéressante mais je n'ai pas la réponse (si quelqu'un a la réponse, qu'il n'hésite pas). Mais en effet il est très possible que le libre soit en retard de ce côté (pas étonnant vu que ce genre d'outils est écrit à la base par des entreprises pour leurs propres besoins de campagnes solo).
Il arrive effectivement que des gens tout seul arrivent à faire des mods (voire des jeux complets) , donc c'est techniquement possible, je n'ai pas dit le contraire. Je faisais juste remarquer qu'il agit quand même d'un phénomène assez rare (la plupart des joueurs vont juste consommer), et que ramené à la population des joueurs de jeux proprios ça ne représente qu'un très faible pourcentage. Si on applique le même pourcentage à la communauté des joueurs libres (infiniment plus petite), alors ce n'est pas étonnant qu'on arrive à environ 0 ; en gros il s'agit peut-être de l'affaire d'une seule personne motivée (ou pas).
Pour faire un parallèle, on a tous les outils pour faire de la BD libre (et encore, dans l'absolu on est pas obligé de n'utiliser que des logiciels libres pour faire une BD libre). Pourtant si tu peux trouver des tas de dessinateurs en herbe qui mettent gratuitement en ligne des strips, la BD libre ça n'existe pas vraiment (sauf l'exception Pepper & Carrot). J'imagine que beaucoup de ces créateurs envisagent le jour où ils pourraient être remarqués et édités de manière classique ; et quand bien même ils connaîtraient les licences libres (ce qui n'est pas gagné), je pense qu'ils préfèrent garder le contrôle "au cas où" (et c'est triste). Du coup, autant je suis le premier à être ravi de l'existence d'outils comme Godot (qui permettent de faire des jeux plus facilement, parfois sans vraiment coder), autant il y a encore pas mal de chemin à parcourir au niveau des mentalités, car ces outils ne garantissent malheureusement pas l'arrivée de nombreuses œuvres abouties.
De manière générale la communauté du jeu libre est minuscule, donc des genres de jeu qui n'ont aucun représentant (un minimum abouti) il y en a des tonnes.
Après pour ta question en particulier, je dirai qu'un FPS en multi, c'est le genre de jeu vraiment très adapté à du développement itératif communautaire. Une (petite) map, une arme, une skin de joueur et tu peux déjà jouer ; ensuite les gens vont pouvoir ajouter des maps/armes/skin au fur et à mesure. Le jeu s'enrichit mais il est intéressant à chaque étape ; évidemment il faut de l'équilibrage, ce n'est pas trivial non plus, mais dans l'ensemble ça marche bien. Et détail important, les gens qui créent le jeu peuvent s'amuser au même titre que les "simples" joueurs.
Alors qu'au contraire, un FPS solo (on peut élargir le raisonnement à tout jeu centré sur l'histoire), il va falloir une map très grande (sûrement plusieurs en fait), des ennemis différents, des PNJ & beaucoup d'assets de manière générale, avant de pouvoir offrir quelque chose d'amusant au joueur. Pour une expérience aussi dense que Half-Life, il va falloir, pour chaque minute de joueur, des jours de travail pour les créateurs. Et détail important, les créateurs ne peuvent pas vraiment apprécier leur œuvre comme les simples joueurs (vu qu'il connaissent l'histoire, ce qu'il faut faire etc…).
Du coup, ce genre de jeu est vraiment plus adapté à un développement par une entreprise, qui propose une expérience à "consommer" (ce n'est pas un gros mot) en échange d'argent. Ce qui n'exclut pas que ce soit libre dans l'absolu évidemment.
Avons-nous des suites bureautiques écrites autrement qu'avec C/C++ ?
Une bonne partie des fonctionnalités de LibreOffice sont implémentées en Java et Python (Python remplace peu à peu Java).
Le moteur de rendu (en C++ donc) n'est pas IO bound, donc je ne vois pas le rapport avec ce à quoi tu réponds (à savoir: pour du IO bound, c'est grosso-modo pareil).
Tu fustiges la presse mais tu fais toi-même un bien mauvais travail d'investigation.
tous les exécutables sous Linux tournent sous l'interpréteur ELF…
ELF est un format de fichiers exécutables (ou bibliothèques dynamiques) binaire, qui sont chargés en mémoires pour être exécutés par le processeur. Pas d'interprétation là dedans.
Tu as tendance à considérer les performances comme quelque chose d'absolu (tel langage est plus performant que tel autre), mais en fait c'est plus complexe. Fortran a été pensé pour le calcul de vecteurs/matrices, et a donc une sémantique adaptée, que les compilateurs vont savoir exploiter (SIMD et compagnie) ; mais pour certaines problématiques ses qualités vont être inutiles (pas/peu de matrices/vecteurs).
Par exemple sur ce premier benchmark Fortran est premier, mais sur ce second benchmark il est derrière java/Go/C# (il est possible que le code Fortran soit mauvais, mais on devra s'en contenter si personne ne l'améliore).
C'est incroyable tout cet acharnement pour un gars qui bosse tout seul dans son coin avec un revenu dérisoire.
Le respect des licences libres (ou pas) ne dépend pas de la taille des revenus ("Ok c'est bon vous êtes une petite boite, vous pouvez violer la GPL c'est pas grave").
Et il y en a qui font la comparaison avec Redhat. Pf, n'importe quoi.
Tout à fait cette comparaison c'est n'importe quoi. RedHat ne base pas son business model sur le fait de dire que Linux c'est du caca, et qu'il faut absolument utiliser son code (mais qu'on s'efforce à ne surtout pas voir rentrer officiellement dans Linux). Non, Redhat fait plein de code libre upstream qui finit par être utilisé par tout le monde (genre gcc).
Si tu multiplies le nombre de salariés par 2, la complexité/le coût de gestion peut être plus que multiplié par 2 (comme une complexité algorithmique de N2 par exemple) ; quelques exemples qui me passent par la tête:
la gestion des congés plus complexe.
tu peux atteindre la taille où ta boite est obligée d'avoir un Comité d'Entreprise (qui a besoin d'un budget), ou de syndicats.
à moins d'optimiser à fond (pas forcément possible selon les cas) l'utilisation de tes locaux (si tu n'utilises pas le télétravail massivement évidement), tu ne vas pas arriver à trivialement avoir 25 bureaux pour 50 personnes à mi-temps, et donc tu vas avoir besoin de plus grands locaux (le même raisonnement pour d'autres ressources est possible).
les gens même s'ils travaillent à mi-temps vont devoir être formés pareil (ils n'ont pas une mi-formation).
Sans compter que, pour prendre un exemple avec du développement, 2 développeurs à 50% ne sont pas forcément aussi productif qu'un développeur à 100% lorsque tu dois les faire bosser sur une même grosse tâche (beaucoup de temps est perdu en communication).
Après je serais curieux de voir les résultats d'une structure mettant en place un tel système.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Certes. Mais dans cas tu es le plombier et tu dis à des non plombiers qu'ils devraient faire la réparation (eux-mêmes) et que ça prendra 2h ; personnellement je le comprends comme "ça va vous prendre 2h". Mais c'est peut-être moi. Peu importe.
Je suis globalement d'accord avec tout ton paragraphe. Mais il n'est pas en contradiction avec ma phrase ; même des pros vont avoir besoin de beaucoup de temps pour faire quelque chose de soigné. Si tu codes (mais c'est vrai pour tout), alors tu sais ce que c'est que faire un sympathique prototype en 3h, mais au final passer 2 semaines sur ton patch pour gérer tous les cas particuliers pénibles etc…
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Je suis d'accord avec l'ensemble de ton commentaire. Je reviens sur 2 points en particulier:
Intéressant. Je me suis déjà amusé à faire le tour des plateformes de financement participatif à la recherche de projets de jeux libres, et je n'avais rien trouvé (sauf un anecdotique jeu genre casse brique pas du tout attrayant). La seule exception semble être la campagne d'amélioration de 0AD.
Du coup l'existence de tels paliers dans des projets de jeux m'intéresse, mais j'y vois 2 bémols:
J'ai axé ma réponse autour du temps, en rapport au message auquel je répondais ; ce n'est évidemment pas le seul problème.
Mais pour préciser ma réponse, je parlais de petits jeux d'arcade comme celui de cette dépêche. Pour de tels jeux, il n'y a pas de grosse difficulté technique (le côté artistique c'est autre chose) (ex: il ne s'agit pas de faire un modèle d'éclairage dynamique 3D nécessitant des connaissances pointues en optique et en pipeline 3D), je pense pour l'aspect mathématique un niveau 4ème doit suffire (bon allez si on peut envoyer une bombe, faut peut-être savoir ce qu'est une parabole). Du coup même si ce sont des amateurs qui codent, s'ils ont assez de temps, ils vont y arriver (le code ne sera peut-être pas terrible, mais ça marchera à peu prêt). Mais même pour un petit jeu comme ça, il faudra pas mal de temps pour faire tous les petits détails qui font que ça rend bien.
Évidemment pour des jeux plus ambitieux le problème sera tout autre.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 7. Dernière modification le 07 novembre 2017 à 00:49.
Certes, mais en parlant d'une journée max de boulot, tu montres à mon avis à quel point il est courant dans le milieu de l'informatique de sous-évaluer le temps de développement (mais peut-être es-tu commercial dans une SSI :) ).
Alors oui, il existe des gens capables lors d'une GameJam de 24h de pondre seul des jeux même plus ambitieux que ça (et en faisant les graphismes et le son) (regardez ce que DeepNight arrive à faire par exemple), mais il s'agit de gens rodés à cet exercice depuis de longues années, qui connaissent leur outils de création de jeux sur le bout des doigts ; généralement ce sont des professionnels de la création de jeux vidéos. Donc s'ils sont capable de faire ça en un week-end, il ne faut pas oublier les années de création de jeux qui on permis d'atteindre ce niveau.
De simples amateurs qui se mettent à la création de jeux il leur faudra bien plus. Ça ne sera pas des années de développement évidemment, mais moi rien que pour lire la documentation et faire les tutoriels de GodotEngine, ça m'a largement pris plus d'une journée, pendant mes vacances. Il est tout à fait possible que tu sois bien plus compétent que moi, mais je bosse depuis suffisamment longtemps pour savoir que je suis plus compétent que la moyenne. Après je serai heureux que tu viennes nous présenter les applications libres que tu codes ; parce que si tu es capable de faire ça en quelques heures, j'imagine qu'en quelques jours de travail ça doit vraiment être impressionnant.
PS: 90% du code écrit ne fait rien de bien complexe. Pourtant le diable se cache dans les détails et même faire quelque chose d'assez trivial, quand on veut que ça soit de bonne qualité, ça prend du temps. Sinon nous aurions des tas de jeux libres de qualité. Hélas on sait qu'il ne sont pas très nombreux.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Visiblement l'idée est d'améliorer le jeu (avec un peu d'imagination, les possibilités sont nombreuses), pas juste de garder quelque chose de figé qu'on va faire tourner sur plein de plateformes. Auquel cas, la façon la plus pragmatique de faire aurait été de faire de l'émulation [*] ; ce n'est pas forcément la plus excitante techniquement évidemment.
Donc un langage de plus haut niveau peut avoir du sens (pour écrire un code réseau plus sereinement par exemple). Après ce n'est pas à moi de décider si le jeu en vaut la chandelle.
[*] la NES mini & la SNES mini par exemple, ce ne sont "que" des émulateurs dans un joli écrin.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 4.
À noter qu'il existe un outil, Corrode , capable de convertir du code C vers Rust (en revanche le projet n'a plus l'air très actif).
Évidemment ce n'est pas magique, mais l'outil a quand même réussi à convertir le code de CVS (50K lignes de code).
Dans le cas présent il est clair que si le code n'est déjà pas du joli C (pour des raisons évidentes), passer de l'asm à du Rust idiomatique ne va pas se faire sans travail de la part des codeurs.
[^] # Re: Trop léger
Posté par GuieA_7 (site web personnel) . En réponse au journal Raspberry Pi et vintage. Évalué à 2.
Ou avec des ventouses. :)
[^] # Re: qui veut une dépêche ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Comment je suis devenu chef de projet. Évalué à 7.
À titre personnel j'aurais mis "effets sonores". Si on parlait de cinéma libre, j'imagine qu'on dirait "des contributeurs en effets spéciaux" ; même si on peut parler d'un effet spécial au singulier (ex: "tel effet spécial a été réalisé avec Blender"), il me semble qu'on en parle au pluriel en général.
Après ça n'est que mon avis.
# Merci !
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.
Merci au créateurs & ayant droit d'avoir accepter de libérer leurs jeux (et de vraiment tout libérer, pas juste le code, comme on le voit "souvent").
Merci à toi d'avoir fait cette démarche de demande de libération, et de travailler dessus évidemment.
J'aimerai que plus de gens dans l'industrie s'en inspirent.
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
C'était une façon détournée de dire "bravo" et "j'ai hâte de lire ces dépêches". :)
(en vrai je code déjà du libre à plein temps ; ça vaut ce que ça vaut, mais je pourrai difficilement faire plus)
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
Donc en fait tu ne bosses pas sur projet qui mérite une dépêche, mais plusieurs.
Je me sens nul…
[^] # Re: essayer Julia ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 5.
J'imagine que c'est de l'humour, mais vu l'incubateur d'excellence qu'est LinuxFr, je vais quand même répondre. :)
À part des cas très spécifiques, par exemple toutes ces conditions sont vérifiées:
soit on garde la vielle version (lente mais correcte), soit on fait une version rapide et correcte (ce qui en l'occurrence n'était pas bien long, les lignes en plus n'étant quelques déclarations). Mais conseiller en premier une bidouille infâme ne me semble pas une bonne chose ; le C++ est déjà assez piégeux comme ça.
[^] # Re: essayer Julia ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 3.
Les variables statiques, à l'ère du multi-threading hyper courant, c'est une mauvaise idée, puisque ta fonction ne sera pas ré-entrante. Personnellement je transformerai cette fonction en une classe avec une méthode (au moins) ; l'allocation du buffer irai dans le constructeur (RAII et compagnie, et donc la désallocation dans le destructeur évidemment), et le traitement principal dans ladite méthode. Si la méthode n'est pas protégée pas un mutex (pour être un poil plus rapide), l'objet ne devrait pas être partagé par différents threads (malheureusement C++ ne permet pas de vérifier ce genre de mauvais usage à la compilation), mais au moins chaque thread peut créer/utiliser sa propre instance sans souci.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
On s'éloigne encore un peu (mais tant pis c'est amusant), mais oui on peut aller jusque là si on est taquin. Un 2000ème CMS en PHP/MySQL ne sera sûrement pas une contribution majeure au libre (et ce n'est pas grave, ses créateurs font ce qu'ils veulent) ; à côté de ça, l'IHM d'iOS a beaucoup inspiré celle d'Android par exemple (ou bien 0AD est clairement inspiré d'Age of Empires etc…). Évidemment, je ne dirai pas qu'Apple, en ce qui concerne iOS en tout cas, a fait une contribution au libre, ou que c'est cool que iOS soit propriétaire. Juste qu'à leur manière ils ont apporté quelque chose à l'humanité (mais bien sûr ça serait tellllleeement mieux si c'était libre, snif).
Je n'ai jamais dit que le logiciel en Flash n'avait aucune plus-value. Dans mon exemple il y aurait aussi un solidworks-like libre en C++ (équivalent à l'autre en Flash), qui aurait une plus grande plus-value. Pour mesurer cette différence de plus-value libre en fonction des dépendances/technos, c'est important dans mon exemple de ne faire varier qu'un seul paramètre (la techno) ; parce que sinon comparer un solidworks en flash et un tetris en C++, n'a pas vraiment de sens.
Toutafé. Je suis le premier a expliquer aux gens que non, open source c'est pas juste que le code est visible ; ou que non CC-NC/ND c'est pas du tout libre.
Du coup OpenArena n'est pas libre (il se balade avec du code non libre, point), mais la version expurgée de Debian l'est.
Je ne veux surtout pas remettre en question la définition de libre ; déjà rien qu'avec la définition commune tout le monde n'est pas toujours d'accord (ex: libre selon la FSF mais pas Debian). Mais je trouve intéressant de garder à l'esprit que la liberté ce n'est pas absolue (comme tu le dis "ça dépend des sensibilités") ; par exemple, selon qu'on considère la liberté du matériel (ou qu'en fiche, parce que matériel on le change souvent, on veut juste que les spec soit publiques) on va se sentir libre ou pas.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
La question est intéressante.
Je trouve qu'à l'échelle d'un logiciel, raisonner la liberté non pas de façon binaire (libre ou pas libre) mais de façon "analogique" peut être pertinent.
J'aurai tendance personnellement à trouver que (je rappelle que les 2 sont similaires en tant que jeu et entièrement sous licence libre) l'apport du 2ème au libre est nettement moindre ; juste dire qu'ils sont libres est un peu réducteur.
[^] # Re: À quand une stable ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 8.
Annoncer une version stable alors même que les mécaniques de base sont visiblement remises en question (pas très amusant à jouer) ça serait une très mauvaise idée. Faire une version stable, puis faire des versions qui améliorent l'esthétique, ça c'est envisageable ; mais là c'est très différent.
C'est déjà compliqué de savoir combien de temps ça va prendre d'écrire du code quand on sait ce qu'il doit faire. Mais là il va peut être falloire des tas de tests sur le long terme pour savoir si les (futures) nouvelles mécaniques sont "amusantes". Quiconque s'intéresse au développement de jeu sait que ça signifie écrire et jeter beaucoup de code. Les développeurs peuvent bien t'annoncer que la prochaine version sera la stable, ils ne savent absolument quand elle sortira.
En plus, s'ils arrêtent de sortir des versions 'alpha', les joueurs prêts à tester, mais pas au point de vouloir compiler à la main le code du SVN, arrêteront de tester et de faire de retours (qui sont essentiels à la sortie de la version stable—donc c'est un cercle vicieux).
Donc c'est certes frustrant, mais dans la mesure où les créateurs n'ont pas un éditeur qui leur permet de travailler à plein temps et de payer des testeurs, alors lesdits tests sont faits par la communauté ; dans l'industrie classique, ces versions 'alpha' seraient internes (tu n'en entendraient même pas parler) ; en revanche il y auraient sûrement plus tard des versions 'beta' pour faire l'équilibrage final.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Évidemment il faut préciser de quoi on parle, parce qu'entre le mode solo d'un doom (suite de maps avec monstres/portes/armes) et le mode solo d'un Call of Duty (des couloirs séparés par des cinématiques :) ) c'est pas vraiment la même chose. Comme le commentaire initial parle de Half-Life (et que la dépêche est à propos d'un jeu en 3D), je suis parti de ce niveau d'exigence (donc des "cinématiques" en temps-réel assez basiques, genre un scientifique qui se fait bouffer juste quand tu arrives).
Je ne sais pas si c'était clair mais je parle de cinématiques en temps-réel, donc qui se passent dans le niveau où tu joues, avec des modèles de personnages du jeu. Et donc oui, ça demande sûrement des compétences différentes, mais:
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Suivant le jeu que tu veux faire ce n'est pas nécessaire que les ennemis soient super intelligents ; alors que typiquement, quand les bots en multi sont idiots mais peuvent te mettre des tir à la tête avec un pistolet pourri à 300 mètres c'est énervant. Par exemple si tu combats des zombis, une IA très basique donnera un bon effet je pense.
Mais si tu dois décrire des scènes cinématiques en temps réel (tel personnage parle, tel autre intervient et la caméra va vers lui etc…) uniquement avec des lignes de code (par d'éditeur visuel), j'imagine que c'est clairement un frein.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
À propos des gens qui arrive à faire des mods/jeux en étant seuls:
cela n'enlève rien au travail parfois titanesque de ces personnes, mais souvent le principe des mods consiste à réutiliser les assets du jeu solo de base (et donc on revient à mon premier commentaire sur le fait de les créer lesdits assets dans le cas des jeux libres). On a aussi les fan-games qui réutilisent de manières illicites des assets d'un jeu ; ce qui pour un jeu gratuit ne me choque pas plus que ça (quand il s'agit de toute évidence d'un hommage), mais si on veut faire les choses proprement, un jeu libre ne pourrait évidemment pas se le permettre.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Désolé je comprends bien que tu voudrais connaître l'état des outils libres permettant d'écrire des campagnes solo de FPS (par rapport à ce qu'on trouve du côté proprio) ; la question est intéressante mais je n'ai pas la réponse (si quelqu'un a la réponse, qu'il n'hésite pas). Mais en effet il est très possible que le libre soit en retard de ce côté (pas étonnant vu que ce genre d'outils est écrit à la base par des entreprises pour leurs propres besoins de campagnes solo).
Il arrive effectivement que des gens tout seul arrivent à faire des mods (voire des jeux complets) , donc c'est techniquement possible, je n'ai pas dit le contraire. Je faisais juste remarquer qu'il agit quand même d'un phénomène assez rare (la plupart des joueurs vont juste consommer), et que ramené à la population des joueurs de jeux proprios ça ne représente qu'un très faible pourcentage. Si on applique le même pourcentage à la communauté des joueurs libres (infiniment plus petite), alors ce n'est pas étonnant qu'on arrive à environ 0 ; en gros il s'agit peut-être de l'affaire d'une seule personne motivée (ou pas).
Pour faire un parallèle, on a tous les outils pour faire de la BD libre (et encore, dans l'absolu on est pas obligé de n'utiliser que des logiciels libres pour faire une BD libre). Pourtant si tu peux trouver des tas de dessinateurs en herbe qui mettent gratuitement en ligne des strips, la BD libre ça n'existe pas vraiment (sauf l'exception Pepper & Carrot). J'imagine que beaucoup de ces créateurs envisagent le jour où ils pourraient être remarqués et édités de manière classique ; et quand bien même ils connaîtraient les licences libres (ce qui n'est pas gagné), je pense qu'ils préfèrent garder le contrôle "au cas où" (et c'est triste). Du coup, autant je suis le premier à être ravi de l'existence d'outils comme Godot (qui permettent de faire des jeux plus facilement, parfois sans vraiment coder), autant il y a encore pas mal de chemin à parcourir au niveau des mentalités, car ces outils ne garantissent malheureusement pas l'arrivée de nombreuses œuvres abouties.
[^] # Re: pas de FPS libre mono-joueur?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 10.
De manière générale la communauté du jeu libre est minuscule, donc des genres de jeu qui n'ont aucun représentant (un minimum abouti) il y en a des tonnes.
Après pour ta question en particulier, je dirai qu'un FPS en multi, c'est le genre de jeu vraiment très adapté à du développement itératif communautaire. Une (petite) map, une arme, une skin de joueur et tu peux déjà jouer ; ensuite les gens vont pouvoir ajouter des maps/armes/skin au fur et à mesure. Le jeu s'enrichit mais il est intéressant à chaque étape ; évidemment il faut de l'équilibrage, ce n'est pas trivial non plus, mais dans l'ensemble ça marche bien. Et détail important, les gens qui créent le jeu peuvent s'amuser au même titre que les "simples" joueurs.
Alors qu'au contraire, un FPS solo (on peut élargir le raisonnement à tout jeu centré sur l'histoire), il va falloir une map très grande (sûrement plusieurs en fait), des ennemis différents, des PNJ & beaucoup d'assets de manière générale, avant de pouvoir offrir quelque chose d'amusant au joueur. Pour une expérience aussi dense que Half-Life, il va falloir, pour chaque minute de joueur, des jours de travail pour les créateurs. Et détail important, les créateurs ne peuvent pas vraiment apprécier leur œuvre comme les simples joueurs (vu qu'il connaissent l'histoire, ce qu'il faut faire etc…).
Du coup, ce genre de jeu est vraiment plus adapté à un développement par une entreprise, qui propose une expérience à "consommer" (ce n'est pas un gros mot) en échange d'argent. Ce qui n'exclut pas que ce soit libre dans l'absolu évidemment.
[^] # Re: Haskell pour les nuls
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 8.
Tu fustiges la presse mais tu fais toi-même un bien mauvais travail d'investigation.
[^] # Re: Haskell pour les nuls
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 6.
ELF est un format de fichiers exécutables (ou bibliothèques dynamiques) binaire, qui sont chargés en mémoires pour être exécutés par le processeur. Pas d'interprétation là dedans.
Tu as tendance à considérer les performances comme quelque chose d'absolu (tel langage est plus performant que tel autre), mais en fait c'est plus complexe. Fortran a été pensé pour le calcul de vecteurs/matrices, et a donc une sémantique adaptée, que les compilateurs vont savoir exploiter (SIMD et compagnie) ; mais pour certaines problématiques ses qualités vont être inutiles (pas/peu de matrices/vecteurs).
Par exemple sur ce premier benchmark Fortran est premier, mais sur ce second benchmark il est derrière java/Go/C# (il est possible que le code Fortran soit mauvais, mais on devra s'en contenter si personne ne l'améliore).
[^] # Re: Combien ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 9.
Le respect des licences libres (ou pas) ne dépend pas de la taille des revenus ("Ok c'est bon vous êtes une petite boite, vous pouvez violer la GPL c'est pas grave").
Tout à fait cette comparaison c'est n'importe quoi. RedHat ne base pas son business model sur le fait de dire que Linux c'est du caca, et qu'il faut absolument utiliser son code (mais qu'on s'efforce à ne surtout pas voir rentrer officiellement dans Linux). Non, Redhat fait plein de code libre upstream qui finit par être utilisé par tout le monde (genre gcc).
# Coquille ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche OCaml 4.04 et 4.05. Évalué à 2.
Dans le dernier exemple :
est-ce que ça ne serait pas 'switch name_opt' plutôt ? (désolé si je dis des bêtises je ne parle pas le ocaml couramment)
Sinon très bonne dépêche !
[^] # Re: Techniquement
Posté par GuieA_7 (site web personnel) . En réponse au message Recherche de boulot en temps partiel voir mi-temps. Évalué à 4.
Si tu multiplies le nombre de salariés par 2, la complexité/le coût de gestion peut être plus que multiplié par 2 (comme une complexité algorithmique de N2 par exemple) ; quelques exemples qui me passent par la tête:
Sans compter que, pour prendre un exemple avec du développement, 2 développeurs à 50% ne sont pas forcément aussi productif qu'un développeur à 100% lorsque tu dois les faire bosser sur une même grosse tâche (beaucoup de temps est perdu en communication).
Après je serais curieux de voir les résultats d'une structure mettant en place un tel système.