• No se han encontrado resultados

Programación 2 Curso 2015/2016. Práctica 1 Imperial Commander (parte 1)

N/A
N/A
Protected

Academic year: 2021

Share "Programación 2 Curso 2015/2016. Práctica 1 Imperial Commander (parte 1)"

Copied!
8
0
0

Texto completo

(1)

Programaci´

on 2

Curso 2015/2016

Pr´

actica 1

Imperial Commander (parte 1)

Esta pr´actica consiste en la realizaci´on de un programa que permita gestionar la flota de cazas imperiales que lleva un destructor imperial en sus bodegas.

1.

Normas generales

1.1.

Entrega

1. El ´ultimo d´ıa para entregar esta pr´actica es el viernes 26 de febrero, hasta las 23:59. No se admitir´an entregas fuera de plazo.

2. La pr´actica debe tener s´olo un fichero llamado “imperialCommander.cc”.

1.2.

Detecci´

on de plagios/copias

En el Grado en Ingenier´ıa Inform´atica, la Programaci´on es una materia fun-damental, que se aprende programando y haciendo las pr´acticas de las diferentes asignaturas (y otros programas, por supuesto). Si alguien pretende aprobar las asignaturas de programaci´on sin programar (copiando), obviamente tendr´a se-rios problemas en otras asignaturas o cuando intente trabajar. Concretamente, en Programaci´on 2 es muy dif´ıcil que alguien que no ha hecho las pr´acticas su-pere el examen de teor´ıa, por lo que copiar una pr´actica es una de las peores decisiones que se puede tomar.

La pr´actica debe ser un trabajo original de la persona que la entrega; en caso de detectarse indicios de copia de una o m´as pr´acticas se suspender´a la asignatura a todos los alumnos implicados (tanto al que copia como al que se deja copiar), y se enviar´a un informe a la direcci´on de la EPS, para que se tomen las medidas disciplinarias oportunas.

1.3.

Otras normas

1. La pr´actica se debe entregar exclusivamente a trav´es del servidor de pr´ acti-cas del departamento de Lenguajes y Sistemas Inform´aticos, al que se pue-de accepue-der pue-despue-de la p´agina principal del departamento ( www.dlsi.ua.es, “Entrega de pr´acticas”) o directamente en la url http://pracdlsi.dlsi. ua.es.

No se admitir´an entregas por otros medios (correo electr´onico, Cam-pus Virtual, etc.).

El usuario y contrase˜na para entregar pr´acticas es el mismo que se utiliza en el Campus Virtual.

La pr´actica se puede entregar varias veces, pero s´olo se corregir´a la ´

(2)

2. El programa debe poder ser compilado sin errores con el compilador de C++ existente en la distribuci´on de Linux de los laboratorios de pr´acticas; si la pr´actica no se puede compilar su calificaci´on ser´a 0. Se recomienda compilar y probar la pr´actica con el autocorrector inmediatamente antes de entregarla.

3. La correcci´on de la pr´actica se har´a de forma autom´atica, por lo que es imprescindible respetar estrictamente los textos y los formatos de salida que se indican en este enunciado.

4. Al principio de todos los ficheros fuente entregados se debe incluir un comentario con el nombre y el NIF (o equivalente) de la persona que entrega la pr´actica, como en el siguiente ejemplo:

// NIF 12345678X GARCIA GARCIA, JUAN MANUEL

5. El c´alculo de la nota de la pr´actica y su influencia en la nota final de la asignatura se detallan en las transparencias de la presentaci´on de la asignatura.

2.

Introducci´

on

Esta pr´actica consiste en realizar un programa para ayudar al comandante de un destructor imperial a gestionar la flota de cazas imperiales del destructor en el transcurso de una batalla con una nave rebelde de similares caracter´ısticas. Podr´a a˜nadir m´as cazas, reparar y mejorar las caracter´ısticas de los cazas, y lanzar un caza a luchar contra un caza rebelde. En posteriores pr´acticas se a˜nadir´an m´as funcionalidades a este programa.

2.1.

Caracter´ısticas de los cazas espaciales

Tanto los cazas imperiales como los rebeldes tienen las siguientes caracter´ısti-cas:

velocidad (velocity) : la velocidad m´axima del caza ataque (attack ) : poder de ataque sobre otras naves escudo (shield ) : poder defensivo de los campos deflectores coste (cost ) : coste en cr´editos del caza

