Hola de nuevo!

Hace una temporadilla que no me meto en el foro porque el curro me absorbe demasiado tiempo. Pero bueno, vamos al tema, que tampoco os voy a contar mis penas :P .
Mi idea inicial de crear una API de alto nivel me sigue pareciendo interesante como proyecto experimental, pero estoy completamente de acuerdo en que no sería factible a la hora de programar un juego real, por muchas de las razones que ya habeis expuesto entre unos y otros. De modo que voy a modificar la propuesta, a raiz de una de las respuestas que he visto y que me ha parecido especialmente interesante (que nadie se piense que la idea ha sido mia).
La intención de crear una API multi-engine es la de establecer un mecanismo para distanciarse de la implementación real del juego y centrarse en la definición. Pero como la idea de la API no ha triunfado, una alternativa es definir el juego mediante un lenguaje (XML por ejemplo). Este lenguaje tendrá una sintaxis tal que permita establecer todos los aspectos del juego (igual que se haría con un lenguaje imperativo), pero será totalmente independiente de todo lenguaje de programación. De esta forma, y una vez definido el juego, se podrá usar el archivo (o archivos) XML como entrada para un transformador que lo traduzca a un lenguaje de scripting determinado (Lua, por poner un ejemplo) o directamente a código fuente ejecutable. De esta forma una única definición de juego podría producir mediante procesos automáticos varias implementaciones en distintos motores.

Por supuesto, y dada la complejidad de cualquier juego, harían falta editores y herramientas de alto nivel que permitan definir el juego sin tener que escribir el código XML a mano; de lo contrario, y ya que un juego sencillito podría facilmente ocupar varios archivos enlazados con cientos de líneas de código, escribiendo todo esto a mano sería una tarea tan costosa como programarlo directamente, y no estaríamos avanzado mucho.

Además un lenguaje así podrá ser fácilmente extensible a medida que surjan nuevas posibilidades en los motores de juego. Y si este lenguaje consiguiera ser aceptado como estándar por algún organismo oficial (esto ya es puramente fantasear, claro), los propios desarrolladores de motores (en especial los comerciales) fabricarían los traductores para sus productos.

Esto me lleva a plantearme como evolucionaria el mercado de videojuegos en general si existiera realmente un estandar de definición de juegos (como lo es HTML para la WWW). (¿O existe y no estoy enterado, que podria ser?) Pero no creo que sea este el hilo para hablar del tema.

Bueno, que empiezo a desvariar. Este es el nuevo planteamiento a grosso modo, aunque con el mismo objetivo inicial: olvidarse de programar juegos para dedicarse únicamente a diseñarlos. Espero con cariño un nuevo aluvión de críticas. :P  :P

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.

[API]

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).

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.