1

Quel taille occupe chacun de nos ? Combien de ligne de pour chacun de nos minis-jeux? Comment se répartissent les langages informatiques entre ces lignes de ? Voyons un peu les de réalisation des projets (et non les statistiques de visites!).

Pourquoi ces stats?

Pour aucune raison! Si ce n’est de la curiosité. Les projets de jeux web ne sont pas des concours du dossier avec le plus de lignes de code, ou de celui utilisant le moins de Javascript possible. Je n’ai donc initialement construit ces statistiques que pour la curiosité… mais par la suite, je me suis posé plusieurs questions: les projets les plus lourds en ligne de code sont-ils les plus joués? Les plus visités? Les plus connus? Ou tout simplement, ceux que j’ai le plus aimé faire?

Créer ces stats

Sonar

D’abord, il a fallu créer ces statistiques. SonarQube permet de connaître le nombre de lignes de code d’un projet, le nombre d’instructions, la proportion de commentaires, etc, mais uniquement par projet et non par dossier! Or, tous les minis-jeux sont regroupés dans un seul dépôt Mercurial, lié à un seul projet Sonar. Pour créer les statistiques du nombre de lignes de code par langage et par mini-jeu, il aurait fallu faire un projet Sonar par mini-jeu! C’était trop…

Un programme existant

Après, j’ai cherché un soft qui permettrait de dresser ces statistiques facilement, graphiquement, par dossier et en excluant certains sous-dossiers ou patterns (car je voulais parfois inclure les dépendances des minis-jeux, et parfois les exclure). Mais je ‘ai rien trouvé de simple et rapide…

Faire soi-même

Du coup, j’ai fait comme pour les statistiques des visites: j’ai fait mon propre script de statistiques des projets. Il est assez simple à utiliser, même si les paramètres sont en dur, et il me permet de sauter certains dossiers des minis-jeux. On peut le consulter depuis le navigateur, puisqu’il est écrit en PHP, pour visualiser directement un graph (PNG) du résultat. Fait en 2H, cela me semble être un bon investissement.

Télécharger le script de stats

Ce script de stats est livré “tel quel”: à vous de l’adapter à votre cas si vous souhaitez ces mêmes stats. Je ne ferai pas de mise à jour dessus.

Les statistiques

Définitions

Contrairement à Sonar, mon outil est très benêt: il se base uniquement sur l’extension du fichier (donc, le HTML dans un *.php est compté comme du PHP) et compte uniquement les lignes non-vides (les lignes de commentaires sont donc incluses). Ces stats sont donc des approximations, ce qui sera suffisant.

Le nombre de lignes de code

Graph

Le nombre de ligne de code par langage et par projet

Analyse

Je suis assez fier de moi au final: la plupart des minis-jeux tiennent en moins de 1000 lignes, tout en étant des jeux web fonctionnels et jouables (bref, des jeux “finis”). Même VariiSpace, qui se rangerai plutôt dans les MMORPG (en ébauche hein!) réussit à limiter sa verbosité, et ne fait pas beaucoup plus de lignes que les minis-jeux les plus aboutis. Ces derniers ont d’ailleurs plus de lignes que les autres minis-jeux principalement à cause de la quantité de données qu’ils embarquent: Skye Birthday et Isometry sont constitués de plusieurs centaines de lignes de JS définissant les tableaux du point-and-click (pour le premier) ou les usines du jeu de gestion (pour le second). En revanche, le projet “Common”, qui regroupe les composants récurrents d’un projet à l’autre (ie: les scripts PHP de l’architecture PRAWD, les configurations, les scripts shell, etc) gagnerait à être allégé.

Les minis-jeux sont des projets amateurs très rentables, avec un bon retour sur investissement (vos heures de conception, réalisation et diffusion seront facilement rentables).

La taille des projets

Graph

La taille de chaque projet

Analyse

Sans surprise, Dracca est le projet le plus obèse, à cause des nombreuses ressources graphiques (et encore: toutes n’y sont pas!). Et, pour tous les projets en général, le plus lourd reste les ressources multimédia: images et audio occupent une large place de l’espace dédié à chacun de ces projets. Ainsi, le “Common” pèse moins que la plupart des minis-jeux, et “VariiSpace” est presque le projet le plus léger (alors que son nombre de lignes de code est important)! Cela permet de se faire une idée de la quantité de travail investie ou non dans l’élaboration du contenu réel de chaque jeu. Sommairement, plus le projet est léger, moins il a de contenu. Cela permet de voir les projets les plus aboutis comme Dracca ou les plus aseptisés comme VariiSpace.

Un projet léger avec beaucoup de lignes de code manque de background et de contenu. Un projet lourd avec peu de lignes est une bibliothèque d’images. Il faut idéalement équilibrer les deux pour avoir un projet suffisamment étoffé en feature (code) et en contenu/background (poids).

Conclusion

Finalement, les minis-jeux sont une bonne façon de faire des jeux web en indé: ils prennent peu de temps à faire, sont facilement à prendre en main par les joueurs, et permettent donc de faire des jeux viable sans y passer des semaines. Enfin, leur légèreté évite de devoir mettre en place une architecture lourde pour les mener à bien.

1