AMBIENTE WEB DE ANIMACIÓN E INTERACCIÓN DE IMAGENES VECTORIALES,

ENRIQUECIDAS CON PROPIEDADES FÍSICAS, DEFINIDAS EN SVG

JAVIER ESTEBAN SUPELANO RODRÍGUEZ

Asesora

Claudia Lucía Jiménez Guarín

UNIVERSIDAD DE LOS ANDES

INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ

2003

ISC-2003-1-52

2

CONTENIDO INTRODUCCIÓN 1. OBJETIVOS 1.1 OBJETIVO GENERAL 1.2 OBJETIVOS ESPECÍFICOS 2. MARCO TEÓRICO 2.1 SIMULACIÓN 2.1.1 Definición y generalidades 2.1.2 Aplicaciones y paquetes de software para la simulación 2.2 IMÁGENES VECTORIALES 2.2.1 SWF (Shockwave Flash) 2.2.2 SVG (Scalable Vector Graphics) 2.2.2.1 Descripción y características 2.2.3 SVG vs. SWF 3. DESCRIPCIÓN DEL JUEGO 3.1 ACERCA DE: THE INCREDIBLE MACHINE ® (TIM) 3.2 ACERCA DE: MY INTERNET INCREDIBLE MACHINE (MITIM) 4. ARQUITECTURA DE LA SOLUCIÓN 4.1. ALMACENAMIENTO DE LA INFORMACIÓN 4.2. GENERACIÓN DINÁMICA DE SVG

pág.

5

8

8

8

9

9

9

11

12

13

13

13

15

16

16

21

26

28

29

ISC-2003-1-52

3

4.2.1 Extensible Stylesheet Language (XLS) 4.2.2 JSP y ASP 4.2.3 Velocity 4.3 CONTROL Y MANIPULACIÓN DE LA INFORMACIÓN REPRESENTADA MEDIANTE SVG 4.4. UBICACIÓN DE LOS COMPONENTES SVG QUE PERMITA LA COMUNICACIÓN ENTRE ELLOS 5. DISEÑO COMPUTACIONAL 5.1 ALCANCE DEL SISTEMA 5.2 DESCRIPCIÓN DEL SISTEMA 5.3 USUARIOS DEL SISTEMA 5.4 REQUERIMIENTOS FUNCIONALES 5.4.1 Ubicar ficha 5.4.2 Rotar ficha 5.4.3 Retirar ficha 5.4.4 Deformar ficha 5.4.5 Fijar ficha 5.4.6 Ver ayuda 5.4.7 Cargar nivel 5.4.8 Probar solución 5.5 REQUERIMIENTOS TÉCNICOS 5.8 CLASES 5.8.1 Cliente

29

29

30

30

31

33

33

33

34

34

35

35

35

35

36

36

36

36

36

40

41

ISC-2003-1-52

4

5.8.2 Servidor 6. IMPLEMENTACIÓN 6.1 CONFIGURACIÓN DE DIRECTORIOS 6.2 SERVIDOR 6.2.1 Modulo Juego 6.2.1.1 Repositorio 6.2.1.1.1 TiposFichas.xml 6.2.1.1.2 Niveles.xml 6.2.1.1.3 Relaciones.xml 6.2.1.1.4 Contactos.xml 6.2.1.1.5 Contenedores.xml 6.2.1.2 ParserJuego 6.2.1.3 Fachada 6.2.1.3.1 TableroNivel.vm 6.2.1.3.2 DisponiblesNivel.vm 6.3 CLIENTE 6.3.1 Página JSP 6.3.2 Juego 6.4 PROBLEMAS 6.5 TRABAJO POR HACER 7. CONCLUSIONES BIBLIOGRAFÍA ANEXOS

47

49

49

51

51

51

51

57

65

67

69

69

70

70

72

74

74

74

76

78

80

ISC-2003-1-52

5

INTRODUCCIÓN En los años 60´s dada la posibilidad de un ataque nuclear, los militares estadounidenses vieron seriamente amenazados sus centros de comunicaciones, ante lo cual empezaron a desarrollar un mecanismo de intercambio de información que no estuviese centralizado. En 1968 surge ARPANET, que básicamente consistía en la unión entre sí de cuatro computadores enormes mediante líneas de transmisión de alta velocidad. Con el tiempo, los principales centros de investigación, universidades y centros militares estadounidenses estaban unidos entre sí por una red de 37 nodos. En 1983 se produjo la separación de ARPANET, liberándola finalmente del control ejercido por parte del mando militar americano, y permitiendo su expansión a partir de la unión de nodos pertenecientes a particulares. El desarrollo de esta red a la que tuvieron los particulares la posibilidad de tener acceso y ser miembros, se conoce como Internet. Desde su creación no ha dejado de crecer; cada día, nuevos usuarios se unen a ella, con el fin de obtener y/o compartir cualquier tipo de información. Internet, más que una revolución en el terreno de las comunicaciones, es sin duda una “... revolución cultural y sociológica, ya que por una puerta permite el acceso a información en todas y desde todas las partes del mundo, y por otra parte no está jerarquizada ni gubernatizada sino que ella misma se autogobierna, por lo que todo el mundo tiene acceso a ella sin ninguna restricción” [1]. Ahora, a través de esta red se puede, entre otras cosas, consultar información de todo tipo (texto, imágenes, música, voz, video), de diversos temas (cultura, ciencia, técnica, economía, deportes, sociedad, comercio, etc.) a nivel mundial; intercambiar mensajes y datos con otras personas, por medio del correo electrónico; participar en grupos de interés para tratar temas específicos; publicar información para que sea visible en todo el mundo, a un costo más bajo que usando otros medios; ofrecer y comercializar productos o servicios a un mercado mundial. La posibilidad que brinda esta tecnología en cuanto al acceso e intercambio de información de todo tipo, sin importar su origen, ha producido cambios en la manera de actuar de las personas, las relaciones entre estas, e incluso su reconocimiento. En la actualidad vivimos en un mundo volátil y en constante

ISC-2003-1-52

6

cambio, que obliga a la gente a reconsiderar sus acciones y a obtener nueva información, con el fin de beneficiarse de estos cambios o evitar ser atropellados por los mismos. Buscando que el contenido de las diferentes cosas que se encontraban en Internet expresara un mensaje más claro, surgió la necesidad de representar objetos del mundo real de tal manera que al ser presentados fuesen percibidos casi de la misma manera en que se hace en la realidad. Esto no incluye solo el querer ver formas, colores y demás características asociadas a la imagen, sino también se desea observar la manera como éstas cambian al tener determinados comportamientos o al estar en relación con otros objetos. Teniendo en cuenta que las cosas que se quiere mostrar a través de Internet usualmente son observadas por personas que se encuentran muy lejos, el medio para hacerlas llegar está limitado físicamente y entre menos tiempo tengan las personas que esperar para tener acceso a las primeras es mejor, el tamaño de las representaciones y su facilidad de interpretación deben ser factores críticos a la hora de plantear soluciones. Para esto surgieron grupos de personas dedicadas a inventar y mejorar día a día formatos, estándares y herramientas que permiten crear y mostrar en Internet cosas cuya apariencia y contenido se asemejan a sus características reales. Uno de los numerosos grupos dedicados a la investigación en este campo es el denominado W3C SVG Working Group [www.w3.org/Graphics/SVG], que inventó y se encuentra desarrollando, junto con otros grupos como Kodak [www.kodak.com], Corel [www.corel.com] y Adobe [www.adobe.com/svg/], el estándar SVG (Scalable Vector Graphics) [www.w3.org/Graphics/SVG], que describe gráficas bidimensionales en XML (Extensible Markup Language) [www.w3.org/XML], un lenguaje utilizado para estructurar documentos en Internet. SVG permite que los documentos web sean más pequeños, rápidos e interactivos; da la posibilidad de crear imágenes dinámicamente, haciendo posible que los diseñadores de sitios web se olviden de estar creando nuevas imágenes para actualizar los documentos. Dado que SVG fue creado pensando en Internet, tiene una gran variedad de usos posibles como crear sitios web cuyas gráficas reflejan el contenido de la página, cambiando automáticamente si el contenido cambia; generar gráficas y cuadros a partir de información almacenada en un gran número de fuentes; crear diagramas que pueden ser aumentados en tamaño para ser observados en detalle; crear animación compleja de imágenes. Dadas las posibilidades que ofrece SVG para crear y manipular imágenes que pueden ser vistas a través de Internet, se decidió crear una versión del juego The Incredible Machine® (TIM) [www.incrediblemachine.net] que pueda ser utilizada en

ISC-2003-1-52

7

Internet. TIM es un juego que plantea situaciones en escenarios con características físicas, las cuales se pueden solucionar por medio de la interacción de distintos objetos, también con características físicas, dentro del escenario. En el presente documento se encuentra inicialmente un marco teórico en el que se incluye una revisión general del concepto de simulación física y su implementación en sistemas computacionales, seguido por una descripción detallada de SVG y sus ventajas respecto a soluciones como Flash [www.flash.com]. Posteriormente, se menciona las características de TIM y la versión particular que se va a desarrollar. Finalmente, está la documentación pertinente al diseño y desarrollo del juego.

ISC-2003-1-52

8

1. OBJETIVOS

1.1 OBJETIVO GENERAL

Desarrollar una versión del juego TIM® accesible a través de una página web, utilizando el lenguaje SVG para la descripción de las imágenes correspondientes al juego. 1.2 OBJETIVOS ESPECÍFICOS

§ Crear mecanismos que permitan simular fenómenos físicos que suceden

a objetos representados de alguna manera computacional. § Generar movimiento en imágenes desplegables en una página web,

consecuente con las propiedades físicas específicas del objeto representado por la imagen, y a partir de la interacción con el usuario.

§ Plantear situaciones que puedan ser resueltas a partir de la manipulación de representaciones gráficas de objetos particulares con propiedades físicas y su interacción.

§ Mostrar que SVG es una buena alternativa para el desarrollo de componentes gráficos animados en páginas web.

ISC-2003-1-52

9

2. MARCO TEÓRICO 2.1 SIMULACIÓN En TIM las características y condiciones físicas del escenario son de gran importancia, pues rigen el comportamiento de los principales elementos que se encuentran en juego; de ellas depende la manera en que el jugador trate de resolver el reto propuesto. Para lograr que el comportamiento de los cuerpos dentro del escenario sea similar al real, se utiliza la simulación por computador. 2.1.1 Definición y generalidades La simulación se define como “... un proceso para modelar un sistema y hacer experimentos con el objetivo de obtener información y entender el sistema utilizando un lenguaje computacional.”[Ren 1999] En este caso, el sistema a modelar son los niveles del juego, donde el jugador puede hacer experimentos hasta lograr resolver su objetivo. En cada uno de estos experimentos el jugador obtiene información al ver exactamente como se comportan los elementos del escenario de acuerdo con las condiciones físicas definidas, lo que le permite finalmente superar el reto. Antes de que fuese posible utilizar la simulación era necesario seguir cada uno de los pasos del método científico i para cualquier tipo de investigación. Sin embargo, los pasos de observación y experimentación podían tomar demasiado tiempo, dinero, o ser inclusive peligrosos, obstaculizando el avance de la ciencia. Así, la simulación por computador se desarrolló poco a poco hasta convertirse en la actualidad en una de las herramientas más utilizadas, no solo en el ámbito científico, sino también en sectores como el de los juegos por computador. La simulación tiene como mayor ventaja la posibilidad de facilitar y agilizar el estudio de un sistema particular; su principal desventaja es que los resultados a pesar de ser una aproximación bastante cercana, no necesariamente son precisos. La tarea de llevar a cabo una simulación incluye tres etapas [Cyb 2002]: diseño, ejecución y análisis. i Observación, hipótesis, experimentación.

ISC-2003-1-52

10

En la etapa de diseño es importante: [Cyb 2002]

1. Definir el problema. 2. Identificar el tipo de sistema que se quiere simular. 3. Definir los objetivos (datos de salida). 4. Formular un modelo matemático. 5. Conocer los datos de entrada o valores numéricos necesarios para

determinar la salida de la simulación. Estos pueden ser: - Condiciones iniciales: valores que expresan el estado del sistema al

iniciar la simulación. - Datos determinísticos: son valores conocidos necesarios para

calcular las salidas de la simulación. - Datos probabilísticos: magnitudes numéricas cuyos valores son

inciertos pero necesarios para obtener las salidas de la simulación. 6. Construir un programa en computador para el modelo.

El sistema se clasifica como continuo [Cyb 2002] cuando su estado cambia constantemente en el tiempo y como discreto cuando su estado cambia solo en ciertos puntos del tiempo. Un sistema discreto puede ser a su vez de terminación, cuando en el sistema existen puntos de inicio y fin precisos, o puede ser de no terminación, cuando es un sistema en curso que carece de puntos de inicio y terminación. Un modelo es una abstracción o representación de un sistema con el fin de analizar el comportamiento del mismo que permita buscar su mejor desempeño; o cuando el sistema no existe todavía, para definir su estructura ideal, indicando las relaciones fundamentales entre sus elementos. [Ren 1999]. Dada la heterogeneidad de los sistemas, existen también diferentes tipos de modelo que se pueden clasificar en descriptivos, analógicos, icónicos, matemáticos y procedimentales o de simulación. [Ren 1999]. Modelos descriptivos: consisten de una descripción del sistema a estudiar (esto podría hacerse mediante un diagrama de flujo inclusive).

Modelos analógicos: utilizan ciertas propiedades de un sistema para representar otro.

Modelos icónicos: son una representación a escala aumentada o reducida del sistema real.

ISC-2003-1-52

11

Modelos matemáticos: emplean letras, números y otro tipo de símbolos para representar el sistema de interés y describir la interacción entre las variables.

Modelos procedimentales o de simulación: expresan relaciones dinámicas que se supone existen en la situación real por medio de una serie de operaciones elementales en las variables apropiadas.

Una vez creado el modelo debe ser implementado en un programa computacional a partir del cual puedan realizarse la ejecución y el análisis del mismo. La visualización gráfica del desarrollo de una simulación puede llevarse a cabo bien mediante el desarrollo de herramientas completas, especificas a un área en particular como es el caso de Robot Schema en robótica, [www.cannes.itam.mx/English/research/simulators/asl.html] o utilizando herramientas genéricas como o JView-lite [Sal 1999], en las que se establece un conjunto de parámetros que definen el tipo y desarrollo de la simulación dentro de un marco de trabajo predeterminado. Estas aplicaciones se pueden desarrollar en lenguajes de programación diferentes, siempre y cuando estos tengan librerías para el manejo de gráficas. 2.1.2 Aplicaciones y paquetes de software para la simulación [Ren 1999] La simulación se ha utilizado como herramienta de estudio en muchas ramas de la ciencia y la ingeniería, por lo que muchas aplicaciones especializadas se han desarrollados en áreas particulares como medicina o ingeniería. Algunas aplicaciones que se encuentran actualmente en el mercado son: Promodel: [www.promodel.com] software de simulación y optimización para la manufactura, logística, ensamblaje, balanceo de líneas, justificación de capital, entre otras aplicaciones. Servicemodel: [www.servicemodel.com] software de simulación y optimización para sistemas de servicio. Medmodel: [www.medmodel.com] software de simulación y optimización de hospitales, clínicas y procedimientos de trabajo en ambiente de hospitales. Arena standard edition: [www.arenasimulation.com] es ideal para simular sistemas complejos, operaciones y procesos de fabricación, transporte, logística, y la cadena de suministro, entre otros. Beige Bag Software: [www.beigebag.com] software para la simulación y diseño de circuitos electrónicos.

ISC-2003-1-52

12

Ssesco: [www.ssesco.com] provee simulaciones para problemas metereológicos y del medio ambiente. Ninguno de los ejemplos mencionados permite desarrollar la simulación concerniente al juego, sin embargo seguramente existe una o más aplicaciones que muestren el comportamiento de objetos colisionando inmersos en un ambiente con condiciones que alteren su comportamiento. De todos modos, las aplicaciones que se encuentran son aplicaciones propietarias y diseñadas para funcionar aparte, y no como un modulo utilizable por cualquier aplicación diseñada para funcionar en un navegador de Internet. Lo que se encuentran son librerías de funciones que calculan valores acordes con leyes físicas, en varios lenguajes y que pueden incluirse fácilmente en la aplicación que desee utilizarlas. 2.2 IMÁGENES VECTORIALES La capacidad de incluir contenido audiovisual en las páginas Web fue un gran avance para la popularización y uso de Internet. Con estos medios dentro del contenido, las páginas Web pasaron de ser un medio para divulgaciones científicas a uno masivo de comunicación de cualquier tipo. Las compañías de software iniciaron la búsqueda de la mejor manera de representar imágenes para mostrarlas en un navegador de páginas Web, comenzaron a describir la imagen por pedazos, punto por punto y se obtuvo entonces un formato de imagen conocido como el mapa de bits, que llegó convertirse en el estándar. En la actualidad, los formatos más aceptados son el formato GIF y el JPG. Estos formatos creados para representar imágenes por medio de un mapa de bits han servido por mucho tiempo, presentando ventajas e inconvenientes en la realización de medios electrónicos con contenido visual; sin embargo, están limitados por la carencia de propiedades comunes que permitan la creación de gráficos funcionales y compactos [Mor 2002]. Se considera que un gráfico es una buena representación de un objeto de la realidad cuando cuenta con las siguientes propiedades: [Mor 2002]

• Escalabilidad o posibilidad de aumentar o disminuir la imagen de tamaño sin que su calidad se vea afectada.

• Dinamicidad física, que permite la construcción de verdaderas animaciones mediante la creación de pautas de comportamiento en función del tiempo.

ISC-2003-1-52

13

• Dinamicidad lógica, con la cual un gráfico dejaría de ser una entidad con propiedades fijas e inmutables una vez guardado el archivo. Con ello se consigue crear gráficos inteligentes, capaces de adaptarse a cambios en los valores que los definen.

