Estamos en un proceso de migración de contenidos desde el sitio scratchbydsigno.com.ar hacia este nuevo blog.

La prioridad está centrada en los 3 Tutoriales que constituyen la base de dicho sitio, para luego seguir con el resto de los contenidos.

En caso de que encuentres algún error de visualización, o links rotos, puedes comunicármelo usando el formulario de contacto...

1er paso: diseñar el mecanismo (parte III)

Llegó el momento por todos esperado: el momento de programar. Cada uno de las 3 agujas necesitará de al menos un script para que nuestro reloj pueda tomar vida, y su movimiento de giro deberá además reproducir fielmente lo que es esperable de un reloj "real" —por algo hablamos de simulación—.
Pero los scripts también se encargan de algo muy importante para un proyecto: asignar condiciones iniciales a los objetos.
Ya hablamos especialmente en nuestro Tutorial 1 sobre este tópico, y dijimos que allí donde no determinemos condiciones iniciales el mismo entorno Scratch se encarga de hacerlo por nosotros. En esta página trataremos particularmente sobre esta cuestión, y también vamos a complementar la meta primaria de nuestro trabajo con otras metas específicas para este 1er paso. ¡Avanti pues!

Nos encontramos a las 12hs.

Por razones que devienen de nuestro lema de cabecera ("ir de lo simple a lo complejo") en este 1er paso propondremos como meta agregada el que nuestro reloj comience su cronométrica labor a las 12 en punto. El conjunto de metas quedará así:

METAS A ALCANZAR EN ESTE 1ER PASO DEL PROYECTO

  • Todas las agujas deberán estar posicionadas en las coordenadas (x=0, y=0) y apuntando en la dirección 0º.
  • Las dimensiones de las agujas se deben corresponder con los estándares habituales para los relojes analógicos (básicamente, que el tamaño de la aguja horaria debe ser menor a la del minutero).
  • El orden de visualización de las agujas debe ser: primero el segundero, después el minutero y después la aguja horaria.
  • El movimiento de giro del segundero se efectuará mediante "saltos de posición" a razón de 1 vez por segundo.
  • El movimiento de giro del minutero se efectuará mediante "saltos de posición" a razón de 1 vez por minuto.
  • Respetando lo que ocurre con los relojes analógicos "reales", la aguja horaria irá moviéndose al ir transcurriendo el lapso de una hora (explicado de otra manera, a las y media estará a mitad de camino entre las dos horas que correspondan).
    En nuestro caso optaremos por lo siguiente: que sus "saltos" de posición se efectúen a razón de 1 vez por minuto —a la par del minutero—
Como podrás ver las tres primeras metas se corresponden a las condiciones iniciales que deben presentarse en los 3 objetos. Son condiciones que se deben cumplir más allá de que el reloj este "en funcionamiento" o no.
Las tres restantes están vinculadas a la manera en que se debe desarrollar el movimiento de rotación de las agujas. Fijate que más allá de las relaciones de "velocidad de giro" que tienen que cumplirse entre las agujas de cualquier reloj analógico, dejamos perfectamente especificado con que frecuencia deben producirse los cambios de dirección —saltos de posición— para cada uno de los objetos.
Esto quedará más claro, como siempre, cuando lo veamos en funcionamiento.

Las 3 primeras metas

Vamos a dedicar lo que queda de esta página a generar el establecimiento de las condiciones iniciales para los 3 objetos. Sin importar el estado en que haya sido detenido o guardado el proyecto, nos proponemos "forzar" a los objetos a comenzar su funcionamiento de tal manera que nuestro reloj indique las 12 hs.

Meta nº 1: posicionar los objetos

