Piedra, papel o tijera… en Arduino, Scratch o lo que usted quiera
¡Aloha seguidor del rufianismo! Aquí ando, liado con el verano. Aunque vaya verano más light, ¿Cuando empiezan las fiestas y esas cosas? En fin, hoy vuelvo al tema infantil y vuelvo con el mítico juego: Piedra, papel o tijeras.
La idea inicial era lo más. Un juego para niños con 3 botones cada uno que montan y luego por parejas programan el juego. Buah, un ejercicio interesante cuanto menos. O eso me parecía a mí…
Si estás ya metido en el mundo de S4A, sabrás porqué no se puede hacer el maldito juego 🙁 Aunque igual te pasa como a mi y hasta que no estés enfrente de ello no te des cuenta. Te voy a contar el problema. S4A no tiene más que para detectar dos botones, uno en el pin digital 2 y el otro en el 3. Así que andamos muy vendidos en este tema.
Para probar el juego hay que volver a utilizar Scratch.
Niños con el piedra, papel o tijera en Scratch
En Scratch, lo primero que tendrán que hacer tus mozos y mozas será crear 6 objetos: 2 piedras, 2 tijeras y 2 papeles. De manera que al elegir uno cada uno se enfrenten. Esto es tan sencillo como en ‘Nuevo Objeto’ pintar un nuevo objeto o escoger alguno del archivo. Sencillo. Al gato sería una cortesía que no se lo cargarán ya que será el árbitro del juego. Será el que indique si estamos ante un empate o si gana el jugador 1 o el 2.
Para ello lo que harán será conseguir que al pulsar uno de los objetos sepamos que se ha pulsado. Y una vez hecho eso habrá que conseguir que el gato, nuestro árbitro, decida quién gana. La parte difícil será la del gato ya que es el cerebro del programa. Es el que dice que piedra gana a tijera, que tijera gana a papel y que papel gana a piedra. Que para nosotros es lo más normal del mundo pero para un ordenador… no lo es tanto.
Lo primero será decidir o pensar cómo hacer para avisar a todo el mundo que se ha pulsado ese botón. El primer impulso es utilizar los mensajes de Scratch para informar a todos de que se ha pulsado el botón. Sería una buena idea pero además habría de tenerse alguna variable o similar para entrelazar los mensajes.
Quiero decir, cuando se envía un mensaje se crea un evento. Pero en este caso vas a crear dos y te tienes que fijar en dos. Pero los eventos no dejan que los utilices de dos en dos. O es uno u otro. Total, que te complicas la existencia. Lo suyo es ir a parar a aquello que sirve para guardar cosas en la programación: las variables.
Para ello lo que vas a hacer es crear dos variables, una para el jugador uno y otra para el jugador dos (bueno las puedes crear tú o tus niños, que para esto no hay edad). Y luego iremos objeto a objeto fijando la variable de cada jugador a piedra, papel o tijeras. Tal vez no sea evidente, que yo lo veo aquí en mi pantalla y parece algo obvio, así que te dejo esta imagen:
Al presionar el objeto (Por eso se debe programar en cada uno de los 6 objetos: piedra, papel y tijeras) fijo la variable del jugador uno a piedra. Podría haberla fijado a papel o tijeras. Y luego fijaré la piedra del jugador dos a piedra, pero usando la variable que he creado para el jugador dos.
Una vez hecho esto las seis veces la primera parte está resuelta totalmente. Ahora lo que toca es crear el cerebro…
Programando los casos del juego
Para eso vamos a programar a nuestro querido gato, al cuál pueden maquear para que parezca un verdadero árbitro de boxeo. Con ring (¿ring? ¿Esto se escribe así? El lugar dónde se dan tortazos los del boxeo, ya me entiendes) incluido.
Para ello lo que hay que hacer es poner una banderita para empezar el juego y utilizar la función si para saber si se produce cada uno de los casos. Cuando digo casos quiero decir si un jugador saca piedra y el otro papel, si sacan lo mismo…
Como ves, es utilizar dos bloques de la sección Operadores. El de y y el de =. Además, tienes que ir a variables y cogerlas para ponerlas dentro. Tijeras, piedra y papel es algo que deberás escribir tú mismo. Si te fijas, además añado el bloque de la sección variables llamado fijar. Esto lo hago para evitar que se queden guardados los valores en cada partida.
Que se quedasen guardados podría implicar que si el jugador uno saca piedra y el otro también pero el uno cambia rápidamente a tijeras, perdería sin que el jugador dos hiciese nada. Así nos aseguramos, junto a la espera, que cada partida es justa y que vamos a esperar un tiempo y evitaremos así cambios rápidos en variables.
Si te fijas en el ultimo si, ahí lo que he hecho ha sido unir 3 operadores o y en cada uno he puesto los casos de empate. Esto ha sido por ahorrar. Tus hijos pueden definir los casos igual que antes sin problemas pero yo he preferido hacerlo más rápido. Y nada, ya pueden probar a jugar.
Mejorando el juego…
Si te das cuenta la solución anterior es una auténtica basura ya que solamente hay un ratón, entonces el jugador dos espera a que el uno juegue y de ahí puede elegir claramente el bueno. Esto es solamente para que comprueben que funciona correctamente el programa. Una vez saben que funciona bien pueden modificarlo para que en lugar de tocar el objeto, el evento sea al pulsar una tecla determinada. Así puede ser que uno juegue con las letras a, s, d y el otro juegue con las letras j, k, l.
Esto es sencillo, en la sección control en lugar de elegir al pulsar el objeto se elige al pulsar la tecla. Nada complicado. A partir de aquí son libres: pueden agregar un contador, pueden agregar animaciones para cuando uno gana. Incluso un baile para el que sea el mejor de tres.
Información básica sobre Proteción de datos
Responsable ➥ Sergio Luján Cuenca
Finalidad ➥ Gestionar el envío de correos electrónicos con artículos, noticias y publicidad. Todo relacionado con los temas de rufianenlared.com
Legitimación ➥ Consentimiento del interesado
Destinatarios ➥ Estos datos se comunicarán a MailRelay para gestionar el envío de los correos electrónicos
Derechos ➥ Acceder, rectificar y suprimir los datos, así como otros derechos, como se explica en la política de privacidad
Plazo de conservación de los datos ➥ Hasta que se solicite la supresión por parte del interesado
Información adicional ➥ Puedes encontrarla en la política de privacidad y el aviso legal
¿Y qué me dices de programarlo en Arduino?
Como me he quedado un poco raro por no poder programarlo en S4A he estado pensando durante este rato que llevo escribiendo y creo haber encontrado una solución al problema. No la he probado pero estoy al 98% seguro que puede funcionar (vaya gilipollez lo de poner un porcentaje que me acabo de inventar). Más que nada porque es simple de cojones.
La idea es la siguiente: al pulsar un botón se crea una señal de 5 Voltios y cuando no está pulsado una de 0 Voltios. Bueno, pues lo que haríamos sería conectar los pulsadores a los pines analógicos. S4A permite coger (lo siento argentinos del mundo) como variable el valor de estos sensores por lo que solamente habría que programar que el valor de esos pines sea superior a 1 Voltio. Recuerda que aquí no funcionamos por Voltios sino que será el equivalente a 1 Voltio (Por no pillar cero voltios, por si acaso) si el total es 1024. Al final sería una quinta parte de 1024, que con calculadora en mano ronda los 205. Así que quedaría algo como esto:
Ya te digo que podrías usar un 1 en lugar de 205, pero más vale prevenir que curar. Nunca se sabe si no identifica cero exactamente y se confunde con algún número. Lo demás es igual: hay 6 botones y luego el cerebro. Es totalmente idéntico. Así que espero que haya suerte con los más pequeños. ¡Nos vemos en las redes sociales! 🙂