2.2.1 SWF (Shockwave Flash) En la búsqueda de un formato más completo, la casa de software Macromedia [www.macromedia.com] creó Shockwave Flash (SWF), capaz de crear gráficos escalables, físicamente dinámicos, a los que, adicionalmente, se puede aplicar una gran cantidad de filtros y efectos. A pesar de las grandes ventajas que ofrece el formato SWF y las constantes mejoras que le son incorporadas, no fue desarrollado pensado en Internet, y es considerado tan solo una solución externa al lenguaje estándar de creación de páginas Web, HTML. [Mor 2002]

Flash introduce en su entorno la posibilidad de interaccionar con el usuario. Para ello, Flash invoca un lenguaje de programación llamado Action Script. Orientado a objetos, este lenguaje tiene claras influencias del JavaScript y permite, entre otras muchas cosas, gestionar el relleno de formularios, ejecutar distintas partes de una animación en función de eventos producidos por el usuario, saltar a otras páginas, etc. [Alv recuperado en agosto 2002].

2.2.2 SVG (Scalable Vector Graphics) Pensando en una solución, el consorcio W3C creó SVG [www.w3.org/Graphics/SVG], un lenguaje de marcado basado en XML que busca ser compatible con tecnologías existentes y del futuro como XSLT (Extensible Style Language Transformation) [www.w3.org/TR/xslt], CSS (Cascading Style Sheets) [www.w3.org/Style/CSS], HTML 4.0, XHTML [www.w3.org] y el modelo DOM (Document Object Model). [www.w3.org/DOM]. Dadas las posibilidades que ofrece el estándar SVG para crear y manipular imágenes que pueden ser vistas a través de Internet, se decidió utilizarlo para desarrollar una versión Web del juego TIM. A continuación se describen las características de SVG, así como sus principales ventajas y desventajas. 2.2.2.1 Descripción y características SVG permite representaciones en dos dimensiones y describe tres tipos de objetos gráficos: formas vectoriales, imágenes y texto. Estos objetos pueden estar compuestos, agrupados, y ser modificados a partir de otros previamente creados; además, se les puede aplicar operaciones como transformaciones simples, anidadas, filtros y enmascaramiento, entre otras.

ISC-2003-1-52

14

Las imágenes resultantes pueden ser interactivas y dinámicas y es posible definir las animaciones mediante declaraciones (utilizando elementos propios del contenido de SVG), o por medio de scripts. Una ventaja adicional de SVG es la posibilidad de hacer aplicaciones sofisticadas por medio de un lenguaje suplementario de scripting que accese al SVG Document Object Model (DOM), el cual provee un acceso completo a todos los elementos, atributos y propiedades de los objetos creados. Un amplio conjunto de controladores de eventos como onmouseover puede ser asignado a un objeto grafico SVG. Debido a su compatibilidad con otros estándares para Web, es posible que características como scripting con XHTML y elementos de SVG se presenten simultáneamente en la misma página Web. [W3C 2003] En resumen, las principales características de SVG son: [Mas 2002]

1. Escalabilidad. 2. Tamaño compacto. 3. Editabilidad. 4. Excelente calidad de color manejable con los sistemas estándar de gestión. 5. El archivo de un gráfico SVG es de texto, lo que permite mayor facilidad

para edición y búsquedas. 6. Es compatible con los estándares actuales de la Web y con los futuros. 7. Soporte de hojas de estilo CSS. 8. Puede incluir código que modifica el gráfico dinámicamente. 9. Es un formato extensible: los fabricantes podrán adoptarlo como formato

nativo de sus aplicaciones, añadiendo las características específicas que deseen, pero siempre mantendrá la compatibilidad básica y universal con toda aplicación que reconozca el formato.

10. Admite efectos visuales al hacer clic o mover el ratón, sonido, etiquetas informativas, entre otros.

11. Puede generarse dinámicamente en un servidor Web como respuesta a instrucciones de Java, JavaScript [javascript.com], Perl [ww.perl.com] o XML.

12. SVG puede llegar a simplificar extraordinariamente el conjunto de actividades necesarias para completar una publicación para la Web. En una aplicación única se podrá generar casi todo el contenido de las páginas, y convertirse en un formato universal: todos los programas podrán abrir todo tipo de archivos.

Es tal la aceptación que ha tenido SVG en el medio que hay quienes dicen: “Podemos pues definir el formato SVG como un puente entre diseño gráfico y programación, entre arte y tecnología” [Mor 2002]; y dan definiciones como: “Últimamente, SVG es la manera estándar para describir gráficas e interacciones

ISC-2003-1-52

15

gráficas; es un dialecto particular de la increíble y rica familia de tecnologías XML. Es la manera de codificar una imagen que puede ser transportada como una unidad sencilla o en piezas, una manera de describir interfaces que pueden ser construidas en el momento justo, existiendo tan solo el tiempo que se necesite y convirtiéndose en otra por si misma.” [Cag 2002]. 2.2.3 SVG vs. SWF SVG presenta numerosas ventajas frente a uno de los formatos de imágenes y animación más utilizado actualmente: SWF. El anexo 1 muestra una comparación detallada de los formatos respecto a: extensibilidad y compatibilidad, funcionalidad del plug-in, primitivas gráficas, sistemas de coordenadas y transformaciones, texto, animación, multimedia e interacción y conversión de datos. En general, en cuanto a la extensibilidad y compatibilidad, SVG supera a SWF en aspectos como editabilidad, posibilidad de ser indexado por motores de búsqueda, y de comprobación y validación de sintaxis, mientras el segundo genera archivos de menor tamaño, dado su formato binario; el plug-in de SVG permite ver el código fuente y buscar cadenas de texto, y aunque actualmente es más grande, se espera que en el futuro no sea requerido. En el aspecto grafico, el rango de posibilidades de SVG de primitivas, rellenos, tipos de líneas, imágenes, filtros, entre otros, es mas amplio que el de SWF; adicionalmente, permite diferentes tipos de transformaciones y en unidades diferentes, características que no se encuentran en el formato de Macromedia. En cuanto a texto, las principales ventajas de SVG sobre SWF son la rotación de grabados simples y la internacionalización. La animación, por otro lado, es muy similar en ambos formatos, siendo superior en SWF dada la posibilidad de enlazar películas Quicktime y tener incluido sonidoii, ventaja que será historia dentro de poco tiempo, cuando la segunda implementación de SVG sea un hecho. A pesar de las ventajas que pueda tener un formato frente al otro, en cualquier de los dos se podría desarrollar el juego MITIM. Se eligió SVG para explorar y descubrir las bondades que ofrece el formato para el desarrollo de este tipo de aplicaciones realizadas ampliamente en Flash.

ii SVG permite sonido, pero este no hace parte de la especificación.

ISC-2003-1-52

16

3. DESCRIPCIÓN DEL JUEGO 3.1 ACERCA DE: THE INCREDIBLE MACHINE ® (TIM) [www.incrediblemachine.net] The Incredible Machine es un juego que requiere razonamiento lógico e intuición para lograr armar sistemas mecánicos que solucionen un reto propuesto. Es una especie de rompecabezas en que las piezas son objetos con características físicas y comportamientos de acción y reacción específicos, al igual que el “tablero” donde se arman. The Incredible Machine fue creado en 1993 por Sierra [www.sierra.com] y su éxito fue tan grande, que 6 versiones se desarrollaron posteriormente, cuyas gráficas, escenarios y número de partes disponibles aumentaron en cantidad y calidad. La segunda versión, Sid & Al's Incredible Toons salió en el mismo año. En esta ocasión se utilizaron personajes de caricaturas (Sid y Al) y el objetivo consiste en lastimar al otro personaje utilizando los elementos disponibles. Incluye 100 retos, modo para dos jugadores y la posibilidad de guardar en “perfiles de jugador” los avances realizados. En 1994 se lanzó al mercado The Incredible Machine 2, como tercera parte en la serie, con algunas mejoras gráficas a la versión original y nuevos niveles por resolver. En el año siguiente apareció The Incredible Machine 3, en el que se incluyen nuevos elementos y la posibilidad de jugar con tres o más jugadores (multiplayer). The Even More Incredible Machine, disponible a partir de 1996 conserva las mismas características de las versiones anteriores, con excepción de ligeros cambios en las gráficas y elementos. La siguiente aparición de este juego, Return of the Incredible Machine: contraptions sucedió 4 años después, con 250 niveles y algunos elementos adicionales; finalmente, The Incredible Machine: even more contraptions, salió en el 2001, adicionando nuevos elementos y mejorando la calidad de las graficas. En general, la dinámica del juego es la siguiente:

• El jugador selecciona qué nivel quiere solucionar. • Se muestra el escenario, que consta de algunos elementos fijos que

interactúan con las partes que ubique el jugador. • Se muestra el conjunto de fichas que el jugador tiene disponible para

solucionar el nivel.

ISC-2003-1-52

17

• El jugador ubica las partes que estime necesarias en el escenario en el lugar que considere pertinente.

• El jugador indica que ya terminó de ubicar las fichas necesarias; enseguida, se muestra la interacción y se verifica si el resultado resuelve el nivel.

• Si el reto no se resolvió, el jugador tiene la posibilidad de reubicar las partes o rendirse.

Para la solución de los diferentes niveles creados en TIM, existen varios tipos de fichas, entre ellos están:

• Motores Motor de ratón

Hay un ratón encerrado en una jaula, que al ser golpeada por la parte superior o inferior, comienza a correr sobre una rueda. Esta rueda puede ser conectada por medio de una Correa a una Cinta transportadora y activarla.

Cinta transportadora

Sirve para mover objetos que se encuentran sobre ella. Se activa al unirla con una correa a objetos que roten y produzcan energía o movimiento como el motor de ratón.

Correa

Se utiliza para unir dos objetos que rotan. Cuando uno de los dos se mueve, el otro se mueve en la misma dirección.

• Paredes Muro horizontal

Secuencia de ladrillos que impide el paso de objetos a través de él. Se encuentra en posición horizontal.

Muro Vertical

Secuencia de ladrillos que impide el paso de objetos a través de él. Se encuentra en posición vertical

Muro inclinado

Secuencia de ladrillos que impide el paso de objetos a través de él. Se encuentra en inclinado 45 grados.

ISC-2003-1-52

18

• Móviles Bomba

Globo lleno de helio que se eleva una vez se inicia la jugada. Se puede atar cuerdas a el.

Bola de bolos

Es muy pesada y no rebota.

Balón de fútbol

Es medianamente pesado y rebota un poco.

• Misceláneos

Sube y baja

Sirve para impulsar algún objeto ubicado en uno de los extremos al ser golpeado el otro por otro objeto, o al ser jalados por una Cuerda. Al unirle una cuerda a algún extremo se pueden detener objetos como Globos.

Cuerda

Une objetos, sostiene cosas en el aire o eleva objetos.

Todas las fichas que hacen parte del juego tienen atributos físicos y comportamientos definidos cuando interactúan con los demás, los atributos más importantes, con que cuentan todas las fichas del juego son: la capacidad o no de ser expandido (de ser deformado en alguna dirección), si es afectado o no por la gravedad, y el numero de veces que puede ser rotado sobre un eje definido para la ficha en particular. La tabla 1 muestra para cada objeto del juego los objetos con que interactúa (objetos que se ven afectados por el comportamiento de dicho objeto y/o los que colisionan con éste), si es afectado o no por la gravedad (G), si es expandible (EXP.) y los grados de libertad que tiene (número de posiciones diferentes en que puede ubicarse el objeto) (° LIB.).

ISC-2003-1-52

19

Tabla 1. Características principales de las fichas

OBJETO INTERACTÚA CON G EXP. ° LIB. Motor de ratón Correa, Bola de bolos, Balón de

fútbol, Bomba

NO NO 2

Cinta transportadora

Correa, Bola de bolos, Balón de fútbol.

NO SI 1

Correa Motor de ratón, Cinta transportadora.

NO SI 1

Sube y baja Cuerda, Bola de bolos, Balón de fútbol, Bomba.

NO NO 2

Cuerda Bomba, Sube y baja, Polea.

NO SI 1

Muro Horizontal

Bomba, Bola de bolos, Balón de fútbol.

NO SI 2

Muro Vertical Bomba, Bola de bolos, Balón de fútbol.

NO SI 2

Muro Inclinado Bomba, Bola de bolos, Balón de fútbol.

NO SI 2

Bola de bolos Motor de ratón, Sube y baja, Muro, Rampa, Cinta transportadora.

SI

NO

1

Balón de fútbol Motor de ratón, Sube y baja, Muro, Rampa, Cinta transportadora

SI

NO

1

Resorte Bomba, Bola de bolos, Balón de fútbol.

NO NO 2

Polea Cuerda. NO NO 2 A continuación se muestra un ejemplo completo tomado de la primera versión del juego para complementar la descripción de este.

ISC-2003-1-52

20

1. Escoger el nivel a solucionar.

Imagen 1. Menú de niveles disponibles de TIM

Tomado del demo de TIM 1

2. Una vez seleccionado el nivel 5, se muestra el escenario junto con las fichas con las que se puede resolver.

Imagen 2. Vista inicial del nivel de TIM

Tomado del demo de TIM 1

ISC-2003-1-52

21

Las fichas que se encuentran en el lado derecho son las disponibles para tratar de solucionar el nivel. En el cuadro grande está el escenario; los objetos que allí aparecen no se pueden mover ni expandir. 3. Se ubican fichas y se prueba que el sistema formado solucione o no el nivel.

Imagen 3. Vista intermedia del nivel de TIM

Tomado del demo de TIM 1

3.2 ACERCA DE: MY INTERNET INCREDIBLE MACHINE (MITIM) My Internet Incredible Machine es una versión del juego The Incredible Machine para ser jugada por Internet, desarrollado como objetivo de este trabajo. Al ser una versión de TIM, MITIM presenta similitudes, y diferencias con el juego original. El propósito del juego es el mismo: armar sistemas que cumplan cierto objetivo, a través de la interacción de objetos con propiedades físicas. En MITIM los objetos que hacen parte del juego y con los que se resuelven los retos de los diferentes niveles del mismo, también interactúan entre sí dependiendo de las características físicas asociadas a ellos. La complejidad y el gran número de opciones que presenta TIM en todas sus versiones, impiden que se desarrolle el juego para Internet, en un plazo de seis meses, con el total de la funcionalidad.

ISC-2003-1-52

22

De las opciones para el jugador presentes en las versiones de TIM, el juego desarrollado presenta solo la posibilidad de solucionar un nivel, es decir, escoger un nivel, entre una lista de posibles, y resolverlo con las fichas dadas. Para resolver los niveles se cuenta con fichas que pertenecen a tres tipos de fichas, estos son:

• Motores: Las fichas pertenecientes a este tipo, son capaces de impulsar otras a una determinada velocidad. Tienen un estado (activo o inactivo) que permite impulsar los objetos que estén en contacto con la ficha. Dos ejemplos de estas fichas son:

Motor Ratón

Motor impulsado por un ratón, su estado cambia a activo cuando es golpeado por una ficha móvil en cualquiera de sus paredes. Activa e imprime la velocidad definida para el a el objeto con el que este en contacto.

Banda de Transporte

Ficha que mueve horizontalmente y en la dirección en la que este activado, lo objetos móviles que se encuentren sobre el.

• Móviles: Son fichas afectadas por la gravedad y que se mueven por todo el tablero dependiendo de las condiciones físicas del ambiente y la velocidad horizontal y vertical que han alcanzado. Entre estas están:

Balón Baloncesto

Representa un balón de baloncesto, las propiedades físicas asociadas a esta, hacen que rebote harto y acelere con rapidez.

Bola Tenis

Representando una pelota de tenis, BolaTenis rebota de acuerdo a sus características físicas.

ISC-2003-1-52

23

• Paredes: Las paredes son fichas que se fijan al tablero y dan dirección a las fichas móviles que rueden y choquen en ellas.

Muro Horizontal

Muro sólido, con un coeficiente de fricción alto que puede rotarse para convertirlo en un muro vertical.

El conjunto de fichas existentes hasta el momento en el juego es pequeño, pero la facilidad para agregar nuevas fichas de cualquiera de los tipos de ficha anteriormente mencionados es grande. La dinámica del juego para desarrollar un nivel es la misma que la de TIM, lo único que varía es la interacción y la retroalimentación con el usuario. Existen tres tipos de fichas, toda ficha tiene unas propiedades comunes a todas las fichas del juego, y otras especiales que dependen del tipo de ficha al que pertenezca. Las propiedades que tienen en común todas las fichas son: § Nombre (debe ser único, no pueden existir dos fichas con el mismo

nombre) § Centro (coordenada (x,y) donde se ubica el eje de rotación de la ficha) § Numero de rotaciones posibles § Puntos de anclaje (se refiere al numero de puntos que deben indicarse en

el tablero para ubicar una ficha ) § Área envolvente (área que envuelve la ficha, la cual no puede estar

intersectada con la de otra ficha) § Deformaciones (indica en que direcciones y cuantas veces puede

deformarse una ficha después de ubicarla en el tablero) § Magnitud deformación (porcentaje del tamaño inicial en que la ficha crece

o disminuye al momento de deformarse) A continuación se muestra un ejemplo completo tomado de la primera versión del juego para complementar la descripción de este.

ISC-2003-1-52

24

1. Escoger el nivel a solucionar. Imagen 4. Menú de niveles disponibles de MITIM

2. Una vez seleccionado el nivel 5, se muestra el escenario junto con las fichas con las que se puede resolver. Imagen 5. Vista inicial del nivel de MITIM

ISC-2003-1-52

25

Las fichas que se encuentran en el lado derecho son las disponibles para tratar de solucionar el nivel. En el cuadro grande está el escenario; los objetos que allí aparecen no se pueden mover ni expandir. 3. Se ubican fichas y se prueba que el sistema formado solucione o no el nivel. Imagen 6. Vista intermedia del nivel de MITIM

4. Al probar la solución del nivel, una vez terminada la interacción de las fichas dentro del tablero, aparecerá una pequeña ventana en el centro de la pantalla con un mensaje de felicitación si se logró el objetivo, o se informa el número de fichas que no alcanzaron el estado esperado.