Los cazas imperiales, junto con los valores de sus caracter´ısticas son:

Tipo Abreviatura Velocity Attack Shield Cost TIE-Fighter tf 150 75 30 45 TIE-Bomber tb 80 150 45 75 TIE-Interceptor ti 180 65 30 55 TIE-Advanced ta 160 80 90 95

Los cazas rebeldes son:

Tipo Abreviatura Velocity Attack Shield Cost X-Wing xw 175 90 75 65 Y-Wing yw 90 150 90 90 A-Wing aw 200 60 50 45 B-Wing bw 120 200 90 100

(3)

co-3 FUNCIONAMIENTO DEL PROGRAMA 3

mandante dispone inicialmente de 2000 cr´editos en la caja fuerte del destructor para comprar cazas, o bien para reparar y mejorar los cazas disponibles. El pro-grama debe almacenar tambi´en el n´umero de victorias y derrotas del destructor en los combates que se produzcan. Cuando un caza imperial destruya al caza rebelde oponente, el Emperador recompensar´a autom´aticamente al comandante con el coste del caza rebelde destruido, que incrementar´a la cantidad de cr´editos disponible en la caja fuerte del destructor. La Alianza Rebelde recompensar´a de la misma manera al comandante de la nave rebelde enemiga.

3.

Funcionamiento del programa

Inicialmente, el programa debe crear e inicializar dos naves, el destructor imperial que gestionar´a el usuario, y una nave rebelde que gestionar´a el propio programa. En la secci´on de implementaci´on se describe con m´as detalle los datos de cada nave:

ambas naves partir´an de la misma cantidad de cr´editos inicial, 2000 cr´ edi-tos, para comprar su dotaci´on inicial de cazas, comprar m´as cazas, y para mejorarlos.

cada una tendr´a diferente capacidad seg´un sea una nave imperial o una nave rebelde.

Cada nave tendr´a inicialmente una dotaci´on de cazas que deben a˜nadirse (en el orden que se indica) al crear la nave. El destructor imperial tendr´a 10 TIE-Fighters, 5 TIE-Bombers, 5 TIE-Interceptors y 5 TIE-Advanced. La nave rebelde tendr´a 10 X-Wing, 5 Y-Wing, 8 A-Wing y 5 B-Wing (v´ease la secci´on de implementaci´on para m´as detalles acerca de c´omo inicializar la dotaci´on de cazas).

Una vez creadas las naves e inicializadas (incluyendo las dotaciones de cazas iniciales), el programa debe mostrar el siguiente men´u:

1- List ship info 2- Add fighters

3- Repair/improve fighter 4- Launch fighter

5- List enemy info q- Quit

Option:

La opci´on ser´a siempre un ´unico car´acter, no es necesario comprobarlo (aun-que ir´a seguido de un car´acter de fin de l´ınea). Si el usuario introduce una op-ci´on incorrecta, el programa debe mostrar el mensaje de error UNKNOWN_OPTION (v´ease la secci´on de implementaci´on para m´as detalles sobre los mensajes de error). Si el usuario elige la opci´on Quit, el programa terminar´a sin emitir ning´un mensaje.

Despu´es de ejecutar alguna de las opciones (que pueden ir bien o generar alg´un error), el programa volver´a a mostrar el men´u.

3.1.

Descripci´

on de las opciones

List ship info/List enemy info : en ambas opciones se debe mostrar la in-formaci´on de la nave correspondiente por pantalla (utilizando exactamente

(4)

la misma funci´on). Por ejemplo, al comenzar el programa la informaci´on del destructor imperial debe ser:1

Ship info: max. capacity=30, side=IMPERIAL, credits=425, wins=0, losses=0 [1] TIE-Fighter (v=150, a=75, s=30, c=45)

[2] TIE-Fighter (v=150, a=75, s=30, c=45) ...

[25] TIE-Advanced (v=160, a=80, s=90, c=95)

En el caso del jugador rebelde, la cadena a mostrar despu´es de “side=” ser´a “REBEL”.

Add fighters : en esta opci´on se a˜nadir´an uno o m´as cazas del mismo tipo al destructor imperial. Para ello, se debe pedir el tipo de caza, mostrando el siguiente mensaje:

Enter fighter type (tf/tb/ti/ta):

