Cambios

Después de haber leído e investigado más a fondo sobre formas de trabajar sesiones con Django hemos decidido hacer ligeros cambios en el diseño y la implementación de la base de datos que ya teníamos hecha. Agregamos una tabla a la base de datos con el fin de mantener un registro de las actividades completadas por los jugadores, se agregaron algunos campos a las otras tablas pero principalmente se cambió la tabla Usuario.

Las ventajas de usar este nuevo modelo son:

• Métodos pre hechos de gran utilidad tanto para administrar como para implementar en las funciones de nuestra lógica.
• Seguridad en el manejo de datos mediante password cifrados y no visibles de manera sencilla
• Validación en los datos para evitar caracteres que puedan comprometer la seguridad del sistema
• Capacidad de autenticar de manera automática y otorgar permisos a los usuarios

Las desventajas:

• La manera de trabajar con los fixtures cambia debido a la seguridad que se menciona antes, esto trae también la desventaja de no poder registrar usuarios mediante los fixtures, dependiendo totalmente de la base de datos
• Modificar las pruebas de unidad

Por otro lado, ya tenemos la interfaz de inicio casi total (falta modificar unas cosas de diseño), y así es como se ve

Por descuido no habíamos subido en la semana anterior todo lo que habíamos avanzado en las sesiones de trabajo que habíamos tenido, pero el ritmo de trabajo ha sido continuo aunque hasta cierto punto un poco accidentado por errores que no nos habían dejado cumplir a cabalidad con los tiempos requeridos.
toda la semana anterior nos habíamos concentrado, como habíamos espeificado en las tarjetas, en la creacion de las bases de datos de nuestro sistema. cuyas tablas ya quedaron implementadas.
También comenzamos la parte de los registros de usuario y validacion de ellos mismos. Al principio quisimos hacer uso del modelo user definido por django, pero no pudimos concluir el proceso usando este modelo ya que nos producía algunos errores a la hora de probar las tablas. sentiamos que el manejo que hacia de las tablas y la informacion que le dabamos era un poco rara y no nos permitiría hacer los fixtures de la manera que queríamos. Hemos intendado resolver el problema y empezamos a ver si sería mejor para nosotros adecuarnos a este modelo o buscar otra opcion para desarrollar lo que queremos.
También comenzamos a hacer los templates del sistema. Usando varias herramientas comenzamos a diseñar las hojas de estilo y las demás interfases del sistema. pero también tuvimos algunos problemas por no haber tomado en cuenta los cambios que tenemos que hacer para que django nos deje manejar el contenido estático, como las imagenes que usaríamos como fondo y nuestras barras.
Seguimos trabajando en finalizar nuestra segunda historia, y acoplarnos con los tiempos que habíamos propuesto. Al mismo tiempo seguimos trabajando en nuestra tercera y cuarta historia para terminarlas segun los tiempos que habiamos propuesto.

Diseño Detallado de la Base de Datos

Como en la entrada anterior lo desciribimos, se hizo un diseño general de la base de datos siendo suceptible a cambios. El cambio más drástico fue el modelo que se usó, ya que el anterior trato de hacer todo 1 a 1, pero al estudiar más a fondo la implementación en Django se hizo un diseño que adoptara los modelos de Django, haciéndolo que fuese de muchos a muchos.

Por otra parte hemos decidido que usaremos MySQL que es una base de datos más robusta que SQLite y se puede utilizar sin problemas en un ambiente distribuido. Además con esta base de datos se puede sacar ventaja también de los modelos de Django para la creación de las tablas de la base de datos.

A continuación se muestra el diseño detallado de la base de datos, tal y como ha sido implementada en Django:

Esta parte la definimos durante el fin de semana, pero hasta hoy hicimos un commit sobre la base de datos que implementamos, ya que también, duarante el fin de semana estuvimos estudiando nuestras opciones y al elegir MySQL, estudiamos su forma de implementación, así como la actualización y adaptación de nuestras StoryCards y TaskCards

Diseño Conceptual del Juego

El día de hoy se hizo un burdo diagrama de flujo en el cual se puede ver la transición en general que el usuario recorrería para entrar e interactuar en el juego. Todo esto con el fin de definir completamente la estructrura de la base de datos, más específicamente, las tablas que se necesitarán para el funcionamiento del juego y sus atributos.

