Programación extrema…¿Quieres salir conmigo?

Bien, tengo la idea clara de hacer un videojuego, un montón de ideas alrededor (funcionalidades, artísticas, posibles mejoras…) y tan sólo un par de cosas claras sobre como hacerlo:

• Simplicidad de las cosas que haga, es la mejor manera para adaptarse a los previsibles cambios que se van a dar, y necesaria para que otros programadores (que no sean el autor) entiendan fácilmente el código, lo puedan utilizar, ampliar o mejorar.

• Clara definición de hitos, si me propongo desarrollar una funcionalidad, quiero saber en qué momento exacto he cruzado la línea de meta. Nada de liarse a “pues esto estaría bien incluirlo”, o “seguro que en un futuro me sirve…”

• Lo primero, a por los riegos ¿Juego Multijugador online en java? Eso suena a muchos problemas que urgen ver como se van a abordar (porque afectan a partes fundamentales del juego o pueden modificarlas), o incluso ¡si no tiene una solución viable!

Es obvio enfocarlo sobre un proceso ágil y ¡carajo! los puntos mencionados arriba, son valores dentro de la metodología programación extrema, asi pues… programación extrema ¿Quieres salir conmigo?

Toca buscar y adaptar todas las herramientas/procesos que aporta la metodología y me puedan ser útiles . Dicho esto, paso a «la chicha». De momento me desenvuelvo con los siguientes elementos:

Grandes objetivos del juego: Caja de pandora de todas los aspectos generales para el videojuego. Cada uno de ellas, aglutinará historias de usuario para implementar (hay que decidir cuales van dentro y cual no) Cada uno de estos grandes objetivos, se presenta como un spring. Simplemente lo tengo guardado en un archivo tipo word un ejemplo sería:

1. Definición de lógica y reglas del propio juego.(Movimientos permitidos, consecuencias de cada uno e interacciones entre objetos)
2. Cliente visual (el cliente ya puede ver algo en su pantalla e interactuar)
3. Multijugador (Comunicación entre una partida y varios clientes)
4. Servidores de partidas (Gestion Nuevo/Modif/Elimina/Busqueda de servidores que crean partidas)
5. Perfiles de los jugadores (Gestion N/M/E/B de perfiles de jugadores)

Historias de usuario (HU): elemento típico de las metodológías ágiles, podéis encontrar mucha info en cualquier buscador, o si es la primera vez que os cruzais, entrar en wikipedia: Historias de usuario que biene bastante bien explicado. Os dejo un ejemplo de una de mi proyecto:

User Story Nº 001	Nombre: Reglas y lógica del espacio
Tipo de actividad: Nueva □ Modificacion □ Extension de US nº:
Prioridad Negocio ALTA		Prioridad Desarrollo ALTA
Fecha Inicio	Fecha Fin		Estimación
Descripción:Las partidas se desarrollan en un escenario. El escenario tiene áreas de movimiento y áreas bloqueadas.Los personajes se pueden mover por las áreas permitidas, previamente definidas por el escenario.Si entran en áreas bloqueadas el movimiento cesará para impedirlo.Los proyectiles, si entran en áreas bloqueadas, tienen que desaparecer.
Observaciones de software: Los objetos y áreas bloqueadas serán tratados como conjuntos de rectángulos

Tareas de ingeniería (TI): para cumplir los requisitos definidos en las historias de usuario, se crean las tareas de ingenierías, que definen, a nivel técnico, funcionalidades a implementar de una historia de usuario determinada. A continuación, un ejemplo de TI que esta asociada a la HU de arriba:

Eng. Task Nº 00111	Nombre: Colisiones de rectángulos
Tipo: Nueva □ Modificacion □ Extension de ET nº:
User Story Nº 001	Nombre US: Reglas y lógica del espacio
Fecha Inicio	Fecha Fin	Estimacion 6horas
Descripción: Definir un rectángulo en un espacio de 2 dimensiones. Función: dado dos rectángulos en un espacio, saber si hay colisiones entre ellos.
Observaciones:

Prueba: pruebas unitarias y generales, pruebas y comprobaciones de todo y para todo. Que quede bien claro, si planteas hacer algo, primero creas la prueba y la lanzas (si, y te fallara evidentemente) Tendrás así, perfectamente definido cual es tu propósito, además, sabrás exactamente cuando lo has conseguido, y puedes pasar a otra cosa, te ayudará a la hora de plantear como vas a implementar tu función (ya sabes: tener claro un problema es tener la mitad de él resuelta). Yo utilizo JUnit, creo una clase test por cada clase que tenga, y luego otra test extra que agrupe las clases de un paquete o secuencia de procedimientos.

No espero tener la forma de trabajo perfectamente definida desde el primer día, también este es un proyecto de descubrir/aprender/experimentar/desarrollar una metodología de trabajo útil y eficaz, asi os pido comentar/debatir sugerencias y propuestas.