Jeux Video

À la une

BRUTAL : le créateur de DayZ libère la technologie qui a aidé RimWorld à quitter Unity

Après avoir participé à la naissance de DayZ et fondé RocketWerkz, Dean Hall s'attaque désormais à un autre problème de l'industrie du jeu vidéo : la dépendance des développeurs aux moteurs commerciaux. Avec BRUTAL, un framework en C# dont le code vient d'être publié, il propose aux studios de reprendre le contrôle de leurs outils sans reverser de royalties. Et ce projet n'a rien d'une simple expérimentation : il constitue déjà l'une des fondations techniques du nouveau moteur de RimWorld et du simulateur spatial Kitten Space Agency.

11 min de lecture 0 commentaire
BRUTAL : le créateur de DayZ libère la technologie qui a aidé RimWorld à quitter Unity

Pendant des années, créer un jeu vidéo indépendant signifiait souvent choisir entre trois grandes solutions : Unity, Unreal Engine ou Godot. Chacune possède ses avantages, ses limites et sa philosophie, mais les deux premières ont un point commun assez important : elles sont développées par des entreprises dont les décisions commerciales peuvent directement affecter les studios qui les utilisent.

C'est précisément ce qui agace Dean Hall, le créateur du mod DayZ devenu phénomène mondial, aujourd'hui à la tête de RocketWerkz et de la plateforme Ahwoo. Le développeur néo-zélandais n'a jamais vraiment caché son goût pour les technologies capables de sortir des sentiers battus. Avec des projets comme Stationeers, ICARUS ou Kitten Space Agency, son studio s'est régulièrement retrouvé face à des besoins techniques que les moteurs généralistes ne couvrent pas toujours de manière idéale.

Le 15 octobre 2026, Ahwoo et RocketWerkz ont donc annoncé la publication du code source de BRUTAL, un framework de développement écrit principalement en C# et conçu pour permettre aux studios de construire leurs jeux, voire leurs propres moteurs, sans repartir totalement de zéro.

Le plus intéressant, c'est que BRUTAL existe déjà depuis plusieurs années en interne. Il ne s'agit pas d'un projet lancé pour profiter d'une tendance, mais d'une technologie utilisée dans des jeux réels et désormais mise à disposition de la communauté. Et son nom n'a visiblement pas été choisi par hasard.

BRUTAL n'est pas un nouveau Unity, et c'est volontaire

Premier point à comprendre : BRUTAL n'est pas un moteur de jeu complet. Ceux qui espèrent télécharger une application, ouvrir un éditeur visuel, déposer trois objets dans une scène et exporter immédiatement leur premier jeu risquent d'être déçus.

Contrairement à Unity, Unreal Engine ou Godot, BRUTAL ne fournit ni éditeur de niveaux, ni système de scènes prêt à l'emploi, ni moteur de rendu complet. L'objectif est tout autre : proposer les composants fondamentaux nécessaires pour que des développeurs expérimentés puissent créer leur propre architecture technique.

Sur son dépôt GitHub officiel, le projet rassemble notamment des bibliothèques de gestion mémoire, de calcul mathématique, de programmation parallèle, de journalisation, de localisation et de communication avec des composants natifs. Des interfaces permettent aussi de travailler avec Vulkan pour l'affichage graphique, GLFW ou SDL pour les fenêtres et les entrées, Jolt et Box2D pour la physique, ainsi qu'avec plusieurs solutions audio et réseau.

Dit comme ça, BRUTAL ressemble à une boîte remplie de pièces détachées plutôt qu'à un outil prêt à démarrer. Et c'est exactement l'idée. Le framework fournit la plomberie, mais laisse le développeur décider de l'organisation du bâtiment.

Cette liberté possède un avantage majeur pour certains types de jeux. Un simulateur spatial devant représenter des distances astronomiques n'a pas forcément les mêmes besoins qu'un jeu de gestion affichant des milliers de personnages sur une grille. Avec un moteur généraliste, les développeurs doivent souvent adapter leurs systèmes aux choix techniques effectués par l'éditeur du moteur. Avec BRUTAL, ils peuvent construire directement les systèmes dont ils ont besoin.

En contrepartie, il faut réellement savoir ce que l'on fait. Le projet utilise notamment des mécanismes de gestion mémoire non supervisée et certaines fonctionnalités considérées comme dangereuses en C#, lorsque leurs performances le justifient. Autrement dit, la liberté s'accompagne d'une responsabilité assez importante.

Le studio assume parfaitement ce positionnement. BRUTAL ne cherche pas à devenir plus facile que ses concurrents. Il veut devenir plus intéressant pour les développeurs qui savent précisément ce qu'ils souhaitent construire.

RimWorld a déjà montré ce que cette approche pouvait apporter

L'annonce arrive quelques jours après une autre actualité particulièrement intéressante : RimWorld abandonne Unity au profit de son nouveau moteur Waylith. Nous avions déjà évoqué cette migration sur GeekParadize, notamment ses conséquences pour les performances et la compatibilité des mods.

On connaît désormais plus précisément l'une des technologies qui ont facilité cette transition.

