Universidad de Costa RicaFacultad de Ingenierıa

Escuela de Ingenierıa Electrica

Modelado en SystemC de un sistema

computador centrado en CPUCR.

Por:

Edgar Fabian Melendez Bolanos

Ciudad Universitaria “Rodrigo Facio”, Costa Rica

Diciembre 2015

Modelado en SystemC de un sistema

computador centrado en CPUCR.

Por:

Edgar Fabian Melendez Bolanos

IE-0499 Proyecto electrico

Aprobado por el Tribunal:

Phd. Lochi Yu LoProfesor guıa

Msc. Teodoro Willink Castro Ing. Diego Valverde GarroProfesor lector Profesor lector

ResumenEste proyecto es parte del desarrollo del videojuego TankBattles, el cual es unvideojuego programado utilizando el lenguaje ensamblador de la arquitecturaCPUCR. El juego consiste en una batalla entre taques, cada tanque contieneun sistema computador que ejecuta un algoritmo programado en el lenguajeensamblador y mediante los puertos de entrada y salida controla dicho tanque.

El videojuego propuesto se espera que sea utilizado en el curso de Estruc-turas de Computadores Digitales I, como parte del proyecto final del curso;en busca del rescate de la arquitectura de computador CPUCR de disenocostarricense que se ha dejado de utilizar en dicho curso.

Se inicio por definir el videojuego, y declarar el modelo de programacionque seguiran los usuarios finales. Ademas se diseno la arquitectura de softwareque debe seguir el desarrollo del videojuego, y se implementaron las clasesnecesarias para contener la logica del juego. Asimismo se plantearon los requi-sitos para el modelo de hardware de la CPUCR (el cual sera en SystemC) ypara la interfaz grafica de usuario.

v

Indice general

Indice de figuras ix

Indice de cuadros x

Nomenclatura xi

1 Introduccion 11.1 Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Marco Teorico 52.1 Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . 52.2 CPUCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Modelo Vista Controlador . . . . . . . . . . . . . . . . . . . . . 62.5 Droidbattles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 SystemC: temporizacion y sincronizacion 93.1 Sincronizacion por tiempo en SystemC . . . . . . . . . . . . . . 93.2 Sincronizacion por eventos en SystemC . . . . . . . . . . . . . . 10

4 Diseno del Juego 134.1 Descripcion y funcionamiento del hardware del Tanque . . . . . 144.2 Modelo de Programacion . . . . . . . . . . . . . . . . . . . . . . 17

5 Arquitectura de Software 215.1 Capa de interfaz grafica de usuario . . . . . . . . . . . . . . . . 215.2 Capa de logica del juego . . . . . . . . . . . . . . . . . . . . . . 225.3 Capa de arquitectura de hardware . . . . . . . . . . . . . . . . 23

6 Capa de Arquitectura de Hardware 256.1 CPUCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Capa de Logica del Juego 297.1 Clase TankBot . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

7.2 Clase TankBattle . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8 Capa de la Interfaz Grafica de Usuario (GUI) 358.1 Configuracion del hardware del tanque . . . . . . . . . . . . . . 358.2 Flujo del programa . . . . . . . . . . . . . . . . . . . . . . . . . 368.3 Sprite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9 Resultados 399.1 Menus de configuracion . . . . . . . . . . . . . . . . . . . . . . 399.2 Arena de Batalla y Sprites . . . . . . . . . . . . . . . . . . . . . 40

10 Conclusiones y Recomendaciones 4510.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4510.2 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliografıa 47

viii

Indice de figuras

2.1 Esquema de arquitectura de la CPUCR . . . . . . . . . . . . . . . 6

2.2 Esquema de arquitectura modelo-vista-controlador . . . . . . . . . 7

4.1 DroidBattles, pantalla principal. . . . . . . . . . . . . . . . . . . . 13

4.2 DroidBattles, ejemplo de batalla. . . . . . . . . . . . . . . . . . . . 14

4.3 DroidBattles, ejemplo de battalla. . . . . . . . . . . . . . . . . . . 15

4.4 Ejemplo del uso del Scanner. . . . . . . . . . . . . . . . . . . . . . 17

4.5 Porcentaje de vida incial de acuerdo con el Armor configurado. . . 17

5.1 Diagrama de capas de abstraccion de software. . . . . . . . . . . . 21

6.1 Diagrama UML del modulo CPUCR. . . . . . . . . . . . . . . . . . 26

6.2 Dinamica de los puertos de la CPUCR. . . . . . . . . . . . . . . . 27

6.3 Diagrama UML del modulo Synchronizer. . . . . . . . . . . . . . . 27

6.4 Diagrama del modulo Synchronizer. . . . . . . . . . . . . . . . . . 28

7.1 Diagrama general de la capa de logica de juego. . . . . . . . . . . . 30

7.2 Diagrama UML de las clases implementadas. . . . . . . . . . . . . 31

7.3 Diagrama UML de la clase TankBot. . . . . . . . . . . . . . . . . . 32

7.4 Diagrama de la clase TankBot. . . . . . . . . . . . . . . . . . . . . 32

7.5 Diagrama UML del struct BotStatus. . . . . . . . . . . . . . . . . 33

7.6 Diagrama UML del struct BotHardware. . . . . . . . . . . . . . . . 33

7.7 Diagrama UML de la clase TankBattle. . . . . . . . . . . . . . . . 34

7.8 Diagrama de la clase TankBattle. . . . . . . . . . . . . . . . . . . . 34

8.1 Flujo de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.2 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.1 Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9.2 Menu creador de tanques . . . . . . . . . . . . . . . . . . . . . . . 40

9.3 Menu editor de configuracion . . . . . . . . . . . . . . . . . . . . . 41

9.4 Menu inicio de juego . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.5 Sprite Batttle - Scoreboard. . . . . . . . . . . . . . . . . . . . . . . 42

9.6 Sprite tanque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.7 Sprite bullet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ix

Indice de cuadros

4.1 Funciones de los puertos de salida. . . . . . . . . . . . . . . . . . . 184.2 Funciones de los puertos de entrada. . . . . . . . . . . . . . . . . . 19

x

Nomenclatura

API Application Programming Interface.

SystemC librerıa de C++ para el modelado de circuitos.

MVC Model View Controller.

TDF Timed Data Flow.

MOC Model Of Computing.

GUI Graphical User Interface.

IDE Integrated Development Environment.

MIPS Microprocessor without Interlocked Pipeline Stages.

RISC Reduced Instruction Set Computing.

CISC Complex Instruction Set Computing.

XML eXtensive Markup Language.

xi

1 Introduccion

Por muchos anos en la Escuela de Ingenierıa Electrica se utilizo una arquitec-tura de computador disenada por Randolph Steinvorth y Marco Vasquez, laCPUCR. Esta arquitectura ha sido utilizada como tema principal de muchosproyectos de graduacion y como recurso didactico en el curso de estructurasde computadores. La CPUCR es una muestra de la ingenierıa costarricense yen especial de la Escuela de Ingenierıa Electrica.

En los anos mas recientes, en el curso de Estructuras de ComputadorasDigitales I, se ha propuesto un proyecto final innovador, los estudiantes jueganDroidBattles. El juego consiste a un programa que simula a un robot. Esteprograma corre sobre una plataforma de hardware emulada similar a un pro-cesador Intel x86. Con el proposito de derrotar a sus rivales en una batalla,los jugadores cuentan con un presupuesto para agregar distintos equipamien-tos a sus robots, para estos sean mas competitivos. El jugador que tenga unmejor manejo de su hardware, por medio de codigo ensamblador, derrota-ra a sus rivales. El juego DroidBattles fue disenado por Andreas Agorander(Bluefire). Se puede descargar el juego y la documentacion oficial del sitio:http://www.bluefire.nu/droidbattles/.

