Unreal Engine contra todos: motores de juego que perdieron la competencia con Epic Games

Unreal Engine se está convirtiendo gradualmente en el estándar de la industria, desplazando los motores propietarios de los estudios. Todo se utiliza: desde la simplificación de las herramientas hasta el dudoso cabildeo de intereses en grandes empresas. Analizamos por qué los desarrolladores abandonan tecnologías que se han creado durante décadas y qué implica la dependencia de Epic Games.

Hubo un tiempo en que el mercado de los motores de juego ofrecía docenas de opciones interesantes. Muchas herramientas demostraban sus puntos fuertes y mostraban a los desarrolladores por qué un motor era mejor que los demás. Por lo tanto, la elección se convertía en una confrontación ideológica. Pero la era de la «diversidad» terminó. Hoy vivimos en un mundo donde la mayoría de los estudios de juegos pequeños, medianos e incluso grandes prefieren usar Unreal Engine. Por él, muchos abandonan sus propias tecnologías en favor de una supuesta simplicidad, accesibilidad y una rica reserva de empleados que no necesitan ser capacitados.

Pero una sombra oscura crece con la creciente popularidad de Unreal Engine. A pesar de su amplia difusión y el amor de los estudios, sigue siendo uno de los motores más controvertidos entre los jugadores. Caídas de fotogramas, imágenes borrosas debido al escalado agresivo, artefactos gráficos al borde de la desintegración de la geometría, una carga increíble en el hardware que llega hasta los bloqueos y la pantalla azul de la muerte, todo esto es una parte obligatoria de cualquier proyecto en Unreal Engine.

Por eso es irónico observar cómo un motor que elimina a sus competidores, paradójicamente, a veces muestra resultados terribles donde otros motores, que fueron abandonados, funcionaban perfectamente. Y nuestra selección es un réquiem por los gigantes caídos y simplemente por las buenas herramientas que Unreal Engine envió al basurero de la historia. Y al mismo tiempo, un intento de entender por qué el ganador que se apoderó de la industria todavía nos hace recordar con tristeza los tiempos en que los juegos «volaban» y las «tecnologías antiguas» no se creaban con inteligencia artificial.

Unity

Durante mucho tiempo, Unity y Unreal Engine ocuparon nichos diferentes. Unity era la opción principal para proyectos indie, móviles y AA, ofreciendo a los desarrolladores una herramienta accesible y universal con soporte para múltiples plataformas. Unreal, por el contrario, se asociaba principalmente con grandes juegos AAA. Sin embargo, con la llegada de Unreal Engine 5, esta división comenzó a desaparecer: Nanite, Lumen, World Partition y otras tecnologías hicieron que Unreal fuera más universal, y sus herramientas permitieron a los estudios no perder tiempo en desarrollar su propia base tecnológica.

La situación para Unity se complicó aún más por la crisis de confianza tras el anuncio de la Runtime Fee en 2023. La compañía tenía la intención de cobrar una tarifa en función de las instalaciones del juego, lo que provocó protestas entre los desarrolladores. Y aunque la compañía abandonó esta idea en septiembre de 2024, muchos desarrolladores indie ya habían comenzado la transición a Godot o Unreal Engine. Y las grandes empresas incluso informaron directamente a Unity que no pagarían por las descargas.

Paradójicamente, a medida que Unreal Engine se fortalecía, comenzó a «absorber» el ecosistema de Unity. Apareció un conjunto completo de herramientas que simplifican la transferencia de contenido a Unreal. Incluye la transferencia de escenas, la exportación automatizada de activos, así como herramientas que traducen las estructuras de Unity a sus análogos en Unreal. Cabe destacar la influencia de las propias comunidades. También han desarrollado herramientas completas para convertir el lenguaje C#, en el que funciona Unity, a C++, el lenguaje de programación de Unreal Engine 5.

