Proyecto: API Multi-Engine

[luiinge]

Buenas a todo el mundo.

Estoy comenzando un nuevo proyecto a título personal en mi tiempo libre y, debido a mi poca disponibilidad por mis compromisos del curro y de que me autoimpongo vida social para no acabar loco, yo solo no voy a poder ocuparme de ello en la vida. No tengo claro si esto de compartir proyectos llega realmente a buen puerto (lo intenté hace un par de años en otra comunidad y la cosa no fue como me esperaba), pero todo es intentarlo.

Bien, antes de nada, hay que decir que mi proyecto NO es un juego. Estas cosas siempre empiezan con buenas ideas y mucha ilusión, y luego la falta de medios y/o conocimiento llevan al fracaso, decepción y traumas infantiles. Yo opino que antes de diseñar un juego hay que tener bien claro qué medios técnicos hay a disposición y ser consecuente con ello. En particular, a la hora de escoger un motor. Y con esto entro en el tema.

Existen cientos de proyectos de motores de juego. Algunos libres, otros comerciales, y otros internos de empresas. Unos son motorcillos simples para los juegos más simples, otros extrujan las posibilidades del hardware más puntero del mercado. Pero básicamente (y más a nuestro nivel, que no es comercial ni mucho menos) todos los motores hacen lo mismo. De modo que escoger uno u otro para un determinado proyecto va a influir en el resultado pero no en el proceso de desarrollo (no debería, al menos; habrá casos que sí, como todo en la villa del Señor).

Así que la idea que lleva tiempo rondándome es que, en lugar de implementar un motor, es mucho más interesante definir una API común a todo motor de forma que a la hora de programar, el programador se olvide un poco de si es OpenGL o DirectX, y piense únicamente en sprites, modelos, etc. sin preocuparse de qué motor se encargue de moverlo todo. La API de desarrollo estará conectada por debajo con uno o varios motores, a modo de plugins. Esto presenta varias ventajas, tal y como yo lo veo:

1) Un juego programado mediante una API se podría probar con distintos motores sin tener que cambiar una sola línea de código, y de ahí escoger cual ofrece mejor rendimiento al juego.
2) Desarrollar varios proyectos con la misma API ayuda al aprendizaje del programador, sin necesidad de aprender el lenguaje de un nuevo motor para cada proyecto distinto.
3) Se pueden desarrollar varios niveles de la API, extendiéndola para abarcar nuevas posibilidades a medida que aparezcan. Por ejemplo, un nivel básico manejaría gráficos 2D y sonido, un segundo nivel lo extendería a gráficos 3D y red, un cuarto a características como cell-shading, etc. Para un proyecto sencillo se usaría un nivel bajo y para proyectos complejos otros niveles.
4) La conexión entre la API y los motores subyacentes se realizará por puentes (en términos de programación) de modo que se puede desarrollar en paralelo puentes para varios motores.
5) Muchos otros que en cuanto se me ocurran los pongo.

La idea a grandes rasgos es diseñar y analizar la API en su nivel más básico, implementar uno o dos conectores a motores sencillos, y a continuación probarlo con un juego pequeñito. Si la cosa demuestra ser útil se continuaría el proceso hacia niveles superiores.

Para la primera fase no se necesita ni programadores ni grafistas, únicamente gente que tenga experiencia con motores orientados a objetos y que aporte conocimiento de como debería ser una API bien diseñada.

Bueno, y de momento como presentación vale. Espero que haya alguien interesado en participar, si no me ocuparé yo en solitario y me llevará algo de tiempo, pero bueno...

Un saludo y gracias por leer este tostón.

[Pogacha]

Estas confundiendo algunos terminos creo yo:
API -> OpenGL, DirectX o ...
Motor -> Wrapper de OpenGL y/o DirectX que puede tener muchos layers y te abstrae del API ...

Tal vez entendí todo mal pues lo escrito parece no tener logica.
Saludos.

[luiinge]

