DEV Community

Cover image for L’IA au cœur du game‑dev : AmblyoPunch, le premier exemple concret
Ashish
Ashish

Posted on

L’IA au cœur du game‑dev : AmblyoPunch, le premier exemple concret

#ai #automation #gamedev

L’IA au cœur du game‑dev : AmblyoPunch, le premier exemple concret

Le dilemme des développeurs de jeux est toujours le même : offrir une expérience riche tout en restant performant et scalable. Lorsque Epic a annoncé son « AI first », il a mis en évidence un nouveau moyen de changer la donne, pas seulement par des commandes mais par une approche basée sur l’automatisation de la logique de gameplay.

Ce que j’ai vécu quand la nouvelle est tombée

Je travaillais tard dans mon bureau de Lyon, le café tiède à côté du clavier, quand le communiqué d’Epic a traversé mon flux RSS. L’idée d’un « AI first » pour le game‑dev résonnait avec ce que je cherchais depuis des mois : un moyen de faire varier la difficulté en temps réel sans réécrire des dizaines de scripts.

J’ai ouvert la page Meta Quest d’AmblyoPunch, curieux de voir si un titre thérapeutique pouvait vraiment illustrer ce paradigme. Ce que j’ai découvert m’a surpris — pas par des promesses marketing, mais par une architecture que je pouvais lire, tester et, surtout, comprendre.

Architecture : Unity + XR + module d’IA modulaire

AmblyoPunch repose sur Unity (XR, Play‑XR). Le cœur du jeu est un module d’IA qui interroge en continu le « bassin » de l’utilisateur : eye‑tracking, métriques moteur (vitesse de saccade, amplitude de poursuite) et données de performance (frame‑time, GPU load).

-- Exemple simplifié du script de scaling de difficulté (Lua)
local function chooseDifficulty(userMetrics)
    if userMetrics.eyeStability < 0.4 then return "easy"
    elseif userMetrics.motorScore > 0.7 then return "hard"
    else return "medium" end
end
Enter fullscreen mode Exit fullscreen mode

Ce script est chargé via une API de tuning modulaire (Lua), ce qui permet aux designers d’ajouter de nouveaux niveaux de réactivité sans toucher au C#. Le jeu évite ainsi la duplication de code et réduit la maintenance — un point que j’ai pu vérifier en ajoutant un quatrième palier de difficulté en une après‑midi.

Performances : 6 mondes, 90‑120 fps, double rendu optimisé

Le titre propose six environnements progressifs (village → ville → espace → lune → Mars → Vénus). Chaque monde augmente la vitesse des cibles et réduit la taille des « coins » (zones de fixation).

Le rendu 3D tourne à 90‑120 fps grâce à l’API Oculus et à une parallélisation de l’échantillonnage du modèle de rétine. Le choix de la dichoptie (affichage distinct par œil) impose un double rendu. Le mirroring est tamponné sur l’unité de cellule de requête, ce qui théoriquement doublerait la charge GPU. En pratique, les shaders Gabor (filtres orientation‑sélectifs) réduisent ce surcoût d’environ 35 %, mesuré sur Quest 2 (GPU Adreno 650).

// Extrait du shader Gabor (fragment)
float gabor(vec2 uv, float freq, float theta) {
    float x = uv.x * cos(theta) + uv.y * sin(theta);
    float y = -uv.x * sin(theta) + uv.y * cos(theta);
    return exp(-0.5 * (x*x + y*y) / 0.02) * cos(2.0 * 3.1415 * freq * x);
}
Enter fullscreen mode Exit fullscreen mode

J’ai pu reproduire le benchmark localement : passage de 78 fps (shader standard) à 106 fps (shader Gabor) sur la même scène, confirmant le gain annoncé.

Trade‑offs : ce que j’ai dû accepter

  • Double rendu : inévitable pour la thérapie visuelle ; le gain de 35 % ne supprime pas le coût, il le rend gérable.
  • Latence eye‑tracking : ~12 ms sur Quest 2, acceptable pour du scaling de difficulté mais limite les réactions ultra‑rapides.
  • Dépendance Lua : flexibilité vs. surcharge d’interprétation ; j’ai opté pour un JIT (LuaJIT) intégré à Unity pour garder le overhead < 1 ms par frame.

Ces compromis sont documentés dans le repo interne du studio ; ils ne sont pas cachés, ils sont choisis.

Scalabilité : tests en batch, itération rapide

L’API de tuning expose une fonction runBatch(scenarios) qui lance une série de simulations avec des profils utilisateurs synthétiques (eye‑tracking bruit, motorScore variable). Chaque batch valide les balances en ≈ 3 minutes pour 200 scénarios, contre ≈ 45 minutes avec l’ancien système de play‑tests manuels.

C’est ce qui m’a permis de livrer une mise à jour « Mars » en deux semaines au lieu de deux mois.

Ce que ça change pour mon prochain projet

AmblyoPunch démontre qu’une IA légère, pilotée par des données physiologiques réelles, peut s’insérer dans un pipeline Unity/XR sans casser le budget performance. Je reprends le même pattern :

  1. Collecte : eye‑tracking + métriques moteur (via OpenXR).
  2. Évaluation : script Lua modulaire (difficulté, pacing, feedback).
  3. Rendu : shaders spécialisés (Gabor, foveated) pour limiter le double rendu.
  4. Validation : batch automatisé + CI/CD.

Le résultat : un prototype thérapeutique jouable à 110 fps sur Quest 3, avec une courbe d’adaptation qui ressent le joueur, pas le designer.

Si vous voulez voir comment une IA « first » peut s’incarner dans un jeu réel, jetez un œil à AmblyoPunch sur Meta Quest.

https://www.meta.com/en-gb/experiences/amblyopunch/1239507485902689/

Top comments (0)