Skip to content

Latest commit

 

History

History
43 lines (33 loc) · 3.73 KB

README.md

File metadata and controls

43 lines (33 loc) · 3.73 KB
Raw

Shinobi Keyboard

Minigame de digitação.

Lógica do Minigame:

  1. Ao iniciar o jogo, uma sequência aleatória de teclas (por exemplo, letras de A a Z) deve ser gerada e exibida ao jogador.
  2. O jogador deve pressionar as teclas na ordem correta dentro de um tempo limite.
  3. Se o jogador pressionar a tecla correta, a próxima tecla da sequência deve ser destacada.
  4. Se o jogador pressionar a tecla errada ou o tempo acabar, o jogo deve terminar e o jogador deve ser notificado.

Requisitos iniciais:

  • A tela principal deve exibir a sequência atual de teclas que o jogador precisa pressionar.
  • Um indicador de tempo deve mostrar quanto tempo resta para completar a sequência.
  • Feedback visual para indicar se a tecla pressionada foi correta ou não.

Funcionalidade extras:

  • Níveis de dificuldade
  • Contagem regressiva antes de iniciar
  • Pontuação
  • Música e efeitos sonoros em boa parte da gameplay
  • Botões para ativar e desativar música e os efeitos sonoros
  • Animação simples ao acessar o minigame

Pontos técnicos:

  • Escolha do servidor de desenvolvimento: Optei pelo Vite.js ao invés do Next.js, pois é um minigame simples que não precisa de funcionalidades muito complexas que utilizem contextos, provedores, técnicas avançadas de SEO, rotas dinâmicas, serveless, entre outras.
  • Tecnologia: Utilizei Typescript para facilitar a leitura do código e o reconhecimento dos tipos das propriedades sem a necessidade de rodar o projeto. Outra alternativa seria a utilização da biblioteca Proptypes, no entanto, seria fácil esquecer de atualizar os tipos (já que não retorna um erro caso falte uma propriedade) e aquele código não seria mais confiável.
  • Framework: Optei pelo React.js, pois o desafio pedia a tecnologia e até mesmo pela reutilização de componentes, no entanto, poderia ser adaptado para utilizar HTML, CSS e Javascript sem grandes problemas por ser um projeto simples.
  • Nomenclatura de arquivos: Após criar uma pasta de componente ou view, adotei deixar o nome do arquivo principal como index, pois qualquer dev que bata o olho reconhece o significado, porém o arquivo de estilo terá o mesmo nome que a pasta principal, pois dessa forma é possível realizar a busca na IDE e facilmente encontrar a pasta que você quer. Para o hook, após o use também adiciono o nome da pasta, algo mais genérico, para que seja possível englobar qualquer lógica referente aquele contexto. Cê o arquivo ficar muito grande e com muitas responsabilidades, é só criar uma pasta helpers na pasta principal e adicionar as lógicas necessárias.
  • Enum: Enums são valiosos quando um dado pode ter muitos valores diferentes e é necessário reutilizar esses valores em outros lugares do projeto.
  • Versões do node e npm: No package.json é possível identificar quais versões do Node e do npm são aceitas pra rodar o projeto. Dessa forma, evitamos problemas na instalação de dependências e a informação não é centralizado somente em uma pessoa.
  • Pastas: Depois de diversas experiências com estrutura de pastas em projetos pequenos, médios e grandes achei algo que me agrade e que faz sentido.
    • /components: Componentes no geral, independente se for pequeno ou grande.
    • /helpers: Funções reutilizáveis com lógicas isoladas.
    • /styles: Armazena estilos globais ou reutilizáveis.
    • /view: Utilizada para criar o componente pai das páginas. Normalmente é formada por diversos componentes e tem um hook customizado.
    • /page: Para ficar claro quais são as páginas existentes e dentro de cada um apenas chamamos o componente pai (vulgo pasta view).
    • /tests: Pasta principal com subpastas para testes unitários e e2e.