DeepSeek V4 : optimiser la génération de jeux avec IA à petit budget

Des modèles abordables peuvent-ils créer des jeux sur navigateur auxquels les gens ont réellement envie de jouer ? Au cours de la dernière semaine, nous avons exploré cette question dans OpenGame Studio. La dernière nouveauté est DeepSeek-V4.1-Flash-1017, la version du 17 octobre de la famille DeepSeek V4.

Nous avons aussi testé Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash et Claude Haiku 5.5. L'objectif était d'améliorer l'équilibre entre le coût de génération, le temps d'attente, le comportement jouable et la qualité visuelle. Un jeu qui s'ouvre correctement peut tout de même aller à droite lorsque le joueur appuie sur gauche, attribuer des pièces trop tôt ou continuer à tomber pendant la pause.

Le dernier runner DeepSeek a réussi les vérifications de gameplay de base que nous lui avons fait passer. Ses graphismes étaient modestes. Des expériences précédentes ont révélé d'autres problèmes, dont un défaut dans notre propre validation de livraison. Ces détails sont plus utiles à un créateur qu'un classement de modèles sans explication.

Le runner original DeepSeek-V4.1-Flash-1017. Le personnage, les voies et les pièces sont reconnaissables ; l'environnement reste un prototype élémentaire.

Optimiser la génération de jeux à petit budget

Pour créer un petit jeu, il faut pouvoir multiplier les essais. Une première version peut nécessiter un autre réglage de la caméra, des commandes, des règles de collision ou de la direction artistique. La question concrète est la quantité de jeu utile et testable obtenue au fil du processus.

Un modèle phare puissant comme Claude Opus 5.5 constitue une option évidente pour des tâches de codage exigeantes. Sa description officielle aborde aussi le travail avec des sous-agents. Avant de choisir un processus plus important, nous voulions explorer une sélection plus abordable. Le nom d'un modèle ne garantit pas à lui seul la qualité du jeu ; faire appel à plusieurs agents relève du choix de processus et peut ajouter du travail et de la consommation.

Notre sélection avait plusieurs profils :

• Grok 4.6 servait de référence généraliste. Pour nous, il s'agissait d'un choix moins axé sur le budget, dont l'accès par abonnement constituait un attrait. La page officielle de lancement décrit l'accès au codage via Grok Build et d'autres outils.
• Xiaomi MiMo V2.6 Flash et Pro nous ont permis de comparer deux options d'une même famille. Xiaomi présente Flash comme un modèle efficace pour un usage fréquent et Pro comme une option pour le raisonnement et les projets plus exigeants. Pro est un modèle phare de sa propre famille ; il faisait néanmoins partie de notre exploration des options économiques.
• GLM 5.3 Flash constituait une autre option axée sur l'efficacité. Son introduction officielle explique ce positionnement. Nous voulions voir comment il traiterait l'ensemble de la demande de jeu.
• Claude Haiku 5.5 ajoutait une option étrangère axée sur le coût. Anthropic présente Haiku comme adapté aux tâches rapides et à haut volume. Nous l'avons testé comme créateur de jeux, avec une évaluation limitée décrite ci-dessous.
• DeepSeek-V4.1-Flash-1017 était la dernière expérience. L'annonce de lancement comprend des démonstrations de projets. Nous avons utilisé notre propre demande de runner pour voir ce qui pourrait être reproduit dans OpenGame Studio.

Plusieurs familles de modèles chinoises figurent ici parce que leur prix abordable en a fait des candidates pour notre sélection. Cela reflète notre processus de sélection et non une conclusion sur la qualité des modèles selon leur pays.

Un runner, six expériences avec des modèles

Notre jeu commun était Colossal Runner, un runner sans fin original à la troisième personne avec trois voies. Le personnage avance automatiquement. Les joueurs changent de voie, sautent par-dessus des barrières, glissent sous des obstacles aériens, ramassent des pièces et recommencent après une collision. Le clavier et le tactile doivent produire le même résultat visible.

