144

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

LA COMPETITIVIDAD COMO UN FACTOR MOTIVANTE PARA EL APRENDIZAJE DE SISTEMAS EXPERTOS Manuel Palomo Duarte1 1

Grupo de Investigación Mejora del Proceso Software y Métodos Formales, Escuela Superior de Ingeniría, Universidad de Cádiz [email protected]

Resumen. La cada vez mayor importancia de la industria del videojuego y del ocio electrónico ha provocado que algunas universidades estén incorporando materias afines en sus planes de estudios. Este artículo presenta una experiencia innovadora de aprendizaje del desarrollo de sistemas expertos (una rama de la inteligencia artificial) mediante una competición entre compañeros de clase dentro de la asignatura optativa "Diseño de Videojuegos" de la titulación Ingeniería Técnica en Informática de Sistemas. Para ello se ha desarrollado un entorno que simula un juego de tablero en el que se enfrentan dos ejércitos realizando movimientos por turnos. La implementación se ha realizado en C/C++ usando la biblioteca SDL para la interfaz gráfica y CLIPS para la explotación de sistemas expertos. Cada alumno diseña e implementa una estrategia que mejora el módulo de inteligencia artificial básico proporcionado para su ejército. Posteriormente se realiza una competición enfrentando los ejércitos programados por los alumnos. Palabras clave: Enseñanzas técnicas, sistemas expertos, competitividad, EEES.

1. INTRODUCCIÓN La importancia que está teniendo en los últimos tiempos la industria del videojuego y del ocio electrónico ha provocado que cada vez sean más las universidades que están incorporando materias afines en sus planes de estudios. La Universidad de Cádiz ofrece desde este curso 2006/07 la asignatura optativa de tercer curso "Diseño de Videojuegos" en su reciente plan de estudios de Ingeniería Técnica en Informática de Sistemas de 2004. Esta asignatura destaca por ser multidisciplinar, lo que facilita la aplicación de distintas estrategias de enseñanza para temas concreto. Este artículo presenta una experiencia innovadora de aprendizaje del desarrollo de sistemas expertos (una rama de la inteligencia artificial) mediante una competición entre programas desarrollados por compañeros de clase. Para ello se ha desarrollado un entorno que simula un juego de tablero en el que se enfrentan dos ejércitos realizando movimientos por turnos. El entorno incluye el motor de simulación (control de turnos, realización de movimientos, etc), un entorno gráfico para ver las partidas y un módulo muy básico de inteligencia artificial para cada equipo que debe mejorar el alumno. La actividad incluye una explicación del profesor sobre los aspectos básicos de los sistemas expertos apoyada en ejemplos para que después cada alumno diseñe una estrategia que mejore el módulo de inteligencia artificial básico de su ejército. Posteriormente los alumnos implementan dicha estrategia y se realiza la competición en clase. En dicha competición se realizan simulaciones que enfrentan ejércitos de dos alumnos funcionando de manera autónoma. Los ejércitos tienen idénticas características pero cada uno lo controla el módulo de inteligencia artificial de un alumno. 2. LA ASIGNATURA La asignatura "Diseño de Videojuegos" es optativa de tercer curso, con una carga de 6 créditos LRU

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

