Comment comparer quatre créateurs de jeux IA avec un même descriptif

Choisissez un outil de création de jeux selon le jeu auquel vous pouvez jouer, les modifications que vous pouvez apporter et le projet que vous pouvez conserver, pas uniquement selon une capture d’écran. Une comparaison équitable part d’un même petit descriptif et vérifie les mêmes règles visibles par le joueur avant de juger l’apparence. Elle consigne aussi le travail manuel, les restrictions du forfait et le contenu réel d’une exportation. Le test proposé couvre SEELE AI, Rosebud AI, GDevelop et Buildbox, les quatre outils nommés dans la comparaison existante. Aucune exécution contrôlée ni inspection d’export n’était disponible pour ce brouillon. Les résultats et recommandations restent donc en attente : il n’y a ni notes, ni écarts de capacité observés, ni gagnant. Les sections suivantes définissent ce qu’il faut exécuter et conserver pour qu’une comparaison ultérieure puisse répondre honnêtement à la question du choix.

Le descriptif commun et les conditions de contrôle

Utilisez un navigateur sur ordinateur, une taille de fenêtre fixe et le même périphérique d’entrée pour chaque essai. Définissez avant d’ouvrir un outil le forfait autorisé, le plafond de dépenses, la limite d’interventions et la condition d’arrêt. Notez le niveau de compte, la date, la version affichée et les coûts réels. Ne supposez pas qu’un même nombre de prompts représente le même effort lorsqu’un processus exige une édition visuelle.

Crée Lantern Delivery, un jeu 2D pour navigateur sur un seul écran en vue de dessus. Utilise un coursier original et des décors originaux simples. Déplace-toi avec WASD ou les flèches. Ramasse cinq lanternes en évitant un danger mobile. Affiche le nombre collecté et un chronomètre de 45 secondes. Un contact avec le danger ou l’expiration du temps termine la tentative. Ramasser les cinq donne la victoire. Inclus des instructions visibles et Recommencer. Garde le même coursier et la même direction artistique partout. N’utilise ni personnages sous licence ni images téléchargées protégées par le droit d’auteur.

Considérez cela comme une spécification, pas comme un résultat généré. Pour le test, démarrez le chronomètre au premier mouvement, bloquez les commandes après chaque fin et restaurez tout l’état au redémarrage. Si une interface ne peut pas accepter directement le descriptif, documentez la façon dont son processus natif le met en œuvre. N’accordez pas discrètement de préparation supplémentaire à un candidat et ne remplacez pas le descriptif par un modèle plus complet.

Les fiches des quatre candidats à compléter

SEELE AI : vérifier les livrables après le prompt

SEELE décrit la création en langage naturel de scènes, de ressources et de code de jeu. Pour cette comparaison, la question est de savoir si ce processus produit la boucle Lantern Delivery spécifiée et permet la modification contrôlée dans le même projet. Fournissez le descriptif inchangé par le processus de création disponible, puis conservez la demande initiale, l’historique des réponses, la première version accessible et les conditions du compte.

Ne déduisez ni l’accès au code source, ni la compatibilité avec un moteur, ni un lancement local réussi du positionnement du produit. Inspectez les livrables réels et notez leur format. Si des précisions ou réparations supplémentaires sont nécessaires, comptez-les et conservez-les avant de passer à l’ajout du bouclier. Une recommandation ultérieure utile relierait la jouabilité observée, l’effort de modification et la reproductibilité aux besoins du lecteur. Ces observations n’existent pas actuellement : ce candidat ne reçoit donc ni note ni avantage attribué.

Rosebud AI : consigner le parcours réel de création et de modification

Exécutez le descriptif commun avec le processus disponible dans le compte Rosebud AI testé. Notez le format d’entrée initial, toute configuration nécessaire et chaque intervention requise pour obtenir une version accessible. Consultez la documentation officielle actuelle sur les conditions du forfait, mais séparez les affirmations documentées de ce que l’évaluateur observe. Ce brouillon n’établit pas quelles fonctionnalités actuelles ni quels formats d’export sont disponibles.

