Ayer domingo hicimos las pruebas Alpha del Xeno, por supuesto con la nueva version 0.5 que trae un monton de novedades. Como dijo algun testeador, realemente se ve el trabajo puesto en el juego.

El Modulo de Ataque ya esta en una situacion jugable, pueden entrar donde siempre o utilizar el link a la version alpha donde podran elegir un Jugador (no hay ninguna diferencia entre los jugadores, es demostrativo nomas) y ponerse a jugar. Podrian llamar a un amigo y jugar un Vs entre los dos . Enumero a continuacion los cambios mas resaltantes:

A) Ahora las acciones cuestan energia para poder ejecutarse


B) Mejora contundente del codigo y un mas ordenado y mejor control de los movimientos. Esto fue gracias a que ordene un poco mi codigo.Existen 2 mototres de acciones en mi codigo PHP. El motor de Acciones y el de Reacciones. El Motor de Acciones se usa cada vez que se manda codigo a mi sistema para verificar que lo que se este mandando este sanitizado y verificado. El Motor de Reacciones se encarga de ejecutar todas las acciones pasadas y mandar una actualizacion adecuada al cliente.

C) Nuevos movimientos de prueba. Por ahora tenemos 2 nuevas acciones, La primera es Ataque de Rango que permite atacar a distancia y la segunda es Arrollar, hace que la undiad arrollada pierda todas sus acciones presentes ademas de recibir daño de combate. Ademas existen nuevos Paths o formas de Tiles seleccionables para las acciones. Como el de Ataque de Rango que hace que se seleccione unidades entre 2 a 3 cuadrados de distancia.

En el mundo de los proyectos informaticos en general, hay muchas , pero muchas formas de mantener el control de un proyecto. Desde ponerte unos milestones, pasando por cronogramas de tiempo en hojas de calculo, hasta trabajar con el conocido PMBOK para proyectos grandes (muy grandes). ¿Pero cuanto control necesitamos nosotros realmente , para poder terminar nuestro proyecto?

Los ejemplos mas claros sobre control de proyectos lo podemos sacar de los desarrolladores de juegos desktop. Por un lado es conocido el sindrome del "tiempo se acaba" que sufren muchos desarrolladores de juegos desktop, en donde por tratar de cumplir los objetivos en un cierto limite de tiempo, empiezan a correr con el proyecto, bajando la calidad de los mismos. Llendonos al otro extremo, existen aquellos proyectos que por falta de control en los mismos nunca terminan, lo que se conoce como Vaporware.

En lo personal el desarrollo de Xeno, lo estoy llevando en base a lapiz y papel y un metodo fotocopia de la Metodologia Scrum (la cual recomienndo le den una leida), solo que para una sola persona. Basicamente se trata de primero tener una idea no muy definida de lo que se quiere hacer (osea un RTS via web). Despues divides tu juego en varias partes iniciales (mis diferentes modulos) y te enfocas en una parte que te sea facil de hacer (o mas divertida de hacer) hasta que este usable por si sola (mi modulo de batallas). Ahora no tengan miedo de añadir, eliminar o modifcar estos modulos. Piensen en ellos como puntos de una ruta. Si llegado a un punto el camino esta bloqueado, pueden tomar otra ruta . Mi sugerencia seria que empiezen por la parte que tengas mejor definida en tu cabeza.

Ahora al trabajar en una seccion, la subdivido en versiones de la misma. Actualmente estoy en la 0.4.9 del modulo de batallas , ya casi para llegar a la version 0.5. Mi avance es subjetivo y no utilizo una metrica precisa, me quitaria flexibilidad. Simplemente calculo mentalmente que requerimientos debe de tener la version 0.5 para ser diferente a 0.4. Esto hace que la version 0.5 pueda tener muchos mas cambios que la version 0.4 o que por ejemplo la 0.6 tengas el doble de cambios o solo la mitad. Con tal que cumpla el objetivo y halla un avance, no hay problema. Eso si es importantisimo que cada una de las versiones sea funcional por si sola. Es decir que cumpla su objetivo.