(4,5 créditos ECTS), dividido al 50% entre teoría y práctica (dos sesiones de dos horas semanales en el segundo cuatrimestre). Destaca por ser una asignatura multidisciplinar, que integra conocimientos de programación, inteligencia artificial, física, modelado, trabajo en grupo, etc. La asignatura se imparte siguiendo un modelo similar al "Aprendizaje basado en proyectos": a principio de curso los alumnos organizan grupos de tres alumnos que trabajarán juntos a lo largo del curso en un proyecto cuyo objetivo es diseñar y programar un videojuego. La asignatura cuenta con el apoyo indispensable de la herramienta de Campus Virtual de la Universidad de Cádiz [1], basada en Moodle [2]. De esta forma se facilita enormemente el acceso de los alumnos a los recursos necesarios en la signatura y también se facilita la comunicación entre compañeros de clase y entre alumno y profesor 2.1. Organización de las clases Las clases teóricas se dedican a explicar conceptos teóricos necesarios para realizar un videojuego y proporciona tiempo para que el grupo decidida la forma de adaptar dichos conceptos a su proyecto. Estos conceptos comprenden taxonomía de videojuegos, arquitectura genérica de un videojuego, secuencia de diseño (metodología, modelado, consejos, buenas prácticas, etc), aspectos a nivelar (jugabilidad, simulación, narrativa, dificultad, etc) e implementación (gráficos en 2D y 3D, gestión de colisiones, incorporación de audio, inteligencia artificial, programación con guiones, etc) En las prácticas se dedican las primeras sesiones al uso de las herramientas básicas que requerirán en el curso: gestión de proyectos, diseño digital, edición de audio, trabajo colaborativo, etc. Todo el software usado en la asignatura es software libre por motivos éticos [3] y en consonancia con la Declaración institucional del Consejo de Gobierno de la Universidad de Cádiz de apoyo al software libre [4], lo que permite que los alumnos puedan usar todos el software y su documentación adjunta en cualquier ordenador sin restricciones de licencias, versiones de evaluación con restricciones y otros inconvenientes del software privativo. Además, este software está instalado en los portátiles que ofrece en préstamo la Universidad de Cádiz Esta medida de habilitar el préstamo de portátiles en las mismas condiciones que el préstamo de libros de biblioteca facilita enormemente el trabajo autónomo de los alumno, sobre todo para ajustándose a su horario personal. Quizás de todas estas herramientas la que más llama la atención a los alumnos son las herramientas para trabajo colaborativo, que permiten que varios alumnos ir trabajando en diferentes módulos de su proyecto y después sincronizar sus cambios en un servidor central que también guarda todas las versiones intermedias de los ficheros subidos por si fuera necesario repasar cambios realizados. En el resto de la prácticas los integrantes del grupo tienen reuniones para ir tomando decisiones coordinarse, en las que principalmente toman decisiones sobre problemáticas que se encuentran en el desarrollo del proyecto y, por supuesto, consultan con el profesor las dudas que no sepan resolver. 2.2. Evaluación La evaluación se compone en un 50% del trabajo individual y el otro 50% del trabajo en grupo. En todas las evaluaciones se usan plantillas (que se suelen denominar rúbricas) que se hace públicas antes de su evaluación. Se permite a los alumnos participar en la creación de dichas plantillas. A nivel individual se valora el trabajo del alumno en el proyecto, su participación en clase y en Campus Virtual (donde las intervenciones en foros reciben una puntuación según su interés) y su trabajo de sistemas expertos.

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

El trabajo en grupo se valora el proyecto realizado en 4 momentos del desarrollo. Al comenzar el cuatrimestre se hace una presentación del objetivo del proyecto y del plan de trabajo que vale un 10%. Después se realizan dos presentaciones intermedias del estado del proyecto que valen un 20% y un 30%. Estas dos presentaciones intermedias tienen como principal objetivo servir de hitos para que los integrantes del grupo puedan evaluar si están alcanzando los objetivos que se plantearon inicialmente o no. Y por último, al final del cuatrimestre se presenta el resultado final que vale un 40%. En las últimas sesiones teóricas no se enseñan conceptos nuevos que aplicar al proyecto porque se considera que este último periodo es para afinar detalles finales del proyecto y no aumentarlo. Así que se aprovecha ese tiempo (un par de sesiones) a explicar el funcionamiento de los sistemas expertos. También las sesiones prácticas correspondientes de esas dos semanas se dedican a que cada alumno realice un sistema experto en el sistema que se creó para la experiencia, para posteriormente competir con los sistemas expertos diseñados por sus compañeros. 3.

LA EXPERIENCIA