Bueno, yo creo que estoy hablando con bastante propiedad. Aun así, vamos a concretar los términos:

API

Una API (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) es un conjunto de especificaciones de comunicación entre componentes software.

(Wikipedia)
Hablando de API me refiero únicamente a una interfaz de programación en su sentido amplio. OpenGL y DirectX son APIs, desde luego, igual que Windows tiene su propia API, y como todo componente software que diseñe.

Motor

Game Engine o Motor de Juego hace referencia a una serie de rutinas de programación que permiten el diseño, la creación y la representación del juego.

(Wikipedia)
El motor de un juego es únicamente una librería implementada con las rutinas que permiten programar el juego. Y aunque normalmente se suele denominar motor únicamente a la parte gráfica, el término en sí se refiere a cualquier componente del juego (gráficos,sonido,dispositivos,red,hilos,gestión de recursos, etc).
[Editado, antes habia puesto algo que no era del todo cierto]
OpenGL y DirectX se pueden considerar tanto simples librerías como motores en sí, dependiendo del criterio que usemos. Los wrappers de los que me hablas son motores que internamente pueden usar estas u otras librerías, pero lo importante es que en cualquier caso el motor dispone de su propia API que normalmente suele ser más abstracta que la de la librería en sí.

Lo que intentaba explicar es la posibilidad de crear una API con un nivel de asbtracción superior (y sobretodo, independiente) de las APIs concretas de los motores (que a su vez proporcionan APIs de nivel superior a la de las librerías), y conectable a ellas mediante puentes. No se si esto te ha aclarado algo; si sigues sin verle la lógica escribiré un post más detallado aclarando todos los puntos.

Además, la idea no se me ha ocurrido a mi exclusivamente (todo esta ya inventado en esta vida). En la web DevMaster hay algún ejemplo de proyecto con una arquitectura parecida (ahora mismo no recuerdo cual).

[Pogacha]

Tal ves otro pueda decirte mejor entonces.
Saludos y suerte.

[tewe76]

A ver si yo lo entiendo :):
Lo mismo que hay engines que permiten usar OGL o DX indistintamente y de forma transparente al usuario del engine (al programador, no al jugador), tú quieres crear una API que permita usar cualquiera de los motores 2D y 3D ya existentes o cualquiera de los que se puedan crear en un futuro.
Yo creo que es éso lo que dices, pero creo que es evidente que es MUY complejo, a parte de que habría que ir actualizándolo contínuamente, según aparezcan nuevos motores. A no ser que esta API se convirtiera en un estándar universal y todo el que crease un nuevo engine lo hiciera cumpliendo las especificaciones de tu API.

No sé, lo veo complicadísimo y personalmente creo que algo así no merecería la pena. Si a OGL y DX les cuesta mantener la compatibilidad, debido a la rapidez con la que avanzan estas tecnologías, a tu API aún más.

También es posible que no te haya entendido bien :)

[luiinge]

Correcto, es a eso a lo que me refería.

En cuanto a tu crítica la agradezco (si lo publico en un foro es precisamente para ver si a la gente le parece buena idea o es solo una paja mental mía), pero no la comparto.
Veamos, para empezar, quiero dejar claro que no pretendo realizar un estándar mundial para la creación de videojuegos (ya me gustaría, pero hay que ser humildes). Esto es meramente un proyecto experimental que tengo ganas de hacer, y es perfectamente posible que al final no consiga cumplirlo. Pero la idea en sí a mi me parece buena y me gustaría ver hasta donde se puede llevar a cabo. Lo de merecer la pena o no es cuestión de opiniones... A mi por ejemplo no me merecería la pena escribir un pacman en DirectX porque es algo hecho mil veces y realmente no aporta nada (excepto experiencia personal). Cada uno tiene sus gustos, y a mi me da por lo retorcido.

