drakmaniso a écrit 274 commentaires

Les commentaires précédents me donnent envie de vomir.

A l'auteur du journal: merci pour le lien. La BD est vraiment claire, sans animosité ni raccourcis réducteurs.

Malheureusement, j'ai l'impression que le sexisme dont elle parle est en grande partie imperméable à une telle pédagogie. Je pense que sa principale racine n'est pas l'ignorance, et cela le rend d'autant plus difficile à combattre.

Merci à l'auteur du journal, l'article donné en lien est vraiment excellent.

Article malheureusement parfaitement illustré par les commentaires ici présents.

Il faut vraiment lutter par tous les moyens possible contre cette recrudescence du sexisme, d'autant plus inquiétante qu'elle a lieu dans des milieux où l'ignorance ne saurait en être la cause.

Aucun rapport avec le problème. On parlait de portages.

Le support de fonctionnalités "modernes" (OpenGL 3, datant de plusieurs années) est assez aléatoires avec les drivers proprios, et est très en retard avec les drivers libres.

Le problème est qu'avant sa version 3, OpenGL avait d'immenses lacunes vis à vis du hardware, lacunes qui ont été (plus ou moins) comblées d'un seul coup; il y a donc eu un énorme boulot à faire pour mettre à jour les drivers. On peut espérer qu'une fois que ce support généralisé, la suite suivra plus facilement.

Bien sûr.

Un jeu médiocre est un jeu qui provoque l'engouement des critiques et d'innombrables joueurs. Un jeu autour duquel il se forme une communauté de création de niveaux ou de mods. Un jeu dont tout le monde attend la suite avec impatience. Mais puisque vous ne l'aimez pas, c'est un jeu médiocre.

Et la grosse blague? L'état des softs libres portés sous d'autres plateformes. Je m'amuse comme un fou lorsque je gimpe sous windows, ou que je lance inkscape. Ou que j'essaie de retravailler des sous-titres avec Gaupol. C'est si facile un portage… qu'à peu près seul Firefox s'en sort.

Il suffit de connaître l'état d'OpenGL sous linux pour comprendre en quoi un portage vidéo-ludique peut-être une gageure. Et ce n'est que l'élément le plus évident parmi une multitude, chacun pouvant poser ses obstacles spécifiques.

Je suis quelque peu sidéré par l'aigreur de certains commentaires ci-dessus. Et je me rends compte qu'on vient de franchir une étape, celle où le portage de jeux vidéos vers notre système est devenue suffisamment banale pour que le linuxien snob, en bon hipster, puisse lâcher sa hargne et raconter n'importe quoi.

Porter une appli vers une plateforme qu'on ne connait pas, et dont la culture nous est tout aussi inconnue, n'est pas une mince affaire, contrairement à ce que certains ont l'air de penser. Je salue le courage des dévs qui ont décidé de le faire.

La qualité des jeux? Pour ne citer qu'eux, Torchlight (au passage, normal que ça ressemble à Diablo, c'est fait par les anciens dévs de Diablo), S.P.A.Z., Dustforce sont des hits du monde des jeux indés, aussi bien au niveau des joueurs que des critiques. De ce fait c'est probablement le bundle qui contient le plus de ces "hits". Ça a toujours été la formule du HIB: un part de titres connus, et le reste plus obscur.

Je dirais que ça dépend du type de vie tu envisages pour Newton Adventure:
- continuer le développement et le level design jusqu'à ce que tu le considères "complet";
- ou bien espérer qu'une communauté se forme et créée de nouvelles maps indéfiniment.

Dans le premier cas, le fork d'un outil est parfaitement raisonnable, vu que son utilité n'est que temporaire. Dans le second cas c'est beaucoup plus délicat, et je pense que pour favoriser la contribution de levels par les joueurs, il faut un outil solide et maintenu à jour, ce qui va doubler le travail si tu as ta propre version.

Il y a une autre solution, un peu extrême mais qui est sûre de marcher: intégrer l'éditeur de maps à ton jeu. C'est le meilleur moyen d'inciter à la création, et cela a été fait à maintes reprises aussi bien dans le monde proprio que dans le libre.

