Game Design 101 : La Game Doc, cette inconnue

Par le mars 22nd, 2010

101 en américain, ça signifie 1er cours de 1ère année. Vous retrouverez dans 101 les cours et notions de base qui font de nous une industrie particulière. N’y voyez donc pas des cours, leçons de choses ou de morale pour les pros du domaine concerné. Il s’agit plutôt de survoler le sujet pour les curieux, notamment d’un autre domaine que celui concerné.

Donc parfois on simplifiera, parfois on raccourcira, parfois on ne fera qu’effleurer le sujet. Que les pros ne s’en offusquent pas trop et que les néophytes en profitent.

J’ai pu avoir aujourd’hui sous la main la game doc d’un petit projet amateur pour le moins ambitieux.

Seul problème, j’ai moins bien compris ce qu’était le jeu APRES avoir lu la game doc’, qu’avant.

Afin de leur filer un coup de main (bien que je n’ai pas le temps en fait) voici une petite (sic) explication de ce qu’est, et ce que n’est pas votre game doc.

Game Doc GTA Harbour City

La Game Doc de GTA Harbour City, selon IGN

A la base c’est quoi une game doc?

Game Doc, Game Documentation, Game Design Documentation, Design Documentation. Globalement il s’agit des mêmes mots pour recouvrir la même idée. Le but est de faire un document synthèse présentant l’ensemble des choix de conception d’un jeu.

Généralement, on a donc une game design doc, et on peut avoir si nécessaire (à coté, c’est mieux, vous verrez pourquoi par la suite) une Technical Doc, pour expliquer et clarifier les choix techniques, et une éventuelle Art Doc pour un jeu où ce serait très important (à caractère historique par exemple).

Une game doc n’est pas un foutoir où on met tout ce qui dépasse. Non. Vous devez comprendre que si tous les choix de design doivent y être expliqués et détaillé, on peut aussi faire l’impasse sur l’aspect technique, par exemple.

Savoir quel public cibler.

L’important est de savoir à qui vous vous adressez. Vous pouvez avoir plusieurs game doc en fonction du public à laquelle il s’adresse.

  • Est ce que c’est pour l’éditeur ? Lui voudra un document global avec un niveau de détail moyen.
  • Est ce que c’est pour les développeurs ? Eux auront besoin de savoir le détail des mécanismes de gameplay, des routines d’IA, des scripts à concevoir.
  • Est ce que c’est pour la direction ? Elle a besoin de savoir les choix faits, les choix restants à faire au niveau game design, le nombre de personnes à affecter…

Bref suivant le public, les morceaux importants sont différents; il est donc parfois plus utile de faire une ou des game doc, soyez un stratège efficace.

La forme

La Game Doc doit généralement se présenter sous la forme d’un document imprimé au format A4. Oui, je sais, certains utilisent des Wiki. Mais la compilation et l’impression des données (Dans 95% des cas l’éditeur préfère un PDF à un wiki) et les soucis inhérents à un wiki (exemple: qui peut écrire sur quoi ?) rendent la chose encore plus pénible.

Je vous invite donc à mettre votre document en forme sur un traitement de texte tel word (ou mieux Indesign si vous avez les quelques connaissances techniques pour, Indesign permettant l’ajout et la modification de .txt à la volée, c’est parfois très puissant… Mais il n’y a pas de correcteur orthographique, faites gaffe).

La langue

Dans 95% des cas, l’Anglais est préférable. Ne serait ce que parce que Sony/Nintendo/Microsoft vous demanderont une version résumée et circonstanciée en anglais de votre game doc pour passer les approvals.

De plus la plus part du temps, votre éditeur enverra le document à la maison mère (comprendre au UK ou aux USA) ou à une filialle américaine pour estimer le potentiel de vente là bas, facteur important dans les négociations

Désolé, va falloir s’y mettre.

Cependant concernant un projet amateur, où les seuls (et encore) lecteurs de la doc seront les développeurs, le Français suffira bien.

Suivez vos versions

Dans la mesure où vous devrez la mettre à jour très régulièrement avant et pendant le développement, numérotez chaque version de votre game design document. Et faites un historique. N’oubliez pas que ce document est vivant, et est amené à être modifié très souvent.

Qu’est ce qu’on y met (généralement) :