ISC-2003-1-52

26

4. ARQUITECTURA DE LA SOLUCIÓN Lo que el juego ha desarrollar hace a grosso modo es mostrar imágenes sobre un navegador de Internet. Imágenes en movimiento cuya forma y posición cambian como respuesta a la interacción con el usuario. Ahora bien, la definición de esas imágenes y el comportamiento de las mismas dependen de unos valores depositados en algún lugar, asequible a alguien que sepa como interpretar esos datos y generar imágenes dinámicas desplegables por un navegador de Internet. Además, una vez mostradas las imágenes debe existir quien las modifique de acuerdo a la interacción con el usuario. El diagrama 1 muestra las diferentes partes involucradas y necesarias para poder cumplir con el objetivo del juego, y la relación entre ellas. Diagrama 1. Componentes básicos Cada una de las figuras que componen el diagrama 1 son los componentes esenciales el juego MITIM. Cada uno de ellos cumple una tarea específica. Todos excepto el Navegador de Internet deben desarrollarse para el juego. Los valores se encuentran almacenados en un repositorio de datos. El Interprete de datos genera imágenes vectoriales desplegables por el Navegador de Internet; estas imágenes son vectoriales debido a las características requeridas

interpreta genera muestra

notifica

modifica

Interprete de datos

Imágenes dinámicas

Controlador de imagen

Navegador Internet valores

juega

ISC-2003-1-52

27

para el juego y van a ser definidas en el lenguaje SVG porque se estableció desde un comienzo que las imágenes del juego se iban a realizar de esa manera. El Controlador de imagen debe ser capaz de manipular esas imágenes SVG y comunicarse con el Navegador de Internet con el fin de recibir las ordenes que el jugador imparta con respecto a las imágenes mostradas. El comportamiento del juego puede verse como la interacción entre alguien a un lado que sabe interpretar datos y crear imágenes, y al otro lado, alguien que muestra y manipula las imágenes previamente creadas, funciona como un sistema conformado por un productor y un consumidor, en otras palabras: un servidor y un cliente. Este es el esquema del juego, o más bien, la arquitectura en la que se basa. Una arquitectura cliente-servidor que involucra los componentes del diagrama 1. Diagrama 2. Ubicación de los componentes básicos

Cliente

Servidor

Interprete de datos

Imágenes dinámicas

Controlador de imagen

Navegador Internet

valores

interpreta

solicita

muestra

notifica modifica

genera

ISC-2003-1-52

28

El diagrama 2 ubica los componentes declarados en el diagrama 1 al lado que corresponden dentro de la arquitectura de la aplicación, y muestra la nueva relación existente entre el cliente y el servidor. Esta relación corresponde a la petición por parte del cliente al servidor para que genere las imágenes que el primero debe mostrar y manipular. El desarrollo de los componentes necesarios de MITIM requiere que se defina la manera y los recursos para manejar cuatro aspectos principales: 1) almacenamiento de información; 2) generación de archivos SVG a partir de datos almacenados; 3) control y manipulación del estado de la información representada mediante SVG; y 4) medio por el cual los componentes SVG puedan comunicarse entre ellos. A continuación se analizan las soluciones tecnológicas existentes para cada uno de los aspectos mencionados. 4.1. ALMACENAMIENTO DE LA INFORMACIÓN El servidor tiene como finalidad generar los archivos SVG que serán desplegados posteriormente; para esto, necesita almacenar y consultar información relacionada con los niveles, las fichas, y en general, con la configuración del juego. Existen dos maneras de hacer esto, mediante una base de datos o utilizando archivos de configuración. Las bases de datos son adecuadas cuando se manejan volúmenes grandes de información o si es necesario hacer ediciones frecuentes de datos y se requiera realizar búsquedas de manera eficiente; en este caso, el volumen de información no es mucho, los datos no cambian casi, así que seria más el espacio y tiempo perdido en la implementación de un puente y una fachada para la base de datos, que la utilidad de la misma. Por otro lado, los archivos de configuración pueden ser binarios, de texto o XML, entre otros. Para los primeros se requiere implementar en el servidor las clases necesarias para llevar el estado del juego, para luego serializar los objetos. Esta opción no es muy valida para el caso, ya que el estado del juego se va a llevar en el cliente, dado el alto costo en rendimiento que acarrearía la notificación de cada cambio del juego al servidor. Los archivos de texto son una posibilidad dado su poco peso y facilidad de edición; sin embargo, los archivos XML son igualmente editables, son también de texto, por lo cual hereda las anteriores características, y además tienen dos ventajas fundamentales: facilitan la organización de la información y tienen un formato

ISC-2003-1-52

29

definido standard interpretable por clases de lenguajes como Java y paquetes Microsoft. Por esto, se utilizaran archivos XML para la configuración del juego, y de esta manera se define el desarrollo del componente valores del diagrama 1. 4.2. GENERACIÓN DINÁMICA DE SVG Una vez el servidor tiene disponible la información necesaria, debe generar los archivos SVG que representan el estado del juego. Existen tres tecnologías que facilitan este proceso: XSLT [www.w3.org/TR/xslt], JSP [java.sun.com/products/jsp] y Velocity [jakarta.apache.org/velocity]. 4.2.1 Extensible Stylesheet Language (XSL) XSL es un lenguaje para representar hojas de estilo. Consta de tres partes [W3C 1999]: XSL Transformation (XSLT), que transforma documentos XML; XML Path Language (XPath) [www.w3.org/TR/xpath], utilizado para tener acceso o referencias a partes de un documento XML; y, XSL Formatting Objects, un vocabulario XML para especificar semánticas de formato. El proceso de transformación de un documento XML en otro involucra el documento fuente, el final y el que define las reglas de la transformación, es decir, la hoja de estilo XSLT. Cada hoja de estilo consta de plantillas que definen la manera en que aparecerá el contenido en el documento. Al ejecutar el procesador XSLT se construye un árbol de estructura del documento XML, se lee la hoja de estilo y se genera, a partir del árbol inicial, un árbol de salida correspondiente a las especificaciones de la hoja de estilo. 4.2.2 JSP y ASP La tecnología JSP es una especificación desarrollada por Sun Microsystems como alternativa a Active Server Pages (ASP) de Microsoft, capaz de generar dinámicamente el contenido de aplicaciones Web. Las páginas hechas con JSP o ASP contienen código Java o Visual Basic, respectivamente, embebido dentro del código HTML. JSP es otra de las posibilidades para crear los componentes SVG dinámicamente. A través de clases o JavaBeans se puede acceder a la información ubicada en el repositorio y obtenerla para incluirla en los archivos SVG. Es posible construir archivos XML dinámicamente mediante el uso de alguna de estas dos tecnologías.

ISC-2003-1-52

30

4.2.3 Velocity Herramienta que permite incorporar contenido dinámico en una página Web [Apa 1999], separando el código de la plantilla de acuerdo con el modelo MVC. Puede utilizarse para crear páginas Web, SQL y cualquier otro tipo de salida de plantillas. Cualquier aplicación de Velocity requiere un archivo con extensión .vm que describe la plantilla en la que se define el formato de salida y una clase en Java que define y organiza los datos que serán adicionados al contexto. Finalmente, se hace un llamado al método merge de Velocity, cuyo valor de retorno es de tipo writer. En este caso, el valor retornado es utilizado para generar el archivo SVG. Las tres alternativas son viables en el caso de MITIM, pero Velocity se escogió como la mejor solución para el desarrollo del componente Interprete de datos del diagrama 1, porque permite de una manera más sencilla, a través del lenguaje Java, la generación de los archivos SVG; XSLT utiliza código más elaborado [Boe

2001], mientras JSP es mas lento, dado que solicita al servidor cada elemento de manera independiente. 4.3 CONTROL Y MANIPULACIÓN DE LA INFORMACIÓN REPRESENTADA MEDIANTE SVG Una vez generados los componentes SVG de acuerdo con la información del juego y la petición del cliente, es necesario poder acceder a los elementos definidos en ese archivo para controlar el estado y la dinámica del juego. El formato SVG soporta el acceso al SVG Document Object Model (DOM), el cual provee un acceso completo a todos los elementos, atributos y propiedades de los objetos creados, mediante lenguajes de scripting como JavaScript, VBscript o EcmaScript. Cualquiera de estos lenguajes de scripting, como ya se dijo, tienen la capacidad de obtener y manipular los elementos contenidos en el documento, con lo cual podría mover, cambiar la apariencia y cualquier otro atributo de cualquier elemento definido en SVG, entre otras cosas. Para el desarrollo del Controlador de imagen (ver Diagrama 1) se tomó la decisión de utilizar JavaScript, ya que es un lenguaje altamente conocido con una sintaxis clara y por la experiencia que se ha tenido trabajando con este lenguaje.

ISC-2003-1-52

31

4.4. UBICACIÓN DE LOS COMPONENTES SVG QUE PERMITA LA COMUNICACIÓN ENTRE ELLOS Los archivos SVG pueden ser cargados y visualizados como elementos independientes, o pueden hacer parte de otros documentos como un HTML o JSP, entre otros. La manera como se incluyen los SVG dentro de otro documento es a través de los nodos que permitan embeber objetos y componentes, propios de la tecnología o lenguaje del documento. HTML, mediante la etiqueta <embed>, permite incluir objetos externos y especificados con otro estándar definido al de HTML; entre otras cosas pueden incluirse componentes gráficos SVG. Al estar embebido el SVG dentro del HTML, este pasa a estar disponible en el documento de la página web (HTML), siendo así, asequible por JavaScript. Mediante la etiqueta <embed> y una función hecha en algún lenguaje de scripting que accese los elementos del documento, pueden pasarse parámetros de inicialización al componente incluido, o acceder externamente al documento de ese mismo componente. Al incluir varios archivos SVG en una misma ventana, estos pueden comunicarse a través de ellos, por medio de las funciones propias al objeto window, alcanzable por todos los que están en la misma ventana. De esta manera pueden tenerse procesos de comunicación entre HTML y SVG, o entre un SVG y otro; sin embargo esto no funciona en todos los navegadores existentes, de ahí el requerimiento técnico de visualización a través de Internet Explorer 5 en adelante. Ya identificada la manera y la tecnología con la que se va a desarrollar la aplicación del juego, encontrará a continuación el diagrama final de arquitectura del juego. El diagrama 3 muestra la arquitectura del juego con las tecnologías utilizadas para cada uno de los módulos descritos en el diagrama 1.

ISC-2003-1-52

32

Diagrama 3. Diagrama de arquitectura Servidor: En el servidor, el Juego se encarga de recibir las peticiones del cliente para generar los componentes gráficos (SVG) que visualizan las partes del juego (MITIM). Para esto, consulta en el Repositorio (conjunto de archivos XML) la información relacionada con el estado y partes del juego, y en particular, el del nivel que se requiere. Los componentes SVG del juego son generados por Juego mediante el uso del paquete de clases de Velocity. Cliente: En el cliente, Juego mantiene el estado del nivel que se esta visualizando, IEXPLORER es el navegador en el que la aplicación se ejecuta, para esto hace uso del plug-in ADOBE SVG VIEWER V3.

Cliente

Servidor

Repositorio

Juego

Velocity

ADOBE SVG VIEWER V3 IEXPLORER

Juego

SVG

ISC-2003-1-52

33

5. DISEÑO COMPUTACIONAL 5.1 ALCANCE DEL SISTEMA La aplicación únicamente permite que un jugador interactúe en el juego, es decir no es un juego multi-jugador. No existe límite de tiempo para que el jugador ubique las fichas que estime necesarias para resolver el nivel. Las fichas y el número de estas que se tiene para resolver un nivel depende del mismo, y no pueden ser modificados cuando se esté resolviendo. El juego contará con algunos niveles listos para ser resueltos. El jugador puede revisar si la solución sugerida es correcta las veces que quiera, sin que le sean retiradas las fichas de los lugares en las que las ubicó. 5.2 DESCRIPCIÓN DEL SISTEMA El objetivo específico del sistema es lograr que cualquier persona aprenda a jugar a través de Internet un juego donde se vea obligada a pensar en la interacción de objetos con propiedades físicas, para lograr construir una máquina que logre un propósito dado. El sistema se compone de dos partes: la representación de objetos con propiedades físicas y un estado de interacción entre estos, conocido como objetivo, y la visualización a través de una página web, en tiempo real del comportamiento presentado a raíz de la interacción de los objetos. El sistema es desarrollado como uno de tipo cliente-servidor, donde el servidor es el encargado de administrar la información relacionada con los niveles y las fichas disponibles en el juego.

Una vez el usuario ingrese al juego, sucederá lo siguiente:

1. Si el usuario decide iniciar un nuevo nivel, se le pedirá que seleccione de una lista el nombre del que desea jugar. Luego, en la barra de herramientas se

ISC-2003-1-52

34

mostrará las fichas y la cantidad que tiene disponible para alcanzar el objetivo, y en el tablero aparecerán las fichas fijas que componen el nivel. El jugador inicia ubicando una o más fichas, de las que tiene disponibles, dentro del tablero, después verifica si la ubicación de esa(s) ficha(s) hacen posible que se solucione el nivel. En caso de que no sea solucionado, se permitirá al usuario acomodar nuevamente las fichas disponibles ubicadas anteriormente, en el lugar que desee para intentarlo de nuevo; si encuentra la solución, se mostrara un mensaje de felicitación y se esperará a que el jugador seleccione alguna otra opción de las que se encuentran en la barra de menú. 2. En caso de querer ver la ayuda del juego, se abrirá una nueva ventana con la información correspondiente al juego. En cualquier momento, incluso después de iniciado un nivel, el jugador podrá cancelarlo y comenzar uno nuevo; igualmente mirar la ayuda del juego. Al ubicar una ficha en el tablero, si esta lo permite, podrá rotarse y/o deformarse y el resultado de estas operaciones dependerá de la ficha en particular. Cada ficha se deforma de manera independiente y la rotación se hace sobre un eje específico a cada ficha. 5.3 USUARIOS DEL SISTEMA El único usuario de la aplicación será la persona que se interese en jugar, que tenga capacidad de leer e identificar relaciones de acción y reacción entre objetos.

La ampliación de las opciones del juego, de nivel o fichas, se hará a través de los archivos XML que administra la aplicación del servidor. 5.4 REQUERIMIENTOS FUNCIONALES El diagrama 4 muestra la funcionalidad disponible para el único usuario del juego: el jugador.

ISC-2003-1-52

35

Diagrama 4. Diagrama casos de uso A continuación se menciona la descripción de los casos de uso del usuario del juego, si se desea consultar la información completa de cada uno, puede hacerlo en el anexo 2: 5.4.1 Ubicar ficha Se ubica en el tablero una ficha para formar parte de la solución sugerida por el jugador al nivel. 5.4.2 Rotar ficha La ficha se rota en el eje de rotación específico para esta, con respecto al centro de la ficha un ángulo recibido como entrada. 5.4.3 Retirar ficha Se retira la ficha ubicada en el tablero para que no interfiera en la solución del nivel. 5.4.4 Deformar ficha Se estira o se encoge una ficha hacia un lado.

UBICAR FICHA CARGAR NIVEL

VER AYUDA ROTAR FICHA

DEFORMAR FICHA

RETIRAR FICHA FIJAR FICHA

PROBAR SOLUCIÓN

ISC-2003-1-52

36

5.4.5 Fijar ficha Se establece que la ficha indicada no podrá moverse dentro del tablero cuando quiera solucionarse el nivel al que pertenece. 5.4.6 Ver ayuda La ayuda se abrirá para dar información acerca del juego: como jugar, partes del juego, desarrollo del juego, entre otros. 5.4.7 Cargar nivel Se desea tratar de resolver alguno de los niveles almacenados en el juego. Para esto deberá seleccionar el nombre de una lista de disponibles. 5.4.8 Probar solución Se revisa si la interacción de las fichas dentro del tablero las lleva a un estado claves tal que correspondan a la solución del nivel. 5.5 REQUERIMIENTOS TÉCNICOS La siguiente es la lista de requerimientos técnicos: § Herramientas y desarrollo

o Plataforma de desarrollo o Herramientas de desarrollo

§ Visualización o Barra de menú o Distribución de pantalla o Visualización o Retroalimentación o Manejo de ventanas o Visualización de una jugada o Metáfora del juego o Pagina principal

§ Interacción o Interacción

§ Operación o Sistema de ayuda

§ Desempeño o Volumen y manejo de datos

§ Robustez y recuperación de error o Manejo de error

§ Mantenibilidad

ISC-2003-1-52

37

o Metodología de diseño o Tipo de documentación o Documentos de diseño

A continuación se encuentra especificado los requerimientos mas importantes en cuanto a visualización y el requerimiento de interacción. La especificación de los otros requerimientos, presentes en la lista, se encuentran en el anexo 3. Tabla 2. Requerimiento técnico de Distribución de pantalla Identificador: rt5

Nombre: DISTRIBUCIÓN DE PANTALLA

DESCRIPCIÓN: EN LA PANTALLA DE JUEGO SE DIFERENCIARÁN CUATRO SECCIONES, INCLUYENDO LA BARRA DE MENÚ : BARRA DE MENÚ: PERMANECERÁ VISIBLE PERMANENTEMENTE, EN LA PARTE SUPERIOR DE LA PANTALLA. TABLERO : MOSTRARÁ EL TABLERO DE JUEGO. SOBRE ESTA ÁREA ES QUE SE DESARROLLA EL NIVEL BARRA DE HERRAMIENTAS: EN ESTA SE ENCUENTRA LAS FICHAS PARA RESOLVER EL NIVEL BARRA DE ESTADO: DESPLIEGA LA INFORMACIÓN NECESARIA PARA QUE EL JUGADOR CONTINÚE EL JUEGO. (MODO DE JUGAR, EL PROPÓSITO DEL NIVEL, ERRORES). Criterios de aceptación: LA DISTRIBUCIÓN DEL JUEGO EN LA PANTALLA SERÁ BARRA DE MENÚ TABLERO BARRA DE HERRAMIENTAS BARRA DE ESTADO