La CPUCR se utilizo por muchos anos como herramienta didactica en elcurso Estructuras de Computadoras Digitales I con el proposito de que losestudiantes aprendan acerca de la arquitectura y el funcionamiento de unprocesador tipo Reduced Instruction Set Computer (RISC, siglas en ingles deComputador de Conjunto Reducido de Instrucciones).

En la actualidad, por la necesidad de que los estudiantes aprendan unaarquitectura globalmente conocida y utilizada, se ha dejado de utilizar laCPUCR y esta se ha cambiado por la arquitectura MIPS. El conocimientode la misma es de interes para empresas transnacionales, y va a mejorar elbagaje tecnico de los egresados de la Escuela de Ingenierıa Electrica.

Este proyecto viene al rescate de la CPUCR como medio didactico, y ade-mas a impulsar estrategias de aprendizaje diferentes, que inspiren y emocionena los estudiantes. Es por esto que se plantea crear un videojuego desarrolladocompletamente por estudiantes de la escuela, que emule el juego planteadopor Droidbattles, en donde los estudiantes jueguen programando en lenguajede ensamblador, pero de la CPUCR.

Se espera que el videojuego TankBattles desarrollado a partir de este pro-yecto, se utilice en el curso de Estructuras de Computadores, como sustituto de

1

2 1 Introduccion

Droidbattles en el proyecto final. Ademas se busca permitir a los estudiantesinvolucrados en su desarrollo, dejar una huella en la escuela.

1.1 Alcance del proyecto

Para este proyecto se desarrollo todo el nucleo del videojuego TankBattles. Sedesarrollo un API (interfaz de programacion de aplicaciones) con una serie declases y atributos desarrollados en C++ y SystemC. El proyecto del videojuegoTankBattles adicionalmente requirio la integracion de una interfaz grafica, asıcomo un modelo completo de la arquitectura CPUCR.

Se especificaron las reglas del juego para TankBattles, desde los recursosdisponibles en hardware (entiendase dispositivos como armas, radar, motor,etc) y el modelo de programacion para poder utilizar el hardware disponible.De esta forma el jugador tiene las reglas para programar su algoritmo enensamblador de la CPUCR. Para esto se definio cuales puertos se utilizan, sufuncion, y la forma de interpretarlos para crear acciones en el tanque comocambiar de direccion, modificar la velocidad, escanear enemigos, y disparar.

Se diseno desde cero la arquitectura del software, definiendo tres nivelesde abstraccion: modelo de hardware, logica del juego e interfaz grafica. Paracada uno de estos niveles de abstraccion se identificaron los problemas quedeben resolver. Para el nivel de la logica del juego se establecieron las clasesa utilizar junto con sus atributos.

El nivel de logica del juego se implemento desarrollando las estructurasde datos necesarias, las clases, los atributos y los metodos especifiados enla arquitectura de software. Ademas se desarrollo la interfaz con la capa delmodelo de hardware y con la capa de la interfaz grafica de usuario.

Para este proyecto no es de interes desarrollar un modelo completo de laCPUCR, por lo que se creo un modelo que simula las escrituras y lecturasde los puertos, que engloba todo el sistema computador (incluyendo memoria,microcontrolador, puertos, etc). El modelo permite el desarrollo de algorit-mos simples para visualizar y probar, las clases y atributos desarrollados. Sinembargo se definieron los requisitos que debe tener el modelo completo de laCPUCR para que sea compatible con este proyecto.

Para la capa de interfaz grafica, se delimitaron los requisitos y las funcionesa realizar en el nivel grafico del juego, y ademas se especifico la forma en quese debe implementar la interfaz entre la logica del juego, sus estructuras dedatos y la interfaz de usuario. No se contemplo el desarrollo de la interfazgrafica del juego.

1.2. Objetivos 3

1.2 Objetivos

Objetivo General

Desarrollar una plataforma de simulacion de multiples procesadores CPUCRen forma grafica.

Objetivos especıficos

• Desarrollar las reglas del juego y el modelo de programacion para eljuego TankBattles.

• Establecer los requisitos de un modelo de la CPUCR para utilizarse enel videojuego.

• Desarrollar un entorno de simulacion para varias CPUCR corriendo si-multaneamente.

• Disenar la arquitectura de software que se utilizara en el videojuegoTankBattles.

• Desarrollar las clases y atributos necesarios para implementar la logicadel juego planteado.

• Establecer los requerimientos de la interfaz grafica.

1.3 Metodologıa

Se dividio la metodologıa a utilizar en tres partes, con fin de estructurar eltrabajo a realizar pero no limitarlo a tareas que aun no pod ser definidas. Elproyecto paso por las siguientes etapas:

• Investigacion: Se realizaron pruebas de concepto para definir la arqui-tectura que tendra el software. Esto con tal de seleccionar la mejor formade estructurar el desarrollo del videojuego, y definir asimismo como serealizara el manejo de tiempos para la simulacion en paralelo de variasCPUCR.

• Diseno: Se diseno el videojuego, definiendo el hardware disponible, esdecir los tipos de armas, motores, escudos, y demas atributos que seimplementaron para el videojuego. Se definio tambien el modelo de pro-gramacion, declarando cuales puertos se requieren en la programacion ysu funcion para que el jugador realice acciones o reciba informacion dela partida. Ademas se diseno la arquitectura de software que seguira elproyecto.

4 1 Introduccion

• Implementacion Clases: Se implementaron las clases y la logica deljuego. Esto a nivel de C++ y SystemC. Se crearon las pruebas nece-sarias para validar las clases y su funcionamiento.

2 Marco Teorico

2.1 Arquitectura de Software

La arquitectura de software es el diseno de mas alto nivel de la estructurade un sistema. Es el proceso de definir una solucion estructurada que complatodos los requisitos tecnicos y operacionales, mientra optimiza atributos decalidad como desempeno, seguridad, y manejabilidad. Garlan y Shaw [2003]

Se define como la organizacion fundamental de un sistema incorporado ensus componentes, las relaciones entre ellos y el ambiente, y los principios queguıan su diseno y evolucion. Eeles [2006].

Esta se selecciona y disena con base en objetivos (requerimientos) y restric-ciones. Los objetivos son aquellos prefijados para el sistema de informacion,tanto funcionalmente como para la mantenibilidad, auditabilidad, flexibilidade interaccion con otros sistemas de informacion. Las restricciones son aquellaslimitaciones derivadas de las tecnologıas disponibles para implementar siste-mas de informacion. Wilson [1999]

2.2 CPUCR

La CPUCR en sı es una unidad central de procesamiento, que utiliza unamemoria de 4096 posiciones de 6 bits cada una. Visto desde afuera, como esde interes en este proyecto, la CPUCR se tomara como un microcontroladorque cuenta con 64 puertos de entrada y salida de 6 bits cada uno. Estos sonde especial interes, ya que se utilizaran para modificar el comportamiento decada jugador. Pacheco y Cubero [2005].

En la figura 2.1 se observa un diagrama de bloques de la arquitectura dela CPUCR, como microcontrolador.

2.3 SystemC

SystemC es una librerıa de C++ con standard ANSI. Es utilizado por ar-quitectos y disenadores para el diseno de hardware y sistemas, en los quese necesita manejar sistemas complejos que son un hıbrido entre hardware ysoftware. [IEEE, 2011]

Esta librerıa permite crear modelos precisos de disenos a nivel de sistema,incluyendo algoritmos de software, arquitecturas de hardware, y sus interfaces;

5

6 2 Marco Teorico

Figura 2.1: Esquema de arquitectura de la CPUCR

transformando ası C++ en un lenguaje de diseno a nivel de sistema (SLDL).Los disenadores crean una especificacion ejecutable que es un programa enC++ que exhibe el mismo comportamiento que el sistema estudiado, permi-tiendo su simulacion, validacion, y optimizacion. Banerjee y Sur [2013]

