Pixel Pals
Un jeu iOS cosy de compagnon virtuel — et le récit honnête de deux pivots pour trouver la core loop.
Un jeu iOS cosy de compagnon virtuel, né comme un idle game de collection d’esprits. Après quatorze sprints et deux pivots, j’ai rédigé un reset du concept et recommencé avec un MVP à un seul compagnon. Pas encore sorti — cette étude de cas porte sur les décisions produit.
- Rôle
- Product Owner, game designer & développeur iOS (solo)
- Équipe
- Solo, assisté par IA (agents Claude Code)
- Contexte
- Projet personnel, pas encore publié
- Outils
- Swift, SwiftUI, SpriteKit, XCTest, Génération d’images GPT
Version 1 : un jeu de collection cosy
Le premier concept : des yokai, des esprits japonais, rendent visite à votre maison traditionnelle. Vous gagnez des pièces pendant votre absence, invitez des esprits, rénovez la pièce et complétez une collection.
Développé en sprints : gains hors ligne plafonnés, raretés, un index de collection, friandises et faim, succès, une cérémonie de baptême et un journal de souvenirs.
Pivot 1 : de la collection au soin
La collection s’est vite essoufflée. J’ai rédigé un document de pivot vers un soin façon Tamagotchi — et repensé la monétisation dans la foulée : pas de gacha, pas de pay-to-win, une évolution toujours accessible gratuitement, parce que le public des cozy games rejette les mécaniques agressives.
Des coupes de scope en chemin
- Un système de 15 objets de décoration avec bonus de set a été remplacé par une rénovation de la pièce en cinq étapes — moins de contenu à produire, une progression plus lisible.
- La boutique premium a été réduite à deux articles.
Pivot 2 : le reset du concept
Après 14 sprints, je me suis arrêté pour écrire noir sur blanc une vérité inconfortable : beaucoup d’UI livrée, mais la core loop n’avait jamais été implémentée. Je suis revenu à ce qui faisait fonctionner le Tamagotchi original de 1996 et j’ai délibérément placé le jeu sur un spectre allant de l’enjeu au stress : un vieillissement qu’on ne peut pas arrêter, mais pas de mort punitive ; un nettoyage qui récompense, sans jamais punir ; pas de pile de corvées qui vous attend à votre retour.
Le redémarrage : un seul compagnon, un scope verrouillé
Le successeur, Pixel Pal, repart de zéro avec un MVP verrouillé : un chat, cinq stades de vie, cinq statistiques, une boucle de soin. Chaque nouvelle idée doit passer quatre questions :
- Est-ce qu’elle renforce la core loop ?
- Est-ce qu’elle demande de nouveaux graphismes ?
- Est-ce qu’elle demande un backend ?
- Un joueur qui joue cinq minutes remarquerait-il son absence ?
S’y ajoutent une roadmap par phases avec des critères de sortie (« un testeur interne peut jouer sept jours sans bug bloquant »), un tableau des risques (limites d’exécution en arrière-plan sur iOS, cohérence des sprites, validation App Store d’une mécanique de mort) et un modèle premium payant — parce que le free-to-play casse la nostalgie.
Ma façon de travailler
- Un changelog par sprint avec le nombre de tests de chaque sprint ; le game design document comme source unique de vérité — les tests vérifient ses chiffres.
- Une équipe d’agents IA spécialisés (game designer, développeur iOS, QA, monétisation) avec un agent product manager comme arbitre des conflits de scope.
Ce que j’ai appris
Le document le plus précieux du projet est celui où j’admets avoir construit la mauvaise chose. L’écrire plus tôt m’aurait fait gagner des semaines — et c’est l’habitude que j’emporte dans chaque produit : nommer d’abord la core loop, puis la défendre.