L’article original « Level 2: Game Design / Iteration and Rapid Prototyping » a été écrit par Ian Schreiber et fait partie d’un cours de game design en ligne, publié sur le blog Game Design Concepts.

L’article original et cette traduction sont publiés sous licence Creative Commons (Attribution).

N’hésitez pas à visiter le blog de Ian Schreiber et suivre son compte Twitter.

~ ~ ~ ~ ~ ~ ~

La dernière fois nous avons posé la question : qu’est-ce qu’un jeu ? Aujourd’hui, nous verrons une question liée : qu’est-ce exactement que le game design ? La dernière fois, nous avons fait un jeu simple. Cette fois, nous verrons en le processus de comment sont faits les jeux en général. Alors qu’il est possible de faire un jeu de plateau de course du type « atteindre l’arrivée » en 15 minutes, cela vous demandera un peu plus de temps si vous voulez faire le prochain Colons de Catane ou World of Warcraft.

Course Announcements

Some administrative things that have come up since Monday:

• First, I would like to apologize to those who are registered for the misbehavior of the wiki. It was sending out hourly announcements of updates… and there were a lot of updates! I have attempted to turn off these updates, so you should hopefully not receive any more “wiki-spam” but if you do, you can shut it off manually by going to your own settings and changing notifications to “Never.”
• As of 5am GMT this morning, the discussion forums are set up and operational. I look forward to seeing some really great discussion. There were quite a few spambots that tried to register, so I had to check every forum account against course registrations. If you got an email that your account was rejected, it just means I was unable to match it up to a course registration; please try again. If you have not yet created a forum account, you can make it easiest for me by using the same email on the forums that you used to register for this course… and if you’re unwilling to do that, at least put some kind of identifying information in there (like your name and location) so I can find you in the list. Thank you.
• Lastly, to those of you who sent in a registration email after the course started (that is, if your email was timestamped after Monday, noon GMT), I apologize for not being able to add you after the fact. Registration emails have taken a lot of my time prior to the start of the course, and if I accept late registrations I will not have the time to do other things for the course. Whether you are registered or not, this blog is free and open to the public (as is the Twitter feed), and I hope you do still follow along and get a lot out of the experience.

Game Design

Nous utiliserons le mot « design » de nombreuses fois dans ce cours, et malheureusement c’est un terme qui est utilisé à tord et à travers alors je clarifierai ce que que je veux dire ici. Comme il est écrit dans Challenges for Game Designers, le game design est la création des règles et du contenu d’un jeu. Cela n’implique pas la programmation, l’illustration, l’animation, ou le marketing, aucune des nombreuses tâches requises pour faire un jeu. Toutes ces tâches peuvent être appelées collectivement « développement de jeu » et le game design fait partie du développement.

Malheureusement, j’ai vu le terme « design » utilisé (en particulier dans certains cursus d’écoles) pour faire référence à tous les aspects du développement. Quand il est utilisé dans l’industrie du jeu vidéo (ou l’industrie du jeu plateau), « game design » a un sens spécifique, et c’est ce sens que nous utiliserons pour ce cours.

Types Multiples de Game Design

Comme mentionné dans Challenges for Game Designers, il y a beaucoup de tâches associées au game design : design de système, design de niveaux, design de contenu, design d’interface utilisateur, construction de monde, écriture d’histoire. Vous pourriez remplir plusieurs cours de 10 semaines avec chacun d’entre eux, alors ce cours d’été ne sera pas un traitement complet de toute l’étendue du game design. Nous verrons superficiellement l’interface utilisateur, l’écriture d’histoire et le contenu lorsque cela sera pertinent, mais la majorité des cours se focalise sur le design de système (aussi parfois appelé « design de systèmes » ou « design de systèmes cœurs »).

Le design de système concerne la définition des règles basiques du jeu. Quelles sont les pièces ? Que contrôlez-vous ? Quelles actions pouvez-vous réaliser à votre tour (si jamais il y a des « tours ») ? Que se passe-t-il quand vous faites chaque action, et comment cela affecte l’état du jeu ? En général, le design de système est la création de ces trois choses :

• Règles de mise en place. Comment le jeu débute ?
• Règles de progression de jeu. Une fois que le jeu a commencé, que peuvent faire les joueurs, et qu’est-ce qui se passe lorsqu’ils agissent ?
• Règles de résolution. Qu’est-ce qui provoque la fin du jeu ? Si le jeu a une issue (comme gagner ou perdre), comment est-elle déterminée ?

Si vous regardez de nouveau au jeu Trois pour Quinze de lundi dernier, vous noterez que ces simples règles contiennent ces éléments. La création de ces règles est le design de système, et c’est ce sur quoi ne passerons la plupart de notre temps cet été.