Non, je pensais aux différents projets de jeux libres que j'ai pu observer d'un peu près (je n'ai participé un peu qu'à Neverball). Il y a souvent une poignée de codeurs, et plusieurs artistes qui se relaient.

Bien sûr il y a aussi des équipes plus restreintes… :)

Je disais juste que ça existait, assez fréquemment. Et donc que "le problème" des jeux libres ne réside pas dans la quantité de travail fourni.

C'est précisément ce que j'entends par "problème de direction". Il amha est plus difficile d'obtenir certaines formes de cohérence dans un projet ouvert.

À ma connaissance, les jeux libres les plus "finis" (je pense à Battle for Wesnoth, Neverball) ont été initialement l'œuvre d'une seule personne.

D'une part, certains studios indés débutent en ayant un autre job à côté (parfois dans une grosse boite de jeux). La situation est alors similaire.

Il y a aussi pas mal de "studios" comportant seulement une ou deux personnes; la plupart des jeux libres dont j'ai pu observer le développement ont souvent bien plus de contributeurs, et peuvent donc cumuler un temps disponible équivalent.

Donc oui, je pense qu'un projet open source peut aisément rivaliser en terme de "puissance brute". Pour moi c'est beaucoup plus un problème de direction que de nombre.

Je pense que le problème est inhérent à la complexité du jeu vidéo : il faudrait fédérer une énorme communauté aux compétences extrêmement variées pour lutter contre les grands du domaine : en allant du moteur jusqu'à la réalisation d'images et de sons.

Je ne pense pas que ce soit le problème, ou du moins, pas le seul, vu qu'il y a plein de petits studios indés qui font des jeux merveilleux. Hors ces studios comportent fréquemment moins de développeurs et d'artistes qu'un projet open source typique.

Personnellement, j'avancerai trois hypothèses sur ce qui fait obstacle à l'abondance de jeux libres "réussis" (ayant le degré de finition des jeux propriétaires):

• Dans un projet ouvert, il n'est pas facile de maintenir une cohérence de style entre plusieurs artistes (que ce soit pour les graphismes, les sons, le level design…). À l'inverse du code où il suffit de quelques règles simples, et où de petites variations de style ne seront pas perceptibles par le joueur.
• Il est difficile de créer un gameplay à plusieurs, dans une discussion ouverte. Paradoxalement, on peut constater cette même difficulté dans les grands studios, dont les titres AAA sont quasiment tous des déclinaisons de gameplay bien établis. Seul les petits studios semblent capables d'innover (il y a bien sûr quelques exceptions).
• Il faut souvent sacrifier du code / des assets pour améliorer le gameplay, et je pense qu'un projet libre hésitera avant de jeter une partie du travail de ses contributeurs.

Les dialogues et la mise en scène regorgent de moment purement whedoniens, de ce côté-là c'est un vrai bonheur. La thématique des Avengers coïncide assez avec l'un des thèmes de prédilection de Whedon, la construction d'une famille à partir d'éléments disparates. C'est d'ailleurs là qu'est la véritable histoire du film, pas dans la lutte contre le grand méchant mais dans la convergence houleuse d'une bande de freaks.

Après comme tu le dis, ce n'est pas un film où il a eu totale liberté, forcément; ça reste une grosse production. Mais contrairement à certaines autres tentatives, c'est de l'entertainment qui s'assume, une grosse déclaration d'amour décomplexée au monde des comics, qui n'essaie pas de se faire passer pour autre chose.

Bref, si tu es fan de Whedon tu vas probablement adorer, en sachant que ce n'est pas sa plus grande réalisation non plus (bien moins personnel que Dr Horrible, Buffy & co).

Chacun son avis. Un grand nombre de joueurs sont très contents d'avoir Steam, et un grand nombre de dévs indés également. Une plateforme n'empêche pas de vendre directement à côté, c'est même sans doute le cas le plus répandu pour les petits studios. Elle permet de toucher un public différent.

Hélas, je suis principalement codeur, et purement lurker sur les forums fréquentés par des artistes susceptibles d'être intéressés. Sans compter que je suis assez dubitatif sur l'enthousiasme que cela générerait…

Oui, mais pratiquement toujours à partir de sources disponibles. Sans le libre, beaucoup de jeux amateurs ne seraient jamais allé au delà du brouillon.