La demande originale comprenait aussi une pause, la réanimation contre des pièces gagnées et un obstacle géant qui bloque deux voies en laissant un itinéraire sûr. Ces règles qui interagissent entre elles rendent la demande plus révélatrice qu'une simple scène animée avec un compteur de score.

Nous avons réutilisé la même demande originale dans ces expériences du 11 au 17 octobre 2026 :

Il s'agit d'expériences individuelles menées par des développeurs. Elles offrent une base de comparaison pratique, avec des limites claires : chaque modèle a produit son propre résumé de demande et sa propre implémentation, avec des choix visuels différents. Les tests ont eu lieu à des dates différentes et l'environnement du site n'était pas figé. MiMo Flash a nécessité un échange supplémentaire avant sa génération. Les durées excluent les échanges, la rédaction des spécifications et les tests de jeu ; la durée indiquée pour GLM s'arrête au rejet.

Pour le runner DeepSeek, nous avons conservé les contraintes de génération existantes et les mêmes instructions de création 3D utilisées lors des expériences MiMo. Aucune réparation manuelle du code source n'a précédé les tests d'acceptation. Cette série ne permet pas d'établir de classement statistiquement fiable de la vitesse ou de la qualité.

Ce que MiMo, GLM et Haiku ont apporté à la comparaison

MiMo Flash a produit un jeu inspectable avec des commandes utiles, notamment lors de vérifications circonscrites du clavier, du tactile et de la pause. Le problème concernait la règle des pièces : les récompenses pouvaient être attribuées avant que le personnage n'atteigne une pièce. Le code consultait le mauvais champ de position lors de la vérification de collecte. Une scène convaincante et un compteur qui augmentait avaient masqué une interaction défectueuse.

Résultat original de MiMo Flash, avant les réparations éditoriales ultérieures. Le défaut de collecte a été établi par les règles de jeu et l'inspection du code ; cette image à elle seule ne permet pas de le prouver.

MiMo Pro a également livré un prototype jouable, et les vérifications de direction et de contact avec les pièces étaient encourageantes. Une pause en plein saut a révélé un autre défaut. La distance et les pièces s'arrêtaient de progresser, tandis que le personnage continuait de tomber. Une pause complète doit figer la simulation concernée, y compris le mouvement vertical.

Scène urbaine originale de MiMo Pro. Son défaut de pause nécessitait un test en plein saut qu'une image fixe attrayante n'aurait pas révélé.

GLM nécessite deux conclusions distinctes. La génération dans Studio a échoué lors de la livraison, car notre validateur a pris du code de jeu intégré pour du balisage de ressources interdit. C'était une erreur de la plateforme. Il serait trompeur d'y voir la preuve que GLM ne pouvait pas générer le jeu.

Nous avons récupéré l'original inchangé et l'avons inspecté séparément. Les vérifications circonscrites de direction, de commandes tactiles et de pause y fonctionnaient, mais le redémarrage pouvait laisser affichée une valeur obsolète de pièces. Cette inspection nous renseigne sur le comportement de l'artefact ; elle ne transforme pas l'échec de livraison dans Studio en livraison réussie.

Original de GLM récupéré et inspecté séparément. Cette image ne prouve pas que la livraison par Studio a réussi.

Haiku 5.5 a livré son aperçu assez rapidement lors de cet essai. L'écran d'accueil s'est affiché, puis nous avons arrêté le test après une première inspection visuelle. Nous n'avons pas terminé les vérifications d'acceptation sur le clavier, le tactile, les collisions, la réanimation ou le redémarrage. Notre première impression n'a pas modifié notre préférence pour les expériences MiMo, mais les observations de gameplay sont insuffisantes pour donner un verdict ferme sur la qualité de Haiku.

Cette distinction est importante pour tenir un journal de test : livré, examiné visuellement et vérifié en situation sont trois étapes différentes.

Pourquoi la gauche devient-elle la droite ?

Le runner Grok a révélé le défaut de commande le plus évident. Depuis la voie centrale, la touche Flèche gauche déplaçait le personnage vers le côté droit de l'écran. Les balayages vers la gauche produisaient le même résultat.

Avant : le runner est au centre.

