Journal Maki à la vapeur

39
25
oct.
2013

Bonjour Nal,

Je t'écris pour te donner des nouvelles de mes projets libres. Au menu, nanimstudio, Newton Adventure, un nouveau jeu (Ned et les maki) et de nouveaux projets (libtiled-jaxb et lwjgl-nuit).

nanimstudio

Mon logiciel d'animation 2d continue à évoluer au fil de mes besoins et des retours des utilisateurs. Après le support de l'APNG et quelques améliorations de l'ergonomie, mon prochain grand chantier est l'ajout d'algorithme de scaling. Pour cela j'utilise la bibliothèque scilter. Le but est de pouvoir prévisualiser les sprites tels qu'ils pourraient être affichés en jeu via des shaders implémentant des techniques d'agrandissement dédiées au pixel art (scale2x, hqx, rotsprite…).

scale3x

Site officiel
scilter

Newton Adventure

Mon projet le plus important continue sa carrière commerciale sur Greenlight. Il s'agit d'un système dédié aux jeux qui candidatent pour être vendu via la base de données sociale / plateforme de vente / adware / DRM / … préférée joueurs PC: Steam. Les clients peuvent voter pour dire s'ils seraient intéressés par l'achat d'un jeu candidat. A partir d'un certain nombre de vote et suivant des calculs et des critères internes à Valve, le jeu peut être accepté.

Si vous êtes du côté de Nice, je présente le jeu sur un stand au JM2L le mois prochain!

Site officiel
La page sur Greenlight
Le site des JM2L

Newton Adventure sur Greenlight

Ned et les maki

Si vous suivez linuxfr régulièrement, vous avez peut être vu que les Geeky Goblin Productions ou GGP ont passé une annonce pour recruter des développeurs pour un projet de jeu. Je suis l'un d'eux!

La production a démarré sur les chapeaux de roue: on a déjà des graphismes, un petit moteur d'affichage, le gameplay est bien défini… J'espère même avoir une petite démo pour les JM2L!

Ned et les maki

Bien sûr comme dans tout projet libre, il a fallu faire des choix techniques et politiques difficiles. Heureusement l'équipe a l'esprit de compromis, ce qui nous a permis de faire rapidement les choix suivants:

Moteur de jeu

La solution retenue est basée sur Java, lwjgl et de gros bouts du code de Newton Adventure!

C++/SDL et Monogame ont été envisagé, mais le premier a dû être écarté pour des raisons de productivité et d'intérêt: j'ai fait valoir que les releases multiplateformes et la gestion des dépendances en C++ sont des tâches très consommatrices de temps et au niveau d'intérêt intellectuel proche de 0, ce qui est contraignant pour qui travaille sur son temps libre. Le second n'a pas été retenu à cause du rejet général de Mono par la communauté libre et de l'incertitude quant à son avenir après l'abandon de XNA par Microsoft (Monogame est une implémentation de XNA).

Licences

Le choix des licences a été compliqué. Les GGP voulaient du Art Libre et seulement du Art Libre. Je voulais que le code soit sous BSD (pour pouvoir échanger du code avec mes autres projets) tandis l'autre développeur préférait MIT. Ce sera finalement MIT pour le code et Art Libre pour les données. La licence MIT permettant le sublicencing, les GGP pourront ainsi distribuer le jeu entièrement sous Art Libre!

Outils pour le travail collaboratifs

git a été choisi pour partager les sources et gérer les versions. Là c'est plus une question de personne n'a jamais été viré pour avoir choisi git

En attendant une mise à niveau du serveur des GGP, nous utilisons une instance de gitlab et des dépôts sur github

Editeur de niveau

Le choix d'une vue en 3d isométrique nous a amené à choisir Tiled pour l'édition des niveaux. Là aussi c'est un choix par défaut, car il n'y a pas beaucoup d'alternatives sur ce "marché".

Nouveaux projets