Ludeon Studios s'est appuyé sur BRUTAL pour construire Waylith, son moteur interne. Selon les tests publiés par Ludeon, la version expérimentale 1.7 de RimWorld affiche des performances deux à quatre fois supérieures dans certaines situations. Un scénario particulièrement chargé aurait notamment vu son temps de chargement passer de quatorze à six minutes avec environ 1 500 mods installés.

Attention toutefois à ne pas attribuer tous ces gains au seul framework. Waylith est un moteur développé par Ludeon, avec ses propres optimisations et ses choix d'architecture. Les résultats annoncés concernent donc cette migration particulière et ne constituent absolument pas une garantie de performances pour n'importe quel jeu développé avec BRUTAL.

L'exemple reste néanmoins parlant. RimWorld possède un historique technique complexe, une communauté particulièrement attachée aux modifications et des contraintes de simulation très différentes de celles d'un FPS classique. En s'appuyant sur des fondations adaptées, Ludeon a pu remplacer une partie importante de sa technologie sans obliger les joueurs à recommencer leurs colonies depuis zéro.

Ce n'est pas rien quand on sait que certains utilisateurs considèrent une sauvegarde RimWorld de plusieurs centaines d'heures comme un membre à part entière de leur patrimoine familial.

Kitten Space Agency, l'autre vitrine de BRUTAL

L'autre exemple concret porte un nom beaucoup plus mignon : Kitten Space Agency. Derrière ses petits astronautes félins se cache un simulateur de vol spatial développé par RocketWerkz, avec la participation de Felipe Falanghe, le créateur original de Kerbal Space Program.

Disponible gratuitement en préalpha sur la plateforme Ahwoo, Kitten Space Agency cherche à représenter un système solaire à grande échelle, avec des distances réalistes, des trajectoires orbitales complexes et des situations exigeant une grande précision dans les calculs.

Ce type de simulation pose des problèmes assez particuliers. Lorsqu'un vaisseau se trouve à quelques mètres d'une station spatiale, le moteur doit gérer des interactions extrêmement précises. Mais lorsque le même engin voyage entre deux planètes, les distances et les coordonnées changent complètement d'échelle. Un système de représentation mal adapté peut rapidement provoquer des erreurs d'arrondi, des tremblements visuels ou des comportements physiques indésirables.

BRUTAL a justement été conçu pour laisser RocketWerkz décider comment calculer ces positions et gérer le rendu. Plutôt que de contourner les limites imposées par une architecture généraliste, les développeurs peuvent concevoir une solution répondant directement aux contraintes de leur simulation.

Le framework servirait actuellement de base à six projets répartis entre trois studios. Outre RimWorld et Kitten Space Agency, le dépôt officiel cite notamment Torpedia, Art of the Rail, Gruntz et Afterskies.

Il serait évidemment prématuré d'en déduire que BRUTAL va remplacer les grands moteurs existants. Mais ces exemples montrent au moins que ses composants ne sont pas de simples démonstrations techniques imaginées pour faire joli sur GitHub.

Crédit : RocketWerkz / Ahwoo.

Derrière ce projet, une vieille querelle avec Unity

L'annonce de BRUTAL possède également une dimension plus politique, au sens économique du terme. Depuis plusieurs années, les conditions commerciales des moteurs de jeux constituent un sujet sensible pour les studios indépendants. Les changements de tarification, les évolutions des licences et les décisions unilatérales de certains éditeurs ont régulièrement alimenté les inquiétudes des développeurs.

Dean Hall possède d'ailleurs un historique personnel avec Unity. En mai 2025, le patron de RocketWerkz avait contesté un courrier de l'entreprise menaçant de révoquer certaines licences de son studio. Il affirmait notamment que les éléments avancés dans ce dossier comportaient des erreurs. L'incident avait renforcé sa conviction qu'un studio ne devrait pas dépendre entièrement d'un fournisseur extérieur pour maintenir ses propres créations.

Cela ne signifie pas que BRUTAL ait été développé uniquement en réaction à cette affaire. Son développement avait commencé plusieurs années auparavant. Mais cet épisode illustre assez bien le problème que Hall souhaite résoudre : un studio peut investir énormément de temps et d'argent dans un jeu tout en dépendant d'une technologie dont il ne maîtrise ni toutes les évolutions ni les conditions d'utilisation.

Avec BRUTAL, les développeurs peuvent consulter le code, le modifier et conserver leur propre version du framework si les décisions de son mainteneur ne correspondent plus à leurs besoins. Cette possibilité de fork, bien connue dans le monde du logiciel libre, change les rapports de dépendance.

Il ne faut cependant pas tomber dans le raccourci inverse. Utiliser Unity ou Unreal reste parfaitement pertinent pour de nombreuses équipes. Ces moteurs proposent des outils de création, des écosystèmes de plugins, une documentation importante et des fonctionnalités que développer soi-même pourrait demander plusieurs années.

La question n'est donc pas de savoir si tous les studios devraient abandonner leur moteur actuel, mais plutôt s'ils devraient disposer de davantage d'options lorsqu'un projet possède des contraintes particulières.

Gratuit et code ouvert, mais avec une licence à regarder de près

