¡Hagamos nuestro engine!, losersjuegos necesita ideas...

[hugoruscitti]

Buenas a todos, ¿como están?.

Hoy hablando con un amigo (karucha) surgió un tema
interesante:

Actualmente hay varios engines, bibliotecas y herramientas
para hacer juegos. Pero muy pocos exploran por completo
lo que nos gustaría ver en una biblioteca de juegos.

La que mas se acerca es pygame, y luego la sigue cocos2d. Pero
es difícil usarlas si no eres un programador que habla o puede
leer inglés (por la documentación digo.)

Entonces charlando sobre bibliotecas y pensando en el futuro
surgieron varias ideas interesantes:

¿Que tendría que tener una biblioteca de videojuegos nueva y
diferente para utilizar?

¿y si escribiéramos una biblioteca los desarrolladores
de losersjuegos?, ¿que tendría que tener?.

Creo que desde hace años venimos aprendiendo juntos sobre
juegos y a esta altura tal vez podamos hacer una biblioteca
que se adapte mejor a lo que nos gusta hacer.

¿Que les parece a ustedes?, ¿ideas?

[hugoruscitti]

Dejo algunas ideas basicas de lo que me gustaría...

Que esté orientada a novatos, desarrolladores casuales o futuros programadores

No todas las bibliotecas deberían hacerce asumiendo que
quien está frente al equipo es un programador. A mi me gustaría
ver una biblioteca que le permita jugar a mi sobrino, que se vea
en la escuela y sea divertida... seguramente eso ayudará a motivar
a nuevos programadores, pero no necesariamente.

Creo que una forma de lograr esto es tener objetos prediseñados
listos para usar. Así los nuevos desarrolladores pueden empezar
a hacer algo útil sin arrancar desde cero:

por ejemplo, que tenga un objeto PacMan ya creado, que uno
pueda poner en pantalla escribiendo algo como:

Código: Seleccionar todo

player = Pacman()
player.x = 30


o para hacer una explosión en un juego de naves:

Código: Seleccionar todo

boom = Boom()
boom.position = (40, 40)
screen.add(boom)


Luego si a esa persona la interesa hacer cosas mas complejas, que pueda
hacer sus propios objetos o personajes sería ideal....

Esto es algo que lamento de pygame, si quieres hacer algo divertido como
un prototipo de colisiones o física, tienes que invertir al menos una hora
en construir objetos, recolectar imágenes y hacer el esqueleto del juego...

Que su documentación primaria esté en español

Generalmente los proyectos de software se documentan el inglés, y luego
en algunos casos muy populares se traduce a otros idiomas (como el español).

Pienso que esto no siempre debería ser así, hay muchas bibliotecas documentadas
en inglés. Si hacemos nuestra biblioteca tendríamos que crear documentación
en español, nuestro público habla en español, sería genial que lo pueda
hacer en su idioma.

Un proyecto de software no es solo código, también necesita tutoriales y documentación. Hoy
es difícil ver bibliotecas que por ejemplo tengan manuales para descargar en PDF.... sería
lindo hacer algo diferente a eso, tener documentación y tutoriales en español sería un
paso significativo.

[carlostex]

Hola, de principio te digo que me encantó la idea, el potencial de lo que se esta hablando es muy grande, como dices, seria muy bueno crear un engine que sea facil de manejar, que cualquier persona con un minimo de conocimientos de programcion pueda usar, y tener un juego sencillo andando en poco tiempo.
y para los desarrolladores mas experimentados que quieran meterse al funcionamiento del engine les puede servir para aprender mucho sobre tecnicas en videjuegos, algoritmos, modelos, etc.

Seria un gran aporte a la comunidad de desarrolladores y futuros desarrolladores la documentación en español.

Y propongo que no solo se escriba en pyton, tambien en C++, dado que habemos varios que sabemos programar en dicho lenguaje.
creo que eso seria facil, se puede establecer los modelos e interfaces independientes del lenguaje.
incluso aunque se escriba en c++, se puede usar un lenguaje script como lua, para que alguien que no sea programador no tenga que meterce con la sintaxis de C.

Me gustaria ser parte de esto, a si que me apunto.
Tengo la experiencia de haber desarrollado mi propio engine con SDL. De hecho eso que comentas del la exploción, tengo una clase que maneja efectos visuales, mas que nada son animaciones que corren hasta que se acaban los frames, entonces para activarlas solo llamo a una funcion, addfx(indice del sprite, posicion, tiempo) y listo tienes una explocion.

Al igual que muchos que han hecho juegos deben tener ideas, o algo con que aportar.

Asi que para empezar hay que ver como se van a apuntar los intersados

[adrigm77]

Obviamente tendría que ser escrita en C/C++ sino el rendimiento sería pésimo (Pygame no está escrita en Python).

Hacer una biblioteca desde 0 no es algo trivial, hay que manejar el hardware a muy bajo nivel para crear ventanas dibujar en pantalla, etc.

Por lo que ha explicado Hugo entiendo que la idea es facilitar el desarrollo con clases prestablecidas con rutinas para hacer sprites animaciones y demás.