ISC-2003-1-52

38

Tabla 3. Requerimiento técnico de Retroalimentación Identificador: rt6

Nombre: RETROALIMENTACIÓN

DESCRIPCIÓN: LA RETROALIMENTACIÓN (MENSAJES DE ERROR O DEL SISTEMA) SE HARÁ POR MEDIO DE LA BARRA DE ESTADO; A TRAVÉS DE ESTA SE DESPLIEGAN MENSAJES QUE DESCRIBEN QUE PASÓ; EN CASO DE SER UN ERROR SE DARÁ LA OPCIÓN DE REINTENTAR (SI ES POSIBLE) O CANCELAR LA OPERACIÓN. Criterios de aceptación: CUALQUIER ERROR EN EL PROCEDIMIENTO DE ALGUNA ACCIÓN POR PARTE DEL JUGADOR, SE INFORMA EN LA BARRA DE ESTADO.

Tabla 4. Requerimiento técnico de Interacción Identificador: rt11

Nombre: INTERACCIÓN

DESCRIPCIÓN: TODA LA INTERACCIÓN SERÁ A TRAVÉS DEL MOUSE (RATÓN), EXCEPTO POR LA OPCIÓN DE CREAR NIVEL, DONDE TENDRÁ QUE INGRESAR EL NOMBRE Y OBJETIVO DEL MISMO. PARA SELECCIONAR ALGUNA DE LAS OPCIONES QUE TRAE EL JUEGO, SE SELECCIONA LA IMAGEN CORRESPONDIENTE EN LA BARRA DE MENÚ O EN EL TABLERO. PARA UBICAR UNA FICHA DENTRO DEL TABLERO, EL USUARIO DEBERÁ PRIMERO HACER CLICK EN LA FICHA QUE SE ENCUENTRA EN LA BARRA DE HERRAMIENTAS Y, POSTERIORMENTE, HACER CLICK EN EL LUGAR DEL TABLERO DONDE QUIERA DEJARLA. PARA ROTAR, SI LA FICHA LO PERMITE, DEBERÁ UBICAR EL MOUSE SOBRE LA IMAGEN Y LUEGO SELECCIONAR EL BOTÓN DE ROTAR QUE APARECERÁ AL LADO. EL MISMO PROCEDIMIENTO SE REALIZA PARA DEFORMAR LA FICHA EN ALGUNO DE LOS SENTIDOS QUE PERMITA. PARA RETIRAR UNA FICHA DEL TABLERO, DEBERÁ SELECCIONARSE Y LUEGO OPRIMIR EL BOTÓN IZQUIERDO DEL RATÓN EN LA BARRA DE HERRAMIENTAS. Criterios de aceptación: TODAS LAS OPCIONES OFRECIDAS AL USUARIO SON ALCANZABLES POR ÉSTE UTILIZANDO UN CLICK EN EL MOUSE O, EN LOS CASOS ESPECIALES, MEDIANTE EL TECLADO.

ISC-2003-1-52

39

Tabla 5. Requerimiento técnico de Visualización de una jugada Identificador: rt8

Nombre: VISUALIZACIÓN DE UNA JUGADA

DESCRIPCIÓN: DESPUÉS DE QUE HA SIDO MOSTRADO EL TABLERO Y SE HA INFORMADO AL JUGADOR EL OBJETIVO DEL NIVEL, ENTONCES: 1. SELECCIONA CUALQUIERA DE LAS FICHAS MOSTRADAS EN LA BARRA DE HERRAMIENTAS. SI SOLO HA SIDO ASIGNADA UNA OCURRENCIA DE ESA FICHA PARA FORMAR ESE NIVEL, LA FICHA DESAPARECE DE LA BARRA DE HERRAMIENTAS; DE LO CONTRARIO, EL NÚMERO QUE INDICA LA CANTIDAD DE FICHAS DISMINUYE EN UNO. 2. AL SELECCIONAR ALGUNA DE LAS FICHAS EL CURSOR DEL MOUSE CAMBIA, INDICANDO QUE TIENE “EN SUS MANOS” UNA FICHA PARA SER UBICADA EN EL TABLERO. PARA UBICARLA BASTA SELECCIONAR CON EL BOTÓN IZQUIERDO DEL MOUSE, ALGÚN LUGAR DENTRO DEL TABLERO DONDE LA FICHA SE PUEDA PONER. UNA FICHA NO SE PUEDE UBICAR ENCIMA DE OTRA QUE YA ESTÁ SOBRE EL TABLERO, O EN UN LUGAR DONDE EL ÁREA ENVOLVENTE DE LA FICHA SE INTERSECTE CON LA DE OTRA Y SOBRE PASE UNOS VALORES PRE-DEFINIDOS; CUANDO SE INTENTA HACER ESTO, SE DESPLIEGA UN MENSAJE EN LA BARRA DE ESTADO Y NO SE UBICA LA FICHA EN ESE LUGAR. 3. EN CASO DE QUE YA NO QUIERA UBICAR LA FICHA SELECCIONADA, PRESIONA EL BOTÓN IZQUIERDO DEL MOUSE SOBRE LA BARRA DE HERRAMIENTAS. 4. DESPUÉS DE HABER UBICADO TODAS LAS FICHAS QUE ESTIME NECESARIAS PARA RESOLVER EL NIVEL, EN LA BARRA DE HERRAMIENTAS SE ENCONTRARÁ EL BOTÓN QUE PONE A FUNCIONAR LA MÁQUINA CONSTRUIDA. SI FUNCIONA O NO LA SOLUCIÓN PLANTEADA POR EL JUGADOR, SE INFORMA EN LA BARRA DE ESTADO. 5. EN CASO DE NO HABER CUMPLIDO EL OBJETIVO, EL JUGADOR PODRÁ REUBICAR LAS FICHAS A SU ANTOJO. Criterios de aceptación: LOS DIFERENTES OBJETOS MENCIONADOS ANTERIORMENTE REACCIONAN DE LA MANERA DESCRITA SIN EXCEPCIÓN.

ISC-2003-1-52

40

tiene

afecta a

bajo efecto

tiene cuenta con

cuenta con

hace parte

jugadas fijas

es de

tipo1

tipo2

inicial

actual

final

es observado

observa

tiene

5.8 CLASES Para cada lado de la aplicación, tanto el cliente como el servidor, se crearon diagramas de clases que ilustran la composición de los objetos y las relaciones entre estos. Diagrama 5. Diagrama de clases del cliente

TMovil TMotor TPared

EMovil EMotor EPared

Relación

TipoFicha

Juego Nivel

Ficha

Ambiente

Estado

EObservado

Cuadrante

AreaEnvolvente

1.*

1.*

1

11.*1.*1.*1.*

1 1

1.*

1

ISC-2003-1-52

41

5.8.1 Cliente El diagrama 5, es el diagrama completo sin detalles de las clases de todo el juego. A continuación se verán cinco diagramas que hacen parte del diagrama principal y veremos como funciona. Las clases en detalle se encuentran como anexo a este documento. Diagrama 6. Detalle diagrama de clases Esta parte del diagrama muestra el modelo de las condiciones físicas de Nivel y Juego. El juego a la hora de cargar un nivel, divide su tablero en Cuadrantes, cuadrantes con un tamaño fijo, en donde estarán distribuidas todas las fichas tanto fijas como jugadas. La explicación de los cuadrantes se dará más adelante en el capitulo de implementación. El Ambiente encierra las condiciones físicas que rigen las fichas dentro de Nivel.

Juego Nivel

Ambiente

tiene

afecta a

bajo efecto

1.*

1.*

1

Cuadrante agregarFicha(Ficha): void estaFicha(Ficha): boolean

agregarFija(Ficha): void agregarJugada(Ficha): void darFicha(id): void retirarFIcha(Ficha): void

ISC-2003-1-52

42

fijas

inicial

actual

final

es observado

observa

tienejugadas

es de

Diagrama 7. Detalle diagrama de clases El diagrama 7 muestra como se relacionan las fichas con Nivel, la composición de Ficha y de Estado. El nivel tiene fichas jugadas y fijas. Cada una de estas a su vez tiene tres estados: inicial, actual y final; y, cada uno tiene un área envolvente, debido a las deformaciones que pueden ocurrir desde el inicio hasta el final de la solución de un nivel. Nota: Solo las fichas que hacen parte de la solución del nivel tienen estado final.

Diagrama 8. Detalle diagrama de clases

Nivel

Estado

AreaEnvolvente

11.*1.*

TipoFicha Ficha rotar(): void trasladar(int, int): void deformar(char): void

TMovil TMotor TPared

TipoFicha

ISC-2003-1-52

43

tiene

cuenta con

tipo1 tipo2

1.*

Diagrama de herencia, TipoFicha es la súper-clase de todos los tipos de ficha existentes en el juego. TMotor, TMovil, y TPared definen características especiales para los tipos de fichas que se quieran crear en el juego. (Los atributos y métodos de estas clases se pueden consultarse en el Anexo 4)

Diagrama 9. Detalle diagrama de clases Esta parte del diagrama 1 modela los tipos de ficha que existen en el juego, y las relaciones que existen entre parejas de tipos de ficha. Las relaciones establecen el comportamiento de fichas de dos tipos cuando entran en algún tipo de contacto (colisión o contacto)

Relación

TipoFicha

Juego

1.*

1 1

crearNivel(Array): void crearJugada(Array): void agregarTipoFicha(Array): void agregarFijaNivel(Array): void agregarJugadaNivel(Array): void agregarRelacion(Array): void agregarCOntacto(Array): void darOpcionesFicha(String): void transformarFicha(String,String, String): void update(int): void restaurarFichas(): void

ISC-2003-1-52

44

Diagrama 10. Detalle diagrama de clases

Al existir varios tipos de ficha, también para cada uno de estos debe existir un estado especial que lleve el estado de los atributos especiales. Además, el comportamiento de una ficha en ciertas ocasiones dependen del de otra, así que se diseño una especie de patrón observador, donde el estado de una ficha observa al de otra con el fin de cambiar en el preciso momento que el otro lo haga. En el cliente también se encuentran los siguientes tres componentes SVG, donde se reflejan los cambios del mundo del juego y se controla los mismos. § BarraEstado

Descripción: muestra los mensajes de error, advertencia o de procedimiento del juego; contiene los botones necesarios para aplicar las transformaciones (rotar, deformar, reducir) una ficha previamente seleccionada en el tablero. También muestra los botones con los que se retira una ficha del tablero.

EMovil EMotor EPared

Estado

EObservado

es observadoobserva

ISC-2003-1-52

45

Funcionalidad: a continuación se describe la funcionalidad que el componente ofrece a los otros que comparten la ventana en la que se encuentra.

o mostrar_mensajes ( texto, tipo) Despliega un mensaje con ciertas características definidas por el tipo de mensaje que se quiera mostrar. (p.e si tipo es alerta, el texto mostrado sería de color rojo e intermitente)

- texto: frase que se quiere mostrar en la barra de estado. - tipo: tipo de mensaje que se quiere mostrar.

o mostrar_opciones( opciones, id) Muestra los botones

correspondientes a una lista de transformaciones recibidas por parámetro.

- id: identificador de una ficha. - opciones: arreglo que contiene la información de las deformaciones que soporta la ficha identificada con id.

o mostrar_controles() Muestra los botones de control de la animación

de las fichas que se encuentran en el tablero. § BarraDisponibles

Descripción: muestra los tipos de ficha y la cantidad de cada uno de estos, que el jugador tiene disponibles para resolver el nivel cargado. Además, lleva la cuenta de la cantidad disponible por cada tipo de ficha.

Funcionalidad: a continuación se describe la funcionalidad que el componente ofrece a los otros que comparten la ventana en la que se encuentra.

o get_seleccionada() Retorna el identificador del último tipo de ficha

que se seleccionó. o agregar_ficha(id) Aumenta en uno la cantidad de un tipo de ficha

de los que se muestran en la barra y muestra este cambio. - id: identificador de la ficha que se quiere agregar

o retirar_disponible() Disminuye en uno la cantidad disponible del tipo de ficha que se seleccionó por última vez.

ISC-2003-1-52

46

§ Tablero

Descripción: Muestra las fichas que se encuentran dentro del tablero del juego, las fichas fijas y las disponibles ubicadas por el jugador.

Funcionalidad: a continuación se describe la funcionalidad que el componente ofrece a los otros que comparten la ventana en la que se encuentra.

o transformar_ficha(transformación, id_ficha) Transforma una ficha

según lo indique los parámetros recibidos. - transformación: información relacionada con el tipo de transformación que debe realizarse a la ficha, y la dirección de la transformación. - id_ficha: identificador de la ficha que se quiere transformar.

o retirar_ficha( id_ficha ) Retira del tablero una determinada ficha.

- id_ficha: identificador de la ficha que desea retirarse

o mover_ficha(id_ficha, x, y) Traslada una ficha a una posición determinada

- id_ficha: identificador de la ficha que se desea trasladar - x: coordenada en x de la posición donde se quiere dejar la ficha - y: coordenada en y de la posición donde se quiere dejar la ficha

o play() Da inicio a la interacción de las fichas existentes en el tablero. o stop() Detiene la interacción de las fichas existentes en el tablero.

ISC-2003-1-52

47

5.8.2 Servidor Diagrama 11. Diagrama de clases del servidor

Descripción de los atributos que hacen referencia a rutas de archivos. - rutaTIM : dirección de la carpeta raíz del juego. - rutaSVG: dirección relativa a rutaTIM donde se deben generar los archivos SVG. - rutaVM : dirección relativa a rutaTIM donde se encuentran las plantillas de Velocity con las que se generan los componentes SVG.

usa

ISC-2003-1-52

48

- rutaConf: dirección relativa a rutaTIM de la carpeta donde se encuentran los archivos de configuración del juego. - rutaNiveles: nombre del archivo donde se encuentra la descripción de los niveles del juego. - rutaTipos: nombre del archivo donde se encuentra la descripción de los tipos de ficha del juego. - rutaContenedores: nombre del archivo que contiene los nombres de los nodos contenedores que se encuentran en los demás archivos de configuración. - rutaRelaciones: nombre del archivo que contiene las relaciones existentes entre los tipos de ficha del juego. - rutaContactos: nombre del archivo que contiene las acciones a realizar a dos fichas de cierto tipo de ficha cuando se genera una acción específica en uno de ellos.

ISC-2003-1-52

49

6. IMPLEMENTACIÓN 6.1 CONFIGURACIÓN DE DIRECTORIOS La aplicación tiene un orden de directorios que obedece en primer lugar a la configuración requerida por el servidor web utilizado (Apache Tomcat 4.1). Se tiene dentro de la carpeta del juego MITIM, una carpeta WEB-INF y dentro de esta una carpeta classes. Dentro de WEB-INF se encuentran los directorios necesarios para configurar y ejecutar el juego, así como una carpeta lib que contiene el archivo de dependencias de Velocity. La carpeta de configuración que se encuentra en WEB-INF se llama conf, en ella se encuentran los archivos de configuración de niveles, tipos de ficha, relaciones entre tipos de fichas y de contactos, todos estos van a ser explicados más adelante. En WEB-INF también se encuentra una carpeta (src) con el paquete de clases de java y otra con las plantillas de Velocity (templates). Adicionalmente, en la carpeta del juego MITIM, esta la carpeta con los componentes SVG generados por el servidor, y otra carpeta con la página de ayuda del juego. En la implementación actual del juego, la carpeta del mismo MITIM deberá ubicarse en el directorio C:\temp. Del equipo donde corra el servidor del juego. La imagen 7 muestra el contenido de la carpeta MITIM.

ISC-2003-1-52

50

Imagen 7. Configuración de directorios

ISC-2003-1-52

51

6.2 SERVIDOR La implementación de los diferentes componentes del servidor se realizó así: 6.2.1 Modulo Juego El modulo del juego es el que se encarga de: primero, mantener de manera estructurada, ordenada y clara, la información relevante al juego, como la definición de las fichas y niveles del juego, en un repositorio de información definido. Segundo, proveer los métodos suficientes para que la vista del juego, existente en el cliente, pueda desplegar apropiadamente la información relacionada con el mismo. Finalmente, obtiene los datos necesarios del repositorio para cumplir con lo anteriormente descrito.

Para cumplir con lo anterior, el servidor esta compuesto por tres componentes:

6.2.1.1 Repositorio Conjunto de archivos XML que contienen la información de configuración del juego, estos archivos se encuentran estructurados de la siguiente manera.

6.2.1.1.1 TiposFichas.xml En este archivo se encuentra la información detallada de cada uno de los tipos de ficha existentes en el juego. El nodo raíz del archivo es <tiposFichas>, este tiene un atributo llamado id cuyo valor siempre debe ser igual a “juego”, y, tiene tantos nodos hijos <tipoFicha>, como tipos de fichas existan en el juego. A continuación encontrará un ejemplo de archivo, y la estructura del nodo <tipoFicha> y la descripción de sus atributos e hijos es:

La imagen 8 muestra la estructura de un archivo que define los tipos de ficha para el juego. En el se está definiendo cuatro tipos de ficha: BolaBaloncesto, MotorRaton, MuroHorizontal y BandaTransporte. Los atributos de las etiquetas y los hijos de estas corresponden a los atributos que se quiere establecer para el tipo de ficha.

ISC-2003-1-52

52

Imagen 8. Ejemplo TiposFichas.xml

Las estructuras de los nodos requeridos para definir el archivo TiposFichas.xml son:

ISC-2003-1-52

53

Tabla 6. Estructura nodo tipoFicha

<tipoFicha>

Descripción: Descripción de un tipo de ficha existente en el juego

Atributos Nombre valor Descripción

id String Nombre del tipo de ficha (no debe contener espacios en blanco)

gravedad [‘true’|’false’] Indica si las fichas de ese tipo son afectadas por la fuerza de gravedad cuando se encuentran ubicadas en el tablero.

magnitud_ deformacion

float Valor entre 0 y 1, que representa un porcentaje del tamaño original del tipo de ficha, en el que debe deformarse las fichas de este tipo.

