Quimera Engine: Buscamos colaboradores

[Thund]

Buenas a todos, quería haceros saber que seguimos buscando colaboradores para el proyecto Quimera Engine (motor de videojuegos multiplataforma en forma de librerías de C++). Aunque ya somos unos pocos, sería genial encontrar más personas interesadas en participar en este proyecto open source y gratuito; concretamente hacen falta más programadores en C++ (nivel avanzado), de manera que podamos avanzar más rápido. Recalcamos que no es un proyecto con ánimo de lucro, todos saldremos ganando, pero no dinero.

Si tienes curiosidad, echa un ojo a estos enlaces:

Acerca del equipo: http://quimeraengine.org/index.php/es/theteam

Acerca del proyecto: http://quimeraengine.org/index.php/es/theproject

Tipo de colaborador que buscamos: http://quimeraengine.org/index.php/es/theteam/joinus

Wiki: http://wiki.quimeraengine.org/doku.php?id=es:start

Repositorio y tracker: http://code.google.com/p/quimeraengine/

Cuenta de twitter: https://twitter.com/QuimeraEngine


Gracias por vuestra atención. Saludos.

Thund.

[XÑA]

Precisamente yo voy a dar una charla sobre el tema de juegos multiplataforma la semana que viene.  :)

Yo me he pasado un año conviertiendo un juego/app de Windows Phone, a Windows Forms, después a iOS y finalmente a Android. Para ambos he utilizado Xamarin. Para que te hagas una idea, he utilizado monogame, pero después de que me funcionara, he tenido que dejarlo y hacer un engine mio propio.

Con esto quiero decirte que para mi es un error que os planteeis hacer un engine multiplataforma SIN analizar primero las plataformas. Y sé que no has analizado las plataformas porqué pones en tu roadmap OpenAL para el audio, y yo al menos tuve que descartarlo en Android después de pelearme con él, y creo que ya no se soporta.

Precisamente en esta charla lo que también voy a plantear es qué necesita un engine multiplataforma hoy en día. Algo básico para mi es que soporte la cámara por ejemplo , para hacer Realidad Aumentada, y también que soporte librerías adicionales, que en el caso de Android al final tienes que meterlas de alguna manera, porqué siempre se están añadiendo nuevas APIS que quieres meter ( algo que por desgracia te LIMITA una barbaridad Xamarin)

No quiero desmotivarte, simplemente contarte un poco mi experiencia, para que podáis aprovecharlo e intentar analizar un poco mejor el roadmap y los requisitos.

Por cierto, he visto vuestra página y parece que sólo está realizada la clase Math....¿eso es así?

[Gallo]

Math no se compone solo de una clase, es una libreria completa de clases, pero si, el motor aun está bastante verde, necesita colaboradores para darle un boost.

Creo que cuando se empezó Quimera, Android y iOS no estaban sobre la mesa, no se si hoy en dia lo están, de todas formas no van por ahí los tiros si no me equivoco, el diseño se centra en proporcionar una lib que no dependa de nada mas que de ella misma, y como excepciones Boost e ICU, asi que para el sonido si ha de tener OpenAL, DirectSound y OpenSL , supongo que lo tendrá.

[XÑA]

Ah, vale.... Es que al leer multiplataforma.... ???

[Gallo]

Ya digo, creo que es multiplataforma por no tener dependencias nativas de las plataformas, de hecho para la parte gráfica creo que si que estaba planeado tanto OpenGL como DirectX, tendria que ponerme al dia, o que Thund no los aclare, un update :P.

[Thund]

Por algún motivo que desconozco este foro no me avisa cuando hay respuestas, menos mal que me ha dado por mirarlo.

A ver, el término multiplataforma no tiene nada que ver necesariamente con móviles, más allá de que cada sistema operativo y arquitectura móvil conforman nuevas plataformas. Las plataformas a las que va dirigido el motor en un principio son Windows, Linux y Mac OS.

Conozco Xamarin de haber leído sobre él, pero este proyecto poco tiene que ver con eso, no se trata de tener una capa superior que luego se traduzca a código de la plataforma deseada, se trata de código C++, nativo, a bajo nivel.
OpenAL está aparentemente descontinuada, como bien dices, pero eso no afecta al proyecto, aún no hemos llegado a la capa de sonido así que podemos elegir la librería que queramos (Open AL Soft, por ejemplo, o cualquier otra solución multiplataforma). Eso al final no es lo importante. Lo que importa es que el diseño del motor permita implementar un módulo que integre cualquier librería que elijamos.

Math no es más que un espacio de nombres en el que hay unas 50 clases bien surtidas, documentadas y sobradamente testeadas (más de 4.000 tests por ahora), que se pueden usar independientemente del motor. Además hay otras clases para tipos de datos, una clase string Unicode, clases de alojamiento de memoria, uso de fechas y horas, contenedores... estos últimos no están al 100% pero les queda poco. Antes de llegar a la capa gráfica quedan clases para manejo de ficheros, threading, sistema de plug-ins, utilidades de depuración y medición de performance, logging... Queda un rato, pero todo acaba llegando. Y para que llegue antes, hacen falta más mentes y más manos; planes y capacidad hay, recursos no, ese es el problema, y no podemos pedir financiación porque no habrá retorno de inversión, así que dependemos de la voluntad y el buen hacer de aquellas personas que compartan nuestros intereses.