Yo personalmente lo que haría seria coger una biblioteca existente y ampliarla, es decir, partiendo de pongamos Pygame, escribir rutinas que faciliten la carga de sprites, movimientos, animaciones, etc, en lugar de crear algo de 0.

En cuanto la documentación, pues pienso lo mismo, que debería haber más en español y podríamos escribirla. Pero más que de una api en general de algoritmos, escribir sobre automatas, como hacer animaciones, de IA, de desarrollo de videojuegos desde 0, etc. Contenido que enseñen a crear videojuegos.

[Geo]

La idea es muy buena, pero en un principio Hugo no comentó una biblioteca, sino un engine.
Yo no he encarado un proyecto de este tamaño aún, así que me gusta que haya varios aquí con más experiencia que se estén interesando . Hace tiempo me planteé un proyecto: un engine open source basado/inspirado en el programa Game Maker, de hecho, hice un par de clases para objetos (o actores) que usé en un proyecto multimedia en la escuela, no eran nada espectacular pero me gustó y me pareció que si podría echar a andar algo como lo que pensé, aunque aún me falta muuucho.

¿Qué les parecería algo como lo que menciona adrigm77? Crear un conjunto de juegos de ejemplo con pygame, pensando en que se creen diferentes clases que puedan usarse entre varios de estos juegos, que se distribuyan con documentación y los ejemplos.

Ahora, yo no se Python , según se decida, pues a echarle ganas .

[carlostex]

El juego si se puede hacer en pyton, hay varios juegos hechos que nececitan de un engine, que los creadores hicieron a su medida, solo es crear unas clases para facilitar la cracion de animaciones, es decir, quitar el trabajo de crear el engine.
Claro que se partiría de otra biblioteca para graficos, en C se puede usar SDL o SFML, aunque eso no es lo mas importante, pues para manejar esas bibliotecas de deben crear interfaces de tal forma que sea facil cambiar las rutinas para hacer graficos. Creo que a lo que se refiere hugo, es crear una serie de clases que ya implementen todas las rutinas para dibujar y hacer los calculos para las animaciones, coliciones etc. Por eso es que se habla de un engine y no una biblioteca de funciones con algoritmos, en cambio los algoritmos se deben encapsular en clases, para que sean faciles de usar desde el engine.


Con respecto a lo que comenta adrian, el proposito del engine es facilitar la creacion de juegos a novatos, ejemplos ya existen hay algunos en esta web, pero para los que quieran saber mas sobre videojuegos, algoritmos, IA, pues ellos que se metan al engine, para que vean como funciona.
Por ejemplo al que le toque implementar el pathfinder, que haga su documentacion, comente codigo, y ponga un ejemplo de prueba aun que sea muy cencillo, asi el que quiera saber sobre pathfinder solo mira esa parte, y que pueda bajarce ese ejemplo, sin nececidad de saber como funciona todo el engine.

[adrigm77]

A mi me gusta la idea del Game Maker, pero algo diferente. Podriamos crear un engine basado por ejemplo en Pygame y Python para desarrollar videojuegos.

Constaría de un editor de escenarios (basado en tiles y demás), gestor de recursos graficos y gestor de eventos, por ejemplo en el editor creamos nuestro mapa y definimos un evento en un tile o coordenada y se nos crea un "script" donde implementar ese evento. Según del tipo que sea pues podría heredar de una clase preestablecida por el engine, por ejemplo crear un evento tipo player en el tile [4, 3] nos crea un objeto que hereda de la clase Player (definida por nuestro engine) y en el gestor de evento podemos implementar a golpe de clicks un formulario que defina lo básico, imagen del sprite, posición, movimiento, etc. Y luego en el editor de scripts se podrían definir a nuestro player métodos propios para ampliarlos.

En resumen la idea es construir un engine base con editor de niveles, eventos, gestión de recursos, etc. Que vaya "implementando" nuestro juego al que luego para hacerlo más potente o darle lógica le metemos mano a los scripts en Python.

[carlostex]

Lo del editor es buena idea, pero creo que mejor comenzamor por hacerlo separado, ya existen editores de mapas, donde se crearia el esenario, y los actores se pondrian mediante codigo, creo que es igual de facil para una persona usar una linea de codigo para saber si se aparetó un boton y otra para mover algo, que ponercelo grafico.
Pero lo del editor queda fuera del objetivo del engine, primero se ecribe el engine y luego el editor.
Luego se podria mejorar para hacer algo parecido a game maker, pues para algo asi, creo que se debe dominar bien el tema de los scripts y python, bueno no conozco muy bien python no se que tan facil sea hacerlo, en C++ conozco formas de implementar lua, y poder hacer un editor donde se pondrian los actores y se les define acciones, aunque de todas formas, es una paso mas alla, creo que de deveria comenzar, con algo como lo que comento hugo, con lineas de codigo, y ya luego nos aventamos por el editor.y es que de todas formas para el editor tiene que escribirse un engine, el editor creo que deveria ser aparte, solo para generar scripts y que el engine las interpete.

[hugoruscitti]

Buenas, ante todo muchas, muchas gracias por contestar
el mensaje. Estoy tomando nota de los comentarios y
tratando de ver cómo se podría implementar.

