Você está na página 1de 32

Apostila de Scratch 2.

0 – Fellowship of the Game


De Marcos Henrique de Paula Dias da Silva
dificildedizer@gmail.com

Índice
Hora 1: Ode Alegria
Hora 2: (Hora 1 alternativa): Blá blá blá
Hora 3: Perguntas e respostas

Hora 4: Jogo de muitas perguntas


Hora 5: Movimentos do ator (parte 1)
Hora 6: Movimentos do ator (parte 2)

Hora 7: Jogo do polvo


Hora 8: Jogo de pegar a chave
Hora 9: Sprites/Fantasias

Hora 10: Fugindo dos raios (parte 1)


Hora 11: Fugindo dos raios (parte 2)
Hora 12: Fugindo dos raios (parte 3)

Hora 13: Bingo


Hora 14: Forca (parte 1)
Hora 15: Forca (parte 2)

Hora 16: Jogo da Bruxa


Hora 17: Jogo da Bruxa
Hora 18: Jogo da Bruxa

Hora 19: Projeto Livre


Hora 20: Projeto Livre
Hora 21: Projeto Livre

Hora 22: Projeto Livre


Hora 23: Projeto Livre
Hora 24: Projeto Livre
Introdução:
Esta apostila está distribuída em oito aulas, cada uma com duração prevista de três horas e
voltada para alunos do Ensino Fundamental ciclo II. O Scratch 2.0 está disponível para uso online e
também para offline, ambas podendo ser providenciadas através do link https://scratch.mit.edu/.
Recomendo para o bom andamento do curso e que cada aluno tenha acesso à um computador com
uma versão do Scratch 2.0 offline.

Hora 1: Ode Alegria


Comece a aula se apresentando aos alunos, perguntando com que frequência eles usam o
computador e se já tiveram alguma experiência com o Scratch 2.0 ou com programação. Estas
perguntas serão importantes para aproximar os alunos do professor, permitindo que eles se
expressem e tirem dúvidas com menos receio. Além de permitir que o professor estime as
dificuldades que eles possam ter no uso do programa dado a experiência que possuem com
computadores. No caso de algum aluno ter alguma experiência com programação ou com o Scratch
2.0, recomendo que explore estas experiências prévias usando-as como assistência para a
aprendizagem dos demais alunos.

No Scratch 2.0, chamaremos a lista de opções coloridas ao


lado direito do gato laranja (imagem à direita), de categorias. Desta
forma, peça que os alunos cliquem na categoria “Som”. Isto fará
com que uma lista de botões da mesma cor que a categoria “Som”,
apareça logo abaixo. Podemos ativar estes botões ao clicar neles.

Com os fones de ouvido, cliquem no primeiro botão do topo


da lista, “toque o som [meow]”. Ouviremos o som de um miado. A área cinza mais escuro ao lado
direito dos botões, chamaremos de “Área de trabalho”. Assim, podemos clicar num botão e sem
soltar o clique, arrastá-lo para a “Área de trabalho”, para só então soltá-lo. Para removê-lo da “Área
de trabalho”, podemos clicar no botão com o botão direito do mouse e selecionar a opção “Apagar”,
ou simplesmente puxar o botão para a lista de botões e então soltá-lo. Ambos os métodos são
eficientes, mas considero o segundo método bem mais conveniente.

Arraste o botão “Toque a nota [60] por [0.5] batidas” para a “Área de trabalho”. Se
clicarmos com o botão direito do mouse sobre qualquer botão, veremos também a opção “Ajuda”.
Ative a opção “Ajuda” para este botão, veja que do lado direito da “Área de trabalho”, abre uma aba
explicando o funcionamento do botão. A explicação fornecida pelo Scratch 2.0 é bastante clara,
ajudando o usuário a entender e usar o botão. Recomendo que quando o funcionamento de algum
botão não for claro, que esta opção seja acessada.

Contudo, ativar os botões atráves do clique do mouse sobre eles, não é conveniente. Clique
agora na categoria “Eventos”. Puxe para a “Área de trabalho” o botão “quando a tecla [espaço] for
pressionada”. Veja que este botão ao se aproximar do “toque a nota [60] por [0.5] batidas”, geram
uma faixa branca entre os dois. Solte-o quando houver esta faixa branca e os botões se unirão.
Agora sempre que teclarmos [espaço], o botão “toque a nota [60] por [0.5] batidas” será ativado.

Construindo um instrumento musical:


Clicando com o botão direito do mouse no botão “quando a tecla [espaço] for pressionada”,
selecione a opção “duplicar”. Esta opção duplica todos os botões abaixo do botão que foi clicado.
Repita este processo 6 vezes. Para cada par de botões (Evento + Som), altere a tecla de ativação e as
notas de cada uma. Crie para 7 teclas diferentes que ativem as notas Dó, Ré, Mi, Fá, Sol, Lá e Si.

Veja que ao lado de cada nota tem [0.5] batidas. Poderíamos alterar uma a uma sempre que
quisessemos modificar a frequência do instrumento. Mas existe uma maneira bem mais simples de
fazer isto.

Clique na categoria “Variáveis”. Então clique na


opção “Criar uma variável”. Crie a variável chamada
batidas e com a opção “todos os atores” ativa. Agora
arraste para a “Área de trabalho” o botão que surgiu com
a criação desta variável, “mude [batidas] para [0]”. Então
arraste o botão “batidas” para o espaço destinado a
“batidas” em cada um dos botões de “Som”. Assim, o
valor da variável “batidas” pode ser alterado usando o
botão “mude [batidas] para [0]” e então clicando no
botão, a variável se altera. Com isto, todas as notas
podem ter seu número de batidas alteradas através de um
só botão. Ao lado temos a configuração dos botões em
seu formato seguindo as instruções desta apostila. Abaixo
segue um link para acesso a um projeto de instrumento
musical criado conforme estas instruções.
https://scratch.mit.edu/projects/90490572/

Experimente agora modificar o número de batidas


e ver como isto influência o som das notas. Peça que os
alunos que saibam alguma melodia tente tocá-la. Tentem
encontrar o número de batidas que melhor combina com a
melodia tocada. Abaixo seguem as notas iniciais de Ode
Alegria. Experimente também tocá-las e alterar as batidas
para este caso também.

Mi – Mi – Fá – Sol – Sol – Fá – Mi – Ré – Dó – Dó – Ré
– Mi – Mi – Ré – Ré

Agora puxe para a “Área de trabalho” o botão “use o instrumento [1]” da categoria “Som”.
Clicando na seta ao lado do número 1, vemos uma lista de opções de instrumento. Experimente
ativar alguns deles e tocar as mesmas melodias com outros instrumentos. E com insto encerramos
nossa primeira aula deste curso.

Hora 2 (ou Hora 1 alternativa): Blá blá blá


Para o completo domínio do curso, recomendo que tanto a aula 1 quanto a aula 1 alternativa,
ocorram. Contudo, na impossibilidade de disponibilizar fones de ouvido para todos os alunos, a aula
1 alternativa busca suprir o conteúdo visto sobre Eventos e Variáveis, acrescentando a categoria
Aparência no lugar da categoria Som. Podemos notar que ambas as aulas possuem muitas
semelhanças, as quais podem ser dispensadas caso se realize a aula 1 alternativa como a segunda
aula deste curso.

Comece a aula se apresentando aos alunos, perguntando com que frequência eles usam o
computador e se já tiveram alguma experiência com o Scratch 2.0 ou com programação. Estas
perguntas serão importantes para aproximar os alunos do professor, permitindo que eles se
expressem e tirem dúvidas com menos receio. Além de permitir que o professor estime as
dificuldades que eles possam ter no uso do programa dado a experiência que possuem com
computadores. No caso de algum aluno ter alguma experiência com programação ou com o Scratch
2.0, recomendo que explore estas experiências prévias usando-as como assistência para a
aprendizagem dos demais alunos.
No Scratch 2.0, chamaremos a lista de opções coloridas ao
lado direito do gato laranja (imagem à direita), de categorias. Desta
forma, peça que os alunos cliquem na categoria “Aparência”. Isto
fará com que uma lista de botões da mesma cor que a categoria
“Aparência”, apareça logo abaixo. Podemos ativar estes botões ao
clicar neles.

Peça que os alunos cliquem no primeiro botão do topo da lista, “diga [Hello!] por [2]
segundos”. Veremos o gato laranja dizendo “Hello” por dois segundos e então a mensagem sumirá.
A área cinza mais escuro ao lado direito dos botões, chamaremos de “Área de trabalho”. Assim,
podemos clicar num botão e sem soltar o clique, arrastá-lo para a “Área de trabalho”, para só então
soltá-lo. Para removê-lo da “Área de trabalho”, podemos clicar no botão com o botão direito do
mouse e selecionar a opção “Apagar”, ou simplesmente puxar o botão para a lista de botões e então
soltá-lo. Ambos os métodos são eficientes, mas considero o segundo método bem mais conveniente.

Arraste o botão “diga [Hello] por [2] segundos” para a “Área de trabalho”. Se clicarmos
com o botão direito do mouse sobre qualquer botão, veremos também a opção “Ajuda”. Ative a
opção “Ajuda” para este botão, veja que do lado direito da “Área de trabalho”, abre uma aba
explicando o funcionamento do botão. A explicação fornecida pelo Scratch 2.0 é bastante clara,
ajudando o usuário a entender e usar o botão. Recomendo que quando o funcionamento de algum
botão não for claro, que esta opção seja acessada.

Contudo, ativar os botões atráves do clique do mouse sobre eles, não é conveniente. Clique
agora na categoria “Eventos”. Puxe para a “Área de trabalho” o botão “quando a tecla [espaço] for
pressionada”. Veja que este botão ao se aproximar do “diga [Hello] por [2] segundos”, geram uma
faixa branca entre os dois. Solte-o quando houver esta faixa branca e os botões se unirão. Agora
sempre que teclarmos [espaço], o botão “diga [Hello] por [2] segundos” será ativado.

Construindo um diálogo:
Clicando com o botão direito do mouse no botão “quando a tecla [espaço] for pressionada”,
aparecerá algumas opções. Ao selecionarmos a opção
“duplicar”, duplicamos todos os botões localizados a partir
deste que foi clicado. Duplique duas vezes apenas o botão
“diga [Hello] por [2] segundos”. Então encaixe estes dois
novos botões abaixo do par Evento e Aparência criados
anterioremente. Como mostra a imagem à direita.

Agora apague o conteúdo do segundo diálogo. Veja, que quando pressionarmos [espaço], o
gato dirá “Hello!” por 2 segundos, não dirá nada por mais 2 segundos, e então voltará a dizer
“Hello!” por mais 2 segundos.

No Scratch 2.0, tudo que permite acrescentar botões de alguma das categorias, ou são Atores
ou são Panos de Fundo. Nosso gato laranja, é um ator por exemplo. Abaixo da tela branca com o
gato, tem uma miniatura do gato, logo acima está escrito “Atores”. À direita tem a opção “Novo
ator:”. Clique na primeira opção (um bonequinho) à esquerda do pincel. Na tela que abriu, estão
todos os atores que o Scratch 2.0 disponibiliza ao usuário (mais atores podem ser acrescentados),
selecione algum ator qualquer e confirme. Vemos que na lista de atores, apareceu o novo ator
criado, e este também aparece na tela branca junto ao gato laranja.

Crie para seu novo ator um botão da categoria Eventos, que ative quando a tecla espaço for
pressionada. E acrescente 3 caixas de “diga [Hello] por [2] segundos” abaixo deste Evento. Agora
veja que cada botão realiza sua ação em 2 segundos. Logo, se o gato diz “Hello!” por 2 segundos, e
espera 2 segundos sem dizer nada. O novo ator pode dizer nada por 2 segundos e então dizer
“Hello!” por 2 segundos. Ao usuário, isto dará a impressão que o novo ator está respondendo ao
“Hello!” do gato laranja.