El proximo post tratara de pequeños tips que pueden ayudar a llevar a cabo sus proyectos de cualquier clase. Eso si la intencion es aplicarlo a equipos pequeños de personas, que a mi parecer son mas eficientes que equipos de muchas personas. algo asi como el "Equipo de cirugia" que penso Fred Brooks en su ya clasico libro "The Mythical Man-Month".

Ayer me di cuenta que la ultima version de Xeno en el servidor no funcionaba bien, bueno ya el error fue subsanado y las disculpas del caso a los que entraron ayer a probarlo. El error no permitia usar las habilidades de las unidades en el mapa. Fue debido a que algunas librerias se actualizaron con datos incorrectos pero ya todo esta funcionando bien. Ahora disfruten la version 0.4.5. Esta version ahora toma en cuenta cuales unidades son amigas y cuales enemigas.

Saludos

En el anterior post hablabamos de como el crear objetos a diestra y siniestra no sirve de mucho para sistemas web. Pero despues de todo somos humanos y no maquinas, necesitamos siempre cambiar un poco de rendimiento por facilidad de codificacion y reutilizacion. Hay que aplicar los conceptos necesarios para que una aplicacion sea escalable. Aqui 3 conceptos que pueden ayudar:

A) Cacheo minimo de variables: Tomando el ejemplo del post anterior. Lo que se debe de hacer es crear los objetos necesarios, uno por uno, usarlos y despues eliminarlos y no esperar que el recolector de basura los elimine. En Php esto se haria llamando a la funcion unset() cada vez que dejemos de usar un objeto. Lo que haces realmente es intercambiar menos velocidad por mas memoria ram. Por ejemplo:

$suma=0;
for($x=0;$x<10$x++){
$raw= mysql_query("select numeric_data from mytable where id=$x") ;
$resp = mysql_fetch_array( $raw) ;
unset($raw) ;
$suma = $resp['numeric_data']+$suma;
unset($resp) ;
}
echo "La Suma es",$suma;
unset($suma) ;

¿No seria mas facil hacer un select de todos los datos de la tabla, en lugar de estar accesando fila por fila mediante PHP? Hell yes, pero sacar todos los datos de una tabla significa mas uso en memoria RAM que poniendonos en el caso de sacar fila por fila y unsetear esa memoria que ya no vamos a usar, por supuesto que usaras mas ciclos de CPU en la segunda opcion, es lo que se dice un tradeoff entre memoria y cpu. Al final tu aplicacion sera mas lenta pero al tener mas memria RAM, mas usuarios pueden conectarse al sistema sin que se empieze la paginacion de memoria. NOTA: Particularmente no me gusta mucho este metodo debido a la particularidad como trabaja PHP liberando memoria. En la pagina de PHP acerca de unset , los comentarios de usuarios dicen cosas que pueden ser contradictorias, seria interesante ver las pruebas de alguien acerca del unset.


B) Lazy Programing: La opcion favorita. Lo que haces basicamente es en lugar de almacenar todos los datos de una vez en un objeto, almacenas solo una referencia como su ID o mejor aun, nada, y solo al momento donde requieras usar esos datos lo inicializas. Lazy Programing funciona de pelos con AJAX. Por ejemplo imaginemos en un mapa imprimes imagenes de las unidades dispuestaas en el mismo. Si quisieras saber informacion acerca de alguna unidad, haces click en la imagen y por Ajax sacas la informacion de esa unidad recien en ese momento, en lugar de calcular toda la informacion de una vez. Se podria resumir LazyOperation como "El codigo mas rapido es el que nunca se ejecuta".

C)Pensamiento Divergente: Cosas como, mejor compramos un paquete de memoria RAM y nos olvidamos la optimizacion, a esto me refiero con pensamiento divergente. Por ejemplo comprar una memoria RAM DDR2 de 2 gigas, posiblemente salga unos 40 dolares a lo mucho. El coste de implementar una optimizacion, digamos, una semana de pagarle a un programador, especialista en este tema... pues va a salir mas de 40 dolares. Siempre existiran opciones para cada cosa que queramos hacer.