Con respecto al editor sería genial, tal vez podría
hacerse como un programa separado y si realmente nos
resulta bien, lo incorporamos.

Sobre técnica, creo que es factible re-utilizar otra
biblioteca multimedia existente. Por ejemplo se podría
usar SFML que funciona bastante bien sobre varios sistemas
operativos distintos. Igual sigo investigando... me quedan
por investigar varias bibliotecas mas (tengo una lista y
voy evaluando cada una: panda3d, rabbyt, pyglet, clutter...)

En resumen, creo que lo mas seguro es hacer un complemento
para otra biblioteca que funcione bien y así focalizarnos mas
en ofrecerle facilidades a los novatos.


Otra cosa, ¿se les ocurre un nombre?. A mí me gusta
el nombre "pilas". Creo que hace honor a la idea de
energía y movimiento, a parte son intercambiables (lástima
que contaminen...)

[carlostex]

a que te refieres como complemento?, todo el contexto que se nececita para hacer funcionar a un juego aparte de los graficos, como deccion de coliciones, carga de mapas, etc?.

Mencionaste panda 3D, estas pensando en hacerlo para 2D o 3D?
Claro que se podria hacer un motor para las dos de dimenciones, pero seria mejor empezar con 2D, y es que en 2D, hay vastante, juegos de plataforma, RPG, isometricos.

[adrigm77]

En mi opinión escogería Pygame. razones:

- Ya tenemos la guía de referencia traducida.
- Hay bastantes artículos sobre él.
- Python es un lenguaje ideal para iniciarse.

La idea entonces sería escribir una serie de clases/funciones para facilitar tareas como crear sprites, movientos, IA, colisiones, etc. ¿No es así?

[carlostex]

Si, estoy de acuerdo, con eso para empezar.
Y tambien me gustaria que sea en C++, para no dejar fuera a lo que sabemos ese lenguaje, y por los que quieran aprendelo

[hugoruscitti]

a que te refieres como complemento?, todo el contexto que se nececita para hacer funcionar a un juego aparte de los graficos, como deccion de coliciones, carga de mapas, etc?.

Nada en especial, complemento no es una definición técnica, solo quería expresar que
no rehicieramos una biblioteca que dibuje sprites o aplique transformaciones como
escalado. Ya existen bibliotecas que hacen eso y se las puede re-utilizar.

Mencionaste panda 3D, estas pensando en hacerlo para 2D o 3D?
Claro que se podria hacer un motor para las dos de dimenciones, pero seria mejor empezar con 2D, y es que en 2D, hay vastante, juegos de plataforma, RPG, isometricos.

No, no pienso en algo que sea 3d, pero aún así estoy investigando panda porque tiene
buenos tutoriales, ejemplos y una api que tiene algunas cosas interesantes que
sirven de inspiración (bah, son muchas cosas interesantes).

[hugoruscitti]

Si, estoy de acuerdo, con eso para empezar.
Y tambien me gustaria que sea en C++, para no dejar fuera a lo que sabemos ese lenguaje, y por los que quieran aprendelo

Ok, lo voy a tener en cuenta. Igual, la idea no es dejar a fuera a nadie, python es mas fácil de aprender que C++...

[hugoruscitti]

Les dejo otra idea para ir pensando...

Pensando en la distribución de los juegos

El problema:

En el foro de losersjuegos vimos muchas veces que
resulta difícil preparar juegos para distribuirlos.

Por ejemplo, en python se puede distribuir fácilmente
el código de un programa. Pero si quieres que los
usuarios de windows tengan la posibilidad de jugar
a tu juego, hay que saber algo de py2exe, o decirle
a las personas: bajá python, descomprimí el archivo, buscá
el archivo .py y dale doble click...

Hacer lo mismo con C o C++ es mas difícil aún, o bien
compilas el programa para cada plataforma o adjuntas
un tutorial de cómo compilarlo (usando make, cmake,
autotools etc.). De hecho, me ha ocurrido bajar códigos
de juegos que siquiera pude compilar, porque se notaba
que estában hechos desde algún IDE que no tengo...

Una posible solución:

Me gustaría que este nuevo engine esté orientado a
personas novatas, y que puedan decir a sus
amigos (no programadores): "¿Quieres mi juego?, no hay
problema, pongo este archivo .exe en el directorio
del juego, te lo copio y listo..."

Es decir, que las personas puedan distribuir sus
juegos directamente en directorios con el código
fuente y que exista un archivo .exe que sea el "cargador".

Todos los juegos podrían ejecutarse con el mismo cargador,
así que los que lo tienen instalado en su equipo ni lo
necesitan.

¿De donde viene?

Esta idea de tener cargadores no es nueva, por ejemplo
el motor de juegos love2d tiene algo como esto:

http://love2d.org/wiki/Game_Distribution

y de hecho, el lenguaje fenix (inspirado en el legendario
div games studio) también tenía este concepto de

¿y será posible?

m... creo que sí, porque si adoptamos python como
lenguaje de programación, python es interpretado, no
necesitamos que el código se compile así que hay
una "chance".

