Quitte à me répéter, les sites que tu listes sont orientés vers le libre et je ne pense pas que ce soit le point le plus important. Pour faire un jeu libre il faut faire un jeu (ça prend plusieurs mois) et copier une licence libre dans le dossier du jeu (ça prend une seconde au début du projet). Une fois que la licence est copiée, il vaut mieux, à mon avis, aller se montrer aux joueurs.
Pourquoi aller sur freegamedev.net plutôt que gamedev.net ? J'en apprends plus sur gamedev.net et j'y ai même trouvé des contributeurs pour mon jeu libre. Sur les sites qui tournent autour du libre j'ai plutôt des retours qui me disent « t'as vu ce que font les gens de XXX ? » ou pire, « pourquoi tu ne vas pas sur openfreefreedomartandstuff.org pour trouver tes ressources ? »
Pourquoi aller sur jeuxlibres.net se montrer à un petit groupe de francophones plutôt que sur indiedb, où des joueurs du monde entier essaieront le jeu ? Si vous voulez supporter le jeu libre, ce n'est pas pour les libristes qu'il faut faire des sites, c'est pour les joueurs.
Quand il s'agit d'outils informatiques, de bureautique par exemple, les utilisateurs du libre cherchent des alternatives à des outils fermés. Ce n'est pas aussi vrai pour les jeux, où les utilisateurs cherchent plutôt des nouveaux jeux.
release early, release often : c'est si dur de packager un tar.bz2 (ou tar.lzma) ? Autant l'automatiser quand il y a des améliorations suffisantes le permettant (au pire, tous les 6 mois, mais ça doit bien être faisable une fois tous les 2 mois si le "packaging" et la génération du changelog sont automatiques ?).
Oui c'est dur de packager un tar.xxx et de le diffuser. Les ajustements pour les différentes plates-formes demandent du temps. L'annonce d'une nouvelle version et son résumé demandent du temps. L'upload met du temps à se faire. L'appli mets du temps à compiler. Le public ne veut pas du source, il veut un truc pour son système, alors faire un deb/rpm ou une compilation statique prend aussi du temps.
Il me faut généralement un jour et demi pour finaliser l'archive de mon jeu. Après quoi il faut encore rédiger l'annonce de la nouvelle version et la diffuser.
Donc à mon avis, qui ne vaut que ce qu'il vaut, l'énergie dépensée pour entretenir des sites comme jeuxlibres.net ou jeuxlinux.fr serait mieux investie dans une veille de l'avancement du dev des jeux et la publication des avancées sur des sites de jeux (pas « jeux libres », juste « jeux »). Ça soulagerait les developpeurs, ça augmenterait la visibilité et les retours et donc leur motivation.
Le problème que je vois dans jeuxlibres.net et jeuxlinux.fr, mais aussi happypenguin.org et lgdb.org, c'est qu'ils mettent le focus sur des qualités des jeux qui ne sont pas les plus importantes : c'est libre ou ça tourne sous Linux.
Je ne dis pas que ce ne sont pas des qualités mais ça me semble aussi peu intéressant que de présenter son jeu sur un site sur Java par exemple. Ça ne concerne aucunement ce qui me semble être le plus important, c'est à dire le contenu. En allant sur des sites de jeux indépendant, ce qu'est effectivement Newton Adventure, les échanges et les commentaires tourneront autour du jeu, et le projet avancera.
Ce sont les retours des joueurs qui donnent envie de bosser sur les projets. Et les joueurs de jeux sous Linux, ou de jeux libres, sont avant tout des joueurs. Vu le temps que ça demande de communiquer sur un projet, autant le faire au plus efficace, c'est à dire sur des sites internationaux de jeux. Ça n'empêche pas de discuter de technique ou de liberté sur d'autres sites, mais il vaut mieux le faire s'il reste du temps.
Un type de contributeur que j'aimerais bien avoir et que je n'ai jamais vu serait une personne qui suivrait l'avancée du projet quasiment en permanence. Elle publierait avec un regard externe les avancées, et plutôt d'une manière orientée jeu. Aujourd'hui les nouvelles sont liées à la sortie du logiciel, et la plupart des articles sont carrément proposés par les développeurs. Ça me semblerait plus utile d'avoir un suivi à la semaine ou au mois des nouveautés en cours de développement, et ça aiderait les projets à ne pas sembler morts durant les années qui séparent les sorties.
Comme je te le dis dans le post plus haut, j'ai l'impression de te voir passer par les étapes que j'ai vécue. Alors je te propose un petit retour d'expérience.
Je ne pense pas que j'utiliserai ton système car, sans vouloir t'offenser, j'ai le sentiment que tu es encore un poil naïf. Je n'ai pas l'impression dans tes propos que tu aies bien fait le tour du besoin. Il est certes utile d'avoir un format d'animation, mais il y a bien d'autres questions qui se posent dans la gestion de l'anim et je doute que le format soit primordial. Par exemple, dans le développement de mon jeu, nous sommes passés par ce genre d'étapes (uniquement sur l'aspect graphique, je passe le moteur physique, le son, les inputs, l'interface, l'IA, etc.) :
On veux des images. C'est facile
Puis on veut des animations. Pas de problème, on fait un super format XML, un éditeur, on gère la durée des frames une à une, on gère le nombre de boucles, on gère le début et la fin de la partie à boucler.
Puis finalement on se dit que pour faire les personnages et d'autres trucs complexes, il nous faut plusieurs animations. OK, on fait un super format XML, un éditeur, et on gère un concept d'action de personnage durant laquelle une animation est jouée.
Puis finalement on met plusieurs animations positionnées les unes par rapport aux autres. Et puis pendant qu'on y est on gère l'enchaînement des actions et un système de connexion avec le code du personnage (i.e. la fonction à appeler à un moment ou à un autre d'une action).
Et puis finalement c'est pas au point, le mouvement des anims les unes par rapport aux autres est trop brutal alors on ajoute aussi l'interpolation de mouvement.
Et puis finalement il y a plein d'images à l'écran et on dessine plusieurs fois certains points à l'écran. Alors on fait un super algo qui découpe les sprites à l'affichage pour éviter de dessiner les parties invisibles. Et puis on implémente un algo qui calcule le plus grand rectangle opaque dans chaque sprite pour optimiser l'affichage.
Et au bout d'un moment on se demande : où est le contenu du jeu dans tout ça ? On a un super moteur qui répond à quasiment toutes nos problématiques, modulaire et indépendant de notre jeu, on a quasiment pas de niveaux, et on voit les autres développeurs de jeux qui revivent la même histoire.
Si je n'ai qu'un conseil à te donner, c'est de te concentrer sur le contenu de ton jeu. Attention à ne pas passer trop de temps sur la technique ; c'est très satisfaisant mais ça ne fait pas avancer le jeu. Va au plus simple, capitalise sur le concept, et essaie de te montrer sur des sites de jeux genre indiedb afin d'avoir des retours sur ce qui compte dans les jeux : le contenu.
Je suis un peu ce que tu racontes sur LinuxFR au sujet de Newton Adventure et j'ai l'impression de te voir passer par les mêmes étapes que j'ai vécues en faisant mon jeu.
Pour le coup, je n'ai jamais cherché à répondre à la question de l'optimisation placement des sprites dans les textures, bien qu'elle se pose depuis le début, et j'ai tendance à le faire au cas par cas. Mais si je devais m'y mettre, la première question concernerait une solution pour remplir l'espace restant après avoir posé les sprites d'une anim.
Par exemple, j'ai une animation de 3 sprites en 32x32 et une autre de 5 sprites. Je veux les mettre dans des textures de 64x64. A priori j'aimerais me retrouver avec deux images au final. Est-ce que ton format d'animation et ton optimiseur permettent cela facilement ?
J'ai eu des soucis avec des sprites auxquels j'appliquais une rotation dans le jeu : un bord du sprite voisin avait tendance à apparaître dans la rotation. Pour éviter cela, j'ai ajouté une bande d'un pixel transparent autour de mes sprites. Est-ce que ton outils permet de mettre une marge entre les sprites ? Envisages-tu de le faire ?
La page émergera de l'intérêt de la communauté du jeu vidéo ou du logiciel libre pour le projet, ou de n'importe quel domaine dans lequel Newton Adventure serait un bon représentant. Il y a des critères d'admissibilité.
Et de mon point de vue, personne ne devrait créer ou rédiger un article sur son propre projet. Si le projet n'a pas réveillé chez un contributeur de Wikipédia l'envie de rédiger un article, c'est qu'il n'y a pas encore sa place. Je sais que c'est tentant, pour « compléter » Wikipédia, pour gagner en visibilité, mais ça doit venir d'une personne extérieure au projet.
Au bureau je suis assis sur une Markus d'Ikea. Très confortable, je passe facilement de la position « regarder le plafond en basculant en arrière pour réfléchir » à la position « droit, les mains sur le clavier pour coder ». Chez moi j'utilise une ancienne version de la Moses d'Ikea, avec un grand dossier, très bien aussi.
Je trouve mes écrans un peu bas et je dois me forcer à rester droit, sinon j'ai tendance à piquer du nez. Mais le vrai problème vient du manque d'attention qui m'amène parfois à m'avachir sur la chaise, les jambes étendues. Il m'arrive régulièrement de sentir une douleur dans le dos avant de remarquer soudain que j'ai dérivé vers une position en vrac.
Au bureau le matériel est sur une table, mes mains sur le clavier et mes coudes posés sur la table. Je crois que je ne pose pas la paume des mains. C'est un clavier quelconque configuré en bépo. J'utilise naturellement la souris en gardant la main alignée avec mon bras, un peu au dessus de la souris, en la maintenant avec le pouce, l'annulaire et l'auriculaire.
Chez moi le clavier et la souris sont posés sur une tablette-tiroir sous le bureau. Contrairement à ce que j'imaginais c'est cette configuration qui me fatigue le plus. Lorsque j'utilise la souris ma position est telle que j'ai tendance à la tenir en posant ma main sur la table, un peu relevée par rapport à l'orientation de mon bras, ce qui réveille rapidement les douleurs.
Pour résumer, dans ma position confortable je me tiens droit sur une bonne chaise, les coudes posés sur une table (juste posés, je ne m'appuie pas dessus). Les mains sont un peu en l'air, alignées avec les bras correspondants et les doigts tombent sur les périphériques.
J'évite aussi d'utiliser la souris, mais plus par flemme de déplacer le bras et pour éviter de casser le rythme.
Bonne idée de partager les instructions de compilation. J'ajouterai pour les autres distributions de vérifier que libclaw est en version 1.7.0, sinon il faut la télécharger sur son site et la compiler de la même façon (cmake . && make && make install).
Est-ce si évident, ou bien cela n'a-t-il vraiment aucune importance ?
C'est une particularité des logiciels libres que de se présenter en mettant en avant les technos utilisées. Personnellement je ne trouve pas ça très important mais c'est vrai que pour un projet en temps limité c'est intéressant de connaître les outils. Corrigeons le tir :
Nous avons utilisé le moteur de Plee the Bear, qui est écrit en C++ et qui utilise la SDL et un peu d'OpenGL. L'avantage étant que nous connaissons bien l'outil, donc c'était facile de coder les objets :) En plus il y a de supers éditeurs de niveau, d'animation et de personnages.
Les images ont été faites avec Gimp. La musique a été faite avec TuxGuitar, convertie de midi à wav avec Timidity et passée dans Audacity pour en faire une boucle. Les sons ont été faits avec Audacity, un micro et des objets qui traînaient autour.
Le WebPM sera un format de vidéo animé qui permettra de naviguer entre les vidéos et de décider la durée d'affichage de chaque vidéo.
Ce sera le format ultime qui unifiera tous les besoins d'images sur le web :
en ne mettant qu'une image par vidéo, WebPM rejoint le WebP animé ;
en ne mettant qu'une seule vidéo on obtient une vidéo (remplace donc le WebM) ;
et en ne mettant qu'une vidéo d'une seule image, on rejoint le WebP classique, aussi obtenu en utilisant le WebP animé avec une seule image dans l'animation.
Par exemple je n'ai pas l'impression que le GIF ait percé dans les jeux aux animations simples, on retrouve souvent la vielle technique du « je mets plein de sprites dans une image et je fais un fichier indiquant la durée d'affichage de chaque sprite ». Alors pour des animations un peu compliquées, genre n lectures entre deux frames, avec allers-retours ou toujours en avant, ou la possibilité de changer dynamiquement la vitesse de lecture, ou encore avec la rotation de certaines frames ; je ne pense pas qu'un autre format d'animation « générique » puisse devenir un standard.
Alors, je dirais qu'en fait, techniquement, vidéo et animation c'est effectivement le même concept. En revanche, les usages sont différents, aussi différents qu'entre aller au cinéma et assister à une conférence avec projection d'un support par transparents.
les interfaces permettant d'interagir avec des vidéos et avec des animations sont différentes : typiquement, dans une animation on peut vouloir passer à l'image suivante, ce qui n'a pas un grand intérêt pour une vidéo.
J'ai l'impression que lorsque tu parles d'animation tu penses à des présentations à la Beamer ou Impress. Est-ce l'utilisation visée par Google avec le WebM animé ou est-ce qu'il s'agit vraiment de remplacer le GIF pour faire des pandas animés dans les pages web ?
Si j'ai bien compris ils ont pris un format vidéo, en ont extrait un format d'image puis ils ont fait un format d'animation. Il n'y a pas une boucle là ?
La différence qui me vient entre une vidéo et un gif animé est que ce dernier permet de faire une animation sur fond transparent. Mais est-ce que le format de vidéo et d'animation n'auraient pas intérêt à être fusionnés ?
Jamp, ou Just a Music Player. Un lecteur maison très simple avec des fonctionnalités de folie et qui correspond bien à ma façon de gérer une liste de lecture : mélanger toute la bibliothèque musicale et l'écouter.
Parmi les excellentes fonctionnalités, on trouve :
- mélanger la liste de lecture en tentant de mettre un minimum d'écart entre deux chansons d'un même auteur ;
- une interface épurée ne comprenant que la liste de lecture et les boutons de lecture, l'ajout de musique se faisant en glisser-déposer ;
- le contrôle de la lecture depuis l'icône de la zone de notification ;
- la possibilité de bannir des chansons pour qu'elles n'apparaissent plus dans la liste ;
- la lecture reprend à la dernière piste jouée quand on relance le lecteur.
Malheureusement il a plein de petits défauts, notamment de ne pouvoir jouer que du 44100 Hz et peu de formats de fichiers (mp3, ogg et flac). Tout ça parce que je n'ai pas le temps de m'en occuper.
Bah finalement qu'un acheté vomisse, c'est pas étonnant. Que personne ne valide l'est moins... non ?
Est-ce que les fournisseurs de blogs valident le contenu de leurs utilisateurs ? Ici l'auteur poste sur un espace de blog, ce n'est pas un « article » au sens donné par le site. J'imagine que comme sur n'importe quel blog l'auteur peut se permettre de mettre tout et n'importe quoi.
Par contre lorsque j'ai rédigé mes deux articles sur sur leur site il y a eu une étape de relecture et des membres que je trouve très compétents ont apporté leurs critiques. Ça dépend donc de l'espace sur lequel on rédige. Pour ma part je suis toujours étonné de la quantité de fautes d'orthographe dans leurs actualités.
Le problème de developpez.com est qu'ils ont tous les types d'utilisateurs depuis les très débutants jusqu'aux très bons et tout le monde peut facilement proposer du contenu. Et comme sur les autres sites où le contenu provient des utilisateurs (par exemple linuxfr ou wikipedia, au hasard), il arrive que de la merde soit diffusée sans que quelqu'un ne l'empêche.
Effectivement il doit y avoir un paquet disponible pour la version précédente dans la plupart des distributions. Cependant on a remarqué que les versions précédentes se dégradaient avant qu'on sorte les nouvelles. Par exemple, lors de la sortie de la 0.5, la version 0.4 qui était dans Debian testing ne se lançait pas. Et j'ai appris aussi que la version 0.5 pour ArchLinux avait des soucis récemment.
Du coup j'hésite à dire que les paquets sont disponibles si je ne suis pas sûr qu'ils se lancent bien.
Il serait bien de fournir un exécutable pour linux (sous forme de tar.gz, avec le plus possible de librairies compilées statiquement) avant de faire l'annonce d'une nouvelle version. Le fait d'avoir à dégainer gcc et d'installer les dépendances est une barrière d'entrée bien trop haute, éloignant beaucoup de joueurs potentiels (de plus sous Ubuntu libclaw est séparée en zillions de petits paquets). Et une fois l'annonce passée, c'est trop tard…
On prenait soin pour les précédentes version de sortir un tar.gz avec les binaires pour Ubuntu, mais plutôt une fois qu'on a reçu les premiers retours. Le problème c'est qu'à force je ne sais plus choisir quelle version faire et je me fais mal au crâne à me demander est-ce que j'en fais une pour Natty ? pour la LTS ? en 32 ou 64 bits ? et pourquoi pas faire une VM avec d'autres distributions pour faire de même ?
Le cycle compilation, test, empaquetage, upload est vraiment chronophage et il y a toujours des petits problèmes après les sorties qui m'obligent à le répéter. Par exemple, j'ai remarqué hier que le jeu ne compilait pas si libclaw n'était pas pris en checkout du svn. Du coup j'ai du refaire les .tar.gz sources et faire l'upload. Et encore je n'ai pas eu à refaire les binaires, mais lors du prochain rapport de bug ça ne sera peut-être pas si simple.
Au final, tout cela fait beaucoup de boulot pour une petite équipe d'une personne et demie, alors je me contente de faire la version source, la version Windows et je suis mainteneur pour le paquet Debian. Je laisse le reste à la communauté :) (qui s'en charge plutôt bien d'ailleurs).
[…] Toutefois je vois un point faible dans l'animation de l'ours, qui n'est pas synchronisée avec le mouvement (l'ours glisse lorsqu'il marche ou court). Du coup cela fausse les sensations, je n'avais pas vraiment l'impression d'avoir le contrôle. Il existe plusieurs techniques pour résoudre ce problème de glissade […]
C'est intéressant que tu l'aies remarqué car à force de jouer ça ne nous choque pas du tout. Les ressources que tu donnes sont intéressantes et effectivement on devrait pouvoir facilement adapter la vitesse de lecture de l'animation à la vitesse. Je garde ça en tête.
Il y a également un problème avec le passage des premiers "bocaux de pierres", il est possible de prendre un chemin qui les évite totalement, et de se retrouver coincé plus tard.
Je crains de ne pas voir le problème. Les pierres ne sont pas indispensables pour atteindre la fin du niveau et il est de toute façon toujours possible de revenir en arrière dans le niveau pour récupérer les objets oubliés. Peux-tu préciser comment tu t'es retrouvé coincé ?
Un autre détail: je ne sais pas si les touches par défaut sont très bien choisies; de plus en plus le standard me semble être l'utilisation de WASD (ZQSD sur un clavier azerty), donc main gauche pour le déplacement et main droite pour les actions.
Tu as bien remarqué que les touches par défaut dépendent d'habitude de l'agencement du clavier. Pour éviter d'avoir à deviner le clavier du joueur, on s'est surtout basé sur les touches flèches, control, alt et shift, mais j'ai l'impression que n'importe quel choix sera insatisfaisant quoi qu'il arrive.
Un peu comme plusieurs commentateurs ci-dessus, je pense aussi que tu te lances dans un projet monstrueux, limite infaisable, et je t'encourage à le tenter. J'ai aussi une bonne expérience de long développement sur un jeu. Voici quelques retours sur mon expérience, si ça peu t'aider.
On a commencé notre jeu à deux développeurs motivés, plus un bon graphiste et un bon musicien qui nous faisaient des images et des musiques. Ça me semble pas mal pour un jeu amateur. Résultat des courses : cela fait six ans que le jeu sera fini en trois ans.
La principale cause de l'avancée très lente du projet est sans doute les développeurs. Il nous est arrivé très souvent de nous lancer dans des petits changements de structure du jeu en nous disant que ça l'améliorerait ou que ça faciliterait le développement. Mais la principale raison était que ça nous plaisait. Résultat, nous avons régulièrement passé du temps à améliorer le peu existant plutôt que de continuer le jeu. Ces petites parenthèses cumulées aboutissent à un grand retard.
C'est un point auquel il faut faire attention. Quelle est ta priorité dans le développement ? Le loisir, l'apprentissage, la diffusion ? Si ta priorité est de diffuser le jeu, alors il faudra être un peu rigoureux et se forcer à faire l'utile avant l'amusant. Ce n'est pas toujours facile.
L'autre difficulté est la recherche de contributeurs. J'ai dis plus haut que nous avions un graphiste et un musicien, et bien ils ne sont pas restés longtemps. À mon avis, le plus grand problème était le temps nécessaire pour que leurs contributions apparaissent dans le jeu. Typiquement, le graphiste nous fait des animations avec Gimp et sort des gif pour voir le résultat. Pour les mettre dans le jeu il faut construire une grande image où toutes les image de l'animation sont côte à côte, construire un fichier d'animation pour rassembler tout ça, gérer les boucles, la durée… et lier cette animation à un fichier de personnage. C'est beaucoup trop d'étapes pour un dessinateur.
Nous avons eu régulièrement des contributeurs, souvent suite à une demande d'aide dans des forums, mais jamais sur une longue durée. Si des gens acceptent de contribuer, il faudra prendre en compte que contrairement à toi, ce n'est pas leur jeu. Par conséquent, s'ils rencontrent des difficultés à ajouter leurs contributions, ils se démotiveront. Idéalement, il faudrait qu'on puisse modifier des éléments du jeu sans effort : je mets une image, un son ou un fichier dans un dossier, je vois le résultat rapidement. S'il faut un trop long protocole pour tester (« tu mets un fichier là, tu compiles tel truc puis tu relances avec tel paramètre »), tes contributeurs vont se lasser.
Tu peux regarder sur gamedev.net pour trouver des contributeurs. Il y a du monde intéressé, mais du coup un peu de concurrents aussi.
Pour un projet comme le tien, je pense que tu as intérêt à prioriser la diffusion du jeu. Fait une base qui tourne, même si c'est moche. Si c'est amusant tu auras suffisamment de joueurs pour que des contributions apparaissent. Puis tu pourras améliorer l'aspect et les fonctionnalités. Quant au langage… prend un truc populaire. Java a beau me déplaire il y a du monde capable de l'utiliser. Si tu veux coder vite c'est sans doute le langage pour lequel tu trouveras le plus facilement des contributeurs. T'auras le temps d'investir sur la qualité du code quand tu auras des joueurs :)
Voilà, c'est un peu long mais j'espère que c'est utile :)
Je passe ma journée à faire du Java et de l'ActionScript sur de l'application d'entreprise. J'aime ce que je fais mais j'ai toujours un pincement au cœur à utiliser ces langages. Moi j'aime bien le C++. Et j'aurais bien aimé faire du jeu vidéo. Et du logiciel libre aussi.
Alors quand je rentre, je suis content de pouvoir programmer un jeu vidéo en C++, libre en plus ! Mais c'est parfois dur parce qu'il faut se caler une tâche d'une heure ou deux et qu'en plus je suis crevé. C'est vraiment du développement de loisir du coup.
Je viens de regarder un peu les options de Claws Mail (oui je n'avais pas trop cherché avant de poser la question…) et je vois que le raccourci du V est présent aussi. Il y a aussi d'autres dispositions disponibles dont « Petit écran » mais je me suis perdu en l'utilisant.
Je suis un peu surpris que l'interface des clients de courriel n'ai pas changé en 10 ans. On a toujours la même présentation en trois cadres, ça manque d'innovation.
Je reformule. Je dis qu'on peut mettre un texte alt plus fidèle à l'image. Entre « visage qui sourit », « :-) » et « ☺ » il me semble que le dernier est le plus fidèle.
Je pensais plus à la fidélité qu'à l'accessibilité aux handicapés. C'est sûr que ce n'est pas le meilleur pour l'aveugle.
Ça pourrait remplacer les smileys actuellement affichés comme images ou ascii-art. Avec ces symboles on a un dessin accessible qui reflète l'expression et qui est copie-collable aisément.
Après pour ce qui sort des bonhommes, j'ai du mal. Peut-être qu'ils veulent faire des interfaces user-friendly en mode texte ? Il y a des types de ncurses dans le consortium ?
[^] # Re: Retours d'expérience
Posté par Julien Jorge (site web personnel) . En réponse au journal nanimopt: un optimiseur de nanim. Évalué à 3.
Quitte à me répéter, les sites que tu listes sont orientés vers le libre et je ne pense pas que ce soit le point le plus important. Pour faire un jeu libre il faut faire un jeu (ça prend plusieurs mois) et copier une licence libre dans le dossier du jeu (ça prend une seconde au début du projet). Une fois que la licence est copiée, il vaut mieux, à mon avis, aller se montrer aux joueurs.
Pourquoi aller sur freegamedev.net plutôt que gamedev.net ? J'en apprends plus sur gamedev.net et j'y ai même trouvé des contributeurs pour mon jeu libre. Sur les sites qui tournent autour du libre j'ai plutôt des retours qui me disent « t'as vu ce que font les gens de XXX ? » ou pire, « pourquoi tu ne vas pas sur openfreefreedomartandstuff.org pour trouver tes ressources ? »
Pourquoi aller sur jeuxlibres.net se montrer à un petit groupe de francophones plutôt que sur indiedb, où des joueurs du monde entier essaieront le jeu ? Si vous voulez supporter le jeu libre, ce n'est pas pour les libristes qu'il faut faire des sites, c'est pour les joueurs.
Quand il s'agit d'outils informatiques, de bureautique par exemple, les utilisateurs du libre cherchent des alternatives à des outils fermés. Ce n'est pas aussi vrai pour les jeux, où les utilisateurs cherchent plutôt des nouveaux jeux.
Oui c'est dur de packager un tar.xxx et de le diffuser. Les ajustements pour les différentes plates-formes demandent du temps. L'annonce d'une nouvelle version et son résumé demandent du temps. L'upload met du temps à se faire. L'appli mets du temps à compiler. Le public ne veut pas du source, il veut un truc pour son système, alors faire un deb/rpm ou une compilation statique prend aussi du temps.
Il me faut généralement un jour et demi pour finaliser l'archive de mon jeu. Après quoi il faut encore rédiger l'annonce de la nouvelle version et la diffuser.
Donc à mon avis, qui ne vaut que ce qu'il vaut, l'énergie dépensée pour entretenir des sites comme jeuxlibres.net ou jeuxlinux.fr serait mieux investie dans une veille de l'avancement du dev des jeux et la publication des avancées sur des sites de jeux (pas « jeux libres », juste « jeux »). Ça soulagerait les developpeurs, ça augmenterait la visibilité et les retours et donc leur motivation.
[^] # Re: Retours d'expérience
Posté par Julien Jorge (site web personnel) . En réponse au journal nanimopt: un optimiseur de nanim. Évalué à 6.
Le problème que je vois dans jeuxlibres.net et jeuxlinux.fr, mais aussi happypenguin.org et lgdb.org, c'est qu'ils mettent le focus sur des qualités des jeux qui ne sont pas les plus importantes : c'est libre ou ça tourne sous Linux.
Je ne dis pas que ce ne sont pas des qualités mais ça me semble aussi peu intéressant que de présenter son jeu sur un site sur Java par exemple. Ça ne concerne aucunement ce qui me semble être le plus important, c'est à dire le contenu. En allant sur des sites de jeux indépendant, ce qu'est effectivement Newton Adventure, les échanges et les commentaires tourneront autour du jeu, et le projet avancera.
Ce sont les retours des joueurs qui donnent envie de bosser sur les projets. Et les joueurs de jeux sous Linux, ou de jeux libres, sont avant tout des joueurs. Vu le temps que ça demande de communiquer sur un projet, autant le faire au plus efficace, c'est à dire sur des sites internationaux de jeux. Ça n'empêche pas de discuter de technique ou de liberté sur d'autres sites, mais il vaut mieux le faire s'il reste du temps.
Un type de contributeur que j'aimerais bien avoir et que je n'ai jamais vu serait une personne qui suivrait l'avancée du projet quasiment en permanence. Elle publierait avec un regard externe les avancées, et plutôt d'une manière orientée jeu. Aujourd'hui les nouvelles sont liées à la sortie du logiciel, et la plupart des articles sont carrément proposés par les développeurs. Ça me semblerait plus utile d'avoir un suivi à la semaine ou au mois des nouveautés en cours de développement, et ça aiderait les projets à ne pas sembler morts durant les années qui séparent les sorties.
# Retours d'expérience
Posté par Julien Jorge (site web personnel) . En réponse au journal nanimopt: un optimiseur de nanim. Évalué à 7.
Comme je te le dis dans le post plus haut, j'ai l'impression de te voir passer par les étapes que j'ai vécue. Alors je te propose un petit retour d'expérience.
Je ne pense pas que j'utiliserai ton système car, sans vouloir t'offenser, j'ai le sentiment que tu es encore un poil naïf. Je n'ai pas l'impression dans tes propos que tu aies bien fait le tour du besoin. Il est certes utile d'avoir un format d'animation, mais il y a bien d'autres questions qui se posent dans la gestion de l'anim et je doute que le format soit primordial. Par exemple, dans le développement de mon jeu, nous sommes passés par ce genre d'étapes (uniquement sur l'aspect graphique, je passe le moteur physique, le son, les inputs, l'interface, l'IA, etc.) :
Et au bout d'un moment on se demande : où est le contenu du jeu dans tout ça ? On a un super moteur qui répond à quasiment toutes nos problématiques, modulaire et indépendant de notre jeu, on a quasiment pas de niveaux, et on voit les autres développeurs de jeux qui revivent la même histoire.
Si je n'ai qu'un conseil à te donner, c'est de te concentrer sur le contenu de ton jeu. Attention à ne pas passer trop de temps sur la technique ; c'est très satisfaisant mais ça ne fait pas avancer le jeu. Va au plus simple, capitalise sur le concept, et essaie de te montrer sur des sites de jeux genre indiedb afin d'avoir des retours sur ce qui compte dans les jeux : le contenu.
# Questions techniques
Posté par Julien Jorge (site web personnel) . En réponse au journal nanimopt: un optimiseur de nanim. Évalué à 4.
Je suis un peu ce que tu racontes sur LinuxFR au sujet de Newton Adventure et j'ai l'impression de te voir passer par les mêmes étapes que j'ai vécues en faisant mon jeu.
Pour le coup, je n'ai jamais cherché à répondre à la question de l'optimisation placement des sprites dans les textures, bien qu'elle se pose depuis le début, et j'ai tendance à le faire au cas par cas. Mais si je devais m'y mettre, la première question concernerait une solution pour remplir l'espace restant après avoir posé les sprites d'une anim.
Par exemple, j'ai une animation de 3 sprites en 32x32 et une autre de 5 sprites. Je veux les mettre dans des textures de 64x64. A priori j'aimerais me retrouver avec deux images au final. Est-ce que ton format d'animation et ton optimiseur permettent cela facilement ?
J'ai eu des soucis avec des sprites auxquels j'appliquais une rotation dans le jeu : un bord du sprite voisin avait tendance à apparaître dans la rotation. Pour éviter cela, j'ai ajouté une bande d'un pixel transparent autour de mes sprites. Est-ce que ton outils permet de mettre une marge entre les sprites ? Envisages-tu de le faire ?
[^] # Re: wikipedia
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Newton Adventure 1.2. Évalué à 1.
La page émergera de l'intérêt de la communauté du jeu vidéo ou du logiciel libre pour le projet, ou de n'importe quel domaine dans lequel Newton Adventure serait un bon représentant. Il y a des critères d'admissibilité.
Et de mon point de vue, personne ne devrait créer ou rédiger un article sur son propre projet. Si le projet n'a pas réveillé chez un contributeur de Wikipédia l'envie de rédiger un article, c'est qu'il n'y a pas encore sa place. Je sais que c'est tentant, pour « compléter » Wikipédia, pour gagner en visibilité, mais ça doit venir d'une personne extérieure au projet.
# Ma config
Posté par Julien Jorge (site web personnel) . En réponse au journal Ergonomie et aménagement du poste de travail : retours et appels à expériences. Évalué à 4.
Au bureau je suis assis sur une Markus d'Ikea. Très confortable, je passe facilement de la position « regarder le plafond en basculant en arrière pour réfléchir » à la position « droit, les mains sur le clavier pour coder ». Chez moi j'utilise une ancienne version de la Moses d'Ikea, avec un grand dossier, très bien aussi.
Je trouve mes écrans un peu bas et je dois me forcer à rester droit, sinon j'ai tendance à piquer du nez. Mais le vrai problème vient du manque d'attention qui m'amène parfois à m'avachir sur la chaise, les jambes étendues. Il m'arrive régulièrement de sentir une douleur dans le dos avant de remarquer soudain que j'ai dérivé vers une position en vrac.
Au bureau le matériel est sur une table, mes mains sur le clavier et mes coudes posés sur la table. Je crois que je ne pose pas la paume des mains. C'est un clavier quelconque configuré en bépo. J'utilise naturellement la souris en gardant la main alignée avec mon bras, un peu au dessus de la souris, en la maintenant avec le pouce, l'annulaire et l'auriculaire.
Chez moi le clavier et la souris sont posés sur une tablette-tiroir sous le bureau. Contrairement à ce que j'imaginais c'est cette configuration qui me fatigue le plus. Lorsque j'utilise la souris ma position est telle que j'ai tendance à la tenir en posant ma main sur la table, un peu relevée par rapport à l'orientation de mon bras, ce qui réveille rapidement les douleurs.
Pour résumer, dans ma position confortable je me tiens droit sur une bonne chaise, les coudes posés sur une table (juste posés, je ne m'appuie pas dessus). Les mains sont un peu en l'air, alignées avec les bras correspondants et les doigts tombent sur les périphériques.
J'évite aussi d'utiliser la souris, mais plus par flemme de déplacer le bras et pour éviter de casser le rythme.
[^] # Re: Compilé, testé et approuvé!
Posté par Julien Jorge (site web personnel) . En réponse au journal Roller Painting, un jeu rigolo fait en deux jours. Évalué à 6.
Bonne idée de partager les instructions de compilation. J'ajouterai pour les autres distributions de vérifier que libclaw est en version 1.7.0, sinon il faut la télécharger sur son site et la compiler de la même façon (cmake . && make && make install).
[^] # Re: RoR!!!
Posté par Julien Jorge (site web personnel) . En réponse au journal Roller Painting, un jeu rigolo fait en deux jours. Évalué à 7.
C'est une particularité des logiciels libres que de se présenter en mettant en avant les technos utilisées. Personnellement je ne trouve pas ça très important mais c'est vrai que pour un projet en temps limité c'est intéressant de connaître les outils. Corrigeons le tir :
Nous avons utilisé le moteur de Plee the Bear, qui est écrit en C++ et qui utilise la SDL et un peu d'OpenGL. L'avantage étant que nous connaissons bien l'outil, donc c'était facile de coder les objets :) En plus il y a de supers éditeurs de niveau, d'animation et de personnages.
Les images ont été faites avec Gimp. La musique a été faite avec TuxGuitar, convertie de midi à wav avec Timidity et passée dans Audacity pour en faire une boucle. Les sons ont été faits avec Audacity, un micro et des objets qui traînaient autour.
[^] # Re: lien qui marche pas
Posté par Julien Jorge (site web personnel) . En réponse au journal Roller Painting, un jeu rigolo fait en deux jours. Évalué à 3.
C'est corrigé, merci.
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . En réponse au journal WebP, le format d'images ultime. Évalué à 4. Dernière modification le 25 novembre 2011 à 13:48.
Le WebPM sera un format de vidéo animé qui permettra de naviguer entre les vidéos et de décider la durée d'affichage de chaque vidéo.
Ce sera le format ultime qui unifiera tous les besoins d'images sur le web :
C'est clair non ?
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . En réponse au journal WebP, le format d'images ultime. Évalué à 2.
Un grand progrès, c'est un bien grand mot :)
Par exemple je n'ai pas l'impression que le GIF ait percé dans les jeux aux animations simples, on retrouve souvent la vielle technique du « je mets plein de sprites dans une image et je fais un fichier indiquant la durée d'affichage de chaque sprite ». Alors pour des animations un peu compliquées, genre n lectures entre deux frames, avec allers-retours ou toujours en avant, ou la possibilité de changer dynamiquement la vitesse de lecture, ou encore avec la rotation de certaines frames ; je ne pense pas qu'un autre format d'animation « générique » puisse devenir un standard.
[^] # Re: Animation
Posté par Julien Jorge (site web personnel) . En réponse au journal WebP, le format d'images ultime. Évalué à 1.
J'ai l'impression que lorsque tu parles d'animation tu penses à des présentations à la Beamer ou Impress. Est-ce l'utilisation visée par Google avec le WebM animé ou est-ce qu'il s'agit vraiment de remplacer le GIF pour faire des pandas animés dans les pages web ?
# Animation
Posté par Julien Jorge (site web personnel) . En réponse au journal WebP, le format d'images ultime. Évalué à 2.
Si j'ai bien compris ils ont pris un format vidéo, en ont extrait un format d'image puis ils ont fait un format d'animation. Il n'y a pas une boucle là ?
La différence qui me vient entre une vidéo et un gif animé est que ce dernier permet de faire une animation sur fond transparent. Mais est-ce que le format de vidéo et d'animation n'auraient pas intérêt à être fusionnés ?
# Jamp
Posté par Julien Jorge (site web personnel) . En réponse au sondage Quel est votre lecteur audio ?. Évalué à 2.
Jamp, ou Just a Music Player. Un lecteur maison très simple avec des fonctionnalités de folie et qui correspond bien à ma façon de gérer une liste de lecture : mélanger toute la bibliothèque musicale et l'écouter.
Parmi les excellentes fonctionnalités, on trouve :
- mélanger la liste de lecture en tentant de mettre un minimum d'écart entre deux chansons d'un même auteur ;
- une interface épurée ne comprenant que la liste de lecture et les boutons de lecture, l'ajout de musique se faisant en glisser-déposer ;
- le contrôle de la lecture depuis l'icône de la zone de notification ;
- la possibilité de bannir des chansons pour qu'elles n'apparaissent plus dans la liste ;
- la lecture reprend à la dernière piste jouée quand on relance le lecteur.
Malheureusement il a plein de petits défauts, notamment de ne pouvoir jouer que du 44100 Hz et peu de formats de fichiers (mp3, ogg et flac). Tout ça parce que je n'ai pas le temps de m'en occuper.
[^] # Re: T'as oublié un **autre** détail.
Posté par Julien Jorge (site web personnel) . En réponse au journal Facebook, Google, twitter, etc. libres ?. Évalué à 9.
Est-ce que les fournisseurs de blogs valident le contenu de leurs utilisateurs ? Ici l'auteur poste sur un espace de blog, ce n'est pas un « article » au sens donné par le site. J'imagine que comme sur n'importe quel blog l'auteur peut se permettre de mettre tout et n'importe quoi.
Par contre lorsque j'ai rédigé mes deux articles sur sur leur site il y a eu une étape de relecture et des membres que je trouve très compétents ont apporté leurs critiques. Ça dépend donc de l'espace sur lequel on rédige. Pour ma part je suis toujours étonné de la quantité de fautes d'orthographe dans leurs actualités.
Le problème de developpez.com est qu'ils ont tous les types d'utilisateurs depuis les très débutants jusqu'aux très bons et tout le monde peut facilement proposer du contenu. Et comme sur les autres sites où le contenu provient des utilisateurs (par exemple linuxfr ou wikipedia, au hasard), il arrive que de la merde soit diffusée sans que quelqu'un ne l'empêche.
[^] # Re: Conditionnons dans la joie
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Deux nouveaux CD pour découvrir les jeux libres. Évalué à 10.
Il y a un paquet de jeux de manipulation de boules aussi : 4stAttack, BillardGL, Enigma, FloboPuyo, Neverball, Neverputt, Trackballs.
[^] # Re: Feed back
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee l'ours revient dans les parages!. Évalué à 2.
Effectivement il doit y avoir un paquet disponible pour la version précédente dans la plupart des distributions. Cependant on a remarqué que les versions précédentes se dégradaient avant qu'on sorte les nouvelles. Par exemple, lors de la sortie de la 0.5, la version 0.4 qui était dans Debian testing ne se lançait pas. Et j'ai appris aussi que la version 0.5 pour ArchLinux avait des soucis récemment.
Du coup j'hésite à dire que les paquets sont disponibles si je ne suis pas sûr qu'ils se lancent bien.
[^] # Re: Quelques remarques
Posté par Julien Jorge (site web personnel) . En réponse à la dépêche Plee l'ours revient dans les parages!. Évalué à 8.
Merci pour ces précieux retours :)
On prenait soin pour les précédentes version de sortir un tar.gz avec les binaires pour Ubuntu, mais plutôt une fois qu'on a reçu les premiers retours. Le problème c'est qu'à force je ne sais plus choisir quelle version faire et je me fais mal au crâne à me demander est-ce que j'en fais une pour Natty ? pour la LTS ? en 32 ou 64 bits ? et pourquoi pas faire une VM avec d'autres distributions pour faire de même ?
Le cycle compilation, test, empaquetage, upload est vraiment chronophage et il y a toujours des petits problèmes après les sorties qui m'obligent à le répéter. Par exemple, j'ai remarqué hier que le jeu ne compilait pas si libclaw n'était pas pris en checkout du svn. Du coup j'ai du refaire les .tar.gz sources et faire l'upload. Et encore je n'ai pas eu à refaire les binaires, mais lors du prochain rapport de bug ça ne sera peut-être pas si simple.
Au final, tout cela fait beaucoup de boulot pour une petite équipe d'une personne et demie, alors je me contente de faire la version source, la version Windows et je suis mainteneur pour le paquet Debian. Je laisse le reste à la communauté :) (qui s'en charge plutôt bien d'ailleurs).
C'est intéressant que tu l'aies remarqué car à force de jouer ça ne nous choque pas du tout. Les ressources que tu donnes sont intéressantes et effectivement on devrait pouvoir facilement adapter la vitesse de lecture de l'animation à la vitesse. Je garde ça en tête.
Je crains de ne pas voir le problème. Les pierres ne sont pas indispensables pour atteindre la fin du niveau et il est de toute façon toujours possible de revenir en arrière dans le niveau pour récupérer les objets oubliés. Peux-tu préciser comment tu t'es retrouvé coincé ?
Tu as bien remarqué que les touches par défaut dépendent d'habitude de l'agencement du clavier. Pour éviter d'avoir à deviner le clavier du joueur, on s'est surtout basé sur les touches flèches, control, alt et shift, mais j'ai l'impression que n'importe quel choix sera insatisfaisant quoi qu'il arrive.
# Retours d'expérience
Posté par Julien Jorge (site web personnel) . En réponse au journal Jeux: Participer au dév un jeu de civilisations. Évalué à 3.
Bonjour,
Un peu comme plusieurs commentateurs ci-dessus, je pense aussi que tu te lances dans un projet monstrueux, limite infaisable, et je t'encourage à le tenter. J'ai aussi une bonne expérience de long développement sur un jeu. Voici quelques retours sur mon expérience, si ça peu t'aider.
On a commencé notre jeu à deux développeurs motivés, plus un bon graphiste et un bon musicien qui nous faisaient des images et des musiques. Ça me semble pas mal pour un jeu amateur. Résultat des courses : cela fait six ans que le jeu sera fini en trois ans.
La principale cause de l'avancée très lente du projet est sans doute les développeurs. Il nous est arrivé très souvent de nous lancer dans des petits changements de structure du jeu en nous disant que ça l'améliorerait ou que ça faciliterait le développement. Mais la principale raison était que ça nous plaisait. Résultat, nous avons régulièrement passé du temps à améliorer le peu existant plutôt que de continuer le jeu. Ces petites parenthèses cumulées aboutissent à un grand retard.
C'est un point auquel il faut faire attention. Quelle est ta priorité dans le développement ? Le loisir, l'apprentissage, la diffusion ? Si ta priorité est de diffuser le jeu, alors il faudra être un peu rigoureux et se forcer à faire l'utile avant l'amusant. Ce n'est pas toujours facile.
L'autre difficulté est la recherche de contributeurs. J'ai dis plus haut que nous avions un graphiste et un musicien, et bien ils ne sont pas restés longtemps. À mon avis, le plus grand problème était le temps nécessaire pour que leurs contributions apparaissent dans le jeu. Typiquement, le graphiste nous fait des animations avec Gimp et sort des gif pour voir le résultat. Pour les mettre dans le jeu il faut construire une grande image où toutes les image de l'animation sont côte à côte, construire un fichier d'animation pour rassembler tout ça, gérer les boucles, la durée… et lier cette animation à un fichier de personnage. C'est beaucoup trop d'étapes pour un dessinateur.
Nous avons eu régulièrement des contributeurs, souvent suite à une demande d'aide dans des forums, mais jamais sur une longue durée. Si des gens acceptent de contribuer, il faudra prendre en compte que contrairement à toi, ce n'est pas leur jeu. Par conséquent, s'ils rencontrent des difficultés à ajouter leurs contributions, ils se démotiveront. Idéalement, il faudrait qu'on puisse modifier des éléments du jeu sans effort : je mets une image, un son ou un fichier dans un dossier, je vois le résultat rapidement. S'il faut un trop long protocole pour tester (« tu mets un fichier là, tu compiles tel truc puis tu relances avec tel paramètre »), tes contributeurs vont se lasser.
Tu peux regarder sur gamedev.net pour trouver des contributeurs. Il y a du monde intéressé, mais du coup un peu de concurrents aussi.
Pour un projet comme le tien, je pense que tu as intérêt à prioriser la diffusion du jeu. Fait une base qui tourne, même si c'est moche. Si c'est amusant tu auras suffisamment de joueurs pour que des contributions apparaissent. Puis tu pourras améliorer l'aspect et les fonctionnalités. Quant au langage… prend un truc populaire. Java a beau me déplaire il y a du monde capable de l'utiliser. Si tu veux coder vite c'est sans doute le langage pour lequel tu trouveras le plus facilement des contributeurs. T'auras le temps d'investir sur la qualité du code quand tu auras des joueurs :)
Voilà, c'est un peu long mais j'espère que c'est utile :)
Bon courage.
# Oui, mais pas le même genre de logiciels
Posté par Julien Jorge (site web personnel) . En réponse au journal Programmez vous chez vous?. Évalué à 10.
Je passe ma journée à faire du Java et de l'ActionScript sur de l'application d'entreprise. J'aime ce que je fais mais j'ai toujours un pincement au cœur à utiliser ces langages. Moi j'aime bien le C++. Et j'aurais bien aimé faire du jeu vidéo. Et du logiciel libre aussi.
Alors quand je rentre, je suis content de pouvoir programmer un jeu vidéo en C++, libre en plus ! Mais c'est parfois dur parce qu'il faut se caler une tâche d'une heure ou deux et qu'en plus je suis crevé. C'est vraiment du développement de loisir du coup.
[^] # Re: Thunderbird + compactheader
Posté par Julien Jorge (site web personnel) . En réponse au message Un client mail qui ne s'étale pas trop. Évalué à 1.
Je vais regarder ça après le boulot, ça a l'air bien.
[^] # Re: mutt
Posté par Julien Jorge (site web personnel) . En réponse au message Un client mail qui ne s'étale pas trop. Évalué à 1.
Je viens de regarder un peu les options de Claws Mail (oui je n'avais pas trop cherché avant de poser la question…) et je vois que le raccourci du V est présent aussi. Il y a aussi d'autres dispositions disponibles dont « Petit écran » mais je me suis perdu en l'utilisant.
Je vais explorer ça un peu plus.
[^] # Re: mutt
Posté par Julien Jorge (site web personnel) . En réponse au message Un client mail qui ne s'étale pas trop. Évalué à 1.
C'est bien ce que je craignais :'(
Je suis un peu surpris que l'interface des clients de courriel n'ai pas changé en 10 ans. On a toujours la même présentation en trois cadres, ça manque d'innovation.
[^] # Re: Utilité
Posté par Julien Jorge (site web personnel) . En réponse au journal Unicode. Évalué à 1.
Je reformule. Je dis qu'on peut mettre un texte alt plus fidèle à l'image. Entre « visage qui sourit », « :-) » et « ☺ » il me semble que le dernier est le plus fidèle.
Je pensais plus à la fidélité qu'à l'accessibilité aux handicapés. C'est sûr que ce n'est pas le meilleur pour l'aveugle.
# Utilité
Posté par Julien Jorge (site web personnel) . En réponse au journal Unicode. Évalué à 3.
Ça pourrait remplacer les smileys actuellement affichés comme images ou ascii-art. Avec ces symboles on a un dessin accessible qui reflète l'expression et qui est copie-collable aisément.
Après pour ce qui sort des bonhommes, j'ai du mal. Peut-être qu'ils veulent faire des interfaces user-friendly en mode texte ? Il y a des types de ncurses dans le consortium ?