Game Design/ Création de jeux 101

Introduction aux méthodes de Game Design et aux étapes de production

Par Baptiste “Stoon” Hébert

Version 1.0 / Juin 2018

 Disclaimer/Avant Propos
Ce document est une synthèse de sources provenant de documentations internes d’éditeurs, de
développeurs et de créateurs exerçant dans le milieu depuis plusieurs années. Basé sur les travaux
de Nicolas Roginski (ancien Responsable pédagogique à Isart, Game Designer et mentor hors pair)
et de mon expérience dans le milieu, j’ai rédigé ce document avec des exemples plus récents, des
annotations et des précisions afin de le rendre plus autonome, de l’enrichir et de lui donner une
forme plus digeste ( j’ai rajouté une dizaine de pages à la proposition originale). Ces propos n’en-
gagent que moi et ces satanés créatures avec la traversée des marais.

Il faut avant tout comprendre que la création de jeu est un travail nécessitant de l’organisation.
Tout le monde à de bonnes idées, c’est la concrétisation et la production des ces idées qui font la
différence. Il ne suffit pas de mettre un tas d’inspirations de gameplay dans un chapeau et de le se-
couer très fort pour faire un jeu. Le vrai combat d’une production de jeu vidéo (comme tout travail
créatif), c’est l’optimisation et la rationalisation. Avoir une grammaire commune à toute l’équipe
est un premier point et il n’y a pas de place au hasard. Tout doit être contrôlé, maitrisé et prévu
pour offrir aux Players et aux joueuses la meilleure expérience.

Le divertissement n’a rien à voir avec le temps de travail. Vous pouvez passez des années à écrire
la meilleure blague du monde et pourtant, voir un quidam glisser sur une peau de banane fera
rire plus de gens que votre trait d’humour travaillé de longue date. Le Game Design, c’est l’art de
produire le plus de divertissement avec le minimum de moyen, c’est pourquoi un bon designer est
un designer fainéant, une personne capable d’optimiser au maximum son travail, car le plus petit
dénominateur commun reste le temps, donc pour corolaire l’argent, le véritable nerf de la guerre.

L’anglais étant la langue la plus utilisée dans l’industrie, j’ai traduis les éléments de langage pré-
cis, mais il est impératif d’en connaitre l’original, afin de partager un vocabulaire commun entre
tous les acteurs et de ne pas rester dans « l’à peu près », qui règne parfois trop dans le discours de
certains observateurs et certaines observatrices. Dans le même ton, chaque studio ou structure de
création à ses propres codes, sa propre hiérarchie et ses propres méthodes. Vous pourrez trouver
d’autres manières ou nomenclatures, mais la philosophie reste la même, celle de créer un produit
maitrisé de bout en bout avec une forte valeur ajoutée en divertissement.

Pour aller plus loin en une seule lecture :

Les travaux théoriques d’Ernest Adams à retrouver sur cette page.
(Fundamentals of Game Design par Ernest Adams)

Merci de me signaler toute erreur/précision

sur Twitter : @Major_Stoon
ou par mail : major_stoon@outlook.fr
 Qu’est-ce qu’un jeu vidéo ?
Il faut bien un point de départ, et la question est légitime. Tout le monde peut y aller de sa petite
définition ou référence, et s’il est aisé de trouver des dizaines de définitions dans des cas particu-
liers, la volonté d’unité doit primer sur le message final.

Les définitions suivantes de Sid Meiers (Civilization) et Ernest Adams (Game Designer, consultant et
auteur éminent du milieu) synthétisent le propos de manière assez simple :

“A series of interesting choices”

« Une suite de choix intéressants »
Sid Meiers

“A casually linked series of choices in a virtual environment”

« Une suite triviale de choix dans un environnement virtuel »
Ernest Adams

En fusionnant les deux, on obtient la définition parfaite, incluant une notion de virtuel pour le
séparer du jeu traditionnel :

“A casually linked series of interesting choices in a virtual environment”

« Une suite triviale de choix intéressants dans un environnement virtuel »

 Qu’est-ce que le gameplay ?
Mot fourre tout, le Gameplay n’a pas vraiment de traduction littérale en français. On pourrait le
résumer par « ensemble des mécaniques de jeu » ou plus simplement par l’équation suivante :

Gameplay = challenge + divertissement

Le Challenge
Le challenge est l’élément principal du jeu vidéo. Le challenge, c’est la confrontation d’un obstacle
et d’une ou plusieurs capacités. Sans challenge, il ne reste qu’une expérience interactive.

Le jeu - dans toutes ses formes – implique forcément de se confronter à un défi, un challenge,
qu’il soit contre un système de règles ou contre la performance d’un adversaire bien réel. Essayez
d’imaginer une épreuve sportive, un concours ou même un pari avec vos proches sans challenge.
Il ne reste alors qu’une histoire qui, aussi bien écrite soit elle, laisse de côté le dépassement de ses
propres capacités pour le Player (« joueuse » et « joueur »).

Le challenge est un des trois piliers de la boucle de gameplay, élément central et indispensable du
jeu.
 La boucle de Gameplay
La boucle de gameplay est l’émulation de trois composantes distinctes du jeu :

Objective => Challenge =>Reward

Objectif => Challenge => Récompense

Cette boucle (aussi appelée OCR) intervient à tous les niveaux d’un jeu et a le rôle de moteur pour
le Player. Elle est décomposée comme suit :

Objective (objectif) :

• Long terme (ex : sauver la princesse dans Zelda, sauver le monde dans Half-Life)
• Moyen terme (ex : atteindre la fin d’un niveau, terminer un donjon, obtenir un objet de quête)
• Court terme (ex : atteindre une plate-forme, battre un monstre, obtenir un bonus/une pièce,
résoudre une énigme, trouver la bonne personne à qui parler)

Challenge :

Il s’agit simplement de la confrontation des obstacles et des capacités.

Il faut toujours mettre en opposition un obstacle avec la capacité qui permet de le franchir.

Reward (Récompense) :

La Reward est la réelle motivation pour le Player. Elle est une gratification de Gameplay (bonus,
nouvelle capacité, accès à une nouvelle zone etc.) ou esthétique.
La Reward doit nourrir de nouvelles boucles de Gameplay en modifiant ou renouvelant le chal-
lenge (ex : grappin dans Zelda ou Gravity Gun dans Half-Life).

