Ésta es una de las preguntas más recurrentes cuando alguien quiere empezar a desarrollar videojuegos, así que me tomé el tiempo para dar una explicación un poco larga, abarcando las principales posibilidades:

Personalmente he trabajado con UnrealEngine3 (aún no he trabajado mucho con el 4), he probado el CryEngine3, he hecho algunas cosas con Unity3D, y también he trabajado en un engine propietario, así que aquí pongo mis comentarios y elimino algunos tabús:

Unity3D

Este es por  mucho el más amigable de todas las otras opciones; reduce en mucho la curva de aprendizaje, por lo que podrás tener algo funcional corriendo en poco tiempo sin mucho problema.. Así que si tienes un equipo sin mucha experiencia creo que éste es un buen motor para ti y tu equipo, además de que está diseñado para el flujo de trabajo de equipos pequeños… Otra diferencia importante es que, a diferencia de los otros, está diseñado para permitirte hacer tanto juegos 2D como 3D… En general ha estado madurando mucho en los últimos años, pero definitivamente el UnrealEngine y CryEngine aún le llevan mucha ventaja…. muchos de los juegos para móviles están hechos con este motor, entre los juegos más famosos hechos con él están Monument Valley, Threes, Hearthstone y Stick it to the Man.

UnrealEngine

El Unreal es un motor diseñado principalmente para juegos FPS online multiplayer (de hecho, siendo más precisos, el UnrealEngine ES por sí mismo un FPS online multiplayer), pero lo puedes modificar para hacer otro tipos de juegos (yo lo utilicé durante el desarrollo de Lucha Libre AAA Heroes del Ring, y The Last Day on Earth)… quizás es el motor más utilizado en juegos AAA para PlayStation3/PlayStation4 y XBox360/XBone.. incluyendo toda la serie de Dragon Age, los Mass Effect, Gears of War, Infinity Blade (para iOS), X-Com Enemy Unknown, Tom Clancy, Batman Arkham XYZ, Medal of Honor, Mortal Kombat, Borderlands, Deus X, Bioshock Infinite, Metro 2033, etc etc etc…

Una ventaja es que Unreal te ofrece el código fuente completo, y si quieres podrás modificar lo que necesites para lograr tus metas. La desventaja del Unreal es que no es tan fácil para el usuario entry-level, aunque ahora en el 4 con los “blue-prints” podrás programar muchas cosas visualmente por nodos sin meterte a el código de C++ (no lo he usado a fondo, así que no te puedo dar una opinión certera de su alcance). Su flujo de trabajo está diseñado principalmente para equipos multidisciplinarios más grandes… pero definitivamente tiene mucho más cosas que Unity aún carece (aunque son cosas mucho más especializadas que un juego casual probablemente no necesitará nunca).

CryEngine

Por su parte, CryEngine es la competencia directa del UnrealEngine, sin embargo éste fue diseñado de propósito general (no como el Unreal que su arquitectura esta diseñada para un juego FPS), personalmente se me hace más limpio de trabajar con el CryEngine que con el Unreal, también está diseñado para que su flujo de trabajo sea para equipos multidisciplinarios más grandes… las cosas “core” del juego las programarás en C++ y el sistema de scrip está en LUA.. y tiene algunas cosas que el UnrealEngine no (un lenguaje visual para I.A, por ejm)… me parece más amigable para Entry Level que Unreal, y también tiene todo el código fuente disponible, pero no es taaan amigable como Unity.

Conozco menos juegos hechos con el CryEngine, entre algunos de ellos están Far Cry, Crysis, The Collectibles (iOS), Ryse Son of Rome, EVE Online…

Uno propio?

En el proyecto que estoy actualmente utilizamos un engine propio, lo cual tiene muchas ventajas, y contrario a la opinión popular no se requiere un ejército de programadores (somos si mucho ~20 programadores en todo el equipo desarrollando el juego), pero definitivamente requieres de un equipo de personas más especializado, por lo que si no tienes gente con el perfil, probablemente no sea lo que busques (e intentar aprender mientras desarrollas el juego probablemente no sea la mejor opción)…

¿por qué no requieres un ejército como la gente que trabaja detrás de Unity / Unreal / CryEngine?… simple y sencillamente por que tu motor estaría hecho específicamente para hacer únicamente las cosas que tu juego requiere y para sacar ventaja para optimizarlo específicamente para las plataformas a las que lo vas a dirigir, buscando alcanzar el hardware más austero posible (lo cual aumenta tu mercado), podrás lograr el estilo artístico exacto que buscan tus artistas, y además podrás diseñar el flujo de trabajo para optimizar los tiempos de los artistas, los creadores de contenido y los game designers de acuerdo a cómo fluirá la producción del juego (lo cual a su vez reduce costos)… además de que podrás reutilizar la base para tus próximos proyectos sin tener que pagar licencias..