rotaciones int Numero de rotaciones permitidas a las fichas de este tipo. El ángulo que se rota cada vez es 360 / rotaciones.

puntos_anclaje int Numero de puntos que deben indicarse cuando quiera ubicarse dentro del tablero una ficha de este tipo

tipo String Nombre de la subclase a la que hace parte el tipo de ficha (TMovil, TMotor, TPared)

Hijos

<deformaciones> : obligatorio <centro> : obligatorio <area> : obligatorio <dimensiones> : obligatorio <TPared> : si atributo tipo=”TPared” <TMotor> : si atributo tipo=”TMotor” <TMovil> : si atributo tipo=”TMovil”

ISC-2003-1-52

54

Tabla 7. Estructura nodo deformaciones <deformaciones>

Descripción: Indica la dirección y numero de veces que se puede deformar una ficha de este tipo de ficha

Atributos Nombre valor Descripción

u int Numero de deformaciones que soporta las fichas del tipo de ficha, hacia la parte superior de esta. iii

d int Numero de deformaciones que soporta las fichas del tipo de ficha, hacia la parte inferior de esta. iv

l int Numero de deformaciones que soporta las fichas del tipo de ficha, hacia el lado izquierdo de esta.v

r int Numero de deformaciones que soporta las fichas del tipo de ficha, hacia el lado derecho de esta.vi

Hijos

Tabla 8. Estructura nodo centro

<centro>

Descripción: Indica las coordenadas (x,y) sobre el cual pasa el eje de rotación del tipo de ficha.

Atributos Nombre valor Descripción

x int Coordenada en x del eje de rotación del tipo de ficha. vii

y int Coordenada en y del eje de rotación del tipo de ficha.viii

Hijos

iii La parte superior de una ficha es la que se encuentre más arriba en la pantalla. iv La parte inferior de una ficha es la que se encuentre más abajo en la pantalla. v El lado izquierdo de una ficha es el izquierdo respecto a el punto de vista del jugador. v i El lado derecho de una ficha es el derecho respecto a el punto de vista del jugador. vii Se encuentra en el mismo plano de referencia en el que esta definido el objeto SVG correspondiente a el tipo de ficha. viii Ibid

ISC-2003-1-52

55

Tabla 9. Estructura nodo area <area>

Descripción: Define el rectángulo que envuelve al tipo de ficha y que se verifica para hallar las colisiones con otros tipos de ficha

Atributos Nombre valor Descripción

x int Coordenada en x del extremo superior izquierdo del cuadrado que hace de área envolvente del tipo de ficha. ix

y int Coordenada en x del extremo superior izquierdo del rectángulo que hace de área envolvente del tipo de ficha.x

alto int Alto del cuadrado del cuadrado que hace de área envolvente del tipo de ficha xi

ancho int Ancho del rectángulo del cuadrado que hace de área envolvente del tipo de fichaxii

Tabla 10. Estructura nodo dimensiones

<dimensiones>

Descripción: Define las dimensiones del rectángulo en el que se puede encerrar toda el tipo de ficha (en este caso coinciden los valores con los del área envolvente)

Atributos Nombre valor Descripción

alto int Alto del rectángulo en el que esta contenida toda la imagen correspondiente al tipo de ficha

ancho int Ancho del rectángulo en el que esta contenida toda la imagen correspondiente al tipo de ficha

ix Se encuentra en el mismo plano de referencia en el que esta definido el objeto SVG correspondiente a el tipo de ficha. x Ibid xi El alto del cuadrado es vertical a la pantalla xii El ancho del cuadrado es horizontal a la pantalla

ISC-2003-1-52

56

Tabla 11. Estructura nodo TMotor

<TMotor>

Descripción: Descripción de las características propias de un tipo de ficha que es capaz de imprimir velocidad a otro. Atributos

Nombre valor Descripción velocidad int Velocidad expresada en metros por

segundo a la cual impulsa el tipo de ficha a las fichas que se encuentran en contacto con el.

Hijos

Tabla 12. Estructura nodo TMovil <TMovil>

Descripción: Descripción de las características propias de un tipo de ficha que se mueve libremente bajo el efecto de la gravedad por el tablero colisiona con los otros objetos del tablero. Atributos

Nombre valor Descripción radio int Longitud del radio del tipo de ficha. masa int Cantidad de masa del tipo de ficha.

elasticidad float Coeficiente de elasticidad del material del tipo de ficha.

friccion float Coeficiente de fricción del material del tipo de ficha.

densidad float Relación entre la masa y el volumen del tipo de ficha.

Hijos

ISC-2003-1-52

57

Tabla 13. Estructura nodo TPared

<TPared>

Descripción: Descripción de las características propias de un tipo de ficha que direcciona los tipos de ficha móviles que sobre el pase. (pe. paredes, tubos) Atributos

Nombre valor Descripción inclinación int Grado de inclinación del tipo de ficha

pared friccion float Coeficiente de fricción del material del

tipo de ficha. Hijos

6.2.1.1.2 Niveles.xml En este archivo se encuentra la información detallada de cada uno de los niveles existentes en el juego. El nodo raíz del archivo es <niveles>, este tiene un atributo llamado id cuyo valor siempre debe ser igual a “juego”, y, tiene tantos nodos hijos <nivel>, como niveles existan en el juego. Ejemplo de archivo Niveles.xml La imagen 9 define un nivel llamado Nivel_Bolas, cuyo objetivo es sacar todas las bolas del tablero (línea 3). Para este se han definido cuatro tipos de fichas disponibles (líneas 6 a 9), y tres fichas fijas (líneas 12 a 63).

ISC-2003-1-52

58

Imagen 9. Ejemplo de archivo Niveles.xml

ISC-2003-1-52

59

La estructura del nodo <nivel> y la descripción de sus atributos e hijos es:

Tabla 14. Estructura nodo nivel <nivel>

Descripción: Descripción de un nivel existente en el juego

Atributos Nombre valor Descripción

id String Nombre con el que se identifica el nivel.

Hijos

<objetivo> : obligatorio <ambiente> : obligatorio <disponibles> : obligatorio <fijas> : obligatorio

Tabla 15. Estructura nodo ambiente <ambiente>

Descripción: Descripción de las características físicas que afectan el movimiento de los objetos dentro del tablero.

Atributos Nombre valor Descripción gravedad float Magnitud de la fuerza de la gravedad

del nivelxiii velocidad_viento int,int Velocidades vertical y horizontal del

viento presente en el nivel. xiv color_fondo int,int,int Código rgb que conforma el color del

fondo del tablero xv Hijos

xiii La gravedad esta expresad en metros por segundo al cuadrado xiv La velocidad esta expresada en centímetros por segundo xv El valor de cada uno de los enteros es entre 0 y 255

ISC-2003-1-52

60

Tabla 16. Estructura nodo objetivo

<objetivo> Descripción:

Describe el objetivo del nivel, lo que debe lograrse para que se considere que se llego a una solución valida. Esta nodo no tiene atributos ni hijos, el valor del nodo va encerrado entre el tag <objetivo> y </objetivo>, su valor es un string

Tabla 17. Estructura nodo disponibles

<disponibles> Descripción:

Contiene la información de los tipos de ficha disponibles del nivel Hijos <disponible> : obligatorio (uno o mas)

Tabla 18. Estructura nodo disponibles

<disponible> Descripción:

Especifica un tipo de ficha y la cantidad de este disponible en el nivel.

Atributos Nombre valor Descripción

id_tipo_ficha string Identificador del tipo de ficha disponible

cantidad int Numero de fichas del tipo de ficha que puede ubicar en el tablero para el nivel.

ISC-2003-1-52

61

Tabla 19. Estructura nodo fijas

<fijas> Descripción:

Contiene la información de las fichas fijas del nivel. Hijos <ficha> : obligatorio (uno o mas)

Tabla 20. Estructura nodo ficha

<ficha> Descripción:

Descripción de una ficha ubicada en el tablero de un nivel Atributos

Nombre valor Descripción id String Identificador de la ficha

es_solucion boolean Indica si la ficha hace parte de la solución del nivel al que pertenece o no.

id_tipo_ficha String Identificador del tipo de ficha al cual pertenece

Hijos

<estados> : obligatorio

Tabla 21. Estructura nodo estados

<estados>

Descripción: Contiene la información de los estados de una ficha en el nivel Hijos <estado> : obligatorio (uno o dos, si la ficha hace parte de la solución del nivel)

ISC-2003-1-52

62

Tabla 22. Estructura nodo estado <estado>

Descripción: Descripción del estado de una ficha ubicada en el tablero de un nivel

Atributos Nombre valor Descripción momento [‘inicio’ |

‘fin’] Indica el momento al que pertenece el estado

rotaciones int Numero de rotaciones ocurridas en la ficha

Hijos

<posicion> : obligatorio <deformaciones> : obligatorio <area> : obligatorio <contactos> : obligatorio <EPare> : si el tipo del tipo de ficha es TPared <EMotor> : si el tipo del tipo de ficha es TMotor <EMovil> : si el tipo del tipo de ficha es TMovil

Tabla 23. Estructura nodo posicion <posicion>

Descripción: Contiene la información de las coordenadas en las que están ubicados los puntos de anclaje de la ficha Hijos <coordenada> : obligatorio (uno o mas dependiendo del numero de puntos de anclaje del tipo de ficha al que pertenece la ficha)

ISC-2003-1-52

63

Tabla 24. Estructura nodo coordenada <coordenada>

Descripción: Define un punto (x,y) en el tablero

Atributos Nombre valor Descripción

x int Coordenada en x del punto en el tablero

y int Coordenada en y del punto en el tablero

Hijos

Tabla 25. Estructura nodo contactos <contactos>

Descripción: Contiene la información de los contactos que tiene con otras fichas dentro del tablero Hijos <contacto> : obligatorio (uno o mas )

Tabla 26. Estructura nodo contacto <contacto>

Descripción: Define una relación de contacto con otra ficha que se encuentra dentro del tablero

Atributos Nombre valor Descripción

tipo_contacto [‘fijo’,’temporal’] Define si el contacto con la ficha es fijo o temporalxvi

id_ficha string Identificador de la ficha con la que esta en contacto

Hijos

xv i Un contacto que perdura aun cuando alguna de las dos fichas cambien de posición se de tipo fijo, de lo contrario es de tipo temporal.

ISC-2003-1-52

64

Tabla 27. Estructura nodo EMotor <EMotor>

Descripción: Descripción de las características propias del estado de una ficha de tipo TMotor. Atributos

Nombre valor Descripción activo boolean Indica si la ficha fue activada y esta en

movimiento. dirección [‘l’ | ‘u’ | ‘r’ |

‘d’] Dirección en la que se aplica la fuerza del motor.

Hijos

Tabla 28. Estructura nodo EMovil <EMovil>

Descripción: Descripción de las características propias del estado de una ficha de tipo TMovil. Atributos

Nombre valor Descripción velocidad int, int Velocidad de la ficha en X y en Y

Hijos

Tabla 29. Estructura nodo EPared <EPared>

Descripción: Descripción de las características propias del estado de una ficha de tipo TPared. Atributos

Nombre valor Descripción inclinación int Angulo de inclinación de la ficha

largo int Longitud de la ficha Hijos

ISC-2003-1-52

65

6.2.1.1.3 Relaciones.xml En este archivo se encuentra la información detallada de cada una de las relaciones existentes entre los tipos de fichas del juego. El nodo raíz del archivo es <relaciones>, este tiene un atributo llamado id cuyo valor siempre debe ser igual a “juego”, y, tiene tantos nodos hijos <relacion>, como niveles existan en el juego. Imagen 10. Ejemplo de archivo Relaciones.xml

Este archivo define las acciones que se deben realizar cuando: una ficha de tipo BolaBaloncesto colisiona con una de tipo MuroHorizontal (línea 2 a 8), una de tipo BolaBaloncesto colisiona con un MotorRaton (lineas 9 a 19), y, cuando se pone en contacto una ficha de tipo Corre con una de tipo MotorRaton (líneas 20 a 33).

ISC-2003-1-52

66

La estructura del nodo <relacion> y la descripción de sus atributos e hijos es:

Tabla 30. Estructura nodo relacion <relacion>

Descripción: Describe las acciones que deben efectuarse cuando dos fichas por la intersección de sus áreas envolventes queden en cierto tipo de contacto. Atributos

Nombre valor Descripción nombre [‘colision’

|‘contacto’] Indica el tipo de contacto en el que se encuentran las fichas

id_tipo1 string Identificador de uno de los tipos de ficha en contacto

id_tipo2 string Identificador de uno de los tipos de ficha en contacto

Hijos <acciones> : obligatorio

Tabla 31. Estructura nodo acciones <acciones>

Descripción: Contiene las acciones que deben realzarse cuando dos fichas de cierto tipo entran en algún tipo de contacto. Las acciones que este contiene, solo se realizan una vez, solo cuando dos fichas de ciertos tipos de ficha entran en contacto. Hijos <accion> : obligatorio (uno o mas )

ISC-2003-1-52

67

Tabla 32. Estructura nodo accion

<accion> Descripción:

Instrucción de JavaScript que modifica los atributos de ficha1 y ficha2 que son las fichas que se encuentran en contacto. Esta nodo no tiene atributos ni hijos, el valor del nodo va encerrado entre el tag <accion> y </accion>, su valor es un string

Cada ficha tiene relacionada un área envolvente, cuando se mueve la ficha se verifica si esta se intersecta con la de otra ficha. Existen unos parámetros, unos márgenes de intersección, los cuales establecen que: si el área de la ficha se intersectó con otra y las longitudes vertical y horizontal del área de intersección supera los márgenes pre-determinados, se dice que las dos fichas se encuentran en una relación de tipo colisión; de lo contrario se encuentran en contacto. 6.2.1.1.4 Contactos.xml En este archivo se encuentra las acciones que deben realizarse cuando una de las acciones de una relación sea notificar a los contactos de una ficha. En las acciones de un contacto interactúan dos fichas, la primera es la que notifica y tiene por contacto a la otra. El elemento raíz del archivo es <contactos> y no es el mismo que se definió anteriormente.

ISC-2003-1-52

68

Imagen 11. Ejemplo de archivo Contactos.xml

Los nodos necesarios para crear el archivo de contactos son:

Tabla 33. Estructura nodo contactos <contactos>

Descripción: Contiene la información de las acciones de notificación entre fichas de cierto tipo . Hijos <contacto> : obligatorio (uno o mas )

ISC-2003-1-52

69

Tabla 34. Estructura nodo contacto

<contacto> Descripción: Contiene la información de las acciones que deben realizarse cuando una de las acciones de una relación sea

notificar a los contactos de una ficha. Atributos

Nombre valor Descripción id_tipo1 string Identificador del tipo de ficha que

notifica al otro id_tipo2 string Identificador del tipo de ficha

notificado Hijos <acciones> : obligatorio

6.2.1.1.5 Contenedores.xml Contiene los nombres de las etiquetas XML que pueden tener más de una etiqueta, del mismo nombre, como hijo.

Imagen 12. Contenedores.xml

6.2.1.2 ParserJuego es una implementación del patrón singleton y tiene como objeto, leer los archivos de configuración del juego y brindar la información que en ellos se encuentra a través de objetos que sean aceptados por el contexto de Velocity. La lectura de los archivos XML se hace por medio del paquete javax.xml.parsers y org.w3c.dom.

ISC-2003-1-52

70

6.2.1.3 Fachada es también una implementación del parámetro singleton. Implementa el método que genera los componentes SVG a partir de la información de los archivos XML, la información la obtiene a través de los métodos que ofrece ParserJuego.

El método que genera los componentes SVG con la información del nivel que se quiere cargar funciona de la siguiente manera:

• Inicializa el motor de plantillas de Velocity • Crea el contexto necesario • Agrega al contexto toda la información que esta esperando las plantillas • Hace el merge ( fusión de las plantillas y el contexto de Velocity y pasa al

método de merge un FileWriter para que deje ahí la respuesta al merge) • Cierra el FileWriter para dejar finalmente el archivo SVG creado.

Adicionalmente, existe una carpeta con los archivos correspondientes a las plantillas que Velocity transforma a SVG. Por cada tipo de ficha existe un archivo con extensión .vm, este archivo contiene el elemento SVG que representa el tipo de ficha. La razón por la que la definición de las imágenes de los tipos de fichas se realicen en un archivo que entienda Velocity, es brindar la posibilidad de que la definición de esos objetos gráficos mediante SVG puedan incluir sentencias VTL [jakarta.apache.org/velocity/vtl-reference-guide.html] y de esa manera inicializarlo con información almacenada en los archivos de configuración. Las dos plantillas principales son: 6.2.1.3.1 TableroNivel.vm Es la plantilla correspondiente al componente TableroNivel del juego. Esta plantilla esta dividida en tres partes principales, las cuales se encargan de:

§ Incluir al documento las definiciones de los tipos de ficha de las fichas del

nivel ( de las fichas fijas y disponibles).

SVG tiene definido el elemento <defs> que permite definir objetos SVG sin que sean mostrados en pantalla, los elementos que allí se encuentren solo se mostraran en pantalla cuando fuera de allí se utilicen a través del elemento <use>. Entonces, se agregan entre las etiquetas <defs> y </defs>, la definición de los tipos de ficha.

ISC-2003-1-52

71

Imagen 13. Aparte de la platilla TableroNivel.vm

En la línea 2 de la imagen 13 se establece la ruta en la que se encuentran las plantillas de los tipos de ficha. En la 3 se inicia un ciclo que recorre todos los objetos que se encuentran en el contenedor llamado $disponibles. Por cada elemento $disponible dentro de $disponibles, se incluye y ejecuta las sentencias VTL del archivo cuya ruta es $path_def${disponible.id}.vm

o Ubicar dentro de la zona del tablero las fichas fijas que pertenecen al

nivel. Imagen 14. Aparte de la platilla TableroNivel.vm

