Organiser une demande de graphismes pour gagner du temps

[Alchimèriste]

Un petit conseil qui peut faire gagner du temps..


Codeurs/responsables de projet, lorsque vous finalisez un jeu ou que celui-ci est suffisamment avancé et que vous recherchez l’aide d’un graphiste pour remplacer vos visuels provisoires voici une méthode parmi une autre pour ne pas {faire} perdre de temps voir motiver vos recrues.
Je sais que personne n’est débile ici même si vous croyez que je donne l’impression de parler à des bleus dans ce post. Au pire ne lisez que la fin de ce sujet, la liste donnée en citation à titre d’exemple.

Donc, dans la mesure du possible évitez svp ce genre d’annonces :

je recherche un graphiste pour faire les unités et bâtiments de mon jeu de gestion.

Ce type de demande, même si j’exagère un peu pour l’exemple, suppose et impose une cascade de questions / réponses de votre part et de la part des intéressés potentiels. En effet vous ne faites pas l’état des lieux et n’avez pas offert de vision globale du travail à accomplir. Les candidats ne connaissent sans doute même pas votre projet.

Il faut éviter les questions inutiles qui nécessitent d’attendre des réponses. Trois mois pour finallement se rendre compte que le gars ne pourra pas vous aider c’est du temps perdu. Accrochez vos candidats immédiatement et même si c’est peut être le but de bien dialoguer ensuite - c’est souvent quand même nécessaire à terme - préparer le travail à l’avance peut allécher le graphiste ou au contraire lui faire comprendre quil ne fera pas l’affaire.
Le mieux est de présenter plus clairement la nature de la demande et la densité du travail demandé, vous éviterez ainsi – sauf si c’est le but – les floods inutiles du genre : quelle sorte, quelle taille, pour quand, tes qui etc etc..


1 - Pour vous épargner cette perte de temps et montrer au graphiste que vous savez ce que vous désirez commencez par énumérer complètement les ressources nécessaires. Vous ne voulez pas tomber sur un rigolo et le candidat veut être certain que vous n’êtes pas non plus un rigolo.

2 - Classez-les dans des catégories de type {bâtiments, animaux, guerriers, véhicules, etc.} ou de taille {32x32px, 128x128px etc..} ou de nature {animations, sprites fixes, textures raccordables, etc..} bref tentez de regrouper les travaux plus ou moins identiques.

3 – éventuellement identifiez les ressources urgentes, celles qui ne sont pas prioritaires ou encore celles qui ne sont que optionnelles ou pas encore nécessaires.

4 - Dressez une liste propre regroupant tout ça et complétez cette liste avec une description claire de ce que vous voulez en terme de format d’image, de qualité et style de rendu, d’esthétique, couleurs etc..

5 – Éventuellement – en bonus - préparez par avance une archive compressée des anciens visuels, ceux actuellement utilisés mais que vous voulez remplacer, ajoutez y si vous en ressentez la nécessité, dans un sous-dossier à part, des sources d’inspirations qui vous semblent pertinentes et pourquoi pas quelques notes TXT. Le graphiste sen servira pour vous comprendre au-delà des mots. Laissez ceci à disposition des gens en DL sur un lien.


Lorsque ceci est prêt, vous n’aurez plus jamais à le faire et les seules questions que vous aurez ensuite à traiter seront plus précises et efficaces. Un dialogue entre vous et le candidat sera largement plus constructif lorsque vous jouez cartes sur table et que ce graphiste aura déjà connaissance du gros de la demande, une vision globale du chantier, grâce à votre poste et avec vos zip/rar.


Je vais illustrer maintenant ce que le graphiste devrait voir immédiatement pour savoir sil peut ou non résoudre votre problème, sil en a les compétences ou le temps. Tout ceci ne sont que des suggestions, je ne dis pas de détailler forcément autant ou autre mais convenez que ce sera autant de choses à ne pas répéter ensuite.

Blabla...Mon projet se termine, actuellement j’utilise ces templates de base : graphismes_provisoires.zip et je voudrais maintenant des visuels plus adaptés qui serviront pour la version finale de mon jeu :

---

Jeu : jeu de gestion rétro style Warcraft
Vue : pixel art / vue iso parallèle / fond transparents c.a.d. sans les sols, juste les éléments
Style : cartoon avec bords noirs ou autre je sais pas et couleurs criardes ou alors comme dofus
Délais : je compte présenter mon alpha dans six mois..
Univers : médiéval fantastique apocalyptique fun voir délirant
Pièces jointes : graphismes_provisoires.zip contenant aussi des sources d’inspiration que j’aime
Implication du graphiste : je laisse au graphiste toute la liberté nécessaire sauf concernant les détails précisés ici

---

Total des ressources à créer : 42 visuels libres de droit et originales

