Sergio Peñalba Lopez NIA:

Transcripción

1 Autor: Sergio Peñalba Lopez NIA:

2 INTRODUCCIÓN CodeRuler es un juego en el que se simula un reino medieval en el que los jugadores deben competir manejando una serie de elementos programables, dichos elementos son campesinos, caballeros y castillos. El funcionamiento es muy simple, se proporciona a cada jugador una serie de interfaces con los que manejar todos los elementos disponibles, y dichos jugadores deben programar una clase(llamada MyRuler), la cual maneja cada uno de los elementos citados anteriormente. Cada jugador es colocado en un terreno bidimensional junto con el resto de competidores y dicho terreno está dividido en cuadrículas, ganando aquel que más puntos consiga al final del juego. El juego dispone de un reloj que se emplaza en el escenario de la competición en el margen derecho, una vez este reloj marque el final del reto, se hace un recuento de puntos. Se pueden ganar puntos de tres formas distintas, la primera es haciendo que los caballeros capturen tanto campesinos, como castillos, como otros caballeros contrarios; la segunda opción para ganar puntos es cultivando la tierra, esta acción es realizada por los campesinos, y por último, también se ganan puntos por cada pieza que sobrevive al duelo. La tabla de puntuaciones es la siguiente: Tabla 1. Puntos por capturas Si capturas... Un campesino Un Caballero Un Castillo Obtienes 4 puntos 6 puntos 15 puntos Tabla 2. Puntos por piezas supervivientes Tipo de Pieza Campesino Caballero Castillo Tierra Cultivada Puntuación 1 punto 2 puntos 25 puntos 1 punto por cada 10 cuadrículas cultivadas 2

3 El escenario, como ya he dicho está dividido en una serie de cuadrículas por las que las piezas se mueven sin importar el tipo de terreno que aparece por pantalla, teniendo unas dimensiones determinadas de las que se pueden extraer coordenadas fácilmente: En resumen, cada jugador tan solo debe implementar la clase MyRuler de modo que maneje a todas sus piezas llevando una estrategia adecuada para ganar más puntos que sus rivales. ENTORNO DE SIMULACIÓN Todo este programa se implementa bajo un entorno llamado Eclipse, el cual es una herramienta para lenguajes de programación a la que se ha adaptado este juego. Durante el desarrollo la herramienta te permite depurar y probar tu código de varias maneras, tanto ejecutando tus Rulers contra ejemplos preprogramados, como contra otros jugadores, así como una opción de Debug que te permite depurar tanto contra dichos ejemplos así como contra otros equipos. En primer lugar se crea un proyecto CodeRuler en el entorno de simulación de Eclipse, en el cual ya se incluye tanto el classpath como el resto de interfaces necesarios para el manejo de los elementos de cada jugador. Una vez creado se abre unesqueleto de la clase MyRuler en la que aparecen exactamente 4 métodos: 3

4 getrulername() Este método nos permite introducir el nombre de cada jugador. getschoolname() Este método nos permite incluir el nombre de la escuela o institución a la que pertenece cada jugador. initialize() Este método se ejecuta una vez al principio de cada juego para cada jugador, y permite a cada uno de ellos que realicen una inicialización. ordersubjects() Este método es llamado por el simulador durante cada turno para cada jugador, de modo que es en este método donde definiremos el modus operandi de nuestras piezas. Por tanto, como podemos ver, tan sólo debemos programar el método ordersubjects() de manera que organicemos nuestra estrategia. En mi caso, he creado una serie de métodos adicionales que empleo en dicho método para que el código resulte más legible y cada acción se realice por nombres y no por código puro. Cada una de las piezas, tanto los campesinos como los caballeros ( ya que los castillos no poseen movilidad) tienen 8 posibles movimientos, de entre los cuales sólo pueden ejecutar uno por turno y que están bien definidos y se representan o bien por números o bien por unas propiedades fijas: 4

5 Cabe reseñar que una vez que el juego ha sido lanzado, podremos ver la puntuación de cada uno de los jugadores en el margen superior derecho, siendo la puntuación de la izquierda la referente a la conseguida gracias a las capturas y la de la derecha la cantidad de terreno cultivado: Cada jugador comienza con 10 caballeros, 10 campesinos y 1 Castillo, pero en cada castillo se producen mas unidades, ya sean campesinos o caballeros. La velocidad de creación (en número de turnos) de estas piezas irá en función de la tierra que en ese momento se tenga cultivada. Podemos ver la relación existente en el siguiente cuadro: 5