Como se ha comentado, cerca del final del cuatrimestre se dedican dos semanas a explicar los principios fundamentales de los sistemas expertos y a implementar un ejercicio sobre el tema. Ese ejercicio es un módulo de inteligencia artificial para manejar de manera autónoma un ejército, que se enfrentará a los ejércitos de otros compañeros. Una experiencia similar puede encontrarse en la que se programaban módulos de inteligencia artificial para simular partidos de fútbol puede consultarse en [5] 3.1. Secuencia La actividad se desarrolla en dos semanas, incluyendo dos clases teóricas y dos clases prácticas. En la primera sesión teórica se les da a los alumnos un pequeño seminario de una hora de duración de introducción a los sistemas expertos, remarcando su importancia en la ciencia y sus diferentes aplicaciones en la realidad. La segunda hora de esta primera sesión se dedica a mostrar ejemplos de reglas de sistemas expertos similares a las que usarán ellos en su ejercicio (incluso algunas preparadas para que la puedan copiar directamente). Se comienza con ejemplos pequeños y termina con el análisis de un sistema de complejidad media orientado a la consecución de un objetivo mediante satisfacción de subobjetivos. En la sesión práctica de dicha semana los alumnos pueden aprenden a manejar el entorno en el aula de prácticas. Como no es difícil familiarizarse con el sistema suelen tener tiempo para comienzan a implementar algunas reglas sencillas y probarlas en el sistema. Se recomienda a los alumnos que comiencen implementando las reglas sencillas que han visto en la clase anterior y después incorporen las suyas. La segunda sesión teórica la dedica cada alumno a diseñar una estrategia que mejore el módulo de inteligencia artificial básico de su ejército. Los alumnos que tengan portátil (ya sea propio o de préstamo de biblioteca) pueden implementar dicha estrategia en clase, y los que no deben implementarlo en casa. Por último, en la segunda sesión práctica se realiza la competición en clase. En dicha competición se realizan simulaciones que enfrentan ejércitos de dos alumnos. Los ejércitos tienen idénticas características pero cada uno incorpora un módulo de inteligencia artificial programado por un alumno. 3.2.

Reglas del juego

Cada alumno realiza un conjunto de reglas para hacer un sistema experto que juegue a un juego basado en el popular juego de mesa Stratego [6]. Sin embargo, se han realizado varias

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

modificaciones que contribuyen a facilitar la programación del entorno, así como la posterior mejora de los sistemas expertos que controlan cada ejército: El juego se desarrolla en un tablero de 8 por 8 casillas. Participan dos jugadores, cada uno a cargo de un ejército. Cada ejército consta de varios tipos de piezas, que se detallan en la Tabla 1. Miembro

Puntos

Unidades

Rey

1

1

Soldado

2

8

Lancero

3

2

Caballero

4

2

Caballero con armadura

5

2

Héroe

6

1

Tabla 1: Valores y cantidades de fichas de cada ejército

Figura 1: Ejemplo de disposición de tablero al iniciar una partida Cada jugador puede colocar sus fichas como desee dentro de las dos filas del tablero más cercanas a él, estando los ejércitos uno enfrente de otro (como se observa en la figura 1). Cada jugador, inicialmente, conoce las posiciones y puntos de sus fichas, pero sólo conocerá las casillas ocupadas por piezas rivales (no el valor de cada una). El objetivo del juego es capturar al rey contrario. Para conseguirlo los jugadores moverán sus ejércitos por turnos. En cada turno se puede desplazar una única pieza (la que desee el jugador) a una casilla anexa: arriba, abajo, izquierda o derecha (sin salirse del tablero y sin pisar casillas de un compañero). Si una casilla está ocupada por una pieza del rival se considera un ataque. En caso de ataque las dos piezas declaran públicamente su rango. Si el atacante tiene un rango mayor que la atacada la eliminará y ocupará su lugar en el tablero. Si el atacado es de mayor rango el atacante se eliminará del tablero este último. Y si ambas tienen el mismo rango desaparecerán las dos.

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

