Tout le monde a un souvenir de projet commun qui a mal tourné. Un exposé à quatre où une seule personne a travaillé. Un groupe de musique qui s'est séparé avant le premier concert. Et, pour beaucoup de créateurs de RPG, ce fameux projet entre copains, lancé un soir d'enthousiasme, avec un scénariste, deux graphistes et un compositeur, qui n'a jamais dépassé la carte du premier village.
Le plus frustrant, c'est que ces projets meurent rarement pour des raisons techniques. Ils meurent de malentendus. Qui décide ? Qui a écrasé le fichier de l'autre ? Pourquoi mon nom est-il en petit dans les crédits ? On ne s'est pas disputés sur le code, on s'est disputés sur tout le reste.
Bonne nouvelle : le reste, ça s'organise. Voici ce que j'aurais aimé savoir avant ma première guilde.
Le pacte de départ
Avant d'ouvrir l'éditeur, prenez une heure, autour d'une table ou en visio, et écrivez ensemble une page. Pas un contrat de cinquante pages, une page. Elle doit répondre à six questions.
- Quel jeu fait-on ? Une phrase de pitch, une durée visée, trois jeux de référence. Si l'un imagine un petit RPG de deux heures et l'autre un monde ouvert de quarante, mieux vaut le savoir maintenant.
- Qui fait quoi ? Les rôles, et surtout qui a le dernier mot dans chaque domaine.
- Combien de temps chacun peut-il donner ? Trois heures par semaine, c'est très bien. Ce qui est toxique, c'est de dire vingt et d'en faire trois.
- Comment décide-t-on quand on n'est pas d'accord ? Vote, chef de projet, tirage au dé à vingt faces : peu importe, tant que c'est décidé avant la dispute.
- Comment apparaît-on dans les crédits ? Noms, pseudos, rôles, ordre.
- Que se passe-t-il si quelqu'un part ? Ses contributions restent-elles dans le jeu ? Sous quelles conditions ?
Cette dernière question paraît pessimiste. Elle est surtout réaliste. Dans un projet qui dure un an, quelqu'un aura un bébé, un nouveau travail, une rupture ou simplement une envie d'autre chose. C'est normal. Ce qui ne l'est pas, c'est de découvrir à ce moment-là que personne ne sait si on a encore le droit d'utiliser ses musiques.
Les crédits et les droits, sérieusement
Je ne suis pas juriste et cet article n'est pas un conseil juridique. Mais deux articles du Code de la propriété intellectuelle méritent d'être connus de toute équipe française. L'article L113-1 pose que la qualité d'auteur appartient, sauf preuve contraire, à celui ou ceux sous le nom de qui l'œuvre est divulguée (Légifrance) : les crédits ne sont donc pas une politesse, ils comptent. Et une œuvre de collaboration est la propriété commune de ses coauteurs, qui exercent leurs droits d'un commun accord (article L113-3), le même article précisant qu'en cas de désaccord, c'est le juge civil qui tranche. Traduction pratique : sans accord écrit, vendre le jeu risque de demander l'accord de tout le monde, y compris de la personne partie fâchée il y a deux ans.
Si le projet a la moindre chance de devenir commercial, faites relire votre page par un professionnel. Ça coûte moins cher qu'une brouille.
Un domaine, un responsable
L'erreur la plus courante dans les petites équipes, c'est le « tout le monde fait tout ». Ça paraît démocratique. En pratique, ça veut dire que personne n'est responsable de rien et que tout le monde a un avis sur tout.
Regarde l'équipe de Celeste, sorti en janvier 2018. D'après sa fiche Wikipédia, Maddy Thorson en assurait la direction et l'écriture, Noel Berry la programmation principale, plusieurs artistes dont Pedro Medeiros les graphismes, Lena Raine l'essentiel de la musique et Kevin Regamey le design sonore. Une petite équipe, des domaines clairs. Tout le monde peut donner son avis sur la musique, mais c'est la compositrice qui tranche sur la musique.
Pour un RPG amateur, une répartition qui marche bien :
| Domaine | Responsable | Il tranche sur… |
|---|---|---|
| Vision et scénario | le ou la scénariste | histoire, personnages, ton |
| Systèmes et équilibrage | le ou la game designer | combats, objets, progression |
| Cartes | un ou une level designer par région | tracé, secrets, rythme |
| Graphismes | l'artiste | style, palette, cohérence |
| Son et musique | le ou la compositrice | ambiances, effets |
| Intégration | une seule personne | ce qui entre dans la version commune |
La dernière ligne est la plus importante, et on en reparle tout de suite.
Les fichiers : qui touche quoi
C'est là que se jouent les pires drames. Deux personnes modifient le même fichier, chacune envoie sa version, et le travail d'une soirée disparaît sans que personne ne comprenne comment.
Un projet au format MV a une structure plutôt favorable au travail à plusieurs : chaque carte est un fichier à part dans le dossier data, les images et les sons vivent dans leurs dossiers. Mais certains fichiers sont partagés par tout le monde, en particulier la base de données (héros, objets, compétences, système). Ce sont eux qui créent les conflits.
Git, ou la machine à remonter le temps
Si l'un de vous est un peu technique, un gestionnaire de versions change la vie. Git a été créé en 2005 par la communauté du noyau Linux, avec Linus Torvalds en figure centrale, et pensé dès le départ pour des milliers de branches de travail en parallèle (Pro Git). Pour un RPG, il apporte trois choses : l'historique de chaque modification, la possibilité de revenir en arrière, et des branches pour essayer une idée sans casser la version commune.
Deux limites à connaître. Les fichiers de données sont du texte, mais deux modifications de la même carte restent pénibles à fusionner : la règle « une carte, un propriétaire » reste valable. Et les gros fichiers binaires, musiques et images, alourdissent vite un dépôt. C'est le rôle de Git LFS, une extension qui remplace ces fichiers par de simples pointeurs et stocke leur contenu sur un serveur à part.
Et dans Makerllo ?
Soyons clairs : un projet en ligne dans Makerllo appartient à un compte, et il n'existe pas d'édition simultanée à plusieurs mains dans l'éditeur. Ce qui existe, et qui sert beaucoup à l'intégrateur, c'est le versionnage. Chaque synchronisation depuis Fichier → Plateforme Makerllo crée une nouvelle version, l'historique des versions permet de rouvrir une ancienne version en copie, et si la version en ligne a changé entre-temps, depuis un autre onglet ou un autre poste par exemple, la synchronisation est refusée au lieu d'écraser quoi que ce soit. L'éditeur sait aussi ouvrir un dossier de projet au format MV présent sur ton disque, ce qui le rend compatible avec un dépôt Git.
Communiquer sans se noyer
Une équipe de RPG amateur n'a pas besoin de réunions. Elle a besoin de rituels courts.
Le plus efficace que je connaisse : un point hebdomadaire de quinze minutes, toujours le même jour. Chacun répond à trois questions. Qu'est-ce que j'ai fini ? Qu'est-ce que je fais cette semaine ? Qu'est-ce qui me bloque ? C'est tout. Les discussions de fond se font après, avec les seules personnes concernées.
Ajoute un tableau de tâches visible par tous, avec trois colonnes : à faire, en cours, fini. Un mur de liège, un tableur partagé ou un outil en ligne, peu importe. Ce qui compte, c'est que chaque tâche ait un nom dessus et que personne n'ait à demander « tu en es où ? ».
Et surtout, jouez ensemble au jeu. Toutes les deux ou trois semaines, une version jouable, et tout le monde y joue. Rien ne réaligne une équipe comme de voir le jeu tourner. Le compositeur entend sa musique sur la vraie carte, la scénariste voit ses dialogues dans les bulles, et les désaccords abstraits deviennent des problèmes concrets.
Se faire des retours sans se blesser
Créer, c'est s'exposer. Quand quelqu'un te dit que ta carte est vide, tu entends parfois que tu es nul. Quelques règles simples évitent les drames.
Commente le travail, jamais la personne. « Ce couloir est long et il ne s'y passe rien » plutôt que « tu fais des couloirs ennuyeux ».
Commence par ce qui marche. Pas par politesse : parce que c'est une information utile. Si tout le monde adore la scène du puits, il faut le dire pour qu'elle ne disparaisse pas à la prochaine refonte.
Décris l'effet, pas la solution. « Je me suis perdu dans la forêt » est un retour précieux. « Mets une flèche » est une solution qui appartient au responsable de la carte. Il en trouvera peut-être une meilleure.
Respecte le dernier mot. Tu as donné ton avis, il a été entendu, la responsable du domaine a tranché. On avance. Si tu ressors le même débat toutes les semaines, la page du début ne sert à rien.
Quand ça coince
Même avec la meilleure organisation, il y aura des tempêtes. Les trois plus fréquentes, et ce qui aide.
Quelqu'un disparaît. Pas de message depuis trois semaines. Commence par prendre des nouvelles, sans reproche : la vie arrive à tout le monde. Puis, s'il faut réorganiser, appuie-toi sur la page du début. C'est exactement pour ça qu'elle existe.
Le projet gonfle. Chaque semaine, une nouvelle idée géniale : un système de cuisine, une deuxième fin, un village de plus. Tenez une liste « pour la version 2 » et notez-y tout ce qui n'était pas dans le pitch. Neuf fois sur dix, personne ne la rouvrira, et c'est très bien comme ça.
Les visions divergent. Parfois, deux personnes veulent vraiment deux jeux différents. Ce n'est pas un échec, c'est une information. Mieux vaut finir un petit jeu commun puis se séparer bons amis que de traîner un projet que plus personne n'aime.
Après la sortie, la guilde continue
Un jeu publié a encore besoin de monde : répondre aux avis, modérer la communauté, regarder ce que font les joueurs. Sur Makerllo, le propriétaire d'un jeu publié peut inviter des membres dans son équipe avec des rôles distincts : manager pour la page, le prix et les versions, modérateur pour les avis et la communauté, analyste pour les statistiques. L'invitation est personnelle et expire au bout de sept jours. Chacun son rôle, encore une fois.
Créer à plusieurs, c'est plus lent au début et plus fragile qu'en solo. Mais quand ça marche, c'est magique. Le jour où tu entendras pour la première fois la musique de ton ami sur la carte que tu as dessinée, pendant que la troisième larronne lit ses dialogues à voix haute avec une voix de dragon ridicule, tu comprendras pourquoi les guildes existent. Et le chat, lui, continuera de dormir au milieu de la carte. Certaines choses ne s'organisent pas.
Sources
- Légifrance, article L113-1 du Code de la propriété intellectuelle
- Légifrance, article L113-3 du Code de la propriété intellectuelle
- Wikipédia, Celeste (jeu vidéo)
- Pro Git, une courte histoire de Git
- Git LFS, site officiel