Nota que mucha gente cree que cuando uno habla de “hacer tu engine” significa escribir absolutamente todo desde cero, y volverlo a hacer desde el principio para cada nuevo juego que hagas (lo cual sería absurdo y rompe con la regla básica de reutilización de código); pero si necesitas gente de experiencia para saber (dependiendo del juego que vas a hacer) qué tanto se va a desarrollar in-house y qué tanto te vas a apoyar en otras librerías existentes… por ejemplo, si tu juego no va a hacer nada especial con el audio, pues utiliza FMOD, si no hay nada especial que vayas a hacer con tus modelos puedes utilizar el FBX SDK, si no vas a hacer nada especial con las texturas, pues utilizas una biblioteca para cargarlas.. ¿no?…

Sin embargo, aunque los programadores más novatos dirán que para qué querrían ellos hacer un exportador de texturas (o los que no son programadores), la gente que tenga ya más experiencia podrá tomar ventaja de cosas particulares del juego y sacarle provecho al programar su propio exportador de otra forma… por ejemplo, en mi caso me tocó modificar el sistema de exportación de texturas en The Sims 4, para tomar ventaja de algunas cosas particulares del sistema de compresión que tiene el juego, y logramos reducir en 20% el espacio en disco para los recursos (que se traduce en aumentar un 20% el mercado potencial al que puedes llegar y por ende aumentar las ventas de tu juego… ya que en una compu de las viejitas no es lo mismo que te digan que requeires casi 4Gb de espacio en disco para instalar el juego, a que te digan que requieres 3.1 Gb)… pero es algo muy particular del juego que probablemente no funcionaría en otros casos… (aunque, nuevamente, eso requiere de gente con más experiencia).

Pero definitivamente la decisión de hacer un motor propio es más complicada que utilizar uno ya existente, ya que tendrás que evaluar muchos factores, como el alcance de tipo de juego(s) que quieres hacer, si cuentas con gente con el perfil y si estás esperando un cierto número de ganancias $ de tu juego..

Hay juegos chicos y grandes que tienen su propio motor, como FEZ, Cut the Rope o Attractio del lado de los más chiquitos, o del lado de los más grandes juegos como Assassin’s Creed, Mario Galaxy, World of Warcraft, Uncharted, The Sims, The Last of Us, Sim City, The Order 1886, etc…

Lo de utilizar DirectX / OpenGL no tiene que ver directamente con si escoges un motor o desarrollas el tuyo propio, incluso Unity tiene una interfaz para que puedas trabajar ciertas cosas a nivel de OpenGL si así lo requieres (y ni se diga con el Unreal o CryEngine donde tienes el código fuente completo)… o en el caso contrario, incluso si vas a hacer tu propio motor podrías utilizar alguna librería (o motor gráfico como también les llaman) como Irrlitch u Ogre y de ahí constuir el motor de tu juego… OpenGL / DirectX son solamente parte del proceso… si tienes gente que lo sabe seguro te abrirá muchas puertas y te sacará de muchos apuros, si no, quizás no siempre puedas hacer exactamente lo que quieres, pero tampoco te cerrará por completo el camino si nadie sabe…

Sé que hay personas que no entiende bien por qué hay gente que prefiere hacer su propio motor en lugar de utilizar uno existente (el tiempo los hará más sabios al intentar comprender los diferentes puntos de vista):

Como analogía, en el caso particular de un cocinero… la diferencia radica en que el cocinero puede saber que si combinas aceite de oliva con orégano y una pizca de sal puedes darle un sazón especial a ciertos platillos, o bien.. puede simplemente utilizar un sazonador pre-hecho que aunque quizás no sea exactamente el sazón que buscaba, igualmente lo hará saber bien (y hasta le ahorrará tiempo).

O visto en términos artísticos: trabajar con un motor sería el equivalente a trabajar con un “auto-rig” para la animación de personajes, un auto-rig está pensado para trabajar con personajes estándar, y quizás el 90% de las veces eso funcionará, y está bien, te hace más productivo el equipo, y eso es bueno…

pero también habrá casos en que tus personajes tengan alguna funcionalidad extra que será difícil cubrir con las opciones que te da un auto-rig… como por ejemplo, si una de las extremidades funcionara de forma inversa a lo normal, o (en el caso particular de CAT), las espinas dorsales funcionan de tal forma que es difícil lograr rigs de serpiente…

En esos casos, si tienes a alguien en el equipo que sepa rigguear, pues seguramente preferirás que él se encargue de crear el rigg y asegurarse de que funcione de la forma cómo se busca para los personajes de ese juego en particular… ¿no?…  pero si nadie de tu equipo sabe rigguear, pues quizás solo te quede hacer algo que se acerque suficientemente al movimiento de la espina dorsal de una serpiente en medida de lo que puedas (así como el sazonador del cocinero)…

o ya viéndolo de manera práctica, como el ejemplo de las texturas que mencionaba arriba..

Pero cualquier cosa está bien!.. nadie te reclamará!.. te lo aseguro 😉

Todo es cuestión de qué tanto “poder de hacer” tienes en tus manos. =)

Saludos!