Dans le monde du libre, peut-être, mais pas pour les dévs indés qui font du "proprio". Je ne dit pas que tout le monde commence à coder from scratch, mais c'est une option viable qui a donné des jeux formidables. Ce qui se fait beaucoup aussi, c'est de réutiliser son propre code.

Le libre, tout comme l'absence de DRM, n'empêche pas de vendre.

Évidement, on peut utiliser les plateformes de ventes actuelles. Je ne suis pas sûr qu'on puisse vendre du logiciel libre sur Steam. Il y au moins Desura qui commence à faire sa place, mais sous Linux certains jeux supportés ne s'installent pas sur certaines distrib. Avoir une plateforme de distribution qui profite des avantages du libre, notamment de pouvoir recompiler un jeu s'il ne tourne pas, pourrait être une bonne idée.

Mais pour qu'une telle plateforme prenne son essor, il faut d'abord une belle collection de jeux capables d'attirer un public plus important que les joueurs déjà libristes.

L'initiative est louable, mais si elle ne touche que des codeurs je pense que son utilité sera très limitée.

Il y a déjà de multiples outils libres adaptés à la création de jeux, depuis les innombrables moteurs jusqu'aux logiciels graphiques, audio, etc. De plus, une des caractéristiques du développement vidéoludique indé c'est qu'il est tout à fait courant de développer soi-même ses petits outils et moteurs ad-hocs, donc la présence de technos libres n'est même pas indispensable.

Ce qui manque au jeu libre c'est tout le reste: les créatifs bien sûr (ce qui inclus la conception de gameplay, qui est un art en soi), mais aussi des équipes stables, avec une direction claire. Peut-être aussi un modèle de distribution qui puisse permettre à ceux qui le désirent d'essayer d'en vivre.

Une autre façon d'aborder le problème serait de promouvoir un modèle à la ID software, avec une libération d'un produit au bout d'un certain nombre d'années.

mais le support de flash et air pour Linux me paraît pas fiable, […] n'assurerait pas que l'on puisse y jouer dans 5 ans

Ironiquement, je pense qu'il y a une bonne chance que la pérennité des jeux en flash soit assurée grâce aux efforts open source. Qu'Adobe finisse par abandonner plus ou moins complètement sa plateforme, cela me parait inéluctable. Mais il y a eu tellement de production (parfois d'excellente qualité) faites avec, que cela ne m'étonnerait pas que dans 5 ans le seul moyen d'y accéder soit d'utiliser un moteur open source.

Ou peut-être que mon naturel optimiste me joue des tours…

Ah bah désolé pour la description manquée de Botanicula. J'ai fait un peu vite.

Sinon, je pense quand même que la forte fréquence reste un intérêt économique (il y a tout de même beaucoup de redondance entre chaque bundle).

Je m'aperçois que ma réponse avait un ton assez critique, ce n'était pas mon intention.

Je pense que s'ils voulaient maximiser leurs gains, ils espaceraient au contraire les bundles, pour garder l'enthousiasme des acheteurs à son maximum. Le modèle repose en grande partie sur l'achat impulsif, et l'effet nouveauté/rareté joue beaucoup là dessus.

Je pense sincèrement que l'équipe derrière le Bundle cherche à amener le maximum de jeux indés à un public aussi large que possible.

D'autre part, la redondance entre les bundles n'est problématique que si l'objectif est de vendre chaque itération à tout le monde. Si au contraire l'idée est de proposer une nouvelle forme de distribution, la redondance prend tout son sens: l'acheteur choisi quel pack l'intéresse. Personnellement j'aimerai qu'ils assouplissent la limite de temps, je pense que le modèle fonctionnerait même sans date butoir.

Il est vrai que la fréquence a largement augmentée, probablement pour des raisons financières.

Ça m'étonnerait beaucoup que ce soit pour cela, vu que ça a plutôt l'effet inverse (lassitude chez les acheteurs potentiels), et que de toute façon, au dernière nouvelles la structure organisatrice se porte incroyablement bien.

Je pense plutôt que c'est l'abondance incroyable de jeux indés de qualité, couplée à la concurrence d'autres bundles similaires, qui pousse à cette fréquence importante.

De fait, j'ai l'impression que le "bundle à prix variable" est en train de devenir un mode de distribution à part entière. Si la quantité continue à augmenter, cela pourra être une bonne chose pour les petits studios. Bien sûr chaque bundle vendrait moins, mais plus de monde pourrait en bénéficier.

Au passage, Botanicula n'est absolument pas un jeu de plateforme, et pas vraiment non plus d'aventure. C'est un pur jeu "point and click", d'exploration, de petits puzzles et d'admiration: une petite perle où tous les détails ont été peaufinés, ne laissez pas les choix techniques malencontrueux vous priver d'un plaisir aussi réussi.

Le problème c'est que lorsqu'il y a des règles de précédences plus complexes que celles de Go, d'après mon expérience chaque programmeur en retient une partie différente, et relire le code d'autrui peut devenir problématique.

Je me suis souvent retrouvé à rajouter des parenthèses que je savais inutiles dans mon code, parce que je savais que telle ou telle précédence n'est généralement pas connue (l’opérateur ternaire me vient à l'esprit, notamment).

