¿Hace falta hacer un engine?

[Kabila]

Para las personas que se empeñan en hacer motores de juego (engines) aqui les dejo un link de quien ha hecho algunos

http://altdevblogaday.com/2011/12/17/why-on-earth-would-we-write-our-own-game-engine/

[XÑA]

Buenísimo!!!  ;)

[Vicente]

Muy bueno si señor :)

[Mars Attacks]

Pues sí. ¡Gracias por el enlace!

[Eskema]

Es algo que siempre he defendido, pudiendo usar un engine que funciona y te va a ahorrar mucho tiempo no veo el interes en crear un engine salvo que quieras aprender todas las cosas internas y quieras ampliar tu conocimiento en vez de hacer un juego

[Warchief]

Tiene puntos interesantes, pero se deja muchos puntos negativos aparte. Trabajar con motores licenciados no es la panacea, y depende de bastantes factores que sea una buena idea o no (tiempo, dinero, equipo, objetivo, plan, ...)

Una cosa importante escondida en el texto es esta: "In the end, we chose to buy, not build. Here are our reasons ..."
Es decir, esto son razones para su decisión, que se aplican a su empresa/juego/situación actual.

Él mismo comenta esto:

Management chose to acquire Criterion and its successful Renderware graphics library and have it used by as many teams and games as possible. This made some logical sense, but the strategy backfired. Renderware was acquired on the strength of Renderware 3.7 on the Playstation 2, but then Renderware 4.0 was adopted for the Playstation 3. Renderware 4.0 was a ground-up rewrite that was not ready for prime time. To make it worse, we all grossly under-estimated the cost of transitioning to a new render engine.

Uhm, un momento. Esta absorción se parece a licenciar un motor: te comes un código que no está listo, dos versiones para dos plataformas, y para colmo tu equipo no sabe nada de él. El fracaso al parecer estuvo en intentar construir un motor encima de ese motor, que algunas veces es lo que necesitas, porque las features que tu quieres no están implementadas en el motor que licencias (a menos que quieras hacer un clon de otro juego que ya esté hecho con ese motor).

Hay varias opiniones en los comentarios al artículo con algunos puntos en contra, así que no pondré aquí los míos a menos que haya interés (soporte, actualizaciones, conocimiento, reusabilidad, nuevas plataformas, dependencia, motivación, etc, etc.)

Yo no tengo 15 años de experiencia, pero he trabajado 4 años con proprietary engines y 2 con licenciados, o debería decir X años con híbridos (algunas partes in-house y otras licenciadas) que es lo más común, y cada uno tiene sus cosas buenas y malas. Como ejemplo de lo que quiero decir, diré que yo he hecho un juego para iPhone en unos 2 meses directamente sobre opengl, haciendo un pequeño motor 2D que puedo reusar para hacer otros juegos parecidos. Licenciar Unity podría haber sido una peor idea para lo que yo necesitaba.

Mi punto no es "siempre construir motor propio", sino "depende", incluso si eres un indie. Al licenciar un motor te puede pasar esto:



Y también se puede tener éxito con motores propios:
RedLynx developed Trials HD using an in-house engine coupled with a modified version of Bullet Physics Library which was optimized to utilize the Xbox 360's CPU and vector units. El truco aquí fue acertar en qué parte no implementar.

[Eskema]

Tu lo has dicho, todo depende de tus necesidades del momento. Crearte un motor 3d no son 2 tardes y hagas lo que hagas nunca estaras a gusto usando una herramienta propietaria porque siempre le faltan cosas o el workflow no es como te gustaria.
Hacer un juego en 2d y crearte una pequeña libreria no es complicado yo mismo lo hice, pero moverte en aguas 3d no es tan facil y para indies no creo que haya otro camino que usar unity o unreal u otro engine suponiendo que quieras hacer algo en un tiempo razonable.
O por lo menos asi lo veo yo

[Warchief]

Temple Run, por ejemplo, es 3D. Ignoro si usa motor propio o licenciado, pero no veo como Unity o Unreal podrían ser mejores que usar openGL directamente. Unreal tiene un code bloat considerable, y Unity para móviles ya requiere desembolsar $400 por plataforma si no me equivoco, por no hablar de que no tienes acceso al código fuente, así que como tengas bugs o cartacterísticas que faltan te las puedes ver negras. El tiempo que ganas por las características ya implementadas, lo puedes perder aprendiendo el motor y lidiando con bugs a través del soporte técnico.

