Discussion :

[yahiko]

Bonjour à tous,

Une petite discussion / débat sur un sujet qui me trotte dans la tête ces derniers temps au sujet d'un élément important d'un jeu vidéo, à savoir son game design et les qualités et compétences à avoir pour être un bon Game Designer.

Un Game Designer se doit-il de savoir programmer auquel cas un parcours de développeur est-il indispensable à un GD ?
Ou bien un GD peut-il se contenter d'être un bon rédacteur de documents Word ?
Un GD au sein d'une équipe indé de petite taille (plénoasme) est-il nécessairement voué à être le leader ? Et pourquoi ?

J'ai quelques autres de réflexions autour de ce sujet, mais je pense que c'est déjà pas mal pour lancer le débat.

Au plaisir de vous lire.

[CodeurPlusPlus]

Je dirais :

petite équipe => pas besoin de game designer

grosse équipe => game designer indispensable

Premières qualités d'un game designer :
- très bonne connaissance de l'histoire du jeu vidéo ;
- très bonne connaissance du marché actuel du jeu vidéo ;
- a exercé au moins un métier créatif avant ;
- sait défendre ses idées.

Mais, en fait, je n'y connais rien du tout donc je dis ça pour faire avancer la discussion vu que le sujet m'intéresse.

[yahiko]

petite équipe => pas besoin de game designer

grosse équipe => game designer indispensable

Disons que même dans une petite équipe, il y a forcément une personne qui a un moment donné endosse les habits de game designer, même s'il l'ignore ! ^^
A l'extrême, un dev tout seul dans son garage est à la fois le programmeur et le GD. Il a deux rôles de mon point de vue.
Je dirais donc que que ce soit dans une grande et une petite équipe, on a besoin d'un game designer tout simplement parce qu'on a besoin à un moment ou à un autre de définir le gameplay, à moins de faire un film et pas un jeu vidéo.
Selon la complexité du gameplay, je pense que le game designer peut soit être un rôle dilué au sein de l'équipe dans le cas de jeux simples ou déjà préétablis (pas besoin de GD pour faire un remake de Tetris, tout le concept et les règles ont déjà été pondues.

J'aurai donc tendance à dire qu'un GD n'est pas nécessaire si on veut faire un remake d'un concept déjà existant. Dans les autres cas, je pense que le GD est nécessaire ne serait-ce que sous la forme d'un rôle partagé par plusieurs personnes. Plus le jeu devient complexe en terme de gameplay, et plus le GD est indispensable imo. Je pense qu'un jeu original de stratégie, de wargame ou de gestion a besoin d'un véritable GD dédié, quel que soit la taille de l'équipe, alors que pour un film interactif, même pour un titre AAA, la nécessité d'un GD dédié n'est pas forcément évidente.

Premières qualités d'un game designer :
- très bonne connaissance de l'histoire du jeu vidéo ;
- très bonne connaissance du marché actuel du jeu vidéo ;
- a exercé au moins un métier créatif avant ;
- sait défendre ses idées.

Mais, en fait, je n'y connais rien du tout donc je dis ça pour faire avancer la discussion vu que le sujet m'intéresse.

Tu ne penses pas qu'un GD doit savoir programmer au prélable ?
Parce que je pense que cela peut aider le GD à se rendre compte de la complexité de certaines de ses exigences, pouvant être coûteuse en terme de temps de développement.

[LittleWhite]

Bonjour,

