Fin décembre, j'avais décidé de participer au #1GAM, concours sans enjeux si ce n'est le défi personnel de créer et surtout terminer, pendant 12 mois, une moyenne d'un jeu par mois.

En restant simple et organisé, cela semblait possible. Les deux premiers jeux semblaient donner le rythme et cela semblait tenable.

Mais aujourd'hui, fin juin, alors que je peine à avancer sur le troisième jeu, prévu pour fin mars, me voici devant ce que l'on appelle « le mur ». Le mur, c'est le moment du projet où plus rien n'avance. Plus de vision clair sur ce que doit être la prochaine tâche, des dysfonctionnements un peu pénible qui nécessiterait de se plonger vraiment dans un projet qui traîne en longueur ; globalement, une perte de motivation générale.

Que s'est-il passé ?

Le jeu partait sur le thème d'un « Rogue-like », proposé optionnellement par #1GAM pour mars. J'ai souvent joué à des Rogue-like, Nethack et autres du genre. Mais jamais développé un jeu de ce genre.

J'ai donc commencé à me renseigner un peu sur le site Rogue Like Development et trouvait ce guide qui donnait une idée générale des étapes à suivre. Suivre ce guide fut ma première erreur, due à deux facteurs.

Le premier était de développer le Rogue-like depuis ses fondations. C'est faisable lorsqu'on connaît l'exercice, mais justement, je ne connaissais pas les étapes et donc les pièges, de ce type de jeu. Vu le timing serré nécessaire pour #1GAM, j'aurais du utiliser un moteur de Rogue-like déjà fait et y ajouter la couche de Gameplay. Il en existe, je les avais vu.

Le deuxième facteur était de m'écarter de ce que j'avais considéré comme une bonne pratique pour les deux projets précédents : une phase de brainstorm et entrée de tâches par priorité et nécessité en phase préparatoire, afin de « programmer » ma phase de développement avec des tâches simples et réalisables unitairement et rapidement.

Si suivre les premières étapes du guide ont été faciles, je me suis rapidement rendu compte que mon développement manquait de structure. Ce guide indique de grandes étapes, mais ne micro-gère pas les mini-étapes. Or pour mon développement qui consiste en de petites phases séparées, ce découpage est nécessaire.

Ma seconde erreur a été de m'acharner. Récemment, j'ai croisé une méthode nommée Mikado dont je n'ai lu que l'introduction et l'abstract, mais qui m'a interpellée. Si je comprends bien, la méthode propose un processus assez radicale où si un développement ne correspond pas parfaitement au but atteint, il est effacé et recommencé.

Cela semble un peu fou comme ça, mais cela me parle.

Je sais déjà d'expérience que les méthodes qui ont l'air de faire perdre du temps de prime abord (comme le TDD font gagner sur le moyen/long terme. Et je sais aussi que s'enfoncer dans de la dette technique n'amène rien de bon.

Appliqué à ce projet, je me dis que j'aurais du revenir sur mes pas quand je me suis aperçu que le design du programme ne me satisfaisait pas. Fort de l'expérience du premier essai, le second peut être meilleur.

Et dans le cas d'un #1GAM, j'aurais tout simplement du m'arrêter fin mars, plutôt que de délayer d'autres projets qui auraient pu être fait sur avril/mai/juin.

Aujourd'hui, j'arrête donc sur ce projet. Si je le reprends, ce sera sur d'autres bases et fort de nouvelles connaissances.