Game design 4 : Concrètement

— Interface : UI, UX
— Les étapes de développement
— La pré-production : GDD
— Faire un bon GDD
— Playtest
— Savoir mettre une fin à son projet
— Workshop : création d'un GDD pour Mario Kart 64

↓ Télécharger la présentation associée

Interface : UI, UX

UI signifie «User Interface» tandis que UX signifie «User eXperience».

User eXperience

L'UX se base sur les neurosciences et la psychologie pour être sûr que l'expérience de jeu soit agréable et immersive. Le but de l'UX est de tout faire pour la cible donnée, que ce soit pour des novices ou des joueurs de niche extrêmement expérimentés.

L'UX est utile pour comprendre les feedbacks des utilisateurs. Les UX designers délivrent une analyse basée sur les connaissances du cerveau, leurs expériences passées, et les données recueillies lors des playtest. Les feedbacks que donnent les utilisateurs ne sont pas toujours exacts, dans le sens où ils incluent de la perception.

La connaissance de chaque individu joue sur notre perception. Un étudiant d'Epitech ne verra pas une voiture de la même manière qu'un ingénieur chez une compagnie automobile. De même que «42» n'évoque quelque chose qu'à un petit nombre de personnes. C'est pour cela que les UX designers font tout particulièrement attention à cette notion.

L'UX se fait tout au long du développement du jeu. Il faut qu'elle soit intégrée au sein du processus et ne pas être mise de côté. C'est là une des difficultés du développement de jeux : il faut tout faire en même temps.

L'affordance est le principe que la forme suit la fonction, la manière dont on le voit est la manière dont cela marche. Arriver à l'affordance est le but ultime, qui n'est souvent pas atteignable, mais doit rester l'objectif.

L'UX pourrait se résumer au seul fait de faire les bons compromis qui font du sens pour l'expérience que vous recherchez.

User Interface

Le rôle d'une bonne interface est de permettre au jeu d'être perçu correctement. Une bonne UI n'est pas possible sans une bonne UX. L'UI doit mettre en avant les éléments importants de manière simple. Si une interface vous affiche des éléments importants, mais pas les éléments dont vous avez besoin dans la situation actuelle, en découle une mauvaise expérience.

Est-ce que l'interface est embêtante ? Si oui, il y a sûrement moyen de faire mieux (raccourcis, bind de touche…). Est-ce qu'il y a une longue animation où il faut attendre ?

Est-ce qu'il y a des sous-menus dans des sous-menus ? Réduisez au maximum la complexité, dès que possible. Ce qui est évident pour vous ne l'est pas pour votre public.

Les étapes de développement

Le développement de jeu vidéo se fait de manière itérative. Nous allons ici voir des étapes très réduites parce qu'elles dépendent de beaucoup de paramètres, mais voici les grands axes.

Tout d'abord vient le concept. Est-ce une idée originale, une mécanique innovante, la suite d'une IP, un jeu dérivé d'une licence commerciale…? C'est la genèse de tout jeu. Cela peut venir d'un "et si on faisait ça, est-ce que ça serait cool ?" ou bien d'une réflexion à partir d'un thème.

Ensuite vient la partie un peu mystique et souvent négligée par les gens techniques : la pré-production. C'est le moment où le game design document (GDD) est créée pour la première fois. L'histoire est écrite, les personnages, des concepts arts sont créés… Tout ce qui touche au jeu est déterminé.

Ensuite, vient la partie itérative de la production. En effet, la production s'accumule sous forme de prototypes qui incluent une ou plusieurs fonctionnalités dans le but de les tester, puis de les ajuster, corriger, ou supprimer.

On se retrouve donc avec le schéma suivant : prototype => playtest => ajustements => recommencer.

Certains construisent à partir de ces prototypes, d'autres ont une version de production du jeu sur lequel ils greffent ce qui est gardé après playtest des prototypes. En fonction des ajustements, le GDD évolue.