Qu’est-ce qu’un game designer ?

Comme vous l’avez noté, le game design est un domaine incroyablement vaste. Ceux d’entre nous qui sont designers professionnels ont parfois des difficultés à expliquer ce que nous faisons à nos familles et à nos amis. Une raison en partie de cela est que nous faisons beaucoup de choses. Voici quelques analogies que j’ai vu en essayant d’expliquer ce que c’est qu’être un game designer :

• Les game designers sont des artistes. Le terme « art » est aussi difficile à définir que le mot « jeu »… mais si les jeux peuvent être une forme d’art (comme nous l’avons vu dans la définition de Costikyan, au moins), alors les designers pourraient être des artistes.
• Les game designers sont des architectes. Les architectes ne construisent pas les structures physiques ; il créent des plans. Les game designers de jeu vidéo créent des « plans » qui sont aussi appelés « document de design ». Les game designers de jeux de plateau créent des « plans » aussi – sous la forme de prototypes – qui sont ensuite produits en masse par les éditeurs.
• Les game designers sont des hôtes de soirées. En tant que designers, nous invitons les joueurs dans notre espace et faisons de notre mieux pour leur faire passer un bon moment.
• Les game designers sont des chercheurs. Comme je l’évoquerai plus tard aujourd’hui, nous créons des jeux d’une façon qui est très proche de la méthode scientifique.
• Les game designers sont des dieux. Nous créons des mondes, et nous créons les règles physiques qui gouvernent ces mondes.
• Les game designers sont des juristes. Nous créons une série de règles que les autres doivent suivre.
• Les game designers sont des enseignants. Comme nous le verrons plus tard quand nous commencerons à lire Theory of Fun, le divertissement et l’apprentissage sont fortement liées, et les jeux sont (au moins parfois) fun parce qu’ils impliquent d’apprendre de nouvelles compétences.

Si le game design est toutes ces choses, où pourrait-il se loger dans un cursus universitaire ? Il pourrait être justifié dans une école de formateurs, ou d’art, ou d’architecture, ou de théologie, ou de gestion d’animation, ou de loi, ou d’ingénierie, ou de sciences appliquées, ou une demi-douzaine de choses.

Est-ce qu’un game designer est toute ces choses ? Aucune d’entre elles ? Cela reste ouvert à la discussion, mais je pense que le game design a des éléments des autres domaines, mais reste son propre domaine. Et vous pouvez voir à quel point le domaine est large ! Au fur et à mesure où le domaine du game design avance, nous pourrions voir le jour où les game designers seront tellement spécialisés que le « game design » sera semblable à un autre domaine des « sciences » – les étudiants devront choisir une spécialité (Chimie, Biologie, Physique, etc.) plutôt que « diplômé en Sciences ».

En parlant de Science…

Comment est conçu un jeu ? Il y a plusieurs méthodes.

Historiquement, la première méthodologie de design était connue sous le nom de méthode en cascade : d’abord vous concevez le jeu en entier sur papier, ensuite vous l’implémentez (en utilisant la programmation dans un jeu vidéo, ou en créant le plateau et les pièces pour un jeu non-numérique), ensuite vous le playtestez¹ pour vérifier que les règles fonctionnent correctement, ajoutez un peu de patine visuelle pour le rendre attrayant, et ensuite le publiez.

Cette méthode est nommée Cascade, car comme l’eau dans une cascade, vous ne pouvez vous déplacer que dans une direction. Si vous êtes occupé à fabriquer les illustrations finales pour le jeu et il apparaît qu’une des règles a besoin de changer, tant pis – la méthodologie n’inclut pas de moyen de revenir en arrière une fois que vous avez fini.

À un certain point, quelqu’un a remarqué que cela pourrait être une bonne idée d’avoir au moins l’option de revenir en arrière et corriger les choses dans les étapes antérieures, et a créé ce qui est parfois connu comme l’approche itérative. Comme avec la cascade, vous commencez à concevoir le jeu, puis l’implémentez, et ensuite faites en sorte qu’il fonctionne. Mais après cela vous ajoutez une étape supplémentaire d’évaluation du jeu. Jouez-y, décidez ce qui est bon et ce qui a besoin de changer. Et ensuite, prenez une décision : avez-vous terminé, ou devriez-vous revenir à l’étape de design et faire des modifications ? Si vous décidez que le jeu est assez bon, alors c’est comme ça. Mais si vous identifiez des changements, vous revenez alors à l’étape de design, trouvez des moyens de résoudre les problèmes identifiés, implémentez ces changements, et les évaluez de nouveau. Continuez à faire cela jusqu’à ce que le jeu soit prêt.

