Julien Jorge a écrit 526 commentaires

Nous utilisons un gestionnaire de bugs (Trac) pour poser les tâches toutes les deux semaines et pour lister les problèmes et améliorations désirées au fur et à mesure que nous les rencontrons.

Je n'imagine pas mettre toutes les spécifications dans le gestionnaire dès le départ, tout d'abord parce que nous faisons une relecture des tickets toutes les deux semaines, ce qui nous impose de garder une liste courte pour éviter d'y passer la journée. Ensuite parce que beaucoup de tâches ne sont pas pertinentes tant que d'autres ne sont pas faites, ou alors elles risquent de changer en fonction de l'avancement. Dans ce cas nous nous retrouverions avec beaucoup de bruit dans le gestionnaire.

Tu indiques aussi le temps estimé ?

Pour Plee the Bear et Andy's Super Great Park, une fois la bible écrite, nous avions fait un tableur reprenant les trucs à faire et une estimation du temps nécessaire. Nous avions choisi de compter en demies journées et à la louche. L'idée n'est pas d'être précis mais plutôt d'avoir une valeur pour comparer les éléments. Il s'agit aussi de discuter de chaque point pour lever rapidement les problèmes éventuels.

Les estimations pour Plee the Bear sont en ligne.

Pour l'exemple voici la bible de Plee the Bear (qui n'est pas fini). Pour Andy's Super Great Park (qui est fini) nous étions partis sur plus petit : nous nous en sommes sortis avec une feuille et un tableur listant les trucs à faire.

Dans les deux cas l'approche est la même : nous commençons par poser les concepts du jeu et nous notons quoi fait quoi à chaque moment du jeu.

Ensuite nous nous servons de cela pour poser nos jalons, en commençant par décider d'un horizon de livraison (deux fois 3 mois pour Andy's Super Great Park). Toutes les deux semaines nous nous posons la question « que voulons-nous voir dans le jeu dans deux semaines ? ». Nous notons toutes les réponses dans des tickets de Trac et nous nous mettons au boulot.

Il nous arrive de revenir sur des décisions de la bible au fur et à mesure de l'avancement, voire d'ajouter des nouveaux trucs, mais grâce au rythme imposé nous avons une bonne vision de ce que cela coutera. Du coup nous pouvons trancher sur l'inclusion, le report ou l'exclusion assez facilement.

Je pense aussi que tu as tout à gagner à écrire une bible qui détaille chaque élément du jeu. J'ai eu l'expérience d'un jeu commencé en 2005 qui devait aussi être terminé en 3 ans, j'étais aussi très motivé et il n'est toujours pas fini. Le bilan est clair, à chaque fois que j'ajoutais du contenu au jeu, je rajoutais des fonctionnalités parce que « ça sera mieux ! ».

Tout a changé quand j'ai commencé à poser sur papier tout le contenu attendu. Maintenant je fais des estimations de temps correctes et je ne dérive pas durant la production.

Donc je pense que ça vaut le coup de le faire. Ça prend une demie-journée pour un petit jeu et ça fait gagner un temps infini.

Ce n'est pas dans un forum mais ça n'empêche pas de poser la question : qu'en est-il du salaire ? Est-il libre ? Fonctionnez-vous en bring your own money ?

As-tu rencontré des problèmes à l'utilisation d'emscripten ? J'ai essayé de l'utiliser plusieurs fois sur une grosse base de code et j'ai toujours rencontré un paquet de petits problèmes dans des entêtes standards comme climits et dans Boost.

De plus le site du zéro ne donne pas forcement les bases de l'algorithmique. Encore une fois pour commencer c'est bien, pour avoir les connaissances de base c'est un autre problème et j'aurais tendance à me tourner vers des livres.

Comme les livres du zéro par exemple ?

Si vous ajoutez brainf**k, je tiens à ce que Goto++ fasse aussi son entrée !

Les sites qui reçoivent du contenu de leurs utilisateurs ont plutôt tendance à s'approprier les droits via un sombre article dans les conditions générales, alors quand un site les mets en libre, je trouve déjà cela bien.

Lors de la livraison, OpenFunding demande aux donateurs de confirmer que le travail est effectivement fait comme il avait été annoncé. Les donateurs ne peuvent pas se faire avoir sur cette plate-forme : si l'objectif n'est pas atteint, l'auteur peut quand même faire son projet et j'en bénéficie ; si l'objectif est atteint, je peux reprendre mes sous si c'est mal fait.

Et puis c'est uniquement pour des jeux libres, alors que jeuxlinux.fr parlait de tous les jeux sous Linux.

Je pense qu'il y a les deux. Comme dit dans un autre commentaire, SPIP n'a plus la côte, et de toute évidence le site manque d'énergie. Enfin moi qui ai proposé les news de mes jeux sur le site, je vois que ça ne répond pas.

Peut-être aussi que le public visé par le site est trop petit pour donner de la motivation aux créateurs et pour générer de nouveaux contributeurs ?