Pero la etapa más importante de la «derrota» de Unity fue la inesperada asociación con Epic Games, anunciada a finales del año pasado. Sin embargo, esta colaboración difícilmente puede considerarse equitativa. Los proyectos de Unity se integran libremente en UEFN, el editor de modos para Fortnite. No se anunció una transferencia libre de juegos de Unity a UE y viceversa. Al mismo tiempo, Unreal Engine recibió soporte en el sistema comercial multiplataforma de Unity para la gestión de catálogos, pagos y tiendas en PC, dispositivos móviles y consolas. Es decir, Unity ofrece mucho más que Epic Games.

REDengine

REDengine fue durante mucho tiempo uno de los componentes más importantes del éxito de CD Projekt RED. El estudio utilizó su propia tecnología desde «The Witcher 2», desarrollándola gradualmente para RPG cada vez más ambiciosos. Fue en REDengine 3 donde se creó «The Witcher 3: Wild Hunt», y su siguiente versión se convirtió en la base de Cyberpunk 2077. La principal ventaja del motor propio era la capacidad de adaptarlo directamente a las tareas de CD Projekt RED: los desarrolladores controlaban todo el proceso tecnológico y podían crear herramientas especializadas para animaciones complejas, mundos abiertos y tramas no lineales. Por lo tanto, REDengine no puede considerarse un «motor problemático». Incluso después de la transición a Unreal Engine, los veteranos de CDPR afirmaron estar orgullosos de su propia tecnología.

El principal problema de REDengine residía en el coste de su desarrollo. Cada nuevo juego requería una adaptación y expansión significativas del motor, y para ello era necesario contar con un equipo de programadores independiente, que en algunos casos podía superar el número de personas que trabajaban en la creación del juego. Esta fue la razón oficial que CD Projekt RED dio para abandonar REDengine. El estudio quería una base más predecible y eficiente, ya diseñada para los mundos abiertos modernos.

Otra debilidad de REDengine estaba relacionada con las versiones de consola. En general, los juegos de CDPR se mostraban como obras maestras potentes pero muy caprichosas. Los desarrolladores admitieron que no era fácil garantizar un funcionamiento estable en diferentes hardware al mismo tiempo. Si en PC mostraban excelentes gráficos, en consolas los desarrolladores tenían que reelaborar el motor e introducir soluciones provisionales para que los lanzamientos funcionaran correctamente. Los desarrolladores de «The Witcher 2» para Xbox 360 tuvieron que ajustarse a los 512 MB de RAM asignados, lo que perjudicó los gráficos. En la tercera parte también se observaron caídas de fotogramas, especialmente en lugares densamente poblados como Novigrad. Digital Foundry registró caídas de aproximadamente 25 FPS en PS4 y una tasa de fotogramas inestable en Xbox One. Y los problemas de optimización en Cyberpunk 2077 resultaron en un escándalo global, por el que el cofundador de CDPR, Marcin Iwiński, tuvo que disculparse públicamente.

Sin embargo, la razón clave para la transición a Unreal Engine estaba directamente relacionada con el personal. El conocimiento de la tecnología propia estaba muy ligado a empleados específicos y estaba mal documentado. Antiguos empleados admitieron que una parte significativa del conocimiento antiguo se transmitía literalmente «de mayor a menor», y al intentar volver a las tecnologías antiguas, el estudio tenía que reconstruirlas prácticamente desde cero. En este contexto, Unreal Engine no solo proporcionó a CDPR una base tecnológica lista, sino también un amplio mercado de especialistas ya familiarizados con el motor.

Como resultado, REDengine no perdió ante Unreal Engine en una competencia directa de capacidades; CD Projekt RED decidió por sí misma que ya no quería participar en la carrera de sus propias tecnologías. La nueva estrategia del estudio prevé el uso de UE5 para toda una generación de proyectos: la nueva saga The Witcher, su remake y el próximo juego de Cyberpunk se basan en la base tecnológica de Unreal. Afortunadamente, la experiencia adquirida durante años de trabajo con REDengine no ha desaparecido: los propios desarrolladores señalaron que muchas de las innovaciones de ingeniería, metodologías y conocimientos pueden transferirse a UE5.

