Si el arranque por defecto del indie durante más de una década fue abrir un proyecto Unity y colocar cosas en el árbol de escenas, dos anuncios públicos de mediados de octubre de 2026 empujaron ese hábito de lado. El 12 de octubre, Ludeon Studios anunció que RimWorld 1.7 pasa a su motor propio Waylith, con unas 2–4× de rendimiento en sus pruebas. Tres días después, Ahwoo y RocketWerkz subieron a GitHub BRUTAL, el framework C# detrás de varios de sus títulos, junto con paquetes NuGet.
Cruce el README de GitHub, la entrada oficial de Ludeon, la reimpresión en GameFromScratch del largo hilo de Dean Hall en r/gamedev y el reportaje de Game Developer del 19 de octubre. Los hechos que se pueden clavar no son muchos. BRUTAL se llama a sí mismo framework, no un motor completo. No trae editor ni grafo de escenas, ni renderizador, y dice que no los añadirá. El agradecimiento de Ludeon es cuidadoso: Brutal framework "helped make Waylith possible". El texto oficial no describe el motor entero como externalizado a RocketWerkz.
La imagen que atraviesa este texto es la incompletud deliberada. Suena a eslogan; en código y licencia se vuelve una lista de rechazos verificables.
1. Por defecto en la industria: el motor termina tus decisiones de arquitectura
Durante mucho tiempo, equipos indie y estudios medianos trataron elegir motor como elegir plataforma. Unity, Unreal y luego Godot traen editor, grafo de escenas, pipeline de assets, modelo de scripting y ruta de render por defecto. Abrir el proyecto ya te mete en las hipótesis de mundo de otra persona. Cómo se cuelga la cámara, cómo se instancian los Prefabs, en qué capa hace tick la física, si el GC levantará la cabeza en un frame: esas preguntas suele responderlas el motor antes de que llegue tu gameplay.
Para la mayoría de proyectos ese defecto es razonable. Baja el umbral de “primero imagen, luego juego” y da lenguaje común a contratación y proveedores. El problema aparece en otra clase de juegos. Un sim de vuelo espacial necesita posiciones a escala real. Un sim de colonia debe meter miles de entidades y mods tardíos en el mismo presupuesto de frame. Obras de ferrocarril o tipo enciclopedia quizá no necesiten un grafo de escenas clásico. En su post de r/gamedev (reimpreso íntegro por GameFromScratch), Dean Hall lo dice claro: los motores generalistas contemporáneos se afinan para el caso medio; cuanto más lejos esté el juego de ese promedio, más tiempo de desarrollo se va en acomodar las hipótesis del motor en lugar de aclarar lo que el juego necesita.
Kitten Space Agency, de RocketWerkz, está lejos de ese promedio. En materiales públicos vuelven la representación de posición, el timing de render y el ritmo de asignación de memoria. Hall dice que BRUTAL creció unos cuatro años, de unas pocas librerías a un framework capaz de sostener un juego entero o un motor entero. Al principio parecía bandera roja desde fuera; el equipo incluso lo mantuvo en secreto. En octubre de 2026 ya sostenía KSA directamente y entraba bajo Waylith de Ludeon.
Ahí se bifurcan la lógica por defecto y BRUTAL. Un motor completo termina las decisiones de arquitectura por ti. BRUTAL te las devuelve y escribe en el temperamento del producto que primero tienes que saber qué quieres hacer. Hall admite que para algunos es más difícil, y más rápido para el tipo de juegos que su equipo quiere hacer, porque ya no pasa semanas averiguando cómo pretendían los autores del motor que algo funcionara y luego eludiendo esas hipótesis.
2. Lista de rechazos: sin editor, PR fuera de alcance rechazados, NuGet solo lo necesario
El README deja “qué no es BRUTAL” más nítido que la lista de funciones. No hay editor ni grafo de escenas. El renderizador también queda fuera de alcance y el equipo dice que no lo añadirá. Empujan contra la presión interna de “añadir más”. Los pull requests que se desvíen de un propósito claro se rechazan. El motivo es duro: meterlo todo es exactamente cómo la industria llegó a los motores que no quieren usar.
No es pose. Corresponde a un layout de paquetes verificable. Cada carpeta de primer nivel es una librería publicada como NuGet: `Brutal.Core`, `Brutal.Interop`, `Brutal.Memory`, `Brutal.Collections`, `Brutal.Strings`, `Brutal.Concurrency`, matemáticas y numéricos, logging y localización, más bindings de Vulkan / OpenGL, GLFW / SDL, Dear ImGui, FMOD / OpenAL, RakNet, Jolt / Box2D, glTF y decodificación de texturas, entre otros. Referencias solo lo que necesitas. El ejemplo inicial puede ser solo Core y Glfw: abrir una ventana sin API gráfica; luego tú cableas render, UI de depuración, jobs, audio y red.
En el núcleo hay una capa de interop a medida que da a C# moderno acceso directo a APIs nativas y librerías C/C++ de alto rendimiento, incluido Vulkan. Las librerías de soporte se obsesionan con reducir asignaciones y overhead, usando memoria no administrada y unsafe donde ayuda. Requisitos del README: SDK de .NET 10; GPU Vulkan 1.3 si renderizas; Windows o Linux listados hoy en público.
La incompletud deliberada tiene por tanto dos capas. En el límite funcional no dibuja tus escenas ni ordena tus nodos; el renderizador sigue siendo tuyo. En la unidad de ingeniería parte capacidades en paquetes elegibles y se niega a enviarse como monolito obligatorio. Hall compara la relación con el kernel de Linux y Ubuntu: no exacta, pero suficientemente clara. BRUTAL aporta la base; cada equipo construye su motor “distro”. Kitten Space Agency se asienta directamente sobre BRUTAL. Ludeon construye Waylith encima.
Rian Drake, responsable de ingeniería de Ahwoo, clava el nombre en los materiales de prensa. Se llama BRUTAL porque a veces es brutal usarlo, y querían decirlo de antemano. Sin barandillas. Eres responsable de los sistemas que construyes y de los errores que cometes, y también tienes el control para corregirlos. GamingOnLinux y otras piezas secundarias retransmiten esa cita. Drake añade que no creen que todo el mundo deba usar esta herramienta para hacer un juego.
3. La escena Waylith: el matiz entre “helped” y externalizar el motor entero
La entrada de Ludeon del 12 de octubre es la fuente primaria cuyo wording más importa. La actualización 1.7 mueve RimWorld de Unity a Waylith. Waylith se describe como motor interno de Ludeon. El juego se ve y se juega igual; las pruebas dan unas 2–4× de rendimiento. Un stress test de colonia tardía corrió unas 2.2× frente a 1.6. Un pack de 1.500 mods cargó en 6 minutos en lugar de 14. Las partidas pasan entre 1.6 y 1.7. La gran mayoría de mods funciona sin cambios del autor. El cierre da las gracias a RocketWerkz, whose Brutal framework helped make Waylith possible.
Esa palabra *helped* importa. En el relato público, Waylith sigue siendo decisión e implementación de motor de Ludeon. BRUTAL aporta capacidad de framework C# de bajo nivel que ayudó a sacar los últimos restos de Unity. El comunicado de Ahwoo (retransmitido por varios medios) usa una línea similar: Ludeon used BRUTAL to help extract the last bits of Unity out of RimWorld to create their Waylith engine. Decir que “todo el motor de RimWorld se externalizó a RocketWerkz” no encaja con los textos oficiales. Como observación de materiales, la lectura más segura es que Ludeon construyó Waylith y BRUTAL es un framework de bajo nivel acreditado que ayudó.
Para modders, Ludeon lista varios cambios: features más nuevas de C#; mods complejos menos propensos a aplastar el rendimiento; cambios visuales grandes y efectos custom más alcanzables. Más de dos docenas de modders ayudaron a probar antes del debut de Waylith. Esos detalles muestran que el cambio de motor no se agota en cambiar el backend de render. También vuelve a clavar el camino caro de RimWorld—colonia tardía más listas enormes de mods—en un stack .NET mantenible.
La tabla de proyectos del README despliega el uso. RimWorld / Ludeon / Waylith. Kitten Space Agency, Torpedia, Art of the Rail y Gruntz se asientan directamente sobre BRUTAL en RocketWerkz. Afterskies es de Floating Origin Interactive. El comunicado de Ahwoo también dice que el framework sostiene hoy seis proyectos de juego en tres estudios. Menciona a Felipe Falanghe (creador de Kerbal Space Program) colaborando en KSA y usando BRUTAL en su próximo juego. Su frase al pasar de Unity a BRUTAL: al principio un poco intimidante; una vez dentro, posees todo lo creado y sabes cómo opera.
4. Licencia, el eslogan de independencia y cómo usar la incompletud deliberada
BRUTAL es gratis para juegos comerciales, sin royalties ni participación en ingresos. La licencia se basa en MIT con atribución añadida. Un juego o producto debe poner el aviso de copyright en créditos o equivalente, mostrar el logo de BRUTAL antes del gameplay y repartir NOTICE.txt. Si no quieres esos términos, hay licencia comercial aparte. Proyectos sin ánimo de lucro, y casos en que el logo dañaría el propósito de la app, pueden eximir el logo según el README. La licencia aún no se ha enviado a OSI; el equipo dice que pretende enviarla y refinarla con feedback comunitario. Algunos reportes secundarios prefieren por eso “source-available”. El README primario sigue llamándose open source, citando texto de familia MIT y el derecho a hacer fork. En este artículo sigo la autodescripción del README como open source y dejo el estado OSI en la nota de fuentes, para no escribir “aún no aprobado” como “ya aprobado”.
Hall clava el relato con una línea: You are only as independent as your tools are. La independencia mide si las herramientas todavía te escuchan. También traza un límite: no dice que todo el mundo deba hacerse su motor; dice que todo desarrollador debería tener la opción, sin gastar cuatro años en cimientos primero. Game Developer también enlaza el trasfondo público de la disputa de licencia de Unity en 2025, y la preferencia de Hall de que otros hagan frameworks más simples del mismo enfoque en lugar de coronar BRUTAL como estándar único de la industria.
Para indies ese eslogan se oye fácil como ánimo. Contra la forma real de BRUTAL se lee más como contrato laboral. Obtienes interop, colecciones sin asignación, sistema de jobs, bindings de Vulkan y una fila de librerías nativas que cableas tú. No obtienes un editor que abra en un prototipo jugable. El README público también dice que los project files, la solution y los scripts de build desde fuente aún están por llegar; de momento usa NuGet y el repo para leer y hacer fork. Escrituras secundarias como Indie Tooling señalan que el sitio de docs quizá no estaba público el día del lanzamiento, y que macOS, consolas y móvil no son promesas claras en el README actual. Trata esos bordes como observaciones de materiales para tu checklist de selección, no como promesa madura de paquete completo.
Así, el significado accionable de la incompletud deliberada para un equipo indie es concreto. Primero pregunta si tu juego está lejos del caso medio. Si es un título convencional 2D o 3D de contenido, Godot, Unity u un framework más completo suelen costar menos vida. Si el cuello de botella está claramente en asignación, scheduling de jobs, interop nativo o un renderizador que debes poseer, los paquetes de BRUTAL empiezan a valer. Abre una ventana con Glfw o SDL y añade solo los paquetes Memory / Collections / Concurrency que duelen de verdad, en lugar de soñar el motor propio entero el primer día. Lee LICENSE y NOTICE; mete logo y créditos en la checklist de release. Los números públicos de Waylith pueden motivar; no son tu presupuesto. Ludeon tiene gameplay existente, ecosistema de mods y años de C#. Tu equipo quizá no.
Cierre: la independencia se repricia alrededor de saber primero qué quieres
Vuelve a poner BRUTAL en el suelo de producción del otoño de 2026 y lo primero que golpea es un hábito silencioso de producción: asumir motor antes que juego, asumir que la arquitectura la puede wizardizar un editor, asumir que dejar un motor solo le toca a estudios gigantes. RimWorld 1.7 y la apertura de BRUTAL en la misma semana abren otro camino. Hay quien hace juegos directamente sobre el framework. Hay quien construye su motor encima. Ambos exigen escribir requisitos antes de cablear bindings.
Hall dice en el post de Reddit que una de las decisiones más importantes es qué *no* meter en BRUTAL. Léelo al revés. La decisión más cara de un indie suele ser qué no traer. Un sistema por defecto menos es una hipótesis menos que no entiendes pero debes rodear. Más propiedad es más poder de arreglar problemas en la raíz cuando aparecen. Ambos lados son duros. BRUTAL al menos escribe la dureza en el nombre.
Indicaciones ejecutables cortas:
- Escribe primero tres listas: arquitectura que el juego debe decidir solo; partes que puedes dejar a un motor existente; fronteras nativas que tu equipo puede mantener de verdad. Si las tres no encajan, aún no toca BRUTAL.
- Haz un experimento mínimo con NuGet. Core más un paquete de ventana para abrir ventana; luego añade Memory, Collections, Concurrency o abstracciones Vulkan por dolor. Dedica un fin de semana a comprobar si poseer el stack es de verdad más rápido que acomodar un motor.
- Lee la LICENSE antes de comprometerte. Créditos, logo de arranque y NOTICE.txt van en la checklist de release. Si necesitas exención, consíguela por escrito; no la descubras la semana antes del lanzamiento.
- Al leer el agradecimiento de Ludeon, quédate con helped. Un motor propio sigue siendo tu decisión de producto. Un framework solo baja el coste de cuatro años de cimientos; el gameplay y el contenido siguen siendo tuyos.
Estos mensajes de octubre no harán desaparecer los motores generalistas. Solo reprician si las herramientas todavía te escuchan. Quien quiera pagar ese precio ahora tiene al menos fuente legible, paquetes elegibles y una advertencia ya escrita en el README. Se llama BRUTAL. No es cortesía.
Fuentes y lectura adicional
ahwootech/BRUTAL, GitHub README (tomado de main)
Tia Young, Ludeon Studios (2026-10-12) Announcing the Waylith Engine and Update 1.7
GameFromScratch (2026-10-14) RimWorld Dump Unity Game Engine