Con el paso del tiempo, la industria de la electronica ha construido siste-mas mas complejos con muchos componentes que incluyen software, se necesitaun lenguaje que modele la complejidad y el tamano de estos sistemas. Sys-temC tiene la capacidad de manejar esta complejidad, con su facilidad demodelar hardware y software juntos en distintos niveles de abstraccion. Estacaracterıstica no se puede lograr en los lenguajes de descripcion de hardwaretradicionales. IEEE [2011]

Algunos mercados que utilizan la librerıa SystemC son: automatizacion deldiseno electrico (EDA, por sus siglas en ingles), circuitos integrados, prove-dores que utilizan SystemC para modelar su propiedad intelectual y usuariosfinales que lo usan en sus productos. IEEE [2011]

SystemC provee tres construcciones que C++ no contiene: tiempo, con-currencia y comportamiento reactivo. Todos cruciales en la descripcion dehardware. Banerjee y Sur [2013] .

2.4 Modelo Vista Controlador

“En el software de juegos es importante separar los componentes graficos de lalogica del juego, para facilitar la transicion a nuevas tecnologıas o diferentes

2.4. Modelo Vista Controlador 7

plataformas. El patron arquitectonico Modelo-Vista-Controlador (MVC) escomunmente utilizado para lograr tal separacion” Olsson et al. [2015]

El MVC un patron de arquitectura de software que separa los datos y lalogica de negocio de una aplicacion de la interfaz de usuario y el modulo en-cargado de gestionar los eventos y las comunicaciones. Para ello MVC proponela construccion de tres componentes distintos que son el modelo, la vista y elcontrolador. Garlan y Shaw [2003]

El modelo es la representacion de la informacion con la que se esta traba-jando, y gestiona todos los accesos a dicha informacion, tanto consultas comoactualizaciones, Reenskaug [1979]

La vista es la representacion visual del modelo, no se despliega toda lainformacion, solo la relevante. La vista esta conectada al modelo, recibe yenvıa informacion al mismo. Reenskaug [1979]

El controlador responde a eventos (que pueden ser acciones del usuario) einvoca peticiones al ’modelo’ cuando se hace alguna solicitud sobre la infor-macion. Tambien puede enviar comandos a su ’vista’ asociada si se solicita uncambio en la forma en que se presenta el ’modelo’. Reenskaug [1979]

La vista no debe conectarse nunca directamente con el usuario, ni debesaber de la operacion de dispositivos como el teclado o el mouse. Reenskaug[1979]

Figura 2.2: Esquema de arquitectura modelo-vista-controlador

8 2 Marco Teorico

2.5 Droidbattles

El juego programable DroidBattles fue disenado inicialmente para ejecutarseen un ambiente Linux/UNIX, sin embargo, tambien puede hacerse en Win-dows. El jugador disena y programa el bot, en un lenguaje similar al ensam-blador. El objetivo es crear un bot con determinado hardware y software quesea mejor que los demas, manteniendo la restriccion de presupuesto. Luego,se ejecutan los bots en una simulacion de batalla, donde compiten y el mejordestruye a su oponente. Agorander [2002]

3 SystemC: temporizacion ysincronizacion

Se realizo una prueba de concepto para identificar la mejor manera de sincroni-zar los modulos de SystemC (que consistiran en CPUCRs). Esto debido a quese utilizaran threads que ejecutaran el codigo ensamblador de cada CPUCR,pero el juego debe ser paralelo para todos los jugadores y se debe tener unciclo de juego, en donde todas las CPUCRs corran a la misma frecuencia losalgoritmos de cada jugador.

Para esto se programo un modulo de contador muy sencillo en SystemCy se instanciaron varios, de forma que se probara la sincronizacion de losdiferentes contadores. Ademas se evaluaron las ventajas y desventajas quetenıa cada forma de sincronizacion.

SystemC basa su manejo de tiempos en un modelo TDF (Timed DataFlow), el cual consiste en un modelo de computacion (MOC-Model OfComputing) basado en el flujo sincronico de datos. En SystemC los datos sonconceptualizados como senales muestreadas en el tiempo, y llevan informacioncontinua o discreta. Una etiqueta de tiempo, llamada time step (intervalo detiempo), esta asociada a cada elemento de datos. Banerjee y Sur [2013]

De esta forma se pueden definir time steps para los modulos y sus puertos,se puede especificar tasas de datos (frecuencia con que son leıdos, etc), retardosy desfases de tiempos para los puertos o datos.

SystemC utiliza un scheduler (planificador), el cual permite ejecutar pro-cesos, sincroniza todos los cambios de senales (que a su vez pueden generarmas cambios de senales) y controla el flujo de ejecucion de los modulos. Elscheduler ejecuta partes del codigo, que cumplan entre otras condiciones quese incluyan eventos en la lista de sensibilidad o que ocurra un timeout. Mulleret al. [2003]

De esta manera surgen dos formas de sincronizar o controlar el flujo deejecucion en SystemC, una de ellas es por medio del tiempo, y la otra consisteen una programacion por eventos, y ambas fueron puestas a prueba.

3.1 Sincronizacion por tiempo en SystemC

Se puso a prueba el uso de retardos para sincronizar las CPUCRs, lo intere-sante de esta forma de sincronizacion es que permite hacerlo de manera tacita,es decir cuando las instancias de modulos encuentran un retardo este actua

9

10 3 SystemC: temporizacion y sincronizacion

como una barrera, de forma que el retardo no se produce hasta que todas lasinstancias hayan llegado al retardo.

Una vez que todas las instancias terminan de ejecutar el codigo, se produceel retardo corriendo un tiempo sintetico generado por SystemC. Por lo que laposicion en el codigo del retardo influye mucho, y ademas se necesita tener unsc main (main de SystemC) que inicialice el tiempo y haga que este ’corra’para poder llevar un estructura de tiempo y que los modulos puedan bajo esaestructura ordenar sus retardos.

Este metodo se mostro efectivo para sincronizar varios modulos al mismotiempo, pero se tiene poco control externo de cuando se ejecuta el codigoexactamente. En caso de que se implementen varios modulos diferentes o bienque se utilize codigo de C++ puro (sin SystemC), esta aproximacion puedeno ser la mas adecuada, debido a que si no se tiene control sobre el flujo delprograma y ademas un solo desfase entre los diferentes modulos se arrastrarahasta el final de la ejecucion.

Otro problema que se encontro en este tipo de sincronizacion fue que per-mite poca versatilidad, en caso de que se quiera correr un modulo de maneradiferente o independiente.

3.2 Sincronizacion por eventos en SystemC

Se realizo una prueba de sincronizacion por eventos. Mientras se tuvierantodas las funciones en el mismo modulo de SystemC, se podıa controlar todopor eventos. Se tenıa un master que generaba eventos y distintas CPUCR queesperaban ese evento para realizar alguna accion.

Sin embargo, al colocar cada CPUCR en un modulo distinto al master,era imposible disparar eventos en un modulo que activara acciones en otrosmodulos. Es decir, no se podıa tener un evento global que fuera funcional.

La manera de comunicarse en SystemC entre modulos es por medio depuertos. Para corregir el problema con los eventos, se generaban eventos dis-tintos en el modulo CPUCR y en el modulo master, y se conectaban ambosmodulos por medio de un puerto. Cuando el modulo master generaba un eventolocal, se activaba una funcion dentro del mismo que enviaba un pulso a travesde puertos. En el modulo CPUCR, se recibıa el pulso a traves de un puerto,donde una funcion disparaba un evento local que activa el funcionamiento dela CPUCR.

Esta solucion es mas complicada, y se busca algo mas simple y funcional.Por lo tanto, se decidio implementar senales de reloj como eventos.