Blam! y Slipspace

La historia del motor propio de Halo comenzó con Bungie y BLAM, en el que se crearon prácticamente todos los juegos clásicos de la serie. Después de que la franquicia pasara a manos de Microsoft y se creara 343 Industries, el motor continuó evolucionando junto con Halo, y antes de la creación de Halo Infinite, el estudio presentó Slipspace Engine, un Blam Engine modificado. 343 Industries declaró que la nueva tecnología debería ser la base para el futuro de Halo y permitir la implementación de ideas mucho más ambiciosas. Según el propio estudio, se creó una nueva infraestructura tecnológica para Halo Infinite.

Esto finalmente se convirtió en uno de los principales problemas de Slipspace Engine. El motor permitió crear un Halo Infinite técnicamente complejo con un mundo abierto, grandes distancias de renderizado, gráficos modernos y numerosas mecánicas, pero su desarrollo tuvo un costo enorme en recursos humanos. En 2024, los líderes de Halo Studios reconocieron que una parte significativa de los empleados de 343 Industries estaba ocupada desarrollando y manteniendo el motor propio en lugar de crear juegos directamente. Además, algunos componentes de Slipspace tenían casi 25 años, y nadie en 343 Industries podía parchearlos.

El problema de personal se agravó por la práctica de Microsoft, que también se extiende a los estudios internos. Halo Studios combinaba empleados a tiempo completo con contratistas. Según Engadget, muchos productores junior y empleados de QA trabajaban bajo contrato, y su duración promedio era de hasta 18 meses. Como resultado, el estudio experimentó una alta rotación de personal y una ineficiencia en el proceso de producción, donde un nuevo empleado tardaba más en aprender los fundamentos del motor de lo que duraba su contrato.

En este contexto, se decidió cambiar por completo el enfoque de desarrollo de la serie. En 2024, 343 Industries se renombró como Halo Studios, y la compañía anunció oficialmente que los futuros proyectos de Halo se crearían con Unreal Engine 5. Para probar la nueva tecnología, el equipo creó Project Foundry, un proyecto de investigación que permitió probar UE5 aplicado a las especificidades de Halo. Se prestó especial atención a Nanite y Lumen, que permitieron obtener mundos más detallados y a gran escala sin la necesidad de crear tecnologías similares de forma independiente. Al mismo tiempo, la política de personal del estudio no cambió. Pero ahora simplemente se pueden contratar freelancers que hayan aprendido Unreal Engine a través de materiales de capacitación en Internet.

Diesel Engine

Motor interno creado por el estudio GRIN. En él se desarrollaron la dilogía Ghost Recon: Advanced Warfighter y Bionic Commando. Tras la quiebra del estudio, sus antiguos desarrolladores continuaron utilizando su propio desarrollo, pero ya en el estudio OVERKILL. Entonces crearon la serie de juegos PAYDAY. A lo largo de los años de desarrollo, el motor se adaptó bastante bien a las especificidades de la serie: cooperativo, entorno destructible, gran cantidad de armas y objetos, y lo más importante, la adición constante de nuevo contenido.

Sin embargo, los desarrolladores se enfrentaron al mismo problema que el resto de los propietarios de motores propios. Necesitaba ser actualizado regularmente. Esto requería personal experimentado y fondos. Y Starbreeze, que en ese momento había comprado OVERKILL, se enfrentó a graves problemas financieros y de producción. La compañía adquirió otro motor de juego, Valhalla, pero no cumplió con las expectativas. Al final, Starbreeze eligió Unreal Engine para sus futuros proyectos. Es significativo que Overkill’s The Walking Dead se desarrolló inicialmente en Diesel, luego se transfirió a Valhalla y finalmente se lanzó en UE4. Debido a esto, el tiempo de desarrollo se prolongó considerablemente y el proyecto en sí fracasó.

