GuieA_7 a écrit 675 commentaires

OK merci pour ta réponse ; c'est bien de voir que d'autres architectures sont envisagées, malgré l'omniprésence du x86 sur les ordinateurs de joueurs, là tout de suite.

Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL

Passer par un IL permettrait à terme de supporter plus facilement d'autres architecture processeur j'imagine. Après, ça ne fait peut être pas partie des priorités du projet (avec la montée des ARM au niveau du grand public ça le deviendra peut-être).

En tout cas merci pour toutes ces belles informations, c'est toujours un plaisir d'avoir un retour de développeur.

Toutafé, c'était un abus de langage de ma part. Pour aller plus loin, on peut même dire que pour monter une boîte, une bande de parfaits incompétents (en technique comme en gestion) suffit ; la faire vivre et prospérer (honnêtement en tout cas) sera plus difficile.

Après niveau compétences c'est totalement indépendant de la formation, surtout a Epitech !

C'est partout pareil, ça n'a rien de spécifique à Epitech. J'ai moi aussi des anecdotes de gens en fin de 3ème année incapables de faire une struct en C ou copiant sans vergogne (ni finesse) le code d'autres élèves, quand d'autres montent leur boite à la sortie de l'école.

C'est ma définition, elle vaut ce qu'elle vaut, mais pour moi un code propre est un code dépourvu de ce genre d'horreur :

• des noms de variable/fonction/classe incongrus.
• des fonctions de 5000 lignes avec 40 niveaux de profondeurs, des gotos utilisés n'importe comment, des tonnes de variables globales.
• du copié/collé à tout va.
• pas de style de programmation respecté : une mauvaise indentation, des conventions de nommage à géométrie variable, etc…
• et toute une infinité de cochonneries qu'on pourrait inventer.

N'importe codeur rigoureux et consciencieux peut donc faire du code propre. Mais ledit code peut quand même avoir une mauvaise conception, être lourd et inefficace etc…, et donc être mauvais.

"set([])" peut être écrit simplement "set()". En fait, pour aller plus loin :

[...]
  subjects = set([])
  g = Graph()
  g.parse(rdf, format=fmt)
  for subject in g.subjects() :
    subjects.add(subject)

  for subject in sorted(subjects) :
  [...]

pourrait être plus court:

[...]
  g = Graph()
  g.parse(rdf, format=fmt)

  for subject in sorted(set(g.subjects())) :
  [...]

OK, merci pour ta réponse ; je comprends mieux et je suis bien d'accord (vu mon activité ça semble évident).

tu fais passer le message "un éditeur ne peut pas faire de libre"

Désolé si je n'ai pas été clair, mais en me présentant comme un éditeur de logiciel libre, je ne pensais pas que c'est le message qui passerait.

tu as sans doute loupé http://linuxfr.org/news/lisez-en-liberte-avec-teabook-open-reader