Si el juego termina en empate (porque quedan los dos reyes se eliminan entre sí) se considerará perdedor aquel ejército realizó el primer movimiento de la partida. En clase se explica el funcionamiento de los sistemas expertos con ejemplos de reglas para el sistema que se usará y se proporciona un conjunto de reglas básico para controlar los movimientos de los miembros del ejército. Cada alumno lo mejorará en clase con ayuda del profesor si fuera necesario. Posteriormente se organiza una competición eliminatoria entre alumnos. En cada enfrentamiento se simulan tres partidas entre dos ejércitos, cada uno con la inteligencia artificial programada por un alumno. El equipo que gane más partidas pasa a la siguiente ronda. No se admiten modificaciones del módulo de Inteligencia Artificial durante la competición. Además se comprueba que el conjunto de reglas de cada alumno asegure la terminación de la partida. Es decir, que no se den situaciones cíclicas en las que ningún equipo ataque. 3.3. Sistema Se ha desarrollado un entorno que simula el juego. Su nombre es "La batalla del Guadalete", en honor a una de las batallas más importantes que han tenido lugar en la provincia de Cádiz. El sistema se distribuye bajo licencia GNU/GPL y puedes descargarse desde la Forja de la Oficina de Software Libre de la Universidad de Cádiz [7]. El entorno incluye el motor de simulación (control de turnos, realización de movimientos, etc), un entorno gráfico para ver las partidas y un módulo muy básico de inteligencia artificial para cada equipo. La implementación se ha realizado usando bibliotecas y sistemas libres: C/C++ para el programa principal, la biblioteca SDL [8] para la interfaz gráfica y CLIPS [9] para la explotación de sistemas expertos. Al ser todos estos componentes multiplataforma era posible tener el sistema compilado en otros sistemas aparte de GNU/Linux, que fue el que se usó. El sistema muestra un único tablero en el que se ve toda la información de las fichas en el paso actual. Para ello se muestran las fichas con un color distinto según el ejército al que pertenezcan y si el valor de una pieza es desconocido por el rival se muestra entre corchetes (como se ve en la figura 2). Para facilitar la programación por parte de los alumnos y evitar trampas sólo es necesario que

Figura 2: Situación intermedia de una partida modifiquen dos ficheros, uno con la disposición inicial de sus piezas y otro con las reglas. De este modo para realizar la simulación sólo es necesario incorporar esos dos ficheros al sistema instalado para la competición.

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

4.

SISTEMAS EXPERTOS

El diseño de sistemas expertos es una rama de la inteligencia artificial cuya finalidad es realizar sistemas informáticos que simulen la capacidad de decisión de un experto humano en una materia determinada. En la actualidad los sistemas expertos se usan con gran éxito en muchos campos de la ciencia como la medicina o la ingeniería. Este apartado comenta las principales características de los sistemas expertos. 4.1.

Elementos de un sistema experto

Los principales elementos de los sistemas expertos basados en reglas son la base de conocimiento, su motor de inferencia y la interfaz de usuario. La base de conocimiento de un sistema experto es el conjunto formado por todo el conocimiento que tiene el sistema en un momento dado. A partir de este conocimiento, el sistema infiere información, que será, directa o indirectamente, la salida del sistema. En nuestro sistema esta salida es el movimiento que se va a realizar en el turno actual (es decir, la ficha que se desea mover y la casilla adyacente hacia la que se mueve) En los sistemas basados en reglas el conocimiento se almacena en forma de hechos (afirmaciones sobre el sistema) y reglas que permiten inferir información. Nuestro sistema genera automáticamente una serie de hechos para cada equipo y turno. Estos hechos informan de la posición y valor de todas las fichas propias, así como las posiciones de las fichas contrarias con su valor si ha sido descubierto. A estos hechos se le suman todos los hechos que genere el módulo de inteligencia artificial programado por el alumno. El conjunto de reglas está formado por una serie de reglas con prioridades asignadas. En todo caso deben existir una serie de reglas de prioridad baja, que se activarán sólo si no hay una regla más prioritaria. Estas reglas acercar fichas al centro del tablero, de modo que si no se puede hacer un movimiento "inteligente" (entendiendo como tal un movimiento programado por el alumno), por lo menos se haga un movimiento que contribuya a que los ejércitos se enfrenten y la partida acabe. Por último, el motor de inferencia que incorpora el sistema CLIPS es una versión mejorada del algoritmo Rete [10]. Este algoritmo aplica una serie de reglas del tipo si entonces a un conjunto de datos para generar datos nuevos. En la agenda se tienen el conjunto de reglas que se pueden activar en un momento dado, una de las cuales se ejecutará pudiendo