La reward doit être équivalente à la difficulté/durée du challenge : si elle trop gratifiante, le Play-
er aura l’impression que le jeu est trop facile ; si elle est trop pauvre, le Player aura l’impression
que les règles ne sont pas justes. Il faut de même toujours récompenser un Skill (capacité) ou une
manière alternative de jouer. Dans le doute sur l’équilibre d’un challenge, toujours choisir la situa-
tion de Gameplay la plus facile.

Il est impératif de laisser le Player essayer et tester une nouvelle arme ou capacité avant de le
mettre devant une situation réelle ou dangereuse. Que l’arme/capacité soit primordiale pour
avancer ou accessoire, il faut introduire une zone ou situation Sandbox (« bac à sable ») afin qu’il
ou elle puisse s’entrainer avec, puis décide suivant son style de jeu si c’est utile ou non.
 La boucle de Gameplay (suite)

Enfin, les achievements/trophées/succès doivent permettre au Game Designer d’inciter le Player

à jouer d’une manière particulière. Un très bon exemple est l’achievement « Fried Piper » sur Left
4 Dead 2, demandant de brûler un zombie clown menant au moins 10 infectés grâce au cocktail
molotov. En plus du challenge à réaliser, cela donne l’information au Player que les zombies clowns
attirent les infectés communs à cause du son.

Attention à ne pas tomber dans la checklist ennuyeuse (ex : faire X centaines de frags avec telle
arme), dans les défis irréalisables en multijoueur car la réussite dépend du groupe (ex : gagner X
parties dans tel mode de jeu) ou contraires à la philosophie du jeu (ex : achievement « Insurgent »
sur CS:GO, demandant de tuer un ennemi qui domine le Player, ne marche pas si le Player joue bien
et n’est pas dominé).
 Les Genres de jeu

On pourrait croire qu’il en existe des centaines, et les pirouettes marketing pour se démarquer de
la concurrence n’aident pas à simplifier les choses auprès du grand public. Il est parfois normal
pour un ou une journaliste de créer des néologismes afin de simplifier un texte et de se faire com-
prendre par son audience. Malgré tout, du point de vue du créateur ou de la créatrice, il n’y en a
qu’une poignée répartie comme suit :

Action

• Shooters (notion de violence)

-FPS : First Person Shooter ou Jeu de Tir à la Première Personne, aussi nommé First Per-
son Camera
ex : Call of Duty/Quake/Doom/GoldenEye etc.

-TPS : Third Person Shooter ou Jeu de Tir à la Troisième Personne

ex: Max Payne/Gears of War/Ghost Recon etc.

-Fighting Games : Jeu de Combat, emphase sur un ou plusieurs arts martiaux

-Beat them up (1v1)
ex : Street Figher/King of Fighter/Tekken/Soul Calibur
-Beat them all (1v100)
ex : Streets of Rage/Final Fight/Golden Axe

-Hack and Slash (« Tailler et trancher ») : Dérivé du RPG mettant l’emphase sur l’action
et les combats à outrance. Concept de Porte/Monstre/Trésor en pilier principal
ex : Gauntlet/Diablo/Path of Exile/Sacred
• Non-Shooters
-Platformer : jeu de plate-forme, notion de timing dans les capacités requises
ex : Super Mario/Crash Bandicoot/Wario etc.

Beat them all/Beat them up

Si le terme « Beat them all » est apparu à la suite d’un faux anglicisme dans la presse
française et largement repris par la communauté de Players, la véritable nomenclature an-
glaise est bien « Beat Them Up » ou « Beat’em up » par contraction (« frappez-les » ou
« cognez-les » en français).

Le distinguo « up » et « all » permet ici de faire la différence entre un jeu où il est ques-
tion d’affronter un seul ennemi par tableau ou au contraire des vagues successives. Si cette
nomenclature hérisse les poils de vieux ou vieilles ermites qui se battent sur les réseaux
sociaux pour savoir qui a raison entre « le » ou « la » Game Boy, il est ici question de se faire
comprendre par un éditeur, son équipe de développement et par conséquent de gagner du
temps/argent sur une production.

Comprenez que cette nomenclature n’est pas mienne et que son pouvoir indicatif est plus
important. Et puis comme dirait l’autre « Appelez-le Susanne si ça vous fait plaisir ».
 Les Genres de jeu (suite)

Adventure (jeux d’aventure)

• Une forte trame narrative

• Des énigmes/de l’exploration (visite de plusieurs lieux exotiques)
• Peut prendre plusieurs formes suivant la caméra adoptée

ex : Monkey Island/Les Chevaliers de Baphomet/Sherlock Holmes

Management (gestion)

• Récolte, gestion et optimisation des ressources

• Pas de hasard dans le gameplay
• La contemplation est un élément de plaisir du Player

ex : Sim City/Theme Park etc.

RPG (jeu de rôle)

• Evolution du personnage et de ses capacités, le plus souvent via un arbre de talent et des
points d’expérience (XP) mais aussi par le butin (loot)
• Une forte trame narrative
• Gestion d’un inventaire, implique une notion de stratégie en préparant à l’avance un chal-
lenge (ex : choisir de porter plus de munitions au détriment des packs de soin)

• Combats
-Tour par tour
ex : vieux Final Fantasy/Fallout 1 & 2/Pokémon bleu/rouge
-Temps réel
ex : Tales of/Final Fantasy 12/Skyrim
Sport :

• Réalistes / Existants : pas besoin d’apprendre un système de jeu

ex : FIFA/Madden/NHL/NBA2K

• Fantaisistes : l’accent est mis sur l’action, le fun, le divertissement. Le résultat doit être spec-
taculaire et les temps de jeu courts
ex : Mario Kart/Mario Tennis/Wii Sports/Yeti Sports
 Les Genres de jeu (suite)
MMO (Massivement Multijoueur en Ligne)