Respondiendo a las pegas:
No se trata de implementarlo para todos los motores que existan (dada la cantidad que hay, eso sería simplemente imposible). La idea es que, una vez definida la API, se vaya probando inicialmente con dos motores distintos (los más sencillos que se encuentren por ahí), y dependiendo de si el resultado es satisfactorio, continuar o no. En cuanto a la complejidad... tiene su miga, desde luego, pero si los motores usados tienen suficiente nivel de abstracción, crear un puente de una API a otra es meramente un trabajo de traducción; si el gap semántico entre las dos APIs es más grande la faena se complicaría, pero sigo opinando que es algo abordable.
Con respecto a lo de tener que mantener continuamente las versiones de cada motor, tampoco veo claro a que te refieres. Si lo dices por el tema de que cada vez los motores proveen de más funcionalidades, la respuesta es que no se pretende recoger todas las opciones que ofrezcan todos los motores y actualizar la API cada vez que salga algo nuevo en un motor, sino las operaciones comunes a todos. Y si se construye un puente, se realizara con una versión concreta de un motor, y aunque salgan versiones posteriores, se espera que ofrezcan una compatibilidad hacia atrás que no obliguen a reescribir el puente (al igual que no obligaría a reescribir un juego escrito con ese motor).

De todas formas tampoco se debe ver la API como un todo compacto, sino como un conjunto de interfaces que se pueden extender unas a otras. , y empezando por las cosas más sencillas y comunes. Si aparece una funcionalidad nueva en el mundo de los motores de forma general, se podrá considerar extender la API para cubrir esa nueva funcionalidad. El único inconveniente (que para mi no es tal) es que al extender la API un puente viejo podrá no proveer las nuevas funcionalidades. ¿Pero y qué? Una API no obliga a implementar las cosas realmente, y si vamos a programar un pacman no nos importa que el puente no implemente efectos de partículas o cosas así, porque no vamos a hacer uso de ellas.

En fin, todo esto es complicado de explicar mediante posts. Necesitaría páginas y páginas para detallar la arquitectura que tengo en mente. De todas formas quiero agradecer que esteis opinando al respecto, aunque no esteis de acuerdo con la idea.

[Zaelsius]

No sé, no le veo ninguna ventaja real. Conseguir una API unificada, que permita acceder al 100% de DX/GL es casi imposible(y menos por una sola persona). Y para hacer algo más simple o incompleto, ya están las rutinas de rendering de los motores 3D.

En realidad lo que propones ya existe, se llama OpenGL, pero a Microsoft no le gusta jugar con otros si no es con su pelota..

Si a tí te gusta lo que haces, adelante.. pero desde la perspectiva de los que hacemos juegos, no es algo que nos facilite la vida. Y los que hacen motores, dudo que quieran desprenderse del control directo sobre cada API, más aun teniendo en cuenta las diferencias entre ambas.

[[EX3]]

Sin animos de avivar el fuego pero no estoy deacuerdo con esto:

El motor de un juego es únicamente una librería implementada con las rutinas que permiten programar el juego. Y aunque normalmente se suele denominar motor únicamente a la parte gráfica, el término en sí se refiere a cualquier componente del juego (gráficos,sonido,dispositivos,red,hilos,gestión de recursos, etc).
[Editado, antes habia puesto algo que no era del todo cierto]
OpenGL y DirectX se pueden considerar tanto simples librerías como motores en sí, dependiendo del criterio que usemos.

Lo que yo y mucha gente entendemos por motor es "algo", libreria o ejecutable, que se basa generalmente en un esquema de programacion "pre-establecido" al que con escasas funciones y poca programabilidad (a veces desde script) esta hace "algo" concreto ya sea cargar, texturizar y animar un modelo o cargar, iluminar y colocar entidades en un escenario o cualquier cosa automatizada por llamarlo de alguna forma. Ni DirectX ni OpenGL hacen algo asi ni por asomo dado que son API's de bajo nivel y esto implica que si el programador quiere cargar un modelo, texturizarlo e intepretar las animaciones tiene que programar una parrafada de codigo que le puede llevar desde una semana a meses incluso, cuando un motor generalmente te permite hacer esto en 5 minutos escasos y sin tener ni idea de como aplicar texturas, crear un buffer de vertices y ordenarlo, ni muchas otras funcionalidades a bajo nivel.