6 Tierra Cultivada Número de turnos para la creación de una pieza 124 o menos No se crean nuevas piezas turnos turnos turnos turnos turnos Más de turnos A cada castillo le podemos dar la orden de que produzca bien campesinos, bien caballeros mediante los métodos createpeasants() y createknights(), respectivamente. Cuantos más castillos tengamos, más piezas produciremos y más puntos obtendremos. Los campesinos cultivan la tierra tan sólo moviéndose sobre la cuadrícula y los caballeros se pueden mover también, pero aunque estén sobre una cuadrícula, ésta no será cultivada. A la hora de capturar tanto castillos, como campesinos, como caballeros, se usa el método capture(iknight caballero,int dirección). En esta ocasión, el caballero correspondiente captura la pieza (que desaparece del escenario), pero no se mueve ocupando su lugar, tan sólo se queda en la cuadrícula adyacente. En el caso de los caballeros, cada uno cuenta de inicio con una fuerza de 100 unidades, la cual se irá restando en un número aleatorio entre 15 y 30 a medida que otros caballeros oponentes intenten capturarlo. En caso de que nuestro caballero capture a otro caballero oponente, ganará 20 puntos de fuerza para posteriores enfrentamientos. Si un caballero captura un castillo oponente, la bandera de éste cambia de color y por tanto dicho castillo de dueño. La implementación de cada uno de los jugadores necesita una cierta restricción, pues de otra forma, cada turno sería interminable y el juego duraría demasiado. El método initialize() está restringido a un segundo de duración por jugador para las inicializaciones que cada participante desee hacer. Por otro lado, el método ordersubjects(int) está restringido en cada turno a 500ms, es decir, medio segundo de duración de ejecución para cada turno, tiempo después del cual, si el jugador sigue ejecutando código será descalificado. 6

7 IMPLEMENTACIÓN El programa se estructura a través de una serie de interfaces que facilitan la programación de cada jugador proporcionando una serie de herramientas a través de métodos. La estructura es la siguiente: Interfaz IObject Es un interfaz que es implementado por todos los objetos en el juego. Permite obtener la localización de cualquier objeto, así como determinar la distancia y dirección hasta un dicho objeto. También puede determinar el ID de un objeto, el jugador al que pertenece y si dicho objeto esta vivo (no ha sido capturado por un caballero oponente) en el juego. Interfaz IPeasant Extiende el interfaz IObject y define el interfaz de todos los campesinos del juego. 7

8 Interfaz IKnight Extiende el interfaz IObject y define el interfaz de todos los caballeros del juego. Además, también define un método con el que se puede obtener la fuerza que le resta al caballero seleccionado: int getstrength(). Interfaz ICastle Extiende el interfaz IObject y define el interfaz de todos los castillos del juego. Interfaz IRuler Define el interfaz de todos los Rulers del duelo. Todos los jugadores extienden este interfaz. Permite encontrar cuales objetos pertenecen a qué jugador. Se pueden obtener tanto los castillos, como los caballeros, como los campesinos de un jugador. También se puede obtener la cantidad de tierra que lleva cultivada un determinado jugador, así como los puntos acumulados, su nombre y el de su escuela o institución. Interfaz World Este es un interfaz de ayuda que provee métodos para obtener todos los jugadores, así como todos sus caballeros, castillos y campesinos. También ofrece la posibilidad de obtener un objeto en una posición determinada, así como el propietario de una pieza de tierra determinada o el número de turnos que han transcurrido hasta el momento. Por último ofrece un método con el cual se puede obtener un punto del mapa hacia una dirección determinada desde una posición dada. ESTRUCTURA DEL PROGRAMA He tratado de diferenciar cada una de las piezas como objetos en sí. Para cada una he aplicado un tratamiento y métodos distintos, pues cada una desempeña su función y debía diferenciarlas. Para explicarme con claridad voy a dividir, por tanto, los diferentes métodos y estrategias en función de cada una de las piezas: 8