Figura 3: Funcionamiento básico de un sistema experto basado en reglas cambiar la base de conocimiento. En la figura 3 se puede observar la arquitectura del sistema. La interfaz de usuario es el protocolo que permite ejecutar y controlar el sistema experto (ya sea por un humano o por otro sistema). En nuestra caso es una interfaz gráfica como la que se muestra en la figura 1, que permite ver la simulación paso a paso cómodamente.

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

4.2.

Adecuación de los sistemas expertos para la experiencia

Hay algunas características que hacen que los sistemas expertos sean adecuados para desarrollar esta experiencia. Por un lado la creación de reglas es un proceso muy sencillo y fácil de depurar. Por ejemplo, una regla en CLIPS real para el entorno puede ser : (defrule EQUIPO-A::atacar1 (declare (salience 20)) (ficha (equipo “A”) (num ?n1) (pos-x ?x1) (pos-y ?y) (puntos ?p1)) (ficha (equipo “B”) (num ?n2) (pos-x ?x2) (pos-y ?y) (puntos ?p2) (descubierta 1)) (test (and (> ?p1 ?p2) (> ?x1 ?x2))) (tiempo ?t) => (assert (mueve (num ?n1) (mov 2) (tiempo ?t)))) Esta regla en lenguaje natural se leería como "La regla atacar-1, que es del equipo A y tiene una prioridad de 20 se activa si hay una ficha de cada equipo en la mima coordenada y y se que la ficha de mi equipo tiene mayor puntuación que la del contrario. En ese caso la ficha del equipo A hace en movimiento 2 (avanza hacia la contraria)". Por otro lado la inteligencia del sistema aumenta a medida que se aumentan el número de reglas sin ser necesario ningún tipo de mantenimiento o entrenamiento. De modo que se pueden hacer pruebas con el entorno y a medida que se vean imperfecciones añadir reglas para pulir los defectos que se observen. Hay que comentar que en este tipo de sistemas que tienen una cierta complejidad (pues las posibles combinaciones de estados hacen que sea prácticamente imposible controlar todas las situaciones) y conocimiento parcial del entorno no suele existir una solución netamente superior al resto. Es decir, un equipo puede ser que sea superior a casi todos los demás, pero es bastante probable que un equipo bastante pero en el caso medio pueda explotar algún punto débil que tenga y ganarle una partida. Por lo tanto se daban casos de alumnos que probaban sus programas entre sí, pero después al emparejarlos con otros compañeros los resultados no fueran los esperados a tenor de las pruebas previas. Y por último, un aspecto interesante es que si las condiciones de activación de las reglas no son excluyentes (lo que suele ser el caso más normal) en un momento dado puede haber varias reglas candidatas a ejecutarse. En ese caso prevalece la regla de mayor prioridad si la hay. Y si varias de ellas tuvieran la misma prioridad el sistema elegirá una de manera aleatoria, lo que favorece un comportamiento más real al no presentar siempre el mismo comportamiento ante la misma situación. 5.

EVALUACIÓN

