Étude de cas

Framework multijoueur & proposition de studio

MESH Interactive

Transformer un partenariat technique réussi en framework multijoueur et en proposition commerciale de studio

Création d’activité, stratégie produit, marque, développement commercial & opérations techniques

Période de participation

Retour au profil Unreal
Session de test d’une expérience multijoueur MESH Interactive

MESH Interactive est né lorsque Raed Abbas et moi avons compris que notre manière de résoudre les problèmes d’intégration et de multijoueur sous Unreal Engine pouvait devenir quelque chose de plus vaste qu’une collaboration unique.

Alors que nous travaillions ensemble sur la conversion multijoueur de Character Interaction, nous avons commencé à imaginer un framework réutilisable plus propre, centré sur la locomotion, l’interaction et une architecture de composants prête pour le multijoueur.

Le 8 décembre 2018, cette idée est devenue explicite.

Le 11 décembre, Raed et moi avons convenu que ce que nous construisions deviendrait une entreprise commune à parts égales.

Deux jours plus tard, j’ai proposé l’identité MESH Interactive et, le 14 décembre, j’ai enregistré meshinteractive.com.

Identifier l’opportunité

L’idée de MESH venait directement de problèmes rencontrés dans de véritables projets sous Unreal Engine.

Les développeurs de jeux avaient accès à des technologies Marketplace de plus en plus sophistiquées.

Un système de locomotion pouvait être excellent.

Un framework d’interaction pouvait être excellent.

Il pouvait en aller de même pour l’inventaire, le combat, les véhicules, l’IA ou les armes.

Le problème apparaissait lorsque quelqu’un essayait de construire un jeu à partir de plusieurs de ces éléments.

Chaque produit avait été conçu selon ses propres hypothèses.

Plusieurs systèmes pouvaient vouloir contrôler le même état du personnage.

Les logiques d’entrée pouvaient entrer en conflit.

Les comportements d’animation pouvaient entrer en conflit.

Les attentes liées au réseau pouvaient différer.

Un framework pouvait même ignorer totalement le multijoueur.

Un développeur pouvait donc posséder toutes les pièces nécessaires et devoir malgré tout consacrer des mois à leur intégration avant qu’elles ne se comportent comme un seul produit.

MESH devait intervenir dans cet espace.

Une fondation réutilisable plutôt qu’une nouvelle intégration isolée

Raed et moi avons commencé à réfléchir à une architecture par composants plus propre, dans laquelle la locomotion et l’interaction pourraient former une fondation multijoueur réutilisable.

Nos échanges ont porté sur les composants réutilisables, une séparation plus claire entre le réseau et les comportements de gameplay, les systèmes de caméra, le trafic réseau et les combinaisons packagées de technologies Marketplace.

L’objectif n’était pas de prétendre que chaque système devait être recréé de zéro.

La proposition était volontairement pragmatique.

Lorsqu’une bonne technologie existait déjà sur la Marketplace, nous pouvions l’intégrer, l’adapter et la répliquer.

Lorsqu’un projet nécessitait une fonction spécifique, nous pouvions concevoir une solution sur mesure autour d’elle.

La valeur résidait dans la capacité à faire fonctionner l’ensemble de manière cohérente.

Les documents de l’époque décrivent MESH comme une entreprise commune à parts égales plutôt que comme une société constituée séparément. Nous avions volontairement prévu de formaliser la structure lorsqu’un contrat rémunéré le rendrait nécessaire.

Construire la proposition

Une fois la décision prise de créer l’activité, je me suis concentré sur la transformation de la capacité technique en une offre que les clients pouvaient comprendre et acheter.

J’ai créé le nom et l’identité visuelle de MESH.

J’ai enregistré le domaine.

J’ai construit le site web et l’infrastructure de messagerie.

J’ai créé le positionnement commercial et les documents de licence.

J’ai mis en place l’environnement Discord.

J’ai travaillé sur la manière de présenter le framework aux studios, investisseurs et partenaires potentiels.

Dans le même temps, Raed poursuivait le développement des démonstrations et des systèmes techniques.

En janvier 2019, nous discutions d’intégrations propres, d’exemples packagés et de démonstrations réutilisables conçues spécifiquement pour montrer le potentiel du framework aux clients éventuels.

C’est l’un des rôles que j’occupe naturellement auprès de spécialistes techniques.

Je ne demande pas seulement : « Qu’avons-nous construit ? »

Je demande : « Quel problème cela résout-il de manière répétée, qui rencontre ce problème, et comment transformer cette capacité en quelque chose que ces personnes peuvent comprendre et acheter ? »

Démontrer l’étendue du framework

Les supports publics de MESH ont fini par montrer un large éventail de domaines de gameplay interconnectés.

Ils comprenaient la locomotion, les sauts intelligents, le placement des pieds par IK, les caméras dynamiques, le ramassage d’objets, la sauvegarde et le chargement, les arbres de talents, les classes de personnages, l’inventaire et l’équipement, les niveaux et les compétences, les véhicules, les systèmes d’interaction, les armes, les lunettes et la balistique, le combat, l’IA, le pillage, ainsi que les modes multijoueur coopératifs et compétitifs.

Cela ne signifiait pas que Raed et moi avions créé indépendamment chaque fonctionnalité sous-jacente.

MESH combinait, intégrait, adaptait et répliquait des systèmes issus de la Marketplace et des systèmes sur mesure.

La proposition reposait sur la couche d’intégration et la fondation technique permettant à ces systèmes de fonctionner ensemble au sein d’une architecture de jeu multijoueur.

Le 21 février 2019, nous avons publié le teaser MESH Interactive.

Une collaboration née autour d’une conversion multijoueur difficile était devenue une proposition de studio identifiable en un peu plus de deux mois.