Ceci est à adapter à votre jeu.

  1. Introduction
    1. Nom du jeu, features clefs et résumé en 3 ligne
    2. Droits, copyrights, licence.
    3. Versions, auteurs
  2. Table des matières
  3. Résumé des points importants
    1. Le concept
    2. Les fonctionnalités clefs (ou features)
    3. Genre
    4. Public Cible, ESRB, PEGI…
    5. Flux principaux du jeu (les boucles principales du jeu, comme « je gagne de l’argent ça me permet d’acheter des batiments qui me rapporteront de l’argent… »)
    6. Look and feel
      1. Style visuel
      2. Références visuelles
      3. Emotions recherchées
    7. Dimensions du jeu
      1. Liste des lieux
      2. Liste des niveaux
      3. Liste des personnages joueurs
      4. Liste des personnages non-joueurs
      5. Liste des armes
      6. …
  4. Gameplay
    1. Mécanismes à la disposition du joueur
      1. Interaction avec l’univers
        1. Objets
        2. Boutons
        3. Personnages Non Joueurs
        4. Autres joueurs
        5. Mouvements
      2. Feedback de l’univers
      3. Contrôles
    2. Mécanismes internes (non directements lancés par le joueur).
    3. Progression
      1. A l’intérieur d’un niveau
      2. Entre les niveaux
    4. Objectifs
      1. Objectifs globaux du jeu (de la storyline)
      2. Comment sont proposés les défis / missions /objectifs des différents niveaux
      3. Structure et forme des micro-objectifs (genre des mini-jeux)
    5. Flux de jeu et relation entre action et objectifs.
    6. Gestion de la physique
    7. Systèmes clefs
      1. Système économique
      2. Système de combat
      3. Physique
      4. Collision
      5. Path Finding
    8. Rejouabilité
    9. Multijoueur
    10. Interface
      1. Liste des différents écrans
      2. Utilité de chaque écran
      3. Comment passer de l’un à l’autre
      4. Heads Up Display
    11. Options
    12. Sauvegarde
    13. Triche, Easter eggs
  5. Histoire et univers
    1. Les personnages
      • Histoire
      • Personnalité
      • Look
      • Capacités physiques
      • Animations
      • Capacités spéciales (gameplay)
      • Rapport à l’histoire
      • Rapport aux autres personnages
    2. L’histoire
      1. L’histoire au début du jeu
      2. Evolution au cours du jeu,
        • chapitre par chapitre
      3. Fins possibles
    3. Lien entre les chapitres et la progression en niveaux
    4. Elements de soutien
      1. Licence éventuelle
      2. Références historiques
      3. Références visuelles
    5. Cinématiques :
      • Acteurs
      • dialogues
      • durée
      • storyboard
      • script
      • placement des caméra
    6. Ambiances et atmosphère
      1. Globale
      2. Moyens mis à disposition
  6. Niveaux
    1. Synopsis du niveau
    2. Description détaillée, carte
    3. Couleurs, ambiance, texture
    4. Introduction scénaristique
    5. Objectifs
    6. Rencontres
    7. Objets
    8. Elements narratifs
    9. Walkthrough
    10. Placement des caméra
  7. Système d’aide et difficulté
    1. Aide
      1. Tutoriaux
      2. Tooltips
      3. Progression dans le déblocage des actions
      4. Compréhension de la storyline
    2. Difficulté
      1. Gestion de la difficulté globale
      2. Gestion de la difficulté interne à chaque niveaux
      3. Intelligence Artificielle
        1. IA adverse
        2. IA de soutien
    3. Playtests
  8. Management
    1. Milestones
    2. Planning détaillé
    3. Budget
    4. Analyse des risques
    5. Localisation
    6. Production
    7. Tests
  9. Liste des assets
  10. Bible Technique (peut être séparé dans un second document)
    1. Plateforme cible
    2. Logiciels, outils, licences
    3. Procédures et standards, conventions
    4. Moteur de jeu
    5. 3D
    6. Réseau
    7. Scripting
    8. Mécanismes clefs
    9. Implémentation des mécanismes clefs
  11. Bible Artistique (idem)
    1. Concepts
    2. Graphique
      1. Charte graphique
      2. Guides de style
      1. Effets recherchés
      1. Personnages
      2. Environnements
      3. Cinématiques
      4. Effets spéciaux, filtres
      5. Références
      6. Méthodes
    3. Audio
      1. Charte graphique
      2. Guides de style
      3. Effets recherchés
      4. Personnages
      5. Environnements
      6. Cinématiques
      7. Effets spéciaux, filtres
      8. Références
      9. Méthodes
  12. Logiciels Third Party (idem)
    1. Editeur de niveau
    2. Plugins artistiques
    3. Librairies de code
    4. Mise à jour, Installation du jeu

10 Conseils supplémentaires

  1. Plusieurs contributeurs, un seul intégrateur pour la game doc
  2. Un bon dessin vaut souvent toutes les explications textuelles du monde
  3. Les références aident à comprendre. Novateur ne veut pas dire « sans référence ». L’abus de référence inutile nuit, par contre.
  4. Votre game doc doit présenter le jeu fini dans l’ensemble de ses aspects
  5. Une storyline ne fait PAS un jeu. Une liste de niveau non plus. La compréhension des mécanismes de gameplay et des features clefs doit être votre point le plus important
  6. Une belle présentation ne nuit jamais. Idem pour un bon packaging.
  7. Ne mettez jamais la charrue avant les boeufs; organisez votre contenu de façon à ce que chaque concept utilisé ai été défini dans une section spécifique avant.
  8. Un lecteur doit pouvoir s’imaginer votre jeu en lisant la game doc. Confiez la à des inconnus et notez ce qu’ils comprennent du jeu. Ne supposez jamais que votre lecteur comprend ou connait déjà votre jeu.
  9. Votre game doc doit vendre votre jeu autant que le présenter intégralement
  10. Un bon game designer sait clairement ce qu’il voudrait comme features. Il peut donc l’énoncer simplement dans la game doc, et le rendre accessible à des non designers.

Et bon courage ! :)




Articles connexes

Catégorisé sous : Formation, Game Design.
Mots clefs associés : , , .

Laisser un commentaire