Proyecto: API Multi-Engine

[marcode]

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.

Se necesita disponibilidad, experiencia, diversidad de conocimientos, ganas.... Va a ser difícil que encuentres un grupo así, pero a lo mejor podrías conseguir que participasen todos los usuarios, ¿cómo?. Pues proponiendo cada parte del diseño en un mensaje en estos mismos foros. Seguro que al cabo de los días la idea general (que es la que interesa) estará más o menos clara, y aquí hay gente de todo tipo para aportar conocimientos, soluciones, ideas, enlaces o documentación, críticas sin piedad, código, etc. Por otro lado la aprobación de todos hasta en el más mínimo detalle garantiza que lo que estás haciendo sirve realmente.

[luiinge]

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

[Fran]

Yo estoy ya en ello. Tengo visor y demás

[tamat]

Cualquier juego necesita logica de juego y eso no lo puedes definir simplemente "en XML", tienes que casarte con algun lenguaje que permite escribir la lista de acciones que se llevan a cabo en cada momento.

Mirate las especificaciones del ECMA Script, del que hereda Javascript y Action Script. Es una base.

Creo que fuí yo el que te recomendé esta idea pero yo me refería mas especificacmente a que los engines soportasen directamente ese XML como input, no que existieran conversores a lenguaje nativo. Mi framework actualmente ya funciona así, le puedes pasar un XML con todo (texturas, modelos, y en un futuro logica) y lo procesa.

Suerte.

[alberizo]

opino como casi todos, una abstraccion inmensa, además que te tienes q conocer las decenas de motores que quieras usar....

la unica cosa que me plantearia, seria hacer un lenguaje standard, y que tu programa lo traduzca a cada uno de los distintos motores (capando las cosas que el motor no soportase), y cada motor podria crear su propio traductor, al estilo de importadores y exportadores como plugins

[Fran]

Cualquier juego necesita logica de juego y eso no lo puedes definir simplemente "en XML", tienes que casarte con algun lenguaje que permite escribir la lista de acciones que se llevan a cabo en cada momento.

Mirate las especificaciones del ECMA Script, del que hereda Javascript y Action Script. Es una base.

Creo que fuí yo el que te recomendé esta idea pero yo me refería mas especificacmente a que los engines soportasen directamente ese XML como input, no que existieran conversores a lenguaje nativo. Mi framework actualmente ya funciona así, le puedes pasar un XML con todo (texturas, modelos, y en un futuro logica) y lo procesa.

Suerte.

Totalmente de acuerdo. El mio te permite enlazar eventos a muchos de los objetos que tiene descritos en XML y enlazar esos eventos a métodos Java. Además te permite data binding con un servidor, etc,etc...