Il me semble que jeuxlinux.fr a atteint l'état où plus personne ne veut travailler dessus. Il est temps de mettre en place une alternative puis de l'achever.

Un envoi d'une démo a tous les magasines/sites spécialisés, une page web fait-maison-comme-on-peut, une inscription au programme greenlight de steam, pis c'est marre, non ?

Une fois que tu as fait cette partie de la communication, tu peux recommencer en boucle, alimenter ton jeu de nouveautés pour en reparler à tout le monde, essayer d'amener des gens à voter sur Greenlight, et espérer percer quelque part avant de mourir d'épuisement.

Je t'invite à lire ce billet nommé How we failed — No one cares about our game. L'équipe a fait un super jeu qui est resté complètement invisible. Malheureusement la création du jeu ne compte que pour la moitié du travail, l'autre moitié est la communication.

J'ai testé emscripten pour faire une version web d'Andy Super Great Park (qui est donc écrit en C++) et je ne le conseille pas pour de nouveaux projets. C'est encore trop jeune pour permettre de faire un projet sereinement et il faut donc être prêt à rencontrer des erreurs obscures de compilation. Dans mon cas j'ai notamment souffert pour utiliser Boost. Alors à moins que la personne ait envie de s'impliquer dans le développement d'emscripten autant que dans son projet, je pense qu'il faut éviter pour l'instant.

Je ne suis pas certain que ce genre de comportement soit le bienvenu dans une dépêche qui ne parle pas d'une personne bronsonisée.

J'ai regardé sur la page du paquet Debian et du paquet Ubuntu mais quand je clique sur « liste des fichiers » ils indiquent tous les deux l'installation d'un /usr/share/java/protobuf.jar, quelle que soit la version.

D'après le changelog du paquet Debian il y a pourtant eu une opération de correction d'un bug de protobuf.jar manquant.

Excellent !

•••• •••• •••• ••••
•••
•••••

Quelle idée d'utiliser un site web aussi, alors que findboob ou searchboob auraient trouvé ça out of browsers !

Pour quelle raison est-ce qu'il n'y aurait pas de mises à jours sur un vieux logiciel? Je ne vois pas trop ce que vient faire l'âge là dedans. Un projet avec 0 utilisateur, 0 utilisation ou 0 bug n'a pas besoin de mise à jour mais tous les autres, si!

Je me dis qu'un vieux logiciel complet, qui est encore utilisé, et qui n'a pas été remplacé par un petit nouveau tout brillant doit voir son nombre de bugs et de besoins diminuer. Hormis pour les projets qui tentent des réécritures complètes ou des fonctionnalités hors cadre, j'ai le sentiment que ça doit tendre vers le zéro bugs, zéro besoins avec le temps, non ?

C'est sympa d'avoir des nouvelles de ces vieux outils GNU. Honnêtement je ne pensais pas qu'ils recevaient encore des mises à jours. Mais qu'est-ce qui est nouveau ici ? La dépêche présente le projet, nous dit qu'il y a une nouvelle version, mais ne nous dit pas ce qu'elle apporte.

Et puis avec des petits exemples d'utilisation ce serait encore plus cool.

Pour ma part j'utilise une disposition bépo sur un clavier azerty. J'ai vraiment gagné en confort et je peux faire des trucs de fous comme taper en regardant quelqu'un d'autre, ou encore mieux : coder en réfléchissant.

J'utilise d'ailleurs Emacs moi aussi, et ça ne fait pas de différence. En fait je ne vois pas pour quelle raison Emacs inviterait à regarder le clavier plus souvent.

Il n'y a pas de section dédiée mais il y a des offres d'emploi qui sont très bien

Ceci dit, si je cherchais un bon pour ma boîte, je ne posterais pas dans les forums. À la place je ferais un journal où je parlerais de mon travail ou d'un projet qu'on aurait fait. Un truc qui ressemblerait à:

Bonjour à tous, je voudrais vous présenter nom du projet. Il s'agit d'une application de objet fait en technos et disponible sous les termes des contrats contrats.

Description détaillée du projet en quelques paragraphes, avec captures. Explication de pourquoi c'est cool et qu'est-ce qui n'a plu, etc.

Ma boîte cherche d'ailleurs des gens supplémentaires en type de contrat pour faire ce genre de projets. L'ambiance est sympa et les salaires des dev autour de salaire brut annuel K€. On a des tickets resto, une mutuelle, on fait du scrum, et la ville est belle.

Ce que je ne mettrais surtout pas : le nombre de collaborateurs, le chiffre d'affaires, la position de la société à l'international, et tout le bla bla classique sur la taille de mon énorme boîte.

J'ai aussi l'impression que ça manque d'une section où les visiteurs pourraient poster leurs contenus courts tout en ayant une visibilité assez grande pour ne pas préférer en faire des journaux. En plus ces contenus y seraient certainement mieux notés et appréciés que dans les journaux.