9 CAMPESINOS La idea es que los campesinos cultiven la tierra con la mayor eficiencia posible a la vez que intentan evadir de alguna manera ser capturados por caballeros oponentes. En primer lugar, he implementado un método para que cultivasen la tierra de una manera eficaz: public void cultivartierra(ipeasant peon) Este método recibe como parámetro el campesino objeto de cultivo y será usado en un bucle a fin de que todos los campesinos cultiven la tierra. La idea que sigue es la de explorar todas las cuadrículas adyacentes de manera que si alguna está libre o no es de mi propiedad se mueva sobre ella. En caso de que todas las cuadrículas que le rodean sean de mi propiedad, el campesino realiza un movimiento aleatorio y vuelve a realizar una comprobación. De esta manera intentamos evitar que se cultive tierra que ya me pertenece y además que el campesino no se quede encerrado en un espacio de tierras propias. public int revisionterreno(ipeasant peon) Este método recibe como parámetro el mismo que el método anterior. En este caso, lo que realiza es una revisión de todas las cuadrículas adyacentes y en caso de que haya un enemigo en alguna de ellas devuelve la dirección opuesta a dicha casilla para el movimiento del campesino a la hora de huir. Los peones realizan una revisión inicial del terreno y si no hay peligro cultivan la tierra, mientras que si existe dicho peligro huyen en la dirección opuesta. CASTILLOS En este caso, para los castillos hay pocas instrucciones. En caso de que el número de peones del enemigo sea mayor que el numero de caballeros propio, entonces produce caballeros, en caso de que el número de caballeros enemigos sea mayor que el número de caballeros propio, también produce caballeros. Sólo en caso de que estos dos requisitos no se cumplan, entonces producirá campesinos. 9

10 CABALLEROS En el caso de los caballeros la estrategia es más compleja. En primer lugar, se hace la selección del objetivo, y para ello he seguido la siguiente estrategia, que consiste en eliminar en primer lugar todos sus campesinos, seguir con sus castillos y a partir de ahí atacar a sus caballeros. Todos los objetivos se guardan en una tabla según su tipo, por lo que siempre que un objetivo sea asignado a un caballero, éste irá siempre a capturar el mismo a menos que lo logre o muera. Para ello, he construido 3 Hashtable distintas, una para cada tipo de pieza y las he ido actualizando a medida que se producen los eventos. Para ello, elimino a los campesinos y cuando ya no queda ninguno, ataco a los castillos, hasta que sean todos míos. Después de eso, la táctica a seguir es observar uno por uno los oponentes caballeros. Si su fuerza es mayor que la del caballero que yo poseo y al que he asignado para capturarle, entonces le asigno a ese oponente hasta 5 caballeros distintos para poder reducirle. Esto lo aplico para cada uno de los oponentes y, al menos en las simulaciones de ejemplo, es muy efectiva contra cualquier rival. Los métodos que he implementado para tales fines son los siguientes: public IPeasant seleccionpeon(iknight caballero,ipeasant[] peonesenemigos) Este método selecciona los campesinos objetivo de una manera eficiente y repartiéndolos habiendo siempre un caballero al menos para cada campesino. public ICastle seleccioncastillo(iknight caballero,icastle[] castillosenemigos) Este método es exactamente igual que el anterior pero particularizado para las piezas Castillo. public IKnight seleccioncaballero(iknight caballero,iknight[] caballerosenemigos) Este método es igual que los dos anteriores con la salvedad de que incluye un booleano que me dice si el caballero enemigo debe tener más caballeros asignados en su captura o no. public int revisionterrenocaballeros(iknight caballero) Este método revisa las cuadrículas adyacentes del caballero y en caso de que haya un enemigo, modifica un booleano para informar y devuelve un entero con la dirección e la que se encuentra dicho enemigo. En caso de que no haya enemigos, devuelve 0. 10

11 public void ofensivapeones(iknight caballero,ipeasant enemigo) Este método es el que gestiona la ofensiva a los campesinos. Se le pasa como parámetro el campesino a capturar y el caballero asignado a tal tarea. Dicho método incluye en la tabla de asignaciones de campesinos una nueva entrada, o la elimina si captura al campesino. Busca en el terreno el objetivo y se mueve en la dirección de este hasta que lo tiene en una casilla adyacente para poder capturarlo. public void ofensivacastillos(iknight caballero,icastle enemigo) Este método es idéntico al anterior con la única diferencia de que en este caso los objetivos son los castillos enemigos. public void ofensivacaballeros(iknight caballero,iknight enemigo) Este método es idéntico a los anteriores con la salvedad de que los objetivos son caballeros. public void capturascaballeros(iknight caballero,iknight enemigocaballero) Este método es el que gestiona los ataques a los caballeros enemigos. En caso de que la fuerza del enemigo sea mayor, asigna hasta 5 caballeros para su captura, activando o desactivando un booleano que nos dice si aún ese enemigo necesita más caballeros para capturarle o no. Por último, cabe reseñar que la estrategia seguida en el ordersubjects(int) es la siguiente: primero ordeno la producción de los castillos, segundo efectúo las operaciones con los campesinos y por último, los caballeros revisan el terreno alrededor suyo, capturan los campesinos enemigos, capturan los castillos enemigos, y por último, capturan los caballeros enemigos. 11