• La plupart des NPC (Non Playable Characters ou Personnages Non Joueur : PNJ) sont inter-
prétés par des Players réels
• Système de chances égales : le Game Balance (équilibre des mécaniques) entre les classes est
primordial
• Différentes récompenses : soit le temps de jeu, soit les aptitudes. Le modèle Free-to-Play (F2P,
jeu à accès gratuit) met l’emphase sur le premier modèle, afin de conserver les Players un
maximum de temps et de multiplier les « murs » où il sera incité à payer pour plus de confort
(inventaire plus grand, personnalisation visuelle ++, plus de slots (« emplacements ») d’ava-
tars disponibles, etc.)
ex : World of Warcraft/Dark Age of Camelot/Guild Wars 2/Star Wars Galaxies/Black
Desert Online

Strategy

• RTS (Real Time Strategy) ou « Stratégie en Temps Réel » (STR) : fait appel à la notion de tac-
tique (adaptation en temps réel à une situation donnée)
ex : Age of Empires/Starcraft/Warcraft

• Turn Based (Tour par Tour) : fait appel à la notion de stratégie (actions mises en pratique à la
fin du tour, préparation de l’action avant déclenchement)
ex : Civilization/Age of Wonders/Endless Space

Puzzle Game

• Solution Unique, pas de résolution par l’action

ex : Quizz/Taquin/7 différences etc. (la catégorie « Casual » sur Steam en regorge)

La plupart des jeux aujourd’hui mélangent ces différentes catégories afin d’enrichir et d’appro-
fondir l’expérience des joueuses et des Players. Il convient de prendre le plus grand dénomina-
teur commun (entendre le genre le plus présent dans le Game Design du titre) pour en définir sa
catégorie.

Ex: Total War mélange stratégie au tour par tour pour la gestion macro de la nation et stratégie
en temps réel pour les batailles (champs de bataille sur une carte à l’échelle avec des centaines
d’unités). Contre l’ordinateur, le Player a le choix de mettre en pause les batailles en temps réel afin
de mieux coordonner les ordres. De plus, le temps de jeu global est d’avantage sur la carte au tour
par tour. On considère alors le jeu comme de la catégorie de la Stratégie au tour par tour pour plus
de clarté.

Autre ex : le premier Tomb Raider mélange les genres Action (gunfights en temps réel), Aventure
(exploration, énigmes, forte trame narrative), Plate-forme et même RPG (gestion d’inventaire). Les
genres dominants en temps de jeu restent l’Action et l’Aventure, on le définira comme un jeu d’Ac-
tion-Aventure.
 Les Genres de jeu (suite et fin)

Une autre manière de catégoriser les jeux existe et sera plutôt utilisée en interne du côté de l’équi-
pe de développement et de l’éditeur. Elle consiste à définir quel pôle aura un poids plus important
dans la création, et par conséquent quelle orientation aura le produit.

On les catégorisera de la sorte :

• Story Driven Game (Jeu ayant comme ligne directrice son histoire) : ici, l’histoire, l’univers ou
l’ambiance du jeu ont la priorité sur le reste en terme de développement. Le titre n’est pas un
défi technologique et ne repose pas sur des mécaniques de jeu complexes (le plus souvent
des systèmes déjà utilisés par d’autres réussites commerciales par le passé), mais va tenter de
séduire son audience par une direction artistique, un scénario, des personnages, des dialogues
etc. La prise de risque s’effectue principalement sur la direction artistique, qui sera le moteur
pour le reste des fonctionnalités du jeu.
Ex : Monkey Island : les quelques systèmes ne sont là que pour servir le déroulement de l’his-
toire, le but est d’amener le Player jusqu’au rideau final, quitte à tomber dans le ridicule/ab-
surde (un singe sur une bouche d’incendie pour stopper le flux d’un torrent)
Autres ex : The Walkind Dead, Heavy Rain etc.

• Technical Driven Game (Jeu ayant comme ligne directrice sa technologie/son moteur) : le but
principal de ce type de jeu est avant tout de mettre en avant un savoir faire technique. Que ce
soit pour vendre un moteur ou un nouveau système de jeu (matériel), le but est d’en mettre
plein la vue. Comme pour un Story Driven Game, il emprunte ses mécaniques à des cadors du
genre et calque sa direction artistique/histoire le plus souvent sur des blockbusters du cinéma
pour parler au public le plus large.
Ex : Unreal Tournament, Rise : Son of Rome, Crysis, Quantum Break, etc.

• Game Design Driven Game (Jeu ayant comme ligne directrice son Game Design) : ici le point
central est le Game Design et le but est d’encourager le public à continuer l’aventure par des
mécaniques poussées, profondes et qui récompensent l’investissement de temps et de com-
préhension. Ni époustouflant techniquement ou artistiquement, l’ensemble des éléments dével-
oppés est fait dans l’optique de servir le game design avant tout (ex : couleur de vêtements
d’une faction pour mieux identifier alliés et ennemis, interface ergonomique avant d’être artis-
tiquement racée pour une meilleure compréhension/manipulation)
Ex : Minecraft, Counter-Strike, Tetris

Comme pour les catégories précédentes, la plupart des titres mélangent dans une certaine
mesure les trois qualificatifs, le but final étant de produire un jeu parfait sur les trois tableaux. Un
titre comme Dishonored : Death of the Outsider pousse les trois potards à un niveau de qualité
exceptionnelle, mais garde dans son ADN une emphase mise sur le gameplay : la technique et la
direction artistique sont là pour servir le Game Design, on peut ainsi le classer comme un Game
Design Driven Game.
 Les Skills (Capacités) demandés aux Players

Afin de rationnaliser et d’anticiper le comportement d’une audience, il convient de cerner ce qui

lui sera demandé au cours des challenges d’un jeu. Le plus petit dénominateur commun est l’in-
put (pas vraiment de traduction littérale, « méthode de saisie » étant un bon client), clef de toute
interaction humain-machine.

Un input peut prendre différentes formes : la pression d’un bouton ou d’une touche (ou combinai-
son), la saisie d’une ligne de texte, un mouvement de stick ou de souris ou toute autre chose sur
des contrôleurs plus exotiques.

La logique ergonomique veut que plus l’action est répétée dans le jeu, plus l’input sera simple à
accéder (ex : un saut sur un jeu de plateforme est souvent sur le bouton le plus proche du pouce,
car c’est l’action la plus répétée au cours du titre). Cela dicte le mapping (« association action-tou-
che ») des touches par hiérarchie, peut demander au Game Designer de trouver des méthodes
doublons pour s’adapter à tout le monde etc. Le but n’est pas d’aller plus loin sur ce domaine, car il
tourne vite en poupée russe donc on en restera là pour les inputs.