Après Flèche gauche : le runner se trouve visiblement à droite. Les deux captures montrent la version générée non modifiée.

Le code l'expliquait : la commande déplaçait le personnage vers la coordonnée X négative du monde pour aller « à gauche », tandis que l'orientation de la caméra rendait ce déplacement visible vers la droite. Le clavier et le tactile utilisaient le même contrôleur de voie et héritaient donc tous deux de l'erreur.

Pour le joueur, le repère est la piste visible. La diminution d'une coordonnée ne prouve pas que le mouvement est bien orienté à gauche. Avec une caméra qui suit le personnage, il faut aussi vérifier sa position par rapport aux voies, car il peut rester au centre de l'écran pendant que la piste se déplace.

Une autre expérience de course a également révélé une faiblesse de notre méthode d'évaluation. Un contrôleur automatisé pouvait compenser la direction inversée et terminer un tour. Nous vérifions maintenant chaque direction séparément depuis un nouveau départ. Terminer le parcours n'avait pas permis de valider les étiquettes des commandes.

Ce qu'a donné DeepSeek V4 lors du test de notre runner

La génération du runner le plus récent a pris environ sept minutes après une courte confirmation. Nous avons testé le résultat original dans l'aperçu du site :

• Directions : Flèche gauche, Flèche droite, A et D déplaçaient le personnage vers la bonne voie visible. Les entrées répétées s'arrêtaient à la voie extérieure.
• Tactile : les balayages gauche et droite fonctionnaient en émulation portrait et paysage. Un balayage vers le haut faisait sauter le personnage ; vers le bas, il l'amenait au sol pour glisser.
• Obstacles : au clavier, le personnage a sauté une barrière au sol, glissé sous une barre aérienne et pris la voie sûre pour contourner le grand bloqueur.
• Pièces et réanimations : la collecte commençait au contact des pièces. Une réanimation dépensait les pièces gagnées et reprenait la course en sécurité ; une réanimation impossible à payer ne dépensait ni pièces ni utilisation.
• Pause et redémarrage : en pleine saut, la pause maintenait la hauteur et la distance et bloquait les commandes de déplacement sur la piste. Le redémarrage réinitialisait la voie centrale, la distance et le nombre de pièces affiché.

Une course parmi les obstacles s'est poursuivie au-delà de 216 mètres avec 51 pièces collectées. L'automatisation du navigateur a envoyé des commandes de jeu normales. Nous n'avons pas modifié les coordonnées, le score ou l'état des collisions pour obtenir ce résultat.

Un balayage vers la gauche amène le personnage dans la voie gauche visible en émulation navigateur portrait. La compatibilité avec un téléphone physique reste à tester.

Nous n'avons pas testé toutes les séquences d'obstacles aléatoires, le parcours sur le toit du train, la limite de réanimations ni l'état du jeu à des étapes avancées. Dans le périmètre vérifié, il s'agissait d'un prototype fonctionnel dont la gestion des règles était encourageante.

Évaluer séparément logique, graphismes et lisibilité

Le runner DeepSeek permettait de distinguer les éléments importants : personnage turquoise, bords de voies lumineux, pièces d'or et dangers contrastés. Son environnement sombre et clairsemé ainsi que ses bâtiments simples laissaient beaucoup de place à l'amélioration visuelle. Ce seul résultat ne permet pas d'affirmer que DeepSeek serait généralement meilleur en logique qu'en graphismes.

Notre expérience distincte Neon Harbor Sprint avait un style néon prononcé, mais la silhouette de la voiture et la route étaient plus difficiles à distinguer. Une révision des performances a réduit la résolution de rendu, améliorant la réactivité mais diminuant la netteté.

Prototype de course DeepSeek distinct. Il utilisait une autre demande et ne fait pas partie de la comparaison des runners communs.

Nous sommes revenus au runner, car un autre jeu aurait brouillé la comparaison. Le jeu de course nous a tout de même appris quelque chose : évaluez le personnage, les dangers et les limites des voies à leur taille réelle de jeu, avec le jeu en mouvement. Les effets et la décoration de l'interface peuvent coexister avec une mauvaise lisibilité.

