Retour au Blog

Epic Games va-t-il intégrer le Model Context Protocol (MCP) à UEFN ? La technologie derrière le scripting Verse assisté par IA

Publié le 29 juin 2026
Epic Games va-t-il intégrer le Model Context Protocol (MCP) à UEFN ? La technologie derrière le scripting Verse assisté par IA

En bref

Cette analyse explore l'intégration potentielle du Model Context Protocol (MCP) à UEFN, suite à l'introduction d'un plugin expérimental par Epic Games dans Unreal Engine 5.8. L'article détaille comment combler le context gap local pour le scripting Verse en utilisant ce standard ouvert ou des solutions de contournement manuelles. Enfin, il présente comment des plateformes Backend-as-a-Service comme horizOn exploitent MCP pour unifier la gestion de bases de données et la telemetry avec le code local.

Chaque créateur UEFN connaît la boucle fastidieuse qui consiste à copier les erreurs de compilation Verse depuis le log UEFN, à les coller dans une fenêtre de LLM externe, et à formater manuellement le contexte de leur hiérarchie Scene Graph dans l'espoir que l'IA n'hallucine pas. Parce que les modèles d'IA publics sont entraînés sur des données Unreal Engine obsolètes ou généralistes, ils n'ont pas connaissance de la structure locale de votre projet, de la version exacte de l'API Verse que vous utilisez, ni des configurations de devices définies dans votre éditeur. Ce manque de contexte localisé force les développeurs à agir comme des data pipelines manuels entre leur éditeur et leurs assistants IA, ralentissant ainsi les temps d'itération. Si vous avez passé des heures à diagnostiquer des timeouts au lancement de session UEFN causés par des network drivers Unreal Engine, vous savez à quel point il est pénible de troubleshooter des états de logs locaux sans un assistant capable d'inspecter directement votre environnement.

Le context gap local dans le développement UEFN

Dans le développement logiciel traditionnel, les développeurs utilisent des plugins d'IDE qui indexent l'ensemble de leur codebase, de leurs dépendances et de leurs variables d'environnement. Les assistants de codage IA modernes peuvent référencer des fichiers locaux, lire la structure du projet et même exécuter des tests. Cependant, Unreal Editor for Fortnite (UEFN) fonctionne au sein d'un écosystème fermé et sandboxed. Les créateurs sont limités à ce que UEFN expose : les fichiers Verse, les configurations de devices propriétaires (fichiers .utps) et l'interface visuelle de l'éditeur Unreal.

Cette isolation crée un "context gap" important. Lorsque vous demandez à un assistant IA générique d'écrire un Verse device personnalisé, il n'a aucun moyen de savoir :

  • Quels assets sont enregistrés dans le répertoire Content de votre projet.
  • Les propriétés et événements exacts liés à vos creative devices dans le niveau.
  • Les erreurs de compilation générées par le compilateur Verse lors du dernier build.
  • La relation entre votre code Verse personnalisé et la hiérarchie visuelle du Scene Graph.

En conséquence, les outils d'IA peinent à fournir des réponses précises. Ils suggèrent fréquemment des fonctions C++ indisponibles en Verse, font référence à des signatures d'API obsolètes, ou génèrent une logique qui échoue à la compilation. Le développeur se retrouve contraint de copier, coller, corriger et répéter — un workflow qui dégrade la productivité et introduit des bugs subtils.

Qu'est-ce que le Model Context Protocol (MCP) ?

Le Model Context Protocol (MCP) est un standard ouvert conçu pour résoudre précisément ce problème. Développé pour établir une interface sécurisée et standardisée entre les modèles d'IA et les ressources locales, MCP agit comme une API gateway entre les LLMs et les outils de développement. Plutôt que de s'en remettre au copier-coller manuel, MCP permet à un assistant IA de se connecter de manière sécurisée à un serveur local s'exécutant dans votre environnement.

┌─────────────────┐       JSON-RPC        ┌────────────────┐
│   AI Client     │ <───────────────────> │   MCP Server   │
│ (Claude, IDE)   │                       │ (Unreal/UEFN)  │
└─────────────────┘                       └────────┬───────┘
                                                   │ Exposes
                                                   ▼
                                          ┌────────────────┐
                                          │  Local Files   │
                                          │  Editor Logs   │
                                          │  Scene Graph   │
                                          └────────────────┘