Si tuviera que hacer un juego como Temple Run, es probable que no usara un motor licenciado (para gráficos ni física). Sin embargo, sí usaría librerías como openFeint, antes que construir una red social similar. Este es el juego si no lo conocéis:
http://itunes.apple.com/app/temple-run/id420009108
http://www.youtube.com/watch?v=cJwkboCnzKE

Hay otros factores aparte del tiempo: dinero, plan de empresa, equipo, motivación, soporte necesario, tipo de juego, características necesarias del motor, lenguaje de programación, ...

[XÑA]

Yo prefiero hacer un engine, pero soy consciente de lo que cuesta eso. Sin embargo es la  mejor forma de aprender, y te enseña a entender cómo funcionan los engines licenciados.

Habláis de Unity como si fuera un gran middleware, y sinceramente, para mi adolece de un montón de fallos. Fallos que te tienes que tragar hasta que descubres que es un fallo. Recuerdo que en el juego que hice de la bola que cae, tenía que asignar 2 veces la variable a un valor, porqué si no, no se asignaba!! O las sombras, que resulta que el sistema que llevaba era sencillamente horrible. Por suerte, todo esto lo van arreglando, pero es tiempo que te lleva a ti aprender de los errores y de las limitaciones.

[Gallo]

pero no veo como Unity o Unreal podrían ser mejores que usar openGL directamente

No tiene nada que ver usar OpenGL directamente a usar Unreal o Unity. El que no usa Unreal o Unity es simplemente por que o bien no se adaptan a sus necesidades o bien no tienen recursos, pero son la primera opción que yo pondria sobre la mesa en lo que a juegos 3D se refiere. Piensa que OpenGL es solo una API gráfica, no te da nada mas que eso, pintar poligonos, que hay de la gestión de memoria, la escena, animaciones, controles, gestión de assets, etc?

Yo he probado algunos motores y frameworks, y mi favorito para juegos 3D es Unreal, que es con el que he desarrollado un juego completo. No he tenido oportunidad de volverlo a utilizar sencillamente por que necesita un equipo muy potente de 4 o 5, modeladores incluidos, dispuestos a aprender a utilizarlo y explotarlo al máximo.

Si no vas a explotar las características de Unreal o quizá buscas abarcar el mayor numero de plataformas, probablemente sea mejor Unity tanto para juegos 3D como 2D.

Aún sin equipo ni recursos hay muchos frameworks / motores gratuitos o muy baratos antes que utilizar directamente OpenGL y otras apis de bajo nivel, y que ahorran muchisimo trabajo y prácticamente tienes el mismo control. El único motivo que yo veo por el una empresa pequeña o un indie se vaya a hacer un motor propio hoy en dia, es simplemente por que lo que hay disponbile no cubre las necesidades/plataformas que necesita o requiere tener control total sobre las características del motor.

[Eskema]

Obviamente se nota que soy novato y un engine 3D esta fuera de orbita para mi, porque yo si que pondria encima de la mesa a unity como bien dice Gallo, en cierto sentido muchos programadores somos unos "maria manias" y siempre queremos el codigo como a nosotros nos gusta (me incluyo aqui) y aprender a usar el codigo/engine de otros se vuelve una montaña y le sacamos fallos por doquier.
¿Por que quieres crearte un engine 3D propio que siempre sera "peor" que unity o unreal, pero estas dispuesto a tragar con openfeint o bullet/box2D (para fisicas)?, total para almacenar unos scores online no necesitas usar openfeint..... ¿no? ya sé, es un ejemplo cutre.....

Yo hace tiempo que uso unity y no lo cambiaria por nada, tiene sus fallos como todo pero es "barato" (400€ no son una brutalidad, 3000€ por la pro ya joden mas) y tiene mucho middleware para facilitarte la vida, asi puedo centrarme en mi juego. Como todo en esta vida te tiras 1 mes aprendiendo como va, pero en mi caso si comparo 1 mes aprendiendo unity con 3-6 meses para crearme un engine 3D, la cosa no tiene color

[yorch]

