Durante ésta semana pasada, ésta y la siguiente nuestro tiempo es escaso y no tenemos el suficiente como para poderlo dedicar a Mandarina (exámenes, trabajos…), aunque intentamos sacarlo de debajo de las piedras para poder ir haciendo algo.
Entre otras cosas intentamos montar nuestro entorno de trabajo, y como ya dije en un post anterior, escogimos Code::Blocks. La principal ventaja de este IDE es que es multiplataforma, y entre las plataformas que soporta se encuentra Windows. Lo primero que pensamos fue programar desde Linux y utilizar MingW32 como compilador cruzado, combinándolo con Wine para ir haciendo las pruebas (al menos al principio).
El proceso de configuración del IDE para conseguir nuestro propósito lo hicimos a partir de éste tutorial que enlazo:
http://forums.codeblocks.org/index.php?topic=3343.0
Cuando intentamos compilar ejecutables no tuvimos ningun tipo de problema, pero cuando intenté compilar una DLL la cosa ya fué otro cantar. El mensaje de error era el siguiente:
“libgajo” does not support the current platform. Skipping…
Por cierto, la librería que dará soporte al manejo de paquetes se llamará LibGajo, lo decidimos así porque la palabra gajo tiene cierta relación con la palabra Mandaria y porqué en el buscador Google la búsqueda del vocablo libgajo (por el momento) devuelve 0 entradas.
Volviendo al tema anterior, ¿Qué hicimos para solucionarlo? Pues descargar la versión instalable de Code::Blocks para Windows (con MingW32 integrado) e instalarlo y usarlo a través de Wine. Por lo general utilizamos la versión de Linux, y sólo cuando tenemos que compilar pasamos a la versión que corre sobre Wine. Obviamente ésto que hemos hecho es una chapuza, y esperamos que sea sólo provisional, cuando encontremos la solución definitiva ya lo comentaremos.
Hasta otra!
Posted in Desarrollo Tagged: Desarrollo
Hola amigos. Soy un estudiante de la universidad de Cádiz y voy a aventurarme a realizar un Simulador de juego de lucha 1vs1, básicamente y a “grosso” modo mi proyecto consistirá en un conjunto de herramientas escritas en c++ y ayudada con la biblioteca SDL, que permitirá al usuario disfrutar de un juego de lucha al puro estilo street fighter II y otros juegos de este subgénero del arcade.
Xfree fighter será un videojuego escrito con este Simulador, pero primero tendré que construir el simulador y luego como demostración del poderío de éste, construir fácilmente el juego. ¿ Imagináis ya el alcance de mi proyecto? podréis,a partir de la lectura de manuales de mi simulador, crear vuestro propio juego fácilmente, modificar código, mejorarlo, seréis totalmente libres e intentaré hacer código legible y claro, para programar nuevas funcionalidades. Siendo el juego un comienzo no un fin.
También daré la opción de modificar personajes sin tener conocimientos de multimedia y programación, podréis poner a personajes predeterminados la cara de vuestros profesores de facultad, a los políticos, a vuestros amigos …..
Bien amigos pues menos charla y ha comenzar con la aventura, este blog intentaré llevarlo al día plasmando en él anécdotas de mi vida que me han llevado hacer este proyecto, mis frustraciones ,mis logros, mis metas….
Y no me gustaría irme sin dedicar mi proyecto a mis padres , mi novia , mis hermanas y a mis abuelos , yo no sería nada sin ellos.
¡Nada os pertenece en propiedad más que vuestros sueños!!
F.W.Nietzsche
Como todo proyecto, sin planificación no puede ir a ningún lado, vamos a poner 6 objetivos básicos los cuales tendré que superar para hacer una versión inicial:
Notas sobre la parte de programación y el diseño del juego:
El videojuego se implementará usando c++ estándar, es decir en todo momento se separará siempre que se pueda parte gráfica (SDL) y el juego en sí. Esto se pondrá de manifiesto y lo reiteraré muchas veces. También será muy importante el uso de ficheros para lo que será la carga, por lo que tendré que definir formatos adecuados en los cuales (teniendo en cuenta que el usuario puede ampliar,crear,modificar personajes) estos serán cargados o no tendrán errores en el juego.
EL HOMBRE NUNCA SABE DE LO QUE ES CAPAZ HASTA QUE LO INTENTA.
Charles Dickens (1812-70)
Finalizada la traducción al ingles de la guía de usuario, aunque dado que mi ingles no es muy expléndido quiero buscar que lo revise alguien un poco más puesto. Ahora solo falta la guía de desarrollador y la internacionalización de la página web, incluida junto a una profunda renovación de ésta, ya que dada las prisas con la que se creó, este tema quizas sea la parte más debil de la aplicación.
Bueno, pues a seguir trabajando, aunque los próximos días lo voy a dedicar a centrarme un poco en los otros proyectos que tengo entre manos, la certificación php y el first.
Pues listo, ya tengo el repositorio un poco mas ordenado, donde en el tronco podemos ver los tres prototipos ya creados y el nuevo prototipo de la aplicacion en el que estamos trabajando, prototipo 4. Hablamos de prototipo porque la planificación de gcalfaces esta orientado al ciclo de vida “prototipado rapido”, si accedeis a la documentacion via svn anonimo o via www.gcalfaces.com podeis ahincar más en este tema, ademas de poder “disfrutar” de la mucha documentación existente.
A partir de ahora, de aqui a unos dias o semanas se va a intentar traducir los manuales de usuario y de diñador a ingles, ademas de la internacionalización de la página web www.gcalfaces.com. No es un tema de desarrollo pero creemos que es importante sobre todo en el tema de crear comunidad.
A continuación de este tema, el procedimiento será definir un plan de trabajo, realizando una lista de features a desarrollar e ir acometiendolas en orden de importancia, de momento ya disponemos de una primera lista beta, que adjunto a continuacion, que se creó al finalizar el proyecto fin de carrera y antes de comenzar este concurso:
Acciones de difusion
Acciones Inmediatas
Crear en svn prototipo 4, version 1.01 -> Hecho
Refinamiento vista de congreso
(se podria poner una leyenda de los colores al final de la vista)
Bueno, los que habeis visto mi blog ya habreis leido que trabajo con Symfony, un framework para php. El caso es que ya se van viendo cosas funcionales del proyecto como entrar y ver usuarios, añadir unidades básicas con las que luego trabajaremos, definir factores de conversión entre unidades para facilitar luego la lectura de los informes, y aunque poca cosa más, hay que decir que esto se puede hacer en dos idiomas y medio (inglés, español y medio francés).
Para poner en marcha este software en tu servidor tendrías que seguir las instrucciones de la web de Symfony, conocer la versión que el menda está usando (1.0.x, donde x tiende a infinito en función del tiempo), buscar en los ficheros de configuración como ha hecho esto … vamos, creo que es un poco lio.
Por suerte Symfony nos ha dotado de un sistema mucho más facil. Cuando salga la primera versión publicada de Gesport no será necesario instalar Symfony desde PEAR configurar el servidor para que apunte a las librerias de symfony como base del sistema ni nada parecido. Lo único que se deberá hacer es copiar el contenido del programa en un directorio del servidor y hacer que el dominio apunte al lugar adecuado que es el directorio web del proyecto.
Si yo estoy trabajando con Symfony instalado con PEAR, lo que significa que la bibliotecas de funciones estén por los /var/share, ¿como es posible que las encuentre?. Pues bien, este entorno de trabajo tiene un comando para “congelar” una versión en un determinado momento. Esta congelación no hace otra cosa que preparar la aplicación web para su publicación copiando las librerias necesarias en el lugar que deben estar (solo las necesarias, así que si no usas internacionalización no te pondrá los ficheros de este conjunto de helpers).
Si os descargáis la versión nocturna no tiene esta característica. La versión nocturna no es otra cosa que un proyecto de eclipse preparado para trabajar en un entorno de pruebas, con un usuario y clave genéricas, que necesita de las librerias instaladas o redireccionadas de alguna manera en la configuración de vuestro apache. Esta parte del proyecto ya la tenía hecha antes de comenzar el concurso, pero es probable que aun así os la cuente, pues si contais con un servidor dedicado configurar una vez Symfony con PEAR y añadir más proyectos que lo usen es coser y cantar. Antes de eso seguiré programando (que ayer no hice nada por un viaje) y buscando múltiples soluciones a los problemas que van surgiendo, como el subir las imágenes a la base de datos sin entrar en conflictos con nada del framework o que cuando un usuario cambie la configuración de internacionalización quede registrado en su perfil para la próxima vez que entre en vez de coger el predeterminado del navegador que use y lo tenga que cambiar a mano…
Mucho trabajo e ideas, así que a por ellas.
Desde hace algún tiempo, en el que me metí en el mundo del BI, me he dado cuenta que el siguiente paso, es meter las reglas de negocio dentro de los desarrollos.
Yo había oído habla de Jrules, que es una herramienta de pago.
Pero he encontrado, esta opción que es de jboss y se llama Drools que es de JBoss.
Tambien , se me ha pasado , por la cabeza ,el tema de meterlo dentro de Red Clover pero , creo que es abarcar demasiado , en primera instancia , lo mejor es no abarcar demasiado desde un principio.
He aquí un poco mas detallado lo que es Drools, que he encontrado por Internet.
Drools (http://drools.org) es una implementación libre de un motor de reglas de negocio compatible con la especificación JSR-94 Rules Engine API (http://www.jcp.org/en/jsr/detail?id=94). ¿Y qué es un motor de reglas de negocio? Es un componente que, a partir de una información inicial y un conjunto de
Reglas, detectas qué reglas deben aplicarse en un instante determinado y cuáles son los resultados de esas reglas.
Uno de los puntos fuertes de los motores de reglas de negocios es que hablan el mismo lenguaje que el dominio del problema. Un ejemplo típico: supongamos que estamos hablando con un cliente para el desarrollo de una tienda virtual.
Algunas de las cosas que nuestro cliente nos pediría pudieran ser:
Si la cuantía del pedido supera cierta cantidad o si es un cliente de confianza, entonces se le aplica un descuento. Si se compra más de N productos del mismo tipo se le aplica un descuento. Entre las fechas X e Y, un producto está en oferta y, si se lleva 2, se le añade un 3º gratis
En una aplicación normal, todo lo anterior deberíamos codificarlo en métodos de clases que se ejecutaran al procesar un pedido, lo cual no siempre es sencillo. Con un motor, solo tenemos que indicarle las reglas de negocio, e ir indicándole los hechos. En este ejemplo, tendríamos que suministrarle al motor la información sobre los pedidos, clientes y productos mediante clases JavaBean.
Otra ventaja es a la hora de realizar cambios o mantenimiento. Si nuestro cliente desea cambiar el descuento por pedido, o el descuento por número de productos, o las fechas o tipos de productos (o quitar todos los descuentos), con un motor de reglas de negocio sólo es necesario cambiar las reglas, sin necesidad de modificar código, recompilar, ni siquiera de parar la aplicación.
Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo (o el conocimiento que tiene), y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se guarda el conocimiento (objetos Java) que el motro utilizará para decidir que reglas deben activarse.
Dentro de las reglas pueden existir conflictos. Un conflicto es cuando varias reglas distintas pueden activarse para el mismo conjunto de hechos y, la aplicación de dichas reglas, pueden tener resultados contradictorios. Algunas de las estrategias para resolver conflictos son: asignarle una prioridad a cada regla, estrategias FIFO o LIFO, aplicarlas en el orden en que se declararon o aplicarlas en orden aleatorio.
Existen otros motores de reglas de negocio para java, por ejemplo
JESS (http://herzberg.ca.sandia.gov/jess/),
Mandarax (http://mandarax.sourceforge.net/)
OpenRules (http://java-source.net/open-source/rule-engines/openrules).
También hay Motores de reglas de negocio para plataforma .NET como Quick Rules, JRules o Blaze.
Los motores de reglas de negocio pueden utilizarse, por ejemplo, para desarrollar prototipos rápidos o, incluso, para implementar la lógica de la aplicación. También pueden utilizarse como parte de un sistema de workflow.
Screeshots
Demos
Después de un poco de trabajo, hemos realizado un primer acercamiento a lo que queremos desarrollar, para visualizarlo más comodamente hemos hecho un pequeño mapa mental con la herramienta freemind, como este se ira modificando hemos creado una pagina solo para el llamada hoja de ruta
Bueno, para ser sincero, mi juego funciona, pero tengo el código más desorganizado del mundo. Una de las razones por las que me apunto al concurso es para obligarme a mi mismo a tomarme más en serio la organización y la documentación.
Para empezar, he organizado toda la jerarquía de directorios y, he movido los ficheros de código a una carpeta src. Además he eliminado muchas cosas(texturas, fuentes, etc) que ya no utilizaba pero no las había borrado.
Además he mejorado(mucho) la compilación creando varios makefile que facilitan la labor. Mi próximo objetivo es crear un script sencillo para automatizar la instalación del juego, instalando las dependencias y llamando al makefile anterior.
Por último, me gustaría conocer vuestra opinión, la mayoría del código lo tengo escrito en español, pero me tienta traducir al inglés, más que nada porque los nombres quedan mas molones, por ejemplo, mi clase ManagerSonido se traduciría en SoundManager, mucho mejor ¿eh?
View Poll
La verdad es que no estamos muy seguros de cómo surgió la idea de F.O.G. Creemos que fué uno de esos días en los que nuestro tema de conversación trataba sobre videojuegos (para variar :-) ), en el que comenzamos a producir ideas sobre cómo sería ese hipotético juego que ...