Si tu connais par cœur l'ensemble des règles de précédence de C, alors crois-moi, tu es une exception. Je préfère de très loin avoir des règles moins fournies mais faciles à retenir.

Je suis d'accord en ce qui concerne les tableaux et les identifiants unicode, ce ne sont pas des choix très heureux.

Par contre, pour avoir codé un peu en Lua, je suis fan de l'absence de parenthèses dans les if, et de l'absence de point virgule en fin de ligne. Ça rend le code beaucoup moins chargé, on peut se concentrer sur l'essentiel plutôt que d'avoir à filtrer mentalement tous les caractères superflus.

Je ne vois pas du tout quel est le problème avec la précédence tes opérateurs? Elle me semble parfaitement saine et classique:

    5             *  /  %  <<  >>  &  &^
    4             +  -  |  ^
    3             ==  !=  <  <=  >  >=
    2             &&
    1             ||

Après, je n'ai pas essayé de coder en Go, peut-être ai-je loupé quelque chose?

Oui, c'est bien de la position du type par rapport à la variable dont je parle.

Il est clair qu'on a (presque) tous l'habitude de lire les types C, mais qui n'a jamais froncé les sourcils devant un mélange de pointeurs/références savamment imbriqués à l'aide de parenthèses? Les pointeurs de fonctions, notamment, sont la plupart du temps complexes à lire.

mais je crois que je ne coderai jamais en Go tellement il y a de choses que je n'aime pas, notamment dans la syntaxe.

Moi c'est exactement l'inverse, il y a pas mal de chose que j'aime, notamment au niveau de la syntaxe.

Enfin un descendant de C qui se départit des maladresses de son aïeul, notamment la notation des types "à l'envers" qui a introduit tout un tas d’ambiguïtés dès que les types se sont un peu compliqués. L'omission des parenthèses pour les if et consorts clarifie aussi le code, même s'il demande un petit temps d'adaptation.

En fait, la seule chose qui me retient de coder en Go, c'est que j'ai beaucoup de mal à croire en son avenir… Peut-être trouvera-t-il sa place dans quelques domaines, mais je le vois mal remplacer C comme langage bas niveau universel.

je comprend toujours pas de nos jours l'utilité de vendre des ordis avec plus de 2Go

Pour du montage vidéo, certains jeux, certains travaux graphiques, de la MAO… (et aussi pour l'utiliser en ramdisk et grapiller quelques millisecondes aux lancements d'applis, mais c'est une autre catégorie d'utilisateur…)

Ce qui sont des usages de plus en plus répandus. Pas au point d'en refourguer à tous les clients, on est d'accord.

Il est clair qu'il y a une grande confusion entre "c'est comme ça qu'il faut faire", et "faire comme cela peut apporter tel avantage".

Par exemple pour cette histoire de return, il est évident qu'il y a plein de situations où il est plus clair de n'avoir qu'un point de retour en fin de fonction. Il est important qu'un nouveau programmeur apprenne cela, mais aussi de ne pas en faire une règle à suivre.

En fait, je crois que l'élément le plus sous-estimé de l'apprentissage de la programmation, c'est la lecture de code. AMHA Il n'y a rien de plus enrichissant et de plus formateur que de lire (et comprendre ^ ^) du code bien écrit.