Ensuite, nous arrivons à la phase de post-production : Q&A, portage, adaptation pour les bonnes manettes, etc.

Tout le monde ici a les capacités de trouver un concept de jeu, de le développer, et de s'occuper du bugfixing. Les deux parties qui sont le plus obscur sont donc la pré-production et le playtest. C'est ce que nous allons découvrir ensemble tout de suite.

La pré-production : GDD

La pré-production s'articule autour d'un document d'une importance capitale pour le développement du jeu : le fameux Game Design Document. Mais que contient-il ? Tout simplement tout. Tout ce qui a un rapport avec le jeu. Mais pour mieux comprendre, nous allons étudier la structure d'un type possible de GDD. En effet, il n'y a pas de document type pour le GDD : cela dépend de l'équipe et du type de jeu. Il n'y a pas d'affrontement entre plusieurs écoles comme pour la guerre des consoles, c'est au bon vouloir de chacun, tant que tout le monde s'y retrouve et peut travailler avec.

L'intérêt principal de ce document est de se poser le moins de questions possible lors de la production du jeu. "Est-ce que ça devrait plutôt être comme ci ou comme ça ?". Si le GDD ne répond pas à cette question, le document n'est pas bon. Cependant, il est amené à évoluer après essai des mécaniques, changement de budget, ou pour plein d'autres raisons. C'est donc un document vivant. Le GDD ne sera pas le même au début de la production qu'après la phase de prototype, il doit être prêt à pouvoir évoluer. Mais trêve de bavardages, regardons un exemple possible de GDD.

Une première partie assez générale, pour donner une idée précise du jeu et son originalité, comprenant :

— une description du jeu qui permet d'avoir une image rapide
— une vue d'ensemble plus détaillée
— des concepts art qui permettent de se représenter le jeu

Puis une deuxième partie comportant des informations de game design comprenant, notamment et possiblement :

— le high concept, une phrase très courte qui décrit le jeu
— backstory
— le ton de l'histoire, le type d'histoire, la narration envisagée…
— le ou les objectifs du jeu
— le gameplay, détaillé de A à Z
— les mécaniques de jeu
— les commandes
— le déroulement d'une partie, de l'écran titre aux crédits
— une description de l'intelligence artificielle voulue
— l'interface de jeu
— la difficulté
— la démographie souhaitée
— le temps de jeu
— la description de la partie multijoueur
— quelle est la séparation du jeu ? (niveaux, chapitres, etc.)
— les 3C, évidemment
— les personnages
— les descriptions des sons et de la musique
— la description du monde
— ...

Bref, TOUT. Et ce n'est absolument pas exhaustif. Ce document est vraiment l'épicentre et est indispensable pour un jeu réussi. Et plus le jeu est complexe, plus ce document est indispensable. En effet, il permet de tout mettre à plat, et d'être sûr de ses choix. Un de autres buts de ce document est d'inspirer, il doit donner envie de jouer et jeu et donc de lui donner vie. Le game designer a aussi un rôle inspirant.

Maintenant que nous avons une idée précise d'à quoi peut ressembler un GDD (des GDD sont donnés dans la bibliographie), nous allons regarder comment écrire un bon GDD.

Faire un bon GDD

Nous allons lister ce qui est indispensable pour créer un bon GDD :

— décrire l'âme du jeu. Un jeu vidéo n'est pas fait que de lignes de code, ce n'est pas un simple programme, c'est une expérience interactive. Il faut que le jeu ait une âme, pas juste une description froide. Il faut que les gens qui lisent votre document aient envie de s'impliquer, et que chaque membre ait envie d'embellir à sa façon dans le cadre de ses fonctions le produit final.

— écrire clairement, de manière lisible et aérée. C'est évident, mais il faut bien le rappeler…