3.2. Sincronizacion por eventos en SystemC 11

Senales de reloj como eventos

Esta solucion consiste en crear una senal que llegue a todos las instancias porigual y que con los cambios en esta senal se genere un evento, el cual se incluyeen la lista de sensibilidad del modulo.

En el manejador de eventos o master, se genera un ciclo de reloj hacia lasCPUCR. Es decir, cada vez que el master este preparado, genera un ciclo dereloj hacia cada CPUCR. Dentro de la misma, se leen los puertos de entraday se modifican los puertos de salida.

Un problema que surge del manejo con eventos, es que en el main (dondese indica cuando generar el evento) no se tiene forma de saber cuando setermino de ejecutar el codigo dentro de las CPUCRs (entiendase un ciclo deejecucion), por lo que pueden ocurrir traslapes entre la ejecucion del codigoen los modulos y el programa principal.

Sincronizacion mixta

Dado que ambas formas de sincronizacion anteriores presentan ventajas ydesventajas, se decidio crear una forma de sincronizacion que implementaraambas.

Para esto se creo una senal de reloj que generara eventos en las instanciasde modulos, y a su vez dentro de la funcion que se ejecuta por el evento seincluyo un retardo de tiempo, de forma que los modulos CPUCR se sincroni-zaran al final de cada ciclo de ejecucion.

Se combinaron las ventajas vistas en las sincronizacion por tiempos y poreventos. De esta forma se tiene total control de cuando se corre un ciclo deejecucion dentro de las CPUCR, pero ademas se tiene la certeza de que al finalde la ejecucion tanto los modulos, como el main estaran sincronizados, y noocurriran traslapes.

Esta ultima forma fue la que se decidio utilizar y se implemento en elproyecto.

4 Diseno del Juego

El juego de TankBattles se basa en gran parte en la idea expuesta por eljuego de Droidbattles. Este ultimo consiste en un juego programado utilizandoun lenguaje de esamblador de la arquitectura IA-32. El juego permite variosmodos de batalla, y una interfaz para configurar el Bot con una serie dedispostivos, entre ellos CPU, Engine, Steering, Plasmagun, Armor, Scanner,Fuel, Turrets, Time-device, Repair Device, Minelayer, beam, chaffs, cloak entreotros.

El menu principal se observa en la figura (4.1), y permite configurar unBot con los dispositivos mencionados, o editar el presupuesto para indicar elprecio de cada dispositivo. Dispone ademas varios modos de juego, entre ellosel modo normal, en modo liga, deathmatch, torneo, etc.

Figura 4.1: DroidBattles, pantalla principal.

Una vez configurada la partida, la dinamica consiste en un juego en dondenaves (bots) interactuan en una escena bidimensional, pueden disparar, es-canear, poner minas y senuelos, etc. En las figuras (4.2) y (4.3) se observan

13

14 4 Diseno del Juego

algunas partidas en droidbattles. Se puede observar el uso del scanner y de lasarmas (plasmaguns).

Figura 4.2: DroidBattles, ejemplo de batalla.

Es a partir de esta idea que surge TankBattles. TankBattles consiste enun juego bidimiensional programado, utilizando lenguaje ensamblador de laCPUCR. Cada jugador sera representado por un tanque al cual se le puedenconfigurar dispositivos similares a los de Droidbattles para intentar derrotara los enemigos. Se iniciara con una version donde se permita configurar elhardware y el presupuesto, y luego permita la interaccion entre los objetosbidimensionales.

4.1 Descripcion y funcionamiento del hardware delTanque

A cada jugador tiene la opcion de configurar una serie de dispositivos parasu tanque, con los cuales podra interacturar con el juego. El jugador puedeconfigurar un motor, un sistema de direccion, un canon, un escaner y unaarmadura, pero cada uno de estos y los diferentes niveles configurables tendranun precio y hay un presupuesto maximo que deben respetar.

4.1. Descripcion y funcionamiento del hardware del Tanque 15

Figura 4.3: DroidBattles, ejemplo de battalla.

La lista de dispositivos que disponen los jugadores se muestra a continua-cion:

• Engine

• Steering

• Cannon

• Scanner

• Fuel

• Armor

Cada uno de estos sera explicado con detalle en las proximas secciones.

CPUCR

Es el componente que controla el tanque y configura los demas perifericos.Consiste en un sistema computador basado en la arquitectura de la CPUCR,tal como se ha especificado anteriormente.

16 4 Diseno del Juego

Engine (Motor)

Es el dispositivo que permite al tanque variar la magnitud de su velocidad.Puede configurarse en 8 (ocho) niveles diferentes, en caso de que el nivel seacero, no se podra mover y cada uno de los niveles siguientes garantizaran unamayor velocidad maxima.

Steering (Direccion)

El dispositivo de steering es el que permite rotar el tanque sobre su eje central.Es necesario para dirigir el tanque y apuntar el canon en la direccion correcta.Si no se configura el tanque no podra rotar.

Cannon (Canon)

Es el arma del tanque, con el que los jugadores deben eliminar a los enemigos.Se puede configurar en 8 (ocho) niveles diferentes, donde el nivel cero nopermite disparar, y los niveles subsiguientes permitiran una mayor tasa dedisparos por unidad de tiempo (es decir disparara mas veces).

Scanner (Escaner)

El scanner es el dispositivo que permite identificar enemigos, su area de visionse configura con dos parametros, el angulo del scanner y el span o aperturadel scanner. Si se configura el scanner retorna informacion de la distancia y elangulo al que se encuentra el enemigo mas cercano dentro del rango de visiondel tanque.

La figura (4.4) muestra como se ve el area de vision configurada por unjugador. En el caso se observa que ambos jugadores configuraron un span yangulo diferentes.

Fuel (Combustible)

Para que el tanque pueda movilizarse se debe configurar algun nivel de com-bustible. Se pueden configurar 8 niveles de combustible inicial el cual se iraconsumiendo con los movimientos del jugador.

Armor (Armadura)

El jugador puede configurar tambien una armadura, que incrementara la can-tidad de vida inicial, y se puede configurar en 8 (ocho) niveles. En caso de queno se configure armadura se iniciara con un 50 % de vida y se ira incrementadolinealmente con el nivel del Armor hasta un 100 % al nivel maximo de Armor.Tal y como se muestra en la figura (4.5).

4.2. Modelo de Programacion 17

Figura 4.4: Ejemplo del uso del Scanner.

Figura 4.5: Porcentaje de vida incial de acuerdo con el Armor configurado.

4.2 Modelo de Programacion

Se definieron tres formas de interpretar los datos de los puertos tanto deentrada como de salida de la CPUCR:

• Magnitud: Se interpreta el dato como un numero sin signo. En dondese mapea linealmente el dato de [0 − 63] (recordemos que la CPUCRtiene puertos de 6 bits, por lo que el maximo valor es 63) a [0 − 100 %].

• Angulo: Se interpreta el dato como un numero con signo, en donde el

18 4 Diseno del Juego

cero representa el origen (para los angulos absolutos el origen es el Esteo la derecha, y para los relativos el origen es el frente del tanque). Deesta forma se mapea el numero de [−32, 31] a [−180◦, 174◦]. Se tiene lalimitante de que la resolucion es de 6◦.

• Bandera: Se interpreta el dato como una bandera booleana, en dondesolo existen dos estados: verdadero o falso. En caso de que el dato seacero, se interpreta como falso y cualquier otro valor se intepreta comoverdadero.

Una vez definidas las formas de interpretar los angulos, se listaron lospuertos de entrada y salida a utilizar, con sus significados. Para cada puertose creo una etiqueta que identifica el puerto con la funcion que realiza y seespera que al programador se le facilite un archivo con las definiciones dedichas etiquetas para facilitar la programacion.