Estoy presuponiendo que ya desplazaste el punto centro de disfraz siguiendo las indicaciones dadas en la página previa. Creo que pensar cuales son los bloques necesarios para cumplir la meta 1 es una tarea más que simple —salvo que seas muy nuev@ en Scratch—: al arrancar el programa con bandera verde lo primero que se le tiene que instruir a cada uno de los objetos es que se posicionen con coordenadas (x=0, y=0) y apuntando en la dirección 0º (hacia arriba). Simple.

Meta nº 2: dimensionar los objetos

De nuevo voy a presuponer que usaste las 3 imágenes suministradas en la página anterior como disfraz de los objetos. De no ser así y encontrarte con algún problemilla para dimensionar los objetos podés encontrar ayuda en esta página.
Las imágenes de las 3 agujas fueron diseñadas teniendo en mente que tuviesen el doble del tamaño óptimo para nuestro reloj (esto facilita el proceso de desplazamiento del centro de disfraz). Por lo tanto dimensionarlas requerirá de la utilización de un bloque fijar tamaño a (50)%. De nuevo simple.

Meta nº 3: dar un orden de visualización (principio)

Si ya aplicaste las condiciones iniciales propuestas debés estar viendo la superposición de las 3 agujas del reloj. En caso de que no hayas utilizado el mouse para reubicar a alguna/as de ellas por el escenario, el orden de visualización debería ser el siguiente: la aguja horaria, el minutero y por debajo de ambas se verá el segundero.
¿Por qué sucede esto? Porque en Scratch los objetos incorporados de forma más reciente se van ubicando por sobre los objetos previos. Conceptualmente hablando, esto tiene que ver con la manera en que Scratch se resuelve el manejo de las capas de visualización; en nuestro caso específico es el orden que Scratch dio por defecto.

Aclaración

Durante el transcurso de la escritura del Tutorial 1 dediqué una página específica al tema Capas en Scratch, en la cual además detallé uno de los posibles métodos que pueden usarse para determinar el ordenamiento de las capas. Tal método puede aplicarse a ciertos casos particulares (aunque muy frecuentes), y en él no se apela a la programación para su resolución.
Como ya irás sospechando, lo que intentaremos ahora es resolver el problema del ordenamiento usando bloques de programación. Aprovecharemos también para complementar el trabajo empezado en aquel ya lejano Tutorial 1, por lo cual quizás te sea indispensable darle una mirada a lo allí expuesto…

Controlar el orden de las capas (II)

Si en tu lectura/relectura recién recomendada llegaste a la comprensión de la "metáfora de la baraja de cartas", es que vamos bien. Ya declaré en su momento lo que constituye mi principal crítica a Scratch como entorno de programación:

…la metáfora de la baraja que usa Scratch termina conspirando contra un control claro del ordenamiento de las capas vía programación (lo más probable es que al mover una capa se afecte el ordenamiento de muchas más).

Por suerte para nosotros en el proyecto sobre el que estamos avanzando sólo se requerirá ordenar una sola vez las capas intervinientes (lo que se hará efectivo mediante el establecimiento de condiciones iniciales). Tres objetos son solo tres capas para ordenar, tres capas son solo tres naipes en la baraja.
Desde el punto de vista de la programación contamos con 2 bloques para "jugar" con el ordenamiento de las capas. Si bien su interpretación dista de ser complicada, sus efectos pueden ser no tan previsibles: recordemos que el reordenamiento de una capa afectará siempre el orden de las restantes, ya que la cantidad de capas está limitada por la cantidad de objetos (hay tantos naipes como objetos).

Nota

Antes de avanzar en la solución de nuestro problema, pongamos de manifiesto la gran potencialidad que encierra el uso de estos bloques: no sólo nos facilitarán imponer condiciones iniciales al orden de las capas, sino que durante la ejecución de un programa también nos permitirán alterar este orden inicial en caso de que fuese necesario —tenlo en cuenta si en algún futuro proyecto te enfrentás a este problema, aunque en la gran mayoría de los proyectos el orden de visualización permanece inalterable de principio a fin—

Una primera forma de solución