Espero les haya servido en algo,y Cualqueir hatemail sobre el unset, porfavor en comentarios XD

Programacion orientada a objetos (POO), o la odias o la amas, pero debes de comprenderla. Y para comprenderla debes de conocer su objetivo primario, que es la reutilizacion de codigo, simplemente es eso. Un objeto es malo si solo lo usas una o 2 veces, si lo piensas bien facil podrias reemplazarlo por una funcion cualquiera. Te ahorrarias muchos includes o imports dependiendo del sabor en que programes. Pero la POO no esta orientado a mejorar la performance ni la escalabilidad de las aplicaciones.

En aplicaciones Desktop no hay muchos problemas sobre esto, solo es una maquina con un solo usuario, el programador crea todas las clases que quiera y el usuario no va a sentir la diferencia. El aumento de clases y objetos recarga el programa "aritmeticamente".

En Sistemas Web la cosa es diferente, aumenta un objeto por aqui y en un segundo la carga de memoria RAM aumenta en 1 mega. La cantidad de usuarios que maneje el sistema hace que aumentar una clase haga mas lento al sistema de forma geometrica. Una clase mas es igual a 1kb multiplicado por el numero de usuarios del sistema, 100 usuarios = 100KBs y solo por una clase mas!!!.


Pues bien, actualmente estoy en una fase de optimizar un poco mi codigo. Y bueno se me aparecio un caso perfecto para dar un poco de sentido comun al uso de objetos.

Resulta que mi juego tiene unidades. Cada unidad tiene propiedades, como puntos de ataque, puntos de defensa.. una propiedad llamada attrition que explicare en otra entrada... Mis unidades atacaran otras unidades asi que hice una funcion atacarUnidad() para el calculo del ataque. Lo obvio desktopmente (sic) hablando seria pensar.. "y bueno porque mejor no mejor agrupar toda esa funcionalidad en un objeto:


Y el objeto unidad ve la luz. El problema de hacer esto es que por cada unidad que exista tendrias que crear un objeto y como los datos estan en la base de datos tendras que hacer varios selects por cada unidad que quisieras crear:


Cada variable que creas en PHP y posiblemente cualquier lenguaje de programacion en web, significa mas memoria RAM y mas tiempo de procesador. Hacer consultas a la BD tambien es relativamente caro. No lo van a notar en una o 10 consultas... lo van a notar va a notar cuando tengan 100 usuarios conectados presionando f5 como chimpances, solo por el gusto de presionar f5.

¿Entonces cual seria una de las posibles soluciones? . Una posible solucion nos lo podria dar el patron de diseño flyweigth. Lo que hacemos es algo asi:


Lo que hace el patron Flyweigth es contener toda la informacion de las unidades en un solo objeto usando arrays para contener todos los datos extrinsecos (osea diferentes, como sus puntos de vida), y variables normales para contener datos intrinsecos (variables en comun de todas las unidades, como digamos el nombre del jugador de esas unidades).

En Teoria ahorramos memoria y procesamiento accesando solo una vez a la Base de Datos para recoger toda la informacion de un solo golpe. Pero en la practica esta solucion no es escalable, la diferencia entre sacar poco a poco la informacion y sacarla todo de un golpes es que consumes mas memoria RAM de un solo tiron, aunque claro harias la aplicacion mas rapida.. hasta que se te acaba la memoria ram y empieza la paginacion en disco duro, que haria mas lento al sistema. Y esto es posible en Sistemas con muchos usuarios, como los Sistemas Webs. Bad.. so Bad.

Hay alguna solucion a este problema? Pues si hay dos soluciones que expondre en un proximo post. No son las mejores pero si que ayudan. Hasta la proxima

