Le problème des actifs fictifs : Comment l'art du programmeur tue les tests de jeu

« Le greybox d'abord, l'art ensuite » est un conseil courant pour le prototypage de jeux. Les guides et tutoriels vous disent souvent de construire d'abord les mécaniques de base, de vous assurer que le jeu est réellement amusant en utilisant des cubes et des capsules abstraits, et de ne vous soucier des visuels qu'une fois la boucle principale éprouvée.

Cette approche est logique. Passer du temps à peaufiner l'art pour un prototype de jeu qui pourrait même ne pas fonctionner semble être un gaspillage de ressources. Le greyboxing est depuis longtemps un moyen fiable de naviguer dans le développement précoce sans souffrir d'une dérive du périmètre.

Cependant, cette approche comporte des coûts cachés. Lorsque vous présentez aux joueurs des éléments graphiques rudimentaires, vous ne testez pas seulement les mécaniques de jeu dans le vide – vous testez la façon dont les joueurs interagissent avec des jeux laids et non finis.

La fidélité visuelle peut avoir un impact profond sur les retours des tests de jeu. La perception qu'a un joueur de la réactivité, du poids et du ressenti global du jeu est affectée par ce qu'il voit à l'écran. Rester trop longtemps dans un environnement visuellement vide risque d'entraîner des retours biaisés par l'aspect visuel, plutôt que de refléter les mécaniques de jeu.

Le conseil standard et ce qu'il néglige

La sagesse conventionnelle en matière de développement de jeux dit qu'il ne faut jamais investir de temps dans des ressources artistiques tant que vos mécaniques ne sont pas totalement figées. Souvent, cela signifie construire des niveaux avec des cubes gris, représenter les joueurs par une capsule et utiliser une interface textuelle simple pour les informations essentielles.

Ce conseil existe pour une bonne raison. Il vous évite de perdre du temps à texturer un personnage qui pourrait être supprimé la semaine prochaine. Il force les équipes à se concentrer sur la boucle de gameplay fondamentale. Passer un mois sur des modèles haute fidélité avant même que le personnage ne puisse sauter correctement est une erreur de débutant célèbre.

Mais ce consensus repose sur l'hypothèse que les êtres humains peuvent complètement séparer le retour visuel du retour mécanique. Il attend d'un testeur qu'il s'assoie, regarde un rectangle gris flottant et évalue avec précision le code physique qui le pilote sans être influencé par le manque de finition visuelle. Mais il est clair pour nous que la psychologie humaine ne fonctionne tout simplement pas ainsi.

Comment la fidélité visuelle modifie ce que les testeurs vous disent

La qualité visuelle ne sert pas seulement à rendre les jeux plus beaux pour les captures d'écran marketing. Elle peut modifier considérablement la façon dont les joueurs perçoivent les mécaniques que vous avez construites, ce qui peut également avoir un impact direct sur les retours de test que vous recevez.

La recherche

Considérez la célèbre démonstration de développeur « Juice It or Lose It » par Martin Jonasson et Petri Purho à la GDC Europe 2012. Ils ont démontré un jeu de casse-briques basique sans aucun style visuel, puis ils ont ajouté des secousses d'écran, des effets de particules et des animations d'interpolation sans changer une seule ligne du code physique sous-jacent. Le jeu résultant semblait sensiblement différent.

Des recherches plus larges sur le gamefeel soutiennent l'idée que même des ajustements comme les secousses d'écran peuvent améliorer le sentiment d'agence et l'exaltation d'un joueur.

À quoi cela ressemble en pratique

Imaginez deux versions du même prototype de jeu. La première version présente une capsule grise glissant sur un plan plat. La seconde version présente un modèle de personnage texturé se déplaçant dans une rue pavée, avec de simples particules de poussière soulevées sous ses pieds.

Si vous présentez ces deux versions à des joueurs, ils pourraient juger la version texturée plus réactive et amusante, même si le code de mouvement sous-jacent est identique. Les testeurs ne peuvent pas toujours distinguer la qualité visuelle de la qualité du jeu – donc si un prototype semble rigide et sans vie, vous pourriez également recevoir des retours indiquant que les commandes semblent rigides et sans vie.

L'ancien compromis et pourquoi il ne s'applique plus

La raison pour laquelle le « greybox d'abord » a été conseillé en premier lieu est que la création d'éléments graphiques corrects était autrefois une phase longue et chronophage du processus de développement de jeu. Les développeurs devaient choisir entre consacrer leur temps au travail sur les fonctionnalités de gameplay principales comme les mécaniques ou sur des éléments visuels comme la peinture de textures. De nombreuses équipes ne pouvaient tout simplement pas faire les deux pendant les premières étapes du prototypage de jeu. Comme l'écart entre l'art du programmeur et l'« art suffisant » était si vaste, les développeurs acceptaient les retours biaisés des tests de jeu comme un mal nécessaire.

