Blog de programación e ideas locas

Desarrollo:Organizando y expandiendo

by on Ene.04, 2012, under Desarrollo, EGa2Dengine, Engine

Uno de los tantos problemas que tenia mi motor (aparte del hecho que reinvencion de rueda) era la carga de Niveles que estaba muy mal programada. Aunque funcionaba pero, cada vez que tenia que agregar una funcionalidad nueva me costaba mucho y por lo tanto muchos dolores de cabeza también. Pero se me ocurrio una idea que tal si, cada tipo de nivel (formato, o como quieran llamarle) ¿Lo lea en distintas clases? Bueno talvez sea muy engorroso lo que planeo, pero actualmente tenia dos tipos de archivos de niveles, uno exclusivo para los actores(Entidades, Objetos de juego o como prefiera decirle) y otro exclusivo para el nivel (escenario, fisica, logica, etc…) entonces por eso me decidi en dos clases distintas y como soy un poco ambicioso hice una clase abstracta que el “Lector de Niveles” en caso de agregar muchas más cosas. Bueno la implementación de este lector fue bastante sencillo e inclusive más de lo que me esperaba, consta de una simple lista con los lectores distintos lectores ya añadidos y cuando quiero leer un nivel reviso su extension de archivo el cual uso para distingir que clase usar.

Organizando y expandiendo(1) Organizando y expandiendo(2)

Cuando se llama LeerNivel en Contexto, lo que ocurre realmente este busca que Reader usar y finalmente lee el nivel con el Reader seleccionado.

Otro de los problemas que me tuve que solucionar era de como podia manejar los tantos niveles que podria tener, eso si la solución fue bastante estupida porque ya lo habia solucionado pero personalmente no aceptaba que deberia funcionar asi. Queria que un manejador de escena maneje muchas escenas, pero en vez de eso decidí que solo manejara una y que un algo superior manejara muchos manejadores de escenas, lo cual es mucho más limpio y ordenado según mi punto de vista. Lo más importante es que siempre mantengan simple y funcional su codigo.

Y el ultimo problema, aunque este solo fue copy and paste (jaja) es que cada actor podia modificar el entorno que lo rodea, entonces tenia que pasarle un puntero a Contexto.

En conclusión, mi motor no sera del todo poderoso y eficaz, pero se acerca cada vez a una version final y madura del mismo.

Saludos

1 Comment :, , , more...

Desarrollo: Leaded Clouds dia 3

by on Oct.07, 2011, under Desarrollo

Bueno fue el día de resolver bugs -.-’ suelen ser muy molestosos y pueden darse de cualquier tipo de manera problemas en la memoria, un caso no visto de un algoritmo, etc…

Se agrego el comportamiento a los Powers Ups:

  • PowerUp : El disparo es más rapido
  • Vida: Añade una vida adicional
  • Misil: Añade un misil a tu inventario
  • Bomba: Añade una bomba a tu inventario
Se añadio el mensaje MUST_DIE este mensaje es muy util, ya que avisa que el Game Object debe morir  o destruirse (por lo tanto liberar los recursos que está usando). Este mensaje es enviado por el componente Health que al recibir mensajes del tipo DAMAGE que hagan reducir la vida a 0.
Leave a Comment :, , , , , , more...

Desarrollo: LeadedClouds dia 01

by on Oct.04, 2011, under Desarrollo

De hace unos dias se logro implementar en el motor el siguiente concepto: “Objetos de juego basados en componentes“ (Game Objects based Component system). Lo cual ha acelerado nuestro proceso de produción, no al 100% pero si bastante en comparación de antes. En comparación del juego actual y AYCE encuentro que el desarrollo va mucho más  rápido. Por ejemplo para lograr una imagen con su respectivo cuerpo  físico (usando Box2D) cayera al vació, se necesitaba una clase probablemente que hereda de Actor (que contiene una imagen) y otra clase que hereda de Entidad (que contiene el cuerpo  físico) esto al principio no fue tan dificil de lograrlo, pero aveces los errores y cambiar el  árbol de herencia hacia que esto fuese  horrible. Sin embargo a nuestro objecto de juego le agregamos dos componentes una Imagen y un Cuerpo fisico ambos totalmente independientes y se pudo lograr el mismo resultado sin usar directamente C, C++, Java, etc… si no todo se había definido en un archivo XML.

Bueno en este  resumen de 3 días, básicamente lo que se ha estado desarrollando son los componentes independientes para poder crear los Go (Game Object) y refinando alguno que otro detalle en el engine. Hasta ahora hemos obtenido buenos resultados. Siendo que ya tenemos algunos objetos listos todavía nos faltan otros por implementar. Lo más costoso que hemos tenido que realizar es crear los componentes desde 0, ya que algunos objetos requieren componentes más personalizados. Sin embargo, eso no es una traba muy grande para el desarrollo de un videojuego usando este concepto.

 

 

PS:Mi ortografia debe estar horrible :/

PS:La falta de desarrollo en mi editor lo convirtio en un CTRL+C  y CTRL+V de entidades (Go)

1 Comment :, , , , , , more...