Confronter la proposition au marché

L’étape suivante consistait à vérifier si des studios accepteraient de la payer.

Une petite demande d’intégration est arrivée peu après le lancement. Nous avons produit une estimation formelle, mais le prospect l’a refusée.

Une opportunité plus importante a suivi en mars.

Le studio potentiel souhaitait combiner plusieurs technologies majeures sous Unreal Engine, notamment Advanced Locomotion System, Survival Game Kit et Character Interaction, dans un jeu multijoueur.

C’était presque exactement le problème pour lequel MESH avait été conçu.

Un accord de confidentialité a été signé et nous avons engagé un processus détaillé de découverte et de cadrage.

Les besoins couvraient les caméras, le comportement des personnages, l’inventaire, les véhicules, les armes, la locomotion, l’interaction, le combat rapproché, le tir à l’arc, les systèmes de lobby et l’architecture multijoueur.

J’ai pris en charge une grande partie du volet commercial : échanges avec le client, recueil des besoins, cadrage, exclusions, méthodes de tarification et traduction du travail technique en mission structurée.

Raed s’est principalement concentré sur les questions techniques spécialisées.

Le client voulait légitimement obtenir la preuve que les éléments difficiles pouvaient être résolus avant de s’engager.

Il fallait notamment démontrer une approche fonctionnelle de caméra véritablement à la première personne.

Nous avons réalisé des prototypes autour de ce besoin, mais la frontière entre démontrer notre capacité et commencer une implémentation non rémunérée est devenue de plus en plus floue.

Le 19 mars, les attentes en matière de périmètre, de prix, de preuve et de livrables avaient suffisamment divergé pour que la mission prenne fin avant tout paiement démontré ou tout travail de production rémunéré.

Comprendre où la découverte technique doit s’arrêter

Cette mission infructueuse est devenue l’une des leçons commerciales les plus utiles de MESH.

Les bonnes équipes techniques veulent naturellement prouver qu’elles savent résoudre le problème.

Les clients potentiels veulent naturellement être rassurés avant d’engager de l’argent.

Sans limites claires, ces deux instincts peuvent créer un piège.

Chaque prototype supplémentaire réduit l’incertitude du client, mais augmente l’investissement non rémunéré du fournisseur.

Chaque réponse technique supplémentaire peut révéler un nouveau besoin à examiner.

À terme, « montrez-nous que vous savez le faire » devient impossible à distinguer du début du projet.

Aujourd’hui, je structurerais ce type de mission différemment.

Les premières discussions serviraient à qualifier l’opportunité.

Tout travail exigeant une architecture, une expérimentation ou un prototype significatif passerait dans une phase de découverte rémunérée.

Cette découverte aurait des livrables et des critères d’acceptation explicites.

La production complète ne commencerait qu’ensuite.

La leçon n’était pas que la proposition MESH était mauvaise.

Elle était qu’une capacité technique spécialisée doit être entourée d’un processus commercial tout aussi solide.

Mon rôle dans MESH

Mon rôle couvrait l’espace entre l’ingénierie et le marché.

J’ai contribué à définir le concept du framework et la direction produit.

J’ai maintenu l’infrastructure de collaboration autour du travail technique.

J’ai créé la marque, l’identité, le site web et la proposition commerciale.

J’ai travaillé à expliquer cette capacité à des personnes qui ne vivaient pas quotidiennement dans les Blueprints d’Unreal Engine.

J’ai identifié des opportunités et échangé avec des clients potentiels.

J’ai dirigé la découverte et aidé à traduire les besoins du jeu en périmètre technique.

J’ai travaillé sur les estimations, les méthodes de réalisation et les structures commerciales.

Pendant toute la collaboration technique, j’ai continué d’utiliser la méthode qui avait fonctionné sur Character Interaction : établir ce qui était connu, remettre les hypothèses en question, préserver les progrès intermédiaires et offrir aux spécialistes assez de structure et d’espace pour résoudre les problèmes les plus difficiles.

Raed apportait une expertise spécialisée plus approfondie en réseau et en réplication.

J’apportais la couche système, produit et commerciale autour de cette expertise.

Cette complémentarité constituait la base de MESH.

Résultat

MESH est resté une initiative relativement courte.

La principale phase de développement et de prospection s’est déroulée en 2019. La collaboration a diminué plus tard dans l’année, le domaine a été annulé en décembre et, en janvier 2020, je parlais déjà de MESH au passé comme de notre marque de « travail en commun ».

Mais MESH a accompli ce qui rend ce projet utile comme étude de cas.

Nous avons compris qu’une expertise développée pour résoudre un problème client difficile pouvait devenir une capacité réutilisable.

Nous avons transformé cette capacité en proposition de framework.

Je l’ai convertie en marque et en offre commerciale.

Nous l’avons démontrée publiquement.

Nous l’avons confrontée à de véritables besoins de studios.

L’expérience a révélé à la fois les forces du modèle technique et les faiblesses de notre approche commerciale initiale de la découverte.

Surtout, MESH a contribué à clarifier un rôle que j’ai continué à jouer dans des projets techniques ultérieurs.

Je suis souvent le plus utile au point de rencontre entre l’ingénierie spécialisée, la réflexion produit et l’opportunité commerciale.

Je peux contribuer à créer l’environnement dans lequel un travail technique difficile réussit, comprendre suffisamment le problème sous-jacent pour remettre les hypothèses en question et coordonner les spécialistes, puis traduire la capacité obtenue en quelque chose que les clients, partenaires ou investisseurs peuvent comprendre.

MESH Interactive a été l’un de mes premiers exemples de ces trois dimensions réunies.

Ouvert aux opportunités

Parlons de votre prochain défi

Discuter d’une opportunité