Los puertos de salida que se utilizan para configurar el hardware definidopor el usuario, la lista de puertos disponibles se muestra en la tabla (4.1).

Cuadro 4.1: Funciones de los puertos de salida.

Puerto de Salida Funcion Dispositivo

0 SET SPEED Engine1 SET DIR Steering2 SHOOT CANNON Cannon3 SET SCANNER ANGLE Scanner4 SET SCANNER SPAN Scanner

El significado de cada uno de las funciones de los puertos de salida, seespecifica a continuacion:

• SET SPEED: Permite configurar la velocidad del motor. Se interpre-ta como magnitud (como se detallo anteriormente). La velocidad finalobservada sera escalada dependiendo del nivel de motor (Engine) confi-gurado.

• SET DIR: Permite configurar la direccion del tanque. Se interpretacomo un angulo absoluto, tomando el Este como la referencia.

• SHOOT CANNON: Se utiliza como bandera para disparar el canon.Si se escribe algo diferente de 0, el tanque disparara. Un hardware decanon mejor implicara una tasa de disparo mas rapido.

• SET SCANNER ANGLE: Configura el angulo al que se centra elscanner, este indica el desfase angular entre el frente del tanque y el

4.2. Modelo de Programacion 19

centro del area del scanner. Es decir se interpreta como un angulo relativoal frente del tanque.

• SET SCANNER SPAN: Sirve para configurar el porcentaje de aper-tura del scanner, se interpreta como un porcentaje de los 360◦ disponi-bles.

Los puertos de salida solo se interpretaran en caso de que se tenga confi-gurado el hardware necesario relacionado al puerto, la relacion entre el puertoy el dispositivo necesario se muestra tambien en la tabla (4.1).

Para los puertos de entrada, que contienen la informacion de la partida quese le brinda al usuario, se listaron los puertos a utilizar y estos se muestran enla tabla (4.2) con sus respectivas etiquetas que indican la funcion que cumplen.

Cuadro 4.2: Funciones de los puertos de entrada.

Puerto de Entrada Funcion

0 GET LIFE1 GET SPEED2 GET DIR3 GET X4 GET Y5 SCANNED DIR6 SCANNED DIST7 GET FUEL

El detalle de cada una de las funciones de los puertos de entrada se mues-tran a continuacion:

• GET LIFE: Contiene la cantidad de vida restante, y debe ser interpre-tado como magnitud. El 100 % de vida se dara solo en el caso que seconfigure el nivel maximo de Armor.

• GET SPEED: Contiene la velocidad con la se ha configurado el Engine.Se debe interpretar como magnitud.

• GET DIR: Contiene el angulo con la direccion del tanque. Se debeinterpretar como un angulo absoluto (medido respecto al Este o la de-recha).

• GET X: Contiene la posicion cartesiana en la arena, se debe interpretarcomo una magnitud, en donde 0 % indica que el jugador se encuentraen el extremo izquierdo de la arena y un 100 % indica que el jugador seencuentra en el extremo derecho de la arena.

20 4 Diseno del Juego

• GET Y: Contiene la posicion cartesiana en la arena, se debe interpretarcomo una magnitud, en donde 0 % indica que el jugador se encuentraen el extremo superior de la arena y un 100 % indica que el jugador seencuentra en el extremo inferior de la arena.

• SCANNED DIR: Contiene el angulo absoluto de la posicion del enemi-go mas cercano dentro del rango del scanner. Este dato es valido solo siel SCANNED DIST es diferente de cero.

• SCANNED DIST: Contiene la distancia hacia el enemigo mas cercanodentro del rango configurado del scanner, en caso de que no se hayaescaneado nada tiene un valor de cero.

• GET FUEL: Contiene el porcentaje de combustible disponible. En casode que sea cero el jugador no podra moverse.

Es importante recalcar que en las estructuras de datos que se empleanpara la logica del juego, se tendran variables con una resolucion mucho masalta y a la hora de escribirlas en los puertos de la CPUCR se perdera dicharesolucion.

5 Arquitectura de Software

Para el diseno del software del juego, se decidio dividir el problema por capas.Cada capa tendra una lista de problemas a resolver e interfaces con las capascontiguas que debe respetar.

El diseno del software tuvo una aproximacion top-to-bottom, es decir seplanteo el software completo y se fueron obteniendo requerimientos y plan-teando las estructuras internas necesarios.

El diseno por capas planteado se muestra en la figura (5.1). En este dia-grama se observa que se plantean 3 (tres) capas distintas. Una capa de GUI(interfaz grafica de usuario), una capa de logica del juego y una capa de ar-quitectura de hardware.

Figura 5.1: Diagrama de capas de abstraccion de software.

5.1 Capa de interfaz grafica de usuario

La capa de interfaz grafica de usuario es la capa mas abstracta y con la queel usuario tiene mas interaccion. Entre las funciones que tiene la capa de GUIestan:

• Implementar los menus de configuracion del hardware del tanque.

21

22 5 Arquitectura de Software

• Implementar un sistema para manejar el costo de los dispositivos y laconfiguracion del tanque.

• Implementar una interfaz para configurar la batalla para diferente can-tidad de usuarios, cada uno con su codigo de ensamblador, nombre yarchivo de configuracion de hardware.

• Implementar un ambiente para interaccion de objetos en 2D (sprites).

• Implementar los sprites para el tanque y las balas.

• Implemetar el movimiento de los objetos a partir de la configuraciondada por la capa logica

• Detectar colisiones entre los objetos.

• Reportar los cambios de vida y combustible al nivel de logica.

• Ejecutar el lazo de flujo del juego.

5.2 Capa de logica del juego

La capa de logica del juego, es la capa intermedia, debe contener a la capa dearquitectura de hardware y debe ser instanciada en la capa de GUI. Entre lasfunciones que debe cumplir la capa de logica de juego estan:

• Contener las estructuras de datos necesarias para almacenar la informa-cion de estado del tanque (informacion de vida, combustible, etc).

• Implementar las estructuras de datos para la configuracion de hardwarede cada jugador.

• Crear las clases para representar a los objetos de Tanque y de batalla.

• Obtener la configuracion de los dispositivos a partir de los puertos desalida de la capa de arquitectura e interpretar los datos de los puertos.

• Actualizar los puertos de entrada de la capa de arquitectura con la in-formacion de estado del tanque.

• Indicar al nivel de capa de arquitectura de hardware cuando deben corrertodas las CPUCR de los usuarios en forma sincronica.

5.3. Capa de arquitectura de hardware 23

5.3 Capa de arquitectura de hardware

La capa de arquitectura de hardware debe utilizar la librerıa de SystemC comoparte de los requisitos impuestos. Entre las funciones que debe cumplir la capade arquitectura de hardware estan:

• Manejar el tiempo y la sincronizacion de los modelos de hardware.

• Desarrollar un modelo completo en SystemC de la CPUCR.

• Permitir el ensamblado y depuracion del programa en lenguaje de en-samblador.

• Tener la capacidad de correr cada uno de los modelos de hardware delas CPUCRs en paralelo.

• Configurar la memoria por medio de la carga de un archivo ensamblado.

• Poner a disposicion de la capa de logica del juego, los puertos de laCPUCR para la lectura y escritura.

• Contener una senal externa de reloj que pueda ser conmutada por lacapa de logica del juego para correr las CPUCR.

6 Capa de Arquitectura deHardware

La capa de Arquitectura de Hardware esta desarrollada por completo utili-zando la librerıa de SystemC para el modelado de hardware, lo que permitedisenar los modelos de hardware y que sean compatibles con el API de la capade logica del juego. Para esta capa se crearon dos modulos de SystemC, loscuales se explican a continuacion.

6.1 CPUCR

El modulo CPUCR, es un modulo de SystemC (sc module), el cual representaa todo el sistema computador de la CPUCR, incluyendo la memoria, los busesde datos, los puertos y el CPU.

