Moteurs de jeu open source comparés : Godot, Bevy, Stride et O3DE

Pour une petite équipe qui commence un jeu généraliste en 2D ou en 3D, Godot constitue un premier candidat utile. Bevy convient à une équipe Rust prête à prendre en charge une plus grande part de son outillage ; Stride mérite un examen pour les workflows C# ; O3DE vaut la peine d’être évalué lorsqu’une équipe peut entretenir une chaîne de production de contenus 3D et de compilation plus importante. Ce sont des points de départ à valider, pas un classement des performances.

Cette comparaison fondée sur la documentation s’adresse aux développeurs qui choisissent un moteur de jeu. Les versions de référence vérifiées le 2 novembre 2026 sont Godot 4.7.2, Bevy 0.20, Stride 4.4 et O3DE 26.05. L’exemple exécutable ci-dessous ne teste qu’une petite fonction de déplacement dans Godot ; il ne permet pas de conclure sur l’utilisation des éditeurs, la vitesse de rendu ou la fiabilité des exports des autres moteurs.

Que comparons-nous ?

Les quatre projets se présentent comme des moteurs de jeu. Leurs workflows diffèrent : un éditeur visuel intégré et un workflow ECS piloté par le code ne laissent pas la même quantité d’outils à assembler à l’équipe. Un framework ou une bibliothèque de rendu peut aussi convenir, mais les outils de scène, de gestion des assets et d’édition manquants doivent être comptabilisés comme du travail à fournir par l’équipe.

Moteur et version de référence	Workflow de développement	Première question avant de s’engager
Godot 4.7.2	Éditeur de scènes et de nœuds avec scripts	Le langage choisi permet-il l’export vers la cible réelle ?
Bevy 0.20	Systèmes et composants Rust articulés autour de l’ECS	L’équipe peut-elle maintenir l’outillage et les migrations d’API ?
Stride 4.4	C# et Game Studio	L’éditeur est-il disponible sur les machines de développement ?
O3DE 26.05	Éditeur 3D extensible et chaîne de composants	L’équipe peut-elle compiler, importer des assets et empaqueter une petite scène ?

Les scénarios ci-dessous sont des recommandations déduites de ces workflows. Ils ne relatent pas l’expérience d’une équipe ayant livré un jeu avec chacun de ces moteurs.

Quel moteur correspond au workflow de l’équipe ?

Godot : commencer par une boucle de création complète

Godot constitue une base raisonnable lorsque l’équipe veut modifier des scènes, leur associer des comportements et itérer dans un même environnement. Sa licence MIT autorise les jeux propriétaires ; la distribution du moteur exige toujours les mentions de droits d’auteur et de licence correspondantes. Les plugins, polices, musiques et modèles ont leurs propres conditions.

Vérifiez tôt la combinaison langage/plateforme. La documentation d’export web de Godot indique actuellement que les projets Godot 4 en C# ne peuvent pas être exportés vers le Web. Un prototype C# pour ordinateur ne prouve donc pas qu’une livraison dans le navigateur est possible. Pour les consoles, les conseils de portage de Godot décrivent l’approbation de la plateforme, les SDK officiels et les modèles d’export privés ou les prestataires tiers. Un moteur open source ne dispense pas de cette procédure.

Bevy : choisir ensemble Rust et la prise en charge de l’outillage

Bevy est un moteur, pas seulement un moteur de rendu. Son introduction décrit Rust, l’ECS et le choix entre les licences MIT et Apache 2.0. Elle avertit aussi que certaines versions rompent la compatibilité des API et que les migrations peuvent être difficiles.

Bevy devient ainsi intéressant pour une équipe qui souhaite placer les systèmes et les composants au centre de son modèle de développement. L’intégration de l’éditeur, les itérations sur les assets et les migrations de version sont des points à démontrer avec le projet de l’équipe. La seule maîtrise de Rust ne garantit pas une boucle de création plus rapide, et un ECS parallèle ne prouve pas de meilleurs temps de calcul par image pour un jeu donné.

Stride : distinguer la prise en charge de C# de la disponibilité de l’éditeur

La FAQ de Stride présente sa licence MIT et l’absence de redevances sur le moteur. Son workflow C# peut en faire un candidat utile pour une équipe .NET existante.

La matrice des plateformes distingue les machines de développement des cibles des jeux : Windows bénéficie d’une prise en charge complète de l’éditeur ; Linux et macOS permettent, sous certaines réserves, la compilation et les workflows reposant uniquement sur le code, et l’éditeur n’est pas disponible nativement hors de Windows. L’annonce de la version 4.4 signale des améliorations des compilations hors de Windows. N’en déduisez pas que le même workflow d’édition est disponible partout.

O3DE : évaluer la chaîne de production avant les démonstrations

O3DE mérite de figurer dans la sélection d’une équipe prête à prendre en charge une chaîne de production 3D extensible. Son fichier de licence définit Apache 2.0 par défaut avec une option MIT et identifie des composants tiers distincts. La page de téléchargement répertorie des paquets Windows/Linux et des exigences importantes pour les machines de développement. Ce sont des exigences relatives aux machines hôtes, pas une liste générale des cibles d’export des jeux.

Commencez par l’import d’un asset représentatif, la compilation du projet et une scène empaquetée. Les notes de version 26.05 qualifient le nouveau système de particules d’expérimental et déconseillent son utilisation en production. Une fonctionnalité mentionnée dans des notes de version ne devient pas automatiquement une dépendance prête pour la production.

« Gratuit » signifie-t-il open source ou production sans frais ?

