| |
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.
|
