le combo game designer programmeur
vs
le game designer pur

Petite réflexion sur le game design…

On me faisais remarqué récemment à quel point c’est utile pour un game designer de savoir programmer. Le game designer crée les systèmes. Le programmeur les implémente. Évidemment, on peut tout de suite voir qu’un combo game designer programmeur est un excellent mélange parce qu’il enlève une étape de communication entre les deux personnes. Pas besoin pour le designer d’expliquer ses idées au programmeur. Il peut, en tant que programmeur, les coder directement.

Cependant, je pense qu’il y a malgré tout un avantage à avoir un game designer «pur» (c’est-à-dire qui n’agit pas comme programmeur dans l’équipe).

Le combo programmeur game designer permet peut-être d’éviter une étape de communication, mais je pense qu’il y a des situations où c’est utile d’avoir cette étape supplémentaire. Séparer le design et l’implémentation ça a ses avantages.

Lorsqu’il développe une idée, un game designer programmeur va penser à deux choses en même temps: il va penser à la complexité du système et penser aussi à comment il va implémenter le système. Mais justement, puisqu’il pense déjà à l’implémentation, il arrive souvent qu’une idée intéressante soit immédiatement rejetée parce qu’elle semble difficile à programmer.

Supposons une idée de design X qui serait absolument géniale. Malheureusement, cette idée géniale X est très complexe à programmer. Si l’idée géniale est apparue dans la tête d’un game designer programmeur, il va immédiatement voir les difficultés dans l’implémentation et tenter de trouver des raccourcis. Mais ce processus risque de détourner l’idée géniale en une idée beaucoup moins géniale. Ça n’arrive peut-être pas à tout coup, mais c’est une possibilité.

Par contre, si le designer arrive avec une idée qu’il a déjà décortiquée en systèmes, le programmeur va devoir prendre le temps de bien considérer l’idée, ne serait-ce que pas politesse envers son ami le designer. L’idée géniale a ainsi beaucoup plus de chance d’être considérée. Peut-être qu’elle ne sera pas intacte. Peut-être qu’elle sera transformé au fur et à mesure que le designer et le programmeur vont discuter des difficultés de l’implémentation. Mais au moins, si le designer tient bien à son idée, on peut être sûr que l’idée géniale ne sera pas travestie simplement parce qu’elle est difficile à programmer.

Au final, ces discussions entre le designer et le programmeur sont très bénéfiques. Pour le designer, cela permet de tester ses concepts en profondeur. Souvent, le programmeur va apporter des aspects au design qui avaient été oubliés. Parfois, les difficultés de programmation vont forcer le designer à trouver des idées encore meilleures pour aller chercher le noyau principale de l’idée et enlever tout le gras. Et pour le programmeur, cela enlève une certaine pression. Il peut se concentrer uniquement sur faire fonctionner le code (ce qui est déjà un défi en soi) et ne pas avoir à se soucier si les idées sont solides ou non. Parce que ça, si le game designer est bon, ça devrait être correct.

La question revient évidemment à savoir qui entre le programmeur et le designer a le plus de pouvoir dans l’équipe. Je ne veut surtout pas dire que le designer doit avoir tous les pouvoirs et que le programmeur doit seulement exécuter le travail! Il faut seulement trouver une balance qui fonctionne. Et ça, c’est probablement une question de goût que chaque équipe de travail doit trouver.