Debido a los alcances del proyecto se creo un modulo de CPUCR querepresenta su comportamiento, en cuanto a puertos (de entrada y salida), ysincronizacion. Este modulo tiene 64 puertos de entrada y 64 de salida, de 6bits cada uno.

Para realizar la sincronizacion entre todas las CPUCRS se utilizara el me-todo de sincronizacion mixta explicada en el capıtulo 3. Para esto la CPUCRdebe contar con una senal de reloj de entrada, que al producir un flanco po-sitivo, se corra un ciclo de ejecucion.

Dentro de cada ciclo de ejecucion se debe tener ademas una espera de 2 nS(nano segundos), este en realidad es un tiempo de SystemC y se utilizara comoparte de la sincronizacion mixta explicada. Esto implica que cada instruccional terminar debe esperar 4 nS para garantizar que todas las CPUCR quedenen sintonıa.

Se requiere ademas que las funciones del ciclo de ejecucion funcionen comothread, para que todas las CPUCR corran al mismo tiempo y en paralelo. Eldiagrama UML del modulo CPUCR se muestra en la figura (6.1).

Para fines de este proyecto se creo una maquina de estados que periodi-camente cambia de los puertos de salida de manera aleatoria, y que permiteimprimir en terminal los valores de entrada y los valores configurados en lospuertos de salida para validar la implementacion de la capa logica.

La dinamica percibida por el programador se ilustra en la figura (6.2). Enesta se observa que los datos en los puertos de salida afectan la configuraciondel hardware, con base a los datos generados por los dispositivos de hardware,

25

26 6 Capa de Arquitectura de Hardware

CPUCR

+ Output_Ports[64] : sc_signal<sc_uint<6>>+ Input_Ports[64] : sc_signal<sc_uint<6>>+ Clock : sc_signal<bool>

+ CPUCR(string name, string file) : void+ run_cicle() : void

Figura 6.1: Diagrama UML del modulo CPUCR.

y la interaccion con el entorno (entiendase colisiones con balas, movimiento,etc) se generan los datos que son recibidos en los puertos de entrada. Todosestos datos en realidad pasan primero por la capa de la logica del juego yadecua los datos a los puertos de la CPUCR.

6.2 Synchronizer

Uno de los principales problemas de diseno fue la sincronizacion de las di-ferentes CPUCR. Es por esto que se creo como parte de la capa de modelode hardware, un modulo de SystemC llamado Synchronizer, este modulo seencarga de sincronizar todas las CPUCRs por medio de una senal de reloj.Contiene una funcion de generar el ciclo de reloj que puede ser activada porla capa logica cuando se necesite correr un ciclo en todas las CPUCR al mis-mo tiempo. El diagrama de conexion entre el synchronizer y las CPUCR semuestra en la figura (6.4).

El diagrama UML de este modulo se observa en la figura (6.3).

6.2. Synchronizer 27

Figura 6.2: Dinamica de los puertos de la CPUCR.

Synchronizer

+ Clock : sc_signal<bool>

+ run_CPUs() : void

Figura 6.3: Diagrama UML del modulo Synchronizer.

28 6 Capa de Arquitectura de Hardware

Figura 6.4: Diagrama del modulo Synchronizer.

7 Capa de Logica del Juego

Para la capa de logica del juego, se implementaron dos clases y dos structsen C++. Se diseno una clase TankBot que representa al “tanque” de unjugador, y se implemento una clase TankBattle la cual representa una batallao partida. Dentro de la clase TankBot se implementaron dos structs, paracontener informacion del estado del tanque y para la informacion del hardwaredel tanque (cuales dispositivos estan disponibles y con que nivel).

Por ultimo se instanciaron los modulos de SystemC (de la capa de hard-ware), la CPUCR y el Synchronizer (sincronizador) dentro de las clases deTankBot y TankBattle respectivamente.

En la figura (7.1) se muestra la relacion entre la clase de TankBattle,la clase de TankBot, los structs de BotStatus y Botwardware y los modulosde SystemC de la capa de arquitectura de hardware. La clase Tankbattlecontendra las instancias de TankBot que representaran a cada jugador asıcomo un modulo sincronizador para controlar el tiempo y la ejecucion de lasCPUCR, cada TankBot tendra una CPUCR que contendra el algoritmo parajugar. Debemos recordar que el modulo Sincronizer brinda una senal de reloja todas las CPUCR.

El diagrama UML correspondiente para la capa de logica, se observa enla figura (7.2). A continuacion se profundizara en las clases TankBot y Tank-Battle, y sus respectivos atributos.

7.1 Clase TankBot

La clase TankBot es una clase implementada en C++, cuyo diagrama UMLse muestra en la figura (7.3). Esta clase es una representacion de cada jugadoro “tanque”. Contiene la informacion acerca del estado del tanque, es decir: suposicion, cantidad de vida, cantidad de combustible, velocidad, configuraciondel scanner y la informacion del enemigo mas proximo escaneado. Ademas,tiene la informacion de la configuracion de hardware del tanque, es decir sitiene o no scanner, si tiene armas, motor, capacidad de doblar, combustible oarmadura.

Para esto la clase TankBot, utiliza dos structs(estructuras de datos) deC++, para simplificar la interaccion entre clases y el manejo de variables. Secreo un primer struct para el estado del tanque y otro para la configuracionde hardware, los cuales seran explicados posteriormente.

29

30 7 Capa de Logica del Juego

Figura 7.1: Diagrama general de la capa de logica de juego.

Un atributo importante de la clase TankBot, es la CPU. Esta CPU es quiencontrola el tanque, y consiste en una instancia de un modulo de CPUCR. Pormedio de los puertos de salida, se cambia el estado del TankBot y debido alestado se modifican los puertos de entrada. Esta interaccion de la CPUCR conla clase TankBot esta representada por la figura (7.4). Un punto a destacaren este modulo CPU, es que necesita una senal de reloj externa para podersincronizarse cuando hayan mas de una instancia de TankBot.

BotStatus

El BotStatus agrupa la informacion del estado del TankBot. Este struct con-tiene las variables cuyos valores cambian constantemente en el tiempo de eje-cucion. En el BotStatus se encuentra la informacion de la posicion, cantidadde vida, cantidad de combustible, velocidad, configuracion del scanner y lainformacion del enemigo mas proximo escaneado. Toda esta informacion se vemodificada por dos factores, el primero son los puertos de salida que configu-ran el hardware para desarrollar el algoritmo del jugador y el segundo es lapartida en sı que modifica el estado del TankBot (vida, posicion, etc).

El BotStatus sirve como intermediario con el CPU del TankBot. Es decir,cuando se modifican las variables como: la vida, el combustible, la posicion o lainformacion del enemigo mas proximo estas son transferidas posteriormente a

7.1. Clase TankBot 31

Figura 7.2: Diagrama UML de las clases implementadas.

los puertos de entrada de la CPU para que puedan ser leıdos; ademas cuando elalgoritmo del jugador modifique los puertos de salida, se leen e interpretan paracambiar los valores del BotStatus, de forma que se configuren los dispositivosde hardware como el alcance del scanner, si se debe disparar, o si se debevariar la velocidad o direccion del tanque.

En esta estructura los angulos estan representados en el rango de [−1, 1]en una variable del tipo flotante (float), las magnitudes estan contenidas envariables del tipo entero (int) y se tiene un booleano para saber si se estadisparando o no. Estas variables se agruparon en tupples para facilitar sumanipulacion.

32 7 Capa de Logica del Juego

TankBot

- Status : BotStatus- Hardware : BotHardware- CPU : CPUCR*

+ TankBot(string name, string hw_file, string name, sc_bool clock)+ get_status() : BotStatus+ set_status(BotStatus) : void+ get_hardware(): BotHardware+ set_hardware(string hw_file) : void+ check_budget(string file_xml) : bool+ update_status() : void+ update_ports(): void

