Programando un juego

En esta página vas a aprender cómo construir un juego sencillo en el que el jugador trata de hacer clic en un personaje que se mueve alrededor de la pantalla.

We've removed the "uncheck the draggable box" instruction completely and moved it to the starter project. That's fine, but it should be explained in the TG (and maybe a yellow sidebox) so that students who try to build their own version of the project don't get tripped up by that. What do you think about a sidebox? --MF, 11/11/19

Also, we should be sure that we teach about adding (and perhaps editing, though I'm less attached to that) costumes somewhere because personalizing is a big part of beauty and joy for many students. --MF, 11/11/19

BTW, I'm experimenting with slightly smaller font for the yellowboxes. Thoughts? (I imagine you, Brian, saying something about how we didn't like the H4 but now I'm trying this. It's a totally different thing to whisper a hint to a student than to yell at them to listen. ;) I'm still wanting to get to an intuitive CSS where students don't have to memorize a bunch of colors. (You'll recall that we aren't going to upload the CSS this week; we'll do it once we are all happy with everything.) --MF, 11/11/19

That's fine, but you made it smaller (.9) and then smaller again (.85). That's too small. I made it .92; can you live with that?  What's not fine is that some time ago, you (or someone) made h4 smaller than the regular body font!  Headings aren't supposed to be smaller than the text.  :-( -bh

Hagamos que el personaje se mueva

  1. Debes asegurarte de tener una sesión iniciada en Snap! para guardar el trabajo.
  2. Haz clic aquí para bajar el archivo. Luego guárdalo en tu cuenta de Snap!.

I moved the discussion of "sprite" here because it was confusing to introduce it along with "costume" on page 4 by saying that they are both called Alonzo. I know you, Brian, don't like vocab boxes for non CSP things, and I'd like to discuss what to do about that, in general, with Paul, and then address what would be the appropriate change here. If you have feedback on moving "sprite" here at all (regardless of how it's formatted), now is a good time for that. --MF, 11/11/19

The alleged definition is bad, because it misses the point that sprites are the actors of this world, the entities that know how to do things.  I'm not suggesting that we have to go into that here, but no definition at all would be way better than a pretend definition that'll have to be revisited later.

But also, the word "vocabulary" is teacher-speak for "this is incredibly boring, even more boring than the rest of the textbook, but you're going to have to commit it to memory anyway for no good reason."  That is so totally not what we want kids to see on the first day!  The fact that it's our own working vocabulary rather than College Board vocabulary takes third place in the reasons I don't want this. -bh

Alonzo character Conoce a Alonzo, la mascota del lenguaje de programación Snap!. Se encuentra en el escenario, la sección blanca en la esquina superior derecha de la ventana de Snap!

Un personaje (sprite) es una gráfica que se puede mover.

picture of Snap! window with white rectangle at right labeled 'Stage' and yellow character on that stage labeled 'Sprite named Alonzo'

I also added "Scripting Area" to the image above and to the problem statement for #3. OK? --MF, 11/11/19

I'm okay with "scripting area" in the picture.  I have a slight preference for not italicizing it in fytd 3, even though it's a technical term, because it sounds as if we're expecting them to drag it someplace else by mistake. -bh

Vamos a programar un juego con la meta de atrapar a Alonzo haciendo un clic mientras se mueve en el escenario.

  1. El primer paso es hacer que el personaje de Alonzo salte al escenario cuando es seleccionado. Arrastra los siguientes dos bloques en el área de trabajo (el área central de la ventana):

    I think this box should stay where it is and should be narrower green. And that makes me want to split off color from width in the CSS, and that's a cross-course find and replace that I'm only going to do after a convo with BH. --MF, 11/8/19

    I don't think you have to sweep through the entire curriculum. You can just program the existing CSS styles as abbreviations for a combination of styles, e.g., "sidenoteBig" abbreviating "medium paleYellow right" or something. -bh

    Paleta de funciones: Movimiento, Apariencia, Sonido, Lápiz, Control, Sensores, Operadores y Variables

    Puedes encontrar los bloques en la paleta de funciones con un color característico. Arrastra un bloque debajo de otro para encajar y pegarlos.

    when I am clicked, go to [random position] go to () block with menu open showing 'random position', 'mouse pointer', and 'center'. The mouse pointer is hovering over 'random position'.
    Brian, can you remake this image so that it doesn't look like you need to click some particular part of that menu option? --MF, 11/8/19
    CRD-2.B.1

    Este es un programa de computadora, también conocido como software. Este es un muy pequeño, pero pronto se va a poner mucho más interesante.

  2. Probemos el programa. Haz Clic varias veces en el personaje de Alonzo sobre el escenario. Si el programa funciona, Alonzo debería moverse a una posición aleatoria en el escenario cada vez que se le presiona con un clic.

Te recomendamos guardar tu trabajo frecuentemente.

  1. Selecciona la opción "Guardar" en la opción del menú Archivo en Snap!, Botón Archivo.

Hagamos el juego más interesante

El juego no es tan divertido si Alonzo está sentado esperando para que le hagamos clic. Luego que le hemos hecho clic por primera vez, él debería seguir saltando alrededor. Para hacer que Alonzo siga moviéndose alrededor, necesitamos el bloque de control que dice "hacer esto por siempre."

  1. Un conjunto de bloques que trabajan juntos es llamado un script(guión).
    Agrega lo siguiente al script de Alonzo:
    por siempre { ir a (posición aleatoria) }

    I think it's fairly likely that some students will end up with when i am clicked, go to random, forever (go to random). In which case, they miss two things: 1) learning (conceptually) that that code structure is redundant and 2) learning (practically) how to put a C-block around something that already exists in the code. How much do we care about those things at this point in the course? --MF, 11/11/19

    We totally want kids to have two GO TO blocks, one before and one inside the FOREVER. That's crucial when they add more code for the ghost effect. If you think there's any chance of a kid not having two GOTO blocks, we should address that somehow, probably just in the TG. -bh

    La secuencia de instrucciones dentro del bloque por siempre se repetirá hasta que tu hagas clic en el botón rojo, botón rojo de alto, o bien detengas el programa de otra forma.
  2. Alonzo se mueve muy rápido. Utiliza el bloque espera 1 segundo para hacerlo más lento. Puedes probar tu programa reduciendo e incrementando el tiempo de espera.
  3. Ahora es un buen momento para guardar tu trabajo

    4. I've always been mixed about whether to put these in an LI or not, and I think we've been inconsistent. Here, I think it's nice to put it in an LI. As a general rule, I could see myself being content with, "it goes in an LI if it's a left-aligned, icon with the text, and it doesn't if it's right-aligned as a mini-icon." Thoughts, Brian? --MF, 11/11/19

    I think in 1.1 we make it a LI but after that we use the small icon, introducing it explicitly the first time.  But (a longer discussion) I think all the small icons should go on the left, not the right. -bh