Las ficha se incluye con el elemento <use> haciendo referencia al objeto (línea 11) agregado en las definiciones de SVG. A este objeto van a aplicárseles diferentes tipos de transformaciones, por lo que es necesario que esté incluido dentro de nodos de transformación. Cada tipo de ficha tiene un centro, ese centro esta en el plano de referencia en el que se

ISC-2003-1-52

72

realizó la ficha, por otro lado en la definición del nivel la posición en la que aparece la ficha es una posición con respecto al sistema de coordenadas del tablero. Para poder situar la ficha en el lugar que indica la definición del nivel, se lleva la ficha hasta el origen (0,0), trasladándolo su centro en sentido negativo (línea 9)

Ya ubicada la ficha en el centro, se traslada a la posición que le corresponde dentro del tablero (línea 6).

Al aplicar una transformación de rotación a un objeto, SVG rota los puntos de este respecto al origen que se encuentra en la esquina superior izquierda del objeto. Ya que el eje de rotación para las fichas es el indicado por el atributo centro, entonces antes de aplicar la transformación de rotación, primero lo trasladamos al origen, y luego si lo rotamos. Lo mismo sucede con el escalamiento; de ahí la justificación del orden de las líneas 7,8 y 9. ( Nota: el orden en que se aplican las transformaciones en SVG en una cascada de elementos como la de la figura, es de adentro hacia fuera).

§ Cargar la información del estado del juego y el tablero.

En esta parte se crean los objetos necesarios definidos en la librería de JavaScript, que permiten controlar el estado del nivel. Las acciones principales son: agregar al juego los tipos de ficha usados en el nivel, agregar al juego los tipos de ficha usados en el nivel, cargar la información de las fichas fijas del nivel, cargar las relaciones que pueden existir en el juego y cargar las acciones a de notificación de contactos que pueden existir en el juego.

Las anteriores acciones definen funciones de JavaScript dinámicamente mediante las sentencias VTL y de acuerdo a la información del contexto.

6.2.1.3.2 DisponiblesNivel.vm Es la plantilla correspondiente al componente DisponibelsNivel del juego. Esta plantilla esta dividida en tres partes principales, las cuales se encargan de:

§ Incluir al documento las definiciones de los tipos de ficha disponibles del nivel.

ISC-2003-1-52

73

Se hace igual que en la plantilla del TableroNivel, con la diferencia de que del contexto se usa el objeto que contiene solo los tipos de ficha disponibles.

Imagen 15. Aparte de la platilla DisponiblesNivel.vm

§ Ubicar las fichas disponibles en el fondo del objeto SVG.

Con un árbol de nodos anidados parecidos al utilizado para ubicar las fichas dentro del tablero, y con la diferencia de que los parámetros de la segunda traslación no son la posición de la ficha en el tablero, sino un valor calculado para que las fichas queden ubicadas en orden y proporcionalmente dentro del área visible, se agregan los tipos de ficha a esta ultima, y junto a cada objeto SVG que representa el tipo de ficha se agrega un elemento de texto <text> con la cantidad disponible de ese tipo de ficha en el nivel.

§ Cargar la cantidades disponibles de los tipos de ficha

Ya que una de las funciones del componente DisponiblesNivel.svg es el de llevar el registro de las fichas disponibles del nivel, entonces, se creo un arreglo el cual se llena con la información de la cantidad por cada uno de los tipos de ficha del nivel.

Imagen 16. Aparte de la platilla DisponiblesNivel.vm

ISC-2003-1-52

74

Para la aplicación del servidor se trabajo con Apache Tomcat 4.1 como servidor web, y para la compilación de la fachada fue necesario incluir en el classpath de la aplicación, los objetos .class de la versión 1.3.1. de Velocity. Para que Tomcat pueda reconocer el código de Fachada que utiliza objetos del paquete de Velocity, debe estar en una carpeta lib dentro de la carpeta WEB-INF de la aplicación, las dependencias de Velocity (velocity-dep-1.3.1-rc2). 6.3 CLIENTE El cliente esta compuesto por: 6.3.1 Página JSP Página en el que se encuentran embebidos los componentes SVG. Pide a la Fachada que se encuentra en el servidor, que genere e inicialice los componentes SVG que hacen parte del juego. Mediante la etiqueta de HTML <embed> tiene embebidos tres componentes SVG: § BarraEstado: muestra mensajes de error y procedimiento del juego, y

contiene los botones de control de la animación, y los controles de deformación de las fichas

§ DisponiblesNivel: muestra los tipos de ficha y la cantidad de cada uno de estos, que el jugador tiene disponibles para resolver el nivel cargado. Además, lleva la cuenta de la cantidad disponible por cada tipo de ficha.

§ TableroNivel: muestra las fichas que se encuentran dentro del tablero del juego, las fichas fijas y las disponibles ubicadas por el jugador.

6.3.2 Juego Juego es un paquete de clases hechas en JavaScript. En estas se mantiene el estado del juego y el control del mismo. Los controladores de los componentes SVG fueron hechos en JavaScript y son generados dinámicamente por el motor de plantillas de Velocity, en la misma petición a la Fachada por parte del JSP de crear los componentes. La animación de las fichas cuando se quiere probar la solución sugerida por el jugador, esta a cargo de la clase Juego. Esta clase cuenta con un método que actualiza el estado de las fichas según las condiciones físicas del tablero y las acciones ejecutadas a raíz de las relaciones que se presentan durante la animación.

ISC-2003-1-52

75

El movimiento de los objetos se puede realizar de dos formas: la primera es mediante la definición de elementos SVG de animación <animate> que en un tiempo determinado cambie linealmente el valor del atributo de posición del objeto, o la manipulación del árbol de transformaciones en el que se encuentra todas las fichas del tablero con scripts. Esta última manera de mover las fichas fue la utilizada en el juego, ya que el nodo de animación es útil solo cuando se conoce una trayectoria fija para un objeto, bien sea una trayectoria recta definida por dos puntos, o, por una poli-línea representada en SVG con el elemento <path>; y en este caso la trayectoria de un objeto puede variar en cualquier momento por causa de una colisión. La zona del tablero esta dividida en cuadrantes. Un cuadrante es un rectángulo que inicia en una posición dentro del tablero y que tiene un ancho y alto determinados. Cada una de las fichas que se agregan al tablero, de acuerdo a su posición dentro de este, son agregadas al cuadrante en cuya área se encuentra la ficha. Los cuadrantes se crearon con el fin de optimizar la búsqueda de colisiones de un objeto al moverse. Cuando un objeto se mueve, se verifica si colisionó con las fichas que se encuentran en el cuadrante donde la ficha se encuentre. Si al moverse queda en otro cuadrante, también se revisa en ese otro, de modo que en la mayoría de los casos, dependiendo de la distribución de los cuadrantes, no va a ser necesario preguntar por todas las fichas buscando si hubo o no colisión. La animación del comportamiento de las fichas esta a cargo de la función update de la clase Juego, esta es llamada por la barra de estado al ser oprimido el botón de “play”. El llamado se hace a través de la función de JavaScript window.setInterval('update()', tiempo);, donde tiempo es un valor expresado en milisegundos que establece cada cuanto va a llamarse la función update. Cuando se presenta una intersección entre dos áreas envolventes, se verifica si el área de intersección sobrepasa el margen máximo establecido. Si no los supera, se establece que esas dos fichas se encuentran en una relación de tipo contacto, de lo contrario la relación en que estarían involucradas sería de tipo colisión. Una vez establecida el tipo de relación en la que se encuentran las fichas, se verifica que existan acciones asociadas a una relación entre los tipos de ficha de las fichas y para el tipo de contacto que están; y se evalúan mediante la función eval() de JavaScript, en caso de que existan. Para evaluar las acciones que deben realizarse cuando dos fichas establecen un tipo de contacto, debe crearse dos variables: ficha1 con la instancia de la ficha que se movió y ficha2 con la instancia de la ficha con la que la primera colisionó. Esto debido a que las acciones son instrucciones JavaScript dentro de los archivos de

ISC-2003-1-52

76

configuración y hacen referencia a las fichas de la relación con esos nombres (ficha1 y ficha2). 6.4 PROBLEMAS Durante la implementación, surgieron problemas ocasionados por la falta de conocimiento que hasta ese momento se tenía del funcionamiento de Velocity y problemas de procedimiento en JavaScript. Con relación a Velocity, el problema en el que más tiempo se perdió fue lograr establecer la ruta de donde el motor de plantillas debía ubicar los recursos. No es difícil, el problema fue encontrar la documentación clara donde se hablara del error y como solucionarlo. el error que salía es el siguiente:

Problem merging template : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource

El problema anterior se soluciona cambiando los propiedades de inicialización que Velocity tiene por defecto, cambiando la ruta donde debe buscar los recursos. Se crea un objeto nuevo de propiedades y se agrega la ruta donde se estén los recursos (plantillas) que Velocity va a convertir, y se inicializa Velocity con las nuevas propiedades.

Properties p = new Properties(); p.put(Velocity.FILE_RESOURCE_LOADER_PATH, "C:\\TEMP\\MITIM\\WEB-INF\\templates\\"); Velocity.init(p);

Con Velocity no hubo otro tipo de problemas, la sintaxis de VTL es muy clara y esta muy bien documentada en jakarta.apache.org/velocity/index.html. Por otra parte, los problemas presentados en la implementación del cliente, están relacionados con el manejo de las variables de JavaScript. Los valores de las algunas variables son por referencia, por lo cual al modificar un valor en un estado en ocasiones se hacia en los tres estados de una ficha, ya que el estado actual de la ficha es el mismo que el inicial a la hora de crear la ficha, y lo mismo sucedió con algunos de los campos del estado final. La solución al problema, fue hacer siempre copias de las variables (en especial a los Array), cuando hubo que poner el valor de una variable correspondía a mas de un objeto.

ISC-2003-1-52

77

Otro problema con las variables en JavaScript fueron que, todo se maneja como cadenas, e incluso después de que se le hiciera el parser al tipo de dato que se necesitara, en ocasiones seguía comportándose como cadena y las sumas entre variables enteras o flotantes terminaba concatenando los dos números, generando errores obvios. Problemas de redondeo se presentaron al calcular la posición de las fichas, ya que esta está representada en enteros y por la escala en la que se encuentra el tablero, hacían que los valores de desplazamiento de las fichas cuando la velocidad tendía a cero, por la función de aproximación a entero, fuera cero en muchas ocasiones. Solo lograba moverse después de un tiempo en que la aceleración de la gravedad modificara la velocidad inicial del objeto a un valor tal que al calcular el desplazamiento, este sobrepasara a cero. Por último, en TableroNivel.svg cuado se va a agregar una ficha de las disponibles al tablero, se crea un nuevo elemento SVG, se cambia sus valores y se agrega al documento SVG. Tan pronto se agrega al documento se visualiza el cambio de este en la pantalla, se pinta el nuevo elemento en la posición que se haya dado. El cambio del documento no se visualiza si se tiene definidas entidades para el documento XML, por ejemplo:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000303 Stylable//EN" "http://www.w3.org/TR/2000/03/WD-SVG-20000303/DTD/svg-20000303-stylable.dtd" [ <!ENTITY ancho_tablero "850"> <!ENTITY alto "600"> <!ENTITY ancho_disp "150"> <!ENTITY medioAncho "75"> <!ENTITY tam_letra "15"> <!ENTITY scale "2"> ]>

Cuando se tiene esto en el SVG, no se actualiza la pantalla, agrega bien el documento pero no se muestran los cambios. Las entidades se habían definido con el propósito de tener en un solo lado los valores de visualización, como la altura y el ancho del tablero, el tamaño de las letras que se mostraran en la barra de estado y de disponibles, entre otras. La solución fue quitar esas definiciones, así como el uso de ellas dentro del archivo SVG, y llenar con constantes los valores de visualización mencionados anteriormente. Otra manera de inicializar los valores de visualización de los componentes SVG, de tal modo que se tenga en un solo sitio estos valores, es

ISC-2003-1-52

78

pasándolos por parámetro desde la página en que están embebidos y creando una función en cada uno de los componentes SVG para que reciba los parámetros. Los parámetros se pueden pasar: primero, definiéndolos como atributos del elemento <embed> en donde se incluye el SVG a la página; y creando una función en la página que contiene el SVG, que le pase el estado mediante la instrucción embedNode.window.passState(embedNode); donde embedNode es el elemento <embed> al que se le definieron parámetros para ser pasados. El problema de hacerlo de esta manera es que antes de llamar esta función hay que saber la versión del navegador, porque en Internet Explorer 6, window no es una propiedad de embedNode y ocasiona un error de compilación. 6.5 TRABAJO POR HACER De los requerimientos iniciales hace falta sólo la opción de crear un nivel. Para esto ya se tiene toda la base lista, de la misma manera como se ubican fichas en el tablero y el juego establece las relaciones de esta con las que ya se encuentran en el tablero, se pueden ubicar fichas en un espacio vacío, que es el inicio de la creación de un nivel nuevo. EL juego ya guarda el estado de las fichas después de ubicarlas en el tablero, faltaría agregar a las opciones que se pueden realizar al seleccionar una ficha, la de fijar una ficha. Al fijar la ficha, es necesario crear una función que cambie el tipo de esa ficha a “fija”. También habría que agregar la opción de establecer una ficha como parte de la solución del nivel, en la barra de estado un botón, y en el juego una función que después de animar las fichas y las interacciones entre ellas, cree un estado final igual al actual, para las fichas que fueron seleccionadas como parte de la solución del nivel. En la parte del cliente, faltaría también, mandar la información correspondiente al nivel a la Fachada para que ParserJuego actualice el archivo Niveles.xml. La actualización del archivo es fácil con el uso de los mismos paquetes con que se leyeron los archivos. En esos xerces se tiene la posibilidad de crear nuevos nodos, agregar hijos y agregar ese nuevo nodo a la estructura de un documento ya existente. Se diseño que el tablero se dividiera en cuadrantes para hacer mas eficiente la búsqueda de colisiones, en este momento se trabajo con un solo cuadrante cuyo

ISC-2003-1-52

79

tamaño es igual al del tablero. Para lograr el objetivo que se busca, falta implementar las funciones necesarias para administrar bien esos cuadrantes, por ejemplo, falta que la función de mover una ficha, verifique que la posición a la que se quiere mover corresponda al mismo cuadrante donde se encuentra la ficha, y que verifique si hay colisión con alguna de las fichas que se encuentra en el cuadrante al que se quiere llegar. Siguiendo con los cuadrantes, después de mover con éxito una ficha habría que actualizar las fichas de los cuadrantes en caso de que la ficha cambie de cuadrante. El método de colisiones falta por implementarse de manera correcta, se resolvieron las ecuaciones que involucran todas las características de las fichas, pero se obtuvieron resultados muy altos, valores que no concuerdan, quizás por un manejo inadecuado de las unidades, o por la solución incorrecta encontrada para las ecuaciones de colisión. Hasta el momento se tiene implementado para todos los tipos de ficha, una área envolvente rectangular, que no es lo más apropiado para todos los tipos de ficha que puedan existir en el juego. Lo más adecuado es poder definir áreas envolventes con poli-líneas que realmente envuelvan la imagen de la ficha. Esto no se hizo por la complejidad y el costo para la aplicación en rendimiento de los algoritmos de intersección entre poli-líneas. De hacerse, los cambios se realizarían en la definición de la clase AreaEnvolvente en el cliente, como el elemento <area> en el repositorio de datos. También seria necesario cambiar la función dar_tipo_contacto() de la clase Juego en el cliente, de manera que calcule la intersección entre dos poli-líneas; y la función de transformar_ficha() para que modificara todos los puntos del área envolvente según la transformación hecha a la ficha. Por la manera en que se crearon los SVG, o más bien, la manera que se agregaron las imágenes al documento, no es posible reflejar cambios en los atributos visuales definidos en la imagen (estilo), como el color, el fondo, relleno; ya que la implementación actual de SVG no permite cambiar estos valores a objetos referenciados por medio de un elemento <use>.

ISC-2003-1-52

80

7. CONCLUSIONES

A lo largo del desarrollo de este ambiente de interacción entre imágenes vectoriales “enriquecidas” con propiedades físicas, y la visualización de los cambios de estas por medio de un medio visual desplegable en un navegador de Internet, se ha podido constatar la excelente alternativa que es el estándar grafico de imágenes vectoriales SVG, en el desarrollo de contenido visual interactivo y dinámico, para un medio tan difundido, en expansión y crecimiento como lo es Internet, y mas aún para un flujo de información digital rico en imágenes no estáticas. Más que su variedad de opciones en presentación y visualización de elementos gráficos definidos con un lenguaje propio, el gran valor agregado que ofrece el lenguaje es su compatibilidad con tecnologías existentes; estas permiten ayudar a crear y visualizar de mejor manera los gráficos vectoriales creados por SVG. También, permite poner en contexto esas gráficas de manera que puedan asociarse a ellas información relevante, y así, modelar y simular situaciones y estados similares a la realidad, para cualquier propósito que se desee. Además de la compatibilidad con otras tecnologías que pertenecen también a la familia XML, SVG es un estándar libre aceptado por la comunidad especializada, lo que permite un fácil acceso y uso del lenguaje. En ningún momento fue propósito de este trabajo, comparar, como se ha hecho en los últimos dos años, a SVG con Flash. Ambas tecnologías tienen personas a favor como en contra, ambas cuentan con características que las hacen únicas. Las diferencias ya se han mencionado, solo se quiso mostrar que existe una opción más para los desarrolladores y creativos interesados en el contenido visual para Internet, una opción diferente a Flash, con diferencias que en ningún momento la hace inferior a esta, y, que de aprovechar el potencial ofrecido por tecnologías y lenguajes como CSS, XSL, JavaScript, entre otras, podría incluso superar a Flash. Es tan útil poder ver gráficos escalables y animables a través de Internet, que para un futuro cercano, se va a poder establecer propiedades y roles a los elementos de SVG por parte del mismo lenguaje. Un grupo independiente al W3C SVG Working Group está diseñando una tecnología que permita a un objeto gráfico definido en SVG, referenciar un nodo, que podríamos llamar, de comportamiento al cual podría asociársele características específicas a un contexto al que se quiera agregar el objeto y esas características tendrían consigo comportamientos definidos por un modelo de eventos.

