| |
Projectos
Puede consultar as correcciones
de este documento aquí
Boletín
sobre GB
Contenido:
Introducción
Su proyecto final consiste en diseñar,
documentar, construir y testear un programa que juegue
a Gizmoball. Gizmoballes una versión de pinball,
un videojuego cuyo objetivo es hacer que una bola se
mueva por todo el juego, sin que se caiga en la la parte
inferior del área del mismo. El jugador controla
un conjunto de impulsores que pueden batear la bola
cuando ésta va a caer.
La ventaja de Gizmoball con respecto
a una máquina de pinball tradicional es
que Gizmoball permite que los usuarios puedan construir
la
propia distribución de su máquina
colocando piezas (como reboteadores, impulsores y túneles
espaciales) en el campo de juego. Estas distribuciones
de la máquina pueden construir también
complejos artefactos de "Rube Goldberg" cuyo
objetivo principal es ser observados, y no servir de
juego. (Si no sabe qué es una máquina
de Rube Goldberg, visite http://www.anl.gov/OPA/rube/index.html
o http://www.rube-goldberg.com/).
A modo de ampliación opcional, (después
de que haya diseñado, documentado, implementado
y testeado toda la funcionalidad necesaria), puede crear
una nueva diversidad de piezas que puedan colocarse
en el campo de juego.
Inicio
Visión
general de Gizmoball
Dado que este proyecto es en parte
un ejercicio de diseño, el trabajo especifica
lo que el usuario debería poder realizar y deja
que usted, bajo su propio criterio, calcule qué
módulos e interfaces son los adecuados. Esta
sección le proporciona una visión de conjunto
de Gizmoball. En el Apéndice 1 se le facilitará una especificación
más detallada. Para posibilitar un testeo automático,
su implementación debe contar con un
formato de fichero (descrito en el Apéndice
2), además de la interfaz gráfica
de usuario especificada a grosso modo.
Gizmoball posee una interfaz gráfica
de usuario con dos modos, modo construcción
y modo ejecución. En modo construcción,
un usuario puede:
-
crear y editar reboteadores
cuadrados, circulares y triangulares sobre la
superficie de juego,
-
crear y editar impulsores,
-
conectar la acción
de los impulsores y los reboteadores con los lanzadores,
cuando, por ejemplo, se pulsa una tecla o uno de
los reboteadores ha sufrido un choque, y
-
guardar y cargar la
configuración del juego de usuario en
un fichero.
En modo ejecución, el usuario
puede comenzar a jugar.
Captura de pantalla de
una implementación de Gizmoball.
Su implementación puede parecer distinta, y es
posible que el movimiento de su bola no se corresponda
exactamente con la animación que se le ha facilitado.
El dibujo de arriba ilustra las características
más sobresalientes de Gizmoball.
- Una herramienta
en forma de paleta
en el lateral,
le facilita al usuario diversas operaciones
(cuadrado, círculo, triángulo, impulsor)
para colocar piezas en el área de juego.
- Una barra de herramientas "modificaciones"
en la parte inferior, proporciona al usuario una variedad
de operaciones (mover, borrar, girar) para
poder editar las piezas del área de juego.
- La barra de herramientas "modificaciones"
posee también un botón connect
(conectar) que conecta el lanzador de una pieza con
la acción de otra. Una vez pulsado este botón,
el usuario podrá conectar piezas entre sí.
Por ejemplo, el usuario podría pulsar el botón
conectar, hacer clic en uno de los reboteadores circulares
y luego hacer otro clic en uno de los impulsores.
Como resultado, cada vez que el lanzador del reboteador
se active (que ocurre cuando una bola choca con el
reboteador), tendrá lugar la acción
del impulsor (girar alrededor de su pivote). Otra
posibilidad podría ser que el usuario pulsara
el botón conectar, a continuación una
tecla, que luego contestara a una pregunta sobre si
el pulsado de la tecla up (arriba) o down
(abajo) resulta de interés
y, acto seguido, hacer clic en uno de los impulsores.
En consecuencia, cada vez que el usuario pulse (o
suelte) esa tecla, el
impulsor se moverá. La misma pieza puede ser
activada por varios lanzadores.
- La barra púrpura que
cruza la parte inferior del área de juego es
la pieza túnel espacial. Cuando una
bola entra en el túnel espacial, se para y
queda sostenida en la esquina inferior derecha de
éste. La acción que el túnel
espacial debe ejecutar es disparar la bola que está
sosteniendo (si hay alguna) directamente hacia la
parte superior del área de juego. El conectar
el túnel espacial a sí mismo, permite
que el juego entre en un
bucle continuo: cada vez que una bola entra
en el túnel espacial, ésta vuelve a
ser lanzada inmediatamente.
- El menú de la parte
superior de la ventana permite al usuario guardar
o cargar las configuraciones del juego y ejecutar
o detener el mismo. En la animación,
el juego está en funcionamiento: la bola es
el círculo azul pequeño que comenzó
en la esquina inferior derecha. La bola rebota en
los reboteadores rojo, verde y azul, y es golpeada
por los impulsores amarillos.
Inicio
Calificación
y programa
Trabajarán en grupos
de tres o cuatro personas. Todos los miembros de un equipo
obtendrán la misma nota, excepto en circunstancias
poco comunes.
Debería entregar cada
sección de este trabajo a su ayudante técnico
en formato electrónico y/o en papel. Todo el código
fuente y el compilado debería colocarse en línea
el 10 de dic. de 2001, en su directorio del proyecto del
grupo. Debido a las limitaciones del fin del trimestre,
no aceptaremos ningún trabajo que se entregue
fuera de plazo.
Inicio
Diseño
preliminar
El diseño preliminar deberá
entregarse en papel en la fecha señalada.
Su diseño preliminar no
debería ocupar más de 15 páginas.
El documento será un subconjunto de aquel descrito
en el boletín Cómo
documentar un sistema de software. Consistirá
en una especificación revisada, un diseño
(que incluya un problema del modelo de objeto), y una
visión general de la implementación (que
incluya un código del modelo o modelos del objeto
y un diagrama de dependencia de módulos). No
es necesario que adjunte información sobre su
estrategia de validación.
La especificación revisada,
el diseño y la visión general de la implementación
deberán tratar entre otras cuestiones:
-
el editor utilizado por los usuarios para construir
las consolas del juego. Por ejemplo, la especificación
debería incluir dibujos o capturas de pantalla
del editor y
casos de uso para tareas en modo de contrucción
básico.
- su bucle
de física, que describe cómo
y en qué orden se han controlado el movimiento,
la detección del choque y su resolución,
el lanzamiento, la fricción/gravedad, el dibujo
y otros factores.
- el sistema de lanzamiento que
conecta los lanzadores con las acciones.
El diseño preliminar debería incluir también
un plan de proyecto, que enumere los hitos del
equipo y la asignación de tareas para cada miembro
del grupo. Un hito es lo que se espera que esté
hecho para alguna fecha, como por ejemplo, un módulo
testeado o una característica del funcionamiento,
un logro que sea objetivo, fácil de evaluar y
notable. Deben existir al menos dos hitos en el proyecto
entre el diseño preliminar y el plazo final de
entrega. La división del trabajo debería
ser equitativa. (Resulta más útil combinar
los hitos y la asignación de tareas dentro de
una única tabla que contenga las columnas tarea,
quién y cuándo, en lugar de
especificar los
hitos y la asignación de tareas en dos documentos
distintos que no guardan relación).
El diseño preliminar será
evaluado según su claridad de expresión
y teniendo en cuenta si ha pensado rigurosamente en
el problema, si ha identificado las cuestiones fundamentales
y los retos, y si ha propuesto un diseño con
sentido.
Inicio
Reuniones
semanales con los ayudantes técnicos
Cada equipo se reunirá con
su ayudante técnico media hora una vez por semana.
El horario oficial para estás reuniones es durante
la hora habitual de clase. Para obtener puntos por la
participación completa:
- Todos los miembros del grupo
deben estar presentes en todas las reuniones.
- Todos los miembros del equipo
deben responder a las preguntas y participar en los
coloquios de cada reunión.
- Deberá entregarse en
cada reunión semanal un documento que muestre
una clara evolución del proyecto y que resulte
útil para la productividad de los coloquios.
Para la primera reunión, un borrador del diseño
preliminar servirá como documento que indique
la marcha del proyecto.
Aunque este documento debe ser
claro, es breve y de carácter informal. Constituirá
la base del coloquio durante la reunión, y el
ayudante técnico se encargará de guardarlo
en un archivo como una grabación de la evolución
lograda. El equipo debería llevar varias copias
a la reunión, una para cada uno de los miembros
del equipo y otra para el ayudante técnico. Dicho
documento debería comprender la siguiente información:
- Una descripción de todas
las cuestiones nuevas que se hayan descubierto durante
el transcurso de la semana. Esto incluye tanto una
lista de recientes errores descubiertos como una lista
de temas de diseño pendientes.
- Una descripción de todas
las cuestiones que hayan sido resueltas durante el
transcurso de la semana. Aquí se incluiría
una lista de errores reparados, cómo se han
reparado, y una lista de temas de diseño que
se hayan resuelto, y cómo se han solucionado.
- Una lista con todas las cuestiones
de semanas anteriores que queden todavía pendientes.
- Un esquema para la semana próxima,
con acciones concretas y objetivos para cada miembro
del equipo.
- Una evaluación del éxito
obtenido en el cumplimiento
del plan/diseño de la semana anterior.
- El documento puede contener
también cualquier
otro material que consideren pertinente para la descripción
de su progreso, como por ejemplo, un modelo de objeto
o fragmentos del diagrama de dependencia de módulos
que muestren cambios en el diseño.
Inicio
Entrega
preliminar
La entrega preliminar consta de
dos partes:
una descripción
crítica del diseño final y una
demostración de la funcionalidad básica.
Inicio
Diseño
final
El documento del diseño
final es una versión completa y mejorada del
documento que presentó como diseño preliminar.
(Por ejemplo, debería incluir una sección
sobre su estrategia de validación /prueba). Su
diseño final debería de ocupar menos de
20 páginas. En la sección del esquema
del proyecto, exponga cualquier hito que no haya conseguido
y explique por qué no fue capaz de lograrlo.
Dado que el diseño final
debe entregarse como parte de los objetivos de la entrega
preliminar, debería haber encontrado todos los
errores fundamentales de su diseño. Por tanto,
evaluaremos el diseño final teniendo en cuenta
si es un buen diseño, además de
su claridad de expresión.
Inicio
Funcionalidad
exigida
El día de la fecha tope
de la entrega preliminar le pediremos que demuestre
alguna funcionalidad concreta.
Para demostrar lo que había
hecho el día de la fecha de la entrega preliminar,
incluso si la demostración es un poco más
tarde y ha realizado modificaciones desde entonces,
debe guardar una copia de su código en el estado
en el que éste se encontraba antes de la fecha
de entrega. Puede realizar una captura de su código
fuente y/o compilado utilizando el fichero
jar. A continuación, puede ejecutar la demostración
ubicando el fichero jar dentro de su classpath (ruta
de clase) o convirtiendo el fichero jar en ejecutable.
Se le aceptará la ejecución
de hasta cuatro programas distintos de Java™ para
demostrar las siguientes cuatro características:
-
Demuestre en la pantalla el lanzamiento de un impulsor
presionando una tecla. Cuando se pulsa, el impulsor
debería girar 90 grados; una vez que la tecla
se suelta, el impulsor debería volver a girar
hacia su posición original. Usted debería
ser capaz de lanzarla una segunda o tercera vez pulsando
de nuevo la tecla después de que ésta
haya vuelto a su posición original. (En modo
construcción, no es necesario que demuestre
la conexión entre la tecla y impulsor).
- Pruebe un túnel espacial
en funcionamiento, el movimiento de la bola, la gravedad
y la fricción. En modo ejecución,
sin
reboteadores ni impulsores en la pantalla,
y con la bola colocada en el túnel espacial,
debería ser capaz de pulsar una tecla, observar
la bola saliendo disparada del túnel espacial,
reduciendo la velocidad a medida que asciende, retrocediendo
al túnel y volviendo a su posición original.
Demuestre también que puede volver a hacerla
salir lanzada por segunda vez. (Dése cuenta
de que no necesita tener constantes
configurables de gravedad o de fricción).
- Controle las colisiones de
las bolas con los reboteadores y las barreras. En
esta etapa no se exige un control adecuado de un choque
entre la bola y el impulsor. Durante el modo ejecución,
una bola que sale disparada del túnel debe
tener un comportamiento adecuado cuando colisiona
con los reboteadores o con las barreras externas.
- Haga una demostración
de la carga de ficheros en el formato estándar.
Dado un fichero de prueba, su implementación
debería exhibir los elementos especificados
en ese fichero en los lugares que se han precisado
en la pantalla. Debería ser capaz de cargar
y visualizar todos los elementos
estándar.
Su animación en modo ejecución
no debería presentar problemas y debería
ser adecuada para hacer una demostración de las
caractarísticas necesarias que se han especificado
anteriormente.
Inicio
Corrección
Poco después de haber presentado
la entrega preliminar, usted recibirá una corrección
de la especificación del programa. En proyectos
extensos de programación, los requisitos cambian
normalmente durante el desarrollo. Su diseño
debería ser lo suficientemente flexible como
para adaptarse con facilidad a los posibles cambios
de la especificación.
Inicio
Implementación
y crítica
Debería ser capaz de describir
su implementación y hacer una crítica
de su diseño en menos de 20 páginas (excepto
las especificaciones del Elemento 2, que pueden ocupar
otras 5 ó 10 páginas y deberían
colocarse en el apéndice). Es importante ser
conciso. El equipo de trabajo que ganó la competición
sobre el diseño de Gizmoball en el año
1999, presentó un informe final de 7 páginas.
Ponga su código en línea
en el directorio del proyecto de su equipo. No es necesario
que entregue una versión impresa de su código.
El informe final incluye una sección
sobre Cambios en el diseño. Describa detalladamente
qué cambios ha realizado en su diseño.
Sea conciso. Es sumamente importante que su ayudante
técnico tenga versiones de las partes descriptivas
de la especificación corregida, de la visión
global de la implementación y de la estrategia
de validación que describe con exactitud el código
que ha presentado y lo que hizo en realidad para testearlo
o validarlo. Si la descripción no es precisa,
la presentación no será calificada con
exactitud.
Para las demostraciones (como se
describe directamente), debe crear también un
fichero jar de su implementación.
Este fichero debe ser ejecutable y debe incluir tanto
su código fuente como su código compilado.
Haga
una demostración de su programa en funcionamiento
para su ayudante técnico. Todos los miembros
del equipo deben estar presentes para hacer una
presentación breve y responder a preguntas relacionadas
con sus responsabilidades durante el proceso de desarrollo.
Tanto la presentación como la demostración
no deberían durar más de 15 minutos. Esté
preparado para otra media hora de preguntas y debate.
Inicio
Concurso
de diseño
Cuando presente su implementación
y crítica, indique en la primera página
si desea que se le tenga en cuenta para alguno de los
siguientes premios:
- Mejor diseño: concedido
al proyecto con la mejor abstracción, modularidad,
extensibilidad, simplicidad, etc. Se tendrá
en cuenta también la calidad del informe final.
- Mejor juego Gizmoball: concedido
al proyecto con el mejor juego. Una parte de lo que
entregue para este premio debería ser un fichero
de entrada que se coloca en
el área de juego; el premio se concederá
por las características del juego en sí,
no por el kit de construcción.
- El más artístico:
concedido al proyecto más magnífico
y fascinante en términos visuales. Una parte
de su entrega para este premio debería ser
un fichero de entrada que se coloca en
el área de juego. Cuando se ejecute
con este fichero de entrada, la o las bolas deberían
rebotar continuamente sin que el usuario tenga que
pulsar ninguna tecla.
Cuando se esté decidiendo
el premio al mejor diseño, no se tendrá
en cuenta si su programa únicamente implementa
la funcionalidad básica exigida o si presenta
funciones adicionales. No obstante, una funcionalidad
adicional que mejore el juego o la maestría de
"Rube Goldberg" constituirá una ventaja a la
hora de competir por los otros dos premios.
En un principio, los ayudantes
técnicos serán los que emitan el primer
juicio, y los profesores se encargarán de emitir
los juicios finales. Un proyecto puede ganar varios
premios. Los ganadores se anunciarán en la última
clase.
Inicio
Lo
que le facilitamos
Las animaciones de Java™
suponen un gran reto. Usará los paquetes Java.awt
y Javax.swing para construir su interfaz
gráfica de usuario (GUI). Le hemos facilitado
un programa de demostración en Example.Java™
que muestra cómo estimular el movimiento de una
bola que rebota en la ventana. También realiza
una demonstración sobre cómo hacer
que su programa escuche las acciones de los usuarios,
como por ejemplo cuando se hace clic en un botón
de la barra de herramientas, cuando se pulsa una tecla
o se arrastra el ratón. Todos los miembros de
su equipo deberían ser capaces de compilar y
ejecutar esta GUI de demostración.
Le hemos facilitado también
una librería de rutinas
físicas (véase el Apéndice
3) para calcular la dinámica de las colisiones
elásticas. Puedes utilizar el código tal
y como está o modificarlo del modo que quiera.
Inicio
Consejos generales
General
- Diseño
Un diseño esmerado le ahorrará mucho
tiempo a largo plazo. Es bien sabido que un error
cometido al principio de un proyecto, puede convertirse
en un gran problema si se detecta tarde. El diseño
preliminar constituye una parte fundamental del proyecto
(mucho más de lo que la proporción en
relación a la calificación podría
indicar). Plantéelo cuidadosamente, intentando
anticipar los problemas que puedan surgir. De
esta forma, el resto
de su proyecto le resultará más claro
y divertido.
- Prototipo
Uno de los retos más importantes para este
tipo de problema de diseño es descifrar dónde
están los gotchas (comentarios especiales).
Si está teniendo problemas al imaginar cómo
estructurar una parte del diseño, sirve de
ayuda en algunas ocasiones, construir un pequeño
prototipo. Planifique deshacerse de sus prototipos.
Una vez que se ha calculado cómo diseñar
algo de forma correcta, casi nunca tiene sentido tratar
de remodelar una versión fragmentada y llena
de errores.
- Valide pronto y a
menudo
¡La validación no debería convertirse
en una idea de última hora! Es posible que
elija un diseño porque su implementación
sea más fácil de testear. Asegúrese
de que valida su código a medida que lo implementa.
- Documente pronto y
con frecuencia
Una documentación incompleta es preferible
a ninguna. Si le surge cualquier posible problema
o alguna sutileza, pero no tiene tiempo (o no es capaz)
de formularlo de manera adecuada, simplemente añada
en su documento unas oraciones en las que se describa
el tema en cuestión. Más tarde, si tiene
tiempo, vuelva a él y repárelo.
- No se exceda en la
documentación
No incluya ningún material redundante. Por
ejemplo, no es necesario que explique las diferencias
entre el testeo basado en el método de la caja
negra y el de la caja de cristal. Simplemente indique
a qué categoría pertenece cada uno de
sus casos de prueba. Del mismo modo, ser riguroso
no es lo mismo que ser excesivamente meticuloso con
lo que es obvio. Puede suponer que su ayudante técnico
sabe qué es un set o una pila. No es
necesario explicar algo partiendo de cero cuando se
pueden utilizar nociones y términos estándar.
- Diviértase
formando parte del equipo
Disfrute siendo parte del equipo. Cree nuevas ideas
delante de sus compañeros y discuta los problemas
con ellos. Lea y analice el código de otros.
Una buen método para encontrar un error es
pedir a alguien que le eche un vistazo a su código.
¡Comience pronto!
- Comuníquese
de manera eficaz
En cada reunión con los miembros de su equipo
(o con su ayudante técnico) debería
tener:
- una agenda. No se reúnan
a menos que conozcan el motivo. Esto evitará
que pierdan el tiempo.
- un jefe nombrado para agilizar
la reunión. Este jefe asegura que la reunión
va por buen camino, anima a todos los miembros
del grupo a que participen y ayuda a resolver
los problemas.
- una secretaria que tome
apuntes y los reparta luego al resto del grupo.
Estos apuntes deben subrayar las decisiones importantes
que se hayan tomado, los asuntos resueltos (y
los no resueltos), etc. Garantizan que todo el
mundo está de acuerdo con las decisiones
que se han tomado y que todos son conscientes
de las cuestiones que han surgido en la reunión.
Los roles de los miembros
del grupo deberían ir cambiando; en el curso
6.170, ningún individuo debería desempeñar
a menudo cualquier rol de forma desproporcionada.
- Priorice
Nos divertimos preparando este
proyecto. Nuestro objetivo era proporcionarle un proyecto
que fuese todo un reto y que le ofreciese muchas oportunidades
para fomentar su creatividad. Le animamos a que lo
experimente. Haga una implementación de Gizmoball
que sea agradable a la vista y que resulte divertida
a la hora de jugar. Es decir, asegúrese
de que consigue que la funcionalidad básica
funcione antes de añadir piezas nuevas
u otros accesorios. El mejor modo de abordar las ampliaciones
del proyecto es hacer su diseño inicial flexible
y extensible.
Inicio
Codificación
La sintaxis de los ficheros de
Gizmoball ha sido diseñada para facilitarle la
lectura al programa. El método
BufferedReader.readLine() puede leer un comando.
La clase StringTokenizer
puede descomponer un comando en sus partes integrantes.
Debería
adquirir conocimientos previos sobre Swing antes de
intentar codificar su GUI. Consulte el
Tutorial Swing de Sun (especialmente las secciones
quick
tour, overview
y painting).
No trate de utilizar un reloj de
tiempo real para determinar la información relativa
al tiempo. En vez de hacer esto, fije la recepción
de un evento temporizador cada 1/imágenes
por segundo y prosiga haciendo la simulación
y las actualizaciones de pantalla en respuesta a este
evento. Si se queda atrás y
si se le echa el tiempo encima, déjelo
así. Un modo sencillo de solucionar esto consiste
en utilizar la clase
Javax.swing.Timer, como en el ejemplo
de la GUI. La utilización de este enfoque
simplificará la implementación de su código
y le ahorrará la necesidad de tener que tratar
cuestiones de sincronización en un programa multihilo.
Si está usando Swing
y desea pintar su propio componente, algo que tendrá
que hacer en realidad para dibujar el tablero, las piezas
y la bola, debería ampliar Javx.swing.JComponent
e implementar sus propias rutinas de pintura. Para hacer
esto, es necesario que ignore el método
paint de su JComponent para
pintar el tablero. El pintado
se lleva a cabo llamando a métodos
del
objeto
Java.awt.Graphics proporcionado. A menos
que lo apague de forma explícita, los componentes
Swing están
dotados automáticamente de un búfer doble
para reducir el parpadeo.
Si no comprende esto, no se preocupe.
Además del Graphics, Java™
posee ahora otro contexto de gráficos
Java.awt.Graphics2D que proporciona posibilidades
más sofisticadas que el objeto Graphics
tradicional. Observe que las llamadas que sus componentes
reciben para paint(Graphics)
tendrán siempre un Graphics2D pasado
como argumento, de modo que si usted quiere trabajar
con Graphics2D, puede simplemente prescindir
del objeto Graphics. Puede implementar
Gizmoball utilizando ambos estilos de gráficos,
pero existen algunas diferencias que debería
tener en cuenta:
- El objeto
Graphics
funciona con valores enteros para píxeles que
le permiten controlar de forma más directa
qué píxeles están actualizados.
Graphics2D, por
el contrario, acepta valores en coma flotante para
definir formas geométricas que sean interpretadas
y lleva a cabo su representación. Esto resulta
un poco más automático, pero también
dificulta el ajustar directamente los píxeles
individuales.
- La clase
Graphics2D
también permite la aplicación de AffineTransforms.
(Una transformación afín
es una transformación geométrica
que mantiene las líneas paralelas).
Para responder a las acciones
del ratón y del teclado que el usuario ejecuta,
es necesario que cree e instale
MouseListener,
MouseMotionListener y
KeyListener , que se encuentran en el paquete
Java.awt.event . Puede encontrar información
sobre los códigos clave de Java™ en la documentación
para
Java.awt.event.KeyEvent.
Pulsado
de tecla
Las especificaciones para controlar
la entrada del teclado en Gizmoball exigen que un objeto
conectado a una tecla se ponga en movimiento cuando
esa tecla se pulsa o se suelta. Esto proporciona
un comportamiento similar al de un juego real de pinball:
al pulsar el botón, el impulsor se mueve hacia
arriba y al soltarlo, éste vuelve a su posición
de reposo.
Eventos
del teclado
Las especificaciones de Java™
para
Java.awt.event.KeyEvent describen tres tipos
de eventos del teclado, KEY_PRESSED,
KEY_TYPED y KEY_RELEASED.
La documentación sugiere que los eventos KEY_PRESSED
se dan cuando el usuario pulsa realmente una tecla,
y que los eventos KEY_RELEASED tienen lugar
cuando se suelta esa tecla. Por tanto, sería
razonable realizar un lanzamiento cuando se reciba un
evento KEY_PRESSED o KEY_RELEASED
que provenga de haber pulsado o soltado cualquier tecla
que esté conectada a una pieza.
Lamentablemente, la mayoría
de los entornos en tiempo de ejecución de
Java™ lanzan múltiples eventos KEY_PRESSED
y en varias ocasiones múltiples eventos KEY_RELEASED,
cuando el usuario sólo ha pulsado la tecla una
vez. Además, en algunos entornos es posible que
nunca se reciban eventos KEY_RELEASED cuando
la tecla se suelta. Esto se debe a que el comportamiento
de KEY_PRESSED y KEY_RELEASED
depende del sistema. Este comportamiento se da por una
interacción con el control por parte del sistema
operativo de las repeticiones de una tecla, que tiene
lugar cuando se mantiene una tecla pulsada durante un
periodo de tiempo.
En
Windows
En Windows, Java™ generará
múltiples eventos KEY_PRESSED cuando
se mantenga pulsada la tecla y sólo un evento
KEY_RELEASED en el momento que la tecla
se suelte. Por ejemplo, el mantener pulsada la tecla
'A' generará los siguientes eventos:
PRESSED 'A'
PRESSED 'A'
...
RELEASED 'A'
En
Unix
En Unix se reciben pares múltiples
de eventos KEY_PRESSED y KEY_RELEASED
cuando se
mantiene pulsada una
tecla:
PRESSED 'A'
RELEASED 'A'
PRESSED 'A'
RELEASED 'A'
...
PRESSED 'A'
RELEASED 'A'
Inicio
Testeo
del programa
Si desea explorar el comportamiento
de su ------ en su entorno,puede
usar la clase
KeypressTest que el personal docente
le ha facilitado. La aplicación volcará
todos los eventos del teclado en la consolapara su revisión.
El código fuente se encuentra
disponible aquí:
KeypressTest.Java
Inicio
Soluciones
No dude en manejar con toda confianza
este matiz de la API de Java™ cuando lo considerase
adecuado. Una solución sencilla consiste en desconectar
el mecanismo automático de repetición
de pulsación de tecla del sistema operativo
y, de este modo, hacer que los eventos KEY_PRESSED
y KEY_RELEASED se correspondan rigurosamente
con las acciones reales del usuario.
- Unix/Linux: escriba "
xset
-r" para desconectar el mecanismo de autorepetición.
Para volver a activar el mecanismo utilice "xset
r"
- Windows: vaya al applet
Accessibility Options (opciones
de accesibilidad) del panel de control. Seleccione
el botón Settings...(ajustes)
para FilterKeys en la pestaña
Keyboard. Seleccione Ignore
quick keystrokes (ignore las pulsaciones rápidas
de las teclas)and slow down the repear rate
(reduzca la velocidad de repetición). Seleccione
el botón Settings...
que está al lado de esa opción.
Asegúrese de que selecciona la opción
No keyboard repeat (no repeticiones del
teclado). Deslice la opción SlowKeys
a Short (0.00). Pulse Ok dos veces. Compruebe
Use FilterKeys y pulse OK. Para habilitar
y desabilitar estos cambios, simplemente compruebe
o desmarque el cuadro de
control de UseFilterKeys.
Se admite que pida al último
usuario que realice ajustes de este tipo, pero debería
incluir esto en su documentación de Gizmoball.
Otra solución sería aprovechar la ayuda
ofrecida por un decorador especial
key listener
que el personal docente les ha facilitado.
La clase está disponible en formato compilado
en el fichero gb-lib.jar como staffui.MagicKeyListener.
Consulte la documentación
de MagicKeyListener o utilice el código
fuente que le han facilitado como su propio punto
de partida.
Inicio
Administración
del sistema y herramientas informáticas
Control
de revisión
Es muy aconsejable que utilice
un paquete de control de revisión
como CVS que le ayude a coordinar su trabajo, a
prevenir la pérdida de código y que le
permita hacer copias de seguridad de versiones anteriores.
Inicio
Make:
modelo del sistema
Otra de las herramientas que puede
serle de utilidad es make. Esta herramienta
le permite escribir un makefile que sea un
modelo de su sistema: qué ficheros contienen
código, qué trabajo necesita realizarse
para compilar el sistema, qué es necesario para
ejecutar sus tests, qué es lo que hay que hacer
para limpiar el directorio, etc. Una vez que haya escrito
el makefile, puede llevar a cabo cualquiera de
estas tareas escribiendo un único comando.
En Athena, escriba info make.
Inicio
Ficheros
(JAR) Archive de Java™
Es necesario que cree ficheros
jar para reunir todas las partes de su aplicación
para entregárselas a su ayudante técnico.
Los ficheros jar son útiles porque pueden
guardar todo el código fuente, el código
compilado y los ficheros de datos asociados
(como imágenes
y sonidos) en un único archivo central
que se puede dividir luego fácilmente.
Para aprender más sobre
los ficheros jar , examine el manual jar
tool de Sun.
Como consulta rápida, le
mostramos a continuación unos ejemplos de uso
del comando jar:
Para crear el fichero gizmo.jar
a partir de las clases de los paquetes gizmo
y ball:
jar cvf gizmo.jar
gizmo ball
Para enumerar los contenidos del
fichero jar, utilice:
jar tf gizmo.jar
Para crear un fichero gizmo.jar
ejecutable:
jar cvfm gizmo.jar
JarMainManifest gizmo ball
En el ejemplo de arriba, el fichero
JarMainManifest debería contener una
línea individual que nombre el punto de entrada:
Main-Class: gizmo.StartGizmoball
Para ejecutar la aplicación
usando el fichero jar, utilice:
Java -jar gizmo.jar
Importante:Observe que cuando
se utiliza la opción -jar para ejecutar
una aplicación, la variable CLASSPATH
y el switch
de la línea de comando -cp se
ignoran. Por tanto, para incluir la librería
de
fichero jar del directorio actual del siguiente
modo:
jar xvf /mit/6.170/lib/gb-lib.jar
física en una aplicación
guardada en un fichero jar ejecutable, tendrá
que extraer los ficheros .class de nuestro
fichero jar, y deberá incluirlos en el suyo.
Puede extraer un
La utilización de un Makefile,
como se explicó en la sección anterior,
puede simplificar y automatizar la creación de
ficheros jar. Dada la complejidad y las cuestiones de
mantenimiento que se dan al combinar los ficheros de
clase de física con su aplicación,
le aconsejamos el uso de un Makefile para
automatizar el proceso.
Inicio
Apéndice
1: requisitos detallados
General
Su implementación debe
contemplar dos modos de ejecución, el
modo construcción y el modo ejecución.
En modo construcción, el usuario puede añadir
piezas al área de juego y modificar las ya existentes.
En modo ejecución, una bola se mueve por todo
el área de juego e interactúa con las
piezas.
Área
de juego
Al describir las dimensiones del
área de juego, se define L como la unidad básica
de distancia, que equivale a la longitud del borde
de un reboteador cuadrado. De acuerdo con el
uso estándar en la comunidad gráfica,
el origen se encuentra en la esquina SUPERIOR derecha
con coordenadas que aumentan hacia la derecha y hacia
ABAJO.
El área de juego debe tener
al menos 20 L de ancho por 20 L de alto. Es decir, se
podrían colocar en el área de juego 400
reboteadores cuadrados sin solaparse. La esquina superior
izquierda está en la posición (0,0) y
la esquina inferior derecha está en la posición
(20,20). Cuando decimos que una pieza se encuentra en
un lugar concreto, queremos decir que el origen de la
pieza está en ese lugar. El origen de cada una
de las piezas estándar está en la esquina
superior izquierda de su recuadro delimitador, por lo
tanto, la posición más lejana desde el
origen, en la que una pieza se puede colocar es (19,19)
en un tablero de 20L x 20L. El origen de una bola se
encuentra en su centro.
Durante
el modo construcción, las piezas deberían
colocarse en una cuadrícula de 1 L por 1 L.
Es decir, un usuario únicamente puede ubicar
piezas en las posiciones (0,0), (0,1), (0,2), y así
sucesivamente.
Durante el modo ejecución,
la cuadrícula de la
animaciónno puede tener un grosor superior a
0.05 L por 0.05 L. Suponga que la bola que se encuentra
en la posición (1,1) se mueve hacia la dirección
de (1,0), es decir, de izquierda a derecha, a una velocidad
de 0.05L
por recuadro trazado.
Entonces,la bola debería mostrarse al
menos en las posiciones (1,1), (1.05,1), (1.10,1), y
podría mostrarse en más posiciones si
usted desea que la animación sea más pausada.
Los impulsores giratorios pueden animarse de un modo
algo más brusco; véase la descripción
concreta sobre los impulsores
a continuación. Si la bola se mueve más
deprisa que el tamaño de la cuadrícula
de la animación por
recuadro trazado, no es necesario que
se vuelva a trazar en cada posición de la cuadrícula
de la animación.
Inicio
Modo
construcción
En modo construcción, el
usuario puede:
- Añadir cualquiera de
los tipos de piezas disponibles al área de
juego.
- Un intento de colocar un
pieza de un modo tal que solape a otra que se haya
colocado anteriormente o al borde del área
de juego, debería ser rechazado (es decir,
no debería tener efecto).
- Mover una pieza desde un lugar
a otro del área de juego.
- Un intento de colocar un
pieza de un modo tal que solape a otra que se haya
colocado anteriormente o al borde del área
de juego, debería ser rechazado (es decir,
no debería tener efecto).
- Aplicar un giro de 90 grados
en el sentido de las agujas del reloj a cualquier
pieza.
- El giro no tiene efecto en
piezas con una simetría giratoria. Por ejemplo,
los reboteadores circulares tienen el mismo aspecto
y funcionan del mismo modo, sin importar cuántas
veces se hayan girado a 90 grados.
- Conectar el
lanzador
de un pieza concreta con la acción
de otra pieza específica.
- Las piezas estándar
producen un lanzamiento cuando la bola choca
contra ellas, y muestran como mucho una acción
(por ejemplo, mueven un impulsor, disparan la bola
hacia fuera deltúnel
espacialo cambian el color de un reboteador). El
lanzamiento que genera una pieza puede conectarse
con las acciones de muchas piezas. Asimismo, la
acción de una pieza puede activarse por muchos
lanzadores. Las acciones
y lanzamientos necesarios para las piezas básicas
se describen a continuación.
- Observe que los disparos
no actúan "en cadena". Es decir,
cuando A se conecta a B y B se conecta a C, una
bola que choque con A, sólo hará que
se lance la acción de B.
- Conectar un lanzamiento al
pulsar una tecla a la acción de una pieza.
- Cada tecla del teclado produce
un único lanzamiento cuando es pulsada. Al
igual que los lanzamientos producidos por las piezas,
los provocados al pulsar una tecla pueden
conectarse también a las acciones de muchas
piezas.
- Borrar un pieza del área
de juego.
- Añadir una bola al área
de juego.
- El usuario debería
ser capaz de especificar una posición y la
velocidad.
- Un intento por colocar la
bola en una posición tal que solape una pieza
que se haya colocado anteriormente o al borde del
área de juego, debería ser rechazado
(es decir, no debería tener efecto). Existe
una excepción en el set de la pieza estándar: una bola que
esté parada puede colocarse dentro del túnel
espacial.
- Guardar en un fichero que haya
sido nombrado por el usuario.
- Debe ser capaz de guardar
un fichero en el formato
estándar que se ha facilitado en el Apéndice
2. Puede, si lo desea, definir una extensión
para el formato estándar que controle los
rasgos especiales de su implementación. Si
lo hace así, el usuario debe poder elegir
entre la opción de guardar en el formato
estándar o en su formato especial.
- El fichero guardado debe
incluir información relativa sobre todas
las piezas que se encuentran actualmente en el área
de juego, sobre todas las conexiones entre los lanzadores
y las acciones y sobre la posición y velocidad
actual de la bola.
- Cargar desde un fichero que
haya sido nombrado por el usuario. Debe ser capaz
de cargar un juego que haya sido guardado en formato
estándar.
- Cambiar a modo ejecución.
- Salir de la aplicación.
Inicio
Modo ejecución
En modo ejecución
el usuario puede:
- Cambiar a modo construcción
en cualquier momento.
- Si el usuario solicita cambiar
a modo construcción mientras un impulsor
está en movimiento, es aceptable retrasar
el cambio hasta que el impulsor haya alcanzado el
final de su trayectoria.
- Se aceptan retrasos breves
similares para acabar estados de transición
de las piezas que cree.
- Pulsar teclas, generando de
este modo lanzamientos que pueden conectarse a las
acciones de las piezas.
- Salir de la aplicación.
En modo ejecución, Gizmoball
debería:
- Proporcionar una animación
fluida del movimiento de la bola desde un punto de
vista visual.
- La bola debe tener por defecto
un diámetro de 0.5L aproximadamente.
- Las velocidades de las bolas
deben oscilar al menos entre 0.01 L/seg y 200 L/seg
y si lo desea, esta oscilación puede ser
mayor. Una velocidad de 0 L/seg (cuando la bola
está parada) debe también contemplarse.
- Se debería utilizar
una velocidad de imagen aceptable
para generar una animación fluida. Hemos
descubierto que a 20 imágenes por segundo
suele funcionar bien en una variedad bastante amplia
de plataformas.
- Facilitar interacciones intuitivamente
razonables entre la bola y las piezas del área
de juego. Es decir, la bola debería rebotar
en la dirección y con la velocidad resultante
que se esperaría que rebotase en un juego de
pinball físico.
- Moderar continuamente
la velocidad de la bola para dar cuenta de los efectos
de la gravedad.
-
Debería mantener un valor estándar
de gravedad a 25 L/seg2, que se semeje
a un juego de pinball con una superficie
de juego ligeramente inclinada.
- Moderar continuamente
la velocidad de la bola para dar cuenta de los efectos
de la fricción.
-
Debería modelar la fricción escalando
la velocidad de la bola al utilizar las constantes
de fricción mu y mu2.
Para una delta_t's lo suficientemente pequeña,
usted puede modelar la fricción como Vnew
= Vold * (1 - mu * delta_t
- mu2 * |Vold|
* delta_t).
-
El valor de mu por defecto, debería
ser de 0.025 por segundo.
- El valor de mu2
por defecto, debería ser de 0.025 por L.
Inicio
Piezas
estándar
Existen siete piezas estándar
que deben contemplarse: rebotadores (cuadrados, circulares
y triangulares), impulsores (derecho e izquierdo), túneles
espaciales y barreras externas.
Un coeficiente de 1.0 significa
que la energía de la bola que sale del reboteador
equivale a la energía con la que ésta
golpea al mismo, pero la bola va rodando en una
dirección distinta. A modo de ampliación,
también puede tener reboteadores con coeficientes
inferiores o superiores a 1.0.
Reboteador
cuadrado
Una figura cuadrada con una longitud
de arista de 1L.
Lanzamiento: generado cuando la bola choca contra él.
Acción: no se requiere ninguna.
Coeficiente de reflexión: 1.0
Inicio
Reboteador
circular
Una figura circular con un diámetro
de 1L.
Lanzamiento: producido cuando la bola choca contra
él.
Acción: no se requiere ninguna.
Coeficiente de reflexión: 1.0
Inicio
Reboteador
triangular
Una figura triangular derecha
con lados de 1L e hipotenusa con una longitud de (2)Lde
raiz cuadrada.
Lanzamiento: se genera cuando la bola choca
contra él.
Acción: no se requiere ninguna.
Coeficiente de reflexión: 1.0
Inicio
Impulsor
Una figura giratoria normalmente
rectangular con un recuadro
delimitador de un tamaño de 2L x 2L
Lanzamiento: se produce cuando la bola choca contra
él.
Acción: gira 90 grados (véase abajo).
Coeficiente de reflexión: 0.95 (véase
abajo).
Es necesario que existan dos clases
de impulsores, impulsor izquierdo e impulsor derecho.
Un impulsor derecho comienza su giro en el sentido de
las agujas del reloj, y uno izquierdo en el sentido
opuesto a las mismas.
Durante el modo ejecución,
un impulsor nunca debería salir fuera de su recuadro
delimitador. En modo edición, no se debería
permitir que el impulsor se colocase de cualquier modo
que pudiera hacer se saliese de su recuadro delimitador
durante el modo ejecución, o que el recuadro
delimitador del mismo se solapase con el de otra pieza
del tablero.
Las imágenes que se muestran a continuación
muestran las posiciones del impulsor en varios giros
iniciales. En modo ejecución, cuando un impulsor
se ha lanzado por primera vez, recorre 90° en la
dirección indicada por las flechas. Si se lanza
de nuevo, éste retrocede los 90° hasta alcanzar
la posición inicial.
En estas imágenes, la forma
y el diseño de los impulsores tienen únicamente
un propósito ilustrativo. No
es necesario que el diseño final de sus piezas
sea igual.
Posición inicial del impulsor y dirección
inicial del giro.
Al igual que ocurre con los tres
reboteadores estándar, un impulsor produce un
lanzamiento cuando la bola choca contra él.
Cuando se dispara la acción
de un impulsor, éste gira a una velocidad angular
constante de 1080 grados por segundo hasta llegar a
una posición que está a 90 grados de su
posición inicial. Cuando la acción se
dispara por segunda vez, el impulsor vuelve a girar
hacia su posición original a una velocidad angular
de 1080 grados por segundo.
Si su acción se dispara
mientras el impulsor está girando, el comportamiento
exacto queda bajo su propio criterio. Aquí tiene
algunas sugerencias, pero no está limitado a
ellas:
- Ignore los lanzadores cuando
el impulsor esté en movimiento. Es posible
que el usuario no desee este comportamiento porque
el simple hecho de que una tecla se pulse o se suelte
podría no hacer que el impulsor volviese a
su posición original.
- Espere hasta que el impulsor
deje de girar (y de responder a cualquier lanzamiento
que haya recibido con anterioridad) antes de responder
a la acción. Es posible que el usuario no desee
este comportamiento porque pulsar rápidamente
varias veces seguidas una tecla podrían hacer
que el impulsor perdiera el control reiteradamente
durante un periodo largo de tiempo.
- No deje en cola más
de un lanzamiento durante el movimiento inicial hacia
delante, y no tenga nada en cola durante el movimiento
de retorno. Con este modelo, una pulsación
detecla que generase dos lanzamientos haría
que el impulsor girase y volviese, pero reiteradas
pulsaciones rápidas de tecla no paralizarían
la acción de éste durante un largo periodo
de tiempo.
- Responda a todos los lanzamientos
de inmediato. Si un impulsor está moviéndose
hacia delante y es lanzado, cambiará inmediatamente
a un movimiento hacia atrás. De este modo,
los impulsores que posean una tecla de lanzamiento
hacia arriba y hacia abajo, tendrán el mismo
comportamiento que la mayoría de los impulsores
en un juego real de pinball.
El coeficiente estándar
de reflexión de un impulsor es de 0.95. Sin embargo,
cuando se calcula el comportamiento de una bola que
sale rebotada de éste, debe dar cuenta de la
velocidad lineal de la parte del impulsor que choca
contra la bola; por tanto, la bola puede salir del impulsor
con más energía que la que tenía
cuando llegó a él.
Inicio
Túnel
espacial
Un rectángulo con lados
de longitud integrante.
Lanzamiento: generado cuando la bola choca contra él.
Acción: lanza hacia fuera una bola que estaba
guardada (véase abajo).
Coeficiente de reflexión: no es pertinente; la
bola está capturada.
Cuando una bola choca contra un
túnel espacial, éste la para y la sostiene
(sin moverla) en la esquina derecha del fondo del mismo.
El centro de la bola está a 0.25L
del fondo del túnel y a .
0.25L de su lado derecho.
Si el túnel está
sosteniendo una bola, la acción de éste,
cuando se lanza, es disparar la bola directamente hacia
arriba en dirección a la parte superior del área
de juego.
La velocidad inicial de la bola
por defecto debería ser 50L/seg. (Con la gravedad
y los valores de fricción por defecto, el valor
de 50L/seg proporciona a la bola la energia suficiente
para colisionar ligeramente con la barrera superior,
si el fondo del túnel está en la coordenada
y=20L). Si el túnel no está sosteniendo
a la bola o si la bola que ha sido previamente expulsada
no ha abandonado aún el túnel, entonces
éste no lleva a cabo ninguna acción cuando
recibe una señal de lanzamiento.
Los túneles espaciales
no pueden ser girados.
Inicio
Barreras
externas
Barreras impermeables que rodean
el campo de juego.
Lanzamiento: se produce cuando la bola choca contraellas.
Acción: no es necesaria.
Coeficiente de reflexión: 1.0
Un juego Gizmoball tiene exactamente
un conjunto de barreras externas. El usuario
no puede mover, borrar o girar estas barreras externas.
Estas barreras están situadas exactamente fuera
del área de juego:
- Hay una barrera horizontal justo
encima de la coordenada y=0L.
- Hay una barrera horizontal justo
debajo de la coordenada y=20L.
- Hay una barrera vertical justo
a la izquierda de la coordenada x=0L.
- Hay una barrera vertical justo
a la derecha de la coordenada x=20L.
No es necesario que el
usuario sea capaz de usar la GUI para conectar el lanzamiento
producido por las barreras externas con cualquiera de
las otras piezas. Sin embargo, el formato
del fichero estándar sí contempla
este tipo de conexión.
Inicio
Apéndice
2: el formato del fichero de Gizmoball
Descripción informal
Los archivos de Gizmoball son interpretadores
de comandos. La sintaxis es quizás algo más
rica que la que se podría diseñar para
un juego sencillo, pero también se puede utilizar
para depurar y testear el programa independientemente
de la GUI. Es decir, el formato del fichero especifica
una interfaz estándar y así los ayudantes
técnicos podrán testear la funcionalidad
de su programa. Los ficheros contienen no sólo
una lista de piezas con sus posiciones, sino también
los comandos para ejercitar toda la funcionalidad de
Gizmoball, incluyendo las funciones de colocar, borrar
y modificar las piezas.
Cada línea de un fichero
de Gizmoball contiene un comando. Cada comando consta
de un opcode (código de operación)
y de cero o más argumentos; estos componentes
están separados por espacios y/o tabulaciones.
Por ejemplo:
Triangle T1 0 7
Este es un comando sencillo. Su
opcode es Triangle (Triángulo)
y sus argumentos son "T1", "0" y "7". Este comando especifica
que el programa debería crear un nuevo reboteador
triangular en la posición (0,7), y que el triángulo
puede ser mencionado más tarde en el fichero
con el nombre "T1". Existen comandos similares
para crear reboteadores cuadrados y triangulares e impulsores.
El comando Triangle coloca
el triángulo en un giro
por defecto.
Si desea que el triángulo esté en un giro
diferente, utilice el comando Rotate (Girar):
Triangle T2 3 5
Rotate T2
Rotate T2
Esto crea un reboteador triangular
en la posición (3,5) y luego lo gira dos veces
a 90 grados en el sentido de las agujas del reloj, hasta
alcanzar un giro total de 180 grados. El hacer girar
a un impulsor no afecta a su recuadro delimitador, pero
sí cambia su pivote. Además del comando
Rotate, existen también comandos para
mover piezas y borrarlas. Por ejemplo:
Square S1 10 2
Square S2 15 15
Move S1 19 17
Delete S2
Esto crea un reboteador cuadrado
en la coordenada (10,2) y otro en (15,15), mueve el
primer reboteador hasta (19,17) y borra el segundo,
dejando un reboteador cuadrado en (19,17).
Existen también reboteadores
para conectar lanzamientos con acciones. Por ejemplo:
Square S3 13 13
LeftFlipper LF1 5 18
Connect S3 LF1
Esto crea un reboteador cuadrado
en la coordenada (13,13) y un impulsor izquierdo en
(5,18). El comando Connect (Conectar) especifica
que la acción del impulsor debería ser
lanzada cada vez que la bola choque contra el reboteador
cuadrado.
El comando KeyConnect (Conexión
de la tecla) precisa que la acción de una pieza
esté asociada a una tecla específica que
se pulsa o que se suelta:
RightFlipper RF1
9 18
KeyConnect key 32 down RF1
KeyConnect key 32 up RF1
Esto especifica que el impulsor
de la derecha que está en (9,18) debería
activarse cada vez que la barra espaciadora se pulse
o se suelte ( "32" es el número que
Java™ AWT le da a la barra espaciadora).
Dado que también le podría
interesar que las barreras externas pudiesen lanzar
varias acciones, existe un identificador especial reservado
para ello:
Connect OuterWalls
GIZ
Este comando haría que la
bola que chocara contra cualquiera de las barreras externas
lanzara la acción de la pieza nombrada
por "GIZ".
El comado Ball (bola) le permite especificar
la posición y velocidad de la bola. Dado que
la bola puede encontrarse en puntos intermedios dentro
de un recuadro especial, las coordenadas se especifican
como números en coma flotante:
Ball B1 14.2 4.5
-3.4 -2.3
Esto sitúa una bola con
su centro en (14.2,4.5) y a una velocidad inicial de
3.4L por segundo hacia la izquierda y de 2.3L por segundo
hacia arriba.
Los comandos Gravity (gravedad) y Friction
(fricción) se pueden utilizar para establecer
las propiedades globales del juego. Cada uno toma valores
en coma flotante como argumentos, como:
Gravity 16.0 Friction
0.0 0.0
Esto reduciría la gravedad
en el juego a sólo 16L/seg2 y eliminaría
cualquier efecto de fricción. Sólo
debería usarse la última aparición
de cada comando Gravedad
y Fricción del fichero.
Aquí tiene el fichero de Gizmoball del ejemplo
mostrado arriba. Se especifica un reboteador triangular
en la esquina superior derecha, un montón de
reboteadores circulares y cuadrados y unos cuantos impulsores.
La tecla space (espacio) lanza la acción
de los impulsores superiores, las teclas "q" y "w" lanzan
la acción de los impulsores inferiores, y estos
también son lanzados por
el choque con algunos de los reboteadores circulares.
La acción del túnel espacial es lanzada
por la tecla delete (borrar) ¡y también
por el propio túnel espacial! Esto permite
que el juego funcione de forma continuada. Cada vez
que la bola choca contra el túnel espacial, éste
la vuelve a lanzar directamente hacia la
parte superior.
Triangle T 19 0 Rotate
T
Triangle T2 1 1
Square S02 0 2
Square S12 1 2
Square S22 2 2
Square S32 3 2
Square S42 4 2
Square S52 5 2
Square S62 6 2
Square S72 7 2
Square S82 8 2
Square S132 13 2
Square S142 14 2
Square S152 15 2
Square S162 16 2
Square S172 17 2
Square S182 18 2
Circle C43 4 3
Circle C54 5 4
Circle C65 6 5
Circle C76 7 6
Circle C99 9 9
Circle C109 10 9
Circle C1110 11 10
Circle C129 12 9
Circle C139 13 9
Circle C156 15 6
Circle C165 16 5
Circle C174 17 4
Circle C183 18 3
LeftFlipper LF92 9 2
KeyConnect key 32 down LF92
KeyConnect key 32 up LF92 RightFlipper RF112 11 2
KeyConnect key 32 down RF112
KeyConnect key 32 up RF112
LeftFlipper LF87 8 7
KeyConnect key 81 down LF87
KeyConnect key 81 up LF87
Connect C43 LF87
Connect C54 LF87
Connect C65 LF87
Connect C76 LF87
Connect C109 LF87
Connect C1110 LF87
Connect C139 LF87
RightFlipper RF137 13 7
KeyConnect key 87 down RF137
KeyConnect key 87 up RF137
Connect C99 RF137
Connect C1110 RF137
Connect C129 RF137
Connect C156 RF137
Connect C165 RF137
Connect C174 RF137
Connect C183 RF137
Absorber A 0 19 20 20
KeyConnect key 127 down A
Connect A A
Ball B 1.0 11.0 0.0 0.0
Inicio
Sintaxis
formal
<file> ::=
<commandline>*
<commandline> ::= <command>"\n" | "\n"
<command> ::= <gizmoOp> <name> <int-pair>
|
Absorber <name> <int-pair> <int-pair>
|
Ball <name> <float-pair> <float-pair>
|
Rotate <name> |
Delete <name> |
Move <name> <number-pair> |
Connect <name> <name> |
KeyConnect <keyid> <name> |
Gravity FLOAT |
Friction FLOAT FLOAT
<name> ::= IDENTIFIER
<gizmoOp> ::= Square | Circle | Triangle | RightFlipper
| LeftFlipper
<number-pair> ::= <int-pair> | <float-pair>
<int-pair> ::= INTEGER INTEGER
<float-pair> ::= FLOAT FLOAT
<keyid> ::= "key" KEYNUM "down" |
"key" KEYNUM "up"
| IDENTIFICADOR |
|
representa cualquier cadena
compuesta únicamente a partir de los caracteres
{'0'..'9','A'..'Z','a..z','_'}. El identificador
"Barreras externas" es una palabra especial
reservada que se refiere a las barreras
externas; ningún otro elemento puede
utilizar este identificador |
| ENTERO |
|
representa cualquier número
entero |
| FLOAT |
|
representa cualquier número
en coma flotante |
| KEYNUM |
|
representa cualquier identificador
de clave numérica (que
sean números enteros) |
Las palabras claves de Gizmoball
no distinguen mayúsculas y minúsculas.
Inicio
Semántica
-
"Square" (IDENTIFIER
name) (INTEGER x) (INTEGER y)
"Circle" (IDENTIFIER name) (INTEGER x) (INTEGER
y)
"Triangle" (IDENTIFIER name) (INTEGER x) (INTEGER
y)
"RightFlipper" (IDENTIFIER name) (INTEGER x) (INTEGER
y)
"LeftFlipper " (IDENTIFIER name) (INTEGER x) (INTEGER
y)
- Crea la pieza determinada
con su esquina superior izquierda en (x,y),
en la orientación
por defecto. Dentro
del fichero, el name debe ser único
y debe usarse más tarde para referirse a esta
pieza concreta. La orientación por defecto
de cada pieza es:
-
-
-
- Square (cuadrado)
- ninguna (todas las orientaciones
son equivalentes)
- Circle (círculo)
- ninguna (todas las orientaciones
son equivalentes)
- Triangle (triángulo)
- Una esquina en el noreste,
una esquina en el noroeste y la última
esquina en el suroeste. La diagonal va desde la
esquina suroeste hasta la esquina noreste.
- LeftFlipper (impulsor
izquierdo)
- gira en la esquina noroeste,
al otro extremo de la esquina suroeste.
- RightFlipper (impulsor
derecho)
- gira en la esquina noreste,
al otro extremo de
la esquina sureste.
-
"Absorber" (IDENTIFIER
name) (INTEGER x1) (INTEGER y1) (INTEGER x2) (INTEGER
y2)
- Crea un túnel espacial
con su esquina superior izquierda en (x1,y1)
y su esquina inferior derecha en (x2,y2).
La segunda posición debe estar al
menos 1L a la derecha de la primera y a 1L por debajo
de la misma. Dentro del fichero, el name
debe ser exclusivo y puede ser utilizado más
tarde para referirse a este túnel espacial
concreto.
-
"Ball" (IDENTIFIER
name) (FLOAT x) (FLOAT y) (FLOAT vx) (FLOAT vy)
- Crea una bola cuyo centro está
en (x,y) y cuya velocidad es (vx,vy).
Dentro del fichero, el name debe ser exclusivo
y puede ser utilizado más tarde para referirse
a esta bola concreta.
-
"Rotate" (IDENTIFIER
name)
- Da un giro de 90 grados en
el sentido de las agujas del rejo sobre el elemento
llamado name. Observe que algunos elementos
(como el túnel espacial, barreras externas
o las bolas) no pueden ser giradas. El hacer girar
a un impulsor no afecta a su recuadro delimitador,
pero sí modifica su pivote.
-
"Delete" (IDENTIFIER
name)
- Borra el elemento llamado name.
Después de esta operación, el elemento
no volverá a existir.
-
"Move" (IDENTIFIER
name) (INTEGER x) (INTEGER y)
"Move" (IDENTIFIER name) (FLOAT x) (FLOAT y)
- En la primera forma, mueve
la pieza con el nombre de pila de modo que su esquina
superior izquierda esté en (x,y).
En la segunda forma, mueve la bola con el nombre de
pila de modo que su centro esté en (x,y).
-
"Connect" (IDENTIFIER
producer) (IDENTIFIER consumer)
- Hace que la pieza nombrada
por consumer sea un consumidorde los lanzamientos
producidos por la pieza descrita por el productor.
Es decir, cada vez que una bola choca con el productor,
tendrá lugar la acción del consumidor.
-
"KeyConnect"
"key" (KEYNUM num) "down" (IDENTIFIER consumer)
"KeyConnect" "key" (KEYNUM num) "up" (IDENTIFIER
consumer)
- Hace que el elemento nombrado
por consumer sea un consumidor del lanzamiento
producido cuando se pulsa (o se suelta) la tecla que
está representada por num.
-
"Gravity" (FLOAT
g)
- Cambia la gravedad del tablero
a gL/seg2 en dirección
hacia abajo. Este comando invalida cualquier ajuste
previo de la gravedad. Si no aparece el comando Gravity
en el fichero, se debería usar el valor por defecto.
"Friction" (FLOAT
mu) (FLOAT mu2)
- Cambia las constantes de fricción
global a mu y mu2 como se describe
en la fórmula de
fricción. Este comando invalida cualquier
ajuste previo de la fricción. Si no parece
el comando Friction en el fichero, se deberían
utilizar los valores por defecto.
-
Inicio
Apéndice
3: el paquete de Física
La librería de física
que se ha facilitado consta de tipos de datos inmutables
como Angle,
Vect,
LineSegment
y Circle,
además de una clase Geometry
que contiene métodos estáticos para modelar
la física de las colisiones elásticas
entre las bolas y otros círculos y segmentos
de línea. Puede o no utilizar este código
como desee, y modificarlo para cubrir sus necesidades.
La documentación del paquete
physics se encuentra en documentation-code/generated-documentation/physics.
Los ficheros .class compilados en código
byte están guardados en el directorio
/mit/6.170/lib/gb-lib.jar, el cual debería
estar automáticamente en su classpath (ruta
de clase).
La fuente para la librería
de física puede encontrarse en Java-source-code/physics.
Aunque se facilite esta fuente, en el caso de que deseara
examinarla o modificarla, le disuadimos encarecidamente
de lo último. En el pasado, los estudiantes que
no utilizaron la librería de física tal
cual obtuvieron resultados pobres en sus proyectos.
La mayoría de los grupos no tendrán
que copiar el código fuente en sus propios
directorios, añadirlo a sus repositorios CVS
o compilarlo, sino que simplemente utilizarán
el fichero gb-lib.jar y examinarán las
especificaciones.
Inicio
Cambio
de registro
En esta sección se detallarán
los cambios llevados a cabo durante las revisiones de
este boletín. Puede utilizar el número
de versión del final de su fotocopia para determinar
qué ha cambiado desde que imprimió este
boletín.
- v. 02/11/2001:
- Repare Angle.equals()
en el paquete de Física. Introdujo una
tolerancia de EPSILON en la comparación
de igualdades().
Inicio
|