A partir de ces inputs, on peut donc dégager une liste de huit skills demandées aux Players. Cette
liste est issue du travail de chercheuses et chercheurs du Games Lab d’Ubisoft et ne souffre d’au-
cun manque ou défaut. En gros, si vous trouvez un skill en plus, vous gagnez le prix Nobel.

• Reflex (Réflexe) :
Capacité de réaction limitée dans le temps, et sanctionnée en cas de mauvais input.
Elle prend aujourd’hui majoritairement la forme d’un QTE (Quick Time Event, « Action Rapide
sous la Pression du Temps »).

• Timing (entendre « Synchronisation » en français) :

Capacité d’effectuer des inputs en succession selon un rythme.
Ex : les notes sur Guitar Hero, Rock Band, etc. ; combos sur Street Fighter, Devil May Cry, etc. ;
sauts successifs sur Super Mario, Crash Bandicoot, etc.

• Strategy (Stratégie) :
Capacité de planification et préparation avant l’action. A bien différencier et opposer avec la
Tactique.
Ex : préparer son arsenal avant une phase d’action, quel plan de bataille adopter (contour-
nement, attaquer le centre, etc.), organisation d’un inventaire en fonction du style de jeu ou du
défi à venir.
 Les Skills (Capacités) demandés aux Players (suite)

• Tactic (Tactique) :
Capacité de prise de décision en temps réel, et donc l’adaptation à une situation donnée. A
bien différencier et opposer à la Stratégie.
Une autre manière de différencier plus facilement Tactique et Stratégie consiste à prendre en
considération le délai d’application des décisions. On peut résumer TRES grossièrement la
stratégie comme étant les décisions à moyen/long terme et la tactique à très court terme.
Ex : un ennemi apparait à l’écran avec une armure plus puissante, que choisir entre du dégât
brut plus élevé (impliquant un positionnement différent face à lui) ou la rapidité d’exécution
des coups avec plus de mobilité (mais une exposition plus longue à ses attaques).
Autre Ex : l’ennemi envoie une grenade sur Call of Duty, choix de la renvoyer pour qu’il prenne
les dégâts (avec le risque qu’elle explose dans les mains de l’avatar si le détonateur est bien
avancé) ou s’en éloigner pour jouer la sécurité (mais possibilité de prendre un peu de dégâts et
laisser à l’adversaire du terrain plus avantageux)

• Management (« Gestion ») :
Capacité de récolte, gestion et optimisation d’un ou plusieurs ressources données.
Ex : l’argent dans Sim City, le gaz et le minerais dans Starcraft etc.

• Precision (« Précision ») :
Capacité à atteindre un espace réduit sur l’écran. La précision verticale est plus dure à attein-
dre que la précision horizontale (rapport à la motricité du bras/poignet/pouce et du balayage
des yeux). Le skill le plus dur à développer chez un Player.
Ex : headshot (« tir à la tête ») sur un jeu de tir, placement d’une balle sur Virtua Tennis

• Measurement (« Evaluation ») :
Capacité d’anticipation et de reproduction de lois physiques existantes.
Ex : distance d’un saut, physique d’une balle dans FIFA, balistique sur ARMA etc.

• Cunning (« intelligence » dans le sens astucieux, rusé) :

Capacité d’utiliser tous les moyens intellectuels de résolution d’énigmes : réflexion, logique,
calcul mental.
Ex : cadenas à code dans Myst utilisant une suite mathématique, confusion de plan pour aligner
un message caché sur un mur, alignement de faisceaux lumineux dans The Witcher 3 ou Un-
charted, etc.
 Les Outils du Game Designer

Le métier de Game Designer est celui qui « coûte » le moins cher dans une production, car les out-
ils qu’il ou elle utilise ne nécessitent pas foncièrement d’avoir une station de travail.

Un bloc de papier et un crayon suffise à rédiger un Game Design, à créer un Level Design (« archi-
tecture d’un niveau » dans le sens zone de jeu, à ne pas confondre avec l’habillage artistique de
celui-ci, un même level design peut avoir différents habillages/thèmes exemple : la map Carentan
sur Call of Duty devenue Chinatown sur Call of Duty : Modern Warfare) ou même concevoir une
table de loots (« butins »).

N’étant plus au XIème siècle, on ajoutera quand même une connexion internet pour avoir accès
à Youtube, véritable mine d’or de sessions de jeu complètes sur tous les types de jeux (modernes,
retro, modding etc., tout y est). Le principe de Youtube est de pouvoir retrouver très rapidement
des références sur des méthodes déjà existantes : vous pouvez rédiger quatre pages de documen-
tation qu’un Let’s Play d’une poignée de secondes résumera mieux.

Le but du ou de la Game Designer est de se faire comprendre par le reste des équipes le plus
simplement possible, pas besoin de faire dans la littérature évoluée quand il s’agit d’expliquer le
positionnement d’une caméra ou le comportement d’un NPC : un clip vidéo de quelques secondes
le fera mieux et donnera à l’ensemble de l’équipe une vision unifiée, peu importe leurs codes
socioculturels ou leur langue maternelle. Le plus important est la capacité à synthétiser un maxi-
mum d’informations en un minimum de temps, ne pas hésiter non plus à utiliser des logiciels de
montage vidéo pour créer un Mock up (un « collage » de différentes sessions) pour bien détailler
un comportement, un timing d’animation ou autre. Quand un budget se compte en homme/jour,
chaque minute compte.

On ajoutera quand même une suite bureautique :

• Word, parce que vous allez écrire des docs sur tout, tout le temps
• Excel, car il faut pouvoir tout chiffrer, trier et manipuler
• Powerpoint, pour produire des documents de présentation de manière très simple
• Visio (pas obligatoire, mais un vrai plus), pouvoir présenter de multiples solutions sous une
forme graphique et facile à suivre (ex : pour des embranchements de dialogues, des comporte-
ments de NPC etc.)