Los wrappers de los que me hablas son motores que internamente pueden usar estas u otras librerías, pero lo importante es que en cualquier caso el motor dispone de su propia API que normalmente suele ser más abstracta que la de la librería en sí.

Un wrapper no es mas que una libreria que hace que en vez de llamar a 20 funciones para hacer una tarea tengas que llamar a una sola y aqui se aplica mas o menos la misma filosofia que un motor pero no suele llegar al mismo nivel dado que un motor suele estar diseñado para un tipo o genero de juego y un wrapper para algo general. En definitiva un wrapper generalmente evitara que sepas como crear un buffer de vertices, como texturizarlo y como proyectarlo, por ejemplo, dado que habra una funcion que lo haga de forma transparente al programador.

Amen de esta opinion o punto de vista sobre que es o deja de ser un API, un motor y un wrapper, decir que tu proyecto me resulta muy interesante y que si llegaras a llevarlo a buen puerto y lograras mantener una buena conjuncion entre los motores que corrieran por debajeo seguro que seria un proyecto la mar de util, pero tambien estoy deacuerdo con los demas en que es un proyecto muy complejo de desarrollar dado las grandes diferencias no de rendimiento si no de implementacion de funciones de cada API y cada motor existentes, sobre todo en motores dado que como te dije cada motor suele estar diseñado para un proposito mas o menos concreto, y unificarlos aprovechando lo maximos posible su potencial seria una tarea de titanes, de lo contrario solo lograrias limitar las capacidades de cada motor en afan de lograr un equilibrio entre motores o librerias, no se si me explico.

Aun con todo esto, por que no, intentalo. Todos nos hemos embarcado en proyectos similares y bien unos han llegado lejos y otros se han quedado por el camino o siguen en desarrollo. Aun asi ten presente el consejo de los demas ya que su experiencia vale su peso en oro.

Salu2 y suerte...

[Hans]

A mi me parece un buen proyecto pero te digo una cosa, yo estoy usando ahora mismo dos motores al mismo tiempo y haciendo código para ambos a la vez y hasta la mayor de las paridas (bueno, depende de cómo se mire) necesita rebuscar código para lograr hacer lo mismo.

Ejemplo: cuando llegué en la empresa se estaba usando un cargador de vídeo vía Direct Show que básicamente lo que hacía era coger directamente los píxeles de cada frame del vídeo ya decodificado y cambiar esos píxeles por los píxeles de una textura ya cargada en memoria (lo explico de manera básica para que se entienda pero la verdad es que yo mismo me pierdo la mitad de las veces xDD) El caso es que tuve que portar ese sistema a Ogre (estábamos usando Irrlitch) y realmente no me costó nada (media hora entre buscar las funciones de apertura del pixelbuffer de la textura y cosas así) pero era una parida y tardé media hora conociendo el motor. Y lo mejor viene ahora que tenemos que portarlo a Linux donde Direct Show como que no existe y la solución pasa por mirarnos el tema de decoders xDDD Menos mal que en Ogre existe un plugin para reproducir Ogg y ya lo tengo montado pero en Irrlitch va a ser otro cantar, aunque quizás se pueda aprovechar ese mismo plugin y sus funciones.

Lo que quiero decir es que a parte de encontrarte con mil trillones de cosas que investigar por cada motor (y hay muchísimos) encima te vas a tener que comer el coco con todos sus plugins, con todas sus actualizaciones que cambian mil cosas cada vez, con dos APIs diferentes y además con mínimo dos sistemas operativos diferentes (a menos que te quieras centrar únicamente en Windows o Linux). Es un proyecto titánico, al menos mientras todo lo que quieres "wrappear" no sea un estandar y dudo que lo sea de aquí a nunca.

