Eu queria criar um jogo. Primeiro, precisei aprender sua linguagem.
Eu queria criar um jogo, mas não sabia por onde começar. Também não entendia como os jogos apresentam informações, conduzem uma rodada ou respondem às ações de quem joga. Sem essa linguagem básica, até uma ideia pequena parecia difícil de organizar.
Passei a chamar essas convenções conhecidas de “linguagem dos jogos”. É apenas um atalho pessoal, não um padrão formal nem uma sintaxe de programação. Ele reúne sinais como a indicação do turno, o destaque do resultado e uma maneira clara de jogar de novo.
O estudo transformou uma vontade vaga em perguntas menores sobre fluxo, informação e resposta. Usei o jogo da velha como exemplo porque seu objetivo é conhecido e uma rodada inteira cabe em uma tela.
Só quer jogar? Experimente o jogo da velha — você não precisa ler o estudo antes.
IA e automação ajudaram a produzir este artigo. Sou o proprietário do AI Maker Lab e assumo a responsabilidade pela redação final e pela verificação das fontes.
Um jogo precisa mostrar o que acontece a seguir
Uma ideia jogável precisa de um caminho completo, não apenas de uma atividade no meio. No jogo da velha, os momentos importantes são começar, fazer uma jogada, ver o resultado e decidir se haverá outra rodada. Pensar em cada momento revelou o que a pessoa precisa antes e depois de tocar no tabuleiro.
Desenhei esse percurso como título → partida → resultado → nova rodada. São situações, não necessariamente páginas separadas. O resultado pode aparecer sobre o tabuleiro concluído, como acontece neste jogo, e ainda assim mudar o que a pessoa vê e pode fazer.
A anatomia de um videogame da MDN descreve uma progressão repetida: apresentar uma situação, receber uma entrada, interpretar uma ação e calcular a situação seguinte. Essa descrição me deu uma forma simples de conferir o percurso. O benefício prático foi enxergar a experiência inteira antes de me concentrar em uma parte da tela.
A tela também faz parte da explicação
A tela precisa responder a perguntas imediatas sem depender de um manual separado. De quem é a vez? Onde posso jogar? Quem venceu? No jogo da velha, as marcas X e O mostram o histórico. O texto de estado informa o turno ou o resultado, e uma linha identifica as três marcas vencedoras.
O HUD, ou painel de informações, mantém dados visíveis durante a partida, como estado ou placar. Essas informações podem ficar sobrepostas à tela, mas também podem existir dentro do mundo fictício do jogo. Um contador de pontos é um exemplo simples de sobreposição. Já uma placa à beira de uma estrada do cenário faz parte daquele mundo.
A dissertação de 2009 Beyond the HUD me deu vocabulário para pensar nessa escolha. Erik Fagerholt e Magnus Lorentzon estudaram interfaces de jogos de tiro em primeira pessoa. Suas categorias servem como perguntas úteis, não como uma regra para todos os gêneros nem como prova de que uma posição seja sempre mais imersiva.
Os controles também explicam a tela. O teclado só ajuda quando a pessoa alcança a ação e enxerga qual controle está em foco. O padrão de botão do W3C descreve a ativação de um botão em foco com Espaço e Enter. Usar controles reais nas células deixa sua disponibilidade visível para quem usa mouse ou teclado. Assim, fica mais fácil decidir o que a pessoa precisa saber e onde o jogo deve mostrar essa informação.
Efeitos são uma forma de o jogo responder
O feedback começa com uma resposta direta à ação. Ao fazer uma jogada, a célula escolhida recebe uma marca. Ao completar uma linha vencedora, o jogo informa quem venceu e destaca a sequência. Essas respostas confirmam o que aconteceu antes de qualquer enfeite adicional.
“Juice” é um nome comum para respostas extras, como movimento, som, partículas ou tremor da tela. A demonstração “Juice it or lose it” adiciona essas técnicas em camadas a um jogo simples. O repositório que acompanha a apresentação permite examinar exemplos de interpolação, som, partículas e tremor. É uma demonstração de possibilidades, não uma promessa de que todo efeito melhora qualquer jogo.
O exemplo de jogo da velha continua discreto. Ele usa marcas, mudanças no texto de estado, tratamentos visíveis de foco e passagem do ponteiro e uma linha vencedora. Não há som, partículas nem tremor. Separar essa implementação da pesquisa mais ampla me ajudou a escolher um efeito pela ação que ele comunica, em vez de adicionar decoração sem propósito.
O estudo me deu uma ordem de trabalho
As perguntas viraram uma ordem compacta para quando uma ideia ainda parece vaga:
- Descrever o objetivo e como a rodada termina.
- Desenhar as situações de início, partida, resultado e nova rodada.
- Criar as menores regras e controles que já permitam jogar.
- Mostrar turnos e resultados e então adicionar respostas que comuniquem mudanças úteis.
- Observar alguém tentando jogar e revisar o que atrapalhar.
A terceira etapa inclui limites, não apenas ações bem-sucedidas. Por exemplo, uma rodada encerrada não aceita novas jogadas. O jogo também oferece um adversário controlado pelo computador, que escolhe entre as casas ainda disponíveis, sem mudar o percurso de quem joga.
Essa ordem é um ponto de partida útil para este projeto pequeno, não o único processo correto para qualquer jogo. Movimento em tempo real, uma história mais longa ou outro grupo de jogadores podem mudar as perguntas e sua ordem.
Ainda não realizei um teste sem orientação desta interface. O próximo passo é observar se alguém consegue escolher um modo, terminar uma rodada e reiniciar sem receber uma explicação. O guia de usabilidade do Nielsen Norman Group descreve a entrega de tarefas a um participante e a observação de seu comportamento. Até isso acontecer aqui, trata-se de uma verificação planejada, não de um resultado.
Experimente o jogo pequeno — ou leve as perguntas para o seu
O resultado útil deste estudo é um conjunto possível de administrar. Qual é o fluxo? Quais informações devem aparecer na tela? Como o jogo responde a uma ação? Essas perguntas me dão um começo concreto sem tratá-las como regras universais.
Você pode jogar uma rodada de jogo da velha só para se divertir. Se tiver curiosidade, também pode reparar em como o jogo comunica uma vitória, mas isso é opcional — não é lição de casa.
Se quiser ver as mesmas perguntas aplicadas a movimento e tempo, a pesquisa sobre o jogo de plataforma é uma leitura opcional.
Fontes
- Mozilla Developer Network. “Anatomy of a video game.” Data de publicação não informada. https://developer.mozilla.org/en-US/docs/Games/Anatomy. Acesso em 2026-08-18.
- W3C Web Accessibility Initiative. “Button Pattern.” Data de publicação não informada. https://www.w3.org/WAI/ARIA/apg/patterns/button/. Acesso em 2026-08-18.
- Fagerholt, Erik, e Magnus Lorentzon. “Beyond the HUD — User Interfaces for Increased Player Immersion in FPS Games.” Dissertação de mestrado, Chalmers University of Technology, 2009. https://odr.chalmers.se/items/d5fe6889-4cc6-49c2-ba56-0d759e2f37eb. Acesso em 2026-09-06.
- Jonasson, Martin, e Petri Purho. “Juice it or lose it.” Publicado em 2012-05-24. https://www.youtube.com/watch?v=Fy0aCDmgnxg. Acesso em 2026-08-18.
- Jonasson, Martin, e Petri Purho.
grapefrukt/juicy-breakout. Criado em 2012-05-08. https://github.com/grapefrukt/juicy-breakout. Acesso em 2026-08-18. - Moran, Kate; Nielsen Norman Group. “Usability (User) Testing 101.” Publicado em 2019-12-01; revisado em 2026-07-15. https://www.nngroup.com/articles/usability-testing-101/. Acesso em 2026-08-18.