Para explicar mejor el diagrama de flujo, cabe mencionar que el usuario al entrar a las interfaces de la zona roja puede moverse a cualquier otra dentro de la zona roja, y de igual manera, en cualquiera de ellas, el usuario puede finalizar la sesión y automáticamente será direccionado a la página de login. Por otra parte, para entrar a la interface denominada "RETO CON BOSS/USUARIO" desde las interfaces de "ACTIVIDADES" y "USUARIOS PARA RETAR", que dependiendo de si es un usuario o un bot automatizado, interactuará con la tabla que le corresponda para cargar los atributos para el reto.

El diseño de la base de datos se basa en un análisis del diagrama de flujo anterior, resultando en el diseño que se muestra a continuación. Cabe mencionar que este diseño podría cambiar durante el desarrollo del juego, debido a requerimientos que no fueron detectados al momento del análisis o por una mala relación entre las tablas, por lo que lo consideraremos como la versión 1.0 del diseño.

Descripción General del Proyecto

Al pensar en la temática de nuestro proyecto, y en la manera en la que se desarrollará el mismo, tuvimos una lluvia con varias de las ideas que propusimos tentativamente para desarrollar.

Algunas de ellas nos parecieron más llamativas que otras, lo que hizo que redujéramos las opciones a dos, un sitio de apuestas en línea y una página de un juego de rol. Al principio nos gustó un poco más la idea de las apuestas, ya que es algo atractivo para los clientes y sentíamos como un buen reto desarrollar dicho proyecto, pero no teníamos un experto que pudiera estar con nosotros y con el que pudiéramos tener el contacto necesario.

Esto nos dejó con la idea de que sería mejor para nosotros desarrollar la página con el juego de rol (RPG), ya que el experto sería alguien con quien tendremos mucho más contacto y estará mucho más comprometido con el proyecto. Tenemos pensado hacer un juego bastante atractivo e innovador, un tema en el que al menos nosotros, no hemos visto. Crearemos un juego con una temática escolar, los niveles que tendría que pasar le darían más puntos en experiencia y lo llevarían a tener mejores herramientas para poder pasar a los niveles más fuertes, posiblemente con ejemplos reales.

Nuestro experto será Gerardo Samuel Cabello Montes de Oca. Él tiene 24 años de edad; Gerardo se encuentra estudiando la carrera de Ingeniería en Tecnologías Computacionales en el Tecnológico de Monterrey, Campus Estado de México. Impulsado por un enorme gusto sobre los videojuegos decide seleccionar su concentración en el área de Sistemas Inteligentes y Computo Visual. Uno de sus géneros favorito de videojuegos es el llamado Juego de Rol o Rol Play Gaming por sus siglas en inglés (RPG), ésta será la temática que tendrá nuestro proyecto lo cual nos da la razón para tomarlo como experto.

Google Code Proyect: Solidaridad

The Valedores de Atizapan Team is glad to introduce you to the “Solidaridad” project hosted in Google Code. This way you can follow us on the development of our project. The link to our project is:

http://code.google.com/p/solidaridad/

The license chosen for our project was the GNU General Public License v3 (GPL v3). We chose this license for several reasons. The first one is that this is the oldest Open Source license, written by Richard Stallman. We liked this particularly because it doesn't allow anyone to make his code private, and not allowing others to get benefited from it.

It also gives us the certainty that if we need to defend ourselves against a third party that has misused our software or has violated the terms agreement, we will have the ball in our side, as history has taught us.

Regarding the version, we decided to use the third one since its the most adapted to today's situations. It has several improvements regarding the software patents, free software license compatibility, a new definition for source code, and hardware restrictions on software modification; as well as internationalization improvements on how violations are handled, and how other permissions can by added by the copyright holder.

If you have any comments let us know and have a nice day!

Eh aquí a los Valedores de Atizapán

Como lo prometido es deuda, aquí está la foto para que nos conozcan en persona.

Saludos!!!

De derecha a Izquierda: Alejandro, Gerardo, Guillermo y Víctor