El tema sería ver cómo hacemos este cargador, porque
creo que si hacemos un script de python y lo pasamos
a un exe con py2exe lograríamos tener algo funcionando...

lo tengo que investigar mas a fondo...
~

[estudiante]

Hola
Esta es una idea que también me "persigue".
No he leído todos los comentarios, discúlpenme.
Es que tengo urgencia por "escupir" las ideas que tengo:

1.- Yo voto por python-pygame. Yo he leido algo de C++. Es que la idea de punteros, de especificar que tipo de variable se está usando ... son cosas que a un novato puede desalentar.
2.- Es mas, preferiría Smalltalk ... Y es que era (o es un lenguaje) que me parecía bastante estricto y coherente: Todo era un objeto. Y es que creo que la programación por objetos se aproxima un poco mas a la realidad. Es decir, no quisiera que en un programa se mezcle funciones, con procedimientos, con objetos, porque me parece a mí que puede confundir... en fin ... no sé ... puedo estar equivocado

3.- Si el proyecto camina, enfoquémoslo en un solo tipo de videojuegos. Es decir hay juegos de rol, de plataformas, de estrategia, lógicos. Aquí yo voto por hacer un "engine" para juegos del tipo plataformas. Es decir un personaje avanzando horizontalmente interactuando con los objetos.

4.- La documentación debe ser tomada en serio. Los usuarios deben saber:Dónde van a ir sus sprites animados, sus sonidos, su música.

Caray... no he podido aclararme ... jaja ...
Bueno, saludos ...

[adrigm77]

Hombre cada uno veo que tira para lo que sabe/conoce y eso tampoco es así. A mi sinceramente me da igual, puedo adaptarme, pero que se llegue a un acuerdo y no sea preferencias personales.

C++/SDL: Es una buena base, al ser compilado (y más C++) lo convierten en ideal para juegos y el tema de la velocidad, es algo más complicado para principiantes.

Python/Pygame: Al ser interpretado mucho más lento que la opción de C++/SDL, pero tiene como fuerte la facilidad de Python.

Para ambos hay mucha documentación base en español. Si se manejan otras opciones adelantes.

[hugoruscitti]

1.- Yo voto por python-pygame. Yo he leido algo de C++. Es que la idea de punteros, de especificar que tipo de variable se está usando ... son cosas que a un novato puede desalentar.

Cierto, creo que pygame es una de las preferidas por muchos de nosotros, aunque también estoy
viendo mucho de SFML con la que trabajo desde hace un tiempo. Las diferencias principales
son que SFML se puede distribuir mas fácilmente y usa opengl, lo que hace sencillo rotar, escalar
o desvanecer objetos.

2.- Es mas, preferiría Smalltalk ... Y es que era (o es un lenguaje) que me parecía bastante estricto y coherente: Todo era un objeto. Y es que creo que la programación por objetos se aproxima un poco mas a la realidad. Es decir, no quisiera que en un programa se mezcle funciones, con procedimientos, con objetos, porque me parece a mí que puede confundir... en fin ... no sé ... puedo estar equivocado

3.- Si el proyecto camina, enfoquémoslo en un solo tipo de videojuegos. Es decir hay juegos de rol, de plataformas, de estrategia, lógicos. Aquí yo voto por hacer un "engine" para juegos del tipo plataformas. Es decir un personaje avanzando horizontalmente interactuando con los objetos.

4.- La documentación debe ser tomada en serio. Los usuarios deben saber:Dónde van a ir sus sprites animados, sus sonidos, su música.

Caray... no he podido aclararme ... jaja ...
Bueno, saludos ...

Si, smalltalk es un gran lenguaje, me gusta, pero no conozco mucho de él como para
tenerlo en cuenta para hacer un engine...

Sobre la temática de los juegos me parece buena tu idea, si lo enfocamos a una sola
categoría de juegos puede nos resulte mejor.

Y claro, lo de la documentación me parece clave...

[carlostex]

Hombre cada uno veo que tira para lo que sabe/conoce y eso tampoco es así. A mi sinceramente me da igual, puedo adaptarme, pero que se llegue a un acuerdo y no sea preferencias personales.

No lo veo asi, pues ni modo que yo hable de algo que no conozca. Los comentarios por supuesto son basados en la experiencia de cada uno.
Y todos van a tener que adaptarce, pues en un proyecto de equipo, y tambien tenemos que aprender nuevas cosas, eso es de entrada.

1.- Yo voto por python-pygame. Yo he leido algo de C++. Es que la idea de punteros, de especificar que tipo de variable se está usando ... son cosas que a un novato puede desalentar.

Por eso es que estor proponiendo dos equipos uno para python y otro para C++. En C++ existe la opcion de hacer extenciones para lenguajes interpretados, se podria usar lua, es un lenguaje muy usado en la industria de los videojuegos, por que combina la potencia del lenguaje C++, y la facilidad de entender un lenguaje interpretado, o incluso se podria usar python, asi que por eso no le veo problema.

Hacer lo mismo con C o C++ es mas difícil aún, o bien
compilas el programa para cada plataforma o adjuntas
un tutorial de cómo compilarlo (usando make, cmake,
autotools etc.). De hecho, me ha ocurrido bajar códigos
de juegos que siquiera pude compilar, porque se notaba
que estában hechos desde algún IDE que no tengo...