Avoir une logique algorithmique est un pré-requis quasi obligatoire, car les jeux vidéo – même les
plus avancées – fonctionnent toujours sous la logique de trigger (« déclencheur »). Cela implique
une logique conditionnelle avec du « si », « alors » (ex : si le Player ouvre la porte, alors faire ap-
paraitre un monstre dans la salle). Le meilleur point de départ pour moi reste les langages simples
type BASIC (sur n’importe quelle calculatrice à 30 balles) qui permettent de bidouiller tout en pou-
vant aller très loin (et comprendre une logique d’allocation de mémoire par exemple sans avoir à le
maitriser). Le modding permet de toucher à tout, le plus important n’est pas de devenir program-
meur ou game artist, mais de comprendre quelles sont leurs contraintes pour mieux les anticiper
en amont (et leur faciliter la tâche).
 Les Outils du Game Designer (suite)

D’un point de vue plus global, il faut cultiver son éclectisme et ce dans tous les domaines. Rester
enfermé dans un domaine donné est le meilleur moyen d’aller droit dans le mur : musique, arts
appliqués, cinéma, littérature, peinture, sculpture etc. il faut s’ouvrir à tout. Les meilleures idées de
Game Design viennent d’inspirations externes, l’innovation doit rester le moteur de cette industrie,
qu’elle soit pour un public large ou pour un public de niche.

Il ne faut pas oublier son bagage vidéo-ludique et dédier un maximum de son temps au jeu. Vous
pouvez garder un ou deux jeux de chevet (parce qu’il faut bien s’amuser), mais il est impératif de
sortir de sa zone de confort pour voir ce qui marche ou ne marche pas ailleurs. Les plateformes
dématérialisées sont un excellent moyen de jouer à moindre coût, tout comme les options de part-
age de jeux ou les ludothèques proposées par certaines médiathèques. Les salons permettent de
rencontrer des développeurs indépendants (ils ou elles ne mangent pas, mais ne soyez pas lour-
dingues non plus). Ne vous contentez pas des trois gros jeux qui font l’actu dans l’année, mais ne
restez pas non plus hermétique à une grosse production dont le marketing vous débecte, car il y a
toujours une fonctionnalité ici ou là qui peut s’avérer intéressante.

Dernier point, terminez les jeux que vous commencez. S’il est facile d’apprécier un gameplay sur
une courte session, c’est l’intégralité du jeu qui vous permet de juger de sa qualité, de sa profon-
deur sur le long terme et de la capacité des designers à en renouveler l’expérience. Vous n’arrêtez
pas un film au bout de 25 minutes de projection ? Et bien, c’est la même chose pour un jeu.

En résumé, un ou une Game Designer doit avoir dans sa besace :

• Un bloc note et un crayon
• Une suite bureautique
• Un accès internet (Youtube est roi)
• Un bagage technique et artistique à développer au fil du temps (mais au moins des bases
saines)
• Une curiosité à alimenter en permanence
• Du temps de jeu, de préférence sur des genres inconnus ou peu connus
• Un côté roublard pour produire le plus rapidement en utilisant des sources existantes
• Bon niveau d’anglais (documentation d’outil en majeure partie en anglais, langue universelle
dans le développement)
 Les Documents de Référence

La communication est un élément important au sein d’une équipe, et même dans le cadre d’un dé-
marchage d’éditeur. Les Game Designers ont une panoplie de documents à disposition, documents
intervenant à des étapes différentes de la production. On détaillera ici ce qui sert de base et non
tout ce qui concerne le Reporting (« création de rapport ») : Play Test (« test de tout ou partie d’un
jeu sur une audience ciblée »), Focus Test (« test d’un élément très précis d’un jeu sur une audience
ciblée : gameplay, DA, heros etc. » ), Rational Level Design (« création de niveau rationnelle ») et
consorts, car ils font appel à des connaissances plus avancées et rendraient la forme de ce docu-
ment totalement indigeste.

GDC/GCD

Le premier document à produire pour un projet de jeu est le Game Design Concept/GDC (« Con-
cept de Création de Jeu ») ou Game Concept Document/GCD (« Document de Concept de Jeu »).
Il s’agit d’un document de séduction et de communication et a pour cible un éditeur/investisseur.
Il comporte deux parties : le document de cadrage et une mise en situation (concept, gameplay,
univers et pitch).

Le document de cadrage est une liste d’informations simples sur le jeu, une sorte de carte d’iden-
tité du produit et comporte les précisions suivantes :
• Nom du jeu (ou nom du projet) :
• Genre (se référer au chapitre sur les catégories) :
• Cible : Casual/hardcore et tranche d’âge (dans certains cas le sexe, mais très rarement)
• Support/Plateforme :
• Date de sortie prévue :
• Concurrents directs :
• Marché visé (Pays/Continent):
• Durée de développement estimée :
• Technologies utilisées (moteurs/logiciels tiers) :

De trois à cinq pages maximum, la mise en situation contient de nombreuses illustrations, croquis,
schémas, vidéos etc. En bref tout ce qui peut illustrer un propos et l’expliquer le plus rapidement
possible, il ne faut pas faire dans la littérature, il faut qu’à la lecture de ce document, l’interlocuteur
ait une idée clair du projet, autant dans son Game Design que dans ses coûts estimés.

C’est un document Stand Alone (« indépendant »), il peut être consulté seul et ne doit pas néces-
siter la présence d’un ou d’une Game Designer pour en expliquer le contenu. C’est littéralement la
première étape, le fait de mettre son concept par écrit.
 Les Documents de Référence (suite)

GDD

Le Game Design Document (« Document de Game Design ») doit détailler et approfondir les points
établis dans le GDC/GCD, et donner des exemples de situations de jeu. Destiné à la fois à l’éditeur
mais aussi aux équipes du studio, ce document comporte entre quinze et vingt pages et doit aussi
être Stand Alone. On commence à y parler des personnages (origine, interaction), des ambiances
sonore et musicale et du scénario s’il y en a.

Ce document doit être généreusement illustré, surtout s’il s’adresse à un éditeur. Ce qu’il faut bien
comprendre, c’est qu’un éditeur n’a pour unique indicateur que le ROI (Return On Investment «
Retour Sur Investissement ») du projet. Ce ROI comporte deux variables :
• le budget mis sur la table pour lancer le projet :
Les détails techniques du document sont importants dans ce sens : Quelle va être la taille de
l’équipe ? La durée du développement ? Les technologies utilisées (licences d’exploitation
logiciel et formation des équipes ou recrutement d’experts) ? L’implantation géographique
du studio (crédit d’impôt et charges différentes suivants les pays) ? etc. Autant de variables
qui font monter très rapidement le coût total, mais où l’éditeur doit avoir une bonne visibil-
ité afin de prévoir des levées de fonds ou crédits, comment intégrer cela sur un budget sur
plusieurs années etc.