Pour moi, le GD est important, même dans les petites équipes. Même s'il risque d'endosser plusieurs rôle (chef de projet, intégrateur de ressources, community manager...), il reste utile. (Hors des projets de copies d'un jeu existant.)
En effet, le GD va devoir faire en sorte que le jeu soit fun (en demandant des ajouts de graphismes ou de fonctionnalités). Qu'il soit jouable, fun et prenant. Sans ça, je pense, il n'y aura pas de succès.
Aussi, il se doit d'équilibrer le jeu et tout ça. En théorie, le graphiste est trop occupé, et le programmeur aussi. En plus, le programmeur connait tous les points faibles de ces algos/de son code et donc sa façon de jouer est complètement biaisé.

Donc, oui, je pense que le GD est important, même dans une GameJam, pour avoir un jeu "fun".

Il se doit savoir programmer. En effet, il doit tester des mécaniques rapidement, ou même savoir modifier les valeurs "laissées" par la programmeur pour changer des variables, des attributs liées au gameplay. Il se doit de rendre le jeu "bon" (car le programmeur lui, il fait principalement le jeu, mais pas souvent bon (désolé les amis , ou alors je parle de moi )).

[Kannagi]

. Il se doit de rendre le jeu "bon" (car le programmeur lui, il fait principalement le jeu, mais pas souvent bon (désolé les amis , ou alors je parle de moi )).

Ah ah je suis assez d'accord avec ça , vu que je trouve souvent mes jeux mal foutu en terme de gameplay

Un Game Designer se doit-il de savoir programmer auquel cas un parcours de développeur est-il indispensable à un GD ?
Ou bien un GD peut-il se contenter d'être un bon rédacteur de documents Word ?

Je pense que quelque notion de programmation pour le GD est indispensable pour pas qu'il propose ds idée trop farfelu niveau programmation ,non pour ma part un GD ne peut pas se contenté de ne faire que du documents Word , sa participation doit etre plus importante.

Un GD au sein d'une équipe indé de petite taille (plénoasme) est-il nécessairement voué à être le leader ? Et pourquoi ?

ça vient d'une expérience perso ? je vois pas pourquoi le GD devrait être le leader ou qu'il le deviendrait , sur une petite équipe je pense que cela doit être le programmeur qui doit être le leader c'est lui qui aura la meilleur vu de l'ensemble du projet et qu'il devra assemblé tout cela.

[Iradrille]

Premières qualités d'un game designer :
- très bonne connaissance de l'histoire du jeu vidéo ;
- très bonne connaissance du marché actuel du jeu vidéo ;
- a exercé au moins un métier créatif avant ;
- sait défendre ses idées.

Je dirai la même chose.
Çà doit être un joueur avant tout.
Qui de mieux placé qu'un joueur pour se mettre dans la peau des joueurs et (essayer de) savoir ce qui plait / plait pas ?

Mais, en fait, je n'y connais rien du tout donc je dis ça pour faire avancer la discussion vu que le sujet m'intéresse.

Pareil *_*

[yahiko]

ça vient d'une expérience perso ? je vois pas pourquoi le GD devrait être le leader ou qu'il le deviendrait , sur une petite équipe je pense que cela doit être le programmeur qui doit être le leader c'est lui qui aura la meilleur vu de l'ensemble du projet et qu'il devra assemblé tout cela.

De ce que j'ai pu expérimenter dans mes tribulations vidéoludiques, il se trouve que le GD est souvent celui qui vient avec le concept de départ pour le projet.
Mais souvent il n'y connait rien ou pas grand chose en programmation. Mais comme il a la connaissance de son concept (normal) et des tenants et des aboutissants, je ne vois pas comment le programmeur pourrait être le leader à sa place, même si dans un "petit" projet, le gros du job en terme de temps, c'est tout de même le programmeur qui doit se le coltiner. Ça c'est aussi une source de frictions et d'incompréhensions entre le GD et le programmeur je pense.

Le GD une fois son concept pondu (et souvent vaguement, pour les amateurs j'entends) refourgue le bébé au programmeur qui a la difficile tâche de décrypter les attentes du GD et de pédaler pour faire avancer le projet, pendant que le GD a plutôt une posture d'inspecteur des travaux finis.

Je pense que c'est une cause importante des ruptures dans les projets indés.

[stopviolence]

Je fais actuellement l'expérience de coder à l'aveuglette sans avoir défini un CDC et bien j'ai fait une belle connerie et mon projet a de fortes chances de finir au pire à la poubelle au mieux à l'état de demomake merdique avec 1% de code réutilisable.

Je pensais que c'était plus efficace de raisonner comme ça: on part d'un programme qui marche, et on rajoute des trucs uniquement si ça colle facilement avec ce qui est déjà programmé, comme ça on avance plus vite... hé bien non grave erreur en fait car les idées qui viennent au fur et à mesure n'ont pas été prévues par la structure de base du programme et on perd un max de temps à faire des restructurations.

Le CDC sert à définir les fondations même du programme, sans lui on part avec des fondations foireuses qui n'ont rien prévu et donc vont tout bloquer.

Bon mais je ne me jette pas la pierre à moi-même car il faut dire que je suis pas influencé en bien par les collègues, la grosse erreur chez les indé c'est justement de bâcler l'étape de conception trop souvent réduite à deux idées nulles piquées sur des jeux vus et revus, par pure flemme de fournir un effort d'imagination et de rédiger un cdc qu'on va réduire à trois mails.

Là où je peux me jeter la pierre c'est d'attendre un CDC de la part du client alors que rien ne l'oblige à le faire, ça n'est pas forcément son boulot, peut-être qu'il a pas le temps, pas l'envie, ou qu'il est pas compétent pour ça.

Donc à partir des idées pauvres et mauvaises du client, il faut faire un effort d'imagination pour édifier ça en CDC qui propose des idées mieux, et tant qu'à faire c'est mieux que ce sale boulot soit fait par le lead dev car c'est lui qui sait ce qui est faisable.

Post-Scriptum j'ai oublié un truc important :

Ah ah je suis assez d'accord avec ça , vu que je trouve souvent mes jeux mal foutu en terme de gameplay

J'allais dire exactement la même chose.

Le fait d'avoir des notions de programmation ne fait pas spécialement un bon designer.

Exemples: un développeur spécialiste de la gestion de bdd n'est pas sensé s'y connaitre en gameplay. Plus subtil encore, un boss de la programmation graphique (donc susceptible d'être recruté par un studio de jv) peut tout à fait être parfaitement incompétent en programmation de gameplay.

Bref plutôt que des codeurs qui n'ont aucune compétence en conception de gameplay, il vaut mieux encore un designer qui ne sait pas coder mais qui sait trouver les idées pour concevoir un gameplay addictif.

[Dabou Master]

Hum c'est un sujet super épineux ça ^^.

Le Game Designer est une profession beaucoup trop jeune et qui sera toujours très malléable, surtout dans une petite équipe (car bien entendu plus l'équipe est petite plus tout le monde est supposé savoir tout faire), chacun se fait son idée de ce qu'il est supposé savoir faire et de quel est son rôle réel.
N'ayant aucune idée des réelles compétences d'un game designer dans un vrai gros studio (je ne sais pas s'ils sont en équipe ou pas du tout) je n'essaierai même pas de dire ce qu'il est supposé savoir faire. Par contre je renommerai le game designer en "détenteur du projet" dans notre cas de petits amateurs qui se réunissent autour d'un feu virtuel en espérant un jour trouver les bons compagnons d'aventure ^^. Selon moi ce qu'est supposé savoir faire un "ddp" s'il n'est là qu'en tant que tel :

- avoir effectivement, comme déjà stipulé, une très grande culture du Jeu Vidéo sur une longue durée et sans limite de domaines (pas de spécialisation en FPS ou RTS ou peu importe, quel que soit le type de jeu qu'il veut créer).
- avoir des connaissances en programmation, pas énormément, quelques notions d'algorithmique, comprendre comment un code est fait, même simple. Son expérience des jeux vidéo le guidera pour savoir ce qui est possible pour un gros studio et un petit.
- avoir des connaissances en graphisme, il aura la charge de la direction artistique (il connait les mécaniques de jeu qu'il veut, il doit avoir en tête à quoi doit ressembler son jeu sinon ça ne collera jamais aussi bien que si tout vient de lui).
- avoir des notions en termes de composition sonore/bruitages. Il doit avoir en tête tous les aspects que le joueur percevra, ça comprend l'ambiance sonore, les musiques et les bruits générés par les interactions dans SON monde.
- être très souple, ses connaissances même minces en graphismes et programmation (et composition) lui permettront d'accorder les besoins de son jeu avec les capacités de ses acolytes. Si quelque chose n'est pas possible il devra réussir à s'entendre avec son graphiste/programmeur/compositeur ce qui est possible et ce qui ne l'est pas.
- le plus dur maintenant, c'est lui qui devra incarner "l'expérience" de l'équipe. C'est-à-dire qu'on suppose que c'est une personne seule qui réunit son équipe et doit huiler les rouages durant tout le projet pour que tout puisse avancer comme il faut. Il faut donc qu'il soit capable de diriger de façon assez stricte son équipe. Il doit savoir donner de petites missions (pour simplifier la cohésion plutôt que de donner un seul gros projet à chacun et "démerdez-vous") aux membres de son équipe, demander ce qui doit être fait à peu près à quel moment etc. tout en restant souple et en pouvant adapter les échéances (car on sait très bien qu'il faut constamment modifier l'emploi du temps dans ce domaine ...). Il est le point névralgique, le cerveau, tous les autres sont des organes qui font leur boulot autour de cet élément principal.
- éventuellement il devra aussi s'occuper de tout ce qui est financement/marketing, à moins d'avoir la chance d'avoir un acolyte pour s'occuper de ça aussi ^^ (dans un sujet relativement ancien on avait déjà émis l'intérêt concret d'avoir un commercial compétent même dans la plus insignifiante des équipes). Sinon il devra savoir diriger un petit peu son commercial, lui donner suffisamment de comptes rendus de la progression du projet pour que le commercial puisse faire son boulot sans trop s'avancer (ou l'inverse).

Par contre je contredis juste un point, c'est connaître le marché actuel. Disons que là on est bien sur une petite équipe et je trouve ça crétin (je ne parle pas de celui qui a exprimé l'idée mais de l'idée en elle-même) d'essayer de suivre la tendance car c'est bousiller ses chances. D'un parce qu'on sera noyé dans la foule de projets qui voudront leur part du gâteau après le succès phénoménal d'un jeu (ex : terraria a très bien suivi minecraft en en étant un peu inspiré tout de même, d'autres ont suivi avec quasiment tous un succès décroissant, et la chance y est pour beaucoup quoi qu'on en dise). De deux, parce qu'il y a les laissés pour compte, il y en a qui attendent toujours cette foutue licence de jeu de combat avec des gars qui se transforment en animaux, pourquoi faire un minecraft-like noyé alors qu'on peut viser une petite communauté désespérée ? (ex : pas mal de "clones" plus ou moins ratés de Dungeon Keeper ou Theme Hospital, ils sont pour certains merdiques mais ils ont réussi à faire parler d'eux, ce qui est un succès en soi). Et de trois, parce que faire comme les gros studios c'est pas forcément intelligent et c'est assez prétentieux, et copier un indépendant qui a eu de la chance c'est pas forcément une bonne idée non plus. Ce qui a marché au final c'est un style plus ou moins récent qui sort d'un coup de l'ombre et a un succès viral même si le concept commençait déjà à prendre la poussière. Tout ça pour dire qu'on prend limite moins de risques à viser une petite communauté solide et à tenter de sortir du lot, qu'à tenter d'atteindre une part du succès d'un jeu qui a réussi à sortir du lot. Après effectivement pour savoir ce qui a tendance à manquer dans la bibliothèque vidéoludique actuelle il faut connaître le marché ^^, je viens de bousiller mon argument mais au moins j'ai précisé cet aspect qui me semble important.

Voilà mon point de vue, comme ce surhomme qui mériterait largement d'avoir sa place sans qu'on lui demande de mettre la main à la pâte (car déjà super occupé avec tout ce qu'il a à faire oO) est plus que rare voire inexistant, il vaut mieux se contenter de diluer le GD dans toute l'équipe. C'est très simple, certains voudront apporter leur pierre à l'édifice, d'autres préfèrent juste exploiter leurs compétences sans qu'on les embête avec ce qu'ils pensent du jeu (oui oui ça existe ^^). Il faut juste rester à l'écoute des autres et beaucoup discuter les idées de chacun mais pas forcément dire amen à tout non plus. Savoir gérer tout seul un game design ça me paraît insurmontable personnellement, je peux imaginer des dizaines de jeux différents dans leur globalité et qui seraient même très probablement réalisables (oui probablement parce que j'ai des idées peut-être un poil trop ambitieuses en général ^^) mais dès qu'il faut rentrer dans le détail (combien de points de vie pour un hack & slash ? Comment tabler l'échelle des dégâts ? Etc.) et surtout les chiffres d'un jeu, là c'est : .

Après faut savoir identifier celui qui veut faire un jeu qui ressemble à un autre. Un jeu ressemblera toujours à un autre mais il y a toujours ce type qui a joué à trente jeux dans sa vie (on est d'accord que c'est un chiffre ridicule ^^) pendant des centaines voire des milliers d'heures, tous (les jeux) sont du même type et il veut faire un jeu exactement dans ce style. Il faut faire attention à ce genre de fan d'un type de jeu qui pourrait éventuellement pourrir le game design dans sa globalité. Identifier les bonnes idées n'est pas évident ^^.

Pas sûr que je sois pas un peu parti en hors sujet mais je crois qu'on ne peut pas réellement traiter ta question. Le résultat est forcément subjectif car même Peter Molyneux (qui a eu sa période de gloire quand même) ne pourrait pas réellement te dire ce qui ferait un bon game designer, la preuve en est qu'il a lui-même fini par s'écrouler.

Et sinon je vais un peu rebondir par rapport à ce qu'a dit kannagi (en étant partiellement d'accord avec lui) et la discussion récente que j'ai eue avec N_I_C_S sur son projet, je pense que dans l'idéal le chef ne devrait être ni un graphiste, ni un programmeur, ni un compositeur. Tout simplement parce que trouver dans ces trois catégories à chaque fois un gars qui voudra transcender ses limites techniques est impossible. Un chef qui n'aura de pied dans aucune des difficultés techniques pourra toujours encourager les autres à se dépasser et à obtenir un jeu de meilleure qualité que si tout le monde reste basé sur ses acquis du moment. On pourrait dire que le risque est d'avoir un jeu qui n'aboutit pas certes, mais il ne faut jamais oublier la souplesse dont doit savoir faire preuve le chef, voir grand mais savoir voir grand à son échelle des possibilités .

[Bousk]

Le GD sera plus enclin à être chef de projet parce qu'il a la vision globale du but à atteindre.
Sa compétence en Word sera amha moins importante que son leadership/charisme : faut (pouvoir et avoir envie de) le suivre!

Dans une petite équipe, s'il programme un peu (enfin scripte plutôt, ça suffira), il pourra mettre la main à la pate et tester des trucs directement. Ca permet aux (vrais) programmeurs de se concentrer sur autre chose (après lui avoir fourni une API Python qui permet de bidouiller GUI, gameplay etc..). Dans la limite du possible.
Dans une plus grande équipe, selon ce qu'il veut tester, la tech en place etc, ce sera possible ou pas. Mais programmer n'est pas nécessaire.

En général il aura une "bonne connaissance vidéoludique" globalement, en gros c'était un joueur, et l'est encore souvent plus que la moyenne.
Il veut créer des jeux, mais faut pas se leurrer : aujourd'hui la création pure n'existe quasiment plus, on crée que des clones de X et/ou Y, plus ou moins bien masqués.
Et surtout c'est pas juste "un type avec des idées" : les idées c'est comme les trous du cul, tout le monde en a. Et ça suffit plus.
Surtout que maintenant il y a des écoles qui fournissent des formations de GD (bien que je ne trouve pas ça bien), mais de plus en plus ils se spécialisent : Economic designer (GD spécialisé F2P et monnaitisation), Quest Designer, Narrative designer, ...

[stopviolence]

aujourd'hui la création pure n'existe quasiment plus, on crée que des clones de X et/ou Y, plus ou moins bien masqués.

Ca a toujours été vrai, déjà dans les années 70 ça s'étripait pour la propriété intellectuelle des clones du pong. La repompe est indissociable du game-design, parce que trouver des idées codables c'est un pari pas évident, on préfère repomper des trucs qui marchent.

Et les franchises à succès d'apparence originale, en fait souvent ils mélangeaient deux ou trois jeux à succès, c'était de la repompe habilement dissimulée.

[LeGreg]

Un Game Designer se doit-il de savoir programmer auquel cas un parcours de développeur est-il indispensable à un GD ?
Ou bien un GD peut-il se contenter d'être un bon rédacteur de documents Word ?
Un GD au sein d'une équipe indé de petite taille (plénoasme) est-il nécessairement voué à être le leader ? Et pourquoi ?.

La différence entre un bon chasseur et un mauvais chasseur c'est : ""..

Bon dans l'industrie : non les game designers ne savent pas forcément programmer. Sinon ils auraient le titre de programmeur.

Dans une petite équipe il y aura forcément des gens qui auront plusieurs casquettes : audio-designer/chauffeur, programmeur/livreur de pizza.
Dans les grosses structures c'est généralement plus rare.

Certains game designers ont commencé comme programmeurs pour de simples raisons historiques. Parce qu'ils ont commencé dans une petite équipe il fallait qu'ils endossent le rôle de programmeur ET de game designer, mais plus tard ils ont préférer se focaliser sur le game design (on peut penser à Peter Molyneux ou Will Wright qui ont programmé sur leurs premiers projets). D'autres ont commencé à faire des jeux dans un tout autre domaine comme Warren Spector qui a fait ses débuts dans le jeu de rôle papier/jeux de plateaux. D'autres ont fait directement une école de game design pour jeu vidéo et n'ont jamais fait autre chose.

Non un game designer n'est pas destiné à être le leader. Il y a des game designers qui sont de simples exécutants. On leur donne les grandes lignes du design ou des tâches précises et s'assurent que tout marche comme prévu (et collaborent avec les artistes et les programmeurs pour réaliser leurs tâches). Si un game designer évolue vers un rôle de leader c'est probablement là aussi pour des raisons historiques. Le leader peut-être un studio head spécialisé dans le management, un ancien QA leader, un producer, un ancien programmeur ou lead artist, ou simplement celui qui a fondé la boîte avec ses sous etc. Il y aura peut-être un chef du game design mais il n'implémentera pas forcément SON idée de jeu mais celle pour laquelle il est embauché.
Si tu es indé et que tu es ton propre boss, tu as plus de chance de faire le jeu que tu veux mais il faut toujours t'entendre avec tes partenaires.

[yahiko]

Par contre je renommerai le game designer en "détenteur du projet" dans notre cas de petits amateurs qui se réunissent autour d'un feu virtuel en espérant un jour trouver les bons compagnons d'aventure ^^.

En général, pour les projets amateurs, en effet le "détenteur du projet" devient de facto le game designer.
Je ne suis pas sûr par contre que cela soit approprié dans tous les cas.
Certains "ddp" ont par exemple un background littéraire qui ne les prédisposent pas nécessairement à formaliser clairement des mécaniques de jeu de façon à ce que cela soit aisément exploitable par le programmeur. C'est souvent un échange où le "ddp" en arrive souvent à dire : "Si X alors Y ou peut-être Z, voilà en gros mon idée, mais si tu as des suggestions, n'hésite pas". En décodé : "je n'ai pas vraiment réfléchi à ce point, en fait je n'ai pas envie de bosser sur les détails techniques et à la formalisation, j'espère que toi le programmeur tu pourras te débrouiller avec. Si le résultat ne convient pas, on pourra toujours corriger le code car ça n'a pas l'air si compliqué après tout le codage..."

Si on part du principe qu'on ne peut pas se permettre dans une petite équipe d'avoir plusieurs GD dédiés à différentes parties du gameplay, et donc de n'avoir au mieux qu'une seule personne endossant le rôle de GD, alors j'ai quand même l'impression qu'un GD se doit d'avoir quand même une tournure d'esprit "scientifique" à minima. Histoire au moins de pouvoir fournir une liste suffisamment détaillée des contraintes liées au gameplay comme par exemple pour un jeu de plateforme, définir les différentes actions possibles du personnage, les paramètres comme sa vitesse de déplacement, la hauteur des sauts, les dégâts causés aux ennemis et aussi les patterns des ennemis et des boss, où sur ce dernier point, avoir une description un peu plus formelle que "le boss doit réagir aux actions du joueur" par exemple.

Ca me fait penser que même si l'IA est un domaine à part, le GD devrait avoir des notions en ce domaine pour bien concevoir un gameplay.

Selon moi ce qu'est supposé savoir faire un "ddp" s'il n'est là qu'en tant que tel :

- avoir des connaissances en graphisme, il aura la charge de la direction artistique (il connait les mécaniques de jeu qu'il veut, il doit avoir en tête à quoi doit ressembler son jeu sinon ça ne collera jamais aussi bien que si tout vient de lui).
- avoir des notions en termes de composition sonore/bruitages. Il doit avoir en tête tous les aspects que le joueur percevra, ça comprend l'ambiance sonore, les musiques et les bruits générés par les interactions dans SON monde.

Je me trompe peut-être dans ma vision du Game Designer, mais la discussion est faite pour échanger les points de vue à ce sujet de toute façon, mais j'avais plus dans l'esprit que le GD était plus dédié au gameplay. La direction artistique n'est selon moi pas forcément du ressort du GD, mais plutôt des créatifs comme l'équipe s'occupant justement des graphismes et du son. C'est peut être trop restrictif, mais je vois le GD comme finalement un Gameplay Designer même si oui, il peut avoir un avis à donner sur les aspects artistiques. Maintenant, si on considère non pas le GD mais le "ddp" au sens large, là oui, il peut toucher à tout, y compris aux aspects commerciaux et économiques puisque de toute façon il est le maître d'ouvrage si on peut parler de la sorte.

A mon avis, compte-tenu du rôle assez important du GD dans la réussite d'un projet (et tout son travail en amont de facilitation pour le ou les développeurs), un "ddp" qui aurait conscience de ne pas être un GD dans l'âme devrait faire du recrutement d'un GD une de ses priorités. Peut-être avant même de trouver un programmeur dans la mesure où le travail du GD intervient en préalable à celui du programmeur.

Pas sûr que je sois pas un peu parti en hors sujet mais je crois qu'on ne peut pas réellement traiter ta question. Le résultat est forcément subjectif car même Peter Molyneux (qui a eu sa période de gloire quand même) ne pourrait pas réellement te dire ce qui ferait un bon game designer, la preuve en est qu'il a lui-même fini par s'écrouler.

Pas touche à Peter Molyneux (tout comme Eric Chahi ou Sid Meier) !

Non un game designer n'est pas destiné à être le leader. Il y a des game designers qui sont de simples exécutants. On leur donne les grandes lignes du design ou des tâches précises et s'assurent que tout marche comme prévu (et collaborent avec les artistes et les programmeurs pour réaliser leurs tâches). Si un game designer évolue vers un rôle de leader c'est probablement là aussi pour des raisons historiques. Le leader peut-être un studio head spécialisé dans le management, un ancien QA leader, un producer, un ancien programmeur ou lead artist, ou simplement celui qui a fondé la boîte avec ses sous etc. Il y aura peut-être un chef du game design mais il n'implémentera pas forcément SON idée de jeu mais celle pour laquelle il est embauché.

Sans aller jusqu'à une orga studio presta et un éditeur client, oui, je pense aussi que le GD n'a pas vocation à être forcément le leader. D'autant plus qu'il a pas mal de boulot au final et que sans lui le projet ne pourra pas aller bien loin (à part faire des remakes).

Ca me fait dire que de ce que j'ai pu voir des projets indé auquel j'ai pu participer, il y a une certaine tendance à partir tout de go vers la programmation sur la base d'une vague idée, en se disant qu'on peaufinera au fur et à mesure et que cela pourra amener à donner des idées de gameplay. Alors que c'est souvent l'inverse qui se produit. A mesure que le développement avance, il devient de plus en plus difficile d'intégrer de nouvelles idées de gameplay car le programme étant conçu sur des hypothèses différentes au départ. Il faudrait sans doute que les projets indés amha investissent davantage sur la formalisation du gameplay, et ensuite s'y tiennent. Mais, je sais que c'est tentant de toujours en rajouter une couche quand on n'est pas soit même programmeur. "Oh, ça ne doit pas être difficile de rajouter ceci et puis cela ? "

[Dabou Master]

Certains "ddp" ont par exemple un background littéraire qui ne les prédisposent pas nécessairement à formaliser clairement des mécaniques de jeu de façon à ce que cela soit aisément exploitable par le programmeur. C'est souvent un échange où le "ddp" en arrive souvent à dire : "Si X alors Y ou peut-être Z, voilà en gros mon idée, mais si tu as des suggestions, n'hésite pas". En décodé : "je n'ai pas vraiment réfléchi à ce point, en fait je n'ai pas envie de bosser sur les détails techniques et à la formalisation, j'espère que toi le programmeur tu pourras te débrouiller avec. Si le résultat ne convient pas, on pourra toujours corriger le code car ça n'a pas l'air si compliqué après tout le codage..."

C'est assez biaisé comme vision des choses et ça sent beaucoup le vécu frustré ça ^^. Je parlais d'un ddp idéal dans tous les cas, et ce qui est idéal n'existe pas c'est bien connu sinon le monde sera parfait (et donc imparfait de par sa perfection).

Si on part du principe qu'on ne peut pas se permettre dans une petite équipe d'avoir plusieurs GD dédiés à différentes parties du gameplay, et donc de n'avoir au mieux qu'une seule personne endossant le rôle de GD, alors j'ai quand même l'impression qu'un GD se doit d'avoir quand même une tournure d'esprit "scientifique" à minima.
(...)
Je me trompe peut-être dans ma vision du Game Designer, mais la discussion est faite pour échanger les points de vue à ce sujet de toute façon, mais j'avais plus dans l'esprit que le GD était plus dédié au gameplay.

Ben j'espère que tu ne te vexeras pas si je dis ça mais on voit bien que t'es programmeur toi ! ^^
Je suis tout à fait d'accord qu'il faut un gars pour s'occuper de ça mais LE Game Design n'est absolument et à aucun moment uniquement fixé sur le gameplay, il n'y a même pas de proportion plus grande destinée au gameplay. Disons qu'en fait c'est pour ça que ta question est un peu trop ... impossible et insolvable ^^. Avant la direction artistique ne s'appelait pas direction artistique, c'était du game design aussi, au fur et à mesure "game design" laisse sa place aux autres noms plus parlants et un jour on parlera "d'ingénieur gameplay" ou que sais-je. Donc oui je comprends en partie ton point de vue mais tu vois un aspect particulier qui n'est que l'une des très nombreuses facettes du game design (qui englobe de par son nom absolument tout du jeu, c'est la façon dont est conçu le jeu quand même). Donc comme là je parlais d'un ddp dans le cadre de petits indépendants (enfin amateurs, on va pas relancer le débat là dessus) il ne peut pas se permettre de juste connaître le gameplay si ce n'est que ça son rôle. Parce que pour le gameplay il faut reconnaître que si tu réunis plusieurs joueurs, ils vont tous avoir une petite idée de gameplay et en fusionnant le tout t'auras un gameplay complet, plus ou moins bancal, qui pourra être ajusté en phase de beta test.

Pas touche à Peter Molyneux (tout comme Eric Chahi ou Sid Meier) !

Mais non ... Mais il faut reconnaître que pour certains l'aventure est ... plus ou moins terminée. Peter Molyneux reste mon exemple par excellence du game designer dans toute sa splendeur mais il a perdu sa flamme, ça m'attriste probablement plus que toi vu ce que certains de ces jeux ont représenté pour moi ^^.

Enfin pour conclure je me rends compte que ce dont tu parles c'est d'un game designer qui facilite la vie au programmeur. Mais c'est là où ça pèche, c'est que c'est une vision un peu étriquée, et c'est le gros problème classique des graphistes qui ne comprennent pas les développeurs et inversement. Le truc c'est que le graphiste ou le compositeurs ont autant besoin que le programmeur d'un gars qui saura leur dire ce qu'il faut. C'est pareil le graphisme, si tu fais un modèle pour tel but et que le but change ben tu dois tout refaire et ça prend énormément de temps.
Après c'est pas du tout une critique, on est tous comme ça à se soucier trop de nos soucis personnels sans se demander ce que les autres rencontrent, faut qu'on évolue ...

Tout ça pour dire qu'au final ta question initiale on ne peut pas y répondre car il n'y a pas vraiment de vision générale du game designer. Peut-être as-tu une problématique plus concrète qui pourrait nous aider à répondre avec plus de pertinence ?

[yahiko]

Tout ça pour dire qu'au final ta question initiale on ne peut pas y répondre car il n'y a pas vraiment de vision générale du game designer. Peut-être as-tu une problématique plus concrète qui pourrait nous aider à répondre avec plus de pertinence ?

C'est un peu noyer le poisson là... Ce n'est pas parce qu'on ne peut pas répondre à 100% à une question qu'on doit renoncer de répondre au 99% possible

[Iradrille]

Certains "ddp" ont par exemple un background littéraire qui ne les prédisposent pas nécessairement à formaliser clairement des mécaniques de jeu de façon à ce que cela soit aisément exploitable par le programmeur. C'est souvent un échange où le "ddp" en arrive souvent à dire : "Si X alors Y ou peut-être Z, voilà en gros mon idée, mais si tu as des suggestions, n'hésite pas". En décodé : "je n'ai pas vraiment réfléchi à ce point, en fait je n'ai pas envie de bosser sur les détails techniques et à la formalisation, j'espère que toi le programmeur tu pourras te débrouiller avec. Si le résultat ne convient pas, on pourra toujours corriger le code car ça n'a pas l'air si compliqué après tout le codage..."

Çà montre simplement que de "ddp" n'a pas assez réfléchi au sujet, si il y réfléchi assez il pourra l'expliquer clairement même en aillant aucune notion de dev.

Si on part du principe qu'on ne peut pas se permettre dans une petite équipe d'avoir plusieurs GD dédiés à différentes parties du gameplay, et donc de n'avoir au mieux qu'une seule personne endossant le rôle de GD, alors j'ai quand même l'impression qu'un GD se doit d'avoir quand même une tournure d'esprit "scientifique" à minima. Histoire au moins de pouvoir fournir une liste suffisamment détaillée des contraintes liées au gameplay comme par exemple pour un jeu de plateforme, définir les différentes actions possibles du personnage, les paramètres comme sa vitesse de déplacement, la hauteur des sauts, les dégâts causés aux ennemis et aussi les patterns des ennemis et des boss, où sur ce dernier point, avoir une description un peu plus formelle que "le boss doit réagir aux actions du joueur" par exemple.

Dans cette liste, beaucoup de choses sont "trop détaillées" pour être importantes : il y à de grandes chances que tout ça n'impacte pas le code. "Tel ennemi possède telle IA", pas besoin d'en savoir plus. Le fait que l’ennemi possède une IA impacte le code, la complexité de l'IA non (elle sera très certainement codée à part via un langage de script, Lua ou autre; on peut avoir besoin de la liste d'actions que l'ennemi est capable de faire pour coder ça, mais à part pour quelques actions très spéciales, ça devrait déjà être en place).

C'est pareil pour les dégâts causées par telle ou telle attaque, on a pas besoin des nombres exacts, seulement l'effet de l'attaque par exemple "inflige x points de dégâts et repousse l'ennemi de y mètres en arrière".
(On a besoin de ça pour savoir qu'on à besoin d'une fonction "pousse l'unité x mètres dans une direction" et une autre "inflige x points de dégâts". Pour le reste c'est comme L'IA, ça n'impacte pas le code.

Ca me fait penser que même si l'IA est un domaine à part, le GD devrait avoir des notions en ce domaine pour bien concevoir un gameplay.

Éventuellement de simples notions dans tous les domaines pour avoir une idée de ce qui est possible (et de la charge de travail que ça représente), mais rien de plus.

Mais je pense que c'est plus au dev de poser les bonnes questions pour savoir quoi faire exactement au niveau du code. Tout comme le graphiste posera des questions aussi pour savoir quoi gribouiller et le style graphique attendu.

À mon avis c'est plus un problème de communication que de connaissances.

[Bousk]

http://gamasutra.com/blogs/LizEnglan..._Designers.php

[yahiko]

Merci pour le lien. Je lirai ça à tête reposée, même si en survolant, j'ai une impression de "omg"...