Le MVP signifie Minimal Viable Product. C’est peut-être évident pour certains parce que c’est un principe bien connu dans le développement Web/Application, mais il n’est pas vraiment répandu dans l’industrie du jeu vidéo. En résumé, MVP se concentre sur la production de quelque chose, étape par étape, en répondant aux premières exigences définies par l’utilisateur, sans travailler tous les détails et les options, avant de passer à l’étape suivante.
Dans l’industrie du jeu vidéo, les projets deviennent de plus en plus complexes, avec de grandes équipes de plusieurs centaines de personnes parfois. La façon dont ils sont planifiés, organisés et divisés en tâches aboutit souvent à un système en forme de « cascade d’eau », où le jeu évolue à travers les étapes de conception, prototype, production, alpha, beta et release. Mais il est rare d’avoir un aperçu du produit final tant qu’il n’est pas fini, ce qui conduit à l’échec de certains projets et beaucoup de frustration pour l’équipe. Il nourrit la mentalité de l’attentisme, où même si les choses ne vont pas très bien, on espère toujours que tout ira bien quand on assemblera toutes les pièces à la fin.
Avant que le studio ne soit doté de personnel et que nous ayons des bureaux, j’ai commencé un premier MVP en me concentrant sur la présentation des piliers du jeu : création du personnage, disposition du donjon, mécanique d’exploration, présentation du personnage de base, combat, système magique, et interface graphique. Je n’ai pas abordé toutes les options et tous les détails, et je n’ai pas non plus fait de code « rapide et sale ». J’ai fait de mon mieux pour atteindre les objectifs que je m’étais fixé dans les 9 mois que je me suis donnés. Le résultat m’a permis de montrer ce projet à d’autres personnes, de montrer comment il fonctionnait, et à partir de là, d’embaucher une équipe et d’obtenir un financement initial. Une fois ce cycle de MVP terminé, nous voulions un nouveau cycle : ajouter du vernis visuel, de l’éclairage, de nouvelles textures, pour convaincre encore plus de gens, obtenir plus de financement et comprendre jusqu’où nous pourrions aller. Le cycle MVP suivant était la construction d’un premier prototype jouable qui est rapidement devenu les Ruines de Téléma, que vous connaissez maintenant sous le nom de démo de Kickstarter.
Travailler avec une approche MVP n’est pas simple : beaucoup de gens aiment avoir une vue d’ensemble et se soucient de couvrir toutes les bases dès le départ, ce qui peut compliquer et ralentir considérablement les cycles de production. Gardez à l’esprit qu’il est beaucoup plus facile d’utiliser l’approche MVP quand vous êtes une petite équipe, ce qui est aussi l’une des raisons pour lesquelles nous utilisons cette méthode. Il est également essentiel de comprendre que le MVP doit travailler en binôme avec le refactoring (Retourner dans les systèmes existants pour les améliorer). Quand j’ai développé le premier prototype, j’avais besoin d’une IA minimale rapide pour les monstres.. Comme il s’est avéré totalement inadéquat pour des situations complexes, notre programmeur IA l’a ensuite remplacé par un système plus avancé. Le refactoring prend un peu de temps, mais vous apprenez à savoir ce que vous devez changer et améliorer parce que vous pouvez tester l’ancien système en jeu. D’un autre côté, l’approche classique consisterait à concevoir une IA complète sur papier au début, puis à espérer qu’elle fonctionne aussi bien que vous l’avez imaginée une fois qu’elle est complètement implémentée dans le jeu. Et parfois vous réalisez que la moitié du travail que vous avez fait était inutile car un autre système a été retiré du jeu par manque de temps.
Par conséquent, notre nouvel objectif MVP (ce sur quoi nous travaillons en ce moment) est de construire les premières heures de jeu. Cela nécessite la création de nombreux nouveaux systèmes, contenus et niveaux par rapport à ce que nous avions pour le Kickstarter. Entre autres, nous devons avoir la création et la personnalisation de personnages, des classes et des archétypes, une introduction et un tutoriel, une carte du monde et navigation, les premières missions de campagne, et beaucoup de choses dont je ne peux pas parler en ce moment. Je sais que beaucoup d’entre vous sont peut-être très impatients de jouer à Solasta, mais nous voulons nous assurer d’atteindre un certain niveau de qualité avant de le mettre entre vos mains….
Avant que le studio ne soit doté de personnel et que nous ayons des bureaux, j’ai commencé un premier MVP en me concentrant sur la présentation des piliers du jeu : création du personnage, disposition du donjon, mécanique d’exploration, présentation du personnage de base, combat, système magique, et interface graphique. Je n’ai pas abordé toutes les options et tous les détails, et je n’ai pas non plus fait de code « rapide et sale ». J’ai fait de mon mieux pour atteindre les objectifs que je m’étais fixé dans les 9 mois que je me suis donnés. Le résultat m’a permis de montrer ce projet à d’autres personnes, de montrer comment il fonctionnait, et à partir de là, d’embaucher une équipe et d’obtenir un financement initial. Une fois ce cycle de MVP terminé, nous voulions un nouveau cycle : ajouter du vernis visuel, de l’éclairage, de nouvelles textures, pour convaincre encore plus de gens, obtenir plus de financement et comprendre jusqu’où nous pourrions aller. Le cycle MVP suivant était la construction d’un premier prototype jouable qui est rapidement devenu les Ruines de Téléma, que vous connaissez maintenant sous le nom de démo de Kickstarter.
Travailler avec une approche MVP n’est pas simple : beaucoup de gens aiment avoir une vue d’ensemble et se soucient de couvrir toutes les bases dès le départ, ce qui peut compliquer et ralentir considérablement les cycles de production. Gardez à l’esprit qu’il est beaucoup plus facile d’utiliser l’approche MVP quand vous êtes une petite équipe, ce qui est aussi l’une des raisons pour lesquelles nous utilisons cette méthode. Il est également essentiel de comprendre que le MVP doit travailler en binôme avec le refactoring (Retourner dans les systèmes existants pour les améliorer). Quand j’ai développé le premier prototype, j’avais besoin d’une IA minimale rapide pour les monstres.. Comme il s’est avéré totalement inadéquat pour des situations complexes, notre programmeur IA l’a ensuite remplacé par un système plus avancé. Le refactoring prend un peu de temps, mais vous apprenez à savoir ce que vous devez changer et améliorer parce que vous pouvez tester l’ancien système en jeu. D’un autre côté, l’approche classique consisterait à concevoir une IA complète sur papier au début, puis à espérer qu’elle fonctionne aussi bien que vous l’avez imaginée une fois qu’elle est complètement implémentée dans le jeu. Et parfois vous réalisez que la moitié du travail que vous avez fait était inutile car un autre système a été retiré du jeu par manque de temps.
Par conséquent, notre nouvel objectif MVP (ce sur quoi nous travaillons en ce moment) est de construire les premières heures de jeu. Cela nécessite la création de nombreux nouveaux systèmes, contenus et niveaux par rapport à ce que nous avions pour le Kickstarter. Entre autres, nous devons avoir la création et la personnalisation de personnages, des classes et des archétypes, une introduction et un tutoriel, une carte du monde et navigation, les premières missions de campagne, et beaucoup de choses dont je ne peux pas parler en ce moment. Je sais que beaucoup d’entre vous sont peut-être très impatients de jouer à Solasta, mais nous voulons nous assurer d’atteindre un certain niveau de qualité avant de le mettre entre vos mains….
Retrouvez toutes nos traductions sur Solasta dans ce dossier
🎮 Fiche du jeu : Solasta : Crown of the Magister