Cuando llegó el momento de Payday 3, el estudio decidió no repetir el error. El juego se creó desde el principio con Unreal Engine 4. Esto ofrecía ventajas obvias: Unreal tiene un amplio ecosistema de especialistas y tecnologías listas. Sin embargo, la apuesta por Unreal no dio el resultado esperado. Payday 3 se lanzó con serios problemas y no cumplió significativamente las expectativas de los fans, y en los años siguientes Starbreeze se vio obligada a trabajar en la recuperación del juego y, al mismo tiempo, a mantener a su predecesor más exitoso. La brecha entre los dos juegos se puede observar en los indicadores en línea. El número promedio de jugadores en Payday 2 es de 30 mil. Al mismo tiempo, en Payday 3 juegan no más de 2-3 mil usuarios.

La historia del soporte de Payday 2 puede considerarse un tipo de comedia aparte. El soporte iba a ser prácticamente descontinuado en 2019 después de la finalización de la trama. Starbreeze planeó inicialmente desarrollar la segunda parte hasta esa fecha, para luego centrarse en Payday 3. Sin embargo, la crisis financiera de la compañía y la posterior reestructuración obligaron a continuar el soporte para evitar la bancarrota. En 2020-2021, el juego recibió una nueva trama, DLC y actualizaciones regulares. En 2023, en vísperas del lanzamiento de PAYDAY 3, el equipo completó nuevamente el ciclo principal de desarrollo de la segunda parte: el último capítulo importante de la trama fue Crude Awakening, y la actualización de septiembre se presentó como un conjunto de mejoras finales. Parecía que la historia de PAYDAY 2 había terminado, pero en octubre de 2025, Starbreeze transfirió inesperadamente el soporte de la versión para PC a Sidetrack Games, un equipo externo con profundas raíces en el modding de Payday 2.

Y aquí ocurrió una paradoja interesante. Mientras Payday 3 en Unreal seguía luchando por la audiencia, el viejo Payday 2 en Diesel recibió una importante actualización del propio motor. En junio de 2026, el nuevo equipo de desarrolladores lanzó la beta abierta de Diesel 3.0: el motor se trasladó a una arquitectura de 64 bits, el renderizador se actualizó a DirectX 11, se rediseñó el sistema de empaquetado de recursos, se aumentó la velocidad de carga y, lo más importante, se redujo el tamaño del juego de 86 a 32 GB.

Diesel Engine resultó ser mucho más resistente de lo que probablemente esperaban los propios desarrolladores. Incluso después de que Starbreeze abandonara el desarrollo de su propio motor, este siguió existiendo gracias al propio Payday 2: primero se mantuvo para preservar los ingresos para un mayor desarrollo, y luego los propios fans se unieron a su desarrollo. Durante 10 años, los modders estudiaron tan bien la estructura interna del juego y su código que pudieron crear su propio contenido, correcciones y nuevas mecánicas.

id Tech

Si buscamos un ejemplo de motor cuyo destino parece incierto, id Tech es el que mejor encaja. La tecnología, que durante décadas fue la base de DOOM, Quake y Wolfenstein, ha sobrevivido a varias generaciones y en los últimos años se consideraba uno de los motores más potentes para shooters en la industria. id Software utilizó su propio motor como una ventaja en el mercado. Y las innovaciones que aparecían en los juegos del estudio se convertían en ejemplos para la competencia.

Sin embargo, este verano Microsoft llevó a cabo una reestructuración masiva de XBOX, en la que 136 personas fueron despedidas de id Software. Especialmente preocupantes fueron los informes de despidos directamente entre los especialistas que trabajaban en id Tech. Según Game Developer, los recortes afectaron a una parte significativa del equipo de ingeniería, incluidos los programadores principales y el director técnico. Uno de los empleados despedidos afirmó que la compañía perdió una enorme cantidad de experiencia acumulada y que ahora es prácticamente imposible imaginar la creación del próximo gran juego en id Tech. Y el colmo de la tragedia fue la noticia de que solo una persona se encarga ahora del soporte de id Tech.