Navegando por internet me encontre con este interesante concurso de creacion de juegos aspiciado nada menos que por la IEEE y otrs 6 organizaciones que tiene que ver ago con la ecologia o el desarrollo de juegos serios. Save The World (Salva el mundo) es el titulo de este concurso, y con premios de hasta 20 mil dolares, ademas de la recompensa moral de ayudar al mundo de alguna forma (no,no es sarcasmo =D), creo que me registrare ademas a diferencia del anterior concurso, tenemos hasta el 2010 para desarrollarlo.

Hay dos formas de concursar:

• Creando una iea hacerca de un juego: Dodne pueden participar personas de todas las edades, aqui esta la documentacion para participar en la misma. El premio para mayores de 18 años son 1000 dolares. Es solo crear docuemntacion y unas 4 o imagenes de tu idea de un juego que manejando informacion de la gente de GEO (Group Of Earth Observation) brinda en su pagina web.
  

• Diseño de un juego: Donde tendremos que tener minimo un prototipo del juego. El juego ademas tiene que tratar alguna de las problematicas que coloco abajo como foto:

El Premio son 20 mil dolares ademas de otros freebies, en esta modalidad del concurso. Sugiero entren a su pagina web para mas informacion. Mas bien dijeron que iban a poner las reglas de la segunda modalidad en febrero del 2009 pero todavia no las colocan. Creo que mandando un correo se arreglaria todo.

Eso si si alguien esta interesado en concursar, pues tengo un Game Engine que desarrollo para mi otro proyecto que podriamos usar para la creacion del juego. Interesados en concursar comuniquense commigo a mi correo designbyjeeba@gmail.com.

Tenemos server definitivo para las pruebas!!! Hell Yeah. Me afilie al hosting A2, el cual recomiendo para todas las personas que buscan la ultima version del Postgres en sus sistemas. Muchos Host que encontre trabajan con la version de 7.X, pero no A2. Los muchachos de A2 trabajan con la 8.3.X . Eso si su precio es un dolar mas caro que la mayoria pero uno paga por la calidad. Ademas eso si busquen siempre cupones que puedan tener . Por ejemplo de 10 dolares al mes que costaba el hosting por un contrato de un año, osea 120 dolares, me lo rebajaron a 100 dolares anuales despues de poner el cupon LuckyIrish, vigente hasta finales de marzo.

Bueno despues de hacerle publicidad gratuita a estos niños, tambien tenemos nueva version del juego. Ya esta en version 0.4.5 Alpha!!!. Ahora estoy en el camino de definir mejor los avances. Por ahora lo que se esta avanzando mas es la seccion BATALLAS, A continuacion defino los posibles modulos a tener y su estado:

• MODULO DE BATALLAS: Esta en Version 0.4.5 Alpha. Es la seccion actualmente manejable (no es jugable pero puede servir como demo). Donde mueves tus unidades por el mapa para batallar.
• MODULO DE CREACION: Tambien llamado GenePool. Aqui podras combinar diferentes piezas para crear una unidad hecha a tus requerimientos. Por ahora esta en version 0.0 aun no se inician los trabajos pero calculo que en la version 0.9 del modulo de batallas, empezare a modificar este modulo.
  
• MODULO CONSTRUCCION: Sin nombre todavia, es el modulo donde mejoras a tu Personaje (Mi juego es una mezcla entre RPG y RTS), comprando recursos o usando tus puntos de experiencia.Version 0.0 del mismo.
  
• MODULO NAVEGACION:Donde navegaras entre los planetas en busca de recursos o batallas. Version 0.0 pero despues de la version 0.9 del modulo de batallas que es el envio de refuerzos al planeta estara en una version 0.1 basica.
• MODULO DE INVESTIGACION: Es como un Wiki donde veras todas las cosas que haz investigado o explorado.

Realmente Postgres ahce las cosas mas sencillas. Hasta luego

Seguimos con este controversial tema. En la primera parte vimos como funcionaba las unidades boqueteras. Ahora veremos cada unidad boquetera a fondo y cuando usarla.

