Lego Mini Memory Game: 5 etapas (com imagens)

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:37

Há cerca de um ano, escrevi um Instructable sobre a instalação de vários LEDs em um Lego Mini Cooper. A inovação, por assim dizer, era que os LEDs podiam ser controlados com um smartphone (ou por meio de qualquer navegador da Web, por falar nisso).

Como eu laboriosamente descrevi naquele Instructable, a maior parte do esforço naquela época relacionava-se a conectar o Mini sem que tudo desmoronasse. Para minha surpresa, o Mini sobreviveu a uma viagem de Connecticut a Toronto e funcionou, mais ou menos, desde então.

"Se não estava quebrado, ele consertou até que ficasse" será meu epitáfio, na melhor das hipóteses, então, quando o Mini voltou para casa no Natal, era hora do Lego Mini 2.0. Afinal, se a Tesla pode enviar atualizações de software para seus carros, quão difícil isso poderia ser?

Tive algumas ideias:

• Melhorar a interface de usuário um tanto desajeitada
• Adicione um chifre!
• Melhorar o recurso de "luzes automáticas"; e, o mais importante
• Adicione uma função de jogo (até eu reconheci que a novidade de ligar e desligar as luzes do Mini com o telefone iria perder o brilho mais cedo ou mais tarde)

A função do jogo era a maior tarefa, até porque não era imediatamente óbvio para mim que tipo de jogo poderia ser. O Mini é muito frágil para sustentar um jogo envolvendo sua manipulação (exceto possivelmente uma variante deprimente de Jenga). Outro obstáculo é que nunca programei um jogo na minha vida.

Depois de um ano de reflexões infrutíferas, me deparei com um projeto no Hackster, no qual um Arduino Uno é usado para emular um brinquedo de jogo de memória datado da década de 1970 chamado Simon. Resumindo, o dispositivo Simon reproduzia uma sequência de luzes que o jogador precisava lembrar e reproduzir pressionando botões. Depois de cada rodada bem-sucedida, a sequência aumentava de tamanho.

Apesar de ser da safra necessária, eu nunca tinha ouvido falar desse jogo, e devo dizer que é incrível o que era passado por diversão naquela época. Ainda mais surpreendente é que o jogo Simon ainda está à venda e recebendo ótimas críticas na Amazon. Claramente, esse tinha que ser o principal candidato a se adaptar aos meus propósitos. Afinal, o Mini já tinha as luzes, então tudo que eu precisava fazer era abandonar os botões físicos e ter a entrada do usuário fornecida por meio de um smartphone. No lado do software, portanto, parecia que isso seria basicamente um trabalho de recortar e colar.

Mas, primeiro, precisei fazer algumas pequenas modificações no hardware.

Etapa 1: Componentes, ferramentas e recursos

Se você estiver replicando este projeto com um Lego Mini, precisará de todas as coisas listadas no meu Instructable anterior. A única coisa extra de que você precisa é uma campainha passiva, que é usada para a buzina e para fazer um monte de ruídos irritantes durante o jogo (que pode ser desativada).

Como ficará claro ao discutir o software, não há necessidade real de usar um Lego Mini para o jogo. Você poderia usar outro kit Lego, ou mesmo um monte de LEDs em uma placa de ensaio conectada a qualquer placa de desenvolvimento ESP8266. Com alguns relés, você pode até usar a iluminação da sala de sua casa. Crianças, perguntem a seus pais primeiro sobre isso.

Da mesma forma, nenhuma ferramenta ou recurso adicional é necessário além daqueles listados para o projeto original.

Se você está entre o punhado de pessoas que leram a descrição original do projeto, você saberá que o Lego Mini foi originalmente comprado como um presente para minha filha adulta, que tem um Mini "real" quase idêntico, ou quase idêntico como pode ser dado que é um Novo Mini, não um "Clássico". A falta de quaisquer componentes adicionais significativos tornou este novo projeto ainda mais atraente, uma vez que me permitiria efetivamente re-presentear o Lego Mini 2.0 como um novo presente de Natal sem custar nem um centavo. Gênio!

Etapa 2: modificação de hardware

O projeto original tinha LEDs RGB controláveis individualmente. Isso consumiu três pinos no NodeMCU, que eu estava usando como placa de desenvolvimento. Após uma consulta discreta com o proprietário do Lego Mini, foi determinado que os LEDs RGB eram um recurso subutilizado. Essa era uma informação importante porque eu precisava liberar um alfinete para a campainha / buzina.

O diagrama de circuito acima é do projeto original. A única mudança necessária para este projeto foi remover os LEDs RGB e usar os três pinos liberados da seguinte forma:

• D1 para o sinal de controle da campainha (que também é conectado diretamente à fonte de alimentação 5 VCC)
• D7 para um interior LED branco
• D8 para um daqueles LEDs coloridos que piscam, que eu chamei de luz "discoteca"

A campainha em si fica bem posicionada sob o compartimento do motor, de modo que passar os fios de volta para o NodeMCU foi muito rápido.

Etapa 3: Atualizando a GUI

A primeira etapa na atualização da GUI foi criar quatro páginas da web separadas:

• Uma "tela inicial" que é iniciada por meio de um ícone personalizado em seu smartphone e vincula a outras páginas
• A página "Controles" que, bem, controla as luzes (e agora, é claro, a buzina)
• A página "Jogo"

• Uma página de configuração que contém opções de configuração como:

  • Ligar e desligar o som
  • Definir o fuso horário (o Mini obtém o tempo da Internet para que possa piscar as luzes na hora certa)
  • Ajustar quando as "luzes automáticas" ligam e desligam os faróis com base no nível de luz ambiente
  • Redefinindo o nome do High Score e do High Scorer (armazenado na EEPROM)