Lorsqu’une version de référence est jouable, conservez-la avant d’envoyer la même demande de bouclier. Notez si la modification concerne le projet existant et si le coursier, les règles et la carte subsistent. Pour les livrables, inspectez l’artefact réellement fourni par le processus testé ; ne rebaptisez pas un lien hébergé « code source ». L’absence d’accès sur un compte est une observation propre à son forfait, pas la preuve qu’un produit ne propose jamais une capacité. Aucune génération, modification ou exportation Rosebud n’a été effectuée pour cet article.

GDevelop : rendre visible le travail dans l’éditeur

Évaluez le processus actuel de GDevelop tel qu’il se présente à la personne qui teste, sans supposer qu’il copie un générateur conversationnel. Notez toute construction de scène, édition d’événements, préparation de ressources ou sélection de modèle nécessaire pour réaliser le descriptif. Si le processus propose une création assistée, conservez ses entrées et sorties avec les actions manuelles. Cet article n’a pas vérifié ces options actuelles ni les conditions de leurs forfaits.

Une structure d’événements modifiable peut constituer le livrable pertinent pour un utilisateur d’éditeur visuel ; elle ne doit pas être écartée au seul motif qu’elle diffère d’un répertoire de scripts écrits à la main. À l’inverse, un projet d’éditeur seul ne prouve pas qu’une version partagée fonctionne dans le navigateur. Consignez séparément la référence, le changement contrôlé des événements ou du projet, les vérifications jouables et le contenu réel de l’export. La comparaison ultérieure doit montrer l’effort et le résultat de ce processus, sans le pénaliser ni le récompenser pour l’étiquette « sans code ». Aucun résultat de test GDevelop n’est disponible ici.

Buildbox : distinguer l’édition du projet du résultat publié

Utilisez le processus réel du compte Buildbox testé pour réaliser Lantern Delivery, en documentant la configuration nécessaire et tout comportement issu d’un modèle. Vérifiez la documentation actuelle et les conditions du compte avant de décrire les options de publication ou d’export. Ne supposez pas que l’interface de prompt, l’organisation des fichiers ou les instructions de lancement local d’un autre outil s’appliquent ici. Conservez la première révision du projet qui peut être évaluée, y compris toute préparation manuelle.

Pour la modification du bouclier, notez la logique modifiable ou les différences de projet qui mettent en œuvre la protection, ainsi que les preuves que les règles de référence restent intactes. Identifiez précisément les livrables : projet d’éditeur, version hébergée, artefact compilé ou fichiers sources, selon ce qui est réellement fourni. Si une cible ou une exportation est inaccessible, indiquez le forfait testé et la restriction exacte observée. Un lecteur ultérieur pourra ainsi juger le processus selon ses besoins. À ce jour, aucune version, révision ou livraison Buildbox n’a été inspectée et aucun verdict sur ses capacités n’est justifié.

Effectuer les mêmes vérifications de jeu, de modification et de livraison

Testez d’abord les instructions, les deux modes de déplacement, la collecte unique, le contact avec le danger, la victoire à cinq lanternes, l’expiration du temps et le redémarrage après chaque fin. Répétez après un nouveau chargement. Marquez chaque vérification comme réussie, échouée ou non testée et associez-y la révision de la version. Conservez un enregistrement ininterrompu incluant les échecs. Une réponse de page ou une scène attrayante ne constituent pas une vérification complète de la boucle de jeu.

Appliquez ensuite une modification contrôlée : ajoutez un bouclier à ramasser qui absorbe exactement un contact avec le danger et disparaît lors de sa collecte. Indiquez si la protection est active. Préservez les graphismes du coursier, la carte, les commandes, le nombre de lanternes, le chronomètre et le redémarrage. Précisez qu’aucun deuxième bouclier n’apparaît avant le redémarrage. Testez la collecte, le premier contact protégé, le contact suivant sans protection, l’expiration du temps sous protection et la restauration au redémarrage. Réexécutez toutes les vérifications de référence. Sauvegardez la différence de révision native, qu’il s’agisse de code, d’événements ou d’un autre artefact de projet inspectable.

