0:04
Tenemos bastantes cosas para programar en este juego,
por lo que empecemos por descomponerlo.
Una forma natural de dividirlo en partes más
pequeñas sería identificar los diferentes elementos que tenemos que programar.
Así tenemos la escoba, el zombie, la flor y el escenario.
Ahora vamos a descomponer cada uno de ellos.
Comenzaremos programando el personaje, que en nuestro caso el
que elegimos tiene disfraz de escoba.
Su programa incluye en seudocódigo: iniciar y por siempre, ir a la posición del ratón.
El comportamiento de tocar el zombie con la escoba lo programaremos en el zombie.
El inicio incluye posicionarlo en el centro y dar las instrucciones.
Para dar las instrucciones podríamos haber elegido cualquiera de
los personajes de nuestro juego, pero seleccionamos la escoba ya
que es el personaje principal con el cual el usuario controla este juego.
Las instrucciones podrían incluir frases como: mueve el
ratón para alejar a los zombies, evita que lleguen a la casa.
El objetivo del juego es alejar la mayor cantidad de zombies,
o sea, obtener un puntaje bien alto.
En el momento que llega alguno, terminó.
Ojo, es importante mencionar que los zombies no deberían aparecer mientras la
escoba esté dando las instrucciones, para que el juego sea justo para el jugador.
Cuando diseñemos el código del zombie tendremos que tener esto en cuenta.
¿Cuántos zombies deberíamos tener?
Queremos una cantidad ilimitada de zombies durante el juego pero,
¿cómo haremos para lograrlo?
Usando clones, ¡claro!.
El programa del zombie incluye el inicio y
por siempre, crear un clon y esperar un breve tiempo.
¿Con qué frecuencia crearemos los clones?
Para responder esta pregunta,
pensemos un poco más en los requerimientos que tenemos.
Queremos que nuestro juego tenga diferentes niveles de dificultad.
Podemos hacer que los zombies aparezcan cada cierto tiempo que
podremos establecer.
Para un juego difícil, el tiempo será pequeño y
para un juego más fácil, el tiempo será más grande.
Para registrar el tiempo entre la creación de los zombies y
poder modificarlo necesitaremos una variable.
Además de esta variable, necesitaremos otra para llevar el puntaje.
Ambas variables serán inicializadas en el bloque de inicio del zombie.
El tiempo entre zombies, por ejemplo, en cinco y el puntaje en cero.
Y también tendremos que esperar un breve tiempo para permitir que el
jugador lea las instrucciones.
Vamos a diseñar ahora el comportamiento del zombie cuando empiece como clon.
Primero será ubicado sobre la derecha del escenario,
luego se moverá continuamente hacia la izquierda chequeando si
está tocando la escoba, la flor o si llegó a la casa.
Cuando toca la escoba se emite un sonido,
se cuenta un zombie más atrapado y el zombie regresa.
Cuando toca la flor, espera por un breve tiempo.
Si llega a la casa, o sea a la zona izquierda de la pantalla, termina el juego.
Ya detallaremos más adelante qué significa que terminó el juego.
Ahora pensemos un poco más en el movimiento del zombie.
¿Cuán rápido debería moverse?
Podríamos especificar su movimiento por ejemplo, en cinco o 10 pasos cada vez.
Otra opción para hacerlo más divertido y
desafiante es hacer que cada cinco segundos los zombies aumenten su
velocidad y así resultará más difícil alejarlos a todos.
Para implementar esto necesitaremos una variable para la velocidad del zombie,
o sea, para la cantidad de pasos que debe moverse.
¿Dónde debemos iniciar esta variable?
¿Y dónde la debemos modificar?
Como afecta a todos los clones creados, esto nos indica que la debemos
iniciar en el mismo bloque del inicio del zombie, por ejemplo, con el valor cinco.
Para poder modificarla cada pocos segundos necesitamos otro
programa o script dentro del objeto del zombie, que se ejecuta al mismo tiempo.
>> Inés: ¿por qué necesitamos otro script?
¿No podría ponerlo en el mismo bloque del por siempre crear clon y
esperar el tiempo entre zombies?
>> No, Cody.
Y te cuento por qué.
Si la pusiéramos ahí, el proceso sería diferente.
Sería por siempre, se crea un clon,
se espera un tiempo entre la creación de los clones, luego se debería
esperar los cinco segundos que dijimos, y finalmente se modificaría la velocidad.
Pero no es éste el comportamiento que queremos.
Queremos que los dos procesos se ejecuten en forma simultánea.
En ciencia de la computación decimos que son procesos concurrentes.
>> Ah, bien, bien.
>> La concurrencia es muy común en la vida diaria.
Por ejemplo, cada uno de los chefs de un restaurante prepara varios platos al
mismo tiempo.
Por ejemplo, puede estar hirviendo papas, cocinando carne en un horno,
cortando vegetales, todo simultáneamente.
Y si miramos el restaurante en general, el comportamiento de los chefs es concurrente
con el de los mozos y los encargados, están todos trabajando a la vez.
La concurrencia es un concepto importante en la ciencia de la computación.
En Scratch es muy fácil crear programas concurrentes.
Y si lo pensamos, muchos de los programas que hicimos son, por cierto, concurrentes.
Por ejemplo, en el juego del Pong, el programa de la pelota y
el de la paleta se ejecutan a la misma vez.
Ahora, analizaremos la parte del código correspondiente a la flor.
Cuando empiece el juego, queremos poner varias flores en el jardín para entretener
a los zombies, por ejemplo, entre tres y 10 flores y que su cantidad varíe al azar.
El seudocódigo sería: repetir una cantidad al azar de veces, crear clon.
Bien, ahora, ¿cuál será su comportamiento cuando empiece como clon?
Sería: posicionar la flor en algún lugar de la pantalla, repetir hasta que
la toque el zombie, cambiar de disfraz por un breve tiempo para simular la animación,
finalmente borrar el clon, o sea, una vez que fue tocada, desaparece.
Y pronto.
Ahora trabajaremos por el escenario.
Cuando comience el programa debe tener el fondo del jardín y la casa.
Hemos diseñado dos fondos para el escenario y
decidimos que, una vez que el juego termine, cambie el fondo del jardín y
la casa a uno que indica que el juego terminó.
¿Qué más debe ocurrir cuando el juego termina?
Todos los programas o scripts deben detener su ejecución.
Este comportamiento puede ser programado en el escenario.
Bien, hemos hecho la descomposición de nuestro programa y
tenemos un diseño detallado de nuestro código.
En el próximo video construiremos nuestro juego en Scratch.
Inés Friss de KerekiPhD
Dr Areti ManatakiTeaching and Research Fellow
