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.
J'aime bien Asus aussi, ils gèrent, mais ces nuls n'avaient plus d'écrans mats. Alors j'ai opté pour un Samsung 350V5C-S03FR parce que Samsung me semble fiable, que l'écran est mat et que la carte graphique est une Ati. Je l'utilise avec les pilotes libres sans soucis.
Bref, ici tout va bien, mais je ne l'ai que depuis 2 semaines. Je te dirai dans un an si c'était un bon achat :)
J'ai une installation de Wine dans laquelle j'ai copié tous les outils et les bibliothèques que j'utilisais auparavant sous Windows. Le script lance simplement les outils de compilation. Alors évidemment il a fallu réussir à tout faire fonctionner sous Windows avant.
Ça a été difficile de trouver une combinaison des outils et bibliothèques qui fonctionne bien (un MinGW qui tourne bien, Boost compilé avec, la SDL, un CMake récent). Comme ça plantait souvent, je ne pouvais pas le faire sous Wine sans me demander si la cause du plantage était l'outil ou Wine. Et une fois que les outils ont enfin fonctionné ensemble, il fallait encore que j'indique manuellement à CMake où étaient les bibliothèques.
Ce script se charge de passer les bons paramètres à CMake, puis il lance la compilation, copie les bibliothèques nécessaires dans le dossier des binaires du jeu et termine par la création d'un installateur avec NSIS.
Au sujet des binaires pour Windows, j'arrive enfin à compiler et packager mon jeu avec Wine. Ça a été un peu galère à mettre en place mais maintenant je peux travailler cette version confortablement, dans l'environnement Linux dans lequel je suis à l'aise, plutôt que de devoir redémarrer sous Windows et travailler avec des outils que je connais moins.
Si ça vous intéresse, je peux poster le script et les détails de la configuration de Wine.
Bien sûr que cela existe : Rakarrack. Il y avait un guitariste aux RMLL en 2010 qui avait branché sa guitare sur un eeepc 700 et qui faisais des démos sur les stands. Pour brancher la guitare il suffit d'avoir une entrée ligne et le câble jack du bon diamètre.
Cependant mon expérience perso est un peu laborieuse. J'ai réussi à utiliser Rackarrack et d'autres logiciels en utilisant une Ubuntu Studio et un noyau pour le temps réel. Avec une distribution classique j'ai toujours beaucoup de mal à bien faire fonctionner les logiciels audio ensemble, notamment à cause des conflits Jack/Pulseaudio et de la latence due au traitement du son.
C'est déjà difficile de dessiner la courbe en OpenGL. Sur l'image que j'ai postée plus haut, avec le bandeau noir, je saurais calculer des sommets de quads pour longer la courbe blanche, mais je ne saurais pas les calculer pour la courbe jaune. Le calcul des coordonnées dans la texture ne me semble pas évident non plus, et en plus il faudra que je découpe le bandeau en parties convexes.
On est très loin d'un « basta » avec ça. Autant tenter Blender, mais là encore ça ne serait pas évident de tracer la courbe jaune.
# 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.
# Moi
Posté par Julien Jorge (site web personnel) . En réponse au message Nouveau portable (bis). Évalué à 1.
J'aime bien Asus aussi, ils gèrent, mais ces nuls n'avaient plus d'écrans mats. Alors j'ai opté pour un Samsung 350V5C-S03FR parce que Samsung me semble fiable, que l'écran est mat et que la carte graphique est une Ati. Je l'utilise avec les pilotes libres sans soucis.
Bref, ici tout va bien, mais je ne l'ai que depuis 2 semaines. Je te dirai dans un an si c'était un bon achat :)
# Quelles erreurs ?
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Diaspora 0.0.1. Évalué à 4.
Avez-vous des exemples de ces erreurs ? Par simple curiosité.
[^] # Re: Mole invasion
Posté par Julien Jorge (site web personnel) . En réponse au journal Créateurs de jeux, dénoncez vous!. Évalué à 3.
J'ai une installation de Wine dans laquelle j'ai copié tous les outils et les bibliothèques que j'utilisais auparavant sous Windows. Le script lance simplement les outils de compilation. Alors évidemment il a fallu réussir à tout faire fonctionner sous Windows avant.
Ça a été difficile de trouver une combinaison des outils et bibliothèques qui fonctionne bien (un MinGW qui tourne bien, Boost compilé avec, la SDL, un CMake récent). Comme ça plantait souvent, je ne pouvais pas le faire sous Wine sans me demander si la cause du plantage était l'outil ou Wine. Et une fois que les outils ont enfin fonctionné ensemble, il fallait encore que j'indique manuellement à CMake où étaient les bibliothèques.
Ce script se charge de passer les bons paramètres à CMake, puis il lance la compilation, copie les bibliothèques nécessaires dans le dossier des binaires du jeu et termine par la création d'un installateur avec NSIS.
Voici le script :
Je me souviens :)
[^] # Re: Mole invasion
Posté par Julien Jorge (site web personnel) . En réponse au journal Créateurs de jeux, dénoncez vous!. Évalué à 3.
Au sujet des binaires pour Windows, j'arrive enfin à compiler et packager mon jeu avec Wine. Ça a été un peu galère à mettre en place mais maintenant je peux travailler cette version confortablement, dans l'environnement Linux dans lequel je suis à l'aise, plutôt que de devoir redémarrer sous Windows et travailler avec des outils que je connais moins.
Si ça vous intéresse, je peux poster le script et les détails de la configuration de Wine.
[^] # Re: Slime Volley
Posté par Julien Jorge (site web personnel) . En réponse au journal Créateurs de jeux, dénoncez vous!. Évalué à 2.
Slime Volley ! Je connais, c'est vraiment un très beau jeu ;)
# Rackarrack
Posté par Julien Jorge (site web personnel) . En réponse au message Guitare -> PC (ampli virtuel + effets). Évalué à 2.
Bien sûr que cela existe : Rakarrack. Il y avait un guitariste aux RMLL en 2010 qui avait branché sa guitare sur un eeepc 700 et qui faisais des démos sur les stands. Pour brancher la guitare il suffit d'avoir une entrée ligne et le câble jack du bon diamètre.
Cependant mon expérience perso est un peu laborieuse. J'ai réussi à utiliser Rackarrack et d'autres logiciels en utilisant une Ubuntu Studio et un noyau pour le temps réel. Avec une distribution classique j'ai toujours beaucoup de mal à bien faire fonctionner les logiciels audio ensemble, notamment à cause des conflits Jack/Pulseaudio et de la latence due au traitement du son.
En tout cas, quand ça marche c'est très sympa.
[^] # Re: OpenGL
Posté par Julien Jorge (site web personnel) . En réponse au message Projeter une image le long d'un chemin. Évalué à 1.
C'est déjà difficile de dessiner la courbe en OpenGL. Sur l'image que j'ai postée plus haut, avec le bandeau noir, je saurais calculer des sommets de quads pour longer la courbe blanche, mais je ne saurais pas les calculer pour la courbe jaune. Le calcul des coordonnées dans la texture ne me semble pas évident non plus, et en plus il faudra que je découpe le bandeau en parties convexes.
On est très loin d'un « basta » avec ça. Autant tenter Blender, mais là encore ça ne serait pas évident de tracer la courbe jaune.