~

Por eso evito en uso de los IDE para programar, cuando eres novato. yo uso un IDE, netbeans, pero el makefile yo me lo preparo, tu debes controlar al IDE y no el a ti.

Si es verdad que suele pasar eso con C, pero no podemos permitir que eso sea un tope. La solucion como lo comenta hugo es dar el codigo fuente junto con el ejecutable y las bibliotecas dinamicas, asi solo le da doble click y listo. Se debe testear la compilacion del codigo en varias maquinas, asi no habra el problema cuando la distribullamos, y alguien quiera compilarlo.
Ademas que tan dificil es hacer un ./configure && make
Se le puede poner documentación para instalar las bibliotecas que se nececitan para compilarlo. La persona que lo haga seguro es un desarrollador y sabrá del tema. Vamos, no es impedimento para divertirnos programando en C++ jaja

[hugoruscitti]

Buenas, comencé a hacer las primeras pruebas y experimentos sobre
las ideas que le comenté.

Cargador de juegos

La idea de cargador de juegos para windows se puede hacer, de hecho, ¡logré
mas de lo que esperaba!, ahora estoy investigando si este cargador puede
ser mas interactivo. Por ejemplo, ¿que pasa si modifico el código fuente
del ejemplo mientras el juego está corriendo?.

Componentes

Y sobre la API, estoy pensando en usar algo como programación orientada a
componentes, espero tener algo para mostrar pronto, pero mi idea
es algo así.

Imagina que quieres poner un objeto en pantalla y que se pueda arrastrar
con el mouse:

Código: Seleccionar todo

pelota = pilas.actors.Ball()


entonces, aparece una pelota en pantalla que no se puede
mover, pero si escribo:

Código: Seleccionar todo

pelota.mix_with(pilas.component.Draggable)


La pelota pasa a heredar de la clase Draggable, que le dá la funcionalidad
de ser arrastrable con el mouse.

Es decir, el módulo "components" tendría que tener muchas clases
que den comportamiento a cualquier objeto... ¿que componentes
se les ocurren para crear?. Yo he pensado en algunos como "Clickeable", "Animable",
"collisionable", pero no se me ocurren mas ¿ideas?.

Por cierto, si tengo éxitos en las pruebas trataré de hacer un documento
para que podamos ir viendo en detalle la api.

Saludos.

[adrigm77]

Suena interesante, me gustaría saber más y si es posible colaborar.

[hugoruscitti]

Suena interesante, me gustaría saber más y si es posible colaborar.

Claro, la idea es que podamos hacer el engine entre varias personas... dame unos dias
para que me organice un poco con el repositorio y ver si las ideas que se han planteado
son viables. Yo creo que sí, pero hay que hacer algunos códigos de prueba para ver
si anda...

Saludos.

PD: puedes ir investigando algo de mercurial, PySFML y python si quieres...

[Geo]

Entonces ahorita la idea va por Python + SFML ¿verdad?

Yo uso C/C++, como ya dije, de Python prácticamente nada.
Me parece bien que se use Python, porque aunque se decidiera trabajar con C/C++, debería brindarse una forma de acceder al engine con Python u otro lenguaje similar que facilite su asimilación.

El tema de la distribución a mi también me parece interesante a definir, y aquí entra en juego el sistema de cada plataforma que se pretenda soportar. estaba pensando en comentar algunas cosas pero tras el mensaje de Hugo, mejor espero para que platique a detalle qué es lo que está probando .

[carlostex]

Pues

Entonces ahorita la idea va por Python + SFML ¿verdad?

Yo uso C/C++, como ya dije, de Python prácticamente nada.
Me parece bien que se use Python, porque aunque se decidiera trabajar con C/C++, debería brindarse una forma de acceder al engine con Python u otro lenguaje similar que facilite su asimilación.

Pues como comenté, si alguien esta interesado en desarrollarlo en C++ ya seriamos dos, lo del lenguaje y la forma de distriburlos es lo de menos, ya comente como. Solo es cosa que haya quienes quieran hacerlo en C++, si hay interesados que lo digan para que se haga paralelamente y usando el mismo en enfoque para los dos lenguajes.

[hugoruscitti]

Pues como comenté, si alguien esta interesado en desarrollarlo en C++ ya seriamos dos, lo del lenguaje y la forma de distriburlos es lo de menos, ya comente como. Solo es cosa que haya quienes quieran hacerlo en C++, si hay interesados que lo digan para que se haga paralelamente y usando el mismo en enfoque para los dos lenguajes.

SFML también tiene bindings para C++, así que se podría hacer como tu dices: un desarrollo en paralelo. ¿se ofrecen voluntarios?.
Por mi parte me voy a focalizar mas en la parte de python, pienso que va a ser bastante trabajo...

[angelus_ira]

Bueno, un poco tardia vi el anuncio y tarde bastante en leer todas las respuestas. Aclaro primero que el único lenguaje en el que me considero nivel intermedio/avanzado es php... (estoy aprendiendo Python, pero los examenes en la uni me impidieron ver codigo este mes).