[fjfnaranjo]

Me parece una idea buena, pero extremadamente compleja para una iniciación, como parecía destacar el tono de tu primer mensaje.

No obstante, lejos de calificarla como imposible, hace 10 años los juegos te daban la opción de jugar con Software, OpenGL o DirectX (por no hablar de otras como glide...) y actualemnte algunas arquitercturas de motores de videojuegos siguen contemplando esa posiblidad (un clarísimo ejemplo en el Unreal Tournament 2004, que aun te da a elegir entre OpenGL y DirectX). Además, existen algún que otro proyecto de motor que permite comunicarse tanto con una API como con la otra.

En definitiva, que a lo mejor sería más interesante programar un motor (que no deja de ser una API si nos ponemos cansidos con el nombre) utilizando un planteamiento modular, y programar conectores para los dos APIs existentes (en vez de tanta capa y capa, que eso se come el rendimiento), ahora, que como ya he dicho hace un momento, eso ya está hecho, y no solo en el UnrealEngine, si no también en otro proyecto amateur que no recuerdo muy bien, pero que básicamente era un motor con dos interfaces, una para cada API (creo que lo ví en estos foros...)

[tamat]

Yo personalmente creo que es un trabajo muy dificil y que no aporta mejoras reales, y te enumero algunas de las razones:

- No es cierto que cada engine es igual, lo cierto es que cada engine persigue un mismo fin pero todos suelen abordar ese fin desde perspectivas muy diferentes. Algunos estan pensados para usar una pipeline determinada, otros para construir la escena usando un tipo de arbol especifico (o layers), etc. Por lo que conseguir abstraer todo eso implicaría no exprimir al 100% la arquitectura de un engine determinado.

- No todos los engines tienen las mismas funcionalidades, en la linea de mi anterior punto, soportar todas las features de todos los engines (a nivel abstracto me refiero) complicaría muchisimo la programacion, e ignorar funcionalidades implicaría no aprovechar el engine que hay debajo, y buscar un compromiso a eso no sirve.

- No todos los engines te permiten abstraerte de ciertas cosas, por ejemplo, para referirte a un elemento de la escena algunos usaran handlers, otros punteros, otros strings, no veo la manera de unificar eso si no es encapsulandolo lo cual puede llevar a más capas que afecten al rendimiento de manera notable.

- El problema de los elementos de bajo nivel, por ejemplo la clase Vector3, ¿implementaras una propia? ¿usará metodos virtuales para acceder a los metodos basicos de la clase vector? en tal caso la perdida de rendimiento será brutal, si por el contrario decides reescribir las llamadas para que hagan llamadas al API especifico entonces hay dos llamadas por llamada (que aunque con el tema inline se pueda acortar sigue siendo algo chapucero).

Dicho todo esto creo que sí que existe una posibilidad dentro de tu proyecto que podria ser interesante, pero no es la de hacer un API generico, sino la de crear un protocolo o formato de fichero para describir un juego, y que luego cada engine importe de ese fichero aquello que pueda aprovechar. Dentro del fichero especificas recursos, scripts, shaders, etc.

Así es como lo veo yo.

[Fran]

Yo personalmente creo que es un trabajo muy dificil y que no aporta mejoras reales, y te enumero algunas de las razones:

- No es cierto que cada engine es igual, lo cierto es que cada engine persigue un mismo fin pero todos suelen abordar ese fin desde perspectivas muy diferentes. Algunos estan pensados para usar una pipeline determinada, otros para construir la escena usando un tipo de arbol especifico (o layers), etc. Por lo que conseguir abstraer todo eso implicaría no exprimir al 100% la arquitectura de un engine determinado.

- No todos los engines tienen las mismas funcionalidades, en la linea de mi anterior punto, soportar todas las features de todos los engines (a nivel abstracto me refiero) complicaría muchisimo la programacion, e ignorar funcionalidades implicaría no aprovechar el engine que hay debajo, y buscar un compromiso a eso no sirve.

