Tester : l’IA qui teste votre map Fortnite avec des preuves

Tester votre map Fortnite avec l’IA

Le Tester reproduit les bugs, conçoit et lance les vérifications disponibles, rédige des cas de test ciblés et signale les régressions. Il examine aussi le câblage des devices, les calculs du gameplay et la couverture des playtests de votre projet UEFN (Unreal Editor for Fortnite).

Il part toujours d’un énoncé précis : préconditions, étapes, nombre de joueurs et résultat attendu. Puis il inspecte les fichiers concernés, la configuration et le catalogue réel d’outils de l’éditeur. Un serveur connecté ne veut pas dire qu’un simulateur ou un lanceur de tests existe : il vérifie avant de choisir sa méthode.

Comment il travaille

Il choisit la plus petite vérification qui répond à la question, et garde séparés les niveaux de preuve :

• Inspection statique des fichiers et de la configuration ;
• Diagnostics du compilateur, par BuildAll quand l’éditeur l’expose ;
• Test automatisé découvert, lancé seulement par un outil au contrat connu ;
• Propriétés et câblage des devices relus dans l’éditeur ;
• Session client observée, quand elle est accessible.

Il couvre l’échec signalé et ses cas limites : évènements en double, valeurs à zéro ou au maximum, arrivée et départ, réapparition, réinitialisation, plusieurs joueurs. Il note pour chaque vérification la valeur attendue, la valeur obtenue, la sortie de l’outil et le fichier ou l’asset concerné. Après une correction, il relance le test qui échouait et la plus petite vérification de régression utile.

Quand vous l’autorisez, il crée ou ajuste des fichiers de test ciblés, chaque écriture passant par votre approbation. Il travaille en duo avec le Verse Coder, qui corrige, et le Reviewer, qui relit sans rien modifier. L’orchestrateur peut lui confier la partie vérification d’un plan.

Exemples de demandes

• Écris la checklist de test d’un achat dans la boutique.
• Les pièces sont parfois comptées deux fois : reproduis le bug et trouve d’où il vient.
• Vérifie que les boutons d’amélioration sont bien reliés à la boutique.
• Contrôle le calcul des récompenses à zéro pièce et au maximum.
• Après la correction du Verse Coder, relance le test qui échouait.

Outils et connexions

Connexions

UEFN, Blender (facultatif)

Compilation

BuildAll par le MCP de UEFN, quand l’éditeur l’expose

Fichiers

fichiers de test ciblés, sur autorisation

Skills de départ

pilot-testing, pilot-qa

Verdicts

PASS, FAIL ou NOT RUN pour chaque vérification

Limites

Aucun moteur de simulation ni playtest automatique n’est supposé disponible. Un outil manquant ou un gameplay inaccessible donne NOT RUN, jamais PASS. Le Tester n’annonce ni simulation hors ligne, ni couverture complète, ni mesure de performance, ni playtest à partir de la seule lecture du code. Il ne refactorise pas la logique de production en silence, ne change pas les réglages du projet et ne dépense pas de crédits de génération pour fabriquer un test.

Pour voir comment il s’intègre à l’équipe, consultez l’équipe d’agents IA, puis les tarifs.

Questions fréquentes

Peut-il jouer à ma map à ma place ?

Non, il n’y a pas de playtest automatique. Il observe une session client seulement si elle lui est accessible ; sinon, la vérification est marquée NOT RUN et il vous dit précisément quoi tester vous-même.

Que signifient PASS, FAIL et NOT RUN ?

PASS : la vérification a eu lieu et le résultat est conforme. FAIL : elle a eu lieu et le résultat diffère, preuves à l’appui. NOT RUN : elle n’a pas pu avoir lieu, avec la raison exacte.

Peut-il corriger le bug lui-même ?

Son rôle est de prouver. Il peut écrire des fichiers de test ciblés sur autorisation, mais la correction de la logique revient au Verse Coder ; il relance ensuite le test pour confirmer.