Je n'ai jamais participé à un Ludum Dare. Parfois par manque d'inspiration,très souvent par manque de temps, parfois tout simplement parce que le temps que je m'aperçoive que ça avait commencé, c'était déjà terminé. Pour le Ludum Dare 25 qui vient d'être organisé, j'ai été au courant à peine quelques heures après le lancement, le thème m'inspirait et j'avais même une idée amusante (du moins j'imagine).

Mais comme souvent, j'avais aussi un week-end qui ne laisse pas de temps à cette activité. Même le Jam, catégorie spécifiquement prévue pour ceux que la vie réelle impactent et qui laisse un jour le plus et des règles plus libres, me semblait trop restreint.

J'ai donc un peu travaillé le sujet dans ma tête et, au bout de 24h sans avoir eu le loisir de vraiment me poser sur le sujet, j'ai abandonné l'idée de participer.

Cependant, je regarde d'un œil ce que lance Ebene qui annonce sa participation sur un réseau social bien connu.

Le dimanche soir, elle annonce que son développeur ne pourra pas terminer le projet. Du coup, je regarde d'un peu plus près ce qui a déjà été fait côté game design et graphismes. Ça me plaît. Et côté programmation, ça me semble faisable en un week-end pour quelqu'un qui s'y atèle et et je pense pouvoir trouver en une semaine le temps correspondant.

Je propose donc à Ebene de faire ce que je peux. Pas de garantie. De mon côté, dépoussiérer mon Javascript + HTML sur un vrai projet me paraît enrichissant. Donc go.

Au bout d'une semaine, l'implémentation est à un niveau correct. Quelques heures supplémentaires seront prises sur la semaine suivante pour peaufiner un peu.

Dans la tradition des post-mortems, je vais répondre à deux questions : qu'est-ce que je pourrais améliorer et qu'est-ce qui s'est bien passé ?

Qu'est-ce que je pourrais améliorer ?

Javascript

Mes précédentes expériences m'avaient déjà donné un goût de la chose. Ce n'est pas pour rien que ce langage, avant d'être popularisé par l'arrivée d'AJAX puis confirmé par HTML5, était très mal considéré. Si les itérations sont rapides (ajout du fonction, rechargement de la page,...), les nombreux pièges m'ont beaucoup ralentis au début, le temps que je me les remémore.

Au fil du développement, les erreurs se sont atténuées, mais pas effacées complètement.

J'étais sur ma lancée et je ne pouvais pas trop m'arrêter pour me faire un environnement confortable. Cependant, sur la fin du développement, je suis allé fouiller dans les programmes d'analyses statiques de type jhlint. Cela m'a permis d'améliorer deux trois petites choses, mais ça aurait été surtout intéressant pendant le développement pour éviter un test alors qu'un des fichiers contienne une erreur de syntaxe.

Au final, Javascript a besoin d'une toolchain qui puisse vérifier en continue les erreurs évidentes. La plupart des outils que j'ai pu tester depuis sont cependant assez lourds au lancement, ce qui atténue la force de l'environnement en ce qui concerne son temps d'itération.

L'autre piste que je peux étudier, c'est d'utiliser des langages construits au dessus de Javascript, comme CoffeeScript ou Dart.

Outils garde-fou

Analyse statique ou environnement de tests, des outils que je trouve indispensables professionnellement au quotidien et dont j'ai du me passer pour cette exercice. En effet, je n'en connaissais pas, ou en tout cas pas assez pour me reposer dessus.

Avant de démarrer une prochaine session de ce type, il me faut tout ça en place et à peu près maîtrisé. Ce sont de grands vecteurs de gains de temps et le temps, c'est une ressource très précieuse.

Distribution / Collaboration

Nous étions deux sur le sujet. Ebene fournissant le document de Game Design, les ressources graphiques, les intégrations HTML et les données du jeu. Toutes ces données étaient disponibles via HTTP.

De mon côté, je fournissais irrégulièrement une archive de mon dépôt Mercurial avec le jeu fonctionnel.

Mes opérations étaient donc :

• aspiration différentielle du site via wget lorsqu'une mise à jour était signalée.- copie des données voulues sur mon dépôt.- comparaison des modifications (surtout sur les fichiers HTML/CSS) et report dans le fichier d'intégration finale.- export des données de jeu vers le format utilisé par le programme.- vérification et submit.

Puis, après une séance de travail sur une amélioration :

• création de l'archive.- envoi de l'archive via sftp sur un dépôt servi en HTTP.- signalement de la mise à jour.

Ce sont beaucoup de manipulations manuelles qui devraient être automatisées.Ce que je vois en améliorations :

• travailler sur un dépôt commun, pas essentiel, mais intéressant.- pour un jeu en HTML, mieux réussir l'intégration en prévoyant mieux la manière de récupérer les pages.- automatisation de l'export des données.- système de build en continu avec analyse statique et création automatique d'une archive et/ou d'un déploiement.

Qu'est-ce qui s'est bien passé ?

1. Un game design bien détaillé / une première version des données fonctionnelles : merci à Ebene pour ça. Mises à part quelques questions pour éclaircir certains points, j'ai pu avancer vite grâce à une bonne idée de ce que devait être le jeu, même si je l'ai vraiment découvert en l'essayant au fur et à mesure de l'implémentation des fonctionnalités.

2. Le choix de la plateforme. Malgré ce que j'ai pu dire sur Javascript, utiliser du HTML scripté convient très bien pour un jeu de ce type.

Un éditeur de texte, un navigateur avec des outils de développeurs (j'ai utilisé Firefox + Firebug) et voilà. Le peu de données nécessaires au jeu permet de le démarrer rapidement et de travailler par petites itérations.

1. Boucle de développement.

La boucle de développement que j'ai respecté globalement était : choix d'une fonctionnalité manquante, prototypage de la fonctionnalité, écriture de la fonctionnalité, assainissement.

Le fait de régulièrement assainir le programme a évité, malgré l'absence d'utilisation d'outils de vérification de qualité, l'accumulation d'une trop grande dette technique.

Même sur un aussi petit projet, la dette peut rapidement s'envoler et réduire la rapidité de programmation de manière drastique. Avec son corollaire : augmenter la frustration des fonctionnalités bancales.

Cela m'a aussi permis de bien veiller à séparer les différentes responsabilités, principalement la logique du jeu et son intégration HTML.

1. Temps de développement

Afin de vérifier qu'un tel développement était possible pour une personne côté programmation lors du game jam, j'ai tracé le nombres d'heures passées.

L'arrivée à un niveau « beta » (jeu fonctionnel mais avec quelques bugs mineurs) a pris 20h environ, dont 5h dans un vrai état de concentration. L'autre quinzaine d'heure a été passée dans un environnement avec des distractions.

Autrement dit, pour quelqu'un qui bénéficie d'un environnement dédié à la participation à l'event, entre 10 et 15h étaient nécessaires. Largement suffisant pour un game jam.

Après la version beta, les petites améliorations et corrections de bugs ont du prendre deux ou trois heures réparties sur une semaine par petites interventions.

Conclusion

L'expérience était vraiment intéressante et le résultat est plaisant. J'ai pu progresser en Javascript + HTML sur un vrai projet et j'ai de nouvelles pistes pour améliorer ma façon de travailler. Mon défi personnel étant de pouvoir être assez efficace pour profiter au maximum des moments courts dont je dispose.

Et le jeu ? Il est là (pour une meilleure expérience, passez en plein écran avec probablement la touche F11 de votre navigateur) (MAJ : lien mort, et qui ne fonctionne pas sur archive.org).

Mais aussi : le billet de présentation du jeu, les explications, les game design et plus encore, ainsi que le billet précédent.