Separar as funções dessa maneira torna a experiência muito mais semelhante à de um aplicativo. Fazer com que o NodeMCU atenda a várias páginas foi um dos desafios deste projeto. Depois de tentar algumas abordagens diferentes, encontrei o código que você vê nas linhas 232 a 236 do esboço principal do Arduino. Isso funciona muito bem - basta criar seu arquivo de índice e nomear as páginas subsequentes como página 1, página 2, etc. Descobri que precisava colocar todos os arquivos de recursos (CSS e imagens) na pasta de dados raiz, mas isso não é realmente um problema para sites de deste tamanho.

Em seguida, tive que trabalhar com CSS e Javascript para fazer algo que parecia pertencer a um Lego Mini. Como não sei quase nada sobre nenhum dos dois assuntos, procurei muito aqui antes de encontrar algo que me deixasse feliz. Comecei copiando descaradamente um bloco de lego em estilo CSS no CodePen aqui. Eu também queria deixar de rotular os botões com texto e acabar usando os gráficos simples do Icons8, que eram perfeitos para meus propósitos. O resto meio que se encaixou a partir daí. As páginas são renderizadas muito bem em todos os iPhones em que testei. Esperançosamente, o mesmo também é verdadeiro para telefones Android (parece OK em um navegador Chrome para desktop).

Etapa 4: o código do jogo

A comunicação entre o servidor NodeMCU e o navegador do smartphone é via Websockets. Depois que um botão é pressionado pelo usuário, o navegador envia um caractere de texto ao NodeMCU que corresponde a uma ou mais luzes do Mini. Personagens adicionais são enviados para controlar o fluxo do jogo. O código do Arduino então age com base no caractere recebido. A comunicação do Websocket só pode lidar com caracteres binários e de texto, portanto, é necessária alguma conversão para inteiros (por exemplo, o fuso horário).

Como mencionei, originalmente havia previsto usar o código do projeto Hackster vinculado para as funções centrais do jogo. O que eu previ que aconteceria é que, depois que um jogador pressionou um botão, o LED correspondente acenderia e o código faria uma leitura digital em todos os LEDs para ver se o correto estava aceso (o projeto Hackster verifica as entradas físicas do botão, mas é a mesma ideia). Isso funcionou, mais ou menos, mas por motivos que ainda não estão claros para mim, não perfeitamente. Cerca de 10% das vezes o Mini diria que um botão incorreto foi pressionado quando, na verdade, o correto havia sido pressionado. Tudo parecia bem com base no que pude ver no monitor serial e no console do navegador, então não tenho ideia de por que não funcionou.

Depois de muita dificuldade em tentar introduzir alguma verificação de erro, abandonei toda a ideia de ler os estados do LED e criei uma matriz de "resposta" que verifica se o texto do Websocket recebido corresponde ao pino correto armazenado na matriz de "sequência" que reproduz a sequência de luzes para lembrar. Isso parece ser 100% confiável, mesmo que a maneira como implementei seja um pouco trabalhosa. Depois de inventar esse método, me deparei com isso, que é uma exploração interessante da maneira como alguns bloqueios digitais funcionam e é análogo à abordagem usada no jogo.

O tempo de entrada de botão agora é tratado com Javascript no lado do navegador (eu permito uns generosos 10 segundos entre as entradas de botão) e o fluxo do jogo agora é inteiramente controlado pelo jogador em vez de codificado. O visor inclui janelas que mostram o tempo restante para fazer o próximo botão pressionado e o número de entradas restantes antes que a sequência seja enviada corretamente pelo jogador.

A pontuação mais alta é armazenada na EEPROM (ou o que passa por EEPROM no mundo ESP8266) e se um jogador atingir uma nova pontuação alta, uma caixa pop-up permite que ele insira um nome de sua escolha, que também é armazenado na EEPROM. Esses valores podem ser redefinidos por meio da página de configuração (tenho certeza de que pode haver motivos legítimos para isso).

Com tudo isso dito, eu reutilizei uma parte decente do código do jogo Hackster, o que acelerou muito as coisas.

Etapa 5: O resto do código

Comparado ao código do projeto Hackster, meu esboço do Arduino parece enorme, mesmo sem todo o HTML, CSS e Javascript nos arquivos de dados. Mas a maior parte do esboço é um monte de funções relacionadas a operações básicas, como criar e gerenciar o servidor, obter tempo NTP, mDNS, fornecer atualização remota, gerenciamento de WiFi, gerenciamento de arquivos SPIFFS e assim por diante.

O Javascript nos arquivos HTML é principalmente para lidar com as mensagens do Websocket (recebidas e enviadas) e aumentar a interatividade da GUI.

Como mencionei, eu queria melhorar a funcionalidade do recurso "luzes automáticas", que usa um resistor dependente de luz no único pino analógico do NodeMCU para detectar a luz ambiente e ligar as luzes do Mini em um nível predefinido (quando não estiver no modo de jogo, claro). Embora este seja um recurso muito frívolo em um projeto frívolo, me incomodou que no projeto original eu tinha codificado o limite de ativação e que o usuário não tinha como ver como o nível de luz predominante se relacionava com esse limite. Agora, a leitura do nível de luz é enviada para a página de configuração a cada cinco segundos e essa página também exibe os limites atuais para ligar e desligar (que podem ser configurados pelo usuário). Então, trabalho feito nisso.

Oh, quase esqueci. O código está no GitHub aqui. Após o download, coloque o pacote inteiro em uma nova pasta, carregue o esboço do Arduino e, em seguida, o conteúdo da pasta de dados no SPIFFS.