A) El Ariete: El ariete me dejo pensando la primera vez que lo vi:

"Y esto con que se come ikariam?".

Yo aqui hablando sobre la necesidad de que todas las unidades tengan una utilidad y ellos sacan una unidad de ataque.. sin ataque!! OMG WTF BBQ. Pero bueno analizandola un poco a fondo descubri su utilidad. Es la unidad barata y rapida para el saqueo. Es casi la mitad de barata que una Catapulta y ademas es rapida. Si mando a saquear con un ariete a alguien de mi isla me demoro 12 minutos.. si mando una catapulta .. se convierte en 15 minutos. Ahora hay un problema obvio con estas unidades: No tienen ataque, y esto es un problema que acompaña a su poder, recuerden el poder Boquetero no da el bonus a unidades con el poder de Asalto. lo que nos hace elegir otras unidades sin Asalto , como gigantes a vapor, arqueros o las mismas unidades boqueteras. Mi recomendacion: Comprar arietes si eres un jugador con: Muchas unidades sin asalto y que planea jugar pensando en la defensa como pioridad, que es casi lo mismo.



B) La Catapulta: Esta si es una obvia unidad de ataque. Su ataque es bueno.. nada sorprendente pero junto con su habilidad de boquetes y ampliandolo al maximo podrias hacer un daño de180 puntos de daño con las suficientes catapultas y una muralla de nivel 24. El mayor problema de las catapultas es que son caras. y como comentabamos en el post anterior, tienes que abrir todas los boquetes posibles en el primer turno. Asi que si no tienes el cuadruple de Catapultas por nivel de muralla enemiga ( osea unas 100 para una improbable muralla lv 25), es mejor que compres tambien algunos Arietes. Y recuerda la manutencion es lo mismo para los dos.


C) El Mortero: La Superarma, esta es por lejos mi arma preferida para ir en contra de una ciudad fuertemente amurallada. Por su excesivo precio no vas a poder comprar cantidades indutriales del mismo, asi que tendras que acompañarlo de catapultas y quizas arietes. Pero comparandolo por ejemplo contra una Catapulta upgradeado a full y atacando una ciudad lv 24.. podrias hacer unos 500 puntos de daño por mortero!, eso son como 20 espadachines con su habilidad de asalto encendida. Claro cuestan como 23 espadachines, pero el mantenimiento y el numero de ciudadanos es mucho menos.. A largo plazo ahorras un 40% de oro. Lo unico malo es la resistencia. Estarias insano si mandas puro mortero sin al menos otra tropa de soporte como 20 veces mas honderos (no bromeo, 10 Morteros y 400 Honderos, cual es la probabilidad de que se te muera un mortero?) , ademas de la unidad perfecta como acompañante de boquetes.. los gigantes a vapor con sus cerca de 200 puntos de ataque en optimas condiciones ( muralla lv 24 y mejorado a fondo).


Y finalmente mencionare algo que podria cambiar el curso del juego. He visto mucha gente con una cantidad exorbitante de Espadachines y fusileros cuando van a sititar una ciudad. Ojo para mi sitiar es una batalla grande con mas de 10 turnos por venir. Lo bueno de tanto espadachin es que tambien son buena carne de cañon, pero en batallas largas la resistencia tiende a caer. Y si cae mas del 30% de resistencia, pierdes tu habilidad de asalto. Se perdera el efecto boquetero en las demas unidades si baja su resistencia?. Si no fuera asi entonces comprar boquetes es la mejor opcion para un sitio.

Bueno tengo excelentes noticias para mi juego Xeno. Voy a mudarme a un hosting que soporte postgres, lo que me ayudara excesivamente en el desarrollo del juego. Mysql no esta mal.. pero estoy acostumbrado mas al postgres.. ademas y principalmene postgres me ofrece unas funciones para manejar matrices multidimensionales que estoy interesado en usar. Suena twisted?, solo son array almacenados en la BD.... algo .. controvertido eso si, para la gente fanatica de la normalizacion.