J'avais fait une présentation de Plee the Bear aux RMLL de 2009 et nous avions un stand à celle de 2010. La présentation n'était pas une expérience particulièrement utile mais je conseille aux créateurs de jeux de demander un stand. C'est très intéressant et efficace de voir les gens jouer à votre jeu en face de vous et de voir leurs réactions. Ça avait aussi été pour nous l'occasion d'ajouter plein de trucs au jeu, notamment un mini-jeu de combat à deux joueurs. C'était très amusant.
Le résultat de Pack My Sprites est un ou plusieurs png contenant les petites images, complètement indépendantes de l'outil qui les charge par la suite. Il faut juste que ce dernier sache prendre une sous partie de l'image pour retrouver le sprite. Le fichier .spritepos permet de retrouver les positions et les tailles des sprites.
À ma connaissance il n'y a pas de difficulté à utiliser ces png en CSS. Il faut voir comment intégrer le .spritepos pour sélectionner la bonne partie de l'image.
Vu le jeu que tu produis, je suis surpris que tu trouves ça tant mieux. SMC reprends les mécanismes de Mario, mais aussi les graphismes, et les musiques. Pour moi ce n'est pas plus intéressant que de reprendre directement une ROM du jeu.
SuperTux fait aussi du Mario mais a le bon goût de n'en reprendre que les mécanismes ; les graphismes et les musiques sont a eux. Je trouve que ça le rend déjà bien plus intéressant.
Pareil pour Warmux ou Hedgewar. C'est du Worms dans la mécanique mais l'univers est à eux.
Il y a une vraie différence entre faire des jeux libres qui reprennent des mécanismes d'autres jeux et faire un clone. Personnellement je ne trouve pas que SMC soit très bon, je le trouve plutôt fade.
Attention, ici on parle clone, pas de contrefaçon :)
Blague à part, je comprends ta remarque. Super Maryo Chronicles, anciennement Super Mario Clone, a le même problème que d'autres jeux libres : c'est avant tout un clone d'un autre jeu, sans personnalité.
Il me semble que le projet a changé d'orientation avec le temps pour devenir un Maryo pas tout à fait Mario et qu'il y a eu un effort pour se distinguer graphiquement, qui n'a pas abouti. OpenSonic a suivi un peu le même chemin mais a l'air encore vivant.
Dans le genre Mario en libre, SuperTux est un bon représentant aussi. Il me semble qu'ils s'étaient démarqués dès le début en ne reprenant pas les graphismes (ils sont partis sur un truc avec un manchot, rapport à Linux et au libre. Vous voyez le truc ?) Par contre l'histoire est la même que dans le Mario Nes (sa meuf s'est faite enlever).
Bref, ça a certes l'air d'un Mario du pauvre mais comme on dit d'habitude : il ne tient qu'à toi de contribuer pour en faire un projet original…
Ou alors tu peux contribuer a un projet qui est déjà original.
Ou alors tu peux t'en moquer parce que tu veux seulement jouer :)
Je ne connais pas de telle fonctionnalité dans GIMP, alors pour ma part j'utilise le décalage de calque Ctrl+Shift+O pour gérer les raccords. C'est loin d'être satisfaisant car je n'ai pas de vue globale et en plus j'ai besoin d'être raccord avec une inversion horizontale et verticale de l'image.
Je te rejoins complètement sur le fait que Xcftools prend une direction peu fiable en implémentant le format XCF hors de Gimp. Je comptais plutôt sur la libgimp dans l'avenir, sans m'être penché dessus encore. As tu des détails sur ce qui empêche la libgimp d'être utilisé hors de Gimp ? Qu'attend-elle de l'application qui la charge ?
Au sujet des fonctionnalités, le seul outil qui m'intéresse dans Xcftools est xcfinfo. Pour tout ce qui concerne les opérations sur l'image j'utilise des scripts Scheme que je passe à gimp-console. Du coup ton outil me conviendrait bien à ceci près que j'aimerais que cela fonctionne sous Windows. J'ai commencé à migrer Xcftools pour pouvoir livrer une version Windows mais ça me semble plus difficile avec ton outil qui utilise des scripts shell.
Je migre le journal dans l'espace de rédaction. Es-tu intéressé pour y présenter xcf-utils ?
En fait je n'étais pas certain que cette présentation des outils, plutôt centrée sur mon propre intérêt, soit opportune en dépêche.
Cependant je veux bien refaire un tour par l'espace de rédaction si ça vous semble pertinent. D'autres — comme Jehan ci-dessous — pourrons y ajouter leurs outils :)
Du coup, j'hésite. J'ai peur d'être ridicule en releasant en l'état une version imparfaite. Peur que le logiciel n'intéresse personne, qu'on me dise que ça ne sert à rien ou que ça existe déjà en mieux ailleurs. Ça vous est déjà arrivé ce genre d'angoisse ? Vous faites quoi dans ce genre de cas ?
Dans ce cas je commence par clore les fonctionnalités en désactivant ou en finissant vite fait ce qui est entamé. Puis je sors quand même une version.
La sortie d'une version ne t'apportera que du positif : tu vas faire l'effort d'en parler, tu vas avoir des commentaires en retour, des gens qui vont te trouver des problèmes que tu n'aurais pas trouvé tout seul, tu auras quelques patches, éventuellement des contributions, etc. Peut-être que tu sortiras un correctif moins d'un mois après. Peut-être qu'on te dira que ça existe déjà en mieux, et tu trouveras des raisons de faire de ton produit quelque chose de différent.
Dans tous les cas tu auras avancé vers quelque chose de meilleur.
En effet sa serait super cool. Comme Gimp sait lire ce format et que Pack My Sprites lui délègue complètement la composition de l'image finale, il suffirait d'un outil équivalent à xcfinfo pour OpenRaster (orainfo ?) afin de pouvoir extraire l'information des calques du fichier et l'utiliser dans Pack My Sprites.
Je ne pense pas que « contribuer » soit le bon terme ici. Ce que tu décris s'apparente plus à une démarche de production et diffusion : je fais un truc et je dis au gens qu'ils peuvent le prendre. Cela n'a pas la même valeur qu'une production dédiée à un projet faisant intervenir plusieurs personnes, où la production de chacun a un sens de contribution autour du projet.
Même une production solo avec une ligne directrice diffusée sous licence libre n'a que peu d'intérêt. Si je fais et diffuse sous licence libre un jeu d'animations d'extra-terrestres, ou un ensemble de décors type médiéval fantastique, c'est bien pour le libre : pour observer ou étudier, pour diffuser. Mais de là à ce que ça soit utilisable dans un jeu de manière cohérente avec des productions de tiers et qu'il n'y ait pas de demande spécifiques à ajouter, il y a beaucoup de chemin.
Le graphisme et la musique libres demandent vraiment une approche différente du code libre. C'est intéressant de faire un bout de code dans son coin pour résoudre un problème et de le diffuser. Cela fait une bibliothèque que les gens reprennent dans leurs projets, qu'ils améliorent et corrigent. Faire une collection de musiques ou de dessins dans son coin, par pure désir créatif, et le diffuser, ça a avant tout un intérêt culturel ; ça n'a certainement pas la même valeur de réutilisation. Cela va rester une œuvre isolée, sûrement intéressante, mais certainement non intégrable avec un projet tiers.
Je me permet de donner mon avis sur l'intervention de graphistes sur les projets, suite à l'expérience que j'ai avec Plee the Bear et Andy's Super Great Park (bientôt en version générique pour Linux !)
La question « pourquoi les graphistes ne s'investissent pas ? » revient souvent dans les jeux libres. On a tendance a regarder les programmeurs, on voit que c'est plutôt facile d'en trouver, qu'ils sont plutôt contents de bricoler le code, et on se demande pourquoi les graphistes (et musiciens, allons-y) ne sont pas pareils. La réponse est simple, c'est parce que ce sont des métiers très différents.
Sur Plee the Bear je faisais beaucoup de code et de dessins, sur Andy's Super Great Park je me suis concentré sur les dessins et mes contributions au code n'étaient que des petits outils et des corrections de bugs dans le moteur. Je vous assure que l'approche n'a rien a voir.
Quand je produis du code je me cale un petit laps de temps pour implémenter et tester. Je fait ça seul, je livre et c'est terminé, on n'en parle plus. Éventuellement il faudra faire quelques corrections de bugs, mais ce n'est pas bloquant.
Quand je fais du graphisme je me cale un petit laps de temps pour produire quelques brouillons dans Gimp. Puis je décris les feuilles de sprites et je les génère. Puis je construit les animations et les modèles de personnages avec les sprites. Selon le cas je dis au développeur ou au level designer que le brouillon visuel est prêt et qu'il peut l'attacher au code du personnage ou le mettre dans les niveaux. À partir de là je commence à finaliser les dessins pour avoir un truc joli. Je continue à bosser dans Gimp, je régénère les feuilles de sprites et parfois je dois réajuster les animations, les modèles ou les niveaux.
En bref, quand je code je peux travailler indépendamment des autres. Quand je fais du graphisme je deviens bloquant et perturbant pour le développeur et le concepteur des niveaux. Et encore je veux bien faire des animations et des modèles. Un autre graphiste pourra rechigner à aller au delà de la production des dessins. Même la production des feuilles de sprites à partir des images sources est déjà une contrainte technique.
Ensuite il y a le problème de la cohérence graphique. La plupart des graphistes n'accepteront pas de ne faire qu'une partie des dessins ; ils voudront s'occuper intégralement d'une partie cohérente du jeu (tous les persos, ou tous les décors, ou toute l'interface). Ce n'est pas qu'une histoire d'égo, c'est juste que c'est très difficile d'avoir un style cohérent sur plusieurs graphistes et que chacun a envie de pratiquer. Certains vont faire du bitmap, d'autres préfèrent le pixel art, d'autres le style manga, etc. Même en restant dans le même style, les détails font la différence (les expressions des persos, les formes générales). C'est bien plus contraignant que de s'accorder sur un style de programmation.
D'une manière générale, je n'ai pas de réticence à proposer un patch pour un programme que j'utilise et dans lequel je vois un manque ou un problème. Ça me coûte entre deux heures et deux jours de travail, au bout desquels j'envoie un patch ; puis je n'ai plus à m'en occuper. Comment pourrais-je avoir le même confort sur de la production graphique ? Je ne me vois pas prendre un seul perso, une seule texture, la modifier et l'envoyer aux auteurs du jeu en leur disant « tiens, je trouvais ça moche alors je t'ai fait un dessin. Mais je ne fais pas les autres persos/textures ». Le résultat serait juste un dessins d'une qualité différente qui ferait tout autant tâche au milieu du reste.
Quand bien même je le ferais, est-ce que c'est intéressant pour l'auteur du programme ? Quand vous recevez un patch qui ne vous convient pas, vous le corrigez ou vous demandez directement à l'auteur de le corriger en lui disant clairement ce qui ne va pas (un bug, un problème de style). Mais avez-vous déjà essayé de faire modifier un dessin ou une musique ? Les critiques sur ces productions commencent souvent par des trucs aussi vagues que « c'est bien mais ça ne va pas avec le reste » ou « je trouve que ça manque de fun ». Il y a aussi les critiques apparemment anodines mais qui impliquent de quasiment tout refaire : « j'aime bien l'expression du bonhomme, mais est-ce qu'il pourrait porter une armure et un glaive, et être blond ? ». C'est très difficile de tomber d'accord sur un visuel avant les premières ébauches, et les modifications qui suivent sont aussi difficiles à exprimer que coûteuse à corriger.
TL ; DR : pour résumer, si vous voulez des artistes sur votre projet, comprenez que :
- la communication est longue, coûteuse et pénible ;
- les métiers sont différents, les approches aussi ;
- un screenshot est une œuvre du graphiste, pas des programmeurs ;
- une vidéo est une œuvre du graphiste et de l'animateur, éventuellement du musicien, à peine des programmeurs ;
- laissez la liberté aux graphistes de s'approprier toute l'apparence ;
- laissez la liberté aux musiciens de s'approprier l'ambiance ;
- ôtez les contraintes techniques aux artistes ;
- ayez un planning et une date limite.
Je reviens un peu tard dans la discussion car je n'ai pas trouvé comment vous contacter autrement. Nous avons une version candidate pour Linux qui pourrait fonctionner hors Ubuntu ; elle s'est notamment lancée sur Debian et Fedora. Elle est disponible sur la page de téléchagement des démos. Si vous l'essayez je serais intéressé de savoir si cela a bien fonctionné ou pas.
Je ne peux pas dire pourquoi la dépêche a été acceptée mais je peux dire pourquoi je l'ai proposée :
Le jeu est traduit en français et nous sommes une équipe nantaise. Cela fait le « FR » de LinuxFR.
Nous avons déjà produit un jeu libre, largement présenté sur LinuxFR. Nous faisons des retours d'expérience sur la création d'un jeu libre, sur l'aspect communautaire, et nous tentons d'aller plus loin dans la production de jeu (une question qui revient régulièrement sur ce site) ; en laissant de côté l'aspect libre, certes. Nous discutons avec vous du pourquoi libre ou pas et de notre expérience sur le tout libre. De plus nous présentons un produit créé uniquement avec des logiciels libres. Il n'y a pas de promesse de libération mais toute le base du jeu et les éditeurs sont toujours disponible dans l'archive source de Plee the Bear. Cela fait le « libre » de LinuxFR.
Le jeu fonctionne pour une distribution utilisant Linux et comme dit plus haut il n'y a pas de raison pour qu'il ne soit pas distribué pour d'autres, si ce n'est un coût en temps. Cela fait le « Linux » de LinuxFR.
je ne veux pas prendre le risque d'acheter un jeux qui peux ne pas fonctionner sur ma distrib Linux.
C'est pour ce genre de question qu'on distribue une démo :)
D'ailleurs pourquoi ne pas faire une version Debian ?
C'est envisagé. Le problème est que tout demande du temps, alors on ne peut pas tout faire avant de sortir le jeu sinon on ne le sortira jamais.
Pour les distributions on travaille plutôt à la demande. Je peux facilement faire des paquets pour les dérivées de Debian, modulo l'installation sur une machine virtuelle. C'est plus difficile pour les distributions à rpm, que je connais peu. Et ce serait intéressant aussi d'avoir un binaire statique.
Ensuite la compatibilité entre les versions des distributions n'est pas évidentes. La version pour Ubuntu 12.04 ne s'installe pas sur 12.10 par exemple.
Enfin le point qui m'embête le plus c'est surtout qu'à chaque mise à jour il faudra refaire des paquets pour n distributions et m architectures. Ça prend du temps à produire et à tester.
Ce que je ne comprends que plus difficilement, c'est de ne pas avoir par ailleurs une forge, pas forcément mise en avant hein, permettant à ceux souhaitant s'impliquer de participer, de profiter des bêtas, d'être acteur, de diffuser du libre, se faire connaître…
Nous avions une forge pour Plee the Bear, et un wiki, et un forum, et un devblog, et ça nous nous a beaucoup coûté et pas beaucoup aidé. Ça demande du temps pour entretenir le tout, pour contrer les spams, pour communiquer, et ça n'a pas apporté grand chose.
Nous avons fait plusieurs appels à contributions, la plupart des retours se résument à « Super jeu ! Mais pourquoi vous ne faites pas X/Y/Z autrement ? », et les quelques personnes qui tentaient de s'investir étaient perdues devant la taille du projet.
C'est clairement du temps qui aurait été mieux investi en développant le projet. Je pense donc après cette expérience qu'il vaut mieux produire un truc complet en communicant un peu dessus, puis ouvrir l'ensemble qu'une fois que des joueurs produisent des niveaux ou qu'ils expriment leur envie de voir ou modifier le jeu. En attendant, il me semble plus efficace d'être fermé.
Vous ne proposez des binaires que pour Windows et Ubuntu…
Pour l'instant ! Mais c'est vrai que lorsqu'on avait diffusé Plee, diverses personnes avaient créé des paquets pour leurs distributions. Là on va devoir tout faire tout seuls, ça va être long. C'est un point sur lequel le libre était clairement avantageux.
Je ne suis pas friand des logiciels mi-libres avec le code libre mais pas les ressources. À mon sens ça n'a plus beaucoup d'intérêt de n'avoir accès qu'au source, alors si j'en libère un bout je libère le reste avec, pour que les intéressés puissent voir comment le tout est fait, quelle taille ça fait, comment les choses s'assemblent, et décider de créer et diffuser un nouveau produit si ça les chante.
Est-ce une crainte que le jeu soit "volé/repackagé" par d'autres personnes ?
Si c'était libre je ne considérerai pas cela comme du vol. Mais pour une première création, un premier jeu complet, je préfère que les gens nous l'achètent plutôt qu'à quelqu'un d'autre.
Est-ce la crainte que personne ne paye ?
Ça ne rentre pas vraiment en compte. Je pense que quel que soit le procédé de diffusion (libre, fermé, avec ou sans drm), ceux qui ne veulent pas payer trouvent un moyen de ne pas payer.
Dans l'absolu j'aimerais bien tenter la mise en vente d'un jeu libre complet, y compris les ressources graphiques et sonores. Cependant ça ne me semble pas très sage de le faire dès nos premiers pas en tant que pro. C'est beaucoup plus simple pour nous de coller aux pratiques classiques.
Tout est en anglais car je pense que c'est la seule langue internationale. Si on sort un jeu en français, on ne parle pas à grand monde ; et je ne vois pas quel honneur cela fait à la langue. Si on le sort en anglais on parle à tout le monde. Pas seulement aux anglophones de naissance, mais bien à toutes les personnes qui utilisent l'anglais pour aller au delà de leurs frontières.
Éventuellement nous pourrions proposer la page web en français, comme nous l'avions fait pour Plee the Bear. Ça nous demande plus de travail, plus de maintenance, plus de complications. Ce n'est clairement pas une priorité dans le planning de finalisation et de sortie du jeu.
Néanmoins, vous aurez remarqué que les dialogues du jeu sont traduits en français.
C'est très simple. Nous sommes deux individus à avoir produit le code et nous autorisons notre société à l'utiliser sous une licence non libre. Cela n'est possible uniquement parce que nous sommes les seuls auteurs, à quelques patches près. Si quelqu'un d'externe contribuait significativement au code de Plee the Bear, nous n'aurions pas pu utiliser ses contributions.
Il interprète le h comme un indicateur de valeur hexadécimal : 4000 en base 16 correspond à 16384 en base 10. D'où sort cette notation ? Aucune idée, je connais les préfixes 0x, le # et &H mais le suffixe h ne me dit rien.
Justement j'ai du mal à en trouver. Tu as quelques noms ? J'ai bien quelques trucs pour des boutiques complètes, avec gestion du panier etc. mais je n'ai rien vu de plus léger (nous n'avons qu'un produit pour l'instant).
Ensuite je ne sais pas trop comment gérer le lien de téléchargement. Je me dis que je ne pourrais pas empêcher l'utilisateur de filer le lien à quelqu'un d'autre, ou de le mettre quelque part en ligne, alors finalement pourquoi mettre un système compliqué.
J'ai oublié d'indiquer que je cherchais un outil libre aussi. J'aimerais bien regarder comment c'est fait.
# Demandez un stand
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Des jeux vidéo aux RMLL ?. Évalué à 6.
J'avais fait une présentation de Plee the Bear aux RMLL de 2009 et nous avions un stand à celle de 2010. La présentation n'était pas une expérience particulièrement utile mais je conseille aux créateurs de jeux de demander un stand. C'est très intéressant et efficace de voir les gens jouer à votre jeu en face de vous et de voir leurs réactions. Ça avait aussi été pour nous l'occasion d'ajouter plein de trucs au jeu, notamment un mini-jeu de combat à deux joueurs. C'était très amusant.
[^] # Re: Pour le Web
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Écosystème Logiciel de GIMP. Évalué à 3.
Le résultat de Pack My Sprites est un ou plusieurs png contenant les petites images, complètement indépendantes de l'outil qui les charge par la suite. Il faut juste que ce dernier sache prendre une sous partie de l'image pour retrouver le sprite. Le fichier .spritepos permet de retrouver les positions et les tailles des sprites.
À ma connaissance il n'y a pas de difficulté à utiliser ces png en CSS. Il faut voir comment intégrer le .spritepos pour sélectionner la bonne partie de l'image.
[^] # Re:Contrefaçon
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Secret Maryo Chronicle, 10 ans déjà !. Évalué à 7.
Vu le jeu que tu produis, je suis surpris que tu trouves ça tant mieux. SMC reprends les mécanismes de Mario, mais aussi les graphismes, et les musiques. Pour moi ce n'est pas plus intéressant que de reprendre directement une ROM du jeu.
SuperTux fait aussi du Mario mais a le bon goût de n'en reprendre que les mécanismes ; les graphismes et les musiques sont a eux. Je trouve que ça le rend déjà bien plus intéressant.
Pareil pour Warmux ou Hedgewar. C'est du Worms dans la mécanique mais l'univers est à eux.
Il y a une vraie différence entre faire des jeux libres qui reprennent des mécanismes d'autres jeux et faire un clone. Personnellement je ne trouve pas que SMC soit très bon, je le trouve plutôt fade.
[^] # Re: Contrefaçon
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Secret Maryo Chronicle, 10 ans déjà !. Évalué à 6.
Attention, ici on parle clone, pas de contrefaçon :)
Blague à part, je comprends ta remarque. Super Maryo Chronicles, anciennement Super Mario Clone, a le même problème que d'autres jeux libres : c'est avant tout un clone d'un autre jeu, sans personnalité.
Il me semble que le projet a changé d'orientation avec le temps pour devenir un Maryo pas tout à fait Mario et qu'il y a eu un effort pour se distinguer graphiquement, qui n'a pas abouti. OpenSonic a suivi un peu le même chemin mais a l'air encore vivant.
Dans le genre Mario en libre, SuperTux est un bon représentant aussi. Il me semble qu'ils s'étaient démarqués dès le début en ne reprenant pas les graphismes (ils sont partis sur un truc avec un manchot, rapport à Linux et au libre. Vous voyez le truc ?) Par contre l'histoire est la même que dans le Mario Nes (sa meuf s'est faite enlever).
Bref, ça a certes l'air d'un Mario du pauvre mais comme on dit d'habitude : il ne tient qu'à toi de contribuer pour en faire un projet original…
Ou alors tu peux contribuer a un projet qui est déjà original.
Ou alors tu peux t'en moquer parce que tu veux seulement jouer :)
[^] # Re: Vue pour texture ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Écosystème Logiciel de GIMP. Évalué à 2.
Je ne connais pas de telle fonctionnalité dans GIMP, alors pour ma part j'utilise le décalage de calque Ctrl+Shift+O pour gérer les raccords. C'est loin d'être satisfaisant car je n'ai pas de vue globale et en plus j'ai besoin d'être raccord avec une inversion horizontale et verticale de l'image.
[^] # Re: xcf-utils
Posté par Julien Jorge (site web personnel) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 1.
Je te rejoins complètement sur le fait que Xcftools prend une direction peu fiable en implémentant le format XCF hors de Gimp. Je comptais plutôt sur la libgimp dans l'avenir, sans m'être penché dessus encore. As tu des détails sur ce qui empêche la libgimp d'être utilisé hors de Gimp ? Qu'attend-elle de l'application qui la charge ?
Au sujet des fonctionnalités, le seul outil qui m'intéresse dans Xcftools est xcfinfo. Pour tout ce qui concerne les opérations sur l'image j'utilise des scripts Scheme que je passe à gimp-console. Du coup ton outil me conviendrait bien à ceci près que j'aimerais que cela fonctionne sous Windows. J'ai commencé à migrer Xcftools pour pouvoir livrer une version Windows mais ça me semble plus difficile avec ton outil qui utilise des scripts shell.
Je migre le journal dans l'espace de rédaction. Es-tu intéressé pour y présenter xcf-utils ?
[^] # Re: Je devrais pas mais tant pis
Posté par Julien Jorge (site web personnel) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 1.
En fait je n'étais pas certain que cette présentation des outils, plutôt centrée sur mon propre intérêt, soit opportune en dépêche.
Cependant je veux bien refaire un tour par l'espace de rédaction si ça vous semble pertinent. D'autres — comme Jehan ci-dessous — pourrons y ajouter leurs outils :)
# il faut se lancer
Posté par Julien Jorge (site web personnel) . En réponse au journal L'angoisse du programmeur. Évalué à 10.
Dans ce cas je commence par clore les fonctionnalités en désactivant ou en finissant vite fait ce qui est entamé. Puis je sors quand même une version.
La sortie d'une version ne t'apportera que du positif : tu vas faire l'effort d'en parler, tu vas avoir des commentaires en retour, des gens qui vont te trouver des problèmes que tu n'aurais pas trouvé tout seul, tu auras quelques patches, éventuellement des contributions, etc. Peut-être que tu sortiras un correctif moins d'un mois après. Peut-être qu'on te dira que ça existe déjà en mieux, et tu trouveras des raisons de faire de ton produit quelque chose de différent.
Dans tous les cas tu auras avancé vers quelque chose de meilleur.
[^] # Re: Je devrais pas mais tant pis
Posté par Julien Jorge (site web personnel) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 2.
Ah mince… merci IPOT !
Un modérateur voudrait-il corriger cette erreur ?
[^] # Re: OpenRaster
Posté par Julien Jorge (site web personnel) . En réponse au journal Outils autour de Gimp : Pack My Sprites et Xcftools. Évalué à 5.
En effet sa serait super cool. Comme Gimp sait lire ce format et que Pack My Sprites lui délègue complètement la composition de l'image finale, il suffirait d'un outil équivalent à xcfinfo pour OpenRaster (orainfo ?) afin de pouvoir extraire l'information des calques du fichier et l'utiliser dans Pack My Sprites.
# Plus de jeux
Posté par Julien Jorge (site web personnel) . En réponse au journal Valve sort Steam de sa phase bêta. Évalué à 6.
Excellente nouvelle. Le jeu de votre serviteur y sera disponible aussi si vous votez pour lui sur Greenlight.
(Oui j'en profite pour faire ma pub…)
Est-ce que vous savez si Steam impose des contraintes aux licences des jeux publiés ?
[^] # Re: Graphistes, musiciens et autres artistes
Posté par Julien Jorge (site web personnel) . En réponse au sondage Achèteriez-vous un jeu libre ?. Évalué à 4.
Je ne pense pas que « contribuer » soit le bon terme ici. Ce que tu décris s'apparente plus à une démarche de production et diffusion : je fais un truc et je dis au gens qu'ils peuvent le prendre. Cela n'a pas la même valeur qu'une production dédiée à un projet faisant intervenir plusieurs personnes, où la production de chacun a un sens de contribution autour du projet.
Même une production solo avec une ligne directrice diffusée sous licence libre n'a que peu d'intérêt. Si je fais et diffuse sous licence libre un jeu d'animations d'extra-terrestres, ou un ensemble de décors type médiéval fantastique, c'est bien pour le libre : pour observer ou étudier, pour diffuser. Mais de là à ce que ça soit utilisable dans un jeu de manière cohérente avec des productions de tiers et qu'il n'y ait pas de demande spécifiques à ajouter, il y a beaucoup de chemin.
Le graphisme et la musique libres demandent vraiment une approche différente du code libre. C'est intéressant de faire un bout de code dans son coin pour résoudre un problème et de le diffuser. Cela fait une bibliothèque que les gens reprennent dans leurs projets, qu'ils améliorent et corrigent. Faire une collection de musiques ou de dessins dans son coin, par pure désir créatif, et le diffuser, ça a avant tout un intérêt culturel ; ça n'a certainement pas la même valeur de réutilisation. Cela va rester une œuvre isolée, sûrement intéressante, mais certainement non intégrable avec un projet tiers.
# Graphistes, musiciens et autres artistes
Posté par Julien Jorge (site web personnel) . En réponse au sondage Achèteriez-vous un jeu libre ?. Évalué à 10.
Je me permet de donner mon avis sur l'intervention de graphistes sur les projets, suite à l'expérience que j'ai avec Plee the Bear et Andy's Super Great Park (bientôt en version générique pour Linux !)
La question « pourquoi les graphistes ne s'investissent pas ? » revient souvent dans les jeux libres. On a tendance a regarder les programmeurs, on voit que c'est plutôt facile d'en trouver, qu'ils sont plutôt contents de bricoler le code, et on se demande pourquoi les graphistes (et musiciens, allons-y) ne sont pas pareils. La réponse est simple, c'est parce que ce sont des métiers très différents.
Sur Plee the Bear je faisais beaucoup de code et de dessins, sur Andy's Super Great Park je me suis concentré sur les dessins et mes contributions au code n'étaient que des petits outils et des corrections de bugs dans le moteur. Je vous assure que l'approche n'a rien a voir.
Quand je produis du code je me cale un petit laps de temps pour implémenter et tester. Je fait ça seul, je livre et c'est terminé, on n'en parle plus. Éventuellement il faudra faire quelques corrections de bugs, mais ce n'est pas bloquant.
Quand je fais du graphisme je me cale un petit laps de temps pour produire quelques brouillons dans Gimp. Puis je décris les feuilles de sprites et je les génère. Puis je construit les animations et les modèles de personnages avec les sprites. Selon le cas je dis au développeur ou au level designer que le brouillon visuel est prêt et qu'il peut l'attacher au code du personnage ou le mettre dans les niveaux. À partir de là je commence à finaliser les dessins pour avoir un truc joli. Je continue à bosser dans Gimp, je régénère les feuilles de sprites et parfois je dois réajuster les animations, les modèles ou les niveaux.
En bref, quand je code je peux travailler indépendamment des autres. Quand je fais du graphisme je deviens bloquant et perturbant pour le développeur et le concepteur des niveaux. Et encore je veux bien faire des animations et des modèles. Un autre graphiste pourra rechigner à aller au delà de la production des dessins. Même la production des feuilles de sprites à partir des images sources est déjà une contrainte technique.
Ensuite il y a le problème de la cohérence graphique. La plupart des graphistes n'accepteront pas de ne faire qu'une partie des dessins ; ils voudront s'occuper intégralement d'une partie cohérente du jeu (tous les persos, ou tous les décors, ou toute l'interface). Ce n'est pas qu'une histoire d'égo, c'est juste que c'est très difficile d'avoir un style cohérent sur plusieurs graphistes et que chacun a envie de pratiquer. Certains vont faire du bitmap, d'autres préfèrent le pixel art, d'autres le style manga, etc. Même en restant dans le même style, les détails font la différence (les expressions des persos, les formes générales). C'est bien plus contraignant que de s'accorder sur un style de programmation.
D'une manière générale, je n'ai pas de réticence à proposer un patch pour un programme que j'utilise et dans lequel je vois un manque ou un problème. Ça me coûte entre deux heures et deux jours de travail, au bout desquels j'envoie un patch ; puis je n'ai plus à m'en occuper. Comment pourrais-je avoir le même confort sur de la production graphique ? Je ne me vois pas prendre un seul perso, une seule texture, la modifier et l'envoyer aux auteurs du jeu en leur disant « tiens, je trouvais ça moche alors je t'ai fait un dessin. Mais je ne fais pas les autres persos/textures ». Le résultat serait juste un dessins d'une qualité différente qui ferait tout autant tâche au milieu du reste.
Quand bien même je le ferais, est-ce que c'est intéressant pour l'auteur du programme ? Quand vous recevez un patch qui ne vous convient pas, vous le corrigez ou vous demandez directement à l'auteur de le corriger en lui disant clairement ce qui ne va pas (un bug, un problème de style). Mais avez-vous déjà essayé de faire modifier un dessin ou une musique ? Les critiques sur ces productions commencent souvent par des trucs aussi vagues que « c'est bien mais ça ne va pas avec le reste » ou « je trouve que ça manque de fun ». Il y a aussi les critiques apparemment anodines mais qui impliquent de quasiment tout refaire : « j'aime bien l'expression du bonhomme, mais est-ce qu'il pourrait porter une armure et un glaive, et être blond ? ». C'est très difficile de tomber d'accord sur un visuel avant les premières ébauches, et les modifications qui suivent sont aussi difficiles à exprimer que coûteuse à corriger.
TL ; DR : pour résumer, si vous voulez des artistes sur votre projet, comprenez que :
- la communication est longue, coûteuse et pénible ;
- les métiers sont différents, les approches aussi ;
- un screenshot est une œuvre du graphiste, pas des programmeurs ;
- une vidéo est une œuvre du graphiste et de l'animateur, éventuellement du musicien, à peine des programmeurs ;
- laissez la liberté aux graphistes de s'approprier toute l'apparence ;
- laissez la liberté aux musiciens de s'approprier l'ambiance ;
- ôtez les contraintes techniques aux artistes ;
- ayez un planning et une date limite.
Je vous invite à lire ce post d'un graphiste aussi.
[^] # Re: Bonne chance
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 1.
Je reviens un peu tard dans la discussion car je n'ai pas trouvé comment vous contacter autrement. Nous avons une version candidate pour Linux qui pourrait fonctionner hors Ubuntu ; elle s'est notamment lancée sur Debian et Fedora. Elle est disponible sur la page de téléchagement des démos. Si vous l'essayez je serais intéressé de savoir si cela a bien fonctionné ou pas.
[^] # Re: …
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 9.
Je ne peux pas dire pourquoi la dépêche a été acceptée mais je peux dire pourquoi je l'ai proposée :
Le jeu est traduit en français et nous sommes une équipe nantaise. Cela fait le « FR » de LinuxFR.
Nous avons déjà produit un jeu libre, largement présenté sur LinuxFR. Nous faisons des retours d'expérience sur la création d'un jeu libre, sur l'aspect communautaire, et nous tentons d'aller plus loin dans la production de jeu (une question qui revient régulièrement sur ce site) ; en laissant de côté l'aspect libre, certes. Nous discutons avec vous du pourquoi libre ou pas et de notre expérience sur le tout libre. De plus nous présentons un produit créé uniquement avec des logiciels libres. Il n'y a pas de promesse de libération mais toute le base du jeu et les éditeurs sont toujours disponible dans l'archive source de Plee the Bear. Cela fait le « libre » de LinuxFR.
Le jeu fonctionne pour une distribution utilisant Linux et comme dit plus haut il n'y a pas de raison pour qu'il ne soit pas distribué pour d'autres, si ce n'est un coût en temps. Cela fait le « Linux » de LinuxFR.
[^] # Re: Bonne chance
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 1.
C'est pour ce genre de question qu'on distribue une démo :)
C'est envisagé. Le problème est que tout demande du temps, alors on ne peut pas tout faire avant de sortir le jeu sinon on ne le sortira jamais.
Pour les distributions on travaille plutôt à la demande. Je peux facilement faire des paquets pour les dérivées de Debian, modulo l'installation sur une machine virtuelle. C'est plus difficile pour les distributions à rpm, que je connais peu. Et ce serait intéressant aussi d'avoir un binaire statique.
Ensuite la compatibilité entre les versions des distributions n'est pas évidentes. La version pour Ubuntu 12.04 ne s'installe pas sur 12.10 par exemple.
Enfin le point qui m'embête le plus c'est surtout qu'à chaque mise à jour il faudra refaire des paquets pour n distributions et m architectures. Ça prend du temps à produire et à tester.
[^] # Re: Pourquoi ce n'est pas libre ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 9.
Nous avions une forge pour Plee the Bear, et un wiki, et un forum, et un devblog, et ça nous nous a beaucoup coûté et pas beaucoup aidé. Ça demande du temps pour entretenir le tout, pour contrer les spams, pour communiquer, et ça n'a pas apporté grand chose.
Nous avons fait plusieurs appels à contributions, la plupart des retours se résument à « Super jeu ! Mais pourquoi vous ne faites pas X/Y/Z autrement ? », et les quelques personnes qui tentaient de s'investir étaient perdues devant la taille du projet.
C'est clairement du temps qui aurait été mieux investi en développant le projet. Je pense donc après cette expérience qu'il vaut mieux produire un truc complet en communicant un peu dessus, puis ouvrir l'ensemble qu'une fois que des joueurs produisent des niveaux ou qu'ils expriment leur envie de voir ou modifier le jeu. En attendant, il me semble plus efficace d'être fermé.
[^] # Re: Pourquoi ce n'est pas libre ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 3.
Pour l'instant ! Mais c'est vrai que lorsqu'on avait diffusé Plee, diverses personnes avaient créé des paquets pour leurs distributions. Là on va devoir tout faire tout seuls, ça va être long. C'est un point sur lequel le libre était clairement avantageux.
[^] # Re: Pourquoi ce n'est pas libre ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 2.
Je ne suis pas friand des logiciels mi-libres avec le code libre mais pas les ressources. À mon sens ça n'a plus beaucoup d'intérêt de n'avoir accès qu'au source, alors si j'en libère un bout je libère le reste avec, pour que les intéressés puissent voir comment le tout est fait, quelle taille ça fait, comment les choses s'assemblent, et décider de créer et diffuser un nouveau produit si ça les chante.
[^] # Re: Pourquoi ce n'est pas libre ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 2.
Si c'était libre je ne considérerai pas cela comme du vol. Mais pour une première création, un premier jeu complet, je préfère que les gens nous l'achètent plutôt qu'à quelqu'un d'autre.
Ça ne rentre pas vraiment en compte. Je pense que quel que soit le procédé de diffusion (libre, fermé, avec ou sans drm), ceux qui ne veulent pas payer trouvent un moyen de ne pas payer.
Dans l'absolu j'aimerais bien tenter la mise en vente d'un jeu libre complet, y compris les ressources graphiques et sonores. Cependant ça ne me semble pas très sage de le faire dès nos premiers pas en tant que pro. C'est beaucoup plus simple pour nous de coller aux pratiques classiques.
[^] # Re: Anglais
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 8.
Tout est en anglais car je pense que c'est la seule langue internationale. Si on sort un jeu en français, on ne parle pas à grand monde ; et je ne vois pas quel honneur cela fait à la langue. Si on le sort en anglais on parle à tout le monde. Pas seulement aux anglophones de naissance, mais bien à toutes les personnes qui utilisent l'anglais pour aller au delà de leurs frontières.
Éventuellement nous pourrions proposer la page web en français, comme nous l'avions fait pour Plee the Bear. Ça nous demande plus de travail, plus de maintenance, plus de complications. Ce n'est clairement pas une priorité dans le planning de finalisation et de sortie du jeu.
Néanmoins, vous aurez remarqué que les dialogues du jeu sont traduits en français.
[^] # Re: comment passez vous de GPL à propriétaire ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Sortie de Andy's Super Great Park, des sensations dans ton Linux. Évalué à 6.
C'est très simple. Nous sommes deux individus à avoir produit le code et nous autorisons notre société à l'utiliser sous une licence non libre. Cela n'est possible uniquement parce que nous sommes les seuls auteurs, à quelques patches près. Si quelqu'un d'externe contribuait significativement au code de Plee the Bear, nous n'aurions pas pu utiliser ses contributions.
[^] # Re: Beaucoup d' heures
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Le Bottin des jeux linux : entretien avec le créateur du site. Évalué à 2.
Il interprète le h comme un indicateur de valeur hexadécimal : 4000 en base 16 correspond à 16384 en base 10. D'où sort cette notation ? Aucune idée, je connais les préfixes 0x, le # et &H mais le suffixe h ne me dit rien.
[^] # Re: Paiement en ligne
Posté par Julien Jorge (site web personnel) . En réponse au message Outil de vente dématérialisée. Évalué à 1.
Tout cela m'a l'air pas mal, je vais faire le tour de ces solutions :)
[^] # Re: Paiement en ligne
Posté par Julien Jorge (site web personnel) . En réponse au message Outil de vente dématérialisée. Évalué à 2.
Justement j'ai du mal à en trouver. Tu as quelques noms ? J'ai bien quelques trucs pour des boutiques complètes, avec gestion du panier etc. mais je n'ai rien vu de plus léger (nous n'avons qu'un produit pour l'instant).
Ensuite je ne sais pas trop comment gérer le lien de téléchargement. Je me dis que je ne pourrais pas empêcher l'utilisateur de filer le lien à quelqu'un d'autre, ou de le mettre quelque part en ligne, alors finalement pourquoi mettre un système compliqué.
J'ai oublié d'indiquer que je cherchais un outil libre aussi. J'aimerais bien regarder comment c'est fait.