Non. L’accès au code source et un prix d’achat nul ne suffisent pas à établir qu’une licence est open source. Par exemple, Defold se présente actuellement comme « source available » ; évaluez sa licence propre au lieu de le regrouper automatiquement avec les quatre moteurs ci-dessus.

La licence du moteur ne paie pas non plus le portage sur console, les licences d’assets, l’hébergement, les plugins ou la maintenance. Avant de décider, identifiez les éléments fournis par le moteur, ceux qui exigent une autre licence et ceux que l’équipe réalisera. Évitez d’estimer un coût total sans avoir défini ce périmètre.

Que doit vérifier un petit prototype ?

Donnez aux moteurs présélectionnés la même tâche de validation : charger un asset représentatif, implémenter une interaction et produire une version compilée pour la cible prévue. Consignez la configuration initiale, les difficultés du cycle répété de modification et d’exécution, ainsi que les exigences non prises en charge. Il s’agit d’une évaluation proposée, pas d’un benchmark réalisé pour cet article.

Voici une partie reproductible : un test de déplacement Godot sans interface graphique. Il reçoit une position, une direction synthétique et un temps écoulé en secondes, limite la norme de la direction à 1, applique la vitesse et contraint le point obtenu à un rectangle. Les entrées sont supposées finies et le temps écoulé positif ou nul. Cette limitation ne traite ni les collisions avec des obstacles, ni la taille des sprites, ni une simulation physique.

Recevoir la position, la direction et le temps écoulé, limiter la norme de la direction, appliquer la vitesse et le temps, contraindre le point aux limites et renvoyer la nouvelle position

Le schéma montre un appel à advance. Le programme de test ci-dessous répète les appels et vérifie les résultats ; il ne lit pas le clavier et n’affiche pas de personnage. La référence de Vector2 décrit les opérations vectorielles. Cela sépare le comportement testé des affirmations sur la productivité dans l’éditeur ou les performances du jeu.

Lorsque l’exécutable standard de l’éditeur Godot 4.7.2 est disponible sous le nom godot, enregistrez project.godot et movement.gd dans le même répertoire. Aucune scène, aucun asset externe, aucun paquet ni accès réseau n’est nécessaire pour exécuter le script une fois le moteur installé.

project.godot:

config_version=5

movement.gd:

extends SceneTree

const SPEED := 120.0
const LIMIT := Vector2(640.0, 360.0)

func advance(pos: Vector2, direction: Vector2, delta: float) -> Vector2:
    var bounded := direction.limit_length(1.0)
    var next := pos + bounded * SPEED * delta
    return next.clamp(Vector2.ZERO, LIMIT)

func _initialize() -> void:
    var cases := [
        [Vector2(100, 100), Vector2.ZERO, 0.5, Vector2(100, 100)],
        [Vector2(100, 100), Vector2.RIGHT, 0.5, Vector2(160, 100)],
        [Vector2.ZERO, Vector2(1, 1), 1.0, Vector2(84.852814, 84.852814)],
        [Vector2.ZERO, Vector2(0.5, 0), 1.0, Vector2(60, 0)],
        [Vector2(639, 100), Vector2.RIGHT, 1.0, Vector2(640, 100)],
        [Vector2(5, 100), Vector2.LEFT, 1.0, Vector2(0, 100)],
        [Vector2(100, 359), Vector2.DOWN, 1.0, Vector2(100, 360)],
        [Vector2(100, 100), Vector2.RIGHT, 0.0, Vector2(100, 100)],
    ]
    for sample in cases:
        var actual := advance(sample[0], sample[1], sample[2])
        if not actual.is_equal_approx(sample[3]):
            push_error("movement mismatch")
            quit(1)
            return
    var split := advance(advance(Vector2(100, 100), Vector2.RIGHT, 0.25), Vector2.RIGHT, 0.25)
    if not split.is_equal_approx(advance(Vector2(100, 100), Vector2.RIGHT, 0.5)):
        push_error("time-step mismatch")
        quit(1)
        return
    print("movement cases=9")
    quit(0)

Exécutez-le depuis ce répertoire avec l’interface en ligne de commande de Godot. Sous macOS, remplacez godot par le chemin Godot.app/Contents/MacOS/Godot du paquet installé s’il ne se trouve pas dans PATH.

godot --headless --no-header --path . --script movement.gd --quit-after 1

L’exemple a été exécuté localement sous macOS avec Godot 4.7.2. Sa sortie était :

movement cases=9

Les vérifications couvrent une entrée inactive, les déplacements horizontaux et diagonaux, une norme de direction partielle, les limites supérieures et inférieures, un temps écoulé nul et un pas de temps fractionné loin des limites. Elles ne vérifient ni le rendu, ni l’export vers un appareil cible, ni les obstacles, ni les fonctions réseau, ni les performances comparées.

Comment faire le choix final ?

Choisissez le candidat qui satisfait le workflow requis par le jeu et produit la version cible avec une charge de maintenance acceptable pour l’équipe. Si la boucle d’édition visuelle est prioritaire, commencez le prototype avec Godot. Si l’équipe souhaite explicitement prendre en charge Rust/ECS, testez le coût de l’outillage et des migrations de Bevy. Pour une équipe C#, testez Stride sur les machines qui accueilleront réellement l’éditeur. Pour une chaîne de production 3D plus importante, validez la boucle d’assets et de compilation d’O3DE avant de vous appuyer sur une fonctionnalité de démonstration.

Le prochain livrable utile est une petite version pour l’appareil cible et une liste d’exigences non satisfaites, pas un classement universel des moteurs. Conservez ces éléments de décision avec le projet pour pouvoir évaluer une mise à niveau du moteur selon le même comportement.