- No todos los engines te permiten abstraerte de ciertas cosas, por ejemplo, para referirte a un elemento de la escena algunos usaran handlers, otros punteros, otros strings, no veo la manera de unificar eso si no es encapsulandolo lo cual puede llevar a más capas que afecten al rendimiento de manera notable.

- El problema de los elementos de bajo nivel, por ejemplo la clase Vector3, ¿implementaras una propia? ¿usará metodos virtuales para acceder a los metodos basicos de la clase vector? en tal caso la perdida de rendimiento será brutal, si por el contrario decides reescribir las llamadas para que hagan llamadas al API especifico entonces hay dos llamadas por llamada (que aunque con el tema inline se pueda acortar sigue siendo algo chapucero).

Dicho todo esto creo que sí que existe una posibilidad dentro de tu proyecto que podria ser interesante, pero no es la de hacer un API generico, sino la de crear un protocolo o formato de fichero para describir un juego, y que luego cada engine importe de ese fichero aquello que pueda aprovechar. Dentro del fichero especificas recursos, scripts, shaders, etc.

Así es como lo veo yo.

Eso lo ves interesante? Como de interesante?

[[EX3]]

también en otro proyecto amateur que no recuerdo muy bien, pero que básicamente era un motor con dos interfaces, una para cada API (creo que lo ví en estos foros...)

Podria ser el Sandra Engine?

Salu2...

[ferminho]

Yo te apoyo con la idea, sobre todo porque me parece algo viable y útil, y el principal motivo de esto es que... mi trabajo se basa en desarrollar precisamente lo que expones.

Ahora, creo que quizá es algo ligeramente distinto. Nosotros lo hacemos a un nivel muy abstracto, el usuario de nuestra API no tiene que saber *nada* del motor que se use por debajo, más que en todo caso, los formatos de mapas y geometría que utiliza. Todo lo demás se abstrae en una API de alto nivel, con su propio modo de tratar el "mundo 3D".

Aunque en principio pueda parecer complejo, no lo es tanto. Cuanto más acceso a bajo nivel se le intenta dar al usuario, entonces más complejo se vuelve porque más diferentes son los motores que hay por debajo. Por eso creo que lo interesante de la idea es para proporcionar una API de alto nivel, sin meter al usuario en términos de cada motor (que si handlers numéricos, cadenas, objetos...).

Para las distintas capacidades de cada motor, por ejemplo, nosotros tenemos un sistema de "querying". Puedes preguntarle a la API qué permite el motor actual y qué no, en términos del nivel abstracto al que trabaja la API, y trabajar con lo que ofrece e ignorar lo que no.
En fin, que ánimo con el proyecto, que te aseguro que resulta muy interesante ;)

[fjfnaranjo]

"]

"]

también en otro proyecto amateur que no recuerdo muy bien, pero que básicamente era un motor con dos interfaces, una para cada API (creo que lo ví en estos foros...)

Podria ser el Sandra Engine?

Salu2...

Si es que no me acuerdo, pero era en una discusión de si usar OpenGL o DirectX, creo, y creo además que en estos foros, rebusca con el buscador :P.

En mi opinión, añadir capas y capas lo único que hace es tirar por los suelos el rendimiento, en cosas como el sistema de entidades, o los motores de colisiones, esta perfectamente justificado y de hecho lo recomiendo ad nauseam, pero si encima del api, y del salto de arquitectura entre OpenGL y DirectX, le añades una capa más a todo eso que haga de interfaz, no va a ser rentable en tiempo de proceso ..., por no decir que cada vez que salga una tecnología habra que tocar en todos lados código.....

Claro que es mi opinión personal, tampoco soy un programador de motores ni nada de eso, pero cójete cualquier proyecto profesional que haya liberado su código y fijate en el lenguaje en que esta programado el motor (ojo, el motor): simple y llanamente "C", y si ponen alguna capa es para el modder de turno que quiere convertir el juego en otra cosa.