• le chiffre d’affaire prévisionnel :

En fonction du public visé, de la plateforme, des tendances du marché, d’études marketing
etc., l’éditeur est plus ou moins enclin à investir sur le projet. Plus le résultat est alléchant, et
plus le budget sera grand.

Ne pas hésiter à y adjoindre en annexe un business plan (« plan d’investissement ») assez simple.
Cela montrera d’une part à l’éditeur que vous n’êtes pas un ou une « artiste » totalement coupée
des réalités et d’autre part que vous prenez au sérieux les problématiques de budget. Pas besoin
de forcément faire appel à un comptable (ça facilite quand même le travail), détailler simplement
les coûts humains/matériels/charges et multipliez ça par le nombre de jour de développement
estimé.
 Les Documents de Référence (suite)

Game Bible

Comme son nom l’indique, la Game Bible (« Bible du Jeu ») regroupe l’intégralité des informations
sur les fonctionnalités du jeu.

D’une taille de 50 à 500 pages (parfois plus), elle cible toute l’équipe et est rédigée puis com-
plétée par les différents Leads (« Chefs ») de chaque pôle : Game Designer, Artist, Programmer, etc.
Dépendante des ambitions du projet (et donc des équipes en place), elle intervient sur les phases
de production et de postproduction afin de fournir un document de référence pour tout le monde.

Les productions modernes utilisent un système similaire à un wiki (portail de contenu participatif),
permettant l’édition simultanée à plusieurs auteurs, l’incrémentation par version (pour revenir plus
facilement sur une erreur d’édition), une consultation peu importe le lieu, un lien avec un logiciel
ou portail de tracking (« traçabilité ») permettant de faire le lien avec un outil de debugging («
chasse aux bugs ») et faciliter le travail et la communication des équipes.

Certaines productions s’en passent et se contentent de quelques documents sur des points précis,
mais il est primordial de garder une source de référence pour toutes les équipes : le projet peut
évoluer, changer de main, être mis en pause etc. et le référencement de toutes ces informations
sera quoi qu’il arrive du temps gagné en cas de coup dur.

Le Lead Game Designer a le dernier droit de regard sur ce document et doit pouvoir comprendre
tout ce qu’il y a dedans. Sur certains projets, le Creative Director (« directeur créatif ») peut aussi
prendre un rôle important sur la rédaction de la Game Bible, encore une fois, cela dépend de l’or-
ganisation interne du studio.

Milestones

Au fil de l’avancement du projet, il convient d’avoir un outil permettant de juger de sa bonne ori-
entation et de sa qualité. La mise en place de Milestones (« Etapes importantes/clefs ») permet de
mettre en opposition les objectifs sur le papier et la réalité du projet/d’une feature à un instant «
t ». Ces Milestones sont définies sur le planning (« agenda ») de production en amont à la fois en
interne, mais surtout par l’éditeur qui veut s’assurer du bon déroulement du projet.

Le respect des Milestones est capital afin de valider la « bonne santé » du projet, ses délais et les
attentes de l’éditeur. Les éléments scrutés en premiers lors d’une Milestone concernent les Key
Selling Points/KSP (« Eléments de Vente Clef »), qui font l’identité du jeu et le démarquent de la
concurrence.
 Les Etapes de Production

La Pré-Production :

Il s’agit de l’étape la plus intéressante en tant que Game Designer et peut durer entre deux mois et
six mois. Si c’est plus long, c’est qu’il y a un souci quelque part.

Le fonctionnement est en équipe réduite, on ne prend que les Leads : Game Designer, Directeur
Artistique, Lead Programmer, Lead Level Designer, Producer, Chef de Projet, RH (parfois des dépar-
tements financiers en fonction de la structure).

Sa durée est flexible : elle est sanctionnée par un First Playable Prototype/FPP (« Premier Prototype
Jouable ») validé par l’éditeur. On ne passe pas en production tant que le FPP n’est pas validé.

Avant le FPP, les différents pôles ne travaillent que sur des prototypes répondant à des besoins
précis et centraux sur le jeu (ndlr : je ne détaillerai pas les différents prototypes sur ce document
pour ne pas l’alourdir). L’idée est de garder que ce qui fonctionne, si on s’amuse sans animation,
sans graphismes, sans son, avec des cubes et des primitives, le jeu va dans le bon sens.

Le DA (Directeur Artistique) réalise les Artworks (« concepts artistiques en 2D ») pour tester des
pistes, de la recherche sur la colorimétrie, les éclairages, les perspectives, le Character Design/Cha-
ra Design (« création des personnages ») etc. Il est aussi question d’un point de vue plus technique
de définir le nombre de triangles par éléments afin de faire rentrer le rendu final sur le cahier des
charges de la machine cible (en gros la puissance de calcul demandée pour le rendu graphique).

Le Lead Programmer décide des technologies utilisées : moteur maison ou tiers en fonction des
features, logiciels tiers (pour la physique par exemple), allocation mémoire pour les différents sec-
teurs (toujours pour respecter l’enveloppe de la machine cible), IA (puissance alloué aux comporte-
ments des NPC), scripts etc.

Le Game Designer va pour sa part déterminer la structure du jeu : combien de niveaux et/ou de
sous niveaux, durée de vie en heures de jeu, description précises des différentes phases de jeu,
précision sur la ou les caméras, détermination des capacités et des challenges proposés. Il peut
déjà établir un système de reward, mais doit le laisser ouvert à toute modification future. Les tests
à ce niveau se font exclusivement en interne.

A titre indicatif, la pré-production occupe entre 10 et 15 personnes sur une équipe de 120.
 Les Etapes de Production (suite)

La production :

Il s’agit de l’étape la plus longue du projet, elle s’étale le plus souvent sur plusieurs années. Si le
travail effectué en pré-production est de qualité, on ne remanie pas le gameplay.