Bâtiments – les structures ne seront pas animés mais en 3 stades dévolution

• Mine, 32x32px, png
  
• Forge, 64x64px png
  
• Scierie, 64x64px png
  
• Donjon, 128x128px png
  

Total : 4 batiments déclinés en 3 versions soit 12 visuels

Unités – si possible un minimum d animation pour faire jolie

• Lanciers, 8x8px png ou gif
  
• Cavaliers, 8x8px png ou gif
  
• Paysans, 8x8px png ou gif
  

Total : 3 types d’unités pour 6 joueurs soit 18 visuels

Ressources – ce sont des icônes, pas de fond transparent mais rondes en 8x8px gif / jpg ou png qui s’embrasent de flammes lorsque l’on les survole

• Bois, buches
  
• Minerai, cailloux
  
• Monnaie, pièce or
  
• Login, bouton I/O
  

Total: 4 icones off et les même en hover donc 8 icones

Effets Spéciaux

• Brouillard, image de 256x256px représentant des nuages de brume distincts, animé si possible
  
• Particule de neige, texture raccordable de 64x64px ou comme vous voulez, non animé
  

Total: 2 images

Terrains – ce sont des tuiles/carrés 64x64px vue iso comme le reste déclinés en deux saisons, hiver/été et les textures devront se raccorder sans impression de voir les bords et sans répétition trop voyante pour les yeux

• Plaines
  
• Désert
  
• Eau
  

Total: 3 types en deux saisons soit 6 tuiles

---

Notes : ah et aussi, je suis fan de MadMax pour le coté destroy et de Trine pour le coté magique et coloré, je voudrais un compromis entre ces deux univers mais je peux changer d’avis si vous avez une meilleur idée.

Pas obligé de faire aussi précis ou complexe ou comme ça, chacun adapte à sa sauce.
De ces conseils ne prenez rien, un peu ou beaucoup mais en gros vous avez compris le message. Je ne sais pas si ceci peut vous servir mais par expérience, je sais, en tant que graphiste amateur, qu avec ceci je peux vite savoir si ça vaut le coup et si j’ai le temps d’aider ou non une personne.

Sur ce, bon code !

[Xenos]

Je ne sais pas si le format d'image (png, gif...) est vraiment intéressant pour le graphiste. Il me semble que le type d'image est bien plus important: transparence ou pas? Couleur RGB? niveaux de gris? N&B? Indexées?

Dans la plupart des cas, un simple "Les images devront être en RGB 32 bits" en début de listing sera surement plus sûr qu'un "je veux du .gif" (qui peut être en couleurs indexées ou N&B).


En revanche, je suis d'accord sur tout le reste.

J'ajouterai même que, puisqu'un projet sérieusement monté a certainement un issue tracker, créer un ticket sur ce tracker pour chaque bundle d'images me semble approprié (un ticket par image, s'il y a 500 sprites, ça me semble trop, mais 1 ticket pour les 14 sprites de légionnaire romain, ça me semble cohérent). En plus, cela offre des outils pour mesurer l'avancement des tâches, et la possibilité de laisser travailler plusieurs graphistes en parallèle. Et chaque graphiste peut facilement remonter le résultat de son travail en uploadant son zip d'images, avec une note descriptive et le statut "Resolved" sur le ticket.

[@lucard]

Je suis fan de ce sujet... En tant que graphiste, c'est chiant voir 'lourd' de toujours demander la même chose au(x) demandeur(s) :

Quelles tailles ? combien ? quel rendu ?

Surtout que, lorsqu'on commence à travaillé sur le sujet, parce qu'on à en tête notre propre vision de la chose et que ça nous botte bien... et qu'au final, on nous dit :  "euh... non c'est pas comme ça (de ce genre) que je le voyais..." et que ça tombe dans un univers complètement différent duquel nous aimons travailler... ça démotive clairement à poursuivre.

La façon dont tu as proposer ta fictive demande, Alchimèriste, est terriblement plus alléchante que n'importe quelle autre demande sur le forum.

De plus mettre une Deadline est très intéressant (avec suffisamment de temps / en s'y prenant à l'avance)...  faut pas non-plus demander de faire tout ça en 2 semaines...

@Xenos :
Comme tu le sous-entends, pour le choix du format, c'est plutôt à nous, graphistes, de dire ce qui serait le mieux en fonction de ce qui est demandé.

toutefois, peu de "demandeurs" savent réellement ce qu'ils veulent, et souvent ignorent ce qu'est la différence/ l'utilité entre les couleurs RVB 8, 16, 32bit, CMJN, couleur indexées, etc...

[Xenos]