Enfin, distinguez un lien jouable, une version compilée, un projet modifiable et du code source lisible par une personne. Sauvegardez et inspectez l’export fourni. Ouvrez-le ou exécutez-le avec les outils documentés dans un répertoire vierge, en notant les commandes réelles, les versions, les ressources manquantes et les corrections manuelles. Une simple réussite du téléchargement n’établit pas qu’un projet est reproductible. Conservez la documentation actuelle à côté de l’observation sans la substituer au test.

Comparez des éléments équivalents : premier résultat accessible avec premier résultat accessible, et résultat réparé avec résultat réparé, en déclarant les interventions. Un débutant peut privilégier des itérations compréhensibles et une boucle fonctionnelle ; un développeur, du code source reproductible ; un utilisateur d’éditeur, des événements inspectables. Ne présentez ces compromis qu’une fois les artefacts disponibles. Les chiffres de temps et de crédits exigent des règles de début et de fin consignées, pas des estimations faites après avoir vu le résultat. Une seule exécution peut étayer une comparaison de cas limitée, pas une affirmation générale de fiabilité.

Liste de preuves : aucune cellule de résultat n’est complète

• Pour chaque candidat : niveau de compte, date du test, version affichée, navigateur, budget et historique réel des interventions.
• Descriptif original, projet ou version de référence et enregistrement complet des vérifications d’acceptation.
• Demande exacte du bouclier, révisions avant et après, modification inspectable et observations de non-régression.
• Artefact réel d’export ou de livraison, relevé de configuration en environnement vierge et résultat de lancement observé.
• Documentation officielle actuelle étayant toute affirmation sur les forfaits ou les formats.
• Constats par outil et recommandations conditionnelles rédigés uniquement après ces vérifications.

Les quatre essais restent à effectuer pour cet article. La liste est un plan de collecte, pas un tableau de résultats. Aucun classement testé, outil le plus rapide, jeu achevé le moins cher ou gagnant vérifié pour l’export ne peut être annoncé.

Conclusion : attendre les preuves avant de recommander

La comparaison utile ne consiste pas à choisir l’outil qui paraît le plus complet, mais le processus testé qui correspond au projet que vous souhaitez poursuivre. Conservez le descriptif commun, déclarez l’aide reçue et distinguez le comportement jouable des livrables inspectables. Ce brouillon ne peut pas désigner de gagnant : les quatre essais contrôlés, modifications et exports manquent encore. Une fois l’accès et tout budget nécessaire autorisés, utilisez le descriptif commun Lantern Delivery dans SEELE et répétez-le sans modification chez les autres candidats. Conservez les échecs et restrictions dans le relevé. Vous pourrez alors réduire les options selon la jouabilité observée, l’effort de modification et l’accès au projet, plutôt que selon un classement supposé.

Questions fréquentes

Un bouton d’export signifie-t-il que je recevrai du code source modifiable ?

Non. L’export peut être une version compilée ou un projet destiné à un éditeur particulier. Téléchargez et inspectez l’artefact réel, puis ouvrez-le ou exécutez-le avec les outils documentés. Notez le forfait et le format testés afin de ne pas confondre une observation limitée à un compte avec une capacité universelle du produit.

La documentation officielle peut-elle remplacer une comparaison pratique ?

Non. La documentation peut étayer une affirmation sur une fonctionnalité ou un forfait actuels, mais elle ne peut pas montrer que ce jeu précis fonctionnait correctement ou a résisté à l’ajout du bouclier. Gardez documentation et résultats observés dans des notes distinctes. Marquez un scénario non exécuté comme non testé au lieu de tirer confiance d’un exemple promotionnel ou d’une liste de fonctionnalités.

Chaque candidat doit-il recevoir exactement le même nombre de prompts ?

Utilisez le même descriptif initial et la même spécification de modification, mais déclarez toute aide supplémentaire et tout travail manuel. Des interfaces différentes peuvent exiger des actions différentes : le nombre de prompts seul ne mesure donc pas équitablement l’effort. Fixez à l’avance les limites d’intervention et de budget, puis conservez l’historique au lieu d’ajuster les règles après avoir vu les résultats.