C’est à ce niveau de la production que l’équipe est la plus grosse, surtout en fin de production avec
les débuggers/Testers QA (« Testeurs Assurance Qualité »). Le but du QA est de chasser et faire du
reporting sur les bugs, comportements inattendus et plus globalement tout ce qui s’éloigne du
cahier des charges initial et détériore l’expérience de jeu.

Cette étape voit la production de tous les assets (« éléments ») visuels et audio : personnages,
niveaux, props (« éléments du décor »), bruitages, soundtrack (« bande son ») etc.

Le Chara design passe par les étapes suivantes :

Croquis => Modélisation 3D => skinning (« dépecage », on crée une enveloppe comme les
habits d’une marionette) => rigging (« squelettage », on applique l’enveloppe du skinning
sur un squelette pour pouvoir l’animer, comme la main dans une marionnette en somme) =>
animations et applications des textures.

Du côté du Game Design, on réalise d’abord les croquis en Top-Down View (« Vue de Dessus »
comme un plan d’architecte) des niveaux. On établit un parcours type personnage et on y place les
ressources/bonus. Cette étape peut être réalisé en pré-production pour les plus rapides, mais at-
tention à ne pas partir trop tôt sur de la production de ce côté, car une modification dans le game-
play à la suite du FPP et ce boulot part à la poubelle.

Il s’agit aussi de définir et préciser les étapes du jeu pour savoir :

• Quelles sont les capacités disponibles ?
• Quels ennemis sont présents ?
• Quel niveau de difficulté appliquer ?
• Quelles sont les intentions du niveau (ajouter/baisser la pression sur le Player, ajouter du
rythme etc.) ?

Il est impéraif d’indiquer sur les croquis les temps de parcours « joué » et « non-joué ».
Cette étape peut aussi servir à faire du Rational Level Design/RLD (« création de niveau ratio-
nnel »), qui consiste à définir un niveau de difficulté arbitraire à chaque bloc de Level Design en
fonction des inputs, afin de contrôler la courbe de progression et la difficulté globale du titre.
Attention, le RLD reste un outil de contrôle et non de création, sans quoi le titre ressemble à une
partition connue d’avance (les Players plus dégourdis anticipent alors la courbe de progression et
cela donne l’impression d’être sur un rail).
 Les Etapes de Production (suite)

La production (suite) :

L’étape suivante de la production concerne la réalisation des gabarits en 3D. Tous les éléments sont
des formes primitives (cubes, cylindres, cônes, etc.) et tout doit être réalisé à la bonne échelle. At-
tention aux échelles différentes suivants les moteurs et les outils de modélisation 3D, l’un en pouce
tandis que l’autre est une unité propriétaire du logiciel, et c’est une perte de temps monumentale
au moment de l’intégration. Il arrive même parfois que la conversion ne soit pas possible (système
impérial vs international) à cause des décimales, forçant à tout recommencer.

Dans le moteur, on intègre le gabarit, on règle les collisions et on laisse les graphistes intégrer leurs
assets. On ne revient plus sur le design à cette étape et on travaille sur le scripting (langage haut
niveau) pour régler les comportements et les différents triggers.

Sur les moteurs récents, le travail participatif permet à certaines de ces étapes d’être réalisées en
parallèle (mise à jour des ressources en temps réel par le réseau par exemple), cela fait gagner un
temps fou et donc allège le coût de la production. Il limite aussi les accidents à l’intégration avec
du Versionning (« contrôle de version »), permettant de créer une branche à chaque nouvelle itéra-
tion et donc de revenir en arrière en cas d’erreur (un ctrl+Z à l’échelle d’un projet pour faire très
simple).

On en profite aussi pour tester en continu (en interne ou via des sessions de Play Tests avec du
public), afin de vérifier que les mécaniques et les intentions sont assimilées par les Players. Une
bonne couche de Débugs finaux et on enchaine avec la post-production.
 Les Etapes de Production (suite)

La Post-Production :

Il s’agit de l’étape la plus « facile » de la production, on compte entre 20 et 30 personnes sur une
équipe de 120.

L’équipe Marketing tourne à plein régime : promotion du titre, mise en place d’un support, site
internet, forum, communauté etc.

Le pôle programmation s’occupe des patchs pour les bugs C. Ils peuvent travailler sur le prochain
jeu ou épisode, voir un add-on (« extension »), DLC (« contenu téléchargeable ») ou de la Research
and Development/R&D (« Recherche et Développement »), possiblement un Post-Mortem.

Le Post Mortem est un document où l’on revient sur la production en épluchant la Game Bible,
en comparant ce qui a marché ou non. C’est une sorte de débriefing à l’échelle globale du projet
et c’est un outil vital pour un studio. Il faut rester objectif et n’opposer que des faits dans un Post
Mortem (ex : telle feature ne marche pas à cause de soucis dans le code, telle éléments pas com-
pris par les Players malgré les Play Tests etc.). L’exhaustivité d’un Post-Mortem est primordiale car
elle permet de rebondir sur la suite, ce document permet en gros de ne pas reproduire les mêmes
erreurs ou au contraire de valider par des données vérifiées sur le public une méthode ou feature.

Beaucoup de productions négligent cette étape au détriment de la production de nouveau con-

tenu, il est impératif de ne rien laisser au hasard ou à l’appréciation personnelle (ex : telle feature
est bien car je l’ai designé et qu’elle me plait). C’est une plus value extrêmement importante d’un
point de vue personnel pour l’équipe (identifier ses forces/ses faiblesses et agir en conséquence)
mais aussi pour le studio en général, pour créer des relations saines entre les membres.

Les Game Designers s’occupent du Port Mortem côté Game Design, de mise en place de patchs de
Game Balance (« Equilibre du Jeu ») ainsi qu’à la préparation de nouveaux projets.

Il n’est pas rare maintenant de voir les pôles Marketing ou Editoriaux travailler bien plus en amont
(même pendant la pré-production). Si cela leur permet d’installer une marque plus tôt sur le
marché, cela comporte de gros risques. En effet, cela peut venir parasiter le message des créatrices
et des créateurs car le public a déjà une image du jeu en tête, image qui ne correspond que très
rarement aux intentions du produit ou même sa qualité (cinématique en images de synthèse pour
une publicité vs jeu en temps réel). Si cela est bien fait, il peut y avoir un message bénéfique pour
le studio, puisque les équipes voient très tôt les réactions du public et cela peut booster leur moral
(contrairement à un travail en sous marin pendant des années), et cela peut aussi éviter l’effet souf-
flet qui retombe au moment du Reveal (« Révélation » du projet au public) à cause d’une commu-
nication mal maitrisée.
 Les Etapes de Production (suite)