ISC-2003-1-52

81

Es amplia la aceptación del estándar SVG, en la actualidad se consiguen una inmensa variedad de productos y tecnologías diseñadas con base en SVG e implementadas con la misma; y aun más amplia el alcance y desarrollo que le auguran los especialistas. Hasta hoy se encuentra implementada la versión 1.1 de SVG y se encuentra en desarrollo la versión 1.2. La implementación actual presenta desventajas frente a SWF en manejo de sonido y video, pero para la versión 1.2 se espera tener la capacidad de incluir y manipular estos medios. También, se ampliará la integración con otros formatos XML, y se mejorará el desempeño de opciones ya existentes como: definición de texto, acceso al DOM, y cualidades de pintura (relleno, bordes, etc), entre otros. El resultado de este trabajo es un abrebocas al potencial de desarrollo visual para soluciones en Internet que se puede alcanzar mediante la combinación de tecnologías ya existentes y otras que hasta ahora se encuentran en desarrollo. “Ver algunos ejemplos de lo que aportará SVG a la web nos abre los ojos a ideas sorprendentes” [Mas 2002].

ISC-2003-1-52

82

GLOSARIO ESCENARIO: espacio donde se ubican las partes con las que se resuelve

un nivel. FICHA: objeto con propiedades físicas (ej: poleas, balones, entre

otras). FICHA FIJA: ficha cuya ubicación fue establecida al momento de crear el

nivel, y que el jugador no puede cambiar antes de probar la solución planteada.

NIVEL: conjunto de fichas fijas y móviles que interactúan entre sí. PROBAR: se refiere a dejar que las fuerzas existentes en el tablero

(gravedad y viento) afecten a las fichas ubicadas en el mismo.

SITUACIÓN: reto propuesto en el juego. Su solución representa un beneficio para el jugador.

TABLERO: escenario. USUARIO: persona que interactúa con la aplicación. NODO CONTENEDOR:

nodo que puede contener mas de un nodo del mismo nombre como hijo.

MERGE: procedimiento hecho por Velocity en el cual a partir de una plantilla realizada con el lenguaje VRL, y los objetos existentes en el contexto actual de Velocity, genera un archivo XML específico.

ISC-2003-1-52

83

REFERENCIAS [Apa 1999] Apache Jakarta Project, Velocity, Guía del usuario, (s.f.), Traducido por Juan Pablo Morales Olaya. Recuperado de http://jakarta.apache.org/velocity/user-guide_es.html [Boe 2001] Boer Berender de. Tutorial: don’t be afraid of XSLT . (2001). Recuperado de

http://www.ntg.nl/eurotex/DeBoerXSLT.pdf [Cag 2002] CAGLE, Kurt. SVG Programming: The Graphical Web. (2002) [Cyb 2002] Cybersitio, Simulación. (s.f.). Recuperado en septiembre de 2002, de

http://cybersitio.iespana.es/cybersitio/contenido/simulacion/simulacion.htm [Mas 2002] Mas J.M, SVG: Presente y futuro de los gráficos vectoriales para la web. (s.f.).

Recuperado en octubre de 2002 de http://www.mundofree.com/joanmmas/Diseno_grafico/Galeria/SVG/svg.html

[Mor 2002] MORENO, Luciano. El formato gráfico SVG. Capitulo 1, (s.f.). Recuperado en septiembre de 2002 de http://www.htmlweb.net/diseno/svg/svg_1.html [Ren 1999] Rendón Lina. Simulación por computadoras. (1999). Recuperado en septiembre de 2002,

de http://ingenieria.udea.edu.co/CURSOS/DOCUM/INVESTIGACIONTEORICA.doc [Sal 1999] Salisbury C.F, Farr S.D, Moore J.A. (1999). Web-based simulation visualization using

Java3D. Air Force Research Laboratory. Recuperado

ISC-2003-1-52

84

[W3C 1999] XSL Working Group, XSL Transformations (XSLT) Version 1.0, W3C Recommendation

(Noviembre 1999 ). Recuperado de http://www.w3.org/TR/xslt [W3C 2003] W3C SVG Working Group, Scalable Vector Graphics (SVG) 1.1 Specification. Recuperado

de http://www.w3.org/TR/2003/REC-SVG11-20030114 [1] Rising Services, Curso de técnicas básicas de ordenador y navegación por Internet.

Modulo 1. (s.f.). Recuperado en septiembre de 2002, de http://www.risingservices.com/formanet/internet.htm

ISC-2003-1-52

85

TABLAS

pág. Tabla 1. Características principales de las fichas 19 Tabla 2. Requerimiento técnico de Distribución de pantalla 37 Tabla 3. Requerimiento técnico de Retroalimentación 38 Tabla 4. Requerimiento técnico de Interacción 38 Tabla 5. Requerimiento técnico de Visualización de una jugada 39 Tabla 6. Estructura nodo tipoFicha 53 Tabla 7. Estructura nodo deformaciones 54 Tabla 8. Estructura nodo centro 54 Tabla 9. Estructura nodo area 55 Tabla 10. Estructura nodo dimensiones 55 Tabla 11. Estructura nodo TMotor 56 Tabla 12. Estructura nodo TMovil 56 Tabla 13. Estructura nodo TPared 57 Tabla 14. Estructura nodo nivel 59 Tabla 15. Estructura nodo ambiente 59 Tabla 16. Estructura nodo objetivo 60 Tabla 17. Estructura nodo disponibles 60 Tabla 18. Estructura nodo disponibles 60 Tabla 19. Estructura nodo fijas 61 Tabla 20. Estructura nodo ficha 61 Tabla 21. Estructura nodo estados 61 Tabla 22. Estructura nodo estado 62 Tabla 23. Estructura nodo posición 62 Tabla 24. Estructura nodo coordenada 63 Tabla 25. Estructura nodo contactos 63 Tabla 26. Estructura nodo contacto 63 Tabla 27. Estructura nodo EMotor 64 Tabla 28. Estructura nodo EMovil 64 Tabla 29. Estructura nodo EPared 64 Tabla 30. Estructura nodo relacion 66 Tabla 31. Estructura nodo acciones 66 Tabla 32. Estructura nodo accion 67 Tabla 33. Estructura nodo contactos 68 Tabla 34. Estructura nodo contacto 69

ISC-2003-1-52

86

IMÁGENES

pág.

Imagen 1. Menú de niveles disponibles de TIM 20 Imagen 2. Vista inicial del nivel de TIM 20 Imagen 3. Vista intermedia del nivel de TIM 21 Imagen 4. Menú de niveles disponibles de MITIM 24 Imagen 5. Vista inicial del nivel de MITIM 24 Imagen 6. Vista intermedia del nivel de MITIM 25 Imagen 7. Configuración de directorios 50 Imagen 8. Ejemplo TiposFichas.xml 52 Imagen 9. Ejemplo de archivo Niveles.xml 58 Imagen 10. Ejemplo de archivo Relaciones.xml 65 Imagen 11. Ejemplo de archivo Contactos.xml 68 Imagen 12. Contenedores.xml 69 Imagen 13. Aparte de la platilla TableroNivel.vm 71 Imagen 14. Aparte de la platilla TableroNivel.vm 71 Imagen 15. Aparte de la platilla DisponiblesNivel.vm 73 Imagen 16. Aparte de la platilla DisponiblesNivel.vm 73

ISC-2003-1-52

87

DIAGRAMAS

pág. Diagrama 1. Componentes básicos 26 Diagrama 2. Ubicación de los componentes básicos 27 Diagrama 3. Diagrama de arquitectura 32 Diagrama 4. Diagrama casos de uso 35 Diagrama 5. Diagrama de clases del cliente 40 Diagrama 6. Detalle diagrama de clases 41 Diagrama 7. Detalle diagrama de clases 42 Diagrama 8. Detalle diagrama de clases 42 Diagrama 9. Detalle diagrama de clases 43 Diagrama 10. Detalle diagrama de clases 44 Diagrama 11. Diagrama de clases del servidor 47

ISC-2003-1-52

88

ANEXOS

Anexo 1 Tabla 1. Tabla comparativa entre SWF y SVG Característica SWF SVG Compatibilidad y extensibilidad Estándar oficial de W3C No Sí Basado en XML No Sí Uso de metadata RDF Sí, solo propietario Sí, RDF compatible Binario / texto Binario Texto Fácilmente editable No Sí Tamaño de los archivos Más compactos que los

SVG debido a su formato binario

Extensos, puede ser comprimido

Uso del DOM Tiene un DOM interno, no está basado en el DOM W3C

Sí

Compatible con CSS y XSL Parcialmente, solo en estilos propietarios

Sí

Transformaciones XSLT No Sí Pueden ser indexados por motores de búsqueda

No Sí

Uso de entidades No Sí Soporte en línea (insertado en HTML, XML)

No Sí, pero únicamente en IExplorer con el plugin de Adobe SVG v3, o en la implementación nativa de SVG en Mozilla.

Validación de sintaxis No Sí, DTD y esquema Funcionalidad del plugin (Macromedia Flash vs Adobe SVGViewer) Necesita un plugin Sí Sí, sin embargo en el

futuro será parte del navegador

Tamaño del plugin Corto, más o menos 200K

Cerca de 2.3 MB

Zoom y Panning Sí Sí Control sobre las animaciones

Sí Sí

ISC-2003-1-52

89

Antialiasing Sí Sí Búsqueda de cadenas de texto

No Sí

Vista del código fuente No Sí Contexto del menú configurable

No Sí, desde el Adobe SVG v3

Texto Fuentes o grabados embebidos

Sí, solo son necesarios los grabados.

Sí, solo son necesarios los grabados o los conjuntos de fuentes con la ayuda de WebFonts de W3C

Se puede seleccionar y copiar el texto.

El autor define si esto es posible o no.

Sí

Rotación de grabados simples

No Sí

Internacionalización No Sí Primitivas gráficas Primitivas gráficas Solo elementos de

patrones, incluye curvas cuadráticas de bezier

Elementos de patrones, curvas cuadráticas y cúbicas de bezier, curvas elípticas, rectángulos, círculos, elipses, líneas, poli-líneas y polígonos.

Introducción de nuevas primitivas gráficas

Sí, usando la “definición de formas” ya almacenándolas en el diccionario se pueden construir objetos de mayor nivel.

Sí, usando símbolos y/o entidades, los símbolos pueden incluir otros símbolos para construir objetos de mayor nivel, los símbolos deben contener algo de código SVG.

Relleno Relleno sólido, gradientes de colores y rellenos bitmap.

Relleno sólido, gradientes de colores y rellenos bitmap, y patrones vectoriales.

Transparencia Sí, relleno, pincelada, instancias de símbolos.

Sí, relleno, pincelada, grupo de opacidad, opacidad en filtros.

Tipos de líneas Solo grosor de las líneas y color.

Grosor de la línea, color, marcadores, flechas, punteado, diferentes tipos de líneas, trazos transparentes.

ISC-2003-1-52

90

Perfiles de colores embebidos

Sí, pero solo en la versión propietario

Sí, ICC/SRGB

Estilos gráficos Sí, relleno y estilo de texto, propietario.

Sí, relleno y estilo de texto, propietario, compatible con CSS y XSL.

Estilos de línea extra para cada segmento de línea.

Sí No

Símbolos Pueden ser simulados con la definición de tags.

Sí

Uso de imágenes raster. Sí, se encuentran embebidas. Soporta tipos de compresión zlib y jpeg.

Sí, embebidas y enlazadas: gif, jpg, png.

Uso de filtros No Sí, objetos raster y vectoriales.

Agrupaciones, capas Sí, grupos y capas Sí, grupos. Sistemas de coordenadas, transformaciones Transformaciones Translación rotación,

escalamiento, bifurcación, matriz.

Translación rotación, escalamiento, bifurcación, matriz y inversión.

Transformaciones anidadas

No Sí

Unidades diferentes No, la unidad básica es el “twip” que mide cerca de 1/20 de píxel.

Sí, (mm,px,pt,pc,in,em,etc)

Conversión de datos Exportado de software Macromedia Freehand,

CorelDraw, Adobe Illustrator, Macromedia Flash, Adobe LiveMotion, etc.

CorelDraw, Adobe Illustrator, Sketch, Kontour, Mayura Draw, Sphinx, WebDraw, etc.

Conexiones a bases de datos

Sí, Macromedia Generator, PerlDBI, Servlets, ASP, FlashSQL, etc.

Sí, PerlDBI, Servlets, ASP, etc.

Animación, multimedia e interacción Sonido Sí, embebido; soporta

streaming y mp3. Sí, pero el sonido no hace parte de la especificación de SVG

Películas Sí, se puede enlazara a películas Quicktime externas.

No

Programación en Propietario, Macromedia ECMA JavaScript, Java

ISC-2003-1-52

91

lenguajes de script ActionScript debe ser mezclado con ECMA JavaScript.

Bindings, ActiveX controls.

Adición de nuevos objetos vía scripting

Sí Sí

Cambio del grafo de escena en tiempo de ejecución

Sí Sí

Animación Sí, basado en frames, tiempo y script.

Sí, basado en frames, tiempo, interpolación,y script.

Elementos y propiedades que pueden ser animadas

Color, posición, transformaciones, opacidad, geometría, entre otros.

Color, posición, transformaciones, opacidad, geometría, entre otros (casi todo atributo puede ser animado)

Morphing de elementos geométricos

Sí, restringido a tener el mismo número de vértices el origen y el destino.

Sí, restringido a tener el mismo número de vértices el origen y el destino.

Cursores definidos por el usuario

Sí Sí

Botones Sí No, pero pueden ser implementados con eventos de javascript.

Tomado de www.carto.net/papers/svg/comparison_flash_svg

ISC-2003-1-52

92

Anexo 2 ( Requerimientos funcionales) Tabla 2. Definición requerimiento funcional Ubicar Ficha Identificador: Nombre: RF1 UBICAR FICHA TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SÍ

PRIORIDAD DE DESARROLLO: ALTA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: FICHA Y POSICIÓN

SALIDA: SE UBICÓ LA FICHA EN LA POSICIÓN ESPECIFICADA SI NO SE ENCUENTRA OTRA UBICADA EN ESTA.

DESCRIPCIÓN: SE UBICA EN EL TABLERO UNA FICHA PARA FORMAR LA SOLUCIÓN SUGERIDA POR EL JUGADOR AL NIVEL. MANEJO DE SITUACIONES ANORMALES SE QUIERE UBICAR LA FICHA SELECCIONADA SOBRE OTRA QUE YA SE ENCUENTRA EN EL TABLERO. Criterios de Aceptación LA IMAGEN DE LA FICHA SELECCIONADA SE ENCUENTRA EN EL LUGAR INDICADO POR EL USUARIO.

ISC-2003-1-52

93

Tabla 3. Definición requerimiento funcional Cargar Nivel Identificador: Nombre: RF2 CARGAR NIVEL TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SI

PRIORIDAD DE DESARROLLO: MEDIA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: NOMBRE DEL NIVEL

Salida: SE CARGA LA INFORMACIÓN RELACIONADA CON EL NIVEL CUYO NOMBRE CORRESPONDE AL NOMBRE RECIBIDO

DESCRIPCIÓN: SE DESEA TRATAR DE RESOLVER ALGUNO DE LOS NIVELES ALMACENADOS EN EL JUEGO, PARA ESTO DEBERÁ SELECCIONAR EL NOMBRE DEL NIVEL DE UNA LISTA DE DISPONIBLES.. MANEJO DE SITUACIONES ANORMALES EL NOMBRE DEL NIVEL NO CORRESPONDE A ALGUNO DE LOS NIVELES QUE EXISTEN EN EL JUEGO. Criterios de Aceptación SE CARGA LA INFORMACIÓN RELACIONADA CON EL NIVEL INDICADO, Y SE MUESTRA AL JUGADOR LO NECESARIO PARA QUE PUEDA RESOLVERLO.

ISC-2003-1-52

94

Tabla 4. Definición requerimiento funcional Ver ayuda Identificador: Nombre: RF3 VER AYUDA TIPO: DESEABLE

Requerimiento que lo Utiliza o Especializa:

Crítico? NO

PRIORIDAD DE DESARROLLO: MEDIA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA:

Salida: SE ABRIÓ UNA VENTANA DE AYUDA CON LA INFORMACIÓN ACERCA DEL JUEGO.

DESCRIPCIÓN: LA AYUDA SE ABRIRÁ PARA DAR INFORMACIÓN ACERCA DEL JUEGO: COMO JUGAR, PARTES DEL JUEGO, DESARROLLO DEL JUEGO, ENTRE OTROS. MANEJO DE SITUACIONES ANORMALES

Criterios de Aceptación SE ABRE UNA VENTANA DE AYUDA CON LA INFORMACIÓN ACERCA DEL JUEGO.

ISC-2003-1-52

95

Tabla 5. Definición requerimiento funcional Rotar ficha Identificador: Nombre: RF4 ROTAR FICHA TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SI

PRIORIDAD DE DESARROLLO: ALTA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: FICHA, ANGULO DE ROTACIÓN.

Salida: SE ROTÓ LA FICHA SELECCIONADA EL ANGULO INDICADO; EL EJE DE ROTACIÓN DEPENDE DE LA FICHA.

DESCRIPCIÓN: LA FICHA SE ROTA EN EL EJE DE ROTACIÓN ESPECÍFICO PARA ESTA, CON RESPECTO AL CENTRO DE LA FICHA UN ANGULO RECIBIDO COMO ENTRADA. MANEJO DE SITUACIONES ANORMALES 1. EL ÁNGULO DE ROTACIÓN ES IGUAL A CERO SOLUCIÓN: NO SE ROTA LA FICHA. Criterios de Aceptación EL SENTIDO DE LA FICHA CAMBIO CONFORME A SU EJE DE ROTACIÓN.

ISC-2003-1-52

96

