Game Design Concepts
2/3
Une expérience de la conception et de l'enseignement du Game Design
Ian Schreiber
Extraits du second cours des game studies de Ian Schreiber, qui se sont tenus entre fin juin et début septembre 2009. Cette seconde partie de cours revient sur les fondamentaux du game design et de la gestion de projet. Introduction plutôt bien faite, pour qui souhaite amorcer une formation en game design.
Liens vers :
Game Design Concepts 1/3
Game Design Concepts 3/3
Liens vers :
Game Design Concepts 1/3
Game Design Concepts 3/3
Source : gamedesignconcepts.wordpress.com
Game
Design / itération et prototypage rapide
La
dernière fois nous avons posé la question : qu'est-ce qu'un jeu
vidéo ? Aujourd'hui, nous allons étudier une question connexe au
jeu vidéo : Qu'est-ce que le Game Design? Cette fois, nous allons
examiner le processus de création. Comment les jeux sont-ils fait?
S'il est possible de faire un jeu de l'Oie en 15 minutes, il vous
prendra un peu plus de temps si vous cherchez à faire le prochain
World of Warcraft.
Le
Game Design
Nous
allons beaucoup utiliser le mot « Design » dans ce cours. C'est un
terme qui est un peu sur-utilisé, donc je vais me permettre de
clarifier ce que je veux dire ici, par Design. le Game Design est la
création des règles et le contenu d'un jeu. Il n'implique pas de
programmation, d'art ou d'animation ou de commercialisation, ou d'innombrables autres tâches nécessaires à la réalisation d'un
jeu. Toutes ces tâches peuvent être appelées collectivement «
développement de jeu vidéo » et le Game Design est une partie du
développement.
Malheureusement,
j'ai vu le terme « Design » utilisé (en particulier dans certains
programmes scolaires) pour désigner tous les aspects du
développement du jeu. Lorsqu'il est utilisé dans l'industrie du jeu
vidéo (ou l'industrie du jeu), « Game Design » a un sens très
précis, et c'est ce sens là que nous utiliserons dans ce cours.
Types
de Game Design
Il
y a plusieurs tâches associées à la conception de jeu :
- La conception de Système
- Le level Design
- La conception du contenu
- La conception de l'interface utilisateur
- La gestion des sauvegardes
- La création d'un monde
- L'écriture de l'histoire
- Le réglage et l'équilibrage du jeu
Nous
pourrions aisément étudier l'une de ces conceptions pendant 10
semaines. Les sujets abordés dans ce cours cette année, se
concentreront sur la conception des interfaces utilisateurs (UI), sur l'écriture scénaristique (Story
Writting), et le Design du Système (System Design ou Core System
Design).
Règles
de base du jeu
La
conception du système est de définir les règles de base du jeu.
Quels sont les éléments du jeu? Qu'est ce que vous pouvez
contrôler? Quelles mesures pouvez-vous prendre en tant que joueur?
Que se passe-t-il quand vous faites une action, et comment cela
affecte t-il l'état du jeu? En général, la conception du système
est la création de trois choses :
1 -Les règles
de mise en route : Comment débute le jeu ?
2 - Les règles
de progression : Une fois que le jeu commence, ce que peuvent
faire les joueurs, et ce qui se passe quand ils font des actions.
3 - Les règles
de résolution : Qu'est ce qui cause la fin du jeu? Si le jeu a
un résultat (par exemple de gagner ou de perdre), comment ce
résultat est il déterminé?
Si
vous pensez à l'analyse du Sudoku ou des Morpions que nous avons vu dans
le cours précédent, vous remarquerez ces jeux très simples
contiennent tous ces règles. La création de ces règles est la
conception du système, et c'est ce que nous verrons la plupart du
temps dans ce cours.
Qu'est-ce qu'un Game Designer?
Comme
vous l'avez peut-être remarqué, le Game Design est un domaine
incroyablement vaste. Ceux d'entre-nous qui sont parfois des Game
Designers professionnels ont du mal à expliquer ce qu'ils font à
leurs proches. La raison à cela est que ce métier comprend
énormément de choses. Voici certaines analogies que j'ai pu
constater lorsque vous essayez d'expliquer ce que c'est que d'être
un Game Designer :
" Le Game Designer est un artiste ". Le terme « art » est tout 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, du moins), alors le Game Designer est un artiste.
" Le Game Designer est un architecte ". Or, l'architecte ne construit
pas des structures physiques ; il crée des plans. Le Game Designer
crée également des plans, qui sont appelés des Design Docs. Le
Game Designer crée des plans, sous forme de prototypes, qui sont
ensuite produits en masse par les éditeurs.
" Le Game Designer est l'hôte de la partie ". En tant que designer, il
invite les joueurs dans
son espace et fait de son mieux pour que les invités (joueurs)
passent un bon moment.
" Le Game Designer est un chercheur scientifique ". En effet, le Game
Designer crée des Jeux d'une manière qui est très proche de la
méthode scientifique.
" Le Game Designer est un dieu ". Le Game Designer crée des mondes,
et les règles physiques qui régissent ces mondes.
" Le
Game Designer est un avocat ". Il crée un ensemble de règles
que d'autres doivent suivre.
" Le
Game Designer est un instructeur ". Comme nous le verrons plus
tard quand nous commencerons la lecture de la théorie du fun, du
divertissement et de l'éducation, nous verrons qu'ils sont fortement
liés, et les jeux sont (du moins parfois) amusants, parce qu'ils
développent précisément de nouvelles compétences.
Si
le Game Design est toutes ces choses, comment l'inscrire dans un
programme d'étude ? L'étude du Game Design pourrait alors être
justifiée dans des écoles d'art, d'architecture, de théologie, de
droit, de génie, de sciences ou d'une demi-douzaine d'autres
filières.
Est-ce qu'un Game Designer doit rassembler toutes ces compétences? Aucune
d'entre elles ? Le sujet reste ouvert, mais je pense que le Game
Design comporte des éléments de beaucoup d'autres spécialités, mais
c'est toujours le même domaine.
Science
du Jeu : Comment est conçu un jeu ?
Il
existe de nombreuses méthodes. Historiquement,
la première méthodologie de conception de jeu était connue comme
la Waterfall Method.
Waterfall
Method
Le
modèle en cascade définit (avec de nombreuses variantes) une suite
d'étapes dans le processus de développement.
Voici comment elle se manifeste dans
le cadre d'une production de jeu vidéo :
- Analyse : on conçoit le jeu en entier sur papier.
- Design : a l'aide de la programmation dans un jeu vidéo, ou la création du plateau et des pièces pour un jeu non numérique.
- Test : afin de s'assurer que les règles fonctionnent correctement
- Ajoutez quelques graphiques propres (pour faire joli :P)
- Expédier
La Waterfall Method est ainsi nommée parce que,
comme l'eau dans une chute, vous pouvez déplacer la
production uniquement dans une seule direction. Si vous êtes occupés à finaliser l'aspect visuel (art) pour le jeu et que vous constatez
un incompatibilité (taille de fichier, résolution...), vous ne
pouvez rien changer.
Cette
méthodologie n'inclut pas la possibilité de revenir à l'étape
de conception précédente, une fois que vous avez terminé une
phase.
La
principale caractéristique de ce modèle est que chacune de ces
étapes doit être terminée avant de pouvoir entamer la suivante. Ce
modèle simple, mais rigide, se heurte à de nombreuses difficultés
dans la réalité, et en particulier :
1
- L'explosion de la complexité lors de l'analyse, en fonction du
nombre d'éléments à inclure, on ne peut tirer parti d'éventuels
progrès dans la compréhension du problème résultant du passage au
développement réel, augmentant les coûts de l'analyse initiale.
2
- Les risques existent à chaque niveau, et le coût de résolution
des problèmes augmente avec leurs découvertes. Comme le test
est l'une des dernières étapes, le coût de traitement des erreurs
découvertes en test, qui impliquent un retour à la première étape
pour correction, est extrêmement élevé : on considère
généralement que le coût de correction d'une erreur détectée est
exponentiel en fonction du délai entre le début du projet et la
date de découverte de l'erreur.
À
un moment donné, quelqu'un a compris que ça pourrait être une
bonne idée d'avoir au moins la possibilité de revenir en amont du
développement, pour pouvoir modifier les étapes précédentes en cours de
production.
Approche
Itérative et Prototypage rapide
D'où
la création de ce qu'on appelle parfois une approche itérative.
Comme avec la méthode Waterfall, vous faites tout d'abord la
conception du jeu, puis mettez en place un prototype, puis vous vous
assurez que ça fonctionne. Et seulement après vous ajoutez une étape
supplémentaire dans l'élaboration du jeu.
Jouez,
décidez ce qui fonctionne et ce qui doit être modifié ou changé.
Et puis, prenez une décision : est-ce OK, ou devez-vous revenir à
une étape de développement antérieur et apporter des modifications
?
Si
vous décidez que le jeu est assez bon, c'est OK. Mais si vous
identifiez des changements, vous reviendrez d'abord à l'étape de
conception, trouverez des moyens de résoudre les problèmes
identifiés, mettrez en œuvre ces changements, et ensuite ré-évaluerez, jusqu'à ce que le jeu soit fonctionnel.
Si
cette méthode semble familière, c'est parce que c'est plus ou moins
la même approche que la méthode scientifique :
Faites une observation :
« Mon expérience de joueur m'a démontré que
certains types de mécaniques sont fun. »
Faites une hypothèse :
« Je crois que cet ensemble particulier de règles rendra le jeu plus amusant ».
Créez une expérience pour vérifier ou réfuter l'hypothèse :
Testez ce jeu et analysez s'il est amusant ou non.
Testez ce jeu et analysez s'il est amusant ou non.
Analysez les résultats de l'expérience formant une nouvelle série
d'observations. Puis, revenez à la première étape.
Avec
les jeux non numériques (carte et plateau, par exemple) ce processus
fonctionne correctement, car il peut être fait rapidement. Avec les
jeux vidéo, il y a encore un problème : la mise en œuvre
(programmation et débogage) est coûteuse et prend beaucoup de
temps. Si il faut en moyenne 18 mois entre la première ligne de code à la
création complète du moteur de jeu, et que vous avez seulement deux
ans pour réaliser l'ensemble de votre projet, il ne vous ne sera pas
possible d'obtenir à temps un gameplay correct.
Le plus souvent vous itérerez, meilleur au final sera votre jeu
Par
conséquent, tout processus de Game Design devrait impliquer des
itérations (qui consiste à réaliser un cycle complet de conception/mise en œuvre/évaluation). Et tout ce que vous pouvez concevoir
de façon flexible, qui permettra les itérations, entraînera
généralement la réalisation d'un meilleur jeu. Pour cette raison,
le Game Design sera prototypé sur papier, et ensuite seulement
impliquera les programmeurs lorsqu'ils seront eux-même convaincu que les règles de base sont réalisables et amusantes. Nous appelons
cela le prototypage rapide.
Itération et Risques
Le
développement et la mise sur le marché des jeux comportent beaucoup de risques :
- Le risque de conception.
- Le risque que le jeu ne soit pas fun et que les gens ne l'aiment pas
- Le risque de mise en œuvre (la possibilité que l'équipe de développement ne soit pas capable de fabriquer le jeu, même si les règles sont solides)
- Le risque du marché, le fait que le jeu puisse être excellent mais que personne ne l'achète
- Et ainsi de suite...
La
méthode itérative permet de réduire les risques lors de la
conception. Plus vous itérez, plus vous pouvez être certain que les
règles du jeu seront efficaces.
Nous
arrivons à présent à un point important : plus le Game Design de
votre jeu est original (autrement dit, quand votre Gameplay est
totalement nouveau et n'a pas d'antécédent sur le marché), plus
vous avez besoin d'itération. La méthode itérative n'est pas aussi
importante pour les jeux où la mécanique est en grande partie
inspirée par un autre jeu à succès : les suites de jeux populaires
sont des exemples de produits où la Waterfall
Method fonctionne correctement.
Ceci
étant dit, la plupart des Game Designers aspirent à créer des jeux
qui sont créatifs et novateurs.
En
résumé :
Les
avantages de cette approche itérative du développement sont :
- La réduction des risques : Permet d’avoir une visibilité de ce qui
est achevé à un moment précis du projet.
- L'augmentation de la valeur : Livrer rapidement une version jouable a des avantages, être
en mesure de livrer le produit quand il est considéré comme assez
bon, plutôt que de devoir attendre tous les éléments destinés à
être livrés.
-
Plus de souplesse/d'agilité : On peut choisir de changer de
direction ou d’adapter les prochaines itérations sur la base ce
qui a été développé et sur l’utilisation du jeu.
-
Une meilleure gestion des coûts : Si, comme tous les trop nombreux
projets de développement de jeu, vous courez après le
budget, une certaine économie peut-être apportée par la méthode
Agile.
Pour cette approche, et pour être efficace, chaque fonction/caractéristique doit être pleinement développée, dans la mesure ou elle doit être livrable, avant de passer à la suite.
Une autre pratique consiste à faire en sorte que chaque fonction soit développé par ordre de priorité, et pas nécessairement dans un ordre logique. Dans le cas contraire, vous pourriez manquer de temps, pour en avoir perdu sur des fonctions de moindre importance.
Construire les fonctionnalités du jeu " importantes " mais peu techniques est également souhaitables pour les même raisons.
Ce n'est que lorsque vous avez terminé tout ce que vous devriez avoir comme fonctions que vous pouvez passer à ce que vous pourriez avoir.
Sinon, vous risqueriez de vous retrouvez dans une situation où vos premières caractéristiques sont fonctionnellement très riches, alors que du côté du moteur de jeu, les caractéristiques seront de moins en moins sophistiquées au fur et à mesure que le temps avance.
Faites en sorte de sauvegarder votre production (backlog, terme lié à la méthode SCRUM) ou votre liste de fonctionnalités pour qu'elle s'exprime en terme de cas d'utilisation, de scénario utilisateur, ou de caractéristiques.
Idéalement, chaque tâche figurant sur la liste doit toujours être quelque chose qui a de la valeur pour l'utilisateur, et doit toujours être vue comme un produit livrable plutôt qu'un produit qui permet de juger de la complétude et de la qualité.
Ce sont des caractéristiques importantes du développement itératif. Elles sont essentielles si vous prévoyez de livrer votre jeu dans les délais fixés.
Pourquoi
ce cours est « non-digital »?
Certains
d'entre-vous feront des Jeux de société, donc la maîtrise
d'éditeur de jeu vidéo ne sera pas nécessaire. Pour ceux qui feront des jeux vidéo, vous avez, j'espère, assimilé que
l'itération est une méthode majeure dans le développement d'un jeu.
L'itération est plus rapide sur papier. Vous pouvez faire un jeu en 15 minutes. Le jeu codé prendra significativement plus de temps. Dans la mesure du possible, commencez par prototyper sur papier, parce qu'un prototype papier de 15 minutes et une séance d'une heure de test de jeu peuvent vous faire économiser des mois de programmation.
L'itération est plus rapide sur papier. Vous pouvez faire un jeu en 15 minutes. Le jeu codé prendra significativement plus de temps. Dans la mesure du possible, commencez par prototyper sur papier, parce qu'un prototype papier de 15 minutes et une séance d'une heure de test de jeu peuvent vous faire économiser des mois de programmation.
Il
y a une autre raison, si nous nous concentrons sur les jeux non
numériques (particulièrement pour les jeux de plateau et les jeux
de cartes). Il s'agit d'un cours de conception de systèmes,
c'est-à-dire, de création de règles du jeu. Dans les Jeux de
société, les règles sont mises à nu. Il peut y avoir certains
éléments physiques, bien sûr, mais l'expérience de jeu est
presque entièrement déterminée par les règles et les interactions
du joueur. Si les règles ne sont pas convaincantes, le jeu ne sera
pas intéressant. Pour analyser le jeu, il faut faire un lien clair
entre les règles et l'expérience du joueur.
Ce
n'est pas toujours vrai dans les jeux vidéo. Nombreux sont ceux qui ont des graphiques et une technologie impressionnante (comme les
moteurs de réalité virtuelle) un univers sonore riche, qui peut
masquer le fait que le Gameplay présente des erreurs et des
faiblesses. Les jeux vidéo prennent également beaucoup plus de
temps à faire (en raison de la programmation la création sonore et
graphique), ce qui les rend laborieux à développer dans un cours
d'introduction au Game Design.
Le
lien entre les règles et l'expérience du joueur est aussi flou dans
les Jeux de rôle. Je me rends compte que beaucoup d'entre vous ont
exprimé un intérêt dans la conception de RPG.
Gardez
à l'esprit qu'un RPG est essentiellement un exercice racontant une
histoire (avec un système de règles pour définir les limites de ce
qui peut et ne peut pas se produire). Ainsi, un excellent scénario peut être ruiné par des joueurs qui ont peu d'idées,
ou une faible capacité pour l'improvisation. En revanche, un
mauvais scénario peut être amélioré par des joueurs plus habiles.
Nous
laisserons donc, dans un premier temps, de côté, ce type de jeu.
Un mot sur :
La Méthode SCRUM
Source : http://www-igm.univ-mlv.fr
Scrum
signifie la « mêlée »
au
rugby, c'est à dire que cette méthode s'articule autour d'une
équipe soudée, ayant un but commun.
La
méthode SCRUM définit le principe d'Itération, appelé Sprint.
L'équipe de développement a donc un but connu à atteindre en une
Itération, dont la durée est souvent de 15 ou 30 jours. A la fin
d'une Itération, une livraison du produit doit être effectuée afin
de présenter au client ce qui a été réalisé durant cette
Itération.
L'équipe
utilisant la méthode SCRUM doit définir plusieurs rôles : un
Product Owner qui est le représentant du client, une équipe de
développement et un Scrum Master qui veille à la bonne application
des valeurs de SCRUM.