A continuaci´on, si el tipo introducido por el usuario (una cadena) coincide con la abreviatura de alguno de los cazas definidos en la tabla de datos de cazas y es un caza imperial (en otro caso se mostrar´a por pantalla el mensaje de error WRONG_FIGHTER_TYPE y saldr´a de la funci´on, volviendo al men´u), entonces se pedir´a el n´umero de cazas mostrando el siguiente mensaje:

Number of fighters:

Si el coste de los nuevos cazas es mayor que el n´umero de cr´editos disponi-ble en la caja fuerte de la nave, se mostrar´a el mensaje de error NO_FUNDS. Si los nuevos cazas caben en la nave (en otro caso se mostrar´a el error CAPACITY_EXCEEDED), se a˜nadir´an al final del vector de cazas de la nave, y se descontar´a su coste de los cr´editos de la caja fuerte.

Repair/improve fighters : esta opci´on permite al comandante mejorar o re-parar alguna de las caracter´ısticas de un caza. Para ello, se pedir´a el n´ ume-ro de caza a reparar o mejorar con el siguiente mensaje:

Select fighter number:

Si el n´umero de caza es incorrecto se mostrar´a el error WRONG_NUMBER; si es correcto, se pedir´a el aspecto a mejorar o reparar con el siguiente mensaje:

What to improve (v/a/s)?

Se leer´a la opci´on elegida (un car´acter, seguido de un car´acter de re-torno de carro), y, si es correcta (en caso contrario se emitir´a el error UNKNOWN_OPTION y se saldr´a de la funci´on, volviendo a continuaci´on al men´u), se pedir´a la cantidad en que se quiere aumentar ese aspecto me-diante el mensaje:

1Por brevedad, solamente se muestran los 2 primeros cazas y el ´ultimo, pero la pr´actica

(5)

3 FUNCIONAMIENTO DEL PROGRAMA 5

Amount:

Una vez le´ıda la cantidad c (se puede asumir que c ser´a mayor o igual que cero, no es necesario comprobarlo), se calcular´a el coste de dicha mejora, que ser´a:

velocidad 2*c (2 cr´editos por unidad) ataque 3*c (3 cr´editos por unidad)

escudo (c+1)/2 (1 cr´edito por 2 unidades, redondeo al alza) El coste de la mejora del escudo se redondea al alza porque en caso con-trario las cantidades impares costar´ıan lo mismo que la cantidad par in-mediatamente inferior. En la implementaci´on, la divisi´on debe ser entera (si los dos operandos son enteros, la divisi´on ser´a entera).

Si el coste no es mayor que los cr´editos disponibles en la caja fuerte de la nave (en otro caso se mostrar´a el error NO_FUNDS y se saldr´a de la funci´on), se mostrar´a el siguiente mensaje, y se pedir´a confirmaci´on:

That will cost you <cost> credits. Confirm? (y/n)

donde <cost> es el coste de la mejora. Si el usuario introduce el car´acter “y”, se realizar´a la mejora en el caza, se incrementar´a el coste del caza, se restar´a el coste de los cr´editos de la caja fuerte, y se mostrar´a un mensaje como el del siguiente ejemplo (en el que se ha aumentado 20 unidades la velocidad de un TIE-Fighter):

Fighter improved: TIE-Fighter (v=170, a=75, s=30, c=85)

Si se introduce cualquier otro car´acter (incluso “Y” o “s”) en la pregunta de confirmaci´on, se entender´a que no se ha confirmado y por tanto no se realizar´a la mejora, y se saldr´a de la funci´on y se volver´a al men´u principal sin mostrar ning´un mensaje.

Launch fighter : en esta opci´on el comandante de la nave elige un caza de los que tiene disponibles en la nave y lo env´ıa a combatir con otro caza de la nave enemiga.

Antes de empezar el combate, se debe comprobar que ambas naves, la imperial y la rebelde, tienen al menos un caza. Si no es as´ı, se emitir´a el error NO_FIGHTERS y se volver´a al men´u.

Una vez hecha esta comprobaci´on, lo primero que se debe hacer es selec-cionar el caza, mostrando el siguiente mensaje:

Select fighter number:

Si el n´umero del caza es correcto (en caso contrario se emitir´a el error WRONG_NUMBER y se saldr´a de la funci´on, volviendo al men´u), se almace-nar´a en una variable el caza elegido y se eliminar´a del vector de cazas. A continuaci´on, se elegir´a aleatoriamente un caza enemigo (generando un n´umero al azar entre 0 y el n´umero de cazas enemigos menos 1), y se elimi-nar´a tambi´en del vector de cazas de la nave enemiga, y comenzar´a la lucha

