Je vais essayer de faire le plus court et le plus clair possible. Tout ce qui va vous être présenté dans ce post est une expérience à (je l'espère) grande échelle de la mise en application de systèmes organisationnels démocratiques dans l'univers du gamedev.
Contexte & Génèse
Je suis data scientist spécialisé dans le traitement automatique de la langue, directeur technique dans une start-up nantaise et je développe en freelance pour des entreprises en France, des solutions mobiles et web. J'ai travaillé auparavant en tant que lead dev pour un petit studio Nantais qui a sorti en tout et pour tout 3 petits jeux vidéos. Passionné par les MMORPG depuis ma plus tendre enfance, j'ai passé une quantité de temps astronomique sur Dofus et WoW. J'ai toujours rêvé de développer mon propre MMO mais de toute évidence seul, c'était impossible, sans expérience, pareil. Et clairement, entre nous, quand + de 90% des projets de jeux vidéo ne voient pas le jour comment être motivé pour développer l'un des types de jeux où à peine 1% des équipes qui se lancent finissent par sortir quelque chose ? (d'où je sors ces chiffres ? de nul part c'est exact). J'ai donc décidé de me former au management, au développement de jeux vidéo, à l'IA et tout plein de choses qui me semblaient pertinentes. Je n'avais qu'une idée en tête créer un jour mon propre jeu, c'est faux, complètement faux, j'ai été complètement démotivé et finalement j'ai abandonné l'idée mais tout ce que j'ai raconté avant reste vrai. Fin du premier acte. Entracte.
Bercé par l'idéologie libertaire et ayant travaillé dans plusieurs entreprises très hiérarchiques, basées sur des principes profondément anti-démocratiques (le salarié est un exécutant répondant à un besoin industriel dicté par le désir d'une poignée de personnes), je me suis dit que ça pouvait être extrêmement intéressant de créer un projet de développement de jeux vidéo qui se démarque par son organisation et son processus créatif. Alors j'ai imaginé Souflos. Permettez moi, je vous prie, de vous raconter un peu ce que j'ai imaginé pour ce projet.
Organisation
Outils
Toute l'organisation du projet réside en l'usage de ces 3 technologies :
Jira by Atlassian --> Pour la gestion scrum de la partie développement
Unity --> Pour le développement du jeu
Discord --> Pour les votes, les attributions de rôles, les discussions, débats, les propositions
Souflos est un jeu où les règles, les quêtes, l’univers graphique et sonore, sont voué à évoluer. En effet, les joueurs proposent leurs idées pour faire évoluer le jeu.
Schéma 1 : Arbre décisionnel lorsqu’un joueur propose une nouvel idée à implanter dans le jeu
Rôles
Modérateur IG / Modérateur Discord : Élu.e.s par un vote
Game Designer en 3 niveaux d'expériences.
Level Designer en 3 niveaux d'expériences.
Content Creator en 3 niveaux d'expériences. Comme son nom l'indique, ce rôle consiste en la création de contenu pour le jeu : des quêtes, des ressources, des histoires, des panoplies, des events, etc.
Game Artist en 3 niveaux d'expériences. Pareil. Ce rôle consiste en la création de ressources graphiques pour le jeu.
Le premier niveau est automatique, vous pouvez vous le définir. Les suivants s'obtiennent en participant activement aux discussions et en faisant des propositions qui sont votés "Pour" à la majorité. Le dernier niveau vous profère la possibilité de générer des votes pour certaines propositions. La communauté a estimé par le vote que vous êtes un allié compétant et elle vous fait confiance.
État du projet
Et bien j'ai une bonne nouvelle, le jeu est déjà jouable avec :
Un système de quêtes
Un système d'hôtel de vente
Un système d'échange
Une monnaie
Des monstres
Des PNJs
Des objets, ressources, consommables, équipements
Système de craft
Combat
Récolte
Une UI Mobile Friendly
Connexion
Création de compte
Inventaire
etc
Le projet a d'ors et déjà un partenaire sur le long terme qui nous fournis gratuitement un serveur suffisant pour les débuts :
32 Go de RAM
150 Go SSD
8 Cores 3.7Ghz
Ubuntu 18.04
Un jira encore un peu vide à l'heure où j'écris ce post
Un discord qui n'attends plus que vous
Business Model
Le jeu sera free-to-play. Un jeu gratuit ça n'existe pas. N’oubliez pas que si quelque chose est gratuit, alors c'est vous le produit. Vos données ne seront pas collectées donc pas revendues. Pas de publicités. Le free-to-play s'orientera autour d'une boutique (déjà développée)
Cette boutique convertir de l'argent en Brise pour pouvoir acheter des objets consommables, équipement, monture ou en Souflos (monnaie locale).
Pour les débuts, les éventuels frais seront pris en charge par mon entreprise.
Quelques images
Ok je suis intéressé.e, je fais quoi ?
Plusieurs scénarios sont possibles :
Tu souhaites simplement suivre l'avancement du projet, sans forcément y participer. Rdv sur le serveur discord
Tu souhaites rejoindre le projet et t'investir dans un ou plusieurs pôles. Rdv sur le serveur discord, go dans le channel "#rôles", prend un ou plusieurs rôles et fait toi entendre dans les salons adaptés.
Tu souhaites jouer au jeu. Rdv dans quelques semaines / mois, et dans quelques jours sur le site web pour en savoir plus
J'espère que ce projet fera écho dans la communauté et que l'idée vous plaît. Si vous avez des conseils, de suggestions ou si vous avez envie d'apporter une critique constructive à ce projet, n'hésitez pas à commenter ou à venir discuter sur le discord. Pour les Nantais et Nantaises, si l'envie d'en discuter autour d'un verre vous prend, n'hésitez pas à me contacter également !
Ton pipeline décisionnel de feature n'est pas très différent de ce qui se fait usuellement en open source, d'ailleurs Jira intègre nativement un système de vote pour ses tickets.
La seule différence c'est que c'est X qui va créer le ticket au lieu que ce soit fait à posteriori.
Ce système à l'avantage, par rapport au tien qu'il permet de centraliser toutes les propositions, acceptées ou pas, avec le canal de discussion qui décrit leur acceptation ou leur rejet.
Egalement, les votes peuvent évoluer au fil du temps, un proposition peut ne pas être intéressante à l'instant T et recueillir peu de vote et le devenir 1 an plus tard parce que le marché ou l'écosystème à changé et recevoir un vote de masse à ce moment là, ça permet donc une plus grande souplesse.
Le choix de Jira est pertinent, si ton projet est open source, tu peux bénéficier d'une instance cloud ou on premise offerte par Atlassian (de même qu'un confluence, bitbucket ou la plupart des outils de leur stack)
Ton pipeline décisionnel de feature n'est pas très différent de ce qui se fait usuellement en open source, d'ailleurs Jira intègre nativement un système de vote pour ses tickets.
La seule différence c'est que c'est X qui va créer le ticket au lieu que ce soit fait à posteriori.
Ce système à l'avantage, par rapport au tien qu'il permet de centraliser toutes les propositions, acceptées ou pas, avec le canal de discussion qui décrit leur acceptation ou leur rejet.
Egalement, les votes peuvent évoluer au fil du temps, un proposition peut ne pas être intéressante à l'instant T et recueillir peu de vote et le devenir 1 an plus tard parce que le marché ou l'écosystème à changé et recevoir un vote de masse à ce moment là, ça permet donc une plus grande souplesse.
Le choix de Jira est pertinent, si ton projet est open source, tu peux bénéficier d'une instance cloud ou on premise offerte par Atlassian (de même qu'un confluence, bitbucket ou la plupart des outils de leur stack)
Je pense que tu l'as saisi, je suis issu de la communauté du logiciel libre donc tout cela est vachement inspiré.
Concernant la centralisation, ton retour est particulièrement pertinent. J'avais connaissance du système par vote de Jira mais c'est un outil encore assez peu maîtrisé contre discord qui peut aussi centraliser en ayant un système de logs des votes. Ici il n'est pas tellement question de vote pour un ticket qui est sensé représenté une tâche de développement atomique sur le projet mais voter pour une idée, un concept, une features donc c'est peut-être pas plus mal d'user de discord, qu'en penses-tu ?
Pour ton dernier point, je possède une licence Jira + Confluence pour des besoins industriels privé donc j'autohost.
J'aimerai bien rendre le code open source mais est-ce qu'ici ça a vraiment du sens ? Le développement ne sera pas participatif dans un premier temps. Il me semble dangereux de publier le code source du serveur également ? Après je me dis que plus il y aura de personnes pour voir le code, moins il y aura de failles ou erreur de programmation, mais je ne sais pas si dans mon cas le bénéfice est plus grand. En tout cas c'est en questionnement et y'a des chances que si le projet devient participatif sur le développement le code source s'en verra publié.
Dans Jira tu as les 'epic' pour représenter une feature importante en terme de travail, et tu as aussi les sub-task, pour découper atomiquement les tâches de dev.
Les subtask sont pratiques dans le sens où quand on défini une feature d'un point de vue business/fonctionnel, on a pas encore toute la vue sur les tâches de dev, et donc on peut rajouter des subtask au cours du développement pour tous les imprévus.
A mon sens Discord est très bien pour discuter de la feature, et aussi des points techniques, mais Jira est le bon endroit pour centraliser les décisions prises suite à ces discussions, chez nous au boulot les devs utilisent aussi un chat(j'ai oublié le nom par contre) pour communiquer entre eux et jira pour recenser les features/taches.
Pour l'open source, tu peux par exemple mettre tes librairies en open, et garder tes apps en closed, c'est ce que je fais, j'ai un peu plus de 200 libs sous licence MIT pour mon framework de jeux/multimedia et une 15aine en fermé qui sont les applications reposant sur ce framework.
Dans Jira tu as les 'epic' pour représenter une feature importante en terme de travail, et tu as aussi les sub-task, pour découper atomiquement les tâches de dev.
Les subtask sont pratiques dans le sens où quand on défini une feature d'un point de vue business/fonctionnel, on a pas encore toute la vue sur les tâches de dev, et donc on peut rajouter des subtask au cours du développement pour tous les imprévus.
A mon sens Discord est très bien pour discuter de la feature, et aussi des points techniques, mais Jira est le bon endroit pour centraliser les décisions prises suite à ces discussions, chez nous au boulot les devs utilisent aussi un chat(j'ai oublié le nom par contre) pour communiquer entre eux et jira pour recenser les features/taches.
Pour l'open source, tu peux par exemple mettre tes librairies en open, et garder tes apps en closed, c'est ce que je fais, j'ai un peu plus de 200 libs sous licence MIT pour mon framework de jeux/multimedia et une 15aine en fermé qui sont les applications reposant sur ce framework.
Super et bien ça sera voté, je ne me porte pas en décisionnaire unique ^-^ Concernant l'open source, je pense que c'est ce que je vais faire tu as raison c'est très pertinent ce que tu proposes ! Merci beaucoup. Hésite pas à passer faire un coucou sur le discord
* Amélioration de la rapidité de réponse du serveur
* Affichage amélioré pour les mobiles 720p
Quelques images
UI Statistiques du personnage
UI Hôtel de vente
Les champs aux alentours
N'oubliez pas que c'est grâce à notre communauté que nous faisons ce jeu ! Nous sommes près de 50 sur notre serveur discord. N'hésitez pas à nous rejoindre ici https://discord.com/Q3cCgRB
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
Sylvain GARCIA - www.necatis.fr - NECATIS SASU 2018-2020