16-05-2013, 11:53 AM
Je me suis surement mal exprimé.
Pourtant ce que je "reproche" à la discipline du code c'est que quand je bosse en tant que game designer avec un programmeur, lui il veut juste une liste définitive de ce que doit faire chaque élément à un instant T, une place P alors que je vais plutôt lui donner ces informations en expliquant aussi les relations entre tous les éléments et pourquoi l'un est issu ou interagit avec l'autre mais cela pose soucis lorsque le projet conçu est en mode prototype attendant des améliorations et donc des changement de code. C'est d'ailleurs aussi à ça que sert un proto il me semble.
C'est comme la manie du codeur à pas faire ce qui est demandé :
Tu lui donne par exemple une interface d'une partie du jeu à développer où tu précise bien pourquoi il faut que les choses soient de telle façon (cad l'impact sur le ressenti du joueur et le jeu et les réaction que cela doit engendrer).
1er retour : en général il revient avec un truc qui fait pas du tout ce que tu voulais > En fait après maintes discussion tu te rends compte qu'il n'avait pas tout lu sur le GD ... Et oui si tu explique les choses .. Et ben il s'en fiche le bougre. Donc tu lui ré-explique tout par skype ce qui te rappelle que tu as écrit ce GD juste pour ta pomme.
2eme retour : Là ça commence à ressembler à ce que tu as demandé mais pourtant c'est différent. Le résultat fonctionnel est là mais ce n'est pas ce qui est demandé.
En gros le codeur simplifie au maximum l'idée en effaçant tout ce qui te paraissait primordial pour l'impact attendu parce que apparemment, lui, il voit pas ça.
3eme retour : Le programmeur vous dit qu'on ne peut pas faire ça. Évidemment, vous ne comprenez pas parce que vous avez déjà vu la même chose. Vous partez alors faire des recherches parce que c'est important pour le jeu et vous découvrez que c'est possible. Vous présentez la solution et là vous avez 2 réponses possibles : "En fait, je sais pas faire" ou "C'est trop la galère à faire.".
4eme retour : Enfin on a réussi après 4 sessions de taf a faire ce qu'il fallait apparaissant au bon endroit et au bon moment avec tout agissant quand il faut.
Dommage que ça recommence presque à chaque fois
Je pense que c'est aussi pour ça que beaucoup de GD sont très très souvent des programmeurs. Ils sont sur la même longueur d'onde.
Ne m'en veuillez pas trop pour ce petit coup de gueule, j'ai pas envie de me fâcher avec tout les développeurs . Et j'ai peut-être un peu dévié de la discussion.
Si je devais faire une allégorie du codage, pour moi, c'est comme si l'aboutissement de la réalisation du code d'un programme était un couloir ultra-serré où mon corps pouvait à peine se faufiler et qu'il faudrait arriver à atteindre l'autre bout de ce couloir. Oui c'est pas très engageant et contraignant.
Malgré tout je suis sur que les programmeurs éprouvent beaucoup de liberté à coder mais je ne la ressens pas. C'est plutôt de la frustration par la limitation.
Pourtant ce que je "reproche" à la discipline du code c'est que quand je bosse en tant que game designer avec un programmeur, lui il veut juste une liste définitive de ce que doit faire chaque élément à un instant T, une place P alors que je vais plutôt lui donner ces informations en expliquant aussi les relations entre tous les éléments et pourquoi l'un est issu ou interagit avec l'autre mais cela pose soucis lorsque le projet conçu est en mode prototype attendant des améliorations et donc des changement de code. C'est d'ailleurs aussi à ça que sert un proto il me semble.
C'est comme la manie du codeur à pas faire ce qui est demandé :
Tu lui donne par exemple une interface d'une partie du jeu à développer où tu précise bien pourquoi il faut que les choses soient de telle façon (cad l'impact sur le ressenti du joueur et le jeu et les réaction que cela doit engendrer).
1er retour : en général il revient avec un truc qui fait pas du tout ce que tu voulais > En fait après maintes discussion tu te rends compte qu'il n'avait pas tout lu sur le GD ... Et oui si tu explique les choses .. Et ben il s'en fiche le bougre. Donc tu lui ré-explique tout par skype ce qui te rappelle que tu as écrit ce GD juste pour ta pomme.
2eme retour : Là ça commence à ressembler à ce que tu as demandé mais pourtant c'est différent. Le résultat fonctionnel est là mais ce n'est pas ce qui est demandé.
En gros le codeur simplifie au maximum l'idée en effaçant tout ce qui te paraissait primordial pour l'impact attendu parce que apparemment, lui, il voit pas ça.
3eme retour : Le programmeur vous dit qu'on ne peut pas faire ça. Évidemment, vous ne comprenez pas parce que vous avez déjà vu la même chose. Vous partez alors faire des recherches parce que c'est important pour le jeu et vous découvrez que c'est possible. Vous présentez la solution et là vous avez 2 réponses possibles : "En fait, je sais pas faire" ou "C'est trop la galère à faire.".
4eme retour : Enfin on a réussi après 4 sessions de taf a faire ce qu'il fallait apparaissant au bon endroit et au bon moment avec tout agissant quand il faut.
Dommage que ça recommence presque à chaque fois
Je pense que c'est aussi pour ça que beaucoup de GD sont très très souvent des programmeurs. Ils sont sur la même longueur d'onde.
Ne m'en veuillez pas trop pour ce petit coup de gueule, j'ai pas envie de me fâcher avec tout les développeurs . Et j'ai peut-être un peu dévié de la discussion.
Si je devais faire une allégorie du codage, pour moi, c'est comme si l'aboutissement de la réalisation du code d'un programme était un couloir ultra-serré où mon corps pouvait à peine se faufiler et qu'il faudrait arriver à atteindre l'autre bout de ce couloir. Oui c'est pas très engageant et contraignant.
Malgré tout je suis sur que les programmeurs éprouvent beaucoup de liberté à coder mais je ne la ressens pas. C'est plutôt de la frustration par la limitation.