Les versions :

Pré-alpha :
• Prototype ciblés : avec entre autre le fameux Proto 3C (Controls/Character/Camera Contrôles/
Personnage/Camera), des protos réseaux dans le cadre d’un jeu en ligne, des tests techniques
de rendu etc.

• First Playable Prototype : Validé par l’éditeur, sanctionne le passage en production.

Alpha :
Fin de pré-production, début de production. Les éléments commencent à être intégrés mais
pas réalisés, on peut encore tout changer.

Bêta (aussi appelée « Silver ») :

Toutes les features sont intégrées mais pas réalisées.

Code Release (aussi appelée Gold pour faire la distinction avec la Master) :
Sanctionnée par la validation de l’éditeur et/ou du constructeur. On ne change plus le game-
play, on ne fait que du débug en attendant de recevoir le tampon de validation.

Le cahier des charges des constructeurs est plus léger ces dernières années pour éviter les
allers-retours où certains studios n’avaient que peu d’information sur la nature du refus, mais
il inclut des tests de stabilité et comportements exotiques.

Gold Master / Master :

On ne touche plus à rien, on attend la sortie du jeu. Il s’agit de la version validée par le con-
structeur et pressée pour distribution en magasin ou déployée sur les Repositories (« serveurs
de dépôt », typiquement un serveur Steam/PSN/Xbox Live) en ligne.

Les données du jeu sont les mêmes que sur la version Code Release, mais on peut faire le dis-
tinguo car la Master inclut la couche constructeur : signatures anti-piratage, boot code (« code
de démarrage », nécessaire pour lancer le jeu sur une console commerciale et non de dévelop-
pement), mise à jour du système d’exploitation, etc. Pour résumer, la version Master est l’im-
age parfaite des données présentes sur le DVD/Blu-Ray trouvable en boutique.
 Les Etapes de Production (suite)

A propos des versions :

Le termes Alpha/Beta sont devenus pour certains des termes marketing, afin de trancher avec le
terme « Démo » qui pouvait renvoyer une image de produit non fini, d’expérience limitée et vul-
gaire « bombec » en attendant le produit final. Les éditeurs utilisent les termes Alpha et Bêta à
outrance pour donner un sentiment au public de faire parti du développement. Ces termes peu-
vent effectivement renvoyer au statut de Beta d’un code réseau pour un jeu en ligne (par ex : Call
of Duty, Battlefield), mais porter le statut Alpha à moins de six mois d’une sortie rentre dans l’es-
croquerie.

Autre point : les méthodes de développement modernes sont beaucoup plus souples pour les
développeurs, notamment grâce à internet. Les dates de sorties sont primordiales pour l’éditeur
et prévalent dans beaucoup de cas sur la qualité finale du titre, jouant la carte du Patch Day One
(« Patch du premier jour », une mise à jour la journée de la sortie pour réparer des bugs) comme
bouée de sauvetage. Il est alors possible d’envoyer sa Gold et d’obtenir une validation du construc-
teur (avec des bugs bloquants dans le code).
 Les Bugs

Il y en aura toujours, partout, tout le temps. Le plus souvent générés par une méconnaissance des
outils et du moteur, le but est de créer une méthode la plus efficace pour les tracker (« pister »), en
faire un raport et les hiérarchiser. Les outils de Bug Tracking (« pistage de bug ») sont très efficaces
là-dessus et permettent via un système de ticket de tout lister, hiérarchiser et attribuer la répara-
tion à un membre de l’équipe.

Les Bugs sont hiérarchisés comme suit :

• Bugs A : empêche toute progression dans le jeu. Doivent être totalement éliminés avant la
BETA.

• Bug B : bug visible et/ou handicapent pour le joueur (collisions, scripting, comportements).
Bugs d’affichage, de textures etc. Bugs éliminés en BETA.

• Bug C : bug esthéthique/immersif (texte qui dépassent, textures mal dimensionnées, mauvais
placement de caméra etc.). Ils sont éliminés jusqu’à la dernière minute.

Enfin, si vous doutez d’un projet livré sans bug, remémorez-vous les jeux d’arcade japonais, c’est
de l’orfèvrerie en termes de finition.
 Conclusion

Pour avoir fait le tour du monde des studios au cours de mon passage en tant que journaliste chez
Gamekult, je peux vous assurer qu’il y a quasiment autant de variantes de ce qui est rédigé ci-des-
sus que d’équipes de développement. Le plus souvent très légères, ces variations sont les témoins
de méthodes de création où un nombre de paramètres importants rentrent en ligne de compte
mais avec un but commun : celui de maitriser la production de bout en bout, autant sur la qualité
du produit final que le budget.

Que vous soyez un duo ou équipe de mille personnes, l’argent reste le moteur d’une production et
la rationalisation des méthodes de création permet de garder un contrôle maximal sur tout le pro-
cessus. Prises indépendamment, ces méthodes paraissent dépendre du bon sens, mais la discipline
requise pour maintenir ce bon sens dans tous les domaines de création est la clef de la réussite.
Comme pour un sport collectif, ce n’est pas le skill individuel qui est le plus dur à atteindre, mais
bien la coordination et le suivi d’un plan de jeu commun qui garantissent la réussite.

N’oubliez jamais que vous faites des jeux pour les autres et non pour vous. Testez sans vergogne,
sortez de votre zone de confort, n’ayez pas peur de la réaction du public, vous prendrez plus de
bides et d’annulations de projet que de succès. Ce medium, à la croisée des arts appliqués et des
sciences, est le seul à bénéficier directement de la notion d’interactivité. Faites évoluer l’innovation,
la recherche de la perfection et apportez du divertissement à tous. Pas besoin de se cacher derrière
de beaux discours, un Game Design solide parle de lui-même.

N’oubliez pas enfin que les Game Designers sont les seules personnes au monde à avoir le pou-
voir de pousser n’importe qui à faire n’importe quoi, tout offrant un niveau de satisfaction comme
nulle part ailleurs. Voilà pourquoi c’est tout simplement le meilleur métier du monde.