Je profite du développement de Ned et les maki pour y faire "incuber" deux nouveaux projets de bibliothèques Java:

  • libtiled-jaxb: un parseur moderne pour les fichiers de Tiled. Ceux qui existent ont le gros défaut de charger les images avec java.awt ou android.graphics, ce qui ralentit considérablement le chargement des niveaux puisque ces API stockent les bitmaps dans des formats qu'il faut convertir en texture OpenGL. Ma bibliothèque laisse le jeu faire le chargement lui même.
  • lwjgl-nuit: une bibliothèque pour créer des interfaces graphiques pour les jeux écrits avec lwjgl. Il en existe déjà plusieurs, mais aucune ne permets de contrôler l'interface uniquement avec une manette de jeu. Je joue souvent en utilisant mon PC comme une console, j'ai donc envie que mes jeux puissent être joués sans avoir à sortir un clavier et une souris.

Que faire après ce journal?

Voici quelques suggestions pour l'après lecture de journal:

  • essayer les projets évoqués.
  • voter sur Greenlight.
  • poster des commentaires pertinents.
  • regarder la nimage de fin, car sur linuxfr, tout finit par des nimages:

nimage

  • # Commentaire supprimé

    Posté par . Évalué à 6.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Mmh

      Posté par (page perso) . Évalué à 3.

      Je fais aussi partie de l'équipe de développement et partisans du c++ au début. Et effectivement c'est la grand base de code java de newton adventure, et l'expérience de dev dans la programmation de jeu vidéo en java qui ma convaincu de travaillé avec ce langage semi-compilé.

      Peut-être que si j'avais découvert crossroad plus tôt je me serai plus battues pour le c++

      Merci pour le bouquin sa fait long temps que je cherche a une bonne référence pour comprendre autotools.

    • [^] # Re: Mmh

      Posté par (page perso) . Évalué à 3.

      La grosse raison de ce choix, j'ai l'impression que c'est plutôt que tu as une grosse base de code java déjà disponible. Je peux me tromper à ce sujet.

      Disons que si j'avais sous la main un template de projet C++/SDL avec autotools, crosscompilation et gestion des dépendances pour Linux, Windows et Mac qui marche aussi simplement qu'un mvn package, je reconsidérerais la question.

      http://devnewton.bci.im

      • [^] # Commentaire supprimé

        Posté par . Évalué à 3.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Mmh

        Posté par . Évalué à 2. Dernière modification le 25/10/13 à 15:59.

        Et as-tu consideré le remplacement de autotools par cmake ?

        Moi mes projets, c'est c++, cmake, sdl, opengl, qt (pas forcément tout en même temps)

        ce que je trouve bien dans cmake, c'est que pour faire un truc simple, c'est simple !

        • [^] # Re: Mmh

          Posté par (page perso) . Évalué à 2.

          cmake ou autre… Je voudrais un maven like pour C++, car les releases, c'est ma hantise.

          http://devnewton.bci.im

          • [^] # Re: Mmh

            Posté par . Évalué à 2.

            Effectivement, ne dévellopant généralement que pour moi, je n'ai jamais été confronté au soucis de release.

            Que fait exactement maven qui tu aimerais trouver dans d'autres outils ?

            cmake est assez puissant de ce coté là aussi (bien que je ne l'ai jamais utilisé, donc je manque beaucoup de recul sur les possible soucis) et permet de créer des .deb/.rpm installeurs windows et mac et quelques autres avec seulement un descriptif si tu n'as pas de besoin spécifiques pour une plateforme (c'est du coté de CPack qu'il faut regarder)

            • [^] # Re: Mmh

              Posté par (page perso) . Évalué à 2.

              Que fait exactement maven qui tu aimerais trouver dans d'autres outils ?

              La crosscompilation (bon maven ne le fait pas, pour du java on s'en fout, mais pour du C++ c'est obligatoire), la gestion des dépendances multiplateformes et la génération des paquets installeurs.

              Je sais qu'on peut se bricoler ce genre de chose avec cmake, cpack, crossroad, ivy et quelques autres outils, mais ça va me demander des heures hautement inintéressantes avant d'avoir un ensemble vaguement fonctionnel.

              C'est le choix entre monter une voiture à base de pièces détachés sans plan ou en prendre une neuve…

              http://devnewton.bci.im

              • [^] # Re: Mmh

                Posté par (page perso) . Évalué à 0.

                On en revient toujours à la même question, ca va plus vite de prendre un surgelé et le mettre dans le micro onde plutôt que de se taper la bouffe à faire.

                Maintenant lorsque tu fais à manger, tu apprends tout plein de choses qui changent ton regard sur la cuisine. C'est de cette apprentissage (par sérendipité) que viendra l'étincelle qui fera que tu auras évolué, que ta pratique sera plus profonde et que tu pourras choisir la techno adapté qui n'est pas forcément celle que tu connais.

                Si tu savais combien il y a d'experts java qui entravent presque que pouic à la techo et qui pondent du code sous ide (c'est comme sous acide, mais sans les effets secondaires pour le consommateur), code merdique qui fait que naviguer sur ces pages/sur ces softs donne l'impression d'avoir installé xp sur un 486DX2 66 et essayer de regarder une video youtube.

                Lorsque tu montes la voiture tu sais comment elle fonctionne. Alors autant pour un simple conducteur ca peut le faire d'acheter tout prêt, mais pour un garagiste c'est moins fun.

                • [^] # Re: Mmh

                  Posté par (page perso) . Évalué à 6.

                  Effectivement c'est intéressant de monté sa voiture soi même, mais a un moment il faut être un peu réaliste, tu peut pas apprend une nouvelle façon de monté tes pièces et en même temps apprendre a monté un 4x4, alors qu'on monté que citadines jusqu'à récemment.

                  Arrêtons la métaphore on a aussi fait le choix d'utilisé Artémis, un framework permettant d'utiliser un systèmes entités relations. Donc combiné apprendre a utilisé autotools, gères les dépendances multiplateformes, et utilisé un nouveaux paradigmes, sa commence a devenir compliquer.

                • [^] # Re: Mmh

                  Posté par (page perso) . Évalué à 8. Dernière modification le 26/10/13 à 11:20.

                  C'est de cette apprentissage (par sérendipité) que viendra l'étincelle qui fera que tu auras évolué

                  J'ai fait du C++ pendant des années, j'avais même une chaîne de compilation et d'outils proche de ce que j'aimerais, donc je sais très bien ce qu'il faudrait faire. Recommencer ce boulot ça n'a aucun intérêt pour moi: sur mon temps libre, je veux faire des jeux, pas des scripts et des makefiles…

                  http://devnewton.bci.im

              • [^] # Commentaire supprimé

                Posté par . Évalué à 2.

                Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Re: Mmh

                  Posté par (page perso) . Évalué à 3.

                  J'ai souvent entendu parler de la solution claudex< compilation service premium, mais est-ce que ça fait Windows et Mac?

                  http://devnewton.bci.im

  • # Cool

    Posté par . Évalué à 2.

    C'est bien ça, une nouvelle version de nanimstudio ! Du coup, ça tombe bien que tu montres cet exemple parce que j'avais une question à propos des animations à une seule frame. Je vois ici que tu mets la durée à une valeur arbitrairement grande, est-ce que c'est la bonne façon de faire ?

    Le choix d'une vue en 3d isométrique nous a amené à choisir Tiled pour l'édition des niveaux. Là aussi c'est un choix par défaut, car il n'y a pas beaucoup d'alternatives sur ce "marché".

    En fait, plus j'y pense, plus je me dis que Tiled fait soit trop de choses, soit pas assez. Tiled pourrait être un simple logiciel pour construire des cartes et rien d'autres. Le fait est qu'il sait faire d'autres choses comme mettre des formes sur la carte. Mais du coup, ces formes et leur signification dépendent beaucoup du jeu qui va les charger. Et donc, il y a une phase de conversion à faire dans tous les cas. On peut s'en sortir plus ou moins bien avec les propriétés associés aux objets mais ça devient vite lourdingue.

    En fait, Tiled devrait être un composant parmi plein d'autres (qui n'existent quasiment pas) pour créer un moteur de ressources de jeu. Mais ça demanderait beaucoup de boulot, notamment normaliser les besoins des jeux de manière à peu près générique. Tout ça, c'est généralement refait dans chaque jeu, et c'est de la perte de temps je trouve. On pourrait aller beaucoup plus loin. L'autre solution, c'est d'utiliser un moteur de jeu complet, avec tous les inconvénients que ça engendre.

    Ma bibliothèque laisse le jeu faire le chargement lui même.

    Oui, j'ai fait pareil pour libtmx. Même si en C++, on n'a pas un truc plus ou moins standard pour charger les images (à l'inverse de Java), je me dis que les bibliothèques graphiques savent faire ce genre de chose, et le font toutes différemment, donc laissons ce travail facile à l'utilisateur. La seule difficulté, c'est de calculer le bon chemin jusqu'au fichier (puisque les chemins sont déterminés en fonction du fichier courant).

    • [^] # Re: Cool

      Posté par (page perso) . Évalué à 2.

      Je vois ici que tu mets la durée à une valeur arbitrairement grande, est-ce que c'est la bonne façon de faire ?

      Comme il n'y a qu'une frame, la durée n'a pas d'importance. Tu peux mettre -1, 42 ou 1000000.

      En fait, Tiled devrait être un composant parmi plein d'autres (qui n'existent quasiment pas) pour créer un moteur de ressources de jeu

      A ce propos, j'attends de voir ce que donnera la prochaine version de Krita: http://krita.org/item/197-new-clones-array-tool

      http://devnewton.bci.im

  • # Commentaire supprimé

    Posté par . Évalué à 3.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: git

      Posté par (page perso) . Évalué à 2.

      On a voulu aller vite, l'autre développeur connaissait git et voilou. J'aurais bien aimé prendre le temps de réévaluer Mercurial, car git est assez peu intuitif et très galère à héberger.

      Pour les projets persos, je préfère toujours le très bon fossil, mais en équipe, je n'avais pas envie d'imposer un outil que personne ne connaît.

      http://devnewton.bci.im

      • [^] # Re: git

        Posté par (page perso) . Évalué à 1.

        git compliqué a hébergé ? Il faut trouvé la solution qui conviennent a tout le monde la l'équipe est principal composé de néophytes et donc utilisé gitolite n'était pas une bonne idée (certaine personne on du mal avec la notions de clef rsa).

        Une authentification par http nécessité la mise en place d'un système de compte, et sa peut'être embêtant pour les utilisateurs régulier de taper son mot de passe a chaque push ou pull.

        gitlab et la solution qui regroupe les deux système sans être contraint de faire un hack horrible (j'ai envisager une solution basé sur cron pour synchroniser 2 dépôt un avec accès gitlab l'autre avec http).

        Le principal problème de fossil, c'est le packaging la dernière fois que j'ai regardé y avais pas de paquet pour fedora.

        • [^] # Re: git

          Posté par (page perso) . Évalué à 2.

          la dernière fois que j'ai regardé y avais pas de paquet pour fedora.

          Je l'entends souvent celle là ;-)

          http://devnewton.bci.im

      • [^] # Commentaire supprimé

        Posté par . Évalué à 2.

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: git

          Posté par (page perso) . Évalué à 3.

          Créer un groupe, un user, gérer des clefs, avoir un serveur ssh… C'est pas vraiment ce que j'appelle simple et il manque encore le bug tracking et le wiki!

          Avec fossil, tu as juste besoin d'un bête cgi de 2 lignes pour avoir tout ça.

          http://devnewton.bci.im

        • [^] # Re: git

          Posté par (page perso) . Évalué à 3.

          Dit a 3 maceux et 2 windowsiens de te gère des clef publique, et tu vera leurs tête exploser.

          • [^] # Commentaire supprimé

            Posté par . Évalué à 1.

            Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: git

            Posté par . Évalué à 0. Dernière modification le 26/10/13 à 17:13.

            On dit macuser 'spèce de vilain -.-.
            lili retourne bouder sur son krita

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.