Agradezco las sugerencias y consejos. Este proyecto lleva ya unos años y sigue avanzando, más despacio de lo que uno quisiera, pero más rápido cada día.

Quisiera aclarar que el roadmap no es más que eso, una intención o una dirección en la que vamos, no necesariamente tenemos que acabar cumpliéndolo al 100% (nadie lo ha hecho jamás, no vamos a ser los primeros :D). Nos adaptaremos a las opciones que tengamos en cada momento y resolveremos los problemas según los encontremos.

Por favor no dudéis en preguntar cualquier otra cosa que queráis. Me pasaré cada poco tiempo, ya que no me llegan los emails.

[pobreotaku]

Después de leer algo del faq, veo que hay que ser español, tener un nivel alto de ingles y ser al menos 3 dan en c++. requisitos con los que no cumplo pes no y llego ni a cinta negra.
He bajado una copia del repositorio con la esperanza de aprender algo de código pero la documentación esta en ingles, cosa que me parece cuando menos rara pues si se planea un desarrollo patrio cundo menos debería documentarce pensando en los paisanos, que ya hay muchos motores por hay y si quiero aprender pues esto ya me pone una primera traba.
Me párese genial que tenga la licencia GPL, pero limitar la participación por la nacionalidad es algo que no termino de entender.

[Thund]

La intención inicial era enfocar el proyecto a la comunidad hispanohablante pero rápidamente uno se da cuenta de que no es práctico. Por un lado, el lenguaje de facto en la informática es el inglés, por suerte o por desgracia, y realmente quien quiera dedicarse a la programación tendrá que aprenderlo, antes o después, si quiere adquirir según qué conocimientos. Teóricamente, las personas que usen el motor no serán recién iniciados en programación sino gente con cierta experiencia, la suficiente como para plantearse hacer un videojuego en C++, que no es cosa baladí. Por otro, si la documentación estuviera sólo en español llegaría a menos gente, de eso estoy seguro, lo cual lo haría menos útil y menos popular; escribir ambas traducciones es posible pero requiere de un tiempo y esfuerzo que no podemos afrontar a día de hoy. Además, que algo tenga una "denominación de origen" no requiere que el idioma en que se presente sea el de origen.
En el foro público, el cual no está activo aún puesto que no ha salido la primera versión, hay una sección para cada idioma con tal de dar soporte en español a quien lo requiera, por comodidad y fluidez.

Lo de ser español está explicado en la web:

Ser español: No, no se trata de un ataque de patriotismo. Somos conscientes de la imagen que tiene el profesional español en el resto de Europa o Norteamérica, tópicos que poco a poco se van disipando gracias al buen trabajo de muchos otros compañeros de oficio. Queremos demostrar que somos capaces de hacer grandes cosas, que tenemos seriedad y buen nivel técnico. Como mínimo, es algo que nos beneficia a nosotros mismos. Es la única forma de labrarnos una reputación que permita atraer inversores, generar nuevas oportunidades de negocio en nuestro territorio en lugar de tener que salir a buscarlas.

Si pudiera, personalmente incluso pediría que fueran de mi ciudad, pero eso no sería realista. De todas formas, esta restricción puede cambiar en el futuro si llegara a ser necesario.

Finalmente quisiera aclarar una vez más que el proyecto está en desarrollo, en una fase temprana. Aún no se puede construir nada con él más allá de usar sus clases por separado.

Un saludo, seguiré estando por aquí para cualquier duda.

[Thund]

Subo el hilo para que más personas puedan ver el anuncio.

[Thund]

En 1 mes acabamos la fase actual de desarrollo, será un buen momento para unirse al equipo.

[Thund]

En menos de una semana empezará la fase 2 de desarrollo de Quimera Engine. Entre otras muchas cosas, el trabajo de esta fase estará focalizado en:

-Manejo de errores
-Trazado de la pila de llamadas
-Sistema de ficheros.
-Mecanismos de entrada/salida.
-Utilidades para el desarrollo multihilo.
-Extensiones trasversales (nuevas utilidades para tipos, delegados, eventos).
-Obtención y medición real del tiempo.

Recuerdo a quien le interese participar que aún es un buen momento para unirse al equipo y estar presente en la reunión de inicio de fase que tendrá lugar dentro de poco.

Un saludo a todos.

[Thund]

La Fase 1 de desarrollo ha acabado:

http://quimeraengine.org/index.php/es/home-es/16-estado-del-proyecto/48-phase1ends-es

Ya estamos trabajando duro en la Fase 2  :D

• Multithreading
• Call stack tracing
• Timing
• Streams
• File system management

etc.

[Thund]

Seguimos buscando colaboradores.
Lo upeo y de camino comento que estoy evaluando varios IDEs multiplataforma para migrar los proyectos que actualmente están en Code::Blocks. La razón de esto es que el soporte de CB en Mac es muy deficiente. Los IDEs que estoy mirando son QtCreator, NetBeans y CodeLite. De momento, el que mejor se ajusta anuestras necesidades es CodeLite. Su interfaz es similar a la de Visual Studio y no tiene ninguna de las carencias (para nuestras necesidades) que tienen los demás. Lo único malo es que el "IntelliSense" no es muy bueno, pero nada más. Si alguien lo ha utilizado y conoce algún problema gordo que debiera tener en cuenta antes de elegirlo le agradecería que lo dijera por aquí :)