(6)

entre los dos cazas. Antes de comenzar el combate se debe mostrar los dos cazas, con el mismo formato que en las opciones de 1 y 5 del men´u (pero sin el n´umero de caza), y al terminar tambi´en.

El combate entre los dos cazas (el primero imperial y el segundo rebelde) se simula de la siguiente manera:

1. Se genera un n´umero aleatorio n entre 0 y 99, 0 ≤ n ≤ 99

2. Si n es menor que 5 o mayor que 95, el combate termina (se simula que han intervenido otros cazas, o se ha alcanzado un campo de asteroides, o que alguno de los cazas se retira).

3. Se calcula qu´e caza acierta en su ataque al caza contrario, obteniendo un umbral u, que se calcula de la siguiente manera:

u = 100v1 v1+ v2

donde v1 es la velocidad del primer caza, y v2la del segundo. Si n es menor o igual que el umbral u, se supone que el caza que ha acertado es el primero (el caza imperial), en caso contrario el caza que ha acertado es el segundo.

4. Se calcula el da˜no d ocasionado al caza contrario, que se restar´a di-rectamente de su escudo. La f´ormula para calcular el da˜no es:

d = (na1)/f si n ≤ u

((100 − n)a2)/f si n > u

donde a1 es el ataque del primer caza, y a2 el del segundo. El valor f es una constante de valor 300.

5. Si el escudo de alguno de los cazas es 0 o negativo, el combate termina, y se considera que dicho caza ha sido destruido. Solamente puede resultar destruido uno de los dos cazas, no pueden destruirse los dos en el mismo combate.

6. Si ambos cazas tienen todav´ıa un valor positivo en su escudo, el combate continua volviendo al paso 1.

Por ejemplo, si al principio del programa se lanza el primer caza imperial de la nave (un TIE Fighter), la salida por pantalla deber´ıa ser:

-- begin fight TIE-Fighter (v=150, a=75, s=30, c=45) B-Wing (v=120, a=200, s=90, c=100) --TIE-Fighter (v=150, a=75, s=-4, c=45) B-Wing (v=120, a=200, s=81, c=100) -- end fight

Cuando termine el combate, se actualizar´an los datos de cr´editos (se su-mar´a a cada nave el coste de los cazas enemigos destruidos), victorias y derrotas de las dos naves, y se devolver´an los cazas supervivientes (pue-de ser uno o los dos) a su nave, a˜nadi´endose al final del vector de cazas correspondiente.

(7)

4 IMPLEMENTACI ´ON 7

4.

Implementaci´

on

Para implementar la pr´actica debes tener en cuenta las siguientes observa-ciones:

1. En la web de la asignatura se publicar´an varios ficheros:

imperialCommander.cc : debes basarte en este fichero para realizar tu pr´actica. Puedes a˜nadir m´as funciones y constantes si lo consideras necesario. Este fichero contiene lo siguiente:

a) Tipos definidos que es necesario utilizar, entre los que est´an los registros (struct) para los cazas (Fighter) y la nave (Ship). b) La tabla de datos de cazas (4 imperiales y 4 rebeldes), y las

abreviaturas de los tipos de caza (que se utilizar´an en la opci´on Add fighter).

c) Constantes de las naves como la capacidad de cada nave, y las dotaciones iniciales de cazas; en estos vectores se indica cu´antos cazas de la tabla tiene cada nave.

d ) Constantes y una funci´on para emitir mensajes de error. e) Una funci´on para generar n´umeros aleatorios (que no debes

mo-dificar).

f ) Los prototipos de las funciones que se debe implementar2. g) Una funci´on main que debes completar.

autocoP2p1.tgz : autocorrector para probar la pr´actica con algunas prue-bas. La correcci´on autom´atica de la pr´actica se realizar´a con un co-rrector similar.

