Informatique

Hello,

Tout est dans le titre, après des années à abandonner systématiquement mes projets, j'aimerais partir sur de nouvelles bases en consacrant les premiers mois d'un nouveau projet à une partie pré-production.

Le truc c'est que je n'ai jamais rédigé de document de ce genre avant cela. J'aimerais faire l'impasse sur la partie documentant le gameplay car je sais parfaitement où je veux en venir de ce côté-là et j'estime qu'à part les stats des ennemis ou des armes, il n'y a rien d'autre à référencer. En fait j'aimerais surtout rédiger une grosse doc concernant la partie artistique et créative du jeu, histoire de ne pas perdre le nord.

Ca incluerait les différents types d'ennemis, les plans des niveaux et leur contenu, le look des personnages et des armes, l'histoire, les concepts (je sais pas dessiner mais ça à la limite c'est pas grave)... tout ça.
.
.
Par exemple, voilà le genre de chose que je pensais intégrer à mon document, une image avec des vignettes indiquant quelles genres de textures/meshes je pourrais utiliser sur telle ou telle surface/zone.

.
.
.
Comment est-ce que je peux/dois mettre au point une telle documentation ? Est-ce que vous pensez que ce que j'ai montré juste au-dessus est approprié ?

Dans un jeu video, il y a bcp d'elements qui fluctuent car la nature meme du projet fait que l'aspect "fun" est impossible a quantifier en amont.
Plutot que des specifications longues et laborieuses qui deviendront vite obsoletes, on prefere des methodes de travail iteratives, bcp plus efficaces pour ce type de produits. Le but d'une pre-production est de minimiser les risques, une fois les fondamentaux etablis, pas de tout documenter. Il faut documenter, mais de maniere utile, ce qui a besoin de l'etre, et mettre en place les elements qui permettront de piloter le suivi du projet.

Si tu lis l'anglais, je te recommande les articles de mon blog http://raphaelgervaise.com/index.php/blog/ qui donnent une introduction a la production de jeu video.

TL;DR ton truc.

Ouais pas besoin d'être autant précis que ce que tu as mis.
Tu peux, si tu veux, faire un GDD dans lequel tu détailles chaque zone de ton jeu et les textures dont tu auras besoins ainsi que les éléments de gameplay à associer et les entités.
Mais pas la peine de dire "la texture de la porte va à cet endroit précis sur cette porte"

Je te conseille quand même de coder en même temps sinon ça peut être un peu relou de trop séparer les tâches

Pour la partie artistique, il faut que tu te cherches des "références" (des images que tu crée où que tu chope à droite à gauche) qui correspondent à l'ambiance, le style visuel que tu veux pour ton jeu que ce soit au pour les niveaux, les ennemis, pnj... enfin bref tout ce qui constituera l'identité visuel de ton jeu. Pour cela tu peux te créer une (des) sorte de patchwork d'image intéressante (ce document porte un nom, mais impossible de m'en souvenir)

Par contre repérer les textures en détails n'est pas approprié pour le moment. Commence du plus large vers le plus précis. Donc identité visuel en premier, le détails des textures tu verras ça au moment de créer tes assets.

Pour ce qui est de l'impasse sur le gameplay, je dis "DANGER" car même si dans ta tête c'est clair, il est évident que tu peux pas envisager toutes les possibilités sans les poser sur le papier (ou alors ton projet est vraiment tout petit ou t'es plus intelligent que tout les devs pro).
Si tu pense pouvoir t'en passer, tu risque d'aller dans le mur car tu risque de commencer par des détails qui ne constitue pas ton coeur de gameplay ou devoir recommencer ton projet en partie car tu n'auras pas pensé à une fonctionnalité qui a d'avantage de conséquences que ce que tu pensais, ou t'embarquer dans des fonctionnalité qui sont beaucoup plus longues à développer que ce que tu peux te permettre, ou mettre en place des fonctionnalité qui ne fonctionnent pas bien ensemble...
Bref démarche hyper casse-gueule. Mais bon après c'est ton projet, c'est toi qui vois.

Si j'ai un seul conseil, fait une recherche sur ce qu'est un GDD. Il y a une tonne d'article à droite à gauche sur le sujet (en anglais pour la plupart, mais en même temps si tu lis pas l'anglais, t'es pas sorti de l'auberge)

Si je savais dessiner ça m'aiderait pas mal quand même.

J'ai jamais fait de GDD parce que le très peu de jeux que j'ai sortis ont été développés en quelques mois, sans l'aide de personne (à part pourt les phases de test) et sont assez courts (durée de vie d'environ 1h à 1h30).
D'habitude je m'occupe de la partie visuelle du jeu (level design, texturing et éclairages) à la volée, pendant le processus de développement, je fais ça au feeling, donc du coup, mes niveaux peuvent proposer de jolies scènes visuelles mais généralement sont assez foutraques au niveau du game design (beaucoup de bracktracking jamais indiqué, par exemple).

Pour le gameplay, je pensais sauter cette partie car depuis que j'ai commencé je ne fais que les mêmes types de jeux (des FPS old-school), et comme celui-ci ne serait pas bien différent, ça me semblait pas vraiment utile de me plonger dans une partie que je connais déjà.

Ca va, je m'en sors en anglais, c'est juste que je trouve le blog de Refeuh très décousu en fait, il y a énormément de trucs et je ne sais pas dans quel ordre commencer.
Je me demande si c'est vraiment pertinent de faire un GDD quand on est une équipe composée de une seule personne, du coup, parce que vu ce que je fais depuis trois ans (changer de projet sans arrêt), c'est pas un GDD qui me fera rester sur un même projet

Hello,

Le GDD n'est absolument pas obligatoire avant de commencer. Beaucoup de productions se lancent juste avec un Game Concept. Une version simplifiée qui présente dans les grandes lignes le jeu. Gameplay, graphisme, son, estimations, plateformes visées, etc.

Je connais quelques GD qui n'écrivent aucune ligne dans un document, mais communique directement avec leur équipe.

C'est une façon de faire, mais lorsqu'on est tout seul, il est très fortement recommandé de mettre TOUTES ces idées quelque part. J'essayerai de faire un article sur ces points sur mon blog, car beaucoup sous-estiment la puissance d'un Game design document.

Ça peut sauver des heures de travail et donc des € !

Bon après, personne ne le lit, mais c'est hyper important de garder une trace de tous ces choix pour plus tard.

Bon dev

-Benoit

Les GDD se touchent souvent la nouille.

GD : "Quoi, hein ? bah j'ai écrit une ligne là c'est bon j'ai fait mon taff"
PROG : "Ta ligne je peux la décliner en 50 variantes, dont chacune d'elle me prend un mois à coder".

Si t'es pas un gros fainéant, tu fais un doc de ton jeu.
Sinon tu t'en bat les couilles et tu laisses faire le prog hein.

Un GDD permet aussi de structurer ses idées, d'éviter de partir dans des impasses, de communiquer ses idées aux autres, etc
Il est plus facile de voir les problèmes en relisant son GDD. Il est bcp plus facile de recentrer un projet en modifiant son GDD plutôt que le code.