Assim, podem ser criados diálogos entre dois atores. Contudo, uma preocupação importante
é o tempo de cada fala de cada ator. Por exemplo, caso desejemos que a fala deles seja de 3
segundos ao invés de 2 segundos. Precisaríamos alterar cada um dos botões de cada ator. Isto seria
bastante trabalhoso, e se não fosse bem feito, as falas poderiam não ficar sincronizadas. Contudo,
podemos fazer isto de forma automática.

Clique na categoria “Variáveis” e pressione o botão “Criar uma variável”. Dê o nome da


variável de “tempo” e selecione a opção “Para todos os atores”. Então, nos novos botões que
surgiram sobre esta variável. Arraste para cada caixa de diálogo o botão “tempo” para o espaço que
antes tinha [2] segundos. E então arraste para a “Área de trabalho” de um dos atores (qualquer um
servirá), o botão “mude [tempo] para [0]”. Ao alternarmos o valor [0] deste botão para [1] e
clicarmos nele, a variável “tempo” passará a valer [1], e todos os diálogos que estão esperando
“tempo”, esperarão [1] segundo. Veja que desta maneira, poderíamos o tempo de centenas de caixas
de diálogos mexendo em apenas um botão. Pressione espaço novamente e veja como o tempo destes
diálogos mudou e eles ainda continuam sincronizados.

Experimente criar diálogos mais longos ou até mesmo com mais atores. Abaixo segue um
link para acesso a um projeto de diálogo criado conforme estas instruções.
https://scratch.mit.edu/projects/91020539/. E com isto encerramos nossa primeira aula deste curso.

Hora 3: Perguntas e respostas


Nesta aula nós veremos o uso de três ferramentas muito importantes do Scratch 2.0, e que
quase sempre aparecem juntas. Estas são Controle, Operadores e Sensores. Recomendo muita calma
e atenção no desenvolvimento desta aula, pois o bom entendimento sobre o uso dos botões destas
categorias facilita muito a construção de programas.

Comecem criando um novo projeto no Scratch 2.0. Então selecionando a categoria


“Eventos”, arraste para a “Área de trabalho” o primeiro botão do topo da lista, “quando clicar em
#bandeira_verde”. Para simplificar as futuras menções à #bandeira_verde, nos referiremos a isto
como o “inicialiador”, dado que clicamos na #bandeira_verde para inicializar o programa. Assim,
tudo que estiver preso embaixo deste botão, será realizado quando o programa começar. E poderá
ser interrompido no momento em que o #octógono_vermelho ao lado for clicado, o qual daqui pra
frente nos referiremos como o botão “finalizador”.