Le protocole fonctionne sur une architecture Client-Serveur simple :

  1. L'Hôte/Client : Une application d'IA (comme un assistant desktop ou une extension d'IDE) qui orchestre l'interaction avec le développeur.
  2. Le Serveur : Un processus local s'exécutant sur la machine du développeur qui expose des outils, des ressources et des prompts.
  3. La Transport Layer : La communication s'effectue via des protocoles standards tels que Server-Sent Events (SSE) ou Standard Input/Output (stdio), en utilisant des messages JSON-RPC.

Voici un payload JSON-RPC simplifié montrant comment un client d'IA interroge un serveur MCP local pour récupérer le contexte d'un fichier Verse local :

{
  "jsonrpc": "2.0",
  "method": "resources/read",
  "params": {
    "uri": "file:///C:/Users/Developer/Documents/FortniteProjects/MyIsland/Plugins/MyIsland/Content/game_manager.verse"
  },
  "id": 1
}

Le serveur MCP local répond avec le contenu réel du fichier Verse, permettant au LLM d'inspecter la structure exacte du script sans aucune action de copier-coller.

Le plugin MCP expérimental d'Unreal Engine 5.8

Avec la sortie d'Unreal Engine 5.8, Epic Games a introduit un plugin MCP expérimental. Ce plugin permet à l'Unreal Editor d'héberger un serveur MCP interne, exposant les sous-systèmes clés du moteur à des outils d'IA externes. En connectant les APIs C++ et Python de l'éditeur au Model Context Protocol, Epic a posé les bases d'une nouvelle génération de workflows de développement de jeux assistés par IA.

Le serveur MCP expérimental d'UE 5.8 expose plusieurs capacités clés :

  • Asset Registry Querying : Les assistants IA peuvent rechercher dans les assets du projet, identifier les textures inutilisées, vérifier les paramètres de LOD des meshes et inspecter les instances de matériaux.
  • Log Querying : L'assistant peut lire les logs de sortie, capturer les erreurs de compilation de Blueprints et tracer les avertissements au runtime.
  • Python Execution : Comme Unreal Engine intègre une interface de scripting Python, le serveur MCP peut exécuter des tâches automatisées de l'éditeur, comme renommer des assets pour respecter les style guides ou placer des actors dans le niveau.
  • Blueprint Inspection : Le serveur permet au modèle d'inspecter les nœuds et les connexions des Blueprints, réduisant ainsi le besoin pour les développeurs de faire des captures d'écran de leurs configurations de visual scripting.

Cette intégration représente un bond en avant massif pour les développeurs Unreal Engine, mais elle pousse les créateurs UEFN à se demander : quand cette technologie arrivera-t-elle dans Fortnite Creative ?

Pourquoi UEFN et Verse ont cruellement besoin du support MCP

Apporter le support MCP à UEFN n'est pas seulement une question de confort — c'est une nécessité technique. Contrairement aux projets Unreal Engine standards qui supportent les plugins C++, les utilitaires d'éditeur personnalisés et le scripting Python, UEFN restreint les créateurs à un environnement étroitement contrôlé. Cela rend impossible pour les créateurs d'écrire leurs propres serveurs MCP personnalisés pour combler le fossé. Epic Games doit implémenter ce support nativement.

Si Epic Games intègre le plugin MCP d'UE 5.8 à UEFN, les avantages transformeraient le scripting Verse, la configuration de devices et l'organisation des scènes :

1. Un scripting Verse pleinement conscient du contexte

Plutôt que d'halluciner du code, un assistant connecté en MCP lirait vos fichiers sources .verse locaux et les définitions d'API locales. Il saurait exactement quels modules sont importés, quelles classes sont définies et quelles méthodes sont disponibles.

Lors de la rédaction d'une logique Verse complexe, comme un gestionnaire de telemetry personnalisé, l'IA peut s'assurer que toutes les signatures de méthodes sont valides. Par exemple, les développeurs se heurtent fréquemment à des limitations strictes lors de la création de systèmes de telemetry personnalisés, tels que la limite de 32 caractères pour le nom d'événement des appareils d'analytics en Verse. Un serveur MCP local permettrait à l'assistant IA d'inspecter vos noms d'événements, de vérifier qu'ils ne dépassent pas 32 caractères et de refactoriser automatiquement le code pour éviter des pertes de telemetry silencieuses en production.

Voici un exemple de script Verse syntaxiquement correct et conscient du contexte, qui gère la telemetry et interagit avec les creative devices. Un serveur MCP lirait ce fichier et comprendrait instantanément les signatures de classes personnalisées :

using { /Fortnite.com/Devices }
using { /Fortnite.com/Characters }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

# Custom telemetry manager that coordinates player state updates
telemetry_coordinator_device := class(creative_device):

    @editable
    ItemGranter : item_granter_device = item_granter_device{}

    @editable
    LogVerbosity : string = "Verbose"

    # Internal map tracking active player scores
    var PlayerScoreMap : [player]int = map{}

    # Initialize listeners on game start
    OnBegin<override>()<suspends> : void =
        GetPlayspace().PlayerAddedEvent().Subscribe(OnPlayerAdded)
        GetPlayspace().PlayerRemovedEvent().Subscribe(OnPlayerRemoved)
        Print("Telemetry Coordinator Device Started.")

    # Executed when a player joins the match
    OnPlayerAdded(Player : player) : void =
        if (not PlayerScoreMap[Player]):
            if (set PlayerScoreMap[Player] = 0):
                Print("Tracking initialized for player.")

    # Executed when a player exits the session
    OnPlayerRemoved(Player : player) : void =
        if (Score := PlayerScoreMap[Player]):
            Print("Player disconnected. Final recorded score: {Score}")
            # Dispatch event to backend metrics aggregator
            DispatchTelemetryPayload(Player, Score)

    # Internal function to handle data dispatching
    DispatchTelemetryPayload(Player : player, Score : int) : void =
        # An MCP assistant can check that the payload conforms to the backend API schema
        Print("Dispatching telemetry payload for score: {Score}")

2. Alignement du Scene Graph et des Creative Devices

La nouvelle architecture Scene Graph dans UEFN définit les jeux à l'aide d'entités et de composants. Gérer ces configurations visuellement dans l'éditeur tout en écrivant des scripts Verse qui y font référence crée des défis de coordination.

Un serveur MCP exposerait la hiérarchie du Scene Graph à votre client IA. Le modèle pourrait lire vos configurations d'entités, identifier les écouteurs d'événements non liés, vérifier si un device manque d'une référence critique (comme un item_granter_device manquant dans les propriétés @editable), et corriger les incohérences.

3. Diagnostics d'erreurs automatisés

Lorsqu'une compilation Verse échoue, UEFN génère des logs d'erreurs détaillés dans la console de sortie. Un client MCP pourrait capturer automatiquement ces logs d'erreurs, les corréler avec les fichiers .verse actifs et présenter le code corrigé directement dans votre IDE, sans que vous ayez besoin de changer de fenêtre ou de lire manuellement des stack traces.

Le défi du Backend : relier les éditeurs locaux aux services Live

Bien que le support MCP dans UEFN résoudrait le context gap de l'éditeur local, les développeurs de jeux font face à un obstacle encore plus grand : connecter leur environnement de développement local avec des backends de jeux en production. Dans les jeux Fortnite Creative modernes, la persistance est primordiale. Pour créer des RPG persistants, des tycoon games ou des shooters basés sur le Matchmaking, vous devez stocker la progression des joueurs, gérer des inventaires dynamiques et suivre les économies virtuelles.

Créer et maintenir ces systèmes manuellement nécessite un travail d'infrastructure colossal :

  1. Intégration d'API : Écrire des gestionnaires de requêtes HTTP personnalisés en Verse pour interagir avec des bases de données externes.
  2. Mocking local : Créer et exécuter des serveurs de mock locaux pour tester les interactions Backend avant le déploiement.
  3. Maintenance de base de données : Concevoir les schémas de base de données, gérer la sérialisation des données des joueurs et configurer les serveurs pour absorber les pics de charge des joueurs.
  4. Sécurité et validation : Implémenter l'authentification, s'assurer que les requêtes clients ne peuvent pas altérer les valeurs de la base de données, et configurer les certificats SSL.

Configurer manuellement cette infrastructure Backend — gérer les load balancers, le sharding de base de données, les endpoints d'API et la synchronisation d'état en temps réel — peut facilement prendre 4 à 6 semaines de travail d'ingénierie dédié. Pour les créateurs solo ou les équipes indépendantes, c'est du temps volé au game design, au Level Design et au marketing.

C'est là que horizOn propose une alternative fluide et prête à l'emploi. En tant que Backend-as-a-Service de jeu dédié, la plateforme offre un support out-of-the-box pour la gestion de bases de données, les profils de joueurs et la telemetry. Elle fournit des endpoints de Backend préconfigurés qui s'intègrent dans votre logique de jeu, vous permettant de gérer l'intégralité de l'état de votre base de données sans écrire une seule ligne de code serveur backend.

De plus, horizOn tire pleinement parti de la puissance de MCP. En fournissant des serveurs MCP personnalisés pour l'administration de bases de données de jeux, horizOn permet à vos assistants IA d'inspecter vos schémas de base de données en production, d'exécuter des requêtes et d'optimiser les tables directement depuis votre éditeur. Cela signifie que votre agent IA bénéficie d'une visibilité totale tant sur votre code frontend Verse local que sur votre base de données Backend en production, garantissant que tout code généré soit parfaitement aligné avec vos structures de données réelles.

Bonnes pratiques concrètes pour les créateurs UEFN d'aujourd'hui

En attendant qu'Epic Games propose un support MCP natif pour UEFN, les développeurs doivent trouver des moyens d'optimiser leurs workflows manuellement. Voici quatre bonnes pratiques concrètes que vous pouvez appliquer aujourd'hui pour combler le context gap et rationaliser votre développement Verse :

1. Maintenir un fichier de contexte LLM dédié

Étant donné que les outils d'IA externes ne peuvent pas scanner votre répertoire UEFN, vous devriez maintenir un unique fichier texte (par exemple, workspace_context.prompt) à la racine de votre projet. Utilisez-le pour suivre :

  • La version exacte de l'API Verse que vous utilisez.
  • Une liste de tous les creative devices actifs dans votre niveau principal.
  • La structure et les signatures de types de vos classes Verse personnalisées.
  • Un résumé des connexions @editable actives.

Lorsque vous lancez une conversation avec votre assistant IA, collez d'abord ce fichier. Cela agit comme une ressource MCP statique et manuelle, fournissant au modèle le contexte exact dont il a besoin pour éviter d'halluciner des APIs.

2. Rationaliser les logs de compilation Verse

Au lieu de copier les erreurs du compilateur, vous pouvez créer un script local qui surveille le log de sortie du compilateur Verse d'UEFN. À l'aide d'une commande de terminal, vous pouvez parser le fichier de log et extraire uniquement les erreurs et les numéros de lignes pertinents. Cela permet de copier plus facilement un extrait de log propre et condensé plutôt qu'un mur d'avertissements redondants.

3. Imposer des règles strictes de nommage des événements et des devices

Pour éviter les désynchronisations et la rupture des références de devices, établissez une convention de nommage stricte pour vos devices et votre code Verse. Par exemple, si un device est nommé VendingMachine_01 dans l'éditeur, sa variable Verse correspondante devrait être VendingMachine01. Cette cohérence visuelle vous aide à vérifier rapidement les liaisons et facilite le partage manuel de contexte avec les modèles d'IA. De plus, pensez à garder les noms d'événements sous la limite des 32 caractères pour éviter les pertes de telemetry silencieuses.

4. Créer un mock HTTP server local

Lors du développement de systèmes Backend, ne testez pas directement sur votre base de données de production lors du prototypage initial. Configurez un simple mock HTTP server local avec Node.js ou Python pour simuler les réponses du Backend. Cela vous permet de tester localement vos requêtes HTTP Verse, d'exécuter des mock queries et de valider le parsing JSON sans subir de latence réseau ni risquer de corrompre les données réelles.

Perspectives : l'avenir de la création de jeux assistée par IA

L'introduction du support du Model Context Protocol dans Unreal Engine 5.8 est une étape majeure vers la modernisation des workflows de développement de jeux. En permettant aux modèles d'IA de comprendre le contexte de l'éditeur, Epic Games montre à l'industrie comment l'IA peut être intégrée comme un outil collaboratif plutôt que comme un simple générateur de texte générique.

Pour les créateurs UEFN, un support MCP natif abaisserait la barrière à l'entrée pour le scripting Verse, simplifierait le routing des devices et accélérerait le débogage. En attendant qu'Epic apporte ce plugin à l'écosystème Fortnite, les développeurs peuvent utiliser des fichiers de contexte structurés, des logs automatisés et des plateformes Backend externes pour combler le fossé.

Prêt à scaler votre Backend Multiplayer ? Essayez horizOn gratuitement ou consultez la documentation de l'API pour voir comment nous simplifions l'administration de bases de données et la telemetry pour les développeurs de jeux modernes.


Source : Bring Unreal Engine 5.8 MCP Support to UEFN