Organiser une demande de graphismes pour gagner du temps

[Alchimèriste]

Je viens faire mon passage annuel (mon vaisseau suivant inexorablement une courbe inter-stellaire un peu compliquée, je n'ai pas souvent l'occasion de croiser la planète Terre mais dès que je peux j'en profite..) et en profiter pour poursuivre la discut' en rebondissant en partie sur la réponse précédente d'@lucard.

Je vois aussi que ce sujet n'est pas épinglé, deudiou.. ..bon il est vrai, il était assez improvisé à la base, mais au-delà de cette maltraitance flagrante et délibérée de mon égo, c'est dommage pour tous car il le devrait si je me base sur que je viens tout juste de lire quelque part sur ce forum, je cite de mémoire: << les graphismes sont la bête noire, ou le point noir, sur ce forum >> lorsqu'il s'agit de trouver des personnes et surtout de les garder.. J'ai un autre début de réponse.

Donc, comment garder son graphiste (en vie et surtout dans un projet) ?

Pour commencer il est nécessaire que le codeur se mette dans la tête du graphiste car ce dernier devra faire lui-même cet effort, ça a été déjà dit dans le message précédent en effet. En pratique ça signifie quoi et surtout quelles en seraient les conséquences? Pour simplifier je vais imaginer ici un binôme de base, genre duo codeur et graphiste, et un projet fictif ensuite.

Bien que tous deux soient, dans le cadre d'un projet, des créateurs/développeurs, codeur et graphiste n'ont pas forcément les mêmes aspirations, ni les mêmes excitations. Du moins l'origine du plaisir ressentie ne réside pas dans les mêmes sources, or ces sources sont nécessaires pour chacun des deux.

Dans la majorité des cas - je vais un peu schématiser - on peut observer que le codeur trouve un réel plaisir à résoudre des problèmes techniques arithmétiques, à assembler des mécanismes entre eux, pendant que l'autre prendra son pied à résoudre des problèmes esthétiques, à assembler des visuels. Cette naïve introduction vous fait sans doute marrer les gens, hein, pourtant ce n'est pas si évident que ça pour tout le monde, surtout en ce que ceci implique : si le codeur, à plus forte raison s'il est le "lead" comme on dit, trouve sa motivation et un réel plaisir en programmant un projet esquissé dans son brouillon ou digéré dans son cahier des charges/carnet de gamedesign, le graphiste, qui lui en retour serait uniquement sollicité et traité seulement comme un producteur de ressource, ne partagera pas (pour) autant ce même plaisir! Ce dernier peut le croire au début, et il signera avant de se rendre compte que l'intensité de ce plaisir n'était finalement pas à la hauteur de l'investissement nécessaire.

Et pourquoi ça?

Car les graphismes ne sont pas (que) des ressources.

J'aime cette notion de plaisir, elle est l'unique moteur naturel qui justifie l'effort et qui va de fait conditionner la présence des membres au sein d'un même projet. Le cadre amateur des projets vidéoludique doit composer avec le poids légitime des individualismes, que vous le vouliez ou non.

Gainsbourg disait un truc plein de sens, qui n'est heureusement pas forcément valable pour tous, mais que les recruteurs de graphistes devraient toujours garder en tête :

«En amour, il y en a toujours un qui souffre et l'autre qui s'emmerde»

Oui, le codeurecruteur souffre souvent c'est vrai... vous me suivez?

Mais parlons du graphiste-recruté, qui fait ici l'objet de nos attentions. Cet animal là, éprouvera de grandes difficultés à s'investir sur le long terme si l'impression de donner vie à une idée, à un projet, lui échappe ou n'est ressentie qu'en vertus des lignes de code tandis que d'autre part, la partie graphique est reléguée ou objectivement vécue simplement comme des ressources nécessaires versées au projet.

Habiller ultérieurement un pavé de code cuisiné en solo de quelques décorations sur commande est un luxe qui fonctionnent parfaitement (en terme de productivité du moins, pas toujours de qualité) bien dans l'industrie mais l'expérience tend à démontrer qu'il en est tout autrement dans un espace récréatif, comme ici.

Ceci, la commande ou la relation unilatérale, conduit à des notions de sous-traitances qui ne procureront pas au graphiste autant de plaisir que les élans créateurs éprouvés par le codeur-créateur du projet. Dans la majorité des cas même, ce travail de sous-traitance consistant à fournir des ressources ne produit tout simplement aucun plaisir et ne justifie plus du tout, dans un cadre de travail bénévole, la présence du dit graphiste qui s'était pourtant engagé en toutes connaissance de cause. Si les graphistes ne se présentent pas, ou peu ou ne restent pas, c'est donc surtout parceque ce lead comme vous dites, a pensé pouvoir avoir ce genre de rapport nécessaire et pragmatique.

Résignez-vous, malheureusement, avoir eu l'idée d'un projet sans pouvoir l’exécuter complétement seul ne fera pas de son initiateur ni le père, ni le leader. Dès lors qu'un codeur recrute gratuitement un graphiste, celui-ci accepte - ou devrait accepter - l'idée que le projet lui échappe en partie au point de soudainement ne devenir qu'un collaborateur à part égal.
Richard Garriott (Akalabeth / Ultima zero) étant codeur et graphiste (rigolez pas de ce temps où l'on programmait ses propres graphismes à coup de lignes rigides en GW-BASIC) et n'avait pas ce problème alors que lui aussi travaillait en parfait amateur. Quand aux anonymes d'Ubi-Soft, ces petites mains savantes, la question ne se pose pas tant elle nourrit son homme suffisamment bien dans un cadre professionnel, excluant toute autre considération de plaisir.

Entre ces deux moyens de productions il y a le codeur sans le sou qui cherche un graphiste à ne pas payer et dans ce cas il faut changer son logiciel de pensée pour pouvoir motiver et garder ce collaborateur nécessaire.

Pour trouver et garder des graphistes il faut donc en réalité voir les choses autrement, et plutôt comme ceci : les graphismes sont, aussi, le projet au même titre que le code. Si c'est évident pour toi lecteur alors cesse de perdre du temps à lire ce texte, si ça ne l'est pas imagine plutôt que tu tombes sur une annonce de ce type :

"Bon, j'ai mon projet, j'ai plein de dessins bien avancés et de sprites, je cherche un codeur pour me faire les ressources nécessaires à rendre ceci animé et jouable. Par contre je m'occupe de tout de A à Z, je dirais juste à mon codeur ce dont j'aurai besoin. Si tu aimes coder, que tu as du talent contacte moi. "

Tu serais choqué non? En tous les cas tu comprendrais que ce gars éprouve certaines difficultés à trouver les petites mains dont il a besoin pour donner vie à ce qu'il désire garder comme son projet. Pourtant ici on parle du premier cas de figure cité plus haut dans le message précédent d'@lucard. Ce cas de figure est envisageable, souvent envisagé mais il débouche sur ce fameux problème de désertion des rangs.

Très bien. J’ose à peine imaginer les commentaire que ce gars pourrait générer.. vous aussi n'est-ce pas?

Coder c'est compliqué et c'est le cœur du projet, les graphismes c'est secondaire et cosmétique

Inventeurs de tout poils détrompez-vous si vous aviez eu la maladresse de penser que ces deux postes/activités sont incomparables ou que l'on ne peut renverser la situation de cette manière sous prétexte qu'un graphiste ne peut recruter un codeur contrairement au cas de figure habituel qui laisserait entendre qu'un codeur le pourrait.
Ces deux postes, codeur et graphiste sont si complémentaires qu'ils ne peuvent être comparés de cette manière, ni même envisagés  en position d'inégalités face aux processus de décisions, d’élaboration des bases et de développement général de n'importe quel projet.

Je disais que les graphismes ne sont pas des ressources, ils ne sont pas des ressources en effet, ils sont aussi le projet lui-même et à part entière. Cette nuance est cruciale.
Ce n'est pas un avis ou une opinion de jugement, on se fiche de la démocratie ici (et ailleurs aussi visiblement bref,,), la question n'est pas d'ordre morale et si les graphismes sont autant le projet que le code c'est aussi et surtout pour des raisons techniques et pratiques : une ligne de code déconnectée du design qui l'habille serait immédiatement ressentie par le joueur.  De manière plus générale, un code/entité de jeu qui serait écrit sans son "image" (sans son alter-ego pixelisée), manquerait inévitablement de cohérence, de consistance et cela se ressent immédiatement, y compris en terme de gameplay. Chaque aspect d'un projet, pour être le plus juste et le plus ludique possible, doit être battu en forge avec un même alliage code-graphisme. On ajoute pas un travail à un autre, ou alors on accepte l'idée que le résultat soit aussi déséquilibré en jeu qu'il aurait été entre ceux qui en sont l'auteur.

Cette harmonie, cette "même longueur d'onde", ne peut naitre qu'un travail commun et en temps réel entre codeur et graphistes : le graphisme peut certainement satisfaire ce dont le code aura besoin mais le graphisme devra tout autant nourrir le code aussi. En rendant stérile le pouvoir décisionnaire du graphiste recruté (et possibilités de véto), un visuel, un décors etc.. donc en coupant le graphiste de son potentiel de création, en l'empêchant d'intégrer à part entière et égal ce flux de développement en amont, chacun de ces visuels se trouveraient inévitablement désincarnés, sans fondements, ne seraient en fin de compte que des marionnettes, maladroitement mis en scène et suspendues à des lignes froides de codes agrippées ici et là de manière très chaotique.

Dans tous les cas, la frustration de chaque partie serait grande et si le lead n'a pas d'autre choix de rester, ce n'est pas tout à fait le cas des autres.

Stop la théorie-bateau, voici un exemple pour bien illustrer mon propos, ce que ça donne en pratique ce disfonctionnement codeur-graphiste si rien est aménagé en ce sens.

Croc-Mignon, le mario à l'age de pierre avec des bouts de dents dedans

Le codeur et leader du projet fictif Croc-Mignon à besoin d'un graphiste pour créer un niveau de type caverne (exploration latérale 2D) et les ennemis qui la peuple, disons un ours, trois salamandres géantes et quelques rats car un jeu vidéo n'est pas un jeu vidéo sans rats à poutrer dans le tutoriel.

Le codeur utilise jusqu'à présent des visuels temporaires qui servent à 100% sa propre vision du projet et a donc pu mettre en pratique son code qui semble bien rouler. Oui, mais ce codeur utilise bien des graphismes temporaires et ces "visuels" ne sont que le fruit de ses propres besoins, ils ne sont pas le résultat d'une élaboration particulièrement précise, puisque ce n'est pas leur rôle. Nous sommes d'accord.

Or cette démarche artistique impliquera plus tard pourtant forcément un certain processus plus ou moins poussé de réflexion, mêlant références et imagination. Un travail que pas mal de monde pense pouvoir être réalisé alors que le code est ficelé. Qu'importe, le codeur pense avoir terminé son projet, il ne manque que les graphismes.

Notre lead poste son message et trouve un graphiste sur le bord de la route, le prend en stop, lui explique le projet et pense certainement que l'autre rigolo va se contenter de se mettre sur sa table à dessin afin de lui pondre une caverne et les animaux qui vont bien.

Au départ c'est certainement ce qu'il va se passer, le graphiste va commencer par produire les décors, une caverne par exemple et aussi imaginatif qu'il peut l'être va tout de même pour le fun ou pour le projet, aussi se nourrir et se régaler de références existantes grâce aux livres de sa bibliothèque, grâce à des documentaires sur la préhistoire éventuellement, sans oublier notre mai qui nous veut du bien, Google Image etc.. Bref le graphiste il compulse, il recherche, il structure en absorbant ce joyeux cocktail puis il dégurgite au bout de quelques heures.

Et c'est à ce moment, alors que son trait se fait plus assuré, que le tracé s'affirme et prend un sens que ce graphiste-recruté va commencer à vraiment tiquer sur des détails.. ..ce qu'il a en tête se heurte à ce qu'il doit pourtant respecter, il va commencer à remettre en question le fait que dans cette grotte par exemple on ne peut voir que des stalagmites (le code n'ayant prévu pour son gameplay et leveldesign uniquement ce type de collision au sol). Ce graphiste va se forcer au début, il va tenter de produire quelque chose qui, au fil de son exécution, va lui sembler de plus en plus improbable et incomplet, il faudrait vraiment des stalactites!

Ce graphiste va commencer à discuter avec son lead, il va dire que cette grotte serait bien mieux avec des pitons au plafond, ce qui risque de modifier foncièrement le gameplay, puis il expliquera au passage au codeur que l’absence de lumière parait illogique, que ce serait bien du coup que le personnage puisse tenir ou allumer des lampes à huile, que ça ferait joli-joli partout, que ça pourrait faire ci ou ça.. que sans un minimum de nouveaux détails le rendu ne serait pas si sympathique que ça.

Le codeur ne tient cependant pas à s'éloigner de son idée originale, pas tant du moins, alors le graphiste se résigne mais en son for intérieur il lui est impossible, impensable de dessiner une grotte et de la représenter en couleur sans jeux de lumières..ni même avec une source de lumière fictive alors il cherche une solution visuelle et décide de percer les parois de la grotte, il place des petites lucarnes naturelles et des minéraux magiques de sorte à faire entrer/irradier logiquement la lumière (sinon c'est pas logique la lumière au fond d'une grotte et ça bhen ça file des démangeaison à notre graphiste). Idem pour les stalactites que le codeur ne veut car ceci modifierait le gameplay (c'est relou le personnage va se cogner en sautant et je veux pas modifier la hauteur du saut) mais le graphiste les représente quand même en sachant que ceux-ci, contrairement aux stalagmites, seront privés de hitbox..pour pas perturber les sauts bref, il se résigne et continue donc. Notez que pendant ce temps, le codeur à l'impression d'être ouvert et tolérant, il "accorde" ainsi certaines libertés à son collègue, du moment que le gameplay ne change pas. Ok.

Pourtant, mal-grès tout, le graphiste qui a passé des heures à imaginer cet univers, à table, aux chiottes et en mangeant, se voit contraint de se l'imaginer en mouvement, d'en supposer le rendu afin justement de produire ce résultat. Imaginer un monde complet a des conséquences, la première étant la cohérence et il ne peut s’empêcher de le rendre cohérent lorsqu'il le reproduit sur sa page blanche et mieux encore, cette cohérence qui s'est matérialisée dans son esprit va l'aider dans son travail car les effets de lumières vont lui permettre de sculpter les formes et les volumes de milles et une nuances.. autant de détails multiples, de démarches invisibles e mentales, qui feront de ce travail, au final, un rendu de qualité, cohérent et complet. Un beau niveau de Caverne quoi.

Le codeur sera enchanté.
Le graphiste lui un peu plus frustré, car si le résultat plait à son collègue, nombre de ses idées servant le design (lampes à huile, collisions stalactites) n'auront pas été implémentées puisqu'elles n'ont pas été prévues dans le cahier de gamedesign initial ni voulues pour le gameplay final.
Plus simplement dit, le code n'aura pas été modelé en même temps que leur cadre graphique et a laissé de côté tant de détails que cette impression de travail inachevé peut être décourageant pour le graphiste. N'oublions pas que le graphiste travaille dans cet exemple gratuitement, donc que le profit est d'ordre personnel - le plaisir de créer - et en ce sens ne peut pas ou très mal se heurter à des limitations sans justifications économiques.

Il faut bien comprendre que c'est en produisant les graphismes, en développant les designs, souvent, que des idées surviennent et s'imposent soudain comme des ingrédients potentiels de gameplay et de leveldesign. C'est en dessinant des rats pour son codeur que le graphiste va soudain se dire que ceci parait un peu illogique, ou que ces ours ne peuvent être aussi grands et nombreux, ou encore qu'ils seraient mieux de couleur bleue avec un nez rouge, ou je ne sais encore quelles autres idées saugrenues donc indispensables pourront soudainement s'imposer.

Les idées s'imposent souvent par la pratique, rarement from scratch

Le processus artistique s'accompagnant inévitablement toujours de réflexion et de références dont il faudra se rapprocher ou au contraire se libérer : dans tous les cas ce qui conduit la main sera l'esprit et en ce sens une remise en question inévitable d'un grand nombre de points précis qui ont été pensés sans cette démarche artistique spécifique. Oui le codeur aussi à de l'imagination, elle n'aura pas été seulement technique bien entendu mais elle n'aura pas été non plus le fruit d'une expérience artistique en terme de pratique, sinon il serait lui même également l’artiste de son projet.

Cette partie du processus de réflexion, penser un jeu, ne peut donc pas provenir uniquement de prévisions et de l'imagination du codeur puisqu'une partie de cette source émane directement de la démarche préalable à la création graphique. Omettre ceci, aller contre ce sens là et ne pas en tenir compte forcerait au graphiste à fonctionner comme un pourvoyeur de choses, de trucs, de bidules sans aucun sens, et ce qui n'a pas de sens n'est jamais ni très beau, ni personnel, ni créatif. Ce qui est possible pour des visuels temporaires ne peut fonctionner pour des visuels finaux.

Et quelle est la meilleur manière d'intégrer les découvertes et nouvelles idées développées par un graphiste exécutant un travail de production de ressource pour un projet? Oui, en l'ayant intégré forcément à statut décisionnel égal au codeur, dès le départ, dès la conception même du projet.
Si un graphiste arrive en cours de route, alors c'est que le codeur à merdé, littéralement, ou alors qu'il accepte de devoir éventuellement modifier un certains nombre de choses nouvelles.

Si les codeurs ne trouvent pas de graphistes, c'est souvent, pas toujours mais souvent, que ceux-ci savent qu'ils seront limités en terme de créativité et que cette créativité ne se cantonne pas à des visuels mais aussi à la fonction et à l’utilisation de ces visuels, on parle bien de codage là. Limiter un graphiste, ne pas lui permettre de lui laisser avoir un rôle à joueur dans le comportement future de ses propres visuels c'est limiter l'imagination qu'il aurait eu plaisir à avoir à approfondir et améliorer chaque aspect prévu par le code, c'est aussi lui dire qu'on est pas là pour s'amuser et c'est lui dire enfin de séparer imagination et production, chose impossible dans ce domaine.

Vous ne demanderez pas aux graphistes de ne pas réfléchir sur le pourquoi du comment. Vous ne recruterez jamais un graphiste qui saura correctement produire un intérieur de palais fantasy par exemple si vous ne lui permettez pas de concevoir ce palais de manière globale.
Le graphiste amateur ne travaille pas sprites par sprites (il faut être payé pour le faire et le résultat sera limité) il crée un ensemble cohérent dont il produira ensuite les composants. Un codeur aussi imaginatif qu'il peut l'être n'a pas accès à cet ensemble que le graphisme imagine au file de ses expérimentations et croquis, c'est pourquoi il se doit de les prendre en compte à valeur égale que ses propres idées et expérimentations.

Pour le projet fictif Croc-Mignon, et tout autre projet réel qui se veut amateur et bénévole, le graphiste même si le codeur l'écoute, finira pas ne plus ressentir la même ivresse, sentant que chaque choix doit être soumis au bon vouloir d'une tiers personne avec un rapport hiérarchique déséquilibré en terme de validations des idées. Ce graphiste ne trouvera pas le même plaisir que son collègue codeur, il s'investira moins, et produira au mieux un strict nécessaire sans vie ni originalité, et au pire ne produira pas plus rien, par manque d'envie, par manque de motivation. Lorsqu'il n y a plus de plaisir, il n y a plus de projet du tout.
Ne pas perdre ce graphiste ne consiste donc pas à l'écouter, mais à le considérer comme un lead d'égal à égal.

Maintenant, à part décisionnel égal, si tous les deux étaient leader du projet, le graphiste aurait alors intégré son idée de lampes à huile et le codeur bien embarrassé de reconnaitre ce surplus de travail aurait aussi découvert que le gameplay allait s'enrichir d'un nouveau concept incluant au gamedesign des jeux d'ombres et de lumières, et même de nouveaux défis avec des ennemis qui tireraient profit de ces ténèbres, ou la nécessiter de devoir trouver de l'huile etc etc.. et même de modifier les points de sauvegardes de sorte à ce qu'ils soient plutôt des dessins façon art rupestre que le joueur/personnage peinte et ajoute sur les parois en ayant trouvé au préalable des pigments magiques au lieu des save fixes initialement prévus en fin de niveau etc.. etc..


Précision pour finir : je n'ai pas écrit ceci pour faire le beau, le mec qui parle et qui étale sa science que ça ne peut être d'ailleurs, ni n'expose forcément mon propre vécu, je ne règle pas de compte et je ne m'inspire de rien ni personne en particulier, je n'accable pas non plus les codeurs ni les graphistes, ne défend pas ces derniers, je n'expose aucune vérité vraie sinon la mienne et elle me suffit car je la sait valable pour moi. Je me suis dit que si c'était bon pour moi, ça ne pouvait pas être totalement inutile pour certains.
Ce que j'espère c'est que mon propos aura comme conséquence de modifier la vision de certains initiateurs de projets, tout au moins de donner des débuts de pistes pour résoudre ce problème et motiver des candidatures lorsqu'il s'agit de trouver un graphiste non rémunéré. Vous devez comprendre comment chacun fonctionne et lâcher du leste, rendre les projets collaboratifs dès le début et ne pas croire ce que l'on peut lire parfois et qui me fait rire à savoir : commencez seul et recrutez ensuite... ça marche pas en mode amateur ça, faut payer pour ça.

En attendant on peut résumer tout ce texte à ceci :

 



PS: comme toujours c'est livré plein de fautes de français et tout et tout.. dsl
EDIT: merci XENOS Tes notes résument tout à fait ce pavé indigeste, je sais qu'en plus de faire pas mal de fautes je n'ai pas l'esprit synthétique, un tord pour arriver à expliquer rapidement des choses donc merci pour tes notes!