Les prompts et les skills sont-ils trop contraignants ?

Notre demande de runner était volontairement détaillée afin de pouvoir la réutiliser. Un créateur ordinaire devrait pouvoir commencer par une idée beaucoup plus courte. Aider à transformer cette idée en consigne utile fait partie du rôle du produit.

Nous n'avons pas mené de comparaison contrôlée entre une consigne courte et une consigne détaillée. La longueur du prompt ne suffit donc pas à expliquer les commandes inversées. Le code défectueux fournit une explication directe liée à la caméra et aux entrées, et d'autres résultats issus de la même demande ont bien associé les directions.

Certaines contraintes protègent l'expérience : des commandes cohérentes, un contact réel avec les pièces, une pause complète et un redémarrage propre. D'autres choix peuvent rester ouverts, comme le thème, la palette, la présentation de la caméra et la construction de la scène par le modèle. Un processus de création rigide peut aussi laisser trop peu de place à l'inspection et à l'amélioration de la première implémentation. Il vaut la peine de tester d'autres possibilités de révision ; leur bénéfice reste ici une hypothèse.

Des essais antérieurs ont montré pourquoi le processus mérite qu'on s'y intéresse. Une tentative MiMo a épuisé sa limite de réponses avant de livrer un jeu. Une autre a écrit le code, mais a perdu la livraison finale à cause d'une défaillance du flux du fournisseur. Ces échecs avaient des causes différentes et doivent être distingués des défauts de gameplay. Ils nous empêchent aussi de traiter toutes les tentatives passées comme un test A/B portant uniquement sur les modèles.

Un créateur pourrait commencer avec cette consigne :

Crée un runner 3D rapide avec trois voies. Je dois pouvoir esquiver à gauche et à droite, sauter par-dessus des barrières et glisser sous des poutres, au clavier ou au tactile. Je veux un personnage bien visible, des collectes de pièces satisfaisantes et un redémarrage rapide après une collision. Choisis le décor et le style visuel.

Il s'agit d'un exemple de départ suggéré, et non de la consigne originale de comparaison. Studio peut demander des précisions sur les règles manquantes, confirmer le brief et laisser de la place aux choix créatifs. Un court test de jeu peut ensuite révéler quelle révision serait la plus utile.

Ce que ces tests changent pour notre prochaine expérience

Pour nous, l'optimisation couvre maintenant la fiabilité de livraison, le temps d'inspection et le volume de réparations nécessaires à un résultat jouable. Une génération à bas coût est utile si le résultat résiste aux entrées normales et peut être amélioré par des révisions faciles à gérer.

Nous conserverons les résultats originaux, noterons l'étape atteinte par chaque tentative et testerons le clavier et le tactile par rapport au comportement visible. Une prochaine comparaison pourrait garder le jeu identique tout en faisant varier un seul paramètre de processus, comme la longueur du brief ou le nombre d'occasions de révision. Ces observations ne nous disent pas encore quel modèle gagnerait ce test.

Pour un exemple jouable, visitez Colossal Runner. Ses versions publiques sélectionnées comprennent des réparations ultérieures et sont distinctes des expériences originales présentées ici. Vous pouvez aussi parcourir d'autres jeux sur navigateur pour trouver des idées de jeu à créer.

Vous avez une petite idée de jeu ? Commencez un brief dans OpenGame Studio, mettez-vous d'accord sur la boucle de jeu et testez la première version avec de vraies commandes.

Note sur les sources

Les sources officielles établissent les noms des modèles, le contexte de leur sortie et le positionnement des fournisseurs : sortie du 17 octobre de DeepSeek, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5 et l'exemple de référence non testé d'un modèle phare, Claude Opus 5.5.

Les observations de gameplay et durées de génération proviennent de nos propres expériences OpenGame Studio et de leurs originaux conservés. Les huit images sont des captures inchangées de ces inspections, avec des graphismes procéduraux originaux ou des ressources de personnages OpenGame M0 sous licence CC0-1.0. Aucune image n'est une démonstration de fournisseur ni une reconstitution améliorée.