No me he leído todo el thread, y mi experiencia con engines y en el área es bastante, bastante limitada, pero creo que el punto del artículo (y en parte relacionado con el debate que propone Warchief), es el desarrollo multi plataforma. Unity en parte tiene resuelto el grueso de móviles (y web, y flash... y parece que lo que venga  :)), ya sólamente por eso parece que merece la pena. Mantener un engine es un curro bastante grande si necesitas que tu juego esté en varias plataformas (diferente memoria, diferentes optimizaciones para la CPU/GPU, diferentes capas para el middleware... etc). Si tienes recursos como EA o un desarrollador AAA pues a lo mejor te lo puedes permitir, pero para una start-up y si el juego no necesita los últimos avances en gráficos... quizás un engine te vale.

Aún como dice un desarrollador en los comentarios de AltDevBlogADay (web muy interesante, BTW), la decisión también depende de cuál sea tu lado de la barrera (por ejemplo: si te hace falta Nintendo DS o si quieres desarrollar para PSVita ya... pues las empresas de engines o middleware a lo mejor no te dan soporte todavía). Desde luego si sólo te enfocas en Android o iPhone quizás te interesa hacerte tu motor. Como dicen, también depende de la empresa o los recursos que tengas... si te puedes permitir aprender a hacer o si sabes hacer lo que te ofrecen los engines o el middleware. Por ejemplo, con audio pasa bastante: en general no hay gente con la formación que hace falta o no hay tiempo necesario para hacerte una implementación de un algoritmo de resampling, o programarte una reverb o un codec personalizado...

[Eskema]

Todo depende de tu negocio, si curras para otros como yo no puedes crear una tecnologia porque la mayoria no la quiere, todo el mundo te dice, "quiero un juego X hecho con el engine X o el Y dame precio". Asi que salvo que trabajes para ti mismo en tus propios proyectos, la opcion de "mi propio engine" esta descartada/fuera de lugar.

Es un debate muy tipico este, cada opcion es perfectamente valida y buena :)

[Mars Attacks]

Aunque sea típico, es muy conveniente saber en qué casos a unos y a otros les ha ido bien o mal con cada opción. Nosotros tuvimos muy malos resultados para nuestro primer juego de iPhone (estuvimos como tres meses trasteando con varios motores y luego otros tres meses lidiando con el elegido, con Eloy constantemente diciendo que si le dábamos un par de semanas hacía un port de su motor a iPhone). Finalmente el juego salió con muchísimas más limitaciones de las esperadas y, cuando Eloy tuvo ese tiempo un poco después, efectivamente en dos semanas teníamos el motor (que ya soportaba PC y medio PSP en ese momento) y la posibilidad de desarrollar en paralelo para PC, PSP e iOS.

Unity en aquel tiempo era un pastizal y, por lo que se comentaba, el rendimiento era malo en iPods de segunda generación (lo más que había en aquél entonces). Aún así, lo probamos, y enseguida nos encontramos con montones de problemas de workflow. El juego era 3D, así que Cocos2D no era una opción (y aunque hubiera sido 2D, Objective C y nuestro equipo no tienen buenas relaciones). Crystal3D era tan a bajo nivel que para programar ahí, lo mismo daba que Eloy hiciera su port. Y llegamos a probar otro que no recuerdo cuál era.

Ahora mismo, aunque es cierto que mucho tiempo de Eloy se va puramente a tecnología, al tener el motor tan integrado en el workflow podemos asumir proyectos de desarrollo rápido (por supuesto, que estén dentro de un conjunto de restricciones que cada vez son menores ya que va integrando funcionalidad bajo demanda). ¿Que alguien nos pide un proyecto con un determinado SDK de pagos? Pues se le mete. ¿Que sale una plataforma nueva que nos interesa? Pues también se le mete, y al estar chachimente organizado todo, podemos tener el mismo juego al momento en otros chismes. A costa del 33% de nuestra potencia de programación de juegos, eso sí. Pero así, él se entretiene y nos deja en paz...

[XÑA]

Este Eloy es mi dios!!  :D

Yo ahora mismo estoy programando un engine básico para un proyecto que me han pedido para windows.
Para Windows Phone, también lo estoy desarrollando todo, porqué no hay engine que trague con los requerimientos de la aplicación.
Para Android, utilizo Corona, pero os prometo que he estado a punto de decir: ¡basta! ¡Aprendo OpenGL y lo hago yo! Pero la compatibilidad me puede por ahora...y la pereza de programa en Java con Eclipse...

Supongo que en poco tiempo esto se normaliza un poco.. Ah no!!! Que ahora Windows 8 viene con DX 11.1 y todos los ejemplos son en C++!!!  :'(