Respecto al lenguaje:
Python se puede usar como lenguaje de scripts, mientras que c++ debería ser el que hace la mayor parte de la magia. Similar a como ocurre con el RPGMaker VX (es de pago) y el previo (no recuerdo la version), los cuales usan como lenguaje de script Ruby. La idea es tener un sistema que aproveche la velocidad de c++ en las librerias importantes y que tenga la simplicidad de python para crear cosas.
Me refiero a que no hay una necesidad real de realizar un desarrollo paralelo. Lo que habría que hacer es tener alguien que sepa Python y C++ para coordinar el desarrollo. Gente que trabaje en C++ para realizar el engine que lea scripts Python, y otras personas (o las mismas) que desarrollen scripts ejemplos en Python.
Si alguno de ustedes estuvo alguna vez viendo el código de los server L2j (para lineage 2), el mismo usa java como lenguaje base y usa jython para los script de las quest del juego. Hay varios ejemplos similares con otros lenguajes.

Explico que es mucho más sencillo dar un ejecutable (respectivo a cada plataforma) con las librerias que se usen (python se puede incluir como libreria) y los recursos (graficos, sonidos...) del juego todo comprimido en un autoejecutable que se cree desde algun "editor" propio para el engine.

Aclaro nuevamente, no soy programador y quizás lo que dije carece de sentido.

Sobre características que debería tener:
1.- No se que tipo de juego sea el que se hará, pero seria bueno que el engine permita realizar consultas a algún tipo de base de datos (ej sqlite), esto es para cuando ya este avanzado el desarrollo claro. Explicación muy larga, pero es pensando si en algún momento se hará algún editor para el engine.
2.-Sobre componentes:
"Clickeable", "Animable","collisionable"
Agregaría "Solid" (para que el usuario, objeto o lo que sea) no pueda pasar por las coordenadas del mismo.

3,. Proyectos interesantes de donde sacar ideas:
easyrpg: http://easyrpg.rpgmaker.es/forums/, clon de RPGMaker 2000. En fase alfa todo. El player esta bastante más avanzado que el editor. Tienen una buena cantidad de recursos gráficos, los cuales creo que están en licencia GPL.

ika: http://ika.sourceforge.net/ es un game engine orientado a crear RPG estilo consolas supernes o genesis.

Tutorial para incluir Python en una aplicación C++:http://members.gamedev.net/sicrane/articles/EmbeddingPythonPart1.html

Boost c++:http://www.boost.org/doc/libs/1_43_0/libs/python/doc/building.html Una serie de librerias, entre las cuales se incluye una para facilitar la inclución o extensión de Python en un programa hecho en c++

cx-freeze: http://cx-freeze.sourceforge.net/, similar a py2exe, pero más multiplataforma. No probe ninguno, pero creo que este está más actualizado.

PD: disculpen el post largo, pero pasar enlaces es lo único que admite mi conocimiento

[adrigm77]

Aquí de lo que se trata es de hacer un engine para programar videojuegos, no un "Game Maker", es decir coger una biblioteca y ampliarla, por lo que no tiene sentido trabajar con lenguaje compilado de base y lenguaje de scripts separado, porque al fin y al cabo el dibujado, la creación de ventanas y demás de las bibliotecas de lenguajes de alto nivel, por ejemplo, Pygame, ya está escrita en C++, por lo que para la lógica y facilitación de código ya escrito no hay que ir a la base.

El RPG Maker por cierto no usa C++ usa Delphi como lenguaje compilado. Los proyectos que mencionas son creaciones de clones del RPG Maker, como por ejemplo el EasyRPG que están basando su estructura en las clases RGSS de Ruby ya escritas y que están orientadas a RPG, si se quiere hacer un RPG, es una buena base a tomar.

[carlostex]

Se pensaba hacer en python por que muchos en este foro programan en python y hugo que fue el que lo arganizó tambien,
Sin embargo lo que dice engelus_ira es cierto, no hay un motor escrito en un lenguaje script, por que no solo los graficos llevan tiempo, algunos calculos y operaciones tambien requieren tiempo, si haces un juego donde se manejen 100 entidades autonomas tu motor escrito en python no va a satisfacer las nececidades de velocidad, en cambio si se escribe en un lenguaje compilado sera mas rápido.Por supuesto aqui no se esta intentado hacer un superjuego, creo que la idea principal es aprender y que loserjuegos aporte algo importante por eso es que en lo personal no me pareció mala la idea de hacerlo en python, y di la idea que tambien se haga en c++, usando lua como interprete, o incluso python, para que todos participaramos

[Juanxo]

Buenas a todos:

He estado fuera una semana, y al parecer habeis estado liados por aquí.
Mi opinion:
- Parece que algunos estamos apuntando a un nivel de abstraccion muy bajo, me explico: como hugo comento, no se trata de hacer un api que rote, dibuje, cree ventanas... si no un api de un alto nivel (en plan con clases Player, Effects, Animation ya implementadas). En este nivel de abstracción , muy pocas aplicaciones están limitadas por la cpu, si no que suelen estar más limitadas por el hecho de dibujar gran numero de cosas, por lo que la velocidad en cuanto a procesador aquí no suele jugar un papel decisivo. Por eso opino que Python esta muy bien