C'est probablement le point qui mérite le plus d'attention avant de se précipiter sur le bouton de téléchargement.

BRUTAL peut être utilisé gratuitement, y compris pour développer des jeux commerciaux. Ahwoo et RocketWerkz ne demandent aucune redevance et ne prélèvent aucun pourcentage sur les ventes. Pour un studio indépendant, c'est évidemment une proposition intéressante.

En revanche, le framework n'est pas distribué sous une licence MIT classique. Il utilise une licence spécifique, inspirée de MIT, qui ajoute plusieurs obligations d'attribution. Les produits utilisant BRUTAL doivent notamment conserver une mention de copyright dans leurs crédits, distribuer un fichier NOTICE et afficher le logo BRUTAL avant le lancement du jeu.

Certaines exceptions existent, notamment pour les projets non commerciaux concernant l'affichage du logo. Une licence commerciale distincte peut également être négociée avec Ahwoo pour des besoins particuliers.

Autre précision importante : cette licence n'a pas encore reçu l'approbation de l'Open Source Initiative, l'organisation qui évalue les licences open source au regard de sa définition officielle. Les développeurs de BRUTAL indiquent ne pas encore l'avoir soumise à cet organisme et souhaitent faire évoluer ses conditions avec les retours de la communauté.

Il convient donc de distinguer la disponibilité publique du code source de la reconnaissance formelle de sa licence. BRUTAL permet bien de consulter, modifier et réutiliser son code dans les conditions annoncées, mais les studios devront étudier précisément le contrat avant de l'intégrer à un produit commercial.

C'est un détail juridique beaucoup moins spectaculaire qu'un moteur Vulkan capable de faire voler une fusée, mais probablement plus important pour quelqu'un qui prévoit de commercialiser son jeu pendant dix ans.

Peut-on déjà utiliser BRUTAL pour fabriquer son propre jeu ?

Oui, mais avec quelques réserves. Le code source est disponible sur GitHub, tandis que les différents composants sont distribués sous forme de paquets NuGet, le gestionnaire de bibliothèques de l'écosystème .NET.

La documentation de démarrage mentionne notamment le SDK .NET 10 et, pour les applications utilisant Vulkan, une carte graphique compatible avec Vulkan 1.3. Les exemples permettent de commencer par créer une simple fenêtre, avant d'ajouter progressivement les systèmes nécessaires à l'application.

Mais le projet vient tout juste d'ouvrir son développement au public et plusieurs éléments doivent encore être améliorés. Au moment de cette publication, le dépôt précise que les fichiers de solution et les scripts permettant de reconstruire facilement l'ensemble depuis les sources sont encore en préparation. Sur les forums officiels, des utilisateurs ont également signalé des liens de documentation inaccessibles, un problème reconnu par l'équipe.

Il ne faut donc pas s'attendre à retrouver immédiatement la simplicité d'installation et l'abondance de tutoriels d'un moteur mature. Pour un développeur curieux, BRUTAL constitue surtout une occasion d'examiner une architecture utilisée dans plusieurs véritables projets et de découvrir une autre façon de concevoir les fondations d'un jeu.

Pour un débutant qui souhaite créer son premier platformer en quelques soirées, Godot reste probablement une meilleure idée. Et c'est très bien ainsi : tous les outils n'ont pas besoin de s'adresser au même public.

L'intérêt de BRUTAL dépasse finalement son code source

Avec cette publication, Dean Hall et ses équipes ne proposent pas seulement un nouvel ensemble de bibliothèques. Ils remettent aussi sur la table une question importante pour l'avenir du développement indépendant : jusqu'où un studio doit-il accepter de dépendre des choix techniques et commerciaux d'un fournisseur extérieur ?

L'exemple de RimWorld montre qu'un moteur spécialisé peut apporter des bénéfices concrets à un jeu possédant des besoins atypiques. Kitten Space Agency démontre qu'une simulation particulièrement ambitieuse peut justifier de reconstruire une partie de son infrastructure technique. BRUTAL cherche à rendre cette démarche un peu moins intimidante en fournissant les fondations que chaque studio n'a pas nécessairement envie de réécrire.

Il ne remplacera probablement jamais Unity, Unreal ou Godot dans les projets ordinaires, et ses propres développeurs n'en font d'ailleurs pas l'objectif. Son intérêt se trouve ailleurs : permettre à des équipes capables de faire leurs propres choix de ne pas être prisonnières d'une architecture pensée pour tout le monde.

Dans une industrie qui multiplie les abonnements, les plateformes et les dépendances logicielles, voir un studio partager plusieurs années de travail technique est une initiative qui mérite l'attention.

BRUTAL porte peut-être un nom un peu intimidant, mais son message est assez simple : les développeurs devraient pouvoir posséder les outils sur lesquels repose leur créativité.

Et si cela permet au passage de faire tourner une colonie de RimWorld remplie de 200 canards sans transformer le processeur en grille-pain, difficile de ne pas y voir un certain progrès.

Sources & références

Tags

Communauté

Commentaires

La discussion est ouverte

Aucun commentaire pour le moment. Soyez le premier à réagir.

Publication après modération