Figura 7.3: Diagrama UML de la clase TankBot.

Figura 7.4: Diagrama de la clase TankBot.

BotHardware

El BotHardware agrupa la informacion del TankBot relacionada a la confi-guracion de hardware. Esta informacion tiene como caracterıstica comun quesolo se modifica una vez al inicio del juego. El BotHardware indica si se tiene ono scanner, motor, steering, armadura, y el canon. Ademas, se indica en casode que sı se tengan: el nivel del motor (a mas nivel, mas velocidad), del canon

7.2. Clase TankBattle 33

BotStatus

+ Life : u int+ Name : String+ Fuel : u Int+ Cannon : Bool+ Position : Tuple <u int, u int>+ Speed : Tuple <u int, float>+ Scanner_conf : <u int, float>+ Scanned : <u int, float>

Figura 7.5: Diagrama UML del struct BotStatus.

(mas nivel, mas dano), la armadura y el combustible.

BotHardware

+ Armor : Int+ Scanner : Bool+ Steering : Bool+ Engine : Int+ Cannon : Int+ Fuel : Int

Figura 7.6: Diagrama UML del struct BotHardware.

7.2 Clase TankBattle

Se diseno la clase TankBattle de forma que fuera una representacion de unabatalla. El diagrama UML de esta clase se muestra en la figura (7.7). En ellase muestra que la clase contiene a los jugadores, en un puntero de TankBot(que funcionara como un arreglo de jugadores), tiene ademas la cantidad dejugadores y un modulo de sincronizador. De esta manera la clase TankBattlese encarga de realizar funciones a todos los jugadores. Un diagrama ilustrativode la clase TankBattle se muestra en la figura (7.8)

34 7 Capa de Logica del Juego

TankBattle

+ TankBattle (int players, string * players, string* hardware, string* names) : void+ get_statuses() : BotStatus*+ set_statuses(BotStatus*) : void+ update_ports() : void+ update_statuses() : void

- Sync : Synchronizer- Players: TankBot* []- Statuses: BotStatus* []- Num_Players: Int

Figura 7.7: Diagrama UML de la clase TankBattle.

Figura 7.8: Diagrama de la clase TankBattle.

8 Capa de la Interfaz Grafica deUsuario (GUI)

Para la capa de interfaz grafica de usuario se establecieron algunos requeri-mientos para ser compatible con las capas de logica del juego y de arquitecturade hardware.

En este nivel de abstraccion se debe instanciar el objeto TankBattle yutilizar el API correspondiente para informar las condiciones del estado decada jugador como: la posicion, la informacion del escaner, la vida, y el com-bustible. Ademas se deben utilizar los metodos correspondientes para obtenerinformacion de configuracion del hardware del tanque.

8.1 Configuracion del hardware del tanque

Como parte de los requerimientos del GUI, esta crear una interfaz para laconfiguracion del hardware. Esta interfaz debe ser compatible con la capa delogica del juego, para esto la clase TankBattle espera en su constructor unarchivo de configuracion de hardware definido en el formato de XML (eX-tensive Markup Language). El formato esperado de los archivos se observa acontinuacion:

1 <TANKBOT>

2 <ARMOR>8</ARMOR>

3 <SCANNER>1</SCANNER>

4 <ENGINE>1</ENGINE>

5 <STEERING>1</STEERING>

6 <CANNON>8</CANNON>

7 <FUEL>7</FUEL>

8 </TANKBOT>

Archivo de configuracion de Hardware

Se observa que para cada uno de los dispositivos se especifica un numeroque corresponde al nivel configurado, y ademas para los que no tienen nivelesse especifica 0 (cero) o 1 (uno).

Ademas, se debe generar un archivo de especificacion del presupuesto enel mismo formato XML. Para este archivo se debe especificar el costo de cadanivel de los dispositivos que se puedan configurar. Se configura solo uno por

35

36 8 Capa de la Interfaz Grafica de Usuario (GUI)

partida. En el archivo se debe especificar el presupuesto maximo que disponecada jugador para armar su tanque. Un ejemplo del archivo de configuraciondel presupuesto se muestra a continuacion:

1 <BUDGET>

2 <MAX_BUDGET>4200</MAX_BUDGET>

3 <ARMOR_COST>100</ARMOR_COST>

4 <SCANNER_COST>700</SCANNER_COST>

5 <ENGINE_COST>250</ENGINE_COST>

6 <STEERING_COST>500</STEERING_COST>

7 <CANNON_COST>200</CANNON_COST>

8 <FUEL_COST>50</FUEL_COST>

9 </BUDGET>

Archivo de configuracion de presupuesto

8.2 Flujo del programa

Otro de los requerimiento que se ha fijado para la capa de interfaz grafica, esel flujo del programa principal. Cuando el juego este en desarrollo debe seguiren general esta serie de pasos y repetir hasta que se encuentre un ganador:

1. Se actualizan los puertos de entrada de las CPUCR con la informacionde las variables de BotStatus utilizando el metodo de la clase TankBattleupdate ports().

2. Se genera un ciclo de reloj utilizando el modulo de Synchronizer, y se-guidamente se deja correr el tiempo sintetico de SystemC por 4ns, uti-lizando la funcion SC START de SystemC.

3. Se actualizan las variables de BotStatus de acuerdo con los valores delos puertos de salida utilizando el metodo update status() de la claseTankBattle.

4. Se verifica la condicion de fin de la partida (cuando quede solo un juga-dor) y en ese caso se termina el ciclo, de otra forma se vuelve a empezar.

5. Para cada tanque, se actualiza su posicion, identifican colisiones, se creanlos objetos de balas en caso de que este disparando y se deben actualizarlas variables de vida, combustible, posicion y la informacion del escaner;todo esto en las variables de BotStatus de cada tanque.

6. Se actualizan las nuevas coordenadas de las balas de acuerdo a unavelocidad configurada y deberan eliminarse cuando salgan de la arenade juego.

8.3. Sprite 37

Estos puntos son necesarios pero puede que no sean suficientes para eldesarrollo adecuado de la interfaz grafica, por lo que pueden realizarse masacciones en el ciclo, como crear animaciones, actualizar algun marcador, oagregar efectos sonoros; todo esto se puede agregar al ciclo. El diagrama de lafigura (8.1) ilustra el ciclo detallado anteriormente.

Figura 8.1: Flujo de programa

8.3 Sprite

Parte de los requisitos de la interfaz grafica es crear un ambiente para lainteraccion de objetos bidimensionales, llamados Sprites. Estos seran las re-presentaciones graficas tanto de la clase TankBot, de las balas e incluso de laclase TanBattle; como se muestra en la figura (8.2).

Figura 8.2: Sprites

9 Resultados

9.1 Menus de configuracion

Para el videojuego TankBattles, se crearon menus de configuracion de formaque se puedan crear nuevos TankBots, configurar el presupuesto para creardichos TankBots y configurar una nueva batalla. El menu principal que secreo se muestra en la figura (9.1) y permite estos tres tipos de configuracion.

Figura 9.1: Menu principal

La primera de estas opciones es el TankBot Creator, cuya ventana de confi-guracion se muestra en la figura (9.2). Este menu permite configurar el Hard-ware del TankBot, seleccionando los dispositivos con los que cuenta dichoTankBot y el nivel para cada uno de ellos. Ademas permite guardar la confi-guracion del TankBot en un archivo XML con el nombre que se desee, o bienprecargar alguna configuracion de otro TankBot. Una funcion importante deeste menu es mostrar el costo total de la configuracion y ver que no sobrepaseun presupuesto definido en un archivo XML que se puede cargar.

39

40 9 Resultados

Figura 9.2: Menu creador de tanques

