Conception de jeux mobiles: itération vs planification et dangers du MVP

À tous les concepteurs de jeux qui ne planifient pas, je voudrais dire:
«Arrêtez! Tu es dangereux. Vous épuisez les développeurs. Vous perdez un temps précieux et des ressources qui pourraient être facilement économisées en accordant suffisamment d'attention à la planification. La conception de fouet se transforme en retards dans le développement global. La hâte de saisir de nouvelles fonctionnalités à moitié cuites vous reviendra sous la forme de dépenses imprévues. Fonctionne bien! "

Comment se fait la planification de la qualité?

En règle générale, la conception de jeux mobiles est divisée en deux écoles de base des principes de développement:

1. Itération - définir les mécanismes de base, puis répéter jusqu'à ce que quelque chose de valable soit obtenu; ébauche du projet avant son développement ultérieur.
2. Planification - réfléchissez soigneusement à chaque fonctionnalité, à chaque fenêtre, à toutes les dépendances et interactions entre les fonctionnalités principales avant le début du développement.

En règle générale, les adeptes de l'école d'itération viennent du monde du PC, où les gens sont habitués à vendre les jeux les plus intéressants pour l'utilisateur dans la configuration de base pour un prix fixe unique. Ces jeux ont souvent un taux de rétention des joueurs élevé et une faible monétisation.
À mon avis, il y a trop de gens qui sont trop emportés par la méthode d'itération. Ces personnes ont élevé le MVP (produit minimum viable anglais) au statut de culte et ont fait de la méthode MVP une béquille universelle et une excuse bon marché afin de ne pas réfléchir très attentivement à toutes les fonctionnalités. Les partisans de l'approche MVP avancent souvent des arguments comme:

• «Nous pouvons simplement l'exécuter plus tard.»
• "Nous penserons à la monétisation plus tard, mais pour l'instant nous devons faire quelque chose d'intéressant."

Malheureusement, les développeurs non techniques ne comprennent pas que le code du jeu n'est pas en caoutchouc. Ce n’est pas à vous d’assembler des blocs en plastique LEGO. Le jeu n'est pas de la pâte à modeler, il ne peut pas être fortement redessiné sans conséquences importantes. C'est parce que le code (en particulier le code du jeu avec une bonne quantité de code dur) est relativement rigide.

À cet égard, j'ai un point de vue plutôt radical: je pense que de nombreux concepteurs de jeux qui utilisent la méthode d'itération dans les jeux mobiles gratuits sont tout simplement dangereux car des équipes de développement entières peuvent ruiner leur paresse.

Dans le nouveau mantra pour le développement de jeux mobiles, nous ne devrions pas parler de MVP en mettant l'accent sur le «minimum» pour développer un produit viable, mais quelque chose de plus.

La loi de Kim:

développer un produit minimalement durable avec la planification la plus durable

L'industrie du jeu mobile est trop difficile pour les personnes qui ne veulent pas investir temps et efforts dans la planification de leurs projets.
Très souvent, je vois les types d'événements suivants:

• Des idées semi-brutes et insuffisamment réfléchies sont données au développement.
• De nombreux développeurs, à la recherche de conceptions de jeux tendance et les plus rentables, insèrent des fonctionnalités dans des jeux existants qui semblent extrêmement ridicules.
• L'interaction des fonctionnalités et leur influence les unes sur les autres dans le jeu n'est pas bien pensée.

À tous les concepteurs de jeux qui entrent dans cette catégorie, je voudrais dire:

«Arrêtez! Tu es dangereux. Vous épuisez les développeurs. Vous perdez un temps précieux et des ressources qui pourraient être facilement économisées en accordant suffisamment d'attention à la planification. La conception de fouet se transforme en retards dans le développement global. La hâte de saisir de nouvelles fonctionnalités à moitié cuites vous reviendra sous la forme de dépenses imprévues. Fonctionne bien! "

Comment se fait la planification de la qualité?

En fait, tout se résume aux tâches de base suivantes:

1. UI. Assurez-vous que l'interface prend en charge votre fonctionnalité. Faites des dispositions des fenêtres principales à l'avance.
2. Flux d'utilisateurs. Avant de donner une nouvelle fonctionnalité au développement, assurez-vous que toutes les fenêtres et leurs combinaisons dans le flux utilisateur sont prises en compte et réfléchies. Quel genre de flux? Lire ici: UI mobile et conception de jeux: écrans vs Les flux
3. Cas limites. Pensez à tous les principaux cas limites. Ce que c'est? Les cas limites sont des situations de jeu qui dépassent le cours normal du jeu, mais elles doivent également être élaborées. Vérifiez que dans les cas limites, il n'y a pas d'embûches.
4. Impact sur le système.Réfléchissez à la façon dont une nouvelle fonctionnalité affectera l'équilibre et l'économie de votre jeu. Comment cela affectera les autres systèmes de votre jeu. Et dans différentes parties de l'interface? Assurez-vous qu'il n'y a aucune contradiction nulle part.
5. Impact sur le projet. Comment une nouvelle fonctionnalité affectera-t-elle le gameplay, les paramètres de conception et la monétisation? Si vous ajoutez immédiatement une nouvelle fonctionnalité PvE à un jeu PvP, cela peut conduire à une CATASTROPHE. Comment cela affectera-t-il la monétisation attendue et réelle? (Plus d'informations ici: Game Design basé sur la monétisation: contribution ARPDAU ) Pensez-y!

Mais il y a des moments où il vaut mieux utiliser une approche itérative plutôt que de planifier. Par exemple, dans des expériences avec de nouveaux types de gameplay, si c'est la tâche principale et le principal risque. En outre, le point n'est pas dans la planification TOP. Tenez compte des problèmes de conception ci-dessus autant que nécessaire pour chaque fonctionnalité spécifique, type de jeu, vos objectifs, etc. C'est votre cas particulier qui déterminera votre Planification Durable Maximale. Il n'y a pas de solution standard à tous les problèmes.

Selon la situation, une planification plus minutieuse nécessite généralement les types de jeux suivants:

• Plus complexe - complexe, multi-système, avec un grand nombre de relations; ici, vous devez comprendre comment une nouvelle fonctionnalité affectera tout le reste du jeu.
• Plus d'interface utilisateur - également plus complexe, mais en termes de grand nombre de fenêtres;
• Multisystem - plus votre jeu est difficile, plus il a de systèmes.



Pour conclure:

• J'espère que cette publication aide l'un de vous à augmenter les chances de succès de votre produit grâce à la planification.
• Vous devez savoir quand utiliser la planification de manière situationnelle et quand utiliser l'itération.
• Utilisez les techniques ci-dessus pour réduire les itérations de production; l'essentiel de la planification doit être effectué aux premières étapes du développement du jeu, lorsque le coût des modifications est encore relativement faible.

Source: https://habr.com/ru/post/fr383131/