Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Estructura de un Engine 2D

Iniciado por nsL, 31 de Agosto de 2011, 02:54:25 PM

« anterior - próximo »

nsL

Buenas!
No se si soy el único o no, pero me pasa que siempre que hago algún desarrollo (personal) de algún jueguillo, hago tal lío de funciones/clases, con particularidades especificas de ese juego dentro de ellas, que al final me resulta bastante complicado reutilizar grandes partes del código sin tener que andar haciendo criba d que es juego y que es "engine". No se si me explico.

Tengo pensado meterme en el mundillo de juegos para Android y aprovechando vengo de novato, empezar a hacer las cosas ordenadas desde un principio. Es decir me gustaría montarme un conjunto de clases, a modo de engine, que me sirvan como base para cualquier desarrollo futuro, y así tener diferenciada la parte del juego del motor, por así decirlo, sin tener que empezar prácticamente desde 0 en cada desarrollo.

Entiendo que hay mil maneras, y/o que cada uno lo hace a la suya.

¿Conocéis de alguna documentación,ya sea en formato Web, o como libro, que expliquen bien como estructurar un motor desde 0? Da igual el lenguaje, la plataforma, o la librería gráfica(dx, ogl), solo necesito una guía de como estructurarlo.

He buscado y he visto alguna entrada en algún blog, además de algún libro por amazon. Pero o bien es bastante escaso en explicaciones, o no me quiero arriesgar a comprar un libro que luego no sea lo que estoy buscando. Igual vosotros sabéis de algo :)

Gracias!

Un saludin
Yo no muero hasta la muerte -

Notnasiul

¿Tienes alguna razón en concreto por la que no quieras utilizar algún motor de juegos 2D ya existente? Eso te ahorraría mucho tiempo, te permitiría hacerte con la estructura de motores ya existentes (por si más adelante quieres hacer el tuyo propio) y te dejaría las puertas abiertas para ir directamente a lo interesante: el juego. Hay multitud de motores y librerías  a cada cual más interesante... Löve, Pyglet, SDL, Stencylworks...
Último juego publicado: Slider (http://playmedusa/slider)
Web: http://playmedusa.com | Twitter: @playmedusa  | Facebook:  www.facebook.com/playmedusafb

nsL

Si, si en parte tienes razón. Como manera de aprender la estructura de un motor es un buen paso supongo. El tema es que en este caso como os puse, estoy empezando con programacion gráfica para Android (para pc y use SDL bastante y OpenGL algo menos), y me gustaría ver como hacer las cosas (para aprender) desde su mas bajo nivel, sin una capa por encima. De ahi que quiera evitar usar un motor ya hecho (AndEngine tiene buena pinta ya dicho de paso).

En cualquier caso, no descarto bajarme los fuentes para cotillear un poco como han organizado las cosas.

Gracias :)
Yo no muero hasta la muerte -

Notnasiul

También tienes Cocos2D, si no me equivoco.

En cuanto a un engine, formas de programarlo hay muchas. La más básica es usar un loop principal donde gestiones, por partes, el input, el sonido y los gráficos. E idealmente en un thread la física, si la hay, aunque podrías meterla en ese bucle principal según qué estés haciendo, claro. Lo suyo es que cuando uno se hace un motor propio es porque va a hacer algo muy específico.

Aunque supongo que ya habrás buscado por ahí, aquí comentan algo (¡precisamente para android!)
http://www.rbgrn.net/content/54-getting-started-android-game-development

y, por supuesto, en GameDev
http://gamedev.stackexchange.com/questions/651/tips-for-writing-the-main-game-loop

¡Suerte! :D
Último juego publicado: Slider (http://playmedusa/slider)
Web: http://playmedusa.com | Twitter: @playmedusa  | Facebook:  www.facebook.com/playmedusafb

Hechelion

Si me permites el comentario, la idea no va solo por donde hacer un engine, va por un tema que tu programación sea reutilizable. En esa lína, lo mejor es siempre generalizar y dividir el problema en partes pequeñas que puedas abordar sin mucho problema, luego, resuelves cada parte pequeña y creas una clase o similar y luego programas las interacciones entre ellas.

Por ejemplo:
Yo quiero un juego donde un personaje salte.
Generalicemos:
¿Qué es saltar? mover la posición de un objeto y aplicar una animación.

Divido en partes simples:
Mover el PJ, es lógica y será un problema a parte.
Animar, es operación gráfica y la será un problema a parte.

Ahora, tengo 2 problemas más pequeños que puedo abordar más fácilmente. y sé que no debo programar una animación de salto, debo programar un sistema que permite reproducir animaciones ¿Por qué?

Ejemplo 2:
Yo quiero un juego donde el PJ se mueve a lo largo de una plataforma.

Generalicemos:
¿Qué es moverse a lo largo de una plataforma.? mover la posición de un objeto y aplicar una animación.


Como ves, el problema general es el mismo, si programaste una solución que permita reproducir animaciones, entonces tienes una clase reutilizable independiente del proyecto.


Sigamos con el ejemplo, una animación seguramente significara que debas cargar ciertas imágenes o texturas, si seguimos en la misma línea anterior, la carga de texturas no corresponde ni a animar ni a mover, por lo cual es un tercer problema que debe ser resuelto a parte, así que te haces un sistema que cargue texturas y para que la clase que carga se entienda con la clase que anima, creas una interfaz.

Partimos de un problema grande y complejo y lo dividimos en partes pequeñas, fácilmente abordables, escalables y reutilizables.


Seguramente sobre esto, deben hacer cientos de buenos libros que explican lo que quiero decir, en mi caso, es lo que he ido aprendiendo con la experiencia, seguramente esto mismo lo dicen en la universidad, pero no es hasta que toca vivirlo en el trabajo diario que realmente te queda y le ves la verdadera utilidad.

nsL

Muchas gracias a ambos!

Si, así es, es un poco de interés por conocer la estructura de un engine y falta de organización por mi parte, muchas veces porque no se marcar la linea divisoria de que es engine y que es juego (básicamente pongo particularidades del juego en lo que debería ser el engine, y al final tengo una chapuza no reutilizable en muchos casos).

Echare un ojo a esos enlaces! gracias a ambos por vuestros consejos.

Un saludin
Yo no muero hasta la muerte -






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.