Agora clique na categoria “Sensores”. Arraste o quinto botão do topo da lista, “pergunte
[What's your name?] e espere a resposta” para que se junte ao botão de Eventos, e apenas ative o
botão abaixo “resposta”. Então inicialize o programa clicando no “inicializador”. Veja que o gato
pergunta qual é seu nome, e abaixo aparece um espaço onde podemos digitar uma resposta. Escreva
qualquer coisa e confirme. Veja que a resposta dada fica guardada no botão “resposta” que
ativamos.

Contudo, ainda temos um problema. Verificar se a resposta dada é correta. Para isto arraste o
botão “resposta” para a “Área de trabalho” e então clique na categoria “Operadores”. Arraste o
sétimo botão do topo da lista, “[ ] = [ ]”, para a “Área de trabalho”. Encaixe o botão resposta em um
dos espaços deste operador. E digite qual deva ser a resposta certa para sua pergunta no outro
espaço. Agora, quando clicarmos no botão “[ ] = [ ]”. Veremos a mensagem “false” se “resposta” for
diferente da resposta correta. E “true” se “resposta” for igual à resposta correta (o Scratch 2.0 não
diferencia na hora de comparar as respostas, letras maiúsculas de minúsculas).
Mas ainda que nós consigamos verificar manualmente se a resposta é correta ou não, através
do clique deste botão, isto ainda não nos é aplicável. Ou seja, precisamos de um processo
automático que realize esta verificação. Para isto, clique na categoria “Controle”. Arraste para a
“Área de trabalho” o quarto botão do topo da lista, “Se < > então // senão”. Perceba que este botão
possuí um encaixe diferente, < >, que se assemelha ao formato do nosso botão operador. Encaixe o
botão operador neste espaço. E agora nosso “Controle” realizará a seguinte tarefa. Se a resposta
dada for igual a resposta correta, ele realizará o que está no primeiro espaço, senão, realizará o que
está no segundo espaço. Neste operador, temos que apesar de haverem duas sequencias de botões,
apenas uma delas será realizada.

Assim, encaixe este operador abaixo da


nossa pergunta, crie para cada situação (acerto ou
erro), caixas de diálogo correspondentes. Altere a
pergunta se necessário e atualize a resposta
correta (caso seja necessário). No fim, devemos
ter uma estrutura de botões como o exemplo à
direita. Abaixo segue um link para acesso a um
projeto criado conforme estas instruções.
https://scratch.mit.edu/projects/91216211/

Jogo de perguntas
Agora vamos supor uma situação bem comum. Queremos propor para o usuário várias
perguntas e no final apresentar quantas ele acertou. Como trabalharemos com várias perguntas que
afetarão o placar, acertos ou erros não precisam de mensagens, desta forma na categoria “Controle”
arraste para a “Área de trabalho” o quarto botão do topo da lista, “Se < > então”. Dentro deste < >
estará o operador “[ ] = [ ]” que compara “resposta” com a resposta correta.

Para marcarmos os pontos do usuário, uma alternativa fácil é criar uma variável, como por
exemplo “Placar” para todos os atores. Na categoria “Variáveis” puxe o botão “adicione a [placar]
[1]” para o espaço vazio do botão “Se < > então”.

Acima do botão “Se < > então” coloque o botão da categoria “Sensores”, “pergunte [What's
your name?] e espere a resposta”, altere a
pergunta para que confira com a resposta dentro
do “Se < > então”. Contudo, acrescentar valores
a uma variável traz uma necessidade,
precisaremos colocar o botão da categoria
“Variáveis”, “mude [placar] para [0]” logo
abaixo do botão “quando clicar em
inicializador”. Duplique o botão “Se < > então”
alterando as perguntas e respostas conforme
desejar.

No final da lista dos “Se < > então”,


podemos colocar um par de diálogos como por
exemplo, “diga [Respostas corretas:] por [2]
segundos” e “diga [ ] por [2] segundos”. No
vazio da segunda mensagem, coloque o botão da
categoria “Eventos”, “placar”. No fim, devemos
ter uma estrutura de botões como o exemplo acima. Abaixo segue um link para acesso a um projeto
criado conforme estas instruções. https://scratch.mit.edu/projects/91404397/

Hora 4: Jogo de muitas perguntas


Realizando a construção do programa anterior, percebemos que a quantidade de botões na
“Área de trabalho” seria imensa se o jogo tivesse por exemplo, 20 perguntas. Precisando para isto
de 20 blocos do operador “Se < > então”.

Para isto, comece criando um evento “quando clicar em inicializador”, para que o programa
comece. Agora precisamos criar uma variável “pivo”, e também teremos que criar uma lista, para
isto clique no botão da categoria “Variáveis”, “Criar uma lista” a qual chamaremos de “perguntas e
respostas”. Assim, logo abaixo do botão “quando clicar em inicializador”, ligue-o com o botão de
“Variáveis”, “mude [pivo] para [0]”. Substitua o [0] do último botão pelo botão de “Variáveis”,
“tamanho de [perguntas e respostas]”. Isto
fará com que logo após o programa
começar, a variável “pivo” mude para o
tamanho da lista “perguntas e respostas”.
Como pode ser visto no exemplo à direita.

Agora puxe para a “Área de trabalho” o botão de “Variáveis”, “insira [thing] na posição [1]
de [perguntas e respostas]”. Duplique este botão, altere na duplicata o valor [1] para [2] e o prenda
abaixo do original (este par de botões ficará isolado na “Área de trabalho”). Como no exemplo a
seguir:

No primeiro botão colocamos a resposta, e no segundo botão a pergunta referente a resposta.


Então podemos clicar no primeiro botão e veremos que a resposta e pergunta aparecem na lista. Se
trocarmos a pergunta e a resposta, podemos pressionar de novo o primeiro botão e acrescentar mais
um par de pergunta e resposta na lista. Repetindo este processo, guardamos todas as perguntas e
respostas sem ocupar nossa “Área de trabalho” com muitos botões repetidos.

Caso deseje apagar a lista inteira, podem clicar no botão da categoria “Variáveis”, “apague
[1] de [perguntas e respostas]” e então trocar o [1] por “todos”. Isto apagará a lista inteira. Podemos
também apagar respostas ou perguntas específicas trocando o [1] pela posição específica. E então
inserir no lugar deste item um “insira [thing] na posição [1] de [perguntas e respostas]” trocando o
[1] pela posição específica. Apenas tome cuidado para não confundir a ordem das perguntas e
respostas.

Agora, precisamos passar por todos os itens da lista perguntando e conferindo as respostas.
Para isto vamos usar um botão da categoria “Controle”, “repita até que < >”. Dentro do “< >”
deste botão, colocaremos o operador “[ ] = [ ]”. Em uma das [ ] coloque a variável “pivo” e no
outro coloque [0]. Isto é necessário pois faremos o pivo diminuir conforme as respostas sejam
dadas, e como o pivo tem o tamanho da nossa lista, cada vez que os botões de dentro do “repita até
que < >” forem realizados, devemos reduzir 2 no valor do pivo. Para isto devemos colocar o botão
“adicione a [pivo] [-2] (este botão deve ser o último dos botões dentro do “repita até que < >”).

Contudo ainda precisamos que o programa leia a pergunta da lista e também que confira a
resposta, para isto precisaremos de um botão da categoria “Sensores”, “pergunte [What's your
name?] e espere a resposta”. Substitua a pergunta pelo botão “item [1] de [perguntas e respostas]”.
No lugar de [1] substitua por “pivo”. Em baixo acrescente um “se < > então”. Dentro do “< >”
coloque o seguinte operador com os itens como mostra abaixo.
Aqui comparamos a resposta dada pelo usuário com o item correspondente da lista
“perguntas e respostas” onde está a resposta correta. Ou seja, como “pivo” recebe o tamanho da
lista “perguntas e respostas”, o item [“pivo” - 1] é a resposta da pergunta que está no item [“pivo”].

Agora precisamos criar uma variável “placar”, e inserir abaixo do evento “quando clicar em
inicializador”, o botão “mude [placar] para [0]”. Assim dentro do “se < > então” adicionaremos um
contador de pontos para medir os acertos do jogador. Ou seja, o botão “adicione a [placar] [1]”. No
fim, devemos ter uma estrutura de botões como o exemplo abaixo. Abaixo segue um link para
acesso a um projeto criado conforme estas instruções. https://scratch.mit.edu/projects/91417318/

Este método para montar um jogo de perguntas é bem mais complicado do que o anterior,
compensando em eficiência, já que não importa a quantidade de perguntas, não será preciso
acrescentar mais nenhum botão ao programa. Recomendo que esta parte seja trabalhada com muita
atenção e paciência, pois daqui pra frente, usaremos várias das técnicas necessárias para este
programa.

Hora 5: Movimentos do ator (parte 1)


Nesta aula trabalharemos a movimentação do ator por meio do teclado. Assim, peça que os
alunos criem um novo projeto. A categoria “Movimento” já inicia aberta. Então arraste para a “Área
de trabalho” o nono botão do topo da lista, “adicione (10) a x”. Se clicarmos neste botão, vemos que
nosso gato laranja movimenta-se um pouco para a direita. Assim, se quisermos que ele se
movimente para a direita sem precisarmos clicar, podemos fazer como na primeira aula (Ode
Alegria), criar botões da categoria “Eventos”, “quando a tecla [espaço] for pressionada”, e substituir
o [espaço] por algo mais conveniente como por exemplo [seta para a direita]. Então juntamos nosso
botão de movimento com este evento, e sempre que pressionarmos a seta para a direita do teclado, o
gato se moverá para a direita.

Agora peça para que os alunos modifiquem o valor (10) do botão “adicione (10) a x”. Sugira
que testem aumentar ou diminuir o valor, inserir valores com vírgulas, ou inserir botões da categoria
“Operador”. Em todos estes casos, o movimento ocorrerá se o que restar dentro do botão puder ser
entendido pelo Scratch 2.0 como um número. Isto significa que podemos colocar até mesmo
variáveis ou itens de uma lista, desde que estes devolvam pro botão um número. Se até o momento
ninguém chegou a testar números negativos, sugira que agora o façam. E verifiquem que com
valores negativos o gato passa a mover-se para a esquerda.

O motivo do gato mover-se para a direita com valores positivos e para a esquerda com
negativos, está na orientação da posição “x”. Pois o botão que usamos representa a posição
horizontal do ator, e o valor de x aumenta
quando movemos para a direita e diminui
quando movemos para a esquerda. Desta forma,
ao subtraírmos algum valor de “x”, o gato
consequentemente movimenta-se para a
esquerda. Peça para que os alunos construam
botões que permitam o gato mover-se para a
esquerda, para cima e para baixo apenas
utilizando o teclado. Os movimentos verticais
podem ser realizados através do botão da
categoria movimento, “adicione (10) a y”. Esta
deve ser uma atividade bastante simples e que
os alunos serão capazes de realizar sozinhos e
em pouco tempo. No fim, devemos ter uma
estrutura de botões como o exemplo a direita.

Agora, temos uma outra questão. Similar ao que fizemos na aula 2 (Blá blá blá) ou na aula 1
(Ode Alegria). Se quisermos modificar as distâncias dos movimentos do ator. Precisaremos alterar
cada um dos botões? Ou podemos substituir por uma variável? É provável que os alunos pensem
que apenas substituindo por uma variável isto vá funcionar. Neste caso, incentive-os para que
tentem. O problema de apenas substituir por uma variável, é que os botões de movimento dependem
de serem positivos ou negativos para determinar se vão para direita ou esquerda, da mesma forma
para cima ou para baixo. Assim, se substituirmos seus valores pela variável de valor (10) por
exemplo. O ator se moverá unicamente para cima e para a direita, já que 10 é um número positivo.
Contudo, se o valor da variável for (-10) o ator se moverá apenas para a esquerda e para baixo, pois
-10 é um número negativo.

Então é impossível tornar este processo


automático com o uso de variáveis? Não.
Podemos aproveitar o que já foi feito, com o
valor da variável sendo (10) por exemplo. E
acrescentarmos nos botões que moverão o ator
para baixo e para a esquerda o botão da
categoria Operador, “( ) - ( )”. E no espaço à
direita deste botão, inserir o botão da variável
que criamos. Assim, para quando quisermos
mover para a esquerda ou para baixo, o botão
adicionará a x por exemplo, 0 – (10). O que é a
mesma coisa que adicionar – 10 a x.
Analogamente para y. No fim, devemos ter uma
estrutura de botões como o exemplo a direita.
Abaixo segue um link para acesso a um projeto
criado conforme estas instruções. https://scratch.mit.edu/projects/91618694/
Hora 6: Movimentos do ator (parte 2)
Dois problemas fáceis de notar neste método. O ator não consegue mover-se nas diagonais
quando pressionamos por exemplo, para cima e para a direita ao mesmo tempo. E também, o ator
não altera imediatamente seu movimento de direita para esquerda por exemplo, experimente
verificar este fato, pressione para a direita e segure, então pressione para a esquerda, segure e deixe
de pressionar para a direita.(se você observar bem, existe uma pausa entre a mudança de um lado
para o outro).

De fato, usar o botão “quando tecla [ ] for pressionada” não é a opção adequada quando
queremos fazer um jogo que o movimento rápido seja importante para passar um estágio por
exemplo. Não queremos que nosso personagem dê uma pausa, toda vez que desejarmos recuar
rapidamente. Veremos agora uma alternativa para estes problemas.

Na categoria “Controle”, usaremos o botão “sempre”. Este botão sem dúvida é um dos mais
impactantes para o programa. Pois o que estiver dentro deste botão será realizado repetidas vezes
para sempre. Ou seja, muito cuidado. Pois se mau usado, isto pode deixar seu programa lento por
conta do excesso de ações realizadas incessantemente. Assim, apague os antigos botões e insira o
“sempre” debaixo de um botão de evento, “quando clicar em inicializador”.

Isto significa, que quando o programa começar, tudo aquilo que estiver dentro deste
“sempre” será realizado para sempre. Dentro do “sempre” acrescente um botão “se < > então” e
outro “se < > então” logo abaixo do primeiro (um embaixo do outro). Assim, dentro dos “< >”
colocaremos um botão da categoria “Sensores”,
“tecla [espaço] pressionada?”. Perceba que esta é
uma pergunta, ou seja, o programa realizará sempre
os “se <tecla espaço pressionada?> então”. Assim,
podemos substituir a tecla espaço por seta para a
direita, e seta para a esquerda. Desta forma, fica
claro que dentro de cada um destes “se < > então”,
colocaremos os botões “adicione (10) a x” e
“adicione (-10) a x”.

Experimente usar as setas para mover o ator.


Agora, o ator esta realizando incessantemente as
perguntas ao programa, a seta para a direita ou para
a esquerda estão pressionadas? Se alguma delas
estiver, então ele move para a direita ou para a
esquerda. Se não estiverem, ele não faz nada.

Generalize os valores (-10) e (10) utilizando


uma variável, igual ao que fizemo na parte 1. E peça
para que os alunos tentem inserir as configurações
que permitam o ator mover para cima, para baixo e
para as diagonais. Nesta ocasião, basta que insiram um par de “se < > então” dentro do mesmo
botão “sempre”, e substituir o “adicione ( ) a x” para “adicione ( ) a y”. No fim, devemos ter uma
estrutura de botões como o exemplo a direita. Abaixo segue um link para acesso a um projeto criado
conforme estas instruções. https://scratch.mit.edu/projects/91618712/

Hora 7: Jogo do Polvo


Agora trabalharemos um jogo single-player bastante simples que utiliza várias das
ferramentas vistas até agora. O Jogo do Polvo, é um game onde um pequeno polvo segue seu mouse
enquanto um tubarão o persegue rapidamente. Se você conseguir manter o polvo fora do alcance do
tubarão por 5 segundos, você vence, caso o tubarão o alcance, você perde.

Para começar, podemos apagar nosso gato amarelo, clicando com o


botão direito na imagem dele presente na lista de atores e selecionando
apagar. Então criamos um ator “Polvo” e um ator “Tubarão”. Como visto
na imagem a direita.

Então para o Polvo, criaremos um botão de eventos, “quando clicar


em inicializador”. Como desejamos que o polvo siga o mouse até que o tubarão o alcance,
criaremos um botão da categoria operador, “repita até que < >”. Dentro do “< >”, colocaremos um
botão da categoria sensores, “tocando em [ ]?”. E selecionamos a opção “Shark” deste botão. Agora
temos um operador que realizará repetidas vezes o que tiver dentro dele, até que o Tubarão alcance
o Polvo.

Dentro do “repita até que < >”, colocaremos um par de botões da categoria movimento.
Primeiro o “aponte para [ ]”, nele nós selecionaremos a opção “ponteiro do mouse”. Perceba que
agora o Polvo fica girando para a direção em que seu mouse está, isto dará ao usuário a impressão
que ele está acompanhando seu mouse. Contudo para ele se mover sempre na direção do mouse,
acrescente o botão “vá para x: ( ) y: ( )”, e no interior do x: ( ), colocaremos o botão da categoria
sensores, “posição x do mouse”, e no interior do y: ( ), colocareos o botão da categoria sensores,
“posição y do mouse”. Agora nosso Polvo segue o mouse por onde quer que vá.

Mas isto ocorrerá até que seja pego pelo Tubarão. Ou seja, quando o Tubarão pegá-lo, algo
deve ocorrer. Uma sugestão que simplifica muito o processo, é colocar o botão da categoria
“Aparência”, “esconda”. Isto fará com que o Polvo não seja mais mostrado pro usuário a partir do
momento em que o Tubarão atingí-lo. Contudo, no Scratch 2.0, as coisas que estão “escondidas”
não aparecem sozinhas quando o programa inicializa. Assim, logo abaixo do botão “quando clicar
em inicializador”, deveremos colocar o botão da categoria “Aparência”, “mostre”. Isto garantirá que
sempre que o programa começar, o Polvo estará visível ao usuário, mesmo que ele tenha sido pego
pelo Tubarão na última partida. Uma sugestão por conveniência, é que o tamanho do Polvo seja
reduzido pela metade. Para fazer isto, abra a categoria “Aparência” e modifique o botão “mude o
tamanho para (100) %” (não precisa puxar o botão para a “Área de trabalho”, para “mude o
tamanho para (50) %”, e então clicar nele.
Veremos que assim o Polvo reduz para
metade do seu tamanho. Esta modificação
não se reverte quando o programa for
inicializado, então não temos a necessidade
de manter este botão na Área de trabalho e
nem ativá-lo toda vez que o programa
inicializar. No fim, devemos ter uma
estrutura de botões como o exemplo a
direita.

Agora, clique no ator “Shark” (o Tubarão). Antes de mais nada, em cima das “Categorias”,
temos três abas. “Scripts”, “Fantasias” e “Sons”. Clicando em “Fantasias”, vemos três imagens
diferentes do mesmo Tubarão. Como queremos que ele pareça assustador contra o Polvo,
recomendo que apaguemos a última imagem, bastando apertar o X na imagem selecionada como
mostra na imagem a direita.
Assim, volte para a aba “Scripts”, onde construíremos um conjunto de botões
com uma estrutura parecida ao do Polvo. Começaremos com o botão “quando clicar
em inicializador”. Como não queremos que o Tubarão comece em qualquer lugar da
tela (pois já pensou se ele começa no mesmo lugar do Polvo, que chances o Polvo
teria?), logo abaixo colocaremos o botão “vá para x: (-100) y: (-100)”. Escolhi estes
valores para x e y por achar que seja uma posição boa para começar, mas sinta-se a
vontade para escolher quaisquer valores.

Contudo, se queremos que o Tubarão persiga o Polvo por um certo tempo,


podemos usar o mesmo botão da categoria “Controle” que usamos para o Polvo.
“repita até que < >”. Mas com uma diferença, queremos que isto aconteça até que o
tempo termine. Neste caso, dentro do “< >”, colocaremos um botão da categoria
“Operadores”, “[ ] > [ ]”. No lado direito deste botão colocaremos o botão da
categoria “Sensores”, “cronômetro”. O “cronômetro” inicializa no 0 sempre que o
programa começa a funcionar. Assim, se queremos que o Tubarão realize estas ações
por 5 segundos, devemos colocar do lado direito do nosso “[ cronômetro ] > [ 5 ]”.
Isto fará com que assim que o cronômetro ultrapassar 5 segundos, as ações do botão
“repita até que < >” terminará.

Mas você pode estar pensando, por que pedir que seja >5 e não =5? Como o cronômetro é
bastante preciso, suponha que a realização do programa que tem dentro do “repita até que < >”
gaste 0.3 segundos. Isto significa que de 0.3 em 0.3 segundos, o programa verificará se o
cronômetro é =5. Se o programa fizer a verificação no momento 4.8 segundos. A próxima
verificação só ocorrerá no momento 5.1 segundos. Desta forma, o programa verá que 5.1 é diferente
de 5.0 e continuará repetindo seu processo, e como o tempo só aumenta, o programa repetirá seu
processo para sempre. Por isto, que ao pedirmos que a verificação seja para cronômetro > 5.0, não
importa o tempo do programa, ainda que ele realize a próxima verificação em 5.1 ou em 5.9, para
qualquer uma que seja maior do que 5.0, ele já interromperá a execução. Fazendo com que na
percepção imprecisa do usuário, realmente interrompa o programa após 5 segundos.

Dentro do “repita até que [ cronômetro ] > [ 5 ]”. Colocaremos os botões da categoria
“Movimento”, “aponte para [ponteiro do mouse]” e “deslize por (1) seg até x: ( ) y: ( )”. Neste
último, substitua o (1) seg por (0.3) seg, pois acredito que deixe o jogo mais desafiador. E
acrescente nos espaços x: ( ) y: ( ), os botões da categoria “Sensores”, “posição x do mouse” e
“posição y do mouse” respectivamente. Isto fará com que o Tubarão realize exatamente as mesmas
funções do Polvo. Contudo de forma mais demorada, isto dará ao jogador a necessidade de
movimentar seu Polvo de maneira que o Tubarão não o alcance, sendo que estará movendo também
o Tubarão sem se dar conta.

Para melhorar a interação com o usuário, ainda dentro do “repita até que < >”, podemos
colocar o botão da categoria “Aparência”, “próxima fantasia”. Isto fará o Tubarão abrir e fechar a
boca mostrando seus dentes como se estivesse tentando morder o Polvo. Agora, de maneira similar
ao que fizemos para o Polvo, caso passem os 5 segundos, algo deve ocorrer ao Tubarão. A ação
mais simples, é pedir que ele suma, para isto colocamos o botão da categoria “Aparência”,
“esconda” abaixo do botão “repita até que < >”. E como as coisas que se escondem, não voltam a
aparecer sozinhas, devemos colocar o botão “mostre” no começo deste programa, logo abaixo do
“quando clicar em inicializador”.

Se você experimentar jogar como está, perceberá que o Tubarão começa a se mover na
mesma ocasião que o inicializador é clicado. Isto pode deixar o jogo difícil demais, pois não dá
tempo ao jogador se preparar para fugir do Tubarão após começar o jogo. Uma alternativa para isto
é acrescentar o botão da categoria “Controle”, “espere (1) seg” logo abaixo do botão “vá para x:
(100) y:(100)” do Tubarão. Agora se experimentarmos jogar, veremos que temos 1 segundo após
clicar no inicializador para nos prepararmos antes do Tubarão começar a nos caçar. No fim,
devemos ter uma estrutura de botões como o exemplo abaixo. Abaixo segue um link para acesso a
um projeto criado conforme estas instruções. https://scratch.mit.edu/projects/91636034/

Apesar de ser simples, a estrutura deste jogo envolve a interação real entre dois atores. Isto
significa que diferente do que foi feito até agora, um ator está influenciando o outro. Também vimos
nesta aula, que o procedimento do programa para realizar suas ações não importa ao usuário, apenas
a impressão que isto lhe passa. Este é um jogo introdutório, então se o seu funcionamento não está
claro ainda, recomendo fortemente que reveja esta aula ou as anteriores antes de prosseguir.

Hora 8: Jogo de Pegar a Chave


Jogos de Pegar a Chave são muito comuns. O jogador precisa controlar seu personagem até
que ele consiga uma chave específica, que lhe permite passar por uma porta. Apesar de geralmente
estes jogos aparecerem com desafios, que tornam o ato de conseguir a chave, desafiador, neste
momento, trabalharemos apenas a seguinte configuração. Existe algo que só pode ser aberto se
outra coisa for pega antes. No nosso exemplo, faremos uma melância, que o nosso personagem, o
gato, pode passar por ela, mas ela continuará fechada. Até que ele pegue a chave e passe pela
melância novamente, então ela se abrirá.

Para começar, crie um projeto novo e insira os movimentos para nosso ator gato laranja (use
o que foi visto na aula 5 ou 6). Então crie dois novos atores. Uma chave e uma melância, ambas
disponíveis na lista de atores do Scratch 2.0 (a escolha da porta como uma melância se deu por
conveniência).

Agora criaremos uma interação entre o gato e a chave. Criaremos um novo botão “quando
clicar em inicializador”. Dentro deste novo evento, vamos inserir o botão da categoria “Controle”,
“espere até < >”. Neste < >, colocaremos o botão da categoria “Sensores”, “tocando em [ ] ?” e no
[ ] selecionaremos o ator “Key”. Assim, temos um evento que aguardará desde o começo do
programa, o gato tocar na chave, para continuar.

Poderíamos fazer a próxima parte utilizando uma variável. Contudo, variáveis envolvem o
uso de controles e operadores que fiquem aguardando a variável atingir um certo valor, além da
preocupação em zerar a variável sempre que o programa começar. Uma alternativa, que recomendo
sempre que tivermos situações simples, é utilizar o botão da categoria “Eventos”, “envie
[message1] a todos”. Este botão envia para todos os atores [message1]. Mas qual a vantagem? Por
que isto é melhor do que variáveis?

A vantagem está na existência do botão da categoria “Eventos”, “quando receber


[message1]”. Ou seja, quando a [message1] for enviada, estes eventos
iniciarão seus trabalhos. Isto é como se fosse um sinal específico que
todos ouvem e sabem se precisam ou não fazer algo assim que ouvir.
Assim, coloque abaixo do “espere até < >”, o botão “envie [message1]
a todos” (a message1 pode ser alterada, contudo neste programa como
só utilizaremos um sinal, a message1 servirá). No fim, devemos ter uma estrutura de botões como o
exemplo a direita.

Agora no ator Key (a chave). Vamos colocar um botão da categoria “Eventos”, “quando
receber [message1]”. Este botão identificará o momento que a message1 for enviada pelo nosso
gato. Assim, se desejamos que o jogador pense que o gato pegou a chave, podemos inserir abaixo
deste evento, o botão da categoria “Aparência”, “esconda”. Isto fará com que
a chave suma assim que o gato tocar nela. Mas, não se esqueça. O Scratch
2.0, não mostra objetos sumidos sozinho quando o programa inicia. Então,
precisaremos de um evento “quando clicar em inicializador” seguido do
botão “mostre”. Para que a chave volte a aparecer quando o programa
recomeçar. No fim, devemos ter uma estrutura de botões como o exemplo a
direita. Pode experimentar mover seu gato pela tela até tocar na chave, e verá
que ela sumirá.

Agora temos que pensar um pouco. Como fazer para a melância só abrir após o gato com a
chave passar por ela? Poderíamos pedir que ela fique verificando constantemente sempre que o gato
tocar nela, se ele já pegou a chave. Uma alternativa, muito mais simples é, inserirmos o botão
“quando receber [message1]” seguido do botão “espere até < >”,
com “tocando em [Sprite1] ?” dentro do < >. Esta combinação de
botões faz com que a partir do momento que o gato pegar a chave,
este ator comece a esperar que o gato toque na melância. Antes de
pegar a chave, este ator não recebeu message1, então não começará.
Assim, abaixo do “espere até < >” podemos colocar o botão da
categoria “Aparência”, “mude para a fantasia [ ]” e selecionamos para
[ ] a fantasia watermelon-b. Mas não podemos esquecer, que as
fantasias não voltam para a primeira sozinhas quando o programa
começa, assim precisamos de um outro botão de eventos, “quando clicar em inicializador” seguido
do botão “mude para a fantasia [watermelon-a]”. No fim, devemos ter uma estrutura de botões
como o exemplo acima. Abaixo segue um link para acesso a um projeto criado conforme estas
instruções. https://scratch.mit.edu/projects/91795708/

Hora 9: Sprites/Fantasias
Como já vimos na aula de movimentos quando fazíamos nosso gato mover as perninhas
enquanto andava, agora veremos como fazer isto num caso geral. Primeiro, vejam que no próprio
Scratch 2.0, vários atores já são oferecidos contendo uma série de movimentos para trocar, como foi
visto na aula passado no caso da melância. Mas se não tivermos no Scratch 2.0 o ator que
desejamos, podemos desenhá-lo nós mesmos ou recorrer a imagens que encontrarmos na internet
(lembre-se de sempre identificar as imagens que não são de sua autoria).

Uma maneira simples de localizar imagens de personagens na internet, é pesquisando pelo


nome Sprites. Sprites são "folhas" contendo um personagem em suas mais variadas formas. Por
exemplo, pesquisarei "sprites megaman x png". A escolha por png foi por conta da qualidade com
que desejo encontrar a imagem, assim se eu não especificasse nada, procuraríamos qualquer
formato. Assim encontrei no endereço http://i.imgur.com/EoZ9x.png, a folha de imagens que
apresento abaixo. Vejam que nesta imagem, temos praticamente todas as ações possíveis que o
megaman precisaria durante o jogo.
Nosso próximo passo será inserir esta imagem no Scratch 2.0. Um problema que podemos
enfrentar nesta etapa é que se tentarmos inserir esta imagem diretamente no Scratch 2.0, ela será
maior do que o máximo suportado pelo programa. Isto resultará que nosso personagem neste caso
ficará muito desconfigurado. Uma alternativa para isto é utilizar um programa de edição de imagens
para recortar fragmentos menores da nossa página de sprites.
Então no Scratch 2.0, podemos criar um novo ator selecionando a opção “Pintar um novo
ator”. Vemos que nesta opção não temos nenhuma imagem definida ou oferecida ao nosso ator,
assim podemos ir em “Fantasias” e selecionar a opção no topo da tela “Importar”, isto permitirá que
acessemos os arquivos do computador e coloquemos em nosso programa a imagem que desejamos.
Recomendo sempre ao importarmos uma imagem, a opção no canto inferior direito seja “Modo
Vetorial”, isto permitirá que a imagem seja melhor conservada.

Notemos agora, que quando nossa imagem é importada para o Scratch 2.0, e seu tamanho
excede a tela que ela aparecerá, o programa comprime a imagem o tanto quanto for necessário para
que caiba. Isto implicara na perda da qualidade da imagem. Esclarecendo uma dúvida antes que ela
surja, imagens de tamanhos diferentes são conservadas igualmente no Scratch 2.0, desde que
caibam no espaço da imagem. Isto significa, que na hora de fracionar sua imagem original, não há a
necessidade de que todos os arquivos com imagens selecionadas tenham o mesmo tamanho, para
que na hora de inserir no jogo elas se mantenham.

Assim que a imagem estiver importada, no próprio Scratch 2.0, são oferecidas ferramentas
que permitem apagar o fundo branco e fazer modificações na imagem. Recomendo que estas
modificações sejam feitas fora do Scratch 2.0, pois existem muitos programas bem mais adequados
para estes objetivos, e insto não é o foco desta apostila. Assim, para o nosso ator, faremos com que
cada cena do personagem seja uma fantasia. Isto incluí os movimentos de cada movimento dele
andando para a direita e também para a esquerda.

Assim, duplique uma vez cada uma das seis fantasias na mesma ordem que elas estão e
então para todas as cópias, vá no canto superior direito e pressione o botão
"Espelhar horizontalmente". Com isto teremos as fantasias do ator
movimentando-se para a direita e para a esquerda. Mas ainda precisamos nos
preocupar com o personagem estar ou não centralizado, checar isto podemos
clicar no botão ao lado do "Espelhar horizontalmente", o botão "Especificar
centro da imagem", nele veremos que a tela é cruzada por duas retas pretas
perpendiculares. Certifique-se que as fantasias estão centralizadas antes de
prosseguir.
Agora criaremos um botão da categoria evento seguido de botões para movimentação (como
já vimos anteriormente). No final, estes botões terão a seguinte configuração.

Mas isto realiza apenas o movimento do ator, não estando relacionado a troca de fantasias e
à impressão de que ele esteja mesmo se movendo. Para isto precisaremos que o programa verifique
a fantasia atual do personagem, pois não queremos que ele se movimente para a direita enquanto
sua imagem é do personagem movimentando-se para a esquerda. Assim, abaixo do botão "adicione
(10) a x", acrescentaremos o botão "próxima fantasia". Isto fará com que sempre que ele se
movimentar para a direita, ele vá para a próxima fantasia. Mas veja que nosso problema está quando
ele chegar na fantasia número 6. Pois a próxima fantasia seria a número 7, que é a do personagem
se movimentando pra esquerda. Para resolver isto, colocamos logo abaixo do "próxima fantasia" o
seguinte conjunto de botões.

Assim, verificamos se após a mudança de fantasia, a fantasia atual é maior que 6. Se for,
mudamos para a fantasia número 1. Veja que isto traz uma vantagem escondida, pois se o nosso ator
estiver movimentando-se para a esquerda e
decidir mover-se para a direita, se a fantasia que
ele estiver usando for a número 12 (a última),
nosso ator irá para a próxima fantasia, que será a
número 1 (a primeira). Contudo se nosso ator
estiver em outra fantasia, a número 10 por
exemplo, ele trocará para a próxima, a número
11, e então verificará se a fantasia atual é maior
do que 6, neste caso, trocará para a fantasia
número 1.

Fazendo um conjunto de botões análogos


para os movimentos para a esquerda, no fim,
devemos ter uma estrutura de botões como o
exemplo a direita. Abaixo segue um link para
acesso a um projeto criado conforme estas
instruções.
https://scratch.mit.edu/projects/94918165/
Hora 10: Fugindo dos Raios (parte 1)
Nessa e nas próximas duas aulas, trabalharemos a construção do seguinte jogo.
https://scratch.mit.edu/projects/91946717/. É recomendável que o professor jogue e também
proponha que seus alunos joguem. Pois este jogo envolverá o uso de muitas ferramentas e será uma
construção mais difícil do que os jogos exemplos que foram mostrados até agora. Assim, se os
alunos conhecerem o que estão para produzir, isto pode motivá-los e contribuir para que se
empenhem em terminar este jogo.

A ideia do jogo Fugindo dos Raios, é controlar um Robô através da tecla espaço, para que
ele vá de um lado para o outro da tela sem que seja atingido por raios. Caso seja atingido, seu Robô
desaparece e se pressionarmos espaço novamente, o jogo reinicia. A intensidade com que os raios
caem aumenta gradativamente, assim como o valor da pontuação aumenta conforme o Robô
sobrevive mais tempo.

A primeira coisa de novo que podemos perceber neste programa. É que muitos raios caem
do céu. Com o que vimos até agora, cada raio precisaria ser um ator e precisaríamos de centenas de
atores para serem raios. Veremos um modo econômico e prático de fazer isto. Comece criando um
ator raio. Nele insira o botão "quando clicar em inicializador". Logo abaixo, o botão da categoria
controle "sempre" e dentro deste botão, acrescente o botão da mesma categoria, "criar clone [este
ator]". Pronto, agora o programa desde o momento da sua inicialização começará a criar clones
deste raio.

Mas este raio original não faz nada, então por enquanto os clones também não farão nada.
Contudo, existe outro botão da categoria Controle, que possuí uma aparência similar aos botões da
categoria Eventos, "quando começar como clone". Este botão é bastante complexo e pode dar muita
confusão, pois a partir do momento que um clone é criado com o botão "criar clone [este ator]", este
botão (quando começar como clone) funciona como um inicializador para o clone que estará agindo
como um novo ator. Se você se perdeu nesta explicação, a ideia aqui é, quando criamos um clone,
este clone passa a trabalhar como um ator novo, e seu Script, será determinado pelo botão "quando
começar como clone".

Um perigo de trabalhar com clones está na individualidade que seus Scripts possuem. Pois
podemos colocar por exemplo o botão "criar clone [este ator]" dentro do Script de "quando começar
como clone". Isto geraria um clone, que geraria outro clone e que consecutivamente geraria novos
clones para sempre. Outro problema bem pesado, está no uso de variáveis. Até agora nós utilizamos
variáveis "para todos os atores". Ou seja, variáveis que são as mesmas para qualquer ator do
programa. Contudo, existe a opção "para este ator apenas". Esta opção faz com que a variável não
seja compartilhada com outros atores, o que não faz tanta diferença quando lidamos com os atores,
pesando mais na questão de limpeza, já que não aparecerão variáveis de um ator disponíveis para
modificação em outro ator. Entretanto, quando criamos clones e a variável é "para este ator apenas".
Cada clone criado, leva consigo uma cópia desta variável e ela passa a ser válida apenas para este
clone.

Um exemplo, suponha que tenhamos uma variável válida apenas para um ator que fica
mudando entre direita e esquerda. Criamos um clone, e verificamos sempre se a variável é direita,
ele se moverá para a direita, se ela é esquerda, ele se moverá para a esquerda. Se a variável deste
ator fosse a mesma para todos os clones, eles ficariam movimentando-se em sincronia para os
mesmos lados, já que a verificação ficaria repetindo e sempre que a variável mudasse, a direção do
clone mudaria. Mas não é isto que acontece. Quando fazemos isto, vemos clones sendo criados e
indo para a direita e outros indo para a esquerda, sem modificar suas direções apesar de estarem
realizando sempre as verificações. Isto significa que no momento que o clone é criado, ele cria
também uma variável cópia e própria, que não depende da variável que esta variando entre direita e
esquerda. Se isto pareceu complicado, agora imagine quão complicado é trabalhar com clones e
listas?

Voltando ao nosso problema dos raios. Após criar o botão "quando começar como clone",
vamos criar o botão "repita até que < >". Neste < > colocaremos um operador "[ ] < [ ]", e no
lado esquerdo deste operador colocaremos o botão da categoria movimento, "posição y", do lado
direito colocaremos [-200]. Isto fará com que o controle "repita até que [posição y] < [-200]", faça o
clone repetir uma ação até que sua altura seja menor do que -200. No nosso caso, isto faz com que o
raio continue caindo até sumir da tela. Assim, dentro deste repita, colocaremos o botão "deslize por
[0] seg até x: (posição x) y: ((posição y)-10)". E com isto, teremos nosso botão que repetirá a ação
de descer com o raio até que ele suma da vista do jogador.

Mas criar clones envolve um problema, pois os clones contam como atores e sozinhos eles
começam a acumular. Veja que o botão sempre repetirá enúmeras vezes o processo de criá-los.
Assim, após o "repita até que [posição y] < [-200]" devemos colocar o botão da categoria controle,
"apague este clone". Isto fará com que após o clone realizar estas ações, ele seja descartado do
programa, evitando que fiquem acumulados na base da tela. Puxe com o mouse o ator Raio para o
topo da tela. Abaixo apresento como a estrutura deve ter ficado seguindo estes procedimentos
citados.

Veja que ao inicializar este programa, nós criamos uma faixa de raios bastante densa. Que é
diferente da chuva de raios que vimos no jogo finalizado. Para reparar isto, precisamos distribuir os
locais de queda dos raios. Para isto, no Script do clone, acrescentaremos em cima do "repita até que
[posição y] < [-200]" o botão "vá para x: (número aleatório entre (-240) e (240)) y: (200)". Isto fará
com que sempre que um clone do raio for criado, ele se mova para um valor aleatório da horizontal
mas que permaneça na altura 200, ou seja, comece no topo como se fosse uma chuva.

Dois problemas fáceis de observar são, o ator original permanece lá em cima parado e a
chuva de raios está intensa demais para qualquer Robô conseguir sobreviver. Façamos primeiro o
ator original sumir, colocando em baixo do "quando clicar em inicializador", o botão "esconda".
Mas isto faz com que todos os raios sumam. Já que a chuva é feita de raios clones, todos os clones
estão começando escondidos. Deste modo precisamos colocar logo abaixo do "quando começar
como clone", o botão "mostre". Pois isto fará com que o clone apareça enquanto que o original
permaneça escondido.

Agora para resolver o problema da intensidade de raios, podemos colocar um botão "espere
((número aleatório entre (0) e (2)) seg)" acima do botão "crie clone de [este ator]". Isto fará com
que o programa sorteie um valor entre 0 e 2, e espere este tempo antes de criar um novo clone. Mas
vemos que este processo deixa o jogo bem parado, pois 2 segundos é um intervalo muito grande
entre cada queda de raio. O ideal seria se o tempo de intervalo entre os raios fosse reduzindo
conforme o jogo avança. Uma alternativa para fazer isto é criando uma variável com um valor
inicial (2 por exemplo), e então pediremos o programa aguarde variável segundos antes de criar um
clone e então nós reduzimos um pouco o valor desta variável, para que no próximo momento, o
programa espere menos e crie outro clone mais rápido. Esta é uma maneira de fazermos isto,
contudo não é a que usaremos aqui.

Como nosso objetivo é a simplicidade do programa e a aprendizagem dos alunos. Usaremos


o próprio cronômetro do Scratch 2.0 para esta tarefa. Agora será necessário um pouco de
ardilosidade, tente acompanhar o raciocínio. O cronômetro começa no 0 e marca os segundos desde
que o jogo inicia. Se mandarmos esperar (cronômetro) entre cada clone, isto fará com que o
intervalo de criar clones aumente ao invés de diminuir. A estratégia aqui é utilizar algum operador
do próprio programa de tal modo que conforme o cronômetro aumente, este operador devolva um
valor que vá reduzindo gradativamente. Por exemplo, se colocarmos o programa para esperar o
operador (1) / (cronômetro), em um segundo de execução, o programa aguardará 1/1 segundos para
criar um clone. Então, quando terminar, já estará no momento 2 segundos, e assim ele aguardará 1/2
segundos para criar o clone, ou seja 0.5 segundos. E quando terminar, ele estará no momento 2.5
segundos, então ele aguardará 1/2.5 segundos que é equivalente a 0.4 segundos, e assim
sucessivamente os valores vão reduzindo cada vez mais próximo do 0.

Contudo apesar de parecerem muitos os processos, para o programa isto ocorrerá tão
rapidamente que começará a chover raios demais para o jogador conseguir sobreviver. Assim, não
podemos usar esta operação. Uma alternativa viável, é utilizar o último botão do topo da lista de
Operadores, o "[raiz quadrada] de ( )". A raiz quadrada é uma função matemática que associa um
número positivo Y a um número X que se X for multiplicado por ele mesmo, chegaremos ao Y.
Assim, como o cronômetro é sempre positivo, temos que raiz quadrada do cronômetro será um
valor que se multiplicado por ela mesma dará o valor do cronômetro. Recomendo ao professor neste
momento um apelo mais detalhado ao assunto de raiz quadrada, fazendo uso de exemplos que
ajudem a compreensão.

Com isso, queremos mostrar que usando o operador


((raiz quadrada de [cronômetro]) / (cronômetro)) temos um valor que vai reduzindo conforme o
tempo avança, como podemos ver no gráfico abaixo. A vantagem deste operador em relação ao
anterior, está na redução dele não ser tão rápida, isto garante que a dificuldade do jogo não
aumentará absurdamente rápido.

Contudo ainda temos um problema que aparece com o uso do cronômetro. A divisão por 0
não existe. Ou seja, se no momento que o jogo começar ele for realizar o processo de esperar do
nosso operador, e o cronômetro ainda estiver marcando 0, ele esperará para sempre. Um jeito
simples de corrigir isto é não fazendo nada. Como foi dito anteriormente, as ações do programa
exigem tempo. Assim, normalmente se existir um botão entre o evento que inicializa o programa e o
botão que utiliza esta operação, provavalmente o cronomêtro ao chegar neste botão não marcará
exatamente 0 segundos. Sua precisão garantirá que alguns centésimos de segundo já tenham sido
registrados, e nesse caso, a operação de divisão ocorrerá com sucesso. Dando ao jogador neste
momento inicial seu maior tempo de intervalo entre os raios, pois daqui para frente, o intervalo de
queda penas aumentará. Assim, seguindo estes procedimentos, deveremos ter uma estrutura similar
ao exemplo abaixo.

Uma opção que pode ajudar na estética dos raios, é acessando sua aba “Fantasias”,
selecionamos com o botão direito a imagem do raio e então escolhemos a opção duplicar. Assim,
em uma das imagens de raio, você vai no canto superior direito e selecionamos a segunda opção,
que realiza a reflexão vertical da imagem. Como pode ser visto na imagem abaixo. E com isto,
veremos que nosso raio agora está ao contrário. Assim volte para o Script do raio e insira após o
“deslize por (0) seg até x:(posição x) y:((posição y)-(10))” o botão “próxima fantasia”. Isto fará com
que o rario fique oscilando de uma fantasia para a outra enquanto desce. Particularmente eu acho
esta modificação bem atrativa para o jogo.

Hora 11: Fugindo os Raios (parte 2)


Agora que já criamos nosso ator raio, podemos trabalhar com o que é necessário para
criarmos nosso Robô. Primeiro crie este ator na lista de atores que o Scratch 2.0 oferece. A escolha
deste ator foi por conveniência, dado que ele pode se deslocar com a mesma imagem de um lado
para o outro e ainda o jogador terá a impressão de que ele está se movendo corretamente. O que
seria diferente de uma pessoa que se movimentasse sem mexer as pernas por exemplo, geraria um
estranhamento ao jogador.

Similar ao que fizemos com o raio na última aula, duplique a fantasia do Robô e reflita
horizontalmente uma das fantasias, para que ele possa virar para o lado que esta se movendo. Assim
antes de tudo, vamos criar aquele botão clássico, o “quando clicar em inicializador”, afinal,
queremos que o jogo comece quando inicializar. Contudo, não colocaremos sequência alguma de
comandos para o Robô debaixo deste botão. Coloraremos abaixo dele apenas o botão da categoria
Eventos, “envie [message1]”.

Assim, já podemos criar o seguinte botão da categoria Eventos, “quando receber


[message1]”. Você pode estar se perguntando, por que ter este trabalho em enviar uma mensagem
para que ela seja recebida e então o programa inicie? Poderíamos começar o programa a partir do
“quando clicar em inicializador”? A resposta é, sim. Poderíamos começar diretamente o programa
abaixo deste botão. Contudo, quando quisermos recomeçar o jogo, seríamos obrigados a clicar no
inicializador ou a construir uma sequência de botões que comecem a partir de um sinal enviado pelo
próprio programa. Este sinal poderia ser a mensagem [message1]. E se faremos isto, então podemos
evitar deixar dois blocos cheios de botões que fazem as mesmas coisas, colocando que ao inicializar
o programa, ele envia o sinal que será o mesmo enviado quando quisermos recomeçar o jogo. A
necessidade deste sinal se dá por não haver um botão que inicialize novamente o jogo, se houve,
poderíamos utilizá-lo simplesmente.

Começaremos com a passagem de um lado para o outro da tela. Abaixo do botão “quando
receber [message1]”, coloque o botão “sempre”, dentro deste sempre vamos inserir um par de “se <
> então”. A condição do primeiro “se < > então” será ((posição x) > 240) e a condição do segundo
“se < > então” será (240<(posição x))”. Estes dois “se < > então”, estão verificando se o Robô
passou da posição -240 ou 240 no eixo horizontal. Em termos práticos, se ele chegou no limite da
tela ou não. Assim, para o primeiro “se < > então”, colocaremos o botão “vá para x: (-240) y:
(posição y)”, e para o segundo “se < > então”, colocaremos o botão “vá para x:(240) y:(posição
y)”. Estes botões farão com que a partir do momento que o Robô ultrapassar os limites de um lado
da tela, ele apareça imediatamente no outro, em termos práticos, dará a impressão ao jogador que o
Robô passou do lado esquerdo para o lado direito da tela.Assim, seguindo estes procedimentos,
deveremos ter uma estrutura similar ao exemplo abaixo.

Agora crie um outro botão da categoria Eventos, “quando receber [message1]”, abaixo dele
coloque o botão “repita até < >”. Por enquanto não colocaremos nada no < >, veremos que sem
preencher esta condição de parada para o repita, ele funcionará da mesma maneira que o botão
“sempre”. Assim, dentro deste botão, colocaremos o botão “adicione a x: (10)”. Veja que agora o
nosso Robô começará a andar para uma direção por toda eternidade e sempre que chegar ao final da
tela, reaparecerá do outro lado. Vamos agora padronizar o valor da distância, para isto criaremos
uma variável “distância” e substituiremos o valor (10) por esta variável, igual o que já fizemos nas
aulas de movimento. Modifique o valor da variável para o desejado (10 por exemplo). Então
criaremos um botão da categoria Eventos, “quando a tecla [espaço] for pressionada” e abaixo os
botões “próxima fantasia” para dar a impressão que o Robô muda de lado conforme a direção e
“mude (distância) para ((distância)*(-1))”, pois se a distância vale 10 por exemplo, ao multiplicá-la
por -1, ela valerá -10, assim com apenas um botão podemos gerar a mudança de um lado para o
outro. Experimente verificar o funcionamento do Robô e suas respectivas mudanças de direção.

Agora vamos colocar uma condição para o nosso “repita até que < >”. O intuitivo nesta
ocasião é colocar “tocando em [raio]?”, mas isto não é a melhor opção. Pois a verificação de um
ator tocando no outro envolve um retângulo ao seu redor, contudo é fácil perceber que se fizermos
um retângulo que enquadre nosso Robô, teremos uma grande área que o Robô não estaria em
contato com o raio, mas este retângulo incluiria. Assim, como neste momento desejamos limitar
nossa percepção apenas ao Robô, pois o jogador se preocupará em não deixar que o raio o toque.
Utilizaremos o seguinte sensor, “cor [ ] tocando em [ ]?”. Para escolher a cor deste sensor, podemos
clicar no primeiro [ ] e então tocar na cor roxa do Robô, e no segundo [ ] e então tocar na cor
amarelo do raio. Assim, este sensor verificará se a cor roxa do Robô está em contato com a cor
amarela do raio. Isto deixará de incluir as rodinhas do Robô por exemplo, mas permitirá uma
melhor percepção do contato do que apenas verificar se um ator está tocando no outro.

Veja que o modo de verificar acima, só é viável pois não existem outras cores amarelas da
mesma tonalidade que a do raio que possam entrar em contato com a cor roxa do Robô, pois se isto
ocorresse, o sensor perceberia e consequentemente identificaria que deveria para o botão de repetir.
Assim, após o botão repetir, podemos colocar o botão “esconda”. Mas agora lembre-se, que se o
Robô será escondido, acima do botão repita, deve haver um botão “mostre”, pois sozinho o Scratch
2.0 não mostra atores escondidos.

Hora 12: Fugindo os Raios (parte 3)


Para que o jogo recomece apenas pressionando espaço. Precisamos nos ater a um detalhe. O
jogador perde em um momento que ele já desistiu, ou em uma esperança de continuar
sobrevivendo? Provavelmente o jogador perderá acreditando fortemente que seu próximo
movimento pode salvá-lo. Ou seja, o jogador alguns instantes após seu personagem ser atingido
pelo raio, ainda poderá pressionar espaço no reflexo de que ele ainda não perdeu. Assim, não
podemos colocar simplesmente “espere até <tecla [espaço pressionada?]>” logo abaixo do botão
“repita até que < >” e “esconda”. Pois provavelmente o jogador pressionaria o botão e o jogo já
recomeçaria imediatamente, impedindo de por exemplo ver o placar atingido, ou até mesmo decidir
se quer ou não jogar de novo.

Por isso, uma alternativa funcional é colocar após o “repita até que < >” e “esconda”, o
botão “espere (0.5) seg”. Isto dará o tempo do jogador perceber o que ocorreu e mesmo que ele
tenha pressionado espaço após perder, nada significará para o programa. Então podemos colocar o
botão “espere até <tecla [espaço] pressionada?>”, seguido dos botões “envie [message1] a todos”.
Peça que os alunos tentem jogar assim. Parecerá tudo normal na primeira vez, talvez até na
segunda, mas quando chegar na quarta tentativa, perceberão que os raios não estão sendo apagados
e nem diminuindo sua intensidade quando o jogo recomeça.

Isto por que, a intensidade com que os raios caem depende do cronômetro (lembra daquela
expressão, raiz quadrada de cronômetro, dividido pelo cronômetro?). E em nenhum momento
pedimos para o cronômetro reiniciar quando o jogo recomeçasse. Assim, para corrigir este
problema, basta que insiramos abaixo do “quando receber [message1]” (pode ser qualquer um
destes botões), o botão “zere o cronômetro”. Agora o problema da intensidade esta resolvido, falta
apenas cuidar dos raios sumirem quando reiniciamos o jogo. Para isto abra o ator raio. Vamos
inserir na Área de trabalho deste ator os seguintes botões juntos “quando receber [message1]” e
“apague este clone”. Este par de botões, faz com que no momento que o programa recebe o sinal,
ele apaga os clones deste ator. Simples?

Agora só falta uma coisa. Inserir um placar. Para isto vamos criar uma variável “Score:” e
acrescentar um botão da categoria Eventos ao nosso Robô, “quando receber [message1]”. Abaixo
dele, acrescentaremos os botões “mude [Score:] para (0)”, pois queremos que o placar comece
zerado. Abaixo ele, eu achei melhor inserir um botão “sempre” e dentro dele um “espere (1) seg”
seguido de um “adicione a [Score:] (arredondamento de ((cronômetro)*5))”.

Digo acima que achei melhor pois o Score que o jogador marca não influencia o movimento
do Robô e a queda de raios. Contudo achei melhor ter esta espera de 1 segundo entre cada repetição,
pois sem ela o valor do Score ficaria modificando rápido demais para o jogador conseguir
acompanhar, ficariam vários números mudando em uma velocidade que tiraria a emoção de
enxergar quantos pontos já marcou. Outra coisa, é o valor dos pontos. Escolhi que fossem
adicionados a cada segundo o valor arredondado do cronômetro vezes 5, pois o Score precisa
aumentar de forma lenta no começo e subir rapidamente conforme o jogo chega em seu momento
crítico. Além disso, a escolha pela multiplicação por 5, foi por conta de que quando pensamos na
quantidade de ponto que marcamos, dizer que obtivemos 300 parece mais estimulante do que dizer
que obtivemos 3. Números grandes animam o jogador, e neste sentido que eu escolhi utilizá-los pois
considerei que fosse um valor alto mas não alto demais para que o jogador perdesse seu estímulo.
Em uma tentativa normal eu mesmo consigo marcar de 700 a 1000 pontos. Isto gera mais estímulo
do que dizer que marcou de 20 a 25. Mas como disse no início deste parágrafo, esta parte não altera
nem influência a mecânica do jogo e por isto é uma questão pessoal a escolha do valor que o Score
crescerá.

Mas se você tentou jogar, perceberá que o Score não para de crescer ainda que seu Robô seja
atingido por um raio, podemos consertar isto acrescentando o botão da categoria “Controle”, “pare
[outros scripts do ator]”, abaixo dos botões “repita até que < >” e “esconda” no Script do Robô,
como mostra a imagem abaixo.

Agora temos o jogo completo. Parabenize os alunos por conseguirem construí-lo, contudo
não pare por ai. Este me parece o momento adequado para avaliá-los. Peça para que os alunos
acrescentem um poder ao Robô (por exemplo, uma vez no jogo ficar imune aos raios por 5
segundos) e uma adversidade especial (por exemplo, após o cronômetro passar dos 20 segundos, os
raios ficam maiores, sendo mais difícil do Robô desviar).

Deixe-os livres para criarem aquilo que quiserem, contudo após finalizados, avalie-os
segundo os seguintes critérios. Considerando 0 quando a resposta for Não, 0.5 quando a resposta for
mais ou menos, ou quase, e 1 quando a resposta for Sim.

* O aluno construiu o programa original corretamente?


* O poder oferecido ao Robô funciona corretamente?
* O jogo ficou mais estimulante com este novo poder?
* O aluno precisou se esforçar (dentro de suas habilidades) para criar este poder?
* O poder criado foi original em relação aos seus colegas próximos?
* A adversidade criada funciona corretamente?
* O jogo ficou mais desafiador com esta nova adversidade?
* O aluno precisou se esforçar (dentro de suas habilidades) para criar esta adversidade?
* A adversidade criada foi original em relação aos seus colegas próximos?
* O aluno acrescentou algum elemento a mais do que foi pedido (por exemplo modificações na
aparência, cenário, raios mais coloridos, comandos melhores)?

Repasse as notas para cada aluno e conforme achar necessário, peça que revejam as aulas
anteriores afim de nivelarem seus conhecimentos para que prossigam no curso. Com isto chegamos
na metade do curso.
Hora 13: Bingo
Um jogo bastante simples é o Bingo. Sua construção pode parecer simples, contudo o Bingo
envolve o sorteio de uma lista de opções, sendo que a cada sorteio, o elemento sorteado é removido
desta lista. Dessa forma, o principal objetivo desta parte do curso é desenvolver um pouco mais o
domínio do estudante na questão de usar a variável “lista”.

Primeiramente criemos um projeto novo e nele crie um novo ator com algumas fantasias
diferentes. Recomendo que elas sejam números de 1 a 6 do próprio conjunto de fantasias que o
Scratch 2.0 oferece, como pode ser visto na imagem abaixo.

Assim, como precisamos realizar um sorteio, devemos lembrar de como o Bingo funciona.
Existem várias bolinhas com números. Ou seja, podemos usar uma lista cujo conteúdo sejam
números de 1 a 6 neste caso. Então cada vez que o usuário apertar a tecla espaço (por exemplo), o
programa sorteará uma das posições da lista e mudará o nosso ator para a fantasia correspondente.
Contudo, também será preciso apagar o conteúdo desta posição da lista.

Preste bastante atenção. Se temos uma lista com os respectivos 3 elementos nas três
primerias posições, a, b, c. Ao apagarmos o elemento b da lista, estamos apagando o segundo
elemento. Entretanto agora nossa lista terá 2 elementos nas duas primeiras posições com
respectivamente, a, c. Isto significa que nosso espaço para sorteio será o tamanho da lista – a
quantidade de sorteios realizados. Assim, no primeiro momento, nossa lista terá seu tamanho
original. No segundo sorteio, nossa lista terá seu tamanho -1. Já no último sorteio, nossa lista terá
apenas um elemento.

Seguindo as ideias observadas acima e utilizando os conhecimentos prévios adquiridos ao


longo deste curso, devemos facilmente construir os seguintes conjuntos de botões. (tente construí-
los sozinho antes de olhar as explicações abaixo).

Neste conjunto de botões, temos a inicialização do programa seguida do processo de


esconder nosso ator, por conta de que antes do sorteio ser realizado, nenhum valor deve ser
mostrado. Assim, também mudamos o tamanho dos números para 400% seu tamanho original (uma
escolha que fiz para melhorar a visualização dos números, mas não é necessária para o
funcionamento do programa). Então, apagamos todos os valores já existentes na lista “Bingo” (se
não lembra o que é uma lista ou como criá-la, reveja a Hora 4). E seguimos com o preenchimento
automático de seus espaços. Veja que neste último botão, fazemos uso do próprio tamanho da lista
+1, para poder preenchê-la com os números em sequência (lembrando que a escolha do “6” é
apenas por conta de termos criado seis fantasias para nosso ator, este número pode ser alterado sem
qualquer influência, desde que as fantasias existam em número suficiente).

Agora neste segundo conjunto de botões. Estamos lidando especificamente com o momento
que o usuário pressionar “espaço” (pode ser qualquer outro botão a sua escolha). Primeiro
revelamos o nosso ator (que foi escondido ao inicio do programa). Então atribuímos para a variável
“bola da vez”, um número que varia entre 1 e o tamanho da lista “Bingo”. Isto quer dizer, que se
existem 40 bolinhas no bingo, este botão sorteará um número natural entre 1 e 40.

Após este sorteio, ele mudará a fantasia do nossa ator para o conteúdo da posição sorteada.
Perceba que aqui não sorteamos o número do bingo, e sim a posição dele na lista. Isto quer dizer,
que se existem 40 bolinhas, pode ser que após 38 sorteios sobre apenas o número 21 e o número 40
por exemplo. Estes dois estarão nas posições 1 e 2 da lista. E o sorteio ocorrerá entre os números
naturais 1 e 2. Se sortear 1, será mostrado o primeiro elemento da lista, neste caso o 21, e se sortear
2, será mostrado o segundo elemento da lista, neste caso o 40.

Assim, após este valor ser mostrado para o usuário, como já vimos antes, ele não sumirá da
tela a menos que mudemos sua fantasia ou ativemos o botão esconda. Deste jeito, o botão “apague
(bola da vez) de [Bingo]”, removerá o elemento da posição sorteada da nossa lista, deixando a lista
com um elemento a menos.

Abaixo segue um link para acesso ao projeto de Bingo criado seguindo as instruções acima.
https://scratch.mit.edu/projects/90052733/. A essa altura do curso, acredito que todos sejam capazes
de modificar as configurações do programa sem risco de comprometer seu funcionamento. Dessa
forma, seria interessante se cada um aumentasse o número de sorteios para 8 e inserisse alguma
interação com o usuário (uma mensagem explicativa ou um apresentador para os resultados do
bingo).

Hora 14: Forca (parte 1)


Um jogo bastante simples é a Forca. Sua construção pode parecer simples, contudo a Forca
envolve checar se a letra digitada pelo jogador já foi digitada antes ou se ela pertence a palavra. E
então mostrar pro jogador onde estão estas letras. Isto já deixa
bastante claro que para montarmos este programa precisaremos de
listas. Assim, para começar, podemos criar dentro do script do
Palco, os botões “quando clicar em inicializador” junto com “envie
[begin] a todos”. Observe que quando lidamos com scripts no Palco,
alguns botões não fazem sentido. Como por exemplo, os de
movimento, já que o Palco é o pano de fundo da tela, ele se
movimenta, apenas está presente. Mas como neste momento da
nossa construção, utilizaremos apenas definições e ações com
variáveis e listas, podemos construir estes botões no próprio Palco
sem que hajam conflitos. Assim, acrescente os botões “quando
receber [begin]” junto com “apague (todos) de [forca]”, “apague
(todos) de [forca numérica]”, “apague (todos) de [letras erradas]”,
“mude [ponteiro] para (0)”, “mude [erro] para (0)”, “mude [acertos] para (0)”. Como pode ser visto
na imagem acima.

Criar listas e variáveis não é um problema a essa altura do curso. Contudo para evitar
problemas de comunicação entre os atores e o palco, as variáveis precisam ser do tipo, “para todos
os atores”. Dentre as listas criadas, a lista “forca”, guardará a palavra a ser descoberta, enquanto que
a lista “forca numérica” guardará os números correspondentes a cada letra da forca (exemplo, a=1,
b=2, c=3, … , z=26). Já a variável “ponteiro”, será usada para percorrermos de maneira ordenada a
nossa lista, sendo mais um indicador de onde estamos na nossa busca para encontrar onde a letra
está na palavra.

Assim, criamos junto ao nosso botão “mude [acertos] para (0)”, os botões “pergunte
[Escolha uma palavra] e espere a resposta”. Seguido do botão “repita (“tamanho (resposta)”)
vezes”. Este botão, repetirá as ações que estiverem dentro dele, o número de letras que tiverem na
palavra, assim para uma palavra de 8 letras por exemplo, este botão repetirá o que houver dentro
dele por 8 vezes. Com isto, podemos colocar dentro um botão “adicione a [ponteiro] (1)” e “insira
(“letra (ponteiro) de (resposta)”) na posição (1) de forca”. Para cada repetição o ponteiro indicará o
número vezes que o processo esta sendo realizado, e o botão seguinte joga para a lista letra por letra
da palavra na mesma ordem que ela foi escrita. Então, fora do repita, acrescentamos o botão “envie
[message1] a todos”, pois isto indicará ao resto do programa, que a palavra inteira já foi inserida
letra por letra na lista. Abaixo segue como este conjunto de botões deverá ficar (lembre-se que este
conjunto estará unido ao anterior).

Agora, teremos um pouco de trabalho. Pois como já podem ter percebido, o Scratch 2.0 não
é capaz de ler uma letra e interpretá-la como um número. Assim, como para apresentarmos as letras
na tela do usuário, utilizaremos um ator com fantasias das 26 letras do alfabeto, precisamos de um
modo de acessar qual letra mostrar por meio de um número. Isso significa, que se a letra escolhida
para mostrar for a letra h por exemplo, pediremos que este ator revele a fantasia número 8.

Contudo, ainda precisamos resolver o problema do Scratch 2.0 não realizar essa conversão.
Assim, precisaremos criar um grupo de botões que realize esta função. Para causar o mínimo de
confusão e diminuir o risco de falhas atrapalharem o restante do programa, recomendo que realize
os passos seguintes em um novo ator, criado exclusivamente para isto.

Comecemos criando um botão da categoria Eventos, “quando receber [message1]” (ou seja,
quando o programa tiver terminado de converter a resposta do usuário para a lista Forca, esta ação
será iniciada. Então, como precisaremos também de um ponteiro e seu trabalho na lista Forca já
terminou (pois recebemos a [message1]), acrescente o botão “mude [ponteiro] para (0)”. Insira um
botão “repita (tamanho de [forca]) vezes”. E dentro dele o botão “adicione a [ponteiro] (1)”. E fora
do botão repita, “envie [message2] a todos”, pois isto indicará aos demais atores que este processo
terminou e consequentemente a variável ponteiro, está livre para ser usada.
Entretanto eu avisei que esta etapa daria algum
trabalho. Pois dentro do repita e abaixo do “adicione a
[ponteiro] (1)”, devemos colocar um “se < > então” para
cada letra do alfabeto. Ou seja, 26 se < > então”. Dentro
de cada “se < > então”, devemos perguntar se o “(item
(ponteiro) de [forca]) = a, b, c, …, z)”. E em caso
afirmativo, “insira [1, 2, 3, …, 26) na posição (1) de
[forca numérica]”.
Isto gerará após a escolha da palavra, uma lista
composta apenas de números.

Hora 15: Forca (parte 2)


Agora começaremos com algo simples. Criar o número de tracinhos equivalente a
quantidade de letras da palavra. Primeiro devemos criar um ator com uma fantasia de
"tracinho" (lembre-se de centralizá-la). Agora vamos escolher a posição do primeiro
tracinho (os demais serão clones deste ator). Dessa forma eu escolhi que o tracinho
comece na posição x:-220 e y:-100. Assim, criamos para este ator o seguinte script,
"quando receber [begin]", "esconda" e "vá para x:(-220) y:(-100)".

Para continuar, precisamos saber quantas letras a palavra possuí.


Assim, podemos criar o evento, "quando receber [message1]" junto dos
botões "mostre" (pois antes da palavra ser digitada, nós o escondemos).
Então, acrescentaremos o botão "repita ((tamanho de forca) -1) vezes" e
dentro "crie clone de [este ator]" e "mude x para ((posição x) + 40)".
Como pode ser visto na imagem ao lado. O motivo para usarmos o
tamanho da forca -1, é que estamos contando com o tracinho original.
Agora quando digitarmos a palavra, logo se formará na tela o mesmo
número de tracinhos que letras da palavra.

Agora, faremos a parte final do processo. Crie um novo ator e nele insira 26 fantasias
de alfabeto na ordem. Estas fantasias podem ser encontradas no próprio Scratch 2.0. É
um processo repetitivo, porém necessário. Primeiro devemos arrumar o tamanho das
fantasias com o tamanho do tracinho que aparecerá abaixo dela, no meu caso, reduzi
para 40% seu tamanho original. Assim, comece criando o seguinte conjunto de botões,
"quando clicar em inicializador", "mude o tamanho para (40)%" e "esconda".

Neste momento é necessário uma atenção redobrada, uma vez que trabalharemos
com muitos "se < > então" uns dentro de outros. Comece criando o evento "quando receber
[message2]". E acrescente o botão "repita até que <((acertos)=(tamanho de [forca numérica])) ou
((erro)=(8))>". Isto realizará as ações deste botão da categoria controle até que o jogador acerte
todas as letras ou erre 8 vezes. Ou seja, no jogo da forca, até que o jogo termine, o jogador deve
poder escolher uma letra, então dentro deste repita, colocaremos "pergunte [Escolha uma letra:] e
espere a resposta".

Debaixo da pergunta colocaremos um "se <não ([letras erradas] contém (resposta)?)>". Esta
condição verifica se na lista "letras erradas", já existe a letra digitada pelo usuário. Ou seja, se ele
escolheu a letra A uma vez, A irá para a lista de "letras erradas" (o nome apropriado dessa lista
deveria ser "letras usadas") e quando for novamente escolhida, não entrará para este "se < > então".

Dentro deste "se < > então", acrescente um "se < ([forca] contém (resposta)?) > então;
senão". Aqui estamos verificando se na lista de letras que compõe a palavra, existe a letra escolhida
pelo jogador. Caso não exista, o programa avançará para o senão, nele vamos colocar "insira
(resposta) a [letras erradas]" e "adicione a [erro] (1)". Isto acrescenta a lista [letras erradas] a letra
que não pertence a palavra e também soma 1 ao número de erros.

Voltando para dentro do "se" de "se < ([forca] contém (resposta)?) > então; senão",
acrescente os botões "mude [ponteiro] para (0)", "insira (resposta) a [letras erradas]" e um "repita
(tamanho de [forca] vezes). Aqui, faremos um processo de checar para cada letra da nossa palavra,
se ela corresponde a letra escolhida. Dentro deste repita, acrescente os botões "adicione a [ponteiro]
(1)" e um "se <((item (ponteiro) de [forca]) = (resposta))> então".

Dentro deste botão acrescentaremos o seguinte conjunto de botões, "adicione a [acertos]


(1)", "substitua o item (ponteiro) de [forca] por (0)". Aqui estamos trocando a letra encontrada por
0, isto evitará que a letra seja reencontada toda vez que for feita a busca. Em seguida, "mude para
fantasia (item((tamanho de [forca numérica]-((ponteiro)-1) de [forca numérica])”.

Abaixo deste botão, acrescente o botão “mude x para ((40*(tamanho de [forca numérica])-
(ponteiro))-220)” e “crie clone de [este ator]”. Aqui estamos localizando a posição da letra
encontrada e trocando a fantasia do ator para esta letra, então a movemos de forma que apareça
acima do tracinho correspondente (observação, o espaçamento que dei entre cada tracinho foi de 40,
por isto aqui acima uso o valor 40).

Agora basta criarmos um novo conjunto de botões, “quando eu começar como clone”
seguido de “mostre”. Isto revelerá o clone da letra que o jogador acertou. Abaixo segue um link
para acesso ao projeto de Forca criado seguindo as instruções acima.
https://scratch.mit.edu/projects/94842278/. Agora cada um deve acrescentar no jogo a imagem de
uma forca e seu bonequinho sendo formado a cada erro que ocorra (uma possibilidade para isto, é
criando um ator com várias fantasias e trocando-as a medida que a variável erro aumenta). Além
disto, também devem oferecer ao jogador duas opções, escrever uma palavra para o outro jogador
jogar a forca (a maneira atual que o jogo funciona) ou dispor uma lista com pelo menos 10 palavras
das quais o jogador pode jogar sozinho por meio do programa que selecione ao acaso alguma dessas
palavras.
Hora 16, 17 e 18: Jogo da Bruxa
Nesta hora e nas próximas duas, desejamos averiguar o andamento da turma em relação a
capacidade de construção em forma independente. Abaixo segue o link do Jogo da Bruxa
(desconheço se existe um nome para este tipo de jogo) https://scratch.mit.edu/projects/95418729/.
Neste jogo, uma bruxinha explica que o jogo começará ao pressionarmos qualquer tecla. Então nos
veremos em uma tela com uma pergunta no fundo e duas respostas voando de maneira aleatória. Ao
apertarmos Z, a bruxa lança uma magia, que se acertar a resposta correta, ela avança ao próximo
nível, mas se acertar a resposta errada, ela vai para uma tela que pergunta se deseja continuar a
jogar. A velocidade de movimento das respostas varia, isto pode levar ao jogador mirar na resposta
correta, mas ela sair do lugar na hora e atingir uma resposta errada.

O professor deve inicialmente jogar um pouco para se acostumar e compreender melhor o


funcionamento deste jogo. Então em sua conta, crie uma versão "Remix" deste projeto e mude para
um nome qualquer e NÃO COMPARTILHE. Pois você deve apresentar o jogo no projetor aos seus
alunos, deixá-lo disponível para que eles venham testar e experimentar, contudo, não os deixe olhar
o interior do jogo (ou seja, eles não devem ver como o jogo foi feito). A razão disto, é que eles
deverão construir um jogo com esta mesma estrutura e por experiência própria, é comum quando os
alunos vêem uma versão construída, que se limitem nos modos de fazer.

Contudo, ao professor esta pode ser uma das aulas mais difíceis, pois agora teremos todos os
alunos realizando suas próprias construções e cabe ao professor oferecer assistência aos seus
trabalhos. Lembre os alunos que eles não precisam reproduzir o jogo de maneira idêntica. Apenas o
tipo de jogo, ou seja, um jogo onde seu personagem se desloca e precisa acertar a resposta correta
que também se movimenta. Abaixo seguem algumas dicas que podem servir de orientação a esta
construção.

Dica 1: As respostas certas são todas fantasias de um mesmo ator com um sensor que avisa quando
a magia da bruxa o atingiu.
Dica 2: Após cada resposta ser atingida, ambas se escondem pelo tempo suficiente para ter certeza
que a magia da bruxa saiu da tela e não ter o risco de com um só disparo acertar a resposta de duas
perguntas.
Dica 3: As respostas continuam movendo-se após serem atingidas, mas como elas estão escondidas
nesse tempo, dá a impressão ao jogador que elas reapareceram em partes aleatórias da tela.
Dica 4: Quando uma resposta certa é atingida, ela envia uma mensagem que faz ela e a errada se
esconderem, e ambas ao receberem esta mensagem avançam para sua próxima fantasia.
Dica 5: A bruxa tem uma posição diferente quando não se movimenta horizontalmente. Isto se torna
mais fácil de ser feito usando dois grupos de botões "sempre". Quando a tecla direita ou esquerda
estiver pressionada, peça para que repita até que a tecla não esteja mais pressionada.
Dica 6: Mantenha o ator que servir de magia da bruxa escondido e sempre que a tecla de disparo for
pressionada, atualize sua posição para a posição atual da bruxa, verifique para qual lado ela esta
virada, crie um clone e faça o clone aparecer movimentando-se na direção certa.
Dica 7: Utilize algum controlador para evitar que se o jogador digitar inicialmente o botão de
disparo, para a bruxa não começar o jogo disparando.
Dica 8: Focalize-se inicialmente na construção da estrutura do jogo para depois se preocupar com a
interação que ele terá com o jogador.
Dica 9: Evite criar vários atores para um mesmo personagem.
Dica 10: Se deseja trocar de personagem, se preocupe com a movimentação dele na tela, pois a
bruxa em sua vassoura possuí a vantagem dela poder mover-se com poucas fantasias e ainda assim
dar a impressão de que esta se movendo corretamente.
Dica 11: Limite os disparos da bruxa por um intervalo de tempo, pois senão ela lançaria várias
magias sequencialmente se o usuário segurasse a tecla de disparo.

Após as construções, peça que eles apresentem seus jogos para o restante da classe junto
com o modo como foi feito. Algo que não demore mais que um minuto cada apresentação. Por
último mostre como era a versão original e aproveite a oportunidade para discutir com os alunos
sobre as diferenças que constataram, suas principais dificuldades e proponha que joguem os jogos
de seus colegas. Ao professor, certifique-se que cada um compartilhou seu jogo e reuna todos em
um mesmo projeto do Scratch 2.0. Assim, além de se tornar mais fácil acessá-los, também podem
ser usados para futuras observações sobre o desempenho e evolução de cada aluno.

Hora 19, 20, 21, 22, 23 e 24: Projeto Livre


As seis horas que seguem deste curso devem ser destinadas a elaboração de projetos livres
por parte dos alunos. O professor neste momento deve manter-se atento para que os alunos
participem e também auxiliá-los na criação do jogo. Uma recomendação que dou desde já, no caso
de algum aluno propor uma construção da qual você não imagine como possa ser feita, pesquise no
site https://scratch.mit.edu/ algum jogo similar e copie a mecânica.

Contudo, dentre os vários tipos de jogos que já procurei no site, sempre achei os jogos de
luta, de pouca qualidade. Dessa forma, disponibilizo a seguir o link de um jogo de luta que
desenvolvi e que pode ser usado como base mecânica para a construção de um jogo similar.
https://scratch.mit.edu/projects/83078214/.

Além disso, durante a proposta de jogo que os alunos fizerem, tente auxiliá-los para que seus
projetos sejam viáveis de terminarem nessas 6 horas. Ainda que a versão completa não seja
possível, mas que ao menos após este tempo, tenha algo para mostrar do jogo em si. Peça que todos
os alunos compartilhem seus projetos no final do primeiro dia de trabalho, então copie-os para sua
conta em um projeto com todos os projetos compartilhados reunidos. Isto lhe ajudará a
compreender as dificuldades de cada aluno e como pode auxiliá-los. Conforme os alunos venham
terminando seus projetos, peça que eles os apresentem para os demais alunos e dependendo de seu
comportamento, permita que eles tentem auxiliar seus colegas na construção de seus projetos.

Após o encerramento do curso, troque contatos com os alunos e tente mantê-los informados
sobe cursos similares ou eventos do gênero. Em caso de dúvidas (ou desespero) mediante a
contrução de algum projeto. Me encaminhe um e-mail para dificildedizer@gmail.com. Espero que
tenha gostado do curso. Estou a disposição para comentários, críticas ou para esclarecimento de
dúvidas.

Você também pode gostar