Sommaire
Akagoria au bout d'un an
Il y a un an le 16 septembre 2013 était publié le premier épisode de cette série. Et même si Akagoria est né sans doute un peu avant, on peut considérer que sa date de naissance est bien ce premier épisode. Bon, ok, j'ai releasé early, mais pas très often il faut bien l'avouer. Au départ, je me suis donné deux à trois ans pour mener à bien cette aventure. Un an s'est déjà écoulé et je pensais que j'aurais avancé plus que ça. Donc, on va dire plutôt trois ans.
Les réussites
Dans ce qui a bien fonctionné, il y a tout d'abord ces épisodes. Douze épisodes ont été publiés de manière irrégulière mais cela me force à avancer, c'est un motivateur assez puissant. Ils me permettent de partager mes trouvailles, mais aussi de mettre de l'ordre dans mes pensées et de les concrétiser quand il le faut. Et c'est important parce qu'entre une idée dans un TODO et sa réalisation, il y a souvent un delta non négligeable et ça peut prendre plus de temps que prévu. En plus, ces épisodes me permettent de me poser la question : quelle est la prochaine étape ? J'ai à peu près toujours un ou deux épisodes en tête pour le futur quand je publie un nouvel épisode. Là par exemple, je sais ce que sera le prochain, et je sais ce qu'il me reste à faire pour qu'il puisse sortir. Yapluka. Voici donc la liste des douze épisodes pour ceux qui veulent faire du replay :
Je me suis permis de faire quelques statistiques sur ces épisodes. Sur le graphique suivant, on peut voir le nombre de pertinentages et le nombre de commentaires pour chaque épisode. On voit qu'il n'y a pas vraiment de corrélation entre les deux. Les moyennes sont respectivement de 50 et 51 mais cachent en fait de grandes disparités avec quelques épisodes qui font beaucoup monter la moyenne. La leçon de ces chiffres, c'est que ces épisodes vous plaisent et que vous y êtes fidèles.
L'autre réussite de cette première année, c'est d'avoir publié pas mal de code. Je n'avais jamais vraiment publié de code publiquement auparavant et montrer son code au monde entier, ça force vraiment à faire les choses à peu près bien, à mettre de la doc, etc. Je suis plutôt satisfait d'avoir réussi à produire ces codes-sources là. Bien sûr, ils sont perfectibles mais ils permettent déjà d'avoir quelques briques de base. Les bibliothèques notamment sont largement réutilisables par d'autres jeux. Voici les bouts de code produits :
-
libes, une bibliothèque pour gérer les systèmes à entités. Cette bibliothèque se stabilise doucement mais sûrement ;
-
libtmx, une bibliothèque pour lire le format TMX de Tiled, plutôt stable pour l'instant (en attendant les évolutions du format lors de la prochaine sortie de Tiled) ;
-
libsuit, une bibliothèque d'entrées physiques et de widgets, encore en développement et qui suivra les besoins du jeu au fur et à mesure ;
-
MapMaker est un logiciel de création de carte d'altitude, dont la partie commune est stable mais dont la partie spécifique à Akagoria est encore en développement, car je ne suis pas encore satisfait de la manière de construire la carte primitive ;
-
SlowTree est un logiciel de génération procédurale de sprite en vue de haut, encore en développement car je veux continuer à explorer certaines pistes pour certains types de sprites.
J'en profite pour remercier tous les contributeurs occasionnels à ces projets et particulièrement Sébastion Rombauts qui a contribué à libes et à MapMaker grâce à de nombreux patchs. Grâce à lui, vous aurez une version sans bug du bruit à base de simplexe dont on avait parlé dans l'épisode 10 et qui avait manifestement un bug.
Les difficultés
Dans le moins bon, je n'ai sans doute pas avancé autant que je l'espérais au départ. Dans ma tête, j'étais parti sur un planning de deux ans avec un développement important du code la première année, et un développement du reste ensuite (scénario, dialogues, sprites, musiques, etc). Or, le code est très très loin d'être opérationnel pour commencer à développer activement le reste.
Comment expliquer ce retard ? Tout d'abord, le temps est une denrée très aléatoire quand on développe un jeu amateur. À l'automne dernier, j'ai eu pas mal de temps libre et donc j'en ai beaucoup profité pour avancer sur plein de fronts. Mais à partir de début 2014, j'ai baissé le rythme drastiquement, en partie à cause d'une activité professionnelle plus prenante (y compris sur mes week-ends), en partie parce que j'ai fait un peu de hors pistes en allant explorer des choses complètement inutiles pour mon jeu. Je voyais le temps défiler et j'étais dans l'incapacité d'avancer convenablement. C'était très frustrant.
Retour sur les choix techniques
Au bout d'un an, il est temps de revenir sur les choix techniques faits au départ pour se demander s'ils sont pertinents.
Commençons par le plus simple. Il y a des choix que je ne regrette pas : SFML, Box2D, TMX. Ces trois technologies sont très efficaces et répondent bien au besoin d'un jeu amateur. SFML est une excellente abstraction et, même si on aimerait qu'elle soit un peu plus complète, j'apprécie sa simplicité et sa documentation riche et utile. Box2D est également une excellente bibliothèque, assez simple à prendre en main. On arrive à faire ce qu'on veut, même si parfois on se demande si la manière dont on procède est bien la bonne manière de faire. TMX enfin, avec son éditeur Tiled, est un format qui me donne vraiment entière satisfaction. Sa généricité n'empêche pas qu'on puisse le spécialiser comme on le souhaite via son système de propriétés. En fait, le plus difficile dans ces trois choix est de les faire cohabiter intelligemment.
Finissons par le choix d'utiliser les systèmes à entités. Là, je dois dire qu'au bout d'un an, je reste perplexe. D'un côté, je vois bien que théoriquement, ce paradigme n'offre que des avantages (en particulier dans le style de jeu que je vise). D'un autre côté, dans la pratique, c'est assez complexe. Ce qui est dur, c'est de bien délimiter les systèmes en fonctionnalités et de choisir les bons composants. Qu'est-ce qui relève de l'état du jeu, qu'est-ce qui relève de données statiques ? La frontière est mince et mouvante. Ce qui serait simple, ce serait d'avoir déjà l'ensemble des systèmes et l'ensemble des composants. Construire les bons systèmes et les bons composants quand on part de zéro et qu'on n'a quasiment aucun modèle, c'est très compliqué. Je pense que j'aurais été beaucoup plus vite pour développer mon jeu avec un paradigme objet plus traditionnel. Mais je pense que je vais rester sur les systèmes à entités pour aller jusqu'au bout de l'expérimentation et contruire un jeu complet avec ce paradigme.
Perspectives
Quelles sont les perspectives ? Tout d'abord, il faut que j'arrive à finir le code (ou en tout cas une partie suffisamment importante du code) pour commencer le contenu du jeu. Je pense que je vais passer en mode sale pour le code qui reste à faire. Comprendre par là que je préfère avoir un code qui marche mais pas tout à fait nickel plutôt que d'essayer à tout prix d'avoir un code propre et bien pensé. En un mot : fonctionnalités plutôt que réutilisabilité. J'espère que dans un an, pour le deuxième anniversaire, on y sera.
L'autre point important, c'est d'avancer sur les sprites. Pour l'instant, Naha m'en a fait quelques uns qui sont plutôt réussis. Il va falloir continuer et sans doute accélérer un peu le rythme parce qu'il manque encore beaucoup de choses à ce niveau. J'aimerais pouvoir générer tout un tas de choses sur la carte primitive et qu'on puisse la modifier facilement sans devoir passer du temps à des tâches répétitives. Par exemple, pour définir une forêt, il est plus simple de tenter de la générer (éventuellement en guidant cette génération) plutôt que de placer les arbres un à un.
Ma première GameJam
J'ai participé à ma première game jam au début de l'été. C'était un moment fort enrichissant à plusieurs niveaux. Pour ceux qui ne savent pas ce qu'est une game jam, c'est une sorte de concours en temps limité où le but est de développer un jeu.
Cette game jam, baptisée Game Cancoillote, et organisée par deux de mes étudiants, s'est déroulé fin juin sur un week-end, dans les locaux de l'Université de Franche-Comté. Ils avaient bien fait les choses, on avait une grande salle pour toutes les équipes, et bien sûr à manger et à boire, ce qui a favorisé une excellente ambiance !
Il y avait cinq équipes qui ont utilisé des technologies très différentes. Une équipe a utilisé GameMaker, une autre Java, une autre HTML5/JS, une autre un moteur de jeu propriétaire, et la dernière, la mienne, a utilisé ce bon vieux couple C++/SFML. Même au niveau des concepts de jeu, il y a eu quelques surprises. Celui que j'ai préféré était l'équipe HTML5/JS qui a fait un jeu d'aventure en pointer-et-cliquer. Ils ont imaginé un scénario par rapport au thème de la game jam et ont utilisé l'université comme décor. Ils ont pris des photos panoramiques de divers endroits, ils ont aussi utilisé certaines vues de Google Maps (ouais, problème de copyright toussa). Et ensuite, ils ont incrusté un personnage en dessin. Et bien ça rend plutôt bien.
Pour ma part, j'étais dans une équipe composée de cinq personnes : trois étudiants (la major d'une spécialité de Master, le major et le second de licence 3) et deux profs (une collègue et moi-même). Sur le papier, une très bonne équipe. Deux des étudiants avaient déjà fait un jeu (dont un en projet semestriel avec moi), mais ma collègue était une novice complète. On avait déjà réfléchi à une idée globale de jeu avant la game jam tout en sachant que nous allions devoir nous adapter au thème (non-connu à l'avance) de la game jam. Notre idée était de partir sur le principe de pierre-feuille-ciseaux avec trois machins qui lutteraient les uns contre les autres.
Ce qui est bien, c'est que l'adaptation a été simple. Le thème de la game jam était une équation qui disait en gros qu'il fallait qu'il y ait de la physique dans le jeu et qu'il ne devait pas y avoir de gagnant dans le jeu. Nous avons alors imaginé qu'on pouvait avoir un jeu solo (donc pas de gagnant) où on contrôle une boule représentant une des trois entités et qu'on serait au milieu d'une sorte d'arène en train d'éviter ou de chasser les boules des autres entités qui arriveraient au hasard. Chaque rencontre donnerait lieu à une collision et une réaction : la disparition d'une boule en cas d'entités différentes. Et pour le fun, on a pris une variante japonaise : le guerrier, le tigre et la mère du guerrier. Voilà à quoi ça ressemble :
Au final, ce n'est pas si mal que ça pour le temps imparti. Nous n'avons pas eu trop de difficultés. Nous avons utilisé Box2D pour la physique (même si on aurait pu développer le moteur physique nous-même dans ce cas simple). Les avatars de chaque camp utilisent des photos prises dans la grande toile et j'aimerais bien les modifier pour pouvoir publier le jeu correctement sans avoir de problème de copyright. En revanche, l'illustration en bas à droite est l'œuvre d'une graphiste présente à la gam jam et qui a fait quelques dessins pour toutes les équipes (elle était très demandée).
Pour la beauté du geste, on a même fait un écran d'accueil avec cette même illustration.
Au niveau du nom, nous n'avons pas été très originaux. Une fois que tout sera d'aplomb niveau copyright, j'essaierai d'imaginer un nouveau nom (ou si vous avez des idées, n'hésitez pas à les partager en commentaire).
Un club de développement de jeu vidéo
La grosse nouveauté pour moi cette année, c'est que je lance dans mon université un club de développement de jeux vidéo. Je l'ai baptisé Dead Pixels Society. L'idée est de faire un jeu vidéo sur l'année universitaire avec une équipe d'une dizaine d'étudiants (pas forcément uniquement des informaticiens d'ailleurs) de tous niveaux.
Je ne sais pas ce que ça peut donner, mais j'ai des étudiants déjà très motivés par cette idée. Évidemment, j'espère aussi initier des étudiants complètement novices aux arcanes du développement d'un jeu vidéo. Pour cela, j'ai réalisé quelques fiches sur des aspects techniques basiques d'un jeu vidéo : la boucle de jeu, les systèmes de coordonnées 2D, les couleurs et la transparence, les sprites et animations, les moteurs physiques, etc. L'idée est de faire passer quelques concepts sans entrer dans les détails et sans s'attacher à une technologie en particulier. J'ai encore quelques idées de fiches mais je crois avoir brossé une bonne partie du sujet. Si vous avez des suggestions, n'hésitez pas à m'en faire part en commentaire.
J'aurai sans doute l'occasion de revenir sur les activités de ce club au cours des prochains épisodes ou dans des journaux. Si nous arrivons à enrichir le paysage des jeux libres d'un nouveau jeu par an, je me dis qu'on aura réussi quelque chose de bien. Cette activité parallèle à Akagoria va aussi sans doute me permettre d'avancer sur mon propre jeu. Outre le fait que j'ai maintenant un créneau fixe chaque semaine consacré au développement de jeux vidéo, il y a aussi les idées (et les bouts de code) qui peuvent émerger dans un autre jeu et dont je pourrai me resservir.