- Yo quizás me apuntase al de C++, todo es ir viendo como evoluciona la cosa

- En cuanto a distribución de proyectos en C++, estoy de acuerdo con que es un asco, aunque cmake parece que esta ayudando bastante a mejorar esto

[Geo]

¿Podemos ir concretándolo un poco? Veo que varios aquí han propuesto buenas cosas, pero también que Hugo ya va trabajando en una línea.

[carlostex]

pues ya se deberia ver quienes van a participar en el desarrollo, y si hay personas para c++.
Esta bien que hugo ya haya hecho una base, pero ya se deberia poner a participar a los ineteresados

[hugoruscitti]

armé un repositorio para la lib en C++

http://bitbucket.org/hugoruscitti/pilascpp

¿voluntarios?

[carlostex]

ya baje el repositorio pero esta vacio, como me suponia jeje. Ps como dije desde el principio yo quiero hacerlo en C++, aurita ya entre a la facultad y no creo tener mucho tiempo, desarrollare en mi ratos libres.

[Juanxo]

Existe algún documento que especifique las funciones a desarrollar, es decir, la composición del API?

[carlostex]

De hecho primero se debería hacer un diagrama de clases y un esquema de como debe quedar la api, por que asi no saben que va a ser cada uno

[hugoruscitti]

No hay por ahora un documento con eso, pero pueden proponerlo... ¿como lo harían?, yo
comencé a implementar la versión python con un diseño muy reducido, para liberarlo
lo antes posible.

Comencé con una clase llamada actor, que representa a los sprites de los juegos
y unas poquitas propiedades:



La clase actor deriva directamente de la clase sf:Sprite, que ya está hecha en SFML...

Por mi parte me voy a focalizar en la versión python, son libres de encarar el desarrollo
de la versión c++ como quieran (documentos, api etc...)

[hugoruscitti]

También subí la documentación de pilas al siguiente mensaje
del foro:

viewtopic.php?f=21&t=823

puede que les resulte útil a la hora de encarar el desarrollo en C++

[carlostex]

Me parece bien el documento, esta bien ordenado, creo que esta bien que te dediques a python y su esquema, en c++ se seguiria el mismo enfoque, pero seguro habran pequeñas diferencias en los diagramas de clases, pues aver quienes quieren empezar con c++, avisen.

[Geo]

Acabo de leer el PDF que creó Hugo de la documentación actual, lo que veo es, si el intérprete interactivo formará parte importante del uso del engine en cuanto a aprendizaje y pruebas, hacerlo en otro lenguaje ya no encaja tanto.

[carlostex]

no veo por que no.
se puede hacer lo mismo para c++, todo estaria controlado por LUA y se puedo hacer tambien interactivo

[Geo]

No he usado LUA ni embebido algún otro en una aplicación C/C++, pero suena bien . Lo que entiendo es que habría que programar el intérprete ¿o ya LUA integra uno? ¿puedes comentar más al respecto?

[carlostex]

Lua es un leguaje de programacion interpretado y extencible.La forma de hacerlo es que ya teniendo todo el motor hecho se usa SWIG para hacer el wrapper de c++
a Lua, es algo cencillo de hacer, solo se escriben las funciones y clases que se quieren que esten disponibles para Lua, de eso hay dos opciones, para usar el modo interactivo se carga la biblioteca desde el interprete de Lua, y si se quiere usar un programa ya escrito de Lua, se llama al interprete desde c++.
Si quieres averiguar mas consulta esta pagina: http://www.swig.org/Doc1.3/Lua.html

[Geo]

Bueno, entonces significa que lo mismo que se consigue hacer con el intérprete de Python podría hacerse usando Lua, o al menos algo similar, ¿es así?

De cualquier forma, en definitiva tengo que aprender Python, no entiendo cómo BaseActor puede tener métodos de sf::Sprite sin haber derivado de esta última ¿o no leí bien el código?

[carlostex]

Si, en realidad se puede hacer lo mismo con python y c++ con Lua, de hecho se puede incluso usar python en vez de lua.

Bueno, entonces significa que lo mismo que se consigue hacer con el intérprete de Python podría hacerse usando Lua, o al menos algo similar, ¿es así?

De cualquier forma, en definitiva tengo que aprender Python, no entiendo cómo BaseActor puede tener métodos de sf::Sprite sin haber derivado de esta última ¿o no leí bien el código?

lo que pasa es que sf es un espacio de nombres, el cual ya se puso a dispocicion al importar la biblioteca, ademas sprite es una clase, y puedes no nececitas heredarla para acceder a ella.

[Geo]

Si, en realidad se puede hacer lo mismo con python y c++ con Lua, de hecho se puede incluso usar python en vez de lua.

Bueno, entonces significa que lo mismo que se consigue hacer con el intérprete de Python podría hacerse usando Lua, o al menos algo similar, ¿es así?

De cualquier forma, en definitiva tengo que aprender Python, no entiendo cómo BaseActor puede tener métodos de sf::Sprite sin haber derivado de esta última ¿o no leí bien el código?