Sin embargo, Microsoft declaró una posición completamente diferente. Según su declaración, decenas de especialistas de otros estudios, incluido MachineGames, continúan trabajando en id Tech, y la dirección de id Software enfatiza que el equipo del motor está «vivo y bien». Pero muchos observadores señalan que los jugadores verán las consecuencias reales en el futuro.

No hubo confirmación oficial de que Microsoft ordenara a id Software cambiar a Unreal Engine. Microsoft niega los planes de cerrar id Tech, y la dirección de id Software continúa hablando públicamente sobre el desarrollo de sus propios juegos y tecnología. Por lo tanto, es más correcto considerar la transición a Unreal no como una decisión establecida, sino como un escenario potencial. La paradoja radica en que id Tech posee las cualidades por las que otras compañías abandonan sus motores: es una tecnología madura, adaptada a un tipo específico de juegos y profundamente integrada con el proceso de producción del estudio. Pero si Microsoft ya no está dispuesta a mantener al equipo que soporta el capital tecnológico acumulado durante décadas, entonces el siguiente paso lógico podría ser realmente abandonar el motor propio en favor de una plataforma lista de Epic Games.

En este sentido, la historia de id Tech puede convertirse en uno de los ejemplos más ilustrativos de la tendencia actual. Unreal Engine puede deshacerse de un competidor no porque sea mejor, sino porque Microsoft puede decidir que mantener a decenas de especialistas altamente remunerados para su propia tecnología es más caro que simplemente usar una plataforma lista.

El mundo del motor irreal

Unreal Engine ha formado una imagen bastante específica. No se le puede llamar el mejor motor de juego desde un punto de vista técnico: existen tecnologías propietarias que, con un trabajo de equipo competente, demuestran un rendimiento excelente y están mucho más adaptadas a tareas específicas. Por ejemplo, RAGE, CryEngine e id Tech. Este último también demuestra lo lejos que se puede llegar con una base tecnológica propia: la estrecha conexión entre los desarrolladores del motor y el propio juego permite optimizar la tecnología durante años para un género y hardware específicos. Unreal, en cambio, a menudo tiene que ser configurado y optimizado adicionalmente por los propios desarrolladores: Epic ofrece un enorme conjunto de posibilidades, pero esto no significa que el juego funcionará automáticamente como debería.

Sin embargo, Unreal gana en otro campo: la accesibilidad. Se puede descargar fácilmente desde Epic Games Store, y los materiales de capacitación están disponibles públicamente y se actualizan constantemente. Las empresas ya no necesitan capacitar a nuevos empleados sobre cómo usar sus desarrollos. Es mucho más fácil y económico contratar a un diseñador de juegos que haya dominado Unreal Engine y asignarle un conjunto de tareas de inmediato. Además, Epic ha convertido el motor en una plataforma masiva que genera grandes cantidades de dinero en forma de regalías por las ventas de juegos.

Y aquí se manifiesta la principal diferencia entre Unreal y un motor propio. La tecnología propietaria se desarrolla con los recursos del propio estudio, mientras que Unreal continúa desarrollándose con los recursos de Epic Games. El desarrollador obtiene acceso a nuevas versiones del motor sin pagar el mantenimiento de todo un equipo de ingenieros que tendría que crear todo desde cero. Y esta alternativa parece ideal para aquellos estudios que ya no quieren o no pueden financiar su propia carrera tecnológica.

Sin embargo, en este momento se convierten en rehenes de Tim Sweeney. Tienen que adaptarse a las tecnologías que Epic considera prioritarias y a los cambios que aparecen en las nuevas versiones del motor. Especialmente revelador es el anuncio de Unreal Engine 6: Epic planea trasladar el modelo de programación a Verse, implementar herramientas basadas en inteligencia artificial e integrar un modelo contextual tipo Claude y Codex. Por lo tanto, la pregunta principal hoy es qué estudio está dispuesto a mantener sus desarrollos y seguir evolucionándolos.