La opcion de Config Editor permite darle un costo a cada dispositivo yestablecer un presupuesto maximo con el que cuentan los jugadores en lapartida. Dicha configuracion se puede cargar de un archivo para precargarvalores o empezar de cero. El configuracion se guarda en un archivo XML quese puede cargar en los menus de Bot Creator o el de inicio de juego. La figura(9.3) muestra el menu de configuracion de presupuesto o Config Editor.

Por ultimo, el menu de configuracion de inicio de batalla, permite selec-cionar los TankBots que van a participar de la batalla, darles un nombre,cargar una configuracion de hardware y un archivo de codigo con el algoritmoprogramado en ensamblador de la CPUCR. Para la batalla se configura unarchivo de presupuesto, que se verifica que cada TankBot respete. El menu deconfiguracion de batalla se muestra en la figura (9.4).

9.2 Arena de Batalla y Sprites

Se crearon tres Sprites, que como se explico, son representaciones bidimensio-nales de los objetos en el juego. El Sprite de TankBattle se representa comoun marcador en la arena de juego, mostrando la vida de cada jugador y ade-

9.2. Arena de Batalla y Sprites 41

Figura 9.3: Menu editor de configuracion

Figura 9.4: Menu inicio de juego

mas el fuel que tiene disponible. Es responsable ademas de generar los flancosde reloj, cambiar los valores en los puertos de entrada y leer los puertos de

42 9 Resultados

salida, ademas permite verificar si hubo un ganador. El sprite de TankBattlese observa en la figura (9.5).

Figura 9.5: Sprite Batttle - Scoreboard.

La instancia de TankBot de cada jugador es representado graficamentepor un Sprite de Tank. Este tanque es el que permite las interacciones con eljuego, permite ver el movimiento del jugador, se observa si dispara o no y laconfiguracion actual del Scanner. En la figura (9.4), se observa el scanner deljugador configurado para cierta apertura y cierto desfase, ademas en la figura(9.6) se observa la imagen del sprite de Tank.

Por ultimo, el Sprite de Bullet representa a las balas disparadas por elcanon de cada tanque. Estas se representan con cırculos rojos y su direccionesta definida por la rotacion del Sprite de Tank del que surgio el disparo, comose muestra en la figura (9.7).

9.2. Arena de Batalla y Sprites 43

Figura 9.6: Sprite tanque

Figura 9.7: Sprite bullet

10 Conclusiones yRecomendaciones

10.1 Conclusiones

• Se desarrollaron las reglas de juego y el modelo de programacion del vi-deojuego TankBattles. Definiendo una serie de dispositivos, o Hardware,que dispone cada usuario para implementar en su tanque; y establecien-do una lista de puertos de entrada y salida, y la forma en que se debeintepretar los datos de dichos puertos por el usuario.

• Se diseno una arquitectura de software para crear el videojuego Tank-Battles divida tres capas: una capa de interfaz grafica de usuario, una dela logica del juego y por ultimo una capa de la arquitectura de hardware.Para cada una de estas se definio una lista de requisitos y la forma enque debe realizar la interfaz con las capas contiguas.

• Se identifico la mejor forma de sincronizacion de los modulos CPUCR,utilizando los flancos positivos de una senal de reloj, los cuales se empleancomo eventos que reciben las instancias de CPUCR e inician un ciclo deejecucion. Luego se emplea un retardo de tiempo sintetico de SystemCpara sincronizar los modulos de forma que queden sincronizados luegode la ejecucion.

• Se definieron los requerimientos de un modelo de la CPUCR basadoen SystemC para que sea compatible con el videjuego desarrollado. LaCPUCR debe contar con 64 puertos de entrada y la misma cantidad desalida, cada puerto debe ser de 6 bits. Ademas debe tener una entradade reloj que al generar un flanco positivo ejecute un ciclo de programa,y luego se debe tener un retardo de 4ns para sincronizarse con todas lasdemas CPUCR.

• Se desarrollo un entorno de simulacion para varias CPUCR, de formaque funcionen en paralelo y sincronizadamente utilizando la librerıa deSystemC y un modelo de sincronizacion mixta empleando flancos enlas senales de reloj como eventos y el retardos de tiempo sinteticos pormedio de SystemC.

45

46 10 Conclusiones y Recomendaciones

• Se disenaron e implementaron las clases de TankBot y TankBattle comoparte de la capa de logica del juego, ası como las estructuras de datosde BotStatus y BotHardware para contener los datos del estado de cadajugador. Se implemetaron ademas todos los metodos necesarios paraaccesar y modificar las estructuras de datos de forma coherente con lasreglas del juego.

• Se establecieron los requerimientos para la capa de interfaz grafica: comoel uso del formato XML en la configuracion del hardware de cada tanquey los pasos que debe seguir el flujo principal del programa al ejecutarse.Todo esto para ser compatible con el API definido por la capa de logicadesarrollada.

10.2 Recomendaciones

En el caso de que se quiera continuar este proyecto se tienen las siguientesrecomendaciones:

• Agregar mas dispositivos de hardware que permitan mas libertad al usua-rio a la hora de configurar su tanque y desarrollar el algoritmo a imple-mentar. Se pueden agregar dispositivos como capas de invisibilidad (parano ser detectados por los radares), minas, senuelos, misiles dirigidos, dis-positivos de reparacion del tanque, escudos, entre muchos otros.

• Aumentar la resolucion para configurar los dispositivos de hardware enlos puertos de entrada y salida uniendo dos puertos (parte alta y partebaja) de forma que se puedan definir angulos con una precicion de 0,087◦,lo cual permitirıa mucho mas exactitud que los 6◦ actuales. Se puedeimplementar lo mismo para los puertos que sean interpretados comomagnitudes.

• Incluir en el desarrollo de la interfaz grafica animaciones y efectos desonido para mejorar la experiencia del usuario.

• Incluir mas modos de batalla, como por ejemplo batallas por equipo,torneos, batallas contra el tiempo, etc.

• Separar el struct de BotStatus en dos, dejando el BotStatus con las va-riables de vida (cuyo flujo de informacion es hacia la CPUCR) y crear unstruct con las variables obtenidas de los puertos de salida de la CPUCR(cuyo flujo de informacion es hacia la GUI).

Bibliografıa

Agorander, A. (2002). The DroidBattles Handbook. Bluefire.

Banerjee, A. y Sur, B. (2013). SystemC and SystemC-AMS in Practice: Sys-temC 2.3, 2.2 and SystemC-AMS 1.0. Springer Science & Business Media.

Eeles, P. (2006). What is software architecture. IBM.

Garlan y Shaw, M. (2003). An Introduction to Software Architecture. Advan-ces in Software Engineering and Knowledge Engineering. World ScientificPublishing.

IEEE (2011). Ieee standard for standard systemc language reference manual.IEEE Std. 1666-2011.

Muller, W., Rosenstiel, W., y Ruf, J. (2003). SystemC: methodologies andapplications. Springer Science & Business Media.

Olsson, T., Toll, D., y Wingkvist, A. (2015). Evolution and evaluation of themodel-view-controller architecture in games. 2015 IEEE/ACM 4th Inter-national Workshop on Games and Software Engineering.

Pacheco, W. A. y Cubero, E. A. O. (2005). Generacion de un modelo sinteti-zable en compuertas estandar para la cpucr. Reporte tecnico, Universidadde Costa Rica.

Reenskaug, T. (1979). MODELS - VIEWS - CONTROLLERS. Reporte tec-nico, http://heim.ifi.uio.no/ ∼ trygver/1979/mvc-2/1979-12-MVC.pdf.

Wilson, S. F. (1999). Analyzing Requirements and Defining Solution Archi-tectures: MCSD Training Kit: For Exam 70-100 with CD-ROM. MicrosoftPress.

47