1er paso: dibujar un cuadrado (final)

Habíamos quedado en dar un cierre al 1er paso dedicándonos a un par de cuestiones decorativas o cosméticas, que habían sido dejadas de lado en su momento cuando desarrollamos el núcleo de nuestro algoritmo.
Pero no por ser accesorias implica necesariamente que deban ser simples o de rápida resolución: muchas veces trabajar sobre los detalles puede llevar tanto o más tiempo que hacerlo sobre lo central. De cualquier manera lo que es seguro es que las cuestiones de detalle también merecen ser pensadas suelen darle a nuestros proyectos un cierre a la altura de todo el esfuerzo previo.

A pensar (again)

Me parece que hay una pregunta clave que nos abrirá un camino en nuestro trabajo:

De lo que queda por hacer ¿qué puede ser considerado un seteo o establecimiento de condición inicial? ¿qué cosa no?

Sobre las condiciones iniciales

Ya hablamos del tema condiciones iniciales en nuestro primer Tutorial. En caso que te haga falta algo más de información para entender de que estamos hablando, dale una mirada a esto.
  • Se pedía que el tamaño del lápiz fuese de 5, y no debía ser cambiado posteriormente >> conviene fijar una condición inicial para esto.
  • Sobre el tamaño de Pier no había indicación alguna, pero vimos que su tamaño original era excesivo >> podemos fijarle un tamaño menor (50%) al principio del programa: es una condición inicial.
  • Los colores de cada lado del cuadrado van a cambiar durante la ejecución del programa, por lo que no tiene sentido hablar de condición inicial aquí, SALVO que querramos que el 1º lado siempre sea azul. En tal caso podemos poner una condición inicial para lograr ésto.
Pero aquí no acaba el asunto: ¿en qué orden lógico deberían ser agregadas al algoritmo/programa estas condiciones iniciales?

A setear se ha dicho

Pensemos (aunque ya la denominación misma de iniciales nos dá una pista). Estas instrucciones en realidad son previas a la ejecución de aquellas que nos permiten alcanzar el dibujo propuesto —que son las que quedaron dentro del bucle—. Si los seteos vinculados al lápiz son hechos después de subir lápiz y antes de bajar lápiz no hay manera que se "arruinemos" nuestro resultado. Y en cuanto al tamaño de Pier… esta propiedad no tiene relación alguna con su capacidad de dibujo.
algoritmo cuadrado
Como ves en la imagen, decidí colocar nuestras nuevas instrucciones justo antes del comando bajar lápiz . Se podrían haber colocado en otro orden, y esto de cualquier manera no hubiese afectado el resultado que estamos buscando: el cuadrado habría quedado igualmente dibujado.
No hace falta que lo diga, abrí el proyecto —en caso que lo hubieses cerrado— y agregá los 3 bloques en cuestión. ¡Voilá, nuestro cuadrado quedó muito melhor!. Es un buen momento para probar a ver que pasa cuando cambiás el orden de las instrucciones previas al bucle… experimentar, que así le dicen. Una vez conforme con el resultado, guardá el proyecto para que se salven los cambios introducidos
Como posiblemente te haya surgido la pregunta (¡ah, así que ahora preguntás vos…!) sobre ese numerito 133 dentro de la casilla de color de lápiz… te pido paciencia porque vamos a hablar sobre la manipulación de colores en Scratch más adelante.
Solo te adelanto que 133 se asocia al azul, 0 al rojo, 33 al amarillo, 67 al verde, 100 al turquesa (o cyan), y así: por ahora para vos será cuestión de fé.

Para que no te quedes mordiéndote las uñas de impaciencia (?), va un dato más para vos: todos los colores "del arco iris" —desde el rojo al violeta— los vas a encontrar entre los valores 0 y 200, pero luego se repiten cíclicamente (what?). Traducido: entre los valores 200 y 400 verás el mismo patrón de colores existente entre 0 y 200 , entre 400 y 600 también, entre -200 y 0… y así sucesivamente —si se te quemó la cabeza eso te pasa por preguntar—.

Conclusión: podríamos haber usado de manera similar para el azul: 133, 333, 533, -67, -267, e infinidad de números más.

Lo que falta

Pier comenzará su dibujo con un lápiz azul [133], y deberá ir cambiando el color del mismo al final del trazado de cada lado: el cambio de color del lápiz es algo que debe ser efectuado durante el transcurso del núcleo del programa. Un buen momento para indicarlo es después del giro de Pier [esto es buscar un orden lógico].
Ahora bien ¿conviene ir fijando nuevos colores para cada tramo? ¿convendrá cambiarlos tomando en cuenta el valor previo? Mientras que la meta se cumpla queda en nosotros buscar el camino más inteligente —creo que es la primera vez que apelo a la idea en en el transcurso del tutorial—.
Si eligieramos ir por la opción fijar color de lápiz a ( ) nos aparecería un problema: no podríamos seguir usando la estructura de control iterativael bucle, bah—, por lo menos sin introducir cambios más profundos en el programa (como ser uso de variables, etc.). Recordemos que nuestra solución iterativa partió de ver que ciertas instrucciones se repetían 4 veces, y por tanto necesitaremos una instrucción que nos permita el cambio de color y que pueda repetirse 4 veces.
Muy distinto es el caso si usásemos cambiar color del lápiz por ( ) en nuestra solución: esta instrucción puede repetirse las 4 veces sin problemas, ¡y por lo tanto puede ser colocada dentro del bucle!
Analicemos los resultados obtenidos si usamos este bloque con el valor 50 —como hice en el algoritmo/programa que ya ves a tu derecha—, y habiendo previamente fijado como primer color al azul [133].
Luego de ser dibujado el 1er lado en azul Pier va a cambiar a un nuevo color: 133 + 50 me darán el color [183] —cercano al magenta, con el que se trazará el 2do lado.
Luego de ser dibujado el 2do lado Pier cambiará al color [233], que como comentamos antes es equivalente al color [33]: amarillo. Cuando se ejecute el bucle por tercera vez para trazar el 3er lado, Pier lo hará con ese color.
Resta un último cambio de color: 233 + 50 me dan el color [283]=[83] —cercano al verde. Nuestro 4to lado tendrá ese color.
Como casi siempre pasa, es más difícil explicar algo poniéndolo en palabras que lo que puede entenderse con sólo verlo en acción (en la nota siguiente aparece un link para ver el proyecto).

Efectuá este último cambio en tu proyecto, guardalo y felicitate: con ésto termina nuestro 1er paso de este Tutorial (¡aplausos también para Pier!)

PARA VER

Podés visitar esta página dentro del sitio de Scratch para ver esta parte del proyecto en acción, e incluso descargarlo (si estás suscripto como usuario).

Lo que viene

Antes que nada… un consejo: si vas a seguir —como así espero— con los siguientes pasos del Tutorial, asegurate de haber entendido con claridad lo que vimos hasta aquí. Te anticipo que en lo que viene la estructura de control del algoritmo no sufrirá mayores cambios, y tampoco hablaremos mucho más sobre este tópico.
El paso que sigue tendrá mucho más que ver con la geometría: vamos a ver como podemos hacer para que Pier dibuje otros polígonos… por ahora dejemos que disfrute de su estrellato —¡las luces de la fama que tanto encandilan!.
Última actualización: Febrero 23, 2014

No hay comentarios.:

Publicar un comentario

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