lo que pasa es que sf es un espacio de nombres, el cual ya se puso a dispocicion al importar la biblioteca, ademas sprite es una clase, y puedes no nececitas heredarla para acceder a ella.

Me refiero a esto:
el código de la clase BaseActor: http://bitbucket.org/hugoruscitti/pilas ... /actors.py
en su constructor llama a SetPosition:

Código: Seleccionar todo

class BaseActor(object, Mixineable):
    "Define la funcionalidad abstracta de un actor."

    def __init__(self):
        insert_as_new_actor(self)
        self._set_central_axis()

        # define la posicion inicial.
        self.SetPosition(320, 240)


Pero no veo de dónde salió self.SetPosition. Igual para algunas otras dentro de BaseActor, como SetX, SetY, SetRotation, las cuales me parece pertenecen a Drawable (de la que deriva Sprite), pero no veo que derive de ninguna de ellas, Mixineable no las contiene, object no lo encuentro.

[hugoruscitti]

Código: Seleccionar todo

class BaseActor(object, Mixineable):
    "Define la funcionalidad abstracta de un actor."

    def __init__(self):
        insert_as_new_actor(self)
        self._set_central_axis()

        # define la posicion inicial.
        self.SetPosition(320, 240)


Pero no veo de dónde salió self.SetPosition. Igual para algunas otras dentro de BaseActor, como SetX, SetY, SetRotation, las cuales me parece pertenecen a Drawable (de la que deriva Sprite), pero no veo que derive de ninguna de ellas, Mixineable no las contiene, object no lo encuentro.

m... buena pregunta, la respuesta es que es un "casi" un bug....

Resulta que ese código del constructor nunca se ejecuta directamente desde esa clase. Porque es
abstracta, si haces "nuevo = BaseActor()" el codigo fallará, porque no se espera que alguien quiera
instanciar de ahí.

Ahora bien, ¿por qué funciona?, porque en realidad el objeto que se usa para crear nuevos
actores es Actor, y como hereda de sf.Sprite sí tiene los métodos SetPosition y similares.

Resulta que pyhton solo llamará al código de __init__ de BaseActor cuando se haga
un objeto de la clase Actor, así que en ese caso va a poder acceder a los métodos SetPosition.

Este es un diagrama de las clases que hay hasta ahora:



De todas formas es buena tu observación, es algo para corregir, si alguien prueba la
biblioteca y trata de crear un objeto de la case BaseActor sería bueno que aparezca un
mensaje advirtiendo en lugar de un error porque no se encuentra el método SetPosition.

Por cierto, si quieres aprender python cuenta conmigo para cualquier consulta que te
quieras.

Saludos.

[Geo]

Gracias Hugo por los comentarios, a eso precisamente me refería.
Es que estaba haciendo un pequeño ejercicio de replicar la clase Actor en C++, solo hice la declaración de la clase, después actualicé el repositorio y vi que se había agregado la clase BaseActor, mientras repetía el ejercicio de la declaración de clase me surgió la duda, puesto que C++ no me permitiría compilar el código si no encuentra referencia a esas funciones en BaseActor, primer elemento a redefinir para la versión C++, creo .

Sobre lo de Python, muchas gracias por el apoyo, en estos días voy a empezar con las referencias en la página, conforme tenga dudas, ya se dónde acudir . Gracias.
---------------------------
Actualización:
¿Qué se requiere para poder enviar actualizaciones a los repositorios en bitbucket? Intenté hacer unas pruebas pero siempre me devuelve que falló la autorización

searching for changes
http authorization required
realm: Bitbucket.org HTTP
user: josejorge
password:
abort: authorization failed

[Geo]

Ya encontré la razón del error del repositorio en BitBucket, simplemente me hacen falta permisos de escritura . Probé creando un repositorio "fork" de pilascpp y como en este si se me asignó permio de escritura no hubo problema .

Una cosa, me ha estado rondando en la cabeza el que los nombres de clases y funciones del engine estuvieran en español, en el repositorio "fork" de pilascpp que creé en bitbucket puse un poco de código haciéndolo así ¿qué piensan?
Esta es la dirección del repositorio: http://bitbucket.org/josejorge/pilascpp

Nota: solo estoy haciendo pruebas, por favor no tomen esto como indicación de que me voy a dedicar a la versión C++ del engine (al menos no por ahora)
Otra nota: cuando el último mensaje en la discusión es mío, normalmente prefiero editarlo en lugar de enviar una nueva respuesta, pero como noté que el foro no notifica de cambios preferí enviar este mensaje.

[hugoruscitti]

Una cosa, me ha estado rondando en la cabeza el que los nombres de clases y funciones del engine estuvieran en español, en el repositorio "fork" de pilascpp que creé en bitbucket puse un poco de código haciéndolo así ¿qué piensan?.

Es una buena idea, creo que siendo un engine para principiantes y desarrolladores casuales
se podría hacer... además creo que la api se tendría que poder cambiar a conveniencia
de todos nosotros.

¿Podrías escribir un mensaje nuevo en el foro así lo conversamos ahí?

[Geo]

¿Podrías escribir un mensaje nuevo en el foro así lo conversamos ahí?

Hecho .