En effet, malgré mon assiduité sur LinuxFr je n'avais pas lu cette intéressante dépêche. Mais sauf si j'ai loupé un truc :
- le modèle de TEA est un subtile mélange de mes points 1 & 3 (et c'est bien), ce qui ne remet pas en cause en ma conception du business autour du libre.
- l'expression "à licence" n'était pas très claire ; avec le recul j'imagine que ça s'opposait juste à "logiciel développé pour un client et auquel on cède le copyright". Désolé si tout le monde avait compris ça sauf moi.

Je remets la citation initiale

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Alors j'ai peut-être mal interprété le "sous licence" (qui ne veut pas dire grand chose au final), mais je l'ai interprété comme "licence payante". Et je n'ai peut être pas saisi ce que tu voulais dire, mais j'ai l'impression que tu dis la même chose que moi. Dans tes exemples, je vois des boites qui gagnent de l'argent grâce :

1. aux services autour de leur produit (services payants, pas la licence).
2. à la vente de versions propriétaires bâties au dessus de leur version libre (d'où ma remarque sur un produit pas entièrement libre, c'est bien le propriétaire qui rapporte de l'argent au final)
3. à leur activité principale, pas lié à ce logiciel, mais qui est libéré gracieusement (ce qui est très bien hein).

Donc CrEv n'a l'air de parler ni de 1 ni de 3, et 2 n'est pas entièrement libre, ce que je disais.

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Dommage que ton modèle soit incompatible avec la création de logiciels libres (ou du moins entièrement libres, certaines briques pourraient l'être). J'ai cela dit déjà entendu parlé de boites faisant des logiciels libres, mais qu'elles ne distribuaient (et donc leurs sources) qu'à leurs clients ; ce système ne marche qu'avec des logiciel de niche je dirais. En tout cas c'est assez éloigné de ma vision idéale de diffusion de la connaissance ; après ce n'est pas le but de tous les libristes, j'en suis conscient.

En tant qu'éditeur de logiciel libre, je pense arriver à combiner:
- une vison produit 'originale', pas une commande bizarre de la part d'un seul client (même si cette vision est amené a évoluée en fonction des retours des utilisateurs, heureusement).
- du service (développement, formation, déploiement, hébergement, conseil…), rémunérateur.

Je suis même régulièrement amené à sortir du cadre de l'informatique pure, genre préparation d'un stand sur un salon (banderole, goodies …) ; ça ne fait pas de moi un meilleur programmeur mais c'est intéressant aussi (pour aller dans ton sens de l'ouverture d'esprit).

Coté univers et aspect graphique, le coté retro de Nikki me touche et me plaît beaucoup, je me doute que ça ne fonctionne pas pour tout le monde, mais moi j'aime bien le retro/pixelisé/8bit assumé.

J'ai des goûts éclectiques (même si j'ai un faible pour la 3D "cell shadée"), et les graphismes rétro savent toucher le vieux joueur que je suis : SuperMeatBoy, Fez, JamesTown, Megaman 9… J'avais bien aimé Frogatto, dont le moteur est libre (je crois qu'il y a un éditeur aussi).

D'ailleurs je n'ai pas critiqué les graphismes de Nikki. Le sprite du personnage est sympa en effet ; après la direction artistique n'est pas bien profonde non plus.

Je pense depuis longtemps que vendre des jeux vidéos dont le code (moteur) serait libre, et les données propriétaires, serait tout à fait viable. Le succès des Indie Bundles, dépourvu de DRM le prouve : ils sont facilement piratables (puisque pas de protection), pourtant dans l'ensemble les gens sont prêts à payer pour de bons jeux. Que le moteur 'nu' soit libre n'y changerait donc rien.

Autant sur des logiciels classiques, à la durée de vie longue, la liberté du code a prouvé ses avantages du point de vue technique, autant sur les jeux tout reste à faire pour convaincre les créateurs. Les joueurs se tapent de la liberté du code et ne vont donc pas boycotter les jeux propriétaires. Il faut donc compter sur de rares créateurs de jeux sensibles au libre pour essayer de démonter que ça apporte quelque chose financièrement (si c'est le cas), car le fait que ça ne coûte rien de libérer ne suffit pas à motiver il faut croire (mais les mentalités peuvent évoluer).

C'est donc vraiment enthousiaste que j'ai accueilli Nikki and the Robots. Le business model me semblait proche de la perfection : un jeu libre complet (code et données), et des données payantes supplémentaires (pour moi la perfection serait de libérer toutes les données à un certain moment, mais je chipote). Mais voilà, c'est là que le bât blesse : le jeu me parait très faible. Je n'ai testé que les niveaux libres, mais ils sont censés me donner envie d'acheter le reste, et ce n'est vraiment pas le cas (malheureusement) : je ne me suis pas amusé, le principe de base n'est pas bien folichon, et le game design, qui aurait pu rattraper cet état de fait, n'est pas du tout inspiré . Peut être que ce n'est pas le cas des niveaux payants, non faits par les joueurs, mais dans ce cas il aurait fallu en libérer quelques uns pour montrer ce que le jeu a dans le ventre.

Donc je suis le premier à le déplorer, parce que l'intention derrière ce jeu est très sympathique, mais dire qu'un jeu très médiocre ne s'est pas bien vendu ne permet pas de dire que c'est la faute du business model. Notez bien que des jeux médiocres peuvent très bien se vendre (pub toussa), et de très bons ne pas trouver leur public ; mais rien à voir avec la licence.

Aux alentours de 2004 (oui c'est loin), dans ma boite on s'est beaucoup intéressé aux moteurs 3D libres. On a du passé la plupart en revue ; aucun d'eux n'étaient parfait évidemment, mais en gros seul Ogre était dénué de grosse lacune rédhibitoire, notamment grâce à son approche généraliste très versatile. Presque 10 ans après, la plupart de ces moteurs ont périclité et ont fini dans l'oubli, alors que de son côté le développement de Ogre est très actif.
Il est notamment utilisé dans le très bon TorchLignt (qu'on retrouve dans le dernier Indie Bundle) et TorchLight2 qui vient de sortir (et recueille lui aussi de très bonnes critiques). Je ne sais pas si d'autres moteurs 3D libres sont utilisés dans des jeux commerciaux à succès (j'exclue les moteurs de Id Software, qui deviennent libres bien après leur succès).
Une autre chose appréciable est que Ogre a toujours eu un script d'export pour Blender de qualité ; mais je ne sais pas si c'est vrai depuis Blender 2.50+.
Je pense que Ogre est très populaire, et ça explique sûrement aussi beaucoup le nombre de critiques qu'on va trouver sur lui (parce il est utilisé par plein de monde ; les moteurs inconnus au bataillon, personne ne va les critiquer). Ce qui ne veut pas dire qu'il est exempt de défaut, ou que les critiques sont infondées. J'imagine que son approche généraliste fait qu'il est surement bien moins bon qu'un moteur spécial FPS si on veut faire un FPS par exemple.

PS: je serai vraiment curieux de voir émerger un moteur 3D (libre) en Go, ça serait intéressant je pense.

Resident Evil (une femme, dans le jeu vidéo ce n'était pas le cas)

Pas du tout ; rien que dans le 1er épisode du jeu tu peux jouer une femme (Jill Valentine) ou un homme (Chris Redfield), et avoir 2 aventures un peu différentes. Et puis les films Resident Evil c'est de la bonne grosse merde, tu aurais pu prendre un autre exemple :) (y a plein d'héroïnes mémorables dans les films de Ghibli)

Wikipedia indique sur la page du jeu que le code source a été libéré en 2011 ; la révision relative à cette annonce date du 23 Mars 2012. Donc ça date un peu, mais ça n'est pas un preuve très solide non plus. De son côté le site de Pandemic est fermé depuis 2009, et celui d'Activision pas bien intéressant.

Ok merci pour ta réponse.

Wait and see…

C'est toi qui as des doutes ou tu as lu des trucs là dessus (c'est une vraie question) ?

Sierra et/ou Valve libére le code de Won (même si c'est obselete maintenant) ? Douteux

Si j'ai bien compris, ce qui as été libéré c'est juste le client, c'est pour ça que le multijoueur ne fonctionne pas.

les fichiers commencent toujours par un header proprio (Copyright 1997-1999 Pandemic Studios, Dark Reign II)

Ce n'est pas spécialement un header proprio ; même dans un code libre les différents fichiers peuvent avoir un copyright différent, mais tous placés sous une même licence (pas forcément répétée dans tous les headers).

les assets sous forme d'archive compressé
aucune modification depuis 2011

En effet l'effort pour rendre la libération propre n'a peut être pas été suffisant.

Bon j'ai vu la news passer sur slashdot (et j'ai un peu regardé histoire de faire un eu plus qu'un journal bookmark), donc Activision l'a surement vu passer. Ce ne sont pas des tendres et les choses devraient être mise au clair rapidement. J'espère que cette libération n'était pas du flan.

Rah mais quel boulet je n'ai pas relu mon titre : s/Drak/Dark
Si un gentil modo pouvait corriger. Merci d'avance.

Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à if !('id' in plop), et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.

unless 'id' in plop
# …

En python on pourra certes l'écrire comme ça :

if not 'id' in plop:
  # ...

mais aussi comme ça :

if 'id' not in plop:
  # ...

qui me semble assez proche de ton envie d'expressivité, et sans ajouter de mot clé.

s/immuable/immuables/ :)

J'ai fait mon Jean-Claude Van Damme, mais j'ai préféré utiliser le terme anglais pour éviter les confusions (d'où les guillemets et le non accord).

Ça doit même être dans le tutoriel de Guido Van Rossum (je regarderai). C'est pourquoi il est conseillé de toujours utiliser des objets "immutable" en tant que valeur par défaut. Quand je forme des débutants, je présente ça comme un écueil classique.

Merci de sourcer à ma place ! :)

Personnellement, je dirais que le management ne l'a probablement pas entendu de cette oreille

Oui c'est exactement ce que je pense ; tout Michel Ancel qu'il est, il ne fait pas tout ce qu'il veut (et puis à quel point était-il à fond derrière cette libération, difficile a savoir). Dommage, vraiment dommage.

D'ailleurs à propos de Rayman Origins, Michel Ancel (son créateur) avait dit dans une interview l'année dernière qu'il envisageait de libérer le moteur du jeu (et les outils associés me semble-t-il). Ça me ferait bien fait plaisir (c'est un moteur 2D utilisant efficacement les cartes graphiques modernes), et c'était très étonnant de la part d'Ubisoft. Malheureusement pour le moment j'ai eu raison de ne pas m'emballer parce que rien à l'horizon à ma connaissance.

En plus il y a une petite typo :
tampon de buffer hiérarchique -> tampon de profondeur hiérarchique