La traduction du document de conception élaborée par l’équipe de Conjure
est terminée. Le but de l’opération était de produire un document en
français et de bien saisir la nature du document et son utilité. En le
traduisant, je l’ai étudié en détail et j’ai pu y déceler quelques
lacunes que je tenterai d’améliorer plus tard. Le document est disponible
ici sous un format PDF. J’y référerai sous l’acronyme GDD pour « game
design document ».
Mais, à quoi sert-il? Ce document sert de support à la conception du jeu.
De cette façon, ceux qui devront travailler sur le jeu pourront toujours
s’y rapporter et ainsi travailler dans le même sens des autres
développeurs. Lorsque le projet est plus personnel et que le concept
d’équipe se limite à une personne, le GDD permet au développeur de
demeurer sur la bonne voix et d’atteindre ces objectifs plus
rapidement. Autrement dit, en mettant ces idées sur papier dès le
départ, le développeur sera plus enclin à implémenter ce qui a été décidé
au début du projet. Sans cela, il est facile d’avoir toutes sortes de «
bonnes » idées et de développer dans une direction puis dans une
autre et finalement, n’aboutir à rien. De plus, en élaborant la
conception tôt, on peut facilement évaluer si une idée tardive risque
d’entrer en conflit avec ce qui a déjà été établit. Par exemple : Si je
décide d’implanter un module d’invincibilité à mon vaisseau en fin de
développement, est-ce que cette nouvelle capacité rendra les combats trop
faciles? Est-ce que je devrai implémenter de nouvelles caractéristiques
aux ennemis? Si oui, peut-être serait-il préférable d’en faire un « cheat
»?
Il est donc très important de bien penser la conception de son projet et
de tout mettre par écrit. Ainsi, les risques de s’écarter et de perte de
temps sont diminués. Aussi, les idées que l’on a déjà eu ne sont plus
oubliées. C’est l’erreur que j’ai commise. Cela fait longtemps que ce
projet me trotte dans la tête, j’ai une bonne idée de la mécanique du jeu
mais en ce qui concerne l’histoire, les ennemis, les personnages, etc.
C’est plutôt vague. J’ai eu des idées que j’ai notées par-ci par-là, mais
je ne saurais les retrouver. Alors quand je pense à mon jeu, il m’arrive
parfois d’avoir 2 ou 3 fois la même idée géniale. Si j’avais élaboré un
bon GDD, je n’aurais probablement pas ces problèmes. Et je me serais
probablement aperçu que certaines idées ne tenaient pas la route et que
d’autres méritaient une attention plus approfondie. J’aurais pu aussi
noter les musiques, les concepts de sprites, etc. sur le GDD au lieu de
noter tout ça sur des post-it qui sont perdus depuis belle lurette. En
fait, il s’agit d’organiser le travail afin d’éviter toute forme de perte
de temps et de procrastination possible. Les problèmes techniques sont
déjà pénibles en soit, ça ne sert à rien d’en rajouter avec des concepts
qui n’existent que dans ma tête. C’est la paresse qui m’a mené dans cette
situation de cafouillis. Car la tâche que représente l’élaboration du GDD
est énorme.
Certes, élaborer le GDD n’est pas facile. Si l’on en croit l’équipe de
Conjure, il faudrait y mettre absolument tout ce qui concerne le jeu qui
sera développé, avec le plus de détails possible. Je ne suis pas d’accord
avec cette approche. Ils ont une vision trop stricte du GDD, à mon avis
il faut que le jeu puisse évoluer. Évidemment, il est préférable de
décider dès le début du type de jeu que l’on veut, dès règles qui
régiront l’univers du jeu, des mécanismes de jouabilité, etc. Changer la
moindre de ces petites choses en cours de développement risque d’avoir un
impact important sur le reste des éléments constituants le jeu. Il faut
prendre le temps de bien y penser pour ne pas regretter ses choix plus
tard. Car si on efface et on recommence, c’est beaucoup de temps de
perdu. Mais en même temps, il faut rester flexible. C’est au niveau
conceptuel, justement, que l’on peut se laisser une plus grande marge de
manœuvre. Une fois les règles et les mécanismes gérant le jeu bien
établi, on peut concevoir le jeu avec un minimum de niveaux, quelques
ennemis, une histoire écrite dans les grandes lignes, etc. Avec le temps,
d’autres idées viendront et il sera facile de les intégrées en autant que
l’on respecte les règles établies. Tout prévoir à l’avance est
pratiquement infaisable. À moins de conserver les nouvelles idées pour
une éventuelle suite.
Et malgré que le GDD de Conjure me semble complet, j’ai trouvé que son
organisation restait obscure. Le lecteur peut facilement s’y perdre, les
mêmes éléments se retrouvent dans différentes catégories, par exemple on
peut retrouver les personnages autant dans la catégorie histoire, que
dans l’art ou la jouabilité. Peut être qu’un découpage en faisant de
personnage une catégorie décrivant tout les points mentionnés serait plus
lisible? J’ai aussi l’impression que le document pourrait avoir une ou
deux sections de plus, tel que les obstacles à surmonter, les conflits en
jeu, etc. Ou encore, inclure des modèles de conception de personnages, de
niveaux, de ressources, etc. Les possibilités sont nombreuses. Justement,
le danger est de rendre le document trop lourd. Trop lourd à produire, ce
qui fait que le jeu sera trop difficile à développer et par conséquent,
il ne verra probablement jamais la lumière au bout du tunnel. Toutefois,
il est plus facile de ne pas implémenter une idée qui a été pensée
qu’essayer d’ajouter une idée dont on n’a pas réfléchie aux conséquences
qu’elle aurait sur le reste du jeu. Si une idée est rejetée, on n’a qu’à
la noter comme étant rejetée et expliquer la raison.
En fin de compte, pour un développeur seul, il faut apprendre à gérer son
temps. En consacrer trop à la conception, c’est en consacrer moins à la
production. Mais une idée notée, est une idée qui n’est pas oubliée.
est terminée. Le but de l’opération était de produire un document en
français et de bien saisir la nature du document et son utilité. En le
traduisant, je l’ai étudié en détail et j’ai pu y déceler quelques
lacunes que je tenterai d’améliorer plus tard. Le document est disponible
ici sous un format PDF. J’y référerai sous l’acronyme GDD pour « game
design document ».
Mais, à quoi sert-il? Ce document sert de support à la conception du jeu.
De cette façon, ceux qui devront travailler sur le jeu pourront toujours
s’y rapporter et ainsi travailler dans le même sens des autres
développeurs. Lorsque le projet est plus personnel et que le concept
d’équipe se limite à une personne, le GDD permet au développeur de
demeurer sur la bonne voix et d’atteindre ces objectifs plus
rapidement. Autrement dit, en mettant ces idées sur papier dès le
départ, le développeur sera plus enclin à implémenter ce qui a été décidé
au début du projet. Sans cela, il est facile d’avoir toutes sortes de «
bonnes » idées et de développer dans une direction puis dans une
autre et finalement, n’aboutir à rien. De plus, en élaborant la
conception tôt, on peut facilement évaluer si une idée tardive risque
d’entrer en conflit avec ce qui a déjà été établit. Par exemple : Si je
décide d’implanter un module d’invincibilité à mon vaisseau en fin de
développement, est-ce que cette nouvelle capacité rendra les combats trop
faciles? Est-ce que je devrai implémenter de nouvelles caractéristiques
aux ennemis? Si oui, peut-être serait-il préférable d’en faire un « cheat
»?
Il est donc très important de bien penser la conception de son projet et
de tout mettre par écrit. Ainsi, les risques de s’écarter et de perte de
temps sont diminués. Aussi, les idées que l’on a déjà eu ne sont plus
oubliées. C’est l’erreur que j’ai commise. Cela fait longtemps que ce
projet me trotte dans la tête, j’ai une bonne idée de la mécanique du jeu
mais en ce qui concerne l’histoire, les ennemis, les personnages, etc.
C’est plutôt vague. J’ai eu des idées que j’ai notées par-ci par-là, mais
je ne saurais les retrouver. Alors quand je pense à mon jeu, il m’arrive
parfois d’avoir 2 ou 3 fois la même idée géniale. Si j’avais élaboré un
bon GDD, je n’aurais probablement pas ces problèmes. Et je me serais
probablement aperçu que certaines idées ne tenaient pas la route et que
d’autres méritaient une attention plus approfondie. J’aurais pu aussi
noter les musiques, les concepts de sprites, etc. sur le GDD au lieu de
noter tout ça sur des post-it qui sont perdus depuis belle lurette. En
fait, il s’agit d’organiser le travail afin d’éviter toute forme de perte
de temps et de procrastination possible. Les problèmes techniques sont
déjà pénibles en soit, ça ne sert à rien d’en rajouter avec des concepts
qui n’existent que dans ma tête. C’est la paresse qui m’a mené dans cette
situation de cafouillis. Car la tâche que représente l’élaboration du GDD
est énorme.
Certes, élaborer le GDD n’est pas facile. Si l’on en croit l’équipe de
Conjure, il faudrait y mettre absolument tout ce qui concerne le jeu qui
sera développé, avec le plus de détails possible. Je ne suis pas d’accord
avec cette approche. Ils ont une vision trop stricte du GDD, à mon avis
il faut que le jeu puisse évoluer. Évidemment, il est préférable de
décider dès le début du type de jeu que l’on veut, dès règles qui
régiront l’univers du jeu, des mécanismes de jouabilité, etc. Changer la
moindre de ces petites choses en cours de développement risque d’avoir un
impact important sur le reste des éléments constituants le jeu. Il faut
prendre le temps de bien y penser pour ne pas regretter ses choix plus
tard. Car si on efface et on recommence, c’est beaucoup de temps de
perdu. Mais en même temps, il faut rester flexible. C’est au niveau
conceptuel, justement, que l’on peut se laisser une plus grande marge de
manœuvre. Une fois les règles et les mécanismes gérant le jeu bien
établi, on peut concevoir le jeu avec un minimum de niveaux, quelques
ennemis, une histoire écrite dans les grandes lignes, etc. Avec le temps,
d’autres idées viendront et il sera facile de les intégrées en autant que
l’on respecte les règles établies. Tout prévoir à l’avance est
pratiquement infaisable. À moins de conserver les nouvelles idées pour
une éventuelle suite.
Et malgré que le GDD de Conjure me semble complet, j’ai trouvé que son
organisation restait obscure. Le lecteur peut facilement s’y perdre, les
mêmes éléments se retrouvent dans différentes catégories, par exemple on
peut retrouver les personnages autant dans la catégorie histoire, que
dans l’art ou la jouabilité. Peut être qu’un découpage en faisant de
personnage une catégorie décrivant tout les points mentionnés serait plus
lisible? J’ai aussi l’impression que le document pourrait avoir une ou
deux sections de plus, tel que les obstacles à surmonter, les conflits en
jeu, etc. Ou encore, inclure des modèles de conception de personnages, de
niveaux, de ressources, etc. Les possibilités sont nombreuses. Justement,
le danger est de rendre le document trop lourd. Trop lourd à produire, ce
qui fait que le jeu sera trop difficile à développer et par conséquent,
il ne verra probablement jamais la lumière au bout du tunnel. Toutefois,
il est plus facile de ne pas implémenter une idée qui a été pensée
qu’essayer d’ajouter une idée dont on n’a pas réfléchie aux conséquences
qu’elle aurait sur le reste du jeu. Si une idée est rejetée, on n’a qu’à
la noter comme étant rejetée et expliquer la raison.
En fin de compte, pour un développeur seul, il faut apprendre à gérer son
temps. En consacrer trop à la conception, c’est en consacrer moins à la
production. Mais une idée notée, est une idée qui n’est pas oubliée.
Commentaires
Enregistrer un commentaire