— prioritiser les différents éléments. Qu'est-ce qui est essentiel ? Qu'est-ce qui pourrait être bien d'avoir mais peut être supprimé ? Vous n'aurez pas le temps de finir votre jeu, alors vous devrez sûrement supprimer des choses. Autant savoir ce qu'il est possible de supprimer dès la pré-production.

— détailler. Tout détailler. Pourquoi avez-vous choisi cela et pas cela ? Gardez une note de ce que vous avez décidé de supprimer pour être sûr de ne pas avoir la même idée plus tard ; ou peut-être parce qu'en vérité cette idée est utile dans un nouveau contexte après évolution de votre game design. Détaillez précisément ce qui se passe quand on tue un ennemi et ce qu'il en découle. Expliquez avec des chiffres, des schémas, des tableaux, des comparaisons… JUSTIFIEZ chacune de vos décisions, elles ne tombent pas du ciel ! Il ne faut jamais rester vague.

— même si vous faites une animation brouillonne, un dessin, un prototype : écrivez. Les deux sont complémentaires et ne doivent pas être négligés. Écrivez ce qui fait l'intérêt de ce que vous créez.

— fournissez des alternatives. Vous n'aurez pas le temps de finir votre jeu comme vous le souhaitez, il est donc intéressant de réfléchir à des alternatives pour les choses que vous n'auriez pas le temps d'implémenter parce que cela demande trop de ressources. Si vous fournissez différentes possibilités pour vos fonctionnalités, vous perdrez moins de temps à devoir tout replanifier, avec le risque de ne pas avoir le temps d'y réfléchir calmement.

— organisez le document pour autoriser le changement. Indiquez clairement quels sont les éléments essentiels de votre jeu qui ne peuvent sous aucun prétexte bouger. Si vous parlez deux fois de la même chose, référencez-le pour que les modifications soient effectives partout et n'entrent pas en contradiction. À chaque changement, vérifiez s'il est cohérent avec le reste du jeu et son core. Pour ce faire, il est recommandé d'avoir un seul mainteneur du document, mais faites bien attention à ce que tout le monde travaille sur la même version.

Faites un bon document : clickable, numéroté, daté. Personne ne doit pouvoir dire «je l'ai fait comme cela parce qu'il n'y avait pas d'indication sur comment le faire».

Playtest

Le playtest est le fait de faire tester son jeu. Mais attention, ce n'est pas du test au sens fonctionnel, ici ce qui va être testé est la réaction des joueurs. Ainsi, ce sont des tests qui sont effectués avec un petit groupe de joueurs, qui n'ont idéalement jamais vu votre jeu avant. De ce fait, ils n'auront aucune attente et vous pourrez voir de manière «pure» s'ils sont intéressés et s'ils apprécient votre jeu. Vous pouvez tester leur engagement, le rythme de votre jeu, et la faisabilité. C'est-à-dire que votre jeu est simple pour vous, étant donné que vous l'avez beaucoup testé, mais vous ne savez pas comment les joueurs se débrouilleront (mais beaucoup moins bien que vous, c'est certain). Grâce à ces playtests, vous pourrez raffiner votre tutoriel pour que votre jeu devienne utilisable. Vous pourrez écouter leurs conseils pour rendre votre jeu meilleur. Vous pourrez également tester les contrôles.

Attention toutefois, vous devez faire attention aux gens à qui vous faites playtest ! Vous ne pouvez pas faire tester un bullet hell à une grand-mère qui n'a jamais joué à des jeux vidéo ! Il faut que vous fassiez tester cela au public à qui vous comptez le vendre, il faut donc l'identifier au préalable.

Pour préparer ces playtests, vous devez désactiver tout ce qui bloque le jeu et qui ne permet pas la progression du joueur dans de bonnes conditions. Le but est d'obtenir des feedbacks utiles, si vous laissez quelque chose de cassé, ils ne le seront pas. Évidemment, mettez vos joueurs en bonne condition pour une expérience optimale.

