lundi 5 mai 2014


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

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 -é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.
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.

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.


traduction : Céline Bernardeau



Un mot sur :


La Méthode SCRUM



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.




Plusieurs outils ou moments clés caractérisent la méthode SCRUM :


- Sprints ou itérations : Scrum fonctionne en Itération, d'une durée de 15 jours par exemple. Chaque Itération a un but à atteindre, défini par le client. Une version du logiciel est générée à chaque Itération, afin de livrer au client une version montrant le travail réalisé durant ce Sprint.

- Daily Scrum : Chaque jour des Scrums (petites réunions) sont réalisés afin de connaître l'état d'avancement de l'équipe, de faire le point sur les problèmes potentiels. Très important car ces réunions d'une dizaine de minutes (souvent réalisés debout), donne une bonne vision au client, au Scrum Master et à l'ensemble de l'équipe du projet.

- Backlog ou carnet de commande : C'est le nom que l'on donne aux besoins fonctionnels récoltés auprès du client et que l'équipe de développement doit réaliser. Ce backlog est souvent accompagné par une estimation en terme de point de la durée nécessaire pour réaliser ces fonctionnalités. Cette liste de fonctionnalités existe au niveau du projet (toutes les fonctionnalités du projet) et au niveau du sprint (les fonctionnalités à réaliser durant l'Iteration)

- Vélocité : La vélocité correspond au nombre de point qu'une équipe peut réaliser dans une Itération. L'équipe de développement passe par une phase d'engagement, afin d'indiquer au client quelles sont les fonctionnalités (et le nombre de points) qui seront réalisées au cours de ce sprint.

- Scrum Planning : correspond à la phase d'engagement de l'équipe sur les fonctionnalités qui seront réalisées durant l'Itération. Une estimation des tâches peut être réalisée à ce moment.

- Daily Scrum : correspond aux petites réunions journalières afin de présenter le travail réalisé à l'ensemble de l'équipe.

- Rétrospective : à chaque fin de sprint, l'équipe se réunit afin de faire un bilan du sprint qui vient de se dérouler, et de trouver des axes d'amélioration pour les prochains. Les rétrospectives sont menées par le Scrum Master.










Aucun commentaire:

Enregistrer un commentaire