Jogo que avalia e estimula a memória de adultos e idosos, feito para o
trabalho de Psicologia da minha namorada. A pessoa ouve a receita da
sopa, compra os ingredientes na feira, cozinha na ordem certa e, depois,
tenta lembrar como foi o passeio.
Meu papel
O jogo inteiro. A teoria e o trabalho escrito são dela
Período
Novembro de 2026 · disciplina de Neurociência Cognitiva
Minha namorada estuda Psicologia e precisava apresentar um jogo que
avaliasse a memória de trabalho e a memória episódica de adultos e idosos.
Muita gente desse público tem pouca intimidade com tela. Então o jogo não
podia pedir para digitar, arrastar ou rolar, nem mostrar cronômetro.
Também não dava para copiar testes comerciais. Antes de programar,
estudamos juntos os artigos sobre memória (Baddeley, Cowan, Tulving),
envelhecimento e uso de tecnologia por idosos, além das diretrizes de
acessibilidade WCAG 2.2. Cada regra do jogo veio dessa pesquisa.
o que eu construí
Uma história do dia a dia, em quatro fases
A vó dita a receita da sopa e a lista some. Na feira, no meio das compras,
ela pede uma troca ("troque a batata por mandioca"). Na panela, os
ingredientes entram na ordem de preparo. Depois de um intervalo, vem o
almoço: a pessoa tenta lembrar o que comprou, onde e quando.
Para o participante
Só toca e fala: sem digitar, arrastar, rolar ou toque duplo
Voz gravada da vó, a mesma para todo mundo
A cor nunca aparece sozinha: cada barraca tem feirante, cor, símbolo e nome
Rodada de treino sem pontuação antes de começar
Para o aplicador
Botões de controle no canto da tela, longe das mãos do participante
Cada toque registrado com o tempo em milissegundos
Relatório da sessão com os indicadores de cada fase, em PDF
Participante identificado só por código (P01), nunca pelo nome
decisões técnicas
Um jogo é uma máquina de estados
O jogo passa por sete etapas, sempre na mesma ordem. Em vez de espalhar
esse controle pelas telas, deixei tudo num lugar só e fiz o TypeScript
me avisar quando algo ficasse faltando.
Fases tipadas com useReducer
As fases são uma lista fechada de nomes, e um único reducer decide
para onde o jogo vai. Se eu criar uma fase nova e esquecer o texto
dela, o build quebra antes de chegar no navegador.
Sorteio fora do reducer
Cada partida sorteia a receita (5 entre 16 ingredientes), a troca e
a posição das barracas. O sorteio acontece antes e entra pronto no
reducer, que continua previsível e fácil de testar.
Guardar o dado bruto, calcular depois
O jogo só anota cada toque e o tempo dele. Acertos, omissões, erros
de ordem e ganho com pista são calculados no fim, em funções
separadas. Assim dá para mudar um indicador sem mexer nas telas.
O jogo fala, mas não escuta
Não usei reconhecimento de voz: no Chrome, o áudio vai para os
servidores do Google, e voz ligada à saúde é dado sensível pela LGPD.
Também não há backend. Tudo fica no navegador, e o PDF sai do próprio
window.print(), sem biblioteca.
fases.ts
export typeFase = | 'treino' | 'receita' | 'feira' | 'panela' | 'distrator' | 'almoco' | 'resultados'// uma entrada para CADA fase: se faltar uma, o build quebraexport const INFO_DAS_FASES: Record<Fase, InfoDaFase> = { treino: { titulo: 'Treino', ... }, receita: { titulo: 'A receita', ... },// ...}
telas
Letra grande, botão grande, nada piscando
Fonte Atkinson Hyperlegible com 24px ou mais, feedback em azul e âmbar
com ícone, texto e som (nunca vermelho e verde) e animações curtas que
desligam com "reduzir movimento". O layout foi medido em tablet e notebook.
da feira à panela · a receita
A vó dita a receita, e depois a lista some
Relatório no tablet
o que eu aprendi
Entender o problema antes do código
Foi o primeiro projeto em que as regras vieram da ciência, e não de um
cliente. Precisei ler artigos e entender por que a troca na feira mede a
atualização da memória, ou por que o almoço começa sem pistas. Só depois
disso o código fez sentido.
Também foi onde mais aprendi React e TypeScript. Fiz o projeto em par com
o Claude Code: eu decidia o que construir, testava cada etapa no navegador
e só seguia depois de entender o porquê.