Si cela vous semble familier, c’est parce que c’est plus ou mois la Méthode Scientifique :

1. Faites une observation. (« Mon expérience dans le fait de jouer ou créer des jeux m’a montré que certains types de mécaniques sont fun »)
2. Faites une hypothèse. (« Je pense que cette série particulière de règles que je rédige fera un jeu fun. »)
3. Créez une expérience pour prouver ou non l’hypothèse. (« Organisons un playtest de ce jeu et voyons s’il est fun ou pas. »)
4. Réalisez l’expérience. (« Jouons ! »)
5. Interprétez les résultats de l’expérience, en formant une nouvelle série d’observations. Revenez à l’étape 1.

Avec les jeux non numériques (cartes et plateau), ce processus fonctionne bien, car il peut être réalisé rapidement. Avec les jeux vidéo, il subsiste un problème : l’implémentation (i.e. la programmation et le débogage) coûte cher et prend beaucoup de temps. Si cela prend 18 mois pour programmer le jeu la première fois et vous avez seulement deux ans, vous n’aurez pas beaucoup de temps pour tester et modifier le jeu.

En général, plus de fois vous itérez, meilleur sera votre jeu final.

Ainsi, n’importe quel processus de game design devrait impliquer l’itération (à savoir, passer à travers un cycle entier de conception, implémentation et évaluation) autant de fois que possible, et tout ce qui vous permet d’itérer plus rapidement mènera en général à un meilleur jeu à la fin. À cause de cela, les designers de jeu vidéo feront souvent d’abord un prototype papier, et ensuite impliqueront les programmeurs quand ils seront certains que les règles cœur sont fun. Nous appelons cela le prototypage rapide.

Itération et Risque

Les jeux ont plusieurs types de risques associés avec eux. Il y a le risque de conception, le risque que le jeu ne soit pas fun et les gens ne l’aiment pas. Il y a le risque d’implémentation, la possibilité que l’équipe de développement ne soit pas du tout capable de construire le jeu, même si les règles sont solides. Il y a le risque commercial, la chance que le jeu soit formidable et que personne ne l’achète malgré cela. Et ainsi de suite.

Le rôle de l’itération est de réduire le risque de conception. Plus vous itérez, plus vous pouvez être certain que les règles de votre jeu sont efficaces.

Tout cela se résume à un point important : plus le risque de conception de votre jeu est grand (à savoir, si vos règles ne sont pas playtestées et validées), plus vous avez besoin d’itérations. Une méthode itérative n’est pas aussi critique pour les jeux dont les mécaniques sont largement empruntées à un autre jeu ayant eu du succès ; les suites et extensions des jeux populaires sont des exemples de situations où une approche en Cascade pourrait parfaitement fonctionner.

Cela dit, la plupart des game designers ont pour aspiration de créer des jeux qui soient nouveaux, créatifs et innovants.

Pourquoi ce cours n’est pas numérique…

Certains d’entre vous préféreraient créer des jeux de plateau de toute façon, alors ne vous inquiétez pas de la façon dont les jeux vidéo sont fait. Mais pour ceux d’entre vous qui aimeraient bien faire des jeux vidéos, vous pourriez vous être demandé pourquoi nous passons autant de temps à faire des jeux de cartes et de plateau dans ce cours. Maintenant vous savez : c’est parce que l’itération est plus rapide et moins coûteuse avec des cartons. Souvenez de lundi : vous pouvez faire un jeu de plateau en 15 minutes. Programmer ce jeu prendre beaucoup plus de temps. Quand c’est possible, prototypez sur papier d’abord, parce qu’un prototype papier fait en 15 minutes et une heure de playtest peuvent vous sauver des mois de programmation.

Plus tard dans ce cours, nous discuterons en détail les méthodes de prototypage papier, pour les jeux de plateaux traditionnels et aussi pour différents types de jeux vidéos.

Il y a une autre raison pour laquelle nous nous concentrerons principalement sur les jeux non numériques cet été, en particulier les jeux de cartes et de plateau. C’est un cours de design de systèmes, à savoir, la création des règles du jeu. Dans les jeux de plateau, les règles sont exposées. Ils peuvent avoir quelques composants physiques, c’est sûr, mais l’expérience de jeu est presque entièrement déterminée par les règles et les interactions entre les joueurs. Si les règles ne sont pas engageantes, le jeu ne sera pas fun, alors travailler dans ce medium crée une connexion claire entre les règles et l’expérience du joueur.

Ce n’est pas vrai dans les jeux vidéo. De nombreux jeux vidéo ont une technologie impressionnante (comme des moteurs physique réalistes) ainsi que des graphismes et des sons, ce qui peuvent masquer le fait que le gameplay² soit éculé. Les jeux vidéo peuvent aussi demander plus de temps à être réalisés (à cause de la programmation et de la création des éléments sonores ou visuels), ce qui en fait un choix peu pratique pour un cours de dix semaines.

