Difficultés d'un LLM local avec le Solitaire Unreal Engine : Qwen 3.6-27B brûle 687 000 jetons sur une carte

L'expérience d'un utilisateur Reddit avec des LLM locaux pour le développement de jeux révèle de sévères limitations pratiques. En utilisant Qwen 3.6-27B avec accès à unreal-mcpython, SearXNG et GitHub, la tâche était de créer un jeu de Solitaire dans Unreal Engine. Après quelques heures (beaucoup de temps passé à attendre les réponses de l'utilisateur aux invites), le résultat était une seule carte avec des textures correctes mais aucune logique de jeu, consommant ↑687k et ↓210k tokens.

Interventions manuelles requises

• Téléchargement manuel des PNG avec les faces des cartes
• Création d'un maillage avec 3 matériaux (le cube standard n'a qu'un seul matériau par face)
• Invites constantes comme "arrête d'imaginer, utilise une recherche, bon sang"
• Corrections répétées : "la carte n'a pas de texture" ou "la carte a l'as de pique des deux côtés"

Le problème de la carte recto-verso a consommé la majorité du temps et des tokens. Le cube standard ne peut avoir qu'un seul matériau sur toutes les faces ; un maillage personnalisé avec 3 matériaux est nécessaire. Gemini Flash 3.5 a généré le fichier OBJ correct en une seule tentative, mais Qwen a tourné en rond pendant des heures malgré des exemples de code concrets. Le modèle insistait pour créer des plans, combiner deux plans avec un cube, désactiver le substrat, ou d'autres approches non fonctionnelles. L'utilisateur a finalement dû fournir le maillage manuellement.

Gemma 4-31B a été testé mais n'a pas pu effectuer un appel MCP significatif et a été disqualifié tôt.

Leçon pratique : pour les tâches Unreal Engine impliquant une géométrie personnalisée, les LLM locaux comme Qwen 3.6-27B nécessitent encore un accompagnement important. Les budgets de tokens gonflent rapidement, et les opérations de base sur les maillages restent un obstacle.