Mais le paysage du développement de jeux est en train de changer. Les phases de développement qui prenaient autrefois beaucoup de temps peuvent désormais être terminées assez rapidement, et l'art de jeu généré par IA a changé la donne en matière de prototypage rapide. La production de textures, de sprites 2D et de matériaux complexes par IA peut faire passer votre conception de niveau en greybox d'une géométrie abstraite à un environnement reconnaissable et cohérent assez rapidement pour que certains développeurs découvrent qu'ils n'ont plus à choisir entre tester les mécaniques et fournir un contexte visuel.

Approches pratiques pour de meilleurs visuels de prototype

Il existe plusieurs options très pratiques et rapides qui peuvent vous aider à rendre votre prototype suffisamment beau pour être testé avec précision, puis à l'affiner avec votre équipe artistique pour le finaliser.

Textures et sprites générés par IA

L'utilisation d'art de jeu généré par IA peut vous aider à améliorer rapidement un prototype, et les outils de génération de ressources comme les générateurs d'IA de Unity peuvent s'intégrer directement dans votre pipeline de ressources. Si vous avez besoin d'une texture de mur en briques pour donner aux joueurs une idée de l'échelle, vous pouvez générer un arrière-plan en briques homogène pour fournir un contexte visuel immédiat sans perturber votre calendrier de codage.

Packs d'espace réservé de l'Asset Store

Si vous préférez des modèles 3D sélectionnés, les packs d'espace réservé de l'Asset Store peuvent être une excellente solution. L'intégration de ces ressources préfabriquées dans votre jeu vous permet de remplacer l'art confus du programmeur par des environnements cohérents et lisibles que les joueurs peuvent comprendre.

Le cadre du « minimum visuel »

Au lieu de viser l'art final, cette approche vise le « minimum visuel ». Elle pose une question simple : Quel est le montant minimum d'investissement artistique requis pour éviter que vos visuels ne faussent les retours de vos tests de jeu ?

Habituellement, la réponse se résume à trois choses : des silhouettes reconnaissables pour que les joueurs sachent ce que sont les objets ; une différenciation des couleurs pour séparer les ennemis de l'arrière-plan ; et une variation de base des matériaux pour que les joueurs puissent faire la différence entre un personnage marchant sur du Metal et marchant sur de l'herbe.

Quand le greyboxing reste le bon choix

Il est important de préciser que le greyboxing n'est pas intrinsèquement mauvais. Il existe des phases de développement spécifiques où la conception de niveaux en greybox peut encore être le bon choix.

Si vous testez des mécaniques pures de manière isolée, comme déterminer si le raw math derrière une trajectoire de double saut fonctionne correctement, vous n'avez pas besoin de textures. Si vous en êtes à la toute première semaine d'un concept qui a une forte probabilité d'être abandonné, investir dans n'importe quel art est prématuré. Enfin, si vous effectuez des tests de disposition de niveau purs où le blocage de la ligne de vue et la vérification des distances de géométrie physique sont les seuls objectifs, les blocs gris conviennent parfaitement.

Le problème n'est pas le greyboxing en soi. Mais tout conseil conventionnel visant à ignorer complètement les visuels lorsque vous commencez à recueillir des retours de playtest sur le ressenti global de votre jeu pourrait être le meilleur conseil lorsque vous recherchez des retours plus complets.

Aller au-delà de la greybox

Des données précises peuvent être d'une aide précieuse pour développer un excellent jeu. Mais lorsque vous testez un prototype rempli d'art de programmeur, les données que vous obtenez sont souvent obscurcies par l'incapacité du joueur à voir au-delà des abstractions visuelles. En améliorant l'art de votre prototype à l'aide d'outils modernes, de packs d'assets et d'un cadre visuel minimal, vous pouvez aider vos testeurs à évaluer la conception de votre jeu de manière plus globale. Arrêtez de laisser un mauvais art temporaire gâcher des mécaniques parfaitement bonnes, et commencez à tester vos jeux de la manière dont les joueurs les vivent réellement.

FAQ : Art de prototype et playtesting

Quel est le moyen le plus rapide d'améliorer l'art temporaire ?

Vous pouvez améliorer rapidement le style visuel de votre jeu en utilisant des textures et des sprites générés par IA, ou en intégrant des packs modulaires provenant de magasins d'assets. Générer des textures par IA pour une scène de base peut grandement améliorer la lisibilité sans ralentir de manière significative le développement mécanique.

Dois-je utiliser de l'art de programmeur ou acheter des packs dans des magasins d'assets ?

Cela dépend entièrement de votre objectif immédiat. L'art du programmeur convient pour tester les mathématiques et la logique raw en interne. Cependant, si vous présentez le jeu à des testeurs externes pour évaluer si le jeu « semble amusant », acheter des packs de l'Asset Store ou générer des textures de base peut vous donner des retours plus précis et exploitables.