5.1. Evaluación del trabajo del alumno La condición que se puso para aprobar esta parte de la asignatura era que el alumno programara un sistema experto capaz de ganar al ejército básico que han mejorado, algo fácil de alcanzar para un alumno que casi es ingeniero teniendo el entorno para hacer las pruebas que deseara. Sin embargo, para sacar nota es necesario eliminar, al menos, a un ejército de otro compañero. De este modo se fomenta la competitividad entre compañeros de clase. Esto provocó que aumentara enormemente la motivación de los alumnos en la actividad, tanto para conseguir nota como para superar a sus compañeros. 5.2. Evaluación de la experiencia

II Jornadas Nacionales de Metodologías ECTS Badajoz, 19, 20 y 21 de septiembre de 2007

La evaluación, tanto como profesor, como por parte de los alumnos ha sido muy positiva. Como profesor he observado un interés muy alto por parte de los alumnos en la experiencia, siendo superior la media de consultas en tutorías o foros a la media de los demás temas. Al final del curso se pasó un cuestionario a los alumnos para que valoraran, entre otros aspectos, la adecuación de la competición como método para aprender sistemas expertos. La valoración media fue de 4,77 sobre 5 puntos de máximo. Por otro lado, los comentarios de los alumnos fueron muy positivos en todo salvo en un pequeño problema que presentó el sistema (que ya ha sido subsanado). Sobre todo destacaban la motivación extra que suponía competición entre compañeros, con los alicientes de que es una competición basada en un trabajo previo, no en rapidez de movimientos o reflejos como suele ser común en los videojuegos. También algunos comentaron que era la primera vez que realizaban un programa y lo veían trabajar sin su intervención, dando una sensación muy reconfortante de creación de un sistema inteligente. También algunos alumnos se interesaron por colaborar con la asignatura el próximo curso como alumno colaborador o realizar un Proyecto Fin de Carrera relacionado con el tema. 6.

TRABAJO FUTURO

Tras los buenos resultados obtenidos y los comentarios recibidos se ha decidido mantener la experiencia para el próximo curso sin grandes cambios. Sin embargo, sí que se puede mejorar el sistema. En concreto se intentará mejorar la interfaz gráfica de modo que sea más sencilla de usar y agradable, ofrecer una biblioteca virtual con los equipos creados por otros alumnos de cursos anteriores y mejorar la integración entre los componentes del sistema (pues actualmente la comunicación entre CLIPS y el programa principal se hace por medio de un fichero de texto) REFERENCIAS [1] Campus Virtual de la Universidad de Cádiz. http://cvirtual.uca.es [2] Herramienta de apoyo al e-learning Moodle. http://www.moodle.org [3] Jesús M. González Barahona y otros. Software libre en la enseñanza informática. "Sobre Software Libre" Editorial Dykinson, ISBN 84-9772-402-X. [4] Boletín Oficial de la Universidad de Cádiz. Declaración institucional del Consejo de Gobierno de la Universidad de Cádiz de apoyo al software libre. Universidad de Cádiz. Año II. No 19 (2004) [5] López, B., Montaner, M., de la Rosa, J. Ll., “Utilización de un simulador de fútbol para enseñar Inteligencia Artificial a Ingenieros”. En actas de las VII Jornadas sobre la Enseñanza Universitaria en Informática (JENUI 2001). Palma de Mallorca, 2001. [6] Información y reglas del juego de mesa Stratego. http://es.wikipedia.org/wiki/Stratego [7] Página oficial del sistema "La batalla del Guadalete" en la Forja de proyectos de la OSLUCA http://softwarelibre.uca.es:8080/Forja/proyectos/guadalete [8] Biblioteca gráfica SDL. http://www.libsdl.org [9] Entorno para la explotación de sistemas expertos CLIPS http://www.ghg.net/clips/CLIPS.html [10] Charles L. Forgy. Rete. "A fast algorithm for the many pattern/many object pattern match problem". Artificial Intelligence n.19, 1982.