Le déroulement d'un playtest est très simple. Vous demandez à un joueur de tester votre jeu pendant une période de temps donnée (généralement 15 minutes, mais cela varie en fonction du jeu) et vous le regardez. Vous prenez des notes vis-à-vis de ses réactions, et surtout, vous ne lui dites rien. De la même manière qu'un joueur sera seul lorsqu'il jouera à votre jeu, vous devez le laisser seul. Le jeu doit être assez bien designé pour être compréhensible par le joueur tout seul. S'il a vraiment des soucis, vous pouvez l'aider, mais si cela se répète, vous pouvez être sûr que vous avez fait une erreur (que ce soit une erreur de design ou que le fassiez tester à de mauvaises personnes). Vous devez tout simplement ne rien dire pendant les playtests et prendre des notes.

Vous devez rester extrêmement poli, remercier vos joueurs, rester humble et calme peu importe s'ils donnent des commentaires positifs ou négatifs. Après cela, vous pouvez poser des questions à vos joueurs. En général, un document de playtest est donné au joueur avec des questions pour permettre d'établir des statistiques.

Il est largement déconseillé de faire playtest à des gens que vous connaissez, car leur appréciation du jeu sera perturbée par l'aspect social.

Savoir mettre une fin à son projet

Une des parties les plus complexes lors de la création d'un jeu, c'est le moment où il faut s'arrêter. Mais plus que s'arrêter, il faut finir. Et il y a une nuance très importante entre ces deux notions, qui est la quantité de détails. Plutôt que de finir cette dernière feature gameplay, il faudrait plutôt s'atteler à rendre le jeu agréable en matière d'interface, à travers des détails.

Mais il faut le finir. Un piège récurrent est de dire que maintenant, avec l'expérience, on est capables de le faire en mieux. Mais c'est le cas pour n'importe quel projet ! Ne recommencez pas, finissez-le ! La recherche de la perfection n'est pas une excuse pour recommencer. Si le jeu ne suit pas, ratez. Mais ratez avec un produit fini. Vous ferez mieux sur votre prochain produit fini la prochaine fois.

Mais comment décider à quel moment il faut arrêter de développer le jeu ? Le meilleur moyen est d'utiliser des deadlines. Les deadlines les plus efficaces sont celles qui ne sont pas arbitraires. Choisissez un salon, et terminez votre jeu pour ce salon. Faites cela tout le long de votre développement, pour les différentes phases de jeu ! Utilisez ces salons pour avoir des feedbacks. Gagnant-gagnant !
…Mais que se passe-t-il quand la date approche et que l'on sait que l'on ne pourra jamais finir à temps ? Eh bien il faut réduire la taille de son jeu. Supprimez des mécaniques, des niveaux, concentrez-vous sur l'essentiel. Magnifiez l'essentiel. Faites surgir tout l'intérêt du cœur de votre jeu. Rajoutez ces détails qui font que votre jeu ressemble à un produit fini. Ne finissez pas cette mécanique, si vous ne l'aviez pas encore implémentée c'est qu'elle n'était pas assez essentielle. C'est comme cela que ça se produit pour l'ensemble de l'industrie du jeu vidéo.

Et n'oubliez pas, savoir terminer un jeu est une qualité avant tout. Il est bien plus simple d'avoir un prototype qu'un jeu fini, avec tout ce que cela implique.

Workshop : création d'un GDD pour Mario Kart 64

Vous avez créé un jeu de plateau et vous avez créé un niveau pour Mario Kart 64. Désormais, il est l'heure de créer un Game Design Document ! Vous allez vous inspirer des deux précédents workshops pour ce faire.
Détaillez les différentes mécaniques, leurs utilités et leurs implications. Le but n'est pas de produire un document extrêmement complet, mais une ébauche pour appréhender la discipline. Si vous avez une idée de jeu original, je vous invite à écrire la première ébauche de GDD à la place de Mario Kart !

Level design ←