2. La generaci´on de n´umeros pseudo-aleatorios se realiza usando las fun-ciones est´andar de C/C++ rand (para generar n´umeros) y srand (para establecer la semilla). Aunque se ha probado en varias versiones de Linux, es posible que en otros sistemas (especialmente en Windows) no funcio-ne exactamente de la misma mafuncio-nera, es decir, no se gefuncio-nere exactamente la misma secuencia de n´umeros aleatorios, por lo que los autocorrectores podr´ıan fallar. Por tanto, es recomendable desarrollar la pr´actica en Linux (preferiblemente en la distribuci´on usada en los laboratorios), y se debe probar con el autocorrector en las m´aquinas de los laboratorios antes de entregarla.

3. Las funciones que se debe implementar son (est´an incluidas en el fichero imperialCommander.cc):

void initializeShip(Ship &ship,bool side); // Inicializa los datos de la nave

void listFighter(const Fighter &f); // Muestra los datos de un caza

void listFighters(const vector<Fighter> &vf);

2Seguramente necesitar´as implementar alguna funci´on adicional para que el c´odigo sea m´as

(8)

// Muestra un vector de cazas

void listShip(const Ship &ship);

// Muestra los datos de una nave y de sus cazas

bool addFighter(Ship &ship);

// A~nade uno o m´as cazas a la nave. Devuelve true si los ha a~nadido

bool improveFighter(Ship &ship);

// Mejora o repara un caza. Devuelve \texttt{true} si lo ha mejorado o reparado

int fight(Fighter &fg1,Fighter &fg2);

// Simula un combate entre dos cazas. Devuelve -1 si gana el primero, 1 si gana el // segundo, 0 si hay empate

void launchFighter(Ship &imperial,Ship &rebel);

// Simula el combate entre un caza imperial y uno rebelde

4. En la correcci´on de la pr´actica se introducir´an datos del tipo correcto siempre, aunque con valores que pueden ser incorrectos. Por ejemplo, si se pide el n´umero de cazas, se introducir´a siempre un valor entero, que podr´ıa ser -1237 o 0, pero nunca se introducir´a un valor de otro tipo (car´acter, string o n´umero real).

5. El resto de decisiones en la implementaci´on de la pr´actica quedan a tu criterio, pero ten en cuenta que el c´odigo fuente de la pr´actica ser´a revisado por tu profesor de pr´acticas siguiendo la gu´ıa de estilo publicada en la web de la asignatura, y parte de la nota de la pr´actica depende de dicha revisi´on. Ten en cuenta especialmente estas recomendaciones:3

El sangrado del c´odigo debe ser adecuado, siguiendo uno de los estilos recomendados en la gu´ıa de estilo. Usa 2 o 3 espacios en vez de tabuladores.

Los ficheros fuente deben estar adecuadamente documentados, con comentarios donde se considere necesario, en aquellos puntos del c´ odi-go que sean m´as oscuros (pero sin poner comentarios obvios).4 En Programaci´on 2 no se pueden utilizar variables globales de nin-guna clase, los ´unicos s´ımbolos globales permitidos son las funciones, los tipos definidos por el programador y las constantes. Tampoco se permite usar break para salir de bucles, ni usar return para salir de funciones en mitad del c´odigo.5

Los nombres de constantes, variables y funciones deben ser adecua-dos, y deben informar sobre su contenido.

Las funciones deben tener un tama˜no adecuado; si una funci´on es demasiado grande (p.ej. no cabe en una pantalla normal), proba-blemente se deber´ıa dividir en dos o m´as funciones. Nunca se debe duplicar (copy/paste) c´odigo.

3Recuerda una cita famosa de John Woods: Always code as if the guy who ends up

main-taining your code will be a violent psychopath who knows where you live.

4Muchos programadores consideran que los comentarios no deber´ıan existir, si el c´odigo

est´a bien escrito no es necesario poner comentarios.

5El objetivo de estas normas es afianzar el aprendizaje, en asignaturas de cursos superiores

Referencias

Documento similar

[r]

Luis Miguel Utrera Navarrete ha presentado la relación de Bienes y Actividades siguientes para la legislatura de 2015-2019, según constan inscritos en el

Tras establecer un programa de trabajo (en el que se fijaban pre- visiones para las reuniones que se pretendían celebrar los posteriores 10 de julio —actual papel de los

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Habiendo organizado un movimiento revolucionario en Valencia a principios de 1929 y persistido en las reuniones conspirativo-constitucionalistas desde entonces —cierto que a aquellas

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de

 Para recibir todos los números de referencia en un solo correo electrónico, es necesario que las solicitudes estén cumplimentadas y sean todos los datos válidos, incluido el