Tabla 6. Definición requerimiento funcional Deformar ficha Identificador: Nombre: RF5 DEFORMAR FICHA TIPO: DESEABLE

Requerimiento que lo Utiliza o Especializa:

Crítico? NO

PRIORIDAD DE DESARROLLO: BAJA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: FICHA Y DIRECCIÓN

Salida: SE DEFORMÓ (ESTIRA O ENCOGE) LA FICHA HACIA EL LADO INDICADO.

DESCRIPCIÓN: SE ESTIRA O SE ENCOGE LA FICHA HACIA UN LADO. MANEJO DE SITUACIONES ANORMALES 1. LA FICHA NO PERMITE LA DEFORMACIÓN EN LA DIRECCIÓN INDICADA SOLUCIÓN: LA FICHA CONSERVA SU FORMA Criterios de Aceptación SE MODIFICA EL TAMAÑO DE LA FICHA EN LA DIRECCIÓN INDICADA

ISC-2003-1-52

97

Tabla 7. Definición requerimiento funcional Retirar ficha Identificador: Nombre: RF6 RETIRAR FICHA TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SI

PRIORIDAD DE DESARROLLO: ALTA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: FICHA

Salida: SE RETIRÓ LA FICHA DEL TABLERO Y SE UBICÓ NUEVAMENTE EN LA BARRA DE HERRAMIENTAS.

DESCRIPCIÓN: SE RETIRA LA FICHA UBICADA EN EL TABLERO PARA QUE NO INTERFIERA EN LA SOLUCIÓN DEL NIVEL. MANEJO DE SITUACIONES ANORMALES 1. LA FICHA ES UNA FICHA FIJA DEL NIVEL SOLUCIÓN: SE DEJA LA FICHA EN EL LUGAR DONDE SE ENCUENTRA DENTRO DEL TABLERO. Criterios de Aceptación: SE PUEDE RETIRAR TODAS LAS FICHAS DEL TABLERO, EXCEPTO LAS QUE SON FIJAS EN EL NIVEL.

ISC-2003-1-52

98

Tabla 8. Definición requerimiento funcional Fijar ficha Identificador: Nombre: RF7 FIJAR FICHA TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SI

PRIORIDAD DE DESARROLLO: ALTA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: FICHA

Salida: SE ESTABLECE QUE LA FICHA INDICADA ES FIJA EN EL NIVEL.

DESCRIPCIÓN: SE ESTABLECE QUE LA FICHA INDICADA NO PODRÁ MOVERSE DENTRO DEL TABLERO CUANDO QUIERA SOLUCIONARSE EL NIVEL. MANEJO DE SITUACIONES ANORMALES 1. LA FICHA NO SE ENCUENTRA EN EL TABLERO SOLUCIÓN: NO SE REALIZA CAMBIO ALGUNO EN EL NIVEL. Criterios de Aceptación: SE FIJAN FICHAS AL TABLERO, DE MODO QUE CUANDO SE ESTE SOLUCIONANDO EL NIVEL ESTAS NO PUEDAN SER CAMBIADAS DE LUGAR.

ISC-2003-1-52

99

Tabla 9. Definición requerimiento funcional Probar solución Identificador: Nombre: RF8 PROBAR SOLUCIÓN TIPO: NECESARIO

Requerimiento que lo Utiliza o Especializa:

Crítico? SI

PRIORIDAD DE DESARROLLO: ALTA

ACTORES: JUGADOR

Documentos de visualización Asociados:

ENTRADA: CONJUNTO DE FICHAS, SU UBICACIÓN Y NOMBRE DEL NIVEL.

Salida: SE INFORMA SI EL CONJUNTO DE FICHAS Y SU UBICACIÓN SOLUCIONAN EL NIVEL.

DESCRIPCIÓN: SE REVISA SI LA INTERACCIÓN DE LAS FICHAS LLEVA A UN ESTADO DE LAS FICHAS CLAVES TAL QUE CORRESPONDAN A LA SOLUCIÓN DEL NIVEL. MANEJO DE SITUACIONES ANORMALES Criterios de Aceptación: SE PERMITE PROBAR SI LA SOLUCIÓN SUGERIDA POR EL JUGADOR CORRESPONDE A LA SOLUCIÓN DEL NIVEL.

ISC-2003-1-52

100

Anexo 3 ( Requerimientos técnicos) Herramientas y desarrollo Tabla 10. Definición requerimiento técnico Plataforma de desarrollo Identificador: RT1

Nombre: PLATAFORMA DE DESARROLLO

DESCRIPCIÓN: LA APLICACIÓN SE DESARROLLARÁ SOBRE LA PLATAFORMA WINDOWS, PARA LA APLICACIÓN DEL SERVIDOR SE UTILIZARA EL SERVIDOR WEB TOMCAT V4. Criterios de aceptación: EL JUEGO FUNCIONA ADECUADAMENTE SOBRE LA PLATAFORMA WINDOWS. EN INTERNET EXPLORER 4 EN ADELANTE, CON EL PLUGIN DE ADOBE SVG V3 CORRECTAMENTE INSTALADO. Tabla 11. Definición requerimiento técnico Herramientas de desarrollo Identificador: RT2

Nombre: HERRAMIENTAS DE DESARROLLO

DESCRIPCIÓN: PARA EL DESARROLLO DEL JUEGO SE UTILIZARÁN EDITORES DE TEXTO COMO NOTEPAD, Y EVENTUALMENTE HERRAMIENTAS PARA DESARROLLO DE APLICACIONES WEB COMO DREAMWEAVER. ADICIONALMENTE SE CONTARÁ CON UN SERVIDOR HTTP, DONDE ESTARÁ MONTADA LA APLICACIÓN DEL SERVIDOR. Criterios de ACEPTACIÓN LA APLICACIÓN FUNCIONA SIN PROBLEMAS EN UNA MÁQUINA CON SISTEMA OPERATIVO WINDOWS (98/NT/2000), QUE TENGA INSTALADO INTERNET EXPLORER Y EL PLUG-IN DE ADOBE SVG V3 INSTALADO CORRECTAMENTE.

ISC-2003-1-52

101

Visualización Tabla 12. Definición requerimiento técnico Barra de menú Identificador: RT3

Nombre: BARRA DE MENÚ

DESCRIPCIÓN: EXISTE UNA BARRA DE MENÚ QUE MUESTRA TODAS LAS OPCIONES DEL JUEGO. DENTRO DE ESTAS OPCIONES ESTARÁ INCLUIDA LA AYUDA. LAS OPCIONES DISPONIBLES EN LA BARRA DE MENÚ SON: CARGAR NIVEL: CONSISTE EN ABRIR UN NIVEL EXISTENTE PARA TRATAR DE SOLUCIONARLO. INICIO: PERMITE PONER A FUNCIONAR LA SOLUCIÓN AL NIVEL SUGERIDA POR EL JUGADOR. AYUDA: PERMITE VER LA AYUDA DEL JUEGO Criterios de aceptación TODO EL TIEMPO LA BARRA DE MENÚ ESTARÁ VISIBLE Y DISPONIBLE Tabla 13. Definición requerimiento técnico Visualización Identificador: RT4

Nombre: VISUALIZACIÓN

DESCRIPCIÓN: LA APLICACIÓN SE VERÁ EN PANTALLA COMPLETA, TENIENDO EN CUENTA LA RESOLUCIÓN Y EL TAMAÑO DE LA MISMA Criterios de aceptación: EL JUEGO OCUPA TODA LA PANTALLA Y SE VE PROPORCIONALMENTE IGUAL EN PANTALLAS DE DIFERENTES TAMAÑOS Y RESOLUCIONES.

ISC-2003-1-52

102

Tabla 14. Definición requerimiento técnico Manejo de ventanas Identificador: rt7

Nombre: MANEJO DE VENTANAS

DESCRIPCIÓN: EN PRINCIPIO ESTARÁ VISIBLE ÚNICAMENTE LA VENTANA CORRESPONDIENTE AL JUEGO. CADA VEZ QUE EL USUARIO SOLICITE AYUDA SE ABRIRÁ UNA NUEVA VENTANA, Y SI ÉSTE NO LAS CIERRA, TENDRÁ TANTAS VENTANAS COMO HAYA SOLICITADO. Criterios de aceptación: UNA VEZ SE HAYA SOLICITADO AYUDA, SE ABRIRÁ UNA NUEVA VENTANA Y EL USUARIO SERÁ EL RESPONSABLE DE MANTENERLA VISIBLE U OCULTARLA. EN CASO DE OCURRIR UN ERROR O DE SER NECESARIO DAR ALGÚN TIPO DE RETROALIMENTACIÓN POR PARTE DEL SISTEMA, SE DESPLEGARÁ UN MENSAJE DE ACUERDO CON LO SUCEDIDO EN LA BARRA DE ESTADO. Tabla 15. Definición requerimiento técnico Metáfora del juego Identificador: RT9

Nombre: METÁFORA DEL JUEGO

DESCRIPCIÓN: LA METÁFORA DEL JUEGO (MITIM) CORRESPONDERÁ A LA DEL JUEGO ORIGINAL (TIM). LAS FICHAS DISPONIBLES LLEVARÁN EL MISMO NOMBRE Y LAS IMÁGENES SERÁN LO MÁS SIMILARES POSIBLE A LAS DE TIM. Criterios de aceptación: NO SE PERCIBEN CAMBIOS DE AMBIENTE RADICALES ENTRE LAS IMÁGENES Y LOS NOMBRES DE LAS FICHAS DISPONIBLES EN MITIM.

ISC-2003-1-52

103

Tabla 16. Definición requerimiento técnico Página principal Identificador: rt10

Nombre: PÁGINA PRINCIPAL

DESCRIPCIÓN: EN ESTA SE ENCONTRARÁ UNA BREVE PRESENTACIÓN Y LA OPCIÓN PARA ENTRAR A LA PÁGINA DONDE SE ENCUENTRAN LAS DIFERENTES ZONAS ANTERIORMENTE MENCIONADAS. Criterios de aceptación: SE INGRESA AL JUEGO DESDE LA PÁGINA PRINCIPAL.

Operación Tabla 17. Definición requerimiento técnico Sistema de ayuda Identificador: rt12

Nombre: SISTEMA DE AYUDA

DESCRIPCIÓN: EN LA BARRA DE TAREAS DEL JUEGO EXISTE LA OPCIÓN DE AYUDA; AL SER SELECCIONADA SE ABRE UNA VENTANA DE INTERNET EXPLORER QUE MUESTRA LAS DIFERENTES OPCIONES DE AYUDA. Criterios de aceptación: SE CUENTA CON UNA PÁGINA WEB DONDE SE PUEDE CONSULTAR TODA LA INFORMACIÓN ACERCA DE CÓMO JUGAR Y UTILIZAR TODAS LAS OPCIONES QUE TRAE EL JUEGO. Desempeño Tabla 18. Definición requerimiento técnico Volumen y manejo de datos Identificador: rt13

Nombre: VOLUMEN Y MANEJO DE DATOS

DESCRIPCIÓN: LA INFORMACIÓN DE LOS NIVELES Y LAS FICHAS DEL JUEGO ESTÁN REPRESENTADAS EN ARCHIVOS XML QUE SE ENCUENTRAN EN LA MÁQUINA DONDE CORRE EL SERVIDOR DEL JUEGO. A PARTIR DE ESTOS SE CONFIGURA EL JUEGO Criterios de aceptación: SOLO LA INFORMACIÓN GENERAL DEL JUEGO Y LA REFERENTE CON EL NIVEL ESPECÍFICO QUE SE ESTA ARMANDO SE ENCUENTRA CARGADA EN MEMORIA.

ISC-2003-1-52

104

Robustez y recuperación de error Tabla 19. Definición requerimiento técnico Manejo de error Identificador: rt14

Nombre: MANEJO DE ERROR

DESCRIPCIÓN: PARA CUALQUIER FALLO DE LA APLICACIÓN SE MUESTRA AL USUARIO UN MENSAJE DE ERROR EN LA BARRA DE ESTADO Y SE DA LA OPCIÓN DE CANCELAR O REINTENTAR(EN CASO DE SER POSIBLE) LA OPERACIÓN. Criterios de aceptación: NO SE PRESENTAN ERRORES PARA LOS CUALES EL SISTEMA NO CUMPLA CON ESTE REQUERIMIENTO.

Mantenibilidad Tabla 20. Definición requerimiento técnico Metodología de diseño Identificador: Rt15

Nombre: METODOLOGÍA DE DISEÑO

DESCRIPCIÓN: EL DISEÑO DE LA PARTE ORIENTADA POR OBJETOS DEL JUEGO SERÁ REALIZADO SIGUIENDO EL ESTÁNDAR UML. Criterios de aceptación: SE SIGUE ESTA METODOLOGÍAS PARA EL DISEÑO DE TODA LA APLICACIÓN DEL SERVIDOR.

Tabla 21. Definición requerimiento técnico Tipo de documentación Identificador: rt16

Nombre: TIPO DE DOCUMENTACIÓN

DESCRIPCIÓN: PARA CADA FUNCIÓN DE CADA MÓDULO CORRESPONDIENTE CON EL MODELO DEL JUEGO, SE DARÁ UNA BREVE DESCRIPCIÓN, PRE Y POST CONDICIÓN, PARÁMETROS DE ENTRADA Y DE SALIDA. TODAS LAS CLASES DE LA APLICACIÓN DEL SERVIDOR ESTARÁN DOCUMENTADAS Y SU ESPECIFICACIÓN SE PODRÁ CONSULTAR A TRAVÉS DE UNA PÁGINA WEB GENERADA POR LA HERRAMIENTA JAVADOC. Criterios de aceptación: LA ESPECIFICACIÓN DE LA APLICACIÓN DEL SERVIDOR SE PUEDE CONSULTAR A TRAVÉS DE UNA PÁGINA WEB GENERADA POR LA HERRAMIENTA JAVADOC. AL INTERIOR DEL CÓDIGO DE LAS PÁGINAS QUE HACEN PARTE DEL CLIENTE, SE PUEDE ENCONTRAR UNA BREVE DESCRIPCIÓN DE LAS FUNCIONES QUE SE ENCUENTRAN ALLÍ.

ISC-2003-1-52

105

Tabla 22. Definición requerimiento técnico Documentos de diseño Identificador: rt17

Nombre: DOCUMENTOS DE DISEÑO

DESCRIPCIÓN: DIAGRAMAS DE CASOS DE USO, CASOS DE USO EXTENDIDOS, DIAGRAMA DE CLASES.

Criterios de aceptación: DICHOS DOCUMENTOS ESTARÁN DISPONIBLES PARA QUIEN DESEE VERLOS A PARTIR DEL MISMO JUEGO Anexo 4. Definición de clases Tabla 23. Clase Ambiente

Ambiente

gravedad : float velocidad_viento : int[] color_fondo : int[]

Tabla 24. Clase AreaEnvolvente

AreaEnvolvente

x : int y : int alto : int ancho : int

ISC-2003-1-52

106

Tabla 25. Clase TipoFicha TipoFicha

tipo : string id : string gravedad : boolean magnitud_deformacion : float rotaciones : int puntos_anclaje : int centro : int[] area_envolvente : AreaEnvolvente deformaciones : int[]

Tabla 26. Clase TMotor

TMotor

velocidad : int

Tabla 27. Clase TPared

TPared

inclinación : int friccion : float

Tabla 28. Clase TMovil

TMovil

radio : int elasticidad : float masa : int densidad : float friccion : float

ISC-2003-1-52

107

Tabla 29. Clase Nivel Nivel

id : string objetivo : string ambiente : Ambiente fichas : Ficha[]

Tabla 30. Clase Estado

Estado

rotaciones : int posición : int[] deformaciones : int[] contactos : Ficha[] area_envolvente : AreaEnvolvente

Tabla 31. Clase EMotor

EMotor

dirección : char activo : boolean velocidad : int rotar(angulo) : void deformar(lado) : void reducir(lado) : void

Tabla 32. Clase EMovil

EMovil

velocidad : int[] estado : string rotar(angulo) : void deformar(lado) : void reducir(lado) : void

ISC-2003-1-52

108

Tabla 33. Clase EPared EPared

inclinación : int largo : int rotar(angulo) : void deformar(lado) : void reducir(lado) : void

Tabla 34. Clase Ficha

Ficha

id : string tipo_ficha : TipoFicha es_solucion : boolean estado_inicial : Estado estado_actual : Estado estado_final : Estado tipo : string

Tabla 35. Clase Cuadrante

Cuadrante

x : int y : int alto : int ancho : int fichas : Ficha[]

Tabla 36. Clase Relacion

Relacion

tipo1 : TipoFicha tipo2 : TipoFicha acciones : string[] nombre : string

ISC-2003-1-52

109

Tabla 37. Clase Juego

Juego niveles : Nivel[] tipos_fichas : TipoFicha[] cuadrantes : Cuadrante[] colisiones : Relacion[] contactos : Relacion[] notificaciones : Relacion[] moviles : Ficha[] init : void crear_nivel(string, string,Array ) : void agregar_tipo_ficha(Array,Array,Array) : void agregar_relacion(string,string,string,Array) : void agregar_contacto(string,string,string,Array) : void crear_jugada(string,string,int,int) : void agregar_ficha( Ficha ) : void agregar_ficha_cuadrante( Ficha ) : void dar_cuadrante( Ficha ) : Cuadrante dar_tipo_contacto(Ficha, int, int, int) : string calcular_interseccion(int[],int[],AreaEnvolvente) : string dar_opciones_ficha(string) : Array transformar_ficha(string, string, string ) : string retirar_ficha( string ) : string actualizar_contactos( string ) : void update( int ) : void restaurar_fichas() : void evaluar_relacion(string, string, string, string) : void colision_moviles(Ficha, Ficha, int, int, int, int, int, int, int, int)

: void

colision_movil_estatico(Ficha, Ficha, int, int, int, int, int, int, int, int)

: void

notificar_contactos( Ficha) : void existe_relacion( string, string ) : boolean establecer_contactos( Ficha, string[] ) : boolean revisar_solucion() : boolean