Julien Jorge a écrit 532 commentaires

Oui oui, le bouton retour arrière est celui que j'essayais de nommer Back. Je mets ça dans ma liste de trucs à faire.

Pourquoi ne pas poster le jeu F-DROID qui un "magasin" opensource d'application opensource pour android tout à fait sympathique ?

Je ne connaissais pas, je vais regarder !

De plus j'ai lancer le jeu, mais je n'ai pas trouver comment en sortir, je veux dire par là mettre fin à l'application !
Je sais c'est pas à la mode sur téléphone les menus "Quitter", mais moi j'aime bien terminer les taches dont j'ai plus besoin !

J'avais implémenté le bouton pour quitter mais cela va clairement à l'encontre des directives de développement pour Android. La politique est que les applications ne doivent jamais quitter d'elles-mêmes. Du coup j'ai enlevé le bouton.

Pour quitter il faut donc appuyer sur le bouton Home de l'appareil, par exemple. J'ai fait attention à réduire autant que possible la consommation du jeu en arrière plan (il ne devrait réagir qu'aux événements du genre « réactivation du jeu »).

Éventuellement je pourrais implémenter un retour à l'écran principal en pressant le bouton Back quand on est dans le sélecteur de niveau, pour permettre de sortir sans quitter.

Je te rejoins là dessus. Je me retrouve aussi avec des commentaires qui ont l'air de reprendre le nom des méthodes mais je me sens obligé de les mettre pour expliciter le fait qu'il n'y a rien de particulier, pas de surprise, dans l'implémentation de la méthode.

J'ai pour habitude de compiler les versions Windows de mes jeux en utilisant Wine, après y avoir installé et compilé toutes les dépendances. C'est un peu galère sur plusieurs points, notamment parce que MinGW est super lent et galère à mettre à jour, que certaines bibliothèques mettent par défaut une éternité à compiler (Boost notamment) et que CMake ne trouve pas les bibliothèques tout seul sous Windows. Du coup j'évite de modifier le ~/.wine/drive_c et d'y mettre à jour les bibliothèques et outils.

Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ? Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?

G'MIC fait des trucs supers mais son intégration à GIMP n'est pas géniale. On se retrouve avec deux ensembles de filtres dans deux interfaces différentes : les filtres par défaut de GIMP et ceux listés dans la boîte de dialogue de l'effet G'MIC. J'aurais préféré avoir les filtres G'MIC éparpillés dans les menus existants et dans les bonnes catégories.

Il y avait déjà CMake pour remplacer ces horreurs.

D'ailleurs CMake génère des Makefiles ; on va pouvoir faire des scripts CMake qui génèrent du Makefile Guile qui génère du CMake…

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 !

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