En este método usaremos sólo 1 de los 2 bloques recién presentados. La estrategia tendrá algo de parecida a aquella que dimos en el primer Tutorial, pero en este caso usaremos bloques de programación. La idea es ir llevando al frente en orden cronológico a cada uno de los objetos, empezando por el que debe terminar más al fondo —el minutero en nuestro caso—, siguiendo por la aguja que debe quedar en medio —la de la hora—, y finalizando por la que debe terminar quedando definitivamente al frente —el segundero—
¿Cómo conseguir ésto? Simplemente agregando un bloque de espera antes de la instrucción que produce el envío al frente (en todos los objetos).
La clave es adecuar estas esperas para que la ejecución de los bloques enviar al frente se dén en tiempos distintos para cada uno de los objetos… ¿te dás cuenta? Probalo.
NOTA: el bloque de espera en la aguja horaria podría haberse obviado.
Este método creo que resultará bastante comprensible una vez que lo vemos en funcionamiento, más aún si tenemos la metáfora de la baraja en mente. Presenta sí un efecto visual que puede resultar molesto, ya que el reacomodamiento de las imágenes va a manifestarse cada vez que arranquemos el programa… en esto difiere totalmente de la solución mencionada en el Tutorial 1.

Otra forma de solución, alias
"Meta nº 3: dar un orden de visualización (final)"

Si, se me mezclaron los subtítulos. Vamos a cerrar el desarrollo que iniciamos más arriba mostrando la solución típica que se utiliza en Scratch para este tipo de situaciones de ordenamiento de capas. En este caso usaremos los dos tipos de bloques que nos brinda el entorno para el manejo de capas… ya estas viendo como quedan los scripts para cada objeto.
Supongo que ya te habrás percatado de la idea que se esconde detrás del armado de los bloques aquí propuesto: intentamos la colocación de la capa de cada objeto tomando siempre como referencia a la capa que queda al frente (es como decir: enviar una capa debajo de la de arriba, enviar dos capas debajo de la de arriba, y así…).
NOTA: el bloque que indica el envío 0 capas hacia atrás en el segundero podría haberse obviado.

...metáfora?

Debo admitir sin sonrojo alguno que no consigo asociar esta solución con la consabida metáfora, ya que según la misma es imposible que haya más de una primera carta, y es imposible que los 3 objetos se encuentren simultáneamente al frente.
Pero la realidad indica que funciona. "E pur si muove" diría don Galilei… "creer o reventar" diría yo.

A armar los scripts 

[A esta altura creo que están casi de más estas palabras]. Reabrí el proyecto en el que estamos trabajando, y verificá que no exista ningún script de testeo "dando vueltas" en el mismo. Procedé luego a generar el script correspondiente a cada uno de los objetos de acuerdo a lo que mostramos en las últimas tres imágenes.
TIP: te aconsejo que armes primero un script y, haciendo clic derecho sobre él, elijas la opción duplicar en el menú emergente. Ya con esa copia "pegada" al puntero del mouse, haz clic sobre alguno de los 2 objetos restantes para pegarlo. Repetí después en el otro. Obviamente deberás luego cambiar el número en los bloques enviar hacia atrás ( ) capas.
Verificá que todo funcione OK, y procedé a guardar el proyecto para salvar estos últimos cambios realizados.

Hasta el momento logramos responder al desafío de las 3 primeras metas casi con elegancia. En ellas se concentran todas las condiciones iniciales que deben fijarse en nuestros objetos/agujas… ¡pero queremos ver a nuestro reloj en funcionamiento!
Nos queda avanzar sobre la parte central de este 1er paso: simular el mecanismo de relojería. Hacia allí vamos.
Última actualización: Marzo 2, 2014

No hay comentarios.:

Publicar un comentario

© Scratch CodeLab | D153ñ0 b454d0 3n l4 pl4n71ll4 SimpleRWD d3 Oloblogger