La connexion entre les règles et l’expérience du joueur est aussi rendue trouble dans les jeux de rôle sur table. Je réalise que beaucoup d’entre vous ont principalement exprimé un intérêt dans le design de jeux de rôle, alors cela pourrait vous paraître étrange. Cependant, gardez à l’esprit qu’un jeu de rôle est essentiellement un exercice de narration collaborative (avec un système de règles en place pour définir les limites de ce qui peut et ne peut pas arriver). En tant que tel, un système formidable peut être ruiné par des joueurs qui auraient des compétences pauvres en narration et en improvisation, et un faible système peut être sauvé par des joueurs compétents. Ainsi, nous resterons loin de ces genres, au moins aux premières étapes [du cours].

Faire un essai

Prenez le jeu que vous avez fait en 15 minutes la dernière fois, et jouez-y, si vous ne l’avez pas déjà fait. Lorsque vous y jouez, demandez-vous : est-ce plus fun ou moins fun que jouer à votre jeu favori ? Pourquoi ? Que pourriez-vous changer dans ce jeu pour le rendre meilleur ? Vous n’avez pas à jouer au jeu jusqu’à la fin, mais seulement aussi longtemps que nécessaire pour avoir un sentiment global de ce que cela fait d’y jouer.

Ensuite, après y avoir joué une fois, faites au moins un changement. Peut-être que vous changerez les règles de mouvement, ou ajouterez une nouvelle façon pour les joueurs d’interagir. Peut-être que vous changerez certaines des cases sur le plateau. Quoi que fassiez, pour quelques raisons que ce soit, faites un changement et jouez-y à nouveau. Notez les différences. Est-ce que la modification a rendu le jeu meilleur, ou pire ? Est-ce que cette unique modification vous fait penser à un changement supplémentaire que vous pourriez faire ? Si le jeu est pire, reviendriez-vous à la règle d’avant, ou la changeriez-vous à nouveau, de façon différente ?

Nous verrons le processus de playtest en détail plus tard dans ce cours. Pour l’instant, je veux juste que tout le monde dépasse cette peur : « que se passera-t-il si je joue à mon jeu et qu’il craint ? » Avec le jeu que vous avez conçu lundi, les chances sont très élevées que votre jeu craigne vraiment (sérieusement, vous attendiez-vous à créer le prochain Gears of War en 15 minutes?). Cela ne fait en aucune façon de vous un « mauvais designer » – mais cela devrait rendre clair que plus vous passez de temps sur un jeu, et plus d’itérations vous faites, meilleur il devient.

Leçons apprises

La chose la plus importante à retenir aujourd’hui est que plus vous itérez sur un jeu, meilleur il devient. Les grands designers ne conçoivent pas de grands jeux. En général ils conçoivent des jeux vraiment mauvais, et ensuite ils itèrent dessus jusqu’à ce que les jeux deviennent bons.

Cela a deux corollaires :

• Vous aurez besoin d’un prototype jouable de votre jeu aussi tôt que possible pendant le développement. Plus rapidement vous pouvez playtester vos idées, plus de temps vous avez pour faire des changements.
• À partir d’un même temps disponible, un jeu plus simple, plus court donnera une meilleure expérience qu’un jeu plus long et plus compliqué. Un jeu qui prend dix heures à jouer jusqu’à la fin vous donnera moins d’itérations qu’un jeu qui peut être joué en cinq minutes. Quand nous débuterons le Projet de Design plus tard dans ce cours, gardez cela à l’esprit.

Jeu à la maison

Avant lundi prochain, lisez les choses suivantes. J’y ferai référence dans le contenu de lundi quand nous parlerons des éléments formels des jeux :

• Challenges for Game Designers, Chapitre 2 (Atoms). Cela agira comme un pont entre lundi dernier quand nous avons parlé d’un vocabulaire critique, et lundi prochain quand nous commencerons à le diviser le concept de « jeu » en ses composants.
• Formal Abstract Design Tools, de Doug Church. Cet article construit sur l’article I Have No Words de Costikyan, en offrant des outils supplémentaires avec lesquels nous pouvons analyser et concevoir des jeux. Alors qu’il utilise de nombreux exemples de jeux vidéo, pensez à la façon dont les concepts clefs dans l’article peuvent aussi s’appliquer à d’autres types de jeux.

Article précédent : Niveau 1 – Vue d’ensemble / Qu’est-ce qu’un jeu ?

Article suivant : Niveau 3 – Eléments formels des jeux