Dans la même lignée de sujet (désolé, j'ai bien lu ton message @lucard, mais j'ai rien à y répondre directement), vaut-il mieux attendre d'avoir du rendu de base (rendu "temporaire", visuels non-définitifs) avant de demander de l'aide aux graphistes, ou est-il possible, avec une belle description comme proposée par Alchimèriste, de lancer la demande bien avant d'avoir les premiers visuels (limite, en parallèle du code, parce que oui, c'est ça ma vraie question en fait)?

Parce qu'en un sens, si on code en ayant les visuels, c'est carrément motivant; et comme c'est pas codé, il est surement plus facile d'accepter du(es) graphiste(s) quelque chose de différent de ce qu'on avait en tête.

[@lucard]

Il y a 2 façon de voir les choses.

- Soit le codeur s'occupe de ce qu'il y aura dans ses "pages", et l'ensemble globale de son projet.
- Soit il y a une discussion dès le départ, avec le graphiste, pour discuter de l'ergonomie du projet.

Dans le 1er cas, si tout le projet est gérer de A-à-Z par le codeur (c'est entièrement son projet) alors le graphiste peu commencer à bosser après le début du code... les "emplacements", les tailles, etc, sont définis par le codeur.

Dans le deuxième cas, c'est un projet qui sera plus "partagé".
D'après les explications du codeur, le graphiste produira une maquette du projet.
L'avantage c'est qu'on pourra rapidement voir les problèmes de codages qui pourront en résulter, où si l'ergonomie est suffisamment bien pensée.
L'avantage d'une maquette, c'est qu'il sera plus facile au graphiste de modifier ses propres illustrations/ mises en page.

L'interprétation d'une description est différente pour chacun. Que ce soit du codeur au graphiste, ou même d'un graphiste à un autre. Il faut bien comprendre que votre vision ne sera jamais totalement reproduite. Parfois ça n'ira pas, mais parfois vous aurez de bonne surprise, et peut-être même une nouvelle façon de voir votre propre projet.

Pour ma part, je préfère travailler depuis le début avec le codeur en début de projet pour porter ce projet plus loin.
Lorsqu'on ne s'occupe que des graphisme, les propositions d'amélioration sont souvent laissée pour compte avec des réponses du type :"Mais ça me fait changer tout un code là... c'est plus chiant qu'autre chose. Change juste la tronche du gars, c'est tout."

Je pense que, pour qu'un projet arrive à un ensemble cohérent, il faut plusieurs personnes sur le projet, un peu comme pour l'écriture d'un Roman, l'auteur (même s'il est seul à écrire son bouquin) aura besoin de personnes pour relire, trouver des incohérence, des problème de compréhension, ou encore des anachronismes...Je ne crois pas avoir jamais vu/lu un livre sans remerciement d'autres personnes ayant soutenu/aider l'auteur.

=)

[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!

[Xenos]

TL;DR

• Il y a 3 rôles dans la création de jeu: Coder le jeu, Dessiner le jeu, Concevoir le jeu. Evitez que la conception soit uniquement accaparée par le codeur, qui traiterait alors "son" graphiste comme une bête source d'images. Répartissez le rôle de conception (surtout si vous ne rémunérez pas votre graphiste associé).

• Avancer en parallèle conception, code et graphisme permettra d'une part de gagner du temps (par parallélisation, le projet sera fini plus tôt) et d'autre part, de gagner en qualité, par l'échange d'idées entre les deux associés (idées différentes, vu les mondes dont ils viennent) et d'améliorer ainsi la conception du projet.

Ne pas perdre ce graphiste ne consiste donc pas à l'écouter, mais à le considérer comme un lead d'égal à égal.

PS: épinglé
PSS: Ce TLDR n'a pas pour vocation d'envoyer promener le roman, bien écrit et sympa à lire, mais de servir de note de rappel (en fait, c'est ce genre de petite note que je laisse usuellement sur mon bureau, mais pourquoi ne pas la partager ici?!)

[niahoo]

Ouf merci, j'avais commencé à lire mais vraiment pas le courage d'aller jusqu'au bout.

[Alchimèriste]

Excellentes tes notes Xenos, il est vrai qu'en plus d'être trop long inutilement (après c'est de l'impro donc je n'a pas réalisé ce travail de synthèse) mes explications restent assez basiques, d'ailleurs je le disais que je simplifiais un peu en limitant l'équipe à codeur / graphiste, alors qu'en réalité en effet l'équipe peut être parfaitement fonctionnelle à 3 voir à 4 si on ajoute un musicos.

Je voulais ajouter que ce texte n'est à lire qu'en dernier recours, seulement pour ceux qui galèrent un peu à trouver un graphiste, et qui peuvent peut-être y trouver un début de solution dans la manière de recruter et bosser.

[rachids]

Merci pour ton temps et le partage de ton expérience en tout cas, ça reste toujours quelque chose de non seulement très pertinent mais en plus gratuit.

J'aurais assurément besoin d'un graphiste bientôt, alors je penserai à consulter ce message