Dans une présentation publiée par InfoQ, Joe Cassavaugh raconte son parcours, de son travail d’ingénieur logiciel à la création d’un projet individuel autour de la série de jeux de réflexion Clutter. Cassavaugh affirme que la série a dépassé 6 millions de dollars de ventes et lui a rapporté plus de 2 millions de dollars nets, et qu’il se préparait à lancer le dix-neuvième jeu de la franchise. Mais l’intérêt de cette expérience ne réside pas uniquement dans les chiffres : il se trouve aussi dans les méthodes qu’il a utilisées pour transformer un produit unique en activité durable pendant des années.
L’histoire a commencé après l’arrêt par iWin du développement d’un jeu sur lequel il travaillait. Sa future partenaire lui a proposé de créer lui-même le jeu ; il a donc développé un prototype pendant un week-end autour de l’idée d’associer des objets similaires. Il a obtenu les droits de propriété intellectuelle auprès d’iWin, avec un accord accordant à l’entreprise un droit de premier refus pour publier tout nouveau jeu pendant deux ans, puis a lancé le premier jeu Clutter en 2011.
Le premier jeu n’a pas atteint les attentes qu’il avait fixées : ses recettes se sont élevées à environ 50 000 dollars après 15 mois, au lieu des deux scénarios qu’il anticipait : moins de 10 000 dollars ou plus de 100 000 dollars. Malgré cela, il a utilisé le moteur et les outils existants pour développer le deuxième épisode en environ six mois. Le deuxième épisode a rapporté environ 50 000 dollars et a également contribué à augmenter les recettes cumulées du premier jeu. C’est à ce moment que Cassavaugh a commencé à considérer la série comme un actif cumulatif, plutôt que comme un ensemble de produits distincts.
Qu’est-ce qui a réellement changé ?
Cassavaugh a appelé cet effet « l’effet franchise ». Chaque nouvelle sortie attire des revenus initiaux, mais elle réactive également les ventes des jeux précédents. Il explique que les sorties n’obtiennent pas toujours les mêmes résultats, mais que le lancement d’un nouveau jeu maintient la série présente auprès de son public, ce qui l’a aidé à suivre le recul du marché des jeux PC téléchargeables.
L’expérience montre également les limites de la réponse aux préférences du public. Lorsque le quatrième épisode s’est éloigné du style de base de Clutter et a ajouté des mini-jeux, les joueurs n’ont pas accepté le changement comme il l’avait prévu. En revanche, d’autres épisodes ont obtenu de meilleurs résultats parce qu’ils proposaient des variations au sein de la mécanique connue, au lieu de la remplacer. Cassavaugh a également utilisé des histoires, des images et des citations pour donner une personnalité aux énigmes, puis a commencé à demander directement l’avis des joueurs.
Pourquoi cette actualité est-elle importante pour les développeurs ?
La principale leçon technique de la présentation est que la vitesse ne provenait pas de journées de travail plus longues, mais de la réduction du travail répétitif. Après avoir utilisé un framework interne qu’il avait développé chez iWin, Cassavaugh est progressivement passé à Unity, et estime que sa productivité a été multipliée par quatre à six par rapport à son environnement précédent. Il précise toutefois que Unity a également élargi l’étendue de ce qu’il pouvait faire ; toute augmentation de capacité ne s’est donc pas directement transformée en réduction de la durée de développement.
Il s’est ensuite appuyé sur une refactorisation continue. Il a créé une classe de base pour les mini-jeux, chargée d’éléments communs tels que la barre de menus, la navigation entre les jeux, le minuteur et les fenêtres. Il peut ainsi ajouter un nouveau jeu sans reconstruire ces fonctions à chaque fois. Il a également transféré davantage de travail vers les fichiers de contenu et les outils automatisés, plutôt que d’écrire du nouveau code pour chaque énigme.
Cassavaugh cite un exemple modeste mais révélateur : la modification de la manière de stocker les paramètres des énigmes, en utilisant plusieurs paires clé-valeur sur une même ligne, a réduit une tâche qui était auparavant répétée manuellement. Il a également automatisé la création de lots d’images à l’aide d’outils tels que Batch et PaintShop Pro, alors que leur préparation nécessitait auparavant environ trois jours de travail répétitif.
Concilier quantité et facilité de production
Chaque jeu comprend, selon sa description, environ 1 800 énigmes en apparence, mais le chiffre pratique est plus proche de 900 ou 1 000 énigmes, car de grandes parties reposent sur la recombinaison du contenu et la modification des ensembles d’images et des règles. La série propose environ 200 énigmes fondées sur des citations ou des paragraphes dans chaque épisode. Cette distinction entre le code et le contenu lui a permis d’augmenter la taille du jeu sans accroître dans les mêmes proportions la taille du système logiciel.
Il a également donné aux joueurs des options concernant la manière de jouer, comme désactiver le minuteur ou modifier la vitesse de rotation des éléments, tout en conservant les règles fondamentales de l’énigme. Il indique qu’environ la moitié de ses joueurs n’utilisent pas le minuteur, ce qui l’a conduit à concevoir une expérience adaptée aussi bien à ceux qui recherchent un défi qu’à ceux qui souhaitent jouer tranquillement.
La lecture éditoriale de certi.news
Ce qui a réellement changé dans le cas de Clutter, c’est le passage d’un jeu isolé à un petit système de production géré par la réutilisation, l’accumulation de contenu et la continuité de la relation avec le public. Il ne s’agit pas d’une recette garantie pour bâtir un projet individuel : les chiffres présentés par Cassavaugh correspondent à son expérience et à son marché, et son succès dépendait également de sa persévérance au fil des années ainsi que de l’existence d’un public revenant pour les nouvelles sorties.
La leçon la plus facilement transposable à d’autres développeurs consiste à déterminer ce qui doit rester fixe et ce qui peut changer : une règle de jeu claire, une structure technique commune et un contenu renouvelé. Les questions restant ouvertes concernent la possibilité de reproduire ce modèle sur d’autres marchés, ainsi que les risques liés à la dépendance du projet envers une seule personne et une seule franchise. Il convient donc de considérer cette présentation comme un cas pratique de gestion du périmètre et de la production, et non comme la preuve que le travail en solo est généralement supérieur aux équipes de développement.